Communication method and user device

Abstract

A communication method according to a first embodiment is used by user equipment to perform, using a radio network temporary identifier (RNTI), processing for reception of a physical downlink control channel (PDCCH) from a base station. The method includes, when N (N ≥ 2) number of group RNTI (G-RNTI) are associated with a single multicast broadcast service (MBS) session, specifying M (M ≤ N) number of G-RNTI, from among N (N ≥ 2) number of G-RNTI, to be used for the processing for reception, and performing the processing for reception using the M number of G-RNTI.

Description

[Technical Field]

[0001] The present disclosure relates to a communication method for use in a mobile communication system. [Background technology]

[0002] The 3GPP (3rd Generation Partnership Project) standard defines the technical specifications for NR (New Radio), a fifth-generation (5G) radio access technology. Compared to LTE (Long Term Evolution), a fourth-generation (4G) radio access technology, NR offers higher speed, larger capacity, higher reliability, and lower latency. Discussions are underway within 3GPP to formulate technical specifications for 5G / NR multicast broadcast services (MBS) (see, for example, Non-Patent Document 1). [Prior art documents] [Non-patent literature]

[0003] [Non-Patent Document 1] 3GPP contribution: RP-201038, “WID revision: NR Multicast and Broadcast Services” Summary of the Invention

[0004] A communication method according to a first aspect is a communication method used by a user device that performs reception processing of a physical downlink control channel (PDCCH) from a base station using radio network temporary identifiers (RNTIs), and includes the steps of: when N (N≧2) group RNTIs (G-RNTIs) are associated with one multicast broadcast service (MBS) session, identifying M (M≦N) G-RNTIs to be used for the reception processing from among the N G-RNTIs; and performing the reception processing using the M G-RNTIs.

[0005] A communication method according to a second aspect is a communication method used in a user equipment that performs reception processing of a physical downlink control channel (PDCCH) from a base station using a radio network temporary identifier (RNTI), and includes: performing the reception processing to receive a dedicated traffic channel (DTCH) using a cell RNTI (C-RNTI); performing the reception processing to receive a multicast traffic channel (MTCH) using a group RNTI (G-RNTI); and, if the DTCH and the MTCH are assigned the same logical channel identifier (LCID), identifying the logical channel to which received data obtained in response to the reception processing belongs based on the RNTI used for the reception processing.

[0006] A communication method according to a third aspect is a communication method used in a mobile communication system, comprising: a base station transmitting, on a multicast control channel (MCCH), configuration information used for receiving a multicast traffic channel (MTCH); and the base station transmitting, at a predetermined timing, a notification regarding a change in the content of the MCCH to a user device on a physical downlink control channel (PDCCH). The transmitting includes, if there is no change, transmitting the notification indicating that there is no change. [Brief explanation of the drawings]

[0007] [Figure 1] 1 is a diagram showing a configuration of a mobile communication system according to a first embodiment. [Figure 2] 1 is a diagram illustrating a configuration of a UE (user equipment) according to a first embodiment. [Figure 3] A diagram showing the configuration of a gNB (base station) according to the first embodiment. [Figure 4] FIG. 10 is a diagram showing the configuration of a protocol stack of a radio interface of a user plane that handles data. [Figure 5] FIG. 1 is a diagram showing the configuration of a protocol stack of a radio interface of a control plane that handles signaling (control signals). [Figure 6]FIG. 1 is a diagram illustrating an overview of MBS traffic distribution according to a first embodiment. [Figure 7] FIG. 3 is a diagram illustrating distribution modes according to the first embodiment. [Figure 8] FIG. 2 is a diagram showing a split multicast radio bearer (MRB) according to the first embodiment. [Figure 9] FIG. 10 is a diagram illustrating a correspondence (mapping) between a group RNTI (G-RNTI) and an MBS session. [Figure 10] 1 is a diagram showing the correspondence (mapping) between G-RNTI, multicast radio bearer (MRB) / multicast traffic channel (MTCH), quality of service (QoS) flow, and MBS session. [Figure 11] FIG. 4 is a diagram illustrating an example of an operation according to the first embodiment. [Figure 12] FIG. 10 is a diagram illustrating internal processing of a UE according to the second embodiment. [Figure 13] FIG. 10 is a diagram illustrating an example of an operation according to the second embodiment. [Figure 14] FIG. 10 is a diagram illustrating internal processing of a UE according to a modification of the second embodiment. [Figure 15] FIG. 11 is a diagram illustrating an example of an operation according to the third embodiment. [Figure 16] FIG. 11 is a diagram illustrating a modified example of the operation according to the third embodiment. [Figure 17] FIG. 13 shows an overview of the Stage 2 control plane aspects of the distributed mode. [Figure 18] FIG. 10 is a diagram showing one-step setting of distribution mode 2. [Figure 19] A diagram showing LTE MBMS interest indication (excluding ROM-related settings). [Figure 20] A diagram showing the contents of SIB13 of LTE. [Figure 21] A diagram showing the contents of SIB13 of LTE. [Figure 22] A diagram showing the contents of SIB13 of LTE. [Figure 23] A diagram showing the contents of SIB15 of LTE. [Figure 24] A diagram showing the contents of SIB20 in LTE. [Figure 25] FIG. 1 is a diagram showing the contents of the SC-MCCH of LTE. [Figure 26] FIG. 1 is a diagram showing the contents of the SC-MCCH of LTE. [Figure 27] FIG. 1 is a diagram showing the contents of the SC-MCCH of LTE. [Figure 28] A diagram showing the contents of MBMS interest indication in LTE. [Figure 29] A diagram showing the contents of MBMS interest indication in LTE. [Figure 30] A diagram showing the contents of MBMS interest indication in LTE. [Figure 31] FIG. 1 is a diagram illustrating the priority of cell reselection for eMBMS frequencies in LTE. [Figure 32] Figure 10 illustrates intra-frequency cell level prioritization and equal priority intra-frequency cell reselection in NB-IoT for CE (including eMTC) and LTE for UE. [Figure 33] A figure showing an example in which QoffsetSCPTM is set as the SCPTM frequency offset in SIB5. [Figure 34] A diagram showing UE function scptm-ParallelReception-r13 in LTE SC-PTM. [Figure 35] FIG. 10 illustrates DRX parameters for PTM transmission via distribution mode 1. [Figure 36] FIG. 10 illustrates DRX parameters for PTM transmission via distribution mode 2. DETAILED DESCRIPTION OF THE INVENTION

[0008] It is expected that 5G / NR multicast broadcast services will provide improved services compared to 4G / LTE multicast broadcast services.

[0009] Therefore, the present disclosure provides a communication method that enables an improved multicast broadcast service.

[0010] A mobile communication system according to an embodiment will be described with reference to the drawings. In the description of the drawings, the same or similar parts are denoted by the same or similar reference numerals.

[0011] [First embodiment]

[0012] (Configuration of a mobile communication system) FIG. 1 is a diagram showing the configuration of a mobile communication system according to a first embodiment. The mobile communication system 1 conforms to the 3GPP standard 5th Generation System (5GS). In the following description, 5GS is used as an example, but the mobile communication system may also be at least partially applied to an LTE (Long Term Evolution) system. The mobile communication system may also be at least partially applied to a sixth generation (6G) system.

[0013] The mobile communication system 1 includes a user equipment (UE) 100, a 5G radio access network (NG-RAN) 10, and a 5G core network (5GC) 20. Hereinafter, the NG-RAN 10 may be simply referred to as the RAN 10. The 5GC 20 may be simply referred to as the core network (CN) 20.

[0014] The UE 100 is a mobile wireless communication device. The UE 100 may be any device that is used by a user. For example, the UE 100 is a mobile phone terminal (including a smartphone), a tablet terminal, a notebook PC, a communication module (including a communication card or a chipset), a sensor or a device provided in a sensor, a vehicle or a device provided in a vehicle (Vehicle UE), or an aircraft or a device provided in an aircraft (Aerial UE).

[0015] The NG-RAN 10 includes a base station (called "gNB" in the 5G system) 200. The gNBs 200 are connected to each other via an Xn interface, which is an interface between base stations. The gNB 200 manages one or more cells. The gNB 200 performs wireless communication with a UE 100 that has established a connection with its own cell. The gNB 200 has a radio resource management (RRM) function, a routing function for user data (hereinafter simply referred to as "data"), a measurement control function for mobility control and scheduling, etc. The term "cell" is used to indicate the smallest unit of a wireless communication area. The term "cell" is also used to indicate a function or resource that performs wireless communication with a UE 100. One cell belongs to one carrier frequency (hereinafter simply referred to as "frequency").

[0016] In addition, gNBs can also connect to the Evolved Packet Core (EPC), which is the LTE core network. LTE base stations can also connect to 5GC. LTE base stations and gNBs can also be connected via a base station-to-base station interface.

[0017] The 5GC20 includes an Access and Mobility Management Function (AMF) and a User Plane Function (UPF) 300. The AMF performs various mobility controls for the UE 100. The AMF manages the mobility of the UE 100 by communicating with the UE 100 using NAS (Non-Access Stratum) signaling. The UPF controls data forwarding. The AMF and UPF are connected to the gNB 200 via an NG interface, which is an interface between a base station and a core network.

[0018] 2 is a diagram showing the configuration of a UE 100 (user equipment) according to the first embodiment. The UE 100 includes a receiving unit 110, a transmitting unit 120, and a control unit 130. The receiving unit 110 and the transmitting unit 120 constitute a wireless communication unit that performs wireless communication with the gNB 200.

[0019] The receiving unit 110 performs various types of reception under the control of the control unit 130. The receiving unit 110 includes an antenna and a receiver. The receiver converts a radio signal received by the antenna into a baseband signal (received signal) and outputs the baseband signal to the control unit 130.

[0020] The transmitting unit 120 performs various transmissions under the control of the control unit 130. The transmitting unit 120 includes an antenna and a transmitter. The transmitter converts a baseband signal (transmission signal) output by the control unit 130 into a radio signal and transmits it from the antenna.

[0021] The control unit 130 performs various controls and processes in the UE 100. Such processes include processes of each layer, which will be described later. The control unit 130 includes at least one processor and at least one memory. The memory stores programs executed by the processor and information used in the processes by the processor. The processor may include a baseband processor and a CPU (Central Processing Unit). The baseband processor performs modulation / demodulation and encoding / decoding of baseband signals. The CPU executes programs stored in the memory to perform various processes.

[0022] 3 is a diagram showing the configuration of the gNB200 (base station) according to the first embodiment. The gNB200 includes a transmitter 210, a receiver 220, a controller 230, and a backhaul communication unit 240. The transmitter 210 and the receiver 220 constitute a wireless communication unit that performs wireless communication with the UE 100. The backhaul communication unit 240 constitutes a network communication unit that performs communication with the CN20.

[0023] The transmission unit 210 performs various transmissions under the control of the control unit 230. The transmission unit 210 includes an antenna and a transmitter. The transmitter converts a baseband signal (transmission signal) output by the control unit 230 into a radio signal and transmits it from the antenna.

[0024] The receiving unit 220 performs various types of reception under the control of the control unit 230. The receiving unit 220 includes an antenna and a receiver. The receiver converts a radio signal received by the antenna into a baseband signal (received signal) and outputs the baseband signal to the control unit 230.

[0025] The control unit 230 performs various controls and processes in the gNB 200. Such processes include processes for each layer, which will be described later. The control unit 230 includes at least one processor and at least one memory. The memory stores programs executed by the processor and information used in the processes by the processor. The processor may include a baseband processor and a CPU. The baseband processor performs modulation / demodulation and encoding / decoding of baseband signals. The CPU executes programs stored in the memory to perform various processes.

[0026] The backhaul communication unit 240 is connected to neighboring base stations via an Xn interface, which is an interface between base stations. The backhaul communication unit 240 is connected to the AMF / UPF 300 via an NG interface, which is an interface between a base station and a core network. Note that the gNB 200 may be configured (i.e., functionally divided) with a CU (Central Unit) and a DU (Distributed Unit), and both units may be connected via an F1 interface, which is a fronthaul interface.

[0027] FIG. 4 is a diagram showing the configuration of a protocol stack of a radio interface of a user plane that handles data.

[0028] The user plane radio interface protocol includes a physical (PHY) layer, a medium access control (MAC) layer, a radio link control (RLC) layer, a packet data convergence protocol (PDCP) layer, and a service data adaptation protocol (SDAP) layer.

[0029] The PHY layer performs encoding / decoding, modulation / demodulation, antenna mapping / demapping, and resource mapping / demapping. Data and control information are transmitted between the PHY layer of UE100 and the PHY layer of gNB200 via a physical channel. The PHY layer of UE100 receives downlink control information (DCI) transmitted from gNB200 on a physical downlink control channel (PDCCH). Specifically, UE100 performs blind decoding of the PDCCH using a radio network temporary identifier (RNTI) and acquires successfully decoded DCI as DCI addressed to the UE. The DCI transmitted from gNB200 has CRC parity bits scrambled by the RNTI added.

[0030] The MAC layer performs data priority control, retransmission processing using Hybrid Automatic Repeat reQuest (HARQ), random access procedures, etc. Data and control information are transmitted between the MAC layer of UE100 and the MAC layer of gNB200 via transport channels. The MAC layer of gNB200 includes a scheduler, which determines the uplink and downlink transport format (transport block size, modulation and coding scheme (MCS)) and the resource blocks to be allocated to UE100.

[0031] The RLC layer transmits data to the RLC layer on the receiving side using the functions of the MAC layer and PHY layer. Data and control information are transmitted between the RLC layer of the UE 100 and the RLC layer of the gNB 200 via logical channels.

[0032] The PDCP layer performs header compression / decompression, encryption / decryption, etc.

[0033] The SDAP layer maps IP flows, which are the units for Quality of Service (QoS) control by the core network, to radio bearers, which are the units for QoS control by the Access Stratum (AS). Note that if the RAN is connected to the EPC, SDAP is not necessary.

[0034] FIG. 5 is a diagram showing the configuration of a protocol stack of a radio interface of a control plane that handles signaling (control signals).

[0035] The protocol stack of the radio interface of the control plane has a Radio Resource Control (RRC) layer and a Non-Access Stratum (NAS) layer instead of the SDAP layer shown in FIG.

[0036] RRC signaling for various settings is transmitted between the RRC layer of UE100 and the RRC layer of gNB200. The RRC layer controls logical channels, transport channels, and physical channels according to the establishment, re-establishment, and release of radio bearers. When there is a connection (RRC connection) between the RRC of UE100 and the RRC of gNB200, UE100 is in an RRC connected state. When there is no connection (RRC connection) between the RRC of UE100 and the RRC of gNB200, UE100 is in an RRC idle state. When the connection between the RRC of UE100 and the RRC of gNB200 is suspended, UE100 is in an RRC inactive state.

[0037] The NAS layer, which is located above the RRC layer, performs session management, mobility management, etc. NAS signaling is transmitted between the NAS layer of the UE 100 and the NAS layer of the AMF 300A. Note that the UE 100 has an application layer and the like in addition to the radio interface protocol. Also, the layer below the NAS layer is called the AS layer.

[0038] (MBS Overview) An overview of the MBS according to the first embodiment will be described. The MBS is a service that enables broadcast or multicast, i.e., point-to-multipoint (PTM) data transmission from the NG-RAN 10 to the UE 100. Possible use cases (service types) of the MBS include public safety communications, mission-critical communications, V2X (Vehicle to Everything) communications, IPv4 or IPv6 multicast distribution, IPTV (Internet Protocol Television), group communications, and software distribution.

[0039] The broadcast service is for applications that do not require highly reliable QoS, and provides service to all UEs 100 within a specific service area. An MBS session used for the broadcast service is called a broadcast session.

[0040] A multicast service provides a service not to all UEs 100 but to a group of UEs 100 participating in the multicast service (multicast session). An MBS session used for a multicast service is called a multicast session. A multicast service can provide the same content to a group of UEs 100 in a more wirelessly efficient manner than a broadcast service.

[0041] FIG. 6 is a diagram showing an outline of MBS traffic distribution according to the first embodiment.

[0042] MBS traffic (MBS data) is distributed from a single data source (application service provider) to multiple UEs. A 5G core network (5GC) 20 receives the MBS data from the application service provider, creates a copy of the MBS data (replication), and distributes it.

[0043] From the 5GC20 perspective, two multicast delivery methods are possible: 5GC Shared MBS Traffic delivery and 5GC Individual MBS Traffic delivery.

[0044] In the 5GC individual MBS traffic delivery method, the 5GC 20 receives a single copy of MBS data packets and delivers individual copies of those MBS data packets to individual UEs 100 via a PDU session for each UE 100. Therefore, one PDU session for each UE 100 needs to be associated with the multicast session.

[0045] In the 5GC shared MBS traffic delivery method, the 5GC 20 receives a single copy of MBS data packets and delivers the single copy of those MBS packets to a RAN node (i.e., the gNB 200). The gNB 200 receives the MBS data packets via an MBS tunnel connection and delivers them to one or more UEs 100.

[0046] From the perspective of the RAN (5G RAN) 10, there are two possible delivery methods for transmitting MBS data over the air in the 5GC shared MBS traffic delivery method: PTP (Point-to-Point) and PTM (Point-to-Multipoint). PTP stands for unicast, and PTM stands for multicast and broadcast.

[0047] In the PTP distribution method, the gNB 200 distributes individual copies of the MBS data packet wirelessly to each UE 100. On the other hand, in the PTM distribution method, the gNB 200 distributes a single copy of the MBS data packet wirelessly to a group of UEs 100. The gNB 200 can dynamically determine whether to use PTM or PTP as the distribution method for MBS data for one UE 100.

[0048] The PTP distribution method and the PTM distribution method are mainly related to the user plane. There are two control modes for MBS data distribution: a first distribution mode and a second distribution mode.

[0049] FIG. 7 is a diagram showing distribution modes according to the first embodiment.

[0050] The first delivery mode (Delivery mode 1: DM1) is a delivery mode that can be used by the UE 100 in the RRC connected state and is a delivery mode for high QoS requirements. The first delivery mode is used for a multicast session among MBS sessions. However, the first delivery mode may also be used for a broadcast session. The first delivery mode may also be available to the UE 100 in the RRC idle state or the RRC inactive state.

[0051] The setting of MBS reception in the first distribution mode is performed by UE-dedicated signaling. For example, the setting of MBS reception in the first distribution mode is performed by an RRC Reconfiguration message (or an RRC Release message), which is an RRC message transmitted by unicast from the gNB 200 to the UE 100.

[0052] The MBS reception configuration includes MBS traffic channel configuration information (hereinafter referred to as "MTCH configuration information") related to the configuration of an MBS traffic channel carrying MBS data. The MTCH configuration information includes MBS session information related to an MBS session and scheduling information for the MBS traffic channel corresponding to this MBS session. The scheduling information for the MBS traffic channel may include a discontinuous reception (DRX) configuration for the MBS traffic channel. The discontinuous reception configuration may include one or more parameters: a timer value (On Duration Timer) defining an on-duration (on duration), a timer value (Inactivity Timer) extending the on-duration, a scheduling interval or DRX cycle (Scheduling Period, DRX Cycle), a start subframe offset value (Start Offset, DRX Cycle Offset) for the scheduling or DRX cycle, a start delay slot value (Slot Offset) for the on-duration timer, a timer value (Retransmission Timer) defining the maximum time until retransmission, and a timer value (HARQ RTT Timer) defining the minimum interval until DL allocation for HARQ retransmission.

[0053] The MBS traffic channel is a type of logical channel and is sometimes referred to as an MTCH. The MBS traffic channel is mapped to a downlink shared channel (DL-SCH), which is a type of transport channel.

[0054] The second delivery mode (Delivery mode 2: DM2) is a delivery mode that can be used not only by the UE 100 in the RRC connected state but also by the UE 100 in the RRC idle state or the RRC inactive state, and is a delivery mode for low QoS requirements. The second delivery mode is used for a broadcast session among MBS sessions. However, the second delivery mode may also be applicable to a multicast session.

[0055] The setting of MBS reception in the second distribution mode is performed by broadcast signaling. For example, the setting of MBS reception in the second distribution mode is performed by a logical channel broadcast from the gNB 200 to the UE 100, such as a broadcast control channel (BCCH) and / or a multicast control channel (MCCH). The UE 100 can receive the BCCH and the MCCH using, for example, a dedicated RNTI predefined in a technical specification. The RNTI for BCCH reception may be SI-RNTI, and the RNTI for MCCH reception may be MCCH-RNTI.

[0056] In the second distribution mode, UE100 may receive MBS data in the following three procedures. First, UE100 receives MCCH configuration information from gNB200 via a SIB (MBS-SIB) transmitted on a BCCH. Second, UE100 receives an MCCH from gNB200 based on the MCCH configuration information. The MCCH transmits the MTCH configuration information. Third, UE100 receives an MTCH (MBS data) based on the MTCH configuration information. Hereinafter, MTCH configuration information and / or MCCH configuration information may be referred to as MBS reception configuration.

[0057] In the first distribution mode and the second distribution mode, the UE 100 may receive the MTCH using a group RNTI (G-RNTI) assigned by the gNB 200. The G-RNTI corresponds to an RNTI for MTCH reception. The G-RNTI may be included in the MBS reception configuration (MTCH configuration information).

[0058] The network can provide different MBS services for each MBS session. An MBS session is identified by at least one of a Temporary Mobile Group Identity (TMGI), a source-specific IP multicast address (consisting of a source unicast IP address of an application function, application server, etc., and an IP multicast address indicating the destination address), a session identifier, and a G-RNTI. At least one of the TMGI, the source-specific IP multicast address, and the session identifier is called an MBS session identifier. The TMGI, the source-specific IP multicast address, the session identifier, and the G-RNTI are collectively called MBS session information.

[0059] 8 is a diagram illustrating a split multicast radio bearer (MRB) according to the first embodiment. The MRB may be a type of data radio bearer (DRB). The split MRB may be used in the first delivery mode described above.

[0060] The gNB200 can configure the UE100 with an MRB separated into a PTP communication path and a PTM communication path. This allows the gNB200 to dynamically switch the transmission of MBS data to the UE100 between PTP (PTP communication path) and PTM (PTM communication path). Alternatively, the gNB200 can improve reliability by dual-transmitting the same MBS data using both PTP (PTP communication path) and PTM (PTM communication path). Hereinafter, the PTP communication path will be referred to as a PTP leg, and the PTM communication path will be referred to as a PTM leg. Furthermore, the functional units corresponding to each layer will be referred to as entities.

[0061] The predetermined layer that terminates splitting is the MAC layer (HARQ), the RLC layer, the PDCP layer, or the SDAP layer. In the following, an example in which the predetermined layer that terminates splitting is the PDCP layer will be mainly described, but the predetermined layer may be the MAC layer (HARQ), the RLC layer, or the SDAP layer.

[0062] The PDCP entity of the gNB 200 and the PDCP entity of the UE 100 each separate an MRB, which is a bearer (data radio bearer) used for MBS, into a PTP leg and a PTM leg. Note that a PDCP entity is provided for each bearer.

[0063] Each of the gNB 200 and the UE 100 has two RLC entities, one MAC entity, and one PHY entity, each of which is provided for each leg. A PHY entity may be provided for each leg. In the case of dual connectivity in which the UE 100 communicates with two gNBs 200, the UE 100 may have two MAC entities.

[0064] The PHY entity transmits and receives data of the PTP leg using a Cell Radio Network Temporary Identifier (C-RNTI) that is assigned one-to-one to the UE 100. The PHY entity transmits and receives data of the PTM leg using a G-RNTI that is assigned one-to-one to the MBS session. The C-RNTI is different for each UE 100, but the G-RNTI is a common RNTI for multiple UEs 100 receiving one MBS session.

[0065] In order to perform PTM transmission (multicast or broadcast) of MBS data from the gNB 200 to the UE 100 using a PTM leg, a split MRB must be configured from the gNB 200 to the UE 100, and the PTM leg must be activated. In other words, even if a split MRB is configured in the UE 100, the gNB 200 cannot perform PTM transmission of MBS data using this PTM leg if the PTM leg is in a deactivation state.

[0066] Furthermore, in order for the gNB200 and the UE100 to perform PTP transmission (unicast) of MBS data using a PTP leg, a split MRB must be configured from the gNB200 to the UE100, and the PTP leg must be activated. In other words, even if a split MRB is configured in the UE100, the gNB200 cannot perform PTP transmission of MBS data using this PTP leg if the PTP leg is in an inactive state.

[0067] In a state in which the PTM leg is activated, the UE 100 monitors a PDCCH to which a G-RNTI associated with an MBS session is applied (i.e., performs blind decoding of the PDCCH using the G-RNTI). The UE 100 may monitor the PDCCH only at scheduling opportunities for the MBS session.

[0068] When the PTM leg is deactivated, UE 100 does not monitor the PDCCH to which the G-RNTI associated with the MBS session is applied (i.e., does not perform blind decoding of the PDCCH using the G-RNTI).

[0069] UE 100 monitors a PDCCH to which a C-RNTI is applied when a PTP leg is activated. When discontinuous reception (DRX) is configured in a PTP leg, UE 100 monitors the PDCCH during a configured on validity period (OnDuration). When a cell (frequency) associated with an MBS session is specified, UE 100 may monitor the PDCCH of the cell even if the cell is deactivated.

[0070] In a state in which the PTP leg is deactivated, the UE 100 may monitor a PDCCH to which a C-RNTI is applied in preparation for normal unicast downlink transmission other than MBS data. However, when a cell (frequency) associated with an MBS session is specified, the UE 100 may not monitor the PDCCH for the MBS session.

[0071] It is assumed that the split MRB as described above is configured by an RRC message (e.g., an RRC Reconfiguration message) sent by the RRC entity of gNB200 to the RRC entity of UE100.

[0072] (Mobile communication system operation) The operation of the mobile communication system 1 according to the first embodiment will be described.

[0073] FIG. 9 is a diagram showing the correspondence (mapping) between a group RNTI (G-RNTI) and an MBS session. The G-RNTI may be a G-CS (Configured Scheduling)-RNTI. Hereinafter, G-RNTI may be read as G-CS-RNTI. For example, two G-RNTIs may be composed of one G-RNTI and one G-CS-RNTI. Note that the G-CS-RNTI is a G-RNTI used for Configured Scheduling, which allocates the same radio resources at regular intervals, and the radio resources specified by the G-CS-RNTI are allocated to multiple UEs at a periodicity set by RRC.

[0074] Mapping between G-RNTIs and MBS sessions includes "1:1 mapping" in which one G-RNTI is associated with one MBS session, "1:N mapping" in which one G-RNTI is associated with N (N≧2) MBS sessions, and "N:1 mapping" in which N G-RNTIs are associated with one MBS session. In the first embodiment, it is mainly assumed that N:1 mapping is used.

[0075] 10 shows the correspondence (mapping) between G-RNTI, multicast radio bearer (MRB) / multicast traffic channel (MTCH), quality of service (QoS) flow, and MBS session. There are cases where multiple QoS flows are associated with one MBS session, and cases where multiple QoS flows are associated with one G-RNTI. There may be a 1:1 relationship between the QoS flow and the MRB / MTCH.

[0076] In N:1 mapping, when multiple QoS flows are associated with one MBS session (e.g., one MBS application), MBS data can be transmitted and received with different settings for each QoS flow (e.g., different MTCH settings for each QoS flow). For example, when considering group communication using a video conferencing application, a scenario can be envisioned in which QoS flow #1 transmits video and QoS flow #2 transmits text messages (chat). In such a scenario, it is considered optimal to transmit and receive data with the following settings, for example:

[0077] QoS Flow #1: RLC UM, DRX cycle = short QoS Flow #2: RLC AM, DRX cycle = Long

[0078] Here, "#1" and "#2" are QoS flow identifiers, "RLC UM" means that the RLC mode is unacknowledged mode (UM), and "RLC AM" means that the RLC mode is acknowledged mode (AM). The DRX cycle means the period in which the UE 100 wakes up in discontinuous reception.

[0079] When using such a setting, since there are two DRX cycles for one MBS session, the UE 100 has to wake up twice within a certain period, which is not preferable in terms of the reception efficiency (power consumption) of the UE 100. The first embodiment is an embodiment that enables reception only for some of the plurality of QoS flows associated with one MBS session.

[0080] The communication method according to the first embodiment is a method used in the UE 100 that performs reception processing of PDCCH from the gNB 200 (hereinafter referred to as "PDCCH reception processing") using a Radio Network Temporary Identifier (RNTI). The communication method includes a step of identifying M (M < N) G-RNTIs to be used for PDCCH reception processing from among N (N ≧ 2) G-RNTIs when the N G-RNTIs are associated with one MBS session, and a step of performing PDCCH reception processing using the M G-RNTIs (where M can be equal to N). For example, in receiving an MBS session, the UE 100 performs PDCCH reception processing using M G-RNTIs without using (N - M) G-RNTIs among the N G-RNTIs for PDCCH reception processing. Thereby, when M < N, the UE 100 can perform reception only for some of the plurality of QoS flows associated with one MBS session.

[0081] Note that the PDCCH reception processing refers to a process in which the UE 100 performs blind decoding of PDCCH (DCI) using an RNTI and performs a CRC check using the CRC parity bits given to the DCI, and may be referred to as PDCCH monitoring processing.

[0082] The timing at which the UE 100 wakes up may be determined by an MTCH configuration associated with M G-RNTIs used for PDCCH reception processing. That is, the UE 100 does not need to apply the MTCH configuration associated with (NM) G-RNTIs, and therefore does not need to wake up according to the MTCH configuration. This reduces the power consumption of the UE 100.

[0083] UE 100 may identify desired QoS flows that it wishes to receive from among K (K≧2) QoS flows associated with one MBS session, and may identify M G-RNTIs associated with the desired QoS flows. The desired QoS flows may be determined by an upper layer of UE 100, for example, an application layer and / or a NAS layer.

[0084] UE 100 may receive information (mapping information) that associates one MBS session with K QoS flows and N G-RNTIs from gNB 200. This allows UE 100 to clearly (specifically) grasp the correspondence (mapping) between the MBS session, the QoS flows and the G-RNTIs.

[0085] The UE 100 may transmit to the gNB 200 a message including an identifier of an MBS session (an MBS session that the UE 100 is receiving or is interested in receiving) and an identifier of a desired QoS flow that belongs to the MBS session. This allows the gNB 200 to know which QoS flow of which MBS session the UE 100 wishes to receive, i.e., which QoS flow the UE 100 is receiving (or is interested in receiving). This allows the gNB 200 to appropriately control the scheduling of an MRB / MTCH associated with the QoS flow that the UE 100 wishes to receive, for example.

[0086] 11 is a diagram showing an example of an operation according to the first embodiment. The RRC state of the UE 100 may be any state (RRC connected state, RRC idle state, RRC inactive state). The MBS distribution mode may be the first distribution mode or the second distribution mode.

[0087] In step S101, the gNB 200 transmits mapping information of an MBS session, a QoS flow, and a G-RNTI to the UE 100. The gNB 200 may transmit the mapping information by broadcast signaling (SIB or MCCH) or by UE-dedicated signaling (RRC Reconfiguration message or RRC Release message). The mapping information may include one or more sets of an MBS session identifier, a QoS flow identifier, and a G-RNTI. The mapping information may be notified to the UE 100 from the AMF 300A by a NAS message.

[0088] In step S102, the UE 100 is receiving or is interested in receiving an MBS session. Note that step S101 may occur after step S102.

[0089] In step S103, UE 100 identifies a desired QoS flow that it wishes to receive from among K (K≧2) QoS flows associated with the MBS session. The desired QoS flow may be one QoS flow or multiple QoS flows.

[0090] Here, the upper layer (such as the application layer) of UE 100 may notify the AS layer of the identifiers of the QoS flows required for the MBS session. For example, the upper layer may notify the AS layer that, in a video conferencing application, video streaming (QoS flow #1) is used and therefore required, but the chat function (QoS flow #2) is turned off and therefore not required.

[0091] In step S104, the UE 100 identifies M G-RNTIs associated with the desired QoS flows identified in step S103.

[0092] In step S105, the UE 100 may transmit to the gNB 200 an MBS interest information message including an identifier of the MBS session (an MBS session that the UE 100 is receiving or is interested in receiving) and an identifier for a desired QoS flow belonging to the MBS session. The identifier for the desired QoS flow may be, for example, an identifier of the desired QoS flow, an identifier of a QoS flow other than the desired QoS flow among the K QoS flows, or a G-RNTI associated with the desired QoS flow. The MBS interest information message is a type of RRC message, and may be, for example, an MBS Interest Indication message or a UE Assistance Information message. The gNB 200 that has received the MBS interest information message may stop transmission of a QoS flow that the UE 100 does not desire, or change the settings of the UE 100 (for example, delete the settings of a QoS flow that the UE 100 does not desire), based on information included in the MBS interest information message (particularly, the identifier for the desired QoS flow). Note that step S105 may be performed before step S104.

[0093] In step S106, the UE 100 performs a PDCCH reception process using the M G-RNTIs identified in step S104. As a result, the UE 100 acquires, from the DCI, scheduling information of the PDSCH to which the MTCH is mapped.

[0094] In step S107, UE100 receives MBS data from gNB200 on the PDSCH.

[0095] [Second embodiment] The second embodiment will be described mainly focusing on the differences from the first embodiment described above.

[0096] 12 is a diagram showing internal processing of the UE 100 according to the second embodiment. The PHY layer of the UE 100 processes user data (received data) received on a PDSCH, which is one of the physical channels, and transmits the data to a downlink shared channel (DL-SCH), which is one of the transport channels. The MAC layer of the UE 100 processes data received on the DL-SCH and transmits the received data to a corresponding logical channel (corresponding RLC entity) based on a logical channel identifier (LCID) included in a header (MAC header) included in the received data.

[0097] Here, logical channels for user data include a dedicated traffic channel (DTCH) and a multicast traffic channel (MTCH). DTCH is a logical channel for unicast, and MTCH is a logical channel for multicast / broadcast. LCIDs for each logical channel may be assigned by the gNB 200. Note that DTCH may be a logical channel for multicast / broadcast PTP, and MTCH may be a logical channel for multicast / broadcast PTM.

[0098] When different LCIDs are assigned to the DTCH and MTCH, the MAC layer can route received data to the appropriate logical channel based on the LCID included in the MAC header. However, it is also possible not to separate the LCID space for the DTCH and MTCH, for example, in order to reduce restrictions on LCIDs.

[0099] If it were specified that the LCID space should not be divided, there would be no particular problem if separate LCIDs were assigned to the MTCH and DTCH by the gNB 200. However, since the MTCH is a logical channel common to multiple UEs, there is a concern that the same LCID may be assigned to the DTCH and MTCH in a certain UE 100. The second embodiment is an embodiment that enables received data to be transmitted to the appropriate logical channel even when the same LCID is assigned to the DTCH and MTCH. In other words, by being able to assign the same LCID to the DTCH and MTCH, the finite number of LCIDs can be used effectively. In other words, while two independent LCIDs were originally required for the DTCH and MTCH, it is now possible to assign one common LCID to them. Furthermore, the complexity that would arise from independently assigning and managing the LCIDs for the DTCH and MTCH can be avoided.

[0100] The communication method according to the second embodiment is a method used by UE 100 that performs PDCCH reception processing from gNB 200 using an RNTI. The communication method includes the steps of performing PDCCH reception processing to receive a DTCH using a cell RNTI (C-RNTI), performing PDCCH reception processing to receive an MTCH using a G-RNTI, and, when the same LCID is assigned to the DTCH and the MTCH, identifying a logical channel to which received data obtained in accordance with the PDCCH reception processing belongs, based on the RNTI used for the PDCCH reception processing. In this way, by identifying the logical channel to which received data obtained in accordance with the PDCCH reception processing belongs, based on the RNTI used for the PDCCH reception processing, it is possible to transmit the received data to an appropriate logical channel even when the same LCID is assigned to the DTCH and the MTCH.

[0101] Specifically, when the LCID included in the header of the MAC PDU, which is the received data, is the same for the DTCH and the MTCH, the MAC layer of UE 100 identifies the DTCH as the logical channel to which the received data obtained in accordance with the PDCCH receiving process using the C-RNTI belongs. On the other hand, it identifies the MTCH as the logical channel to which the received data obtained in accordance with the PDCCH receiving process using the G-RNTI belongs. Then, the MAC layer of UE 100 outputs the received data (MAC SDU / RLC PDU) to the identified logical channel.

[0102] In the second embodiment, the UE 100 may receive from the gNB 200 information associating a data radio bearer (DRB) with an LCID of a DTCH, and information associating a multicast radio bearer (MRB) with an LCID of an MTCH.

[0103] 13 is a diagram showing an example of the operation according to the second embodiment. The RRC state of UE 100 may be any state (RRC connected state, RRC idle state, RRC inactive state). For example, the RRC state of UE 100 may be the RRC connected state. The MBS delivery mode is the first delivery mode or the second delivery mode. For example, the MBS delivery mode may be the first delivery mode.

[0104] In step S201, the gNB 200 notifies the UE 100 of mapping information for the LCID of the DTCH and the LCID of the MTCH. For example, the gNB 200 transmits to the UE 100 information associating the DRB#1 with the DTCH LCID#1 and information associating the MRB#2 with the MTCH LCID#1. That is, in this operation example, the same LCID may be associated with the DTCH and the MTCH. If the UE 100 recognizes that the LCIDs are the same, it may perform the following operation.

[0105] In step S202, the UE 100 is receiving or is interested in receiving an MBS session. Note that step S201 may be after step S202.

[0106] In step S203, UE 100 may perform unicast reception for DTCH LCID #1 by using C-RNTI. Specifically, UE 100 may perform DTCH reception by performing PDCCH reception processing by using C-RNTI.

[0107] In step S204, UE 100 may perform multicast reception for MTCH LCID #1 using G-RNTI. Specifically, UE 100 may perform MTCH reception by performing PDCCH reception processing using G-RNTI. Note that step S204 may be executed before step S203.

[0108] In response to step S203 or step S204, the UE 100 receives user data on the PDSCH in step S205. For example, the user data received on the PDSCH in response to step S203 may be unicast data, and the user data received on the PDSCH in response to step S204 may be MBS data (multicast data or broadcast data).

[0109] If the same LCID is associated with the DTCH and MTCH (step S206: YES), in step S207, UE 100 (MAC layer) identifies the corresponding logical channel from the RNTI used for reception of the data (packet) received in step S205. If UE 100 receives the packet with C-RNTI, it transmits the packet to LCID #1 associated with DRB #1 (DTCH) (step S208). On the other hand, if UE 100 receives the packet with G-RNTI, it transmits the packet to LCID #1 associated with MRB #2 (MTCH) (step S208).

[0110] If the same LCID is not associated with the DTCH and the MTCH (step S206: NO), in step S208, the UE 100 (MAC layer) transmits the packet (MAC PDU) to the logical channel indicated by the LCID included in the header of the packet.

[0111] In the second embodiment, a reception method when a DTCH and an MTCH have the same LCID has been described, but this is not limiting. The operation according to the second embodiment can also be applied when the same LCID is assigned to different MTCHs. As shown in Fig. 14, when MTCH#1 is transmitted / received using G-RNTI#1 and MTCH#2 is transmitted / received using G-RNTI#2, even if the same LCID is assigned (set) to MTCH#1 and MTCH#2, UE100 can send data to the appropriate RLC entity from G-RNTI#1 and G-RNTI#2 used for reception processing.

[0112] [Third embodiment] The third embodiment will be described mainly focusing on the differences from the first and second embodiments.

[0113] In the second distribution mode, the UE 100 acquires MTCH configuration information by receiving the MCCH from the gNB 200, and receives the MTCH (MBS data) based on the MTCH configuration information. Here, the content of the MCCH may be changed. The period during which the content of the MCCH is maintained may be referred to as an MCCH modification period. The predetermined timing during which the content of the MCCH may be changed may be referred to as an MCCH modification boundary.

[0114] For a UE 100 receiving an MBS or interested in receiving an MBS, receiving the MCCH (specifically, the PDSCH, which is a physical channel) at each MCCH change boundary and decoding its contents leads to increased load and power consumption. Therefore, it is assumed that a notification regarding a change in the MCCH content is transmitted from the gNB 200 to the UE 100 on the PDCCH (in the DCI) at a predetermined timing. This allows the UE 100 to determine whether or not it needs to receive the MCCH, thereby suppressing unnecessary MCCH reception. Such an MCCH change notification may be transmitted based on a change in the MCCH content, for example, an MBS session start, an MBS session change, or an MBS session stop. The MCCH change notification may be configured as one bit in the DCI, i.e., a one-bit flag that is set to "1" only when there is a change.

[0115] However, a UE 100 that does not receive an MCCH change notification at a predetermined timing, i.e., a UE 100 that does not detect a bit indicating an MCCH change, cannot determine whether the error is due to a PDCCH (DCI) transmission error (loss in the wireless section) or the absence of an MCCH change. Therefore, considering the possibility of a PDCCH (DCI) transmission error, a UE 100 that does not receive an MCCH change notification at a predetermined timing may need to receive the MCCH and decode its contents. The third embodiment is an embodiment that attempts to solve such a problem.

[0116] The communication method according to the third embodiment includes a step in which the gNB 200 transmits, on an MCCH, configuration information (MTCH configuration information) used for receiving the MTCH, and a step in which the gNB 200 transmits, at a predetermined timing, a notification (hereinafter referred to as an "MCCH notification") regarding a change in the content of the MCCH (hereinafter referred to as an "MCCH change") to the UE 100 on a physical downlink control channel (PDCCH). The transmitting step includes a step in which, if there is no MCCH change, the UE 100 transmits an MCCH notification indicating that there is no MCCH change. In this way, by transmitting the MCCH notification indicating that there is no MCCH change if there is no MCCH change, the UE 100 can clearly determine that there is no MCCH change. Therefore, if the UE 100 does not receive the MCCH notification at a predetermined timing, it can determine that this is due to a transmission error in the PDCCH (DCI). This makes it possible to prevent the UE 100 from receiving unnecessary MCCH.

[0117] For example, if there is an MCCH change, the gNB 200 transmits a first value indicating that there is an MCCH change as an MCCH notification. If there is no MCCH change, the gNB 200 transmits a second value indicating that there is no MCCH change as an MCCH notification. This allows the UE 100 to clearly determine whether there is an MCCH change.

[0118] For example, when the UE 100 receives a first value on the PDCCH, the UE 100 may attempt to receive the MCCH. When the UE 100 receives a second value on the PDCCH, the UE 100 may omit receiving the MCCH. When the UE 100 fails to receive an MCCH notification on the PDCCH at a predetermined timing, the UE 100 may attempt to receive the MCCH.

[0119] 15 is a diagram showing an example of the operation according to the third embodiment. The RRC state of the UE 100 may be any state (RRC connected state, RRC idle state, RRC inactive state). The MBS delivery mode may be the second delivery mode.

[0120] In step S301, the UE 100 is receiving or is interested in receiving an MBS session.

[0121] In steps S302 to S304, the gNB200 performs processing to transmit an MCCH notification. Here, the MCCH notification is configured using a certain bit of the DCI. The MCCH notification based on the start of an MBS session and the MCCH notification based on the change / stop of an MBS session may be notified using the same bit or different bits. Furthermore, the MCCH notification may be notified using a different bit for each MBS session, or common to all sessions (only one bit). The (each) bit configuring the MCCH notification may be defined as "no change" when "0" and as "change" when "1". Furthermore, the 0 / 1 relationship of the (each) bit configuring the MCCH notification may be reversed. The gNB200 transmits the MCCH notification regardless of whether the MCCH has been changed.

[0122] If there is an MCCH change (step S302: YES), in step S303, gNB200 transmits a first value (for example, "1") indicating that there is an MCCH change as an MCCH notification at a predetermined timing.

[0123] On the other hand, if there is no MCCH change (step S302: NO), in step S304, gNB200 transmits a second value (e.g., "0") indicating that there is no MCCH change as an MCCH notification at a predetermined timing.

[0124] The UE 100 receives the signal at a predetermined timing ( MCCH modification boundary ) and attempts to receive MCCH notification (DCI).

[0125] Here, when the UE 100 normally receives the MCCH notification and the received MCCH notification is the second value (step S305: YES), the UE 100 does not attempt to receive the MCCH (PDSCH).

[0126] On the other hand, if the MCCH notification is received normally and the received MCCH notification is a first value, the UE 100 attempts to receive the MCCH (PDSCH) (step S306). Furthermore, if the MCCH notification cannot be received normally, the UE 100 attempts to receive the MCCH (PDSCH) (step S306). Specifically, the UE 100 attempts to receive the PDCCH (DCI) that transmits scheduling information for the MCCH (PDSCH). Note that the DCI constituting the MCCH notification may be scrambled with a dedicated RNTI (for example, SC-N-RNTI), and the DCI for the MCCH may be scrambled with a dedicated RNTI (for example, SC-RNTI). These RNTIs may be fixed RNTIs defined in the technical specifications. The UE 100 checks the received MCCH, and if there is a change, applies the content (settings) of the MCCH.

[0127] In the second embodiment, an example has been described in which the presence or absence of an MCCH change is represented by a bit value, but the presence or absence of an MCCH change may be represented by the value of the RNTI. In this case, the bit value may be a fixed value regardless of the presence or absence of an MCCH change. As shown in steps S303', S304', and S305' in Fig. 16, when an MCCH notification is transmitted in a first RNTI (RNTI#1), it may be defined as "no change," and when an MCCH notification is transmitted in a second RNTI (RNTI#2), it may be defined as "changed."

[0128] [Other embodiments] The above-described operational flows are not limited to being implemented independently, but can also be implemented by combining two or more operational flows. For example, some steps of one operational flow may be added to another operational flow. Some steps of one operational flow may be replaced with some steps of another operational flow.

[0129] In the above-described embodiment and example, an example in which the base station is an NR base station (gNB) has been described, but the base station may be an LTE base station (eNB) or a 6G base station. The base station may also be a relay node such as an IAB (Integrated Access and Backhaul) node. The base station may also be a DU of the IAB node. The user equipment may also be an MT (Mobile Termination) of the IAB node.

[0130] A program may be provided that causes a computer to execute each process performed by UE100 or gNB200. The program may be recorded on a computer-readable medium. The computer-readable medium can be used to install the program on a computer. Here, the computer-readable medium on which the program is recorded may be a non-transitory recording medium. The non-transitory recording medium is not particularly limited, and may be, for example, a recording medium such as a CD-ROM or a DVD-ROM. Furthermore, circuits that execute each process performed by UE100 or gNB200 may be integrated, and at least a part of UE100 or gNB200 may be configured as a semiconductor integrated circuit (chip set, SoC: System on a chip).

[0131] As used in this disclosure, the terms "based on" and "depending on" do not mean "based only on" or "depending only on," unless expressly stated otherwise. The term "based on" means both "based only on" and "based at least in part on." Similarly, the term "depending on" means both "based only on" and "at least in part on." Furthermore, "obtain" may mean obtaining information from stored information, obtaining information from information received from another node, or obtaining information by generating the information. The terms "include," "comprise," and variations thereof do not mean including only the listed items, but may also mean including only the listed items or including additional items in addition to the listed items. Furthermore, as used in this disclosure, the term "or" is not intended to mean an exclusive or. Furthermore, any reference to elements using designations such as "first," "second," etc., as used in this disclosure does not generally limit the quantity or order of those elements. These designations may be used herein as a convenient method of distinguishing between two or more elements. Thus, reference to first and second elements does not imply that only two elements may be employed therein or that the first element must precede the second element in some manner. In this disclosure, where articles are added by translation, such as a, an, and the in English, these articles shall include the plural unless the context clearly indicates otherwise.

[0132] The above describes the embodiments in detail with reference to the drawings, but the specific configuration is not limited to that described above, and various design changes can be made within the scope that does not deviate from the gist of the invention.

[0133] This application claims priority to U.S. Provisional Application No. 63 / 228268 (filed August 2, 2021), the entire contents of which are incorporated herein by reference.

[0134] [Appendix 1] (1. Introduction) A revised work item on NR Multicast and Broadcast Services (MBS) was approved in RAN#88.

[0135] RAN2 has agreed to two delivery modes: delivery mode 1 for a multicast session received by UEs in Connected state, and delivery mode 2 for a broadcast session received by UEs in all RRC states.

[0136] RAN2 also agreed on the details of the MCCH scheduling method, namely the MCCH repetition period, the MCCH transmission window, the search space, and the MCCH modification period.

[0137] In RAN2#114-e, the following agreement was reached on two delivery modes:

[0138] Use PCCH for multicast enable notification (also used for MBS support nodes). Verify that the MBS session ID is conveyed in the notification. The use of paging in all (legacy) POs using PRNTI is a baseline assumption (other variations can be discussed). An MBS-specific SIB is defined to perform the MCCH configuration. The content of the MCCH must include information about the broadcast session such as G-RNTI, MBS session ID, and scheduling information for the MTCH (search space, DRX, etc.). The L1 parameters that need to be included in the MCCH are pending further RAN1 processing and input. Postpone the discussion on whether a dedicated MCCH configuration is necessary until RAN1 progresses on BWP / CFR for MCCH. Indications of MCCH changes due to changes in the configuration of an ongoing session (including session termination) are provided by explicit notification from the network (if RAN1 has confirmed that the MCCH change notification DCI can accommodate another bit for this purpose in addition to the bit for session start notification). Whether this notification can be reused for changes to other information carried by the MCCH requires further study. Further study is needed to determine whether it is necessary to address the possibility that the UE may miss the MCCH change notification, or whether this can be left to the UE implementation. At least, if RAN1 decides to use an RNTI other than the MCCH-RNTI for the MCCH change notification, the MCCH change notification is sent at the first MCCH monitoring opportunity of each MCCH repetition period. Supports single MCCH.

[0139] Supplementary Note 1 provides details of the control plane aspects of delivery mode 2, considering the baseline LTE eMBMS mechanism.

[0140] (2. Discussion) (3. Remaining Stage 2 Questions) At this point, according to the RAN2 agreement, the characteristics of the two delivery modes are shown in Figure 17.

[0141] (4. Multicast session connected via distribution mode 2) NR MBS is expected to support a variety of use cases, as quoted from the WID below: NR MBS must be appropriately designed for a variety of requirements, from delay-sensitive applications such as mission-critical and V2X to delay-tolerant applications such as IoT. In reality, not all multicast services require "high QoS," such as software delivery to UDP-type streaming such as IPTV.

[0142] Objective A of the SA2 SI concerns the enablement of general MBS services over 5GS, and identified use cases that could benefit from this capability include public safety, mission-critical, V2X applications, transparent IPv4 / IPv6 multicast distribution, IPTV, and software distribution over wireless, group communication, and IoT applications.

[0143] Some of these services with "low QoS requirements" may be covered by delivery mode 2, while other services with "high QoS requirements" require delivery mode 1. Furthermore, LTE eMBMS may deliver multicast sessions, which can be considered a baseline for NR MBS. In this sense, it is beneficial for the gNB to be able to choose to use delivery mode 2 for multicast sessions. This issue requires further study from RAN2#112-e to RAN2#114-e, but in general, there is no technical reason to restrict it.

[0144] In RAN2, it was agreed that "RAN2 will prioritize active multicast support in RRC connected mode in Rel-17, and if time permits, multicast support in RRC inactive state can be discussed later (when multicast solutions in connected mode and broadcast solutions are more mature)." However, since the agreement was made in the context of delivery mode 1, it does not preclude multicast sessions using delivery mode 2 for UEs in connected state.

[0145] Proposal 1: RAN2 should agree that in addition to broadcast sessions, delivery mode 2 can be used for multicast sessions at least for UEs in RRC Connected state.

[0146] (5. Dedicated MCCH (for service continuity)) RAN2 agreed to postpone the discussion on whether a dedicated MCCH configuration is required until RAN1 has made progress on the BWP / CFR for MCCH. A dedicated MCCH is expected to be provided, if supported, for example, by RRC reconfiguration.

[0147] Observation 1: A dedicated MCCH can be interpreted as the MCCH being provided by RRC reconfiguration, i.e., not in a broadcast-based manner.

[0148] On the other hand, a dedicated MCCH can be considered from the perspective of broadcast service continuity. RAN2 has already agreed to "assume that the LTE SC-PTM mechanism for connected UEs can be reused to receive PTM configuration for NR MBS delivery mode 2, i.e., the broadcast-based method." This assumption is for intra-cell configuration, but not for inter-cell service continuity, i.e., handover.

[0149] Observation 2: The RAN2 agreed MCCH is provided in a broadcast-based manner for intra-cell configuration, but not for inter-cell service continuity.

[0150] In LTE SC-PTM, the UE is assumed to acquire the target cell's SIB20 and MCCH in some way before, during, or even after handover. This can be considered the baseline for NR MBS delivery mode 2. However, this implies a risk of service interruption because the UE may miss or delay acquiring the neighbor cell's MCCH, for example, when in a busy state. Therefore, it is worth discussing a more reliable solution. Specifically, the target cell's MCCH, and at least the target MTCH scheduling information, must be provided by a synchronized RRC reconfiguration, i.e., handover command. This solution ensures service continuity after handover.

[0151] Proposal 2: RAN2 must agree that the target cell's MCCH, and at least the target MTCH scheduling information, is provided during the handover procedure, i.e. by RRC reconfiguration with synchronization, to ensure inter-cell service continuity for UEs in RRC Connected state.

[0152] (6. MCCH Change Notification Regarding Other Information) RAN2 agreed to introduce MCCH change notification with session start, session change, and session stop, and the current intention is that MCCH change notification will be sent when settings related to MTCH reception (e.g., MBS session information and MTCH scheduling information) change. RAN2 noted that "further consideration is needed as to whether this notification can be reused for changes to other information held by MCCH."

[0153] The possible "other information" can be interpreted as neighboring cell / frequency information, which will be discussed in the following section. If the UE misses the neighboring cell / frequency information, it is not a critical issue when the UE remains in the serving cell. However, up-to-date neighboring cell / frequency information is important information for UEs in idle / inactive state and in case of inter-cell mobility for UEs in RRC connected state if proposal 5 is not agreed. In this sense, for more reliable service continuity, if RAN2 agrees that neighboring cell / frequency information is provided by the MCCH, it should also send an MCCH change notification when other information changes.

[0154] Proposal 3: RAN2 should agree that MCCH change notifications are sent when any of the MCCH content changes, i.e., in addition to MBS session information and MTCH scheduling information, also applies to "other information", which is at least neighbor frequency / cell information (if agreed to be provided by the MCCH).

[0155] (7. Missed MCCH change notification) RAN2 left it open to further consideration whether it is necessary to address the possibility that the UE may miss the MCCH change notification or whether it can be left to the UE implementation. According to the agreement, the MCCH change notification is expected to be provided by DCI, but details are left to RAN1.

[0156] The issue requiring further study is related not only to session change / stop but also to session start, and has never been recognized as an issue in LTE eMBMS. Furthermore, whether the issue actually exists may depend on the DCI design of RAN1. For example, an MCCH change notification may be sent even when the MCCH has not changed. For example, the DCI bit can be "0" to indicate "no change" and "1" to indicate "change," so the UE can be notified if it has missed the MCCH change. It may be notified without additional power consumption and take some action to recover. Therefore, it is unclear at this point whether RAN2 should discuss the issue requiring further study.

[0157] Observation 3: Before discussing the possibility of UEs missing MCCH change notifications in RAN2, RAN1 progress on the DCI design for MCCH change notifications is needed.

[0158] (8. On-Demand MCCH) A new paradigm in NR is the support of on-demand SI transmission. This concept can be reused for MCCH in delivery mode 2, i.e., on-demand MCCH. For example, MCCH for delay-tolerant services is provided on-demand, thus optimizing signaling resource consumption. Of course, the network has other options, i.e., providing MCCH periodically instead of on-demand for delay-sensitive services, etc.

[0159] Proposal 4: RAN2 should agree to be able to provide MCCH on demand.

[0160] (9. One-step setup) Another possibility is to merge the MCCH with the BCCH, i.e., one-step configuration as shown in Figure 18, which can be further discussed. For example, the SIB provides MTCH scheduling information directly, i.e., without the MCCH. This provides optimization for delay-tolerant services and power-sensitive UEs. For example, a UE can request an SIB (on-demand), and the gNB can start providing the SIB and corresponding services after requests from multiple UEs. These UEs do not need to monitor the repeatedly broadcast MCCH.

[0161] Proposal 5: RAN2 should agree that multicast reception without MCCH is supported (i.e., one-step configuration), e.g., the SIB provides MTCH scheduling information directly.

[0162] (10. Counting in idle / inactive state) For NR MBS, it was agreed that MBS interest indication is supported in the RRC connected state, but not in the idle / inactive state. Based on this, it is worth discussing enhancements over LTE eMBMS.

[0163] In LTE eMBMS, even if a large proportion of UEs are in RRC idle state and receiving broadcast services, neither MII nor counting can collect information from idle UEs, which is one of the remaining issues for LTE eMBMS from the perspective of session control and resource efficiency.

[0164] Observation 4: For broadcast sessions, most of the UEs receiving the MBS service may be in RRC idle / inactive state.

[0165] In NR MBS, the same problem can occur for idle / inactive UEs, i.e., delivery mode 2 of broadcast sessions. For example, the network does not know whether idle / inactive UEs are not receiving / interested in the broadcast service. Therefore, the network may continue to provide PTM transmissions even when no UEs are receiving the service. If the gNB knows the interests of idle / inactive UEs, it must avoid such unnecessary PTM transmissions. Conversely, if PTM is stopped while there are still idle / inactive UEs receiving the service, a large number of UEs may send connection requests simultaneously, which is also undesirable.

[0166] It is therefore worth discussing whether to introduce a mechanism to collect UE assistance information, especially MBMS counts, from idle / inactive UEs. Needless to say, it would be desirable for these idle / inactive UEs to be able to report information without transitioning to the RRC connected state. This could be achieved, for example, if PRACH resource partitioning associated with MBS services were introduced for such reporting.

[0167] Note that there is no MCE in the NR MBS, which means that the MCE functionality is integrated within the gNB. In this sense, it is RAN2 that decides whether counting is required in the NR MBS, regardless of what RAN3 decides from a network interface perspective.

[0168] Proposal 6: RAN2 needs to discuss whether MBS counts are implemented and whether they are collected from UEs in idle / inactive state.

[0169] (11. Stage 3 Aspects) SIB13, SIB15, SIB20, SC-MCCH, MBMS interest indication IE, and cell reselection procedures in LTE can be considered as the baseline for the Stage 3 specification of NR MBS.

[0170] (12.MBS-specific SIB) (13. Basic Content) RAN2 agreed that "MBS-specific SIBs are defined to perform MCCH configuration." Regarding MCCH configuration, RAN2 already agreed that "the MCCH transmission window is defined by the MCCH repetition period, MCCH window duration, and radio frame / slot offset," and "the modification period is defined for the NR MCCH." These parameters are the same as SIB20, namely, SC-MCCH-repetition-period, SC-MCCH-first-subframe, SC-MCCH-period, SC-MCCH-offset, and SC-MCCH-modification-period, respectively. Therefore, the ranges of these parameters can be easily reused to minimize standardization efforts.

[0171] Proposal 7: RAN2 should agree that in the MBS-specific SIB, the ranges of MCCH repetition period, duration, radio frame / offset and modification period reuse the ranges of these parameters of LTE SC-PTM, i.e. SIB20.

[0172] (14. Advanced Content) Whether an MBS service is provided via PTP or PTM, and via delivery mode 1 or delivery mode 2, is up to the network implementation. This allows for a good balance between service reliability and spectral efficiency. However, from the UE's perspective, especially for idle / inactive UEs and late-joining UEs, the UE needs to know whether it needs to initiate connection establishment to acquire the target MBS service. The UE first checks the MCCH. If the MCCH does not contain MTCH scheduling information for the target MBS service, the UE can assume that the MBS service is only provided in the RRC connected state, i.e., via PTP, delivery mode 1, or unicast (PDU session). However, this process is burdensome for the UE, and there may be some delay before the MBS service can be acquired. Therefore, it is worth discussing whether an MBS-specific SIB provides information on whether the UE needs to be connected to acquire the MBS service.

[0173] Proposal 8: RAN2 needs to discuss whether MBS-specific SIBs provide information to associate MBS services with their delivery modes.

[0174] RAN2 agreed to introduce an MBS interest indication, which is supposed to be used in broadcast sessions. At least from the AS's perspective, it is up to the network whether an MBS service is provided as a multicast or broadcast session. Furthermore, from the UE's perspective, it is unclear whether the gNB can obtain information about MBS services of interest to the UE, which may be provided by the AMF for multicast sessions but not for broadcast sessions. As a result, the UE cannot know whether it needs to send an MBS interest indication for an MBS service of interest. Therefore, it would be helpful for the UE if the gNB provided information about whether MBS interest indication is allowed for each MBS service. In other words, which MBS services require an MBS interest indication. Therefore, RAN2 needs to discuss whether such additional information is needed.

[0175] Proposal 9: RAN2 needs to discuss whether MBS-specific SIBs should provide information on whether MBS interest indications can be sent to each MBS service.

[0176] (15.MCCH) RAN2 agreed that "the content of the MCCH should include information about the broadcast session such as G-RNTI, MBS session ID, etc., and scheduling information for the MTCH (search space, DRX, etc.). The L1 parameters that need to be included in the MCCH are pending the progress and input of RAN1," and "postpone the discussion of whether a dedicated MCCH configuration is necessary until RAN1 progresses with BWP / CFR for the MCCH."

[0177] Regarding MTCH scheduling information, the SC-MCCH in LTE SC-PTM includes an SC-MTCH-InfoList containing MBMS Session Info (TMGI and Session ID), g-RNTI, and SC-MTCH-scheduling Info (On ​​Duration Timer SCPTM, DRX-Inactivity Timer SCPTM, Scheduling Period Start Offset SCPTM). Since RAN2 agreed that "for NR MBS delivery mode 2, the LTE SC-PTM DRX scheme is used as the baseline," these parameters and value ranges are simply reused to minimize standardization efforts.

[0178] Proposal 10: RAN2 needs to agree that MCCH provides MBS Session Info (TMGI and Session ID), G-RNTI and MTCH-scheduling Info (On ​​Duration Timer, Inactivity Timer, Scheduling Period, and Start Offset) as MTCH information.

[0179] Proposal 11: RAN2 must agree that the value range of each parameter of the MTCH scheduling information (i.e., On Duration Timer, Inactivity Timer, Scheduling Period, and Start Offset) is the same as that of LTE SC-PTM, i.e., these parameters in the SC-PTM configuration.

[0180] In LTE eMBMS, SIB15 provides inter-frequency information in SAI, i.e. MBMS-SAI-InterFrequencyList. In LTE SC-PTM, SC-MCCH contains SCPTM-Neighbor Cell List, which consists of cell IDs and frequencies, and SC-MTCH Neighbor Cell List, which is a bit string referencing the neighbor cell list. This information is useful for service continuity from the UE's perspective, i.e. MBMS Interest Indication and cell reselection priority handling.

[0181] Such neighboring cell / frequency information is considered to remain useful for NR MBS for the same purpose, i.e., service continuity. Therefore, RAN2 must agree on a cell / frequency list on which MBS services are broadcast. Because UEs need to know the cell / frequency on which the MBS service of interest is provided, the neighboring cell / frequency information must be associated with an MBS session ID (e.g., TMGI). For example, a cell / frequency list that is further associated with a SAI, such as LTE eMBMS, requires further consideration, as does whether it is broadcast via an MBS-specific SIB or MCCH.

[0182] Proposal 12: RAN2 should agree that the neighbor cell / frequency list associated with the MBS session ID (e.g., TMGI) is broadcast for service continuity. Whether it is further associated with the SAI and whether it is provided in an MBS-specific SIB or MCCH needs further consideration.

[0183] (16.MBS Interest Indication) (17. Basic Content) RAN2 agreed that "it is assumed that MBS interest indication is supported by UEs in connected mode for broadcast services," but the exact content has not yet been discussed.

[0184] In LTE, the MBMS interest indication includes three IEs, excluding ROM-related settings (shown in Figure 19). This assistance information helps ensure service continuity, such as gNB scheduling and handover decisions. Since the characteristics of SC-PTM and distribution mode 2 are very similar, the same information is considered useful for NR MBS.

[0185] Proposal 13: RAN2 needs to agree that the MBS interest indication includes a frequency list, a priority between MBS reception and unicast, and an MBS service list, similar to the MBMS interest indication in LTE.

[0186] Since the minimum MBS service area may be the cell of the NR MBS, it is considered whether the MBS interest indication should also include a list of cells that provide the MBS service of interest to the UE. In LTE SC-PTM, since the gNB provides neighbor cell information, assuming that the gNB knows which neighbor cells provide which MBS service, MBMS service refers to such cells. In particular, if Proposal 9 is acceptable, the same assumption applies to NR MBS. Therefore, RAN2 needs to check with the gNB.

[0187] Proposal 14: RAN2 should verify that if an MBS service list is included in the MBS interest indication, it means the cell that provides the MBS service of interest to the UE, that is, it is assumed that the gNB knows the MBS services provided in neighboring cells.

[0188] (18. Advanced Content) In addition to the LTE baseline, i.e., Proposal 13 and Proposal 14 above, it is worth considering whether the MBS interest indication needs to provide other supporting information.

[0189] For example, MBMS priority is used to indicate whether a UE prioritizes MBMS reception over unicast reception, which can be useful, for example, for gNB scheduling and can be reused in NR MBS. However, NR MBS has two delivery modes: delivery mode 1 using C-RNTI and delivery mode 2 using G-RNTI, which are based on different scheduling algorithms for MTCH transmission. Therefore, if a UE is interested in multiple MBS services provided via different delivery modes, it may be useful for the UE to provide a priority between reception of delivery mode 1 and reception of delivery mode 2. Other examples, such as the UE's power saving settings, which will be described as necessary, can also be considered. Therefore, RAN2 must first discuss whether the MBS interest indication provides additional information for advanced purposes.

[0190] Proposal 15: RAN2 should discuss whether additional information should be provided by the MBS interest indication, e.g., the priority between receiving delivery mode 1 and receiving delivery mode 2.

[0191] (19. Message Definition) Another issue worth considering is whether the MBMS Interest Indication is a new / separate message or is integrated with the UE Assistance Information message. In LTE, the MBMS Interest Indication (MII) is separated from the UE Assistance Information (UAI) because the prerequisites are different, i.e., obtaining SIB15 for the MII during the RRC connection reconfiguration of the UAI. On the other hand, the In-device Coexistence Indication (IDC), which was a separate message in LTE, is integrated into the UAI in NR. This is feasible because the prerequisites in LTE (and NR) are the same between IDC and UAI, i.e., the RRC connection reconfiguration is the same.

[0192] Observation 5: The ability to integrate MBS interest indication with UE assistance information depends on whether the preconditions are aligned between the two messages.

[0193] For NR MBS, generating the MBS interest indication message with the IE in Proposal 10 requires neighbor cell / frequency information in an MBS-specific SIB or MCCH as in Proposal 9. Furthermore, the MBS interest indication is expected to be configured in an MBS-specific SIB, the same SIB (or MCCH) as in LTE eMBMS. Therefore, this does not match the prerequisite for UAI, i.e., RRC reconfiguration. Therefore, the MBS interest indication needs to be a separate message from UAI, as in LTE eMBMS.

[0194] Proposal 16: RAN2 should agree to define the MBS Interest Indication as a new message, i.e., separate from the UE Assistance Information.

[0195] Proposal 17: RAN2 should agree that sending an MBS interest indication is allowed if the UE can obtain an MBS-specific SIB from the serving cell (i.e., as a prerequisite).

[0196] 20. MBS Interest Indication for Multicast Session RAN2 assumes that MBS interest indication is supported for broadcast sessions, but not for multicast sessions. For multicast sessions, the general understanding seems to be that the core network notifies the gNB of the UE's interest, since multicast sessions have a higher-layer session join procedure. In the context of Proposal 10 and Figure 18, this applies to the MBS service of interest to the UE. It is also clear that if Proposal 11 is agreed upon, the gNB knows the MBS frequency and the cell providing the MBS service of interest to the UE. However, the priority between MBS reception and unicast is similar to the MBMS priority in LTE and is purely AS-related information, meaning that it is strange for the UE to notify the core network of the priority information in the session join procedure, and therefore may not be provided by the core network.

[0197] Observation 6: For multicast sessions, the core network provides the gNBs of interest to the UE, such as MBS services, and the gNB knows the MBS frequency / cell, but the core network and gNB may not know the UE's AS priority between MBS and unicast.

[0198] The priority information is still considered useful to the gNB, e.g., for scheduling and handover decisions similar to LTE eMBMS, which is also related to service continuity. Therefore, the UE needs to inform the gNB of the priority information for multicast sessions as well. In this sense, RAN2 needs to agree that MBS interest indication must be supported also for multicast services / distribution mode 1.

[0199] Proposal 18: RAN2 should agree that MBS interest indication is also supported in multicast sessions / distribution mode 1, at least for UEs to inform the gNB of the priority between MBS reception and unicast.

[0200] (21. Cell reselection) (22. Cell Reselection Priority Handling) In LTE eMBMS, for inter-frequency cell reselection, the so-called "highest priority rule" is applied to the cell reselection priority process. In particular, the UE can consider frequencies that provide the MBMS service of interest as the highest priority. The UE can also consider frequencies that do not provide the MBMS service of interest as the lowest priority. Regardless of the absolute frequency priority set by the eNB, the UE can reselect a cell that provides the target MBMS service, ensuring service continuity. These rules apply only at the frequency level, and it is sufficient to assume that MBMS services are provided on a frequency-by-frequency basis.

[0201] Observation 7: In LTE, service continuity is guaranteed by the UE being able to consider the frequency that provides the targeted MBMS service as the highest priority, which is applicable to inter-frequency cell reselection.

[0202] Observation 8: In LTE, the UE may also consider frequencies that do not offer the intended MBMS service as the lowest priority, which is applicable to inter-frequency cell reselection.

[0203] Additionally, for intra-frequency and equal priority inter-frequency cell reselection, and for NB-IoT and UE to CE (i.e., extended coverage), the R criterion (i.e., ranking) applies an SC-PTM specific offset, which can be set to "infinity." This mimics the "highest priority rule" per cell. This means that the defined ranking applies to intra-frequency and inter-frequency cell reselection (regardless of the configured frequency priority), so the UE is in extended coverage. That is, traditional inter-frequency cell reselection does not apply to NB-IoT and UE to CE.

[0204] Observation 9: In LTE, NB-IoT UEs and CE UEs apply an SC-PTM specific offset (which may be "infinity") to the R criteria, which is applicable for intra-frequency and inter-frequency cell reselection of the same priority.

[0205] In summary, LTE has two mechanisms that can be applied to inter-frequency cell reselection (i.e., frequency-based) and intra-frequency and equal-priority inter-frequency reselection (i.e., cell-based), respectively. The "highest priority rule" for inter-frequency cell reselection is easy to implement for NR MBS because, similar to LTE eMBMS, idle / inactive UEs must camp on the frequency that provides the target MBS service. Therefore, RAN2 needs to agree to implement the "highest priority rule" for NR MBS. Additionally, a "lowest priority rule" like that in Observation 5 also needs to be implemented.

[0206] Proposal 19: RAN2 should agree that, similar to LTE, UEs may consider frequencies that provide targeted MBS services as their highest priority.

[0207] Proposal 20: RAN2 should agree that, similar to LTE, a UE may consider frequencies that do not offer the intended MBS service as the lowest priority.

[0208] (23.R standard) Another mechanism, the SC-PTM-specific offset of the R criteria, is worth considering, considering that the minimum NR MBS service area is considered a cell, but still depends on the deployment scenario preferred in Rel-17: frequency-based or cell-based. Frequency-based deployment, where the same MBS service is provided across cells on a frequency within a specific MBS service area, is a subset of cell-based deployment. That is, an MBS service is only provided on a cell because the frequency can be represented by a list of cells, which includes all cells on the frequency. Therefore, if MBS service is provided primarily on a cell-by-cell basis, there is more flexibility to support different deployment scenarios.

[0209] As mentioned above, the SC-PTM specific offset was introduced for multicast support in eMTC / NB-IoT in Rel-14, i.e., the absence of inter-frequency cell reselection at the CE, but can be used to prioritize specific cells offering MBMS services of interest. Therefore, the same mechanism can be reused to prioritize cells offering MBS services of interest to the UE, thereby reducing the standardization effort.

[0210] Proposal 21: RAN2 should agree that MBS-specific offsets can be applied to the R criteria to prioritize specific cells that provide MBS services of interest to the UE, allowing the offset to be set at "infinity", similar to LTE.

[0211] [Annex] LTE SIB13 The contents of LTE SIB13 are shown in Figures 20 to 22.

[0212] LTE SIB15 The contents of LTE SIB15 are shown in Figure 23.

[0213] LTE SIB20 The contents of SIB20 in LTE are shown in FIG.

[0214] SC-MCCH in LTE The contents of the SC-MCCH in LTE are shown in Figures 25 to 27.

[0215] MBMS Interest Indication in LTE The contents of the MBMS interest indication in LTE are shown in Figures 28 to 30.

[0216] Prioritized cell reselection in LTE The priority order for cell reselection of eMBMS frequencies in LTE is shown in FIG.

[0217] Cell-Level Prioritization in LTE Intra-frequency cell level prioritization and equal priority intra-frequency cell reselection in NB-IoT for CE (including eMTC) and LTE for UE are shown in Figure 32.

[0218] An example in which QoffsetSCPTM is set as the SCPTM frequency offset in SIB5 is shown in Figure 33.

[0219] [Appendix 2] (1. Introduction) A revised work item on NR Multicast and Broadcast Services (MBS) was approved in RAN#88. Regarding group scheduling aspects, RAN2#114 reached the following agreement:

[0220] One-to-one mapping between G-RNTI and MBS session is supported in NR MBS, other mappings require further study. One-to-one mapping between G-CS-RNTI and MBS session is supported in NR MBS, other mappings require further study. The UE can support multiple G-RNTI / G-CS-RNTIs. Whether this depends on the UE capabilities needs further study. This agreement is notified to RAN1. Multiple MBS QoS flows corresponding to the same MBS session can be mapped to one or more MBS radio bearers. The MCCH is mapped to the DL-SCH in NR MBS distribution mode 2. MTCH is specified for PTM transmission of NR MBS. The MTCH is mapped to the DL-SCH. DTCH is reused for PTP transmission of NR MBS. Further investigation is needed to determine whether the channels used require specific LCID spaces. Multiplexing / demultiplexing of different logical channels associated with the same G-RNTI is supported in NR MBS. Whether multiplexing / demultiplexing of different logical channels associated with the same G-CS-RNTI is supported in NR MBS requires further study. Multiplexing / demultiplexing of various logical channels associated with C-RNTI is supported in NR MBS.

[0221] Appendix 2 discusses the open issues identified in group scheduling. Note that these open issues are considered common issues for delivery mode 1 and delivery mode 2. Therefore, unless otherwise stated, the findings and suggestions apply to both delivery modes.

[0222] (2. Discussion) (3. Mapping between G-RNTI / G-CS-RNTI and MBS session) RAN2 has agreed to a 1:1 mapping between G-RNTI and MBS sessions, and between G-CS-RNTI and MBS sessions, but further study is required to determine whether other mappings are supported.

[0223] The advantage of 1:1 mapping, adopted in LTE SC-PTM, which is the simplest scheme and widely reused as the baseline for NR MBS, is that it avoids unnecessary UE power consumption due to attempting to receive MBS sessions that it is not interested in. For example, a UE that is only interested in TMGI#1 only needs to monitor G-RNTI#1. In other words, the UE does not attempt to decode PDSCHs assigned by PDCCHs scrambled with other G-RNTIs.

[0224] Observation 1: A 1:1 mapping from G-RNTI / G-CS-RNTI to MBS sessions is beneficial from the perspective of UE power consumption and simplicity.

[0225] Regarding 1:N mapping, one G-RNTI / G-CS-RNTI multiplexes multiple MBS sessions. For example, G-RNTI#1 conveys TMGI#1 and TMGI#2. This provides flexibility from a network perspective, since some MBS sessions requiring similar QoS may be transmitted over a single G-RNTI. It has also been pointed out that 1:N mapping may reduce UE complexity if a UE is interested in receiving multiple MBS sessions simultaneously. However, it is unclear whether such optimization is truly necessary. RAN2 already states that "UEs can support multiple G-RNTI / G-CS-RNTI. Whether this depends on UE capabilities is subject to further study." Therefore, UEs that need to simultaneously receive multiple MCPTT sessions, etc., only support such capabilities (if defined). Furthermore, 1:N mapping is inefficient for retransmissions. For example, if only one TMGI receives a NACK and the other receives an ACK, the entire transport block must be retransmitted.

[0226] On the other hand, this is not optimal from the UE power consumption point of view, since a UE that is only interested in TMGI#1 still needs to receive data from TMGI#2, i.e. it needs to decode a larger PDSCH than expected.

[0227] Observation 2: The 1:N mapping of G-RNTI / G-CS-RNTI to MBS sessions may provide flexibility in limited cases from the network perspective, but is not optimal from the UE power consumption perspective.

[0228] Regarding N:1 mapping, multiple G-RNTIs / G-CS-RNTIs convey one MBS session. For example, TMGI#1 can be considered as being split into G-RNTI#1 and G-RNTI#2. RAN2 agreed that "multiple MBS QoS flows corresponding to the same MBS session can be mapped to one or more MBS radio bearers." This may assume that these QoS flows require different QoS, e.g., one QoS flow for video streaming and another for text transfer within the same MBS session. Therefore, it makes sense for these QoS flows to be transmitted on different G-RNTIs, e.g., with different periodicities and resource amounts. Because the UE only needs to monitor the G-RNTI associated with the target MBS session (and QoS flow), a significant increase in UE power consumption is not expected.

[0229] Note: As in Observation 10, with 1:1 mapping, all QoS flows that correspond to the same MBS session and are mapped to multiple MRBs must be mapped to the same G-RNTI, even if the QoS requirements of these QoS flows are different. While 1:1 mapping is efficient in most cases, it may not be the same in all cases.

[0230] Observation 3: The N:1 mapping of G-RNTI / G-CS-RNTI to MBS sessions is efficient for different QoS flows with different QoS requirements and may have less impact on UE power consumption.

[0231] Considering the above observations, N:1 mapping is worth supporting, but 1:N mapping may not be very beneficial. Therefore, it is necessary to discuss whether RAN2 should support N:1 mapping in addition to 1:1 mapping.

[0232] Proposal 1: RAN2 needs to discuss whether N:1 mapping of G-RNTI / G-CS-RNTI to MBS sessions is additionally supported.

[0233] Figure 9 shows the UE capabilities for multiple G-RNTIs / G-CS-RNTIs.

[0234] 4. UE Capability for Multiple G-RNTI / G-CS-RNTI RAN2 agreed that "UEs can support multiple G-RNTI / G-CS-RNTIs," but "whether this depends on the UE capabilities requires further study."

[0235] In LTE SC-PTM, the UE function scptm-ParallelReception-r13 is defined as shown in FIG.

[0236] For NR MBS, similar UE capabilities can be used as a baseline, but there are still many open issues and NR-specific enhancements being discussed, such as the use of BWP / CFR (Common Frequency Resource). Therefore, it is premature to discuss UE capability aspects at this time.

[0237] Observation 4: UE functionality will be discussed after the functionality is solidified.

[0238] (5.LCID and LCID space of MCCH and MTCH) RAN2 stated that "further study is needed to determine whether specific LCID spaces are required for the channels used." In LTE eMBMS, separate LCID spaces are provided for the MCCH ("00000") and MTCH ("00001-11100", or in some cases "00000") of MCH, and for the SC-MCCH and SC-MTCH ("11001") of DL-SCH. This is feasible because eMBMS does not support the PDCP layer and only RLC-UM mode is applied.

[0239] In an LTE MBSFN, if an MCH does not have an MCCH, the MCCH and MTCH can share the same LCID (i.e., "00000"), but different MTCHs are assigned different LCIDs (i.e., "00001-11100"). Because "MTCH and MCCH can be multiplexed on the same MCH" and "multiple MBMS services can be mapped to the same MCH," i.e., because of the 1:N mapping as in Observation 11, different LCIDs are required to distinguish between an MCCH and different MTCHs. Needless to say, because an MCCH / MTCH is mapped to an MCH and a DTCH is mapped to a DL-SCH, the MCCH / MTCH LCID space is separated from the unicast LCID space. It is useful to avoid MBSFN LCIDs (i.e., MBMS area-specific and common to a group of UEs) from colliding with the same unicast LCID (i.e., cell-specific and UE-specific).

[0240] Observation 5: In LTE MBSFN, each MTCH has a different LCID (maximum 32 due to 1:N mapping), and the LCID of an MCCH may not be shared with an MTCH unless an MCH has no MCCH, and the MCCH / MTCH LCID space is separate from one for DTCH.

[0241] In LTE SC-PTM, the same LCID ("11001") is shared by the SC-MCCH, SC-MTCH, and multiple SC-MTCHs. Because the SC-MCCH is transmitted with the SC-RNTI and "SC-MCCH and SC-MTCH transmissions are each indicated by a logical channel-specific RNTI on the PDCCH (there is a one-to-one mapping between the TMGI used to receive the DL-SCH to which the SC-MTCH is mapped and the G-RNTI)," different LCIDs are not required to distinguish between the SC-MCCH and different SC-MTCHs. That is, the UE can distinguish these LCIDs by the RNTI. Similar to MBSFN, separate LCID spaces are in place by default to avoid LCID collisions between SC-PTM and unicast.

[0242] Observation 6: In LTESC-PTM, all MTCHs and MCCHs share the same LCID (due to 1:1 mapping and logical channel specific RNTI), and the LCID (space) is separated from the LCID space of DTCHs.

[0243] For NR MBS, similar to LTE SC-PTM, MCCH can be distinguished by RNTI since RAN2 agreed that a new RNTI is defined for MCCH scheduling. The same is true for MTCH, which means that MTCH can generally be distinguished from other logical channels by G-RNTI.

[0244] Observation 7: For NR MBS, the LCIDs for MCCH and MTCH can be shared with other logical channels because the UE can distinguish these logical channels by either the agreed new RNTI for MCCH or the G-RNTI for MTCH, regardless of the LCID.

[0245] On the other hand, for MTCHs, RAN2 agreed that "multiple MBS QoS flows corresponding to the same MBS session can be mapped to one or more MBS radio bearers." This allows us to simply assume that each MBS is associated with a separate LCH, as shown in Figure 9. Therefore, even if a 1:1 mapping between G-RNTI / G-CS-RNTI and MBS sessions is adopted, the UE cannot distinguish between MTCHs belonging to the same MBS session. In other words, the same G-RNTI / G-CS-RNTI can carry multiple MTCHs associated with the same MBS session. Therefore, the concept of one LCID shared by multiple MTCHs, as in LTE SC-PTM, does not apply to NR MBS; multiple LCIDs are required for MTCHs, as in LTE MBSFN.

[0246] Observation 8: For NR MBS, one LCID cannot be shared by multiple MTCHs. That is, even if a 1:1 mapping between G-RNTI / G-CS-RNTI and MBS session is assumed, multiple LCIDs are required since there may be multiple MRBs / MTCHs belonging to the same MBS session.

[0247] On the other hand, the method for defining LCIDs for MTCHs also depends on whether the principle of 1:1 mapping between G-RNTI / G-CS-RNTI and MBS sessions is maintained. Using 1:1 mapping, the UE can learn each MBS session from the corresponding G-RNTI. Therefore, LCIDs can be grouped by MBS session (or G-RNTI), so the number of LCIDs is equal to the number of MTCHs belonging to the same MBS session. For example, as shown in Figure 10, there are three LCIDs, regardless of the number of MBS sessions. Using N:1 mapping, the UE can also learn each MBS session from the corresponding G-RNTI. Therefore, the number of LCIDs is equal to the number of MTCHs mapped to the same G-RNTI. For example, as shown in Figure 10, there are a maximum of two LCIDs, regardless of the number of MBS sessions. If 1:N mapping is permitted, the UE cannot distinguish each MBS session from the G-RNTI. Therefore, the number of LCIDs is equal to the number of MTCHs for all MBS sessions. Therefore, more LCIDs may be required for 1:N mapping compared to 1:1 or N:1 mapping.

[0248] Observation 9: For NR MBS, the number of LCIDs in the MTCH is related to the G-RNTI / G-CS-RNTI to MBS session mapping rule (1:1, N:1, or 1:N).

[0249] Observation 10: For NR MBS, the 1:1 and N:1 mapping rules may result in fewer LCIDs for the MTCH compared to 1:N mapping.

[0250] In light of the above observations, each MTCH needs to be assigned a different LCID. This means defining the maximum number of LCIDs for an MTCH. At this point, according to the aforementioned LTE MBSFN, such a maximum number can be considered as 32, although a smaller number may be desirable.

[0251] Proposal 2: RAN2 needs to discuss the maximum number of LCIDs for MTCH, for example, less than 32 LCIDs based on LTE MBSFN as a possible baseline.

[0252] Also, in the context of the above observations, RAN2 needs to agree that MCCH and MTCH may share the same LCID to avoid consuming LCID unnecessarily.

[0253] Proposal 3: RAN2 should agree that MCCH and MTCH may share the same LCID, i.e., UEs differentiate MCCH by the agreed new RNTI and MTCH by the G-RNTI, but each MTCH is differentiated by its corresponding LCID.

[0254] The remaining question is whether the LCID space for MBS should be shared with the unicast LCID space or separated. Assuming 32 LCIDs as in Proposal 2, the eLCID space is large, so it may be acceptable for the eLCID to consume such codepoints exclusively for MBS. That is, 256 for a one-octet eLCID for primarily MAC CEs and 65,536 for a two-octet eLCID for primarily DTCHs. However, providing such a separate LCID space is questionable, as the actual benefits are unclear. From the UE MAC perspective, after receiving and demultiplexing the MAC PDUs, each MAC SDU is transmitted to the corresponding RLC entity. That is, the UE's behavior is the same regardless of whether these MAC SDUs are associated with an MCCH, MTCH, or DTCH. Furthermore, if a set of LCIDs (e.g., 32) is reserved for MBS by default, regardless of whether MBS service is provided (i.e., MCCH / MTCH are transmitted in the cell), it would be inefficient to use LCIDs.

[0255] Observation 11: For NR MBS, the benefit of using a separate LCID space for MBS is not clear from the UE's perspective.

[0256] Furthermore, NR MBS only supports Rel-17 single-cell transmission, meaning there is no standard support for SFN (single frequency network). Therefore, depending on the implementation, the gNB can fully manage the LCID of the MCCH / MTCH (cell-specific and common to all UEs) to ensure that it does not conflict with the LCID of the DTCH (UE-specific).

[0257] Observation 12: For NR MBS, since standard support is limited to single-cell transmission in Rel-17, NW implementations can manage LCIDs for MBS to avoid conflicts with unicast LCIDs even without a separate LCID space.

[0258] On the other hand, from a future-proofing perspective, e.g., for possible standard support of SFN, a separate LCID space for MBS would be beneficial, since the LCIDs for MBS would need to be coordinated across multiple cells / gNBs. This means that the LCIDs are MBS area specific and common to all UEs, which may risk conflicting with the LCIDs for DTCH (cell-specific and UE-specific). Therefore, it is necessary to discuss whether a separate LCID space is reserved for MCCH / MTCH in this release, just for future enhancements of MBS.

[0259] Proposal 4: RAN2 should discuss whether the LCID space for MCCH and MTCH should be separate from the LCID space for DTCH for future proofing (e.g., support for single frequency networks).

[0260] Incidentally, with regard to PTP transmission, RAN2 agreed to "reuse DTCH for PTP transmission of NR MBS." Therefore, we believe that the LCID for PTP transmission is not part of RAN2 that requires further consideration. In other words, it is quite natural for it to share the same LCID space as unicast. However, it may be beneficial for RAN2 to confirm the intent of the agreement.

[0261] Proposal 5: RAN2 should ensure that the DTCH for PTP transmission shares the LCID space with the DTCH for unicast, i.e., at least from a MAC perspective, PTP transmission is the same as traditional unicast.

[0262] (6. (De)multiplexing of different logical channels) RAN2 agreed that "multiplexing / demultiplexing of different logical channels associated with the same G-RNTI is supported in NR MBS" and "multiplexing / demultiplexing of different logical channels associated with C-RNTI is supported in NR MBS." RAN2 left it as follows: "Whether multiplexing / demultiplexing of different logical channels associated with the same G-CS-RNTI is supported in NR MBS requires further study."

[0263] It is recognized that further study is needed to (de)multiplex different logical channels with the G-CS-RNTI, but RAN2 has already agreed on one with the G-RNTI. As with the G-RNTI, there is no problem in supporting (de)multiplexing different logical channels with the same G-CS-RNTI.

[0264] Proposal 6: RAN2 should agree that (de)multiplexing of different logical channels associated with the same G-CS-RNTI is supported, as well as the G-RNTI.

[0265] (7.DRX for PTM transmission) RAN2 left it open that "For PTM transmission of NR MBS, further consideration is needed as to whether the DRX scheme is independent from the DRX of unicast transmission, e.g., supported per G-RNTI." In LTE SC-PTM, DRX of SC-MTCH is independent from DRX of unicast. Needless to say, in LTE MBSFN, DRX of MTCH (i.e., MBSFN subframe) is independent from DRX of unicast.

[0266] For NR MBS, the same principle applies: MTCH DRX is common to multiple UEs, while unicast DRX is UE-specific. Therefore, coordinating these DRXs is difficult and inefficient. Furthermore, since RAN2 already agrees that "multiplexing / demultiplexing of different logical channels associated with the same G-RNTI is supported in NR MBS," MTCH DRX is configured per G-RNTI. UEs wake up during PTM transmission opportunities (on periods) to monitor the associated G-RNTI. Therefore, RAN2 must agree that DRX configuration is provided per G-RNTI, which is independent from unicast DRX.

[0267] Proposal 7: RAN2 should agree that PTM DRX is independent from unicast DRX and is configured per G-RNTI.

[0268] (8. DRX parameters for transmission mode 1) MTCH reception in delivery mode 1 is essentially performed by UEs in RRC connected state and has similar characteristics to DTCH, i.e., unicast, since it supports dynamic scheduling, HARQ feedback / retransmission, etc. Therefore, it makes sense to reuse the DRX parameters, i.e., DRX configuration, of unicast.

[0269] Proposal 8: RAN2 should agree that the DRX parameters for PTM transmission via distribution mode 1 should use the one for unicast, i.e., the DRX settings, as the baseline.

[0270] If we agree with Proposal 8, we need to discuss which exact parameters should be introduced for PTM transmission via distribution mode 1. As shown in Figure 35, UL retransmission is not applicable to NR MBS, so parameters related to UL retransmission are obviously not necessary. Furthermore, parameters related to short DRX are also not necessary, because short DRX may not be very efficient for MBS traffic. For example, typical MBS traffic is assumed to be a type of voice and video, so their transmission cycle may be stable and suitable for long DRX. Also, LTE SC-PTM does not have a short DRX option, as shown in Figure 36. In other words, parameters related to long DRX and DL retransmission can be reused as they are.

[0271] Proposal 9: In addition to proposal 8 (i.e. unicast DRX as a baseline for PTM transmission over distribution mode 1), RAN2 should agree that parameters related to UL retransmissions and short DRX are not required.

[0272] (9. DRX parameters for transmission mode 2) RAN2 agreed that "for NR MBS distribution mode 2, the LTE SC-PTM DRX scheme will be used as the baseline." The DRX parameters for LTE SC-PTM are shown in Figure 36, which is essentially the same as Figure 35 / proposal 30 (i.e., for PTM transmission via distribution mode 1) for parameters related to DL retransmissions. If parameters related to DL retransmissions, which are not required for distribution mode 2, are excluded, the on-duration timer, inactivity timer, scheduling period, and start offset can be reused without major issues.

[0273] Observation 13: We can confirm the baseline of DRX parameters for PTM transmission via distribution mode 2, i.e., the baseline based on SC-MTCH scheduling information.

[0274] (10. DRX for PTP transmission) RAN2 left open the question of whether "for PTP transmission, whether to reuse the DRX operation of unicast transmission" to be considered further. Meanwhile, RAN2 already agreed that "multiplexing / demultiplexing of different logical channels associated with C-RNTI is supported in NR MBS." This is not limited to different logical channels belonging to MBS services. That is, they may be (de)multiplexed with unicast services. Furthermore, RAN2 agreed that "DTCH is reused for PTP transmission in NR MBS." This means that MAC does not need to know whether each MAC SDU for DTCH belongs to a DRB or an MRB. It is also already clear that PTP transmission is transmitted using the same C-RNTI as existing unicast transmission. In this sense, PTP transmission is exactly the same and consistent with unicast transmission, at least from the perspective of DRX operation.

[0275] Proposal 10: RAN2 should agree that for PTP reception, the UE will only wake up for unicast On-periods, i.e., no additional On-periods or specific extensions of PTP transmissions, at least from a DRX perspective. [Explanation of symbols]

[0276] 1: Mobile communication system 10:RAN 20 :CN 100:UE 110: Receiving unit 120: Transmitter 130: Control unit 200 :gNB 210: Transmission unit 220: Receiving unit 230: Control unit 240: Backhaul communication unit

Claims

1. A communication method used in a user equipment that performs a reception process of a physical downlink control channel (PDCCH) from a base station using a radio network temporary identifier (RNTI), comprising: When N (N≧2) group RNTIs (G-RNTIs) are associated with one multicast broadcast service (MBS) session, identifying M (M≦N) G-RNTIs to be used for the reception process from among the N G-RNTIs; performing the reception processing using the M G-RNTIs; The identifying step includes: Identifying a desired QoS (Quality of Service) flow that the user equipment wishes to receive from among K (K≧2) QoS flows associated with the one MBS session; Identifying the M G-RNTIs associated with the desired QoS flows; Contains Communication method.

2. Performing the reception processing includes performing the reception processing using the M G-RNTIs without using (N-M) G-RNTIs out of the N G-RNTIs for the reception processing in the reception of the MBS session. The communication method according to claim 1 .

3. The method further includes receiving, from the base station, information associating the one MBS session, the K QoS flows, and the N G-RNTIs. The communication method according to claim 1 .

4. and transmitting a message to the base station including an identifier of the MBS session and an identifier for the desired QoS flow. The communication method according to claim 1 .

5. A user equipment (UE) that performs a receiving process of a physical downlink control channel (PDCCH) from a base station using a radio network temporary identifier (RNTI), A control unit that identifies M (M≦N) G-RNTIs to be used for the reception process from among the N G-RNTIs when N (N≧2) group RNTIs (G-RNTIs) are associated with one multicast broadcast service (MBS) session; a communication unit that performs the reception process using the M G-RNTIs, The control unit Identifying a desired QoS (Quality of Service) flow that the user equipment wishes to receive from among K (K≧2) QoS flows associated with the one MBS session; Identifying the M G-RNTIs associated with the desired QoS flows. User equipment.

Images