Communication methods, user devices, chipsets, programs, network nodes, and mobile communication systems

Abstract

This invention provides a communication control method and user equipment that realize improved multicast broadcast services (MBS). [Solution] In a mobile communication system, user equipment 100 performs a process that includes receiving MBS settings transmitted via dedicated signaling from a base station 200, and receiving MBS settings transmitted via multicast signaling from a base station. The MBS settings transmitted via dedicated signaling include scheduling information for an MBS traffic channel corresponding to an MBS multicast session, and the MBS settings transmitted via multicast signaling include scheduling information corresponding to the same MBS multicast session as the MBS multicast session.

Description

Technical Field

[0001] The present disclosure relates to a communication control method and a user device used in a mobile communication system.

Background Art

[0002] In recent years, the fifth-generation (5G) mobile communication system has attracted attention. NR (New Radio), which is a radio access technology (RAT) of the 5G system, has characteristics such as high speed, large capacity, high reliability, and low latency compared to LTE (Long Term Evolution), which is a fourth-generation radio access technology.

Prior Art Documents

Non-Patent Documents

[0003]

Non-Patent Document 1

Summary of the Invention

[0004] The communication control method according to the first aspect is a method used in a mobile communication system that provides a multicast / broadcast service (MBS) from a base station to a user device. The communication control method includes the base station transmitting switching information to the user device for switching a delivery mode between a first mode in which MBS settings are provided by dedicated signaling and a second mode in which MBS settings are provided by broadcast signaling, and the user device that has received the switching information performing mode switching between the first mode and the second mode based on the switching information.

[0005] The user device according to the second embodiment is a device used in a mobile communication system that provides multicast broadcast service (MBS). The user device includes a receiving unit that receives switching information from a base station for switching the distribution mode between a first mode in which MBS settings are provided by dedicated signaling and a second mode in which MBS settings are provided by broadcast signaling, and a control unit that performs mode switching between the first mode and the second mode based on the switching information. [Brief explanation of the drawing]

[0006] [Figure 1] This figure shows the configuration of a mobile communication system according to one embodiment. [Figure 2] This diagram shows the configuration of a UE (User Equipment) according to one embodiment. [Figure 3] This diagram shows the configuration of a gNB (base station) according to one embodiment. [Figure 4] This diagram shows the protocol stack configuration of the user plane wireless interface that handles data. [Figure 5] This diagram shows the protocol stack configuration of the wireless interface of the control plane that handles signaling (control signals). [Figure 6] This figure shows an overview of MBS traffic distribution according to one embodiment. [Figure 7] This figure shows a distribution mode according to one embodiment. [Figure 8] This figure shows a split MBS bearer according to one embodiment. [Figure 9] This figure shows an example of operation in the first mode according to one embodiment. [Figure 10] This figure shows an example of the configuration of an RRC Reconfiguration message according to one embodiment. [Figure 11] This figure shows an example of operation in the second mode according to one embodiment. [Figure 12] This figure shows variations in MBS settings in the second mode according to one embodiment. [Figure 13] It is a diagram showing a configuration example of a broadcast message according to an embodiment. [Figure 14] It is a diagram showing an operation according to an embodiment. [Figure 15] It is a diagram showing a first operation example according to an embodiment. [Figure 16] It is a diagram showing a second operation example according to an embodiment. [Figure 17] It is a diagram showing a third operation example according to an embodiment. [Figure 18] It is a diagram showing a fourth operation example according to an embodiment. [Figure 19] It is a diagram showing a fifth operation example according to an embodiment. [Figure 20] It is a diagram showing an example of the structure of the distribution mode 1 setting. [Figure 21] It is a diagram showing a two-stage setting in LTE SC-PTM.

Embodiments for Carrying Out the Invention

[0007] It is considered to introduce a multicast / broadcast service into a 5G system (NR). The multicast / broadcast service of NR is desired to provide a service improved from the multicast / broadcast service of LTE.

[0008] Therefore, the present disclosure aims to realize an improved multicast / broadcast service.

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

[0010] (Configuration of Mobile Communication System) First, the configuration of the mobile communication system according to the embodiment will be described.

[0011] FIG. 1 is a diagram showing the configuration of a mobile communication system according to an embodiment. This mobile communication system complies with the 5th generation system (5GS) of the 3GPP standard. In the following, 5GS will be taken as an example for description, but the LTE (Long Term Evolution) system and / or the 6th generation (6G) system may be at least partially applied to the mobile communication system.

[0012] As shown in FIG. 1, the mobile communication system includes a user equipment (UE) 100, a 5G radio access network (NG-RAN) 10, and a 5G core network (5GC) 20.

[0013] The UE 100 is a movable wireless communication device. The UE 100 can be any device as long as it is used by a user. For example, the UE 100 can be a mobile phone terminal (including smartphones), a tablet terminal, a notebook PC, a communication module (including a communication card or chipset), a sensor or a device provided on the sensor, a vehicle or a device provided on the vehicle (Vehicle UE), and / or an aircraft or a device provided on the aircraft (Aerial UE).

[0014] NG-RAN10 includes base stations (referred to as "gNBs" in 5G systems) 200. The gNBs 200 are interconnected via the Xn interface, which is an inter-base station interface. Each gNB 200 manages one or more cells. The gNB 200 performs wireless communication with UEs 100 that have established a connection with its own cell. The gNB 200 has radio resource management (RRM) functions, user data routing functions (hereinafter simply referred to as "data"), and / or measurement and control functions for mobility control and scheduling. "Cell" is used as a term to indicate the smallest unit of a wireless communication area. "Cell" is also used as a term to indicate a function or resource that performs wireless communication with a UE 100. One cell belongs to one carrier frequency.

[0015] Furthermore, gNBs can also connect to the EPC (Evolved Packet Core), which is the core network of LTE. LTE base stations can also connect to 5GCs. LTE base stations and gNBs can also be connected via an inter-base station interface.

[0016] The 5GC20 includes the AMF (Access and Mobility Management Function) and the UPF (User Plane Function) 300. The AMF performs various mobility controls for the UE100. The AMF manages the mobility of the UE100 by communicating with it using NAS (Non-Access Stratum) signaling. The UPF controls data transfer. The AMF and UPF are connected to the gNB200 via the NG interface, which is the base station-core network interface.

[0017] Figure 2 shows the configuration of UE100 (user device) according to one embodiment.

[0018] As shown in Figure 2, the UE100 comprises a receiving unit 110, a transmitting unit 120, and a control unit 130.

[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 the radio signal received by the antenna into a baseband signal (received signal) and outputs it to the control unit 130.

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

[0021] The control unit 130 performs various controls on the UE100. 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 for processing by the processor. The processor may include a baseband processor and a CPU (Central Processing Unit). The baseband processor performs modulation, demodulation, encoding, and decoding of baseband signals. The CPU executes programs stored in memory and performs various processing.

[0022] Figure 3 shows the configuration of a gNB200 (base station) according to one embodiment.

[0023] As shown in Figure 3, the gNB200 comprises a transmitting unit 210, a receiving unit 220, a control unit 230, and a backhaul communication unit 240.

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

[0025] 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 the radio signal received by the antenna into a baseband signal (received signal) and outputs it to the control unit 230.

[0026] The control unit 230 performs various controls in the gNB200. 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 for processing by the processor. The processor may include a baseband processor and a CPU. The baseband processor performs modulation, demodulation, encoding, and decoding of baseband signals. The CPU executes programs stored in memory and performs various processing.

[0027] The backhaul communication unit 240 is connected to an adjacent base station via an inter-base station interface. The backhaul communication unit 240 is connected to the AMF / UPF300 via a base station-core network interface. The gNB may consist of a CU (Central Unit) and a DU (Distributed Unit) (i.e., functionally separated), and the two units may be connected via an F1 interface.

[0028] Figure 4 shows the configuration of the protocol stack for the user plane's wireless interface that handles data.

[0029] As shown in Figure 4, the user plane radio interface protocol has a physical (PHY) layer, a MAC (Medium Access Control) layer, an RLC (Radio Link Control) layer, a PDCP (Packet Data Convergence Protocol) layer, and an SDAP (Service Data Adaptation Protocol) layer.

[0030] The PHY layer performs encoding / decoding, modulation / demodulation, antenna mapping / demapping, and resource mapping / demapping. Data and control information are transmitted between the UE100's PHY layer and the gNB200's PHY layer via a physical channel.

[0031] The MAC layer performs data priority control, retransmission processing using Hybrid Automatic Repeat request (HARQ), and random access procedures. Data and control information are transmitted between the MAC layer of the UE100 and the MAC layer of the gNB200 via the transport channel. The MAC layer of the gNB200 includes a scheduler. The scheduler determines the transport format for the up and down links (transport block size, modulation and coding scheme (MCS)) and the resource blocks to be allocated to the UE100.

[0032] The RLC layer transmits data to the receiving RLC layer using the functions of the MAC layer and PHY layer. Data and control information are transmitted between the UE100's RLC layer and the gNB200's RLC layer via a logical channel.

[0033] The PDCP layer performs header compression / decompression, and encryption / decryption.

[0034] The SDAP layer maps IP flows, which are the units under which the core network performs QoS (Quality of Service) control, to wireless bearers, which are the units under which the AS (Access Stratum) performs QoS control. Note that if the RAN is connected to the EPC, the SDAP is not required.

[0035] Figure 5 shows the configuration of the protocol stack of the wireless interface of the control plane that handles signaling (control signals).

[0036] As shown in Figure 5, the protocol stack of the control plane's wireless interface has an RRC (Radio Resource Control) layer and a NAS (Non-Access Stratum) layer instead of the SDAP layer shown in Figure 4.

[0037] RRC signaling for various settings is transmitted between the RRC layer of the UE100 and the RRC layer of the gNB200. The RRC layer controls the logical channel, transport channel, and physical channel in response to the establishment, re-establishment, and release of the radio bearer. If there is a connection (RRC connection) between the RRC of the UE100 and the RRC of the gNB200, the UE100 is in the RRC connected state. If there is no connection (RRC connection) between the RRC of the UE100 and the RRC of the gNB200, the UE100 is in the RRC idle state. If the connection between the RRC of the UE100 and the RRC of the gNB200 is suspended, the UE100 is in the RRC inactive state.

[0038] The NAS layer, located above the RRC layer, handles session management and mobility management, among other things. NAS signaling is transmitted between the UE100's NAS layer and the AMF300B's NAS layer.

[0039] In addition to the wireless interface protocol, the UE100 also has an application layer and other components.

[0040] (MBS) Next, an MBS according to one embodiment will be described.

[0041] MBS is a service that enables broadcast or multicast data transmission from NG-RAN10 to UE100, i.e., point-to-multipoint (PTM) data transmission. Potential use cases (service types) for MBS include public security communications, mission-critical communications, V2X (Vehicle to Everything) communications, IPv4 or IPv6 multicast distribution, IPTV, group communications, and software distribution.

[0042] The broadcast service provides service to all UE100s within a specific service area for applications that do not require high reliability QoS. The MBS session used for the broadcast service is called a broadcast session.

[0043] Multicast services provide service to a group of UE100s participating in the multicast service, rather than to all UE100s. The MBS session used for multicast services is called a multicast session. Multicast services allow the same content to be delivered to a group of UE100s in a more wirelessly efficient way compared to broadcast services.

[0044] Figure 6 shows an overview of MBS traffic distribution according to one embodiment.

[0045] As shown in Figure 6, MBS traffic is delivered from a single data source (application service provider) to multiple UEs. The 5G core network, 5G CN (5GC)20, receives MBS traffic from the application service provider, creates copies of the MBS traffic (replication), and delivers them.

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

[0047] In the 5GC individual MBS traffic distribution method, the 5GC20 receives a single copy of MBS data packets and distributes individual copies of those MBS data packets to individual UE100s via a Protocol Data Unit (PDU) session for each UE100. Therefore, one PDU session per UE100 needs to be associated with the multicast session.

[0048] In the 5GC shared MBS traffic distribution method, firstly, the 5GC20 receives a single copy of the MBS data packets and distributes that single copy of the MBS data packets to the RAN nodes (i.e., gNB200). Secondly, the gNB200 distributes them to one or more UE100s.

[0049] From the perspective of RAN (5G RAN)10, two distribution methods are possible for transmitting MBS traffic wirelessly in the 5GC shared MBS traffic distribution method: PTP (Point-to-Point) and PTM (Point-to-Multipoint).

[0050] In the PTP distribution method, the gNB200 wirelessly distributes individual copies of MBS data packets to each UE100. On the other hand, in the PTM distribution method, the gNB200 wirelessly distributes a single copy of MBS data packets to a group of UE100s. The gNB200 dynamically determines whether to use PTM or PTP as the method for distributing MBS traffic to a single UE100.

[0051] The PTP and PTM distribution methods primarily relate to the user plane. There are two distribution modes, the first mode and the second mode, for controlling MBS traffic distribution. Figure 7 shows a distribution mode according to one embodiment.

[0052] As shown in Figure 7, the first mode (Delivery mode 1) is a delivery mode available to UE100 in an RRC connected state and is a delivery mode for high QoS requirements. The first mode is used only for multicast sessions among MBS sessions. In one embodiment, it is assumed that the first mode is used for multicast sessions, but the first mode may also be used for broadcast sessions. The first mode may also be available to UE100 in an RRC idle state or an RRC inactive state.

[0053] In one embodiment, the MBS reception in the first mode is configured by dedicated signaling (also known as "unicast signaling"). Specifically, the MBS reception in the first mode is configured by an RRC Reconfiguration message (or RRC Release message), which is an RRC message transmitted unicast from the gNB200 to the UE100. In the first mode, advanced MBS traffic distribution using the split MBS bearer described later is possible.

[0054] The MBS reception settings include MBS traffic channel information (hereinafter referred to as "MTCH information") regarding the MBS traffic channel that carries MBS traffic. The MTCH information includes MBS session information regarding the MBS session and scheduling information (hereinafter referred to as "MTCH scheduling information") for the MBS traffic channel corresponding to this MBS session.

[0055] The MBS traffic channel is a type of logical channel and is sometimes called an MTCH (Multicast Traffic Channel). The MBS traffic channel is mapped to a type of transport channel called a DL-SCH (Downlink Shared Channel).

[0056] Delivery mode 2 is a delivery mode that can be used not only by UE100s in the RRC connected state, but also by UE100s in the RRC idle or RRC inactive state, and is a delivery mode for low QoS requirements. Delivery mode 2 is used for broadcast sessions within MBS sessions. However, delivery mode 2 may also be applicable to multicast sessions.

[0057] In the second mode, MBS reception is configured via broadcast signaling. Specifically, the MBS reception in the second mode is configured via a logical channel broadcast from the gNB200 to the UE100, such as a BCCH (Broadcast Control Channel) or MCCH (Multicast Control Channel). In the following, such a control channel may be referred to as the MBS control channel.

[0058] The network can provide different MBS services for each MBS session. An MBS session is identified by at least one of the following: TMGI (Temporary Mobile Group Identity), session identifier, and group RNTI (Radio Network Temporary Identifier). At least one of the TMGI and session identifier is called the MBS session identifier. The TMGI, session identifier, and group RNTI together are called MBS session information. The MBS session identifier may also be called the MBS service identifier or multicast group identifier.

[0059] (Split MBS Bearer) Next, a split MBS bearer according to one embodiment will be described. The split MBS bearer is available in the first mode described above.

[0060] The gNB200 can configure the UE100 with an MBS bearer separated into a PTP communication path and a PTM communication path (hereinafter referred to as a "split MBS bearer" as appropriate). This allows the gNB200 to dynamically switch the transmission of MBS traffic to the UE100 between PTP (PTP communication path) and PTM (PTM communication path). Alternatively, the gNB200 can enhance reliability by using both PTP and PTM to transmit the same MBS traffic twice. Alternatively, the gNB200 can enhance reliability by sending the initial transmission of MBS traffic to multiple UE100s via PTM and then retransmitting the MBS traffic to a specific UE100.

[0061] The predetermined layer terminating the split is a MAC layer (HARQ), an RLC layer, a PDCP layer, or an SDAP layer. In the following, we will mainly describe an example where the predetermined layer terminating the split is a PDCP layer, but the predetermined layer may be a MAC layer (HARQ), an RLC layer, or an SDAP layer.

[0062] Figure 8 shows a split MBS bearer according to one embodiment. Hereafter, a PTP communication path will be referred to as a PTP leg, and a PTM communication path will be referred to as a PTM leg. Also, the functional parts corresponding to each layer will be referred to as entities.

[0063] As shown in Figure 8, the PDCP entities of gNB200 and UE100 each separate the MBS bearer (data radio bearer) used for MBS into a PTP leg and a PTM leg. A PDCP entity is provided for each bearer.

[0064] Each of the gNB200 and UE100 has two RLC entities, one MAC entity, and one PHY entity, each provided for each leg. The PHY entity may be provided for each leg. In the case of dual connectivity, where the UE100 communicates with two gNB200s, the UE100 may have two MAC entities.

[0065] PHY entities send and receive data for PTP legs using a Cell Radio Network Temporary Identifier (C-RNTI) assigned one-to-one with each UE100. PHY entities send and receive data for PTM legs using a Group Radio Network Temporary Identifier (G-RNTI) assigned one-to-one with each MBS session. While the C-RNTI is different for each UE100, the G-RNTI is a common RNTI shared by multiple UE100s receiving a single MBS session.

[0066] In order for gNB200 to send MBS traffic via PTM (multicast or broadcast) using a PTM leg to UE100, a split MBS bearer must be configured on UE100 from gNB200, and the PTM leg must be activated. In other words, even if a split MBS bearer is configured on UE100, gNB200 cannot send MBS traffic via PTM using this PTM leg if the PTM leg is deactivated.

[0067] Furthermore, for gNB200 and UE100 to transmit MBS traffic via PTP (unicast) using the PTP leg, a split MBS bearer must be configured from gNB200 to UE100, and the PTP leg must be activated. In other words, even if a split MBS bearer is configured on UE100, gNB200 cannot transmit MBS traffic via PTP using this PTP leg if the PTP leg is inactive.

[0068] When the PTM leg is activated, UE100 monitors the PDCCH (Physical Downlink Control Channel) to which G-RNTI associated with the MBS session is applied (i.e., performs blind decoding of the PDCCH using G-RNTI). UE100 may also monitor the PDCCH only when scheduling the MBS session.

[0069] When the PTM leg is deactivated, the UE100 does not monitor the PDCCH to which G-RNTI is applied in association with the MBS session (i.e., it does not perform blind decoding of the PDCCH using G-RNTI).

[0070] The UE100 monitors the PDCCH to which C-RNTI is applied when the PTP leg is activated. If discontinuous reception (DRX) is set for the PTP leg, the UE100 monitors the PDCCH during the set on-duration. If a cell (frequency) associated with an MBS session is specified, the UE100 may monitor the PDCCH of that cell even if that cell is deactivated.

[0071] UE100 may monitor the PDCCH with C-RNTI applied in preparation for normal unicast downlink transmissions other than MBS traffic when the PTP leg is deactivated. However, UE100 does not need to monitor the PDCCH for an MBS session if a cell (frequency) associated with that MBS session is specified.

[0072] Furthermore, it is assumed that the split MBS bearer described above is configured by an RRC message (for example, an RRC Reconfiguration message) sent from the RRC entity of gNB200 to the RRC entity of UE100.

[0073] (An example of the first mode) Next, we will describe an example of the first mode.

[0074] Figure 9 shows an example of operation in the first mode according to one embodiment. In Figure 9, steps that are not essential are shown with dashed lines.

[0075] As shown in Figure 9, in step S11, the UE100, which is in the RRC connected state, sends an MBS Interest Indication (MII) message to the gNB200. The MII message contains MBS session information about the MBS session that the UE100 desires (i.e., the MBS session that the UE100 is interested in receiving). By receiving the MII message, the gNB200 understands the MBS session that the UE100 desires. In this operating pattern, the MII message is a type of RRC message.

[0076] In step S12, the gNB200 transmits the MBS settings necessary for receiving the desired MBS session on the UE100 via dedicated signaling. In one embodiment, the dedicated signaling is an RRC Reconfiguration message. However, the dedicated signaling may be an RRC Release message.

[0077] In step S13, UE100 sends a response message to gNB200 for the dedicated signaling received in step S12. The response message is, for example, an RRC Reconfiguration Complete message. gNB200 receives the response message.

[0078] In step S14, the gNB200 transmits MBS traffic via MTCH (e.g., multicast transmission) according to the MBS configuration set in step S12. Here, the gNB200 may perform advanced MBS traffic distribution using a split MBS bearer. The UE100 receives the MBS traffic.

[0079] Figure 10 shows an example of the configuration of an RRC Reconfiguration message according to one embodiment. As shown in Figure 10, the RRC Reconfiguration message sent from gNB200 to UE100 includes MBS settings necessary for MBS reception as information elements.

[0080] The MBS settings in the RRC Reconfiguration message include MTCH information. The MBS settings in the RRC Reconfiguration message may further include RRC Connected-specific settings that are applicable only to MBS reception in the RRC Connected state.

[0081] MTCH information may be a common setting across all RRC states (i.e., RRC Connected state, RRC Idle state, RRC Inactive state). MTCH information includes MBS session information (at least one of the MBS session identifier and group RNTI) and MTCH scheduling information. MTCH scheduling information includes at least one of the MTCH transmission occasion and transmission BWP (Bandwidth Part).

[0082] Here, the group RNTI is the RNTI commonly assigned to a group of UE100s. The transmit occasion is a candidate timing (e.g., subframe) for the gNB200 to transmit MBS traffic using the MTCH. For example, the transmit occasion may include parameters such as On Duration, Inactivity Timer, periodicity(cycle) / offset, and DRX Retransmission Timer. The transmit BWP is the BWP for which the gNB200 transmits MBS traffic using the MTCH. The BWP is a bandwidth portion narrower than the frequency bandwidth of a single cell, and is intended to limit the operating bandwidth of the UE100.

[0083] On the other hand, RRC Connected-only settings include settings related to the split MBS bearer, and for example, at least one of the following: the bearer settings for the split MBS bearer, the dynamic switching settings between PTP and PTM, and the PTP leg settings. Note that the PTM leg settings can be used even in the RRC idle or RRC inactive state, and may therefore be included in the MTCH information. RRC Connected-only settings may also include HARQ feedback settings.

[0084] (An example of the second mode) Next, an example of the second mode will be described. Figure 11 is a diagram showing an example of operation of the second mode according to one embodiment. In the second mode, the UE100 may be in any of the following RRC states: RRC connected, RRC idle, or RRC inactive.

[0085] As shown in Figure 11, in step S21, gNB200 transmits the MBS settings necessary for MBS reception via broadcast signaling. Broadcast signaling is signaling transmitted periodically via BCCH and / or MCCH. Below, we will mainly describe an example where broadcast signaling is transmitted via MCCH. UE100 receives the broadcast signaling.

[0086] In step S22, gNB200 transmits MBS traffic via MTCH (e.g., broadcast transmission) according to the MBS settings configured in step S21. UE100 receives the MBS traffic.

[0087] Figure 12 shows variations in MBS settings in the second mode according to one embodiment.

[0088] As shown in Figure 12, the gNB200 provides the UE100 with scheduling information for the MCCH via a System Information Block (SIB) transmitted by the BCCH. The UE100 receives the MCCH (i.e., MBS configuration) based on the SIB received from the gNB200, and receives the MTCH (i.e., MBS traffic) based on the received MCCH. This type of configuration is sometimes called a two-step configuration.

[0089] Alternatively, the gNB200 may provide the MBS configuration to the UE100 via an SIB. In this case, the UE100 receives MTCH (i.e., MBS traffic) based on the SIB received from the gNB200. Such a configuration is sometimes called a one-step configuration.

[0090] The gNB200 may configure multiple MCCHs (Multiple MCCHs) within a single cell. Each MCCH may have a different scheduling (e.g., transmission cycle). Any of the MCCHs may be provided on demand upon request from the UE100.

[0091] Figure 13 shows an example of the configuration of a broadcast message according to one embodiment. The broadcast message corresponds to broadcast signaling that provides MBS settings.

[0092] As shown in Figure 13, the broadcast message sent from gNB200 to UE100 includes the MBS settings required for MBS reception as informational elements.

[0093] The MBS settings in a broadcast message include one or more MTCH information. Figure 13 shows an example where a broadcast message includes multiple MTCH information corresponding to multiple MBS sessions (multiple MTCHs).

[0094] (Action according to one embodiment) Next, an operation according to one embodiment will be described.

[0095] As described above, assuming that two distribution modes, the first mode and the second mode, coexist, if the UE100 that receives MBS signals operates fixedly in only one of the distribution modes, the following problems may arise.

[0096] Firstly, consider a scenario where UE100, in the RRC connected state, performs MBS reception in mode 1. In such a scenario, if the load on gNB200 is high, or if there is no ongoing data in the multicast session, UE100 is transitioned to the RRC idle state or RRC inactive state. This reduces the load on gNB200 and UE100. However, transitioning UE100 to the RRC idle state or RRC inactive state may prevent UE100 from continuing MBS reception.

[0097] Secondly, consider a scenario where UE100, in an RRC idle or RRC inactive state, performs MBS reception in the second mode. In such a scenario, if the load on gNB200 is low, it would be possible to transition UE100 to the RRC connected state and switch to the first mode, enabling advanced MBS traffic distribution, for example, using a split MBS bearer.

[0098] In the operation according to one embodiment, mode switching between the first mode and the second mode is enabled by controlling the gNB200. Figure 14 is a diagram showing the operation according to one embodiment.

[0099] As shown in Figure 14, in step S1, the UE100, operating in either the first or second mode, receives MBS traffic from the gNB200 via the MTCH. The first mode is a delivery mode in which MBS configuration is provided by dedicated signaling, and the second mode is a delivery mode in which MBS configuration is provided by broadcast signaling.

[0100] In step S2, gNB200 sends switching information to UE100 to switch the delivery mode between the first mode and the second mode. The switching information may be sent via dedicated signaling (e.g., RRC Reconfiguration message) and / or broadcast signaling (e.g., SIB, MCCH, or paging). UE100 receives the switching information.

[0101] In step S3, UE100 switches modes between the first mode and the second mode based on switching information from gNB200. Specifically, UE100 switches modes from the first mode to the second mode based on switching information for switching the distribution mode from the first mode to the second mode. Alternatively, UE100 switches modes from the second mode to the first mode based on switching information for switching the distribution mode from the second mode to the first mode.

[0102] In step S4, the UE100, operating in the switched-out mode, receives MBS traffic from the gNB200 via the MTCH.

[0103] In this way, by controlling the gNB200 to switch between the first and second modes, it becomes possible to appropriately use the first and second modes. Furthermore, even when switching modes, the UE100 can more easily continue MBS reception.

[0104] (Example of first action) Next, a first example of operation according to one embodiment will be described. The following example of operation will mainly describe the mode switching from the first mode to the second mode.

[0105] In this example, the gNB200 switches the UE100, which is performing PTM reception in the first mode while in the RRC connected state, from the first mode to the second mode before transitioning it to the RRC idle state or RRC inactive state. For example, the gNB200 sequentially transitions the UE100 to the RRC idle state or RRC inactive state as soon as it can start MBS reception in the second mode. This allows the UE100 to continue MBS reception while reducing the load on both the gNB200 and the UE100.

[0106] Specifically, the gNB200 transmits switching information to the UE100, which is operating in the first mode when RRC connected, to switch to the second mode. The UE100 switches from the first mode to the second mode based on the switching information received from the gNB200.

[0107] After switching from mode 1 to mode 2, UE100 transitions to either the RRC idle state or the RRC inactive state. In the RRC idle state or RRC inactive state, UE100 receives MBS traffic from gNB200 using the MBS settings provided by broadcast signaling.

[0108] In this example, UE100 may send a notification to gNB200 based on the switch from the first mode to the second mode. Upon receiving the notification from UE100, gNB200 transitions UE100 to the RRC idle state or RRC inactive state. This allows gNB200 to confirm that UE100 can continue receiving MBS before transitioning UE100 to the RRC idle state or RRC inactive state.

[0109] Figure 15 shows a first example of operation according to one embodiment. In Figure 15, steps that are not essential are shown with dashed lines.

[0110] As shown in Figure 15, in step S101, UE100 is in the RRC connected state in the cell of gNB200.

[0111] In step S102, the gNB200 and UE100 operate in the first mode as described above (see Figure 9). For example, the UE100 receives the MBS configuration transmitted from the gNB200 via dedicated signaling and uses this MBS configuration to receive the MBS traffic (MTCH) transmitted from the gNB200 via PTM.

[0112] In step S103, the gNB200 decides which UE100 to transition to the RRC idle state or RRC inactive state, taking into account its own load (e.g., wireless resource utilization and / or hardware resource utilization). Here, we will proceed with the assumption that the load on the gNB200 is high.

[0113] Here, gNB200 may determine that any UE100 that has not transmitted uplink traffic for a certain period of time should be transitioned to the RRC idle state or RRC inactive state. gNB200 may also determine that any UE100 that is interested in an MBS session that has not transmitted downlink traffic for a certain period of time, or that is receiving (or participating in) such MBS traffic, should be transitioned to the RRC idle state or RRC inactive state. gNB200 may also determine that all UE100s receiving a given MBS session should be transitioned to the RRC idle state or RRC inactive state.

[0114] In step S104, the gNB200 begins transmitting in second mode. Specifically, the gNB200 begins transmitting broadcast signaling in second mode and / or MBS traffic (MTCH) in second mode. Note that step S104 may be performed after step S105.

[0115] In step S105, a receiving mode switching instruction to the second mode is transmitted as switching information to the UE100 determined in step S103. The receiving mode switching instruction to the second mode includes at least one of the following pieces of information.

[0116] • The MBS session identifier, group RNTI, MBS bearer ID, and / or PTM LCID (Logical Channel ID) of the MBS session being switched to receive mode (the currently receiving MBS session). • After switching the receive mode (for the MBS session to be received), the group RNTI, MBS bearer ID, and / or PTM LCID will be displayed. • Timing information indicating the timing of the receiver mode switch. This timing information may be expressed in absolute time (such as SFN) and / or relative time (such as timer value).

[0117] In step S106, UE100 begins preparing for second-mode reception in response to a switching instruction received from gNB200. For example, UE100 attempts to receive broadcast signaling (SIB and / or MCCH) and MTCH. If UE100 received a timer value in step S105, it starts the timer.

[0118] In step S107, upon receiving the second mode, UE100 notifies gNB200 that it is ready to receive. UE100 may also send a notification to gNB200 upon completion of SIB and / or MCCH reception. UE100 may also send a notification to gNB200 upon completion of MTCH reception. This notification may be an RRC message and / or MAC CE (Control Element). As such a notification, UE100 may send gNB200 a Release Assistance Information (RAI), which is an RRC message prompting gNB200 to transition to an RRC idle or RRC inactive state. UE100 may include information indicating that it is ready to receive the second mode in the RAI.

[0119] In step S108, based on the notification from UE100, gNB200 sends an RRC Release message to UE100 when it is ready to receive. This causes gNB200 to transition UE100 to the RRC idle state or the RRC inactive state. When gNB200 transitions UE100 to the RRC inactive state, it sends an RRC Release message that includes Suspend Config as an information element. UE100 may discard or disable the RRC Connected-only setting configured in Dedicated Signaling.

[0120] In step S109, UE100 transitions to either the RRC idle state or the RRC inactive state in response to receiving the RRC Release message.

[0121] In step S110, UE100 receives MBS traffic (MTCH) transmitted from gNB200 via PTM using the MBS configuration provided by broadcast signaling from gNB200.

[0122] In step S106, it is also possible that UE100 may not be able to start receiving in the second mode within the period until the timing of the receive mode switch. Such cases include, for example, when reception has not started at the time of SFN, or when reception has not started when the timer expires. In this case, in step S107, UE100 may send a notification of reception preparation failure to gNB200. If gNB200 receives a notification of reception preparation failure from UE100, it may maintain UE100 in the RRC connected state.

[0123] (Example of second action) Next, a second example of operation according to one embodiment will be described, primarily focusing on the differences from the above-described example of operation. This example of operation is based on the first example of operation described above.

[0124] In the first operational example described above, there is a concern that packet loss or delay in MBS traffic may occur in the UE100 when switching from the first mode to the second mode, for example, due to the acquisition of broadcast signaling (SIB and / or MCCH).

[0125] Here, UE100 can detect packet loss based on discontinuities in the packet sequence number, for example, at the PDCP layer. However, UE100 cannot detect packet loss if the PDCP entity in second mode is a different PDCP entity from the PDCP entity in first mode (i.e., a new PDCP entity is established). UE100 also cannot detect packet loss when the PDCP entity is re-established. Furthermore, there is a risk that the PDCP entity may not be able to continue the packet header compression / decompression process (e.g., RoHC (Robust Header Compression)) and / or security processing.

[0126] Therefore, the UE100 in this operational example continuously uses the PDCP entity used for receiving MBS traffic in the first mode to perform receiving MBS traffic in the second mode. This solves the problems described above.

[0127] Figure 16 is a diagram illustrating a second operational example according to one embodiment. Specifically, Figure 16 shows the operation of the UE100 in relation to MBS traffic reception.

[0128] As shown in Figure 16, in step S201, UE100 receives MBS traffic transmitted via PTM from gNB200 in first mode (Delivery mode 1). This MBS traffic belongs to a specific MBS session. In UE100, the PHY entity, MAC entity, RLC entity, and PDCP entity process the MBS traffic in first mode. Here, the PDCP entity performs packet loss detection based on the sequence number included in the header of the MBS traffic packet (PDCP packet), and also performs header restoration according to RoHC.

[0129] The gNB200 assigns the same PDCP sequence number to the MBS traffic of the MBS session targeted for receiving mode switching (a specific MBS session) and transmits it in both the first mode and the second mode.

[0130] In step S202, when UE100 performs a receive mode switch (for example, when it receives a switch instruction), it relocates the PDCP entities in the first mode to the second mode. Specifically, UE100 rearranges the PDCP entities that were positioned as a higher layer above the RLC entities in the first mode to be positioned as a higher layer above the RLC entities in the second mode. UE100 may also perform this relocation by changing the association between the PDCP entities and the RLC entities (LCID). As a result, the PDCP context information (PDCP sequence number, RoHC context) from the first mode is carried over to the second mode.

[0131] In step S203, UE100 receives MBS traffic transmitted via PTM from gNB200 in the second mode (Delivery mode 2). That is, UE100 continues to receive data for that particular MBS session in the second mode. In UE100, the PHY entity, MAC entity, RLC entity, and PDCP entity process the MBS traffic in the second mode. Here, the PDCP entity continues packet loss detection processing and RoHC header restoration processing using the PDCP context information inherited from the first mode.

[0132] Furthermore, the PDCP relocation in this example may be performed by establishing a new PDCP entity for the second mode or by re-establishing a PDCP entity and transferring the PDCP context information from the first mode to the PDCP entity for the second mode.

[0133] (Example of third action) Next, a third example of operation according to one embodiment will be described, primarily focusing on the differences from the above-described example of operation. This example of operation is another example of operation addressing the same problem as the second example of operation described above.

[0134] In this example, gNB200 configures UE100 with a bearer (i.e., a split bearer) that is divided into a first communication path for the first mode (hereinafter referred to as the "first mode leg") and a second communication path for the second mode (hereinafter referred to as the "second mode leg"). When UE100 switches from the first mode to the second mode, it switches from the first mode leg to the second mode leg while maintaining the PDCP entity.

[0135] Figure 17 shows a third operational example according to one embodiment. Specifically, Figure 17 shows the operation of UE100 in relation to MBS traffic reception. Here, we will mainly explain the differences from the second operational example described above.

[0136] As shown in Figure 17, in step S301, UE100 receives MBS traffic transmitted via PTM from gNB200 in the first mode leg. This MBS traffic belongs to a specific MBS session. In UE100, the PHY entity, MAC entity, RLC entity, and PDCP entity process the MBS traffic for the first mode leg.

[0137] The gNB200 assigns the same PDCP sequence number to the MBS traffic of the MBS session targeted for receiving mode switching (a specific MBS session) for both the first mode leg and the second mode leg, and transmits it.

[0138] In step S302, when the UE100 performs a receive mode switch (for example, when it receives a switch instruction), it modifies the PDCP entities of the first mode to associate them with the legs for the second mode (RLC entities, LCID). As a result, the PDCP context information (PDCP sequence number, RoHC context) of the first mode is carried over to the second mode.

[0139] In step S303, UE100 receives MBS traffic transmitted via PTM from gNB200 on the second mode leg. That is, UE100 continues to receive data for that particular MBS session in second mode. The PDCP entity continues packet loss detection processing and RoHC header restoration processing using the PDCP context information inherited from the first mode. Note that UE100 may release (delete) the first mode leg after switching to the second mode, for example, when it receives an RRC Release message.

[0140] (Example of the fourth action) Next, we will explain the differences between a fourth example of operation according to one embodiment and the above-described example of operation.

[0141] In the above example of operation, it was assumed that the MTCH scheduling for the first mode and the MTCH scheduling for the second mode were different for a single MBS session. However, by making the MTCH scheduling the same for both the first and second modes of an MBS session, the mode switching for that MBS session can be streamlined. Furthermore, by making the group RNTI for the first mode and the group RNTI for the second mode the same for an MBS session, the mode switching for that MBS session can also be streamlined.

[0142] In this example, the gNB200 transmits MTCH scheduling information, which is scheduling information for MBS traffic channels, via dedicated signaling (i.e., first-mode signaling). This MTCH scheduling information is associated with one MBS session. Furthermore, the gNB200 transmits the same MTCH scheduling information for this MBS session via broadcast signaling (i.e., second-mode signaling).

[0143] In this example, the gNB200 may transmit switching information that includes a notification indicating that the MTCH scheduling information transmitted by dedicated signaling is also applicable in the second mode.

[0144] Figure 18 shows a fourth example of operation according to one embodiment. Here, the differences from the first example of operation described above will be mainly explained. In Figure 18, steps that are not essential are shown with dashed lines.

[0145] As shown in Figure 18, in step S401, UE100 is in the RRC connected state in the cell of gNB200.

[0146] In step S402, the gNB200 and UE100 operate in the first mode as described above (see Figure 9). For example, the UE100 receives MBS configuration (MTCH information) transmitted from the gNB200 via dedicated signaling, and uses this MTCH information to receive MBS traffic (MTCH) transmitted from the gNB200 via PTM. This MBS traffic belongs to a specific MBS session.

[0147] In step S403, gNB200 determines which UE100 will be switched from the first mode to the second mode.

[0148] In step S404, the gNB200 starts transmitting in second mode for the specific MBS session. Specifically, the gNB200 starts transmitting broadcast signaling in second mode. Note that step S404 may be performed after step S405. Here, the gNB200 transmits the same MTCH information in broadcast signaling as it transmitted in broadcast signaling in first mode.

[0149] In step S405, gNB200 may send the above-mentioned receive mode switching instruction as switching information to UE100 determined in step S403. gNB200 may send switching information to UE100 that includes information indicating that the MTCH scheduling information (MTCH information) is the same, for example, "Same MTCH info{true}". gNB200 may also send switching information to UE100 that includes a notification indicating that the particular MBS session can also be received in the second mode. gNB200 may send such switching information by broadcast signaling (such as SIB).

[0150] In step S406, UE100 assumes that the MTCH information is identical based on the switching instruction received from gNB200, and continues to receive MBS traffic (MTCH) even before receiving broadcast signaling from gNB200.

[0151] Furthermore, similar to the first example of operation described above, gNB200 may transition UE100 from the RRC connected state to the RRC idle state or the RRC inactive state based on a notification from UE100. Here, UE100 may send a notification (e.g., RAI) even if it is receiving or interested in receiving the particular MBS session, such as when there is no unicast data communication. gNB200 may determine that the transition to the second mode is complete when there are no UE100s receiving the particular MBS session in the first mode.

[0152] (Example of the fifth action) Next, we will explain the differences between a fifth example of operation according to one embodiment and the above-described example of operation.

[0153] As described above, the gNB200 switches from mode 1 to mode 2 for certain MBS sessions due to its own load. Such a switch to mode 2 may be a temporary switch limited to periods when the load on the gNB200 is high.

[0154] A specific MBS session that has been switched to mode 2 is an MBS session that should originally be subject to mode 1. Therefore, it is undesirable for UE100, which is originally in an RRC idle or RRC inactive state, to start receiving data from that specific MBS session.

[0155] In this example, after switching from the first mode to the second mode, the gNB200 transmits a broadcast signaling (e.g., MCCH or SIB) containing MBS session information indicating the MBS session that has been switched from the first mode to the second mode. This allows the UE100, which is originally in an RRC idle or RRC inactive state, to recognize the MBS session that has been switched to the second mode based on the broadcast signaling. As a result, the UE100 can avoid, for example, starting to receive the MBS session that has been switched to the second mode.

[0156] In this example, after switching from the first mode to the second mode, if, for example, its own load decreases, the gNB200 sends a broadcast signaling that includes MBS session information indicating the MBS session to switch back from the second mode to the first mode. This allows the UE100, which has been switched to the second mode, to take action to return to the first mode.

[0157] Figure 19 shows a fifth example of operation according to one embodiment.

[0158] As shown in Figure 19, in step S501, UE100a is in the RRC connected state in the gNB200 cell.

[0159] On the other hand, in step S502, UE100b is in an RRC idle state or RRC inactive state in the cell of gNB200.

[0160] In step S503, the gNB200 and UE100a perform the first mode of operation as described above for a specific MBS session.

[0161] In step S504, the gNB200 and UE100a perform the mode switching operation described above for the specific MBS session.

[0162] In step S505, UE100a transitions from the RRC connected state to the RRC idle state or the RRC inactive state.

[0163] In step S506, gNB200 transmits information via second-mode broadcast signaling (e.g., MCCH) indicating that the particular MBS session is an MBS session that has been switched from first mode. UE100a and UE100b receive this broadcast signaling. Such notification includes MBS session information for the particular MBS session. The notification may also indicate that the particular MBS session will be removed from second mode after UE100a returns to the RRC connected state.

[0164] In step S507, UE100a continues MBS reception in the RRC idle / RRC inactive state.

[0165] On the other hand, even if UE100b is interested in receiving the particular MBS session, it determines, based on the broadcast signaling in step S506, that it cannot receive the particular MBS session in the RRC idle / RRC inactive state. In order for UE100b to receive the particular MBS session, it needs to transition to the RRC connected state and obtain the MBS settings from gNB200 via dedicated signaling.

[0166] Alternatively, UE100b may start receiving the particular MBS session in an RRC idle or RRC inactive state. In this case, UE100b may attempt to establish or restore an RRC connection with gNB200 based on the notification (switching information) from gNB200 in step S509 described below.

[0167] Subsequently, in step S508, the gNB200 decides to switch from the second mode to the first mode for that particular MBS session. For example, the gNB200 decides to make such a switch when its own load decreases.

[0168] In step S509, gNB200 transmits switching information to switch from the second mode to the first mode for the particular MBS session. This switching information includes the MBS session information for the particular MBS session. This switching information may be transmitted via broadcast signaling (SIB, MCCH, or paging message), MTCH, and / or MAC CE. UE100a and UE100b receive the switching information from gNB200.

[0169] In step S510, UE100a performs a connection process (random access procedure) with gNB200 to establish or restore the RRC connection with gNB200, based on the switching information received from gNB200 in step S509. As a result, UE100a performs MBS reception in the first mode while in the RRC connected state.

[0170] In step S511, UE100b performs a connection process (random access procedure) with gNB200 to establish or restore the RRC connection with gNB200, based on the switching information received from gNB200 in step S509. As a result, UE100b performs MBS reception in the first mode while in the RRC connected state.

[0171] (Other embodiments) The above example primarily described a case of switching from PTM in mode 1 to PTM in mode 2. However, it is also possible to switch from PTP in mode 1 to PTM in mode 2. Since mode 1 is primarily intended for the RRC connected state, and the choice between PTP and PTM depends on the gNB200 implementation, it is possible to switch from PTP in mode 1 to PTM in mode 2. In this case, UE100 receives MBS traffic transmitted from gNB200 via PTP in mode 1, and receives MBS traffic transmitted from gNB200 via PTM in mode 2. Switching from mode 1 to mode 2 includes switching from PTP to PTM.

[0172] Each of the above-mentioned examples of actions can be performed not only independently, but also by combining some steps from two or more examples of actions.

[0173] Furthermore, although the above embodiment describes an example where the base station is an NR base station (gNB), the base station may also be an LTE base station (eNB). Additionally, the base station may be a relay node such as an IAB (Integrated Access and Backhaul) node. The base station may also be a DU (Distributed Unit) of an IAB node.

[0174] A program may be provided that causes a computer to perform each of the processes that UE100 or gNB200 performs. The program may be recorded on a computer-readable medium. Using a computer-readable medium, it is possible to install the program on a computer. Here, the computer-readable medium on which the program is recorded may be a non-transient recording medium. The non-transient recording medium is not particularly limited, but may be a recording medium such as a CD-ROM or DVD-ROM.

[0175] Alternatively, the circuits that perform each process carried out by the UE100 or gNB200 may be integrated, and at least a portion of the UE100 or gNB200 may be configured as a semiconductor integrated circuit (chipset, SoC).

[0176] Although the embodiments have been described in detail above with reference to the drawings, the specific configuration is not limited to those described above, and various design changes can be made without departing from the gist of the invention.

[0177] This application claims priority to U.S. Provisional Application No. 63 / 136,946 (filed January 13, 2021), the entirety of which is incorporated into the specification of this application.

[0178] (Note) (introduction) A revised work item concerning NR's Multicast Broadcast Service (MBS) has been approved. It has been agreed to introduce two MBS delivery modes as follows:

[0179] In Rel-17, R2 defines the following two modes: 1: A delivery mode available in Connected mode (if no data is received, the UE may switch to another state, but this is TBD) for high QoS (reliability, latency) requirements. 2: Delivery mode for "low" QoS requirements. The UE can receive data even when inactive / idle (details TBD). R2 assumes that (in the case of R17) distribution mode 1 is used only for multicast sessions. R2 assumes that distribution mode 2 is used for the broadcast session. The applicability of distribution mode 2 to multicast sessions requires further investigation. • No data: If there is no ongoing data in the multicast session, the UE may remain RRC connected. In other cases, further consideration is required.

[0180] Regarding distribution mode 2, the following additional agreement was reached regarding the MBS settings:

[0181] The UE receives MBS settings via BCCH and / or MCCH (undetermined) (in broadcast / distribution mode 2), which may be received in idle / inactive mode. Connected mode requires further consideration. A notification mechanism is used to notify of changes in MBS control information.

[0182] This addendum considers aspects of the NR MBS control plane, taking into account the LTE eMBMS mechanism and the latest RAN2 agreement.

[0183] (Discussion) In accordance with the RAN2 agreement, the two delivery modes at this point are summarized in Table 1.

[0184] [Table 1]

[0185] (Streaming mode 1 setting) Distribution Mode 1 is primarily considered for data reception via RRC Connected, but configuration aspects are still undecided. While MBS configuration being provided via RRC reconfiguration may be straightforward, receiving MCCH via Connected, as in LTE eMBMS, is still under consideration. Given that Distribution Mode 1 is expected for high-QoS services, it should include, for example, PTP / PTM split bearer and / or lossless handover. Since these UE-specific configurations would be meaningless if provided via MCCH, in our view, RRC reconfiguration should be used for configuring Distribution Mode 1.

[0186] Proposal 1: In delivery mode 1, RAN2 should agree to use RRC reconfiguration for MBS configuration.

[0187] On the other hand, while WID clearly states that RRC Connected and Idle / Inactive should have the greatest commonality with respect to MBS configuration, RAN2 agreed on separate delivery modes for multicast and broadcast sessions, respectively.

[0188] To maintain maximum commonality between the RRC Connected state and the RRC Idle / Inactive state in the PTM reception settings, this document specifies the changes necessary to enable reception of PTM transmissions by UEs in the RRC Idle / Inactive state.

[0189] Even though the RRC messages for these delivery modes differ, the structure of the MBS configuration and IE should be coordinated as much as possible between the two delivery modes to achieve the objectives of WID. For example, the RRC reconfiguration for delivery mode 1 includes information specific to delivery mode 1, such as PTP / PTM split bearer and handover-related information, in addition to MTCH scheduling information, which is a block common to delivery mode 2. Therefore, further consideration is needed at this point.

[0190] Proposal 2: RAN2 should agree to aim for maximum commonality between the two delivery modes, for example, by using a common structure and IE from the perspective of MBS configuration.

[0191] Note that "MCCH" in Figure 20 refers only to MTCH scheduling information, i.e., MTCH settings related to MBS session information. In delivery mode 1, adjacent cell information is not required.

[0192] Further consideration is needed regarding whether a UE can be released into idle / inactive mode when there is no ongoing data for a multicast session. In other words, further consideration is needed regarding whether an idle / inactive UE can receive MBS data via distribution mode 1. As RAN2 agreed, the baseline is that the UE should be kept in distribution mode 1, i.e., RRC connected for multicast sessions requiring high QoS. However, other / exceptional cases are still worth considering.

[0193] During the email discussion, some companies pointed out that network congestion might prevent the network from keeping all UEs connected. Other companies also noted that UEs do not need to remain connected at all times due to uplink activity, QoS requirements, and / or UE power consumption.

[0194] From a RAN2 perspective, it may be beneficial for both the network and the UE to support this functionality. Whether the UE is released inactive / when it is released depends on the gNB implementation, and whether the UE is released idle depends on the core network. One concern regarding MBS data reception in idle state is that the gNB releases the UE context. On the other hand, the UE context is retained in idle state. This means that the controllability of the gNB may be lost, which may contradict the general concept of delivery mode 1. Therefore, RAN2 should agree that delivery mode 1 can be received by the UE at least in idle state, but further consideration is needed for idle state.

[0195] Proposal 3: In delivery mode 1, RAN2 should agree that the UE can receive delivery mode 1 at least in an inactive state. Further consideration is needed for idle states.

[0196] If we agree to Proposal 3, it is unclear how the idle / inactive MBS settings will be provided to the UE. Three options are possible:

[0197] Option 1: RRC reset An idle / inactive UE will continue to apply the MBS settings provided by the RRC reconfiguration. This option is straightforward as the UE simply reuses the MBS settings originally provided for RRC Connected. However, when transitioning to idle / inactive and / or resuming RRC Connected, some UE behavior may need to be considered, such as how to handle PTP / PTM split bearer settings if they are configured.

[0198] Option 2: RRC release Idle / inactive UEs apply the MBS settings provided by RRC release. While this option is straightforward, it may not be efficient because it is uncertain whether the MBS settings are different from those previously provided by RRC reconfiguration.

[0199] Option 3: Switching the streaming mode from Mode 1 to Mode 2 The UE is switched from distribution mode 1 to distribution mode 2 before being released into idle / inactive mode. This option is another simple solution, as distribution mode 2 is designed to receive data in all RRC states, as agreed upon by RAN2. However, packet loss and / or delay may be expected during switching, for example, due to MCCH acquisition.

[0200] Each option has its pros and cons, but in our view, option 1 is slightly preferable in terms of simplicity and efficiency. RAN2 should consider, but not be limited to, the above options, and discuss how to provide a delivery mode 1 setting for data reception in idle / inactive states.

[0201] Proposal 4: If Proposal 3 can be agreed upon, RAN2 should discuss how the delivery mode 1 setting for inactive data reception should be provided to the UE.

[0202] (Streaming mode 2 setting) In LTE SC-PTM, configuration is provided by two messages, namely SIB20 and SC-MCCH. SIB20 provides SC-MCCH scheduling information, and SC-MCCH provides SC-MCCH scheduling information including G-RNTI and TMGI, as well as neighboring cell information.

[0203] The advantage of the two-stage LTE configuration shown in Figure 21 was that SC-MCCH scheduling was independent of SIB20 scheduling in terms of repetition period, duration, and change period. In particular, it facilitated frequent scheduling / updating of SC-MCCH for latency-sensitive services and / or UEs that join sessions late. According to WID, the same applies to NR MBS, as one of the applications is group communications.

[0204] Finding 1: In LTE, a two-stage configuration using SIB20 and SC-MCCH is useful for different scheduling of these control channels. This is also useful for NR MBS.

[0205] Proposal 5: RAN2 should agree to use a two-stage configuration for NR MBS messages, such as SIB20 and SC-MCCH for SC-PTM.

[0206] In addition to Proposal 5, NR MBS is expected to support the various types of use cases described in the WID. It should be noted that NR MBS should be appropriately designed to meet a wide range of requirements, from latency-sensitive applications such as mission-critical and V2X to latency-tolerant applications such as IoT, as well as other aspects of requirements ranging from lossless applications such as software distribution to UDP-type streaming such as IPTV. Some of these services may be covered by distribution mode 2, while others with "high QoS requirements" will require distribution mode 1. In this sense, it is beneficial for gNB to be able to choose to use distribution mode 2 for multicast sessions.

[0207] Furthermore, since RAN2 has already agreed to allow data reception in RRC Connected, it is straightforward to enable RRC Connected UEs to receive MBS settings. It would be pointless if the UE had to transition to idle / inactive just to obtain the MCCH. While it is straightforward to enable Connected UEs to receive the MCCH, it may not be optimal in terms of scheduling flexibility (as the UE may need a "gap") and / or UE power consumption (as the UE needs to monitor "SC-RNTI" in addition to C-RNTI and G-RNTI). Therefore, whether the UE receives MBS settings via MCCH or RRC reconfiguration may require further discussion.

[0208] These two challenges remain, but generally speaking, there appear to be no technical reasons to limit them from our perspective.

[0209] Proposal 6: RAN2 should agree that, in addition to broadcast sessions, distribution mode 2 can be used for multicast sessions.

[0210] Proposal 7: In distribution mode 2, it should be agreed that RAN2 can be received even by UEs with MBS settings set to RRC connected. Further consideration is needed regarding whether MCCH or RRC reconfiguration should be used.

[0211] In light of Proposal 6, the control channel design for delivery mode 2 should take into consideration flexibility and resource efficiency. Otherwise, for example, if latency-tolerant and latency-sensitive services are configured together on a single control channel, more signaling overhead may be incurred because the control channel needs to be scheduled more frequently to meet the latency requirements of the latency-sensitive services.

[0212] Objective A of SA2 SI is to enable general MBS services over 5GS, and identified use cases that may benefit from this functionality include, but are not limited to, public safety, mission-critical, V2X applications, transparent IPv4 / IPv6 multicast distribution, IPTV, software distribution over radio, group communications, and IoT applications.

[0213] Finding 2: The NR MBS control channel for delivery mode 2 requires flexibility and resource efficiency for various types of use cases.

[0214] One possibility is to consider whether it is necessary to separate the configured channels for different use cases, as shown in Figure 12. For example, one MCCH may frequently provide latency-sensitive services, while another MCCH provides latency-tolerant services sporadically. LTE SC-PTM had the limitation that a single cell could only have one SC-MCCH. However, given that more use cases are expected than in LTE, NR MBS's delivery mode 2 should remove such limitations. If multiple MCCHs are allowed within a cell, each MCCH will have different scheduling settings, such as repetition periods, which can be optimized for specific services. Further consideration is needed as to how the UE identifies the MCCH providing the service of interest.

[0215] Proposal 8: In distribution mode 2, we should discuss whether RAN2 supports multiple MCCHs in a cell, something that was not present in LTE.

[0216] Furthermore, a new paradigm for NR is the support for on-demand SI transmission. This concept can be reused for MCCH in distribution mode 2, i.e., on-demand MCCH. For example, MCCH for latency-tolerant services is provided on demand, thus optimizing signaling resource consumption. Needless to say, the network has another option for providing MCCH periodically, i.e., not on demand, but for latency-sensitive services, etc.

[0217] Proposal 9: In delivery mode 2, RAN2 should discuss options for when MCCH is provided on an on-demand basis, which was not available in LTE.

[0218] Another possibility, as shown in Figure 12, is to merge these messages, i.e., a one-stage configuration, which could be further considered. For example, the SIB could provide MTCH scheduling information directly, i.e., without MCCH. This would provide an optimization for delay-tolerant services and / or power-sensitive UEs. For example, a UE could request an SIB (on demand), and the gNB could begin providing the SIB and corresponding services after requests from multiple UEs. These UEs would not need to monitor repeatedly broadcast MCCHs.

[0219] Proposal 10: In distribution mode 2, if multicast reception without MCCH (i.e., one-stage configuration) is supported, options such as SIB directly providing MTCH scheduling information should be discussed.

[0220] (Indication / counting of interests) In LTE eMBMS, two methods are specified for the network to collect UE's receiving / interest services to make appropriate decisions regarding MBMS data distribution, including starting / stopping MBMS sessions: MBMS interest indications (MII) and MBMS counting. MIIs triggered by the UE include information related to the MBMS frequencies of interest, the MBMS services of interest, MBMS priorities, and MBMS ROM (receive-only mode). Counting responses triggered by the network via counting requests for specific MBMS services include information related to the MBSFN areas and MBMS services of interest.

[0221] These methods were introduced for various purposes. MII is primarily used in networks to ensure that UEs can continue to receive services they are interested in while in a connected state. Counting, on the other hand, is used to allow a network to determine if a sufficient number of UEs are interested in receiving a service.

[0222] Finding 3: In LTE e MBMS, two types of UE assistance information are introduced for different purposes. Specifically, MBMS interest indications are introduced for NB scheduling, and MBMS counting is introduced for MCE session control.

[0223] In the case of NR MBS, multicast services such as group communication use cases are expected, and the network already has complete knowledge of the MBS services that connected UEs are receiving / interested in, so assistance information from UEs, such as decisions on network PTP / PTM distribution, is not useful to the network. However, to our understanding, the same is not true for broadcast services and / or idle / inactive UEs. Especially for broadcast services, the problem that was solved in LTE eMBMS by counting with MII, i.e., Finding 3, still exists in NR MBS. Therefore, RAN2 needs to consider whether assistance information such as MII and counting is useful to NR MBS.

[0224] Note that, as stated in WID, ROM and SFN are not supported, so Rel-17 does not require MII's MBMS ROM information or information regarding the MBSFN area of ​​the counting response.

[0225] Proposal 11: RAN2 should agree to introduce NR MBS UE assistance information, such as MBS interest indications and / or MBS counting.

[0226] If you agree with Proposal 11, it is worth considering extensions in addition to LTE eMBMS. With LTE eMBMS, neither MII nor counting can collect information from idle UEs, even if the majority of UEs are receiving broadcast services in an RRC idle state. This is, to our understanding, one of the remaining issues with LTE eMBMS from the standpoint of session control and resource efficiency.

[0227] In NR MBS, the same problem can exist with idle / inactive UEs. For example, the network doesn't know if an idle / inactive UE is receiving / interested in broadcast services. Therefore, the network may continue to provide PTM transmissions even if there are no UEs receiving the service. If the gNB is aware of the interest of idle / inactive UEs, such unnecessary PTMs should be avoided. Conversely, if a PTM stops while there are still idle / inactive UEs receiving the service, many UEs may request connections simultaneously, which is also undesirable.

[0228] Therefore, it is worth considering whether to introduce a mechanism to collect UE assistance information, specifically for MBMS counting, from idle / inactive UEs. Needless to say, it is desirable that idle / inactive UEs can report information without transitioning to RRC Connected. This could be achieved, for example, if PRACH resource partitioning associated with MBS services were introduced into such reporting.

[0229] Proposal 12: RAN2 should consider whether UE assistance information, such as MBS counting, is also collected from idle / inactive UEs.

Claims

1. A communication control method used in a mobile communication system that provides multicast broadcast services (MBS) from a network node to user equipment, The user device receives MBS settings transmitted via dedicated signaling from the network node, The user device has the ability to receive MBS settings transmitted via multicast signaling from the network node, The MBS configuration transmitted via the dedicated signaling includes scheduling information for the MBS traffic channel corresponding to the MBS multicast session. The MBS settings transmitted via the multicast signaling include the scheduling information corresponding to the same MBS multicast session as the MBS multicast session. Communication control method.

2. User equipment used in a mobile communication system that provides multicast broadcast services (MBS), The system includes a receiving unit that receives MBS settings transmitted via dedicated signaling from network nodes. The receiving unit receives the MBS settings transmitted via multicast signaling from the network node, The MBS configuration transmitted via the dedicated signaling includes scheduling information for the MBS traffic channel corresponding to the MBS multicast session. The MBS settings transmitted via the multicast signaling include the scheduling information corresponding to the same MBS multicast session as the MBS multicast session. User device.

3. A chipset for user equipment used in a mobile communication system that provides multicast broadcast services (MBS), The process of receiving MBS settings transmitted via dedicated signaling from network nodes, The process of receiving MBS settings transmitted via multicast signaling from the network node is performed, The MBS configuration transmitted via the dedicated signaling includes scheduling information for the MBS traffic channel corresponding to the MBS multicast session. The MBS settings transmitted via the multicast signaling include the scheduling information corresponding to the same MBS multicast session as the MBS multicast session. Chipset.

4. User equipment used in mobile communication systems that provide multicast broadcast services (MBS), The process of receiving MBS settings transmitted via dedicated signaling from network nodes, The process of receiving MBS settings transmitted via multicast signaling from the network node is performed. The MBS configuration transmitted via the dedicated signaling includes scheduling information for the MBS traffic channel corresponding to the MBS multicast session. The MBS settings transmitted via the multicast signaling include the scheduling information corresponding to the same MBS multicast session as the MBS multicast session. program.

5. A network node used in a mobile communication system that provides multicast broadcast services (MBS), It includes a transmission unit that transmits MBS settings, which are sent via dedicated signaling, to the user device. The transmitting unit transmits the MBS settings, which are transmitted via multicast signaling, to the user device. The MBS configuration transmitted via the dedicated signaling includes scheduling information for the MBS traffic channel corresponding to the MBS multicast session. The MBS settings transmitted via the multicast signaling include the scheduling information corresponding to the same MBS multicast session as the MBS multicast session. Network node.

6. A mobile communication system having a user device and a network node as described in claim 2.

Images