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

Abstract

According to embodiments, an electronic device of a first distributed unit (DU) is provided. The electronic device may comprise a memory, at least one transceiver, and at least one processor coupled to the memory and the at least one transceiver. The at least one processor may be configured to transmit a setup request message to a second DU through a communication interface between the first DU and the second DU. The at least one processor may be configured to receive a setup response message from the second DU.

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 is applicable as prior art related to the present disclosure.

[0014] According to embodiments, a method performed by a first distributed unit (DU) is provided. The method may include transmitting a DU group setup request message to a second DU via a communication interface between the first DU and the second DU. The method may include receiving a DU group setup response message from the second DU. The DU group setup request message may include at least one of identification information related to the first DU, address information related to the first DU, version information of the first DU, cell information for each cell provided by the first DU, information indicating whether the first DU supports a DU-to-DU carrier aggregation (CA) function, or information indicating whether the first DU supports a DC (dual connectivity) function. The DU group setup response message may include at least one of identification information related to the second DU, address information related to the second DU, version information of the second DU, cell information for each cell provided by the second DU, information indicating whether the second DU supports a CA function between DUs, or information indicating whether the second DU supports a DC function.

[0015] According to embodiments, an electronic device of a first distributed unit (DU) is provided. The electronic device may include a memory, at least one transceiver, and at least one processor coupled with the memory and the at least one transceiver. The at least one processor may be configured to transmit a DU group setup request message to a second DU through a communication interface between the first DU and the second DU. The at least one processor may be configured to receive a DU group setup response message from the second DU. The DU group setup request message may include at least one of identification information related to the first DU, address information related to the first DU, version information of the first DU, cell information for each cell provided by the first DU, information indicating whether the first DU supports a DU-to-DU carrier aggregation (CA) function, or information indicating whether the first DU supports a DC (dual connectivity) function. The DU group setup response message may include at least one of identification information related to the second DU, address information related to the second DU, version information of the second DU, cell information for each cell provided by the second DU, information indicating whether the second DU supports a CA function between DUs, or information indicating whether the second DU supports a DC function.

[0016] According to embodiments, a non-transitory storage medium is provided. The non-transitory storage medium may include a memory storing a program including instructions. When the instructions are executed, an electronic device may be configured to perform procedures for signaling at an interface between DUs. When the instructions are executed, the instructions may cause the electronic device to transmit a DU group setup request message to a second DU through a communication interface between the first DU and the second DU. When the instructions are executed, the instructions may cause the electronic device to receive a DU group setup response message from the second DU. The DU group setup request message may include at least one of identification information related to the first DU, address information related to the first DU, version information of the first DU, cell information for each cell provided by the first DU, information indicating whether the first DU supports a CA (carrier aggregation) function between DUs, or information indicating whether the first DU supports a DC (dual connectivity) function. The DU group setup response message may include at least one of identification information related to the second DU, address information related to the second DU, version information of the second DU, cell information for each cell provided by the second DU, information indicating whether the second DU supports a CA function between DUs, or information indicating whether the second DU supports a DC function.

[0017] In embodiments, a method performed by a first distributed unit (DU) is provided. The method may include transmitting a setup request message to a second DU through a communication interface between the first DU and the second DU. The method may include receiving a setup response message from the second DU. The setup request message may include at least one of identification information associated with the first DU or cell information for each cell provided by the first DU. The setup response message may include at least one of identification information associated with the second DU or address information associated with the second DU.

[0018] In embodiments, an electronic device of a first distributed unit (DU) is provided. The electronic device may include at least one processor and a memory storing instructions. The instructions, when executed by the at least one processor, may cause the electronic device to transmit a setup request message to a second DU through a communication interface between the first DU and the second DU, and to receive a setup response message from the second DU. The setup request message may include at least one of identification information associated with the first DU or cell information for each cell provided by the first DU. The setup response message may include at least one of identification information associated with the second DU or cell information for each cell provided by the second DU.

[0019] 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:

[0020] FIGS. 1A and 1B illustrate examples of wireless communication systems according to embodiments of the present disclosure.

[0021] FIGS. 2A to 2C illustrate examples of spectrum aggregation environments according to embodiments of the present disclosure.

[0022] FIG. 3 illustrates an example of a resource structure in the time domain and frequency domain according to embodiments of the present disclosure.

[0023] FIG. 4a illustrates a protocol stack in a control plane according to embodiments of the present disclosure.

[0024] FIG. 4b illustrates a protocol stack in a user plane according to embodiments of the present disclosure.

[0025] FIG. 5 illustrates an example of spectrum aggregation between distributed units (DUs) according to embodiments of the present disclosure.

[0026] FIG. 6 illustrates an example of a control plane for spectrum aggregation between DUs according to embodiments of the present disclosure.

[0027] FIGS. 7A and 7B illustrate a DU group setup procedure according to embodiments of the present disclosure.

[0028] FIG. 7c illustrates a DU group modification procedure according to embodiments of the present disclosure.

[0029] FIG. 8 illustrates a DU group release procedure according to embodiments of the present disclosure.

[0030] FIG. 9 illustrates a resource status report procedure according to embodiments of the present disclosure.

[0031] FIG. 10A illustrates a SCell (secondary cell) configuration setup procedure according to embodiments of the present disclosure.

[0032] FIG. 10b illustrates a SCell configuration modification request procedure according to embodiments of the present disclosure.

[0033] FIG. 10c illustrates a SCell configuration modification required procedure according to embodiments of the present disclosure.

[0034] FIG. 10d illustrates a SCell de-configuration procedure according to embodiments of the present disclosure.

[0035] FIG. 10e illustrates a SCell deconfiguration request procedure according to embodiments of the present disclosure.

[0036] FIG. 11 illustrates signal flows for SCell configuration setup according to embodiments of the present disclosure.

[0037] FIG. 12 illustrates signal flows for a SCell configuration modification procedure initiated by a central unit (CU) according to embodiments of the present disclosure.

[0038] FIG. 13 illustrates signal flows for a SCell configuration modification procedure initiated by a PCell (primary cell)-DU according to embodiments of the present disclosure.

[0039] FIG. 14 illustrates signal flows for a SCell configuration modification procedure initiated by a SCell-DU according to embodiments of the present disclosure.

[0040] FIG. 15 illustrates an example of a user plane for spectrum aggregation between DUs according to embodiments of the present disclosure.

[0041] FIG. 16 illustrates examples of components of an electronic device according to embodiments of the present disclosure.

[0042] 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.

[0043] 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.

[0044] 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.

[0045] 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"}.

[0046] 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.

[0047] 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.

[0048] 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.

[0049] 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.

[0050] 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).

[0051] 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.

[0052] 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.

[0053] FIGS. 1A and 1B illustrate examples of wireless communication systems according to embodiments of the present disclosure.

[0054] 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).

[0055] 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.

[0056] 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.

[0057] 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.

[0058] 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.

[0059] 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).

[0060] 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 (120). DC technology is a technology that increases frequency usage 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.

[0061] 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.

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

[0063] 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.

[0064] 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.

[0065] 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.

[0066] 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.

[0067] 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).

[0068] Figures 2a to 2c illustrate examples of spectrum aggregation environments according to embodiments of the present disclosure. 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 primary cell (PCell) and a primary cell (SCell) may be used together for data communication. For example, spectrum aggregation may include DC. The frequency range occupied by a cell of an MCG of an MN and the frequency range occupied by a cell of an SCG of an 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.

[0069] 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.

[0070] 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)).

[0071] 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).

[0072] 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).

[0073] 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.

[0074] 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.

[0075] FIG. 3 illustrates examples of resource structures in the time and frequency domains according to embodiments of the present disclosure. FIG. 3 illustrates the basic structure of the time-frequency domain, which is a wireless resource region in which data or control channels are transmitted in the downlink or uplink.

[0076] 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).

[0077] 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.

[0078] 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.

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

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

[0081] FIG. 4a illustrates a protocol stack (400) in a control plane according to embodiments of the present disclosure.

[0082] 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).

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

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

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

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

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

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

[0089] - Security functions including key management

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

[0091] - Mobility features including:

[0092] 1) Handover and context transfer

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

[0094] 3) Inter-RAT mobility

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

[0096] - UE measurement reporting and reporting control;

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

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

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

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

[0101] - User data transfer function

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

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

[0104] - PDCP PDU reordering for reception

[0105] - Duplicate detection of lower layer SDUs

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

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

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

[0109] 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.

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

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

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

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

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

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

[0116] - Re-segmentation of RLC data PDUs

[0117] - Reordering of RLC data PDUs

[0118] - Duplicate detection function

[0119] - Protocol error detection

[0120] - RLC SDU discard function

[0121] - RLC re-establishment function

[0122] 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.

[0123] 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.

[0124] 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.

[0125] 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).

[0126] 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.

[0127] 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.

[0128] 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 the received RLC PDUs to record any lost RLC PDUs.

[0129] 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.

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

[0131] - Multiplexing / demultiplexing of MAC SDUs

[0132] - Scheduling information reporting function

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

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

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

[0136] - MBMS service identification function

[0137] - Transport format selection function

[0138] - Padding function

[0139] 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.

[0140] FIG. 4b illustrates a protocol stack (450) in a user plane according to embodiments of the present disclosure.

[0141] 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).

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

[0143] - Transfer of user plane data

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

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

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

[0147] 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.

[0148] 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.

[0149] 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.

[0150] 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.

[0151] FIG. 5 illustrates an example of spectrum aggregation between distributed units (DUs) according to embodiments of the present disclosure.

[0152] 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.

[0153] 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).

[0154] 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).

[0155] SCell reconfiguration, addition, and removal can be performed by RRC. During handovers within NR 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.

[0156] 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. In order to support inter-DU CA even if they are not the same vendor or not in the same region, an interface between DUs may be defined. Hereinafter, the interface between DUs is referred to as an X1 interface, but the interface may be referred to instead by another term having the same technical meaning (e.g., M1, F3, MV, XD). The interface between DUs in the control plane 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 share call control information between DUs and may be used for setup procedures. The X1-U interface (582) can be used for CA bearer transfer between DUs, signaling between MAC layers, and information sharing.

[0157] FIG. 6 illustrates an example of a control plane for spectrum aggregation between DUs according to embodiments of the present disclosure.

[0158] Referring to FIG. 6, CU (505) can be responsible for functions of RRC (615) and functions of PDCP (614). CU (505) can be connected to DU #1 (510) via F1 interface. The F1 interface can include F1-C interface (681) for control plane and F1-U interface (682) for user plane.

[0159] DU #1 (510) and DU #2 (510) 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. DU #1 (510) may be a node providing a PCell of CA. DU #1 (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 MAC processing module (612) may be configured to process functions of the MAC (422) and the MAC (472). The RLC-H processing module (613a) and the RLC-L processing module (613b) may be configured to process functions of the RLC (424) and the RLC (474). Among the functions of RLC (424) and RLC (474), 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 DU #2 (520).

[0160] DU #2 (520) may be a node providing SCell of CA. DU #2 (520) may include a MAC processing module (622), an RLC-L processing module (623b), and a call processing block (672). The MAC processing module (622) may be configured to process functions of MAC (422) and MAC (472). The RLC-L processing module (623b) may be configured to process at least some of functions of RLC (424) and RLC (474). The call processing block (672) may be configured to process parameters received from DU #1 (520). Although not shown in FIG. 6, according to one embodiment, DU #2 (520) may also have an F1 interface with CU (505). In this case, the call processing block (672) of DU #2 (520) may be configured to process parameters (e.g., RRC IEs) received from CU (505).

[0161] To configure inter-DU CA according to embodiments of the present disclosure, various parameters may be provided through an interface between DUs. At least some of the parameters may be received from the CU (505) or generated within the DU.

[0162] According to embodiments, parameters for identification information may be provided through the interface between DUs. For example, cell ID (identifier), DU ID, and gNB ID, which are unique information of the base station, may be used to recognize a specific cell, DU, or gNB, respectively. For example, when connecting IPs between DUs, fixed internal IP addressing may be used instead of public IP. The fixed internal IP may be used to prevent IP conflicts. Alternatively, a unique key may be used when setting a fixed user defined routing (UDR) port number. For ID management convenience, the Node ID value may be utilized as a unique key in a specific region. For example, site ID information may be used as a unique key in inter-DU CA between regions for CA operation that distinguishes intra-site and inter-site.

[0163] According to embodiments, parameters for address information may be provided via an interface between DUs. For CA communication between DUs, a source DU may set its own Source X1-C IP address, and an IP address of another DU may also be set as a Target X1-C IP address. For signaling and bearer communication for CA between DUs, a source DU may set its own Source X1-U IP address. A source DU may also set a Target X1-U IP address for an IP address of another DU.

[0164] According to embodiments, parameters related to functions may be provided through an interface between DUs. When transmitting a CA signaling packet through an X1-C interface (581) or a CA bearer packet through an X1-U interface (582), DSCP (Differentiated Services Code Point) setting may be supported to ensure priority. When transmitting a CA signaling packet through an X1-C interface (581) or a CA bearer packet through an X1-U interface (582), VLAN (virtual local area network) ID setting may be supported to determine a path.

[0165] According to embodiments, a timer (e.g., Setup Retry Timer) may be defined to handle cases where DU group setup fails or is canceled. When the timer expires, the DU may attempt to set up the DU group again. Procedures related to the timer are described in FIGS. 7b and 8 .

[0166] The parameters described above can be defined as shown in the table below.

[0167] ParameterDescriptionCell IDUnique ID information for the cell in the DUDU IDUnique ID information for the DUgNB IDUnique ID information for the gNB (e.g., Global gNB ID)Node IDUnique ID information for the gNB in ​​a specific region (e.g., Site indicated by Site ID)Site IDUnique ID information for the Site where the DU existsInter DU CA On / offOn / Off setting for Inter DU CA operationSource X1-C IP addressSet the IP address of this DU for sending and receiving inter-DU call procedure packets for Inter DU CASource X1-U IP addressSet the IP address of this DU for sending and receiving inter-DU CA bearer and signaling packets for Inter DU CATarget X1-C IP addressSet the IP address of the other DU for sending and receiving inter-DU call procedure packets for Inter DU CATarget X1-U IP addressSet the IP address of the other DU for sending and receiving inter-DU CA bearer and signaling packets for Inter DU CASCTP STATUSDU Group setup Information about the Connection Status when completed. CA Signaling DSCP I Sets the DSCP ID to be applied when transmitting CA Signaling Packets between DUs through the DX1-U interface. CA Bearer DSCP I Sets the DSCP ID to be applied when transmitting CA Bearer Packets between DUs through the DX1-U interface. CA Signaling VLAN I Sets the VLAN ID to be applied when transmitting CA Signaling Packets between DUs through the DX1-U interface. CA Bearer VLAN I Sets the VLAN ID to be applied when transmitting CA Bearer Packets between DUs through the DX1-U interface. Setup Retry Timer DU GroupA timer to wait until the setup procedure is re-executed.

[0168] Meanwhile, the parameters described above are exemplary, and the table is not used to limit the interpretation of the embodiments of the present disclosure for CA between DUs according to the embodiments of the present disclosure. For example, some of the parameters may not be used in the interface between DUs. For example, some of the parameters may be set internally within the DU. For example, some of the parameters may have fixed values.

[0169] Figures 7a and 7b illustrate a DU group setup procedure according to embodiments of the present disclosure. The DU group setup procedure is a procedure for sharing and initially setting up necessary information between DUs for Inter-DU CA.

[0170] Referring to FIG. 7A, in operation (701), DU #1 (510) may transmit an X1 DU group setup request message to DU #2 (520). According to one embodiment, when specific information is set, DU #1 (510) may transmit an X1 DU group setup request message to DU #2 (520). For example, the specific information may be a value indicating inter-DU CA (e.g., On of Inter DU CA Flag). For example, the specific information may include information on the counterpart DU (e.g., Target IP address). For example, the specific information may include DSCP or VLAN ID. According to one embodiment, when a specific message is received, DU #1 (510) may transmit an X1 DU group setup request message to DU #2 (520). For example, the message may include the X1 DU group setup rejection message of FIG. 7b or the DU group setup release message of FIG. 8. After receiving the specific message, DU #1 (510) may transmit an X1 DU group setup request message after a certain period of time has elapsed.

[0171] DU #1 (510) can provide DU #2 (520) with attribute information of DU #1 (510). For example, the X1 DU group setup request message can include at least one of the following parameters.

[0172] - DU SW Version: Indicates the software version of DU #1 (510).

[0173] - CA / DC Function on / off information (Inter DU CA On / off Flag, EN-DC Usage flag, NR-DC Usage flag, SA Usage flag): Indicates whether a specific function (e.g., CA function and / or DC function) is activated in DU #1 (510). 'flag' can be used to indicate the function. For example, in the SCell addition procedure of inter-DU CA, a DU with the CA function disabled can be excluded from selection. For example, in the SN addition procedure, when selecting an SCell within the SN, a DU with the DC function disabled can be excluded from selection.

[0174] - Transport information (Source RLC IP Address information for Inter DU CA, Source MAC IP Address information for Inter DU CA)

[0175] - ID Information: Site ID, gNB ID, DU ID, Node ID, Cell ID: Indicates the region ID where DU #1 (510) is located, the global gNB ID of DU #1 (510), the ID of DU #1 (510), and the cell ID provided by DU #1 (510).

[0176] - Served Cell information: Band, Bandwidth, SCS(subcarrier spacing), TDD ratio, Slice ID, PLMN, Symmetric / Asymmetric DSS: The TDD ratio can indicate the ratio of UL resources to DL resources of a TDD cell. For example, in the SCell addition procedure of inter-DU CA, an SCell with a TDD ratio equal to or related to the TDD ratio of the PCell can be selected. The Slice ID can be used to identify a network slice. For example, in the SCell addition procedure of inter-DU CA, an SCell that can support the network slice of the Slice ID of the PCell can be selected. Symmetric DSS indicates a cell whose center frequency / bandwidth of an LTE cell matches the center frequency / bandwidth of an NR cell, and Asymmetric DSS indicates a cell of a DSS other than Symmetric DSS.

[0177] - Cell Status information (Normal / Disabled)

[0178] In operation (703), DU #2 (520) may transmit an X1 DU Group Setup Response (DU GROUP SETUP RESPONSE) message to DU #1 (510). If DU #2 (520) successfully receives the X1 DU Group Setup Request message of DU #1 (510), it may transmit an X1 DU Group Setup Response message as a response to the X1 DU Group Setup Request message.

[0179] DU #2 (520) can identify whether the packages between DU #1 (510) and DU #2 (520) are compatible in order to determine whether the X1 DU group setup request message has been successfully received. For example, DU #2 (520) can identify whether the packages are compatible through the software version of DU #1 (510). DU #2 (520) can confirm whether the configuration information for DU #1 (510) has been normally entered. For example, DU #2 (520) can confirm whether the configuration information for DU #1 (510) has been normally entered through the IP address information for DU #1 (510) and / or whether the CA function has been activated. DU #2 (520) can identify that the X1 connection with DU #1 (510) is normal and that the attribute information of DU #1 (510) is suitable for configuring inter-DU CA with DU #2 (520). DU #2 (520) can continue the DU group setup procedure for configuring inter-DU CA.

[0180] DU #2 (520) can provide DU #1 (510) with attribute information of DU #2 (520). For example, the X1 DU group setup response message can include at least one of the following parameters.

[0181] - DU SW Version: Indicates the software version of DU #2 (520).

[0182] - CA / DC Function on / off information (Inter DU CA On / off Flag, EN-DC Usage flag, NR-DC Usage flag, SA Usage flag): Indicates whether a specific function (e.g., CA function and / or DC function) is activated in DU #2 (520). To indicate the function, 'flag' can be used. For example, in the SCell addition procedure of inter-DU CA, a DU with the CA function disabled can be excluded from selection. For example, in the SN addition procedure, when selecting an SCell within the SN, a DU with the DC function disabled can be excluded from selection.

[0183] - Transport information (Source RLC IP Address information for Inter DU CA, Source MAC IP Address information for Inter DU CA)

[0184] - ID Information: Site ID, gNB ID, DU ID, Node ID, Cell ID: Indicates the region ID where DU #2 (520) is located, the global gNB ID of DU #2 (520), the ID of DU #2 (520), and the cell ID provided by DU #2 (520).

[0185] - Served Cell information: Band, Bandwidth, SCS(subcarrier spacing), TDD ratio, Slice ID, PLMN, Symmetric / Asymmetric DSS: The TDD ratio can indicate the ratio of UL resources to DL resources of a TDD cell. For example, in the SCell addition procedure of inter-DU CA, an SCell with a TDD ratio equal to or related to the TDD ratio of the PCell can be selected. The Slice ID can be used to identify a network slice. For example, in the SCell addition procedure of inter-DU CA, an SCell that can support the network slice of the Slice ID of the PCell can be selected. Symmetric DSS indicates a cell whose center frequency / bandwidth of an LTE cell matches the center frequency / bandwidth of an NR cell, and Asymmetric DSS indicates a cell of a DSS other than Symmetric DSS.

[0186] - Cell Status information (Normal / Disabled)

[0187] Although FIG. 7a illustrates a case where a DU group setup request message is successfully processed, the DU group setup request message may not be successfully processed. Below, FIG. 7b illustrates a procedure for a case where a DU group setup request message is unsuccessfully processed.

[0188] Referring to FIG. 7b, in operation (751), DU #1 (510) may transmit an X1 DU Group Setup Request (DU GROUP SETUP REQEUST) message to DU #2 (520). For operation (751), reference may be made to the description for operation (701).

[0189] In operation (753), DU #2 (520) may transmit an X1 DU group setup reject (DU GROUP SETUP REJECT) message to DU #1 (510). For example, if the software version of DU #1 (510) is different from the software version of DU #2 (520), DU #2 (520) may decide to reject the X1 DU group setup request message. For another example, if the address information provided from DU #1 (510) is different from the address information identified in DU #2 (520), DU #2 (520) may decide to reject the X1 DU group setup request message. For another example, if the function requested from DU #1 (510) is not supported by DU #2 (520), DU #2 (520) may decide to reject the X1 DU group setup request message. For example, the X1 DU group setup rejection message may include cause information. The cause information may indicate the cause of the rejection. For example, the cause information may indicate that the software version is not compatible ('SW Version is not compatible'). For example, the cause information may indicate that the configuration between DU #1 (510) and DU #2 (520) does not match ('Configuration mismatch').

[0190] After a specified time (754) has elapsed, in operation (755), DU #1 (510) may retransmit an X1 DU Group Setup Request (DU GROUP SETUP REQEUST) message to DU #2 (520). For example, the length of the specified time (754) may be a fixed value. In another example, the length of the specified time (754) may be set from DU #2 (510). For example, a timer corresponding to the length of the specified time (754) may be set by a message of DU #2 (520) (e.g., a DU Group Setup Reject message).

[0191] Meanwhile, unlike as illustrated in FIG. 7b, according to another embodiment, DU #1 (510) that receives an X1 DU group setup rejection message may not perform a retry of the DU group setup. For example, if the cause information indicates 'software is not compatible (SW Version is not compatible)', DU #1 (510) may not perform a retry of the DU group setup. DU #1 (510) may wait until it receives an X1 DU GROUP setup request message from DU #2 (520) after the software package in DU #2 (520) is upgraded to a compatible version.

[0192] In the DU group setup procedure described through FIGS. 7A and 7B, version information, identification information, address information, and parameters related to specific functions can be shared between DUs (e.g., DU #1 (510), DU #2 (520)). Through the shared information, whether CA is performed between DUs can be determined. Hereinafter, in the present disclosure, DU group setup may be referred to as setup for convenience of description. For example, a DU setup request message may be referred to as a setup request message, and a DU setup response message may be referred to as a setup response message.

[0193] In one embodiment, whether or not to perform inter-DU CA may be determined based on whether the function is activated. For example, let us assume a situation where NR-CA is performed in EN-DC, NR-DC, or SA, respectively, by sharing and checking the on / off of the EN-DC Usage flag, NR-DC Usage flag, and SA Usage flag. DU #1 (510) may support CA in EN-DC, NR-DC, and SA. If the corresponding flag (e.g., EN-DC Usage flag, NR-DC Usage flag, or SA Usage flag) of DU #2 (520) is on, DU #1 (510) may perform inter-DU CA between DUs. If the corresponding flag of DU #2 (520) is off, DU #1 (510) may not perform inter-DU CA between DUs. For example, in a situation where an SCell is to be added for an EN-DC UE, if the EN-DC Usage flag of DU #2 (520) indicates off, DU #1 (510) may not perform inter-DU CA with DU #2 (520).

[0194] When CA is performed between DUs, DU #1 (510) can establish an X1-U connection with DU #2 (520) during the UE context management procedure by sharing the IP addresses for the CA bearer and signaling of each DU. In addition, DU #1 (510) can transmit and receive packets with DU #2 (520) through the CA bearer.

[0195] In order to configure inter-DU CA, serving cell information shared between DUs can be used. By sharing serving cell information of each DU, the band, bandwidth, or SCS of the counterpart DU can be identified. In the UE context management procedure, the DU can perform selection of a band combination and a specific feature set based on the serving cell information of the counterpart DU. According to one embodiment, through sharing of serving cell information, DU #1 (510) can obtain serving cell information of DU #2 (520). DU #1 (510) can check the TDD ratio of the cell of DU #2 (520). Based on the result of checking the TDD ratio, DU #1 (510) can configure inter-DU CA only for the supportable TDD CA combination when performing the UE context management procedure. In one embodiment, through sharing of serving cell information, DU #1 (510) can identify the slice ID of DU #2 (520). Based on the slice ID, DU #1 (510) can configure inter-DU CA only for the supportable network slice when performing a UE context management procedure. In one embodiment, through sharing of serving cell information, DU #1 (510) can identify the Public Land Mobile Network selection (PLMN) of DU #2 (520). Based on the PLMN, DU #1 (510) can configure inter-DU CA only for the supportable PLMN when performing a UE context management procedure. In one embodiment, through sharing of serving cell information, DU #1 (510) can identify DSS cell information of DU #2 (520). For example, the DSS cell information may indicate whether the cell provides Symmetric DSS or Asymmetric DSS.DU #1 (510) can configure inter-DU CA only for supportable DSS cells when performing UE context management procedure based on the DSS cell information. According to one embodiment, through sharing of serving cell information, DU #1 (510) can identify cell status information (e.g., Cell Status information (Normal / Disabled)) of DU #2 (520). DU #1 (510) can configure inter-DU CA only for cells in normal status (i.e., cells that are not disabled) when performing UE context management procedure based on the cell status information.

[0196] Figure 7c illustrates a DU group modification procedure according to embodiments of the present disclosure. In the DU group setup procedure described in Figures 7a and 7b, if changes to some information are required or additional settings are required, the DU group setup procedure may be utilized. This procedure may be used to modify and setup necessary information between DUs.

[0197] Referring to FIG. 7c, in operation (771), DU #1 (510) may transmit an X1 DU Group Modification Request (DU GROUP MODIFICATION REQEUST) message to DU #2 (520). DU #1 (510) may transmit an X1 DU Group Setup Request message to DU #2 (520) if a change is required in at least one of the parameters set through the DU Group Setup procedure.

[0198] DU #1 (510) can provide attribute information that requires a change in DU #1 (510) to DU #2 (520). For example, the X1 DU group modification request message can include at least one of the following parameters. For a description of each parameter, reference may be made to the descriptions in FIGS. 7A and 7B.

[0199] - DU SW Version, Inter DU CA On / off Flag, EN-DC Usage flag, NR-DC Usage flag, SA Usage flag

[0200] - Source RLC IP Address information for Inter DU CA

[0201] - Source MAC IP Address information for Inter DU CA

[0202] - ID Information: Site ID, gNB ID, DU ID, Node ID, Cell ID,

[0203] - Served Cell information: Band, Bandwidth, SCS, TDD Ratio, Slice ID, PLMN, Sym / Asymmetric DSS

[0204] - Cell Status information (Normal / Disabled)

[0205] In operation (773), DU #2 (520) may transmit an X1 DU Group Modification Response (DU GROUP MODIFICATION RESPONSE) message to DU #1 (510). If DU #2 (520) successfully receives the X1 DU Group Modification Request message of DU #1 (510), it may transmit an X1 DU Group Modification Response message as a response to the X1 DU Group Modification Request message.

[0206] DU #2 (520) can identify whether the packages between DU #1 (510) and DU #2 (520) are compatible in order to determine whether the X1 DU group modification request message has been successfully received. For example, DU #2 (520) can identify whether the packages are compatible through the software version of DU #1 (510). DU #2 (520) can check whether the configuration information for DU #1 (510) has been normally input. DU #2 (520) can identify whether the changed information of DU #1 (510) is normally accepted by DU #2 (520). If DU #2 (520) determines that the changed information of DU #1 (510) is acceptable, DU #2 (520) can continue the DU group modification procedure to configure CA between DUs.

[0207] DU #2 (520) may provide DU #1 (510) with information that requires a change in DU #2 (520). For example, the X1 DU group modification response message may include at least one of the following parameters. For a description of each parameter, reference may be made to the descriptions in FIGS. 7A and 7B.

[0208] - DU SW Version, Inter DU CA On / off Flag, EN-DC Usage flag, NR-DC Usage flag, SA Usage flag

[0209] - Source RLC IP Address information for Inter DU CA

[0210] - Source MAC IP Address information for Inter DU CA

[0211] - ID Information: Site ID, gNB ID, DU ID, Node ID, Cell ID,

[0212] - Served Cell information: Band, Bandwidth, SCS, TDD Ratio, Slice ID, PLMN, Sym / Asymmetric DSS

[0213] - Cell Status information (Normal / Disabled)

[0214] If there are no parameters that need to be changed in DU #2 (520), the parameters described above may be omitted from the message.

[0215] Through the DU group modification procedure of Fig. 7c, version information, identification information, address information, and parameters related to specific functions that require changes can be shared between DUs (e.g., DU #1 (510), DU #2 (520)). Through the shared information, whether to perform CA between DUs can be determined.

[0216] In one embodiment, whether or not to perform inter-DU CA may be determined based on whether the function is activated. For example, let us assume a situation where NR-CA is performed in EN-DC, NR-DC, or SA, respectively, by sharing and checking the On / Off of the EN-DC Usage flag, NR-DC Usage flag, and SA Usage flag. DU #1 (510) may support CA in EN-DC, NR-DC, and SA. If the corresponding Flag (e.g., EN-DC Usage flag, NR-DC Usage flag, or SA Usage flag) of DU #2 (520) is On, DU #1 (510) may perform Inter DU CA between DUs. If the changed Flag of DU #2 (520) is Off, DU #1 (510) may not perform Inter DU CA between DUs. For example, in a situation where an SCell is to be added for an EN-DC UE, if the EN-DC Usage flag of DU #2 (520) indicates off, DU #1 (510) may not perform inter-DU CA with DU #2 (520).

[0217] When CA is performed between DUs, DU #1 (510) can establish an X1-U connection with DU #2 (520) during the UE context management procedure by sharing the IP addresses for the CA bearer and signaling of each DU. In addition, DU #1 (510) can transmit and receive packets with DU #2 (520) through the CA bearer.

[0218] To configure inter-DU CA, changed serving cell information can be used. By sharing the changed serving cell information, the band, bandwidth, or SCS of the counterpart DU can be identified. In the UE context management procedure, the DU can perform selection of a band combination and a specific feature set based on the changed serving cell information of the counterpart DU. According to one embodiment, by sharing the serving cell information, DU #1 (510) can obtain changed serving cell information of DU #2 (520). DU #1 (510) can check the TDD ratio of the cell of DU #2 (520). Based on the result of checking the TDD ratio, DU #1 (510) can configure inter-DU CA only for the supportable TDD CA combination when performing the UE context management procedure. In one embodiment, through sharing of serving cell information, DU #1 (510) can identify a changed slice ID of DU #2 (520). Based on the changed slice ID, DU #1 (510) can configure inter-DU CA only for supportable network slices when performing a UE context management procedure. In one embodiment, through sharing of serving cell information, DU #1 (510) can identify a changed Public Land Mobile Network selection (PLMN) of DU #2 (520). Based on the changed PLMN, DU #1 (510) can configure inter-DU CA only for supportable PLMNs when performing a UE context management procedure. In one embodiment, through sharing of serving cell information, DU #1 (510) can identify changed DSS cell information of DU #2 (520). For example, the above-mentioned changed DSS cell information may indicate whether the cell provides Symmetric DSS or Asymmetric DSS.Based on the changed DSS cell information, DU #1 (510) can configure inter-DU CA only for supportable DSS cells when performing a UE context management procedure. According to one embodiment, by sharing the changed serving cell information, DU #1 (510) can identify changed cell status information (e.g., Cell Status information (Normal / Disabled)) of DU #2 (520). Based on the changed cell status information, DU #1 (510) can configure inter-DU CA only for cells in a normal state (i.e., cells that are not disabled) when performing a UE context management procedure.

[0219] Although FIG. 7C illustrates only a successful case for a DU group modification request, embodiments of the present disclosure are not limited thereto. Rejection of a DU group modification request may also be included in embodiments of the present disclosure. According to one embodiment, unlike FIG. 7C, DU #2 (520) may transmit a DU group modification rejection message to DU #1 (510) in response to the DU group modification request message. For example, if the software version of DU #1 (510) is different from the software version of DU #2 (520), DU #2 (520) may decide to reject the X1 DU group modification request message. For another example, if the address information provided from DU #1 (510) is different from the address information identified in DU #2 (520), DU #2 (520) may decide to reject the X1 DU group modification request message. For another example, if a function changed from DU #1 (510) is not supported by DU #2 (520), DU #2 (520) may decide to reject the X1 DU group modification request message. For example, the X1 DU group modification rejection message may include cause information. The cause information may indicate the cause for the rejection. For example, the cause information may indicate that the software version is not compatible ('SW Version is not compatible'). For example, the cause information may indicate that the configuration between DU #1 (510) and DU #2 (520) does not match ('Configuration mismatch'). Thereafter, DU #1 (510) may, in response to the DU group modification rejection message, transmit the DU group modification request message again after a certain period of time or transmit the DU group release request message of FIG. 8.

[0220] FIG. 8 illustrates a DU group release procedure according to embodiments of the present disclosure. The DU group release procedure is performed via the X1 interface and can be used to release a DU group that was established via the DU group setup procedure.

[0221] Referring to FIG. 8, in operation (801), DU #1 (510) may transmit an X1 DU group release request (DU GROUP RELEASE REQEUST) message to DU #2 (520). The X1 DU group release request message may include cause information. The cause information may indicate a cause for release. DU #1 (510) may transmit the X1 DU group release request message when a specified condition is met. For example, when the 'Inter DU CA Flag' of DU #1 (510) and / or DU #2 (520) is off, DU #1 (510) may transmit the X1 DU group release request message to DU #2 (520). In addition, for example, when DU #1 (510) and / or DU #2 (520) are in a shutdown or locked state, DU #1 (510) may transmit an X1 DU group release request message to DU #2 (520). In addition, for example, when DU #1 (510) receives a DU group modification rejection message (e.g., a DU group modification rejection message of FIG. 7c) from DU #2 (520), DU #1 (510) may transmit an X1 DU group release request message to DU #2 (520). In addition, for example, when an IP address for a CA bearer and a signaling is changed and it is determined that the changed IP address is difficult to maintain for a terminal configured with CA between existing DUs, DU #1 (510) may transmit an X1 DU group release request message to DU #2 (520).

[0222] In operation (803), DU #2 (520) may transmit an X1 DU Group Release Response message to DU #1 (510). DU #1 (510) may identify that the DU group configured for inter-DU CA between DU #1 (510) and DU #2 (520) is released based on the X1 DU Group Release Response message. If the DU group including DU #1 (510) and DU #2 (520) is released, inter-DU CA using both DU #1 (510) and DU #2 (520) may not be allowed. CU (505), DU #1 (510), and / or DU #2 (520) may perform a UE context management procedure with a terminal (120) (e.g., UE) for which the inter-DU CA is configured. Through the UE context management procedure, the CA configuration for the terminal (120) can be changed or released.

[0223] After a specified time (804) has elapsed, in operation (805), DU #1 (510) may transmit an X1 DU Group Setup Request (DU GROUP SETUP REQEUST) message to DU #2 (520). For example, the length of the specified time (804) may be a fixed value. In another example, the length of the specified time (804) may be set from DU #2 (510). For example, a timer corresponding to the length of the specified time (804) may be set by a message (e.g., a DU Group Release Response message) of DU #2 (520). The timer may also be shared with DU #1 (510) via a message (e.g., a DU Group Release Request message).

[0224] FIG. 9 illustrates a resource status report procedure according to embodiments of the present disclosure. The resource status report procedure may be provided via the X1-X interface (581). It may be used to share resource information required for CA between DUs.

[0225] Referring to FIG. 9, in operation (901), DU #1 (510) may transmit a resource status report message to DU #2 (520). The resource status report message may be used to provide information that changes or requires updating relatively frequently compared to the DU group establishment procedure and the DU group modification procedure. Although FIG. 9 describes a situation in which DU #1 (510) transmits a resource status report message to DU #2 (520), embodiments of the present disclosure are not limited thereto. DU #2 (520) may also transmit a resource status report message to DU #1 (510). For example, the resource status report message may include the following information (e.g., information element (IE)).

[0226] - PRB Usage information by cell

[0227] - Information on the number of UEs per cell

[0228] - PRB usage information by cell and slice

[0229] - UE number information per cell and slice

[0230] In one embodiment, the resource status reporting procedure can be triggered based on various conditions. For example, if the initial DU GROUP setup procedure completes successfully, the resource status reporting procedure can be performed. The resource status reporting message can be sent periodically or when a specific event is detected.

[0231] In one embodiment, information provided through a resource status report message may be used for band combination and SCell selection. For example, DU #1 (510) may perform band combination and SCell selection based on a resource status report message received from DU #2 (520). DU #1 (510) may perform band combination and SCell selection with high expected throughput in inter-DU CA based on information about PRB usage and number of UEs of DU #2 (520). DU #1 (510) may perform band combination and SCell selection using not only information about PRB usage and number of UEs of DU #2 (520) but also information about PRB usage and number of UEs of DU #1 (510). In addition, DU #1 (510) can perform band combination and SCell selection with high expected throughput per slice in inter-DU CA based on information about PRB usage and number of UEs per slice of DU #2 (520). DU #1 (510) can perform band combination and SCell selection by using not only information about PRB usage and number of UEs per slice of DU #2 (520), but also information about PRB usage and number of UEs per slice of DU #1 (510).

[0232] The procedures for setting up, modifying, and releasing DU groups for inter-DU CA are described through FIGS. 7A to 9. To configure inter-DU CA for a UE, a UE context management procedure may be performed. Hereinafter, a UE context management procedure using an interface between DUs is described through FIGS. 10A to 14. When inter-DU CA for a terminal (120) is performed, a DU providing a PCell may be referred to as a PCell-DU, and a DU providing an SCell may be referred to as an SCell-DU. Each DU may provide multiple cells, and a plurality of SCells may also be configured. For example, two or more SCells may be configured in an SCell-DU, and other cells within the PCell-DU may also be operated as SCells.

[0233] FIG. 10A illustrates a SCell (secondary cell) configuration setup procedure according to embodiments of the present disclosure. The SCell configuration setup procedure can be performed via the X1-C interface (581). The procedure can be used to set up SCell configuration in a CA between DUs.

[0234] Referring to FIG. 10A, in operation (1001), DU #1 (510) may transmit a SCELL CONFIGURATION SETUP REQUEST message to DU #2 (520). For example, the SCell configuration setup request message may include the following information.

[0235] - Transport information (X1-U Source IP address): For example, indicates the IP address of DU #1 (510).

[0236] - Selected SpCell ID, Selected SCell List: SpCell (special cell) includes PCell and / or PSCell (primary secondary cell). The above information may include the SCell list for SCell setup request and information about PCell (e.g., the ID of PCell of DU #1 (510)).

[0237] - Bearer information (QCI(QoS class identifier) / 5QI(5G QoS identifier) ​​ID, PDCP / RLC / MAC configuration)

[0238] - Selected BC / featureset information: Band combination and feature set information. The feature set supported for each block of adjacent serving cells within a band can be referred to as a feature set (FS). A two-dimensional matrix of feature sets for all bands in a band combination (i.e., all feature sets per band) can be referred to as a feature set combination. The number of feature sets per band in a feature set combination is equal to the number of band entries in the band combination, and all feature sets per band can have the same number of feature sets. Each band combination can be associated with one feature set combination.

[0239] - C-RNTI (cell-radio network temporary identity) information

[0240] - MRDC (multi-RAT (radio access technology) DC) / NR / LTE UE Capability information

[0241] In operation (1003), DU #2 (520) may transmit a SCELL CONFIGURATION SETUP RESPONSE message to DU #1 (510). For example, the SCELL CONFIGURATION SETUP RESPONSE message may include the following information:

[0242] - Transport information (X1-U Target IP address): For example, indicates the IP address of DU #2 (520).

[0243] - Failed SCell List, Fail Cause: Displays a list of SCells for which SCell configuration setup failed. The above information may include information on the cause of the failure.

[0244] - SCell Configuration

[0245] Although not shown in FIG. 10a, DU #2 (520) may also transmit a SCell configuration setup failure message (or SCell configuration setup rejection message) to DU #1 (510). If the setup of all SCells requested by DU #1 (510) fails, DU #2 (520) may transmit a SCell configuration setup failure message to DU #1 (510). The SCell configuration setup failure message may include information about the cause of the failure. DU #1 (510) may not perform CA using the SCell of DU #2 (520) for the related terminal.

[0246] FIG. 10b illustrates a SCell configuration modification request procedure according to embodiments of the present disclosure. The SCell configuration modification request procedure may be performed via the X1-C interface (581). The procedure may be used to modify the SCell configuration in a CA between DUs. In FIG. 10b, the SCell configuration modification procedure may be triggered by DU #1 (510). For example, DU #1 (510) is a DU that provides a PCell and may be referred to as a PCell DU. DU #2 (520) is a DU that provides only an SCell and may be referred to as an SCell DU.

[0247] Referring to FIG. 10b, in operation (1011), DU #1 (510) may transmit a SCELL CONFIGURATION MODIFICATION REQUEST message to DU #2 (520). For example, the SCELL configuration modification request message may include the following information. For a description of each parameter, reference may be made to FIG. 10a.

[0248] - Transport information (X1-U Source IP address)

[0249] - Selected SPcell ID, Selected SCell List

[0250] - Bearer information (QCI / 5QI ID, PDCP / RLC / MAC configuration)

[0251] - Selected BC / featureset information.

[0252] - C-RNTI information

[0253] - MRDC / NR / LTE UE Capability information

[0254] In operation (1013), DU #2 (520) may transmit a SCELL CONFIGURATION MODIFICATION RESPONSE message to DU #1 (510). For example, the SCELL CONFIGURATION MODIFICATION RESPONSE message may include the following information. For a description of each parameter, reference may be made to FIG. 10A.

[0255] - Transport information (X1-U Target IP address)

[0256] - Failed SCell List, Fail Cause

[0257] - SCell Configuration

[0258] Although not shown in FIG. 10b, DU #2 (520) may also transmit a SCell configuration modification failure message to DU #1 (510). If all modifications of the SCell(s) requested by DU #1 (510) fail, DU #2 (520) may transmit a SCell configuration modification failure message to DU #1 (510). The SCell configuration modification failure message may include information about the cause of the failure. In one embodiment, when the SCell configuration modification failure message is received, DU #1 (510) may perform a SCell deconfiguration procedure. The procedure of FIG. 10d may be used for the SCell deconfiguration procedure. For example, if DU #1 (510) determines that it is difficult to maintain the existing settings with the UE, it may transmit a SCell deconfiguration request message to DU #2 (520).

[0259] FIG. 10C illustrates a SCell configuration modification request procedure according to embodiments of the present disclosure. The SCell configuration modification request procedure can be performed via the X1-C interface (581). The procedure can be used to modify the SCell configuration in a CA between DUs. Unlike FIG. 10B, the SCell configuration modification procedure can be triggered first by DU #2 (520), not DU #1 (510). For example, DU #1 (510) is a DU that provides a PCell and can be referred to as a PCell DU. DU #2 (520) is a DU that provides only an SCell and can be referred to as an SCell DU.

[0260] Referring to FIG. 10c, in operation (1021), DU #2 (520) may transmit a SCELL CONFIGURATION MODIFICATION REQUIRED message to DU #1 (510). For example, the SCELL CONFIGURATION MODIFICATION REQUIRED message may include the following information. For a description of each parameter, reference may be made to FIG. 10a.

[0261] - Transport information (X1-U Target IP address)

[0262] - Failed SCell List, Fail Cause

[0263] - SCell Configuration

[0264] In operation (1023), DU #1 (510) may transmit a SCELL configuration modification confirmation message to DU #2 (520). For example, the SCELL configuration modification confirmation message may include the following information. For a description of each parameter, reference may be made to FIG. 10A.

[0265] - Transport information (X1-U Source IP address)

[0266] - Selected SpCell ID, Selected SCell List

[0267] - Bearer information (QCI / 5QI ID, PDCP / RLC / MAC configuration)

[0268] - Selected BC / featureset information.

[0269] - C-RNTI information

[0270] - MRDC / NR / LTE UE Capability information

[0271] Although not shown in FIG. 10c, DU #1 (510) may also transmit a SCell configuration modification reject message to DU #2 (520). If DU #1 (510) does not accept the modification of the configuration of the SCell(s) requested by DU #2 (520), DU #1 (510) may transmit a SCell configuration modification reject message to DU #2 (520). The SCell configuration modification reject message may include information about the cause of the failure. In one embodiment, when the SCell configuration modification reject message is received, DU #2 (520) may perform a SCell configuration release request procedure. The procedure of FIG. 10e may be used for the SCell configuration release procedure. For example, if DU #2 (520) determines that it is difficult to maintain the existing configuration with the UE, DU #2 (520) may transmit a SCell configuration release request message to DU #1 (510).

[0272] FIG. 10d illustrates a SCell configuration release procedure according to embodiments of the present disclosure. The SCell configuration modification release procedure may be performed via the X1-C interface (581). The SCell configuration release procedure may be used to release an SCell configuration configured for a UE with inter-DU CA. In FIG. 10d, the SCell configuration release procedure may be triggered by DU #1 (510). For example, DU #1 (510) is a DU that provides a PCell and may be referred to as a PCell DU. DU #2 (520) is a DU that provides only an SCell and may be referred to as an SCell DU.

[0273] Referring to FIG. 10d, in operation (1061), DU #1 (510) may transmit a SCELL CONFIGURATION RELEASE COMMAND message to DU #2 (520). For example, the SCell configuration release command message may include information about the cause of the release.

[0274] In operation (1063), DU #2 (520) may transmit a SCELL CONFIGURATION RELEASE COMPLETE message to DU #1 (510). For example, the SCELL CONFIGURATION RELEASE COMPLETE message may include the following information. For a description of each parameter, reference may be made to FIG. 10A.

[0275] - Transport information (X1-U Target IP address)

[0276] - Failed SCell List, Fail Cause

[0277] - SCell Configuration

[0278] In one scenario, the SCell deconfiguration procedure may be triggered from a CU (e.g., CU 505). For example, CU 505 may transmit information about a list of SCells to be removed (e.g., 'SCell To Be Removed List' IE) to DU #1 (510). Based on the information, DU #1 (510) may transmit an SCell deconfiguration command message to DU #2 (520). The SCell deconfiguration command message may include cause information. DU #2 (520) may be a DU that provides the SCell indicated by the information. By transmitting the SCell deconfiguration command message, an SCell configured for inter-DU CA may be deconfigured.

[0279] FIG. 10e illustrates a SCell configuration release request procedure according to embodiments of the present disclosure. The SCell configuration modification release request procedure can be performed via the X1-C interface (581). The SCell configuration release request procedure can be used to release an SCell configuration configured for a UE with inter-DU CA. Unlike FIG. 10d, the SCell configuration release procedure can be triggered first by DU #2 (520) rather than DU #1 (510). For example, DU #1 (510) is a DU that provides a PCell and can be referred to as a PCell DU. DU #2 (520) is a DU that provides only an SCell and can be referred to as an SCell DU.

[0280] Referring to FIG. 10e, in operation (1071), DU #2 (520) may transmit a SCELL CONFIGURATION RELEASE REQUIRED message to DU #1 (510). For example, the SCell CONFIGURATION RELEASE REQUIRED message may include information regarding the cause of the release request.

[0281] In operation (1073), DU #1 (510) may transmit a SCELL CONFIGURATION RELEASE CONFIRM message to DU #2 (520). For example, the SCELL CONFIGURATION RELEASE CONFIRM message may include the following information. For a description of each parameter, reference may be made to FIG. 10A.

[0282] - Transport information (X1-U Target IP address)

[0283] - Failed SCell List, Fail Cause

[0284] - SCell Configuration

[0285] DU #2 (520) may transmit an SCell Deconfiguration Request message to DU #1 (510) when release of one or more SCell(s) of DU #2 (520) is required (e.g., cell access control (CAC)). The SCell Deconfiguration Request message may include cause information for the release. DU #1 (510) may transmit an SCell Deconfiguration Confirmation message to DU #2 (520) in response to the SCell Deconfiguration Request message. Thereafter, DU #1 (510) may initiate a procedure to request the CU to modify the UE context. For example, DU #1 (510) may transmit a message (e.g., an F1 UE Context Modification Required message) including SCell information to be released (e.g., an 'SCell To Be Removed List' IE) to the CU (e.g., CU (505)). As an example, the context modification request message may include the following information.

[0286] - SCell To Be Removed List

[0287] - DU To CU RRC Information (CellGroupConfig, Selected BandCombinationIndex, Selected FeatureSetEntryIndex

[0288] FIG. 11 illustrates signal flows for SCell configuration setup according to embodiments of the present disclosure. CU (505) and DU #1 (510) may be connected via an F1 interface. DU #1 (510) and DU #2 (520) may be connected via an X1 interface. For example, DU #1 (510) is a DU that provides PCell and may be a PCell DU. DU #2 (520) is a DU that provides only SCell and may be an SCell DU.

[0289] Referring to FIG. 11, DU #1 (510) may provide one or more first cells. For example, the one or more first cells may include cell #X and cell #Y. DU #2 (520) may provide one or more second cells. For example, the one or more second cells may include cell #A and cell #B.

[0290] In operation (1101), DU #1 (510) and DU #2 (520) can perform a DU group setup procedure. For the DU group setup procedure, at least one of the procedures described through FIGS. 7A to 9 can be performed. Hereinafter, a situation in which DU #1 (510) and DU #2 (520) are set as a DU group for inter-DU CA is described.

[0291] In operation (1111), the CU (505) may transmit a UE context setup request (UE CONTEXT SETUP REQEUST) message to the DU #1 (510). The CU (505) may include configuration information for signaling radio bearer (SRB) / data radio bearer (DRB) in the 'SRB / DRB to Be Setup List' IE in the UE context setup procedure. The CU (505) may transmit a UE context setup request message including the above IE to the DU #1 (510). In the UE context setup procedure, if an addition is required for the SCell of DU #2 (520), which is a SCell-DU (for example, if a new SCell of inter-DU CA is visible to the terminal (120) through MR (measurement report) operation, or if a blind SCell addition is performed), the CU (505) may transmit 'SCell To Be Setup List' information including information on the SCell of DU #2 (520) to DU #1 (510). DU #1 (510) may check whether the SCell of DU #2 (520), which is received as the 'SCell To Be Setup List' through the F1 UE context setup procedure from CU (505), is a SCell of a DU that has been set up as a DU group for inter-DU CA in advance. DU #1 (510) can perform setup procedures for SCell for inter-DU CA with DU #2 (520), which is the target DU.

[0292] For example, a UE context setup request message may include the following information:

[0293] - SCell To Be Setup List

[0294] - SRB / DRB to Be Setup List

[0295] In operation (1113), DU #1 (510) may transmit a SCell configuration setup request message to DU #2 (520). For example, DU #1 (510) may initiate a SCell configuration setup procedure when it receives a request for inter-DU CA from CU (505) targeting an SCell of another DU for a new UE. The description of FIG. 10A may be referenced for the SCell configuration setup request message. When DU #1 (510) receives a UE context setup request message from CU (505), it may perform setup for SRB / DRB through SCell configuration setup procedure with DU (e.g., DU #2 (520)) that is the target of inter-DU CA. DU #1 (510) may perform setup for SRB / DRB through SCell configuration setup procedure with DU #2 (520) that is the target of inter-DU CA.

[0296] In operation (1115), DU #2 (520) may transmit a SCELL configuration setup response message to DU #1 (510). The description of FIG. 10a may be referenced for the SCell configuration setup response message.

[0297] According to one embodiment, DU #1 (510) may recognize the band, bandwidth, SCS, TTD ratio, Slice ID, PLMN, and DSS cell information (e.g., whether Symmetric / Asymmetric DSS) of cells of a DU group previously received through a DU context management procedure (e.g., the DU group setup procedure of FIGS. 7A to 9). DU #1 (510) may select one or more SCells within a valid cell. DU #1 (510) may transmit an SCell configuration setup request message to another DU (e.g., DU #2 (520)) if the selected cell is located in the other DU. The SCell configuration setup request message may include 'Selected SCell List' information. The 'Selected SCell List' information may include information about the selected SCell(s). DU #2 (520) can receive 'Selected PSCell ID' and 'Selected SCell List' through SCell Configuration Setup Request message. DU #2 (520) can select a valid SCell from DU #2 (520). DU #2 (520) can transmit SCell Configuration Setup Response message including SCell configuration information for the selected SCell to DU #1 (510). If DU #2 (520) includes an invalid SCell among one or more SCells in the 'Selected SCell List', DU #2 (520) can generate SCell Configuration Setup Response message including 'Failed SCell list' and cause information for failure. DU #2 (520) can transmit the SCell Configuration Setup Response message to DU #1 (510). DU #1 (510) can receive the 'Failed SCell list'.DU #1 (510) may transmit a message containing information about failed SCells to CU (505) based on the 'Failed SCell list'. For example, DU #1 (510) may transmit a message containing the 'Failed SCell list' and information about the cause of the failure to CU (505).

[0298] According to one embodiment, DU #1 (510) may transmit bearer information (e.g., QCI / 5QI ID, PDCP / RLC / MAC configuration) to DU #2 (520) through an SCell configuration setup request message based on the SRB / DRB Setup List received from CU (505). When DU #2 (520) receives the bearer information (QCI / 5QI ID, PDCP / RLC / MAC configuration) through the SCell configuration setup request from DU #1 (510), it may generate a DRB that matches the settings.

[0299] According to one embodiment, DU #1 (510) may recognize the band, bandwidth, SCS, TTD ratio, Slice ID, PLMN, and DSS cell information (e.g., whether Symmetric / Asymmetric DSS) of cells in a DU group through a DU context management procedure (e.g., the DU group setup procedure of FIGS. 7A to 9). DU #1 (510) may determine the selected band combination and feature set information. DU #1 (510) may transmit an SCell configuration setup request message including the determined band combination and feature set information to DU #2 (520). When DU #2 (520) receives the band combination and feature set information from DU #1 (510) through the SCell configuration setup request, it may configure a cell within the corresponding band combination and feature set.

[0300] According to one embodiment, DU #1 (510) can determine C-RNTI information. DU #1 (510) can transmit an SCell configuration setup request message including the C-RNTI information to DU #2 (520). When DU #2 (520) receives the C-RNTI information through the SCell configuration setup request from DU #1 (510), it can check whether there is no conflict with the currently operating C-RNTI for the corresponding C-RNTI. Based on the check result, DU #2 (520) can apply the C-RNTI information to the SCell.

[0301] According to one embodiment, DU #1 (510) may transmit information about MRDC / NR / LTE UE capabilities received through CU (505) to DU #2 (520) via an SCell configuration setup request message. Upon receiving MRDC / NR / LTE UE capability information from DU #1 (510), DU #2 (520) may configure a cell that matches the capability information.

[0302] In operation (1117), DU #1 (510) may transmit a UE context setup response message (UE CONTEXT SETUP RESPONSE) to CU (505). DU #1 (510) may obtain SCell configuration from DU #2 (520) after performing SCell configuration setup procedure. DU #1 (510) may input the SCell configuration into the 'CellGroupConfig' IE of the UE context setup response message and then transmit a UE context setup response message including the input result to CU (505).

[0303] DU #1 (510) can determine a CA band combination and feature set that can maximize performance based on the CA capability information of the UE and the CA capability information of the DU. DU #1 (510) can perform an SCell configuration setup procedure with DU #2 (520), and then input the values ​​of 'Selected BandCombinationIndex' and 'Selected FeatureSetEntryIndex' of the UE context setup response message based on the selected CA band combination and feature set. DU #1 (510) can transmit the UE context setup response message to the CU (505). For example, the UE context setup response message can include the following information.

[0304] - SRB / DRB Setup List

[0305] - SRB / DRB Failed to be Setup List

[0306] - SCell Failed To Setup List (SCell ID, Cause)

[0307] - DU To CU RRC Information (CellGroupConfig, Selected BandCombinationIndex, Selected FeatureSetEntryIndex)

[0308] For the SCell of DU #2 (520) received in the 'SCell To Be Setup List' from CU (505), if the corresponding cell is difficult to configure for inter-DU CA or setup is not allowed, information about the cell may be included in the UE context setup response message. For example, the UE context setup response message may include 'SCell Failed To Setup List' information. The 'SCell Failed To Setup List' information may include information about the 'failed SCell ID' of the corresponding cell and the failed cause for each cell. DU #1 (510) may transmit the UE context setup response message including the information about the cell to CU (505).

[0309] When DU #1 (510) sends a UE context setup response message to CU (505), it may wait for reconfiguration until it receives an indicator indicating that reconfiguration is complete.

[0310] Although not shown in FIG. 11, if DU #1 (510) cannot support a UE context setup request received from CU (505), it may transmit a UE context setup failure message to CU (505). The UE context setup failure message may include cause information for the failure of the UE context setup request message. For example, if DU #1 (510) identifies difficulty in acceptance for a specific SRB / DRB through a setup procedure with DU #2 (520), it may include the corresponding failed SRB / DRB information in the 'SRB / DRB Failed to be Setup List' of the UE context setup response message. DU #1 (510) may transmit the UE context setup response message to CU (505).

[0311] In operation (1121), an X1-U CA bearer path can be established between DU #1 (510) and DU #2 (520). When DU #1 (510) and DU #2 (520) each receive transmission information (e.g., X1-U Source IP address, X1-U Target IP address) through the SCell configuration procedure, DU #1 (510) can transmit a path setup and CA signal packet for CA signaling to DU #2 (520) through the X1-U interface, or receive it from DU #2 (520).

[0312] In operation (1123), DU #1 (510) and CU (505) may perform an RRC reconfiguration procedure. The RRC reconfiguration procedure may be performed based on a UE context setup procedure initiated by CU (505). CU (505) may generate an RRC reconfiguration message. CU (505) may transmit a DL forwarding message including the RRC reconfiguration message to DU #1 (510). DU #1 (510) may transmit the RRC reconfiguration message to terminal (120) (e.g., UE). Through the RRC reconfiguration message, parameters for inter-DU CA of terminal (120) may be reconfigured. The parameters may include at least some of RRC layer parameters, PDCP layer parameters, RLC layer MAC layer parameters, and / or PHY layer parameters. Terminal (120) may transmit a reconfiguration complete message to CU (505). CU (505) may receive an RRC reconfiguration complete message from terminal (120). In response to the RRC reconfiguration complete message, CU (505) may transmit an indicator (e.g., 'RRC Reconfiguration Complete Indicator' IE) indicating completion of RRC reconfiguration to DU #1 (510). When DU #1 (510) receives the indicator indicating completion of RRC reconfiguration from CU (505), it may apply configuration according to SCell setup procedure. If necessary, SCell configuration modification procedure may be performed for RRC configuration for SCell of DU #1 (510) or RRC configuration for SCell of DU #2 (520).

[0313] In operation (1125), DU #1 (510) may transmit an RRC reconfiguration complete message to DU #2 (520). After receiving the RRC reconfiguration complete message, DU #2 (520) may perform CA between the terminal (120) and the DU. DU #2 (520) may identify that the changed RRC configuration is applied to the terminal (120) according to the SCell configuration setup procedure of DU #1 (510). If necessary, an SCell configuration modification procedure may be performed for the RRC configuration for the SCell of DU #1 (510) or the RRC configuration for the SCell of DU #2 (520).

[0314] FIG. 12 illustrates signal flows for an SCell configuration modification procedure initiated by a central unit (CU) according to embodiments of the present disclosure. CU (505) and DU #1 (510) may be connected via an F1 interface. DU #1 (510) and DU #2 (520) may be connected via an X1 interface. For example, DU #1 (510) is a DU that provides PCell and may be a PCell DU. DU #2 (520) is a DU that provides only SCell and may be an SCell DU.

[0315] Referring to FIG. 12, DU #1 (510) may provide one or more first cells. For example, the one or more first cells may include cell #X and cell #Y. DU #2 (520) may provide one or more second cells. For example, the one or more second cells may include cell #A and cell #B.

[0316] In operation (1201), DU #1 (510) and DU #2 (520) can perform a DU group setup procedure. For the DU group setup procedure, at least one of the procedures described through FIGS. 7A to 9 can be performed. Hereinafter, a situation in which DU #1 (510) and DU #2 (520) are set as a DU group for inter-DU CA is described.

[0317] In operation (1211), CU (505) may transmit UE context modification request message to DU #1 (510). If new configuration for signaling radio bearer (SRB) / data radio bearer (DRB) is required, CU (505) may include configuration information for SRB / DRB in 'SRB / DRB to Be Setup List' IE. DU #1 (510) may receive 'SRB / DRB to Be Setup List' IE. DU #1 (510) may perform setup for SRB / DRB through SCell configuration setup procedure or SCell configuration modification procedure with DU (e.g., DU #2 (520)) for inter-DU CA. If a change to an SRB / DRB is required, the CU (505) can include configuration information for the SRB / DRB in the 'SRB / DRB to Be Modified List' IE. DU #1 (510) can receive the 'SRB / DRB to Be Modified List' IE. DU #1 (510) can perform a change to the SRB / DRB through a DU (e.g., DU #2 (520)) for inter-DU CA and an SCell configuration setup procedure or an SCell configuration modification procedure. If a release of an SRB / DRB is required, the CU (505) can include configuration information for the SRB / DRB in the 'SRB / DRB to Be Released List' IE. DU #1 (510) can receive the 'SRB / DRB to Be Released List' IE. DU #1 (510) can perform release for SRB / DRB through SCell configuration setup procedure or SCell configuration modification procedure with DU (e.g. DU #2 (520)) for inter-DU CA.For example, if DU #1 (510) has difficulty in accepting setup for a specific SRB / DRB through the SCell configuration setup procedure or SCell configuration modification procedure with DU #2 (520), it may include the failed SRB / DRB information in the 'SRB / DRB Failed to be Setup List' of the UE context modification response message. DU #1 (510) may transmit the UE context modification response message to the CU (505).

[0318] In the UE context modification procedure, if an addition is required for the SCell of DU #2 (520), which is a SCell-DU (for example, if a new SCell of inter-DU CA is visible to the terminal (120) through MR operation, or if a blind SCell addition is performed), the CU (505) may transmit 'SCell To Be Setup List' information including information on the SCell of DU #2 (520) to DU #1 (510). DU #1 (510) may check whether the SCell of DU #2 (520), which is received as the 'SCell To Be Setup List' through the F1 UE context modification procedure from CU (505), is a SCell of a DU that has been set up as a DU group for inter-DU CA in advance. DU #1 (510) may perform a setup procedure for the SCell for inter-DU CA with DU #2 (520), which is a target DU.

[0319] In the UE context modification procedure, if a release is required for the SCell of DU #2 (520), which is a SCell-DU (for example, if a new SCell of inter-DU CA has a weak signal at the terminal (120) through MR operation), the CU (505) may transmit 'SCell To Be Removed List' information including information on the SCell of DU #2 (520) to DU #1 (510). DU #1 (510) may check whether the SCell of DU #2 (520), which is received as the 'SCell To Be Removed List' through the F1 UE context modification procedure from CU (505), is a SCell of a DU that has been previously set as a DU group for inter-DU CA. DU #1 (510) may perform a release procedure for the SCell for inter-DU CA with DU #2 (520), which is a target DU.

[0320] For example, a UE context modification request message may include the following information:

[0321] - SRB / DRB to Be Setup List

[0322] - DRB to Be Modified List

[0323] - SRB / DRB To Be Released List

[0324] - SCell To Be Setup List

[0325] - SCell To Be Removed List

[0326] In operation (1213), DU #1 (510) may transmit an SCell configuration modification request message to DU #2 (520). For example, DU #1 (510) may initiate an SCell configuration modification procedure when a configuration change is required for a terminal while inter-DU CA is in operation. The description of FIG. 10b may be referenced for the SCell configuration modification request message. When DU #1 (510) receives a UE context modification request message from CU (505), it may perform modifications to SRBs / DRBs through an SCell configuration modification procedure with a DU (e.g., DU #2 (520)) that is the target of inter-DU CA. DU #1 (510) may perform modifications to SRBs / DRBs through an SCell configuration modification procedure with DU #2 (520) that is the target of inter-DU CA.

[0327] In operation (1215), DU #2 (520) may send an SCell configuration modification response message to DU #1 (510). The description of FIG. 10b may be referenced for the SCell configuration modification response message.

[0328] According to one embodiment, DU #1 (510) may recognize the band, bandwidth, SCS, TTD ratio, Slice ID, PLMN, and DSS cell information (e.g., whether Symmetric / Asymmetric DSS) of cells of a DU group previously received through a DU context management procedure (e.g., the DU group modification procedure of FIGS. 7A to 9). DU #1 (510) may select one or more SCells within a valid cell. If the selected cell is located in another DU (e.g., DU #2 (520)), DU #1 (510) may transmit an SCell configuration modification request message to the other DU. The SCell configuration modification request message may include 'Selected SCell List' information. The 'Selected SCell List' information may include information about the selected SCell(s). DU #2 (520) may receive the 'Selected PSCell ID' and the 'Selected SCell List' through the SCell configuration modification request message. DU #2 (520) can select a valid SCell from DU #2 (520). DU #2 (520) can transmit a SCell configuration modification response message including SCell configuration information for the selected SCell to DU #1 (510). If an invalid SCell is included among one or more SCells in the 'Selected SCell List' of DU #2 (520), DU #2 (520) can generate a SCell configuration modification response message including a 'Failed SCell list' and cause information for the failure. DU #2 (520) can transmit the SCell configuration modification response message to DU #1 (510). DU #1 (510) can receive the 'Failed SCell list'.DU #1 (510) may transmit a message containing information about failed SCells to CU (505) based on the 'Failed SCell list'. For example, DU #1 (510) may transmit a message containing the 'Failed SCell list' and information about the cause of the failure to CU (505).

[0329] According to one embodiment, DU #1 (510) may transmit bearer information (e.g., QCI / 5QI ID, PDCP / RLC / MAC configuration) to DU #2 (520) through an SCell configuration modification request message based on the SRB / DRB Setup List received from CU (505). When DU #2 (520) receives the bearer information (QCI / 5QI ID, PDCP / RLC / MAC configuration) through the SCell configuration modification request from DU #1 (510), it may generate a DRB that matches the corresponding settings.

[0330] According to one embodiment, DU #1 (510) may recognize the band, bandwidth, SCS, TTD ratio, Slice ID, PLMN, and DSS cell information (e.g., whether Symmetric / Asymmetric DSS) of cells in a DU group through a DU context management procedure (e.g., the DU group modification procedure of FIGS. 7A to 9). DU #1 (510) may determine the selected band combination and feature set information. DU #1 (510) may transmit an SCell configuration modification request message including the determined band combination and feature set information to DU #2 (520). When DU #2 (520) receives the band combination and feature set information from DU #1 (510) through the SCell configuration modification request, it may configure an RLC layer, a MAC layer, and a cell within the corresponding band combination and feature set.

[0331] According to one embodiment, DU #1 (510) may transmit information about MRDC / NR / LTE UE capabilities received through CU (505) to DU #2 (520) via an SCell configuration modification request message. Upon receiving MRDC / NR / LTE UE capability information from DU #1 (510), DU #2 (520) may configure a cell that matches the capability information.

[0332] In operation (1217), DU #1 (510) may transmit a UE context modification response message (UE CONTEXT SETUP RESPONSE) to CU (505). DU #1 (510) may obtain SCell configuration from DU #2 (520) after performing SCell configuration setup procedure. DU #1 (510) may input the SCell configuration into the 'CellGroupConfig' IE of the UE context setup response message and then transmit a UE context setup response message including the input result to CU (505).

[0333] DU #1 (510) can determine a CA band combination and feature set that can maximize performance based on the CA capability information of the UE and the CA capability information of the DU. DU #1 (510) can perform an SCell configuration modification procedure with DU #2 (520), and then input the values ​​of 'Selected BandCombinationIndex' and 'Selected FeatureSetEntryIndex' of the UE context modification response message based on the selected CA band combination and feature set. DU #1 (510) can transmit the UE context modification response message to the CU (505). For example, the UE context modification response message can include the following information.

[0334] - SRB / DRB Setup List

[0335] - SRB / DRB Modified List

[0336] - SRB / DRB Failed to be Setup List

[0337] - SCell Failed To Setup List (SCell ID, Cause)

[0338] - DU To CU RRC Information (CellGroupConfig, Selected BandCombinationIndex, Selected FeatureSetEntryIndex)

[0339] For the SCell of DU #2 (520) received in the 'SCell To Be Setup List' from CU (505), if the corresponding cell is difficult to configure for inter-DU CA or setup is not allowed, information about the cell may be included in the UE context modification response message. For example, the UE context modification response message may include 'SCell Failed To Setup List' information. The 'SCell Failed To Setup List' information may include information about the 'failed SCell ID' of the corresponding cell and the failed cause for each cell. DU #1 (510) may transmit the UE context modification response message including the information about the cell to CU (505).

[0340] When DU #1 (510) sends a UE context modification response message to CU (505), it may wait for reconfiguration until it receives an indicator indicating completion of reconfiguration.

[0341] Although not shown in FIG. 12, if DU #1 (510) cannot support a UE context modification request received from CU (505), it may transmit a UE context modification failure message to CU (505). The UE context modification failure message may include cause information for the failure of the UE context modification request message. For example, if DU #1 (510) identifies difficulty in acceptance for a specific SRB / DRB through a modification procedure with DU #2 (520), it may include the corresponding failed SRB / DRB information in the 'SRB / DRB Failed to be Setup List' of the UE context modification response message. DU #1 (510) may transmit the UE context modification response message to CU (505).

[0342] In operation (1223), DU #1 (510) and CU (505) may perform an RRC reconfiguration procedure. The RRC reconfiguration procedure may be performed based on a UE context modification procedure initiated by CU (505). CU (505) may generate an RRC reconfiguration message. CU (505) may transmit a DL forwarding message including the RRC reconfiguration message to DU #1 (510). DU #1 (510) may transmit the RRC reconfiguration message to terminal (120) (e.g., UE). Through the RRC reconfiguration message, parameters for inter-DU CA of terminal (120) may be reconfigured. The parameters may include at least some of RRC layer parameters, PDCP layer parameters, RLC layer MAC layer parameters, and / or PHY layer parameters. Terminal (120) may transmit a reconfiguration complete message to CU (505). CU (505) may receive an RRC reconfiguration complete message from terminal (120). In response to the RRC reconfiguration complete message, CU (505) may transmit an indicator (e.g., 'RRC Reconfiguration Complete Indicator' IE) indicating completion of RRC reconfiguration to DU #1 (510). When DU #1 (510) receives the indicator indicating completion of RRC reconfiguration from CU (505), it may apply a configuration according to the SCell modification procedure. If necessary, the SCell configuration modification procedure may be performed for RRC configuration of the SCell of DU #1 (510) or for RRC configuration of the SCell of DU #2 (520).

[0343] In operation (1225), DU #1 (510) may transmit an RRC reconfiguration complete message to DU #2 (520). After receiving the RRC reconfiguration complete message, DU #2 (520) may perform CA between the terminal (120) and the DU. DU #2 (520) may identify that the changed RRC configuration is applied to the terminal (120) according to the SCell configuration modification procedure of DU #1 (510). If necessary, an SCell configuration modification procedure may be performed for the RRC configuration for the SCell of DU #1 (510) or the RRC configuration for the SCell of DU #2 (520).

[0344] FIG. 13 illustrates signal flows for an SCell configuration modification procedure initiated by a PCell (primary cell)-DU according to embodiments of the present disclosure. CU (505) and DU #1 (510) may be connected via an F1 interface. DU #1 (510) and DU #2 (520) may be connected via an X1 interface. For example, DU #1 (510) is a DU that provides a PCell and may be a PCell DU. DU #2 (520) is a DU that provides only an SCell and may be an SCell DU.

[0345] Referring to FIG. 13, DU #1 (510) may provide one or more first cells. For example, the one or more first cells may include cell #X and cell #Y. DU #2 (520) may provide one or more second cells. For example, the one or more second cells may include cell #A and cell #B.

[0346] In operation (1301), DU #1 (510) and DU #2 (520) can perform a DU group setup procedure. For the DU group setup procedure, at least one of the procedures described through FIGS. 7A to 9 can be performed. Hereinafter, a situation in which DU #1 (510) and DU #2 (520) are set as a DU group for inter-DU CA is described.

[0347] In operation (1311), DU #1 (510) may transmit a SCell configuration modification request message to DU #2 (520). For example, DU #1 (510) may initiate an SCell configuration modification procedure for a terminal when a configuration change is required while inter-DU CA is in operation. The description of FIG. 10b may be referenced for the SCell configuration modification request message.

[0348] In operation (1313), a SCell configuration modification response message may be transmitted to DU #1 (510). The description of FIG. 10b may be referred to for the SCell configuration modification response message. For example, DU #2 (520) may receive changed 'Transport information' (X1-U Source / Target IP address) through an SCell configuration modification request procedure from DU #1 (510). DU #2 (520) may apply the changed value. For example, DU #2 (520) may receive changed 'Selected PScell ​​ID' and 'Selected SCell List' through an SCell configuration modification request procedure. DU #2 (520) must select a valid SCell. DU #2 (520) may transmit information about the selected SCell (e.g., SCell configuration information: which may include RLC / MAC / PHY related parameters) to DU #1 (510). DU #2 (520) can send a SCell configuration modification response message including information about the selected SCell to DU #1 (510). If the 'Selected SCell List' is an invalid SCell, DU #2 (520) can send a SCell configuration modification response message including a 'Failed SCell list' and a 'Fail cause' to DU #1 (510).

[0349] According to one embodiment, DU #1 (510) may transmit bearer information (e.g., QCI / 5QI ID, PDCP / RLC / MAC configuration) to DU #2 (520) via an SCell configuration modification request message. When DU #2 (520) receives the bearer information (QCI / 5QI ID, PDCP / RLC / MAC configuration) from DU #1 (510) via the SCell configuration modification request, it may generate a DRB corresponding to the corresponding settings.

[0350] According to one embodiment, DU #1 (510) may transmit information about MRDC / NR / LTE UE capabilities to DU #2 (520) via an SCell configuration modification request message. Upon receiving the MRDC / NR / LTE UE capability information from DU #1 (510), DU #2 (520) may set parameters and cells for each layer (e.g., RLC, MAC, PHY) that correspond within the capability information.

[0351] According to one embodiment, DU #1 (510) may recognize the band, bandwidth, SCS, TTD ratio, Slice ID, PLMN, and DSS cell information (e.g., whether Symmetric / Asymmetric DSS) of cells in a DU group through a DU context management procedure (e.g., the DU group setup procedure of FIGS. 7A to 9). DU #1 (510) may determine the selected band combination and feature set information. DU #1 (510) may transmit an SCell configuration modification request message including the determined band combination and feature set information to DU #2 (520). When DU #2 (520) receives the band combination and feature set information from DU #1 (510) through the SCell configuration modification request, it may set parameters for each layer (e.g., RLC, MAC, PHY) within the corresponding band combination and feature set.

[0352] In operation (1321), DU #1 (510) may transmit a UE context modification request message to CU (505). If RRC reconfiguration is required for SCell of DU #1 (510) or SCell of DU #2 (520) through UE context modification request procedure, DU #1 (510) may include information to be reconfigured in DU To CU RRC Information ('CellGroupConfig' IE of TS 38.331) in a message (e.g., UE context modification request message). DU #1 (510) may transmit the above message to CU (505). For example, if DU #1 (510) receives 'Failed SCell list' and 'Cause' from DU #2 (520), DU #1 (510) can transmit a UE context modification request message including 'Failed SCell list' and 'Cause' to CU (505).

[0353] In operation (1323), CU (505) may transmit a UE context modification confirmation message to DU #1 (510). CU (505) may receive a UE context modification request message from DU #1 (510). In response to the UE context modification request message, CU (505) may transmit a UE context modification confirmation message. For example, the UE context modification confirmation message may include 'DRB Modified List' information.

[0354] When DU #1 (510) receives a UE context modification confirmation message from CU (505), it may wait for the reconfiguration until it receives an indicator indicating that the reconfiguration is complete. Although not shown in FIG. 13, when CU (505) cannot support the UE context modification request message received from DU #1 (510), it may transmit a UE context modification reject message to CU (505). The UE context modification reject message may include cause information.

[0355] In operation (1331), DU #1 (510) and CU (505) may perform an RRC reconfiguration procedure. The RRC reconfiguration procedure may be performed based on a UE context modification request procedure initiated by DU #1 (510). CU (505) may generate an RRC reconfiguration message. CU (505) may transmit a DL forwarding message including the RRC reconfiguration message to DU #1 (510). DU #1 (510) may transmit the RRC reconfiguration message to terminal (120) (e.g., UE). Through the RRC reconfiguration message, parameters for inter-DU CA of terminal (120) may be reconfigured. The parameters may include at least some of RRC layer parameters, PDCP layer parameters, RLC layer MAC layer parameters, and / or PHY layer parameters. Terminal (120) may transmit a reconfiguration complete message to CU (505). CU (505) may receive an RRC reconfiguration complete message from terminal (120). In response to the RRC reconfiguration complete message, CU (505) may transmit an indicator (e.g., 'RRC Reconfiguration Complete Indicator' IE) indicating completion of RRC reconfiguration to DU #1 (510). When DU #1 (510) receives the indicator indicating completion of RRC reconfiguration from CU (505), it may apply a configuration according to the SCell configuration modification procedure. If necessary, the SCell configuration modification procedure may be performed for the RRC configuration for the SCell of DU #1 (510) or the RRC configuration for the SCell of DU #2 (520).

[0356] In operation (1341), DU #1 (510) may transmit an RRC reconfiguration complete message to DU #2 (520). After receiving the RRC reconfiguration complete message, DU #2 (520) may perform CA between the terminal (120) and the DU. DU #2 (520) may identify that the changed RRC configuration is applied to the terminal (120) according to the SCell configuration modification procedure. If necessary, an SCell configuration modification procedure may be performed for the RRC configuration of the SCell of DU #1 (510) or the RRC configuration of the SCell of DU #2 (520). If the RRC reconfiguration procedure between the terminal and the network is triggered due to the SCell configuration modification procedure, DU #2 (520) may start CA between the DUs based on the changed settings after receiving the RRC reconfiguration complete message (e.g., 'Reconfiguration Complete Indicator').

[0357] FIG. 14 illustrates signal flows for an SCell configuration modification procedure initiated by an SCell-DU according to embodiments of the present disclosure. CU (505) and DU #1 (510) may be connected via an F1 interface. DU #1 (510) and DU #2 (520) may be connected via an X1 interface. For example, DU #1 (510) is a DU that provides a PCell and may be a PCell DU. DU #2 (520) is a DU that provides only an SCell and may be an SCell DU.

[0358] Referring to FIG. 14, DU #1 (510) may provide one or more first cells. For example, the one or more first cells may include cell #X and cell #Y. DU #2 (520) may provide one or more second cells. For example, the one or more second cells may include cell #A and cell #B.

[0359] In operation (1401), DU #1 (510) and DU #2 (520) can perform a DU group setup procedure. For the DU group setup procedure, at least one of the procedures described through FIGS. 7A to 9 can be performed. Hereinafter, a situation in which DU #1 (510) and DU #2 (520) are set as a DU group for inter-DU CA is described.

[0360] In operation (1411), DU #2 (520) may transmit an SCell configuration modification request message to DU #1 (510). For the SCell configuration modification request message, FIG. 10c may be referenced. For example, DU #1 (510) may receive changed 'Transport information' (X1-U Source / Target IP address) through the SCell configuration modification request procedure from DU #2 (520). DU #1 (510) may apply the changed value.

[0361] In operation (1413), DU #1 (510) may transmit an SCell configuration modification confirmation message to DU #2 (520). For the SCell configuration modification confirmation message, reference may be made to FIG. 10c.

[0362] In operation (1421), DU #1 (510) may transmit a UE context modification request message to CU (505). If RRC reconfiguration is required for the SCell of DU #1 (510) or the SCell of DU #2 (520) through the UE context modification request procedure, DU #1 (510) may include information to be reconfigured in a message (e.g., UE context modification request message) in DU To CU RRC Information (CellGroupConfig). DU #1 (510) may transmit the above message to CU (505).

[0363] In operation (1423), CU (505) may transmit a UE context modification confirmation message to DU #1 (510). CU (505) may receive a UE context modification request message from DU #1 (510). In response to the UE context modification request message, CU (505) may transmit a UE context modification confirmation message. For example, the UE context modification confirmation message may include 'DRB Modified List' information.

[0364] When DU #1 (510) receives a UE context modification confirmation message from CU (505), it may wait for reconfiguration until it receives an indicator indicating that reconfiguration is complete. Although not shown in FIG. 14, when CU (505) cannot support the UE context modification request message received from DU #1 (510), it may transmit a UE context modification reject message to CU (505). The UE context modification reject message may include cause information.

[0365] In operation (1431), DU #1 (510) and CU (505) may perform an RRC reconfiguration procedure. The RRC reconfiguration procedure may be performed based on a UE context modification request procedure initiated by DU #1 (510). CU (505) may generate an RRC reconfiguration message. CU (505) may transmit a DL forwarding message including the RRC reconfiguration message to DU #1 (510). DU #1 (510) may transmit the RRC reconfiguration message to terminal (120) (e.g., UE). Through the RRC reconfiguration message, parameters for inter-DU CA of terminal (120) may be reconfigured. The parameters may include at least some of RRC layer parameters, PDCP layer parameters, RLC layer MAC layer parameters, and / or PHY layer parameters. Terminal (120) may transmit a reconfiguration complete message to CU (505). CU (505) may receive an RRC reconfiguration complete message from terminal (120). In response to the RRC reconfiguration complete message, CU (505) may transmit an indicator (e.g., 'RRC Reconfiguration Complete Indicator' IE) indicating completion of RRC reconfiguration to DU #1 (510). When DU #1 (510) receives the indicator indicating completion of RRC reconfiguration from CU (505), it may apply a configuration according to the SCell configuration modification request procedure. If necessary, the SCell configuration modification procedure may be performed for the RRC configuration for the SCell of DU #1 (510) or the RRC configuration for the SCell of DU #2 (520).

[0366] In operation (1441), DU #1 (510) may transmit an RRC reconfiguration complete message to DU #2 (520). After receiving the RRC reconfiguration complete message, DU #2 (520) may perform CA between the terminal (120) and the DU. DU #2 (520) may identify that the changed RRC configuration is applied to the terminal (120) according to the SCell configuration modification request procedure. If necessary, an SCell configuration modification procedure may be performed for the RRC configuration for the SCell of DU #1 (510) or the RRC configuration for the SCell of DU #2 (520).

[0367] FIG. 15 illustrates an example of a user plane for spectrum aggregation between DUs according to embodiments of the present disclosure. In FIG. 15, L2 protocols and protocol-specific functions for CA between DUs are described.

[0368] Referring to FIG. 15, DU #1 (510) may be a PCell DU. DU #1 (510) may include a MAC processing module (612), an RLC-H processing module (613a), and an RLC-L processing module (613b). The MAC processing module (612) may be configured to process functions of MAC (422) and MAC (472). The RLC-H processing module (613a) and the RLC-L processing module (613b) may be configured to process functions of RLC (424) and RLC (474). Among the functions of RLC (424) and RLC (474), 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). DU #2 (520) may be an SCell DU. DU #2 (520) may include a MAC processing module (622) and an RLC-L processing module (623b).

[0369] The RLC-H processing module (613a) can receive DL PDCP PDUs from the upper PDCP protocol or transmit UL PDCP PDUs. The RLC-H processing module (613a) can perform the following RLC sub-functions among the RLC functions.

[0370] - SN numbering

[0371] - Headering

[0372] - Reassemble

[0373] - ARQ

[0374] - Re-segmentation

[0375] The RLC-L processing module (613b) and the RLC-L processing module (623b) can transmit DL RLC PDUs or receive UL RLC PDUs from lower MAC protocols. The RLC-L processing module (613b) and the RLC-L processing module (623b) can perform the following RLC functions among the RLC functions.

[0376] - Segmentation.

[0377] The MAC processing module (612) and the MAC processing module (622) can perform the existing MAC function in conjunction with each upper RLC-L processing module.

[0378] The RLC-H processing module (613a) and the RLC-L processing module (613b) can transmit and receive DL RLC PDUs and / or UL RLC PDUs through the X1-U interface. The RLC-H processing module (613a) and the RLC-L processing module (623b) can transmit and receive flow control signals through the X1-U interface (852) for distribution of DL RLC PDUs between the RLC-H processing module (613a) and the RLC-L processing module (613b). The MAC processing module (612) and the MAC processing module (623b) can transmit and receive MAC control signals required to support CA operations such as HARQ operations through the X1-U interface (852).

[0379] DL PDU processing behavior

[0380] When the RLC-H processing module (613a) receives a DL PDCP PDU, it can perform RLC SN numbering and RLC Headering. Thereafter, the RLC-H processing module (613a) can perform distribution to each of DU #1 (510) and DU #2 (520). The RLC-H processing module (613a) can distribute and deliver the RLC PDU to each of the RLC-H processing module (613a) and the RLC-L processing module (613b).

[0381] The RLC-L processing module (613b) can receive an RLC PDU from the RLC-H processing module (613a). The RLC-L processing module (613b) can obtain transport block size information (TB Size info) from the MAC processing module (612), which is each lower layer. The RLC-L processing module (613b) transmits the RLC PDU to the MAC processing module (612) when the size of the current RLC PDU is smaller than the transport block size, and can perform segmentation based on the transport block size when the size of the current RLC PDU is greater than or equal to the transport block size. Additional parameters can be used for the above-described segmentation. An update can be performed on the segmentation information (SI) of the RLC header depending on whether it is a complete SDU or a first / last / middle segment. Segment offset (SO) can point to the current segment location.

[0382] UL PDU processing operation

[0383] When the RLC-L processing module (613b) and the LC-L processing module (623b) receive a UL RLC PDU from a lower MAC, they can forward the received UL RLC PDU to the RLC-H processing module (613a). The RLC-H processing module (613a) can receive UL RLC PDUs from the RLC-L processing module (613b) and the LC-L processing module (623b), respectively. The RLC-H processing module (613a) can perform reassembly when the received UL RLC PDU is segmented. The RLC-H processing module (613a) can transmit the reassembled RLC PDU or the received RLC PDU to a node in charge of the upper PDCP (e.g., CU (505)).

[0384] ARQ processing operation

[0385] The RLC-H processing module (613a) can receive a status report for a DL PDCP PDU from the terminal. If retransmission is required due to a NACK, the DL PDCP PDU can be retransmitted. If the retransmission packet is a segment PDU, the RLC-H processing module (613a) can use the segment PDU. The RLC-H processing module (613a) can transmit a status report for a UL PDCP PDU to the terminal and receive a retransmission packet from the terminal.

[0386] In one embodiment, messages provided on the user plane between DU #1 (510) and DU #2 (520) may have various formats. The following formats may be used to exchange data, such as RLC PDUs, between DUs configured with inter-DU CA.

[0387]

[0388]

[0389] Unlike the previous method of configuring CAs of multiple cells within a single DU, the present disclosure provides CAs between different DUs, thereby not only increasing the capacity of the DU for the operator but also enabling more efficient CA operation.

[0390] Fig. 16 illustrates a configuration of an electronic device according to embodiments of the present disclosure. The structure illustrated in Fig. 16 can be understood as a configuration of a device having at least one function among the PCell-DU, SCell-DU, or CU described above. Terms such as “… unit”, “… unit”, etc. 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.

[0391] Referring to FIG. 16, the electronic device may include a transceiver (1610), a memory (1620), and a processor (1630).

[0392] The transceiver (1610) provides an interface for communicating with other devices within a network. That is, the transceiver (1610) 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 (1610) can transmit or receive signals. Accordingly, the transceiver (1610) 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 (1610) enables the electronic device to communicate with other electronic devices or systems via a backhaul connection (e.g., a wired backhaul or wireless backhaul) or via a network. The transceiver (1610) may include one or more transceivers.

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

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

[0395] In embodiments, a method performed by a first distributed unit (DU) is provided. The method may include transmitting a setup request message to a second DU through a communication interface between the first DU and the second DU. The method may include receiving a setup response message from the second DU. The setup request message may include at least one of identification information associated with the first DU or cell information for each cell provided by the first DU. The setup response message may include at least one of identification information associated with the second DU or address information associated with the second DU.

[0396] For example, the setup request message may include at least one of information indicating whether the first DU supports a CA (carrier aggregation) function between DUs or information indicating whether the first DU supports a DC (dual connectivity) function. The setup response message may include at least one of information indicating whether the second DU supports a CA (carrier aggregation) function between DUs or information indicating whether the second DU supports a DC (dual connectivity) function.

[0397] For example, the method may include an operation of transmitting a modification request message to the second DU through the communication interface. The method may include an operation of receiving a modification response message from the second DU. The modification request message may include at least one of identification information related to the first DU, identification information related to the first DU, address information related to the first DU, version information of the first DU, cell information for each cell provided by the first DU, information indicating whether the first DU supports a DU-to-DU CA function, or information indicating whether the first DU supports a DC function. The above modification response message may include at least one of identification information related to the second DU, address information related to the second DU, version information of the second DU, cell information for each cell provided by the second DU, information indicating whether the second DU supports a CA function between DUs, or information indicating whether the second DU supports a DC function.

[0398] For example, the method may include receiving a user equipment (UE) context modification request message from a central unit (CU). The method may include transmitting a UE context modification response message to the CU. The UE context modification request message may include information about one or more secondary cells (SCells). If the one or more SCells include a cell provided by the second DU, the setup request message or the modification request message may be generated based on the context modification request message.

[0399] For example, the method may include an operation of transmitting a SCell configuration setup request message to the second DU through the communication interface. The method may include an operation of receiving a SCell configuration setup response message from the second DU through the communication interface. The first DU may provide a PCell (primary cell) in the CA between the DUs. The second DU may provide an SCell in the CA between the DUs.

[0400] For example, the SCell configuration setup request message may include information about the PCell and information about one or more candidate SCells. The SCell configuration setup request message may include configuration information of each SCell of at least one SCell among the one or more candidate SCells. The configuration information may include at least one of a parameter of at least one radio link control (RLC) layer, a parameter of at least one medium access control (MAC) layer, and / or a parameter of at least one physical (PHY) layer in the corresponding cell.

[0401] For example, the method may include an operation of transmitting a SCell configuration modification request message to the second DU through the communication interface. The method may include an operation of receiving a SCell configuration modification response message from the second DU through the communication interface. The first DU may provide a PCell (primary cell) in the CA between the DUs. The second DU may provide an SCell in the CA between the DUs.

[0402] For example, the SCell configuration modification request message may include at least one of address information, bearer information, band combination and feature set, cell-radio network temporary identity (C-RNTI) information, and DC-related capability information. The SCell configuration modification response message may include address information and configuration information for each modified SCell. The configuration information may include at least one of a parameter of at least one radio link control (RLC) layer, a parameter of at least one medium access control (MAC) layer, and / or a parameter of at least one physical (PHY) layer in the corresponding cell.

[0403] For example, the SCell configuration modification response message may include information about the SCell for which the SCell configuration modification failed and information about the cause of the failure.

[0404] For example, the method may include receiving a SCell configuration modification request message from the second DU through the communication interface. The method may include transmitting a SCell configuration confirmation message to the second DU through the communication interface. The first DU may provide a PCell (primary cell) in the CA between the DUs. The second DU may provide an SCell in the CA between the DUs.

[0405] For example, the method may include an operation of transmitting a SCell configuration release request message to the second DU through the communication interface. The method may include an operation of receiving a SCell configuration release completion message from the second DU through the communication interface. The SCell configuration release request message may include information about a cause of release of the SCell configuration for the second DU. The first DU may provide a PCell (primary cell) in the CA between the DUs. The second DU may provide an SCell in the CA between the DUs.

[0406] For example, the setup request message may include dynamic spectrum sharing (DSS) information indicating whether the center frequency and bandwidth of the long term evolution (LTE) cell in the first DU are identical to the center frequency and bandwidth of the new radio (NR) cell, respectively. The setup response message may include DSS information indicating whether the center frequency and bandwidth of the LTE cell in the second DU are identical to the center frequency and bandwidth of the NR cell, respectively.

[0407] For example, the setup request message may include cell status information indicating whether each cell provided by the second DU is activated or deactivated. The setup response message may include cell status information indicating whether each cell provided by the second DU is activated or deactivated.

[0408] In embodiments, an electronic device of a first distributed unit (DU) is provided. The electronic device may include at least one processor and a memory storing instructions. The instructions, when executed by the at least one processor, may cause the electronic device to transmit a setup request message to a second DU through a communication interface between the first DU and the second DU, and to receive a setup response message from the second DU. The setup request message may include at least one of identification information associated with the first DU or cell information for each cell provided by the first DU. The setup response message may include at least one of identification information associated with the second DU or cell information for each cell provided by the second DU.

[0409] According to embodiments, an electronic device of a first distributed unit (DU) is provided. The electronic device may include a memory, at least one transceiver, and at least one processor coupled to the memory and the at least one transceiver. The at least one processor may be configured to transmit a setup request message to a second DU through a communication interface between the first DU and the second DU. The at least one processor may be configured to receive a setup response message from the second DU. The setup request message may include at least one of identification information associated with the first DU or cell information for each cell provided by the first DU. The setup response message may include at least one of identification information associated with the second DU or cell information for each cell provided by the second DU.

[0410] The above instructions, when executed by the at least one processor, may cause the electronic device to perform the corresponding operation. In other words, the at least one processor may be configured to perform the corresponding operation.

[0411] For example, the at least one processor may be configured to receive a user equipment (UE) context modification request message from a central unit (CU) and transmit a UE context modification response message to the CU. The UE context modification request message may include information about one or more secondary cells (SCells). If the one or more SCells include a cell provided by the second DU, the setup request message or the modification request message may be generated based on the context modification request message.

[0412] For example, the at least one processor may be configured to transmit a SCell configuration setup request message to the second DU through the communication interface, and to receive a SCell configuration setup response message from the second DU through the communication interface. The first DU may provide a PCell (primary cell) in the inter-DU CA. The second DU may provide an SCell in the inter-DU CA.

[0413] For example, the SCell configuration setup request message may include information about the PCell and information about one or more candidate SCells. The SCell configuration setup request message may include configuration information of each SCell of at least one SCell among the one or more candidate SCells. The configuration information may include at least one of a parameter of at least one radio link control (RLC) layer, a parameter of at least one medium access control (MAC) layer, and / or a parameter of at least one physical (PHY) layer in the corresponding cell.

[0414] For example, the at least one processor may be configured to transmit a SCell configuration modification request message to the second DU through the communication interface, and to receive a SCell configuration modification response message from the second DU through the communication interface. The first DU may provide a PCell (primary cell) in the inter-DU CA, and the second DU may provide an SCell in the inter-DU CA.

[0415] For example, the SCell configuration modification request message may include at least one of address information, bearer information, band combination and feature set, cell-radio network temporary identity (C-RNTI) information, and DC-related capability information. The SCell configuration modification response message may include address information and configuration information for each modified SCell. The configuration information may include at least one of a parameter of at least one radio link control (RLC) layer, a parameter of at least one medium access control (MAC) layer, and / or a parameter of at least one physical (PHY) layer in the corresponding cell.

[0416] For example, the SCell configuration modification response message may include information about the SCell for which the SCell configuration modification failed and information about the cause of the failure.

[0417] For example, the at least one processor may be configured to transmit a SCell configuration modification request message to the second DU through the communication interface, and to receive a SCell configuration confirmation message from the second DU through the communication interface. The first DU may provide an SCell in the inter-DU CA. The second DU may provide a PCell (primary cell) in the inter-DU CA.

[0418] For example, the at least one processor may be configured to transmit a SCell deconfiguration request message to the second DU through the communication interface, and to receive a SCell deconfiguration completion message from the second DU through the communication interface. The SCell deconfiguration request message may include information about a cause of deconfiguration of the SCell for the second DU. The first DU may provide a PCell (primary cell) in the inter-DU CA. The second DU may provide an SCell in the inter-DU CA.

[0419] 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).

[0420] 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.

[0421] 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.

[0422] 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.

[0423] 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.

[0424] 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.

[0425] 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.

[0426] 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.

[0427] 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.

[0428] 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 the first DU (distributed unit), An operation of transmitting a setup request message to the second DU through a communication interface between the first DU and the second DU, Including an operation of receiving a setup response message from the second DU, The setup request message includes at least one of identification information related to the first DU or cell information for each cell provided by the first DU, The setup response message includes at least one of identification information related to the second DU or address information related to the second DU. method.

2. In claim 1, The setup request message includes at least one of information indicating whether the first DU supports a CA (carrier aggregation) function between DUs or information indicating whether the first DU supports a DC (dual connectivity) function. The above setup response message includes at least one of information indicating whether the 2nd DU supports the CA function between DUs or information indicating whether the 2nd DU supports the DC function. method.

3. In claim 2, An action of transmitting a modification request message to the second DU through the above communication interface, Further comprising an operation of receiving a modification response message from the second DU, The above modification request message includes at least one of identification information related to the first DU, identification information related to the first DU, address information related to the first DU, version information of the first DU, cell information for each cell provided by the first DU, information indicating whether the first DU supports a CA function between DUs, or information indicating whether the first DU supports a DC function. The above modification response message includes at least one of identification information related to the second DU, address information related to the second DU, version information of the second DU, cell information for each cell provided by the second DU, information indicating whether the second DU supports a CA function between DUs, or information indicating whether the second DU supports a DC function. method.

4. In claim 1, An action for receiving a UE (user equipment) context modification request message from a CU (central unit), Further comprising the action of sending a UE context modification response message to the CU; The above UE context modification request message includes information about one or more SCells (secondary cells), If the one or more SCells include a cell provided by the second DU, the setup request message or the modification request message is generated based on the context modification request message. method.

5. In claim 1, An operation of transmitting a SCell configuration setup request message to the second DU through the communication interface, Including an operation of receiving a SCell configuration setup response message from the second DU through the communication interface, The above first DU provides PCell (primary cell) in the CA between the DUs, The above second DU provides SCell in the CA between the DUs. method.

6. In claim 5, The above SCell configuration setup request message includes information about the PCell and information about one or more candidate SCells, The above SCell configuration setup request message is Contains configuration information of each SCell of at least one SCell among the above one or more candidate SCells, The above configuration information includes at least one of a parameter of at least one RLC (radio link control) layer, a parameter of at least one MAC (medium access control) layer, and / or a parameter of at least one PHY (physical) layer in the corresponding cell. method.

7. In claim 1, An action of transmitting a SCell configuration modification request message to the second DU through the communication interface, Including an operation of receiving a SCell configuration modification response message from the second DU through the communication interface, The above first DU provides PCell (primary cell) in the CA between the DUs, The above second DU provides SCell in the CA between the above DUs. method.

8. In claim 7, The above SCell configuration modification request message includes at least one of address information, bearer information, band combination and feature set, C-RNTI (cell-radio network temporary identity) information, and DC-related capability information. The above SCell configuration modification response message includes address information and modified SCell-specific configuration information, The above configuration information includes at least one of a parameter of at least one RLC (radio link control) layer, a parameter of at least one MAC (medium access control) layer, and / or a parameter of at least one PHY (physical) layer in the corresponding cell. Electronic devices.

9. In claim 8, The above SCell configuration modification response message further includes information about the SCells for which the SCell configuration modification failed and information about the cause of the failure. Electronic devices.

10. In claim 1, An operation of receiving a SCell configuration modification request message from the second DU through the communication interface, Including an operation of transmitting a SCell configuration confirmation message to the second DU through the communication interface, The above first DU provides PCell (primary cell) in the CA between the DUs, The above second DU provides SCell in the CA between the above DUs. method.

11. In claim 1, An operation of transmitting a SCell de-configuration request message to the second DU through the communication interface; Further comprising an operation of receiving a SCell de-configuration completion message from the second DU through the communication interface, The above SCell configuration release request message includes information about the cause of release of the SCell configuration for the second DU, The above first DU provides PCell (primary cell) in the CA between the DUs, The above second DU provides SCell in the CA between the above DUs. Electronic devices.

12. In claim 1, The above setup request message includes DSS (dynamic spectrum sharing) information indicating whether the center frequency and bandwidth of the LTE (long term evolution) cell in the first DU are the same as the center frequency and bandwidth of the NR (new radio) cell, respectively. The above setup response message includes DSS information indicating whether the center frequency and bandwidth of the LTE cell in the second DU are the same as the center frequency and bandwidth of the NR cell, respectively. Electronic devices.

13. In claim 1, The above setup request message includes cell status information to indicate whether each cell provided by the second DU is activated or deactivated, The above setup response message includes cell status information to indicate whether each cell provided by the second DU is activated or deactivated. Electronic devices.

14. In the electronic device of the first DU (distributed unit), at least one processor; and Contains memory that stores instructions, The above instructions, when executed by the at least one processor, cause the electronic device to: Transmitting a setup request message to the second DU through the communication interface between the first DU and the second DU, Causes to receive a setup response message from the second DU, The setup request message includes at least one of identification information related to the first DU or cell information for each cell provided by the first DU, The setup response message includes at least one of identification information related to the second DU or cell information for each cell provided by the second DU. Electronic devices.

15. In claim 14, wherein said at least one processor is configured to perform one of the methods of claims 2 to 14; Electronic devices.

Images