Communication systems, central units and user equipment

Abstract

In cases where a cell is spatially separated by multiple wireless beams, radio resource management can be simplified. A cell (811) comprised of a base station device (800) is spatially separated by multiple wireless beams (804-810) belonging to the base station device (800). The base station device (800) shares the RRC (Radio Resource Control) parameters used by the communication terminal device in two or more of these multiple wireless beams (804-810).

Description

[0001] This application is a divisional application of the invention patent application entitled "Communication System", with an international filing date of December 28, 2017 and application number 201780079241.1 (international application number PCT / JP2017 / 047155). Technical Field

[0002] This invention relates to a communication system for wireless communication between a communication terminal device, such as a mobile terminal device, and a base station device. Background Technology

[0003] Within the 3GPP (3rd Generation Partnership Project), the standardization organization for mobile communication systems, a communication method known as Long Term Evolution (LTE) in terms of the radio domain and System Architecture Evolution (SAE) in terms of the overall system architecture including the core network and the radio access network (hereinafter collectively referred to as the network) has been studied (e.g., Non-Patent Documents 1-5). This communication method is also referred to as a 3.9G (3.9 Generation) system.

[0004] As an access method for LTE, the downlink uses OFDM (Orthogonal Frequency Division Multiplexing), and the uplink uses SC-FDMA (Single Carrier Frequency Division Multiple Access). Furthermore, unlike W-CDMA (Wideband Code Division Multiple Access), LTE does not include line switching; it is solely a packet communication method.

[0005] use Figure 1 Explain the decisions made in 3GPP concerning the frame structure of the LTE system as described in Non-Patent Document 1 (Chapter 5). Figure 1 This is an explanatory diagram showing the structure of the radio frame used in an LTE communication system. Figure 1In this system, a radio frame is 10ms long. A radio frame is divided into 10 equal-sized subframes. Each subframe is further divided into two equal-sized slots. The first and sixth subframes of each radio frame contain downlink synchronization signals. These synchronization signals consist of a primary synchronization signal (P-SS) and a secondary synchronization signal (S-SS).

[0006] Non-Patent Document 1 (Chapter 5) describes the decisions made by 3GPP regarding channel structure in LTE systems. It is assumed that CSG (Closed Subscriber Group) cells also use the same channel structure as non-CSG cells.

[0007] The Physical Broadcast Channel (PBCH) is a downlink transmission channel from a base station (hereinafter sometimes referred to as "base station") to a mobile terminal device (hereinafter sometimes referred to as "mobile terminal") or other communication terminal device (hereinafter sometimes referred to as "communication terminal"). A BCH transport block is mapped to four subframes in a 40ms interval. There is no clear signaling at 40ms intervals.

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

[0009] The Physical Downlink Control Channel (PDCCH) is the downlink transmission channel from the base station to the communication terminal. The PDCCH notifies the recipients of resource allocation information for the Downlink Shared Channel (DL-SCH), one of the transport channels described later; resource allocation information for the Paging Channel (PCH), another transport channel described later; and HARQ (Hybrid Automatic Repeat reQuest) information related to the DL-SCH. The PDCCH transmits uplink scheduling grants. It also transmits response signals for uplink transmissions, namely Ack (Acknowledgement) and Nack (Negative Acknowledgement). The PDCCH is also known as the L1 / L2 control signal.

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

[0011] The Physical Multicast Channel (PMCH) is a downlink transmission channel from the base station to the communication terminal. The PMCH maps to the Multicast Channel (MCH), which serves as the transmission channel.

[0012] The Physical Uplink Control Channel (PUCCH) is the uplink transmission channel from the communication terminal to the base station. The PUCCH transmits response signals (ACK / Nack) for downlink transmissions. It also transmits CQI (Channel Quality Indicator) reports, which indicate the quality of received data or the quality of the communication line. The PUCCH also transmits scheduling requests (SRs).

[0013] The Physical Uplink Shared Channel (PUSCH) is the uplink transmission channel from the communication terminal to the base station. The PUSCH maps to the Uplink Shared Channel (UL-SCH), which is one of the transmission channels.

[0014] The Physical Hybrid ARQ Indicator Channel (PHICH) is the downlink transmission channel from the base station to the communication terminal. PHICH transmits the Ack / Nack response signals sent in response to the uplink transmission. The Physical Random Access Channel (PRACH) is the uplink transmission channel from the communication terminal to the base station. PRACH transmits the random access preamble.

[0015] Downlink reference signals (RS) are known symbols in LTE communication systems. Five types of downlink reference signals are defined: Cell-specific Reference Signal (CRS), MBSFN reference signal, UE-specific reference signal (also known as Demodulation Reference Signal: DM-RS), Positioning Reference Signal (PRS), and Channel-State Information Reference Signal (CSI-RS). As a physical layer measurement for communication terminals, the received power (RSRP) of the reference signal is measured.

[0016] This describes the transport channel as described in Non-Patent Document 1 (Chapter 5). In the downlink transport channel, the broadcast channel (BCH) is broadcast to the entire coverage area of ​​its base station (cell). The BCH is mapped to the Physical Broadcast Channel (PBCH).

[0017] The Downlink Shared Channel (DL-SCH) utilizes HARQ (Hybrid ARQ) for retransmission control. DL-SCH can broadcast across the entire coverage area of ​​a base station (cell). DL-SCH supports dynamic or semi-static resource allocation. Semi-static resource allocation is also known as persistent scheduling. DL-SCH supports discontinuous reception (DRX) of communication terminals to reduce power consumption. DL-SCH is mapped to the Physical Downlink Shared Channel (PDSCH).

[0018] The Paging Channel (PCH) supports DRX (Demand Reduction) of communication terminals to reduce power consumption. The PCH is required to broadcast over the entire coverage area of ​​the base station (cell). The PCH is mapped to physical resources such as the Physical Downlink Shared Channel (PDSCH) that can be dynamically utilized for traffic.

[0019] The Multicast Channel (MCH) is used to broadcast to the entire coverage area of ​​a 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 quasi-static resource allocation. The MCH is mapped to the PMCH.

[0020] Retransmission control using HARQ (Hybrid ARQ) is applied to the Uplink Shared Channel (UL-SCH) in the uplink transport channel. UL-SCH supports dynamic or semi-static resource allocation. UL-SCH is mapped to the Physical Uplink Shared Channel (PUSCH).

[0021] The Random Access Channel (RACH) is restricted by control information. RACH is subject to collision risks. RACH is mapped to the Physical Random Access Channel (PRACH).

[0022] HARQ is explained below. HARQ is a technique that improves the communication quality of a transmission line by combining Automatic Repeat Request (ARQ) and Forward Error Correction. HARQ has the following advantages: even for transmission lines where communication quality changes, retransmission can effectively enable error correction. In particular, during retransmission, the quality can be further improved by combining the initial received result with the retransmitted result.

[0023] Here's an example illustrating the retransmission method. When the receiving side cannot correctly decode the received data—in other words, when a CRC (Cyclic Redundancy Check) error occurs (CRC = NG)—a "Nack" is sent from the receiving side to the sending side. The sending side, receiving the "Nack," retransmits the data. When the receiving side can correctly decode the received data—in other words, when no CRC error occurs (CRC = OK)—a "ck" is sent from the receiving side to the sending side. The sending side, receiving the "Ack," transmits the next data.

[0024] This section explains the logical channel described in Non-Patent Document 1 (Chapter 6). The Broadcast Control Channel (BCCH) is a downlink channel used for broadcasting system control information. The BCCH, as a logical channel, is mapped to either the Broadcast Channel (BCH) as a transmission channel or the Downlink Shared Channel (DL-SCH).

[0025] The Paging Control Channel (PCCH) is a downlink channel used to transmit paging information and system information updates. The PCCH is used when the network is unaware of the cell location of the communicating terminal. As a logical channel, the PCCH is mapped to the Paging Channel (PCH), which is used as a transport channel.

[0026] The Common Control Channel (CCCH) is a channel used to transmit control information between a communication terminal and a base station. The CCCH is used when there is no RRC connection between the communication terminal and the network. In the downlink direction, the CCCH is mapped to the Downlink Shared Channel (DL-SCH) used as a transport channel. In the uplink direction, the CCCH is mapped to the Uplink Shared Channel (UL-SCH) used as a transport channel.

[0027] The Multicast Control Channel (MCCH) is a downlink channel used for point-to-multipoint transmission. The MCCH is used to send one or more MBMS control messages (MTCHs) from the network to the communication terminal. The MCCH is only used by the communication terminal during the MBMS reception process. The MCCH is mapped to the Multicast Channel (MCH), which serves as the transport channel.

[0028] The Dedicated Control Channel (DCCH) is a channel used to transmit dedicated control information between a communication terminal and the network in a point-to-point manner. The DCCH is used when the communication terminal is in 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).

[0029] A Dedicated Traffic Channel (DTCH) is a channel used to transmit user information and conduct point-to-point communication with individual terminals. DTCH exists in both the uplink and downlink. In the uplink, DTCH is mapped to the Uplink Shared Channel (UL-SCH), and in the downlink, it is mapped to the Downlink Shared Channel (DL-SCH).

[0030] The Multicast Traffic Channel (MTCH) is a downlink channel used to send service data from the network to the communication terminal. The MTCH is used only by the communication terminal during MBMS reception. The MTCH is mapped to the Multicast Channel (MCH).

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

[0032] A CSG (Closed Subscriber Group) cell is a cell for a specific subscriber with designated access rights (hereinafter sometimes referred to as a "subscriber-specific cell"). A specific subscriber is permitted access to more than one cell within a PLMN (Public Land Mobile Network). The more than one cell for which a specific subscriber is permitted access is called a "CSG cell(s)". However, PLMNs have access restrictions.

[0033] A CSG cell is part of a PLMN that broadcasts a unique CSG identity (CSG ID) and uses a CSG indication to broadcast "TRUE". Members of a pre-registered and authorized joiner group access the CSG cell using the CSG ID from their access permission information.

[0034] CSGIDs are broadcast by the CSG cell or the cell itself. Multiple CSGIDs exist in LTE communication systems. Furthermore, the CSGID is used by the user terminal (UE) to facilitate access for CSG-associated members.

[0035] Location tracking of a communication terminal is performed on a unit consisting of one or more cells. Location tracking is used to locate the communication terminal even in standby mode, thereby enabling the terminal to be accessed; in other words, it is performed to allow the terminal to be reached. The area used for location tracking of this communication terminal is called the tracking area.

[0036] In 3GPP, base stations referred to as Home-NodeB (Home-NB; HNB) and Home-eNodeB (Home-eNB; HeNB) have been studied. HNBs in UTRAN and HeNBs in E-UTRAN are, for example, base stations providing access services for homes, corporations, and businesses. Non-Patent Document 2 discloses three different modes for accessing HeNBs and HNBs. Specifically, it discloses Open access mode, Closed access mode, and Hybrid access mode.

[0037] Furthermore, within 3GPP, the standardization of Long Term Evolution Advanced (LTE-A), version 10, is continuously evolving (see Non-Patent Documents 3 and 4). LTE-A is based on the radio inter-communication method of LTE and is constructed by adding several new technologies.

[0038] In LTE-A systems, to support wider transmission bandwidths up to 100MHz, carrier aggregation (CA), which combines two or more component carriers (CCs), has been studied. CA is described in Non-Patent Literature 1.

[0039] In the case of a CA (Cybernetic Association), the UE has a unique RRC connection with the network (NW). Within the RRC connection, a serving cell provides NAS (Navigation 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 (DLPCC). In the uplink, the carrier corresponding to the PCell is the Uplink Primary Component Carrier (ULPCC).

[0040] Based on the UE's capabilities, secondary serving cells (SCells) are constructed to form a serving cell group with the Pcell. In the downlink, the carrier corresponding to the SCell is the Downlink Secondary Component Carrier (DLSCC). In the uplink, the carrier corresponding to the SCell is the Uplink Secondary Component Carrier (ULSCC).

[0041] For a UE, a serving cell group is formed by one PCell and one or more Scells.

[0042] Furthermore, as a new technology for LTE-A, it features technologies that support wider bandwidth extension and Coordinated Multiple Point Transmission and Reception (CoMP). CoMP, which was researched for the implementation of LTE-A in 3GPP, is described in Non-Patent Literature 1.

[0043] Furthermore, 3GPP is researching the use of small eNBs (hereinafter sometimes referred to as "small-scale base station devices") to cope with the massive traffic volume expected in the future. For example, research is underway on technologies that improve frequency utilization efficiency and increase communication capacity by setting up multiple small eNBs and forming multiple small cells. Specifically, there are dual connectivity (DC) systems where the UE communicates by connecting to two eNBs. DC is described in Non-Patent Literature 1.

[0044] Sometimes one of the eNBs that perform dual connections (DC) is called the "primary eNB (MeNB)" and the other is called the "secondary eNB (SeNB)".

[0045] Mobile network traffic is trending upwards, and communication speeds are continuously increasing. With the official implementation of LTE and LTE-A, further increases in communication speeds are foreseeable.

[0046] Furthermore, fifth-generation (hereinafter sometimes referred to as "5G") radio access systems are under investigation, with the goal of enabling next-generation mobile communications to begin service after 2020. For example, in Europe, the organization METIS is summarizing the requirements for 5G (see Non-Patent Document 5).

[0047] In 5G wireless access systems, for LTE systems, the following are the necessary conditions for achieving further low power consumption and low device cost: system capacity is 1000 times greater, data transmission speed is 100 times greater, data processing latency is 1 / 10th, and the number of simultaneous connections of communication terminals is 100 times greater.

[0048] To meet the above requirements, 3GPP is conducting 5G standard research as version 14 (see Non-Patent Documents 6-10). The technology for 5G radio bands is called "New Radio (NR) Access Technology," and several new technologies are being researched (see Non-Patent Documents 11-14). For example, research is underway on mobility without RRC, multi-beamforming (MBF) based on analog or hybrid beamforming, network slicing, etc.

[0049] Existing technical documents

[0050] Non-patent literature

[0051] Non-patent document 1: 3GPP TS36.300 V14.0.0

[0052] Non-patent document 2: 3GPP S1-083461

[0053] Non-patent document 3: 3GPP TR36.814 V9.0.0

[0054] Non-patent document 4: 3GPP TR36.912 V13.0.0

[0055] Non-Patent Document 5: “Scenarios, Requirements and KPIs for 5G mobile and wireless system”, [Online], April 30, 2013, ICT-317669-METIS / D1.1, [Searched December 8, 2018], Internet<https: / / www.metis2020.com / documents / deliverables / >

[0056] Non-patent document 6: 3GPP TR23.799 V1.1.0

[0057] Non-patent document 7: 3GPP TR38.801 V0.4.0

[0058] Non-patent document 8: 3GPP TR38.802 V1.0.0

[0059] Non-patent document 9: 3GPP TR38.804 V0.4.0

[0060] Non-patent literature 10: 3GPP TR38.912 V0.0.2

[0061] Non-patent document 11: 3GPP R2-164670

[0062] Non-patent document 12: 3GPP TS36.331 V14.0.0

[0063] Non-patent document 13: 3GPP R1-165364

[0064] Non-patent document 14: 3GPP R2-165542 Summary of the Invention

[0065] The problem that the invention aims to solve

[0066] In NR, mobility without RRC is studied. Compared to LTE, NR uses higher frequencies and concentrates power over a narrow area by forming beams, using one or more beams to cover the desired coverage area. Since beam movement occurs frequently with UE movement, leveraging mobility without RRC reduces signaling associated with inter-beam movement.

[0067] In communications using multiple beams or multiple TRPs (Transmission / Reception Points) in NR, the communicable space is separated by each beam or TRP. The parameters for handling RRC in this situation are not publicly available. Therefore, even if the communicable space is separated within the cell, the number of UEs that can be accommodated within the cell does not increase.

[0068] When carrier aggregation (CA), which collects and uses multiple carriers for communication, is applied to NR, it is unclear which beam of the cell should be aggregated, so the gNB cannot set the CA for the UE. As a result, many radio resources become unavailable, making it impossible to provide the UE with high-speed, high-capacity communication services.

[0069] Furthermore, in LTE, in Dual Connectivity (DC), a technology used to provide high-speed and high-capacity communication services, the primary base station (Master eNB: MeNB) requests bearer configuration from the secondary base station (Secondary gNB: SeNB). This bearer configuration request uses E-RAB parameters. However, in 5G, due to the use of network slicing, flow-based control is discussed between the CN and RAN, and bearer-based control is used within the RAN. Consequently, with the disappearance of E-RAB, the method for requesting bearer configuration from the Master gNB (MgNB) to the Secondary gNB (SgNB) becomes unclear. Therefore, in 5G, DC cannot be used, significantly reducing the efficiency of radio resource utilization.

[0070] The purpose of this invention is to provide a communication system that increases the number of UEs that can be accommodated in an NR and enables high-speed and high-capacity communication in the UEs.

[0071] Technical solutions for solving technical problems

[0072] The first communication system of the present invention includes: a communication terminal device; and a base station device for wireless communication with the communication terminal device via a wireless beam, wherein a cell formed by the base station device is spatially separated by a plurality of wireless beams belonging to the base station device, and the base station device shares RRC (Radio Resource Control) parameters for the communication terminal in two or more of the plurality of wireless beams.

[0073] The second communication system of the present invention includes: a communication terminal device; and a base station device for wireless communication with the communication terminal device via a wireless beam, wherein a cell formed by the base station device is spatially separated by a plurality of wireless beams belonging to the base station device, and when the communication terminal device moves from the coverage area of ​​the first wireless beam to the coverage area of ​​the second wireless beam, the base station device changes the RRC (Radio Resource Control) parameter used for the communication terminal device from a first RRC parameter for the first wireless beam to a second RRC parameter for the second wireless beam.

[0074] The third communication system of the present invention includes: a communication terminal device; and a base station device that communicates wirelessly with the communication terminal device via a wireless beam, wherein a cell formed by the base station device is spatially separated by a plurality of wireless beams belonging to the base station device, and the base station device sets up carrier aggregation in wireless beam units.

[0075] The fourth communication system of the present invention includes: a communication terminal device; a plurality of base station devices that can be wirelessly connected to the communication terminal device; and a core network that manages the communication between the communication terminal device and each base station device. When a first base station device connected to the communication terminal device requests a second base station device to set up a bearer for the communication terminal device, the first base station device notifies the second base station device of QoS (Quality of Service) related information obtained from the core network for a PDU session, and the second base station device sets up the bearer for the communication terminal device based on the notified QoS related information.

[0076] The fifth communication system of the present invention includes: a communication terminal device; a plurality of base station devices that can be wirelessly connected to the communication terminal device; and a core network that manages the communication between the communication terminal device and each base station device. When a first base station device connected to the communication terminal device requests a second base station device to set up a bearer for the communication terminal device, the first base station device sets up the bearer for the communication terminal device based on the QoS (Quality of Service) obtained from the core network for a PDU session, and notifies the second base station device of information related to the set bearer.

[0077] Invention Effects

[0078] According to the first communication system of the present invention, RRC parameters used for the communication terminal device are shared among two or more of a plurality of wireless beams that spatially separate a cell composed of base station devices. Therefore, wireless resource management is simplified.

[0079] According to the second communication system of the present invention, the RRC parameters used for the communication terminal device are changed according to the change of the wireless beam used for the communication terminal device. Therefore, the number of communication terminal devices that can be accommodated can be increased.

[0080] According to the third communication system of the present invention, carrier aggregation is configured on a wireless beam unit basis. Therefore, cells supporting beamforming can be configured as cells for carrier aggregation, increasing the available wireless resources. This enables the provision of high-speed and high-capacity communication services.

[0081] According to the fourth communication system of the present invention, the first base station device notifies the second base station device of QoS-related information obtained from the core network for a PDU session, and the second base station device sets up the bearer for the communication terminal device based on the notified QoS-related information. Therefore, dual connectivity (DC) can be set up for the fifth-generation (5G) radio access system.

[0082] According to the fifth communication system of the present invention, the first base station device sets up a bearer for the communication terminal device based on the QoS (Quality of Service) obtained from the core network for the PDU session, and notifies the second base station device of information related to the set bearer. Therefore, dual connectivity (DC) can be set up for the fifth generation (5G) radio access system.

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

[0084] Figure 1 This is an explanatory diagram showing the structure of the radio frame used in an LTE communication system.

[0085] Figure 2 This is a block diagram representing the overall structure of a communication system 200 using the LTE method discussed in 3GPP.

[0086] Figure 3 This refers to the communication terminal involved in this invention. Figure 2 The diagram shows the structure of the mobile terminal 202.

[0087] Figure 4 This refers to the base station involved in this invention. Figure 2 The diagram shows the structure of base station 203.

[0088] Figure 5 This is a block diagram illustrating the structure of the MME involved in this invention.

[0089] Figure 6This is a flowchart summarizing the process from cell search to standby mode performed by a communication terminal (UE) in an LTE communication system.

[0090] Figure 7 This is a diagram representing the concept of a cell structure where both macro eNBs and small eNBs coexist.

[0091] Figure 8 This is a diagram illustrating the separation of the communicable space through multiple beams or TRPs in Implementation 1.

[0092] Figure 9 This is a flowchart of beam / TRP switching using MAC signaling in Implementation Method 2.

[0093] Figure 10 This is a flowchart of beam / TRP switching using MAC signaling in implementation method 3.

[0094] Figure 11 This is a flowchart of beam / TRP switching using MAC signaling in implementation method 4.

[0095] Figure 12 This is a diagram illustrating the architecture of the CA set in beam units in the gNB of embodiment 6.

[0096] Figure 13 This is a diagram illustrating an example of the CA setting process for a beam unit using RRC signaling in Implementation 6.

[0097] Figure 14 This is a diagram illustrating an example of the CA setting process for a beam unit using RRC signaling in Implementation 6.

[0098] Figure 15 This is a diagram illustrating an example of a MAC CE for beam activation / deactivation information in a variation of Embodiment 6, Example 1.

[0099] Figure 16 This is a diagram illustrating an example of the CA setting process for a beam unit using MAC signaling in a variation of implementation 6, Example 1.

[0100] Figure 17 This is a diagram illustrating an example of the CA setting process for a beam unit using MAC signaling in a variation of implementation 6, Example 1.

[0101] Figure 18 This is a diagram illustrating an example of the CA setting process for a beam unit using L1 / L2 signaling in a variation 2 of implementation 6.

[0102] Figure 19This is a diagram illustrating an example of the CA setting process for a beam unit using L1 / L2 signaling in a variation 2 of implementation 6.

[0103] Figure 20 This is a diagram illustrating an example of the CA setting process for a beam unit using L1 / L2 signaling in a variation 2 of implementation 6.

[0104] Figure 21 This is a diagram illustrating the DC (SCG bearer) setting method of Embodiment 7.

[0105] Figure 22 This is a diagram illustrating the DC (Divided Bearer) setting method of Embodiment 7.

[0106] Figure 23 This is a diagram illustrating an example of the DC (SCG bearer) setup process in Implementation 7.

[0107] Figure 24 This is a diagram illustrating an example of the DC (SCG bearer) setup process in Implementation 7.

[0108] Figure 25 This is a diagram illustrating the DC (SCG bearer) setting method for each PDU session in a variation of embodiment 7, 1.

[0109] Figure 26 This is a diagram illustrating the DC (SCG bearer) setting method for each PDU session in a variation of embodiment 7, 1.

[0110] Figure 27 This is a diagram illustrating the DC (segmented bearing) setting method of Modification 1 of Embodiment 7.

[0111] Figure 28 This is a diagram illustrating another DC (split bearing) setting method of variation 1 of embodiment 7.

[0112] Figure 29 This is a diagram illustrating another DC (split bearing) setting method of variation 1 of embodiment 7.

[0113] Figure 30 This is a diagram illustrating the DC (SCG bearer) setting method for each PDU session in a variation of embodiment 7, example 2.

[0114] Figure 31 This is a diagram illustrating the DC (Split Bearer) setting method for each PDU session in a variation of embodiment 7, example 2. Detailed Implementation

[0115] Implementation method 1.

[0116] Figure 2This is a block diagram illustrating the overall structure of a communication system 200 using the LTE method discussed in 3GPP. Figure 2 The following explanation is provided. The radio access network is referred to as E-UTRAN (Evolved Universal Terrestrial Radio Access Network) 201. The communication terminal device, namely the mobile terminal device (hereinafter referred to as "Mobile Terminal (User Equipment): UE)") 202, can wirelessly communicate with the base station device (hereinafter referred to as "Base Station (E-UTRAN NodeB): eNB)") 203 and use wireless communication to transmit and receive signals.

[0117] Here, "communication terminal device" refers not only to mobile terminal devices such as mobile phone terminals, but also to stationary devices such as sensors. In the following description, "communication terminal device" may sometimes be abbreviated as "communication terminal".

[0118] If the control protocols for mobile terminal 202, such as RRC (Radio Resource Management) and user layer protocols, such as PDCP (Packet Data Convergence Protocol), RLC (Radio Link Control), MAC (Medium Access Control), and PHY (Physical layer), terminate at base station 203, then E-UTRAN consists of one or more base stations 203.

[0119] The control protocol RRC between mobile terminal 202 and base station 203 includes broadcasting, paging, and RRC connection management. The states of base station 203 and mobile terminal 202 in RRC are RRC_IDLE and RRC_CONNECTED.

[0120] In RRC_IDLE, PLMN (Public Land Mobile Network) selection, System Information (SI) broadcasting, paging, cell re-selection, and mobility are performed. In RRC_CONNECTED, the mobile terminal has an RRC connection and can send and receive data with the network. Furthermore, in RRC_CONNECTED, handover (HO) and neighbor cell measurement are performed.

[0121] Base station 203 is classified into eNB 207 and Home-eNB 206. Communication system 200 includes eNB group 203-1 containing multiple eNBs 207, and Home-eNB group 203-2 containing multiple Home-eNBs 206. The system consisting of EPC (Evolved Packet Core) as the core network and E-UTRAN 201 as the radio access network is called EPS (Evolved Packet System). Sometimes, EPC as the core network and E-UTRAN 201 as the radio access network are collectively referred to as the "network".

[0122] The eNB 207 connects to a Mobility Management Entity (MME), an S-GW (Serving Gateway), or an MME / S-GW unit (hereinafter sometimes referred to as "MME unit") 204 via the S1 interface, facilitating control information communication between the eNB 207 and the MME unit 204. Multiple MME units 204 can be connected to a single eNB 207. The eNBs 207s also connect to each other via the X2 interface, facilitating control information communication between them.

[0123] The Home-eNB 206 connects to the MME unit 204 via the S1 interface, and communication of control information between the Home-eNB 206 and the MME unit 204 is performed. One MME unit 204 can be connected to multiple Home-eNB 206s. Alternatively, the Home-eNB 206 connects to the MME unit 204 via the HeNBGW (Home-eNB Gateway) 205. The Home-eNB 206 and HeNBGW 205 are connected via the S1 interface, and the HeNBGW 205 and MME unit 204 are connected via the S1 interface.

[0124] One or more Home-eNB206s are connected to one HeNBGW205 and communicate via the S1 interface. The HeNBGW205 is connected to one or more MME units 204 and communicates via the S1 interface.

[0125] MME 204 and HeNBGW 205 are upper-level devices, specifically upper-level nodes, that control the connection between eNB 207 (as a base station) and Home-eNB 206 and mobile terminal (UE) 202. MME 204 constitutes the EPC (Engineering Process Control) as the core network. Base station 203 and HeNBGW 205 constitute E-UTRAN 201.

[0126] Furthermore, the following structure was studied in 3GPP. It supports the X2 interface between Home-eNBs 206. That is, Home-eNBs 206 are connected via the X2 interface and communicate control information between them. From the perspective of MME 204, HeNBGW 205 can be considered as a Home-eNB 206. From the perspective of Home-eNB 206, HeNBGW 205 can be considered as MME 204.

[0127] Whether the Home-eNB206 is connected to the MME unit 204 via the HeNBGW205 or directly to the MME unit 204, the interface between the Home-eNB206 and the MME unit 204 is always the S1 interface.

[0128] Base station 203 can constitute one cell or multiple cells. Each cell has a predetermined range as its coverage area, which enables communication with mobile terminal 202, and wireless communication is conducted with mobile terminal 202 within the coverage area. When a base station 203 constitutes multiple cells, each cell is configured to communicate with mobile terminal 202.

[0129] Figure 3 This illustrates the communication terminal involved in the present invention. Figure 2 The diagram shows the structure of the mobile terminal 202. Figure 3The transmission process of the mobile terminal 202 shown will be described. First, control data from the protocol processing unit 301 and 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 transmitted to the encoding unit 304 for error correction and other encoding processing. Alternatively, data may be output directly from the transmission data buffer unit 303 to the modulation unit 305 without encoding processing. The data encoded by the encoding unit 304 is modulated 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 into a wireless transmission frequency. Afterward, the transmission signal is transmitted from the antenna 307 to the base station 203.

[0130] Furthermore, the receiving process of the mobile terminal 202 is performed as follows: The antenna 307 receives the wireless signal from the base station 203. The received signal is converted from the wireless receiving frequency to a baseband signal by the frequency conversion unit 306, and demodulated in the demodulation unit 308. The demodulated data is transmitted to the decoding unit 309 for error correction and other decoding processes. Of the decoded data, control data is transmitted to the protocol processing unit 301, and user data is transmitted to the application unit 302. A series of processes of the mobile terminal 202 are controlled by the control unit 310. Thus, although in Figure 3 The details have been omitted, but the control unit 310 is connected to each of the units 301 to 309.

[0131] Figure 4 This illustrates the base station involved in the present invention. Figure 2 The diagram shows the structure of base station 203. Figure 4 The transmission processing of the base station 203 shown will be described. The EPC communication unit 401 handles data transmission and reception between base station 203 and EPC (MME unit 204, etc.), HeNBGW 205, etc. Other base station communication units 402 handle data transmission and reception with other base stations. The EPC communication unit 401 and other base station communication units 402 exchange information with the protocol processing unit 403. Control data from the protocol processing unit 403, as well as user data and control data from the EPC communication unit 401 and other base station communication units 402, are stored in the transmission data buffer unit 404.

[0132] The data stored in the transmission data buffer 404 is transmitted to the encoding unit 405 for encoding processing such as error correction. Alternatively, data may be output directly from the transmission data buffer 404 to the modulation unit 406 without encoding processing. The encoded data is modulated 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 into a wireless transmission frequency. Afterward, the transmission signal is transmitted to one or more mobile terminals 202 using the antenna 408.

[0133] Furthermore, the reception processing of base station 203 is performed as follows. Wireless signals from one or more mobile terminals 202 are received by antenna 408. The received signal is converted from a wireless receiving frequency to a baseband signal by frequency conversion unit 407, and demodulated by demodulation unit 409. The demodulated data is transmitted to decoding unit 410 for error correction and other decoding processing. Of the decoded data, control data is transmitted to protocol processing unit 403, or EPC communication unit 401, or other base station communication units 402; user data is transmitted to EPC communication unit 401 and other base station communication units 402. A series of processes of base station 203 are controlled by control unit 411. Thus, although in Figure 4 The details have been omitted, but the control unit 411 is connected to each of the units 401 to 410.

[0134] Figure 5 This is a block diagram illustrating the structure of the MME involved in this invention. Figure 5 The above is shown in the middle. Figure 2 The structure of MME 204a included in MME 204 is shown. PDN GW communication unit 501 performs data transmission and reception between MME 204a and PDN GW. Base station communication unit 502 performs data transmission and reception between MME 204a and base station 203 via the S1 interface. When the data received from the PDN GW is user data, the user data is transmitted from PDN GW communication unit 501 to base station communication unit 502 via user plane communication unit 503, and then sent to one or more base stations 203. When the data received from base station 203 is user data, the user data is transmitted from base station communication unit 502 to PDN GW communication unit 501 via user plane communication unit 503, and then sent to PDN GW.

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

[0136] The HeNBGW communication unit 504, when HeNBGW 205 is present, performs data transmission and reception between MME 204a and HeNBGW 205 via an interface (IF) according to the information type. Control data received from the HeNBGW communication unit 504 is transmitted from the HeNBGW communication unit 504 to the control plane control unit 505. The processing results in the control plane control unit 505 are sent to the PDN GW via the PDNGW communication unit 501. Furthermore, the results processed by the control plane control unit 505 are sent to one or more base stations 203 via the base station communication unit 502 and the S1 interface, or to one or more HeNBGW 205 via the HeNBGW communication unit 504.

[0137] The control plane control unit 505 includes the NAS security unit 505-1, the SAE bearer control unit 505-2, and the Idle State mobility management unit 505-3, which performs all processing at the control plane. The NAS security unit 505-1 is responsible for the security of NAS (Non-Access Stratum) messages. The SAE bearer control unit 505-2 manages the SAE (System Architecture Evolution) bearer. The Idle State Mobility Management unit 505-3 manages mobility in standby state (also known as idle state; LTE-IDLE state, or simply idle), generates and controls paging signals in standby state, adds, deletes, updates, and retrieves tracking areas for one or more mobile terminals 202 within the coverage area, and manages the tracking area list.

[0138] MME204a distributes paging signals to one or more base stations 203. MME204a performs mobility control in the idle state. MME204a manages the tracking area list when the mobile terminal is in idle state and active state. MME204a initiates the paging protocol by sending a paging message to the cell belonging to the tracking area registered by the UE. The management of the CSG, CSGID, and whitelist of the Home-eNB206 connected to MME204a can be performed by the idle state mobility management unit 505-3.

[0139] Next, an example of a cell search method in a communication system is shown. Figure 6This is a flowchart illustrating the process of a communication terminal (UE) in an LTE communication system from cell search to standby operation. If the communication terminal starts cell search, in step ST601, the first synchronization signal (P-SS) and the second synchronization signal (S-SS) sent from the surrounding base stations are used to obtain the synchronization of time slot timing and frame timing.

[0140] P-SS and S-SS are collectively referred to as the Synchronization Signal (SS). The Synchronization Signal (SS) contains a synchronization code that corresponds one-to-one with the PCI assigned to each cell. Consider setting the number of PCIs to 504. These 504 PCIs are used to achieve synchronization, and the PCIs of synchronized cells are detected (determined).

[0141] Next, in step ST602, the reference signal (Reference Signal: RS) sent from the base station to each cell after synchronization is achieved, i.e., the Cell-specific Reference Signal (CRS), is measured, and the Received Power of the RS (RSRP) is determined. The Reference Signal (RS) uses a code that corresponds one-to-one with the PCI. This code can be used to obtain correlation and thus separate the cell from other cells. By deriving the RS code for the cell based on the PCI determined in step ST601, the RS can be detected, and the Received Power of the RS can be measured.

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

[0143] Next, in step ST604, the PBCH of the best cell is received to obtain the broadcast information, i.e., the BCCH. The BCCH on the PBCH maps to the MIB (Master Information Block), which contains cell structure information. Therefore, by receiving the PBCH and obtaining the BCCH, the MIB can be obtained. Information in the MIB includes, for example, the DL (downlink) system bandwidth (also known as transmission bandwidth configuration), the number of transmit antennas, and the SFN (System Frame Number).

[0144] Next, in step ST605, based on the cell structure information of the MIB, the DL-SCH of the cell is received, and SIB (System Information Block) 1 in the broadcast information BCCH is obtained. SIB1 contains information related to accessing the cell, information related to cell selection, and scheduling information of other SIBs (SIBk; k≥2 integers). In addition, SIB1 contains the Tracking Area Code (TAC).

[0145] Next, in step ST606, the communication terminal compares the TAC of SIB1 received in step ST605 with the TAC portion of the Tracking Area Identity (TAI) in the tracking area list already saved by the communication terminal. The tracking area list is also called the TAI list. TAI is identification information used to identify the tracking area, consisting of the MCC (Mobile Country Code), MNC (Mobile Network Code), and TAC (Tracking Area Code). MCC is the country code. MNC is the network code. TAC is the tracking area code number.

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

[0147] The apparatus constituting the core network (hereinafter sometimes referred to as "core network-side apparatus") updates the tracking area list based on the TAU request signal and the identification number (UE-ID, etc.) of the communication terminal sent from the communication terminal. The core network-side apparatus sends the updated tracking area list to the communication terminal. The communication terminal rewrites (updates) its own TAC list based on the received tracking area list. Afterward, the communication terminal enters standby mode in the cell.

[0148] The widespread adoption of smartphones and tablets has led to an explosive growth in traffic volume using cellular wireless communication systems, raising concerns about insufficient wireless resources worldwide. To address this issue and improve frequency utilization efficiency, research has been conducted on cell miniaturization and the separation of propulsion spaces.

[0149] In the existing cell structure, cells composed of eNBs have a wide coverage area. Previously, cells were constructed by utilizing the wide coverage area of ​​multiple cells consisting of multiple eNBs to cover a specific area.

[0150] When miniaturizing cells, cells composed of existing eNBs have a narrower coverage area compared to cells composed of existing eNBs. Therefore, similar to existing technologies, to cover a certain area, a large number of miniaturized eNBs are needed compared to existing eNBs.

[0151] In the following explanation, as with conventional eNBs, cells with larger coverage areas are referred to as "macrocells," and the eNBs that make up macrocells are referred to as "macro eNBs." Furthermore, as with cells that have undergone miniaturization, cells with smaller coverage areas are referred to as "small cells," and the eNBs that make up small cells are referred to as "small eNBs."

[0152] For example, a macro eNB can be a "wide area base station" as described in Non-Patent Document 7.

[0153] Small eNBs can be, for example, low-power nodes, local nodes, and hotspots. Small eNBs can be pico eNBs constituting pico cells, femto pico eNBs constituting femto pico cells, HeNBs, RRHs (Remote Radio Heads), RUs (Remote Radio Units), RREs (Remote Radio Equipment), or RNs (Relay Nodes). An eNB can be a "Local Area Base Station" or a "Home Base Station" as described in Non-Patent Document 7.

[0154] Figure 7 This diagram illustrates the concept of a cell structure when macro eNBs and small eNBs are combined. Macro cells, composed of macro eNBs, have a relatively large coverage area 701. Small cells, composed of small eNBs, have a smaller coverage area 702 compared to the coverage area 701 of the macro eNBs (macro cells).

[0155] When multiple eNBs are mixed together, the coverage area of ​​a cell consisting of one eNB may be included in the coverage area of ​​a cell consisting of other eNBs. Figure 7In the cell structure shown, as indicated by reference numerals "704" or "705", the coverage area 702 of a small cell consisting of small eNBs is sometimes included within the coverage area 701 of a macro cell consisting of macro eNBs.

[0156] Furthermore, as indicated by reference numeral "705", there are also cases where the coverage areas 702 of multiple, for example, two small cells are included within the coverage area 701 of a macrocell. A mobile terminal (UE) 703, for example, is included within the coverage area 702 of the small cells and communicates via the small cells.

[0157] In addition, Figure 7 In the structure of the cell shown, as indicated by reference numeral "706", the following situation will occur: the coverage area 701 of the macro cell composed of macro eNBs and the coverage area 702 of the small cell composed of small eNBs will overlap in a complex manner.

[0158] Furthermore, as indicated by reference numeral "707", the coverage area 701 of macro cells composed of macro eNBs and the coverage area 702 of small cells composed of small eNBs will not overlap.

[0159] Furthermore, as indicated by reference numeral "708", the following situation will also occur: the coverage area 702 of multiple small cells consisting of multiple small eNBs will be within the coverage area 701 of a macro cell consisting of a macro eNB.

[0160] During LTE handover, the mobile target cell generates parameters (such as cell ID) used by the UE in the mobile target, and the generated parameters are notified to the UE from the mobile source cell as RRC signaling (see Non-Patent Literature 1).

[0161] In NR, beam communication was used in the study. In NR, the beam belonging to the UE is frequently switched due to the movement of the UE. Therefore, the mobility of RRC is not used in the study when the UE moves between beams (see Non-Patent Literature 11).

[0162] Furthermore, 3GPP proposes a scheme where the gNB is separated into two units (see Non-Patent Document 7). These two units are called CU (Central Unit) and DU (Distributed Unit). The CU connects to multiple DUs. For example, a scheme has been proposed where the CU has PDCP, RLC, MAC, and H-PHY. A scheme has been proposed where the DU has L-PHY. Other methods have been proposed where the CU has PDCP and the DU has RLC, MAC, and PHY, or where the CU has PDCP and H-RLC and the DU has L-RLC, MAC, and PHY. The TRP can have the same functions as the DU. The DU or TRP constitutes one or more beams.

[0163] Furthermore, the study investigates the implementation of inter-cell mobility (i.e., mobility using RRC signaling) when the TRP has Layer 2 functionality during movement between UE beams or TRPs (Transmission / Reception Points), and the implementation of inter-beam mobility (i.e., mobility without RRC signaling) when the TRP does not have Layer 2 functionality (refer to 3GPP R2-167024 (hereinafter referred to as "Reference 1")).

[0164] In NR communication using multiple beams or multiple TRPs, the communicable space is separated by each beam or each TRP.

[0165] Figure 8 This is a diagram illustrating how multiple beams or TRPs separate the communicable space. Figure 8 In this configuration, the gNB800 consists of one CU (Central Unit) and two DUs (Distributed Units). DU#1 801 and DU#2 802 are connected to CU803. DUs can be TRPs.

[0166] Figure 8 In this configuration, DU#1 has beams #1 804, #2 805, and #3 806, while DU#2 has beams #4 807, #5 808, #6 809, and #7 810. Cell 811, i.e., the space where the gNB can communicate, is separated by beams #1 804 to #7 810.

[0167] Figure 8 In this configuration, one DU or multiple DUs can be used. Furthermore, the CU and DU can also be combined and configured as a single device.

[0168] However, in cases where a cell is spatially separated due to individual beams or TRPs, as described above, the parameters for handling RRCs are not disclosed.

[0169] This embodiment 1 discloses a method for solving the above-mentioned problems.

[0170] Within a single cell's beam or TRP, the same RRC parameters are shared for a single UE. RRC parameters can be those shown in Section 6.3.2 of Non-Patent Document 12. RRC parameters can be, for example, parameters related to SR, parameters related to Ack / Nack repetition, parameters related to Sounding Reference Signal (SRS), or parameters related to CQI / CSI.

[0171] During the sharing of RRC parameters, the CU of the gNB can notify each TRP within the cell of the RRC parameters. This notification can be specifically for physical layer-related RRC parameters. Physical layer-related RRC parameters can be, for example, parameters representing the frequency resources of the SRS. This facilitates modulation and demodulation in each TRP.

[0172] Alternatively, the parameters required for beam scanning can be shared within a single cell's beam or TRP. These parameters could include, for example, the beam scanning period, the duration of a single beam scan, or the time required for one beam. These parameters can be set as new RRC parameters. This allows the UE to easily receive beam scanning signals while moving between beams / TRPs.

[0173] The CU can notify each TRP within the cell of the parameters required for beam scanning. This allows for easy transmission of beam scanning signals in each TRP.

[0174] In the above, for example, the area of ​​the CPRI (Common Public Radio Interface) control word can be used for RRC parameter notification from CU to TRP. This control word can be used when CPRI is used for the CU-DU interface. Thus, RRC parameters can be notified without compromising the frequency band of user data flowing through the CU and DU on CPRI.

[0175] In the above, the RRC parameter notification from CU to TRP can use the ASN.1 (Abstract Syntax Notation One) format, or other formats. By using ASN.1, DU can notify TRP of parameters in the same format as RRC signaling, thus simplifying the process of DU notifying TRP of RRC parameters.

[0176] Through this implementation method 1, even if multiple beams or TRPs exist within a cell, RRC parameters can be managed in the CU. Furthermore, the same RRC parameters are shared between beams or TRPs within the cell, thereby simplifying radio resource management within the CU.

[0177] According to Embodiment 1, a communication system is provided, which includes, for example, a communication terminal device and a base station device for wireless communication with the communication terminal device using wireless beams. A cell formed by the base station device is spatially separated by multiple wireless beams belonging to the base station device. The base station device shares RRC (Radio Resource Control) parameters for the communication terminal device among the multiple wireless beams belonging to the same cell. Furthermore, the multiple wireless beams can be configured as follows: Figure 8 As illustrated, it can be formed by multiple DUs (in other words, TRPs), or it can be formed by a single DU.

[0178] According to this structure, RRC parameters for communication terminal devices can be shared among two or more wireless beams in a cell spatially separated by base station devices. Therefore, wireless resource management can be simplified as described above. Here, the above structure can be modified in various ways as described above. Furthermore, while Embodiment 1 illustrates an example of all wireless beams belonging to the same cell sharing RRC parameters, the structure is not limited to this example (for example, refer to Embodiment 8 and its modifications described later).

[0179] Implementation method 2.

[0180] In Implementation 1, the case of sharing RRC parameters between different beams or different TRPs within a cell is shown, but it is also possible not to share RRC parameters. The RRC parameters can be the same as in Implementation 1. Thus, different UEs existing within the coverage areas of different beams or different TRPs do not need to compete for the same RRC parameters, thereby increasing the number of UEs that can be accommodated in the cell.

[0181] However, when the CU and DU are separated as described in Embodiment 1, for example, when the CU has PDCP, RLC, MAC, and H-PHY, RRC signaling cannot be used as described in Embodiment 1 during inter-beam movement or inter-TRP movement within the cell. Therefore, RRC parameters cannot be notified to the UE from the gNB. Similarly, in base station devices where the CU and DU are not separated, RRC parameters cannot be notified to the UE from the gNB during inter-beam movement within the cell. This results in the problem of being unable to increase the number of UEs that can be accommodated in the cell.

[0182] This embodiment 2 discloses a method for solving the above-mentioned problems.

[0183] The CU (Cellular Control Unit) informs the UE in advance of the RRC parameters used by the beam or TRP (Telephone / TRP) within the cell. The CU can perform this notification using RRC signaling. The CU can perform this notification at the start of the UE's RRC connection or when the RRC parameters change.

[0184] During beam / TRP switching, the CU notifies the UE of a beam / TRP switching indication. This switching indication may include an identifier representing the moving target beam / TRP. The CU may notify the UE of this switching indication using L1 / L2 signaling or MAC signaling.

[0185] Therefore, the CU can achieve parameter changes accompanying beam / TRP switching with less signaling.

[0186] The notification of the aforementioned RRC parameters can consist solely of the RRC parameters used by the beam / TRP near the UE. This "nearby beam / TRP" can include beams / TRPs adjacent to the beam / TRP where the UE is located. Furthermore, the RRC parameters included in the notification can also consist solely of parameters different from those used by the beam / TRP where the UE is located. This reduces the size of the notification.

[0187] Other methods are also disclosed. During beam or TRP switching, the CU notifies the UE of the RRC parameters used by the moving target beam / TRP. This notification can be made via the moving source beam / TRP. The RRC parameters can be the same as those shown in Section 6.3.2 of Non-Patent Document 12, as in Embodiment 1. The RRC parameters can be, for example, parameters related to SR, parameters related to Ack / Nack repetition, parameters related to Sounding Reference Signal (SRS), or parameters related to CQI / CSI.

[0188] Therefore, the aforementioned RRC signaling from CU to UE is unnecessary, thus enabling beam / TRP switching with less signaling.

[0189] The CU can notify the UE of the parameters required for beam scanning. These parameters can be set to those shown in Implementation 1. This notification can be made via the mobile source beam / TRP. The parameters required for beam scanning can be set to those in the mobile target beam / TRP. Therefore, the UE can easily receive beam scanning signals moving between beams / TRPs.

[0190] The notification of the required beam scanning parameters from the CU to the UE can be performed using L1 / L2 signaling or MAC signaling. This allows for the rapid notification of the parameters needed for beam scanning.

[0191] The CU notifies the UE of a beam / TRP handover indication (hereinafter sometimes simply referred to as "handover indication") via the mobile source beam / TRP. The handover indication may contain an identifier representing the mobile target beam / TRP. In addition, the handover indication may contain information indicating the timing of the beam / TRP handover.

[0192] In the above, when the CU determines the moving target beam / TRP, it can use the beam measurement results notified by the UE to the CU. These measurement results can be, for example, beam reception strength or beam reception quality.

[0193] The handover indication can include an identifier representing the moving target beam / TRP. The CU and UE can automatically determine the moving target beam / TRP based on the beam / TRP measurement results. The beam / TRP measurement results can be, for example, the received strength of each beam or the received quality. This reduces the signaling load of the handover indication.

[0194] As the RRC parameters related to SR mentioned above, the following (1) to (3) are shown.

[0195] (1) Determine the parameters of the RB (Resource Block) and code of the SR. For example, sr-PUCCH-ResourceIndex as described in Non-Patent Document 12.

[0196] (2) The transmission period and subframe offset of SR. For example, the sr-ConfigIndex described in Non-Patent Document 12.

[0197] (3) The combination of (1) and (2) above.

[0198] According to (1) above, by preventing the location of the RB used for SR from competing with other UEs due to the movement of the UE between beams / TRPs, the number of UEs that can be accommodated in a beam / TRP can be increased.

[0199] According to (2) above, by preventing the SR transmission timing from competing with other UEs due to the movement of the UE between beams / TRPs, the number of UEs that can be accommodated in one beam / TRP can be increased.

[0200] In (2) above, only the subframe offset of the SR transmission can be changed. Furthermore, when the subframe offset is changed, only the subframe offset information can be notified. Therefore, for the SR transmission of multiple UEs in the Mobile Target Beam / TRP, adjustments can be easily made by the CU to avoid contention between UEs. Moreover, by only notifying the subframe offset information, the amount of bits transmitted from the CU to the UE can be reduced.

[0201] The parameters notified in (1) to (3) above can be the value itself or the change in the value. By using the value itself, the processing of parameter notification from CU to UE becomes easier. Furthermore, by using the change in the value, the number of bits required for parameter notification can be reduced.

[0202] The CU can simultaneously notify the UE of multiple parameters in the RRC parameters (1) to (3) mentioned above. This reduces the amount of signaling required for notification.

[0203] The CU can notify the UE of the RRC parameters (1) to (3) mentioned above. Thus, the parameters can be notified even when there are fewer transmission resources.

[0204] The CU may notify the UE of a parameter representing the maximum number of SR retransmissions as an RRC parameter related to SR, or it may not notify the UE. The parameter representing the maximum number of retransmissions may, for example, be dsr-TransMax as described in Non-Patent Document 12. By notifying the parameter, for example, by changing the parameter to a smaller value in adverse transmission environments, the UE can quickly transition to random access processing after exceeding the SR retransmission count. This allows for faster completion of beam / TRP movement processing.

[0205] The CU may include an identifier indicating a parameter change resulting from a TRP / beam switch in its notification of RRC parameters to the UE. The UE can retain the RRC parameters before the change. Therefore, the UE can prevent changes to the RRC parameters before a TRP / beam switch, thus preventing, for example, situations where SR transmission fails to reach the mobile source TRP / beam due to the aforementioned parameter changes.

[0206] Regarding RRC parameter notifications, the CU can avoid notifying parameters with the same values ​​used in the Moving Target Beam / TRP. This reduces the signaling load generated by parameter notifications.

[0207] The CU and UE can restore the RRC parameter values ​​to their initial values ​​during UE beam / TRP handover. For example, the initial values ​​can be changed if parameter notification from the mobile source beam / TRP to the UE fails. The initial values ​​can be determined by the standard or can be notified in advance from the CU to the UE using RRC signaling. Thus, even if parameter notification from the mobile source beam / TRP to the UE fails, the UE can continue communication with the CU using the initial values.

[0208] Alternatively, the CU and UE can retain the parameter values ​​described above. Retaining parameter values ​​can, for example, occur when parameter notification from the CU to the UE fails. Thus, even if parameter notification from the mobile source beam / TRP to the UE fails, the UE can still use the RRC parameters before the change. Therefore, for example, if the same RRC parameters as the mobile source beam / TRP are used in the mobile target beam / TRP, the UE can prevent SR from not being delivered to the mobile target beam / TRP.

[0209] Whether the parameters used during UE beam / TRP handover are restored to their initial values ​​or maintained can be determined by the standard, or can be communicated to the UE in advance from the CU. This notification can use RRC signaling. Alternatively, the information regarding whether to restore to the initial values ​​or maintain them can be sent from the CU to the UE along with the handover indication. This allows the CU to flexibly set the parameters based on the usage of RRC parameters by its subordinate UEs.

[0210] The CU can notify the UE of RRC parameters along with the handover indication. This reduces the signaling load during beam / TRP handover.

[0211] Alternatively, the CU can notify the UE of the handover indication after the RRC parameter notification. Thus, the CU can notify the UE of the handover indication after the RRC parameter confirmation is received. Therefore, it can avoid situations such as SR non-delivery from the UE due to the non-delivery of RRC parameters related to the SR, and random access operations due to exceeding the retransmission limit.

[0212] Alternatively, the CU can notify the UE of the RRC parameters after the handover indication notification. In this case, the CU can notify the UE of the handover indication along with the handover timing. Thus, even if the processing of switching the communication target beam / TRP in the UE takes time, the handover can be performed smoothly.

[0213] The CU can use L1 / L2 signaling to notify the UE of the RRC parameters. This allows for rapid notification of parameters to the UE.

[0214] Alternatively, the CU can use MAC signaling to notify RRC parameters. This allows for multi-level modulation and parameter notification with fewer symbols. Furthermore, HARQ retransmission control is implemented, thus improving the reliability of parameter notification. Additionally, the CU can notify the UE of the handover indication after parameter confirmation, thereby avoiding, for example, SR non-delivery from the UE due to parameter non-delivery and random access execution due to exceeding the SR retransmission limit.

[0215] The CU can notify the Mobile Target Beam / TRP of the RRC parameters. Similar to Embodiment 1, this notification can use, for example, a region of the control word CPRI, and can use the ASN.1 format or other formats. Therefore, in addition to the same effects as Embodiment 1, for example, the Mobile Target Beam / TRP can quickly decode the SR from the UE immediately after a beam / TRP handover.

[0216] The CU can use L1 / L2 signaling to notify the UE of the handover indication. This allows for rapid notification of beam / TRP handover to the UE.

[0217] Alternatively, the CU can use MAC signaling to notify the handover indication. The CU can switch its own beam / TRP after receiving an Ack for the handover indication from the UE. The UE can also switch its target communication beam / TRP after sending an Ack for the handover indication. This improves the reliability of the CU notifying the UE of the handover indication and reduces the likelihood of a Radio Link Failure (RLF) due to link loss with the gNB.

[0218] In the aforementioned handover indication notification using MAC signaling, the CU can switch the beam / TRP when the handover indication from the mobile source beam / TRP to the UE exceeds the HARQ retransmission count. Beam / TRP switching can be performed even when the Ack / Nack signal from the UE in response to the handover indication cannot be determined. Therefore, when the mobile source beam / TRP fails to receive the Ack signal from the UE in response to the handover indication, the communication target beam / TRP in the UE can be switched, and the beam / TRP in the gNB can also be switched. This prevents the loss of the link between the UE and the gNB.

[0219] Alternatively, as described above, the CU can choose not to switch beams / TRPs if the handover indication from the mobile source beam / TRP to the UE exceeds the HARQ retransmission count. In this case, the UE can resume communication with the mobile source beam / TRP after the RLF is restored following the link loss with the gNB. This simplifies beam switching control within the CU.

[0220] Figure 9 This is a flowchart illustrating the beam / TRP switching when the CU notifies the SR-related parameters via the mobile source beam / TRP. Figure 9 This example demonstrates how MAC signaling is used to notify the UE of SR-related parameters and handover instructions from the CU. Figure 9 In this context, the mobile source beam / TRP under the CU is denoted as S-beam / TRP, and the mobile target beam / TRP under the CU is denoted as T-beam / TRP. Furthermore, Figure 9In the image, the black circle in the arrow indicates the beam / TRP used for communication.

[0221] according to Figure 9 In step ST901 before beam / TRP switching, the UE transmits and receives user data with the CU via S-beam / TRP.

[0222] Figure 9 In step ST902, the CU notifies the SR parameters to the UE via S-beam / TRP. This notification uses MAC signaling. L1 / L2 signaling can also be used. Furthermore, the SR parameters can include either the sr-PUCCH-ResourceIndex shown in Non-Patent Document 12 or the sr-ConfigIndex shown in Non-Patent Document 12. In step ST903, the UE notifies the CU of an Ack response to the SR parameter notification via S-beam / TRP. If the reception result from the UE is Nack, the CU can retransmit the SR parameters via S-beam / TRP.

[0223] Figure 9 In step ST904, the CU notifies the UE of the handover indication via S-beam / TRP. The handover indication notification can use MAC signaling or L1 / L2 signaling. The CU can include information representing the T-beam / TRP in the handover indication. In step ST905, the UE notifies the CU of an Ack response to the handover indication via S-beam / TRP. If the received result from the UE is Nack, the CU can retransmit the handover indication via S-beam / TRP.

[0224] Figure 9 In step ST906, the UE switches the beam / TRP of the communication target from S-beam / TRP to T-beam / TRP. In step ST907, the CU switches the beam / TRP from S-beam / TRP to T-beam / TRP. In step ST908, the CU communicates user data with the UE via T-beam / TRP.

[0225] The UE can send uplink signals to the beam / TRP of the mobile source. The uplink signal can be a response to L1 / L2 signaling in response to RRC parameter notification from the CU. The uplink signal can also be a response to L1 / L2 signaling in response to handover indication from the CU. As an uplink signal, additional L1 / L2 signaling for the response can be configured. New uplink control information (UCI) can be configured as the above response. Therefore, even if L1 / L2 signaling is used in the RRC parameter notification or handover indication from the CU, the CU can still confirm delivery to the UE. This improves the reliability of the aforementioned L1 / L2 signaling.

[0226] Alternatively, the UE can send the uplink signal to the beam / TRP of the mobile target. The uplink signal can be used as an acknowledgment signal for beam / TRP switching within the UE. The frequency resources of the SR (Signal Transfer Signal) can be used to send the acknowledgment signal. Alternatively, the SR can be sent as the acknowledgment signal. This saves frequency resources used for uplink signals.

[0227] Alternatively, a new UCI can be sent. The CU can allocate this new UCI resource per UE. The CU can include information about this UCI resource in a notification that requires a response from the UE. This notification could be, for example, a handover notification or a parameter change notification. Thus, the CU can flexibly allocate new UCI resources to UEs based on resource availability.

[0228] As another example of new UCI resources, shared resources can be prepared for use by UEs within the cell. These shared resources can be, for example, PRACH, shared resources for SR, or other shared resources. Therefore, the CU does not need to notify the UE of the new UCI resource information, thus reducing signaling load.

[0229] As an uplink signal, the UE can send an SR to the beam / TRP of the mobile target with a minimum cycle. This allows for low-latency confirmation that the UE has switched the beam / TRP of the communication target.

[0230] In the above, the CU can ensure shared SR resources for UEs existing within the coverage area of ​​the same beam / TRP. UEs can utilize these shared SR resources for SR transmission. These shared SR resources can be contention-based resources that allow UEs to compete for them. The location of the shared SR resources can be predetermined by the standard or notified to subordinate UEs by the CU. This notification can be broadcast or a UE-specific notification. The UE-specific notification mentioned above can be RRC-specific signaling. Therefore, even if RRC parameter reception fails, the UE can still notify the CU that a beam / TRP handover has occurred.

[0231] The UE can use the initial values ​​of the RRC parameters related to the SR during the communication target beam / TRP handover as SR shared resources. Therefore, even if RRC parameter reception fails, the UE can still notify the CU that a beam / TRP handover has occurred.

[0232] The UE described above can also send SRS to the mobile target's beam / TRP. The SRS can be either aperiodic or periodic. The UE can send a predetermined number of SRS to the mobile target's beam / TRP. This number of transmissions can be determined by the standard or can be notified to the UE in advance by the CU. This notification can be performed using RRC signaling. Therefore, even without uplink user data being sent to the CU, the UE can notify the CU that a communication target beam / TRP handover has occurred.

[0233] The CU can use the aforementioned SR to determine whether the UE is switching communication target beams / TRPs. For example, if there is no SR notification from the UE, the CU can determine that the UE is not switching communication target beams / TRPs. The CU can then re-notify the RRC parameters and handover indication from the mobile source beam / TRP. This re-notification can be made using the aforementioned determination result. Therefore, for example, it can prevent RLF or random access processing due to the UE's failure to receive parameters or handover indications related to the SR. This can shorten the beam / TRP handover time.

[0234] The CU can notify the UE of whether or not it has sent an uplink signal. This request can be for uplink signals to the mobile source beam / TRP and uplink signals to the mobile target beam / TRP, respectively. This request can be included in the handover indication from the CU to the UE. Therefore, for example, when communication quality is excellent, a response from the UE may not be necessary, thus reducing signaling load.

[0235] The CU can notify the UE of RRC parameters multiple times. This improves the reliability of parameter notification. The number of notifications can be determined by the standard or pre-notified to the UE by the gNB. These notifications can be performed using RRC signaling.

[0236] The CU can increase the transmission power for notifying the UE of RRC parameters. This improves the reliability of parameter notification with fewer notifications. The amount of power increase can be determined by the standard or pre-notified to the UE by the CU. This notification can be performed using RRC signaling.

[0237] Similar to the notification of RRC parameters, the handover indication notification to the UE can be sent multiple times, and the power can also be increased. This improves the reliability of the handover indication notification.

[0238] The UE uses notifications of RRC parameters received from the mobile source beam / TRP to switch the beam / TRP of the communication target. Beam / TRP switching can be accompanied by beam scanning and random access. Beam / TRP switching can be performed using the reception of more than one RRC parameter. Beam / TRP switching can occur after the UE receives more than one of the aforementioned parameters and a predetermined time has elapsed. This predetermined time can be determined by the standard or can be notified to the UE in advance by the CU. This notification can be delivered using RRC signaling. Therefore, even if the UE cannot correctly receive the handover instruction from the CU to the UE, the UE can still switch the beam / TRP of the communication target. Furthermore, the time required for retransmitting the handover notification from the CU to the UE is eliminated.

[0239] In the above, the CU can include information indicating the moving target beam / TRP in the parameter notification. Therefore, in beam / TRP handover of the UE when the UE cannot correctly receive the handover instruction from the CU to the UE, the time for the UE to search for and handover the target beam / TRP can be shortened.

[0240] For SR transmissions from the UE, the CU can invalidate SRs received by the mobile source beam / TRP. The CU can invalidate SRs when a beam / TRP handover occurs between SR reception and uplink scheduling-permitted transmission. In the above scenario, the UE can retransmit the SR to the mobile target beam / TRP. This simplifies the implementation of SR transmission processing within the UE.

[0241] Alternatively, regarding the beam / TRP handover following the SR transmission from the UE, the CU can validate the SR received by the mobile source beam / TRP. The CU can then send the uplink scheduling permission for the SR to the UE via the mobile target beam / TRP. This ensures smooth uplink data communication during beam / TRP handover.

[0242] Whether the aforementioned SR is set to valid can be determined by the standard. Alternatively, it can be notified to the UE by the CU. This notification can be made in advance via RRC signaling, MAC signaling, or L1 / L2 signaling. In examples using MAC signaling or L1 / L2 signaling, this notification can be made together with the handover notification. This allows for flexible scheduling of uplink data communication in the CU.

[0243] Regarding uplink scheduling grant notifications from the CU to the UE, the CU and UE can invalidate uplink scheduling grants transmitted from the mobile source beam / TRP. When a beam / TRP handover occurs between an uplink scheduling grant and uplink user data, the CU and UE can invalidate the uplink scheduling grant. In the above, the CU can retransmit the uplink scheduling grant from the mobile target beam / TRP. Alternatively, the UE can restart SR transmission to the mobile target beam / TRP. Whether the UE restarts from SR transmission is determined by the standard. Alternatively, the gNB can notify the UE. This notification can be pre-processed via RRC signaling, MAC signaling, or L1 / L2 signaling. In examples where the notification is performed using MAC signaling or L1 / L2 signaling, the notification can be performed together with the handover notification. Thus, the gNB can perform scheduling corresponding to the uplink resource usage in the mobile target beam / TRP.

[0244] Alternatively, regarding the beam / TRP handover following the uplink scheduling clearance notification from the CU to the UE, both the CU and UE can make the uplink scheduling clearance sent from the mobile source beam / TRP valid. The UE can then use the uplink scheduling clearance to send uplink user data to the mobile target beam / TRP. This reduces the signaling load between the CU and the UE.

[0245] Whether the uplink scheduling permission is enabled can be determined by the standard, or it can be notified from the CU to the UE. The notification from the CU to the UE can be performed in advance via RRC signaling, MAC signaling, or L1 / L2 signaling. As an example of enabling the uplink scheduling permission, it can be set up so that the Mobile Target Beam / TRP allows the UE to use the uplink resources indicated by the scheduling permission. In examples where the notification is performed using MAC signaling or L1 / L2 signaling, the notification can be performed together with a handover notification. Thus, the CU can perform scheduling corresponding to the uplink resource usage status in the Mobile Target Beam / TRP with less signaling.

[0246] For uplink user data transmission from the UE to the CU, the CU can send an Ack / Nack from the Mobile Target Beam / TRP to the UE for the uplink user data received from the UE by the Mobile Source Beam / TRP. This Ack / Nack transmission from the Mobile Target Beam / TRP can be performed during beam / TRP handover between uplink user data transmission from the UE and the Ack / Nack notification from the CU. This ensures a smooth beam / TRP handover after uplink user data transmission.

[0247] According to this embodiment 2, RRC parameters can be notified from the CU to the UE during beam / TRP movement within the cell, increasing the number of UEs that can be accommodated in a cell spatially separated by beam / TRP. Furthermore, compared to notification based on RRC signaling, parameter notification can be performed more quickly.

[0248] In Implementation 2, a base station apparatus with separate CU and DU is shown as an example, but it can also be applied to base station apparatuses where the CU and DU are not separated. This base station apparatus can be one that does not share RRC parameters between beams. When applying Implementation 2 to this base station apparatus, the CU can be replaced with a gNB. Therefore, during inter-beam movement within a cell, RRC parameters can be notified to the UE from the gNB via the mobile source beam, increasing the number of UEs that can be accommodated in spatially separated cells due to beam separation. Parameters can be quickly notified to the UE from the gNB.

[0249] In Embodiment 2, a base station apparatus that uses a mobile source beam / TRP to notify the UE of RRC parameters is shown as an example, but other beam / TRPs can also be used to notify the RRC parameters. These other beam / TRPs could be, for example, beam / TRPs used for transmitting control information. Therefore, in a base station apparatus that has beam / TRPs for both user data transmission and control information transmission, RRC parameters can be notified using less signaling. Thus, RRC parameter notification can be performed quickly during beam movement.

[0250] According to Embodiment 2, a communication system is provided, which includes, for example, a communication terminal device and a base station device for wireless communication with the communication terminal device using wireless beams. A cell formed by the base station device is spatially separated by multiple wireless beams belonging to the base station device. When the communication terminal device moves from the coverage area of ​​a first wireless beam to the coverage area of ​​a second wireless beam, the base station device changes the RRC (Radio Resource Control) parameters used by the communication terminal device from a first RRC parameter for the first wireless beam to a second RRC parameter for the second wireless beam. Furthermore, the multiple wireless beams can be configured as follows: Figure 8 As illustrated, it can be formed by multiple DUs (in other words, TRPs), or by a single DU, or by a base station device that integrates CU and DU.

[0251] According to this structure, the RRC parameters used by the communication terminal device can be changed based on the change in the wireless beam used for the communication terminal device. Therefore, the number of communication terminal devices that can be accommodated can be increased as described above.

[0252] Here, the above structure can be modified in various ways as described above. For example, a communication system can be provided in which: the base station device includes at least one DU (Distributed Unit) that outputs multiple wireless beams and a CU (Central Unit) that controls at least one DU; the CU has a MAC (Medium Access Control) function; the CU notifies the communication terminal device of a second RRC parameter and notifies the communication terminal device of a switching indication from the first wireless beam to the second wireless beam using the first wireless beam. Alternatively, a communication system can be provided in which: the base station device has the function of outputting multiple wireless beams and a MAC function; the base station device notifies the communication terminal device of the second RRC parameter and notifies the communication terminal device of a switching indication from the first wireless beam to the second wireless beam using the first wireless beam.

[0253] Furthermore, various modifications are provided as described in the following modifications 1 to 3.

[0254] Variation 1 of Implementation Method 2.

[0255] In Implementation 2, the description focuses on the notification of RRC parameters related to SR, but it can also be applied to RRC parameters related to Ack / Nack repetition.

[0256] As the RRC parameters related to Ack / Nack repetition mentioned above, the following (1) to (3) are shown.

[0257] (1) The number of repetitions of Ack / Nack from the UE. For example, the repetition factor described in Non-Patent Document 12.

[0258] (2) The parameters of the RB that determine the repeated transmission of Ack / Nack. For example, nlPUCCH-AN-Rep as described in Non-Patent Document 12.

[0259] (3) The combination of (1) and (2) above.

[0260] Based on (1) above, the number of repetitions of Ack / Nack can be changed according to the transmission conditions, thereby improving the reliability of Ack / Nack notifications from UE to CU, especially in the case of a poor transmission environment.

[0261] According to (2) above, by preventing the RB used for Ack / Nack repetition from competing with other UEs due to the movement between UE beams / TRPs, the number of UEs that can be accommodated in one beam / TRP can be increased.

[0262] The parameters used in the above (1) to (3) notifications can be the value itself or the change in the value.

[0263] In this variation 1, the method and content of the handover notification from the CU to the UE via the forward beam / TRP can be set to be the same as in embodiment 2. Furthermore, the method for the CU to notify the UE of RRC parameters related to Ack / Nack repetition via the forward beam / TRP can be the same as the RRC parameter notification method described in embodiment 2.

[0264] The CU can notify the UE of a parameter indicating whether retransmitted data is bundled, as an RRC parameter related to Ack / Nack duplication, or it can choose not to notify it. The parameter indicating whether bundled data is bundled can be, for example, tdd_AckNackFeedbackMode as described in Non-Patent Document 12. If the parameter indicating whether bundled data is bundled is notified, for example by invalidating the bundled data during adverse transmission conditions, the CU can suppress the retransmission of already acknowledged user data.

[0265] Similar to implementation 2, the CU can notify the UE of the parameters required for beam scanning. Thus, the UE can easily receive beam scanning signals moving between beams / TRPs.

[0266] The notification of parameters required for beam scanning from CU to UE can be achieved using L1 / L2 signaling or MAC signaling.

[0267] The CU may include an identifier indicating a parameter change resulting from a TRP / beam handover in its notification to the UE regarding RRC parameters related to Ack / Nack repetition. The UE can retain the RRC parameters related to Ack / Nack repetition before the change. This prevents a decrease in the reliability of Ack / Nack transmission to the mobile source TRP / beam due to parameter changes during Ack / Nack transmission before the TRP / beam handover.

[0268] Similar to implementation 2, the CU may also refrain from notifying users of the same RRC parameters used in the Moving Target Beam / TRP regarding Ack / Nack repetition. This reduces the signaling load generated by parameter notifications.

[0269] The CU and UE can either restore the RRC parameter values ​​related to Ack / Nack repetition to their initial values ​​or retain them during UE beam / TRP handover. The initial values ​​of the RRC parameters can be determined by the standard or notified to the UE from the CU via RRC signaling. Whether to restore or retain the parameter values ​​during UE beam / TRP handover can be determined by the standard or notified to the UE in advance from the CU. Alternatively, the information on whether to restore or retain the initial values ​​can be notified to the UE from the CU along with the handover indication. Therefore, even if parameter notification from the mobile source beam / TRP to the UE fails, the UE can use the initial values ​​or the RRC parameters before the change. This improves the reliability of Ack / Nack repetition from the UE to the mobile target beam / TRP.

[0270] Similar to implementation 2, the CU can notify the UE of the RRC parameters related to Ack / Nack repetition along with the handover indication. This reduces the signaling load during beam / TRP handover.

[0271] Alternatively, the CU can notify the UE of the handover indication after receiving notification of the RRC parameters related to Ack / Nack duplication. This allows the CU to notify the UE of the handover indication only after the RRC parameters related to Ack / Nack duplication have been confirmed. Consequently, it avoids the failure to deliver duplicate Ack / Nack messages from the UE due to the failure to deliver the RRC parameters related to Ack / Nack duplication, and the resulting decrease in the reliability of Ack / Nack notifications due to the failure to deliver duplicate Ack / Nack messages from the UE.

[0272] Alternatively, the CU can notify the UE of the RRC parameters related to Ack / Nack repetition after the handover indication notification. In this case, the CU can notify the UE of the handover indication together with the handover timing. Thus, even if the processing of switching the communication target's beam / TRP in the UE takes time, the handover can be performed smoothly.

[0273] The CU can use L1 / L2 signaling to notify the UE of the aforementioned RRC parameters related to Ack / Nack repetition. This allows for rapid notification of the parameters to the UE.

[0274] Alternatively, the CU can utilize MAC signaling to notify the aforementioned RRC parameters related to Ack / Nack repetition. This enables multi-level modulation and parameter notification with a smaller number of symbols. Furthermore, HARQ retransmission control is implemented, thus improving the reliability of parameter notification. Additionally, the CU can notify the UE of the handover indication after parameter acknowledgment, thereby avoiding duplicate Ack / Nack failures from the UE due to parameter non-delivery and improving the reliability of Ack / Nack transmission.

[0275] Regarding handover notification, similar to implementation method 2, the notification can be sent from the CU to the UE using L1 / L2 signaling or MAC signaling. This achieves the same effect as implementation method 2.

[0276] As an example of the process for RRC parameter notification and switching indication related to Ack / Nack repetition, Figure 9 The parameters related to SR in step ST902 can be replaced with parameters related to Ack / Nack repetition.

[0277] Similar to implementation method 2, the CU can send multiple notifications of parameters related to Ack / Nack repetition to the UE, thereby increasing the transmission power. This improves the reliability of Ack / Nack repetition notifications. The same applies to handover indications from the CU to the UE.

[0278] The UE can send Ack / Nack notifications to the mobile target beam / TRP for downlink user data received from the CU via the mobile source beam / TRP. This Ack / Nack notification from the UE to the mobile target beam / TRP can occur during beam / TRP handover between downlink user data and Ack / Nack. This allows for seamless downlink user data processing in both the CU and UE during beam / TRP handover.

[0279] During Ack / Nack repetition from UE to CU, CU can use both the Ack / Nack received by the mobile source beam / TRP and the Ack / Nack received by the mobile target beam / TRP, or only one of them. Ack / Nack utilization can occur when switching beam / TRPs during Ack / Nack repetition from UE to CU. The specific beam / TRP from which Ack / Nack is used can be determined in advance by the standard, or the CU can switch appropriately. By using both the Ack / Nack received by the mobile source beam / TRP and the Ack / Nack received by the mobile target beam / TRP, the reliability of Ack / Nack notification from UE to CU is improved even when switching beam / TRPs during Ack / Nack repetition. Furthermore, by using only one of the Ack / Nack received by the mobile source beam / TRP and the Ack / Nack received by the mobile target beam / TRP, the synthesis processing of Ack / Nack repetitions in CU is eliminated. Therefore, Ack / Nack reception processing in the CU becomes simple.

[0280] The CU can retransmit downlink user data to the UE that utilizes Ack / Nack repetitions sent from the UE to the mobile source beam / TRP. This retransmission can occur when the beam / TRP is switched between Ack / Nack repetitions from the UE to the CU and retransmissions of downlink user data from the CU to the UE. Therefore, downlink user data retransmission processing can be smoothly performed in both the CU and the UE during beam / TRP switching.

[0281] By using this variation 1, RRC parameters related to Ack / Nack repetition can be notified to the UE, increasing the number of UEs that can be accommodated in spatially separated cells due to beam / TRP. Furthermore, compared to notifications based on RRC signaling, the parameters can be notified much faster.

[0282] Variation 2 of Implementation Method 2.

[0283] In Implementation 2, the description focuses on the notification of RRC parameters related to SR, but it can also be applied to RRC parameters related to SRS.

[0284] As the RRC parameters related to SRS mentioned above, the following (1) to (7) are shown.

[0285] (1) The frequency band used for SRS. For example, the srs-bandwidth described in Non-Patent Document 12.

[0286] (2) The frequency band for SRS frequency hopping. For example, the srs-Hopping Bandwidth described in Non-Patent Document 12.

[0287] (3) Position on the frequency axis of the SRS. For example, freqDomainPosition as described in Non-Patent Document 12.

[0288] (4) SRS period and subframe offset. For example, srs-ConfigIndex as described in Non-Patent Document 12.

[0289] (5) The location of the Comb when the SRS is transmitted. For example, the transmission Comb described in Non-Patent Document 12.

[0290] (6) Cyclic shift of SRS. For example, cyclic shift as described in Non-Patent Document 12.

[0291] (7) The combination of (1) to (6) above.

[0292] According to (1) above, by changing the frequency band used for SRS according to the number of UEs in a beam / TRP, the number of UEs accommodated in a beam / TRP can be increased.

[0293] According to (2) above, by flexibly changing the frequency band for SRS frequency hopping based on the number of UEs in a beam / TRP, the number of UEs that can be accommodated in a beam / TRP can be increased.

[0294] According to (3) above, by preventing the position on the frequency axis of the SRS from competing with other UEs due to the movement of the UE between beams / TRPs, the number of UEs that can be accommodated in one beam / TRP can be increased.

[0295] According to (4) above, by preventing the SRS transmission timing from competing with other UEs due to the movement of the UE between beams / TRPs, the number of UEs that can be accommodated in one beam / TRP can be increased.

[0296] According to (5) above, by preventing the position of the SRS Comb from competing with other UEs due to the movement of the UE between beams / TRPs, the number of UEs that can be accommodated in one beam / TRP can be increased.

[0297] According to (6) above, by preventing the cyclic shift of the SRS from competing with other UEs due to the movement of the UE between beams / TRPs, the number of UEs that can be accommodated in a beam / TRP can be increased.

[0298] In (4) above, only the subframe offset of the SRS transmission can be changed. Furthermore, when the subframe offset is changed, only the subframe offset information can be notified. Therefore, for the SRS transmission of multiple UEs in the Mobile Target Beam / TRP, adjustments can be easily made by the CU to avoid contention between UEs. Furthermore, by only notifying the subframe offset information, the amount of bits transmitted from the CU to the UE can be reduced.

[0299] The parameters notified in (1) to (7) above can be the value itself or the change in the value. By using the value itself, the processing of parameter notification from CU to UE becomes easier. In addition, by using the change in the value, the number of bits required for parameter notification can be reduced.

[0300] In this variation 2, the method and content of the handover notification from the CU to the UE via the forward beam / TRP can be set to be the same as in embodiment 2. Furthermore, the method by which the CU notifies the UE of the RRC parameters related to the SRS via the forward beam / TRP can be the same as the method for notifying the RRC parameters described in embodiment 2.

[0301] The CU can notify the UE of a parameter indicating whether SRS is being continuously transmitted, which can be used as an RRC parameter related to SRS, or it can choose not to notify it. The parameter indicating whether continuous transmission is being transmitted can be, for example, the Duration described in Non-Patent Document 12. By notifying the above parameter, the CU can flexibly allocate SRS resources to the UE.

[0302] Similar to implementation 2, the CU can notify the UE of the parameters required for beam scanning. Thus, the UE can easily receive beam scanning signals moving between beams / TRPs.

[0303] The notification of parameters required for beam scanning from CU to UE can be achieved using L1 / L2 signaling or MAC signaling.

[0304] The CU can include an identifier indicating a parameter change caused by a TRP / beam handover in its notification of SRS-related RRC parameters to the UE. The UE can retain the SRS-related RRC parameters from before the change. Therefore, the UE can prevent random access actions and uplink communication rate degradation caused by SRS failure to reach the CU due to parameter changes during SRS transmission before the TRP / beam handover.

[0305] Similar to Implementation 2, the CU may also omit the notification of parameters using the same values ​​in the Moving Target Beam / TRP regarding the RRC parameters related to SRS. Therefore, the signaling load generated by parameter notification can be reduced.

[0306] The CU and UE can either restore the values ​​of the RRC parameters related to SRS to their initial values ​​or retain them during UE beam / TRP handover. The initial values ​​of the RRC parameters can be determined by the standard or notified to the UE from the CU via RRC signaling. Whether to restore or retain the parameter values ​​during UE beam / TRP handover can be determined by the standard or notified to the UE in advance from the CU. Alternatively, the information regarding whether to restore or retain the initial values ​​can be notified to the UE from the CU along with the handover indication.

[0307] Therefore, even if parameter notification from the mobile source beam / TRP to the UE fails, the UE can prevent the SRS from being missed from the UE to the mobile target beam / TRP by using the initial value or the RRC parameter before the change.

[0308] Similar to implementation method 2, the CU can notify the UE of the RRC parameters related to the SRS along with the handover indication. This reduces the signaling load during beam / TRP handover.

[0309] Alternatively, the CU can notify the UE of the handover indication after receiving notification of the RRC parameters related to the SRS. Thus, the CU can notify the UE of the handover indication after acknowledgment of the delivery of the RRC parameters related to the SRS. As a result, SRS non-delivery from the UE to the CU due to the non-delivery of the RRC parameters related to the SRS can be avoided, thus preventing a decrease in uplink communication rate and the occurrence of random access.

[0310] Alternatively, the CU can notify the UE of the RRC parameters related to the SRS after receiving the handover indication. In this case, the CU can notify the UE of the handover indication along with the handover timing. Therefore, even if the processing of switching the communication target's beam / TRP in the UE takes time, the handover can proceed smoothly.

[0311] The CU can use L1 / L2 signaling to notify the UE of the aforementioned SRS-related RRC parameters. This allows for rapid notification of the parameters to the UE.

[0312] Alternatively, the CU can use MAC signaling to notify the aforementioned SRS-related RRC parameters. This allows for multi-level modulation and parameter notification with fewer symbols. Furthermore, HARQ retransmission control improves the reliability of parameter notification. The CU can notify the UE of a handover indication after parameter confirmation, thus avoiding SRS non-delivery from the UE to the CU due to parameter non-delivery, preventing uplink communication rate degradation and random access.

[0313] Regarding handover notification, similar to implementation method 2, the notification can be sent from the CU to the UE using L1 / L2 signaling or MAC signaling. This achieves the same effect as implementation method 2.

[0314] As an example of the process for notifying RRC parameters and providing handover instructions related to SRS, Figure 9 In step ST902, the parameters related to SR can be replaced with parameters related to SRS.

[0315] Similar to implementation method 2, the CU can send multiple notifications of SRS-related parameters to the UE, thereby increasing the transmission power. This improves the reliability of SRS-related parameter notifications. The same applies to handover indications from the CU to the UE.

[0316] The UE can utilize the Mobile Target Beam / TRP to transmit SRS in response to an SRS transmission indication received from the CU via the Mobile Source Beam / TRP. This SRS transmission from the UE to the Mobile Target Beam / TRP can occur during beam / TRP handover between the SRS transmission indication and the SRS transmission itself. This SRS transmission can be aperiodic. Therefore, SRS transmission processing during beam / TRP handover can be performed smoothly in both the CU and the UE.

[0317] The CU can invalidate the SRS transmitted from the UE to the mobile source beam. Invalidating the SRS can be performed after a beam / TRP switch following the SRS transmission. The CU can also send a retransmission instruction to the UE. The UE can then retransmit the SRS to the mobile target beam / TRP. Thus, the CU can perform scheduling adapted to the transmission status after a beam / TRP switch.

[0318] The aforementioned SRS retransmission from the UE can be performed autonomously by the UE. Therefore, the CU can quickly obtain the SRS after beam / TRP handover. Whether the UE autonomously retransmits the SRS can be determined by the standard, either by notifying the UE in advance via RRC signaling or by notifying it together with the handover indication notification from the CU to the UE.

[0319] By using this variation 2, RRC parameters related to SRS can be notified to the UE, increasing the number of UEs that can be accommodated in spatially separated cells due to beam / TRP. Furthermore, compared to notification based on RRC signaling, the parameters can be notified much faster.

[0320] Variation 3 of Implementation Method 2.

[0321] In Implementation 2, the description focuses on notification of RRC parameters related to SR, but it can also be applied to RRC parameters related to CQI / CSI.

[0322] As the RRC parameters related to CQI / CSI mentioned above, the following (1) to (5) are shown.

[0323] (1) Determine the parameters of the RB of CQI. For example, cqi-PUCCH-ResourceIndex as described in Non-Patent Document 12.

[0324] (2) The period and subframe offset of CQI and PMI (Precoding Matrix Indicator). For example, cqi-pmi-Configindex as described in Non-Patent Document 12.

[0325] (3) The period and subframe offset of RI (Rank Indicator). For example, ri-ConfigIndex as described in Non-Patent Document 12.

[0326] (4) Whether it is possible to send Ack / Nack and CQI simultaneously. For example, the simultaneous Ack / Nack and CQI described in Non-Patent Document 12.

[0327] (5) The combination of (1) to (4) above.

[0328] According to (1) above, by preventing the location of the RB used for CQI from competing with other UEs due to the movement of the UE between beams / TRPs, the number of UEs that can be accommodated in one beam / TRP can be increased.

[0329] According to (2) above, by preventing the CQI and PMI transmission timing from competing with other UEs due to the movement of the UE between beams / TRPs, the number of UEs that can be accommodated in one beam / TRP can be increased.

[0330] According to (3) above, by preventing the RI transmission timing from competing with other UEs due to the movement of the UE between beams / TRPs, the number of UEs that can be accommodated in one beam / TRP can be increased.

[0331] Based on the above (4), it is possible to flexibly set whether Ack / Nack and CQI can be sent simultaneously according to the uplink data scheduling status of the moving target's beam / TRP, so that the UE can efficiently send Ack / Nack and CQI to the CU.

[0332] In (2) above, only the subframe offsets of CQI and PMI can be changed. Furthermore, when the subframe offset is changed, only the subframe offset information can be notified. Therefore, for CQI / CSI transmissions of multiple UEs in the Mobile Target Beam / TRP, adjustments can be easily made through the CU to avoid contention between UEs. Furthermore, by only notifying the subframe offset information, the amount of bits transmitted from the CU to the UE can be reduced.

[0333] In step (3) above, the subframe offset of RI can be changed only, just like in step (2) above. Furthermore, when the subframe offset changes, only the subframe offset information can be notified. Thus, the same effect as described above can be achieved.

[0334] The parameters notified in (1) to (5) above can be the value itself or the change in the value. By using the value itself, the processing of parameter notification from CU to UE becomes easier. Furthermore, by using the change in the value, the number of bits required for parameter notification can be reduced.

[0335] Similar to implementation 2, the CU can notify the UE of the parameters required for beam scanning. Thus, the UE can easily receive beam scanning signals moving between beams / TRPs.

[0336] The notification of parameters required for beam scanning from CU to UE can be achieved using L1 / L2 signaling or MAC signaling.

[0337] In this variation 3, the method and content of the handover notification from the CU to the UE via the forward beam / TRP can be set to be the same as in embodiment 2. Furthermore, the method for the CU to notify the UE of RRC parameters related to CQI / CSI via the forward beam / TRP can be the same as the method for notifying RRC parameters described in embodiment 2.

[0338] The CU can include an identifier indicating a parameter change caused by a TRP / beam switch in its notification to the UE regarding CQI / CSI-related RRC parameters. The UE can retain the previous CQI / CSI-related RRC parameters. Therefore, the UE can prevent downlink communication rate degradation caused by CQI / CSI not reaching the CU due to parameter changes during CQI / CSI transmission before the TRP / beam switch.

[0339] Similar to Implementation 2, regarding RRC parameters related to CQI / CSI, the CU may not need to notify parameters that also use the same values ​​in the Moving Target Beam / TRP. Therefore, the signaling load generated by parameter notification can be reduced.

[0340] The CU and UE can either restore or retain the RRC parameters related to CQI / CSI to their initial values ​​during UE beam / TRP handover. The initial values ​​of the RRC parameters can be determined by the standard or notified from the CU to the UE via RRC signaling. Whether to restore or retain the parameter values ​​during UE beam / TRP handover can be determined by the standard or notified to the UE in advance by the CU. Alternatively, the information regarding whether to restore or retain the initial values ​​can be notified to the UE along with the handover indication. Therefore, even if parameter notification from the mobile source beam / TRP to the UE fails, the UE can use the initial values ​​or the RRC parameters before the change. Thus, for example, if the same RRC parameters as the mobile source beam / TRP are used in the mobile target beam / TRP, the UE can prevent CQI / CSI from not being delivered to the mobile target beam / TRP.

[0341] Similar to implementation method 2, the CU can notify the UE of the RRC parameters related to CQI / CSI along with the handover indication. This reduces the signaling load during beam / TRP handover.

[0342] Alternatively, the CU can notify the UE of the handover indication after receiving notification of the RRC parameters related to CQI / CSI. This allows the CU to notify the UE of the handover indication only after acknowledgment of the delivery of the RRC parameters related to CQI / CSI. Consequently, it avoids CQI non-delivery from the UE to the CU due to the non-delivery of the RRC parameters related to CQI / CSI, thus preventing a decrease in downlink communication speed.

[0343] Alternatively, the CU can notify the UE of the RRC parameters related to CQI / CSI after receiving the handover indication. In this case, the CU can notify the UE of the handover indication along with the handover timing. Therefore, even if the processing of switching the communication target's beam / TRP in the UE takes time, the handover can proceed smoothly.

[0344] The CU can use L1 / L2 signaling to notify the UE of the aforementioned RRC parameters related to CQI / CSI. This allows for rapid notification of the parameters to the UE.

[0345] Alternatively, the CU can utilize MAC signaling to notify the aforementioned RRC parameters related to CQI / CSI. This allows for multi-level modulation and parameter notification with a smaller number of symbols. Furthermore, HARQ retransmission control is implemented, thus improving the reliability of parameter notification. The CU can notify the UE of a handover indication after parameter confirmation, thereby avoiding CQI / CSI non-delivery from the UE to the CU due to parameter non-delivery and preventing a decrease in downlink communication rate.

[0346] Regarding handover notification, similar to implementation method 2, the notification can be sent from the CU to the UE using L1 / L2 signaling or MAC signaling. This achieves the same effect as implementation method 2.

[0347] As an example of the process for notifying and indicating RRC parameters related to CQI / CSI, Figure 9 The parameters related to SR in step ST902 can be replaced with parameters related to CQI / CSI.

[0348] Similar to implementation method 2, the CU can send multiple notifications of CQI / CSI related parameters to the UE, thereby increasing the transmission power. This improves the reliability of CQI / CSI related parameter notifications. The same applies to handover indications from the CU to the UE.

[0349] The UE can utilize the Mobile Target Beam / TRP to transmit CQI / CSI signals received from the CU via the Mobile Source Beam / TRP. This CQI / CSI transmission from the UE to the Mobile Target Beam / TRP can occur during beam / TRP handover between the CQI / CSI transmission signal and the CQI / CSI transmission. This CQI / CSI transmission can be aperiodic. Therefore, CQI / CSI transmission processing during beam / TRP handover can be performed smoothly in both the CU and the UE.

[0350] The CU can invalidate CQI / CSI transmitted from the UE to the mobile source beam. Invalidating CQI / CSI can be performed after a beam / TRP switch following CQI / CSI transmission. The CU can instruct the UE to retransmit CQI / CSI. The UE can retransmit CQI / CSI to the mobile target beam / TRP. Thus, the CU can perform scheduling adapted to the transmission status after a beam / TRP switch.

[0351] The aforementioned CQI / CSI retransmission from the UE can be performed autonomously by the UE. Therefore, the CU can quickly obtain the CQI / CSI after beam / TRP handover. Whether the UE autonomously retransmits the CQI / CSI can be determined by the standard, either by notifying the UE in advance via CQI / CSI signaling from the CU, or by notifying the UE together with the handover indication notification from the CU to the UE.

[0352] By using this variation 3, RRC parameters related to CQI / CSI can be notified to the UE, increasing the number of UEs that can be accommodated in spatially separated cells due to beam / TRP. Furthermore, compared to notifications based on RRC signaling, the parameters can be notified much faster.

[0353] Implementation method 3.

[0354] Implementation 2 illustrates a scenario where the gNB notifies the UE of RRC parameters from the mobile source beam / TRP. In NR, to ensure wide bandwidth, higher frequencies than LTE are used. However, using higher frequencies can lead to a sharp deterioration in communication due to obstacles or other factors. In such cases, if RRC parameter notification or handover notification is not timely during beam / TRP switching, a loss of the radio link between the gNB and the UE can occur.

[0355] This embodiment 3 discloses a method for solving the above-mentioned problems.

[0356] The CU notifies the UE of RRC parameters via the Mobile Target Beam / TRP. The handover indication notification from the CU to the UE is performed via the Mobile Source Beam / TRP. This differs from implementation 2 in that the RRC parameter notification from the CU is performed via the Mobile Target Beam / TRP.

[0357] The notification of RRC parameters from CU to UE can be performed after the handover notification from CU to UE. Therefore, the UE can smoothly obtain the aforementioned RRC parameters after switching communication target beams / TRPs.

[0358] The RRC parameters can be the same as those shown in Section 6.3.2 of Non-Patent Document 12, as in Embodiment 2. The RRC parameters can be, for example, parameters related to SR, parameters related to Ack / Nack repetition, parameters related to the Sounding Reference Signal (SRS), or parameters related to CQI / CSI.

[0359] The CU can notify the UE of the parameters required for beam scanning. The parameters required for beam scanning can be set to the parameters shown in Implementation 1. Notification of the parameters required for beam scanning can be performed via the mobile source beam / TRP. The parameters required for beam scanning can be set to the parameters in the mobile target beam / TRP. Therefore, the UE can easily receive beam scanning signals moving between beams / TRPs.

[0360] The notification of parameters required for beam scanning from the CU to the UE can be achieved using L1 / L2 signaling, similar to Embodiment 2, or using MAC signaling. This allows for rapid notification of the parameters required for beam scanning.

[0361] The RRC parameters related to SR mentioned above can be the parameters shown in (1) to (3) of Embodiment 2. Furthermore, similar to Embodiment 2, the CU can notify the UE of a parameter representing the maximum number of retransmissions of SR as the RRC parameter related to SR, or it can choose not to notify the UE. Thus, the same effect as Embodiment 2 can be obtained.

[0362] The notification of RRC parameters from the CU to the UE can be performed using L1 / L2 signaling in the same manner as in Implementation Method 2. This allows for rapid notification from the CU to the UE. Furthermore, even if the frequency resources used for the Ack / Nack response from the UE to the CU change due to beam / TRP switching of the gNB, the aforementioned RRC parameters can still be notified from the CU to the UE.

[0363] Alternatively, MAC signaling can be used as described above. Therefore, similar to implementation method 2, the RRC parameters can be transmitted with fewer symbols, and the reliability of parameter notification is improved. Thus, it is possible to avoid, for example, SR failure from the UE due to the failure to deliver the aforementioned parameters, and random access due to exceeding the retransmission limit.

[0364] Alternatively, RRC signaling can be used in the above process. This allows the RRC parameters to be communicated from the CU to the UE in advance, eliminating the need for RRC parameter notification during beam / TRP handover. This reduces signaling overhead. The method described above differs from Non-Patent Document 1 in that it communicates the RRC parameters to the UE from the mobile target beam / TRP.

[0365] The method for notifying the UE of the handover indication from the CU can use L1 / L2 signaling in the same way as in Implementation Method 2. Alternatively, MAC signaling can be used. This allows for rapid notification of beam / TRP handover to the UE. Furthermore, using MAC signaling improves the reliability of the notification.

[0366] Regarding RRC parameters, the CU may also choose not to notify parameters that use the same values ​​in the Moving Target Beam / TRP. Therefore, the signaling load generated by parameter notification can be reduced.

[0367] Similar to implementation method 2, during beam / TRP handover of the UE, the CU and UE can either restore the RRC parameter value to its initial value or retain the parameter value. Retaining the parameter value can, for example, be done if parameter notification from the CU to the UE fails. The initial value of the parameter can be determined by a standard, or it can be notified in advance from the CU to the UE using RRC signaling. Whether the parameter value is restored to its initial value or retained during beam / TRP handover can be set by a standard, can be notified in advance from the CU to the UE, or can be notified in advance from the CU to the UE along with the handover indication. Therefore, even if parameter notification from the mobile source beam / TRP to the UE fails, the UE can still use the RRC parameter before the change. Thus, for example, if the same RRC parameter as the mobile source beam / TRP is used in the mobile target beam / TRP, the UE can prevent situations where the SR is not delivered to the mobile target beam / TRP.

[0368] Similar to implementation method 2, the gNB can switch the beam / TRP when the handover indication from the mobile source beam / TRP to the UE exceeds the HARQ retransmission count, or it can choose not to switch the beam / TRP. For all cases, the same effect as implementation method 2 can be achieved.

[0369] Figure 10 This is a flowchart illustrating beam / TRP switching when parameters are notified from the CU via the moving target beam / TRP. Figure 10 This illustrates an example of using MAC signaling to notify the UE of parameters and handover instructions from the CU. Figure 10 In this context, the mobile source beam / TRP under the CU is denoted as S-beam / TRP, and the mobile target beam / TRP under the CU is denoted as T-beam / TRP. Furthermore, Figure 10 In the diagram, the black circle within the arrow represents the beam / TRP used for communication. (This is related to...) Figure 9 Identical steps are labeled with the same step number, and common descriptions are omitted.

[0370] Figure 10 In the process, before the beam / TRP switch, the UE transmits and receives user data with the CU via the S-beam / TRP (step ST901).

[0371] Figure 10 In step ST2001, the CU notifies the UE of the handover indication via S-beam / TRP. The handover indication notification can use MAC signaling or L1 / L2 signaling. The CU can include information representing the T-beam / TRP in the handover indication. In step ST2002, the UE notifies the CU of an Ack response to the handover indication via S-beam / TRP. If the received result from the UE is Nack, the CU can retransmit the handover indication via S-beam / TRP.

[0372] Figure 10 In step ST2003, the CU notifies the SR parameters to the UE via T-beam / TRP. This notification uses MAC signaling. L1 / L2 signaling can also be used. Furthermore, the SR parameters can include either the sr-PUCCH-ResourceIndex shown in Non-Patent Document 12 or the sr-ConfigIndex shown in Non-Patent Document 12. In step ST2004, the UE notifies the CU of the ACK for the notification regarding the SR parameters via T-beam / TRP. If the reception result from the UE is NACK, the CU can retransmit the SR parameters via T-beam / TRP.

[0373] The UE can send uplink signals to the beam / TRP of the mobile source. The uplink signal can be a response to L1 / L2 signaling in response to a handover indication from the CU. New L1 / L2 signaling can be configured as the uplink signal. New uplink control information (UCI) can be configured as the response. Therefore, even if L1 / L2 signaling is used in the handover indication from the CU, the CU can still send a confirmation of delivery to the UE. This improves the reliability of the aforementioned L1 / L2 signaling.

[0374] The new UCI can be set to be the same as in Implementation Method 2. Therefore, the same effect as in Implementation Method 2 can be obtained.

[0375] Alternatively, the UE can send an uplink signal to the beam / TRP of the mobile target. The CU and UE can use the uplink signal as an acknowledgment signal for beam / TRP handover within the UE. The uplink signal can be a response to MAC signaling in response to RRC parameter notification from the CU. Alternatively, it can be a response to L1 / L2 signaling in response to RRC parameter notification from the CU. New L1 / L2 signaling can be configured as the uplink signal. New uplink control information (UCI) can be configured as the above response. Therefore, even if L1 / L2 signaling is used in the handover indication from the CU, the CU can still send an acknowledgment to the UE. This improves the reliability of the aforementioned L1 / L2 signaling.

[0376] Similar to implementation 2, the CU can notify the UE of whether it requests to send an uplink signal. The presence or absence of this request can be for uplink signals to the mobile source beam / TRP and uplink signals to the mobile target beam / TRP, respectively. The presence or absence of this request can be included in the handover indication from the CU to the UE. Therefore, for example, when communication quality is excellent, a response from the UE may not be necessary, thus reducing signaling load.

[0377] The UE can utilize the frequency resources of the SR to transmit the aforementioned acknowledgment signal. Alternatively, the SR can be transmitted as the aforementioned acknowledgment signal. This conserves frequency resources used for uplink signals.

[0378] Similar to implementation method 2, the UE can send the SR described above with a minimum cycle. This allows for low-latency confirmation that the UE has switched the beam / TRP of the communication target.

[0379] Similar to implementation 2, the CU can ensure shared SR resources for UEs existing within the coverage area of ​​the same beam / TRP. UEs can utilize these shared SR resources to transmit SR. These shared SR resources can be contention-based resources that allow UEs to compete with each other. Therefore, even if RRC parameter reception fails, the UE can still notify the CU that a beam / TRP handover has occurred.

[0380] The CU and UE can set the initial values ​​of the RRC parameters related to the SR to the location of the shared resource for the SR during the UE's beam / TRP handover. The UE can then use the shared resource for the SR to notify the mobile target beam / TRP. Therefore, the UE can send the SR to the CU immediately after the communication target beam / TRP handover, and thus, can immediately send uplink user data to the CU. This reduces uplink communication latency during beam / TRP handover.

[0381] Similar to implementation method 2, the UE can send SRS to the mobile target's beam / TRP. The SRS can be either aperiodic or periodic. The UE can send a predetermined number of SRS to the mobile target's beam / TRP. This number of transmissions can be determined by a standard or can be notified to the UE in advance by the CU. Thus, even without uplink user data being sent to the CU, the UE can notify the CU that a communication target beam / TRP switch has occurred.

[0382] Similar to implementation method 2, the CU can use the aforementioned SR to determine whether there is a communication target beam / TRP handover in the UE. The CU can then re-notify the parameters and handover indication related to the SR from the mobile source beam / TRP. This prevents RLF or random access that may occur due to the UE failing to receive the parameters or handover indication related to the SR. Consequently, the beam / TRP handover time can be shortened.

[0383] Similar to implementation method 2, the CU can notify the UE of parameters multiple times. Furthermore, the CU can increase the transmission power of the parameter notification to the UE. This improves the reliability of parameter notification.

[0384] For SR transmissions from the UE, the CU can invalidate SRs received by the mobile source beam / TRP. The CU can invalidate SRs when a beam / TRP handover occurs between SR reception and uplink scheduling clearance transmission. In the above, the UE can retransmit the SR to the mobile target beam / TRP. SR retransmission can occur after receiving RRC parameter notifications from the CU to the UE. This prevents retransmitted SRs from the UE from failing to reach the CU.

[0385] Alternatively, similar to implementation 2, regarding beam / TRP handover after SR transmission from the UE, the CU can enable the SR received by the mobile source beam / TRP. This allows for smooth uplink data communication during beam / TRP handover.

[0386] Regarding the uplink scheduling grant notification from the CU to the UE, similarly to Implementation 2, both the CU and UE invalidate the uplink scheduling grant when a beam / TRP handover occurs between the uplink scheduling grant and uplink user data. In the above, the CU can retransmit the uplink scheduling grant from the mobile target beam / TRP. Alternatively, the UE can restart SR transmission for the mobile target beam / TRP. SR retransmission can be performed after receiving the RRC parameter notification from the CU to the UE. This prevents the retransmitted SR from the UE from failing to reach the CU.

[0387] In the above description, the CU and UE can enable the aforementioned permission. The operation of the CU and UE when the permission is enabled is the same as in Implementation Method 2. This reduces the signaling volume between the CU and UE.

[0388] Whether the uplink scheduling permission is enabled can be determined by the standard, or it can be notified from the CU to the UE. The notification from the gNB to the UE can be performed in advance via RRC signaling, MAC signaling, or L1 / L2 signaling. As an example of enabling the uplink scheduling permission, it can be set so that the Mobile Target Beam / TRP can use the uplink resources indicated by the scheduling permission for the UE. In examples where the notification is performed using MAC signaling or L1 / L2 signaling, the notification can be performed together with the handover notification. Thus, the CU can perform scheduling corresponding to the uplink resource usage status in the Mobile Target Beam / TRP with less signaling.

[0389] For uplink user data transmission from the UE to the CU, the CU can send an Ack / Nack from the Mobile Target Beam / TRP to the UE for the uplink user data received from the UE using the Mobile Source Beam / TRP. This Ack / Nack transmission from the Mobile Target Beam / TRP can occur during beam / TRP handover between uplink user data transmission from the UE and an Ack / Nack notification from the gNB. The Ack / Nack notification from the UE can occur before or after the RRC parameter notification from the CU to the UE. Alternatively, the Ack / Nack notification can occur between the parameter notification and the Ack / Nack response from the UE to the CU in response to the parameter notification. This allows for a smooth beam / TRP handover after uplink user data transmission.

[0390] According to this embodiment 3, in addition to the effects shown in embodiment 2, even in the case of a rapid deterioration in the communication environment between the mobile source beam / TRP and the UE, RRC parameter notification can still be sent from the CU to the UE. As a result, for example, random access processing of the UE due to the failure to deliver the SR can be suppressed.

[0391] Implementation method 2 and implementation method 3 can be combined. That is, the CU can switch which of the mobile source beam / TRP and the mobile target beam / TRP to transmit RRC parameters. Thus, the CU can flexibly change the beam / TRP from which RRC parameters are transmitted according to the communication environment.

[0392] The CU can pre-set the UE's quasi-static settings regarding which of the mobile source beam / TRP or the mobile target beam / TRP to send RRC parameters from. RRC signaling can be used in this notification. Therefore, the notification path for RRC parameters can be flexibly set according to transmission conditions.

[0393] Alternatively, it can be dynamically configured by the CU. For example, the CU can include information in the handover indication indicating which of the mobile source beam / TRP or mobile target beam / TRP the RRC parameters will be transmitted from, thus notifying the UE. The UE can then use this notification to receive the RRC parameters. Therefore, since the UE can explicitly know the target for receiving the RRC parameters, the reliability of RRC parameter notification acquisition can be improved.

[0394] Alternatively, this can be implicitly determined by the standard. For example, the UE can receive RRC parameters via the mobile source beam / TRP before receiving the handover indication, or via the mobile target beam / TRP after receiving the handover indication. Thus, there is no need for the CU to notify the UE of which of the mobile source beam / TRP or the mobile target beam / TRP to receive the RRC parameters from.

[0395] In Implementation 3, a base station device with separate CU and DU is shown as an example, but it can also be applied to base station devices where CU and DU are not separated. This base station device can be one that does not share RRC parameters between beams. When applying Implementation 3 to this base station device, the CU can be replaced with a gNB. Therefore, during inter-beam movement within the cell, RRC parameters can be notified to the UE from the gNB via the moving target beam, increasing the number of UEs that can be accommodated in spatially separated cells due to beam separation. Parameters can be quickly notified to the UE from the gNB.

[0396] According to Embodiment 3, a communication system is provided similarly to Embodiment 2. This system includes, for example, a communication terminal device and a base station device for wireless communication with the communication terminal device using wireless beams. A cell formed by the base station device is spatially separated by multiple wireless beams belonging to the base station device. When the communication terminal device moves from the coverage area of ​​the first wireless beam to the coverage area of ​​the second wireless beam, the base station device changes the RRC (Radio Resource Control) parameters used by the communication terminal device from the first RRC parameters used for the first wireless beam to the second RRC parameters used for the second wireless beam. Furthermore, the multiple wireless beams can be configured as follows: Figure 8 As illustrated, it can be formed by multiple DUs (in other words, TRPs), or by a single DU, or by a base station device that integrates CU and DU.

[0397] According to this structure, the RRC parameters used by the communication terminal device can be changed based on the change in the wireless beam used for the communication terminal device. Therefore, the number of communication terminal devices that can be accommodated can be increased as described above.

[0398] Here, the above structure can be modified in various ways as described above. Specifically, according to embodiment 3, for example, a communication system is provided where: the base station device includes at least one DU (Distributed Unit) that outputs multiple wireless beams and a CU (Central Unit) that controls at least one DU; the CU has a MAC (Medium Access Control) function; the CU notifies the communication terminal device of a second RRC parameter using a second wireless beam and notifies the communication terminal device of a switching indication from the first wireless beam to the second wireless beam using a first wireless beam. Alternatively, a communication system is provided where: the base station device has the function of outputting multiple wireless beams and a MAC function; the base station device notifies the communication terminal device of the second RRC parameter using a second wireless beam and notifies the communication terminal device of a switching indication from the first wireless beam to the second wireless beam using a first wireless beam.

[0399] Furthermore, various modifications are provided as described in the following modifications 1 to 3.

[0400] Variation 1 of Implementation Method 3.

[0401] In Implementation 3, the description focuses on the notification of RRC parameters related to SR, but it can also be applied to RRC parameters related to Ack / Nack repetition.

[0402] The RRC parameters related to the repetition of Ack / Nack mentioned above can be the same as those in Variation 1 of Implementation 2.

[0403] In this variation 1, the method and content of the handover notification from the CU to the UE via the forward beam / TRP can be set to be the same as in embodiment 3. Furthermore, the method by which the CU notifies the UE of RRC parameters related to Ack / Nack repetition via the forward target beam / TRP can be the same as the RRC parameter notification method described in embodiment 3. Therefore, the UE can smoothly obtain the aforementioned RRC parameters after switching the communication target beam / TRP.

[0404] Similar to Embodiment 3, the CU can notify the UE of the parameters required for beam scanning. The method of notifying the parameters can be the same as in Embodiment 3. Therefore, the UE can easily receive beam scanning signals moving between beams / TRPs.

[0405] The notification of parameters required for beam scanning from the CU to the UE described above can be achieved using L1 / L2 signaling or MAC signaling. This achieves the same effect as in Implementation Method 3.

[0406] Similar to implementation method 3, regarding the RRC parameters related to Ack / Nack repetition, the CU may also omit the requirement to notify parameters using the same values ​​in the Moving Target Beam / TRP. Therefore, the signaling load generated by parameter notification can be reduced.

[0407] Similar to Implementation Method 3, the CU and UE can either restore the values ​​of the RRC parameters related to Ack / Nack repetition to their initial values ​​or retain them during beam / TRP handover of the UE. Whether to restore the parameter values ​​to their initial values ​​or retain them during beam / TRP handover can be determined by a standard or can be communicated to the UE in advance from the CU. Alternatively, the information regarding whether to restore the initial values ​​or retain them can be communicated to the UE from the CU along with the handover instruction. This achieves the same effect as Implementation Method 3.

[0408] The CU can use L1 / L2 signaling to notify the UE of the aforementioned RRC parameters related to Ack / Nack repetition. This allows for rapid notification of the parameters to the UE.

[0409] Alternatively, the CU can use MAC signaling to notify the aforementioned RRC parameters related to Ack / Nack repetition. This enables multi-level modulation and parameter notification with a smaller number of symbols. Furthermore, HARQ retransmission control is implemented, thus improving the reliability of parameter notification.

[0410] Regarding handover notification, similar to implementation method 3, the notification can be sent from the CU to the UE using L1 / L2 signaling or MAC signaling. This achieves the same effect as implementation method 3.

[0411] As an example of the process for RRC parameter notification and switching indication related to Ack / Nack repetition, Figure 10 The parameters related to SR in step ST2003 can be replaced with parameters related to Ack / Nack repetition.

[0412] Similar to implementation method 3, the CU can send multiple notifications of parameters related to Ack / Nack repetition to the UE, thereby increasing the transmission power. This improves the reliability of Ack / Nack repetition notifications. The same applies to handover indications from the CU to the UE.

[0413] The UE can send Ack / Nack notifications received from the mobile source beam / TRP for downlink user data from the CU to the mobile target beam / TRP. This Ack / Nack notification from the UE to the mobile target beam / TRP can occur during beam / TRP handover between downlink user data and Ack / Nack. Therefore, downlink user data processing can be performed smoothly in both the CU and the UE during beam / TRP handover.

[0414] The aforementioned Ack / Nack notification from the UE to the Mobile Target Beam / TRP can be initiated after receiving parameter notifications related to Ack / Nack repetition from the CU to the UE. Therefore, the CU can receive subsequent Ack / Nack calls configured by the Ack / Nack repetition, thus improving the reliability of the Ack / Nack notification from the UE to the CU.

[0415] During Ack / Nack repetitions from UE to CU, CU can use only the Ack / Nack received by the mobile source beam / TRP. Ack / Nack utilization can occur during beam / TRP switching during Ack / Nack repetitions from UE to CU. Therefore, Ack / Nack reception processing in CU can be performed smoothly during beam / TRP switching during Ack / Nack repetitions.

[0416] Alternatively, in the Ack / Nack repetition from UE to CU, CU can validate the Ack / Nack received from both the mobile source beam / TRP and the mobile target beam / TRP. In this scenario, the UE can send the Ack / Nack repetition to the mobile target beam / TRP after receiving the RRC parameters related to the Ack / Nack repetition. This improves the reliability of the Ack / Nack notification from UE to CU.

[0417] Whether the CU uses the Ack / Nack received via the moving target beam / TRP can be determined in advance by the standard, or it can be switched appropriately using the CU. This allows for flexible switching based on the transmission environment and efficient reception of Ack / Nack.

[0418] Whether the CU uses the Ack / Nack received through the Mobile Target Beam / TRP can be notified to the UE by the CU. This notification can be made using RRC signaling or together with the handover notification from the CU to the UE. Thus, for example, when the CU only uses the Mobile Source Beam / TRP, the UE does not need to send repeated Ack / Nacks after the beam / TRP handover, thereby reducing signaling load.

[0419] The CU can retransmit downlink user data to the UE that utilizes Ack / Nack repetitions sent from the UE to the mobile source beam / TRP. This retransmission can occur when the beam / TRP is switched between Ack / Nack repetitions from the UE to the CU and retransmissions of downlink user data from the CU to the UE. Therefore, downlink user data retransmission processing can be smoothly performed in both the CU and the UE during beam / TRP switching.

[0420] By using this variation 1, the notification to the UE regarding the RRC parameters related to Ack / Nack repetition can achieve the same effect as in embodiment 3.

[0421] Variation 2 of Implementation Method 3.

[0422] In Implementation 3, the description focuses on the notification of RRC parameters related to SR, but it can also be applied to RRC parameters related to SRS.

[0423] The RRC parameters related to SRS mentioned above can be the same as those in Variation 2 of Embodiment 2.

[0424] In this variation 2, the method and content of the handover notification from the CU to the UE via the forward beam / TRP can be set to be the same as in embodiment 3. Furthermore, the method by which the CU notifies the UE of the RRC parameters related to SRS via the forward target beam / TRP can be the same as the RRC parameter notification method described in embodiment 3. Therefore, the UE can smoothly obtain the aforementioned RRC parameters after switching the communication target beam / TRP.

[0425] Similar to implementation method 3, the CU can notify the UE of the parameters required for beam scanning. Thus, the UE can easily receive beam scanning signals moving between beams / TRPs.

[0426] The notification of parameters required for beam scanning from the CU to the UE described above can be achieved using L1 / L2 signaling or MAC signaling. This achieves the same effect as in Implementation Method 3.

[0427] Similar to implementation method 3, regarding the RRC parameters related to SRS, the CU may not need to notify parameters that also use the same values ​​in the Moving Target Beam / TRP. Therefore, the signaling volume generated by parameter notification can be reduced.

[0428] Similar to Implementation Method 3, the CU and UE can either restore the values ​​of the RRC parameters related to SRS to their initial values ​​or maintain them during beam / TRP handover of the UE. Whether to restore the parameter values ​​to their initial values ​​or maintain them during beam / TRP handover can be determined by the standard or can be communicated to the UE in advance from the CU. Alternatively, the information regarding whether to restore the initial values ​​or maintain them can be communicated to the UE from the CU along with the handover instruction. This achieves the same effect as Implementation Method 3.

[0429] The CU can use L1 / L2 signaling to notify the UE of the aforementioned SRS-related RRC parameters. This allows for rapid notification of the parameters to the UE.

[0430] Alternatively, the CU can use MAC signaling to notify the aforementioned SRS-related RRC parameters. This enables multi-level modulation and parameter notification with a smaller number of symbols. Furthermore, HARQ retransmission control is implemented, thus improving the reliability of parameter notification.

[0431] Regarding handover notification, similar to implementation method 3, the notification can be sent from the CU to the UE using L1 / L2 signaling or MAC signaling. This achieves the same effect as implementation method 3.

[0432] As an example of the process for notifying RRC parameters and providing handover instructions related to SRS, Figure 10 The steps in ST2003 can be completed by replacing the SR-related parameters with SRS-related parameters.

[0433] Similar to implementation method 3, the CU can send multiple notifications of SRS-related parameters to the UE, thereby increasing the transmission power. This improves the reliability of SRS-related parameter notifications. The same applies to handover indications from the CU to the UE.

[0434] The UE can transmit SRS to the Mobile Target Beam / TRP after receiving SRS-related parameters from the CU via the Mobile Target Beam / TRP. This prevents the transmission of SRS that the Mobile Target Beam / TRP cannot receive before the UE receives the SRS-related parameters.

[0435] The UE can enable the SRS transmission request received from the CU from the mobile source beam / TRP. This action of enabling the SRS transmission request from the CU can be performed during beam / TRP handover between the SRS transmission request and the SRS transmission. Therefore, downlink user data processing can be performed smoothly in both the CU and the UE during beam / TRP handover.

[0436] Alternatively, as described above, the UE can invalidate the SRS transmission request. In this case, the CU can retransmit the SRS transmission request to the UE via the Mobile Target Beam / TRP. Thus, the CU can perform scheduling adapted to the transmission status after beam / TRP switching.

[0437] During SRS transmission from the UE to the CU, the CU can invalidate the SRS received by the mobile source beam / TRP. This invalidation can occur after a beam / TRP handover following the SRS transmission from the UE to the CU. The CU can notify the UE of the SRS transmission request via the mobile target beam / TRP. This notification can be used in aperiodic SRS. This allows the CU to communicate with the UE using an uplink communication rate that accurately reflects the beam / TRP handover.

[0438] By using this variation 2, the same effect as in embodiment 3 can be achieved in notifying the UE of RRC parameters related to SRS.

[0439] Variation 3 of Implementation Method 3.

[0440] In Implementation 3, the description focuses on notification of RRC parameters related to SR, but it can also be applied to RRC parameters related to CQI / CSI.

[0441] The RRC parameters related to CQI / CSI mentioned above can be the same as those in variation 3 of embodiment 2.

[0442] In this variation 3, the method and content of the handover notification from the CU to the UE via the forward beam / TRP can be set to be the same as in embodiment 3. Furthermore, the method by which the CU notifies the UE of RRC parameters related to CQI / CSI via the forward target beam / TRP can be the same as the RRC parameter notification method described in embodiment 3. Therefore, the UE can smoothly obtain the aforementioned RRC parameters after switching the communication target beam / TRP.

[0443] Similar to implementation method 3, the CU can notify the UE of the parameters required for beam scanning. Thus, the UE can easily receive beam scanning signals moving between beams / TRPs.

[0444] The notification of parameters required for beam scanning from the CU to the UE described above can be achieved using L1 / L2 signaling or MAC signaling. This achieves the same effect as in Implementation Method 3.

[0445] Similar to implementation method 3, regarding RRC parameters related to CQI / CSI, the CU may not need to notify parameters that also use the same values ​​in the Moving Target Beam / TRP. Therefore, the signaling volume generated by parameter notification can be reduced.

[0446] Similar to Implementation Method 3, the CU and UE can either restore the initial values ​​of the RRC parameters related to CQI / CSI to their respective values ​​or retain them during beam / TRP switching of the UE. Whether to restore the initial values ​​or retain them during beam / TRP switching can be determined by the standard or can be communicated to the UE in advance from the CU. Alternatively, the information regarding whether to restore the initial values ​​or retain them can be communicated to the UE from the CU along with the handover instruction. This achieves the same effect as Implementation Method 3.

[0447] The CU can use L1 / L2 signaling to notify the UE of the aforementioned RRC parameters related to CQI / CSI. This allows for rapid notification of the parameters to the UE.

[0448] Alternatively, the CU can use MAC signaling to notify the aforementioned CQI / CSI-related RRC parameters. This enables multi-level modulation and parameter notification with a smaller number of symbols. Furthermore, HARQ retransmission control is implemented, thus improving the reliability of parameter notification.

[0449] Regarding handover notification, similar to implementation method 3, the notification can be sent from the CU to the UE using L1 / L2 signaling or MAC signaling. This achieves the same effect as implementation method 3.

[0450] As an example of the process for notifying and indicating RRC parameters related to CQI / CSI, Figure 10 The steps in ST2003 can be completed by replacing the SR-related parameters with CQI / CSI-related parameters.

[0451] Similar to implementation method 3, the CU can send multiple notifications of CQI / CSI related parameters to the UE, thereby increasing the transmission power. This improves the reliability of CQI / CSI related parameter notifications. The same applies to handover indications from the CU to the UE.

[0452] The UE can transmit CQI / CSI to the Mobile Target Beam / TRP after receiving CQI / CSI-related parameters transmitted from the CU via the Mobile Target Beam / TRP. This prevents the transmission of CQI / CSI that the Mobile Target Beam / TRP cannot receive before the UE receives the CQI / CSI-related parameters.

[0453] The UE can enable CQI / CSI transmission requests received from the CU via the mobile source beam / TRP. This action of enabling CQI / CSI transmission requests from the CU can be performed during beam / TRP handover between CQI / CSI transmission requests and CQI / CSI transmissions. This allows for smooth downlink user data processing in both the CU and UE during beam / TRP handovers.

[0454] Alternatively, as described above, the UE can invalidate the CQI / CSI transmission request. In this case, the CU can retransmit the CQI / CSI transmission request to the UE via the Mobile Target Beam / TRP. Thus, the CU can perform scheduling adapted to the transmission status after beam / TRP switching.

[0455] During CQI / CSI transmission from the UE to the CU, the CU can invalidate CQI / CSI received by the mobile source beam / TRP. This invalidation can occur after a beam / TRP handover following the CQI / CSI transmission from the UE to the CU. The CU can notify the UE of the CQI / CSI transmission request via the mobile target beam / TRP. This notification can be used for aperiodic CQI / CSI. This allows the CU to communicate with the UE using a downlink communication rate that accurately reflects the beam / TRP handover.

[0456] By using this variation 3, the same effect as in embodiment 3 can be achieved in notifying the UE of RRC parameters related to CQI / CSI.

[0457] Implementation method 4.

[0458] Unlike implementation 2, for example, when the CU has PDCP and the DU has RLC, MAC and PHY, or when the CU has PDCP and H-RLC and the DU has L-RLC, MAC and PHY, RRC parameters can be notified using RRC signaling during inter-beam movement or inter-TRP movement within the cell.

[0459] However, beamforming is used in NR, so beam / TRP movement within the cell occurs frequently. Therefore, there is a problem of frequent RRC signaling, leading to reduced communication efficiency.

[0460] This embodiment 4 discloses a method for solving the above-mentioned problems.

[0461] Similar to Implementation 2, the CU notifies the UE in advance of the RRC parameters used by the beam or TRP (hereinafter sometimes referred to as beam / TRP) within the cell. The CU can perform this notification using RRC signaling. During beam / TRP handover, the CU notifies the UE of a beam / TRP handover indication. This handover indication may include an identifier representing the moving target beam / TRP. The CU can notify the UE of this handover indication using L1 / L2 signaling or MAC signaling. Thus, the CU can implement parameter changes accompanying beam / TRP handover with less signaling.

[0462] Similar to implementation method 2, the RRC parameters included in this notification can be parameters near the beam / TRP where the UE is located. These nearby beams / TRPs can include those adjacent to the beam / TRP where the UE is located. Furthermore, the RRC parameters included in this notification can also consist only of parameters different from those used by the beam / TRP where the UE is located. This reduces the size of the notification.

[0463] Other methods were also disclosed. During beam or TRP handover, the CU notifies the UE of the RRC parameters used by the mobile target beam / TRP via the mobile source beam / TRP. This notification can be made between the CU and the mobile source beam / TRP using the CU-DU inter-interface. Furthermore, the notification between the mobile source beam / TRP and the UE can use L1 / L2 signaling or MAC signaling.

[0464] As described above, L1 / L2 signaling is used to notify the UE, enabling rapid parameter notification. Furthermore, by using MAC signaling, multi-level modulation is possible, allowing parameter notification with a smaller number of symbols. Additionally, HARQ retransmission control is implemented, thus improving the reliability of parameter notification.

[0465] The CU can notify the UE of RRC parameters along with the handover indication. This reduces the signaling load during beam / TRP handover.

[0466] Alternatively, the CU can notify the UE of the handover indication after the RRC parameters are notified. Thus, the CU can notify the UE of the handover indication after the RRC parameters are confirmed to have been delivered. Therefore, it can avoid situations such as the failure to deliver the SR from the UE due to the failure to deliver RRC parameters related to the SR, and the execution of random access due to exceeding the retransmission limit.

[0467] Alternatively, the CU can notify the UE of the RRC parameters after receiving the handover indication. In this case, the CU can notify the UE of the handover indication along with the handover timing. Therefore, even if the processing of switching the communication target's beam / TRP in the UE takes time, the handover can proceed smoothly.

[0468] The mobile source TRP can notify the CU that the parameters have been acknowledged. This notification can be made during MAC signaling when parameters are notified. The CU can then use this information to notify the UE of the handover instruction. This prevents handover instruction notifications when parameters have not been delivered, thus preventing random access caused by factors such as a missed SR from the UE or exceeding the retransmission limit.

[0469] The RRC parameters can be the same as those shown in Section 6.3.2 of Non-Patent Document 12, as in Embodiment 1. The RRC parameters can be, for example, parameters related to SR, parameters related to Ack / Nack repetition, parameters related to the Sounding Reference Signal (SRS), or parameters related to CQI / CSI.

[0470] Similar to Embodiment 2, the CU can notify the UE of the parameters required for beam scanning. The parameters required for beam scanning can be set to the parameters shown in Embodiment 1. This notification can be made via the mobile source beam / TRP. The parameters required for beam scanning can be set to the parameters in the mobile target beam / TRP. Therefore, the UE can easily receive beam scanning signals moving between beams / TRPs.

[0471] Similar to implementation 2, the CU notifies the UE of a beam / TRP handover indication (hereinafter sometimes simply referred to as "handover indication") via the mobile source beam / TRP. The handover indication may or may not include an identifier representing the mobile target beam / TRP. In addition, the handover indication may include information indicating the time of beam / TRP handover.

[0472] The handover indication notification from the CU to the UE can be delivered using either L1 / L2 signaling or MAC signaling. As described above, using L1 / L2 signaling to notify the UE allows for rapid notification of the handover indication. Furthermore, using MAC signaling enables multi-level modulation, thus allowing for handover indication notification with fewer symbol numbers. Additionally, HARQ retransmission control improves the reliability of the handover indication notification.

[0473] The mobile source TRP can notify the CU that the handover indication has been acknowledged. This notification can be made when MAC signaling is used to notify the handover indication. The CU can then use this information to switch beams / TRPs. This prevents beam / TRP switching when the handover indication has not been delivered, thus avoiding RLF (Redirect Life Failure) due to link loss with the gNB.

[0474] The RRC parameters related to SR mentioned above can be (1) to (3) disclosed in Implementation 2. The CU can notify the UE of the parameter representing the maximum number of retransmissions of SR as the RRC parameter related to SR, or it can choose not to notify it. Thus, the same effect as in Implementation 2 can be obtained.

[0475] Similar to implementation method 2, the CU can simultaneously notify the UE of multiple parameters in the RRC parameters. This reduces the signaling amount required for notification.

[0476] Similar to implementation method 2, the CU can notify the RRC parameters to the UE separately. Therefore, the parameters can be notified even with limited transmission resources.

[0477] The CU can notify the Mobile Target Beam / TRP of the RRC parameters. Similar to Embodiment 1, this notification can use, for example, a region of the control word CPRI, and can use the ASN.1 format or other formats. Therefore, in addition to the same effects as Embodiment 1, for example, the Mobile Target Beam / TRP can quickly decode the uplink user data from the UE immediately after a beam / TRP handover.

[0478] Similar to implementation 2, regarding RRC parameters, the CU may not need to notify the use of parameters with the same values ​​in the Moving Target Beam / TRP. Therefore, the signaling volume generated by parameter notification can be reduced.

[0479] Similar to implementation 2, the CU may include an identifier indicating a parameter change resulting from a TRP / beam switch in its notification of RRC parameters to the UE. The UE can retain the RRC parameters before the change. Thus, for example, the UE can prevent the SR from failing to reach the mobile source TRP / beam due to the aforementioned parameter change during SR transmission before the TRP / beam switch.

[0480] The CU and UE can either restore the RRC parameter values ​​to their initial values ​​or retain them during beam / TRP handover. The initial values ​​of the RRC parameters can be determined by the standard or notified from the CU to the UE via RRC signaling. Whether to restore or retain the parameter values ​​during beam / TRP handover can be determined by the standard or notified to the UE in advance by the CU. Alternatively, the information regarding whether to restore or retain the initial values ​​can be notified from the CU to the UE along with the handover indication. Therefore, even if parameter notification from the mobile source beam / TRP to the UE fails, the UE can still use the previous RRC parameters. Thus, for example, if the same RRC parameters as the mobile source beam / TRP are used in the mobile target beam / TRP, the UE can prevent situations where the SR (Signal Request) is not delivered to the mobile target beam / TRP.

[0481] Similar to Implementation 2, the CU can switch the beam / TRP when the handover indication from the mobile source beam / TRP to the UE exceeds the HARQ retransmission count, or it can choose not to switch the beam / TRP. For all cases, the same effect as in Implementation 2 can be achieved.

[0482] Figure 11 This is a flowchart illustrating the beam / TRP switching when the CU notifies the SR-related parameters via the mobile source beam / TRP. Figure 11 This example demonstrates how MAC signaling is used to notify the UE of SR-related parameters and handover instructions from the CU. Figure 11 In this context, the mobile source beam / TRP under the CU is denoted as S-beam / TRP, and the mobile target beam / TRP under the CU is denoted as T-beam / TRP. Furthermore, Figure 11 In the diagram, the black circle within the arrow represents the beam / TRP used for communication. (This is related to...) Figure 9 Identical steps are labeled with the same step number, and common descriptions are omitted.

[0483] Figure 11 In step ST3001, the CU notifies the SR parameters to be notified to the UE via the S-beam / TRP. The parameter notification can use the CU-DU inter-interface. In step ST3002, the S-beam / TRP notifies the UE of the aforementioned parameters. The parameter notification from the S-beam / TRP to the UE uses MAC signaling. L1 / L2 signaling can also be used. In step ST3003, the UE notifies the S-beam / TRP of the Ack notification for the SR parameters. The Ack notification can use uplink control signals.

[0484] Figure 11 In step ST3004, the CU notifies the UE of the handover indication via the S-beam / TRP. The handover indication notification can be sent using the CU-DU inter-interface. In step ST3005, the S-beam / TRP notifies the UE of the handover indication. The handover indication notification from the S-beam / TRP to the UE uses MAC signaling. L1 / L2 signaling can also be used. In step ST3006, the UE notifies the S-beam / TRP of an Ack response to the handover indication. If the received result from the UE is Nack, the CU can retransmit the handover indication via the S-beam / TRP.

[0485] Similar to implementation method 2, the UE can send uplink signals to the beam / TRP of the mobile source. The uplink signal can be a response to L1 / L2 signaling in response to parameter notification from the CU. Alternatively, it can be a response to L1 / L2 signaling in response to a handover indication from the CU. New L1 / L2 signaling for the response can be set as the uplink signal. New uplink control information (UCI) can be set as the aforementioned response. Therefore, even if L1 / L2 signaling is used in parameter notification or handover indication from the CU, the CU can still confirm delivery to the UE. This improves the reliability of the aforementioned L1 / L2 signaling.

[0486] The new UCI can be set to be the same as in Implementation Method 2. Therefore, the same effect as in Implementation Method 2 can be obtained.

[0487] In the above description, the mobile source beam / TRP can notify the CU that it has received the aforementioned response via L1 / L2 signaling. Therefore, the CU can ascertain that the UE has correctly received the parameter notification or handover instruction, thus enabling a smooth beam / TRP handover.

[0488] Regarding the RRC parameter notification from the CU to the UE using MAC signaling, the mobile source beam / TRP can notify the CU that it has received an Ack message for the RRC parameter notification. The CU can then use this notification to switch the beam / TRP in use. Thus, the CU can ascertain that the UE has correctly received the RRC parameter notification, thereby enabling a smooth beam / TRP handover.

[0489] Regarding the handover indication notification from the CU to the UE using MAC signaling, the mobile source beam / TRP can notify the CU that an Ack message has been received regarding the handover indication notification. The CU can then use this notification information to switch the beam / TRP in use. Thus, the CU can ascertain that the UE has correctly received the handover indication, thereby enabling a smooth beam / TRP handover.

[0490] Similar to implementation method 2, the UE can send an uplink signal to the beam / TRP of the mobile target. The uplink signal can be set as an acknowledgment signal for beam / TRP switching in the UE. The frequency resources of the SR can be used to send the acknowledgment signal. Alternatively, the SR can be sent as the acknowledgment signal. Therefore, even if L1 / L2 signaling is used in the handover indication from the CU, the CU can still send an acknowledgment to the UE. This improves the reliability of the aforementioned L1 / L2 signaling.

[0491] In the above scenario, the UE can send SRs with a minimum cycle time. This allows for low-latency confirmation that the UE has switched the beam / TRP of the communication target.

[0492] In the above, the CU can ensure shared SR resources for UEs existing within the coverage area of ​​the same beam / TRP. UEs can utilize these shared SR resources for SR transmission. These shared SR resources can be contention-based resources that allow UEs to compete for them. The location of the shared SR resources can be predetermined by the standard or notified to subordinate UEs by the CU. This notification can be broadcast or a UE-specific notification. The UE-specific notification mentioned above can be RRC-specific signaling. Therefore, even if RRC parameter reception fails, the UE can still notify the CU that a beam / TRP handover has occurred.

[0493] Similar to Implementation Method 2, the UE can set the location of the SR shared resource to the initial value of the SR-related RRC parameters during the aforementioned communication target beam / TRP handover. Therefore, even if RRC parameter reception fails, the UE can still notify the CU that a beam / TRP handover has occurred.

[0494] The UE described above can also send SRS to the mobile target's beam / TRP. The SRS can be either aperiodic or periodic. The UE can send a predetermined number of SRS to the mobile target's beam / TRP. This number of transmissions can be determined by the standard or can be notified to the UE in advance by the CU. This notification can be made using RRC signaling. Therefore, even without uplink user data being sent to the CU, the UE can notify the CU that a communication target beam / TRP handover has occurred.

[0495] Similar to implementation method 2, the CU can use the aforementioned SR to determine whether the UE is switching communication target beams / TRPs. For example, if there is no SR notification from the UE, the CU can determine that the UE is not switching communication target beams / TRPs. The CU can then re-notify the parameters and handover indication from the mobile source beam / TRP. This re-notification can be performed using the aforementioned determination result. Therefore, for example, it is possible to prevent RLF or random access due to the UE's failure to receive parameters or handover indications related to the SR. This also shortens the beam / TRP handover time.

[0496] Similar to implementation method 2, the CU can notify the UE of parameters multiple times. Furthermore, the CU can increase the transmission power of the parameter notification to the UE. This improves the reliability of parameter notification. The number of parameter notifications can be determined by a standard or can be pre-notified to the UE by the CU. This notification can be performed using RRC signaling.

[0497] Similar to implementation method 2, the handover indication notification to the UE can be sent multiple times, just like the parameter notification, and the power can also be increased. This improves the reliability of the handover indication notification.

[0498] Similar to Implementation Method 2, the UE can perform beam switching of the communication target using notifications of parameters received from the CU. Beam switching can be accompanied by beam scanning and random access. Beam switching can be performed using the reception of one or more parameters. Beam switching can be performed after a predetermined time has elapsed after the UE receives one or more parameters. The predetermined time can be determined by a standard or can be notified to the UE in advance by the CU. This notification can be performed using RRC signaling. Therefore, even if the UE cannot correctly receive the handover instruction from the CU to the UE, the UE can still switch the beam of the communication target. Furthermore, the time required for retransmitting the handover notification from the CU to the UE is eliminated.

[0499] For SR transmissions from the UE, the CU can invalidate SRs received by the mobile source beam / TRP. The CU can invalidate SRs when a beam / TRP handover occurs between SR reception and uplink scheduling clearance transmission. In the above scenario, the UE can retransmit the SR to the mobile target beam / TRP. This prevents retransmitted SRs from the UE from failing to reach the CU.

[0500] Alternatively, regarding the beam / TRP handover following the SR transmission from the UE, the CU can validate the SR received by the mobile source beam / TRP. The mobile source beam / TRP can then forward the SR to the mobile target beam / TRP. This forwarding can be done via the CU. The SR can be replaced with information indicating that it has been received. Therefore, even if a beam / TRP handover occurs between SR reception and uplink scheduling clearance transmission, the UE can smoothly perform a series of processes including SR transmission, uplink scheduling clearance reception, and uplink user data transmission.

[0501] Regarding uplink scheduling grant notifications from the CU to the UE, the CU and UE can invalidate uplink scheduling grants transmitted from the mobile source beam / TRP. When a beam / TRP handover occurs between uplink scheduling grants and uplink user data, the CU and UE can invalidate the uplink scheduling grant. In the above, the mobile target beam / TRP can retransmit the uplink scheduling grant to the UE. In the above retransmission of uplink scheduling grants, the mobile source beam / TRP can request the mobile target beam / TRP to retransmit the uplink scheduling grant to the UE. Alternatively, the UE can restart SR transmission to the mobile target beam / TRP. In the above, whether the UE restarts SR transmission is determined by the standard. Alternatively, the CU can notify the UE. The above notification can be performed in advance via RRC signaling, MAC signaling, or L1 / L2 signaling. In examples where the above notification is performed using MAC signaling or L1 / L2 signaling, the notification can be performed together with the handover notification. Therefore, the UE can receive uplink scheduling permission corresponding to the uplink resource usage status of the Mobile Target Beam / TRP used for uplink user data transmission.

[0502] Alternatively, regarding the aforementioned handover from the mobile source beam / TRP to the beam / TRP after notifying the UE of the uplink scheduling permission, the CU and UE can make the uplink scheduling permission sent from the mobile source beam / TRP valid. The mobile source beam / TRP can notify the mobile target beam / TRP of the information regarding the uplink scheduling permission. The UE can use the uplink scheduling permission to send uplink user data to the mobile target beam / TRP. This reduces the signaling volume between the CU and the UE.

[0503] Whether the uplink scheduling permission is enabled can be determined by the standard, or it can be notified from the CU to the UE. The notification from the gNB to the UE can be pre-processed via RRC signaling, MAC signaling, or L1 / L2 signaling. As an example of enabling the uplink scheduling permission, it can be set up so that the mobile target beam / TRP can use the uplink resources indicated by the scheduling permission for the UE. The mobile source beam / TRP can notify the mobile target beam / TRP of the uplink scheduling permission information. Therefore, the mobile target beam / TRP can determine whether the uplink scheduling permission is enabled or disabled, thus enabling flexible scheduling.

[0504] In examples where the above notification is delivered using MAC signaling or L1 / L2 signaling, the notification can be delivered together with the handover notification. Thus, the CU can perform scheduling corresponding to uplink resource usage in the Mobile Target Beam / TRP with less signaling.

[0505] For uplink user data transmission from the UE to the CU, the mobile target beam / TRP can send an Ack / Nack from the mobile source beam / TRP to the UE for the uplink user data received from the UE. This Ack / Nack transmission from the mobile target beam / TRP to the UE can occur during beam / TRP handover between uplink user data transmission from the UE and the Ack / Nack notification for the uplink user data. In this context, the mobile source beam / TRP can notify the mobile target beam / TRP of the Ack / Nack information for the uplink user data. This allows for a smooth beam / TRP handover after uplink user data transmission.

[0506] The Mobile Source Beam (TRP) can notify the Mobile Target Beam (TRP) of information related to the decoding results of uplink user data received from the UE. This information may, for example, be the soft decision value of the uplink user data. Thus, the Mobile Target Beam (TRP) can synthesize and decode the initial reception and retransmission reception results of the uplink user data. This reduces the probability of reception errors.

[0507] According to this embodiment 4, when the CU has PDCP and the DU has RLC, MAC, and PHY, or when the CU has PDCP and H-RLC and the DU has L-RLC, MAC, and PHY, the same effect as in embodiment 2 can be obtained. In the above cases, the signaling volume between beams / TRPs can be reduced.

[0508] In Implementation 4, a base station apparatus with separate CU and DU is shown as an example, but it can also be applied to base station apparatuses where CU and DU are not separated. This base station apparatus can be one that does not share RRC parameters between beams. Furthermore, this base station apparatus can be, for example, a base station that performs different HARQ scheduling for each beam, a base station with different RLC layers for each beam, or a base station combining both. When applying Implementation 4 to this base station apparatus, the CU can be replaced with a gNB. Therefore, during inter-beam movement within a cell, RRC parameters can be notified to the UE from the gNB via the mobile source beam, increasing the number of UEs that can be accommodated in spatially separated cells due to beam separation. Parameters can be quickly notified to the UE from the gNB.

[0509] In Embodiment 4, a base station apparatus that notifies the UE of RRC parameters by a mobile source beam / TRP is shown as an example, but other beam / TRPs can also be used to notify the RRC parameters. These other beam / TRPs could be, for example, beam / TRPs for transmitting control information. Therefore, in a base station apparatus that has beam / TRPs for both user data transmission and control information transmission, RRC parameters can be notified using less signaling, thus enabling rapid notification of RRC parameters during beam movement.

[0510] According to Embodiment 4, a communication system is provided similarly to Embodiment 2. This system includes, for example, a communication terminal device and a base station device for wireless communication with the communication terminal device using wireless beams. A cell formed by the base station device is spatially separated by multiple wireless beams belonging to the base station device. When the communication terminal device moves from the coverage area of ​​the first wireless beam to the coverage area of ​​the second wireless beam, the base station device changes the RRC (Radio Resource Control) parameters used by the communication terminal device from the first RRC parameters used for the first wireless beam to the second RRC parameters used for the second wireless beam. Furthermore, the multiple wireless beams can be configured as follows: Figure 8 As illustrated, it can be formed by multiple DUs (in other words, TRPs), or by a single DU, or by a base station device that integrates CU and DU.

[0511] According to this structure, the RRC parameters used by the communication terminal device can be changed based on the change in the wireless beam used by the communication terminal device. Therefore, the number of communication terminal devices that can be accommodated can be increased as described above.

[0512] Here, the above structure can be modified in various ways as described above. Specifically, according to embodiment 4, for example, a communication system is provided where: a base station device includes at least one DU (Distributed Unit) that outputs multiple wireless beams and a CU (Central Unit) that controls at least one DU; the at least one DU has a MAC (Medium Access Control) function; the CU notifies a communication terminal device of a second RRC parameter via a first wireless beam and using L1 / L2 signaling or MAC signaling; and notifies the communication terminal device of a switching indication from the first wireless beam to the second wireless beam via the first wireless beam and using L1 / L2 signaling or MAC signaling. In the above, the DU may have an RLC (Radio Link Control) function. Alternatively, as another example, a communication system is provided where: the base station device has the function of outputting multiple wireless beams and a MAC function; the base station device notifies the communication terminal device of the second RRC parameter; and notifies the communication terminal device of a switching indication from the first wireless beam to the second wireless beam via the first wireless beam.

[0513] Furthermore, various modifications are provided as described in the following modifications 1 to 4.

[0514] Variation 1 of Implementation Method 4.

[0515] In Implementation 4, the description focuses on the notification of RRC parameters related to SR, but it can also be applied to RRC parameters related to Ack / Nack repetition.

[0516] The RRC parameters related to the repetition of Ack / Nack mentioned above can be the same as those in Variation 1 of Implementation 2.

[0517] In this variation 1, the method and content of the handover notification from the CU to the UE via the forward beam / TRP can be set to be the same as in embodiment 4. Furthermore, the method for the CU to notify the UE of RRC parameters related to Ack / Nack repetition via the forward beam / TRP can be the same as the RRC parameter notification method described in embodiment 4. Thus, the same effect as in embodiment 4 can be obtained.

[0518] Similar to embodiment 4, the CU can notify the UE of the parameters required for beam scanning. The method of notifying the parameters can be the same as in embodiment 4. Therefore, the UE can easily receive beam scanning signals moving between beams / TRPs.

[0519] The notification of parameters required for beam scanning from the CU to the UE described above can be achieved using L1 / L2 signaling or MAC signaling. This achieves the same effect as in Implementation Method 4.

[0520] Similar to implementation method 4, the CU may include an identifier indicating a parameter change caused by a TRP / beam switch in its notification to the UE regarding the RRC parameters related to Ack / Nack repetition. The UE can retain the RRC parameters related to Ack / Nack repetition before the change. Therefore, the UE can prevent a decrease in the reliability of Ack / Nack transmission to the mobile source TRP / beam due to parameter changes during Ack / Nack transmission before the TRP / beam switch.

[0521] Similar to implementation 4, regarding the RRC parameters related to Ack / Nack repetition, the CU may not notify parameters that also use the same values ​​in the Moving Target Beam / TRP. Therefore, the signaling load generated by parameter notification can be reduced.

[0522] Similar to Implementation 4, the CU and UE can either restore the values ​​of the RRC parameters related to Ack / Nack repetition to their initial values ​​or retain them during beam / TRP handover of the UE. The initial values ​​of the RRC parameters can be determined by the standard or communicated to the UE in advance via RRC signaling. Whether to restore or retain the parameter values ​​during beam / TRP handover can be determined by the standard or communicated to the UE in advance via the CU. Alternatively, the information regarding whether to restore or retain the initial values ​​can be communicated to the UE via the handover instruction. This achieves the same effect as Implementation 4.

[0523] Similar to implementation 4, the CU can notify the UE of the RRC parameters related to Ack / Nack repetition along with the handover indication. This reduces the signaling load during beam / TRP handover.

[0524] Alternatively, the CU can notify the UE of the handover indication after receiving notification of the RRC parameters related to repeated Ack / Nack. This avoids the UE applying parameters from before the change after beam / TRP handover, and prevents situations where repeated Ack / Nack from the UE is not delivered, or where the reliability of the Ack / Nack notification is reduced due to repeated Ack / Nack from the UE not being delivered.

[0525] Alternatively, the CU can notify the UE of the RRC parameters related to Ack / Nack repetition after the handover indication is sent. In this case, the CU can notify the UE of the handover indication along with the handover timing. Therefore, even if the processing of switching the communication target's beam / TRP in the UE takes time, the handover can proceed smoothly.

[0526] The CU can use L1 / L2 signaling to notify the UE of the aforementioned RRC parameters related to Ack / Nack repetition. This allows for rapid notification of the parameters to the UE.

[0527] Alternatively, the CU can use MAC signaling to notify the aforementioned RRC parameters related to Ack / Nack repetition. This enables multi-level modulation and parameter notification with a smaller number of symbols. Furthermore, HARQ retransmission control is implemented, thus improving the reliability of parameter notification.

[0528] Similar to implementation method 4, the mobile source TRP can notify the CU of information indicating that parameter acknowledgment has been delivered. This notification can be made when MAC signaling is used to notify the parameters. The CU can then use this information to notify the UE of a handover instruction. This avoids repeated Ack / Nack failures from the UE due to parameter non-delivery, thus improving the reliability of Ack / Nack transmission.

[0529] Regarding handover notification, similar to implementation method 4, the notification can be sent from the CU to the UE using L1 / L2 signaling or MAC signaling. This achieves the same effect as implementation method 4.

[0530] As an example of the process for RRC parameter notification and switching indication related to Ack / Nack repetition, Figure 11 The parameters related to SR in steps ST3001 and ST3002 can be replaced with parameters related to Ack / Nack repetition.

[0531] Similar to implementation method 4, the CU can send multiple notifications of parameters related to Ack / Nack repetition to the UE, thereby increasing the transmission power. This improves the reliability of parameter notifications. The same applies to handover indications from the CU to the UE.

[0532] For both the mobile source beam / TRP and the mobile target beam / TRP, the UE may not need to notify the UE of the Ack / Nack response for downlink user data received from the CU via the mobile source beam / TRP. This UE action can be performed during beam / TRP handover between downlink user data and Ack / Nack. The mobile source beam / TRP can then forward the downlink user data to the mobile target beam / TRP. The mobile target beam / TRP can then forward the downlink user data to the UE. This prevents downlink user data loss due to beam / TRP handover.

[0533] As another example, the UE can notify the mobile target beam / TRP of the Ack / Nack response to downlink user data received from the CU from the mobile source beam / TRP. This Ack / Nack notification can occur during a beam / TRP handover between downlink user data and the Ack / Nack response. The mobile target beam / TRP can then notify the mobile source beam / TRP of the Ack / Nack reception result. This reduces the signaling volume related to downlink user data during beam / TRP handover.

[0534] In the above description, the mobile source beam / TRP can forward the downlink user data to the mobile target beam / TRP. This forwarding can occur when a Nack notification is received from the UE regarding downlink user data. The mobile target beam / TRP can then use the forwarded downlink user data to retransmit to the UE. This ensures smooth retransmission of downlink user data during beam / TRP handover.

[0535] Regarding the determination of Ack / Nack received from the UE, the mobile source beam / TRP can either utilize only the received results from its own beam / TRP or utilize the received results from the mobile target beam / TRP as well. The mobile target beam / TRP can forward the Ack / Nack received from the UE to the mobile source beam / TRP. This action can be performed when switching beam / TRPs between Ack / Nack repetitions from the UE to the mobile source beam / TRP. By utilizing only the received results from the mobile source beam / TRP, the reception of Ack / Nack repetitions from the UE can be performed quickly. By utilizing the received results from the mobile target beam / TRP as well, the reliability of Ack / Nack repetitions in the mobile source beam / TRP can be improved. Whether the mobile source beam / TRP utilizes only the received results from its own beam / TRP or utilizes the received results from the mobile target beam / TRP as well can be determined by the standard or appropriately switched by the CU. By appropriately switching the receiver via the CU, the appropriate receiving action can be selected, for example, based on the transmission status in the mobile source beam / TRP, thus improving the flexibility of receiving Ack / Nack repetitions in the gNB.

[0536] In the above, the mobile target beam / TRP can replace the mobile source beam / TRP for Ack / Nack repetition reception processing. The mobile target beam / TRP can utilize only the reception results from its own beam / TRP, or it can utilize the reception results from the mobile source beam / TRP together. The mobile source beam / TRP can forward the Ack / Nack reception results from the UE to the mobile target beam / TRP. Thus, the same effect as described above can be achieved. Whether the mobile target beam / TRP utilizes only the reception results from its own beam / TRP or utilizes the reception results from the mobile source beam / TRP together can be determined by the standard, or it can be switched appropriately by the CU.

[0537] Which of the mobile source beam / TRP or the mobile target beam / TRP performs the Ack / Nack reception, as described above, can be determined by the standard or predetermined by the CU. This prevents malfunctions caused by inconsistencies in the Ack / Nack reception results between the mobile source beam / TRP and the mobile target beam / TRP.

[0538] The mobile target beam / TRP can retransmit downlink user data to the UE using Ack / Nack repeats sent from the UE to the mobile source beam / TRP. This retransmission can occur when a beam / TRP handover occurs between the Ack / Nack repeats from the UE to the mobile source beam / TRP and the retransmission of downlink user data to the UE. The mobile source beam / TRP can then forward the retransmitted data to the mobile target beam / TRP. This ensures smooth downlink user data retransmission processing during beam / TRP handover.

[0539] By using this variation 1, the notification to the UE regarding the RRC parameters related to Ack / Nack repetition can achieve the same effect as in embodiment 4.

[0540] Variation 2 of Implementation Method 4.

[0541] In Implementation 4, the description focuses on the notification of RRC parameters related to SR, but it can also be applied to RRC parameters related to SRS.

[0542] The RRC parameters related to SRS mentioned above can be the same as those in Variation 2 of Embodiment 2.

[0543] In this variation 2, the method and content of the handover notification from the CU to the UE via the forward beam / TRP can be set to be the same as in embodiment 4. Furthermore, the method by which the CU notifies the UE of the RRC parameters related to the SRS via the forward beam / TRP can be the same as the RRC parameter notification method described in embodiment 4. Thus, the same effect as in embodiment 4 can be obtained.

[0544] Similar to embodiment 4, the CU can notify the UE of the parameters required for beam scanning. The method of notifying the parameters can be the same as in embodiment 4. Therefore, the UE can easily receive beam scanning signals moving between beams / TRPs.

[0545] The notification of parameters required for beam scanning from the CU to the UE described above can be achieved using L1 / L2 signaling or MAC signaling. This achieves the same effect as in Implementation Method 4.

[0546] Similar to implementation method 4, the CU may include an identifier indicating parameter switching caused by TRP / beam switching in its notification to the UE regarding the RRC parameters related to SRS. The UE can retain the RRC parameters related to SRS before the change. Thus, the UE can prevent random access operations and uplink communication rate degradation due to SRS not being delivered during SRS transmission before TRP / beam switching.

[0547] Similar to implementation 4, regarding the RRC parameters related to SRS, the CU may not need to notify parameters that also use the same values ​​in the Moving Target Beam / TRP. Therefore, the signaling volume generated by parameter notification can be reduced.

[0548] Similar to Implementation 4, the CU and UE can either restore the values ​​of the RRC parameters related to SRS to their initial values ​​or maintain them during beam / TRP handover of the UE. The initial values ​​of the RRC parameters can be determined by the standard or notified to the UE from the CU via RRC signaling. Whether to restore or maintain the parameter values ​​during beam / TRP handover can be determined by the standard or notified to the UE in advance from the CU. Alternatively, the information regarding whether to restore or maintain the initial values ​​can be notified to the UE from the CU along with the handover indication. Thus, the same effect as in Implementation 4 can be achieved.

[0549] Similar to implementation method 4, the CU can notify the UE of the RRC parameters related to the SRS along with the handover indication. This reduces the signaling load during beam / TRP handover.

[0550] Alternatively, the CU can notify the UE of the handover indication after receiving notification of the RRC parameters related to the SRS. This avoids applying the previous SRS-related RRC parameters to the UE after beam / TRP handover, thus preventing SRS from being missed from the UE and avoiding random access actions and uplink communication rate reductions caused by the SRS being missed from the UE.

[0551] Alternatively, the CU can notify the UE of the RRC parameters related to the SRS after receiving the handover indication. In this case, the CU can notify the UE of the handover indication along with the handover timing. Therefore, even if the processing of switching the communication target's beam / TRP in the UE takes time, the handover can proceed smoothly.

[0552] The CU can use L1 / L2 signaling to notify the UE of the aforementioned SRS-related RRC parameters. This allows for rapid notification of the parameters to the UE.

[0553] Alternatively, the CU can use MAC signaling to notify the aforementioned SRS-related RRC parameters. This enables multi-level modulation and parameter notification with a smaller number of symbols. Furthermore, HARQ retransmission control is implemented, thus improving the reliability of parameter notification.

[0554] Similar to implementation method 4, the mobile source TRP can notify the CU of information indicating that parameter confirmation has been delivered. This notification can be made when MAC signaling is used to notify the parameters. The CU can then use this information to notify the UE of a handover instruction. This avoids SRS failure from the UE due to parameter non-delivery, preventing random access operations and uplink communication rate degradation.

[0555] Regarding handover notification, similar to implementation method 4, the notification can be sent from the CU to the UE using L1 / L2 signaling or MAC signaling. This achieves the same effect as implementation method 4.

[0556] As an example of the process for notifying RRC parameters and providing handover instructions related to SRS, Figure 11 The parameters related to SR in steps ST3001 and ST3002 can be replaced with parameters related to SRS.

[0557] Similar to implementation method 4, the CU can send multiple notifications of SRS-related parameters to the UE, thereby increasing the transmission power. This improves the reliability of parameter notifications. The same applies to handover indications from the CU to the UE.

[0558] The UE can transmit an SRS (Signal Transmission) to the Mobile Target Beam / TRP in response to an SRS transmission instruction received from the Mobile Source Beam / TRP. This SRS transmission from the UE to the Mobile Target Beam / TRP can occur during beam / TRP handover between the SRS transmission instruction and the actual SRS transmission. The SRS transmission can be aperiodic. The Mobile Source Beam / TRP can notify the Mobile Target Beam / TRP that it has indicated an SRS transmission to the UE. Therefore, SRS transmission processing during beam / TRP handover can be performed smoothly in both the CU and the UE.

[0559] In the above, the UE can invalidate the SRS transmission indication received from the mobile source beam / TRP. This reduces signaling from the mobile source beam / TRP to the mobile target beam / TRP.

[0560] The mobile source beam / TRP can invalidate the SRS transmitted from the UE to this beam. Invalidating the SRS can be performed after the beam / TRP has been switched following the SRS transmission. Therefore, the mobile target beam / TRP can perform scheduling adapted to the transmission status after the beam / TRP switch.

[0561] By using this variation 2, the same effect as in embodiment 4 can be achieved in notifying the UE of RRC parameters related to SRS.

[0562] Variation 3 of Implementation Method 4.

[0563] In Implementation 4, the description focuses on notification of RRC parameters related to SR, but it can also be applied to RRC parameters related to CQI / CSI.

[0564] The RRC parameters related to CQI / CSI mentioned above can be the same as those in variation 3 of embodiment 2.

[0565] In this variation 3, the method and content of the handover notification from the CU to the UE via the forward beam / TRP can be set to be the same as in embodiment 4. Furthermore, the method by which the CU notifies the UE of RRC parameters related to CQI / CSI via the forward beam / TRP can be the same as the RRC parameter notification method described in embodiment 4. Thus, the same effect as in embodiment 4 can be obtained.

[0566] Similar to embodiment 4, the CU can notify the UE of the parameters required for beam scanning. The method of notifying the parameters can be the same as in embodiment 4. Therefore, the UE can easily receive beam scanning signals moving between beams / TRPs.

[0567] The notification of parameters required for beam scanning from the CU to the UE described above can be achieved using L1 / L2 signaling or MAC signaling. This achieves the same effect as in Implementation Method 4.

[0568] Similar to implementation method 4, the CU may include an identifier indicating the parameter switching caused by the TRP / beam switching in its notification to the UE regarding the RRC parameters related to CQI / CSI. The UE can retain the RRC parameters related to CQI / CSI before the change. Thus, the UE can prevent downlink communication rate degradation due to CQI / CSI not being delivered during CQI / CSI transmission before the TRP / beam switching.

[0569] Similar to implementation 4, the CU may also omit notifying parameters related to CQI / CSI that use the same values ​​in the Moving Target Beam / TRP. Therefore, the signaling load generated by parameter notification can be reduced.

[0570] The CU and UE can either restore the values ​​of the RRC parameters related to CQI / CSI to their initial values ​​or maintain them during UE beam / TRP handover. The initial values ​​of the RRC parameters can be determined by the standard or notified to the UE from the CU via RRC signaling. Whether to restore the parameter values ​​to their initial values ​​or maintain them during UE beam / TRP handover can be determined by the standard or notified to the UE in advance from the CU. Alternatively, the information on whether to restore the initial values ​​or maintain them can be notified to the UE from the CU along with the handover indication. This achieves the same effect as in implementation method 4.

[0571] Similar to implementation method 4, the CU can notify the UE of the RRC parameters related to CQI / CSI along with the handover indication. This reduces the signaling load during beam / TRP handover.

[0572] Alternatively, the CU can notify the UE of the handover indication after receiving notification of the RRC parameters related to CQI / CSI. This avoids applying the previous RRC parameters related to CQI / CSI to the UE after beam / TRP handover, and avoids the failure to deliver CQI / CSI from the UE and the resulting reduction in downlink communication rate.

[0573] Alternatively, the CU can notify the UE of the RRC parameters related to CQI / CSI after receiving the handover indication. In this case, the CU can notify the UE of the handover indication along with the handover timing. Therefore, even if the processing of switching the communication target's beam / TRP in the UE takes time, the handover can proceed smoothly.

[0574] The CU can use L1 / L2 signaling to notify the UE of the aforementioned RRC parameters related to CQI / CSI. This allows for rapid notification of the parameters to the UE.

[0575] Alternatively, the CU can use MAC signaling to notify the aforementioned CQI / CSI-related RRC parameters. This enables multi-level modulation and parameter notification with a smaller number of symbols. Furthermore, HARQ retransmission control is implemented, thus improving the reliability of parameter notification.

[0576] Similar to implementation method 4, the mobile source TRP can notify the CU of information indicating that parameter confirmation has been delivered. This notification can be made when MAC signaling is used to notify the parameters. The CU can then use this information to notify the UE of a handover instruction. This avoids the possibility of CQI / CSI failure from the UE due to parameter non-delivery, and prevents a reduction in downlink communication speed.

[0577] Regarding handover notification, similar to implementation method 4, the notification can be sent from the CU to the UE using L1 / L2 signaling or MAC signaling. This achieves the same effect as implementation method 4.

[0578] As an example of the process for notifying and indicating RRC parameters related to CQI / CSI, Figure 11 The parameters related to SR in steps ST3001 and ST3002 can be replaced with parameters related to CQI / CSI.

[0579] Similar to implementation method 4, the CU can send multiple notifications of parameters related to CQI / CSI to the UE, thereby increasing the transmission power. This improves the reliability of parameter notifications. The same applies to handover indications from the CU to the UE.

[0580] The UE can transmit CQI / CSI to the Mobile Target Beam / TRP in response to a CQI / CSI transmission indication received from the Mobile Source Beam / TRP. This CQI / CSI transmission from the UE to the Mobile Target Beam / TRP can occur during beam / TRP handover between the CQI / CSI transmission indication and the CQI / CSI transmission itself. This CQI / CSI transmission can be aperiodic. The Mobile Source Beam / TRP can notify the Mobile Target Beam / TRP of a CQI / CSI transmission indication given to the UE. Therefore, CQI / CSI transmission processing during beam / TRP handover can be performed smoothly among the Mobile Source Beam / TRP, the Mobile Target Beam / TRP, and the UE.

[0581] The mobile source beam / TRP can invalidate CQI / CSI transmissions from the UE to its beam. This invalidation can occur after a beam / TRP switch following a CQI / CSI transmission. The mobile source beam / TRP can notify the mobile target beam / TRP of a CQI / CSI transmission instruction given to the UE. The mobile target beam / TRP can then retransmit the CQI / CSI transmission instruction to the UE. The UE can also retransmit the CQI / CSI to the mobile target beam / TRP. Thus, the mobile target beam / TRP can perform scheduling adapted to the transmission status after a beam / TRP switch.

[0582] By using this variation 3, the same effect as in embodiment 4 can be achieved in notifying the UE of RRC parameters related to CQI / CSI.

[0583] Variation 4 of Implementation Method 4.

[0584] In Implementation 4, the description focuses on the notification of RRC parameters related to SR, but it can also be applied to RRC parameters related to RLC.

[0585] As the RRC parameters related to RLC mentioned above, the following (1) to (8) are shown.

[0586] (1) A timer used to determine whether the RLCPDU needs to be retransmitted. For example, T-PollRetransmit as described in Non-Patent Document 12.

[0587] (2) The number of RLCPDUs that the transmitting entity, as the RLC, sends to the receiving entity at polling intervals. For example, the PollPDU described in Non-Patent Document 12.

[0588] (3) The amount of RLCPDU data that the transmitting entity of the RLC sends to the receiving entity at polling intervals. For example, PollByte as described in Non-Patent Document 12.

[0589] (4) The maximum number of repetitions in the ARQ of the RLC. For example, maxRetxThreshold as described in Non-Patent Document 12.

[0590] (5) A timer for reordering RLCPDUs. For example, T-reordering as described in Non-Patent Document 12.

[0591] (6) Minimum transmission interval of RLC status PDU. For example, T-StatusProhibit as described in Non-Patent Document 12.

[0592] (7) The size of the serial number of the RLCPDU. For example, the SN-FieldLength described in Non-Patent Document 12.

[0593] (8) The combination of (1) to (7) above.

[0594] According to (1) above, by reducing the value of the timer used to determine whether RLCPDU needs to be retransmitted in a beam / TRP with an unstable transmission environment, for example, the delay in communication between the UE and the CU can be reduced.

[0595] According to (2) above, by reducing the number of RLCPDUs between polls, for example, in a beam / TRP with an unstable transmission environment, the delay in communication between the UE and the CU can be reduced.

[0596] According to (3) above, by reducing the size of the RLCPDU between polls, for example in a beam / TRP with an unstable transmission environment, the delay in communication between the UE and the CU can be reduced.

[0597] According to (4) above, the reliability of RLCPDU transmission and reception can be improved by increasing the maximum number of retransmissions of RLCPDU, for example, in beam / TRP with unstable transmission environment.

[0598] According to (5) above, the loss of RLCPDU can be prevented by increasing the value of the timer used for reordering in a beam / TRP with an unstable transmission environment, for example.

[0599] According to (6) above, by shortening the transmission interval of the state PDU in, for example, a beam / TRP with an unstable transmission environment, low-latency and high-reliability communication can be ensured.

[0600] According to (7) above, by increasing the size of the sequence number in, for example, beams / TRPs with unstable transmission environments, the loss of RLCPDUs can be prevented.

[0601] In this variation 1, the method and content of the handover notification from the CU to the UE via the forward beam / TRP can be set to be the same as in embodiment 4. Furthermore, the method by which the CU notifies the UE of RRC parameters related to RLC via the forward beam / TRP can be the same as the RRC parameter notification method described in embodiment 4. Thus, the same effect as in embodiment 4 can be obtained.

[0602] Similar to Embodiment 4, the CU can notify the UE of the parameters required for beam scanning. The method for notifying the parameters can be the same as in Embodiment 4. Thus, the same effect as in Embodiment 4 can be obtained.

[0603] Notification of the parameters required for beam scanning from the CU to the UE can be achieved using L1 / L2 signaling or MAC signaling. This achieves the same effect as in implementation method 4.

[0604] Similar to implementation method 4, the CU may include an identifier indicating a parameter change resulting from a TRP / beam handover in its notification to the UE regarding the RLC-related RRC parameters. The UE may retain the RLC-related RRC parameters before the change, or it may use the changed parameters after the TRP / beam handover. Thus, before the TRP / beam handover, RLC reconstruction of the UE and the mobile source beam / TRP that occurs along with the change of RLC-related RRC parameters can be prevented, and communication loss caused by this can be prevented.

[0605] Similar to implementation 4, regarding RRC parameters related to RLC, the CU may not need to notify parameters that also use the same values ​​in the Moving Target Beam / TRP. Therefore, the signaling volume generated by parameter notification can be reduced.

[0606] Similar to Implementation 4, the CU and UE can restore or maintain the initial values ​​of the RRC parameters related to RLC during beam / TRP handover of the UE. These initial values ​​can be determined by a standard or notified from the CU to the UE via RRC signaling. Whether to restore or maintain the initial values ​​can be determined by a standard, or the CU can notify the UE in advance, or the CU can notify the UE along with the handover indication. Thus, the same effect as Implementation 4 can be achieved.

[0607] Similar to embodiment 4, the CU can notify the UE of the RLC-related RRC parameters together with the handover indication, or it can notify the UE of the handover indication after notifying the RLC-related RRC parameters. Alternatively, the CU can notify the UE of the RLC-related RRC parameters after notifying the handover indication. In this case, the CU can notify the UE of the handover indication together with the handover timing. Thus, the same effect as embodiment 4 can be obtained.

[0608] The CU can use L1 / L2 signaling to notify the UE of the aforementioned RLC-related RRC parameters. This allows for rapid notification of the parameters to the UE.

[0609] Alternatively, the CU can use MAC signaling to notify the aforementioned RLC-related RRC parameters. This enables multi-level modulation and parameter notification with a smaller number of symbols. Furthermore, HARQ retransmission control is implemented, thus improving the reliability of parameter notification.

[0610] Similar to implementation method 4, the mobile source TRP can notify the CU of information indicating that parameter confirmation has been delivered. This notification can be made when MAC signaling is used to notify the parameters. The CU can then use this information to notify the UE of a handover instruction. This prevents malfunctions of the RLC due to undelivered parameters.

[0611] Regarding handover notification, similar to implementation method 4, the notification can be sent from the CU to the UE using L1 / L2 signaling or MAC signaling. This achieves the same effect as implementation method 4.

[0612] Similar to implementation method 4, the CU can send multiple notifications of RLC-related parameters, thereby increasing the transmission power. This improves the reliability of parameter notifications. The same applies to handover indications from the CU to the UE.

[0613] The CU and UE can stop transmitting and receiving user data along with the handover indication notification. The CU and UE can resume transmitting and receiving user data after the beam / TRP handover is completed. This prevents data loss due to RLC reconstruction.

[0614] By using this variation 4, the RRC parameters related to RLC can be quickly notified to the UE. Furthermore, appropriate values ​​can be set according to the beam / TRP transmission environment, thus reducing communication latency in the RLC layer and improving reliability.

[0615] Implementation method 5.

[0616] In Implementation 4, for example, it is shown that when the CU has a PDCP and the DU has RLC, MAC, and PHY, or when the CU has a PDCP and H-RLC and the DU has L-RLC, MAC, and PHY, the RRC parameters are notified to the UE from the mobile source beam / TRP. In the above cases, the RRC parameters can also be notified to the UE from the mobile target beam / TRP.

[0617] The Mobile Target Beam / TRP notifies the UE of the RRC parameters. The Mobile Source Beam / TRP notifies the UE of the handover indication.

[0618] Notification of RRC parameters from the mobile target beam / TRP to the UE can occur after the handover notification from the mobile source beam / TRP to the UE. This allows the UE to smoothly obtain the RRC parameters after switching communication target beams / TRPs.

[0619] The RRC parameter can be the same as that shown in Section 6.3.2 of Non-Patent Document 12, as in Embodiment 2. The RRC parameter can be, for example, a parameter related to SR, a parameter related to Ack / Nack repetition, a parameter related to Sounding Reference Signal (SRS), or a parameter related to CQI / CSI.

[0620] The RRC parameters related to SR mentioned above can be the parameters shown in (1) to (3) of Embodiment 2. Furthermore, similar to Embodiment 2, the CU can notify the UE of a parameter representing the maximum number of retransmissions of SR as the RRC parameter related to SR, or it can choose not to notify it. Thus, the same effect as Embodiment 2 can be obtained.

[0621] The CU can notify the UE of the parameters required for beam scanning. The parameters required for beam scanning can be set to the parameters shown in Implementation 1. Notification of the parameters required for beam scanning can be performed via the mobile source beam / TRP. The parameters required for beam scanning can be set to the parameters in the mobile target beam / TRP. Therefore, the UE can easily receive beam scanning signals moving between beams / TRPs.

[0622] Notifying the UE of RRC parameters from the moving target beam / TRP can be done using L1 / L2 signaling, similar to implementation method 2, or it can use MAC signaling. This allows for the rapid notification of the parameters required for beam rate scanning.

[0623] Alternatively, as described above, RRC signaling can be used in the same way as in Implementation Method 3. This allows the RRC parameters to be communicated from the CU to the UE in advance, eliminating the need for RRC parameter notification during beam / TRP handover. This reduces the amount of signaling required.

[0624] The method for notifying the UE of a handover indication from the mobile source beam / TRP can use L1 / L2 signaling in the same way as in embodiment 2, or it can use MAC signaling. This allows for rapid notification of beam / TRP handover to the UE. Furthermore, using MAC signaling improves the reliability of this notification.

[0625] Similar to implementation method 4, the mobile source TRP can notify the CU of information indicating that a handover indication confirmation has been delivered. This notification can be made when MAC signaling is used to notify the handover indication. The CU can then use this information to switch beams / TRPs. This prevents beam / TRP switching when a handover indication has not been delivered, thus avoiding RLF (Redirect Live Failure) due to link loss between the UE and the CU.

[0626] Regarding RRC parameters, the CU may not need to notify the user of parameters with the same values ​​in the Moving Target Beam / TRP. Therefore, the signaling load generated by parameter notification can be reduced.

[0627] In the aforementioned handover indication notification using MAC signaling, similar to Embodiment 2, the CU can switch the beam / TRP when the handover indication from the mobile source beam / TRP to the UE exceeds the HARQ retransmission count. This allows for beam / TRP switching even when the UE's Ack / Nack response to the handover indication cannot be determined. Therefore, when the mobile source beam / TRP fails to receive an Ack signal from the UE in response to the handover indication, a communication target beam / TRP switch can be performed within the UE, and also within the gNB. This prevents the loss of the link between the UE and the gNB.

[0628] Similar to Embodiment 2, the UE can send an uplink signal to the beam / TRP of the mobile source. The uplink signal can be a response to L1 / L2 signaling in response to a handover indication from the CU. New L1 / L2 signaling can be configured as the uplink signal. New uplink control information (UCI) can be configured as the response. Thus, the same effect as described in Embodiment 2 can be achieved.

[0629] The new UCI can be set to be the same as in Implementation Method 2. Therefore, the same effect as in Implementation Method 2 can be obtained.

[0630] As described above, similar to embodiment 4, the mobile source beam / TRP can notify the CU of the information received in response L1 / L2 signaling. Thus, the CU can ascertain that the UE has correctly received the handover instruction, and therefore, beam / TRP handover can be performed smoothly.

[0631] Regarding the handover indication notification from the mobile source beam / TRP to the UE using MAC signaling, the mobile source beam / TRP can notify the CU that an Ack message has been received regarding the handover indication notification. The CU can then use this notification information to switch the beam / TRP in use. Thus, the CU can ascertain whether the UE has correctly received the handover indication, thereby enabling a smooth beam / TRP handover.

[0632] Similar to implementation method 2, the UE can send an uplink signal to the mobile target's beam / TRP. The uplink signal can be set as an acknowledgment signal for beam / TRP switching within the UE. The acknowledgment signal can be sent using the frequency resources of the SR (Radio Signal Regulator). Alternatively, the SR can be sent as the acknowledgment signal. Therefore, the mobile target beam / TRP can notify the RRC parameters upon confirming that the UE's communication target beam / TRP has been switched. This improves the reliability of delivering RRC parameter notifications to the UE.

[0633] The SR transmission from the UE to the mobile target beam / TRP, the SR transmission using common resources, and the SRS transmission are the same as in Implementation Method 2, so the description is omitted.

[0634] The method for the CU to determine whether there is a communication target beam / TRP switching in the UE is the same as in Implementation Method 2, so it is omitted here.

[0635] The transmitting source beam / TRP can send handover indication notifications to the UE multiple times, and its power can also be increased. This improves the reliability of the handover indication notification.

[0636] Sending the target beam / TRP can notify the UE of parameters multiple times, and can also increase the power. This improves the reliability of the parameter notification.

[0637] For SR transmissions from the UE, the mobile source beam / TRP can invalidate the SR received by the UE. The mobile source beam / TRP can invalidate the SR when a beam / TRP handover occurs between SR reception and uplink scheduling clearance transmission. In the above scenario, the UE can retransmit the SR to the mobile target beam / TRP. SR retransmission from the UE can occur after receiving the RRC parameters related to the SR from the mobile target beam / TRP. This avoids situations where retransmitted SRs from the UE to the mobile target beam / TRP fail to reach the mobile target beam / TRP.

[0638] Alternatively, as described above, the mobile source beam / TRP can enable the SR received from the UE. The mobile source beam / TRP can then forward the SR to the mobile target beam / TRP. This forwarding can be done via the CU. In the above scenario, information indicating that the SR has been received can be used instead of the SR. Therefore, even if a beam / TRP handover occurs between SR reception and uplink scheduling clearance transmission, the UE can smoothly perform a series of processes including SR transmission, uplink scheduling clearance reception, and uplink user data reception. Thus, uplink scheduling clearance can be received and uplink user data transmission can be performed without waiting for notification of the RRC parameters related to the SR from the mobile target beam / TRP. This reduces latency in uplink user data communication.

[0639] The Mobile Target Beam / TRP can simultaneously notify the UE of uplink scheduling clearance and RRC parameters related to SR. This reduces the signaling volume from the Mobile Target Beam / TRP to the UE and decreases latency in uplink user data communication.

[0640] Regarding uplink scheduling grant notifications from the CU to the UE, both the CU and the UE can invalidate uplink scheduling grants sent from the mobile source beam / TRP. When a beam / TRP handover occurs between uplink scheduling grants and uplink user data, both the CU and the UE can invalidate the uplink scheduling grant. In the above, the mobile target beam / TRP can retransmit the uplink scheduling grant to the UE. During the retransmission of the uplink scheduling grant, the mobile source beam / TRP can request the mobile target beam / TRP to retransmit the uplink scheduling grant to the UE. Alternatively, the UE can restart the SR transmission for the mobile target beam / TRP. The SR can be retransmitted after receiving the RRC parameter notification from the CU to the UE. This prevents situations where retransmitted SRs from the UE fail to reach the CU.

[0641] Whether the UE restarts SR transmission as described above can be determined by the standard or by the CU notifying the UE. The notification from the gNB to the UE can be pre-processed via RRC signaling, MAC signaling, or L1 / L2 signaling. In examples where the notification is performed using MAC signaling or L1 / L2 signaling, the notification can be sent together with the handover notification. Thus, the UE can receive uplink scheduling clearance corresponding to the uplink resource usage status of the Mobile Target Beam / TRP used for uplink user data transmission.

[0642] Alternatively, regarding the aforementioned beam / TRP handover following the uplink scheduling permission notification from the mobile source beam / TRP to the UE, the CU and UE can make the uplink scheduling permission sent from the mobile source beam / TRP valid. The UE can then use the uplink scheduling permission to send uplink user data to the mobile target beam / TRP. This reduces the signaling volume between the CU and the UE.

[0643] Whether the uplink scheduling permission is enabled can be determined by the standard, or it can be notified from the CU to the UE. The notification from the gNB to the UE can be pre-processed via RRC signaling, MAC signaling, or L1 / L2 signaling. As an example of enabling the uplink scheduling permission, it can be set up so that the mobile target beam / TRP can use the uplink resources indicated by the scheduling permission for the UE. The mobile source beam / TRP can notify the mobile target beam / TRP of the uplink scheduling permission information. Therefore, the mobile target beam / TRP can determine whether the uplink scheduling permission is enabled or disabled, thus enabling flexible scheduling.

[0644] In examples where the above notification is delivered using MAC signaling or L1 / L2 signaling, the notification can be delivered together with the handover notification. Thus, the CU can perform scheduling corresponding to uplink resource usage in the Mobile Target Beam / TRP with less signaling.

[0645] For uplink user data transmission from the UE to the CU, the mobile target beam / TRP can send an Ack / Nack from the mobile source beam / TRP to the UE for the uplink user data received from the UE. This Ack / Nack transmission from the mobile target beam / TRP to the UE can occur during beam / TRP handover between uplink user data transmission from the UE and the Ack / Nack notification for the uplink user data. In this context, the mobile source beam / TRP can notify the mobile target beam / TRP of the Ack / Nack information for the uplink user data. This allows for a smooth beam / TRP handover after uplink user data transmission.

[0646] The Mobile Source Beam (TRP) can notify the Mobile Target Beam (TRP) of information related to the decoding results of uplink user data received from the UE. This information may, for example, be the soft decision value of the uplink user data. Thus, the Mobile Target Beam (TRP) can synthesize and decode the initial reception and retransmission reception results of the uplink user data. This reduces the probability of reception errors.

[0647] According to this embodiment 5, the same effect as in embodiment 2 can be obtained when the CU has PDCP and the DU has RLC, MAC, and PHY, or when the CU has PDCP and H-RLC and the DU has L-RLC, MAC, and PHY. Furthermore, even in the event of a rapid deterioration in the communication environment between the mobile source beam / TRP and the UE, the RRC parameters can still be notified to the UE from the CU. As a result, for example, random access processing of the UE due to the failure to deliver SR can be suppressed.

[0648] Similar to the combination of Embodiments 2 and 3, Embodiment 4 can also be used in combination with this Embodiment 5. That is, the CU can switch which of the mobile source beam / TRP and the mobile target beam / TRP to transmit RRC parameters from. Thus, the CU can flexibly change the beam / TRP from which RRC parameters are transmitted according to the communication environment.

[0649] Similar to the combination of Embodiments 2 and 3, the CU can pre-set the RRC parameters to the UE quasi-statically, dynamically by the CU, or implicitly by the standard, regarding which of the mobile source beam / TRP and mobile target beam / TRP the RRC parameters are transmitted from. Thus, the same effect as the combination of Embodiments 2 and 3 can be obtained.

[0650] In Implementation 5, a base station apparatus with separate CU and DU is shown as an example, but it can also be applied to base station apparatuses where CU and DU are not separated. This base station apparatus can be one that does not share RRC parameters between beams. Furthermore, this base station apparatus can be, for example, a base station that performs different HARQ scheduling for each beam, a base station with different RLC layers for each beam, or a base station combining both. When applying Implementation 5 to this base station apparatus, the CU can be replaced with a gNB. Therefore, during inter-beam movement within a cell, RRC parameters can be notified to the UE from the gNB via the moving target beam, increasing the number of UEs that can be accommodated in spatially separated cells due to beam separation. Parameters can be quickly notified to the UE from the gNB.

[0651] According to Embodiment 5, a communication system is provided similarly to Embodiment 2. This system includes, for example, a communication terminal device and a base station device for wireless communication with the communication terminal device using wireless beams. A cell formed by the base station device is spatially separated by multiple wireless beams belonging to the base station device. When the communication terminal device moves from the coverage area of ​​the first wireless beam to the coverage area of ​​the second wireless beam, the base station device changes the RRC (Radio Resource Control) parameters used by the communication terminal device from the first RRC parameters used for the first wireless beam to the second RRC parameters used for the second wireless beam. Furthermore, the multiple wireless beams can be configured as follows: Figure 8 As illustrated, it can be formed by multiple DUs (in other words, TRPs), or by a single DU, or by a base station device that integrates CU and DU.

[0652] According to this structure, the RRC parameters used by the communication terminal device can be changed based on the change in the wireless beam used for the communication terminal device. Therefore, the number of communication terminal devices that can be accommodated can be increased as described above.

[0653] Here, the above structure can be modified in various ways as described above. Specifically, according to embodiment 5, for example, a communication system is provided where: a base station device includes at least one DU (Distributed Unit) that outputs multiple wireless beams and a CU (Central Unit) that controls at least one DU; the at least one DU has a MAC (Medium Access Control) function; the base station device notifies a communication terminal device of a second RRC parameter via a second wireless beam using L1 / L2 signaling or MAC signaling, and notifies the communication terminal device of a switching indication from the first wireless beam to the second wireless beam via a first wireless beam using L1 / L2 signaling or MAC signaling. In the above, the DU may have an RLC (Radio Link Control) function. Furthermore, as another example, a communication system is provided where: a base station device has the function of outputting multiple wireless beams and a MAC function; the base station device notifies the communication terminal device of the second RRC parameter via the second wireless beam, and notifies the communication terminal device of a switching indication from the first wireless beam to the second wireless beam via the first wireless beam.

[0654] Furthermore, various modifications are provided as described in the following modifications 1 to 4.

[0655] Variation 1 of Implementation Method 5.

[0656] In Implementation 5, the description focuses on the notification of RRC parameters related to SR, but it can also be applied to RRC parameters related to Ack / Nack repetition.

[0657] The RRC parameters related to the repetition of Ack / Nack mentioned above can be the same as those in Variation 1 of Implementation 2.

[0658] In this variation 1, the method and content of the handover notification from the CU to the UE via the moving target beam / TRP can be set to be the same as in embodiment 5. Furthermore, the method by which the CU notifies the UE of RRC parameters related to Ack / Nack repetition via the moving target beam / TRP can be the same as the RRC parameter notification method described in embodiment 5. Thus, the same effect as in embodiment 5 can be obtained.

[0659] Similar to embodiment 5, the CU can notify the UE of the parameters required for beam scanning. The method of notifying the parameters can be the same as in embodiment 5. Therefore, the UE can easily receive beam scanning signals moving between beams / TRPs.

[0660] The notification of parameters required for beam scanning from the CU to the UE described above can be achieved using L1 / L2 signaling or MAC signaling. This achieves the same effect as in Implementation Method 5.

[0661] Similar to implementation 5, regarding the RRC parameters related to Ack / Nack repetition, the CU may also omit the requirement to notify parameters using the same values ​​in the Moving Target Beam / TRP. Therefore, the signaling load generated by parameter notification can be reduced.

[0662] Similar to implementation 5, the CU and UE can either restore the values ​​of the RRC parameters related to Ack / Nack repetition to their initial values ​​or retain them during UE beam / TRP handover. Whether to restore the parameter values ​​to their initial values ​​or retain them during UE beam / TRP handover can be determined by the standard or can be communicated to the UE in advance from the CU. Alternatively, the information regarding whether to return to the initial values ​​or retain them can be communicated to the UE from the CU along with the handover instruction. Therefore, even if parameter notification from the mobile source beam / TRP to the UE fails, the UE can use the initial values ​​or the RRC parameters before the change, thus improving the reliability of Ack / Nack repetition from the UE to the mobile target beam / TRP.

[0663] The CU can use L1 / L2 signaling to notify the UE of the aforementioned RRC parameters related to Ack / Nack repetition. This allows for rapid notification of the parameters to the UE.

[0664] Alternatively, the CU can use MAC signaling to notify the aforementioned RRC parameters related to Ack / Nack repetition. This enables multi-level modulation, thus allowing parameter notification with a smaller number of symbols. Furthermore, HARQ retransmission control is implemented, thereby improving the reliability of parameter notification.

[0665] Regarding handover notification, similar to implementation method 2, the notification can be sent from the CU to the UE using L1 / L2 signaling or MAC signaling. This achieves the same effect as implementation method 2.

[0666] The method for notifying the UE of the handover indication from the mobile source beam / TRP can use L1 / L2 signaling in the same way as in Embodiment 5, or it can use MAC signaling. Thus, the same effect as shown in Embodiment 5 can be obtained.

[0667] Similar to implementation 5, the mobile source TRP can notify the CU of information indicating that a handover indication confirmation has been delivered. This notification can be made when MAC signaling is used to notify the handover indication. The CU can then use this information to switch beams / TRPs. This prevents beam / TRP switching when a handover indication has not been delivered, thus avoiding RLF (Redirect Live Frame) due to link loss with the gNB for the UE.

[0668] Similar to implementation method 5, the CU can send multiple notifications of parameters related to Ack / Nack repetition to the UE, which can increase the transmission power. This improves the reliability of Ack / Nack repetition notifications. The same applies to handover indications from the CU to the UE.

[0669] For both the mobile source beam / TRP and the mobile target beam / TRP, the UE may not need to notify the UE of the Ack / Nack response for downlink user data received from the CU via the mobile source beam / TRP. This UE action can be performed during beam / TRP handover between downlink user data and Ack / Nack. The mobile source beam / TRP can then forward the downlink user data to the mobile target beam / TRP. The mobile target beam / TRP can then forward the downlink user data to the UE. This prevents downlink user data loss due to beam / TRP handover.

[0670] As another example, the UE can notify the mobile target beam / TRP of the Ack / Nack response to downlink user data received from the CU from the mobile source beam / TRP. This Ack / Nack notification can occur during a beam / TRP handover between downlink user data and the Ack / Nack response. The mobile target beam / TRP can then notify the mobile source beam / TRP of the Ack / Nack reception result. This reduces the signaling volume related to downlink user data during beam / TRP handover.

[0671] In the above description, the mobile source beam / TRP can forward the downlink user data to the mobile target beam / TRP. This forwarding can occur when a Nack notification is received from the UE regarding downlink user data. The mobile target beam / TRP can then use the forwarded downlink user data to retransmit to the UE. This ensures smooth retransmission of downlink user data during beam / TRP handover.

[0672] Upon receiving parameter notifications related to Ack / Nack repetition from the CU to the UE, the downlink user data from the Mobile Target Beam / TRP to the UE can be retransmitted. This allows the Mobile Target Beam / TRP to receive subsequent Ack / Nack signals configured by Ack / Nack repetition, thus improving the reliability of Ack / Nack notifications from the UE to the Mobile Target Beam / TRP.

[0673] The Ack / Nack notification from the UE to the Mobile Target Beam / TRP can be performed after receiving the parameter notification related to Ack / Nack repetition from the Mobile Target Beam / TRP to the UE, just as described above. Thus, the same effect as described above can be achieved.

[0674] Regarding the determination of Ack / Nack received from the UE, the mobile source beam / TRP can either utilize only the received results from its own beam / TRP or utilize the received results from the mobile target beam / TRP as well. The mobile target beam / TRP can forward the Ack / Nack received from the UE to the mobile source beam / TRP. This action can be performed when switching beam / TRPs between Ack / Nack repetitions from the UE to the mobile source beam / TRP. By utilizing only the received results from the mobile source beam / TRP, the reception of Ack / Nack repetitions from the UE can be performed quickly. By utilizing the received results from the mobile target beam / TRP as well, the reliability of Ack / Nack repetitions in the mobile source beam / TRP can be improved. Whether the mobile source beam / TRP utilizes only the received results from its own beam / TRP or utilizes the received results from the mobile target beam / TRP as well can be determined by the standard or appropriately switched by the CU. By appropriately switching the receiver via the CU, the appropriate receiving action can be selected, for example, based on the transmission status in the mobile source beam / TRP, thus improving the flexibility of receiving Ack / Nack repetitions in the gNB.

[0675] In the above, the mobile target beam / TRP can replace the mobile source beam / TRP for Ack / Nack repetition reception processing. The mobile target beam / TRP can utilize only the reception results from its own beam / TRP, or it can utilize the reception results from the mobile source beam / TRP together. The mobile source beam / TRP can forward the Ack / Nack reception results from the UE to the mobile target beam / TRP. Thus, the same effect as described above can be achieved. Whether the mobile target beam / TRP utilizes only the reception results from its own beam / TRP or utilizes the reception results from the mobile source beam / TRP together can be determined by the standard, or it can be switched appropriately by the CU.

[0676] Which of the mobile source beam / TRP or the mobile target beam / TRP performs the Ack / Nack reception, as described above, can be determined by the standard or predetermined by the CU. This prevents malfunctions caused by inconsistencies in the Ack / Nack reception results between the mobile source beam / TRP and the mobile target beam / TRP.

[0677] The Mobile Target Beam / TRP can utilize Ack / Nack repeats sent from the UE to the Mobile Source Beam / TRP to retransmit downlink user data to the UE. This retransmission can occur when a beam / TRP handover occurs between the Ack / Nack repeats from the UE to the Mobile Source Beam / TRP and the retransmission of downlink user data to the UE. The Mobile Source Beam / TRP can then forward the retransmitted data to the Mobile Target Beam / TRP. This ensures smooth downlink user data retransmission processing during beam / TRP handover.

[0678] By using this variation 1, the notification to the UE regarding the RRC parameters related to Ack / Nack repetition can achieve the same effect as in embodiment 5.

[0679] Variation 2 of Implementation Method 5.

[0680] In Implementation 5, the description focuses on the notification of RRC parameters related to SR, but it can also be applied to RRC parameters related to SRS.

[0681] The RRC parameters related to SRS mentioned above can be the same as those in Variation 2 of Embodiment 2.

[0682] In this variation 2, the method and content of the handover notification from the CU to the UE via the moving front beam / TRP can be set to be the same as in embodiment 5. Furthermore, the method by which the CU notifies the UE of the RRC parameters related to the SRS via the moving target beam / TRP can be the same as the RRC parameter notification method described in embodiment 5. Thus, the same effect as in embodiment 5 can be obtained.

[0683] Similar to implementation 5, the CU can notify the UE of the parameters required for beam scanning. Thus, the UE can easily receive beam scanning signals moving between beams / TRPs.

[0684] The notification of parameters required for beam scanning from the CU to the UE described above can be achieved using L1 / L2 signaling or MAC signaling. This achieves the same effect as in Implementation Method 5.

[0685] Similar to implementation 5, regarding the RRC parameters related to SRS, the CU may not need to notify parameters that also use the same values ​​in the Moving Target Beam / TRP. Therefore, the signaling volume generated by parameter notification can be reduced.

[0686] Similar to Implementation 5, the CU and UE can either restore the values ​​of the RRC parameters related to SRS to their initial values ​​or retain them during beam / TRP handover of the UE. Whether to restore the parameter values ​​to their initial values ​​or retain them during beam / TRP handover can be determined by a standard or can be communicated to the UE in advance from the CU. Alternatively, the information regarding whether to restore the initial values ​​or retain them can be communicated to the UE from the CU along with the handover instruction. This achieves the same effect as Implementation 5.

[0687] The CU can use L1 / L2 signaling to notify the UE of the aforementioned SRS-related RRC parameters. This allows for rapid notification of the parameters to the UE.

[0688] Alternatively, the CU can use MAC signaling to notify the aforementioned SRS-related RRC parameters. This enables multi-level modulation, thus allowing parameter notification with a smaller number of symbols. Furthermore, HARQ retransmission control is implemented, thereby improving the reliability of parameter notification.

[0689] Regarding handover notification, similar to implementation method 5, the notification can be sent from the CU to the UE using L1 / L2 signaling or MAC signaling. This achieves the same effect as implementation method 5.

[0690] Similar to implementation method 5, the CU can send multiple notifications of SRS-related parameters to the UE, which can increase the transmission power. This improves the reliability of SRS-related parameter notifications. The same applies to handover indications from the CU to the UE.

[0691] The UE can transmit SRS to the Mobile Target Beam / TRP after receiving SRS-related parameters from the CU via the Mobile Target Beam / TRP. This prevents the transmission of SRS that the Mobile Target Beam / TRP cannot receive before the UE receives the SRS-related parameters.

[0692] The UE can transmit SRS to the Mobile Target Beam / TRP in response to an SRS transmission indication received from the Mobile Source Beam / TRP. This SRS transmission from the UE to the Mobile Target Beam / TRP can occur during beam / TRP handover between the SRS transmission indication and the actual SRS transmission. The SRS transmission can be aperiodic. The Mobile Source Beam / TRP can notify the Mobile Target Beam / TRP that it has indicated an SRS transmission to the UE. Therefore, SRS transmission processing during beam / TRP handover can be performed smoothly in both the CU and the UE.

[0693] In the above, the UE can invalidate the SRS transmission indication received from the mobile source beam / TRP. This reduces signaling from the mobile source beam / TRP to the mobile target beam / TRP.

[0694] The mobile source beam / TRP can invalidate the SRS transmitted from the UE to this beam. Invalidating the SRS can be performed after the beam / TRP has been switched following the SRS transmission. Therefore, the mobile target beam / TRP can perform scheduling adapted to the transmission status after the beam / TRP switch.

[0695] By using this variation 2, the same effect as in embodiment 5 can be achieved in notifying the UE of RRC parameters related to SRS.

[0696] Variation 3 of Implementation Method 5.

[0697] In Implementation 5, the description focuses on notification of RRC parameters related to SR, but it can also be applied to RRC parameters related to CQI / CSI.

[0698] The RRC parameters related to CQI / CSI mentioned above can be the same as those in variation 3 of embodiment 2.

[0699] In this variation 3, the method and content of the handover notification from the CU to the UE via the moving front beam / TRP can be set to be the same as in embodiment 5. Furthermore, the method by which the CU notifies the UE of RRC parameters related to CQI / CSI via the moving target beam / TRP can be the same as the RRC parameter notification method described in embodiment 5. Thus, the same effect as in embodiment 5 can be obtained.

[0700] Similar to implementation 5, the CU can notify the UE of the parameters required for beam scanning. Thus, the UE can easily receive beam scanning signals moving between beams / TRPs.

[0701] The notification of parameters required for beam scanning from the CU to the UE described above can be achieved using L1 / L2 signaling or MAC signaling. This achieves the same effect as in Implementation Method 5.

[0702] Similar to implementation 5, regarding RRC parameters related to CQI / CSI, the CU may not need to notify parameters that also use the same values ​​in the Moving Target Beam / TRP. Therefore, the signaling load generated by parameter notification can be reduced.

[0703] Similar to Implementation 5, the CU and UE can either restore the initial values ​​of the RRC parameters related to CQI / CSI to their respective values ​​or retain them during beam / TRP switching of the UE. Whether to restore the initial values ​​or retain them during beam / TRP switching can be determined by a standard or can be communicated to the UE in advance from the CU. Alternatively, the information regarding whether to restore the initial values ​​or retain them can be communicated to the UE from the CU along with the handover instruction. This achieves the same effect as Implementation 5.

[0704] The CU can use L1 / L2 signaling to notify the UE of the aforementioned RRC parameters related to CQI / CSI. This allows for rapid notification of the parameters to the UE.

[0705] Alternatively, the CU can use MAC signaling to notify the aforementioned CQI / CSI-related RRC parameters. This enables multi-level modulation, thus allowing parameter notification with a smaller number of symbols. Furthermore, HARQ retransmission control is implemented, thereby improving the reliability of parameter notification.

[0706] Regarding handover notification, similar to implementation method 5, the notification can be sent from the CU to the UE using L1 / L2 signaling or MAC signaling. This achieves the same effect as implementation method 5.

[0707] Similar to implementation method 5, the CU can send multiple notifications of CQI / CSI related parameters to the UE, thereby increasing the transmission power. This improves the reliability of CQI / CSI related parameter notifications. The same applies to handover indications from the CU to the UE.

[0708] The UE can transmit CQI / CSI to the Mobile Target Beam / TRP after receiving CQI / CSI-related parameters transmitted from the CU via the Mobile Target Beam / TRP. This prevents the transmission of CQI / CSI that the Mobile Target Beam / TRP cannot receive before the UE receives the CQI / CSI-related parameters.

[0709] The UE can transmit CQI / CSI to the Mobile Target Beam / TRP in response to a CQI / CSI transmission indication received from the Mobile Source Beam / TRP. This CQI / CSI transmission from the UE to the Mobile Target Beam / TRP can occur during beam / TRP handover between the CQI / CSI transmission indication and the CQI / CSI transmission itself. This CQI / CSI transmission can be aperiodic. The Mobile Source Beam / TRP can notify the Mobile Target Beam / TRP of a CQI / CSI transmission indication given to the UE. Therefore, CQI / CSI transmission processing during beam / TRP handover can be performed smoothly among the Mobile Source Beam / TRP, the Mobile Target Beam / TRP, and the UE.

[0710] The mobile source beam / TRP can invalidate CQI / CSI transmissions from the UE to its beam. This invalidation can occur after a beam / TRP switch following a CQI / CSI transmission. The mobile source beam / TRP can notify the mobile target beam / TRP of a CQI / CSI transmission instruction given to the UE. The mobile target beam / TRP can then retransmit the CQI / CSI transmission instruction to the UE. The UE can also retransmit the CQI / CSI to the mobile target beam / TRP. Thus, the mobile target beam / TRP can perform scheduling adapted to the transmission status after a beam / TRP switch.

[0711] By using this variation 3, the same effect as in embodiment 5 can be achieved in notifying the UE of RRC parameters related to CQI / CSI.

[0712] Variation 4 of Implementation Method 5.

[0713] In Implementation 5, the description focuses on the notification of RRC parameters related to SR, but it can also be applied to RRC parameters related to RLC.

[0714] In the above, (1) to (8) shown in the variation 4 of embodiment 4 can be used as RRC parameters related to RLC.

[0715] In this variation 4, the method and content of the handover notification from the CU to the UE via the forward beam / TRP can be set to be the same as in embodiment 5. Furthermore, the method by which the CU notifies the UE of RRC parameters related to RLC via the forward beam / TRP can be the same as the RRC parameter notification method described in embodiment 5. Thus, the same effect as in embodiment 5 can be obtained.

[0716] Similar to Embodiment 5, the CU can notify the UE of the parameters required for beam scanning. The method for notifying the parameters can be the same as in Embodiment 5. Thus, the same effect as in Embodiment 5 can be obtained.

[0717] Notification of the parameters required for beam scanning from the CU to the UE can be achieved using L1 / L2 signaling or MAC signaling. This achieves the same effect as in implementation method 5.

[0718] Similar to implementation method 5, the CU may include an identifier indicating a parameter change resulting from a TRP / beam handover in its notification to the UE regarding the RLC-related RRC parameters. The UE may retain the RLC-related RRC parameters before the change, or it may use the changed parameters after the TRP / beam handover. Thus, before the TRP / beam handover, RLC reconstruction of the UE and the mobile source beam / TRP that occurs along with the change of RLC-related RRC parameters can be prevented, and communication loss caused by this can be prevented.

[0719] Similar to implementation 5, regarding RRC parameters related to RLC, the CU may not need to notify parameters that also use the same values ​​in the Moving Target Beam / TRP. Therefore, the signaling volume generated by parameter notification can be reduced.

[0720] Similar to Implementation 5, the CU and UE can restore or maintain the initial values ​​of the RRC parameters related to RLC during beam / TRP handover of the UE. These initial values ​​can be determined by a standard or notified from the CU to the UE via RRC signaling. Whether to restore or maintain the initial values ​​can be determined by a standard, or the CU can notify the UE in advance, or the CU can notify the UE along with the handover indication. Thus, the same effect as Implementation 5 can be achieved.

[0721] The CU can use L1 / L2 signaling to notify the UE of the aforementioned RLC-related RRC parameters. This allows for rapid notification of the parameters to the UE.

[0722] Alternatively, the CU can use MAC signaling to notify the aforementioned RLC-related RRC parameters. This enables multi-level modulation, thus allowing parameter notification with a smaller number of symbols. Furthermore, HARQ retransmission control is implemented, thereby improving the reliability of parameter notification.

[0723] Similar to implementation method 5, the mobile target TRP can notify the CU of information indicating that parameter confirmation has been delivered. This notification can be made when MAC signaling is used to notify the parameters. The CU can then use this information to notify the UE of a handover instruction. This prevents malfunctions of the RLC due to undelivered parameters.

[0724] Regarding handover notification, similar to implementation method 5, the notification can be sent from the CU to the UE using L1 / L2 signaling or MAC signaling. This achieves the same effect as implementation method 5.

[0725] Similar to implementation method 5, the CU can send multiple notifications of RLC-related parameters, which can increase the transmission power. This improves the reliability of parameter notifications. The same applies to handover indications from the CU to the UE.

[0726] The CU and UE can suspend user data transmission and reception along with the handover indication notification. The CU and UE can resume user data transmission and reception after beam / TRP handover and the transmission and reception of RLC-related parameters are completed. This prevents data loss due to RLC reconstruction.

[0727] By using this variation 4, the same effect as in embodiment 5 can be achieved in notifying the UE about RRC parameters related to RLC.

[0728] Implementation method 6.

[0729] There is a technique called carrier aggregation (CA), which collects multiple carriers and uses them as radio resources for communication. In CA, a UE constitutes a serving cell consisting of one PCell and one or more SCells. Therefore, CA is configured on a cell unit basis. CA configuration from the eNB to the UE is performed by notifying the cell unit parameters for CA.

[0730] In NR (New Radio), a technique is proposed where base stations (in this specification, 5G base stations are referred to as gNBs) use beamforming for communication. Beamforming uses multiple antennas to form a narrow-range beam. For example, in a gNB, it consists of multiple antennas. Figure 4 Antenna 408 is shown. The gNB utilizes a portion or all of the multiple antennas to form a beam in a predetermined direction. By forming a narrow-range beam, the radio wave coverage area can be expanded.

[0731] When a cell supporting CA (Callable Communication) supports the use of multiple beams, even if CA is set only by the cell identifier, it is unclear which beam of the cell can be aggregated. Therefore, the gNB cannot set CA for the UE and cannot utilize many radio resources. Consequently, it cannot provide high-speed and high-capacity communication services to the UE.

[0732] In this 6th embodiment, a method for solving the above-mentioned problems is disclosed.

[0733] CA settings are performed on a beam-by-beam basis. One beam or multiple beams can be used. The gNB informs the UE which beam to use when configuring the SCell.

[0734] Figure 12 This describes the architecture of the CA (Cyclic Alignment) in a gNB (gearband network) configured in beam units. A gNB consists of protocols for PDCP (Pulse Detection and Control), RLC (Remote Control and Control), MAC (Machine Interface), and PHY (Physical Hybrid). The PHY function can be divided into two parts, which can be referred to as H-PHY and L-PHY, respectively.

[0735] In 3GPP, a scheme is proposed to separate the gNB into two units (see Non-Patent Document 7). These two units are referred to as CU (Central Unit) and DU (Distributed Unit). The CU is connected to multiple DUs. For example, a scheme is proposed where the CU has PDCP, RLC, MAC, and H-PHY. A scheme is proposed where the DU has L-PHY. The TRP can have the same functions as the DU. Bn (n is a natural number) represents the beamforming. DUs or TRPs constitute one or more beams.

[0736] The gNB performs CA on the UE through one PCC (Primary Component Carrier) and one or more SCCs (Secondary Component Carriers). A cell using a PCC is a PCell. A cell using an SCC is an SCell. Sometimes, the gNB performs CA on the UE through one PCell and one or more SCells. Each cell has its own HARQ at the bottom of the MAC address, and these are aggregated above it. Each cell has its own functions below the PHY level.

[0737] When CA is set in beam units, specify which beam in the PCell or SCell to use for CA. Figure 12 In the example, the gNB uses beam 1 of TRP1 of PCell, beam 2 of TRP2 of PCell, beam 1 and beam 2 of TRP1 of SCell, and beam 1 of TRP2 of SCell to perform CA on the UE.

[0738] By configuring CA (Callable Communication) on a beam-by-beam basis, cells that support beamforming can be designated as CA cells. This allows the UE to utilize a significant amount of radio resources, enabling high-speed and high-capacity communication.

[0739] The method for setting the CA of the public beam unit.

[0740] RRC signaling is used in the CA settings of beam units. The gNB notifies the UE of beam-related information via RRC signaling. Beam-related information can be included in the configuration messages of the SCell. For example, beam-related information can be included in the RRC connection reset message. Beam-related information can also be included in the parameters used for adding / changing or releasing SCells.

[0741] The beam-related information is simply information that the UE can use to determine the beam. For example, when a beam-specific RS is transmitted as a beam, the UE can determine the beam by receiving the beam-specific RS. In the above case, the beam-related information has a beam-specific RS (Beat RS (BRS)) structure. Furthermore, for example, if the beam is associated with an identifier, and the beam identifier is linked to the beam-specific RS structure, the beam identifier can be set as beam-related information. Additionally, a renumbered beam index can be set based on the number of beams for which the beam identifier is set.

[0742] The gNB maps the aforementioned beam-related information to the SCell used for CA and notifies the UE of this information. The gNB informs the UE of information related to the beam being monitored within the SCell. By receiving this information, the UE can identify the beam being monitored within the SCell. The correspondence between SCells and beams set by the RRC remains until it is reset.

[0743] The gNB uses MAC control signaling to activate / deactivate SCells for the UE. When a SCell is activated / deactivated using MAC control signaling, the UE considers the beam corresponding to the SCell received via RRC signaling to be activated / deactivated. The UE monitors the beam corresponding to the activated SCell. By monitoring the beam, the UE detects whether there is any information destined for itself. For example, the UE receives the Physical Downlink Control Channel (PDCCH) of the beam and detects whether there is any scheduling information destined for itself.

[0744] The UE receives the Synchronization Signal (SS) of the SCell notified by RRC signaling and performs synchronization. At this time, any beam of the SCell is used to receive the SS and perform synchronization. After synchronization, the UE uses at least one of the beam identifier of the beam corresponding to the SCell notified by RRC signaling and the BRS structure to detect the beam being monitored within the SCell. The UE receives the Physical Downlink Control Channel (PDCCH) of the monitored beam.

[0745] Alternatively, the UE can receive and synchronize the SS (Synchronization Signal) of an activated SCell notified by MAC control signaling. In this case, any beam of that SCell is used to receive the SS and perform synchronization. After synchronization, the UE uses at least one of the beam identifier of the beam corresponding to the SCell notified by RRC signaling and the BRS structure to detect the beam being monitored within the SCell. The UE receives the Physical Downlink Control Channel (PDCCH) of the monitored beam.

[0746] The gNB can use the PDCCH of this beam to notify the UE of scheduling information. Therefore, the gNB can notify the UE which beam to use for notification, and the UE can identify which beam to monitor and which beam to use for communication.

[0747] If only the SCell is notified as before, then after accessing the SCell, it is necessary to configure which beam within the SCell to use. Therefore, in addition to the SCell access processing, the selection of the beam to use also needs to be performed. This results in time being spent before CA begins.

[0748] As shown in Embodiment 6, by determining which beam to use for CA during CA setup, the time until CA begins can be reduced. Since CA can begin earlier, higher capacity communication can be achieved.

[0749] Additionally, as a method for the gNB to identify which beam is used for communication, the UE can pre-determine each beam of the SCell before CA settings. The UE can then notify the gNB of the determination results. This notification can be periodic, event-triggered, or requested by the gNB.

[0750] Figure 13 and Figure 14 This is a diagram illustrating an example of the CA setup process for a beam unit that uses RRC signaling. Figure 13 and Figure 14 Connect at the location of boundary line BL521. Figure 13 and Figure 14 The diagram illustrates the scenario where the gNB performs CA (Communication Communication) with the UE using the PCell and SCell. Furthermore, it shows a scenario where the PCell consists of beams 1 and 2, and the SCell consists of beams 1, 2, and 3. In step ST5201, the UE and gNB communicate via beam 1 of the PCell.

[0751] In step ST5202, the gNB notifies the UE of the configuration information of the CA SCell and the information related to the beam corresponding to the SCell via beam 1 of the PCell. This notification uses dedicated RRC signaling. In previous LTE systems, dedicated RRC signaling was used in the notification of CA SCell configuration information, thus allowing beam-related information to be added only to this message. This reduces the complexity of control over the configuration of each beam.

[0752] In step ST5202, the beam corresponding to the SCell used for notification can be set as the beam used to notify the UE. The beam corresponding to the SCell used for notification can be set as the beam the UE wants to monitor the physical downlink control channel. The beam corresponding to the SCell used for notification can be set as the beam the UE wants to access. Thus, the gNB can notify the UE which beam in the SCell to use for communication, and the UE can determine the beam in the SCell to use for communication.

[0753] Each beam of the SCell periodically transmits SS (refer to steps ST5203-ST5205). Additionally, each beam of the SCell periodically transmits BRS (refer to steps ST5206-ST5208). BRS can be transmitted according to at least one of the frequency and time resources of a predetermined pattern.

[0754] In step ST5209, the gNB notifies the SCell of activation / deactivation information. This notification uses MAC control signaling. The activation / deactivation information is included in the MAC CE notification. In step ST5210, the UE receives the SS of the activated SCell and synchronizes it. In step ST5211, the UE detects the beam being monitored within the SCell using at least one of the beam identifier corresponding to the beam notified by the RRC dedicated signaling and the BRS structure. In step ST5212, the UE receives the Physical Downlink Control Channel (PDCCH) of the monitored beam.

[0755] In step ST5209, the gNB, which notified the SCell of activation information via beam 1 of the PCell, then in step ST5213, notifies the UE of downlink scheduling information from beam 1 of the SCell. This notification uses L1 / L2 control signals. In step ST5214, the gNB sends downlink data to the UE based on this scheduling information. Based on the scheduling information received from beam 1 of the SCell in step ST5213, the UE receives downlink data from beam 1 of the SCell in step ST5214.

[0756] In step ST5215, the UE wishing to transmit uplink data via SCell uses beam 1 of SCell to transmit PRACH and performs RA processing with the gNB. RA processing based on the Physical Downlink Control Signal (PDCCH) indication can be performed. In step ST5216, the UE begins transmitting uplink data to beam 1 of SCell. UEs wishing to transmit uplink data via SCell can transmit SR instead of PRACH. This is effective when uplink synchronization has been performed and there is no need to acquire TA again. If the gNB has recognized the presence of uplink data in the UE, the gNB notifies the UE of uplink scheduling information from beam 1 of SCell. The UE transmits uplink data to the gNB according to this scheduling information.

[0757] PRACH transmission from the UE can be performed after the beam used for communication by the UE is detected. Here, PRACH transmission can be performed on the detected beam after the processing in step ST5211. Alternatively, PRACH transmission from the UE can be performed after PDCCH reception and before downlink scheduling information reception. Here, PRACH transmission can be performed on the detected beam after the processing in step ST5212. This allows uplink data transmission to begin as early as possible.

[0758] Next, refer to Figure 14 An example of the procedure for changing the beam used by the gNB to communicate with the UE within a SCell is disclosed. In step ST5217, the gNB decides to change the beam used for communication with the UE. For example, this can be determined by the gNB's RRC function unit. As a method for determining which beam to change the beam used for communication between the gNB and the UE, the method disclosed above for the gNB to identify which beam to communicate with can be applied. In step ST5218, the gNB notifies the UE of the CA's SCell configuration information and information related to the beam corresponding to that SCell via beam 1 of the PCell. The beam-related information is set to the changed information. This notification uses RRC-specific signaling.

[0759] Although the gNB discloses that it notifies the UE of the CA's SCell configuration information and related information about the changed beam via beam 1 of the PCell, it can also notify via beam 1 of the SCell. The gNB can determine which communication quality is better and use the beam with the better communication quality for notification.

[0760] When notification is sent via the PCell beam, it will not be affected by the drastic degradation of the SCell beam's communication quality. The gNB can notify the UE of the CA's SCell configuration information and information related to the changed beam. The UE can change to the beam notified by the gNB.

[0761] For example, when SCells are used at high frequencies and with narrow coverage areas, communication quality can deteriorate sharply due to UE congestion and movement. In such cases, the gNB can utilize the PCell beam for notification.

[0762] Each beam of the SCell periodically transmits SS (refer to steps ST5219-ST5221). Additionally, each beam of the SCell periodically transmits BRS (refer to steps ST5222-ST5224). BRS can be transmitted according to at least one of the frequency and time resources of a predetermined pattern.

[0763] In step ST5225, the gNB notifies the SCell of activation / deactivation information. This notification uses MAC control signaling. The activation / deactivation information is included in the notification via the MAC CE. This notification can be omitted if the SCell's activation / deactivation information has not changed. In step ST5226, the UE receives the SS of the activated SCell and synchronizes it. This process can be omitted if the activated SCell has not changed and synchronization has already been performed.

[0764] In step ST5227, the UE detects the beam being monitored within the SCell using at least one of the beam identifier of the modified beam corresponding to the SCell notified by the RRC dedicated signaling and the BRS structure. In step ST5228, the UE receives the Physical Downlink Control Channel (PDCCH) of the monitored beam.

[0765] In step ST5229, the gNB notifies the UE of downlink scheduling information from beam 2 of the SCell. This notification uses L1 / L2 control signals. In step ST5230, the gNB sends downlink data to the UE based on the scheduling information. Based on the scheduling information received from beam 2 of the SCell in step ST5229, the UE receives downlink data from beam 2 of the SCell in step ST5230.

[0766] In step ST5231, a Relationship Arrangement (RA) is performed between the UE that wishes to transmit uplink data via the SCell and the gNB that transmits PRACH data using beam 2 of the SCell. In step ST5232, the UE begins transmitting uplink data to beam 2 of the SCell. Alternatively, an SR (Relationship Request) can be transmitted instead of PRACH. This is effective when uplink synchronization has been performed and when a TA (Target Acquisition Request) does not need to be acquired again. If the gNB has detected the presence of uplink data in the UE, the gNB notifies the UE of uplink scheduling information from beam 2 of the SCell. The UE then transmits uplink data to the gNB based on this scheduling information.

[0767] Therefore, the beam of the SCell communicating with the UE can be changed from beam 1 to beam 2.

[0768] Using the method disclosed in Embodiment 6, the gNB and UE can determine the beam of the SCell and communicate. The gNB can set the CA for the UE using the beams of the PCell and the SCell. The gNB can increase the radio resources used by setting the CA for the UE. Therefore, high-speed and high-capacity communication services can be provided to the UE.

[0769] Furthermore, the UE does not need to perform the process of selecting the beam for communication after receiving the SS of the SCell. The UE does not need to notify the gNB which beam of the SCell has been received. Therefore, the UE can determine the beam for communication as early as possible and can perform SCell addition and correction processing with low latency.

[0770] According to embodiment 6, a communication system is provided, which includes, for example, a communication terminal device and a base station device for wireless communication with the communication terminal device using wireless beams. A cell formed by the base station device is spatially separated by multiple wireless beams belonging to the base station device, and the base station device sets carrier aggregation on a wireless beam unit basis. Furthermore, the multiple wireless beams can be configured as follows: Figure 8 As illustrated, it can be formed by multiple DUs (in other words, TRPs), or it can be formed by a single DU.

[0771] Based on this structure, carrier aggregation is configured using wireless beam units. Therefore, cells supporting beamforming can be made into cells for carrier aggregation, as described above, increasing the available wireless resources. This enables the provision of high-speed and high-capacity communication services.

[0772] Here, the above structure can be modified in various ways as described above and as shown in the following variations 1 to 2.

[0773] Variation 1 of Implementation Method 6.

[0774] In NR, to ensure wideband frequency resources, high-frequency bands are required. However, high-frequency bands are prone to drastic channel quality degradation due to congestion between the gNB antenna and the UE. Furthermore, transmission loss increases at high frequencies, necessitating the use of narrow-coverage beams. With narrow-coverage beams, beam changes occur frequently as the UE moves.

[0775] In the method disclosed in Implementation 6, when the UE performs beam setting and changes during CA, RRC signaling is required. Therefore, setting and changing the aggregated beam takes time, increasing the delay before communication with the desired beam. If the delay is large, the following situation may occur: the processing of beam setting and changes caused by congestion and UE movement may not be timely, making it impossible to continue SCell communication.

[0776] The method for solving the above problem is disclosed in this variation 1.

[0777] The gNB notifies the UE of the beams that can be formed by the SCell via RRC signaling. In Embodiment 6, the UE is notified of the beams being monitored via RRC signaling. In this variation 1, the beams that can be formed by the SCell are notified. In other words, the gNB notifies the UE of the beams that can be formed as CA in the SCells that can be set as CA. This notification can be performed on a per-UE basis. Information related to the beams used for communication can be the same as the beam-related information in Embodiment 6.

[0778] The gNB notifies the UE of SCell activation / deactivation information via MAC signaling. It can also notify the UE of SCell activation / deactivation information via RRC signaling.

[0779] Thus, the UE can identify which SCell is being monitored. However, this alone does not indicate which beam of that SCell can be used for communication.

[0780] The gNB notifies the UE of the activation / deactivation information of the beam composed of SCells via MAC signaling. MAC signaling can be used to notify the UE of the activation / deactivation information of the beam composed of activated SCells. It can also notify the UE of the activation of the beam being activated, rather than the activation / deactivation information of the beam composed of SCells. The beam information includes the beam identifier.

[0781] When changing the beam used for CA (Carrier Activation), the beam activation / deactivation settings can be changed. The gNB can notify the UE of the changed beam activation / deactivation information. The activation / deactivation information of the beam composed of SCells can be set as MAC control information. The activation / deactivation information of the beam composed of activated SCells can also be set.

[0782] The activation / deactivation information of the SCell and the activation / deactivation information of the beam can be combined into a single MAC CE. This reduces the amount of information and simplifies the processing of CA settings.

[0783] SCell activation / deactivation information and beam activation / deactivation information can be used as different MAC CEs. This allows the use of only the beam activation / deactivation MAC CE in the beam change settings within the SCell, instead of in the CA settings. This reduces the amount of information required for beam changes and simplifies beam change processing.

[0784] This document presents an example of using beam activation / deactivation information as part of MAC CE. The maximum number of beams that can be formed by a single cell can be predetermined. When using RRC signaling to notify the SCell-formed beams, beam-related information is provided, with beam indices ranging from 0 to the maximum value. In other words, they are numbered. The beam indices are associated with the beam ID and BRS. For example, a single cell can form a maximum of 7 beams. Indices from beam #0 to beam #6 are provided for the beams formed by the cell.

[0785] Figure 15 This is a diagram illustrating an example of a MAC CE (Machine Code Execution) indicating beam activation / deactivation information. It shows a maximum of seven beams in a single cell. The MAC CE consists of 8 bits. R is a reserved bit. B0 to B6 are bits indicating the activation / deactivation of each beam. For example, 1 can be set to activation and 0 to deactivation. B0 to B6 are the beam indices for each beam, set by RRC (Regulatory Control Code) signaling.

[0786] The beam activation / deactivation information for each SCell consists of 8 bits. This information is concatenated sequentially according to the SCell's index. The activation / deactivation information of the deactivated SCell can be set to deactivate all beams. Alternatively, the activation / deactivation information of only the SCell to be activated can be concatenated. The concatenation method can be statically predetermined by standards, etc. Both the gNB and the UE can recognize this method.

[0787] By setting the beam activation / deactivation information as MAC CE, the gNB can notify the UE of the activation / deactivation information of the beam formed by the SCell via MAC signaling.

[0788] Figure 16 and Figure 17 This is a diagram illustrating an example of the CA setup process for a beam unit that uses MAC signaling. Figure 16 and Figure 17 Connect at the location of boundary line BL541. Figure 16 and Figure 17 The process shown includes and Figure 13 and Figure 14 The process shown has the same steps, so the same steps are labeled with the same step number, and common descriptions are omitted.

[0789] In step ST5401, the gNB notifies the UE of the CA's SCell configuration information and related information about the beam corresponding to that SCell via beam 1 of the PCell. This notification uses RRC-specific signaling. In step ST5401, the beam corresponding to the SCell that is notified can be set as a beam that can be formed in the CA for the UE. Therefore, the gNB can notify the UE which beam in the SCell can be formed in the CA.

[0790] In step ST5402, the gNB notifies the UE of the activation / deactivation information of the SCell. This notification uses MAC control signaling. The activation / deactivation information is included in the notification via MAC CE. In step ST5403, the gNB notifies the UE of the activation / deactivation information of the beam of the activated SCell. This notification uses MAC control signaling. The activation / deactivation information is included in the notification via MAC CE.

[0791] In step ST5404, the UE receives the SS of the activated SCell and synchronizes it. In step ST5405, the UE receives the BRS of each beam and, based on the information of the beams that the SCell can form (specifically, at least one of the beam identifier and BRS structure and the beam index) notified by RRC signaling and the information of the activated beams (specifically, the beam index) notified by MAC signaling, detects the beam being monitored within the SCell. In step ST5406, the UE receives the Physical Downlink Control Channel (PDCCH) of the monitored beam.

[0792] Therefore, the gNB can communicate with the UE via beam 1 of the SCell.

[0793] Next, refer to Figure 17 An example of the procedure for changing the beam used by the gNB to communicate with the UE within the SCell is disclosed. In step ST5407, the gNB decides to change the beam used to communicate with the UE. For example, this can be decided by the MAC function unit of the gNB. In step ST5408, the gNB notifies the UE of the activation / deactivation information of the changed beam through beam 1 of the PCell. This information is contained in the MAC CE and notified by MAC signaling.

[0794] The gNB can notify the UE of the activation / deactivation information of the changed beam through beam 1 of the SCell. The gNB can determine which beam has better communication quality and use the beam with better communication quality for notification.

[0795] When notification is sent via the PCell beam, it will not be affected by the drastic degradation of the SCell beam's communication quality. The gNB can notify the UE of the CA's SCell configuration information and information related to the changed beam. The UE can then change to the beam notified by the gNB.

[0796] In step ST5409, the UE receives the BRS of each beam and, based on the information of the beams that the Scell ​​can form (specifically, at least one of the beam identifier and BRS structure and the beam index) notified by RRC signaling and the information of the activated beams after the change notified by MAC signaling (specifically, the beam index), detects the beams being monitored within the SCell. In step ST5410, the UE receives the Physical Downlink Control Channel (PDCCH) of the monitored beams.

[0797] Therefore, the beam of the SCell communicating with the UE can be changed from beam 1 to beam 2.

[0798] By employing the method disclosed in this variation 1, beam activation / deactivation can be performed via MAC signaling.

[0799] Therefore, the delay from the start of beam determination by the UE to the start of CA using a beam with better communication quality can be reduced. This also reduces the occurrence of problems where drastic communication quality degradation due to congestion and UE movement prevents the inability to initiate communication using the SCell.

[0800] Furthermore, it reduces the delay from when the UE determines the beam to when it switches to a beam with better communication quality. Therefore, it reduces the occurrence of communication interruptions using SCells due to sharp deterioration in communication quality caused by congestion and UE movement.

[0801] Therefore, beam setting and modification are instantaneous, reducing the delay until communication can be initiated using the desired beam. Consequently, the processing time for beam setting and modification is shortened, reducing the occurrence of communication interruptions and failures to initiate communication using the SCell due to congestion and UE movement.

[0802] Variation 2 of Implementation Method 6.

[0803] Other methods for solving the problem illustrated in Variation 1 are disclosed.

[0804] The gNB notifies the UE of the beams that can be formed by the SCell via RRC signaling. In Embodiment 6, the UE is notified of the beams being monitored via RRC signaling. In this variation 2, the beams that can be formed by the SCell are notified. In other words, the gNB notifies the UE of the beams that can be formed as CA in the SCells that can be set as CA. This notification can be performed on a per UE basis. Information related to the beams used for communication can be the same as the beam-related information in Embodiment 6.

[0805] The gNB notifies the UE of SCell activation / deactivation information via L1 / L2 control signals. It can also notify the UE of SCell activation / deactivation information via RRC signaling. By notifying the UE via L1 / L2 control signals, the gNB can achieve low-latency notification of SCell activation / deactivation.

[0806] As another method for the gNB to notify the UE of SCell activation / deactivation information, a method using MAC signaling can be employed. The method disclosed in Variation 1 of Implementation 6 can be applied. In this case, due to retransmission control, notification can be performed with a low reception error rate.

[0807] Thus, the UE can identify which SCell is being monitored. However, this alone does not indicate which beam of that SCell can be used for communication.

[0808] The gNB notifies the UE of the activation / deactivation information of the beam composed of SCells via L1 / L2 control signals. The gNB can also use L1 / L2 control signals to notify the UE of the activation / deactivation information of the beam composed of activated SCells. It can also notify the UE of the activation of the beam being activated, rather than the activation / deactivation information of the beam composed of SCells. The beam information includes the beam identifier.

[0809] When changing the beam used for CA (Cyclic Activation), the beam activation / deactivation settings can be changed. The gNB can notify the UE of the changed beam activation / deactivation information. The activation / deactivation information of the beam composed of SCells can be set as L1 / L2 control information. The activation / deactivation information of the beam composed of the activated SCells can also be set.

[0810] At least one of the activation / deactivation information of the SCell and the activation / deactivation information of the beam formed by the SCells can be used as a DCI. This information is notified to the UE from the gNB via the downlink. The activation / deactivation information of the SCell and the activation / deactivation information of the beam can be included in a single DCI. This reduces the amount of information and simplifies the CA setting process.

[0811] SCell activation / deactivation information and beam activation / deactivation information can be used as different DCIs. This allows for the use of only the beam activation / deactivation DCI in the beam change settings within the SCell, rather than in the CA settings. This reduces the amount of information required for beam changes and simplifies beam change processing.

[0812] A new format can be set in DCI to be used for the above information.

[0813] Beam indexes can be used as activation / deactivation information for both SCells and beams. Similar to Variation 1 of Implementation 6, a bitmap can be employed. This reduces the amount of information required.

[0814] The method for notifying beam activation / deactivation information is disclosed.

[0815] The gNB notifies the UE of beam activation / deactivation information via the L1 / L2 control signals of the SCell. It can also notify the UE of the beam to be activated. The UE can receive the beam from the activated SCell. For example, it can receive beams with higher receive power or quality. The UE determines the beam ID based on the BRS of the received beam and notifies the gNB of the determined beam ID. Alternatively, the UE can use the received beam to perform PRACH transmission and initiate RA processing, thereby notifying the gNB of the beam ID. The UE then monitors that beam.

[0816] The gNB, having received the beam ID from the UE, uses the L1 / L2 control signals of that beam to notify the UE of the beam to be activated for the UE. The UE monitors the activated beam. The UE receives the physical downlink control channel of the activated beam. One beam or multiple beams can be used. Thus, the UE can identify the activation / deactivation information of the SCell's beams.

[0817] In the above method, after the gNB decides to start CA and notifies the UE of the activation of the SCell for CA, it performs beam determination between the UE and the gNB. Therefore, a delay occurs before the UE communicates with the cell where CA is actually configured.

[0818] Other methods for notifying beam activation / deactivation information are disclosed.

[0819] The gNB notifies the UE of SCell beam activation / deactivation information via L1 / L2 control information from the PCell. It can notify the UE of the activation / deactivation information of the beams in the SCell being activated, or it can notify the UE of the activated beams within the SCell. The UE monitors the beams of the SCell notified by the PCell. The UE receives the physical downlink control channel of the activated beam. One beam or multiple beams can be used. Thus, the UE can identify the SCell beam activation / deactivation information.

[0820] For example, the information of the activated SCell and the information of the activated beam within that SCell can be included in the same DCI. The gNB simultaneously notifies the UE of this information, allowing the UE to receive BRS synchronously with the SCell, thereby determining the beam to be monitored and receiving the physical downlink control channel of that beam. The UE can monitor the beam of the SCell in a short period of time.

[0821] A DCI containing beam information of the SCell can be mapped to the physical downlink control channel of the PCell. The DCI containing the PCell information can be different from the DCI containing the SCell information, and the DCI containing the SCell information can contain beam information.

[0822] The above two methods for notifying activation / deactivation information of beams can be combined. An example of public combination is provided.

[0823] The gNB notifies the UE of the active beam information of a SCell via L1 / L2 control information from the PCell. The information of the active SCell and the active beam information within that SCell can be associated and included in the same DCI. The UE can monitor a beam of the SCell notified by the PCell. The UE receives the physical downlink control channel of the active beam.

[0824] The gNB notifies the UE of the activated beam information via the L1 / L2 control signal of one beam in the SCell. Alternatively, it can notify the SCell of beam activation / deactivation information. One beam or multiple beams can be used. The UE monitors the activated beam. The UE receives the physical downlink control channel of the activated beam.

[0825] In this method, the UE does not need to send uplink signals to the gNB to receive beam activation / deactivation information within the SCell. Therefore, the UE can determine which beam to use within the SCell earlier. Furthermore, it reduces the UE's power consumption.

[0826] Figures 18-20This diagram illustrates an example of the CA setting process for a beam unit using L1 / L2 control signals, and is an example of a notification method that combines the above two beam activation / deactivation information. Figures 18-20 Connect at the positions of boundary lines BL551 and BL552. Figures 18-20 The process shown includes and Figure 16 and Figure 17 The process shown has the same steps, so the same steps are labeled with the same step number, and common descriptions are omitted.

[0827] In step ST5501, the gNB notifies the UE of the activation / deactivation information of the SCell. This notification uses L1 / L2 control signals. The activation / deactivation information is included in the DCI for notification. In step ST5502, the gNB notifies the UE of the activation / deactivation information of one beam of the activated SCell. This notification uses L1 / L2 control signals. The activation / deactivation information is included in the DCI for notification.

[0828] In step ST5503, the UE receives the SS of the activated SCell and synchronizes it. In step ST5504, the UE receives the BRS of each beam and, based on the information of the beams that the SCell can form (specifically, at least one of the beam identifier and BRS structure and the beam index) notified by RRC signaling and the information of an activated beam (specifically, the beam index) notified by L1 / L2 control signals from the PCell, detects the beam being monitored within the SCell. In step ST5505, the UE receives the Physical Downlink Control Channel (PDCCH) of the monitored beam.

[0829] Therefore, the gNB can communicate with the UE via beam 1 of the SCell.

[0830] Reference Figure 19 In step ST5506, the gNB notifies the UE of the activation / deactivation information of the SCell beam via SCell beam 1. This notification uses L1 / L2 control signals. The activation / deactivation information is included in the notification via DCI.

[0831] In step ST5507, the UE receives the BRS of each beam and, based on the information of the beams that the Scell ​​can form (specifically, the beam identifier and at least one of the BRS structure and the beam index) notified by RRC signaling and the information of the active beams of the SCell notified by the L1 / L2 control signals from the SCell (specifically, the beam index), detects the beams being monitored within the SCell. In step ST5508, the UE receives the Physical Downlink Control Channel (PDCCH) of the monitored beams.

[0832] Therefore, the gNB can communicate with the UE via beam 2 of the SCell.

[0833] Next, refer to Figure 20 An example of the procedure for changing the beam used by the gNB to communicate with the UE within a SCell is disclosed. In step ST5509, the gNB decides to change the beam used to communicate with the UE. For example, this can be determined by the PHY function of the gNB's SCell. In step ST5510, the gNB notifies the UE of the activation / deactivation information of the changed beam through beam 1 of the SCell. This information is contained in the DCI and notified by the L1 / L2 control signals.

[0834] The gNB can notify the UE of the activation / deactivation information of the changed beam through beam 1 of the PCell. The gNB can determine which beam has better communication quality and use the beam with better communication quality for notification.

[0835] When notification is sent via the PCell beam, it will not be affected by the drastic degradation of the SCell beam's communication quality. The gNB can notify the UE of information related to the changed beam. The UE can then change to the beam notified by the gNB.

[0836] In step ST5511, the UE receives the BRS of each beam and, based on the information of the beams that the Scell ​​can form (specifically, the beam identifier and at least one of the BRS structure and the beam index) notified by RRC signaling and the information of the modified activated beams (specifically, the beam index) notified by the L1 / L2 control signals from the SCell, detects the beam being monitored within the SCell. In step ST5512, the UE receives the Physical Downlink Control Channel (PDCCH) of the monitored beam.

[0837] Therefore, the beam of the SCell that communicates with the UE can be changed from beam 2 to beam 3.

[0838] Therefore, by using the L1 / L2 control signals to notify beam information, the setting and modification of the converged beam can be implemented more dynamically compared to Embodiment 6 and its variant 1. This further reduces the time required for beam setting and modification, and decreases the delay before communication using the desired beam. Consequently, the processing time for beam setting and modification can be further shortened, reducing the occurrence of communication interruptions and failures to start communication using the SCell due to congestion and UE movement.

[0839] In the above method, it is not necessary to determine and set the optimal beam as the beam of the SCell notified by the PCell. A beam with sufficient communication quality can be set. After CA begins using this beam of the SCell, the optimal beam can be set during the change of the beam notified by the SCell. Since the SCell beam is measured after communication with the SCell begins, the measurement process in the UE becomes simpler and lower power consumption can be achieved.

[0840] The above method discloses a scenario where the gNB uses the L1 / L2 control information of the PCell to notify the UE of the activation of one beam in the SCell. This is not limited to one beam activation in the SCell; it can also include multiple beams. The gNB can notify the UE of multiple activation beams in the SCell through the L1 / L2 control information of the PCell.

[0841] The UE can monitor multiple beams of the SCell notified by the PCell. The UE receives the physical downlink control channel of the active beam.

[0842] The gNB notifies the UE of the activated beam information via the L1 / L2 control signal of one of the multiple beams in the SCell. Alternatively, it can notify the SCell of beam activation / deactivation information. One beam or multiple beams can be used. The UE monitors the activated multiple beams and can therefore receive the L1 / L2 control signal transmitted by one of those beams.

[0843] By setting multiple active beams in the SCell, even if the communication quality of some beams deteriorates, the information of the active beam can be notified by the other beams. This enables highly reliable and stable communication.

[0844] The methods disclosed in Embodiments 6 to 6 Modifications 2 can be appropriately combined. For example, the gNB uses the PCell and MAC signaling to notify the UE of the activation / deactivation information of the SCell. The gBN uses the PCell and MAC signaling to notify the UE of information related to the activated beam of the SCell. The UE starts communicating with the activated beam of the SCell. Then, the activation / deactivation information of the SCell beam is notified by the L1 / L2 control signal and the SCell.

[0845] By utilizing MAC signaling to notify the activated SCell and the activated beam, the reception error rate in the UE can be reduced. Therefore, CA (Cyclic Alignment) can be reliably set, thus reducing malfunctions between the gNB and the UE. L1 / L2 control signals are used to notify the SCell of beam activation / deactivation information, enabling dynamic and low-latency notification to the UE. Even in situations where the appropriate communication beam changes frequently due to high-frequency operation congestion or UE movement, the CA beam can be set and changed with low latency.

[0846] Therefore, by appropriately combining the methods disclosed in Embodiments 6 to 6 Modifications 2, the beam for CA can be set and changed with low delay according to the radio wave transmission conditions that change over time.

[0847] Implementation method 7.

[0848] In LTE, data flow from the Core Network (CN) to the Radio Access Network (RAN) is based on bearers. Bearers are configured between each node (see Non-Patent Document 1). In LTE, there is a one-to-one mapping between EPS bearers and DRBs (Data Radio Bearers).

[0849] However, regarding data flow in 5G, flow-based control between CN-RAN and bearer-based control within the RAN were investigated (refer to 3GPP R2-166892 (hereinafter referred to as "Reference 2")). When control between CN-RAN becomes flow-based, the existing EPS bearer configured between P-GW and UE, and the existing E-RAB configured between S-GW and UE, will not be configured. However, since bearer-based control is maintained within the RAN, the DRB will be configured as the radio bearer for data.

[0850] In 5G, the study investigates cases where QoS (Quality of Service) flows are used instead of service flows (see Reference 2). In 3GPP, using QoS tags for each packet for QoS flows is standardized. QoS tags are set by scalar values. Therefore, even different services / sessions with the same QoS will be classified as the same QoS flow. Furthermore, the study investigates cases where multiple QoS flows can be mapped to a single DRB.

[0851] Therefore, the gNB, acting as a node in the RAN, maps traffic from one or more different PDU (Protocol Data Unit) sessions to a DRB. The gNB sets the DRB based on the QoS of the traffic from the PDU sessions. The gNB then maps data from the PDU sessions to the set DRB.

[0852] Here, the CN in 5G is referred to as NG-CN. The study examines the scenario where the gNB sets up the DC (Dual Connectivity) within the NG-CN coverage area. The DC is set up for each bearer. The DC supports three bearer types: MCG (Master Cell Group) bearer, SCG (Secondary Cell Group) bearer, and segmented bearer (see Non-Patent Literature 1). In existing LTE DCs, the MeNB (primary eNB) requests the SeNB (secondary eNB) to set up the bearer.

[0853] However, existing bearer configuration requests utilize E-RAB parameters. E-RAB is not available in 5G's NG-CN. Therefore, E-RAB parameters cannot be used in DC bearer configuration requests. Consequently, the configuration methods for DCs (e.g., the bearer configuration request method from MgNB (primary gNB) to SgNB (secondary gNB) and the bearer configuration method for DCs within SgNBs) become unclear.

[0854] In this embodiment 7, a method for solving the above-mentioned problems is disclosed.

[0855] The SgNB uses QoS-related information from the PDU session to configure the DC bearer. The MgNB uses QoS-related information to request bearer configuration, which is included in the PDU session-related information notified by the NG-CN (CP). In 3GPP, it is studied how to notify the gNB of PDU session-related information from the NG-CN (CP) during PDU session establishment. The context of notifying the PDU session and including QoS-related information in the PDU session context as PDU session-related information has been studied (see Non-Patent Document 6). The QoS-related information included in the above-mentioned PDU session-related information can be used.

[0856] The SgNB uses QoS-related information from the PDU session context, either notified by the MgNB along with the bearer configuration request or included in the bearer configuration request message, to configure the DC DRB. In the case of configuring a split bearer, the MgNB can change the values ​​of the QoS-related information within the PDU session context and notify the SgNB of the changed values. The DC DRB is configured such that the bearers on the MgNB side and the SgNB side meet the QoS requirements requested by the PDU session.

[0857] The MgNB can notify the SgNB of the session identifier of the DC's PDU session. The PDU session identifier can be notified in conjunction with QoS-related information of the PDU session. It can be notified together with a bearer configuration request or included in the bearer configuration request message.

[0858] By notifying the PDU session ...

Claims

1. A communication system, characterized in that, include: User equipment; Multiple distributed units (DUs) that communicate wirelessly with the user equipment; as well as The central unit (CU) connected to the plurality of DUs, During movement among the plurality of DUs belonging to the CU, the CU uses a specified format on the CU-DU interface to send the RRC (Radio Resource Control) parameters used for wireless communication between the mobile target DU and the user equipment to the mobile target DU. The specified format is the same as the RRC signaling format for the user equipment. During the movement among the plurality of DUs belonging to the CU, the user equipment receives an identifier of a beam from the CU via a moving source DU for identifying the moving target DU. The user equipment uses the beam identified according to the identifier to send an uplink signal to the mobile target DU.

2. The communication system as described in claim 1, characterized in that, The RRC parameter is a parameter related to the period and offset of the scheduling request (SR).

3. The communication system as described in claim 1, characterized in that, The RRC parameter is related to the Ack (Acknowledgement) / Nack (Negative Acknowledgement) repetition.

4. The communication system as described in claim 1, characterized in that, The RRC parameter is a parameter related to the Sounding Reference Signal (SRS).

5. The communication system as described in claim 1, characterized in that, The RRC parameters are parameters related to Channel Quality Indicator (CQI) / Channel-State Information (CSI).

6. The communication system as described in claim 1, characterized in that, The RRC parameters are parameters related to Radio Link Control (RLC).

7. A central unit, comprising a user device, a plurality of distributed units (DUs) wirelessly communicating with the user device, and a central unit (CU) connected to the plurality of DUs, characterized in that, During movement among the plurality of DUs belonging to the CU, the RRC (Radio Resource Control) parameters used for wireless communication between the mobile target DU and the user equipment are transmitted to the mobile target DU using a specified format on the CU-DU interface. The specified format is the same as the RRC signaling format for the user equipment. The identifier of the beam used to identify the mobile target DU is sent to the user equipment via the mobile source DU.

8. A user equipment, comprising the user equipment, a plurality of distributed units (DUs) wirelessly communicating with the user equipment, and a central unit (CU) connected to the plurality of DUs, characterized in that, During movement among the plurality of DUs belonging to the CU, wireless communication is conducted with the mobile target DU that performs wireless communication using RRC (Radio Resource Control) parameters received from the CU. The RRC parameters are received from the CU using a specified format on the CU-DU inter-interface interface. The specified format is the same as the RRC signaling format for the user equipment. During the movement among the plurality of DUs belonging to the CU, an identifier for identifying the moving target DU is received from the CU via the moving source DU. Uplink signals are transmitted to the mobile target DU using the beam identified by the identifier.

Images