Method for communication between distributed units (DU) and related device

Abstract

A method for communication between distributed units (DUs) and a related device are provided. The method includes: a first DU receives data of a terminal from a centralized unit (CU). The first DU processes the data using a media access control (MAC) entity scheduling function specific to the terminal to obtain a physical layer transmission data stream. The first DU transmits the physical layer transmission data stream to a second DU. In the method provided in the present application, since the MAC entity of the first DU is used to uniformly schedule the physical layer transmission data stream, the first DU and the second DU do not need to exchange a large amount of layer 2 (L2) parameter information, and as a result, the information transmission overhead can be reduced.

Description

[Technical Field]

[0001] This application claims priority to Chinese Patent Application No. 202210428325.4, entitled "INTER-DISTRIBUTED-UNIT DU COMMUNICATION METHOD AND RELATED APPARATUS," filed with the State Intellectual Property Administration of China on April 22, 2022, the entire contents of which are incorporated herein by reference.

[0002] The embodiments of the present application relate to the field of wireless communication, and in particular to a method and related device for communication between distributed units (DUs). [Background technology]

[0003] Release-16, the 5th generation mobile communication technology (5G) new radio (NR) standard released by the Third Generation Partnership Project (3GPP®), introduces a centralized unit (CU) and distributed unit (DU) split architecture to the 5G gNodeB (gNodeB, gNB). In other words, a gNB includes one gNB-CU and one or more gNB-DUs. Based on this split architecture, functions for high latency requirements, such as scheduling and fast retransmission, are implemented in the DU, while functions for low latency requirements are implemented in a centralized manner in the CU. Currently, 3GPP is discussing standardization work on inter-gNB / gNB-DU coordination, where cooperating base stations may be logical gNB-DU entities. Inter-base station coordination may be applied to application scenarios including carrier aggregation (CA) and multi-TRP (Transmission Reception Point) transmission.

[0004] The purpose of introducing CA in 5G is to meet the requirements for high data transmission rates in some application scenarios (e.g., enhanced mobile broadband (eMBB)). The principle of CA is to aggregate the bandwidths of multiple cells used by the same user equipment (UE). After aggregating multiple component carriers (CCs), the UE can use the sum of the bandwidths of the multiple carriers, and the UE's peak rate can be increased approximately proportionally. Carrier aggregation can be applied in scenarios involving cells serving multiple DUs. In this application scenario, a master DU (mDU) steers service data units (SDUs) or data packets arriving at the radio link control (RLC) layer or media access control (MAC) layer to secondary DUs (sDUs).

[0005] The purpose of introducing TRPs into 5G is to reduce the impact of obstructions on the propagation of gNB high-frequency signals. In high-frequency scenarios, multiple physically separated antennas or multiple antenna panels on the same antenna are used to form different spatial channels. In other words, multiple TRPs are used to form multi-TRPs, which utilize the non-correlation properties between spatial channels to maximize spatial diversity beamforming gain or reliability gain, thereby providing better downlink transmission coverage, better reliability, or better data rates.

[0006] TRPs can be deployed on different DUs to form inter-DU multi-TRP transmissions and can be controlled by a physical layer entity and a MAC layer entity. In the current inter-DU cooperative transmission scheme, different DUs each need to configure a separate RLC entity or MAC entity for the UE. Furthermore, a large amount of Layer 2 (Layer 2 may include the RLC layer and the MAC layer) parameter information is exchanged between the cooperative DUs, such as Layer 2 context, configuration, and intermediate state variables. For example, intermediate state variables include timers, correspondence between hybrid automatic repeat request (HARQ) processes and PDCP entities, RLC entities, or higher layer entities, and data transmission variables of HARQ processes. Data transmission variables of HARQ processes include parameters such as data packet acknowledgment status, maximum transmission or reception state variables, transmission or reception state variables, and transmission windows. It can be observed that the existing architecture configuration is complex and has high information transmission overhead. Summary of the Invention [Means for solving the problem]

[0007] The embodiments of the present application provide an inter-DU communication method and related devices to reduce information transmission overhead in a distributed unit inter-DU transmission system.

[0008] According to a first aspect, the present application provides a method for communication between distributed units (DUs). The method includes a first DU receiving data of a terminal from a central unit (CU). The first DU processes the data using a medium access control (MAC) entity scheduling function specific to the terminal to obtain a physical layer transmission data stream. The first DU then transmits the physical layer transmission data stream to a second DU. According to this method, because the MAC entity of the first DU is used to uniformly schedule the physical layer transmission data stream, the first DU and the second DU do not need to exchange a large amount of Layer 2 parameter information, thereby reducing information transmission overhead.

[0009] In relation to the first aspect, in one possible implementation, the physical layer transmission data stream is a media access control protocol data unit (MAC PDU), where the first DU processes the data using a MAC entity scheduling function specific to the terminal, and the processed data is encapsulated in the MAC PDU.

[0010] Referring to the first aspect, in one possible implementation, the first DU processing data using a medium access control MAC entity scheduling function specific to the terminal to obtain a physical layer transmission data stream includes the first DU processing data using a medium access control MAC entity scheduling function and a physical layer scheduling function for the terminal to obtain a physical layer transmission data stream, where the physical layer transmission data stream is one of a transport block TB, a code word CW, and a code block CB.

[0011] Optionally, the physical layer transmission data stream may alternatively be baseband modulation symbols generated by modulating different CWs, or may be orthogonal frequency division multiplexing (OFDM) symbols generated by combining modulation symbols to perform layer mapping and precoding / weighting, and then mapping the modulation symbols to radio resource element (RE) blocks.

[0012] Referring to the first aspect, in one possible implementation form, the method further includes the first DU transmitting physical layer transmission control information to the second DU, where the physical layer transmission control information includes one or more of: related parameter information of downlink control information (DCI), related parameter information of TB, CB, or CW, parameter information of a modulation and coding scheme (MCS), parameter information of a transmission power control (TPC), status parameter information of a transmission configuration indicator (TCI), parameter information of a precoding matrix indication (PMI), parameter information of an antenna port, related parameter information of a time-frequency position and a search space (Searchspace) of a physical downlink control channel (PDCCH) for a terminal in a control resource set (CORESET), information about a data scrambling identifier of a physical downlink shared channel (PDSCH), and information about a radio network temporary identifier (RNTI). According to this method, the second DU can determine a manner of transmitting a physical layer transmission data stream to the terminal.

[0013] Referring to the first aspect, in one possible implementation, the method further includes the first DU receiving uplink control information UCI from the second DU, where the UCI includes one or more of a buffer status report BSR, a power headroom report PHR, a timing advance TA, and a measurement reference signal measurement result.

[0014] Referring to the first aspect, in one possible implementation form, the method further includes: the first DU receiving uplink feedback information from the second DU, where the uplink feedback information includes hybrid automatic repeat request (HARQ) reception status feedback information.

[0015] Referring to the first aspect, in one possible implementation form, the method further includes: a first DU receiving instruction information from a CU, the instruction information including an identifier of the terminal, the instruction information instructing the first DU and the second DU to perform inter-DU cooperative transmission for the terminal. Optionally, the CU sends the instruction information to the first DU and the second DU via an F1 interface.

[0016] According to a second aspect, the present application provides a method for communication between distributed units (DUs). The method includes a second DU receiving a physical layer transmission data stream from a first DU. The second DU transmits the physical layer transmission data stream to a terminal. According to this method, since a MAC entity of the first DU is used to uniformly schedule the physical layer transmission data stream, the first DU and the second DU do not need to exchange a large amount of Layer 2 parameter information, and as a result, information transmission overhead can be reduced.

[0017] Referring to the second aspect, in one possible implementation, the physical layer transmission data stream is one of a media access control protocol data unit MAC PDU, a transport block TB, a codeword CW, and a code block CB.

[0018] Referring to a second aspect, in one possible implementation, the second DU prohibits enabling a terminal-specific MAC entity scheduling function. The second DU does not need to enable the terminal-specific MAC entity scheduling function, and the first DU and the second DU do not need to exchange a large amount of Layer 2 parameter information. As a result, information transmission overhead can be reduced.

[0019] Referring to a second aspect, in one possible implementation form, the method further includes: the second DU receiving physical layer transmission control information from the first DU, wherein the physical layer transmission control information includes one or more of: related parameter information of downlink control information DCI; related parameter information of TB, CB, or CW; parameter information of a modulation and coding scheme MCS; parameter information of a transmission power control TPC; status parameter information of a transmission configuration indicator TCI; parameter information of a precoding matrix indication PMI; parameter information of an antenna port; related parameter information of a time-frequency position and search space Searchspace of a physical downlink control channel PDCCH for a terminal in a control resource set CORESET; information about a data scrambling identifier of a physical downlink shared channel PDSCH; and information about a radio network temporary identifier RNTI.

[0020] Referring to the second aspect, in one possible implementation, the second DU transmitting the physical layer transmission data stream to the terminal includes the second DU determining a time-frequency position of a PDCCH corresponding to the terminal based on the time-frequency position of the PDCCH for the terminal and related parameter information of the search space in the CORESET within the physical layer transmission control information. The second DU determines a time-frequency position of a PDSCH based on related parameter information of a DCI within the physical layer transmission control information. The second DU transmits the DCI scrambled using the RNTI to the terminal via the PDCCH, where the DCI indicates the PDSCH. The second DU transmits the physical layer transmission data stream scrambled using the data scrambling identifier of the PDSCH to the terminal via the PDSCH.

[0021] Referring to a second aspect, in one possible implementation form, the method further includes: a second DU receiving uplink control information UCI from the terminal, the UCI including one or more of a buffer status report BSR, a power headroom report PHR, a timing advance TA, and a measurement reference signal measurement result; The second DU transmitting the UCI to the first DU.

[0022] Referring to a second aspect, in one possible implementation form, the method further includes: a second DU receiving uplink feedback information from the terminal, the uplink feedback information including hybrid automatic repeat request (HARQ) reception status feedback information; and the second DU transmitting the uplink feedback information to the first DU.

[0023] Referring to a second aspect, in one possible implementation form, the method further includes the second DU receiving instruction information from the CU, where the instruction information includes an identifier of the terminal, and the instruction information instructs the second DU and the first DU to perform inter-DU cooperative transmission for the terminal.

[0024] According to a third aspect, the present application provides a method for communication between distributed units (DUs). The method includes: a first DU receiving instruction information from a central unit (CU), the instruction information instructing a terminal to initiate contention-free random access to a second DU. The first DU transmits the instruction information to the terminal. The first DU receives a random access message 1 (Msg1) from the second DU. The first DU generates a random access message 2 (Msg2) based on Msg1. The first DU transmits Msg2 to the terminal. In this method, the terminal accesses the second DU in a contention-free random access manner, thereby improving the success rate of the terminal's access to the second DU.

[0025] Referring to the third aspect, in one possible implementation, the instruction information indicates a dedicated preamble to be used for contention-free random access, and Msg1 includes the dedicated preamble. Alternatively, the instruction information indicates a dedicated random access resource to be used for contention-free random access, and receiving Msg1 from the second DU by the first DU includes receiving Msg1 from the second DU using the dedicated random access resource. Alternatively, the instruction information indicates a dedicated preamble and a dedicated random access resource, and receiving Msg1 from the second DU by the first DU includes receiving Msg1 from the second DU using the dedicated random access resource, and Msg1 includes the dedicated preamble.

[0026] According to a fourth aspect, the present application provides a method for communication between distributed units (DUs). The method includes: a second DU receiving a random access message 1 (Msg1) from a terminal, where Msg1 is generated in response to instruction information, and the instruction information instructs the terminal to initiate contention-free random access to the second DU. The second DU then transmits Msg1 to the first DU. In this method, the terminal accesses the second DU in a contention-free random access manner, thereby improving the success rate of the terminal's access to the second DU.

[0027] Referring to the fourth aspect, in one possible implementation, the indication information indicates a dedicated preamble to be used for contention-free random access, and Msg1 includes the dedicated preamble. Alternatively, the indication information indicates a dedicated random access resource to be used for contention-free random access, and receiving Msg1 from the terminal by the second DU includes receiving Msg1 from the terminal using the dedicated random access resource. Alternatively, the indication information indicates a dedicated preamble and a dedicated random access resource, and receiving Msg1 from the terminal by the second DU includes receiving Msg1 from the terminal by the second DU using the dedicated random access resource, and Msg1 includes the dedicated preamble.

[0028] According to a fifth aspect, the present application provides a method for communication between distributed units (DUs). The method includes a first DU receiving a random access message 1 (Msg1) from a second DU. The first DU generates a random access message 2 (Msg2) based on Msg1. The first DU transmits Msg2 to a terminal. The first DU receives a random access message 3 (Msg3) from the second DU. The first DU transmits Msg3 to a central unit (CU). The first DU receives Msg4 from the CU. The first DU transmits Msg4 to the terminal. In the method, the terminal accesses the second DU in a contention-based random access manner.

[0029] Referring to a fifth aspect, in one possible implementation form, the method further includes: a first DU receiving, from a second DU, a random access radio network temporary identifier (RA-RNTI) value of a secondary cell, where there is a correspondence relationship between the secondary cell and the second DU; the RA-RNTI value is used to determine a time-frequency location of a first physical downlink control channel (PDCCH) for scheduling Msg2 and a time-frequency location of a first physical downlink shared channel (PDSCH) for transmitting data information of Msg2, and is used for data scrambling of the first PDCCH.

[0030] Referring to the fifth aspect, in one possible implementation, the response time window for monitoring the first PDCCH or the random access response is greater than 80 slots. In this way, a longer response time window is configured for the process in which the terminal accesses the second DU in the contention-based random access manner. In this way, the influence of non-ideal BH between DUs can be reduced, and the success rate of the terminal accessing the second DU can be increased.

[0031] Referring to the fifth aspect, in one possible implementation form, the first DU transmitting Msg2 to the terminal includes the first DU transmitting Msg2 to the terminal via the second DU.

[0032] Referring to the fifth aspect, in one possible implementation form, the first DU transmitting Msg4 to the terminal includes the first DU transmitting Msg4 to the terminal via the second DU.

[0033] Referring to the fifth aspect, in one possible implementation, the maximum duration of the timer for monitoring Msg4 is longer than the duration of 64 subframes. In this way, the longer maximum duration of the timer is configured for the process in which the terminal accesses the second DU in the contention-based random access manner. In this way, the influence of non-ideal BH between DUs can be reduced, and the success rate of the terminal accessing the second DU can be increased.

[0034] According to a sixth aspect, the present application provides a method for communication between distributed units (DUs). The method includes a second DU receiving a random access message 1 (Msg1) from a terminal. The second DU transmits Msg1 to a first DU. The second DU transmits a random access radio network temporary identifier (RA-RNTI) value of a secondary cell to the first DU, where a correspondence exists between the secondary cell and the second DU. The RA-RNTI value is used to determine a time-frequency location of a first physical downlink control channel (PDCCH) for scheduling the random access message 2 (Msg2) and a time-frequency location of a first physical downlink shared channel (PDSCH) for transmitting data information of Msg2, and is used for data scrambling of the first PDCCH. The second DU receives a random access message 3 (Msg3) from the terminal. The second DU transmits Msg3 to the first DU. In this method, the terminal accesses the second DU using contention-based random access.

[0035] In relation to the sixth aspect, in one possible implementation, the method further includes the second DU determining a time-frequency location of the first PDCCH and a time-frequency location of the first PDSCH based on the RA-RNTI value. The second DU receives Msg2 from the first DU. The second DU transmits a first DCI to the terminal via the first PDCCH, where the first DCI is scrambled based on the RA-RNTI value and indicates the time-frequency location of the first PDSCH. The second DU transmits data information of Msg2 to the terminal via the first PDSCH.

[0036] Referring to the sixth aspect, in one possible implementation, the response time window for monitoring the first PDCCH or Msg2 is greater than 80 slots. In this way, a longer response time window is configured for the process in which the terminal accesses the second DU in the contention-based random access manner. In this way, the influence of non-ideal BH between DUs can be reduced, and the success rate of the terminal accessing the second DU can be increased.

[0037] Referring to a sixth aspect, in one possible implementation, the method further includes a second DU receiving a random access message 4 (Msg4) from the first DU, where a search space of a second PDCCH for scheduling Msg4 is configured for the second DU, the second PDCCH is used to transmit second downlink control information (DCI) for scheduling the second PDSCH, and the second PDSCH is used to transmit data information for Msg4. The second DU transmits the second DCI to the terminal via the second PDCCH, where the second DCI is scrambled based on a temporary cell radio network temporary identifier (TC-RNTI), the TC-RNTI is included in Msg2, and the second DCI indicates the second PDSCH. The second DU transmits the data information for Msg4 to the terminal via the second PDSCH.

[0038] Referring to the sixth aspect, in one possible implementation, the maximum duration of the timer for monitoring the second PDCCH or Msg4 is longer than the duration of 64 subframes. In this way, the longer maximum duration of the timer is configured for the process in which the terminal accesses the second DU in the contention-based random access manner. In this way, the influence of non-ideal BH between DUs can be reduced, and the success rate of the terminal accessing the second DU can be increased.

[0039] According to a seventh aspect, the present application provides a communication device, the communication device including: a unit configured to perform the method of the first aspect and any one of its possible implementations, a unit configured to perform the method of the second aspect and any one of its possible implementations, a unit configured to perform the method of the third aspect and any one of its possible implementations, a unit configured to perform the method of the fourth aspect and any one of its possible implementations, a unit configured to perform the method of the fifth aspect and any one of its possible implementations, or a unit configured to perform the method of the sixth aspect and any one of its possible implementations.

[0040] According to an eighth aspect, the present application provides a communication device. The communication device may be the first DU or a chip disposed within the first DU in the aforementioned method design. The communication device includes a communication interface and a processor, and optionally further includes a memory. The memory is configured to store a computer program or instruction. The processor is coupled to the memory and the communication interface. When the processor executes the computer program or instruction, the communication device is enabled to execute the method performed by the first DU in the aforementioned aspect.

[0041] According to a ninth aspect, the present application provides a communication device. The communication device may be a second DU or a chip disposed within the second DU in the above-described method design. The communication device includes a communication interface and a processor, and optionally further includes a memory. The memory is configured to store a computer program or instruction. The processor is coupled to the memory and the communication interface. When the processor executes the computer program or instruction, the communication device is enabled to execute the method performed by the second DU in the above-described aspect.

[0042] The communication interface in the communication device of the eighth and ninth aspects is configured to receive a signal from another communication device other than the communication device and transmit the signal to the processor, or transmit a signal from the processor to another communication device other than the communication device. The communication interface may be a transceiver in the communication device, and may be implemented, for example, via an antenna, a feeder, a codec, etc. in the communication device. Alternatively, if the communication device is a chip disposed in the communication device, the communication interface may be an input / output interface of the chip, for example, an input / output pin.

[0043] According to a tenth aspect, there is provided a computer program product, the computer program product including computer program code that, when executed, performs the method performed by the first DU or the second DU in the aforementioned aspect.

[0044] According to an eleventh aspect, the present application provides a computer-readable storage medium storing a computer program, which, when executed, performs the method performed by the first DU or the second DU in the aforementioned aspect.

[0045] In an embodiment of the present application, the first DU receives data for the terminal from an upper layer, enables a terminal-specific MAC entity scheduling function, processes the data to obtain a physical layer transmission data stream, and then sends the physical layer transmission data stream to the second DU to form PHY layer data segmentation for the terminal. Because the MAC entity of the first DU is used to uniformly schedule the physical layer transmission data stream and the second DU does not enable the terminal-specific MAC entity scheduling function, the first DU and the second DU do not need to exchange a large amount of Layer 2 parameter information, and as a result, the information transmission overhead can be reduced. [Brief explanation of the drawings]

[0046] [Figure 1] 1 is a diagram of a network architecture of a wireless communication system according to an embodiment of the present application; [Figure 2] FIG. 1 is a diagram of an architecture of an NG-RAN according to an embodiment of the present application. [Figure 3] FIG. 1 is a diagram of the architecture of a CP / UP split gNB according to one embodiment of the present application. [Figure 4] A diagram of the distribution of air interface protocol stacks for gNB-CU and gNB-DU according to one embodiment of the present application. [Figure 5] FIG. 1 is a diagram of a control plane protocol stack when a gNB uses a CU / DU split architecture according to one embodiment of the present application. [Figure 6] FIG. 1 is a diagram of a user plane protocol stack when a gNB uses a CU / DU split architecture according to one embodiment of the present application. [Figure 7] FIG. 1 is a diagram of carrier aggregation according to an embodiment of the present application. [Figure 8] FIG. 2 is a diagram of an intra-base station CA architecture and an inter-base station CA architecture according to an embodiment of the present application. [Figure 9] FIG. 1 is a diagram of multi-TRP transmission according to an embodiment of the present application. [Figure 10]FIG. 1 is a diagram of an architecture for DU inter-cell data splitting according to an embodiment of the present application. [Figure 11] 1 is a schematic flowchart of an inter-DU communication method according to an embodiment of the present application; [Figure 12] FIG. 10 is another architecture diagram of DU inter-cell data splitting according to an embodiment of the present application; [Figure 13] 1 is a schematic flowchart of another inter-DU communication method according to an embodiment of the present application; [Figure 14] 1 is a schematic flowchart of another inter-DU communication method according to an embodiment of the present application; [Figure 15] 1 is a schematic flowchart of another inter-DU communication method according to an embodiment of the present application; [Figure 16] FIG. 1 is a diagram of an IAB network communication system according to an embodiment of the present application. [Figure 17] FIG. 2 is a diagram of a control plane protocol stack in an IAB network according to an embodiment of the present application. [Figure 18] FIG. 1 is a diagram of a user plane protocol stack in an IAB network according to an embodiment of the present application. [Figure 19] FIG. 1 is a diagram of a communication scenario according to an embodiment of the present application. [Figure 20] FIG. 2 is a diagram of a dual connectivity communication scenario according to an embodiment of the present application. [Figure 21] FIG. 1 is a diagram of a dual connectivity communication architecture in an IAB network according to an embodiment of the present application. [Figure 22] FIG. 1 is a diagram of a CP-UP split scenario in an EN DC scenario according to an embodiment of the present application. [Figure 23] FIG. 1 is a diagram of a CP-UP split scenario in an NR DC scenario according to one embodiment of the present application. [Figure 24] FIG. 1 is a diagram of an IAB network communication system using EN DC networking according to an embodiment of the present application. [Figure 25]FIG. 1 is a diagram of an IAB network communication system using NR DC networking according to one embodiment of the present application. [Figure 26] 1 is a schematic flowchart of a communication method according to an embodiment of the present application; [Figure 27] 1 is a schematic flowchart of a communication method according to an embodiment of the present application; [Figure 28] 1 is a schematic flowchart of a communication method according to an embodiment of the present application; [Figure 29] 1 is a schematic flowchart of a communication method according to an embodiment of the present application; [Figure 30] 1 is a diagram of the structure of a communication device according to an embodiment of the present application; [Figure 31] FIG. 10 is a diagram of the structure of another communication device according to an embodiment of the present application; [Figure 32] 1 is a diagram of a chip structure according to an embodiment of the present application; DETAILED DESCRIPTION OF THE INVENTION

[0047] The following describes the technical solutions in the embodiments of the present application in more detail.

[0048] The terms used in the following embodiments of this application are intended to describe particular embodiments only and are not intended to limit this application. As used in the specification and appended claims of this application, the singular terms "a," "one," "said," "above," "the," and "this" are intended to include the plural terms as well, unless the context clearly indicates otherwise. It should also be understood that the term "and / or," as used in this application, means and includes any and all possible combinations of one or more listed items. The term "plurality," as used in this application, means two or more.

[0049] It should be noted that in the specification, claims, and accompanying drawings of this application, the terms "first," "second," "third," etc. are intended to distinguish between similar objects, but do not necessarily dictate a particular order or sequence. Such terms, as used herein, are interchangeable under appropriate circumstances, and as a result, it should be understood that the embodiments of the application described herein may be performed in orders other than those illustrated or described herein. Furthermore, the term "comprising" and any variations thereof are intended to cover non-exclusive inclusions; for example, a process, method, system, product, or server that includes a list of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units that are not explicitly listed or that are inherent to the process, method, product, or device.

[0050] The embodiments of the present application may be applied to the network architecture shown in FIG. 1. The network architecture shown in FIG. 1 is a network architecture for a wireless communication system. The network architecture typically includes a terminal device, a network device, and a core network (CN) device. The number and form of the devices do not constitute limitations on the embodiments of the present application. The terminal device is wirelessly connected to a network device (also referred to as a radio access network device or an access network (AN) device), and the network device is wirelessly or wiredly connected to a core network. The core network device and the radio access network device may be different, independent physical devices. Alternatively, the functions of the core network device and the logical functions of the radio access network device may be integrated into the same physical device (the physical device may be referred to as a network device). Alternatively, some functions of the core network device and some functions of the radio access network equipment may be integrated into one physical device. FIG. 1 is merely a diagram. The communication system may further include other network devices, such as a wireless relay device or a wireless backhaul device, which are not shown in FIG. 1.

[0051] It should be noted that the wireless communication systems referred to in the embodiments of the present application include, but are not limited to, Internet of Things (IoT) systems, Long Term Evolution (LTE) systems, 5th-generation (5G) mobile communication systems, 6th-generation (6G) mobile communication systems, and future mobile communication systems. In some embodiments, the technical solutions in the embodiments of the present application may be further applied to Wireless Local Area Networks (WLANs), Vehicle-to-Everything (V2X) networks, non-terrestrial networks (NTNs), satellites and High-Altitude Platforms (HAPs), advanced Internet of Things, or other networks. In some other embodiments, the technical solutions in the embodiments of the present application may be further applied to communication-radar integrated communication systems, terahertz communication systems, communication systems with higher frequencies, etc. This is not specifically limited in the present application.

[0052] The network device in the embodiment of the present application may be a base station (BS). A base station may provide communication services to multiple terminal devices, or multiple base stations may provide communication services to the same terminal device. In the embodiment of the present application, the base station is a device deployed in a radio access network to provide wireless communication functions to terminal devices. The base station device may be a base station, a relay station, or an access point. The base station may be an eNB or an eNodeB (Evolutionary NodeB) in Long Term Evolution (LTE). The base station may be a gNodeB (gNB) in a 5G network or a radio controller in a Cloud Radio Access Network (CRAN) scenario. Alternatively, the base station may be a base station in a future 6G network or a network device in a future evolved PLMN network. Alternatively, the base station may be a wearable device, an in-vehicle device, etc. In the embodiment of the present application, the device configured to perform the functions of the network device may be a network device or a device, such as a chip system, capable of supporting the network device in performing the functions. This device may be installed in the network device.

[0053] In an embodiment of the present application, a base station may use a central unit (CU) and distributed unit (DU) split architecture. In other words, a gNB includes one gNB-CU and one or more gNB-DUs. The starting point of the CU / DU split is that functions with high latency requirements, such as scheduling and fast retransmission, can be implemented in the DU, while functions with low latency requirements can be implemented in the CU. Another advantage of the CU / DU split is that all external interfaces of the gNB, such as Xn (i.e., interfaces between neighboring gNBs), are within the CU, thereby avoiding the additional complexity of external interfaces for each DU. Furthermore, the CU / DU split supports centralized PDCP processing. This not only facilitates end-to-end security protection for communications between the UE and the CU, but also facilitates data packet processing in dual connectivity and handover scenarios. This is because traffic passing through different DUs is separated on the CU.

[0054] FIG. 2 is a diagram of the architecture of a next-generation radio access network (NG-RAN) according to one embodiment of the present application. As shown in FIG. 2, the NG-RAN includes multiple gNBs connected to 5GC. The NG-RAN may include complete gNBs or gNBs including gNB-CUs and gNB-DUs. Specifically, the gNBs are connected via Xn interfaces, the gNB-CUs and gNB-DUs are connected via F1 interfaces, and the gNB-CUs and 5GCs are connected via NG interfaces. One gNB-DU can be connected to only one gNB-CU, and one gNB-CU may be connected to multiple gNB-DUs. Note that the gNB-CUs and the gNB-DUs connected to the gNB-CUs are considered to be one gNB for the other gNBs and 5GCs.

[0055] In some embodiments, the gNB-CU may be further divided into two network units: a gNB-CU-CP and a gNB-CU-UP. Figure 3 is a diagram of the architecture of a CP / UP split gNB according to one embodiment of the present application. One gNB-DU and one gNB-CU-UP are connected to only one gNB-CU-CP. Under the control of the same gNB-CU-CP, one gNB-DU may be connected to multiple gNB-CU-UPs, and one gNB-CU-UP may be connected to multiple DUs. The gNB-DU is connected to the gNB-CU-CP and gNB-CU-UP via an F1-C interface and an F1-U interface, respectively. The gNB-CU-CP is connected to the gNB-CU-UP via an E1 interface.

[0056] In an embodiment of the present application, the network device may be a CU or a DU. Figure 4 is a diagram illustrating the distribution of air interface protocol stacks of a gNB-CU and a gNB-DU according to an embodiment of the present application. The CU performs functions of radio resource control (RRC) and packet data convergence protocol (PDCP) belonging to a base station, and may further perform functions of service data adaptation protocol (SDAP). The DU completes functions of a radio link control (RLC) layer and medium access control (MAC) layer belonging to a base station, and may further complete some or all functions of a physical layer (PHY). For a specific description of the aforementioned protocol layers, please refer to the relevant technical specifications of the 3rd generation partnership project (3GPP).

[0057] The terminal device in the embodiments of the present application may also be called a terminal, or may be a device having wireless transmission and reception capabilities. The terminal device in the embodiments of the present application may include various user equipment (UE) with wireless communication capabilities, access terminals, UE units, UE stations, mobile stations, remote stations, remote terminals, mobile devices, UE terminals, terminals, wireless communication devices, UE agents, or UE devices. The access terminal may be a cellular phone, a cordless phone, a Session Initiation Protocol (SIP) phone, a Wireless Local Loop (WLL) station, a Personal Digital Assistant (PDA), a handheld device with wireless communication capabilities, a computing device, or another processing device connected to a wireless modem, an unmanned aerial vehicle (or drone, for short), a vehicle-mounted device, a wearable device, a terminal device in a future 5G network, a terminal device in a future evolved PLMN network, etc. In the embodiments of the present application, a device configured to perform the functions of a terminal may be a terminal, or may be a device, such as a chip system, capable of supporting a terminal in performing the functions. The device may be installed in the terminal. In embodiments of this application, a chip system may include a chip, or may include a chip and other discrete components.

[0058] The embodiments of the present application may be applied to a device to device (D2D) system, a machine to machine (M2M) system, a vehicle to everything (V2X) system, and the like.

[0059] The embodiments of the present application may further be applied to next generation microwave scenarios, NR-based microwave scenarios, integrated access and backhaul (IAB) scenarios, etc.

[0060] In the embodiments of the present application, the network devices and terminal devices may be in fixed locations or may be mobile. The network devices and terminal devices may be deployed on land, including indoor devices, outdoor devices, handheld devices, or vehicle-mounted devices. The application scenarios of the network devices and terminal devices are not limited in the embodiments of the present application.

[0061] The network architectures and service scenarios described in the embodiments of the present application are intended to more clearly explain the technical solutions of the embodiments of the present application, and do not constitute limitations on the technical solutions provided in the embodiments of the present application. As those skilled in the art can see, with the evolution of network architectures and the emergence of new service scenarios, the technical solutions provided in the embodiments of the present application can also be applied to similar technical problems.

[0062] The following describes some related contents / concepts in the embodiments of the present application.

[0063] 1. Control plane (CP) protocol stack when CU / DU split architecture is used for gNB 5 is a diagram of a control plane protocol stack when a CU / DU split architecture is used for a gNB according to one embodiment of the present application. Specifically, a UE accesses a gNB-CU via a gNB-DU. In other words, the PHY, MAC, and RLC layer functions of the UE's peer layer are located on the gNB-DU, and the PDCP, SDAP, and RRC layer functions of the UE's peer layer are located on the gNB-CU.

[0064] For the control plane, in the uplink (UL) direction, the gNB-DU encapsulates an RRC message generated by a terminal (e.g., user equipment (UE)) into an F1 application protocol (F1AP) message on the F1 interface and transmits the F1 application protocol message to the gNB-CU. In the downlink (DL) direction, the gNB-CU encapsulates the RRC message into an F1AP message and transmits the F1AP message to the gNB-DU. The gNB-DU extracts the RRC message from the F1AP message, maps the RRC message to a signaling radio bearer (SRB, including SRB0, SRB1, and SRB2) corresponding to the Uu interface, and transmits the RRC message to the UE.

[0065] 2. User plane (UP) protocol stack when CU / DU split architecture is used for gNB 6 is a diagram of a user plane protocol stack when a CU / DU split architecture is used for a gNB according to one embodiment of the present application. For the user plane, in the UL direction, the gNB-DU maps UE data packets received from a data radio bearer (DRB) on the Uu interface to a corresponding tunnel identified by the general packet radio system (GPRS) tunneling protocol (GTP) and transmits the UE data packets to the gNB-CU. In the DL direction, the gNB-CU maps the UE data packets to a corresponding GTP tunnel and transmits the UE data packets to the gNB-DU. The gNB-DU extracts the UE data packets from the GTP tunnel, maps the UE data packets to a DRB corresponding to the Uu interface, and transmits the UE data packets to the UE.

[0066] 3. Carrier aggregation (CA) To meet the requirements for high data transmission rates in some application scenarios (e.g., enhanced mobile broadband (eMBB)), the concept of CA is further introduced into this field. The principle of CA is to aggregate the bandwidths of multiple cells for use by the same terminal (e.g., UE). After multiple component carriers (CCs) are aggregated, the bandwidth that can be enjoyed by the UE is the sum of the bandwidths of the multiple carriers, and the peak rate of the UE can be increased approximately proportionally. For example, in LTE, by using CA technology, two to five CCs can be aggregated together to achieve a maximum transmission bandwidth of 100 MHz, thereby effectively improving the uplink and downlink transmission rates. The terminal may determine the maximum number of carriers that can be simultaneously used for uplink and downlink transmission based on the terminal's capabilities.

[0067] 7 is a diagram of carrier aggregation according to an embodiment of the present application. A network device provides n component carriers CC1 to CCn to terminal devices, and terminal device 1 and terminal device 2 may perform uplink transmission and downlink transmission using the carriers obtained by aggregating the n component carriers.

[0068] In an embodiment of the present application, carrier aggregation may be intra-base station (inter-DU) CA. In other words, the component carriers used for aggregation are provided by the same base station for a terminal. Alternatively, carrier aggregation may be inter-base station (inter-CU) CA. In other words, the component carriers used for aggregation are provided by two or more base stations. Regarding CA classification, inter-base station CA may be intra-band CA (including intra-band contiguous CA and intra-band discontinuous CA) or inter-band CA. Inter-base station CA uses the Xn interface link for transmitting signaling and data for cooperative services between gNodeBs. CA performs data division at the RLC layer or MAC layer. Compared with data division at the PDCP layer, this is data division at the RLC layer, or data division at the MAC layer is data division at a lower layer protocol, and has higher latency requirements.

[0069] For example, Figure 8 is a diagram of an intra-base station CA architecture and an inter-base station CA architecture according to one embodiment of the present application. For example, a communication system includes a base station 1 (including CU1, DU1, and DU2), a base station 2 (including CU2, DU3, and DU4), a terminal 1 (e.g., UE1), and a terminal 2 (e.g., UE2). Signaling and data transmission of coordinated services between gNodeBs is performed between CUs via the X2 interface. The CUs and DUs are connected via the F1 interface. DU1 and DU2 provide intra-base station CA for UE1, and DU2 and DU3 provide inter-base station CA for UE2.

[0070] 4. gNB-DU multi-transmission reception point (multi-TRP) The concept of TRP is introduced into 5G to reduce the impact of signal blocking caused by obstacles when gNBs are used at high frequencies. In high-frequency scenarios, multiple physically separated antennas or multiple antenna panels on the same antenna are used to form different spatial channels. In other words, multiple transmission reception points (TRPs) are used to form multi-TRPs, which utilize the non-correlation property between spatial channels to maximize the beamforming gain or reliability gain of spatial diversity, providing better coverage, reliability, or data rates for the physical downlink shared channel (PDSCH).

[0071] 9 is a diagram of multi-TRP transmission according to one embodiment of the present application. For example, a communication system includes a base station 1, a base station 2, and a terminal 1 (e.g., UE1). Base station 1 includes two TRPs, namely, TRP1 and TRP2, and base station 2 includes one TRP, namely, TRP3. TRP1, TRP2, and TRP3 form a multi-TRP system to provide communication services to UE1, so that the coverage and transmission reliability of the PDSCH can be enhanced.

[0072] Generally, there are two multi-TRP operation modes: single downlink control information (DCI) and multi-DCI. For both modes, uplink and downlink operations are controlled by the physical and MAC layers. In single DCI mode, the same DCI is used to schedule a UE on two TRPs. In multi-DCI mode, different DCIs are used to schedule a UE on two TRPs.

[0073] In multi-TRP transmission, the transmission delay between the TRP and the UE capabilities must be taken into account. For multiple antenna panels deployed per TRP or per gNodeB, ideal transmission with no delay can be implemented. For multiple TRPs between different gNodeBs, the transmission delay may be 20 ms or more. Therefore, the 3GPP protocol must consider two scenarios: ideal transmission with very short or no delay, and non-ideal transmission with long delay. Different solutions are required for the two different scenarios. In the non-ideal delay scenario, to meet the delay requirements of 5G services, DCI, transmission of uplink control information (UCI) and data carried on the PDSCH cannot be performed simultaneously between TRPs. Therefore, support for loosely coordinated transmission between multiple TRPs is considered. In other words, each TRP independently schedules transmissions on the physical downlink control channel (PDCCH) corresponding to the PDSCH, and the UE also supports independent transmission scheduling. In an ideal delay scenario, control information and data are exchanged smoothly between TRPs, so that any TRP can schedule transmissions / retransmissions of multiple TRPs (single-DCI multi-TRP transmissions). Compared to the multi-DCI design, the single-DCI design allows the UE to monitor a smaller search space, resulting in reduced UE blind decoding complexity and UE power consumption.

[0074] In a DU-to-DU carrier aggregation application scenario, data generated by a CU is segmented to different DUs, which then transmit data to the same terminal. In one possible implementation, a master DU (mDU) segments data packets arriving at the RLC or MAC layer into secondary DUs (sDUs) via a backhaul link between the DUs. Note that these data packets are not processed by the layer before segmentation. In other words, service data units (SDUs) at the RLC or MAC layer are segmented. In addition, an inter-DU mobility enhancement method has been proposed in which a CU performs segmentation on protocol data units (PDUs) at the PDCP layer and then transmits the PDUs to different DUs via a backhaul link between the CU and the DU.

[0075] For example, Figure 10 is a diagram of an architecture for DU inter-cell data division according to one embodiment of the present application. A communication system includes a base station and terminals. The base station includes a CU, a DU1 (functioning as a master DU or master node (MN)), and a DU2 (functioning as a secondary DU or secondary node (SN)). In Figure 10, the data division scheme indicated by arrow (1) is that the CU divides protocol data units (PDUs) at the PDCP layer. The data division scheme indicated by arrow (2) is that the master DU steers service data units (SDUs) arriving at the RLC layer to the secondary DU, and these data packets are not processed by the RLC layer before steering. The data division scheme indicated by arrow (3) is that the master DU steers PDUs from the RLC layer or SDUs arriving at the MAC layer to the secondary DU, and these data packets are not processed by the MAC layer before steering. In addition, it should be noted that the format of the data packets in the data division scheme indicated by arrow (1) may be the same as the format of the data packets in the data division scheme indicated by arrow (2), however, the former data division is performed by the CU and the latter data division is performed by DU1.

[0076] In the above two transmission methods, different DUs need to separately configure independent RLC or MAC entities for the UE. Furthermore, because Layer 2 (including the RLC and MAC layers) interactions are involved, the cooperative DUs need to exchange a large amount of Layer 2 parameter information, including Layer 2 context, configuration, and intermediate state variables. For example, the intermediate state variables include timers, correspondence between hybrid automatic repeat request (HARQ) processes and PDCP entities, RLC entities, or higher layer entities, and data transmission variables for the HARQ processes. The data transmission variables for the HARQ processes include parameters such as data packet acknowledgment status, maximum transmission or reception state variables, transmission or reception state variables, and transmission windows. It can be seen that the configuration of existing architectures is complex and incurs high information transmission overhead. In consideration of this, a solution is provided in an embodiment of the present application.

[0077] In an embodiment of the present application, a first DU (e.g., a master DU) receives data of a terminal from an upper layer, enables a terminal-specific MAC entity scheduling function, processes the data to obtain a physical layer transmission data stream, and then sends the physical layer transmission data stream to a second DU to form PHY layer data segmentation for the terminal. Because the MAC entity of the first DU is used to uniformly schedule the physical layer transmission data stream and the second DU does not enable a terminal-specific MAC entity scheduling function, the first DU and the second DU do not need to exchange a large amount of Layer 2 parameter information, and as a result, information transmission overhead can be reduced.

[0078] 11 is a schematic flowchart of an inter-DU communication method according to an embodiment of the present application. The method may be implemented based on the network architecture and related devices described in the foregoing. In this embodiment of the present application, the base station uses a CU / DU split architecture. The method includes the following steps:

[0079] S101: The CU transmits data of the terminal to the first DU.

[0080] The data is generated by the CU and transmitted to the terminal, that is, downlink data.

[0081] In this embodiment of the present application, the first DU may be a master DU, in other words, the first DU uses a master cell group (MCG) to serve the terminal.

[0082] S102: After receiving data of the terminal from the CU, the first DU processes the data using a MAC entity scheduling function specific to the terminal to obtain a physical layer transmission data stream.

[0083] The first DU enables MAC entity scheduling functions specific to the terminal, which may include, for example, (1) error correction using a HARQ mechanism, (2) priority management between different logical channels of the same UE, (3) priority management between UEs through dynamic scheduling, and (4) transport format selection, in which the corresponding transport format (including modulation scheme, coding rate, etc.) is selected based on measurement information reported by the physical layer, user capabilities, etc., to achieve the most effective resource utilization.

[0084] In one possible implementation, the physical layer transmission data stream is a media access control protocol data unit (MAC PDU). In this way, the first DU processes the data using a MAC entity scheduling function specific to the terminal, and the processed data is encapsulated in a MAC PDU.

[0085] In another possible implementation form, the manner in which the first DU processes data using a terminal-specific medium access control MAC entity scheduling function to obtain a physical layer transmission data stream is specifically as follows: The first DU processes the data using a medium access control MAC entity scheduling function and a physical layer scheduling function for the terminal to obtain a physical layer transmission data stream, where the physical layer transmission data stream is one of a transport block (TB), a code word (CW), and a code block (CB).

[0086] A TB is a basic data unit processed by the MAC layer on a transport channel, i.e., the basic unit for data exchange between the MAC layer and the physical layer, and is a data information block to be coded. Data and signaling messages on the user plane need to be processed by the PDCP layer, RLC layer, and MAC layer before reaching the PHY layer. The data processed by the physical layer is actually a PDU from the MAC layer, and the data block of the PDU is a TB. After receiving a TB, the PHY layer must convert it to a CW, and CB is the name of the data block in the conversion process. In other words, a CB is the data unit obtained after the MAC layer submits a TB to the PHY layer and adds a cyclic redundancy check (CRC) and segmentation process. It is the basic data unit processed before the general coding procedure at the physical layer is completed. A CW is the processing result obtained after the physical layer performs a series of operations on the TB, such as CRC, segmentation, channel coding, and reassembly. In other words, a CW is the coded data information.

[0087] In another possible implementation, the physical layer transmission data stream may alternatively be baseband modulation symbols generated by modulating different CWs, or may be orthogonal frequency division multiplexing (OFDM) symbols generated by combining modulation symbols to perform layer mapping and precoding / weighting, and then mapping the modulation symbols to radio resource element (RE) blocks.

[0088] S103: The first DU sends a physical layer transmission data stream to the second DU.

[0089] Optionally, the physical layer transmission data stream may be all or a part of the physical layer transmission data stream of the first DU. The second DU serves the terminal using a secondary cell group (SCG). The first DU and the second DU may be DUs connected to the same CU (e.g., DU1 and DU2 in FIG. 8) or may be DUs connected to different CUs (e.g., DU2 and DU3 in FIG. 8).

[0090] Specifically, the first DU transmits a physical layer transmission data stream to the second DU via an interface between the first DU and the second DU. Optionally, the interface between the first DU and the second DU may be a direct connection in a wired or wireless manner. Optionally, the connection between the first DU and the second DU may not be a direct connection. For example, the connection between the first DU and the second DU may be implemented by multiplexing optical fibers between the DU and the CU.

[0091] For example, Figure 12 is a diagram of an architecture for DU inter-cell data division according to one embodiment of the present application. A communication system includes a base station and a terminal. The base station includes a CU, a first DU (acting as a master DU), and a second DU (acting as a secondary DU). In this example, the first DU and the second DU are DUs connected to the same CU. The first DU divides the physical layer transmission data stream processed by the MAC layer to the secondary DU. Because the MAC entity of the first DU is used to uniformly schedule the physical layer transmission data stream and the second DU does not need to enable a MAC entity scheduling function specific to the terminal, the first DU and the second DU do not need to exchange a large amount of Layer 2 parameter information, which can reduce information transmission overhead.

[0092] In some embodiments, the first DU further transmits physical layer transmission control information to the second DU to enable the second DU to determine a manner of transmitting the physical layer transmission data stream to the terminal. The second DU may determine configuration parameters to be used for downlink transmission based on the physical layer transmission control information and reserve transmission resources required for the downlink transmission. The physical layer transmission control information includes one or more of the following: parameter information related to DCI, parameter information related to TB, CB, or CW (e.g., TB size and CB size), parameter information of modulation and coding scheme (MCS), parameter information of transmit power control (TPC), parameter information of transmission configuration indicator (TCI) status, parameter information of precoding matrix indication (PMI), parameter information of antenna port (port), parameter information related to time-frequency location and search space of physical downlink control channel (PDCCH) for terminals in a control-resource set (CORESET) (e.g., per-UE PDCCH), information on data scrambling ID of PDSCH, and information on radio network temporary identifier (RNTI). The data scrambling ID of PDSCH is included in PDSCH-Config IE_>dataScramblingIdentityPDSCH IE. The RNTI may include various RNTIs, for example, a cell radio network temporary identifier (cell RNTI, C-RNTI), a system information radio network temporary identifier (system information RNTI, SI-RNTI), and a paging radio network temporary identifier (paging RNTI, P-RNTI).

[0093] It should be noted that in the CORESET, the relevant parameter information of the time-frequency location and search space of the PDCCH for the terminal, the information about the data scrambling identifier of the PDSCH, and the information about the radio network temporary identifier RNTI are included in the RRC configuration message and system information block (SIB) message sent by the CU to the terminal via the first DU. Therefore, in a specific implementation, the first DU may directly forward the parameter values ​​or information element values ​​in the RRC configuration message and SIB message sent by the CU to the second DU.

[0094] Specifically, in an NR system, information such as the frequency band occupied by the PDCCH in the frequency domain and the number of OFDM symbols occupied by the PDCCH in the time domain is encapsulated in a CORESET, and information such as the PDCCH starting OFDM symbol number and PDCCH monitoring periodicity is encapsulated in a Searchspace. Each Searchspace is associated with one CORESET. After one CORESET is combined with one Searchspace, the PDCCH configuration can be determined. In addition, transmission of DCI with different contents can be performed on the PDCCH, and the DCI can be distinguished by scrambling using different RNTIs. For example, the C-RNTI, P-RNTI, and SI-RNTI are used to scramble DCI to schedule transmissions such as broadcast messages, paging messages, and terminal data, respectively. First, the terminal needs to demodulate the DCI scrambled using the RNTI and whose transmission is performed on the PDCCH based on the RNTI value. Then, at the PDSCH time-frequency resource location indicated by the DCI, the terminal demodulates information whose transmission is carried on the terminal's PDSCH, such as broadcast messages, paging messages, and terminal data, based on the data scrambling ID.

[0095] S104: The second DU sends the physical layer transmission data stream to the terminal.

[0096] Specifically, the second DU prohibits the activation of a MAC entity scheduling function specific to the terminal. For the MAC entity scheduling function, please refer to the description above. Details will not be described again in this specification. Furthermore, the second DU further prohibits the activation of an RLC layer entity scheduling function specific to the terminal and bearer mapping configurations such as RLC channels and DRBs. In other words, in this solution, the first DU uniformly schedules the downlink transmissions of the first DU and the second DU.

[0097] In one possible implementation, the second DU transmits a physical layer transmission data stream to the terminal by determining a time-frequency location of a PDCCH corresponding to the terminal based on the time-frequency location of the PDCCH for the terminal and related parameter information of the search space in the CORESET in the physical layer transmission control information. The second DU determines a time-frequency location of a PDSCH based on related parameter information of a DCI in the physical layer transmission control information. The second DU transmits DCI scrambled using the RNTI to the terminal via the PDCCH, where the DCI indicates the PDSCH. The second DU transmits a physical layer transmission data stream scrambled using a data scrambling identifier of the PDSCH to the terminal via the PDSCH. For example, the physical layer transmission data stream may be a broadcast message, a paging message, or a data message transmitted to the terminal. In this implementation, the second DU transmits the DCI to the terminal. For example, an application scenario of this implementation may include a multi-DCI inter-DU multi-TRP transmission scenario due to a non-ideal backhaul (BH) between DUs.

[0098] In another possible implementation, a specific method in which the second DU transmits a physical layer transmission data stream to the terminal is for the second DU to determine a time-frequency position of a PDSCH based on related parameter information of the DCI in the physical layer transmission control information, and transmit the scrambled physical layer transmission data stream to the terminal via the PDSCH using a data scrambling identifier of the PDSCH. In this implementation, the second DU does not transmit DCI to the terminal, but transmits data information to the terminal via the PDSCH indicated by the related parameter information of the DCI transmitted to the terminal by the first DU. For example, an application scenario of this implementation may include a single-DCI inter-DU multi-TRP transmission scenario for ideal BH between DUs.

[0099] Optionally, in some embodiments, the CU sends instruction information to the first DU and the second DU, where the instruction information includes an identifier of the terminal, and the instruction information instructs the first DU and the second DU to perform inter-DU cooperative transmission for the terminal. The first DU and the second DU performing inter-DU cooperative transmission for the terminal may be understood as the first DU and the second DU jointly providing a data transmission service for the terminal device. In the case of the first DU, the first DU may directly transmit data to the terminal. In the case of the second DU, the second DU may receive a physical layer transmission data stream obtained by processing the terminal's data by the first DU, and then transmit the physical layer transmission data stream to the terminal, which is the data transmission scheme shown in FIG. 11.

[0100] Optionally, the CU sends indication information to the first DU and the second DU via the F1 interface. The indication information further indicates that the second DU prohibits (also referred to as not enabling) the MAC entity scheduling function of the cooperatively served UE, in other words, prohibits enabling the MAC layer scheduler of the cooperatively served UE. Optionally, the existing UE F1AP ID information element may indicate that the UE associated with the existing UE F1AP ID information element is a cooperatively served UE. The indication information and the UE F1AP ID may be included in an F1AP message sent by the CU to the DU. The indication information may be indicated by defining new UE-associated F1AP signaling.

[0101] Note that control plane signaling between the CU and DU is transmitted using the F1AP protocol layer and is called F1AP messages. F1AP messages are classified into two types: (1) Non-UE-associated services, which are related to the entire F1 interface instance between the gNB-DU and gNB-CU and use a non-UE-associated signaling connection; and (2) UE-associated services, which are related to one UE and the F1AP function providing the service uses a UE-associated signaling connection to provide the service to the UE. In general, there is at most one F1AP procedure related to a particular UE at a protocol endpoint.

[0102] Optionally, after receiving the indication information and the UE F1AP ID, the second DU does not set up a UE context for the indicated UE (i.e., the cooperatively served UE), and the context includes bearer configurations such as SRB, DRB, BH RLC channel, and logical channel. In addition, the second DU does not enable a Layer 2 scheduler for scheduling data packets of the UE. In a specific implementation, the second DU may alternatively enable some functions of the MAC entity to distinguish whether an uplink data packet is from a UE cooperatively served between DUs or a UE independently served by the second DU.

[0103] The above describes the downlink transmission process in inter-DU cooperative transmission performed by the first DU and the second DU for the terminal. The following further describes uplink transmission in an inter-DU cooperative transmission scenario.

[0104] In one possible implementation, UL scheduling and UL transmission for a terminal (i.e., a cooperatively served terminal) may be processed only on the first DU (or MCG). In this way, the terminal triggers and reports uplink control information (UCI) only to the MCG of the first DU, where the UCI includes one or more of the following: a buffer status report (BSR), a power headroom report (PHR) status report, a timing advance (TA), and a measurement reference signal (SRS) measurement result. A measurement reference signal may also be referred to as a channel sounding reference signal, listening reference signal, sounding reference signal, monitoring reference signal, etc.

[0105] In addition, the terminal transmits uplink feedback information only to the first DU, and the uplink feedback information includes HARQ reception status feedback information, for example, an acknowledgement character (ACK) message and a negative acknowledgement character (NACK) message.

[0106] In another possible implementation, UL scheduling and UL transmission for a terminal (i.e., a terminal provided cooperatively) may also be processed on the second DU (or SCG). In this way, in addition to transmitting UCI and uplink feedback information to the first DU, the terminal may further transmit UCI and uplink feedback information to the second DU. For example, Figure 13 is a schematic flowchart of another inter-DU communication method according to an embodiment of the present application.

[0107] S201: The terminal sends UCI to the second DU.

[0108] For UCI, please refer to the description above. Details will not be described again in this specification. Optionally, the terminal triggers and reports BSR or PHR in the secondary cell group of the second DU. Optionally, when performing scheduling and transmission in the secondary cell group of the second DU, the terminal transmits TA and SRS measurement results to the second DU.

[0109] S202: After receiving the UCI from the terminal, the second DU sends the UCI to the first DU.

[0110] S203: The terminal sends uplink feedback information to the second DU.

[0111] For uplink feedback information, please refer to the description above. Details will not be described again in this specification. Optionally, the HARQ entity in the MAC layer of the terminal generates status acknowledgement feedback information (e.g., ACK or NACK) for the received data packet.

[0112] S204: After receiving the uplink feedback information from the terminal, the second DU sends the uplink feedback information to the first DU.

[0113] In the method embodiments corresponding to Figures 11 and 13, the first DU splits the physical layer transmission data stream, so that the first DU and the second DU can perform cooperative transmission at the physical layer of the same terminal. Because the MAC layer of the first DU is used to process the physical layer transmission data stream and the second DU does not need to enable terminal-specific MAC entity scheduling functions, the first DU and the second DU do not need to exchange a large amount of Layer 2 parameter information, which can reduce information transmission overhead. This scheme can be applied to scenarios such as inter-DU multi-TRP transmission and inter-DU CA transmission.

[0114] The above content describes a scheme in which a first DU and a second DU perform inter-DU cooperative transmission for a terminal. Considering that the BH between DUs may not be ideal, in other words, transmission between DUs may cause additional transmission delay, the embodiments of the present application further provide some random access enhancement methods for the second DU. The content of this part will be described below. The random access enhancement methods for the second DU proposed in the following content are also applicable to the split architecture shown in FIG. 10.

[0115] First, let us explain the concept of random access (RA). Uplink synchronization between a terminal (e.g., a UE) and a gNB is implemented using the random access (RA) method. In a synchronous system, due to the different distances from different UEs to the gNB, uplink data from different UEs may arrive at different times, causing interference. Therefore, the gNB expects that the signal arrival times of different UEs from the same subframe will be essentially aligned. The gNB can correctly receive uplink data transmitted by a UE as long as the signal falls within the cyclic prefix (CP) range. The gNB may obtain the uplink timing offset (time advance, TA) by measuring the RA preamble (i.e., Msg1) transmitted by the UE. In the RA process, the UE needs to initiate access on a specific time-frequency resource of a physical random access channel (PRACH). The signal transmitted by the UE when the UE initiates access is the RA preamble. The RA preamble is used to notify the gNB of a random access request, allowing the gNB to estimate the transmission delay between the gNB and the UE. Furthermore, the gNB transmits the TA value to the UE in an RA response (Random Access Response, or Msg2) message. Additionally, the gNB may further allocate uplink resources (UL grant) to the UE via the RA, so that the UE transmits uplink signaling and data on these resources.

[0116] There are two CA mechanisms: contention-based random access (CBRA) and contention-free random access (CFRA). In the CBRA process, a preamble is randomly selected by the UE within the preamble range broadcast in System Information Block 1 (SIB1). Therefore, preambles selected by different UEs may conflict. Therefore, the gNB handles accesses of different UEs through contention. However, the access results are random, and not all UE accesses are successful. In the CFRA process, the preamble is a dedicated preamble assigned to the UE by the gNB, so preamble contention does not occur on the UE. In a special case, if the dedicated preamble is insufficient, the gNB instructs the UE to initiate CBRA.

[0117] 14 is a schematic flowchart of another inter-DU communication method according to an embodiment of the present application. The method may be implemented based on the network architecture and related devices described above. In this embodiment of the present application, the base station uses a CU / DU split architecture. The first DU functions as a master DU and serves the terminal using a master cell group. The second DU functions as a secondary DU and serves the terminal using a secondary cell group. In the method shown in FIG. 14, the terminal accesses the second DU in a contention-free random access manner. The method includes the following steps:

[0118] S301: A CU generates instruction information, which instructs a terminal to initiate contention-free random access to a second DU.

[0119] For example, the indication information may be a Random Access Preamble Assignment.

[0120] In one possible implementation, the indication information indicates a dedicated preamble to be used for contention-free random access. In another possible implementation, the indication information indicates a dedicated random access resource (e.g., a time-frequency resource of a PRACH) to be used for contention-free random access. In another possible implementation, the indication information indicates a dedicated preamble and a dedicated random access resource to be used for contention-free random access.

[0121] Optionally, the indication information may be included in an RRC message or a DCI.

[0122] S302: The CU sends instruction information to the first DU.

[0123] S303: After receiving the instruction information from the CU, the first DU sends the instruction information to the terminal.

[0124] S304: After receiving the indication information from the first DU, the terminal sends a random access message 1 (Msg1) to the second DU according to the indication information.

[0125] For example, Msg1 may be a Random Access Preamble.

[0126] Optionally, an implementation form in which the terminal transmits Msg1 to the second DU based on the indication information may include the following cases: In a possible implementation form, the indication information indicates a dedicated preamble to be used for contention-free random access. In this case, Msg1 transmitted by the terminal includes the dedicated preamble. In another possible implementation form, the indication information indicates a dedicated random access resource to be used for contention-free random access. In this case, the terminal transmits Msg1 to the second DU using the dedicated random access resource. In another possible implementation form, the indication information indicates a dedicated preamble and a dedicated random access resource to be used for contention-free random access. In this case, the terminal transmits Msg1 to the second DU using the dedicated random access resource, and Msg1 includes the dedicated preamble.

[0127] S305: After receiving Msg1 from the terminal, the second DU sends Msg1 to the first DU.

[0128] Optionally, the second DU receives Msg1 from the terminal based on the indication information. Specifically, the manner of reception corresponds to the manner of transmitting Msg1 by the terminal and may include the following cases: In one possible implementation, the indication information indicates a dedicated preamble to be used for contention-free random access. In this case, Msg1 received by the second DU includes the dedicated preamble. In another possible implementation, the indication information indicates a dedicated random access resource to be used for contention-free random access. In this case, the second DU receives Msg1 from the terminal using the dedicated random access resource. In another possible implementation, the indication information indicates a dedicated preamble and a dedicated random access resource to be used for contention-free random access. In this case, the second DU receives Msg1 from the terminal using the dedicated random access resource, and Msg1 includes the dedicated preamble.

[0129] S306: After the first DU receives Msg1 from the second DU, the first DU generates a random access message 2 (Msg2) based on Msg1.

[0130] For example, Msg2 may be a random access response. The first DU transmits Msg2 on a PDSCH to indicate that it has received Msg1 (one PDSCH may be used to simultaneously transmit Msg2 to multiple terminals). Optionally, the first DU may estimate a transmission delay between the secondary DU and the terminal based on Msg1 to determine a TA value. Msg2 includes the TA value, which is used to adjust the uplink transmission timing of the terminal. In addition, the information carried in Msg2 may further include an RA-preamble identifier, an uplink transmission grant (UL grant), a temporary C-RNTI identifier (Temporary C-RNTI or TC-RNTI), etc.

[0131] S307: The first DU sends Msg2 to the terminal.

[0132] S308: After receiving Msg2 from the first DU, the terminal sends Msg3 to the second DU.

[0133] For example, Msg3 may be a Scheduled Transmission.

[0134] Optionally, after transmitting Msg1, the terminal starts an RA response time window (e.g., ra-ResponseWindow) and continuously monitors the PDCCH within the RA window until the required RA response (i.e., Msg2) is obtained on the PDSCH. Generally, the value "sl80" of the ra-ResponseWindow IE indicates 80 slots, which is the maximum length of the response time window. The terminal generates Msg3 based on the received Msg2.

[0135] In the method shown in FIG. 14, the terminal accesses the second DU in a contention-free random access manner, which may result in an improved success rate of the terminal accessing the second DU.

[0136] 15 is a schematic flowchart of another inter-DU communication method according to an embodiment of the present application. This method may be implemented based on the network architecture and related devices described above. In this embodiment of the present application, the base station uses a CU / DU split architecture. The first DU functions as a master DU and serves the terminal using a master cell group. The second DU functions as a secondary DU and serves the terminal using a secondary cell group. In the method shown in FIG. 15, the terminal accesses the second DU in a contention-based random access manner. The method includes the following steps:

[0137] S401: The terminal sends a random access message 1 (Msg1) to the second DU.

[0138] For example, Msg1 may be a Random Access Preamble, where the preamble included in Msg1 is randomly selected by the terminal within the preamble range broadcast in System Information Block 1 (SIB1).

[0139] S402: After receiving Msg1 from the terminal, the second DU sends Msg1 to the first DU.

[0140] Optionally, the second DU may send Msg1 to the master DU via an interface or channel between the first DU and the second DU. Optionally, the interface between the first DU and the second DU may be a direct connection in a wired or wireless manner. Optionally, the connection between the first DU and the second DU may not be a direct connection. For example, the connection between the first DU and the second DU may be implemented by multiplexing optical fibers between the DU and the CU. In the following content, information exchange between the first DU and the second DU may be performed via this interface. This will not be described in detail later.

[0141] S403: The second DU sends a random access radio network temporary identifier (RA-RNTI) value of the secondary cell to the first DU.

[0142] The RA-RNTI value of the secondary cell is calculated by the second DU based on the time-frequency position of the PRACH where Msg1 is received, and there is a correspondence relationship between the secondary cell and the second DU. Specifically, the RA-RNTI value is used to determine the time-frequency position of the first PDCCH for scheduling random access message 2 (Msg2) and the time-frequency position of the first PDSCH for transmitting data information of Msg2, and is used to perform data scrambling for the first DCI whose transmission is carried by the first PDCCH. S404: The first DU receives random access message 1 (Msg1) from the second DU, and the first DU generates Msg2 based on Msg1.

[0143] For example, Msg2 may be a random access response. Optionally, the first DU determines, based on the RA-RNTI value, a time-frequency location of a first PDCCH for scheduling Msg2 and a time-frequency location of a first PDSCH for transmitting data information of Msg2, and scrambles the first DCI using the RA-RNTI. Msg2 may include a TA, an RA-preamble identifier, a UL grant, and a TC-RNTI.

[0144] S405: The first DU sends Msg2 to the terminal.

[0145] In one possible implementation, the first DU directly transmits Msg2 to the terminal, specifically, the first DCI for scheduling the first PDSCH is transmitted to the terminal on the first PDCCH, and the data information of Msg2 is transmitted on the first PDSCH.

[0146] In another possible implementation, the first DU sends Msg2 to the terminal via the second DU. In this way, the first DU sends Msg2 to the second DU.

[0147] The second DU determines the time-frequency location of the first PDCCH and the time-frequency location of the first PDSCH based on the RA-RNTI value. The second DU receives Msg2 from the master DU. The second DU transmits the first DCI to the terminal via the first PDCCH, where the first DCI is scrambled based on the RA-RNTI and indicates the first PDSCH. The second DU transmits data information in Msg2 to the terminal via the first PDSCH.

[0148] S406: After receiving Msg2 sent by the first DU, the terminal sends a random access message 3 (Msg3) to the second DU.

[0149] Optionally, the terminal may receive Msg2 sent by the first DU via the second DU. For example, Msg3 may be a Scheduled Transmission.

[0150] Optionally, after transmitting Msg1, the terminal starts an RA response time window (e.g., ra-ResponseWindow), continuously monitors the PDCCH within the RA window (the first PDCCH in this embodiment), and simultaneously performs descrambling using the RA-RNTI until the required RA response (i.e., Msg2) is obtained on the PDSCH. In this embodiment, the response time window in which the terminal monitors the first PDCCH or Msg2 is greater than 80 slots. Note that the duration of the response time window is longer than the duration in which the terminal monitors another general Msg2. In other words, in this embodiment, a longer response time window is configured for the process in which the terminal accesses the second DU in a contention-based random access manner. In this way, the impact of non-ideal BH between DUs can be reduced, and the success rate of the terminal accessing the second DU can be increased.

[0151] For example, Msg3 may be a Scheduled Transmission. The terminal generates Msg3 based on the received Msg2.

[0152] S407: After receiving Msg3 from the terminal, the second DU sends Msg3 to the first DU.

[0153] Optionally, the second DU may send Msg3 to the first DU via an interface or channel between the first DU and the second DU.

[0154] S408: After receiving Msg3 from the second DU, the first DU sends Msg3 to the CU.

[0155] For example, Msg3 may be an RRC message.

[0156] S409: After receiving Msg3 from the first DU, the CU generates Msg4 based on Msg3.

[0157] Optionally, the RRC layer of the CU generates Msg4 based on Msg3.

[0158] S410: The CU sends Msg4 to the first DU.

[0159] S411: After receiving Msg4 from the CU, the first DU sends Msg4 to the terminal.

[0160] In one possible implementation, the first DU directly transmits Msg4 to the terminal, specifically, a second DCI for scheduling the second PDSCH is transmitted to the terminal on the second PDCCH, the second DCI is scrambled based on the TC-RNTI, and the data information of Msg4 is transmitted on the second PDSCH.

[0161] In another possible implementation, a search space of the second PDCCH for scheduling Msg4 is configured for the second DU. The search space may be a common or dedicated search space. In this case, the first DU may transmit Msg4 to the terminal via the second DU. In this manner, the first DU transmits Msg4 to the second DU. For the second DU, the second DU receives Msg4 from the first DU. The second DU then transmits a second DCI to the terminal via the second PDCCH, where the second DCI is scrambled based on the TC-RNTI and indicates the second PDSCH. The second DU transmits data information of Msg4 to the terminal via the second PDSCH. Optionally, the TC-RNTI may be the TC-RNTI of the secondary cell of the second DU or the TC-RNTI transmitted by the first DU to the second DU.

[0162] It should be noted that after transmitting Msg3, the terminal starts a contention resolution timer and then monitors the PDCCH (the second PDCCH in this embodiment) within the time window of the timer. The gNB assists the UE in contention resolution by using the TC-RNTI for scrambling on the PDCCH or the UE contention resolution identity for scrambling on the PDSCH. Before the contention resolution timer expires, the UE continues to monitor the PDCCH channel and also uses the TC-RNTI for descrambling. If the UE's TC-RNTI is detected on the PDCCH corresponding to Msg4, the UE considers the contention resolution successful (in other words, the UE's access is successful) and stops the contention resolution timer. If the UE's TC-RNTI is not detected on the PDCCH of Msg4, the UE does not stop the timer. In this embodiment, the maximum duration of the timer for the terminal to monitor the second PDCCH or Msg4 is longer than the duration of 64 subframes. It should be noted that the maximum duration of the timer is longer than the duration for which the terminal monitors another general Msg4. In other words, in this embodiment, a longer maximum duration of the timer is configured for the process in which the terminal accesses the second DU in the manner of contention-based random access. In this way, the influence of non-ideal BH between DUs can be reduced, and the success rate of the terminal accessing the second DU can be increased.

[0163] This embodiment of the present application may further be applied to an integrated access and backhaul (IAB) network communication system shown in FIG. 16. The communication system includes a terminal, an IAB node, and a donor base station. In this application, the term "IAB network" is merely an example and may be replaced with a "wireless backhaul network" or a "relay network." The term "IAB node" is also merely an example and may be replaced with a "wireless backhaul device" or a "relay node." The "IAB node" in this embodiment of the present application may be a first node.

[0164] A donor base station may function as a donor node for an IAB node. In the present application, the donor base station may include, but is not limited to, a next generation node B (gNB), an evolved Node B (eNB), a radio network controller (RNC), a Node B (NB), a base station controller (BSC), a base transceiver station (BTS), a home evolved Node B (or home Node B), a transmission and reception point (transmission point), a road side unit (RSU) having base station functionality, a baseband unit (BBU), and a remote radio unit (RRU), an active antenna unit (AAU), one or a group of antenna panels, a node having base station functionality in a subsequent evolved system, etc. The donor base station may be an entity and may further include a centralized unit (CU) entity and at least one distributed unit (DU) entity. The interface between the CU and the DU may be referred to as an F1 interface. The two ends of the F1 interface are the CU and the DU, respectively. The peer end of the F1 interface of the CU is the DU, and the peer end of the F1 interface of the DU is the CU. The F1 interface may further include a control plane F1 interface (F1-C) and a user plane F1 interface (F1-U). In this application, the CU of the donor base station may be abbreviated as donor CU, and the DU of the donor base station may be abbreviated as donor DU.

[0165] In this application, a terminal may also be referred to as user equipment (UE), a mobile station, a terminal device, etc. Terminals may be widely used in various scenarios, such as device-to-device (D2D), vehicle-to-everything (V2X) communication, machine-type communication (MTC), the Internet of Things (IoT), virtual reality, augmented reality, industrial control, autonomous driving, telemedicine, smart grid, smart furniture, smart office, smart wearable, smart transportation, and smart city. A terminal may be a mobile phone, a tablet computer, a computer with wireless transceiver capability, a wearable device, a vehicle, an unmanned aerial vehicle, a helicopter, an airplane, a ship, a robot, a mechanical arm, a smart home device, etc. The terminal may include, but is not limited to, a user equipment (UE), a mobile station, a mobile device, a terminal device, a user agent, a mobile phone, a cordless phone, a session initiation protocol (SIP) phone, a wireless local loop (WLL) station, a personal digital assistant (PDA), a handheld device with wireless communication capabilities, a computing device, another processing device connected to a wireless modem, an in-vehicle device, a wearable device (such as a smart watch, a smart band, or smart glasses), smart furniture or appliances, a vehicle device in a vehicle-to-everything (V2X) system, a terminal device with relay capabilities, a customer premises equipment (CPE), an IAB node (specifically, an IAB node acting as an MT or terminal for an IAB node), etc. The specific name and implementation of the terminal are not limited in this application.

[0166] In the present application, an IAB node may include at least one mobile terminal (MT) and at least one distributed unit (DU). The IAB node may be an entity. For example, the IAB node includes at least one MT function and at least one DU function. The IAB node may alternatively include multiple entities. For example, the IAB node includes at least one MT entity and at least one DU entity. The MT entity and the DU entity may communicate with each other, for example, via a network cable. When communicating with its parent node (which may be a donor base station or another IAB node), the IAB node may function as a terminal. For example, the IAB node is used in various scenarios where a terminal is used. In other words, the IAB node plays the role of a terminal. In this case, the MT function or MT entity provides the IAB node with the role of a terminal. When facing its child node (which may be another IAB node or a terminal), the IAB node may function as a network device. In other words, the IAB node plays the role of a network device. In this case, the DU function or DU entity provides the IAB node with the role of a network device. In this application, the MT of an IAB node may be abbreviated as IAB-MT, and the DU of an IAB node may be abbreviated as IAB-DU. An IAB node may access a donor base station or may be connected to the donor base station via another IAB node.

[0167] The IAB network supports multi-hop networking and multi-connectivity networking to ensure the reliability of service transmission. An IAB node may regard an IAB node providing backhaul services to the IAB node as a parent node, and correspondingly, the IAB node may be regarded as a child node of the IAB node's parent node. A terminal may regard an IAB node accessed by the terminal as a parent node or alternative, and correspondingly, the IAB node may regard a terminal accessing the IAB node as a child node or alternative. An IAB node may regard a donor base station accessed by the IAB node as a parent node, and correspondingly, the donor base station may regard an IAB node accessing the donor base station as a child node or alternative. As shown in FIG. 16, terminal 1 may be referred to as a downstream node or descendant node of IAB node 4. Each IAB node needs to maintain a backhaul link (BL) pointing toward the parent node. If the child node of an IAB node is a terminal, the IAB node further needs to maintain an access link (AL) between the IAB node and the terminal. As shown in FIG. 16, the link between IAB node 4 and terminal 1 or terminal 2 includes an AL. A BL is included between IAB node 4 and IAB node 2 or IAB node 3. Transmission of an uplink data packet transmitted by the terminal to a donor base station may be performed via one or more IAB nodes. In other words, the target node of the uplink data between the terminal and the donor base station may be the donor base station. Downlink data packets transmitted by the donor base station to the terminal may be transmitted to the access IAB node of the terminal via one or more IAB nodes, and then transmitted to the terminal by the access IAB node. In other words, the target node of the downlink data between the terminal and the donor base station may be the access IAB node. It will be understood that in an IAB network, one transmission path between a terminal and a donor base station may include one or more IAB nodes.Each IAB node must maintain a wireless backhaul link (BL) toward its parent node. If the child node of an IAB node is a terminal, a wireless access link (AL) exists between the IAB node and the terminal. As shown in FIG. 16, in path 1 between terminal device 1 and a donor base station, terminal 1 accesses IAB node 4 via AL, IAB node 4 is connected to IAB node 3 via BL, IAB node 3 is connected to IAB node 1 via BL, and IAB node 1 is connected to the donor base station via BL.

[0168] 17 and 18 are diagrams of a control plane protocol stack in an IAB network and a user plane protocol stack in an IAB network, respectively, according to an embodiment of the present application. The donor base station in FIGS. 17 and 18 may include a donor CU function and a donor DU function (in this case, the donor base station is one entity), or may include a donor CU entity and a donor DU entity (in this case, the donor base station is divided into two entities). As shown in FIG. 17 or 18, the peer protocol layers between the donor DU and the donor CU include an IP layer, Layer 2 (L2), and Layer 1 (L1). L1 and L2 may be protocol stack layers in a wired transmission (e.g., optical fiber transmission) network. For example, L1 may be the physical layer, and L2 may be the data link layer. Backhaul links (BL) are set up between IAB node 4 and IAB node 3, between IAB node 3 and IAB node 1, and between IAB node 1 and the donor DU. The peer protocol stacks at both ends of the BL may include a backhaul adaptation protocol (BAP) layer, a radio link control (RLC) layer, a medium access control (MAC) layer, and a physical (PHY) layer.

[0169] As shown in FIG. 17, there is an interface between the terminal and the donor base station, and the interface may also be referred to as an air interface. For example, the interface may be referred to as a Uu interface. One end of the Uu interface is located in the terminal, and the other end of the Uu interface is located in the donor base station. The peer control plane protocol stacks at both ends of the Uu interface include a radio resource control (RRC) layer, a packet data convergence protocol (PDCP) layer, an RLC layer, a MAC layer, and a PHY layer. The protocol layers included in the control plane protocol stack of the Uu interface may also be referred to as a control plane access stratum (AS). When the donor base station includes a donor CU entity and a donor DU entity, the control plane protocol stacks at the donor base station end of the Uu interface may be located in the donor DU and donor CU, respectively. For example, the PHY layer, MAC layer, and RLC layer are located in the donor DU, and the RRC layer and PDCP layer are located in the donor CU.

[0170] There is an interface between the DU of the IAB node (i.e., IAB node 4 in FIG. 16) accessed by the terminal and the donor base station. For example, the interface is called an F1 interface. One end of the F1 interface is located in IAB node 4, and the other end of the F1 interface is located in the donor base station. The peer end of the F1 interface of the donor base station (which may be, for example, a donor CU) is the IAB node (specifically, which may be the DU of the IAB node), and the peer end of the F1 interface of the IAB node (specifically, which may be the DU of the IAB node) is the donor base station (specifically, which may be the donor CU). The peer control plane protocol stacks at both ends of the F1 interface include an F1 application protocol (F1AP) layer, a stream control transmission protocol (SCTP) layer, and an IP layer. The donor base station may include a donor CU entity and a donor DU entity. The control plane protocol stack of the F1 interface at the donor base station end may be located in the donor CU. For example, the donor CU includes an F1AP layer, an SCTP layer, and an IP layer. Alternatively, the control plane protocol stack of the F1 interface at the donor base station end may be located in the donor CU and donor DU, respectively. For example, the donor CU includes an F1AP layer and an SCTP layer, and the donor DU includes an IP layer. As shown in FIG. 18, the peer user plane protocol stack at both ends of the Uu interface between the terminal and the donor base station includes a service data adaptation protocol (SDAP) layer, a PDCP layer, an RLC layer, a MAC layer, and a PHY layer. The protocol layers included in the user plane protocol stack of the Uu interface may also be referred to as a user plane access layer (AS). When the donor base station includes a donor CU entity and a donor DU entity, the user plane protocol stacks of the Uu interface at the donor base station end may be located in the donor DU and donor CU, respectively.For example, the PHY layer, MAC layer, and RLC layer are located in the donor DU, and the SDAP layer and PDCP layer are located in the donor CU.

[0171] The peer user plane protocol layers at both ends of the F1 interface between the DU of the IAB node 4 and the donor base station include a general packet radio service tunneling protocol for the user plane (GTP-U) for the user plane layer, a user datagram protocol (UDP) layer, and an IP layer. The donor base station may include a donor CU entity and a donor DU entity. The user plane protocol stack of the F1 interface at the donor base station end may be located in the donor CU. For example, the donor CU includes the GTP-U layer, the UDP layer, and the IP layer. Alternatively, the user plane protocol stack of the F1 interface at the donor base station end may be located in the donor CU and the donor DU, respectively. For example, the donor CU includes the GTP-U layer and the UDP layer, and the donor DU includes the IP layer.

[0172] When a terminal refers to an IAB node or an MT function or MT entity of an IAB node, or when it plays the role of a terminal, the protocol stack of the terminal shown in FIG. 17 or FIG. 18 is the protocol stack of the MT function or MT entity of the IAB node, or the protocol stack of the IAB node playing the role of a terminal. When accessing an IAB network, the IAB node may play the role of a terminal. In this case, the MT of the IAB node has the protocol stack of the terminal. A protocol stack of the air interface (Uu interface) exists between the IAB node and the donor base station. The terminal protocol stack in FIG. 17 and FIG. 18 includes an RRC layer or SDAP layer, a PDCP layer, an RLC layer, a MAC layer, and a PHY layer. In the control plane, the IAB node's RRC messages are encapsulated into F1AP messages by the IAB node's parent node for transmission. In the user plane, the IAB node's data packets are encapsulated into PDCP protocol data units (PDUs) and sent to the IAB node's parent node. The parent node of the IAB node encapsulates the received PDCP PDU in a GTP-U tunnel on the F1 interface between the parent node of the IAB node and the donor CU for transmission. In addition, after the IAB node accesses the IAB network, the IAB node may still act as a common terminal. For example, transmission of the IAB node's data packets may be performed between the IAB node and the donor base station. For example, the data packets may include operation, administration, and maintenance (OAM) network element data packets, measurement reports, etc.

[0173] It should be noted that one IAB node may play one or more roles in the IAB network. For example, the IAB node may play the role of a terminal, or the role of an access IAB node (e.g., the protocol stack of IAB node 4 in FIGS. 17 and 18), or the role of an intermediate IAB node (e.g., the protocol stack of IAB node 1 or IAB node 3 in FIGS. 17 and 18). In the case of different roles, the IAB node may use protocol stacks corresponding to the different roles. When an IAB node plays multiple roles in the IAB network, the IAB node may simultaneously have multiple sets of protocol stacks. The multiple sets of protocol stacks may share some of the same protocol layers, for example, the same RLC layer, the same MAC layer, and the same PHY layer.

[0174] 19 is a diagram of a communication scenario. As shown in FIG. 19, a donor base station and an IAB node are included. The donor base station may include a donor CU and at least one donor DU. The communication interface between the donor base station and the IAB node may include an air interface (Uu interface) and an F1 interface. For example, an air interface (Uu interface) exists between an MT of the IAB and the donor base station, and an F1 interface exists between a DU of the IAB and the donor base station.

[0175] Figure 20 is a diagram of a dual connectivity communication scenario. As shown in Figure 20, a master base station, a secondary base station, and an IAB node are included. The donor base station of the IAB is the secondary base station. The communication interface between the master base station and the IAB node includes an air interface (Uu interface). The communication interface between the secondary base station and the IAB node includes a Uu interface and an F1 interface.

[0176] FIG. 21 is a diagram of an IAB dual connectivity communication architecture. As shown in FIG. 21, donor base station 1 includes donor CU1 and donor DU1. Donor base station 2 includes donor CU2 and donor DU2. A communication interface exists between the IAB node and donor base station 1 or donor base station 2. For example, the communication interface between the IAB node and donor base station 1 or donor base station 2 may include a Uu interface and / or an F1 interface. A communication interface also exists between donor base station 1 and donor base station 2. Donor CU1 and donor CU2 may communicate with each other, for example, via an X2 or Xn interface. Donor CU1 and donor DU2, and donor CU2 and donor DU1 may communicate with each other, for example, via an IP network. It may be understood that the communication architecture shown in Figure 21 may further include downstream or descendant nodes of the IAB node. There may also be upstream nodes of the IAB node between the IAB node and the donor base station.

[0177] In this application, a dual connectivity IAB node indicates that the IAB node simultaneously accesses two parent nodes in a dual connectivity manner. One of the two parent nodes serves as the master node (MN) of the IAB node, and the other parent node serves as the secondary node (SN) of the IAB node. The cell group (CG) configured on the MN side is the master cell group (MCG), and the cell group configured on the SN side is the secondary cell group (SCG). In other words, the IAB node is served by the MCG and the SCG. Dual connectivity scenarios may include, but are not limited to, the general NR DC scenario shown in Figure 21 and a CP-UP split scenario in the DC scenario.

[0178] In this application, CP-UP splitting indicates that the F1-C (F1 interface control plane) service and F1-U (F1 interface user plane) service of a dual connectivity IAB node do not reach the IAB donor via the same path. The F1 interface user plane (F1-U) service is encapsulated by the IAB-MT in a BAP layer data packet. Then, according to the BAP layer route and BH RLC channel mapping protocol, the F1-U service reaches the IAB donor via BH multihop forwarding (passing through multiple intermediate IAB nodes). This transmission method may be referred to as "F1 over BAP." In a general CP-UP non-split DC scenario, F1 over BAP is also applicable to F1-C services. The F1 interface control plane (F1-C) service is encapsulated by the IAB-MT in an RRC message of the IAB-MT and reaches the MN or SN via the Uu interface between the IAB-MT and a non-F1 terminating node (i.e., a non-F1 terminating node), and then reaches the IAB donor via the inter-base station Xn interface. This transmission method may be called "F1 over RRC." F1 over RRC is only applicable to F1-C services.

[0179] The IAB DC scenarios of Figures 22 and 23 are used as examples. Figure 22 is a diagram of a CP-UP split scenario in an EN DC scenario according to an embodiment of the present application. Figure 23 is a diagram of a CP-UP split scenario in an NR DC scenario according to an embodiment of the present application.

[0180] As shown in Figure 22, an IAB node (e.g., IAB node 2 or IAB node 1 in Figure 22) supports 4G and 5G dual connectivity, i.e., E-UTRAN NR Dual Connectivity (EN DC) mode. The LTE base station eNB is the master base station (Master eNB, MeNB), which provides the IAB node with an LTE air interface (LTE Uu) connection and sets up an S1 interface with the 4G Evolved Packet Core (EPC) network to perform user plane and control plane transmission. The CG on the LTE side is the MCG. The IAB-donor (gNB) is a secondary base station, which provides the IAB node with an NR air interface (NR Uu) connection and sets up an S1 interface with the core network EPC to perform user plane transmission. The CG on the NR side is the SCG. The F1-C service (shown in FIG. 22) and F1-U service of an IAB node (e.g., IAB node 2 in FIG. 22 or IAB node 1 in FIG. 22) reach the IAB donor (gNB) via different paths, respectively.

[0181] As shown in Figure 23, IAB node 2 sets up a connection to the network only via the air interface of the New Radio (NR) standard. Specifically, IAB node 2 is simultaneously connected to two parent nodes (in this application, a parent node may also include a donor node) in an NR DC format. The two parent nodes may function as a master node (MN) or a secondary node (SN) of IAB node 2, respectively. The CG configured on the MN side is the MCG, and the CG configured on the SN side is the SCG. The F1-C service and F1-U service of IAB node 2 reach the IAB donor (SgNB) via different routes, respectively.

[0182] The inter-base station cooperative transmission scheme is considered to include not only the CA and m-TRP described in the above embodiment, but also the above-mentioned IAB dual connectivity mode, specifically, the IAB communicates with two base stations by setting up a dual connectivity mode. Therefore, the method in this embodiment of the present application may further be applied to an IAB network communication system using DC networking, for example, an IAB network communication system using EN DC networking shown in Figure 24, or an IAB network communication system using NR DC networking shown in Figure 25.

[0183] For example, FIG. 24 is a diagram of an IAB network communication system using EN DC networking according to the present application. As shown in FIG. 24, the IAB network communication system may include a UE, IAB node 1, IAB node 2, an MeNB, IAB donor 1, IAB donor 2, and an EPC. The UE may communicate with IAB donor 1 or IAB donor 2 via IAB node 2 and IAB node 1. IAB node 2 is configured to provide access and backhaul services to the UE. IAB node 2 may include an IAB node DU (IAB-DU for short) and an IAB node MT (IAB-MT for short). IAB node 1 is configured to provide access and backhaul services to a child node (i.e., IAB node 2). IAB node 1 may also include an IAB node DU (IAB-DU for short) and an IAB node MT (IAB-MT for short).

[0184] The IAB-DU is a distributed unit part of an IAB node (e.g., IAB node 1 or IAB node 2 in this specification), has functions similar to those of the gNB-DU, and is configured to set up an F1 interface with the IAB-donor-CU and provide access services to the IAB-DU or child nodes of the UE.

[0185] The IAB-MT is a mobile-terminated part of an IAB node (e.g., IAB node 1 or IAB node 2 in this specification), has UE functionality, and is configured to provide data backhaul services to the IAB-MT or child nodes of the UE.

[0186] An IAB donor (referred to herein as IAB donor 1 or IAB donor 2) is a donor base station that supports an IAB node and may include an IAB-donor-CU and at least one IAB-donor-DU. An IAB-donor-CU may include one IAB-donor-CU-C (responsible for control plane services) and at least one IAB-donor-CU-UP (responsible for user plane services).

[0187] The IAB-donor-DU is a distributed unit part of the IAB donor (referred to herein as IAB donor 1 or IAB donor 2), has similar functions to the gNB-DU, and primarily implements the functions of the L1 and L2 protocol stacks, including the functions of the PHY layer, MAC layer, and RLC layer.

[0188] The IAB-donor-CU is the central unit part of the IAB donor (IAB donor 1 or IAB donor 2 in this specification), and has the same functions as the gNB-CU, mainly performing the functions of the PDCP layer, SDAP layer, and RRC layer. An F1-C interface is set up between the IAB-donor-CU-CP and the IAB-DU, and an F1-U interface is set up between the IAB-donor-CU-UP and the IAB-DU.

[0189] The MeNB is an LTE standard base station in EN DC networking mode, and for a UE or an IAB node (herein IAB node 1 or IAB node 2), the base station is a master base station (Master eNB, MeNB).

[0190] The BH is a backhaul link, for example, the NR BH shown in FIG. 24, specifically a connection channel between the MT part of the IAB node (IAB node 1 or IAB node 2 in this specification) and the DU part of the parent node of the IAB node, used to backhaul UE data packets or forward IAB donor data packets.

[0191] As shown in Figure 24, the IAB node (herein referred to as IAB node 1 or IAB node 2) supports 4G and 5G network dual connectivity, i.e., EN DC mode. The LTE base station eNB is an MeNB, which provides the IAB node with an LTE air interface (LTE Uu) connection and sets up an S1 interface with the EPC for user plane and control plane transmission. The CG on the LTE side is the MCG. The NR base station gNB is a secondary base station, which provides the IAB node with an NR air interface (NR Uu) connection and sets up an S1 interface with the core network EPC for user plane transmission. The CG on the NR side is the SCG. Similarly, the UE also supports EN DC. The UE is connected to the master base station eNB via an LTE Uu interface and to the secondary base station IAB node 2 via an NR Uu interface. In some embodiments, the UE's secondary base station may alternatively be IAB donor 1 or IAB donor 2. As shown in Figure 24, the EN DC scenario of the IAB network may also support multi-hop IAB networking. In other words, an IAB node may be connected to IAB donor 1 or IAB donor 2 via a multi-hop wireless backhaul link.

[0192] Optionally, the EN DC scenario of the IAB network may include a CP-UP split scenario and a CP-UP non-split scenario. In the CP-UP split scenario of the EN DC scenario, the F1-C service of the IAB node (herein referred to as IAB node 1 or IAB node 2) may reach a non-F1 interface terminating node (i.e., MeNB) via an LTE Uu interface channel. The non-F1 interface terminating node then transmits the F1-C service to the IAB donor (herein referred to as IAB donor 1 or IAB donor 2) via the inter-base station interface X2, and the IAB donor may be referred to as the F1-interface terminating donor node of the IAB node. The F1-U service of the IAB node (herein referred to as IAB node 1 or IAB node 2) reaches the IAB donor (herein referred to as IAB donor 1 or IAB donor 2) via BH multihop forwarding by the IAB node according to the BAP layer protocol.

[0193] It should be noted that the communication system architecture shown in Figure 24 is described using two IAB nodes as an example. The communication system architecture may include more IAB nodes, e.g., three, four, or more IAB nodes, or may include fewer IAB nodes, e.g., one IAB node. The present application is not limited to the system architecture shown in Figure 24.

[0194] 25 is a diagram of an IAB network communication system using NR DC networking according to the present application. As shown in FIG. 25, the IAB network communication system may include a UE, an IAB node 1, an IAB node 2, a gNB, an IAB donor 1, an IAB donor 2, and a 5GC.

[0195] For descriptions of the UE, IAB node 1, IAB node 2, IAB-DU, IAB-MT, IAB donor, IAB-donor-DU, and IAB-donor-CU, please refer to the related description of Figure 24. Details will not be described again in this specification.

[0196] A gNB is a base station in the 5G standard. In the case of a UE or an IAB node (herein referred to as IAB node 1 or IAB node 2), the gNB can be a master station (i.e., MN or MgNB) or a secondary station (i.e., SN or SgNB) of the UE or IAB node in DC mode.

[0197] Unlike the IAB network communication system in the EN DC networking shown in Figure 24, in the IAB network communication system shown in Figure 25, both the IAB node and the UE set up a connection to the network only via the NR standard air interface. In the NR DC configuration, IAB node 2 is simultaneously connected to two parent nodes, namely IAB node 1 and gNB. The two parent nodes may function as the MN or SN of IAB node 2, respectively. The CG configured on the MN side is the MCG, and the CG configured on the SN side is the SCG.

[0198] Optionally, the NR DC scenario for an IAB network may include a CP-UP split scenario and a CP-UP non-split scenario. In the CP-UP split scenario of the NR DC scenario, the F1-C service of an IAB node (herein referred to as IAB node 1 or IAB node 2) may reach a non-F1 interface terminating node via an NR Uu interface channel. The non-F1 interface terminating node then transmits the F1-C service to an IAB donor (herein referred to as IAB donor 1 or IAB donor 2) via a base station-to-base station interface Xn, and the IAB donor may be referred to as the F1 interface terminating node of the IAB node. The F1-U service of an IAB node (herein referred to as IAB node 1 or IAB node 2) reaches the IAB donor (herein referred to as IAB donor 1 or IAB donor 2) via a BH multihop forwarding by the IAB node according to the BAP layer protocol.

[0199] In NR DC networking, the non-F1 interface terminating node may be an MgNB and the F1 interface terminating donor node may be an SgNB. Alternatively, the non-F1 interface terminating node may be an SgNB and the F1 interface terminating node may be an MgNB.

[0200] It should be noted that the communication system architecture shown in Figure 25 is described using two IAB nodes as an example. The communication system architecture may include more IAB nodes, e.g., three, four, or more IAB nodes, or may include fewer IAB nodes, e.g., one IAB node. The present application is not limited to the system architecture shown in Figure 25.

[0201] It should be further noted that the name of the F1 interface is merely an example and does not limit the function of the F1 interface. In 5G networks and other future networks, the F1 interface may alternatively have another name. This is not specifically limited in the embodiments of the present application. In addition, it should be understood that the names of messages (or signaling) transmitted between the aforementioned network elements are merely examples and do not constitute any limitation on the function of the messages.

[0202] According to the current 3GPP TS 38.331, when an IAB node is added as a mobile terminating MT to the topology process managed by the donor node, or when an IAB node already integrated into the topology needs to update its original BAP configuration, the network device eNB (limited to being in EN DC mode) or gNB (in single-connection mode or NR DC mode) sends an RRCReconfiguration message or an RRCConnectionReconfiguration message to the IAB node. The bap-Config field included in the configuration information carries information used to configure the IAB node's BAP entity and corresponding functions, i.e., BAP configuration information. Furthermore, when the bap-Config field is set to setup, the IAB-MT performs a specific BAP configuration process based on the information element content included in the bap-Config field. When the bap-Config field is set to release, the IAB-MT releases the BAP entity, and the currently configured BAP configuration is also released. An IAB node has a unique BAP entity in its DU or MT portion. In addition, in NR DC mode, the BAP entity of the IAB may perform different BAP routing and bearer mapping functions based on the bap-Config information configured by the MCG and SCG, respectively.

[0203] Additionally, in the EN DC or NR DC dual connectivity mode, processes such as a secondary node change or handover and a secondary cell group link failure may occur in the IAB node. Therefore, the IAB node releases the secondary node and the BAP configuration associated with the secondary node. This process is called the Multi-Radio Access Technology (MR DC) dual connectivity release process of the IAB node. The endc-ReleaseAndAdd field carried in the RRCConnectionReconfiguration message sent by the master node eNB to the IAB node indicates the initiation of the process, or the nrdc-ReleaseAndAdd field carried in the RRCReconfiguration message sent by the master node gNB to the IAB node indicates the initiation of the process. According to the current 3GPP TS 38.331 standard, when an IAB node receives indication information from the master node in DC mode and executes the MR DC release process, the IAB-MT releases the BAP configuration bap-Config associated with the SCG.

[0204] However, the existing standard does not specify the scenarios or conditions under which an IAB node should release a BAP entity. This could lead to an IAB node improperly releasing a BAP entity in NR DC mode and improperly retaining a BAP entity in EN DC mode. For example, in common NR DC mode, the IAB-MT may need to release the bap-Config configuration for only one CG. According to the existing standard, when the bap-Config field is set to release for indication, the IAB-MT directly releases the IAB-MT's BAP entity. As a result, the BAP configurations configured for other CGs will not operate normally. In EN DC mode, when the IAB-MT performs MR DC release, according to the existing standard, the IAB-MT releases only the bap-Config configuration associated with the SCG. However, in this case, because the MCG is an LTE cell and does not have a bap-Config configuration, the IAB-MT also needs to release the BAP entity.

[0205] In the present application, adding a node includes at least one of setting up configuration and functional entities associated with the node, setting up an interface with the node, and setting up connections and / or bearers on the interface with the node. For example, adding an IAB donor node includes setting up a BAP configuration and entity associated with the donor. Setting up a Uu interface may include at least one of setting up an RRC connection, setting up an SRB, and setting up a DRB. Setting up an F1 interface may include setting up an F1 connection. Releasing a node includes at least one of releasing configuration and functional entities associated with the node, disconnecting the interface, and disconnecting connections and / or bearers on the interface. For example, releasing an IAB donor node includes releasing a BAP configuration and entity associated with the donor. Disconnecting the Uu interface may include at least one of disconnecting an RRC connection, disconnecting an SRB, and disconnecting a DRB. Disconnecting the F1 interface may include disconnecting the F1 connection.

[0206] The present application provides a communication method. The method includes: a first node receiving a reconfiguration message from a network device, the reconfiguration message being a radio resource control (RRC) reconfiguration message or an RRC connection reconfiguration message. The first node releases a backhaul adaptation protocol (BAP) entity of the first node based on the reconfiguration message. According to the method, when the first node functions as an IAB node, the first node may release the BAP entity of the first node based on the RRC message sent by the network device.

[0207] In one possible implementation, the reconfiguration message (specifically, when the BAP configuration (bap-Config) field included in the reconfiguration message is set to release) indicates that the BAP configuration of the first node is to be released, and a unique, successfully configured BAP configuration exists only in the first node. According to the above method, the first node functions as an IAB node. When the first node releases the unique BAP configuration of the first node, the first node may no longer hold the BAP entity of the first node.

[0208] In one possible implementation, a reconfiguration message (specifically, an EN DC Release and Add (endc-ReleaseAndAdd) field included in the reconfiguration message) instructs a first node, which is in an Evolved Universal Terrestrial Radio Access (E-UTRA) and New Radio NR (NR) dual connectivity (EN DC) mode, to perform a multi-RAT dual connectivity release (MR DC) process. Before the first node releases its backhaul adaptation protocol (BAP) entity based on the reconfiguration message, a BAP configuration associated with a secondary cell group (SCG) has already been released. According to the above method, the first node functions as an IAB node in the EN DC mode. When releasing the BAP configuration associated with the SCG, the IAB node also releases its BAP entity because the BAP configuration associated with the SCG is a unique BAP configuration present in the IAB node.

[0209] In one possible implementation, a reconfiguration message (specifically, an MR DC release and add mrdcReleaseAndAdd field included in the reconfiguration message) indicates to a first node to perform a multi-RAT dual connectivity release (MR DC release) process, where the first node is in a new radio standard dual connectivity (NR DC) mode. Before the first node releases its backhaul adaptation protocol (BAP) entity based on the reconfiguration message, a BAP configuration associated with a secondary cell group (SCG) has already been released, and the BAP configuration is the last successfully configured BAP configuration that exists only in the first node. According to the above method, the first node functions as an IAB node in the NR DC mode. When releasing the BAP configuration associated with the SCG, if the BAP configuration associated with the SCG is the unique or last BAP configuration that exists in the IAB node, the IAB node releases the BAP configuration and the BAP entity of the IAB node.

[0210] In one possible implementation, the reconfiguration message (specifically, an MR DC release and add (mrdc-ReleaseAndAdd) field included in the reconfiguration message) indicates that the IAB node is performing a multi-RAT dual connectivity MR DC release process and is in NR DC mode in an F1 interface control plane and F1 interface user plane split scenario. Additionally, the secondary node SN is the F1 interface terminating donor node of the IAB node, the master node MN is the non-F1 interface terminating node of the IAB node, and the IAB node is in NR DC mode. Before the first node releases its backhaul adaptation protocol (BAP) entity based on the reconfiguration message, the BAP configuration associated with the secondary cell group SCG has already been released, and the BAP configuration is a unique, successfully configured BAP configuration that exists only in the IAB node. According to the above method, the first node functions as an IAB node in NR DC mode in an F1 interface control plane and F1 interface user plane split scenario. When releasing the BAP configuration associated with the SCG, the IAB node releases the BAP configuration and the BAP entity of the IAB node because the BAP configuration associated with the SCG is a unique BAP configuration that exists in the IAB node.

[0211] In one possible implementation, the first node is an integrated access and backhaul (IAB) node or a mobile termination unit (IAB-MT) of the IAB node. According to the method described above, the IAB node or the IAB-MT may release the BAP configuration and the BAP entity of the IAB node or the IAB-MT based on the indication information from the network device.

[0212] In one possible implementation, the network device may be an IAB donor base station, an NR standard base station gNB, or an LTE standard base station eNB. The NR standard base station gNB may be a master node MN in NR DC mode, and the LTE standard base station eNB may be a master node eNB in ​​EN DC mode. According to the aforementioned method, the IAB donor base station, the master node MN in NR DC mode, or the master node MeNB in ​​EN DC mode may send an RRC reconfiguration message to the first node to instruct the first node to release the BAP configuration and the BAP entity of the first node.

[0213] The present application provides a communication method. The method includes a first node receiving a reconfiguration message from a network device, the reconfiguration message (including an MR DC release and add (mrdc-ReleaseAndAdd) field) instructing the first node to perform a multi-RAT dual connectivity release (MR DC release) process, the reconfiguration message being a radio resource control (RRC) reconfiguration message. The first node is in a new radio standard dual connectivity (NR DC) mode in an F1 interface control plane and F1 interface user plane non-split scenario, a first backhaul adaptation protocol (BAP) configuration and a second BAP configuration exist on the first node, the first BAP configuration is associated with a secondary cell group (SCG), and the second BAP configuration is associated with a master cell group (MCG). The first node releases the first BAP configuration based on the reconfiguration message and prohibits the release of the BAP entity of the first node. According to the above method, the first node functions as an IAB node in NR DC mode in an F1 interface control plane and F1 interface user plane non-split scenario. When only the BAP configuration associated with the SCG is released, the IAB node still retains its BAP entity to perform the BAP configuration associated with the MCG.

[0214] In one possible implementation, the first node is an integrated access and backhaul (IAB) node or a mobile termination part (IAB-MT) of the IAB node. According to the aforementioned method, the IAB node or the IAB-MT may release the BAP configuration of the IAB node or the IAB-MT based on the indication information from the network device, and at the same time, retain the BAP entity of the IAB node or the IAB-MT.

[0215] In one possible implementation, the network device may be an IAB donor base station, an NR standard base station gNB, or an LTE standard base station eNB. The NR standard base station gNB may be a master node MN in NR DC mode, and the LTE standard base station eNB may be a master node eNB in ​​EN DC mode. According to the aforementioned method, the IAB donor base station, the master node MN in NR DC mode, or the master node MeNB in ​​EN DC mode may send an RRC reconfiguration message to the first node to instruct the first node to release the BAP configuration and the BAP entity of the first node.

[0216] The following provides a specific method for determining, by an IAB node, whether to release the BAP entity of the IAB node, according to one embodiment of the present application.

[0217] S501: As shown in Figure 26, the IAB-MT receives an RRC reconfiguration message (RRCReconfiguration) or an RRC connection reconfiguration message (RRCConnectionReconfiguration) from a network device. The network device may be an IAB donor in this application, a 5G base station gNB, or an LTE base station eNB. The gNB may be a master node gNB of the IAB in the NR DC mode, and the eNB may be a master node eNB of the IAB in the EN DC mode.

[0218] S502: If the bap-Config field included in the RRC reconfiguration message or the RRC connection reconfiguration message is set to "release" and the IAB node only has a unique configured backhaul adaptation protocol BAP configuration (i.e., bap-Config), the IAB-MT releases the BAP entity of the IAB node. The unique configured bap-Config is equal to the last configured bap-Config on the IAB node. The last configured bap-Config on the IAB node includes the last configured BAP configuration bap-Config that exists only on the IAB node after the IAB node receives multiple BAP configurations. The unique configured bap-Config fully corresponds to the functionality of the BAP entity of the IAB node.

[0219] As shown in FIG. 27, for step S601, please refer to the description of step S501. Step S502 may be replaced by step S602: the IAB-MT initiates the MR DC release process based on the indication information (e.g., the endc-ReleaseAndAdd field) included in the RRC reconfiguration message received from the network device MeNB. If the IAB node is in the EN DC mode (as shown in FIG. 22 or FIG. 24), the IAB-MT not only releases the BAP configuration (bap-Config) associated with the SCG, but also releases the BAP entity of the IAB node. The EN DC mode includes the secondary node SgNB being the F1-terminating donor node of the IAB node and the secondary cell group SCG being an NR cell. The BAP configuration (bap-config) associated with the SCG can be a unique configured bap-config existing on the IAB node or the last configured bap-Config on the IAB node. The last configured bap-Config on an IAB node contains the last configured BAP configuration bap-Config that is only present on the IAB node after the IAB node has received multiple BAP configurations. The BAP configuration bap-Config associated with an SCG fully corresponds to the capabilities of the BAP entity of the IAB node.

[0220] As shown in FIG. 28, for step S701, please refer to the description of step S501. Step S502 may be replaced by step S702: the IAB-MT initiates the MR DC release process based on the indication information (e.g., the endc-ReleaseAndAdd field) included in the RRC reconfiguration message received from the network device MgNB. If the IAB node is in NR DC mode and the BAP configuration bap-Config associated with the SCG is the last configured BAP configuration bap-Config existing in the IAB node, the IAB-MT not only releases the BAP configuration bap-Config associated with the SCG, but also releases the BAP entity in the IAB node. The last configured bap-Config on the IAB node includes the last configured bap-Config existing only on the IAB node after the IAB node has received multiple BAP configurations. The last configured bap-Config existing on the IAB node fully corresponds to the functionality of the BAP entity in the IAB node.

[0221] As shown in Figure 29, for step S801, please refer to the description of step S501. Step S502 may be replaced by step S802: the IAB-MT performs the MR DC release process based on the indication information (e.g., the mrdc-ReleaseAndAdd field) in the RRC reconfiguration message received from the network device MgNB. When the IAB node is in the NR DC mode in the F1 interface CP-UP split scenario (as shown in Figure 23 or Figure 25), the secondary node SN is the F1 interface terminating donor node of the IAB node, and the master node MN or MgNB is the non-F1 interface terminating node of the IAB node, the IAB-MT not only releases the BAP configuration bap-Config associated with the SCG, but also releases the BAP entity of the IAB node. The BAP configuration bap-config associated with the SCG can be a unique configured bap-config existing on the IAB node or the last configured bap-Config on the IAB node. The last configured bap-Config on an IAB node contains the last configured BAP configuration bap-Config that is only present on the IAB node after the IAB node has received multiple BAP configurations. The BAP configuration bap-Config associated with an SCG fully corresponds to the capabilities of the BAP entity of the IAB node.

[0222] In another implementation, the IAB-MT performs the MR DC release process based on the indication information (e.g., the mrdc-ReleaseAndAdd field) in the RRC reconfiguration message from the network device MgNB. If the IAB node is in the F1 interface CP-UP non-split NR DC mode (as shown in Figure 21) and the IAB node has two configured BAP configurations (bap-Config) (associated with the SCG and the MCG, respectively), the IAB-MT releases only the BAP configuration (bap-Config) associated with the SCG and does not release the BAP entity of the IAB-MT. Both configured BAP configurations (bap-Config) (associated with the SCG and the MCG, respectively) are used to configure the functionality of the BAP entity of the IAB node.

[0223] In the foregoing embodiments provided in the present application, the methods provided in the embodiments of the present application are described separately in terms of interactions between devices such as a CU, a first DU, a second DU, and a terminal, and interactions between devices such as a first node and a network device. To implement the functions in the methods provided in the embodiments of the present application, devices such as a CU, a first DU, a second DU, a terminal, a first node, and a network device may each include a hardware structure and a software module, and may implement the above-mentioned functions in the form of a hardware structure, a software module, or a hardware structure + software module. One of the various functions described above may be implemented in the form of a hardware structure, a software module, or a combination of a hardware structure and a software module.

[0224] 30 is a diagram of the structure of a communication device 900 according to an embodiment of the present application. The communication device 900 may correspondingly implement functions or steps performed by devices such as a CU, a first DU, a second DU, a terminal, a first node, or a network device in the above-mentioned method embodiments.

[0225] The communication device 900 may include a transceiver unit 901 and a processing unit 902. Optionally, a storage unit may be further included. The storage unit may be configured to store instructions (codes or programs) and / or data. The transceiver unit 901 or the processing unit 902 may be coupled to the storage unit. For example, the processing unit 902 may read the instructions (codes or programs) and / or data in the storage unit and perform a corresponding method. The aforementioned units may be independently located or may be partially or fully integrated. Optionally, the transceiver unit 901 may include a transmitting unit or a receiving unit. The transmitting unit is configured to perform a transmitting operation, and the receiving unit is configured to perform a receiving operation.

[0226] The processing unit 902 may be a processor or controller, such as a general-purpose central processing unit (CPU), a general-purpose processor, a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field programmable gate array (FPGA), or another programmable logic device, transistor logic device, hardware component, or combination thereof. The processing unit 902 may implement or execute various exemplary logic blocks, units, or circuits described in connection with the subject matter disclosed herein. Alternatively, the processor may be a combination of processors that perform computer functions, such as a combination of one or more microprocessors, or a combination with a DSP or microprocessor. The transceiver unit 901 is an interface circuit of the device and is configured to receive signals from other devices. For example, if the device is implemented in the form of a chip, the transceiver unit 901 is an interface circuit used by the chip to receive signals from another chip or device, or an interface circuit used by the chip to transmit signals to another chip or device.

[0227] The communication device 900 may be a CU, a first DU, a second DU, a terminal, a first node, or a network device in the above embodiments, or may be a chip used in a CU, a first DU, a second DU, a terminal, a first node, or a network device.

[0228] For example, if the communication device 900 is a CU, a first DU, a second DU, a terminal, a first node, or a network device, the processing unit 902 may be, for example, a processor, and the transceiver unit 901 may be, for example, a transceiver. Optionally, the transceiver may include a radio frequency circuit or an input / output interface, and the storage unit may be, for example, a memory. For example, if the communication device 900 is a chip used in a CU, a first DU, a second DU, a terminal, a first node, or a network device, the processing unit 902 may be, for example, a processor, and the transceiver unit 901 may be, for example, an input / output interface, a pin, or a circuit.

[0229] The processing unit 902 may execute computer-executable instructions stored in a memory unit. Optionally, the memory unit is a memory unit within the chip, such as a register or a cache. Alternatively, the memory unit may be within the CU, the first DU, the second DU, the terminal, the first node, or the network device, and may be a memory unit located outside the chip, such as a read-only memory (ROM), another type of static storage device capable of storing static information or instructions, or a random access memory (RAM).

[0230] In some embodiments, the communication device 900 may correspondingly implement the behavior and functions of the first DU in the above-described method embodiments. For example, the communication device 900 may be the first DU or a component (e.g., a chip or circuit) used in the first DU.

[0231] The transceiver unit 901 may be configured to support communication between the first DU and another network entity, for example, to support communication between the first DU and a CU, a second DU, a terminal, etc., shown in Figures 11 to 15. The processing unit 902 is configured to control and manage operation of the first DU. For example, the processing unit 902 is configured to support the first DU in performing operations other than transmission and reception of the first DU in Figures 11 to 15.

[0232] In one embodiment, the transceiver unit 901 is configured to receive data of the terminal from the central unit CU.

[0233] The processing unit 902 is configured to process the data using a terminal-specific medium access control MAC entity scheduling function to obtain a physical layer transmission data stream.

[0234] The transceiver unit 901 is further configured to transmit the physical layer transmission data stream to a second DU.

[0235] In one possible implementation, the physical layer transmission data stream is a media access control protocol data unit MAC PDU.

[0236] In one possible implementation, the processing unit 902 is specifically configured to process data using a medium access control MAC entity scheduling function and a physical layer scheduling function for the terminal to obtain a physical layer transmission data stream, where the physical layer transmission data stream is one of a transport block TB, a code word CW, and a code block CB.

[0237] In one possible implementation form, the transceiver unit 901 is further configured to send physical layer transmission control information to the second DU, where the physical layer transmission control information includes one or more of the following: related parameter information of downlink control information DCI; related parameter information of TB, CB, or CW; parameter information of a modulation and coding scheme MCS; parameter information of a transmission power control TPC; status parameter information of a transmission configuration indicator TCI; parameter information of a precoding matrix indication PMI; parameter information of an antenna port; related parameter information of a time-frequency position and search space Searchspace of a physical downlink control channel PDCCH for a terminal in a control resource set CORESET; information about a data scrambling identifier of a physical downlink shared channel PDSCH; and information about a radio network temporary identifier RNTI.

[0238] In one possible implementation, the transceiver unit 901 is further configured to receive uplink control information UCI from the second DU, where the UCI includes one or more of the following: a buffer status report BSR, a power headroom report PHR, a timing advance TA, and a measurement reference signal measurement result.

[0239] In one possible implementation form, the transceiver unit 901 is further configured to receive uplink feedback information from the second DU, where the uplink feedback information includes hybrid automatic repeat request (HARQ) reception status feedback information.

[0240] In one possible implementation form, the transceiver unit 901 is further configured to receive instruction information from the CU, where the instruction information includes an identifier of the terminal, and the instruction information instructs the first DU and the second DU to perform inter-DU cooperative transmission for the terminal.

[0241] It should be noted that in this embodiment, the communication device can perform the relevant steps of the first DU in the method embodiments shown in Figures 11 to 13. For details, please refer to the implementation forms provided in the preceding steps. The details will not be described again in this specification.

[0242] In another embodiment, the transceiver unit 901 is configured to perform the operations of receiving indication information from the central unit CU, where the indication information instructs a terminal to initiate contention-free random access to the second DU, transmitting the indication information to the terminal, and receiving a random access message 1 Msg1 from the second DU.

[0243] The processing unit 902 is configured to generate a random access message 2 Msg2 based on Msg1.

[0244] The transceiver unit 901 is further configured to transmit Msg2 to the terminal.

[0245] In one possible implementation, the indication information indicates a dedicated preamble to be used for contention-free random access, and Msg1 includes the dedicated preamble. Alternatively, the indication information indicates a dedicated random access resource to be used for contention-free random access, and the transceiver unit 901 is specifically configured to receive Msg1 from the second DU using the dedicated random access resource. Alternatively, the indication information indicates a dedicated preamble and a dedicated random access resource, and the transceiver unit 901 is specifically configured to receive Msg1 from the second DU using the dedicated random access resource, and Msg1 includes the dedicated preamble.

[0246] It should be noted that in this embodiment, the communication device may perform the relevant steps of the first DU in the method embodiment shown in Figure 14. For details, please refer to the implementation forms provided in the preceding steps. The details will not be described again in this specification.

[0247] In another embodiment, the transceiver unit 901 is configured to receive a random access message 1 Msg1 from the second DU.

[0248] The processing unit 902 is configured to generate a random access message 2 Msg2 based on Msg1.

[0249] The transceiver unit 901 is further configured to perform the following operations: sending Msg2 to the terminal; receiving a random access message 3 Msg3 from the second DU; sending Msg3 to the central unit CU; receiving Msg4 from the CU; and sending Msg4 to the terminal.

[0250] In a possible implementation, the transceiver unit 901 is further configured to perform the following operations: receiving a Random Access Radio Network Temporary Identifier (RA-RNTI) value of a secondary cell from a second DU, where there is a correspondence between the secondary cell and the second DU, and the RA-RNTI value is used to determine a time-frequency location of a first Physical Downlink Control Channel (PDCCH) for scheduling Msg2 and a time-frequency location of a first Physical Downlink Shared Channel (PDSCH) for transmitting data information of Msg2, and is used for data scrambling of the first PDCCH.

[0251] In one possible implementation, the response time window for monitoring the first PDCCH or random access response is greater than 80 slots.

[0252] In a possible implementation form, the transceiver unit 901 is specifically configured to transmit Msg2 to the terminal via the second DU.

[0253] In a possible implementation form, the transceiver unit 901 is specifically configured to transmit Msg4 to the terminal via the second DU.

[0254] In one possible implementation, the maximum duration of the timer for monitoring Msg4 is greater than the duration of 64 subframes.

[0255] It should be noted that in this embodiment, the communication device may perform the relevant steps of the first DU in the method embodiment shown in Figure 15. For details, please refer to the implementation forms provided in the preceding steps. The details will not be described again in this specification.

[0256] In some embodiments, the communication device 900 can correspondingly implement the behavior and functions of the second DU in the above-described method embodiments. For example, the communication device 900 may be the second DU or a component (e.g., a chip or circuit) used in the second DU.

[0257] The transceiver unit 901 may be configured to support communication between the second DU and another network entity, for example, to support communication between the second DU and a CU, a first DU, a terminal, etc., as shown in Figures 11 to 15. The processing unit 902 is configured to control and manage operation of the second DU. For example, the processing unit 902 is configured to support the second DU in performing operations other than transmission and reception of the second DU in Figures 11 to 15.

[0258] In one embodiment, the transceiver unit 901 is configured to perform the following operations: receiving a physical layer transmission data stream from a first DU; and transmitting the physical layer transmission data stream to a terminal.

[0259] In one possible implementation, the physical layer transmission data stream is one of the following: a media access control protocol data unit MAC PDU, a transport block TB, a code word CW, and a code block CB.

[0260] In one possible implementation, the second DU prohibits the terminal-specific MAC entity scheduling function from being enabled.

[0261] In one possible implementation form, the transceiver unit 901 is further configured to receive physical layer transmission control information from the first DU, where the physical layer transmission control information includes one or more of the following: related parameter information of downlink control information DCI; related parameter information of TB, CB, or CW; parameter information of a modulation and coding scheme MCS; parameter information of a transmission power control TPC; status parameter information of a transmission configuration indicator TCI; parameter information of a precoding matrix indication PMI; parameter information of an antenna port; related parameter information of a time-frequency position and search space Searchspace of a physical downlink control channel PDCCH for a terminal in a control resource set CORESET; information about a data scrambling identifier of a physical downlink shared channel PDSCH; and information about a radio network temporary identifier RNTI.

[0262] In one possible implementation form, the transceiver unit 901 is specifically configured to: determine a time-frequency position of a PDCCH corresponding to a terminal based on related parameter information of a search space and a time-frequency position of a PDCCH of the terminal in a CORESET in the physical layer transmission control information; determine a time-frequency position of a PDSCH based on related parameter information of a DCI in the physical layer transmission control information; transmit the DCI scrambled using the RNTI to the terminal via the PDCCH, where the DCI indicates the PDSCH; and transmit a physical layer transmission data stream scrambled using a data scrambling identifier of the PDSCH to the terminal via the PDSCH.

[0263] In one possible implementation, the transceiver unit 901 is further configured to receive uplink control information UCI from the terminal, where the UCI includes one or more of the following: a buffer status report BSR, a power headroom report PHR, a timing advance TA, and a measurement reference signal measurement result. The second DU sends the UCI to the first DU.

[0264] In one possible implementation, the transceiver unit 901 is further configured to receive uplink feedback information from the terminal, where the uplink feedback information includes hybrid automatic repeat request (HARQ) reception status feedback information. The second DU transmits the uplink feedback information to the first DU.

[0265] In one possible implementation form, the transceiver unit 901 is further configured to receive instruction information from the CU, where the instruction information includes an identifier of the terminal, and the instruction information instructs the second DU and the first DU to perform inter-DU cooperative transmission for the terminal.

[0266] It should be noted that in this embodiment, the communication device can perform the relevant steps of the first DU in the method embodiments shown in Figures 11 to 13. For details, please refer to the implementation forms provided in the preceding steps. The details will not be described again in this specification.

[0267] In another embodiment, the transceiver unit 901 is configured to receive a random access message 1 Msg1 from a terminal, where Msg1 is generated in response to indication information, where the indication information instructs the terminal to initiate contention-free random access to a second DU and transmit Msg1 to the first DU.

[0268] In one possible implementation, the indication information indicates a dedicated preamble to be used for contention-free random access, and Msg1 includes the dedicated preamble. Alternatively, the indication information indicates a dedicated random access resource to be used for contention-free random access, and the transceiver unit 901 is specifically configured to receive Msg1 from the terminal using the dedicated random access resource. Alternatively, the indication information indicates a dedicated preamble and a dedicated random access resource, and the transceiver unit 901 is specifically configured to receive Msg1 from the terminal using the dedicated random access resource, and Msg1 includes the dedicated preamble.

[0269] It should be noted that in this embodiment, the communication device may perform the relevant steps of the first DU in the method embodiment shown in Figure 14. For details, please refer to the implementation forms provided in the preceding steps. The details will not be described again in this specification.

[0270] In another embodiment, the transceiver unit 901 is configured to receive a random access message 1 Msg1 from the terminal, send the Msg1 to the first DU, send a random access radio network temporary identifier RA-RNTI value of a secondary cell to the first DU, where there is a correspondence relationship between the secondary cell and the second DU, the RA-RNTI value being used to determine a time-frequency location of a first physical downlink control channel PDCCH for scheduling the random access message 2 Msg2 and a time-frequency location of a first physical downlink shared channel PDSCH for transmitting data information of Msg2, and being used for data scrambling of the first PDCCH, receive a random access message 3 Msg3 from the terminal, and send the Msg3 to the first DU.

[0271] In a possible implementation, the processing unit 902 is specifically configured to determine a time-frequency location of the first PDCCH and a time-frequency location of the first PDSCH based on the RA-RNTI value. The transceiver unit 901 is further configured to receive Msg2 from the first DU, send a first DCI to the terminal via the first PDCCH, where the first DCI is scrambled based on the RA-RNTI value, and the first DCI indicates the time-frequency location of the first PDSCH, and send data information of Msg2 to the terminal via the first PDSCH.

[0272] In one possible implementation, the response time window for monitoring the first PDCCH or Msg2 is greater than 80 slots.

[0273] In a possible implementation, the transceiver unit 901 is further configured to receive a random access message 4 Msg4 from the first DU, a search space of a second PDCCH for scheduling Msg4 being configured for the second DU, the second PDCCH being used for transmitting second downlink control information DCI for scheduling the second PDSCH, the second PDSCH being used for transmitting data information of Msg4, transmitting the second DCI to the terminal via the second PDCCH, the second DCI being scrambled based on a temporary cell radio network temporary identifier TC-RNTI, the TC-RNTI being included in Msg2, the second DCI indicating the second PDSCH, and transmitting the data information of Msg4 to the terminal via the second PDSCH.

[0274] In one possible implementation, the maximum duration of the timer for monitoring the second PDCCH or Msg4 is greater than the duration of 64 subframes.

[0275] It should be noted that in this embodiment, the communication device may perform the relevant steps of the first DU in the method embodiment shown in Figure 15. For details, please refer to the implementation forms provided in the preceding steps. The details will not be described again in this specification.

[0276] In some embodiments, the communication device 900 may correspondingly implement the behavior and functionality of a first node in the method embodiments. For example, the communication device 900 may be the first node or a component (e.g., a chip or circuit) used in the first node.

[0277] The transceiver unit 901 may be configured to support communication between the first node and another network entity, such as, for example, the first node and a network device shown in Figures 16 to 29. The processing unit 902 is configured to control and manage operation of the first node. For example, the processing unit 902 is configured to support the first node in performing operations other than transmitting and receiving of the first node in Figures 16 to 29.

[0278] In one embodiment, the transceiver unit 901 is configured to receive a reconfiguration message from a network device, where the reconfiguration message is a radio resource control (RRC) reconfiguration message or an RRC connection reconfiguration message.

[0279] The processing unit 902 is configured to release a backhaul adaptation protocol BAP entity of the first node based on the reconfiguration message.

[0280] In one possible implementation, the reconfiguration message (the BAP configuration (bap-Config) field included in the reconfiguration message is set to release) indicates that the BAP configuration of the communication device is to be released, and a unique successfully configured BAP configuration exists only in the communication device.

[0281] In one possible implementation, the reconfiguration message (including an EN DC release and add (endc-ReleaseAndAdd) field) instructs the communication device, which is in an Evolved Universal Terrestrial Radio Access (E-UTRA) standard and New Radio NR standard dual connectivity (EN DC) mode, to perform a multi-RAT dual connectivity MR DC release process. Before a backhaul adaptation protocol (BAP) entity of the communication device is released based on the reconfiguration message, a BAP configuration associated with a secondary cell group (SCG) has already been released.

[0282] In one possible implementation, the reconfiguration message (including the MR DC release and add mrdcReleaseAndAdd fields) instructs the communication device, which is in New Radio NR Standard Dual Connectivity (NR DC) mode, to perform a multi-RAT dual connectivity release (MR DC release) process. Before the backhaul adaptation protocol (BAP) entity of the communication device is released based on the reconfiguration message, a BAP configuration associated with the secondary cell group SCG has already been released, and the BAP configuration is the last successfully configured BAP configuration present only on the communication device.

[0283] In one possible implementation, the reconfiguration message (MR DC Release and Add (mrdc-ReleaseAndAdd) field) indicates an IAB node that performs a multi-RAT dual connectivity MR DC release process and is in NR DC mode in an F1 interface control plane and F1 interface user plane split scenario. In addition, the secondary node SN is the F1 interface terminating donor node of the IAB node, the master node MN is the non-F1 interface terminating node of the IAB node, and the IAB node is in NR DC mode. Before the backhaul adaptation protocol (BAP) entity of the communication device is released based on the reconfiguration message, the BAP configuration associated with the secondary cell group SCG has already been released, and the BAP configuration is a unique successfully configured BAP configuration that exists only on the IAB node.

[0284] In one possible implementation, the communication device is an integrated access and backhaul (IAB) node or a mobile termination of an IAB node (IAB-MT).

[0285] In one possible implementation, the network device may be an IAB donor base station, an NR standard base station gNB, or an LTE standard base station eNB. The NR standard base station gNB may be a master node MN in the NR DC mode, and the LTE standard base station eNB may be a master node eNB in ​​the EN DC mode.

[0286] It should be noted that in this embodiment, the communication device can perform the related steps of the first node in the method embodiments shown in Figures 26 to 29. For details, please refer to the implementation forms provided in the preceding steps. The details will not be described again in this specification.

[0287] In another embodiment, the transceiver unit 901 is configured to receive a reconfiguration message from a network device, the reconfiguration message (including an MR DC Release and Add (mrdc-ReleaseAndAdd) field) instructing the communication device to perform a multi-RAT dual connectivity release (MR DC release) process, the reconfiguration message being a radio resource control (RRC) reconfiguration message, the communication device being in a new radio standard dual connectivity (NR DC) mode in an F1 interface control plane and F1 interface user plane non-split scenario, a first backhaul adaptation protocol (BAP) configuration and a second BAP configuration present on the communication device, the first BAP configuration being associated with a secondary cell group (SCG), and the second BAP configuration being associated with a master cell group (MCG).

[0288] The processing unit 902 is configured to release the first BAP configuration based on the reconfiguration message and prohibit releasing the BAP entity of the communication device.

[0289] In one possible implementation, the communication device is an integrated access and backhaul (IAB) node or a mobile termination part (IAB-MT) of the IAB node. According to the aforementioned method, the IAB node or the IAB-MT may release the BAP configuration of the IAB node or the IAB-MT based on the indication information from the network device, and at the same time, retain the BAP entity of the IAB node or the IAB-MT.

[0290] In one possible implementation, the network device may be an IAB donor base station, an NR standard base station gNB, or an LTE standard base station eNB. The NR standard base station gNB may be a master node MN in the NR DC mode, and the LTE standard base station eNB may be a master node eNB in ​​the EN DC mode.

[0291] 31 is a diagram of the structure of a communication device 1000 according to an embodiment of the present application. The communication device 1000 may be a CU, a first DU, a second DU, a terminal, a first node, or a network device, and may perform the functions or steps of the CU, the first DU, the second DU, the terminal, the first node, or the network device in the methods provided in the embodiments of the present application. The communication device 1000 may be a chip system. In the embodiments of this application, the chip system may include a chip, or may include a chip and other individual components.

[0292] The communication device 1000 includes at least one processor 1002. The processor 1002 may be a CPU, a microprocessor, an ASIC, or one or more integrated circuits configured to control program execution of the solutions in the present application, and is configured to implement or support the communication device 1000 in performing the functions of a control plane network element, a terminal device, or an access network device of a private network, or the functions of a mobility management network element of a public network, in the methods provided in the embodiments of the present application. For details, please refer to the detailed description in the method examples. Details will not be described again in this specification.

[0293] The communication device 1000 may further include at least one memory 1001 configured to store program instructions and / or data. The memory 1001 is coupled to the processor 1002. The coupling in the embodiments of the present application may be an indirect coupling or communication connection between devices, units, or modules in an electrical, mechanical, or other form, used for information exchange between the devices, units, or modules. The processor 1002 may cooperate with the memory 1001. The processor 1002 may execute the program instructions and / or data stored in the memory 1001 such that the communication device 1000 performs a corresponding method. At least one of the at least one memory may be included in the processor 1002.

[0294] The communication device 1000 may further include a communication interface 1003, configured to communicate with another device or a communication network, such as an Ethernet, a radio access network (RAN), a wireless local area network (WLAN), or a wired access network, using any device such as a transceiver. The communication interface 1003 is configured to communicate with other devices via a transmission medium, allowing devices within the communication device 1000 to communicate with other devices. For example, if the communication device 1000 is a private network element, the other device may be a public network element, a private user plane network element, an access network device, or a terminal device. Alternatively, if the communication device is a public network element, the other device may be a private network element (a private session management network element or a private authentication network element), a private user plane network element, an access network device, or a terminal device. The processor 1002 may transmit and receive data via the communication interface 1003. The communication interface 1003 may specifically be a transceiver.

[0295] The specific connection medium between the communication interface 1003, the processor 1002, and the memory 1001 is not limited in this embodiment of the present application. In this embodiment of the present application, in FIG. 31, the memory 1001, the processor 1002, and the communication interface 1003 are connected to each other via a bus 1004. In FIG. 31, the bus is represented by a thick line. The connection method between the other components is merely an example for explanation and is not intended to be limiting. The bus may be classified as an address bus, a data bus, a control bus, etc. For ease of explanation, only one thick line is used in FIG. 31 to represent a bus, but this does not mean that there is only one bus or only one type of bus.

[0296] In this embodiment of the present application, the processor 1002 may be a general-purpose processor, a digital signal processor, an application-specific integrated circuit, a field programmable gate array or other programmable logic device, a discrete gate or transistor logic device, or a discrete hardware component, and may implement or perform the methods, steps, and logic block diagrams disclosed in the embodiments of the present application. The general-purpose processor may be a microprocessor, any conventional processor, etc. The steps of the methods disclosed with reference to the embodiments of the present application may be performed directly by a hardware processor, or may be performed by a combination of hardware and software units in the processor.

[0297] The memory 1001 may be a ROM, another type of static storage device capable of storing static information and instructions, a RAM, or another type of dynamic storage device capable of storing information and instructions, or may be an electrically erasable programmable read-only memory (EEPROM), a compact disc read-only memory (CD-ROM) or other compact disc storage device, an optical disc storage device (including compact discs, laser discs, optical discs, digital versatile discs, Blu-ray discs, etc.), a magnetic disc storage medium or other magnetic storage device, or any other medium that can be configured to carry or store expected program code in the form of instructions or data structures and that can be accessed by a computer. However, the memory 1001 is not limited in this respect. The memory may exist independently or be connected to the processor via bus 1004. Alternatively, the memory may be integrated with the processor.

[0298] The memory 1001 is configured to store computer-executable instructions for implementing the solution of the present application, and the processor 1002 controls the execution. The processor 1002 is configured to execute the computer-executable instructions stored in the memory 1001 to implement the method for separating public network services from private network services provided in the aforementioned embodiments of the present application.

[0299] Optionally, the computer-executable instructions in this embodiment of the present application may be referred to as application program code, which is not specifically limited in this embodiment of the present application.

[0300] For cases where the communication device can be a chip or a chip system, please refer to the diagram of the chip structure shown in Figure 32. The chip 110 shown in Figure 32 includes a processor 1101 and an interface 1102. There may be one or more processors 1101, and there may be multiple interfaces 1102.

[0301] In the embodiment of the present application, when the chip is configured to perform the functions of the first DU,

[0302] In one embodiment, the processor 1101 is configured to receive data of the terminal from the central unit CU via the interface 1102 .

[0303] The processor 1101 is configured to process data using a terminal-specific medium access control MAC entity scheduling function to obtain a physical layer transmission data stream.

[0304] The processor 1101 is configured to send the physical layer transmission data stream to the second DU via the interface 1102.

[0305] In another embodiment, the processor 1101 is configured to perform the following operations: receiving, via the interface 1102, indication information from the central unit CU, where the indication information instructs a terminal to initiate contention-free random access to the second DU; transmitting the indication information to the terminal; and receiving a random access message 1 Msg1 from the second DU.

[0306] The processor 1101 is configured to generate a random access message 2 Msg2 based on Msg1.

[0307] The processor 1101 is further configured to send Msg2 to the terminal via the interface 1102.

[0308] In another embodiment, the processor 1101 is configured to receive a random access message 1 Msg1 from the second DU via the interface 1102.

[0309] The processor 1101 is configured to generate a random access message 2 Msg2 based on Msg1.

[0310] The processor 1101 is further configured to perform the following operations via the interface 1102: sending Msg2 to the terminal, receiving a random access message 3 Msg3 from the second DU, sending Msg3 to the central unit CU, receiving Msg4 from the CU, and sending Msg4 to the terminal.

[0311] In the embodiment of the present application, when the chip is configured to perform the functions of the second DU,

[0312] In one embodiment, the processor 1101 is configured to receive a physical layer transmission data stream from the first DU via the interface 1102 and send the physical layer transmission data stream to the terminal.

[0313] In another embodiment, the processor 1101 is configured to perform the following operations via the interface 1102: receive a random access message 1 Msg1 from a terminal, where Msg1 is generated in response to indication information, the indication information instructing the terminal to initiate contention-free random access to a second DU; and send Msg1 to the first DU.

[0314] In another embodiment, the processor 1101 is configured to perform the following operations via the interface 1102: receiving a random access message 1 Msg1 from the terminal; transmitting Msg1 to the first DU; transmitting a random access radio network temporary identifier RA-RNTI value of the secondary cell to the first DU, where there is a correspondence between the secondary cell and the second DU, and the RA-RNTI value is used to determine a time-frequency location of a first physical downlink control channel PDCCH for scheduling the random access message 2 Msg2 and a time-frequency location of a first physical downlink shared channel PDSCH for transmitting data information of Msg2, and is used for data scrambling of the first PDCCH; receiving a random access message 3 Msg3 from the terminal; and transmitting Msg3 to the first DU.

[0315] In the embodiment of the present application, when the chip is configured to perform the functions of the first node,

[0316] In one embodiment, the processor 1101 is configured to receive a reconfiguration message from a network device via the interface 1102, the reconfiguration message being a radio resource control (RRC) reconfiguration message or an RRC connection reconfiguration message.

[0317] The processor 1101 is configured to release a backhaul adaptation protocol BAP entity of the first node based on the reconfiguration message.

[0318] In another embodiment, the processor 1101 is configured to receive a reconfiguration message from a network device via the interface 1102, the reconfiguration message (including an MR DC release and add (mrdc-ReleaseAndAdd) field) instructing the chip to perform a multi-RAT dual connectivity release (MR DC release) process, the reconfiguration message being a radio resource control (RRC) reconfiguration message, the chip being in a new radio standard dual connectivity (NR DC) mode in an F1 interface control plane and F1 interface user plane non-split scenario, a first backhaul adaptation protocol (BAP) configuration and a second BAP configuration present on the chip, the first BAP configuration being associated with a secondary cell group (SCG), and the second BAP configuration being associated with a master cell group (MCG).

[0319] The processor 1101 is configured to release the first BAP configuration based on the reconfiguration message and inhibit the release of the BAP entity of the chip.

[0320] Optionally, the chip further includes a memory 1103, which is configured to store program instructions and data.

[0321] An embodiment of the present application further provides a communication system. Specifically, the communication system includes a first DU and a second DU. For example, the communication system includes the first DU and the second DU configured to perform the relevant functions of Figures 11 to 15.

[0322] An embodiment of the present application further provides a computer-readable storage medium containing instructions, which, when executed on a computer, enable the computer to perform the methods performed by the first DU, the second DU, or the first node in Figures 11 to 15 and 26 to 29.

[0323] An embodiment of the present application further provides a computer program product including instructions, which, when executed on a computer, enable the computer to perform the methods performed by the first DU, the second DU, or the first node in Figures 11 to 15 and 26 to 29.

[0324] An embodiment of the present application provides a chip system. The chip system includes a processor and may further include a memory, and is configured to perform the functions of the first DU, the second DU, or the first node in the above-described method. The chip system may include a chip, or may include a chip and another individual component.

[0325] All or part of the above-described embodiments may be implemented using software, hardware, firmware, or any combination thereof. When software is used to implement the above-described embodiments, all or part of the above-described embodiments may be implemented in the form of a computer program product. The computer program product includes one or more computer instructions. When the computer instructions are loaded into a computer and executed, the procedures or functions according to the embodiments of the present application are generated in whole or in part. The computer may be a general-purpose computer, a special-purpose computer, a computer network, or another programmable device. The computer instructions may be stored in a computer-readable storage medium, or the computer instructions may be transmitted from one computer-readable storage medium to another. For example, the computer instructions may be transmitted from a website, computer, server, or data center to another website, computer, server, or data center via wired (e.g., coaxial cable, optical fiber, or digital subscriber line (DSL)) or wireless (e.g., infrared, radio, or microwave) methods. The computer-readable storage medium may be any available medium that can be accessed by a computer, or a data storage device, such as a server or data center, that incorporates one or more available media. The available medium may be magnetic media (e.g., floppy disks, hard disks, or magnetic tapes), optical media (e.g., high-density digital video discs (DVDs)), semiconductor media (e.g., solid-state disks (SSDs)), etc.

[0326] Those skilled in the art can understand that the various numerical values ​​such as first and second in this specification are distinguished merely for ease of explanation and are not intended to limit the scope and order of the embodiments of the present application.

[0327] "Predefine" in this application may be understood as "define," "predefine," "store," "prestore," "prenegotiate," "preconfigure," "fix," or "predischarge."

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

[0329] For ease of description, it is clearly understood by those skilled in the art that the detailed operation processes of the aforementioned systems, devices and units should be referred to the corresponding processes in the aforementioned method embodiments, and the details will not be described again in this specification.

[0330] The above description is merely a specific implementation of the present application. However, the scope of protection of the present application is not limited thereto. Any modifications or replacements that can be easily conceived by those skilled in the art within the technical scope disclosed in the present application shall fall within the scope of protection of the present application. Therefore, the scope of protection of the present application shall be subject to the scope of protection of the claims. [Explanation of symbols]

[0331] 900 Communication Equipment 901 Transceiver Unit 902 Processing Unit 1000 Communication Equipment 1001 memory 1002 processor 1003 Communication Interface 1004 Bus 110 chips 1101 processor 1102 Interface 1103 Memory

Claims

1. 1. A communication method comprising: receiving, by a first node, a reconfiguration message from a network device, the reconfiguration message being a Radio Resource Control (RRC) reconfiguration message or an RRC connection reconfiguration message; releasing, by the first node, a Backhaul Adaptation Protocol (BAP) entity of the first node based on the reconfiguration message; Including, the first node is an integrated access and backhaul (IAB) node or an IAB node mobile termination (IAB-MT); A unique, successfully configured BAP configuration exists only on said first node; the reconfiguration message indicates releasing the BAP configuration of the first node; the first node is in an Evolved Universal Terrestrial Radio Access (E-UTRA) and New Radio (NR) Dual Connectivity (EN DC) mode, and the reconfiguration message instructs the first node to perform a Multi-RAT Dual Connectivity (MR DC) release process; Before the step of releasing, by the first node, a BAP entity of the first node based on the reconfiguration message, the method further comprises: Releasing, by the first node, a BAP configuration associated with a secondary cell group (SCG). The method further comprises:

2. A communication method, comprising: receiving, by a first node, a reconfiguration message from a network device, the reconfiguration message being a Radio Resource Control (RRC) reconfiguration message or an RRC connection reconfiguration message; releasing, by the first node, a Backhaul Adaptation Protocol (BAP) entity of the first node based on the reconfiguration message; Including, the first node is an integrated access and backhaul (IAB) node or an IAB node mobile termination (IAB-MT); the first node is in a New Radio Dual Connectivity (NR DC) mode, and the reconfiguration message instructs the first node to perform an NR DC release process; Before the step of releasing, by the first node, a BAP entity of the first node based on the reconfiguration message, the method further comprises: Releasing, by the first node, a BAP configuration associated with a secondary cell group (SCG), the BAP configuration associated with the SCG being a last successfully configured BAP configuration that exists only in the first node. The method further comprises:

3. A communication method, comprising: receiving, by a first node, a reconfiguration message from a network device, the reconfiguration message being a Radio Resource Control (RRC) reconfiguration message or an RRC connection reconfiguration message; releasing, by the first node, a Backhaul Adaptation Protocol (BAP) entity of the first node based on the reconfiguration message; Including, the first node is an integrated access and backhaul (IAB) node or an IAB node mobile termination (IAB-MT); The first node is in a New Radio Dual Connectivity (NR DC) mode in an F1 interface control plane and F1 interface user plane split scenario, a secondary node (SN) is an F1 interface terminating donor node of the first node, a master node (MN) is a non-F1 interface terminating node of the first node, the first node is in an NR DC mode, and the reconfiguration message instructs the first node to perform a Multi-RAT Dual Connectivity (MR DC) release process; Before the step of releasing, by the first node, a BAP entity of the first node based on the reconfiguration message, the method further comprises: Releasing, by the first node, a BAP configuration associated with a secondary cell group (SCG), wherein the BAP configuration associated with the SCG is a unique, successfully configured BAP configuration that exists only in the first node. The method further comprises:

4. A communication device comprising means for carrying out the method according to any one of claims 1 to 3.

5. 4. A computer-readable storage medium configured to store instructions that, when executed, perform the method of any one of claims 1 to 3.

Images