Communication method and user device

Abstract

A first aspect relates to a communication method for use in a mobile communication system supporting a multicast and broadcast service (MBS), the communication method comprising user equipment, performing MBS reception or having an interest in the MBS reception in a wireless resource control (RRC) connected state, transmitting an RRC message to a base station. The transmitting includes transmitting the RRC message including an information element indicating a mode desired by the user equipment as an MBS delivery mode or an MBS reception mode from the base station.

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 for use in a mobile communication system supporting a Multicast Broadcast Service (MBS), comprising: a user equipment (UE) in a Radio Resource Control (RRC) Connected state receiving an MBS or interested in receiving the MBS, transmitting an RRC message to a base station, the transmitting including an information element regarding an MBS delivery mode or an MBS reception mode desired by the user equipment from the base station.

[0005] A communication method according to a second aspect is a communication method used in a mobile communication system supporting a multicast broadcast service (MBS), and includes a radio resource control (RRC) message transmitted to a base station by a user equipment (UE) in a connected state that is receiving MBS for a plurality of MBS sessions or that is interested in receiving the MBS. The transmitting step includes: To the base station transmitting the RRC message including the notification information element.

[0006] A communication method according to a third aspect is a communication method for use in a mobile communication system supporting a Multicast Broadcast Service (MBS), comprising: a user equipment (UE) in a Radio Resource Control (RRC) Connected state receiving an MBS or interested in receiving the MBS, transmitting an RRC message to a base station, the RRC message including an information element indicating whether multicast reception is prioritized over unicast reception, even when the user equipment (UE) is participating in a multicast session. [Brief explanation of the drawings]

[0007] [Figure 1] 1 is a diagram illustrating a configuration of a mobile communication system according to an embodiment. [Figure 2] 1 is a diagram illustrating a configuration of a UE (user equipment) according to an embodiment. [Figure 3] A diagram showing the configuration of a gNB (base station) according to an 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 an embodiment. [Figure 7]FIG. 10 is a diagram illustrating a distribution mode according to the embodiment. [Figure 8] FIG. 1 illustrates a split MRB according to an embodiment. [Figure 9] FIG. 2 is a diagram illustrating an operation of the mobile communication system according to the first embodiment. [Figure 10] FIG. 2 is a diagram illustrating an example of the configuration of an RRC message according to the first embodiment. [Figure 11] FIG. 10 is a diagram illustrating another example of the configuration of an RRC message according to the first embodiment. [Figure 12] FIG. 10 is a diagram illustrating a partial modification of the operation of the mobile communication system according to the first embodiment. [Figure 13] FIG. 10 is a diagram showing a modification of the first embodiment. [Figure 14] FIG. 10 is a diagram illustrating an example of the configuration of an RRC message according to a modification of the first embodiment. [Figure 15] FIG. 10 is a diagram illustrating an operation according to the second embodiment. [Figure 16] FIG. 13 shows an overview of the Stage 2 control plane aspects of the distributed mode. [Figure 17] FIG. 10 is a diagram showing one-step setting of distribution mode 2. [Figure 18] A diagram showing LTE MBMS interest indication (excluding ROM-related settings). [Figure 19] A diagram showing the contents of SIB13 of LTE. [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 SIB15 of LTE. [Figure 23] A diagram showing the contents of SIB20 in LTE. [Figure 24] FIG. 1 is a diagram showing the contents of the SC-MCCH of 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] A diagram showing the contents of MBMS interest indication in 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] FIG. 1 is a diagram illustrating the priority of cell reselection for eMBMS frequencies in LTE. [Figure 31] 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 32] A figure showing an example in which QoffsetSCPTM is set as the SCPTM frequency offset in SIB5. 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 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 a radio interface protocol.

[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 TMGI (Temporary Mobile Group Identity), 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 used as an MBS session identifier. With children The TMGI, source-specific IP multicast address, session identifier, and 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] As described above, there are two delivery modes for MBS data: a first delivery mode and a second delivery mode. Each MBS session is delivered from the gNB 200 in either the first delivery mode or the second delivery mode. Although the UE 100 can simultaneously receive multiple MBS sessions, it may not be able to simultaneously receive multiple MBS sessions to which different delivery modes are applied. Furthermore, the second delivery mode allows MBS reception even when the UE 100 is in an RRC idle state or an RRC inactive state, and the second delivery mode may be preferable for a UE 100 that wishes to receive MBS data with low power consumption. Therefore, if the gNB 200 can determine the delivery mode desired by the UE 100, appropriate and efficient MBS delivery is expected to be possible.

[0074] 9 is a diagram showing the operation of the mobile communication system 1 according to the first embodiment. It is assumed that the UE 100 is in an RRC connected state in a cell (serving cell) of the gNB 200.

[0075] In step S11, the UE 100 is in a state of receiving an MBS or is interested in receiving an MBS.

[0076] In step S12, the UE 100 generates an RRC message and transmits the generated RRC message to the gNB 200. The gNB 200 receives the RRC message. The RRC message is, for example, a message that the UE 100 can autonomously transmit, and may be an MBS Interest Indication message or a UE Assistance Information message.

[0077] Here, UE 100 transmits an RRC message including an information element (hereinafter referred to as a "desired mode information element") indicating a mode desired by UE 100 as an MBS transmission mode or MBS reception mode from gNB 200. This allows gNB 200 to know the MBS transmission mode or MBS reception mode desired by UE 100 based on the desired mode information element included in the received RRC message, thereby enabling appropriate and efficient MBS transmission.

[0078] The RRC message may include identifiers of one or more MBS sessions (MBS session identifiers) for which UE 100 is receiving MBS or is interested in receiving MBS, and a desired mode information element associated with each of the one or more MBS session identifiers. That is, the RRC message may include information that associates the MBS sessions (MBS session identifiers) for which UE 100 is receiving MBS or is interested in receiving MBS with the desired mode (desired mode information element).

[0079] The desired mode information element may be an information element indicating a delivery mode desired by the UE 100 from among a plurality of delivery modes as MBS delivery modes. For example, the desired mode information element may be an information element indicating a delivery mode desired (preferred) by the UE 100 from among the first delivery mode and the second delivery mode. The desired mode information element may be an information element indicating a preference for the delivery mode and / or an information element indicating a priority order of the delivery modes (e.g., giving priority to reception in the first delivery mode over the second delivery mode).

[0080] Here, the first distribution mode is an example of a distribution mode for a multicast session, and the second distribution mode is an example of a distribution mode for a broadcast session. Also, the first distribution mode is an example of a distribution mode for an RRC connected state, and the second distribution mode is an example of a distribution mode for all RRC states (RRC connected state, RRC idle state, and RRC inactive state). Furthermore, the first distribution mode is an example of a distribution mode in which MBS reception setting is performed by UE-dedicated signaling from the gNB200, and the second distribution mode is an example of a distribution mode in which MBS reception setting is performed by broadcast signaling from the gNB200.

[0081] Fig. 10 is a diagram showing an example of the configuration of an RRC message according to the first embodiment. The RRC message includes a correspondence between an MBS session identifier for which UE 100 is receiving or is interested in receiving MBS and a desired mode information element. In Fig. 10, the RRC message includes an MBS session identifier #1 and an MBS session identifier #2, and shows an example in which a desired mode information element is associated with each MBS session identifier. Each desired mode information element indicates one of a first transmission mode and a second transmission mode.

[0082] Alternatively, the desired mode information element may be associated with an MBS frequency identifier (or a cell identifier) ​​instead of or in addition to the MBS session identifier. For example, as shown in Fig. 11, the RRC message may include one or more MBS frequency identifiers (or cell identifiers) from which the UE 100 is receiving MBS or is interested in receiving MBS, and a desired mode information element associated with each of the one or more MBS frequency identifiers (or cell identifiers).

[0083] The desired mode information element may be an information element indicating that the UE 100 desires low power consumption MBS reception as the MBS reception mode. This allows the gNB 200 to understand that the UE 100 desires low power consumption MBS reception based on the desired mode information element included in the received RRC message. The desired mode information element may include at least one of the following information:

[0084] - Information indicating that the default QoS does not have to be met.

[0085] - Information indicating a desire to receive low-power MBS.

[0086] Information indicating your preference for the second delivery mode: This indicates that the UE 100 desires to receive an MBS in the RRC idle state / RRC inactive state.

[0087] -Information indicating that you wish to receive PTP in the first distribution mode: In the case of split MRB shown in Figure 8, PTP leg reception is always on to perform unicast reception, but PTM leg reception requires additional power consumption. Also, while PTP has an optimized MCS like unicast, PTM is received by multiple UEs, so the MCS is not optimal and longer / more reception operations are required. Therefore, low power consumption operation can be achieved by performing only PTP reception in the first distribution mode.

[0088] Information indicating a desire not to switch from PTP to PTM.

[0089] Information indicating that UE 100 wishes to turn off feedback (e.g., HARQ feedback) to gNB 200.

[0090] - Information indicating that you do not wish to receive certain MRBs.

[0091] Returning to FIG. 9, in step S13, gNB200 performs one of the following MBS delivery controls based on the desired mode information element included in the RRC message received from UE100 in step S12.

[0092] Change the delivery mode for an MBS session: For example, the gNB 200 changes an MBS session currently being delivered in the second delivery mode to the first delivery mode. Alternatively, the gNB 200 changes an MBS session currently being delivered in the first delivery mode to the second delivery mode. The change to the second delivery mode may be for the purpose of receiving an MBS with low power consumption.

[0093] Perform handover of UE 100: For example, the gNB 200 hands over a UE 100 that wishes to receive an MBS session in the second distribution mode to a cell that distributes the MBS session in the second distribution mode, or the gNB 200 hands over a UE 100 that wishes to receive an MBS session in the first distribution mode to a cell that distributes the MBS session in the first distribution mode.

[0094] -Schedule or change settings to enable low-power MBS reception: For example, the gNB 200 provides an MBS session using PTP. The gNB 200 may configure the UE 100 to turn off feedback.

[0095] FIG. 12 is a diagram showing a partial modification of the operation of the mobile communication system 1 according to the first embodiment.

[0096] In step S101, the gNB 200 transmits configuration information indicating that transmission of an RRC message including a desired mode information element is permitted to the UE 100. The gNB 200 may transmit the configuration information by UE-dedicated signaling (RRC Reconfiguration message) or broadcast signaling (SIB or MCCH).

[0097] The UE 100 may be able to transmit the desired mode information element (step S12) only when such permission is granted. The UE 100 may be able to transmit the desired mode information element (step S12) only when a condition is satisfied that the remaining battery charge is equal to or less than a threshold. The threshold may be set in the UE 100 by the gNB 200.

[0098] According to the first embodiment, the UE 100 transmits to the gNB 200 an RRC message including a desired mode information element indicating a mode desired by the UE 100 as an MBS transmission mode or an MBS reception mode from the gNB 200. This allows the gNB 200 to know the MBS transmission mode or MBS reception mode desired by the UE 100 based on the desired mode information element included in the received RRC message, thereby enabling appropriate and efficient MBS transmission.

[0099] [Modification of the first embodiment] A modification of the first embodiment will be described, focusing on differences from the above-described first embodiment. Fig. 13 is a diagram illustrating a modification of the first embodiment. It is assumed that the UE 100 is in an RRC connected state in a cell (serving cell) of the gNB 200.

[0100] In step S21, the UE 100 is in a state of receiving MBSs of a plurality of MBS sessions or is interested in receiving the MBSs.

[0101] In step S22, the UE 100 generates an RRC message and transmits the generated RRC message to the gNB 200. The gNB 200 receives the RRC message. The RRC message is, for example, a message that the UE 100 can autonomously transmit, and may be an MBS Interest Indication message or a UE Assistance Information message.

[0102] Here, the UE 100 determines the reception priority for each MBS session and transmits an RRC message including an information element notifying the reception priority for each MBS session. The reception priority for each MBS session may be notified from the NAS layer to the AS layer. The AS layer may notify the gNB 200 of the reception priority notified from the NAS layer.

[0103] Fig. 14 is a diagram showing an example of the configuration of an RRC message according to this modification. The RRC message includes a correspondence between an MBS session identifier for which UE 100 is receiving MBS or is interested in receiving MBS and a priority level. In Fig. 14, the RRC message includes MBS session identifier #1 and MBS session identifier #2, and shows an example in which a priority level (reception priority level) is associated with each MBS session identifier. Here, MBS session identifier #1 has the highest priority level, and MBS session identifier #2 has the second highest priority level.

[0104] Alternatively, instead of or in addition to the MBS session identifier, an MBS frequency identifier (or cell identifier) ​​may be associated with a reception priority. For example, the RRC message may include one or more MBS frequency identifiers (or cell identifiers) from which the UE 100 is receiving MBS or is interested in receiving MBS, and priority information associated with each of the one or more MBS frequency identifiers (or cell identifiers).

[0105] Instead of explicitly notifying the gNB 200 of the priority, the priority may be implicitly notified to the gNB 200. For example, the RRC message may include a list of MBS session identifiers (or MBS frequency identifiers, or cell identifiers) arranged in order of priority, where the position of an entry in the list indicates the priority.

[0106] 13, in step S23, the gNB 200 performs the above-described MBS delivery control based on the information element included in the RRC message received from the UE 100 in step S22. For example, the gNB 200 may perform handover of the UE 100. If the gNB 200 (its own cell) is not providing an MBS session with a high priority, the gNB 200 may handover the UE 100 to another cell that provides the MBS session.

[0107] In addition, as in Figure 12, gNB200 may transmit configuration information to UE100 indicating that transmission of an RRC message including the information element is permitted.

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

[0109] In the second embodiment, it is mainly assumed that in the first delivery mode, the UE 100 in the RRC connected state receives MBS data (i.e., multicast data) transmitted by multicast from the gNB 200. For this reason, it is assumed that the MBS session is a multicast session. The multicast session may be mapped to a PTM leg or a PTM bearer (MRB). Note that an MBS traffic channel (MTCH) is used to transmit the multicast data from the gNB 200 to the UE 100.

[0110] 15 is a diagram showing the operation according to the second embodiment. It is assumed that the UE 100 is in an RRC connected state in a cell (serving cell) of the gNB 200.

[0111] In step S31, it is assumed that UE 100 in the RRC connected state has become interested in a certain multicast session (hereinafter referred to as the "target multicast session"). "Being interested in a multicast session" means that an upper layer of UE 100 requests or desires to receive the multicast session. The upper layer includes a NAS layer. The upper layer may further include an application. UE 100 (NAS entity) may perform a multicast session join procedure to the network (CN 20) to join the targeted multicast session. For example, UE 100 joins the targeted multicast session by sending a first NAS message to AMF 300A requesting participation in the targeted multicast session and receiving a second NAS message from AMF 300A approving participation in the targeted multicast session. "Joining the targeted multicast session" means registering UE 100 in the CN device as a member of a UE group (multicast group) that receives the multicast session. Note that participation in a multicast session may be performed when the multicast session is in an enabled state (transmitting) or an disabled state (waiting for transmission to start or transmission suspended).

[0112] In step S32, CN20 (AMF300A) may notify gNB200 of UE100's MBS interest information (MBS frequency, MBS session identifier, etc.).

[0113] In step S33, gNB200 may retain the information from CN20 as UE context information of UE100.

[0114] In this way, when UE 100 is participating in a multicast session, gNB 200 can acquire UE 100's MBS interest information (MBS frequency, MBS session identifier, etc.) from CN 20, so it is considered that there is little need for UE 100 to transmit MBS interest information (RRC message) to gNB 200. However, there is a concern that gNB 200 may not be able to acquire from CN 20 priority information on whether multicast reception (MBS reception) is prioritized over unicast reception.

[0115] In step S34, even when UE 100 is participating in a multicast session, UE 100 transmits an RRC message including an information element indicating whether multicast reception is prioritized over unicast reception to gNB 200. gNB 200 receives the RRC message. The RRC message is, for example, a message that UE 100 can transmit autonomously, and may be an MBS Interest Indication message or a UE Assistance Information message.

[0116] This allows gNB200 to obtain priority information from UE100 regarding whether multicast reception (MBS reception) is prioritized over unicast reception, and to understand whether UE100 prioritizes multicast reception (MBS reception) over unicast reception.

[0117] In step S35, gNB200 retains the information elements included in the RRC message received in step S34 as UE context information of UE100.

[0118] Although the case where UE 100 participates in a multicast session has been described, if UE 100 does not participate in a multicast session, it is considered that gNB 200 cannot acquire UE 100's MBS interest information (MBS frequency, MBS session identifier, etc.) from CN 20. Therefore, for example, if UE 100 in an RRC connected state is receiving a broadcast session or is interested in receiving a broadcast session, UE 100 notifies gNB 200 of UE 100's MBS interest information (MBS frequency, MBS session identifier, etc.).

[0119] That is, when UE 100 is not participating in a multicast session, UE 100 transmits to gNB 200 an RRC message including an information element indicating whether multicast reception (MBS reception) is prioritized over unicast reception and other information elements indicating MBS sessions and / or MBS frequencies in which UE 100 is receiving MBS or is interested in receiving MBS (step S34).On the other hand, when UE 100 is participating in a multicast session, UE 100 transmits to gNB 200 an RRC message including an information element indicating whether multicast reception (MBS reception) is prioritized over unicast reception, without including the other information elements (step S34).

[0120] According to the second embodiment, even when the UE 100 is participating in a multicast session, the UE 100 transmits an RRC message including an information element indicating whether multicast reception is prioritized over unicast reception to the gNB 200. M In a situation where BS interest information (MBS frequency, MBS session identifier, etc.) can be obtained from CN20, priority information that gNB200 cannot obtain from CN20 can be provided to gNB200 from UE100.

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

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

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

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

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

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

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

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

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

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

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

[0132] This appendix provides details of the control plane aspects of delivery mode 2, considering the baseline LTE eMBMS mechanism.

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

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

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

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

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

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

[0139] (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.

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

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

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

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

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

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

[0146] The possible "other information" can be interpreted as neighboring cell / frequency information, which will be explained 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.

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

[0148] (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.

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

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

[0151] (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.

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

[0153] (9. One-step setup) Another possibility is to merge the MCCH with the BCCH, i.e., one-step configuration as shown in Figure 17, 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.

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

[0155] (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.

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

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

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

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

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

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

[0162] (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.

[0163] (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.

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

[0165] (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.

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

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

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

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

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

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

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

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

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

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

[0176] (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.

[0177] In LTE, the MBMS interest indication includes three IEs, excluding ROM-related settings (shown in Figure 18). 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.

[0178] Proposal 13: RAN2 should 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.

[0179] Since the minimum MBS service area may be the cell of an 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, the gNB provides neighbor cell information, so 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.

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

[0181] (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.

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

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

[0184] (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.

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

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

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

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

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

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

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

[0192] Proposal 8: 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.

[0193] (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.

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

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

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

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

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

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

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

[0201] (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.

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

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

[0204] [Annex] LTE SIB13 The contents of LTE SIB13 are shown in Figures 19 to 21.

[0205] LTE SIB15 The contents of LTE SIB15 are shown in Figure 22.

[0206] LTE SIB20 The contents of LTE SIB20 are shown in Figure 23.

[0207] SC-MCCH in LTE The contents of the SC-MCCH in LTE are shown in Figures 24 to 26.

[0208] MBMS Interest Indication in LTE The contents of the MBMS interest indication in LTE are shown in Figures 27 to 29.

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

[0210] 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 31.

[0211] An example in which QoffsetSCPTM is set as the SCPTM frequency offset in SIB5 is shown in Figure 32. [Explanation of symbols]

[0212] 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. 1. A communication method for use in a mobile communication system supporting a multicast broadcast service (MBS), comprising: a user equipment receiving or interested in receiving an MBS in a Radio Resource Control (RRC) Connected state, sending an RRC message to a base station; the transmitting step includes transmitting the RRC message including an information element regarding a mode desired by the user equipment as an MBS transmission mode or an MBS reception mode from the base station; The information element includes at least one of an information element indicating a desire to receive an MBS in an RRC idle state or an RRC inactive state, and an information element indicating that a certain MRB is not desired to be received. Communication method.

2. The RRC message includes identifiers of one or more MBS sessions in which the user equipment is receiving or is interested in receiving the MBS, and the information element associated with each of the identifiers of the one or more MBS sessions. The communication method according to claim 1 .

3. The information element is an information element indicating a distribution mode desired by the user device from among a plurality of distribution modes as the MBS distribution mode. The communication method according to claim 1 or 2.

4. The plurality of delivery modes includes a delivery mode for a multicast session and a delivery mode for a broadcast session. The communication method according to claim 3 .

5. The plurality of delivery modes includes a delivery mode for an RRC connected state and a delivery mode for all RRC states. The communication method according to claim 3 .

6. The plurality of distribution modes include a distribution mode in which MBS reception setting is performed by user equipment dedicated signaling, and a distribution mode in which the MBS reception setting is performed by broadcast signaling. The communication method according to claim 3 .

7. 1. A communication method for use in a mobile communication system supporting a multicast broadcast service (MBS), comprising: a user equipment receiving or interested in receiving an MBS in a Radio Resource Control (RRC) Connected state, sending an RRC message to a base station; The transmitting step includes: transmitting the RRC message including an information element indicating whether multicast reception is prioritized over unicast reception even when the user equipment is participating in a multicast session; If the user equipment is not participating in the multicast session, transmitting the RRC message including the information element and other information elements indicating MBS sessions and / or MBS frequencies on which the user equipment is receiving or is interested in receiving MBS; If the user equipment is participating in the multicast session, transmitting the RRC message including the information element without including the other information elements. Communication method.

8. A user device, A transmitter for transmitting an RRC message to a base station when a multicast broadcast service (MBS) is being received or the base station is interested in receiving the MBS in a radio resource control (RRC) connected state, The transmitter transmits the RRC message including an information element indicating whether multicast reception is prioritized over unicast reception even when the user equipment is participating in a multicast session; The information element includes at least one of an information element indicating a desire to receive an MBS in an RRC idle state or an RRC inactive state, and an information element indicating that a certain MRB is not desired to be received. User equipment.

9. A user equipment for use in a mobile communication system supporting a multicast broadcast service (MBS), comprising: a transmitter for transmitting an RRC message to a base station when the mobile station is in a radio resource control (RRC) connected state and is receiving an MBS or is interested in receiving the MBS; The transmission unit transmitting the RRC message including an information element indicating whether multicast reception is prioritized over unicast reception even when the user equipment is participating in a multicast session; If the user equipment is not participating in the multicast session, sending the RRC message including the information element and other information elements indicating MBS sessions and / or MBS frequencies in which the user equipment is receiving or is interested in receiving MBS; If the user equipment is participating in the multicast session, the RRC message including the information element is transmitted without including the other information elements. User equipment.

Images