Communication systems and communication terminals

Abstract

This invention provides user equipment, base stations, and communication systems that enable the rapid assurance of reliability in multicast communication. [Solution] The communication system comprises a base station compatible with New Radio Access Technology and a communication terminal (UE) capable of multicast communication with the base station. While multicast communication is in progress, the UE transmits reception status information, which is information regarding the data reception status, to the base station during communication. Based on the reception status information, the base station controls the retransmission of data to the communication terminal.

Description

Technical Field

[0001] This disclosure 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. The DCCH is mapped to the UL-SCH in the uplink and to the DL-SCH in the downlink.

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

[0030] The Multicast Traffic Channel (MTCH) is a downlink channel for transmitting traffic data from a network to a communication terminal. The MTCH is a channel used only for 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, LTE-A (Long Term Evolution Advanced) to be described later, and UMTS (Universal Mobile Telecommunication System), a CSG (Closed Subscriber Group) cell is 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 (User Interface Device), which is a communication terminal, has a single RRC connection to the network (NW). In the RRC connection, one serving cell provides NAS mobility information and security input. This cell is called the Primary Cell (PCell). 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 one 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, there is dual connectivity (abbreviated as 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-19). 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 frame configurations, 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 (3GPP TS38.211)).

[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.

[0051] During the duration of the SS burst, the base station transmits SS blocks of each beam, switching between beams. The SS block consists of P-SS, S-SS, and PBCH.

[0052] 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.

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

[0054] 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.

[0055] 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).

[0056] Furthermore, 3GPP is considering supporting services (or applications) using side-link (SL) communication (also known as PC5 communication) in both the Evolved Packet System (EPS) described later and the 5G core system (see Non-Patent Documents 1, 16, 20, 21, 22, and 23). Examples of services using SL communication include V2X (Vehicle-to-everything) services and proximity services.

[0057] Furthermore, 3GPP is considering several new technologies. For example, multicast using NR is being considered. In multicast using NR, for example, a reliable multicast scheme and dynamic switching between point-to-multipoint (PTM) transmission and point-to-point (PTP) transmission are being considered (see Non-Patent Documents 24, 25, and 26). [Prior art documents] [Non-patent literature]

[0058]

Non-licensed literature 1

Non-licensed Document 2

Non-licensed Document 4

Non-licensed Document 5

Non-licensed Document 6

Non-licensed Document 7

Non-licensed Document 8

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

[0059] A PDCP (Packet Data Convergence Protocol) status report may be used when switching between PTM and PTP legs. However, sending a PDCP status report from the UE to the base station requires instructions from the base station. For example, the UE sends a PDCP status report to the base station in response to instructions from the base station such as a DRB (Data Radio Bearer) modification (see Non-Patent Documents 19 and 27). Therefore, for example, if the UE fails to receive some PDCP PDUs (Protocol Data Units) consisting of multicast data, the UE cannot send a PDCP status report to the base station, resulting in the problem that the multicast data loss at the UE is not resolved.

[0060] In light of the above-mentioned issues, one of the objectives of this disclosure is to realize a communication system that can quickly ensure reliability in multicast. [Means for solving the problem]

[0061] The user device relating to this disclosure transmits a PDCP (Packet Data Convergence Protocol) status report to the base station in multicast, and transmits first information regarding the reception status of the multicast to the base station using the PDCP status report. [Effects of the Invention]

[0062] According to this disclosure, it is possible to realize a communication system that can quickly ensure reliability in multicast.

[0063] The purpose, features, aspects, and advantages of this disclosure will become clearer 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 the 5GC section. [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 is a sequence diagram illustrating the switching operation from a PTM leg to a PTP leg and from a PTP leg to a PTM leg in multicast transmission, according to Embodiment 1. [Figure 15]The following is a sequence diagram illustrating another example of the switching operation from a PTM leg to a PTP leg and from a PTP leg to a PTM leg in multicast transmission, according to Embodiment 1. [Figure 16] This is a sequence diagram illustrating the multicast operation in Embodiment 1, where PTM legs and PTP legs are used simultaneously. [Figure 17] This diagram shows the configuration of a PDCP entity and an RLC entity used in multicast using PTM legs and / or PTP legs, as shown in Modification 1 of Embodiment 1. [Figure 18] This figure shows another example of the configuration of PDCP entities and RLC entities used in multicast using PTM legs and / or PTP legs, as shown in Modification 1 of Embodiment 1. [Figure 19] This figure shows another example of the configuration of PDCP entities and RLC entities used in multicast using PTM legs and / or PTP legs, as shown in Modification 1 of Embodiment 1. [Figure 20] This diagram shows the multicast architecture in the DC according to Embodiment 2. [Figure 21] This figure shows another example of a multicast architecture in a DC according to Embodiment 2. [Figure 22] This figure shows another example of a multicast architecture in a DC according to Embodiment 2. [Figure 23] This figure shows another example of a multicast architecture in a DC according to Embodiment 2. [Figure 24] This is a sequence diagram showing the configuration operation of a multicast bearer configuration in a DC for Embodiment 2. [Figure 25] This diagram shows the multicast architecture in a base station with a CU / DU separation configuration, according to Embodiment 3. [Figure 26]This figure shows another example of a multicast architecture in a base station with a CU / DU separation configuration, according to Embodiment 3. [Figure 27] This figure shows another example of a multicast architecture in a base station with a CU / DU separation configuration, according to Embodiment 3. [Figure 28] This is a connection diagram for multicast from base stations constituting the IAB in Embodiment 4. [Figure 29] This is a protocol stack diagram for multicast from base stations constituting the IAB in Embodiment 4. [Figure 30] This figure shows another example of multicast connectivity from base stations constituting the IAB in Embodiment 4. [Modes for carrying out the invention]

[0065] The communication system and communication terminal according to the embodiments of this disclosure will be described in detail below with reference to the drawings.

[0066] 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.

[0067] 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."

[0068] 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.

[0069] 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.

[0070] 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.

[0071] 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."

[0072] The eNB207 is connected to a Mobility Management Entity (MME), or a Serving Gateway (S-GW), or an MME / S-GW unit (hereinafter sometimes referred to as "MME unit") 204 including both an MME and an S-GW, via an S1 interface, 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 them.

[0073] 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.

[0074] 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.

[0075] 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).

[0076] 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.

[0077] 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.

[0078] 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.

[0079] 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.

[0080] The 5GC unit 214 is a higher-level device, specifically a higher-level node, and 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 202 is in the idle state, in the inactive state, and in the 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 mobile terminal 202 is registered.

[0081] 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.

[0082] 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.

[0083] In a 5G communication system, the Unified Data Management (UDM) function and Policy Control Function (PCF) described in Non-Patent Document 21 (3GPP TS23.501) may be included. The UDM and / or PCF may be included in the 5GC unit 214 in Figure 3.

[0084] In a 5G communication system, a Location Management Function (LMF) as described in Non-Patent Document 32 (3GPP TS38.305) may be provided. The LMF may be connected to a base station via an AMF, as disclosed in Non-Patent Document 33 (3GPP TS23.273).

[0085] In a 5G communication system, a Non-3GPP Interworking Function (N3IWF) described in Non-Patent Document 21 (3GPP TS23.501) may be included. In non-3GPP access between the UE and the N3IWF, the Access Network (AN) may be terminated between the UE and the UE.

[0086] 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.

[0087] 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.

[0088] 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.

[0089] 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.

[0090] 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.

[0091] 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. The control unit 310 is realized by a processing circuit that includes, for example, a processor and memory. That is, the control unit 310 is realized by the processor executing a program that describes the series of processes of the mobile terminal 202. A program describing a series of processes for the mobile terminal 202 is stored in memory. Examples of memory include non-volatile or volatile semiconductor memory such as RAM (Random Access Memory), ROM (Read Only Memory), and flash memory. The control unit 310 may be implemented using a dedicated processing circuit such as an FPGA (Field Programmable Gate Array), ASIC (Application Specific Integrated Circuit), or DSP (Digital Signal Processor). 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.

[0092] 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.

[0093] 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.

[0094] 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, and the user data is passed to the 5GC communication unit 412, the EPC communication unit 401, or 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-410 and 412. The control unit 411, like the control unit 310 of the mobile terminal 202 described above, is implemented as a processing circuit that includes a processor and memory, or as a dedicated processing circuit such as an FPGA, ASIC, or DSP. 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.

[0095] 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.

[0096] 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 (Packet Data Network Gateway). 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.

[0097] 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.

[0098] The HeNBGW communication unit 504 transmits and receives data between the MME204a and the HeNB GW (Home-eNB Gateway). The control data received by the HeNBGW communication unit 504 from the HeNB GW is passed to the control plane control unit 505. The HeNBGW communication unit 504 transmits the control data input from the control plane control unit 505 to the HeNB GW.

[0099] 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 referred to as LTE-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.

[0100] 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 202 is in the idle state and when it is in the active state. The MME204a initiates the paging protocol by sending a paging message to cells belonging to the tracking area where the mobile terminal 202 is registered. 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.

[0101] The series of processes of the MME204a are controlled by the control unit 506. Therefore, although the control unit 506 is omitted in Figure 10, it is connected to each of the units 501 to 505. The control unit 506 is implemented as a processing circuit that includes a processor and memory, similar to the control unit 310 of the mobile terminal 202 described above, or as a dedicated processing circuit such as an FPGA, ASIC, or DSP.

[0102] Figure 11 is a block diagram showing the configuration of the 5GC unit. 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.

[0103] 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 communication 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.

[0104] 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.

[0105] The series of processes in the 5GC unit 214 are controlled by the control unit 526. Therefore, although the control unit 526 is omitted in Figure 11, it is connected to each of the units 521-523, 525, and 527. The control unit 526 is implemented as a processing circuit that includes a processor and memory, similar to the control unit 310 of the mobile terminal 202 described above, or as a dedicated processing circuit such as an FPGA, ASIC, or DSP.

[0106] 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.

[0107] 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. The communication terminal uses these 504 PCI combinations to synchronize and also detects (identifies) the PCI of the synchronized cell.

[0108] The communication terminal then detects the cell-specific reference signal (CRS), which is a reference signal (RS) transmitted from the base station to each cell, in step ST602 for the next synchronized cell, and measures the Reference Signal Received Power (RSRP). 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.

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

[0110] Next, in step ST604, the communication terminal receives the PBCH of the best cell and obtains the BCCH, which is broadcast information. 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).

[0111] Next, in step ST605, the communication terminal receives the DL-SCH of the cell based on the cell configuration information of the MIB and obtains SIB (System Information Block) 1 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).

[0112] 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.

[0113] 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).

[0114] 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.

[0115] 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.

[0116] 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.

[0117] 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.

[0118] 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.

[0119] 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."

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

[0121] 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.

[0122] 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.

[0123] 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.

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

[0125] 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.

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

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

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

[0129] The Physical Sidelink Feedback Channel (PSFCH) carries HARQ feedback over the sidelink from the UE that received the PSSCH transmission to the UE that transmitted the PSSCH.

[0130] 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.

[0131] The Sidelink Discovery Channel (SL-DCH) has periodic broadcast transmissions in a fixed size and predetermined format. The SL-DCH 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 resources individually via the eNB. The SL-DCH also supports HARQ combining but not HARQ feedback. The SL-DCH is mapped to the physical channel PSDCH.

[0132] Sidelink shared channels (SL-SCH) support broadcast transmission. SL-SCH 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. SL-SCH also supports HARQ combining but not HARQ feedback. Furthermore, SL-SCH supports dynamic link adaptation by changing transmit power, modulation, and coding. SL-SCH is mapped to the physical channel PSSCH.

[0133] 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.

[0134] 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.

[0135] The Sidelink Control Channel (SCCH) is a sidelink control channel used to transmit control information from one UE to another. The SCCH is mapped to the transport channel SL-SCH.

[0136] 3GPP is considering supporting V2X communication in NR as well. The study 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.

[0137] In LTE, SL communication was limited to broadcast only. In NR, support for unicast and groupcast in addition to broadcast is being considered for SL communication (see Non-Patent Document 22 (3GPP TS23.287)).

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

[0139] In SL communication, in addition to broadcast, support for unicast and groupcast is being considered, and therefore support for PC5-S signaling is being explored (see Non-Patent Document 22 (3GPP TS23.287)). For example, PC5-S signaling is implemented to establish a link for SL, i.e., PC5 communication. This link is implemented at the V2X layer and is also referred to as a Layer 2 link.

[0140] Furthermore, support for RRC signaling in SL communication is being considered (see Non-Patent Document 22 (3GPP TS23.287)). RRC signaling in SL communication is also referred to as PC5 RRC signaling. For example, it has been proposed to notify UEs of their capabilities between UEs performing PC5 communication, and to notify AS layer settings for V2X communication using PC5 communication.

[0141] In multicast communication using NR, both PTM (Point to Multipoint) and PTP (Point to Point) may be used. A common PDCP entity may be used in both PTM and PTP. PTM and PTP may have different legs (RLC, combinations of logical channels). In multicast communication, PTM legs and PTP legs may be used while being dynamically switched between them.

[0142] A PDCP status report may be used in switching between PTM and PTP legs. The base station may use the PDCP status report transmitted from the UE to determine whether the UE is switching between PTM and PTP. The base station may use the report to retransmit a PDCP PDU containing multicast data to the UE.

[0143] However, sending a PDCP status report from the UE to the base station requires instructions from the base station. For example, the UE sends a PDCP status report to the base station in response to instructions from the base station, such as a DRB modification (see Non-Patent Documents 19 and 27). Therefore, if, for example, the UE fails to receive some PDCP PDUs consisting of multicast data, the UE cannot send a PDCP status report to the base station, resulting in the problem that the multicast data loss at the UE is not resolved.

[0144] This embodiment discloses a method for solving these problems.

[0145] To solve the aforementioned problems, in the communication system according to this embodiment, the UE notifies the base station of information regarding the multicast reception status. The UE may be capable of autonomously sending the notification to the base station. The notification may use a PDCP status report (see Non-Patent Document 27 (TS38.323)). As other examples, the notification may use PRACH or RRC signaling.

[0146] The base station uses the information received from the UE to perform the PTM / PTP switching. Alternatively, the base station may perform the PTM / PTP switching without using this information.

[0147] The base station notifies the UE of information regarding PTM / PTP switching. This notification may use RRC signaling, MAC signaling, or L1 / L2 signaling.

[0148] As another example, the base station may not notify the information. That is, the base station may implicitly switch between PTM and PTP. The UE may be able to receive both PTM and PTP simultaneously. This allows for rapid switching between PTM and PTP in a communication system, for example.

[0149] This document discloses an example in which a PDCP status report is used to notify a base station of information regarding the reception status of multicast from a UE.

[0150] The UE may autonomously send PDCP status reports. The UE may also autonomously send PDCP status reports via multicast.

[0151] The UE may determine whether or not it is multicast. The UE may use a logical channel identifier, a QoS flow identifier, or a bearer identifier for this determination. As an example of using a bearer identifier, the identifier of the multicast bearer (MRB-ID) may be used.

[0152] The following conditions (1) to (5) are disclosed for the UE to send a PDCP status report.

[0153] (1) Transmit periodically.

[0154] (2) Transmission triggered by predetermined conditions in the PDCP layer.

[0155] (3) Transmission is triggered by predetermined conditions in the RLC layer.

[0156] (4) Transmission triggered by certain conditions in HARQ.

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

[0158] As described in (1) above, the UE periodically sends PDCP status reports to the base station. The base station may use these periodic reports to understand the reception status of multicast data at the UE. This allows the base station to continuously monitor the reception status at the UE, resulting in stable multicast communication.

[0159] The period in (1) above may be predetermined by the standard, or it may be determined by the base station and notified to the UE. The base station may make this notification using RRC signaling, for example, RRC Reconfiguration. This RRC signaling may be, for example, RRC signaling used for multicast configuration. This makes it possible to reduce signaling from the base station, for example.

[0160] Other examples of how the base station may provide such notifications include MAC signaling or L1 / L2 signaling. This allows for, for example, rapid notification from the base station to the UE.

[0161] Another example of the period is that the AMF may determine the period. The AMF may notify the UE of the period. The AMF may notify the period using, for example, NAS signaling. This allows the AMF to notify the UE of a great deal of information.

[0162] In (2) above, the UE may send a PDCP status report triggered by the expiration of a timer used in the PDCP layer. This timer may be, for example, a timer used for reordering (t-reordering as described in Non-Patent Document 27). The base station may use this notification to perform PTM / PTP switching, retransmit the PDCP PDU, or do both. This enables, for example, rapid retransmission from the base station after a PDCP layer reception failure at the UE.

[0163] As another example, a timer may be newly established for sending PDCP status reports. This timer may be triggered, for example, when PDCP PDUs do not arrive in the correct order. The timer value may be, for example, shorter than t-reordering. The UE may send a PDCP status report to the base station when the timer for sending PDCP status reports expires. This allows the base station to send the missing PDCP PDUs to the UE before t-reordering expires, and as a result, the UE can forward the reordered multicast data to the upper layer.

[0164] As another example in (2) above, the number of missing PDCP PDUs or the number of missing PDCP SDUs (Service Data Units) may be used. For example, the UE may send a PDCP status report to the base station when the number of missing PDCP PDUs exceeds a predetermined value or is greater than a predetermined value. As another example, the number of consecutive missing data may be used instead of the number of missing data mentioned above. The aforementioned PDCP PDUs may be, for example, PDCP PDUs related to multicast. The base station may use the report to perform PTM / PTP switching, retransmit PDCP PDUs, or do both. This makes it possible, for example, to retransmit the missing multicast data from the base station to the UE in a batch, resulting in efficient multicast retransmission.

[0165] Another example in (2) above may be the PDCP PDU loss rate. The UE may, for example, calculate the PDCP PDU loss rate for PDCP SN (Sequence Number) within a predetermined range, or calculate the PDCP SDU loss rate for COUNT values ​​within a predetermined range (see Non-Patent Document 27 (TS38.323)). The UE may send a PDCP status report to the base station if the loss rate is equal to or greater than a predetermined value. The base station may use the report to perform PTM / PTP switching, retransmit PDCP PDUs, or both. This allows the base station to quickly retransmit the missing multicast data to the UE, thereby ensuring the reliability of the multicast.

[0166] As an example in (3) above, the UE may transmit a PDCP status report when the conditions for transmitting an RLC status PDU (see Non-Patent Document 28 (TS38.322)) are met. The UE's RLC layer may notify the PDCP layer that the conditions for transmitting an RLC status PDU have been met, or it may instruct the base station to notify the PDCP status report. The UE may transmit both an RLC status PDU and a PDCP status report. As another example, the UE may transmit a PDCP status report instead of transmitting an RLC status PDU. The base station may use the report to perform PTM / PTP switching, retransmit a PDCP PDU, or do both. This allows, for example, the UE to quickly transmit a PDCP status report to the base station, and as a result, the base station to quickly retransmit a PDCP status report to the UE.

[0167] As another example in (3) above, the UE may send a PDCP status report triggered by the expiration of a timer used in the RLC layer. This timer may be, for example, a timer used for reassembly in the RLC layer (t-reassembly as described in Non-Patent Document 28). The UE's RLC layer may notify the PDCP layer of the timer's expiration, or instruct it to notify the base station of the PDCP status report. The base station may use the report to perform PTM / PTP switching, retransmit the PDCP PDU, or both. This enables, for example, rapid retransmission from the base station after a loss of reception in the UE's PDCP layer.

[0168] In (3) above, a new timer may be provided. This timer may be activated, for example, when RLC PDUs do not arrive in the correct order. The value of this timer may be, for example, shorter than the t-reassembly timer. The UE may send a PDCP status report to the base station when the timer expires. This allows the base station to send the missing PDCP PDUs to the UE before the t-reassembly timer expires, and as a result, the UE can forward the reassembled multicast data to the upper layer.

[0169] Another example in (3) above is the number of missing RLC PDUs. For example, the UE may send a PDCP status report to the base station when the number of missing RLC PDUs exceeds a predetermined value or is greater than a predetermined value. Another example is that the number of consecutive missing data is used instead of the number of missing data mentioned above. The RLC PDU may be, for example, an RLC PDU related to multicast. The base station may use the report to perform PTM / PTP switching, retransmit PDCP PDUs, or do both. This allows the base station to retransmit the missing multicast data to the UE in a batch, resulting in efficient multicast retransmission.

[0170] Another example in (3) above may be the RLC PDU loss rate. The UE may, for example, calculate the RLC PDU loss rate for RLC SN (Sequence Number) within a predetermined range. The UE may send a PDCP status report to the base station if the loss rate is greater than or equal to a predetermined value. The base station may use the report to perform PTM / PTP switching, retransmit PDCP PDUs, or both. This allows the base station to quickly retransmit the missing multicast data to the UE, thereby ensuring multicast reliability.

[0171] The RLC entity used in the conditional determination in (3) above may be an RLC-AM (Acknowledged Mode) entity. This can, for example, avoid complexity in the communication system. As another example, the RLC entity may be an RLC-UM (Unacknowledged Mode) entity. This can, for example, ensure the reliability of multicast with less processing power.

[0172] The RLC entity used in the conditional determination in (3) above may be an RLC entity used for PTM communication. This allows for, for example, rapid switching from PTM to PTP. The RLC entity may also be an RLC entity used for PTP communication. This allows for, for example, rapid switching from PTP to PTM. The RLC entity may be both an RLC entity used for PTM communication and an RLC entity used for PTP communication. This allows for, for example, rapid switching from PTM to PTP and from PTP to PTM.

[0173] The RLC entity used in the condition determination in (3) above may be an RLC entity of an active communication path. This allows, for example, the UE to quickly send a PDCP status report to the base station. As another example, the RLC entity may be an inactive RLC entity. This allows, for example, the UE to make a retransmission request to the base station for data awaiting retransmission on an inactive RLC entity, thereby ensuring reliability.

[0174] The base station may configure the leg for the UE. This configuration may include information about the leg type (e.g., PTM leg, PTP leg) and information about the default operating state (e.g., active, stopped). This configuration may be performed, for example, using RRC signaling.

[0175] The base station may send a notification to the UE regarding the activation and / or deactivation of a leg. The notification may include information identifying the UE's leg, information regarding the activation and / or deactivation of the leg, or a combination of both. As another example, the notification may include information about the leg to be activated. The UE may use the notification to activate or deactivate the leg. For example, the UE may use the information about the leg to be activated to activate that leg and deactivate other legs. As another example, the UE may use the information about the leg to be activated to activate that leg while other legs are activated. As yet another example, the UE may use the information about the leg to be deactivated to deactivate that leg. The UE may use the information about the leg to be deactivated to activate or deactivate other legs. The base station may send the notification using RRC signaling, MAC signaling, or L1 / L2 signaling. This allows for, for example, rapid leg switching.

[0176] As an example in (4) above, the UE may send a PDCP status report to the base station when the number of HARQ retransmissions in the UE exceeds a predetermined number or is greater than a predetermined number. The predetermined number may be one or multiple times. The HARQ layer of the UE may notify the PDCP layer that the number of HARQ retransmissions exceeds a predetermined number or is greater than a predetermined number, or may instruct it to send a PDCP status report. The base station may use the report to perform PTM / PTP switching, retransmit PDCP PDUs, or do both. This makes it possible, for example, for the base station to retransmit missing multicast data in bulk to the UE, resulting in efficient multicast retransmission.

[0177] Another example in (4) above is that the UE may send a PDCP status report to the base station when the number of HARQ retransmissions at the UE exceeds a predetermined number or is greater than a predetermined number within a predetermined period. A timer representing the predetermined period may be provided. This allows the base station to quickly retransmit missing multicast data to the UE, thereby ensuring the reliability of multicast.

[0178] As another example in (4) above, the UE may send a PDCP status report to the base station when the number of HARQ retransmissions within a predetermined number of transport block transmissions exceeds a predetermined number or is greater than a predetermined number. This can achieve, for example, the same effect as described above.

[0179] The predetermined values, ranges, frequency, and / or durations in (1) to (4) above may be predetermined by the standard, or they may be determined by the base station and notified to the UE. The base station may make such notification using RRC signaling, for example, RRC Reconfiguration. Such RRC signaling may be, for example, RRC signaling used for multicast configuration. This may reduce the amount of signaling from the base station.

[0180] Other examples of how the base station may provide such notifications include MAC signaling or L1 / L2 signaling. This allows for, for example, rapid notification from the base station to the UE.

[0181] The UE may use the PTM leg to send the PDCP status report. This allows the UE to quickly notify the base station of the report, for example.

[0182] The base station may individually allocate resources such as uplink PUCCH time and / or frequency and code sequence to UEs using PTM legs. The resources allocated to the UE may be for SR or for HARQ feedback. The UE may use the resources to transmit an SR to the base station. The base station may notify the UE of an uplink grant in response to the SR. The UE may use the uplink grant to transmit a PDCP status report to the base station. The resources individually allocated by the base station to the UE may differ for each UE. This makes it possible, for example, to prevent collisions with other UEs in uplink PUCCH transmissions. The base station may configure the resources using, for example, RRC individual signaling.

[0183] As another example, the UE may perform the transmission using the PTP leg. This can, for example, avoid complexity in the communication system. In this case, the uplink RLC layer transmission on the UE's PTM leg may not be performed. This can, for example, reduce the circuit size in the UE.

[0184] As another example, the UE may use the active leg to send PDCP status reports. This allows for, for example, rapid notification from the UE to the base station.

[0185] As another example, the UE may use an inactive leg to send PDCP status reports. The UE may temporarily activate the inactive leg. This allows the UE to perform multicast reception and PDCP status report transmission in parallel, resulting in increased efficiency of the communication system. After the transmission is complete, the UE may deactivate the leg again. This can reduce the UE's power consumption, for example.

[0186] As another example, the UE may send the PDCP status report using a different leg than the one used for the condition checks in (1) to (4) above. This makes it possible to avoid, for example, the deterioration of the communication environment that occurred in the leg used for condition checks, and as a result, improve the reliability of sending the PDCP status report.

[0187] The UE may include in the PDCP status report information regarding the number of received data loss signals for PDCP PDUs, information regarding the number of consecutive received data loss signals for PDCP PCUs, information regarding the timing of such consecutive received data loss signals, and information regarding the received data loss rate for PDCP PDUs. This allows, for example, the base station to quickly obtain this information.

[0188] The UE may include a request for multicast PTM / PTP switching in the PDCP status report. This request may include information indicating whether or not a leg switch is to be performed, information about which leg to keep active, information about which leg to stop, or a combination of the above. The base station may use this information to perform multicast PTM / PTP switching, or it may not. This allows the base station to perform PTM / PTP switching quickly, for example, and as a result, improve the reliability of multicast communication.

[0189] The UE may include information identifying the multicast in the PDCP status report (e.g., multicast identifier, logical channel identifier for multicast, identifier of the radio bearer used for multicast, e.g., MRB-ID). This allows, for example, a base station to quickly identify the multicast.

[0190] A predetermined range may be set for the logical channel identifiers used for multicast, for example, the logical channel identifiers assigned to PTM legs. This range may differ from the range of logical channel identifiers that can be assigned to individual channels. This makes it possible, for example, for a UE receiving multicast to prevent duplication between the logical channel identifiers assigned to PTM legs and the logical channel identifiers of other individual channels.

[0191] This document discloses an example of how RACH is used to notify base stations of multicast reception status from a UE.

[0192] A RACH may be provided for the notification of such information. The PRACH preamble in the RACH may differ from the PRACH preamble used for initiating a connection with the base station and the PRACH preamble used for system information requests. For example, a predetermined range may be provided for the PRACH preamble used for notifying the base station of multicast reception status from the UE. The base station may use the PRACH preamble from the UE to determine the type of RACH. This allows the base station to quickly determine the type of RACH, for example.

[0193] The base station may individually assign the PRACH preamble to the UE. This assignment from the base station to the UE may be made, for example, from within the predetermined range described above. This assignment from the base station to the UE may be made, for example, using RRC signaling. The UE may use the preamble to transmit the PRACH to the base station. This makes it possible to prevent, for example, PRACH collisions between the UE and other UEs, and as a result the UE can notify the information quickly.

[0194] The conditions under which the UE sends a RACH for the notification may be the same as the conditions under which a PDCP status report is sent. This can achieve the same effect as, for example, sending a PDCP status report.

[0195] Another example of the condition is when the reception quality from the base station at the UE falls below or is less than a predetermined value. The UE may use SS blocks, CSI-RS, PDCCH related to multicast, or multicast data to measure reception quality. The UE may use SINR (Signal to Interference plus Noise Ratio), SNR (Signal to Noise Ratio), BLER (Block Error Rate), BER (Bit Error Rate) (or BER equivalent), RSRP (Reference Signal Received Power), or RSRQ (Reference Signal Received Quality) as the reception quality. The predetermined value may be defined in advance by a standard, or it may be determined by the base station and notified or broadcast to the UE. The base station may use this information to switch between PTM / PTP for multicast or to retransmit multicast. This allows the UE to quickly notify the base station of deterioration in reception quality, and as a result, the reliability of multicast can be quickly ensured.

[0196] The UE may include information regarding multicast retransmission requests in its RACH to the base station, information regarding the multicast data to be retransmitted, and information identifying the multicast. It may also include information similar to that in the aforementioned PDCP status report. The base station may use this information to identify the multicast data that needs to be retransmitted. This allows the base station to perform multicast retransmissions quickly, for example.

[0197] The UE may include this information in Msg3 during random access processing and transmit it to the base station. This random access processing may, for example, be a four-step random access process. This allows the UE to transmit more information to the base station.

[0198] The UE may include the information in MsgA during random access processing and transmit it to the base station. This random access processing may be, for example, a two-step random access process. This allows the UE to quickly notify the base station of the information.

[0199] In the RACH for this notification, the base station may include the PTP / PTM switching instruction to the UE in Msg4 or MsgB. This can, for example, reduce the amount of signaling between the base station and the UE.

[0200] In the RACH for the notification, Msg4 or MsgB may not be sent from the base station to the UE. This allows, for example, the RACH procedure for the notification to be completed quickly.

[0201] An example of using RRC signaling to notify base stations of multicast reception status from a UE is disclosed.

[0202] The UE may notify the base station of this information using RRC signaling. This allows the UE to notify the base station of a larger amount of information, for example.

[0203] As the RRC signaling, existing signaling may be used, for example, the signaling used in measurement reporting described in Non-Patent Document 19 (TS38.331). Alternatively, new signaling may be provided.

[0204] The conditions under which the UE transmits the RRC signaling may be the same as the conditions under which the PDCP status report is transmitted, as described above. This will produce the same effect as, for example, transmitting the PDCP status report.

[0205] Another example of the conditions is that they may be the same as the conditions for sending RACH as described above. This would have the same effect as, for example, sending RACH.

[0206] Another example of the conditions is an event that triggers the measurement (see Non-Patent Document 19 (TS38.331)). Existing events may be used as such events. This can, for example, avoid the complexity of the design in a communication system.

[0207] A new event may be established. This new event may be, for example, the occurrence of the conditions for sending a PDCP status report as described above, or the same as the conditions for sending a RACH as described above, or the occurrence of any of the conditions (1) to (5) described above. This new event may be used as an event to trigger measurement. The base station may set a measurement event for the UE triggered by this event. This setting from the base station to the UE may be done, for example, using measurement request signaling or multicast setting signaling. The UE may send a measurement report to the base station when this event occurs. This allows for flexible condition setting, for example.

[0208] The UE may include in the RRC signaling information regarding a multicast retransmission request, information regarding the multicast data to be retransmitted, or information identifying the multicast. This information may include, for example, information regarding the radio bearer used to transmit the multicast data, information regarding the logical channel, information regarding the QoS flow of the multicast data, information regarding the PDCP PDU involved in the retransmission, information regarding the RLC PDU involved in the retransmission, or a combination of the above. The base station may use this information to identify the multicast data that needs to be retransmitted. This allows the base station to perform multicast retransmissions quickly, for example.

[0209] The signaling disclosed above may be used in combination. The signaling used may be switched. For example, the signaling used may be switched depending on the type of RLC entity used for multicast transmission and reception. For example, when using RLC-AM, a PDCP status report may be used, or when using RLC-UM, RACH may be used. This can improve the flexibility of the communication system and avoid complexity in the design of the communication system.

[0210] The base station decides whether to switch between PTM and PTP. The base station may make this decision using information about the multicast reception status received from the UE, or it may not use such information. For example, the base station may make the switching decision autonomously. For example, the base station may decide the switching using HARQ-NACKs from the UE (e.g., triggered by receiving a predetermined number of HARQ-NACKs from the UE), or it may decide the switching using information about the PDCP SN transmitted to the UE receiving the PTP leg and the PDCP SN transmitted to another UE using PTM (e.g., triggered by the fact that the difference between the two PDCP SNs has disappeared). This allows the base station to select the optimal leg according to the communication environment with the UE, and as a result, the efficiency of the communication system can be improved.

[0211] A PTM / PTP switch is performed between the base station and the UE. The base station may request the UE to switch between PTM and PTP. This request from the base station to the UE may be made using RRC signaling, MAC signaling, or L1 / L2 signaling. The UE uses the signaling to switch the leg performing the receiving operation between PTM and PTP. This can, for example, reduce power consumption at the UE.

[0212] The base station may send the request using the leg currently in use for multicast transmission to the UE. This allows the base station to quickly notify the UE of the request. The request may include information about the UE to switch legs (e.g., C-RNTI: Cell Radio Network Temporary Identifier). This makes it easy to identify the UE to switch legs, even if the request is sent using a PTM leg. The request may include information about the multicast to which the leg is being switched (e.g., multicast identifier, information about the bearer used for multicast transmission, information about the logical channel used for multicast transmission). This allows the UE to quickly identify the multicast involved in the leg switch. The request may include information about the destination of the leg switch, information about the source of the leg switch, or information that identifies the leg switch (e.g., information indicating a switch from PTM to PTP, or from PTP to PTM). This allows the UE to quickly identify the switched leg.

[0213] In the switching from a PTP leg to a PTM leg, the same procedures as described above may be followed. For example, the UE may send a PDCP status report to the base station, RACH may be used, or RRC signaling, such as a measurement report, may be sent. As another example, the UE may send an RLC status PDU to the base station, MAC signaling may be sent, or L1 / L2 signaling may be sent.

[0214] A base station may decide to switch from a PTP leg to a PTM leg. The base station may decide to switch, for example, using the aforementioned notification from the UE, or it may decide autonomously. Examples of decisions made by the base station include when t-reordering at the UE does not expire for a predetermined period of time, or when the difference between the PDCP SN sent to the receiving UE using the PTP leg and the PDCP SN sent to another UE using the PTM disappears. This allows the base station to decide to switch quickly and improves the communication efficiency in multicast.

[0215] Figure 14 is a sequence diagram showing the switching operation from the PTM leg to the PTP leg and from the PTP leg to the PTM leg during multicast transmission from the base station to the UE. Figure 14 shows an example in which the UE notifies the status of multicast reception using a PDCP status report. Figure 14 shows an example in which this notification is triggered by the expiration of the t-reordering timer.

[0216] In step ST1415 shown in Figure 14, the base station instructs the UE to configure multicast. The base station may make this notification using, for example, RRC reconfiguration (see Non-Patent Literature 19 (TS38.331)). The instruction from the base station to the UE may include information about the multicast in question (e.g., multicast identifier, identifier of the radio bearer used for multicast transmission), information about the configuration of the PTM leg and / or PTP leg, information about notification from the UE to the base station, for example, the method of notification (e.g., PDCP status report, RACH, RRC signaling), information about the conditions for notification (e.g., information about (1) to (5) above), and information about the configuration of uplink transmission from the UE. The information about the configuration of the PTM leg and / or PTP leg may include information about the logical channel (e.g., logical channel identifier), information about the RLC layer configuration, information about the MAC layer, and information about the PHY layer. Information regarding the uplink transmission settings from the UE may include, for example, information regarding the uplink PUCCH time and / or frequency, and code sequence resources. The UE may use this notification to configure multicast reception settings.

[0217] In step ST1417 shown in Figure 14, the UE notifies that multicast configuration is complete. The UE may give this notification, for example, by using RRC reconfiguration completion (see Non-Patent Document 19 (TS38.331)).

[0218] In step ST1419 shown in Figure 14, the base station requests multicast distribution from the AMF. This request may include information identifying the UE and information identifying multicast. In step ST1421, the AMF requests multicast distribution from the multicast / broadcast SMF (MB-SMF) (Non-Patent Literature 24 (see TR23.757)). In step ST1423, session information modification related to multicast distribution is performed between the MB-SMF and the multicast / broadcast UPF (MB-UPF) (Non-Patent Literature 24 (see TR23.757)). In step ST1425, the MB-SMF notifies the AMF of its response to the multicast distribution request. In step ST1427, the AMF notifies the base station of its response to the multicast distribution request.

[0219] In step ST1429 shown in Figure 14, the base station notifies the AMF of the response to the change in session information related to multicast distribution. In step ST1430, the AMF notifies the SMF of the response to the change in session information. This notification may use, for example, the processing of Nsmf_PDUSession_Update (see Non-Patent Literature 29 (TS23.502)). In step ST1431, the SMF uses this notification to decide that it does not need to use UPF and notifies the AMF. This notification may include the session management context.

[0220] In step ST1433 shown in Figure 14, the MB-UPF transmits multicast data to the base station. In step ST1435, the base station transmits multicast data to the UE. The multicast data transmission in step ST1435 is performed using a PTM leg.

[0221] In step ST1437 shown in Figure 14, the UE checks whether the t-reordering timer has expired. If the timer has not expired, it continues to receive multicast data. If the timer has expired, it performs the process in step ST1439.

[0222] In step ST1439 shown in Figure 14, the UE sends a PDCP status report to the base station. This report may include information about missing PDCP PDUs. The base station may use step ST1439 to decide whether to switch between PTM and PTP. In the example shown in Figure 14, the base station decides to switch from the PTM leg to the PTP leg for multicast communication to the UE.

[0223] In step ST1441 shown in Figure 14, a PTM / PTP switchover occurs between the base station and the UE. That is, the base station switches the leg used for multicast transmission to the UE from a PTM leg to a PTP leg. The base station may or may notify the UE of this switchover. The base station may use RRC signaling, MAC signaling, or L1 / L2 signaling for this notification. The base station may use the active leg, the PTM leg in the example in Figure 14, to notify the UE. The notification using the PTM leg may include information about the UE, information that identifies multicast, or information indicating a switchover from a PTM leg to a PTP leg. The UE may, upon receiving this notification, switch the leg used for multicast reception from a PTM leg to a PTP leg.

[0224] In step ST1442 shown in Figure 14, the base station retransmits multicast data to the UE. This retransmission from the base station to the UE is performed using a PTP leg. The data to be retransmitted may be, for example, a missing PDCP PDU, as indicated by the information contained in the PDCP status report sent in step ST1439.

[0225] In step ST1443 shown in Figure 14, the MB-UPF transmits multicast data to the base station. In step ST1445, the base station transmits multicast data to the UE. The multicast data transmission in step ST1445 is performed using a PTP leg.

[0226] In step ST1447 shown in Figure 14, the base station decides to switch the leg used for multicast transmission to the UE from a PTP leg to a PTM leg. The base station may make this decision, for example, if the PDCP PDU transmitted to the UE using the PTP leg has the same or earlier data than the PDCP PDU transmitted to other UEs using the PTM leg, that is, if the PDCP SN (Sequence Number) of the PDCP PDU transmitted using the PTP leg is equal to or greater than the PDCP SN of the PDCP PDU transmitted using the PTM leg. The base station may or may notify the UE of this switch. The notification from the base station to the UE may be the same as in step ST1441. The UE may switch the leg used for multicast reception from a PTP leg to a PTM leg upon receiving this notification.

[0227] In step ST1449 shown in Figure 14, the MB-UPF transmits multicast data to the base station. In step ST1451, the base station transmits multicast data to the UE. The multicast data transmission in step ST1451 is performed using a PTM leg.

[0228] Figure 14 shows an example of sending a PDCP status report triggered by the expiration of the t-reordering timer, but the UE may also send a PDCP status report triggered by the expiration of other timers. For example, a new timer may be introduced. This timer may have a shorter value than the t-reordering timer, for example. This allows the base station to send a PDCP PDU related to multicast data to the UE before the t-reordering timer expires, and as a result, the UE can forward the reordered multicast data to the upper layer.

[0229] Figure 14 shows an example where a PDCP status report is sent triggered by the expiration of the t-reordering timer, but other conditions may also be used as triggers. For example, a condition related to the number of missing PDCP PDUs or a condition related to the number of missing RLC PDUs may be used. This allows, for example, the base station to quickly retransmit missing multicast data to the UE.

[0230] Figure 15 is a sequence diagram illustrating other examples of the switching operation from a PTM leg to a PTP leg and from a PTP leg to a PTM leg during multicast transmission from a base station to a UE. Figure 15 shows an example in which the UE notifies of the multicast reception status using PRACH. Figure 15 shows an example in which this notification is triggered by the expiration of the t-reordering timer. In Figure 15, the same step numbers are used for processes common to Figure 14, and common explanations are omitted.

[0231] Steps ST1415 to ST1437 shown in Figure 15 are the same as in Figure 14. The base station may include in the signal transmitted in step ST1415 information about the range of the PRACH preamble used to notify information about multicast reception status, or it may include information about the PRACH preamble used by the UE to notify information about multicast reception status. If the t-reordering timer expires in step ST1437, the UE performs the process in step ST1539.

[0232] In step ST1539 shown in Figure 15, the UE transmits a PRACH to the base station. The preamble used for the PRACH may belong to a different range from the PRACH preamble for initial access and / or the PRACH preamble for System Information (SI) requests. Alternatively, a PRACH preamble configured by the base station for notifying information about multicast reception status may be used. In step ST1541, the base station transmits a Random Access Response (RAR) to the UE. The RAR transmitted in step ST1541 may include information about an uplink grant for Msg3.

[0233] In step ST1543 shown in Figure 15, the UE sends a random access processing signaling message 3 to the base station. The signaling message 3 may include information regarding a multicast retransmission request, information regarding multicast data to be retransmitted, information identifying the multicast, information regarding a missing PDCP PDU, or information regarding a PTM / PTP switching request. In step ST1545, the base station sends a random access processing signaling message 4 to the UE.

[0234] Steps ST1441 to ST1445 shown in Figure 15 are the same as those in Figure 14.

[0235] In steps ST1557 to ST1563 shown in Figure 15, the same process as in steps ST1539 to ST1545 is performed.

[0236] Steps ST1447 to ST1451 shown in Figure 15 are the same as those in Figure 14.

[0237] Figure 15 shows an example where PRACH is sent triggered by the expiration of the t-reordering timer, but the trigger could also be the expiration of another timer. For example, a new timer may be introduced. This timer may have a shorter value than the t-reordering timer. This allows the base station to send a PDCP PDU related to multicast data to the UE before the t-reordering timer expires, and as a result, the UE can forward the reordered multicast data to the upper layer.

[0238] Figure 15 shows an example where PRACH is sent triggered by the expiration of the t-reordering timer, but other conditions may also be used as triggers. For example, a condition related to the number of missing PDCP PDUs or a condition related to the number of missing RLC PDUs may be used. This allows, for example, the base station to quickly retransmit missing multicast data to the UE.

[0239] In step ST1545 and ST1441 shown in Figure 15, an example is shown where the transmission of Msg4 from the base station to the UE and the switching from the PTM leg to the PTP leg are performed in different steps, but they may also be performed in the same step. For example, the base station may decide to switch from the PTM leg to the PTP leg triggered by the transmission of Msg3 in step ST1543, and notify the UE of the switching information in Msg4 in step ST1545. The same may be done in steps ST1561, ST1563, and ST1447. This makes it possible to reduce the amount of signaling between the base station and the UE, for example.

[0240] The example shown in Figure 15 illustrates the use of a 4-step RACH, but a 2-step RACH may also be used. For example, steps ST1539 and ST1543 may be combined as MsgA, or steps ST1541 and ST1545 may be combined as MsgB. The same may apply to steps ST1557 to ST1563. This allows for the rapid execution of, for example, random access processing.

[0241] In the example shown in Figure 15, the RACH processing in steps ST1557 to ST1563 is performed during the switching from a PTP leg to a PTM leg. However, the RACH processing in steps ST1557 to ST1563 may be omitted. For example, the base station may autonomously perform the switching process from a PTP leg to a PTM leg. For instance, the base station may switch from a PTP leg to a PTM leg when the PDCP SN value of a PDCP PDU transmitted using a PTP leg is equal to or greater than the PDCP SN value of a PDCP PDU transmitted to another UE using a PTM leg. This allows for rapid switching from a PTP leg to a PTM leg and reduces signaling between the base station and the UE.

[0242] In this first embodiment, the case where the PTM leg and PTP leg of multicast are switched between is shown, but the PTM leg and PTP leg may be used simultaneously. For example, multicast retransmission data may be sent and received using the PTP leg. This makes it possible to improve the efficiency of multicast in a communication system, for example.

[0243] Another example of PTM / PTP switching is that the base station may not send the request to the UE. The UE may be able to receive multicast using either leg. This allows for rapid switching between PTM and PTP between the base station and the UE, for example. The UE uses the PDCCH reception result for the multicast data to decide which leg to use, PTM or PTP. For example, if the PDCCH is decodeable using a multicast RNTI, the UE may receive the multicast data using the PTM leg, or if the PDCCH is decodeable using a C-RNTI, the UE may receive the multicast data using the PTP leg.

[0244] For example, a base station may use PTP legs to transmit only multicast data for retransmission. This can improve the efficiency of multicast transmission, for example. As another example, a base station may use PTP legs to transmit to UEs with poor propagation conditions. This can prevent excessively high-intensity radio waves from being transmitted to other UEs, for example.

[0245] Figure 16 is a sequence diagram showing the operation in which the PTM leg and PTP leg are used simultaneously in multicast transmission from the base station to the UE. Figure 16 shows an example in which the UE notifies the status of multicast reception using a PDCP status report. Figure 16 shows an example in which this notification is triggered by the expiration of the t-reordering timer. In Figure 16, the same step numbers are used for processes common to Figure 14, and common explanations are omitted.

[0246] Steps ST1415 to ST1433 shown in Figure 16 are the same as in Figure 14.

[0247] In step ST1435 shown in FIG. 16, the base station transmits multicast data to the UE. This transmission is performed using the PTM leg. The UE receives the data using the PTM leg. Since the PDCCH related to step ST1435 is decodable using the multicast RNTI, the UE determines to use the PTM leg.

[0248] Steps ST1437 to ST1439 shown in FIG. 16 are the same as those in FIG. 14.

[0249] In step ST1442 shown in FIG. 16, the base station retransmits multicast data to the UE. This retransmission is performed using the PTP leg. The UE receives the data using the PTP leg. Since the PDCCH related to step ST1442 is decodable using the C-RNTI, the UE determines to use the PTP leg.

[0250] Step ST1443 shown in FIG. 16 is the same as that in FIG. 14.

[0251] In step ST1645 shown in FIG. 16, the base station transmits multicast data to the UE. This transmission is performed using the PTM leg. The UE receives the data using the PTM leg. Since the PDCCH related to step ST1645 is decodable using the multicast RNTI, the UE determines to use the PTM leg.

[0252] Step ST1449 shown in FIG. 16 is the same as that in FIG. 14.

[0253] Step ST1451 shown in FIG. 16 is the same as step ST1645.

[0254] Figure 16 shows an example of sending a PDCP status report triggered by the expiration of the t-reordering timer, but the trigger could also be the expiration of another timer. For example, a new timer could be introduced. This timer could be set to a shorter value than the t-reordering timer. This would allow the base station to send a PDCP PDU related to multicast data to the UE before the t-reordering timer expires, and as a result, the UE could forward the reordered multicast data to the upper layer.

[0255] Figure 16 shows an example where a PDCP status report is sent triggered by the expiration of the t-reordering timer, but other conditions may also be used as triggers. For example, a condition related to the number of missing PDCP PDUs may be used, or a condition related to the number of missing RLC PDUs may be used. This allows, for example, the base station to quickly retransmit missing multicast data to the UE.

[0256] The example shown in Figure 16 illustrates the use of a PDCP status report, but RACH or RRC signaling may also be used. This allows for the avoidance of complexity in communication systems, for example.

[0257] Different carriers or different BWPs may be used for the PTM leg and the PTP leg. The base station may configure different carriers or different BWPs as radio resources for the PTM leg and the PTP leg for the UE. This allows the UE to quickly distinguish between the PTM leg and the PTP leg, for example.

[0258] This embodiment 1 enables notification of multicast reception status from the UE to the base station, thereby improving the reliability of multicast.

[0259] Modification 1 of Embodiment 1. This modified example 1 discloses the RLC entity used for multicast transmission and reception in Embodiment 1.

[0260] In multicast transmission and reception in the communication system according to this modified example 1, both RLC-AM entities and RLC-UM entities may be connected to the PDCP having PTM legs and PTP legs.

[0261] For example, two RLC-UM entities and one RLC-AM entity may be connected to a single PDCP. One of the two RLC-UM entities may be for transmitting and the other for receiving. For example, two RLC-UM entities may be for PTM legs, or one RLC-AM entity may be for PTP legs.

[0262] Figure 17 shows the configuration of PDCP entities and RLC entities used in multicast using PTM legs and / or PTP legs. In Figure 17, both the base station and UE use two RLC-UM entities in the PTM leg and one RLC-AM entity in the PTP leg. Of the two RLC entities in the PTM leg, one is a transmitting entity and the other is a receiving entity. In both the base station and UE, the transmitting and receiving entities of the RLC-UM are facing each other. In both the base station and UE, the RLC-AM entities in the PTP leg are facing each other.

[0263] As another example, one RLC-UM entity and one RLC-AM entity may be connected to a single PDCP. An RLC-UM entity at the UE may be a receiving RLC-UM entity. An RLC-UM entity at the base station may be a transmitting RLC-UM entity. For example, an RLC-UM entity may be for PTM legs, and an RLC-AM entity may be for PTP legs. This can reduce the memory usage required for multicast at the base station and UE, for example.

[0264] Figure 18 shows another example of the configuration of PDCP and RLC entities used in multicast using PTM and / or PTP legs. In Figure 18, both the base station and the UE use one RLC-UM entity in the PTM leg and one RLC-AM entity in the PTP leg. The base station's PTM leg uses a transmitting RLC-UM entity. The UE's PTM leg uses a receiving RLC-UM entity. The base station's transmitting RLC-UM entity and the UE's receiving RLC-UM entity face each other. For both the base station and the UE, the PTP legs have RLC-AM entities facing each other.

[0265] As another example, three RLC-UM entities may be connected to one PDCP. Two RLC-UM entities in the UE may be for receiving and one for transmitting. One RLC-UM entity in the base station may be for receiving and two for transmitting. For example, one transmitting RLC-UM entity and one receiving RLC-UM entity may be for PTP legs, or one receiving RLC-UM entity in the UE and one transmitting RLC-UM entity in the base station may be for PTM legs. This eliminates the need for RLC-AM entities, for example, and as a result, the processing load at the base station and UE can be reduced.

[0266] Figure 19 shows another example of the configuration of PDCP and RLC entities used in multicast using PTM and / or PTP legs. In Figure 19, both the base station and the UE use one RLC-UM entity in the PTM leg and two RLC-UM entities in the PTP leg. The base station's PTM leg uses a transmitting RLC-UM entity. The UE's PTM leg uses a receiving RLC-UM entity. The base station's transmitting RLC-UM entity and the UE's receiving RLC-UM entity face each other. Of the two RLC-UM entities in the PTP leg, one is a transmitting entity and the other is a receiving entity. In both the base station and the UE, the transmitting and receiving entities of the RLC-UM entities face each other.

[0267] The base station may notify the UE of the configuration for the PDCP and / or RLC used for multicast. This configuration may include information on the use of PTP legs and / or PTM legs, and information on RLC entities in the PTP and PTM legs, such as whether they are RLC-AM or RLC-UM, the number of RLC entities, and whether transmit and / or receive RLC-UM entities are required. This configuration may also include information on the number of bits in the PDCP SN, as described below. The UE may use this setting to configure the PDCP and / or RLC layers used for multicast reception. This can, for example, improve the flexibility of the communication system.

[0268] The operation of PDCP in multicast is disclosed below.

[0269] The behavior of PDCP in multicast may be determined by the mode of the connected RLC entity.

[0270] For example, a PDCP with even one RLC-AM entity connected may behave similarly to a PDCP in an AM DRB. For example, a PDCP at a UE with even one RLC-AM entity connected may send a PDCP status report to the base station. This allows for, for example, rapid retransmission of multicast from the base station to the UE.

[0271] As another example, a PDCP to which even one RLC-UM entity is connected may behave similarly to a PDCP in a UM DRB. For example, a PDCP in a UE to which even one RLC-UM entity is connected may not send a PDCP status report to the base station. The UE's PDCP may notify information regarding multicast reception status using PRACH, as disclosed in Embodiment 1, or it may notify information regarding multicast reception status using RRC signaling. This can, for example, reduce the processing load used by the UE's PDCP.

[0272] Another example of PDCP operation in multicast may be determined based on the type of RLC entity in the PTP leg. For example, a PDCP using an RLC-AM entity in the PTP leg may operate similarly to a PDCP in AM DRB. This can, for example, improve reliability in multicast.

[0273] As another example, the operation of the PDCP may be determined based on the type of RLC entity in the PTM leg. For example, a PDCP using an RLC-UM entity in the PTM leg may operate similarly to a PDCP in a UM DRB. This can, for example, reduce the processing load required for multicast.

[0274] As another example regarding the operation of PDCP in multicast, the PDCP SN may be 18 bits. This enables, for example, an increase in buffer capacity such as reordering, and as a result, long-term buffering of reordering waiting data becomes possible.

[0275] As another example, the PDCP SN may be 12 bits. This enables, for example, reduction of the PDCP header size, and as a result, improvement of the throughput in multicast becomes possible.

[0276] As another example, other numbers of bits may be given to the PDCP SN. For example, the PDCP SN may be 10 bits. This makes, for example, padding in the PDCP header unnecessary (see Non-Patent Document 27 (TS38.323)), and as a result, improvement of the throughput in multicast becomes possible.

[0277] The base station may determine the number of bits of the PDCP SN and notify the UE. This enables, for example, improvement of the flexibility in the communication system.

[0278] Another example of PDCP operation in multicast is the provision of sublayers within the PDCP. For example, common operations for PDCPs using RLC-AM entities and PDCPs using RLC-UM entities may be provided in the common sublayer, while different operations for PDCPs using RLC-AM entities and PDCPs using RLC-UM entities may be provided in the individual sublayers. Functions provided in the common layer may include, for example, discarding duplicate PDCP PDUs, reordering, header compression, or integrity protection. Functions provided in the individual layers may include, for example, recognizing missing PDCPs or generating PDCP status reports. Different individual layers may be connected to different RLC entities at the UE and / or base station. This can, for example, avoid complexity in the design of the communication system.

[0279] This modified example 1 enables a flexible PDCP configuration based on the multicast configuration.

[0280] Embodiment 2. Multicast using PTM legs and PTP legs may be used in the DC.

[0281] However, when applying this multicast to a data center (DC), the architecture and configuration methods are not disclosed in the standards and other documents established to date, including the aforementioned Non-Patent Documents 1 to 33. Therefore, there is a risk of malfunctions occurring between the base station and the UE (Unified Element User) when using multicast with a DC.

[0282] This second embodiment discloses a solution to the aforementioned problems.

[0283] To solve the aforementioned problems, the communication system according to this embodiment sets the PTM leg and the PTP leg to the same base station in the DC. This base station may be, for example, a master base station (also called an MN (Master Node)) or a secondary base station (also called an SN (Secondary Node)).

[0284] Figure 20 shows the multicast architecture in a data center. In Figure 20, the secondary base station has the SDAP layer and the PDCP layer, and both the PTM leg and the PTP leg are also held by the secondary base station (SN).

[0285] In the example shown in Figure 20, multicast control may be performed by the master base station (MN). This can reduce the processing load on the secondary base station, for example. As another example, multicast control may be performed by the secondary base station. This can also reduce the processing load on the master base station, for example.

[0286] The base station where the multicast PDCP layer is located may be different from the base station where the RLC layer and below are located. For example, the multicast PDCP layer may be located at the master base station, and the multicast RLC layer and below may be located at the secondary base station. Alternatively, the multicast PDCP layer may be located at the secondary base station, and everything except the multicast RLC layer and below may be located at the master base station. This can, for example, improve the flexibility of the communication system.

[0287] Figure 21 shows another example of a multicast architecture in a data center. In Figure 21, the master base station has the SDAP layer and PDCP layer, while the secondary base station has both the PTM leg and the PTP leg.

[0288] In the example shown in Figure 21, the master base station and MB-UPF may be connected to each other. The master base station may also control multicast. This can, for example, reduce the processing load on secondary base stations.

[0289] Other solutions are disclosed. In a data center, the PTM leg and the PTP leg may be located at different base stations. For example, the PTM leg may be located at the master base station and the PTP leg at the secondary base station, or the PTP leg may be located at the master base station and the PTM leg at the secondary base station. This allows for, for example, distribution of the load on base stations due to multicast, and as a result, an increase in the number of EUs that can be accommodated in the communication system.

[0290] A multicast PDCP layer may be provided on the master base station. This allows, for example, the master base station to quickly configure RRC settings for the UE.

[0291] Figure 22 shows another example of a multicast architecture in a data center. In Figure 22, the master base station has the SDAP layer and the PDCP layer. The master base station also has the PTM leg, and the secondary base station has the PTP leg.

[0292] In the example shown in Figure 22, the master base station and MB-UPF may be connected to each other. The master base station may also control multicast. This can, for example, reduce the processing load on secondary base stations.

[0293] As another example, a multicast PDCP layer may be provided at the secondary base station. This can, for example, reduce the processing load at the master base station.

[0294] Figure 23 shows another example of a multicast architecture in a data center. In Figure 23, the SDAP layer and PDCP layer are located on the secondary base station. Additionally, the PTM leg is located on the master base station, and the PTP leg is located on the secondary base station.

[0295] In the example shown in Figure 23, the secondary base station and MB-UPF may be connected to each other. This can reduce latency in multicast transmission, for example. The master base station may control multicast. This can reduce the workload on the secondary base station, for example.

[0296] A base station may notify the UE of the configuration of a multicast bearer configuration. The base station may be, for example, a master base station. For example, RRC signaling may be used for this notification. For example, RRC Reconfiguration signaling may be used. The configuration may be the establishment, addition, modification, switching, or deletion of a multicast bearer configuration. Adding a bearer configuration may be, for example, the addition of a PTM leg and / or a PTP leg, the addition of a new bearer accompanying the addition of a new multicast channel, or the addition of QoS flows related to the newly added multicast channel to an existing bearer. Modifying a bearer configuration may be, for example, a modification of parameters related to the bearer configuration. Switching a bearer configuration may be, for example, the switching of a base station having a PTM / PTP leg, or the switching of a base station having an SDAP layer or a PDCP layer. Deleting a bearer configuration may, for example, involve deleting a bearer related to multicast, deleting PTM legs and / or PTP legs, or deleting QoS flows related to multicast channels.

[0297] The signaling may include information about the type of configuration (e.g., establishment, addition, modification, switching, deletion), a combination of logical channel identifiers related to multicast, information about the type of PTM / PTP leg, an identifier for the UE in the PTM leg (e.g., G-RNTI), an identifier for the UE in the PTP leg (e.g., C-RNTI), and information about the cell group where each leg transmits and receives data, such as whether it is a master cell group or a secondary cell group. The UE may use this information to switch the multicast bearer configuration. This prevents, for example, misconfiguration of the bearer by the UE, and as a result prevents multicast malfunctions.

[0298] The master base station may notify the secondary base station of the configuration of the bearer configuration. The signaling may be, for example, an Xn signaling. The Xn signaling may be, for example, an S-Node Modification Request (see Non-Patent Document 30 (TS38.423)). The configuration may be the establishment, addition, modification, switching, or deletion of a multicast bearer configuration. This allows, for example, the secondary base station to quickly understand the configuration of the bearer configuration.

[0299] Figure 24 is a sequence diagram of the configuration operation for a multicast bearer configuration. In Figure 24, the master base station (MN) is equipped with a PTM leg. Figure 24 shows an example of a base station equipped with a PTP leg switching from a master base station to a secondary base station (SN). In Figure 24, the same step numbers are used for processes common to Figure 14, and common explanations are omitted.

[0300] Steps ST1433 to ST1445 shown in Figure 24 are the same as those in Figure 14.

[0301] In step ST2447 shown in Figure 24, the MN decides to switch the PTP leg from the MN to the SN. The conditions used for this decision may be, for example, the same as those disclosed in Embodiment 1, or the switching may be determined using the notification from the UE disclosed in Embodiment 1.

[0302] In step ST2449 shown in Figure 24, the MN notifies the SN of the leg's route switching. This notification may be signaled, for example, by an S-Node Modification Request (see Non-Patent Document 30 (TS38.423)). In step ST2451, the SN notifies the MN of its response to step ST2449. In the example shown in Figure 24, an affirmative response to step ST2449 is notified.

[0303] In step ST2455 shown in Figure 24, the MN notifies the UE of the PTP leg route switch. This notification may include, for example, RRC Reconfiguration signaling. The notification may include information indicating that the PTP leg route is being switched from the MN to the SN, and may also include settings for the PTP leg after the switch to the SN (e.g., RLC settings, MAC settings, PHY settings). The UE reconfigures the PTP leg in response to step ST2455. In step ST2459, the UE notifies the MN of a PDCP status report. In step ST2461, the UE notifies the MN of the completion of the RRC reconfiguration. In step ST2463, the MN notifies the SN of the completion of the RRC reconfiguration for the secondary base station at the UE. In step ST2465, the MN notifies the SN of the sequence number status.

[0304] In step ST2467 shown in Figure 24, multicast data is sent from MB-UPF to MN. In step ST2469, MN forwards the multicast data to SN. In step ST2471, SN sends multicast data to UE. The multicast data transmission in step ST2471 is performed using PTP legs.

[0305] In step ST2473 shown in Figure 24, the leg transmitting multicast switches from PTP to PTM. This switching may be performed, for example, in the same manner as disclosed in Embodiment 1. For example, the MN may decide to switch when the PDCP PDU transmitted to the UE using the PTP leg is the same as or earlier than the PDCP PDU transmitted to other UEs using the PTM leg, i.e., the PDCP SN (Sequence Number) of the PDCP PDU transmitted using the PTP leg is equal to or greater than the PDCP SN of the PDCP PDU transmitted using the PTM leg. The MN may notify the SN of this switching. This notification may be performed, for example, using the Xn interface. Upon receiving this notification, the SN may discard the multicast data stored in the buffer. This can, for example, reduce the memory usage of the SN. As another example, the SN may notify the MN of information regarding multicast data that has been confirmed for transmission to the UE. The notification may include information about the received RLC SN, information about the PDCP SN, or information about the NR-U sequence number disclosed in Non-Patent Document 31 (TS38.425). This allows, for example, the MN to quickly know the multicast data that has been sent to the UE. The MN may notify the UE of the switchover. This notification may be made in the same manner as in step ST1441. In step ST2475, multicast data is sent from the MB-UPF to the MN. In step ST2477, the MN sends multicast data to the UE. The multicast data transmission in step ST2477 is performed using a PTM leg.

[0306] A base station may switch the multicast bearer configuration using the load status at its own base station, or it may switch using the received signal strength and / or received quality report of the downlink signal at the UE, or it may switch using the received signal strength and / or received quality of the uplink signal from the UE.

[0307] The master base station may notify the AMF of information regarding each cell of the secondary base station, for example, information regarding the coverage of each cell. The AMF may notify the MB-SMF of this information, or may request information regarding the multicast service area. The MB-SMF may notify the AMF of information regarding whether each cell of the secondary base station is within the multicast service area, or may notify the AMF of information regarding the multicast service area. The AMF may use this information to determine whether each cell of the secondary base station is within the multicast service area. The AMF may notify the master base station of the result of this determination. The master base station may notify the secondary base station of information regarding whether multicast transmission is permitted. This information regarding transmission permission may be provided for each cell. The secondary base station may use this information to transmit multicast or not. This makes it possible, for example, to prevent multicast transmission by the secondary base station outside the service area.

[0308] As another example, the master base station may make the determination. The master base station may make the determination using information about the multicast service area from the MB-SMF and / or coverage information for each cell of the secondary base stations. The master base station may notify the AMF of the determination result. This can, for example, reduce the processing load on the AMF.

[0309] This second embodiment enables multicast even in a data center (DC). Furthermore, it enables load balancing through multicast in a DC.

[0310] Embodiment 3. In a base station with a CU / DU separation configuration, multicast transmissions that switch between PTM and PTP may be performed. For example, the PTM leg and the PTP leg may be located on the same DU.

[0311] Figure 25 shows the multicast architecture at a base station with a CU / DU separation configuration. In Figure 25, the same DU has both the PTM leg and the PTP leg.

[0312] As another example, the PTM leg and the PTP leg may be located on different DUs. This allows for load balancing in the DU via multicast, for example.

[0313] Figure 26 shows another example of a multicast architecture in a base station with a CU / DU separation configuration. In Figure 26, DU#1 has the PTM leg and DU#2 has the PTP leg.

[0314] The CU may notify the DU of information regarding multicast configuration. For example, the F1 interface may be used for such notification. Examples of such information are disclosed below (A) to (G).

[0315] (A) Information indicating that it is multicast.

[0316] (B) Information regarding wireless bearers used for multicast.

[0317] (C) Information regarding multicast QoS.

[0318] (D) Information regarding the legs set in the DU.

[0319] (E) Information regarding PTM / PTP switching instructions.

[0320] (F) Information regarding the switching conditions for PTM / PTP.

[0321] (G) A combination of (A) to (F) as described above.

[0322] The information in (A) above may include, for example, information indicating whether or not it is a multicast, or information for identifying a multicast, such as a multicast identifier. Based on (A) above, for example, the DU can identify multiple multicasts.

[0323] The information in (B) above may be, for example, an MRB-ID. The information in (B) above allows, for example, the DU to identify the bearers necessary for multicast transmission.

[0324] The information in (C) above may be, for example, 5QI (5G QoS Identifier) ​​(see Non-Patent Document 21 (TS23.501)). The information in (C) above enables the DU to perform optimal scheduling based on QoS.

[0325] The information in (D) above may include information indicating whether it is a PTM leg or a PTP leg, information about the logical channel using the leg (e.g., a logical channel identifier), information about the RLC used in the leg, such as information about the type of RLC entity, information about the MAC, or information about the physical layer. The information in (D) above allows, for example, the DU to configure a leg for multicast transmission.

[0326] The information in (E) above may include, for example, information about the leg after the switchover. The information in (E) above allows, for example, the DU to reduce the processing load in the PTM / PTP switchover.

[0327] The information in (F) above may include, for example, information about the conditions for switching from a PTM leg to a PTP leg, or information about the conditions for switching from a PTP leg to a PTM leg. The information about the switching conditions may include, for example, the information in (1) to (5) above disclosed as the conditions under which the UE sends a PDCP status report in Embodiment 1, or it may include information about predetermined values, ranges, number of times, and / or periods in (1) to (4) above. The DU may use this information to switch between PTM and PTP legs. The information in (F) above allows, for example, the DU to quickly perform the PTM / PTP switching.

[0328] The DU may notify the CU of information regarding the UE receiving multicast. For example, the F1 interface may be used for this notification. Examples of such information are disclosed below (a) to (e).

[0329] (a) Information regarding UEs using PTM legs.

[0330] (b) Information regarding UE using PTP legs.

[0331] (c) Information regarding UE related to PTM / PTP switching.

[0332] (d) Information regarding the values ​​used in the conditional judgments described in (1) to (5) above.

[0333] (e) A combination of (a) to (d) above.

[0334] The aforementioned (a) may include information regarding the number and / or identifier of UEs that perform multicast reception using PTM legs. The aforementioned (a) allows, for example, the CU to know the number of UEs using PTM legs, and as a result, to quickly decide whether to switch between PTM and PTP.

[0335] The aforementioned (b) may include information regarding the number and / or identifiers of UEs that perform multicast reception using PTP legs. The aforementioned (b) allows, for example, the CU to identify UEs using PTP legs, and as a result, to quickly determine when to switch from PTP legs to PTM legs.

[0336] The aforementioned (c) may include information indicating that the PTM / PTP switching conditions have been met, information about the UE that has met the PTM / PTP switching conditions (e.g., an identifier), or information about the direction of the switching (e.g., from a PTM leg to a PTP leg, or from a PTP leg to a PTM leg). The aforementioned (c) allows the CU to quickly identify which UEs should or will perform a PTM / PTP switch.

[0337] The aforementioned (d) may include information regarding the number of PDCP PDUs for which delivery confirmation with the UE has not been obtained, information regarding the percentage of PDCP PDUs for which delivery confirmation with the UE has not been obtained, information regarding the number of PDCP PDUs for which delivery confirmation with the UE has not been obtained consecutively, information regarding the expiration of a timer used in the PDCP layer, such as the t-reordering timer, information regarding the number of RLC PDUs for which delivery confirmation with the UE has not been obtained, information regarding the percentage of RLC PDUs for which delivery confirmation with the UE has not been obtained, information regarding the number of RLC PDUs for which delivery confirmation with the UE has not been obtained consecutively, information regarding the expiration of a timer used in the RLC layer, such as the t-reassembly timer, information regarding the number of HARQ retransmissions exceeded at the UE, information regarding the number of HARQ retransmissions exceeded at the UE within a predetermined period, or information regarding the number of HARQ retransmissions exceeded between a predetermined number of transport block transmissions. The CU may use this information to determine whether to switch between PTM and PTP. This eliminates the need for notification from the UE to the CU, and as a result, the CU can make a quick decision regarding the switchover.

[0338] Multicast transmissions that switch between PTM and PTP may be used in base stations where the CU for C-plane (CU-CP) and the CU for U-plane (CU-UP) are separated. For example, the same DU may be used for transmitting C-plane and U-plane data. Alternatively, different DUs may be used for transmitting C-plane and U-plane data. This can, for example, reduce the load on the DU.

[0339] For example, the PTM leg and the PTP leg may be located on the same DU. This can, for example, avoid complexity in the control of the DU. As another example, the PTM leg and the PTP leg may be located on different DUs. This can, for example, reduce the load on the DU.

[0340] Figure 27 shows another example of a multicast architecture in a base station with a CU / DU separation configuration. In Figure 27, the base station's CU is divided into CU-CP and CU-UP. DU#0 has the leg related to the C plane, DU#1 has the PTM leg of the U plane, and DU#2 has the PTP leg.

[0341] The CU-CP may notify the CU-UP of information regarding multicast configuration. For example, the E1 interface may be used for this notification. This information may include, for example, the information described in (A) to (G) above. This will, for example, achieve the same effect as described above. This information may include information about the DU being used, for example, the DU identifier. This information about the DU may include, for example, information used in the PTM leg and information used in the PTP leg. This will, for example, enable the CU-UP to quickly identify the DU.

[0342] The CU-UP may notify the CU-CP of information regarding the UE receiving multicast. For example, the E1 interface may be used for this notification. This information may include, for example, the information described in (a) to (e) above. This will produce, for example, the same effect as described above.

[0343] This third embodiment enables multicast transmission from a base station with a CU / DU separation configuration.

[0344] Embodiment 4. 5G base stations can support Integrated Access and Backhaul (IAB) (see Non-Patent Document 16 (TS38.300 V16.2.0)). That is, multicast can be performed using base stations that support IAB (hereinafter sometimes referred to as IAB base stations). However, how multicast is performed using IAB base stations is not disclosed in the standards and other documents established to date, including Non-Patent Documents 1 to 33 mentioned above. Therefore, a problem arises in that multicast cannot be performed using IAB base stations.

[0345] Therefore, in this fourth embodiment, a method for solving the aforementioned problem is disclosed. In the following description, the CU and DU of a base station operating as an IAB donor will be referred to as IAB donor CU and IAB donor DU, respectively.

[0346] To solve the aforementioned problems, in the communication system according to this embodiment, the IAB donor DU and / or IAB node perform multicast transmission to the IAB node and / or UE. All IAB donor DUs and IAB nodes may perform multicast transmission.

[0347] Figure 28 is a connection diagram for multicast from base stations that make up the IAB. In Figure 28, the IAB donor CU and IAB donor DU are connected by wire. The IAB donor DU performs multicast transmission to the IAB node and UE#3. Multicast transmission from the IAB donor DU may be performed using PTP or PTM. The IAB node performs multicast transmission to UE#1 and UE#2. Multicast transmission from the IAB node may be performed using PTP or PTM.

[0348] Figure 29 is a protocol stack diagram for multicast transmission from base stations constituting the IAB to the UE. The L1, L2, and IP layers terminate between the IAB donor CU and the IAB donor DU. IP routing is performed at the IAB donor DU. The PHY, MAC, RLC, BAP (Backhaul Adaptation Protocol), and IP layers terminate between the IAB donor DU and the IAB node. The UDP (User Datagram Protocol) and GTP-U (GPRS Tunneling Protocol for User Plane) layers terminate between the IAB donor CU and the IAB node. The PHY, MAC, and RLC layers terminate between the IAB node and the UE. The PDCP and SDAP layers terminate between the IAB donor CU and the UE.

[0349] Only some IAB donor DUs and / or IAB nodes may perform multicast transmission. In such multicast transmission, PTM legs or PTP legs may be used. The IAB donor CU may determine which IAB donor DUs and / or IAB nodes will perform multicast transmission. The IAB donor DUs and / or IAB nodes may have information regarding their ability to perform multicast transmission. This information may, for example, be included in the capabilities of the DU and / or node. The IAB donor DUs and / or IAB nodes may notify the IAB donor CU of this information. The IAB donor CU may use this information to determine which nodes will perform multicast transmission. The IAB donor CU may configure multicast transmission for the IAB donor DUs and / or IAB nodes. This can, for example, improve the flexibility of the communication system.

[0350] Another example of a scenario where only some IAB donor DUs and / or IAB nodes perform multicast transmissions is one where only IAB donor DUs and / or IAB nodes that do not have any IAB nodes connected to them perform multicast transmissions. Such multicast transmissions may, for example, be multicast transmissions using PTM legs. This can, for example, avoid the complexity of multicast in IABs.

[0351] IAB donor DUs and / or IAB nodes that do not have any IAB nodes connected to them may perform multicast transmissions. Such multicast transmissions may, for example, use PTP legs. This makes it possible to perform multicast transmissions to many UEs, for example.

[0352] In multicast transmissions within the IAB, the PTM leg and the PTP leg may share the same path. This avoids, for example, the complexity of multicast control.

[0353] As another example, the paths through the multicast PTM legs and the paths through the PTP legs may be different. This can, for example, improve the flexibility of the communication system and reduce the load on the IAB nodes.

[0354] Figure 30 shows another example of multicast connectivity from base stations constituting the IAB. In Figure 30, the IAB donor CU and IAB donor DU#1, and the IAB donor CU and IAB donor DU#2 are both connected by wire. Multicast data for PTM is sent from IAB donor DU#1 to IAB node #1. Multicast data for PTP is sent from IAB donor DU#2 to IAB node #2. Multicast data for PTM is sent from IAB node #1 to IAB node #3. Multicast data for PTP is sent from IAB node #2 to IAB node #3. IAB node #3 performs multicast transmission to UE#1 to UE#3. IAB node #3 sends multicast data for PTM to UE#1 and UE#2. IAB node #3 sends multicast data for PTP to UE#3.

[0355] This fourth embodiment enables multicast transmission from base stations that support IAB.

[0356] Embodiment 5. Packet duplication may be used in multicast transmission. For example, packet duplication may be used in the configurations disclosed in Embodiments 1 to 4. The UE may receive PDCP PDUs transmitted from both the PTM leg and the PTP leg. The UE may keep only the PDCP PDUs that arrived first and discard the PDCP PDUs of the same PDCP SN that arrived later.

[0357] In multicast, packet duplication using CA may be used. Different cells may be used for multicast transmission and reception using PTM legs and multicast transmission and reception using PTP legs. This allows for improved reliability of multicast transmission through frequency diversity, even when the same base station, DU, and / or IAB node is used for both the PTM and PTP legs.

[0358] In multicast, packet duplication using a DC may be used. Multicast transmission using PTM and multicast transmission using PTP may be performed using different base stations, different DUs, or different IAB nodes. This allows for, for example, the effect of spatial diversity in multicast, and as a result, reliability in multicast can be improved.

[0359] Multiple PTM legs may be provided. Multiple PTP legs may be provided. Packet duplication combining DC and CA may be used in multicast. For example, one PTM leg and one PTP leg may be provided at the master base station and one at the secondary base station, or one base station may have a PTM leg and another base station may have multiple PTP legs. This allows for the effects of both frequency diversity and spatial diversity in multicast, for example, and as a result, the reliability of multicast can be improved.

[0360] This embodiment 5 makes it possible to improve reliability in multicast.

[0361] In this disclosure, the UE from which the service data originates is designated as UE-TX. For example, if UE-TX is UE1 and UE-RX is UE2, and service data originates in UE2 and is sent to UE1, then it is preferable to designate UE2 as UE-TX and UE1 as UE-RX and apply the method described in this disclosure. This will achieve the same effect.

[0362] The embodiments and their variations described above are merely illustrative, and these embodiments and their variations can be freely combined. Furthermore, any component of each embodiment and its variations can be modified or omitted as appropriate.

[0363] For example, in the embodiments and their modifications described above, a subframe is an example of a time unit for communication in a fifth-generation communication system. A subframe may also be a scheduling unit. In the embodiments and their modifications described above, the processing described as being performed in subframe units may also be performed in TTI units, slot units, sub-slot units, or mini-slot units.

[0364] For example, the methods disclosed in each of the embodiments and their variations described above may be applied not only to V2X (Vehicle-to-everything) services but also to services that use SL communication. For example, they may be applied to SL communication used in various services such as proximity-based services, public safety, communication between wearable devices, and communication between machines in factories.

[0365] Although this disclosure has been described in detail, the above description is illustrative and not limiting in all respects. It is understood that countless variations not illustrated are conceivable. [Explanation of Symbols]

[0366] 200,210 Communication system, 202 Communication terminal equipment (mobile terminal), 203,207,213,217,223-1,224-1,224-2,226-1,226-2,750 Base station equipment (base station), 204 MME / S-GW section (MME section), 204a MME, 214 AMF / SMF / UPF section (5GC section), 218 Central unit, 219 Distributed unit, 301,403 Protocol processing section, 302 Application section, 303,404 Transmit data buffer section, 304,405 Encoder section, 305,406 Modulation section, 306,407 Frequency conversion section, 307-1~307-4,408-1~408-4 Antenna, 308,409 Demodulation section, 309,410 Decoder section, 310, 411, 506, 526 Control section, 401 EPC communication section, 402 Other base station communication section, 412 5GC communication section, 501 PDN GW communication section, 502, 522 Base station communication section, 503, 523 User plane communication section, 504 HeNBGW communication section, 505, 525 Control plane control section, 505-1, 525-1 NAS security section, 505-2 SAE bearer control section, 505-3, 525-3 Idle state mobility management section, 521 Data Network communication section, 525-2 PDU session control section, 527 Session management section, 751-1~751-8 Beam.

Claims

1. A user device that, in multicast mode, sends a PDCP (Packet Data Convergence Protocol) status report to the base station. The first information regarding the reception status of the multicast is transmitted to the base station using the PDCP status report. User device.

2. A second piece of information regarding the switching between PTM (Point-to-Multipoint) and PTP (Point-to-Point) is notified using RRC (Radio Resource Control) signaling. The PTM / PTP switching is performed using the second information described above. The user device according to claim 1.

3. Both PTM and PTP can be received. The base station receives multicast data using the PTM leg and / or PTP leg of the PTP determined by the base station. The PTM leg and / or the PTP leg are dynamically switched. The user device according to claim 2.

4. When the PDCCH (Physical Downlink Control Channel) is decoded using the first RNTI (Radio Network Temporary Identifier), the multicast data is received by the PTP leg, and when the PDCCH is decoded using the second RNTI, the multicast data is received by the PTM leg. The user device according to claim 3.

5. When the base station has a CU (Central-Unit) / DU (Distributed-Unit) separation configuration, the DU can provide either the PTM or the PTP. The multicast data is received by the PTM leg and / or PTP leg determined by the DU. The user device according to claim 3.

6. The PTM leg and the PTP leg are configured as the master base station. The multicast data is received using the PTM leg and / or the PTP leg. The user device according to claim 3.

7. The first information includes information regarding missing data units in the PDCP status report. The user device according to claim 1.

8. The user device sends a PDCP (Packet Data Convergence Protocol) status report to the base station in multicast mode. The user device transmits first information regarding the reception status of the multicast to the base station using the PDCP status report. Communication system.

9. In multicast, a PDCP (Packet Data Convergence Protocol) status report is notified. The first information regarding the reception status of the multicast is notified using the PDCP status report. Based on the first piece of information, the second piece of information regarding the switching between PTM (Point-to-Multipoint) and PTP (Point-to-Point) is notified using RRC (Radio Resource Control) signaling. Base station.

Images