WO2022236644A1 - 发送和接收信号的方法、装置和通信*** - Google Patents

发送和接收信号的方法、装置和通信*** Download PDF

Info

Publication number
WO2022236644A1
WO2022236644A1 PCT/CN2021/092913 CN2021092913W WO2022236644A1 WO 2022236644 A1 WO2022236644 A1 WO 2022236644A1 CN 2021092913 W CN2021092913 W CN 2021092913W WO 2022236644 A1 WO2022236644 A1 WO 2022236644A1
Authority
WO
WIPO (PCT)
Prior art keywords
iab
node
donor
message
request
Prior art date
Application number
PCT/CN2021/092913
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 富士通株式会社
Priority to CN202180097986.7A priority Critical patent/CN117280745A/zh
Priority to EP21941220.2A priority patent/EP4340444A4/en
Priority to JP2023569597A priority patent/JP2024517469A/ja
Priority to PCT/CN2021/092913 priority patent/WO2022236644A1/zh
Priority to KR1020237038595A priority patent/KR20230169245A/ko
Publication of WO2022236644A1 publication Critical patent/WO2022236644A1/zh
Priority to US18/385,929 priority patent/US20240064572A1/en

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W36/00—Hand-off or reselection arrangements
    • H04W36/0005—Control or signalling for completing the hand-off
    • H04W36/0009—Control or signalling for completing the hand-off for a plurality of users or terminals, e.g. group communication or moving wireless networks
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00—Routing or path finding of packets in data switching networks
    • H04L45/24—Multipath
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W28/00—Network traffic management; Network resource management
    • H04W28/02—Traffic management, e.g. flow control or congestion control
    • H04W28/0252—Traffic management, e.g. flow control or congestion control per individual bearer or channel
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W28/00—Network traffic management; Network resource management
    • H04W28/02—Traffic management, e.g. flow control or congestion control
    • H04W28/08—Load balancing or load distribution
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W28/00—Network traffic management; Network resource management
    • H04W28/02—Traffic management, e.g. flow control or congestion control
    • H04W28/08—Load balancing or load distribution
    • H04W28/0827—Triggering entity
    • H04W28/0835—Access entity, e.g. eNB
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W28/00—Network traffic management; Network resource management
    • H04W28/02—Traffic management, e.g. flow control or congestion control
    • H04W28/08—Load balancing or load distribution
    • H04W28/086—Load balancing or load distribution among access entities
    • H04W28/0861—Load balancing or load distribution among access entities between base stations
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W28/00—Network traffic management; Network resource management
    • H04W28/02—Traffic management, e.g. flow control or congestion control
    • H04W28/08—Load balancing or load distribution
    • H04W28/086—Load balancing or load distribution among access entities
    • H04W28/0861—Load balancing or load distribution among access entities between base stations
    • H04W28/0864—Load balancing or load distribution among access entities between base stations of different hierarchy levels, e.g. Master Evolved Node B [MeNB] or Secondary Evolved node B [SeNB]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W28/00—Network traffic management; Network resource management
    • H04W28/02—Traffic management, e.g. flow control or congestion control
    • H04W28/10—Flow control between communication endpoints
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W40/00—Communication routing or communication path finding
    • H04W40/02—Communication route or path selection, e.g. power-based or shortest path routing
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W40/00—Communication routing or communication path finding
    • H04W40/02—Communication route or path selection, e.g. power-based or shortest path routing
    • H04W40/22—Communication route or path selection, e.g. power-based or shortest path routing using selective relaying for reaching a BTS [Base Transceiver Station] or an access point
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W40/00—Communication routing or communication path finding
    • H04W40/24—Connectivity information management, e.g. connectivity discovery or connectivity update
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W40/00—Communication routing or communication path finding
    • H04W40/24—Connectivity information management, e.g. connectivity discovery or connectivity update
    • H04W40/248—Connectivity information update
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W76/00—Connection management
    • H04W76/10—Connection setup
    • H04W76/12—Setup of transport tunnels
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W84/00—Network topologies
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W84/00—Network topologies
    • H04W84/02—Hierarchically pre-organised networks, e.g. paging networks, cellular networks, WLAN [Wireless Local Area Network] or WLL [Wireless Local Loop]
    • H04W84/04—Large scale networks; Deep hierarchical networks
    • H04W84/042—Public Land Mobile systems, e.g. cellular systems
    • H04W84/047—Public Land Mobile systems, e.g. cellular systems using dedicated repeater stations
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W88/00—Devices specially adapted for wireless communication networks, e.g. terminals, base stations or access point devices
    • H04W88/08—Access point devices
    • H04W88/085—Access point devices with remote components

Definitions

  • the embodiment of the present application relates to the technical field of communication.
  • IAB integrated access and backhaul
  • NG-RAN next generation radio access network
  • IAB-node The integrated access and backhaul node
  • NR New Radio
  • IAB-donor represents a network device (eg, gNB) that supports the IAB function.
  • IAB-node can connect to an IAB host (IAB-donor) through one or more hops. These multi-hop connections form a directed acyclic graph (DAG, Directed Acyclic Graph) topology with the IAB host as the root node.
  • DAG directed acyclic graph
  • the IAB host is responsible for performing centralized resource management, topology management, and routing management in the IAB network topology.
  • IAB-node supports the function of gNB-DU (distributed unit, distributed unit). IAB-node DU is also called IAB-DU. The end point of the NR access interface is also the end point of the F1 protocol to the gNB-CU (central unit, central unit) on the IAB-donor.
  • the IAB-DU can serve normal UEs and IAB sub-nodes.
  • the IAB-DU implements the network-side device function, connects to the downstream child IAB-node, provides NR air interface access to the UE and the downstream child IAB-node, and establishes an F1 connection with the IAB donor-CU.
  • IAB-node In addition to the gNB-DU function, IAB-node also supports some UE functions, called IAB-MT (Mobile Termination), IAB-MT includes functions such as physical layer, layer 2, RRC and NAS to connect to another IAB-node Or the gNB-DU of the IAB-donor, connected to the gNB-CU on the IAB-donor and connected to the core network. IAB-MT can support functions such as UE physical layer, access (access stratum, AS), radio resource control (radio resource control, RRC) layer and non-access (non-access stratum, NAS) layer, and can be connected to the IAB parent node.
  • IAB-MT Mobile Termination
  • IAB-MT Mobile Termination
  • IAB-MT Mobile Termination
  • IAB-MT includes functions such as physical layer, layer 2, RRC and NAS to connect to another IAB-node Or the gNB-DU of the IAB-donor, connected to the gNB-CU on the IAB-
  • the IAB-donor is the termination node on the network side, and the IAB-donor provides network access for the IAB-MT or UE through the backhaul or access link.
  • IAB-donor is further divided into IAB-donor-CU (central unit) and IAB-donor-DU.
  • IAB-DU and IAB-donor-CU are connected through F1 interface.
  • the gNB and the IAB-donor-CU are connected through the Xn interface.
  • BAP Backhaul Adaptation Protocol
  • RLC radio link control
  • FIG. 1 is a schematic diagram of the IAB topology.
  • IAB-node100 comprises IAB-MT functional unit 101 and IAB-DU functional unit 102, and the adjacent node on the interface of IAB-DU functional unit 102 is called child node (child node), as shown in Fig. 1, the child nodes 201, 202, 203, the IAB-DU functional unit 102 and the child nodes 201, 202, 203 can communicate through the air interface (Uu); the IAB-MT functional unit 101
  • the adjacent node on the interface is called parent node (parent node), as shown in Fig. 1 parent node 301,302, can pass air interface (Uu) to communicate.
  • IAB-donor (not shown) performs centralized resource, topology and routing management for the IAB topology 10 .
  • Topology redundancy refers to the establishment of redundant paths for IAB nodes in the IAB topology network, that is, the second path, so as to offload part of the business in one topology network to another topology network, that is, Data transmission via redundant paths.
  • the main purpose of topology redundancy is to perform service load balancing, reduce service interruption, and improve network robustness.
  • the existing host (intra-CU) topology redundancy process can establish and release redundant paths in the IAB topology under the same IAB-donor-CU, which can achieve a certain degree of path diversity and load balanced. If the topological network under the same IAB-donor-CU has reached the saturation of the load, it will affect the performance of the business. Inter-host (inter-CU) topology redundancy can further improve path diversity and better meet load balancing requirements.
  • Embodiments of the present application provide a method, device, and communication system for sending and receiving signals.
  • the first IAB-donor-CU sends a traffic offload request to the second IAB-donor-CU
  • the second IAB-donor-CU sends a traffic offload request to the first
  • the IAB-donor-CU sends a reply agreeing to traffic offloading or a reply denying traffic offloading, whereby a redundant path can be established between the network topology of the first IAB-donor-CU and the network topology of the second IAB-donor-CU , so that the diversity of paths can be further improved, and the requirements of load balancing and reduction of service interruption can be better met.
  • a device for sending and receiving signals is provided, which is applied to a first integrated access and backhaul node donor central unit (IAB-donor-CU), and the device includes a first transceiver unit, It is configured as:
  • a device for sending and receiving signals which is applied to a second integrated access and backhaul node donor central unit (IAB-donor-CU), and the device includes a second transceiver unit , the second transceiver unit is configured to:
  • a device for sending and receiving signals which is applied to an IAB node, the IAB node is connected to the first parent node, and the IAB node has been or will be connected to the second parent node connected, the first parent node is a node within the topology of the first IAB-donor-CU, the second parent node is a node within the topology of the second IAB-donor-CU,
  • the device includes a third transceiver unit, and the third transceiver unit is configured to:
  • the first RRC reconfiguration message is generated according to the reply that the second IAB-donor-CU sends to the first IAB-donor-CU agreeing to traffic offloading
  • the first RRC reconfiguration message includes at least one TNL address assigned to a DU of the IAB node, the TNL address being anchored to a second IAB-donor-DU within the topology of the second IAB-donor-CU ,
  • the RRC reconfiguration complete (RRCReconfigurationComplete) message is used to indicate that the IAB node has received the first RRC reconfiguration message and completed the reconfiguration.
  • a device for sending and receiving signals which is applied to a descendant node of an IAB node, the IAB node is connected to the first parent node, and the IAB node has been or will be connected to the first parent node
  • Two parent nodes are connected, the first parent node is a node within the topology of the first IAB-donor-CU, and the second parent node is a node within the topology of the second IAB-donor-CU,
  • the device includes a fourth transceiver unit, the fourth transceiver unit is configured to:
  • the first RRC reconfiguration message is generated according to the reply that the second IAB-donor-CU sends to the first IAB-donor-CU agreeing to traffic offloading
  • the first RRC reconfiguration message includes at least one TNL address allocated for the DU of the descendant node, and the TNL address is anchored to the second IAB-donor-CU within the topology of the second IAB-donor-CU.
  • the RRC reconfiguration complete (RRCReconfigurationComplete) message is used to indicate that the descendant node has received the first RRC reconfiguration message and has completed reconfiguration.
  • a method for sending and receiving a signal which corresponds to the device for sending and receiving a signal in any aspect above.
  • the beneficial effect of the embodiment of the present application is that: the first IAB-donor-CU sends a traffic offloading request to the second IAB-donor-CU, and the second IAB-donor-CU sends a reply agreeing to traffic offloading to the first IAB-donor-CU Or reject the reply of traffic offloading, so that a redundant path can be established between the network topology of the first IAB-donor-CU and the network topology of the second IAB-donor-CU.
  • Figure 1 is a schematic diagram of the IAB topology
  • FIG. 2 shows an example of a topology transmission path in a scenario of inter-host (inter-CU) topology redundancy
  • Fig. 3 is a schematic diagram of the method for sending and receiving signals according to the embodiment of the first aspect
  • Fig. 4 is a schematic diagram of a method for sending and receiving signals according to an embodiment of the second aspect
  • Fig. 5 is a schematic diagram of the establishment process of the second path of the IAB node in Embodiment 1;
  • FIG. 6 is a schematic diagram of a method for establishing a redundant path between hosts for a descendant node of an IAB node in Embodiment 2;
  • FIG. 7 shows a schematic diagram of adding SN to an IAB node to become a dual-connection node and establishing a redundant path
  • FIG. 8 is a schematic diagram of a successful traffic offloading process
  • Fig. 9 is a schematic diagram of the failure of the traffic offloading process
  • FIG. 10 is a schematic diagram of the release of redundant paths proposed by the initiator of traffic offloading
  • Fig. 11 is a schematic diagram of redundant path release proposed by the receiver of traffic offloading
  • Fig. 12 is a schematic diagram of a method for sending and receiving signals according to an embodiment of the third aspect
  • Fig. 13 is a schematic diagram of a method for sending and receiving signals according to an embodiment of the third aspect
  • Fig. 14 is a schematic diagram of signals of the sending and receiving device according to the embodiment of the present application.
  • Fig. 15 is a schematic diagram of a device for sending and receiving signals in an embodiment of the sixth aspect
  • Fig. 16 is a schematic diagram of a device for sending and receiving signals in an embodiment of the seventh aspect
  • Fig. 17 is a schematic diagram of a device for sending and receiving signals in an embodiment of the eighth aspect
  • FIG. 18 is a schematic diagram of a network device according to an embodiment of the present application.
  • FIG. 19 is a schematic diagram of a terminal device according to an embodiment of the present application.
  • the terms “first”, “second”, etc. are used to distinguish different elements from the title, but do not indicate the spatial arrangement or time order of these elements, and these elements should not be referred to by these terms restricted.
  • the term “and/or” includes any and all combinations of one or more of the associated listed items.
  • the terms “comprising”, “including”, “having” and the like refer to the presence of stated features, elements, elements or components, but do not exclude the presence or addition of one or more other features, elements, elements or components.
  • the term “communication network” or “wireless communication network” may refer to a network conforming to any of the following communication standards, such as New Radio (NR, New Radio), Long Term Evolution (LTE, Long Term Evolution), Enhanced Long-term evolution (LTE-A, LTE-Advanced), wideband code division multiple access (WCDMA, Wideband Code Division Multiple Access), high-speed packet access (HSPA, High-Speed Packet Access), etc.
  • NR New Radio
  • New Radio Long Term Evolution
  • LTE-A Long-term evolution
  • LTE-A Long-term evolution
  • WCDMA Wideband Code Division Multiple Access
  • HSPA High-Speed Packet Access
  • the communication between devices in the communication system can be carried out according to any stage of communication protocols, such as but not limited to the following communication protocols: 1G (generation), 2G, 2.5G, 2.75G, 3G, 4G, 4.5G and 5G , New Radio (NR, New Radio), etc., and/or other communication protocols that are currently known or will be developed in the future.
  • Network device refers to, for example, a device in a communication system that connects a terminal device to a communication network and provides services for the terminal device.
  • Network equipment may include but not limited to the following equipment: integrated access and backhaul node (IAB-node), base station (BS, Base Station), access point (AP, Access Point), sending and receiving point (TRP, Transmission Reception Point), broadcast transmitter, mobile management entity (MME, Mobile Management Entity), gateway, server, radio network controller (RNC, Radio Network Controller), base station controller (BSC, Base Station Controller), etc.
  • IAB-node integrated access and backhaul node
  • BS Base Station
  • AP access point
  • TRP Transmission Reception Point
  • MME mobile management entity
  • MME Mobile Management Entity
  • gateway server
  • RNC Radio Network Controller
  • BSC Base Station Controller
  • the base station may include but not limited to: Node B (NodeB or NB), evolved Node B (eNodeB or eNB), and 5G base station (gNB), etc., and may also include Remote Radio Head (RRH, Remote Radio Head) , Remote Radio Unit (RRU, Remote Radio Unit), relay (relay) or low-power nodes (such as femeto, pico, etc.).
  • Node B Node B
  • eNodeB or eNB evolved Node B
  • gNB 5G base station
  • RRH Remote Radio Head
  • RRU Remote Radio Unit
  • relay relay
  • low-power nodes such as femeto, pico, etc.
  • base station may include some or all of their functions, each base station may provide communication coverage for a particular geographic area.
  • the term "cell” can refer to a base station and/or its coverage area depending on the context in which the term is used.
  • the term "User Equipment” (UE, User Equipment) or “terminal equipment” (TE, Terminal Equipment or Terminal Device), for example, refers to a device that accesses a communication network through a network device and receives network services.
  • a terminal device may be fixed or mobile, and may also be called a mobile station (MS, Mobile Station), a terminal, a subscriber station (SS, Subscriber Station), an access terminal (AT, Access Terminal), a station, etc.
  • the terminal equipment may include but not limited to the following equipment: Cellular Phone (Cellular Phone), Personal Digital Assistant (PDA, Personal Digital Assistant), wireless modem, wireless communication equipment, handheld equipment, machine-type communication equipment, laptop computer, Cordless phones, smartphones, smart watches, digital cameras, and more.
  • Cellular Phone Cellular Phone
  • PDA Personal Digital Assistant
  • wireless modem wireless communication equipment
  • handheld equipment machine-type communication equipment
  • laptop computer Cordless phones
  • Cordless phones smartphones, smart watches, digital cameras, and more.
  • the terminal device can also be a machine or device for monitoring or measurement, such as but not limited to: a machine type communication (MTC, Machine Type Communication) terminal, Vehicle communication terminal, device to device (D2D, Device to Device) terminal, machine to machine (M2M, Machine to Machine) terminal, etc.
  • MTC Machine Type Communication
  • Vehicle communication terminal device to device (D2D, Device to Device) terminal
  • M2M Machine to Machine
  • network side refers to one side of the network, which may be a certain base station, or may include one or more network devices as above.
  • user side or “terminal side” or “terminal device side” refers to a side of a user or a terminal, which may be a certain UE, or may include one or more terminal devices as above.
  • the high-level signaling may be, for example, radio resource control (RRC) signaling; for example, it is called an RRC message (RRC message), for example including MIB, system information (system information), and a dedicated RRC message; or It is called RRC IE (RRC information element).
  • RRC radio resource control
  • the high-level signaling may also be, for example, F1-C signaling, or the F1AP protocol. But the present application is not limited thereto.
  • multiple UEs are connected to the IAB-donor through a multi-hop IAB node, and finally access a network, such as a 5G network.
  • FIG. 2 shows an example of a topology transmission path in the scenario of inter-CU topology redundancy.
  • Donor-CU1 in Figure 2 is also called IAB-donor-CU1
  • Donor-CU2 is also called IAB-donor-CU2.
  • Donor-CU1 is the F1 terminating host of IAB node 3 and IAB node 4 .
  • IAB node 3 is a dual-connection node, and it has two paths to reach Donor-CU1.
  • IAB node 4 may also have two paths to reach Donor-CU1.
  • IAB node 4 as an access (access) IAB node as an example, some data between IAB node 4 and Donor-CU1 is transmitted through the topology network controlled by Donor-CU1 (called the first path, as shown by the solid arrow ), some data is transmitted through the topology network controlled by Donor-CU2 (called the second path, as shown by the dotted arrow), so as to achieve the purpose of data distribution and load balancing.
  • the IAB node 3 and other descendant nodes (not shown in the figure) of the IAB node 3 may also serve as access IAB nodes to establish the second path.
  • IAB node 1 is the first parent node of IAB node 3
  • IAB node 2 is the second parent node of IAB node 3
  • IAB node 4 is a descendant node of IAB node 3 .
  • the UE below the IAB node 4 is not shown in the figure.
  • the first IAB-donor-CU may be Donor-CU1 in FIG. 2
  • the second IAB-donor-CU may be Donor-CU2 in FIG. 2
  • the IAB node may be the In the IAB node 3
  • the descendant node of the IAB node 3 can be the IAB node 4 in Figure 2
  • the first parent node of the IAB node 3 can be the IAB node 1 in Figure 2
  • the second parent node of the IAB node 3 can be IAB node 2 in Fig.
  • the first parent node of IAB node 3 (for example, IAB node 1) is the node in the topology of the first IAB-donor-CU
  • the second parent node of IAB node 3 (for example, IAB node 2) is a node within the topology of the second IAB-donor-CU.
  • the second IAB-donor-DU may be Donor-DU2 in FIG. 2 .
  • IAB node 3 is connected to the first parent node (for example, IAB node 1), and IAB node 3 is connected to the second parent node (for example, IAB node 1). Node 2) is connected.
  • the IAB node 3 and the second parent node may be in a connected state, It may also be a state of not yet connected (that is, about to be connected).
  • the access IAB node includes an IAB node (for example, the IAB node 3 in FIG. 2 ) and/or a descendant node of the IAB node (for example, the IAB node 4 in FIG. 2 ), or, Become a dual-connected IAB node (eg, a node to be connected to a first IAB-donor-CU and a second IAB-donor-CU).
  • IAB node for example, the IAB node 3 in FIG. 2
  • a descendant node of the IAB node for example, the IAB node 4 in FIG. 2
  • Become a dual-connected IAB node eg, a node to be connected to a first IAB-donor-CU and a second IAB-donor-CU.
  • a node in the topology of the Donor-CU means that the DU part of the node is managed by the Donor-CU, that is, the F1 interface of the node is terminated on the Donor-CU.
  • Donor-CU and IAB-donor-CU have the same meaning, and the two can be interchanged.
  • Embodiments of the first aspect of the present application provide a method for sending and receiving signals.
  • the method is applied to a first integrated access and backhaul node donor central unit (IAB-donor-CU).
  • IAB-donor-CU integrated access and backhaul node donor central unit
  • the embodiment of the first aspect of the present application describes the method for sending and receiving signals from the side of the first IAB-donor-CU.
  • the first IAB-donor-CU may be, for example, Donor-CU1 in FIG. 2 .
  • Fig. 3 is a schematic diagram of a method for sending and receiving signals according to an embodiment of the first aspect. As shown in Fig. 3, the method includes:
  • Operation 301 Send a traffic offload request to the second IAB-donor-CU.
  • Operation 302 Receive a reply of agreeing to traffic offloading or a reply of denying traffic offloading sent by the second IAB-donor-CU.
  • operation 301 and operation 302 can support topology redundancy between the first IAB-donor-CU and the second IAB-donor-CU, so that the diversity of paths can be further improved and the load can be better satisfied Balanced needs.
  • the traffic offloading request sent in operation 301 includes a request to establish a cross-host redundant path for the IAB node and/or a descendant node of the IAB node.
  • the first IAB-donor-CU configures the configuration of the backhaul radio link control (BH RLC) channel and the configuration of the routing table of the BAP sublayer between the IAB node and the descendant node of the IAB node, for supporting the first
  • the routing of the two paths and the BH RLC channel mapping are thus used to establish redundant paths for descendant nodes;
  • the first IAB-donor-CU can also perform BAP routing identifier mapping for the IAB nodes according to the reply of agreeing to traffic offloading configuration whereby, at an IAB node, a BAP route translation between the topology of a first path controlled by a first IAB-donor-CU and the topology of a second path controlled by a second IAB-donor-CU can be performed, thereby providing The descendant node establishes a redundant path;
  • the first IAB-donor-CU can also pass the user equipment context modification request (UE CONTEXT MODIFICATION REQUEST) message or the user equipment context establishment request
  • the reply agreeing to traffic offloading in operation 302 may indicate at least partially accepting the traffic offloading request.
  • partially accepting the traffic offloading request means: establishing redundant paths for some F1-C channels associated with the TNL, or establishing redundant paths for some F1-U channels.
  • the traffic offloading request may be included in the traffic offloading request message, and the traffic offloading request message is for example It is a TRAFFIC OFFLOAD REQUEST message, or a Redundant Path Establishment Request message, etc.;
  • the reply agreeing to traffic offloading can be included in the traffic offloading request acceptance message, such as the TRAFFIC OFFLOAD REQUEST ACKNOWLEDGE message;
  • the reply of rejecting traffic offloading It may be included in a traffic offload rejection message, such as a TRAFFIC OFFLOAD REQUEST REJECT message.
  • the traffic offloading request message may include an identification (UE XnAP ID) of the user equipment of the traffic offloading initiating node on the Xn interface, and/or identification information of one or more F1-Cs.
  • the traffic unloading initiating node refers to the first IAB-donor-CU; the user equipment refers to the access IAB node (the IAB node is used as the user equipment of the IAB-donor); the identification information of the F1-C is used for accessing the IAB node
  • One or more F1-Cs establish redundant paths.
  • the traffic offload request message includes at least one of the following information: the UE XnAP ID of the traffic offload initiating node, the BAP address of the access IAB node, the TNL address, and one or more F1-U channel identifiers information, IP header information (IP header information) of F1-C and/or each F1-U channel, and quality of service (Quality of Service, QoS) information of each F1-U channel.
  • IP header information IP header information
  • QoS Quality of Service
  • the traffic offloading request acceptance message may include at least one of the following information:
  • the UE XnAP ID of the traffic offloading initiating node the UE XnAP ID of the traffic offloading receiving node, the identification information of the F1-C and/or F1-U channel, the TNL address newly allocated for the DU connected to the IAB node, and the F1- BH RLC channel identity for C and/or F1-U channel configuration on the link between the dual-connected IAB node and the second parent node, BAP address of the second parent node, topology controlled by the second IAB-donor-CU
  • the BAP routing identifier in the second BAP address of the IAB node.
  • the traffic offloading receiving node refers to the second IAB-donor-CU; the traffic offloading receiving node UE XnAP ID refers to the Xn interface identifier of the accessing IAB node in the node of the second IAB-donor-CU.
  • the UE XnAP ID of the traffic offloading initiating node and the UE XnAP ID of the traffic offloading receiving node can also be called M-NG-RAN node UE XnAP ID (the UE XnAP ID of the main base station node) respectively. ID) or S-NG-RAN node UE XnAP ID (UE XnAP ID of the secondary base station node).
  • the second IAB-donor-CU sends a traffic offloading request rejection message, and the traffic offloading request rejection message includes The UE XnAP ID of the traffic offloading initiating node.
  • the IAB node when the IAB node is connected to the first parent node, and the IAB node is also connected to the second parent node: if the first IAB-donor-CU is a master node (MN), the traffic offload request and the content of the reply agreeing to the traffic offloading or the reply denying the traffic offloading are used as information elements (IE), and are included in the message of the S-NG-RAN node Modification Preparation process of the XnAP.
  • MN master node
  • IE information elements
  • the content of the traffic offloading request and the reply of agreeing to traffic offloading or rejecting the traffic offloading can be used as an information element (IE) and be included in the message of the SeNB node addition preparation (S-NG-RAN node Addition Preparation) process of XnAP.
  • IE information element
  • the traffic offloading request may be included in the request to add a secondary node (S-NODE ADDITION REQUEST) message sent by the first IAB-donor-CU to the second IAB-donor-CU; for another example, the reply agreeing to traffic offloading may be Included in the SN addition request acceptance (S-NODE ADDITION REQUEST ACKNOWLEDGE) message sent by the second IAB-donor-CU to the first IAB-donor-CU.
  • S-NODE ADDITION REQUEST secondary node
  • the reply agreeing to traffic offloading may be Included in the SN addition request acceptance (S-NODE ADDITION REQUEST ACKNOWLEDGE) message sent by the second IAB-donor-CU to the first IAB-donor-CU.
  • the method also includes:
  • Operation 303 Send a first RRC reconfiguration message to the IAB node and/or a descendant IAB node of the IAB node according to the reply of agreeing to traffic offloading.
  • the first RRC reconfiguration message may include: a distribution unit that is an IAB node (for example, IAB node 3 in FIG. 2 ) and/or a descendant node of the IAB node (for example, IAB node 4 in FIG. 2 ).
  • a distribution unit that is an IAB node (for example, IAB node 3 in FIG. 2 ) and/or a descendant node of the IAB node (for example, IAB node 4 in FIG. 2 ).
  • DU At least one transport network layer (transport network layer, TNL, or transport layer) address allocated respectively, the TNL address is anchored in the second IAB-donor-DU within the topology of the second IAB-donor-CU (for example , Donor-DU2 in Figure 2).
  • the BAP configuration information element (bap-Config IE) of the first RRC reconfiguration message includes a field for indicating the second BAP address configured for the IAB node, such as bap-Address-redundant, or bap-Address-second, etc., are used to indicate that it is the second BAP address; or, the BAP address field in the BAP configuration information element (bap-Config IE) of the first RRC reconfiguration message includes a list, and each entry in the list is A BAP address and its associated information.
  • the list can be bap-AddressList.
  • Each entry in the list is a BAP address and its associated information.
  • Each entry is, for example, ⁇ bap-Address,'MCG'/'SCG ' ⁇ , or ⁇ bap-Address,iab-donor-DU-BAP-Address ⁇ , etc.
  • the IAB node 3 can be assigned a second BAP address, which can be used for BAP routing configuration on the redundant path (ie, the second path passing through Donor-DU2).
  • the first IAB-donor-CU may add the new TNL address to the IAB node and/or The DU of its descendant node is associated with the F1-C of the first IAB-donor-CU.
  • the method for sending and receiving signals may also include:
  • the first IAB-donor-CU sends or receives a redundant path release request
  • the first IAB-donor-CU receives or sends a redundant path release request acceptance message.
  • the first IAB-donor-CU sends a redundant path release request to the second IAB-donor-CU, and the first IAB-donor-CU receives a redundant path release request acceptance message from the second IAB-donor-CU; and
  • the first IAB-donor-CU receives a redundant path release request sent by the second IAB-donor-CU, and the first IAB-donor-CU sends a redundant path release request acceptance message to the second IAB-donor-CU.
  • the redundant path release request includes: the UE XnAP ID of the node initiating traffic offloading, the UE XnAP ID of the node accepting traffic offloading, the TNL address associated with the F1-C that needs to be released, or needs to be released User plane transport layer information (UP Transport Layer Information) of the F1-U channel of the redundant path.
  • the redundant path is, for example, the second path shown in FIG. 2 .
  • the redundant path release request both the content and the content of the redundant path release request acceptance message are taken as IEs and included in the SeNB node modification preparation (S-NG-RAN node Modification Preparation) process.
  • the embodiment of the first aspect of the present application it is possible to support the establishment of a topology redundant path between the first IAB-donor-CU and the second IAB-donor-CU, thereby further improving path diversity and better satisfying The requirement of load balancing; in addition, the topology redundant path between the first IAB-donor-CU and the second IAB-donor-CU can also be released.
  • the embodiment of the second aspect of the present application provides a method for sending and receiving signals, corresponding to the method of the embodiment of the first aspect.
  • the method for sending and receiving signals of the embodiment of the second aspect of the present application is applied to a second integrated access and backhaul node donor central unit (IAB-donor-CU).
  • IAB-donor-CU integrated access and backhaul node donor central unit
  • the embodiment of the second aspect of the present application describes the method for sending and receiving signals from the side of the second IAB-donor-CU.
  • the second IAB-donor-CU may be, for example, Donor-CU2 in FIG. 2 .
  • Fig. 4 is a schematic diagram of a method for sending and receiving signals according to an embodiment of the second aspect. As shown in Fig. 4, the method includes:
  • Operation 401 Receive a traffic offload request sent by the first IAB-donor-CU;
  • Operation 402 Send a reply of agreeing to traffic offloading or a reply of denying traffic offloading to the first IAB-donor-CU.
  • operation 401 and operation 402 can support topology redundancy between the first IAB-donor-CU and the second IAB-donor-CU, so that the diversity of paths can be further improved and the load can be better satisfied Balanced needs.
  • the traffic offloading request in operation 401 includes establishing redundancy for the IAB node (for example, IAB node 3 in FIG. Requests for remaining paths.
  • the reply agreeing to traffic offloading in operation 402 represents at least partially accepting the traffic offloading request.
  • partially accepting the traffic offloading request means: establishing redundant paths for some F1-Cs associated with some TNLs, or some F1-U channels.
  • the traffic offloading request can be included in the traffic offloading request message; the reply agreeing to the traffic offloading can be included in the traffic offloading request acceptance
  • the traffic offload request acceptance message may be, for example, a TRAFFIC OFFLOAD REQUEST ACKNOWLEDGE message; the reply to reject the traffic offload may be included in the traffic offload rejection message, and the traffic offload rejection message may be, for example, a TRAFFIC OFFLOAD REQUEST REJECT.
  • the traffic offloading request message may include the identification (UE XnAP ID) of the user equipment on the Xn interface of the traffic offloading initiating node, and/or identification information of one or more F1-Cs.
  • the identification information of the F1-C is used to establish a redundant path for one or more F1-Cs connected to the IAB node, the connected IAB node includes the IAB node and/or the descendant node of the IAB node, or is about to become a dual connection The IAB node.
  • the traffic offloading request message may include at least one of the following information: the UE XnAP ID of the traffic offloading initiating node, the BAP address of the access IAB node, the TNL address, one or more F1-U channel identification information, F1-C and /or IP header information (IP header information) of each F1-U channel, and service quality (QoS) information of each F1-U channel.
  • the traffic offloading request acceptance message may include at least one of the following information:
  • the UE XnAP ID of the initiating node of traffic offloading the UE XnAP ID of the receiving node of traffic offloading, the identification information of the F1-C and/or F1-U channel, the TNL address newly allocated for the DU connected to the IAB node, and the F1-C and/or F1-U channel / or the BH RLC channel identity on the link between the dual-connected IAB node and the second parent node configured by the F1-U channel, the BAP address of the second parent node, the topology of the second IAB-donor-CU control BAP routing identifier, the second BAP address of the IAB node.
  • the traffic offloading receiving node refers to the second IAB-donor-CU; the traffic offloading receiving node UE XnAP ID refers to the Xn interface identifier of the accessing IAB node in the node of the second IAB-donor-CU.
  • the second IAB-donor-CU may send a traffic offload request reject message to the first IAB-donor-CU, the traffic offload request reject The message may include the UE XnAP ID of the traffic offloading initiating node.
  • the IAB node when the IAB node is connected to the first parent node, and the IAB node is connected to the second parent node: if the first IAB-donor-CU is a master node (MN), then the traffic offload request and the content of the reply agreeing to the traffic offloading or the reply denying the traffic offloading can be used as an information element (IE) and included in the message of the XnAP SeNB node modification preparation (S-NG-RAN node Modification Preparation) process.
  • IE information element
  • the content of the traffic offloading request and the reply of agreeing to traffic offloading or rejecting the reply of traffic offloading can be used as an information element (IE) and included in the message of the SeNB node addition preparation (S-NG-RAN node Addition Preparation) process of XnAP.
  • IE information element
  • the traffic offloading request is included in the request to add a secondary node (S-NODE ADDITION REQUEST) message sent by the first IAB-donor-CU to the second IAB-donor-CU.
  • the reply agreeing to traffic offloading is included in the SN addition request acceptance (S-NODE ADDITION REQUEST ACKNOWLEDGE) message sent by the second IAB-donor-CU to the first IAB-donor-CU.
  • the method also includes:
  • the second IAB-donor-CU sends a user equipment context modification request (UE CONTEXT MODIFICATION REQUEST) message to the second parent node to modify the IAB node mobile terminal (MT ) user equipment (UE) context, and set at least one bearer (bearer); or
  • the second IAB-donor-CU sends a UE CONTEXT SETUP REQUEST message to the second parent node to establish the UE of the MT of the IAB node context, and set at least one bearer.
  • the method also includes:
  • the second IAB-donor-CU configures the BH RLC channel from the IAB node to the second IAB-donor-DU for the second path required by the IAB node and/or the descendant node of the IAB node And the configuration of the routing table of the BAP sublayer.
  • the method also includes:
  • the second IAB-donor-CU sends the address of the second BAP configured for the IAB node to the mobile terminal (MT) of the IAB node.
  • the second IAB-donor-CU may send a second reconfiguration (RRCReconfiguration) message to the mobile terminal (MT) of the IAB node, where the second RRCReconfiguration message includes BAP configuration information (bap-Config),
  • the BAP configuration information includes the address of the second BAP configured for the IAB node.
  • the second path can be set for the IAB node.
  • the method also includes:
  • the second IAB-donor-CU receives or sends a redundant path release request
  • the second IAB-donor-CU sends or receives a redundant path release request acceptance message.
  • the second IAB-donor-CU receives the redundant path release request sent by the first IAB-donor-CU, and in operation 408, the second IAB-donor-CU sends the first IAB-donor-CU Send a redundant path release request acceptance message.
  • the second IAB-donor-CU sends a redundant path release request to the first IAB-donor-CU, and in operation 408, the second IAB-donor-CU receives the first IAB-donor-CU Sent redundant path release request acceptance message.
  • the redundant path release request in operation 407 includes: the UE XnAP ID of the traffic offloading initiating node, the UE XnAP ID of the traffic offloading accepting node, the TNL address associated with the F1-C that needs to release the redundant path, or The user plane transport layer information (UP Transport Layer Information) of the F1-U channel that needs to release the redundant path.
  • the redundant path is, for example, the second path shown in FIG. 2 .
  • both the content of the redundant path release request and the message content of the redundant path release request acceptance can be As an IE, it is included in the SeNB node modification preparation (S-NG-RAN node Modification Preparation) process.
  • the embodiment of the second aspect of the present application it is possible to support the establishment of a topology redundant path between the first IAB-donor-CU and the second IAB-donor-CU, thereby further improving path diversity and better satisfying The requirement of load balancing; in addition, the topology redundant path between the first IAB-donor-CU and the second IAB-donor-CU can also be released.
  • an IAB node (for example, IAB node 3 in FIG. 2 ) is in a state of being dual-connected to two different IAB-donor-CUs. Therefore, in Embodiment 1, IAB node 3 is also referred to as Dual-connecting IAB-node.
  • the F1 termination node may be the MN or the SN.
  • the first IAB-donor-CU (for example, IAB-donor-CU1 in FIG. 2 ) is an F1 termination node, which may be a master node (MN) or a secondary node in this embodiment. Node (secondary node, SN).
  • the second IAB-donor-CU (for example, IAB-donor-CU2 in Figure 2) is a non-F1-terminating (non-F1-terminating) node, which can be an SN or an MN in this embodiment .
  • FIG. 5 is a schematic diagram of the establishment process of the second path of the IAB node in Embodiment 1. As shown in Figure 5, the establishment process includes the following steps:
  • IAB-donor-CU1 initiates a traffic offload request (for example, TRAFFIC OFFLOAD REQUEST) to IAB-donor-CU2, that is, a request to establish a redundant path for a dual-connection IAB node. If IAB-donor-CU2 refuses, IAB-donor-CU2 directly sends a reply of rejecting traffic offloading, and does not perform the following steps.
  • a traffic offload request for example, TRAFFIC OFFLOAD REQUEST
  • the IAB-DU of the second parent node of the dual-connection IAB node responds to IAB-donor-CU2 with a UE CONTEXT MODIFICATION RESPONSE message.
  • the IAB-donor-CU2 sends a downlink radio link control message transmission (for example, DL RRC MESSAGE TRANSFER) message to the IAB-DU of the second parent node, wherein Contains the generated RRCReconfiguration message.
  • the RRCReconfiguration message may include bap-Config, which contains the configured second BAP address.
  • the second parent node forwards the received RRCReconfiguration message to the dual connectivity IAB-MT.
  • the dual-connection IAB-MT responds to the second parent node with an RRC configuration complete (RRCReconfigurationComplete) message.
  • the second parent node sends an uplink radio link control message transfer (UL RRC MESSAGE TRANSFER) message to the IAB-donor-CU2, which contains the received RRCReconfigurationComplete message.
  • UL RRC MESSAGE TRANSFER uplink radio link control message transfer
  • IAB-donor-CU2 responds to IAB-donor-CU1 with a message agreeing to traffic offloading.
  • IAB-donor-CU1 According to the response message content of IAB-donor-CU2 (for example, the assigned TNL address, etc.), IAB-donor-CU1 sends a DL RRC MESSAGE TRANSFER message to the IAB-DU of the first parent node, which contains the generated RRCReconfiguration message.
  • This RRCReconfiguration message may contain one or more TNL addresses allocated for the dual connectivity IAB-DU, which are anchored in the IAB-donor-DU of the second path (eg, Donor-DU2 in Figure 2).
  • IAB-donor-CU2 can actively obtain these TNL addresses from Donor-DU2.
  • the assigned TNL address is the outer IP address. If a redundant path has been established for the F1-C or F1-U of the dual-connection IAB node before, and the TNL address has been allocated, there is no need to allocate it again.
  • the first parent node forwards the received RRCReconfiguration message to the dual connectivity IAB-MT.
  • the dual-connectivity IAB-MT responds with an RRCReconfigurationComplete message to the second parent node.
  • the first parent node sends a UL RRC MESSAGE TRANSFER message to IAB-donor-CU2, which conveys the received RRCReconfigurationComplete message.
  • IAB-donor-CU1 can configure new UL BH information (uplink feedback information) for the F1AP message of the second path.
  • the specific process can be implemented, for example, through the gNB-DU Configuration Update process of F1AP.
  • IAB-donor-CU1 can migrate the F1-U channel from IAB-donor-CU1 to dual-connection IAB-DU from the first path to the second path through the UE CONTEXT MODIFICATION REQUEST message.
  • the dual connection IAB-DU replies to the UE CONTEXT MODIFICATION RESPONSE message.
  • the second path of the dual-connection IAB node can be established, and uplink user data (uplink user data) or downlink user data (downlink user data) can pass through the second path between the user equipment (UE) and the first IAB-donor- Transfer between CUs.
  • uplink user data uplink user data
  • downlink user data downlink user data
  • the transmission sequence of uplink user data is: UE—dual connection IAB node—second parent node—intermediate hop IAB node (Intermediate hop IAB node) on the second path -donor on the second path)—the host distributed unit on the second path (for example, Donor-DU2 in Figure 2)——the first IAB-donor-CU.
  • the transmission sequence of downlink user data is: the first IAB-donor-CU—the donor distributed unit on the second path (for example, Donor-DU2 in FIG. 2 )——Intermediate hop IAB-donor on the second path (Intermediate hop IAB-donor on the second path)——second parent node——dual connection IAB node——UE.
  • step 4-7 is to allocate the second BAP address for the dual connectivity IAB node.
  • the second BAP address can be used for BAP routing configuration on the redundant path (ie, the second path).
  • the dual-connection IAB node needs to associate the BAP address with the primary cell group (master cell group, MCG)/secondary cell group (secondary cell group, SCG) or MN/SN.
  • the received BAP address is related to MCG or MN If the RRCReconfiguration message with the BAP address received by the dual-connectivity node is from the SCG or through SRB3, associate the received BAP address with the SCG or SN.
  • SRB signaling radio bearer, signaling radio bearer
  • steps 4-7 may be removed, and the second BAP address may be sent in steps 10 to 13 together with other RRC configuration messages.
  • steps 4-7 may be removed, and the second BAP address may be sent in steps 10 to 13 together with other RRC configuration messages.
  • the existing RRCReconfiguration message format needs to be modified. There are two modification methods:
  • Method 1 Add a field in the bap-Config IE (information element: information element) of the RRCReconfiguration message, such as bap-Address-redundant, or bap-Address-second, etc., indicating that this field represents the second BAP address.
  • bap-Config IE information element: information element
  • Method 2 Change the bap-Address field in the bap-Confg IE of the RRCReconfiguration message to a list, such as bap-AddressList.
  • Each entry in the list is a BAP address and its associated information.
  • the entry is, for example, ⁇ bap-Address, 'MCG'/'SCG' ⁇ , or ⁇ bap-Address, iab-donor-DU-BAP-Address ⁇ , etc.
  • the IAB node (for example, IAB node 3 in FIG. 2 ) is in a state of being dual-connected to two different IAB-donor-CUs, therefore, in Embodiment 2, IAB node 3 is also referred to as Dual-connecting IAB-node.
  • Embodiment 2 is used to illustrate a method for establishing a redundant path between hosts for a descendant node of an IAB node (for example, the IAB node 4 in FIG. 2 ).
  • the establishment process includes the following steps:
  • the IAB-donor-CU1 initiates a traffic offloading request to the IAB-donor-CU2, and the request includes a request for establishing a redundant path for the descendant node of the dual-connection IAB node.
  • Steps 4 ⁇ 7 are the same as Steps 4 ⁇ 7 of Embodiment 1, in the case that the dual-connection IAB node or other descendant IAB nodes have not established redundant paths before, assign the second path to the dual-connection IAB node. BAP address.
  • steps 4-7 can be skipped and not executed.
  • the IAB-donor-CU2 configures the BH RLC channel and configures the routing table of the BAP sublayer from the dual-connected IAB node to the IAB-donor-DU2 for the descendant node on the second path. It is the same as the method for dual-connection IAB nodes in Embodiment 1.
  • IAB-donor-CU1 configures one or more TNL addresses for descendant IAB nodes according to the reply message of IAB-donor-CU2, and the one or more TNL addresses are anchored in the IAB-donor-CU2 on donor-DU2.
  • IAB-donor-CU1 configures the BH RLC channel and the routing table of the BAP sublayer between the dual-connection IAB node and the descendant access IAB node (Configuration of BAP route and mapping rules along the path between dual- connecting IAB-node and the access IAB-node for the redundant path.), used to support routing and BH RLC channel mapping of the second path.
  • IAB-donor-CU1 also configures BAP routing ID mapping (Configuration of BAP routing ID mapping) for dual-connection IAB nodes based on the response message of IAB-donor-CU2 (for example, sent in step 9), for two BAP route translation between topologies. These configurations can be done earlier, such as directly after step 10.
  • step 10 add these addresses to the F1-C association between descendant IAB-DU and IAB-donor-CU1.
  • the IAB-donor-CU1 can configure new uplink backhaul information (UL BH information) for the F1AP message of the second path.
  • UL BH information new uplink backhaul information
  • IAB-donor-CU1 can migrate its F1-U channel to the descendant IAB-DU of the dual-connection IAB node from the first path to the second path through the UE CONTEXT MODIFICATION REQUEST message.
  • the descendant IAB-DU replies to the UE CONTEXT MODIFICATION RESPONSE message.
  • the second path of the descendant node of the dual-connection IAB node can be established, and uplink user data (uplink user data) or downlink user data (downlink user data) can pass through the second path between the user equipment (UE) and the first IAB -Transfer between donor-CUs.
  • uplink user data uplink user data
  • downlink user data downlink user data
  • the transmission sequence of uplink user data is: UE—descendant node—dual connection IAB node—second parent node—intermediate hop IAB node on the second path (Intermediate hop IAB-donor on the second path)—the host distributed unit on the second path (for example, Donor-DU2 in Figure 2)——the first IAB-donor-CU.
  • the transmission sequence of downlink user data is: the first IAB-donor-CU—the donor distributed unit on the second path (for example, Donor-DU2 in FIG. 2 )——intermediate hop IAB-donor on the second path (Intermediate hop IAB-donor on the second path)——second parent node——dual connection IAB node——descendant node——UE.
  • the process of establishing redundant paths for descendant IAB nodes may be performed after establishing redundant paths for dual-connectivity IAB nodes, that is, the process in FIG. 6 may be performed after the process in FIG. 5 .
  • the process of establishing redundant paths for descendant IAB nodes may be performed at the same time as establishing redundant paths for dual-connectivity IAB nodes, that is, the process in FIG. 6 may be performed simultaneously with the process in FIG. 5 .
  • the IAB node (for example, the IAB node 3 in FIG. 2 ) is a single-connection node, that is, the IAB node is connected to the IAB-donor-CU1.
  • IAB-donor-CU1 judges that the traffic of this topology network is overloaded and needs to use the network topology managed by other Donor-CUs to unload traffic
  • the IAB node is added to the SN (for example, IAB-donor-CU2 in Figure 2)
  • the operation is to make the IAB node become a cross-host (ie, inter-CU) dual connection, and offload part of the traffic to the IAB-donor-CU2 topology to establish a redundant path.
  • FIG. 7 shows a schematic diagram of adding an SN to an IAB node to become a dual-connectivity node and establishing a redundant path.
  • the steps of assigning the second BAP address by the IAB node in the dual connectivity state can refer to steps 5-7 in FIG. 5 , and thus are not shown in FIG. 7 .
  • the difference between the process shown in FIG. 7 and that in FIG. 5 will be mainly described, and the similarities will not be described repeatedly.
  • the process flow in Figure 7 includes the following steps:
  • IAB-MT sends a measurement report (for example, MeasurementReport) message to the IAB-DU of the first parent node, and the report can be based on the measurement configuration (for example, Measurement Configuration) received from IAB-donor-CU1 before the IAB-MT ) produced.
  • a measurement report for example, MeasurementReport
  • the IAB-DU of the first parent node sends a UL RRC MESSAGE TRANSFER message to IAB-donor-CU1 to transmit the received MeasurementReport.
  • IAB-donor-CU1 initiates a request (S-NODE ADDITION REQUEST) message to add SN to IAB-donor-CU2, which contains a request for traffic offloading, that is, an IAB node (for example, IAB node 3 in Figure 2 ) to establish a request for redundant paths. See Embodiment 4 for specific signaling. If the IAB-donor-CU2 rejects the request to add an SN, it can send a reply rejecting traffic offloading, and does not need to perform the following steps.
  • IAB-donor-CU2 If IAB-donor-CU2 agrees to the request to add an SN, but rejects the request for traffic offloading, proceed directly to the process of adding an SN according to the existing standard, and the reply message includes the content of rejecting the traffic offloading, and the following steps are not required.
  • the IAB-donor-CU2 sends a UE CONTEXT SETUP REQUEST message to the IAB-DU of the second parent node of the IAB node, which is used to establish the UE context of the IAB-MT and set one or more Bearer (bearer), the one or more bearers can be used for IAB-MT's own signaling and optional data traffic.
  • Bearer bearer
  • the IAB-DU of the second parent node of the IAB node responds to the IAB-donor-CU2 with a UE CONTEXT SETUP RESPONSE message.
  • IAB-donor-CU2 responds to IAB-donor-CU1 with an SN addition request acceptance (S-NODE ADDITION REQUEST ACKNOWLEDGE) message, which includes an IE that agrees to traffic offloading.
  • S-NODE ADDITION REQUEST ACKNOWLEDGE SN addition request acceptance
  • IAB-donor-CU1 sends a secondary node reconfiguration complete (for example, S-NODE RECONFIGURATION COMPLETE) message to IAB-donor-CU2, indicating that the dual connection configuration for the IAB node is successfully completed.
  • a secondary node reconfiguration complete for example, S-NODE RECONFIGURATION COMPLETE
  • the IAB node performs a random access procedure in the IAB-DU of the second parent node.
  • step 3 if the message in step 3 also includes a request to establish a redundant path for the descendant IAB node, corresponding operations can be performed with reference to Embodiment 2.
  • Embodiment 4 illustrates the signaling between IAB-donor-CU1 and IAB-donor-CU2, that is, the XnAP (Xn Application Protocol, Xn Application Protocol) process.
  • IAB-donor-CU1 sends a traffic offload request to IAB-donor-CU2, which is used to migrate a certain F1-C or one or more F1-U channels to the topology redundant path of IAB-donor--CU2.
  • FIG. 8 is a schematic diagram of a successful traffic offloading process.
  • NG-RAN node 1 that is, IAB-donor-CU1
  • NG-RAN node 2 that is, IAB-donor-CU2
  • TRAFFIC OFFLOAD REQUEST message a message of a traffic offload request
  • the NG-RAN node 2 replies with an accepted or partially accepted message, such as a TRAFFIC OFFLOAD REQUEST ACKNOWLEDGE message.
  • Partial acceptance refers to the establishment of redundant paths for some TNL-associated F1-Cs, or some F1-U channels.
  • Fig. 9 is a schematic diagram of failure of the traffic offloading process.
  • NG-RAN node 1 that is, IAB-donor-CU1
  • NG-RAN node 2 that is, IAB-donor-CU2
  • the traffic offloading rejection message may be called a TRAFFIC OFFLOAD REQUEST REJECT message, which may include a failure reason (cause).
  • the UE XnAP ID of the traffic offloading initiating node and/or identification information of one or more F1-Cs may be included in the traffic offloading request message.
  • redundant paths can be established for one or more access IAB nodes.
  • These access IAB nodes may be dual-connectivity IAB nodes or IAB nodes that will soon become dual-connectivity IAB nodes, or may be descendant IAB nodes of the dual-connectivity IAB nodes.
  • the traffic offload request message may also include the BAP address of the access IAB node.
  • the F1-C identification information may be TNL association (association), and may also be TNL-associated transport layer information (for example, IAB-DU control plane transport layer address, that is, TNL address). It may explicitly indicate that the F1-C traffic offload is performed on the TNL association, or it may implicitly indicate that the F1-C traffic offload is performed on the TNL association by not providing the F1-U information.
  • the Traffic Offload Request Acknowledge message can include the UE XnAP ID of the node that initiates traffic offload, the UE XnAP ID of the node that receives traffic offload, the identification information of the F1-C, IAB-donor-DU2 The newly assigned TNL address for accessing the IAB-DU, the BH RLC channel identity configured for the F1-C on the link between the dual-connection IAB node and the second parent node, the BAP address of the second parent node, CU2 The BAP routing identifier (including uplink and downlink) in the topology of the control, the second BAP address of the possible dual-connection IAB node, etc.
  • the BAP address of the second parent node is used for Donor-CU1 to configure the next-hop node of the uplink route of the redundant path when configuring the routing table for the dual-connection IAB node.
  • the BAP routing identifier in the topology controlled by Donor-CU2 refers to the uplink or downlink BAP routing identifier between Donor-DU2 and the dual-connection IAB node, which is used when Donor-CU1 configures the BAP routing identifier mapping for the dual-connection IAB node .
  • the traffic offload request message may also contain one or more F1-U channels, that is, identification information of data radio bearers (data radio bearers, DRBs), indicating that redundant paths are established for these F1-U channels.
  • the F1-U channel identification information can be UP Transport Layer Information (user plane transport layer information), which includes transport layer address and GTP-TEID (GPRS Tunneling Protocol–Tunnel Endpoint ID).
  • the request message can also include the BAP address of the access IAB node, the TNL address, the IP header information (IP header information) of the F1-U, QoS information, etc.
  • the IP header information is used for traffic mapping from IP layer to layer 2 (layer 2) on Donor-DU2, and the QoS information is used for BH RLC channel selection and configuration in each hop of the redundant path.
  • the QoS information can be the DRB QoS IE defined in TR38.473, or part of the information in the IE, such as 5QI (5G QoS Identifier).
  • the Traffic Offload Request Acknowledge message can include the identification information of the accepted F1-U channel, the dual-connection IAB node and the second parent node configured for the F1-U channel BH RLC channel identification on the link between nodes, can also contain new TNL address, BAP address of the second parent node, BAP routing identification (both uplink and downlink) in the topology controlled by CU2, possible dual connectivity IAB The node's second BAP address, etc.
  • the content of these requests and reply messages can also be used as IE, included in the existing XnAP S-NG-RAN node Modification Preparation (Secondary base station node modification preparation ) process. That is, reuse existing messages, such as S-NODE MODIFICATION REQUEST, S-NODE MODIFICATION REQUEST ACKNOWLEDGE, S-NODE MODIFICATION REJECT, etc. Among them, when reusing existing messages, if all traffic offloading requests are rejected, but any other modification requests are agreed, the S-NODE MODIFICATION REQUEST ACKNOWLEDGE message is still used. The S-NODE MODIFICATION REJECT message is used only if the arbitrary modification request is not agreed and the arbitrary traffic offloading request is not agreed, or fails.
  • S-NODE MODIFICATION REJECT is used only if the arbitrary modification request is not agreed and the arbitrary traffic offloading request is not agreed, or fails.
  • the contents of these messages can be respectively used as IEs and included in the S-NG-RAN node Addition Preparation (secondary base station node addition preparation) process of the existing XnAP. That is to reuse existing messages, such as S-NODE ADDITION REQUEST, S-NODE ADDITION REQUEST ACKNOWLEDGE, S-NODE ADDITION REJECT, etc.
  • existing messages such as S-NODE ADDITION REQUEST, S-NODE ADDITION REQUEST ACKNOWLEDGE, S-NODE ADDITION REJECT, etc.
  • S-NODE MODIFICATION REJECT message is used only if the SN cannot be added or a failure occurs.
  • Embodiment 5 is used to illustrate the release process of the redundant path between IAB-donor-CU1 and IAB-donor-CU2.
  • Both NG-RAN node 1 (ie, IAB-donor-CU1 ) and NG-RAN node 2 (ie, IAB-donor-CU2 ) can initiate the release process of the redundant path.
  • a new dual-connection-related XnAP process can be added to realize the release process.
  • Both the initiator (for example, IAB-donor-CU1 ) and the receiver (for example, IAB-donor-CU2 ) of traffic offloading can propose redundant path release.
  • FIG. 10 is a schematic diagram of a redundant path release proposed by the traffic offloading initiator
  • FIG. 11 is a schematic diagram of a redundant path release proposed by the traffic offloading receiver.
  • the initiator of traffic offloading that is, the F1 terminating host node can send a TRAFFIC OFFLOAD RELEASE REQUEST message to a non-F1 terminating host node, and the non-F1 terminating host node replies with a traffic offload release acceptance (TRAFFIC OFFLOAD RELEASE ACKNOWLEDGE) message; as shown in Figure 11, the non-F1 termination host node can send a traffic offload release request (TRAFFIC OFFLOAD RELEASE REQUIRED) message to the F1 termination host node, and the F1 termination host node replies with the traffic offload release confirmation (TRAFFIC OFFLOAD RELEASE CONFIRM) message.
  • TRAFFIC OFFLOAD RELEASE REQUEST TRAFFIC OFFLOAD RELEASE REQUEST
  • TRAFFIC OFFLOAD RELEASE REQUIRED traffic offload release request
  • TRAFFIC OFFLOAD RELEASE CONFIRM traffic offload release confirmation
  • the TRAFFIC OFFLOAD RELEASE REQUEST/REQUIRED message contains the TNL address associated with the F1-C that needs to release the redundant path, or the UP Transport Layer Information of the F1-U channel that needs to release the redundant path.
  • the specific process of releasing the redundant path is: if necessary, Donor-CU1 and/or Donor-CU2 release the BAP routing entries related to the redundant path, modify or release the BH RLC channel required by the redundant path; if necessary, Donor-CU1 deletes The mapping information of the relevant BAP routing identifier on the dual-connectivity IAB node.
  • the contents of the above request and reply messages can also be used as IEs respectively, and included in the existing XnAP S-NG-RAN node Modification Preparation (secondary base station node modification preparation) process. That is to reuse existing messages, such as S-NODE MODIFICATION REQUEST, S-NODE MODIFICATION REQUEST ACKNOWLEDGE, etc.
  • the embodiment of the third aspect of the present application provides a method for sending and receiving signals, which corresponds to the method of the embodiment of the first aspect.
  • the method for sending and receiving signals in the embodiment of the third aspect of the present application is applied to an IAB node, such as the IAB node 3 in FIG. 2 .
  • Fig. 12 is a schematic diagram of a method for sending and receiving signals according to an embodiment of the third aspect. As shown in Fig. 12, the method includes:
  • Operation 1201. Receive the first RRC reconfiguration message sent by the first IAB-donor-CU;
  • Operation 1202. Send an RRC reconfiguration complete message to the first IAB-donor-CU.
  • the first RRC reconfiguration message is generated according to the reply that the second IAB-donor-CU sends to the first IAB-donor-CU agreeing to traffic offloading.
  • the first RRC reconfiguration message includes at least one TNL address assigned to the DU of the IAB node, the TNL address being anchored to the second IAB-donor-DU within the topology of the second IAB-donor-CU.
  • the bap configuration information element (bap-Config IE) of the first RRC reconfiguration message includes a field for representing the second BAP address configured for the IAB node; or, the bap configuration information element (bap-Config IE) of the first RRC reconfiguration message
  • the bap address field in IE) includes a list, each entry in the list is a BAP address and its associated information.
  • the RRC reconfiguration complete (for example, RRCReconfigurationComplete) message in operation 1202 is used to indicate that the IAB node has received the first RRC reconfiguration message.
  • the RRC reconfiguration complete message may further indicate that the IAB node has completed reconfiguration.
  • a redundant path across hosts can be established for the IAB node.
  • the method also includes:
  • the IAB node receives a second RRC reconfiguration (RRC Reconfiguration) message sent by the second IAB-donor-CU;
  • the IAB node sends a reconfiguration complete (RRCReconfigurationComplete) message to the second IAB-donor-CU.
  • the second RRC Reconfiguration message includes BAP configuration information (bap-Config), and the BAP configuration information includes a second BAP address configured for the IAB node.
  • a reconfiguration complete (RRCReconfigurationComplete) message is used to indicate that the IAB node has received the second RRC Reconfiguration message.
  • the method also includes:
  • the IAB node associates the second BAP address with the primary cell group (MCG, master cell group)/secondary cell group (SCG, secondary cell group) or the primary node (MN)/secondary node (SN).
  • MCG primary cell group
  • SCG secondary cell group
  • MN primary node
  • SN secondary node
  • the second RRCReconfiguration message with the second BAP address received by the IAB node comes from the MCG, or is received through signaling radio bearer 1 (SRB, signaling radio bearer), then the second BAP address Associated with the MCG or MN; if the second RRCReconfiguration message with the second BAP address received by the IAB node is from the SCG or received through the SRB3, associate the second BAP address with the SCG or SN.
  • SRB signaling radio bearer 1
  • the embodiment of the fourth aspect of the present application provides a method for sending and receiving signals, corresponding to the method of the embodiment of the first aspect.
  • the method for sending and receiving signals in the embodiment of the fourth aspect of the present application is applied to a descendant node of the IAB node, such as the IAB node 4 in FIG. 2 .
  • Fig. 13 is a schematic diagram of a method for sending and receiving signals according to an embodiment of the third aspect. As shown in Fig. 13, the method includes:
  • Operation 1301. Receive the first RRC reconfiguration message sent by the first IAB-donor-CU;
  • Operation 1302. Send an RRC reconfiguration complete message to the first IAB-donor-CU.
  • the first RRC reconfiguration message in operation 1301 is generated according to the reply of agreeing traffic offloading sent by the second IAB-donor-CU to the first IAB-donor-CU.
  • the first RRC reconfiguration message includes at least one TNL address allocated for the DU of the descendant node, and the TNL address is anchored to the second IAB-donor-DU within the topology of the second IAB-donor-CU.
  • the RRC reconfiguration complete (RRCReconfigurationComplete) message in operation 1302 is used to indicate that the descendant node has received the first RRC reconfiguration message.
  • the RRC reconfiguration complete message may further indicate that the descendant node has completed reconfiguration
  • a cross-host redundant path can be established for the descendant nodes of the IAB node.
  • An embodiment of the present application provides a device for sending and receiving signals.
  • This device applies to the first IAB-donor-CU.
  • the device may be the first IAB-donor-CU, and the device may also be a part of the first IAB-donor-CU.
  • the apparatus corresponds to the method of an embodiment of the first aspect.
  • Fig. 14 is a schematic diagram of signals of the sending and receiving device according to the embodiment of the present application.
  • the signal sending and receiving device 1400 includes a first transceiver unit 1401, and the first transceiver unit 1401 is configured as:
  • the first transceiving unit 1401 is further configured to: send the first RRC reconfiguration message to the IAB node and/or the descendant IAB node of the IAB node according to the reply agreeing to traffic offloading.
  • the first RRC reconfiguration message includes at least one TNL address allocated to each DU of the IAB node and/or the descendant node of the IAB node, and the TNL address is anchored in the topology of the second IAB-donor-CU
  • the second IAB-donor-DU the IAB node is connected to the first parent node
  • the first parent node is a node in the topology of the first IAB-donor-CU
  • the IAB node has been or will be connected to the second
  • the parent node is connected
  • the second parent node is a node in the topology of the second IAB-donor-CU.
  • the BAP configuration information element (bap-Config IE) of the first RRC reconfiguration message includes a field for representing the second BAP address configured for the IAB node; or, the first RRC reconfiguration
  • the BAP address field in the BAP configuration information element (bap-Config IE) of the message includes a list, and each entry in the list is a BAP address and its associated information.
  • the first transceiver unit is also configured to:
  • the new TNL address is added to the F1-C association between the DU of the IAB node and/or the descendant node of the IAB node and the first IAB-donor-CU.
  • the traffic offloading request includes a request to establish a redundant path for the IAB node and/or the descendant nodes of the IAB node.
  • the first transceiver unit 1401 is also configured to:
  • the first IAB-donor-CU configures the configuration of the BH RLC channel and the routing table of the BAP sublayer between the IAB node and the descendant node of the IAB node, for supporting the routing of the second path and the BH RLC channel map.
  • the first transceiver unit 1401 is also configured to:
  • the first IAB-donor-CU configures BAP routing identifier mapping for the IAB node according to the reply agreeing to traffic offloading.
  • the first transceiver unit 1401 is also configured to:
  • the first IAB-donor-CU sends the first IAB-donor-CU to the IAB node and / Or the F1-U channel of the DU of the descendant node of the IAB node is migrated from the first path to the second path.
  • the reply of agreeing to traffic offloading indicates at least partially accepting the traffic offloading request, wherein the partially accepting the traffic offloading request refers to: F1-C associated with certain TNLs, or certain F1 -U channel establishes redundant paths.
  • the IAB node is connected to a first parent node, and the IAB node is connected to a second parent node, the first parent node is a node within the topology of the first IAB-donor-CU, the second The second parent node is a node in the topology of the second IAB-donor-CU, the traffic offload request is included in the traffic offload request (TRAFFIC OFFLOAD REQUEST) message, and the reply agreeing to traffic offload is included in the traffic offload request acceptance ( In the TRAFFIC OFFLOAD REQUEST ACKNOWLEDGE) message, the reply to reject the traffic offload is included in the traffic offload rejection (TRAFFIC OFFLOAD REQUEST REJECT) message.
  • TRAFFIC OFFLOAD REQUEST traffic offload request
  • the reply agreeing to traffic offload is included in the traffic offload request acceptance ( In the TRAFFIC OFFLOAD REQUEST ACKNOWLEDGE) message
  • the reply to reject the traffic offload is included in the
  • the traffic offloading request message includes the identification (UE XnAP ID) of the user equipment of the traffic offloading initiating node on the Xn interface, and/or identification information of one or more F1-Cs, and the F1-C's
  • the identification information is used to establish a redundant path for one or more F1-Cs accessing the IAB node, and the accessing IAB node includes the IAB node and/or the descendant node of the IAB node, or an IAB node that is about to become dual-connected.
  • the traffic offload request message includes at least one of the following information:
  • UE XnAP ID of the node that initiates traffic offloading BAP address of the access IAB node, TNL address, identification information of one or more F1-U channels, IP header information (IP header information) of F1-C and/or each F1-U channel ), the QoS information of each F1-U channel.
  • the traffic offload request acceptance (TRAFFIC OFFLOAD REQUEST ACKNOWLEDGE) message includes at least one of the following information:
  • the traffic offloading request rejection (TRAFFIC OFFLOAD REQUEST REJECT) message includes the UE XnAP ID of the traffic offloading initiating node.
  • the IAB node is connected to a first parent node, and the IAB node is connected to a second parent node, the first parent node is a node within the topology of the first IAB-donor-CU, the second the second parent node is a node within the topology of the second IAB-donor-CU,
  • the first IAB-donor-CU is the master node (MN), and the content of the traffic offloading request and the content of the reply agreeing to the traffic offloading or the reply denying the traffic offloading are included in the auxiliary node of the XnAP as an information element (IE).
  • IE information element
  • the IAB node is connected to a first parent node, and the IAB node is not connected to a second parent node, the first parent node is a node within the topology of the first IAB-donor-CU, the the second parent node is a node within the topology of the second IAB-donor-CU,
  • the content of the traffic offloading request and the content of the reply agreeing to traffic offloading or denying traffic offloading are included in the S-NG-RAN node addition preparation (S-NG-RAN node Addition Preparation) process of XnAP as information elements (IE). in the news.
  • S-NG-RAN node Addition Preparation information elements
  • the traffic offloading request is included in a request to add a secondary node (S-NODE ADDITION REQUEST) message sent by the first IAB-donor-CU to the second IAB-donor-CU.
  • S-NODE ADDITION REQUEST secondary node
  • the reply agreeing to traffic offloading is included in the SN addition request acceptance (S-NODE ADDITION REQUEST ACKNOWLEDGE) message sent by the second IAB-donor-CU to the first IAB-donor-CU.
  • S-NODE ADDITION REQUEST ACKNOWLEDGE SN addition request acceptance
  • the reply of rejecting traffic offloading is included in the SN addition request acceptance (S-NODE ADDITION REQUEST ACKNOWLEDGE) message sent by the second IAB-donor-CU to the first IAB-donor-CU.
  • S-NODE ADDITION REQUEST ACKNOWLEDGE SN addition request acceptance
  • the first transceiver unit 1401 is also configured to:
  • the first IAB-donor-CU sends or receives a redundant path release request
  • the first IAB-donor-CU receives or sends a redundant path release request acceptance message.
  • the redundant path release request includes: the UE XnAP ID of the node initiating traffic offloading, the UE XnAP ID of the node accepting traffic offloading, the TNL address associated with the F1-C that needs to be released, or needs to be released User plane transport layer information (UP Transport Layer Information) of the F1-U channel of the redundant path.
  • UP Transport Layer Information User plane transport layer information
  • the acceptance of the redundant path release request includes: the UE XnAP ID of the node initiating traffic offloading, and the UE XnAP ID of the node receiving traffic offloading.
  • Both the content of the redundant path release request and the content of the message accepted by the redundant path release request are used as IEs and included in the S-NG-RAN node modification preparation (S-NG-RAN node Modification Preparation) process.
  • first transceiver unit 1401 For a detailed description of the first transceiver unit 1401, reference may be made to the description of the method in the embodiment of the first aspect.
  • An embodiment of the present application provides a device for sending and receiving signals.
  • the apparatus is applied to the second IAB-donor-CU, for example, the apparatus may be the second IAB-donor-CU, or may be one or some components or components configured on the second IAB-donor-CU.
  • the apparatus corresponds to the method of an embodiment of the second aspect.
  • Fig. 15 is a schematic diagram of a device for sending and receiving signals in an embodiment of the sixth aspect.
  • the device 1500 includes a second transceiver unit 1501, and the second processing unit 1501 is configured to:
  • the traffic offloading request includes a request to establish a redundant path for the IAB node and/or the descendant nodes of the IAB node.
  • the second transceiver unit 1501 is also configured to:
  • the second IAB-donor-CU When the IAB node has been connected with the second parent node, the second IAB-donor-CU sends a user equipment context modification request (UE CONTEXT MODIFICATION REQUEST) message to the second parent node to modify the mobile terminal (MT) of the IAB node ), and set at least one bearer (bearer), wherein the second parent node is a node in the topology of the second IAB-donor-CU.
  • UE CONTEXT MODIFICATION REQUEST user equipment context modification request
  • MT mobile terminal
  • bearer bearer
  • the second transceiver unit 1501 is also configured to:
  • the second IAB-donor-CU When the IAB node is not connected to the second parent node, the second IAB-donor-CU sends a UE CONTEXT SETUP REQUEST message to the second parent node to establish the UE context of the MT of the IAB, And set at least one bearer (bearer),
  • the second parent node is a node in the topology of the second IAB-donor-CU.
  • the second transceiver unit 1501 is also configured to:
  • the second IAB-donor-CU sends a second reconfiguration (RRCReconfiguration) message to the mobile terminal (MT) of the IAB node
  • the second RRCReconfiguration message includes BAP configuration information (bap-Config)
  • the BAP configuration information includes information for the The address of the second BAP configured by the IAB node.
  • the second transceiver unit 1501 is also configured to:
  • the second IAB-donor-CU For the second path required by the IAB node and/or the descendant node of the IAB node, the second IAB-donor-CU performs BH RLC channel configuration and BAP from the IAB node to the second IAB-donor-DU The configuration of the routing table of the sublayer,
  • the second IAB-donor-DU is within the topology of the second IAB-donor-CU.
  • the reply of agreeing to traffic offloading indicates at least partially accepting the traffic offloading request, wherein the partially accepting the traffic offloading request refers to: F1-C associated with certain TNLs, or certain F1 -U channel establishes redundant paths.
  • the IAB node is connected to a first parent node, and the IAB node is connected to a second parent node, the first parent node is a node within the topology of the first IAB-donor-CU, the second the second parent node is a node within the topology of the second IAB-donor-CU,
  • the traffic offload request is included in the traffic offload request message
  • the traffic offload reply is included in the traffic offload request acceptance (TRAFFIC OFFLOAD REQUEST ACKNOWLEDGE) message
  • the traffic offload reply is rejected in the traffic offload reject (TRAFFIC OFFLOAD REQUEST ACKNOWLEDGE) message.
  • REQUEST REJECT REQUEST REJECT
  • the traffic offloading request message includes the identification (UE XnAP ID) of the user equipment on the Xn interface of the traffic offloading initiating node, and/or identification information of one or more F1-Cs.
  • the identification information of the F1-C is used to establish a redundant path for one or more F1-Cs accessing the IAB node, the accessing IAB node includes the IAB node and/or the descendant node of the IAB node, or is about to become a dual The connected IAB node.
  • the traffic offload request message includes at least one of the following information:
  • UE XnAP ID of the node that initiates traffic offloading BAP address of the access IAB node, TNL address, identification information of one or more F1-U channels, IP header information (IP header information) of F1-C and/or each F1-U channel ), the QoS information of each F1-U channel.
  • the traffic offload request acceptance (TRAFFIC OFFLOAD REQUEST ACKNOWLEDGE) message includes at least one of the following information:
  • the UE XnAP ID of the traffic offloading initiating node the UE XnAP ID of the traffic offloading receiving node, the identification information of the F1-C and/or F1-U channel, the TNL address newly allocated for the DU connected to the IAB node, and the F1-C and/or F1-U channel configuration on the link between the dual-connected IAB node and the second parent node BH RLC channel identification, the BAP address of the second parent node, the topology controlled by the second IAB-donor-CU
  • the BAP routing identifier in the second BAP address of the IAB node.
  • the traffic offloading request rejection (TRAFFIC OFFLOAD REQUEST REJECT) message includes the traffic offloading initiation node UE XnAP ID, which can be Optionally include traffic offload deny node UE XnAP ID.
  • the IAB node is connected to a first parent node, and the IAB node is connected to a second parent node, the first parent node is a node within the topology of the first IAB-donor-CU, the second the second parent node is a node within the topology of the second IAB-donor-CU,
  • the first IAB-donor-CU is the master node (MN), and the content of the traffic offloading request and the content of the reply agreeing to the traffic offloading or the reply denying the traffic offloading are included in the auxiliary node of the XnAP as an information element (IE).
  • IE information element
  • the IAB node is connected to a first parent node, and the IAB node is not connected to a second parent node, the first parent node is a node within the topology of the first IAB-donor-CU, the the second parent node is a node within the topology of the second IAB-donor-CU,
  • the content of the traffic offloading request and the content of the reply agreeing to traffic offloading or the reply denying traffic offloading are included in the S-NG-RAN node addition preparation (S-NG-RAN node Addition Preparation) process of XnAP as an information element (IE). in the news.
  • S-NG-RAN node Addition Preparation S-NG-RAN node Addition Preparation
  • the traffic offloading request is included in a request to add a secondary node (S-NODE ADDITION REQUEST) message sent by the first IAB-donor-CU to the second IAB-donor-CU.
  • S-NODE ADDITION REQUEST secondary node
  • the reply agreeing to traffic offloading is included in the SN addition request acceptance (S-NODE ADDITION REQUEST ACKNOWLEDGE) message sent by the second IAB-donor-CU to the first IAB-donor-CU.
  • S-NODE ADDITION REQUEST ACKNOWLEDGE SN addition request acceptance
  • the second transceiver unit 1501 is also configured to:
  • the second IAB-donor-CU receives or sends a redundant path release request
  • the second IAB-donor-CU sends or receives a redundant path release request acceptance message.
  • the redundant path release request includes: the UE XnAP ID of the node initiating traffic offloading, the UE XnAP ID of the node accepting traffic offloading, the TNL address associated with the F1-C that needs to be released, or needs to be released User plane transport layer information (UP Transport Layer Information) of the F1-U channel of the redundant path.
  • UP Transport Layer Information User plane transport layer information
  • Both the content of the redundant path release request and the content of the message accepted by the redundant path release request are used as IEs and included in the S-NG-RAN node modification preparation (S-NG-RAN node Modification Preparation) process.
  • the second transceiver unit 1501 For a detailed description of the second transceiver unit 1501, reference may be made to the description of the method in the embodiment of the second aspect.
  • An embodiment of the present application provides a device for sending and receiving signals.
  • the device is applied to an IAB node, for example, the device may be an IAB node, or may be one or some components or components configured on the IAB node.
  • the apparatus corresponds to the method of an embodiment of the third aspect.
  • Fig. 16 is a schematic diagram of a device for sending and receiving signals in an embodiment of the seventh aspect.
  • the device 1600 includes a third transceiver unit 1601, and the third transceiver unit 1601 is configured to:
  • the first RRC reconfiguration message is generated according to the reply that the second IAB-donor-CU sends to the first IAB-donor-CU agreeing to traffic offloading, and the first RRC reconfiguration message includes: At least one TNL address allocated by the DU of the IAB node, the TNL address is anchored to the second IAB-donor-DU in the topology of the second IAB-donor-CU, wherein the RRC reconfiguration complete (RRCReconfigurationComplete) message is used Yu indicates that the IAB node has received the first RRC reconfiguration message.
  • the RRC reconfiguration complete message may further indicate that the IAB node has completed reconfiguration.
  • the third transceiver unit 1601 is further configured to:
  • the IAB node receives the second RRC reconfiguration (RRC Reconfiguration) message sent by the second IAB-donor-CU, the second RRC Reconfiguration message includes BAP configuration information (bap-Config), and the BAP configuration information includes information for the IAB node a configured second BAP address; and
  • the IAB node sends a reconfiguration complete (RRCReconfigurationComplete) message to the second IAB-donor-CU,
  • the reconfiguration complete (RRCReconfigurationComplete) message is used to indicate that the IAB node has received the second RRC Reconfiguration message.
  • the third transceiver unit 1601 is further configured to:
  • the IAB node associates the second BAP address with a primary cell group (MCG, master cell group)/secondary cell group (SCG, secondary cell group) or a master node (MN)/secondary node (SN).
  • MCG primary cell group
  • SCG secondary cell group
  • MN master node
  • SN secondary node
  • the second RRCReconfiguration message with the second BAP address received by the IAB node comes from the MCG, or is received through signaling radio bearer 1 (SRB, signaling radio bearer), then Associating the second BAP address with the MCG or MN;
  • the second RRCReconfiguration message with the second BAP address received by the IAB node is from the SCG or received through SRB3, associate the second BAP address with the SCG or SN.
  • the bap configuration information element (bap-Config IE) of the first RRC reconfiguration message includes a field for representing the second BAP address configured for the IAB node;
  • the bap address field in the bap configuration information element (bap-Config IE) of the first RRC reconfiguration message includes a list, and each entry in the list is a BAP address and its associated information.
  • the third transceiver unit 1601 For a detailed description of the third transceiver unit 1601, reference may be made to the description of the method in the embodiment of the third aspect.
  • An embodiment of the present application provides a device for sending and receiving signals.
  • the device is applied to a descendant node of the IAB node, for example, the device may be the descendant node, or one or some components or components configured on the child descendant node.
  • the apparatus corresponds to the method of an embodiment of the fourth aspect.
  • Fig. 17 is a schematic diagram of a device for sending and receiving signals in an embodiment of the eighth aspect. As shown in Fig. 17, the device includes a fourth transceiver unit 1701, and the fourth transceiver unit 1701 is configured to:
  • the first RRC reconfiguration message is generated according to the reply that the second IAB-donor-CU sends to the first IAB-donor-CU agreeing to traffic offloading, and the first RRC reconfiguration message includes the DU of the descendant node Assigned at least one TNL address, the TNL address is anchored to the second IAB-donor-DU in the topology of the second IAB-donor-CU, wherein the RRC reconfiguration complete (RRCReconfigurationComplete) message is used to indicate the descendant node The first RRC reconfiguration message has been received.
  • the RRC reconfiguration complete message may further indicate that the descendant node has completed reconfiguration.
  • the embodiment of the present application also provides a communication system, which can be referred to FIG. 1 , and the same content as the embodiments of the first aspect to the eighth aspect will not be repeated.
  • the communication system may include:
  • the first IAB-donor-CU which includes the apparatus 1400 for sending and receiving signals according to the embodiment of the fifth aspect;
  • the second IAB-donor-CU which includes the apparatus 1500 for sending and receiving signals according to the embodiment of the sixth aspect;
  • An IAB node which includes the apparatus 1600 for sending and receiving signals according to the embodiment of the seventh aspect.
  • a descendant node of the IAB node which includes the apparatus 1700 for sending and receiving signals according to the embodiment of the eighth aspect.
  • the integrated access and backhaul node may include an IAB-MT functional unit and an IAB-DU functional unit.
  • the IAB-MT functional unit may have the same structure as that of the terminal equipment.
  • the IAB-DU functional unit, the first IAB-donor-CU, and the second IAB-donor-CU may have the same units as those of the network device.
  • FIG. 18 is a schematic diagram of a network device according to an embodiment of the present application.
  • a network device 1800 may include: a processor 1810 (such as a central processing unit CPU) and a memory 1820 ; the memory 1820 is coupled to the processor 1810 .
  • the memory 1820 can store various data; in addition, it also stores a program 1830 for information processing, and executes the program 1830 under the control of the processor 1810 .
  • the processor 1810 may be configured to execute a program to implement the method performed by the IAB-donor CU in the embodiment of the first aspect or the embodiment of the second aspect, or the embodiment of the third aspect or the implementation of the fourth aspect The method performed by the IAB-DU in the example.
  • the network device 1800 may further include: a transceiver 1840 and an antenna 1850 , etc.; where the functions of the above components are similar to those of the prior art, and will not be repeated here. It should be noted that the network device 1800 does not necessarily include all the components shown in FIG. 18 ; in addition, the network device 1800 may also include components not shown in FIG. 18 , and reference may be made to the prior art.
  • the IAB-donor-CU and the IAB-donor-DU can exist in one node and become a network device IAB-donor, or can be separated into two nodes to implement different functions of the network device respectively, and reference can be made to the prior art.
  • FIG. 19 is a schematic diagram of a terminal device according to an embodiment of the present application.
  • the terminal device 1900 may include a processor 1910 and a memory 1920 ; the memory 1920 stores data and programs, and is coupled to the processor 1910 .
  • the processor 1910 may be configured to execute a program to implement the method performed by the IAB-MT in the embodiment of the third aspect or the embodiment of the fourth aspect. .
  • the terminal device 1900 may further include: a communication module 1930 , an input unit 1940 , a display 1950 , and a power supply 1960 .
  • a communication module 1930 the functions of the above components are similar to those of the prior art, and will not be repeated here. It should be noted that the terminal device 1900 does not necessarily include all the components shown in FIG. have technology.
  • the embodiment of the present application also provides a computer program, wherein when the program is executed in the Donor-CU, the program causes the Donor CU to execute the method described in the embodiment of the first aspect or the second aspect.
  • the embodiment of the present application also provides a storage medium storing a computer program, wherein the computer program enables the Donor-CU to execute the method described in the embodiment of the first aspect or the second aspect.
  • the embodiment of the present application also provides a computer program, wherein when the program is executed in the IAB or its descendant nodes, the program causes the IAB or its descendant nodes to execute the third aspect or the embodiment of the fourth aspect. Signal sending and receiving methods.
  • the embodiment of the present application also provides a storage medium storing a computer program, wherein the computer program enables the IAB or its descendant nodes to execute the signal sending and receiving method described in the embodiment of the third aspect or the fourth aspect.
  • the above devices and methods in this application can be implemented by hardware, or by combining hardware and software.
  • the present application relates to a computer-readable program that, when executed by a logic component, enables the logic component to realize the above-mentioned device or constituent component, or enables the logic component to realize the above-mentioned various methods or steps.
  • the present application also relates to storage media for storing the above programs, such as hard disks, magnetic disks, optical disks, DVDs, flash memories, and the like.
  • the method/device described in conjunction with the embodiments of the present application may be directly embodied as hardware, a software module executed by a processor, or a combination of both.
  • one or more of the functional block diagrams shown in the figure and/or one or more combinations of the functional block diagrams may correspond to each software module or each hardware module of the computer program flow.
  • These software modules may respectively correspond to the steps shown in the figure.
  • These hardware modules for example, can be realized by solidifying these software modules by using a Field Programmable Gate Array (FPGA).
  • FPGA Field Programmable Gate Array
  • a software module may reside in RAM memory, flash memory, ROM memory, EPROM memory, EEPROM memory, registers, hard disk, removable disk, CD-ROM or any other form of storage medium known in the art.
  • a storage medium can be coupled to the processor such that the processor can read information from, and write information to, the storage medium, or it can be an integral part of the processor.
  • the processor and storage medium can be located in the ASIC.
  • the software module can be stored in the memory of the mobile terminal, or can be stored in a memory card that can be inserted into the mobile terminal.
  • the software module can be stored in the MEGA-SIM card or large-capacity flash memory device.
  • One or more of the functional blocks described in the accompanying drawings and/or one or more combinations of the functional blocks can be implemented as a general-purpose processor, a digital signal processor (DSP) for performing the functions described in this application ), application specific integrated circuits (ASICs), field programmable gate arrays (FPGAs) or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, or any suitable combination thereof.
  • DSP digital signal processor
  • ASICs application specific integrated circuits
  • FPGAs field programmable gate arrays
  • One or more of the functional blocks described in the drawings and/or one or more combinations of the functional blocks can also be implemented as a combination of computing devices, for example, a combination of a DSP and a microprocessor, a plurality of microprocessors processor, one or more microprocessors in communication with a DSP, or any other such configuration.
  • the first RRC reconfiguration message includes at least one TNL address allocated to each of the DUs of the IAB node and/or the descendant node of the IAB node, and the TNL address is anchored in the second IAB-donor - the second IAB-donor-DU within the topology of the CU,
  • the IAB node is connected to a first parent node, the first parent node is a node in the topology of the first IAB-donor-CU, and the IAB node has been or will be connected to a second parent node, the The second parent node is a node within the topology of the second IAB-donor-CU.
  • the BAP configuration information element (bap-Config IE) of the first RRC reconfiguration message includes a field representing a second BAP address configured for the IAB node;
  • the BAP address field in the BAP configuration information element (bap-Config IE) of the first RRC reconfiguration message includes a list, and each entry in the list is a BAP address and its associated information.
  • the traffic offloading request includes a request for establishing a redundant path for the IAB node and/or the descendant node of the IAB node.
  • the first IAB-donor-CU configures the configuration of the BH RLC channel and the configuration of the routing table of the BAP sublayer between the descendant nodes from the IAB node to the IAB node, so as to support the routing and routing of the second path BH RLC channel mapping.
  • the first IAB-donor-CU configures BAP routing identifier mapping for the IAB node according to the reply agreeing to traffic offloading.
  • the first IAB-donor-CU transfers the first IAB-donor-CU to the IAB through a UE CONTEXT MODIFICATION REQUEST message or a UE CONTEXT SETUP REQUEST message.
  • the F1-U channel of the DU of the node and/or the descendant node of the IAB node is migrated from the first path to the second path.
  • the reply agreeing to traffic offloading indicates at least partially accepting the traffic offloading request
  • the partially accepting the traffic offloading request refers to establishing redundant paths for some F1-Cs associated with some TNLs, or some F1-U channels.
  • the IAB node is connected to a first parent node, and the IAB node is connected to a second parent node, the first parent node is a node in the topology of the first IAB-donor-CU, and the second parent node is a node within the topology of the second IAB-donor-CU,
  • the traffic offloading request is included in the traffic offloading request (TRAFFIC OFFLOAD REQUEST) message
  • the reply of agreeing to the traffic offloading is included in the traffic offloading request acceptance (TRAFFIC OFFLOAD REQUEST ACKNOWLEDGE) message
  • the reply of rejecting the traffic offloading is included in the Included in the TRAFFIC OFFLOAD REQUEST REJECT message.
  • the traffic offload request message includes at least one of the following information:
  • UE XnAP ID The identification (UE XnAP ID) of the user equipment at the Xn interface of the traffic offloading initiating node, the BAP address of the access IAB node, the TNL address, one or more F1-C identification information, one or more F1-U channel identification information, IP header information (IP header information) of F1-C and/or each F1-U channel, QoS information of each F1-U channel.
  • the traffic offload request acceptance (TRAFFIC OFFLOAD REQUEST ACKNOWLEDGE) message includes at least one of the following information:
  • the TRAFFIC OFFLOAD REQUEST REJECT message includes the UE XnAP ID of the traffic offloading initiating node.
  • the IAB node is connected to a first parent node, and the IAB node is connected to a second parent node, the first parent node is a node in the topology of the first IAB-donor-CU, and the second parent node is a node within the topology of the second IAB-donor-CU,
  • the first IAB-donor-CU is a master node (MN), the content of the traffic offloading request and the content of the reply agreeing to traffic offloading or the reply denying traffic offloading are used as information elements (IE), and are included in In the message of the XnAP secondary base station node modification preparation (S-NG-RAN node Modification Preparation) process.
  • MN master node
  • IE information elements
  • the IAB node is connected to a first parent node, and the IAB node is not connected to a second parent node, the first parent node is a node in the topology of the first IAB-donor-CU, and the second parent node a node is a node within the topology of said second IAB-donor-CU,
  • the content of the traffic offloading request and the content of the reply agreeing to traffic offloading or the reply denying traffic offloading are used as information elements (IE), and are included in the secondary base station node addition preparation (S-NG-RAN node Addition Preparation) of XnAP ) process messages.
  • IE information elements
  • S-NG-RAN node Addition Preparation secondary base station node Addition Preparation
  • the traffic offloading request is included in a request to add a secondary node (S-NODE ADDITION REQUEST) message sent by the first IAB-donor-CU to the second IAB-donor-CU.
  • S-NODE ADDITION REQUEST secondary node
  • the reply agreeing to traffic offloading is included in the SN addition request acceptance (S-NODE ADDITION REQUEST ACKNOWLEDGE) message sent by the second IAB-donor-CU to the first IAB-donor-CU.
  • the first IAB-donor-CU sends or receives a redundant path release request
  • the first IAB-donor-CU receives or sends a redundant path release request acceptance message.
  • the redundant path release request includes: the UE XnAP ID of the node initiating traffic offloading, the UE XnAP ID of the node accepting traffic offloading, the TNL address associated with the F1-C that needs to release the redundant path, or the F1-C that needs to release the redundant path.
  • User plane transport layer information (UP Transport Layer Information) of the U channel.
  • Both the content of the redundant path release request and the content of the redundant path release request acceptance message are included as IEs in the SeNB node modification preparation (S-NG-RAN node Modification Preparation) process.
  • the second IAB-donor-CU side method is the second IAB-donor-CU side method
  • the traffic offloading request includes a request for establishing a redundant path for the IAB node and/or the descendant node of the IAB node.
  • the second IAB-donor-CU sends a UE CONTEXT MODIFICATION REQUEST message to the second parent node to modify the movement of the IAB node
  • UE user equipment
  • MT terminal
  • bearer bearer
  • the second parent node is a node in the topology of the second IAB-donor-CU.
  • the second IAB-donor-CU sends a UE CONTEXT SETUP REQUEST message to the second parent node to establish the MT of the IAB UE context, and set at least one bearer (bearer),
  • the second parent node is a node in the topology of the second IAB-donor-CU.
  • the second IAB-donor-CU sends a second reconfiguration (RRCReconfiguration) message to the mobile terminal (MT) of the IAB node
  • the second RRCReconfiguration message includes BAP configuration information (bap-Config), and the BAP configuration
  • the information includes an address of a second BAP configured for the IAB node.
  • the second IAB-donor-CU performs a BH RLC channel from the IAB node to the second IAB-donor-DU for the second path required by the IAB node and/or the descendant node of the IAB node configuration and routing table configuration of the BAP sublayer,
  • the second IAB-donor-DU is within the topology of the second IAB-donor-CU.
  • the reply agreeing to traffic offloading indicates at least partially accepting the traffic offloading request
  • the partially accepting the traffic offloading request refers to establishing redundant paths for some F1-Cs associated with some TNLs, or some F1-U channels.
  • the IAB node is connected to a first parent node, and the IAB node is connected to a second parent node, the first parent node is a node in the topology of the first IAB-donor-CU, and the second parent node is a node within the topology of the second IAB-donor-CU,
  • the traffic offloading request is included in the traffic offloading request message
  • the reply of agreeing to the traffic offloading is included in the traffic offloading request acceptance (TRAFFIC OFFLOAD REQUEST ACKNOWLEDGE) message
  • the reply of rejecting the traffic offloading is included in the traffic offloading rejection (TRAFFIC OFFLOAD REQUEST REJECT) message.
  • the traffic offload request message includes at least one of the following information:
  • UE XnAP ID The identification (UE XnAP ID) of the user equipment at the Xn interface of the traffic offloading initiating node, the BAP address of the access IAB node, the TNL address, one or more F1-C identification information, one or more F1-U channel identification information, IP header information (IP header information) of F1-C and/or each F1-U channel, QoS information of each F1-U channel.
  • the traffic offload request acceptance (TRAFFIC OFFLOAD REQUEST ACKNOWLEDGE) message includes at least one of the following information:
  • the UE XnAP ID of the traffic offloading initiating node the UE XnAP ID of the traffic offloading receiving node, the identification information of the F1-C and/or F1-U channel, the TNL address newly allocated for the DU connected to the IAB node, and the F1-C And/or the BH RLC channel identification on the link between the dual-connection IAB node and the second parent node configured by the F1-U channel, the BAP address of the second parent node, the second IAB-donor-CU controlled The BAP routing identifier in the topology, the second BAP address of the IAB node.
  • the traffic offload request rejection (TRAFFIC OFFLOAD REQUEST REJECT) message includes the traffic offload initiation node UE XnAP ID.
  • the IAB node is connected to a first parent node, and the IAB node is connected to a second parent node, the first parent node is a node in the topology of the first IAB-donor-CU, and the second parent node is a node within the topology of the second IAB-donor-CU,
  • the first IAB-donor-CU is a master node (MN), the content of the traffic offloading request and the content of the reply agreeing to traffic offloading or the reply denying traffic offloading are used as information elements (IE), and are included in In the message of the XnAP secondary base station node modification preparation (S-NG-RAN node Modification Preparation) process.
  • MN master node
  • IE information elements
  • the IAB node is connected to a first parent node, and the IAB node is not connected to a second parent node, the first parent node is a node in the topology of the first IAB-donor-CU, and the second parent node a node is a node within the topology of said second IAB-donor-CU,
  • the content of the traffic offloading request and the content of the reply agreeing to traffic offloading or the reply denying traffic offloading are used as information elements (IE), and are included in the secondary base station node addition preparation (S-NG-RAN node Addition Preparation) of XnAP ) process messages.
  • IE information elements
  • S-NG-RAN node Addition Preparation secondary base station node Addition Preparation
  • the traffic offloading request is included in a request to add a secondary node (S-NODE ADDITION REQUEST) message sent by the first IAB-donor-CU to the second IAB-donor-CU.
  • S-NODE ADDITION REQUEST secondary node
  • the reply agreeing to traffic offloading is included in the SN addition request acceptance (S-NODE ADDITION REQUEST ACKNOWLEDGE) message sent by the second IAB-donor-CU to the first IAB-donor-CU.
  • the second IAB-donor-CU receives or sends a redundant path release request
  • the second IAB-donor-CU sends or receives a redundant path release request acceptance message.
  • the redundant path release request includes: the UE XnAP ID of the node initiating traffic offloading, the UE XnAP ID of the node accepting traffic offloading, the TNL address associated with the F1-C that needs to release the redundant path, or the F1-C that needs to release the redundant path.
  • User plane transport layer information (UP Transport Layer Information) of the U channel.
  • Both the content of the redundant path release request and the content of the redundant path release request acceptance message are included as IEs in the SeNB node modification preparation (S-NG-RAN node Modification Preparation) process.
  • the methods include:
  • the first RRC reconfiguration message is generated according to the reply that the second IAB-donor-CU sends to the first IAB-donor-CU agreeing to traffic offloading
  • the first RRC reconfiguration message includes at least one TNL address assigned to a DU of the IAB node, the TNL address being anchored to a second IAB-donor-DU within the topology of the second IAB-donor-CU ,
  • the RRC reconfiguration complete (RRCReconfigurationComplete) message is used to indicate that the IAB node has received the first RRC reconfiguration message.
  • the IAB node receives a second RRC reconfiguration (RRC Reconfiguration) message sent by the second IAB-donor-CU, the second RRC Reconfiguration message includes BAP configuration information (bap-Config), and the BAP configuration information includes a second BAP address configured for the IAB node; and
  • the IAB node sends a reconfiguration complete (RRCReconfigurationComplete) message to the second IAB-donor-CU,
  • the reconfiguration complete (RRCReconfigurationComplete) message is used to indicate that the IAB node has received the second RRC Reconfiguration message.
  • the IAB node associates the second BAP address with a master cell group (MCG, master cell group)/secondary cell group (SCG, secondary cell group) or a master node (MN)/secondary node (SN).
  • MCG master cell group
  • SCG secondary cell group
  • MN master node
  • SN secondary node
  • the second RRCReconfiguration message with the second BAP address received by the IAB node comes from the MCG, or is received through a signaling radio bearer 1 (SRB, signaling radio bearer), then the first 2.
  • BAP address is associated with MCG or MN;
  • the second RRCReconfiguration message with the second BAP address received by the IAB node is from the SCG or received through SRB3, associate the second BAP address with the SCG or SN.
  • the bap configuration information element (bap-Config IE) of the first RRC reconfiguration message includes a field representing a second BAP address configured for the IAB node;
  • the bap address field in the bap configuration information element (bap-Config IE) of the first RRC reconfiguration message includes a list, and each entry in the list is a BAP address and its associated information.
  • the methods include:
  • the first RRC reconfiguration message is generated according to the reply that the second IAB-donor-CU sends to the first IAB-donor-CU agreeing to traffic offloading
  • the first RRC reconfiguration message includes at least one TNL address assigned to the DU of the descendant node, and the TNL address is anchored to a second IAB-donor-DU within the topology of the second IAB-donor-CU ,
  • the RRC reconfiguration complete (RRCReconfigurationComplete) message is used to indicate that the descendant node has received the first RRC reconfiguration message.

Landscapes

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

Abstract

本申请实施例提供一种发送和接收信号的方法、装置和通信***，该发送和接收信号的装置应用于第一集成的接入和回传节点宿主中心单元(IAB-donor-CU)，该装置包括第一收发单元，其被配置为：向第二IAB-donor-CU发送流量卸载请求；以及接收所述第二IAB-donor-CU发送的同意流量卸载的回复或拒绝流量卸载的回复。

Description

发送和接收信号的方法、装置和通信*** 技术领域
本申请实施例涉及通信技术领域。
背景技术
集成的接入和回传(Integrated access and backhaul，IAB)又称接入回传一体化，在下一代无线接入网络(NG-RAN：next generation radio access network)中实现了无线中继的功能。集成的接入和回传节点(IAB-node)支持通过新无线(New Radio，NR)的接入和回传。NR回传在网络侧中终止点被称为IAB-donor，它表示一个具有支持IAB功能的网络设备(例如，gNB)。
IAB-node可以通过一跳或者多跳来连接到一个IAB宿主(IAB-donor)。这些多跳连接形成了一个以IAB宿主为根节点的有向无环图(DAG，Directed Acyclic Graph)拓扑结构。IAB宿主负责执行IAB网络拓扑中集中式的资源管理、拓扑管理和路由管理。
IAB-node支持gNB-DU(distributed unit，分布式单元)的功能，IAB-node DU也被称为IAB-DU，IAB-DU是到终端设备(UE)和下一跳IAB-node的无线接入(NR access)接口的终点，也是到IAB-donor上的gNB-CU(central unit，中心单元)的F1协议的终点。IAB-DU可以服务普通的UE和IAB子节点。IAB-DU实现网络侧设备功能，连接到下游的child IAB-node，对UE以及下游child IAB-node提供NR空口接入并与IAB donor-CU之间建立有F1连接。
除了gNB-DU功能，IAB-node也支持一部分UE的功能，被称为IAB-MT(Mobile Termination)，IAB-MT包括比如物理层、层2、RRC和NAS功能来连接到另一个IAB-node或IAB-donor的gNB-DU、连接到IAB-donor上的gNB-CU和连接到核心网。IAB-MT可支持如UE物理层、接入(access stratum，AS)、无线资源控制(radio resource control，RRC)层和非接入(non-access stratum，NAS)层功能，可以连接到IAB父节点。
IAB-donor是网络侧的终结节点，IAB-donor通过回传或接入链路为IAB-MT或UE提供网络接入。IAB-donor又进一步分为IAB-donor-CU(central unit)和 IAB-donor-DU。IAB-DU和IAB-donor-CU之间通过F1接口连接。在独立组网场景下，gNB与IAB-donor-CU之间通过Xn接口连接。
为了支持数据包的多跳路由转发，IAB引入了回传适配协议(Backhaul Adaptation Protocol，BAP)子层。BAP子层位于无线链路控制(RLC)子层之上、IP层之下，支持数据包目的节点及路径选择、数据包路由转发、承载映射、流控反馈、回传链路失败通知等功能。
图1是IAB拓扑结构的一个示意图。如图1所示，在IAB拓扑结构10中，IAB-node100包括IAB-MT功能单元101和IAB-DU功能单元102，IAB-DU功能单元102的接口上的邻节点被称为子节点(child node)，如图1中所示的子节点201、202、203，IAB-DU功能单元102与子节点201、202、203之间可以通过空中接口(Uu)进行通信；IAB-MT功能单元101的接口上的邻节点被称为父节点(parent node)，如图1中所示的父节点301、302，IAB-MT功能单元101与父节点301、302之间可以通过空中接口(Uu)进行通信。
如图1所示，IAB-node 100到子节点201、202、203的方向被称为下游(downstream)方向，IAB-node 100到父节点301、302的方向被称为上游(upstream)方向。IAB-donor(未图示)为该IAB拓扑结构10执行集中式的资源、拓扑和路由管理。
应该注意，上面对技术背景的介绍只是为了方便对本申请的技术方案进行清楚、完整的说明，并方便本领域技术人员的理解而阐述的。不能仅仅因为这些方案在本申请的背景技术部分进行了阐述而认为上述技术方案为本领域技术人员所公知。
发明内容
拓扑冗余(topology redundancy)是指在IAB拓扑网络中为IAB节点建立冗余路径，也就是第二路径，从而将一个拓扑网络中的部分业务卸载(offload)到另外一个拓扑网络中，即，通过冗余的路径进行数据传输。拓扑冗余的主要目的是可以进行业务的负载均衡，减少业务中断，提高网络的鲁棒性。
现有的宿主内(intra-CU)拓扑冗余过程可以在同一个IAB-donor-CU下的IAB拓扑中进行冗余路径的建立和释放，该过程能够达到一定程度的路径的多样性和负载均衡。如果同一个IAB-donor-CU下的拓扑网络已经达到了负载的饱和，就会影响业务的性能。宿主间(inter-CU)拓扑冗余能够进一步的提高路径的多样性，更好地满 足负载均衡的需求。
然而，本申请的发明人发现，如何建立或释放宿主间的拓扑冗余路径，目前还没有相应的解决方案。
本申请的实施例提供一种发送和接收信号的方法、装置和通信***，第一IAB-donor-CU向第二IAB-donor-CU发送流量卸载请求，第二IAB-donor-CU向第一IAB-donor-CU发送同意流量卸载的回复或拒绝流量卸载的回复，由此，能够在第一IAB-donor-CU的网络拓扑和第二IAB-donor-CU的网络拓扑之间建立冗余路径，从而能够进一步的提高路径的多样性，更好地满足负载均衡以及减少业务中断的需求。
根据本申请实施例的一个方面，提供一种发送和接收信号的装置，应用于第一集成的接入和回传节点宿主中心单元(IAB-donor-CU)，该装置包括第一收发单元，其被配置为：
向第二IAB-donor-CU发送流量卸载请求，也就是冗余路径建立请求；以及
接收所述第二IAB-donor-CU发送的同意流量卸载的回复或拒绝流量卸载的回复。
根据本申请实施例的另一个方面，提供一种发送和接收信号的装置，应用于第二集成的接入和回传节点宿主中心单元(IAB-donor-CU)，该装置包括第二收发单元，所述第二收发单元被配置为：
接收第一IAB-donor-CU发送的是流量卸载请求；以及
向所述第一IAB-donor-CU发送同意流量卸载的回复或者拒绝流量卸载的回复。
根据本申请实施例的另一个方面，提供一种发送和接收信号的装置，应用于IAB节点，所述IAB节点与第一父节点连接，并且，所述IAB节点已经或即将与第二父节点连接，所述第一父节点是第一IAB-donor-CU的拓扑内的节点，所述第二父节点是第二IAB-donor-CU的拓扑内的节点，
所述装置包括，第三收发单元，所述第三收发单元被配置为：
接收所述第一IAB-donor-CU发送的第一RRC重配置消息；以及
向所述第一IAB-donor-CU发送RRC重配置完成消息，
其中，所述第一RRC重配置消息根据第二IAB-donor-CU发送给所述第一IAB-donor-CU的同意流量卸载的回复而生成，
所述第一RRC重配置消息包括为所述IAB节点的DU分配的至少一个TNL地址，所述TNL地址锚定在所述第二IAB-donor-CU的拓扑内的第二IAB-donor-DU，
其中，所述RRC重配置完成(RRCReconfigurationComplete)消息用于表示所述IAB节点已经收到所述第一RRC重配置消息并完成了重配置。
根据本申请实施例的另一个方面，提供一种发送和接收信号的装置，应用于IAB节点的后裔节点，所述IAB节点与第一父节点连接，并且，所述IAB节点已经或即将与第二父节点连接，所述第一父节点是第一IAB-donor-CU的拓扑内的节点，所述第二父节点是第二IAB-donor-CU的拓扑内的节点，
所述装置包括第四收发单元，所述第四收发单元被配置为：
接收所述第一IAB-donor-CU发送的第一RRC重配置消息；以及
向所述第一IAB-donor-CU发送RRC重配置完成消息，
其中，所述第一RRC重配置消息根据第二IAB-donor-CU发送给所述第一IAB-donor-CU的同意流量卸载的回复而生成，
所述第一RRC重配置消息包括为所述后裔节点的DU分配的至少一个TNL地址，所述TNL地址锚定(anchored)在所述第二IAB-donor-CU的拓扑内的第二IAB-donor-DU，
其中，所述RRC重配置完成(RRCReconfigurationComplete)消息用于表示所述后裔节点已经收到所述第一RRC重配置消息，并完成了重配置。
根据本申请实施例的另一个方面，提供一种发送和接收信号的方法，与上述任一方面的发送和接收信号的装置对应。
本申请实施例的有益效果在于：第一IAB-donor-CU向第二IAB-donor-CU发送流量卸载请求，第二IAB-donor-CU向第一IAB-donor-CU发送同意流量卸载的回复或拒绝流量卸载的回复，由此，能够在第一IAB-donor-CU的网络拓扑和第二IAB-donor-CU的网络拓扑之间建立冗余路径。
参照后文的说明和附图，详细公开了本申请的特定实施方式，指明了本申请的原理可以被采用的方式。应该理解，本申请的实施方式在范围上并不因而受到限制。在所附权利要求的精神和条款的范围内，本申请的实施方式包括许多改变、修改和等同。
针对一种实施方式描述和/或示出的特征可以以相同或类似的方式在一个或更多个其它实施方式中使用，与其它实施方式中的特征相组合，或替代其它实施方式中的特征。
应该强调，术语“包括/包含”在本文使用时指特征、整件、步骤或组件的存在，但 并不排除一个或更多个其它特征、整件、步骤或组件的存在或附加。
附图说明
在本申请实施例的一个附图或一种实施方式中描述的元素和特征可以与一个或更多个其它附图或实施方式中示出的元素和特征相结合。此外，在附图中，类似的标号表示几个附图中对应的部件，并可用于指示多于一种实施方式中使用的对应部件。
图1是IAB拓扑结构的一个示意图；
图2示出了在宿主间(inter-CU)拓扑冗余的场景下的一个拓扑传输路径的例子；
图3是第一方面的实施例的发送和接收信号的方法的一个示意图；
图4是第二方面的实施例的发送和接收信号的方法的一个示意图；
图5是实施例1中IAB节点的第二路径的建立过程的一个示意图；
图6是实施例2中为IAB节点的后裔节点建立宿主间冗余路径方法的一个示意图；
图7示出了为IAB节点加入SN变成双连接节点并建立冗余路径的示意图；
图8是流量卸载过程成功的一个示意图；
图9是流量卸载过程失败的一个示意图；
图10是流量卸载的发起方提出冗余路径释放的一个示意图；
图11是流量卸载的接受方提出冗余路径释放的一个示意图；
图12是第三方面的实施例的发送和接收信号的方法的一个示意图；
图13是第三方面的实施例的发送和接收信号的方法的一个示意图；
图14是本申请实施例的发送和接收装置信号的的一示意图；
图15是第六方面的实施例中发送和接收信号的装置的一个示意图；
图16是第七方面的实施例中发送和接收信号的装置的一个示意图；
图17是第八方面的实施例中发送和接收信号的装置的一个示意图；
图18是本申请实施例的网络设备的构成示意图；
图19是本申请实施例的终端设备的示意图。
具体实施方式
参照附图，通过下面的说明书，本申请的前述以及其它特征将变得明显。在说明 书和附图中，具体公开了本申请的特定实施方式，其表明了其中可以采用本申请的原则的部分实施方式，应了解的是，本申请不限于所描述的实施方式，相反，本申请包括落入所附权利要求的范围内的全部修改、变型以及等同物。
在本申请实施例中，术语“第一”、“第二”等用于对不同元素从称谓上进行区分，但并不表示这些元素的空间排列或时间顺序等，这些元素不应被这些术语所限制。术语“和/或”包括相关联列出的术语的一种或多个中的任何一个和所有组合。术语“包含”、“包括”、“具有”等是指所陈述的特征、元素、元件或组件的存在，但并不排除存在或添加一个或多个其他特征、元素、元件或组件。
在本申请实施例中，单数形式“一”、“该”等包括复数形式，应广义地理解为“一种”或“一类”而并不是限定为“一个”的含义；此外术语“所述”应理解为既包括单数形式也包括复数形式，除非上下文另外明确指出。此外术语“根据”应理解为“至少部分根据……”，术语“基于”应理解为“至少部分基于……”，除非上下文另外明确指出。
在本申请实施例中，术语“通信网络”或“无线通信网络”可以指符合如下任意通信标准的网络，例如新无线(NR，New Radio)、长期演进(LTE，Long Term Evolution)、增强的长期演进(LTE-A，LTE-Advanced)、宽带码分多址接入(WCDMA，Wideband Code Division Multiple Access)、高速报文接入(HSPA，High-Speed Packet Access)等等。
并且，通信***中设备之间的通信可以根据任意阶段的通信协议进行，例如可以包括但不限于如下通信协议：1G(generation)、2G、2.5G、2.75G、3G、4G、4.5G以及5G、新无线(NR，New Radio)等等，和/或其他目前已知或未来将被开发的通信协议。
在本申请实施例中，术语“网络设备”例如是指通信***中将终端设备接入通信网络并为该终端设备提供服务的设备。网络设备可以包括但不限于如下设备：集成的接入和回传节点(IAB-node)、基站(BS，Base Station)、接入点(AP、Access Point)、发送接收点(TRP，Transmission Reception Point)、广播发射机、移动管理实体(MME、Mobile Management Entity)、网关、服务器、无线网络控制器(RNC，Radio Network Controller)、基站控制器(BSC，Base Station Controller)等等。
其中，基站可以包括但不限于：节点B(NodeB或NB)、演进节点B(eNodeB或eNB)以及5G基站(gNB)，等等，此外还可包括远端无线头(RRH，Remote Radio  Head)、远端无线单元(RRU，Remote Radio Unit)、中继(relay)或者低功率节点(例如femeto、pico等等)。并且术语“基站”可以包括它们的一些或所有功能，每个基站可以对特定的地理区域提供通信覆盖。术语“小区”可以指的是基站和/或其覆盖区域，这取决于使用该术语的上下文。
在本申请实施例中，术语“用户设备”(UE，User Equipment)或者“终端设备”(TE，Terminal Equipment或Terminal Device)例如是指通过网络设备接入通信网络并接收网络服务的设备。终端设备可以是固定的或移动的，并且也可以称为移动台(MS，Mobile Station)、终端、用户台(SS，Subscriber Station)、接入终端(AT，Access Terminal)、站，等等。
其中，终端设备可以包括但不限于如下设备：蜂窝电话(Cellular Phone)、个人数字助理(PDA，Personal Digital Assistant)、无线调制解调器、无线通信设备、手持设备、机器型通信设备、膝上型计算机、无绳电话、智能手机、智能手表、数字相机，等等。
再例如，在物联网(IoT，Internet of Things)等场景下，终端设备还可以是进行监控或测量的机器或装置，例如可以包括但不限于：机器类通信(MTC，Machine Type Communication)终端、车载通信终端、设备到设备(D2D，Device to Device)终端、机器到机器(M2M，Machine to Machine)终端，等等。
此外，术语“网络侧”或“网络设备侧”是指网络的一侧，可以是某一基站，也可以包括如上的一个或多个网络设备。术语“用户侧”或“终端侧”或“终端设备侧”是指用户或终端的一侧，可以是某一UE，也可以包括如上的一个或多个终端设备。
在本申请的各实施例中，高层信令例如可以是无线资源控制(RRC)信令；例如称为RRC消息(RRC message)，例如包括MIB、***信息(system information)、专用RRC消息；或者称为RRC IE(RRC information element)。高层信令例如还可以是F1-C信令，或者叫F1AP协议。但本申请不限于此。
在本申请的各实施例中，多个UE通过多跳的IAB节点，连接到IAB-donor，最后接入网络，该网络例如是5G网络。
图2示出了在宿主间(inter-CU)拓扑冗余的场景下的一个拓扑传输路径的例子。图2中的Donor-CU1也被称为IAB-donor-CU1，Donor-CU2也被称为IAB-donor-CU2。
如图2所示，Donor-CU1是IAB节点3和IAB节点4的F1终结(terminating) 宿主。IAB节点3是双连接节点，其有两条路径可以到达Donor-CU1。IAB节点4也可以有两条路径到达Donor-CU1。以IAB节点4作为接入(access)IAB节点为例，IAB节点4到Donor-CU1之间的某些数据通过Donor-CU1控制的拓扑网络进行传输(称为第一路径，如实线箭头所示)，某些数据经由Donor-CU2控制的拓扑网络进行传输(称为第二路径，如虚线箭头所示)，从而达到数据分流，负载均衡的目的。类似的，IAB节点3以及IAB节点3的其他后裔节点(未在图中示出)也可以作为接入IAB节点建立第二路径。
在图2中，IAB节点1是IAB节点3的第一父节点，IAB节点2是IAB节点3的第二父节点，IAB节点4是IAB节点3的后裔节点。为了简化，图中IAB节点4下面的UE没有画出。
在本申请各方面的实施例中，第一IAB-donor-CU可以是图2中的Donor-CU1，第二IAB-donor-CU可以是图2中的Donor-CU2，IAB节点可以是图2中的IAB节点3，IAB节点3的后裔节点可以是图2中的IAB节点4，IAB节点3的第一父节点可以是图2中的IAB节点1，IAB节点3的第二父节点可以是图2中的IAB节点2，IAB节点3的第一父节点(例如，IAB节点1)是第一IAB-donor-CU的拓扑内的节点，IAB节点3的第二父节点(例如，IAB节点2)是第二IAB-donor-CU的拓扑内的节点。第二IAB-donor-DU可以是图2中的Donor-DU2。
在图2中，在第一路径和第二路径都被建立的情况下，IAB节点3与第一父节点(例如，IAB节点1)连接，并且IAB节点3与第二父节点(例如，IAB节点2)连接的情况。此外，在第二路径没有被建立之前(即，在没有执行本申请的发送和接收信号的方法之前)，IAB节点3与第二父节点(例如，IAB节点2)可以是已经连接的状态，也可以是尚未连接(即，即将连接)的状态。
在本申请各方面的实施例中，接入IAB节点包括IAB节点(例如，图2的IAB节点3)和/或该IAB节点的后裔节点(例如，图2的IAB节点4)，或者，即将成为双连接的IAB节点(例如，即将与第一IAB-donor-CU和第二IAB-donor-CU连接的节点)。
在本申请各方面的实施例中，IAB-DU可以表示IAB节点的分布式单元，即，IAB的DU；IAB-MT可以表示IAB节点的移动终端，即，IAB的MT。
在本申请的各实施例中，Donor-CU的拓扑内的节点指该节点的DU部分被该 Donor-CU管理，也就是该节点的F1接口终结到该Donor-CU上。
在本申请的各实施例中，Donor-CU与IAB-donor-CU含义相同，二者可以互换。
第一方面的实施例
本申请第一方面的实施例提供一种发送和接收信号的方法。该方法应用于第一集成的接入和回传节点宿主中心单元(IAB-donor-CU)。本申请第一方面的实施例从第一IAB-donor-CU一侧对该发送和接收信号的方法进行说明。其中，第一IAB-donor-CU例如可以是图2中的Donor-CU1。
图3是第一方面的实施例的发送和接收信号的方法的一个示意图，如图3所示，该方法包括：
操作301、向第二IAB-donor-CU发送流量卸载请求；以及
操作302、接收第二IAB-donor-CU发送的同意流量卸载的回复或拒绝流量卸载的回复。
在本申请中，操作301和操作302能够支持在第一IAB-donor-CU和第二IAB-donor-CU之间的拓扑冗余，从而能够进一步的提高路径的多样性，更好地满足负载均衡的需求。
在至少一个实施例中，操作301发送的流量卸载请求中包括为IAB节点和/或该IAB节点的后裔节点建立跨宿主的冗余路径的请求。
例如，第一IAB-donor-CU在从IAB节点到该IAB节点的后裔节点之间进行回传无线链路控制(BH RLC)信道的配置和BAP子层的路由表的配置，用于支持第二路径的路由和BH RLC信道映射，由此，用于为后裔节点建立冗余路径；此外，第一IAB-donor-CU还可以根据同意流量卸载的回复，对IAB节点进行BAP路由标识映射的配置，由此，在IAB节点处，能够执行第一IAB-donor-CU控制的第一路径的拓扑与第二IAB-donor-CU控制的第二路径的拓扑之间的BAP路由转换，从而为后裔节点建立冗余路径；此外，第一IAB-donor-CU还可以通过用户设备上下文修改请求(UE CONTEXT MODIFICATION REQUEST)消息或者用户设备上下文建立请求(UE CONTEXT SETUP REQUEST)消息，将第一IAB-donor-CU到IAB节点和/或该IAB节点的后裔节点的DU的F1-U通道从第一路径迁移(migrate)到第二路径，由此，为IAB节点和/或后裔节点建立冗余路径。
在至少一个实施例中，操作302中的同意流量卸载的回复可以表示至少部分地接受流量卸载请求。其中，部分地接受流量卸载请求是指：为某些TNL关联的F1-C通道建立冗余路径，或者为某些F1-U通道建立冗余路径。
在至少一个实施例中，在IAB节点与第一父节点连接，并且，IAB节点与第二父节点也连接的情况下：流量卸载请求可以被包含在流量卸载请求消息中，流量卸载请求消息例如是TRAFFIC OFFLOAD REQUEST消息，或者是Redundant Path Establishment Request消息等；同意流量卸载的回复可以被包含在流量卸载请求接受消息中，该流量卸载请求接受消息例如是TRAFFIC OFFLOAD REQUEST ACKNOWLEDGE消息；拒绝流量卸载的回复可以被包含在流量卸载拒绝消息中，该流量卸载拒绝消息例如是TRAFFIC OFFLOAD REQUEST REJECT消息。
在一个实施方式中，流量卸载请求消息可以包括流量卸载发起节点的用户设备在Xn接口的标识(UE XnAP ID)，和/或一个或多个F1-C的标识信息。其中，流量卸载发起节点是指第一IAB-donor-CU；用户设备是指接入IAB节点(IAB节点作为IAB-donor的用户设备)；该F1-C的标识信息用于为接入IAB节点的一个或多个F1-C建立冗余路径。
在另一个实施方式中，流量卸载请求消息包括如下信息中的至少之一者：流量卸载发起节点的UE XnAP ID，接入IAB节点的BAP地址，TNL地址，一个或多个F1-U通道标识信息，F1-C和/或各F1-U通道的IP报头信息(IP header information)，各F1-U通道的服务质量(Quality of Service，QoS)信息。
在上述两个实施方式中，在接受对于至少部分的F1-C和/或F1-U通道的流量卸载请求的情况下，流量卸载请求接受消息中可以包括如下信息中的至少一者：
流量卸载发起节点的UE XnAP ID，流量卸载接受节点的UE XnAP ID，该F1-C和/或F1-U通道的标识信息，为接入IAB节点的DU新分配的TNL地址，为该F1-C和/或F1-U通道配置的在双连接IAB节点和第二父节点之间的链路上的BH RLC信道标识，第二父节点的BAP地址，第二IAB-donor-CU控制的拓扑中的BAP路由标识，IAB节点的第二BAP地址。其中，流量卸载接受节点是指第二IAB-donor-CU；流量卸载接受节点UE XnAP ID是指接入IAB节点在第二IAB-donor-CU的节点内的Xn接口标识。根据流量发起节点和流量接受节点对应MN还是SN，流量卸载发起节点的UE XnAP ID和流量卸载接受节点的UE XnAP ID还可以分别叫M-NG-RAN node  UE XnAP ID(主基站节点的UE XnAP ID)或S-NG-RAN node UE XnAP ID(辅基站节点的UE XnAP ID)。
在上述两个实施方式中，在拒绝对于所有F1-C和F1-U通道的流量卸载请求的情况下，第二IAB-donor-CU发送流量卸载请求拒绝消息，该流量卸载请求拒绝消息中包括流量卸载发起节点的UE XnAP ID。
在至少一个实施例中，在IAB节点与第一父节点连接，并且，IAB节点与第二父节点也连接的情况下：如果第一IAB-donor-CU是主节点(MN)，流量卸载请求的内容以及同意流量卸载的回复或拒绝流量卸载的回复的内容被作为信息元素(IE)，被包含在XnAP的辅基站节点修改准备(S-NG-RAN node Modification Preparation)过程的消息中。
在至少另一个实施例中，在IAB节点与第一父节点连接，并且，该IAB节点没有与第二父节点连接的情况下：流量卸载请求的内容以及同意流量卸载的回复或者拒绝流量卸载的回复的内容可以被作为信息元素(IE)，被包含在XnAP的辅基站节点添加准备(S-NG-RAN node Addition Preparation)过程的消息中。
例如，流量卸载请求可以被包含在第一IAB-donor-CU向第二IAB-donor-CU发送的添加辅节点的请求(S-NODE ADDITION REQUEST)消息中；又例如，同意流量卸载的回复可以被包含在第二IAB-donor-CU向第一IAB-donor-CU发送的SN添加请求接受(S-NODE ADDITION REQUEST ACKNOWLEDGE)消息中。
如图3所示，该方法还包括：
操作303、根据同意流量卸载的回复，向IAB节点和/或IAB节点的后裔IAB节点发送第一RRC重配置消息。
在操作303中，第一RRC重配置消息可以包括：为IAB节点(例如，图2中的IAB节点3)和/或IAB节点的后裔节点(例如，图2中的IAB节点4)的分布单元(DU)各自分配的至少一个传输网络层(transport network layer，TNL，或transport layer)地址，该TNL地址锚定在第二IAB-donor-CU的拓扑内的第二IAB-donor-DU(例如，图2中的Donor-DU2)。
在操作303中，第一RRC重配置消息的BAP配置信息元素(bap-Config IE)包括用于表示为该IAB节点配置的第二BAP地址的字段，该字段例如是bap-Address-redundant，或者bap-Address-second等，用于表明是第二BAP地址；或 者，第一RRC重配置消息的BAP配置信息元素(bap-Config IE)中的BAP地址字段包括列表，列表中的每一个条目是一个BAP地址及其关联信息，例如，该列表可以是bap-AddressList，该列表中的每一个条目是一个BAP地址及其关联信息，每一个条目比如是{bap-Address,‘MCG’/‘SCG’}，或者{bap-Address,iab-donor-DU-BAP-Address}等。由此，能够为IAB节点3分配第二BAP地址，该第二BAP地址可以用于冗余路径(即，经过Donor-DU2的第二路径)上的BAP路由配置。
在至少一个实施例中，在操作303中为IAB节点和/或其后裔节点分配了新的TNL地址的情况下，第一IAB-donor-CU可以将新的TNL地址加入到该IAB节点和/或其后裔节点的DU与第一IAB-donor-CU的F1-C关联中。
如图3所示，该发送和接收信号的方法还可以包括：
操作304、第一IAB-donor-CU发送或接收冗余路径释放请求；以及
操作305、第一IAB-donor-CU接收或发送冗余路径释放请求接受的消息。
例如，第一IAB-donor-CU向第二IAB-donor-CU发送冗余路径释放请求，第一IAB-donor-CU从第二IAB-donor-CU接收冗余路径释放请求接受的消息；又例如，第一IAB-donor-CU接收第二IAB-donor-CU发送的冗余路径释放请求，第一IAB-donor-CU向第二IAB-donor-CU发送冗余路径释放请求接受的消息。
在至少一个实施例中，冗余路径释放请求包括：流量卸载发起节点的UE XnAP ID，流量卸载接受节点的UE XnAP ID，需要释放冗余路径的F1-C关联的TNL地址，或者，需要释放冗余路径的F1-U通道的用户平面传输层信息(UP Transport Layer Information)。其中，冗余路径例如是图2所示的第二路径。
在至少一个实施例中，在第一IAB-donor-CU和第二IAB-donor-CU中的主节点(master node，MN)发送冗余路径释放请求的情况下，该冗余路径释放请求的内容和冗余路径释放请求接受的消息的内容都被作为IE，被包含在辅基站节点修改准备(S-NG-RAN node Modification Preparation)过程中。
在至少一个实施例中，在进行IAB节点的辅基站节点释放(S-NG-RAN node Release)过程时，将SN拓扑中所有的与IAB节点相关的冗余路径释放。
根据本申请第一方面的实施例，能够支持在第一IAB-donor-CU和第二IAB-donor-CU之间建立拓扑冗余路径，从而能够进一步的提高路径的多样性，更好 地满足负载均衡的需求；此外，也能够释放第一IAB-donor-CU和第二IAB-donor-CU之间的拓扑冗余路径。
第二方面的实施例
至少针对与第一方面的实施例相同的问题，本申请第二方面的实施例提供一种发送和接收信号的方法，与第一方面的实施例的方法对应。本申请第二方面的实施例的发送和接收信号的方法应用于第二集成的接入和回传节点宿主中心单元(IAB-donor-CU)。本申请第二方面的实施例从第二IAB-donor-CU一侧对该发送和接收信号的方法进行说明。其中，第二IAB-donor-CU例如可以是图2中的Donor-CU2。
图4是第二方面的实施例的发送和接收信号的方法的一个示意图，如图4所示，该方法包括：
操作401、接收第一IAB-donor-CU发送的流量卸载请求；以及
操作402、向第一IAB-donor-CU发送同意流量卸载的回复或者拒绝流量卸载的回复。
在本申请中，操作401和操作402能够支持在第一IAB-donor-CU和第二IAB-donor-CU之间的拓扑冗余，从而能够进一步的提高路径的多样性，更好地满足负载均衡的需求。
在至少一个实施例中，操作401中的流量卸载请求中包括为IAB节点(例如，图2的IAB节点3)和/或该IAB节点的后裔节点(例如，图2的IAB节点4)建立冗余路径的请求。
操作402中的同意流量卸载的回复表示至少部分地接受流量卸载请求。其中，部分地接受流量卸载请求是指：为某些TNL关联的F1-C，或者某些F1-U通道建立冗余路径。
在IAB节点与第一父节点连接，并且，IAB节点与第二父节点连接的情况下：流量卸载请求可以被包含在流量卸载请求消息中；同意流量卸载的回复可以被包含在流量卸载请求接受消息中，流量卸载请求接受消息例如可以是TRAFFIC OFFLOAD REQUEST ACKNOWLEDGE消息；拒绝流量卸载的回复可以被包含在流量卸载拒绝消息中，流量卸载拒绝消息例如可以是TRAFFIC OFFLOAD REQUEST REJECT。
流量卸载请求消息可以包括流量卸载发起节点的用户设备在Xn接口的标识(UE  XnAP ID)，和/或一个或多个F1-C的标识信息。该F1-C的标识信息用于为接入IAB节点的一个或多个F1-C建立冗余路径，该接入IAB节点包括IAB节点和/或该IAB节点的后裔节点，或者即将成为双连接的IAB节点。
流量卸载请求消息可以包括如下信息中的至少之一者：流量卸载发起节点的UE XnAP ID，接入IAB节点的BAP地址，TNL地址，一个或多个F1-U通道标识信息，F1-C和/或各F1-U通道的IP报头信息(IP header information)，各F1-U通道的业务质量(QoS)信息。
在至少一个实施例中，在接受对于F1-C和/或F1-U通道的流量卸载请求的情况下，流量卸载请求接受消息中可以包括如下信息中的至少一者：
流量卸载发起节点UE XnAP ID，流量卸载接受节点UE XnAP ID，该F1-C和/或F1-U通道的标识信息，为接入IAB节点的DU新分配的TNL地址，为该F1-C和/或F1-U通道配置的在双连接IAB节点和第二父节点之间的链路上的BH RLC信道标识，第二父节点的BAP地址，第二IAB-donor-CU控制的拓扑中的BAP路由标识，该IAB节点的第二BAP地址。其中，流量卸载接受节点是指第二IAB-donor-CU；流量卸载接受节点UE XnAP ID是指接入IAB节点在第二IAB-donor-CU的节点内的Xn接口标识。
此外，在拒绝对于所有F1-C和F1-U通道的流量卸载请求的情况下，第二IAB-donor-CU可以向第一IAB-donor-CU发送流量卸载请求拒绝消息，该流量卸载请求拒绝消息中可以包括流量卸载发起节点的UE XnAP ID。
在至少一个实施例中，在IAB节点与第一父节点连接，并且，IAB节点与第二父节点连接的情况下：如果第一IAB-donor-CU是主节点(MN)，那么流量卸载请求的内容以及同意流量卸载的回复或拒绝流量卸载的回复的内容可以被作为信息元素(IE)，被包含在XnAP的辅基站节点修改准备(S-NG-RAN node Modification Preparation)过程的消息中。
在至少一个实施例中，在IAB节点与第一父节点连接，并且，IAB节点没有与第二父节点连接的情况下：流量卸载请求的内容以及同意流量卸载的回复或拒绝流量卸载的回复的内容可以被作为信息元素(IE)，被包含在XnAP的辅基站节点添加准备(S-NG-RAN node Addition Preparation)过程的消息中。
例如，流量卸载请求被包含在第一IAB-donor-CU向第二IAB-donor-CU发送的添 加辅节点的请求(S-NODE ADDITION REQUEST)消息中。又例如，同意流量卸载的回复被包含在第二IAB-donor-CU向第一IAB-donor-CU发送的SN添加请求接受(S-NODE ADDITION REQUEST ACKNOWLEDGE)消息中。
如图4所述，该方法还包括：
操作403、在IAB节点已经与第二父节点连接时，第二IAB-donor-CU向第二父节点发送用户设备上下文修改请求(UE CONTEXT MODIFICATION REQUEST)消息，以修改该IAB节点移动终端(MT)的用户设备(UE)上下文，并设置至少一个承载(bearer)；或者
操作404、在IAB节点没有与第二父节点连接时，第二IAB-donor-CU向第二父节点发送用户设备上下文建立请求(UE CONTEXT SETUP REQUEST)消息，以建立该IAB节点的MT的UE上下文，并设置至少一个承载(bearer)。
如图4所述，该方法还包括：
操作405、第二IAB-donor-CU针对该IAB节点和/或该IAB节点的后裔节点所需的第二路径，从该IAB节点到第二IAB-donor-DU之间进行BH RLC信道的配置和BAP子层的路由表的配置。
如图4所示，该方法还包括：
操作406、第二IAB-donor-CU向该IAB节点的移动终端(MT)发送为该IAB节点配置的第二BAP的地址。
例如，在操作406中，第二IAB-donor-CU可以向该IAB节点的移动终端(MT)发送第二重配置(RRCReconfiguration)消息，该第二RRCReconfiguration消息包括BAP配置信息(bap-Config)，BAP配置信息包括为该IAB节点配置的第二BAP的地址。
在本申请中，通过操作403～操作403，能够为IAB节点设置第二路径。
如图4所示，该方法还包括：
操作407、第二IAB-donor-CU接收或发送冗余路径释放请求；
操作408、第二IAB-donor-CU发送或接收冗余路径释放请求接受的消息。
例如，在操作407中，第二IAB-donor-CU接收第一IAB-donor-CU发送的冗余路径释放请求，在操作408中，第二IAB-donor-CU向第一IAB-donor-CU发送冗余路径释放请求接受的消息。又例如，在操作407中，第二IAB-donor-CU向第一 IAB-donor-CU发送冗余路径释放请求，在操作408中，第二IAB-donor-CU接收第一IAB-donor-CU发送的冗余路径释放请求接受的消息。
在至少一个实施例中，操作407的冗余路径释放请求包括：流量卸载发起节点的UE XnAP ID，流量卸载接受节点的UE XnAP ID，需要释放冗余路径的F1-C关联的TNL地址，或需要释放冗余路径的F1-U通道的用户平面传输层信息(UP Transport Layer Information)。其中，冗余路径例如是图2所示的第二路径。
在第一IAB-donor-CU和第二IAB-donor-CU中的MN发送冗余路径释放请求的情况下，冗余路径释放请求的内容和冗余路径释放请求接受的消息的内容都可以被作为IE，被包含在辅基站节点修改准备(S-NG-RAN node Modification Preparation)过程中。
在进行IAB节点的辅基站节点释放(S-NG-RAN node Release)过程时，可以将辅节点(SN)拓扑中与IAB节点(例如，图2的IAB节点3)相关的所有的冗余路径释放。
根据本申请第二方面的实施例，能够支持在第一IAB-donor-CU和第二IAB-donor-CU之间建立拓扑冗余路径，从而能够进一步的提高路径的多样性，更好地满足负载均衡的需求；此外，也能够释放第一IAB-donor-CU和第二IAB-donor-CU之间的拓扑冗余路径。
下面，结合具体的实施例，对第一方面的实施例的发送和接收信号的方法以及第二方面的实施例的发送和接收信号的方法进行更具体地说明。
实施例1、
在实施例1中，IAB节点(例如，图2中的IAB节点3)处于已经双连接到两个不同IAB-donor-CU的状态，因此，在实施例1中，IAB节点3也被称为双连接IAB节点(Dual-connecting IAB-node)。
由于F1接口可能在IAB节点的MT连接到两个不同宿主之后建立，所以F1终结节点可能是MN，也可能是SN。在第一路径上，第一IAB-donor-CU(例如，图2的IAB-donor-CU1)是F1终结节点，在本实施例中可以是主节点(master node，MN)，也可以是辅节点(secondary node，SN)。在第二路径上，第二IAB-donor-CU(例如，图2的IAB-donor-CU2)是非F1终结(non-F1-terminating)节点，在本实施例中可以是SN，也可以是MN。
图5是实施例1中IAB节点的第二路径的建立过程的一个示意图。如图5所示，该建立过程包括如下步骤：
1.IAB-donor-CU1向IAB-donor-CU2发起流量卸载请求(例如，TRAFFIC OFFLOAD REQUEST)，即，为双连接IAB节点建立冗余路径的请求。如果IAB-donor-CU2拒绝，IAB-donor-CU2直接发送拒绝流量卸载的回复，不进行下面的步骤。
2.如果IAB-donor-CU2同意或者部分同意流量卸载的请求，IAB-donor-CU2向双连接IAB节点的第二父节点的IAB-DU发送UE CONTEXT MODIFICATION REQUEST消息，来修改双连接IAB-MT的UE上下文，设置一个或多个承载(bearer)。
3.双连接IAB节点的第二父节点的IAB-DU向IAB-donor-CU2回应一个UE CONTEXT MODIFICATION RESPONSE消息。
4.如果需要给双连接IAB节点分配第二个BAP地址，则IAB-donor-CU2向第二父节点的IAB-DU发送下行无线链路控制消息传送(例如，DL RRC MESSAGE TRANSFER)消息，其中包含产生的RRCReconfiguration消息。该RRCReconfiguration消息可以包含bap-Config，里面含有配置的第二BAP地址。
5.第二父节点将收到的RRCReconfiguration消息转发给双连接IAB-MT。
6.双连接IAB-MT向第二父节点回应一个RRC配置完成(RRCReconfigurationComplete)消息。
7.第二父节点向IAB-donor-CU2发送一个上行无线链路控制消息传送(UL RRC MESSAGE TRANSFER)消息，里面包含收到的RRCReconfigurationComplete消息。
8.IAB-donor-CU2在第二路径上从双连接IAB节点到IAB-donor-DU2之间进行BH RLC信道的配置和BAP子层的路由表的配置(Configuration of BAP route and mapping rules along the second path between dual-connecting IAB-node and the second path IAB-donor-DU via the second parent IAB-node.)。第8步可以在更早的时候进行，比如在第2步之后直接进行。
9.IAB-donor-CU2向IAB-donor-CU1回应同意流量卸载的消息。
10.根据IAB-donor-CU2的回应消息内容(例如，分配的TNL地址等)，IAB-donor-CU1向第一父节点的IAB-DU发送DL RRC MESSAGE TRANSFER消息，里面包含产生的RRCReconfiguration消息。这个RRCReconfiguration消息可以包含为 双连接IAB-DU分配的一个或多个TNL地址，这些地址锚定在第二路径的IAB-donor-DU(例如，图2的Donor-DU2)。IAB-donor-CU2可以从Donor-DU2那里主动获得这些TNL地址。当IPsec通道模式被用来保护F1和非F1流量时，分配的TNL地址是外部(outer)IP地址。如果以前对双连接IAB节点的F1-C或F1-U建立过冗余路径，已经分配过TNL地址，可以不用再分配。
11.第一父节点将收到的RRCReconfiguration消息转发给双连接IAB-MT。
12.双连接IAB-MT向第二父节点回应一个RRCReconfigurationComplete消息。
13.第一父节点向IAB-donor-CU2发送一个UL RRC MESSAGE TRANSFER消息，里面传达了收到的RRCReconfigurationComplete消息。
15.如果第10步中分配了新的TNL地址，将这些地址加入到双连接IAB-DU与IAB-donor-CU1的F1-C关联中(Addition of new TNL address(es)to dual-connecting IAB-node DU’s F1-C associations.)。IAB-donor-CU1可以为第二路径的F1AP消息配置新的UL BH information(上行回传信息)。具体过程例如可以通过F1AP的gNB-DU Configuration Update过程实现。
16.IAB-donor-CU1可以通过UE CONTEXT MODIFICATION REQUEST消息，将IAB-donor-CU1到双连接IAB-DU的F1-U通道从第一路径迁移(migrate)到第二路径。
17.双连接IAB-DU回复UE CONTEXT MODIFICATION RESPONSE消息。
由此，双连接IAB节点的第二路径可以被建立，上行用户数据(uplink user data)或下行用户数据(downlink user data)可以通过第二路径在用户设备(UE)和第一IAB-donor-CU之间传送。
例如，如图5所示，在第二路径上，上行用户数据的传输顺序为：UE——双连接IAB节点——第二父节点——第二路径上的中间跳IAB节点(Intermediate hop IAB-donor on the second path)——第二路径上的宿主分布式单元(例如，图2的Donor-DU2)——第一IAB-donor-CU。
又例如，如图5所示，在第二路径上，下行用户数据的传输顺序为：第一IAB-donor-CU——第二路径上的宿主分布式单元(例如，图2的Donor-DU2)——第二路径上的中间跳IAB节点(Intermediate hop IAB-donor on the second path)——第二父节点——双连接IAB节点——UE。
在实施例一中，步骤4-7是为双连接IAB节点分配第二BAP地址。第二BAP地址可以用于冗余路径(即，第二路径)上的BAP路由配置。双连接IAB节点需要将BAP地址与主小区组(master cell group，MCG)/辅小区组(secondary cell group，SCG)或者是MN/SN相关联。如果双连接节点收到的带有BAP地址的RRCReconfiguration消息是来自于MCG，或是通过SRB1(SRB：signalling radio bearer，信令无线承载)收到，则将收到的BAP地址和MCG或者MN相关联；如果双连接节点收到的带有BAP地址的RRCReconfiguration消息是来自于SCG，或是通过SRB3收到，则将收到的BAP地址和SCG或者SN相关联。
此外，也可以使用其他方法分配第二BAP地址。例如，可以去掉步骤4-7，并且，将第二BAP地址放到步骤10～步骤13中和其他RRC配置消息一起发送。这样需要修改现有的RRCReconfiguration消息格式，有两种修改方法：
方法1：在RRCReconfiguration消息的bap-Config IE(information element：信息元素)中增加一个字段，比如叫bap-Address-redundant，或者bap-Address-second等，表明该字段代表第二BAP地址。
方法2：将RRCReconfiguration消息的bap-Confg IE中的bap-Address字段改为一个列表，比如叫bap-AddressList，该列表中的每一个条目是一个BAP地址和它的关联信息，该条目比如是{bap-Address，‘MCG’/‘SCG’}，或者{bap-Address，iab-donor-DU-BAP-Address}等。
实施例2、
在实施例2中，IAB节点(例如，图2中的IAB节点3)处于已经双连接到两个不同IAB-donor-CU的状态，因此，在实施例2中，IAB节点3也被称为双连接IAB节点(Dual-connecting IAB-node)。
实施例2用于说明为IAB节点的后裔节点(例如，图2中的IAB节点4)建立宿主间冗余路径的方法。
图6是实施例2中为IAB节点的后裔节点建立宿主间冗余路径方法的一个示意图。为了简化图示，后裔IAB节点和双连接IAB节点之间可能的节点没有示出。下面，对图6和图5的区别之处进行说明，二者相同或基本类似的步骤可以参考对实施例1的说明。
如图6所示，该建立过程包括如下步骤：
1.IAB-donor-CU1向IAB-donor-CU2发起流量卸载的请求，该请求中包括为双连接IAB节点的后裔节点建立冗余路径的请求。
4～7.步骤4～7与实施例1的步骤4～7相同，是在双连接IAB节点或者其他后裔IAB节点在之前并没有建立冗余路径的情况下，为双连接IAB节点分配第二BAP地址。此外，如果双连接IAB节点已经被分配过第二BAP地址，步骤4～7可以跳过不执行。
8.如果需要，IAB-donor-CU2在第二路径上针对后裔节点，从双连接IAB节点到IAB-donor-DU2之间进行BH RLC信道的配置和BAP子层的路由表的配置。和实施例1中针对双连接IAB节点的方法一样。
10.与图1的步骤10类似的，IAB-donor-CU1根据IAB-donor-CU2的回复消息，为后裔IAB节点配置一个或多个TNL地址，该一个或多个TNL地址锚定在IAB-donor-DU2上。
14.IAB-donor-CU1在从双连接IAB节点到后裔接入IAB节点之间进行BH RLC信道的配置和BAP子层的路由表的配置(Configuration of BAP route and mapping rules along the path between dual-connecting IAB-node and the access IAB-node for the redundant path.)，用于支持第二路径的路由和BH RLC信道映射。IAB-donor-CU1还基于IAB-donor-CU2的回应消息(例如，在步骤9中发送)，对双连接IAB节点进行BAP路由标识映射的配置(Configuration of BAP routing ID mapping)，用于两个拓扑之间的BAP路由转换。这些配置可以在更早的时候进行，比如在步骤10之后直接进行。
15.如果步骤10中分配了新的TNL地址，将这些地址加入到后裔IAB-DU与IAB-donor-CU1的F1-C关联中。IAB-donor-CU1可以为第二路径的F1AP消息配置新的上行回传信息(UL BH information)。
16.IAB-donor-CU1可以通过UE CONTEXT MODIFICATION REQUEST消息，将它到双连接IAB节点的后裔IAB-DU的F1-U通道从第一路径迁移(migrate)到第二路径。
17.后裔IAB-DU回复UE CONTEXT MODIFICATION RESPONSE消息。
由此，双连接IAB节点的后裔节点的第二路径可以被建立，上行用户数据(uplink user data)或下行用户数据(downlink user data)可以通过第二路径在用户设备(UE) 和第一IAB-donor-CU之间传送。
例如，如图6所示，在第二路径上，上行用户数据的传输顺序为：UE——后裔节点——双连接IAB节点——第二父节点——第二路径上的中间跳IAB节点(Intermediate hop IAB-donor on the second path)——第二路径上的宿主分布式单元(例如，图2的Donor-DU2)——第一IAB-donor-CU。
又例如，如图6所示，在第二路径上，下行用户数据的传输顺序为：第一IAB-donor-CU——第二路径上的宿主分布式单元(例如，图2的Donor-DU2)——第二路径上的中间跳IAB节点(Intermediate hop IAB-donor on the second path)——第二父节点——双连接IAB节点——后裔节点——UE。
基于不同实现，为后裔IAB节点建立冗余路径的过程可以在为双连接IAB节点建立冗余路径之后，即，图6的流程可以在图5的流程之后进行。或者，为后裔IAB节点建立冗余路径的过程可以在为双连接IAB节点建立冗余路径的同时进行，即，图6的流程可以与图5的流程同时进行。
实施例3、
在实施例3中，IAB节点的冗余路径建立之前，该IAB节点(例如，图2中的IAB节点3)是单连接节点，即，IAB节点连接到IAB-donor-CU1。
当IAB-donor-CU1判断为本拓扑网络的流量过载，需要借助其他Donor-CU管理的网络拓扑进行流量卸载时，对该IAB节点进行加入SN(例如，图2的IAB-donor-CU2)的操作，也就是使该IAB节点成为跨宿主(即，inter-CU)的双连接，并且将部分流量卸载到IAB-donor-CU2的拓扑，建立冗余路径。
图7示出了为IAB节点加入SN变成双连接节点并建立冗余路径的示意图。为了简化说明，双连接状态下的IAB节点分配第二BAP地址的步骤可以参考图5的步骤5～7，因而没有被示出在图7中。下面，主要说明图7所示的流程与图5的区别之处，相同之处不再重复说明。
图7的流程包括如下步骤：
1.IAB-MT发送一个测量报告(例如，MeasurementReport)消息给第一父节点的IAB-DU，该报告可以基于该IAB-MT之前从IAB-donor-CU1接收到的测量配置(例如，Measurement Configuration)而产生。
2.第一父节点的IAB-DU发送一个UL RRC MESSAGE TRANSFER消息给 IAB-donor-CU1来传送收到的MeasurementReport.
3.IAB-donor-CU1向IAB-donor-CU2发起添加SN的请求(S-NODE ADDITION REQUEST)消息，该消息里带有流量卸载的请求，也就是为IAB节点(例如，图2的IAB节点3)建立冗余路径的请求。具体信令见实施例4。如果IAB-donor-CU2拒绝添加SN的请求，可以发送拒绝流量卸载的回复，并且不用进行下面的步骤。如果IAB-donor-CU2同意添加SN的请求，但是拒绝流量卸载的请求，直接按照现有标准进行添加SN的流程，回复消息里包含拒绝流量卸载的内容，并且，不用进行下面的步骤。
4.如果同意或者部分同意流量卸载请求，IAB-donor-CU2向IAB节点的第二父节点的IAB-DU发送UE CONTEXT SETUP REQUEST消息，用于建立IAB-MT的UE上下文，设置一个或多个承载(bearer)，该一个或多个承载可以用于IAB-MT自身的信令以及可选的数据流量。
5.IAB节点的第二父节点的IAB-DU向IAB-donor-CU2回应一个UE CONTEXT SETUP RESPONSE消息。
7.IAB-donor-CU2向IAB-donor-CU1回应SN添加请求接受(S-NODE ADDITION REQUEST ACKNOWLEDGE)消息，其中包含同意流量卸载的IE。
12.IAB-donor-CU1向IAB-donor-CU2发送辅节点重配置完成(例如，S-NODE RECONFIGURATION COMPLETE)消息，表明对IAB节点的双连接配置成功完成。
13.IAB节点在第二父节点的IAB-DU进行随机接入过程。
对于图7中其他步骤的说明同实施例1。此外，在图7中，如果在步骤3里的消息中还包含了需要给后裔IAB节点建立冗余路径的请求，可以参照实施例2进行相应操作。
实施例4、
实施例4说明IAB-donor-CU1和IAB-donor-CU2之间的信令，也就是XnAP(Xn Application Protocol，Xn应用协议)过程。IAB-donor-CU1向IAB-donor-CU2发送流量卸载请求，用于将某F1-C或者一个或多个F1-U通道迁移到IAB-donor--CU2的拓扑冗余路径。
针对实施例1和2，可以通过增加新的双连接相关的XnAP过程，比如流量卸载(Traffic Offload)过程，以及新的XnAP消息。
图8是流量卸载过程成功的一个示意图。如图8所示，NG-RAN节点1(也就是IAB-donor-CU1)向NG-RAN节点2(也就是IAB-donor-CU2)发送流量卸载请求的消息，比如叫做TRAFFIC OFFLOAD REQUEST消息。NG-RAN节点2回复接受或者部分接受的消息，比如叫做TRAFFIC OFFLOAD REQUEST ACKNOWLEDGE消息。部分接受指为某些TNL关联的F1-C，或者某些F1-U通道建立冗余路径。
图9是流量卸载过程失败的一个示意图。如图9所示，NG-RAN节点1(也就是IAB-donor-CU1)向NG-RAN节点2(也就是IAB-donor-CU2)发送流量卸载请求的消息，比如TRAFFIC OFFLOAD REQUEST消息。如果NG-RAN节点2自己有比较高的流量负载，或者有其他失败发生，可以拒绝所有流量卸载请求，这样任意一个冗余路径都不会被建立。这个拒绝流量卸载消息可以叫TRAFFIC OFFLOAD REQUEST REJECT消息，该消息里可以包含一个失败的原因(cause)。
在流量卸载请求消息中可以包含流量卸载发起节点的UE XnAP ID，和/或一个或多个F1-C的标识信息。从而能够为一个或多个接入IAB节点建立冗余路径。这些接入IAB节点可以是双连接IAB节点或者即将成为双连接的IAB节点，也可以是双连接IAB节点的后裔IAB节点。流量卸载请求消息中还可以包含接入IAB节点的BAP地址。F1-C标识信息可以是TNL关联(association)，也可以是TNL关联的传输层信息(比如，IAB-DU控制平面传输层地址，也即TNL地址)。可以显式指示对该TNL关联进行F1-C的流量卸载，也可以隐式通过不提供F1-U的信息，说明是针对该TNL关联进行F1-C的流量卸载。
如果接受对于F1-C的流量卸载请求，Traffic Offload Request Acknowledge消息中可以包括流量卸载发起节点的UE XnAP ID，流量卸载接受节点的UE XnAP ID，该F1-C的标识信息，IAB-donor-DU2为接入IAB-DU新分配的TNL地址，为该F1-C配置的在双连接IAB节点和第二父节点之间的链路上的BH RLC信道标识，第二父节点的BAP地址，CU2控制的拓扑中的BAP路由标识(包括上行和下行)，可能的双连接IAB节点的第二BAP地址等。其中，第二父节点的BAP地址是为了让Donor-CU1在为双连接IAB节点配置路由表时配置冗余路径的上行路由的下一跳节点用的。Donor-CU2控制的拓扑中的BAP路由标识是指从Donor-DU2到双连接IAB节点之间的上行或下行BAP路由标识，为了Donor-CU1在为双连接IAB节点配置BAP路由标识映射时用的。
在流量卸载请求消息中还可以包含一个或多个F1-U通道，也就是数据无线承载(data radio bearer，DRB)的标识信息，表示为这些F1-U通道建立冗余路径。F1-U通道标识信息可以是UP Transport Layer Information(用户平面传输层信息)，它包括传输层地址和GTP-TEID(GPRS Tunnelling Protocol–Tunnel Endpoint ID)。请求消息中还可以包含接入IAB节点的BAP地址，TNL地址，F1-U的IP header information(IP报头信息)，QoS信息等。IP报头信息用于在Donor-DU2做IP层到层2(layer 2)的流量映射，QoS信息用于在冗余路径的各跳中进行BH RLC信道选择和配置。QoS信息可以是TR38.473中定义的DRB QoS IE，也可以是IE中的部分信息，比如5QI(5G QoS Identifier)。如果接受或部分接受对于F1-U通道的流量卸载请求，Traffic Offload Request Acknowledge消息中可以包括接受的F1-U通道的标识信息，为该F1-U通道配置的在双连接IAB节点和第二父节点之间的链路上的BH RLC信道标识，还可以包含新的TNL地址，第二父节点的BAP地址，CU2控制的拓扑中的BAP路由标识(包括上行和下行)，可能的双连接IAB节点的第二BAP地址等。
如果是已经有双连接的情况，且MN发起流量卸载请求，还可以将这些请求和回复消息的内容都作为IE，包含在现有XnAP的S-NG-RAN node Modification Preparation(辅基站节点修改准备)过程中。即，重用现有的消息，比如S-NODE MODIFICATION REQUEST，S-NODE MODIFICATION REQUEST ACKNOWLEDGE,S-NODE MODIFICATION REJECT等。其中，在重用现有消息时，如果拒绝所有流量卸载请求，但是同意任意其他修改请求，仍然使用S-NODE MODIFICATION REQUEST ACKNOWLEDGE消息。只有不同意任意修改请求且不同意任意流量卸载请求，或发生失败，才使用S-NODE MODIFICATION REJECT消息。
如果是实施例3，可以将这些消息的内容分别作为IE，包含在现有XnAP的S-NG-RAN node Addition Preparation(辅基站节点添加准备)过程中。也就是重用现有的消息，比如S-NODE ADDITION REQUEST,S-NODE ADDITION REQUEST ACKNOWLEDGE,S-NODE ADDITION REJECT等。其中，重用现有消息时，如果拒绝所有流量卸载请求，但是同意添加SN请求，仍然使用S-NODE ADDITION REQUEST ACKNOWLEDGE消息。只有不能添加SN或发生失败，才使用S-NODE MODIFICATION REJECT消息。
实施例5、
实施例5用于说明IAB-donor-CU1和IAB-donor-CU2之间的冗余路径的释放过程。
NG-RAN节点1(即，IAB-donor-CU1)和NG-RAN节点2(即，IAB-donor-CU2)都可以发起冗余路径的释放过程。可以增加新的双连接相关的XnAP过程来实现来释放过程。
流量卸载的发起方(例如，IAB-donor-CU1)和接受方(例如，IAB-donor-CU2)都可以提出冗余路径释放。图10是流量卸载的发起方提出冗余路径释放的一个示意图，图11是流量卸载的接受方提出冗余路径释放的一个示意图。
如图10和图11所示，为了区分是由流量卸载的发起方(例如，IAB-donor-CU1)还是接受方(例如，IAB-donor-CU2)提出的冗余路径释放，可以用不同的消息名称。例如，如图10所示，流量卸载的发起方，也就是F1终结宿主节点可以向非F1终结宿主节点发送流量卸载释放请求(TRAFFIC OFFLOAD RELEASE REQUEST)消息，非F1终结宿主节点回复流量卸载释放接受(TRAFFIC OFFLOAD RELEASE ACKNOWLEDGE)消息；如图11所示，非F1终结宿主节点可以向F1终结宿主节点发送流量卸载释放要求(TRAFFIC OFFLOAD RELEASE REQUIRED)消息，F1终结宿主节点回复流量卸载释放确认(TRAFFIC OFFLOAD RELEASE CONFIRM)消息。
TRAFFIC OFFLOAD RELEASE REQUEST/REQUIRED消息包含需要释放冗余路径的F1-C关联的TNL地址，或需要释放冗余路径的F1-U通道的UP Transport Layer Information。
冗余路径释放的具体过程为：如果需要，Donor-CU1和/或Donor-CU2释放冗余路径相关的BAP路由条目，修改或释放冗余路径需要的BH RLC信道；如果需要，Donor-CU1删除双连接IAB节点上的相关BAP路由标识的映射信息。
如果是MN发起冗余路径释放过程，还可以将上述的请求和回复消息的内容分别作为IE，包含在现有XnAP的S-NG-RAN node Modification Preparation(辅基站节点修改准备)过程中。也就是重用现有的消息，比如S-NODE MODIFICATION REQUEST,S-NODE MODIFICATION REQUEST ACKNOWLEDGE等。
在进行S-NG-RAN node Release(辅基站节点释放)过程时，将SN拓扑中所有的冗余路径释放。
第三方面的实施例
至少针对与第一方面的实施例相同的问题，本申请第三方面的实施例提供一种发送和接收信号的方法，与第一方面的实施例的方法对应。本申请第三方面的实施例的发送和接收信号的方法应用于IAB节点，该IAB节点例如是图2的IAB节点3。
图12是第三方面的实施例的发送和接收信号的方法的一个示意图，如图12所示，该方法包括：
操作1201、接收第一IAB-donor-CU发送的第一RRC重配置消息；以及
操作1202、向第一IAB-donor-CU发送RRC重配置完成消息。
其中，第一RRC重配置消息根据第二IAB-donor-CU发送给第一IAB-donor-CU的同意流量卸载的回复而生成。该第一RRC重配置消息包括为该IAB节点的DU分配的至少一个TNL地址，该TNL地址锚定在第二IAB-donor-CU的拓扑内的第二IAB-donor-DU。
第一RRC重配置消息的bap配置信息元素(bap-Config IE)包括用于表示为IAB节点配置的第二BAP地址的字段；或者，第一RRC重配置消息的bap配置信息元素(bap-Config IE)中的bap地址字段包括列表，该列表中的每一个条目是一个BAP地址及其关联信息。
操作1202中的RRC重配置完成(例如，RRCReconfigurationComplete)消息用于表示该IAB节点已经收到第一RRC重配置消息。此外，RRC重配置完成消息还可以进一步表明该IAB节点完成了重配置。
根据操作1201和操作1202，能够为IAB节点建立跨宿主的冗余路径。
如图12所示，该方法还包括：
操作1203、IAB节点接收第二IAB-donor-CU发送的第二RRC重配置(RRC Reconfiguration)消息；以及
操作1204、IAB节点向第二IAB-donor-CU发送重配置完成(RRCReconfigurationComplete)消息。
在操作1203中，第二RRC Reconfiguration消息包括BAP配置信息(bap-Config)，该BAP配置信息包括为该IAB节点配置的第二BAP地址。在操作1204中，重配置完成(RRCReconfigurationComplete)消息用于表示该IAB节点已经收到该第二RRC Reconfiguration消息。
如图12所示，该方法还包括：
操作1205、IAB节点将第二BAP地址与主小区组(MCG，master cell group)/辅小区组(SCG，secondary cell group)或者主节点(MN)/辅节点(SN)相关联。
例如，如果该IAB节点收到的带有第二BAP地址的所述第二RRCReconfiguration消息来自于MCG，或是通过信令无线承载1(SRB，signalling radio bearer)收到，则将第二BAP地址和MCG或者MN相关联；如果IAB节点收到的带有第二BAP地址的第二RRCReconfiguration消息来自于SCG，或是通过SRB3收到，则将该第二BAP地址和SCG或者SN相关联。
第四方面的实施例
至少针对与第一方面的实施例相同的问题，本申请第四方面的实施例提供一种发送和接收信号的方法，与第一方面的实施例的方法对应。本申请第四方面的实施例的发送和接收信号的方法应用于IAB节点的后裔节点，该后裔节点例如是图2的IAB节点4。
图13是第三方面的实施例的发送和接收信号的方法的一个示意图，如图13所示，该方法包括：
操作1301、接收第一IAB-donor-CU发送的第一RRC重配置消息；以及
操作1302、向第一IAB-donor-CU发送RRC重配置完成消息。
其中，操作1301的第一RRC重配置消息根据第二IAB-donor-CU发送给第一IAB-donor-CU的同意流量卸载的回复而生成。该第一RRC重配置消息包括为该后裔节点的DU分配的至少一个TNL地址，该TNL地址锚定在第二IAB-donor-CU的拓扑内的第二IAB-donor-DU。
其中，操作1302的RRC重配置完成(RRCReconfigurationComplete)消息用于表示该后裔节点已经收到该第一RRC重配置消息。此外，该RRC重配置完成消息还可以进一步表示该后裔节点已经完成了重配置
根据第四方面的实施例，能够为IAB节点的后裔节点建立跨宿主的冗余路径。
第五方面的实施例
本申请实施例提供一种发送和接收信号的装置。该装置应用于第一 IAB-donor-CU。该装置可以是第一IAB-donor-CU，该装置也可以是第一IAB-donor-CU的一部分单元。该装置对应于第一方面的实施例的方法。
图14是本申请实施例的发送和接收装置信号的的一示意图，如图14所示，信号的发送和接收装置1400包括第一收发单元1401，第一收发单元1401被配置为：
向第二IAB-donor-CU发送流量卸载请求；以及
接收该第二IAB-donor-CU发送的同意流量卸载的回复或拒绝流量卸载的回复。
在至少一个实施例中，第一收发单元1401还被配置为：根据同意流量卸载的回复，向IAB节点和/或该IAB节点的后裔IAB节点发送第一RRC重配置消息。
其中，该第一RRC重配置消息包括为该IAB节点和/或该IAB节点的后裔节点的DU各自分配的至少一个TNL地址，该TNL地址锚定在该第二IAB-donor-CU的拓扑内的第二IAB-donor-DU，该IAB节点与第一父节点连接，该第一父节点是该第一IAB-donor-CU的拓扑内的节点，并且，该IAB节点已经或即将与第二父节点连接，该第二父节点是该第二IAB-donor-CU的拓扑内的节点。
在至少一个实施例中，该第一RRC重配置消息的BAP配置信息元素(bap-Config IE)包括用于表示为该IAB节点配置的第二BAP地址的字段；或者，该第一RRC重配置消息的BAP配置信息元素(bap-Config IE)中的BAP地址字段包括列表，该列表中的每一个条目是一个BAP地址及其关联信息。
在至少一个实施例中，该第一收发单元还被配置为：
在被分配了新的TNL地址的情况下，将该新的TNL地址加入到该IAB节点和/或该IAB节点的后裔节点的DU与该第一IAB-donor-CU的F1-C关联中。
在至少一个实施例中，该流量卸载请求中包括为IAB节点和/或该IAB节点的后裔节点建立冗余路径的请求。
在至少一个实施例中，该第一收发单元1401还被配置为：
该第一IAB-donor-CU在从该IAB节点到该IAB节点的后裔节点之间进行BH RLC信道的配置和BAP子层的路由表的配置，用于支持第二路径的路由和BH RLC信道映射。
在至少一个实施例中，该第一收发单元1401还被配置为：
该第一IAB-donor-CU根据该同意流量卸载的回复，对该IAB节点进行BAP路由标识映射的配置。
在至少一个实施例中，该第一收发单元1401还被配置为：
该第一IAB-donor-CU通过用户设备上下文修改请求(UE CONTEXT MODIFICATION REQUEST)消息或者用户设备上下文建立请求(UE CONTEXT SETUP REQUEST)消息，将该第一IAB-donor-CU到该IAB节点和/或该IAB节点后裔节点的DU的F1-U通道从第一路径迁移(migrate)到第二路径。
在至少一个实施例中，该同意流量卸载的回复表示至少部分地接受该流量卸载请求，其中，该部分地接受该流量卸载请求是指：为某些TNL关联的F1-C，或者某些F1-U通道建立冗余路径。
在至少一个实施例中，IAB节点与第一父节点连接，并且，该IAB节点与第二父节点连接，该第一父节点是该第一IAB-donor-CU的拓扑内的节点，该第二父节点是该第二IAB-donor-CU的拓扑内的节点，该流量卸载请求被包含在流量卸载请求(TRAFFIC OFFLOAD REQUEST)消息中，该同意流量卸载的回复被包含在流量卸载请求接受(TRAFFIC OFFLOAD REQUEST ACKNOWLEDGE)消息中，该拒绝流量卸载的回复被包含在流量卸载拒绝(TRAFFIC OFFLOAD REQUEST REJECT)消息中。
在至少一个实施例中，该流量卸载请求消息包括流量卸载发起节点的用户设备在Xn接口的标识(UE XnAP ID)，和/或一个或多个F1-C的标识信息，该F1-C的标识信息用于为接入IAB节点的一个或多个F1-C建立冗余路径，该接入IAB节点包括该IAB节点和/或该IAB节点的后裔节点，或者即将成为双连接的IAB节点。
在至少一个实施例中，该流量卸载请求消息包括如下信息中的至少之一者：
流量卸载发起节点的UE XnAP ID，接入IAB节点的BAP地址，TNL地址，一个或多个F1-U通道标识信息，F1-C和/或各F1-U通道的IP报头信息(IP header information)，各F1-U通道的QoS信息。
在至少一个实施例中，在接受对于F1-C和/或F1-U通道的流量卸载请求的情况下，该流量卸载请求接受(TRAFFIC OFFLOAD REQUEST ACKNOWLEDGE)消息中包括如下信息中的至少一者：
流量卸载发起节点的UE XnAP ID，流量卸载接受节点的UE XnAP ID，该F1-C和/或F1-U通道的标识信息，为接入IAB节点的DU新分配的TNL地址，为该F1-C和/或F1-U通道配置的在双连接IAB节点和第二父节点之间的链路上的BH RLC信 道标识，第二父节点的BAP地址，该第二IAB-donor-CU控制的拓扑中的BAP路由标识，该IAB节点的第二BAP地址。
在至少一个实施例中，在拒绝对于所有F1-C和F1-U通道的流量卸载请求的情况下，该流量卸载请求拒绝(TRAFFIC OFFLOAD REQUEST REJECT)消息中包括流量卸载发起节点的UE XnAP ID。
在至少一个实施例中，IAB节点与第一父节点连接，并且，该IAB节点与第二父节点连接，该第一父节点是该第一IAB-donor-CU的拓扑内的节点，该第二父节点是该第二IAB-donor-CU的拓扑内的节点，
该第一IAB-donor-CU是主节点(MN)，该流量卸载请求的内容以及该同意流量卸载的回复或拒绝流量卸载的回复的内容被作为信息元素(IE)，被包含在XnAP的辅基站节点修改准备(S-NG-RAN node Modification Preparation)过程的消息中。
在至少一个实施例中，IAB节点与第一父节点连接，并且，该IAB节点没有与第二父节点连接，该第一父节点是该第一IAB-donor-CU的拓扑内的节点，该第二父节点是该第二IAB-donor-CU的拓扑内的节点，
该流量卸载请求的内容以及该同意流量卸载的回复或者拒绝流量卸载的回复的内容被作为信息元素(IE)，被包含在XnAP的辅基站节点添加准备(S-NG-RAN node Addition Preparation)过程的消息中。
在至少一个实施例中，该流量卸载请求被包含在该第一IAB-donor-CU向该第二IAB-donor-CU发送的添加辅节点的请求(S-NODE ADDITION REQUEST)消息中。
在至少一个实施例中，该同意流量卸载的回复被包含在该第二IAB-donor-CU向该第一IAB-donor-CU发送的SN添加请求接受(S-NODE ADDITION REQUEST ACKNOWLEDGE)消息中。
在至少一个实施例中，该拒绝流量卸载的回复被包含在该第二IAB-donor-CU向该第一IAB-donor-CU发送的SN添加请求接受(S-NODE ADDITION REQUEST ACKNOWLEDGE)消息中。
在至少一个实施例中，该第一收发单元1401还被配置为：
该第一IAB-donor-CU发送或接收冗余路径释放请求；
该第一IAB-donor-CU接收或发送冗余路径释放请求接受的消息。
在至少一个实施例中，该冗余路径释放请求包括：流量卸载发起节点的UE XnAP  ID，流量卸载接受节点的UE XnAP ID，需要释放冗余路径的F1-C关联的TNL地址，或需要释放冗余路径的F1-U通道的用户平面传输层信息(UP Transport Layer Information)。
在至少一个实施例中，该冗余路径释放请求接受包括：流量卸载发起节点的UE XnAP ID，流量卸载接受节点的UE XnAP ID。
在至少一个实施例中，在该第一IAB-donor-CU和该第二IAB-donor-CU中的MN发送冗余路径释放请求的情况下，
该冗余路径释放请求的内容和该冗余路径释放请求接受的消息的内容都被作为IE，被包含在辅基站节点修改准备(S-NG-RAN node Modification Preparation)过程中。
在至少一个实施例中，在进行IAB节点的辅基站节点释放(S-NG-RAN node Release)过程时，将SN拓扑中所有的与该IAB节点相关的冗余路径释放。
关于第一收发单元1401的详细说明，可以参考第一方面的实施例中对于方法的说明。
第六方面的实施例
本申请实施例提供一种发送和接收信号的装置。该装置应用于第二IAB-donor-CU，该装置例如可以是第二IAB-donor-CU，也可以是配置于第二IAB-donor-CU的某个或某些部件或者组件。该装置对应于第二方面的实施例的方法。
图15是第六方面的实施例中发送和接收信号的装置的一个示意图，如图15所示，该装置1500包括第二收发单元1501，第二处理单元1501被配置为：
接收第一IAB-donor-CU发送的是流量卸载请求；以及
向该第一IAB-donor-CU发送同意流量卸载的回复或者拒绝流量卸载的回复。
在至少一个实施例中，该流量卸载请求中包括为IAB节点和/或该IAB节点的后裔节点建立冗余路径的请求。
在至少一个实施例中，该第二收发单元1501还被配置为：
在IAB节点已经与第二父节点连接时，该第二IAB-donor-CU向该第二父节点发送用户设备上下文修改请求(UE CONTEXT MODIFICATION REQUEST)消息，以修改该IAB节点的移动终端(MT)的用户设备(UE)上下文，并设置至少一个承载 (bearer)，其中，该第二父节点是该第二IAB-donor-CU的拓扑内的节点。
在至少一个实施例中，该第二收发单元1501还被配置为：
在IAB节点没有与第二父节点连接时，该第二IAB-donor-CU向该第二父节点发送用户设备上下文建立请求(UE CONTEXT SETUP REQUEST)消息，以建立该IAB的MT的UE上下文，并设置至少一个承载(bearer)，
其中，该第二父节点是该第二IAB-donor-CU的拓扑内的节点。
在至少一个实施例中，该第二收发单元1501还被配置为：
该第二IAB-donor-CU向该IAB节点的移动终端(MT)发送第二重配置(RRCReconfiguration)消息，该第二RRCReconfiguration消息包括BAP配置信息(bap-Config)，该BAP配置信息包括为该IAB节点配置的第二BAP的地址。
在至少一个实施例中，该第二收发单元1501还被配置为：
该第二IAB-donor-CU针对该IAB节点和/或该IAB节点的后裔节点所需的第二路径，从该IAB节点到第二IAB-donor-DU之间进行BH RLC信道的配置和BAP子层的路由表的配置，
该第二IAB-donor-DU在该第二IAB-donor-CU的拓扑内。
在至少一个实施例中，该同意流量卸载的回复表示至少部分地接受该流量卸载请求，其中，该部分地接受该流量卸载请求是指：为某些TNL关联的F1-C，或者某些F1-U通道建立冗余路径。
在至少一个实施例中，IAB节点与第一父节点连接，并且，该IAB节点与第二父节点连接，该第一父节点是该第一IAB-donor-CU的拓扑内的节点，该第二父节点是该第二IAB-donor-CU的拓扑内的节点，
该流量卸载请求被包含在流量卸载请求消息中，该同意流量卸载的回复被包含在流量卸载请求接受(TRAFFIC OFFLOAD REQUEST ACKNOWLEDGE)消息中，该拒绝流量卸载的回复被包含在流量卸载拒绝(TRAFFIC OFFLOAD REQUEST REJECT)消息中。
在至少一个实施例中，该流量卸载请求消息包括流量卸载发起节点的用户设备在Xn接口的标识(UE XnAP ID)，和/或一个或多个F1-C的标识信息。该F1-C的标识信息用于为接入IAB节点的一个或多个F1-C建立冗余路径，该接入IAB节点包括该IAB节点和/或该IAB节点的后裔节点，或者即将成为双连接的IAB节点。
在至少一个实施例中，该流量卸载请求消息包括如下信息中的至少之一者：
流量卸载发起节点的UE XnAP ID，接入IAB节点的BAP地址，TNL地址，一个或多个F1-U通道标识信息，F1-C和/或各F1-U通道的IP报头信息(IP header information)，各F1-U通道的QoS信息。
在至少一个实施例中，在接受对于F1-C和/或F1-U通道的流量卸载请求的情况下，该流量卸载请求接受(TRAFFIC OFFLOAD REQUEST ACKNOWLEDGE)消息中包括如下信息中的至少一者：
流量卸载发起节点的UE XnAP ID，流量卸载接受节点UE XnAP ID，该F1-C和/或F1-U通道的标识信息，为接入IAB节点的DU新分配的TNL地址，为该F1-C和/或F1-U通道配置的在双连接IAB节点和第二父节点之间的链路上的BH RLC信道标识，第二父节点的BAP地址，该第二IAB-donor-CU控制的拓扑中的BAP路由标识，该IAB节点的第二BAP地址。
在至少一个实施例中，在拒绝对于所有F1-C和F1-U通道的流量卸载请求的情况下，该流量卸载请求拒绝(TRAFFIC OFFLOAD REQUEST REJECT)消息中包括流量卸载发起节点UE XnAP ID，可选地包括流量卸载拒绝节点UE XnAP ID。
在至少一个实施例中，IAB节点与第一父节点连接，并且，该IAB节点与第二父节点连接，该第一父节点是该第一IAB-donor-CU的拓扑内的节点，该第二父节点是该第二IAB-donor-CU的拓扑内的节点，
该第一IAB-donor-CU是主节点(MN)，该流量卸载请求的内容以及该同意流量卸载的回复或拒绝流量卸载的回复的内容被作为信息元素(IE)，被包含在XnAP的辅基站节点修改准备(S-NG-RAN node Modification Preparation)过程的消息中。
在至少一个实施例中，IAB节点与第一父节点连接，并且，该IAB节点没有与第二父节点连接，该第一父节点是该第一IAB-donor-CU的拓扑内的节点，该第二父节点是该第二IAB-donor-CU的拓扑内的节点，
该流量卸载请求的内容以及该同意流量卸载的回复或拒绝流量卸载的回复的内容被作为信息元素(IE)，被包含在XnAP的辅基站节点添加准备(S-NG-RAN node Addition Preparation)过程的消息中。
在至少一个实施例中，该流量卸载请求被包含在该第一IAB-donor-CU向该第二IAB-donor-CU发送的添加辅节点的请求(S-NODE ADDITION REQUEST)消息中。
在至少一个实施例中，该同意流量卸载的回复被包含在该第二IAB-donor-CU向该第一IAB-donor-CU发送的SN添加请求接受(S-NODE ADDITION REQUEST ACKNOWLEDGE)消息中。
在至少一个实施例中，该第二收发单元1501还被配置为：
该第二IAB-donor-CU接收或发送冗余路径释放请求；
该第二IAB-donor-CU发送或接收冗余路径释放请求接受的消息。
在至少一个实施例中，该冗余路径释放请求包括：流量卸载发起节点的UE XnAP ID，流量卸载接受节点的UE XnAP ID，需要释放冗余路径的F1-C关联的TNL地址，或需要释放冗余路径的F1-U通道的用户平面传输层信息(UP Transport Layer Information)。
在至少一个实施例中，在该第一IAB-donor-CU和该第二IAB-donor-CU中的MN发送冗余路径释放请求的情况下，
该冗余路径释放请求的内容和该冗余路径释放请求接受的消息的内容都被作为IE，被包含在辅基站节点修改准备(S-NG-RAN node Modification Preparation)过程中。
在至少一个实施例中，在进行IAB节点的辅基站节点释放(S-NG-RAN node Release)过程时，将SN拓扑中与该IAB节点相关的所有的冗余路径释放。
关于第二收发单元1501的详细说明，可以参考第二方面的实施例中对于方法的说明。
第七方面的实施例
本申请实施例提供一种发送和接收信号的装置。该装置应用于IAB节点，该装置例如可以是IAB节点，也可以是配置于IAB节点的某个或某些部件或者组件。该装置对应于第三方面的实施例的方法。
图16是第七方面的实施例中发送和接收信号的装置的一个示意图，如图16所示，该装置1600包括第三收发单元1601，第三收发单元1601被配置为：
接收该第一IAB-donor-CU发送的第一RRC重配置消息；以及
向该第一IAB-donor-CU发送RRC重配置完成消息。
在至少一个实施例中，该第一RRC重配置消息根据第二IAB-donor-CU发送给该 第一IAB-donor-CU的同意流量卸载的回复而生成，该第一RRC重配置消息包括为该IAB节点的DU分配的至少一个TNL地址，该TNL地址锚定在该第二IAB-donor-CU的拓扑内的第二IAB-donor-DU，其中，该RRC重配置完成(RRCReconfigurationComplete)消息用于表示该IAB节点已经收到该第一RRC重配置消息。此外，该RRC重配置完成消息还可以进一步表示该IAB节点已经完成了重配置。
在至少一个实施例中，该第三收发单元1601还被配置为：
该IAB节点接收该第二IAB-donor-CU发送的第二RRC重配置(RRC Reconfiguration)消息，该第二RRC Reconfiguration消息包括BAP配置信息(bap-Config)，该BAP配置信息包括为该IAB节点配置的第二BAP地址；以及
该IAB节点向该第二IAB-donor-CU发送重配置完成(RRCReconfigurationComplete)消息，
其中，该重配置完成(RRCReconfigurationComplete)消息用于表示该IAB节点已经收到该第二RRC Reconfiguration消息。
在至少一个实施例中，该第三收发单元1601还被配置为：
该IAB节点将该第二BAP地址与主小区组(MCG，master cell group)/辅小区组(SCG，secondary cell group)或者主节点(MN)/辅节点(SN)相关联。
在至少一个实施例中，如果该IAB节点收到的带有该第二BAP地址的该第二RRCReconfiguration消息来自于MCG，或是通过信令无线承载1(SRB，signalling radio bearer)收到，则将该第二BAP地址和MCG或者MN相关联；
如果该IAB节点收到的带有该第二BAP地址的该第二RRCReconfiguration消息来自于SCG，或是通过SRB3收到，则将该第二BAP地址和SCG或者SN相关联。
在至少一个实施例中，该第一RRC重配置消息的bap配置信息元素(bap-Config IE)包括用于表示为该IAB节点配置的第二BAP地址的字段；或者
该第一RRC重配置消息的bap配置信息元素(bap-Config IE)中的bap地址字段包括列表，该列表中的每一个条目是一个BAP地址及其关联信息。
关于第三收发单元1601的详细说明，可以参考第三方面的实施例中对于方法的说明。
第八方面的实施例
本申请实施例提供一种发送和接收信号的装置。该装置应用于IAB节点的后裔节点，该装置例如可以是该后裔节点，也可以是配置于该子后裔节点的某个或某些部件或者组件。该装置对应于第四方面的实施例的方法。
图17是第八方面的实施例中发送和接收信号的装置的一个示意图，如图17所示，该装置包括第四收发单元1701，第四收发单元1701被配置为：
接收该第一IAB-donor-CU发送的第一RRC重配置消息；以及
向该第一IAB-donor-CU发送RRC重配置完成消息。
其中，该第一RRC重配置消息根据第二IAB-donor-CU发送给该第一IAB-donor-CU的同意流量卸载的回复而生成，该第一RRC重配置消息包括为该后裔节点的DU分配的至少一个TNL地址，该TNL地址锚定在该第二IAB-donor-CU的拓扑内的第二IAB-donor-DU，其中，该RRC重配置完成(RRCReconfigurationComplete)消息用于表示该后裔节点已经收到该第一RRC重配置消息。此外，该RRC重配置完成消息还可以进一步表示该后裔节点已经完成了重配置。
关于第四收发单元1701的详细说明，可以参考第四方面的实施例中对于方法的说明。
第九方面的实施例
本申请实施例还提供一种通信***，可以参考图1，与第一方面至第八方面的实施例相同的内容不再赘述。
在一些实施例中，通信***可以包括：
第一IAB-donor-CU，其包括如第五方面的实施例所述的发送和接收信号的装置1400；
第二IAB-donor-CU，其包括如第六方面的实施例所述的发送和接收信号的装置1500；
IAB节点，其包括如第七方面的实施例所述的发送和接收信号的装置1600；以及
IAB节点的后裔节点，其包括如第八方面的实施例所述的发送和接收信号的装置1700。
其中，集成的接入和回传节点(IAB)可以包括IAB-MT功能单元和IAB-DU功能单元。其中，IAB-MT功能单元可以具有与终端设备相同的结构。IAB-DU功能单元、第一IAB-donor-CU以及第二IAB-donor-CU可以具有与网络设备相同的单元。
图18是本申请实施例的网络设备的构成示意图。如图18所示，网络设备1800可以包括：处理器1810(例如中央处理器CPU)和存储器1820；存储器1820耦合到处理器1810。其中该存储器1820可存储各种数据；此外还存储信息处理的程序1830，并且在处理器1810的控制下执行该程序1830。
例如，处理器1810可以被配置为执行程序而实现如第一方面的实施例或第二方面的实施例中由IAB-donor CU执行的方法，或者第三方面的实施例或第四方面的实施例中由IAB-DU执行的方法。
此外，如图18所示，网络设备1800还可以包括：收发机1840和天线1850等；其中，上述部件的功能与现有技术类似，此处不再赘述。值得注意的是，网络设备1800也并不是必须要包括图18中所示的所有部件；此外，网络设备1800还可以包括图18中没有示出的部件，可以参考现有技术。此外，IAB-donor-CU和IAB-donor-DU可以存在于一个节点，成为一个网络设备IAB-donor，也可以分离成两个节点，分别实现网络设备的不同功能，可以参考现有技术。
图19是本申请实施例的终端设备的示意图。如图19所示，该终端设备1900可以包括处理器1910和存储器1920；存储器1920存储有数据和程序，并耦合到处理器1910。值得注意的是，该图是示例性的；还可以使用其他类型的结构，来补充或代替该结构，以实现电信功能或其他功能。例如，处理器1910可以被配置为执行程序而实现如第三方面的实施例或第四方面的实施例中由IAB-MT执行的方法。。
如图19所示，该终端设备1900还可以包括：通信模块1930、输入单元1940、显示器1950、电源1960。其中，上述部件的功能与现有技术类似，此处不再赘述。值得注意的是，终端设备1900也并不是必须要包括图19中所示的所有部件，上述部件并不是必需的；此外，终端设备1900还可以包括图19中没有示出的部件，可以参考现有技术。
本申请实施例还提供一种计算机程序，其中当在Donor-CU中执行所述程序时，所述程序使得所述Donor CU执行第一方面或第二方面的实施例所述的方法。
本申请实施例还提供一种存储有计算机程序的存储介质，其中所述计算机程序使 得Donor-CU执行第一方面或第二方面的实施例所述的方法。
本申请实施例还提供一种计算机程序，其中当在IAB或其后裔节点中执行所述程序时，所述程序使得所述IAB或其后裔节点执行第三方面或第四方面的实施例所述的信号的发送和接收方法。
本申请实施例还提供一种存储有计算机程序的存储介质，其中所述计算机程序使得IAB或其后裔节点执行第三方面或第四方面的实施例所述的信号的发送和接收方法。
本申请以上的装置和方法可以由硬件实现，也可以由硬件结合软件实现。本申请涉及这样的计算机可读程序，当该程序被逻辑部件所执行时，能够使该逻辑部件实现上文所述的装置或构成部件，或使该逻辑部件实现上文所述的各种方法或步骤。本申请还涉及用于存储以上程序的存储介质，如硬盘、磁盘、光盘、DVD、flash存储器等。
结合本申请实施例描述的方法/装置可直接体现为硬件、由处理器执行的软件模块或二者组合。例如，图中所示的功能框图中的一个或多个和/或功能框图的一个或多个组合，既可以对应于计算机程序流程的各个软件模块，亦可以对应于各个硬件模块。这些软件模块，可以分别对应于图中所示的各个步骤。这些硬件模块例如可利用现场可编程门阵列(FPGA)将这些软件模块固化而实现。
软件模块可以位于RAM存储器、闪存、ROM存储器、EPROM存储器、EEPROM存储器、寄存器、硬盘、移动磁盘、CD-ROM或者本领域已知的任何其它形式的存储介质。可以将一种存储介质耦接至处理器，从而使处理器能够从该存储介质读取信息，且可向该存储介质写入信息；或者该存储介质可以是处理器的组成部分。处理器和存储介质可以位于ASIC中。该软件模块可以存储在移动终端的存储器中，也可以存储在可***移动终端的存储卡中。例如，若设备(如移动终端)采用的是较大容量的MEGA-SIM卡或者大容量的闪存装置，则该软件模块可存储在该MEGA-SIM卡或者大容量的闪存装置中。
针对附图中描述的功能方框中的一个或多个和/或功能方框的一个或多个组合，可以实现为用于执行本申请所描述功能的通用处理器、数字信号处理器(DSP)、专用集成电路(ASIC)、现场可编程门阵列(FPGA)或者其它可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件或者其任意适当组合。针对附图描述的功能方 框中的一个或多个和/或功能方框的一个或多个组合，还可以实现为计算设备的组合，例如，DSP和微处理器的组合、多个微处理器、与DSP通信结合的一个或多个微处理器或者任何其它这种配置。
以上结合具体的实施方式对本申请进行了描述，但本领域技术人员应该清楚，这些描述都是示例性的，并不是对本申请保护范围的限制。本领域技术人员可以根据本申请的精神和原理对本申请做出各种变型和修改，这些变型和修改也在本申请的范围内。
关于包括以上实施例的实施方式，还公开下述的附记：
第一IAB-donor-CU侧方法：
1.一种发送和接收信号的方法，应用于第一集成的接入和回传节点宿主中心单元(IAB-donor-CU)，该方法包括：
向第二IAB-donor-CU发送流量卸载请求；以及
接收所述第二IAB-donor-CU发送的同意流量卸载的回复或拒绝流量卸载的回复。
2.如附记1所述的方法，其中，所述方法还包括：
根据所述同意流量卸载的回复，向IAB节点和/或所述IAB节点的后裔IAB节点发送第一RRC重配置消息，
其中，所述第一RRC重配置消息包括为所述IAB节点和/或所述IAB节点的后裔节点的DU各自分配的至少一个TNL地址，所述TNL地址锚定在所述第二IAB-donor-CU的拓扑内的第二IAB-donor-DU，
所述IAB节点与第一父节点连接，所述第一父节点是所述第一IAB-donor-CU的拓扑内的节点，并且，所述IAB节点已经或即将与第二父节点连接，所述第二父节点是所述第二IAB-donor-CU的拓扑内的节点。
3.如附记2所述的方法，其中，
所述第一RRC重配置消息的BAP配置信息元素(bap-Config IE)包括用于表示为所述IAB节点配置的第二BAP地址的字段；或者
所述第一RRC重配置消息的BAP配置信息元素(bap-Config IE)中的BAP地址字段包括列表，所述列表中的每一个条目是一个BAP地址及其关联信息。
4.如附记2所述的方法，其中，所述方法还包括：
在被分配了新的TNL地址的情况下，将所述新的TNL地址加入到所述IAB节点 和/或所述IAB节点的后裔节点的DU与所述第一IAB-donor-CU的F1-C关联中。
5.如附记1所述的方法，其中，
所述流量卸载请求中包括为IAB节点和/或所述IAB节点的后裔节点建立冗余路径的请求。
6.如附记5所述的方法，其中，所述方法还包括：
所述第一IAB-donor-CU在从所述IAB节点到所述IAB节点的后裔节点之间进行BH RLC信道的配置和BAP子层的路由表的配置，用于支持第二路径的路由和BH RLC信道映射。
7.如附记5所述的方法，其中，所述方法还包括：
所述第一IAB-donor-CU根据所述同意流量卸载的回复，对所述IAB节点进行BAP路由标识映射的配置。
8.如附记5所述的方法，其中，所述方法还包括：
所述第一IAB-donor-CU通过用户设备上下文修改请求(UE CONTEXT MODIFICATION REQUEST)消息或者用户设备上下文建立请求(UE CONTEXT SETUP REQUEST)消息，将所述第一IAB-donor-CU到所述IAB节点和/或所述IAB节点后裔节点的DU的F1-U通道从第一路径迁移(migrate)到第二路径。
9.如附记1所述的方法，其中，
所述同意流量卸载的回复表示至少部分地接受所述流量卸载请求，
其中，所述部分地接受所述流量卸载请求是指：为某些TNL关联的F1-C，或者某些F1-U通道建立冗余路径。
10.如附记1所述的方法，其中，
IAB节点与第一父节点连接，并且，所述IAB节点与第二父节点连接，所述第一父节点是所述第一IAB-donor-CU的拓扑内的节点，所述第二父节点是所述第二IAB-donor-CU的拓扑内的节点，
所述流量卸载请求被包含在流量卸载请求(TRAFFIC OFFLOAD REQUEST)消息中，所述同意流量卸载的回复被包含在流量卸载请求接受(TRAFFIC OFFLOAD REQUEST ACKNOWLEDGE)消息中，所述拒绝流量卸载的回复被包含在流量卸载拒绝(TRAFFIC OFFLOAD REQUEST REJECT)消息中。
11.如附记10所述的方法，其中，
所述流量卸载请求消息包括如下信息中的至少之一者：
流量卸载发起节点的用户设备在Xn接口的标识(UE XnAP ID)，接入IAB节点的BAP地址，TNL地址，一个或多个F1-C标识信息，一个或多个F1-U通道标识信息，F1-C和/或各F1-U通道的IP报头信息(IP header information)，各F1-U通道的QoS信息。
12.如附记11所述的方法，其中，
在接受对于F1-C和/或F1-U通道的流量卸载请求的情况下，所述流量卸载请求接受(TRAFFIC OFFLOAD REQUEST ACKNOWLEDGE)消息中包括如下信息中的至少一者：
流量卸载发起节点的UE XnAP ID，流量卸载接受节点的UE XnAP ID，该F1-C和/或F1-U通道的标识信息，为接入IAB节点的DU新分配的TNL地址，为该F1-C和/或F1-U通道配置的在双连接IAB节点和第二父节点之间的链路上的BH RLC信道标识，第二父节点的BAP地址，所述第二IAB-donor-CU控制的拓扑中的BAP路由标识，所述IAB节点的第二BAP地址。
13.如附记11所述的方法，其中，
在拒绝对于所有F1-C和F1-U通道的流量卸载请求的情况下，所述流量卸载请求拒绝(TRAFFIC OFFLOAD REQUEST REJECT)消息中包括流量卸载发起节点的UE XnAP ID。
14.如附记1所述的方法，其中，
IAB节点与第一父节点连接，并且，所述IAB节点与第二父节点连接，所述第一父节点是所述第一IAB-donor-CU的拓扑内的节点，所述第二父节点是所述第二IAB-donor-CU的拓扑内的节点，
所述第一IAB-donor-CU是主节点(MN)，所述流量卸载请求的内容以及所述同意流量卸载的回复或拒绝流量卸载的回复的内容被作为信息元素(IE)，被包含在XnAP的辅基站节点修改准备(S-NG-RAN node Modification Preparation)过程的消息中。
15.如附记1所述的方法，其中，
IAB节点与第一父节点连接，并且，所述IAB节点没有与第二父节点连接，所述第一父节点是所述第一IAB-donor-CU的拓扑内的节点，所述第二父节点是所述第 二IAB-donor-CU的拓扑内的节点，
所述流量卸载请求的内容以及所述同意流量卸载的回复或者拒绝流量卸载的回复的内容被作为信息元素(IE)，被包含在XnAP的辅基站节点添加准备(S-NG-RAN node Addition Preparation)过程的消息中。
16.如附记15所述的方法，其中，
所述流量卸载请求被包含在所述第一IAB-donor-CU向所述第二IAB-donor-CU发送的添加辅节点的请求(S-NODE ADDITION REQUEST)消息中。
17.如附记15所述的方法，其中，
所述同意流量卸载的回复被包含在所述第二IAB-donor-CU向所述第一IAB-donor-CU发送的SN添加请求接受(S-NODE ADDITION REQUEST ACKNOWLEDGE)消息中。
18.如附记1所述的方法，其中，所述方法还包括：
所述第一IAB-donor-CU发送或接收冗余路径释放请求；
所述第一IAB-donor-CU接收或发送冗余路径释放请求接受的消息。
19.如附记18所述的方法，其中，
所述冗余路径释放请求包括：流量卸载发起节点的UE XnAP ID，流量卸载接受节点的UE XnAP ID，需要释放冗余路径的F1-C关联的TNL地址，或需要释放冗余路径的F1-U通道的用户平面传输层信息(UP Transport Layer Information)。
20.如附记18所述的方法，其中，
在所述第一IAB-donor-CU和所述第二IAB-donor-CU中的MN发送冗余路径释放请求的情况下，
所述冗余路径释放请求的内容和所述冗余路径释放请求接受的消息的内容都被作为IE，被包含在辅基站节点修改准备(S-NG-RAN node Modification Preparation)过程中。
21.如附记1所述的方法，其中，
在进行IAB节点的辅基站节点释放(S-NG-RAN node Release)过程时，将SN拓扑中所有的与所述IAB节点相关的冗余路径释放。
第二IAB-donor-CU侧方法：
1.一种发送和接收信号的方法，应用于第二集成的接入和回传节点宿主中心单元(IAB-donor-CU)，该方法包括：
接收第一IAB-donor-CU发送的是流量卸载请求；以及
向所述第一IAB-donor-CU发送同意流量卸载的回复或者拒绝流量卸载的回复。
2.如附记1所述的方法，其中，
所述流量卸载请求中包括为IAB节点和/或所述IAB节点的后裔节点建立冗余路径的请求。
3.如附记1所述的方法，其中，所述方法还包括：
在IAB节点已经与第二父节点连接时，所述第二IAB-donor-CU向所述第二父节点发送用户设备上下文修改请求(UE CONTEXT MODIFICATION REQUEST)消息，以修改所述IAB节点的移动终端(MT)的用户设备(UE)上下文，并设置至少一个承载(bearer)，
其中，所述第二父节点是所述第二IAB-donor-CU的拓扑内的节点。
4.如附记1所述的方法，其中，所述方法还包括：
在IAB节点没有与第二父节点连接时，所述第二IAB-donor-CU向所述第二父节点发送用户设备上下文建立请求(UE CONTEXT SETUP REQUEST)消息，以建立所述IAB的MT的UE上下文，并设置至少一个承载(bearer)，
其中，所述第二父节点是所述第二IAB-donor-CU的拓扑内的节点。
5.如附记3或4所述的方法，其中，所述方法还包括：
所述第二IAB-donor-CU向所述IAB节点的移动终端(MT)发送第二重配置(RRCReconfiguration)消息，所述第二RRCReconfiguration消息包括BAP配置信息(bap-Config)，所述BAP配置信息包括为所述IAB节点配置的第二BAP的地址。
6.如附记3或4所述的方法，其中，所述方法还包括：
所述第二IAB-donor-CU针对所述IAB节点和/或所述IAB节点的后裔节点所需的第二路径，从所述IAB节点到第二IAB-donor-DU之间进行BH RLC信道的配置和BAP子层的路由表的配置，
所述第二IAB-donor-DU在所述第二IAB-donor-CU的拓扑内。
7.如附记1所述的方法，其中，
所述同意流量卸载的回复表示至少部分地接受所述流量卸载请求，
其中，所述部分地接受所述流量卸载请求是指：为某些TNL关联的F1-C，或者某些F1-U通道建立冗余路径。
8.如附记1所述的方法，其中，
IAB节点与第一父节点连接，并且，所述IAB节点与第二父节点连接，所述第一父节点是所述第一IAB-donor-CU的拓扑内的节点，所述第二父节点是所述第二IAB-donor-CU的拓扑内的节点，
所述流量卸载请求被包含在流量卸载请求消息中，所述同意流量卸载的回复被包含在流量卸载请求接受(TRAFFIC OFFLOAD REQUEST ACKNOWLEDGE)消息中，所述拒绝流量卸载的回复被包含在流量卸载拒绝(TRAFFIC OFFLOAD REQUEST REJECT)消息中。
9.如附记8所述的方法，其中，
所述流量卸载请求消息包括如下信息中的至少之一者：
流量卸载发起节点的用户设备在Xn接口的标识(UE XnAP ID)，接入IAB节点的BAP地址，TNL地址，一个或多个F1-C标识信息，一个或多个F1-U通道标识信息，F1-C和/或各F1-U通道的IP报头信息(IP header information)，各F1-U通道的QoS信息。
10.如附记9所述的方法，其中，
在接受对于F1-C和/或F1-U通道的流量卸载请求的情况下，所述流量卸载请求接受(TRAFFIC OFFLOAD REQUEST ACKNOWLEDGE)消息中包括如下信息中的至少一者：
流量卸载发起节点的UE XnAP ID，流量卸载接受节点UE XnAP ID，该F1-C和/或F1-U通道的标识信息，为接入IAB节点的DU新分配的TNL地址，为该F1-C和/或F1-U通道配置的在双连接IAB节点和第二父节点之间的链路上的BH RLC信道标识，第二父节点的BAP地址，所述第二IAB-donor-CU控制的拓扑中的BAP路由标识，所述IAB节点的第二BAP地址。
11.如附记9所述的方法，其中，
在拒绝对于所有F1-C和F1-U通道的流量卸载请求的情况下，所述流量卸载请求拒绝(TRAFFIC OFFLOAD REQUEST REJECT)消息中包括流量卸载发起节点UE XnAP ID。
12.如附记1所述的方法，其中，
IAB节点与第一父节点连接，并且，所述IAB节点与第二父节点连接，所述第一父节点是所述第一IAB-donor-CU的拓扑内的节点，所述第二父节点是所述第二IAB-donor-CU的拓扑内的节点，
所述第一IAB-donor-CU是主节点(MN)，所述流量卸载请求的内容以及所述同意流量卸载的回复或拒绝流量卸载的回复的内容被作为信息元素(IE)，被包含在XnAP的辅基站节点修改准备(S-NG-RAN node Modification Preparation)过程的消息中。
13.如附记1所述的方法，其中，
IAB节点与第一父节点连接，并且，所述IAB节点没有与第二父节点连接，所述第一父节点是所述第一IAB-donor-CU的拓扑内的节点，所述第二父节点是所述第二IAB-donor-CU的拓扑内的节点，
所述流量卸载请求的内容以及所述同意流量卸载的回复或拒绝流量卸载的回复的内容被作为信息元素(IE)，被包含在XnAP的辅基站节点添加准备(S-NG-RAN node Addition Preparation)过程的消息中。
14.如附记13所述的方法，其中，
所述流量卸载请求被包含在所述第一IAB-donor-CU向所述第二IAB-donor-CU发送的添加辅节点的请求(S-NODE ADDITION REQUEST)消息中。
15.如附记13所述的方法，其中，
所述同意流量卸载的回复被包含在所述第二IAB-donor-CU向所述第一IAB-donor-CU发送的SN添加请求接受(S-NODE ADDITION REQUEST ACKNOWLEDGE)消息中。
16.如附记1所述的方法，其中，所述方法还包括：
所述第二IAB-donor-CU接收或发送冗余路径释放请求；
所述第二IAB-donor-CU发送或接收冗余路径释放请求接受的消息。
17.如附记16所述的方法，其中，
所述冗余路径释放请求包括：流量卸载发起节点的UE XnAP ID，流量卸载接受节点的UE XnAP ID，需要释放冗余路径的F1-C关联的TNL地址，或需要释放冗余路径的F1-U通道的用户平面传输层信息(UP Transport Layer Information)。
18.如附记16所述的方法，其中，
在所述第一IAB-donor-CU和所述第二IAB-donor-CU中的MN发送冗余路径释放请求的情况下，
所述冗余路径释放请求的内容和所述冗余路径释放请求接受的消息的内容都被作为IE，被包含在辅基站节点修改准备(S-NG-RAN node Modification Preparation)过程中。
19.如附记1所述的方法，其中，在进行IAB节点的辅基站节点释放(S-NG-RAN node Release)过程时，将SN拓扑中与所述IAB节点相关的所有的冗余路径释放。
双连接IAB节点侧方法：
1.一种发送和接收信号的方法，应用于IAB节点，所述IAB节点与第一父节点连接，并且，所述IAB节点已经或即将与第二父节点连接，所述第一父节点是第一IAB-donor-CU的拓扑内的节点，所述第二父节点是第二IAB-donor-CU的拓扑内的节点，
所述方法包括：
接收所述第一IAB-donor-CU发送的第一RRC重配置消息；以及
向所述第一IAB-donor-CU发送RRC重配置完成消息，
其中，所述第一RRC重配置消息根据第二IAB-donor-CU发送给所述第一IAB-donor-CU的同意流量卸载的回复而生成，
所述第一RRC重配置消息包括为所述IAB节点的DU分配的至少一个TNL地址，所述TNL地址锚定在所述第二IAB-donor-CU的拓扑内的第二IAB-donor-DU，
其中，所述RRC重配置完成(RRCReconfigurationComplete)消息用于表示所述IAB节点已经收到所述第一RRC重配置消息。
2.如附记1所述的方法，其中，所述方法还包括：
所述IAB节点接收所述第二IAB-donor-CU发送的第二RRC重配置(RRC Reconfiguration)消息，所述第二RRC Reconfiguration消息包括BAP配置信息(bap-Config)，所述BAP配置信息包括为所述IAB节点配置的第二BAP地址；以及
所述IAB节点向所述第二IAB-donor-CU发送重配置完成(RRCReconfigurationComplete)消息，
其中，所述重配置完成(RRCReconfigurationComplete)消息用于表示所述IAB节点已经收到所述第二RRC Reconfiguration消息。
3.如附记2所述的方法，其中，所述方法还包括：
所述IAB节点将所述第二BAP地址与主小区组(MCG，master cell group)/辅小区组(SCG，secondary cell group)或者主节点(MN)/辅节点(SN)相关联。
4.如附记3所述的方法，其中，
如果所述IAB节点收到的带有所述第二BAP地址的所述第二RRCReconfiguration消息来自于MCG，或是通过信令无线承载1(SRB，signalling radio bearer)收到，则将所述第二BAP地址和MCG或者MN相关联；
如果所述IAB节点收到的带有所述第二BAP地址的所述第二RRCReconfiguration消息来自于SCG，或是通过SRB3收到，则将所述第二BAP地址和SCG或者SN相关联。
5.如附记1所述的方法，其中，
所述第一RRC重配置消息的bap配置信息元素(bap-Config IE)包括用于表示为所述IAB节点配置的第二BAP地址的字段；或者
所述第一RRC重配置消息的bap配置信息元素(bap-Config IE)中的bap地址字段包括列表，所述列表中的每一个条目是一个BAP地址及其关联信息。
后裔节点侧方法：
1.一种发送和接收信号的方法，应用于IAB节点的后裔节点，所述IAB节点与第一父节点连接，并且，所述IAB节点已经或即将与第二父节点连接，所述第一父节点是第一IAB-donor-CU的拓扑内的节点，所述第二父节点是第二IAB-donor-CU的拓扑内的节点，
所述方法包括：
接收所述第一IAB-donor-CU发送的第一RRC重配置消息；以及
向所述第一IAB-donor-CU发送RRC重配置完成消息，
其中，所述第一RRC重配置消息根据第二IAB-donor-CU发送给所述第一IAB-donor-CU的同意流量卸载的回复而生成，
所述第一RRC重配置消息包括为所述后裔节点的DU分配的至少一个TNL地址， 所述TNL地址锚定在所述第二IAB-donor-CU的拓扑内的第二IAB-donor-DU，
其中，所述RRC重配置完成(RRCReconfigurationComplete)消息用于表示所述后裔节点已经收到所述第一RRC重配置消息。

Claims (20)

  1. 一种发送和接收信号的装置，应用于第一集成的接入和回传节点宿主中心单元(IAB-donor-CU)，该装置包括第一收发单元，其被配置为：
    向第二IAB-donor-CU发送流量卸载请求；以及
    接收所述第二IAB-donor-CU发送的同意流量卸载的回复或拒绝流量卸载的回复。
  2. 如权利要求1所述的装置，其中，所述第一收发单元还被配置为：
    根据所述同意流量卸载的回复，向IAB节点和/或所述IAB节点的后裔IAB节点发送第一RRC重配置消息，
    其中，所述第一RRC重配置消息包括为所述IAB节点和/或所述IAB节点的后裔节点的DU各自分配的至少一个TNL地址，所述TNL地址锚定在所述第二IAB-donor-CU的拓扑内的第二IAB-donor-DU，
    所述IAB节点与第一父节点连接，所述第一父节点是所述第一IAB-donor-CU的拓扑内的节点，并且，所述IAB节点已经或即将与第二父节点连接，所述第二父节点是所述第二IAB-donor-CU的拓扑内的节点。
  3. 如权利要求2所述的装置，其中，
    所述第一RRC重配置消息的BAP配置信息元素(bap-Config IE)包括用于表示为所述IAB节点配置的第二BAP地址的字段；或者
    所述第一RRC重配置消息的BAP配置信息元素(bap-Config IE)中的BAP地址字段包括列表，所述列表中的每一个条目是一个BAP地址及其关联信息。
  4. 如权利要求1所述的装置，其中，
    所述流量卸载请求中包括为IAB节点和/或所述IAB节点的后裔节点建立冗余路径的请求。
  5. 如权利要求4所述的装置，其中，所述第一收发单元还被配置为：
    所述第一IAB-donor-CU根据所述同意流量卸载的回复，对所述IAB节点进行BAP路由标识映射的配置。
  6. 如权利要求1所述的装置，其中，
    所述同意流量卸载的回复表示至少部分地接受所述流量卸载请求，
    其中，所述部分地接受所述流量卸载请求是指：为某些TNL关联的F1-C，或者某些F1-U通道建立冗余路径。
  7. 如权利要求1所述的装置，其中，
    IAB节点与第一父节点连接，并且，所述IAB节点与第二父节点连接，所述第一父节点是所述第一IAB-donor-CU的拓扑内的节点，所述第二父节点是所述第二IAB-donor-CU的拓扑内的节点，
    所述流量卸载请求被包含在流量卸载请求(TRAFFIC OFFLOAD REQUEST)消息中，所述同意流量卸载的回复被包含在流量卸载请求接受(TRAFFIC OFFLOAD REQUEST ACKNOWLEDGE)消息中，所述拒绝流量卸载的回复被包含在流量卸载拒绝(TRAFFIC OFFLOAD REQUEST REJECT)消息中。
  8. 如权利要求7所述的装置，其中，
    所述流量卸载请求消息包括如下信息中的至少之一者：
    流量卸载发起节点的用户设备在Xn接口的标识(UE XnAP ID)，接入IAB节点的BAP地址，TNL地址，一个或多个F1-C标识信息，一个或多个F1-U通道标识信息，F1-C和/或各F1-U通道的IP报头信息(IP header information)，各F1-U通道的QoS信息。
  9. 如权利要求8所述的装置，其中，
    在接受对于F1-C和/或F1-U通道的流量卸载请求的情况下，所述流量卸载请求接受(TRAFFIC OFFLOAD REQUEST ACKNOWLEDGE)消息中包括如下信息中的至少一者：
    流量卸载发起节点的UE XnAP ID，流量卸载接受节点的UE XnAP ID，该F1-C和/或F1-U通道的标识信息，为接入IAB节点的DU新分配的TNL地址，为该F1-C和/或F1-U通道配置的在双连接IAB节点和第二父节点之间的链路上的BH RLC信道标识，第二父节点的BAP地址，所述第二IAB-donor-CU控制的拓扑中的BAP路由标识，所述IAB节点的第二BAP地址。
  10. 如权利要求8所述的装置，其中，
    在拒绝对于所有F1-C和F1-U通道的流量卸载请求的情况下，所述流量卸载请求拒绝(TRAFFIC OFFLOAD REQUEST REJECT)消息中包括流量卸载发起节点的UE XnAP ID。
  11. 如权利要求1所述的装置，其中，
    IAB节点与第一父节点连接，并且，所述IAB节点没有与第二父节点连接，所述第一父节点是所述第一IAB-donor-CU的拓扑内的节点，所述第二父节点是所述第二IAB-donor-CU的拓扑内的节点，
    所述流量卸载请求的内容以及所述同意流量卸载的回复或者拒绝流量卸载的回复的内容被作为信息元素(IE)，被包含在XnAP的辅基站节点添加准备(S-NG-RAN node Addition Preparation)过程的消息中。
  12. 如权利要求1所述的装置，其中，所述第一收发单元还被配置为：
    所述第一IAB-donor-CU发送或接收冗余路径释放请求；
    所述第一IAB-donor-CU接收或发送冗余路径释放请求接受的消息。
  13. 如权利要求12所述的装置，其中，
    所述冗余路径释放请求包括：流量卸载发起节点的UE XnAP ID，流量卸载接受节点的UE XnAP ID，需要释放冗余路径的F1-C关联的TNL地址，或需要释放冗余路径的F1-U通道的上行传输层信息(UP Transport Layer Information)。
  14. 如权利要求1所述的装置，其中，
    在进行IAB节点的辅基站节点释放(S-NG-RAN node Release)过程时，将SN拓扑中所有的与所述IAB节点相关的冗余路径释放。
  15. 一种发送和接收信号的装置，应用于第二集成的接入和回传节点宿主中心单元(IAB-donor-CU)，该装置包括第二收发单元，所述第二收发单元被配置为：
    接收第一IAB-donor-CU发送的是流量卸载请求；以及
    向所述第一IAB-donor-CU发送同意流量卸载的回复或者拒绝流量卸载的回复。
  16. 如权利要求15所述的装置，其中，
    所述流量卸载请求中包括为IAB节点和/或所述IAB节点的后裔节点建立冗余路径的请求。
  17. 一种发送和接收信号的装置，应用于IAB节点，所述IAB节点与第一父节点连接，并且，所述IAB节点已经或即将与第二父节点连接，所述第一父节点是第一IAB-donor-CU的拓扑内的节点，所述第二父节点是第二IAB-donor-CU的拓扑内的节点，
    所述装置包括，第三收发单元，所述第三收发单元被配置为：
    接收所述第一IAB-donor-CU发送的第一RRC重配置消息；以及
    向所述第一IAB-donor-CU发送RRC重配置完成消息，
    其中，所述第一RRC重配置消息根据第二IAB-donor-CU发送给所述第一IAB-donor-CU的同意流量卸载的回复而生成，
    所述第一RRC重配置消息包括为所述IAB节点的DU分配的至少一个TNL地址，所述TNL地址锚定在所述第二IAB-donor-CU的拓扑内的第二IAB-donor-DU，
    其中，所述RRC重配置完成(RRCReconfigurationComplete)消息用于表示所述IAB节点已经收到所述第一RRC重配置消息并完成了重配置。
  18. 如权利要求17所述的装置，其中，所述第三收发单元还被配置为：
    所述IAB节点接收所述第二IAB-donor-CU发送的第二RRC重配置(RRC Reconfiguration)消息，所述第二RRC Reconfiguration消息包括BAP配置信息(bap-Config)，所述BAP配置信息包括为所述IAB节点配置的第二BAP地址；以及
    所述IAB节点向所述第二IAB-donor-CU发送重配置完成(RRCReconfigurationComplete)消息，
    其中，所述重配置完成(RRCReconfigurationComplete)消息用于表示所述IAB节点已经收到所述第二RRC Reconfiguration消息。
  19. 如权利要求18所述的装置，其中，所述第三收发单元还被配置为：
    所述IAB节点将所述第二BAP地址与主小区组(MCG，master cell group)/辅小区组(SCG，secondary cell group)或者主节点(MN)/辅节点(SN)相关联。
  20. 如权利要求19所述的装置，其中，
    如果所述IAB节点收到的带有所述第二BAP地址的所述第二RRCReconfiguration消息来自于MCG，或是通过信令无线承载1(SRB，signalling radio bearer)收到，则将所述第二BAP地址和MCG或者MN相关联；
    如果所述IAB节点收到的带有所述第二BAP地址的所述第二RRCReconfiguration消息来自于SCG，或是通过SRB3收到，则将所述第二BAP地址和SCG或者SN相关联。
PCT/CN2021/092913 2021-05-10 2021-05-10 发送和接收信号的方法、装置和通信*** WO2022236644A1 (zh)

Priority Applications (6)

Application Number Priority Date Filing Date Title
CN202180097986.7A CN117280745A (zh) 2021-05-10 2021-05-10 发送和接收信号的方法、装置和通信***
EP21941220.2A EP4340444A4 (en) 2021-05-10 2021-05-10 SIGNAL SENDING AND RECEIVING METHOD, SIGNAL SENDING AND RECEIVING APPARATUS, AND COMMUNICATION SYSTEM
JP2023569597A JP2024517469A (ja) 2021-05-10 2021-05-10 信号の送受信方法、装置及び通信システム
PCT/CN2021/092913 WO2022236644A1 (zh) 2021-05-10 2021-05-10 发送和接收信号的方法、装置和通信***
KR1020237038595A KR20230169245A (ko) 2021-05-10 2021-05-10 신호를 송신 및 수신하기 위한 방법, 신호를 송신 및 수신하기 위한 장치, 및 통신 시스템
US18/385,929 US20240064572A1 (en) 2021-05-10 2023-11-01 Method and apparatus for transmitting and receiving signal and communication system

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/CN2021/092913 WO2022236644A1 (zh) 2021-05-10 2021-05-10 发送和接收信号的方法、装置和通信***

Related Child Applications (1)

Application Number Title Priority Date Filing Date
US18/385,929 Continuation US20240064572A1 (en) 2021-05-10 2023-11-01 Method and apparatus for transmitting and receiving signal and communication system

Publications (1)

Publication Number Publication Date
WO2022236644A1 true WO2022236644A1 (zh) 2022-11-17

Family

ID=84029084

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2021/092913 WO2022236644A1 (zh) 2021-05-10 2021-05-10 发送和接收信号的方法、装置和通信***

Country Status (6)

Country Link
US (1) US20240064572A1 (zh)
EP (1) EP4340444A4 (zh)
JP (1) JP2024517469A (zh)
KR (1) KR20230169245A (zh)
CN (1) CN117280745A (zh)
WO (1) WO2022236644A1 (zh)

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20170006499A1 (en) * 2015-06-30 2017-01-05 Qualcomm Incorporated Traffic flow migration in backhaul networks
WO2020031004A1 (en) * 2018-08-08 2020-02-13 Telefonaktiebolaget Lm Ericsson (Publ) Flow control for integrated access backhaul (iab) networks
CN112088544A (zh) * 2018-06-21 2020-12-15 谷歌有限责任公司 通过施主基站切换来维持通信和信令接口

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20170006499A1 (en) * 2015-06-30 2017-01-05 Qualcomm Incorporated Traffic flow migration in backhaul networks
CN112088544A (zh) * 2018-06-21 2020-12-15 谷歌有限责任公司 通过施主基站切换来维持通信和信令接口
WO2020031004A1 (en) * 2018-08-08 2020-02-13 Telefonaktiebolaget Lm Ericsson (Publ) Flow control for integrated access backhaul (iab) networks

Non-Patent Citations (3)

* Cited by examiner, † Cited by third party
Title
FUJITSU: "Discussion on inter-donor topology redundancy", 3GPP DRAFT; R3-212048, 3RD GENERATION PARTNERSHIP PROJECT (3GPP), MOBILE COMPETENCE CENTRE ; 650, ROUTE DES LUCIOLES ; F-06921 SOPHIA-ANTIPOLIS CEDEX ; FRANCE, vol. RAN WG3, no. Online; 20210517 - 20210527, 7 May 2021 (2021-05-07), Mobile Competence Centre ; 650, route des Lucioles ; F-06921 Sophia-Antipolis Cedex ; France , XP052002289 *
HUAWEI: "Inter-CU topology redundancy", 3GPP DRAFT; R3-212415, 3RD GENERATION PARTNERSHIP PROJECT (3GPP), MOBILE COMPETENCE CENTRE ; 650, ROUTE DES LUCIOLES ; F-06921 SOPHIA-ANTIPOLIS CEDEX ; FRANCE, vol. RAN WG3, no. Online; 20210517 - 20210527, 7 May 2021 (2021-05-07), Mobile Competence Centre ; 650, route des Lucioles ; F-06921 Sophia-Antipolis Cedex ; France , XP052002459 *
See also references of EP4340444A4 *

Also Published As

Publication number Publication date
KR20230169245A (ko) 2023-12-15
EP4340444A4 (en) 2024-06-12
CN117280745A (zh) 2023-12-22
EP4340444A1 (en) 2024-03-20
US20240064572A1 (en) 2024-02-22
JP2024517469A (ja) 2024-04-22

Similar Documents

Publication Publication Date Title
JP7036268B2 (ja) ターゲット無線アクセスネットワークノード、５ｇコアネットワークノード、及びこれらの方法
US11546811B2 (en) Method for establishing a fronthaul interface, method for performing access for a UE, method and apparatus for performing a handover for a UE, data forwarding method, user equipment and base station
JP6904419B2 (ja) 無線アクセスネットワークノード、コアネットワークノード、及び無線端末並びにこれらの方法
JP6969620B2 (ja) ターゲットｒａｎノード、５ｇコアネットワーク装置、及びこれらの方法
CN110383895B (zh) 在切换过程期间获取按需***信息的方法
CN116438835A (zh) 用于施主间移动的方法和装置
US20230180090A1 (en) Communication method and apparatus
CN115699816A (zh) 用于在双连接下进行侧行链路中继通信的方法
WO2024031289A1 (zh) 网络节点的通信方法、移动节点的通信方法、移动节点和宿主设备
WO2022151298A1 (zh) 群组迁移方法、装置和***
WO2022082690A1 (zh) 群组切换的方法、装置和***
WO2022236644A1 (zh) 发送和接收信号的方法、装置和通信***
WO2019214384A1 (zh) 一种通信方法及装置
WO2023150975A1 (zh) Iab宿主设备以及传输迁移回退方法
WO2023150976A1 (zh) Iab宿主设备以及传输迁移管理方法
WO2023010364A1 (zh) 集成的接入和回传的通信装置以及方法
WO2023130231A1 (zh) Iab节点设备、iab宿主设备以及拓扑退行方法
WO2023150974A1 (zh) Iab宿主设备以及传输迁移管理方法
WO2023130232A1 (zh) Iab节点设备、iab宿主设备以及路径迁移方法
WO2023197184A1 (zh) Iab宿主设备以及传输地址配置方法
WO2023184542A1 (zh) 配置信息的方法、装置和通信***
WO2024026803A1 (zh) 移动节点的配置方法和宿主设备
WO2022205326A1 (en) Integrated access and backhaul donor migration methods and systems
WO2023197105A1 (zh) 配置信息的方法、装置和通信***
WO2023197185A1 (zh) Iab节点设备、iab宿主设备以及传输地址确定方法

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 21941220

Country of ref document: EP

Kind code of ref document: A1

ENP Entry into the national phase

Ref document number: 20237038595

Country of ref document: KR

Kind code of ref document: A

WWE Wipo information: entry into national phase

Ref document number: 202180097986.7

Country of ref document: CN

Ref document number: 2023569597

Country of ref document: JP

Ref document number: 1020237038595

Country of ref document: KR

WWE Wipo information: entry into national phase

Ref document number: 2021941220

Country of ref document: EP

NENP Non-entry into the national phase

Ref country code: DE

ENP Entry into the national phase

Ref document number: 2021941220

Country of ref document: EP

Effective date: 20231211