Electronic device and method for communication between distributed units in wireless communication system

Abstract

In embodiments of the present disclosure, a method performed by a central unit (CU) is provided. The method may comprise the operations of: transmitting a first user data message to a first distributed unit (DU) for providing a primary cell (PCell) for carrier aggregation (CA); and transmitting a second user data message to a second DU for providing a secondary cell (SCell) for the CA. The first user data message may include information on a sequence number (SN) of a starting packet data convergence protocol (PDCP) protocol data unit (PDU) and information on a wrap-around count of the SN of the PDCP PDU in the first DU. The second user data message may include information on the SN of the starting PDCP PDU and information on the wrap-around count of the SN of the PDCP PDU. Hereinafter, in the present disclosure, the SN indicates the sequence number of a PDU including an SDU. For example, the SN of the SDU may indicate the SN of the header of a PDU including the SDU.

Description

Electronic device and method for communication between distributed units in a wireless communication system

[0001] The present disclosure relates to a wireless communication system, and more particularly, to an electronic device and method for communication between distributed units in a wireless communication system.

[0002] 4G(4 th To meet the increasing demand for wireless data traffic since the commercialization of the 5G (5 generation) communication system, the improved 5G (5 th Efforts are being made to develop 5G communication systems or pre-5G communication systems. For this reason, 5G communication systems or pre-5G communication systems are also called Beyond 4G Network communication systems or Post-LTE systems.

[0003] To achieve high data rates, 5G communication systems are being considered for implementation in ultra-high frequency (mmWave) bands (e.g., the 60 GHz band). To mitigate radio path loss and increase the transmission range of radio waves in ultra-high frequency bands, beamforming, massive MIMO (massive MIMO), full-dimensional MIMO (FD-MIMO), array antennas, analog beamforming, and large-scale antenna technologies are being discussed in 5G communication systems.

[0004] Additionally, to improve the network of the system, technologies such as evolved small cells, advanced small cells, cloud radio access networks (cloud RAN), ultra-dense networks, device-to-device communication (D2D), wireless backhaul, moving networks, cooperative communication, CoMP (Coordinated Multi-Points), and interference cancellation are being developed in 5G communication systems.

[0005] In addition, advanced coding modulation (ACM) methods such as Hybrid Frequency Shift Keying and Quadrature Amplitude Modulation (FQAM) and Sliding Window Superposition Coding (SWSC), as well as advanced access technologies such as Filter Bank Multi Carrier (FBMC), Non Orthogonal Multiple Access (NOMA), and Sparse Code Multiple Access (SCMA), are being developed in 5G systems.

[0006] In order to meet the demand for wireless data traffic, 5G system, NR (new radio or next radio) is commercialized, and it is expected that it will be able to provide users with high data transmission rate services through 5G system like 4G, and also provide wireless communication services for various purposes such as Internet of Things and services that require high reliability for specific purposes. In the current mixed system of 4th generation communication system, 5th generation system, etc., O-RAN (open radio access network) established by business operators and equipment providers defines E2AP (E2 application protocol) standard in the application protocol of E2 interface between E2 node and Near-RT (real time) RIC (RAN (radio access network) intelligent controller).

[0007] Looking back at the evolution of wireless communication over successive generations, technologies have primarily been developed for human-facing services such as voice, multimedia, and data. With the commercialization of the 5G (5th Generation) communication system, an explosive increase in connected devices is expected to be connected to communication networks. Examples of networked objects include vehicles, robots, drones, home appliances, displays, smart sensors installed in various infrastructures, construction equipment, and factory equipment. Mobile devices are also expected to evolve into diverse form factors, such as augmented reality glasses, virtual reality headsets, and holographic devices. In the 6G (6th Generation) era, efforts are being made to develop improved 6G communication systems to connect hundreds of billions of devices and objects and provide diverse services. For this reason, 6G communication systems are often referred to as "beyond 5G."

[0008] The 6G communication system, expected to be realized around 2030, will have a maximum transmission speed of terabytes (i.e., 1,000 gigabits) per second (bps) and a wireless latency of 100 microseconds (μsec). In other words, compared to 5G, the transmission speed in a 6G communication system will be 50 times faster and the wireless latency will be reduced to one-tenth.

[0009] To achieve these high data rates and ultra-low latency, 6G communication systems are being considered for implementation in the terahertz (THz) band (e.g., from 95 gigahertz (GHz) to 3 terahertz (THz)). Compared to the millimeter wave (mmWave) band introduced in 5G, the terahertz band is expected to have more severe path loss and atmospheric absorption, making it more important to develop technologies that can guarantee signal reach, or coverage. Key technologies to ensure coverage include Radio Frequency (RF) components, antennas, new waveforms that offer better coverage than Orthogonal Frequency Division Multiplexing (OFDM), beamforming, and multiple antenna transmission technologies such as massive Multiple-Input and Multiple-Output (MIMO), Full Dimensional MIMO (FD-MIMO), array antennas, and large-scale antennas. In addition, new technologies such as metamaterial-based lenses and antennas, high-dimensional spatial multiplexing using Orbital Angular Momentum (OAM), and Reconfigurable Intelligent Surface (RIS) are being discussed to improve the coverage of terahertz band signals.

[0010] In addition, in order to improve frequency efficiency and system network, 6G communication systems are developing full duplex technology that utilizes the same frequency resources at the same time for uplink and downlink; network technology that integrates satellites and HAPS (High-Altitude Platform Stations); network structure innovation technology that supports mobile base stations and enables optimization and automation of network operation; dynamic spectrum sharing technology through collision avoidance based on spectrum usage prediction; AI-based communication technology that utilizes artificial intelligence (AI) from the design stage and internalizes end-to-end AI support functions to realize system optimization; and next-generation distributed computing technology that realizes services with complexity that exceeds the limits of terminal computing capabilities by utilizing ultra-high-performance communication and computing resources (Mobile Edge Computing (MEC), cloud, etc.). In addition, efforts are being made to further strengthen connectivity between devices, further optimize networks, promote softwareization of network entities, and increase the openness of wireless communications through the design of new protocols to be used in 6G communication systems, the implementation of hardware-based security environments, the development of mechanisms for the safe use of data, and the development of technologies for maintaining privacy.

[0011] Research and development of these 6G communication systems are expected to enable a new level of hyper-connected experience through the hyper-connectivity of 6G communication systems, which encompass not only connections between things but also connections between people and things. Specifically, 6G communication systems are expected to enable services such as truly immersive eXtended Reality (XR), high-fidelity mobile holograms, and digital replicas. Furthermore, services such as remote surgery, industrial automation, and emergency response, which are provided through 6G communication systems through enhanced security and reliability, will be applied in diverse fields such as industry, medicine, automobiles, and home appliances.

[0012] In 6G communication systems, RAN functions are expected to be further refined, separating them into service subscribers and service providers. In service-based networks, subscription service confirmation procedures for service subscription status will be applied to various functions.

[0013] The above information may be provided as background art to aid in understanding the present disclosure. No claim or determination is made as to whether any of the above-described matters constitute prior art related to the present disclosure.

[0014] In embodiments of the present disclosure, a method performed by a central unit (CU) is provided. The method may include transmitting a first user data message to a first distributed unit (DU) for providing a primary cell (PCell) for carrier aggregation (CA), and transmitting a second user data message to a second DU for providing a secondary cell (SCell) for the CA. The first user data message may include information about a sequence number (SN) of a starting packet data convergence protocol (PDCP) protocol data unit (PDU) and information about a number of repetitions of the SN of the PDCP PDU in the first DU. The second user data message may include information about the SN of the starting PDCP PDU and information about the number of repetitions of the SN of the PDCP PDU. Hereinafter, in the present disclosure, SN represents a sequence number of a PDU including an SDU. For example, the SN of an SDU may represent the SN of the header of a PDU containing the SDU. The SN of a PDU may represent the SN in the header of the PDU.

[0015] In embodiments of the present disclosure, a method performed by a distributed unit (DU) is provided. The method may include receiving a user data message from a central unit (CU). The user data message may include information about a sequence number (SN) of a starting packet data convergence protocol (PDCP) protocol data unit (PDU) and information about a number of repetitions of the SN of the PDCP PDU. The user data message may be associated with the CU and shared with other DUs for inter-DU carrier aggregation (CA).

[0016] In embodiments of the present disclosure, a device of a central unit (CU) is provided. The device may include at least one processor; and a memory storing instructions. The instructions, when executed by the at least one processor, may individually or collectively cause the device to transmit a first user data message to a first distributed unit (DU) for providing a primary cell (PCell) for carrier aggregation (CA), and to transmit a second user data message to a second DU for providing a secondary cell (SCell) for the CA. The first user data message may include information about a sequence number (SN) of a starting packet data convergence protocol (PDCP) protocol data unit (PDU) and information about a repetition count of the SN of the PDCP PDU in the first DU. The second user data message may include information about the SN of the starting PDCP PDU and information about the repetition count of the SN of the PDCP PDU.

[0017] In embodiments of the present disclosure, a device of a distributed unit (DU) is provided. The device may include at least one processor; and a memory storing instructions. The instructions, when executed by the at least one processor, may individually or collectively cause the device to receive a user data message from a central unit (CU). The user data message may include information about a sequence number (SN) of a starting packet data convergence protocol (PDCP) protocol data unit (PDU) and information about a cycle count of the SN of the PDCP PDU. The user data message may be associated with the CU and shared with other DUs for inter-DU carrier aggregation (CA) (inter-DU CA).

[0018] In embodiments of the present disclosure, a method is provided, which is performed by a central unit (CU) connected to a first distributed unit (DU) and a second DU. The method may include an operation of transmitting a user equipment (UE) context setup request message to the first distributed unit (DU). The UE context setup request message may include information about a first internet protocol (IP) address used for uplink transmission in a user plane between the first DU and the CU for providing a primary cell (PCell); and information about a second IP address used for uplink transmission in a user plane between the second DU and the CU for providing a secondary cell (SCell). The method may include an operation of receiving a UE context setup response message from the first DU. The UE context setup response message may include information about a third IP address used for downlink transmission in a user plane between the first DU and the CU and information about a fourth IP address used for downlink transmission in a user plane between the second DU and the CU. The method may include transmitting, to the first DU based on the third IP address, a first user data message including a first packet data convergence protocol (PDCP) protocol data unit (PDU) and first sequence number (SN) synchronization information for the first PDCP PDU. The method may include transmitting, to the second DU based on the fourth IP address, a second user data message including a second PDCP PDU and second SN synchronization information for the second PDCP PDU.

[0019] In embodiments of the present disclosure, a method performed by a first distributed unit (DU) is provided. The method may include receiving a user equipment (UE) context setup request message from a central unit (CU) connected to the first DU. The UE context setup request message may include information about a first Internet protocol (IP) address used for uplink transmission in a user plane between the first DU and the CU for providing a primary cell (PCell); and information about a second IP address used for uplink transmission in a user plane between a second DU and the CU for providing a secondary cell (SCell). The method may include transmitting an SCell setup request message including information about the second IP address to the second DU. The method may include receiving an SCell setup response message from the second DU in response to the SCell setup request message. The SCell setup response message may include information related to a fourth IP address used for downlink transmission in the user plane between the CU and the second DU. The method may include an operation of transmitting a UE context setup response message to the CU. The UE context setup response message may include information about a third IP address used for downlink transmission in the user plane between the CU and the first DU and information about the fourth IP address used for downlink transmission in the user plane between the CU and the second DU.The method may include receiving, from the CU, a first user data message including a first PDCP (packet data convergence protocol) protocol data unit (PDU) and first SN (sequence number) synchronization information for the first PDCP PDU, based on the third IP address.

[0020] In embodiments of the present disclosure, a method performed by a second DU (distributed unit) is provided. The method may include receiving, from a first DU for providing a PCell (primary cell), a SCell (secondary cell) setup request message for configuring the second DU for providing a SCell (secondary cell). The SCell setup request message may include configuration information for inter-DU carrier aggregation (CA) using the first DU, the second DU, and a central unit (CU) connected to the first DU and the second DU. The method may include transmitting, to the first DU, an SCell setup response message in response to the SCell setup request message. The SCell setup response message may include information about an IP address used for downlink transmission in a user plane between the CU and the second DU. The method may include receiving, based on the IP address, a user data message including a PDCP (packet data convergence protocol) PDU (protocol data unit) and SN (sequence number) synchronization information for the PDCP PDU from the CU.

[0021] In embodiments of the present disclosure, a central unit (CU) connectable to a first DU (distributed unit) and a second DU is provided. The CU may include at least one processor; and a memory storing instructions. The instructions, when executed by the at least one processor, cause the CU to transmit a user equipment (UE) context setup request message to the first DU (distributed unit), the UE context setup request message including information about a first IP (internet protocol) address used for uplink transmission in a user plane between the first DU and the CU for providing a PCell (primary cell); And information about a second IP address used for uplink transmission in a user plane between the second DU and the CU for providing a SCell (secondary cell), and receiving a UE context setup response message from the first DU, the UE context setup response message including information about a third IP address used for downlink transmission in a user plane between the first DU and the CU and information about a fourth IP address used for downlink transmission in a user plane between the second DU and the CU, and transmitting to the first DU a first user data message including a first PDCP (packet data convergence protocol) protocol data unit (PDU) and first SN (sequence number) synchronization information for the first PDCP PDU based on the third IP address, and transmitting to the second DU a second user data message including a second PDCP PDU and second SN synchronization information for the second PDCP PDU based on the fourth IP address.

[0022] In embodiments of the present disclosure, a distributed unit (DU) is provided.The DU comprises at least one processor; and a memory storing instructions, wherein the instructions, when executed by the at least one processor, cause the DU to receive a user equipment (UE) context setup request message from a central unit (CU) connected to the DU, the UE context setup request message including information about a first IP (internet protocol) address used for uplink transmission in a user plane between the DU and the CU for providing a PCell (primary cell); And information about a second IP address used for uplink transmission in a user plane between another DU and the CU for providing a SCell (secondary cell), transmits an SCell setup request message including information about the second IP address to the other DU, receives an SCell setup response message in response to the SCell setup request message from the other DU, the SCell setup response message including information related to a fourth IP address used for downlink transmission in a user plane between the CU and the other DU, transmits a UE context setup response message to the CU, the UE context setup response message including information about a third IP address used for downlink transmission in a user plane between the CU and the DU and information about the fourth IP address used for downlink transmission in a user plane between the CU and the other DU, and includes a first PDCP (packet data convergence protocol) protocol data unit (PDU) and a first SN (sequence number) for the first PDCP PDU. The DU may be caused to receive a first user data message including synchronization information from the CU based on the third IP address.

[0023] In embodiments of the present disclosure, a distributed unit (DU) is provided. The DU includes at least one processor; And a memory storing instructions, wherein the instructions, when executed by the at least one processor, cause the DU to receive an SCell (secondary cell) setup request message for configuring the DU to provide an SCell (secondary cell) from another DU for providing a PCell (primary cell), the SCell setup request message including configuration information for inter-DU carrier aggregation (CA) using the DU, the other DU, and a CU (central unit), and transmit an SCell setup response message to the other DU in response to the SCell setup request message, the SCell setup response message including information on an IP address used for downlink transmission in a user plane between the CU and the DU, and based on the IP address, transmit a user data message including a PDCP (packet data convergence protocol) PDU (protocol data unit) and SN (sequence number) synchronization information for the PDCP PDU from the CU. It can cause you to receive.

[0024] The above and other aspects, features and advantages of specific embodiments of the present disclosure will become more apparent from the following description taken in conjunction with the accompanying drawings, in which:

[0025] Figures 1a and 1b illustrate examples of wireless communication systems.

[0026] Figures 2a to 2c illustrate examples of spectrum aggregation environments.

[0027] Figure 3 shows an example of a resource structure in the time domain and frequency domain.

[0028] Figure 4a shows the protocol stack in the control plane.

[0029] Figure 4b shows the protocol stack in the user plane.

[0030] Figure 5 shows an example of spectrum aggregation between distributed units (DUs).

[0031] Figure 6 shows an example of a protocol for spectrum aggregation between DUs.

[0032] Figure 7a shows an example of bearer split between DUs.

[0033] Figure 7b shows an example of bearer switching between DUs.

[0034] Figure 8 shows an example of a procedure for setting up multiple RLC (radio link control).

[0035] Figure 9 shows an example of a protocol of a network entity for multiple RLCs.

[0036] Figure 10 shows an example of multi-path flow control for multiple RLCs.

[0037] Figure 11 shows an example of radio link outage (RLO) control in multiple RLCs.

[0038] Figure 12 shows an example of retransmission due to release of a SCell (secondary cell) path in a multi-RLC.

[0039] Figure 13 shows an example of SN (serial number) synchronization information.

[0040] Figure 14 shows an example of downlink transmission using SN synchronization information in multiple RLCs.

[0041] Figure 15 shows an example of ARQ (automatic repeat request) operation per DU in a multi-RLC.

[0042] Figure 16 shows an example of traffic processing according to deactivation of SCell DU in multi-RLC.

[0043] Figure 17 shows an example of multiple MAC (medium access control) paths.

[0044] Figure 18 shows an example of RLC reassembly and ARQ reporting.

[0045] Figure 19 illustrates the configuration of an electronic device.

[0046] The terms used in this disclosure are used only to describe specific embodiments and may not be intended to limit the scope of other embodiments. The singular expression may include plural expressions unless the context clearly indicates otherwise. Terms used herein, including technical or scientific terms, may have the same meaning as commonly understood by those of ordinary skill in the art described in this disclosure. Terms defined in general dictionaries among the terms used in this disclosure may be interpreted as having the same or similar meaning in the context of the relevant technology, and shall not be interpreted in an idealized or overly formal sense unless explicitly defined in this disclosure. In some cases, even if a term is defined in this disclosure, it cannot be interpreted to exclude embodiments of the present disclosure.

[0047] The various embodiments of the present disclosure described below illustrate a hardware-based approach as an example. However, since the various embodiments of the present disclosure include techniques utilizing both hardware and software, the various embodiments of the present disclosure do not exclude a software-based approach.

[0048] In the following description, terms referring to signals (e.g., signal, information, message, signaling), terms referring to resources (e.g., symbol, slot, subframe, radio frame, subcarrier, resource element (RE), resource block (RB), bandwidth part (BWP), occasion), terms for operational states (e.g., step, operation, procedure), terms referring to data (e.g., packet, user stream, information, bit, symbol, codeword), terms referring to channels, terms referring to network entities, terms referring to components of devices, etc. are examples for convenience of description. Therefore, the present disclosure is not limited to the terms described below, and other terms having equivalent technical meanings may be used. In addition, the terms '...bu', '...gi', '...mul', '...che', etc. used below may mean at least one shape structure or a unit that processes a function.

[0049] In addition, in the present disclosure, expressions such as "more than" or "less than" may be used to determine whether a specific condition is satisfied or fulfilled, but this is merely a description for expressing an example and does not exclude descriptions such as "more than" or "less than." A condition described as "more than" may be replaced with "more than," a condition described as "less than" may be replaced with "less than," and a condition described as "more than and less than" may be replaced with "more than and less than." In addition, hereinafter, "A" to "B" mean at least one of elements from A (including A) to B (including B). hereinafter, "C" and / or "D" mean at least one of "C" or "D," that is, including {"C", "D", "C" and "D"}.

[0050] Although the present disclosure describes various embodiments using terms used in some communication standards (e.g., 3rd Generation Partnership Project (3GPP), extensible radio access network (xRAN), open-radio access network (O-RAN), etc.), these are merely examples for explanation. The various embodiments of the present disclosure can be easily modified and applied to other communication systems.

[0051] In the present disclosure, the signal quality may be, for example, at least one of RSRP (reference signal received power), BRSRP (beam reference signal received power), RSRQ (reference signal received quality), RSSI (received signal strength indicator), SINR (signal to interference and noise ratio), CINR (carrier to interference and noise ratio), SNR (signal to noise ratio), EVM (error vector magnitude), BER (bit error rate), and BLER (block error rate). In addition to the examples described above, it goes without saying that other terms having equivalent technical meanings or other metrics indicating channel quality may be used. Hereinafter, in the present disclosure, high signal quality means a case where a signal quality value related to a signal size is large or a signal quality value related to an error rate is small. A higher signal quality may mean that a smooth wireless communication environment is guaranteed. In addition, an optimal beam may mean a beam with the highest signal quality among beams.

[0052] Currently, discussions are underway to improve and enhance the initial 5G mobile communication technology in consideration of the services that 5G mobile communication technology was intended to support, and physical layer standardization is in progress for technologies such as V2X (Vehicle-to-Everything) to help autonomous vehicles make driving decisions and increase user convenience based on their own location and status information transmitted by vehicles, NR-U (New Radio Unlicensed) for the purpose of system operation that complies with various regulatory requirements in unlicensed bands, NR terminal low power consumption technology (UE Power Saving), Non-Terrestrial Network (NTN), which is direct terminal-satellite communication to secure coverage in areas where communication with terrestrial networks is impossible, and Positioning.

[0053] In addition, standardization of wireless interface architecture / protocols is in progress for technologies such as intelligent factories (Industrial Internet of Things, IIoT) to support new services through linkage and convergence with other industries, Integrated Access and Backhaul (IAB) that provides nodes for expanding network service areas by integrating wireless backhaul links and access links, Mobility Enhancement technology including Conditional Handover and Dual Active Protocol Stack (DAPS) handover, and 2-step random access (2-step RACH for NR) that simplifies random access procedures. Standardization is also in progress for system architecture / services such as 5G baseline architecture (e.g., Service-based Architecture, Service-based Interface) for grafting Network Functions Virtualization (NFV) and Software-Defined Networking (SDN) technologies, and Mobile Edge Computing (MEC) that provides services based on the location of the terminal.

[0054] Once these 5G mobile communication systems are commercialized, an explosive increase in connected devices will be connected to the communication network, necessitating enhanced functionality and performance of 5G mobile communication systems and integrated operation of these connected devices. To this end, new research will be conducted on improving 5G performance and reducing complexity, supporting AI services, supporting metaverse services, and drone communications by utilizing eXtended Reality (XR), Artificial Intelligence (AI), and Machine Learning (ML) to efficiently support Augmented Reality (AR), Virtual Reality (VR), and Mixed Reality (MR).

[0055] In addition, the development of these 5G mobile communication systems includes new waveforms to ensure coverage in the terahertz band of 6G mobile communication technology, multi-antenna transmission technologies such as Full Dimensional MIMO (FD-MIMO), Array Antenna, and Large Scale Antenna, metamaterial-based lenses and antennas to improve the coverage of terahertz band signals, high-dimensional spatial multiplexing technology using Orbital Angular Momentum (OAM), Reconfigurable Intelligent Surface (RIS) technology, as well as full duplex technology to improve the frequency efficiency and system network of 6G mobile communication technology, satellite, AI (Artificial Intelligence) from the design stage and AI-based communication technology that realizes system optimization by internalizing end-to-end AI support functions, and ultra-high-performance communication and computing resources to provide services with complexity that exceeds the limits of terminal computing capabilities. It can serve as a basis for the development of next-generation distributed computing technologies that can be realized by utilizing them.

[0056] Hereinafter, 4G and / or 5G environments are described as examples, but this description does not limit the scope of the communication environments of the embodiments of the present disclosure. The technical principles according to the embodiments of the present disclosure can also be applied to 6G and post-6G communication technologies and network environments.

[0057] Figures 1a and 1b illustrate examples of wireless communication systems.

[0058] Referring to FIG. 1A, FIG. 1A illustrates a base station (110) and a terminal (120) as some of the nodes utilizing a wireless channel in a wireless communication system. Although FIG. 1A illustrates only one base station, the wireless communication system may further include other base stations identical or similar to the base station (110).

[0059] The base station (110) is a network infrastructure that provides wireless access to the terminal (120). The base station (110) has coverage defined based on the distance at which a signal can be transmitted. In addition to the base station, the base station (110) may be referred to as an 'access point (AP)', 'eNodeB (eNB)', '5th generation node', 'next generation nodeB (gNB)', 'wireless point', 'transmission / reception point (TRP)', or other terms having equivalent technical meanings.

[0060] The terminal (120) is a device used by a user and communicates with the base station (110) via a wireless channel. The link from the base station (110) to the terminal (120) is referred to as a downlink (DL), and the link from the terminal (120) to the base station (110) is referred to as an uplink (UL). In addition, although not shown in FIG. 1A, the terminal (120) and another terminal may communicate with each other via a wireless channel. In this case, the link between the terminal (120) and another terminal (device-to-device link, D2D) is referred to as a sidelink, and the sidelink may be used interchangeably with the PC5 interface. In some other embodiments, the terminal (120) may be operated without the involvement of a user. In one embodiment, the terminal (120) is a device that performs machine type communication (MTC) and may not be carried by the user. Additionally, according to one embodiment, the terminal (120) may be an NB (narrowband)-IoT (internet of things) device.

[0061] The terminal (120) may be referred to as a terminal, or other terms such as 'user equipment (UE),' 'customer premises equipment (CPE),' 'mobile station,' 'subscriber station,' 'remote terminal,' 'wireless terminal,' 'electronic device,' or 'user device,' or other terms having equivalent technical meanings.

[0062] The base station (110) and the terminal (120) can perform beamforming. The base station (110) and the terminal (120) can transmit and receive wireless signals in a relatively low frequency band (e.g., FR 1 (frequency range 1) of NR). In addition, the base station (110) and the terminal (120) can transmit and receive wireless signals in a relatively high frequency band (e.g., FR 2 (or, FR 2-1, FR 2-2, FR 2-3), FR 3 of NR), millimeter wave (mmWave) band (e.g., 28 GHz, 30 GHz, 38 GHz, 60 GHz)). To improve channel gain, the base station (110) and the terminal (120) can perform beamforming. Here, the beamforming can include transmission beamforming and reception beamforming. The base station (110) and the terminal (120) can impart directionality to the transmitted or received signal. To this end, the base station (110) and the terminal (120) can select serving beams through a beam search or beam management procedure. After the serving beams are selected, subsequent communication can be performed through resources that have a QCL relationship with the resource that transmitted the serving beams.

[0063] The terminal (120) may be configured with cells of the base station (110) and carrier aggregation (CA). CA technology is a technology that increases the frequency usage efficiency of the terminal (120) and the base station (110) by connecting the terminal to a group of homogeneous wireless communication cells having a common radio resource control entity, and simultaneously using frequency resources on component carriers of each cell located in different frequency bands for signal transmission and reception. The cells configured for CA may include one PCell (primary cell) and one or more SCells (secondary cells).

[0064] Referring to FIG. 1B, a terminal (120) may be configured in dual connectivity (DC) using a first base station (110-1) and a second base station (110-2). DC technology is a technology that increases frequency utilization efficiency by simultaneously connecting a terminal to two independent heterogeneous or homogeneous wireless communication cell groups having separate radio resource control entities, and using frequency resources on component carriers of cells within each cell group located in different frequency bands for signal transmission and reception. The terminal (110) is connected to two different radio resource entities (e.g., a first base station (110-1), a second base station (110-2)) and is a technology for using radio resources allocated by each radio resource entity. In MR-DC, a UE (e.g., terminal 120) in a radio resource control (RRC) connected state (i.e., RRC_CONNCETED) can be configured to utilize radio resources provided by two independent schedulers. Each scheduler can be located in an NG-RAN node (e.g., a first base station (110-1) and a second base station (110-2)). Here, one node is a master node (MN) and the other node is a secondary node (SN). The MN and SN are connected via a network interface, and the MN can be connected to a core network. The SN may or may not be connected to the core network.

[0065] The MN may provide a master cell group (MCG). The MN, in addition to the MN, may be referred to as an M-NODE or an M-NG-RAN node. The MCG may include one or more cells. The MCG may include a PCell (primary cell). The MCG may include multiple aggregated cells. The MCG may include a PCell and one or more secondary cells (SCells). The SN may provide a secondary cell group (SCG). The SN, in addition to the SN, may be referred to as an S-NODE or an S-NG-RAN node. The SCG may include one or more cells. The SCG may include multiple aggregated cells. Like the MCG, the SCG may include a PCell and / or an SCell. A cell functioning as a PCell within the SCG may be referred to as a PSCell (primary secondary cell). The secondary cell group may include a PSCell and one or more SCells. Hereinafter, the term "SpCell" (special cell) may be used to encompass PCell and PSCell. "SpCell" refers to the primary cell of an MCG or SCG. In other words, an MCG SpCell refers to a PCell, and an SCG SpCell refers to an SCell.

[0066] The possible types of DC can be defined as follows:

[0067] 1) EN-DC: Dual connectivity in which the eNB is connected to the evolved packet core (EPC), and the UE is connected to the eNB acting as an MN and the gNB acting as an SN. Here, the gNB may be referred to as an en-gNB, and the en-gNB may or may not be connected to the EPC.

[0068] 2) NGEN-DC: Dual connectivity in which the eNB is connected to the 5GC (5G core), and the terminal is connected to the eNB operating as an MN and the gNB operating as an SN. Here, the eNB may be referred to as ng-eNB.

[0069] 3) NE-DC: Dual connectivity in which the gNB is connected to the 5GC, and the terminal is connected to the gNB operating as an MN and the eNB operating as an SN. Here, the eNB may be referred to as ng-eNB.

[0070] 4) NR-DC: Dual connectivity where gNBs are connected to 5GC, and the UE is connected to a gNB that acts as an MN and a gNB that acts as an SN. NR-DC can also be used when a UE is connected to a single gNB that acts as both an MN and SN and configures both an MCG and an SCG.

[0071] The terminal (120) can support MR (multi-radio)-DC. The terminal (120) can be connected to a first base station (110-1) and a second base station (110-2). The first base station (110-1) is an MN, and the second base station (110-2) is an SN, and can be connected to the terminal. With the CA (carrier aggregation) provided by each base station, the DC technology can provide higher data rates. The first base station (110-1) and the second base station (110-2), as MN and SN, respectively, can transmit downlink traffic to the terminal (120) or receive uplink traffic from the terminal (120).

[0072] Figures 2a to 2c illustrate examples of spectrum aggregation environments. Spectrum aggregation refers to a wireless communication technology that uses a certain frequency interval in the frequency domain and another frequency interval together with the frequency interval. Depending on the technology used, the frequency interval may correspond to at least one of a resource block (RB), a bandwidth part (BWP), a bandwidth, a cell, a cell group, a frequency band, and / or a frequency range. For example, spectrum aggregation may include CA. The bandwidth of a PCell (primary cell) and the bandwidth of a SCell (primary cell) may be used together for data communication. For example, spectrum aggregation may include DC. The frequency range occupied by the MCG cell of the MN and the frequency range occupied by the SCG cell of the SN may be used together for communication. For example, spectrum aggregation may include CoMP. Base stations with different frequency spectrums may be utilized for data communications. For example, spectrum aggregation may include multi-transmission reception points (M-TRPs). Resources allocated in different frequency bands may be utilized for data transmission.

[0073] A cell can refer to an area (or coverage) that can be covered by a single base station (e.g., gNB) (or a single DU). A cell can refer to not only a geographical area but also an area occupying a specific spectrum in the frequency domain. A DU can cover one cell or multiple cells. Here, multiple cells can be distinguished by the frequency they support and the area of ​​the sector they cover. A serving cell is a cell that provides a terminal and upper layer signaling (e.g., radio resource control (RRC) signaling), and can refer to one cell or multiple cells. If the terminal (120) is not configured to support carrier aggregation (CA) and dual connectivity (DC), the serving cell can be a single cell corresponding to a PCell. When the terminal (120) is set to support CA or DC, the serving cell may be a set of cells including a PCell and one or more SCells.

[0074] Referring to Fig. 2a, a base station can be divided into a CU and a DU. For example, if the base station corresponds to a gNB, the CU is a logical node that hosts the RRC, SDAP (service data adaptation protocol), and PDCP (packet data convergence protocol) protocols of the base station. The CU and the DU can be connected via the F1 interface. The DU is a logical node that hosts the RLC (radio link control), MAC (medium access control), and PHY (physical) layers. A DU can support one or more cells, and a cell can be supported by only one DU. A first base station (110-1) can include CU #1 (205-1) and DU #1 (210-1). DU #1 (210-1) can provide one or more cells. A second base station (110-2) can include CU #2 (205-2) and DU #2 (210-2). DU #2 (210-2) may provide one or more cells. For example, for DC operation, MgNB-DU may represent the gNB-DU of the en-gNB or gNB acting as a master node (e.g., DU #1 (210-1)), and SgNB-DU may represent the gNB-DU of the en-gNB or gNB acting as a secondary node (e.g., DU #2 (210-2)).

[0075] Referring to FIG. 2B, a base station can be divided into a CU and a DU. Unlike multiple independent base stations (e.g., a first base station (110-1), a second base station (110-2)) that serve a terminal (120), one CU and multiple DUs can serve a terminal (120). For example, CU #1 (215) can be connected to DU #1 (231) and DU #2 (232). CU #1 (215) can be connected to each of DU #1 (231) and DU #2 (232) via an F1 interface. DU #1 (231) can provide one or more cells. DU #2 (232) can provide one or more cells. For example, for CA operation, DU #1 (231) can provide a cell corresponding to a PCell. DU #2 (232) can provide a cell corresponding to an SCell. Two cells can be configured for the terminal (120).

[0076] Referring to Fig. 2c, the base station can be divided into CU and DU. In addition to the distributed arrangement separated into CU and DU, a base station (242) for small cells can be additionally deployed. For example, CU #1 (215) can be connected to DU #1 (231) via the F1 interface. The base station (242) can communicate with CU #1 (215) as an independent base station. DU #1 (231) can provide one or more cells. The base station (242) can provide one or more small cells. For example, for CA operation, DU #1 (231) can provide a cell corresponding to PCell. DU #2 (232) can provide a cell corresponding to SCell. Two cells can be configured for the terminal (120).

[0077] The vendors of DUs (or DUs and base stations of small cells) may be different. Frequency bands used by multiple vendors may not be compatible with each other. For example, the vendors of the first DU and the second DU may purchase different frequency bands. The frequency range occupied by the cell provided by the first DU may be different from the frequency range occupied by the cell provided by the second DU. Since the second DU does not have accurate information about the cell of the first DU, it may be difficult to configure CA between the two cells. If CA is configured between the two cells, signaling via the CU or a higher-level entity is required because there is no interface between the first DU and the second DU. However, the increase in signaling causes delay, making effective resource management difficult.

[0078] Hereinafter, embodiments of the present disclosure describe a new interface and procedures and messages for configuring the interface for spectrum aggregation, such as the CA or DC described above. First, resources at the physical layer are described through FIG. 3.

[0079] Figure 3 illustrates an example of a resource structure in the time domain and frequency domain. Figure 3 illustrates the basic structure of the time-frequency domain, which is a radio resource domain in which data or control channels are transmitted in the downlink or uplink.

[0080] Referring to Figure 3, the horizontal axis represents the time domain and the vertical axis represents the frequency domain. The minimum transmission unit in the time domain is an OFDM (orthogonal frequency division multiplexing) symbol, N symbOFDM symbols (302) are grouped to form one slot (306). The length of a subframe is defined as 1.0 ms, and the length of a radio frame (314) is defined as 10 ms. The minimum transmission unit in the frequency domain is a subcarrier, and the carrier bandwidth constituting the resource grid is N BW It consists of a number of subcarriers (304).

[0081] The basic unit of resources in the time-frequency domain is a resource element (RE) (312), which can be represented by an OFDM symbol index and a subcarrier index. A resource block may include multiple resource elements. In the LTE system, a resource block (RB) (or physical resource block (PRB)) is N in the time domain. symb N consecutive OFDM symbols and frequency domain SC RB are defined as N consecutive subcarriers. In the NR system, a resource block (RB) (308) is defined as N in the frequency domain. SC RB can be defined as a series of consecutive subcarriers (310). One RB (308) is N in the frequency axis. SC RB It contains REs (312). In general, the minimum transmission unit of data is RB and the number of subcarriers is N. SC RB=12. The frequency domain may include common resource blocks (CRBs). Physical resource blocks (PRBs) may be defined in the bandwidth part (BWP) of the frequency domain. The CRB and PRB numbers may be determined based on the subcarrier spacing. The data rate may increase in proportion to the number of RBs scheduled to the terminal.

[0082] In the NR system, in the case of a frequency division duplex (FDD) system that operates the downlink and uplink by frequency division, the downlink transmission bandwidth and the uplink transmission bandwidth may be different. The channel bandwidth represents the radio frequency (RF) bandwidth corresponding to the system transmission bandwidth. [Table 1] shows part of the correspondence between the system transmission bandwidth, subcarrier spacing (SCS), and channel bandwidth defined in the NR system in a frequency band lower than x GHz (e.g., frequency range (FR) 1 (310 MHz to 7125 MHz)). And [Table 2] shows part of the correspondence between the transmission bandwidth, subcarrier spacing, and channel bandwidth defined in the NR system in a frequency band higher than y GHz (e.g., FR2 (24250 MHz - 52600 MHz) or FR2-2 (52600 MHz to 71000 MHz)). For example, an NR system with a 100 MHz channel bandwidth and a 30 kHz subcarrier spacing has a transmission bandwidth of 273 RBs. In [Table 1] and [Table 2], N / A may be a bandwidth-subcarrier combination not supported by the NR system.

[0083] Channel bandwidth [MHz] SCS 5 10 20 50 80 100 Transmission bandwidth configuration N RB15kHz2552106207N / AN / A30kHz11245113321727360kHzN / A112465107135

[0084] Channel bandwidth [MHz] SCS50100200400 Transmission bandwidth configuration N RB 60kHz66132264N / A120kHz3266132264

[0085] Figure 4a illustrates a protocol stack (400) in the control plane.

[0086] Referring to FIG. 4A, in an NR communication system, a wireless protocol of a control plane of a terminal (120) (e.g., UE) may include PHY (411), MAC (412), RLC (413), PDCP (414), and RRC (415). In an NR communication system, a wireless protocol of a control plane of a base station (110) (e.g., gNB) may include PHY (421), MAC (422), RLC (423), PDCP (424), and RRC (425).

[0087] The main functions of RRC (415, 425) may include some of the following functions.

[0088] - Broadcast of system information related to AS (Access Stratum) and NAS (Non Access Stratum)

[0089] - Paging initiated by 5GC or NG-RAN

[0090] - Establishment, maintenance and release of RRC connection between UE and NG-RAN including:

[0091] 1) Adding, modifying, and releasing carrier aggregation

[0092] 2) Add, modify and remove Dual Connectivity within NR or between E-UTRA and NR.

[0093] - Security functions including key management

[0094] - Setup, configuration, maintenance, and release of SRB (Signaling Radio Bearer) and DRB (Data Radio Bearer).

[0095] - Mobility features including:

[0096] 1) Handover and context transfer

[0097] 2) UE cell selection and reselection and control of cell selection and reselection

[0098] 3) Inter-RAT mobility

[0099] - QoS (Quality of Service) management function

[0100] - UE measurement reporting and reporting control;

[0101] - Detection of and recovery from radio link failure

[0102] - Transmitting NAS messages from / to the UE to / from the NAS.

[0103] The main functions of PDCP (414, 424) may include some of the following functions:

[0104] - Header compression and decompression (ROHC only)

[0105] - User data transfer function

[0106] - In-sequence delivery of upper layer PDUs (protocol data units)

[0107] - Out-of-sequence delivery of upper layer PDUs

[0108] - PDCP PDU reordering for reception

[0109] - Duplicate detection of lower layer SDUs (service data units)

[0110] - Retransmission function (Retransmission of PDCP SDUs)

[0111] - Encryption and decryption functions (Ciphering and deciphering)

[0112] - Timer-based SDU discard in uplink.

[0113] In the above, the reordering function of the PDCP layer may refer to the function of reordering PDCP PDUs received from the lower layer in order based on the PDCP SN (sequence number). The reordering function of the PDCP layer may include the function of transmitting data to the upper layer in the reordered order, the function of transmitting data directly without considering the order, the function of recording lost PDCP PDUs by reordering the order, the function of reporting the status of lost PDCP PDUs to the transmitting side, and the function of requesting retransmission of lost PDCP PDUs.

[0114] The main functions of RLC (413, 423) may include some of the following functions:

[0115] - Data transfer function (Transfer of upper layer PDUs)

[0116] - In-sequence delivery of upper layer PDUs

[0117] - Out-of-sequence delivery of upper layer PDUs

[0118] - ARQ function (Error Correction through ARQ)

[0119] - Concatenation, segmentation and reassembly of RLC SDUs

[0120] - Re-segmentation of RLC data PDUs

[0121] - Reordering of RLC data PDUs

[0122] - Duplicate detection function

[0123] - Protocol error detection

[0124] - RLC SDU discard function

[0125] - RLC re-establishment function

[0126] In the above, the in-sequence delivery function of the RLC layer may refer to the function of sequentially delivering RLC SDUs received from lower layers to upper layers. If a single RLC SDU is originally received divided into multiple RLC SDUs, the in-sequence delivery function of the RLC layer may include the function of reassembling and delivering them.

[0127] The in-sequence delivery function of the RLC layer may include a function to reorder received RLC PDUs based on the RLC SN (sequence number) or PDCP SN (sequence number), a function to record lost RLC PDUs by reordering them, a function to report status of lost RLC PDUs to the transmitter, and a function to request retransmission of lost RLC PDUs.

[0128] The in-sequence delivery function of the RLC layer may include a function to sequentially deliver to the upper layer only the RLC SDUs up to the lost RLC SDU when there is a lost RLC SDU. In addition, the in-sequence delivery function of the RLC layer may include a function to sequentially deliver to the upper layer all RLC SDUs received before the timer starts if a predetermined timer has expired even if there is a lost RLC SDU. In addition, the in-sequence delivery function of the RLC layer may include a function to sequentially deliver to the upper layer all RLC SDUs received up to the present if a predetermined timer has expired even if there is a lost RLC SDU.

[0129] The RLC layer can process RLC PDUs in the order they are received and deliver them to the PDCP (405, 440) device, regardless of the order of the sequence number (out-of-sequence delivery).

[0130] When the RLC layer receives a segment, it can receive segments that are stored in a buffer or will be received later, reconstruct them into a complete RLC PDU, and then transmit them to the PDCP device.

[0131] The RLC layer may not include concatenation functionality, and the function may be performed by the MAC layer or replaced by the multiplexing functionality of the MAC layer.

[0132] In the above, the out-of-sequence delivery function of the RLC layer may refer to the function of directly delivering RLC SDUs received from a lower layer to an upper layer regardless of the order. The out-of-sequence delivery function of the RLC layer may include the function of reassembling and delivering multiple RLC SDUs when an original RLC SDU is received fragmented into multiple RLC SDUs. The out-of-sequence delivery function of the RLC layer may include the function of storing and arranging the RLC SN or PDCP SN of received RLC PDUs to record any lost RLC PDUs.

[0133] MAC (412, 422) can be connected to multiple RLC layer layers configured in one terminal, and the main functions of MAC can include some of the following functions.

[0134] - Mapping function (Mapping between logical channels and transport channels)

[0135] - Multiplexing / demultiplexing of MAC SDUs

[0136] - Scheduling information reporting function

[0137] - HARQ function (Error correction through HARQ)

[0138] - Priority handling between logical channels of one UE

[0139] - Priority handling between UEs by means of dynamic scheduling

[0140] - MBMS service identification function

[0141] - Transport format selection function

[0142] - Padding function

[0143] The PHY layer (411, 421) can perform operations such as channel coding and modulating upper layer data, converting it into OFDM symbols and transmitting it through a wireless channel, or demodulating and channel decoding OFDM symbols received through a wireless channel and transmitting them to a higher layer.

[0144] Figure 4b illustrates a protocol stack (450) in the user plane.

[0145] Referring to FIG. 4b, the wireless protocol of the user plane of the terminal (120) (e.g., UE) may include PHY (461), MAC (462), RLC (463), PDCP (464), and SDAP (465). In an NR communication system, the wireless protocol of the user plane of the base station (110) (e.g., gNB) may include PHY (471), MAC (472), RLC (473), PDCP (474), and SDAP (475).

[0146] The main functions of SDAP (465, 475) may include some of the following functions:

[0147] - Transfer of user plane data

[0148] - Mapping function between QoS flow and data bearer for both DL and UL

[0149] - QoS flow ID marking function for uplink and downlink (marking QoS flow ID in both DL and UL packets)

[0150] - Ability to map relective QoS flow to data bearer for uplink SDAP PDUs (reflective QoS flow to DRB mapping for the UL SDAP PDUs).

[0151] For the SDAP layer, the terminal (120) can be configured by a Radio Resource Control (RRC) message for each PDCP layer, each bearer, or each logical channel to use the header of the SDAP layer or to use the function of the SDAP layer. When the SDAP header is configured, the terminal (120) can instruct the terminal (120) to update or reset the mapping information for the QoS flow and data bearer of the uplink and downlink using a 1-bit indicator (NAS reflective QoS) for reflecting the Non-Access Stratum (NAS) Quality of Service (QoS) of the SDAP header and a 1-bit indicator (AS reflective QoS) for reflecting the Access Stratum (AS) QoS. The SDAP header can include QoS flow ID information indicating QoS. The QoS information can be used as data processing priority, scheduling information, etc. to support a smooth service.

[0152] For PDCP (464, 474) in the user plane, reference may be made to the description of PDCP (414, 424) in the control plane. For RLC (463, 473) in the user plane, reference may be made to the description of RLC (413, 423) in the control plane. For MAC (462, 472) in the user plane, reference may be made to the description of MAC (412, 422) in the control plane. For PHY (461, 471) in the user plane, reference may be made to the description of PHY (411, 421) in the control plane.

[0153] Although the wireless protocol of the NR communication system in the radio access network is described as an example, the embodiments of the present disclosure are not limited thereto. For example, even in the LTE communication system, a DU may be defined (e.g., eNB-DU), in which case the SDAP (465, 475) may be omitted. The embodiments of the present disclosure provide procedures for an interface between DUs or an interface between a DU and a base station (e.g., eNB / gNB) for spectrum aggregation that can be applied in 4G, 5G, and / or 6G systems, and various types of layers or protocols may be used in addition to the communication protocol of FIG. 4b.

[0154] As communication technology advances, the number of network entities increases, and communication with external nodes (e.g., base stations, other DUs) through CUs causes delays. Therefore, interfaces between DUs or interfaces between DUs and base stations need to be defined. Hereinafter, a new interface and procedures and messages for configuring the interface are proposed for spectrum aggregation, such as the CA described above. Although procedures and messages related to the interface between DUs are described below, it should be understood that the descriptions can be applied in the same or similar manner to the interface between a DU and an independent base station (e.g., a base station of a small cell). In the present disclosure, when describing the interface between DUs, the DUs may be from the same vendor or different vendors. That is, information can be exchanged between DUs from different vendors through the interfaces and messages described below.

[0155] Figure 5 illustrates an example of spectrum aggregation between distributed units (DUs). Like reference numbers may be used to refer to like descriptions.

[0156] Referring to FIG. 5, a communication network may include a radio access network (500) and a core network (560). A node (e.g., a base station (110)) providing the radio access network (500) may provide a communication service to a user device (e.g., a terminal (120)) through one or more cells. The core network (560) may include various entities so that the communication service can be smoothly performed. For example, the core network (560) may include an entity in charge of an access management function (AMF). For example, the core network (560) may include an entity in charge of a user plane function (UPF). The core network (560) may be implemented through the radio access network (500) and an NG interface. The NG interface may include an NG-C interface for a control plane and an NG-U interface for a user plane. The NG-C interface may be defined between the node providing the radio access network (500) and the AMF. The above NG-U interface can be defined between a node providing a wireless access network (500) and the UPF.

[0157] A node providing a wireless access network (500) may be implemented in a distributed deployment according to a CU (central unit) (505) configured to perform functions of upper layers (e.g., PDCP, RRC) of an access network and a DU (distributed unit) configured to perform functions of lower layers (e.g., RLC, MAC, PHY). An interface between the CU (505) and the DU may be referred to as an F1 interface. The F1 interface may include an F1-C interface for a control plane and an F1-U interface for a user plane. The CU (505) may be connected to one or more DUs. For example, the CU (505) may be connected to DU #1 (510), DU #2 (520), ..., DU #n (550). Each DU may provide one or more cells. For example, DU #1 (510) may be connected to a cell #1 (511) and cell #2 (512) can be provided. DU #2 (520) can provide cell #1 (521) and cell #2 (522). DU #n (550) can provide cell #1 (551) and cell #2 (552).

[0158] CA (Carrier Aggregation) can aggregate two or more cells. A cell can have a component carrier (CC). The UE (120) can simultaneously receive or transmit signals through one or more CCs depending on its capabilities. When CA is configured, the UE (120) can have only one RRC connection with the network. During RRC connection establishment / reestablishment / handover, one serving cell can provide NAS mobility information, and during RRC connection reestablishment / handover, one serving cell can provide security input. The serving cell can be referred to as a PCell (Primary Cell). Depending on the UE capability of the UE (120), a SCell (Secondary Cell) can be configured to form a serving cell set together with the PCell. The serving cell set configured for the UE (120) can always consist of one PCell and one or more SCells. For example, cell #1 (511) of DU #1 (510) and cell #1 (521) of DU #2 (520) may be configured as a serving cell set for terminal (120). In addition, for example, cell #1 (511) of DU #1 (510), cell #1 (521) of DU #2 (520), and cell #1 (551) of DU #n (550) may be configured as a serving cell set for terminal (120). In addition, for example, cell #2 (512) of DU #1 (510) and cell #1 (551) of DU #n (550) may be configured as a serving cell set for terminal (120).

[0159] The setup, reconfiguration, addition, and removal of SCells can be performed by RRC. During intra-NR handovers and during connection resumption in RRC_INACTIVE, the network may also add, remove, maintain, or reconfigure SCells to be used with the target PCell. When adding a new SCell, dedicated RRC signaling can be used to transmit all essential system information about the SCell.

[0160] In embodiments of the present disclosure, a CA for a terminal (120) may be configured through multiple DUs. An operator may construct DUs across multiple sites or DUs for multiple vendors, depending on the network environment and the carriers' holding status. An interface between DUs may be defined to support inter-DU CA even if they are not from the same vendor or in the same region. For example, if a product (or server) configured to perform the functions of a DU is difficult to upgrade to support a new band or function, inter-DU CA may be provided by installing an additional DU. Data throughput performance may be improved through such inter-DU CA. Hereinafter, the interface between DUs is referred to as an X1 interface, but the interface may be referred to instead by other terms having the same technical meaning (e.g., D2, M1, F3, MV, XD). In the control plane, the interface between DUs may be referred to as an X1-C interface (581). The interface between DUs in the user plane may be referred to as an X1-U interface (582). The X1-C interface (581) may be used to share call control information between DUs and for setup procedures. The X1-U interface (582) may be used for CA bearer transfer between DUs, signaling between MAC layers, and information sharing.

[0161] A DU providing a PCell (hereinafter, PCell DU) can manage not only the control plane but also the user plane. A DU providing a PCell may include an RLC entity connected to the PDCP layer of the CU. Meanwhile, if the user plane is supported only in the connection between the DU providing the PCell and the CU, and not in the connection between the DU providing the SCell (hereinafter, SCell DU) and the CU, a bottleneck is likely to occur as the amount of data increases. For example, as the number of SCell DUs connected to a PCell DU increases or the number of SCells supported by the SCell DU increases, a bottleneck may occur due to the interface capacity between the PCell DU and the CU. In the embodiments of the present disclosure, a DU providing a PCell may also include an RLC entity connected to the PDCP layer of the CU. The SCell DU can perform data communication in the user plane through an F1-U connection with the CU. For example, an SCell DU can transmit an RLC SDU (or PDCP PDU) to a CU or receive a PDCP PDU from a CU through an RLC entity that connects to the PDCP layer of the CU in the user plane.

[0162] In the present disclosure, a network architecture, protocols, and procedures between nodes, including multiple DUs (e.g., a first DU (510), a second DU (520)) and a CU (e.g., a CU (505)) that constitute a network for carrier aggregation (CA) of a terminal (120), are described. For CA between DUs, it is assumed that all traffic is transmitted from the CU (505) to the first DU (510) (hereinafter, PCell DU or PCell-gNB-DU) that provides a PCell (primary cell). Thereafter, the first DU (510) can transmit traffic to the second DU (520) (hereinafter, SCell DU or SCell-gNB-DU) that provides a SCell (secondary cell). However, this structure requires the first DU (510) to perform traffic processing for all cells (e.g., one PCell and multiple SCells). Therefore, as the number of terminals configured with CA and / or the number of cells for CA increases, the packet processing capacity of the PCell may reach its limit. In addition, since CA traffic must be transmitted from the PCell DU to each SCell-DU, high capacity may be required at the interface between the DUs. According to embodiments of the present disclosure, the PCell DU can offload data traffic for CA to the SCell DU. This can prevent degradation of CA performance due to packet processing limitations in the PCell DU. In addition, as the data traffic is split in the CU, the split data traffic can be transmitted to each of the DUs for CA. As the data traffic between DUs for CA is eliminated, the capacity required at the interface between DUs can be reduced.

[0163] Fig. 6 illustrates an example of a control plane for spectrum aggregation between DUs. The spectrum aggregation between DUs may be referred to as CA using the DUs. A network (e.g., an access network of a base station (110)) may be provided through a structure in which one CU (e.g., CU (505)) and multiple DUs (e.g., first DU (510), second DU (520)) are connected to the CU. Cells provided by the DUs may be utilized for CA. For inter-DU CA, interfaces between DUs may be defined. The same reference numbers may be used to refer to the same description.

[0164] Referring to FIG. 6, the CU (505) may be responsible for the functions of the RRC (615) and the functions of the PDCP (614). Cells provided by the DUs may be used for CA. For inter-DU CA, an interface between the DUs may be defined. The CU (505) may be connected to the first DU (510) via an F1 interface. The F1 interface may include an F1-C interface (681) for the control plane and an F1-U interface (682) for the user plane. The CU (505) may be connected to the second DU (520) via an F1 interface. The F1 interface may include an F1-U interface (683) for the user plane.

[0165] The first DU (510) and the second DU (520) may be connected via an X1 interface. The X1 interface may include an X1-C interface (581) for a control plane and an X1-U interface (582) for a user plane. The first DU (510) may be a node providing a PCell of CA. The first DU (510) may be referred to as a PCell DU or a PCell-gNB-DU. The first DU (510) may include a MAC processing module (612), an RLC-H processing module (613a), an RLC-L processing module (613b), and a call processing block (671). The RLC-H processing module (613a) and the RLC-L processing module (613b) may be referred to as an RLC entity (613). The MAC processing module (612) may be configured to process functions of the MAC (422) and the MAC (472). The MAC processing module (612) may be referred to as a MAC entity (612). The RLC-H processing module (613a) and the RLC-L processing module (613b) may be configured to process functions of the RLC (423) and the RLC (473). Among the functions of the RLC (423) and the RLC (473), functions requiring real-time processing (e.g., TTI-based functions) may be processed in the RLC-L processing module (613b), and other functions requiring non-real-time processing may be processed in the RLC-H processing module (613a). The call processing block (671) may be configured to process parameters (e.g., RRC IEs) received from the CU (505) or parameters received from the second DU (520).

[0166] The second DU (520) may be a node that provides the SCell of the CA. The first DU (510) may be referred to as an SCell DU or an SCell-gNB-DU. The second DU (520) may include a MAC processing module (622), an RLC-H processing module (623a), an RLC-L processing module (623b), and a call processing block (672). The RLC-H processing module (623a) and the RLC-L processing module (623b) may be referred to as an RLC entity (623). The MAC processing module (622) may be configured to process the functions of the MAC (422) and the MAC (472). The MAC processing module (622) may be referred to as a MAC entity (622). The RLC-H processing module (623a) and the RLC-L processing module (623b) may be configured to process at least some of the functions of the RLC (423) and the RLC (473). The call processing block (672) may be configured to process parameters (e.g., RRC IEs) received from the CU (505) or parameters received from the first DU (510).

[0167] According to embodiments of the present disclosure, a CU (505) can transmit data to a terminal (e.g., terminal 120) configured with inter-DU CA through multiple DUs (e.g., first DU (510), second DU (520)) having independent RLC entities. The CU (505) can perform data transmission using multiple RLC entities. The terminal (120) can receive data through multiple RLC entities. For example, the CU (505) can split the data on the PDCP (614) and transmit the split data through each RLC entity. In addition, for example, the CU (505) can adaptively perform bearer switching while changing the RLC entity to transmit the data. Hereinafter, data transmission operations using multiple RLC entities (e.g., may be referred to as PDCP split and multiple RLC (PSMR) operations) are described in the present disclosure.

[0168] Figure 7a illustrates an example of bearer splitting between DUs (e.g., the first DU (510) and the second DU (520)). Data traffic for inter-DU CA may correspond to a data radio bearer. The same reference numbers may be used to refer to the same description.

[0169] Referring to FIG. 7A, data of a data radio bearer (799) can be transmitted from a CU (505) to each DU (e.g., a first DU (510), a second DU (520)). The CU (505) can segment data (e.g., a PDCP PDU) of the data radio bearer (799). The CU (505) can transmit the segmented data to each of the first DU (510) and the second DU (520). The RLC entity (613) of the first DU (510) can process the segmented data. The RLC entity (613) of the second DU (520) can process the segmented data. Transmission of the segmented data can be referred to as a bearer split.

[0170] Figure 7b illustrates an example of bearer switching between DUs (e.g., the first DU (510) and the second DU (520)). Data traffic for inter-DU CA may correspond to a data radio bearer. The same reference numbers may be used to refer to the same description.

[0171] Referring to FIG. 7b, data of a data radio bearer (799) can be transmitted from a CU (505) to each DU (e.g., a first DU (510), a second DU (520)). The CU (505) can change the path of data (e.g., a PDCP PDU) of the data radio bearer (799). For example, one of a plurality of DUs connected to the CU (505) based on the data radio bearer (799) can be selected. For example, the second DU (520) can be selected. All data of the radio bearer (799) can be transmitted to the RLC entity (623) of the second DU (520). The change of the RLC entity can be referred to as bearer switching.

[0172] In describing various operations, signaling, and / or protocols of the present disclosure, an example of a single SCell DU for inter-DU CA is described; however, embodiments of the present disclosure are not limited thereto. A structure in which a PCell DU and two or more SCell DUs are connected may also be understood as an embodiment of the present disclosure.

[0173] Figure 8 illustrates an example of a procedure for establishing multiple RLC (radio link control). In Figure 8, an E1 bearer setup procedure and an F1 UE context setup procedure may be performed to add a new SCell DU. Additionally, an X1 bearer context setup procedure may be performed between the PCell DU and the SCell DU to configure CA between the PCell DU and the SCell DU. Through the X1 bearer context setup procedure, multiple RLC entities may be established for the CA. The same reference numbers may be used to refer to the same description.

[0174] Referring to FIG. 8, a CU (505) may include a CU-CP (505a) and a CU-UP (505b). The CU-CP (505a) may correspond to a gNB-CU-CP. The CU-CP (505a) represents a logical node that hosts the control plane portion of the RRC and PDCP protocols of a gNB-CU for an en-gNB or gNB. The CU-CP (505a) may be connected to the CU-UP (505b) via an E1 interface and to a gNB-DU via an F1-C interface. In DC operation, the MgNB-CU-CP represents the gNB-CU-CP of the gNB-CU for the en-gNB or gNB acting as a master node, and the SgNB-CU-CP represents the gNB-CU-CP of the gNB-CU for the en-gNB or gNB acting as a secondary node. The CU-UP (505b) represents a logical node that hosts the user plane portion of the PDCP protocol of the gNB-CU for the en-gNB and the user plane portions of the PDCP protocol and SDAP protocol of the gNB-CU for the gNB. The CU-UP (505b) can be connected to the CU-CP (505a) via an E1 interface. The CU-UP (505b) can be connected to the gNB-DU via an F1-U interface. In DC operation, the MgNB-CU-UP represents the gNB-CU-UP of the gNB-CU for the en-gNB or the gNB acting as a master node, and the SgNB-CU-UP represents the gNB-CU-UP of the gNB-CU for the en-gNB or the gNB acting as a secondary node.

[0175] In operation (801), the CU-CP (505a) may transmit an E1 bearer setup request message to the CU-UP (505b). Although not shown in FIG. 8, as a non-limiting example, the CU-CP (505a) may check whether the PDCP split mode for CA is enabled (e.g., is in the On state). For example, the CU-CP (505a) may determine whether the PDCP split mode for CA is enabled (e.g., is in the On state) by checking the parameter values ​​of the YANG (yet another next generation) model. If the PDCP split mode for CA is enabled and the SCell is an SCell for inter-DU CA, the CU-CP (505a) may request the CU-CU-UP (505b) to configure separated F1 tunnels in the user plane. The E1 bearer setup request message may include information for requesting the number of F1 tunnels. For example, when inter-DU CA is established, the number of F1 tunnels may be 2 or more. For example, the F1 tunnels may include a tunnel between a first DU (510) and a CU (505) (e.g., CU-UP (505b)) and a tunnel between a second DU (520) and a CU (505) (e.g., CU-UP (505b)). In one embodiment, when the CU-CP (505a) wants to add a DU that provides an SCell for inter-DL CA, it may transmit an E1 bearer setup request message when 1) the CA PDCP split flag is set to on or 2) the CA PDCP split flag is set to on and the SCell corresponds to the SCell for inter-DU CA. The number of F1 tunnels for the SCell DU may be requested through the E1 bearer setup request message. The above E1 bearer setup request message may include a 'PDU Session Resource To Setup List' IE (information element).The 'PDU Session Resource To Setup List' IE includes a 'Cell Group list' IE, and the 'Cell Group list' IE may include information about a cell group ID indicating an 'MCG (master cell group)' and the number of F1 tunnels that are '2' in the MCG. It is assumed that the CU (505) corresponds to the MCG.

[0176] In operation (802), the CU-UP (505b) may transmit an E1 bearer setup response message to the CU-CP (505a). The E1 bearer setup response message may include a 'PDU Session Resource Setup List' IE. The 'PDU Session Resource Setup List' IE may include a 'UL UP Parameters' IE, and the 'UL UP Parameters' IE may include transport layer information (e.g., 'UP Transport Layer Information' IE) and a cell group ID. The cell group ID may indicate an MCG. The transport layer information may include a first IP address and a second IP address. The first IP address may indicate an IP address of an uplink path between the first DU (510) and the CU (505). The second IP address may indicate an IP address of an uplink path between the second DU (520) and the CU (505).

[0177] In operation (820), the CU (505) (e.g., CU-CP (505a)) may transmit a UE context setup request message to the first DU (510) (e.g., call processing block (671)). The UE context setup request message may be transmitted over the F1 interface. For example, the UE context setup request message may be transmitted over the F1-C interface in the control plane. The UE context setup request message may be transmitted to the first DU (510) having the F1-C connection to configure carrier aggregation (CA) for PCell and SCell. The UE context setup request message may include UL UP (user plane) parameters (e.g., IP address). For example, the UE context setup request message may include a 'DRB to Be Setup List' IE. The 'DRB to Be Setup List' IE may include the 'UL UP TNL Information to be setup List' IE. The 'UL UP TNL Information to be setup List' IE may include UL (uplink) UP (user plane) TNL (transport network layer) information. The UL UP TNL information may include the first IP address and the second IP address. In addition, the UE context setup request message may include a PDCP SN length (e.g., DL PDCP SN Length). The first IP address may be used for uplink transmission between the first DU (510) and the CU (505) (e.g., CU-UP (505b)) in the user plane. For example, the first IP address may be used for a GTP (GPRS (General Packet Radio Service) Tunneling Protocol) tunnel using the first DU (510) in the user plane.On the control plane, the PCell DU and CU can communicate, and on the user plane, the PCell DU and CU can exchange IP addresses for establishing F1-U to perform communication. The second IP address can be used for uplink transmission between the second DU (520) and the CU (505) (e.g., CU-UP (505b)) on the user plane. For example, the second IP address can be used for a GTP tunnel using the second DU (520) on the user plane.

[0178] In operation (831), the first DU (510) (e.g., call processing block (671)) may transmit an SCell setup request message to the second DU (520) (e.g., call processing block (672)). The SCell setup request message may include an SCell RLC indicator (e.g., information for configuring an SCell to an RLC entity), PCell RLC configuration information (e.g., parameter(s) related to an RLC entity in the PCell DU), a serving cell list, bearer configuration information (e.g., signaling radio bearer (SRB) configuration information, DRB configuration information), and / or X1-U IP address information of the first DU (510) (e.g., a source X1-U IP address). The SCell RLC indicator may be used to configure an RLC entity in the second DU (520). The RLC entity in the second DU (520) may be used for inter-DU CA together with the RLC entity in the first DU (510). The SCell setup request message may also be referred to as an X1 SCell configuration request message. The SCell setup request message may be replaced with an X1 SCell modification request message or an X1 SCell configuration update message.

[0179] In operation (832), the second DU (520) (e.g., call processing block (672)) may transmit an SCell setup response message to the first DU (510) (e.g., call processing block (671)). The second DU (520) may create an RLC entity and a MAC entity for the SCell within the second DU (520) based on the SCell setup request message. In response to the SCell setup request message, the second DU (520) may transmit the SCell setup response message. The SCell setup response message may include a successful SCell list, a failed SCell list, X1-U UP address information of the second DU (520) (e.g., target X1-U IP address), address information of the SCell MAC entity (e.g., IP address), and / or address information of the SCell RLC entity (e.g., IP address, DL UP IP address). The above SCell setup response message may also be referred to as an X1 SCell configuration response message. The above SCell setup response message may be replaced with an X1 SCell modification confirmation / response message or an X1 SCell configuration update confirmation message.

[0180] In operation (842), the first DU (510) (e.g., call processing block (671)) may transmit a UE context setup response message to the CU (505) (e.g., CU-CP (505a)). When the setup procedure between the first DU (510) and the second DU (520) is completed, the first DU (510) may transmit a UE context setup response message to the CU (505) that includes information about DL UP parameters (e.g., IP address) for inter-DU CA. For example, the UE context setup response message may include a third IP address and a fourth IP address. The third IP address may indicate an IP address of a downlink path between the first DU (510) and the CU (505). The fourth IP address may indicate an IP address of a downlink path between the second DU (520) and the CU (505). For example, the UE context setup response message may include a 'DL UP TNL Information to be setup List' IE. The 'DL UP TNL Information to be setup List' IE may include the third IP address and the fourth IP address. The third IP address may be used for downlink transmission between the first DU (510) and the CU (505) (e.g., CU-UP (505b)) in the user plane. As an example, the third IP address may be used for a GTP tunnel using the first DU (520) in the user plane. The fourth IP address may be used for downlink transmission between the second DU (520) and the CU (505) (e.g., CU-UP (505b)) in the user plane. As an example, the fourth IP address may be used for a GTP tunnel using the second DU (520) in the user plane.

[0181] In operation (851), the CU-CP (505a) may transmit an E1 bearer modification request message to the CU-UP (505b). The E1 bearer modification request message may include a 'DRB To Modify List' IE. The 'DRB To Modify List' IE may include information about DL UP parameters. The information about the DL UP parameters may include information about UP transport layer information and cell group ID. For example, the UP transport layer information may include a third IP address and a fourth IP address. The information about the cell group ID indicates a cell group of each IP address, and all of them may point to 'MCG'.

[0182] In operation (852), the CU-UP (505b) may transmit an E1 bearer modification response message to the CU-CP (505a). The CU-UP (505b) may transmit the E1 bearer modification response message in response to an E1 bearer modification request message including information about DL UP parameters.

[0183] Through the above-described procedures, inter-DU CA using the first DU (510) and the second DU (520) can be configured. A network-side (e.g., the first DU (510) and the second DU (520)) setup procedure for inter-DU CA can be performed on the UE. Through signaling for adding SCell DUs, F1-U connections for the CA can be established. Although not illustrated in FIG. 8, after operation (852), the terminal (120) can be configured to perform inter-DU CA using the first DU (510) and the second DU (520) through an RRC reconfiguration procedure between the CU (505) and the terminal (e.g., the terminal (120)). Although the E1 bearer setup procedure and the F1 UE context update procedure are illustrated in FIG. 8, embodiments of the present disclosure are not limited thereto. To add a SCell DU, the E1 bearer modification procedure and / or the F1 UE context update procedure may be used instead.

[0184] In Fig. 8, a series of procedures for setting up a PCell DU and a SCell DU for inter-DU CA are described. The above procedures were performed by a UE context setup procedure. Since the F1-C connection is performed through the PCell DU, a UE context setup procedure was performed between the first DU (510), which is a PCell DU, and the CU (505). The parameters, information, and / or messages mentioned in Fig. 8 can also be used for a procedure for modifying a UE context related to inter-DU CA using the PCell DU and the SCell DU. For example, to modify a UE context related to a currently configured inter-DU CA, the CU-CP (550a) can transmit a UE context modification request message to the first DU (510). As an example, the modification can be used to modify resources related to the SCell of the second DU (520), which is an SCell DU. The first DU (510) can perform an SCell modification procedure with the second DU (520). The first DU (510) can transmit an SCell modification request message to the second DU (520). The SCell modification request message can include an SCell RLC indicator (e.g., information for configuring an SCell to an RLC entity), PCell RLC configuration information (e.g., parameter(s) related to an RLC entity in the PCell DU), a serving cell list, bearer configuration information (e.g., signaling radio bearer (SRB) configuration information, DRB configuration information), and / or X1-U IP address information of the first DU (510) (e.g., a source X1-U IP address). The SCell RLC indicator can be used to configure an RLC entity in the second DU (520). The second DU (520) can transmit an SCell modification response message to the first DU (510).The SCell Modification Response message may include a modified SCell list, a SCell list for which modification failed, X1-U UP address information of the second DU (520) (e.g., target X1-U IP address), address information of the SCell MAC entity (e.g., IP address), and / or address information of the SCell RLC entity (e.g., IP address, DL UP IP address). Thereafter, the first DU (510) may transmit a UE context modification response message to the CU-CP (550a). The UE context modification response message may include information on DL UP parameters (e.g., IP address) for inter-DU CA. For example, the UE context modification response message may include a third IP address and a fourth IP address.

[0185] These procedures can be used in the same manner when adding, modifying, or releasing SCell DUs in CA between DUs. For example, procedures can be performed between CU-CP (550a), CU-UP (550b), first DU (510), and second DU (520) to support releasing SCell DUs. When releasing SCell DUs, CU-CP (550a) can reduce the number of F1 tunnels by the number of SCell DUs to be released and can notify CU-UP (550b) of the information about the number of F1 tunnels through an E1 bearer modification request procedure. The E1 bearer modification request message can include information about the number of F1 tunnels. The CU-UP (550b) may transmit an E1 bearer modification response message including UL UP parameters with the IP address information of the SCell DU removed to the CU-CP (550a) to remove the F1 tunnel for the SCell DU to be released. The CU-CP (550a) may transmit the UL UP parameters to the first DU (510), which is a PCell DU, via an F1 UE context modification request message. The first DU (510) may perform an SCell configuration de-configuration procedure with the second DU (520), which is the SCell DU to be removed. Through the SCell configuration de-configuration procedure, the SCell DU may be removed from the list for inter-DU CA. The first DU (510) may transmit an F1 UE context modification response message to the CU-CP (550a). Through the above procedure, the F1-U connection between the CU (505) and the second DU (520) may be removed.

[0186] Figure 9 illustrates an example of a protocol of a network entity for multiple RLCs. The same reference numerals may be used to refer to the same description. In one embodiment, a CU (505) (e.g., CU-UP (505b)) may receive uplink data (e.g., PDCP PDU) from a first DU (510) based on a first IP address. In one embodiment, a CU (505) (e.g., CU-UP (505b)) may receive uplink data (e.g., PDCP PDU) from a second DU (520) based on a second IP address. In one embodiment, a first DU (510) may receive downlink data (e.g., PDCP PDU) from a CU (505) (e.g., CU-UP (505b)) based on a third IP address. In one embodiment, the second DU (520) may receive downlink data (e.g., PDCP PDU) from the CU (505) (e.g., CU-UP (505b)) based on the fourth IP address.

[0187] Referring to FIG. 9, the CU (505) may be responsible for the functions of the RRC (615) and the functions of the PDCP (614). The first DU (510) may be a node providing a PCell of the CA. The first DU (510) may include a MAC processing module (612), an RLC-H processing module (613a), and an RLC-L processing module (613b). The second DU (520) may be a node providing a SCell of the CA. The second DU (520) may include a MAC processing module (622), an RLC-H processing module (623a), and an RLC-L processing module (623b). The CU (505) may be connected to the first DU (510) via an F1 interface (e.g., an F1-C interface (681), an F1-U interface (682)). The CU (505) may be connected to the second DU (520) via an F1 interface (e.g., an F1-U interface (683)). The first DU (510) and the second DU (520) may be connected via an X1 interface (e.g., an X1-C interface (581), an X1-U interface (582)). For example, the first DU (510) may receive data from the second DU (520) on the X1-U interface (582) based on a source X1-U IP address of the first DU (510). For example, the second DU (520) may receive data from the first DU (510) on the X1-U interface (582) based on a target X1-U IP address of the second DU (520).

[0188] According to one embodiment, the RLC-H processing module (613a) of the first DU (610) may be configured to perform at least some of the functions of an RLC entity. For example, the RLC-H processing module (613a) of the first DU (610) may be configured to perform functions of SN numbering, headering, UL ARQ reporting, UL reassembly, PCell DL ARQ, and / or segmentation. According to one embodiment, the RLC-L processing module (613b) of the first DU (610) may be configured to perform at least some of the functions of an RLC entity. For example, the RLC-L processing module (613b) of the first DU (610) may be configured to perform functions of segmentation. The RLC-H processing module (613a) of the first DU (610) is an RLC entity and can transmit and receive signals with the RLC-H processing module (623a) of the second DU (620) via an X1 interface (e.g., X1-U interface (582)). Bearer traffic for CA can be transmitted between the RLC-H processing module (613a) and the RLC-L processing module (613b) in the first DU (610).

[0189] According to one embodiment, the RLC-H processing module (623a) of the second DU (620) may be configured to perform at least some of the functions of an RLC entity. For example, the RLC-H processing module (623a) of the second DU (620) may be configured to perform functions of SN numbering, headering, SCell DL ARQ, and / or segmentation. According to one embodiment, the RLC-L processing module (623b) of the second DU (620) may be configured to perform at least some of the functions of an RLC entity. For example, the RLC-L processing module (623b) of the second DU (620) may be configured to perform functions of segmentation. The RLC-H processing module (623a) of the second DU (620) is an RLC entity and can transmit and receive signals with the RLC-H processing module (613a) of the first DU (610) via an X1 interface (e.g., X1-U interface (582)). Bearer traffic for CA can be transmitted between the RLC-H processing module (623a) and the RLC-L processing module (623b) in the second DU (620).

[0190] Figure 10 illustrates an example of multi-path flow control for multiple RLCs. Like reference numerals may be used to refer to like descriptions.

[0191] Referring to FIG. 10, the CU (505) may be responsible for the functions of the PDCP (614). The CU (505) may be connected to one or more DUs. For example, the CU (505) may be connected to the PCell DU (510), the first SCell DU (1021), the second SCell DU (1022), and / or the third SCell DU (1023). The PCell DU (510) may provide a PCell in inter-DU CA. The PCell DU (510) may include an RLC entity (613) (e.g., an RLC-H processing module (613a), an RLC-L processing module (613b)). The first SCell DU (1021) may include an RLC entity (1031) (e.g., an RLC-H processing module (623a), an RLC-L processing module (623b)). The second SCell DU (1022) may include an RLC entity (1032) (e.g., an RLC-H processing module (623a), an RLC-L processing module (623b)). The third SCell DU (1023) may include an RLC entity (1033) (e.g., an RLC-H processing module (623a), an RLC-L processing module (623b)). The first SCell DU (1021), the second SCell DU (1022), and / or the third SCell DU (1023) may provide SCells in inter-DU CA, such as a PCell DU (510). To provide inter-DU CA, each SCell DU connected to a CU (505) may include an RLC entity (e.g., an RLC-H processing module (623a), an RLC-L processing module (623b)). As the SCell DU functions as an independent RLC entity, an F1-U connection may be established between the PDCP (614) of the CU (505) and the SCell DU.

[0192] The PDCP (614) of the CU (505), i.e., the PDCP entity, may be connected to multiple RLC entities. The CU (505) may distribute data to the multiple RLC entities. According to one embodiment, the CU (505) may split data of the DRB and transmit the split data to each of the PCell DU (510), the first SCell DU (1021), the second SCell DU (1022), and / or the third SCell DU (1023). As multiple RLC entities are operated, instead of multiple paths through which data is transmitted being concentrated to a specific DU (e.g., the PCell DU (510)), the data may be distributed through multiple paths. Through flow control using the multiple RLC entities, not only can the data transmission speed be improved, but also efficient operation of the X1 interface may be possible as traffic on the X1 interface is reduced.

[0193] Figure 11 illustrates an example of radio link outage (RLO) control in a multi-RLC. The same reference numerals may be used to refer to the same description. In one embodiment, the CU (505) (e.g., CU-UP (505b)) may receive uplink data (e.g., PDCP PDU) from the first DU (510) based on a first IP address. In one embodiment, the CU (505) (e.g., CU-UP (505b)) may receive uplink data (e.g., PDCP PDU) from the second DU (520) based on a second IP address. In one embodiment, the first DU (510) may receive downlink data (e.g., PDCP PDU) from the CU (505) (e.g., CU-UP (505b)) based on a third IP address. In one embodiment, the second DU (520) may receive downlink data (e.g., PDCP PDU) from the CU (505) (e.g., CU-UP (505b)) based on the fourth IP address.

[0194] Referring to FIG. 11, the CU (505) may be responsible for the functions of the PDCP (614). The CU (505) may be connected to one or more DUs. For example, the CU (505) may be connected to a first DU (510) and a second DU (520). The first DU (510) may include an RLC entity (613) (e.g., an RLC-H processing module (613a), an RLC-L processing module (613b)). The second DU (520) may include an RLC entity (623) (e.g., an RLC-H processing module (623a), an RLC-L processing module (623b)). The first DU (510) and the second DU (520) can be connected via an X1 interface (e.g., an X1-C interface (581), an X1-U interface (582)). For example, the first DU (510) can receive data from the second DU (520) on the X1-U interface (582) based on a source X1-U IP address of the first DU (510). For example, the second DU (520) can receive data from the first DU (510) on the X1-U interface (582) based on a target X1-U IP address of the second DU (520).

[0195] The CU (505) can transmit data through the first DU (510) or the second DU (520). For example, the CU (505) can transmit a PDCP SDU with SN=1 through the F1-U interface (682). The CU (505) can transmit a PDCP SDU with SN=2 through the F1-U interface (682). For example, the CU (505) can transmit a PDCP SDU with SN=3 through the F1-U interface (683). The CU (505) can transmit a PDCP SDU with SN=4 through the F1-U interface (683). The reception of the PDCP SDU with SN=3 may be acknowledged, but the reception of the PDCP SDU with SN=4 may not be acknowledged. The CU (505) can receive a message (1110) (e.g., a downlink data delivery status (DDDS) message) including an RLO (radio link outage) indicator from the second DU (520). The message (1110) can include an RLO indicator and / or an RLO cause value. The cause value of the DDDS message indicates a specific event reported from the second DU (520). For example, if the cause value is '0', it indicates 'unknown'. If the cause value is '1', it indicates 'RLO (radio link outage)'. If the cause value is '2', it indicates 'RADIO LINK RESUME'. If the cause value is '3', it indicates 'UL RADIO LINK OUTAGE'. If the cause value is '4', it indicates 'DL RADIO LINK OUTAGE'. If the cause value is '5', it indicates 'UL RADIO LINK RESUME'. If the above cause value is '6', it indicates 'DL RADIO LINK RESUME'. The CU (505) can perform pass switching (1120) based on the message (1110). The CU (505) can retransmit unacknowledged PDCP SDUs.CU (505) can perform data recovery after pass switching (1120). For example, CU (505) can transmit PDCP SDU with SN=4 to DU (510) through F1-U interface (682).

[0196] Although not shown in FIG. 11, the CU (505) may reuse the excluded branch (e.g., the F1 connection between the CU (505) and the second DU (520)) if it receives an indication of a resume after an RLO or a message containing a DL resume cause value. For example, the CU (505) may transmit data to the second DU (520) via the F1-U interface (683) between the CU (505) and the second DU (520).

[0197] Figure 12 illustrates an example of retransmission due to release of a SCell (secondary cell) path in a multi-RLC. The same reference numerals may be used to refer to the same description. According to one embodiment, the CU (505) (e.g., CU-UP (505b)) may receive uplink data (e.g., PDCP PDU) from the first DU (510) based on a first IP address. According to one embodiment, the CU (505) (e.g., CU-UP (505b)) may receive uplink data (e.g., PDCP PDU) from the second DU (520) based on a second IP address. According to one embodiment, the first DU (510) may receive downlink data (e.g., PDCP PDU) from the CU (505) (e.g., CU-UP (505b)) based on a third IP address. In one embodiment, the second DU (520) may receive downlink data (e.g., PDCP PDU) from the CU (505) (e.g., CU-UP (505b)) based on the fourth IP address.

[0198] Referring to FIG. 12, the CU (505) may be responsible for the functions of the PDCP (614). The CU (505) may include a CU-CP (505a) and a CU-CP (505b). The PDCP (614) may include a CP portion and an UP portion. The CU (505) may be connected to one or more DUs. For example, the CU (505) may be connected to a first DU (510) and a second DU (520). The first DU (510) may include an RLC entity (613) (e.g., an RLC-H processing module (613a), an RLC-L processing module (613b)). The second DU (520) may include an RLC entity (623) (e.g., an RLC-H processing module (623a), an RLC-L processing module (623b)). The first DU (510) and the second DU (520) can be connected via an X1 interface (e.g., an X1-C interface (581), an X1-U interface (582)). For example, the first DU (510) can receive data from the second DU (520) on the X1-U interface (582) based on a source X1-U IP address of the first DU (510). For example, the second DU (520) can receive data from the first DU (510) on the X1-U interface (582) based on a target X1-U IP address of the second DU (520).

[0199] The CU (505) can transmit data through the first DU (510) or the second DU (520). For example, the CU (505) can transmit a PDCP SDU with SN=1 through the F1-U interface (682). The CU (505) can transmit a PDCP SDU with SN=2 through the F1-U interface (682). For example, the CU (505) can transmit a PDCP SDU with SN=3 through the F1-U interface (683). The CU (505) can transmit a PDCP SDU with SN=4 through the F1-U interface (683). The reception of the PDCP SDU with SN=3 may be acknowledged, but the reception of the PDCP SDU with SN=4 may not be acknowledged. The CU (505) may decide to release a SCell DU (e.g., the second DU (520)). For example, the CU-CP (505a) may send a SCell DU release message (1210) to the CU-UP (505b). The CU-UP (505b) may release the F1-U connection. Accordingly, the CU (505) may perform pass switching (1220). The CU (505) may perform data recovery after the pass switching (1220). The CU (505) may retransmit unacknowledged PDCP SDUs. For example, the CU (505) may transmit a PDCP SDU with SN=4 to the DU (510) via the F1-U interface (682).

[0200] Although not shown in Fig. 12, the CU-CP (505a) can send an SCell DU addition message to the CU-UP (505b) not only when the SCell DU is released but also when the SCell DU is added. The CU-UP (505b) can create an F1-U connection. The CU-UP (505b) can transmit data for inter-DU CA through the created F1-U connection.

[0201] Figure 13 illustrates an example of SN (serial number) synchronization information. The same reference numbers may be used to refer to the same description.

[0202] When only the first DU (510), which is a PCell DU, is in charge of all RLC entities, the first DU (510) manages all synchronization for the PCARQ procedure (e.g., ACK / NACK). However, when an F1-U connection is established between the CU (505) and the second DU (520), which is an Scell ​​DU, the two RLC entities (e.g., the RLC entity of the first DU (510) and the RLC entity of the second DU (520)) are divided from the PDCP layer, and thus a synchronization problem may occur. In order to resolve the problem of data synchronization being different between different DUs, the CU (505) according to embodiments of the present disclosure may include synchronization information in the data frame when transmitting the data frame. An example of the synchronization information is described below with reference to FIG. 13.

[0203] Referring to FIG. 13, a DL USER DATA frame (1300) may have a predefined format. The DL USER DATA frame (1300) according to embodiments of the present disclosure may include SN synchronization information. The SN synchronization information may include information indicating whether SN synchronization information is transmitted (hereinafter, synchronization flag, 'SN Sync Info' IE), information on the SN of the PDCP PDU transmitted for the first time after the E1 procedure (hereinafter, start SN information, 'Initial NR PDCP PDU SN' IE), and / or information on the number of rotations of the SN of the PDCP PDU (hereinafter, circulation information, 'Number of around of PDCP SN' IE). The synchronization flag may indicate whether the SN synchronization information is transmitted. The synchronization flag may correspond to 1 bit. When the synchronization flag is 0, the synchronization flag may indicate that SN synchronization information does not exist. When the above synchronization flag is 1, the synchronization flag may indicate that SN synchronization information exists. For example, the SN synchronization information may be referenced as follows.

[0204] - SN Sync Info :- Description: This parameter indicates whether SN Sync Information is transmitted. In other words, the information can indicate whether synchronization information is included in the frame.- Value range: {0= SN Sync Information not present, 1= SN Sync Information present}.- Field length: 1 bit.

[0205] The above start SN information may indicate the SN of the PDCP PDU transmitted first after the E1 procedure. For example, the above start SN information may be referenced as follows.

[0206] - Initial NR PDCP PDU SN- Description: This parameter is the SN information of the first outgoing PDCP PDU after the E1 procedure.- Value range: {0..218-1}..- Field length: 3 octets.

[0207] For example, the above-mentioned start SN information may indicate the SN of the first PDCP PDU transmitted after the setup of CA between CU and DU is completed. As a non-limiting example, the E1 procedure is a procedure between CU-CP (505a) and CU-UP (505b), and when the setup of CA between DUs is completed, the CU-CP (505a) may notify the CU-UP (505b) that the setup of CA between DUs is completed through the E1 bearer context setup modification procedure.

[0208] The above circular information indicates the number of times the SN of the PDCP PDU is rotated and repeated. For example, the circular information can be referenced as follows.

[0209] - Number of around PDCP SN- Description: This parameter is the number of times the SN of the PDCP PDU is around.- Value range: {1..244}.- Field length: 1 octet.

[0210] More precisely, the above cyclic information may indicate the number of modulo cycles. PDCP PDUs may be renumbered based on modulo operations. Each time a modulo cycle is repeated (e.g., starting from 0 after reaching the maximum value corresponding to the length), the value may increase by 1.

[0211] The CU (505) may transmit a DL USER DATA frame (1300) to the first DU (510) or the second DU (520). In one embodiment, the CU (505) may transmit the DL USER DATA frame (1300) to the first DU (510) or the second DU (520) when performing a handover without PDCP reset. In one embodiment, the CU (505) may transmit the DL USER DATA frame (1300) to the first DU (510) or the second DU (520) when a new F1-U connection is established (e.g., a SCell DU for inter-DU CA is added). As a non-limiting example, the DL USER DATA frame (1300) may be transmitted only to the second DU (520), which is a newly added SCell DU. According to one embodiment, the CU (505) may transmit a DL USER DATA frame (1300) to the first DU (510) or the second DU (520) after the initial PDCP setup if the SN is cyclic (e.g., if the SN reaches the maximum value (e.g., 4096) and starts from 0 again according to modulo operation). The DL USER DATA frame (1300) may include SN synchronization information including a synchronization flag (e.g., SN Sync Info = 1), start SN information (e.g., 'Initial NR PDCP PDU SN' IE), and / or cyclic information (e.g., 'Number of around of PDCP SN' IE).

[0212] In addition to the IEs described above, the 3GPP TS 38.425 specification may be referenced for a description of each IE of the DL USER DATA frame (1300).

[0213] The first DU (510) can manage the ordering of data by calculating and reassembling the RLC SN for the data based on the information included in the data frame (e.g., the DL USER DATA frame (1300)). The second DU (510) can manage the ordering of data by calculating and reassembling the RLC SN for the data based on the information included in the data frame (e.g., the DL USER DATA frame (1300)). Data between different DUs performing inter-DU CA can be synchronized (in-sync).

[0214] FIG. 14 illustrates an example of downlink transmission using SN synchronization information (e.g., synchronization information of a DL USER DATA frame (1300)) in a multi-RLC. The same reference numbers may be used to refer to the same description. According to one embodiment, the CU (505) (e.g., CU-UP (505b)) may receive uplink data (e.g., PDCP PDU) from the first DU (510) based on a first IP address. According to one embodiment, the CU (505) (e.g., CU-UP (505b)) may receive uplink data (e.g., PDCP PDU) from the second DU (520) based on a second IP address. According to one embodiment, the first DU (510) may receive downlink data (e.g., PDCP PDU) from the CU (505) (e.g., CU-UP (505b)) based on a third IP address. In one embodiment, the second DU (520) may receive downlink data (e.g., PDCP PDU) from the CU (505) (e.g., CU-UP (505b)) based on the fourth IP address.

[0215] Referring to FIG. 14, the CU (505) may be responsible for the functions of the PDCP (614). The CU (505) may include a CU-CP (505a) and a CU-CP (505b). The PDCP (614) may include a CP portion and an UP portion. The CU (505) may be connected to one or more DUs. For example, the CU (505) may be connected to a first DU (510) and a second DU (520). The first DU (510) may include an RLC entity (613) (e.g., an RLC-H processing module (613a), an RLC-L processing module (613b)). The second DU (520) may include an RLC entity (623) (e.g., an RLC-H processing module (623a), an RLC-L processing module (623b)). The first DU (510) and the second DU (520) can be connected via an X1 interface (e.g., an X1-C interface (581), an X1-U interface (582)). For example, the first DU (510) can receive data from the second DU (520) on the X1-U interface (582) based on a source X1-U IP address of the first DU (510). For example, the second DU (520) can receive data from the first DU (510) on the X1-U interface (582) based on a target X1-U IP address of the second DU (520).

[0216] The CU (505) can transmit data via the first DU (510) or the second DU (520). For example, the CU (505) can transmit a PDCP SDU with SN=1 via the F1-U interface (682). The CU (505) can transmit a PDCP SDU with SN=2 via the F1-U interface (682). For example, the CU (505) can transmit a PDCP SDU with SN=3 via the F1-U interface (683). The CU (505) can transmit a PDCP SDU with SN=4 via the F1-U interface (683). The first DU (510) can receive a data message (1410) from the CU (505). The data message (1410) can have a format such as a DL USER DATA frame (1300). The second DU (520) can receive a data message (1420) from the CU (505). The data message (1420) can have the same format as a DL USER DATA frame (1300).

[0217] The RLC-H processing module (613a) can perform the functions of SN numbering and headering. The RLC-H processing module (613a) can perform SN numbering based on a data message (1410). The RLC-H processing module (623a) can perform the functions of SN numbering and headering. The RLC-H processing module (623a) can perform SN numbering based on a data message (1420). A DU (e.g., an RLC-H processing module) can perform RLC SN coordination between multiple RLCs. Each DU can independently perform SN numbering. Since it knows information about SNs in PDCP, it can perform SN numbering. The DU can compare the PDCP SN length with the RLC SN length. According to one embodiment, the DU can determine the RLC SN based on the type of UE when the PDCP SN length is equal to the RLC SN length. For example, when the UE is initially connected, the DU can determine the PDCP SN as the RLC SN. For example, when the UE performs a handover without PDCP reset, the DU can determine the RLC SN by subtracting the SN of the start SN information from the PDCP SN. For example, the DU can determine the RLC SN according to the following mathematical equation.

[0218] <Mathematical Formula 1>

[0219] RLC SN = PDCP SN - Initial NR PDCP PDU SN

[0220] 'RLC SN' indicates RLC SN, 'PDCP SN' indicates PDCP SN, and 'Initial NR PDCP PDU SN' indicates starting SN information in a data message (e.g., DL USER DATA frame (1300)).

[0221] For example, when a UE is configured with inter-DU CA (e.g., a new F1-U connection is established or an SCell DU is added for inter-DU CA), the DU can be determined as an RLC SN by subtracting the SN of the start SN information from the PDCP SN (see [Equation 1]). For example, when the PDCP SN is cyclic, the DU can be determined as an RLC SN by subtracting the SN of the start SN information from the PDCP SN (see [Equation 1]).

[0222] In one embodiment, the DU may determine the RLC SN based on the type of the UE, if the PDCP SN length (e.g., 18 bits) is greater than the RLC SN length (e.g., 12 bits). For example, if the UE is initially attached, the DU may determine the RLC SN by subtracting the number of cycles indicated by the cyclic information from the PDCP SN multiplied by 4096. For example, the DU may determine the RLC SN according to the following mathematical equation.

[0223] <Mathematical Formula 2>

[0224] RLC SN = PDCP SN - 4096 * Number of around of PDCP SN

[0225] 'RLC SN' indicates RLC SN, 'PDCP SN' indicates PDCP SN, and 'Number of around of PDCP SN' indicates circular information within a data message (e.g., DL USER DATA frame (1300)).

[0226] For example, when the UE performs a handover without PDCP reset, the DU can determine the RLC SN by adding the SN of the start SN information to the PDCP SN and subtracting the value obtained by multiplying the number of cycles indicated by the cyclic information by 4096. For example, when inter-DU CA is configured for the UE (e.g., a new F1-U connection is established or an SCell DU is added for inter-DU CA), the DU can determine the RLC SN by adding the SN of the start SN information to the PDCP SN and subtracting the value obtained by multiplying the number of cycles indicated by the cyclic information by 4096. For example, when the PDCP SN has cyclically cyclic, the DU can determine the RLC SN by adding the SN of the start SN information to the PDCP SN and subtracting the value obtained by multiplying the number of cycles indicated by the cyclic information by 4096. For example, the DU can determine the RLC SN according to the following mathematical equation.

[0227] <Mathematical Formula 3>

[0228] RLC SN = PDCP SN - 4096 * Number of around of PDCP SN + Initial NR PDCP PDU SN

[0229] 'RLC SN' represents RLC SN, 'PDCP SN' represents PDCP SN, 'Number of around of PDCP SN' represents circular information within a data message (e.g., DL USER DATA frame (1300)), and 'Initial NR PDCP PDU SN' represents start SN information within a data message (e.g., DL USER DATA frame (1300)).

[0230] In one embodiment, the DU may determine the RLC SN based on the type of the UE, if the PDCP SN length (e.g., 12 bits) is less than the RLC SN length (e.g., 18 bits). For example, if the UE is initially attached, the DU may determine the RLC SN by adding the product of the number of cycles indicated by the cyclic information in the PDCP SN and 4096. For example, the DU may determine the RLC SN according to the following mathematical equation.

[0231] <Mathematical Formula 4>

[0232] RLC SN = PDCP SN + 4096 * Number of around of PDCP SN

[0233] 'RLC SN' indicates RLC SN, 'PDCP SN' indicates PDCP SN, and 'Number of around of PDCP SN' indicates circular information within a data message (e.g., DL USER DATA frame (1300)).

[0234] For example, when the UE performs a handover without PDCP reset, the DU can determine the RLC SN by adding the SN of the start SN information to the PDCP SN and multiplying the number of cycles indicated by the cyclic information by 4096. For example, when inter-DU CA is configured for the UE (e.g., a new F1-U connection is established or an SCell DU is added for inter-DU CA), the DU can determine the RLC SN by adding the SN of the start SN information to the PDCP SN and multiplying the number of cycles indicated by the cyclic information by 4096. For example, when the PDCP SN has cyclically cyclic, the DU can determine the RLC SN by adding the SN of the start SN information to the PDCP SN and multiplying the number of cycles indicated by the cyclic information by 4096. For example, the DU can determine the RLC SN according to the following mathematical equation.

[0235] <Mathematical Formula 5>

[0236] RLC SN = PDCP SN + 4096 * Number of around of PDCP SN + Initial NR PDCP PDU SN

[0237] 'RLC SN' represents RLC SN, 'PDCP SN' represents PDCP SN, 'Number of around of PDCP SN' represents circular information within a data message (e.g., DL USER DATA frame (1300)), and 'Initial NR PDCP PDU SN' represents start SN information within a data message (e.g., DL USER DATA frame (1300)).

[0238] Figure 15 illustrates an example of a per-DU automatic repeat request (ARQ) operation in a multi-RLC. The same reference numerals may be used to refer to the same description. According to one embodiment, a CU (505) (e.g., CU-UP (505b)) may receive uplink data (e.g., PDCP PDU) from a first DU (510) based on a first IP address. According to one embodiment, a CU (505) (e.g., CU-UP (505b)) may receive uplink data (e.g., PDCP PDU) from a second DU (520) based on a second IP address. According to one embodiment, a first DU (510) may receive downlink data (e.g., PDCP PDU) from a CU (505) (e.g., CU-UP (505b)) based on a third IP address. In one embodiment, the second DU (520) may receive downlink data (e.g., PDCP PDU) from the CU (505) (e.g., CU-UP (505b)) based on the fourth IP address.

[0239] Referring to FIG. 15, the CU (505) may be responsible for the functions of the PDCP (614). The CU (505) may include a CU-CP (505a) and a CU-CP (505b). The PDCP (614) may include a CP portion and an UP portion. The CU (505) may be connected to one or more DUs. For example, the CU (505) may be connected to a first DU (510) and a second DU (520). The first DU (510) may include an RLC entity (613) (e.g., an RLC-H processing module (613a), an RLC-L processing module (613b)). The second DU (520) may include an RLC entity (623) (e.g., an RLC-H processing module (623a), an RLC-L processing module (623b)). The CU (505) can transmit data through the first DU (510) or the second DU (520). The first DU (510) and the second DU (520) can be connected through an X1 interface (e.g., an X1-C interface (581), an X1-U interface (582)). For example, the first DU (510) can receive data from the second DU (520) on the X1-U interface (582) based on a source X1-U IP address of the first DU (510). For example, the second DU (520) can receive data from the first DU (510) on the X1-U interface (582) based on a target X1-U IP address of the second DU (520).

[0240] The first DU (510) can receive ARQ status information (1511) for downlink data transmitted to a terminal (e.g., terminal (120)). The first DU (510) can transmit information obtained based on the ARQ status information (1511) to the second DU (520). The first DU (510) can determine whether retransmission is required for the PDU transmitted by the first DU (510). The first DU (510) (e.g., RLC-H processing module (613a)) can perform PCell DL ARQ and segmentation. For example, the first DU (510) can determine that retransmission is required for an RLC SDU with SN=1. The first DU (510) can segment the RLC SDU with SN=1. A segment of an RLC SDU may have a segment offset (SO). The first DU (510) may transmit a segment of an RLC SDU with SN=1 and SO=1 to the terminal (120).

[0241] The second DU (520) can receive ARQ status information (1521) for downlink data transmitted to a terminal (e.g., terminal (120)). The second DU (520) can transmit information obtained based on the ARQ status information (1521) to the first DU (510). The second DU (520) can determine whether retransmission is required for the PDU transmitted by the second DU (520). The second DU (520) (e.g., RLC-H processing module (623a)) can perform SCell DL ARQ and segmentation. For example, the second DU (520) can determine that retransmission is required for an RLC SDU with SN=3. The second DU (520) can segment the RLC SDU with SN=3. The second DU (520) can transmit a segment of an RLC SDU with SN=3, SO=0 and a segment of an RLC SDU with SN=3, SO=1 to the terminal (120).

[0242] Figure 16 illustrates an example of traffic processing according to deactivation of SCell DU in multi-RLC. The same reference numbers may be used to refer to the same description. According to one embodiment, the CU (505) (e.g., CU-UP (505b)) may receive uplink data (e.g., PDCP PDU) from the first DU (510) based on a first IP address. According to one embodiment, the CU (505) (e.g., CU-UP (505b)) may receive uplink data (e.g., PDCP PDU) from the second DU (520) based on a second IP address. According to one embodiment, the first DU (510) may receive downlink data (e.g., PDCP PDU) from the CU (505) (e.g., CU-UP (505b)) based on a third IP address. In one embodiment, the second DU (520) may receive downlink data (e.g., PDCP PDU) from the CU (505) (e.g., CU-UP (505b)) based on the fourth IP address.

[0243] Referring to FIG. 16, the CU (505) may be responsible for the functions of the PDCP (614). The CU (505) may include a CU-CP (505a) and a CU-CP (505b). The PDCP (614) may include a CP portion and an UP portion. The CU (505) may be connected to one or more DUs. For example, the CU (505) may be connected to a first DU (510) and a second DU (520). The first DU (510) may include an RLC entity (613) (e.g., an RLC-H processing module (613a), an RLC-L processing module (613b)). The second DU (520) may include an RLC entity (623) (e.g., an RLC-H processing module (623a), an RLC-L processing module (623b)). The CU (505) can transmit data through the first DU (510) or the second DU (520). The first DU (510) and the second DU (520) can be connected through an X1 interface (e.g., an X1-C interface (581), an X1-U interface (582)). For example, the first DU (510) can receive data from the second DU (520) on the X1-U interface (582) based on a source X1-U IP address of the first DU (510). For example, the second DU (520) can receive data from the first DU (510) on the X1-U interface (582) based on a target X1-U IP address of the second DU (520).

[0244] A first DU (510) (e.g., MAC processing module (612)) may determine to deactivate an SCell. The first DU (510) may transmit a deactivation command (1610) to a second DU (520), which is an SCell DU, on the MAC layer. The second DU (520) (e.g., MAC processing module (622)) may, based on identifying that the SCell status has changed, notify the change to an RLC entity (623) (e.g., RLC-H processing module (623a)). A notification (1620) regarding the change may be provided to the RLC entity (623) (e.g., RLC-H processing module (623a)). Based on the notification, the second DU (520) may transmit a message (1630) to the CU (505). For example, message (1630) may be a DDDS message. For example, the 'Desired buffer size' field in message (1630) may be set to 0. Accordingly, transmission of new packets may be stopped. When the DU (520) receives the above notification, it may transmit data to the first DU (510). The data is unconfirmed data (i.e., data for which an ACK has not been received), and the RLC-L processing module (613b) of the first DU (510) may perform retransmission (1640) of the data.

[0245] Although not shown in FIG. 16, the first DU (510) may also provide a command for activation in addition to deactivation. The first DU (510) may instruct the second DU (520) to activate the SCell through inter-MAC signaling. The second DU (520) (e.g., the MAC processing module (622)) may receive the instruction for the activation and notify the RLC entity (623) (e.g., the RLC-H processing module (623a)) of the instruction. When the second DU (520) receives the instruction for the activation, it may transmit a message (1630) to the CU (505). For example, the message (1630) may be a DDDS message. In the message (1630), the 'Desired buffer size' field may be set to a 'valid value'. Transmission of a new packet may be performed with a size determined based on the 'valid value'. The CU (505) can transmit the new packet through the F1-U connection between the second DU (520) and the CU (505). The CU (505) can perform a traffic resumption operation through the F1-U connection between the second DU (520) and the CU (505).

[0246] Although not shown in FIG. 16, the path for data transmission may be changed through the CU (505) instead of the DU-to-DU interface. For example, the second DU (520) may transmit a DDDS message to the CU (505). The DDDS message may be provided on the user plane (e.g., F1-U interface). The CU (505) may determine the status of the SCell based on the cause value of the DDDS message. For example, if the cause value indicates 'RLO', the CU (505) may re-provide data that was transmitted to the second DU (520) but whose reception has not yet been confirmed to the first DU (510). In other words, the CU (505) may resume transmission of the data. For example, if the cause value indicates 'RLO', the CU (505) may perform a procedure for releasing and / or deactivating the SCell provided by the second DU (520). The CU (505) may perform a UE context modification procedure with the first DU (510) to release and / or deactivate the SCell. For example, if the cause value indicates 'RADIO LINK RESUME', the CU (505) may perform a procedure for adding and / or activating the SCell provided by the second DU (520). The CU (505) may perform a UE context modification procedure with the first DU (510) to add and / or activate the SCell.

[0247] Figure 17 illustrates examples of multiple MAC (medium access control) paths. The same reference numerals may be used to refer to the same description. In one embodiment, the CU (505) (e.g., CU-UP (505b)) may receive uplink data (e.g., PDCP PDU) from the first DU (510) based on a first IP address. In one embodiment, the CU (505) (e.g., CU-UP (505b)) may receive uplink data (e.g., PDCP PDU) from the second DU (520) based on a second IP address. In one embodiment, the first DU (510) may receive downlink data (e.g., PDCP PDU) from the CU (505) (e.g., CU-UP (505b)) based on a third IP address. In one embodiment, the second DU (520) may receive downlink data (e.g., PDCP PDU) from the CU (505) (e.g., CU-UP (505b)) based on the fourth IP address.

[0248] Referring to FIG. 17, the CU (505) may be responsible for the functions of the PDCP (614). The CU (505) may include a CU-CP (505a) and a CU-CP (505b). The PDCP (614) may include a CP portion and an UP portion. The CU (505) may be connected to one or more DUs. For example, the CU (505) may be connected to a first DU (510) and a second DU (520). The first DU (510) may include an RLC entity (613) (e.g., an RLC-H processing module (613a), an RLC-L processing module (613b)). The second DU (520) may include an RLC entity (623) (e.g., an RLC-H processing module (623a), an RLC-L processing module (623b)). The CU (505) can transmit data through the first DU (510) or the second DU (520). The first DU (510) and the second DU (520) can be connected through an X1 interface (e.g., an X1-C interface (581), an X1-U interface (582)). For example, the first DU (510) can receive data from the second DU (520) on the X1-U interface (582) based on a source X1-U IP address of the first DU (510). For example, the second DU (520) can receive data from the first DU (510) on the X1-U interface (582) based on a target X1-U IP address of the second DU (520).

[0249] The RLC-L processing module (613b) of the first DU (510) can receive data (e.g., PDU) from the RLC-H processing module (623a) of the second DU (520). As a non-limiting example, the RLC-L processing module (613b) of the first DU (510) can process the data together with the data from the RLC-H processing module (613a) of the first DU (510). For the processing, the RLC-L processing module (613b) of the first DU (510) can perform segmentation. When the segmentation is performed, the RLC-L processing module (613b) of the first DU (510) can insert SO (segment offset) information into the RLC header. For example, the RLC-L processing module (613b) of the first DU (510) can perform segmentation (1710). The RLC-L processing module (613b) of the first DU (510) can perform segmentation (1710) for an RLC SDU with SN=1. The RLC-L processing module (613b) of the first DU (510) can transmit a segment of an RLC SDU with SN=1, SO=0 and a segment of an RLC SDU with SN=1, SO=1 to the terminal (120). Similarly, the RLC-L processing module (623b) of the second DU (520) can perform segmentation (1720) for an RLC SDU with SN=3. The RLC-L processing module (623b) of the second DU (520) can transmit a segment of an RLC SDU with SN=3 and SO=0 and a segment of an RLC SDU with SN=3 and SO=1 to the terminal (120).

[0250] Figure 18 illustrates an example of RLC reassembly and ARQ reporting. The same reference numbers may be used to refer to the same description. In one embodiment, the CU (505) (e.g., CU-UP (505b)) may receive uplink data (e.g., PDCP PDU) from the first DU (510) based on a first IP address. In one embodiment, the CU (505) (e.g., CU-UP (505b)) may receive uplink data (e.g., PDCP PDU) from the second DU (520) based on a second IP address. In one embodiment, the first DU (510) may receive downlink data (e.g., PDCP PDU) from the CU (505) (e.g., CU-UP (505b)) based on a third IP address. In one embodiment, the second DU (520) may receive downlink data (e.g., PDCP PDU) from the CU (505) (e.g., CU-UP (505b)) based on the fourth IP address.

[0251] Referring to FIG. 18, the CU (505) may be responsible for the functions of the PDCP (614). The CU (505) may include a CU-CP (505a) and a CU-CP (505b). The PDCP (614) may include a CP portion and an UP portion. The CU (505) may be connected to one or more DUs. For example, the CU (505) may be connected to a first DU (510) and a second DU (520). The first DU (510) may include an RLC entity (613) (e.g., an RLC-H processing module (613a), an RLC-L processing module (613b)). The second DU (520) may include an RLC entity (623) (e.g., an RLC-H processing module (623a), an RLC-L processing module (623b)). The CU (505) can transmit data through the first DU (510) or the second DU (520). The first DU (510) and the second DU (520) can be connected through an X1 interface (e.g., an X1-C interface (581), an X1-U interface (582)). For example, the first DU (510) can receive data from the second DU (520) on the X1-U interface (582) based on a source X1-U IP address of the first DU (510). For example, the second DU (520) can receive data from the first DU (510) on the X1-U interface (582) based on a target X1-U IP address of the second DU (520).

[0252] The RLC-L processing module (613b) of the first DU (510) can transmit segmented PDUs and / or non-segmented PDUs to the RLC-H processing module (613a) of the first DU (510) (1811). The RLC-L processing module (623b) of the second DU (520) can transmit both segmented PDUs and / or non-segmented PDUs to the RLC-H processing module (613a) of the first DU (510) (1812). The RLC-H processing module (613a) of the first DU (510) can reassemble the segmented PDUs and then transmit the result of the reassembly (1830) to the CU (505). For example, the RLC-H processing module (613a) of the first DU (510) may reassemble at least one segment received from the RLC-L processing module (613b) of the first DU (510) and at least one segment received from the RLC-L processing module (623b) of the second DU (520), and transmit a UL PDU corresponding to the reassembly to the CU (505).

[0253] Fig. 19 illustrates the configuration of an electronic device. The structure illustrated in Fig. 19 can be understood as a configuration of a device having at least one function among the PCell-DU (e.g., the first DU (510)), the SCell-DU (e.g., the second DU (520)), or the CU (e.g., the CU (505)) described above. Terms such as "... unit" and "... device" used hereinafter mean a unit that processes at least one function or operation, and this can be implemented by hardware, software, or a combination of hardware and software.

[0254] Referring to FIG. 19, the electronic device may include a transceiver (1910), a memory (1920), and a processor (1930).

[0255] The transceiver (1910) provides an interface for communicating with other devices within a network. That is, the transceiver (1910) converts a bit string transmitted from an electronic device to another electronic device into a physical signal, and converts a physical signal received from another electronic device into a bit string. That is, the transceiver (1910) can transmit or receive signals. Accordingly, the transceiver (1910) may be referred to as a modem, a communication unit, a transmit unit, a receive unit, or a transmit / receive unit. In this case, the transceiver (1910) enables the electronic device to communicate with other electronic devices or systems via a backhaul connection (e.g., wired backhaul or wireless backhaul) or via a network. The transceiver (1910) may include one or more transceivers.

[0256] The memory (1920) stores data such as basic programs, application programs, and setting information for the operation of the electronic device. The memory (1920) may be composed of volatile memory, non-volatile memory, or a combination of volatile and non-volatile memory. Furthermore, the memory (1920) provides stored data upon request from the processor (1930). The memory (1920) may be referred to as a storage unit.

[0257] The processor (1930) controls the overall operations of the electronic device. For example, the processor (1930) transmits and receives signals via the transceiver (1910). Additionally, the processor (1930) writes and reads data to and from the memory (1920). The processor (1930) may be referred to as a control unit. To this end, the processor (1930) may be composed of multiple processors or include at least one sub-processor. According to various embodiments, the processor (1930) may control the electronic device to perform operations according to various embodiments described in the present disclosure.

[0258] In the present disclosure, by offloading CA traffic of PCell RLC to SCell RLC, CA performance constraints due to packet processing constraints of PCell RLC can be mitigated. Since CA bearers between DUs are omitted through a structure branching from the CU, bandwidth between DUs can be reduced. According to embodiments of the present disclosure, bearer split and bearer switching setup procedures for inter-DU CA can be performed on the RRC interface side. A multi-RLC setup procedure can be performed on the RRC interface side. A multi-RLC setup procedure can be performed on the RRC interface side. A SCell DU release procedure can be performed. According to embodiments of the present disclosure, multi-path flow control, path switching and retransmission according to RLO, bearer split or data recovery according to SCell addition and release, and / or SN synchronization can be performed on the PDCP side. According to embodiments of the present disclosure, RLC SN coordination between multiple RLCs can be performed on the RLC-H side. Additionally, on the RLC-H side, DL ARQ interworking between multiple RLCs can be supported. Furthermore, on the RLC-H side, data recovery can be supported when SCells are activated and / or deactivated. Furthermore, on the RLC-H side, RLC UL reassembly and UL ARQ reporting can be performed. According to embodiments of the present disclosure, on the RLC-L side, interworking between RLC-Hs of multiple RLC entities can be supported.

[0259] In embodiments of the present disclosure, a method performed by a central unit (CU) is provided. The method may include transmitting a first user data message to a first distributed unit (DU) for providing a primary cell (PCell) for carrier aggregation (CA), and transmitting a second user data message to a second DU for providing a secondary cell (SCell) for the CA. The first user data message may include information about a sequence number (SN) of a starting packet data convergence protocol (PDCP) protocol data unit (PDU) and information about a number of repetitions of the SN of the PDCP PDU in the first DU. The second user data message may include information about the SN of the starting PDCP PDU and information about the number of repetitions of the SN of the PDCP PDU. Hereinafter, in the present disclosure, SN represents a sequence number of a PDU including an SDU. For example, the SN of an SDU may represent the SN of the header of a PDU containing the SDU. The SN of a PDU may represent the SN in the header of the PDU.

[0260] For example, the method may include transmitting a UE context setup request message to the first DU and receiving a UE context setup response message from the first DU. The UE context setup request message may include first IP (internet protocol) address information for uplink transmission between the first DU and the CU and second IP address information for uplink transmission between the second DU and the CU. The UE context setup response message may include third IP address information for downlink transmission between the first DU and the CU and fourth IP address information for downlink transmission between the second DU and the CU.

[0261] For example, the UE context setup request message may include PDCP SN length information. The PDCP SN length information may represent 12 bits or 18 bits.

[0262] For example, the first DU may include a first RLC entity for the CU and F1-U connection. The second DU may include a second RLC entity for the CU and F1-U connection. Data corresponding to the data radio bearer for the CA may be provided to the second RLC entity.

[0263] For example, the method may include an operation of receiving a downlink data delivery status (DDDS) message from the second DU, an operation of performing a procedure for releasing an F1-U connection between the CU and the second DU when a cause value of the DDDS message corresponds to a value related to radio link outage (RLO), and an operation of transmitting unconfirmed data transmitted through the second DU through the first DU.

[0264] In embodiments of the present disclosure, a method performed by a distributed unit (DU) is provided. The method may include receiving a user data message from a central unit (CU). The user data message may include information about a sequence number (SN) of a starting packet data convergence protocol (PDCP) protocol data unit (PDU) and information about a number of repetitions of the SN of the PDCP PDU. The user data message may be associated with the CU and shared with other DUs for inter-DU carrier aggregation (CA).

[0265] For example, the method may include receiving a UE context setup request message from the CU and transmitting a UE context setup response message to the CU. The UE context setup request message may include first IP (internet protocol) address information for uplink transmission between the DU and the CU and second IP address information for uplink transmission between the other DU and the CU. The UE context setup response message may include third IP address information for downlink transmission between the DU and the CU and fourth IP address information for downlink transmission between the other DU and the CU.

[0266] For example, the UE context setup request message may include PDCP SN length information. The PDCP SN length information may represent 12 bits or 18 bits.

[0267] For example, the DU may include a first RLC entity for the CU and F1-U connection. The other DU may include a second RLC entity for the CU and F1-U connection.

[0268] For example, the method may include an operation of transmitting a SCell (Secondary cell) setup request message to the other DU, and an operation of receiving a SCell (Secondary cell) setup response message from the other DU. The SCell setup request message may include information for configuring an RLC entity in the other DU and RLC configuration information in the DU. The SCell setup response message may include IP (internet protocol) address information related to the RLC entity in the other DU.

[0269] In embodiments of the present disclosure, a device of a central unit (CU) is provided. The device may include at least one processor; and a memory storing instructions. The instructions, when executed by the at least one processor, may individually or collectively cause the device to transmit a first user data message to a first distributed unit (DU) for providing a primary cell (PCell) for carrier aggregation (CA), and to transmit a second user data message to a second DU for providing a secondary cell (SCell) for the CA. The first user data message may include information about a sequence number (SN) of a starting packet data convergence protocol (PDCP) protocol data unit (PDU) and information about a repetition count of the SN of the PDCP PDU in the first DU. The second user data message may include information about the SN of the starting PDCP PDU and information about the repetition count of the SN of the PDCP PDU.

[0270] For example, the instructions, when executed by the at least one processor, may individually or collectively cause the device to transmit a UE context setup request message to the first DU and to receive a UE context setup response message from the first DU. The UE context setup request message may include first Internet protocol (IP) address information for uplink transmission between the first DU and the CU and second IP address information for uplink transmission between the second DU and the CU. The UE context setup response message may include third IP address information for downlink transmission between the first DU and the CU and fourth IP address information for downlink transmission between the second DU and the CU.

[0271] For example, the UE context setup request message may include PDCP SN length information. The PDCP SN length information may represent 12 bits or 18 bits.

[0272] For example, the first DU may include a first RLC entity for the CU and F1-U connection. The second DU may include a second RLC entity for the CU and F1-U connection. Data corresponding to the data radio bearer for the CA may be provided to the second RLC entity.

[0273] For example, the instructions, when executed by the at least one processor, may individually or collectively cause the device to perform a procedure for releasing an F1-U connection between the CU and the second DU, if the device receives a downlink data delivery status (DDDS) message from the second DU and a cause value of the DDDS message corresponds to a value related to radio link outage (RLO), and cause unconfirmed data transmitted through the second DU to be transmitted through the first DU.

[0274] In embodiments of the present disclosure, a device of a distributed unit (DU) is provided. The device may include at least one processor; and a memory storing instructions. The instructions, when executed by the at least one processor, may individually or collectively cause the device to receive a user data message from a central unit (CU). The user data message may include information about a sequence number (SN) of a starting packet data convergence protocol (PDCP) protocol data unit (PDU) and information about a cycle count of the SN of the PDCP PDU. The user data message may be associated with the CU and shared with other DUs for inter-DU carrier aggregation (CA) (inter-DU CA).

[0275] For example, the instructions, when executed by the at least one processor, may individually or collectively cause the device to receive a UE context setup request message from the CU and to transmit a UE context setup response message to the CU. The UE context setup request message may include first Internet protocol (IP) address information for uplink transmission between the DU and the CU and second IP address information for uplink transmission between the other DU and the CU. The UE context setup response message may include third IP address information for downlink transmission between the DU and the CU and fourth IP address information for downlink transmission between the other DU and the CU.

[0276] For example, the UE context setup request message may include PDCP SN length information. The PDCP SN length information may represent 12 bits or 18 bits.

[0277] For example, the DU may include a first RLC entity for the CU and F1-U connection. The other DU may include a second RLC entity for the CU and F1-U connection.

[0278] For example, the instructions, when executed by the at least one processor, may individually or collectively cause the device to transmit a SCell (Secondary cell) setup request message to the other DU and to receive a SCell (Secondary cell) setup response message from the other DU. The SCell setup request message may include information for configuring an RLC entity in the other DU and RLC configuration information in the DU. The SCell setup response message may include IP (internet protocol) address information associated with the RLC entity in the other DU.

[0279] In embodiments of the present disclosure, a method is provided, which is performed by a central unit (CU) connected to a first distributed unit (DU) and a second DU. The method may include an operation of transmitting a user equipment (UE) context setup request message to the first distributed unit (DU). The UE context setup request message may include information about a first internet protocol (IP) address used for uplink transmission in a user plane between the first DU and the CU for providing a primary cell (PCell); and information about a second IP address used for uplink transmission in a user plane between the second DU and the CU for providing a secondary cell (SCell). The method may include an operation of receiving a UE context setup response message from the first DU. The UE context setup response message may include information about a third IP address used for downlink transmission in a user plane between the first DU and the CU and information about a fourth IP address used for downlink transmission in a user plane between the second DU and the CU. The method may include transmitting, to the first DU based on the third IP address, a first user data message including a first packet data convergence protocol (PDCP) protocol data unit (PDU) and first sequence number (SN) synchronization information for the first PDCP PDU. The method may include transmitting, to the second DU based on the fourth IP address, a second user data message including a second PDCP PDU and second SN synchronization information for the second PDCP PDU.

[0280] For example, the first SN synchronization information may include the SN of a start PDCP PDU transmitted after the CA (carrier aggregation) setup procedure for the PCell and the SCell is completed and the number of modulo cycles from the SN of the start PDCP PDU to the SN of the first PDCP PDU. For example, the second SN synchronization information may include the SN of the start PDCP PDU and the number of modulo cycles from the SN of the start PDCP PDU to the SN of the second PDCP PDU.

[0281] For example, the UE context modification request message may include information about a PDCP SN length of 12 bits or 18 bits. The first DU may include a first radio link control (RLC) entity configured to perform RLC SN numbering based on at least one of the PDCP SN length, the SN of the starting PDCP PDU, or the number of modulo cycles up to the SN of the first PDCP PDU. The second DU may include a second RLC entity configured to perform RLC SN numbering based on at least one of the PDCP SN length, the SN of the starting PDCP PDU, or the number of modulo cycles up to the SN of the second PDCP PDU.

[0282] For example, the UE context setup request message may be used to cause the first DU to send an SCell setup request message to the second DU. The SCell setup request message may include an indicator for configuring a second RLC entity for the CA, configuration information related to the first RLC entity for the CA, and the second IP address.

[0283] For example, the method may include receiving a downlink data delivery status (DDDS) message from the second DU based on the second IP address. The method may include performing a procedure for an F1-U connection between the CU and the second DU when a cause value of the DDDS message indicates a radio link outage (RLO). The method may include transmitting PDCP data transmitted through the second DU but not confirmed for reception to the first DU.

[0284] In embodiments of the present disclosure, a method performed by a first distributed unit (DU) is provided. The method may include receiving a user equipment (UE) context setup request message from a central unit (CU) connected to the first DU. The UE context setup request message may include information about a first Internet protocol (IP) address used for uplink transmission in a user plane between the first DU and the CU for providing a primary cell (PCell); and information about a second IP address used for uplink transmission in a user plane between a second DU and the CU for providing a secondary cell (SCell). The method may include transmitting an SCell setup request message including information about the second IP address to the second DU. The method may include receiving an SCell setup response message from the second DU in response to the SCell setup request message. The SCell setup response message may include information related to a fourth IP address used for downlink transmission in the user plane between the CU and the second DU. The method may include an operation of transmitting a UE context setup response message to the CU. The UE context setup response message may include information about a third IP address used for downlink transmission in the user plane between the CU and the first DU and information about the fourth IP address used for downlink transmission in the user plane between the CU and the second DU.The method may include receiving, from the CU, a first user data message including a first PDCP (packet data convergence protocol) protocol data unit (PDU) and first SN (sequence number) synchronization information for the first PDCP PDU, based on the third IP address.

[0285] For example, the first SN synchronization information may include the SN of a start PDCP PDU transmitted after the setup procedure of CA (carrier aggregation) for the PCell and the SCell is completed and the number of modulo cycles from the SN of the start PDCP PDU to the SN of the first PDCP PDU. The SN of the start PDCP PDU may be used for synchronization between the first DU and the second DU.

[0286] For example, the UE context modification request message may include information about a PDCP SN length of 12 bits or 18 bits. The first DU may include a first radio link control (RLC) entity configured to perform RLC SN numbering based on at least one of the PDCP SN length, the SN of the starting PDCP PDU, or the number of modulo cycles up to the SN of the first PDCP PDU. The second DU may include a second RLC entity configured to perform RLC SN numbering based on at least one of the PDCP SN length, the SN of the starting PDCP PDU, or the number of modulo cycles up to the SN of the second PDCP PDU.

[0287] For example, the SCell setup request message may include an instruction to configure a second RLC entity for the CA and configuration information related to a first RLC entity for the CA.

[0288] In embodiments of the present disclosure, a method performed by a second DU (distributed unit) is provided. The method may include receiving, from a first DU for providing a PCell (primary cell), a SCell (secondary cell) setup request message for configuring the second DU for providing a SCell (secondary cell). The SCell setup request message may include configuration information for inter-DU carrier aggregation (CA) using the first DU, the second DU, and a central unit (CU) connected to the first DU and the second DU. The method may include transmitting, to the first DU, an SCell setup response message in response to the SCell setup request message. The SCell setup response message may include information about an IP address used for downlink transmission in a user plane between the CU and the second DU. The method may include receiving, based on the IP address, a user data message including a PDCP (packet data convergence protocol) PDU (protocol data unit) and SN (sequence number) synchronization information for the PDCP PDU from the CU.

[0289] In embodiments of the present disclosure, a central unit (CU) connectable to a first DU (distributed unit) and a second DU is provided. The CU may include at least one processor; and a memory storing instructions. The instructions, when executed by the at least one processor, cause the CU to transmit a user equipment (UE) context setup request message to the first DU (distributed unit), the UE context setup request message including information about a first IP (internet protocol) address used for uplink transmission in a user plane between the first DU and the CU for providing a PCell (primary cell); And information about a second IP address used for uplink transmission in a user plane between the second DU and the CU for providing a SCell (secondary cell), and receiving a UE context setup response message from the first DU, the UE context setup response message including information about a third IP address used for downlink transmission in a user plane between the first DU and the CU and information about a fourth IP address used for downlink transmission in a user plane between the second DU and the CU, and transmitting to the first DU a first user data message including a first PDCP (packet data convergence protocol) protocol data unit (PDU) and first SN (sequence number) synchronization information for the first PDCP PDU based on the third IP address, and transmitting to the second DU a second user data message including a second PDCP PDU and second SN synchronization information for the second PDCP PDU based on the fourth IP address.

[0290] For example, the first SN synchronization information may include the SN of a start PDCP PDU transmitted after the CA (carrier aggregation) setup procedure for the PCell and the SCell is completed and the number of modulo cycles from the SN of the start PDCP PDU to the SN of the first PDCP PDU. For example, the second SN synchronization information may include the SN of the start PDCP PDU and the number of modulo cycles from the SN of the start PDCP PDU to the SN of the second PDCP PDU.

[0291] For example, the UE context modification request message may include information about a PDCP SN length of 12 bits or 18 bits. The first DU may include a first radio link control (RLC) entity configured to perform RLC SN numbering based on at least one of the PDCP SN length, the SN of the starting PDCP PDU, or the number of modulo cycles up to the SN of the first PDCP PDU. The second DU may include a second RLC entity configured to perform RLC SN numbering based on at least one of the PDCP SN length, the SN of the starting PDCP PDU, or the number of modulo cycles up to the SN of the second PDCP PDU.

[0292] For example, the UE context setup request message may be used to cause the first DU to send an SCell setup request message to the second DU. The SCell setup request message may include an indicator for configuring a second RLC entity for the CA, configuration information related to the first RLC entity for the CA, and the second IP address.

[0293] For example, the instructions, when executed by the at least one processor, may cause the CU to receive a downlink data delivery status (DDDS) message from the second DU based on the second IP address, and, if a cause value of the DDDS message indicates a radio link outage (RLO), perform a procedure for an F1-U connection between the CU and the second DU, and transmit PDCP data transmitted through the second DU but not confirmed for reception to the first DU.

[0294] In embodiments of the present disclosure, a distributed unit (DU) is provided.The DU comprises at least one processor; and a memory storing instructions, wherein the instructions, when executed by the at least one processor, cause the DU to receive a user equipment (UE) context setup request message from a central unit (CU) connected to the DU, the UE context setup request message including information about a first IP (internet protocol) address used for uplink transmission in a user plane between the DU and the CU for providing a PCell (primary cell); And information about a second IP address used for uplink transmission in a user plane between another DU and the CU for providing a SCell (secondary cell), transmits an SCell setup request message including information about the second IP address to the other DU, receives an SCell setup response message in response to the SCell setup request message from the other DU, the SCell setup response message including information related to a fourth IP address used for downlink transmission in a user plane between the CU and the other DU, transmits a UE context setup response message to the CU, the UE context setup response message including information about a third IP address used for downlink transmission in a user plane between the CU and the DU and information about the fourth IP address used for downlink transmission in a user plane between the CU and the other DU, and includes a first PDCP (packet data convergence protocol) protocol data unit (PDU) and a first SN (sequence number) for the first PDCP PDU. The DU may be caused to receive a first user data message including synchronization information from the CU based on the third IP address.

[0295] For example, the first SN synchronization information may include the SN of a start PDCP PDU transmitted after the CA (carrier aggregation) setup procedure for the PCell and the SCell is completed and the number of modulo cycles from the SN of the start PDCP PDU to the SN of the first PDCP PDU. The SN of the start PDCP PDU may be used for synchronization between the DU and the other DU.

[0296] For example, the UE context modification request message may include information about a PDCP SN length of 12 bits or 18 bits. The DU may include a first radio link control (RLC) entity configured to perform RLC SN numbering based on at least one of the PDCP SN length, the SN of the starting PDCP PDU, or the number of modulo cycles up to the SN of the first PDCP PDU. The other DU may include a second RLC entity configured to perform RLC SN numbering based on at least one of the PDCP SN length, the SN of the starting PDCP PDU, or the number of modulo cycles up to the SN of the second PDCP PDU.

[0297] For example, the SCell setup request message may include an instruction to configure a second RLC entity for the CA and configuration information related to a first RLC entity for the CA.

[0298] In embodiments of the present disclosure, a distributed unit (DU) is provided. The DU includes at least one processor; And a memory storing instructions, wherein the instructions, when executed by the at least one processor, cause the DU to receive an SCell (secondary cell) setup request message for configuring the DU to provide an SCell (secondary cell) from another DU for providing a PCell (primary cell), the SCell setup request message including configuration information for inter-DU carrier aggregation (CA) using the DU, the other DU, and a CU (central unit), and transmit an SCell setup response message to the other DU in response to the SCell setup request message, the SCell setup response message including information on an IP address used for downlink transmission in a user plane between the CU and the DU, and based on the IP address, transmit a user data message including a PDCP (packet data convergence protocol) PDU (protocol data unit) and SN (sequence number) synchronization information for the PDCP PDU from the CU. It can cause you to receive.

[0299] For one or more embodiments, at least one of the components described in one or more of the preceding drawings may be configured to perform one or more operations, techniques, processes, and / or methods as described herein. For example, a processor (e.g., a baseband processor) described herein with respect to one or more of the preceding drawings may be configured to operate according to one or more examples described herein. For another example, circuitry associated with a user equipment (UE), a base station, a network element, and the like, as described above with respect to one or more of the preceding drawings, may be configured to operate according to one or more examples described herein.

[0300] Any of the embodiments described above may be combined with any other embodiment (or combination of embodiments) unless explicitly stated otherwise. The foregoing description of one or more implementations provides examples and descriptions, but is not intended to be exhaustive or limit the scope of the embodiments to the precise forms disclosed. Modifications and variations are possible in light of the above teachings or may be learned from practicing various embodiments.

[0301] Various embodiments of this document may be implemented as software including one or more instructions stored on a storage medium readable by a machine (e.g., DU, PCell-DU, SCell-DU). For example, the machine may call at least one of the one or more instructions stored from the storage medium and execute it. This enables the machine to operate to perform at least one function according to the at least one called instruction. The one or more instructions may include code generated by a compiler or code executable by an interpreter. The machine-readable storage medium may be provided in the form of a non-transitory storage medium. Here, 'non-transitory' only means that the storage medium is a tangible device and does not contain a signal (e.g., electromagnetic waves), and this term does not distinguish between cases where data is stored semi-permanently and cases where it is stored temporarily. O-RAN enables the construction of a virtualized intelligent network with standardized open interfaces. For network virtualization, operations according to embodiments may be implemented in the form of a recording medium (e.g., memory).

[0302] According to one embodiment, the method according to various embodiments disclosed in the present document may be provided as included in a computer program product. The computer program product may be traded as a product between a seller and a buyer. The computer program product may be distributed in the form of a machine-readable storage medium (e.g., compact disc read-only memory (CD-ROM)), or may be distributed online (e.g., downloaded or uploaded) via an application store (e.g., Play Store™) or directly between two user devices (e.g., smart phones). In the case of online distribution, at least a portion of the computer program product may be temporarily stored or temporarily generated in a machine-readable storage medium, such as the memory of a manufacturer's server, an application store's server, or an intermediary server.

[0303] According to various embodiments, each component (e.g., a module or a program) of the above-described components may include one or more entities, and some of the entities may be separated and placed in other components. According to various embodiments, one or more components or operations of the aforementioned components may be omitted, or one or more other components or operations may be added. Alternatively or additionally, a plurality of components (e.g., a module or a program) may be integrated into a single component. In such a case, the integrated component may perform one or more functions of each of the plurality of components identically or similarly to those performed by the corresponding component among the plurality of components prior to the integration. According to various embodiments, the operations performed by a module, program, or other component may be executed sequentially, in parallel, iteratively, or heuristically, or one or more of the operations may be executed in a different order, omitted, or one or more other operations may be added.

[0304] The methods according to the embodiments described in the claims or specification of the present disclosure may be implemented in the form of hardware, software, or a combination of hardware and software.

[0305] When implemented in software, a computer-readable storage medium storing one or more programs (software modules) may be provided. The one or more programs stored in the computer-readable storage medium are configured for execution by one or more processors in an electronic device. The one or more programs include instructions that cause the electronic device to execute methods according to embodiments described in the claims or specifications of the present disclosure. The one or more programs may be provided as included in a computer program product. The computer program product may be traded between sellers and buyers as a product. The computer program product may be distributed in the form of a device-readable storage medium (e.g., compact disc read only memory (CD-ROM)) or an application store (e.g., Play Store). 쪠 ) or directly between two user devices (e.g., smart phones), online distribution (e.g., downloading or uploading). In the case of online distribution, at least a portion of the computer program product may be at least temporarily stored or temporarily created in a machine-readable storage medium, such as the memory of a manufacturer's server, an application store's server, or an intermediary server.

[0306] These programs (software modules, software) may be stored in random access memory, non-volatile memory including flash memory, read only memory (ROM), electrically erasable programmable read only memory (EEPROM), magnetic disc storage devices, compact disc-ROM (CD-ROM), digital versatile discs (DVDs) or other forms of optical storage devices, magnetic cassettes, or may be stored in memories formed by a combination of some or all of these. In addition, each configuration memory may include multiple copies.

[0307] Additionally, the program may be stored on an attachable storage device that is accessible via a communication network, such as the Internet, an intranet, a local area network (LAN), a wide area network (WAN), a storage area network (SAN), or a combination thereof. Such a storage device may be connected to a device implementing an embodiment of the present disclosure via an external port. Additionally, a separate storage device on the communication network may be connected to a device implementing an embodiment of the present disclosure.

[0308] In the specific embodiments of the present disclosure described above, components included in the disclosure are expressed singularly or plurally, depending on the specific embodiment presented. However, the singular or plural expressions are selected to suit the presented situation for convenience of explanation, and the present disclosure is not limited to singular or plural components. Components expressed in plural may be composed of singular elements, or components expressed in singular may be composed of plural elements.

[0309] According to embodiments, one or more of the components or operations of the aforementioned components may be omitted, or one or more other components or operations may be added. Alternatively or additionally, a plurality of components (e.g., modules or programs) may be integrated into a single component. In such a case, the integrated component may perform one or more functions of each of the plurality of components identically or similarly to those performed by the corresponding component among the plurality of components prior to the integration. According to embodiments, the operations performed by a module, program, or other component may be executed sequentially, in parallel, iteratively, or heuristically, or one or more of the operations may be executed in a different order, omitted, or one or more other operations may be added.

[0310] Meanwhile, although the detailed description of the present disclosure has described specific embodiments, it is obvious that various modifications are possible within the scope of the present disclosure.

Claims

1. In a method performed by a CU (central unit) connected to a first DU (distributed unit) and a second DU, An operation of transmitting a UE (user equipment) context setup request message to the first DU (distributed unit), wherein the UE context setup request message: Information about a first IP (internet protocol) address used for uplink transmission in the user plane between the first DU and the CU to provide a PCell (primary cell); and Includes information about a second IP address used for uplink transmission in the user plane between the second DU and the CU to provide SCell (secondary cell), An operation of receiving a UE context setup response message from the first DU, wherein the UE context setup response message includes information about a third IP address used for downlink transmission in a user plane between the first DU and the CU and information about a fourth IP address used for downlink transmission in a user plane between the second DU and the CU, An operation of transmitting a first user data message including a first PDCP (packet data convergence protocol) PDU (protocol data unit) and first SN (sequence number) synchronization information for the first PDCP PDU to the first DU based on the third IP address; An operation of transmitting a second user data message including a second PDCP PDU and second SN synchronization information for the second PDCP PDU to the second DU based on the fourth IP address, method.

2. In claim 1, The above first SN synchronization information includes the SN of the start PDCP PDU transmitted after the setup procedure of CA (carrier aggregation) for the PCell and the SCell is completed and the number of modulo cycles from the SN of the start PDCP PDU to the SN of the first PDCP PDU, The second SN synchronization information includes the SN of the start PDCP PDU and the number of modulo cycles from the SN of the start PDCP PDU to the SN of the second PDCP PDU. method.

3. In claim 2, The above UE context modification request message includes information about the PDCP SN length, which is 12-bit or 18-bit, The first DU includes a first radio link control (RLC) entity configured to perform RLC SN numbering based on at least one of the PDCP SN length, the SN of the starting PDCP PDU, or the number of modulo cycles up to the SN of the first PDCP PDU, The second DU includes a second RLC entity configured to perform RLC SN numbering based on at least one of the PDCP SN length, the SN of the starting PDCP PDU, or the number of modulo cycles up to the SN of the second PDCP PDU. method.

4. In claim 3, The above UE context setup request message is used to cause the first DU to transmit an SCell setup request message to the second DU, The SCell setup request message includes an instruction for configuring a second RLC entity for the CA, configuration information related to a first RLC entity for the CA, and the second IP address. method.

5. In claim 1, An operation of receiving a DDDS (downlink data delivery status) message from the second DU based on the second IP address; If the cause value of the above DDDS message indicates RLO (radio link outage), an operation for performing a procedure for F1-U connection between the CU and the second DU; Further comprising an operation of transmitting PDCP data transmitted through the second DU but not confirmed for reception to the first DU. method.

6. In a method performed by the first DU (distributed unit), An operation of receiving a UE (user equipment) context setup request message from a CU (central unit) connected to the first DU, wherein the UE context setup request message: Information about a first IP (internet protocol) address used for uplink transmission in the user plane between the first DU and the CU to provide a PCell (primary cell); and Includes information about a second IP address used for uplink transmission in the user plane between the second DU and the CU for providing SCell (secondary cell), An operation of transmitting an SCell setup request message including information about the second IP address to the second DU; An operation of receiving an SCell setup response message in response to the SCell setup request message from the second DU, wherein the SCell setup response message includes information related to a fourth IP address used for downlink transmission in a user plane between the CU and the second DU, An operation of transmitting a UE context setup response message to the CU, wherein the UE context setup response message includes information about a third IP address used for downlink transmission of a user plane between the CU and the first DU and information about a fourth IP address used for downlink transmission of a user plane between the CU and the second DU, An operation including receiving a first user data message including a first PDCP (packet data convergence protocol) PDU (protocol data unit) and first SN (sequence number) synchronization information for the first PDCP PDU from the CU based on the third IP address. method.

7. In claim 6, The above first SN synchronization information includes the SN of the start PDCP PDU transmitted after the setup procedure of CA (carrier aggregation) for the PCell and the SCell is completed and the number of modulo cycles from the SN of the start PDCP PDU to the SN of the first PDCP PDU, The SN of the above start PDCP PDU is used for synchronization between the first DU and the second DU. method.

8. In claim 7, The above UE context modification request message includes information about the PDCP SN length, which is 12-bit or 18-bit, The first DU includes a first radio link control (RLC) entity configured to perform RLC SN numbering based on at least one of the PDCP SN length, the SN of the starting PDCP PDU, or the number of modulo cycles up to the SN of the first PDCP PDU, The second DU includes a second RLC entity configured to perform RLC SN numbering based on at least one of the PDCP SN length, the SN of the starting PDCP PDU, or the number of modulo cycles up to the SN of the second PDCP PDU. method.

9. In claim 8, The SCell setup request message includes an instruction for configuring a second RLC entity for the CA and configuration information related to a first RLC entity for the CA. method.

10. In a method performed by the second DU (distributed unit), An operation of receiving an SCell (secondary cell) setup request message for configuring a second DU to provide a SCell (secondary cell) from a first DU to provide a PCell (primary cell), wherein the SCell setup request message includes configuration information for inter-DU CA (carrier aggregation) using the first DU, the second DU, and a CU (central unit) connected to the first DU and the second DU, An operation of transmitting an SCell setup response message to the first DU in response to the SCell setup request message, wherein the SCell setup response message includes information about an IP address used for downlink transmission in a user plane between the CU and the second DU, Based on the IP address, the operation of receiving a user data message including a PDCP (packet data convergence protocol) PDU (protocol data unit) and SN (sequence number) synchronization information for the PDCP PDU from the CU, method.

11. In the CU (central unit) that can be connected to the first DU (distributed unit) and the second DU, at least one processor; and A memory for storing instructions, wherein the instructions, when executed by the at least one processor, cause the CU to: Transmit a UE (user equipment) context setup request message to the first DU (distributed unit), wherein the UE context setup request message: Information about a first IP (internet protocol) address used for uplink transmission in the user plane between the first DU and the CU to provide a PCell (primary cell); and Includes information about a second IP address used for uplink transmission in the user plane between the second DU and the CU to provide SCell (secondary cell), Receive a UE context setup response message from the first DU, and the UE context setup response message includes information about a third IP address used for downlink transmission in a user plane between the first DU and the CU and information about a fourth IP address used for downlink transmission in a user plane between the second DU and the CU, Transmitting a first user data message including a first PDCP (packet data convergence protocol) PDU (protocol data unit) and first SN (sequence number) synchronization information for the first PDCP PDU to the first DU based on the third IP address; Causing the second DU to transmit a second user data message including a second PDCP PDU and second SN synchronization information for the second PDCP PDU based on the fourth IP address; CU.

12. In claim 11, The above first SN synchronization information includes the SN of the start PDCP PDU transmitted after the setup procedure of CA (carrier aggregation) for the PCell and the SCell is completed and the number of modulo cycles from the SN of the start PDCP PDU to the SN of the first PDCP PDU, The second SN synchronization information includes the SN of the start PDCP PDU and the number of modulo cycles from the SN of the start PDCP PDU to the SN of the second PDCP PDU. CU.

13. In claim 12, The above UE context modification request message includes information about the PDCP SN length, which is 12-bit or 18-bit, The first DU includes a first radio link control (RLC) entity configured to perform RLC SN numbering based on at least one of the PDCP SN length, the SN of the starting PDCP PDU, or the number of modulo cycles up to the SN of the first PDCP PDU, The second DU includes a second RLC entity configured to perform RLC SN numbering based on at least one of the PDCP SN length, the SN of the starting PDCP PDU, or the number of modulo cycles up to the SN of the second PDCP PDU. CU.

14. In claim 13, The above UE context setup request message is used to cause the first DU to transmit an SCell setup request message to the second DU, The SCell setup request message includes an instruction for configuring a second RLC entity for the CA, configuration information related to a first RLC entity for the CA, and the second IP address. CU. In 15.DU(distributed unit), at least one processor; and A memory for storing instructions, wherein the instructions, when executed by the at least one processor, cause the DU to: Receive a UE (user equipment) context setup request message from a CU (central unit) connected to the above DU, and the UE context setup request message: Information about the first IP (internet protocol) address used for uplink transmission in the user plane between the DU and the CU to provide PCell (primary cell); and Includes information about a second IP address used for uplink transmission in the user plane between another DU and the CU to provide SCell (secondary cell), Transmitting an SCell setup request message including information about the second IP address to the other DU, Receive an SCell setup response message in response to the SCell setup request message from the other DU, wherein the SCell setup response message includes information related to a fourth IP address used for downlink transmission in the user plane between the CU and the other DU, Transmitting a UE context setup response message to the CU, wherein the UE context setup response message includes information about a third IP address used for downlink transmission of a user plane between the CU and the DU and information about a fourth IP address used for downlink transmission of a user plane between the CU and the other DU, Causing the DU to receive a first user data message including a first PDCP (packet data convergence protocol) PDU (protocol data unit) and first SN (sequence number) synchronization information for the first PDCP PDU from the CU based on the third IP address. DU.

Images