Communication terminals, base stations, and communication systems

Abstract

To provide a low-latency and highly reliable wireless communication technique.SOLUTION: A communication system includes a plurality of communication terminals (UE) capable of communicating with each other in a sidelink, and a base station that wirelessly communicates with each of the plurality of communication terminals. An SLBWP, which is a bandwidth portion (BWP) for the sidelink, is set separately from a ULBWP, which is a bandwidth portion for an uplink.SELECTED DRAWING: Figure 35

Description

Technical Field

[0001] The present invention relates to wireless communication technology.

Background Art

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

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

[0004] The decisions made by 3GPP regarding the frame structure in LTE systems, as described in Non-Patent Document 1 (Chapter 5), will be explained using Figure 1. Figure 1 is an explanatory diagram showing the structure of a radio frame used in an LTE communication system. In Figure 1, one radio frame is 10ms. A radio frame is divided into 10 subframes of equal size. Each subframe is divided into two slots of equal size. Downlink synchronization signals are included in the 1st and 6th subframes of each radio frame. The synchronization signals consist of a primary synchronization signal (P-SS) and a secondary synchronization signal (S-SS).

[0005] The 3GPP's decisions regarding channel configuration in LTE systems are described in Non-Patent Document 1 (Chapter 5). It is assumed that the same channel configuration as non-CSG cells will be used in CSG (Closed Subscriber Group) cells.

[0006] The Physical Broadcast Channel (PBCH) is a channel used for downlink transmission from base station equipment (hereinafter sometimes simply referred to as "base station") to communication terminal equipment (hereinafter sometimes simply referred to as "mobile terminal") and other such devices. A PBCH transport block is mapped to four subframes within a 40ms interval. There is no explicit signaling at 40ms timing.

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

[0008] The Physical Downlink Control Channel (PDCCH) is the channel used for downlink transmission from the base station to the communication terminal. The PDCCH notifies 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 carries the Uplink Scheduling Grant. The PDCCH also carries Ack (Acknowledgement) / Nack (Negative Acknowledgement), which are response signals to uplink transmissions. The PDCCH is also called the L1 / L2 control signal.

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

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

[0011] The Physical Uplink Control Channel (PUCCH) is the channel used for uplink transmission from the communication terminal to the base station. The PUCCH carries the Ack / Nack response signal for downlink transmission. The PUCCH also carries Channel State Information (CSI). The CSI consists of the Rank Indicator (RI), Precoding Matrix Indicator (PMI), and Channel Quality Indicator (CQI) report. RI is the rank information of the channel matrix in MIMO. PMI is information of the precoding weight matrix used in MIMO. CQI is quality information indicating the quality of the received data or the quality of the communication channel. The PUCCH also carries a Scheduling Request (SR).

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

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

[0014] The downlink reference signal (RS) is a well-known symbol in LTE communication systems. Five types of downlink reference signals are defined: Cell-specific Reference Signal (CRS), MBSFN Reference Signal, UE-specific Reference Signal (UE-specific), Demodulation Reference Signal (DM-RS), Positioning Reference Signal (PRS), and Channel State Information Reference Signal (CSI-RS). One measurement of the physical layer of a communication terminal is the Reference Signal Received Power (RSRP).

[0015] Similarly, the uplink reference signals are also known symbols for LTE communication systems. Two types of uplink reference signals are defined: the Demodulation Reference Signal (DM-RS) and the Sounding Reference Signal (SRS).

[0016] This section explains the transport channel described in Non-Patent Document 1 (Chapter 5). Of the downlink transport channels, the Broadcast Channel (BCH) broadcasts to the entire coverage of the base station (cell). The BCH is mapped to the Physical Broadcast Channel (PBCH).

[0017] Downlink Shared Channels (DL-SCH) are subject to retransmission control using HARQ (Hybrid ARQ). DL-SCH can broadcast to the entire coverage of a base station (cell). DL-SCH supports dynamic or semi-static resource allocation. Semi-static resource allocation is also called persistent scheduling. DL-SCH supports discontinuous reception (DRX) for communication terminals to reduce power consumption. DL-SCH is mapped to Physical Downlink Shared Channels (PDSCH).

[0018] Paging Channels (PCHs) support DRX for communication terminals to enable low power consumption for those terminals. PCHs are required to broadcast across the entire coverage of a base station (cell). PCHs are mapped to physical resources, such as Physical Downlink Shared Channels (PDSCHs), which are dynamically available for traffic.

[0019] Multicast channels (MCHs) are used for broadcasting across the entire coverage of a base station (cell). MCHs support SFN synthesis of MBMS (Multimedia Broadcast Multicast Service) services (MTCH and MCCH) in multi-cell transmission. MCHs support quasi-static resource allocation. MCHs are mapped to PMCHs.

[0020] Among the uplink transport channels, the Uplink Shared Channel (UL-SCH) is subject to retransmission control using HARQ (Hybrid ARQ). UL-SCH supports dynamic or semi-static resource allocation. UL-SCH is mapped to the Physical Uplink Shared Channel (PUSCH).

[0021] Random Access Channels (RACHs) are limited to control information. RACHs carry a risk of collisions. RACHs are mapped to Physical Random Access Channels (PRACHs).

[0022] This section explains HARQ. HARQ is a technology that improves the communication quality of a transmission path by combining Automatic Repeat reQuest (ARQ) and Forward Error Correction. HARQ has the advantage that error correction works effectively through retransmission even on transmission paths where the communication quality changes. In particular, it is possible to achieve further quality improvement by combining the reception results of the initial transmission and the retransmission during retransmission.

[0023] Here is an example of how to retransmit data. If the receiving side is unable to correctly decode the received data, in other words, if a CRC (Cyclic Redundancy Check) error occurs (CRC=NG), the receiving side sends "Nack" to the sending side. Upon receiving "Nack," the sending side retransmits the data. If the receiving side is able to correctly decode the received data, in other words, if no CRC error occurs (CRC=OK), the receiving side sends "Ack" to the sending side. Upon receiving "Ack," the sending side sends 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 downstream channel for broadcast system control information. The BCCH, being a logical channel, is mapped to the broadcast channel (BCH), which is a transport channel, or to the downstream shared channel (DL-SCH).

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

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

[0027] A Multicast Control Channel (MCCH) is a downlink channel for one-to-many transmission. MCCHs are used to transmit MBMS control information for one or more MCCHs from the network to communication terminals. MCCHs are only used by communication terminals receiving MBMS. MCCHs are mapped to the Multicast Channel (MCH), which is the transport channel.

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

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

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

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

[0032] Location tracking of communication terminals is performed in units of areas consisting of one or more cells. Location tracking is performed to track the location of communication terminals even when they are in standby mode, and to enable them to be called, in other words, to allow them to receive calls. This area used for location tracking of communication terminals is called the tracking area.

[0033] Furthermore, 3GPP is working on the Long Term Evolution Advanced (LTE-A) standard as Release 10 (see Non-Patent Documents 3 and 4). LTE-A is based on the LTE wireless communication method and incorporates several new technologies.

[0034] In LTE-A systems, carrier aggregation (CA), which involves aggregating two or more component carriers (CCs) to support wider transmission bandwidths up to 100 MHz, is being considered. CA is described in Non-Patent Document 1.

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

[0036] Depending on the capabilities of the UE, secondary cells (SCells) are configured to form a set of serving cells together with PCells. On the downlink, the carrier corresponding to the SCell is the Downlink Secondary Component Carrier (DL SCC). On the uplink, the carrier corresponding to the SCell is the Uplink Secondary Component Carrier (UL SCC).

[0037] A set of serving cells consisting of one PCell and one or more SCells is configured for a single UE.

[0038] Furthermore, new technologies in LTE-A include technologies that support wider bandwidths (Wider bandwidth extension) and technologies such as Coordinated Multiple Point transmission and reception (CoMP). The CoMP technology being considered by 3GPP for LTE-A is described in Non-Patent Document 1.

[0039] Furthermore, 3GPP is considering using small eNBs (sometimes referred to as "small-scale base station equipment") that constitute small cells to cope with the enormous traffic of the future. For example, technologies are being considered to increase communication capacity by improving frequency utilization efficiency by installing a large number of small eNBs to constitute a large number of small cells. Specifically, this includes dual connectivity (DC), in which a UE connects to and communicates with two eNBs. DC is described in Non-Patent Document 1.

[0040] In some cases, among eNBs that perform dual connectivity (DC), one is called the "master eNB (abbreviated as MeNB)" and the other is called the "secondary eNB (abbreviated as SeNB)".

[0041] Mobile network traffic is on the rise, and communication speeds are also increasing. Further speed increases are expected once LTE and LTE-A are fully operational.

[0042] Furthermore, in response to the increasing sophistication of mobile communications, a fifth-generation (sometimes referred to as "5G") wireless access system is being considered, with the goal of launching services after 2020. For example, in Europe, the METIS organization has compiled the requirements for 5G (see Non-Patent Document 5).

[0043] In 5G wireless access systems, the requirements include achieving 1000 times the system capacity, 100 times the data transmission speed, one-tenth (1 / 10) the data processing delay, and 100 times the number of simultaneous connections for communication terminals compared to LTE systems, while also achieving further reductions in power consumption and equipment costs.

[0044] To meet these requirements, 3GPP is working on the 5G standard as Release 15 (see Non-Patent Documents 6-18). The technology for the wireless portion of 5G is called "New Radio Access Technology" ("New Radio" is abbreviated as "NR").

[0045] The NR system is being developed based on the LTE system and LTE-A system, but the following changes and additions have been made compared to the LTE system and LTE-A system.

[0046] For NR access, OFDM is used for the downstream direction, and OFDM and DFT-s-OFDM (DFT-spread-OFDM) are used for the upstream direction.

[0047] NR allows for the use of higher frequencies compared to LTE, in order to improve transmission speed and reduce processing delays.

[0048] In NR (Noise Reduction), cell coverage is ensured by forming a narrow beam-shaped transmission and reception range (beamforming) and changing the direction of the beam (beam sweeping).

[0049] In NR's frame configuration, various subcarrier intervals, i.e., various numerologies, are supported. In NR, regardless of the numerology, one subframe is 1 millisecond, and one slot consists of 14 symbols. Furthermore, the number of slots contained in one subframe is one for a numerology with a subcarrier interval of 15 kHz, and increases proportionally with the subcarrier interval for other numerologies (see Non-Patent Document 13 (TS38.211 V15.2.0)).

[0050] In NR, the downlink synchronization signal is transmitted from the base station as a synchronization signal burst (SS burst) at a predetermined period and for a predetermined duration. The SS burst consists of a synchronization signal block (SS block) for each beam of the base station. The base station transmits the SS block for each beam, changing beams within the duration of the SS burst. The SS block consists of P-SS, S-SS, and PBCH.

[0051] In noise reduction (NR), the effect of phase noise is reduced by adding a Phase Tracking Reference Signal (PTRS) as the downstream reference signal. Similarly, a PTRS is also added to the upstream reference signal.

[0052] In NR, Slot Format Indication (SFI) information has been added to the PDCCH to allow for flexible switching between DL / UL within a slot.

[0053] Furthermore, in NR, a portion of the carrier frequency band (sometimes referred to as the Bandwidth Part (BWP)) is pre-configured by the base station for the UE, and the UE performs transmission and reception with the base station in the BWP, thereby reducing the power consumption of the UE.

[0054] 3GPP is considering several data center configurations, including a data center with LTE and NR base stations connected to an EPC, a data center with NR base stations connected to a 5G core system, and a data center with LTE and NR base stations connected to a 5G core system (see Non-Patent Documents 12, 16, and 19).

[0055] Furthermore, 3GPP is considering several new technologies. For example, time-sensitive networks (see Non-Patent Document 20 (3GPP RP-182090)), local caching (see Non-Patent Document 21 (3GPP RP-172726)), and preemption in sidelinks (see Non-Patent Document 22 (3GPP R1-1810593)) are being considered. [Prior art documents] [Non-patent literature]

[0056] [Non-Patent Document 1] 3GPP TS 36.300 V15.2.0 [Non-Patent Document 2] 3GPP S1-083461 [Non-Patent Document 3] 3GPP TR 36.814 V9.2.0 [Non-Patent Document 4] 3GPP TR 36.912 V15.0.0 [Non-Patent Document 5] "Scenarios, requirements and KPIs for 5G mobile and wireless system", ICT-317669-METIS / D1.1

Non-licensed Document 6

Non-licensed Document 7

Non-licensed literature 9

Non-licensed literature 10

Non-licensed Document 11

Non-licensed Document 12

Non-licensed Document 13

Non-licensed Document 14

Non-licensed Document 15

Non-licensed Document 16

Non-licensed Document 17

Non-licensed Document 18

Non-licensed Document 19

Non-licensed Document 20

Non-licensed Document 21

Non-licensed Document 22

[0057] In 3GPP, support for Time Sensitive Networks (TSNs) is being considered to meet the requirements of Ultra-Reliable and Low Latency Communication (URLLC) (see Non-Patent Document 20 (3GPP RP-182090)). In Time Sensitive Networks, time synchronization between multiple UEs is required (see Non-Patent Document 23 (3GPP TR22.804 V16.1.0)). As a method for time synchronization between multiple UEs, time synchronization between a base station and each UE is being considered (see Non-Patent Documents 24 (3GPP R3-185808), 25 (3GPP TS36.331 V15.3.0), and 26 (3GPP R2-1817173)). However, when mobility occurs, UEs do not know the propagation delay between themselves and the destination base station, so the UE time may change abruptly before and after mobility. This can lead to malfunctions in systems that use TSN.

[0058] Furthermore, in order to satisfy the low-latency requirement in NR sidelink (SL) communication, the introduction of preemption in NR SL communication has been proposed (see Non-Patent Document 22 (3GPP R1-1810593) and Non-Patent Document 27 (3GPP R1-1810775)). However, since a specific method for SL preemption has not been disclosed, a problem arises in SL communication where preemption cannot be implemented, and the low-latency requirement cannot be met.

[0059] In view of the above problems, one of the objectives of the present invention is to provide a low-latency, high-reliability wireless communication technology for NR. [Means for solving the problem]

[0060] According to the present invention, a communication terminal is provided in a communication system comprising a plurality of communication terminals that can communicate with each other in a sidelink, and a base station that wirelessly communicates with each of the plurality of communication terminals, wherein the SLBWP, which is the bandwidth portion for the sidelink, is set separately from the ULBWP, which is the bandwidth portion for the uplink.

[0061] Furthermore, according to the present invention, a base station is provided in a communication system comprising a plurality of communication terminals that can communicate with each other in a sidelink, and a base station that wirelessly communicates with each of the plurality of communication terminals, wherein the SLBWP, which is the bandwidth portion for the sidelink, is set separately from the ULBWP, which is the bandwidth portion for the uplink. Furthermore, according to the present invention, a communication system is provided comprising a plurality of communication terminals that can communicate with each other in a sidelink, and a base station that wirelessly communicates with each of the plurality of communication terminals, wherein the SLBWP, which is the bandwidth portion (BWP) for the sidelink, is set separately from the ULBWP, which is the bandwidth portion for the uplink. [Effects of the Invention]

[0062] According to the present invention, it is possible to provide wireless communication technology with low latency and high reliability.

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

[0064] [Figure 1] This is an explanatory diagram showing the configuration of wireless frames used in LTE communication systems. [Figure 2] This block diagram shows the overall configuration of the LTE communication system 200 as discussed in 3GPP. [Figure 3] This is a block diagram showing the overall configuration of the NR communication system 210 as discussed in 3GPP. [Figure 4] This is a diagram illustrating the configuration of a data center using eNBs and gNBs connected to the EPC. [Figure 5] This is a diagram showing the configuration of the DC using gNB connected to the NG core. [Figure 6] This is a diagram showing the configuration of the DC with eNBs and gNBs connected to the NG core. [Figure 7] This is a diagram showing the configuration of the DC with eNBs and gNBs connected to the NG core. [Figure 8] Figure 2 is a block diagram showing the configuration of the mobile terminal 202. [Figure 9] Figure 2 is a block diagram showing the configuration of base station 203. [Figure 10] This block diagram shows the configuration of MME. [Figure 11] This is a block diagram showing the configuration of 5GC. [Figure 12] This is a flowchart illustrating the general process from cell search to standby operation performed by a communication terminal (UE) in an LTE communication system. [Figure 13] This figure shows an example of a cell configuration in an NR system. [Figure 14] This figure shows an overview of the UE time correction operation when a handover occurs in Embodiment 1. [Figure 15] This is a sequence diagram showing the operation of UE time correction when a handover occurs in Embodiment 1. [Figure 16] This sequence diagram shows another example of the UE time correction operation when a handover occurs, according to Embodiment 1. [Figure 17] This sequence diagram illustrates an example of Embodiment 1 in which the UE estimates the TA of the destination base station and performs UE time correction when a handover occurs. [Figure 18] This is a sequence diagram showing an example of the time correction operation between base stations in a modified example of Embodiment 1. [Figure 19]This is a sequence diagram illustrating the switching of PDU sessions used for data transmission and the switching of base stations to which the UE is connected, according to Embodiment 2. [Figure 20] This is a sequence diagram illustrating the switching of PDU sessions used for data transmission and the switching of base stations to which the UE is connected, according to Embodiment 2. [Figure 21] The second embodiment is a sequence diagram illustrating another example of the switching of PDU sessions used for data transmission and the switching of base stations to which the UE is connected. [Figure 22] The second embodiment is a sequence diagram illustrating another example of the switching of PDU sessions used for data transmission and the switching of base stations to which the UE is connected. [Figure 23] This diagram shows an overview of preemption in SL communication according to Embodiment 4. [Figure 24] This figure shows a first example of a preemption method in SL communication according to Embodiment 4. [Figure 25] This figure shows a second example of a preemption method in SL communication according to Embodiment 4. [Figure 26] This figure shows a third example of a preemption method in SL communication, according to Embodiment 4. [Figure 27] This figure shows a fourth example of a preemption method in SL communication, according to Embodiment 4. [Figure 28] This diagram shows an overview of preemption in SL communication, as shown in the modified example 1 of Embodiment 4. [Figure 29] This figure shows a first example of a preemption method in SL communication, as a modified example of Embodiment 4. [Figure 30] This figure shows a second example of a preemption method in SL communication, as a modified example of Embodiment 4. [Figure 31] This figure shows a third example of a preemption method in SL communication, as a modified example of Embodiment 4. [Figure 32]This figure shows the case in Embodiment 5 where SLRP is set for the UL carrier of Uu. [Figure 33] This figure shows the case in Embodiment 5 where preemption is permitted for SL communication for Uu's UL resource. [Figure 34] This figure shows the case in Embodiment 5 where preemption is permitted for Uu UL communication for resources within SLRP. [Figure 35] This figure shows the case in Embodiment 6 where two SLRPs and SLBWPs are configured within the same carrier. [Figure 36] Embodiment 7 is a conceptual diagram showing that SL supports SUL in addition to non-SUL. [Figure 37] This figure shows the case in Embodiment 7 where the numerology is the same for both the non-SUL and SUL versions. [Figure 38] This figure shows the case in Embodiment 7 where the numerology is different for non-SUL and SUL. [Figure 39] This figure shows an example of a sequence for performing SL communication using SL SUL in Embodiment 7. [Figure 40] This figure shows an example of a sequence for performing SL communication using SL SUL in Embodiment 7. [Figure 41] This figure shows another example of a sequence for performing SL communication with SL SUL in Embodiment 7. [Figure 42] This figure shows another example of a sequence for performing SL communication with SL SUL in Embodiment 7. [Modes for carrying out the invention]

[0065] Embodiment 1. Figure 2 is a block diagram showing the overall configuration of the LTE communication system 200 being discussed in 3GPP. Figure 2 will be explained below. The radio access network is called E-UTRAN (Evolved Universal Terrestrial Radio Access Network) 201. The mobile terminal equipment (hereinafter referred to as "User Equipment: UE") 202, which is a communication terminal device, can communicate wirelessly with the base station equipment (hereinafter referred to as "Base Station (E-UTRAN NodeB: eNB)") 203 and transmits and receives signals wirelessly.

[0066] Here, "communication terminal equipment" includes not only mobile terminal equipment such as portable mobile phone terminals, but also stationary devices such as sensors. In the following explanation, "communication terminal equipment" may sometimes be simply referred to as "communication terminal."

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

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

[0069] In RRC_IDLE mode, tasks such as PLMN (Public Land Mobile Network) selection, System Information (SI) notification, paging, cell re-selection, and mobility are performed. In RRC_CONNECTED mode, mobile terminals have an RRC connection and can send and receive data with the network. In RRC_CONNECTED mode, tasks such as handover (HO) and neighbor cell measurement are also performed.

[0070] Base station 203 consists of one or more eNB207 units. The system, comprising the core network EPC (Evolved Packet Core) and the wireless access network E-UTRAN201, is called EPS (Evolved Packet System). The EPC and E-UTRAN201 are sometimes collectively referred to as the "network."

[0071] The eNB207 is connected via an S1 interface to a Mobility Management Entity (MME), or a Serving Gateway (S-GW), or an MME / S-GW unit (hereinafter sometimes referred to as "MME unit") 204 that includes both an MME and an S-GW, and control information is communicated between the eNB207 and the MME unit 204. Multiple MME units 204 may be connected to a single eNB207. The eNB207s are connected to each other via an X2 interface, and control information is communicated between the eNB207s.

[0072] The MME unit 204 controls the connection between the higher-level device, specifically the higher-level node, which is the base station eNB 207, and the mobile terminal (UE) 202. The MME unit 204 constitutes the core network EPC. The base station 203 constitutes the E-UTRAN 201.

[0073] The base station 203 may constitute one cell or multiple cells. Each cell has a predetermined range called coverage, which is the range within which it can communicate with the mobile terminal 202, and wireless communication is performed with the mobile terminal 202 within that coverage. When one base station 203 constitutes multiple cells, each cell is configured to communicate with the mobile terminal 202.

[0074] Figure 3 is a block diagram showing the overall configuration of the 5G communication system 210 being discussed in 3GPP. Figure 3 will now be explained. The radio access network is called NG-RAN (Next Generation Radio Access Network) 211. UE 202 can communicate wirelessly with NR base station equipment (hereinafter referred to as "NR base station (NG-RAN NodeB: gNB)") 213 and transmits and receives signals wirelessly. The core network is called the 5G Core (5GC).

[0075] If the control protocol for UE202, such as RRC (Radio Resource Control), and the user plane (hereinafter sometimes referred to as U-Plane), such as SDAP (Service Data Adaptation Protocol), PDCP (Packet Data Convergence Protocol), RLC (Radio Link Control), MAC (Medium Access Control), and PHY (Physical layer), are terminated at the NR base station 213, then the NG-RAN is composed of one or more NR base stations 213.

[0076] The functionality of the Radio Resource Control (RRC) control protocol between UE202 and NR base station 213 is the same as in LTE. The states of NR base station 213 and UE202 in RRC are RRC_IDLE, RRC_CONNECTED, and RRC_INACTIVE.

[0077] RRC_IDLE and RRC_CONNECTED are the same as in the LTE system. RRC_INACTIVE means that the connection between the 5G core and NR base station 213 is maintained while system information (SI) broadcasting, paging, cell re-selection, and mobility are performed.

[0078] The gNB217 is connected via an NG interface to an Access and Mobility Management Function (AMF), a Session Management Function (SMF), or a User Plane Function (UPF), or an AMF / SMF / UPF unit (hereinafter sometimes referred to as the "5GC unit") 214 that includes AMF, SMF, and UPF. Control information and / or user data are communicated between the gNB217 and the 5GC unit 214. The NG interface is a collective term for the N2 interface between the gNB217 and AMF, the N3 interface between the gNB217 and UPF, the N11 interface between AMF and SMF, and the N4 interface between UPF and SMF. Multiple 5GC units 214 may be connected to a single gNB217. The gNB217s are connected to each other via an Xn interface, and control information and / or user data are communicated between them.

[0079] Like base station 203, NR base station 213 may also consist of one or more cells. When one NR base station 213 consists of multiple cells, each cell is configured to communicate with UE 202.

[0080] The gNB217 may be divided into a Central Unit (CU) 218 ​​and a Distributed Unit (DU) 219. One CU218 is configured within the gNB217. One or more DU219s are configured within the gNB217. The CU218 is connected to the DU219 via an F1 interface, and control information and / or user data are communicated between the CU218 and the DU219.

[0081] Figure 4 shows the configuration of a DC with eNBs and gNBs connected to the EPC. In Figure 4, solid lines indicate U-Plane connections, and dashed lines indicate C-Plane connections. In Figure 4, eNB223-1 acts as the master base station, and gNB224-2 acts as the secondary base station (this DC configuration is sometimes referred to as EN-DC). Figure 4 shows an example where the U-Plane connection between the MME unit 204 and gNB224-2 is made via eNB223-1, but it may also be made directly between the MME unit 204 and gNB224-2.

[0082] Figure 5 shows the configuration of a DC with gNBs connected to the NG core. In Figure 5, solid lines indicate U-Plane connections, and dashed lines indicate C-Plane connections. In Figure 5, gNB224-1 acts as the master base station, and gNB224-2 acts as the secondary base station (this DC configuration is sometimes referred to as NR-DC). Figure 5 shows an example where the U-Plane connection between 5GC unit 214 and gNB224-2 is made via gNB224-1, but it may also be made directly between 5GC unit 214 and gNB224-2.

[0083] Figure 6 shows the configuration of a DC with eNBs and gNBs connected to the NG core. In Figure 6, solid lines indicate U-Plane connections, and dashed lines indicate C-Plane connections. In Figure 6, eNB226-1 acts as the master base station, and gNB224-2 acts as the secondary base station (this DC configuration is sometimes referred to as NG-EN-DC). Figure 6 shows an example where the U-Plane connection between 5GC unit 214 and gNB224-2 is made via eNB226-1, but it may also be made directly between 5GC unit 214 and gNB224-2.

[0084] Figure 7 shows another configuration of a DC with eNBs and gNBs connected to the NG core. In Figure 7, solid lines indicate U-Plane connections, and dashed lines indicate C-Plane connections. In Figure 7, gNB224-1 acts as the master base station, and eNB226-2 acts as the secondary base station (this DC configuration is sometimes referred to as NE-DC). Figure 7 shows an example where the U-Plane connection between 5GC unit 214 and eNB226-2 is made via gNB224-1, but it may also be made directly between 5GC unit 214 and eNB226-2.

[0085] Figure 8 is a block diagram showing the configuration of the mobile terminal 202 shown in Figure 2. The transmission process of the mobile terminal 202 shown in Figure 8 will now be explained. 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 passed to the encoder unit 304, where encoding processing such as error correction is performed. There may be data that is output directly from the transmission data buffer unit 303 to the modulation unit 305 without undergoing encoding processing. The data encoded by the encoder unit 304 is then modulated in the modulation unit 305. Precoding in MIMO may be performed in the modulation unit 305. The modulated data is converted into a baseband signal, then output to the frequency conversion unit 306, where it is converted to a wireless transmission frequency. After that, the transmission signal is sent from antennas 307-1 to 307-4 to the base station 203. Figure 8 illustrates the case where there are four antennas, but the number of antennas is not limited to four.

[0086] Furthermore, the reception processing of the mobile terminal 202 is performed as follows: A radio signal from the base station 203 is received by antennas 307-1 to 307-4. The received signal is converted from the radio reception frequency to a baseband signal by the frequency conversion unit 306, and demodulation processing is performed by the demodulation unit 308. Weight calculation and multiplication processing may also be performed in the demodulation unit 308. The demodulated data is passed to the decoder unit 309, where decoding processing such as error correction is performed. Of the decoded data, the control data is passed to the protocol processing unit 301, and the user data is passed to the application unit 302. The series of processes of the mobile terminal 202 are controlled by the control unit 310. Therefore, although the control unit 310 is omitted in Figure 8, it is connected to each of the units 301 to 309. In Figure 8, the number of antennas used by the mobile terminal 202 for transmission and the number of antennas used for reception may be the same or different.

[0087] Figure 9 is a block diagram showing the configuration of the base station 203 shown in Figure 2. The transmission process of the base station 203 shown in Figure 9 will now be explained. The EPC communication unit 401 transmits and receives data between the base station 203 and the EPC (MME unit 204, etc.). The 5GC communication unit 412 transmits and receives data between the base station 203 and the 5GC (5GC unit 214, etc.). The other base station communication unit 402 transmits and receives data with other base stations. The EPC communication unit 401, the 5GC communication unit 412, and the other base station communication unit 402 each 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, the 5GC communication unit 412, and the other base station communication unit 402, are stored in the transmission data buffer unit 404.

[0088] The data stored in the transmission data buffer unit 404 is passed to the encoder unit 405, where it undergoes encoding processing such as error correction. Some data may be output directly from the transmission data buffer unit 404 to the modulation unit 406 without undergoing encoding processing. The encoded data is then modulated in the modulation unit 406. Precoding in MIMO may be performed in the modulation unit 406. The modulated data is converted to a baseband signal, then output to the frequency conversion unit 407, where it is converted to a wireless transmission frequency. Subsequently, the transmission signal is sent from antennas 408-1 to 408-4 to one or more mobile terminals 202. Figure 9 illustrates the case with four antennas, but the number of antennas is not limited to four.

[0089] Furthermore, the reception processing of the base station 203 is performed as follows: A radio signal from one or more mobile terminals 202 is received by the antenna 408. The received signal is converted from the radio reception frequency to a baseband signal by the frequency conversion unit 407, and demodulation processing is performed by the demodulation unit 409. The demodulated data is passed to the decoder unit 410, where decoding processing such as error correction is performed. Of the decoded data, the control data is passed to the protocol processing unit 403, the 5GC communication unit 412, the EPC communication unit 401, or the other base station communication unit 402, while the user data is passed to the 5GC communication unit 412, the EPC communication unit 401, and the other base station communication unit 402. The series of processes of the base station 203 are controlled by the control unit 411. Therefore, although the control unit 411 is omitted in Figure 9, it is connected to each of the units 401 to 410. In Figure 9, the number of antennas used by the base station 203 for transmission and the number of antennas used for reception may be the same or different.

[0090] Figure 9 is a block diagram showing the configuration of base station 203, but base station 213 may have a similar configuration. Also, in Figures 8 and 9, the number of antennas on mobile terminal 202 and base station 203 may be the same or different.

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

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

[0093] 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, and performs all processing for the control plane (hereinafter sometimes referred to as C-Plane). The NAS security unit 505-1 performs security for NAS (Non-Access Stratum) messages, etc. The SAE bearer control unit 505-2 performs management of SAE (System Architecture Evolution) bearers, etc. The idle state mobility management unit 505-3 performs mobility management in the standby state (also called LTE-IDLE state or simply idle), generation and control of paging signals in the standby state, addition, deletion, updating, searching, and tracking area management for one or more mobile terminals 202 under its umbrella.

[0094] The MME204a distributes paging signals to one or more base stations 203. The MME204a also performs mobility control in the idle state. The MME204a manages the tracking area list when the mobile terminal is in the idle state and when it is in the active state. The MME204a initiates the paging protocol by sending paging messages to cells belonging to the registered tracking area of ​​the UE. The management of the CSG, CSG ID, and whitelist of the eNB207 connected to the MME204a may be performed by the idle state mobility management unit 505-3.

[0095] Figure 11 is a block diagram showing the configuration of the 5GC. Figure 11 shows the configuration of the 5GC unit 214 shown in Figure 3. Figure 11 shows the case where the 5GC unit 214 shown in Figure 5 includes the configurations of AMF, SMF, and UPF. The Data Network communication unit 521 transmits and receives data between the 5GC unit 214 and the Data Network. The base station communication unit 522 transmits and receives data via the S1 interface between the 5GC unit 214 and the base station 203, and / or the NG interface between the 5GC unit 214 and the base station 213. If the data received from the Data Network is user data, the user data is passed from the Data Network communication unit 521 to the base station communication unit 522 via the user-plane communication unit 523, and transmitted to one or more base stations 203 and / or base station 213. If the data received from base station 203 and / or base station 213 is user data, the user data is passed from base station communication unit 522 to Data Network communication unit 521 via user plane communication unit 523 and transmitted to the Data Network.

[0096] If the data received from the Data Network is control data, the control data is passed from the Data Network communication unit 521 to the session management unit 527 via the user plane control unit 523. The session management unit 527 passes the control data to the control plane control unit 525. If the data received from base station 203 and / or base station 213 is control data, the control data is passed from base station communication unit 522 to the control plane control unit 525. The control plane control unit 525 passes the control data to the session management unit 527.

[0097] The control plane control unit 525 includes the NAS security unit 525-1, the PDU session control unit 525-2, and the idle state mobility management unit 525-3, and performs all processing for the control plane (hereinafter sometimes referred to as C-Plane). The NAS security unit 525-1 performs security for NAS (Non-Access Stratum) messages, etc. The PDU session control unit 525-2 manages PDU sessions between the mobile terminal 202 and the 5GC unit 214, etc. The idle state mobility management unit 525-3 performs mobility management in the standby state (also referred to as RRC_IDLE state or simply idle), generation and control of paging signals in the standby state, addition, deletion, updating, searching, and tracking area list management for one or more mobile terminals 202 under its umbrella.

[0098] The 5GC unit 214 distributes paging signals to one or more base stations 203 and / or base station 213. The 5GC unit 214 also performs mobility control in the idle state. The 5GC unit 214 manages the tracking area list when the mobile terminal is in the idle state, inactive state, and active state. The 5GC unit 214 initiates the paging protocol by sending a paging message to a cell belonging to the tracking area where the UE is registered.

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

[0100] P-SS and S-SS together are called the Synchronization Signal (SS). Each PCI assigned to a cell has a synchronization code that corresponds one-to-one with that PCI. 504 different PCI combinations are being considered. These 504 PCI combinations are used for synchronization, and the PCI of the synchronized cell is detected (identified).

[0101] Next, for the synchronized cell, step ST602 detects the cell-specific reference signal (CRS), which is a reference signal (RS) transmitted from the base station to each cell, and measures the received power (RSRP) of the RS. The reference signal (RS) uses a code that corresponds one-to-one with the PCI. By correlating with this code, it is possible to isolate it from other cells. By deriving the code for the RS of the cell from the PCI identified in step ST601, it becomes possible to detect the RS and measure the received power of the RS.

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

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

[0104] Next, in step ST605, the DL-SCH of the cell is received based on the cell configuration information of the MIB, and SIB (System Information Block) 1 is obtained from the broadcast information BCCH. SIB1 contains information about accessing the cell, information about cell selection, and scheduling information for other SIBs (SIBk; an integer k ≥ 2). SIB1 also contains the Tracking Area Code (TAC).

[0105] Next, in step ST606, the communication terminal compares the TAC of the SIB1 received in step ST605 with the TAC portion of the Tracking Area Identity (TAI) in the Tracking Area List already held by the communication terminal. The Tracking Area List is also called the TAI list. TAI is identification information for identifying a tracking area and consists of 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 code number of the tracking area.

[0106] If, as a result of the comparison in step ST606, the TAC received in step ST605 is the same as a TAC included in the tracking area list, the communication terminal enters a waiting state in that cell. If, after comparison, the TAC received in step ST605 is not included in the tracking area list, the communication terminal requests a change in the tracking area through that cell to the Core Network (EPC), which includes the MME, etc., in order to perform a Tracking Area Update (TAU).

[0107] In the example shown in Figure 12, an example of the operation from cell search to standby in the LTE system is shown. However, in the NR system, in step ST603, the best beam may be selected in addition to the best cell. Also in the NR system, in step ST604, beam information, such as a beam identifier, may be obtained. Also in the NR system, in step ST604, scheduling information for the Remaining Minimum SI (RMSI) may be obtained. In the NR system, in step ST605, the RMSI may be received.

[0108] The devices constituting the core network (sometimes referred to as "core network devices") update the tracking area list based on the identification number (UE-ID, etc.) of the communication terminal sent from the communication terminal along with the TAU request signal. The core network devices send the updated tracking area list to the communication terminal. The communication terminal rewrites (updates) its TAC list based on the received tracking area list. After that, the communication terminal enters a waiting state in that cell.

[0109] The proliferation of smartphones and tablet devices has led to an explosive increase in cellular wireless communication traffic, raising concerns about a shortage of wireless resources worldwide. To address this, efforts are being made to improve frequency utilization efficiency by reducing the number of cells and promoting spatial separation.

[0110] In conventional cell configurations, cells composed of eNBs have relatively wide coverage. Traditionally, cells are configured to cover a certain area through the relatively wide coverage of multiple cells composed of multiple eNBs.

[0111] When subdivided into smaller cells, the cells composed of eNBs have narrower coverage than cells composed of conventional eNBs. Therefore, as before, a larger number of subdivided eNBs are needed to cover a given area compared to conventional eNBs.

[0112] In the following explanation, cells with relatively high coverage, such as those composed of conventional eNBs, will be referred to as "macrocells," and the eNBs that make up macrocells will be referred to as "macro eNBs." Similarly, cells with relatively low coverage, such as those that have been resized into smaller cells, will be referred to as "small cells," and the eNBs that make up small cells will be referred to as "small eNBs."

[0113] Macro eNB may be, for example, a "Wide Area Base Station" as described in Non-Patent Document 7.

[0114] A small eNB may be, for example, a low-power node, a local area node, or a hotspot. Alternatively, a small eNB may be a pico eNB constituting a picocell, a femto eNB constituting a femtocell, a HeNB, an RRH (Remote Radio Head), an RRU (Remote Radio Unit), an RRE (Remote Radio Equipment), or an RN (Relay Node). Furthermore, a small eNB may be a "Local Area Base Station" or "Home Base Station" as described in Non-Patent Document 7.

[0115] Figure 13 shows an example of a cell configuration in NR. In an NR cell, a narrow beam is formed and transmitted by changing its direction. In the example shown in Figure 13, base station 750 uses beam 751-1 to transmit and receive with a mobile terminal at a certain time. At other times, base station 750 uses beam 751-2 to transmit and receive with a mobile terminal. Similarly, base station 750 uses one or more of beams 751-3 to 751-8 to transmit and receive with a mobile terminal. In this way, base station 750 configures a wide-area cell.

[0116] Figure 13 shows an example where the base station 750 uses eight beams, but the number of beams may be different from eight. Also, in the example shown in Figure 13, the base station 750 uses one beam simultaneously, but it may use multiple beams.

[0117] In time synchronization between a base station and an UE in a TSN, the base station may broadcast or individually notify the UE of information regarding time synchronization. This information may be included in system information or in RRC signaling, such as in the signaling of DLInformationTransfer. This information may also be time reference information (hereinafter referred to as timing reference). The timing reference may be information that combines information about a given system frame with a time, for example, information indicating the time at the end of a given system frame. The UE may use this information to set its own UE time.

[0118] In the information included in the timing reference, instead of a predetermined system frame, information combining information about a predetermined subframe and a time, for example, information indicating the time at the end of the subframe, may be used. Alternatively, in the information included in the timing reference, information combining information about a predetermined slot and a time, for example, information indicating the time at the end of the slot, may be used. Instead of the time at the end as described above, the time at the beginning may be used. This allows the UE to reduce the waiting time until that time, and as a result, the UE can set its own time more quickly.

[0119] The timing reference transmitted from the base station to the UE may be generated using time information obtained by the base station from GNSS (Global Navigation Satellite System) or RNSS (Regional Navigation Satellite System), or using time information signaled to the base station by a location information server, or using time information signaled to the base station by a higher-level network device (e.g., AMF and / or SMF), or using time information obtained from a time server. For example, by having the base station transmit a timing reference using time information signaled to the base station by a higher-level network device to the UE, time synchronization across the entire communication system becomes possible.

[0120] The UE may correct its own UE time derived using the timing reference. This correction may, for example, compensate for the propagation delay between the base station and the UE. In this correction, for example, a timing advance (TA) may be used. In a communication system, for example, the TA may be considered as the round-trip propagation delay time between the base station and the UE. The UE may use a value obtained by adding half the value of the TA to its own UE time as its corrected own UE time.

[0121] However, the method for synchronizing the time when an UE (Underground User) is mobile is not disclosed. Therefore, when an UE is mobile, it cannot smoothly synchronize its time with the destination base station. For example, if the TA (Terminal Adapter) between the destination base station and the UE is different from the TA between the original base station and the UE, the UE time may change abruptly when correcting the UE time using the TA. This can lead to malfunctions in systems using TSN (Time Signal Network).

[0122] The solution to the aforementioned problem is disclosed below.

[0123] In correcting its own UE time, the UE simultaneously applies the timing reference received from the destination base station and the timing agent (TA) received from the destination base station. In other words, the UE does not correct its own UE time using only one of the timing reference or the TA.

[0124] The UE corrects its own UE time using both the timing reference of the destination base station and the TA of the destination base station simultaneously. For example, the UE time may be the time obtained by adding half the value of the TA to the timing reference. The UE may also use the UE time that it derived using the timing reference and TA from the source base station prior to this derivation.

[0125] The UE may retain the timing reference and / or timing reference received from the source base station. This retention may occur, for example, during or after the handover from the source base station to the destination base station. Post-handover retention may continue, for example, until both the destination base station's timing reference and timing reference are received. This retention may be performed on the timing reference received from the source base station. The UE may use the timing reference and timing reference to derive its own UE time. The UE's own clock may be used for this derivation. This derivation of the UE time using the timing reference and timing reference from the source base station may continue, for example, until the handover is complete. This allows the UE to maintain its own UE time even in the event of a handover failure.

[0126] The UE may establish uplink synchronization with the destination base station before correcting its own UE time using a timing reference and TA from the destination base station, or it may establish uplink synchronization with the destination base station simultaneously with the correction of its own UE time. In establishing this uplink synchronization, the UE may use the TA received from the destination base station. The UE may retain both the TA received from the destination base station and the TA received from the source base station. This allows the UE to quickly establish uplink synchronization with the destination base station while maintaining its own UE time.

[0127] The UE may release the TA and timing reference received from the source base station after correcting its own UE time using the timing reference and TA from the destination base station. This can, for example, reduce the memory usage of the UE.

[0128] Figure 14 shows an overview of the UE time correction operation when mobility occurs. In Figure 14, the time of the source base station and the destination base station are assumed to be synchronized with the reference time used as the standard in the 5G system. In Figure 14, the rectangle enclosed by a solid line represents the SFN.

[0129] At timing 1401 shown in Figure 14, the UE is assumed to know the propagation delay d1 from the mobile base station to its own UE. The mobile base station notifies the UE of a timing reference indicating that the time at the end of a predetermined SFN is t1. At timing 1402, the UE sets its own time at the time it receives the signal at the end of the SFN as the time (t1+d1) obtained by adding the propagation delay d1 to the time t1 included in the timing reference.

[0130] Assume that at timing 1403 shown in Figure 14, the UE has handed over from the source base station to the destination base station. At timing 1404, assume that the UE is aware of the propagation delay d2 from the destination base station to its own UE. The destination base station notifies the UE of a timing reference indicating that the time at the end of a predetermined SFN, different from the one described above, is t2. At timing 1405, the UE resets its own time at the time it received the signal at the end of the SFN to be the time (t2+d2) obtained by adding the propagation delay d2 to the time t2 included in the timing reference.

[0131] Figure 14 shows the case where the timing reference is information indicating the time at the end of a predetermined SFN. However, the time at the end of a predetermined subframe, the time at the end of a predetermined slot, the time at the end of a predetermined minislot, or the time at the end of a predetermined symbol may also be used. Instead of the aforementioned end times, the beginning time may be used. In the aforementioned cases, the rectangle enclosed by the solid line in Figure 14 may be a subframe, a slot, a minislot, or a symbol. This makes it possible to shorten the time from when the UE receives the timing reference until the predetermined time included in the timing reference. As a result, the UE can perform time synchronization more quickly.

[0132] A base station may broadcast a timing reference, or it may notify an individual UE. System information, RRC individual signaling, MAC signaling, or L1 / L2 signaling may be used to notify a timing reference. As an example of using MAC signaling for a timing reference, it may include information about the time at a predetermined timing (e.g., the beginning and end of the slot / minislot) of the slot or minislot containing the MAC signaling. As an example of using L1 / L2 signaling for a timing reference, it may include information about the time at a predetermined timing (e.g., the beginning and end of the slot / minislot) of the slot or minislot containing the L1 / L2 signaling.

[0133] A UE in the RRC_INACTIVE or RRC_IDLE state may obtain a timing reference. The UE may obtain the timing reference, for example, using system information broadcast by a base station. The UE may use the timing reference to set its own UE time. The UE may determine the uncertainty at its own UE time using the cell radius of the base station. The cell radius may, for example, be broadcast by the base station. This makes time synchronization possible in a communication system, for example, regardless of the UE's RRC state.

[0134] A timing reference notification from a base station to a UE may be a notification directed only to that UE (e.g., a notification that includes the UE's C-RNTI), or it may be a notification directed to multiple UEs. These multiple UEs may be, for example, multiple UEs within the beam to which the UE belongs (e.g., all UEs in the beam, or some UEs in the beam). These multiple UEs may also be all UEs. In the timing reference notification from the base station to these multiple UEs, a group common PDCCH may be used, for example. This allows the base station to notify many UEs of the timing reference, thereby improving the efficiency of the communication system.

[0135] The UE may request the base station to notify it of a timing reference. This request may be made, for example, using the signaling of a System Information Request, such as PRACH containing a random access preamble for a System Information Request, or RRC individual signaling may be used. As an example of using RRC individual signaling, the request may be included in the RRCReconfigurationComplete signaling, or a new RRC individual signaling may be established. Based on this request, the base station may notify the UE of the timing reference. This allows the UE to quickly obtain a timing reference without waiting for the system information broadcast cycle.

[0136] Another example of a timing reference request is that the UE may make such a request to a higher-level network device. The higher-level network device may be, for example, an AMF or an SMF. The request from the UE to the SMF may be made via the AMF. NAS signaling may be used for the request. The request may include, for example, information about the base station that will receive the timing reference, or it may not. The higher-level network device may use the request to instruct a base station to notify the UE of the timing reference. Signaling on the NG interface may be used for this instruction. The base station to which the higher-level network device instructs may be, for example, the same base station indicated in the information included in the request from the UE to the higher-level network device. The base station may use the instruction to notify the UE of the timing reference. This allows, for example, the higher-level network device to control the timing reference notification from the base station to the UE, thereby improving the efficiency of the communication system.

[0137] Another example of timing reference notification is the use of NAS signaling. An upstream network device may notify a UE of the timing reference. The upstream network device may be, for example, an AMF, an SMF, or an UPF. The SMF may provide the timing reference to the UE via the AMF. In the aforementioned case, the upstream network device may obtain the frame timing of the base station. The base station may notify the upstream network device of information regarding the frame timing. For example, an NG interface may be used for this notification. This enables, for example, the establishment of synchronization between UEs under different base stations in a 5G system. As another example, a location information server may notify a UE of the timing reference. Instead of obtaining the frame timing, the upstream network device may obtain subframe timing, slot timing, mini-slot timing, or symbol timing.

[0138] Figure 15 is a sequence diagram showing the operation of UE time correction during a handover. Figure 15 shows an example where both the source base station and the destination base station are NR base stations (gNBs). Figure 15 also shows an example where the UE obtains a timing reference from the destination gNB through signaling of downlink information transfer (DLInformationTransfer) from the destination gNB. In Figure 15, unless otherwise specified, it is assumed that an Xn interface is used for communication between the source gNB and the destination gNB.

[0139] In step ST1501 shown in Figure 15, the source gNB decides to hand over the UE to the destination gNB. In step ST1502, the source gNB notifies the destination gNB of a Handover Request. In step ST1503, the destination gNB performs Admission Control.

[0140] In step ST1504 shown in Figure 15, the destination gNB notifies the source gNB of a Handover Request Acknowledge. In step ST1505, the source gNB instructs the UE to hand over to the destination gNB. This instruction may be signaled, for example, by an RRC Reconfiguration signal. In step ST1506, the UE switches the connected base station from the source gNB to the destination gNB. In step ST1506, the UE may use its own UE time derived using the timing reference and TA received from the source gNB. In step ST1506, the UE may retain the timing reference and TA received from the source gNB.

[0141] In step ST1507 shown in Figure 15, the UE sends a PRACH to the destination gNB. In step ST1508, the destination gNB sends a Random Access Response (RAR) to the UE. The destination gNB may notify the UE in the RAR of step ST1508, including a Time Arrangement (TA) and / or an uplink grant. The UE may use the TA to establish uplink synchronization with the destination gNB in ​​step ST1509. In step ST1509, the UE may not correct its own time. The UE may use the uplink grant to notify the destination gNB in ​​step ST1510 that the handover is complete. This notification may be done, for example, using RRCReconfigurationComplete.

[0142] In step ST1511 shown in Figure 15, the destination gNB notifies the UE of the timing reference. RRC signaling, such as DLInformationTransfer, may be used for this notification. In step ST1512, the UE corrects its own time using the TA received in step ST1508 and the timing reference received in step ST1511. This time correction may, for example, be set as the time at the point specified in the timing reference by adding half the value of the TA to the time included in the timing reference. In step ST1512, the UE may discard the timing reference and the TA of the source gNB.

[0143] Figure 15 shows an example where RRC individual signaling is used for timing reference notification, but system information may also be used for timing reference notification. The UE may obtain the timing reference using system information. This makes it possible to reduce the amount of signaling from the destination gNB to the subordinate UEs, for example.

[0144] Step ST1510, shown in Figure 15, illustrates a case where the UE notifies the destination gNB that the handover is complete. This notification may include a timing reference notification request from the UE to the destination gNB. For example, the RRCReconfigurationComplete signaling sent from the UE to the destination gNB may include information regarding the timing reference notification request. The destination gNB may then use this request to notify the UE of the timing reference. This allows the destination gNB to quickly notify the UE of the timing reference.

[0145] The timing reference of the destination base station may be notified to the UE before the handover. The destination base station may notify the source base station of its own gNB timing reference. Signaling on the inter-base station interface (e.g., the Xn interface) may be used for this notification. For example, the timing reference may be notified by being included in the signaling of the handover request acknowledgment. The source base station may use the signaling of the response to notify the UE of the timing reference of the destination base station. For example, the source base station may include the timing reference in the signaling of the handover instruction (e.g., RRCReconfiguration). The UE may use the signaling of the instruction to obtain the timing reference of the destination base station. The UE may use the TA received from the destination base station and the timing reference to correct its own UE time. This correction may be performed, for example, after receiving the TA. This allows the UE to perform its own UE time correction quickly.

[0146] Figure 16 is a sequence diagram illustrating another example of UE time correction operation during a handover. Figure 16 shows an example where both the source and destination base stations are NR base stations (gNBs). Figure 16 also shows an example where the UE obtains a timing reference from the destination gNB using a handover instruction. In Figure 16, the same step numbers are used for processes common to Figure 15, and common explanations are omitted.

[0147] Steps ST1501 to ST1503 shown in Figure 16 are the same as those in Figure 15.

[0148] In step ST1604 shown in Figure 16, the destination gNB notifies the source gNB of a Handover Request Acknowledge. The destination gNB notifies the source gNB of its own timing reference in this response. In step ST1605, the source gNB instructs the UE to hand over to the destination gNB. The source gNB notifies the UE of this instruction, including the timing reference of the destination gNB. This instruction may, for example, use RRCReconfiguration signaling. In step ST1506, the UE switches the connected base station from the source gNB to the destination gNB. In step ST1506, the UE obtains the timing reference of the destination gNB from the handover instruction received in step ST1605. In step ST1506, the UE may use its own UE time derived using the timing reference and TA received from the source gNB. In step ST1506, the UE may hold the timing reference and TA received from the source gNB.

[0149] Steps ST1507 to ST1509 shown in Figure 16 are the same as those in Figure 15.

[0150] In step ST1611 shown in Figure 16, the UE corrects its own time using the TA received in step ST1508 and the timing reference received in step ST1605. The method of this time correction may be the same as the example disclosed in Figure 15. In step ST1611, the UE may discard the timing reference and the TA of the source gNB.

[0151] Step ST1510 shown in Figure 16 is the same as in Figure 15.

[0152] The UE may use only the most recent timing reference among multiple timing references it has received. For example, if the UE receives both a timing reference broadcast by the base station and a timing reference notified separately, the UE may use only the timing reference received later. The UE may discard the timing reference received earlier. This can, for example, improve the accuracy of the UE time.

[0153] Other solutions are disclosed. The UE may estimate the TA of the destination base station. The UE may correct its own UE time using the estimated TA and timing references from the destination base station. The UE may estimate the TA of the destination base station using the difference between the propagation delay from the destination base station and the propagation delay from the source base station. This estimation in the UE may be applicable, for example, when the slot timing (which may also be frame timing, hereafter the same) at the time of transmission of the destination base station and the source base station is the same. This estimation in the UE may be applied, for example, during mobility between TRPs (Transmission Reception Points). This allows the UE to correct its own UE time before random access processing begins.

[0154] The UE may retain the slot timing of the source base station. The UE may retain the TA of the source base station. The UE may obtain the slot timing of the destination base station. The UE may derive the TA of the destination base station using the difference between the slot timing of the destination base station and the TA from the source base station. For example, the UE may estimate the TA from the destination base station by adding twice the difference between the slot timing of the destination base station and the TA from the source base station. This allows the UE to correct its own time before performing random access processing with the destination base station. In the above, the UE may choose not to perform random access processing with the destination base station. The UE may establish uplink synchronization with the destination base station using the estimated TA. This allows the UE to perform handover processing quickly.

[0155] The signaling of the handover instruction from the source base station to the UE may include information regarding the frame timing of the source and destination base stations. This information may, for example, indicate whether the frame timings of both base stations are the same, whether TA estimation is performed, or the difference in frame timing between the two base stations. The information regarding the difference may be from the time of transmission at both base stations. The UE may use this information to perform TA estimation, or not, or to decide whether or not to perform TA estimation. This allows the UE to perform TA estimation quickly, for example.

[0156] The source base station may obtain information regarding the slot timing of the destination base station. The source base station may obtain this information, for example, by using cell search. The source base station may use the obtained information to derive information regarding the frame timing of the source base station and the destination base station. The information regarding the frame timing of the source base station and the destination base station may be the same as described above. The source base station may notify the UE of the derived information. As another example, the destination base station may obtain information regarding the slot timing of the source base station. The destination base station may obtain this information, for example, by using cell search. The destination base station may use the obtained information to notify the source base station of the slot timing of the source base station and the destination base station. For example, the source base station may notify the UE of this information. This allows, for example, the source base station or the destination base station to obtain information regarding the slot timing of each other's base stations.

[0157] The UE may obtain the frame timing of the destination gNB. This acquisition operation in the UE may be performed, for example, during measurement execution. The UE may notify the source gNB of the information obtained regarding the timing, or of the difference between the frame timing of the source gNB and the frame timing of the destination gNB. The aforementioned notification may be included, for example, in the measurement result report from the UE to the source gNB. The source gNB may use the notification to derive the TA in the connection between the destination gNB and the UE. The destination gNB may derive the TA and notify the source gNB. The source gNB may notify the UE of the TA. This notification may be included, for example, in a handover instruction from the source gNB to the UE. This allows the UE to quickly obtain the TA, and as a result, the UE can quickly establish synchronization with the destination gNB.

[0158] Figure 17 is a sequence diagram showing an example of how the UE estimates the TA of the destination base station and performs UE time correction during a handover. Figure 17 shows an example where both the source and destination base stations are NR base stations (gNBs). Figure 17 shows an example where the frame timings of the source and destination gNBs are the same. Figure 17 also shows an example where the UE obtains a timing reference from the destination gNB using a handover instruction. In Figure 17, the same step numbers are used for processes common to Figures 15 and 16, and common explanations are omitted.

[0159] In step ST1701 shown in Figure 17, the UE receives an SS block from the source gNB and obtains the frame timing of the source gNB.

[0160] Steps ST1501 to ST1503 shown in Figure 17 are the same as in Figure 15. Steps ST1604, ST1605, and ST1506 are the same as in Figure 16.

[0161] In step ST1707 shown in Figure 17, the UE receives an SS block from the destination gNB and obtains the frame timing of the destination gNB. In step ST1708, the UE estimates the TA at the destination gNB using the frame timing of the source gNB obtained in step ST1701 and the frame timing of the destination gNB obtained in step ST1707. In step ST1711, the UE corrects its own time using the TA estimated in step ST1708 and the timing reference received in step ST1605. The method of this time correction may be the same as the example disclosed in Figure 15. In step ST1711, the UE may discard the timing reference and the TA of the source gNB.

[0162] Steps ST1507 to ST1509, ST1611, and ST1510 shown in Figure 17 are the same as those in Figure 15.

[0163] Figure 17 shows an example where the UE performs self-UE time correction twice. This allows the UE to quickly acquire the time after handover, while also obtaining a highly accurate time through the second correction.

[0164] Figure 17 shows an example where the UE performs self-UE time correction twice, but self-UE time correction may be performed only once. For example, step ST1611 shown in Figure 17 may be omitted. This can reduce the processing load on the UE, for example.

[0165] Figure 17 shows an example where the UE performs step ST1707, which involves receiving SS blocks from the destination gNB, after the switching step ST1506 to the destination gNB. In contrast, the reception of SS blocks from the destination gNB may be performed before the switching to the destination gNB. For example, the UE may receive SS blocks from the destination gNB and retain the frame timing from the destination gNB during the measurement before the handover decision in step ST1501. This allows the UE to quickly perform destination TA estimation after switching to the destination gNB.

[0166] The UE may perform time correction using only the TA from the destination gNB. This correction may be performed, for example, when the time is synchronized between the source gNB and the destination gNB. The source gNB may notify the UE of information regarding time synchronization with the destination gNB. This information may be, for example, information regarding whether or not time synchronization is occurring, or information regarding the accuracy of time synchronization. The UE may perform time correction at its own UE using this time synchronization information and the TA from the destination gNB. This eliminates the need for the UE to receive a timing reference from the destination gNB, and as a result, enables rapid UE time correction.

[0167] A UE may discard a received timing reference. For example, if the UE handed over before the SFN included in the timing reference arrived, the UE may discard the timing reference. As another example, if the UE receives multiple timing references, the UE may discard the one that is not the most recent. This can prevent, for example, malfunctions in the UE time.

[0168] If a UE performs a handover before the SFN included in the timing reference arrives, it may set or correct its own UE time based on the SFN prior to the handover. This can, for example, reduce signaling between the base station and the UE.

[0169] The UE may amplify the uncertainty of its own time. The amount of uncertainty amplification may be determined using the clock accuracy of the UE. For example, the amount of uncertainty amplification may be the value obtained by multiplying the clock error per unit time of the UE by the elapsed time since the last UE time correction or the last uncertainty amplification. The amplification operation may be performed when a handover occurs or when a handover does not occur. The amplification operation may be performed, for example, when a timing reference from the base station is not received.

[0170] As another example, the UE may expand the uncertainty when a handover occurs. This expansion may occur when receiving a timing reference from the destination base station, or when not receiving a TA from the destination base station. For example, the UE may add a time value equivalent to the propagation delay over a distance of half the cell radius of the destination base station to the uncertainty. The UE may assume that the TA from the destination base station is a time value equivalent to the propagation delay over a distance of half the cell radius. The UE may use the timing reference from the destination base station and the assumed TA to correct the UE time. This allows the UE to quickly derive the UE time after a handover, for example.

[0171] The method in this embodiment 1 may be applied not only to handovers exemplified as inter-base station mobility, but also to inter-DU mobility and / or inter-TRP mobility. This makes it possible to prevent sudden changes in the time of the UE during mobility, even when a base station has multiple DUs and / or TRPs. As a result, malfunctions in the communication system can be prevented.

[0172] Here, base stations, DUs, and TRPs share the common characteristic of being communication devices configured to wirelessly communicate with UEs. Therefore, it is also possible to refer to inter-base station mobility, inter-DU mobility, and inter-TRP mobility as inter-communication device mobility.

[0173] The method in this embodiment 1 may also be applied to the movement of an UE between communication devices. For example, the method in this embodiment 1 may be applied when a TA is changed. The UE may correct its own time using the changed TA and the timing reference received after the TA change simultaneously. This makes it possible to prevent sudden changes in the UE's time when the TA is changed, and as a result, it is possible to prevent malfunctions in the communication system.

[0174] During the transfer between communication devices, the UE may correct its own UE time using the difference in downlink frame timing between the previous UE time correction and the time after the TA change, and the changed TA. In deriving this difference, the UE may retain information about the downlink frame timing at the previous UE time correction. This correction may be performed before the UE receives the timing reference after the TA change. This allows the UE to quickly correct its own UE time after receiving the changed TA, for example.

[0175] This embodiment 1 makes it possible to prevent sudden changes in the UE time when mobility occurs. As a result, it is possible to prevent malfunctions in systems that use TSN.

[0176] Modification 1 of Embodiment 1. Time synchronization between the base station and UE in a TSN may also be applied when using a DC.

[0177] Each time the UE receives a timing reference from the master base station and / or secondary base stations, it corrects its own time.

[0178] The UE may prioritize the timing reference from the master base station. For example, the UE may discard the timing reference transmitted from the secondary base station. This can, for example, avoid complexity in the communication system.

[0179] As another example, the UE may prioritize the timing reference from the secondary base station. For instance, if the master base station is an eNB and the secondary base station is a gNB, the UE may prioritize the timing reference from the secondary base station. The gNB may be more accurate than the eNB. This allows, for example, the UE time to be maintained with high accuracy.

[0180] As another example, the UE may decide which base station's timing reference to prioritize. This decision in the UE may use, for example, information about the time accuracy of each base station. For example, the UE may prioritize the timing reference from the base station with higher accuracy. This accuracy information may, for example, be information about the uncertainty contained in the timing reference. This can, for example, improve the accuracy of the UE time.

[0181] As another example, a base station may decide and notify the UE which base station's timing reference to prioritize. This notification may use RRC signaling, MAC signaling, or L1 / L2 signaling. The base station making this decision may be a master base station or a secondary base station. For example, information regarding the time accuracy of each base station may be used in this decision at the base station. For example, a master base station may decide to prioritize the timing reference from a base station with higher accuracy. This accuracy information may include, for example, information about the uncertainty contained in the timing reference. This can, for example, improve the accuracy of the UE time.

[0182] Another example of the determination in the UE is the validity period of the timing reference, as disclosed in Modification 2 of Embodiment 1. For example, the UE may prioritize the timing reference from the base station with the longer validity period. This can achieve, for example, the same effect as described above. The same may be applied to the determination in the base station.

[0183] Another example of the determination at the UE is the use of the maximum value of the validity period. The master base station and / or secondary base stations may inform the UE of information regarding the maximum validity period of the timing reference, or notify it individually. This prevents, for example, the alternation of the base stations determined by the UE due to timing reference updates over time. The same may be applied to the determination at the base stations.

[0184] As another example, the upstream network equipment may notify the UE of information regarding which base station's timing reference the UE will use. The upstream network equipment may be a 5G core device, such as an AMF or an SMF. As yet another example, the upstream network equipment may be an EPC, such as an MME. The notification may be, for example, NAS signaling, or a combination of signaling at the interface between the upstream network equipment and the base station and signaling at the interface between the base station and the UE (e.g., RRC signaling, MAC signaling, L1 / L2 signaling).

[0185] As another example, the UE may maintain multiple time zones. For instance, it may maintain both a time zone set and / or corrected using a timing reference from the master base station, and a time zone set and / or corrected using a timing reference from the secondary base station. This prevents sudden changes in the UE time zone, for example, even if the time zones differ between the master and secondary base stations. As a result, malfunctions in the communication system can be prevented.

[0186] Another example of a UE maintaining multiple time zones is that a different UE time zone may be assigned to each service requirement used by the UE. For example, a UE may maintain a separate UE time zone for each different network slicing. This allows for flexible time management across different service requirements used by the UE.

[0187] The timing reference information may include information about the source base station. The master base station and / or secondary base stations may include information about themselves in the timing reference information and notify the UE of this information. This information about the base station may be, for example, an identifier indicating whether it is a master base station or a secondary base station. The UE may use the information about the source base station to identify the base station that is the source of the timing reference.

[0188] The timing reference information may not include information about the source base station. The UE may use information about the communication path to the base station, such as information about the bearer used, to determine which time period the data is associated with. This can, for example, avoid complexity in the communication system.

[0189] Data transmitted from a base station to a UE may include or be appended with information indicating which base station's timing reference is being used. This inclusion or appending may be performed, for example, by the UPF, the AMF, or the base station. When the base station includes or appends this information, it may be done by the RRC layer, the SDAP layer, a layer higher than the RRC or PDCP layer, the RLC layer, or the MAC layer. Notification of this information from the base station to the UE may be done using RRC signaling, included in the SDAP header, included in the PDCP header, as a PDCP control PDU, included in the RLC header, as an RLC control PDU, included in the MAC header, as MAC signaling, or as L1 / L2 signaling. The UE may use this information to determine which time the data is associated with.

[0190] The UPF or the AMF may decide which base station's timing reference to use for processing the data. For example, the UPF may decide for U-plane data, the AMF may decide for C-plane data, or the AMF may decide for both U-plane and C-plane data. In this decision, for example, information about the accuracy of each base station's time may be used. This information may be, for example, uncertainty information included in the timing reference. This accuracy information may be notified from each base station to the UPF and / or AMF, or from the UE to the AMF. The NG interface may be used for notification from each base station to the UPF and / or AMF. NAS signaling may be used for notification from the UE to the AMF. The AMF may notify the UPF of this information, or notify the UPF of information regarding this decision. This notification from the AMF to the UPF may be made via the SMF. The UPF and / or AMF may, for example, decide to use the time of the base station with the most accurate time. This enables, for example, high-precision time synchronization between UEs (Unified Entity Devices).

[0191] As another example, the data transmitted from the base station to the UE may not include information indicating which base station's timing reference is being used. The UE may use information about the communication path with the base station, such as information about the bearer being used, to determine which time the data is associated with.

[0192] Another example of a time correction method in a UE is that the UE may expand the uncertainty of its own UE time. For example, the UE may use a range as the uncertainty of its own UE time that includes the time derived using a timing reference from a master base station and the time derived using a timing reference from a secondary base station. The UE may set its own UE time to a value that lies between the two aforementioned times, for example, the midpoint between the two times. This can, for example, avoid design complexity in a communication system.

[0193] Other solutions are disclosed. The UE may request a base station to correct its time. The base station may be a master base station or a secondary base station. When the UE sends a time correction request to a secondary base station, the UE may send the request directly to the secondary base station or send the request to the secondary base station via the master base station. The base station may use the request to correct its own time.

[0194] The UE may determine which base stations to correct for time synchronization using timing reference information from each base station. In determining which base stations to correct, for example, a base station with low accuracy may be selected for correction. This allows for time synchronization to be performed in accordance with a base station with high accuracy, and as a result, synchronization between UEs in the communication system can be performed with high accuracy. Another example of determining which base stations to correct is that a base station with high accuracy may be selected for correction.

[0195] Another example of base station time correction is that the UE may notify the upstream network equipment of a request for base station time correction. The upstream network equipment may be, for example, an AMF. For example, NAS signaling may be used for this notification from the UE to the upstream network equipment. The upstream network equipment may notify the base station of the request. The base station may use the notification to correct its own time.

[0196] As another example, a base station may notify a higher-level network of information regarding its own time. The higher-level network equipment may be, for example, an AMF (Automatic Time Function). The higher-level network equipment may use this information to notify the base station of a time correction request. The base station may use this notification to correct its own time.

[0197] The request may include information indicating that it is a time correction request, information about the base station to be corrected, or information about the amount of time correction. The information about the base station to be corrected may be, for example, an identifier indicating whether it is a master base station or a secondary base station. The information about the amount of time correction may be, for example, given as a correction amount for a predetermined time unit. The base station may correct its own time using the information included in the request. The base station may notify the UE of the completion of the correction. This notification of completion may be made via the other base station or via the higher-level network equipment.

[0198] Time correction may be performed between base stations. This correction may be performed, for example, using a request from the UE.

[0199] A base station subject to time correction may broadcast or notify its subordinate UEs of a timing reference using the corrected time. The subordinate UEs may then use this timing reference to correct their own time. This enables, for example, time synchronization between UEs within a communication system.

[0200] Figure 18 is a sequence diagram illustrating an example of time correction operation between base stations. Figure 18 shows an example where a UE requests a master base station (MN) to correct the time of a secondary base station (SN). Figure 18 also shows an example where an MN requests a time correction from an SN. In Figure 18, it is assumed that the UE has already obtained TAs from the MN and SN.

[0201] In step ST2001 shown in Figure 18, the MN notifies the UE of a timing reference. The UE uses the timing reference from the MN to derive the UE time (which may hereafter be referred to as the UE time referenced by the MN). In step 2002, the SN notifies the UE of a timing reference. The UE uses the timing reference from the SN to derive the UE time (which may hereafter be referred to as the UE time referenced by the SN).

[0202] In step ST2003 shown in Figure 18, the UE compares the UE time of the MN reference with the UE time of the SN reference. The comparison of both UE times may be performed, for example, by checking whether there is any overlap between the UE time of the MN reference and its uncertainty range and the UE time of the SN reference and its uncertainty range. For example, if such overlap exists, the UE may determine that both UE times are the same.

[0203] If both UE times coincide in step ST2003 as shown in Figure 18, the UE returns to the operation of receiving the timing references of both base stations in step ST2001 and step ST2002 in step 2004. If both UE times differ in step ST2003, the UE sends a request to the MN for correction of the SN time in step ST2005. The request may include information indicating that the correction is to be made to the SN, or it may include information regarding the amount of time correction. The UE may derive the amount of correction using the difference between the two UE times.

[0204] In step ST2006 shown in Figure 18, MN requests SN to correct the time. This request may include information about the amount of time correction for SN. This information may be the correction amount obtained by MN from UE in step ST2005. In step ST2007, SN corrects the time of its base station using the information about the time correction amount obtained in step ST2006.

[0205] In step ST2008 shown in Figure 18, the SN notifies the MN that the time correction of its base station is complete. In step ST2009, the MN notifies the UE of an acknowledgment of the SN time correction request. The notification in step ST2009 may also be a notification indicating the completion of the SN time correction.

[0206] Steps ST2010 and ST2011 shown in Figure 18 are the same as steps ST2001 and ST2002. In step ST2011, SN notifies the timing reference using the corrected time. UE uses the timing references obtained in steps ST2010 and ST2011 to derive the UE time for MN reference and the UE time for SN reference, respectively.

[0207] Other solutions are disclosed. The UE may set its own time in a range where its own UE time and the range of uncertainty of that time, obtained using a timing reference from a master base station, overlap with its own UE time and the range of uncertainty of that time, obtained using a timing reference from a secondary base station. The UE may, for example, set its own UE time to the median of the overlapping range, or define the range including the overlapping range as the range of uncertainty of its own UE time. This allows the UE to improve the accuracy of its own UE time by using timing references from two base stations.

[0208] The base station time correction method disclosed in this modified example 1 of Embodiment 1 may also be applied to handover. This makes it possible, for example, to achieve time synchronization between base stations.

[0209] As an example of base station time correction during handover, the time of the source base station may be corrected. The UE may request the destination base station to correct the time of the source base station. Notification of this request from the UE to the destination base station may occur after the UE has obtained the destination base station's timing reference and TA. Correction of the UE's own time may occur before, after, or simultaneously with the notification of this request to the destination base station. The destination base station may request the source base station to correct its time. The information included in this request from the UE to the destination base station and from the destination base station to the source base station may be the same as the information disclosed above. The source base station may use this request from the destination base station to correct its own time.

[0210] As another example, the time of the destination base station may be corrected. The UE may request the destination base station to correct its time. The UE may notify the destination base station of this request after the UE has obtained the destination base station's timing reference and TA. The information included in the request from the UE to the destination base station may be the same as the information disclosed above. The destination base station may use the request from the UE to correct its own base station time. The UE may then use the corrected timing reference and TA from the destination base station to correct its own UE time.

[0211] The UE may decide whether to correct the time of the source base station or the destination base station during a handover. For example, it may correct the time of the base station with lower time accuracy. Alternatively, the source base station or the destination base station may make the decision.

[0212] Regarding time correction of base stations during handover, the higher-level network equipment may instruct the base stations. The UE may notify the higher-level network equipment of time correction information from each base station. For example, NAS signaling may be used for this notification. The method of time correction of the base stations using instructions from the higher-level network equipment may be the same as the method of time correction using the higher-level network equipment in the DC described above.

[0213] As another example, a UE may determine its own UE time using both a timing reference from the destination base station and a timing reference from the origin base station. For example, a UE may determine its own UE time within a range where the range of uncertainty of its own UE time and the time obtained using the timing reference from the destination base station overlap with the range of uncertainty of its own UE time and the time obtained using the timing reference from the destination base station. This can, for example, improve the time accuracy of the UE.

[0214] The base station time correction method disclosed in this modified example 1 of Embodiment 1 may be applied to the time correction of a base station surrounding the UE. The base station may not be connected to the UE. The application of the method described above may be applied when the frame timing difference between the surrounding base station and the base station to which the UE is connected is known to any device in the communication system.

[0215] The UE may obtain a timing reference of the surrounding base station. The timing reference obtained by the UE may be broadcast by the surrounding base station. The UE may estimate the TA of the surrounding base station using the frame timing of the surrounding base station. This estimation may be the method disclosed in Embodiment 1. The UE may request a time correction of the surrounding base station from the base station to which the UE is connected. This request may use RRC signaling, MAC signaling, or L1 / L2 signaling. The base station to which the UE is connected may request a time correction from the surrounding base station. The information included in the request from the UE to the connected base station, and the information included in the request from the base station to which the UE is connected to the surrounding base station, may be the same as the information disclosed in this modified example 1 of Embodiment 1. The surrounding base station may correct its own time using the request from the base station to which the UE is connected.

[0216] In the case of time correction of surrounding base stations, similar to time correction of base stations during handover, the higher-level network equipment may instruct the base stations.

[0217] As another example, the UE may determine its own UE time using timing references from the connected base station and timing references from surrounding base stations. For example, the UE may determine its own UE time within a range where the range of uncertainty of its own UE time and the time obtained using the timing reference from the connected base station overlap with the range of uncertainty of its own UE time and the time obtained using the timing reference from surrounding base stations. In the foregoing, there may be one surrounding base station or multiple surrounding base stations. This can, for example, improve the time accuracy at the UE.

[0218] The method in Modification 1 of this Embodiment 1 may also be applied to the movement of a UE between communication devices. For example, when a UE receives timing references from multiple DUs, the UE may determine its own UE time using the timing reference from the DU with the highest accuracy, or the UE may determine its own UE time and range of uncertainty in the range where the UE time and range of uncertainty obtained using the timing references from both DUs overlap. This makes it possible to improve the accuracy of the UE time, for example.

[0219] As another example, immediately before a handover, a UE may communicate with the originating base station using a DU with a longer validity period for its timing reference among the available DUs. This can prevent, for example, a deterioration in the accuracy of the UE's own time during the handover.

[0220] This modified version 1 of Embodiment 1 clarifies which base station the UE synchronizes its time with, thereby preventing malfunctions in the communication system. Furthermore, it becomes possible to correct time errors between base stations in the DC, thereby increasing the number of UEs that can synchronize their time in the communication system.

[0221] Modification 2 of Embodiment 1. In NR (Noise Reduction), beamforming is used, requiring timing reference notifications from the gNB (Ground Neural Network) to the subordinate UEs (Upper Entities) for multiple beam directions. Therefore, transmitting the timing reference from the base station to the UE takes time. As a result, if, for example, the clock accuracy at the UE is low, the error in the UE time may increase.

[0222] We will now disclose a method to solve the aforementioned problem.

[0223] A validity period is set for the timing reference. This validity period may be set in the UE. This validity period may be predetermined by a standard. This validity period may be, for example, a fixed value or may be determined using the clock accuracy of the UE. Information regarding this validity period may be included in the UE capability. This information may be, for example, the validity period or information regarding the clock accuracy of the UE.

[0224] A timer for the validity period may be provided. The timer may be provided at the base station. The UE may notify the base station of information regarding the validity period. The notification may be, for example, a notification of UE capabilities. The base station may use the notification to set a timer for the validity period of the timing reference at the UE. The timer may be initialized and started by broadcasting or notifying the UE of the timing reference from the base station. The base station may notify the UE of the timing reference when the timer expires. This makes it possible to prevent, for example, an increase in the error of the UE time.

[0225] A timer for the validity period may be provided in the UE. The UE may initialize and start the timer upon receiving a timing reference broadcast or notified by the base station. When the timer expires, the UE may request a timing reference from the base station. This request may be made via RRC signaling, MAC signaling, or L1 / L2 signaling. The base station may use this request to notify the UE of the timing reference. This can, for example, prevent an increase in the error of the UE time.

[0226] Other solutions are disclosed. The UE may always obtain a periodically broadcast timing reference. The base station may pre-notify or inform the UE of the broadcasting period of the timing reference. This can, for example, prevent an increase in the error of the UE time.

[0227] As another example, the UE may acquire a periodically announced timing reference at certain announcement cycles. For example, the UE may acquire the timing reference at multiple cycle intervals. The number of cycles may be determined, for example, using the clock accuracy of the UE. This eliminates the need for the UE to perform receiving operations for some timing reference announcements, and as a result, power consumption in the UE can be reduced.

[0228] The UE may notify the base station of the need for individual notification of timing references. For example, the UE may notify the base station that individual notification of timing references is unnecessary if sufficient time accuracy can be maintained by receiving periodically broadcast timing references only. This information may be included, for example, in the UE capabilities. The base station may use this information to refrain from individually notifying the UE of timing references. This can, for example, improve the efficiency of the communication system.

[0229] The timer in this modified example 2 of Embodiment 1 may be applied to the validity period and / or TA. The validity period and / or timer of the TA may be provided as a different timer from the timeAlignmentTimer described in Non-Patent Literature 17 (3GPP TS 38.321 V15.2.0). The validity period and / or timer may be set to a shorter value than the aforementioned timeAlignmentTimer. The setting method and operation of the TA timer may be the same as that of the timing reference timer. For example, the base station may notify the UE of the TA when the timer in the TA expires. The UE may use the TA to correct its own UE time. As another example, the value of the timer may be determined using the UE's movement speed. The movement speed may be, for example, the movement speed in the cell radial direction. This allows the base station to quickly grasp TA changes caused by UE movement, and as a result, maintain the accuracy of the UE time.

[0230] The base station may obtain the UE's moving speed using the uplink RS. For example, the UE's moving speed may be derived using the Doppler shift of the uplink RS. The uplink RS may be, for example, a DMRS, an SRS, or a PTRS. Another example is a positioning RS.

[0231] It is also possible to use both the timing reference timer and the TA timer. This allows for further improvement in the accuracy of the UE time, for example.

[0232] This modified version 2 of Embodiment 1 makes it possible to prevent the increase in time error caused by the clock error of the UE.

[0233] Embodiment 2. In the communication of U-plane data and / or C-plane data in a TSN, the latency may be kept constant.

[0234] However, when mobility such as handover occurs, a problem arises in which latency fluctuates during and before / after the mobility occurs. In addition, a problem arises in which latency fluctuates in communication between the base station and the UE due to the constraints of frequency resources and / or time resources at the base station.

[0235] We will now disclose a method to solve the aforementioned problem.

[0236] The UE communicates using multiple PDU sessions. These multiple PDU sessions may be set up in both the path through the master base station and the path through the secondary base station. These multiple PDU sessions may be configured for a single network slicing. The UE sends and receives data in the PDU session that passes through a base station where no mobility occurs. The PDU session in which data is sent and received may switch between the multiple PDU sessions.

[0237] For example, when a master base station switches over, the UE may switch the uplink data transmission path to a path that goes through the secondary base station. The UPF may also switch the downlink data transmission path to a path that goes through the secondary base station.

[0238] As another example, when a secondary base station switches over, the UE may switch the uplink data transmission path to the path through the master base station. The UPF may switch the downlink data transmission path to the path through the master base station.

[0239] The master base station may instruct the UE to switch the uplink data transmission path. The master base station may also be the mobile master base station when a master base station switch occurs. The instruction may include information indicating which base station to use for the path, and may also include information about the data subject to the path switch. The information about the data subject to the path switch may be, for example, information about QoS flows, information about bearers, or information about PDU sessions. The UE may use the instruction to switch the path used for uplink data transmission. This makes it possible to switch transmission paths only for data that requires a path switch, and as a result, congestion on the switched transmission path can be prevented.

[0240] The UE may send a response to the instruction to the master base station. This prevents discrepancies regarding the uplink data communication path between the UE and the master base station, and as a result prevents malfunctions in the communication system.

[0241] After the switching instruction, the UE may receive downlink data from either the base station before the switching or the base station after the switching. This makes it possible to prevent, for example, the loss of downlink data before and after switching the downlink data transmission path in the UPF.

[0242] The instruction from the master base station to the UE may be RRC signaling. For example, the instruction may be included in the signaling of RRC reconfiguration (RRCReconfiguration). This can avoid, for example, the design complexity in the communication system. As another example, the instruction may be MAC signaling. For example, a MAC CE for switching the path may be provided. This enables the master base station to quickly notify the UE of the switching of the uplink data transmission path, for example. As another example, the instruction may be L1 / L2 signaling. This enables the master base station to notify the UE of the switching even more quickly, for example.

[0243] The response from the UE to the master base station may be RRC signaling, MAC signaling, or L1 / L2 signaling. For example, the response may be the signaling of RRC reconfiguration complete (RRCReconfigurationComplete), a HARQ response to the MAC CE including the instruction, or other signaling

[0244] The master base station may instruct the AMF to switch the downlink data transmission path in the UPF. The master base station may be the source master base station when the switching of the master base station occurs. The AMF may transfer the instruction to the UPF. The transfer of the instruction from the AMF to the UPF may be performed via the SMF. The instruction may include information indicating which base station's path to use, or may include information regarding the data targeted for path switching. The information regarding the data targeted for path switching may be, for example, information regarding a QoS flow or information regarding a PDU session, for example. The UPF may use the instruction to switch the path used for downlink data transmission. This enables, for example, switching of the transmission path only for the data that requires switching of the transmission path, and as a result, it is possible to prevent congestion in the switched-to transmission path.

[0245] The UPF may send a response to the AMF for the instruction. The transmission of the response may be performed via the SMF. The AMF may transfer the response to the master base station. This enables, for example, prevention of a discrepancy regarding the uplink data communication path between the upper-layer NW device and the master base station, and as a result, prevention of malfunction in the communication system.

[0246] After the switching instruction, the UPF may receive uplink data from the base station before the switching or from the base station after the switching. This enables, for example, prevention of loss of uplink data before and after switching of the uplink data transmission path in the UE.

[0247] The instruction from the master base station to the AMF may be signaling in the NG interface. The signaling for transmitting the instruction may be existing signaling or newly provided signaling. The same may apply to the transfer of the instruction from the AMF to the UPF, the response of the instruction from the UPF to the AMF, and the transfer of the response from the AMF to the UE.

[0248] An active / deactive state may be provided for the PDU session. In the above-described switching of the communication path, activation / deactivation of the PDU session may be used. The UE and / or the UPF may perform data transmission using an active PDU session. The UE and / or the UPF may perform data reception in an active PDU session or may also enable it in a deactive PDU session. This enables, for example, obtaining the same effect as described above.

[0249] In the above-described plurality of PDU sessions, the latency between the UPF and the UE may be made the same. This enables, for example, keeping the latency of data transmission and reception constant before and after switching of the PDU session used for data transmission.

[0250] In data transmission between a UE and a UPF, the transmitting device may notify the receiving device of information regarding the transmission time of the transmitted data, or information regarding the time at which the receiving device should receive the data. The transmitting device may be a UE or a UPF. The receiving device may be a UPF or a UE. The time at which the data should be received may, for example, be the time at which the receiving device should transfer the data to the upper layer. This time may, for example, be a time in milliseconds, a time using a subframe number, a time using a slot number, a time using a mini-slot number, a time using a symbol number, or a time using a combination of several of the above. The transmitting device may, for example, attach a timestamp to the transmitted data. This timestamp may be similar to the time information described above. This timestamp may be attached at the upper layer, at SDAP, at PDCP, at RLC, or at MAC. As another example, information regarding the transmission time may be notified using NAS signaling, RRC signaling, MAC signaling, or L1 / L2 signaling. The receiving device may use the information regarding the transmission time to derive the timing. The receiving device may remove the timestamp from the received data. The method described above may be applied to multiple PDU sessions between the UE and the UPF. This makes it possible, for example, to make the latency in data transmission and reception between the UE and the UPF the same across multiple PDU sessions.

[0251] The AMF may notify the UPF and / or UE of information regarding the latency between the UPF and the UE. This information may, for example, be the latency required for communication between the UPF and the UE. This notification may be performed using, for example, signaling on the NG interface or NAS signaling. The UPF and / or UE may use this information to obtain the latency between the UPF and the UE.

[0252] In data transmission between the UE and UPF, notification of information regarding the transmission time of the transmitted data from the transmitting device and / or the time at which the receiving device should receive it may be applied to periodic data transmission. For example, the information regarding the time at which the receiving device should receive it may be a combination of the period and an offset, i.e., one of the times at which the receiving device should receive it. Information indicating that the data transmission is periodic may also be included. The UE and / or UPF may use this information to forward the received data to the upper layer. This makes it possible to maintain a constant latency even in periodic data transmission.

[0253] Figures 19 and 20 are sequence diagrams showing the switching of PDU sessions used for data transmission and the switching of base stations to which the UE is connected in this second embodiment. Figures 19 and 20 are connected at the boundary line BL1920. Figures 19 and 20 show an example in which U-plane data is transmitted and received between the UE and the UPF. In the example shown in Figures 19 and 20, the PDU session used for data transmission switches from a PDU session passing through the source master base station (source MN) to a PDU session passing through a secondary base station, and the master base station to which the UE is connected switches from the source MN to the destination MN.

[0254] In steps ST2500 and ST2501 shown in Figure 19, data is transmitted and received between the UE and the UPF via the source MN. Step ST2500 represents data transmission and reception between the UPF and the source MN, and step ST2501 represents data transmission and reception between the source MN and the UE.

[0255] In step ST2502 shown in Figure 19, the source MN decides to perform a master base station switchover from its own base station to the destination MN. In step ST2502, the source MN may also decide not to perform a secondary base station switchover.

[0256] In step ST2505 shown in Figure 19, the mobile MN requests the AMF to switch the PDU session used for downlink U-plane data transmission between the UE and UPF from the PDU session via its own base station to the PDU session via the mobile SN. In step ST2508, the AMF notifies the UPF of the request for the switch, and the UPF notifies the AMF of the completion of the switch. The notification of the request and the notification of completion may be made via the SMF. The UPF uses the notification of the request to switch the PDU session used for downlink U-plane data transmission from the PDU session via the mobile MN to the PDU session via the mobile SN.

[0257] In steps ST2510 and ST2511 shown in Figure 19, the UPF transmits downlink U-plane data to the UE via the source SN. Step ST2510 represents data transmission from the UPF to the source SN, and step ST2511 represents data transmission from the source SN to the UE. In steps ST2512 and ST2513, the UE transmits uplink U-plane data to the UPF via the source MN. Step ST2512 represents data transmission from the UE to the source MN, and step ST2513 represents data transmission from the source MN to the UPF.

[0258] In step ST2514 shown in Figure 19, the AMF sends an acknowledgment to the source MN for the PDU session switching request in step ST2505. This acknowledgment may be sent using the switching completion notification that was notified to the AMF by the UPF in step ST2508.

[0259] In step ST2515 shown in Figure 19, the source MN instructs the UE to switch the PDU session used for transmitting uplink U-plane data between the UE and the UPF from the PDU session via its own base station to the PDU session via the source SN. This instruction may be included, for example, in the RRC Reconfiguration signaling. The UE uses this instruction to switch the PDU session used for transmitting uplink U-plane data from the PDU session via the source MN to the PDU session via the source SN.

[0260] In steps ST2520 and ST2521 shown in Figure 19, data is transmitted and received between the UE and the UPF via the source SN. Step ST2520 shows the data transmission and reception between the UPF and the source SN, and step ST2521 shows the data transmission and reception between the source SN and the UE.

[0261] In step ST2522 shown in Figure 19, the UE notifies the source MN of its response to the switching instruction in step ST2515. The notification of this response may be given using the RRCReconfigurationComplete signaling.

[0262] In step ST2523 shown in Figure 19, the source MN notifies the destination MN of a Handover Request. This notification may include information indicating that the secondary base station will not be switched over. In step ST2524, the destination MN performs Admission Control for the handover.

[0263] In step ST2525 shown in FIG. 20, the destination MN sends a Secondary Node Addition Request to the source SN. In step ST2526, the source SN notifies the destination MN of a Secondary Node Addition Request Acknowledge.

[0264] In step ST2527 shown in FIG. 20, the destination MN sends a Handover Request Acknowledge to the source MN for the handover request in step ST2523.

[0265] In step ST2528 shown in FIG. 20, the source MN sends a Secondary Node Release Request to the source SN. After the request is notified, data transmission and reception between the UE and the UPF via the source SN may continue. The source MN may include information indicating that data transmission and reception via the source SN continues in the request.

[0266] Steps ST2530 and ST2531 shown in FIG. 20 are the same as steps ST2520 and ST2521, respectively.

[0267] In step ST2533 shown in FIG. 20, the source SN notifies the source MN of a Secondary Node Release Request Acknowledge.

[0268] In step ST2535 shown in Figure 20, the source MN instructs the UE to perform a handover from its base station to the destination MN. This instruction may be included, for example, in the RRC Reconfiguration signaling. The instruction may also include information indicating that the secondary base station will not change. The UE uses this instruction to perform a handover from the source MN to the destination MN without changing the secondary base station from the source SN. In step ST2537, random access processing is performed between the UE and the destination MN. In step ST2538, the UE notifies the destination MN that the handover is complete. This notification may use, for example, the RRC Reconfiguration Complete signaling. In step ST2539, the destination MN notifies the source SN that the Secondary Node Reconfiguration is complete.

[0269] Steps ST2540 and ST2541 shown in Figure 20 are the same as steps ST2520 and ST2521, respectively.

[0270] In step ST2542 shown in Figure 20, the destination MN notifies the AMF of a request to switch the route of PDU sessions between the UE and the UPF from the source MN to the destination MN. This notification may be made, for example, using PDU session path switch request signaling. In step ST2545, the AMF notifies the UPF of the request for the switch, and the UPF notifies the AMF of the completion of the switch. This notification of the request and the notification of completion may be made via the SMF. The UPF uses this notification of the request to switch the route of PDU sessions between the UE and the UPF from the source MN to the destination MN.

[0271] In step ST2547 shown in Figure 20, the AMF sends an acknowledgment to the destination MN for the PDU session path switching request in step ST2542. This acknowledgment may be sent using the switching completion notification that was notified to the AMF by the UPF in step ST2545.

[0272] In step ST2548 shown in Figure 20, the destination MN instructs the source MN to release the UE context. This instruction may be given, for example, using UE context release signaling.

[0273] Steps ST2550 and ST2551 shown in Figure 20 are the same as steps ST2520 and ST2521, respectively.

[0274] Figures 19 and 20 disclose an example in which the downlink data transmission PDU session switching shown in steps ST2505 to ST2514 occurs before the uplink data transmission PDU session switching shown in steps ST2515 to ST2522. In contrast, the downlink data transmission PDU session switching may occur after the uplink data transmission PDU session switching. As another example, the uplink data transmission PDU session switching may occur in the middle of the downlink data transmission PDU session switching. For example, step ST2515 may occur between steps ST2505 to ST2514. As yet another example, the downlink data transmission PDU session switching may occur in the middle of the uplink data transmission PDU session switching. For example, step ST2505 may occur between steps ST2515 to ST2522. This can improve flexibility in the communication system, for example.

[0275] Figures 19 and 20 illustrate the switching of transmission and reception paths for U-plane data, but transmission and reception path switching may also occur in C-plane data. In C-plane transmission and reception path switching, C-plane data may be transmitted and received between the UE and the AMF. This makes it possible to prevent latency fluctuations associated with base station switching, even for C-plane data.

[0276] Figures 21 and 22 are sequence diagrams showing other examples of the switching of PDU sessions used for data transmission and the switching of base stations to which the UE is connected in this second embodiment. Figures 21 and 22 are connected at the boundary line BL2122. Figures 21 and 22 show an example of U-plane data transmission and reception between the UE and the UPF. In the example shown in Figures 21 and 22, the PDU session used for data transmission switches from a PDU session passing through the source secondary base station (source SN) to a PDU session passing through the destination master base station, and the secondary base station to which the UE is connected switches from the source SN to the destination SN. Here, we will describe an example in which the operations shown in Figures 21 and 22 occur following the operations shown in Figures 19 and 20. In Figures 21 and 22, the same step numbers are used for processes similar to those in Figures 19 and 20, and common explanations are omitted.

[0277] In steps ST2600 and ST2601 shown in Figure 21, data is transmitted and received between the UE and the UPF via the source SN. Step ST2600 represents data transmission and reception between the UPF and the source SN, and ST2601 represents data transmission and reception between the source SN and the UE.

[0278] In step ST2602 shown in Figure 21, the destination MN decides to switch the secondary base station from the source SN to the destination SN.

[0279] In step ST2605 shown in Figure 21, the destination MN requests the AMF to switch the PDU session used for downlink U-plane data transmission between the UE and UPF from the PDU session via the source SN to the PDU session via its own base station. Step ST2508 is the same as in Figure 19. The UPF uses the notification of this request to switch the PDU session used for downlink U-plane data transmission from the PDU session via the source SN to the PDU session via the destination MN.

[0280] In steps ST2610 and ST2611 shown in Figure 21, the UPF transmits downlink U-plane data to the UE via the destination MN. Step ST2610 represents the transmission of data from the UPF to the destination MN, and step ST2611 represents the transmission of data from the destination MN to the UE. In steps ST2612 and ST2613, the UE transmits uplink U-plane data to the UPF via the source SN. Step ST2613 represents the transmission of data from the UE to the source SN, and step ST2613 represents the transmission of data from the source SN to the UPF.

[0281] In step ST2614 shown in Figure 21, the AMF sends an acknowledgment to the destination MN for the PDU session switching request in step ST2605. This acknowledgment may be sent using the switching completion notification that was notified to the AMF by the UPF in step ST2508.

[0282] In step ST2615 shown in Figure 21, the destination MN instructs the UE to switch the PDU session used for transmitting uplink U-plane data between the UE and the UPF from the PDU session via the source SN to the PDU session via its own base station. This instruction may be included, for example, in the RRC Reconfiguration signaling. The UE uses this instruction to switch the PDU session used for transmitting uplink U-plane data from the PDU session via the source SN to the PDU session via the destination MN.

[0283] In steps ST2620 and ST2621 shown in Figure 21, data is transmitted and received between the UE and the UPF via the destination MN. Step ST2620 shows the data transmission and reception between the UPF and the destination MN, and step ST2621 shows the data transmission and reception between the destination MN and the UE.

[0284] In step ST2622 shown in Figure 21, the UE notifies the destination MN of its response to the switching instruction in step ST2615. The RRC Reconfiguration Complete signal may be used to notify the UE of this response.

[0285] In step ST2625 shown in Figure 22, the destination MN makes a Secondary Node Addition Request to the destination SN. In step ST2626, the destination SN notifies the destination MN of a Secondary Node Addition Request Acknowledge.

[0286] In step ST2628 shown in Figure 22, the destination MN makes a Secondary Node Release Request to the source SN. In step ST2633, the source SN notifies the destination MN of a Secondary Node Release Request Acknowledge.

[0287] In step ST2635 shown in Figure 22, the destination MN instructs the UE to switch the secondary base station from the source SN to the destination SN. This instruction may be included, for example, in the RRC Reconfiguration signaling. The UE may use this instruction to change the secondary base station from the source SN to the destination SN. In step ST2636, the UE notifies the destination MN that the SN base station switchover is complete. This notification may use, for example, the RRC Reconfiguration Complete signaling. In step ST2638, the destination MN notifies the destination SN that the Secondary Node Reconfiguration is complete. In step ST2639, random access processing is performed between the UE and the destination SN.

[0288] Steps ST2640 and ST2641 shown in Figure 22 are the same as steps ST2620 and ST2621, respectively.

[0289] In step ST2642 shown in Figure 22, the destination MN notifies the AMF of a route switch for PDU sessions between the UE and the UPF that are currently routed via the source SN, from the source SN to the destination SN. This notification may be made, for example, using PDU session resource modify indication signaling. In step ST2645, the AMF forwards the switch notification to the UPF, and the UPF notifies the AMF of the completion of the switch. The switch notification and the completion notification may be made via the SMF. The UPF uses the switch notification to switch the route for PDU sessions between the UE and the UPF that are currently routed via the source SN, from the source SN to the destination SN.

[0290] In step ST2647 shown in Figure 22, the AMF sends an acknowledgment to the destination MN for the PDU session resource change notification in step ST2642. This acknowledgment may be sent using the switchover completion notification that was notified to the AMF by the UPF in step ST2645.

[0291] In step ST2648 shown in Figure 22, the destination MN instructs the source SN to release the UE context. This instruction may be given, for example, using UE context release signaling.

[0292] Steps ST2650 and ST2651 shown in Figure 22 are the same as steps ST2620 and ST2621, respectively.

[0293] In Figures 21 and 22, as in Figures 19 and 20, the downlink data transmission PDU session switching shown in steps ST2605 to ST2614 may occur after the uplink data transmission PDU session switching shown in steps ST2615 to ST2622, or it may occur in between. Also, the uplink data transmission PDU session switching shown in steps ST2615 to ST2622 may occur in the middle of the downlink data transmission PDU session switching shown in steps ST2605 to ST2614. This makes it possible to improve the flexibility of the communication system, for example.

[0294] In Figures 21 and 22, similar to Figures 19 and 20, the transmission and reception paths may also be switched in the C-plane. In the transmission and reception path switching in the C-plane, the transmission and reception of C-plane data may occur between the UE and the AMF, or between the UE and the SMF. This makes it possible to prevent latency fluctuations associated with base station switching, even in the case of C-plane data.

[0295] The operations shown in Figures 19 and 20 and the operations shown in Figures 21 and 22 may be performed alternately. This makes it possible to maintain a constant latency for data transmission and reception between the UE and the higher-level network equipment, even when the UE is constantly moving.

[0296] In a method in which a UE communicates using multiple PDU sessions, multiple UPFs may be used. For example, each of the different PDU sessions may pass through a different UPF. In communication using multiple UPFs, a device on the Data Network (DN) in Non-Patent Literature 30 (3GPP TS23.501 V15.3.0) may use the multiple UPFs to send and receive data with the UE. The master base station may request the AMF to switch the downlink data transmission path. The AMF may forward the request to the device on the DN. This forwarding may be done via the SMF. The device on the DN may use the forwarded request to switch the PDU session used for downlink data transmission. The master base station may instruct the UE to switch the PDU session used for uplink data transmission. This instruction from the master base station to the UE may be the same as described above. This allows, for example, communication using multiple UPFs to obtain the same effect as described above.

[0297] Disclose other solutions. Do not perform handovers to base stations that do not meet latency requirements. The source base station notifies the destination base station of the latency requirements. The destination base station uses these latency requirements to decide whether to accept or reject the handover.

[0298] Latency requirements information may be included in the signaling of handover requests communicated from the source base station to the destination base station. This information may be set for each QoS flow used by the UE, or for each bearer used by the UE. The destination base station may use this information to decide whether to accept or reject a handover for each QoS flow and / or bearer. The destination base station may be notified of the QoS flows and / or bearers for which it will accept the handover.

[0299] Time synchronization may be performed within the 5G system. For example, time synchronization may be performed between the upstream network equipment and the base station.

[0300] The higher-level network device may notify the base station of a timestamp. The base station may notify the higher-level network device of a timestamp. The higher-level network device may use the timestamp it transmitted and the timestamp the base station transmitted to it to derive the transmission delay from itself to the base station. The higher-level network device may notify the base station of this transmission delay. The base station may use this transmission delay to correct its own time.

[0301] Time synchronization may be performed between base stations. In the synchronization between base stations, the time synchronization method between the higher-level NW equipment and the base station described above may be applied, or the method disclosed in Modification 1 of Embodiment 1 may be applied.

[0302] This second embodiment makes it possible to maintain a constant communication latency even when mobility occurs.

[0303] Embodiment 3. The base station may hold downlink data to be transmitted to the UE. The held downlink data (hereinafter sometimes referred to as local cache data) may be transmitted from the UPF to the base station. The base station may transmit the local cache data to the UE.

[0304] However, if a handover between base stations occurs at the UE, the destination base station does not hold the local cache data. This leads to problems such as increased latency in receiving the data at the UE.

[0305] We will now disclose a solution to the aforementioned problem.

[0306] The destination base station also retains local cache data. This local cache data may be transmitted from the originating base station.

[0307] The transmission of the local cache data from the source base station to the destination base station may occur simultaneously with or after the transmission of the handover request from the source base station to the destination base station. This allows the destination base station to quickly acquire the local cache data, for example.

[0308] As another example, the transmission of the local cache data from the source base station to the destination base station may occur, for example, after the destination base station has acknowledged the handover request to the source base station. This eliminates the need to resend the local cache data to the selected destination base station if, for example, the destination base station rejects the handover request. As a result, the efficiency of the communication system can be improved.

[0309] As another example, the UPF may send local cache data to the destination base station. The destination base station may request the UPF to send the local cache data to the destination base station. This can, for example, reduce the load on the inter-base station interface.

[0310] The originating base station may release local cache data. For example, the originating base station may perform this release operation after receiving a handover request acknowledgment. This can, for example, reduce the amount of memory used by the originating base station.

[0311] Another solution is disclosed. Multiple base stations hold local cache data. These multiple base stations may, for example, be in the same RAN Notification Area (RNA) as the source base station, or in the same tracking area as the source base station. Alternatively, the source base station may determine which base stations hold the local cache data, or a higher-level network device may determine this. The source base station or the higher-level network device may determine which base stations hold the local cache data using, for example, the location information of the UE. The multiple base stations may hold the local cache data, for example, before the start of the handover. This makes it possible to prevent congestion on the communication system during the handover process, for example.

[0312] The originating base station may notify the destination base station of information indicating which data from which point onward (or from which data onward) of the local cache data should be transmitted to the UE. Sequence numbers may be assigned to the local cache data. These sequence numbers may be assigned separately from the PDCP SN. These sequence numbers may be assigned, for example, to each packet. This information may include the sequence number, the PDCP SN, or a combination of the sequence number and the PDCP SN. This makes it possible to prevent, for example, duplication or loss of local cache data after a handover.

[0313] The UE may notify the base station of information regarding the data it wishes to begin receiving in the local cache data. This information may include the sequence number, the PDCP SN, or a combination of the sequence number and the PDCP SN. This notification from the UE to the base station may, for example, be made when data communication to the UE is resumed, used in fast forwarding and / or rewinding in data communication from the base station to the UE, or made during a UE handover. Resuming data communication to the UE may, for example, be when the UE returns from RRC_INACTIVE to RRC_CONNECTED. The UE may retain the sequence number, the PDCP SN, or a combination of the sequence number and the PDCP SN when transitioning to RRC_INACTIVE. This allows for improved flexibility in, for example, the transmission of local cache data from the base station to the UE.

[0314] Another example of a sequence number for local cache data is that a mapping may be established between the sequence number and the PDCP SN. For example, the sequence number may be obtained by adding or subtracting a predetermined offset from the PDCP SN. As described above, one PDCP PDU may be generated from one packet in the local cache. This can, for example, avoid complexity in the communication system.

[0315] The source base station may notify the destination base station of a combination of information regarding the offset value and information regarding the PDCP SN that should next generate a PDCP PDU. This can, for example, reduce the size of signaling in inter-base station communication.

[0316] The UE may notify the base station of only the PDCP SN for the data it wishes to begin receiving in the local cache data. The base station may use the information regarding the offset value and the PDCP SN to derive the sequence number in the local cache data for the data it wishes to begin receiving. As another example, the UE may notify the base station of the sequence number in the local cache data for the data it wishes to begin receiving. The base station may use the sequence number and the information regarding the offset value to derive the PDCP SN for the data it wishes to begin receiving in the local cache data. The aforementioned notification may be performed using a PDCP control PDU or using RRC signaling. This can, for example, reduce the amount of signaling between the UE and the base station.

[0317] Another example of a sequence number for local cache data is the use of TCP sequence numbers. The aforementioned notification from the source base station to the destination base station may include TCP sequence numbers. The source base station may maintain information regarding the combination of TCP sequence numbers and PDCP SNs in the local cache data. The aforementioned notification from the UE to the base station may include TCP sequence numbers. This eliminates the need to create new numbers in the communication system, for example, thereby avoiding complexity in the communication system.

[0318] The local cache data in this third embodiment may be applied to uplink communication transmitted from the UE to the base station. The local cache may be used, for example, for user data transmitted from the UE to another UE via the base station. The local cache may also be used, for example, when the communication speed from the UE to the counterpart at the application layer of the UE is high (e.g., a long communication distance, a large number of routing devices between the UE and the counterpart), to terminate the communication protocol (e.g., TCP) with the UE at the base station.

[0319] Local cache data in uplink communication may be transferred from the source base station to the destination base station. This local cache data may be maintained at multiple base stations.

[0320] The originating base station may notify the UE of information indicating which data from which point (or from which data onward) of the local cache data should be transmitted to the UE. Sequence numbers may be assigned to the local cache data. These sequence numbers may be assigned separately from the PDCP SN. These sequence numbers may be assigned, for example, to each packet. The UE may use this information to determine which data to begin uplink transmission to the destination base station. This makes it possible to prevent duplicate transmission or loss of data, for example, in uplink communication.

[0321] This third embodiment enables the UE to reduce latency in downlink and / or uplink communications even in situations where handover occurs. Furthermore, the UE can ensure reliability in said downlink and / or uplink communications.

[0322] Embodiment 4. In 3GPP, Side Link (SL) is supported for D2D (Device to Device) and V2V (Vehicle to Vehicle) communication (see Non-Patent Document 1). SL is defined by the PC5 interface.

[0323] The physical channels used in SL (see Non-Patent Document 1) are described below. The Physical Sidelink Broadcast Channel (PSBCH) carries system and synchronization-related information and is transmitted from the UE.

[0324] The Physical Sidelink Discovery Channel (PSDCH) carries sidelink discovery messages from the UE (Union Engine).

[0325] The Physical Sidelink Control Channel (PSCCH) carries control information from the UE for sidelink communication and V2X sidelink communication.

[0326] The Physical Sidelink Shared Channel (PSSCH) carries data from the UE for sidelink communication and V2X sidelink communication.

[0327] The transport channels used in SL (see Non-Patent Document 1) are described below. The Sidelink broadcast channel (SL-BCH) has a predetermined transport format and is mapped to the physical channel PSBCH.

[0328] The Sidelink Discovery Channel (SL-DCH) has periodic broadcast transmissions in a fixed size and predetermined format. It also supports both UE autonomous resource selection and resource allocation scheduled by the eNB. UE autonomous resource selection carries a risk of collisions, while there are no collisions when the UE allocates individual resources via the eNB. It also supports HARQ combining, however, it does not support HARQ feedback. The SL-DCH is mapped to the physical channel PSDCH.

[0329] Sidelink shared channels (SL-SCH) support broadcast transmission. They support both UE autonomous resource selection and resource allocation scheduled by the eNB. UE autonomous resource selection carries a risk of collisions, while there are no collisions when the UE allocates individual resources via the eNB. They also support HARQ combining, but not HARQ feedback. Furthermore, they support dynamic link adaptation by changing transmit power, modulation, and coding. SL-SCH is mapped to the physical channel PSSCH.

[0330] This section describes the logical channels used in SL (see Non-Patent Document 1). The Sidelink Broadcast Control Channel (SBCCH) is a sidelink channel used to broadcast sidelink system information from one UE to another. The SBCCH is mapped to the transport channel SL-BCH.

[0331] A Sidelink Traffic Channel (STCH) is a one-to-many sidelink traffic channel for transmitting user information from one UE to another. STCH is used only by UEs with sidelink communication capabilities and UEs with V2X sidelink communication capabilities. One-to-one communication between two UEs with sidelink communication capabilities is also achieved via STCH. STCH is mapped to the transport channel SL-SCH.

[0332] 3GPP is also considering support for V2X communication in NR. The consideration of V2X communication in NR is progressing based on the LTE system and LTE-A system, but the following changes and additions have been made from the LTE system and LTE-A system.

[0333] In LTE, SL communication was limited to broadcast only. In NR, in addition to broadcast, support for unicast and groupcast as SL communication is being considered (see Non-Patent Document 28 (3GPP RP-182111)).

[0334] Support for HARQ feedback (Ack / Nack) and CSI reporting is being considered for unicast and groupcast communications.

[0335] Low latency is required for NR SL communication. To meet this low latency requirement, the introduction of preemption has been proposed for NR SL communication (Non-Patent Document 22 (3GPP R1-1810593), Non-Patent Document 27 (R1-1810775)). Preemption is a technique that preempts data transmission to an UE that is already being performed by transmitting to another UE that requires low latency (Non-Patent Document 16 (TS38.300)).

[0336] In SL, a transmitting UE may transmit data for multiple services, and each service may have a different receiving UE. In such cases, the UE receiving the resources for the preempted communication will be different from the UE receiving the resources for the communication that preempts. The transmitting UE needs to notify these receiving UEs that the communication has been preempted and that it will preempt, respectively. The method for these notifications has not yet been disclosed.

[0337] Thus, specific methods for preemption in SL have not yet been disclosed. As a result, the problem arises that the requirement for low latency characteristics cannot be met because preemption cannot be implemented. This embodiment 4 discloses a method to solve this problem.

[0338] In normal SL communication, the transmitting UE (Sending UE) includes scheduling information such as resource allocation information for the PSSCH and the communication target UE (Receiving UE) in the SL control information (SCI) and transmits it via PSCCH. The transmitting UE also transmits PSSCH according to the scheduling information. The receiving UE recognizes that the data is intended for its own UE upon receiving PSCCH, and receives the PSSCH according to the scheduling information to acquire the data.

[0339] Disclosures regarding preemption are made. The transmitting UE transmits preemption indication information (PI) via PSCCH. The transmitting UE may include the preemption indication information in the SCI and transmit it via PSCCH. The transmitting UE may transmit the resource allocation information of the communication to be preempted and the preemption indication information via PSCCH. The transmitting UE may include the resource allocation information of the communication to be preempted and the preemption indication information in the SCI and transmit it via PSCCH. The transmitting UE may transmit this information via the PSCCH of the communication to be preempted. Instead of the resource allocation information of the communication to be preempted as described above, scheduling information of the communication to be preempted may be used. The transmitting UE may include the scheduling information of the communication to be preempted and the preemption indication information in the SCI and transmit it via PSCCH.

[0340] In SL, all UEs performing SL communication are capable of receiving the PSCCH of the configured resource pool. Both the receiving UE in the preempting communication and the receiving UE in the preempted communication are capable of receiving the PSCCH. Therefore, the receiving UE in the preempting communication can receive resource allocation information, and the receiving UE in the preempted communication can receive information indicating preemption.

[0341] The SCI may be divided into two, for example, SCI1 and SCI2. Two different channels may be provided for transmitting each SCI, for example, PSCCH1 and PSCCH2. One PSCCH, for example PSCCH1, can be received by all UEs with a configured resource pool, similar to a conventional PSCCH. The other PSCCH, for example PSCCH2, unlike a conventional PSCCH, can only be received by one UE or group of UEs.

[0342] Information indicating preemption may be included in the SCI1 of PSCCH1, which is receivable by all UEs configured with a resource pool. Resource allocation information for the communication to be preempted and information indicating preemption may be included in the SCI1 of PSCCH1, which is receivable by all UEs configured with a resource pool. Other information may be included in SCI2. In this way, both the receiving UE in the communication to be preempted and the receiving UE in the communication that is being preempted will be able to receive the SCI1 of PSCCH1.

[0343] The receiving UE of a preempted communication receives the PSCCH and determines whether the SCI contains a PI. If the PI is not included, the receiving UE determines that the communication is not preempted. If the PI is included, the receiving UE determines that the communication is preempted. If the receiving UE determines that the communication is preempted, it does not receive the resources allocated in the PSCCH.

[0344] The PI may include allocation information for resources to be preempted. In this case, if a receiving UE of a preempted communication determines that it is being preempted, it will not receive the resources allocated according to the resource allocation information included in the PI. This prevents the receiving UE of a preempted communication from receiving PSSCH messages sent to other receiving UEs using the preempted resources.

[0345] A receiving UE of a preempted communication receives a PSCCH and determines whether its own identifier is included in the SCI as the target UE. If its own identifier is not included, the receiving UE determines that the data was not sent to its own UE and does not receive the PSCCH. If its own identifier is included, the receiving UE determines that the data was sent to its own UE and receives the PSCCH using the scheduling information included in the SCI. In this way, a receiving UE of a preempted communication can receive the PSCCH sent from the preempted resource.

[0346] The communication resources that are preempted may be reserved resources or resources to which data has actually been allocated. The method disclosed above can also be applied when preempting reserved resources.

[0347] The following are five specific examples of information included in PI. (1) Information indicating preemption. (2) Information about the resources to be preempted. (3) Information indicating the receiving process in the event of preemption. (4) Information about the receiving UE of the preempted communication. (5) A combination of (1) through (4).

[0348] Regarding (1) above, the information indicating preemption may be information indicating whether or not preemption has occurred, or it may be information indicating that preemption has occurred.

[0349] Regarding (2) above, the information of the preempted resource may be resource allocation information. The resource information may also be time-frequency information. For example, this could be slot number, number of slots, PRB number, number of PRBs, etc. As time units, this could be TTI, slot, mini-slot, symbol, 1 / n symbol (where n is a positive integer), CBG (Code Block Group), etc. As frequency units, this could be PRB, subcarrier, etc.

[0350] The information about preempted resources may be limited to time information only. In this case, frequency resources may be the same as those already allocated or reserved. This reduces the amount of information about preempted resources.

[0351] RS in SL may be excluded from the resources to be preempted. For example, DMRS may be excluded. For example, when performing preemption on a symbol-by-symbol basis, symbols excluding DMRS may be included as the resources to be preempted. By using DMRS, the receiving UE of a preempted communication can improve the likelihood of being able to demodulate the data mapped to the slot containing the preempted resource.

[0352] Regarding (3) above, the receiving process in the case of preemption may be a process that does not receive only the preempted resource, or it may be a process that does not receive a predetermined resource that includes the preempted resource. The predetermined resource may be, for example, a slot. Alternatively, the predetermined resource may be a set of multiple consecutive slots. As another example, the receiving process in the case of preemption may be a process that does not receive all of the data for which some resources have been preempted. This makes the receiving process simpler. The receiving process described here may also be a data demodulation process.

[0353] Regarding (4) above, the information regarding the receiving UE of the preempted communication should be information that identifies the receiving UE. For example, this information may be an identifier for the UE. This allows for the explicit identification of the receiving UE to be preempted, thereby reducing the occurrence of malfunctions.

[0354] The PSCCH containing the PI may be the PSCCH of the slot / mini-slot that performs resource allocation for the preempted resource. This allows the PSCCH to notify the PI when a PSCCH is sent on the preempted resource. Alternatively, the PSCCH containing the PI may be the PSCCH immediately following the slot that performs resource allocation for the preempted resource. This allows the PSCCH to notify the PI even if no PSCCH is sent on the preempted resource.

[0355] The transmitting UE may transmit information about the receiving UE of the communication to be preempted via PSCCH. The transmitting UE may also transmit information about the receiving UE of the communication to be preempted via PSCCH, along with scheduling information including resource allocation information for the communication to be preempted and PI, in SCI. The information about the receiving UE of the communication to be preempted may be information for identifying the receiving UE. This information may be, for example, an identifier for the UE.

[0356] When sending information about the receiving UE of a communication to be preempted via PSCCH, the transmission of PI may be omitted. The transmitting UE includes information about the receiving UE of the communication to be preempted, along with scheduling information including resource allocation information for the communication to be preempted, in the SCI and transmits it via PSCCH.

[0357] The receiving UE of a preempted communication receives a PSSCH and, based on the information about the receiving UE of the preempted communication, can recognize that the data is intended for another UE. The receiving UE of a preempted communication should not receive the resources indicated in the resource allocation information.

[0358] The receiving UE of a preempted communication receives a PSCCH, recognizes from the information about the receiving UE of the preempted communication that it is scheduling information for its own UE, and receives a PSSCH according to the scheduling information.

[0359] When a transmitting UE performs preemption, it may choose not to send only the preempted resources to the receiving UE of the preempted communication. This minimizes the amount of data not sent to the receiving UE of the preempted communication. Alternatively, the transmitting UE may choose not to send to the receiving UE of the preempted communication using a predetermined resource that includes the preempted resources. This predetermined resource could be, for example, one or more CBGs (Code Block Groups) or one or more slots. For example, if multiple slots are scheduled, the transmitting UE may choose not to send to the receiving UE of the preempted communication using multiple slots that include the preempted resources. This simplifies the processing for the transmitting UE.

[0360] If a transmitting UE is scheduling a transmission to a receiving UE for a preempted communication, and the transmission is performed on a resource other than the preempted resource, the transmitting UE may rate-match the transmission data to the resource other than the preempted resource and send it. The transmitting UE can then send data on the resource that is performing the scheduling. Information regarding rate matching should be notified from the transmitting UE to the receiving UE. The information indicating the receiving process in the case of preemption, as described above, may be included in the PI (Public Indicator) and notified from the transmitting UE to the receiving UE.

[0361] When preemption is performed, the sending process of the preempted communication to the receiving UE at the sending UE and the receiving process in the case of preemption at the receiving UE may be appropriately mapped as needed. For example, if the sending UE decides not to send one slot containing the preempted resource to the receiving UE of the preempted communication during preemption, the receiving process at the receiving UE may be to not receive one slot containing the preempted resource. In this case, the sending UE may notify the receiving UE of the sending process for the preempted communication to the receiving UE instead of the information indicating the receiving process in the case of preemption as described above.

[0362] This enables preemption in SL communication. Therefore, preemption can be implemented in SL communication where low latency is required, making it possible to satisfy the low latency characteristics required for communication.

[0363] Figure 23 is a diagram illustrating the overview of preemption in SL communication. Figure 23 shows the case where the transmitting UE of the preempted communication and the transmitting UE of the preempting communication are the same, but the receiving UE of the preempted communication and the receiving UE of the preempting communication are different. Assume that UE1 is the transmitting UE, UE2 is the receiving UE of the preempted communication, and UE3 is the receiving UE of the preempting communication. The communication from UE1 to UE3 is a communication that requires lower latency characteristics.

[0364] Resource reservations are made from UE1 to UE2. Here, it is assumed that resource reservations are made periodically. The example in Figure 23 shows that three resource slots are reserved periodically. However, one slot may be reserved, or multiple slots may be reserved. With resource reservations already made from UE1 to UE2 in this state, the transmission of SL to UE3 is triggered in UE1. UE1 performs the transmission process and selects resources. Resource selection is done in the Selection Window.

[0365] Shortening the resource selection window period reduces the time until transmission, resulting in lower latency. However, shortening the resource selection window period reduces the number of selectable resources, increasing the likelihood that a resource may already be reserved. Making reserved resources preemptible can increase the number of selectable resources.

[0366] UE1 decides to preempt resources already reserved for UE2 in order to communicate with UE3, which requires low latency. Here, UE1 preempts the second slot after the transmission process. UE1 then transmits to UE3 using the preempted resources. UE1 may choose not to transmit to UE2 using the preempted resources. Here, UE1 does not transmit to UE2 using the second slot.

[0367] In this way, UE1 preempts resources already reserved for UE2 and sends them to UE3. This makes it possible to communicate with UE3, which requires even lower latency characteristics, with low latency.

[0368] Figure 24 shows a first example of a preemption method in SL communication. Similar to Figure 23, Figure 24 shows three slots containing resources to be preempted. PSCCH, PSSCH, GAP, and PSFCH are mapped to each slot. PSCCH and PSSCH are transmitted from the transmitting UE. GAP is a no-transmission section. PSFCH is a feedback channel and includes HARQ feedback (Ack, Nack), CSI reports, SRS, etc., and is transmitted from the receiving UE.

[0369] Figure 24 illustrates the case where UE1 has already reserved 3 resource slots to UE2, and the second slot is preempted. UE1 triggers the transmission of an SL to UE3, and UE1 decides to preempt the resource in the second slot after transmission processing in order to communicate with UE3. The first and third slots continue to transmit to UE2 as usual, so PSCCH and PSSCH are sent from UE1 to UE2.

[0370] SCI is mapped to PSCCH. SCI may include the slot configuration. For example, SCI may include the configuration such as the number of symbols and symbol numbers to which PSSCH, GAP, and PSFCH are mapped. In this way, the receiving UE can recognize the configuration of the slots transmitted from the transmitting UE.

[0371] UE1 preempts the second slot, after the transmission process to UE3, for communication with UE3. In this second slot, resources for UE2 are preempted. In the preempted second slot, UE1 transmits PSCCH and PSSCH to UE3. The preempted slot may be configured to map GAP and PSFCH. UE1 includes scheduling information, such as resource allocation information for PSSCH, and PI in the PSCCH of the preempted slot and transmits it.

[0372] The scheduling information, such as resource allocation information from PSSCH, may be included in the SCI, and the SCI and PI may be transmitted via PSCCH. Alternatively, the scheduling information, such as resource allocation information from PSSCH, and the PI may be included in the SCI and transmitted via PSCCH. In addition, information to identify UE3 may be included in the SCI.

[0373] In SL communication, any receiving UE can receive the PSCCH in the resource pool. Therefore, both UE2 and UE3 can receive the PSCCH in the second slot. UE2 can determine whether a resource is preempted based on whether the received PSCCH contains a PI. If no PI is included, UE2 determines that it is a scheduling call for its own UE and receives the PSCCH using the scheduling information. If a PI is included, UE2 determines that the resource is preempted and does not receive the resource allocated in the PSCCH.

[0374] This prevents UE2 from mistakenly receiving resources that have been preempted by other UEs. UE3 receives the PSCCH in the second slot, recognizes that the PSSCH is destined for its own UE, and can then receive the PSSCH using the scheduling information contained in the SCI.

[0375] This preemption method enables preemption in SL communication. For communications requiring low latency, it becomes possible to preempt resources that have already been allocated or reserved. This makes it possible to satisfy the requirement for low latency.

[0376] When UE1 performs preemption for UE3, it may choose not to send only the preempted resources to UE2. This minimizes the amount of data not sent to UE2. Alternatively, UE1 may choose not to send slots containing preempted resources to UE2. Or, if multiple slots are scheduled, UE1 may choose not to send multiple slots containing preempted resources to UE2. This simplifies the processing for both UE1 and UE2.

[0377] For the transmission process from UE1 to UE2, the settings suitable for receiving in the case of preemption, as disclosed in the specific examples of information included in PI, may be used. These transmission and reception methods may be associated in advance. Which transmission method and which reception method to use may be determined statically by standards, etc., or the gNB may set it and notify the UE of SL communication. Alternatively, which transmission method and which reception method to use may be preconfigured in advance by the UE.

[0378] When UE1 preempts the first slot that is reserved or scheduled for UE2, UE1 notifies UE3 of the scheduling information via the PSCCH of the first slot. UE1 also notifies UE2 of the PI via the PSCCH of the first slot. The PSCCH of the first slot is mapped to the scheduling information for UE3, but not to the scheduling information for UE2. Therefore, UE2 cannot receive the scheduling information for the first slot. In this case, UE1's transmission process may be one that does not send to UE2 via the first slot, and UE2's reception process may be one that does not receive via the first slot.

[0379] This prevents UE2 from mistakenly receiving data intended for UE3 in the first slot. UE2 should receive the PSCCH in the second slot. If a PSSCH is scheduled from UE1 to UE2 in the second slot, UE2 can receive the scheduling information and thus receive the PSSCH.

[0380] If UE1 preempts the first slot that is reserved or scheduled for UE2, UE1 does not need to notify UE2 of the PI in the first slot's PSCCH. UE1 may only notify scheduling information for UE3 in the first slot's PSCCH. If UE2 recognizes that the first slot is scheduled for UE3, it should not receive the first slot. This prevents UE2 from mistakenly receiving data intended for UE3 in the first slot.

[0381] This document discloses how data from preempted resources is handled for UE2. UE1 may send the data from preempted resources to UE2 using the remaining resources. To do this, UE1 may perform rate matching. This allows preempted data to be sent earlier.

[0382] Alternatively, UE1 may send the data of the preempted resource to UE2 using the next reserved resource. The number of times a resource can be re-selected may be set in the NR's SL. If the reserved resource has been used for a predetermined number of re-selections, the resource selection is performed again, and the resource is re-reserved. In this way, monopolization of resources within one's own UE can be avoided.

[0383] If the number of transmissions using a reserved resource has not reached a predetermined number of re-selections, UE1 transmits the data of the preempted resource to UE2 using the next reserved resource. If the number of transmissions using a reserved resource reaches a predetermined number of re-selections, UE1 re-selects the resource, re-reserves the resource, and transmits the data using the newly reserved resource.

[0384] When a newly reserved resource is used to send data from a preempted resource, the re-selection count may not be counted. The re-selection count may also not be decremented. Doing so avoids further increases in latency when sending data from a preempted resource.

[0385] UE1 may perform new resource selection and resource reservations to send data for preempted resources to UE2. These resource selection and reservations may not be periodic, or they may be performed dynamically. Short-term resource reservations may also be performed. This method may be applied even if the preempted resources are periodic. This allows for the early transmission of preempted data without waiting for the next reserved resource.

[0386] Alternatively, UE1 may choose not to perform any special processing for preempted resource data for UE2. If HARQ feedback is applied, UE1 may choose not to perform any special processing for preempted resource data for UE2. If HARQ feedback is applied, UE1 may choose to follow HARQ. If UE2 fails to receive scheduled data, it sends a Nack to UE1. Upon receiving the Nack, UE1 retransmits the data. In HARQ retransmission, UE1 may include information in the SCI indicating which data the retransmission is for. This information may be, for example, a HARQ process identifier. In this way, UE2 is able to receive the scheduled data.

[0387] Furthermore, if repetition transmission is applied and HARQ feedback is also applied, UE1 may not perform any special processing for preempted resource data for UE2. Even if one transmission in a repetition is preempted, other repetition transmissions will still allow UE2 to receive the scheduled data.

[0388] By not performing any special processing on the data of preempted resources in this way, it becomes possible to simplify the preemption process at both the sending and receiving UEs.

[0389] Figure 25 shows a second example of a preemption method in SL communication. Unlike Figure 24, Figure 25 illustrates a preemption method when three slots containing the resources to be preempted are scheduled consecutively. PSCCH, PSSCH, GAP, and PSFCH are mapped to the three consecutive slots. PSCCH is mapped to the first slot of the three consecutive slots. GAP and PSFCH are mapped to the last slot of the three consecutive slots.

[0390] In the example in Figure 24, the PSCCH of the second slot, which is preempted, includes scheduling information such as resource allocation information from the PSSCH, as well as the PI. In the example in Figure 25, scheduling is performed from UE1 to UE2 using three consecutive slots, so the PSCCH is not sent in the second slot. Therefore, UE2 does not receive the PSCCH of the second slot. Even if the PI is sent in the PSCCH of the second slot, UE2 will not receive the PI.

[0391] To solve this problem, in the example in Figure 25, UE1 includes the PI in the PSCCH of the next slot in the consecutively scheduled slot and sends it. UE2 receives the PSCCH of the next slot in the consecutively scheduled slot. This allows UE2 to determine whether or not the PSCCH contains the PI. Therefore, UE2 can determine whether or not the resource has been preempted.

[0392] UE2 should retain received data until it determines whether a resource has been preempted in a scheduled sequence of slots. If a resource is preempted, UE2 excludes the preempted resource and receives the data. If the resource is not preempted, UE2 receives data from the three consecutive slots. This prevents UE2 from mistakenly receiving preempted data.

[0393] The PSCCH for the second slot is transmitted from UE1 to UE3, and this PSCCH does not include PI. Upon receiving the PSCCH for the second slot, UE3 obtains the scheduling information for the PSSCH and becomes able to receive the PSSCH.

[0394] UE1 disclosed that it transmits the PI in the PSCCH of the slot following the consecutively scheduled slot, but another method is disclosed. UE1 may transmit the PI to UE2 in the PSCCH of the slot reserved or allocated to the next consecutively scheduled slot. UE2 receives the PSCCH of the slot reserved or allocated to its UE following the consecutively scheduled slot. This allows UE2 to determine whether the PSCCH contains the PI. Thus, UE2 can determine whether the resource is preempted.

[0395] When UE1 preempts the first slot that is reserved or scheduled for UE2, UE1 notifies UE3 of scheduling information via the PSCCH of the first slot. Alternatively, UE1 may also notify UE2 of a PI via the PSCCH of the first slot. The PSCCH of the first slot is mapped to the scheduling information for UE3, but not to the scheduling information for UE2. As a result, UE2 will not receive the scheduling information for the first slot. In such a case, UE1's transmission process may be a process that does not send to UE2 for three consecutive slots, and UE2's reception process may be a process that does not receive for three consecutive slots. By doing so, it is possible to prevent UE2 from mistakenly receiving data intended for UE3 in the first to third slots.

[0396] If UE1 preempts the first slot that is reserved or scheduled for UE2, UE1 does not need to notify UE2 of the PI in the PSCCH of the first slot. UE1 may only notify scheduling information for UE3 in the PSCCH of the first slot. If UE2 recognizes that the first slot is scheduled for UE3, it should not receive the three consecutive slots. This prevents UE2 from mistakenly receiving data intended for UE3 in the first three slots.

[0397] This preemption method enables preemption in SL communication even when scheduling is performed using multiple consecutive slots.

[0398] Figure 26 shows a third example of a preemption method in SL communication. Similar to Figure 25, Figure 26 illustrates a preemption method when three slots containing the resource to be preempted are scheduled consecutively. Unlike Figure 25, Figure 26 shows the case where the resource to be preempted is a mini-slot.

[0399] Even when the resource to be preempted is a mini-slot, UE1 transmits the PI in the PSCCH of the next slot in the consecutively scheduled slot, similar to the method disclosed in Figure 26. UE2 receives the PSCCH of the next slot in the consecutively scheduled slot. This allows UE2 to determine whether or not the PSCCH contains the PI. Therefore, UE2 can determine whether or not the resource is being preempted.

[0400] The PSCCH of the mini-slot to be preempted in the second slot is sent from UE1 to UE3, and this PSCCH does not include PI. Upon receiving the mini-slot PSCCH, UE3 obtains the scheduling information for the PSSCH and becomes able to receive the PSSCH.

[0401] When UE1 preempts a resource, including the PSCCH area of ​​the first slot that is reserved or scheduled for UE2, using a mini-slot, UE1 notifies UE3 of scheduling information using the mini-slot's PSCCH. UE1 may also notify UE2 of a PI using the mini-slot's PSCCH. The mini-slot's PSCCH is mapped with scheduling information for UE3, but not with scheduling information for UE2. Therefore, UE2 will not receive scheduling information for three consecutive slots. In such a case, UE1's transmission process may be one that does not send data to UE2 for three consecutive slots, and UE2's reception process may be one that does not receive data for three consecutive slots. This prevents UE2 from mistakenly receiving data intended for UE3 in the first three slots.

[0402] If UE1 preempts a resource in a minislot that includes the PSCCH area of ​​the first slot reserved or scheduled for UE2, UE1 does not need to notify UE2 of the PI in the minislot's PSCCH. UE1 may only notify scheduling information for UE3 in the minislot's PSCCH. If UE2 recognizes that the minislot resource is scheduled for UE3, UE2 should not receive the three consecutive slots. This prevents UE2 from mistakenly receiving data for UE3 in the first three slots.

[0403] The receiving UE needs to receive the PSCCH of the minislot in SL communication. When data is scheduled to a minislot in SL communication, the receiving UE receives the PSCCH of that minislot. If the receiving UE does not know the transmission timing of the minislot's PSCCH, it cannot receive the PSCCH. This leads to the problem that the receiving UE cannot receive the minislot's PSCCH. This document discloses a method to solve this problem.

[0404] This document discloses a method for configuring mini-slots in SL. Mini-slot configuration in SL is performed by the transmitting UE. The transmitting UE configures the mini-slots in SL and notifies the receiving UE of the configuration. The PSCCH of a normal slot may be used for this notification. Information for configuring mini-slots may include, for example, the number of symbols in the mini-slot, the number of symbols and / or symbol numbers of the PSCCH, the number of symbols and / or symbol numbers of the PSSCH, and the number of symbols and / or symbol numbers of the RS. The number of symbols and / or symbol numbers of the GAP and PSFCH may also be included in the information for configuring mini-slots.

[0405] Information indicating the relationship with the regular slot may be included in the information for setting up the mini-slot. This information could include, for example, information indicating which symbols of the regular slot the mini-slot corresponds to. It is recommended to set the target mini-slot using the symbol numbers of the regular slot. The same applies to PSCCH, PSSCH, GAP, and PSFCH of the mini-slot. In this way, it becomes possible to set up the mini-slot.

[0406] Other methods are disclosed for a transmitting UE to notify a receiving UE of the minislot configuration. Information for minislot configuration may be notified using MAC signaling. Information for minislot configuration may be included in MAC control information. Information for minislot configuration may be notified using PC5 signaling. Alternatively, if an RRC connection is established between opposing UEs in SL unicast communication, information for minislot configuration may be notified using SL RRC signaling. Information for minislot configuration may be included in SL RRC information.

[0407] This document discloses another method for a transmitting UE to notify a receiving UE of the minislot settings. The transmitting UE notifies the minislot settings via PSBCH. The transmitting UE includes the minislot settings in the broadcast information, maps it to PSBCH, and notifies the UE. This eliminates the need to individually notify the receiving UE of the minislot settings when each transmitting UE sets its own minislot. This reduces the amount of signaling in SL communication.

[0408] Information indicating the activation and / or deactivation of the mini-slot settings may be provided. Hereafter, this information will be referred to as the mini-slot setting act / deact information. The transmitting UE notifies the receiving UE of the mini-slot setting act / deact information. The notification method for mini-slot setting information should be applied to this notification.

[0409] For example, the transmitting UE notifies the receiving UE of information for configuring the mini-slot. Subsequently, the transmitting UE notifies the act information of the mini-slot configuration. A unique identifier may be assigned to each mini-slot configuration, and this identifier may be notified along with the act / deact information of the mini-slot configuration. In this way, even if there are multiple mini-slot configurations, it becomes possible to recognize which mini-slot configuration should be activated.

[0410] The receiving UE applies the mini-slot settings upon receiving the act information of the mini-slot settings. The sending UE sends data via the mini-slot, and the receiving UE receives data via the mini-slot. The sending UE notifies the receiving UE of the deact information of the mini-slot settings. Upon receiving the deact information of the mini-slot settings, the receiving UE cancels the mini-slot settings. The receiving UE may then proceed to receive data from a regular slot. In this way, it is possible to terminate the mini-slot settings in SL.

[0411] This allows for the setting of a mini-slot in SL, enabling transmission and reception using the mini-slot.

[0412] This document discloses an alternative method for configuring the minislot in SL. The gNB configures the minislot in SL. The gNB configures the minislot in SL and notifies the transmitting UE of the configuration. The transmitting UE notifies the receiving UE of the received minislot configuration in SL. The Uu interface between the gNB and the UE is used for this notification. The gNB may include the information for configuring the minislot in SL in the DCI and notify the transmitting UE of the SL communication via PDCCH. This allows for dynamic configuration. Alternatively, the gNB may notify the transmitting UE of the SL communication of the minislot configuration information via MAC signaling. Alternatively, the minislot configuration information may be notified via RRC signaling. This can reduce reception errors.

[0413] For information regarding mini-slot settings, the previously mentioned example should be applied. The method for notifying the receiving UE of the mini-slot settings from the transmitting UE in SL communication should also be the method described above.

[0414] The act / deact settings for the mini-slot configuration may be set by the transmitting UE of the SL communication. The transmitting UE of the SL communication sets the act / deact settings for the mini-slot configuration and notifies the receiving UE. The method described above should be applied to this method. By having the transmitting UE set the act / deact settings for the mini-slot configuration, it becomes possible to configure the mini-slot according to the service of the data transmitted by SL. The time required to set the act / deact settings for the mini-slot configuration can be shortened.

[0415] This document discloses alternative methods for the act / deact of mini-slot configuration. The act / deact of mini-slot configuration may be set by the gNB. The gNB sets the act / deact of mini-slot configuration and notifies the transmitting UE of SL communication. The transmitting UE that receives the act / deact information of mini-slot configuration should notify the receiving UE of the same information. The notification methods for mini-slot configuration information described above should be applied to these notification methods. By having the gNB set the act / deact of mini-slot configuration, it becomes possible to consider the configuration for other UEs performing SL communication. This makes it possible to reduce resource conflicts when performing mini-slot configuration.

[0416] This preemption method enables mini-slot preemption in SL communication.

[0417] Figure 27 shows a fourth example of a preemption method in SL communication. Similar to Figure 25, Figure 27 illustrates a preemption method when three slots containing resources to be preempted are scheduled consecutively. In the example in Figure 27, UE3 ensures that it receives the PSCCH region of each slot even when three consecutive slots are scheduled. This can be statically defined in the standard or other specifications.

[0418] Alternatively, the gNB may notify the UE performing SL communication of information indicating that it is receiving the PSCCH region for each slot. The gNB may broadcast this information by including it in the SIB, or notify the UE via RRC signaling. Alternatively, this information may be pre-configured in the UE.

[0419] Another method is shown. Information indicating that the PSCCH region for each slot is to be received, or information indicating whether or not the PSCCH region for each slot is to be received, may be included in the PSCCH of the first slot. This information may also be included in the PSCCH that contains scheduling information when scheduling is performed on multiple consecutive slots. In this way, UE2 can receive information indicating that the PSCCH region for each slot is to be received by receiving the scheduling of multiple consecutive slots from UE1. For example, when UE1 prints the resources of the second slot to UE3, UE1 sends information to UE2 indicating that the PSCCH region for each slot is to be received. In this way, UE2 can receive the PSCCH of the second slot.

[0420] Furthermore, UE1 transmits a PI to UE2, including it in the PSCCH of the second slot. Similar to the example in Figure 24, UE1 transmits an SCI containing scheduling information, such as resource allocation information for the PSSCH of UE3, and a PI to UE2, in the PSCCH of the second slot. In this way, UE2 is able to receive the PI.

[0421] When UE1 preempts the first slot that is reserved or scheduled for UE2, UE1 notifies UE3 of the scheduling information via the PSCCH of the first slot. UE1 also notifies UE2 of the PI via the PSCCH of the first slot. The PSCCH of the first slot is mapped to the scheduling information for UE3, but not to the scheduling information for UE2. Therefore, UE2 cannot receive the scheduling information for the first slot. In this case, UE1's transmission process may be one that does not send to UE2 via the first slot, and UE2's reception process may be one that does not receive via the first slot.

[0422] This prevents UE2 from mistakenly receiving data intended for UE3 in the first slot. If the UE is to receive the PSCCH region of each slot, as statically determined by the standard or notified by the gNB, then UE2 should receive the PSCCH of the second slot. If a PSSCH is scheduled from UE1 to UE2 in the second slot, UE2 can receive this scheduling information and thus receive the PSSCH.

[0423] If UE1 preempts the first slot that is reserved or scheduled for UE2, UE1 does not need to notify UE2 of the PI in the first slot's PSCCH. UE1 may only notify scheduling information for UE3 in the first slot's PSCCH. If UE2 recognizes that the first slot is scheduled for UE3, it should not receive the first slot. This prevents UE2 from mistakenly receiving data intended for UE3 in the first slot.

[0424] The PI may include information indicating that the PSCCH region for each slot is to be received. UE1 notifies UE2 of the PI for the PSCCH of the first slot. This allows UE2 to receive the scheduling information and thus receive the PSCCH if a PSSCH is scheduled for the second slot from UE1.

[0425] By using the method disclosed in Figure 27, unlike the methods disclosed in Figures 25 or 26, UE1 no longer needs to send the PI to UE2 in the next slot of a series of consecutively scheduled slots. As a result, UE2 can determine earlier whether a resource has been preempted by receiving the PI earlier. UE2 can then demodulate the data earlier, excluding the preempted resource. Furthermore, UE2 does not need to hold the data until it receives the PI in the next slot. This reduces the data buffer capacity in UE2.

[0426] Another example of a preemption method in SL communication is disclosed. A resource for PI transmission is provided. The resource for PI transmission may be provided within the reserved or allocated resources of the communication to be preempted, but outside the resources being preempted. The resource for PI transmission may be a time-frequency resource. The time unit of the resource may be, for example, a slot, a minislot, a symbol, or a 1 / n symbol. The frequency unit of the resource may be, for example, a PRB or a subcarrier.

[0427] The configuration of the PI transmission resources may include, for example, slot number, number of symbols, symbol number, number of PRBs, PRB number, etc. The PI transmission resource configuration may be predetermined statically by a standard or the like. Alternatively, the gNB may determine the PI transmission resource configuration and notify the UE performing SL communication of the determined resource configuration via SIB. Alternatively, the gNB may determine the PI transmission resource configuration and notify the transmitting UE of the SL communication of the determined resource configuration via RRC signaling. The transmitting UE may also notify the receiving UE of the PI transmission resource configuration via PSCCH.

[0428] Alternatively, the transmitting UE in SL communication may determine the PI transmission resource configuration and notify the receiving UE of the determined configuration. The transmitting UE may also notify the receiving UE of the PI transmission resource configuration via PSCCH. When the transmitting UE and / or receiving UE in SL communication receive the PI transmission resource configuration, they can use the PI transmission resource configuration to transmit and receive PIs.

[0429] The transmitting UE transmits the PI using a resource for transmitting the PI. Alternatively, a channel containing the PI may be provided and mapped to the resource for transmitting the PI. Alternatively, the PI may be included in the PSCCH and mapped to the resource for transmitting the PI. The receiving UE may receive the PI transmitting resource if the configuration for the PI transmitting resource is notified.

[0430] Alternatively, information indicating the activation and / or deactivation of the PI transmission resource reception may be provided. The transmitting UE sends act / deact information of the PI transmission resource reception to the receiving UE via PSCCH. When the receiving UE receives act information of the PI transmission resource reception, it receives the PI transmission resource using the PI transmission resource configuration. When the receiving UE receives deact information of the PI transmission resource reception, it terminates the reception of the PI transmission resource using the PI transmission resource configuration.

[0431] A specific example is disclosed. When scheduling with multiple consecutive slots, the transmitting UE uses the symbol immediately preceding the GAP of the last slot as the resource for PI transmission. The transmitting UE transmits the PI using this symbol. The transmitting UE may send this PI transmission resource configuration to the receiving UE using the PSCCH of the first slot. In this way, the receiving UE can receive the PI transmission resource configuration and use it to receive the PI.

[0432] This method allows for the transmission of PIs within multiple consecutive slots, even when preempting resources scheduled across multiple consecutive slots. Therefore, unlike the examples in Figures 25 and 26, the transmitting UE does not need to transmit the PI on the PSCCH of the next slot in the sequence. Furthermore, the receiving UE only needs to receive the configured PI transmission resource to receive the PI. Therefore, unlike the method shown in Figure 27, the receiving UE does not need to receive the PSCCH of every slot. Also, the receiving UE only needs to receive the reserved or allocated resource for the preempted communication to receive the PI. This simplifies processing on the receiving UE.

[0433] The method described above discloses the provision of a resource for PI transmission. The transmitting UE transmits the PI using the PI transmission resource. In this case, the transmitting UE does not transmit data. Here, another example of a preemption method in SL communication is disclosed.

[0434] The transmitting UE uses a resource for PI transmission to multiplex the PI or a channel containing the PI with the data. The transmitting UE may also use a resource for PSCCH to multiplex the PSCCH containing the PI with the data. Code multiplexing is a good method for multiplexing. As a method of code multiplexing, for example, a method of multiplying the channel containing the PI by a predetermined scrambling code may be used. Alternatively, a predetermined ZC (Zadoff-Chu) sequence may be used on the channel containing the PI.

[0435] The predetermined scrambling code or ZC sequence may be statically determined in advance by a standard or the like, or it may be notified from the transmitting UE to the receiving UE. In this way, the receiving UE can separate the PI from the data and demodulate it, and thus receive the PI.

[0436] Different scrambling codes may be applied to the data or data demodulation RS and the channel containing the PI. Alternatively, different ZC sequences may be used for the data or data demodulation RS and the channel containing the PI. These scrambling codes or ZC sequences may be predetermined statically by standards or the like. Alternatively, the gNB may determine the scrambling codes or ZC sequences and notify the UE performing SL communication of the determined scrambling codes or ZC sequences. Alternatively, the transmitting UE may determine the scrambling codes or ZC sequences and notify the receiving UE of the determined scrambling codes or ZC sequences. In this way, the receiving UE can demodulate the data and PI separately and receive the data and PI.

[0437] Another example of a preemption method in SL communication is disclosed. Resources for PI transmission are provided outside the reserved or allocated resources of the communication to be preempted. The PI transmission resource configuration may be periodic. For the PI transmission resource configuration, the method of notifying the PI transmission resource configuration, and the PI transmission and reception methods at the transmitting UE and receiving UE, it is preferable to apply the example disclosed above, i.e., the example where resources for PI transmission are provided within the reserved or allocated resources of the communication to be preempted, but outside the resources being preempted.

[0438] A transmitting UE performing SL communication should exclude the PI transmission resource and reserve the SL communication resource instead. This will help avoid conflicts between the SL communication resource and the PI transmission resource.

[0439] This approach increases the number of potential resources available for PI transmission. Furthermore, it allows PI transmission without reducing the resources used for preempted communications.

[0440] Resources for PI transmission may be provided inside or outside the reserved or allocated resources for the preempted communication. The method disclosed above may be applied.

[0441] The example in the aforementioned figure disclosed a case where resource reservations from UE1 to UE2 are performed periodically. The method disclosed in Embodiment 4 does not necessarily have to be applied when resource reservations or scheduling from UE1 to UE2 are performed periodically; for example, it may be applied when resource reservations or scheduling from UE1 to UE2 are performed aperiodically. The method disclosed in Embodiment 4 may also be applied when resource reservations or scheduling from UE1 to UE2 are performed dynamically. Similar effects can be obtained.

[0442] The decision of whether or not preemption is possible should be made by the transmitting UE. The transmitting UE determines whether it is possible to preempt resources that have already been reserved or scheduled for communication of an existing service for communication of another service. Information about the service may be used in this determination. This information may include, for example, QoS information, QCI, PPPP, required latency, required slew rate, etc.

[0443] For example, if a service sending data that occurs later requires a shorter delay than a service that has already been reserved or scheduled, it may be possible to preempt it.

[0444] Let's look at a specific example. The transmitting UE reserves resources for communication of a service with a requested delay time of L1. In this state, suppose data for a service with a requested delay time of L2 is generated at the transmitting UE. Here, the requested delay time of L2 is smaller than the requested delay time of L1 (L1 > L2). In this way, if the requested delay time of the later-generating service is smaller, preemption is possible. The transmitting UE compares the requested delay times of these services and determines that preemption is possible if the requested delay time of the later-generating service is smaller.

[0445] These decisions may be made in the MAC of the SL. The MAC of the SL may use information about the service to determine whether or not it is preemptible. The MAC of the SL may obtain information about the service from the higher layer. By determining whether or not it is preemptible in the MAC of the SL, it is possible to facilitate the coordination between scheduling for communications to be preempted and scheduling for communications to be preempted.

[0446] The method disclosed in this embodiment 4 enables preemption in SL. Therefore, even when a transmitting UE transmits data for multiple services and each service uses a different receiving UE, preemption can be implemented in SL communication for services that require low latency. This makes it possible to satisfy the low latency requirements for communication.

[0447] Modification 1 of Embodiment 4. Embodiment 4 disclosed a preemption method when the transmitting UE of the communication to be preempted and the transmitting UE of the communication that preempts are the same. This Modification 1 discloses a preemption method when the transmitting UE of the communication to be preempted and the transmitting UE of the communication that preempts are different.

[0448] When the sending UE of a preempted communication and the sending UE of a preempting communication are different, the problem is not only how to notify the receiving UE of the preempted communication that preemption has occurred, but also how to notify the sending UE of the preempted communication that preemption has occurred. If the sending UE of the preempted communication does not recognize that preemption has occurred, it will attempt to send data using the preempted resource, resulting in a collision with the preempting communication. This collision will prevent both the receiving UE of the preempted communication and the receiving UE of the preempting communication from receiving data. This modified example 1 discloses a method for solving this problem.

[0449] The transmitting UE of a preempted communication sends PI2 using a resource in a slot prior to the resource being preempted that is receivable by the preempted transmitting UE. The transmitting UE of a preempted communication may also map a channel containing PI2 to a resource in a slot prior to the resource being preempted that is receivable by the preempted transmitting UE and send PI2. The transmitting UE of a preempted communication may also send PI2 on a PSFCH in a slot prior to the resource being preempted.

[0450] PI2 is information indicating preemption. Five specific examples of information included in PI2 are disclosed below. (1) Information indicating preemption. (2) Information about the resources to be preempted. (3) Information indicating the transmission process in the case of preemption. (4) Information about the transmitting UE of the communication to be preempted. (5) A combination of (1) through (4).

[0451] The aforementioned (1) and (2) are the same as for PI.

[0452] Regarding (3) above, the transmission process in the case of preemption may be a process that does not transmit only the resources that are preempted, or it may be a process that does not transmit a predetermined resource that includes the resources that are preempted. The predetermined resource may be, for example, a slot. Alternatively, the predetermined resource may be a series of consecutive slots. As another example, the transmission process in the case of preemption may be a process that does not transmit all of the data for which some resources are preempted. This makes the transmission process simpler. The transmission process may also be a process that stops transmission, or a process that turns off or reduces the transmission power.

[0453] Regarding (4) above, the information regarding the transmitting UE of the communication to be preempted should be information that identifies the transmitting UE. For example, this information may be an identifier for the UE. This allows for the explicit identification of the transmitting UE to be preempted, thereby reducing the occurrence of malfunctions.

[0454] In this way, the sending UE of a preempted communication can receive PI2 from the sending UE of the preempting communication using the receiving symbol of the slot preceding the resource being preempted. By receiving PI2, the sending UE of a preempted communication can recognize the resource being preempted. This allows it to perform actions such as stopping transmission on the preempted resource.

[0455] Methods for sending scheduling information, including resource allocation, from the transmitting UE of the communication to be preempted to the receiving UE of the communication to be preempted, and methods for sending PI from the transmitting UE of the communication to be preempted to the receiving UE of the communication to be preempted, may be based on the methods disclosed in Embodiment 4.

[0456] This approach enables preemption even when the sending UE of the preempted communication and the sending UE of the preempting communication are different.

[0457] Figure 28 is a diagram illustrating the overview of preemption in SL communication. Figure 28 shows the case where the transmitting UE of the preempted communication and the transmitting UE of the preempting communication are different. Assume that UE1 is the transmitting UE of the preempted communication, UE2 is the receiving UE of the preempted communication, UE3 is the transmitting UE of the preempting communication, and UE4 is the receiving UE of the preempting communication. The communication from UE3 to UE4 is a communication that requires lower latency characteristics.

[0458] Resource reservations are made from UE1 to UE2. Here, as in Figure 23, resource reservations are assumed to be made periodically. With resource reservations already made from UE1 to UE2, UE3 is triggered to send an SL to UE4. UE3 performs the sending process and selects resources. Resource selection is done within the selection window.

[0459] UE3 decides to preempt resources that UE1 has already reserved for UE2 in order to communicate with UE4, which requires low latency. Here, UE3 preempts the second slot after the transmission process. UE3 then sends a transmission to UE4 using the preempted resources. UE1 may choose not to send a transmission to UE2 using the preempted resources. Here, UE1 does not send a transmission to UE2 using the second slot.

[0460] In this way, UE3 preempts and sends resources that UE1 has already reserved for UE2 to UE4. This makes it possible to communicate with UE4, which requires even lower latency characteristics, with low latency.

[0461] Figure 29 shows a first example of a preemption method in SL communication. Similar to Figure 28, Figure 29 shows three slots containing resources to be preempted. PSCCH, PSSCH, GAP, and PSFCH are mapped to each slot.

[0462] Figure 29 illustrates the case where UE1 has already reserved 3 resource slots to UE2, and the second slot is preempted. UE3 triggers the transmission of an SL to UE4, and UE3 decides to preempt the second slot's resource after transmission processing in order to communicate with UE4. The first and third slots continue to transmit from UE1 to UE2 as usual, so UE1 sends PSCCH and PSSCH to UE2.

[0463] UE3 sends PI2 with a symbol that UE1 can receive in the slot immediately preceding the second slot to be preempted (i.e., the first slot). Here, UE3 includes PI2 in PSFCH and sends it with a symbol that UE1 can receive.

[0464] In this way, UE1 can receive PI2 before the second slot is preempted. Upon receiving PI2, UE1 becomes aware of the preempted resource. Therefore, UE1 can, for example, stop transmitting on the preempted resource. In this case, UE1 stops transmitting on the second preempted slot. In this way, UE1 can avoid interfering with the communication from UE3 to UE4 on the second preempted slot.

[0465] UE3 preempts the second slot, after the transmission process to UE4, for communication with UE4. In this second slot, resources for UE2 are preempted. In the preempted second slot, UE3 transmits PSCCH and PSSCH to UE4. The preempted slot may be configured to map GAP and PSFCH. UE3 transmits scheduling information, such as resource allocation information for PSSCH to UE4, and PI to UE2, in the PSCCH of the preempted slot. Since PSCCH is also receivable by UE2, UE2 can receive the PI contained in the PSCCH transmitted from UE3.

[0466] This prevents UE2 from mistakenly receiving resources that have been preempted by other UEs. UE4 receives the PSCCH in the second slot, recognizes that the PSSCH is destined for its own UE, and can then receive the PSSCH using the scheduling information contained in the SCI.

[0467] PI2 or a channel containing PI2 may be multiplexed with PSFCH. The transmitting UE of a preempted communication may transmit by multiplexing PI2 or a channel containing PI2 with PSFCH using resources that the preempted transmitting UE can receive.

[0468] A method for multiplexing PI2 and PSFCH is disclosed. Time-division multiplexing is recommended. Multiplexing should be performed using symbols that UE1 can receive. The symbols that UE1 can receive should be different from the symbols that map PI2 and the symbols that map PSFCH. In this way, UE1 can receive both PI2 and PSFCH.

[0469] The slot format settings can be changed depending on whether PI2 is present or not. For example, if PI2 is present, the number of receive symbols in the slot can be set to 2, and if PI2 is not present, the number of receive symbols in the slot can be set to 1. This eliminates the need to reserve symbols for PI2 when PI2 is not present, allowing those symbols to be used for other purposes (e.g., transmission). This improves resource utilization efficiency.

[0470] Other multiplexing methods for PI2 and PSFCH are disclosed. Frequency division multiplexing is a good method. Multiplexing is performed using the frequency domain of symbols that UE1 can receive. The frequency domains for mapping PI2 (e.g., PRB) and PSFCH (e.g., PRB) are made different in the symbols that UE1 can receive. In this way, UE1 can receive both PI2 and PSFCH.

[0471] Other multiplexing methods for PI2 and PSFCH are disclosed. Code splitting multiplexing is recommended. Multiplexing using scrambling codes or ZC sequences is recommended for symbols that UE1 can receive. The scrambling codes applied to PI2 and the scrambling codes applied to PSFCH should be different for symbols that UE1 can receive. In this way, UE1 can receive both PI2 and PSFCH. Multiplexing may also be performed using the CS (Cyclic Shift) of the ZC sequence. A similar effect can be obtained.

[0472] PI2 may be included in the PSFCH. For example, it is good to include HARQ feedback information and PI2 information in the PSFCH. For example, SL feedback control information (SFCI (Sidelink Feedback Control information)) is provided and this information is mapped to the PSFCH. It is good to include HARQ feedback information and PI2 information in the SFCI.

[0473] PI2 may be included in the PSFCH, and this PSFCH may be multiplexed with PSFCHs from other UEs. The multiplexing method should be the one described above. In this way, UE1 will be able to receive both PI2 and the PSFCH.

[0474] This preemption method enables preemption in SL communication even when the transmitting UE of the preempted communication and the transmitting UE of the preempting communication are different. It also allows for the preemption of resources that have already been allocated or reserved for communications requiring low latency. This makes it possible to satisfy the requirement for low latency.

[0475] For the transmission process of preempted resources in UE1 and the reception process in UE2, the methods disclosed in Embodiment 4 may be applied as appropriate. For example, the method disclosed in the example in Figure 24 may be applied as appropriate. Similar effects can be obtained. Similarly, for the processing of data from preempted resources to UE2, the methods disclosed in Embodiment 4 may be applied as appropriate. For example, the method disclosed in the example in Figure 24 may be applied as appropriate. Similar effects can be obtained.

[0476] For the process of preempting the first slot reserved or scheduled from UE1 to UE2, the method disclosed in Embodiment 4 may be applied as appropriate. For example, the method disclosed in the example in Figure 24 may be applied as appropriate. Similar effects can be obtained.

[0477] Figure 30 shows a second example of a preemption method in SL communication. Unlike Figure 29, Figure 30 illustrates a preemption method when three slots containing the resources to be preempted are scheduled consecutively. PSCCH, PSSCH, GAP, and PSFCH are mapped to the three consecutive slots. PSCCH is mapped to the first slot of the three consecutive slots.

[0478] Traditionally, GAP and PSFCH are mapped to the last slot of three consecutive slots. In this modified example 1, a receiving symbol is mapped to each slot. Here, PSFCH is mapped to the receiving symbol.

[0479] UE3 sends PI2 with a symbol that UE1 can receive in the slot immediately preceding the second slot to be preempted (i.e., the first slot). Here, UE3 includes PI2 in PSFCH and sends it with a symbol that UE1 can receive.

[0480] In this way, UE1 can receive PI2 before the second slot is preempted. Upon receiving PI2, UE1 becomes aware of the preempted resource. Therefore, UE1 can, for example, stop transmitting on the preempted resource. In this case, UE1 stops transmitting on the second preempted slot. In this way, UE1 can avoid interfering with the communication from UE3 to UE4 on the second preempted slot.

[0481] In the example in Figure 29, the PSCCH of the second slot, which is preempted, includes scheduling information such as resource allocation information from UE3 to UE4 via PSCCH, and PI from UE3 to UE2. In the example in Figure 30, scheduling is performed from UE1 to UE2 using three consecutive slots, so PSCCH is not sent in the second slot. Therefore, UE2 does not receive PSCCH from the second slot. Even if PI is sent in PSCCH from the second slot, UE2 will not receive the PI.

[0482] To solve this problem, in this modified example 1, UE3 includes the PI in the PSCCH of the next slot in the consecutively scheduled slots and transmits it. UE2 receives the PSCCH of the next slot in the consecutively scheduled slots. This allows UE2 to determine whether or not the PSCCH contains the PI. Therefore, UE2 can determine whether or not the resource has been preempted.

[0483] UE2 should retain received data until it determines whether a resource has been preempted in a scheduled sequence of slots. If a resource is preempted, UE2 excludes the preempted resource and receives the data. If the resource is not preempted, UE2 receives data from the three consecutive slots. This prevents UE2 from mistakenly receiving preempted data.

[0484] The PSCCH for the second slot is sent from UE3 to UE4, and this PSCCH does not include PI. By receiving the PSCCH for the second slot, UE4 obtains the scheduling information for the PSSCH and becomes able to receive the PSSCH.

[0485] For the transmission process of preempted resources in UE1 and the reception process in UE2, the methods disclosed in Embodiment 4 may be applied as appropriate. For example, the method disclosed in the example in Figure 25 may be applied as appropriate. Similar effects can be obtained. Similarly, for the processing of preempted resource data to UE2, the methods disclosed in Embodiment 4 may be applied as appropriate. For example, the method disclosed in the example in Figure 25 may be applied as appropriate. Similar effects can be obtained.

[0486] For the process of preempting the first slot reserved or scheduled from UE1 to UE2, the method disclosed in Embodiment 4 may be applied as appropriate. For example, the method disclosed in the example in Figure 25 may be applied as appropriate. Similar effects can be obtained.

[0487] This preemption method enables preemption in SL communication even when scheduling is performed using multiple consecutive slots.

[0488] Figure 31 shows a third example of a preemption method in SL communication. Similar to Figure 30, Figure 31 illustrates a preemption method when three slots containing the resource to be preempted are scheduled consecutively. Unlike Figure 30, Figure 31 shows the case where the resource to be preempted is a mini-slot.

[0489] Even when the resource to be preempted is a mini-slot, UE3 transmits the PI in the PSCCH of the next slot in the consecutively scheduled slot, similar to the method disclosed in Figure 30. UE2 receives the PSCCH of the next slot in the consecutively scheduled slot. This allows UE2 to determine whether or not the PSCCH contains the PI. Therefore, UE2 can determine whether or not the resource is being preempted.

[0490] The PSCCH of the mini-slot to be preempted in the second slot is sent from UE3 to UE4, and this PSCCH does not contain PI. Upon receiving the PSCCH of the mini-slot, UE4 obtains the scheduling information for the PSSCH and becomes able to receive the PSSCH.

[0491] After UE1 receives PI2, UE1 may send a PI to UE2 using PSCCH. By receiving PI2, UE1 can recognize the preempted resource. Therefore, UE1 can send a PI to UE2.

[0492] For example, after UE1 receives PI2, UE1 sends the PI, along with other information, to the PSCCH of the next slot in the consecutively scheduled slots for UE2. The PSCCH of that slot may also contain information indicating which UE sent the PI, such as the UE's identifier. The information contained in the PI may also be included in the PSCCH of that slot. This allows UE2 to recognize which UE sent the PI.

[0493] For the transmission process of preempted resources in UE1 and the reception process in UE2, the methods disclosed in Embodiment 4 may be applied as appropriate. For example, the method disclosed in the example in Figure 26 may be applied as appropriate. Similar effects can be obtained. Similarly, for the processing of data of preempted resources to UE2, the methods disclosed in Embodiment 4 may be applied as appropriate. For example, the method disclosed in the example in Figure 26 may be applied as appropriate. Similar effects can be obtained.

[0494] When preempting a resource, including the PSCCH area of ​​the first slot reserved or scheduled from UE1 to UE2, using a mini-slot, the method disclosed in Embodiment 4 may be applied as appropriate. For example, the method disclosed in the example in Figure 26 may be applied as appropriate. Similar effects can be obtained.

[0495] Other examples of preemption methods in SL communication disclosed in Embodiment 4 may be applied as appropriate. For example, a method of providing resources for PI transmission may be applied as appropriate. In Embodiment 4, UE1 transmits PI to UE2, but in this Modification 1, UE3 transmits PI to UE2. UE3 needs to recognize the PI transmission resource configuration. For this reason, the gNB may notify the UE performing SL communication of the PI transmission resource configuration via SIB. Alternatively, the gNB may determine the PI transmission resource configuration and notify the transmitting UE of the SL communication via RRC signaling. By applying these methods, UE3 can recognize the PI transmission resource configuration.

[0496] Alternatively, UE1 may notify UE3 of the PI transmission resource configuration. For example, UE1 may notify UE3 of the PI transmission resource configuration using RRC signaling and MAC signaling. Or, UE1 may notify the PI transmission resource configuration using PSCCH. Upon receiving PSCCH, UE3 can recognize the PI transmission resource configuration. This allows UE3 to send PI to UE2.

[0497] The example in the aforementioned figure disclosed a case where resource reservations from UE1 to UE2 are performed periodically. The method disclosed in this Modification 1 does not necessarily have to be applied when resource reservations or scheduling from UE1 to UE2 are performed periodically; for example, it may be applied when resource reservations or scheduling from UE1 to UE2 are performed aperiodically. The method disclosed in this Modification 1 may also be applied when resource reservations or scheduling from UE1 to UE2 are performed dynamically. Similar effects can be obtained.

[0498] In SL communication, it is preferable to include service information in PSCCH. In SL communication, the transmitting UE includes service information in PSCCH and transmits it. Alternatively, the transmitting UE may include service information in SCI and transmit it via PSCCH. Alternatively, the transmitting UE may include service information in SCI1 and transmit it via PSCCH. In this way, the UE in SL communication can obtain service information by receiving PSCCH.

[0499] The decision of whether or not preemption is possible should be made by the transmitting UE in the communication to be preempted. The transmitting UE determines whether it is possible to preempt resources reserved or scheduled for communication by other UEs for communication of its own service. Information about the service may be used in this determination.

[0500] The transmitting UE receives PSCCHs of resources reserved or scheduled for communication by other UEs and obtains information about the services. The transmitting UE may also receive PSCCHs of resources prior to the resource to be preempted and obtain information about the services. The transmitting UE compares the service information of other UEs with the service information of its own UE to determine whether preemption is possible. The method for determining whether preemption is possible based on the service information may be the method disclosed in Embodiment 4.

[0501] Alternatively, information regarding whether a service is preemptible may be included as part of the service information. For example, for services requiring the lowest latency characteristics, information indicating that the service is preemptible may be included as part of the service information. A UE configured with information indicating that a service is preemptible will preempt resources reserved or scheduled for communication with other UEs.

[0502] In this way, preemption in SL becomes possible for communication of services that require preemption, such as those that demand lower latency characteristics.

[0503] By using the method disclosed in Modification 1, preemption in SL is possible even when the transmitting UE of the preempted communication and the transmitting UE of the preempting communication are different. As a result, the receiving UE of the preempting communication can receive the data earlier. By implementing preemption in SL communication for services requiring low latency, it is possible to satisfy the low latency requirements for the communication.

[0504] Embodiment 5. Resources for SL communication are configured as a resource pool (hereinafter referred to as SLRP). The SLRP is pre-configured on the UE. Alternatively, the gNB notifies the UE of the SLRP via SIB or RRC signaling.

[0505] Figure 32 shows the case where SLRP is set for the UL carrier of Uu. Resources are shown on a slot-by-slot basis. The shaded hatched area is the resource used for Uu's UL communication, and the horizontal hatched area is the SLRP used for SL communication. The SLRP is set within the range of the BWP (BandWidth Part) set for Uu's UL. The SLRP is set within the range of the SL BWP. In Figure 32, the frequency range of the SLRP and the frequency range of the SL BWP are the same.

[0506] In such cases, preemption between Uu's UL and SL communications is conceivable. However, no disclosure has been made regarding preemption between Uu's UL and SL communications. This document discloses how to handle preemption between Uu's UL and SL communications.

[0507] Do not preempt resources used for Uu's UL communication for SL communication. You may prohibit or not allow preempting resources used for Uu's UL communication for SL communication. Do not preempt resources outside of SLRP for SL communication. You may prohibit or not allow preempting resources outside of SLRP for SL communication.

[0508] Do not preempt resources within the SLRP for Uu's UL communication. You may prohibit or not allow preemption of resources within the SLRP for Uu's UL communication. Do not preempt resources outside of Uu's UL communication resources for Uu's UL communication. You may prohibit or not allow preemption of resources outside of Uu's UL communication resources for Uu's UL communication.

[0509] These settings may be configured for each service, or only one of them may be configured.

[0510] This approach prevents SL communication from using Uu's UL communication resources. Furthermore, Uu communication is no longer performed via SLRP. By separating communication resources for Uu's UL and SL communication, it becomes easier to multiplex Uu's UL and SL communication, even when they are performed on the same carrier. This simplifies communication processing on both the network and terminal sides.

[0511] However, if data requiring low latency characteristics arises in the SL (Service Level), such data may not be able to be transmitted outside of the SLRP (Service Level Relay) and must wait until the SLRP timing. This can result in the inability to meet the low latency requirement. The same applies in reverse. If data requiring low latency characteristics arises in the Uu (User Unit) UL (Urgent Load), such data may not be able to be transmitted in the SLRP and must wait until the Uu UL resource timing. This can result in the inability to meet the low latency requirement. A method to solve these problems is disclosed.

[0512] To address these issues, preemption may be implemented between Uu's UL communication and SL communication. Resources used for Uu's UL communication may be preempted for SL communication. It may be permitted to preempt resources used for Uu's UL communication for SL communication. Resources outside the SLRP may be preempted for SL communication. It may be permitted to preempt resources outside the SLRP for SL communication.

[0513] The UL communication resources for a preempted Uu may be limited to the BWP containing the SLRP. The UL resources for a preempted Uu may also be limited to the same slot as the SLRP.

[0514] Alternatively, a resource pool for SL communication preemption may be provided in the UL resource of the Uu. An SL preemption RP is configured for the SL communication UE. The SL communication receiving UE receives not only the SLRP but also the SL preemption RP using the configured SL preemption RP configuration. The SL communication transmitting UE can transmit not only with the SLRP but also with the SL preemption RP using the configured SL preemption RP configuration.

[0515] Figure 33 shows the case where preemption for SL communication is permitted for Uu's UL resources. Resources are shown on a slot-by-slot basis. The sandy hatched areas represent resources preempted for SL communication. Uu's UL resources are used for this preemption. Resources to be preempted for SL communication are configured within the BWP containing the SLRP.

[0516] In this way, when data requiring low latency characteristics arises in SL, it becomes possible to perform SL communication by preempting the Uu's UL resources for SL communication. In particular, even when there is a long interval until the next SLRP timing, SL communication can be performed without waiting. This makes it possible to achieve low latency characteristics.

[0517] Resources within the SLRP may be preempted for Uu's UL communication. Preemption of resources within the SLRP for Uu's UL communication may be permitted. Resources outside of Uu's UL communication resources may be preempted for Uu's UL communication. Preemption of resources outside of Uu's UL communication resources for Uu's UL communication may be permitted.

[0518] The SL communication resources to be preempted may be limited to the BWP containing the Uu's UL communication resources. The SL communication resources to be preempted may also be limited to the same slot as the Uu's UL communication resources.

[0519] Figure 34 shows the case where preemption is permitted for Uu's UL communication for resources within the SLRP. Resources are shown on a slot-by-slot basis. The hatched areas represent resources preempted for Uu's UL communication. SL communication resources are used for this preemption. Resources to be preempted for Uu's UL communication are configured within the Uu's UL communication BWP.

[0520] In this way, when data requiring low latency characteristics arises in Uu's UL communication, it becomes possible to perform Uu's UL communication by preempting the SL communication resources. In particular, even when there is a long interval until the timing of the next Uu UL communication resource, it becomes possible to perform Uu's UL communication without waiting. It also becomes possible to preempt the SL communication resources when the usage load of Uu's UL communication resources is high. As a result, low latency characteristics can be obtained.

[0521] Embodiment 6. In NR, it is agreed that BWP is used in SL (Non-Patent Literature 29 (Draft Report of 3GPP TSG RAN WG1 #95 v0.2.0 (Spokane, USA, 12th-16h November 2018))). Each resource pool (RP) of SL is (pre-configured) within the range of one SLBWP. Figure 35 shows the case where two SLRPs and SLBWPs are configured within the same carrier. Each SLRP is set within the frequency range of each SLBWP. However, no specific method for configuring SLBWPs has been disclosed. This embodiment 6 discloses a method for configuring SLBWPs.

[0522] SLBWP is separate from Uu's UL's BWP. SLBWP is configured separately from the BWP set in Uu's UL. This makes it possible to set up SLRP in a different frequency band than Uu's UL's BWP. SL communication becomes possible in a different frequency band than Uu's UL's BWP.

[0523] The frequency range for SLRP settings may also be set to SLBWP. In Uu communication, the BWP setting is used to limit the frequency range that the UE can communicate with. In SL as well, by setting the SLBWP to the frequency range of the SLRP setting, it becomes unnecessary to set the UE's communication frequency range to a wider range than the SLRP frequency range. This simplifies the configuration of UEs performing SL communication.

[0524] If multiple SLRPs are configured within the range of a single SLBWP, the smallest frequency range encompassing the frequency ranges of those multiple SLRPs may be used as the SLBWP. Similarly, the UE's communicable frequency range does not need to be wider than the smallest frequency range encompassing the frequency ranges of the configured multiple SLRPs. This simplifies the configuration of UEs performing SL communication.

[0525] This document discloses the method for notifying the UE of SLBWP. The SLRP and SLBWP settings for the UE may be configured separately. As mentioned above, the SLRP is pre-configured on the UE. Alternatively, the gNB notifies the UE of the SLRP configuration via SIB or RRC signaling. Similarly, the SLBWP is pre-configured on the UE. Alternatively, the gNB notifies the UE of the SLBWP configuration via SIB or RRC signaling. The SLBWP configuration may also be included in the BWP configuration of the Uu's UL. If the SLRP and SLBWP are configured separately on the UE, it is necessary to associate which SLRP corresponds to which SLBWP.

[0526] A dedicated SLRP identifier should be established to identify the SLRP. It is advisable to include this SLRP identifier in the information used to configure the SLBWP. The SLRP identifier of the SLRP corresponding to the SLBWP being configured should be included in the information used to configure that SLBWP. This allows the UE to recognize the correspondence between the SLRP and the SLBWP. Furthermore, it becomes possible to flexibly modify the settings of the SLRP and SLBWP individually. This also reduces the amount of information required in the SIB or RRC signaling for these modifications.

[0527] The SLBWP settings for the UE may be included in the SLRP settings. For example, the SLBWP settings can be included in the SLRP settings by associating the information for SLBWP settings with the SLRP being configured. This reduces the amount of signaling that needs to be configured for the UE.

[0528] Numerical information may be included as part of the SLBWP configuration information. The UE will then be able to recognize the numerology of the SLBWP resources. The numerology of the SLRP should be the same as the numerology of the corresponding SLBWP. The UE will then be able to recognize the numerology of the SLRP as well.

[0529] The UE may notify the gNB of the frequency range in which its UE can communicate via SL. The UE may include information about this frequency range in its capabilities. The UE may also notify the gNB of its UE capabilities. The gNB uses the information about the UE's SL-communication frequency range to configure the UE's SLBWP. The gNB notifies the UE of the SLBWP configuration. In this way, the UE does not have to communicate in a frequency range that exceeds its capabilities. This reduces the occurrence of malfunctions and communication interruptions at the UE.

[0530] A UE may notify the transmitting UE in SL communication of information regarding its own UE's SL communication frequency range. The UE's capability information may include information regarding the frequency range. UE capabilities may be notified between UEs in SL communication. The transmitting UE uses the information regarding the receiving UE's SL communication frequency range to configure the SLBWP. For example, the transmitting UE may configure other SLBWPs on the PSCCH. The transmitting UE may also notify other SLBWPs and SLRP configurations. In this way, the transmitting UE does not have to communicate in a frequency range that exceeds the receiving UE's capabilities. This reduces the occurrence of malfunctions and communication interruptions between UEs.

[0531] UEs performing SL communication may be configured to enable communication within a pre-configured frequency range. This pre-configured frequency range may be set as the default SLBWP. Unless a BWP is configured for each UE, the default SLBWP may be set. SLRP is set within the frequency range of the default SLBWP. This allows signaling to UEs to be omitted when individual UE configuration is not required. Furthermore, the default SLBWP can be used even if the UE is located outside the cell's coverage and cannot receive the SLBWP from the gNB.

[0532] You may configure an SLBWP for each service. The SLRP will be configured within the frequency range of the SLBWP for each service. Alternatively, you may configure an SLBWP for each QCI. The SLRP will be configured within the frequency range of the SLBWP for each QCI. You may also use the QoS metric used in SL instead of QCI. The SLBWP can be the default SLBWP or an SLBWP configured individually for each UE. This allows for the configuration of an appropriate SLRP for each service.

[0533] By using the SLBWP setting method disclosed in Embodiment 6, the UE can recognize the SLBWP setting, enabling BWP operation in SL communication. The UE only needs to be able to communicate within the SLBWP range in SL communication. Furthermore, the gNB can set the SLBWP according to the UE's SL communication capability, enabling SLRP setting within the SLBWP range.

[0534] Embodiment 7. In NR, the operation of SUL (Supplementary Uplink) in Uu is supported (Non-Patent Document 16 (TS38.300)). In Uu, SUL is configured per cell, and non-SUL and SUL are configured in the same cell. In addition, gNB can dynamically configure SUL for UE using PDCCH. Dynamic SUL configuration is performed per slot for each UE.

[0535] SUL (Sub-Ultraviolet Limit) is provided in SL (Single-Language) communication. SL communication may also be performed using SUL. When the communication quality of SL communication performed using normal UL (i.e., non-SUL) deteriorates, using SUL can improve communication quality.

[0536] Figure 36 is a conceptual diagram showing that SL supports SUL in addition to non-SUL. In Uu's UL, both non-SUL and SUL are supported. The transmitting UE can transmit to the gNB using SUL as well as non-SUL. In SL communication, SUL is also supported in addition to non-SUL. In SL communication, the transmitting UE can transmit to the receiving UE using SUL as well as non-SUL.

[0537] The SUL for SL can be the same as the SUL set in Uu. This eliminates the need to set up a separate SUL for SL, and the UE does not need to communicate using multiple SULs. Therefore, processing in the UE can be simplified.

[0538] The SUL for SL may be different from the SUL set for Uu. Alternatively, an SUL can be set for SL, and SL communication can be performed using that SUL. This allows for a separate SUL for SL, independent of the SUL for Uu. This enables flexible configuration of the SUL for SL. For example, it becomes possible to set the SUL according to the communication quality of SL communication. This can improve the communication quality of SL communication.

[0539] The SLRP configuration in SUL may be the same as the SLRP configuration in non-SUL. This allows for, for example, the same resource allocation for SL communication in both SUL and non-SUL environments.

[0540] The SLRP configuration in SUL may differ from the SLRP configuration in non-SUL environments. This allows the SLRP configuration in SUL to be set up to suit the communication load in SUL.

[0541] The numerology may be the same for SUL and non-SUL. This allows, for example, the timing of SLRP to be the same. Alternatively, the numerology may be different for SUL and non-SUL. This allows for numerology suitable for each carrier frequency of SUL and non-SUL.

[0542] The time domain configuration of SLRP in SUL may be the same as that of SLRP in non-SUL. SLRP settings may be made on a symbolic or 1 / n symbolic basis. This allows the time domain configuration to be the same even when the numerology differs.

[0543] By making the time domain configuration the same, this becomes effective, for example, when a transmitting UE schedules a PSSCH on SUL using a PSCCH on a non-SUL, as will be discussed later. Because the time domain configuration of the SLRP on a non-SUL and the SLRP on SUL are the same, the time domain scheduling information for the PSSCH on a non-SUL and the time domain scheduling information for the PSSCH on SUL can be made the same. This simplifies scheduling control using the SLRP on SUL.

[0544] The time-domain configuration of SLRP in SUL may be different from that of SLRP in non-SUL. By differentiating the time-domain configuration, the timing of non-SUL transmission and SUL transmission at the transmitting UE will be different. Therefore, the UE does not need to distribute the available transmit power between non-SUL transmission and SUL transmission, making it possible to improve the reception quality on each link. In addition, the receiving UE does not need to receive non-SUL SLRP and SUL SLRP simultaneously. Therefore, the reception processing at the receiving UE can be simplified.

[0545] Figure 37 shows the case where the numerology is the same for non-SUL and SUL. In the example in Figure 37, the SLRP configuration for non-SUL and the SLRP configuration for SUL are the same. However, since the frequencies are different for non-SUL and SUL, the frequency of the SLRP for non-SUL and the frequency of the SLRP for SUL are different. Figure 37 shows the case where SLRP is set for the UL carrier of Uu. Resources are shown on a slot-by-slot basis. The shaded hatched area is the resource used for Uu's UL communication, and the horizontal hatched area is the SLRP used for SL communication. For both non-SUL and SUL, SLRP is set within the range of BWP set for Uu's UL. SLRP is set within the range of SL BWP. In Figure 37, the frequency range of SLRP and the frequency range of SL BWP are the same.

[0546] Figure 38 shows the case where the numerology differs between non-SUL and SUL. In the example in Figure 38, the time domain configuration of the SLRP is the same for both non-SUL and SUL. Resources are shown in slot units. The symbol spacing for SUL is set to half the symbol spacing for non-SUL. The subcarrier spacing (SCS (SubCarrier Spacing)) for SUL is twice the subcarrier spacing for non-SUL. The SLRP settings are made in units of half the symbol in the SUL numerology. In this way, even if the numerology differs between non-SUL and SUL, the time domain configuration of the SLRP can be made the same.

[0547] This document discloses how to configure SULs in SL (hereinafter sometimes referred to as SL SULs). SULs may be pre-configured in the UE. Alternatively, the gNB may notify the UE of the SUL configuration via SIB or RRC signaling. This document also discloses how to configure SLRPs to be set up in SULs in SL. One or more SLRPs may be configured in a single SUL. One SLRP configuration may be configured in one or more SULs. SULs and the SLRPs configured in those SULs may be configured in association. The SLRP configuration in a SUL may be pre-configured in the UE. Alternatively, the gNB may notify the UE of the SLRP configuration in a SUL via SIB or RRC signaling.

[0548] The configuration of the SUL and the configuration of the SLRP on the SUL may be performed separately. In such cases, information to identify the SUL may be provided. This information may be an identifier for the SUL, or it may be a carrier identifier for the SUL. It is advisable to include information to identify the associated SUL as part of the information for configuring the SLRP on the SUL. In this way, even if the configuration of the SUL and the configuration of the SLRP on the SUL are performed separately, the UE can recognize which SUL and which SLRP configuration to set.

[0549] Information may be provided to identify the SLRP. This information may be an identifier for the SLRP. It is advisable to include information to identify the associated SLRP as part of the information for configuring the SUL. In this way, even if the SUL configuration and the SLRP configuration within the SUL are performed separately, the UE can recognize which SUL is configured with which SLRP configuration.

[0550] Unlike Uu communication, SL communication takes place both inside and outside cell coverage. SULs in SL do not need to be set for each cell. For example, the same SUL may be set within a Tracking Area (TA). UEs in the RRC_Idle state can use this SUL when performing SL communication. The same SUL may also be set within an RNA (RAN-based Notification Area). UEs in the RRC_inactive state can use this SUL when performing SL communication.

[0551] The SUL for SL can be set on a per-cell basis. When a UE in the RRC_Connected state performs SL communication, it can use the SUL. The SUL for SL can be the same as the SUL for Uu. This makes it possible to perform SL communication on the same carrier frequency as non-SUL and SUL for Uu. This simplifies the SL communication processing on the UE.

[0552] This document discloses the scheduling method for SL SUL. It also discloses the case where the gNB performs scheduling. Information indicating whether or not it is SL SUL is provided. The gNB includes information indicating whether or not it is SUL in the DCI and notifies the transmitting UE in SL communication. The gNB may also include the identifier of SL SUL in the DCI and notify the transmitting UE. The gNB may also include scheduling information in the DCI and notify the transmitting UE. The transmitting UE in SL communication can use this information to select a resource for SL communication in SL SUL. The transmitting UE transmits PSCCH and PSSCH for SL communication using that resource.

[0553] The UE is equipped with transmission and / or reception capabilities (hereinafter sometimes referred to as transmission / reception capabilities) for SL SUL. The UE may notify the gNB of information regarding SL SUL. Information regarding SL SUL may include information regarding transmission and reception capabilities for SL SUL. Information regarding transmission and reception capabilities for SL SUL may include the carrier frequency, bandwidth, numerology, and MIMO multiplexing number that can be transmitted and / or received as SL SUL.

[0554] The UE's capabilities may include information about SL SUL. The UE may notify the gNB of its capabilities. The gNB uses the UE's SL SUL information to configure the UE's SL SUL. The gNB notifies the UE of the SL SUL configuration. In this way, the UE does not have to communicate using an SL SUL that exceeds its capabilities. This reduces the occurrence of malfunctions and communication interruptions at the UE.

[0555] A UE may notify the transmitting UE in SL communication of information about its own UE's SL SUL. The UE's capability information may include information about the SL SUL. UE capabilities may be notified between UEs in SL communication. The transmitting UE uses the receiving UE's information about the SL SUL to configure the SL SUL. For example, the transmitting UE may configure the SL SUL using PSCCH. The transmitting UE may also notify the SL SUL and the SLRP configuration on that SUL. In this way, the transmitting UE does not have to communicate with an SL SUL that exceeds the receiving UE's capabilities. This reduces the occurrence of malfunctions and communication interruptions between UEs.

[0556] When an UE with an SLRP configured on an SL SUL receives SL communication, it searches for the SLRP on the SL SUL. Alternatively, the UE may receive the PSCCH of the SLRP on the SL SUL. The UE activates the SLRP search upon receiving notification of the SLRP configuration on the SL SUL. The UE deactivates the SLRP search upon receiving notification of the SLRP release configuration on the SL SUL.

[0557] Information indicating the activation or deactivation (act / deact) of the SL SUL may be provided. Upon receiving the act / deact information of the SL SUL, the UE activates or deactivates the SLRP search on the SL SUL. The gNB may notify the receiving UE of the act / deact information of the SL SUL via RRC signaling.

[0558] The use of SL SUL act / deact information may be limited to cases where unicast or groupcast communication is performed on the SL. Unlike broadcast communication, the receiving UE is identified in unicast or groupcast communication on the SL. Therefore, SL SUL act / deact information can be notified to the receiving UE via RRC signaling. In the case of broadcast communication, act / deact information may be notified as common information via SIB or RRC signaling. This is effective when the receiving UE cannot be identified.

[0559] In this way, by providing act / deact information for the SL SUL and notifying the receiving UE, the UE does not need to continuously search for the SLRP on the SL SUL from the time the SLRP is configured until the configuration is released. The UE only needs to search for the SLRP on the SL SUL from the time it receives the act information until it receives the deact information. This reduces the power consumption of the UE.

[0560] Figures 39 and 40 show an example sequence for performing SL communication on an SL SUL. Figures 39 and 40 are connected at the boundary line BL3940. Figures 39 and 40 show the case where the gNB configures SL SUL and SLRP. Figures 39 and 40 also show the transmitting UE and receiving UE that perform SL communication with the gNB. In step ST5701, the gNB configures SL SUL. In step ST5702, the gNB configures SLRP for non-SUL (nSUL) and SUL, respectively. In steps ST5703 and ST5704, the gNB notifies the UEs of the SUL configuration, the SLRP configuration for non-SUL, and the SLRP configuration for SUL. For example, the gNB broadcasts these configurations in the SIB. Both the transmitting UE and receiving UE performing SL communication can receive this information.

[0561] In step ST5706, the UE receiving the SL communication receives the PSCCH in the SLRP outside of SUL and begins searching for a PSCCH for its own UE. In the examples in Figures 39 and 40, the receiving UE does not begin searching for a PSCCH in the SLRP outside of SUL. In step ST5705, the transmitting UE in the SL communication sends a Scheduling Request (SR) to the gNB to perform unicast communication outside of SUL. Along with the SR, or as part of the SR information, the UE may notify, for example, the identifier of the UE on the other end of the communication (receiving UE), the BSR of the SL communication, and information about the service to be communicated over the SL. The service information may include QoS information, QCI, PPPP, the requested delay time, the requested slew rate, etc.

[0562] SRs and this information are notified from the transmitting UE to the gNB using the Uu's UL. SRs and this information may also be notified from the transmitting UE to the gNB using PUCCH. This allows for earlier notification. Alternatively, MAC signaling or RRC signaling may be used. Since HARQ is supported in MAC signaling and RRC signaling, notification can be performed with a low error rate.

[0563] In step ST5707, the gNB determines the scheduling for non-SUL SL communication. In step ST5708, the gNB notifies the transmitting UE of the scheduling information for non-SUL SL communication. In step ST5709, the transmitting UE performs the transmission process using the received scheduling information. In step ST5710, the transmitting UE transmits SL using the scheduling information received from the gNB to the receiving UE. The transmitting UE transmits PSCCH and PSSCH.

[0564] The transmitting UE may include the identifier of the receiving UE performing SL communication in the PSCCH. In this way, the receiving UE that is searching for the PSCCH in step ST5706 can receive the PSCCH from the transmitting UE and determine that the PSCCH is intended for its own UE. The receiving UE that has received the PSCCH from the transmitting UE uses the scheduling information of the PSSCH contained in the PSCCH to receive the PSSCH. This allows the receiving UE to receive data from the transmitting UE.

[0565] The receiving UE may send a notification to the transmitting UE indicating whether the data was received or not. The receiving UE may also send the notification as HARQ feedback information (Ack / Nack). The receiving UE may also send channel status information (CSI) to the transmitting UE. The receiving UE may also send SRS to the transmitting UE. The receiving UE may also perform measurements and send the measurement results to the transmitting UE. As a measurement, the receiving UE may measure the RSRP and RSRQ of the RS received from the transmitting UE. Alternatively, the receiving UE may measure the RSRP and RSRQ of one or more PRBs or subchannel RSs, not limited to the RSRP and RSRQ of the RS received from the transmitting UE. The receiving UE sends the measurement results to the transmitting UE.

[0566] In step ST5711, the transmitting UE performs measurements of SL communication over a non-SUL (Single-Layered Unlimited) network. The transmitting UE uses the channel or signal transmitted from the receiving UE to measure the communication quality. Alternatively, the transmitting UE may use the measurement results transmitted from the receiving UE instead of the measurement. In this way, the transmitting UE can obtain measurement information for SL communication over a non-SUL network. Furthermore, the transmitting UE can recognize the communication quality of SL communication over a non-SUL network.

[0567] In step ST5712, the transmitting UE transmits measurement information for non-SUL SL communication to the gNB. In step ST5713, the gNB uses the measurement information received from the transmitting UE to decide whether or not to use SUL for SL communication. A predetermined threshold may be set for communication quality. For example, if the communication quality falls below this threshold, the gNB may decide to use SUL for SL communication.

[0568] The gNB may notify the transmitting UE of a predetermined threshold in advance. The transmitting UE decides whether or not to use SUL for SL communication based on the measurement results obtained in step ST5711. If the communication quality falls below the threshold, the transmitting UE may determine that SUL is necessary for SL communication and request the gNB to use SUL for SL communication in step ST5712. In step ST5713, the gNB may decide to use SUL for SL communication in response to the request from the transmitting UE.

[0569] In steps ST5714 and ST5715, the gNB notifies the act information of the SL SUL. The gNB may also notify the act information of the SLRP on the SL SUL. The SL SUL is activated by the notification of the act information of the SLRP on the SL SUL. In the examples in Figures 39 and 40, the gNB notifies the transmitting UE and receiving UE of the act information of the SLRP on the SUL via RRC signaling. The transmitting UE and receiving UE may also notify the gNB that they have received the act information of the SLRP on the SUL. RRC signaling may be used for this notification. Having received the act information of the SLRP on the SUL, the receiving UE uses the SLRP setting on the SUL received in step ST5704 to start searching for the PSCCH of the SLRP on the SUL in step ST5716.

[0570] In step ST5717, the gNB performs scheduling for SL communication on SUL, and in step ST5718, it notifies the transmitting UE of the SL scheduling information on SUL. In step ST5719, the transmitting UE performs the transmission process. In step ST5720, the transmitting UE transmits on SUL using the scheduling information received from the gNB to the receiving UE. The transmitting UE transmits PSCCH and PSSCH.

[0571] The transmitting UE may include the identifier of the receiving UE performing SL communication in the PSCCH. In this way, the receiving UE that is searching for the PSCCH in step ST5716 can receive the PSCCH from the transmitting UE and determine that the PSCCH is intended for its own UE. The receiving UE that has received the PSCCH from the transmitting UE uses the scheduling information of the PSSCH contained in the PSCCH to receive the PSSCH. This allows the receiving UE to receive data from the transmitting UE.

[0572] The receiving UE may apply the method disclosed for step ST5710 to the communication on the SUL. The receiving UE may send feedback information to the transmitting UE indicating whether the data was received or not. The receiving UE may send the data reception status as HARQ feedback information (Ack / Nack). The receiving UE may also send channel status information (CSI) to the transmitting UE. The receiving UE may also send SRS to the transmitting UE. The receiving UE may also perform measurements and send the measurement results to the transmitting UE. As measurements, the receiving UE may measure the RSRP and RSRQ of the RS received from the transmitting UE. Alternatively, the receiving UE may measure the RSRP and RSRQ of one or more PRBs or subchannel RSs, not limited to the RSRP and RSRQ of the RS from the transmitting UE. The receiving UE sends the measurement results to the transmitting UE.

[0573] In step ST5721, the transmitting UE measures the SL communication on the SUL. The transmitting UE measures the communication quality using the channel or signal transmitted from the receiving UE. Alternatively, the transmitting UE may use the measurement results transmitted from the receiving UE instead of the measurement. In this way, the transmitting UE can obtain measurement information for the SL communication on the SUL. Furthermore, the transmitting UE can recognize the communication quality for the SL communication on the SUL.

[0574] In step ST5722, the transmitting UE transmits measurement information for SL communication using SUL to the gNB. The gNB uses the measurement information received from the transmitting UE to decide whether or not to use non-SUL for SL communication. A predetermined threshold may be set for communication quality. For example, if the communication quality falls below this threshold, the gNB may decide to use non-SUL for SL communication.

[0575] This enables SL communication over SUL.

[0576] The same applies to the deactivation of the SUL. For example, in step ST5722, the gNB, having received measurement information for the SUL's SL communication, decides whether or not to terminate the use of the SUL for SL communication. For example, if the communication quality of the SL communication on the SUL falls below a predetermined threshold, the gNB may terminate the use of the SUL for SL communication. The gNB, having decided to terminate the use of the SUL for SL communication on the SUL, notifies the transmitting UE and receiving UE of the deact information for the SLRP on the SUL. This deact information may be notified via RRC signaling. The transmitting UE and receiving UE may also notify the gNB that they have finished receiving the deact information for the SLRP on the SUL. This completion of reception may also be notified via RRC signaling. The receiving UE, having received the deact information for the SLRP on the SUL, terminates the search for the PSCCH for the SLRP on the SUL.

[0577] This allows for SUL configuration on the SL, and enables activation and deactivation of SUL. Therefore, the receiving UE only needs to search for the SLRP on the SL SUL from the reception of SL SUL's act information to the reception of deactivation information. This reduces the power consumption of the UE.

[0578] In the examples in Figures 39 and 40, the transmitting UE and receiving UE do not terminate SL communication in the non-SUL even after receiving SLRP activation in the SUL. The transmitting UE and receiving UE may perform SL communication between the non-SUL and SUL. Furthermore, activation and deactivation information for non-SUL use in SL may also be provided in the non-SUL. By using the same method as for notifying act / deact information in SUL, it becomes possible to perform activation and deactivation for non-SUL use in SL even in the non-SUL.

[0579] Step ST5710 discloses that the receiving UE measures SL communication in a non-SUL environment and transmits the measurement results to the transmitting UE. Step ST5720 also discloses that the receiving UE measures SL communication in a SUL environment and transmits the measurement results to the transmitting UE. The measurement does not have to be limited to either non-SUL or SUL. The receiving UE may perform measurements in both non-SUL and SUL environments. The measurement results for both non-SUL and SUL environments may be transmitted on the UL where the transmitting UE is communicating with SL.

[0580] The gNB may use the non-SUL and SUL measurement results at the receiving or transmitting UE to decide whether to perform SL communication in a non-SUL environment or in a SUL environment. For example, if the SL communication quality in a non-SUL environment is better than the SL communication quality in a SUL environment, SL communication may be performed in a non-SUL environment, and if the SL communication quality in a SUL environment is better than the SL communication quality in a non-SUL environment, SL communication may be performed in a SUL environment. This allows for SL communication with better communication quality.

[0581] Regarding the use of non-SUL in SL, upon receiving SLRP activation on SUL, the transmitting and receiving UEs may terminate non-SUL transmission and reception. Conversely, upon receiving SLRP deactivation on SUL, the transmitting and receiving UEs may begin non-SUL transmission and reception. This allows SL communication using either non-SUL or SUL UL. UEs do not need to use both non-SUL and SUL for SL communication. The receiving UE only needs to search for either non-SUL or SUL PSCCH. Power consumption of the receiving UE can be reduced.

[0582] Figures 41 and 42 show an example sequence for performing SL communication on SL SUL. Figures 41 and 42 are connected at the boundary line BL4142. In Figures 41 and 42, steps common to Figures 39 and 40 are given the same step numbers, and common explanations are omitted. The examples in Figures 41 and 42 differ from the examples in Figures 39 and 40 in the method of notifying SLRP act information on SUL. In the examples in Figures 41 and 42, in step ST5801, the gNB sends SLRP act information on SUL to the transmitting UE. The gNB includes the SLRP act information on SUL in the DCI and notifies it via PDCCH. The transmitting UE, having received this SLRP act information on SUL, sends the same SLRP act information on SUL to the receiving UE in step ST5802. The transmitting UE includes the SLRP act information in the SCI and notifies it via PSCCH, which is transmitted outside of SUL.

[0583] Since the receiving UE is receiving the PSCCH from the transmitting UE in a non-SUL state, it is able to receive the act information of the SLRP in SUL contained in the PSCCH. Upon receiving the act information of the SLRP in SUL, the receiving UE can start searching for the PSCCH of the SLRP in SUL in step ST5716.

[0584] This allows for early activation / deactivation of the SL SUL. It enables dynamic SL communication on the SL SUL. As a result, power consumption of the UE can be further reduced.

[0585] In the examples in Figures 41 and 42, the transmitting UE notified the receiving UE of the SL SUL activation / deactivation. As another example, the gNB could notify the receiving UE of the SLRP act / deactivation information via PDCCH, including it in the DCI. A similar effect can be achieved.

[0586] In the examples shown in Figures 39 and 40, and in Figures 41 and 42, scheduling from the transmitting UE to the receiving UE in SL communication on the SUL was performed using the SUL's PSCCH. Other examples are disclosed.

[0587] In SL communication, scheduling on the SUL from the transmitting UE to the receiving UE may be performed using a non-SUL PSCCH. In SL communication, the transmitting UE may perform scheduling on the SUL PSSCH for the receiving UE using a non-SUL PSCCH. The receiving UE receives a non-SUL PSCCH and, if scheduling on the SUL PSSCH has been performed, receives the SUL PSSCH according to that scheduling.

[0588] Information may be provided indicating whether to perform non-SUL or SUL scheduling. If SL communication is performed with one or more non-SUL and one or more SUL, information may be provided indicating which non-SUL or SUL scheduling will be performed. Alternatively, information indicating that scheduling will be performed with SUL may be provided. This information may be included in the SCI. This information may be included in the SCI and mapped to the PSCCH.

[0589] If the numerology differs between non-SUL and SUL systems, a conversion may be performed according to the symbol duration or SCS ratio of each numerology in order to derive the scheduling information for SUL systems from the scheduling information for non-SUL systems.

[0590] This configuration allows the transmitting UE to transmit PSCCH only on non-SUL (Surface Unknown) surfaces, simplifying the PSCCH transmission process. Furthermore, the receiving UE only needs to search for and receive PSCCH on non-SUL surfaces. This simplifies the receiving UE's PSCCH reception process and reduces power consumption.

[0591] Information indicating whether to perform non-SUL or SUL scheduling may be used along with the act / deact information of the SL SUL. The transmitting UE notifies the receiving UE via a non-SUL PSCCH, including the act information of the SL SUL and the scheduling information of the PSSCH on the SUL in the SCI. By receiving the PSCCH on the non-SUL, the receiving UE can recognize that the SL SUL has been activated and that a PSSCH has been scheduled on that SUL. The receiving UE can then receive the PSSCH on the SUL at an earlier stage.

[0592] The transmitting UE notifies the receiving UE via a PSCCH on the non-SUL, including the deactivation information for the SL SUL and the scheduling information for the PSCCH on the non-SUL in the SCI. Alternatively, if information indicating that scheduling will be performed on the SUL is provided, this information is not notified. By receiving the PSCCH on the non-SUL, the receiving UE can recognize that the SL SUL has been deactivated and that the PSCCH has been scheduled on the non-SUL. The receiving UE can receive the PSCCH on the non-SUL at an early stage.

[0593] Information indicating whether to perform non-SUL or SUL scheduling may also indicate SL SUL activation / deactivation. If scheduling on SUL is indicated, SUL may be activated. Alternatively, if scheduling on non-SUL is indicated, SUL may be deactivated. By sending and receiving information indicating whether to perform non-SUL or SUL scheduling for each scheduling, SL SUL activation / deactivation can be performed.

[0594] In SL communication, scheduling on the SUL from the transmitting UE to the receiving UE is disclosed to be performed using a non-SUL PSCCH. Alternatively, scheduling on the non-SUL from the transmitting UE to the receiving UE may be performed using a SUL PSCCH. The aforementioned method may be applied as appropriate.

[0595] In SL communication, either a non-SUL or SUL link may be set as the primary link, and the transmitting UE and receiving UE may send and receive PSCCH for SL communication on the primary link. The primary link may be set together with the SL SUL setting. Alternatively, the primary link may be set together with the SL SUL activation / deactivation setting.

[0596] This approach simplifies the transmission process, as the transmitting UE only needs to transmit PSCCH on either the non-SUL or SUL link. The receiving UE only needs to search for and receive PSCCH on the non-SUL link. This simplifies the receiving UE's PSCCH reception process and reduces power consumption. Furthermore, the primary link can be changed according to communication quality, range, and load, leading to improved communication quality, increased resource utilization efficiency, and reduced SL communication delay due to reduced resource conflicts with other UEs.

[0597] The switching between non-SUL and SUL in Uu's UL and the switching between non-SUL and SUL in SL may be linked. For example, if the transmitting UE is set to SUL in Uu's UL by gNB, SL SUL will also be set in SL communication. In this way, for example, if the frequency band for Uu's UL SUL and the frequency band for SL's SUL are set to the same, Uu's UL can determine whether it is better to use that frequency band or not.

[0598] Examples in Figures 39 and 40, and Figures 41 and 42, disclose that HARQ feedback for data transmission on the SUL is transmitted on the SUL. When a single slot contains symbols from a transmitting UE to a receiving UE and symbols from a receiving UE to a transmitting UE, the HARQ feedback may be transmitted using the symbols from the receiving UE to the transmitting UE of a resource reserved on the SUL for SL communication. The transmitting UE receives the HARQ feedback from the receiving UE for data transmission on the SUL on the SUL.

[0599] Scheduling information for HARQ feedback transmission at the receiving UE may be included in the SCI and mapped to the PSCCH. For example, this scheduling information may be the time interval from PSCCH transmission to HARQ feedback transmission. The time unit may be, for example, a slot, minislot, subframe, symbol, TTI, etc.

[0600] By transmitting PSSCH and HARQ feedback on the same SUL, scheduling of HARQ feedback for PSSCH, particularly time-domain scheduling, becomes easier. This simplifies scheduling control for the transmitting UE and streamlines processing from PSSCH to HARQ feedback at the receiving UE.

[0601] Another example of how HARQ feedback can be sent is sending HARQ feedback for data transmissions on SUL from a non-SUL. HARQ feedback can be sent using symbols from the receiving UE to the transmitting UE for resources reserved on a non-SUL for SL communication. The transmitting UE then receives the HARQ feedback from the receiving UE for data transmissions on SUL on a non-SUL.

[0602] This allows the control channel between the transmitting and receiving UEs to be transmitted and received over a non-SUL (Single-Labeled Union) network. Only data transmission and reception can be performed using the SUL. This makes it possible to offload data onto the SUL, reducing the communication load on non-SUL networks.

[0603] As another example, HARQ feedback for data transmission on a non-SUL (Surface-Ultrasound) surface could be sent on a SUL surface. A similar effect can be achieved.

[0604] It may be possible to configure whether HARQ feedback is sent non-SUL or SUL. Information indicating whether HARQ feedback is sent non-SUL or SUL may be provided. The transmitting UE may include this information in the SCI, map it to the PSCCH, and notify the receiving UE. This information may be notified together with the PSSCH scheduling information. Alternatively, this information may be included in the scheduling information for sending HARQ feedback.

[0605] By doing so, it becomes possible to change the link to which HARQ feedback is sent according to communication quality, communication range, communication load, etc., thereby improving communication quality, improving resource utilization efficiency, and reducing SL communication latency by reducing resource conflicts with other UEs.

[0606] As a method of notifying the receiving UE of whether to transmit HARQ feedback in non-SUL or SUL mode, PC5 control signaling may be used from the transmitting UE to the receiving UE. Alternatively, RRC signaling may be used. Or, MAC signaling may be used. This can reduce the reception error rate.

[0607] The gNB may decide whether to transmit the HARQ feedback in non-SUL or SUL mode. The gNB notifies the transmitting UE of this information in the DCI via the PDCCH. Alternatively, RRC signaling or MAC signaling may be used to notify the UE of this information. This can reduce the reception error rate. The transmitting UE that receives this information may notify the receiving UE in SL communication of this information using the method described above.

[0608] The gNB may notify the receiving UE of this information. A similar method may be used for notification.

[0609] By having the gNB notify the transmitting UE whether to send HARQ feedback as non-SUL or SUL, it becomes possible to reduce the delay time of SL communication by reducing resource usage conflicts with other UEs.

[0610] Examples in Figures 39 and 40, and Figures 41 and 42, disclose that a gNB performs SL scheduling on the SUL. Another example is disclosed. The transmitting UE in SL communication may perform SL scheduling on the SUL. Resources for SL communication may be selected from within the SLRP on the SUL. The transmitting UE senses available resources from within the SLRP on the SUL, selects resources to be used for SL communication from among the available resources, and reserves them.

[0611] The receiving UE searches for the PSCCH within the SLRP on the SUL when the SLRP on the SUL is configured or activated using the method described above. This allows it to receive the PSCCH from the transmitting UE.

[0612] This allows the transmitting UE to perform SL scheduling on the SUL. Since the transmitting UE can perform SL scheduling on the SUL without waiting for scheduling from the gNB, SL communication can be initiated earlier. SL communication can be performed with low latency.

[0613] A UE performing SL communication may transmit a synchronization signal (SS) at the SL SUL. If the Uu's SUL and the SL SUL are on the same carrier frequency, the UE performing SL communication should synchronize by receiving the SS from the gNB. If the UE performing SL communication is outside the coverage of the gNB, it should synchronize by receiving the SS from a UE transmitting an SS at a nearby SL SUL. The UE performing SL communication should determine whether it is within the coverage of the gNB and whether there is a nearby UE transmitting an SS using received power or received quality.

[0614] For this determination, a predetermined threshold for received power or received quality may be set. For example, if a UE performing SL communication receives received power exceeding the predetermined threshold from a gNB or a UE transmitting SS, it will synchronize with the gNB or the UE transmitting SS. In this way, it is not necessary to synchronize the frame timing between non-SUL and SUL, and synchronization at SUL becomes possible.

[0615] By using the SUL setting method disclosed in Embodiment 7, it becomes possible to use SUL in SL communication. Therefore, even when the communication quality of SL communication performed without SUL deteriorates, it is possible to improve the communication quality by using SUL.

[0616] Embodiment 8. In NR communication via Uu, the handling of RLF (Radio Link Failure) is defined (Non-Patent Literature 16 (TS38.300)). Due to Uu communication, RLF processing is performed when the UE becomes out of sync with the gNB. If the UE cannot resynchronize with the gNB, an RLF occurs, and the UE performs cell reselection and executes RRC re-establishment. If RRC re-establishment is not possible, the UE transitions to RRC_Idle.

[0617] In NR's SL communication, support for unicast and groupcast is being considered. Therefore, RLF processing methods are required even in SL communication. However, SL communication is between UEs, not between UEs and gNBs. For this reason, the conventional RLF processing used for UE-gNB communication cannot be applied without modification.

[0618] A problem arises in how to handle situations where SL communication becomes impossible between the transmitting UE and the receiving UE. For example, how should communication failure be determined, and what should be done if communication failure is determined? If these methods are unclear, the transmitting UE and the receiving UE will be unable to process or coordinate processing, and communication will not be performed normally. This embodiment 8 discloses a method to solve these problems.

[0619] This document discloses a method for determining whether a unicast or groupcast communication is in a synchronized state. The receiving UE determines whether it is in a synchronized state. For determining whether it is in a synchronized state, the PSCCH, not the PDCCH received from the gNB, is used. The receiving UE may determine that it is in a synchronized state (In-Sync) if it has received the PSCCH transmitted from the transmitting UE a predetermined number of times consecutively. The receiving UE may also determine that it is in a synchronized state if it has received the PSCCH continuously for a predetermined time. The receiving UE may also determine that it is in a synchronized state if it has received the PSCCH a predetermined number of times consecutively within a predetermined time.

[0620] A receiving UE may determine that it is out of sync if it fails to receive the PSCCH transmitted from the transmitting UE for a predetermined number of consecutive times. A receiving UE may also determine that it is out of sync if it fails to receive the PSCCH transmitted from the transmitting UE for a predetermined period of time. A receiving UE may also determine that it is out of sync if it fails to receive the PSCCH transmitted from the transmitting UE for a predetermined number of consecutive times within a predetermined period of time.

[0621] Information such as a predetermined number of times or a predetermined time used to determine whether or not a synchronization state is in place may be notified from the gNB to the UE performing SL communication. This information may be included in the broadcast information and broadcast. The predetermined value can be determined for each cell. Alternatively, this information may be notified to each UE individually via RRC signaling. Alternatively, this information may be statically predetermined by a standard or the like. Alternatively, this information may be pre-configured in the UE performing SL communication.

[0622] Information such as the number of times or the time may be set for each service. This information may also be set for each QoS of the service. For example, the predetermined values ​​can be determined according to the delay time required for each service. The notification method from gNB to UE should be the method described above.

[0623] Other methods are disclosed. As a method for determining whether or not a unicast or groupcast communication is synchronized, the Synchronization Signal (SS) (hereinafter referred to as SLSS) at the SL may be used. The receiving UE determines whether or not it is synchronized using the SLSS transmitted from the UE that synchronizes with the SL. The receiving UE may determine that it is synchronized if it has received the SLSS transmitted from the UE that synchronizes with the SL a predetermined number of times consecutively. The receiving UE may determine that it is out of sync if it has not received the SLSS transmitted from the UE that synchronizes with the SL a predetermined number of times consecutively.

[0624] Similar to synchronization in PSCCH, the number of synchronization cycles may be set to a predetermined time, or a predetermined number of cycles within a predetermined time, rather than a predetermined number of cycles.

[0625] In SL (Simulation-Like) communication, the receiving UE (UE) may be different from the transmitting UE (UE) with which it is synchronized. As mentioned above, by deciding whether to use PSCCH or SLSS to determine whether or not synchronization is in progress, the receiving UE in SL communication can clearly determine whether or not it is synchronized. As a result, the occurrence of malfunctions can be reduced.

[0626] A combination of methods using PSCCH and SLSS may be used to determine whether or not the system is synchronized. For example, by combining PSCCH and SLSS, if a predetermined number of consecutive receptions are not possible within a predetermined time, the system may be determined to be out of sync; otherwise, it may be determined to be synchronized. This allows for early detection of out-of-sync conditions, enabling an earlier transition to the next processing step.

[0627] Furthermore, for example, if both PSCCH and SLSS become out of sync, it may be determined that the unicast or groupcast communication is out of sync. If not, it may be determined that the communication is synchronized. If only PSCCH or only SLSS is out of sync, the communication is synchronized. This reduces the situations that lead to a out-of-sync state, and allows the communication state to be maintained as much as possible.

[0628] The process of a UE that has determined it is out of sync is disclosed. The UE performs resynchronization. If the UE determined it was out of sync using PSCCH, it receives PSCCH from the transmitting UE and performs resynchronization. In this way, the receiving UE becomes able to receive PSCCH and PSSCH from the transmitting UE. Unicast communication on SL becomes possible again.

[0629] If a synchronization outage is detected using SLSS, the UE receives the SLSS and performs resynchronization. Receiving the SLSS may be done by receiving the SLSS of the UE that was most recently synchronized. Alternatively, thresholds for the received power or quality of the SLSS for resynchronization may be set, and synchronization may be performed with the SLSS of a UE that exceeds these thresholds.

[0630] The thresholds for SLSS received power and received quality for resynchronization may be the same as the thresholds for SLSS received power and received quality for synchronization. This makes it easier to control the synchronization process. Alternatively, the thresholds for SLSS received power and received quality for resynchronization may be different from those for synchronization. For example, the threshold for resynchronization may be lower than the threshold for synchronization. This makes resynchronization easier and reduces the delay time until communication becomes possible again.

[0631] A receiving UE that has received SLSS and resynchronized will receive PSCCH from the transmitting UE. In this way, the receiving UE will be able to receive both PSCCH and PSSCH from the transmitting UE. Unicast communication via SL will then be possible again.

[0632] When SLSS is used to determine that synchronization has been lost, the PSCCH from the transmitting UE may still be receivable. In such cases, the receiving UE, having received the SLSS and performed resynchronization, may continue to receive the PSCCH from the transmitting UE. In such cases, unicast communication using SL can be continued.

[0633] Depending on how synchronization status is determined, these resynchronization methods may be used in appropriate combinations. This makes it possible to simplify the process of resynchronization and resynchronization.

[0634] If the receiving UE becomes out of sync and is unable to resynchronize, it is appropriate to terminate the SL communication. This indicates that the unicast or groupcast communication in the SL has ended. The receiving UE, having terminated the SL communication, will then perform a new synchronization process for SL communication, search for the SLRP PSCCH, receive the PSCCH from the transmitting UE, and begin the unicast or groupcast communication process. This way, even if the receiving UE becomes out of sync due to deterioration of communication quality in the SL communication, it is possible to start a new SL communication.

[0635] When a receiving UE terminates SL communication, it releases the RRC settings configured for unicast or groupcast communication. It may also release the settings for each protocol used in SL communication. For example, it may release the settings for PDCP, RLC, MAC, and PHY used in SL communication. Alternatively, it may discard data buffered by PDCP, RLC, MAC, and PHY used in SL communication. This reduces the processing load and buffer capacity within the UE.

[0636] Furthermore, if a bearer is configured in SL, the receiving UE, upon termination of SL communication, may release the bearer configuration. Each protocol configured with the bearer set in SL will then be released. A similar effect can be achieved.

[0637] The time elapsed since the start of the out-of-sync state can be managed using a timer. If resynchronization occurs within the timer's timeframe after the out-of-sync state began, the system should return to a synchronized state and the timer should be reset. If resynchronization fails within the timer's timeframe after the out-of-sync state began, the SL communication should be terminated and the timer reset. This approach helps avoid prolonging the resynchronization process.

[0638] If the receiving UE fails to resynchronize after becoming out of sync, it may choose not to release or retain some or all of the RRC settings configured for unicast or groupcast communications. For example, it may choose not to release or retain some or all of the PDCP, RLC, MAC, and PHY settings in SL communications. Alternatively, it may choose not to discard or retain some or all of the data buffered by the PDCP, RLC, MAC, and PHY in SL communications.

[0639] Furthermore, in cases where a bearer is configured in SL, if the receiving UE becomes out of sync and is unable to resynchronize, the receiving UE may choose not to release or to retain some or all of the bearer configuration.

[0640] The transmitting UE may retain some or all of the RRC settings or some or all of the bearer settings configured for unicast or groupcast communication while the receiving UE is holding them. The retention period should be set considering the timer from the start of the out-of-sync state to resynchronization, and the timer from the point at which resynchronization fails until the completion of the synchronization process for SL communication, as described later. If communication with the receiving UE is not resumed after the retention period has elapsed, the transmitting UE releases some or all of the retained RRC settings or some or all of the bearer settings. In this way, even if SL communication is resumed, communication can be resumed quickly by using the retained settings.

[0641] If the receiving UE fails to resynchronize after becoming out of sync, it will retain some or all of these settings, perform a new synchronization process for SL communication, search for the SLRP PSCCH, receive the PSCCH from the transmitting UE, and start unicast or groupcast communication. In this way, even when starting a new SL communication, the retained settings can be used to enable communication quickly.

[0642] If the receiving UE fails to resynchronize after becoming out of sync, it will retain some or all of these settings, perform a new synchronization process for SL communication, search for the SLRP PSCCH, receive the PSCCH from the transmitting UE, and start unicast or groupcast communication. In this way, even when starting a new SL communication, the retained settings can be used to enable communication quickly.

[0643] If the receiving UE fails to resynchronize after becoming out of sync, it may perform a further resynchronization process while retaining some or all of these settings. This further resynchronization process may be the same as the aforementioned resynchronization process performed after the receiving UE became out of sync. In this way, even if SL communication is resumed after resynchronization, communication can be resumed quickly by using the retained settings.

[0644] If synchronization fails after a loss of synchronization, the time elapsed since the failure to resynchronize may be managed by a timer. If a new synchronization process for SL communication is completed within the timer from the point in time when resynchronization failed, the system should return to a synchronized state and the timer should be reset. Alternatively, if a PSCCH signal from the transmitting UE is received within the timer from the point in time when resynchronization failed and the system returns to a synchronized state, the timer should be reset. Alternatively, if a successful resynchronization process is performed within the timer from the point in time when resynchronization failed, the system should return to a synchronized state and the timer should be reset.

[0645] If resynchronization fails after a synchronization out state, the SL communication should be terminated when the timer expires from the point at which resynchronization failed. Terminating the SL communication releases some or all of the RRC settings or some or all of the bearer settings that were being held. This allows for an earlier transition to SL communication termination, eliminating the need to retain some or all of the settings from the aforementioned SL communication for an extended period.

[0646] The aforementioned timers, such as the timer from the start of the out-of-sync state until resynchronization, or the timer from the point at which resynchronization fails until the completion of the synchronization process for SL communication, may be statically determined in advance by a standard or the like. Alternatively, the aforementioned timers may be notified from the transmitting UE to the receiving UE. RRC signaling may be used for this notification. Alternatively, PSCCH or MAC signaling may be used for this notification. Furthermore, the aforementioned timers may be notified from the gNB to the UE. The notification method may be the same as the SLRP notification method described above. Alternatively, the aforementioned timers may be pre-configured in the UE. In this way, the receiving UE can obtain the timer settings.

[0647] These timers may be set separately from the timers used for RLF processing in Uu. The service content, usage conditions, and radio wave propagation environment differ between Uu communication and SL communication. It becomes possible to set values ​​that are appropriate for such differences. For example, the aforementioned timers for SL communication can be made longer than the timers used for RLF processing in Uu. This prevents SL communication from ending too quickly. It also reduces the delay time caused by processes such as resource search, resource selection, and resource reservation to restart SL communication.

[0648] The transmitting UE may determine whether it is synchronized with the receiving UE in unicast or groupcast communication. The determination of whether the transmitting UE is synchronized may be made in conjunction with the determination of whether the receiving UE is synchronized. The determination of whether the transmitting UE is synchronized may be made using signals or channels transmitted from the receiving UE. Examples of signals or channels transmitted from the receiving UE include SRS, HARQ feedback, and CSI reports. Alternatively, PSFCH may be used.

[0649] The method for determining whether the transmitting UE is synchronized or not should be to appropriately apply the method described above for determining whether the receiving UE is synchronized or not.

[0650] The following describes how to handle a loss of synchronization at the transmitting UE. The transmitting UE re-selects a resource. Alternatively, the transmitting UE may change the SLRP. The transmitting UE may change the SLRP and then re-select a resource. This makes it possible to start SL communication using a resource with better communication quality.

[0651] If the transmitting UE remains out of sync for a predetermined period, the SL communication may be terminated. During this predetermined period, the transmitting UE may retain some or all of the RRC settings or some or all of the bearer settings configured for unicast or groupcast communications. When terminating the SL communication, the transmitting UE may release some or all of the RRC settings or some or all of the bearer settings configured for unicast or groupcast communications.

[0652] When the transmitting UE generates data for unicast or groupcast communication, it restarts the unicast or groupcast communication. This allows the transmitting UE to determine whether it is in a synchronized state and to handle situations where SL communication becomes impossible between the transmitting and receiving UEs.

[0653] When unicast or groupcast communication is being performed in SL, the transmitting UE may lose synchronization with the UE it is supposed to be synchronizing with. In such cases, the question arises as to how to handle the unicast or groupcast communication. In such cases, the transmitting UE should apply the method disclosed for the receiving UE, as described above, to determine whether it is synchronized with the UE, to handle the loss of synchronization, to handle the process from the start of the loss of synchronization to resynchronization, and to handle the case where resynchronization fails. Similar effects can be obtained.

[0654] In SL communication, the UE that receives the SLSS and synchronizes may be different from the opposing UE in unicast or groupcast communication. The UE that receives the SLSS and synchronizes may be selected independently of the opposing UE in unicast or groupcast communication. For example, a UE can synchronize with the UE best suited for synchronization, such as the UE with the highest received power. However, in such a case, the receiving UE must receive signals from both the synchronizing UE and the transmitting UE. In such a case, the receiving UE's receiving process becomes complex, and power consu...

Claims

1. A communication terminal in a communication system comprising a plurality of communication terminals capable of communicating with each other in a side link, and a base station that wirelessly communicates with each of the plurality of said communication terminals, The SLBWP, which is the bandwidth portion (BWP) for the side link, is set separately from the ULBWP, which is the bandwidth portion for the uplink. The Sidelink Resource Pool (SLRP), which is a resource pool for the aforementioned sidelink, is configured separately from the SLBWP and is configured within the corresponding SLBWP. The SLRP identifier is included in the SLBWP setting and indicates the SLRP corresponding to the SLBWP. The aforementioned communication terminal, The base station receives configuration information for the SLBWP and SLRP via radio resource control (RRC) signaling. In accordance with the above configuration information, configure the SLRP within the SLBWP. Communication terminal.

2. The aforementioned configuration information includes information regarding the numerology of the SLBWP, Each of the numerology of one or more sidelink resource pools corresponds to the numerology for the SLBWP, The communication terminal according to claim 1.

3. A predetermined range is provided for the aforementioned SLBWP. If the location is outside the coverage area of ​​the aforementioned base station, the aforementioned pre-set range is used. The communication terminal according to claim 1.

4. UE capability information, including information regarding the frequency range in which sidelink communication is possible, is transmitted to the base station. The communication terminal according to claim 1.

5. The UE capability information indicating the capabilities of the aforementioned communication terminal is transmitted and received with other communication terminals. The communication terminal according to claim 1.

6. A base station in a communication system comprising a plurality of communication terminals that can communicate with each other in a side link, and a base station that wirelessly communicates with each of the plurality of said communication terminals, The SLBWP, which is the bandwidth portion (BWP) for the side link, is set separately from the ULBWP, which is the bandwidth portion for the uplink. The Sidelink Resource Pool (SLRP), which is a resource pool for the aforementioned sidelink, is configured separately from the SLBWP and is configured within the corresponding SLBWP. The SLRP identifier is included in the SLBWP setting and indicates the SLRP corresponding to the SLBWP. The base station transmits configuration information for the SLBWP and SLRP via radio resource control (RRC) signaling. Base station.

7. A communication system comprising a plurality of communication terminals that can communicate with each other in a side link, and a base station that wirelessly communicates with each of the plurality of said communication terminals, The SLBWP, which is the bandwidth portion (BWP) for the side link, is set separately from the ULBWP, which is the bandwidth portion for the uplink. The Sidelink Resource Pool (SLRP), which is a resource pool for the aforementioned sidelink, is configured separately from the SLBWP and is configured within the corresponding SLBWP. The SLRP identifier is included in the SLBWP setting and indicates the SLRP corresponding to the SLBWP. The aforementioned communication terminal, The base station receives configuration information for the SLBWP and SLRP via radio resource control (RRC) signaling. In accordance with the above configuration information, configure the SLRP within the SLBWP. Communication system.

Images