Communication system, user device and base station

Abstract

To provide a high-speed communication system with the high reliability and the low latency under New Radio (NR).SOLUTION: A communication system comprises: a user device (UE); and a plurality of base stations that include a master base station (MgNB) and a secondary base station (SgNB) which constitute dual connectivity. Each of the plurality of base stations comprises: one or more distributed units (DUs) that can wirelessly communicate with the user device (UE); and a central unit (CU) that is connected to the DU. The master base station (MgNB) notifies the secondary base station (SgNB) of a sequence number in an interface between the master base station (MgNB) and the secondary base station (SgNB).SELECTED DRAWING: Figure 49

Description

Technical Field

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

Background Art

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

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

[0004] Regarding the decisions on the frame structure in the LTE system in 3GPP described in Non-Patent Document 1 (Chapter 5), it will be described with reference to FIG. 1. FIG. 1 is an explanatory diagram showing the configuration of a radio frame used in a communication system of the LTE method. In FIG. 1, one radio frame is 10 ms. The radio frame is divided into 10 subframes of equal size. The subframe is divided into 2 slots of equal size. The downlink synchronization signal is included in the first and sixth subframes for each radio frame. The synchronization signal includes a primary synchronization signal (P-SS) and a secondary synchronization signal (S-SS).

[0005] The decisions on the channel configuration in the LTE system in 3GPP 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 even 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 "base station") to a communication terminal device such as a mobile terminal device (hereinafter sometimes simply referred to as "mobile terminal") (hereinafter sometimes simply referred to as "communication terminal"). The BCH transport block is mapped to 4 subframes at 40 ms intervals. There is no explicit signaling at 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 number of OFDM (Orthogonal Frequency Division Multiplexing) symbols used for PDCCHs from the base station to the communication terminal. The PCFICH is transmitted for each subframe.

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

[0009] The Physical Downlink Shared Channel (PDSCH) is a channel for downlink transmission from a base station to a communication terminal. The DL-SCH, which is a transport channel, and the PCH, which is a transport channel, are mapped to the PDSCH.

[0010] The Physical Multicast Channel (PMCH) is a channel for downlink transmission from a base station to a communication terminal. The 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 an Ack / Nack, which is a response signal for downlink transmission. The PUCCH carries a CQI (Channel Quality Indicator) report. The CQI is quality information indicating the quality of received data or the communication channel quality. The PUCCH also carries a Scheduling Request (SR).

[0012] The Physical Uplink Shared Channel (PUSCH) is a channel for uplink transmission from a communication terminal to a base station. The 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 an Ack / Nack, which is a response signal for 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] The downlink reference signal (Reference Signal: RS) is a symbol known as an LTE communication system. The following five types of downlink reference signals are defined: Cell-specific Reference Signal (CRS), MBSFN Reference Signal, Demodulation Reference Signal (DM-RS) which is a UE-specific Reference Signal, Positioning Reference Signal (PRS), and Channel State Information Reference Signal (CSI-RS). As a measurement of the physical layer of a communication terminal, there is a measurement of the received power of the reference signal (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 throughout the coverage of its base station (cell). The BCH is mapped to the Physical Broadcast Channel (PBCH).

[0016] For the downlink shared channel (DL-SCH), retransmission control by HARQ (Hybrid ARQ) is applied. The DL-SCH enables notification to the entire coverage area of the base station (cell). The DL-SCH supports dynamic or semi-static resource allocation. Semi-static resource allocation is also called persistent scheduling. The DL-SCH supports discontinuous reception (DRX) of communication terminals for power consumption reduction of the communication terminals. The 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 requires notification to the entire coverage area of the base station (cell). The PCH is mapped to a physical resource such as the physical downlink shared channel (PDSCH) that can be dynamically used for traffic.

[0018] The multicast channel (MCH) is used for notification to the entire coverage area of the base station (cell). The MCH supports SFN synthesis 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, for the uplink shared channel (UL-SCH), retransmission control by HARQ (Hybrid ARQ) is applied. 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 has a risk of collision. The RACH is mapped to the Physical Random Access Channel (PRACH).

[0021] Hybrid Automatic Repeat reQuest (HARQ) will be described. HARQ is a technology that improves the communication quality of a transmission path by combining Automatic Repeat reQuest (ARQ) and Forward Error Correction. HARQ has the advantage that error correction functions effectively by retransmission even for a transmission path where the communication quality changes. In particular, it is also possible to obtain further quality improvement by combining the reception result of the first transmission and the reception result of the retransmission at the time of retransmission.

[0022] An example of a retransmission method will be described. When the receiving side cannot correctly decode the received data, in other words, when a Cyclic Redundancy Check (CRC) error occurs (CRC = NG), the receiving side transmits "Nack" to the transmitting side. The transmitting side that has received "Nack" retransmits the data. When the receiving side can correctly decode the received data, in other words, when no CRC error occurs (CRC = OK), the receiving side transmits "Ack" to the transmitting side. The transmitting side that has received "Ack" transmits 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 BCCH, which is a logical channel, is mapped to the Broadcast Channel (BCH), which is a transport channel, or the Downlink Shared Channel (DL-SCH).

[0024] The Paging Control Channel (PCCH) is a downlink channel for transmitting paging information and system information changes. 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] The Common Control Channel (CCCH) is a channel for transmission control information between a communication terminal and a base station. The CCCH is used when the communication terminal does not have an RRC connection with the network. In the downlink direction, the CCCH is mapped to the Downlink Shared Channel (DL-SCH), which is a transport channel. In the uplink direction, the CCCH is mapped to the Uplink Shared Channel (UL-SCH), which is a transport channel.

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

[0027] The Dedicated Control Channel (DCCH) is a channel for transmitting dedicated control information between a communication terminal and the network on a one-to-one basis. The DCCH is used when the communication terminal has an RRC connection. In the uplink, the DCCH is mapped to the Uplink Shared Channel (UL-SCH), and in the downlink, it is mapped to the Downlink Shared Channel (DL-SCH).

[0028] The Dedicated Traffic Channel (DTCH) is a one-to-one communication channel to an individual communication terminal for the transmission of user information. The DTCH exists both in the uplink and downlink. In the uplink, the DTCH is mapped to the Uplink Shared Channel (UL-SCH), and in the downlink, it is mapped to the Downlink Shared Channel (DL-SCH).

[0029] The Multicast Traffic Channel (MTCH) is a downlink channel for the transmission of traffic data from the network to a communication terminal. The MTCH is a channel used only by communication terminals during MBMS reception. The MTCH is mapped to the Multicast Channel (MCH).

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

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

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

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

[0034] Location tracking of a communication terminal is performed in units of an area consisting of one or more cells. Location tracking is performed to track the location of the communication terminal even in the standby state and to enable calling the communication terminal, in other words, to enable the communication terminal to be called. The area for this location tracking of the 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 being considered. The HNB in UTRAN and the HeNB in E-UTRAN are base stations for, for example, home, corporate, and commercial access services. 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] In addition, in 3GPP, as Release 10, the standardization of Long Term Evolution Advanced (LTE-A) is in progress (see Non-Patent Document 3 and Non-Patent Document 4). LTE-A is based on the radio interval communication method of LTE and is configured by adding several new technologies thereto.

[0037] In the LTE-A system, in order to support a wider frequency bandwidth (transmission bandwidths) up to 100 MHz, carrier aggregation (CA) is being studied, which aggregates (also referred to as "aggregation") two or more component carriers (CCs). 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 the 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] According to the capabilities of the UE, 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 consisting of one PCell and one or more SCells is configured for one UE.

[0041] Also, as new technologies in LTE-A, there are technologies such as Wider bandwidth extension and Coordinated Multiple Point transmission and reception (CoMP). Regarding CoMP being studied for LTE-A in 3GPP, it is described in Non-Patent Document 1.

[0042] Also, in 3GPP, in order to cope with future huge traffic, it is being studied to use small eNBs (hereinafter sometimes referred to as "small base station devices") that constitute small cells. For example, technologies such as increasing the frequency utilization efficiency and increasing the communication capacity by installing a large number of small eNBs to form a large number of small cells are being studied. Specifically, there is Dual Connectivity (abbreviated as DC) where the UE connects to two eNBs for communication. Regarding DC, it is described in Non-Patent Document 1.

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

[0044] The traffic volume of mobile networks is on an increasing trend, and the communication speed is also accelerating. When LTE and LTE-A are fully launched, further increase in communication speed is expected.

[0045] Furthermore, a fifth-generation (hereinafter sometimes referred to as "5G") radio access system aimed at starting services after 2020 has been studied for advanced mobile communications. For example, in Europe, the requirements for 5G have been summarized by a group called METIS (see Non-Patent Document 5).

[0046] In the 5G radio access system, compared with the LTE system, the system capacity is 1000 times, the data transmission speed is 100 times, the data processing delay is one-tenth (1 / 10), and the number of simultaneously connected communication terminals is 100 times. Further reduction of power consumption and cost of devices are required.

[0047] To meet such requirements, in 3GPP, the standard study of 5G is underway as Release 14 (see Non-Patent Documents 6 to 10). The technology of the 5G radio section is called "New Radio Access Technology" (abbreviated as "New Radio" is "NR"), and several new technologies are being studied (see Non-Patent Documents 11 to 14). For example, packet duplication using DC or multi-connectivity (abbreviated as MC), separation of the CU (Central Unit) and DU (Distributed Unit) of the gNB, etc. are being studied.

Prior Art Documents

Non-Patent Documents

[0048] [Non-Patent Document 1] 3GPP TS 36.300 V14.0.0 [Non-Patent Document 2] 3GPP S1-083461 [Non-Patent Document 3] 3GPP TR 36.814 V9.0.0 [Non-Patent Document 4] 3GPP TR 36.912 V13.0.0 [Non-Patent Document 5] “Scenarios, requirements and KPIs for 5G mobile and wireless system”, ICT-317669-METIS / D1.1 [Non-Patent Document 6] 3GPP TR 23.799 V1.1.0 [Non-Patent Document 7] 3GPP TR 38.801 V14.0.0 [Non-Patent Document 8] 3GPP TR 38.802 V1.0.0 [Non-Patent Document 9] 3GPP TR 38.804 V1.0.0 [Non-Patent Document 10] 3GPP TR 38.912 V0.0.2 [Non-Patent Document 11] 3GPP R2-1700672 [Non-Patent Document 12] 3GPP R2-1700172 [Non-Patent Document 13] 3GPP R2-1700982 [Non-Patent Document 14] 3GPP R2-1701472 [Non-Patent Document 15] 3GPP TS 36.423 v14.2.0 [Non-Patent Document 16] 3GPP TS 36.311 v14.2.1 [Non-Patent Document 17] CPRI Specification V7.0 [Non-Patent Document 18] 3GPP R2-1701461

Non-Patent Document 19

Non-Patent Document 20

Non-Patent Document 21

Non-Patent Document 22

Non-Patent Document 23

Summary of the Invention

Problems to be Solved by the Invention

[0049] In NR, in order to increase the number of UEs accommodated per gNB, it has been proposed to separate the gNB into two units, namely, a CU (Central Unit) and a DU (Distributed Unit), and make it possible to connect a plurality of DUs to the CU. Also, in NR, it has been proposed to provide communication that satisfies high reliability and low latency by using packet duplication in which the same packet is transmitted and received at each gNB using a DC or MC configuration.

[0050] In NR, it has been proposed to perform packet duplication using a plurality of DUs. However, since the DC or MC configuration cannot be directly applied between DUs, communication by packet duplication using a plurality of DUs cannot be provided. Therefore, communication that satisfies high reliability and low latency cannot be provided.

[0051] Also, in NR, in the case of using a plurality of DUs, 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. For this reason, data transmission from the MgNB to the DU under the SgNB becomes impossible, resulting in a problem that 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, greatly reducing the usage efficiency of radio resources.

[0052] In view of the above problems, one object of the present invention is to provide a communication system in NR that is fast, highly reliable, and has low latency.

Means for Solving the Problems

[0053] According to the present invention, for example, a communication system is provided that includes a user device and a plurality of base stations including a master base station and a secondary base station that constitute dual connectivity, and each of the plurality of base stations includes one or more distributed units (DUs) capable of wireless communication with the user device and a central unit (CU) connected to the DU, and the master base station notifies the secondary base station of a sequence number at an interface between the master base station and the secondary base station.

Effects of the Invention

[0054] According to the present invention, in NR, a communication system or the like that is fast, highly reliable, and has low latency can be provided.

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

Brief Description of the Drawings

[0056]

Figure 1

Figure 2

Figure 3

Figure 4

Figure 5

Figure 6

Figure 7

Figure 8

Figure 9

Figure 10

Figure 11

Figure 12

Figure 13

Figure 14

Figure 15

Figure 16

Figure 17

Figure 18

Figure 19

Figure 20

Figure 21

Figure 22

Figure 23

Figure 24

Figure 25

Figure 26

Figure 27

Figure 28

Figure 29

Figure 30

Figure 31

Figure 32

Figure 33

Figure 34

Figure 35

Figure 36

Figure 37

Figure 38

Figure 39

Figure 40

Figure 41

Figure 42

Figure 43

Figure 44

Figure 45

Figure 46

Figure 47

Figure 48

Figure 49

Figure 50

Figure 51

Figure 52

Figure 53

Figure 54

Figure 55

Figure 56

Figure 57

Modes for Carrying Out the Invention

[0057] Embodiment 1. Figure 2 is a block diagram showing the overall configuration of a communication system 200 of the LTE system being discussed in 3GPP. An explanation of Figure 2 will be given. The radio access network is referred to as E-UTRAN (Evolved Universal Terrestrial Radio Access Network) 201. A mobile terminal device (hereinafter simply referred to as "mobile terminal (User Equipment: UE)") 202, which is a communication terminal device, can communicate wirelessly with a base station device (hereinafter referred to as "base station (E-UTRAN NodeB: eNB)") 203 and performs signal transmission and reception through wireless communication.

[0058] Here, the "communication terminal device" includes not only mobile terminal devices such as mobile phone terminal devices that can move, but also non-mobile devices such as sensors. In the following description, the "communication terminal device" may sometimes be simply referred to as the "communication terminal".

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

[0060] The control protocol RRC (Radio Resource Control) between the mobile terminal 202 and the base station 203 performs functions such as broadcast, paging, and RRC connection management. As the states of the base station 203 and the mobile terminal 202 in RRC, there are RRC_IDLE and RRC_CONNECTED.

[0061] In RRC_IDLE, PLMN (Public Land Mobile Network) selection, system information (SI) notification, 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. Also in RRC_CONNECTED, handover (HO), measurement of neighbour cells, etc. are performed.

[0062] The base station 203 is classified into eNB 207 and 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. Also, a system composed of the EPC (Evolved Packet Core) which is a core network and the E-UTRAN 201 which is a radio access network is called an EPS (Evolved Packet System). The core network EPC and the radio access network E-UTRAN 201 together may be referred to as the "network".

[0063] The eNB 207 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 the "MME unit") 204 including the MME and the S-GW by an S1 interface, and control information is communicated between the eNB 207 and the MME unit 204. A plurality of MME units 204 may be connected to one eNB 207. The eNBs 207 are connected by 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 the 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 the HeNBGW (Home-eNB GateWay) 205. The Home-eNB 206 and the HeNBGW 205 are connected by the S1 interface, and the HeNBGW 205 and the MME unit 204 are connected via the S1 interface.

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

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

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

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

[0069] The base station 203 may constitute one cell or a plurality of cells. Each cell has a range predetermined as coverage within which it can communicate with the mobile terminal 202, and performs wireless communication with the mobile terminal 202 within the coverage. When one base station 203 constitutes a plurality of cells, each individual 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, and encoding processing 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 undergoing encoding processing. The data encoded by the encoder unit 304 is subjected to modulation processing in 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 to a wireless transmission frequency. Thereafter, a transmission signal is transmitted from the antenna 307 to the base station 203.

[0071] Also, the reception process of the mobile terminal 202 is executed as follows. A wireless signal from the base station 203 is received by the antenna 307. The received signal is converted from the wireless reception frequency to a baseband signal by the frequency conversion unit 306, and demodulation processing is performed in the demodulation unit 308. The demodulated data is passed to the decoder unit 309, and decoding processing such as error correction is performed. Among 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 are controlled by the control unit 310. Therefore, although omitted in FIG. 3, the control unit 310 is connected to each of the units 301 to 309.

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

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

[0074] Also, 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 the antenna 408. The received signal is converted from the radio reception frequency to a baseband signal in the frequency conversion unit 407, and demodulation processing is performed in the demodulation unit 409. The demodulated data is passed to the decoder unit 410, and decoding processes such as error correction are performed. Among the decoded data, the control data is passed to the protocol processing unit 403, the EPC communication unit 401, or the 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 are controlled by the control unit 411. Therefore, although omitted in Figure 4, the control unit 411 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. In FIG. 5, the configuration of the MME 204a included in the MME unit 204 shown in FIG. 2 described above is shown. 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 via the S1 interface between the MME 204a and the base station 203. When 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 plain communication unit 503 and transmitted to one or more base stations 203. When 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 plain 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 plain 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 plain control unit 505.

[0077] The HeNBGW communication unit 504 is provided when the HeNBGW 205 exists and transmits and receives data via the interface (IF) between the MME 204a and the HeNBGW 205 according to the information type. The control data received from the HeNBGW communication unit 504 is passed from the HeNBGW communication unit 504 to the control plain control unit 505. The result of the processing in the control plain control unit 505 is transmitted to the PDN GW via the PDN GW communication unit 501. Also, the result processed in the control plain control unit 505 is transmitted to one or more base stations 203 via the base station communication unit 502 by the S1 interface and to one or more HeNBGWs 205 via the HeNBGW communication unit 504.

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

[0079] The MME 204a distributes paging signals to one or more base stations 203. Also, the MME 204a performs mobility control in the idle state. The MME 204a manages the tracking area list when the mobile terminal is in the standby state and in the active state. The MME 204a initiates the paging protocol by transmitting a paging message to a cell belonging to the tracking area (tracking area) in which the UE is registered. The management of the CSG of the Home-eNB 206 connected to the MME 204a, the management of the CSG ID, and the management of the white list may be performed by the idle state mobility management unit 505-3.

[0080] Next, an example of a cell search method in a communication system is shown. FIG. 6 is a flowchart showing an overview from cell search to standby operation performed by a communication terminal (UE) in an LTE communication system. When the communication terminal starts cell search, in step ST601, it synchronizes the slot timing and frame timing using the first synchronization signal (P-SS) and the second synchronization signal (S-SS) transmitted from surrounding base stations.

[0081] The P-SS and S-SS are combined and called the synchronization signal (SS). A synchronization code corresponding one-to-one to the PCI assigned to each cell is assigned to the synchronization signal (SS). 504 types of PCI are being considered. Synchronization is performed using these 504 types of PCI, and the PCI of the synchronized cell is detected (identified).

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

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

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

[0085] Next, in step ST605, based on the cell configuration information in the MIB, the DL - SCH of the cell is received to obtain the SIB (System Information Block) 1 in the notification information BCCH. The SIB1 contains information related to access to the cell, information related to cell selection, and scheduling information for other SIBs (SIBk; k is an integer greater than or equal to 2). Also, the SIB1 contains the 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 part of the Tracking Area Identity (TAI) in the tracking area list already held by the communication terminal. The tracking area list is also referred to as the TAI list. The TAI is identification information for identifying a tracking area and is composed of an MCC (Mobile Country Code), an MNC (Mobile Network Code), and a TAC (Tracking Area Code). The MCC is the country code. The MNC is the network code. The TAC is the code number of the tracking area.

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

[0088] The device constituting the core network (hereinafter sometimes referred to as the "core network side device") updates the tracking area list based on the identification number (such as UE-ID) of the communication terminal sent from the communication terminal together with the TAU request signal. The core network side device 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. Thereafter, the communication terminal enters the standby operation in the cell.

[0089] Due to the spread of smartphones and tablet-type terminal devices, traffic by cellular wireless communication has increased explosively, and a shortage of radio resources is a concern worldwide. In response to this, in order to improve the frequency utilization efficiency, it has been studied to reduce the cell size and proceed with spatial separation.

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

[0091] When the cell size is reduced, a cell constituted by an eNB has a coverage area that is narrower than the coverage area of a cell constituted by a conventional eNB. Therefore, in order to cover a certain area as in the conventional case, a larger number of small-sized eNBs are required compared to 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 the eNB constituting the macro cell is referred to as a "macro eNB". Also, a cell with a relatively small coverage, such as a small cell, is referred to as a "small cell", and the eNB constituting the small cell is referred to as a "small eNB".

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

[0094] The small eNB may be, for example, a low-power node, a local area node, a hot spot, etc. Also, the small eNB may be a pico eNB constituting a pico cell, a femto eNB constituting a femto cell, a HeNB, an RRH (Remote Radio Head), an RRU (Remote Radio Unit), an RRE (Remote Radio Equipment), or an RN (Relay Node). Also, the small eNB may be a "Local Area Base Station" or a "Home Base Station" described in Non-Patent Document 7.

[0095] FIG. 7 is a diagram showing a concept of the cell configuration when a macro eNB and a small eNB coexist. The macro cell configured by the macro eNB has a relatively wide coverage area 701. The small cell configured by the small eNB has a coverage area 702 that is smaller in range compared to the coverage area 701 of the macro eNB (macro cell).

[0096] When multiple eNBs coexist, the coverage of a cell formed by a certain eNB may be included within the coverage of a cell formed by another eNB. In the cell configuration shown in FIG. 7, as indicated by reference numeral "704" or "705", the coverage 702 of a small cell formed by a small eNB may be included within the coverage 701 of a macro cell formed by a macro eNB.

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

[0098] Also, in the cell configuration shown in FIG. 7, as indicated by reference numeral "706", a case may occur where the coverage 701 of a macro cell formed by a macro eNB and the coverage 702 of a small cell formed by a small eNB overlap complexly.

[0099] Also, as indicated by reference numeral "707", a case may occur where the coverage 701 of a macro cell formed by a macro eNB and the coverage 702 of a small cell formed by a small eNB do not overlap.

[0100] Furthermore, as indicated by reference numeral "708", a case may occur where the coverages 702 of a number of small cells formed by a number of small eNBs are configured within the coverage 701 of one macro cell formed by one macro eNB.

[0101] As one of the services in NR, there is URLLC (Ultra Reliability, Low Latency Communication) which requires low-latency and high-reliability communication. In order to simultaneously meet low latency and high reliability, it has been agreed in the 3GPP standardization meeting that AM (Acknowledged Mode) is not used in the RLC layer in URLLC. Also, in order to ensure reliability by using UM (Unacknowledged Mode) in the RLC layer, it has been agreed in the 3GPP standardization meeting to support packet duplication in the PDCP layer (see Non-Patent Document 11 (3GPP R2-1700672)). In NR, it has been proposed to use the aforementioned packet duplication in the configurations of DC and MC (see Non-Patent Document 12 (3GPP R2-1700172)).

[0102] Also, in 3GPP, it has been proposed that the gNB be separated into two units (see Non-Patent Document 7). These two units are referred to as CU (Central Unit) and DU (Distributed Unit) respectively. A plurality of DUs are connected to the CU. Regarding the functional division between the CU and the DU in CU-DU separation, a plurality of options have been proposed. For example, as Option 2, it has been proposed that the CU has PDCP and the DU has RLC, MAC, and PHY. Also, as Option 3, it has been 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 has been proposed that the L-RLC of Option 3 has the function of RLC-PDU segmentation, and the H-RLC of Option 3 has the function of delivery confirmation and other functions of RLC.

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

[0104] However, in the DU, since there is no distinction between the master base station and the secondary base station in the DC and MC, the configurations and sequences of the DC or MC cannot be directly applied to the 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 achieved.

[0105] In addition, since the mobility sequence between DUs is not disclosed, the UE cannot switch to the corresponding DU even when it moves. Therefore, a problem occurs in that stable communication cannot be provided when the UE moves.

[0106] Also, since the configurations and sequences of the DC or MC cannot be directly applied to the communication between DUs, the CU cannot provide packet replication communication using multiple DUs. Therefore, a problem occurs in that communication satisfying high reliability and low latency cannot be provided.

[0107] Embodiment 1 discloses a method for solving such problems.

[0108] The CU replicates the packets transferred from the upper network device. The CU transfers the replicated packets to each DU. Each DU transmits the packets to the UE. The UE performs duplicate detection of the packets. The UE deletes the duplicate packets. In the above-mentioned duplicate detection and deletion, the UE may, for example, make only one of the same packets received repeatedly valid and delete the rest.

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

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

[0111] In addition, the UE duplicates the packets and transmits them to each DU via the lower-layer entities facing each DU. Each DU transfers the received packets to the CU. The CU performs duplicate detection on the packets received from the DU. The CU deletes the duplicate packets. In the above-mentioned duplicate detection and deletion, the CU may, for example, make only one of the same packets received repeatedly valid and delete the rest. The CU transfers the packets that have not been deleted to the upper-layer network device.

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

[0113] The CU may transfer the duplicated packets to all the DUs under its control. Similarly, the UE may transmit the duplicated packets to all the DUs under the control of the opposing CU. This can increase the redundancy of communication and improve the reliability.

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

[0115] The DU that transfers the duplicated packets from the CU (hereinafter, may be referred to as the used DU in downlink communication) may be different from the DU that transmits the duplicated packets from the UE (hereinafter, may be referred to as the used DU in uplink communication). Also, the number of used DUs in downlink communication may be different from the number of used DUs in uplink communication. This allows for flexible setting of the communication path.

[0116] In the above, the number of used DUs in downlink communication may be one, two, or three or more. The same may apply to the number of used DUs in uplink communication. This can efficiently improve the reliability.

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

[0118] As described above, the used DU may be set for each UE. For example, when a certain CU has DUs #1 to #3 under its control, in communication with UE#1, the CU may use DUs #1 and #2. Also, in communication with UE#2, the CU may use DUs #2 and #3. This makes it possible to construct an optimal communication system according to the position of the UE.

[0119] As described above, the used DU may be set according to the combination of each CU and each UE. For example, in communication with UE#1, CU#1 may use DUs #1 and #2 among the subordinate DUs #1 to #3, and CU#2 may use DUs #4 and #6 among the subordinate DUs #4 to #6. Also, in communication with UE#2, CU#1 may use DUs #2 and #3, and CU#2 may use DUs #4 to #6. This makes it possible to construct an optimal communication system according to the positional relationship and communication path between each CU and each DU.

[0120] The CU may determine the used DU.

[0121] As examples of the information used by the CU for the above determination, the following (1) to (5) are disclosed.

[0122] (1) Measurement results obtained by the subordinate DUs. For example, uplink signal measurement results.

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

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

[0125] (4) Load status of CU.

[0126] (5) Combination of the above (1) to (4).

[0127] According to the above (1), it is no longer necessary to notify the measurement results from the UE to the CU, so the signaling amount in the radio section can be reduced.

[0128] In the above (1), the DU may measure the uplink reference signal (uplink RS). By this, the DU can measure the uplink signal regardless of the presence or absence of user data. Alternatively, the DU may measure the uplink data error rate. By this, the DU can reduce the time for the measurement process of the uplink signal. The DU may measure the bit error rate (BER) before error correction processing as the above error rate. By this, the DU can obtain a measurement result that accurately reflects the status of the radio channel. Also, the DU may measure the block error rate (BLER) after error correction processing. By this, the DU can shorten the time for the measurement result acquisition process.

[0129] According to the above (2), the same processing as the measurement result acquisition processing in the existing LTE communication system can be used, so the complexity in the design of the communication system can be avoided.

[0130] In the foregoing (2), the UE may measure the downlink reference signal (downlink RS). By doing so, the UE can obtain the measurement result of the downlink signal regardless of the presence or absence of user data. Alternatively, the UE may measure the error rate of the downlink data. By doing so, the UE can reduce the time for the measurement process of the uplink signal. As the foregoing error rate, the UE may measure the bit error rate (BER) before the error correction process. By doing so, the UE can obtain a measurement result that accurately reflects the status of the radio channel. Further, the UE may measure the block error rate (BLER) after the error correction process. By doing so, the UE can shorten the time for the measurement result acquisition process.

[0131] The UE may notify the CU of the information in the foregoing (2). The UE may notify the information via the DU. The UE may notify the DU of the information using L1 / L2 signaling. By doing so, a prompt notification according to the change in the channel status becomes possible. Alternatively, MAC signaling may be used. Since MAC signaling can use multi-value modulation, the number of symbols can be reduced. Alternatively, RRC signaling may be used. By using RRC signaling, the transfer process of the information in the DU to the CU becomes easier.

[0132] When notifying the CU of the information from the UE, the DU used for camping on by the UE may be the serving DU. By doing so, it becomes possible to shorten the time required for the connection from the UE to the DU.

[0133] Alternatively, the DU with which the connection to the UE is established may be the serving DU. The DU with which the connection to the UE is established may be, for example, the DU for which the random access process has been completed. Alternatively, for example, the DU for which the RRC connection has been established may be used. By doing so, for example, even when the DU used for camping on is different from the DU with which the current connection is established due to mobility, the notification from the UE to the CU becomes possible.

[0134] Alternatively, when notifying the information from the UE to the CU, a plurality of DUs may be serving DUs. The aforementioned plurality of DUs may be, for example, a combination of the DU at the time of camping on and the DU with which the connection to the UE is established, or may be a plurality of DUs with which the connection to the UE is established. This improves the reliability of the notification.

[0135] As the load situation in (3) above, for example, a resource situation or an available resource situation may be used. As the aforementioned resource situation, radio resources may be used. By this, the CU can communicate with the UE using a DU that can secure a wideband on the radio channel. Alternatively, a buffer amount may be used. The buffer amount may be, for example, (a) the buffer amount in the RLC layer, (b) the buffer amount in HARQ, or an amount obtained by summing the aforementioned (a) and (b). By this, the CU can select a DU while avoiding congestion of user data.

[0136] Alternatively, as the load situation in (3) above, for example, the number of connected UEs may be used. By this, for example, the CU can allocate a large-capacity communication to a DU with a small number of connected UEs, so that it is possible to efficiently perform the allocation of DUs.

[0137] By using (3) above, the CU can select a DU in consideration of the communication situation with other UEs.

[0138] As the load situation of the aforementioned (4), for example, the buffer amount may be used. The buffer amount may be, for example, (a) the buffer amount in a newly established layer above PDCP in the U-Plane of NR, (b) the buffer amount in the PDCP layer, or alternatively, the sum of the aforementioned (a) and (b). The aforementioned buffer amount may be a value for each opposing UE, or a value obtained by summing the opposing UEs. As a result, for example, flexible control such as using a plurality of serving DUs when the buffer amount is large and using one serving DU when the buffer amount is small becomes possible.

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

[0140] When determining the DU (hereinafter sometimes referred to as the serving DU) used for communication between the CU and the UE using the aforementioned (1) to (5), a threshold may be set. The CU may determine the serving DU using the threshold. For example, when the reception strength of the uplink reference signal received from the 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 buffer amount 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 can facilitate the determination of the serving DU in the CU.

[0141] In the communication between the CU and the DU, the CU-DU interface may be used. As the aforementioned CU-DU interface, for example, the Fs interface (see Non-Patent Document 7) may be used. The Fs interface may be used when the CU requests the aforementioned information (1) to (3) and (5) from the DU, or when the DU notifies the aforementioned information (1) to (3) and (5) to the CU. The CU may request the aforementioned information (1) to (3) and (5) from the DU by piggybacking on the user data, or may request it independently. Also, the DU may notify the aforementioned information (1) to (3) and (5) to the CU by piggybacking on the user data, or may notify it independently. The piggybacking of the aforementioned request and notification on the user data may be performed, for example, by inserting the aforementioned request or the aforementioned notification into the free area (padding area) of the user data. By doing so, it is possible to reduce the overhead such as the header in the transfer. Also, by performing the aforementioned request and notification independently of the user data, the request and the notification can be performed quickly.

[0142] In the first embodiment, a DU that is a candidate for the used DU (hereinafter sometimes referred to as a candidate DU) may be provided. The candidate DU may be, for example, a DU that the UE monitors for the PDCCH. The candidate DU and the used DU may be determined step by step. For example, the used DU may be selected from among the candidate DUs. By doing so, flexible setting of the used DU becomes possible.

[0143] The candidate DU may be all the DUs under the CU. By doing so, the flexibility of communication is expanded. Also, the candidate DU may be some of the DUs under the CU. By doing so, the number of DUs that the UE monitors for the PDCCH can be reduced, so the power consumption of the UE can be reduced.

[0144] The CU may notify the UE of information indicating which DU is to be used as the serving DU. For the aforementioned notification, L1 / L2 signaling may be used. As the L1 / L2 signaling, for example, scheduling information, that is, downlink allocation information or uplink grant information, may be used. The CU may transmit the L1 / L2 signaling to the UE via all or any of the candidate DUs. The L1 / L2 signaling may be transmitted to the UE via the serving DU in downlink communication. The CU may include in the L1 / L2 signaling the downlink allocation information of the serving DU, or may include the uplink grant information, or may include both the downlink allocation information and the uplink grant information. The UE may determine the serving DU by using the presence or absence of the aforementioned scheduling information. As a result, the CU can flexibly change the serving DU and can quickly notify the UE of the information of the serving DU.

[0145] The CU may determine the candidate DUs. When the CU determines the candidate DUs, the CU may use the same information as the aforementioned information (1) to (5) used for determining the serving DU. The information used by the CU for determining the serving DU and the information used for determining the candidate DUs may be the same or different. This can avoid the complexity in determining the candidate DUs and the serving DU in the CU.

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

[0147] Examples of the information used by the DU for the aforementioned determination are disclosed as follows (1) to (5).

[0148] (1) Measurement results obtained by the DU. For example, uplink 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) Load status of the CU.

[0152] (5) Combinations of the above (1) to (4).

[0153] In the above (1), the DU may use information similar to the above information (1) and (2) that the CU uses for the decision of using the DU. By this, the same effect as when the CU uses the above information (1) or (2) for the decision of using the DU can be obtained.

[0154] In the above (3), the CU may use information similar to the above information (3) that the CU uses for the decision of using the DU. By this, it becomes unnecessary for the DU to notify the CU of the load status of the local DU, so the signaling amount in the CU-DU interface, for example, the Fs interface, can be reduced.

[0155] In the above (4), the CU may use information similar to the above information (4) that the CU uses for the decision of using the DU. By this, it becomes possible to flexibly change the use of the DU according to the necessary communication amount between the CU and the UE.

[0156] The DU may request the CU for the information in the above (4). The CU may notify the DU of the information in the above (4). 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 the standard or may be notified from the CU to the DU. By this, it becomes possible to optimize the signaling amount required for the above notification from the CU to the DU.

[0157] In the determination of the DU to be used using the foregoing (1) to (4), a threshold value may be set. The DU may determine the DU to be used using the threshold value. For example, when the reception intensity of the uplink reference signal received from the UE is equal to or greater than a certain value, the DU may determine that its own DU can be used for communication between the CU and the UE. Alternatively, for example, when the buffer amount in its own DU is equal to or greater than a certain value, the DU may determine that its own DU can be used for communication between the CU and the UE. This can facilitate the determination of the DU to be used in the DU.

[0158] The UE may determine the foregoing DU to be used and candidate DUs. The UE may request the CU to use the DU determined by its own judgment as the DU to be used or a candidate DU. This request may be included in the scheduling request from the UE to the CU. The CU may accept or reject the request. By the UE determining the DU to be used, for example, it becomes possible to quickly switch the DU to be used following the movement of the UE.

[0159] When the UE determines the DU to be used, the UE may use the measurement results obtained by itself. The measurement results may use the same information as the foregoing information (2) used by the CU for determining the DU to be used. This can obtain the same effect as when the CU uses the foregoing information (2) for determining the DU to be used, and further reduce the signaling amount in the CU-DU interface, for example, the Fs interface, and the radio interface.

[0160] The DU used for uplink communication and the DU used for downlink communication may be the same or different. The candidate DUs for uplink communication and the candidate DUs for downlink communication may be the same or different. Using the same DU simplifies the control in the CU and the UE. Also, by using different DUs, an appropriate DU can be selected according to the channel conditions of each of the uplink communication and the downlink communication, so that high-capacity, low-latency, and high-reliability communication can be ensured. The entities that determine the candidate DUs and the used DUs may be different for uplink communication and downlink communication. For example, the CU may determine the candidate DUs and the used DUs for uplink communication, and the UE may determine the candidate DUs and the used DUs for downlink communication. This enables the receiving side to control the used DU according to the actually measurable channel conditions, thus improving the reliability of communication. Alternatively, for example, the UE may determine the candidate DUs and the used DUs for uplink communication, and the CU may determine the candidate DUs and the used DUs for downlink communication. This eliminates the need to feedback the measurement results on the radio interface, thus reducing the signaling amount on the radio interface. Alternatively, for example, the CU may determine the candidate DUs for both uplink communication and downlink communication, the UE may determine the used DU for downlink communication, and the CU may determine the used DU for uplink communication. This enables the receiving side to control the used DU according to the actually measurable channel conditions, thus improving the reliability of communication and enabling the used DU to be determined quickly by the CU providing the candidate DUs uniformly.

[0161] A method for using different DUs for uplink communication and downlink communication is disclosed.

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

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

[0164] In the aforementioned uplink communication, the UE may simultaneously transmit data to multiple DUs or may perform the transmission at different timings. Regarding whether to perform the transmission simultaneously or at different timings, the CU may notify the UE. For the notification, L1 / L2 signaling, MAC signaling, or RRC signaling may be used for quasi-static notification. As a result, it is possible to enhance the flexibility in the uplink communication.

[0165] In the present invention, a primary DU and a secondary DU may be provided. As a result, the selection of the DU used in the CU and the UE becomes easy, and thus it is possible to reduce the processing amount and the signaling amount of the CU and the UE. A DU other than the primary DU may be used as the secondary DU. The number of primary DUs may be one or multiple. All the DUs under the CU may be used as primary DUs, or some of the DUs may be used as primary DUs.

[0166] The primary DU may be, for example, the DU used or a candidate DU in the C-Plane data transmission. As a result, the processing associated with the transfer of the C-Plane data becomes easy. Alternatively, the primary DU may be a DU that preferentially conducts data for both the C-Plane and the U-Plane over the secondary DU. As a result, it is possible to reduce the processing amount for determining the DU used for both the C-Plane and the U-Plane.

[0167] The CU may determine which DU under it is to be the primary DU. This facilitates the control of DUs for the entire communication system.

[0168] The UE may determine which DU under the CU is to be the primary DU. This eliminates the need for the UE to notify the CU of measurement results, thus reducing the signaling volume. For the DUs under the CU, the DU serving as the primary DU may vary for each UE. This enables the construction of an optimal conduction path for each UE, enhancing reliability and the flexibility of the communication system. The CU and the UE may use different DUs as the primary DU for uplink and downlink communications respectively. This allows for the flexible construction of conduction paths according to the differences in channel conditions between uplink and downlink communications and enhances the reliability of communication.

[0169] The CU may determine the primary DU using information on the performance of the DUs under it. The aforementioned performance may be the communication range, the operating frequency band, the buffer volume, or the communication capacity between the CU and the DU. This enables efficient communication for the communication system. For example, by designating a DU with a wide communication range as the primary DU, the CU can use this primary DU to conduct C-Plane communication with many UEs, thus enabling efficient C-Plane communication.

[0170] When the CU determines the primary DU using information on the performance of the DUs, the DU may notify the CU of information on its own performance. This notification may be made when the DU starts connecting to the CU. The CU may also request the DU for information on its performance. This request may be made when the DU starts connecting to the CU. This enables the CU to accurately determine the primary DU immediately after the DU starts connecting to the CU.

[0171] The foregoing requests and notifications may be made when setting up the CU-DU interface, for example, the Fs interface. Also, the foregoing requests and notifications may be included in the signaling during the setup of the Fs interface. This can reduce the amount of signaling between the CU and the DU.

[0172] The foregoing requests and notifications may be made when the performance of the DU is updated. This enables the CU and the UE to accurately determine the primary DU in reflection of the performance update of the DU.

[0173] The foregoing requests and notifications may be made when communication with the UE starts. This enables flexible determination of the primary DU for each UE.

[0174] The CU and / or the UE may use a DU with good communication quality with the UE as the primary DU. This can improve the reliability of communication. For the communication quality, received signal strength (e.g., RSRP) may be used, or signal-to-noise ratio may be used. Other metrics, such as RSRQ, may also be used. A certain threshold may be set for the communication quality, and a DU with better communication quality than the threshold, or a DU having a communication quality equal to or higher than the threshold, may be used as the primary DU. Alternatively, a predetermined number of DUs may be used as the primary DUs in the order of better communication quality. The threshold and / or the aforementioned predetermined number may be determined by the 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 the UE may use the DU used during the camping on of the UE as the primary DU. This simplifies the control of the DU.

[0176] Alternatively, the CU and / or the UE may use the DU at the time when the UE becomes RRC-CONNECTED as the primary DU. This simplifies the control of the DU.

[0177] Alternatively, when the CU and / or the UE determines the primary DU, the aforementioned information (1) to (4) for determining which DU under the CU to use for communication may be used. This enables the common use of the determination of the DU to be used and the determination of the primary DU, facilitating the design of the communication system and reducing the processing load.

[0178] The CU and / or the UE may fixedly determine the primary DU. That is, the once-determined primary DU may continue to be used as the primary DU. This simplifies the control of the DU by the CU.

[0179] Alternatively, the CU and / or the UE may make the determination of the primary DU variable. That is, the once-determined primary DU may be changed. This enhances the flexibility of the communication system.

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

[0181] The CU may transfer different numbers of replicated packets to different DUs. For example, when DU#1 and DU#2 exist under the CU, the CU may replicate a packet into three, transfer two packets to DU#1, and transfer the remaining one packet to DU#2. This can enhance the reliability in downlink communication. For example, when the channel condition between DU#1 and the UE is poor and HARQ may exceed the maximum retransmission times, by transferring two packets from the CU to DU#1 as described above, even if packet loss occurs due to exceeding the maximum retransmission times of HARQ for one packet, it is possible to transmit the other packet from DU#1 to the UE.

[0182] The UE may transfer different numbers of replicated packets to entities in the lower layers facing different DUs. For example, when the UE communicates with a CU that has two DUs (DU#1, DU#2) under it, the PDCP layer of the UE may replicate a packet into three, transfer two packets to the RLC entity facing DU#1, and transfer the remaining one packet to the RLC entity facing DU#2. This can enhance the reliability in uplink communication.

[0183] In the above, when determining the number of replicated packets that the CU transfers to each DU, the CU may use the same information as the information for the CU to determine the serving DU. Also, when determining the number of replicated packets that the UE transfers to the lower layer facing each DU, the UE may use the same information as the information for the UE to determine the serving DU. This can avoid the complexity in constructing the communication system.

[0184] The CU and / or the UE may assign the same PDCP sequence number to the replicated packets. This can facilitate packet duplicate detection at the receiving UE and / or CU.

[0185] Alternatively, the CU and / or the UE may assign different PDCP sequence numbers to the duplicated packets. This can avoid the design complexity for the PDCP header adding part and the corresponding RLC transfer part in the transmitting CU and / or UE.

[0186] As described above, the CU and / or the UE may assign different serial 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 another two packets obtained by duplicating another packet. This can avoid the design complexity of the PDCP header adding part.

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

[0188] Alternatively, the CU and / or the UE may assign PDCP sequence numbers with branch numbers to each of the duplicated packets. For example, PDCP sequence numbers #3-1 and #3-2 may be assigned to two packets obtained by duplication. This makes it possible to easily identify the same packet at the receiving side without adding a PDCP header.

[0189] Alternatively, even when branch numbers are adopted, there may be packets to which no branch number is assigned. For example, PDCP sequence numbers #3 and #3-1 may be assigned to two packets obtained by duplication. This can reduce the number of bits of the PDCP sequence number.

[0190] The UE and / or CU may discard duplicate received PDCP-PDUs. The UE and / or CU may receive PDCP-PDUs on a first-come, first-served basis. That is, the same PDCP-PDU received later may be discarded. This can reduce latency. Also, the UE and / or CU may immediately transfer the received PDCP-PDU to the upper layer. This can reduce latency.

[0191] Each DU that serves as a conduction path between the CU and the UE may be assigned a priority. The UE and / or CU may preferentially receive PDCP-PDUs with a higher priority. For example, PDCP-PDUs received via a DU with a small delay in the CU / DU link may be preferentially received. This simplifies the PDCP-PDU reception process when the difference in the delay of the CU / DU link is large and when the reliability of one link is low.

[0192] The priority of each DU may be assigned by the CU or by the UE. Examples (1) to (7) below are disclosed as information used by the CU and / or UE for the above-described priority determination.

[0193] (1) CU / DU link delay.

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

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

[0196] (4) Performance of the DU.

[0197] (5) Load status of the DU.

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

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

[0200] In the foregoing (1), for example, by assigning a high priority to a DU with a small delay in the link between the CU and the DU, the PDCP-PDU reception processing of the CU and / or the DU can be facilitated.

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

[0202] In the foregoing (3), for example, by assigning a high priority to a DU with a small propagation delay, the PDCP-PDU reception processing of the CU and / or the DU can be facilitated.

[0203] In the foregoing (4), for example, the time from receiving the PDCP-PDU from the upper layer until transmitting the PDCP-PDU to the radio interface may be used. Alternatively, the time from receiving the data from the radio interface until transmitting it to the CU as a PDCP-PDU may be used. Thereby, for example, by assigning a high priority to a DU with high performance, the PDCP-PDU reception processing of the CU and / or the DU can be facilitated.

[0204] In the foregoing (5), for example, the free resource status may be used. The free resource status may use, for example, the buffer amount of the DU or the radio resources of the DU. Thereby, for example, by assigning a high priority to a DU with a large amount of free resources, the PDCP-PDU reception processing of the CU and / or the DU can be facilitated and the transmission speed can be improved.

[0205] In the foregoing (5), alternatively, 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. Thereby, since it becomes possible to shorten the waiting time for user data scheduling, the delay associated with communication can be reduced.

[0206] In the above (6), it is possible to reduce the processing amount in the priority determination by the CU.

[0207] The CU and the UE may measure the delay time of the link between the CU and the UE. In that case, for different links passing through different DUs, the relative value of the delay time may be measured. By measuring the relative value, the transmitting side does not need to attach a time stamp, so the measurement process becomes easier.

[0208] The above measurement may be performed for each of the CU-DU interface between the CU and the DU, for example, the Fs interface, and the radio interface between the DU and the UE. This makes the measurement process easier.

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

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

[0211] In the above 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, in the Fs interface, pilot data with timestamps may be used, or uplink or downlink reference signals may be used for the radio interface. This can reduce the overhead due to measurement.

[0212] The UE may notify the CU of the measurement results of the delay time of the link passing through each DU. The CU may determine the priority of the link passing through each DU using the measurement results. For this notification, the UE may use RRC signaling. This can reduce the processing time by the DU, for example, the decoding time of data. Alternatively, the UE may use PDCP status PDUs. This enables notification with a 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, for the notification from the UE to the DU, L1 / L2 signaling or MAC signaling may be used. According to L1 / L2 signaling, rapid notification is possible. According to MAC signaling, notification can be made with a small number of symbols using multi-value modulation. Also, for the notification from the DU to the CU, a control signal of the CU-DU interface, for example, the Fs interface, may be used. The control signal may be piggybacked on the user data or transmitted independently of the user data. In this way, by using different signaling for the notification from the UE to the DU and the notification from the DU to the CU, the overhead due to feedback is reduced.

[0213] The UE may notify the CU of the result of averaging the measured values of the aforementioned delay time or the result of filtering. As the notification of the result of averaging or the result of filtering, the same method as the notification from the UE to the CU of the measurement result of the aforementioned delay time may be used. By this, the influence of the variation of the measured values can be suppressed and the signaling amount in the aforementioned notification can be reduced.

[0214] In the above, the parameters used for the averaging process or the filtering process may be determined by the standard or may be determined by the CU. The CU may notify the UE of the aforementioned parameters. By this, flexible measurement according to the situation of the communication system becomes possible.

[0215] The CU may notify the UE of the measurement results of the delay times of the links passing through each DU. The UE may determine the priorities of the links passing through each DU using the measurement results. For this notification, the CU may use RRC signaling. By this, the processing time by the DU, for example, the decoding time of data can be reduced. Alternatively, the CU may use PDCP status PDUs. By this, notification with a small overhead becomes possible. 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, for the notification from the CU to the DU, a control signal of the CU-DU interface, for example, the Fs interface may be used. The control signal may be piggybacked on the user data or may be transmitted independently of the user data. The aforementioned piggybacking may be performed, for example, by inserting the control signal into the free 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. According to the L1 / L2 signaling, rapid notification becomes possible. According to the MAC signaling, notification with a small number of symbols can be performed using multi-value modulation. In this way, by using different signaling for the notification from the CU to the DU and the notification from the DU to the UE, the overhead due to feedback becomes small.

[0216] The CU may notify the UE of the result of averaging the measured values of the aforementioned delay time or the result of filtering. As the notification of the result of averaging or the result of filtering, the same method as the notification from the CU of the measurement result of the aforementioned delay time to the UE may be used. This can suppress the influence of fluctuations in the measured values and reduce the signaling amount in the aforementioned notification.

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

[0218] The CU may determine the priority. The CU may notify the UE of the priority. This enables the CU to optimize the communication speed based on the communication situations 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 enables the CU to notify the UE with a small signaling amount. Alternatively, the notification may be the ratio of the duplicate packet transfer amount for each DU. This enables flexible specification of the transfer method of the duplicated packets, thus enabling efficient improvement of communication reliability.

[0219] The CU may use the PDCP control PDU for the notification. This enables notification with a small overhead. Alternatively, RRC signaling may be used. This enables notification of a large amount of information.

[0220] The UE may determine the priority. The UE may use the measurement results obtained 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, thus reducing the signaling amount.

[0221] In the communication between the CU and the UE, the priority of the DU used may be changed between the uplink and the downlink. By doing so, the priority can be flexibly controlled according to the situation of each communication path of the uplink communication and the downlink communication. Also, different entities may determine the priority of the DU used between the uplink and the downlink. For example, the CU may determine the priority of the uplink, and the UE may determine the priority of the downlink. By doing so, the amount of signaling can be reduced in measurement and feedback of measurement results.

[0222] In the communication between the CU and the UE, the receiving-side PDCP layer may generate a PDCP-SDU using the replicated PDCP-PDUs and transfer it to the upper layer. The aforementioned upper layer may be, for example, the application layer or the RRC. In the above, one or more of the PDCP-SDUs to be transferred may be used. That is, the receiving side does not necessarily have to generate a PDCP-SDU for all of the replicated PDCP-PDUs. By doing so, it is possible to reduce the delay on the receiving side. Also, the receiving side may receive the replicated PDCP-PDUs using a reordering timer. By doing so, the smooth operation of the system becomes possible.

[0223] In the communication between the CU and the UE, the receiving-side PDCP layer may be able to determine which DU the PDCP-PDU was received via. Each RLC entity on the receiving side may transfer an identifier representing its own entity to the PDCP layer together with the PDCP-PDU. Alternatively, an identifier representing the DU used for the communication may be used. By doing so, it is possible to facilitate the priority determination of the DU on the receiving side. 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] When the receiving - side PDCP layer creates a PDCP - SDU (PDCP - Service Data Unit) from a PDCP - PDU, it may delete the aforementioned identifier. By doing so, it becomes possible to reduce the data processing volume in the upper layer, for example, the application layer. Alternatively, the receiving - side PDCP layer may leave the aforementioned identifier in the creation of the PDCP - SDU and transfer the PDCP - SDU to the upper layer, for example, RRC. By doing so, the control of the DU used in the upper layer, for example, RRC, becomes easier. The receiving - side PDCP layer may transfer the PDCP - SDU from which the aforementioned identifier has been deleted to the upper layer, for example, the application layer, and transfer the information of the deleted identifier to another upper layer, for example, RRC. By doing so, for example, the processing volumes in the application layer and RRC can be reduced.

[0225] In the communication between the CU and the UE, the transmitting side may attach an identifier. The receiving - side RLC layer may transfer the identifier to the receiving - side PDCP layer. By doing so, it becomes possible to reduce the processing volume in the receiving - side RLC layer. The receiving - side PDCP layer may transfer the data from which the identifier has been deleted to the upper layer, for example, the application layer. It becomes possible to reduce the processing volume in the application layer. The receiving - side PDCP layer may transfer the information of the identifier to another upper layer, for example, RRC. The control of the DU used in RRC becomes easier.

[0226] The CU may acquire the information of the packets received from each DU. The information may be, for example, the packet loss rate or the packet delay time. By doing so, the CU can easily control the DU used.

[0227] Alternatively, the UE may acquire the information of the packets received from each RLC entity. The information may be, for example, the packet loss rate or the packet delay time. By doing so, the UE can easily control the DU used.

[0228] As an identifier representing the DU, the IP address of the DU may be used. By doing so, it becomes possible to directly use the configuration of the interface between base stations, thus avoiding complexity in the design of the CU and DU. In addition, it is possible to suppress the occurrence of processing overhead in the RLC layer.

[0229] An identifier representing the DU (hereinafter sometimes referred to as DU-ID) may be given so as to be unique among the DUs under the CU. By doing so, it becomes possible to identify the DU with a small number of bits.

[0230] Alternatively, the DU-ID may be given so as to be unique among the surrounding gNBs. By doing so, in the combination of DC or MC and CU-DU separation, the CU of the master base station can identify the DU of the secondary base station, thus enhancing the flexibility of the CU-DU configuration. The aforementioned surrounding gNBs may be gNBs within the same tracking area. By doing so, it becomes possible to prevent double management of the surrounding gNBs for DU identification and the gNBs within the tracking area, thus avoiding the complexity of the device. Alternatively, the aforementioned surrounding gNBs may be gNBs connected to the same MME (Mobility Management Entity). By doing so, it becomes easier to identify the DU in gNB-to-gNB mobility.

[0231] Alternatively, the DU-ID may be given so as to be unique among the master base station and the secondary base stations. By doing so, even when the master base station and the secondary base stations straddle the boundary of the aforementioned surrounding gNBs, it becomes possible to easily identify the DU among the master base station and its subordinate secondary base stations.

[0232] Alternatively, an identifier given to be unique among DUs under the CU of a gNB and the identifier of the gNB may be used in combination. This enables easy identification of the DU from other gNBs. Instead of the identifier of the gNB, a Physical Cell Identity (abbreviated as PCI) may be used. This facilitates the identification of the cell and the DU, thus simplifying the system control.

[0233] Alternatively, an identifier unique to all DUs on the communication system may be given. This facilitates the identification of DUs on the communication system.

[0234] Regarding the above-mentioned identifier of the DU, renumbering may be performed. This enables reduction of the number of bits used for identifying the DU, for example, in signaling. The above-mentioned renumbering may be performed using, for example, a table. The above-mentioned table may include the original identifier of the DU and the renumbered identifier. This facilitates the association between the original identifier of the DU and the renumbered identifier.

[0235] The above-mentioned renumbering may be performed by a higher-level network device. This enables management of DUs spanning multiple gNBs with a small number of bits.

[0236] Alternatively, the above-mentioned renumbering may be performed by a master base station. This enables management of DUs in a DC or MC configuration with a small number of bits.

[0237] In the foregoing, the master base station may request the secondary base station to notify the identifiers of the DUs under the secondary base station. The secondary base station may notify the master base station of the identifiers of the DUs under its own secondary base station. By doing so, the secondary base station only needs to notify the master base station of the DU identifiers at the required timing, so that the signaling amount can be reduced. Alternatively, the secondary base station may notify the master base station of the DUs under its own base station when the configuration of the DUs under its own base station is changed. By doing so, the master base station can perform control that quickly reflects the change in the configuration of the DUs under the secondary base station.

[0238] Each base station may perform the foregoing renumbering. By doing so, it is possible to reduce the inquiry operations regarding the mapping of identifiers that are performed between base stations or between a base station and a higher-level network device. Thereby, the signaling amount can be reduced.

[0239] The CU and the UE may share the information regarding the foregoing renumbering. The foregoing information may be information combining the identifier of the DU before renumbering and the identifier of the DU after renumbering. In the communication between the CU and the UE, the signaling amount regarding the DU information can be reduced.

[0240] The CU may notify the UE of the foregoing information. The notification may be performed by RRC signaling. By doing so, it is possible to reduce the signaling processing amount in the used DU.

[0241] Alternatively, the notification between the CU and the DU may be made by a control signal on the CU-DU interface, e.g., the Fs interface. The control signal may be piggybacked on the user data or transmitted independently of the user data. The aforementioned piggybacking may be performed, for example, by inserting the control signal into the empty area (padding area) of the user data. By doing so, the overhead associated with the transmission of the control signal can be reduced. The notification between the DU and the UE may be made by L1 / L2 signaling. By doing so, a prompt notification from the DU to the UE becomes possible. Alternatively, MAC signaling may be used. By doing so, it becomes possible to make a notification with a small number of symbols using multi-value modulation and to enhance the reliability by HARQ retransmission control. Alternatively, a signaling method similar to carrier aggregation may be used. By doing so, the signaling method can be made common, so that it becomes possible to avoid the complexity in system design.

[0242] The CU and the DU may share the information regarding the aforementioned re-numbering. In sharing the aforementioned information, the CU and the DU may notify each other of the information necessary for re-numbering. For the aforementioned notification, the CU-DU interface, e.g., the Fs interface, may be used. The DU may notify the CU, for example, of its own DU identifier as the information necessary for re-numbering. The CU may notify the DU of the identifier after re-numbering. By doing so, it becomes possible to reduce the number of bits required for notifying the DU identifier in the CU-DU interface, e.g., the Fs interface.

[0243] The upper-layer network device and the CU may share the information regarding the aforementioned re-numbering. When sharing the aforementioned information, the upper-layer network device and the CU may notify each other of the information necessary for re-numbering. For the aforementioned notification, the interface between the upper-layer network device and the CU may be used. The CU may notify the upper-layer network device, for example, of the identifier of the subordinate DU as the information necessary for re-numbering. The aforementioned identifier of the DU may be combined with the identifier of the gNB. The upper-layer network device may notify the combined information of the identifier of the DU before re-numbering and the identifier of the DU after re-numbering. By doing so, it becomes possible to reduce the amount of signaling of the information regarding the DU at the interface between the upper-layer network device and the CU.

[0244] In the CU and / or the UE, the buffer of the PDCP layer may be made common among the DUs. By doing so, the buffer amount can be saved. Alternatively, a PDCP layer buffer may be secured for each DU. By doing so, for example, even when there is a DU where communication is stalled, communication can be continued by other DUs, so that it becomes possible to reduce the delay.

[0245] FIG. 8 is a diagram showing the configuration of a CU that performs packet duplication at the PDCP layer and transfers the packets to a plurality of DUs, a DU, and a UE that performs duplicate packet detection in downlink communication. In FIG. 8, the CU 801 communicates with the UE 804 using the DU#1 (which may also be referred to as the DU 802) and the DU#2 (which may also be referred to as the DU 803).

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

[0247] In FIG. 8, the PDCP layer 809 duplicates the PDCP-SDU 808 into two, attaches a PDCP header 810 to one of the duplicated SDUs to generate a PDCP-PDU #1 (which may also be called PDCP-PDU 812), and attaches a PDCP header 811 to the other duplicated SDU to generate a PDCP-PDU #2 (which may also be called PDCP-PDU 813). The PDCP headers 810 and 811 include information of the same sequence number #n in FIG. 8, but may include information of different sequence numbers. For example, by making the sequence numbers of the PDCP headers 810 and 811 consecutive, the design of the sequence number assignment section of the PDCP layer becomes easier.

[0248] In FIG. 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] In FIG. 8, DU#1 transmits the PDCP-PDU#1 received at the RLC layer 816 to the DU#1 facing entity 818 of the UE 804. DU#2 transmits the PDCP-PDU#2 received at the RLC layer 817 to the DU#2 facing 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 the PDCP-PDU#1 and the PDCP-PDU#2 are duplicates and deletes the PDCP-PDU#2. The PDCP layer 822 obtains the PDCP-SDU 808 by deleting the PDCP header 810 from the PDCP-PDU#1 and transfers the PDCP-SDU 808 to the New AS Layer 823. The PDCP layer 822 deletes the PDCP-PDU#2 in the example of FIG. 8, but may also delete the PDCP-PDU#1. In that case, the PDCP layer 822 obtains the PDCP-SDU 808 by deleting the PDCP header 811 from the PDCP-PDU#2 and transfers the PDCP-SDU 808 to the New AS Layer 823.

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

[0252] In the communication between the CU and the UE, a bearer passing through all DUs under the CU may be established. The CU may notify the UE of a change in the settings regarding the communication with each DU in the DU mobility of the UE. As a result, even when the UE moves between DUs, bearer changes are not required, reducing the signaling volume.

[0253] The CU may allocate the radio resources of all the subordinate DUs. The CU may allocate the buffer sizes of all the subordinate DUs. The allocation of radio resources and / or buffer sizes may be performed when the CU newly configures a bearer. The allocation of radio resources and / or buffer sizes may also be performed when the CU modifies the configuration of a bearer. This enables communication to continue while meeting the QoS (e.g., bandwidth guarantee) required for the bearer even when the UE performs mobility between DUs.

[0254] The CU may allocate the radio resources of some of the subordinate DUs. The number of DUs for which radio resources are allocated may be one or two or more. This can save radio resources allocated at the time of bearer establishment as described above, enabling efficient communication.

[0255] Some of the DUs mentioned above may be a predetermined number of DUs in descending order of measurement results. This can improve communication reliability while saving radio resources.

[0256] Alternatively, some of the DUs mentioned above may be DUs adjacent to the DUs used in the communication between the CU and the UE. This can further save radio resources allocated by the CU to the DUs.

[0257] Alternatively, some of the DUs mentioned above may be DUs around the DUs used in the communication between the CU and the UE. The surrounding DUs may include DUs adjacent to the used DUs. This enables smooth mobility between DUs even when the radio channel situation changes suddenly, while saving radio resources.

[0258] Figure 9 is a diagram showing the configuration of a bearer passing through all the DUs under the CU. Figure 9 shows an example in which the CU 900 has DUs #1, #2, and #3 (which may also be referred to as DU901, DU902, and DU903 respectively) under it and communicates with the UE 904.

[0259] In FIG. 9, a bearer 905 is established as a bearer passing through all DUs under the CU. The bearer 905 terminates at the PDCP layer 906 of the CU 901 and the PDCP layer 907 of the UE 904. The bearer 905 passes through the RLC layer, MAC layer, and PHY layer respectively possessed by DU#1, DU#2, and DU#3. Also, the bearer 905 passes through the DU#1 facing entity 908, DU#2 facing entity 909, and DU#3 facing entity 910 of the UE 904.

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

[0261] The CU may request information regarding the performance of the DUs under it from the DUs under it. This request may be made to a DU that has newly come under the CU, for example, a DU connected to the CU. The information regarding the performance of the DU may be, for example, the time from receiving a PDCP-PDU from the upper layer to transmitting the PDCP-PDU to the radio interface. Alternatively, the information regarding the performance of the DU may be the time from receiving data from the radio interface to transmitting it to the CU as a PDCP-PDU. Alternatively, the information regarding the performance of the DU may be the buffer amount of the DU or the radio resources. Thus, when adding a DU, the CU can appropriately change the bearer settings using the information regarding the performance of the DU.

[0262] The DU may notify the CU of information regarding its own performance. This notification may be made when the DU newly comes under the CU, for example, when the DU is connected to the CU. The information may be the same as the aforementioned information regarding the performance of the DU. This can achieve the same effect as described above.

[0263] The DU may request the CU for information regarding the communication status. This request may be made when the DU newly comes under the control of the CU, for example, when the DU is connected to the CU. The information regarding the communication status may be, for example, information on the UE with which the CU is communicating, information on the bearer used by the UE, or information regarding the bearer settings. Thereby, for example, the startup operation at the time of DU connection can be performed quickly.

[0264] The CU may notify the DU of information regarding the communication status. This notification may be made to the DU that has newly come under the control of the CU, for example, the DU connected to the CU. The information regarding the communication status may be the same as the aforementioned information. Thereby, the same effect as described above can be obtained.

[0265] The aforementioned request and notification may be made at the time of setting up the CU-DU interface, for example, the Fs interface. Also, the aforementioned request and notification may be included in the signaling in the setup of the Fs interface. Thereby, the signaling amount between the CU and the DU can be reduced.

[0266] The aforementioned request and notification may be made at the time of performance update of the DU. Thereby, the CU and the UE can accurately determine the primary DU reflecting the performance update of the DU.

[0267] The aforementioned request and notification may be made at the start of communication with the UE. Thereby, it becomes possible to flexibly determine the primary DU for each UE.

[0268] In the communication between the CU and the UE, a split bearer (hereinafter, may be referred to as a DU - to - DU split bearer) may be established for the DU that is the transfer destination of the duplicate packet. By doing so, it becomes possible to save the resources of the DU that are not used for the conduction of the duplicate packet. Once the DU - to - DU split bearer is established for a DU, it may not be necessary to release the DU - to - DU split bearer. For example, even when DU - to - DU mobility occurs, it may not be necessary to release the DU - to - DU split bearer. Also, the DU - to - DU split bearer may be released for the DU. For example, even when the connection between the UE and the CU is released, the DU - to - DU split bearer may be released. Or, when the DU is in an overloaded state, the DU - to - DU split bearer may be released. By this, even when re - using the DU that was previously used in the communication between the CU and the UE, the amount of signaling related to the setting of the DU - to - DU split bearer can be reduced.

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

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

[0271] In steps ST1003 and ST1004 shown in FIG. 10, the CU notifies the UE of the RRC connection reconfiguration signaling. This notification is sent from the CU to DU#1 in step ST1003 and from DU#1 to the UE in step ST1004. This notification includes information indicating the addition of DU#2 and information indicating the start of packet duplication. Further, this notification includes information regarding RRC parameters for the DU#2 peer entity. This notification may also include information regarding RRC parameters for the DU#1 peer entity. The UE uses the information received in step ST1004 to perform RRC parameter settings for packet duplication and communication with DU#2.

[0272] In steps ST1005 and ST1006 shown in FIG. 10, the UE sends an RRC connection reconfiguration completion notification to the CU. This notification is sent from the UE to DU#1 in step ST1005 and from DU#1 to the CU in step ST1006.

[0273] In step ST1007 shown in FIG. 10, the CU notifies DU#2 of a communication start instruction. This instruction may include RRC parameters. Further, this instruction may include information indicating the performance of packet duplication. DU#2 uses this instruction to perform RRC parameter settings for data transmission and reception with the UE.

[0274] In step ST1008 shown in FIG. 10, DU#2 notifies the CU of a communication start instruction response. This response may include information indicating that the settings in DU#2 have been completed.

[0275] In steps ST1009 and ST1010 shown in FIG. 10, random access processing for the UE to communicate with the CU via DU#2 is performed. In step ST1009, signaling is performed between DU#2 and the CU, and in step ST1010, radio signals are transmitted and received between the UE and DU#2. Step ST1009 may be a random access Msg3 from DU#2 to the CU, or may be information indicating that the random access processing has been completed from DU#2 to the CU. Further, step ST1009 may be an affirmative response or a negative response from the CU to DU#2 for 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 the 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, the signaling necessary to start the transmission and reception of duplicate packets using DU#1 and #2 is completed.

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

[0278] In step ST1011 shown in FIG. 11, user data is transferred from the upper network device to the CU. In step ST1012, the CU replicates the PDCP-PDU containing the user data.

[0279] As shown in FIG. 11, the CU transfers the replicated 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] In step ST1017 shown in FIG. 11, the UE detects the duplication of the user data received in steps ST1015 and ST1016. Further, the UE deletes the duplicated received user data.

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

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

[0283] As shown in FIG. 11, the UE transmits the replicated 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] In step ST1023 shown in FIG. 11, the CU detects the duplication of the user data received in steps ST1021 and ST1022. Also, the CU deletes the duplicated received user data.

[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 indicating the transmission and reception of uplink user data may be executed after or simultaneously with steps ST1011 to ST1017 indicating the transmission and reception of downlink user data. This increases the flexibility in the transmission and reception of user data.

[0287] In the examples of FIGS. 10 and 11, the sequence for starting the transmission and reception of replicated packets between the CU and the UE does not require signaling to the 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 the transmission and reception of replicated packets between the CU and the 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 aforementioned communication change instruction, the CU may also transmit to the DU an identifier indicating that each layer of RLC, MAC, and PHY during communication is not initialized. This can prevent communication interruption caused by data discard due to initialization.

[0290] FIG. 12 and FIG. 13 are diagrams showing other sequences for starting the transmission and reception of replicated packets in the communication between the CU and the UE. FIG. 12 and FIG. 13 are connected at the position of the boundary line BL1213. In FIG. 12 and FIG. 13, the same step numbers are assigned to the same steps as in FIG. 10 and FIG. 11, and common descriptions are omitted.

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

[0292] In step ST1102 shown in FIG. 12, DU#1 notifies the CU of a communication change instruction response. The response includes information indicating that the settings in DU#1 are completed.

[0293] By using the sequences shown in FIG. 12 and FIG. 13, the communication channel can be flexibly set with the addition of a DU.

[0294] In another sequence for starting the transmission and reception of replicated packets between the CU and the UE, the RRC connection reconfiguration from the CU to the UE may be performed after the aforementioned communication instruction start response. The aforementioned RRC connection reconfiguration may be performed when a positive response is received from the additional DU in the aforementioned communication instruction start response. By this, even when the processing of the DU fails for the aforementioned communication start instruction, it is possible to prevent the re - execution of the RRC connection reconfiguration. Also, in the UE, the time from the RRC connection reconfiguration to the random access processing can be shortened.

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

[0296] In steps ST1201 and ST1202 shown in FIG. 14, the CU notifies the UE of the RRC connection reconfiguration signaling. Steps ST1201 and ST1202 may be the same as steps ST1003 and ST1004 in FIG. 10. The UE performs RRC parameter setting for packet replication and communication with DU#2 using the information received in step ST1202.

[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 the same as steps ST1005 and ST1006 in FIG. 10.

[0298] In step ST1205 shown in FIG. 14, the CU notifies DU#2 that the RRC connection reconfiguration to the UE has been completed. DU#2 starts random access processing with the UE using this notification.

[0299] The sequence shown in FIG. 14 is different from the sequence shown in FIG. 10 in that step ST1201 is executed after step ST1008. By this, even when the processing of the DU fails for the above-mentioned communication start instruction, it is possible to prevent the re-execution of the RRC connection reconfiguration. Also, in the UE, the time from the RRC connection reconfiguration to the random access processing can be shortened.

[0300] As another example of the sequence for starting the transmission and reception of duplicate packets in the communication between the CU and the UE, the CU may give an instruction to each DU and UE without waiting for a response from each DU and UE. By this, it becomes possible to quickly perform the process of adding a DU.

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

[0302] In steps ST1301 and ST1302 shown in FIG. 16, the CU notifies the UE of the signaling for RRC connection reconfiguration. Steps ST1301 and ST1302 may be the same as steps ST1003 and ST1004 in FIG. 10. The UE performs RRC parameter setting for packet duplication and communication with DU#2 using the information received in step ST1302.

[0303] In step ST1303 shown in FIG. 16, the CU notifies DU#2 of the communication start instruction. Step ST1303 may be the same as step ST1007 shown in FIG. 10. DU#2 performs RRC parameter setting for data transmission and reception with the UE using the information received in step ST1303.

[0304] In step ST1304 shown in FIG. 16, the CU notifies the DU#1 of a communication change instruction. Step ST1304 may be the same as step ST1101 shown in FIG. 12. The DU#1 changes the RRC parameters for the UE 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. This makes it possible to give flexibility to the operation of the CU.

[0306] According to the sequences shown in FIGS. 16 and 17, the CU can quickly perform DU addition processing because it gives instructions without waiting for responses from each DU and the UE.

[0307] The CU may notify the DU of a communication stop instruction. The aforementioned communication stop instruction may be given when packet duplication stops. The DU may notify the CU of a communication stop instruction response. This makes it possible to smoothly continue communication before and after packet duplication stops.

[0308] The CU may notify the UE of an RRC connection reconfiguration. The aforementioned notification of the RRC connection reconfiguration may be given when packet duplication stops. The aforementioned RRC connection reconfiguration may include information indicating the release of the DU. The UE may notify the CU of the completion of the RRC connection reconfiguration. This makes it possible to smoothly continue communication before and after packet duplication stops. The aforementioned RRC connection reconfiguration may include information indicating the cancellation of packet duplication. Alternatively, the aforementioned RRC connection reconfiguration may not include information indicating the cancellation of packet duplication. This makes it possible to reduce the number of DUs used while maintaining packet duplication.

[0309] The CU may communicate the above-mentioned RRC connection reconfiguration to the UE using the non-released DU. This enables the RRC connection reconfiguration to be notified with high reliability. Alternatively, the CU may notify the above-mentioned RRC connection reconfiguration using the released DU. This can reduce the overhead in the non-released DU.

[0310] FIG. 18 is a diagram showing a sequence for stopping the transmission and reception of duplicated packets in the communication between the CU and the UE. FIG. 18 shows an example of switching from communication using duplicated packets with DUs #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 the upper network device and the 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 perform the transmission and reception of the duplicated user data. In steps ST1405 and ST1406, the UE and DUs #1 and #2 perform the transmission and reception of the 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 the RRC connection reconfiguration signaling. This notification is sent from the CU to DU#1 in step ST1408 and then sent from DU#1 to the UE in step ST1409. The notification includes information indicating the release of communication with DU#2 and information indicating the stop of packet duplication. The notification may also include information regarding RRC parameters for the DU#1 facing entity. The UE uses the information received in step ST1409 to perform RRC parameter settings for stopping packet duplication and releasing communication with 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 RRC parameters in the communication with DU#1. The UE may use the information received in step ST1409 to change the RRC parameter settings in the communication with DU#1. Thus, the CU can flexibly perform the communication settings with DU#1 accompanying the release of communication with DU#2.

[0315] In steps ST1410 and ST1411 shown in FIG. 18, the UE sends an RRC connection reconfiguration completion notification to the CU. This notification is sent from the UE to DU#1 in step ST1410 and then sent from DU#1 to the CU in step ST1411.

[0316] In step ST1412 shown in FIG. 18, the CU notifies DU#2 of a communication stop instruction. The instruction includes information indicating the stop of the use of DU#2 in the communication with the UE.

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

[0318] In steps ST1414 to ST1416 shown in FIG. 18, the CU and the UE perform transmission and reception of user data via DU#1. In step ST1414, user data is transmitted and received between the upper-layer network device and the CU. In step ST1415, the CU and DU#1 perform transmission and reception of user data. In step ST1416, the UE and DU#1 perform transmission and reception of user data.

[0319] In FIG. 18, the stop of packet duplication indicated by steps ST1414 to ST1416 may be performed before or after the communication stop instruction response in step ST1413. By performing the stop of packet duplication before the communication stop instruction response, unnecessary communication resources can be released earlier, enabling efficient communication. Also, by performing the stop of packet duplication after the communication stop instruction response, the reliability of user data communication before and after the signaling for performing the stop of packet duplication can be enhanced.

[0320] The CU may use a combination of the aforementioned communication start instruction and the aforementioned communication stop instruction. This combination may be used for switching the DU in use. As described above, the CU may notify the UE of the RRC connection reconfiguration notification in a single summary. This enables smooth switching of the DU in use and further reduces the signaling amount.

[0321] The CU may add or delete the DUs in use one by one. That is, the CU may notify each of the DUs of a communication start instruction or a communication stop instruction. This facilitates recovery from a failure in the sequence of adding or deleting the DUs in use.

[0322] Alternatively, the CU may add or delete the DUs in use in a batch. As described above, the CU may perform the RRC connection reconfiguration notification to the UE in a single summary. This makes it possible to reduce the signaling amount.

[0323] The CU and the UE may communicate via a plurality of DUs in the C-Plane, similar to the U-Plane. Packet replication similar to that of the U-Plane may be applied to the communication via the aforementioned plurality of DUs. This can enhance the reliability of the signaling between the CU and the UE. The aforementioned signaling may be NAS signaling, RRC signaling, or PDCP control PDUs. This can enhance the reliability of the signaling at each layer.

[0324] FIG. 19 and FIG. 20 are sequence diagrams for explaining the switching of the used DU and the communication using a plurality of DUs in the C-Plane. FIG. 19 and FIG. 20 are connected at the position of the boundary line BL1920. FIG. 19 and FIG. 20 show an example in which the used DU is switched from DU#1 and DU#2 to DU#1 and DU#3. In FIGS. 19 and 20, the same step numbers are assigned to the same steps as in FIG. 18, and the common descriptions are omitted.

[0325] Steps ST1500 to ST1505 shown in FIG. 19 represent a sequence related to the signaling of RRC connection reconfiguration notified by the CU to the UE. More specifically, they represent a sequence related to the duplication and notification of packets of this signaling. In step ST1500, the CU duplicates the packet of the RRC connection reconfiguration signaling generated by itself. The above duplication may be performed at the PDCP layer. The above RRC connection reconfiguration signaling may include information regarding the change of the serving DU (in the examples of FIGS. 19 and 20, switching to the use of DU#1 and DU#3), and information indicating that packet duplication is enabled. In steps ST1501 and ST1502, the CU transfers the above-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 signaling. In step ST1505, the UE performs duplicate detection of the received signaling. Also, the UE deletes the duplicated signaling. The above duplicate detection and deletion may be performed at the PDCP layer. The UE uses the above signaling to change the RRC parameters and the serving DU.

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

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

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

[0329] In step ST1517 shown in FIG. 20, the CU notifies DU#3 of a communication start instruction. Step ST1517 may be the same as step ST1007 shown in FIG. 10. DU#3 performs RRC parameter setting for data transmission and reception with the UE using the information received in step ST1517.

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

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

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

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

[0334] In step ST1525 shown in FIG. 20, user data is transmitted and received between the upper network device and the CU. In step ST1526, the CU performs packet duplication of downlink user data, 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 performs packet duplication of uplink user data, detects duplicate packets of downlink user data, and deletes the duplicate packets.

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

[0336] In FIG. 20, the sequence of the communication stop instruction and the communication stop instruction response with DU#2 indicated by steps ST1515 and ST1516, and the sequence of the communication start instruction and the communication start instruction response with DU#3 indicated by steps ST1517 and ST1518 may be performed before the RRC connection reconfiguration sequence shown in steps ST1500 to ST1505. By doing so, it is possible to prevent the re-execution of the RRC connection reconfiguration caused by the failure of the aforementioned communication stop instruction or the aforementioned communication start instruction.

[0337] The UE may notify the CU of the failure of the RRC connection reconfiguration. The notification may include the reason for the failure. The reason for the failure may be, for example, insufficient resources in the UE, inability to communicate with the DU, or other reasons. The CU may proceed with the process using the reason for the failure. The process may be, for example, the use of another DU. By doing so, it is possible for the CU and the UE to prevent the interruption of the sequence due to the RRC connection reconfiguration failure and the accompanying operation stop.

[0338] The UE and the CU may continue the communication using the parameters before the RRC connection reconfiguration notification. The aforementioned continuation of the communication may be performed when the UE notifies the CU of the RRC connection reconfiguration failure. In the aforementioned continuation of the communication, the UE may maintain the RRC_CONNECTED state. Also, the UE may not notify the CU of the RRC connection re-establishment request. By doing so, it is possible to maintain the communication between the UE and the CU.

[0339] In the above, the notification of RRC connection reconfiguration from the CU to the UE may include an identifier that specifies the operation of the UE when the RRC connection reconfiguration fails. The identifier may include information regarding whether to maintain the RRC_CONNECTED state, or may include information indicating the necessity of notifying the CU from the UE of a request for RRC connection re - establishment. Thereby, the UE can easily determine whether to continue communication when the RRC connection reconfiguration fails. Alternatively, the UE may determine its own operation using an identifier indicating whether packet duplication exists. Thereby, the number of bits in the signaling of the RRC connection reconfiguration can be reduced, and further, the UE can easily determine whether to continue communication when the RRC connection reconfiguration fails.

[0340] The notification of the RRC connection reconfiguration failure from the UE to the CU and the notification of the completion of the RRC connection reconfiguration may be integrated as one notification. In the above - mentioned integrated notification, an identifier indicating the completion or failure of the RRC connection reconfiguration may be provided. Alternatively, the identifier of the reason for the RRC connection reconfiguration failure may include the completion of the RRC connection reconfiguration. For example, the case where the value indicating the failure reason is 0 may be assigned to the completion of the RRC connection reconfiguration. Thereby, since the types of signaling are reduced, the processing in the UE and the CU becomes easier.

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

[0342] In steps ST1601 and ST1602 shown in FIG. 21, the UE notifies the CU of the failure of RRC connection reconfiguration. This notification may include the reason for the failure. In the example of FIG. 21, this notification includes the 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 another DU other than DU#2 when a failure occurs. Alternatively, the CU may include in the RRC connection reconfiguration instruction an instruction to use DU#2 again after a certain period of time has elapsed when a failure occurs. Thus, the DU can be flexibly selected even when RRC connection reconfiguration fails.

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

[0344] In step ST1614 shown in FIG. 22, the CU notifies DU#3 of a communication start instruction. Step ST1614 may be the same as step ST1007 shown in FIG. 10. DU#3 performs RRC parameter setting for data transmission and reception with the UE using the information received in step ST1614.

[0345] In step ST1615 shown in FIG. 22, DU#3 notifies the CU of a communication start instruction response. Step ST1615 may be the same as step ST1008 in FIG. 10.

[0346] In steps ST1616 and ST1617 shown in FIG. 22, random access processing for the UE to communicate with the CU via DU#3 is performed. Signaling between DU#3 and the CU is performed in step ST1616, and radio signal transmission and reception between the UE and DU#3 are performed in step ST1617. Steps ST1616 and ST1617 may be the same processing as steps ST1009 and ST1010 in FIG. 10.

[0347] In step ST1617 shown in FIG. 22, the signaling necessary to start the transmission and reception of replication packets using DU#1 and #3 is completed.

[0348] The DU may send a notification of communication start failure to the CU. The notification may include the reason for the failure. Further, the reason for the failure may be, for example, the one described in section 9.2.6 of Non-Patent Document 15 (3GPP TS 36.423 v14.2.0), or other reasons. This enables the reason for the communication start failure of the DU to be notified in the same way as the reason for the failure in the conventional Xn interface, so that the complexity in the design of the CU can be avoided. The CU may proceed with the process using the reason for the failure. The process may be, for example, the use of another DU. This enables the CU and the UE to prevent the interruption of the sequence due to the failure of the communication start instruction to the DU and the accompanying operation stop.

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

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

[0351] In step ST1701 shown in FIG. 23, the CU notifies the DU#2 of an instruction to start communication. Step ST1701 may be the same as step ST1007 shown in FIG. 10. The DU#2 attempts to set RRC parameters for data transmission and reception with the UE using the information received in step ST1701.

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

[0353] Through sequences such as those shown in FIGS. 23 and 24, even when the instruction to start communication from the CU to the 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, before the CU reconfigures the RRC connection to the UE, the CU may notify the UE of the communication start instruction. For example, in FIGS. 23 and 24, steps ST1701 and ST1614 indicating the start of communication may be performed before steps ST1003, ST1004, ST1610, and ST1611 indicating the RRC connection reconfiguration. This eliminates the need to re-perform the RRC connection reconfiguration due to the failure of the DU to start communication, thus reducing the signaling volume. In the examples of FIGS. 23 and 24, steps ST1003 and ST1004 indicating the RRC connection reconfiguration and steps ST1005 and ST1006 indicating the completion of the RRC connection reconfiguration become unnecessary.

[0355] The DU may notify the CU of a communication stop failure. The DU may perform the notification after the instruction to stop communication from the CU to the DU. The notification of the failure may be the same as the notification of the communication start failure. Thus, the same effect as the notification of the communication start failure can be obtained.

[0356] The CU may stop user data communication with the UE via the DU. This stop may be performed on the DU that has notified the CU of a communication stop failure. This makes it possible to prevent unnecessary communication continuation in the case of a communication stop failure.

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

[0358] The DU may notify the CU of a communication change failure. The DU may perform this notification after a communication change instruction from the CU to the DU. The notification of the failure may be the same as the communication start failure notification. This makes it possible to obtain the same effect as the communication start failure notification.

[0359] The CU may continue user data communication with the UE via the DU. This continuation may be performed on the DU that has notified the CU of a communication change failure. This communication continuation may be performed using the parameters before being changed by the aforementioned communication change instruction. This makes it possible to maintain communication reliability even in the case of a communication change failure.

[0360] The CU may determine that a communication start instruction has failed when there is no response from the DU that has instructed communication start for a predetermined period. The aforementioned predetermined period may be determined in advance by a standard, may be determined by the CU, or may be determined by a higher-level network device and notified to the CU. This makes it possible to prevent the operation of the CU from stopping due to non-arrival of a communication start instruction response from the DU.

[0361] Similar to the above, the CU may determine that the communication stop instruction has failed due to no response from the DU that instructed the communication stop for a predetermined period. Also, the CU may determine that the communication change instruction has failed due to no response from the DU that instructed the communication change for a predetermined period. This makes it possible to prevent the operation of the CU from stopping due to non-arrival of the communication stop instruction response or the communication change instruction response from the DU.

[0362] Figures 25 and 26 are sequence diagrams for explaining the operation when the communication start response from the DU to the CU fails to arrive. Figure 25 and Figure 26 are connected at the position of the boundary line BL2526. Figures 25 and 26 show an example in which there is no response from DU#2 to the CU for a certain period with respect to the communication start instruction notified by the CU to DU#2. In Figures 25 and 26, the same step numbers are assigned to the same steps as in Figures 23 and 24, and common explanations are omitted.

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

[0364] According to the sequence of Figures 25 and 26, it is possible to prevent the operation of the CU from stopping while waiting for a response from DU#2, and for example, it becomes possible to resend the communication start instruction to another DU.

[0365] The CU and the DU may transmit and receive data to each other for verifying the normal operation of the peer entity. The CU and the DU may transmit and receive the data periodically. The CU and the DU may verify the normal operation of the peer entity using the data. The CU may exclude a DU that does not transmit the data for a certain period from the serving DUs. Alternatively, the CU may exclude a DU that does not transmit the data for a certain period from the candidate DUs. For example, the CU may exclude a DU that does not transmit the data for a certain period from the notification targets of a communication start instruction, a communication stop instruction, or a communication change instruction. As a result, the CU may not need to issue a communication start instruction, a communication stop instruction, or a communication change instruction to the DU. Therefore, it is 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 verifying the normal operation of the peer entity described above may include only the identifiers of the CU and the DU. This makes it possible to reduce the amount of signaling associated with verifying the normal operation of the peer entity.

[0367] The CU may notify the UE of an RRC connection reconfiguration. The notification may be performed using RRC signaling. The parameters shown in Section 6.2.2 of Non-Patent Document 16 (3GPP TS 36.311 v14.2.1) may be used for the notification. This makes it possible to avoid the complexity in the design of the CU and the UE regarding the RRC connection reconfiguration notification.

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

[0369] (1) An identifier indicating a bearer. For example, a bearer ID.

[0370] (2) Information regarding packet duplication. For example, an identifier indicating the presence or absence of packet duplication.

[0371] (3) Information on additional DUs.

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

[0373] (5) Information of the DU for which the settings are to be changed.

[0374] (6) Number of DUs in use.

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

[0376] (8) Combinations of the foregoing (1) to (7).

[0377] In the foregoing (1), for example, a bearer ID (DRB-ID) may be used. This enables the replication of U-Plane packets. Also, an identifier of a signalling radio bearer (abbreviated as SRB; e.g., SRB-ID) may be used. The SRB-ID may be, for example, SRB0, SRB1, or SRB2. This enables the replication of C-Plane packets.

[0378] In the foregoing (2), for example, an identifier indicating the presence or absence of packet replication may be included. This enables the UE to easily identify the presence or absence of packet replication. Also, information regarding the transmission ratio of replicated packets to each DU may be included. This enables the flexible change of the ratio of replicated packets in both uplink and downlink communications. Also, information regarding the priority of PDCP-PDUs received from each DU may be included. This enables the reduction of the processing amount of duplicate detection of PDCP-PDUs in the UE.

[0379] In the foregoing (3), for example, the number of additional DUs to be added may be included. As a result, it becomes possible for the UE to easily grasp setting parameters and the like for the additional DUs on RRC signaling. Further, the identifier of the additional DU to be added may be included. The identifier of the DU may be the foregoing DU-ID or the cell ID. As a result, the UE can easily identify the opposing DU. Further, RRC parameters for communicating with the DU may be included. The foregoing RRC parameters may include parameters related to the New AS layer, PDCP layer, RLC layer, MAC layer, or PHY layer. As a result, communication establishment between the UE and the DU becomes possible.

[0380] In the foregoing (4), for example, the number of DUs to be released may be included. As a result, it becomes possible for the UE to easily grasp parameters and the like for the released DUs on RRC signaling. Further, the ID of the DU to be released may be included. The identifier of the DU may be the same as the identifier of the DU in the foregoing (3). As a result, the same effect as in the foregoing (3) can be obtained. Further, an identifier indicating the presence or absence of release of the split bearer between DUs for the DU may be included. As a result, when using a split bearer between DUs in communication using a plurality of DUs, it becomes possible to reduce the processing amount in reconfiguring a DU that has been released once.

[0381] In the foregoing (5), for example, the number of DUs to be changed may be included. As a result, it becomes possible for the UE to easily grasp setting parameters and the like for the changed DUs on RRC signaling. Further, the 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 foregoing (3). As a result, the same effect as in the foregoing (3) can be obtained. Further, RRC parameters for communicating with the DU may be included. The foregoing RRC parameters may be the same as the RRC parameters in the foregoing (3). As a result, the same effect as in the foregoing (3) can be obtained.

[0382] In the above (6), by notifying the changed number of DUs from the CU to the UE, the UE can easily grasp the number of DUs to be used after RRC connection reconfiguration.

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

[0384] In the above (7), the entities of each layer may be re - established. By doing so, it is possible to reduce the processing load of the UE associated with RRC parameter change.

[0385] The UE may notify the CU of the completion of RRC connection reconfiguration. This 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 this notification. By doing so, it is possible to avoid the complexity in the design of the CU and the UE regarding the RRC connection reconfiguration completion notification.

[0386] Alternatively, the PDCP sequence number received by the UE may be included in the RRC connection reconfiguration completion notification. By doing so, it is possible to prevent data loss in RRC connection reconfiguration. The UE may notify the above - mentioned PDCP sequence number independently of the RRC connection reconfiguration completion notification. By doing so, it is possible to avoid the complexity of the design regarding the RRC connection reconfiguration completion notification in the CU and the UE.

[0387] The above-mentioned RRC connection reconfiguration completion notification in Embodiment 1 may include a failure reason. 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, when the value indicating the failure reason is 0, it may be assigned to RRC connection reconfiguration completion. This reduces the types of signaling, thus facilitating the processing in the UE and the CU.

[0388] The CU may notify the DU of a communication start instruction. The instruction may be carried out using signaling on the CU-DU interface, for example, the Fs interface. The parameters described in SeNB Addition Request in Section 9.1.3.1 of Non-Patent Document 15 (3GPP TS 36.423 v14.2.0) may be used for the instruction. The parameters used in SCG-ConfigInfo in Section 10.2.2 of Non-Patent Document 16 (3GPP TS 36.311 v14.2.1) may also be used for the instruction. This makes it possible to avoid the complexity in the design of the CU and the 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. For example, a bearer ID.

[0391] (2) Information regarding packet duplication. For example, an identifier indicating the presence or absence of packet duplication.

[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 entities of each layer are not re-established.

[0396] (7) The combination of the foregoing (1) to (6).

[0397] In the foregoing (1), the same information as the foregoing information (1) in the RRC connection reconfiguration notification from the CU to the UE may be used. By this, the same effect as the foregoing information (1) in the RRC connection reconfiguration notification can be obtained.

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

[0399] By using the foregoing (3), it is possible to prevent malfunction due to another DU receiving the instruction erroneously and performing processing.

[0400] By using the foregoing (4), the DU can identify the UE that is the communication counterparty entity indicated by the instruction.

[0401] The RRC parameters in the foregoing (5) may include parameters related to the RLC layer, the MAC layer, or the PHY layer. By this, it is possible to establish communication between the UE and the DU.

[0402] The layer indicated in the foregoing (6) may be the RLC layer, the MAC layer, or the PHY layer. By this, it is possible to prevent data loss by preventing buffer clearing due to re - establishment of the entity of the foregoing layer. Furthermore, by preventing re - transmission from the PDCP layer in the CU and the UE, it is possible to reduce the delay of data transmission.

[0403] In the foregoing (6), the entity of each layer may be re - established. By this, it is possible to reduce the processing amount of the DU associated with the RRC parameter change.

[0404] The DU may notify the CU of a communication start instruction response. By doing so, the CU can grasp the state of the DU, for example, whether the DU has a failure.

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

[0406] (1) An identifier indicating a bearer. For example, 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 the process associated with the communication start instruction.

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

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

[0411] According to the above (2), for example, when the CU notifies a communication start instruction to a plurality of 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. Among the above identifiers, a value indicating that the process associated with the communication start instruction has succeeded may be added. The above value may be, for example, 0. By doing so, it is possible to integrate the above communication start instruction response and the above communication start failure notification, and it is 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. By doing so, it is possible to reduce the amount of padding.

[0414] Alternatively, 64-bit alignment may be used for the Fs interface. This facilitates data alignment in communication using 64b / 66b.

[0415] The Fs interface may apply the method defined in the CPRI (see Non-Patent Document 17) interface as the CU-DU interface. This enables the interface to be shared between the option of implementing CU-DU separation at a low layer and the option of implementing CU-DU separation at a high layer (e.g., Option 2).

[0416] In the above, control information may be placed in a control block and data may be placed in a data block. This can improve the efficiency of communication over the Fs interface.

[0417] The Fs interface may have a collision avoidance function. This enables the aggregation of the wiring between the CU and multiple DUs while ensuring low latency and high reliability.

[0418] The Fs interface may apply the method defined in the S1 interface as the CU-DU interface. This can avoid the complexity in the design of the Fs interface.

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

[0420] In the above, the DU may use the RRC signaling from the CU to the UE as configuration information for its own DU. This enables the signaling from the CU to the DU (e.g., communication start instruction) to be shared with the RRC signaling from the CU to the UE (e.g., RRC connection reconfiguration notification), thereby reducing the signaling volume.

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

[0422] The technique of transmitting and receiving replicated packets using a plurality of DUs described in the first embodiment may be applied to mobility between DUs. In the mobility between DUs, the above-mentioned addition of the used DU and the above-mentioned release of the used DU may be combined. This makes it possible to ensure the reliability before and after the mobility between DUs.

[0423] When applying the technique of transmitting and receiving replicated packets using a plurality of DUs to mobility between DUs, the CU may notify the UE of information indicating that the C-Plane data is transmitted via the destination DU. This notification may be performed using the RRC signaling from the CU to the UE, for example, RRC connection reconfiguration. The RRC connection reconfiguration may be performed when adding the used DU in the mobility between DUs. This enables the UE to smoothly receive the RRC signaling at the time of releasing the used DU in the mobility between DUs.

[0424] Alternatively, instead of the information indicating transmission via the destination DU, the CU may notify the UE of the information indicating transmission via either the destination DU or the source DU. The CU may transmit the RRC signaling at the time of releasing the serving DU in 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 the DU with a better channel condition with the UE. The UE may be able to receive the RRC signaling from both the source DU and the destination DU. Thereby, for example, the CU can use the DU with a better channel condition with the UE, making it possible to improve the reliability in C-Plane data transmission.

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

[0426] FIG. 27 and FIG. 28 are diagrams showing the sequence of DU mobility using the replicated packet transmission and reception technique. FIG. 27 and FIG. 28 are connected at the position of the boundary line BL2728. FIGS. 27 and 28 show an example in which the communication between the CU and the UE switches from the communication using DU#1 to the communication using DU#1, #2, and packet replication, and then switches to the communication using DU#2. In FIGS. 27 and 28, the same step numbers are assigned to the same steps as in FIGS. 10, 11, 14, and 15, and the 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 results. This notification may be performed using RRC signaling. In step ST1905, the UE transmits the measurement results to DU#1, and in step ST1906, DU#1 transmits the measurement results to the CU. In step ST1907, the CU determines the presence or absence of DU mobility using the measurement results. In the example of FIG. 27, it is determined in step ST1907 that packet duplication is performed using DU#1 and DU#2.

[0428] In the sequence of steps ST1007, ST1008, ST1201 to ST1205, ST1009, and ST1010 shown in FIG. 27, the addition of DU#2 and the setting of packet duplication are performed.

[0429] In steps ST1908 to ST1914 shown in FIG. 28, user data communication by packet duplication using DU#1 and DU#2 is performed. 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 steps ST1904 to ST1906 described above are performed. In step ST1918, the CU determines the presence or absence of DU mobility using the measurement results of step ST1917. In the example of FIG. 28, it is determined in step ST1918 that communication is performed using only DU#2.

[0431] In steps ST1919 and ST1920 shown in FIG. 28, a communication stop instruction from the CU to DU#1 and a communication stop instruction response from DU#1 to the CU are performed. Steps ST1919 and ST1920 may be the same as steps ST1412 and ST1413 in FIG. 18, respectively.

[0432] In steps ST1921 to ST1924 shown in FIG. 28, RRC connection reconfiguration from the CU to the UE and an RRC connection reconfiguration completion notification from the UE to the CU are performed. In the example of FIG. 28, DU#1 release and packet duplication release settings are performed. Step ST1921 indicates the transmission of RRC connection reconfiguration from the CU to DU#2, step ST1922 indicates the transmission of RRC connection reconfiguration from DU#2 to the UE, step ST1923 indicates the transmission of an RRC connection reconfiguration completion notification from the UE to DU#2, and step ST1924 indicates an RRC connection reconfiguration completion notification from DU#2 to the CU.

[0433] In step ST1925 shown in FIG. 28, the CU notifies DU#1 of the completion of UE reconfiguration. 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 using DU#2 is performed. Step ST1930 indicates the transmission of user data between the upper network device and the CU, step ST1931 indicates the transmission and reception of user data between the CU and DU#2, and step ST1932 indicates the transmission and reception of user data between DU#2 and the UE.

[0435] In FIGS. 27 and 28, the DU used in the measurement result notification may be the DU before movement. This eliminates the need for a DU change instruction, thereby reducing the signaling amount.

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

[0437] According to Embodiment 1, since packet communication using a plurality of DUs becomes possible, it is possible to ensure high reliability and low latency of communication between the CU and the UE.

[0438] According to Embodiment 1, 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 capable of wireless communication 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 duplicates 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, the communication terminal device deletes the duplicate downlink packets according to a predetermined downlink packet deletion criterion.

[0440] Here, the communication terminal device may transmit a duplicate of an uplink packet transmitted from the communication terminal device to two or more of the plurality of 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 variously modified based on the disclosure and suggestions of this specification including Embodiment 1. According to the above configuration and its modified configurations, the above problems can be solved and the above effects can be obtained.

[0442] Modification Example 1 of Embodiment 1. In Embodiment 1, packet duplication in Option 2 of CU-DU separation was described, but packet duplication may be applied to Option 3-1 of CU-DU separation.

[0443] The CU duplicates the packets transferred from the upper-layer network device. The CU may perform the packet duplication at the PDCP layer. The CU transfers the duplicated packets to the RLC-H layer facing each DU. Each RLC-H layer transmits the packets to the peer DU. Each DU transmits the packets to the UE. The UE performs duplicate detection of the packets. The UE deletes the duplicate packets.

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

[0445] Also, the UE duplicates the packets and transmits the duplicated packets to each DU via the entities of the lower layer facing 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 duplicate detection. The PDCP layer of the CU deletes the duplicate packets. The CU transfers the packets that have not been deleted to the upper-layer network device.

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

[0447] FIG. 29 is a diagram showing a configuration in which packets of the PDCP layer are duplicated in downlink communication using a plurality of DUs for Option 3-1 of CU-DU separation. In FIG. 29, the same blocks as those in FIG. 8 are denoted by the same numbers, and the common descriptions are omitted.

[0448] In FIG. 29, the PDCP layer 809 transfers the PDCP-PDU #1 (PDCP-PDU 812) to the RLC-H layer 2001. Also, 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 attaches an RLC header 2005 to the PDCP-PDU #1 to generate an RLC-PDU #1 (which may also be referred to as RLC-PDU 2008). The RLC-H layer 2001 transfers the RLC-PDU #1 to the RLC-L layer 2012 of the DU #1 (DU 802) using the Fs interface 814. Similarly, the RLC-H layer 2002 attaches an RLC header 2006 to the PDCP-PDU #2 to generate an RLC-PDU #2 (which may also be referred to as RLC-PDU 2009). The RLC-H layer 2002 transfers the RLC-PDU #2 to the RLC-L layer 2013 of the DU #2 (DU 803) using the Fs interface 815.

[0450] In Fig. 29, the DU #1 transmits the RLC-PDU #1 received at the RLC-L layer 2012 to the DU #1 facing 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 facing 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 obtains the PDCP-PDU #1 by removing 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 perform packet duplicate detection and delete the duplicate packets is the same as that in Fig. 8.

[0452] For other detailed operations, since they are the same as those in Embodiment 1, the description is omitted. By applying the same method as in Embodiment 1, the same effects as in Embodiment 1 can also be obtained in Option 3-1 of CU-DU separation.

[0453] According to Variant 1 of Embodiment 1, even when Option 3-1 of CU-DU separation is used, high reliability and low latency of communication can be ensured by packet duplication.

[0454] Embodiment 2 In NR, it has been proposed that packet duplication be performed at a layer lower than the PDCP layer, that is, the RLC layer or the MAC layer, to ensure high reliability and low latency while quickly coping with changes in the channel status (see Non-Patent Document 14 (3GPP R2-1701472)).

[0455] On the other hand, in Variant 1 of Embodiment 1, a method of performing packet duplication at the PDCP layer in Option 3-1 of CU-DU separation and communicating with the UE using a plurality of subordinate DUs was disclosed.

[0456] However, according to Variant 1 of Embodiment 1, the RLC-H layer below the PDCP layer also exists in the CU. For this reason, there arises a problem that the buffer usage amount in the RLC-H layer increases and the processing amounts in the PDCP layer and the RLC-H layer increase.

[0457] In this Embodiment 2, a method for solving such a problem is disclosed.

[0458] The CU performs packet duplication at 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 performs duplicate detection 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] Also, the UE duplicates the packets at the RLC-H layer and transmits them to each DU via the entity of the RLC-L layer facing each DU. The RLC-L layer of each DU transfers the received packets to the CU. The RLC-H layer of the CU performs duplicate detection on the packets received from the RLC-L layer of each DU. The RLC-H layer of the CU deletes the duplicate packets. The RLC-H layer of the CU transfers the packets that have not been deleted to the upper-layer network device via the upper layer.

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

[0462] The CU and / or UE may assign the same RLC sequence number to the duplicated packets. This facilitates duplicate detection of the packets at the receiving UE and / or CU.

[0463] The CU and / or UE may assign the RLC sequence number in the same manner as the assignment of the PDCP sequence number in Embodiment 1. This facilitates duplicate detection of the packets at the receiving UE and / or CU, similar to Embodiment 1.

[0464] Embodiment 1 and Modification Example 1 of Embodiment 1 used the PDCP sequence number, while Embodiment 2 uses the RLC sequence number, which is different from Embodiment 1 and Modification Example 1 of Embodiment 1. Also, Embodiment 2 is different from Non-Patent Document 14 in that the CU performs transmission and reception with the UE using a plurality of DUs under its control by packet duplication in the RLC-H layer.

[0465] FIG. 30 is a diagram showing a configuration in which packets of the RLC-H layer are duplicated in downlink communication using a plurality of DUs for Option 3-1 of CU-DU separation. In FIG. 30, the same blocks as those in FIG. 29 are denoted by the same reference numerals, and the common description is omitted.

[0466] In FIG. 30, the PDCP layer 2104 attaches 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 duplicates the PDCP-PDU 2101 into two, attaches an RLC header 2106 to one of the replicated PDUs to generate an RLC-PDU #1 (which may also be referred to as RLC-PDU 2108), and attaches an RLC header 2107 to the other replicated PDU to generate an RLC-PDU #2 (which may also be referred to as RLC-PDU 2109). The RLC headers 2106 and 2107 include information of the same sequence number #m in FIG. 30, but may include information of different sequence numbers. For example, by numbering the sequence numbers of the RLC headers 2106 and 2107 consecutively, the design of the sequence number assignment section of the RLC layer becomes easier.

[0468] In FIG. 30, the RLC-H layer 2105 transfers the RLC-PDU #1 to the RLC-L layer 2012 of 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 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 duplicates, and deletes RLC-PDU #2. The RLC-H layer 2110 obtains the PDCP-PDU 2101 by deleting the RLC header 2106 from RLC-PDU #1, and transfers the PDCP-PDU 2101 to the PDCP layer 2111. The RLC-H layer 2110 deletes RLC-PDU #2 in the example of FIG. 30, but it may also delete RLC-PDU #1. In that case, the RLC-H layer 2110 obtains the PDCP-PDU 2101 by deleting the RLC header 2107 from RLC-PDU #2, and transfers the PDCP-PDU 2101 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 obtained PDCP-SDU 808 to the New AS Layer 823.

[0472] For other detailed operations, since they are the same as those in Embodiment 1, the description is omitted. By applying the same method as in Embodiment 1, the same effects as in Embodiment 1 can be obtained even in Option 3-1 of CU-DU separation.

[0473] According to this Embodiment 2, the same effects as in Modification Example 1 of Embodiment 1 can be obtained. Furthermore, compared with Modification Example 1 of Embodiment 1, since it is possible to reduce the buffer usage amount in the RLC-H layer, it is possible to reduce the buffer mounting amount in the RLC-H layer. Also, compared with Embodiment 1 and Modification Example 1 of Embodiment 1, since packet duplication and duplicate packet detection are performed at a lower layer, packet processing in the CU and UE becomes faster.

[0474] According to Embodiment 2, similar to Embodiment 1, 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 capable of wireless communication with the communication terminal device. More specifically, the base station device includes a plurality of DUs (Distributed Units) that transmit and receive wireless signals, and a CU (Central Unit) that controls the plurality of DUs. The CU duplicates a downlink packet destined for 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 wireless signals. When the communication terminal device receives overlapping downlink packets, the overlapping downlink packets are deleted according to a predetermined downlink packet deletion criterion.

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

[0477] Based on the disclosure and suggestions in this specification including Embodiment 2, the above configuration can be variously modified. According to the above configuration and its modified configurations, the above problems can be solved and the above effects can be obtained.

[0478] Embodiment 3. In Embodiment 1, Modification Example 1 of Embodiment 1, and Embodiment 2, a method for ensuring low latency and high reliability by performing packet duplication and transmitting and receiving the packet using a plurality of DUs was disclosed.

[0479] Even when mobility occurs between DUs, it is possible to ensure the reliability of data transmission and reception before and after the mobility between DUs by using the aforementioned packet duplication.

[0480] However, as described above, there is a problem that packet duplication consumes a large amount of wireless resources and buffers of DUs under the CU.

[0481] In Embodiment 3, a method for solving such a problem is disclosed.

[0482] The DU notifies the CU of the information on the PDCP sequence number. The DU notifies the CU of the sequence number of the PDCP-PDU for which HARQ delivery confirmation has been obtained in the local DU as the aforementioned PDCP sequence number. The CU transmits a PDCP-PDU that does not correspond to the PDCP sequence number to the DU.

[0483] The above operation may be performed when DU-to-DU mobility occurs. For example, the DU that notifies the CU of the information on 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 aforementioned PDCP sequence number may be the target DU. As a result, when DU-to-DU mobility occurs, it becomes possible to retransmit a PDCP-PDU for which delivery confirmation from the source DU to the UE has not been obtained from the CU to the target DU. Therefore, it is possible to prevent PDCP-PDU loss in DU-to-DU mobility. Also, it becomes possible to quickly perform the retransmission of the aforementioned PDCP-PDU.

[0484] Also, the above operation may be performed when DU-to-DU mobility has not occurred. For example, the DU that notifies the CU of the information on the PDCP sequence number may be the same as the DU to which the CU transmits a PDCP-PDU that does not correspond to the aforementioned PDCP sequence number. As an application to the case where DU-to-DU mobility has not occurred, for example, when HARQ maximum retransmission count exceeded occurs, the DU may notify the CU of the PDCP sequence number of the PDCP-PDU included in the transport block data for which HARQ retransmission exceeded. As a result, for example, the CU can quickly retransmit the PDCP-PDU included in the transport block data for which HARQ retransmission exceeded to the DU.

[0485] The DU may notify the aforementioned PDCP sequence number using an interface between the CU and the DU, such as the Fs interface. The notification via the Fs interface may be, for example, the method defined at the S1 interface applied as the interface between the CU and the DU in the same manner as in Embodiment 1. This makes it possible to avoid the complexity in the design of the Fs interface. Also, for example, by transmitting the aforementioned PDCP sequence number as control information of the Fs interface, it is possible to notify with less overhead.

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

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

[0488] The PDCP sequence number used in Embodiment 3 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 that does not use the feedback performed by the peer entity for delivery confirmation.

[0489] The foregoing 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 HARQ. The CU may transfer the PDCP-PDU with the PDCP sequence number to the destination DU. As a result, it is not necessary to increment the PDCP sequence number by the CU, so it is possible to reduce the processing amount in the CU.

[0490] Alternatively, the foregoing PDCP sequence number may be the PDCP sequence number of the last one among the consecutive PDCP-PDUs for which HARQ delivery confirmation has been obtained at the DU. As a result, it is possible to reduce the amount of signaling from the DU to the CU.

[0491] Alternatively, as information indicating the foregoing PDCP sequence number, for example, the source DU may notify the CU of the delivery status of the PDCP-PDUs in the form of a bitmap. As a result, for example, when the PDCP-PDUs for which delivery confirmation has not been obtained are non-consecutive, the CU can efficiently retransmit the PDCP-PDUs for which delivery confirmation has not been obtained to the destination DU.

[0492] Alternatively, the information indicating the foregoing PDCP sequence number may be, for example, information combining the PDCP sequence number of the latest transmitted PDCP-PDU among the PDCP-PDUs for which delivery confirmation has been obtained and the sequence numbers of the PDCP-PDUs for which delivery confirmation has not been obtained before the PDCP sequence number. As a result, while suppressing the amount of signaling for notification from the source DU to the CU, the CU can efficiently retransmit the PDCP-PDUs for which delivery confirmation has not been obtained to the destination DU.

[0493] Alternatively, the information indicating the foregoing PDCP sequence number may be information that combines, for example, the PDCP sequence number of the earliest transmitted PDCP-PDU among the PDCP-PDUs for which delivery confirmation has not been obtained and the sequence numbers of the PDCP-PDUs for which delivery confirmation has been obtained after the PDCP sequence number. By doing so, particularly when there are few PDCP-PDUs for which delivery confirmation has been obtained, the same effects as described above can be obtained.

[0494] Alternatively, the information indicating the foregoing 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. By doing so, the CU and the DU can respond quickly in association with the DU mobility.

[0495] The DU may associate the HARQ-ACK information received from the UE with the PDCP-SN information. This association may be always performed during the communication continuation between the DU and the UE. By doing so, it becomes possible to quickly notify the PDCP sequence number to the CU when DU mobility occurs.

[0496] An example of the foregoing method for associating the HARQ-ACK information with the 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 foregoing PDCP sequence number with the RLC sequence number of the RLC-PDU that the own RLC layer transmitted to the MAC layer 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 foregoing RLC sequence number with the HARQ process number when the own MAC layer transmits the RLC-PDU to the UE as transport block data.

[0499] The MAC layer of the DU uses the HARQ-ACK information from the UE to obtain the HARQ process number for which delivery confirmation has been received. The MAC layer of the DU uses the HARQ process number and the information on the association between the RLC sequence number and the HARQ process number described above to obtain the RLC sequence number for which delivery confirmation has been received. The MAC layer of the DU notifies the RLC layer of the DU of the information on the RLC sequence number.

[0500] The RLC layer of the DU uses the information on the RLC sequence number notified by the MAC layer of the DU and the information on the association between the PDCP sequence number and the RLC sequence number described above to obtain the PDCP sequence number for which delivery confirmation has been received.

[0501] According to the above-described association method, in the delivery confirmation of PDCP-PDUs, feedback information from the RLC layer and the PDCP layer of the UE becomes unnecessary. Therefore, it becomes possible to quickly perform the delivery confirmation of PDCP-PDUs.

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

[0503] In Non-Patent Document 19 (3GPP R2-1700177), HARQ-NACK from the UE is used for delivery confirmation in the RLC layer. In contrast, 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 in the PDCP layer is performed by associating the RLC sequence number and the PDCP sequence number.

[0504] When DU-to-DU mobility occurs, the transmission stop of the source DU may be performed after transmitting the data accumulated in the buffer of the DU to the UE. The aforementioned data may be HARQ retransmission data. Alternatively, the aforementioned data may include data that is not scheduled and is accumulated in the RLC buffer. This makes it possible to improve the reliability in transmitting the data accumulated in the buffer of the DU.

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

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

[0507] In FIG. 31, the RLC layer 2202 in DU#1 (DU802) obtains the PDCP sequence number from the PDCP-PDU acquired from the PDCP layer 2201 in CU801. The RLC layer 2202 transfers the RLC-PDU generated using the PDCP-PDU to the MAC layer 2203, and manages by associating the RLC sequence number of the RLC-PDU and the PDCP sequence number.

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

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

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

[0511] In FIG. 31, the RLC layer 2202 obtains the PDCP sequence number for which delivery confirmation has been obtained using the RLC sequence number notification 2206 and the correspondence between the above-described RLC sequence number and PDCP sequence number.

[0512] In FIG. 31, the RLC layer 2202 and the MAC layer 2203 may update at any time the RLC sequence number for which delivery confirmation has been obtained and the PDCP sequence number for which delivery confirmation has been obtained, using the HARQ-ACK information from the MAC layer 2210 of the UE 804. This enables the PDCP sequence number to be quickly notified from DU#1 to the CU when DU mobility occurs. Alternatively, the above update may be performed when DU mobility occurs. This makes it possible to reduce the processing load on the RLC layer 2202 and the MAC layer 2203.

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

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

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

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

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

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

[0519] In steps ST1904 to ST1906 and ST2315 shown in Figure 32, measurements of DU#1 and DU#2 by the UE, notification of the measurement results from the UE to the CU, and determination of DU mobility by the CU are performed. In the example of Figure 32, it is determined in step ST2315 to perform mobility from DU#1 to DU#2.

[0520] In step ST2320 shown in FIG. 33, DU#1 notifies the CU of the information on the delivery confirmation 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 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 switch from DU#1 to DU#2 is completed by steps ST1205, ST1925, ST1009, and ST1010 shown in FIG. 33.

[0523] In step ST2341 shown in FIG. 34, the CU uses the PDCP sequence number information notification in step ST2320 to transmit PDCP-PDUs with unacknowledged delivery PDCP sequence numbers to DU#2. FIG. 34 shows an example where the PDCP-PDUs with unacknowledged delivery PDCP sequence numbers are PDCP-PDUs with PDCP sequence numbers after the PDCP sequence number in step ST2320.

[0524] In steps ST2342 to ST2347 shown in FIG. 34, the same processing as in steps ST2302 to ST2307 is performed at DU#2.

[0525] In FIGS. 32 to 34, the notification of the PDCP sequence number information in step ST2320 may be performed after step ST1925, that is, after the notification of the completion of UE reconfiguration from the CU to DU#1. As a result, DU#1 can notify the CU of the PDCP sequence number for which delivery confirmation has been obtained immediately before the DU handover. Therefore, it is possible to reduce the duplication of PDCP-PDU transmission.

[0526] As another example of the sequence related to mobility for performing PDCP delivery confirmation using HARQ-ACK, the UE may make a mobility determination. As a result, since it is not necessary to notify the measurement result, it is possible to reduce 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 the data accumulated in its own buffer to the CU. The data may include HARQ retransmission data, or may include data accumulated in the RLC buffer, that is, data for which HARQ scheduling has not been performed. As a result, it is possible to improve the reliability of data transmission when DU-to-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 accumulated in its own buffer. As a result, it is possible to perform DU-to-DU mobility quickly.

[0529] FIGS. 35 to 37 are diagrams showing other sequences related to mobility for performing PDCP delivery confirmation using HARQ-ACK. FIGS. 35 to 37 are connected at the positions of the boundary lines BL3536 and BL3637. In the example of FIGS. 35 to 37, a mobility determination is made in the UE. In FIGS. 35 to 37, the same step numbers are assigned to the same steps as in FIGS. 32 to 34, and the common description is omitted.

[0530] In step ST2410 shown in FIG. 35, the UE determines mobility using the measurement result of step ST1904. In the examples of FIGS. 35 to 37, a switch 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, an inter-DU mobility request is transmitted from the UE to DU#1, and in step ST2412, an inter-DU mobility request is transmitted from DU#1 to the CU.

[0531] By the sequence shown in FIGS. 35 to 37, it is possible to reduce the amount of signaling for measurement result notification.

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

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

[0534] When applying the method shown in the third embodiment to the notification of PDCP sequence numbers from the DU to the CU when the maximum number of HARQ retransmissions is exceeded as described above, an example of detailed operation is disclosed below.

[0535] The MAC layer of the DU may obtain the RLC sequence number including the transport block that has exceeded the maximum HARQ retransmission count, using the HARQ process number when transmitting a transport block that has exceeded the maximum HARQ retransmission count, and the information on the association between the RLC sequence number and the HARQ process number described above.

[0536] The RLC layer of the DU obtains the PDCP sequence number of the PDCP-PDU including the transport block that has exceeded the maximum HARQ retransmission count, using the information on the RLC sequence number notified from the MAC layer of the DU and the information on the association between the PDCP sequence number and the RLC sequence number described above. The RLC layer of the DU notifies the CU of the PDCP sequence number.

[0537] The method shown in Embodiment 3 may be applied to mobility between secondary base stations. By respectively replacing the CU, the source DU, and the destination DU in Embodiment 3 with the master base station, the source secondary base station, and the destination secondary base station, the application to mobility between secondary base stations can be implemented. Thereby, it becomes possible to ensure low latency and reliability in mobility between secondary base stations.

[0538] The method shown in Embodiment 3 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 the New AS Layer 807, and the packet 806 is directly transmitted from the upper network device 805 to the PDCP 2201. Also, the UE 804 does not have the New AS Layer 823, and the PDCP-SDU 2225 is directly transferred from the PDCP layer 2220 to the upper layer 824.

[0539] By applying the method shown in Embodiment 3 to the mobility during C-Plane data transfer, for example, the reliability of NAS data transmission during DU mobility can be enhanced.

[0540] Although downlink communication was described in Embodiment 3, Embodiment 3 may be applied to uplink communication. Specifically, by replacing the PDCP layer of the CU with the PDCP layer of the UE, and replacing the RLC layer and MAC layer of the DU with the RLC layer and MAC layer of the UE respectively, and replacing the MAC layer of the UE with the MAC layer of the DU, application to uplink communication can be implemented. As a result, it becomes possible to ensure reliability without performing packet duplication also in uplink communication.

[0541] In Embodiment 3, the foregoing PDCP-PDU may be transferred from the source DU to the destination DU. The PDCP-PDU may be a PDCP-PDU containing transport block data for which a HARQ delivery confirmation has not been obtained at the source DU. As a result, since the data transferred from the CU to the destination DU is transferred from the source DU to the destination DU, it becomes possible to reduce the data transfer amount between the CU and the DU.

[0542] In the foregoing transfer from the source DU to the destination DU, a DU interface may be provided. The source DU may use the DU interface for transferring the PDCP-PDU to the destination DU. This enables communication between DUs.

[0543] In the foregoing DU interface, a method defined in the X2 / Xn interface may be used as the DU interface. For example, a new message named MOBILITY DATA TRNSFER may be provided to perform the foregoing PDCP-PDU transfer. This makes it possible to avoid the complexity in the design of the DU interface. Also, since the same processing as the inter-base station communication in DC can be applied, it becomes possible to reduce the processing amount of the base station.

[0544] The method shown in Embodiment 3 may be applied to a base station and a UE that perform communication using RLC-AM. By doing so, it becomes possible to perform retransmission control more quickly than the ARQ of the conventional RLC.

[0545] By the method shown in Embodiment 3, it is possible to ensure reliability and low latency while suppressing resource usage due to packet duplication.

[0546] According to Embodiment 3, 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 capable of wireless communication 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 regarding packets that have been delivered to the communication terminal device from the DU connected to the communication terminal device. The CU transmits packets not indicated in the delivery completion information from the aforementioned DU or another DU to the communication terminal device.

[0548] Here, in Embodiment 3, an example in which the delivery completion information is the sequence number of a packet notified as having been delivered from the communication terminal device is disclosed. However, the delivery completion information is not limited to this example.

[0549] The above configuration can be variously modified based on the disclosure and suggestions of this specification including Embodiment 3. According to the above configuration and its modified configurations, the above problems can be solved and the above effects can be obtained.

[0550] Modification Example 1 of Embodiment 3. In Embodiment 3, an example of performing PDCP delivery confirmation using HARQ-ACK in Option 2 of CU-DU separation was described. The PDCP delivery confirmation using HARQ-ACK may be applied to Option 3-1 of CU-DU separation.

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

[0552] This Modification Example 1 is different from Embodiment 3 in that the RLC sequence number is used instead of the PDCP sequence number.

[0553] FIG. 38 is a diagram showing a configuration for performing RLC delivery confirmation using HARQ-ACK for Option 3-1 of CU-DU separation. In FIG. 38, the same blocks as those in FIG. 31 are denoted by the same numbers, and the common descriptions are omitted.

[0554] In FIG. 38, the RLC-L layer 2501 in DU#1 (DU802) obtains the RLC sequence number from the RLC-PDU acquired from the RLC-H layer 2502 in CU801. The RLC-L layer 2501 transfers the RLC-PDU to the MAC layer 2203.

[0555] In FIG. 38, the MAC layer 2203 obtains the RLC sequence number from the RLC-PDU. The MAC layer 2203 transmits the transport block data generated using the RLC-PDU to the UE804, and manages the HARQ process number used for transmitting the transport block data in association with the RLC sequence number.

[0556] In FIG. 38, assume that the MAC layer 2210 in UE804 correctly receives user data (transport block generated using RLC-PDU2504) from the MAC layer 2203 in DU#1. The MAC layer 2210 notifies the MAC layer 2203 in DU#1 of the HARQ-ACK information 2205.

[0557] In FIG. 38, the MAC layer 2203 in DU#1 obtains the HARQ process number that has become 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 association between the HARQ process number and the above-mentioned HARQ process number and the RLC sequence number. The MAC layer 2203 transmits the RLC sequence number to the RLC-L layer 2501 as the 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 at any time by using the HARQ-ACK information obtained from the MAC layer 2210 of the UE804. As a result, it becomes possible to quickly notify the RLC sequence number from DU#1 to the CU when DU mobility occurs. Alternatively, the above update may be performed when DU mobility occurs. As a result, it becomes possible to reduce the processing load on the RLC-L layer 2501 and the MAC layer 2203.

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

[0560] In FIG. 38, the RLC-H layer 2502 transmits the RLC-PDU 2504 of the RLC sequence number for which delivery confirmation has not been obtained (for example, m + 1) to DU#2 (DU803) by using the RLC sequence number notification 2503. The Fs interface 815 is used for this transmission.

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

[0562] For other detailed operations, since they are the same as those in Embodiment 3, the description is omitted. By applying the same method as in Embodiment 3, the same effects as in Embodiment 3 can be obtained even in Option 3-1 of CU-DU separation.

[0563] According to Modification Example 1 of Embodiment 3, even when using Option 3-1 of CU-DU separation, it is possible to suppress the resource usage due to packet duplication while ensuring reliability and low latency.

[0564] Embodiment 4. In a base station configuration using DC, when mobility occurs in the secondary base station, for example, when a change occurs in the secondary base station, the source secondary base station transfers the downlink PDCP-PDUs for which the UE has not received an acknowledgment of delivery to the master base station. The master base station transfers the PDCP-PDUs to the target secondary base station (see Non-Patent Document 1).

[0565] However, according to the above method, when mobility occurs, data transfer from the source secondary base station to the master base station occurs, resulting in a problem that the bandwidth of the interface between the base stations is congested.

[0566] Embodiment 4 discloses a method for solving such a problem.

[0567] When mobility occurs in the secondary base station, the master base station transfers the PDCP-PDUs for which an acknowledgment of delivery to the UE has not been received to the target secondary base station. The target secondary base station transmits or retransmits the PDCP-PDUs 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] Figure 39 is a sequence diagram showing secondary base station - to - secondary base station mobility using PDCP status reports from the UE. Figure 39 shows an example where the secondary base station switches from SgNB#1 to SgNB#2.

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

[0575] In step ST2603 shown in Figure 39, an SgNB addition request is notified from MgNB to SgNB#2. In step ST2604, an affirmative response to step ST2603 is returned from SgNB#2 to MgNB. In step ST2605, an SgNB release request is notified from MgNB to SgNB#1.

[0576] In step ST2607 shown in Figure 39, MgNB notifies the UE of an RRC connection re - configuration. The notification includes information indicating that the secondary base station is to be switched from SgNB#1 to SgNB#2. The notification may also include RRC parameters for SgNB#2. In step ST2608, the UE notifies MgNB of the completion of the RRC connection re - configuration.

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

[0578] In step ST2610 shown in Figure 39, MgNB notifies SgNB#2 of the completion of the SgNB re - configuration. In step ST2611, random access processing is performed between the UE and SgNB#2, and the UE is connected to SgNB#2.

[0579] In step ST2612 shown in FIG. 39, MgNB transfers user data to SgNB#2, and in step ST2613, SgNB#2 transmits the user data to the UE. The user data may be PDCP-PDUs for which delivery confirmation has not been obtained at the UE in the PDCP status report of step ST2609.

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

[0581] Embodiment 4 may be applied to mobility between DUs. This makes it possible to suppress the bandwidth compression of the CU-DU interface, for example, the Fs interface. Specifically, by replacing MgNB with CU and SgNB with DU, it is possible to implement the application to mobility between DUs.

[0582] Also, Embodiment 4 may be applied to the transmission and reception of C-Plane data. For example, Embodiment 4 may be applied to mobility between DUs of C-Plane data. The aforementioned C-Plane data may be, for example, NAS data. This makes it possible to ensure efficient transmission and reliability in mobility between DUs during C-Plane data transmission.

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

[0584] In step ST2701 shown in FIG. 41, the UE transmits a PDCP status report to DU#1. In step ST2702, DU#1 forwards 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. 39.

[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 be PDCP-PDUs for which the UE has not received a delivery confirmation, similar to steps ST2612 and ST2613 shown in FIG. 39.

[0586] According to Embodiment 4, it is possible to suppress the bandwidth compression of the base station interface and / or the CU-DU interface when mobility occurs.

[0587] According to Embodiment 4, for example, the following configuration is provided.

[0588] A communication system is provided, which includes a communication terminal device and a plurality of base station devices configured to be capable of wireless communication 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 communicating with the communication terminal device is changed from the first secondary base station device to the second secondary base station device, the master base station device acquires delivery information regarding the 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 the packets not indicated in the delivery information to the communication terminal device from the second secondary base station device or the master base station device.

[0589] Also, according to Embodiment 4, 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 capable of wireless communication with the communication terminal device. More specifically, the base station device includes a plurality of DUs (Distributed Units) that transmit and receive wireless signals, and a CU (Central Unit) that controls the plurality of DUs. The CU acquires delivery completion information regarding packets that have been delivered to the communication terminal device from a DU connected to the communication terminal device. The CU transmits packets not indicated in the delivery completion information to the communication terminal device from the aforementioned DU or another DU.

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

[0592] The above configuration can be variously modified based on the disclosure and suggestions of this specification including Embodiment 4. According to the above configuration and its modified configurations, the above problems can be solved and the above effects can be obtained.

[0593] Modification Example 1 of Embodiment 4. In this Modification Example 1, another method for solving the problems in Embodiment 4 is disclosed.

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

[0595] The source secondary base station may transfer RLC-PDUs for which delivery confirmation from the UE has not been received to the destination secondary base station via the master base station. The aforementioned transfer may be performed for downlink data. This makes it possible to reduce the transfer amount at the base station interface.

[0596] In the foregoing, the source secondary base station may transfer the RLC control PDU to the destination secondary base station via the master base station. As a result, at the destination secondary base station, regeneration of the RLC control PDU becomes unnecessary, so that the processing load at the destination secondary base station can be reduced.

[0597] The source secondary base station may transfer the RLC-PDU during the assembly process of the PDCP-PDU to the destination secondary base station via the master base station. The foregoing transfer may be performed for uplink data. As a result, even if the RLC-PDU is missing at the destination secondary base station, it is possible to suppress retransmission of the PDCP-PDU from the UE.

[0598] The source secondary base station may transfer the RLC state variable to the destination secondary base station via the master base station. The foregoing RLC state variable may be a variable described in Section 7.1 of Non-Patent Document 21 (3GPP TS 36.322 v14.0.0). As a result, it is possible to ensure the continuity of the RLC entity before and after mobility. Therefore, processing in the opposing UE becomes easier.

[0599] The source secondary base station may transfer the value of the timer used in the RLC entity to the destination secondary base station via the master base station. The foregoing value of the timer may be a value described in Section 7.3 of Non-Patent Document 21 (3GPP TS 36.322 v14.0.0). As a result, it is possible to maintain smooth operation of the RLC entity.

[0600] This Modification Example 1 may be applied to mobility between DUs. As a result, it is possible to suppress compression of the bandwidth of the CU-DU interface, for example, the Fs interface. Specifically, by replacing the MgNB with the CU and the SgNB with the DU, application to mobility between DUs can be implemented.

[0601] Further, the first modification example may be applied to the transmission and reception of C-Plane data. For example, the first modification example may be applied to the DU-to-DU mobility of C-Plane data. The aforementioned C-Plane data may be, for example, NAS data. This enables ensuring efficient transmission and reliability in the DU-to-DU mobility during C-Plane data transmission.

[0602] According to the first modification example, it is possible to suppress the bandwidth compression of the interface between base stations and / or the interface between the CU and the DU at the time of mobility occurrence.

[0603] Embodiment 5. As disclosed in Embodiment 1, in NR, a configuration for separating the CU and the DU is being considered. A plurality of DUs may be provided in the CU-DU separation configuration. In such a case, the problem is which part of the gNB, which is the CU-DU separation configuration of Option 2, performs the routing to the DU. Here, a method for routing the DU in the gNB will be disclosed.

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

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

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

[0607] Also, the inter-DU routing function may 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. As flow control, there are controls such as the start and stop of data transmission for controlling the data transmission timing, and the control of the data transmission speed.

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

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

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

[0611] In the inter-DU routing function, the routing destination DU may be determined and transmitted for each PDCP PDU. The routing destination DU may be determined and transmitted for every predetermined amount or number of PDCP PDUs. Also, the routing destination DU may be determined and transmitted at every predetermined time. Also, the routing destination DU may be determined and transmitted for each amount of PDCP PDUs in response to requests from each DU. By doing so, it becomes possible to adjust the amount of PDCP PDUs transmitted to each DU.

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

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

[0614] As a receiving-side function, data from each DU is routed to the upper-layer functions in the order of arrival. That is, data from each DU is sent to the upper-layer functions one by one in the order of arrival.

[0615] As another method, data from each DU may be routed to the upper-layer functions in the order of PDCP-SN (sequence number). That is, data from each DU is routed in the order of PDCP-SN and sent to the upper-layer functions one by one.

[0616] By doing so, it becomes possible to route data from each DU of the gNB to the upper-layer functions.

[0617] A buffer for the DU may be provided in the CU within the gNB. The buffer may be a buffer for communication on the CU-DU interface. By using the buffer for inter-DU routing or for routing to the upper-layer functions on the receiving side, data can be held in the buffer. Therefore, it is possible to reduce the state of data overflow and reduce data loss in cases where data communication between the UE and the DU is stalled.

[0618] The buffer may be provided for each DU. By having a buffer for each DU, it becomes possible to reduce the state of data overflow for each DU according to the data communication situation between the UE and each DU, and reduce data loss. Also, it is possible to reduce the state where data of other DUs overflows due to a stall in data communication of one of the DUs and reduce data loss.

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

[0620] A buffer may be provided for each DU within the gNB's DU. The buffer may be provided within the RLC. The buffer may also be used as a buffer for communication on the CU-DU interface. By using the buffer for receiving data routed from the CU or for transmitting data to the CU on the receiving side, data can be held in the buffer. This can reduce the state of data overflow and reduce data loss in cases where data communication between the UE and the DU is stalled or where functions in the CU or PDCP are stalled.

[0621] Information requesting downlink data from the RLC of each DU may be notified to the CU. This information may be notified from the RLC within each DU to the PDCP within the CU. Five examples are disclosed below as this information.

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

[0623] (2) Amount of data requested.

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

[0625] (4) Buffer margin within its own DU.

[0626] (5) Combination of (1) to (4).

[0627] The DU routing function within the CU can determine which DU to transmit data to in consideration of the information notified from each DU.

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

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

[0630] The PDCP in the CU determines to which DU the data determined for retransmission is to be routed again by the inter-DU routing function, and transmits the data to the determined routing destination DU. In this case, it may be possible to transmit not only to the DU that transmitted last time but also to any DU. By enabling transmission to a DU different from the DU that transmitted last time, it becomes possible to determine the routing destination DU in consideration of the communication status between the UE and the DU.

[0631] The packet duplication function and the duplicate packet detection and deletion function disclosed in Embodiment 1 may be configured in the CU of the gNB together with the inter-DU routing function. Those functions may also be functions of the PDCP in the CU. The gNB implements the packet duplication function, and the packets duplicated by the gNB using the inter-DU routing function can be routed between DUs.

[0632] For the function of determining the DU that transmits the duplicated packet, either the DU determination method in the packet duplication function disclosed in Embodiment 1 or the function of determining the routing destination DU of the inter-DU routing function may be applied.

[0633] When the DU itself or the UE determines the DU that communicates the duplicated packet, the function of determining the routing destination DU of the inter-DU routing function may be disabled. The function of determining the routing destination DU of the inter-DU routing function may be bypassed or made transparent. In the inter-DU routing function, the function of transmitting the duplicated packet may be enabled for the DU that communicates the duplicated packet determined by the DU itself or the UE.

[0634] By doing so, it becomes possible to configure a CU having both a packet duplication function and a DU - to - CU routing function.

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

[0636] According to Embodiment 5, for example, the following configuration is provided.

[0637] A communication system is provided, which includes a communication terminal device and a base station device configured to be capable of wireless communication with the communication terminal device. More specifically, the base station device includes a plurality of DUs (Distributed Units) that transmit and receive wireless 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 destined for the communication terminal device within or below PDCP (Packet Data Convergence Protocol).

[0638] Based on the disclosure and suggestion of this specification including Embodiment 5, the above configuration can be variously modified. According to the above configuration and its 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) as an NR technology is being studied.

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

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

[0642] Data for the SgNB is routed to the SgNB within the PDCP of the MgNB and then transmitted to the SgNB. The data transmitted to the SgNB will be input to the RLC within the SgNB.

[0643] When using the gNB with the CU-DU split configuration of Option 2 as the SgNB of the SB, the following problems occur.

[0644] Conventionally, when the SgNB is not in the CU-DU split configuration as in LTE, the MgNB only needed to transmit data to the SgNB. However, in NR, when the SgNB is in the CU-DU split configuration, it becomes unclear where the MgNB should send the data to the SgNB, that is, whether it should be sent to the CU or the DU.

[0645] Also, as described above, the SgNB does not use PDCP for UEs that perform 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 within the CU. Since there is no RLC within the CU, it becomes impossible to process. For this reason, the data transmission from the PDCP within the CU to the RLC within the DU described above becomes impossible.

[0646] Also, even if data is transmitted from the MgNB to the DU of the SgNB, it becomes unclear to which DU of which other gNB and by what method it should be transmitted.

[0647] Due to the above reasons, data transmission from the MgNB to the SgNB becomes impossible.

[0648] In the uplink, since it is the reverse transmission path, the description is omitted here, but similarly, data transmission from the SgNB to the MgNB becomes impossible.

[0649] For this reason, a problem occurs in that communication cannot be established between the UE communicating using the DU of the SgNB and the base station side.

[0650] In Embodiment 6, a method for solving such a problem is 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 for which routing is performed may be user data (U-plane data). Also, the data for which routing is performed may be control data (C-plane data). In that case, it can be applied when supporting control data in a split bearer.

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

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

[0654] (1) Provide an inter-DU routing function within the PDCP in the CU of the SgNB.

[0655] (2) Provide an inter-DU routing function outside the PDCP in the CU of the SgNB.

[0656] (3) Provide a protocol stack having an inter-DU routing function outside the PDCP in the CU of the SgNB.

[0657] Details of the above (1) are disclosed.

[0658] A DU - to - DU routing function is provided within 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 split bearer to the PDCP of the SgNB. In the CU of the SgNB, only the DU - to - DU routing function of the PDCP is operated. It may be sufficient to enable only this function. Also, other functions may not be operated. Other functions may be bypassed or made transparent. Data is output from the PDCP within the CU of the SgNB to each DU.

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

[0660] As a receiving - side function, data from each DU is routed to the MgNB in the order of arrival. That is, data from each DU is sent one by one to the MgNB in the order of arrival.

[0661] As another method, data from each DU may be routed to the MgNB in the order of PDCP - SN (sequence number). That is, data from each DU is routed in the order of PDCP - SN and sent one by one to the MgNB.

[0662] Figure 42 is a diagram showing an example of the architecture when a DU - to - DU routing function is provided in the PDCP of the SgNB. Figure 42 shows the case where both the MgNB and the SgNB have the CU - DU separation configuration of Option 2.

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

[0664] 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 the secondary gNB of the UE that performs DC, in the conventional configuration, the 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] A DU - to - DU routing function is provided in the PDCP within the CU of the SgNB. In the example of Figure 42, a DU - to - DU routing function is also provided in the PDCP within the CU of the MgNB.

[0666] For data communication between the MgNB and the SgNB, it is advisable to provide an interface between the CU of the MgNB and the CU of the SgNB. As this interface, a new interface may be provided, or alternatively, 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 targeted for split bearer to the PDCP of the SgNB. In the PDCP configured in the CU of the SgNB, only the DU - to - DU routing function operates. The data from the MgNB is output to each DU by the DU - to - DU routing function.

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

[0669] By adopting such a method, it becomes possible to reuse the existing protocol stack PDCP in the SgNB, so that the gNB can be easily configured. It becomes easier to use the gNB with the CU - DU separation configuration of Option 2 as the secondary for DC.

[0670] Note that the packet duplication function and the function of detecting and deleting duplicate packets disclosed in Embodiment 1 may be provided in the CU of the SgNB. The function may be provided within the PDCP configured in the CU. Packet duplication can be performed at the SgNB.

[0671] Further, the function may be configured in the CU of the SgNB together with the DU - to - DU routing function. Those functions may be functions of the PDCP within the CU. The gNB having both the packet duplication function and the DU - to - DU routing function in the PDCP within the CU disclosed in Embodiment 5 may be used as the SgNB. When using the gNB as the SgNB of the UE targeted for DC, it is advisable to enable the packet duplication function and the DU - to - DU routing function.

[0672] By doing so, it becomes possible to implement the packet duplication function, the function of detecting and deleting duplicate packets using a plurality of DUs in the SgNB. Also, the MgNB does not need to implement the packet duplication function using a plurality of DUs of the SgNB. Therefore, it is possible to prevent an increase in the data traffic volume between the MgNB and the SgNB.

[0673] Details of the above - mentioned (2) will be disclosed.

[0674] A DU - to - DU routing function is provided outside the 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 will be disclosed. Data is input from the MgNB of the UE targeted for split bearer to the CU of the SgNB. In the CU of the SgNB, only the DU - to - DU routing function is operated. It may be sufficient to enable only this function. Also, 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 receiving-side function, the method disclosed in the above (1) may be applied.

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

[0678] The MgNB is composed 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 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 the secondary gNB of 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 FIG. 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 above, the inter-DU routing function was provided inside the PDCP of the MgNB, but here, the inter-DU routing function may be provided outside the PDCP of the MgNB.

[0682] Similar to the case of (1) described above, an interface may be provided 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 targeted for split bearer to the DU - to - DU routing function provided outside the PDCP in the CU of the SgNB. The input data is output to each DU by the DU - to - DU routing function.

[0684] Regarding the receiving side, in the DU - to - DU routing function provided outside the PDCP in the CU of the SgNB, data from each DU is routed to the MgNB. 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 split bearer, the SgNB can be configured without using PDCP, similar to the conventional split bearer. Therefore, it becomes easier to expand the functions in the SgNB.

[0686] Also, when the DU - to - DU routing function is possessed by the RRC of the SgNB, the DU - to - DU routing function can be realized only by adding functions to the RRC, so it becomes possible to easily configure the gNB. Further, when the DU - to - DU routing function is possessed by the RRC of the SgNB, routing in a plurality of bearers can be performed collectively, so the processing amount can be reduced.

[0687] Note that the packet duplication function, the function of detecting and deleting duplicate packets disclosed in Embodiment 1 may be provided in the CU of the SgNB. This function may be provided outside the PDCP configured in the CU. Packet duplication can be implemented in the SgNB.

[0688] Alternatively, the function may be configured in the CU of the SgNB together with the DU - to - DU routing function. These functions may also be functions outside the PDCP within the CU. A gNB having both a packet duplication function and a DU - to - DU routing function outside the PDCP within the CU may be used as the SgNB. When using the gNB as the SgNB for a DC - target UE, it is advisable to enable the packet duplication function and the DU - to - DU routing function.

[0689] By doing so, it becomes possible to implement a packet duplication function using multiple DUs in the SgNB, a function for detecting and deleting duplicate packets. Also, the MgNB does not need to implement the packet duplication function using multiple DUs in the SgNB. Therefore, it becomes possible to prevent an increase in the data traffic between the MgNB and the SgNB.

[0690] Details of the above - mentioned (3) are disclosed.

[0691] A protocol stack (sometimes referred to as RP) having a DU - to - DU routing function is provided outside the PDCP within the CU of the SgNB. It is advisable to provide the RP separately from the PDCP. The RP may also be provided below the PDCP. The DU - to - DU routing in the SgNB is performed by the RP.

[0692] Regarding the data transfer between the MgNB and the SgNB, data is input from the MgNB of a UE targeted for split bearer to the CU of the SgNB. It is advisable to input the data to the RP within the CU of the SgNB. The DU - to - DU routing of the data is performed by the DU - to - DU routing function provided in the RP, and the data is output to each DU.

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

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

[0695] FIG. 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. FIG. 44 shows the case of the CU-DU separation configuration of Option 2 for both the MgNB and the SgNB.

[0696] The MgNB is composed 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 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, 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 FIG. 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 the RP may be provided with an inter-DU routing function. In the example of FIG. 43 described above, the inter-DU routing function was provided outside the PDCP of the MgNB, but here, an RP may be provided outside the PDCP of the MgNB, and the RP may be provided with an inter-DU routing function.

[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 inter-DU routing function for the MgNB and the inter-DU routing function for the SgNB may be shared to make the RP a gNB common protocol stack. For example, it may be assumed that data is input from the PDCP to the RP on the transmission side and data is transmitted from the RP to the PDCP on the reception side.

[0701] The MgNB performs data transmission and reception between the PDCP and the RP within its own gNB. The SgNB performs data transmission and reception between the PDCP of the MgNB and the RP of its own gNB.

[0702] Even for the same gNB, it can be the MgNB for one UE and the SgNB for another UE. Therefore, by providing a gNB-common RP, DU-interworking routing can be executed regardless of whether it is used as either gNB.

[0703] Similar to the case of (1) described above, an interface may be provided 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 targeted for split bearer to the RP provided outside the PDCP in the CU of the SgNB. The input data is output to each DU by the DU-interworking routing function.

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

[0706] By providing a protocol stack having such a DC-interworking routing function in this way, it becomes possible to configure the gNB without affecting other protocol stacks within the gNB. For this reason, the SgNB can be easily configured.

[0707] Also, by using a gNB-common RP, there is no need to perform different designs, implementations, or settings for the MgNB and the SgNB, and it becomes possible to avoid complexity.

[0708] Note that the packet duplication function and the duplicate packet detection and deletion function disclosed in Embodiment 1 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 the packet duplication function and the duplicate packet detection and deletion function in the RP common to the gNBs, it is not necessary to perform different designs, implementations, or settings for the MgNB and the SgNB, and it is possible to avoid complexity.

[0710] Note that the packet duplication function and the duplicate packet detection and deletion function disclosed in Embodiment 1 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, the function may be configured in the CU of the SgNB together with the DU - to - DU routing function. Those functions may be functions in the RP of the CU. A gNB having both the packet duplication function and the DU - to - DU routing function in the RP of the CU may be used as the SgNB. When using the gNB as the SgNB for the UE targeted for DC, it is advisable to enable the packet duplication function and the DU - to - DU routing function.

[0712] By doing so, it is possible to implement the packet duplication function, the duplicate packet detection, and deletion function using multiple DUs in the SgNB. In addition, the MgNB does not need to implement the packet duplication function using multiple DUs of the SgNB. Therefore, it is possible to prevent an increase in the data traffic between the MgNB and the SgNB.

[0713] A buffer for the DU may be provided in the CU within the gNB. Also, a buffer may be provided for each DU in the DU of the gNB. The method disclosed in Embodiment 5 may be applied to obtain a similar effect.

[0714] Further, each DU may notify the CU of information requesting downlink data, information related to RLC retransmission control, and information related to MAC retransmission control. The method disclosed in Embodiment 5 may be applied. The same effect can be obtained.

[0715] Also, in Embodiment 5, it is disclosed that the PDCP in the CU determines to which DU the data determined to be retransmitted is to be routed again by the DU - to - DU routing function, and transmits the data to the determined routing - destination DU. In this Embodiment 6, the same CU or the protocol stack within the CU that provides the DU - to - DU routing function may perform these processes. The same effect can be obtained.

[0716] The SgNB may notify the MgNB of information indicating the presence or absence of the CU - DU separation configuration of the own SgNB.

[0717] Further, the SgNB may notify the MgNB of information related to the DU - to - DU routing function of the own SgNB. As information related to the DU - to - DU routing function, there is configuration information such as the presence or absence of the DU - to - DU routing function and where to provide the DU - to - DU routing function.

[0718] The SgNB may notify the MgNB of this information at the time of DC configuration. For example, when SgNB addition is performed, the SgNB may notify the MgNB of this information. The SgNB may notify the MgNB of this information by including this information in the signaling that notifies the response to the request for SgNB addition.

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

[0720] By notifying the MgNB of information indicating the presence or absence of the CU-DU separation configuration and information related to the DU-to-DU routing function from the SgNB in this way, the MgNB can recognize them. The MgNB may perform SB routing considering them.

[0721] Also, instead of at the time of DC setting, for example, at the time of setting up the interface between gNBs, the aforementioned information may be notified between gNBs. By including information indicating the presence or absence of the CU-DU separation configuration of its own gNB and information related to DU-to-DU routing in the setup message, the information may be notified to other gNBs.

[0722] Alternatively, at the time of updating the gNB setting, the aforementioned information may be notified. By including information indicating the presence or absence of the CU-DU separation configuration of its own gNB and information related to DU-to-DU routing in the gNB setting update message, the information may be notified to other gNBs.

[0723] The aforementioned other gNB may be a neighboring gNB.

[0724] By notifying the aforementioned information at the time of setup or at the time of updating the gNB setting in this way, it becomes possible to consider the configuration of neighboring gNBs not only in DC but also in other services.

[0725] Disclose the information notified between the MgNB and the SgNB. The information may be the information notified between the MgNB and the SgNB at the time of SB in LTE. The information may be the information notified on X2-U (Non-Patent Document 23: TS36.425).

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

[0727] As information to be notified from SgNB to MgNB, there is information on the transmission status of DL data. The information on the transmission status of DL data is, for example, the highest PDCP-SN successfully transmitted to the UE. SgNB may notify, as information on the transmission status of DL data, the PDCP-SN that has been successfully transmitted to the UE within a predetermined period. SgNB may notify, as information on the transmission status of DL data, the PDCP-SN that has failed to be transmitted to the UE within a predetermined period. SgNB may notify together the first PDCP-SN to be notified and the PDCP-SN that has been successfully transmitted or has failed to be transmitted within a predetermined period. The PDCP-SN that has been successfully transmitted or has failed to be transmitted within a predetermined period may be notified as bitmap information. The number of bits required for notification can be reduced.

[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 to the RLC within the DU. SgNB may notify, as information on the transmission status of DL data, the PDCP-SN that has been successfully transmitted from the CU to the DU or to the RLC within the DU within a predetermined period. SgNB may notify, as information on the transmission status of DL data, the PDCP-SN that has failed to be transmitted from the CU to the DU or to the RLC within the DU within a predetermined period. SgNB may notify together the first PDCP-SN to be notified and the PDCP-SN that has been successfully transmitted or has failed to be transmitted within a predetermined period. The PDCP-SN that has been successfully transmitted or has failed to be transmitted within a 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 that has been successfully transmitted to the UE by the DU or the RLC within the DU. The SgNB may notify, as the information on the transmission status of DL data, the PDCP-SN that has been successfully transmitted to the UE by the DU or the RLC within the DU during a predetermined period. The SgNB may notify, as the information on the transmission status of DL data, the PDCP-SN that has failed to be transmitted to the UE by the DU or the RLC within the DU during a predetermined period. The SgNB may notify the first PDCP-SN to be notified and the PDCP-SN that has been successfully or unsuccessfully transmitted during a predetermined period together. The PDCP-SN that has been successfully or unsuccessfully transmitted during a predetermined period may be notified as bitmap information. The number of bits required for the notification can be reduced.

[0730] The information on the highest PDCP-SN that has been successfully transmitted to the UE by the DU or the RLC within the DU, the information on the PDCP-SN that has been successfully transmitted to the UE by the DU or the RLC within the DU during a predetermined period, and the information on the PDCP-SN that has failed to be transmitted to the UE by the DU or the RLC within the DU during a predetermined period may be notified from the DU to the CU. Alternatively, these information may be notified from the RLC within the DU to the PDCP within the CU. The CU within the SgNB can notify these information to the MgNB.

[0731] As the information to be notified from the SgNB to the MgNB, there is buffer size information. For example, information on the desired buffer size for the bearer targeted for SB, information on the minimum desired buffer size for the UE targeted for SB, and the like.

[0732] As information to be notified from the SgNB to the MgNB, there is information regarding data lost in the data communication between the MgNB and the SgNB. The information regarding the lost data is, for example, the sequence number assigned on the interface between the MgNB and the SgNB for the lost data. As another example of the information regarding the lost data, there are the sequence number assigned on the interface between the MgNB and the SgNB for the first lost data and the sequence number assigned on the interface between the MgNB and the SgNB for the last lost data. Also, the number of sets of these consecutive lost data may be notified.

[0733] By doing so, even if data is transmitted from the MgNB to the PDCP in the CU of the SgNB, it becomes possible to appropriately and efficiently perform the data transmission.

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

[0735] The SgNB has a CU-DU separation configuration of Option 2, and two DUs (DU#1, DU#2) are connected to one CU. The MgNB is also in the case of the CU-DU separation 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-layer NW device and the MgNB CU.

[0737] In step ST6802, the MgNB CU performs routing between DUs. For example, if the inter-DU routing function is configured in the PDCP, the PDCP performs inter-DU routing. In inter-DU routing, the destination DU for routing is determined, and data is transmitted to the determined destination DU for routing.

[0738] In step ST6803, the MgNB CU transmits the data determined to be routed 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 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] For transmissions from the UE, the reverse operation is performed. In step ST6804, data is transmitted from the UE to the MgNB DU#1. The data received by the MgNB DU#1 is processed by PHY, MAC, and RLC in step ST6803 and transmitted to the MgNB CU. Similarly, in steps ST6805 and ST6806, data is transmitted from the UE to the MgNB CU via the MgNB DU#2. In step ST6802, the MgNB CU performs receiving-side DU - to - DU routing. For example, the MgNB CU transmits the data from the MgNB DU#1 and the data from the MgNB DU#2 to the upper - layer function in the order of arrival. The data from the UE is processed by PDCP in the MgNB CU, processed by the New AS Layer, and transmitted to the upper - layer NW device in step ST6801.

[0741] This enables communication between the UE and the upper - layer NW device even when the MgNB is composed of multiple DUs.

[0742] Next, the case where DC of the SB is performed will be described. In step ST6807, the MgNB determines to perform DC on the UE.

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

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

[0745] In step ST6810, the SgNB CU notifies the MgNB CU of an SgNB addition request response message. This message is notified including the DU to be used for DC determined in step ST6809.

[0746] The MgNB CU that receives the SgNB addition request response message notifies the UE performing DC of the DC configuration in step ST6811. At this time, information regarding the DU of the SgNB to be used for DC may be notified. For example, identifiers of DU#1 and DU#2, resources and sequence information used for initial access (e.g., random access), etc.

[0747] An RRC connection reconfiguration message may be used for this notification. By doing so, the UE can identify which DU of the SgNB to perform DC with, and access to the DU performing DC becomes possible.

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

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

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

[0751] In steps ST6814 and ST6815, the UE performs random access (RA) processing with DU#1 and DU#2 of the SgNB that performs DC. As a result, access becomes possible between the UE and DU#1 and DU#2 of the SgNB that performs DC.

[0752] In step ST6816, the MgNB CU routes data transmitted from the upper-layer 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] Regarding the data routed to the MgNB, inter-DU routing is performed in step ST6827. The data determined by the MgNB CU to be routed to MgNB DU#1 through 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 determined by the MgNB CU to be routed to 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] Regarding the 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 determined by the SgNB CU to be routed to SgNB DU#1 through 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] Through the DU - to - DU routing in step ST6822, the data determined by the SgNB CU to be routed to SgNB DU#2 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] For the transmission from the UE, the reverse operation is performed. Since the operation on the MgNB side is the same as the method disclosed from step ST6802 to step ST6806, it is omitted.

[0759] Disclose for the SgNB.

[0760] In step ST6824, data is transmitted from the UE to SgNB DU#1. The data received by the SgNB DU#1 is processed by the PHY, MAC, and RLC, and is transmitted to the SgNB CU in step ST6823. 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 the receiving - side DU - to - DU routing. For example, the data from the SgNB DU#1 and the data from the SgNB DU#2 are transmitted to the MgNB in the order of arrival. The 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 the PDCP, processed by the New AS Layer, and transmitted to the upper - level NW device.

[0762] In the communication between the MgNB CU and the SgNB CU in step ST6821, the information notified between the MgNB and the SgNB as described above may be notified.

[0763] By doing so, it becomes possible to execute the DC of the SB using the gNB with the CU - DU split configuration of option 2 as the secondary.

[0764] By adopting the method disclosed in Embodiment 6, when the gNB with the CU-DU separation configuration of Option 2 is used as the SgNB of the DC of the SB, data transfer from the MgNB to the SgNB is enabled. Also, inter-DU routing is enabled within the CU of the SgNB.

[0765] Therefore, communication using the gNB with the CU-DU separation configuration of Option 2 as the SgNB of the DC of the SB is enabled.

[0766] Also, by applying the method disclosed in Embodiment 6 to the MgNB, inter-DU routing within the MgNB is enabled.

[0767] Therefore, communication using the gNB with the CU-DU separation configuration of Option 2 as the MgNB of the DC of the SB is enabled.

[0768] In the example disclosed above, the configuration method of the inter-DU routing function is made the same for the MgNB and the SgNB. By doing so, an inter-DU routing function common to the gNBs can be provided, making it possible to simplify the configuration of the gNB.

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

[0770] Also, when the gNB has a plurality of configurations of the inter-DU routing function, the configuration of the inter-DU routing function may be changed quasi-statically or dynamically. The gNB may notify other gNBs or the gNB performing the DC of the configuration information of the inter-DU routing function of its own gNB as information regarding the inter-DU routing function.

[0771] By doing so, it becomes possible to change the DU - to - DU routing function according to the configuration of each gNB and the load situation at each gNB. It becomes possible to appropriately reduce the processing load of DU - to - DU routing in the gNB.

[0772] According to Embodiment 6, for example, the following configuration is provided.

[0773] A communication system is provided, which includes a communication terminal device and a plurality of base station devices configured to be capable of wireless communication 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. The master base station device and the secondary base station device each include a plurality of DUs (Distributed Units) that transmit and receive wireless signals to and from the communication terminal device, and a CU (Central Unit) that controls the plurality of DUs. The master base station device receives downlink data destined for the communication terminal device from a network device higher than the master base station device. The master base station performs routing of 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 the 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 the downlink data routed to the secondary base station device to the determined routing destination DU.

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

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

[0777] Based on the disclosure and suggestion of this specification including Embodiment 6, the above configuration can be variously modified. According to the above configuration and its modified configurations, the above problems can be solved and the above effects can be obtained.

[0778] Modification Example 1 of Embodiment 6. In this Modification Example 1, another method for solving the problems described in Embodiment 6, specifically, the problems in the case of using the gNB with the CU-DU separation configuration of Option 2 as the SgNB of the SB, is disclosed.

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

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

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

[0782] Regarding the method of configuring the function of determining the routing destination DU of the SgNB within the MgNB, three examples are disclosed below.

[0783] (1) Provide a function of determining the routing destination DU within the PDCP.

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

[0785] (3) Provide a protocol stack having a function of determining the routing destination DU outside the PDCP.

[0786] Regarding the method of configuring the function of transmitting data from the MgNB to the routing destination DU within the CU of the SgNB, three examples are disclosed below.

[0787] (1) Provide a function of transmitting data to the routing destination DU within the PDCP within the CU within the SgNB.

[0788] (2) Provide a function of transmitting data to the routing destination DU outside the PDCP within the CU within the SgNB.

[0789] (3) Provide a protocol stack having a function of transmitting data to the routing destination DU outside the PDCP within the CU within the SgNB.

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

[0791] When the gNB becomes the MgNB, configure the DU - to - DU routing function for the SgNB. Among the DU - to - DU routing functions of the SgNB, enable the function of determining the routing destination DU and disable the function of sending data to the routing destination DU. As another example, when the gNB becomes the MgNB, among the DU - to - DU routing functions of the SgNB, other functions that are not the function of determining the routing destination DU may be bypassed or made transparent. By doing so, when the gNB becomes the MgNB, it becomes possible to implement the function of determining the routing destination DU of the SgNB in the MgNB.

[0792] When the MgNB is in the CU - DU split configuration of Option 2, the DU - to - DU routing function may be configured for the MgNB. It becomes possible to implement the DU - to - DU routing function of its own gNB in the MgNB.

[0793] When the gNB becomes the SgNB, disable the function of determining the routing destination DU among the DU - to - DU routing functions and enable the function of sending data to the routing destination DU. As another example, when the gNB becomes the SgNB, among the DU - to - DU routing functions, other functions that are not the function of sending data to the routing destination DU may be bypassed or made transparent. By doing so, when the gNB becomes the SgNB, it becomes possible to implement the function of sending data to the routing destination DU in the SgNB.

[0794] For the data sent to the SgNB, the MgNB determines the routing destination DU of the SgNB by implementing the function of determining the routing destination DU of the SgNB, and sends the transmission data to the SgNB. The SgNB can send the data sent from the MgNB to each DU by implementing the function of sending data to the routing destination DU.

[0795] On the receiving side, the SgNB is provided with a function 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. Alternatively, the function of routing data from each DU to the MgNB may be one of the functions of transmitting data to the destination DU for routing. As a receiving-side function, data from each DU is routed to the MgNB in the order of arrival. That is, data from each DU is sent to the MgNB one by one in the order of arrival.

[0796] As another method, data from each DU may be routed to the MgNB in the order of PDCP-SN (sequence number). That is, 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 to transmit data sent from the SgNB to a higher-layer function. At this time, the MgNB may delete information not required by the higher-layer function and transmit the data after the deletion to the higher-layer function. The function of transmitting data sent from the SgNB to a higher-layer function may be one of the inter-DU routing functions. Alternatively, the function of transmitting data sent from the SgNB to a higher-layer function may be one of the functions of determining the destination DU for routing.

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

[0799] Regarding the aforementioned configuration methods (1) to (3) of the function of determining the destination DU for routing and the aforementioned configuration methods (1) to (3) of the function of transmitting data to the destination DU for routing, the configuration method of the inter-DU routing function disclosed in Embodiment 6 may be appropriately applied.

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

[0801] MgNB is composed 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] 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 SgNB. RLC, MAC, and PHY are configured in the DU. Since SgNB is the secondary gNB of the UE that performs DC, in the conventional configuration, New AS Layer and PDCP are not configured in the CU. However, in Modification Example 1 of Embodiment 6, PDCP is provided in the CU.

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

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

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

[0806] As a result, the SgNB can send the data transmitted from the MgNB to the DU determined by the MgNB as the routing destination.

[0807] The interface for data communication between the MgNB and the SgNB may apply the interface disclosed in Embodiment 6.

[0808] On the receiving side, in the function of routing the data from each DU to the MgNB, which is a function provided in the PDCP configured in the CU of the SgNB, the data from each DU is routed to the MgNB. For example, the SgNB routes and transmits the data from each DU to the MgNB in the order of arrival.

[0809] In the MgNB, in the function of transmitting the data transmitted from the SgNB to the upper-layer function, which is a function configured in the MgNB, the data from the SgNB is transmitted to the upper-layer function.

[0810] By adopting such a method, it becomes possible to reuse the PDCP, which is an existing protocol stack, in the SgNB, and thus it becomes possible to easily configure the gNB. It becomes easier to use the gNB with the CU-DU separation configuration of Option 2 as the secondary of the DC.

[0811] Between gNBs, information indicating the presence or absence of the CU-DU separation configuration of its own gNB may be notified.

[0812] Between gNBs, the information of the DU of its own gNB may be notified. As the DU information, the information of the DU connected to the CU of its own gNB may be notified. As the DU information, the information of each DU and the information of the CU to which the DU is connected may be associated and notified.

[0813] In this first modification example, unlike the method disclosed in the sixth embodiment, MgNB has a function of determining the routing destination DU of SgNB. 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 regarding the DU. MgNB can determine the SgNB routing destination DU in consideration of this information.

[0814] The information of the DU may be a DU identifier.

[0815] The DU identifier may be associated with the identifier of the gNB or the cell. Also, the information of the DU may be the 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. By associating with the identifier of the gNB or the cell in this way, it becomes possible to recognize which gNB constitutes the DU.

[0817] The information of the DU notified between gNBs may be limited to that regarding the DU that can be used for sending and receiving data from other gNBs. For example, the information of the DU notified between gNBs may be limited to the information regarding the DU that can be used for DC. By doing so, it becomes possible to reduce the amount of information notified between gNBs.

[0818] The information of the CU to which the DU is connected may be a CU identifier. The same method as the aforementioned DU identifier may be applied.

[0819] The information indicating the presence or absence of the CU-DU separation configuration and the information of the DU may be notified between gNBs at the time of setting up the interface between gNBs. By including the information indicating the presence or absence of the CU-DU separation configuration of the own gNB and the information of the DU in the setup message, this information may be notified to other gNBs.

[0820] Alternatively, when updating the gNB configuration, the foregoing information may be notified. By including information indicating the presence or absence of the CU-DU separation configuration of the local gNB and DU information in the gNB configuration update message, this information may be notified to other gNBs.

[0821] The foregoing other gNBs may be neighboring gNBs.

[0822] By notifying the foregoing information at the time of setup or when updating the gNB configuration in this way, at the time of DC configuration, the MgNB can recognize the DU configuration of the gNB used as secondary. Therefore, the MgNB can determine the routing destination DU of the SgNB.

[0823] Information indicating the presence or absence of the DU separation configuration of the local gNB and DU information of the local gNB may be notified at the time of DC configuration. The method of notifying information indicating the presence or absence of the CU-DU separation configuration of the local SgNB from the SgNB to the MgNB at the time of DC configuration disclosed in Embodiment 6 may be applied.

[0824] At the time of DC configuration, the MgNB may notify the SgNB of information requesting the SgNB to use the DU of the SgNB for DC. This information may include the number of DUs to be used in DC.

[0825] For example, when SgNB addition is performed, the MgNB may notify the SgNB of the foregoing request. The foregoing request may be included in the signaling of SgNB addition requested by the MgNB to the SgNB.

[0826] Alternatively, when SgNB modification is performed, the MgNB may notify the SgNB of the foregoing request. The foregoing request may be included in the signaling of SgNB modification requested by the MgNB to the SgNB.

[0827] By doing so, the number of DUs required by MgNB for DC can be recognized by SgNB. SgNB can prevent setting an excessive number of DUs for DC. Also, SgNB can prevent setting an insufficient number of DUs for DC.

[0828] When setting DC, SgNB may notify MgNB of information regarding the DUs available for DC in SgNB. Examples of information regarding DUs include the identifier of the DU, information on the number of available DUs, etc.

[0829] For example, when SgNB addition is performed, SgNB may notify MgNB of the aforementioned information. The aforementioned information may be included in the signaling that notifies the response to the SgNB addition request.

[0830] Alternatively, when SgNB modification is performed, SgNB may notify MgNB of the aforementioned information. The aforementioned information may be included in the signaling that notifies the response to the SgNB modification request.

[0831] By doing so, SgNB can notify MgNB of the number of DUs available for DC according to the resources and load status of its own gNB. Since MgNB can recognize the number of SgNB DUs available for DC, it can appropriately perform routing to each gNB for SB.

[0832] Disclose the buffer configuration of SgNB and the information notified between MgNB and SgNB.

[0833] Provide one buffer for routing in the CU of the SgNB. This...

Claims

1. A user device; A plurality of base stations including a master base station and a secondary base station configuring dual connectivity, Each of the plurality of base stations one or more distributed units (DUs) capable of wirelessly communicating with the user equipment; a central unit (CU) connected to the DU; The master base station notifies the secondary base station of a sequence number in an interface between the master base station and the secondary base station. Communication systems.

2. The master base station determines the DU of the secondary base station to be a routing destination; The CU of the secondary base station transmits data to the DU that is the routing destination. The communication system according to claim 1 .

3. The secondary base station transmits status information regarding a transmission status of the downlink data to the master base station. The communication system according to claim 1 .

4. The status information indicates the highest sequence number among the successfully transmitted PDCP sequence numbers. The communication system according to claim 3.

5. The DU transmits status information regarding the transmission status of downlink data to the CU. The communication system according to claim 1 .

6. The status information indicates the highest sequence number among the successfully transmitted PDCP sequence numbers.

6. The communication system according to claim 5.

7. The CU of the secondary base station notifies the master base station of the received status information.

6. The communication system according to claim 5.

8. The secondary base station notifies the master base station of information regarding DUs available for the dual connectivity. The communication system according to claim 1 .

9. In the dual connectivity, a split bearer is set from the secondary base station to the master base station and the secondary base station. A communication system according to any one of claims 1 to 8.

10. One base station among the plurality of base stations transmits configuration information regarding the DU included in the one base station to another base station among the plurality of base stations. The communication system according to claim 1 .

11. The configuration information indicates at least one of a DU identifier indicating the DU, a base station identifier of the one base station including the DU, and a cell identifier of a cell corresponding to the one base station. The communication system according to claim 10.

12. A user device; A user equipment in a communication system including a master base station and a secondary base station configuring dual connectivity, Each of the plurality of base stations includes one or more distributed units (DUs) capable of wirelessly communicating with the user equipment and a central unit (CU) connected to the DUs; A sequence number in an interface between the master base station and the secondary base station is notified to the secondary base station. The sequence number is transmitted to the master base station via wireless communication. User equipment.

13. A user device; A base station in a communication system including a master base station and a secondary base station configuring dual connectivity, one or more distributed units (DUs) capable of wirelessly communicating with the user equipment; a central unit (CU) connected to the DU; The master base station notifies the secondary base station of a sequence number in an interface between the master base station and the secondary base station. Base station.

Images