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

By introducing new communication interfaces and messaging mechanisms between distributed units, the compatibility issues of CA and DC function configurations in spectrum aggregation are resolved, improving the efficiency of the spectrum aggregation process and resource management, and enabling efficient communication between distributed units.

CN121587079APending Publication Date: 2026-02-27SAMSUNG ELECTRONICS CO LTD
View PDF 0 Cites 0 Cited by

Patent Information

Application Number
CN202480047614.7
Authority / Receiving Office
CN · China
Patent Type
Applications(China)
Current Assignee / Owner
Priority Date
2023-05-19
Filing Date
2024-03-29
Publication Date
2026-02-27

AI Technical Summary

Technical Problem

In spectrum aggregation between distributed units, existing technologies struggle to effectively configure carrier aggregation (CA) and dual connectivity (DC) functions, leading to increased signaling and resource management delays, especially due to compatibility issues arising from the lack of interfaces between DUs from different vendors.

Method used

By introducing new communication interfaces and messaging mechanisms between distribution units (DUs), including DU group establishment request and response messages, identification information, address information, version information, and CA and DC function support status, effective spectrum aggregation configuration can be achieved.

Benefits of technology

It improves the efficiency of the spectrum aggregation process, reduces signaling latency, enables more effective resource management and compatibility, and supports efficient communication between distributed units.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN121587079A_ABST
    Figure CN121587079A_ABST
Patent Text Reader

Abstract

According to an embodiment, an electronic device of a first distribution 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 send a setup request message to the second DU over 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.
Need to check novelty before this filing date? Find Prior Art

Description

Technical Field

[0001] This disclosure relates to wireless communication systems, and more specifically, to electronic devices and methods for communication between distributed units in wireless communication systems. Background Technology

[0002] To meet the increasing demand for wireless data services since the commercialization of 4G (fourth generation) communication systems, efforts have been made to develop improved 5G (fifth generation) communication systems or pre-5G communication systems. For this reason, 5G communication systems or pre-5G communication systems are referred to as beyond 4G network communication systems or post-Long Term Evolution (LTE) systems.

[0003] To achieve high data transmission rates, 5G communication systems are being considered for implementation in millimeter-wave (mmWave) bands (e.g., the 60 GHz band). To reduce radio wave propagation loss and increase transmission distance, beamforming, massive MIMO, full-dimensional MIMO (FD-MIMO), array antennas, analog beamforming, and massive MIMO technologies are discussed in 5G communication systems.

[0004] In addition, to enhance network performance, 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, mobile networks, cooperative communication, cooperative multipoint (CoMP), and interference cancellation are being developed in 5G communication systems.

[0005] In addition, advanced coding and modulation (ACM) technologies such as hybrid frequency shift keying and orthogonal amplitude modulation (FQAM) and sliding window superposition coding (SWSC) are being developed in 5G systems, as well as advanced access technologies such as filter bank multicarrier (FBMC), non-orthogonal multiple access (NOMA) and sparse code multiple access (SCMA).

[0006] With the commercialization of 5G systems and new-generation radio (NR) to meet the demand for wireless data services, high data rate services are being offered to users through 5G systems similar to 4G, and a variety of wireless communication services are expected to be available, including the Internet of Things (IoT) and services requiring high reliability for specific purposes. In the current system, which is a mix of fourth-generation and fifth-generation communication systems, various standards are defined in the application protocols of the Open Radio Access Network (O-RAN) established by operators and equipment providers for the E2 interface between E2 nodes and Near-Real-Time Radio Access Network (RAN) Intelligent Controllers (RICs).

[0007] Looking back at the development of wireless communication generations, technologies have primarily been developed for services targeted at humans, such as voice, multimedia, and data. Following the commercialization of fifth-generation (5G) communication systems, the number of connected devices is expected to explode, connecting to communication networks. Examples of objects connected to the network include vehicles, robots, drones, home appliances, displays, smart sensors installed in various infrastructures, construction machinery, and factory equipment. Mobile devices are expected to evolve into various forms, such as augmented reality glasses, virtual reality headsets, and holographic devices. In the sixth-generation (6G) era, efforts are underway to develop improved 6G communication systems to connect hundreds of billions of devices and objects and provide a wide range of services. For this purpose, 6G communication systems are being called systems that surpass 5G.

[0008] In the sixth-generation (6G) communication system, which is expected to be realized around 2030, the maximum transmission speed will be trillions (i.e., 1000 gigabits) bits per second (bps), and the wireless latency will be 100 microseconds (μsec). That is to say, compared with the 5G communication system, the transmission speed of the 6G communication system will be 50 times faster, and the wireless latency will be reduced to one-tenth.

[0009] To achieve such high data transmission speeds and ultra-low latency, 6G mobile communication systems are being considered in the terahertz band (e.g., the 95 GHz to 3 THz band). Due to more severe path loss and atmospheric absorption compared to the millimeter-wave (mmWave) band introduced in 5G, the terahertz band is expected to place greater emphasis on technologies that ensure signal reach distance (i.e., coverage). As a key technology for ensuring coverage, the development of multi-antenna transmission technologies is necessary, such as radio frequency (RF) components, antennas, new waveforms superior to orthogonal frequency division multiplexing (OFDM) in terms of coverage, beamforming, massive MIMO, full-dimensional MIMO (FD-MIMO), array antennas, and large antennas. Furthermore, to improve the coverage of terahertz band signals, new technologies such as metamaterial-based lenses and antennas, high-dimensional spatial multiplexing using orbital angular momentum (OAM), and reconfigurable smart surfaces (RIS) are being discussed.

[0010] To improve frequency efficiency and enhance system networks, 6G communication systems are developing technologies such as full-duplex technology that allows uplink and downlink to utilize the same frequency resources simultaneously; network technologies that integrate satellite and high-altitude platform stations (HAPS); innovative network architecture technologies that support mobile base stations and enable network operation optimization and automation; dynamic spectrum sharing technologies that avoid conflicts through spectrum usage prediction; AI-based communication technologies that internalize end-to-end artificial intelligence (AI) support functions and leverage AI from the design phase to achieve system optimization; and next-generation distributed computing technologies that utilize ultra-high-performance communication and computing resources (e.g., mobile edge computing (MEC), cloud, etc.) to enable services with complexity exceeding the limitations of terminal computing capabilities. Furthermore, efforts are underway to enhance connectivity between devices, further optimize networks, promote the software-defined networking of network entities, and increase the openness of wireless communication by designing new protocols to be used in 6G communication systems, implementing hardware-based security environments, developing mechanisms for secure data utilization, and developing technologies to maintain privacy.

[0011] Thanks to the research and development of 6G communication systems, the next generation of hyper-connected experiences is expected to become possible through the hyper-connectivity of 6G communication systems. This includes not only interconnection between objects but also connections between people and objects. Specifically, 6G communication systems are expected to provide 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 will be provided through 6G communication systems with enhanced security and reliability, and these services will be applied in various fields such as industry, healthcare, automotive, and home appliances.

[0012] In 6G communication systems, the RAN (Radio RAN) function is expected to be further divided into service subscribers and service providers. In service-based networks, service subscription verification processes for service subscription status will be applied to various functions.

[0013] For the purpose of aiding understanding of this disclosure, the above information is provided as related technology. No claim or determination is made regarding whether any of the above information can be used as prior art in relation to this disclosure. Summary of the Invention

[0014] According to an embodiment, a method performed by a first distribution unit (DU) is provided. The method may include sending a DU group establishment request message to a second DU via a communication interface between the first DU and a second DU. The method may include receiving a DU group establishment response message from the second DU. The DU group establishment request message may include at least one of the following: identification information associated with the first DU, address information associated with 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 carrier aggregation (CA) functionality, or information indicating whether the first DU supports dual connectivity (DC) functionality. The DU group establishment response message may include at least one of the following: identification information associated with the second DU, address information associated with 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 CA functionality between DUs, or information indicating whether the second DU supports DC functionality.

[0015] According to an embodiment, an electronic device for a first distribution 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 send a DU group establishment request message to the second DU via a communication interface between the first DU and the second DU. The at least one processor may be configured to receive a DU group establishment response message from the second DU. The DU group establishment request message may include at least one of the following: identification information associated with the first DU, address information associated with the first DU, version information of the first DU, cell information of each cell provided by the first DU, information indicating whether the first DU supports carrier aggregation (CA) functionality, or information indicating whether the first DU supports dual connectivity (DC) functionality. The DU group establishment response message may include at least one of the following: identification information associated with the second DU, address information associated with the second DU, version information of the second DU, cell information of each cell provided by the second DU, information indicating whether the second DU supports CA functionality between DUs, or information indicating whether the second DU supports DC functionality.

[0016] According to an embodiment, a non-transitory recording medium is provided. The non-transitory recording medium may include a memory storing a program including instructions. When the instructions are executed, an electronic device may be configured to perform a process for transmitting signals in an interface between DUs. When the instructions are executed, they may cause the electronic device to send a DU group establishment request message to the second DU via a communication interface between a first DU and a second DU. When these instructions are executed, they may cause the electronic device to receive a DU group establishment response message from the second DU. The DU group establishment request message may include at least one of identification information associated with the first DU, address information associated with 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 carrier aggregation (CA) functionality, or information indicating whether the first DU supports dual connectivity (DC) functionality. The DU group establishment response message may include at least one of identification information associated with the second DU, address information associated with 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 CA functionality between DUs, or information indicating whether the second DU supports DC functionality.

[0017] In one embodiment, a method performed by a first distribution unit (DU) is provided. The method may include sending an establishment request message to a second DU via a communication interface between the first DU and the second DU. The method may include receiving an establishment response message from the second DU. The establishment 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 establishment 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 this embodiment, an electronic device is provided as a first distribution unit (DU). The electronic device may include at least one processor and a memory for storing instructions. When executed by the at least one processor, the instructions cause the electronic device to send an establishment request message to the second DU via a communication interface between the first and second DUs, and to receive an establishment response message from the second DU. The establishment 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 establishment 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. Attached Figure Description

[0019] The above and other aspects, features and advantages of certain embodiments of this disclosure will become more apparent from the following description taken in conjunction with the accompanying drawings.

[0020] Figures 1a to 1bAn example of a wireless communication system according to an embodiment of the present disclosure is shown.

[0021] Figures 2a to 2c An example of a spectrum aggregation environment according to an embodiment of the present disclosure is shown.

[0022] Figure 3 Examples of resource structures in the time and frequency domains according to embodiments of this disclosure are shown.

[0023] Figure 4a A protocol stack on the control plane according to an embodiment of this disclosure is shown.

[0024] Figure 4b A protocol stack on the user plane according to an embodiment of this disclosure is shown.

[0025] Figure 5 An example of spectral aggregation between distribution units (DUs) according to embodiments of the present disclosure is shown.

[0026] Figure 6 An example of a control plane for spectral aggregation between DUs according to an embodiment of the present disclosure is shown.

[0027] Figures 7a to 7b The process for establishing a DU group according to an embodiment of this disclosure is illustrated.

[0028] Figure 7c The DU group modification process according to an embodiment of this disclosure is illustrated.

[0029] Figure 8 The DU group release process according to an embodiment of the present disclosure is illustrated.

[0030] Figure 9 A resource status reporting process according to an embodiment of the present disclosure is illustrated.

[0031] Figure 10a The process for configuring and establishing a secondary cell (SCell) according to an embodiment of this disclosure is illustrated.

[0032] Figure 10b The SCell configuration modification request process according to an embodiment of this disclosure is illustrated.

[0033] Figure 10c The process of requesting a SCell configuration modification according to an embodiment of this disclosure is illustrated.

[0034] Figure 10d The SCell configuration release process according to an embodiment of this disclosure is illustrated.

[0035] Figure 10e A SCell configuration release request process according to an embodiment of this disclosure is illustrated.

[0036] Figure 11 The signal flow established according to an embodiment of the present disclosure is illustrated.

[0037] Figure 12 The signal flow of a SCell configuration modification process initiated by a central unit (CU) according to an embodiment of the present disclosure is shown.

[0038] Figure 13 The signal flow of a SCell configuration modification process initiated by the primary cell (PCell)-DU according to an embodiment of the present disclosure is shown.

[0039] Figure 14 The signal flow of a SCell configuration modification process initiated by a SCell-DU according to an embodiment of the present disclosure is shown.

[0040] Figure 15 An example of a user plane for spectral aggregation between DUs according to an embodiment of this disclosure is shown.

[0041] Figure 16 Components of an electronic device according to an embodiment of the present disclosure are shown. Detailed Implementation

[0042] The terminology used in this disclosure is for the purpose of describing particular embodiments only and is not intended to limit the scope of other embodiments. Singular expressions may include plural expressions unless the context clearly indicates otherwise. The terms used herein, including technical or scientific terms, may have the same meaning as those commonly understood by one of ordinary skill in the art as described in this disclosure. Among the terminology used in this disclosure, terms as defined in a general dictionary may be interpreted as having the same or similar meaning as in the context of related art, and are not to be construed as having an ideal or overly formal meaning unless explicitly defined in this disclosure. In some cases, even terms defined in this disclosure should not be construed as excluding embodiments of this disclosure.

[0043] In the various embodiments of this disclosure described below, hardware methods will be described as examples. However, since the various embodiments of this disclosure include techniques using both hardware and software, software-based methods are not excluded from the various embodiments of this disclosure.

[0044] The terms used in the following description relating to signals (e.g., signals, information, messages, signaling), resources (e.g., symbols, time slots, subframes, radio frames, subcarriers, resource elements (REs), resource blocks (RBs), bandwidth portions (BWPs), timings), operational states (e.g., steps, operations, processes), data (e.g., packets, user streams, information, bits, symbols, codewords), channels, network entities, and device components are examples used for ease of explanation. Therefore, this disclosure is not limited to the terms described below, and other terms with equivalent technical meanings may be used. Furthermore, terms such as “...unit,” “...device,” “...object,” and “...structure” may refer to at least one shape structure or a unit of processing function.

[0045] Furthermore, in this disclosure, the terms "greater than" or "less than" are used to determine whether a specific condition is met, but this is merely a description of examples and does not exclude descriptions of "greater than or equal to" or "less than or equal to". A condition described as "greater than or equal to" can be replaced with "greater than", a condition described as "less than or equal to" can be replaced with "less than", and a condition described as "greater than or equal to and less than" can be replaced with "greater than and less than or equal to". Additionally, in the following, "A" to "B" refers to at least one of the elements from A (inclusive) to B (inclusive). In the following, "C" and / or "D" indicates that at least one of "C" or "D" is included, i.e., {"C", "D", and "C and D"}.

[0046] This disclosure describes various embodiments using terms used in some communication standards (e.g., 3GPP, xRAN, and ORAN), but these are merely examples for illustrative purposes. The various embodiments of this disclosure can be readily modified and applied to other communication systems.

[0047] In this disclosure, signal quality can be at least one of, for example, Reference Signal Received Power (RSRP), Beam Reference Signal Received Power (BRSRP), Reference Signal Received Quality (RSRQ), Received Signal Strength Indicator (RSSI), Signal-to-Interference-to-Noise Ratio (SINR), Carrier-to-Interference-to-Noise Ratio (CINR), Signal-to-Noise Ratio (SNR), Error Vector Magnitude (EVM), Bit Error Rate (BER), and Block Error Rate (BLER). In addition to the examples above, other terms or other metrics indicating channel quality with equivalent technical meaning may be used. Hereinafter, in this disclosure, high signal quality means a large signal quality value related to signal strength or a small signal quality value related to error rate. Higher signal quality ensures a smoother wireless communication environment. Furthermore, optimal beam can mean the beam with the highest signal quality among the beams.

[0048] Currently, considering the services that 5G mobile communication technology is intended to support, improvements and enhancements to the initial 5G mobile communication technology are being discussed, and physical layer standardization is underway for technologies such as: Vehicle-to-Everything (V2X) to assist autonomous vehicle driving decisions and enhance user convenience based on the location and status information of autonomous vehicles transmitted by vehicles; New Radio Unlicensed (NR-U) designed to make system operation compliant with various regulatory requirements in unlicensed frequency bands; technologies to reduce the power consumption of NR terminals (UE power-saving technologies); Non-Terrestrial Networks (NTN) enabling direct terminal-to-satellite communication to ensure coverage in areas where communication with terrestrial networks is unavailable; and positioning.

[0049] Furthermore, standardization is underway in the field of wireless interface architecture / protocols, such as Industrial Internet of Things (IIoT) for supporting new services through connectivity and convergence with other industries, Integrated Access and Backhaul (IAB) for providing nodes to extend network service areas by integrating support for wireless backhaul and access links, mobility enhancement technologies including conditional handover and dual active stack (DAPS) handover, and two-step random access (2-step RACH for NR) to simplify the random access process. In addition, standardization is also underway in the field of system architecture / services for 5G baseline architectures that apply Network Functions Virtualization (NFV) and Software-Defined Networking (SDN) technologies (e.g., service-based architectures, service-based interfaces), and Mobile Edge Computing (MEC) based on terminal location reception services.

[0050] When this 5G mobile communication system is commercialized, a rapidly increasing number of connected devices will be connected to the communication network. Therefore, new research is expected related to extended reality (XR) for effectively supporting AR (augmented reality), VR (virtual reality), MR (mixed reality), etc., 5G performance improvements and complexity reductions through the use of artificial intelligence (AI) and machine learning (ML), AI service support, metaverse service support, and drone communication.

[0051] Furthermore, this development of 5G mobile communication systems will serve as a foundation for developing not only new waveforms for providing coverage in the terahertz band of 6G mobile communication technology, such as full-dimensional MIMO (FD-MIMO), multi-antenna transmission technologies like array antennas and massive MIMO, metamaterial-based lenses and antennas for improving terahertz band signal coverage, high-dimensional spatial multiplexing technologies using OAM (orbital angular momentum) and RIS (reconfigurable smart surfaces), but also full-duplex technologies for improving the frequency efficiency of 6G mobile communication technology and enhancing system networks, AI-based communication technologies for system optimization by leveraging satellites and AI (artificial intelligence) from the design phase and internalizing end-to-end AI support capabilities, and next-generation distributed computing technologies for providing services at complexity levels exceeding the limitations of UE operational capabilities by utilizing ultra-high-performance communication and computing resources.

[0052] Although 4G and / or 5G environments are shown as examples, this description does not limit the scope of the communication environments described in the embodiments of this disclosure. The technical principles based on the embodiments of this disclosure can also be applied to 6G and post-6G communication technologies and network environments.

[0053] Figures 1a to 1b An example of a wireless communication system according to an embodiment of the present disclosure is shown.

[0054] refer to Figure 1a , Figure 1a The base station 110 and terminal 120 are shown as part of a wireless communication system utilizing a wireless channel; Figure 1a Only one base station is shown, but the wireless communication system may also include another base station that is the same as or similar to base station 110.

[0055] Base station 110 is network infrastructure that provides wireless access to terminal 120. Base station 110 has a coverage range defined based on the distance at which a signal can be transmitted. In addition to "base station", base station 110 may be referred to as "access point (AP)", "eNodeB (eNB)", "fifth generation node", "next generation node B (gNB)", "wireless point", "transmit / receive point (TRP)" or other terms with equivalent technical meanings.

[0056] Terminal 120, a device used by a user, communicates with base station 110 via a wireless channel. The link from base station 110 to terminal 120 is called the downlink (DL), and the link from terminal 120 to base station 110 is called the uplink (UL). Furthermore, although in Figure 1a Not shown, but terminal 120 and another terminal can communicate with each other via a wireless channel. In this case, the link between terminal 120 and the other terminal (device-to-device link (D2D)) is called a side link, and this side link can be used interchangeably with the PC5 interface. In some other embodiments, terminal 120 can operate without user intervention. According to embodiments, terminal 120, as a device performing machine-type communication (MTC), may not be carried by a user. Furthermore, according to embodiments, terminal 120 can be a narrowband (NB)-Internet of Things (IoT) device.

[0057] In addition to "terminal", terminal 120 may also be referred to as "user equipment (UE)", "customer premises equipment (CPE)", "mobile station", "user station", "remote terminal", "wireless terminal", "electronic device", "user equipment" or other terms with equivalent technical meaning.

[0058] Base station 110 can perform beamforming with terminal 120. Base station 110 and terminal 120 can transmit and receive radio signals in relatively low frequency bands (e.g., NR frequency range 1 (FR 1)). Furthermore, base station 110 and terminal 120 can transmit and receive radio signals in relatively high frequency bands (e.g., FR 2 (or FR 2-1, FR 2-2, FR 2-3) or FR 3) and millimeter-wave frequency bands (e.g., 28 GHz, 30 GHz, 38 GHz, 60 GHz). Base station 110 and terminal 120 can perform beamforming to improve channel gain. In this document, beamforming can include transmit beamforming and receive beamforming. Base station 110 and terminal 120 can provide directionality to the transmitted or received signals. To this end, base station 110 and terminal 120 can select a serving beam through a beam search or beam management process. After selecting a serving beam, subsequent communication can be performed using resources that have a QCL relationship with the resources of the transmitting serving beam.

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

[0060] refer to Figure 1b Terminal 120 can be configured in dual connectivity (DC) using a first base station 110-1 and a second base station 110-2. DC technology is a technique that improves frequency utilization efficiency by allowing a terminal to simultaneously connect to two independent heterogeneous or homogeneous wireless communication cell groups. These two wireless communication cell groups have independent radio resource control entities and use frequency resources on component carriers of cells within each cell group located in different frequency bands for signal transmission and reception. Terminal 120 connecting to two different radio resource entities (e.g., the first base station 110-1 and the second base station 110-2) to use radio resources allocated by each radio resource entity is a technique. In MR-DC, a UE (e.g., terminal 120) in a radio resource control (RRC) connected state (i.e., RRC_CONNECTED) can be configured to use radio resources provided by two independent schedulers. Each scheduler can be located in an NG-RAN node (e.g., the first base station 110-1 or the second base station 110-2). In this paper, one node is the primary node (MN) and the other is the secondary node (SN). The MN and SN are connected via a network interface, and the MN can be connected to the core network. The SN may or may not be connected to the core network.

[0061] A subcell group (MN) can provide a primary cell group (MCG). Besides MN, MN can be referred to as an M node or an M-NG-RAN node. An MCG can include one or more cells. An MCG can include a primary cell (PCell). An MCG can include multiple aggregated cells. An MCG can include a PCell and one or more secondary cells (SCells). A secondary cell group (SN) can provide a secondary cell group (SCG). Besides SN, SN can be referred to as an S node or an S-NG-RAN node. An SCG can include one or more cells. An SCG can include multiple aggregated cells. An SCG can include PCells and / or SCells, as in an MCG. A cell acting as a PCell within an SCG can be referred to as a primary / secondary cell (PSCell). A subcell group can include a PSCell and one or more SCells. In the following text, the term "Special Cell" (SpCell) can be used as a term encompassing both PCells and PSCells. A SpCell refers to the primary cell of an MCG or SCG. In other words, the SpCell of an MCG refers to a pCell, and the SpCell of an SCG refers to an SCell.

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

[0063] 1) EN-DC: In this configuration, the eNB is connected to the Evolved Packet Core (EPC), and the terminal is connected to a dual connection between the eNB acting as the MN and the gNB acting as the SN. Here, the gNB may be referred to as the en-gNB, and the en-gNB may or may not be connected to the EPC.

[0064] 2) NGEN-DC: In this configuration, the eNB connects to the 5G core (5GC), and the terminal connects to a dual-connectivity network consisting of the eNB acting as the MN and the gNB acting as the SN. Here, the eNB can be referred to as an ng-eNB.

[0065] 3) NE-DC: where the gNB is connected to the 5GC, and the terminal is connected to a dual connection between the gNB acting as the MN and the eNB acting as the SN. Here, the eNB can be referred to as the ng-eNB.

[0066] 4) NR-DC: This is a dual-connectivity configuration where the gNB is connected to the 5GC, and the terminal is connected to both the gNB acting as the MN and the gNB acting as the SN. NR-DC can be used even when the UE is connected to a single gNB and performs both the MN and SN roles and is configured with MCG and SCG.

[0067] Terminal 120 can support multiple radio (MR)-DC. Terminal 120 can connect to a first base station 110-1 and a second base station 110-2. The first base station 110-1, acting as the MN, and the second base station 110-2, acting as the SN, can connect to the terminal. DC technology can provide higher data rates in conjunction with carrier aggregation (CA) provided in each base station. The first base station 110-1 and the second base station 110-2 can respectively act as the MN and SN to send downlink traffic to terminal 120 or receive uplink traffic from terminal 120.

[0068] Figures 2a to 2c An example of a spectrum aggregation environment according to embodiments of the present disclosure is shown. Spectrum aggregation refers to a wireless communication technique that uses a frequency interval in the frequency domain together with another frequency interval different from that frequency interval. Depending on the technique used, the frequency interval may correspond to at least one of a resource block (RB), bandwidth portion (BWP), bandwidth, cell, cell group, frequency band, and / or frequency range. For example, spectrum aggregation may include CA. The bandwidth of a primary cell (PCell) and the bandwidth of a secondary cell (SCell) may be used together for data communication. For example, spectrum aggregation may include DC. The frequency domain occupied by cells of the MCG of an MN and the frequency domain occupied by cells of the SCG of an SN may be used together for communication. For example, spectrum aggregation may include CoMP. Base stations with different spectrums may be used for data communication. For example, spectrum aggregation may include multiple (M) transmit / receive points (TRPs). Resources allocated in different frequency domains may be used for data transmission.

[0069] A cell can refer to an area (or coverage area) that can be covered by a base station (e.g., a gNB) (or a DU). A cell can indicate 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 supported frequencies or the area of ​​the covered sectors. The serving cell that provides higher-layer signaling (e.g., Radio Resource Control (RRC) signaling) to the terminal can refer to one or more cells. When terminal 120 is not configured to support carrier aggregation (CA) and dual connectivity (DC), the serving cell can be a cell corresponding to a PCell. When terminal 120 is configured to support CA or DC, the serving cell can be a set of cells including a PCell and one or more SCells.

[0070] refer to Figure 2a A base station can be divided into CUs and DUs. For example, when a base station corresponds to a gNB, the CU is a logical node that hosts the base station's RRC, Serving Data Adaptation Protocol (SDAP), and Packet Data Convergence Protocol (PDCP). CUs and DUs can be connected via an F1 interface. A DU is a logical node that carries the Radio Link Control (RLC) layer, Media Access Control (MAC) layer, and Physical (PHY) layer. A DU can support one or more cells, and a cell can be supported by only one DU. The first base station 110-1 may include CU #1 205-1 and DU #1 210-1. DU #1 210-1 can provide one or more cells. The second base station 110-2 may include CU #2 205-2 and DU #2 210-2. DU #2 210-2 can provide one or more cells. For example, for DC operations, MgNB-DU can indicate a gNB-DU that acts as a master node or an en-gNB (e.g., DU # 1210-1), and SGNb-DU can indicate a gNB-DU that acts as a slave node or an en-gNB (e.g., DU #2 210-2).

[0071] refer to Figure 2bThe base station can be divided into CUs and DUs. Unlike a configuration where multiple independent base stations (e.g., first base station 110-1 and second base station 110-2) serve terminal 120, one CU and multiple DUs can serve terminal 120. For example, CU #1215 can connect to DU #1 231 and DU #2 232. CU #1 215 can connect 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 the PCell. DU #2 232 can provide a cell corresponding to the SCell. Two cells can be configured for terminal 120.

[0072] refer to Figure 2c The base station can be divided into CUs and DUs. In addition to the distributed deployment of CUs and DUs, a separate base station 242 for small cells can be deployed. For example, CU #1 215 can connect to DU #1 231 via the F1 interface. Base station 242, acting as an independent base station, can perform communication with CU #1 215. DU #1 231 can provide one or more cells. Base station 242 can provide one or more small cells. For example, for CA operation, DU #1 231 can provide a cell corresponding to the PCell. DU #2 232 can provide a cell corresponding to the SCell. Two cells can be configured for terminal 120.

[0073] The vendors of a DU (or the base station of a DU and a small cell) may differ from each other. Frequency spacing used by multiple vendors may not be compatible with each other. For example, the vendors of the first DU and the second DU may have purchased different frequency bands. The frequency domain occupied by a cell provided by the first DU may differ from the frequency domain occupied by a cell provided by the second DU. Since the second DU cannot accurately know information about the cells of the first DU, it may be difficult to configure CA between the two cells. If CA is configured for both cells, signaling is required through a CU or higher entity because there is no interface between the first and second DUs. However, the increased signaling leads to latency, and therefore effective resource management may be difficult.

[0074] In the following, embodiments of this disclosure describe a new interface and procedures and messages for configuring an interface for spectrum aggregation such as CA or DC as described above. First, refer to Figure 3 Describes resources in the physical layer.

[0075] Figure 3 Examples of resource structures in the time and frequency domains according to embodiments of this disclosure are shown. Figure 3 The basic structure of the time-frequency domain is shown, which is the radio resource domain in which data or control channels are transmitted in the downlink or uplink.

[0076] refer to Figure 3 The horizontal axis indicates the time domain, and the vertical axis indicates the frequency domain. The smallest transmission unit in the time domain is an Orthogonal Frequency Division Multiplexing (OFDM) symbol, and N symb OFDM symbols 302 are aggregated to form a time slot 306. The subframe length is defined as 1.0 ms, and the radio frame 314 length is defined as 10 ms. The smallest transmission unit in the frequency domain is a subcarrier, and the carrier bandwidth for configuring the resource grid can be N. BW Configure 304 subcarriers.

[0077] The basic unit of resources in the time-frequency domain is a resource element (hereinafter referred to as "RE")312, and can be indicated as an OFDM symbol index and a subcarrier index. A resource block can include multiple resource elements. In the LTE system, a resource block (RB) (or physical resource block, hereinafter referred to as "PRB") is defined as N in the time domain. symb A continuous OFDM symbol and N in the frequency domain SC RB A series of consecutive subcarriers. In an NR system, a resource block (RB) 308 can be defined as N in the frequency domain. SC RB A series of consecutive subcarriers 310. An RB 308 includes N on the frequency axis. SC RB 312 REs. Typically, the smallest unit of data transmission is an RB, and the number of subcarriers is N. SC RB =12. The frequency domain can include Common Resource Blocks (CRBs). Physical Resource Blocks (PRBs) can be defined within the Bandwidth Part (BWP) of the frequency domain. The number of CRBs and PRBs can be determined based on the subcarrier spacing. The data rate can be increased proportionally to the number of RBs scheduled for the terminal.

[0078] In NR systems, in the case of frequency division duplex (FDD) systems that operate by dividing the downlink and uplink by frequency, the downlink transmission bandwidth and uplink transmission bandwidth can be different. Channel bandwidth indicates the radio frequency (RF) bandwidth corresponding to the system transmission bandwidth. Table 1 shows a portion of the correspondence between system transmission bandwidth, subcarrier spacing (SCS), and channel bandwidth defined in NR systems in frequency bands below x GHz (e.g., Frequency Range (FR) 1 (310MHz to 7125MHz)). Table 2 shows a portion of the correspondence between transmission bandwidth, subcarrier spacing, and channel bandwidth defined in NR systems in frequency bands above y GHz (e.g., FR2 (24250MHz - 52600MHz) or FR2-2 (52600MHz - 71000MHz)). For example, in an NR system with a channel bandwidth of 100 MHz and a subcarrier spacing of 30 kHz, the transmission bandwidth is configured as 273 RBs. In Tables 1 and 2, N / A can be a bandwidth-subcarrier combination not supported in the NR system.

[0079] [Table 1]

[0080]

[0081] [Table 2]

[0082]

[0083] Figure 4a A protocol stack 400 on the control plane according to an embodiment of the present disclosure is shown.

[0084] refer to Figure 4a In an NR communication system, the radio protocols of the control plane of terminal 120 (e.g., UE) may include PHY 411, MAC 412, RLC 413, PDCP 414, and RRC 415. In an NR communication system, the radio protocols of the control plane of base station 110 (e.g., gNB) may include PHY 421, MAC 422, RLC 423, PDCP 424, and RRC 425.

[0085] The main functions of RRC 415 or 425 may include some of the following functions.

[0086] - Broadcast system information related to the Access Layer (AS) and Non-Access Layer (NAS)

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

[0088] The establishment, maintenance, and release of RRC connections between the UE and NG-RAN include:

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

[0090] 2) Adding, modifying, and releasing dual connections within NR or between E-UTRA and NR.

[0091] - Security features, including key management

[0092] - Establishment, configuration, maintenance, and release of signaling radio bearers (SRBs) and data radio bearers (DRBs)

[0093] Mobility features include:

[0094] 1) Switching and context passing

[0095] 2) UE cell selection and reselection control

[0096] 3) Mobility between RATs

[0097] - Quality of Service (QoS) management functions

[0098] - UE Measurement Reports and Report Control

[0099] - Detection and recovery of radio link failures

[0100] - NAS message transmission from NAS to UE and from UE to NAS

[0101] The main functions of PDCP 414 or 424 may include some of the following functions.

[0102] -Header compression and decompression: ROHC only

[0103] -Transmission of user data

[0104] - Sequential delivery of upper-layer PDUs

[0105] -Disordered delivery of upper-layer PDUs

[0106] - Reordering of PDCP PDU reception

[0107] -Repetition detection of low-level SDUs

[0108] - PDCP SDU retransmission

[0109] - Encryption and decryption

[0110] - Timer-based SDU dropping in the uplink

[0111] In the above description, the PDCP layer reordering function can refer to the function of reordering PDCP PDUs received from lower layers in order based on the PDCP sequence number (SN). The PDCP layer reordering function can include the function of delivering data to the upper layer in the reordered sequence, the function of delivering data regardless of the order, the function of recording lost PDCP PDUs in the reordered order, the function of reporting the status of lost PDCP PDUs to the sending side, and the function of requesting retransmission of lost PDCP PDUs.

[0112] The main functions of RLC 413 or 423 may include some of the following functions.

[0113] -Transmission of upper-layer PDUs

[0114] - Sequential delivery of upper-layer PDUs

[0115] -The disorder of the upper-layer PDUs is all

[0116] - Error correction via ARQ

[0117] Cascading, segmentation, and reassembly of RLC SDUs

[0118] - Resegmentation of RLC data PDUs

[0119] -RLC data PDU reordering

[0120] -Duplicate detection

[0121] -Protocol error detection

[0122] -RLC SDU discard

[0123] - RLC Reconstruction

[0124] In the above description, the ordered delivery function of the RLC layer can refer to the function of sequentially delivering RLC SDUs received from lower layers to higher layers. When an RLC SDU is segmented into multiple RLC SDUs and received, the ordered delivery function of the RLC layer can include the function of reassembling and delivering them.

[0125] The ordered delivery function of the RLC layer can include the function of reordering received RLC PDUs based on RLC sequence number (SN) or PDCP sequence number (SN), the function of recording lost RLC PDUs in reordered order, the function of reporting the status of lost RLC PDUs to the sender, and the function of requesting retransmission of lost RLC PDUs.

[0126] In the event of a lost RLC SDU, the ordered delivery function of the RLC layer can include the ability to deliver only RLC SDUs to RLC SDUs before the loss. Furthermore, if a predetermined timer has expired even though a lost RLC SDU exists, the ordered delivery function of the RLC layer can include the ability to deliver all RLC SDUs received before the predetermined timer starts to the upper layer in sequence. Additionally, if a predetermined timer has expired even though a lost RLC SDU exists, the ordered delivery function of the RLC layer can include the ability to deliver all RLC SDUs received to date to the upper layer in sequence.

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

[0128] In the case of the RLC layer receiving segment, it can receive segments stored in the buffer or to be received later, reconstruct them into a complete RLC PDU, and deliver it to the PDCP device.

[0129] The RLC layer may not include cascading functionality, and this functionality can be performed in the MAC layer or replaced by multiplexing functionality of the MAC layer.

[0130] In the above description, the out-of-order delivery function of the RLC layer can refer to the function of immediately delivering RLC SDUs received from lower layers to higher layers, regardless of order. When an RLC SDU is initially segmented into multiple RLC SDUs and received, the out-of-order delivery function of the RLC layer can include the function of reassembling and delivering it. The out-of-order delivery function of the RLC layer can include the function of storing the RLC SN or PDCP SN of received RLC PDUs, ordering them, and recording lost RLC PDUs.

[0131] The MAC 412 or 422 can connect to multiple RLC layers configured in a single terminal, and the main functionality of the MAC can include a subset of the following features.

[0132] Mapping between logical channels and transport channels

[0133] - MAC SDU multiplexing / demultiplexing

[0134] - Scheduling Information Report

[0135] - Error correction via HARQ

[0136] Priority processing between logical channels of a UE

[0137] Priority processing among UEs is performed through dynamic scheduling.

[0138] - MBMS service identifier

[0139] -Transmission format selection

[0140] -filling

[0141] PHY layer 411 or 421 can perform channel coding and modulation of higher-layer data, generate OFDM symbols and transmit them to the radio channel, or perform demodulation of OFDM symbols received through the radio channel, perform channel decoding and deliver them to the higher layers.

[0142] Figure 4b A protocol stack 450 on the user plane according to an embodiment of this disclosure is shown.

[0143] refer to Figure 4b The radio protocols of the user plane of terminal 120 (e.g., UE) may include PHY 461, MAC 462, RLC 463, PDCP 464, and SDAP 465. In the NR communication system, the radio protocols of the user plane of base station 110 (e.g., gNB) may include PHY 471, MAC 472, RLC 473, PDCP 474, and SDAP 475.

[0144] The main functions of SDAP 465 or 475 may include some of the following functions.

[0145] -Transmission of user plane data

[0146] Mapping between QoS flows and DRB in -DL and UL

[0147] - Mark QoS flow IDs in DL and UL groups

[0148] - UL SDAP PDU reflection QoS flow to DRB mapping

[0149] For the SDAP layer, terminal 120 can configure whether to use the SDAP layer header or SDAP layer functionality via Radio Resource Control (RRC) messages for each PDCP layer, bearer, or logical channel. When the SDAP header is configured, terminal 120 can instruct itself to update or reset the mapping information between uplink and downlink QoS flows and data bearers via a 1-bit indicator of Non-Access Stratum (NAS) reflecting QoS settings (NAS reflects QoS) and an 1-bit indicator of Access Stratum (AS) reflecting QoS settings (AS reflects QoS) in the SDAP header. The SDAP header may include QoS flow ID information indicating QoS. QoS information can be used for data processing priority, scheduling information, etc., to support smooth service.

[0150] For PDCP 464 or 474 in the user plane, refer to the description of PDCP 414 or 424 in the control plane. For RLC 463 or 473 in the user plane, refer to the description of RLC 413 or 423 in the control plane. For MAC 462 or 472 in the user plane, refer to the description of MAC 412 or 422 in the control plane. For PHY 461 or 471 in the user plane, refer to the description of PHY 411 or 421 in the control plane.

[0151] Although radio protocols for NR communication systems in radio access networks have been described by way of example, embodiments of this disclosure are not limited thereto. For example, also in LTE communication systems, DUs (e.g., eNB-DUs) can be defined, and in this case, SDAP 465 or 475 can be omitted. Since embodiments of this disclosure provide procedures applicable to interfaces between DUs for spectrum aggregation or between DUs and base stations (e.g., eNB / gNB) in 4G, 5G, and / or 6G systems, therefore, in addition to… Figure 4b In addition to the communication protocol, various types of layers or protocols can be used.

[0152] As the number of network entities increases with advancements in communication technology, and as communication with external nodes (e.g., base stations, other DUs) via a CU results in latency, it is necessary to define interfaces between DUs or between a DU and a base station. Below, for spectrum aggregation, such as CA as described above, a new interface and the procedures and messages for configuring this interface are proposed. The procedures and messages related to the interface between DUs are described below; however, it goes without saying that the same or similar methods can also be applied to the interface between a DU and an independent base station (e.g., a base station in a small cell). In this disclosure, when describing the interface between DUs, the DUs can be from the same vendor or different vendors. That is, information exchange can be performed between DUs from different vendors through the interfaces and messages described below.

[0153] Figure 5 An example of spectral aggregation between distribution units (DUs) according to embodiments of the present disclosure is shown.

[0154] refer to Figure 5 The communication network may include a radio access network 500 and a core network 560. A node providing the radio access network 500 (e.g., base station 110) can provide communication services to user equipment (e.g., terminal 120) through one or more cells. The core network 560 may include various entities to smoothly perform the communication services. For example, the core network 560 may include an entity responsible for access management functions (AMF). For example, the core network 560 may include an entity responsible for user plane functions (UPF). The core network 560 can be implemented through the radio access network 500 and an NG interface. The NG interface may include an NG-C interface for the control plane and an NG-U interface for the user plane. The NG-C interface may be defined between the node providing the radio access network 500 and the AMF. The NG-U interface may be defined between the node providing the radio access network 500 and the UPF.

[0155] The nodes providing the radio access network 500 can be deployed in a distributed manner based on a central unit (CU) 505 configured to perform upper-layer (e.g., PDCP or RRC) functions of the access network and a distribution unit (DU) configured to perform lower-layer (e.g., RLC, MAC, or PHY) functions. The interface between the CU 505 and the DU can be referred to as an F1 interface. The F1 interface can include an F1-C interface for the control plane and an F1-U interface for the user plane. The CU 505 can connect to one or more DUs. For example, the CU 505 can connect to DU #1 510, DU #2 520, ..., and DU #n 550. Each DU can provide one or more cells. For example, DU #1 510 can provide cells #1 511 and #2 512. DU #2 520 can provide cells #1 521 and #2 522. DU #n 550 can provide cells #1 551 and #2 552.

[0156] In carrier aggregation (CA), two or more cells can be aggregated. A cell can have component carriers (CCs). Terminal 120 can simultaneously receive or transmit signals through one or more CCs, depending on its capabilities. When CA is configured, terminal 120 may have only one RRC connection to the network. During RRC connection establishment / re-establishment / handover, a serving cell provides NAS mobility information, and during RRC connection re-establishment / handover, a serving cell can provide security input. The serving cell can be referred to as the primary cell (PCell). Depending on the UE capabilities of terminal 120, secondary cells (SCells) can be configured to form a serving cell set with the PCell. The serving cell set configured for terminal 120 can always be configured with one PCell and one or more SCells. For example, cell #1 511 of DU#1 510 and cell #1 521 of DU#2 520 can be configured as the serving cell set of terminal 120. Furthermore, for example, cells #1 511 of DU #1 510, cells #1 521 of DU #2 520, and cells #1 551 of DU #n 550 can be configured as the serving cell set of terminal 120. Additionally, for example, cells #2 512 of DU #1 510 and cells #1 551 of DU #n 550 can be configured as the serving cell set of terminal 120.

[0157] RRC can perform SCell reconfiguration, addition, and deletion. During handover in NR and during connection recovery from RRC_INACTIVE, the network can also add, remove, maintain, or reconfigure SCells for use with a target PCell. When a new SCell is added, dedicated RRC signaling can be used to send all basic system information for the SCell.

[0158] In embodiments of this disclosure, the CA of terminal 120 can be configured using multiple DUs. Depending on the network environment and operator availability, operators can deploy DUs across multiple sites or from multiple vendors. To support inter-DU CA even when DUs are not from the same vendor or are not at the same site, interfaces between DUs can be defined. Hereinafter, the interface between DUs is referred to as the X1 interface, but this interface can be alternatively referred to by another term with the same technical meaning (e.g., M1, F3, MV, or XD). In the control plane, the interface between DUs can be referred to as the X1-C interface 581. In the user plane, the interface between DUs can be referred to as the X1-U interface 582. The X1-C interface 581 can be used to share call control information between DUs and for the establishment process. The X1-U interface 582 can be used for bearer transmission between DU CAs, signaling and information sharing between MAC layers.

[0159] Figure 6 An example of a control plane for spectral aggregation between DUs according to an embodiment of the present disclosure is shown.

[0160] refer to Figure 6 The CU 505 can perform the functions of RRC 615 and PDCP 614. The CU 505 can be connected to DU #1 510 via an F1 interface. The F1 interface may include an F1-C interface 681 for the control plane and an F1-U interface 682 for the user plane.

[0161] DU #1 510 and DU #2 510 can be connected to each other via an X1 interface. The X1 interface may include an X1-C interface 581 for the control plane and an X1-U interface 582 for the user plane. DU #1 510 may be a node providing a CA (Call of Action) on a PCell. 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. MAC processing module 612 can be configured to handle the functions of MAC 422 and MAC 472. RLC-H processing module 613a and RLC-L processing module 613b can be configured to handle the 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) can be handled by RLC-L processing module 613b, while other functions requiring non-real-time processing can be handled by RLC-H processing module 613a. Call processing block 671 can be configured to process parameters received from CU 505 (e.g., RRC IE) or parameters received from DU #2 520.

[0162] DU #2 520 can be a node providing a CA (Cell Controller). DU #2 520 may include a MAC processing module 622, an RLC-L processing module 623b, and a call processing block 672. MAC processing module 622 can be configured to handle the functions of MAC 422 and MAC 472. RLC-L processing module 623b can be configured to handle at least a portion of the functions of RLC 424 and RLC 474. Call processing block 672 can be configured to process parameters received from DU #1 520. Although in Figure 6 Not shown, but according to an embodiment, DU #2 520 may 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 IE) received from CU 505.

[0163] To configure inter-DU CA according to embodiments of this disclosure, various parameters can be provided through the interface between DUs. At least some of the parameters can be received from CU 505, or can be generated within the DU.

[0164] According to an embodiment, the parameters of the identification information can be provided through the interface between DUs. For example, the cell identifier (ID), DU ID, and gNB ID, which are unique information of the base station, can be used to identify a specific cell, DU, or gNB, respectively. For example, when connecting IPs between DUs, fixed internal IP addressing can be used instead of public IPs. Fixed internal IPs can be used to prevent IP conflicts. Alternatively, when setting fixed user-defined route (UDR) port numbers, a unique key can be used. For ease of ID management, the node ID value can be used as a unique key in a specific area. For example, site ID information (which is a unique key during inter-region DU CA) can be used to distinguish between intra-site and inter-site CA operations.

[0165] According to an embodiment, address information parameters can be provided through the interface between DUs. For CA communication between DUs, the source DU can set its own source X1-C IP address, and the IP address of another DU can also be set as the destination X1-C IP address. For CA signaling and bearer communication between DUs, the source DU can set its own source X1-U IP address. The source DU can also set the destination X1-U IP address for the IP address of another DU.

[0166] According to the embodiment, function-related parameters can be provided through the interface between DUs. When sending CA signaling packets via X1-C interface 581 or CA bearer packets via X1-U interface 582, Differentiated Service Point (DSCP) settings can be supported to ensure priority. When sending CA signaling packets via X1-C interface 581 or CA bearer packets via X1-U interface 582, Virtual Local Area Network (VLAN) ID settings can be supported for path determination.

[0167] According to an embodiment, a timer (e.g., a retry timer) can be defined for cases where DU group creation fails or is released. When the timer expires, the DU can attempt to create the DU group again. (See reference...) Figure 7b and Figure 8 Describe the procedures related to timers.

[0168] The parameters mentioned above can be defined as shown in the table below.

[0169] [Table 3]

[0170]

[0171] Furthermore, the parameters described above are exemplary, and this table is not intended to limit the interpretation of the embodiments of this disclosure regarding the CA between DUs. For example, some parameters may not be used in the interface between DUs. For example, these parameters may be internally set in the DU. For example, these parameters may have fixed values.

[0172] Figures 7a to 7b A DU group establishment process according to an embodiment of the present disclosure is illustrated. The DU group establishment process is a process for sharing and initially establishing necessary information between DUs for inter-DU CA (Communication as a Specific Component).

[0173] refer to Figure 7a In operation 701, DU #1 510 can send an X1 DU group establishment request message to DU #2 520. According to an embodiment, DU #1 510 can send an X1 DU group establishment request message to DU #2 520 when specific information is set. For example, the specific information may be a value indicating the CA between DUs (e.g., an inter-DU CA enable flag). For example, the specific information may include information about the other DU (e.g., a target IP address). For example, the specific information may include a DSCP or a VLAN ID. According to an embodiment, upon receiving a specific message, DU #1 510 can send an X1 DU group establishment request message to DU #2 520. For example, this message may include... Figure 7b The X1 DU group establishes a rejection message or Figure 8The DU group creation and release message. When a specific time has elapsed after receiving a specific message, DU #1 510 can send an X1 DU group creation request message.

[0174] DU #1 510 can provide DU #2 520 with attribute information of DU #1 510. For example, an X1 DU group creation request message may include at least one of the following parameters.

[0175] - DUSW Version: Indicates the software version of DU #1 510.

[0176] - CA / DC Function On / Off Information (Inter-DU CA On / Off Flag, EN-DC Use Flag, NR-DC Use Flag, SA Use Flag): Indicates whether a specific function (e.g., CA function and / or DC function) is activated in DU #1 510. Flags can be used to indicate the corresponding function. For example, during the addition of a SCell for CA between DUs, DUs where the CA function is deactivated can be excluded from the selection target. For example, during the addition of an SN, when a SCell in the SN is selected, DUs where the DC function is deactivated can be excluded from the selection target.

[0177] -Transmission information (source RLC IP address information for inter-DU CA, source MAC IP address information for inter-DU CA)

[0178] ID information: Site ID, gNB ID, DU ID, Node ID, Cell ID: indicating the area 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.

[0179] Serving Cell Information: Frequency Band, Bandwidth, Subcarrier Spacing (SCS), TDD Ratio, Slice ID, PLMN, Symmetric / Asymmetric DSS: The TDD ratio indicates the ratio of UL resources to DL resources in a TDD cell. For example, during the addition of a SCell to a CA between DUs, a SCell with the same TDD ratio as 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, during the addition of a SCell to a CA between DUs, a SCell of a network slice that supports the Slice ID of the PCell can be selected. A Symmetric DSS indicates a cell where the center frequency / bandwidth of the LTE cell is the same as that of the NR cell; an Asymmetric DSS indicates a cell whose DSS is not symmetric.

[0180] - Cell status information (normal / disabled)

[0181] In operation 703, DU #2 520 can send an X1 DU group establishment response message to DU #1 510. Upon successfully receiving an X1 DU group establishment request message from DU #1 510, DU #2 520 can respond to that X1 DU group establishment request message by sending an X1 DU group establishment response message.

[0182] DU #2 520 can identify whether packets are compatible between DU #1 510 and DU #2 520 to determine if the X1 DU group establishment request message has been successfully received. For example, DU #2 520 can identify packet compatibility by the software version of DU #1 510. DU #2 520 can check whether the configuration information for DU #1 510 has been entered correctly. For example, DU #2 520 can check whether the configuration information for DU #1 510 has been entered correctly via the IP address information for DU #1 510 and / or whether the CA function is 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 the CA configuration between the DUs and DU #2 520. DU #2 520 can then continue the DU group establishment process for configuring the CA between the DUs.

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

[0184] - DUSW Version: Indicates the software version of DU #2 520.

[0185] - CA / DC Function On / Off Information (Inter-DU CA On / Off Flag, EN-DC Use Flag, NR-DC Use Flag, SA Use Flag): Indicates whether a specific function (e.g., CA function and / or DC function) is activated in DU #2 520. Flags can be used to indicate the corresponding function. For example, during the addition of a CA SCell between DUs, DUs where the CA function is deactivated can be excluded from the selection target. For example, during the addition of an SN, when a SCell in the SN is selected, DUs where the DC function is deactivated can be excluded from the selection target.

[0186] -Transmission information (source RLC IP address information for inter-DU CA, source MAC IP address information for inter-DU CA)

[0187] ID information: Site ID, gNB ID, DU ID, Node ID, Cell ID: Indicates the area 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.

[0188] Serving Cell Information: Frequency Band, Bandwidth, Subcarrier Spacing (SCS), TDD Ratio, Slice ID, PLMN, Symmetric / Asymmetric DSS: The TDD ratio indicates the ratio of UL resources to DL resources in a TDD cell. For example, during the addition of a SCell to a CA between DUs, a SCell with the same TDD ratio as 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, during the addition of a SCell to a CA between DUs, a SCell of a network slice that supports the Slice ID of the PCell can be selected. A Symmetric DSS indicates a cell where the center frequency / bandwidth of the LTE cell is the same as that of the NR cell; an Asymmetric DSS indicates a cell whose DSS is not symmetric.

[0189] - Cell status information (normal / disabled)

[0190] although Figure 7a This describes the scenarios where the DU group creation request message has been successfully processed; however, the DU group creation request message may not have been successfully processed. The following text will refer to... Figure 7b Describe the process in which the DU group creation request message is not successfully processed.

[0191] refer to Figure 7b In operation 751, DU #1 510 can send an X1 DU group establishment request message to DU #2 520. For operation 751, please refer to the description of operation 701.

[0192] In operation 753, DU #2 520 can send an X1 DU group setup rejection 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 can determine to reject the X1 DU group setup request message. As another example, if the address information provided by DU #1 510 is different from the address information identified in DU #2 520, DU #2 520 can determine to reject the X1 DU group setup request message. As yet another example, if the function requested by DU #1 510 is not supported by DU #2 520, DU #2 520 can determine to reject the X1 DU group setup request message. For example, the X1 DU group setup rejection message may include reason information. The reason information may indicate the reason for the rejection. For example, the reason information may indicate software version incompatibility (“SW version incompatibility”). For example, the cause information can indicate a configuration mismatch (“configuration mismatch”) between DU #1 510 and DU #2 520.

[0193] After the specified time 754 has elapsed, in operation 755, DU #1 510 can send the X1 DU group establishment request message back to DU #2 520. For example, the length of the specified time 754 can be a fixed value. Alternatively, the length of the specified time 754 can be set according to DU #2 510. For example, a timer corresponding to the length of the specified time 754 can be set through a message from DU #2 520 (e.g., a DU group establishment rejection message).

[0194] At the same time, with Figure 7b In a different embodiment, DU #1 510, which receives an X1 DU group establishment rejection message, may not retry the DU group establishment. For example, if the reason information indicates "SW version incompatibility," DU #1 510 may not retry the DU group establishment. After being upgraded to a software group version compatible with DU #2 520, DU #1 510 may wait until it receives an X1 DU group establishment request message from DU #2 520.

[0195] In passing Figures 7a to 7b During the DU group establishment process described, parameters related to version information, identification information, address information, and specific functions can be shared between DUs (e.g., DU #1 510 and DU #2 520). By sharing this information, it can be determined whether to perform a CA (Confirmation and Response) between DUs. In the following, for ease of description, DU group establishment may be referred to as "establishment". As an example, a DU establishment request message may be referred to as an establishment request message, and a DU establishment response message may be referred to as an establishment response message.

[0196] According to embodiments, whether CA between DUs is performed can be determined by whether the function is activated. For example, suppose that NR-CA is performed in EN-DC, NR-DC, or SA by checking the on / off state of the shared and EN-DC use flag, NR-DC use flag, and SA use flag. DU #1 510 can support CA in DC, DC, and SA. When the corresponding flag of DU #2 520 (e.g., DC use flag, NR-DC use flag, or SA use flag) is on, DU #1 510 can perform inter-DU CA between DUs. When the corresponding flag of DU #2 520 is off, DU #1 510 may not perform inter-DU CA between DUs. For example, when adding a SCell to an EN-DC UE, if the EN-DC use flag of DU #2 520 is indicated as off, DU #1 510 may not perform CA between DUs and DU #2 520.

[0197] When a CA is executed between DUs, DU #1 510 can establish an X1-U connection with DU #2 520 during UE context management procedures by sharing IP addresses for CA bearers and signaling for each DU. Furthermore, DU #1 510 can send packets to and receive packets from DU #2 520 via the CA bearer.

[0198] To configure CA between DUs, serving cell information shared between DUs can be used. By sharing the serving cell information of each DU, the frequency band, bandwidth, or SCS of the corresponding DU can be identified. During UE context management, DUs can perform frequency band combination and feature set selection based on the serving cell information of the other DU. According to an embodiment, by sharing serving cell information, DU #1 510 can obtain the 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, when performing the UE context management procedure, DU #1 510 can configure CA between DUs only for the supported TDD CA combinations. According to an embodiment, by sharing serving cell information, DU #1 510 can identify the slice ID of DU #2 520. Based on the slice ID, when performing the UE context management procedure, DU #1 510 can configure CA between DUs only for the supported network slices. According to an embodiment, by sharing serving cell information, DU #1 510 can identify the Public Land Mobile Network Selection (PLMN) of DU #2 520. Based on the PLMN, when performing the UE context management procedure, DU #1 510 can configure the CA between DUs only for supported PLMNs. According to an embodiment, DU #1 510 can identify the DSS cell information of DU #2 520 by sharing serving cell information. For example, DSS cell information can indicate whether the corresponding cell provides symmetric or asymmetric DSS. Based on the DSS cell information, when performing the UE context management procedure, DU #1 510 can configure the CA between DUs only for supported DSS cells. According to an embodiment, by sharing serving cell information, DU #1 510 can identify the cell status information (normal / disabled) of DU #2 520. Based on the cell status information, when performing the UE context management procedure, DU #1 510 can configure the CA between DUs only for cells in the normal state (i.e., cells that have not been deactivated).

[0199] Figure 7c The DU group modification process according to an embodiment of this disclosure is illustrated. (In the process of...) Figures 7a to 7b During the DU group creation process, when it is necessary to modify some information or add configurations, the DU group modification procedure can be used. This procedure can be used to modify and create necessary information between DUs.

[0200] refer to Figure 7cIn operation 771, DU #1 510 can send an X1 DU group modification request message to DU #2 520. DU #1 510 can send an X1 DU group creation request message to DU #2 520 when it is necessary to change at least one parameter set through the DU group creation procedure.

[0201] DU #1 510 can provide DU #2 520 with the attribute information required to change DU #1 510. For example, an X1 DU group modification request message may include at least one of the following parameters. For a description of each parameter, please refer to [link / reference]. Figures 7a to 7b The description.

[0202] - DU SW version, On / Off flag, EN-DC usage flag, NR-DC usage flag, SA usage flag

[0203] - Source RLC IP address information used for DU inter-CA

[0204] Source MAC IP address information used for inter-DU CA

[0205] - ID information: Site ID, gNB ID, DU ID, Node ID, Unit ID,

[0206] -Serving cell information: frequency band, bandwidth, SCS, TDD ratio, slice ID, PLMN, symmetric / asymmetric DSS

[0207] - Cell status information (normal / disabled)

[0208] In operation 773, DU #2 520 can send an X1 DU group modification response message to DU #1 510. When DU #1 510 successfully receives the X1 DU group modification request message, DU #2 520 can respond to the X1 DU group modification request message by sending an X1 DU group modification response message.

[0209] DU #2 520 can identify whether a group is compatible between DU #1 510 and DU #2 520 to determine if the X1 DU group modification request message has been successfully received. For example, DU #2 520 can identify whether the group is compatible by the software version of DU #1 510. DU #2 520 can check whether the configuration information for DU #1 510 has been entered correctly. DU #2 520 can identify whether the changes to DU #1 510 are generally acceptable to DU #2 520. When DU #2 520 determines that the changes to DU #1 510 are acceptable, it can continue the DU group modification process to configure the CA between DUs.

[0210] DU #2 520 can provide DU #1 510 with the information needed to change 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, please refer to [link / reference]. Figures 7a to 7b The description.

[0211] - DU SW version, DU-to-CA on / off flag, EN-DC usage flag, NR-DC usage flag, SA usage flag

[0212] - Source RLC IP address information, used for inter-DU CA

[0213] Source MAC IP address information of DU-CA

[0214] - ID information: Site ID, gNB ID, DU ID, Node ID, Unit ID,

[0215] -Serving cell information: frequency band, bandwidth, SCS, TDD ratio, slice ID, PLMN, symmetric / asymmetric DSS

[0216] - Battery status information (normal / disabled)

[0217] If there are no parameters that need to be changed in DU #2 520, the above parameters can be omitted from the message.

[0218] pass Figure 7c The DU group modification process allows for the sharing of version information, identification information, address information, and parameters related to specific functions that need to be changed between DUs (e.g., DU #1 510 and DU #2 520). By sharing this information, it can be determined whether to proceed. DU CA between.

[0219] According to the embodiment, whether CA between DUs is performed can be determined by whether the function is activated. For example, assume that NR-CA is performed in EN-DC, NR-DC, or SA by checking the on / off state of the shared and EN-DC use flag, NR-DC use flag, and SA use flag. DU #1 510 can support CA in DC, DC, and SA. When the corresponding flag of DU #2 520 (e.g., DC use flag, NR-DC use flag, or SA use flag) is on, DU #1 510 can perform inter-DU CA between DUs. When the change flag of DU #2 520 is off, DU #1 510 may not perform inter-DU CA between DUs. For example, when adding a SCell to an EN-DC UE, if the EN-DC use flag of DU #2 520 is off, DU #1 510 may not perform CA between DUs and DU #2 520.

[0220] When CA is performed between DUs, DU #1 510 can establish an X1-U connection with DU #2 520 during UE context management procedures by sharing IP addresses for CA bearers and signaling for each DU. Furthermore, DU #1 510 can send packets to and receive packets from DU #2 520 via the CA bearer.

[0221] To configure CA between DUs, modified serving cell information can be used. By sharing modified serving cell information, the frequency band, bandwidth, or SCS of the other DU can be identified. During UE context management, DUs can perform frequency band combination and feature set selection based on the modified serving cell information of the other DU. According to an embodiment, by sharing serving cell information, DU #1 510 can obtain the modified serving cell information of DU #2 520. DU #1 510 can identify the TDD ratio of the cell of DU #2 520. Based on the result of checking the TDD ratio, when performing the UE context management procedure, DU #1 510 can configure CA between DUs only for the supported TDD CA combinations. According to an embodiment, by sharing serving cell information, DU #1 510 can identify the modified slice ID of DU #2 520. Based on the modified slice ID, when performing the UE context management procedure, DU #1 510 can configure CA between DUs only for the supported network slices. According to an embodiment, by sharing serving cell information, DU #1 510 can identify the changed Public Land Mobile Network Selection (PLMN) of DU #2 520. Based on the changed PLMN, when performing a UE context management procedure, DU #1 510 can configure the CA between DUs only for the supported PLMNs. According to an embodiment, by sharing serving cell information, DU #1 510 can identify the changed DSS cell information of DU #2 520. For example, the changed DSS cell information can indicate whether the corresponding cell provides symmetric DSS or asymmetric DSS. Based on the changed DSS cell information, when performing a UE context management procedure, DU #1 510 can configure the CA between DUs only for the supported DSS cells. According to an embodiment, by sharing changed serving cell information, DU #1 510 can identify the changed cell status information (normal / disabled) of DU #2 520. Based on the changed cell state information, when performing the UE context management procedure, DU #1 510 can configure CA between DUs only for cells in the normal state (i.e., cells that have not been deactivated).

[0222] exist Figure 7c This disclosure only shows the case where a DU group modification request is successful, but the embodiments of this disclosure are not limited to this. Rejecting a DU group modification request may also be included in the embodiments of this disclosure. According to the embodiments, with... Figure 7cUnlike other DUs, DU #2 520 can send a DU group modification rejection message to DU #1 510 in response to a DU group modification request message. For example, DU #2 520 can reject an X1 DU group modification request message if the software version of DU #1 510 differs from the software version of DU #2 520. Similarly, DU #2 520 can reject an X1 DU group modification request message if the address information provided from DU #1 510 differs from the address information identified at DU #2 520. Furthermore, DU #2 520 can reject an X1 DU group modification request message if the changed functionality from DU #1 510 is not supported by DU #2 520. For example, an X1 DU group modification rejection message may include reason information. The reason information may indicate the reason for the rejection. For example, the reason information may indicate software version incompatibility (“SW version incompatible”). For example, the cause information could indicate a configuration mismatch (“configuration mismatch”) between DU #1 510 and DU #2 520. Subsequently, in response to the DU group modification rejection message, DU #1 510 could resend the DU group modification request message, or send it after a specific time has elapsed. Figure 8 The DU group release request message.

[0223] Figure 8 A DU group release procedure according to an embodiment of the present disclosure is illustrated. The DU group release procedure is executed via an X1 interface and can be used to release DU groups that have been set up through the DU group creation procedure.

[0224] refer to Figure 8 In operation 801, DU #1 510 can send an X1 DU group release request message to DU #2 520. The X1 DU group release request message may include reason information. The reason information may indicate the reason for the release. DU #1 510 can send the X1 DU group release request message when specified conditions are met. For example, if the "Inter-DU CA Flag" of DU #1 510 and / or DU #2 520 is closed, DU #1 510 can send the X1 DU group release request message to DU #2 520. Furthermore, for example, if DU #1 510 and / or DU #2 520 are in a closed or locked state, DU #1 510 can send the X1 DU group release request message to DU #2 520. Additionally, for example, if DU #1 510 receives a DU group modification rejection message from DU #2 520 (e.g., ... Figure 7cIn the event of a DU group modification rejection message, DU #1 510 may send an X1 DU group release request message to DU #2 520. Furthermore, for example, if the IP addresses used for CA bearer and signaling change, and it is determined that it is difficult to maintain the changed IP addresses for terminals that have already configured CAs between existing DUs, DU #1 510 may send an X1 DU group release request message to DU #2 520.

[0225] In operation 803, DU #2 520 can send an X1 DU group release response message to DU #1 510. Based on the X1 DU group release response message, DU #1 510 can recognize that the DU group with CA configuration between DUs of DU #1 510 and DU #2 520 has been released. In the case of a DU group including DU #1 510 and DU #2 520 being released, CA between DUs using both DU #1 510 and DU #2 520 may not be allowed. CU 505, DU #1 510, and / or DU #2 520 can perform a UE context management procedure with terminal 120 (e.g., UE), where CA between DUs has already been configured for terminal 120. Through the UE context management procedure, the CA configuration of terminal 120 can be changed or released.

[0226] After the specified time 804 has elapsed, in operation 805, DU #1 510 can send an X1 DU group establishment request message to DU #2 520. For example, the length of the specified time 804 can be a fixed value. Alternatively, the length of the specified time 804 can be set according to DU #2 520. For example, a timer corresponding to the length of the general specified time 804 can be set via a message from DU #2 520 (e.g., a DU group release response message). This timer can also be shared with DU #1 510 via a message (e.g., a DU group release request message).

[0227] Figure 9 A resource status reporting process according to an embodiment of this disclosure is illustrated. The resource status reporting process can be provided via an X1-X interface 581. This process can be used to share resource information required by a CA between DUs.

[0228] refer to Figure 9 In operation 901, DU #1 510 can send a resource status report message to DU #2 520. Resource status report messages can be used to provide information that needs to be updated or changed more frequently than during the DU group creation or modification process. Although... Figure 9The description describes a scenario where DU #1 510 sends a resource status report message to DU #2 520, but embodiments of this disclosure are not limited thereto. DU #2 520 may also send a resource status report message to DU #1 510. For example, a resource status report message may include information such as information elements.

[0229] - PRB usage information for each community

[0230] - Number of UEs per cell

[0231] PRB usage information for each cell and each slice

[0232] - Number of UEs per cell and per slice

[0233] According to embodiments, the resource status reporting process can be triggered based on various conditions. For example, the resource status reporting process can be executed after the initial DU group establishment process has been completed normally. Resource status reporting messages can be sent periodically or when a specific event is detected.

[0234] According to embodiments, information provided via resource status report messages can be used for band combination and SCell selection. For example, DU #1 510 can perform band combination and SCell selection based on resource status report messages received from DU #2 520. DU #1 510 can perform band combination and SCell selection with expected high throughput in the CA between DUs based on information about PRB usage and the number of UEs in DU #2 520. DU #1 510 can perform band combination and SCell selection by using information about PRB usage and the number of UEs in both DU #1 510 and DU #2 520. Furthermore, DU #1 510 can perform band combination and SCell selection with the expected high throughput for each slice in the CA between DUs based on information about PRB usage and the number of UEs for each slice of DU #2 520. DU #1510 can perform band combination and SCell selection by using information about PRB usage and UE number for each slice of DU #1 510 and information about PRB usage and UE number for each slice of DU #2 520.

[0235] Already referenced Figures 7a to 9 This describes the procedures for establishing, modifying, and releasing CAs between DUs. To configure CAs between DUs for a UE, a UE context management procedure can be performed. References will be made below. Figures 10a to 14This describes the UE context management process using the interface between DUs. When CA is performed between DUs for terminal 120, the DU providing the PCell can be called a PCell-DU, and the DU providing the SCell can be called an SCell-DU. Each DU can provide multiple cells, and multiple SCells can also be configured. For example, two or more SCells can be configured in an SCell-DU, and another cell in a PCell-DU can also operate as an SCell.

[0236] Figure 10a A secondary cell (SCell) configuration establishment process according to an embodiment of this disclosure is illustrated. The SCell configuration establishment process can be executed via X1-C interface 581. This process can be used to establish an SCell configuration in a CA between DUs.

[0237] refer to Figure 10a In operation 1001, DU #1 510 can send a SCELL configuration setup request message to DU #2 520. For example, the SCELL configuration setup request message may include the following information.

[0238] -Transmission information (X1-U source IP address): For example, indicating the IP address of DU #1 510.

[0239] - Selected SpCell ID, Selected SCell List: A special cell (SpCell) includes one pCell and / or one primary / secondary cell (PSCell). This information may include a list of SCells used for the SCell establishment request and information about the PCell (e.g., the PCell ID for DU #1 510).

[0240] - Bearer information (QCI (QoS Class Identifier) / 5QI (5G QoS Identifier) ​​ID, PDCP / RLC / MAC configuration)

[0241] - Selected BC / Feature Set Information: Band Combination and Feature Set Information. The feature set supported by each block of neighboring serving cells within a band can be called a Feature Set (FS). A two-dimensional matrix of feature sets for all bands in a band combination (i.e., all feature sets for each band) can be called a Feature Set Combination. In a Feature Set Combination, the number of feature sets for each band is equal to the number of band entries in the corresponding band combination, and all feature sets for each band can have the same number of feature sets. Each band combination can be connected to a Feature Set Combination.

[0242] - C-RNTI (Cellular Radio Network Temporary Identity) information

[0243] - MRDC (Multiple Radio Access Technologies) / NR / LTE UE Capability Information

[0244] In operation 1003, DU #2 520 can send an SCell configuration setup request message to DU #1 510. For example, the SCell configuration setup response message may include the following information.

[0245] -Transmission information (X1-U destination IP address): For example, indicating the IP address of DU #2 520.

[0246] - List of failed SCells and reasons for failure: Instructs the SCell configuration to create a list of failed SCells. This information may include details about the reasons for the failures.

[0247] - SCell Configuration

[0248] although Figure 10a Not shown, but DU #2 520 can send an SCell configuration establishment failure message (or SCell configuration establishment rejection message) to DU #1 510. If all SCell establishment requests made by DU #1 510 fail, DU #2 520 can send an SCell configuration establishment failure message to DU #1 510. The SCell configuration establishment failure message may include information about the reason for the failure. DU #1 510 may perform CA without using the SCell of DU #2 520 for the relevant terminal.

[0249] Figure 10b A SCell configuration modification request procedure according to an embodiment of this disclosure is illustrated. The SCell configuration modification request procedure can be executed via X1-C interface 581. This procedure can be used to modify the SCell configuration in a CA between DUs. Figure 10b In this context, SCell configuration modifications can be triggered by DU #1 510. For example, DU #1 510, which provides PCell, can be referred to as the PCell DU. DU #2 520, which provides only SCell, can be referred to as the SCell DU.

[0250] refer to Figure 10b In operation 1011, DU #1 510 can send 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, please refer to... Figure 10a .

[0251] -Transmission information (X1-U source IP address)

[0252] - Selected SPcell ID, Selected SCell List

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

[0254] - Selected BC / feature set information.

[0255] -RNTI Information

[0256] - MRDC / NR / LTE UE capability information

[0257] In operation 1013, DU #2 520 can send an 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, please refer to... Figure 10a .

[0258] -Transmitted information (X1-U destination IP address)

[0259] - List of failed Scells, reasons for failure

[0260] - SCell Configuration

[0261] although Figure 10b Not shown, but DU #2 520 can send an SCell configuration modification failure message to DU #1 510. If all SCell modifications requested by DU #1 510 fail, DU #2 520 can send an SCell configuration modification failure message to DU #1 510. The SCell configuration modification failure message may include information about the reason for the failure. According to an embodiment, upon receiving an SCell configuration modification failure message, DU #1 510 can perform an SCell configuration release procedure. Figure 10d This process can be used for the SCell configuration release process. For example, when it is determined that it is difficult to maintain the existing settings with the UE, DU #1 510 can send an SCell configuration release request message to DU #2 520.

[0262] Figure 10c A procedure for requesting SCell configuration modification according to an embodiment of this disclosure is illustrated. The SCell configuration modification request procedure can be executed via X1-C interface 581. This procedure can be used to modify the SCell configuration in a CA between DUs. Figure 10bUnlike DU #1 510, SCell configuration modification can be triggered first by DU #2 520. For example, DU #1 510, which provides PCell, can be called the PCell DU. DU #2 520, which only provides SCell, can be called the SCell DU.

[0263] refer to Figure 10c In operation 1021, DU #2 520 can send a SCell configuration modification request message to DU #1 510. For example, the SCell configuration modification request message may include the following information. For a description of each parameter, please refer to... Figure 10a .

[0264] -Transmitted information (X1-U destination IP address)

[0265] - List of failed Scells, reasons for failure

[0266] - SCell Configuration

[0267] In operation 1023, DU #1 510 can send 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, please refer to... Figure 10a .

[0268] -Transmission information (X1-U source IP address)

[0269] - Selected SpCell ID, Selected SCell List

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

[0271] - Selected BC / feature set information.

[0272] -RNTI Information

[0273] - MRDC / NR / LTE UE capability information

[0274] although Figure 10cNot shown, but DU #1 510 can send an SCell configuration modification rejection message to DU #2 520. If the requested SCell configuration modification by DU #2 520 is not accepted, DU #1 510 can send an SCell configuration modification rejection message to DU #2 520. The SCell configuration modification rejection message may include information about the reason for the failure. According to an embodiment, upon receiving an SCell configuration modification rejection message, DU #2 520 can execute an SCell configuration release request procedure. Figure 10e This process can be used for the SCell configuration release process. For example, when it is determined that it is difficult to maintain the existing configuration with the UE, DU #2 520 can send an SCell configuration release request message to DU #1 510.

[0275] Figure 10d A SCell configuration release procedure according to an embodiment of this disclosure is illustrated. The SCell configuration modification and release procedure can be executed via the X1-C interface 581. The SCell configuration release procedure can be used to release the SCell configuration configured for a terminal with a CA having DUs. Figure 10d In this context, the SCell configuration release process can be triggered by DU #1 510. For example, DU #1 510, which provides PCell, can be referred to as the PCell DU. DU #2 520, which provides only SCell, can be referred to as the SCell DU.

[0276] refer to Figure 10d In operation 1061, DU #1 510 can send a SCell configuration release command message to DU #2 520. For example, the SCell configuration release command message may include information about the reason for the release.

[0277] In operation 1063, DU #2 520 can send 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, please refer to... Figure 10a .

[0278] -Transmitted information (X1-U destination IP address)

[0279] - List of failed Scells, reasons for failure

[0280] - SCell Configuration

[0281] In one scenario, the SCell configuration release procedure can be triggered from a CU (e.g., CU 505). For example, CU 505 can send information (e.g., "List of SCells to be removed" IE) to DU #1 510. DU #1 510 can then send an SCell configuration release command message to DU #2 520 based on this information. The SCell configuration release command message may include reason information. DU #2 520 may be the DU that provides the SCell indicated by this information. By sending the SCell configuration release command message, SCells configured for CA between DUs can be released.

[0282] Figure 10e A SCell configuration release request procedure according to an embodiment of this disclosure is illustrated. The SCell configuration modification release request procedure can be executed via X1-C interface 581. The SCell configuration release request procedure can be used to release the SCell configuration configured for a terminal with a CA having DUs. Figure 10d Unlike DU #2, the SCell configuration release process can be triggered first by DU #2520 instead of DU #1 510. For example, DU #1 510, which provides PCell, can be called the PCell DU. DU #2 520, which provides only SCell, can be called the SCell DU.

[0283] refer to Figure 10e In operation 1071, DU #2 520 can send a SCell configuration release request message to DU #1 510. For example, the SCell configuration release request message may include information about the reason for the release request.

[0284] In operation 1073, DU #1 510 can send an SCell configuration release acknowledgment message to DU #2 520. For example, the SCell configuration release acknowledgment message may include the following information. For a description of each parameter, please refer to [link / reference needed]. Figure 10a .

[0285] -Transmitted information (X1-U destination IP address)

[0286] - List of failed Scells, reasons for failure

[0287] - SCell Configuration

[0288] In cases where it is necessary to release one or more SCells of DU #2 520 (e.g., Cell Access Control (CAC)), DU #2 520 may send an SCell configuration release request message to DU #1 510. The SCell configuration release request message may include information about the reason for the release. In response to the SCell configuration release request message, DU #1 510 may send an SCell configuration release confirmation message to DU #2 520. Thereafter, DU #1 510 may initiate a procedure to request the CU to modify the UE context. For example, DU #1 510 may send a message (e.g., a UE context modification request message) to the CU (e.g., CU 505) including information about the SCells to be released (e.g., the "List of SCells to be Removed" IE). For example, the context modification request message may include the following information.

[0289] - List of SCells to be deleted

[0290] - DU to CU RRC information (CellGroupConfig, Selected BandCombinationIndex, Selected FeatureSetEntryIndex

[0291] Figure 11 The signal flow established according to an embodiment of the present disclosure is illustrated. CU 505 and DU #1 510 can be connected to each other via an F1 interface. DU #1 510 and DU #2 520 can be connected to each other via an X1 interface. For example, DU #1 510, as a DU providing a PCell, can be a PCell DU. DU #2 520, as a DU providing only an SCell, can be an SCell DU.

[0292] refer to Figure 11 DU #1 510 can provide one or more first cells. For example, one or more first cells may include cell #X and cell #Y. DU #2 520 can provide one or more second cells. For example, one or more second cells may include cell #A and cell #B.

[0293] In operation 1101, DU #1 510 and DU #2 520 can execute the DU group creation procedure. For the DU group creation procedure, the reference can be executed. Figures 7a to 9 At least one of the processes described. In the following, the case where DU #1 510 and DU #2 520 are configured as a group of DUs for inter-DU CA will be described.

[0294] In operation 1111, CU 505 can send a UE context establishment request message to DU #1 510. During UE context establishment, CU 505 can include configuration information about the signaling radio bearer (SRB) / data radio bearer (DRB) in the list of SRBs / DRBs to be established (IE). CU 505 can send a UE context establishment request message to DU #1 510 including this IE. During UE context establishment, if it is necessary to add a SCell of DU #2 520 (i.e., SCell DU) (e.g., when a signal for a new SCell for CA between DUs is visible at terminal 120 via Measurement Report (MR) operation, or when performing a blind SCell addition), CU 505 can send a "list of SCells to be established" information to DU #1 510 that includes information about the SCell of DU #2 520. For a SCell of DU #2 520 received from CU 505 as a "SCell to be established" via the F1 UE context modification procedure, DU #1 510 can check whether the SCell is a SCell of a DU group previously set up for CA between DUs. DU #1 510 can then perform the SCell establishment procedure for CA between DUs with DU #2 520, which is the target DU.

[0295] For example, a UE context establishment request message may include the following information.

[0296] - List of SCells to be created

[0297] - List of SRBs / DRBs to be created

[0298] In operation 1113, DU #1 510 can send an SCell configuration establishment request message to DU #2 520. For example, if DU #1 is requested by the CU to perform inter-DU CA for an SCell of another DU regarding a new UE, DU #1 can initiate the SCell configuration establishment procedure. For details on the SCell configuration establishment request message, please refer to... Figure 10a The description is as follows: When a UE context establishment request message is received from CU 505, DU #1 510 can perform SRB / DRB establishment through a SCell configuration establishment procedure with a DU (e.g., DU #2 520), where the DU is the target of the CA between DUs. DU #1 510 can also perform SRB / DRB establishment through a SCell configuration establishment procedure with DU #2 520, where DU #2 520 is the target of the CA between DUs.

[0299] In operation 1115, DU #2 520 can send a SCell configuration setup response message to DU #1 510. For details on SCell configuration setup response messages, please refer to... Figure 10a The description.

[0300] According to an embodiment, DU #1 510 can recognize previous DU context management procedures (e.g., Figures 7a to 9 The DU group establishment process receives information about the frequency band, bandwidth, SCS, TDD ratio, slice ID, PLMN, and DSS cell information (e.g., whether the DSS is symmetric / asymmetric) of the cells in the DU group. DU #1 510 can select one or more SCells from the valid cells. If the selected cell is located in another DU (e.g., DU #2 520), DU #1 510 can send an SCell configuration establishment request message to that other DU. The SCell configuration establishment request message may include "selected SCell list" information. The "selected SCell list" information may include information about the selected SCell. DU #2 520 can receive "selected PSCell ID" and "selected SCell list" through the SCell configuration establishment request message. DU #2 520 can select valid SCells in DU #2 520. DU #2 520 can send an SCell configuration establishment response message to DU #1 510, which includes SCell configuration information about the selected SCell. If an invalid SCell from one or more SCells in the "Selected SCell List" is included in DU #2 520, DU #2 520 can generate a SCell configuration setup response message that includes a "List of Failed SCells" and information about the reason for the failure. DU #2 520 can send a SCell configuration setup response message to DU #1 510. DU #1 510 can receive the "List of Failed SCells". DU #1 510 can send a message to CU 505 based on the "List of Failed SCells" that includes information about the failed SCells. For example, DU #1 510 can send a message to CU 505 that includes a "List of Failed SCells" and information about the reason for the failure.

[0301] According to one embodiment, DU #1 can send bearer information (e.g., QCI / 5QI ID or PDCP / RLC / MAC configuration) to DU #2 via a SCell configuration establishment request message based on the SRB / DRB establishment list received from CU. When DU #2 receives bearer information (QCI / 5QI ID or PDCP / RLC / MAC configuration) from DU #1 via a SCell configuration establishment request, DU #2 can generate a DRB suitable for the corresponding establishment.

[0302] According to an embodiment, DU #1 510 can be managed through a DU context management process (e.g., Figures 7a to 9 The DU group establishment process identifies the frequency band, bandwidth, SCS, TTD ratio, slice ID, PLMN, and DSS cell information of the DU group's cells (e.g., whether the DSS is symmetric / asymmetric). DU #1 can determine the selected frequency band combination and feature set information. DU #1 510 can send an SCell configuration establishment request message to DU #2 520, including the determined frequency band combination and feature set information. When DU #2 520 receives the frequency band combination and feature set information from DU #1 510 via the SCell configuration establishment request, it can set up the cell in the corresponding frequency band combination and feature set.

[0303] According to one embodiment, DU #1 can determine C-RNTI information. DU #1 510 can send a SCell configuration establishment request message including the C-RNTI information to DU #2 520. When C-RNTI information is received from DU #1 510 via the SCell configuration establishment request, DU #2 520 can check for any conflict with the current operation C-RNTI corresponding to the C-RNTI. Based on the confirmation result, DU #2 520 can apply the C-RNTI information to the SCell.

[0304] According to an embodiment, DU #1 510 can send information about the MRDC / NR / LTE UE capabilities received via CU 505 to DU #2 520 via a SCell configuration setup request message. When DU #2 520 receives the MRDC / NR / LTE UE capability information from DU #1 510, it can configure the appropriate cell within the corresponding capability information.

[0305] In operation 1117, DU #1 510 can send a UE context establishment response message to CU 505. After performing the SCell configuration establishment procedure, DU #1 510 can obtain the SCell configuration from DU #2 520. DU #1 510 can input the SCell configuration into the "CellGroupConfig" IE of the UE context establishment response message, and then send the UE context establishment response message including the input results to CU 505.

[0306] DU #1 510 can determine the CA band combination and feature set whose performance can be maximized based on information about the UE's CA capabilities and the DU's CA capabilities. After performing the SCell configuration establishment procedure with DU #2, DU #1 can input the values ​​of each of "Selected Band CombinationIndex" and "Selected FeatureSetEntryIndex" in the UE context setting response message based on the selected CA band combination and feature set. DU #1 510 can send a UE context establishment response message to CU 505. For example, the UE context establishment response message may include the following information.

[0307] - SRB / DRB creation list

[0308] - SRB / DRB Failure List Creation

[0309] - SCell build failure list (SCell ID, reason)

[0310] - DU to CU RRC information (CellGroupConfig, Selected BandCombinationIndex, Selected FeatureSetEntryIndex)

[0311] For a SCell of DU #2 received from the CU as part of the "SCell to be established list", if it is difficult to configure the corresponding cell for the CA between DUs or if establishing the configuration is not allowed, information about the cell can be included in the UE context establishment response message. For example, the UE context establishment response message may include "SCell establishment failure list" information. The "SCell establishment failure list" information may include the "SCell failure ID" for the corresponding cell and the reason for failure for each cell. DU #1 510 can send a UE context establishment response message including information about the cell to CU 505.

[0312] When a UE context establishment response message is sent to CU 505, DU #1 510 can wait for reconfiguration until it receives an indicator indicating that the reconfiguration is complete.

[0313] Despite Figure 11 Not shown, but if a UE context establishment request received from the CU cannot be supported, DU #1 may send a UE context establishment failure message to the CU. The UE context establishment failure message may include information about the reason for the failure of the UE context establishment request message. For example, if a specific SRB / DRB is identified as unacceptable through the establishment process with DU #2, DU #1 may include the corresponding failed SRB / DRB information in the "SRB / DRB establishment failure list" of the UE context establishment response message. DU #1 510 may send a UE context establishment response message to CU 505.

[0314] In operation 1121, an X1-UCA bearer path can be established between DU #1 510 and DU #2 520. When each of DU #1 510 and DU #2 520 receives transport information (e.g., X1-U source IP address or X1-U destination IP address) through the SCell configuration procedure, DU #1 510 can send path setup and CA signaling packets for CA signaling to DU #2 520 via the X1-U interface, or receive path setup and CA signaling packets for CA signaling from DU #2 520.

[0315] In operation 1123, DU #1 510 and CU 505 can perform an RRC reconfiguration procedure. The RRC reconfiguration procedure can be performed based on a UE context establishment procedure initiated by CU 505. CU 505 can generate an RRC reconfiguration message. CU 505 can send a DL delivery message including the RRC reconfiguration message to DU #1 510. DU #1 510 can send the RRC reconfiguration message to terminal 120 (e.g., UE). The parameters of the CA between DUs for terminal 120 can be reconfigured via the RRC reconfiguration message. These parameters can include at least a portion of RRC layer parameters, PDCP layer parameters, RLC layer MAC layer parameters, and / or PHY layer parameters. Terminal 120 can send a reconfiguration completion message to CU 505. CU 505 can receive the RRC reconfiguration completion message from terminal 120. In response to the RRC reconfiguration completion message, CU can send an indicator indicating RRC reconfiguration completion (e.g., "RRC Reconfiguration Completion Indicator" IE) to DU #1. Upon receiving an indication from CU 505 that RRC reconfiguration is complete, DU #1 510 can apply the configuration according to the SCell setup procedure. For the RRC configuration of the SCell used for DU #1 510 or the RRC configuration of the SCell used for DU #2 520, the SCell configuration modification procedure can be performed if necessary.

[0316] In operation 1125, DU #1 510 can send an RRC reconfiguration complete message to DU #2 520. Upon receiving the RRC reconfiguration complete message, DU #2 520 can perform CA (Configuration Agreement) between the DUs and terminal 120. DU #2 520 can recognize that the RRC configuration changed according to the SCell configuration establishment procedure of DU #1 510 has been applied to terminal 120. For the RRC configuration used for the SCell of DU #1 510 or the RRC configuration used for the SCell of DU #2 520, a SCell configuration modification procedure can be performed if necessary.

[0317] Figure 12 The signal flow of a SCell configuration modification process initiated by a central unit (CU) according to an embodiment of this disclosure is illustrated. CU 505 and DU #1 510 can be connected to each other via an F1 interface. DU #1 510 and DU #2 520 can be connected to each other via an X1 interface. For example, DU #1 510, as a DU providing a PCell, can be a PCell DU. DU #2 520, as a DU providing only a SCell, can be an SCell DU.

[0318] refer to Figure 12DU #1 510 can provide one or more first cells. For example, one or more first cells may include cell #X and cell #Y. DU #2 520 can provide one or more second cells. For example, one or more second cells may include cell #A and cell #B.

[0319] In operation 1201, DU #1 510 and DU #2 520 can execute the DU group creation procedure. For the DU group creation procedure, the reference can be executed. Figures 7a to 9 At least one of the processes described. In the following, the case where DU #1 510 and DU #2 520 are configured as a group of DUs for inter-DU CA will be described.

[0320] In operation 1211, CU 505 can send a UE context modification request message to DU #1 510. When a new setting for the Signaling Radio Bearer (SRB) / Data Radio Bearer (DRB) is required, CU 505 can include configuration information about the SRB / DRB in the "SRB / DRB List to be Established" IE. DU #1 510 can receive the "SRB / DRB List to be Established" IE. DU #1 510 can perform the establishment of the CA between DUs via a SCell configuration establishment procedure or a SCell configuration modification procedure with a DU (e.g., DU #2 520). When a change to the SRB / DRB is required, CU 505 can include configuration information about the SRB / DRB in the "SRB / DRB List to be Modified" IE. DU #1 510 can receive the "SRB / DRB List to be Modified" IE. DU #1 510 can perform changes to the SRB / DRB for the CA between DUs through a SCell configuration establishment or modification procedure with DU (e.g., DU #2 520). When it is necessary to release an SRB / DRB, CU 505 can include configuration information about 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 the release of the SRB / DRB for the CA between DUs through a SCell configuration establishment or modification procedure with DU (e.g., DU #2 520). For example, if it is difficult to accept the establishment of a specific SRB / DRB with DU #2 520 through a SCell configuration establishment or modification procedure, DU #1 510 can include the corresponding failed SRB / DRB information in the "SRB / DRB Establishment Failure List" of the UE context modification response message. DU #1 510 can send a UE context modification response message to CU 505.

[0321] During UE context modification, when a request is made to add a SCell for DU #2 520 as a SCell DU (e.g., when a signal for a new SCell for CA between DUs is visible at terminal 120 via Measurement Report (MR) operation, or when performing a blind SCell addition), CU 505 may send a "List of SCells to be Created" message to DU #1 510, including information about the SCell for DU #2 520. For a SCell for DU #2 520 received from CU 505 as a "List of SCells to be Created" via the F1 UE context modification procedure, DU #1 510 may check whether the SCell is a SCell of a DU group previously set up for CA between DUs. DU #1 510 may then perform a process to create a SCell for CA between DUs with DU #2 520 as the target DU.

[0322] During UE context modification, if it is necessary to release the SCell of DU #2 520 as a SCell-DU (e.g., when the signal of a new SCell used for CA between DUs at terminal 120 via Measurement Report (MR) operation is weak), CU 505 can send a "List of SCells to be Removed" information, including information about the SCell of DU #2 520, to DU #1 510. For the SCell of DU #2 520 received from CU 505 as part of the "List of SCells to be Removed" via the F1 UE context modification procedure, DU #1 510 can check whether the SCell is a SCell of a DU previously set in the DU group used for CA between DUs. DU #1 510 can then perform the release procedure for CA between DUs with DU #2 520 as the target DU.

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

[0324] - List of SRBs / DRBs to be created

[0325] - DRB list to be modified

[0326] -List of SRBs / DRBs to be released

[0327] - List of SCells to be created

[0328] - List of SCells to be removed

[0329] In operation 1213, DU #1 510 can send an SCell configuration modification request message to DU #2 520. For example, if a configuration change is required while the CA between the DUs of the terminals is in operation, DU #1 510 can initiate the SCell configuration modification process. For details on the SCell configuration modification request message, please refer to... Figure 10b The description is as follows: When a UE context modification request message is received from CU 505, DU #1 510 can perform SRB / DRB modification through a SCell configuration modification procedure with a DU (e.g., DU #2 520), where the DU is the target of the CA between DUs. DU #1 510 can perform SRB / DRB modification through a SCell configuration modification procedure with DU #2 520, where DU #2 520 is the target of the CA between DUs.

[0330] In operation 1215, DU #2 520 can send a SCell configuration modification response message to DU #1 510. For details on SCell configuration modification response messages, please refer to... Figure 10b The description.

[0331] According to an embodiment, DU #1 510 can be managed through a DU context management process (e.g., Figures 7a to 9The DU group modification process identifies the frequency band, bandwidth, SCS, TTD ratio, slice ID, PLMN, and DSS cell information (e.g., whether the DSS is symmetric or asymmetric) of the cells in the pre-received DU group. DU #1 510 can select one or more SCells from the valid cells. If the selected cell is located in another DU (e.g., DU #2 520), DU #1 510 can send a SCell configuration modification request message to that 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. DU #2 520 can receive the "selected PSCell ID" and "selected SCell list" through the SCell configuration modification request message. DU #2 520 can select a valid SCell in DU #2 520. DU #2 520 can send a SCell configuration modification response message to DU #1 510, including SCell configuration information about the selected SCell. If an invalid SCell from one or more SCells in the "Selected SCell List" is included in DU #2 520, DU #2 520 can generate a SCell configuration modification response message that includes a "Failed SCell List" and information about the reason for the failure. DU #2 520 can send the SCell configuration modification response message to DU #1 510. DU #1 510 can receive the "Failed SCell List". DU #1 510 can send a message to CU 505 based on the "Failed SCell List" that includes information about the failed SCells. For example, DU #1 510 can send a message to CU 505 that includes a "Failed SCell List" and information about the reason for the failure.

[0332] According to an embodiment, DU #1 510 can establish a list based on the SRB / DRB received from CU 505 and send bearer information (e.g., QCI / 5QI ID or PDCP / RLC / MAC configuration) to DU #2 520 via a SCell configuration modification request message. When receiving bearer information (QCI / 5QI ID, or PDCP / RLC / MAC configuration) from DU #1 510 via a SCell configuration modification request, DU #2 520 can generate a DRB suitable for the corresponding establishment.

[0333] According to an embodiment, DU #1 510 can be managed through a DU context management process (e.g., Figures 7a to 9The DU group modification process identifies the frequency band, bandwidth, SCS, TTD ratio, slice ID, PLMN, and DSS cell information of the DU group's cells (e.g., whether the DSS is symmetric or asymmetric). DU #1 510 can determine the selected frequency band combination and feature set information. DU #1 510 can send an SCell configuration modification request message to DU #2 520, including the determined frequency band combination and feature set information. When receiving the frequency band combination and feature set information from DU #1 510 via the SCell configuration modification request, DU #2 520 can set the RLC layer, MAC layer, and cell in the corresponding frequency band combination and feature set.

[0334] According to an embodiment, DU #1 510 can send information about the MRDC / NR / LTE UE capabilities received via CU 505 to DU #2 520 via a SCell configuration modification request message. When DU #2 520 receives the MRDC / NR / LTE UE capability information from DU #1 510, it can configure the appropriate cell within the corresponding capability information.

[0335] In operation 1217, DU #1 510 can send a UE context modification response message (UE CONTEXTSETUP RESPONSE) to CU 505. After performing the SCell configuration setup procedure, DU #1 510 can obtain the SCell configuration from DU #2 520. DU #1 510 can input the SCell configuration into the "CellGroupConfig" IE of the UE context setup response message, and then send the UE context setup response message including the input results to CU 505.

[0336] DU #1 510 can determine the CA band combination and feature set whose performance can be maximized based on the UE's CA capability and the DU's CA capability information. After performing the SCell configuration modification procedure with DU #2 520, DU #1 510 can input the values ​​of each of "Selected BandCombinationIndex" and "Selected FeatureSetEntryIndex" in the UE context modification response message based on the selected CA band combination and feature set. DU #1 510 can send a UE context modification response message to CU 505. For example, the UE context modification response message may include the following information.

[0337] - SRB / DRB creation list

[0338] - SRB / DRB Modification List

[0339] - SRB / DRB Failure List Creation

[0340] - SCell build failure list (SCell ID, reason)

[0341] - DU to CU RRC information (CellGroupConfig, Selected BandCombinationIndex, Selected FeatureSetEntryIndex)

[0342] For a SCell of DU #2 520 received from CU 505 as part of the "SCell to be established list," if it is difficult to configure the corresponding cell for the CA between DUs or if establishing the configuration is not allowed, information about the cell can be included in the UE context modification response message. For example, the UE context modification response message may include "SCell establishment failure list" information. The "SCell establishment failure list" information may include the "SCell failure ID" for the corresponding cell and the reason for failure for each cell. DU #1 510 can send a UE context modification response message to CU 505 that includes information about the cell.

[0343] When a UE context modification response message is sent to CU 505, DU #1 510 can wait for reconfiguration until it receives an indicator indicating that the reconfiguration is complete.

[0344] Despite Figure 12 Although not shown in the diagram, if a UE context modification request received from CU 505 cannot be supported, DU #1 510 may send a UE context modification failure message to CU 505. The UE context modification failure message may include information about the reason for the failure of the UE context modification request message. For example, if a specific SRB / DRB is identified as unacceptable through the establishment process with DU #2, DU #1 may include the corresponding failed SRB / DRB information in the "SRB / DRB establishment failure list" of the UE context modification response message. DU #1 510 may then send a UE context modification response message to CU 505.

[0345] In operation 1223, DU #1 510 and CU 505 can perform an RRC reconfiguration procedure. The RRC reconfiguration procedure can be performed based on a UE context modification procedure initiated by CU 505. CU 505 can generate an RRC reconfiguration message. CU 505 can send a DL delivery message including the RRC reconfiguration message to DU #1 510. DU #1 510 can send the RRC reconfiguration message to terminal 120 (e.g., UE). The parameters of the CA between DUs for terminal 120 can be reconfigured via the RRC reconfiguration message. The parameters can include at least a portion of RRC layer parameters, PDCP layer parameters, RLC layer MAC layer parameters, and / or PHY layer parameters. Terminal 120 can send a reconfiguration completion message to CU 505. CU 505 can receive the RRC reconfiguration completion message from terminal 120. In response to the RRC reconfiguration completion message, CU can send an indicator indicating RRC reconfiguration completion (e.g., "RRC Reconfiguration Completion Indicator" IE) to DU #1. Upon receiving an indication from CU 505 that RRC reconfiguration is complete, DU#1 510 can apply the configuration according to the SCell modification procedure. For RRC configurations of SCells used for DU #1 510 or SCells used for DU #2 520, the SCell configuration modification procedure can be performed if necessary.

[0346] In operation 1225, DU #1 510 can send an RRC reconfiguration complete message to DU #2 520. Upon receiving the RRC reconfiguration complete message, DU #2 520 can perform CA (Configuration Execution) between the DUs and terminal 120. DU #2 520 can recognize that the RRC configuration changed according to the SCell configuration modification procedure of DU #1 510 has been applied to terminal 120. For the RRC configuration used for the SCell of DU #1 510 or the RRC configuration used for the SCell of DU #2 520, the SCell configuration modification procedure can be performed if necessary.

[0347] Figure 13 The signal flow of a SCell configuration modification process initiated by a primary cell (PCell)-DU according to an embodiment of this disclosure is illustrated. CU 505 and DU #1 510 can be connected to each other via an F1 interface. DU #1 510 and DU #2 520 can be connected to each other via an X1 interface. For example, DU #1 510, as a DU providing a PCell, can be a PCell DU. DU #2 520, as a DU providing only a SCell, can be a SCell DU.

[0348] refer to Figure 13DU #1 510 can provide one or more first cells. For example, one or more first cells may include cell #X and cell #Y. DU #2 520 can provide one or more second cells. For example, one or more second cells may include cell #A and cell #B.

[0349] In operation 1301, DU #1 510 and DU #2 520 can execute the DU group creation procedure. For the DU group creation procedure, the reference can be executed. Figures 7a to 9 At least one of the processes described. In the following, the case where DU #1 510 and DU #2 520 are configured as a group of DUs for inter-DU CA will be described.

[0350] In operation 1311, DU #1 510 can send an SCell configuration modification request message to DU #2 520. For example, if a configuration change is required while a CA between the DUs of the terminals is in operation, DU #1 510 can initiate the SCell configuration modification process. For details on the SCell configuration modification request message, please refer to... Figure 10b The description.

[0351] In operation 1313, it can send a SCell configuration modification response message to DU #1 510. For details on SCell configuration modification response messages, please refer to... Figure 10b The description is as follows. For example, DU #2 520 can receive changed "transmission information" (X1-U source / destination IP address) from DU #1 510 through the SCell configuration modification request procedure. DU #2 520 can apply the changed values. For example, DU #2 520 can receive changed "selected PScell ​​ID" and "selected SCell list" through the SCell configuration modification request procedure. DU #2 520 should select a valid SCell. DU #2 520 can send information about the selected SCell to DU #1 510 (e.g., SCell configuration information: which may include RLC / MAC / PHY related parameters). DU #2 520 can send a SCell configuration modification response message to DU #1 510 including information about the selected SCell. If the "selected SCell list" is an invalid SCell, DU #2 520 can send a SCell configuration modification response message to DU #1 510 including a "failed SCell list" and a "reason for failure".

[0352] According to an embodiment, DU #1 510 can send bearer information (e.g., QCI / 5QI ID or PDCP / RLC / MAC configuration) to DU #2 520 via a SCell configuration modification request message. When DU #2 520 receives bearer information (QCI / 5QI ID, or PDCP / RLC / MAC configuration) from DU #1 510 via a SCell configuration modification request, DU #2 520 can generate a DRB suitable for the corresponding establishment.

[0353] According to an embodiment, DU #1 510 can send information about MRDC / NR / LTE UE capabilities to DU #2 520 via a SCell configuration modification request message. When receiving MRDC / NR / LTE UE capability information from DU #1 510, DU #2 520 can set appropriate parameters and cells for each layer (e.g., RLC, MAC, or PHY) within the corresponding capability information.

[0354] According to an embodiment, DU #1 510 can be managed through a DU context management process (e.g., Figures 7a to 9 The DU group establishment process identifies the frequency band, bandwidth, SCS, TTD ratio, slice ID, PLMN, and DSS cell information of the DU group's cells (e.g., whether the DSS is symmetric or asymmetric). DU #1 510 can determine the selected frequency band combination and feature set information. DU #1 510 can send an SCell configuration modification request message to DU #2 520, including the determined frequency band combination and feature set information. When receiving the frequency band combination and feature set information from DU #1 510 via the SCell configuration modification request, DU #2 520 can set parameters and cells for each layer (e.g., RLC, MAC, PHY) in the corresponding frequency band combination and feature set.

[0355] In operation 1321, DU #1 510 may send a UE context modification request message to CU 505. When requesting RRC reconfiguration of a SCell of DU #1 510 or a SCell of DU #2 520 via the UE context modification request procedure, DU #1 510 may include information to be reconfigured in the DU-to-CU RRC information (TS 38.331's "CellGroupConfig" IE) in the message (e.g., the UE context modification request message). DU #1 510 may send this message to CU 505. For example, when DU #1 510 receives a "list of failed SCells" and a "reason" from DU #2 520, DU #1 510 may send a UE context modification request message to CU 505 including the "list of failed SCells" and the "reason".

[0356] In operation 1323, CU 505 can send a UE context modification confirmation message to DU #1 510. CU 505 can receive a UE context modification request message from DU #1 510. CU 505 can send a UE context modification confirmation message in response to the UE context modification request message. For example, the UE context modification confirmation message may include "DRB modification list" information.

[0357] When a UE context modification confirmation message is received from CU 505, DU #1 510 can wait for reconfiguration until an indicator indicating reconfiguration completion is received. Although in Figure 13 Although not shown, if the UE context modification request message received from DU #1 510 cannot be supported, CU 505 may send a UE context modification rejection message to CU 505. The UE context modification rejection message may include reason information.

[0358] In operation 1331, DU #1 510 and CU 505 can perform an RRC reconfiguration procedure. The RRC reconfiguration procedure can be performed based on a UE context modification request procedure initiated by DU #1 510. CU 505 can generate an RRC reconfiguration message. CU 505 can send a DL delivery message including the RRC reconfiguration message to DU #1 510. DU #1 510 can send the RRC reconfiguration message to terminal 120 (e.g., UE). Parameters for the CA between DUs of terminal 120 can be reconfigured via the RRC reconfiguration message. Parameters may include at least a portion of RRC layer parameters, PDCP layer parameters, RLC layer MAC layer parameters, and / or PHY layer parameters. Terminal 120 can send a reconfiguration completion message to CU 505. CU 505 can receive the RRC reconfiguration completion message from terminal 120. In response to an RRC reconfiguration complete message, CU 505 may send an indicator indicating RRC reconfiguration completion (e.g., "RRC Reconfiguration Complete Indicator" IE) to DU #1 510. Upon receiving the indicator indicating RRC reconfiguration completion from CU 505, DU #1 510 may apply the configuration according to the SCell configuration modification procedure. For RRC configurations of SCells used by DU #1 510 or DU #2 520, the SCell configuration modification procedure may be performed if necessary.

[0359] In operation 1341, DU #1 510 can send an RRC reconfiguration complete message to DU #2 520. Upon receiving the RRC reconfiguration complete message, DU #2 520 can perform a CA between the DUs with terminal 120. DU #2 520 can recognize that the RRC configuration changed according to the SCell configuration modification procedure of DU #1 510 has been applied to terminal 120. For the RRC configuration used for the SCell of DU #1 510 or the RRC configuration used for the SCell of DU #2 520, a SCell configuration modification procedure can be performed if necessary. In cases where the RRC reconfiguration procedure between the terminal and the network is triggered due to the SCell configuration modification procedure, DU #2 520 can initiate a CA between the DUs based on the changed settings after receiving an RRC reconfiguration complete message (e.g., a "reconfiguration complete indicator").

[0360] Figure 14 The signal flow of an SCell configuration modification process initiated by an SCell-DU according to an embodiment of this disclosure is illustrated. CU 505 and DU #1 510 can be connected to each other via an F1 interface. DU #1 510 and DU #2 520 can be connected to each other via an X1 interface. For example, DU #1 510, as a DU providing a PCell, can be a PCell DU. DU #2 520, as a DU providing only an SCell, can be an SCell DU.

[0361] refer to Figure 14 DU #1 510 can provide one or more first cells. For example, one or more first cells may include cell #X and cell #Y. DU #2 520 can provide one or more second cells. For example, one or more second cells may include cell #A and cell #B.

[0362] In operation 1401, DU #1 510 and DU #2 520 can execute the DU group creation procedure. For the DU group creation procedure, the reference can be executed. Figures 7a to 9 At least one of the processes described. In the following, the case where DU #1 510 and DU #2 520 are configured as a group of DUs for inter-DU CA will be described.

[0363] In operation 1411, DU #2 520 can send a SCell configuration modification request message to DU #1 510. For details on SCell configuration modification request messages, please refer to... Figure 10cFor example, DU #1 510 can receive changed "transport information" (X1-U source / destination IP address) from DU #2 520 via the SCell configuration modification request procedure. DU #1 510 can then apply the changed values.

[0364] In operation 1413, DU #1 510 can send a SCell configuration modification confirmation message to DU #2 520. For details on SCell configuration modification confirmation messages, please refer to... Figure 10c .

[0365] In operation 1421, DU #1 510 may send a UE context modification request message to CU 505. When requesting RRC reconfiguration for the SCell of DU #1 510 or the SCell of DU #2 520 via the UE context modification request procedure, DU #1 510 may include the information to be reconfigured in the DU-to-CU RRC information (TS 38.331's "CellGroupConfig" IE) in the message (e.g., the UE context modification request message). DU #1 510 may send this message to CU 505.

[0366] In operation 1423, CU 505 can send a UE context modification confirmation message to DU #1 510. CU 505 can receive a UE context modification request message from DU #1 510. CU 505 can send a UE context modification confirmation message in response to the UE context modification request message. For example, the UE context modification confirmation message may include "DRB modification list" information.

[0367] When a UE context modification confirmation message is received from CU 505, DU #1 510 can wait for reconfiguration until an indicator indicating reconfiguration completion is received. Although in Figure 14 Although not shown, if the UE context modification request message received from DU #1 510 cannot be supported, CU 505 may send a UE context modification rejection message to CU 505. The UE context modification rejection message may include reason information.

[0368] In operation 1431, DU #1 510 and CU 505 can perform an RRC reconfiguration procedure. The RRC reconfiguration procedure can be performed based on a UE context modification request procedure initiated by DU #1 510. CU 505 can generate an RRC reconfiguration message. CU 505 can send a DL delivery message including the RRC reconfiguration message to DU #1 510. DU #1 510 can send the RRC reconfiguration message to terminal 120 (e.g., UE). Parameters of the CA between DUs for terminal 120 can be reconfigured via the RRC reconfiguration message. These parameters can include at least a portion of RRC layer parameters, PDCP layer parameters, RLC layer MAC layer parameters, and / or PHY layer parameters. Terminal 120 can send a reconfiguration completion message to CU 505. CU 505 can receive the RRC reconfiguration completion message from terminal 120. In response to an RRC reconfiguration complete message, CU 505 may send an indicator indicating RRC reconfiguration completion (e.g., "RRC Reconfiguration Complete Indicator" IE) to DU #1 510. Upon receiving the indicator indicating RRC reconfiguration completion from CU 505, DU #1 510 may apply the configuration according to the SCell configuration modification procedure. For RRC configurations of SCells used by DU #1 510 or DU #2 520, the SCell configuration modification procedure may be performed if necessary.

[0369] In operation 1441, DU #1 510 can send an RRC reconfiguration complete message to DU #2 520. Upon receiving the RRC reconfiguration complete message, DU #2 520 can perform CA (Configuration Assist) with the DU of terminal 120. DU #2 520 can recognize that the RRC configuration changes, as required by the SCell configuration modification process, have been applied to terminal 120. For either the RRC configuration used for the SCell of DU #1 510 or the RRC configuration used for the SCell of DU #2 520, the SCell configuration modification process can be performed if necessary.

[0370] Figure 15 An example of a user plane for spectral aggregation between DUs according to embodiments of this disclosure is shown. Figure 15 In this section, for CAs between DUs, the L2 protocol and the function of each protocol are described.

[0371] refer to Figure 15DU #1 510 can be a PCell DU. DU #1 510 can include a MAC processing module 612, an RLC-H processing module 613a, and an RLC-L processing module 613b. MAC processing module 612 can be configured to handle the functions of MAC 422 and MAC 472. RLC-H processing module 613a and RLC-L processing module 613b can be configured to handle the 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) can be handled by RLC-L processing module 613b, while other functions requiring non-real-time processing can be handled by RLC-H processing module 613a. DU #2 520 can be a SCell DU. DU #2 520 can include a MAC processing module 622 and an RLC-L processing module 623b.

[0372] The RLC-H processing module 613a can receive DL PDCP PDUs or send UL PDCPPDUs from the upper-layer PDCP protocol. The RLC-H processing module 613a can perform the following RLC sub-functions within the RLC function.

[0373] -SN number

[0374] -Headerization

[0375] -Reorganization

[0376] -ARQ

[0377] -Re-segmentation

[0378] RLC-L processing modules 613b and 623b can send DL RLC PDUs or receive UL RLC PDUs from a lower MAC protocol. RLC-L processing modules 613b and 623b can perform the following RLC functions within the RLC functionality.

[0379] - Segmentation.

[0380] MAC processing module 612 and MAC processing module 622 can be combined with each upper-layer RLC-L processing module to perform existing MAC functions.

[0381] Between the RLC-H processing module 613a and the RLC-L processing module 613b, it can send and receive DL RLC PDUs and / or UL RLC PDUs via an X1-U interface. The RLC-H processing module 613a and the RLC-L processing module 623b can send and receive flow control signals via an X1-U interface 852 for distributing DL RLC PDUs to the RLC-H processing module 613a and the RLC-L processing module 613b. The MAC processing modules 612 and 622 can send and receive MAC control signals required to support CA operations such as HARQ operations via the X1-U interface 852.

[0382] DL PDU processing operation

[0383] Upon receiving a DL PDCP PDU, the RLC-H processing module 613a can perform RLC SN numbering and RLC header generation. Subsequently, the RLC-H processing module 613a can perform distribution for each of DU #1 510 and DU #2 520. The RLC-H processing module 613a can also distribute and deliver RLCPDUs to each of the RLC-H processing module 613a and the RLC-L processing module 613b.

[0384] The RLC-L processing module 613b can receive RLC PDUs from the RLC-H processing module 613a. The RLC-L processing module 613b can obtain transport block size information (TB size information) from the MAC processing module 612 (each lower layer). If the current RLC PDU size is smaller than the transport block size, the RLC-L processing module 613b can send the RLC PDU to the MAC processing module 612; if the current RLC PDU size is greater than or equal to the transport block size, segmentation can be performed based on the transport block size. Additional parameters can be used for the above segmentation. For the segmentation information (SI) in the RLC header, updates can be performed based on whether it is a complete SDU or the first / last / intermediate segment. The segment offset (SO) can indicate the position of the current segment.

[0385] UL PDU processing operation

[0386] When RLC-L processing module 613b and LC-L processing module 623b receive UL RLC PDUs from the lower MAC address, the received UL RLC PDUs can be forwarded to RLC-H processing module 613a. RLC-H processing module 613a can receive UL-RLC PDUs from each of RLC-L processing module 613b and LC-L processing module 623b. If the received UL RLC PDU is fragmented, RLC-H processing module 613a can perform reassembly. RLC-H processing module 613a can send the reassembled RLC PDU or the received RLC PDU to the node responsible for upper-layer PDCP (e.g., CU 505).

[0387] ARQ processing operations

[0388] The RLC-H processing module 613a can receive status reports about DL PDCP PDUs from the terminal. In cases where retransmission is required due to NACK, the corresponding DL PDCP PDU can be retransmitted. For the RLC-H processing module 613a, if the retransmitted packet is a segmented PDU, the segmented PDU can be used. The RLC-H processing module 613a can send status reports about UL PDCPPDUs to the terminal and receive retransmitted packets from the terminal.

[0389] According to an embodiment, messages provided in the user plane between DU #1 510 and DU #2 520 can have various formats. The following formats can be used to exchange data such as RLC PDUs between DUs configured with inter-DU CA.

[0390] [Table 4]

[0391]

[0392] [Table 5]

[0393]

[0394]

[0395] Unlike existing methods that configure CAs for multiple cells within a DU, this disclosure provides CAs between different DUs, which not only increases the capacity of the DU for operators but also enables more efficient CA operations.

[0396] Figure 16 Components of an electronic device according to an embodiment of the present disclosure are shown. Figure 16The structure shown can be understood as a configuration of a device having at least one of the functions of the PCell-DU, SCell-DU, or CU described above. Terms such as “…unit” and “…module” as used herein refer to a unit that processes at least one function or operation and can be implemented by hardware, software, or a combination of hardware and software.

[0397] refer to Figure 16 The electronic device may include a transceiver 1610, a memory 1620, and a processor 1630.

[0398] Transceiver 1610 provides an interface for communicating with other devices in a network. That is, transceiver 1610 converts a bit stream sent from one electronic device to another into a physical signal, and converts a physical signal received from another electronic device back into a bit stream. In other words, transceiver 1610 can both send and receive signals. Therefore, transceiver 1610 can be referred to as a modem, communication unit, transmitting unit, receiving unit, or transmit / receive unit. In this case, transceiver 1610 allows electronic devices to communicate with other electronic devices or systems via backhaul connections (e.g., wired or wireless backhaul) or over a network. Transceiver 1610 may include one or more transceivers.

[0399] Memory 1620 stores data used for the operation of the electronic device, such as basic programs, application programs, and setting information. Memory 1620 can be configured using volatile memory, non-volatile memory, or a combination of volatile and non-volatile memory. Furthermore, memory 1620 provides stored data according to requests from processor 1630. Memory 1620 may be referred to as a storage unit.

[0400] Processor 1630 controls the overall operation of the electronic device. For example, processor 1630 sends and receives signals via transceiver 1610. Furthermore, processor 1630 writes data to and reads data from memory 1620. Processor 1630 may be referred to as a control unit. For this purpose, processor 1630 may be configured with multiple processors, or may include at least one subprocessor. According to various embodiments, processor 1630 can control the electronic device to perform operations according to the various embodiments described in this disclosure.

[0401] In one embodiment, a method performed by a first distribution unit (DU) is provided. The method may include sending an establishment request message to a second DU via a communication interface between the first DU and the second DU. The method may include receiving an establishment response message from the second DU. The establishment 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 establishment response message may include at least one of identification information associated with the second DU and address information associated with the second DU.

[0402] For example, an establishment request message may include at least one of information indicating whether the first DU supports inter-DU carrier aggregation (CA) functionality and information indicating whether the first DU supports dual connectivity (DC) functionality. An establishment response message may include at least one of information indicating whether the second DU supports inter-DU CA functionality or information indicating whether the second DU supports DC functionality.

[0403] For example, the method may include sending a modification request message to a second DU via a communication interface. The method may also include receiving a modification response message from the second DU. The modification request message may include at least one of the following: identification information associated with the first DU, address information associated with 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 inter-DU CA functionality, or information indicating whether the first DU supports DC functionality. The modification response message may include at least one of the following: identification information associated with the second DU, address information associated with 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 inter-DU CA functionality, or information indicating whether the second DU supports DC functionality.

[0404] For example, the method may include receiving a User Equipment (UE) context modification request message from a Central Unit (CU). The method may also include sending 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 one or more SCells include cells provided by a second DU, an establishment request message or a modification request message may be generated based on the context modification request message.

[0405] For example, the method may include sending an SCell configuration establishment request message to a second DU via a communication interface. The method may also include receiving an SCell configuration establishment response message from the second DU via a communication interface. The first DU may provide the primary cell (PCell) in a CA between DUs. The second DU may provide the SCell in a CA between DUs.

[0406] For example, an SCell configuration establishment request message may include information about the PCell and information about one or more candidate SCells. The SCell configuration establishment request message may include configuration information for at least one SCell from the one or more candidate SCells. The configuration information may include at least one of the following: parameters from at least one Radio Link Control (RLC) layer, parameters from at least one Media Access Control (MAC) layer, and / or parameters from at least one Physical (PHY) layer in the corresponding cell.

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

[0408] For example, an SCell configuration modification request message may include at least one of address information, bearer information, frequency band combination and feature set, Cell Radio Network Temporary Identity (C-RNTI) information, or DC-related capability information. An SCell configuration modification response message may include address information and modified SCell-specific configuration information. The configuration information may include at least one of the following: parameters of at least one RLC layer, parameters of at least one MAC layer, and / or parameters of at least one PHY layer in the corresponding cell.

[0409] For example, an SCell configuration modification response message may include information about the SCell where the configuration modification failed and information about the reason for the failure.

[0410] For example, the method may include receiving an SCell configuration modification request message from a second DU via a communication interface. The method may also include sending an SCell configuration confirmation message to the second DU via the communication interface. The first DU may provide a PCell in a CA between DUs. The second DU may provide an SCell in a CA between DUs.

[0411] For example, the method may include sending an SCell configuration release request message to a second DU via a communication interface. The method may also include receiving an SCell configuration release complete message from the second DU via the communication interface. The SCell configuration release request message may include information about the reason for releasing the SCell configuration of the second DU. The first DU may provide a PCell in a CA between DUs. The second DU may provide an SCell in a CA between DUs.

[0412] For example, an establishment 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 the same as those of the New Radio (NR) cell. An establishment response message may include DSS information, indicating whether the center frequency and bandwidth of the LTE cell in the second DU are the same as those of the NR cell.

[0413] For example, a setup request message may include cell status information indicating whether each cell provided by the second DU is active or deactivated. A setup response message may include cell status information indicating whether each cell provided by the second DU is active or deactivated.

[0414] In this embodiment, an electronic device for a first distribution unit (DU) is provided. This electronic device may include at least one processor and a memory storing instructions. When executed by the at least one processor, the instructions may cause the electronic device to send an establishment request message to the second DU via a communication interface between the first DU and the second DU, and to receive an establishment response message from the second DU. The establishment request message may include at least one of identification information associated with the first DU and cell information for each cell provided by the first DU. The establishment response message may include at least one of identification information associated with the second DU and cell information for each cell provided by the second DU.

[0415] According to an embodiment, an electronic device for a first distribution 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 send an establishment request message to the second DU via a communication interface between the first DU and the second DU. The at least one processor may be configured to receive an establishment response message from the second DU. The establishment 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 establishment response message may include at least one of identification information associated with the second DU and address information associated with the second DU.

[0416] When executed by at least one processor, instructions can cause an electronic device to perform a corresponding operation. In other words, at least one processor can be configured to perform the corresponding operation.

[0417] For example, at least one processor can be configured to receive a User Equipment (UE) Context Modification Request message from a Central Unit (CU) and send 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 one or more SCells include cells provided by a second DU, an Establishment Request message or a Modification Request message can be generated based on the Context Modification Request message.

[0418] For example, at least one processor can be configured to send an SCell configuration establishment request message to a second DU via a communication interface, and receive an SCell configuration establishment response message from the second DU via the same communication interface. The first DU can provide the primary cell (PCell) in a CA between DUs. The second DU can provide the SCell in a CA between DUs.

[0419] For example, an SCell configuration establishment request message may include information about the PCell and information about one or more candidate SCells. The SCell configuration establishment request message may include configuration information for at least one SCell from the one or more candidate SCells. The configuration information may include at least one of the following: parameters from at least one Radio Link Control (RLC) layer, parameters from at least one Media Access Control (MAC) layer, and / or parameters from at least one Physical (PHY) layer in the corresponding cell.

[0420] For example, at least one processor can be configured to send an SCell configuration modification request message to a second DU via a communication interface, and to receive an SCell configuration modification response message from the second DU via a communication interface. The first DU can provide the primary cell (PCell) in a CA between DUs, and the second DU can provide the SCell in a CA between DUs.

[0421] For example, an SCell configuration modification request message may include at least one of address information, bearer information, frequency band combination and feature set, Cell Radio Network Temporary Identity (C-RNTI) information, or DC-related capability information. An SCell configuration modification response message may include address information and modified SCell-specific configuration information. The configuration information may include at least one of the following: parameters of at least one RLC layer, parameters of at least one MAC layer, and / or parameters of at least one PHY layer in the corresponding cell.

[0422] For example, an SCell configuration modification response message may include information about the SCell where the configuration modification failed and information about the reason for the failure.

[0423] For example, at least one processor can be configured to send an SCell configuration modification request message to a second DU via a communication interface, and to receive an SCell configuration confirmation message from the second DU via the same communication interface. The first DU may provide a PCell in a CA between DUs. The second DU may provide an SCell in a CA between DUs.

[0424] For example, at least one processor can be configured to send an SCell configuration release request message to a second DU via a communication interface, and receive an SCell configuration release completion message from the second DU via the same communication interface. The SCell configuration release request message may include information about the reason for releasing the SCell configuration of the second DU. The first DU may provide a PCell in a CA between DUs. The second DU may provide an SCell in a CA between DUs.

[0425] Various embodiments of this document can be implemented as software, which includes one or more instructions stored in a machine-readable storage medium (e.g., DU, PCell-DU, SCell-DU). For example, a machine can invoke and execute at least one of one or more instructions stored from the storage medium. This makes it possible to operate the machine to perform at least one function according to the invoked at least one instruction. The one or more instructions may include code generated by a compiler or code that can be executed by an interpreter. Machine-readable storage media may be provided in the form of non-transitory storage media. In this document, "non-transitory" means only that the storage medium is a tangible device, excluding signals (e.g., electromagnetic waves), and the term does not distinguish between cases where data is stored semi-permanently in the storage medium and cases where data is temporarily stored. O-RAN enables the configuration of virtualized intelligent networks with standardized open interfaces. For network virtualization, operations according to embodiments may be implemented in the form of recording media (e.g., memory).

[0426] According to embodiments, methods according to various embodiments of this disclosure can be included in and provided therein in a computer program product. The computer program product can be traded as a product between a seller and a buyer. The computer program product can be distributed in the form of a machine-readable storage medium (e.g., an optical disc read-only memory (CD-ROM)), or distributed online (e.g., downloaded or uploaded) via an app store (e.g., the Play Store), or distributed directly between two user devices (e.g., smartphones). If distributed online, at least a portion of the computer program product can be temporarily generated or at least temporarily stored in a machine-readable storage medium, such as the memory of a manufacturer's server, an app store's server, or a relay server.

[0427] According to various embodiments, each component (e.g., a module or program) described above may include a single entity or multiple entities, and some of the multiple entities may be separately located in different components. According to various embodiments, one or more of the above-described components may be omitted, or one or more other components may be added. Alternatively or additionally, multiple components (e.g., modules or programs) may be integrated into a single component. In this case, according to various embodiments, the integrated component may still perform one or more functions of each of the multiple components in the same or similar manner as performed by a corresponding component among the multiple components prior to integration. According to various embodiments, operations performed by a module, program, or other component may be performed sequentially, in parallel, repeatedly, or heuristically, or one or more operations may be performed in a different order or omitted, or one or more other operations may be added.

[0428] The methods described in the embodiments of the claims or specification of this disclosure can be implemented in hardware, software, or a combination of hardware and software.

[0429] When implemented as software, a computer-readable storage medium may be provided for storing one or more programs (software modules). The one or more programs stored in the computer-readable storage medium are configured to be executed by one or more processors in an electronic device. The one or more programs include instructions to cause the electronic device to perform a method according to the embodiments described in the claims or specification of this disclosure. The one or more programs may be included in and provided therein 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., an optical disc read-only memory (CD-ROM)), or distributed online (e.g., downloaded or uploaded) via an app store (e.g., the Play Store), or directly between two user devices (e.g., smartphones). In the case of online distribution, at least a portion of the computer program product may be temporarily generated or at least temporarily stored in a machine-readable storage medium, such as the memory of a manufacturer's server, an app store's server, or a relay server.

[0430] Such programs (software modules, software) can be stored in random access memory, non-volatile memory including flash memory, read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), disk storage devices, optical storage devices (e.g., optical discs (CD-ROM), digital versatile discs (DVDs), or other formats), or magnetic tape. Alternatively, it can be stored in a memory configured with some or all of these. Furthermore, multiple configuration memories may be included.

[0431] Furthermore, the program can be stored in an attachable storage device that can be accessed via a communication network such as the Internet, intranet, local area network (LAN), wide area network (WAN), or storage area network (SAN), or a combination thereof. Such a storage device can be connected to a device executing embodiments of this disclosure via an external port. Additionally, a separate storage device on the communication network can also be connected to a device executing embodiments of this disclosure.

[0432] In the specific embodiments described above, the components included in this disclosure are represented in a singular or plural form according to the presented embodiments. However, the singular or plural representation may be appropriately chosen for ease of explanation, and this disclosure is not limited to singular or plural components; even components expressed in a plural form may be configured in a singular form, or vice versa.

[0433] According to various embodiments, one or more of the aforementioned components or operations may be omitted, or one or more other components or operations may be added. Alternatively or additionally, multiple components (e.g., modules or programs) may be integrated into a single component. In this case, the integrated component can still perform one or more functions of each of the multiple components in the same or similar manner as it was performed by a corresponding component among the multiple components prior to integration. According to various embodiments, operations performed by a module, program, or other component may be performed sequentially, in parallel, repeatedly, or heuristically, or one or more operations may be performed in a different order or omitted, or one or more other operations may be added.

[0434] Furthermore, specific embodiments have been described in the detailed description of this disclosure, and various modifications are possible without departing from the scope of this disclosure.

Claims

1. A method executed by a first distributed unit (DU), the method comprising: Send an establishment request message to the second DU through the communication interface between the first DU and the second DU; as well as Receive the setup response message from the second DU The establishment request message includes at least one of the following: identification information related to the first DU and cell information for each cell provided by the first DU. The response message includes at least one of the identification information associated with the second DU and the address information associated with the second DU.

2. The method according to claim 1, in, The setup request message includes at least one of information indicating whether the first DU supports carrier aggregation (CA) functionality between DUs and information indicating whether the first DU supports dual connectivity (DC) functionality. The establishment response message includes at least one of information indicating whether the second DU supports CA function between DUs and information indicating whether the second DU supports DC function.

3. The method according to claim 2, further comprising: Send a modification request message to the second DU via the communication interface; as well as Receive the modified response message from the second DU. The modification request message includes at least one of the following: identification information related to the first DU, address information related to the first DU, version information of the first DU, cell information of each cell provided by the first DU, information indicating whether the first DU supports CA function between DUs, and information indicating whether the first DU supports DC function. The modification response message includes at least one of the following: identification information related to the second DU, address information related to the second DU, version information of the second DU, cell information of each cell provided by the second DU, information indicating whether the second DU supports CA function between DUs, and information indicating whether the second DU supports DC function.

4. The method according to claim 1, further comprising: Receive User Equipment (UE) Context Modification Request message from the Central Unit (CU); as well as Send a UE context modification response message to the CU. The UE context modification request message includes information about one or more secondary cells (SCells), and In cases where one or more Scells include cells provided by a second DU, a setup request message or a modification request message is generated based on the context modification request message.

5. The method according to claim 1, comprising: Send a SCell configuration establishment request message to the second DU through the communication interface; as well as Receive the SCell configuration setup response message from the second DU through the communication interface. Among them, the first DU provides the primary cell (PCell) in the CA between DUs, and The second DU provides SCell in the CA between the DUs.

6. The method according to claim 5, in, The SCell configuration setup request message includes information about the PCell and information about one or more candidate SCells. The SCell configuration establishment request message includes configuration information for at least one SCell from one or more candidate SCells, and The configuration information includes at least one of the following: parameters of at least one Radio Link Control (RLC) layer, parameters of at least one Media Access Control (MAC) layer, and parameters of at least one Physical (PHY) layer in the corresponding cell.

7. The method according to claim 1, comprising: Send a SCell configuration modification request message to the second DU through the communication interface; as well as Receive SCell configuration modification response messages from the second DU through the communication interface. Among them, the first DU provides the primary cell (PCell) in the CA between DUs, and The second DU provides SCell in the CA between the DUs.

8. The method according to claim 7, in, The SCell configuration modification request message includes at least one of the following: address information, bearer information, frequency band combination and feature set, cell radio network temporary identity (C-RNTI) information, and DC-related capability information. The SCell configuration modification response message includes address information and modified SCell-specific configuration information. The configuration information includes at least one of the parameters of at least one RLC layer, at least one MAC layer, and at least one PHY layer in the corresponding cell.

9. The method according to claim 8, in, The SCell configuration modification response message also includes information about the SCell where the configuration modification failed and information about the reason for the failure.

10. The method according to claim 1, comprising: Receive SCell configuration modification request messages from the second DU through the communication interface; as well as A SCell configuration confirmation message is sent to the second DU through the communication interface. Wherein, the first DU provides PCell in the CA between DUs, and The second DU provides SCell in the CA between the DUs.

11. The method of claim 1, further comprising: Send a SCell configuration release request message to the second DU through the communication interface; as well as Receive the SCell configuration release complete message from the second DU through the communication interface. The SCell configuration release request message includes information about the reason for releasing the SCell configuration of the second DU. Wherein, the first DU provides PCell in the CA between DUs, and The second DU provides SCell in the CA between the DUs.

12. The method according to claim 1, in, The establishment request message includes Dynamic Spectrum Sharing (DSS) information indicating whether the center frequency and bandwidth of the Long Term Evolution (LTE) cell in the first DU are the same as the center frequency and bandwidth of the New Radio (NR) cell, and The establishment response message includes DSS information, which indicates whether the center frequency and bandwidth of the LTE cell in the second DU are the same as those of the NR cell.

13. The method according to claim 1, in, The establishment request message includes cell status information, indicating whether each cell provided by the second DU is active or deactivated, and The establishment response message includes cell status information provided by the second DU indicating whether each cell is active or deactivated.

14. An electronic device for a first distribution unit (DU), comprising: At least one processor; as well as Memory, stored instructions When executed by the at least one processor, the instructions cause the electronic device to: Send an establishment request message to the second DU through the communication interface between the first DU and the second DU; and Receive the setup response message from the second DU The establishment request message includes at least one of the following: identification information related to the first DU and cell information for each cell provided by the first DU. The establishment response message includes at least one of the identification information associated with the second DU and the cell information of each cell provided by the second DU.

15. The electronic device according to claim 14, in, The at least one processor is configured to perform the method according to any one of claims 2 to 14.