WO2024093833A1 - 一种通信方法和通信装置 - Google Patents

一种通信方法和通信装置 Download PDF

Info

Publication number
WO2024093833A1
WO2024093833A1 PCT/CN2023/127192 CN2023127192W WO2024093833A1 WO 2024093833 A1 WO2024093833 A1 WO 2024093833A1 CN 2023127192 W CN2023127192 W CN 2023127192W WO 2024093833 A1 WO2024093833 A1 WO 2024093833A1
Authority
WO
WIPO (PCT)
Prior art keywords
message
iab node
iab
topology
migration
Prior art date
Application number
PCT/CN2023/127192
Other languages
English (en)
French (fr)
Inventor
朱世超
孙飞
朱元萍
史玉龙
Original Assignee
华为技术有限公司
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 华为技术有限公司 filed Critical 华为技术有限公司
Publication of WO2024093833A1 publication Critical patent/WO2024093833A1/zh

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W36/00—Hand-off or reselection arrangements
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W36/00—Hand-off or reselection arrangements
    • H04W36/08—Reselecting an access point
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W36/00—Hand-off or reselection arrangements
    • H04W36/24—Reselection being triggered by specific parameters
    • H04W36/30—Reselection being triggered by specific parameters by measured or perceived connection quality data

Definitions

  • the present application relates to the field of communications, and in particular to a communication method and a communication device.
  • the fifth generation mobile communication has put forward more stringent requirements for various network performance indicators. For example, the capacity is increased by 1000 times, the coverage requirements are wider, and the ultra-high reliability and ultra-low latency are required.
  • the capacity is increased by 1000 times, the coverage requirements are wider, and the ultra-high reliability and ultra-low latency are required.
  • the use of high-frequency small base stations to form a network is becoming more and more popular. The propagation characteristics of high-frequency carriers are poor, the attenuation is serious due to obstruction, and the coverage range is not wide, so a large number of small base stations need to be deployed densely.
  • IAB Integrated access and backhaul
  • a relay node In an IAB network, a relay node, or IAB-node, can provide wireless access services for user equipment (UE, user equipment).
  • the service data of the UE is transmitted by the IAB-node connected to the IAB host (IAB-donor) through a wireless backhaul link.
  • the IAB-node includes a mobile termination (MT) part and a distributed unit (DU) part.
  • MT mobile termination
  • DU distributed unit
  • the IAB-donor is an access network element with complete base station (such as gNB) functions, including a centralized unit (CU) and a distributed unit (DU).
  • the IAB-donor is connected to the core network serving the UE (for example, connected to the 5G core network).
  • the cross-CU migration of IAB nodes is divided into two implementation methods: full migration and partial migration.
  • partial migration the MT of the migrating IAB node, that is, the boundary node, switches across CUs, but the DU of the boundary node still maintains an F1 connection with the source CU; while in full migration, the DU of the boundary node needs to establish an F1 connection with the target CU.
  • the essential difference between full migration and partial migration is whether DU migration is required (in fact, a new logical DU is generated and then an F1 interface is established with the target CU, but from the macro perspective of the IAB node, it can usually be expressed as "DU migration").
  • An embodiment of the present application discloses a communication method and a communication device, which can realize DU migration in continuous partial migration.
  • an embodiment of the present application provides a communication method, which is applied to a first CU or a module in the first CU, and the method includes: receiving a first message, the first message including an identification (ID) of an MT for identifying an IAB node in a third CU and the ID of the third CU; determining whether to perform migration of the DU of the IAB node based on the first message; and sending a second message to the IAB node if it is determined that the DU migration of the IAB node is to be performed, wherein the second message is used to instruct the DU of the IAB node to establish an F1 interface with the third CU.
  • ID identification
  • the first CU determines whether to migrate the DU of the IAB node based on the first message.
  • the first CU receiving the first message is a trigger condition for the first CU to decide whether to migrate the DU of the IAB node. Therefore, an embodiment of the present application provides a trigger condition for the first CU to decide whether to migrate the DU of the IAB node. Determine whether to migrate the DU of the IAB node based on the first message. It can be seen that the embodiment of the present application also provides a basis for the first CU to decide whether to migrate the DU of the IAB node.
  • sending a second message to the IAB node is a DU migration method provided by an embodiment of the present application.
  • Embodiment of the present application The solution in the embodiment can support DU migration triggered by topology change of MT, and solves the problem of migrating DU in the process of continuous partial migration which is not supported by the existing technology.
  • the second message is used to instruct the DU of the IAB node to generate a new logical DU and establish an F1 interface with the third CU.
  • the first CU instructs the DU of the IAB node to generate a new logical DU by sending the second message, and establishes an F1 interface with the third CU, so as to implement the migration of the DU of the IAB node.
  • the first message further includes the IP address of the third CU or the IP address of the host DU managed by the third CU.
  • the first message also includes the IP address of the third CU or the IP address of the host DU managed by the third CU, so that the first CU determines whether to perform DU migration of the IAB node based on the IP address of the third CU or the IP address of the host DU managed by the third CU.
  • the determining whether to perform migration of the DU of the IAB node according to the first message includes: determining whether the first CU can reach the third CU or the host DU managed by the third CU without going through the core network according to the first message; or, determining whether the first CU can establish an XN interface with the third CU according to the first message; or, determining whether the first CU can reach the third CU or the host DU managed by the third CU through IP routing according to the first message.
  • the first CU cannot reach the third CU or the host DU managed by the third CU without going through the core network, it is determined to perform migration of the DU of the IAB node; if the first CU can reach the third CU or the host DU managed by the third CU without going through the core network, it is determined not to perform migration of the DU of the IAB node. If the first CU can establish an XN interface with the third CU, it is determined not to perform migration of the DU of the IAB node; if the first CU cannot establish an XN interface with the third CU, it is determined to perform migration of the DU of the IAB node.
  • the first CU can reach the third CU or the host DU managed by the third CU through IP routing, it is determined not to migrate the DU of the IAB node; if the first CU cannot reach the third CU or the host DU managed by the third CU through IP routing, it is determined to migrate the DU of the IAB node.
  • three methods are provided for determining whether to perform the migration of the DU of the IAB node according to the first message; and whether to perform the migration of the DU of the IAB node can be determined more reasonably.
  • radio resource control RRC
  • RRC radio resource control
  • the first message is used to indicate that the MT will switch from the topology under the second CU to the topology under the third CU, the MT has completed the switch from the topology under the second CU to the topology under the third CU, or a wireless link failure occurs between the MT and the second CU and accesses the topology under the third CU.
  • the first message may be triggered in time, and the first CU decides whether to migrate the DU of the IAB node.
  • a radio resource control RRC connection is established between the MT and the second CU; the method further includes: in a case where it is determined that DU migration of the IAB node is to be performed, sending a third message to the second CU, wherein the third message is used to request the second CU to configure resources for the F1 interface between the DU of the IAB node and the third CU within its topology.
  • a third message is sent to the second CU so that the second CU configures resources for the F1 interface between the DU of the IAB node and the third CU within its topology; the interaction between the DU of the IAB node and the third CU through NG can be avoided, thereby speeding up the migration of the DU.
  • the first message is used to indicate that the MT will switch from the topology under the second CU to the topology under the third CU; after sending the third message to the second CU, the method also includes: receiving a fourth message, wherein the fourth message is used to indicate that the F1 interface between the DU of the IAB node and the third CU has been established.
  • the method further includes: after sending a first switching command to the terminal device, sending a fifth message to the second CU, wherein the first switching command is used to instruct the terminal device to switch to the target cell under the DU of the IAB node, and the fifth message is used to indicate that the first CU has sent the first switching command.
  • the fifth message is sent to the second CU so that the second CU sends the switching instruction to the MT of the IAB node in time.
  • the method further includes: initiating an IAB transmission migration management process in partial migration to the third CU when it is determined that the IAB node DU migration is not to be performed, the process being used for cross-topology migration of traffic.
  • traffic between the first CU and the IAB node can be transmitted through the topology under the third CU, thereby ensuring service continuity of the UE served by the IAB node.
  • the IAB transmission migration management process of initiating partial migration to the third CU includes: sending a sixth message to an access and mobility management function (access and mobility management) network element, the sixth message including the IP address of the traffic of the IAB node under the third CU and the service quality QoS information of the traffic of the IAB node; receiving a seventh message from the access and mobility management function network element, the seventh message including the backhaul link information under the third CU and the differentiated services code point (differentiated services code point, DSCP) or flow label (Flow Label) information of the traffic of the IAB node.
  • DSCP differentiated services code point
  • Flow Label flow label
  • the backhaul link information under the third CU and the DSCP or retention flow signature of the traffic of the IAB node can be obtained through the access and mobility management function network element.
  • an embodiment of the present application provides another communication method, which is applied to a second CU or a module in the second CU, and the method includes: generating a first message; sending the first message to the first CU, wherein the first message is used to indicate that the MT of the IAB node will switch from the topology under the second CU to the topology under the third CU, the MT has completed the switch from the topology under the second CU to the topology under the third CU, or a wireless link failure occurs between the MT and the second CU and accesses the topology under the third CU.
  • a first message is sent to the first CU to trigger the first CU to decide whether to migrate the DU of the IAB node, and a triggering condition for the first CU to decide whether to migrate the DU of the IAB node is given.
  • the method further includes: receiving a third message from the first CU; and configuring resources for an F1 interface between the DU of the IAB node and the third CU within its topology according to the third message.
  • the second CU configures resources for the F1 interface between the DU of the IAB node and the third CU within its topology, which can help establish the F1 interface between the DU of the IAB node and the third CU.
  • the method before sending the first message to the first CU, the method further includes: receiving an eighth message from a third CU, the eighth message being used to indicate that the MT of the IAB node will switch to the topology under the third CU, the MT has switched to the topology under the third CU, or the MT has accessed the topology under the third CU after a radio link failure occurs between the MT and the second CU.
  • Receiving the eighth message is a trigger condition for the second CU to send the first message to the first CU.
  • the eighth message from the third CU is received so as to send the first message to the first CU in time, that is, to trigger the first CU to decide whether to perform migration of the DU of the IAB node.
  • the eighth message includes the IP address of the third CU and/or the IP address of the host DU managed by the third CU.
  • the eighth message includes the IP address of the third CU and/or the IP address of the host DU managed by the third CU, so that the second CU provides the IP address of the third CU and/or the IP address of the host DU managed by the third CU to the first CU.
  • the first message includes an ID for identifying the MT in the third CU and an ID of the third CU.
  • the first CU may determine whether to perform migration of the DU of the IAB node according to the first message.
  • the method also includes: receiving a fifth message from the first CU, the fifth message being used to indicate that the first CU has sent a first switching command to the terminal device, the first switching command being used for the terminal device to switch to the target cell under the DU of the IAB node; and sending a second switching command to the MT, the second switching command being used for the MT of the IAB node to switch to the topology under the third CU.
  • the MT of the IAB node can be switched to the topology under the third CU in a timely manner.
  • an embodiment of the present application provides another communication method, which is applied to a third CU or a module in the third CU, and the method includes: generating a first message; sending the first message to the first CU, wherein the first message is used to indicate that the MT of the IAB node will switch from the topology under the second CU to the topology under the third CU, the MT has completed the switch from the topology under the second CU to the topology under the third CU, or a wireless link failure occurs between the MT and the second CU and accesses the topology under the third CU.
  • a first message is sent to the first CU to trigger the first CU to decide whether to migrate the DU of the IAB node, and a triggering condition for the first CU to decide whether to migrate the DU of the IAB node is given.
  • the method further includes: sending a fourth message to the first CU, where the fourth message is used to indicate that an F1 interface between the DU of the IAB node and the third CU has been established.
  • sending the fourth message to the first CU can indicate that the F1 interface between the DU of the IAB node and the third CU has been established.
  • the first message includes an ID for identifying the MT in the third CU and an ID of the third CU.
  • the first CU may determine whether to perform migration of the DU of the IAB node according to the first message.
  • the method before sending the first message to the first CU, the method further includes: sending a ninth message to the second CU or receiving a tenth message from the second CU, the ninth message being used to indicate that the MT will switch to the topology under the third CU or that the MT has been transformed to the topology under the third CU, and the tenth message being used to indicate that the MT has been transformed to the topology under the third CU.
  • Sending the ninth message to the second CU or receiving the tenth message from the second CU is a trigger condition for the third CU to send the first message to the first CU.
  • the first message can be sent to the first CU in a timely manner, that is, the first CU is triggered to decide whether to perform migration of the DU of the IAB node.
  • the ninth message includes the IP address of the third CU and/or the IP address of the host DU managed by the third CU.
  • the ninth message includes the IP address of the third CU and/or the IP address of the host DU managed by the third CU, so that the second CU provides the IP address of the third CU and/or the IP address of the host DU managed by the third CU to the first CU.
  • the tenth message includes the ID of the MT under the first CU.
  • the tenth message includes the ID of the MT under the first CU, so that the third CU sends the first message to the first CU according to the tenth message.
  • the method further includes: responding to an IAB transmission migration management process in the partial migration initiated by the first CU to the third CU.
  • the IAB transmission migration management process in response to the partial migration initiated by the first CU to the third CU includes: receiving an eleventh message from an access and mobility management function network element, the eleventh message including the IP address of the traffic of the IAB node under the third CU and the QoS information of the traffic of the IAB node; sending a twelfth message to the access and mobility management function network element, the twelfth message including the backhaul link information under the third CU and the differentiated service coding point or flow label information of the traffic of the IAB node.
  • the access and mobility management function network element provides the first CU with the backhaul link information under the third CU and the DSCP or retention flow signature of the traffic of the IAB node.
  • an embodiment of the present application provides another communication method, which is applied to an IAB node or a module in an IAB node, and the method includes: switching the MD of the IAB node from the topology under the second CU to the topology under the third CU; sending a first message to the first CU, wherein the first message includes an ID for identifying the MT in the third CU, such as the XNAP ID of the MT under the third CU. For example, after the MT of the IAB node switches to the topology under the third CU, the DU of the IAB node sends a first message to the first CU.
  • the DU of the IAB node sends a first message to the first CU.
  • the DU of the IAB node sends a first message to the first CU.
  • a first message is sent to the first CU to trigger the first CU to decide whether to migrate the DU of the IAB node, and a triggering condition for the first CU to decide whether to migrate the DU of the IAB node is given.
  • the first message includes the IP address of the third CU and/or the IP address of the host DU managed by the third CU.
  • the first message includes the IP address of the third CU and/or the IP address of the host DU managed by the third CU, so that the first CU determines whether to migrate the DU of the IAB node based on the IP address of the third CU and/or the IP address of the host DU managed by the third CU.
  • the method further includes: receiving a second message from the first CU; and establishing an F1 interface with the third CU according to the second message.
  • the DU of the IAB node generates a new logical DU and establishes an F1 interface with the third CU.
  • the F1 interface can be established with the third CU in a timely manner.
  • an embodiment of the present application provides a communication method, which is applied to an IAB node or a module in an IAB node, and the method includes: sending a first message to a CU, wherein the first message is used to indicate a cell that the IAB node wishes to activate; and receiving a second message, wherein the second message is used to activate the cell that the IAB node wishes to activate.
  • the DU of the IAB node sends a first message to the CU and receives a second message, so as to activate the cell that the IAB node wishes to activate.
  • the first message is further used to indicate a cell that the IAB node wants to shut down; the method further includes: receiving a third message, wherein the second message is used to shut down the cell that the IAB node wants to shut down.
  • the DU of the IAB node receives the third message so as to timely shut down the cell that the IAB node wishes to shut down.
  • the DU of the IAB node sending the first message to the CU includes: sending the first message to the CU when a cell identity conflict is detected.
  • the first message can be sent in time.
  • an embodiment of the present application provides another cell switching method, which is applied to a CU, and the method includes:
  • a first message is received from a DU of an IAB node, where the first message is used to indicate a cell that the IAB node wishes to activate; and a second message is sent to the DU of the IAB node, where the second message is used to activate the cell that the IAB node wishes to activate.
  • the cell that the IAB node wants to activate can be activated.
  • the first message is also used to indicate the cell that the IAB node wishes to shut down; after the CU sends the second message to the DU of the IAB node, the method further includes: after receiving a switching completion message from the terminal device, sending a third message to the DU of the IAB node, the third message being used to shut down the cell that the IAB node wishes to shut down, and the switching completion message being used to indicate that the terminal device has switched to the cell that the IAB node wishes to activate.
  • the cell that the IAB node wishes to deactivate can be deactivated.
  • the method further includes: sending a switching command to the terminal device, where the switching command is used for the terminal device to switch to the cell that the IAB node wishes to activate.
  • the CU sends a switching command to the terminal device so that the terminal device switches to the cell that the IAB node wishes to activate, thereby improving communication quality.
  • an embodiment of the present application provides a communication device, which has the function of implementing the behavior in the method embodiment of the first aspect above.
  • the communication device may be a communication device, or a component of a communication device (such as a processor, a chip, or a chip system, etc.), or a logic module or software that can implement all or part of the functions of the communication device.
  • the function of the communication device may be implemented by hardware, or may be implemented by hardware executing corresponding software, and the hardware or software includes one or more modules or units corresponding to the above functions.
  • the communication device includes a transceiver unit and a processing unit, wherein: the transceiver unit is used to receive a first message, the first message includes an ID of an MT for identifying an IAB node in a third CU and an ID of the third CU; the processing unit is used to determine whether to migrate the DU of the IAB node according to the first message; in the case of determining that the DU of the IAB node is to be migrated, a second message is sent to the IAB node through the transceiver unit, wherein the second message is used to instruct the DU of the IAB node to establish an F1 interface with the third CU.
  • the processing unit is specifically used to determine, based on the first message, whether the first CU can reach the third CU or the host DU managed by the third CU without going through the core network; or, based on the first message, determine whether the first CU can establish an XN interface with the third CU; or, based on the first message, determine whether the first CU can reach the third CU or the host DU managed by the third CU through IP routing.
  • a radio resource control RRC connection is established between the MT and the second CU; the processing unit is further used to send a third message to the second CU through the transceiver unit when it is determined that DU migration of the IAB node is to be performed, wherein the third message is used to request the second CU to configure resources for the F1 interface between the DU of the IAB node and the third CU within its topology.
  • the first message is used to indicate that the MT will switch from the topology under the second CU to the topology under the third CU; the transceiver unit is also used to receive a fourth message, and the fourth message is used to indicate that the F1 interface between the DU of the IAB node and the third CU has been established.
  • the transceiver unit is also used to send a fifth message to the second CU after sending a first switching command to the terminal device, wherein the first switching command is used to instruct the terminal device to switch to the target cell under the DU of the IAB node, and the fifth message is used to indicate that the first CU has sent the first switching command.
  • the processing unit is further configured to initiate an IAB transmission migration management process in partial migration to the third CU through the transceiver unit when determining not to perform the IAB node DU migration, wherein the process is used for cross-topology migration of traffic.
  • the transceiver unit is specifically used to send a sixth message to the access and mobility management function network element, wherein the sixth message includes the IP address of the traffic of the IAB node under the third CU and the quality of service QoS information of the traffic of the IAB node; and receive a seventh message from the access and mobility management function network element, wherein the seventh message includes the backhaul link information under the third CU and the DSCP or flow label information of the traffic of the IAB node.
  • Possible implementations of the communication device of the seventh aspect may refer to various possible implementations of the first aspect.
  • an embodiment of the present application provides another communication device, which has the function of implementing the behavior in the method embodiment of the second aspect above.
  • the communication device may be a communication device, or a component of a communication device (such as a processor, a chip, or a chip system, etc.), or a logic module or software that can implement all or part of the functions of the communication device.
  • the function of the communication device may be implemented by hardware, or may be implemented by hardware executing corresponding software, and the hardware or software includes one or more modules or units corresponding to the above functions.
  • the communication device includes a transceiver unit and a processing unit, wherein: the processing unit is used to generate a first message; the transceiver unit is used to send the first message to the first CU, and the first message is used to indicate that the MT of the IAB node will switch from the topology under the second CU to the topology under the third CU, the MT has completed the switch from the topology under the second CU to the topology under the third CU, or the MT has a wireless link failure with the second CU and accesses any one of the topologies under the third CU.
  • the transceiver unit is further used to receive a third message from the first CU; the processing unit is further used to configure resources for the F1 interface between the DU of the IAB node and the third CU within its topology according to the third message.
  • the transceiver unit is further configured to receive an eighth message from the third CU, the eighth message being used to indicate that the MT of the IAB node will switch to the topology under the third CU, the MT has switched to the topology under the third CU, or the MT has accessed the topology under the third CU after a radio link failure occurs between the MT and the second CU.
  • Receiving the eighth message is a trigger condition for the second CU to send the first message to the first CU.
  • the transceiver unit is also used to receive a fifth message from the first CU, where the fifth message is used to indicate that the first CU has sent a first switching command to the terminal device, and the first switching command is used for the terminal device to switch to the target cell under the DU of the IAB node; and send a second switching command to the MT, and the second switching command is used for the MT of the IAB node to switch to the topology under the third CU.
  • Possible implementations of the communication device of the eighth aspect may refer to various possible implementations of the second aspect.
  • an embodiment of the present application provides another communication device, which has the function of implementing the behavior in the method embodiment of the third aspect above.
  • the communication device may be a communication device, or a component of a communication device (such as a processor, a chip, or a chip system, etc.), or a logic module or software that can implement all or part of the functions of the communication device.
  • the function of the communication device can be implemented by hardware, or by hardware executing corresponding software implementations, and the hardware or software includes one or more modules or units corresponding to the above functions.
  • the communication device includes a transceiver unit and a processing unit, wherein: the processing unit is used to generate a first message; the transceiver unit is used to send the first message to the first CU, and the first message is used to indicate that the MT of the IAB node will switch from the topology under the second CU to the topology under the third CU, the MT has completed the switch from the topology under the second CU to the topology under the third CU, or the MT has a wireless link failure with the second CU and accesses any one of the topologies under the third CU.
  • the transceiver unit is further configured to send a fourth message to the first CU, where the fourth message is used to indicate that an F1 interface between the DU of the IAB node and the third CU has been established.
  • the transceiver unit is further configured to send a ninth message to the second CU or receive a tenth message from the second CU, the ninth message being used to indicate that the MT will switch to the topology under the third CU or that the MT has been transformed to the topology under the third CU, and the tenth message being used to indicate that the MT has been transformed to the topology under the third CU.
  • Sending the ninth message to the second CU or receiving the tenth message from the second CU is a trigger condition for the third CU to send the first message to the first CU.
  • the processing unit is further configured to respond to an IAB transmission migration management process in the partial migration initiated by the first CU to the third CU.
  • the transceiver unit is also used to receive an eleventh message from an access and mobility management function network element, the eleventh message including the IP address of the traffic of the IAB node under the third CU and the QoS information of the traffic of the IAB node; and send a twelfth message to the access and mobility management function network element, the twelfth message including the backhaul link information under the third CU and the differentiated service coding point or flow label information of the traffic of the IAB node.
  • Possible implementations of the communication device of the ninth aspect may refer to various possible implementations of the third aspect.
  • an embodiment of the present application provides another communication device, which has the function of implementing the behavior in the method embodiment of the fourth aspect.
  • the communication device can be a communication device, or a component of a communication device (such as a processor, a chip, or a chip system, etc.), or a logic module or software that can implement all or part of the functions of the communication device.
  • the functions of the communication device can be implemented by hardware, The corresponding software implementation may also be executed by hardware, and the hardware or software includes one or more modules or units corresponding to the above functions.
  • the communication device includes a transceiver unit and a processing unit, wherein: the processing unit is used to switch the MD of the IAB node from the topology under the second CU to the topology under the third CU; the transceiver unit is used to send a first message to the first CU, and the first message includes an ID for identifying the MT in the third CU, such as the XNAP ID of the MT under the third CU.
  • the transceiver unit is further used to receive a second message from the first CU; the processing unit is further used to establish an F1 interface with the third CU according to the second message.
  • Possible implementations of the communication device of the tenth aspect may refer to various possible implementations of the fourth aspect.
  • an embodiment of the present application provides another communication device, which has the function of implementing the behavior in the method embodiment of the fifth aspect above.
  • the communication device can be a communication device, or a component of a communication device (such as a processor, a chip, or a chip system, etc.), or a logic module or software that can implement all or part of the functions of the communication device.
  • the functions of the communication device can be implemented by hardware, or by hardware executing corresponding software implementations, and the hardware or software includes one or more modules or units corresponding to the above functions.
  • the communication device includes a transceiver unit and a processing unit, wherein: the processing unit is used to generate a first message; the transceiver unit is used to send the first message to the CU, and the first message is used to indicate the cell that the IAB node wishes to activate; receive a second message, and the second message is used to activate the cell that the IAB node wishes to activate.
  • the first message is further used to indicate a cell that the IAB node wishes to close;
  • the transceiver unit is further used to receive a third message, wherein the second message is used to close the cell that the IAB node wishes to close.
  • the processing unit is configured to send the first message to the CU through the transceiver unit when a cell identifier conflict is detected.
  • Possible implementations of the communication device of the eleventh aspect may refer to various possible implementations of the fifth aspect.
  • an embodiment of the present application provides another communication device, which has the function of implementing the behavior in the above-mentioned sixth aspect method embodiment.
  • the communication device can be a communication device, or a component of a communication device (such as a processor, a chip, or a chip system, etc.), or a logic module or software that can implement all or part of the functions of the communication device.
  • the function of the communication device can be implemented by hardware, or it can be implemented by hardware executing corresponding software, and the hardware or software includes one or more modules or units corresponding to the above functions.
  • the communication device includes a transceiver unit and a processing unit, wherein: the transceiver unit is used to receive a first message from the DU of the IAB node, and the first message is used to indicate the cell that the IAB node wants to activate; the processing unit is used to generate a second message; the transceiver unit is also used to send a second message to the DU of the IAB node, and the second message is used to activate the cell that the IAB node wants to activate.
  • the first message is also used to indicate the cell that the IAB node wishes to shut down; the transceiver unit is also used to send a third message to the DU of the IAB node after receiving the switching completion message from the terminal device, wherein the third message is used to shut down the cell that the IAB node wishes to shut down, and the switching completion message is used to indicate that the terminal device has switched to the cell that the IAB node wishes to activate.
  • the transceiver unit is further configured to send a switching command to the terminal device, where the switching command is used for the terminal device to switch to the cell that the IAB node wishes to activate.
  • Possible implementations of the communication device of the twelfth aspect may refer to various possible implementations of the sixth aspect.
  • an embodiment of the present application provides another communication device, which includes a processor, the processor is coupled to a memory, the memory is used to store programs or instructions, when the program or instructions are executed by the processor, the communication device executes the method shown in any one of the above-mentioned first aspect to the above-mentioned sixth aspect.
  • the process of sending information (or signal) in the above method can be understood as the process of outputting information based on the instructions of the processor.
  • the processor When outputting information, the processor outputs the information to the transceiver so that it can be transmitted by the transceiver. After the information is output by the processor, it may also need to be processed in other ways before it reaches the transceiver.
  • the processor receives input information
  • the transceiver receives the information and inputs it into the processor.
  • the information may need to be processed in other ways before it is input into the processor.
  • the processor may be a processor specifically used to execute these methods, or may be a processor that executes computer instructions in a memory to execute these methods, such as a general-purpose processor, etc.
  • the processor may also be used to execute a program stored in the memory, and when the program is executed, the communication device executes the method as shown in the first aspect or any possible implementation of the first aspect.
  • the memory is located outside the communication device. In a possible implementation, the memory is located inside the communication device.
  • the processor and the memory may also be integrated into one device, that is, the processor and the memory may also be integrated together.
  • the communication device further includes a transceiver, and the transceiver is used to receive a signal or send a signal.
  • the present application provides another communication device, which includes a processing circuit and an interface circuit, wherein the interface circuit is used to acquire or output data; the processing circuit is used to execute the method shown in any one of the above-mentioned first to sixth aspects.
  • the present application provides a computer-readable storage medium, in which a computer program is stored.
  • the computer program includes program instructions, which, when executed, enable the computer to execute the method shown in any one of the above-mentioned first to sixth aspects.
  • the present application provides a computer program product, which includes a computer program, and the computer program includes program instructions, which, when executed, enable the computer to execute the method shown in any one of the above-mentioned first to sixth aspects.
  • the present application provides a communication system, comprising the communication device described in the seventh aspect or any possible implementation of the seventh aspect, the communication device described in the eighth aspect or any possible implementation of the eighth aspect, and the communication device described in the eighth aspect or any possible implementation of the eighth aspect.
  • the present application provides a communication system, comprising the communication device described in the above-mentioned eleventh aspect or any possible implementation of the eleventh aspect, and the communication device described in the above-mentioned twelfth aspect or any possible implementation of the twelfth aspect.
  • the present application provides a chip comprising a processor and a communication interface, wherein the processor reads instructions stored in a memory through the communication interface and executes a method as shown in any one of the first to sixth aspects above.
  • FIG1 is a schematic diagram of the architecture of a communication system used in an embodiment of the present application.
  • FIG2 shows an example of an IAB network including multiple UEs and multiple IAB nodes
  • FIG3 is a schematic diagram of an IAB network architecture
  • FIG4 is a schematic diagram of a control plane protocol architecture in an IAB network
  • FIG5 is a schematic diagram of a user plane protocol architecture in an IAB network
  • FIG6 shows a schematic diagram of an IAB network architecture
  • Figure 7 is a schematic diagram of a partial migration
  • FIG8 is a schematic diagram of a full migration
  • Figure 9 is an example of a continuous partial migration (no DU migration) scenario
  • FIG10 is an example of a scenario of migrating DUs in a continuous partial migration provided in an embodiment of the present application.
  • FIG11 shows a schematic diagram of a mobile IAB node
  • FIG12 is an interactive flow chart of a DU migration method in an IAB network provided in an embodiment of the present application.
  • FIG13 is an interactive flow chart of another DU migration method in an IAB network provided in an embodiment of the present application.
  • FIG14 is an interactive flow chart of another DU migration method in an IAB network provided in an embodiment of the present application.
  • FIG15 is an example of a continuous partial migration provided in an embodiment of the present application.
  • FIG16 is an example of a state in which an MT in an IAB network is switched after completion provided by an embodiment of the present application
  • FIG17 is an interactive flow chart of another DU migration method in an IAB network provided in an embodiment of the present application.
  • FIG18 is a flow chart of information interaction provided in an embodiment of the present application.
  • FIG19 is a flow chart of another information interaction method provided in an embodiment of the present application.
  • FIG20 is an interactive flow chart of a cell switching method provided by an embodiment of the present application.
  • FIG21 shows a possible exemplary block diagram of a communication device involved in an embodiment of the present application
  • FIG22 is a schematic diagram of the structure of a simplified terminal device provided by the present application.
  • FIG. 23 is a schematic diagram of the structure of a network device 2300 provided in an embodiment of the present application.
  • a process, method, system, product or equipment, etc., comprising a series of steps or units is not limited to the listed steps or units, but optionally also includes steps or units that are not listed, etc., or optionally also includes other steps or units inherent to these processes, methods, products or equipment, etc.
  • a corresponds to B means that there is a corresponding relationship between A and B, and B can be determined according to A.
  • determining (or generating) B according to (or based on) A does not mean that B is determined (or generated) only according to (or based on) A, and B can also be determined (or generated) according to (or based on) A and/or other information.
  • FIG1 is a schematic diagram of the architecture of a communication system used in an embodiment of the present application.
  • the communication system includes a core network device 110, a wireless access network device 120, a wireless backhaul device 130, and at least one terminal device (in FIG1, terminal devices 140 and 150 are described as examples).
  • the terminal device is connected to the wireless backhaul device wirelessly, and is connected to the wireless access network device through one or more wireless backhaul devices. In addition, some terminal devices may also be directly connected to the wireless access network device wirelessly).
  • the wireless access network device is connected to the core network device wirelessly or wired.
  • the core network device and the wireless access network device may be independent and different physical devices, or the functions of the core network device and the logical functions of the wireless access network device may be integrated on the same physical device, or the functions of some core network devices and some wireless access network devices may be integrated on a physical device, and this application does not limit this.
  • the terminal device may be fixed or movable. It should be understood that the mobile communication system shown in FIG1 is only a schematic diagram, and the communication system may also include other network devices, such as wireless relay devices or wireless backhaul devices, which are not shown in FIG1. The embodiment of the present application does not limit the number of core network devices, wireless access network devices, wireless backhaul devices and terminal devices included in the mobile communication system.
  • the wireless access network equipment is the access equipment that the terminal equipment accesses to the mobile communication system by wireless means, which can be a base station NodeB, an evolved base station eNodeB, a base station in a 5G mobile communication system, a base station in a future mobile communication system, or an access node in a WiFi system, etc.
  • the embodiments of this application do not limit the specific technology and specific equipment form adopted by the wireless access network equipment.
  • the terminal equipment can also be called a terminal, UE, mobile station (MS), mobile terminal (MT), etc.
  • the terminal device can be a mobile phone, a tablet computer, a computer with wireless transceiver function, a virtual reality (VR) terminal device, an augmented reality (AR) terminal device, a cellular phone, a smart phone, a wireless data card, a personal digital assistant (PDA), a wireless terminal in industrial control, a wireless terminal in self driving, a wireless terminal in remote medical surgery, a wireless terminal in smart grid, a wireless terminal in transportation safety, a wireless terminal in smart city, a wireless terminal in smart home, a machine type communication (MTC) terminal, a wearable device, a vehicle-mounted terminal device, a drone, etc.
  • VR virtual reality
  • AR augmented reality
  • a cellular phone a smart phone
  • smart phone a wireless data card
  • PDA personal digital assistant
  • MTC machine type communication
  • the wireless backhaul device can provide backhaul services for its child nodes.
  • it can be a relay node in the long-term evolution (LTE) system, an IAB node in the 5G system, or other devices that can provide wireless relay functions.
  • Wireless access network equipment and terminal equipment can be deployed on land, including indoors or outdoors, handheld or vehicle-mounted; can also be deployed on the water; can also be deployed on Aircraft, balloons and artificial satellites in the air.
  • the embodiments of the present application do not limit the application scenarios of the wireless access network equipment and the terminal equipment.
  • the wireless access network equipment and the terminal equipment, as well as the terminal equipment and the terminal equipment, may communicate through the licensed spectrum (licensed spectrum), may communicate through the unlicensed spectrum (unlicensed spectrum), or may communicate through the licensed spectrum and the unlicensed spectrum at the same time.
  • the wireless access network equipment and the terminal equipment, as well as the terminal equipment and the terminal equipment may communicate through the spectrum below 6 gigahertz (GHz), may communicate through the spectrum above 6 GHz, or may communicate through the spectrum below 6 GHz and the spectrum above 6 GHz at the same time.
  • GHz gigahertz
  • the embodiments of the present application do not limit the spectrum resources used between the wireless access network equipment and the terminal equipment.
  • the above-mentioned network elements can be network elements implemented on dedicated hardware, software instances running on dedicated hardware, or instances of virtualized functions on appropriate platforms.
  • the embodiments of the present application can also be applied to other future-oriented communication technologies.
  • the network architecture and business scenarios described in this application are intended to more clearly illustrate the technical solutions of this application and do not constitute a limitation on the technical solutions provided in this application. It is known to those of ordinary skill in the art that with the evolution of the network architecture and the emergence of new business scenarios, the technical solutions provided in this application are also applicable to similar technical problems.
  • IAB network Considering the small coverage of high frequency bands, in order to ensure the coverage performance of the network and provide network coverage in some remote areas, the deployment of optical fiber is difficult and costly, and it is also necessary to design flexible and convenient access and backhaul solutions. IAB technology came into being. Its access link and backhaul link both use wireless transmission solutions to avoid optical fiber deployment and reduce equipment costs.
  • a relay node In the IAB network, a relay node, or IAB-node, can provide wireless access services for UEs, and the service data of UEs is transmitted by the IAB-node to the IAB-donor through a wireless backhaul link.
  • the IAB node can establish a wireless backhaul link with one or more upper-level nodes and access the core network through the upper-level node.
  • the upper-level node can perform certain control on the relay node through various signaling (for example, data scheduling, timing modulation, power control, etc.).
  • the relay node can establish an access link with one or more lower-level nodes and provide access services to one or more lower-level nodes.
  • the upper-level node of the relay node can be a base station or another relay node.
  • the lower-level node of the relay node can be a terminal or another relay node.
  • the upper-level node of an IAB node can also be called its upstream node or parent node, and the lower-level node of the IAB node can also be called its downstream node or child node.
  • Multi-hop networking may be used in the IAB network.
  • the IAB node can support dual connectivity (DC) or multi-connectivity to cope with abnormal situations that may occur in the backhaul link (for example, interruption or blockage of the wireless link and load fluctuation, etc.) to improve the reliability of transmission. Therefore, the IAB network can support multi-hop and multi-connection networking, and there may be multiple routing paths between the terminal device and the host base station. Among them, on one path, there is a definite hierarchical relationship between the IAB nodes, and between the IAB nodes and the host base station serving the IAB nodes. Each IAB node regards the node that provides backhaul services to it as a parent node, and accordingly, each IAB node can be regarded as a child node of its parent node.
  • Wireless link congestion may refer to the amount of uplink or downlink cache data to be transmitted by a certain IAB node on a certain link exceeding a certain threshold.
  • the IAB node may include an MT part (i.e., IAB-node-MT) and a DU part (i.e., IAB-node-DU.
  • IAB-node-MT MT part
  • IAB-node-DU DU part
  • the IAB node faces its parent node, it can be regarded as a terminal device accessing the parent node, that is, as a role of MT; when the IAB faces its child node, it can be regarded as a network device providing backhaul services for the child node, that is, as a role of DU, wherein the child node here may be another IAB node or a terminal device.
  • An IAB donor node can be an access network element with complete base station functions, such as a donor base station DgNB, or an access network element with a centralized unit (CU) and DU separated.
  • the IAB donor node is connected to the core network element (e.g., connected to the 5G core network) serving the terminal device and provides wireless backhaul functions for the IAB node.
  • the centralized unit of the IAB donor node can be referred to as donor CU or IAB-donor CU
  • the distributed unit of the IAB donor node can be referred to as donor DU or IAB-donor DU.
  • the donor CU may also be in a form of separation of the control plane (CP) and the user plane (UP).
  • the CU can be composed of a CU-CP and one (or more) CU-UPs.
  • one or more IAB-nodes may be included on a transmission path between a UE and an IAB-donor.
  • Each IAB-node needs to maintain a wireless backhaul link to the parent node and also needs to maintain a wireless link with the child node. If the child node of an IAB-node is a terminal device, the wireless access link is between the IAB-node and the child node (i.e., the terminal device). If the child node of an IAB-node is another IAB-node, the wireless backhaul link is between the IAB-node and the child node (i.e., the other IAB-node).
  • Figure 2 shows a wireless backhaul link including multiple UEs and An example of an IAB network with multiple IAB nodes.
  • Figure 2 takes an example including 2 UEs and 5 IAB nodes. Among them, the 2 UEs are UE1 and UE2, and the 5 IAB nodes are IAB node 1 to IAB node 5. It should be understood that the thick line in Figure 2 indicates the access link, and the thin line indicates the backhaul link.
  • UE1 accesses IAB-node4 through a wireless access link
  • IAB-node4 is connected to IAB-node3 through a wireless backhaul link
  • IAB-node3 is connected to IAB-node1 through a wireless backhaul link
  • IAB-node1 is connected to IAB-donor through a wireless backhaul link.
  • IAB networking scenario shown in Figure 2 is only exemplary, and there are many other possibilities in the IAB network that supports multi-hop and multi-connection networking, which are not listed here one by one.
  • the IAB-node-DU (hereinafter simply referred to as IAB-DU) is logically connected to the IAB-donor CU (hereinafter simply referred to as CU) through the F1 interface.
  • Figure 3 is a schematic diagram of an IAB network architecture.
  • the F1 connection in Figure 3 is not a physical direct connection, but a logical connection.
  • the F1 connection between the IAB-DU and the CU is physically realized through the NR Uu interface between the IAB-node MT and the parent node DU of each hop, but since the IAB-DU can communicate with the CU in the end, it can be considered that the F1 interface exists logically.
  • the F1 interface can also be called the F1* interface, and the embodiment of the present application does not limit the name of the interface. And in this article, the interface is called the F1 interface as an example.
  • the IAB-donor CU is connected to the 5G core network (5G core network, 5GC/5GCN) through the NG interface. There is an Xn-C interface between the IAB-donor CU and the gNodeB.
  • the F1 interface can support user plane protocols (F1-U/F1*-U) and control plane protocols (F1-C/F1*-C).
  • the user plane protocols include one or more of the following protocol layers: general packet radio service (GPRS) tunneling protocol user plane (GTP-U), user datagram protocol (UDP), Internet protocol (IP), etc.
  • the control plane protocols include one or more of the following protocol layers: F1 application protocol (F1AP), stream control transport protocol (SCTP), IP, etc.
  • FIG. 4 is a schematic diagram of a control plane protocol architecture in an IAB network
  • FIG. 5 is a schematic diagram of a user plane protocol architecture in an IAB network.
  • a Uu interface is established between UE1 and IAB2-DU, and the peer protocol layers include the radio link control protocol (RLC) layer, the media access control layer (MAC) layer, and the physical layer (PHY) layer.
  • RLC radio link control protocol
  • MAC media access control layer
  • PHY physical layer
  • An F1-C interface is established between IAB2-DU and IAB donor CU 1, and the peer protocol layers include the F1AP layer and the SCTP layer.
  • IAB donor DU 1 and IAB donor CU 1 are connected by wire, and the peer protocol layers include the internet protocol (IP) layer, L2, and L1.
  • IP internet protocol
  • BL is established between IAB node 2 and IAB node 3, between IAB node 3 and IAB node 1, and between IAB node 1 and IAB donor DU 1, and the peer protocol layers include the backhaul adaptation protocol (BAP) layer, RLC layer, MAC layer, and PHY layer.
  • BAP backhaul adaptation protocol
  • RRC peer radio resource control
  • PDCP packet data convergence protocol
  • the DU connected to the IAB node realizes the functions of the gNB-DU of a single air interface (that is, the functions of establishing a peer RLC layer, MAC layer and PHY layer with the UE, and the functions of establishing a peer F1AP layer and SCTP layer with the CU).
  • the DU connected to the IAB node in the IAB network realizes the functions of the gNB-DU of a single air interface;
  • the IAB donor CU realizes the functions of the gNB-CU of a single air interface.
  • the RRC message is encapsulated in the F1AP message between the access IAB node and the IAB donor CU for transmission.
  • UE1 encapsulates the RRC message in the PDCP protocol data unit (PDU), and sends it to the IAB2-DU after being processed by the RLC layer, MAC layer, and PHY layer in sequence.
  • the IAB2-DU is processed by the PHY layer, MAC layer, and RLC layer in sequence to obtain the PDCP PDU
  • the PDCP PDU is encapsulated in the F1AP message, and is processed by the SCTP layer and IP layer in sequence to obtain the IP packet.
  • the IAB2-MT sends the IP packet to the IAB3-DU after being processed by the BAP layer, RLC layer, MAC layer, and PHY layer respectively.
  • the IAB3-DU is processed by the PHY layer, MAC layer, RLC layer, and BAP layer in sequence to obtain the IP packet, and then the IAB3-MT uses operations similar to those of the IAB2-MT to send the IP packet to the IAB1-DU.
  • IAB1-MT sends the IP packet to IAB donor DU 1.
  • IAB donor DU 1 parses the IP packet, it sends the IP packet to IAB donor CU 1.
  • IAB donor CU 1 processes the IP packet through the SCTP layer, F1AP layer, and PDCP layer in sequence to obtain the RRC message.
  • the downlink direction is similar and will not be described here.
  • a Uu interface is established between UE1 and IAB2-DU, and the equivalent protocol layers include the RLC layer, MAC layer, and PHY layer.
  • An F1-U interface is established between IAB2-DU and IAB donor CU 1, and the equivalent protocol layers include the GTP-U layer and the user datagram protocol (UDP) layer.
  • IAB donor DU 1 and IAB donor CU 1 are connected via a wired connection, and the equivalent protocol layers include the IP layer, L2, and L1.
  • IAB node 2 and IAB node 3 Between IAB node 2 and IAB node 3, between IAB node 3 and IAB node 1, and between IAB A BL is established between Node 1 and IAB donor DU 1, and the equivalent protocol layers include BAP layer, RLC layer, MAC layer and PHY layer.
  • an equivalent SDAP layer and PDCP layer are established between UE1 and IAB donor CU 1, and an equivalent IP layer is established between IAB2-DU and IAB donor DU 1.
  • the DU of the IAB access node implements some functions of the gNB-DU of the single air interface (i.e., the functions of establishing a peer RLC layer, MAC layer and PHY layer with the terminal, and the functions of establishing a peer GTP-U layer and UDP layer with the IAB donor CU 1). It can be understood that the DU of the IAB access node implements the functions of the gNB-DU of the single air interface; the IAB donor CU implements the functions of the gNB-CU of the single air interface.
  • PDCP packets are encapsulated and transmitted in the GTP-U tunnel between the access IAB node and the IAB donor CU.
  • the GTP-U tunnel is established on the F1-U interface.
  • FIG6 shows a schematic diagram of an IAB network architecture, including an IAB network of a standalone network (SA) and an IAB network of a non-standalone network (NSA).
  • An IAB node includes an MT part and a DU part.
  • FIG6 takes IAB node1 and IAB node2 as examples to illustrate.
  • An IAB donor can be further divided into a DU and a CU part.
  • a CU can also be divided into a CU-CP and a CU-UP part.
  • FIG6 takes IAB donor1 and IAB donor2 as examples to illustrate.
  • the DU part of each IAB node has an F1 interface with the IAB donor CU.
  • the F1 interface includes two parts: the control plane and the user plane.
  • the user plane part is maintained between the IAB-DU and the IAB donor CU-UP, while the control plane part is maintained between the IAB-DU and the IAB donor CU-CP.
  • the F1 interface between the IAB-DU and the IAB donor CU is not shown in Figure 6.
  • the UE is connected to the DU of the IAB node through the NR Uu interface, and the MT and DU in each IAB node are connected through the NR BH interface.
  • the IAB donor CU-CP is connected to the IAB donor CU-UP through the E1 interface.
  • the IAB node When the IAB node works in SA mode, the IAB node can be connected to one parent node or two parent nodes, where the two parent nodes can be controlled by the same IAB donor or by different IAB donors.
  • the DU part of the IAB node can establish an F1 interface with an IAB donor, and the IAB donor can be connected to the 5G core network (5G core, 5GC), that is, the dotted part in the figure.
  • 5G core 5G core network
  • the IAB-donor-CU-CP is connected to the control plane network element (such as access and mobility management function AMF) in the 5GC through the NG control plane interface (NG-C), and the IAB-donor-CU-UP is connected to the user plane network element (such as user plane function UPF) in the 5GC through the NG user plane interface (NG-U).
  • control plane network element such as access and mobility management function AMF
  • user plane network element such as user plane function UPF
  • the IAB-donor-CU-UP can be connected to the EPC (for example, connected to the serving gateway (SGW)) through the S1 user plane interface, there is an LTE Uu air interface connection between the MeNB and the MT of the IAB node, there is an X2/Xn-C interface between the MeNB and the IAB-donor-CU-CP, and the MeNB is connected to the EPC through the S1 interface (including the S1 interface user plane and the S1 interface control plane).
  • the IAB-donor-CU-UP is connected to the EPC through the S1 interface user plane (S1-U).
  • the MeNB in Figure 6 can also be replaced with a 5G base station gNB, and the dotted LTE-Uu interface in Figure 6 is correspondingly replaced by an NR-Uu interface.
  • the gNB can establish a user plane and/or control plane interface with the 5GC, and the gNB and IAB-donor provide dual connection services for the IAB node.
  • the gNB can act as the primary base station of the IAB node, or the secondary base station.
  • full migration includes three implementation methods: gradual top-down, gradual bottom-up, and full nested.
  • partial migration the MT of the IAB node is switched across CUs, but the DU of the IAB node still maintains an F1 connection with the source CU; while in full migration, the DU of the IAB node needs to establish an F1 connection with the target CU.
  • Rel-17 is mainly aimed at the migration of IAB nodes based on load balancing, so partial migration can be used. Only by switching the MT, the F1 interface changes the transmission path, but the anchor point of the F1 interface is not changed.
  • Rel-18 is mainly aimed at migration caused by IAB node movement.
  • IAB node moves over a large range, it is inappropriate to maintain F1 connection with the source CU, and the anchor point of the F1 connection also needs to be changed to the target CU. Therefore, full migration is a mandatory feature of Rel-18 mobile IAB. The following will briefly introduce the current status of the discussion on partial migration and full migration.
  • FIG. 7 is a schematic diagram of a partial migration.
  • IAB-node2 is a boundary node. Before IAB-node2 performs partial migration, there is an RRC connection between IAB-MT2 and CU1, and there is an F1 interface between IAB-DU2 and CU1. IAB-node2 communicates with IAB-donor through the source path (through IAB-node1 composed of IAB-MT1 and IAB-DU1), see the solid line with the arrow. During the partial migration of IAB-node2, IAB-MT2 undergoes cross-CU cell switching and establishes an RRC connection with CU2.
  • IAB-DU2 still maintains the F1 interface with CU1 and does not establish an F1 interface with CU2. Therefore, the communication path between CU1 and IAB-DU2 becomes cross-topology: See the dashed line with an arrow.
  • CU1 and CU2 are called F1-terminating CU and non-F1-terminating CU respectively. It should be noted that data does not pass through the CU2, CU1 and Donor-DU2 communicate directly through the IP network.
  • IAB TRANSPORT MANAGEMENT REQUEST/RESPONSE message refer to standard TS 38.423V17.2.0 Section 9.4.2, Section 9.4.3.
  • CU1 requests CU2 to help it establish cross-topology traffic transmission through the IAB TRANSPORT MANAGEMENT REQUEST message, which carries the IP address of the traffic and the quality of service (QoS) information; after CU2 establishes cross-topology traffic transmission, it returns the backhaul link (backhaul) information of the MT of the border node (the topology in the dotted box under CU2) to CU1 through the IAB TRANSPORT MANAGEMENT RESPONSE message.
  • backhaul backhaul link
  • CU1 Based on the backhaul information of the MT of the border node, CU1 configures the cross-topology BAP rules for the border node through F1AP.
  • IAB TRANSPORT MANAGEMENT REQUEST/RESPONSE is an XN message associated with the UE, and is associated to the MT of the border node. Therefore, both messages need to carry the XNAP ID of the MT of the border node under CU1 and the XNAP ID under CU2 to identify the MT.
  • FIG8 is a schematic diagram of a full migration.
  • IAB-node3 is a boundary node.
  • the F1 interface between IAB-DU3 and CU1 needs to be migrated to CU2. Since the protocol does not support the simultaneous existence of F1 interfaces between a DU and two CUs, in the existing implementation scheme, IAB-DU3 is expanded into two logical DUs, namely IAB-DU3a (abbreviated as DU3a) and IAB-DU3b (i.e., the new logical DU).
  • IAB-DU3a abbreviated as DU3a
  • IAB-DU3b i.e., the new logical DU
  • IAB-DU3a always maintains the F1 interface with CU1, while IAB-DU3b (abbreviated as DU3b) is used to establish a new F1 interface with CU2.
  • DU3a and DU3b can be regarded as two DUs, each with an F1 interface.
  • the UE needs to perform a handover from the cell under IAB-DU3a to the cell under IAB-DU3b.
  • IAB-MT3 (MT3 for short) is switched to establish cross-topology F1-C and F1-U between DU3a and CU1.
  • CU2 helps to establish cross-topology F1-C and F1-U between DU3a and CU1, it also establishes F1-C and F1-U between DU3b and CU2.
  • the UE is switched to DU3b.
  • the UE can communicate with CU2 directly on the target path.
  • the target path is
  • the cross-topology F1-C and F1-U between DU3b and CU2 are established, so that the UE can switch to DU3b, and the control plane and user plane data transmission between DU3b and CU2 through topology 1 are established.
  • a switching command is sent to MT3 or the switching command of MT3 is effective, and then F1-C/U is established on the target path, so that the UE traffic can be migrated to the target path.
  • Topology 1 refers to To establish control plane and user plane data transmission between DU3b and CU2 through topology 1, it is necessary to establish backhaul link resources (BH RLC CH) on DU3b and donor-DU1, as well as on the intermediate hop nodes between the two (if any), and configure the BAP layer so that these related nodes have corresponding resources for transmitting control plane and user plane data, and the BAP layer of each related node knows how to map data packets to resources.
  • backhaul link resources BH RLC CH
  • the full nested situation is similar to the gradual bottom-up.
  • a cross-topology F1-C between DU3b and CU2 (only cross-topology F1-C is established to allow CU2 to switch the UE to DU3b when making a switching decision, but cross-topology F1-U is not established, and cross-topology data transmission is not performed)
  • the UE is allowed to switch to DU3b.
  • a switching command is immediately sent to MT3 or the switching command of MT3 is effective, and then F1-C/U is directly established on the target path to allow the UE traffic to be migrated to the target path.
  • mIAB mobile IAB
  • the mIAB-DU always maintains an F1 connection with CU1.
  • the CU i.e., CU1 of the F1 anchor point of the mAB-DU decides whether DU migration is required.
  • Figure 10 is an example of a scenario for migrating DUs in a continuous partial migration provided in an embodiment of the present application. Figure 10 shows the situation where CU1 decides to migrate the DU when the mAB-MT migrates from the topology under CU2 to the topology under CU3.
  • the mAB-node needs to generate a new logical DU (mIAB-DU2), establish an F1 interface with CU3, and then switch the UE from the cell under mAB-DU1 to the cell under mAB-DU2.
  • mIAB-DU2 new logical DU
  • the mAB-MT is directly connected to the donor-DU, but this is only for illustration.
  • the mAB-MT can also be connected to other fixed IAB-DUs and reach the donor-DU through multiple hops. This is not limited in the embodiments of the present application.
  • Cell ID It can be indicated by PCI or cell global identifier (CGI), which is an important parameter of the cell. Each cell will correspond to a cell ID, which is used to distinguish different cells. Downlink signal synchronization, signal demodulation and signal switching can be performed based on the cell ID.
  • the cell ID is PCI as an example for specific explanation.
  • 5G includes a total of 1008 PCIs, of which 10008 PCIs are divided into There are 336 groups, each of which includes 3 PCIs, as shown below:
  • Adjacent cells cannot be assigned the same PCI. If adjacent cells are assigned the same PCI, the UE will not be able to detect the adjacent cells in the overlapping coverage area, affecting handover and residence.
  • the frequencies of the serving cells are the same, and the adjacent cells cannot be assigned the same PCI. If the same PCI is assigned, when the UE reports the neighboring cell PCI to the base station where the source cell is located, the source base station cannot determine the target switching cell based on the PCI.
  • PCI mode30 for PUCCH demodulation reference signal (DMRS) and channel sounding reference signal (SRS), the algorithm uses PCI mode30 as the high-level configuration ID to select the sequence group. Therefore, the PCI mode30 of adjacent cells should be staggered as much as possible to ensure the correct demodulation of uplink signals.
  • DMRS PUCCH demodulation reference signal
  • SRS channel sounding reference signal
  • the cell ID can be configured through operation administration and maintenance (OAM), or after the IAB node establishes the F1 interface with the CU, the configured cell ID is reported to the CU, or the CU reconfigures the cell ID based on the cell ID and other information reported by the IAB node. The details are not explained here. In short, the cell ID is pre-configured.
  • OAM operation administration and maintenance
  • the IAB node is fixed at a certain location, that is, statically deployed.
  • the IAB node can be installed on the vehicle and move with the vehicle, as shown in Figure 11.
  • Figure 11 shows a schematic diagram of a mobile IAB node.
  • vehicle VMR1 receives services under gNB1
  • vehicle VMR1 is equipped with IAB node 1
  • the cell identifier configured under IAB node 1 is PCI#1.
  • VMR1 moves to gNB2 to receive services.
  • gNB2 also provides services for vehicle VMR2.
  • the IAB node 2 carried by VMR2 is also configured with cell identifier PCI#1, then the two cell identifiers are the same, and a cell collision will occur, affecting the communication quality. It can be seen from this that the existing static PCI configuration method is no longer applicable. For the R18 mobile IAB scenario, if a static PCI is used, during the movement of the IAB cell, it may conflict with the PCI of the neighboring cell. A new cell identifier configuration method is urgently needed to avoid signal collisions.
  • the existing conference conclusion only provides that in continuous partial migration, the first CU (i.e., the source CU of the boundary node) decides whether to migrate the DU, but on what basis does the first CU decide whether to migrate the DU?
  • the conference conclusion did not provide a specific solution.
  • the conference conclusion also did not provide a solution on how to migrate the DU in continuous partial migration, and when the first CU decides whether to migrate the DU.
  • the DU migration solution in the IAB network provided in the embodiment of the present application can solve the above three problems and is a complete solution for implementing DU migration in continuous partial migration.
  • FIG12 is an interactive flow chart of a DU migration method in an IAB network provided by an embodiment of the present application.
  • the method in FIG12 is applicable to the scenario of migrating DUs in continuous partial migration.
  • mIAB-MT represents the MT of the IAB node
  • mIAB-DU1 represents the IAB node
  • DU mIAB-DU2
  • the meanings of the network elements in other subsequent figures can refer to the meanings in Figure 12.
  • the method includes:
  • the second CU sends a first message to the first CU.
  • the first CU receives the first message from the second CU.
  • the first message includes the ID of the MT for identifying the IAB node in the third CU and the ID of the third CU.
  • the ID of the MT for identifying the IAB node in the third CU may be the XNAP ID of the IAB node under the third CU.
  • the first message includes the IP address of the third CU or the IP address of the host DU managed by the third CU, and the ID of the MT for identifying the IAB node in the third CU.
  • the first message may be an XN message.
  • the first message may be called a DU migration query message.
  • the trigger condition for the second CU to send the first message to the first CU is that the second CU receives from the third CU: 1) HANDOVER REQUEST ACKNOWLEDGE about the MT (indicating that the MT is about to switch), or 2) UE CONTEXT RELEASE about the MT (indicating that the MT has completed the switch from the second CU to the third CU), or 3) RETRIEVE UE CONTEXT REQUEST about the MT (MT has completed the recovery of the radio link failure).
  • the MT has completed the recovery of the radio link failure.
  • the radio link failure between the MT and the second CU can be a topology under the third CU.
  • HANDOVER REQUEST ACKNOWLEDGE can refer to the standard TS 38.423 V17.2.0 Section 9.1.1.2.
  • UE CONTEXT RELEASE can refer to the standard TS 38.423 V17.2.0 Section 9.1.1.5.
  • RETRIEVE UE CONTEXT REQUEST can refer to the standard TS 38.423 V17.2.0 Section 9.1.1.8.
  • the trigger condition for the second CU to send the first message to the first CU is receiving the eighth message from the third CU.
  • the eighth message is used to indicate that the MT of the IAB node will switch to the topology under the third CU, the MT has switched to the topology under the third CU, or the MT has accessed the topology under the third CU after a radio link failure occurs between the MT and the second CU.
  • the eighth message is HANDOVER REQUEST ACKNOWLEDGE, UE CONTEXT RELEASE, or RETRIEVE UE CONTEXT REQUEST about the MT.
  • the topology under the third CU is the topology to which MT changes from the topology of the second CU. For example, MT switches from the topology under the first CU to the topology under the second CU, and then switches from the topology under the second CU to the topology under the second CU.
  • the topology under the third CU is the topology to which MT changes from the topology of the second CU.
  • MT switches from the topology under the first CU to the topology under the second CU, RLF occurs between MT and the second CU, and then the RLF Recovery process is executed to re-access the topology of the third CU.
  • the topology under the third CU is the topology to which MT changes from the topology of the second CU.
  • the third CU sends a first message to the first CU.
  • the first CU receives the first message from the third CU.
  • the first message in step 1201' may be the same as the first message in step 1201.
  • the first message may be an XN message.
  • the first message may be called a DU migration query message.
  • the triggering condition for the third CU to send the first message to the first CU is: 1) the third CU sends a HANDOVER REQUEST ACKNOWLEDGE about the MT to the second CU, or 2) the third CU sends a UE CONTEXT RELEASE to the second CU; or 3) the third CU receives a RETRIEVE UE CONTEXT RESPONSE about the MT from the second CU.
  • the triggering condition for the third CU to send the first message to the first CU is: sending the ninth message to the second CU or receiving the tenth message from the second CU.
  • the ninth message is used to indicate that the MT will switch to the topology under the third CU or that the MT has been transformed to the topology under the third CU.
  • the ninth message is HANDOVER REQUEST ACKNOWLEDGE, UE CONTEXT RELEASE, or RETRIEVE UE CONTEXT REQUEST about the MT.
  • the tenth message is used to indicate that the MT has changed to the topology under the third CU.
  • the tenth message is RETRIEVE UE CONTEXT RESPONSE.
  • the DU of the IAB node sends a first message to the first CU.
  • the first CU receives the first message from the DU of the IAB node.
  • the first message in step 1201" may be an F1 message, such as a gNB-DU Configuration update message carrying the ID of the MT for identifying the IAB node in the third CU and the ID of the third CU. That is, the existing gNB-DU Configuration update message carrying the ID of the MT for identifying the IAB node in the third CU and the ID of the third CU may be reused as the first message.
  • the triggering condition for the DU of the IAB node to send the first message to the first CU may be: the MT of the IAB node switches from the topology of the second CU to the topology of the third CU.
  • Step 1201, step 1201', and step 1201" are three possible implementations.
  • the first CU may receive a first message from a second CU, may receive a first message from a third CU, or may receive a first message from a DU of an IAB node. It should be understood that the method flow in FIG. 12 includes any one of step 1201, step 1201', or step 1201", which is not limited in the embodiment of the present application.
  • the first message may be regarded as a condition that triggers the first CU to decide whether to migrate the DU of the IAB node.
  • the first message is used Indicating that the MT will switch from the topology under the second CU to the topology under the third CU, the MT has completed the switch from the topology under the second CU to the topology under the third CU, or the radio link failure between the MT and the second CU and access to the topology under the third CU.
  • the first message includes the ID of the third CU and the XN AP ID of the IAB node under the third CU.
  • the first message includes the IP address of the third CU and the XN AP ID of the IAB node under the third CU.
  • the first message includes the IP address of the host DU managed by the third CU and the XN AP ID of the IAB node under the third CU.
  • the first message includes the ID of the third CU, the IP address of the third CU and the XN AP ID of the IAB node under the third CU.
  • the first message includes the ID of the third CU, the IP address of the host DU managed by the third CU, and the XN AP ID of the IAB node under the third CU.
  • the first message includes the ID of the third CU, the IP address of the host DU managed by the third CU, and the XN AP ID of the IAB node under the third CU.
  • the first message includes the IP address of the third CU, the IP address of the host DU managed by the third CU, and the XN AP ID of the IAB node under the third CU.
  • the first message includes the ID of the third CU, the IP address of the third CU, the IP address of the host DU managed by the third CU, and the XN AP ID of the IAB node under the third CU.
  • the first CU When the first CU receives the first message, it can be learned that the MT will switch from the topology under the second CU to the topology under the third CU, the MT has completed the switch from the topology under the second CU to the topology under the third CU, or the wireless link between the MT and the second CU fails and accesses the topology under the third CU.
  • the first CU can be triggered in time to decide whether to migrate the DU of the IAB node.
  • the first CU determines whether to migrate the DU of the IAB node according to the first message.
  • Determining whether to migrate the DU of the IAB node can be written as: Determine whether to migrate the DU of the IAB node.
  • a possible implementation of step 1202 is as follows: Based on the first message, determine whether the first CU can reach the third CU or the host DU managed by the third CU without going through the core network. In other words, based on the first message, determine whether the first CU can reach the third CU or the host DU managed by the third CU through the IP network that does not include the core network. The embodiment of the present application does not limit the method of determining whether the first CU can reach the third CU or the host DU managed by the third CU without going through the core network based on the first message.
  • the network manager configures a table of network nodes that can be reached directly to the first CU without going through the core network, and the CU queries the table to determine whether it can reach the third CU or the host DU managed by the third CU without going through the core network.
  • step 1202 determine whether the first CU can establish an XN interface with the third CU according to the first message.
  • the embodiment of the present application does not limit the manner of determining whether the first CU can establish an XN interface with the third CU according to the first message. For example, the first CU attempts to initiate an XN interface establishment request to the third CU. If the first CU obtains a response allowing the XN interface to be established, the first CU believes that the XN interface can be established with the third CU, otherwise the first CU believes that the XN interface is not allowed to be established with the third CU.
  • step 1202 determines whether the first CU can reach the third CU or the host DU managed by the third CU by means of IP routing. In other words, according to the first message, determine whether the first CU and the third CU or the host DU managed by the third CU are IP reachable (IP routable).
  • IP routable IP reachable
  • the embodiment of the present application does not limit the method of determining whether the first CU can reach the third CU or the host DU managed by the third CU by means of IP routing according to the first message. For example, the first CU queries the IP routing table.
  • the IP is considered to be reachable, otherwise the IP is considered to be unreachable.
  • the first CU sends a second message to the DU of the IAB node.
  • the DU of the IAB node receives the second message from the first CU.
  • the second message is used to instruct the DU of the IAB node to establish an F1 interface with the third CU.
  • the second message is used to instruct the IAB node or the DU of the IAB node to generate a new logical DU and establish an F1 interface with the third CU through the new logical DU, that is, to establish an F1 interface between the new logical DU and the third CU.
  • the second message can be called a DU migration command.
  • the DU of the IAB node establishes an F1 interface with the third CU according to the second message.
  • the second message may include the ID of the third CU.
  • a possible implementation of step 1204 is as follows: the DU of the IAB node generates a new logical DU according to the second message, and establishes an F1 interface with the third CU through the new logical DU. For example, after the DU of the IAB node generates a new logical DU, the new logical DU initiates an F1 setup request message (F1SETUP REQUEST) to the third CU according to the ID of the third CU carried in the second message.
  • F1 setup request message F1SETUP REQUEST
  • Step 1203 and step 1204 are optional. Step 1203 and step 1204 can be replaced by step 1203' below, or by step 1203" and step 1204". It should be understood that the method flow in Figure 12 includes any one of steps 1203 to 1204, step 1203', or steps 1203" to 1204", and the embodiments of the present application are not limited thereto.
  • the first CU initiates the IAB transmission migration management process in the partial migration to the third CU.
  • Step 1203' is optional.
  • the IAB TRANSPORT MIGRATION MANAGEMENT process is used for cross-topology migration of traffic.
  • the IAB TRANSPORT MIGRATION MANAGEMENT process can be found in standard TS 38.423 V17.2.0 Section 9.4.2, Section 9.4.3.
  • step 1203' is to implement partial migration.
  • the IAB transfer migration management process in the partial migration initiated by the first CU to the third CU is the IAB transfer migration management process in the standard.
  • the IAB transport migration management process in the partial migration initiated to the third CU transfers the key information elements in the IAB TRANSPORT MIGRATION MANAGEMENT REQUEST/RESPONSE message on the XN interface in the new message on the NG interface (i.e., the sixth message and the seventh message below), and the implementation method is described in detail below.
  • the first CU sends a sixth message to the access and mobility management function network element (such as AMF), and the sixth message includes the IP address of the traffic of the IAB node under the third CU and the QoS information of the traffic of the IAB node; the first CU receives the seventh message from the access and mobility management function network element, and the seventh message includes the backhaul link (backhaul) information under the third CU, and the DSCP (Flow Label) information of the traffic of the IAB node.
  • backhaul link (backhaul) information refer to the standard TS 38.423 V17.2.0 Section 9.2.2.83.
  • the first CU sends a third message to the second CU.
  • the third message is used to request the second CU to configure resources for the F1 interface between the new logical DU generated by the DU of the IAB node and the third CU in its topology.
  • the third message can also be used to request the second CU not to migrate the MT of the IAB node temporarily.
  • the third message is used to request the second CU not to migrate the MT of the IAB node temporarily, and to configure resources for the F1 interface between the new logical DU generated by the DU of the IAB node and the third CU, where the F1 interface is a cross-topology F1 interface that passes through the topology (donor-DU2) under the second CU and terminates on the third CU.
  • the third message carries the XNAP ID of the MT in the first CU.
  • the third message also carries the gNB ID of the third CU.
  • the gNB ID of the third CU is optional because the first CU may not necessarily need to know which CU this F1 interface is established for, but only needs to configure resources serving this F1 interface in its topology.
  • the third message can be an XN message.
  • the third message can be called Other node F1 setup request, indicating that this F1 interface is not established on the second CU, but is established to help other nodes. It should be noted that the names of the messages in the embodiments of the present application are not limited.
  • the second CU configures resources for the F1 interface between the new logical DU generated for the DU of the IAB node in its topology and the third CU according to the third message.
  • Step 1203" and step 1204" are optional.
  • the first CU after the first CU receives the first message, it determines whether to migrate the DU of the IAB node according to the first message.
  • the first CU receiving the first message is a trigger condition for the first CU to decide whether to migrate the DU of the IAB node, and thus the trigger condition for the first CU to decide whether to migrate the DU of the IAB node is given.
  • the first message it is determined whether to migrate the DU of the IAB node. It can be seen that the embodiment of the present application also provides the basis for the first CU to decide whether to migrate the DU of the IAB node.
  • sending a second message to the IAB node is the DU migration method provided by the embodiment of the present application.
  • the scheme in the embodiment of the present application can support DU migration triggered by topology changes in the MT, which solves the problem of migrating DUs during continuous partial migration that is not supported by the prior art.
  • FIG13 is an interactive flow chart of another DU migration method in an IAB network provided by an embodiment of the present application.
  • the method flow in FIG13 is a possible implementation of the method described in FIG12. As shown in FIG13, the method includes:
  • the second CU sends message 1 to the third CU.
  • the third CU receives message 1 from the second CU.
  • Message 1 is used to request to switch the MT to the topology under the third CU.
  • Message 1 can be an MT HO request.
  • Message 1 may include the XNAP ID of the MT under the first CU (needed to be carried for the case of executing step 1305', the specific reason will be given in step 1305').
  • the second CU knows the XNAP ID of the MT under the first CU.
  • the Handover Preparation process includes the interaction of the Handover Request message and the Handover Request Acknowledge message.
  • the third CU sends message 2 to the second CU.
  • the second CU receives message 2 from the third CU.
  • Message 2 may be a HANDOVER REQUEST ACKNOWLEDGE about the MT.
  • Message 2 may be regarded as a message that the third CU replies to the second CU in response to message 1.
  • Message 2 may include the XNAP ID of the MT under the second CU, the XNAP ID of the MT under the third CU, and the IP address of the MT under the third CU (MT’s IP address under the third CU).
  • message 2 carries the IP address of the host DU managed by the third CU or the third CU.
  • the IP address of the host DU managed by the third CU may be obtained by the third CU through the donor-DU to which the target cell of the MT belongs (theoretically, multiple donor-DUs may be attached to one donor-CU).
  • the purpose of carrying the IP address here is to be used by the subsequent first CU to determine whether there is an IP path between the host DU managed by the third CU or the third CU.
  • the reason why it is optional and non-mandatory is that the first CU can also be implemented internally, for example, judging whether there is an IP path between the host DU managed by the third CU or the third CU according to the gNB ID of the third CU.
  • the MT of the IAB node performs an MT switching operation with the third CU.
  • Step 1303 can be understood as a subsequent step of the MT of the IAB node and the third CU performing MT switching. Step 1303 can be implemented by existing technologies and will not be described in detail here.
  • the third CU sends message 3 to the second CU.
  • Message 3 is used to instruct the second CU to release the UE context of the MT with respect to the IAB node.
  • message 3 is UE CONTEXT RELEASE.
  • the third CU sends message 4 to the second CU.
  • the second CU receives message 4 from the third CU.
  • Message 4 is used to request the UE context of the MT regarding the IAB node from the second CU.
  • Message 4 includes the XNAP ID of the MT under the second CU and the XNAP ID of the MT under the third CU.
  • message 4 includes the IP address of the third CU or the IP address of the host DU managed by the third CU.
  • message 4 is RETRIEVE UE CONTEXT REQUEST.
  • RLF occurs between the MT and the second CU, and then the RLF Recovery process is executed to re-access the topology of the third CU, and then the third CU sends message 4 to the second CU.
  • the second CU sends message 5 to the third CU.
  • the third CU receives message 5 from the second CU.
  • message 5 carries the XNAP ID of the MT under the first CU (necessary for the case of executing step 1305' below, the specific reason will be given in step 1305').
  • message 5 is RETRIEVE UE CONTEXT RESPONSE.
  • Steps 1301 to 1304 and steps 1301' to 1302' are two different implementations. It should be understood that the method flow in Figure 13 includes steps 1301 to 1304, or includes 1301' to 1302', and the embodiment of the present application is not limited thereto.
  • the second CU sends a first message to the first CU.
  • the first message includes the ID of the third CU, the XNAP ID of the MT under the first CU, the XNAP ID of the MT under the second CU, and the XNAP ID of the MT under the third CU.
  • the first message includes the IP address of the third CU or the IP address of the host DU managed by the third CU.
  • the triggering condition for the second CU to send the first message to the first CU may be any of the following: the second CU receives message 2 from the third CU; the second CU receives message 3 from the third CU; the second CU receives message 4 from the third CU.
  • the method flow in Figure 13 includes steps 1301 to 1304, and the second CU executes step 1305 after receiving message 2 from the third CU.
  • the order in which the second CU executes steps 1303 and 1305 is not limited.
  • the method flow in Figure 13 includes steps 1301 to 1304, and the second CU executes step 1305 after receiving message 3 from the third CU.
  • the method flow in Figure 13 includes steps 1301' to 1302'. After receiving message 4 from the third CU, the second CU executes step 1305.
  • the order in which the second CU executes step 1302' and step 1305 is not limited.
  • the third CU sends a first message to the first CU.
  • the first message in step 1305' may be the same as the first message in step 1305, and will not be repeated here.
  • the triggering condition for the third CU to send the first message to the first CU may be any of the following: the third CU sends message 2 to the second CU; the third CU sends message 3 to the second CU; the third CU sends message 4 to the second CU; the third CU receives message 1 from the second CU; the third CU receives message 5 from the second CU.
  • the method flow in Figure 13 includes steps 1301 to 1304, and after the third CU sends message 2 to the second CU, step 1305' is executed, and the order in which the third CU executes step 1305' and step 1303 is not limited.
  • the method flow in Figure 13 includes steps 1301 to 1304, and after the third CU sends message 3 to the second CU, step 1305' is executed.
  • the method flow in Figure 13 includes steps 1301 to 1304, and after the third CU receives message 1 from the second CU, step 1305' is executed, and the order in which the third CU executes step 1305' and step 1302 is not limited.
  • the method flow in Figure 13 includes 1301' to step 1302', and after the third CU sends message 4 to the second CU, step 1305' is executed.
  • the method flow in Figure 13 includes 1301' to step 1302', and after the third CU receives message 5 sent from the second CU, step 1305' is executed.
  • the first message is an XN message between the third CU and the first CU
  • this XN message needs to carry the XNAP ID of the MT under the first CU and the third CU.
  • the XNAP ID of the MT under the first CU is carried by message 1 of step 1301 or message 5 of step 1302', so this is necessary for step 1302'.
  • step 1305 and step 1305' are two possible implementations of the first CU receiving the first message.
  • the method flow in Figure 13 includes step 1305 or step 1305'.
  • the above examples illustrate the combination of steps 1301 to 1304 with step 1305, and the combination of steps 1301' to 1302' with step 1305.
  • the above also illustrates the combination of steps 1301 to 1304 with step 1305', and the combination of steps 1301' to 1302' with step 1305'.
  • the first CU determines whether to migrate the DU of the IAB node according to the first message.
  • Step 1306 may refer to step 1202 .
  • the first CU sends a second message to the DU of the IAB node.
  • Step 1307 may refer to step 1203 .
  • the DU of the IAB node establishes an F1 interface with the third CU according to the second message.
  • Step 1308 may refer to step 1204. Step 1307 and step 1308 are optional. Step 1307 and step 1308 may be replaced by step 1307' below.
  • the first CU when it is determined that the IAB node DU migration is not to be performed, the first CU initiates the IAB transmission in the partial migration to the third CU Migration management process.
  • the solution in the embodiment of the present application can support DU migration triggered by topology changes in MT, solving the problem of migrating DU during continuous partial migration that is not supported by the prior art.
  • the first CU is notified through the first message only after the MT has completed the handover or RLF recovery. This is a bit late, because at this time the MT has already reached the third CU topology. If the first CU finds that the host DU managed by the third CU or the third CU IP is unreachable at this time, the F1 interface message between the first CU and the DU of the IAB node can no longer be directly transmitted through the host DU managed by the third CU, and may only be able to bypass the core network through the NG interface, which is not what we want to see.
  • the first CU cannot directly send a message to the DU of the IAB node through the cross-topology F1 interface, and then send a switching command to the UE (the switching command sent by the CU to the UE is an F1-C message encapsulated between the CU and the DU of the IAB node and sent to the DU of the IAB node, and then the DU of the IAB node unpacks the F1-C message and sends it to the UE), but it has to go through the core network (F1-C over NGAP) to reach the DU of the IAB node, thereby sending a switching command to the UE.
  • the switching command sent by the CU to the UE is an F1-C message encapsulated between the CU and the DU of the IAB node and sent to the DU of the IAB node, and then the DU of the IAB node unpacks the F1-C message and sends it to the UE
  • an embodiment of the present application provides a DU migration solution that can avoid NG interaction, refer to the method flow in Figure 14.
  • FIG14 is an interactive flow chart of another DU migration method in an IAB network provided by an embodiment of the present application.
  • the method flow in FIG14 is a possible implementation of the method described in FIG12.
  • the first CU instructs the second DU to temporarily suspend switching the MU, and configures resources for the F1 interface between the DU of the IAB node and the third CU in its topology; NG interaction can be avoided, thereby speeding up the migration of the DU.
  • the method includes:
  • the third CU sends message 2 to the second CU.
  • Step 1401 may refer to step 1302. For example, before the third CU sends the message 2 to the second CU, it receives the message 1 from the second CU; in response to the message 1, the third CU sends the message 2 to the second CU.
  • the second CU sends a first message to the first CU.
  • Step 1402 may refer to step 1305 .
  • the third CU sends a first message to the first CU.
  • Step 1402' may refer to step 1305'. It should be understood that step 1402 and step 1402' are two possible implementations of the first CU receiving the first message.
  • the method flow in FIG. 14 includes step 1402 or step 1402'.
  • the first CU determines whether to migrate the DU of the IAB node according to the first message.
  • Step 1403 may refer to step 1202. After the first CU determines not to migrate the DU of the IAB node according to the first message, the first CU may initiate the IAB transmission migration management process in partial migration to the third CU, see step 1203'.
  • the first CU sends a third message to the second CU.
  • Step 1404 may refer to step 1203.
  • the second CU configures resources for an F1 interface between a new logical DU generated for the DU of the IAB node in its topology and the third CU according to the third message.
  • step 1405 configure resources serving the cross-topology F1-C on a node in the second CU topology (such as donor-DU2), and inform mIAB-MT of the default BAP configuration for transmitting F1-C messages through an RRC message.
  • the IAB node generates a new logical DU, and establishes an F1 interface between the new logical DU and the third CU via the second CU.
  • mAB-MT opens a new logical DU on the IAB node, namely, DU2 of the IAB node, and interacts with the third CU via the resources configured in step 1405 via the F1SETUP REQUEST/RESPONSE message.
  • DU2 of the IAB node the F1 interface between DU2 of the IAB node and the third CU through the second CU topology is shown in FIG15 below.
  • FIG15 is an example of a continuous partial migration provided in an embodiment of the present application.
  • CU1 is the first CU
  • CU2 is the second CU
  • CU3 is the third CU
  • Donor-DU1 is the host DU managed by the first CU
  • Donor-DU2 is the host DU managed by the second CU
  • Donor-DU3 is the host DU managed by the third CU
  • mAB-DU1 represents the DU of the IAB node
  • mAB-DU2 represents the new logical DU
  • the arrow indicated by 1501 represents the F1 interface between mAB-DU2 and the third CU through the second CU topology.
  • the DU of the IAB node sends a fourth message to the first CU.
  • the first CU receives a fourth message from the DU of the IAB node.
  • the fourth message is used to indicate that the F1 interface between the DU of the IAB node and the third CU has been established.
  • the fourth message includes the gNB-DUID of the DU of the IAB node and the gNBID of the third CU.
  • the third CU sends a fourth message to the first CU.
  • the first CU receives the fourth message from the third CU.
  • step 1407 and step 1407' are two possible implementations of the first CU receiving the fourth message.
  • the method flow in FIG14 includes step 1407 or step 1407'.
  • the first CU initiates the UE HO Preparation process to the third CU.
  • the first CU should have received the measurement report of the cell under DU2 containing the IAB node of the UE.
  • the first CU initiates the UE HO Preparation process to the third CU.
  • the first CU may not select the target cell based on the UE's measurement report, but obtain the UE target cell through other means, such as: the target CU (third CU) switched by the UE or the IAB node directly informs the first CU of the UE's target cell. If there is no IP path between the first CU and the third CU, the HO Preparation process can be interacted through NG.
  • the first CU sends a first switching command to the terminal device.
  • the first switching command is used to instruct the terminal device to switch to the target cell under the DU of the IAB node.
  • the first CU sends a fifth message to the second CU.
  • the fifth message is used to indicate that the first CU has sent the first handover command. For example, after the first CU sends the first handover command to the terminal device, it sends the fifth message to the second CU.
  • the fifth message informs the second CU that the first CU has sent the handover command (HO Command) to all terminal devices.
  • the second CU sends a second switching command to the MT.
  • the second switching command is used for the MT of the IAB node to switch to the topology under the third CU.
  • Figure 16 is an example of the state after the MT switching in an IAB network provided in an embodiment of the present application is completed.
  • CU1 is the first CU
  • CU2 is the second CU
  • CU3 is the third CU
  • Donor-DU1 is the host DU managed by the first CU
  • Donor-DU2 is the host DU managed by the second CU
  • Donor-DU3 is the host DU managed by the third CU
  • mIAB-DU1 represents the DU of the IAB node
  • mIAB-DU2 represents the new logical DU.
  • Figure 16 shows the state of the MT of the IAB node (i.e., mIAB-MT) switching to the topology under the third CU.
  • the line with an arrow represents the F1 interface between mIAB-DU2 and the third CU. At this time, just close mIAB-DU1.
  • the embodiment of the present application is similar to the full nested process in the full migration introduced in the background technology, and can be understood as an enhanced version of full nested application in 3 CUs, all for better switching of UE.
  • MT switching Before MT switching, first activate the new logical DU and establish a cross-topology F1 interface, and then immediately send a switching command to MT after sending the switching command to UE.
  • steps 1403 and 1410 are required in the scenario of 3 CUs.
  • the target CUs for MT and DU migration are both the third CU, while the source CU of MT is the second CU, and the source CU of DU is the first CU.
  • step 1403 the first CU needs to inform the second CU not to switch MT temporarily and establish a cross-topology F1 interface.
  • step 1310 the first CU also needs to inform the second CU that the UE's HO Command has been sent and the MT can be switched. If the first CU and the second CU in the three-CU scenario are the same CU, then it is actually a full nested of two CUs, and step 1403 and step 1410 are not required.
  • the first CU instructs the second DU to postpone switching the MU and configures resources for the F1 interface between the DU of the IAB node and the third CU within its topology; NG interaction can be avoided, thereby speeding up the migration of the DU.
  • FIG. 17 is an interactive flow chart of another DU migration method in an IAB network provided in an embodiment of the present application.
  • the method flow in FIG. 17 is a possible implementation of the method described in FIG. 12. As shown in FIG. 17, the method includes:
  • the second CU sends message 1 to the third CU.
  • Step 1701 can refer to step 1301.
  • Message 1 can be an MT HO REQUEST message about mAB-MT sent by the second CU to the third CU, and the MT HO REQUEST carries the XNAP ID of the mAB-MT under the second CU.
  • the MT HO REQUEST also carries the XNAP ID of the mAB-MT under the first CU.
  • step 1707 if the DU migration method is not that the first CU directly sends the first message to the DU of the IAB node, but requires the first CU and the third CU to interact with a message similar to DU migration request (not expanded in the embodiment of the present application, and will be introduced later), and if this DU migration request only carries the XNAP ID of the mAB-MT under the first CU, then the third CU needs to understand that the MT associated with this XN message about DU migration is the MT that initiates the switch in the first step (i.e., step 1701).
  • Step 1701 is similar to step 1301, except that the condition of whether to carry the XNAPID of the mAB-MT under the first CU is different from that in step 1301.
  • the third CU sends message 2 to the second CU.
  • Step 1702 may refer to step 1302 .
  • the second CU sends a switching command to the MT of the IAB node.
  • the handover command is used for the MT of the IAB node to perform the handover process, that is, to switch from the topology under the second CU to the topology under the third CU.
  • the handover command carries the XNAP ID of the MT of the IAB node under the third CU, and the XNAP ID of the MT under the third CU is used by the IAB node to further inform the first CU of this information. If the HANDOVER REQUEST ACKNOWLEDGE about the MT in step 1702 carries the host DU managed by the third CU or the IP address of the third CU, it can also be carried in the handover command. Optionally, the gNB ID of the third CU is carried in the handover command.
  • the MT of the IAB node can also obtain the gNB ID of the third CU by listening to the neighboring SIB1 message. It should be noted that the XNAP ID of the MT under the third CU, the IP address of the host DU or the third CU managed by the third CU, and the gNB ID of the third CU can also be carried in other identical or different RRC messages and sent by the second CU to the MT of the IAB node.
  • the MT of the IAB node executes a handover process according to the handover command.
  • the DU of the IAB node sends a first message to the first CU.
  • the first message is the F1 message.
  • Step 1705 can refer to step 1201".
  • the first CU determines whether to migrate the DU of the IAB node according to the first message.
  • Step 1706 may refer to step 1202 .
  • the first CU sends a second message to the DU of the IAB node.
  • Step 1707 may refer to step 1203 .
  • the DU of the IAB node establishes an F1 interface with the third CU according to the second message.
  • Step 1708 may refer to step 1204 .
  • the first CU initiates the IAB transmission migration management process in the partial migration to the third CU.
  • Step 1707' can refer to step 1203".
  • the method flow in Figure 17 includes steps 1707 to 1708 or step 1707'.
  • the DU of the IAB node sends a first message to the first CU to inform the first CU that the MT has completed the switch, so as to trigger the first CU to decide whether to migrate the DU.
  • the first CU determines whether to migrate the DU based on whether the IP between it and the host DU managed by the third CU or the third CU is reachable. If it decides to migrate the DU, the first CU sends a second message to the DU of the IAB node; this solves the problem of migrating the DU during the continuous partial migration process that is not supported by the prior art.
  • Figure 18 is an information interaction flow chart provided in an embodiment of the present application. As shown in Figure 18, the method includes:
  • the first CU sends a DU migration request to the third CU.
  • the DU migration request is used to request the migration of the DU of the IAB node to the topology of the third CU.
  • the DU migration request includes the XNAP ID of the MT of the IAB node under the first CU.
  • the DU migration request includes the XNAP ID of the MT of the IAB node under the third CU, QoS information, and the IP address of the UE traffic.
  • the third CU sends a DU migration response to the first CU.
  • DU migration response is a message that the third CU replies to the first CU in response to the DU migration request.
  • the DU migration response is used to indicate that the third CU agrees to migrate the DU of the IAB node to the topology of the third CU.
  • the DU migration response is used to indicate that the third CU has learned to migrate the DU of the IAB node to the topology of the third CU.
  • the first CU sends a second message to the DU of the IAB node.
  • the first CU sends the second message to the DU of the IAB node through the F1 interface between the first CU and the DU of the IAB node.
  • the first CU sends a DU migration request to the third CU.
  • Step 1801' can refer to step 1801.
  • the third CU sends a DU migration response to the second CU.
  • the second CU sends a second message to the MT of the IAB node.
  • the second CU sends the second message to the mIAB-MT through the RRC connection between the second CU and the mIAB-MT.
  • Steps 1801' to 1803' are applicable to the case where the migration of the DU precedes the switching of the MT, and the MT is still connected in the second CU topology.
  • the first CU sends a DU migration request to the third CU.
  • Step 1801 can refer to step 1801.
  • the third CU sends a second message to the MT of the IAB node.
  • the third CU is directly sent to the mIAB-MT through the RRC connection between the third CU and the mIAB-MT.
  • Steps 1801" to 1802" are used in the case where the migration of the DU is later than the switching performed by the MT, and the MT is already connected to the third CU topology.
  • the second message may carry the XNAP ID of the mIAB-MT under both the first CU and the third CU, or may only carry the XNAP ID of the mIAB-MT under the first CU. If there is no XN interface between the first CU and the third CU (e.g., IP is unreachable), the second message may also be delivered through the NG interface or forwarded through the second CU.
  • step 1801 to step 1803 is an independent interaction process
  • step 1801' to step 1803' is another independent interaction process
  • step 1801" to step 1802" is another independent interaction process.
  • Figure 18 shows three possible ways of sending the second message to the DU of the IAB node.
  • An optional enhancement is also introduced in the embodiment of the present application, that is, the IP address and QoS information of the UE traffic are carried in the second message, so that the third CU can know in advance the UE traffic information (such as QoS, etc.) brought by the DU migration, so as to configure it in advance, without having to wait until the subsequent DU migration is completed and then obtain the UE traffic information through UE HO REQUEST.
  • the UE traffic information such as QoS, etc.
  • the embodiments of the present application provide various possible DU migration interaction methods to enable DU migration to be performed.
  • FIG19 is a flow chart of another information interaction method provided in an embodiment of the present application.
  • FIG19 describes a method of the IAB transmission migration management process in which the first CU initiates a partial migration to the third CU when there is no XN interface between the first CU and the third CU. As shown in FIG19, the method includes:
  • the first CU sends the sixth message to AMF.
  • the sixth message includes the IP address of the traffic of the IAB node under the third CU, the QoS information of the traffic of the IAB node, and the NGAP ID of the third CU.
  • AMF can be replaced by other network elements with specific access and mobility management functions.
  • AMF sends the eleventh message to the third CU.
  • the eleventh message includes the IP address of the traffic of the IAB node under the third CU, the QoS information of the traffic of the IAB node, and the NGAP ID of the first CU.
  • the eleventh message can be regarded as the sixth message forwarded by the AMF to the third CU.
  • the third CU sends the twelfth message to AMF.
  • the twelfth message includes the backhaul link information under the third CU, the DSCP or flow label (Flow Label) information of the traffic of the IAB node, and the ID of the first CU.
  • AMF sends the seventh message to the first CU.
  • the seventh message includes the backhaul link information under the third CU, the DSCP or flow label information of the traffic of the IAB node, and the ID of the third CU.
  • the seventh message can be regarded as the seventh message forwarded by the AMF to the first CU.
  • the sixth message, the seventh message, the eleventh message, and the twelfth message are messages on the NG interface.
  • An example of an embodiment of the present application is to transmit the key information elements in the IAB TRANSPORT MIGRATION MANAGEMENT REQUEST/RESPONSE message on the XN interface in a new message on the NG interface.
  • the key information elements transmitted by the first CU to the third CU include the IP address and QoS parameters of each traffic.
  • the key information elements transmitted by the third CU to the first CU include the backhaul link information allocated to these traffic under the third CU topology, and the DSCP/Flow Label configured for its QoS parameters.
  • the DSCP/Flow Label is used by the first CU to insert the DSCP/Flow Label into the IP header of the downstream traffic sent from the first CU.
  • the embodiment of the present application introduces a new NG message, which transmits the key information elements in the IAB TRANSPORT MIGRATION MANAGEMENT REQUEST/RESPONSE message on the XN interface in the new message on the NG interface, so that partial migration can work even when there is no IP path between the source CU and the target CU or the target donor-DU.
  • the cell ID (including PCI, CGI) of each cell is pre-configured by the network management system to ensure that there is no conflict with the cell ID of the neighboring cell. Since the base station is fixed, the cell ID does not need to change.
  • the cell under the DU of the IAB node is constantly moving with the IAB node. If the cell under it always uses the same cell ID, it may conflict with the current nearby cell due to the change in the neighboring cell relationship. Therefore, the cell ID of the cell under the DU of the IAB node may need to be changed. For the cell of the DU that is providing services to the UE, its cell ID cannot be changed suddenly, otherwise it will cause the interruption of the UE link.
  • TAC and RANAC in the cell broadcast information are similar. These parameters do not need to change when the base station is fixed. In the mobile IAB scenario, TAC and RANAC may no longer reflect the current geographic location information and also face the problem of needing to be updated. For the cell of the DU that is providing services to the UE, these broadcast parameters cannot be changed suddenly, otherwise it will cause the interruption of the UE link.
  • an embodiment of the present application provides a solution that activates some new cells under the DU of the IAB node (it is not necessary to start a new DU like DU Migration, and here it is sufficient to start a new cell under the same DU), and then performs cell switching on the UE, switching from the old (conflicting or needing to be changed) PCI/CGI/TAC/RANAC cell to the new one. PCI/CGI/TAC/RANAC cell.
  • an embodiment of the present application provides an interactive flow chart of a cell switching method, which can be performed through the interaction between a UE, an IAB node and a donor node (Donor-CU), wherein the IAB node includes an IAB-DU and an IAB-MT.
  • the donor node can establish an F1 connection with multiple IAB nodes to perform data interaction.
  • the method includes:
  • the IAB node is pre-configured with one or more of the following: PCI list, CGI list, TAC list, RANAC list.
  • the network management preconfigures one or more of the following items to the IAB node: PCI list, CGI list, TAC list, RANAC list.
  • TAC tracking area code
  • RANAC radio access network area code
  • the corresponding gNB ID or CGI may also be configured.
  • the PCI list or CGI list it includes a resource pool of PCI or CGI.
  • step 2000 is a pre-configuration operation, and the IAB node may not need to execute step 2000 before executing step 2001.
  • the PCI list is used to detect whether the PCI conflicts.
  • the IAB node does not need to execute step 2000 before each execution of step 2000.
  • the IAB node pre-configures one or more of the following: PCI list, CGI list, TAC list, RANAC list, step 2001 can be directly executed later without executing step 2000.
  • the IAB node detects a cell identity (including PCI or CGI) conflict.
  • the IAB node detects a PCI/CGI conflict because the PCI/CGI of the nearby cell heard by the MT of the IAB node is the same as the PCI/CGI of the cell under its own DU.
  • Step 2001 may also be replaced by the IAB node wanting to change the UE's service cell for some other reason, or because the IAB node determines that the TAC or RANAC broadcast by the cell needs to be changed based on the CGI or gNB ID heard from the parent node, such as: in the TAC list or RANAC list, the item corresponding to the current gNB ID or CGI is different from the TAC or RANAC broadcast in the current IAB-DU cell.
  • the DU of the IAB node sends a first message to the CU.
  • the CU receives the first message of the DU from the IAB node.
  • the first message is used to indicate the cell that the IAB node wishes to activate.
  • the first message includes a list, and the list includes the PCI of the cell that you want to activate.
  • the first message includes indication information 1 and the PCI of one or more cells, and the indication information 1 is used to indicate that the cell corresponding to the PCI of the one or more cells is the cell that you want to activate.
  • the first message is a gNB-DU Configuration Update message.
  • the gNB-DU Configuration Update message can be found in standard TS 38.473 V17.2.0 Section 9.2.1.7.
  • the carrying method of CGI, TAC, and RANAC of the cell that you want to activate is the same as PCI.
  • the CU sends a second message to the DU of the IAB node according to the first message.
  • the second message is used to activate the cell that the IAB node wants to activate.
  • the second message is a gNB-DU Configuration Update ACK message.
  • the gNB-DU Configuration Update ACK message can be found in standard TS 38.473 V17.2.0 Section 9.2.1.8.
  • CU sends a switching command to the terminal device.
  • the terminal device receives a handover command from the CU.
  • the handover command is used for the terminal device to handover to the cell that the IAB node wishes to activate.
  • the CU After sending the second message to the DU of the IAB node, the CU sends the handover command to the terminal device.
  • the terminal device switches to the cell that the IAB node wants to activate according to the switching command, and sends a switching completion message to the CU.
  • the CU receives a handover completion message from the terminal device.
  • the handover completion message is used to indicate that the terminal device has been handed over to the cell that the IAB node wishes to activate.
  • the CU sends a third message to the DU of the IAB node.
  • the third message is used to deactivate the cell that the IAB node wants to deactivate.
  • the CU notifies the IAB node to deactivate (or deactivate) the old cell through an RRC message or an F1 message.
  • the first message is also used to indicate the cells that the IAB node wishes to shut down; after receiving the handover completion message from the terminal device, the CU sends a third message to the DU of the IAB node.
  • the DU of the IAB node can inform the CU by sending a first message to the CU which of its own cells (new PCI) wish to be activated and which cells (old PCI cells) wish to be "deactivated" (shut down).
  • the PCI of each cell under the DU can be carried in this message, and corresponding instructions can be carried for the cells that wish to be activated and the cells that wish to be deactivated.
  • a table is used to represent the mapping relationship between the new cell PCI and the old cell PCI, and the column corresponding to the new cell is the cell that wishes to be activated, and the column corresponding to the old cell is the cell that wishes to be deactivated, thereby telling the CU which PCI corresponding cells wish to be activated and which PCI corresponding cells wish to be shut down.
  • the closing method of the old cells related to CGI, TAC, and RANAC is the same as that of PCI. It should be noted that the meanings of the first message, the second message, and the handover command in the method flow of Figure 20 are different from those in the above text.
  • the IAB node when the IAB node wishes to change the PCI/CGI/TAC/RANAC, or wishes to change the UE cell, it will activate The new cell informs the CU, and the CU activates the cell according to the instructions, then performs UE switching, and instructs the IAB node to shut down the old cell after the UE switching is completed.
  • the embodiment of the present application supports a conflict resolution method after the IAB node detects a PCI or CGI conflict, and a solution for detecting the need to change TAC or RANAC based on the currently connected gNB ID or CGI, reducing the interference problem caused by PCI or CGI conflicts that may occur in the mobile IAB scenario, and reducing the problem that the TAC or RANAC broadcast by the mobile IAB cannot reflect the current geographic location information.
  • FIG21 shows a possible exemplary block diagram of a communication device involved in an embodiment of the present application.
  • the communication device 2100 may include: a processing unit 2101 and a transceiver unit 2102.
  • the processing unit 2101 is used to control and manage the actions of the communication device 2100.
  • the transceiver unit 2102 is used to support the communication of the communication device 2100 with other devices.
  • the transceiver unit 2102 may include a receiving unit and/or a sending unit, which are respectively used to perform receiving and sending operations.
  • the communication device 2100 may also include a storage unit for storing program code and/or data of the communication device 2100.
  • the transceiver unit may be referred to as an input-output unit, a communication unit, etc., and the transceiver unit may be a transceiver; the processing unit may be a processor.
  • the communication device is a module (such as a chip) in a communication device
  • the transceiver unit may be an input-output interface, an input-output circuit or an input-output pin, etc., and may also be referred to as an interface, a communication interface or an interface circuit, etc.
  • the processing unit may be a processor, a processing circuit or a logic circuit, etc.
  • the device can be the above-mentioned terminal equipment, IAB-DU, donor CU, etc.
  • FIG22 a simplified schematic diagram of the structure of a terminal device provided by the present application is shown.
  • a mobile phone is used as an example of the terminal device.
  • the terminal device includes a processor, a memory, a radio frequency circuit, an antenna, and an input/output device.
  • the processor is mainly used to process communication protocols and communication data, as well as control terminal devices, execute software programs, process software program data, etc.
  • Memory is mainly used to store software programs and data.
  • Radio frequency circuits are mainly used for conversion between baseband signals and radio frequency signals and for processing radio frequency signals.
  • Antennas are mainly used to send and receive radio frequency signals in the form of electromagnetic waves.
  • Input and output devices such as touch screens, display screens, keyboards, etc., are mainly used to receive data input by users and output data to users.
  • terminal devices may not have input and output devices.
  • the processor When data needs to be sent, the processor performs baseband processing on the data to be sent and outputs the baseband signal to the RF circuit.
  • the RF circuit performs RF processing on the baseband signal and then sends the RF signal outward in the form of electromagnetic waves through the antenna.
  • the RF circuit receives the RF signal through the antenna, converts the RF signal into a baseband signal, and outputs the baseband signal to the processor.
  • the processor converts the baseband signal into data and processes the data.
  • FIG22 For ease of explanation, only one memory and processor are shown in FIG22. In an actual terminal device product, there may be one or more processors and one or more memories.
  • the memory may also be referred to as a storage medium or a storage device, etc.
  • the memory may be set independently of the processor or may be integrated with the processor, and the embodiments of the present application do not limit this.
  • the antenna and the radio frequency circuit with transceiver functions can be regarded as the transceiver unit of the terminal device, and the processor with processing function can be regarded as the processing unit of the terminal device.
  • the terminal device 2200 includes a transceiver unit 2210 and a processing unit 2220.
  • the transceiver unit 2210 may also be referred to as a transceiver, a transceiver, a transceiver device, etc.
  • the processing unit 2220 may also be referred to as a processor, a processing board, a processing unit, a processing device, etc.
  • the device used to implement the receiving function in the transceiver unit 2210 may be regarded as a receiving unit, and the device used to implement the sending function in the transceiver unit 2210 may be regarded as a sending unit, that is, the transceiver unit 2210 includes a receiving unit and a sending unit.
  • the transceiver unit may sometimes be referred to as a transceiver, a transceiver, or a transceiver circuit.
  • the receiving unit may sometimes be referred to as a receiver, a receiver, or a receiving circuit.
  • the sending unit may sometimes be referred to as a transmitter, a transmitter, or a transmitting circuit.
  • transceiver unit 2210 is used to perform the sending operation and the receiving operation of the terminal device in the above method embodiment
  • processing unit 2220 is used to perform other operations except the sending and receiving operation on the terminal device in the above method embodiment.
  • the chip When the terminal device is a chip, the chip includes a transceiver unit 2210 and a processing unit 2220.
  • the transceiver unit 2210 may be an input/output circuit or a communication interface;
  • the processing unit 2220 is a processor or a microprocessor or an integrated circuit or a logic circuit integrated on the chip.
  • the present application also provides a network device.
  • FIG. 23 it is a schematic diagram of the structure of a network device 2300 provided in an embodiment of the present application.
  • the network device 2300 can be applied to the system shown in FIG. 1.
  • the network device 2300 can be an IAB-DU or a donor CU to perform the functions of the network device in the above method embodiment. It should be understood that the following is only an example. In future communication systems, network devices may have other forms and structures.
  • the network device 2300 may include a CU, a DU, and an AAU.
  • the network equipment consists of one or more radio frequency units, such as remote radio units (RRUs) and one or more building base band units (BBUs).
  • RRUs remote radio units
  • BBUs building base band units
  • the non-real-time part of the original BBU will be separated and redefined as CU, which is responsible for processing non-real-time protocols and services.
  • Some physical layer processing functions of BBU will be merged with the original RRU and passive antenna into AAU.
  • the remaining functions of BBU will be redefined as DU, which is responsible for processing physical layer protocols and real-time services.
  • CU and DU are distinguished by the real-time nature of the processing content, and AAU is a combination of RRU and antenna.
  • CU, DU, and AAU can be separated or co-located, so there will be a variety of network deployment forms.
  • One possible deployment form is shown in Figure 23, which is consistent with the traditional 4G network equipment, and CU and DU are deployed in the same hardware. It should be understood that Figure 23 is only an example and does not limit the scope of protection of this application.
  • the deployment form can also be DU deployed in the BBU room, CU centralized deployment or DU centralized deployment, CU higher-level centralized, etc.
  • the AAU2400 can implement a transceiver function corresponding to the transceiver unit 2102 in FIG. 21.
  • the AAU2400 can also be called a transceiver, a transceiver circuit, or a transceiver, etc., which may include at least one antenna 2401 and a radio frequency unit 2402.
  • the AAU2400 may include a receiving unit and a transmitting unit, the receiving unit may correspond to a receiver (or a receiver, a receiving circuit), and the transmitting unit may correspond to a transmitter (or a transmitter, a transmitting circuit).
  • the internal processing functions that the CU and DU2500 can implement correspond to the functions of the processing unit 2101 in FIG. 21.
  • the CU and DU2500 can control network devices, etc., and may be called a controller.
  • the AAU and the CU and DU may be physically arranged together or physically separated.
  • the network device is not limited to the form shown in Figure 23, but can also be in other forms: for example: including a BBU and an adaptive radio unit (adaptive radio unit, ARU), or including a BBU and an AAU; it can also be customer premises equipment (customer premises equipment, CPE), and can also be in other forms, which is not limited in this application.
  • ARU adaptive radio unit
  • AAU adaptive radio unit
  • CPE customer premises equipment
  • the CU and DU2500 may be composed of one or more single boards, and multiple single boards may jointly support a wireless access network of a single access standard (such as an LTE network), or may respectively support wireless access networks of different access standards (such as an LTE network, a 5G network, a future network or other networks).
  • the CU and DU2500 also include a memory 2501 and a processor 2502.
  • the memory 2501 is used to store necessary instructions and data.
  • the processor 2502 is used to control the network device to perform necessary actions, such as controlling the network device to execute the operation flow of the network device in the above method embodiment.
  • the memory 2501 and the processor 2502 can serve one or more single boards. In other words, a memory and a processor may be separately set on each single board. It is also possible that multiple single boards share the same memory and processor. In addition, necessary circuits may be set on each single board.
  • the network device 2300 shown in Figure 23 can implement the network device functions involved in the method embodiment of Figure 7.
  • the operations and/or functions of each unit in the network device 2300 are respectively to implement the corresponding processes performed by the network device in the method embodiment of the present application. To avoid repetition, the detailed description is appropriately omitted here.
  • the structure of the network device illustrated in Figure 23 is only a possible form and should not constitute any limitation on the embodiment of the present application. The present application does not exclude the possibility of other forms of network device structures that may appear in the future.
  • the above CU and DU2500 can be used to execute the actions implemented by the network device described in the previous method embodiment, and the AAU2400 can be used to execute the actions of the network device sending to or receiving from the terminal device described in the previous method embodiment. Please refer to the description in the previous method embodiment for details, which will not be repeated here.
  • An embodiment of the present application further provides a communication system, which includes the first CU, the second CU, the third CU and the IAB node.
  • the embodiments of the present application further provide a readable storage medium, which stores instructions, and when the instructions are executed, the method in any of the above embodiments is implemented.
  • the readable storage medium may include: a USB flash drive, a mobile hard disk, a read-only memory, a random access memory, a magnetic disk or an optical disk, and other media that can store program codes.
  • the embodiments of the present application may be provided as methods, systems, or computer program products. Therefore, the present application may take the form of a complete hardware embodiment, a complete software embodiment, or an embodiment combining software and hardware. Moreover, the present application may take the form of a computer program product implemented on one or more computer-usable storage media (including but not limited to disk storage, compact disc read-only memory (CD-ROM), optical storage, etc.) containing computer-usable program code.
  • CD-ROM compact disc read-only memory
  • optical storage etc.
  • These computer program instructions may also be stored in a computer program that can direct a computer or other programmable data processing device to work in a specific manner.
  • the computer readable memory causes the instructions stored in the computer readable memory to produce a product including an instruction device, which implements the functions specified in one or more processes in the flowchart and/or one or more blocks in the block diagram.
  • These computer program instructions may also be loaded onto a computer or other programmable data processing device so that a series of operational steps are executed on the computer or other programmable device to produce a computer-implemented process, whereby the instructions executed on the computer or other programmable device provide steps for implementing the functions specified in one or more processes in the flowchart and/or one or more boxes in the block diagram.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Mobile Radio Communication Systems (AREA)

Abstract

本申请提供一种通信方法和通信装置，涉及通信技术领域，本申请可以应用于IAB网络中的DU迁移。该方法应用于第一CU或第一CU中的模块，该方法包括：接收第一消息，该第一消息包括用于在第三CU中标识IAB节点的MT的ID和第三CU的ID；根据第一消息，确定是否要进行IAB节点的DU的迁移；在确定要进行IAB节点的DU迁移的情况下，向IAB节点发送第二消息，其中，第二消息用于指示所述IAB节点的DU与所述第三CU建立F1接口。本申请实施例中的方案可支持因MT发生拓扑变化而触发的DU迁移，解决了现有技术不支持的连续partial migration的过程中迁移DU的问题。

Description

一种通信方法和通信装置
本申请要求在2022年11月03日提交中国国家知识产权局、申请号为202211372936.8的中国专利申请的优先权，发明名称为“一种通信方法和通信装置”的中国专利申请的优先权，其全部内容通过引用结合在本申请中。
技术领域
本申请涉及通信领域，尤其涉及一种通信方法和通信装置。
背景技术
相较于第四代移动通信系统，第五代移动通信(5G)针对网络各项性能指标，提出了更严苛的要求。例如，容量提升1000倍、更广的覆盖需求、超高可靠超低时延等。一方面，考虑到高频载波频率资源丰富，在热点区域为满足5G超高容量需求，利用高频小站组网愈发流行。高频载波传播特性较差，受遮挡衰减严重，覆盖范围不广，故而需要大量密集部署小站。相应地，为这些大量密集部署的小站提供光纤回传的代价很高，施工难度大，因此需要经济便捷的回传方案。另一方面，从广覆盖需求的角度出发，在一些偏远地区提供网络覆盖，光纤的部署难度大，成本高，也需要设计灵活便利的接入和回传方案。接入回传一体化(integrated access and backhaul,IAB)技术为解决上述两个问题提供了思路：其接入链路(access link)和回传链路(backhaul link)皆采用无线传输方案，减少了光纤部署。
在IAB网络中，中继节点，或者叫IAB节点(IAB-node)，可以为用户设备(UE，user equipment)提供无线接入服务。UE的业务数据由IAB-node通过无线回传链路连接到IAB宿主(IAB-donor)传输。IAB-node包括移动终端(mobile termination，MT)部分和分布式单元(distributed unit，DU)部分。其中，当IAB-node面向其父节点时，可以作为终端设备，即MT的角色；当IAB-node面向其子节点(子节点可能是另一IAB-node，或者UE)时，其被视为网络设备，即作为DU的角色。IAB-donor是一个具有完整基站(例如gNB)功能的接入网网元，包括集中式单元(centralized unit，CU)和分布式单元(distributed unit，DU)，IAB-donor连接到为UE服务的核心网(例如连接到5G核心网)。
在Rel-17的讨论中，将IAB节点跨CU迁移分为完全迁移(full migration)和部分迁移(partial migration)两种实现方式。部分迁移中，发生迁移的IAB节点，即边界节点(boundary node)的MT发生了跨CU切换，但该边界节点的DU仍然与源CU保持F1连接；而完全迁移中，边界节点的DU需要与目标(target)CU建立F1连接。完全迁移和部分迁移的本质区别在于是否需要进行DU的迁移(事实上，是生成一个新的逻辑DU再与目标CU建立F1接口，但从IAB节点宏观角度考虑，通常也可以表述为“DU的迁移”)。在Rel-18 mobile IAB的立项文件中，将full migration作为必选特性。然而，这也并不意味着IAB节点每一次迁移都需要做full migration。在Rel-18前几次会议的讨论中，主流观点是以连续的partial migration作为基线，在需要进行DU迁移的时候，再进行DU的迁移。当前会议的结论是在连续partial migration中，由CU决定是否做DU的迁移。然而，目前未给出具体的方案。因此需要研究在连续partial migration中进行DU迁移的方案。
发明内容
本申请实施例公开了一种通信方法和通信装置，能够实现连续partial migration中的DU迁移。
第一方面，本申请实施例提供一种通信方法，该方法应用于第一CU或第一CU中的模块，该方法包括：接收第一消息，所述第一消息包括用于在第三CU中标识IAB节点的MT的标识(identification，ID)和所述第三CU的ID；根据所述第一消息，确定是否要进行所述IAB节点的DU的迁移；在确定要进行所述IAB节点的DU迁移的情况下，向所述IAB节点发送第二消息，其中，所述第二消息用于指示所述IAB节点的DU与所述第三CU建立F1接口。
本申请实施例中，第一CU接收到第一消息之后，根据第一消息确定是否要进行IAB节点的DU的迁移。第一CU接收到第一消息为第一CU决定是否迁移IAB节点的DU的触发条件，因此本申请实施例给出了第一CU决定是否迁移IAB节点的DU的触发条件。根据第一消息，确定是否要进行IAB节点的DU的迁移。可见，本申请实施例还给出了第一CU决定是否迁移IAB节点的DU的依据。在确定要进行IAB节点的DU迁移的情况下，向IAB节点发送第二消息为本申请实施例提供的DU迁移方式。本申请实施例 中的方案可支持因MT发生拓扑变化而触发的DU迁移，解决了现有技术不支持的连续partial migration的过程中迁移DU的问题。
在一种可能的实现方式中，所述第二消息用于指示所述IAB节点的DU生成一个新的逻辑DU，并与所述第三CU建立F1接口。
在该实现方式中，第一CU通过发送第二消息指示IAB节点的DU生成一个新的逻辑DU，并与第三CU建立F1接口，以便实现IAB节点的DU的迁移。
在一种可能的实现方式中，所述第一消息还包括所述第三CU的IP地址或者所述第三CU管理的宿主DU的IP地址。
在该实现方式中，第一消息还包括第三CU的IP地址或者第三CU管理的宿主DU的IP地址，以便第一CU根据第三CU的IP地址或者第三CU管理的宿主DU的IP地址，确定是否要进行IAB节点的DU迁移。
在一种可能的实现方式中，所述根据所述第一消息，确定是否要进行所述IAB节点的DU的迁移包括：根据所述第一消息，确定所述第一CU是否能够不通过核心网到达所述第三CU或所述第三CU管理的宿主DU；或者，根据所述第一消息，确定所述第一CU是否能够与所述第三CU建立XN接口；或者，根据所述第一消息，确定所述第一CU是否能够通过IP路由的方式到达所述第三CU或所述第三CU管理的宿主DU。应理解，若所述第一CU不能够不通过核心网到达所述第三CU或所述第三CU管理的宿主DU，则确定要进行所述IAB节点的DU的迁移；若所述第一CU能够不通过核心网到达所述第三CU或所述第三CU管理的宿主DU，则确定不进行所述IAB节点的DU的迁移。若所述第一CU能够与所述第三CU建立XN接口，则确定不进行所述IAB节点的DU的迁移；若所述第一CU不能与所述第三CU建立XN接口，则确定进行所述IAB节点的DU的迁移。若所述第一CU能够通过IP路由的方式到达所述第三CU或所述第三CU管理的宿主DU，则确定不进行所述IAB节点的DU的迁移；若所述第一CU不能通过IP路由的方式到达所述第三CU或所述第三CU管理的宿主DU，则确定进行所述IAB节点的DU的迁移。
在该实现方式中，提供了根据第一消息，确定是否要进行IAB节点的DU的迁移的三种方式；能够较合理的确定是否要进行IAB节点的DU的迁移。
在一种可能的实现方式中，所述MT与第二CU之间具有无线资源控制(radio resource control，RRC)连接，或者，所述第三CU下的拓扑为所述MT从所述第二CU的拓扑下变换至的拓扑。
在该实现方式中，能够解决现有技术不支持的连续partial migration的过程中迁移DU的问题。
在一种可能的实现方式中，所述第一消息用于指示所述MT将从所述第二CU下的拓扑切换至所述第三CU下的拓扑、所述MT已完成从所述第二CU下的拓扑至所述第三CU下的拓扑的切换、或者所述MT与所述第二CU之间发生无线链路失败且接入所述第三CU下的拓扑下中的任一项。
在该实现方式中，第一消息可及时触发，第一CU决定是否迁移IAB节点的DU。
在一种可能的实现方式中，所述MT与第二CU之间具有无线资源控制RRC连接；所述方法还包括：在确定要进行所述IAB节点的DU迁移的情况下，向所述第二CU发送第三消息，所述第三消息用于请求所述第二CU在其拓扑内为所述IAB节点的DU与所述第三CU之间的F1接口配置资源。
在该实现方式中，在确定要进行IAB节点的DU迁移的情况下，向第二CU发送第三消息，以便第二CU在其拓扑内为IAB节点的DU与第三CU之间的F1接口配置资源；可避免IAB节点的DU与第三CU通过NG交互，从而加快迁移DU的速度。
在一种可能的实现方式中，所述第一消息用于指示所述MT将从所述第二CU下的拓扑切换至所述第三CU下的拓扑；在向所述第二CU发送第三消息之后，所述方法还包括：接收第四消息，所述第四消息用于指示所述IAB节点的DU与所述第三CU之间的F1接口已建立。
在该实现方式中，接收第四消息，能够获知IAB节点的DU与第三CU之间的F1接口已建立。
在一种可能的实现方式中，在接收第四消息之后，所述方法还包括：在向终端设备发送第一切换命令之后，向所述第二CU发送第五消息，所述第一切换命令用于指示所述终端设备切换至所述IAB节点的DU下的目标小区，所述第五消息用于指示所述第一CU已发送所述第一切换命令。
在该实现方式中，向第二CU发送第五消息，以便第二CU及时向IAB节点的MT发送切换指令。
在一种可能的实现方式中，所述方法还包括：在确定不进行所述IAB节点DU迁移的情况下，向所述第三CU发起部分迁移中的IAB传输迁移管理流程，所述流程用于流量的跨拓扑迁移。
在该实现方式中，第一CU与IAB节点之间的流量能够通过第三CU下的拓扑传输，保障了IAB节点所服务UE的业务连续性。
在一种可能的实现方式中，所述向所述第三CU发起部分迁移中的IAB传输迁移管理流程包括：向接入和移动性管理功能(access and mobility management)网元发送第六消息，所述第六消息包括所述IAB节点的流量在所述第三CU下的IP地址以及所述IAB节点的流量的服务质量QoS信息；接收来自所述接入和移动性管理功能网元的第七消息，所述第七消息包括所述第三CU下的回传链路信息，以及所述IAB节点的流量的区分服务编码点(differentiated services code point，DSCP)或流标签(Flow Label)信息。
在该实现方式中，通过接入和移动性管理功能网元能够获得第三CU下的回传链路信息，以及IAB节点的流量的DSCP或留流签。
第二方面，本申请实施例提供另一种通信方法，该方法应用于第二CU或第二CU中的模块，该方法包括：生成第一消息；向第一CU发送所述第一消息，所述第一消息用于指示所述IAB节点的MT将从所述第二CU下的拓扑切换至所述第三CU下的拓扑、所述MT已完成从所述第二CU下的拓扑至所述第三CU下的拓扑的切换、或者所述MT与所述第二CU之间发生无线链路失败且接入所述第三CU下的拓扑下中的任一项。
本申请实施例中，向第一CU发送第一消息，以便触发第一CU决定是否进行IAB节点的DU的迁移，给出了第一CU决定是否迁移IAB节点的DU的触发条件。
在一种可能的实现方式中，在向第一CU发送所述第一消息之后，所述方法还包括：接收来自第一CU的第三消息；根据所述第三消息，在其拓扑内为IAB节点的DU与第三CU之间的F1接口配置资源。
在该实现方式中，第二CU在其拓扑内为IAB节点的DU与第三CU之间的F1接口配置资源，能够帮助建立IAB节点的DU与第三CU之间的F1接口。
在一种可能的实现方式中，在向第一CU发送所述第一消息之前，所述方法还包括：接收来自第三CU的第八消息，所述第八消息用于指示IAB节点的MT将切换至所述第三CU下的拓扑、所述MT已切换至所述第三CU下的拓扑、或者所述MT在与所述第二CU之间发生无线链路失败之后已接入所述第三CU下的拓扑中的任一项。接收到所述第八消息，为所述第二CU向第一CU发送所述第一消息的触发条件。
在该实现方式中，接收来自第三CU的第八消息，以便及时向第一CU发送第一消息，即触发第一CU决定是否要进行IAB节点的DU的迁移。
在一种可能的实现方式中，所述第八消息包括所述第三CU的IP地址和/或所述第三CU管理的宿主DU的IP地址。
在该实现方式中，第八消息包括第三CU的IP地址和/或第三CU管理的宿主DU的IP地址，以便第二CU向第一CU提供第三CU的IP地址和/或第三CU管理的宿主DU的IP地址。
在一种可能的实现方式中，所述第一消息包括用于在所述第三CU中标识所述MT的ID和所述第三CU的ID。
在该实现方式中，可以使得第一CU根据第一消息，确定是否要进行IAB节点的DU的迁移。
在一种可能的实现方式中，所述方法还包括：接收来自所述第一CU的第五消息，所述第五消息用于指示所述第一CU已向终端设备发送第一切换命令，所述第一切换命令用于所述终端设备切换至所述IAB节点的DU下的目标小区；向所述MT发送第二切换命令，所述第二切换命令用于所述IAB节点的MT切换至所述第三CU下的拓扑。
在该实现方式中，能够及时使得IAB节点的MT切换至第三CU下的拓扑。
第三方面，本申请实施例提供另一种通信方法，该方法应用于第三CU或第三CU中的模块，该方法包括：生成第一消息；向第一CU发送所述第一消息，所述第一消息用于指示所述IAB节点的MT将从第二CU下的拓扑切换至所述第三CU下的拓扑、所述MT已完成从所述第二CU下的拓扑至所述第三CU下的拓扑的切换、或者所述MT与所述第二CU之间发生无线链路失败且接入所述第三CU下的拓扑下中的任一项。
本申请实施例中，向第一CU发送第一消息，以便触发第一CU决定是否进行IAB节点的DU的迁移，给出了第一CU决定是否迁移IAB节点的DU的触发条件。
在一种可能的实现方式中，在向第一CU发送所述第一消息之后，所述方法还包括：向所述第一CU发送第四消息，所述第四消息用于指示IAB节点的DU与所述第三CU之间的F1接口已建立。
在该实现方式中，向第一CU发送第四消息，能够指示IAB节点的DU与第三CU之间的F1接口已建立。
在一种可能的实现方式中，所述第一消息包括用于在所述第三CU中标识所述MT的ID和所述第三CU的ID。
在该实现方式中，可以使得第一CU根据第一消息，确定是否要进行IAB节点的DU的迁移。
在一种可能的实现方式中，在向所述第一CU发送第一消息之前，所述方法还包括：向所述第二CU发送第九消息或接收来自所述第二CU的第十消息，所述第九消息用于指示所述MT将切换至所述第三CU下的拓扑或者所述MT已变换至所述第三CU下的拓扑，所述第十消息用于指示所述MT已变换至所述第三CU下的拓扑。向所述第二CU发送第九消息或接收来自所述第二CU的第十消息为第三CU向所述第一CU发送第一消息的触发条件。
在该实现方式中，能够及时向第一CU发送第一消息，即触发第一CU决定是否要进行IAB节点的DU的迁移。
在一种可能的实现方式中，所述第九消息包括所述第三CU的IP地址和/或所述第三CU管理的宿主DU的IP地址。
在该实现方式中，第九消息包括第三CU的IP地址和/或第三CU管理的宿主DU的IP地址，以便第二CU向第一CU提供第三CU的IP地址和/或第三CU管理的宿主DU的IP地址。
在一种可能的实现方式中，所述第十消息包括所述MT在所述第一CU下的ID。
在该实现方式中，第十消息包括MT在第一CU下的ID，以便第三CU根据第十消息，向第一CU发送第一消息。
在一种可能的实现方式中，所述方法还包括：响应所述第一CU向所述第三CU发起的部分迁移中的IAB传输迁移管理流程。
在一种可能的实现方式中，所述响应所述第一CU向所述第三CU发起的部分迁移中的IAB传输迁移管理流程包括：接收来自接入和移动性管理功能网元的第十一消息，所述第十一消息包括所述IAB节点的流量在所述第三CU下的IP地址以及所述IAB节点的流量的QoS信息；向所述接入和移动性管理功能网元发送第十二消息，所述第十二消息包括所述第三CU下的回传链路信息，以及所述IAB节点的流量的区分服务编码点或流标签信息。
在该实现方式中，通过接入和移动性管理功能网元向第一CU提供第三CU下的回传链路信息，以及IAB节点的流量的DSCP或留流签。
第四方面，本申请实施例提供另一种通信方法，该方法应用于IAB节点或IAB节点中的模块，该方法包括：将所述IAB节点的MD从第二CU下的拓扑向第三CU下的拓扑切换；向第一CU发送第一消息，所述第一消息包括用于在所述第三CU中标识所述MT的ID，例如所述MT在所述第三CU下的XNAP ID。例如，IAB节点的MT切换至第三CU下的拓扑之后，IAB节点的DU向第一CU发送第一消息。又例如，在IAB节点的MT开始向第三CU下的拓扑切换之后，IAB节点的DU向第一CU发送第一消息。又例如，在IAB节点的MT向第三CU下的拓扑切换的过程中，IAB节点的DU向第一CU发送第一消息。
本申请实施例中，向第一CU发送第一消息，以便触发第一CU决定是否进行IAB节点的DU的迁移，给出了第一CU决定是否迁移IAB节点的DU的触发条件。
在一种可能的实现方式中，所述第一消息包括所述第三CU的IP地址和/或所述第三CU管理的宿主DU的IP地址。
在该实现方式中，第一消息包括第三CU的IP地址和/或第三CU管理的宿主DU的IP地址，以便第一CU根据第三CU的IP地址和/或第三CU管理的宿主DU的IP地址确定是否要进行IAB节点的DU的迁移。
在一种可能的实现方式中，在所述IAB节点的DU向第一CU发送第一消息之后，所述方法还包括：接收来自所述第一CU的第二消息；根据所述第二消息，与所述第三CU建立F1接口。例如，所述IAB节点的DU生成一个新的逻辑DU，并与所述第三CU建立F1接口。
在该实现方式中，可及时与第三CU建立F1接口。
第五方面，本申请实施例提供一种通信方法，该方法应用于IAB节点或IAB节点中的模块，该方法包括：向CU发送第一消息，所述第一消息用于指示所述IAB节点希望激活的小区；接收第二消息，所述第二消息用于激活所述IAB节点希望激活的小区。
本申请实施例中，IAB节点的DU向CU发送第一消息，并接收第二消息，能够激活IAB节点希望激活的小区。
在一种可能的实现方式中，所述第一消息还用于指示所述IAB节点希望关闭的小区；所述方法还包括：接收第三消息，所述第二消息用于关闭所述IAB节点希望关闭的小区。
在该实现方式中，IAB节点的DU接收第三消息，以便及时关闭IAB节点希望关闭的小区。
在一种可能的实现方式中，所述IAB节点的DU向CU发送第一消息包括：在检测到小区标识冲突的情况下，向所述CU发送所述第一消息。
在该实现方式中，能够及时发送第一消息。
第六方面，本申请实施例提供另一种小区切换方法，该方法应用于CU，该方法包括：
接收来自IAB节点的DU的第一消息，所述第一消息用于指示所述IAB节点希望激活的小区；向所述IAB节点的DU发送第二消息，所述第二消息用于激活所述IAB节点希望激活的小区。
本申请实施例中，通过向IAB节点的DU发送第二消息，能够激活IAB节点希望激活的小区。
在一种可能的实现方式中，所述第一消息还用于指示所述IAB节点希望关闭的小区；在所述CU向所述IAB节点的DU发送第二消息之后，所述方法还包括：在接收到来自终端设备的切换完成消息之后，向所述IAB节点的DU发送第三消息，所述第三消息用于关闭所述IAB节点希望关闭的小区，所述切换完成消息用于指示所述终端设备已切换至所述IAB节点希望激活的小区。
在该实现方式中，通过向IAB节点的DU发送第三消息，能够关闭IAB节点希望关闭的小区。
在一种可能的实现方式中，在所述CU向所述IAB节点的DU发送第二消息之后，所述方法还包括：向所述终端设备发送切换命令，所述切换命令用于所述终端设备切换至所述IAB节点希望激活的小区。
在该实现方式中，CU向终端设备发送切换命令，以便终端设备切换至IAB节点希望激活的小区，从而提高通信质量。
第七方面，本申请实施例提供一种通信装置，该通信装置具有实现上述第一方面方法实施例中的行为的功能。该通信装置可以是通信设备，也可以是通信设备的部件(例如处理器、芯片、或芯片系统等)，还可以是能实现全部或部分该通信设备的功能的逻辑模块或软件。该通信装置的功能可以通过硬件实现，也可以通过硬件执行相应的软件实现，该硬件或软件包括一个或多个与上述功能相对应的模块或单元。在一种可能的实现方式中，该通信装置包括收发单元和处理单元，其中：所述收发单元，用于接收第一消息，所述第一消息包括用于在第三CU中标识IAB节点的MT的ID和所述第三CU的ID；所述处理单元，用于根据所述第一消息，确定是否要进行所述IAB节点的DU的迁移；在确定要进行所述IAB节点的DU迁移的情况下，通过所述收发单元向所述IAB节点发送第二消息，其中，所述第二消息用于指示所述IAB节点的DU与所述第三CU建立F1接口。
在一种可能的实现方式中，所述处理单元，具体用于根据所述第一消息，确定所述第一CU是否能够不通过核心网到达所述第三CU或所述第三CU管理的宿主DU；或者，根据所述第一消息，确定所述第一CU是否能够与所述第三CU建立XN接口；或者，根据所述第一消息，确定所述第一CU是否能够通过IP路由的方式到达所述第三CU或所述第三CU管理的宿主DU。
在一种可能的实现方式中，所述MT与第二CU之间具有无线资源控制RRC连接；所述处理单元，还用于在确定要进行所述IAB节点的DU迁移的情况下，通过所述收发单元向所述第二CU发送第三消息，所述第三消息用于请求所述第二CU在其拓扑内为所述IAB节点的DU与所述第三CU之间的F1接口配置资源。
在一种可能的实现方式中，所述第一消息用于指示所述MT将从所述第二CU下的拓扑切换至所述第三CU下的拓扑；所述收发单元，还用于接收第四消息，所述第四消息用于指示所述IAB节点的DU与所述第三CU之间的F1接口已建立。
在一种可能的实现方式中，所述收发单元，还用于在向终端设备发送第一切换命令之后，向所述第二CU发送第五消息，所述第一切换命令用于指示所述终端设备切换至所述IAB节点的DU下的目标小区，所述第五消息用于指示所述第一CU已发送所述第一切换命令。
在一种可能的实现方式中，所述处理单元，还用于在确定不进行所述IAB节点DU迁移的情况下，通过所述收发单元向所述第三CU发起部分迁移中的IAB传输迁移管理流程，所述流程用于流量的跨拓扑迁移。
在一种可能的实现方式中，所述收发单元，具体用于向接入和移动性管理功能网元发送第六消息，所述第六消息包括所述IAB节点的流量在所述第三CU下的IP地址以及所述IAB节点的流量的服务质量QoS信息；接收来自所述接入和移动性管理功能网元的第七消息，所述第七消息包括所述第三CU下的回传链路信息，以及所述IAB节点的流量的DSCP或流标签信息。
第七方面的通信装置可能的实现方式可参见第一方面的各种可能的实现方式。
关于第七方面的各种可能的实现方式所带来的技术效果，可参考对于第一方面或第一方面的各种可能的实现方式的技术效果的介绍。
第八方面，本申请实施例提供另一种通信装置，该通信装置具有实现上述第二方面方法实施例中的行为的功能。该通信装置可以是通信设备，也可以是通信设备的部件(例如处理器、芯片、或芯片系统等)，还可以是能实现全部或部分该通信设备的功能的逻辑模块或软件。该通信装置的功能可以通过硬件实现，也可以通过硬件执行相应的软件实现，该硬件或软件包括一个或多个与上述功能相对应的模块或单元。在一种可能的实现方式中，该通信装置包括收发单元和处理单元，其中：所述处理单元，用于生成第一消息；所述收发单元，用于向第一CU发送所述第一消息，所述第一消息用于指示所述IAB节点的MT将从所述第二CU下的拓扑切换至所述第三CU下的拓扑、所述MT已完成从所述第二CU下的拓扑至所述第三CU下的拓扑的切换、或者所述MT与所述第二CU之间发生无线链路失败且接入所述第三CU下的拓扑下中的任一项。
在一种可能的实现方式中，所述收发单元，还用于接收来自第一CU的第三消息；所述处理单元，还用于根据所述第三消息，在其拓扑内为IAB节点的DU与第三CU之间的F1接口配置资源。
在一种可能的实现方式中，所述收发单元，还用于接收来自第三CU的第八消息，所述第八消息用于指示IAB节点的MT将切换至所述第三CU下的拓扑、所述MT已切换至所述第三CU下的拓扑、或者所述MT在与所述第二CU之间发生无线链路失败之后已接入所述第三CU下的拓扑中的任一项。接收到所述第八消息，为所述第二CU向第一CU发送所述第一消息的触发条件。
在一种可能的实现方式中，所述收发单元，还用于接收来自所述第一CU的第五消息，所述第五消息用于指示所述第一CU已向终端设备发送第一切换命令，所述第一切换命令用于所述终端设备切换至所述IAB节点的DU下的目标小区；向所述MT发送第二切换命令，所述第二切换命令用于所述IAB节点的MT切换至所述第三CU下的拓扑。
第八方面的通信装置可能的实现方式可参见第二方面的各种可能的实现方式。
关于第八方面的各种可能的实现方式所带来的技术效果，可参考对于第二方面或第二方面的各种可能的实现方式的技术效果的介绍。
第九方面，本申请实施例提供另一种通信装置，该通信装置具有实现上述第三方面方法实施例中的行为的功能。该通信装置可以是通信设备，也可以是通信设备的部件(例如处理器、芯片、或芯片系统等)，还可以是能实现全部或部分该通信设备的功能的逻辑模块或软件。该通信装置的功能可以通过硬件实现，也可以通过硬件执行相应的软件实现，该硬件或软件包括一个或多个与上述功能相对应的模块或单元。在一种可能的实现方式中，该通信装置包括收发单元和处理单元，其中：所述处理单元，用于生成第一消息；所述收发单元，用于向第一CU发送所述第一消息，所述第一消息用于指示所述IAB节点的MT将从第二CU下的拓扑切换至所述第三CU下的拓扑、所述MT已完成从所述第二CU下的拓扑至所述第三CU下的拓扑的切换、或者所述MT与所述第二CU之间发生无线链路失败且接入所述第三CU下的拓扑下中的任一项。
在一种可能的实现方式中，所述收发单元，还用于向所述第一CU发送第四消息，所述第四消息用于指示IAB节点的DU与所述第三CU之间的F1接口已建立。
在一种可能的实现方式中，所述收发单元，还用于向所述第二CU发送第九消息或接收来自所述第二CU的第十消息，所述第九消息用于指示所述MT将切换至所述第三CU下的拓扑或者所述MT已变换至所述第三CU下的拓扑，所述第十消息用于指示所述MT已变换至所述第三CU下的拓扑。向所述第二CU发送第九消息或接收来自所述第二CU的第十消息为第三CU向所述第一CU发送第一消息的触发条件。
在一种可能的实现方式中，所述处理单元，还用于响应所述第一CU向所述第三CU发起的部分迁移中的IAB传输迁移管理流程。
在一种可能的实现方式中，所述收发单元，还用于接收来自接入和移动性管理功能网元的第十一消息，所述第十一消息包括所述IAB节点的流量在所述第三CU下的IP地址以及所述IAB节点的流量的QoS信息；向所述接入和移动性管理功能网元发送第十二消息，所述第十二消息包括所述第三CU下的回传链路信息，以及所述IAB节点的流量的区分服务编码点或流标签信息。
第九方面的通信装置可能的实现方式可参见第三方面的各种可能的实现方式。
关于第九方面的各种可能的实现方式所带来的技术效果，可参考对于第三方面或第三方面的各种可能的实现方式的技术效果的介绍。
第十方面，本申请实施例提供另一种通信装置，该通信装置具有实现上述第四方面方法实施例中的行为的功能。该通信装置可以是通信设备，也可以是通信设备的部件(例如处理器、芯片、或芯片系统等)，还可以是能实现全部或部分该通信设备的功能的逻辑模块或软件。该通信装置的功能可以通过硬件实现， 也可以通过硬件执行相应的软件实现，该硬件或软件包括一个或多个与上述功能相对应的模块或单元。在一种可能的实现方式中，该通信装置包括收发单元和处理单元，其中：所述处理单元，用于将所述IAB节点的MD从第二CU下的拓扑向第三CU下的拓扑切换；所述收发单元，用于向第一CU发送第一消息，所述第一消息包括用于在所述第三CU中标识所述MT的ID，例如所述MT在所述第三CU下的XNAP ID。
在一种可能的实现方式中，所述收发单元，还用于接收来自所述第一CU的第二消息；所述处理单元，还用于根据所述第二消息，与所述第三CU建立F1接口。
第十方面的通信装置可能的实现方式可参见第四方面的各种可能的实现方式。
关于第十方面的各种可能的实现方式所带来的技术效果，可参考对于第四方面或第四方面的各种可能的实现方式的技术效果的介绍。
第十一方面，本申请实施例提供另一种通信装置，该通信装置具有实现上述第五方面方法实施例中的行为的功能。该通信装置可以是通信设备，也可以是通信设备的部件(例如处理器、芯片、或芯片系统等)，还可以是能实现全部或部分该通信设备的功能的逻辑模块或软件。该通信装置的功能可以通过硬件实现，也可以通过硬件执行相应的软件实现，该硬件或软件包括一个或多个与上述功能相对应的模块或单元。在一种可能的实现方式中，该通信装置包括收发单元和处理单元，其中：所述处理单元，用于生成第一消息；所述收发单元，用于向CU发送所述第一消息，所述第一消息用于指示所述IAB节点希望激活的小区；接收第二消息，所述第二消息用于激活所述IAB节点希望激活的小区。
在一种可能的实现方式中，所述第一消息还用于指示所述IAB节点希望关闭的小区；所述收发单元，还用于接收第三消息，所述第二消息用于关闭所述IAB节点希望关闭的小区。
在一种可能的实现方式中，所述处理单元，用于在检测到小区标识冲突的情况下，通过所述收发单元向所述CU发送所述第一消息。
第十一方面的通信装置可能的实现方式可参见第五方面的各种可能的实现方式。
关于第十一方面的各种可能的实现方式所带来的技术效果，可参考对于第五方面或第五方面的各种可能的实现方式的技术效果的介绍。
第十二方面，本申请实施例提供另一种通信装置，该通信装置具有实现上述第六方面方法实施例中的行为的功能。该通信装置可以是通信设备，也可以是通信设备的部件(例如处理器、芯片、或芯片系统等)，还可以是能实现全部或部分该通信设备的功能的逻辑模块或软件。该通信装置的功能可以通过硬件实现，也可以通过硬件执行相应的软件实现，该硬件或软件包括一个或多个与上述功能相对应的模块或单元。在一种可能的实现方式中，该通信装置包括收发单元和处理单元，其中：所述收发单元，用于接收来自IAB节点的DU的第一消息，所述第一消息用于指示所述IAB节点希望激活的小区；所述处理单元，用于生成第二消息；所述收发单元，还用于向所述IAB节点的DU发送第二消息，所述第二消息用于激活所述IAB节点希望激活的小区。
在一种可能的实现方式中，所述第一消息还用于指示所述IAB节点希望关闭的小区；所述收发单元，还用于在接收到来自终端设备的切换完成消息之后，向所述IAB节点的DU发送第三消息，所述第三消息用于关闭所述IAB节点希望关闭的小区，所述切换完成消息用于指示所述终端设备已切换至所述IAB节点希望激活的小区。
在一种可能的实现方式中，所述收发单元，还用于向所述终端设备发送切换命令，所述切换命令用于所述终端设备切换至所述IAB节点希望激活的小区。
第十二方面的通信装置可能的实现方式可参见第六方面的各种可能的实现方式。
关于第十二方面的各种可能的实现方式所带来的技术效果，可参考对于第六方面或第五方面的各种可能的实现方式的技术效果的介绍。
第十三方面，本申请实施例提供另一种通信装置，该通信装置包括处理器，该处理器与存储器耦合，该存储器用于存储程序或指令，当该程序或指令被该处理器执行时，使得该通信装置执行上述第一方面至上述第六方面中任一方面所示的方法。
本申请实施例中，在执行上述方法的过程中，上述方法中有关发送信息(或信号)的过程，可以理解为基于处理器的指令进行输出信息的过程。在输出信息时，处理器将信息输出给收发器，以便由收发器进行发射。该信息在由处理器输出之后，还可能需要进行其他的处理，然后到达收发器。类似的，处理器接收输入的信息时，收发器接收该信息，并将其输入处理器。更进一步的，在收发器收到该信息之后，该信息可能需要进行其他的处理，然后才输入处理器。
对于处理器所涉及的发送和/或接收等操作，如果没有特殊说明，或者，如果未与其在相关描述中的实 际作用或者内在逻辑相抵触，则可以一般性的理解为基于处理器的指令输出。
在实现过程中，上述处理器可以是专门用于执行这些方法的处理器，也可以是执行存储器中的计算机指令来执行这些方法的处理器，例如通用处理器等。例如，处理器还可以用于执行存储器中存储的程序，当该程序被执行时，使得该通信装置执行如上述第一方面或第一方面的任意可能的实现方式所示的方法。
在一种可能的实现方式中，存储器位于上述通信装置之外。在一种可能的实现方式中，存储器位于上述通信装置之内。
在一种可能的实现方式中，处理器和存储器还可能集成于一个器件中，即处理器和存储器还可能被集成于一起。
在一种可能的实现方式中，通信装置还包括收发器，该收发器，用于接收信号或发送信号等。
第十四方面，本申请提供另一种通信装置，该通信装置包括处理电路和接口电路，该接口电路用于获取数据或输出数据；处理电路用于执行如上述第一方面至上述第六方面中任一方面所示的方法。
第十五方面，本申请提供一种计算机可读存储介质，该计算机可读存储介质中存储有计算机程序，该计算机程序包括程序指令，该程序指令被执行时使得计算机执行如上述第一方面至上述第六方面中任一方面所示的方法。
第十六方面，本申请提供一种计算机程序产品，该计算机程序产品包括计算机程序，该计算机程序包括程序指令，该程序指令被执行时使得计算机执行如上述第一方面至上述第六方面中任一方面所示的方法。
第十七方面，本申请提供一种通信系统，包括上述第七方面或第七方面的任意可能的实现方式所述的通信装置、上述第八方面或第八方面的任意可能的实现方式所述的通信装置以及上述第八方面或第八方面的任意可能的实现方式所述的通信装置。
第十八方面，本申请提供一种通信系统，包括上述第十一方面或第十一方面的任意可能的实现方式所述的通信装置，以及上述第十二方面或第十二方面的任意可能的实现方式所述的通信装置。
第十九方面，本申请提供一种芯片，包括处理器与通信接口，所述处理器通过所述通信接口读取存储器上存储的指令，执行如上述第一方面至上述第六方面中任一方面所示的方法。
附图说明
为了更清楚地说明本申请实施例或背景技术中的技术方案，下面将对本申请实施例或背景技术中所需要使用的附图进行说明。
图1为本申请实施例应用的通信系统的架构示意图；
图2示出了包括多个UE和多个IAB节点的IAB网络的一种示例；
图3为一种IAB网络架构的示意图；
图4为IAB网络中的控制面协议架构的示意图；
图5为IAB网络中的用户面协议架构的示意图；
图6示出一种IAB网络架构的示意图；
图7为一种partial migration的示意图；
图8为一种full migration的示意图；
图9为一种连续partial migration(不迁移DU)的场景的示例；
图10为本申请实施例提供的一种连续partial migration中迁移DU的场景的示例；
图11示出了一种移动IAB节点的示意图；
图12为本申请实施例提供的一种IAB网络中的DU迁移方法交互流程图；
图13为本申请实施例提供的另一种IAB网络中的DU迁移方法交互流程图；
图14为本申请实施例提供的另一种IAB网络中的DU迁移方法交互流程图；
图15为本申请实施例提供的一种连续partial migration的示例；
图16为本申请实施例提供的一种IAB网络中的MT切换完成后的状态的示例；
图17为本申请实施例提供的另一种IAB网络中的DU迁移方法交互流程图；
图18为本申请实施例提供的一种信息交互流程图；
图19为本申请实施例提供的另一种信息交互方法流程图；
图20为本申请实施例提供一种小区切换方法交互流程图；
图21示出了本申请实施例中所涉及的通信装置的可能的示例性框图；
图22为本申请提供的一种简化的终端设备的结构示意图；
图23为本申请实施例提供的网络设备2300的结构示意图。
具体实施方式
本申请的说明书、权利要求书及附图中的术语“第一”和“第二”等仅用于区别不同对象，而不是用于描述特定顺序。可以理解的是，在本申请的实施例中涉及的各种数字编号仅为描述方便进行的区分，并不用来限制本申请的实施例的范围。上述各过程的序号的大小并不意味着执行顺序的先后，各过程的执行顺序应以其功能和内在逻辑确定。此外，术语“包括”和“具有”以及它们的任何变形，意图在于覆盖不排他的包含。例如包含了一系列步骤或单元的过程、方法、系统、产品或设备等，没有限定于已列出的步骤或单元，而是可选地还包括没有列出的步骤或单元等，或可选地还包括对于这些过程、方法、产品或设备等固有的其它步骤或单元。
在本文中提及的“实施例”意味着，结合实施例描述的特定特征、结构或特性可以包含在本申请的至少一个实施例中。在说明书中的各个位置出现该短语并不一定均是指相同的实施例，也不是与其它实施例互斥的独立的或备选的实施例。本领域技术人员可以显式地和隐式地理解的是，本文所描述的实施例可以与其它实施例相结合。
本申请以下实施例中所使用的术语只是为了描述特定实施例的目的，而并非旨在作为对本申请的限制。如在本申请的说明书和所附权利要求书中所使用的那样，单数表达形式“一个”、“一种”、“所述”、“上述”、“该”和“这一”旨在也包括复数表达形式，除非其上下文中明确地有相反指示。还应当理解，本申请中使用的术语“和/或”是指并包含一个或多个所列出项目的任何或所有可能组合。例如，“A和/或B”可以表示：只存在A，只存在B以及同时存在A和B三种情况，其中A，B可以是单数或者复数。本申请中使用的术语“多个”是指两个或两个以上。在本申请的文字描述中，字符“/”，一般表示前后关联对象是一种“或”的关系。本申请中使用的术语“至少一个”是指一个或多个。
可以理解，在本申请各实施例中，“A对应的B”表示A与B存在对应关系，根据A可以确定B。但还应理解，根据(或基于)A确定(或生成)B并不意味着仅仅根据(或基于)A确定(或生成)B，还可以根据(或基于)A和/或其它信息确定(或生成)B。
图1为本申请实施例应用的通信系统的架构示意图。如图1所示，该通信系统包括核心网设备110、无线接入网设备120、无线回传设备130和至少一个终端设备(图1中以终端设备140和终端设备150进行示例性描述)。终端设备通过无线的方式与无线回传设备相连，并通过一个或多个无线回传设备与无线接入网设备相连。此外，部分终端设备也可以直接与无线接入网设备通过无线方式相连)。无线接入网设备通过无线或有线方式与核心网设备连接。核心网设备与无线接入网设备可以是独立的不同的物理设备，也可以是将核心网设备的功能与无线接入网设备的逻辑功能集成在同一个物理设备上，还可以是一个物理设备上集成了部分核心网设备的功能和部分的无线接入网设备的功能，本申请对此不作限定。终端设备可以是固定位置的，也可以是可移动的。应理解的是，如图1所示的移动通信系统仅为示意图，该通信系统中还可以包括其它网络设备，例如还可以包括无线中继设备或无线回传设备，在图1中未画出。本申请实施例对该移动通信系统中包括的核心网设备、无线接入网设备、无线回传设备和终端设备的数量不做限定。
其中，无线接入网设备是终端设备通过无线方式接入到该移动通信系统中的接入设备，可以是基站NodeB、演进型基站eNodeB、5G移动通信系统中的基站、未来移动通信系统中的基站或WiFi系统中的接入节点等，本申请的实施例对无线接入网设备所采用的具体技术和具体设备形态不做限定。终端设备也可以称为终端(terminal)、UE、移动台(mobile station，MS)、移动终端(mobile terminal，MT)等。
终端设备可以是手机(mobile phone)、平板电脑(Pad)、带无线收发功能的电脑、虚拟现实(virtual reality，VR)终端设备、增强现实(augmented reality，AR)终端设备、蜂窝电话(cellular phone)、智能电话(smart phone)、无线数据卡、个人数字助理(personal digital assistant，PDA)、工业控制(industrial control)中的无线终端、无人驾驶(self driving)中的无线终端、远程手术(remote medical surgery)中的无线终端、智能电网(smart grid)中的无线终端、运输安全(transportation safety)中的无线终端、智慧城市(smart city)中的无线终端、智慧家庭(smart home)中的无线终端、机器类型通信(machine type communication,MTC)终端、可穿戴设备、车载终端设备、无人机等。
其中，无线回传设备可以为其子节点提供回传服务。具体的，其可以是长期演进(long term evolution，LTE)系统中的中继节点，5G系统中的IAB节点，或者其他能够提供无线中继功能的设备。无线接入网设备和终端设备可以部署在陆地上，包括室内或室外、手持或车载；也可以部署在水面上；还可以部署在 空中的飞机、气球和人造卫星上。本申请的实施例对无线接入网设备和终端设备的应用场景不作限定。
无线接入网设备和终端设备之间以及终端设备和终端设备之间可以通过授权频谱(licensed spectrum)进行通信，也可以通过免授权频谱(unlicensed spectrum)进行通信，也可以同时通过授权频谱和免授权频谱进行通信。无线接入网设备和终端设备之间以及终端设备和终端设备之间可以通过6吉兆赫(gigahertz，GHz)以下的频谱进行通信，也可以通过6GHz以上的频谱进行通信，还可以同时使用6GHz以下的频谱和6GHz以上的频谱进行通信。本申请的实施例对无线接入网设备和终端设备之间所使用的频谱资源不做限定。
上述各网元既可以是在专用硬件上实现的网络元件，也可以是在专用硬件上运行的软件实例，或者是在适当平台上虚拟化功能的实例。此外，本申请实施例还可以适用于面向未来的其他通信技术。本申请描述的网络架构以及业务场景是为了更加清楚的说明本申请的技术方案，并不构成对本申请提供的技术方案的限定，本领域普通技术人员可知，随着网络架构的演变和新业务场景的出现，本申请提供的技术方案对于类似的技术问题，同样适用。
为了便于理解本申请实施例，下面先对本申请实施例中涉及的术语和技术特征作简单说明。
1)IAB网络：考虑到高频段的覆盖范围小，为了保障网络的覆盖性能，在一些偏远地区提供网络覆盖，光纤的部署难度大，成本高，也需要设计灵活便利的接入和回传方案。IAB技术应运而生，其接入链路(access link)和回传链路(backhaul link)皆采用无线传输方案，避免光纤部署，降低了设备成本。
在IAB网络中，中继节点，或者叫IAB节点(IAB-node)，可以为UE提供无线接入服务，UE的业务数据由IAB-node通过无线回传链路连接到IAB宿主节点(IAB-donor)传输。IAB节点可以与一个或多个上级节点建立无线回传链路，并通过上级节点接入核心网。上级节点可通过多种信令对中继节点进行一定的控制(例如，数据调度、定时调制、功率控制等)。另外，中继节点可以与一个或多个下级节点建立接入链路，并为一个或多个下级节点提供接入服务。中继节点的上级节点可以是基站，也可以是另一个中继节点。中继节点的下级节点可以是终端，也可以是另一个中继节点。在某些情形下，一个IAB节点的上级节点也可以称为其上游节点或父节点，该IAB节点的下级节点也可以称为其下游节点或子节点。
在IAB网络中可能采用多跳组网。考虑到业务传输可靠性的需求，IAB节点可以支持双连接(dual connectivity，DC)或者多连接(multi-connectivity)，以应对回传链路可能发生的异常情况(例如，无线链路的中断或阻塞(blockage)及负载波动等)，提高传输的可靠性保障。因此，IAB网络可以支持多跳和多连接组网，在终端设备和宿主基站之间可能存在多条路由路径。其中，在一条路径上，IAB节点之间，以及IAB节点和为IAB节点服务的宿主基站有确定的层级关系，每个IAB节点将为其提供回传服务的节点视为父节点，相应地，每个IAB节点可视为其父节点的子节点。
应理解的是，无线链路的中断(outage)或阻塞(blockage)均可能导致无线链路失败或拥塞。例如，当UE与IAB宿主节点之间存在建筑物遮挡时，可能导致UE与IAB宿主节点之间的无线链路阻塞。现有技术中，无线链路失败的原因主要有当物理层指示无线链路出现问题且超过一定时长或随机接入发生失败或无线链路层控制(radio link control，RLC)失败。应理解的是，无线链路失败还可能有其他原因，本申请实施例对此不做限定。无线链路拥塞可以是指某个IAB节点在某条链路上所要传输的上行或下行缓存数据量超过一定门限。
其中，IAB节点可以包括MT部分(即IAB-node-MT)和DU部分(即IAB-node-DU。其中，当IAB节点面向其父节点时，可以被看作是接入父节点的终端设备，即作为MT的角色；当IAB面向其子节点时，其可被看作是为子节点提供回传服务的网络设备，即作为DU的角色，其中，这里的子节点可能是另一个IAB节点或者终端设备。
IAB宿主节点(IAB-donor)可以是一个具有完整基站功能的接入网网元，例如宿主基站DgNB，还可以是集中式单元(centralized unit，CU)和DU分离形态的接入网网元，IAB宿主节点连接到为终端设备服务的核心网(例如连接到5G核心网)网元，并为IAB节点提供无线回传功能。为便于表述，将IAB宿主节点的集中式单元可简称为donor CU或IAB-donor CU，IAB宿主节点的分布式单元简称为donor DU或IAB-donor DU，其中donor CU还有可能是控制面(control plane，CP)和用户面(user plane，UP)分离的形态，例如CU可由一个CU-CP和一个(或多个)CU-UP组成。
在IAB网络中，在UE和IAB-donor之间的一条传输路径上，可以包含一个或多个IAB-node。每个IAB-node需要维护面向父节点的无线回传链路，还需要维护和子节点的无线链路。若IAB-node的子节点是终端设备，该IAB-node和子节点(即该终端设备)之间是无线接入链路。若IAB-node的子节点是其他IAB-node，该IAB-node和子节点(即其他IAB-node)之间是无线回传链路。图2示出了包括多个UE和 多个IAB节点的IAB网络的一种示例。图2以包括2个UE和5个IAB节点为例。其中，这2个UE分别为UE1和UE2，这5个IAB节点分别为IAB节点1～IAB节点5。应理解，图2粗线示意接入链路，细线示意回传链路。参见图2，在路径“UE1→IAB-node4→IAB-node3→IAB-node1→IAB-donor”中，UE1通过无线接入链路接入IAB-node4，IAB-node4通过无线回传链路连接到IAB-node3，IAB-node3通过无线回传链路连接到IAB-node1，IAB-node1通过无线回传链路连接到IAB-donor。应理解的是，图2所示的IAB组网场景仅仅是示例性的，支持多跳和多连接组网IAB网络中还有更多其他的可能性，此处不再一一列举。
IAB-node-DU(后续简单表述为IAB-DU)在逻辑上通过F1接口连接至IAB-donor CU(后续简单表述为CU)。图3为一种IAB网络架构的示意图。图3中的F1连接并不是物理上的直接连接，是逻辑上的连接。实际上，IAB-DU与CU的F1连接在物理上是通过每一跳的IAB-node MT与父节点DU之间的NR Uu接口实现的，但由于最终IAB-DU能够与CU通信，可以认为在逻辑上存在F1接口。F1接口也可以称为F1*接口，本申请实施例对该接口的名称不作限制。且本文中以该接口称为F1接口为例。IAB-donor CU通过NG接口连接到5G核心网(5G core network，5GC/5GCN)。IAB-donor CU与gNodeB之间有Xn-C接口。
F1接口可支持用户面协议(F1-U/F1*-U)和控制面协议(F1-C/F1*-C)，用户面协议包括以下协议层的一个或多个：通用分组无线服务(general packet radio service，GPRS)隧道协议用户面(GPRS tunnelling protocol user plane，GTP-U)协议层，用户数据报协议(user datagram protocol，UDP)协议层、因特网协议(internet protocol，IP)协议层等；控制面协议包括以下协议层中的一个或者多个：F1应用协议(F1application protocol，F1AP)、流控传输协议(stream control transport protocol，SCTP)、IP协议层等。通过F1/F1*接口的控制面，IAB节点和IAB宿主之间可以进行执行接口管理、对IAB-DU进行管理，以及执行UE上下文相关的配置等。通过F1/F1*接口的用户面，IAB节点和IAB宿主之间可以执行用户面数据的传输，以及下行传输状态反馈等功能。
示例性的，请参见图4和图5，其中图4为IAB网络中的控制面协议架构的示意图，图5为IAB网络中的用户面协议架构的示意图。
对于控制面而言，如图4所示，UE1和IAB2-DU之间建立有Uu接口，对等的协议层包括无线链路层控制协议(radio link control，RLC)层、媒体介入控制层(media access control，MAC)层和物理层(physical layer，PHY)层。IAB2-DU和IAB donor CU 1建立有F1-C接口，对等的协议层包括F1AP层、SCTP层。IAB donor DU 1和IAB donor CU 1之间通过有线连接，对等的协议层包括互联网协议(internet protocol，IP)层、L2和L1。IAB节点2和IAB节点3之间、IAB节点3和IAB节点1之间，以及IAB节点1和IAB donor DU 1之间均建立有BL，对等的协议层包括回传适配协议(bakhaul adaptation protocol，BAP)层、RLC层、MAC层以及PHY层。另外，UE1和IAB donor CU 1之间建立有对等的无线资源控制(radio resource control，RRC)层和分组数据汇聚协议(packet data convergence protocol，PDCP)层，IAB2-DU和IAB donor DU 1之间建立有对等的IP层。
可以看出，IAB网络的控制面协议栈与单空口的控制面协议栈相比，接入IAB节点的DU实现了单空口的gNB-DU的功能(即与UE建立对等RLC层、MAC层和PHY层的功能，以及与CU建立对等的F1AP层、SCTP层的功能)。也就是说，IAB网络中接入IAB节点的DU实现了单空口的gNB-DU的功能；IAB donor CU实现了单空口的gNB-CU的功能。
在控制面上，RRC消息封装在接入IAB节点和IAB donor CU之间的F1AP消息中传输。具体地，在上行方向上，UE1将RRC消息封装在PDCP协议数据单元(protocol data unit，PDU)中，并依次经过RLC层、MAC层和PHY层的处理后发送至IAB2-DU。IAB2-DU依次经过PHY层、MAC层和RLC层的处理后得到PDCP PDU，将PDCP PDU封装在F1AP消息中，并依次经过SCTP层、IP层处理后得到IP包。IAB2-MT将IP包分别通过BAP层、RLC层、MAC层和PHY层的处理后发送至IAB3-DU。IAB3-DU依次经过PHY层、MAC层、RLC层和BAP层的处理后得到IP包，然后IAB3-MT采用类似于IAB2-MT的操作，将该IP包发送至IAB1-DU。同理，IAB1-MT将该IP包发送至IAB donor DU 1。IAB donor DU 1解析得到IP包后，将该IP包发送至IAB donor CU 1，IAB donor CU 1将该IP包依次通过SCTP层、F1AP层和PDCP层的处理后得到RRC消息。下行方向类似，在此不再描述。
对于用户面而言，如图5所示，UE1和IAB2-DU之间建立有Uu接口，对等的协议层包括RLC层、MAC层和PHY层。IAB2-DU和IAB donor CU 1建立有F1-U接口，对等的协议层包括GTP-U层、用户数据报协议(user datagram protocol，UDP)层。IAB donor DU 1和IAB donor CU 1之间通过有线连接，对等的协议层包括IP层、L2和L1。IAB节点2和IAB节点3之间、IAB节点3和IAB节点1之间，以及IAB 节点1和IAB donor DU 1之间均建立有BL，对等的协议层包括BAP层、RLC层、MAC层以及PHY层。另外，UE1和IAB donor CU 1之间建立有对等的SDAP层和PDCP层，IAB2-DU和IAB donor DU 1之间建立有对等的IP层。
可以看出，IAB网络的用户面协议栈与单空口的用户面协议栈相比，IAB接入节点的DU实现了单空口的gNB-DU的部分功能(即与终端建立对等RLC层、MAC层和PHY层的功能，以及与IAB donor CU 1建立对等的GTP-U层、UDP层的功能)。可以理解，IAB接入节点的DU实现了单空口的gNB-DU的功能；IAB donor CU实现了单空口的gNB-CU的功能。
在用户面上，PDCP数据包封装在接入IAB节点和IAB donor CU之间的GTP-U隧道中传输。GTP-U隧道建立在F1-U接口上。
图6示出一种IAB网络架构的示意图，包括独立组网(SA)的IAB网络，以及非独立组网(NSA)的IAB网络。IAB node包含MT部分和DU部分，图6中以，IAB node1和IAB node2为例来说明，IAB donor可以进一步分为DU和CU部分，CU还可分为CU-CP和CU-UP部分，图6中以IAB donor1和IAB donor2为例来说明。
每个IAB节点的DU部分，与IAB donor CU之间有F1接口，该F1接口包含控制面和用户面两部分，其中用户面的部分是IAB-DU与IAB donor CU-UP之间维护的，而控制面部分是IAB-DU与IAB donor CU-CP之间维护的。IAB-DU和IAB donor CU之间的F1接口，在图6中未示出。其中，UE与IAB node的DU通过NR Uu接口连接，各IAB node中的MT和DU通过NR BH接口连接。IAB donor CU-CP与IAB donor CU-UP之间通过E1接口连接。
在IAB节点工作在SA模式时，IAB node可以单连接到一个父节点，或者双连接到两个父节点，其中这两个父节点可以由同一个IAB donor控制，或者分别由不同的IAB donor控制。IAB node的DU部分与一个IAB donor之间建立F1接口即可，该IAB donor可以连接到5G核心网(5G core，5GC)，即图中的虚线部分。其中IAB-donor-CU-CP与通过NG控制面接口(NG-C)连接到5GC中的控制面网元(例如接入和移动性管理功能AMF)，其中IAB-donor-CU-UP与通过NG用户面接口(NG-U)连接到5GC中的用户面网元(例如用户面功能UPF)。
当IAB节点工作在NSA模式(或者说EN-DC模式)时，IAB-donor-CU-UP可以通过S1用户面接口连接到EPC(例如连接到业务网关(serving gateway，SGW))，MeNB与IAB node的MT之间有LTE Uu空口连接，MeNB与IAB-donor-CU-CP之间有X2/Xn-C接口，MeNB通过S1接口连接到EPC(包括S1接口用户面，以及S1接口控制面)。如，IAB-donor-CU-UP与EPC之间通过S1接口用户面(S1-U)连接。
另一种可能的情况，图6中的MeNB也可以换成5G的基站gNB，图6中的虚线LTE-Uu接口相应的被替换为NR-Uu接口，gNB可以和5GC之间建立用户面和/或控制面的接口，gNB和IAB-donor为IAB节点提供双连接服务，gNB可以作为IAB节点的主基站的角色，或者辅基站的角色。
2)部分迁移(partial migration)和完全迁移(full migration)
在3GPP版本17(Release-17)的讨论中，将IAB节点跨CU迁移分为full migration和partial migration两种实现方式。其中，full migration又包括逐步自顶向下(gradual top-down)、逐步自低向上(gradual bottom-up)和完全嵌套(full nested)三种实现方式。在partial migration中，IAB节点的MT发生了跨CU切换，但该IAB节点的DU仍然与源CU保持F1连接；而在full migration中，IAB节点的DU需要与目标CU建立F1连接。Rel-17主要面向以负载均衡为出发点的IAB节点的迁移，因此可以采用partial migration，只通过切换MT，使得F1接口换一条路径传输，但不改变F1接口的锚点。而Rel-18中主要面向因IAB节点移动导致的迁移，在IAB节点移动范围较大时，仍然与源CU维持F1连接是不合适的，F1连接的锚点也需要变化到目标CU上。因此，full migration是Rel-18移动IAB的必选特性。下面将对partial migration和full migration讨论现状进行简要介绍。
发生迁移的IAB节点称为边界节点(boundary node)。图7为一种partial migration的示意图。参阅图7，IAB-node2为边界节点，IAB-node2在进行partial migration之前，IAB-MT2与CU1之间存在RRC连接，IAB-DU2与CU1之间存在F1接口，IAB-node2与IAB-donor通过源路径(经过由IAB-MT1和IAB-DU1构成的IAB-node1)进行通信，参阅带箭头的实线。IAB-node2在partial migration时，IAB-MT2发生了跨CU的小区切换，与CU2建立了RRC连接，但为了避免引入F1接口的重建立过程，IAB-DU2仍然与CU1保持F1接口，并不会与CU2建立F1接口。因此，CU1与IAB-DU2之间的通信路径变为了跨拓扑的：参阅带箭头的虚线。图7中，CU1和CU2分别称为F1-terminating CU和non-F1-terminating CU。需要注意的是，数据在这条路径上传输时并不经过 CU2，CU1与Donor-DU2是直接通过IP网络通信的。在partial migration中，核心的交互信令是CU1与CU2之间的XN消息：IAB TRANSPORT MANAGEMENT REQUEST/RESPONSE消息，参阅标准TS 38.423V17.2.0 Section 9.4.2,Section 9.4.3。CU1通过IAB TRANSPORT MANAGEMENT REQUEST消息请求CU2帮助它建立跨拓扑的流量传输，其中携带流量的IP地址和服务质量(quality of service，QoS)信息；CU2建立好跨拓扑的流量传输之后，将边界节点的MT的回传链路(backhaul)信息(位于CU2下的虚线框中的拓扑)通过IAB TRANSPORT MANAGEMENT RESPONSE消息返回给CU1，CU1基于边界节点的MT的backhaul信息，通过F1AP给边界节点配置跨拓扑的BAP规则。IAB TRANSPORT MANAGEMENT REQUEST/RESPONSE是UE关联(associated)的XN消息，关联到(associated to)边界节点的MT，因此在这两条消息中，都需要携带边界节点的MT在CU1下的XNAP ID和在CU2下的XNAP ID，用于标识这个MT。
图8为一种full migration的示意图。参阅图8，IAB-node3为边界节点，在full migration中，需要将IAB-DU3与CU1之间的F1接口迁移至CU2。由于协议不支持一个DU与两个CU同时存在F1接口，现有的实现方案中，通过将IAB-DU3扩展为两个逻辑DU，即IAB-DU3a(可简称为DU3a)和IAB-DU3b(即新的逻辑DU)，IAB-DU3a始终维持与CU1之间的F1接口，而IAB-DU3b(可简称为DU3b)用于与CU2建立新的F1接口，DU3a与DU3b可以视为两个DU，各自存在F1接口，UE需要做一次切换，由IAB-DU3a下的小区切换至IAB-DU3b的小区之下。在三种full migration的实现方式中：
gradual top-down的前几步与partial migration类似，首先按照partial migration的过程，切换IAB-MT3(可简称为MT3)，建立DU3a与CU1之间的跨拓扑F1-C和F1-U，CU2在帮助建立DU3a与CU1之间的跨拓扑F1-C和F1-U时，也建立DU3b与CU2之间的F1-C和F1-U，然后将UE切换至DU3b下，UE可直接在目标路径(target path)上与CU2通信。目标路径是指
在gradual bottom-up中，首先通过建立DU3b与CU2之间的跨拓扑F1-C和F1-U，使得UE能够切换到DU3b之下，建立DU3b与CU2之间通过拓扑1的控制面和用户面数据传输，在所有UE切换成功后，再向MT3发送切换命令或生效MT3的切换命令，然后在target path上建立F1-C/U，使得UE的流量能够迁移到target path。拓扑1是指建立DU3b与CU2之间通过拓扑1的控制面和用户面数据传输需要在DU3b与donor-DU1上，以及在二者之间的中间跳节点(如果有)上建立回传链路资源(BH RLC CH)，并进行BAP层的配置，使得这些相关节点上能够有相应的资源用于传输控制面与用户面数据，且每一个相关节点的BAP层都知道如何进行数据包到资源的映射。
full nested情况与gradual bottom-up类似，首先通过建立DU3b与CU2之间的跨拓扑F1-C(只建立跨拓扑F1-C，用于CU2做切换判决时允许将UE切到DU3b之下，但不建立跨拓扑F1-U，不进行跨拓扑数据传输)，使得UE能够允许切换到DU3b之下，在向所有UE发送切换命令后，马上向MT3发送切换命令或生效MT3的切换命令，然后直接在target path上建立F1-C/U，使得UE的流量能够迁移到target path。
3)连续partial migration中的DU迁移
full migration与partial migration的本质区别在于是否需要进行DU的迁移(事实上，是生成一个新的逻辑DU再与目标(target)CU建立F1接口，但从IAB节点的宏观角度考虑，通常也可以表述为“DU的迁移”)。在Rel-18 mobile IAB的立项文件中，将full migration作为必选特性。然而，这也并不意味着IAB节点每一次迁移都需要做full migration。在Rel-18前几次会议的讨论中，主流观点是以连续的partial migration作为基线，在需要进行DU迁移的时候，再进行DU的迁移。图9为一种连续partial migration(不迁移DU)的场景的示例。如图9所示。mIAB(mobile IAB)-MT由CU1拓扑切换至CU2下的拓扑，又由CU2切换至CU3下的拓扑，mIAB-DU始终与CU1维持F1连接。根据RAN3#117b e-meeting的结论，由mIAB-DU的F1锚点的CU(即CU1)决定是否需要做DU的迁移。图10为本申请实施例提供的一种连续partial migration中迁移DU的场景的示例。图10给出了当mIAB-MT从CU2下的拓扑迁移到CU3下的拓扑时，CU1决定进行DU迁移的情况，与full migration类似，mIAB-node需要生成一个新的逻辑DU(mIAB-DU2)，与CU3建立F1接口，然后将UE从mIAB-DU1下的小区切换至mIAB-DU2下的小区。图9与图10中，mIAB-MT直接连到donor-DU，但仅是示意，mIAB-MT也可以连接到其他固定的IAB-DU，通过多跳到达donor-DU，本申请实施例不进行限定。
4)小区标识：可通过PCI或全球小区标识(cell global identifier，CGI)来指示，是小区重要参数。每个小区会对应一个小区标识，用于区分不同的小区，基于小区标识可进行下行信号的同步、信号解调以及信号切换。在此以小区标识为PCI为例来具体说明。5G中一共包括1008个PCI，其中10008个PCI被分 为336个组，每组包括3个PCI，如下所示：
其中，
参阅表1，5G的PCI相对LTE的主要区别如下：
表1
PCI规划主要遵循原理如下：
a)、相邻小区不能分配相同的PCI。若邻近小区分配相同的PCI，会导致UE在重叠覆盖区域无法检测到邻近小区，影响切换、驻留。
b)、服务小区的频率相同，相邻小区不能分配相同的PCI，若分配相同的PCI，则当UE上报邻区PCI到源小区所在的基站时，源基站无法基于PCI判断目标切换小区。
基于3GPP PUSCH DMRS ZC序列组号与PCI mode30相关；对于PUCCH解调参考信号(demodulation reference signal，DMRS)、信道探测参考信号(sounding reference signal，SRS)，算法使用PCI mode30作为高层配置ID，选择序列组。所以，相邻小区的PCI mode30应尽量错开，保证上行信号的正确解调。
在IAB网络中，小区标识可通过运营管理和维护(operation administration and maintenance，OAM)配置，或者是IAB节点与CU建立F1接口后，将配置好的小区标识上报至CU，或者是CU基于IAB节点上报的小区标识以及其他信息，重新配置小区标识，在此不具体说明，总而言之，该小区标识为预先配置的。
在R16/17中IAB节点是固定设置在某个位置，也即静态部署的，R18中IAB节点可以安装在车上，随车辆一起移动，如图11所示。图11示出了一种移动IAB节点的示意图。如车辆VMR1在gNB1下接收服务，车辆VMR1搭载有IAB节点1，IAB节点1下属配置的小区标识为PCI#1，VMR1在移动过程中，移动到gNB2下接收服务，gNB2还为车辆VMR2提供服务，若VMR2搭载的IAB节点2下属也配置有小区标识PCI#1，那么两个小区标识相同，则会发生小区碰撞，影响通信质量。由此可知，现有的静态PCI配置方法不再适用，针对R18移动IAB场景，若使用静态的PCI，在IAB小区移动的过程中，可能会与邻区的PCI发生冲突，亟需一种新的小区标识配置方法以避免信号碰撞的情况出现。
根据上文的介绍，现有会议结论只给出了在连续partial migration中由第一CU(即边界节点的源CU)决定是否做DU的迁移，但第一CU依据什么决定是否迁移DU？会议结论没有给出具体方案。会议结论也未给出如何在连续partial migration中迁移DU的方案，以及第一CU何时决定是否迁移DU。本申请实施例提供的IAB网络中的DU迁移方案可解决上述三个问题，是实现连续partial migration中的DU迁移的完整方案。
下面结合附图描述本申请实施例提供的IAB网络中的DU迁移方案。
图12为本申请实施例提供的一种IAB网络中的DU迁移方法交互流程图。图12中的方法适用于连续partial migration中迁移DU的场景。图12中，mIAB-MT表示IAB节点的MT，mIAB-DU1表示IAB节点 的DU，mIAB-DU2表示IAB节点的新的逻辑DU，后续其他图中的各网元的含义可参阅图12中的含义。如图12所示，该方法包括：
1201、第二CU向第一CU发送第一消息。
相应的，第一CU接收来自第二CU的第一消息。第一消息包括用于在第三CU中标识IAB节点的MT的ID和第三CU的ID。例如，用于在第三CU中标识IAB节点的MT的ID可以是IAB节点在第三CU下的XNAP ID。或者，第一消息包括第三CU的IP地址或者第三CU管理的宿主DU的IP地址，以及用于在第三CU中标识IAB节点的MT的ID。第一消息可以是XN消息。例如，第一消息可称为DU migration query消息。在一种可能的实现中，第二CU向第一CU发送该第一消息的触发条件为第二CU收到第三CU发来的：1)关于MT的HANDOVER REQUEST ACKNOWLEDGE(表明MT将要切换)，或2)关于MT的UE CONTEXT RELEASE(表明MT已完成从第二CU至第三CU切换)，或3)关于MT的RETRIEVE UE CONTEXT REQUEST(MT已完成无线链路失败的恢复)。MT已完成无线链路失败(radio link failure)的恢复(recovery)可以是MT与第二CU之间发生无线链路失败且接入第三CU下的拓扑。HANDOVER REQUEST ACKNOWLEDGE可参见标准TS 38.423 V17.2.0 Section 9.1.1.2。UE CONTEXT RELEASE可参见标准TS 38.423 V17.2.0 Section 9.1.1.5。RETRIEVE UE CONTEXT REQUEST可参见标准TS 38.423 V17.2.0 Section 9.1.1.8。
或者说，第二CU向第一CU发送该第一消息的触发条件为接收到来自第三CU的第八消息。第八消息用于指示IAB节点的MT将切换至第三CU下的拓扑、MT已切换至第三CU下的拓扑、或者MT在与第二CU之间发生无线链路失败之后已接入第三CU下的拓扑中的任一项。例如，第八消息为关于MT的HANDOVER REQUEST ACKNOWLEDGE、UE CONTEXT RELEASE或RETRIEVE UE CONTEXT REQUEST。
MT与第二CU之间具有RRC连接，表明MT切换至第二CU下的拓扑且未切换至第三CU下的拓扑。例如，MT由第一CU下的拓扑切换至第二CU下的拓扑，IAB节点与第一CU维持F1连接，这时MT与第二CU之间具有RRC连接。或者，第三CU下的拓扑为MT从第二CU的拓扑下变换至的拓扑。例如，MT由第一CU下的拓扑切换至第二CU下的拓扑，又从第二CU下的拓扑切换至第二CU下的拓扑，这时第三CU下的拓扑为MT从第二CU的拓扑下变换至的拓扑。又例如，MT由第一CU下的拓扑切换至第二CU下的拓扑，MT与第二CU之间发生RLF，然后执行RLF Recovery流程，重新接入第三CU的拓扑下，这时第三CU下的拓扑为MT从第二CU的拓扑下变换至的拓扑。
1201’、第三CU向第一CU发送第一消息。
相应的，第一CU接收来自第三CU的第一消息。步骤1201’中的第一消息可与步骤1201中的第一消息相同。第一消息可以是XN消息。例如，第一消息可称为DU migration query消息。在一种可能的实现中，第三CU向第一CU发送该第一消息的触发条件为：1)第三CU向第二CU发送关于MT的HANDOVER REQUEST ACKNOWLEDGE，或2)第三CU向第二CU发送UE CONTEXT RELEASE；或3)第三CU收到第二CU发来的关于MT的RETRIEVE UE CONTEXT RESPONSE。而由于这是一条第三CU与第一CU之间的XN消息，这条XN消息需要携带MT在第一CU与第三CU下的XNAP ID。或者说，第三CU向第一CU发送该第一消息的触发条件为：向第二CU发送第九消息或接收来自第二CU的第十消息。第九消息用于指示MT将切换至第三CU下的拓扑或者MT已变换至第三CU下的拓扑。例如，第九消息为关于MT的HANDOVER REQUEST ACKNOWLEDGE、UE CONTEXT RELEASE或RETRIEVE UE CONTEXT REQUEST。第十消息用于指示MT已变换至第三CU下的拓扑。例如，第十消息为RETRIEVE UE CONTEXT RESPONSE。
1201”、IAB节点的DU向第一CU发送第一消息。
相应的，第一CU接收来自IAB节点的DU的第一消息。步骤1201”中的第一消息可以为F1消息，例如携带用于在第三CU中标识IAB节点的MT的ID和第三CU的ID的gNB-DU Configuration update消息。也就是说，可以复用现有的gNB-DU Configuration update消息携带用于在第三CU中标识IAB节点的MT的ID和第三CU的ID作为第一消息。IAB节点的DU向第一CU发送第一消息的触发条件可以是：IAB节点的MT从第二CU的拓扑下切换至第三CU的拓扑下。
步骤1201、步骤1201’、步骤1201”是三种可能的实现方式。第一CU可能接收来自第二CU的第一消息，也可能接收来自第三CU的第一消息，还可能接收来自IAB节点的DU的第一消息。应理解，图12中的方法流程中包括步骤1201、步骤1201’、或者步骤1201”中的任一个，本申请实施例不作限定。第一消息可视为触发第一CU决定是否要迁移IAB节点的DU的条件。在一种可能的实现方式中，第一消息用 于指示MT将从第二CU下的拓扑切换至第三CU下的拓扑、MT已完成从第二CU下的拓扑至第三CU下的拓扑的切换、或者MT与第二CU之间发生无线链路失败且接入第三CU下的拓扑下中的任一项。例如，第一消息包括第三CU的ID和IAB节点在第三CU下的XN AP ID。又例如，第一消息包括第三CU的IP地址和IAB节点在第三CU下的XN AP ID。又例如，第一消息包括第三CU管理的宿主DU的IP地址和IAB节点在第三CU下的XN AP ID。又例如，第一消息包括第三CU的ID、第三CU的IP地址和IAB节点在第三CU下的XN AP ID。又例如，第一消息包括第三CU的ID、第三CU管理的宿主DU的IP地址和IAB节点在第三CU下的XN AP ID。又例如，第一消息包括第三CU的IP地址、第三CU管理的宿主DU的IP地址和IAB节点在第三CU下的XN AP ID。又例如，第一消息包括第三CU的ID、第三CU的IP地址、第三CU管理的宿主DU的IP地址和IAB节点在第三CU下的XN AP ID。第一CU接收到第一消息，可获知MT将从第二CU下的拓扑切换至第三CU下的拓扑、MT已完成从第二CU下的拓扑至第三CU下的拓扑的切换、或者MT与第二CU之间发生无线链路失败且接入第三CU下的拓扑下中的任一项。在该实现方式中，可及时触发第一CU决定是否要迁移IAB节点的DU。
1202、第一CU根据第一消息，确定是否要进行IAB节点的DU的迁移。
确定是否要进行IAB节点的DU的迁移可写成：确定是否要迁移IAB节点的DU。步骤1202一种可能的实现方式如下：根据第一消息，确定第一CU是否能够不通过核心网到达第三CU或第三CU管理的宿主DU。或者说，根据第一消息，确定第一CU是否能够通过不包括核心网的IP网络到达第三CU或第三CU管理的宿主DU。本申请实施例不限定根据第一消息，确定第一CU是否能够不通过核心网到达第三CU或第三CU管理的宿主DU的方式。例如，网管向第一CU配置一张能够不通过核心网直接到达的网络节点的表格，CU查询所述表格，确定能否不通过核心网到达第三CU或第三CU管理的宿主DU。
步骤1202一种可能的实现方式如下：根据第一消息，确定第一CU是否能够与第三CU建立XN接口。本申请实施例不限定根据第一消息，确定第一CU是否能够与第三CU建立XN接口的方式。例如，第一CU尝试向第三CU发起XN接口建立请求，如果第一CU获得允许XN接口建立的响应，则第一CU认为能与第三CU建立XN接口，否则第一CU认为不允许与第三CU建立XN接口。
步骤1202一种可能的实现方式如下：根据第一消息，确定第一CU是否能够通过IP路由的方式到达第三CU或第三CU管理的宿主DU。或者说，根据第一消息，确定第一CU与第三CU或第三CU管理的宿主DU是否是IP可达的(IP routable)。本申请实施例不限定根据第一消息，确定第一CU是否能够通过IP路由的方式到达第三CU或第三CU管理的宿主DU的方式。例如，第一CU查询IP路由表，如果其中有关于第三CU或第三CU管理的donor-DU的项(如：能够根据第三CU或第三CU管理的donor-DU的IP地址查询到下一跳IP地址)，则认为IP可达，否则认为IP不可达。
1203、在确定要进行IAB节点的DU迁移的情况下，第一CU向IAB节点的DU发送第二消息。
相应的，IAB节点的DU接收来自第一CU的第二消息。第二消息用于指示IAB节点的DU与第三CU建立F1接口。例如，第二消息用于指示IAB节点或IAB节点的DU生成一个新的逻辑DU，并通过新的逻辑DU与第三CU建立F1接口，即建立新的逻辑DU与第三CU之间的F1接口。第二消息可称为DU迁移命令(migration command)。
1204、IAB节点的DU根据第二消息，与第三CU建立F1接口。
第二消息可包括第三CU的ID。步骤1204一种可能的实现方式如下：IAB节点的DU根据第二消息，生成一个新的逻辑DU，并通过新的逻辑DU与第三CU建立F1接口。例如，IAB节点的DU生成新的逻辑DU后，根据第二消息中携带的第三CU的ID，由新的逻辑DU向第三CU发起F1建立请求消息(F1SETUP REQUEST)。
步骤1203和步骤1204是可选的。步骤1203和步骤1204可替换为下文的步骤1203’，也可替换为步骤1203”和步骤1204”。应理解，图12中的方法流程中包括步骤1203至步骤1204、步骤1203’、或者步骤1203”至步骤1204”中的任一种，本申请实施例不作限定。
1203’、在确定不进行IAB节点DU迁移的情况下，第一CU向第三CU发起部分迁移中的IAB传输迁移管理流程。
步骤1203’是可选的。IAB传输迁移管理(IAB TRANSPORT MIGRATION MANAGEMENT)流程用于流量的跨拓扑迁移。IAB TRANSPORT MIGRATION MANAGEMENT流程可参见标准TS 38.423 V17.2.0 Section 9.4.2,Section 9.4.3。
步骤1203’的目的是实现partial migration。在一种可能的实现方式中，第一CU向第三CU发起的部分迁移中的IAB传输迁移管理流程为标准中的IAB传输迁移管理流程。在一种可能的实现方式中，第一CU 向第三CU发起的部分迁移中的IAB传输迁移管理流程与标准中的IAB传输迁移管理流程相比，将XN接口上的IAB TRANSPORT MIGRATION MANAGEMENT REQUEST/RESPONSE消息中的关键信元在NG接口上的新消息(即下文的第六消息和第七消息)中传递，下文再详述该实现方式。例如，第一CU向接入和移动性管理功能网元(例如AMF)发送第六消息，该第六消息包括IAB节点的流量在第三CU下的IP地址以及IAB节点的流量的QoS信息；第一CU接收来自接入和移动性管理功能网元的第七消息，第七消息包括第三CU下的回传链路(backhaul)信息，以及IAB节点的流量的DSCP或流标签(Flow Label)信息。回传链路(backhaul)信息可参见标准TS 38.423 V17.2.0 Section 9.2.2.83。
1203”、在确定要进行IAB节点的DU迁移的情况下，第一CU向第二CU发送第三消息。
第三消息用于请求第二CU在其拓扑内为IAB节点的DU生成的新的逻辑DU与第三CU之间的F1接口配置资源。第三消息还可用于请求第二CU暂时不要迁移IAB节点的MT。例如，第三消息用于请求第二CU暂时不要迁移IAB节点的MT，并为IAB节点的DU生成的新的逻辑DU与第三CU之间的F1接口配置资源，该F1接口为经过第二CU下的拓扑(donor-DU2)，且终结在第三CU上的跨拓扑的F1接口。第三消息携带MT在第一CU的XNAP ID。可选的，第三消息还携带第三CU的gNB ID。第三CU的gNB ID之所以是可选的，是因为第一CU可能不一定需要知道这个F1接口是为哪个CU建立的，只需要在其拓扑内配置服务于这一F1接口的资源即可。第三消息可以为XN消息。第三消息可称为Other node F1 setup request，表示这个F1接口不是建立在第二CU上的，而是帮助其他节点建立的。需要注意，本申请实施例对各消息的名称不作限定。
1204”、第二CU根据第三消息，在其拓扑内为IAB节点的DU生成的新的逻辑DU与第三CU之间的F1接口配置资源。
步骤1203”和步骤1204”是可选的。
本申请实施例中，第一CU接收到第一消息之后，根据第一消息确定是否要进行IAB节点的DU的迁移。第一CU接收到第一消息为第一CU决定是否迁移IAB节点的DU的触发条件，因此给出了第一CU决定是否迁移IAB节点的DU的触发条件。根据第一消息，确定是否要进行IAB节点的DU的迁移。可见，本申请实施例还给出了第一CU决定是否迁移IAB节点的DU的依据。在确定要进行IAB节点的DU迁移的情况下，向IAB节点发送第二消息为本申请实施例提供的DU迁移方式。本申请实施例中的方案可支持因MT发生拓扑变化而触发的DU迁移，解决了现有技术不支持的连续partial migration的过程中迁移DU的问题。
图13为本申请实施例提供的另一种IAB网络中的DU迁移方法交互流程图。图13中的方法流程是图12描述的方法的一种可能的实现方式。如图13所示，该方法包括：
1301、第二CU向第三CU发送消息1。
相应的，第三CU接收到来自第二CU的消息1。消息1用于请求将MT切换至第三CU下的拓扑。消息1可以为MT HO request。消息1可包括MT在第一CU下的XNAP ID(对于执行步骤1305’的情况需携带，具体原因将在步骤1305’中给出)。第二CU是知道MT在第一CU下的XNAP ID的。原因在于，当IAB节点的MT从第一CU迁移到第二CU时，已经经过了Handover Preparation的交互以及IAB TRANSPORT MIGRATION MANAGEMENT的流量迁移过程，因此第二CU是知道第一CU的XNAP ID的。Handover Preparation流程包括Handover Request消息和Handover Request Acknowledge消息的交互。
1302、第三CU向第二CU发送消息2。
相应的，第二CU接收来自第三CU的消息2。消息2可以为关于MT的HANDOVER REQUEST ACKNOWLEDGE。消息2可视为第三CU针对消息1向第二CU回复的消息。消息2可包括MT在第二CU下的XNAP ID、MT在第三CU下的XNAP ID、MT在第三CU下的IP地址(MT’s IP address under第三CU)。可选的，消息2携带第三CU管理的宿主DU或第三CU的IP地址。第三CU管理的宿主DU的IP地址可以为第三CU通过MT的目标小区归属的donor-DU得出(理论上一个donor-CU下可以挂多个donor-DU)。这里携带IP地址的作用是用于后续第一CU判断是否与第三CU管理的宿主DU或第三CU之间存在IP通路。而可选非必选的原因是第一CU也可以通过内部实现，例如根据第三CU的gNB ID判断与第三CU管理的宿主DU或第三CU之间存在IP通路。
1303、IAB节点的MT与第三CU执行MT切换操作。
步骤1303可理解为IAB节点的MT与第三CU执行MT切换的后续步骤。步骤1303可通过现有的技术实现，这里不再赘述。
1304、第三CU向第二CU发送消息3。
消息3用于指示第二CU释放关于IAB节点的MT的UE上下文。例如，消息3为UE CONTEXT RELEASE。
1301’、第三CU向第二CU发送消息4。
相应的，第二CU接收来自第三CU的消息4。消息4用于从第二CU处索要关于IAB节点的MT的UE上下文。消息4包括MT在第二CU下的XNAP ID、MT在第三CU下的XNAP ID。可选的，消息4包括第三CU的IP地址或第三CU管理的宿主DU的IP地址。例如，消息4为RETRIEVE UE CONTEXT REQUEST。在一种可能的实现中，MT与第二CU之间发生RLF，然后执行RLF Recovery流程，重新接入第三CU的拓扑下，然后第三CU向第二CU发送消息4。
1302’、第二CU向第三CU发送消息5。
相应的，第三CU接收来自第二CU的消息5。可选的，消息5携带MT在第一CU下的XNAP ID(对于执行下文的步骤1305’的情况需携带，具体原因将在步骤1305’中给出)。例如，消息5为RETRIEVE UE CONTEXT RESPONSE。
步骤1301至步骤1304，与步骤1301’至步骤1302’是两种不同的实现方式。应理解，图13中的方法流程中包括步骤1301至步骤1304，或者包括1301’步骤1302’，本申请实施例不作限定。
1305、第二CU向第一CU发送第一消息。
第一消息包括第三CU的ID、MT在第一CU下的XNAP ID、MT在第二CU下的XNAP ID、MT在第三CU下的XNAP ID。可选的，第一消息包括第三CU的IP地址或者第三CU管理的宿主DU的IP地址。第二CU向第一CU发送第一消息的触发条件可以为如下任一种：第二CU接收到来自第三CU的消息2；第二CU接收到来自第三CU的消息3；第二CU接收到来自第三CU的消息4。例如，图13中的方法流程包括步骤1301至步骤1304，第二CU在接收到来自第三CU的消息2之后，执行步骤1305，第二CU执行步骤1303和步骤1305的先后顺序不作限定。又例如，图13中的方法流程包括步骤1301至步骤1304，第二CU在接收到来自第三CU的消息3之后，执行步骤1305。又例如，图13中的方法流程包括步骤1301’至步骤1302’，第二CU在接收到来自第三CU的消息4之后，执行步骤1305,第二CU执行步骤1302’和步骤1305的先后顺序不作限定。
1305’、第三CU向第一CU发送第一消息。
步骤1305’中的第一消息可与步骤1305中的第一消息相同，这里不再赘述。第三CU向第一CU发送第一消息的触发条件可以为如下任一种：第三CU向第二CU发送消息2；第三CU向第二CU发送消息3；第三CU向第二CU发送消息4；第三CU接收到来自第二CU的消息1；第三CU接收到来自第二CU的消息5。例如，图13中的方法流程包括步骤1301至步骤1304，第三CU向第二CU发送消息2之后，执行步骤1305’，第三CU执行步骤1305’和步骤1303的先后顺序不作限定。例如，图13中的方法流程包括步骤1301至步骤1304，第三CU向第二CU发送消息3之后，执行步骤1305’。例如，图13中的方法流程包括步骤1301至步骤1304，第三CU接收来自第二CU的消息1之后，执行步骤1305’，第三CU执行步骤1305’和步骤1302的先后顺序不作限定。例如，图13中的方法流程包括1301’至步骤1302’，第三CU向第二CU发送消息4之后，执行步骤1305’。例如，图13中的方法流程包括1301’至步骤1302’，第三CU接收到来自第二CU发送的消息5之后，执行步骤1305’。由于第一消息为第三CU与第一CU之间的XN消息，这条XN消息需要携带MT在第一CU与第三CU下的XNAP ID，MT在第一CU下的XNAP ID由步骤1301的消息1或步骤1302’的消息5携带，因此对于步骤1302’，这是必需的。
应理解，步骤1305和步骤1305’是第一CU两种可能的接收到第一消息的实现方式。图13中的方法流程中包括步骤1305或者步骤1305’。上文例举了步骤1301至步骤1304与步骤1305结合的例子，以及1301’至步骤1302’与步骤1305结合的例子。上文还例举了步骤1301至步骤1304与步骤1305’结合的例子，以及1301’至步骤1302’与步骤1305’结合的例子。
1306、第一CU根据第一消息，确定是否要进行IAB节点的DU的迁移。
步骤1306可参阅步骤1202。
1307、在确定要进行IAB节点的DU迁移的情况下，第一CU向IAB节点的DU发送第二消息。
步骤1307可参阅步骤1203。
1308、IAB节点的DU根据第二消息，与第三CU建立F1接口。
步骤1308可参阅步骤1204。步骤1307和步骤1308是可选的。步骤1307和步骤1308可替换为下文的步骤1307’。
1307’、在确定不进行IAB节点DU迁移的情况下，第一CU向第三CU发起部分迁移中的IAB传输 迁移管理流程。
本申请实施例中的方案可支持因MT发生拓扑变化而触发的DU迁移，解决了现有技术不支持的连续partial migration的过程中迁移DU的问题。
在图12和图13的方案中，有些是当MT已完成切换或RLF recovery后，才通过第一消息告知第一CU的。这有些晚，因为此时MT已经到了第三CU拓扑下，如果这时第一CU才发现与第三CU管理的宿主DU或第三CU IP不可达，第一CU与IAB节点的DU之间的F1接口消息已经不能直接通过第三CU管理的宿主DU传输，或许只能走NG接口绕道核心网，这不是我们所希望看到的。举例来说，对于后续UE的切换，第一CU无法直接通过跨拓扑的F1接口向IAB节点的DU发送消息，进而向UE发送切换命令(CU向UE发送的切换命令是封装在CU与IAB节点的DU之间的F1-C消息发送到IAB节点的DU，然后IAB节点的DU解开F1-C消息后，发给UE的)，而是要绕道核心网(F1-C over NGAP)才能到达IAB节点的DU，从而向UE发送切换命令，这样的F1-C over NGAP会使得F1-C的传输变得十分缓慢。为避免由于第一CU无法直接通过跨拓扑的F1接口向IAB节点的DU发送消息造成DU迁移的较慢的问题，本申请实施例提供了可避免NG交互的DU迁移方案，参阅图14中的方法流程。
图14为本申请实施例提供的另一种IAB网络中的DU迁移方法交互流程图。图14中的方法流程是图12描述的方法的一种可能的实现方式。在该实现方式中，第一CU在确定迁移IAB节点的DU之后，指示第二DU暂缓切换MU，并在其拓扑内为IAB节点的DU与第三CU之间的F1接口配置资源；可避免NG交互，从而加快迁移DU的速度。如图14所示，该方法包括：
1401、第三CU向第二CU发送消息2。
步骤1401可参阅步骤1302。例如，第三CU在向第二CU发送消息2之前，接收来自第二CU的消息1；第三CU针对该消息1，向第二CU发送消息2。
1402、第二CU向第一CU发送第一消息。
步骤1402可参阅步骤1305。
1402’、第三CU向第一CU发送第一消息。
步骤1402’可参阅步骤1305’。应理解，步骤1402和步骤1402’是第一CU两种可能的接收到第一消息的实现方式。图14中的方法流程中包括步骤1402或者步骤1402’。
1403、第一CU根据第一消息，确定是否要进行IAB节点的DU的迁移。
步骤1403可参阅步骤1202。第一CU根据第一消息，确定不进行IAB节点的DU的迁移之后，第一CU可向第三CU发起部分迁移中的IAB传输迁移管理流程，参阅步骤1203’。
1404、在确定要进行IAB节点的DU迁移的情况下，第一CU向第二CU发送第三消息。
步骤1404可参阅步骤1203”。
1405、第二CU根据第三消息，在其拓扑内为IAB节点的DU生成的新的逻辑DU与第三CU之间的F1接口配置资源。
步骤1405一种可能的实现方式如下：在第二CU拓扑内的节点上(如：donor-DU2)配置服务于跨拓扑F1-C的资源，并通过RRC消息告知mIAB-MT用于传输F1-C消息的default BAP配置。
1406、IAB节点生成一个新的逻辑DU，并建立新的逻辑DU与第三CU之间的经过第二CU的F1接口。
例如，mIAB-MT收到default BAP配置后，在IAB节点上开启一个新的逻辑DU，即IAB节点的DU2，并与第三CU之间经过步骤1405中配置的资源交互F1SETUP REQUEST/RESPONSE消息。为了便于理解，IAB节点的DU2与第三CU之间的经过第二CU拓扑的F1接口如下图15所示。图15为本申请实施例提供的一种连续partial migration的示例。图15中，CU1为第一CU，CU2为第二CU，CU3为第三CU，Donor-DU1为第一CU管理的宿主DU，Donor-DU2为第二CU管理的宿主DU，Donor-DU3为第三CU管理的宿主DU，mIAB-DU1表示IAB节点的DU，mIAB-DU2表示新的逻辑DU，1501指示的箭头表示mIAB-DU2与第三CU之间的经过第二CU拓扑的F1接口。
1407、IAB节点的DU向第一CU发送第四消息。
相应的，第一CU接收来自IAB节点的DU的第四消息。第四消息用于指示IAB节点的DU与第三CU之间的F1接口已建立。例如，第四消息包括IAB节点的DU的gNB-DUID与第三CU的gNBID。
1407’、第三CU向第一CU发送第四消息。
相应的，第一CU接收来自第三CU的第四消息。应理解，步骤1407和步骤1407’是第一CU两种可能的接收到第四消息的实现方式。图14中的方法流程中包括步骤1407或者步骤1407’。
1408、第一CU向第三CU发起UE HO Preparation流程。
举例来说，第一CU接收到第四消息之后，应该已经可以收到UE的含有IAB节点的DU2下的小区的测量报告，第一CU收到测量报告后，向第三CU发起UE HO Preparation流程。另一种可能的实现方式中，第一CU也可以不基于UE的测量报告选择目标小区，而是通过其他方式获取UE目标小区，如：由UE切换的目标CU(第三CU)或IAB节点直接将UE的目标小区告知第一CU。如果第一CU与第三CU之间没有IP通路，HO Preparation流程可以通过NG交互。
1409、第一CU向终端设备发送第一切换命令。
第一切换命令用于指示终端设备切换至IAB节点的DU下的目标小区。
1410、第一CU向第二CU发送第五消息。
第五消息用于指示第一CU已发送第一切换命令。例如，第一CU在向终端设备发送完第一切换命令后，向第二CU发送第五消息。第五消息告知第二CU，第一CU已经向所有终端设备发送了切换命令(HO Command)。
1411、第二CU向MT发送第二切换命令。
第二切换命令用于IAB节点的MT切换至第三CU下的拓扑。图16为本申请实施例提供的一种IAB网络中的MT切换完成后的状态的示例。图16中，CU1为第一CU，CU2为第二CU，CU3为第三CU，Donor-DU1为第一CU管理的宿主DU，Donor-DU2为第二CU管理的宿主DU，Donor-DU3为第三CU管理的宿主DU，mIAB-DU1表示IAB节点的DU，mIAB-DU2表示新的逻辑DU。图16示出了IAB节点的MT(即mIAB-MT)切换至第三CU下的拓扑的状态，带箭头的线条表示mIAB-DU2与第三CU之间的F1接口，此时关闭mIAB-DU1即可。
对于图14方法流程中所有第一CU与第三CU之间的交互，如果第一CU与第三CU之间没有IP通路，则都可以通过NG接口，经核心网交互(相比于F1-C over NGAP，CU之间通过核心网交互是常规操作)。
本申请实施例与背景技术中介绍的full migration中的full nested流程类似，可以理解为full nested应用在3个CU中的增强版本，都是为了更好的切换UE。在MT切换之前，先激活新的逻辑DU并建立跨拓扑F1接口，然后给UE下发完切换命令后，马上给MT下发切换命令。本申请实施例中3个CU与现有的2个CU中的full nested的主要区别在于，3个CU的场景中需要存在步骤1403和步骤1410。MT和DU迁移的目标CU都是第三CU，而MT的源CU是第二CU，DU的源CU是第一CU.因此，在步骤1403中，需要由第一CU告知第二CU暂时不要切换MT以及建立跨拓扑F1接口。步骤1310中，也需要由第一CU告知第二CU，UE的HO Command已经下发，可以切换MT了。如果3个CU场景中的第一CU与第二CU是同一个CU，那其实就是2个CU的full nested，也就不需要步骤1403与步骤1410了。
本申请实施例中，第一CU在确定迁移IAB节点的DU之后，指示第二DU暂缓切换MU，并在其拓扑内为IAB节点的DU与第三CU之间的F1接口配置资源；可避免NG交互，从而加快迁移DU的速度。
图12中的方法流程未详述步骤1201”涉及的具体流程，即未详述IAB节点的DU向第一CU发送第一消息的具体流程。下面结合附图介绍IAB节点的DU向第一CU发送第一消息的具体流程。图17为本申请实施例提供的另一种IAB网络中的DU迁移方法交互流程图。图17中的方法流程是图12描述的方法的一种可能的实现方式。如图17所示，该方法包括：
1701、第二CU向第三CU发送消息1。
相应的，第三CU接收到来自第二CU的消息1。步骤1701可参阅步骤1301。消息1可以为第二CU向第三CU发送关于mIAB-MT的MT HO REQUEST消息，MT HO REQUEST中携带mIAB-MT在第二CU下的XNAP ID。可选的，MT HO REQUEST中还会携带mIAB-MT在第一CU下的XNAP ID。这里携带第一CU下XNAP ID的原因在于步骤1707中，如果DU迁移的方式不是第一CU直接向IAB节点的DU发送第一消息，而是需要第一CU与第三CU之间交互类似于DU migration request的消息(本申请实施例中没有展开，后续会做相关介绍)，且这个DU migration request如果只携带mIAB-MT在第一CU下的XNAP ID，则第三CU需要理解这个关于DU迁移的XN消息关联的MT就是第一步(即步骤1701)发起切换的MT。因此，第三CU需要在第一步中拿到第一CU下的XNAP ID。这种情况只会出现在步骤1707中需要DU migration request的情况。除此之外，并没有第三CU需要预先知道mIAB-MT在第一CU下XNAP ID的需求，因此是可选的。步骤1701与步骤1301类似，区别仅在于此处是否携带mIAB-MT在第一CU下的XNAPID的条件与步骤1301有所不同。
1702、第三CU向第二CU发送消息2。
相应的，第二CU接收来自第三CU的消息2。步骤1702可参阅步骤1302。
1703、第二CU向IAB节点的MT发送切换命令。
切换命令用于IAB节点的MT执行切换过程，即从第二CU下的拓扑切换至第三CU下的拓扑。切换命令携带IAB节点的MT在第三CU下的XNAP ID，该MT在第三CU下的XNAP ID用于IAB节点将这一信息进一步告知第一CU。如果步骤1702中关于MT的HANDOVER REQUEST ACKNOWLEDGE携带了第三CU管理的宿主DU或第三CU的IP地址，切换命令中也可携带。可选的，切换命令中携带第三CU的gNB ID。这是可选的，因为IAB节点的MT也可以自己通过侦听邻区SIB1消息得到第三CU的gNB ID。需要说明的是，上述MT在第三CU下的XNAP ID、第三CU管理的宿主DU或第三CU的IP地址、第三CU的gNB ID也可以携带在其他相同或不同的RRC消息中，由第二CU发送给IAB节点的MT。
1704、IAB节点的MT根据切换命令，执行切换过程。
由于IAB节点的MT根据切换命令，执行切换过程是本领域的惯用技术手段，这里不再详述。
1705、IAB节点的DU向第一CU发送第一消息。
第一消息为F1消息。步骤1705可参阅步骤1201”。
1706、第一CU根据第一消息，确定是否要进行IAB节点的DU的迁移。
步骤1706可参阅步骤1202。
1707、在确定要进行IAB节点的DU迁移的情况下，第一CU向IAB节点的DU发送第二消息。
步骤1707可参阅步骤1203。
1708、IAB节点的DU根据第二消息，与第三CU建立F1接口。
步骤1708可参阅步骤1204。
1707’、在确定不进行IAB节点DU迁移的情况下，第一CU向第三CU发起部分迁移中的IAB传输迁移管理流程。
步骤1707’可参阅步骤1203”。
图17中的方法流程中包括步骤1707至步骤1708或者步骤1707’。
本申请实施例中，IAB节点的DU向第一CU发送第一消息，以便告知第一CU，MT已完成切换，以触发第一CU决定是否迁移DU。第一CU根据其是否与第三CU管理的宿主DU或第三CU之间IP可达判断是否迁移DU，如果决定迁移DU，则第一CU向IAB节点的DU发送第二消息；解决了现有技术不支持的连续partial migration的过程中迁移DU的问题。
图12、图13以及图17的方法流程中，第一CU向IAB节点的DU发送第二消息。下面结合附图再介绍几种向IAB节点的DU发送第二消息的实现方式。图18为本申请实施例提供的一种信息交互流程图。如图18所示，该方法包括：
1801、第一CU向第三CU发送DU迁移请求。
DU迁移请求(DU migration request)用于请求将IAB节点的DU迁移至第三CU的拓扑下。DU迁移请求包括IAB节点的MT在第一CU下的XNAP ID。可选的，DU迁移请求包括IAB节点的MT在第三CU下的XNAP ID、QoS信息、UE流量的IP地址。
1802、第三CU向第一CU发送DU迁移响应。
DU迁移响应(DU migration response)为第三CU针对DU迁移请求，向第一CU回复的消息。DU迁移响应用于指示第三CU同意将IAB节点的DU迁移至第三CU的拓扑下。或者，DU迁移响应用于指示第三CU已获知将IAB节点的DU迁移至第三CU的拓扑下。
1803、第一CU向IAB节点的DU发送第二消息。
例如，第一CU通过与IAB节点的DU之间的F1接口，向IAB节点的DU发送第二消息。
1801’、第一CU向第三CU发送DU迁移请求。
步骤1801’可参阅步骤1801。
1802’、第三CU向第二CU发送DU迁移响应。
1803’、第二CU向IAB节点的MT发送第二消息。
例如，第二CU通过与mIAB-MT之间的RRC连接向mIAB-MT发送第二消息。步骤1801’至步骤1803’适用于DU的迁移先于MT执行切换的情况，此时MT还连接在第二CU拓扑下。
1801”、第一CU向第三CU发送DU迁移请求。
步骤1801”可参阅步骤1801。
1802”、第三CU向IAB节点的MT发送第二消息。
例如，第三CU直接通过与mIAB-MT之间的RRC连接向mIAB-MT发送。骤1801”至步骤1802”用于DU的迁移晚于MT执行切换的情况，此时MT已经连接到了第三CU拓扑下。
第二消息可能会同时携带mIAB-MT在第一CU和第三CU之下的XNAP ID，也可能只携带mIAB-MT在第一CU下的XNAP ID。如果第一CU与第三CU之间不存在XN接口(如：IP不可达的情况)，则第二消息也可以通过NG接口传递或通过第二CU转发。
应理解，步骤1801至步骤1803是一个独立的交互流程，步骤1801’至步骤1803’是另一个独立的交互流程，步骤1801”至步骤1802”是又一个独立的交互流程。图18示出了三种可能的向IAB节点的DU发送第二消息的方式。
本申请实施例中还引入一个可选的增强，就是在第二消息中，携带UE流量的IP地址和QoS信息，这样可以让第三CU提前知道DU迁移而带过来的UE流量信息(如QoS等)，从而提前进行配置，而不用等在后续DU迁移完成后，再通过UE HO REQUEST获取UE的流量信息。
本申请实施例给出了各种可能的DU迁移交互方法，使得DU迁移能够执行。
下面结合附图描述第一CU向第三CU发起部分迁移中的IAB传输迁移管理流程(参阅步骤1203’)一种具体的方式。图19为本申请实施例提供的另一种信息交互方法流程图。图19描述了在第一CU与第三CU之间无XN接口的情况下，第一CU向第三CU发起部分迁移中的IAB传输迁移管理流程的方式。如图19所示，该方法包括：
1901、第一CU向AMF发送第六消息。
该第六消息包括IAB节点的流量在第三CU下的IP地址、IAB节点的流量的QoS信息、第三CU的NGAP ID。AMF可替换为其他具体接入和移动性管理功能的网元。
1902、AMF向第三CU发送第十一消息。
第十一消息包括IAB节点的流量在第三CU下的IP地址、IAB节点的流量的QoS信息、第一CU的NGAP ID。第十一消息可视为AMF向第三CU转发的第六消息。
1903、第三CU向AMF发送第十二消息。
第十二消息包括第三CU下的回传链路信息、IAB节点的流量的DSCP或流标签(Flow Label)信息以及第一CU的ID。
1904、AMF向第一CU发送第七消息。
第七消息包括第三CU下的回传链路信息、IAB节点的流量的DSCP或流标签(Flow Label)信息以及第三CU的ID。第七消息可视为AMF向第一CU转发的第七消息。
上述第六消息、第七消息、第十一消息、第十二消息为NG接口上的消息。本申请实施例的一个示例为将XN接口上的IAB TRANSPORT MIGRATION MANAGEMENT REQUEST/RESPONSE消息中的关键信元在NG接口上的新消息中传递。第一CU向第三CU方向传递的关键信元包括了每一条traffic的IP地址以及QoS参数，第三CU向第一CU方向传递的关键信元包括了其为这些流量在第三CU拓扑下分配的backhaul链路信息，以及针对其QoS参数配置的DSCP/Flow Label。DSCP/Flow Label用于第一CU将DSCP/Flow Label打入从第一CU发出的下行流量的IP header。
本申请实施例引入了新的NG消息，将XN接口上的IAB TRANSPORT MIGRATION MANAGEMENT REQUEST/RESPONSE消息中的关键信元在NG接口上的新消息中传递，使得partial migration在源CU与目标CU或目标donor-DU没有IP通路时也可以工作。
在一般场景中，每一个小区的小区标识(包括PCI,CGI)是网管系统预先配置的，能确保与邻区的小区标识不发生冲突。由于基站是固定不动的，小区标识也不需要发生变化。但在mobile IAB场景中，IAB节点的DU下的小区随着IAB节点在不断移动，如果它下面的小区始终采用不变的小区标识，则由于邻区关系的改变，可能会与当前附近小区发生小区标识冲突。因此，IAB节点的DU下小区的小区标识可能需要改变。而对于正在对UE提供服务的DU的小区，其小区标识是不可以直接突然改变的，否则会导致UE链路的中断。除小区标识之外，小区广播信息中的TAC,RANAC,也是类似的，这些参数在基站固定不动时，也不需要发生变化，而在移动IAB场景中，TAC和RANAC可能不再能够反映当前地理位置信息，也面临需要更新的问题，而对于正在对UE提供服务的DU的小区，这些广播参数都是不可以直接突然改变的，否则会导致UE链路的中断。鉴于此，本申请实施例提供的一种方案是，在IAB节点的DU下激活一些新的小区(不一定需要像DU Migration那样开启新的DU，此处在同一个DU下开启新的小区即可)，然后对UE进行小区切换，从旧的(发生冲突的或需要变更的)PCI/CGI/TAC/RANAC的小区切换到新的 PCI/CGI/TAC/RANAC小区。
参阅图20，本申请实施例提供一种小区切换方法交互流程图，该方法可通过UE、IAB节点与宿主节点(Donor-CU)的交互来执行，其中，IAB节点包括IAB-DU和IAB-MT。在实际应用时，宿主节点可以与多个IAB节点建立F1连接从而进行数据交互，在此仅以一个IAB节点为例来说明，但是在实际应用时，并不限定IAB节点的数量。如图20所示，该方法包括：
2000、IAB节点预配置以下一项或多项：PCI list，CGI list,TAC list，RANAC list。
例如，网管向IAB节点预配置以下一项或多项：PCI list，CGI list,TAC list，RANAC list。TAC(trackingareacode)是指跟踪区编码。RANAC(radioaccessnetworkareacode)是指无线网络区域编码。其中，在预配TAC list(列表)和RANAC list时，可能还配置了对应的gNB ID或CGI。示例性的，对于PCI list或CGI list，其包括了一个PCI或CGI的资源池，当需要变更PCI或CGI时，从PCI list或CGI list中任选一个与当前PCI或CGI不同的项；对于TAC list或RANAC list，其包括了{gNB ID或CGI}与{TAC或RANAC}的对应关系，当IAB节点根据当前父节点广播的gNB ID或CGI判断出需要变更TAC或RANAC时，从所述对应关系中选择对应的TAC或RANAC。需要说明，步骤2000是预配置操作，IAB节点在执行步骤2001之前，可能不需要执行步骤2000。例如，IAB节点预配置PCI list之后，在未更新预配置的PCI list之前，均利用该PCI list检测PCI是否冲突。在该例子中，IAB节点不需要在每次执行步骤2000之前，执行步骤2000。或者说，IAB节点预配置以下一项或多项：PCI list，CGI list,TAC list，RANAC list之后，后续可直接执行步骤2001，不必执行步骤2000。
2001、IAB节点检测到小区标识(包括PCI或CGI)冲突。
IAB节点检测到PCI/CGI冲突可以是IAB节点的MT收听到的附近小区的PCI/CGI与自己的DU下的小区的PCI/CGI相同。步骤2001也可替换为IAB节点由于其他某种原因希望变更UE的服务小区，或因IAB节点根据听到的父节点的CGI或gNB ID，判断出需要变更小区广播的TAC或RANAC，如：在TAC list或RANAC list中，当前gNB ID或CGI对应的项与当前IAB-DU小区中广播的TAC或RANAC不相同。
2002、IAB节点的DU向CU发送第一消息。
相应的，CU接收来自IAB节点的DU的第一消息。第一消息用于指示IAB节点希望激活的小区。以PCI为例，第一消息中包括一个列表，该列表中包括希望激活的小区的PCI。又例如，第一消息包括指示信息1以及一个或多个小区的PCI，该指示信息1用于指示该一个或多个小区的PCI对应的小区为希望激活的小区。例如，第一消息为gNB-DU Configuration Update消息。gNB-DU Configuration Update消息可参见标准TS 38.473 V17.2.0 Section 9.2.1.7。希望激活的小区的CGI,TAC,RANAC的携带方式与PCI相同。
2003、CU根据第一消息，向IAB节点的DU发送第二消息。
第二消息用于激活IAB节点希望激活的小区。例如，第二消息为gNB-DU Configuration Update ACK消息。gNB-DU Configuration Update ACK消息可参见标准TS 38.473 V17.2.0 Section 9.2.1.8。
2004、CU向终端设备发送切换命令。
相应的，终端设备接收到来自CU的切换命令。切换命令用于终端设备切换至IAB节点希望激活的小区。CU在向IAB节点的DU发送第二消息之后，向终端设备发送切换命令。
2005、终端设备根据切换命令切换至IAB节点希望激活的小区，并向CU发送切换完成消息。
相应的，CU接收来自终端设备的切换完成消息。切换完成消息用于指示终端设备已切换至IAB节点希望激活的小区。
2006、CU向IAB节点的DU发送第三消息。
第三消息用于关闭IAB节点希望关闭的小区。例如，CU通过RRC消息或F1消息通知IAB节点去激活(或关闭)旧的小区。
在一种可能的实现方式中，第一消息还用于指示IAB节点希望关闭的小区；CU在接收到来自终端设备的切换完成消息之后，向IAB节点的DU发送第三消息。以PCI为例，IAB节点的DU可通过向CU发送第一消息告知CU，自己的哪些小区(新PCI)希望被激活，哪些小区(旧PCI小区)希望被“去激活”(关闭)。具体的，可以在这条消息中携带DU下每一个小区的PCI，并对希望激活的小区和希望去激活的小区分别携带对应的指示。或者，用一张表格来表示新小区PCI与旧小区PCI的映射关系，新小区对应的一列是希望激活的小区，旧小区对应的一列是希望去激活的小区，从而告诉CU，哪些PCI对应的小区是希望被激活的，以及哪些PCI对应的小区是希望被关闭的。CGI,TAC,RANAC相关的旧小区的关闭方式与PCI相同。需要说明的，图20方法流程中的第一消息、第二消息、切换命令的含义与上文的含义不同。
本实施例中，当IAB节点希望变更PCI/CGI/TAC/RANAC时，或希望变更UE cell时，将希望激活的 新的小区告知CU，CU按照指示激活小区，然后执行UE切换，并在UE切换完成后指示IAB节点关闭旧小区。相比于现有技术，本申请实施例支持了由IAB节点检测出PCI或CGI冲突后的冲突解决方案，以及根据当前接入的gNB ID或CGI检测出需要变更TAC或RANAC的方案，减少了mobile IAB场景中可能出现的因PCI或CGI冲突导致的干扰问题，以及减少了mobile IAB广播的TAC或RANAC不能反映当前地理位置信息的问题。
图21示出了本申请实施例中所涉及的通信装置的可能的示例性框图。如图21所示，通信装置2100可以包括：处理单元2101和收发单元2102。处理单元2101用于对通信装置2100的动作进行控制管理。收发单元2102用于支持通信装置2100与其他设备的通信。可选地，收发单元2102可以包括接收单元和/或发送单元，分别用于执行接收和发送操作。可选的，通信装置2100还可以包括存储单元，用于存储通信装置2100的程序代码和/或数据。所述收发单元可以称为输入输出单元、通信单元等，所述收发单元可以是收发器；所述处理单元可以是处理器。当通信装置是通信设备中的模块(如，芯片)时，所述收发单元可以是输入输出接口、输入输出电路或输入输出管脚等，也可以称为接口、通信接口或接口电路等；所述处理单元可以是处理器、处理电路或逻辑电路等。具体地，该装置可以为上述的终端设备、IAB-DU、donor CU等。
如图22所示，为本申请提供的一种简化的终端设备的结构示意图。为了便于理解和图示方式，图22中，终端设备以手机作为例子。如图22所示，终端设备包括处理器、存储器、射频电路、天线及输入输出装置。
处理器主要用于对通信协议以及通信数据进行处理，以及对终端设备进行控制，执行软件程序，处理软件程序的数据等。
存储器主要用于存储软件程序和数据。
射频电路主要用于基带信号与射频信号的转换以及对射频信号的处理。
天线主要用于收发电磁波形式的射频信号。
输入输出装置，例如触摸屏、显示屏，键盘等主要用于接收用户输入的数据以及对用户输出数据。
需要说明的是，有些种类的终端设备可以不具有输入输出装置。
当需要发送数据时，处理器对待发送的数据进行基带处理后，输出基带信号至射频电路，射频电路将基带信号进行射频处理后将射频信号通过天线以电磁波的形式向外发送。当有数据发送到终端设备时，射频电路通过天线接收到射频信号，将射频信号转换为基带信号，并将基带信号输出至处理器，处理器将基带信号转换为数据并对该数据进行处理。
为便于说明，图22中仅示出了一个存储器和处理器。在实际的终端设备产品中，可以存在一个或多个处理器和一个或多个存储器。存储器也可以称为存储介质或者存储设备等。存储器可以是独立于处理器设置，也可以是与处理器集成在一起，本申请实施例对此不做限制。
在本申请实施例中，可以将具有收发功能的天线和射频电路视为终端设备的收发单元，将具有处理功能的处理器视为终端设备的处理单元。
如图22所示，终端设备2200包括收发单元2210和处理单元2220。收发单元2210也可以称为收发器、收发机、收发装置等。处理单元2220也可以称为处理器，处理单板，处理单元、处理装置等。
可选的，可以将收发单元2210中用于实现接收功能的器件视为接收单元，将收发单元2210中用于实现发送功能的器件视为发送单元，即收发单元2210包括接收单元和发送单元。收发单元有时也可以称为收发机、收发器、或收发电路等。接收单元有时也可以称为接收机、接收器、或接收电路等。发送单元有时也可以称为发射机、发射器或者发射电路等。
应理解，收发单元2210用于执行上述方法实施例中终端设备的发送操作和接收操作，处理单元2220用于执行上述方法实施例中终端设备上除了收发操作之外的其他操作。
当该终端设备为芯片时，该芯片包括收发单元2210和处理单元2220。其中，该收发单元2210可以是输入输出电路或通信接口；处理单元2220为该芯片上集成的处理器或者微处理器或者集成电路或者逻辑电路。
本申请还提供一种网络设备。如图23所示，为本申请实施例提供的网络设备2300的结构示意图，该网络设备2300可应用于如图1所示的系统中，例如网络设备2300可以为IAB-DU、donor CU，用以执行上述方法实施例中网络设备的功能。应理解以下仅为示例，未来通信系统中，网络设备可以有其他形态和构成。
举例来说，在5G通信系统中，网络设备2300可以包括CU、DU和AAU，相比于LTE通信系统中的 网络设备由一个或多个射频单元，如射频拉远单元(remote radio unit，RRU)和一个或多个室内基带处理单元(building base band unit，BBU)来说：
原BBU的非实时部分将分割出来，重新定义为CU，负责处理非实时协议和服务、BBU的部分物理层处理功能与原RRU及无源天线合并为AAU、BBU的剩余功能重新定义为DU，负责处理物理层协议和实时服务。简而言之，CU和DU，以处理内容的实时性进行区分、AAU为RRU和天线的组合。
CU、DU、AAU可以采取分离或合设的方式，所以，会出现多种网络部署形态，一种可能的部署形态如图23所示与传统4G网络设备一致，CU与DU共硬件部署。应理解，图23只是一种示例，对本申请的保护范围并不限制，例如，部署形态还可以是DU部署在BBU机房，CU集中部署或DU集中部署，CU更高层次集中等。
所述AAU2400可以实现收发功能与图21中的收发单元2102对应。可选地，该AAU2400还可以称为收发机、收发电路、或者收发器等，其可以包括至少一个天线2401和射频单元2402。可选地，AAU2400可以包括接收单元和发送单元，接收单元可以对应于接收器(或称接收机、接收电路)，发送单元可以对应于发射器(或称发射机、发射电路)。所述CU和DU2500可以实现的内部处理功能与图21中的处理单元2101的功能对应。可选地，该CU和DU2500可以对网络设备进行控制等，可以称为控制器。所述AAU与CU和DU可以是物理上设置在一起，也可以物理上分离设置的。
另外，网络设备不限于图23所示的形态，也可以是其它形态：例如：包括BBU和自适应无线单元(adaptive radio unit，ARU)，或者包括BBU和AAU；也可以为客户终端设备(customer premises equipment，CPE)，还可以为其它形态，本申请不限定。
在一个示例中，所述CU和DU2500可以由一个或多个单板构成，多个单板可以共同支持单一接入制式的无线接入网(如LTE网)，也可以分别支持不同接入制式的无线接入网(如LTE网，5G网，未来网络或其他网)。所述CU和DU2500还包括存储器2501和处理器2502。所述存储器2501用以存储必要的指令和数据。所述处理器2502用于控制网络设备进行必要的动作，例如用于控制网络设备执行上述方法实施例中关于网络设备的操作流程。所述存储器2501和处理器2502可以服务于一个或多个单板。也就是说，可以每个单板上单独设置存储器和处理器。也可以是多个单板共用相同的存储器和处理器。此外每个单板上还可以设置有必要的电路。
应理解，图23所示的网络设备2300能够实现图7的方法实施例中涉及的网络设备功能。网络设备2300中的各个单元的操作和/或功能，分别为了实现本申请方法实施例中由网络设备执行的相应流程。为避免重复，此处适当省略详述描述。图23示例的网络设备的结构仅为一种可能的形态，而不应对本申请实施例构成任何限定。本申请并不排除未来可能出现的其他形态的网络设备结构的可能。
上述CU和DU2500可以用于执行前面方法实施例中描述的由网络设备内部实现的动作，而AAU2400可以用于执行前面方法实施例中描述的网络设备向终端设备发送或从终端设备接收的动作。具体请见前面方法实施例中的描述，此处不再赘述。
本申请实施例还提供了一种通信系统，该通信系统包括上述第一CU、上述第二CU、上述第三CU以及上述IAB节点。
基于以上实施例，本申请实施例还提供一种可读存储介质，该可读存储介质存储有指令，当所述指令被执行时，使上述任一实施例中的方法被实施。该可读存储介质可以包括：U盘、移动硬盘、只读存储器、随机存取存储器、磁碟或者光盘等各种可以存储程序代码的介质。
本领域内的技术人员应明白，本申请的实施例可提供为方法、系统、或计算机程序产品。因此，本申请可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本申请可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、紧凑型光盘只读储存器(compact disc read-only memory，CD-ROM)、光学存储器等)上实施的计算机程序产品的形式。
本申请是参照根据本申请的方法、装置(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理装置的处理器以产生一个机器，使得通过计算机或其他可编程数据处理装置的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。
这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理装置以特定方式工作的计算机 可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。
这些计算机程序指令也可装载到计算机或其他可编程数据处理装置上，使得在计算机或其他可编程装置上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程装置上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。

Claims (50)

  1. 一种通信方法，其特征在于，所述方法应用于第一集中式单元CU或第一CU中的模块，所述方法包括：
    接收第一消息，所述第一消息包括用于在第三CU中标识接入回传一体化IAB节点的移动终端MT的标识ID和所述第三CU的ID；
    根据所述第一消息，确定是否要进行所述IAB节点的分布式单元DU的迁移；
    在确定要进行所述IAB节点的DU迁移的情况下，向所述IAB节点发送第二消息，其中，所述第二消息用于指示所述IAB节点的DU与所述第三CU建立F1接口。
  2. 根据权利要求1所述的方法，其特征在于，所述第二消息用于指示所述IAB节点的DU生成一个新的逻辑DU，并与所述第三CU建立F1接口。
  3. 根据权利要求1或2所述的方法，其特征在于，所述第一消息还包括所述第三CU的IP地址或者所述第三CU管理的宿主DU的IP地址。
  4. 根据权利要求1至3任一项所述的方法，其特征在于，所述根据所述第一消息，确定是否要进行所述IAB节点的DU的迁移包括：
    根据所述第一消息，确定所述第一CU是否能够不通过核心网到达所述第三CU或所述第三CU管理的宿主DU；
    或者，根据所述第一消息，确定所述第一CU是否能够与所述第三CU建立XN接口；
    或者，根据所述第一消息，确定所述第一CU是否能够通过IP路由的方式到达所述第三CU或所述第三CU管理的宿主DU。
  5. 根据权利要求1至4任一项所述的方法，其特征在于，所述MT与第二CU之间具有无线资源控制RRC连接，或者，所述第三CU下的拓扑为所述MT从所述第二CU的拓扑下变换至的拓扑。
  6. 根据权利要求5所述的方法，其特征在于，所述第一消息用于指示所述MT将从所述第二CU下的拓扑切换至所述第三CU下的拓扑、所述MT已完成从所述第二CU下的拓扑至所述第三CU下的拓扑的切换、或者所述MT与所述第二CU之间发生无线链路失败且接入所述第三CU下的拓扑下中的任一项。
  7. 根据权利要求1所述的方法，其特征在于，所述MT与第二CU之间具有无线资源控制RRC连接；所述方法还包括：
    在确定要进行所述IAB节点的DU迁移的情况下，向所述第二CU发送第三消息，所述第三消息用于请求所述第二CU在其拓扑内为所述IAB节点的DU与所述第三CU之间的F1接口配置资源。
  8. 根据权利要求7所述的方法，其特征在于，所述第一消息用于指示所述MT将从所述第二CU下的拓扑切换至所述第三CU下的拓扑；在向所述第二CU发送第三消息之后，所述方法还包括：
    接收第四消息，所述第四消息用于指示所述IAB节点的DU与所述第三CU之间的F1接口已建立。
  9. 根据权利要求8所述的方法，其特征在于，在接收第四消息之后，所述方法还包括：
    在向终端设备发送第一切换命令之后，向所述第二CU发送第五消息，所述第一切换命令用于指示所述终端设备切换至所述IAB节点的DU下的目标小区，所述第五消息用于指示所述第一CU已发送所述第一切换命令。
  10. 根据权利要求1至9任一项所述的方法，其特征在于，所述方法还包括：
    在确定不进行所述IAB节点DU迁移的情况下，向所述第三CU发起部分迁移中的IAB传输迁移管理流程，所述流程用于流量的跨拓扑迁移。
  11. 根据权利要求10所述的方法，其特征在于，所述向所述第三CU发起部分迁移中的IAB传输迁移 管理流程包括：
    向接入和移动性管理功能网元发送第六消息，所述第六消息包括所述IAB节点的流量在所述第三CU下的IP地址以及所述IAB节点的流量的服务质量QoS信息；
    接收来自所述接入和移动性管理功能网元的第七消息，所述第七消息包括所述第三CU下的回传链路信息，以及所述IAB节点的流量的区分服务编码点或流标签信息。
  12. 一种通信方法，其特征在于，所述方法应用于第二集中式单元CU或第二CU中的模块，所述方法包括：
    生成第一消息；
    向第一CU发送所述第一消息，所述第一消息用于指示接入回传一体化IAB节点的移动终端MT将从所述第二CU下的拓扑切换至所述第三CU下的拓扑、所述MT已完成从所述第二CU下的拓扑至所述第三CU下的拓扑的切换、或者所述MT与所述第二CU之间发生无线链路失败且接入所述第三CU下的拓扑下中的任一项。
  13. 根据权利要求12所述的方法，其特征在于，在向第一CU发送所述第一消息之后，所述方法还包括：
    接收来自第一CU的第三消息；
    根据所述第三消息，在其拓扑内为所述IAB节点的分布式单元DU与第三CU之间的F1接口配置资源。
  14. 根据权利要求12或13所述的方法，其特征在于，在向第一CU发送所述第一消息之前，所述方法还包括：
    接收来自第三CU的第八消息，所述第八消息用于指示IAB节点的MT将切换至所述第三CU下的拓扑、所述MT已切换至所述第三CU下的拓扑、或者所述MT在与所述第二CU之间发生无线链路失败之后已接入所述第三CU下的拓扑中的任一项。
  15. 根据权利要求14所述的方法，其特征在于，所述第八消息包括所述第三CU的IP地址和/或所述第三CU管理的宿主DU的IP地址。
  16. 根据权利要求13至15任一项所述的方法，其特征在于，所述第一消息包括用于在所述第三CU中标识所述MT的ID和所述第三CU的ID。
  17. 根据权利要求12至16任一项所述的方法，其特征在于，所述方法还包括：
    接收来自所述第一CU的第五消息，所述第五消息用于指示所述第一CU已向终端设备发送第一切换命令，所述第一切换命令用于所述终端设备切换至所述IAB节点的DU下的目标小区；
    向所述MT发送第二切换命令，所述第二切换命令用于所述IAB节点的MT切换至所述第三CU下的拓扑。
  18. 一种通信方法，其特征在于，所述方法应用于第三集中式单元CU或第三CU中的模块，所述方法包括：
    生成第一消息；
    向第一CU发送所述第一消息，所述第一消息用于指示接入回传一体化IAB节点的移动终端MT将从第二CU下的拓扑切换至所述第三CU下的拓扑、所述MT已完成从所述第二CU下的拓扑至所述第三CU下的拓扑的切换、或者所述MT与所述第二CU之间发生无线链路失败且接入所述第三CU下的拓扑下中的任一项。
  19. 根据权利要求18所述的方法，其特征在于，在向第一CU发送所述第一消息之后，所述方法还包括：
    向所述第一CU发送第四消息，所述第四消息用于指示所述IAB节点的分布式单元DU与所述第三 CU之间的F1接口已建立。
  20. 根据权利要求18或19所述的方法，其特征在于，所述第一消息包括用于在所述第三CU中标识所述MT的ID和所述第三CU的ID。
  21. 根据权利要求18至20任一项所述的方法，其特征在于，在向所述第一CU发送第一消息之前，所述方法还包括：
    向所述第二CU发送第九消息或接收来自所述第二CU的第十消息，所述第九消息用于指示所述MT将切换至所述第三CU下的拓扑或者所述MT已变换至所述第三CU下的拓扑，所述第十消息用于指示所述MT已变换至所述第三CU下的拓扑。
  22. 根据权利要求21所述的方法，其特征在于，所述第九消息包括所述第三CU的IP地址和/或所述第三CU管理的宿主DU的IP地址。
  23. 根据权利要求21或22所述的方法，其特征在于，所述第十消息包括所述MT在所述第一CU下的ID。
  24. 根据权利要求18至23任一项所述的方法，其特征在于，所述方法还包括：
    响应所述第一CU向所述第三CU发起的部分迁移中的IAB传输迁移管理流程。
  25. 根据权利要求24所述的方法，其特征在于，所述响应所述第一CU向所述第三CU发起的部分迁移中的IAB传输迁移管理流程包括：
    接收来自接入和移动性管理功能网元的第十一消息，所述第十一消息包括所述IAB节点的流量在所述第三CU下的IP地址以及所述IAB节点的流量的QoS信息；
    向所述接入和移动性管理功能网元发送第十二消息，所述第十二消息包括所述第三CU下的回传链路信息，以及所述IAB节点的流量的区分服务编码点或流标签信息。
  26. 一种通信装置，其特征在于，包括用于实现权利要求1至11中任一项所述的方法的模块或单元。
  27. 一种通信装置，其特征在于，包括用于实现权利要求12至17中任一项所述的方法的模块或单元。
  28. 一种通信装置，其特征在于，包括用于实现权利要求18至25中任一项所述的方法的模块或单元。
  29. 一种计算机可读存储介质，其特征在于，所述计算机可读存储介质中存储有计算机程序，所述计算机程序包括程序指令，所述程序指令被执行时使得计算机执行如权利要求1至25中任一项所述的方法。
  30. 一种通信装置，其特征在于，包括处理器，所述处理器与存储器耦合，所述存储器存储计算机程序指令，所述处理器用于执行所述计算机程序指令，使得所述通信装置执行如权利要求1至25任一项所述的方法。
  31. 一种通信方法，其特征在于，所述方法应用于接入回传一体化IAB节点的分布式单元DU，所述方法包括：
    所述IAB节点的DU生成第一消息，所述第一消息携带用于在第三集中式单元CU中标识所述IAB节点的移动终端MT的标识ID和所述第三CU的ID；
    所述IAB节点的DU向第一CU发送所述第一消息。
  32. 根据权利要求31所述的方法，其特征在于，所述IAB节点的DU向第一CU发送所述第一消息包括：
    在所述IAB节点的MT从第二CU的拓扑下切换至所述第三CU的拓扑下的情况下，所述IAB节点的 DU向所述第一CU发送所述第一消息。
  33. 一种通信方法，其特征在于，所述方法应用于第一集中式单元CU或第一CU中的模块，所述方法包括：
    接收来自接入回传一体化IAB节点的分布式单元DU的第一消息，所述第一消息携带用于在第三CU中标识所述IAB节点的移动终端MT的标识ID和所述第三CU的ID。
  34. 一种通信方法，其特征在于，所述方法应用于接入回传一体化IAB节点的分布式单元DU，所述方法包括：
    所述IAB节点的DU接收来自第一集中式单元CU的第二消息，所述第二消息包括第三CU的标识ID；
    所述IAB节点的DU根据所述第二消息，与所述第三CU建立F1接口。
  35. 根据权利要求34所述的方法，其特征在于，所述第二消息用于指示所述IAB节点的DU与所述第三CU建立F1接口。
  36. 一种通信方法，其特征在于，所述方法应用于第一集中式单元CU或第一CU中的模块，所述方法包括：
    生成第二消息，所述第二消息包括第三CU的标识ID；
    向接入回传一体化IAB节点的分布式单元DU发送所述第二消息。
  37. 根据权利要求36所述的方法，其特征在于，所述第二消息用于指示所述IAB节点的DU与所述第三CU建立F1接口。
  38. 一种通信方法，其特征在于，所述方法应用于接入回传一体化IAB节点的分布式单元DU，所述方法包括：
    所述IAB节点的DU生成第四消息，所述第四消息包括第三集中式单元CU的基站标识gNBID，所述第四消息用于指示所述IAB节点的DU与所述第三CU之间的F1接口已建立；
    所述IAB节点的DU向第一CU发送所述第四消息。
  39. 根据权利要求38所述的方法，其特征在于，所述第四消息还包括所述IAB节点的DU的基站分布式单元标识gNB-DU ID。
  40. 一种通信方法，其特征在于，所述方法应用于第一集中式单元CU或第一CU中的模块，所述方法包括：
    接收来自接入回传一体化IAB节点的分布式单元DU的第四消息，所述第四消息包括第三集中式单元CU的基站标识gNBID，所述第四消息用于指示所述IAB节点的DU与所述第三CU之间的F1接口已建立。
  41. 根据权利要求40所述的方法，其特征在于，所述第四消息还包括所述IAB节点的DU的基站分布式单元标识gNB-DU ID。
  42. 一种通信装置，其特征在于，包括用于实现权利要求31或32所述的方法的模块。
  43. 一种通信装置，其特征在于，包括用于实现权利要求33所述的方法的模块。
  44. 一种通信装置，其特征在于，包括用于实现权利要求34或35所述的方法的模块。
  45. 一种通信装置，其特征在于，包括用于实现权利要求36或37所述的方法的模块。
  46. 一种通信装置，其特征在于，包括用于实现权利要求38或39所述的方法的模块。
  47. 一种通信装置，其特征在于，包括用于实现权利要求40或41所述的方法的模块。
  48. 一种计算机可读存储介质，其特征在于，所述计算机可读存储介质中存储有计算机程序，所述计算机程序包括程序指令，所述程序指令被执行时使得计算机执行如权利要求31至41中任一项所述的方法。
  49. 一种通信装置，其特征在于，包括处理器，所述处理器与存储器耦合，所述存储器存储计算机程序指令，所述处理器用于执行所述计算机程序指令，使得所述通信装置执行如权利要求31至41任一项所述的方法。
  50. 一种计算机程序产品，其特征在于，所述计算机程序产品包括计算机程序，所述计算机程序包括程序指令，所述程序指令被执行时使得计算机执行如权利要求31至41中任一项所述的方法。
PCT/CN2023/127192 2022-11-03 2023-10-27 一种通信方法和通信装置 WO2024093833A1 (zh)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN202211372936.8A CN117998481A (zh) 2022-11-03 2022-11-03 一种通信方法和通信装置
CN202211372936.8 2022-11-03

Publications (1)

Publication Number Publication Date
WO2024093833A1 true WO2024093833A1 (zh) 2024-05-10

Family

ID=90901612

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2023/127192 WO2024093833A1 (zh) 2022-11-03 2023-10-27 一种通信方法和通信装置

Country Status (2)

Country Link
CN (1) CN117998481A (zh)
WO (1) WO2024093833A1 (zh)

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN111194054A (zh) * 2018-11-15 2020-05-22 中兴通讯股份有限公司 用户设备迁移方法、集中单元、分布单元及系统
US20210051547A1 (en) * 2019-08-16 2021-02-18 Nokia Solutions And Networks Oy Associating iab mt to iab du at handover-target gnb
CN114071617A (zh) * 2020-08-07 2022-02-18 大唐移动通信设备有限公司 Iab节点组切换中的信息传输方法、装置、网络设备及系统

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN111194054A (zh) * 2018-11-15 2020-05-22 中兴通讯股份有限公司 用户设备迁移方法、集中单元、分布单元及系统
US20210051547A1 (en) * 2019-08-16 2021-02-18 Nokia Solutions And Networks Oy Associating iab mt to iab du at handover-target gnb
CN114071617A (zh) * 2020-08-07 2022-02-18 大唐移动通信设备有限公司 Iab节点组切换中的信息传输方法、装置、网络设备及系统

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
ERICSSON (MODERATOR): "CB # IAB2_Mobility - Summary of email discussion", 3GPP TSG-RAN WG3 MEETING #117-BIS-E, R3-225937, 18 October 2022 (2022-10-18), XP052266075 *

Also Published As

Publication number Publication date
CN117998481A (zh) 2024-05-07

Similar Documents

Publication Publication Date Title
US20230097891A1 (en) System and method for mobility enhancements
RU2713442C1 (ru) Система и способ переключения сот
EP3035735B1 (en) Handover method, master base station and slave base station
JP7455998B2 (ja) 通信方法、装置、およびシステム
US20140269575A1 (en) Method, base station, and user equipment for implementing carrier aggregation
JP6567686B2 (ja) データ・オフロードのためのパスを確立する方法及び装置
US20160242224A1 (en) Mobile terminal communication control methods, devices and related equipment
WO2016119109A1 (zh) 一种切换装置及方法
WO2016161759A1 (zh) 数据的传输方法及装置
CN106941700B (zh) 一种数据传输方法及装置和基站及ue
JP6290413B2 (ja) 接続管理方法及びアクセスネットワークエレメント
CN107302773B (zh) 连接的建立方法、装置及系统
WO2021026706A1 (zh) 一种f1接口管理方法及装置
US20230328607A1 (en) Communication control method
WO2024093833A1 (zh) 一种通信方法和通信装置
WO2022082690A1 (zh) 群组切换的方法、装置和系统
WO2022151298A1 (zh) 群组迁移方法、装置和系统
TW202033047A (zh) 行動性中斷減少之方法及其使用者設備
EP4325798A1 (en) Communication method and apparatus
WO2024026803A1 (zh) 移动节点的配置方法和宿主设备
WO2024027277A1 (zh) 一种小区标识配置方法及通信装置
WO2024067015A1 (zh) 通信方法、通信装置及通信系统
WO2023142981A1 (zh) 通信方法及相关装置
WO2022206317A1 (zh) 一种通信方法以及通信设备
WO2024067112A1 (zh) 一种通信方法、通信设备、介质及程序产品