COMMUNICATION SYSTEM, USER EQUIPMENT AND CENTRAL UNIT

Abstract

To provide a communication system and the like having high speed, high reliability, and low delay in NR (New Radio).SOLUTION: A communication system includes user equipment 804, a plurality of distributed units (DUs) 802 and 803 capable of wireless communication with the user equipment 804, and a central unit (CU) 801 connected to the plurality of DUs 802 and 803. The user equipment 804 reports a measurement result regarding a downlink reference signal to the CU 801. The CU 801 determines a DU to be used for wireless communication with the user equipment 804 based on the measurement result.SELECTED DRAWING: Figure 8

Description

[Technical field]

[0001] The present invention relates to a communication system or the like that performs wireless communication between a communication terminal device such as a mobile terminal device and a base station device. [Background technology]

[0002] 3GPP (3rd Generation Partnership Project), a standardization organization for mobile communication systems, is considering a communication method called Long Term Evolution (LTE) for wireless sections and System Architecture Evolution (SAE) for the overall system configuration including a core network and a wireless access network (hereinafter collectively referred to as a network) (for example, Non-Patent Documents 1 to 5). This communication method is also called a 3.9G (3.9 Generation) system.

[0003] LTE uses OFDM (Orthogonal Frequency Division Multiplexing) for downlink and SC-FDMA (Single Carrier Frequency Division Multiple Access) for uplink as its access method. Also, unlike W-CDMA (Wideband Code Division Multiple Access), LTE does not include circuit switching and is only a packet communication method.

[0004] The decisions made by 3GPP regarding the frame configuration in the LTE system, which are described in Non-Patent Document 1 (Chapter 5), will be described with reference to FIG. 1. FIG. 1 is an explanatory diagram showing the configuration of a radio frame used in an LTE communication system. In FIG. 1, one radio frame is 10 ms. The radio frame is divided into 10 equally sized subframes. The subframe is divided into two equally sized slots. The first and sixth subframes of each radio frame include a downlink synchronization signal. The synchronization signal includes a primary synchronization signal (P-SS) and a secondary synchronization signal (S-SS).

[0005] The decisions made by 3GPP regarding the channel configuration in the LTE system are described in Non-Patent Document 1 (Chapter 5). It is assumed that the same channel configuration as that of a non-CSG cell is used in a CSG (Closed Subscriber Group) cell.

[0006] The Physical Broadcast Channel (PBCH) is a channel for downlink transmission from a base station device (hereinafter, sometimes simply referred to as a "base station") to a communication terminal device (hereinafter, sometimes simply referred to as a "communication terminal") such as a mobile terminal device (hereinafter, sometimes simply referred to as a "mobile terminal"). A BCH transport block is mapped to four subframes in a 40 ms interval. There is no explicit signaling of the 40 ms timing.

[0007] The Physical Control Format Indicator Channel (PCFICH) is a channel for downlink transmission from a base station to a communication terminal. The PCFICH notifies the communication terminal of the number of OFDM (Orthogonal Frequency Division Multiplexing) symbols used for PDCCHs from the base station. The PCFICH is transmitted every subframe.

[0008] The Physical Downlink Control Channel (PDCCH) is a channel for downlink transmission from a base station to a communication terminal. The PDCCH reports resource allocation information for a Downlink Shared Channel (DL-SCH), which is one of the transport channels described below, resource allocation information for a Paging Channel (PCH), which is one of the transport channels described below, and Hybrid Automatic Repeat reQuest (HARQ) information for the DL-SCH. The PDCCH carries an uplink scheduling grant. The PDCCH carries Acknowledgement (Acknowledgement) / Nack (Negative Acknowledgement), which are response signals to uplink transmission. The PDCCH is also called an L1 / L2 control signal.

[0009] A physical downlink shared channel (PDSCH) is a channel for downlink transmission from a base station to a communication terminal. A downlink shared channel (DL-SCH), which is a transport channel, and a PCH, which is a transport channel, are mapped to the PDSCH.

[0010] A physical multicast channel (PMCH) is a channel for downlink transmission from a base station to communication terminals. A multicast channel (MCH), which is a transport channel, is mapped to the PMCH.

[0011] The Physical Uplink Control Channel (PUCCH) is a channel for uplink transmission from a communication terminal to a base station. The PUCCH carries Ack / Nack, which is a response signal to a downlink transmission. The PUCCH carries a CQI (Channel Quality Indicator) report. CQI is quality information that indicates the quality of received data or the quality of the communication path. The PUCCH also carries a Scheduling Request (SR).

[0012] A Physical Uplink Shared Channel (PUSCH) is a channel for uplink transmission from a communication terminal to a base station. An Uplink Shared Channel (UL-SCH), which is one of the transport channels, is mapped to the PUSCH.

[0013] The Physical Hybrid ARQ Indicator Channel (PHICH) is a channel for downlink transmission from a base station to a communication terminal. The PHICH carries Ack / Nack, which is a response signal to an uplink transmission. The Physical Random Access Channel (PRACH) is a channel for uplink transmission from a communication terminal to a base station. The PRACH carries a random access preamble.

[0014] Downlink reference signals (RS) are known symbols in LTE communication systems. The following five types of downlink reference signals are defined: Cell-specific Reference Signal (CRS), MBSFN Reference Signal, UE-specific Reference Signal (DM-RS) Demodulation Reference Signal (PRS), Positioning Reference Signal (PRS), and Channel State Information Reference Signal (CSI-RS). Measurement of the physical layer of a communication terminal includes measurement of the reference signal received power (RSRP).

[0015] The transport channel described in Non-Patent Document 1 (Chapter 5) will be explained. Among the downlink transport channels, the broadcast channel (BCH) is broadcast to the entire coverage of the base station (cell). The BCH is mapped to the physical broadcast channel (PBCH).

[0016] Retransmission control using HARQ (Hybrid ARQ) is applied to the Downlink Shared Channel (DL-SCH). DL-SCH can be broadcast to the entire coverage of a base station (cell). DL-SCH supports dynamic or semi-static resource allocation. Semi-static resource allocation is also called persistent scheduling. DL-SCH supports discontinuous reception (DRX) of communication terminals to reduce power consumption of communication terminals. DL-SCH is mapped to the physical downlink shared channel (PDSCH).

[0017] The Paging Channel (PCH) supports DRX of communication terminals to enable low power consumption of the communication terminals. The PCH is required to be broadcast to the entire coverage of the base station (cell). The PCH is mapped to physical resources such as the Physical Downlink Shared Channel (PDSCH) that can be dynamically used for traffic.

[0018] The Multicast Channel (MCH) is used for broadcasting to the entire coverage of a base station (cell). The MCH supports SFN combining of MBMS (Multimedia Broadcast Multicast Service) services (MTCH and MCCH) in multi-cell transmission. The MCH supports semi-static resource allocation. The MCH is mapped to the PMCH.

[0019] Among the uplink transport channels, the uplink shared channel (UL-SCH) is subject to retransmission control using HARQ (Hybrid ARQ). The UL-SCH supports dynamic or semi-static resource allocation. The UL-SCH is mapped to the physical uplink shared channel (PUSCH).

[0020] The Random Access Channel (RACH) is limited to control information. The RACH is subject to collision risk. The RACH is mapped to the Physical Random Access Channel (PRACH).

[0021] Let us explain about HARQ. HARQ is a technology that improves the communication quality of a transmission line by combining Automatic Repeat reQuest (ARQ) and Forward Error Correction. HARQ has the advantage that error correction works effectively by retransmission even for transmission lines whose communication quality changes. In particular, it is possible to obtain further quality improvement by combining the reception result of the initial transmission and the reception result of the retransmission when retransmitting.

[0022] An example of a retransmission method will be described below. If the received data cannot be decoded correctly on the receiving side, in other words, if a CRC (Cyclic Redundancy Check) error occurs (CRC=NG), the receiving side will send a "Nack" to the transmitting side. The transmitting side that receives the "Nack" will retransmit the data. If the received data can be decoded correctly on the receiving side, in other words, if no CRC error occurs (CRC=OK), the receiving side will send an "Ack" to the transmitting side. The transmitting side that receives the "Ack" will send the next data.

[0023] The logical channel described in Non-Patent Document 1 (Chapter 6) will be explained. The Broadcast Control Channel (BCCH) is a downlink channel for broadcast system control information. The logical channel BCCH is mapped to the broadcast channel (BCH) or the downlink shared channel (DL-SCH), which are transport channels.

[0024] The Paging Control Channel (PCCH) is a downlink channel for transmitting paging information and changes to system information. The PCCH is used when the network does not know the cell location of the communication terminal. The PCCH, which is a logical channel, is mapped to the Paging Channel (PCH), which is a transport channel.

[0025] A Common Control Channel (CCCH) is a channel for transmission control information between a communication terminal and a base station. CCCH is used when a communication terminal does not have an RRC connection with the network. In the downlink direction, CCCH is mapped to a transport channel, the Downlink Shared Channel (DL-SCH). In the uplink direction, CCCH is mapped to a transport channel, the Uplink Shared Channel (UL-SCH).

[0026] The Multicast Control Channel (MCCH) is a downlink channel for point-to-multipoint transmission. The MCCH is used for transmission of MBMS control information for one or several MTCHs from the network to communication terminals. The MCCH is used only by communication terminals receiving MBMS. The MCCH is mapped to the Multicast Channel (MCH), which is a transport channel.

[0027] A Dedicated Control Channel (DCCH) is a channel that transmits dedicated control information between a communication terminal and a network on a one-to-one basis. DCCH is used when a communication terminal is in an RRC connection. DCCH is mapped to an uplink shared channel (UL-SCH) in the uplink and to a downlink shared channel (DL-SCH) in the downlink.

[0028] A Dedicated Traffic Channel (DTCH) is a one-to-one communication channel for transmitting user information to an individual communication terminal. DTCH exists in both uplink and downlink. DTCH is mapped to an uplink shared channel (UL-SCH) in uplink and to a downlink shared channel (DL-SCH) in downlink.

[0029] A Multicast Traffic Channel (MTCH) is a downlink channel for transmitting traffic data from a network to a communication terminal. The MTCH is a channel used only by communication terminals receiving MBMS. The MTCH is mapped to a Multicast Channel (MCH).

[0030] CGI stands for Cell Global Identifier. ECGI stands for E-UTRAN Cell Global Identifier. CSG (Closed Subscriber Group) cells are introduced in LTE, LTE-A (Long Term Evolution Advanced) (described below), and UMTS (Universal Mobile Telecommunication System).

[0031] A CSG (Closed Subscriber Group) cell is a cell for which an operator has specified available subscribers (hereinafter sometimes referred to as a "specified subscriber cell"). The specified subscribers are permitted to access one or more cells in a PLMN (Public Land Mobile Network). The one or more cells to which the specified subscribers are permitted to access are called "CSG cell(s)". However, there are access restrictions in the PLMN.

[0032] A CSG cell is a part of a PLMN that broadcasts a unique CSG identity (CSG ID) and broadcasts a CSG indication of "TRUE". Members of a pre-registered and authorized subscriber group access the CSG cell using the CSG ID, which is access permission information.

[0033] The CSG ID is broadcast by a CSG cell or cells. There are a plurality of CSG IDs in an LTE communication system. The CSG ID is used by a communication terminal (UE) to facilitate access of CSG-related members.

[0034] The location of a communication terminal is tracked in units of an area consisting of one or more cells. Location tracking is performed to track the location of the communication terminal even when it is in standby mode and to enable the communication terminal to be called, in other words, to allow the communication terminal to receive calls. The area for tracking the location of this communication terminal is called a tracking area.

[0035] In 3GPP, base stations called Home-NodeB (Home-NB; HNB) and Home-eNodeB (Home-eNB; HeNB) are under consideration. HNB in ​​UTRAN and HeNB in ​​E-UTRAN are base stations for home, corporate and commercial access services, for example. Non-Patent Document 2 discloses three different modes of access to HeNB and HNB. Specifically, an open access mode, a closed access mode and a hybrid access mode are disclosed.

[0036] 3GPP is also working on the development of standards for Long Term Evolution Advanced (LTE-A) as Release 10 (see Non-Patent Documents 3 and 4). LTE-A is based on the LTE wireless communication method, and is configured by adding several new technologies to it.

[0037] In the LTE-A system, in order to support wider frequency bandwidths (transmission bandwidths) up to 100 MHz, Carrier Aggregation (CA) is being considered, which aggregates two or more Component Carriers (CCs) (also called "aggregation"). CA is described in Non-Patent Document 1.

[0038] When CA is configured, the UE has only one RRC connection with the network (NW). In the RRC connection, one serving cell provides NAS mobility information and security input. This cell is called a Primary Cell (PCell). In the downlink, the carrier corresponding to the PCell is the Downlink Primary Component Carrier (DL PCC). In the uplink, the carrier corresponding to the PCell is the Uplink Primary Component Carrier (UL PCC).

[0039] Depending on the UE's capabilities, a secondary cell (SCell) is configured to form a set of serving cells together with the PCell. In the downlink, the carrier corresponding to the SCell is the downlink secondary component carrier (DL SCC). In the uplink, the carrier corresponding to the SCell is the uplink secondary component carrier (UL SCC).

[0040] A set of serving cells, which includes one PCell and one or more SCells, is configured for one UE.

[0041] New technologies for LTE-A include a technology that supports wider bandwidth (Wider Bandwidth Extension) and a Coordinated Multiple Point transmission and reception (CoMP) technology. CoMP, which is being considered for LTE-A by 3GPP, is described in Non-Patent Document 1.

[0042] In addition, in 3GPP, in order to handle the huge traffic in the future, the use of small eNBs (hereinafter sometimes referred to as "small-scale base station devices") that configure small cells is being considered. For example, technologies are being considered that improve frequency utilization efficiency and increase communication capacity by installing many small eNBs and configuring many small cells. Specifically, there is dual connectivity (abbreviated as DC) in which a UE connects to two eNBs to communicate. DC is described in Non-Patent Document 1.

[0043] Of the eNBs performing dual connectivity (DC), one may be referred to as a "master eNB (abbreviated as MeNB)" and the other as a "secondary eNB (abbreviated as SeNB)."

[0044] Mobile network traffic is on the rise, and communication speeds are also getting faster. Once LTE and LTE-A are fully operational, communication speeds are expected to become even faster.

[0045] Furthermore, to cope with the increasing sophistication of mobile communications, fifth-generation (hereinafter sometimes referred to as "5G") wireless access systems are being considered, with the goal of starting services after 2020. For example, in Europe, an organization called METIS has compiled requirements for 5G (see Non-Patent Document 5).

[0046] Compared to the LTE system, the 5G wireless access system requires a system capacity that is 1,000 times greater, a data transmission speed that is 100 times greater, data processing delay that is one-tenth (1 / 10), and 100 times the number of simultaneous connections of communication terminals, while also achieving further reductions in power consumption and reductions in equipment costs.

[0047] In order to meet such demands, 3GPP is currently working on 5G standards as Release 14 (see Non-Patent Documents 6 to 10). 5G wireless section technology is called "New Radio Access Technology" ("New Radio" is abbreviated as "NR"), and several new technologies are being considered (see Non-Patent Documents 11 to 14). For example, packet duplication using DC or multi-connectivity (abbreviated as MC), and separation of gNB into CU (Central Unit) and DU (Distributed Unit) are being considered. [Prior art documents] [Non-patent literature]

[0048]

Non-licensed literature 1

Non-licensed Document 2

Non-licensed Document 4

Non-licensed Document 5

Non-licensed Document 6

Non-licensed Document 7

Non-licensed literature 9

Non-licensed literature 10

Non-licensed Document 11

Non-licensed Document 12

Non-licensed Document 13

Non-licensed Document 14

Non-licensed Document 15

Non-licensed Document 16

Non-licensed Document 17

Non-licensed Document 18

[0049] In NR, in order to increase the number of UEs that can be accommodated per gNB, it is proposed to separate the gNB into two units, i.e., CU (Central Unit) and DU (Distributed Unit), and to allow multiple DUs to be connected to a CU. In addition, in NR, it is proposed to provide communications that satisfy high reliability and low latency by using packet replication, in which the same packets are sent and received at each gNB using a DC or MC configuration.

[0050] In NR, it has been proposed to duplicate packets using multiple DUs. However, because the DC or MC configuration cannot be applied directly between DUs, communication using packet duplication using multiple DUs cannot be provided. As a result, communication that satisfies high reliability and low latency cannot be provided.

[0051] In addition, in NR, when multiple DUs are used, especially when DC and CU-DU separation are used in combination, it is unclear to which DU of the SgNB the MgNB should transfer data. As a result, data transmission from the MgNB to a DU under the SgNB becomes impossible, and a problem occurs in which communication using the DU of the SgNB cannot be established between the UE and the base station. Therefore, in 5G, DC and CU-DU separation cannot be used in combination, which greatly reduces the efficiency of radio resource usage.

[0052] In view of the above problems, one of the objects of the present invention is to provide a communication system in NR that is high speed, highly reliable, and has low latency. [Means for solving the problem]

[0053] According to the present invention, for example, a communication system is provided that includes a user equipment, a plurality of distributed units (DUs) capable of wireless communication with the user equipment, and a central unit (CU) connected to the plurality of DUs, in which the user equipment reports measurement results for downlink reference signals to the CU, and the CU determines a DU to be used for wireless communication with the user equipment based on the measurement results. Effect of the Invention

[0054] According to the present invention, it is possible to provide a communication system etc. that is high speed, highly reliable and has low latency in NR.

[0055] The objects, features, aspects and advantages of the present invention will become more apparent from the following detailed description and the accompanying drawings. [Brief description of the drawings]

[0056] [Figure 1] FIG. 1 is an explanatory diagram showing the configuration of a radio frame used in an LTE communication system. [Diagram 2]1 is a block diagram showing the overall configuration of a communication system 200 based on the LTE standard that is being discussed in 3GPP. [Diagram 3] FIG. 3 is a block diagram showing a configuration of a mobile terminal 202 shown in FIG. 2, which is a communication terminal according to the present invention. [Figure 4] FIG. 3 is a block diagram showing a configuration of a base station 203 shown in FIG. 2 which is a base station according to the present invention. [Diagram 5] FIG. 2 is a block diagram showing the configuration of an MME according to the present invention. [Figure 6] 1 is a flowchart showing an overview of operations from cell search to standby performed by a communication terminal (UE) in an LTE communication system. [Figure 7] A diagram showing the concept of a cell configuration when macro eNBs and small eNBs are mixed. [Figure 8] FIG. 11 is a diagram showing the configuration of a CU that performs packet duplication in the PDCP layer and transfers the packets to multiple DUs, a DU, and a UE that performs duplicate packet detection in downlink communication, in accordance with the first embodiment. [Figure 9] FIG. 11 is a diagram showing the configuration of a bearer that passes through all DUs under a CU in accordance with the first embodiment. [Figure 10] FIG. 11 is a diagram showing a sequence for starting transmission and reception of duplicate packets in communication between a CU and a UE in accordance with the first embodiment. [Figure 11] FIG. 11 is a diagram showing a sequence for starting transmission and reception of duplicate packets in communication between a CU and a UE in accordance with the first embodiment. [Figure 12] FIG. 11 is a diagram showing another sequence for starting transmission and reception of duplicate packets in communication between a CU and a UE according to the first embodiment. [Figure 13] FIG. 11 is a diagram showing another sequence for starting transmission and reception of duplicate packets in communication between a CU and a UE according to the first embodiment. [Figure 14] FIG. 11 is a sequence diagram for a case where an RRC connection re-establishment is performed after a communication instruction start response, according to the first embodiment. [Figure 15]FIG. 11 is a sequence diagram for a case where an RRC connection re-establishment is performed after a communication instruction start response, according to the first embodiment. [Figure 16] FIG. 11 is a diagram showing a sequence in which a CU issues an instruction to each DU and UE without waiting for a response from each DU and UE, in accordance with the first embodiment. [Figure 17] FIG. 11 is a diagram showing a sequence in which a CU issues an instruction to each DU and UE without waiting for a response from each DU and UE, in accordance with the first embodiment. [Figure 18] FIG. 11 is a diagram showing a sequence for stopping transmission and reception of duplicated packets in communication between a CU and a UE in accordance with the first embodiment. [Figure 19] FIG. 11 is a sequence diagram for explaining switching of a DU in use and communication using multiple DUs in a C-Plane in the first embodiment. [Figure 20] FIG. 11 is a sequence diagram for explaining switching of a DU in use and communication using multiple DUs in a C-Plane in the first embodiment. [Figure 21] FIG. 4 is a sequence diagram illustrating an operation when an RRC connection re-establishment fails, according to the first embodiment. [Figure 22] FIG. 4 is a sequence diagram illustrating an operation when an RRC connection re-establishment fails, according to the first embodiment. [Figure 23] FIG. 11 is a sequence diagram illustrating an operation when a communication start instruction fails in the first embodiment. [Figure 24] FIG. 11 is a sequence diagram illustrating an operation when a communication start instruction fails in the first embodiment. [Diagram 25] FIG. 11 is a sequence diagram explaining an operation when a communication start response from a DU to a CU does not reach the CU, in accordance with the first embodiment. [Figure 26] FIG. 11 is a sequence diagram explaining an operation when a communication start response from a DU to a CU does not reach the CU, in accordance with the first embodiment. [Figure 27] FIG. 11 is a diagram showing a sequence of inter-DU mobility using packet duplication according to the first embodiment. [Figure 28] FIG. 11 is a diagram showing a sequence of inter-DU mobility using packet duplication according to the first embodiment. [Figure 29] FIG. 11 is a diagram showing a configuration for duplicating packets of the PDCP layer in downstream communication using multiple DUs, for CU-DU separation option 3-1, in accordance with a first modification of the first embodiment. [Diagram 30] This figure shows a configuration for duplicating packets of the RLC-H layer in downlink communication using multiple DUs, for CU-DU separation option 3-1, in accordance with the second embodiment. [Diagram 31] FIG. 11 is a diagram showing a configuration for performing PDCP delivery confirmation using HARQ-ACK in accordance with the third embodiment. [Diagram 32] FIG. 11 is a diagram showing a sequence relating to mobility in which PDCP delivery confirmation is performed using HARQ-ACK in accordance with the third embodiment. [Diagram 33] FIG. 11 is a diagram showing a sequence relating to mobility in which PDCP delivery confirmation is performed using HARQ-ACK in accordance with the third embodiment. [Diagram 34] FIG. 11 is a diagram showing a sequence relating to mobility in which PDCP delivery confirmation is performed using HARQ-ACK in accordance with the third embodiment. [Diagram 35] FIG. 11 is a diagram showing another sequence related to mobility in which PDCP delivery confirmation is performed using HARQ-ACK, in accordance with the third embodiment. [Diagram 36] FIG. 11 is a diagram showing another sequence related to mobility in which PDCP delivery confirmation is performed using HARQ-ACK, in accordance with the third embodiment. [Figure 37] FIG. 11 is a diagram showing another sequence related to mobility in which PDCP delivery confirmation is performed using HARQ-ACK, in accordance with the third embodiment. [Figure 38] A diagram showing a configuration for performing RLC delivery confirmation using HARQ-ACK for CU-DU separation option 3-1, in accordance with variant example 1 of embodiment 3. [Figure 39]FIG. 13 is a sequence diagram showing mobility between secondary base stations using a PDCP status report from a UE according to a fourth embodiment. [Diagram 40] FIG. 13 is a sequence diagram showing inter-DU mobility using a PDCP status report from a UE according to a fourth embodiment. [Diagram 41] FIG. 13 is a sequence diagram showing inter-DU mobility using a PDCP status report from a UE according to a fourth embodiment. [Diagram 42] FIG. 23 is a diagram illustrating an example of an architecture in which an inter-DU routing function is provided in the PDCP of an SgNB in ​​accordance with a sixth embodiment. [Diagram 43] FIG. 23 is a diagram illustrating an example of an architecture in which an inter-DU routing function is provided outside the PDCP in the CU of the SgNB, in accordance with the sixth embodiment. [Diagram 44] FIG. 23 is a diagram illustrating an example of an architecture in a case where a protocol stack having an inter-DU routing function is provided in addition to the PDCP in the CU of the SgNB, in accordance with the sixth embodiment. [Diagram 45] A figure showing an example of a DC sequence of an SB using an SgNB with a CU-DU separated configuration, for embodiment 6. [Diagram 46] A figure showing an example of a DC sequence of an SB using an SgNB with a CU-DU separated configuration, for embodiment 6. [Figure 47] A figure showing an example of a DC sequence of an SB using an SgNB with a CU-DU separated configuration, for embodiment 6. [Figure 48] This figure shows an example of architecture in a first variant of the sixth embodiment, in which the MgNB is provided with a function for determining a routing destination DU for the SgNB, and the PDCP in the CU of the SgNB is provided with an inter-DU routing function. [Figure 49] A figure showing an example of architecture in which one buffer for routing is provided in a CU of an SgNB, for a first variant of the sixth embodiment. [Figure 50]FIG. 21 is a diagram illustrating an example of an architecture in which a buffer for routing is provided for each DU in a CU of an SgNB, in accordance with a first variant of the sixth embodiment. [Figure 51] A figure showing an example of a DC sequence of an SB using an SgNB with a CU-DU separated configuration, for variant example 1 of embodiment 6. [Figure 52] A figure showing an example of a DC sequence of an SB using an SgNB with a CU-DU separated configuration, for variant example 1 of embodiment 6. [Figure 53] A figure showing an example of a DC sequence of an SB using an SgNB with a CU-DU separated configuration, for variant example 1 of embodiment 6. [Figure 54] FIG. 23 is a diagram illustrating an example of an architecture in a case where an MgNB is provided with an inter-DU routing function of an SgNB, in accordance with a second variant of the sixth embodiment. [Figure 55] A figure showing an example of a DC sequence of an SB using an SgNB with a CU-DU separated configuration, for a second variant of the sixth embodiment. [Figure 56] A figure showing an example of a DC sequence of an SB using an SgNB with a CU-DU separated configuration, for a second variant of the sixth embodiment. [Figure 57] A figure showing an example of a DC sequence of an SB using an SgNB with a CU-DU separated configuration, for a second variant of the sixth embodiment. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0057] Embodiment 1 Fig. 2 is a block diagram showing the overall configuration of an LTE-based communication system 200 being discussed in 3GPP. Fig. 2 will now be described. The radio access network is called E-UTRAN (Evolved Universal Terrestrial Radio Access Network) 201. A mobile terminal device (hereinafter referred to as "mobile terminal (User Equipment: UE)") 202, which is a communication terminal device, is capable of wireless communication with a base station device (hereinafter referred to as "base station (E-UTRAN NodeB: eNB)") 203, and transmits and receives signals via wireless communication.

[0058] Here, the term "communication terminal device" includes not only mobile terminal devices such as mobile mobile phone terminal devices, but also stationary devices such as sensors. In the following description, the "communication terminal device" may be simply referred to as a "communication terminal."

[0059] If control protocols for mobile terminals 202, such as RRC (Radio Resource Control), and user planes (hereinafter sometimes referred to as U-Planes), such as PDCP (Packet Data Convergence Protocol), RLC (Radio Link Control), MAC (Medium Access Control), and PHY (Physical layer), terminate in a base station 203, E-UTRAN is composed of one or more base stations 203.

[0060] A control protocol RRC (Radio Resource Control) between the mobile terminal 202 and the base station 203 performs broadcast, paging, RRC connection management, etc. The states of the base station 203 and the mobile terminal 202 in RRC include RRC_IDLE and RRC_CONNECTED.

[0061] In RRC_IDLE, PLMN (Public Land Mobile Network) selection, system information (SI) broadcast, paging, cell re-selection, mobility, etc. are performed. In RRC_CONNECTED, the mobile terminal has an RRC connection and can transmit and receive data with the network. In addition, in RRC_CONNECTED, handover (HO), measurement of neighbor cells, etc. are performed.

[0062] The base station 203 is classified into an eNB 207 and a Home-eNB 206. The communication system 200 includes an eNB group 203-1 including a plurality of eNBs 207, and a Home-eNB group 203-2 including a plurality of Home-eNBs 206. A system including an EPC (Evolved Packet Core) which is a core network and an E-UTRAN 201 which is a radio access network is called an EPS (Evolved Packet System). The EPC which is a core network and the E-UTRAN 201 which is a radio access network may be collectively called a "network."

[0063] The eNB207 is connected to a Mobility Management Entity (MME), or a Serving Gateway (S-GW), or an MME / S-GW unit (hereinafter sometimes referred to as an "MME unit") 204 including an MME and an S-GW via an S1 interface, and control information is communicated between the eNB207 and the MME unit 204. A plurality of MME units 204 may be connected to one eNB207. The eNBs 207 are connected to each other via an X2 interface, and control information is communicated between the eNBs 207.

[0064] The Home-eNB 206 is connected to the MME unit 204 via an S1 interface, and control information is communicated between the Home-eNB 206 and the MME unit 204. A plurality of Home-eNBs 206 are connected to one MME unit 204. Alternatively, the Home-eNB 206 is connected to the MME unit 204 via a Home-eNB GateWay (HeNBGW) 205. The Home-eNB 206 and the HeNBGW 205 are connected to each other via an S1 interface, and the HeNBGW 205 and the MME unit 204 are connected to each other via the S1 interface.

[0065] One or more Home-eNBs 206 are connected to one HeNBGW 205, and information is communicated through an S1 interface. The HeNBGW 205 is connected to one or more MME units 204, and information is communicated through an S1 interface.

[0066] The MME unit 204 and the HeNBGW 205 are upper devices, specifically, upper nodes, and control connections between the eNB 207 and the Home-eNB 206, which are base stations, and the mobile terminal (UE) 202. The MME unit 204 constitutes the EPC, which is a core network. The base station 203 and the HeNBGW 205 constitute the E-UTRAN 201.

[0067] Furthermore, 3GPP is considering the following configuration. The X2 interface between Home-eNBs 206 is supported. That is, the Home-eNBs 206 are connected via the X2 interface, and control information is communicated between the Home-eNBs 206. From the MME unit 204, the HeNBGW 205 appears as the Home-eNB 206. From the Home-eNB 206, the HeNBGW 205 appears as the MME unit 204.

[0068] In either case where the Home-eNB 206 is connected to the MME unit 204 via the HeNBGW 205 or where the Home-eNB 206 is directly connected to the MME unit 204, the interface between the Home-eNB 206 and the MME unit 204 is the same, that is, the S1 interface.

[0069] The base station 203 may configure one cell or multiple cells. Each cell has a predetermined range as a coverage area in which communication with the mobile terminal 202 is possible, and performs wireless communication with the mobile terminal 202 within the coverage area. When one base station 203 configures multiple cells, each cell is configured to be able to communicate with the mobile terminal 202.

[0070] FIG. 3 is a block diagram showing the configuration of the mobile terminal 202 shown in FIG. 2, which is a communication terminal according to the present invention. The transmission process of the mobile terminal 202 shown in FIG. 3 will be described. First, the control data from the protocol processing unit 301 and the user data from the application unit 302 are stored in the transmission data buffer unit 303. The data stored in the transmission data buffer unit 303 is passed to the encoder unit 304, where encoding such as error correction is performed. There may be data that is directly output from the transmission data buffer unit 303 to the modulation unit 305 without encoding. The data that has been encoded by the encoder unit 304 is modulated by the modulation unit 305. The modulated data is converted into a baseband signal, and then output to the frequency conversion unit 306, where it is converted into a radio transmission frequency. Thereafter, a transmission signal is transmitted from the antenna 307 to the base station 203.

[0071] Moreover, the receiving process of the mobile terminal 202 is executed as follows. A radio signal from the base station 203 is received by the antenna 307. The received signal is converted from a radio receiving frequency to a baseband signal by the frequency conversion unit 306, and demodulated by the demodulation unit 308. The demodulated data is passed to the decoder unit 309, where decoding such as error correction is performed. Of the decoded data, the control data is passed to the protocol processing unit 301, and the user data is passed to the application unit 302. A series of processes of the mobile terminal 202 is controlled by the control unit 310. Therefore, although the control unit 310 is omitted in FIG. 3, it is connected to each of the units 301 to 309.

[0072] Fig. 4 is a block diagram showing the configuration of the base station 203 shown in Fig. 2 which is a base station according to the present invention. A transmission process of the base station 203 shown in Fig. 4 will be described. The EPC communication unit 401 transmits and receives data between the base station 203 and the EPC (MME unit 204, etc.), the HeNBGW 205, etc. The other base station communication unit 402 transmits and receives data with other base stations. The EPC communication unit 401 and the other base station communication unit 402 each exchange information with a protocol processing unit 403. The control data from the protocol processing unit 403, and the user data and control data from the EPC communication unit 401 and the other base station communication unit 402 are stored in a transmission data buffer unit 404.

[0073] The data stored in the transmission data buffer unit 404 is passed to the encoder unit 405, where it is subjected to encoding processing such as error correction. Some data may be output directly from the transmission data buffer unit 404 to the modulator unit 406 without being encoded. The encoded data is modulated in the modulator unit 406. The modulated data is converted into a baseband signal, and then output to the frequency converter unit 407, where it is converted into a radio transmission frequency. The transmission signal is then transmitted from the antenna 408 to one or more mobile terminals 202.

[0074] Moreover, the reception process of the base station 203 is executed as follows. A radio signal from one or more mobile terminals 202 is received by an antenna 408. The received signal is converted from a radio reception frequency to a baseband signal by a frequency conversion unit 407, and demodulated by a demodulation unit 409. The demodulated data is passed to a decoder unit 410, where a decoding process such as error correction is performed. Of the decoded data, the control data is passed to a protocol processing unit 403 or an EPC communication unit 401 or an other base station communication unit 402, and the user data is passed to the EPC communication unit 401 and the other base station communication unit 402. A series of processes of the base station 203 is controlled by a control unit 411. Therefore, although the control unit 411 is omitted in FIG. 4, it is connected to each unit 401 to 410.

[0075] FIG. 5 is a block diagram showing the configuration of the MME according to the present invention. FIG. 5 shows the configuration of the MME 204a included in the MME unit 204 shown in FIG. 2 described above. The PDN GW communication unit 501 transmits and receives data between the MME 204a and the PDN GW. The base station communication unit 502 transmits and receives data between the MME 204a and the base station 203 via the S1 interface. If the data received from the PDN GW is user data, the user data is passed from the PDN GW communication unit 501 to the base station communication unit 502 via the user plane communication unit 503 and transmitted to one or more base stations 203. If the data received from the base station 203 is user data, the user data is passed from the base station communication unit 502 to the PDN GW communication unit 501 via the user plane communication unit 503 and transmitted to the PDN GW.

[0076] When the data received from the PDN GW is control data, the control data is passed from the PDN GW communication unit 501 to the control plane control unit 505. When the data received from the base station 203 is control data, the control data is passed from the base station communication unit 502 to the control plane control unit 505.

[0077] The HeNBGW communication unit 504 is provided when a HeNBGW 205 is present, and transmits and receives data via an interface (IF) between the MME 204a and the HeNBGW 205 depending on the information type. Control data received from the HeNBGW communication unit 504 is passed from the HeNBGW communication unit 504 to a control plane control unit 505. A result of processing in the control plane control unit 505 is transmitted to the PDN GW via the PDN GW communication unit 501. In addition, a result of processing in the control plane control unit 505 is transmitted to one or more base stations 203 by the S1 interface via the base station communication unit 502, and is also transmitted to one or more HeNBGW 205 via the HeNBGW communication unit 504.

[0078] The control plane control unit 505 includes a NAS security unit 505-1, an SAE bearer control unit 505-2, an idle state mobility management unit 505-3, etc., and performs general processing for the control plane (hereinafter, sometimes referred to as C-Plane). The NAS security unit 505-1 performs security for NAS (Non-Access Stratum) messages, etc. The SAE bearer control unit 505-2 performs management of SAE (System Architecture Evolution) bearers, etc. The idle state mobility management unit 505-3 performs mobility management in the idle state (also called the LTE-IDLE state or simply idle), generation and control of paging signals in the idle state, addition, deletion, update, search, and tracking area list management of one or more mobile terminals 202 under its control.

[0079] The MME 204a distributes a paging signal to one or more base stations 203. The MME 204a also performs mobility control in an idle state. The MME 204a manages a tracking area list when the mobile terminal is in an idle state and in an active state. The MME 204a initiates a paging protocol by transmitting a paging message to a cell that belongs to a tracking area in which the UE is registered. The idle state mobility management unit 505-3 may manage the CSG, CSG ID, and whitelist of the Home-eNB 206 connected to the MME 204a.

[0080] Next, an example of a cell search method in a communication system is shown. Fig. 6 is a flow chart showing an outline of a process from cell search to standby operation performed by a communication terminal (UE) in an LTE communication system. When the communication terminal starts a cell search, in step ST601, the communication terminal synchronizes slot timing and frame timing using a primary synchronization signal (P-SS) and a secondary synchronization signal (S-SS) transmitted from a surrounding base station.

[0081] P-SS and S-SS are collectively called the Synchronization Signal (SS). The Synchronization Signal (SS) is assigned a synchronization code that corresponds one-to-one to the PCI assigned to each cell. 504 different PCIs are being considered. These 504 different PCIs are used to achieve synchronization and to detect (identify) the PCI of the synchronized cell.

[0082] Next, in step ST602, for the synchronized cell, a cell-specific reference signal (CRS), which is a reference signal (RS) transmitted from the base station for each cell, is detected and the RS received power (Reference Signal Received Power: RSRP) is measured. A code that has a one-to-one correspondence with the PCI is used for the reference signal (RS). By correlating with the code, it is possible to separate the cell from other cells. By deriving the code for the RS of the cell from the PCI identified in step ST601, it is possible to detect the RS and measure the RS received power.

[0083] Next, in step ST603, the cell with the best RS reception quality, for example the cell with the highest RS reception power, that is, the best cell, is selected from among one or more cells detected up to step ST602.

[0084] Next, in step ST604, the PBCH of the best cell is received to obtain a BCCH, which is broadcast information. A MIB (Master Information Block), which includes cell configuration information, is mapped to the BCCH on the PBCH. Therefore, the MIB can be obtained by receiving the PBCH and obtaining the BCCH. Examples of MIB information include DL (downlink) system bandwidth (also called transmission bandwidth configuration: dl-bandwidth), the number of transmitting antennas, SFN (System Frame Number), and the like.

[0085] Next, in step ST605, the DL-SCH of the cell is received based on the cell configuration information in the MIB, and SIB (System Information Block) 1 in the broadcast information BCCH is obtained. SIB 1 includes information on access to the cell, information on cell selection, and scheduling information of other SIBs (SIBk; k is an integer ≧2). SIB 1 also includes a tracking area code (TAC).

[0086] Next, in step ST606, the communication terminal compares the TAC of the SIB1 received in step ST605 with the TAC portion of the tracking area identity (TAI) in the tracking area list that the communication terminal already holds. The tracking area list is also called a TAI list. The TAI is identification information for identifying a tracking area, and is composed of a MCC (Mobile Country Code), an MNC (Mobile Network Code), and a TAC (Tracking Area Code). The MCC is a country code. The MNC is a network code. The TAC is a code number of the tracking area.

[0087] If the TAC received in step ST605 is the same as the TAC included in the tracking area list as a result of the comparison in step ST606, the communication terminal enters standby mode in the cell. If the TAC received in step ST605 is not included in the tracking area list as a result of the comparison, the communication terminal requests a core network (EPC) including an MME, etc., to change the tracking area in order to perform a Tracking Area Update (TAU) through the cell.

[0088] An apparatus constituting a core network (hereinafter sometimes referred to as a "core network side apparatus") updates the tracking area list based on an identification number (such as a UE-ID) of a communication terminal sent from the communication terminal together with a TAU request signal. The core network side apparatus transmits the updated tracking area list to the communication terminal. The communication terminal rewrites (updates) the TAC list held by the communication terminal based on the received tracking area list. After that, the communication terminal enters standby mode in the cell.

[0089] The spread of smartphones and tablet terminal devices has led to an explosive increase in traffic via cellular wireless communications, raising concerns about a shortage of wireless resources around the world. In response to this, efforts are being made to create smaller cells and promote spatial separation in order to improve frequency utilization efficiency.

[0090] In a conventional cell configuration, a cell configured by an eNB has a relatively wide coverage area. Conventionally, a cell is configured to cover a certain area by the relatively wide coverage areas of a plurality of cells configured by a plurality of eNBs.

[0091] In the case of small cell configuration, the cell configured by the eNB has a narrower coverage range than the coverage of the cell configured by the conventional eNB. Therefore, as in the past, in order to cover a certain area, a large number of small cell eNBs are required compared to the conventional eNBs.

[0092] In the following description, a cell with a relatively large coverage, such as a cell configured by a conventional eNB, is referred to as a "macro cell," and an eNB that configures the macro cell is referred to as a "macro eNB." Also, a cell with a relatively small coverage, such as a cell that has been made into a small cell, is referred to as a "small cell," and an eNB that configures the small cell is referred to as a "small eNB."

[0093] The macro eNB may be, for example, a “Wide Area Base Station” as described in Non-Patent Document 7.

[0094] The small eNB may be, for example, a low power node, a local area node, a hotspot, etc. Also, the small eNB may be a pico eNB constituting a pico cell, a femto eNB constituting a femto cell, a HeNB, a remote radio head (RRH), a remote radio unit (RRU), a remote radio equipment (RRE), or a relay node (RN). Also, the small eNB may be a "local area base station" or a "home base station" as described in Non-Patent Document 7.

[0095] 7 is a diagram showing the concept of a cell configuration when macro eNBs and small eNBs are mixed. A macro cell configured by a macro eNB has a relatively wide coverage area 701. A small cell configured by a small eNB has a coverage area 702 that is smaller than the coverage area 701 of the macro eNB (macro cell).

[0096] When multiple eNBs are mixed, the coverage of a cell configured by one eNB may be included in the coverage of a cell configured by another eNB. In the cell configuration shown in Fig. 7, as shown by reference numerals "704" and "705", the coverage 702 of a small cell configured by a small eNB may be included in the coverage 701 of a macro cell configured by a macro eNB.

[0097] Also, as indicated by reference numeral "705," the coverage of multiple, for example, two, small cells 702 may be included within the coverage of one macro cell 701. A mobile terminal (UE) 703 is included, for example, within the coverage 702 of the small cell and communicates via the small cell.

[0098] Furthermore, in the cell configuration shown in FIG. 7, as indicated by reference numeral "706," there may be cases where coverage 701 of a macro cell formed by a macro eNB and coverage 702 of a small cell formed by a small eNB overlap in a complex manner.

[0099] Also, as indicated by reference numeral "707," there may be cases where coverage 701 of a macro cell configured by a macro eNB and coverage 702 of a small cell configured by a small eNB do not overlap.

[0100] Furthermore, as indicated by reference numeral "708," there may be cases where the coverage 702 of multiple small cells formed by multiple small eNBs is formed within the coverage 701 of one macro cell formed by one macro eNB.

[0101] One of the services in NR is URLLC (Ultra Reliability, Low Latency Communication), which requires low-latency and high-reliability communication. In order to simultaneously achieve low latency and high reliability, it was agreed at the 3GPP standardization meeting that URLLC will not use AM (Acknowledged Mode) in the RLC layer. In addition, it was agreed at the 3GPP standardization meeting that packet duplication in the PDCP layer will be supported in order to ensure reliability using UM (Unacknowledged Mode) in the RLC layer (see Non-Patent Document 11 (3GPP R2-1700672)). In NR, it is proposed to use the above-mentioned packet duplication in the configurations of DC and MC (see Non-Patent Document 12 (3GPP R2-1700172)).

[0102] Also, in 3GPP, it is proposed that the gNB is separated into two units (see Non-Patent Document 7). The two units are called a CU (Central Unit) and a DU (Distributed Unit). A plurality of DUs are connected to the CU. A plurality of options have been proposed for the division of functions between the CU and the DU in the CU-DU separation. For example, as option 2, it is proposed that the CU has PDCP, and the DU has RLC, MAC, and PHY. Also, as option 3, it is proposed that the CU has PDCP and H-RLC, and the DU has L-RLC, MAC, and PHY. Option 3 includes option 3-1, and in option 3-1, it is proposed that the L-RLC of option 3 has a function of RLC-PDU division, and the H-RLC of option 3 has a function of delivery confirmation and other functions of RLC.

[0103] In NR, it has been proposed to apply DC or MC to communication using multiple DUs (see Non-Patent Document 13 (3GPP R2-1700982) and Non-Patent Document 14 (3GPP R2-1701472)).

[0104] However, in the case of a DU, there is no distinction between the master base station and the secondary base station in the DC and MC, so the configuration and sequence of the DC or MC cannot be applied directly to communication between DUs. Therefore, a problem occurs in that communication using multiple DUs cannot be established, and communication between the base station and the UE cannot be performed.

[0105] In addition, because the mobility sequence between DUs is not disclosed, the UE cannot switch the DU that is the counterpart even if it moves, which causes a problem that stable communication cannot be provided when the UE moves.

[0106] In addition, because the configuration and sequence of the DC or MC cannot be applied directly to communications between DUs, the CU cannot provide communications with packet duplication using multiple DUs, which causes the problem that communications that satisfy high reliability and low latency cannot be provided.

[0107] In the first embodiment, a method for solving such a problem will be disclosed.

[0108] The CU duplicates a packet transferred from an upper network device. The CU transfers the duplicated packet to each DU. Each DU transmits the packet to the UE. The UE performs duplication detection for the packet. The UE deletes the duplicated packet. In the above-mentioned duplication detection and deletion, the UE may, for example, validate only one of the same packets received in duplicate and delete the rest.

[0109] The CU may perform the packet duplication at the PDCP layer, and the UE may perform the duplication detection and deletion of duplicate packets at the PDCP layer.

[0110] The above-described operations of the CU, DU and UE may be performed for downlink communication.

[0111] Furthermore, the UE duplicates the packet and transmits it to each DU via an entity in a lower layer opposite each DU. Each DU transfers the received packet to the CU. The CU performs duplication detection on packets received from the DU. The CU deletes duplicate packets. In the above-mentioned duplication detection and deletion, the CU may, for example, validate only one of the same packets received in duplicate and delete the rest. The CU transfers the packets that were not deleted to an upper network device.

[0112] The above-described operations of the CU, DU and UE may be performed for uplink communication.

[0113] A CU may forward duplicated packets to all DUs under its control. Similarly, a UE may transmit duplicated packets to all DUs under the control of the opposite CU. This increases communication redundancy and improves reliability.

[0114] Alternatively, the CU may forward duplicated packets to some of the DUs under its control. Similarly, the UE may transmit duplicated packets to some of the DUs under its control. This makes it possible to efficiently improve the reliability of communication.

[0115] The DU to which the duplicated packet is transferred from the CU (hereinafter, may be referred to as the DU used in downlink communication) may be different from the DU to which the duplicated packet is transmitted from the UE (hereinafter, may be referred to as the DU used in uplink communication). Also, the number of DUs used in downlink communication may be different from the number of DUs used in uplink communication. This allows for flexible setting of communication paths.

[0116] In the above, the number of DUs used in downstream communication may be one, two, or three or more. The number of DUs used in upstream communication may be the same. This makes it possible to efficiently improve reliability.

[0117] In the above, the DUs used in downlink communication and the DUs used in uplink communication (hereinafter sometimes referred to as "used DUs") may be set for each CU. For example, in communication with a certain UE, CU#1 may use DUs#1 and #2 among DUs#1 to #3 under its control, and CU#2 may use DUs#5 and #6 among DUs#4 to #6 under its control. This makes it possible to build an optimal communication system according to the communication path between each CU and DU.

[0118] In the above, the DU to be used may be set for each UE. For example, if a certain CU has DUs #1 to #3 under it, the CU may use DUs #1 and #2 in communication with UE #1. The CU may also use DUs #2 and #3 in communication with UE #2. This makes it possible to build an optimal communication system according to the location of the UE.

[0119] In the above, the DUs to be used may be set by a combination of each CU and each UE. For example, in communication with UE#1, CU#1 may use DU#1 and #2 among DU#1 to #3 under its control, and CU#2 may use DU#4 and #6 among DU#4 to #6 under its control. In addition, in communication with UE#2, CU#1 may use DU#2 and #3, and CU#2 may use DU#4 to #6. This makes it possible to build an optimal communication system according to the positional relationship between each CU and each DU and the communication route.

[0120] The CU may determine the DU in use.

[0121] The following examples (1) to (5) are disclosed as information that the CU may use in making the above-mentioned judgment.

[0122] (1) Measurement results acquired by subordinate DUs. For example, upstream signal measurement results.

[0123] (2) Measurement results obtained by the UE, for example, downlink signal measurement results.

[0124] (3) Load status of subordinate DUs.

[0125] (4) CU load status.

[0126] (5) A combination of (1) to (4) above.

[0127] The above (1) eliminates the need for the UE to notify the CU of the measurement results, thereby reducing the amount of signaling in the wireless section.

[0128] In the above (1), the DU may measure an uplink reference signal (uplink RS). This allows the DU to measure the uplink signal regardless of the presence or absence of user data. Alternatively, the DU may measure an error rate of the uplink data. This allows the DU to reduce the measurement processing time of the uplink signal. The DU may measure a bit error rate (BER) before error correction processing as the above-mentioned error rate. This allows the DU to obtain measurement results that accurately reflect the status of the wireless channel. The DU may also measure a block error rate (BLER) after error correction processing. This allows the DU to reduce the measurement result acquisition processing time.

[0129] The above-mentioned (2) makes it possible to use the same processing for acquiring measurement results as in existing LTE communication systems, thereby avoiding complexity when designing the communication system.

[0130] In the above (2), the UE may measure a downlink reference signal (downlink RS). This allows the UE to acquire a measurement result of the downlink signal regardless of the presence or absence of user data. Alternatively, the UE may measure an error rate of the downlink data. This allows the UE to reduce the measurement processing time of the uplink signal. The UE may measure a bit error rate (BER) before error correction processing as the above-mentioned error rate. This allows the UE to acquire a measurement result that accurately reflects the state of the wireless channel. The UE may also measure a block error rate (BLER) after error correction processing. This allows the UE to reduce the measurement result acquisition processing time.

[0131] The UE may notify the CU of the information in (2) above. The UE may notify the information via the DU. The UE may notify the DU of the information using L1 / L2 signaling. This allows for quick notification in response to changes in channel conditions. Alternatively, MAC signaling may be used. Since MAC signaling can use multilevel modulation, the number of symbols can be reduced. Alternatively, RRC signaling may be used. Using RRC signaling makes it easier for the DU to transfer the information to the CU.

[0132] When the UE notifies the CU of the information, the DU used by the UE for camping on may be the used DU, which can shorten the time required for the UE to connect to the DU.

[0133] Alternatively, the DU to be used may be the DU to which a connection with the UE is established. The DU to which a connection with the UE is established may be, for example, a DU to which a random access process is completed. Alternatively, for example, a DU to which an RRC connection is established may be used. This allows the UE to notify the CU even if the DU used for camping on is different from the DU to which a connection is currently established due to, for example, mobility occurrence.

[0134] Alternatively, when the UE notifies the CU of the information, multiple DUs may be used. The multiple DUs may be, for example, a combination of a DU at camp-on and a DU with which a connection with the UE is established, or multiple DUs with which a connection with the UE is established. This improves the reliability of the notification.

[0135] As the load status in (3) above, for example, a resource status or an available resource status may be used. As the resource status above, a radio resource may be used. This enables the CU to communicate with the UE using a DU that can secure a wide bandwidth on a radio channel. Alternatively, a buffer amount may be used. The buffer amount may be, for example, (a) a buffer amount in the RLC layer, (b) a buffer amount in the HARQ, or a combined amount of (a) and (b) above. This enables the CU to select a DU while avoiding congestion of user data.

[0136] Alternatively, for example, the number of connected UEs may be used as the load status in (3) above. This allows the CU to allocate high-capacity communication to a DU with a small number of connected UEs, making it possible to allocate DUs efficiently.

[0137] By using the above (3), the CU can select a DU while taking into account the communication status with other UEs.

[0138] As the load condition of the above-mentioned (4), for example, the buffer amount may be used. The buffer amount may be, for example, (a) the buffer amount in a layer newly established above the PDCP in the U-Plane of the NR, (b) the buffer amount in the PDCP layer, or the combined amount of the above-mentioned (a) and (b). The above-mentioned buffer amount may be a value for each opposing UE, or may be a combined value for the opposing UE. This enables flexible control, for example, by using multiple used DUs when the buffer amount is large and using one used DU when the buffer amount is small.

[0139] The CU may request the above-mentioned information (1) to (3) and (5) from each DU. The DU may notify the above-mentioned information (1) to (3) and (5) to the CU. The DU may perform the above-mentioned notification periodically or when requested by the CU. Alternatively, the DU may perform the above-mentioned notification when a predetermined condition is satisfied. The above-mentioned condition may be determined by a standard, or may be notified to the DU by the CU.

[0140] When using the above (1) to (5) to determine a DU to be used for communication between a CU and a UE (hereinafter, sometimes referred to as a used DU), a threshold may be set. The CU may determine a used DU using the threshold. For example, when the reception strength of an uplink reference signal received from a UE is equal to or greater than a certain value, the CU may determine that the DU can be used for communication between the CU and the UE. Alternatively, for example, when the amount of buffer in the DU is equal to or greater than a certain value, the CU may determine that the DU can be used for communication between the CU and the UE. This makes it easier for the CU to determine a used DU.

[0141] A CU-DU interface may be used in communication between a CU and a DU. For example, an Fs interface (see Non-Patent Document 7) may be used as the CU-DU interface. The Fs interface may be used when a CU requests the above-mentioned information (1) to (3) and (5) from a DU, or when a DU notifies a CU of the above-mentioned information (1) to (3) and (5). The CU may request the above-mentioned information (1) to (3) and (5) from a DU by piggybacking it on user data, or may do so independently. Also, the DU may notify the CU of the above-mentioned information (1) to (3) and (5) by piggybacking it on user data, or may do so independently. The above-mentioned requests and notifications may be piggybacked on user data by, for example, inserting the above-mentioned requests or notifications into free space (padding space) of user data. This makes it possible to reduce overhead such as headers during transfer. Furthermore, by making the above-mentioned requests and notifications independently of user data, the requests and notifications can be made quickly.

[0142] In the first embodiment, DUs that are candidates for the used DU (hereinafter, may be referred to as candidate DUs) may be provided. The candidate DUs may be, for example, DUs that are targets for which the UE monitors the PDCCH. The candidate DUs and the used DUs may be determined in stages. For example, the used DU may be selected from the candidate DUs. This allows flexible setting of the used DUs.

[0143] The candidate DUs may be all DUs under the control of the CU. This increases the flexibility of communication. The candidate DUs may be some DUs under the control of the CU. This reduces the number of DUs that the UE monitors the PDCCH, thereby reducing the power consumption of the UE.

[0144] The CU may notify the UE of information indicating which DU is to be used as the used DU. For the above-mentioned notification, L1 / L2 signaling may be used. For example, scheduling information, i.e., downlink allocation information and uplink grant information, may be used as the L1 / L2 signaling. The CU may transmit the L1 / L2 signaling to the UE via all or any of the candidate DUs. The CU may transmit the L1 / L2 signaling to the UE via the used DU in the downlink communication. The CU may include the downlink allocation information of the used DU, the uplink grant information, or both the downlink allocation information and the uplink grant information in the L1 / L2 signaling. The UE may determine the used DU by using the presence or absence of the above-mentioned scheduling information. This allows the CU to flexibly change the used DU and quickly notify the UE of the information on the used DU.

[0145] The CU may determine the candidate DUs. When the CU determines the candidate DUs, the CU may use information similar to the above-mentioned information (1) to (5) that the CU uses to determine the used DUs. The information that the CU uses to determine the used DUs and the information that the CU uses to determine the candidate DUs may be the same or different. This makes it possible to avoid complexity in determining the candidate DUs and used DUs in the CU.

[0146] The DU itself may determine the DU (used DU) and candidate DU to be used for communication between the CU and the UE. The DU may request the CU to use the DU for communication between the CU and the UE. The CU may accept or reject the request. By the DU itself making the determination, the amount of processing by the CU in determining the used DU can be reduced. In addition, since it is not necessary for the DU to notify the CU of the measurement result, the amount of signaling in the CU-DU interface, for example, the Fs interface, can be reduced.

[0147] DU will disclose the following examples (1) to (5) as information to be used in making the above-mentioned judgment.

[0148] (1) Measurement results acquired by the DU itself, for example, upstream signal measurement results.

[0149] (2) Measurement results obtained by the UE, for example, downlink signal measurement results.

[0150] (3) Load status of the local DU.

[0151] (4) CU load status.

[0152] (5) A combination of (1) to (4) above.

[0153] In the above (1), the DU may use information similar to the above information (1) and (2) used by the CU to determine the DU in use. This can provide the same effect as when the CU uses the above information (1) or (2) to determine the DU in use.

[0154] In the above (3), the CU may use the same information as the above (3) used to determine the DU to be used. This makes it unnecessary for the DU to notify the CU of its own load status, so that the amount of signaling in the CU-DU interface, for example, the Fs interface, can be reduced.

[0155] In the above (4), the CU may use the same information as the above (4) used to determine the DU to be used. This makes it possible to flexibly change the DU to be used depending on the amount of communication required between the CU and the UE.

[0156] The DU may request the information in (4) above from the CU. The CU may notify the DU of the information in (4) above. The CU may perform the above notification periodically, or when requested by the DU. Alternatively, the CU may perform the above notification when a predetermined condition is satisfied. The above condition may be determined by a standard, or may be notified from the CU to the DU. This makes it possible to optimize the amount of signaling required for the notification from the CU to the DU.

[0157] A threshold may be set in determining the DU to be used using the above (1) to (4). The DU may determine the DU to be used using the threshold. For example, when the reception strength of an uplink reference signal received from a UE is equal to or greater than a certain value, the DU may determine that the DU can be used for communication between a CU and the UE. Alternatively, for example, when the buffer amount in the DU is equal to or greater than a certain value, the DU may determine that the DU can be used for communication between a CU and the UE. This makes it easier for the DU to determine the DU to be used.

[0158] The above-mentioned in-use DU and candidate DU may be determined by the UE. The UE may request the CU to set the DU determined by the UE as the in-use DU or candidate DU. The request may be included in a scheduling request from the UE to the CU. The CU may accept or reject the request. By the UE determining the in-use DU, it becomes possible to quickly switch the in-use DU following the movement of the UE, for example.

[0159] When the UE determines the DU to be used, the UE may use the measurement result acquired by the UE itself. The measurement result may be the same as the above-mentioned information (2) used by the CU to determine the DU to be used. This provides the same effect as when the CU uses the above-mentioned information (2) to determine the DU to be used, and further makes it possible to reduce the amount of signaling in the CU-DU interface, for example, the Fs interface, and the radio interface.

[0160] The used DU in the uplink communication and the used DU in the downlink communication may be the same or different. The candidate DU in the uplink communication and the candidate DU in the downlink communication may be the same or different. By using the same DU, the control in the CU and the UE is simplified. In addition, by using different DUs, it is possible to select an appropriate DU according to the channel conditions of the uplink communication and the downlink communication, so that it is possible to ensure a large capacity of communication, low delay, and high reliability. The entity that determines the candidate DU and the used DU may be different between the uplink communication and the downlink communication. For example, the CU may determine the candidate DU and the used DU for the uplink communication, and the UE may determine the candidate DU and the used DU for the downlink communication. This allows the receiving side to control the used DU according to the channel conditions that can actually be measured, so that the reliability of the communication can be improved. Alternatively, for example, the UE may determine the candidate DU and the used DU for the uplink communication, and the CU may determine the candidate DU and the used DU for the downlink communication. This eliminates the need to feed back the measurement results on the radio interface, so that the amount of signaling on the radio interface can be reduced. Alternatively, for example, the CU may determine candidate DUs for both uplink and downlink communication, the UE may determine the DU to be used for downlink communication, and the CU may determine the DU to be used for uplink communication. This allows the receiver to control the DU to be used according to the channel conditions that can actually be measured, improving the reliability of communication, and by having the CU centrally provide candidate DUs, it becomes possible to quickly determine the DU to be used.

[0161] A method for using different DUs for upstream communication and downstream communication is disclosed.

[0162] In downlink communication, the CU may include the scheduling information of the used DU, i.e., downlink allocation information, in the L1 / L2 signaling of the used DU. The UE may determine that the DU that includes the downlink allocation information in the L1 / L2 signaling is the used DU. This allows the UE to quickly determine the used DU for downlink communication.

[0163] In uplink communication, the CU may notify the DU used in uplink communication by combining uplink grant information and information on the DU used in uplink communication in L1 / L2 signaling from the DU to the UE. The CU may perform the notification using one of the candidate DUs in downlink communication. The UE may determine the DU used in uplink communication using the L1 / L2 signaling. This allows the UE to quickly determine the DU used in uplink communication.

[0164] In the above-mentioned uplink communication, the UE may transmit data to multiple DUs simultaneously or at different times. The CU may notify the UE whether the data transmissions are to be performed simultaneously or at different times. The notification may be performed using L1 / L2 signaling, MAC signaling, or semi-statically by RRC signaling. This makes it possible to increase the flexibility in uplink communication.

[0165] In the present invention, a primary DU and a secondary DU may be provided. This makes it easier for the CU and UE to select the DU to be used, making it possible to reduce the amount of processing and signaling required by the CU and UE. A DU other than the primary DU may be a secondary DU. The number of primary DUs may be one or more. All DUs under a CU may be primary DUs, or some of the DUs may be primary DUs.

[0166] The primary DU may be, for example, a used DU or a candidate DU in C-Plane data transmission. This facilitates processing associated with the transfer of C-Plane data. Alternatively, the primary DU may be a DU that transmits data preferentially over the secondary DU in both the C-Plane and the U-Plane. This reduces the amount of processing required to determine the used DU in both the C-Plane and the U-Plane.

[0167] The CU may determine which DU under its control is to be the primary DU, which makes it easier to control the DUs in the entire communication system.

[0168] The UE may determine which DU, among those under the CU, is to be the primary DU. This makes it unnecessary for the UE to notify the CU of the measurement results, thereby making it possible to reduce the amount of signaling. For the DUs under the CU, the primary DU may be different for each UE. This allows an optimal conduction path to be constructed for each UE, thereby increasing reliability and enhancing the flexibility of the communication system. The CU and UE may each designate a different DU as the primary DU for uplink communication and downlink communication. This allows a flexible construction of conduction paths according to differences in the channel conditions of uplink communication and downlink communication, and also increases the reliability of communication.

[0169] The CU may determine the primary DU using information on the performance of the subordinate DUs. The aforementioned performance may be a communication range, a frequency band used, a buffer amount, or a communication capacity between the CU and the DU. This enables efficient communication as a communication system. For example, by selecting a DU with a wide communication range as the primary DU, the CU can use the primary DU to perform C-Plane communication with many UEs, thereby enabling efficient C-Plane communication.

[0170] When the CU uses information about the performance of the DU to determine the primary DU, the DU may notify the CU of information about its own DU's performance. The notification may be made when the DU starts a connection with the CU. The CU may request information about the performance of the DU from the DU. The request may be made when the DU starts a connection with the CU. This enables the CU to accurately determine the primary DU immediately after the DU starts a connection with the CU.

[0171] The above-mentioned request and notification may be performed when setting up an interface between a CU and a DU, for example, an Fs interface. Also, the above-mentioned request and notification may be included in signaling in setting up an Fs interface. This makes it possible to reduce the amount of signaling between a CU and a DU.

[0172] The above-mentioned request and notification may be performed when the capabilities of the DU are updated. This enables the CU and UE to accurately determine the primary DU by reflecting the updated capabilities of the DU.

[0173] The above-mentioned request and notification may be performed when starting communication with the UE, which allows the primary DU to be flexibly determined for each UE.

[0174] The CU and / or UE may select a DU having good communication quality with the UE as a primary DU. This makes it possible to improve the reliability of communication. For the communication quality, reception strength (e.g., RSRP) or a signal-to-noise ratio may be used. Other indices, for example, RSRQ, may be used. A certain threshold may be set for the communication quality, and a DU having a communication quality better than the threshold or a communication quality equal to or higher than the threshold may be selected as a primary DU. Alternatively, a predetermined number of DUs may be selected in order of best communication quality as the primary DUs. The threshold and / or the aforementioned predetermined number may be determined by a standard or may be determined by the CU. The CU may notify the UE of the threshold and / or the aforementioned predetermined number. For the notification, RRC signaling, MAC signaling, or L1 / L2 signaling may be used.

[0175] The CU and / or UE may set the DU used when the UE was camped on as the primary DU, which makes it easier to control the DU.

[0176] Alternatively, the CU and / or UE may set the DU when the UE becomes RRC-CONNECTED as the primary DU, which makes it easier to control the DU.

[0177] Alternatively, when the CU and / or UE decides the primary DU, the CU may use the above-mentioned information (1) to (4) for determining which subordinate DU the CU will use for communication. This allows the decision of the DU to be used and the decision of the primary DU to be made in common, making it easier to design the communication system and reducing the amount of processing.

[0178] The CU and / or UE may determine the primary DU permanently. In other words, the CU and / or UE may continue to use the determined primary DU as the primary DU. This makes it easier for the CU to control the DUs.

[0179] Alternatively, the CU and / or UE may variably determine the primary DU, i.e., may change the primary DU once determined, thereby making it possible to increase the flexibility of the communication system.

[0180] The CU may transfer the duplicated packet to each DU using a CU-DU interface, for example, an Fs interface. Similarly, each DU may transfer the received duplicated packet to the CU using a CU-DU interface, for example, an Fs interface.

[0181] A CU may transfer different numbers of duplicate packets to different DUs. For example, when DU#1 and DU#2 exist under a CU, the CU may copy a packet into three, transfer two packets to DU#1, and transfer the remaining packet to DU#2. This can improve the reliability of downlink communication. For example, when the channel condition between DU#1 and the UE is poor and the maximum number of retransmissions may be exceeded in HARQ, by transferring two packets from the CU to DU#1 as described above, even if a packet loss occurs for one packet due to the maximum number of retransmissions being exceeded for HARQ, the other packet can be transmitted from DU#1 to the UE.

[0182] The UE may transmit different numbers of duplicated packets to lower layer entities corresponding to different DUs. For example, when the UE communicates with a CU that has two DUs (DU#1, DU#2) under it, the UE's PDCP layer may duplicate a packet into three packets, transmit two packets to the RLC entity corresponding to DU#1, and transmit the remaining packet to the RLC entity corresponding to DU#2. This can improve the reliability of uplink communication.

[0183] In the above, when the CU determines the number of duplicated packets to be transferred to each DU, the CU may use the same information as that used by the CU to determine the DU to be used. Also, when the UE determines the number of duplicated packets to be transferred to the lower layer of each DU, the UE may use the same information as that used by the UE to determine the DU to be used. This makes it possible to avoid complexity in constructing a communication system.

[0184] The CU and / or UE may give duplicate packets the same PDCP sequence number, which facilitates packet duplication detection at the receiving UE and / or CU.

[0185] Alternatively, the CU and / or UE may assign different PDCP sequence numbers to the duplicated packets, which avoids the design complexity of the PDCP header adder and RLC transport in the transmitting CU and / or UE.

[0186] In the above, the CU and / or UE may assign different sequence numbers to each of the duplicated packets. For example, when the PDCP sequence numbers are #1 to #7, #4 and #5 may be assigned to two packets obtained by duplicating a certain packet, and #6 and #7 may be assigned to two packets obtained by duplicating another packet. This makes it possible to avoid complexity in the design of the PDCP header adding unit.

[0187] The CU and / or UE may provide an identifier indicating that the packet is a duplicated packet and transmit the duplicated packet to the receiving side. The identifier may be included in the PDCP header, for example. This allows the receiving side to easily identify the same packet.

[0188] Alternatively, the CU and / or UE may assign a PDCP sequence number with a branch number to each of the duplicated packets. For example, the CU and / or UE may assign PDCP sequence numbers #3-1 and #3-2 to two duplicated packets. This allows the receiving side to easily identify identical packets without adding a PDCP header.

[0189] Alternatively, even if branch numbers are used, there may be packets to which branch numbers are not assigned. For example, two copies of a packet may be assigned PDCP sequence numbers #3 and #3-1. This makes it possible to reduce the number of bits in the PDCP sequence number.

[0190] The UE and / or CU may discard duplicated PDCP-PDUs. The UE and / or CU may receive PDCP-PDUs on a first-come, first-served basis, i.e., discard later-received identical PDCP-PDUs, thereby reducing delays. The UE and / or CU may also immediately forward received PDCP-PDUs to higher layers, thereby reducing delays.

[0191] A priority may be assigned to each DU that is a continuity path between a CU and a UE. The UE and / or CU may preferentially receive a PDCP-PDU with a high priority. For example, a PDCP-PDU received via a DU with a small delay in the link between the CU / DU may be preferentially received. This facilitates the PDCP-PDU reception process when the difference in delay between the links between the CU / DU is large and when the reliability of one of the links is low.

[0192] The priority of each DU may be given by the CU or the UE. The following examples (1) to (7) are disclosed as information used by the CU and / or the UE to determine the above-mentioned priority.

[0193] (1) Link delay between CU and DU.

[0194] (2) Reliability of the CU / DU link.

[0195] (3) Propagation delay between DU / UE.

[0196] (4) DU performance.

[0197] (5) DU load status.

[0198] (6) Information indicating that it is a primary DU.

[0199] (7) A combination of (1) to (6) above.

[0200] In the above (1), for example, by giving a high priority to a DU with a small delay in a link between the CU and the DU, it is possible to facilitate the PDCP-PDU reception process of the CU and / or DU.

[0201] In the above (2), for example, the packet loss rate in the link may be used. This makes it possible to improve the reliability of communication between the CU and the UE by giving a high priority to a DU in a link with a low packet loss rate.

[0202] In the above (3), for example, by giving a high priority to a DU with a small propagation delay, it is possible to facilitate the PDCP-PDU reception process of the CU and / or DU.

[0203] In the above (4), for example, the time from when a PDCP-PDU is received from an upper layer to when the PDCP-PDU is transmitted to a radio interface may be used. Alternatively, the time from when data received from a radio interface is transmitted to a CU as a PDCP-PDU may be used. This makes it possible to facilitate the PDCP-PDU reception process of a CU and / or DU by, for example, giving a high priority to a DU with high performance.

[0204] In the above (5), for example, the free resource status may be used. For example, the free resource status may be the buffer amount of the DU, or the radio resource of the DU. In this way, for example, by assigning a high priority to a DU with many free resources, it is possible to facilitate the PDCP-PDU reception process of the CU and / or DU and improve the transmission speed.

[0205] In the above (5), the number of UEs communicating using the DU may be used. For example, a high priority may be assigned to a DU with a small number of UEs. This makes it possible to shorten the time spent waiting for scheduling of user data, thereby reducing delays in communication.

[0206] In the above (6), it is possible to reduce the amount of processing required for the CU to determine priority.

[0207] The CU and UE may measure the delay times of the links between the CU and the UE. In this case, the relative delay times of different links passing through different DUs may be measured. Measuring the relative values ​​simplifies the measurement process because the sender does not need to add a timestamp.

[0208] The above measurements may be performed on a CU-DU interface between a CU and a DU, for example, an Fs interface, and on a radio interface between a DU and a UE, respectively, which makes the measurement process easier.

[0209] In the above-mentioned measurement, the CU and the UE may use measurement data. As the above-mentioned measurement data, for example, RRC signaling or PDCP status PDU may be used. The above-mentioned measurement data may include a timestamp. The UE may obtain the link delay time by using the arrival time of the above-mentioned measurement data and the above-mentioned timestamp. This makes it possible to measure the absolute value of the link delay time. Also, it becomes possible to reduce the amount of processing in the DU in measuring the delay time of the link between the CU and the UE.

[0210] Alternatively, the CU and UE may use user data. This can reduce the overhead associated with the measurement. When performing measurements using user data, the transmitting side may use information indicating that the user data is the measurement target. The information may be notified to the UE in advance from the CU, or an identifier indicating the information may be added to the user data.

[0211] In the above-mentioned measurement, different signals may be used for the measurement of the CU-DU interface, for example, the Fs interface, and the measurement of the radio interface. For example, pilot data with a time stamp may be used for the Fs interface, and an uplink or downlink reference signal may be used for the radio interface. This makes it possible to reduce the overhead caused by the measurement.

[0212] The UE may notify the CU of the measurement result of the delay time of the link passing through each DU. The CU may use the measurement result to determine the priority of the link passing through each DU. For the notification, the UE may use RRC signaling. This can reduce the processing time by the DU, for example, the data decoding time. Alternatively, the UE may use PDCP status PDU. This enables notification with small overhead. Alternatively, different signaling may be used for the notification from the UE to the DU and the notification from the DU to the CU. For example, L1 / L2 signaling or MAC signaling may be used for the notification from the UE to the DU. The L1 / L2 signaling enables quick notification. The MAC signaling enables notification with a small number of symbols by using multi-level modulation. Also, a control signal of the CU-DU interface, for example, an Fs interface, may be used for the notification from the DU to the CU. The control signal may be piggybacked on user data, or may be transmitted independently of the user data. In this way, by using different signaling for notifications from the UE to the DU and notifications from the DU to the CU, the overhead caused by feedback is reduced.

[0213] The UE may notify the CU of the result of averaging or filtering the measured delay time values. The result of averaging or filtering may be notified in the same manner as the result of measuring the delay time from the UE to the CU. This makes it possible to suppress the influence of fluctuations in the measured delay time and to reduce the amount of signaling required for the notification.

[0214] In the above, the parameters used for the averaging process or filtering process may be determined by the standard or may be determined by the CU. The CU may notify the UE of the parameters. This enables flexible measurement according to the status of the communication system.

[0215] The CU may notify the UE of the measurement result of the delay time of the link passing through each DU. The UE may use the measurement result to determine the priority of the link passing through each DU. In the notification, the CU may use RRC signaling. This can reduce the processing time by the DU, for example, the data decoding time. Alternatively, the CU may use a PDCP status PDU. This enables notification with small overhead. Alternatively, different signaling may be used for the notification from the CU to the DU and the notification from the DU to the UE. For example, a control signal of the CU-DU interface, for example, the Fs interface, may be used for the notification from the CU to the DU. The control signal may be piggybacked on the user data, or may be transmitted independently of the user data. The above-mentioned piggybacking may be performed, for example, by inserting the control signal into an empty area (padding area) of the user data. For the notification from the DU to the UE, L1 / L2 signaling or MAC signaling may be used. L1 / L2 signaling allows for quick notification. MAC signaling allows for notification with a small number of symbols using multilevel modulation. In this way, by using different signaling for notifications from CU to DU and notifications from DU to UE, the overhead caused by feedback is reduced.

[0216] The CU may notify the UE of the result of averaging or filtering the measured delay time values. The result of averaging or filtering may be notified in the same manner as the result of measuring the delay time from the CU to the UE. This makes it possible to suppress the influence of fluctuations in the measured delay time and to reduce the amount of signaling required for the notification.

[0217] In the above, the parameters used for the averaging process or filtering process may be determined by the standard or may be determined by the CU. The CU may notify the UE of the parameters. This enables flexible measurement according to the status of the communication system.

[0218] The CU may determine the priority. The CU may notify the UE of the priority. This allows the CU to optimize the communication speed in consideration of the communication status of other UEs. The notification may include an identifier indicating the priority and an identifier indicating the DU. The notification may be the priority order of each DU. This allows the CU to notify the UE with a small amount of signaling. Alternatively, the notification may be the ratio of the amount of duplicated packet transfer for each DU. This allows the method of transferring duplicated packets to be flexibly specified, thereby making it possible to efficiently improve the reliability of communication.

[0219] The CU may use a PDCP control PDU for the notification, which allows the notification to be performed with less overhead. Alternatively, the CU may use RRC signaling, which allows a large amount of information to be notified.

[0220] The UE may determine the priority. The UE may use measurement results acquired by the UE for the determination. The UE may notify the CU of the priority. This eliminates the need for feedback of the measurement results, thereby reducing the amount of signaling.

[0221] In communication between a CU and a UE, the priority of a used DU may be different between an uplink and a downlink. This allows the priority to be flexibly controlled according to the status of each communication path of the uplink communication and the downlink communication. Also, the priority of a used DU may be determined by different entities in the uplink and the downlink. For example, the priority of the uplink may be determined by the CU, and the priority of the downlink may be determined by the UE. This allows the amount of signaling to be reduced in measurement and feedback of the measurement results.

[0222] In the communication between the CU and the UE, the PDCP layer on the receiving side may generate PDCP-SDUs using the replicated PDCP-PDUs and transfer them to the upper layer. The above-mentioned upper layer may be, for example, an application layer or an RRC. In the above, the number of PDCP-SDUs to be transferred may be one or more. That is, the receiving side does not necessarily have to generate PDCP-SDUs for all of the replicated PDCP-PDUs. This makes it possible to reduce delays on the receiving side. In addition, the receiving side may receive the replicated PDCP-PDUs using a reordering timer. This enables the system to operate smoothly.

[0223] In communication between a CU and a UE, the PDCP layer on the receiving side may be able to determine through which DU a PDCP-PDU was received. Each RLC entity on the receiving side may transfer an identifier representing the entity to the PDCP layer together with the PDCP-PDU. Alternatively, an identifier representing the DU used in the communication may be used. This makes it easier for the receiving side to determine the priority of the DU. Since it is not necessary to notify the identifier of the DU on the radio interface, it is possible to reduce the amount of signaling on the radio interface.

[0224] The PDCP layer on the receiving side may delete the identifier when creating a PDCP-SDU (PDCP-Service Data Unit) from the PDCP-PDU. This makes it possible to reduce the amount of data processing in a higher layer, for example, an application layer. Alternatively, the PDCP layer on the receiving side may leave the identifier when creating a PDCP-SDU and transfer the PDCP-SDU to a higher layer, for example, an RRC. This makes it easy to control the DUs used in a higher layer, for example, an RRC. The PDCP layer on the receiving side may transfer the PDCP-SDU from which the identifier has been deleted to a higher layer, for example, an application layer, and transfer information on the deleted identifier to another higher layer, for example, an RRC. This makes it possible to reduce the amount of processing in, for example, the application layer and the RRC.

[0225] In communication between a CU and a UE, the transmitting side may add an identifier. The receiving side RLC layer may transfer the identifier to the receiving side PDCP layer. This makes it possible to reduce the amount of processing in the receiving side RLC layer. The receiving side PDCP layer may transfer the data from which the identifier has been deleted to a higher layer, for example, an application layer. This makes it possible to reduce the amount of processing in the application layer. The receiving side PDCP layer may transfer the information of the identifier to another higher layer, for example, an RRC. This makes it easier to control the DUs used in the RRC.

[0226] The CU may obtain information on packets received from each DU. The information may be, for example, a packet loss rate or a packet delay time. This allows the CU to easily control the DUs in use.

[0227] Alternatively, the UE may obtain information on packets received from each RLC entity. The information may be, for example, a packet loss rate or a packet delay time. This allows the UE to easily control the DU to be used.

[0228] The IP address of the DU may be used as an identifier representing the DU. This allows the configuration of the base station interface to be used as is, thereby avoiding complexity in the design of the CU and DU. In addition, the occurrence of processing overhead in the RLC layer can be suppressed.

[0229] An identifier representing a DU (hereinafter, sometimes referred to as a DU-ID) may be assigned so as to be unique among DUs under a CU, which makes it possible to identify a DU using a small number of bits.

[0230] Alternatively, the DU-ID may be given so as to be unique among the surrounding gNBs. This allows the CU of the master base station to identify the DU of the secondary base station in a combination of DC or MC and CU-DU separation, thereby increasing the flexibility of the CU-DU configuration. The surrounding gNBs may be gNBs in the same tracking area. This makes it possible to prevent the surrounding gNBs in DU identification and the gNBs in the tracking area from being managed in duplicate, thereby making it possible to avoid the complexity of the device. Alternatively, the surrounding gNBs may be gNBs connected to the same MME (mobility management entity). This makes it easy to identify the DU in inter-gNB mobility.

[0231] Alternatively, the DU-ID may be given to be unique among the master base station and the secondary base station. This makes it possible to easily identify the DU among the master base station and the secondary base station under it, even if the master base station and the secondary base station cross the boundary of the surrounding gNBs described above.

[0232] Alternatively, an identifier given to be unique among DUs under the CU of a gNB may be used in combination with the identifier of the gNB. This makes it possible to easily identify the DU from other gNBs. Instead of the identifier of the gNB, a physical cell identity (abbreviated as PCI) may be used. This makes it easy to identify cells and DUs, making it easier to control the system.

[0233] Alternatively, a unique identifier may be given to every DU in a communication system, which makes it easy to identify the DU in the communication system.

[0234] The identifiers of the DUs may be renumbered. This makes it possible to reduce the number of bits used to identify the DUs in signaling, for example. The renumbering may be performed using a table, for example. The table may include the original identifiers of the DUs and the renumbered identifiers. This makes it easy to associate the original identifiers of the DUs with the renumbered identifiers.

[0235] The above-mentioned renumbering may be performed by an upper network device. This makes it possible to manage DUs across multiple gNBs with a small number of bits.

[0236] Alternatively, the renumbering described above may be performed by the master base station. This makes it possible to manage DUs in a DC or MC configuration with a small number of bits.

[0237] In the above, the master base station may request the secondary base station to notify the identifier of the DU under the secondary base station. The secondary base station may notify the master base station of the identifier of the DU under its own secondary base station. This allows the secondary base station to reduce the amount of signaling, since the master base station only needs to notify the identifier of the DU at the timing required by the master base station. Alternatively, the secondary base station may notify the master base station of the DU under its own base station when the configuration of the DU under its own base station is changed. This allows the master base station to perform control that quickly reflects the change in the configuration of the DU under the secondary base station.

[0238] The above-mentioned renumbering may be performed by each base station. This makes it possible to reduce the number of inquiry operations regarding identifier mapping between base stations or between a base station and an upper network device. This makes it possible to reduce the amount of signaling.

[0239] The CU and the UE may share information about the renumbering. The information may be a combination of the identifier of the DU before the renumbering and the identifier of the DU after the renumbering. In the communication between the CU and the UE, the amount of signaling related to the information of the DU can be reduced.

[0240] The CU may notify the UE of the above information. The notification may be performed by RRC signaling. This makes it possible to reduce the amount of signaling processing in the used DU.

[0241] Alternatively, notification between the CU and the DU may be performed by a control signal of the CU-DU interface, for example, the Fs interface. The control signal may be piggybacked on the user data, or may be transmitted independently of the user data. The piggybacking may be performed, for example, by inserting the control signal into an empty area (padding area) of the user data. This can reduce the overhead associated with the transmission of the control signal. Notification between the DU and the UE may be performed by L1 / L2 signaling. This allows for quick notification from the DU to the UE. Alternatively, MAC signaling may be used. This allows for notification with a small number of symbols using multi-level modulation, and also allows for increased reliability through HARQ retransmission control. Alternatively, a signaling method similar to carrier aggregation may be used. This allows for a common signaling method, making it possible to avoid complexity in system design.

[0242] The CU and DU may share information related to the renumbering. In sharing the information, the CU and DU may notify each other of information necessary for renumbering. For the notification, a CU-DU interface, for example, an Fs interface, may be used. The DU may notify the CU of its own DU's identifier as information necessary for renumbering. The CU may notify the DU of the identifier after renumbering. This makes it possible to reduce the number of bits required for notifying the DU's identifier in a CU-DU interface, for example, an Fs interface.

[0243] The upper network device and the CU may share information related to the renumbering. In sharing the information, the upper network device and the CU may notify each other of information necessary for renumbering. The notification may be performed using an interface between the upper network device and the CU. The CU may notify the upper network device of, for example, the identifier of a subordinate DU as information necessary for renumbering. The identifier of the DU may be combined with the identifier of the gNB. The upper network device may notify information combining the identifier of the DU before renumbering and the identifier of the DU after renumbering. This makes it possible to reduce the amount of signaling of information related to the DU in the interface between the upper network device and the CU.

[0244] In the CU and / or UE, the PDCP layer buffer may be shared among the DUs. This can save the amount of buffering. Alternatively, a PDCP layer buffer may be reserved for each DU. This can reduce delays, for example, because even if a DU has a halt in communication, other DUs can continue communication.

[0245] Fig. 8 is a diagram showing the configuration of a CU that performs packet duplication at the PDCP layer and transfers the packet to multiple DUs, a DU, and a UE that performs duplicate packet detection in downlink communication. In Fig. 8, a CU 801 communicates with a UE 804 using a DU #1 (sometimes called a DU 802) and a DU #2 (sometimes called a DU 803).

[0246] 8, an upper network device 805 transfers a packet 806 to a New AS Layer 807 in a CU 801. The New AS Layer is a layer that has a function of mapping a QoS flow to a data radio bearer (abbreviated as a Data Radio Bearer, DRB) in the U-Plane of the NR (see Non-Patent Document 11). The New AS Layer 807 generates a PDCP-Service Data Unit (PDCP-SDU) 808 using the packet 806, and transfers the PDCP-SDU to a PDCP Layer 809.

[0247] In Fig. 8, the PDCP layer 809 copies the PDCP-SDU 808 into two, adds a PDCP header 810 to one of the copied SDUs to generate PDCP-PDU#1 (sometimes called PDCP-PDU 812), and adds a PDCP header 811 to the other copied SDU to generate PDCP-PDU#2 (sometimes called PDCP-PDU 813). The PDCP headers 810 and 811 contain the same information of sequence number #n in Fig. 8, but may contain information of different sequence numbers. For example, making the sequence numbers of the PDCP headers 810 and 811 consecutive makes it easier to design the sequence number assignment section of the PDCP layer.

[0248] 8, the PDCP layer 809 transfers the PDCP-PDU#1 to the RLC layer 816 of the DU#1, using the Fs interface 814. Also, the PDCP layer 809 transfers the PDCP-PDU#2 to the RLC layer 817 of the DU#2, using the Fs interface 815.

[0249] 8, the DU#1 transmits the PDCP-PDU#1 received at the RLC layer 816 to the DU#1 counterpart entity 818 of the UE 804. The DU#2 transmits the PDCP-PDU#2 received at the RLC layer 817 to the DU#2 counterpart entity 819 of the UE 804. The RLC layer 820 transfers the received PDCP-PDU#1 to the PDCP layer 822. The RLC layer 821 transfers the received PDCP-PDU#2 to the PDCP layer 822.

[0250] In Fig. 8, the PDCP layer 822 detects duplicate packets. In the example of Fig. 8, the PDCP layer 822 detects that PDCP-PDU#1 and PDCP-PDU#2 are duplicated, and deletes PDCP-PDU#2. The PDCP layer 822 acquires PDCP-SDU808 by deleting the PDCP header 810 from PDCP-PDU#1, and transfers the PDCP-SDU808 to the New AS Layer 823. The PDCP layer 822 deletes PDCP-PDU#2 in the example of Fig. 8, but may delete PDCP-PDU#1. In that case, the PDCP layer 822 acquires PDCP-SDU808 by deleting the PDCP header 811 from PDCP-PDU#2, and transfers the PDCP-SDU808 to the New AS Layer 823.

[0251] In FIG. 8, New AS Layer 823 restores packet 806 using PDCP-SDU 808 and transfers packet 806 to upper layer 824 .

[0252] In communication between a CU and a UE, a bearer that passes through all DUs under the CU may be established. In the inter-DU mobility of the UE, the CU may notify the UE of changes in settings related to communication with each DU. This makes it unnecessary to change the bearer even when the UE moves between DUs, thereby reducing the amount of signaling.

[0253] The CU may reserve radio resources for all DUs under its control. The CU may reserve buffer capacity for all DUs under its control. The radio resources and / or buffer capacity may be reserved when the CU sets a new bearer. The radio resources and / or buffer capacity may be reserved when the CU changes the settings of a bearer. This makes it possible to continue communication while satisfying the QoS (e.g., bandwidth guarantee) required for the bearer even when the UE performs inter-DU mobility.

[0254] A CU may reserve radio resources for some of the DUs under its control. The number of DUs for which radio resources are reserved may be one, or two or more. This makes it possible to save on the radio resources reserved when establishing the bearer described above, thereby enabling efficient communication.

[0255] The aforementioned part of the DUs may be a predetermined number of DUs in order of the best measurement results, which can improve the reliability of communication and save radio resources.

[0256] Alternatively, some of the DUs may be adjacent to the DUs used in the communication between the CU and the UE, which can further save the radio resources reserved by the CU for the DUs.

[0257] Alternatively, the above-mentioned part of DUs may be DUs surrounding the used DU in the communication between the CU and the UE. The surrounding DUs may include DUs adjacent to the used DU. This makes it possible to conserve radio resources while enabling smooth inter-DU mobility even when the radio channel conditions change suddenly.

[0258] Fig. 9 is a diagram showing the configuration of a bearer passing through all DUs under a CU. Fig. 9 shows an example in which a CU 900 has DU#1, DU#2, and DU#3 (sometimes called DU901, DU902, and DU903, respectively) under its control, and communicates with a UE 904.

[0259] In Fig. 9, a bearer 905 is established as a bearer that passes through all DUs under a CU. The bearer 905 terminates at a PDCP layer 906 of a CU 901 and a PDCP layer 907 of a UE 904. The bearer 905 passes through an RLC layer, a MAC layer, and a PHY layer that each of a DU #1, a DU #2, and a DU #3 has. The bearer 905 also passes through a DU #1 facing entity 908, a DU #2 facing entity 909, and a DU #3 facing entity 910 of the UE 904.

[0260] Although Fig. 9 shows an example of a bearer passing through all DUs under a CU, a bearer passing through some of the DUs may be used. For example, a bearer may be configured by candidate DUs in communication with a UE. Alternatively, a bearer may be configured by a DU used in communication with a UE. This makes it possible to prevent unnecessary resource reservation.

[0261] A CU may request information on the performance of a subordinate DU from the subordinate DU. The request may be made to a DU that has newly become subordinate to the CU, for example, a DU connected to the CU. The information on the performance of the DU may be, for example, the time from when a PDCP-PDU is received from an upper layer to when the PDCP-PDU is transmitted to a radio interface. Alternatively, the information on the performance of the DU may be the time from when data received from a radio interface is transmitted to the CU as a PDCP-PDU. Alternatively, the information on the performance of the DU may be the buffer amount of the DU or the radio resources. This allows the CU to appropriately change the bearer settings when adding a DU, using the information on the performance of the DU.

[0262] A DU may notify a CU of information regarding its own performance. The notification may be performed when the DU becomes subordinate to a CU, for example, when the DU is connected to the CU. The information may be the same as the above-mentioned information regarding the performance of the DU. This can provide the same effect as described above.

[0263] A DU may request information about a communication status from a CU. The request may be made when the DU is newly subordinate to a CU, for example, when the DU is connected to the CU. The information about the communication status may be, for example, information about a UE with which the CU is communicating, information about a bearer used by the UE, or information about the setting of the bearer. This allows, for example, a startup operation to be performed quickly when the DU is connected.

[0264] The CU may notify the DU of information on the communication status. The notification may be sent to a DU that has newly become subordinate to the CU, for example, a DU connected to the CU. The information on the communication status may be the same as the information described above. This can provide the same effect as described above.

[0265] The above-mentioned request and notification may be performed when setting up an interface between a CU and a DU, for example, an Fs interface. Also, the above-mentioned request and notification may be included in signaling in setting up an Fs interface. This makes it possible to reduce the amount of signaling between a CU and a DU.

[0266] The above-mentioned request and notification may be performed when the capabilities of the DU are updated. This enables the CU and UE to accurately determine the primary DU by reflecting the updated capabilities of the DU.

[0267] The above-mentioned request and notification may be performed when starting communication with the UE, which allows the primary DU to be flexibly determined for each UE.

[0268] In communication between a CU and a UE, a split bearer (hereinafter, sometimes referred to as an inter-DU split bearer) may be established for a DU to which a duplicate packet is to be transferred. This makes it possible to save resources of a DU that is not used for the conduction of a duplicate packet. For a DU for which an inter-DU split bearer has once been established, the inter-DU split bearer does not need to be released. For example, when inter-DU mobility occurs, an inter-DU split bearer may not need to be released. In addition, the inter-DU split bearer may be released for the DU. For example, when a connection between the UE and the CU is released, an inter-DU split bearer may be released when the DU is overloaded. This makes it possible to reduce the amount of signaling related to the setting of an inter-DU split bearer, even when a DU previously used in communication between a CU and a UE is used again.

[0269] Figures 10 and 11 are diagrams showing a sequence for starting transmission and reception of duplicate packets in communication between a CU and a UE. Figures 10 and 11 are connected at the position of a boundary line BL1011. Figures 10 and 11 show an example of switching from communication using DU#1 to communication using duplicate packets using DU#1 and #2.

[0270] 10, steps ST1000, ST1001, and ST1002 represent transmission and reception of user data between an upper NW device and a UE. In step ST1000, user data is transmitted and received between the upper NW device and a CU, in step ST1001, user data is transmitted and received between the CU and a DU#1, and in step ST1002, user data is transmitted and received between the DU#1 and a UE.

[0271] In steps ST1003 and ST1004 shown in FIG. 10, the CU notifies the UE of signaling of RRC connection reconfiguration. The notification is transmitted from the CU to the DU #1 in step ST1003, and is transmitted from the DU #1 to the UE in step ST1004. The notification includes information indicating the addition of the DU #2 and information indicating the start of packet duplication. The notification also includes information on the RRC parameters for the DU #2 opposite entity. The notification may include information on the RRC parameters for the DU #1 opposite entity. The UE performs packet duplication and RRC parameter configuration for communication with the DU #2, using the information received in step ST1004.

[0272] In steps ST1005 and ST1006 shown in Fig. 10, the UE transmits an RRC connection reconfiguration completion notification to the CU. The notification is transmitted from the UE to the DU #1 in step ST1005, and from the DU #1 to the CU in step ST1006.

[0273] In step ST1007 shown in FIG. 10, the CU notifies the DU#2 of a communication start instruction. The instruction may include RRC parameters. The instruction may also include information indicating that a packet is to be copied. Using the instruction, the DU#2 sets RRC parameters for transmitting and receiving data to and from the UE.

[0274] 10, the DU#2 notifies the CU of a response to the communication start instruction. The response may include information indicating that the setting in the DU#2 has been completed.

[0275] In steps ST1009 and ST1010 shown in FIG. 10, random access processing is performed so that the UE communicates with the CU via the DU#2. In step ST1009, signaling is performed between the DU#2 and the CU, and in step ST1010, radio signals are transmitted and received between the UE and the DU#2. Step ST1009 may be a random access Msg3 from the DU#2 to the CU, or may be information from the DU#2 to the CU indicating that the random access processing has been completed. Also, step ST1009 may be a positive response or a negative response from the CU to the DU#2 in response to the random access Msg3 or the information indicating that the random access processing has been completed. This makes it possible to improve the reliability of notification of the random access Msg3 or the information indicating that the random access processing has been completed.

[0276] In step ST1010 shown in FIG. 10, signaling required to start transmitting and receiving duplicate packets using DUs #1 and #2 is completed.

[0277] Steps ST1011 to ST1017 shown in FIG. 11 show transmission and reception of downlink user data.

[0278] In step ST1011 shown in Fig. 11, user data is transferred from an upper network device to the CU. In step ST1012, the CU copies the PDCP-PDU including the user data.

[0279] As shown in Fig. 11, the CU transfers the duplicated user data to DU #1 and DU #2 in steps ST1013 and ST1014, respectively. In step ST1015, DU #1 transmits the user data to the UE. In step ST1016, DU #2 transmits the user data to the UE.

[0280] 11, the UE detects duplication of the user data received in steps ST1015 and ST 1016. Furthermore, the UE deletes the user data that has been received redundantly.

[0281] Steps ST1018 to ST1024 shown in FIG. 11 show transmission and reception of uplink user data.

[0282] In Step ST1018 shown in FIG. 11, the UE replicates the PDCP-PDU including the user data.

[0283] As shown in Fig. 11, the UE transmits the duplicated user data to DU #1 and DU #2 in steps ST1019 and ST1020, respectively. In step ST1021, DU #1 transfers the user data to the CU. In step ST1022, DU #2 transfers the user data to the CU.

[0284] 11, the CU detects duplication of the user data received in steps ST1021 and ST1022. Furthermore, the CU deletes the duplicated user data received.

[0285] In step ST1024 shown in FIG. 11, the CU transfers the received user data to the upper network device.

[0286] Steps ST1018 to ST1024, which show the transmission and reception of uplink user data, may be executed after steps ST1011 to ST1017, which show the transmission and reception of downlink user data, or may be executed simultaneously, thereby increasing the flexibility in the transmission and reception of user data.

[0287] In the examples of Figures 10 and 11, the sequence for starting transmission and reception of duplicate packets between the CU and the UE does not require signaling to an upper network device, for example, the Path Update Procedure described in Section 10.1.2.8.1 of Non-Patent Document 1.

[0288] In a sequence for starting transmission and reception of duplicate packets between a CU and a UE, for example, the CU may notify a DU communicating with the UE of a communication change instruction. The DU may notify the CU of a communication change instruction response. This makes it possible to flexibly change RRC parameters when adding a DU.

[0289] In the above-mentioned communication change instruction, the CU may also transmit to the DU an identifier indicating that the RLC, MAC, and PHY layers during communication are not to be initialized. This makes it possible to prevent communication interruption caused by discarding data associated with the initialization.

[0290] Figures 12 and 13 are diagrams showing other sequences for starting transmission and reception of duplicate packets in communication between a CU and a UE. Figures 12 and 13 are connected at the position of a boundary line BL1213. In Figures 12 and 13, the same step numbers are assigned to steps that are the same as those in Figures 10 and 11, and common explanations will be omitted.

[0291] In step ST1101 shown in FIG. 12, the CU notifies the DU#1 of a communication change instruction. The instruction may include an RRC parameter change instruction. In addition, an identifier indicating that each layer is not to be initialized may be added to the instruction. The DU#1 changes the RRC parameters for the UE by using the information received in step ST1101.

[0292] 12, the DU#1 notifies the CU of a response to the communication change instruction. The response includes information indicating that the setting in the DU#1 has been completed.

[0293] By using the sequences shown in Figs. 12 and 13, communication channels can be flexibly set in accordance with the addition of DUs.

[0294] In another sequence for starting transmission and reception of duplicate packets between a CU and a UE, the RRC connection re-establishment from the CU to the UE may be performed after the above-mentioned communication instruction start response. The above-mentioned RRC connection re-establishment may be performed when a positive response is received from the DU to be added in the above-mentioned communication instruction start response. This can prevent the RRC connection re-establishment from being re-established even if the DU fails to process the above-mentioned communication start command. Also, the time from the RRC connection re-establishment to the random access process in the UE can be shortened.

[0295] Figures 14 and 15 are diagrams showing a sequence for starting transmission and reception of duplicate packets between a CU and a UE, in which an RRC connection reconfiguration is performed after the above-mentioned communication instruction start response. Figures 14 and 15 are connected at the position of a boundary line BL1415. In Figures 14 and 15, the same step numbers are assigned to steps that are the same as those in Figures 10 and 11, and common explanations are omitted.

[0296] In steps ST1201 and ST1202 shown in Fig. 14, the CU notifies the UE of signaling for RRC connection reconfiguration. Steps ST1201 and ST1202 may be similar to steps ST1003 and ST1004 in Fig. 10. The UE uses the information received in step ST1202 to perform packet duplication and RRC parameter configuration for communication with DU#2.

[0297] In Steps ST1203 and ST1204 shown in Fig. 14, the UE transmits an RRC connection reconfiguration completion notification to the CU. Steps ST1203 and ST1204 may be similar to Steps ST1005 and ST1006 in Fig. 10.

[0298] 14, the CU notifies the DU#2 that the RRC connection re-setting with the UE has been completed. Using the notification, the DU#2 starts a random access process with the UE.

[0299] The sequence shown in Fig. 14 differs from the sequence shown in Fig. 10 in that step ST1201 is executed after step ST1008. This makes it possible to prevent retry of RRC connection re-establishment even if the process of the DU fails in response to the above-mentioned communication start instruction. Also, it is possible to shorten the time from RRC connection re-establishment to random access process in the UE.

[0300] As another example of a sequence for starting transmission and reception of duplicate packets in communication between a CU and a UE, the CU may instruct each DU and UE without waiting for a response from each DU and UE, which enables the process of adding a DU to be performed quickly.

[0301] Figures 16 and 17 are diagrams showing a sequence for starting transmission and reception of duplicate packets between a CU and a UE, in which a CU issues an instruction to each DU and UE without waiting for a response from each DU and UE. Figures 16 and 17 are connected at the position of a boundary line BL1617. In Figures 16 and 17, the same step numbers are assigned to steps that are the same as those in Figures 10 and 11, and common explanations are omitted.

[0302] In steps ST1301 and ST1302 shown in Fig. 16, the CU notifies the UE of signaling of RRC connection reconfiguration. Steps ST1301 and ST1302 may be similar to steps ST1003 and ST1004 in Fig. 10. The UE uses the information received in step ST1302 to perform packet duplication and RRC parameter configuration for communication with DU#2.

[0303] In Step ST1303 shown in Fig. 16, the CU notifies the DU#2 of a communication start instruction. Step ST1303 may be similar to Step ST1007 shown in Fig. 10. The DU#2 uses the information received in Step ST1303 to set RRC parameters for transmitting and receiving data to and from the UE.

[0304] In Step ST1304 shown in Fig. 16, the CU notifies the DU#1 of a communication change instruction. Step ST1304 may be similar to Step ST1101 shown in Fig. 12. The DU#1 changes the RRC parameters for the UE by using the information received in Step ST1304.

[0305] The order of steps ST1301, ST1303, and ST1304 shown in Fig. 16 may be different from each other, which allows flexibility in the operation of the CU.

[0306] The sequences shown in Figures 16 and 17 enable the CU to issue an instruction without waiting for a response from each DU and UE, thereby enabling the process of adding a DU to be performed quickly.

[0307] The CU may notify the DU of a communication stop instruction. The above-mentioned communication stop instruction may be issued when packet duplication is stopped. The DU may notify the CU of a communication stop instruction response. This allows communication to be continued smoothly before and after packet duplication is stopped.

[0308] The CU may notify the UE of RRC connection reconfiguration. The above-mentioned notification of RRC connection reconfiguration may be performed when packet duplication is stopped. The above-mentioned RRC connection reconfiguration may include information indicating the release of the DU. The UE may notify the CU of the completion of RRC connection reconfiguration. This allows communication to be smoothly continued before and after packet duplication is stopped. The above-mentioned RRC connection reconfiguration may include information indicating the release of packet duplication. Alternatively, the above-mentioned RRC connection reconfiguration may not include information indicating the release of packet duplication. This makes it possible to reduce the number of DUs used while maintaining packet duplication.

[0309] The CU may communicate the RRC connection reconfiguration to the UE using a non-released DU, which allows the RRC connection reconfiguration to be notified with high reliability. Alternatively, the CU may communicate the RRC connection reconfiguration using a released DU, which allows the overhead in the non-released DU to be reduced.

[0310] Fig. 18 is a diagram showing a sequence for stopping transmission and reception of a duplicated packet in communication between a CU and a UE. Fig. 18 shows an example of switching from communication by a duplicated packet using DU#1 and #2 to communication using DU#1.

[0311] Steps ST1401 to ST1407 shown in FIG. 18 represent user data communication using packet duplication. In step ST1401, user data is transmitted and received between an upper network device and a CU. In step ST1402, the CU performs packet duplication of downlink user data, detects duplicate packets of uplink user data, and deletes the duplicate packets. In steps ST1403 and ST1404, the CU and DUs #1 and #2 transmit and receive duplicated user data. In steps ST1405 and ST1406, the UE and DUs #1 and #2 transmit and receive duplicated user data. In step ST1407, the UE performs packet duplication of uplink user data, detects duplicate packets of downlink user data, and deletes the duplicate packets.

[0312] Steps ST1408 to ST1413 shown in FIG. 18 are signaling for stopping packet duplication.

[0313] In steps ST1408 and ST1409 shown in FIG. 18, the CU notifies the UE of signaling of RRC connection reconfiguration. The notification is transmitted from the CU to the DU #1 in step ST1408, and is also transmitted from the DU #1 to the UE in step ST1409. The notification includes information indicating the release of communication with the DU #2 and information indicating the stop of packet duplication. The notification may include information on the RRC parameters for the DU #1 opposite entity. The UE uses the information received in step ST1409 to perform RRC parameter setting for stopping packet duplication and releasing communication with the DU #2.

[0314] In steps ST1408 and ST1409 shown in Fig. 18, the notification from the CU to the UE may include information instructing a change in the RRC parameters in the communication with the DU #1. The UE may change the RRC parameter settings in the communication with the DU #1 by using the information received in step ST1409. This allows the CU to flexibly perform communication settings with the DU #1 following the release of the communication with the DU #2.

[0315] 18, the UE transmits an RRC connection reconfiguration completion notification to the CU. The notification is transmitted from the UE to the DU #1 in step ST1410, and from the DU #1 to the CU in step ST1411.

[0316] 18, the CU notifies the DU#2 of a communication stop instruction. The instruction includes information indicating that the use of the DU#2 in communication with the UE is to be stopped.

[0317] 18, the DU#2 notifies the CU of a communication stop instruction response. The response includes information indicating that the communication stop process in the DU#2 has been completed.

[0318] In steps ST1414 to ST1416 shown in FIG. 18, the CU and UE transmit and receive user data via DU#1. In step ST1414, user data is transmitted and received between an upper network device and the CU. In step ST1415, the CU and DU#1 transmit and receive user data. In step ST1416, the UE and DU#1 transmit and receive user data.

[0319] In Fig. 18, the stop of packet duplication indicated by steps ST1414 to ST1416 may be performed before or after the response to the communication stop instruction in step ST1413. By stopping packet duplication before the response to the communication stop instruction, unnecessary communication resources can be released early and communication can be performed efficiently. Also, by stopping packet duplication after the response to the communication stop instruction, the reliability of user data communication before and after the signaling for stopping packet duplication can be improved.

[0320] The CU may use a combination of the above-mentioned communication start instruction and the above-mentioned communication stop instruction. This combination may be used to switch the used DU. In the above, the CU may notify the UE of the RRC connection reconfiguration notification in one package. This makes it possible to smoothly switch the used DU and further reduce the amount of signaling.

[0321] The CU may add or remove the used DUs one by one. That is, the CU may notify each of the DUs of a communication start instruction or a communication stop instruction. This makes it easy to recover from a failure in the sequence of adding or removing a used DU.

[0322] Alternatively, the CU may add or delete the used DUs collectively. In the above, the CU may send a single RRC connection reconfiguration notification to the UE. This can reduce the amount of signaling.

[0323] In the communication of the C-Plane, the CU and the UE may communicate via a plurality of DUs as in the U-Plane. The packet duplication as in the U-Plane may be applied to the communication via the above-mentioned plurality of DUs. This makes it possible to improve the reliability of the signaling between the CU and the UE. The above-mentioned signaling may be NAS signaling, RRC signaling, or PDCP control PDU. This makes it possible to improve the reliability of the signaling in each layer.

[0324] Figures 19 and 20 are sequence diagrams for explaining switching of the used DU and communication using multiple DUs in the C-Plane. Figures 19 and 20 are connected at the position of the boundary line BL1920. Figures 19 and 20 show an example in which the used DUs are switched from DU#1 and DU#2 to DU#1 and DU#3. In Figures 19 and 20, the same step numbers are assigned to steps that are the same as those in Figure 18, and common explanations will be omitted.

[0325] Steps ST1500 to ST1505 shown in FIG. 19 show a sequence related to the signaling of RRC connection reconfiguration notified by the CU to the UE, more specifically, a sequence related to duplication and notification of the signaling packet. In step ST1500, the CU duplicates the signaling packet of the RRC connection reconfiguration generated by its own CU. The above-mentioned duplication may be performed in the PDCP layer. The above-mentioned signaling of the RRC connection reconfiguration may include information on a change of the DU used (switching to the use of DU#1 and DU#3 in the examples of FIG. 19 and FIG. 20) and information to enable packet duplication. In steps ST1501 and ST1502, the CU transfers the above-mentioned duplicated signaling to DU#1 and DU#2, respectively. In steps ST1503 and ST1504, DU#1 and DU#2 notify the UE of the above-mentioned signaling. In step ST1505, the UE performs duplication detection of the received signaling. In addition, the UE deletes duplicated signaling. The above-mentioned duplicate detection and deletion may be performed in the PDCP layer. The UE uses the above-mentioned signaling to change RRC parameters and change the DUs used.

[0326] Steps ST1506 to ST1511 shown in FIG. 19 show a sequence related to the signaling of the completion of RRC connection reconfiguration notified to the CU by the UE, more specifically, a sequence related to duplication and notification of the signaling packet. In step ST1506, the UE duplicates the signaling packet of the completion of RRC connection reconfiguration generated by the UE itself. The above-mentioned duplication may be performed in the PDCP layer. In steps ST1507 and ST1508, the UE transmits the above-mentioned duplicated signaling to DU#1 and DU#2, respectively. In steps ST1509 and ST1510, the DU#1 and DU#2 transfer the above-mentioned signaling to the CU. In step ST1511, the CU detects duplication of the received signaling. In addition, the CU deletes the duplicated signaling. The above-mentioned duplication detection and deletion may be performed in the PDCP layer. The CU recognizes that the UE has completed the RRC connection reconfiguration by using the above-mentioned signaling.

[0327] 20, the CU notifies the DU#2 of a communication stop instruction. The notification includes information indicating that the use of the DU#2 in communication with the UE is to be stopped.

[0328] 20, the DU#2 notifies the CU of a communication stop instruction response. The response includes information indicating that the communication stop process in the DU#2 has been completed.

[0329] In Step ST1517 shown in Fig. 20, the CU notifies the DU#3 of a communication start instruction. Step ST1517 may be similar to Step ST1007 shown in Fig. 10. The DU#3 uses the information received in Step ST1517 to set RRC parameters for transmitting and receiving data with the UE.

[0330] 20, the DU#3 notifies the CU of a response to the communication start instruction. The response may include information indicating that the setting in the DU#3 has been completed.

[0331] In steps ST1520 and ST1521 shown in Fig. 20, random access processing is performed so that the UE can communicate with the CU via the DU #3. In step ST1520, signaling is performed between the DU #3 and the CU, and in step ST1521, radio signals are transmitted and received between the UE and the DU #3. Steps ST1520 and ST1521 may be similar to steps ST1009 and ST1010 in Fig. 10.

[0332] In steps ST1520 and ST1521 shown in FIG. 20, signaling required for switching the DUs in use from DUs #1 and #2 to DUs #1 and #3 is completed.

[0333] Steps ST1525 to ST1531 shown in FIG. 20 show user data transmission and reception by packet duplication using DUs #1 and #3.

[0334] In step ST1525 shown in FIG. 20, user data is transmitted and received between an upper network device and the CU. In step ST1526, the CU duplicates downlink user data packets, detects duplicate packets of uplink user data, and deletes the duplicate packets. In steps ST1527 and ST1528, the CU and DU#1 and #3 transmit and receive the duplicated user data. In steps ST1529 and ST1530, the UE and DU#1 and DU#3 transmit and receive the duplicated user data. In step ST1531, the UE duplicates uplink user data packets, detects duplicate packets of downlink user data, and deletes the duplicate packets.

[0335] 20, the sequence of a communication start instruction and a communication start instruction response to DU #3 shown in steps ST1517 and ST1518 may be performed before a communication stop instruction to DU #2 shown in step ST1515. By performing a communication start instruction before a communication stop instruction, the random access process performed by the UE via DU #3 can be performed quickly.

[0336] 20, the sequence of a communication stop instruction and a communication stop instruction response with DU#2 shown in steps ST1515 and ST1516, and the sequence of a communication start instruction and a communication start instruction response with DU#3 shown in steps ST1517 and ST1518 may be performed before the RRC connection re-setting sequence shown in steps ST1500 to ST1505. This makes it possible to prevent the need to redo the RRC connection re-setting caused by a failure in the above-mentioned communication stop instruction or the above-mentioned communication start instruction.

[0337] The UE may notify the CU of the failure of the RRC connection reconfiguration. The notification may include a failure reason. The failure reason may be, for example, a lack of resources in the UE, an inability to communicate with the DU, or other reasons. The CU may proceed with the process using the failure reason. The process may be, for example, the use of another DU. This allows the CU and the UE to prevent the interruption of the sequence due to the failure of the RRC connection reconfiguration and the associated operation stop.

[0338] The UE and the CU may continue communication using parameters before the RRC connection reconfiguration notification. The above-mentioned communication may be continued when the UE notifies the CU of a failure in the RRC connection reconfiguration. In the above-mentioned communication, the UE may maintain the RRC_CONNECTED state. Also, the UE may not notify the CU of an RRC connection re-establishment request. This makes it possible to maintain the communication between the UE and the CU.

[0339] In the above, the notification of the RRC connection reconfiguration from the CU to the UE may include an identifier that specifies the UE's operation when the RRC connection reconfiguration fails. The identifier may include information on whether the RRC_CONNECTED state is maintained or not, or may include information indicating whether the UE needs to notify the CU of the RRC connection re-establishment request. This allows the UE to easily determine whether to continue communication when the RRC connection reconfiguration fails. Alternatively, the UE may determine the operation of the UE using an identifier indicating whether or not a packet is duplicated. This allows the number of bits in the signaling of the RRC connection reconfiguration to be reduced, and further allows the UE to easily determine whether to continue communication when the RRC connection reconfiguration fails.

[0340] The notification of RRC connection reconfiguration failure from the UE to the CU and the notification of RRC connection reconfiguration completion may be integrated into one notification. In the integrated notification, an identifier indicating the completion or failure of RRC connection reconfiguration may be provided. Alternatively, the identifier of the reason for RRC connection reconfiguration failure may include RRC connection reconfiguration completion. For example, the value 0 indicating the reason for failure may be assigned to RRC connection reconfiguration completion. This reduces the number of types of signaling, making processing easier in the UE and CU.

[0341] Figures 21 and 22 are sequence diagrams for explaining the operation when RRC connection reconfiguration fails. Figures 21 and 22 are connected at the position of the boundary line BL2122. Figures 21 and 22 show an example in which RRC connection reconfiguration for the CU and UE to communicate using DU#2 fails, and RRC connection reconfiguration for the CU and UE to communicate using DU#3 is completed. In Figures 21 and 22, the same step numbers are assigned to steps that are the same as those in Figures 10, 11, 19, and 20, and common explanations are omitted.

[0342] In steps ST1601 and ST1602 shown in FIG. 21, the UE notifies the CU of a failure of the RRC connection reconfiguration. The notification may include a reason for the failure. In the example of FIG. 21, the notification includes a reason for the failure that the UE cannot use DU#2. In the example of FIG. 21, the CU may include in the RRC connection reconfiguration instruction an instruction to use a DU other than DU#2 in the event of failure. Alternatively, the CU may include in the RRC connection reconfiguration instruction an instruction to use DU#2 again after a certain time has elapsed in the event of failure. This allows for flexible selection of a DU even when the RRC connection reconfiguration fails.

[0343] In steps ST1610 and ST1611 shown in Fig. 21, the CU notifies the UE of signaling for RRC connection reconfiguration. This notification is the same as steps ST1003 and ST1004 in Fig. 10, except for the content that the DU to be used is DU#3.

[0344] In Step ST1614 shown in Fig. 22, the CU notifies the DU#3 of a communication start instruction. Step ST1614 may be similar to Step ST1007 shown in Fig. 10. The DU#3 uses the information received in Step ST1614 to set RRC parameters for transmitting and receiving data to and from the UE.

[0345] 22, the DU#3 notifies the CU of a communication start instruction response. Step ST1615 may be similar to Step ST1008 in FIG.

[0346] In steps ST1616 and ST1617 shown in Fig. 22, random access processing is performed so that the UE can communicate with the CU via the DU #3. In step ST1616, signaling is performed between the DU #3 and the CU, and in step ST1617, radio signals are transmitted and received between the UE and the DU #3. Steps ST1616 and ST1617 may be similar to steps ST1009 and ST1010 in Fig. 10.

[0347] In step ST1617 shown in FIG. 22, signaling required to start transmitting and receiving duplicate packets using DUs #1 and #3 is completed.

[0348] The DU may send a notification of failure to start communication to the CU. The notification may include a reason for failure. The reason for failure may be, for example, one described in section 9.2.6 of non-patent document 15 (3GPP TS 36.423 v14.2.0), or may be another reason. This makes it possible to notify the reason for failure of the DU to start communication in the same way as the reason for failure in the conventional Xn interface, thereby making it possible to avoid complexity in the design of the CU. The CU may proceed with processing using the reason for failure. The processing may be, for example, the use of another DU. This makes it possible for the CU and UE to prevent interruption of the sequence due to failure of the communication start instruction to the DU, and the associated operation stop.

[0349] The notification of the failure of the communication start instruction from the DU to the CU and the notification of the response to the communication start instruction may be integrated into one notification. In the integrated notification, an identifier indicating the completion or failure of the communication start instruction may be provided. Alternatively, the response to the communication start instruction may be included in the identifier of the reason for the failure to start communication. For example, the value 0 indicating the reason for the failure may be assigned to the response to the communication start instruction. This reduces the number of types of signaling, making processing in the DU and CU easier.

[0350] Fig. 23 and Fig. 24 are sequence diagrams for explaining the operation when a communication start instruction fails. Fig. 23 and Fig. 24 are connected at the position of the boundary line BL2324. Fig. 23 and Fig. 24 show an example in which RRC connection re-setting for the CU and UE to communicate using DU#2 fails, and RRC connection re-setting for the CU and UE to communicate using DU#3 is completed. In Fig. 23 and Fig. 24, the same step numbers are assigned to steps that are the same as those in Figs. 10, 11, and 19 to 22, and common explanations are omitted.

[0351] In Step ST1701 shown in Fig. 23, the CU notifies the DU#2 of a communication start instruction. Step ST1701 may be similar to Step ST1007 shown in Fig. 10. The DU#2 attempts to set RRC parameters for transmitting and receiving data to and from the UE, using the information received in Step ST1701.

[0352] In step ST1702 shown in Fig. 23, DU#2 notifies the CU of a failure to start communication. The notification may include the reason for the failure. In the example of Fig. 23, DU#2 notifies the CU of a hardware failure as the reason for the failure. The CU may select another DU as a DU to be used, using the information received in step ST1702.

[0353] With the sequences shown in Figures 23 and 24, even if a communication start instruction from a CU to a DU fails, the CU can maintain communication with the UE by selecting another DU as the DU to be used.

[0354] As another example of the operation when the communication start instruction fails, the CU may notify the UE of the communication start instruction before the RRC connection re-establishment from the CU to the UE. For example, in Fig. 23 and Fig. 24, steps ST1701 and ST1614 indicating the start of communication may be performed before steps ST1003, ST1004, ST1610, and ST1611 indicating the RRC connection re-establishment. This makes it unnecessary to redo the RRC connection re-establishment due to the failure of the DU to start communication, and therefore makes it possible to reduce the amount of signaling. In the examples of Fig. 23 and Fig. 24, steps ST1003 and ST1004 indicating the RRC connection re-establishment and steps ST1005 and ST1006 indicating the completion of the RRC connection re-establishment are unnecessary.

[0355] The DU may notify the CU of the failure to stop communication. The DU may notify the CU after the CU issues a command to stop communication to the DU. The notification of the failure may be the same as the notification of failure to start communication. This can provide the same effect as the notification of failure to start communication.

[0356] The CU may stop user data communication with the UE via the DU. The stop may be performed for the DU that notified the CU of the failure to stop communication. This makes it possible to prevent unnecessary continuation of communication when the communication stop failure occurs.

[0357] The CU may continue user data communication with the UE via the DU. The continuation may be performed for the DU that notified the CU of the failure to stop communication. This makes it possible to maintain the reliability of communication even when the communication stop fails.

[0358] The DU may notify the CU of the failure of the communication change. The DU may notify the CU after the CU issues a command to change the communication to the DU. The notification of the failure may be the same as the notification of failure to start communication. This can provide the same effect as the notification of failure to start communication.

[0359] The CU may continue user data communication with the UE via the DU. The continuation may be performed for the DU that notified the CU of the communication change failure. The communication may be continued using the parameters before being changed by the above-mentioned communication change instruction. This makes it possible to maintain the reliability of the communication even when the communication change fails.

[0360] The CU may determine that the communication start instruction has failed when there is no response from the DU that has been instructed to start communication for a predetermined period of time. The aforementioned predetermined period may be set in advance by a standard, may be determined by the CU, or may be determined by an upper network device and notified to the CU. This makes it possible to prevent the operation of the CU from being stopped due to failure to receive a response to the communication start instruction from the DU.

[0361] As described above, the CU may determine that the communication stop instruction has failed when there is no response from the DU that instructed the communication to stop for a predetermined period of time. The CU may also determine that the communication change instruction has failed when there is no response from the DU that instructed the communication to change for a predetermined period of time. This makes it possible to prevent the operation of the CU from being stopped due to failure to receive a response to the communication stop instruction or a response to the communication change instruction from the DU.

[0362] Fig. 25 and Fig. 26 are sequence diagrams for explaining the operation when a communication start response from a DU to a CU does not reach the CU. Fig. 25 and Fig. 26 are connected at the position of a boundary line BL2526. Fig. 25 and Fig. 26 show an example of a case where there is no response from DU#2 to a CU for a certain period of time in response to a communication start instruction notified by the CU to DU#2. In Fig. 25 and Fig. 26, the same step numbers are assigned to steps that are the same as those in Fig. 23 and Fig. 24, and common explanations are omitted.

[0363] 25, the CU waits for a predetermined period for the DU #2 to respond to the communication start instruction notified to the DU #2 in step ST1701. In step ST1801, if there is no response from the DU #2 for a certain period, the CU determines that the communication start instruction has failed.

[0364] The sequences in FIGS. 25 and 26 prevent the operation of the CU from stopping while waiting for a response from DU#2, and make it possible, for example, to resend a communication start instruction to another DU.

[0365] The CU and the DU may transmit and receive data to each other for confirming the normal operation of the opposite entity. The CU and the DU may transmit and receive the data periodically. The CU and the DU may use the data to confirm the normal operation of the opposite entity. The CU may exclude a DU that does not transmit the data for a certain period of time from the used DU. Alternatively, the CU may exclude a DU that does not transmit the data for a certain period of time from the candidate DU. For example, the CU may exclude a DU that does not transmit the data for a certain period of time from the notification target of a communication start instruction, a communication stop instruction, or a communication change instruction. This makes it unnecessary for the CU to issue a communication start instruction, a communication stop instruction, or a communication change instruction to the DU. This makes it possible to prevent the occurrence of a failure sequence for the DU, and to delete unnecessary signaling from the CU to the DU.

[0366] The data for checking the normal operation of the opposite entity may include only the identifiers of the CU and the DU. This makes it possible to reduce the amount of signaling involved in checking the normal operation of the opposite entity.

[0367] The CU may notify the UE of the RRC connection reconfiguration. The notification may be performed using RRC signaling. The notification may use parameters shown in section 6.2.2 of non-patent document 16 (3GPP TS 36.311 v14.2.1). This makes it possible to avoid complexity in the design of the CU and the UE regarding the RRC connection reconfiguration notification.

[0368] The notification may include the following information (1) to (8).

[0369] (1) An identifier indicating a bearer, such as a bearer ID.

[0370] (2) Information regarding packet duplication, such as an identifier indicating whether a packet is duplicated or not.

[0371] (3) Information about the DU to be added.

[0372] (4) Information on the DU to be released.

[0373] (5) Information about the DU whose settings you want to change.

[0374] (6) Number of DUs used.

[0375] (7) An identifier indicating that the entity of each layer will not be re-established.

[0376] (8) A combination of (1) to (7) above.

[0377] In the above (1), for example, a bearer ID (DRB-ID) may be used. This allows for duplication of U-Plane packets. Also, an identifier (for example, SRB-ID) of a signaling radio bearer (abbreviated as SRB) may be used. The SRB-ID may be, for example, SRB0, SRB1, or SRB2. This allows for duplication of C-Plane packets.

[0378] In the above (2), for example, an identifier indicating whether or not a packet is duplicated may be included. This allows the UE to easily identify whether or not a packet is duplicated. Also, information regarding the duplicate packet transmission ratio to each DU may be included. This allows the ratio of duplicate packets to be flexibly changed in both uplink and downlink communications. Also, information regarding the priority of the PDCP-PDU received from each DU may be included. This allows the UE to reduce the amount of processing required for detecting duplicate PDCP-PDUs.

[0379] In the above (3), for example, the number of DUs to be added may be included. This allows the UE to easily grasp the setting parameters for the added DU on the RRC signaling, etc. Also, an identifier of the DU to be added may be included. The identifier of the DU may be the above-mentioned DU-ID or a cell ID. This allows the UE to easily identify the opposing DU. Also, RRC parameters for opposing the DU may be included. The above-mentioned RRC parameters may include parameters related to the New AS layer, the PDCP layer, the RLC layer, the MAC layer, or the PHY layer. This enables the establishment of communication between the UE and the DU.

[0380] In the above (4), for example, the number of DUs to be released may be included. This allows the UE to easily grasp parameters for the released DU on the RRC signaling, etc. Also, the ID of the DU to be released may be included. The DU identifier may be the same as the DU identifier in the above (3). This makes it possible to obtain the same effect as in the above (3). Also, an identifier indicating whether or not an inter-DU split bearer for the DU has been released may be included. This makes it possible to reduce the amount of processing required to reconfigure a DU that has been released once when an inter-DU split bearer is used in communication using multiple DUs.

[0381] In the above (5), for example, the number of DUs to be changed may be included. This allows the UE to easily grasp the setting parameters for the changed DU on the RRC signaling, etc. Also, an identifier of the DU to be changed may be included. The identifier of the DU may be the same as the identifier of the DU in the above (3). This makes it possible to obtain the same effect as in the above (3). Also, an RRC parameter for facing the DU may be included. The above RRC parameter may be the same as the RRC parameter in the above (3). This makes it possible to obtain the same effect as in the above (3).

[0382] In the above (6), by notifying the UE of the changed number of DUs from the CU, the UE can easily grasp the number of DUs in use after the RRC connection is reconfigured.

[0383] The layer indicated in (7) above may be the New AS layer, the PDCP layer, the RLC layer, the MAC layer, or the PHY layer. This makes it possible to prevent data loss by preventing buffer clearing due to re-establishment of entities in the above layers. Furthermore, it is possible to reduce delays in data transmission by preventing retransmission from upper layers of the UE.

[0384] In the above (7), entities of each layer may be re-established, which can reduce the amount of processing by the UE associated with the change of the RRC parameters.

[0385] The UE may notify the CU of the completion of the RRC connection reconfiguration. The notification may be performed using RRC signaling. The RRC connection reconfiguration completion notification shown in section 6.2.2 of non-patent document 16 (3GPP TS 36.311 v14.2.1) may be applied to the notification. This makes it possible to avoid complexity in the design of the CU and UE regarding the RRC connection reconfiguration completion notification.

[0386] Alternatively, the PDCP sequence number that the UE has received may be included in the RRC connection reconfiguration completion notification. This makes it possible to prevent data loss during RRC connection reconfiguration. The UE may notify the above-mentioned PDCP sequence number independently of the RRC connection reconfiguration completion notification. This makes it possible to avoid design complexity related to the RRC connection reconfiguration completion notification in the CU and the UE.

[0387] The failure reason may be included in the above-mentioned RRC connection reconfiguration completion notification in the first embodiment. The failure reason may be the above-mentioned failure reason included in the notification of RRC connection reconfiguration failure transmitted from the UE to the CU. The identifier indicating the above-mentioned failure reason may include RRC connection reconfiguration completion. For example, the case where the value indicating the failure reason is 0 may be assigned to RRC connection reconfiguration completion. This reduces the number of types of signaling, making processing in the UE and the CU easier.

[0388] The CU may notify the DU of a communication start instruction. The instruction may be sent using signaling on a CU-DU interface, for example, an Fs interface. The instruction may use parameters described in SeNB Addition Request in section 9.1.3.1 of non-patent document 15 (3GPP TS 36.423 v14.2.0). The instruction may use parameters used in SCG-ConfigInfo in section 10.2.2 of non-patent document 16 (3GPP TS 36.311 v14.2.1). This makes it possible to avoid complexity in the design of the CU and DU regarding the communication start instruction.

[0389] The above-mentioned instruction may include the following information (1) to (7).

[0390] (1) An identifier indicating a bearer, such as a bearer ID.

[0391] (2) Information regarding packet duplication, such as an identifier indicating whether a packet is duplicated or not.

[0392] (3) An identifier of the DU, for example, a DU-ID.

[0393] (4) An identifier of the UE, for example, a UE-ID.

[0394] (5) RRC parameters.

[0395] (6) An identifier indicating that the entity of each layer will not be re-established.

[0396] (7) A combination of (1) to (6) above.

[0397] In the above-mentioned (1), the same information as the above-mentioned information (1) in the RRC connection reconfiguration notification from the CU to the UE may be used. This provides the same effect as the above-mentioned information (1) in the RRC connection reconfiguration notification.

[0398] By using the above (2), the CU and DU can optimize the packet duplication process using the presence or absence of packet duplication.

[0399] By using the above-mentioned (3), it is possible to prevent malfunctions caused by other DUs mistakenly receiving and processing the instruction.

[0400] By using the above (4), the DU can identify the UE that is the counterpart entity of the communication indicated in the instruction.

[0401] The RRC parameters in (5) above may include parameters related to the RLC layer, the MAC layer, or the PHY layer, which enables the establishment of communication between the UE and the DU.

[0402] The layer indicated in (6) above may be the RLC layer, the MAC layer, or the PHY layer. This makes it possible to prevent data loss by preventing buffer clearing due to re-establishment of entities in the above layers. Furthermore, it is possible to reduce delays in data transmission by preventing retransmissions from the PDCP layer in the CU and UE.

[0403] In the above (6), entities of each layer may be re-established, which makes it possible to reduce the amount of processing by the DU associated with the change of the RRC parameters.

[0404] The DU may notify the CU of a response to the communication start instruction, which enables the CU to grasp the status of the DU, for example, whether or not the DU has a failure.

[0405] The response may include the following information (1) to (4).

[0406] (1) An identifier indicating a bearer, such as a bearer ID.

[0407] (2) An identifier of the DU, for example, a DU-ID.

[0408] (3) An identifier indicating the completion or failure of processing associated with a communication start instruction.

[0409] (4) A combination of (1) to (3) above.

[0410] According to the above (1), for example, when the DU is notified of a command to start communication for a plurality of bearers from the CU, the CU can easily identify the bearers to be set by the DU.

[0411] According to the above-mentioned (2), for example, when a CU issues a command to start communication to multiple DUs, the CU can easily identify the DU that sent the response.

[0412] In the above (3), an identifier indicating the reason for failure may be included. A value indicating that the process associated with the communication start instruction was successful may be added to the above identifier. The above value may be, for example, 0. This makes it possible to integrate the above communication start instruction response and the above communication start failure notification, thereby making it possible to reduce the types of signaling.

[0413] For communication between the CU and the DU, a CU-DU interface, for example, an Fs interface, may be used. The Fs interface may be 8-bit aligned. This allows the amount of padding to be reduced.

[0414] Alternatively, 64-bit alignment may be used for the Fs interface, which makes it easier to align data when communicating using 64b / 66b.

[0415] The Fs interface may be an interface between CU and DU that is based on the method defined in the CPRI (see Non-Patent Document 17). This makes it possible to standardize the interface between an option in which CU-DU separation is performed at a low layer and an option in which CU-DU separation is performed at a high layer (for example, option 2).

[0416] In the above, the control information may be arranged in a control block, and the data may be arranged in a data block, which makes it possible to improve the efficiency of communication in the Fs interface.

[0417] The Fs interface may have a collision avoidance function, which makes it possible to consolidate wiring between a CU and multiple DUs while ensuring low latency and high reliability.

[0418] The Fs interface may be an application of the method defined in the S1 interface as an interface between a CU and a DU. This makes it possible to avoid complexity in the design of the Fs interface.

[0419] The control information in the Fs interface may be common to the RRC signaling. This allows the CU and DU to easily convert between the RRC signaling and the control information on the Fs interface, thereby reducing processing time.

[0420] In the above, the DU may use the RRC signaling from the CU to the UE as setting information for the DU. This makes it possible to share the signaling from the CU to the DU (e.g., a communication start instruction) with the RRC signaling from the CU to the UE (e.g., an RRC connection reconfiguration notification). This makes it possible to reduce the amount of signaling.

[0421] The format of the control information in the Fs interface may be based on ASN.1, for example, which makes it possible to easily convert between the control information in the Fs interface and RRC signaling.

[0422] The technology described in the first embodiment for transmitting and receiving duplicate packets using multiple DUs may be applied to inter-DU mobility. In inter-DU mobility, the above-mentioned used DU addition and the above-mentioned used DU release may be combined. This makes it possible to ensure reliability before and after inter-DU mobility.

[0423] When applying the technology of transmitting and receiving duplicate packets using multiple DUs to inter-DU mobility, the CU may notify the UE of information indicating that C-Plane data is transmitted via the destination DU. The notification may be performed by using RRC signaling from the CU to the UE, for example, RRC connection reconfiguration. The RRC connection reconfiguration may be performed when a used DU is added in inter-DU mobility. This enables the UE to smoothly receive RRC signaling when a used DU is released in inter-DU mobility.

[0424] Alternatively, instead of the information indicating transmission via the destination DU, the CU may notify the UE of information indicating transmission via either the destination DU or the source DU. The CU may transmit RRC signaling when releasing a used DU in inter-DU mobility to the UE via either the destination DU or the source DU. For example, the CU may compare the destination DU and the source DU and use a DU with a good channel condition with the UE. The UE may be able to receive the RRC signaling from both the source DU and the destination DU. This allows the CU to use a DU with a good channel condition with the UE, for example, thereby improving the reliability of C-Plane data transmission.

[0425] Alternatively, instead of the information indicating transmission via the destination DU, the CU may notify the UE of information indicating transmission via both the destination DU and the source DU. The CU may transmit RRC signaling at the time of releasing a used DU in inter-DU mobility to the UE via both the destination DU and the source DU. The CU and UE may apply a technique for transmitting and receiving a duplicated packet of the C-Plane using multiple DUs to transmit and receive the signaling. The UE may be able to receive the RRC signaling from both the source DU and the destination DU. This makes it possible to further improve the reliability of C-Plane data transmission and reception during inter-DU mobility.

[0426] Figures 27 and 28 are diagrams showing the sequence of inter-DU mobility using a duplicated packet transmission / reception technique. Figures 27 and 28 are connected at the position of the boundary line BL2728. Figures 27 and 28 show an example in which communication between a CU and a UE switches from communication using DU#1 to communication using DU#1, #2 and packet duplication, and then switches to communication using DU#2. In Figures 27 and 28, the same step numbers are assigned to steps that are the same as those in Figures 10, 11, 14, and 15, and common explanations are omitted.

[0427] In step ST1904 shown in FIG. 27, the UE measures signals transmitted from DU #1 and DU #2. In steps ST1905 and ST1906, the UE notifies the CU of the measurement result. The notification may be performed using RRC signaling. In step ST1905, the UE transmits the measurement result to DU #1, and in step ST1906, the DU #1 transmits the measurement result to the CU. In step ST1907, the CU uses the measurement result to determine whether or not there is inter-DU mobility. In the example of FIG. 27, it is determined in step ST1907 that packet duplication using DU #1 and DU #2 will be performed.

[0428] In the sequence of steps ST1007, ST1008, ST1201 to ST1205, ST1009, and ST1010 shown in FIG. 27, DU#2 is added and packet duplication is set.

[0429] In steps ST1908 to ST1914 shown in Fig. 28, user data communication is performed by packet duplication using DU #1 and DU #2. Steps ST1908 to ST1914 are the same processes as steps ST1401 to ST1407 in Fig. 18, respectively.

[0430] In steps ST1915 to ST1917 shown in Fig. 28, the same processes as those in steps ST1904 to ST1906 described above are performed. In step ST1918, the CU judges the presence or absence of inter-DU mobility by using the measurement result in step ST1917. In the example of Fig. 28, it is judged in step ST1918 that communication will be performed using only DU#2.

[0431] 28, a communication stop instruction is sent from the CU to the DU #1, and a communication stop instruction response is sent from the DU #1 to the CU. Steps ST1919 and ST1920 may be similar to steps ST1412 and ST1413 in FIG. 18, respectively.

[0432] In steps ST1921 to ST1924 shown in Fig. 28, an RRC connection reconfiguration is performed from the CU to the UE, and an RRC connection reconfiguration completion notification is sent from the UE to the CU. In the example of Fig. 28, DU#1 release and packet deduplication are set. Step ST1921 shows an RRC connection reconfiguration transmission from the CU to the DU#2, step ST1922 shows an RRC connection reconfiguration transmission from the DU#2 to the UE, step ST1923 shows an RRC connection reconfiguration completion notification sent from the UE to the DU#2, and step ST1924 shows an RRC connection reconfiguration completion notification sent from the DU#2 to the CU.

[0433] 28, the CU notifies the DU#1 of the completion of UE reconfiguration. The DU#1 may use this notification to stop communication with the UE.

[0434] In steps ST1930 to ST1932 shown in Fig. 28, user data communication is performed using the DU #2. Step ST1930 shows user data transmission between an upper network device and a CU, step ST1931 shows user data transmission and reception between the CU and the DU #2, and step ST1932 shows user data transmission and reception between the DU #2 and a UE.

[0435] 27 and 28, the DU used in the measurement result notification may be the DU before movement. This makes it unnecessary to issue a DU change instruction, and therefore makes it possible to reduce the amount of signaling.

[0436] The technique of transmitting and receiving duplicate packets using a plurality of DUs described in the first embodiment may be applied to inter-CU mobility. In application to inter-CU mobility, for example, a Handover Request ACK from a destination base station to a source base station described in Non-Patent Document 1 may include an identifier of a DU used in the destination base station and an identifier indicating that packet duplication is to be performed. The same may be applied to an RRC connection reconfiguration notification from the source base station to the UE. This makes it possible to ensure reliability before and after inter-CU mobility.

[0437] According to the first embodiment, packet communication using multiple DUs becomes possible, so that high reliability and low delay in communication between a CU and a UE can be ensured.

[0438] According to the first embodiment, for example, the following configuration is provided.

[0439] A communication system is provided that includes a communication terminal device and a base station device configured to be able to wirelessly communicate with the communication terminal device. More specifically, the base station device includes a plurality of DUs (Distributed Units) that transmit and receive radio signals, and a CU (Central Unit) that controls the plurality of DUs. The CU copies a downlink packet addressed to the communication terminal device and transfers it to at least two of the plurality of DUs. The at least two DUs transmit the downlink packet acquired from the CU to the communication terminal device by radio signals. When the communication terminal device receives duplicate downlink packets, it deletes the duplicated downlink packets according to a predetermined downlink packet deletion criterion.

[0440] Here, the communication terminal device may transmit a copy of the uplink packet to be transmitted from the communication terminal device to two or more of the multiple DUs. In this case, when the base station device receives duplicate uplink packets, the base station device deletes the duplicate uplink packets according to a predetermined uplink packet deletion criterion.

[0441] The above configuration can be modified in various ways based on the disclosures and suggestions of this specification, including embodiment 1. According to the above configuration and modified configurations, the above problems can be solved and the above effects can be obtained.

[0442] Variation 1 of the first embodiment In the first embodiment, packet duplication in option 2 of CU-DU separation has been described, but packet duplication may also be applied to option 3-1 of CU-DU separation.

[0443] The CU copies a packet transferred from an upper network device. The CU may perform the packet copy in the PDCP layer. The CU transfers the copied packet to the RLC-H layer facing each DU. Each RLC-H layer transmits the packet to the facing DU. Each DU transmits the packet to the UE. The UE detects duplication of the packet. The UE deletes the duplicated packets.

[0444] The above-described operations of the CU, DU and UE may be performed for downlink communication.

[0445] The UE also copies packets and transmits the copies to each DU via the lower layer entities corresponding to each DU. Each DU transfers the received packets to the CU. The CU transfers the packets received from the DU to the PDCP layer. The PDCP layer of the CU performs duplication detection. The PDCP layer of the CU deletes duplicate packets. The CU transfers the packets that were not deleted to an upper network device.

[0446] The above-described operations of the CU, DU and UE may be performed for uplink communication.

[0447] Figure 29 is a diagram showing a configuration for duplicating packets of the PDCP layer in downstream communication using multiple DUs for CU-DU separation option 3-1. In Figure 29, the same blocks as in Figure 8 are assigned the same numbers, and common explanations will be omitted.

[0448] 29, the PDCP layer 809 transfers the PDCP-PDU#1 (PDCP-PDU 812) to the RLC-H layer 2001. In addition, the PDCP layer 809 transfers the PDCP-PDU#2 (PDCP-PDU 813) to the RLC-H layer 2002.

[0449] In Fig. 29, the RLC-H layer 2001 adds an RLC header 2005 to the PDCP-PDU#1 to generate an RLC-PDU#1 (sometimes referred to as an RLC-PDU2008). The RLC-H layer 2001 transfers the RLC-PDU#1 to the RLC-L layer 2012 of the DU#1 (DU802) using the Fs interface 814. Similarly, the RLC-H layer 2002 adds an RLC header 2006 to the PDCP-PDU#2 to generate an RLC-PDU#2 (sometimes referred to as an RLC-PDU2009). The RLC-H layer 2002 transfers the RLC-PDU#2 to the RLC-L layer 2013 of the DU#2 (DU803) using the Fs interface 815.

[0450] 29, the DU#1 transmits the RLC-PDU#1 received at the RLC-L layer 2012 to the DU#1 counterpart entity 2015 of the UE 804. The DU#2 transmits the RLC-PDU#2 received at the RLC-L layer 2013 to the DU#2 counterpart entity 2016 of the UE 804. The RLC-L layer 2017 transfers the received RLC-PDU#1 to the RLC-H layer 2020. The RLC-L layer 2018 transfers the received RLC-PDU#2 to the RLC-H layer 2021. The RLC-H layer 2020 acquires the PDCP-PDU#1 by deleting the RLC header 2005 from the RLC-PDU#1, and transfers the PDCP-PDU#1 to the PDCP layer 822. Similarly, the RLC-H layer 2021 obtains the PDCP-PDU#2 by removing the RLC header 2006 from the RLC-PDU#2, and transfers the PDCP-PDU#2 to the PDCP layer 822.

[0451] In FIG. 29, the operation of the PDCP layer 822 to detect packet duplication and delete the duplicate packets is the same as in FIG.

[0452] Other detailed operations are the same as those in the first embodiment, and therefore description thereof will be omitted. By applying the same method as in the first embodiment, the same effect as in the first embodiment can be obtained in the CU-DU separation option 3-1.

[0453] According to the first modification of the first embodiment, even if the CU-DU separation option 3-1 is used, high reliability and low latency of communication can be ensured by packet duplication.

[0454] Embodiment 2 In NR, it is proposed to quickly respond to changes in channel conditions while ensuring high reliability and low latency by performing packet duplication at a layer lower than the PDCP layer, i.e., the RLC layer or the MAC layer (see non-patent document 14 (3GPP R2-1701472)).

[0455] On the other hand, in the first modification of the first embodiment, in option 3-1 of CU-DU separation, a method is disclosed in which packets are duplicated in the PDCP layer and communication with the UE is performed using multiple subordinate DUs.

[0456] However, according to the first modification of the first embodiment, the RLC-H layer below the PDCP layer also exists in the CU, which causes problems such as an increase in the buffer usage in the RLC-H layer and an increase in the amount of processing in the PDCP layer and the RLC-H layer.

[0457] In the second embodiment, a method for solving such a problem will be disclosed.

[0458] The CU duplicates packets in the RLC-H layer. The RLC-H layer transfers the duplicated packets to the RLC-L layer of each DU. In the UE, the packets transmitted from each DU are received by the RLC-L layer facing each DU, and the RLC-H layer receives the packets from the RLC-L layer facing each DU. The RLC-H layer of the UE detects duplication of the packets. The RLC-H layer of the UE deletes the duplicate packets.

[0459] The above-described operations of the CU, DU and UE may be performed for downlink communication.

[0460] In addition, the UE duplicates packets in the RLC-H layer and transmits them to each DU via the RLC-L layer entities corresponding to each DU. The RLC-L layer of each DU forwards the received packets to the CU. The RLC-H layer of the CU performs duplication detection on packets received from the RLC-L layer of each DU. The RLC-H layer of the CU deletes duplicate packets. The RLC-H layer of the CU forwards packets that were not deleted to an upper network device via a higher layer.

[0461] The above-described operations of the CU, DU and UE may be performed for uplink communication.

[0462] The CU and / or UE may give duplicated packets the same RLC sequence number, which facilitates packet duplication detection at the receiving UE and / or CU.

[0463] The CU and / or UE may assign the RLC sequence numbers in a manner similar to the manner in which the PDCP sequence numbers are assigned in embodiment 1. This facilitates detection of duplicate packets in the receiving UE and / or CU, as in embodiment 1.

[0464] The first embodiment and the first modification of the first embodiment use PDCP sequence numbers, whereas the second embodiment uses RLC sequence numbers, which is different from the first embodiment and the first modification of the first embodiment. Also, the second embodiment differs from Non-Patent Document 14 in that a CU transmits and receives data to and from a UE using multiple subordinate DUs by packet duplication in the RLC-H layer.

[0465] Figure 30 is a diagram showing a configuration for duplicating packets of the RLC-H layer in downlink communication using multiple DUs for CU-DU separation option 3-1. In Figure 30, the same blocks as in Figure 29 are assigned the same numbers, and common explanations will be omitted.

[0466] 30, the PDCP layer 2104 adds a PDCP header 2100 to the PDCP-SDU 808 to generate a PDCP-PDU 2101. The PDCP layer 2104 transfers the PDCP-PDU 2101 to the RLC-H layer 2105.

[0467] In Fig. 30, the RLC-H layer 2105 copies the PDCP-PDU 2101 into two, adds an RLC header 2106 to one of the copied PDUs to generate an RLC-PDU#1 (sometimes called an RLC-PDU 2108), and adds an RLC header 2107 to the other copied PDU to generate an RLC-PDU#2 (sometimes called an RLC-PDU 2109). The RLC headers 2106 and 2107 contain the same sequence number #m information in Fig. 30, but may contain information of different sequence numbers. For example, making the sequence numbers of the RLC headers 2106 and 2107 consecutive makes it easier to design a sequence number assignment unit of the RLC layer.

[0468] 30, the RLC-H layer 2105 transfers the RLC-PDU#1 to the RLC-L layer 2012 of the DU#1 using the Fs interface 814. Also, the RLC-H layer 2105 transfers the RLC-PDU#2 to the RLC-L layer 2013 of the DU#2 using the Fs interface 815.

[0469] The RLC-L layer 2017 of the UE 804 transfers the received RLC-PDU #1 to the RLC-H layer 2110. The RLC-L layer 2018 of the UE 804 transfers the received RLC-PDU #2 to the RLC-H layer 2110.

[0470] In FIG. 30, the RLC-H layer 2110 detects duplicate packets. In the example of FIG. 30, the RLC-H layer 2110 detects that RLC-PDU#1 and RLC-PDU#2 are duplicated, and deletes RLC-PDU#2. The RLC-H layer 2110 acquires PDCP-PDU2101 by deleting the RLC header 2106 from RLC-PDU#1, and transfers the PDCP-PDU2101 to the PDCP layer 2111. The RLC-H layer 2110 deletes RLC-PDU#2 in the example of FIG. 30, but may delete RLC-PDU#1. In that case, the RLC-H layer 2110 acquires PDCP-PDU2101 by deleting the RLC header 2107 from RLC-PDU#2, and transfers the PDCP-PDU2101 to the PDCP layer 2111.

[0471] In FIG. 30, the PDCP layer 2111 deletes the PDCP header 2100 from the PDCP-PDU 2101 and transfers the resulting PDCP-SDU 808 to the New AS Layer 823 .

[0472] Other detailed operations are the same as those in the first embodiment, and therefore description thereof will be omitted. By applying the same method as in the first embodiment, the same effect as in the first embodiment can be obtained in the CU-DU separation option 3-1.

[0473] The second embodiment provides the same effects as the first modification of the first embodiment. Furthermore, compared to the first modification of the first embodiment, it is possible to reduce the amount of buffer usage in the RLC-H layer, so that it is possible to reduce the amount of buffering in the RLC-H layer. Furthermore, compared to the first embodiment and the first modification of the first embodiment, packet duplication and duplicate packet detection are performed in a lower layer, so that packet processing in the CU and UE becomes faster.

[0474] According to the second embodiment, similarly to the first embodiment, for example, the following configuration is provided.

[0475] A communication system is provided that includes a communication terminal device and a base station device configured to be able to wirelessly communicate with the communication terminal device. More specifically, the base station device includes a plurality of DUs (Distributed Units) that transmit and receive radio signals, and a CU (Central Unit) that controls the plurality of DUs. The CU copies a downlink packet addressed to the communication terminal device and transfers it to at least two of the plurality of DUs. The at least two DUs transmit the downlink packet acquired from the CU to the communication terminal device by radio signals. When the communication terminal device receives duplicate downlink packets, it deletes the duplicated downlink packets according to a predetermined downlink packet deletion criterion.

[0476] Here, the communication terminal device may transmit a copy of the uplink packet to be transmitted from the communication terminal device to two or more of the multiple DUs. In this case, when the base station device receives duplicate uplink packets, the base station device deletes the duplicate uplink packets according to a predetermined uplink packet deletion criterion.

[0477] The above configuration can be modified in various ways based on the disclosures and suggestions of this specification, including embodiment 2. According to the above configuration and modified configurations, the above problems can be solved and the above effects can be obtained.

[0478] Embodiment 3 In the first embodiment, the first variation of the first embodiment, and the second embodiment, a method for ensuring low latency and high reliability by duplicating packets and transmitting / receiving the packets using a plurality of DUs has been disclosed.

[0479] Even when mobility between DUs occurs, the reliability of data transmission and reception before and after the mobility between DUs can be ensured by using the packet duplication described above.

[0480] However, in the above, packet duplication causes a problem of consuming a large amount of radio resources and buffers of the DUs under the CU.

[0481] In the third embodiment, a method for solving such a problem will be disclosed.

[0482] The DU notifies the CU of information on the PDCP sequence number. The DU notifies the CU of the sequence number of the PDCP-PDU for which the DU has received HARQ delivery confirmation as the aforementioned PDCP sequence number. The CU transmits PDCP-PDUs that do not correspond to the PDCP sequence number to the DU.

[0483] The above-mentioned operation may be performed when inter-DU mobility occurs. For example, the DU that notifies the CU of the information of the PDCP sequence number may be the source DU. Also, the DU to which the CU transmits a PDCP-PDU that does not correspond to the above-mentioned PDCP sequence number may be the destination DU. This makes it possible to retransmit, from the CU to the destination DU, a PDCP-PDU for which the delivery confirmation from the source DU to the UE has not been obtained when inter-DU mobility occurs. This makes it possible to prevent PDCP-PDU loss during inter-DU mobility. Also, it becomes possible to quickly perform the above-mentioned PDCP-PDU retransmission.

[0484] Moreover, the above-mentioned operation may be performed when inter-DU mobility does not occur. For example, the DU that notifies the CU of the information of the PDCP sequence number may be the same as the DU to which the CU transmits the PDCP-PDU that does not correspond to the above-mentioned PDCP sequence number. As an application to the case where inter-DU mobility does not occur, for example, when the HARQ maximum retransmission count is exceeded, the DU may notify the CU of the PDCP-PDUPDCP sequence number included in the transport block data that has exceeded the HARQ retransmission count. This enables, for example, the CU to quickly retransmit the PDCP-PDU included in the transport block data that has exceeded the HARQ retransmission count to the DU.

[0485] The DU may notify the above-mentioned PDCP sequence number using a CU-DU interface, for example, an Fs interface. As in the first embodiment, the notification by the Fs interface may be, for example, a method defined in the S1 interface applied as a CU-DU interface. This makes it possible to avoid complexity in the design of the Fs interface. Also, for example, by transmitting the above-mentioned PDCP sequence number as control information of the Fs interface, it becomes possible to notify with little overhead.

[0486] Non-Patent Document 18 (3GPP R2-1701461) proposes retransmission control in the PDCP layer as PDCP ARQ, but the third embodiment differs from Non-Patent Document 18 in that it does not require feedback of the PDCP sequence number from the receiving side.

[0487] In applying the third embodiment to inter-DU mobility, the same conditions as those for conventional inter-base station mobility may be used as the generation conditions for inter-DU mobility. For example, the condition described in Non-Patent Document 12, that is, the condition that the difference in signal to noise ratio (abbreviated as SNR) is equal to or greater than a certain threshold or equal to or less than a certain threshold, may be applied, and the difference in SNR between DUs may be used. This makes it possible to avoid the complexity of processing inter-DU mobility.

[0488] The PDCP sequence number used in the third embodiment may be determined using the HARQ-ACK from the UE. This enables delivery confirmation in the PDCP layer even when the PDCP layer or the RLC layer uses RLC-UM, which does not use feedback from the opposite entity for delivery confirmation.

[0489] The above-mentioned PDCP sequence number may be the PDCP sequence number of the earliest transmitted PDCP-PDU among the PDCP-PDUs for which delivery confirmation has not been obtained in the HARQ. The CU may transfer the PDCP-PDU with that PDCP sequence number to the destination DU. This eliminates the need for the CU to increment the PDCP sequence number, making it possible to reduce the amount of processing in the CU.

[0490] Alternatively, the PDCP sequence number may be the last PDCP sequence number of consecutive PDCP-PDUs for which HARQ delivery confirmation has been obtained in the DU, which makes it possible to reduce the amount of signaling from the DU to the CU.

[0491] Alternatively, the source DU may notify the CU of the delivery status of the PDCP-PDU in the form of, for example, a bitmap as information indicating the above-mentioned PDCP sequence number. This allows the CU to efficiently retransmit the PDCP-PDUs for which delivery confirmation has not been obtained to the destination DU, for example, when the PDCP-PDUs for which delivery confirmation has not been obtained are intermittent.

[0492] Alternatively, the information indicating the PDCP sequence number may be, for example, a combination of the PDCP sequence number of the latest transmitted PDCP-PDU among the acknowledged PDCP-PDUs and the sequence number of the PDCP-PDU before the PDCP sequence number for which the acknowledgement has not been received. This enables the CU to efficiently retransmit the PDCP-PDU for which the acknowledgement has not been received to the destination DU while suppressing the amount of signaling for notifications from the source DU to the CU.

[0493] Alternatively, the information indicating the PDCP sequence number may be, for example, a combination of the PDCP sequence number of the earliest transmitted PDCP-PDU among unacknowledged PDCP-PDUs and the sequence number of the PDCP-PDU whose delivery has been acknowledged after the PDCP sequence number. This makes it possible to obtain the same effect as described above, particularly when there are few PDCP-PDUs whose delivery has been acknowledged.

[0494] Alternatively, the information indicating the above-mentioned PDCP sequence number may be the sequence number of a PDCP-PDU including data that is not scheduled in the HARQ layer of the source DU. This enables the CU and DU to respond quickly when inter-DU mobility occurs.

[0495] The DU may associate the HARQ-ACK information received from the UE with the PDCP-SN information. This association should be performed at all times while the DU and UE are communicating. This makes it possible to quickly notify the CU of the PDCP sequence number when inter-DU mobility occurs.

[0496] An example of the above-mentioned method of associating HARQ-ACK information with PDCP-SN information is disclosed below.

[0497] The RLC layer of the DU obtains the PDCP sequence number from the PDCP-PDU received from the PDCP layer of the CU. The RLC layer of the DU associates the above-mentioned PDCP sequence number with the RLC sequence number of the RLC-PDU that the RLC layer transmitted to the MAC layer by using the PDCP-PDU.

[0498] The MAC layer of the DU obtains the RLC sequence number from the RLC-PDU received from the RLC layer. The MAC layer of the DU associates the RLC sequence number with the HARQ process number used when the MAC layer transmits the RLC-PDU to the UE as transport block data.

[0499] The MAC layer of the DU acquires the HARQ process number for which delivery confirmation has been obtained, using the HARQ-ACK information from the UE. The MAC layer of the DU acquires the RLC sequence number for which delivery confirmation has been obtained, using the HARQ process number and the above-mentioned information on the correspondence between the RLC sequence number and the HARQ process number. The MAC layer of the DU notifies the RLC layer of the RLC sequence number information of the DU.

[0500] The RLC layer of the DU obtains the PDCP sequence number for which delivery has been confirmed, using the RLC sequence number information notified from the MAC layer of the DU and the aforementioned information relating to the correspondence between the PDCP sequence number and the RLC sequence number.

[0501] The above-mentioned association method makes it possible to quickly confirm the delivery of PDCP-PDUs without feedback information from the UE for the RLC layer and the PDCP layer.

[0502] When the DU notifies the CU of the PDCP sequence number for which delivery confirmation has not been obtained, the RLC layer of the DU may obtain the PDCP sequence number for which delivery confirmation has not been obtained by using the PDCP sequence number obtained by its own RLC layer from the PDCP-PDU and the above-mentioned PDCP sequence number for which delivery confirmation has been obtained. For example, the PDCP sequence number for which delivery confirmation has not been obtained may be the PDCP sequence number obtained by excluding the PDCP sequence number for which delivery confirmation has been obtained from the PDCP sequence number obtained from the PDCP-PDU. This makes it possible to quickly notify the DU of the information on the PDCP sequence number for which delivery confirmation has not been obtained to the CU.

[0503] In non-patent document 19 (3GPP R2-1700177), HARQ-NACK from UE is used for RLC layer delivery confirmation. In contrast, the present embodiment 3 differs from non-patent document 19 in that delivery confirmation is performed using HARQ-ACK. Also, it differs from non-patent document 19 in that delivery confirmation is performed in the PDCP layer by associating the RLC sequence number with the PDCP sequence number.

[0504] When inter-DU mobility occurs, the source DU may stop transmission after transmitting data stored in the buffer of the DU to the UE. The data may be HARQ retransmission data. Alternatively, the data may include unscheduled data stored in the RLC buffer. This makes it possible to increase the reliability of transmission of data stored in the buffer of the DU.

[0505] Alternatively, when inter-DU mobility occurs, the source DU may stop transmitting data stored in the buffer of the DU without transmitting the data to the UE. This makes it possible to quickly complete inter-DU mobility.

[0506] Fig. 31 shows a configuration for performing PDCP delivery confirmation using HARQ-ACK. Fig. 31 shows an example in which the DU used by the CU and UE is switched from DU#1 to DU#2. In Fig. 31, the same blocks as those in Fig. 8 and Fig. 30 are assigned the same numbers, and common explanations are omitted.

[0507] 31, the RLC layer 2202 in DU#1 (DU802) acquires a PDCP sequence number from the PDCP-PDU acquired from the PDCP layer 2201 in the CU801. The RLC layer 2202 transfers an RLC-PDU generated using the PDCP-PDU to the MAC layer 2203, and manages the RLC sequence number of the RLC-PDU in association with the PDCP sequence number.

[0508] 31, the MAC layer 2203 obtains an RLC sequence number from the RLC-PDU. The MAC layer 2203 transmits transport block data generated using the RLC-PDU to the UE 804, and manages the HARQ process number used to transmit the transport block data in association with the RLC sequence number.

[0509] 31, it is assumed that the MAC layer 2210 in the UE 804 correctly receives user data (a transport block generated using the RLC-PDU 2215) from the MAC layer 2203 in DU#1. The MAC layer 2210 notifies the MAC layer 2203 in DU#1 of HARQ-ACK information 2205.

[0510] 31, the MAC layer 2203 in DU#1 obtains the HARQ process number that resulted in the HARQ-ACK from the HARQ-ACK information 2205. The MAC layer 2203 obtains the RLC sequence number for which delivery confirmation has been obtained by using the HARQ process number and the above-mentioned correspondence between the HARQ process number and the RLC sequence number. The MAC layer 2203 transmits the RLC sequence number to the RLC layer 2202 as an RLC sequence number notification 2206.

[0511] In FIG. 31, the RLC layer 2202 acquires the PDCP sequence number for which delivery has been confirmed, using the RLC sequence number notification 2206 and the above-mentioned association between the RLC sequence number and the PDCP sequence number.

[0512] In FIG. 31, the RLC layer 2202 and the MAC layer 2203 may update the RLC sequence number for which delivery has been confirmed and the PDCP sequence number for which delivery has been confirmed as needed, using HARQ-ACK information from the MAC layer 2210 of the UE 804. This allows the DU #1 to quickly notify the CU of the PDCP sequence number when inter-DU mobility occurs. Alternatively, the above-mentioned update may be performed when inter-DU mobility occurs. This allows the amount of processing in the RLC layer 2202 and the MAC layer 2203 to be reduced.

[0513] 31, it is assumed that inter-DU mobility occurs from DU #1 to DU #2 when the PDCP sequence number for which delivery confirmation has been obtained is n. When inter-DU mobility occurs from DU #1 to DU #2, the RLC layer 2202 transmits the PDCP sequence number n for which delivery confirmation has been obtained as a PDCP sequence number notification 2207 to the PDCP layer 2201 of the CU 801. The Fs interface 814 is used for this transmission.

[0514] 31, the PDCP layer 2201 transmits a PDCP-PDU 2211 having a PDCP sequence number (for example, n+1) for which delivery confirmation has not been received, to DU#2 (DU 803), using a PDCP sequence number notification 2207. The Fs interface 815 is used for this transmission.

[0515] The configuration shown in FIG. 31 enables the PDCP layer 2201 to quickly retransmit to the UE 804, using DU #2, a PDCP-PDU that the UE has not correctly received when mobility occurs from DU #1 to DU #2.

[0516] Figures 32 to 34 are diagrams showing sequences related to mobility in which PDCP delivery confirmation is performed using HARQ-ACK. Figures 32 to 34 are connected at the positions of borders BL3233 and BL3334. Figures 32 to 34 show an example in which the DU used by the CU and UE is switched from DU#1 to DU#2. In Figures 32 to 34, the same step numbers are assigned to steps that are the same as those in Figures 27 and 28, and common explanations will be omitted.

[0517] In Step ST2301 shown in FIG. 32, the CU transmits a PDCP-PDU of user data for the UE to the DU #1. In Step ST2302, the RLC layer of the DU #1 acquires a PDCP sequence number (PDCP-SN) from the PDCP-PDU of Step ST2301. In Step ST2303, the DU #1 transmits the user data of Step ST2301 to the UE.

[0518] In step ST2304 shown in FIG.32, the UE notifies the MAC layer of the DU #1 of HARQ-ACK information. In step ST2305, the MAC layer of the DU #1 updates the delivery acknowledgement HARQ-ID using the HARQ-ACK information of step ST2304. In step ST2306, the MAC layer of the DU #1 updates the delivery acknowledgement RLC sequence number using the HARQ-ID and notifies the RLC layer of the DU #1 of the RLC sequence number. In step ST2307, the RLC layer of the DU #1 updates the delivery acknowledgement PDCP sequence number using the RLC sequence number.

[0519] In steps ST1904 to ST1906 and ST2315 shown in Fig. 32, the UE measures DU #1 and DU #2, the UE notifies the CU of the measurement result, and the CU decides inter-DU mobility. In the example of Fig. 32, it is decided in step ST2315 that mobility from DU #1 to DU #2 will be performed.

[0520] In Step ST2320 shown in Fig. 33, the DU #1 notifies the CU of information on the delivery acknowledgement PDCP sequence number updated in Step ST2307. The notification in Step ST2320 may be performed together with the communication stop instruction response in Step ST1920. This makes it possible to reduce the amount of signaling from the DU #1 to the CU.

[0521] In steps ST2325 and ST2326 shown in Fig. 33, an RRC connection reconfiguration notification is sent from the CU to the UE via DU #1. In steps ST2325 and ST2326, the CU instructs the UE to switch from DU #1 to DU #2. In steps ST2327 and ST2328, an RRC connection reconfiguration completion notification is sent from the UE to the CU via DU #1.

[0522] The switching from DU #1 to DU #2 is completed by steps ST1205, ST1925, ST1009, and ST1010 shown in FIG.

[0523] In Step ST2341 shown in Fig. 34, the CU transmits a PDCP-PDU having an unconfirmed PDCP sequence number to DU#2, by using the PDCP sequence number information notification of Step ST2320. Fig. 34 shows an example in which the PDCP-PDU having an unconfirmed PDCP sequence number is a PDCP-PDU having a PDCP sequence number later than the PDCP sequence number in Step ST2320.

[0524] In steps ST2342 to ST2347 shown in FIG. 34, the same processes as those in steps ST2302 to ST2307 are performed in DU#2.

[0525] 32 to 34, the notification of the PDCP sequence number information in Step ST2320 may be performed after Step ST1925, that is, after the CU notifies DU#1 of the completion of UE reconfiguration. This enables DU#1 to notify the CU of the PDCP sequence number for which delivery has been confirmed immediately before the DU switching. This makes it possible to reduce duplication of PDCP-PDU transmission.

[0526] As another example of a mobility sequence for confirming PDCP delivery using HARQ-ACK, the UE may determine the mobility, which eliminates the need for measurement result notification and thus reduces the amount of signaling in the radio interface.

[0527] In FIG. 33, after the notification of the completion of UE reconfiguration shown in step ST1925, DU#1 may transmit data stored in the buffer of its own DU to the CU. The data may include HARQ retransmission data, or may include data stored in the RLC buffer, i.e., data for which HARQ scheduling has not been completed. This makes it possible to improve the reliability of data transmission when inter-DU mobility occurs.

[0528] Alternatively, in FIG. 33, after the notification of the completion of UE reconfiguration shown in Step ST1925, DU#1 may discard the data stored in the buffer of its own DU. This makes it possible to quickly perform inter-DU mobility.

[0529] Figures 35 to 37 are diagrams showing other sequences related to mobility in which PDCP delivery confirmation is performed using HARQ-ACK. Figures 35 to 37 are connected at borders BL3536 and BL3637. In the examples of Figures 35 to 37, mobility is determined in the UE. In Figures 35 to 37, the same step numbers are assigned to steps that are the same as those in Figures 32 to 34, and common explanations will be omitted.

[0530] In Step ST2410 shown in Fig. 35, the UE determines mobility using the measurement result in Step ST1904. In the examples of Figs. 35 to 37, switching from DU #1 to DU #2 is performed. In Steps ST2411 and ST2412, the UE transmits an inter-DU mobility request to the CU. In Step ST2411, the UE transmits an inter-DU mobility request to DU #1, and in Step ST2412, the UE transmits an inter-DU mobility request from DU #1 to the CU.

[0531] The sequences shown in FIGS. 35 to 37 make it possible to reduce the amount of signaling required for notifying measurement results.

[0532] The third embodiment may be applied to a PDCP-PDU that does not have a PDCP sequence number. In the above, for example, a special number may be provided for the PDCP sequence number, and the special number may be assigned to a PDCP-PDU that does not have a PDCP sequence number. The PDCP-PDU that does not have a PDCP sequence number may be, for example, a PDCP control PDU. This makes it possible to improve the reliability of delivery of a PDCP control PDU associated with inter-DU mobility.

[0533] The method shown in the third embodiment may be used in a situation where mobility does not occur. For example, when the maximum number of HARQ retransmissions is exceeded, the DU may notify the CU of the PDCP sequence number of the PDCP-PDU included in the transport block that has exceeded the maximum number of retransmissions. The CU may retransmit the PDCP-PDU with that PDCP sequence number to the DU. This makes it possible to prevent packet loss due to an excess number of HARQ retransmissions and to quickly retransmit the PDCP-PDU.

[0534] An example of detailed operations when the method shown in the third embodiment is applied to the above-mentioned PDCP sequence number notification from the DU to the CU when the maximum number of HARQ retransmissions is exceeded will be disclosed below.

[0535] The MAC layer of the DU may obtain the RLC sequence number including the transport block that exceeded the maximum number of HARQ retransmissions by using the HARQ process number used when transmitting the transport block that exceeded the maximum number of HARQ retransmissions and the aforementioned information on the correspondence between the RLC sequence number and the HARQ process number.

[0536] The RLC layer of the DU acquires the PDCP sequence number of the PDCP-PDU including the transport block that has exceeded the maximum number of HARQ retransmissions, using the information of the RLC sequence number notified from the MAC layer of the DU and the above-mentioned information of the correspondence between the PDCP sequence number and the RLC sequence number. The RLC layer of the DU notifies the CU of the PDCP sequence number.

[0537] The method shown in the third embodiment may be applied to mobility between secondary base stations. By replacing the CU, source DU, and destination DU in the third embodiment with the master base station, source secondary base station, and destination secondary base station, respectively, application to mobility between secondary base stations is possible. This makes it possible to ensure low latency and reliability in mobility between secondary base stations.

[0538] The method shown in the third embodiment may be applied to mobility during C-Plane data transfer. The C-Plane data may be, for example, NAS data. The C-Plane data transfer is different from the U-Plane in that the CU and the UE do not have a New AS Layer. For example, in the example of FIG. 31, the CU 801 does not have a New AS Layer 807, and a packet 806 is directly transmitted from the upper network device 805 to the PDCP 2201. Also, the UE 804 does not have a New AS Layer 823, and a PDCP-SDU 2225 is directly transmitted from the PDCP layer 2220 to the upper layer 824.

[0539] By applying the method shown in the third embodiment to mobility during C-Plane data transfer, it is possible to improve the reliability of NAS data transmission when inter-DU mobility occurs, for example.

[0540] Although the third embodiment has been described with respect to downlink communication, the third embodiment may be applied to uplink communication. Specifically, the PDCP layer of the CU is replaced with the PDCP layer of the UE, the RLC layer and the MAC layer of the DU are replaced with the RLC layer and the MAC layer of the UE, respectively, and the MAC layer of the UE is replaced with the MAC layer of the DU, thereby making it possible to apply the third embodiment to uplink communication. This makes it possible to ensure reliability in uplink communication without packet duplication.

[0541] In the third embodiment, the source DU may transfer the above-mentioned PDCP-PDU to the destination DU. The PDCP-PDU may be a PDCP-PDU including transport block data for which the source DU has not received HARQ delivery confirmation. This makes it possible to reduce the amount of data transferred between the CU and the DU, since the data to be transferred from the CU to the destination DU is transferred from the source DU to the destination DU.

[0542] An inter-DU interface may be provided for the transfer from the source DU to the destination DU described above. The source DU may use the inter-DU interface to transfer the PDCP-PDU to the destination DU. This enables communication between DUs.

[0543] In the above-mentioned DU-to-DU interface, the method specified in the X2 / Xn interface may be applied as the DU-to-DU interface. For example, a new message called MOBILITY DATA TRNSFER may be provided to transfer the above-mentioned PDCP-PDU. This makes it possible to avoid complexity in the design of the DU-to-DU interface. In addition, since the same processing as that for base station communication in DC can be applied, the amount of processing at the base station can be reduced.

[0544] The method shown in the third embodiment may be applied to a base station and a UE that communicate using RLC-AM. This makes it possible to perform retransmission control more quickly than with the conventional RLC ARQ.

[0545] The method shown in the third embodiment makes it possible to ensure reliability and low latency while suppressing resource usage due to packet duplication.

[0546] According to the third embodiment, for example, the following configuration is provided.

[0547] A communication system is provided that includes a communication terminal device and a base station device configured to be able to wirelessly communicate with the communication terminal device. More specifically, the base station device includes a plurality of DUs (Distributed Units) that transmit and receive radio signals, and a CU (Central Unit) that controls the plurality of DUs. The CU acquires delivery completion information on packets that have been delivered to the communication terminal device from a DU connected to the communication terminal device. The CU transmits packets that are not indicated in the delivery completion information from the DU or another DU to the communication terminal device.

[0548] Here, in the third embodiment, an example has been disclosed in which the delivery completion information is the sequence number of the packet notified of delivery completion by the communication terminal device. However, the delivery completion information is not limited to this example.

[0549] The above configuration can be modified in various ways based on the disclosures and suggestions of this specification, including embodiment 3. According to the above configuration and modified configurations, the above problems can be solved and the above effects can be obtained.

[0550] Variation 1 of embodiment 3 In the third embodiment, an example has been described in which PDCP delivery acknowledgement is performed using HARQ-ACK in CU-DU separation option 2. PDCP delivery acknowledgement using HARQ-ACK may be applied to CU-DU separation option 3-1.

[0551] The DU notifies the CU of information on the RLC sequence number. The DU notifies the CU of the sequence number of the RLC-PDU for which the HARQ delivery confirmation has been obtained in the DU as the above-mentioned RLC sequence number. The CU transmits the RLC-PDU that does not correspond to the RLC sequence number to the DU.

[0552] The present first modification differs from the third embodiment in that an RLC sequence number is used instead of a PDCP sequence number.

[0553] Fig. 38 is a diagram showing a configuration for performing RLC delivery confirmation using HARQ-ACK for CU-DU separation option 3-1. In Fig. 38, the same blocks as those in Fig. 31 are assigned the same numbers, and common explanations will be omitted.

[0554] 38, the RLC-L layer 2501 in the DU #1 (DU 802) obtains an RLC sequence number from the RLC-PDU obtained from the RLC-H layer 2502 in the CU 801. The RLC-L layer 2501 transfers the RLC-PDU to the MAC layer 2203.

[0555] 38, the MAC layer 2203 obtains an RLC sequence number from the RLC-PDU. The MAC layer 2203 transmits transport block data generated using the RLC-PDU to the UE 804, and manages the HARQ process number used to transmit the transport block data in association with the RLC sequence number.

[0556] 38, it is assumed that the MAC layer 2210 in the UE 804 correctly receives user data (a transport block generated using the RLC-PDU 2504) from the MAC layer 2203 in DU #1. The MAC layer 2210 notifies the MAC layer 2203 in DU #1 of HARQ-ACK information 2205.

[0557] 38, the MAC layer 2203 in DU#1 obtains the HARQ process number that resulted in the HARQ-ACK from the HARQ-ACK information 2205. The MAC layer 2203 obtains the RLC sequence number for which delivery confirmation has been obtained by using the HARQ process number and the above-mentioned correspondence between the HARQ process number and the RLC sequence number. The MAC layer 2203 transmits the RLC sequence number to the RLC-L layer 2501 as an RLC sequence number notification 2206.

[0558] In FIG. 38, the RLC-L layer 2501 and the MAC layer 2203 may update the RLC sequence number for which delivery confirmation has been obtained as needed, using the HARQ-ACK information acquired from the MAC layer 2210 of the UE 804. This allows the DU #1 to promptly notify the CU of the RLC sequence number when inter-DU mobility occurs. Alternatively, the above-mentioned update may be performed when inter-DU mobility occurs. This allows the amount of processing in the RLC-L layer 2501 and the MAC layer 2203 to be reduced.

[0559] 38, assume that inter-DU mobility occurs from DU #1 to DU #2 when the RLC sequence number for which delivery confirmation has been obtained is m. When inter-DU mobility occurs from DU #1 to DU #2, the RLC-L layer 2501 transmits the RLC sequence number m for which delivery confirmation has been obtained as an RLC sequence number notification 2503 to the RLC-H layer 2502 of the CU 801. The Fs interface 814 is used for this transmission.

[0560] 38, the RLC-H layer 2502 transmits an RLC-PDU 2504 having an unacknowledged RLC sequence number (for example, m+1) to the DU#2 (DU 803) by using an RLC sequence number notification 2503. The Fs interface 815 is used for this transmission.

[0561] The configuration shown in FIG. 38 enables the RLC-H layer 2502 to quickly retransmit to the UE 804, using DU #2, an RLC-PDU that the UE has not correctly received when mobility occurs from DU #1 to DU #2.

[0562] Other detailed operations are the same as those in the third embodiment, and therefore description thereof will be omitted. By applying the same method as in the third embodiment, the same effect as in the third embodiment can be obtained in the CU-DU separation option 3-1.

[0563] According to the first modification of the third embodiment, even when the CU-DU separation option 3-1 is used, it is possible to ensure reliability and low latency while suppressing resource usage due to packet duplication.

[0564] Embodiment 4 In a base station configuration using DC, when mobility of a secondary base station occurs, for example, when a change of a secondary base station occurs, the source secondary base station transfers a downlink PDCP-PDU that has not been acknowledged by the UE to the master base station. The master base station transfers the PDCP-PDU to the destination secondary base station (see Non-Patent Document 1).

[0565] However, according to the above-mentioned method, when mobility occurs, data transfer occurs from the source secondary base station to the master base station, which causes a problem of straining the band of the interface between base stations.

[0566] In the fourth embodiment, a method for solving such a problem will be disclosed.

[0567] When mobility of the secondary base station occurs, the master base station transfers the PDCP-PDU, whose delivery to the UE has not been confirmed, to the destination secondary base station, which then transmits or retransmits the PDCP-PDU to the UE.

[0568] The master base station obtains information about PDCP-PDUs whose delivery has been confirmed by the UE, using the PDCP status report transmitted from the UE.

[0569] The above-mentioned PDCP status report may be a periodic PDCP status report as described in Non-Patent Document 20 (3GPP TS36.323 v14.2.0), which makes it possible to reduce the amount of signaling during mobility.

[0570] Also, when mobility occurs, the UE may transmit a PDCP status report to the master base station. The aforementioned transmission may be via the source secondary base station. By transmitting the PDCP status report from the UE, the master base station can acquire the latest PDCP-PDU delivery confirmation status that the UE knows at the time of mobility occurrence. This makes it possible to suppress unnecessary retransmission from the master base station to the UE using the destination secondary base station, for example, retransmission of a PDCP-PDU whose delivery was confirmed by the UE immediately before mobility occurrence. This makes it possible to prevent the bandwidth of the interface between base stations from being constricted.

[0571] The transmission of the PDCP status report from the UE during mobility may be determined by the standard. For example, the UE may transmit the above-mentioned PDCP status report when the UE receives an RRC connection reconfiguration from the master base station. This makes it possible to reduce the amount of signaling required for the above-mentioned PDCP status report transmission.

[0572] Alternatively, the transmission of the PDCP status report from the UE during mobility may be triggered by polling from the master base station to the UE, which makes it possible to avoid complexity in the design of the PDCP layer.

[0573] Fig. 39 is a sequence diagram showing mobility between secondary base stations using a PDCP status report from a UE. Fig. 39 shows an example in which the secondary base station switches from SgNB#1 to SgNB#2.

[0574] In Step ST2601 shown in FIG 39, user data is transferred from the MgNB to the SgNB#1. In Step ST2602, the user data is transmitted from the SgNB#1 to the UE.

[0575] In Step ST2603 shown in FIG. 39, an SgNB addition request is notified from the MgNB to the SgNB#2. In Step ST2604, an acknowledgment in response to Step ST2603 is returned from the SgNB#2 to the MgNB. In Step ST2605, an SgNB release request is notified from the MgNB to the SgNB#1.

[0576] In Step ST2607 shown in FIG. 39, the MgNB notifies the UE of RRC connection reconfiguration. The notification includes information indicating that the secondary base station is switched from SgNB#1 to SgNB#2. The notification may include RRC parameters for SgNB#2. In Step ST2608, the UE notifies the MgNB of completion of RRC connection reconfiguration.

[0577] In Step ST2609 shown in FIG. 39, the UE transmits a PDCP status report to the MgNB. The report includes PDCP-PDU delivery confirmation information in the UE. The PDCP status report may be transmitted from the UE to the MgNB via the SgNB#1.

[0578] In Step ST2610 shown in Fig. 39, the MgNB notifies the SgNB#2 of completion of SgNB reconfiguration. In Step ST2611, a random access procedure is performed between the UE and the SgNB#2, and the UE is connected to the SgNB#2.

[0579] In Step ST2612 shown in FIG. 39, the MgNB transfers user data to the SgNB#2, and in Step ST2613, the SgNB#2 transmits the user data to the UE. The user data may be a PDCP-PDU whose delivery has not been confirmed by the UE in the PDCP status report in Step ST2609.

[0580] In Step ST2614 shown in FIG. 39, the MgNB notifies the SgNB#1 of the UE context release, and then a series of mobility sequences ends.

[0581] This fourth embodiment may be applied to inter-DU mobility. This makes it possible to suppress the band pressure of the CU-DU interface, for example, the Fs interface. Specifically, by replacing MgNB with CU and SgNB with DU, application to inter-DU mobility is possible.

[0582] In addition, the fourth embodiment may be applied to transmission and reception of C-Plane data. For example, the fourth embodiment may be applied to inter-DU mobility of C-Plane data. The above-mentioned C-Plane data may be, for example, NAS data. This makes it possible to ensure efficient transmission and reliability in inter-DU mobility during C-Plane data transmission.

[0583] Figures 40 to 41 are sequence diagrams showing inter-DU mobility using a PDCP status report from a UE. Figures 40 and 41 are connected at the position of boundary line BL4041. Figures 40 and 41 show an example of switching from DU#1 to DU#2. In Figures 40 and 41, the same step numbers are assigned to steps that are the same as those in Figures 32 to 34, and common explanations will be omitted.

[0584] In Step ST2701 shown in FIG.41, the UE transmits a PDCP status report to the DU#1. In Step ST2702, the DU#1 transfers the PDCP status report to the CU. The PDCP status report shown in Steps ST2701 and ST2702 may be the same as that in Step ST2609 shown in FIG.

[0585] In Steps ST2703 and ST2704 shown in FIG 41, user data is transmitted from the CU to the UE via DU #2. Steps ST2703 and ST2704 may transmit PDCP-PDU for which delivery confirmation has not been obtained by the UE, similar to Steps ST2612 and ST2613 shown in FIG 39.

[0586] According to the fourth embodiment, it is possible to suppress pressure on the band of the interface between base stations and / or the interface between CU and DU when mobility occurs.

[0587] According to the fourth embodiment, for example, the following configuration is provided.

[0588] A communication system is provided that includes a communication terminal device and a plurality of base station devices configured to be able to wirelessly communicate with the communication terminal device. More specifically, the plurality of base station devices include a master base station device and a secondary base station device that configure a bearer for the communication terminal device. When the secondary base station device that communicates with the communication terminal device is changed from a first secondary base station device to a second secondary base station device, the master base station device acquires delivery information related to packets that have been delivered from the first secondary base station device to the communication terminal device from the communication terminal device. The master base station device transmits packets not indicated in the delivery information from the second secondary base station device or the master base station device to the communication terminal device.

[0589] Moreover, according to the fourth embodiment, for example, the following configuration is also provided.

[0590] A communication system is provided that includes a communication terminal device and a base station device configured to be able to wirelessly communicate with the communication terminal device. More specifically, the base station device includes a plurality of DUs (Distributed Units) that transmit and receive radio signals, and a CU (Central Unit) that controls the plurality of DUs. The CU acquires delivery completion information on packets that have been delivered to the communication terminal device from a DU connected to the communication terminal device. The CU transmits packets that are not indicated in the delivery completion information from the DU or another DU to the communication terminal device.

[0591] Here, in the fourth embodiment, an example has been disclosed in which the CU acquires the delivery completion information based on a Packet Data Convergence Protocol (PDCP) status report notified from the communication terminal device. However, the delivery completion information is not limited to this example.

[0592] The above configuration can be modified in various ways based on the disclosures and suggestions of this specification, including embodiment 4. According to the above configuration and modified configurations, the above problems can be solved and the above effects can be obtained.

[0593] Variation 1 of embodiment 4 In this first modification, another method for solving the problem in the fourth embodiment will be disclosed.

[0594] The source secondary base station transfers the RLC-PDU to the master base station, which in turn transfers the RLC-PDU to the destination secondary base station.

[0595] The source secondary base station may transfer the RLC-PDU, which has not been acknowledged by the UE, to the destination secondary base station via the master base station. The transfer may be performed for downlink data. This makes it possible to reduce the amount of data transferred in the interface between base stations.

[0596] In the above, the source secondary base station may transfer the RLC control PDU to the destination secondary base station via the master base station. This makes it unnecessary for the destination secondary base station to regenerate the RLC control PDU, thereby reducing the amount of processing at the destination secondary base station.

[0597] The source secondary base station may transfer the RLC-PDU being assembled into a PDCP-PDU to the destination secondary base station via the master base station. The transfer may be performed for uplink data. This makes it possible to suppress retransmission of the PDCP-PDU from the UE even if the RLC-PDU is lost in the destination secondary base station.

[0598] The source secondary base station may transfer the RLC state variables to the destination secondary base station via the master base station. The above-mentioned RLC state variables may be variables described in section 7.1 of non-patent document 21 (3GPP TS 36.322 v14.0.0). This makes it possible to ensure the continuity of the RLC entities before and after the mobility. This makes it easier to process in the opposing UE.

[0599] The source secondary base station may transfer the value of a timer used in the RLC entity to the destination secondary base station via the master base station. The timer value may be a value described in section 7.3 of non-patent document 21 (3GPP TS 36.322 v14.0.0). This makes it possible to maintain smooth operation of the RLC entity.

[0600] This modification 1 may be applied to inter-DU mobility. This makes it possible to suppress the bandwidth pressure of the CU-DU interface, for example, the Fs interface. Specifically, by replacing MgNB with CU and SgNB with DU, application to inter-DU mobility is possible.

[0601] In addition, this modified example 1 may be applied to the transmission and reception of C-Plane data. For example, this modified example 1 may be applied to the mobility between DUs of C-Plane data. The above-mentioned C-Plane data may be, for example, NAS data. This makes it possible to ensure efficient transmission and reliability in the mobility between DUs during C-Plane data transmission.

[0602] According to this modification 1, it is possible to suppress pressure on the bandwidth of the interface between base stations and / or the interface between CU and DU when mobility occurs.

[0603] Embodiment 5. As disclosed in the first embodiment, a configuration in which CU and DU are separated is being considered in NR. A plurality of DUs may be provided in a CU-DU separated configuration. In such a case, the question arises as to which part of a gNB having a CU-DU separated configuration of option 2 performs routing to a DU. Here, a routing method of a DU in a gNB is disclosed.

[0604] In the case of a gNB with a CU-DU separation configuration (Option 2), the gNB CU has an inter-DU routing function. The gNB CU performs routing to the DU.

[0605] A routing function between DUs may be provided in the PDCP in the CU of the gNB. The PDCP in the CU of the gNB may perform routing to the DU.

[0606] The inter-DU routing function includes a function for determining a routing destination DU and a function for transmitting data to the determined routing destination DU.

[0607] The inter-DU routing function may also include a flow control function. The flow control function may be included in the function of determining the routing destination DU, or may be included in the function of transmitting data to the determined routing destination DU. Flow control includes control of data transmission timing, such as starting and stopping data transmission, and control of data transmission speed.

[0608] The inter-DU routing function may be provided below the conventional PDCP function or the intra-CU PDCP function proposed in NR (Non-Patent Document 22: R3-170266).

[0609] When the intra-CU PDCP has a routing function for a split bearer, the inter-DU routing function may be provided below the routing function for the split bearer.

[0610] By providing the inter-DU routing function below the routing function for split bearers, inter-DU routing is performed after data is split to each gNB. For each gNB, routing between DUs can be performed for data intended for each gNB. It is possible to avoid complexity in providing an inter-DU routing function.

[0611] In the inter-DU routing function, a routing destination DU may be determined and transmitted for each PDCP PDU. A routing destination DU may be determined and transmitted for each predetermined amount or number of PDCP PDUs. A routing destination DU may be determined and transmitted at predetermined time intervals. A routing destination DU may be determined and transmitted for each amount of PDCP PDUs according to a request from each DU. In this way, it becomes possible to adjust the amount of PDCP PDUs transmitted to each DU.

[0612] By doing this, it becomes possible to perform routing from CU to DU in a gNB with a CU-DU separation configuration as in Option 2.

[0613] On the receiving side, a function is provided in the PDCP in the CU of the gNB to route data from each DU to a higher-level function. The function of routing data from each DU to a higher-level function may be one of the inter-DU routing functions.

[0614] As a function on the receiving side, it routes data from each DU to the upper function in the order in which it arrives. In other words, it sends data from each DU to the upper function one by one in the order in which it arrives.

[0615] Alternatively, data from each DU may be routed to the upper function in the order of PDCP-SN (sequence number), i.e., data from each DU is routed in the order of PDCP-SN and sent to the upper function one by one.

[0616] In this way, it becomes possible to route data from each DU of the gNB to a higher-level function.

[0617] A DU buffer may be provided in a CU in a gNB. The buffer may be a buffer for communication on a CU-DU interface. By using a buffer for routing between DUs or for routing to a higher-level function on the receiving side, data can be stored in the buffer. This makes it possible to reduce data overflows and data loss when data communication between a UE and a DU is stalled.

[0618] The buffer may be provided for each DU. By having a buffer for each DU, it is possible to reduce the state where data overflows for each DU depending on the data communication status between the UE and each DU, and to reduce data loss. In addition, it is possible to reduce the state where data overflows for other DUs due to stagnation of data communication for one DU, and to reduce data loss.

[0619] A DU buffer may be provided within the PDCP. This facilitates linkage processing with the inter-DU routing function.

[0620] A buffer may be provided for each DU in the DU of the gNB. The buffer may be provided in the RLC. The buffer may be a buffer for communication on the CU-DU interface. By using a buffer for receiving data routed from the CU or for transmitting data to the CU on the receiving side, the data can be stored in the buffer. This makes it possible to reduce data overflows in cases where data communication between the UE and the DU is stalled or where the CU or PDCP functions are stalled, and to reduce data loss.

[0621] Information requesting downlink data may be sent from the RLC of each DU to the CU. The information may be sent from the RLC in each DU to the PDCP in the CU. Five examples of the information are disclosed below.

[0622] (1) Identifier of the own DU.

[0623] (2) The amount of data requested.

[0624] (3) The number of PDCP-PDUs requested.

[0625] (4) The amount of buffer space available in the own DU.

[0626] (5) A combination of (1) to (4).

[0627] The inter-DU routing function in the CU can determine to which DU to transmit data, taking into account the information notified from each DU.

[0628] In addition, each DU may notify the CU of information regarding the success or failure of transmission due to the RLC retransmission control. Each DU may notify the information in association with its own DU identifier. The PDCP in the CU can determine whether to perform retransmission accordingly.

[0629] Also, each DU may notify the CU of information regarding the success or failure of transmission by MAC retransmission control (HARQ). Each DU may notify the information in association with its own DU identifier. The PDCP in the CU can determine whether to perform retransmission accordingly. For example, the method disclosed in the third embodiment may be applied as this method.

[0630] The CU PDCP uses the inter-DU routing function to determine again which DU to route the data determined to be retransmitted, and transmits the data to the determined routing destination DU. In this case, it may be possible to transmit to any DU, not just the DU to which it was previously transmitted. By allowing transmission to a DU different from the DU to which it was previously transmitted, it becomes possible to determine the routing destination DU while taking into consideration the communication status between the UE and the DU.

[0631] The packet duplication function and the duplicate packet detection and deletion function disclosed in the first embodiment may be configured in the CU of the gNB together with the inter-DU routing function. These functions may be functions of intra-CU PDCP. The gNB performs the packet duplication function, and the gNB can route the duplicated packets using the inter-DU routing function between DUs.

[0632] The function for determining the DU to which a duplicated packet is to be transmitted may be implemented by using either the DU determination method in the packet duplication function disclosed in the first embodiment or the function for determining the routing destination DU in the inter-DU routing function.

[0633] When the DU itself or the UE determines the DU to which the duplicated packet will be communicated, the function of the inter-DU routing function to determine the routing destination DU may be disabled. The function of the inter-DU routing function to determine the routing destination DU may be bypassed or transparent. In the inter-DU routing function, it is preferable to enable the function of transmitting a duplicated packet to the DU that the DU itself or the UE determines will communicate the duplicated packet.

[0634] In this way, it is possible to configure a CU that has both a packet duplication function and an inter-DU routing function.

[0635] According to the method disclosed in this embodiment 5, even if multiple DUs are connected to a CU in the CU-DU separation configuration of option 2, the gNB can communicate with the UE using multiple DUs.

[0636] According to the fifth embodiment, for example, the following configuration is provided.

[0637] A communication system is provided that includes a communication terminal device and a base station device configured to be able to wirelessly communicate with the communication terminal device. More specifically, the base station device includes a plurality of DUs (Distributed Units) that transmit and receive radio signals to and from the communication terminal device, and a CU (Central Unit) that controls the plurality of DUs. The CU has a function of routing downlink data addressed to the communication terminal device within PDCP (Packet Data Convergence Protocol) or at a lower level than PDCP.

[0638] The above configuration can be modified in various ways based on the disclosures and suggestions of this specification, including embodiment 5. According to the above configuration and modified configurations, the above problems can be solved and the above effects can be obtained.

[0639] Embodiment 6 In 3GPP, dual connectivity (DC) using split bearer (SB) is being considered as an NR technology.

[0640] It has been proposed that in an SB, a master gNB (MgNB) is responsible for routing to an MgNB or an SgNB (Non-Patent Document 22: R3-170266).

[0641] In addition, in NR, similar to LTE, a configuration that does not use PDCP of a secondary gNB (SgNB) for UEs performing DC is being considered (Non-Patent Document 9: TR38.804V1.0.0).

[0642] Data for the SgNB is routed to the SgNB in ​​the PDCP of the MgNB and transmitted to the SgNB. The data transmitted to the SgNB is input to the RLC in the SgNB.

[0643] If a gNB with a CU-DU separated configuration in Option 2 is used as an SgNB for an SB, the following problems arise.

[0644] In the past, when the SgNB was not configured with CU-DU separation as in LTE, the MgNB only had to transmit data to the SgNB. However, in NR, when the SgNB is configured with CU-DU separation, the MgNB does not know where to send the data in the SgNB, that is, whether to send it to the CU or the DU.

[0645] Also, as mentioned above, the SgNB does not use PDCP for UEs performing DC (TR38.804 v1.0.0). Therefore, even if data is transmitted from the MgNB to the CU of the SgNB, it cannot be input to the PDCP in the CU. Since there is no RLC in the CU, processing is impossible. For this reason, data transmission from the PDCP in the CU to the RLC in the DU as mentioned above is impossible.

[0646] Furthermore, even if data is transmitted from the MgNB to a DU of the SgNB, it is unclear to which DU of another gNB the data should be transmitted to and how.

[0647] This makes it impossible to transmit data from the MgNB to the SgNB.

[0648] In the uplink, the transmission path is reversed, so a detailed explanation will be omitted here, but similarly, data transmission from the SgNB to the MgNB becomes impossible.

[0649] This causes a problem in that communication cannot be established between the UE that communicates using the DU of the SgNB and the base station.

[0650] In the sixth embodiment, a method for solving such a problem will be disclosed.

[0651] Provide an inter-DU routing function in the SgNB. The SgNB performs inter-DU routing. Provide an inter-DU routing function in the CU of the SgNB. The CU of the SgNB performs inter-DU routing. The data to be routed may be user data (U-plane data). The data to be routed may also be control data (C-plane data). In that case, it can be applied when supporting control data with a split bearer.

[0652] The SgNB, which is a gNB used as a secondary in the DC of the SB, performs inter-DU routing for the PDCP-PDU transmitted from the MgNB.

[0653] As mentioned above, the question is where to provide the inter-DU routing function in the CU of the SgNB. Here, three examples are disclosed for where to provide the inter-DU routing function.

[0654] (1) An inter-DU routing function is provided within the PDCP in the CU of the SgNB.

[0655] (2) An inter-DU routing function is provided outside the PDCP in the CU of the SgNB.

[0656] (3) A protocol stack having inter-DU routing function is provided outside the PDCP in the CU of the SgNB.

[0657] Details regarding (1) above will be disclosed.

[0658] An inter-DU routing function is provided in the PDCP in the CU of the SgNB. Data transfer between the MgNB and the SgNB is disclosed. Data is input from the MgNB of the UE targeted for the split bearer to the PDCP of the SgNB. In the CU of the SgNB, only the PDCP inter-DU routing function is operated. This function alone may be enabled. Other functions may not be operated. Other functions may be bypassed or made transparent. Data is output to each DU from the PDCP in the CU of the SgNB.

[0659] On the receiving side, a function is provided for routing data from each DU to the MgNB by PDCP in the CU of the SgNB. The function for routing data from each DU to the MgNB may be one of the inter-DU routing functions.

[0660] The function of the receiver is to route data from each DU to the MgNB in ​​the order of arrival, i.e., send data from each DU to the MgNB one by one in the order of arrival.

[0661] Alternatively, data from each DU may be routed to the MgNB in ​​the order of PDCP-SN (sequence number), i.e., data from each DU is routed in the order of PDCP-SN and sent to the MgNB one by one.

[0662] Fig. 42 is a diagram showing an example of an architecture in which an inter-DU routing function is provided in the PDCP of the SgNB. Fig. 42 shows the case of Option 2 CU-DU separation configuration for both the MgNB and the SgNB.

[0663] The MgNB consists of a CU and a DU. Two DUs (DU#1, DU#2) are connected to one CU. RRC, New AS Layer, and PDCP are configured in the CU. RLC, MAC, and PHY are configured in the DU.

[0664] The SgNB is composed of a CU and a DU. Two DUs (DU#1, DU#2) are connected to one CU. RRC is configured in the CU of the SgNB. RLC, MAC, and PHY are configured in the DU. Since the SgNB is a secondary gNB for a UE that performs DC, in the conventional configuration, a New AS Layer and PDCP are not configured in the CU. However, in the example of Figure 42, PDCP is provided in the CU.

[0665] An inter-DU routing function is provided in the PDCP in the CU in the SgNB. In the example of Figure 42, an inter-DU routing function is also provided in the PDCP in the CU in the MgNB.

[0666] For data communication between the MgNB and the SgNB, an interface may be provided between the CU of the MgNB and the CU of the SgNB. As the interface, a new interface may be provided, or Xn or Xx, which are being considered as interfaces between gNBs in 3GPP, may be used.

[0667] Using this interface, data is input from the MgNB of the UE to which the split bearer is to be applied to the PDCP of the SgNB. In the PDCP configured in the CU of the SgNB, only the inter-DU routing function is operated. Data from the MgNB is output to each DU by the inter-DU routing function.

[0668] On the receiving side, the data from each DU is routed to the MgNB in ​​the PDCP inter-DU routing function configured in the CU of the SgNB. For example, the SgNB routes and transmits data from each DU to the MgNB in ​​the order of arrival.

[0669] By adopting this method, the existing protocol stack PDCP can be reused in the SgNB, making it easier to configure the gNB. It becomes easier to use the gNB with the CU-DU separation configuration of Option 2 as a secondary for the DC.

[0670] The packet duplication function and the duplicate packet detection and deletion function disclosed in the first embodiment may be provided in the CU of the SgNB. The function may be provided in the PDCP configured in the CU. Packet duplication can be performed in the SgNB.

[0671] In addition, this function may be configured in the CU of the SgNB together with the inter-DU routing function. These functions may be functions of the PDCP in the CU. The gNB having both the packet duplication function and the inter-DU routing function in the PDCP in the CU disclosed in the fifth embodiment may be used as the SgNB. When using the gNB as the SgNB of the UE to be DC-targeted, it is preferable to enable the packet duplication function and the inter-DU routing function.

[0672] In this way, the SgNB can perform a packet duplication function using multiple DUs, and a duplicate packet detection and deletion function. Also, the MgNB does not need to perform the packet duplication function using multiple DUs of the SgNB. This makes it possible to prevent an increase in the amount of data communication between the MgNB and the SgNB.

[0673] Details regarding (2) above will be disclosed.

[0674] An inter-DU routing function is provided outside of PDCP in the CU of the SgNB. The RRC of the SgNB may have the routing function. Data transfer between the MgNB and the SgNB is disclosed. Data is input from the MgNB of the UE targeted for the split bearer to the CU of the SgNB. In the CU of the SgNB, only the inter-DU routing function is operated. Only this function may be enabled. Other functions may not be operated. Other functions may be bypassed or made transparent. Data is output from the CU of the SgNB to each DU.

[0675] On the receiving side, a function for routing data from each DU to the MgNB is provided outside the PDCP in the CU of the SgNB. The function for routing data from each DU to the MgNB may be one of the inter-DU routing functions.

[0676] As the function on the receiving side, it is advisable to apply the method disclosed in (1) above.

[0677] Fig. 43 is a diagram showing an example of an architecture in which an inter-DU routing function is provided outside the PDCP in the CU of the SgNB. Fig. 43 shows the case of Option 2 CU-DU separation configuration for both the MgNB and the SgNB.

[0678] The MgNB consists of a CU and a DU. Two DUs (DU#1, DU#2) are connected to one CU. RRC, New AS Layer, and PDCP are configured in the CU. RLC, MAC, and PHY are configured in the DU.

[0679] The SgNB consists of a CU and a DU. Two DUs (DU#1, DU#2) are connected to one CU. RRC is configured in the CU of the SgNB. RLC, MAC, and PHY are configured in the DU. Since the SgNB is a secondary gNB for the UE that performs DC, New AS Layer and PDCP are not configured in the CU.

[0680] An inter-DU routing function is provided outside the PDCP in the CU of the SgNB. In the example of Figure 43, an inter-DU routing function is provided outside the PDCP in the CU of the MgNB.

[0681] In the gNB, an inter-DU routing function may be provided outside the PDCP of the gNB. In the example of FIG. 42 described above, an inter-DU routing function is provided in the PDCP of the MgNB, but here, an inter-DU routing function may be provided outside the PDCP of the MgNB.

[0682] As in the above case (1), it is preferable to provide an interface between the CU of the MgNB and the CU of the SgNB for data communication between the MgNB and the SgNB.

[0683] Using this interface, data is input from the MgNB of the UE to which the split bearer is to be applied to the inter-DU routing function provided outside the PDCP in the CU of the SgNB. The input data is output to each DU by the inter-DU routing function.

[0684] On the receiving side, the data from each DU is routed to the MgNB in ​​an inter-DU routing function provided outside the PDCP in the CU of the SgNB. For example, the SgNB routes and transmits data from each DU to the MgNB in ​​the order of arrival.

[0685] By adopting such a method, when implementing a split bearer, the SgNB can be configured without using PDCP, as in the case of a conventional split bearer, which makes it easy to extend the functions of the SgNB.

[0686] In addition, if the RRC of the SgNB has an inter-DU routing function, the inter-DU routing function can be realized simply by adding a function to the RRC, so that the gNB can be easily configured. In addition, if the RRC of the SgNB has an inter-DU routing function, the amount of processing can be reduced because routing in multiple bearers can be performed collectively.

[0687] The packet duplication function and the duplicate packet detection and deletion function disclosed in the first embodiment may be provided in the CU of the SgNB. The function may be provided outside the PDCP configured in the CU. Packet duplication can be performed in the SgNB.

[0688] In addition, this function may be configured in the CU of the SgNB together with the inter-DU routing function. These functions may be functions outside the PDCP in the CU. A gNB having both the packet duplication function and the inter-DU routing function outside the PDCP in the CU may be used as the SgNB. When using the gNB as the SgNB of the UE to be DC-targeted, it is recommended to enable the packet duplication function and the inter-DU routing function.

[0689] In this way, the SgNB can perform a packet duplication function using multiple DUs, and a duplicate packet detection and deletion function. Also, the MgNB does not need to perform the packet duplication function using multiple DUs of the SgNB. This makes it possible to prevent an increase in the amount of data communication between the MgNB and the SgNB.

[0690] Details regarding (3) above will be disclosed.

[0691] A protocol stack (sometimes called RP) with inter-DU routing function is provided outside the PDCP in the CU of the SgNB. It is preferable to provide the RP separately from the PDCP. The RP may also be provided below the PDCP. The RP performs inter-DU routing in the SgNB.

[0692] This section describes data transfer between the MgNB and the SgNB. Data is input from the MgNB of the UE to which the split bearer is applied to the CU of the SgNB. The data may be input to the RP in the CU of the SgNB. The RP performs inter-DU routing of the data using the inter-DU routing function, and outputs the data to each DU.

[0693] On the receiving side, a function is provided in the RP in the CU of the SgNB to route data from each DU to the MgNB. The function of routing data from each DU to the MgNB may be one of the inter-DU routing functions.

[0694] As the function on the receiving side, it is advisable to apply the method disclosed in (1) above.

[0695] Figure 44 is a diagram showing an example of an architecture in which a protocol stack having an inter-DU routing function is provided outside the PDCP in the CU of the SgNB. Figure 44 shows the case of Option 2 CU-DU separation configuration for both the MgNB and the SgNB.

[0696] The MgNB consists of a CU and a DU. Two DUs (DU#1, DU#2) are connected to one CU. RRC, New AS Layer, and PDCP are configured in the CU. RLC, MAC, and PHY are configured in the DU.

[0697] The SgNB consists of a CU and a DU. Two DUs (DU#1, DU#2) are connected to one CU. RRC is configured in the CU of the SgNB. RLC, MAC, and PHY are configured in the DU. Since the SgNB is a secondary gNB for the UE that performs DC, New AS Layer and PDCP are not configured in the CU.

[0698] An RP is provided outside the PDCP in the CU of the SgNB. The RP is provided with an inter-DU routing function. In the example of Figure 44, an RP is provided outside the PDCP in the CU of the MgNB. The RP is provided with an inter-DU routing function.

[0699] In the gNB, an RP may be provided outside the PDCP of the gNB, and an inter-DU routing function may be provided in the RP. In the example of FIG. 43 described above, an inter-DU routing function is provided outside the PDCP of the MgNB, but here, an RP may be provided outside the PDCP of the MgNB, and an inter-DU routing function may be provided in the RP.

[0700] The RP may be a gNB common protocol stack having both an inter-DU routing function for the MgNB and an inter-DU routing function for the SgNB. Alternatively, the RP may be a gNB common protocol stack by commonizing the inter-DU routing function for the MgNB and the inter-DU routing function for the SgNB. For example, data may be input from PDCP to the RP on the transmitting side, and data may be transmitted from the RP to PDCP on the receiving side.

[0701] The MgNB transmits and receives data between the PDCP in its own gNB and the RP. The SgNB transmits and receives data between the PDCP of the MgNB and the RP of its own gNB.

[0702] The same gNB may be an MgNB for one UE and an SgNB for another UE. Therefore, by providing a gNB common RP, it is possible to perform inter-DU routing regardless of which gNB it is used as.

[0703] As in the above case (1), it is preferable to provide an interface between the CU of the MgNB and the CU of the SgNB for data communication between the MgNB and the SgNB.

[0704] Using this interface, data is input from the MgNB of the UE to which the split bearer is to be applied to the RP provided outside the PDCP in the CU of the SgNB. The input data is output to each DU by the inter-DU routing function.

[0705] On the receiving side, the data from each DU is routed to the MgNB in ​​the inter-DU routing function of the RP provided outside the PDCP in the CU of the SgNB. For example, the SgNB routes and transmits data from each DU to the MgNB in ​​the order of arrival.

[0706] By providing a protocol stack with an inter-DC routing function in this way, it is possible to configure the gNB without affecting other protocol stacks in the gNB. This makes it easy to configure the SgNB.

[0707] In addition, by using a common RP for gNBs, there is no need to design, implement, or configure differently for MgNB and SgNB, which makes it possible to avoid complexity.

[0708] In addition, the packet duplication function and the duplicate packet detection and deletion function disclosed in the first embodiment may be provided in the RP. By providing the packet duplication function and the duplicate packet detection and deletion function in the RP, it is possible to configure the gNB without affecting other protocol stacks.

[0709] In addition, by providing a packet duplication function and a function for detecting and deleting duplicate packets within the RP common to the gNBs, there is no need to design, implement or configure differently for the MgNB and SgNB, thereby making it possible to avoid complexity.

[0710] In addition, the packet duplication function and the duplicate packet detection and deletion function disclosed in the first embodiment may be provided in the CU of the SgNB. The function may be provided in the RP configured in the CU. Packet duplication can be performed in the SgNB.

[0711] In addition, this function may be configured in the CU of the SgNB together with the inter-DU routing function. These functions may be functions in the RP of the CU. A gNB having both the packet duplication function and the inter-DU routing function in the RP of the CU may be used as the SgNB. When using the gNB as the SgNB of the UE to be DC-targeted, it is recommended to enable the packet duplication function and the inter-DU routing function.

[0712] In this way, the SgNB can perform a packet duplication function using multiple DUs, and a duplicate packet detection and deletion function. Also, the MgNB does not need to perform the packet duplication function using multiple DUs of the SgNB. This makes it possible to prevent an increase in the amount of data communication between the MgNB and the SgNB.

[0713] A buffer for DU may be provided in a CU in the gNB. Also, a buffer may be provided for each DU in the DU of the gNB. The method disclosed in the fifth embodiment may be applied. Similar effects can be obtained.

[0714] Also, each DU may notify the CU of information requesting downlink data, information on RLC retransmission control, and information on MAC retransmission control. The method disclosed in the fifth embodiment may be applied. Similar effects can be obtained.

[0715] Also, in the fifth embodiment, it was disclosed that the PDCP in the CU decides to which DU the data determined to be retransmitted should be routed again by the inter-DU routing function, and transmits the data to the decided routing destination DU. In the sixth embodiment, it is preferable that the same CU or intra-CU protocol stack that provides the inter-DU routing function performs these processes. Similar effects can be obtained.

[0716] The SgNB may notify the MgNB of information indicating whether or not the SgNB has a CU-DU separation configuration.

[0717] In addition, the SgNB may notify the MgNB of information regarding the inter-DU routing function of its own SgNB. Information regarding the inter-DU routing function includes configuration information such as whether the inter-DU routing function is present and where the inter-DU routing function is provided.

[0718] The SgNB may notify the MgNB of these pieces of information when DC is configured. For example, when an SgNB is added (SgNB addition), the SgNB may notify the MgNB of the information. The SgNB may notify the MgNB of the information by including the information in signaling that notifies a response to a request for SgNB addition.

[0719] Alternatively, when an SgNB modification is performed, the SgNB may notify the MgNB of the information. The SgNB may notify the MgNB of the information by including the information in signaling that notifies a response to a request for SgNB modification.

[0720] In this way, by notifying the MgNB of information indicating the presence or absence of a CU-DU separation configuration and information regarding the inter-DU routing function from the SgNB, the MgNB can recognize them. The MgNB may perform SB routing taking these into consideration.

[0721] In addition, the above-mentioned information may be notified between gNBs not only when DC is set, but also when an interface between gNBs is set up. The setup message may include information indicating the presence or absence of a CU-DU separation configuration of the gNB itself and information regarding inter-DU routing, thereby notifying the other gNBs of the information.

[0722] Alternatively, the above information may be notified when updating the gNB configuration. The gNB may notify other gNBs of the information by including information indicating the presence or absence of a CU-DU separation configuration of the gNB and information regarding inter-DU routing in a gNB configuration update message.

[0723] The other gNBs mentioned above may be neighboring gNBs.

[0724] By notifying the above-mentioned information at the time of setup or when updating gNB settings, it becomes possible to take into account the configuration of surrounding gNBs not only for DC but also for other services.

[0725] Information notified between MgNB and SgNB will be disclosed. The information may be information notified between MgNB and SgNB during SB in LTE. The information may be information notified over X2-U (Non-Patent Document 23: TS36.425).

[0726] The information notified from the MgNB to the SgNB includes information associated with DL data. The information associated with DL data is, for example, a sequence number assigned on the interface between the MgNB and the SgNB. When Xn or Xx is provided, the sequence number assigned on the interface may be the information associated with DL data. For example, Xn-U SN or Xx-U SN.

[0727] The information notified from the SgNB to the MgNB includes information on the transmission status of DL data. The information on the transmission status of DL data is, for example, the highest PDCP-SN that has been successfully transmitted to the UE. The SgNB may notify the PDCP-SN that has been successfully transmitted to the UE within a predetermined period as the information on the transmission status of DL data. The SgNB may notify the PDCP-SN that has been unsuccessfully transmitted to the UE within a predetermined period as the information on the transmission status of DL data. The SgNB may notify the first PDCP-SN to be notified together with the PDCP-SNs that have been successfully or unsuccessfully transmitted within the predetermined period. The PDCP-SNs that have been successfully or unsuccessfully transmitted within the predetermined period may be notified as bitmap information. This reduces the number of bits required for notification.

[0728] The information on the transmission status of DL data may be, for example, the highest PDCP-SN successfully transmitted from the CU to the DU or the RLC in the DU. The SgNB may notify the PDCP-SN successfully transmitted from the CU to the DU or the RLC in the DU within a predetermined period as the information on the transmission status of DL data. The SgNB may notify the PDCP-SN unsuccessfully transmitted from the CU to the DU or the RLC in the DU within a predetermined period as the information on the transmission status of DL data. The SgNB may notify the first PDCP-SN to be notified together with the PDCP-SNs successfully or unsuccessfully transmitted within the predetermined period. The PDCP-SNs successfully or unsuccessfully transmitted within the predetermined period may be notified as bitmap information. The number of bits required for notification can be reduced.

[0729] The information on the transmission status of DL data may be, for example, the highest PDCP-SN successfully transmitted to the UE by the DU or RLC in the DU. The SgNB may notify the PDCP-SN successfully transmitted to the UE by the DU or RLC in the specified period as the information on the transmission status of DL data. The SgNB may notify the PDCP-SN unsuccessfully transmitted to the UE by the DU or RLC in the specified period as the information on the transmission status of DL data. The SgNB may notify the first PDCP-SN to be notified together with the PDCP-SNs successfully or unsuccessfully transmitted during the specified period. The PDCP-SNs successfully or unsuccessfully transmitted during the specified period may be notified as bitmap information. The number of bits required for notification can be reduced.

[0730] Information on the highest PDCP-SN successfully transmitted to the UE by the DU or RLC in the DU, information on the PDCP-SN successfully transmitted to the UE by the DU or RLC in the DU in a predetermined period, and information on the PDCP-SN unsuccessfully transmitted to the UE by the DU or RLC in the DU in a predetermined period may be notified from the DU to the CU. Alternatively, these pieces of information may be notified from the RLC in the DU to the PDCP in the CU. The CU in the SgNB can notify the MgNB of these pieces of information.

[0731] The information notified from the SgNB to the MgNB includes buffer size information, such as a desired buffer size for a bearer to be the target of SB, and a minimum desired buffer size for a UE to be the target of SB.

[0732] The information notified from the SgNB to the MgNB includes information on data lost in data communication between the MgNB and the SgNB. The information on the lost data is, for example, a sequence number given to the lost data on the interface between the MgNB and the SgNB. Another example of the information on the lost data is a sequence number given to the first lost data on the interface between the MgNB and the SgNB, and a sequence number given to the last lost data on the interface between the MgNB and the SgNB. The number of sets of these series of lost data may also be notified.

[0733] In this way, even if data is transmitted from the MgNB to a PDCP in a CU of the SgNB, the data transmission can be performed appropriately and efficiently.

[0734] 45 to 47 are diagrams showing an example of a DC sequence of an SB using an SgNB with a CU-DU split configuration. 45 to 47 are connected at the positions of boundary lines BL4546 and BL4647.

[0735] The SgNB has a CU-DU split configuration of Option 2, and two DUs (DU #1, DU #2) are connected to one CU. The MgNB also has a CU-DU split configuration of Option 2, and two DUs (DU #1, DU #2) are connected to one CU.

[0736] In Step ST6801, data is transmitted and received between the upper NW device and the MgNB CU.

[0737] In Step ST6802, the MgNB CU performs routing between DUs. For example, when the inter-DU routing function is configured in the PDCP, the PDCP performs the inter-DU routing. In the inter-DU routing, the MgNB CU determines a DU to be a routing destination and transmits data to the determined routing destination DU.

[0738] In Step ST6803, the MgNB CU transmits the data that it has decided to route to the MgNB DU#1 to the DU#1. In Step ST6804, the MgNB DU#1 performs RLC, MAC, and PHY processing on the data received from the MgNB CU, and transmits the processed data to the UE.

[0739] In Step ST6806, the MgNB CU transmits the data that has been determined to be routed to the MgNB DU#2 to the DU#2. In Step ST6805, the MgNB DU#2 performs RLC, MAC, and PHY processing on the data received from the MgNB CU, and transmits the processed data to the UE.

[0740] The reverse operation is performed for transmission from the UE. In step ST6804, data is transmitted from the UE to MgNB DU#1. In step ST6803, the data received by MgNB DU#1 is processed by PHY, MAC, and RLC, and transmitted to the MgNB CU. Similarly, in steps ST6805 and ST6806, data is transmitted from the UE to the MgNB CU via MgNB DU#2. In step ST6802, the MgNB CU performs inter-DU routing on the receiving side. For example, the MgNB CU transmits data from MgNB DU#1 and data from MgNB DU#2 to a higher-level function in the order of arrival. Data from the UE is processed by PDCP in the MgNB CU, processed by the New AS Layer, and transmitted to the higher-level NW device in step ST6801.

[0741] This makes it possible for the UE and the upper network device to communicate with each other even when the MgNB is made up of multiple DUs.

[0742] Next, a case where DC of SB is performed will be described. In Step ST6807, the MgNB decides to perform DC for the UE.

[0743] In Step ST6808, the MgNB CU notifies the SgNB CU of an SgNB addition request message. The SgNB CU that receives the message permits its own gNB to be an SgNB.

[0744] At this time, in Step ST6809, the SgNB CU may determine the DU to be used for the DC.

[0745] In Step ST6810, the SgNB CU notifies the MgNB CU of an SgNB addition request response message. The DU to be used for the DC determined in Step ST6809 is included in this message and notified.

[0746] In step ST6811, the MgNB CU that has received the SgNB addition request response message notifies the UE that performs DC of the DC setting. At this time, it is preferable to notify information about the DU of the SgNB used for DC. For example, identifiers of DU #1 and DU #2, resources and sequence information used for initial access (e.g., random access), etc.

[0747] For this notification, an RRC connection reconfiguration message may be used. In this way, the UE can identify which DU of the SgNB to perform DC with, and can access the DU to perform DC.

[0748] In Step ST6812, the UE notifies the MgNB CU of the completion of the DC configuration. For this notification, an RRC connection reconfiguration complete message may be used.

[0749] In Step ST6813, the MgNB CU notifies the SgNB CU of the completion of SgNB reconfiguration.

[0750] In this way, the DC of the SB is set.

[0751] In steps ST6814 and ST6815, the UE performs random access (RA) processing between the DU #1 and DU #2 of the SgNB performing DC. This enables access between the UE and the DU #1 and DU #2 of the SgNB performing DC.

[0752] In Step ST6816, the MgNB CU routes data transmitted from the upper NW device to the MgNB and the SgNB for the SB. The data routed to the SgNB is transmitted to the SgNB in ​​Step ST6821. Specifically, the data is transmitted to the CU of the SgNB.

[0753] For the data routed to the MgNB, inter-DU routing is performed in Step ST6827. The data that the MgNB CU has decided to route to the MgNB DU#1 by the inter-DU routing in Step ST6827 is transmitted to the MgNB DU#1 in Step ST6817. In Step ST6818, the MgNB DU#1 processes the received data and transmits it to the UE.

[0754] The data that the MgNB CU has decided to route to the MgNB DU #2 through the inter-DU routing in Step ST6827 is transmitted to the MgNB DU #2 in Step ST6820. In Step ST6819, the MgNB DU #2 processes the received data and transmits it to the UE.

[0755] For data transmitted to the CU of the SgNB, inter-DU routing is performed in Step ST6822. Even if an inter-DU routing function is provided in the PDCP of the SgNB, only the inter-DU routing function is enabled.

[0756] The data that the SgNB CU has determined to be routed to the SgNB DU #1 by the inter-DU routing in Step ST6822 is transmitted to the SgNB DU #1 in Step ST6823. In Step ST6824, the SgNB DU #1 processes the received data and transmits it to the UE.

[0757] The data that the SgNB CU has determined to route to the SgNB DU #2 through the inter-DU routing in Step ST6822 is transmitted to the SgNB DU #2 in Step ST6826. In Step ST6825, the SgNB DU #2 processes the received data and transmits it to the UE.

[0758] The reverse operation is performed for transmission from the UE. As for the MgNB side, the method is the same as that disclosed in Steps ST6802 to ST6806, and therefore a description thereof is omitted.

[0759] Disclose SgNB.

[0760] In Step ST6824, data is transmitted from the UE to the SgNB DU#1. The data received by the SgNB DU#1 is processed by PHY, MAC, and RLC, and in Step ST6823, is transmitted to the SgNB CU. Similarly, in Steps ST6825 and ST6826, data is transmitted from the UE to the SgNB CU via the SgNB DU#2.

[0761] In step ST6822, the SgNB CU performs inter-DU routing on the receiving side. For example, data from SgNB DU#1 and data from SgNB DU#2 are transmitted to the MgNB in ​​the order of arrival. Data from the UE is transmitted from the SgNB CU to the MgNB CU in step ST6821. The data received by the MgNB CU is processed by PDCP, processed by the New AS Layer, and transmitted to the upper NW device.

[0762] In the communication between the MgNB CU and the SgNB CU in Step ST6821, the above-mentioned information notified between the MgNB and the SgNB may be notified.

[0763] By doing this, it becomes possible to perform DC of the SB using a gNB with a CU-DU separation configuration in Option 2 as a secondary.

[0764] By using the method disclosed in the sixth embodiment, when a gNB with a CU-DU separation configuration of option 2 is used as an SgNB of a DC of an SB, data transfer from an MgNB to an SgNB is possible. In addition, inter-DU routing is possible within the CU of the SgNB.

[0765] This enables communication using a gNB with a CU-DU separated configuration in Option 2 as an SgNB of the DC of the SB.

[0766] In addition, by applying the method disclosed in the sixth embodiment to the MgNB, routing between DUs within the MgNB is possible.

[0767] This enables communication using a gNB with a CU-DU separated configuration in Option 2 as an MgNB for the DC of the SB.

[0768] In the example disclosed above, the method of configuring the inter-DU routing function is the same for the MgNB and the SgNB. In this way, it is possible to provide a common inter-DU routing function for the gNBs, which makes it possible to simplify the configuration of the gNB.

[0769] As another method, the configuration method of the inter-DU routing function may be different between the MgNB and the SgNB. The configuration of the inter-DU routing function may be different depending on other configurations of each gNB.

[0770] In addition, when a gNB has multiple inter-DU routing function configurations, the configuration of the inter-DU routing function may be changed semi-statically or dynamically. The gNB may notify other gNBs or gNBs performing DC of the configuration information of the inter-DU routing function of its own gNB as information on the inter-DU routing function.

[0771] In this way, it is possible to change the inter-DU routing function according to the configuration of each gNB, the load situation at each gNB, etc. It is possible to appropriately reduce the processing load of inter-DU routing at the gNB.

[0772] According to the sixth embodiment, for example, the following configuration is provided.

[0773] A communication system is provided that includes a communication terminal device and a plurality of base station devices configured to be able to wirelessly communicate with the communication terminal device. The plurality of base station devices include a master base station device and a secondary base station device that configure a bearer for the communication terminal device. Each of the master base station device and the secondary base station device includes a plurality of distributed units (DUs) that transmit and receive radio signals to and from the communication terminal device, and a central unit (CU) that controls the plurality of DUs. The master base station device receives downlink data addressed to the communication terminal device from a network device that is higher than the master base station device. The master base station routes the downlink data to the master base station device and the secondary base station device.

[0774] Here, the CU of the master base station device has a function of determining a routing destination DU in the master base station device and a function of transferring downlink data routed to the master base station device to the determined routing destination DU. The CU of the secondary base station device has a function of determining a routing destination DU in the secondary base station device and a function of transferring downlink data routed to the secondary base station device to the determined routing destination DU.

[0775] Alternatively, the CU of the master base station device may have a function of determining a routing destination DU in the master base station device, a function of transferring downlink data routed to the master base station device to the determined routing destination DU, and a function of determining a routing destination DU in the secondary base station device. In this case, the CU of the secondary base station device has a function of transferring downlink data routed to the secondary base station device to the routing destination DU of the secondary base station device determined by the master base station device.

[0776] Alternatively, the CU of the master base station device may have a function of determining a routing destination DU in the master base station device, a function of transferring downlink data routed to the master base station device to the determined routing destination DU, a function of determining a routing destination DU in the secondary base station device, and a function of transferring downlink data routed to the secondary base station device to the routing destination DU of the secondary base station device.

[0777] The above configuration can be modified in various ways based on the disclosures and suggestions of this specification, including embodiment 6. According to the above configuration and modified configurations, the above problems can be solved and the above effects can be obtained.

[0778] Variation 1 of the sixth embodiment In this variant example 1, another method for solving the problem described in embodiment 6, specifically, the problem when a gNB with a CU-DU separated configuration in option 2 is used as an SgNB of an SB, is disclosed.

[0779] The MgNB is provided with a function for determining a routing destination DU for the SgNB. The SgNB is provided with a function for transmitting data to the routing destination DU. The CU of the SgNB is provided with a function for transmitting data to the routing destination DU.

[0780] The function of determining the routing destination DU of the SgNB may be provided below the conventional PDCP function or the PDCP function proposed in NR (Non-Patent Document 22: R3-170266).

[0781] A function for determining a routing destination DU for an SgNB is provided below the routing function for an SB. A function for determining a routing destination DU for an SgNB after routing to the SgNB may also be provided.

[0782] Three examples are disclosed below regarding how to configure the function of determining the routing destination DU of the SgNB within the MgNB.

[0783] (1) A function for determining the routing destination DU is provided within the PDCP.

[0784] (2) Provide a function outside the PDCP to determine the routing destination DU.

[0785] (3) A protocol stack having a function for determining the routing destination DU is provided outside the PDCP.

[0786] Three examples are disclosed below regarding how to configure the function of transmitting data from the MgNB to the destination DU in the CU of the SgNB.

[0787] (1) A function for transmitting data to a routing destination DU is provided in the PDCP in the CU in the SgNB.

[0788] (2) A function for transmitting data to a routing destination DU is provided outside the PDCP in the CU in the SgNB.

[0789] (3) A protocol stack having the function of transmitting data to the routing destination DU is provided in addition to the PDCP in the CU in the SgNB.

[0790] The gNB may be provided with an inter-DU routing function.

[0791] When the gNB becomes an MgNB, the inter-DU routing function is configured for the SgNB. Among the inter-DU routing functions of the SgNB, the function of determining the routing destination DU is enabled, and the function of transmitting data to the routing destination DU is disabled. As another example, when the gNB becomes an MgNB, among the inter-DU routing functions of the SgNB, functions other than the function of determining the routing destination DU may be bypassed or made transparent. In this way, when the gNB becomes an MgNB, it becomes possible to implement the function of determining the routing destination DU of the SgNB in ​​the MgNB.

[0792] When the MgNB has a CU-DU separation configuration of option 2, the inter-DU routing function may be configured for the MgNB. It becomes possible for the MgNB to implement the inter-DU routing function of its own gNB.

[0793] When the gNB becomes an SgNB, the function of determining the routing destination DU among the inter-DU routing functions is disabled, and the function of transmitting data to the routing destination DU is enabled. As another example, when the gNB becomes an SgNB, among the inter-DU routing functions, other functions other than the function of transmitting data to the routing destination DU may be bypassed or transparent. In this way, when the gNB becomes an SgNB, it is possible to implement the function of transmitting data to the routing destination DU in the SgNB.

[0794] The MgNB determines the SgNB's routing destination DU for data sent to the SgNB by implementing a function to determine the SgNB's routing destination DU, and sends the data to the SgNB. The SgNB can transmit data sent from the MgNB to each DU by implementing a function to transmit data to the routing destination DU.

[0795] On the receiving side, the SgNB is provided with a function for routing data from each DU to the MgNB. The function for routing data from each DU to the MgNB may be one of the inter-DU routing functions. Alternatively, the function for routing data from each DU to the MgNB may be one of the functions for transmitting data to the routing destination DU. As a function on the receiving side, data from each DU is routed to the MgNB in ​​the order of arrival. In other words, data from each DU is sent to the MgNB one by one in the order of arrival.

[0796] Alternatively, data from each DU may be routed to the MgNB in ​​the order of PDCP-SN (sequence number), i.e., data from each DU is routed in the order of PDCP-SN and sent to the MgNB one by one.

[0797] The MgNB may be provided with a function for transmitting data transmitted from the SgNB to the upper function. In this case, the MgNB may delete information that is not required by the upper function and transmit the deleted data to the upper function. The function for transmitting data transmitted from the SgNB to the upper function may be one of the inter-DU routing functions. Alternatively, the function for transmitting data transmitted from the SgNB to the upper function may be one of the functions for determining the routing destination DU.

[0798] By doing this, it becomes possible for the receiving side to transmit data from each DU of the SgNB to the MgNB.

[0799] For the above-mentioned configuration methods (1) to (3) of the function for determining the routing destination DU, and the above-mentioned configuration methods (1) to (3) of the function for transmitting data to the routing destination DU, it is advisable to appropriately apply the configuration method of the inter-DU routing function disclosed in embodiment 6.

[0800] Figure 48 is a diagram showing an example of an architecture in which the MgNB is provided with a function for determining the routing destination DU of the SgNB, and the PDCP in the CU of the SgNB is provided with an inter-DU routing function. Figure 48 shows the case of Option 2 CU-DU separation configuration for both the MgNB and the SgNB.

[0801] The MgNB consists of a CU and a DU. Two DUs (DU#1, DU#2) are connected to one CU. RRC, New AS Layer, and PDCP are configured in the CU. RLC, MAC, and PHY are configured in the DU.

[0802] The SgNB is composed of a CU and a DU. Two DUs (DU#1, DU#2) are connected to one CU. RRC is configured in the CU of the SgNB. RLC, MAC, and PHY are configured in the DU. Since the SgNB is a secondary gNB of a UE that performs DC, a New AS Layer and PDCP are not configured in the CU in the conventional configuration. However, in the first modification of the sixth embodiment, PDCP is provided in the CU.

[0803] The PDCP in the CU of the MgNB is provided with a function for determining a routing destination DU of the gNB itself and a function for transmitting data to the determined routing destination DU. Instead of the function for determining a routing destination DU and the function for transmitting data to the determined routing destination DU, an inter-DU routing function may be provided.

[0804] The PDCP in the CU of the MgNB is provided with a function for determining a routing destination DU of the SgNB. The PDCP in the CU of the SgNB is provided with a function for transmitting data to the routing destination DU.

[0805] The MgNB notifies the SgNB of information indicating the SgNB's routing destination DU determined by the MgNB in ​​relation to data to be transmitted to the SgNB. By receiving this information, the SgNB can recognize to which DU the data transmitted from the MgNB should be transmitted.

[0806] This enables the SgNB to transmit data transmitted from the MgNB to the routing destination DU determined by the MgNB.

[0807] The interface for data communication between the MgNB and the SgNB may be the interface disclosed in the sixth embodiment.

[0808] On the receiving side, the data from each DU is routed to the MgNB by a function provided in the PDCP configured in the CU of the SgNB, which is a function for routing data from each DU to the MgNB. For example, the SgNB routes and transmits data from each DU to the MgNB in ​​the order of arrival.

[0809] In the MgNB, a function configured in the MgNB, which is a function for transmitting data transmitted from the SgNB to a higher-level function, transmits the data from the SgNB to the higher-level function.

[0810] By adopting this method, the existing protocol stack PDCP can be reused in the SgNB, making it easier to configure the gNB. It becomes easier to use the gNB with the CU-DU separation configuration of Option 2 as a secondary for the DC.

[0811] gNBs may notify each other of information indicating whether or not their own gNBs have a CU-DU separation configuration.

[0812] gNBs may notify each other of information on DUs of their own gNBs. As information on DUs, information on DUs connected to CUs of their own gNBs may be notified. As information on DUs, information on each DU and information on CUs to which the DUs are connected may be associated and notified.

[0813] In this first modification, unlike the method disclosed in the sixth embodiment, the MgNB has a function of determining the SgNB's routing destination DU. Therefore, by doing so, the master gNB can recognize information indicating the presence or absence of the CU-DU separation configuration of the secondary gNB and information about the DU. The MgNB can determine the SgNB's routing destination DU in consideration of these pieces of information.

[0814] The DU information may be a DU identifier.

[0815] The DU identifier may be associated with a gNB or cell identifier, and the DU information may be an address of the DU.

[0816] For example, the DU identifier is composed of a gNB identifier and a DU identifier within the gNB. Alternatively, the DU identifier is composed of a cell identifier and a DU identifier within the cell. In this way, by associating with the identifier of the gNB or cell, it is possible to recognize which gNB constitutes the DU.

[0817] The information of the DU notified between gNBs may be limited to information about the DU that can be used to transmit and receive data from other gNBs. For example, the information of the DU notified between gNBs may be limited to information about the DU that can be used for DC. In this way, it is possible to reduce the amount of information notified between gNBs.

[0818] The information on the CU to which the DU is connected may be a CU identifier, using a method similar to that for the DU identifier described above.

[0819] Information indicating the presence or absence of a CU-DU separation configuration and DU information may be notified between gNBs when setting up an interface between gNBs. The information indicating the presence or absence of a CU-DU separation configuration of the gNB itself and DU information may be included in a setup message to notify other gNBs of the information.

[0820] Alternatively, the above information may be notified when updating the gNB configuration. The gNB may notify other gNBs of the information by including information indicating the presence or absence of a CU-DU separation configuration of the gNB or information on the DU in a gNB configuration update message.

[0821] The other gNBs mentioned above may be neighboring gNBs.

[0822] In this way, by notifying the above information at the time of setup or when updating the gNB settings, the MgNB can recognize the DU configuration of the gNB used as a secondary when setting up the DC. This makes it possible for the MgNB to determine the routing destination DU of the SgNB.

[0823] Information indicating the presence or absence of DU separation configuration of the own gNB and information on the DU of the own gNB may be notified at the time of DC setting. It is preferable to apply the method disclosed in the sixth embodiment in which information indicating the presence or absence of CU-DU separation configuration of the own SgNB is notified from the SgNB to the MgNB at the time of DC setting.

[0824] When setting up a DC, the MgNB may notify the SgNB of information requesting the use of the DU of the SgNB for DC. The information may include the number of DUs to be used in the DC.

[0825] For example, when an SgNB is added (SgNB addition), the MgNB may notify the SgNB of the above-mentioned request. The above-mentioned request may be included in signaling of SgNB addition that the MgNB requests the SgNB to add.

[0826] Alternatively, when an SgNB modification is performed, the MgNB may notify the SgNB of the above-mentioned request. The above-mentioned request may be included in signaling of an SgNB modification that the MgNB requests the SgNB.

[0827] In this way, the SgNB can recognize the number of DUs that the MgNB needs in the DC. The SgNB can avoid setting an excessive number of DUs in the DC. Also, the SgNB can avoid setting an insufficient number of DUs in the DC.

[0828] When DC is set, the SgNB may notify the MgNB of information about DUs available for DC in the SgNB. The information about DUs includes DU identifiers, information about the number of available DUs, and the like.

[0829] For example, when an SgNB is added (SgNB addition), the SgNB may notify the MgNB of the above information. The above information may be included in signaling for notifying a response to a request for SgNB addition.

[0830] Alternatively, when an SgNB modification is performed, the SgNB may notify the MgNB of the above information. The above information may be included in signaling that notifies a response to a request for SgNB modification.

[0831] In this way, the SgNB can notify the MgNB of the number of DUs available in the DC according to the resources and load status of the gNB itself. Since the MgNB can recognize the number of DUs of the SgNB that can be used in the DC, it is possible to appropriately perform routing to each gNB for the SB.

[0832] The buffer configuration of the SgNB and information transmitted between the MgNB and the SgNB are disclosed.

[0833] A buffer for routing is provided in the CU of the SgNB. The buffer may be provided in the PDCP in the CU of the SgNB, or may be provided outside the PDCP in the CU. The buffer may be provided between the function for determining the routing destination DU configured in the MgNB and the function for transmitting data to the routing destination DU configured in the CU of the SgNB. The buffer may be provided above the function for transmitting data to the routing destination DU configured in the CU of the SgNB.

[0834] Figure 49 is a diagram showing an example of architecture when one buffer for routing is provided in the CU of the SgNB. Figure 49 shows an example in which the buffer is provided outside the PDCP in the CU of the SgNB. In Figure 49, the buffer is provided above the function configured in the CU of the SgNB that transmits data to the routing destination DU.

[0835] When SB DC is implemented for the target UE, data transmitted from the MgNB is temporarily stored in the buffer provided in the CU of the SgNB, thereby making it possible to reduce data loss due to delays in the function of transmitting data to the next routing destination DU.

[0836] A similar buffer may also be provided on the receiving side. By temporarily storing data received from each DU before sending it to the MgNB, it is possible to reduce data loss at the interface that transmits data from the SgNB to the MgNB.

[0837] The information notified from the MgNB to the SgNB includes information associated with DL data. The information associated with DL data is, for example, a sequence number assigned on the interface between the MgNB and the SgNB. When Xn or Xx is provided, the sequence number assigned on the interface may be the information associated with DL data. For example, Xn-U SN or Xx-U SN.

[0838] Also, as other information notified from the MgNB to the SgNB, information indicating the routing destination DU of the SgNB may be notified. The information indicating the routing destination DU of the SgNB may be included in information associated with DL data and notified. The MgNB can route data transmitted to the SgNB to the routing destination DU determined by the MgNB.

[0839] A sequence number may be assigned to each routing destination DU on the interface between the MgNB and the SgNB, allowing the SgNB to determine data lost on the interface between the MgNB and the SgNB for each DU.

[0840] In addition, as other information notified from the MgNB to the SgNB, information indicating the destination gNB may be notified. In addition, as other information, information indicating the source gNB may be notified. When multiple SgNBs are used, the SgNB can verify whether the received data is data transmitted to the own gNB and from which MgNB the received data is transmitted. Therefore, it is possible to reduce malfunctions during DC of SBs using multiple SgNBs.

[0841] When SB DC is performed using multiple SgNBs, the routing function for SBs within the MgNB may determine to which SgNB the MgNB routes the transmitted data.

[0842] As the information notified from the SgNB to the MgNB, the information disclosed in the sixth embodiment, specifically, the information on the transmission status of DL data notified from the SgNB to the MgNB, may be applied. Similar effects can be obtained.

[0843] Of the information notified from the SgNB to the MgNB disclosed in the sixth embodiment, the PDCP-SN that was successfully or unsuccessfully transmitted to the UE may not be notified. This makes it possible to reduce the amount of information notified from the SgNB to the MgNB. The MgNB determines whether the PDCP-SN was successfully or unsuccessfully transmitted from the SgNB to the UE.

[0844] For example, the PDCP of the MgNB assigns a PSCP-SN to data before routing for SB, and manages which gNB the data is routed to after routing for SB. The UE transmits a PDCP status report to the MgNB. The status report may be transmitted via the SgNB or directly to the MgNB. Since a gNB or DU with good communication quality can be used, the reliability of communication is improved.

[0845] In this way, the MgNB can determine which PDCP-SNs were successfully or unsuccessfully transmitted from the SgNB to the UE.

[0846] Since the SgNB does not need to determine whether a PDCP-SN was successfully or unsuccessfully transmitted to the UE, the functionality of the SgNB can be reduced, making it easier to configure the SgNB.

[0847] Of the information notified from the SgNB to the MgNB disclosed in the sixth embodiment, the buffer size information may not be notified. This makes it possible to reduce the amount of information notified from the SgNB to the MgNB. For example, the MgNB sets a bearer for the SgNB and measures the amount of PDCP-PDUs transmitted to the SgNB.

[0848] In this manner, the MgNB can determine information on the desired buffer size for the bearer to be the SB target in the SgNB, information on the minimum buffer size desired for the UE to be the SB target, and the like.

[0849] Since the SgNB does not need to determine the desired buffer size for the bearer to be SBed at the SgNB, the minimum desired buffer size for the UE to be SBed, etc., the functionality of the SgNB can be reduced and the SgNB can be easily configured.

[0850] The information notified from the SgNB to the MgNB may be an amount indicating the buffer margin of the SgNB. The SgNB determines the free space of the buffer of the SgNB and notifies the MgNB. In this way, the MgNB can perform routing of the PDCP-PDU for the SB, taking into account the buffer margin of the SgNB.

[0851] The amount indicating the buffer headroom of the SgNB may be an amount indicating the buffer headroom fo...

Claims

1. A user device; A base station device including a plurality of distributed units (DUs) capable of wirelessly communicating with the user equipment, and a central unit (CU) connected to the plurality of DUs, the base station device being configured such that the CU and the DU transmit and receive information to each other via an interface between the CU and the DU; A communication system comprising: The user equipment reports a measurement result on a downlink reference signal to the CU; The CU determines a DU to be used for wireless communication with the user equipment based on the measurement result; The CU further comprises: receiving information regarding a buffer amount from one DU of the plurality of DUs; determining a DU whose buffer amount is greater than a predetermined value as a DU to be used for wireless communication with the user equipment; Communication systems.

2. At least one of the plurality of DUs transmits status information indicating the number of user devices connected to the DU to the CU in response to request information from the CU. The communication system according to claim 1 .

3. A DU to be used for wireless communication with the user equipment is determined from the plurality of candidate DUs determined by the CU. The communication system according to claim 1 .

4. The CU determines a plurality of candidate DUs; The user equipment determines a DU to be used for wireless communication with the user equipment from among a plurality of candidate DUs. The communication system according to claim 1 .

5. The plurality of DUs includes a primary DU and a secondary DU. The communication system according to claim 1 .

6. The primary DU performs communication in the C-plane.

6. The communication system according to claim 5.

7. When the user equipment communicates with a first DU and a second DU under the CU, The user equipment duplicates a single packet into three packets, transmits one of the three packets in the first DU, and transmits two of the three packets in the second DU. The communication system according to claim 1 .

8. The three duplicated packets are assigned the same sequence number.

8. The communication system according to claim 7.

9. The CU obtains information regarding packet delay from at least one DU of the plurality of DUs. The communication system according to claim 1 .

10. An identifier that is unique among the plurality of DUs under the control of the CU is assigned to each of the plurality of DUs. The communication system according to claim 1 . A split bearer is established for the plurality of DUs. The communication system according to claim 1 .

12. After receiving a response to a communication start instruction, the CU performs RRC reconfiguration for the user equipment. The communication system according to claim 1 .

13. The CU sends an instruction to the DU to stop replicating packets. The communication system according to claim 1 .

14. In the mobility between the multiple DUs, DU addition and DU release are performed in combination. The communication system according to claim 1 .

15. In the mobility between the multiple DUs, one DU notifies the CU of information regarding a PDCP sequence number. The communication system according to claim 1 .

16. The one DU is a source DU, The information about the PDCP sequence number indicates a sequence number corresponding to the last PDCP-PDU among the PDCP-PDUs whose delivery has been confirmed in the one DU.

16. The communication system of claim 15.

17. A user device; A base station device including a plurality of distributed units (DUs) capable of wirelessly communicating with the user equipment, and a central unit (CU) connected to the plurality of DUs, the base station device being configured such that the CU and the DU transmit and receive information to each other via an interface between the CU and the DU; A user equipment in a communication system comprising: The user equipment reports a measurement result on a downlink reference signal to the CU; The measurement result is used by the CU to determine a DU to be used for wireless communication with the user equipment; Information regarding the amount of buffering is transmitted from one of the plurality of DUs to the CU; The information about the buffer amount is used to determine a DU that the CU should use for wireless communication with the user equipment, The user equipment communicates with the CU via a DU in which the buffer amount is greater than a predetermined value. User equipment.

18. A user device; A base station device including a plurality of distributed units (DUs) capable of wirelessly communicating with the user equipment, and a central unit (CU) connected to the plurality of DUs, the base station device being configured such that the CU and the DU transmit and receive information to each other via an interface between the CU and the DU; A CU in a communication system comprising: The CU determines a DU to be used for wireless communication with the user equipment based on a measurement result of a downlink reference signal reported from the user equipment; The CU further comprises: receiving information regarding a buffer amount from one DU of the plurality of DUs; determining a DU whose buffer amount is greater than a predetermined value as a DU to be used for wireless communication with the user equipment; Central unit.

Images