COMMUNICATION CONTROL METHOD, USER EQUIPMENT, CHIP SET, PROGRAM, BASE STATION, AND SYSTEM

Abstract

To provide a communication control method and user equipment to achieve improvement of multicast broadcasting service.SOLUTION: In a mobile communication service providing multicast broadcasting service (MBS), a communication control method to be performed by user equipment comprises the following steps of: receiving, in the user equipment (UE) in a RRC connected state, an RRC message including MBS settings required for MBS receiving from a base station gNB; MBS receiving, in the UE that has been shifted from the RRC connected state to an RRC idle state or RRC interactive state, using the MBS settings that have been received during the RRC connected state. The RRC message is an abbreviation of RRC reconfiguration message or RRC release message.SELECTED DRAWING: Figure 10

Description

[Technical field]

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

[0002] In recent years, the fifth generation (5G) mobile communication system has been attracting attention. NR (New Radio), the radio access technology (RAT) of the 5G system, has features such as high speed, large capacity, high reliability, and low latency compared to LTE (Long Term Evolution), the fourth generation radio access technology. [Prior art documents] [Non-patent literature]

[0003] [Non-Patent Document 1] 3GPP technical specification "3GPP TS 38.300 V16.3.0 (2020-09)" Summary of the Invention

[0004] A communication control method according to a first aspect is a method executed by a user device in a mobile communication system that provides a multicast / broadcast service (MBS). The communication control method includes the steps of: the user device in an RRC (Radio Resource Control) connected state receiving an RRC message including an MBS setting required for MBS reception from a base station; and the user device that has transitioned from the RRC connected state to an RRC idle state or an RRC inactive state receiving the MBS using the MBS setting received in the RRC connected state. The RRC message is an RRC Reconfiguration message or an RRC Release message.

[0005] A user device according to a second aspect is a device used in a mobile communication system that provides a multicast broadcast service (MBS). The user device includes a receiver that receives an RRC message including an MBS setting required for MBS reception from a base station when the user device is in an RRC (Radio Resource Control) connected state, and a controller that performs the MBS reception using the MBS setting received in the RRC connected state after the user device transitions from the RRC connected state to an RRC idle state or an RRC inactive state. The RRC message is an RRC Reconfiguration message or an RRC Release message. [Brief description of the drawings]

[0006] [Figure 1] 1 is a diagram showing a configuration of a mobile communication system according to an embodiment. [Diagram 2] FIG. 2 is a diagram showing a configuration of a UE (user equipment) according to an embodiment. [Diagram 3] A diagram showing the configuration of a gNB (base station) according to an embodiment. [Figure 4] A diagram showing the configuration of a protocol stack of a wireless interface of a user plane that handles data. [Diagram 5] FIG. 2 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. 2 is a diagram showing an overview of MBS traffic distribution according to an embodiment. [Figure 7] FIG. 13 is a diagram illustrating a distribution mode according to the embodiment. [Figure 8] A diagram showing a split MBS bearer according to an embodiment. [Figure 9] 13 is a diagram showing an example of the configuration of an RRC Reconfiguration message used to set MBS reception in distribution mode 1. [Figure 10] FIG. 1 illustrates an operation according to an embodiment. [Figure 11]FIG. 10 is a diagram illustrating an operation according to a first modified example of the embodiment. [Figure 12] FIG. 11 is a diagram illustrating an operation according to a second modified example of the embodiment. [Figure 13] FIG. 13 is a diagram illustrating an operation according to a third modified example of the embodiment. [Figure 14] FIG. 13 is a diagram illustrating an operation according to a fourth modified example of the embodiment. [Figure 15] FIG. 13 is a diagram illustrating an operation according to a fifth modified example of the embodiment. [Figure 16] FIG. 13 is a diagram illustrating an operation according to a sixth modified example of the embodiment. [Figure 17] FIG. 13 is a diagram showing an example of a structure of a distribution mode 1 setting. [Figure 18] FIG. 1 is a diagram showing two-stage configuration in LTE SC-PTM. [Figure 19] FIG. 13 is a diagram showing an example of a scheme of distribution mode 2. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0007] The introduction of multicast and broadcast services to the 5G system (NR) is being considered. It is hoped that the NR multicast and broadcast services will provide improved services compared to the LTE multicast and broadcast services.

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

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

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

[0011] 1 is a diagram showing a configuration of a mobile communication system according to an embodiment. This mobile communication system complies with the 3GPP standard 5th Generation System (5GS). In the following description, 5GS is taken as an example, but the mobile communication system may be at least partially applied to an LTE (Long Term Evolution) system and / or a 6th Generation (6G) 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 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), and / or an aircraft or a device provided in an aircraft (Aerial UE).

[0014] 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 the 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"), and / or a measurement control function for mobility control and scheduling. 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 for wireless communication with the UE 100. One cell belongs to one carrier frequency.

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

[0016] 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 Non-Access Stratum (NAS) signaling. The UPF controls data forwarding. The AMF and the UPF are connected to the gNB 200 via an NG interface, which is an interface between a base station and a core network.

[0017] FIG. 2 is a diagram showing a configuration of a UE 100 (user equipment) according to an embodiment.

[0018] As shown in FIG. 2, the UE 100 includes a receiving unit 110, a transmitting unit 120, and a control unit .

[0019] The receiving unit 110 performs various receptions 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 transmission unit 120 performs various transmissions under the control of the control unit 130. The transmission 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 in the UE 100. 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 processing 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 processing.

[0022] FIG. 3 is a diagram showing the configuration of a gNB 200 (base station) according to one embodiment.

[0023] As shown in FIG. 3, the gNB 200 includes a transmitter 210, a receiver 220, a control unit 230, and a backhaul communication unit 240.

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

[0025] The receiving unit 220 performs various receptions 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.

[0026] The control unit 230 performs various controls in the gNB 200. 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 processing 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 processing.

[0027] The backhaul communication unit 240 is connected to adjacent base stations via an inter-base station interface. The backhaul communication unit 240 is connected to the AMF / UPF 300 via a base station-core network interface. Note that the gNB is composed of a CU (Central Unit) and a DU (Distributed Unit) (i.e., the functions are divided), and both units may be connected to each other via an F1 interface.

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

[0029] As shown in FIG. 4, 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.

[0030] 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 the UE 100 and the PHY layer of the gNB 200 via a physical channel.

[0031] 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 the UE 100 and the MAC layer of the gNB 200 via a transport channel. The MAC layer of the gNB 200 includes a scheduler. The scheduler determines the uplink and downlink transport format (transport block size, modulation and coding scheme (MCS)) and the resource blocks to be assigned to the UE 100.

[0032] The RLC layer transmits data to the RLC layer on the receiving side by using the functions of the MAC layer and the 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 a logical channel.

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

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

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

[0036] As shown in FIG. 5, 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.

[0037] Between the RRC layer of the UE 100 and the RRC layer of the gNB 200, RRC signaling for various settings is transmitted. 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 the UE 100 and the RRC of the gNB 200, the UE 100 is in an RRC connected state. When there is no connection (RRC connection) between the RRC of the UE 100 and the RRC of the gNB 200, the UE 100 is in an RRC idle state. When the connection between the RRC of the UE 100 and the RRC of the gNB 200 is suspended, the UE 100 is in an RRC inactive state.

[0038] The NAS layer, which is located above the RRC layer, performs session management, mobility management, etc. NAS signaling is transmitted between the NAS layer of the UE 100 and the NAS layer of the AMF 300B.

[0039] In addition, the UE 100 has an application layer and the like in addition to the protocol of the radio interface.

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

[0041] 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 MBS include public safety 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 services to all UEs 100 within a particular service area for applications that do not require reliable QoS. The multicast service provides services to a group of UEs 100 that have joined the multicast service, rather than to all UEs 100. The multicast service allows the same content to be provided to a group of UEs 100 in a more radio-efficient manner than the broadcast service.

[0043] FIG. 6 is a diagram illustrating an overview of MBS traffic delivery according to one embodiment.

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

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

[0046] 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 Protocol Data Unit (PDU) session for each UE 100. Therefore, one PDU session for each UE 100 needs to be associated with the multicast session.

[0047] In the 5GC shared MBS traffic delivery method, first, the 5GC 20 receives a single copy of the MBS data packets and delivers the single copy of the MBS data packets to a RAN node (i.e., the gNB 200). Second, the gNB 200 delivers them to one or more UEs 100.

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

[0049] In the PTP delivery method, the gNB 200 delivers individual copies of the MBS data packets over the air to each UE 100. On the other hand, in the PTM delivery method, the gNB 200 delivers a single copy of the MBS data packets over the air to a group of UEs 100. The gNB 200 dynamically decides whether to use PTM or PTP as the delivery method for MBS traffic to one UE 100.

[0050] The PTP distribution method and the PTM distribution method are mainly related to the user plane. There are two distribution modes for the control mode of MBS traffic distribution: distribution mode 1 and distribution mode 2. Figure 7 is a diagram showing the distribution modes according to an embodiment.

[0051] As shown in FIG. 7, delivery mode 1 is a delivery mode available to UE 100 in an RRC connected state, and is a delivery mode for high QoS requirements. Delivery mode 1 is used only for a multicast session among MBS sessions. In one embodiment, it is assumed that delivery mode 1 is used for a multicast session, but delivery mode 1 may be used for a broadcast session. Delivery mode 1 may also be available to UE 100 in an RRC idle state or an RRC inactive state.

[0052] In one embodiment, the configuration of MBS reception in distribution mode 1 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. The configuration of MBS reception includes scheduling information of an MBS traffic channel that carries MBS traffic. The MBS traffic channel, which is a type of logical channel, is sometimes called an MTCH (Multicast Traffic Channel). The MBS traffic channel is mapped to a DL-SCH (Downlink Shared Channel), which is a type of transport channel.

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

[0054] The setting of MBS reception in distribution mode 2 is performed by a logical channel, for example, a BCCH (Broadcast Control Channel) or an MCCH (Multicast Control Channel), transmitted by broadcast from the gNB 200 to the UE 100. Hereinafter, such a control channel is referred to as an MBS control channel.

[0055] In addition, the network can provide different MBS services for each MBS session. The MBS session is identified by at least one of a Temporary Mobile Group Identity (TMGI) and a session identifier. At least one of these identifiers is called an MBS session identifier. Such an MBS session identifier may be called an MBS service identifier or a multicast group identifier.

[0056] (Split MBS Bearer) Next, a split MBS bearer according to an embodiment will be described. The split MBS bearer is available in the above-mentioned delivery mode 1.

[0057] The gNB200 can set an MBS bearer separated into a PTP communication path and a PTM communication path (hereinafter referred to as a "split MBS bearer" as appropriate) for the UE100. 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 improve reliability by using PTP and PTM in combination to transmit the same MBS traffic twice. Alternatively, the gNB200 can improve reliability by initially transmitting MBS traffic to multiple UE100 using PTM and retransmitting the MBS traffic to a specific UE100.

[0058] The predetermined layer that terminates the split 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 the split 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.

[0059] 8 is a diagram showing a split MBS bearer according to an embodiment. In the following, a PTP communication path is called a PTP leg, and a PTM communication path is called a PTM leg. In addition, a functional unit corresponding to each layer is called an entity.

[0060] As shown in Fig. 8, each of the PDCP entity of the gNB 200 and the PDCP entity of the UE 100 separates an MBS bearer, 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.

[0061] Each of the gNB 200 and the UE 100 has two RLC entities provided for each leg, one MAC entity, and one PHY entity. The 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.

[0062] 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 Group Radio Network Temporary Identifier (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.

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

[0064] In addition, in order for the gNB200 and the UE100 to perform PTP transmission (unicast) of MBS traffic using a PTP leg, a split MBS bearer must be set from the gNB200 to the UE100, and the PTP leg must be activated. In other words, even if a split MBS bearer is set to the UE100, the gNB200 cannot perform PTP transmission of MBS traffic using this PTP leg if the PTP leg is in an inactive state.

[0065] In a state in which the PTM leg is activated, the UE 100 monitors a PDCCH (Physical Downlink Control Channel) to which a G-RNTI associated with the MBS session is applied (i.e., blind decoding of the PDCCH is performed using the G-RNTI). The UE 100 may monitor the PDCCH only at a scheduling opportunity for the MBS session.

[0066] In a state in which the PTM leg is deactivated, the UE 100 does not monitor the PDCCH to which the G-RNTI associated with the MBS session is applied (that is, does not perform blind decoding of the PDCCH using the G-RNTI).

[0067] UE 100 monitors the PDCCH to which the C-RNTI is applied when the PTP leg is activated. When discontinuous reception (DRX) is set in the PTP leg, UE 100 monitors the PDCCH in the set on duration (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.

[0068] In a state where 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 traffic. However, when a cell (frequency) associated with an MBS session is specified, the UE 100 may not monitor the PDCCH for the MBS session.

[0069] It is assumed that the split MBS bearer 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.

[0070] (Operation according to one embodiment) Next, an operation according to an embodiment will be described below, mainly assuming that distribution mode 1 is used as the distribution mode.

[0071] Fig. 9 is a diagram showing a configuration example of an RRC Reconfiguration message used for setting MBS reception in distribution mode 1. As shown in Fig. 9, the RRC Reconfiguration message transmitted from the gNB 200 to the UE 100 includes MBS settings required for MBS reception as information elements.

[0072] The MBS settings include basic reception settings, which are basic settings for MBS reception, and RRC connected-only settings that are applicable only to MBS reception in the RRC connected state.

[0073] The basic reception configuration is a common configuration in all RRC states (i.e., RRC connected state, RRC idle state, and RRC inactive state). The basic reception configuration includes MTCH scheduling information. The MTCH scheduling information includes at least one of a group RNTI, an MBS session identifier, a transmission occasion, and a transmission BWP (Bandwidth Part).

[0074] Here, the group RNTI is an RNTI commonly assigned to a group of UEs 100. The transmission occasion is a candidate for a timing (e.g., a subframe) at which the gNB 200 transmits MBS traffic using the MTCH. The transmission BWP is a BWP at which the gNB 200 transmits MBS traffic using the MTCH. The BWP is a bandwidth portion narrower than the frequency bandwidth of one cell, and is intended to limit the operating bandwidth of the UE 100.

[0075] On the other hand, the RRC connected dedicated configuration includes a configuration related to a split MBS bearer, and includes at least one of a bearer configuration of a split MBS bearer, a dynamic switching configuration between PTP and PTM, and a PTP leg configuration. Note that the PTM leg configuration can be used in the RRC idle state or the RRC inactive state, and therefore may be included in the basic reception configuration. The RRC connected dedicated configuration may include a HARQ feedback configuration.

[0076] In one embodiment, when there is no ongoing data for a multicast session for a UE 100 having an MBS configuration, the gNB 200 transitions the UE 100 to an RRC idle state or an RRC inactive state, where the gNB 200 may be in a situation where it cannot keep the UE 100 in an RRC connected state due to congestion.

[0077] It is desirable that the UE 100 can continue to receive the MBS even when the UE 100 transitions to the RRC idle state or the RRC inactive state. In one embodiment, the UE 100 continues to apply the MBS configuration provided by the RRC Reconfiguration message as the MBS configuration to be used in the RRC idle state or the RRC inactive state. That is, the UE 100 reuses the MBS configuration provided in the RRC connected state.

[0078] That is, when the UE 100 according to one embodiment is in an RRC connected state, the UE 100 receives an RRC Reconfiguration message (RRC message) including an MBS setting required for MBS reception from a base station. After transitioning from the RRC connected state to an RRC idle state or an RRC inactive state, the UE 100 performs MBS reception using the MBS setting received in the RRC connected state.

[0079] Here, the handling of the RRC connected dedicated setting among the MBS settings becomes an issue. When the UE 100 according to one embodiment transitions to the RRC idle state or the RRC inactive state, the UE 100 performs a process of invalidating the RRC connected dedicated setting included in the MBS setting received in the RRC connected state. This can save the storage capacity of the UE 100 and suppress the occurrence of unexpected errors.

[0080] FIG. 10 is a diagram illustrating operations according to one embodiment.

[0081] As shown in FIG. 10, in step S101, UE100 is in an RRC connected state in a cell of gNB200.

[0082] In step S102, the gNB 200 transmits an RRC Reconfiguration message including an MBS configuration, that is, a basic reception configuration and an RRC connected-dedicated configuration, to the UE 100. The UE 100 receives the RRC Reconfiguration message.

[0083] In step S103, the UE 100 stores and applies the MBS configuration included in the received RRC Reconfiguration message.

[0084] In step S104, UE100 receives MBS traffic from gNB200 using the MBS settings applied in step S103, i.e., the basic reception settings and the RRC connected dedicated settings.

[0085] In this manner, the UE 100 receives the MBS configuration in the RRC Reconfiguration message and receives the MBS traffic.

[0086] Then, in step S105, the gNB200 identifies the UE100 to be transitioned to the RRC idle state or the RRC inactive state.

[0087] Here, the gNB200 may identify the UE100 receiving the target MBS session as the UE100 to be transitioned to the RRC idle state or the RRC inactive state. For example, when the MBS traffic transmission in step S104 is performed by multicast, the gNB200 requests information from the 5GC20 and identifies the UE100 receiving the target MBS session. On the other hand, when the MBS traffic transmission in step S104 is performed by broadcast, the gNB200 receives information in advance from the UE100 by an MBS interest indication message (MII). As a result, the gNB200 identifies the UE100 receiving the target MBS session.

[0088] The gNB200 may identify a non-moving UE100 as a UE100 to transition to an RRC idle state or an RRC inactive state.

[0089] In the case of a moving UE 100, the gNB 200 may need to perform handover control to ensure the continuity of the MBS service, so it is desirable to maintain the moving UE 100 in the RRC connected state. On the other hand, since there is no need for such control for a stationary UE 100, the gNB 200 transitions the stationary UE 100 to the RRC idle state or the RRC inactive state. This reduces the load on the gNB 200.

[0090] In addition, when the UE 100 leaves a cell (or an area range described later), the MBS setting of this cell may become invalid, but there is no such risk for a stationary UE 100. Therefore, the gNB 200 can reduce the load of the gNB 200 by transitioning the stationary UE 100 to an RRC idle state or an RRC inactive state.

[0091] In addition, the gNB200 may identify a UE 100 whose residence time in its own cell exceeds a predetermined time as a UE 100 that does not move. The gNB200 may also identify a UE 100 that does not move based on location information periodically received from the UE 100. Alternatively, the gNB200 may identify a UE 100 that does not move by being notified of a movement state from the UE 100. The notification may be notified by a request from the gNB200. The notification may be notified by the UE 100 itself (for example, accompanying a change in the movement state). The movement state may be notified using an MBS interest indication (MII). The movement state may be notified in association with interest information in MBS reception.

[0092] In step S106, the gNB 200 transmits an RRC Release message to the UE 100 identified in step S105. The UE 100 receives the RRC Release message. When the gNB 200 transitions the UE 100 to an RRC inactive state, the gNB 200 transmits an RRC Release message including suspend config as an information element to the UE 100.

[0093] In step S107, the UE 100 transitions to an RRC idle state or an RRC inactive state based on the received RRC Release message.

[0094] In step S108, the UE 100 continues to apply the basic reception setting and performs a process of invalidating the RRC connected-dedicated setting. The invalidation process is to discard the RRC connected-dedicated setting, to suspend the application of the RRC connected-dedicated setting, or to deactivate the RRC connected-dedicated setting.

[0095] In the case of suspend or deactivate, the RRC connected dedicated setting is retained without being discarded. The retained RRC connected dedicated setting may be restored (enabled) when the UE 100 returns to the RRC connected state again. Note that the operation of the UE 100 transitioning from the RRC inactive state to the RRC connected state is called resume (RRC resume). The UE 100 may not activate the retained RRC connected dedicated setting at the time of RRC resume. The UE 100 may activate the RRC connected dedicated setting when the cell at the time of transitioning to the RRC idle state or the RRC inactive state is the same as the cell at the time of returning to the RRC connected state, and may not activate the RRC connected dedicated setting when these are different cells (details will be described in a modification example described later).

[0096] In step S108, the UE 100 may release an entity that has been used only in the RRC connected state, for example, an RLC entity of a PTP leg. The UE 100 may reconfigure an associated entity, for example, deactivate a split (or combination) function of a PDCP entity.

[0097] In step S109, the UE 100 continues to receive the MBS traffic in the RRC idle state or the RRC inactive state using the basic reception configuration.

[0098] (First modified example) Next, a first modification of the above embodiment will be described, focusing mainly on the differences from the above embodiment.

[0099] In this modification, when UE100 transitions from the RRC connected state to the RRC inactive state, it holds the RRC connected-only setting. This allows UE100 to effectively use the held setting to quickly set up a split MBS bearer, etc. Note that the gNB200 when UE100 transitions to the RRC inactive state and the gNB200 when UE100 returns to the RRC connected state may be the same, or these gNB200 may be different.

[0100] In this modification, the UE 100 that has transitioned to the RRC inactive state holds the RRC connected-only setting in the RRC inactive state. The UE 100 transmits a notification indicating that the RRC connected-only setting is held to the gNB 200 during a resume operation for transitioning from the RRC inactive state to the RRC connected state. The gNB 200 that has received this notification instructs the UE 100 whether or not to enable the RRC connected-only setting held by the UE 100.

[0101] 11 is a diagram illustrating an operation according to a first modified example of the embodiment. Here, an example will be described in which the gNB 200a when the UE 100 transitions to the RRC inactive state is different from the gNB 200b when the UE 100 returns to the RRC connected state.

[0102] As shown in Fig. 11, the operations of steps S201 to S208 are the same as those of the above-mentioned embodiment. However, in this modification, the UE 100 disables and holds the RRC connected-dedicated setting when transitioning to the RRC inactive state. In step S209, the UE 100 continues to receive MBS traffic in the RRC inactive state using the basic reception setting.

[0103] In step S210, UE 100, which is in an RRC inactive state, performs cell reselection from the cell of gNB 200a to the cell of gNB 200b.

[0104] When UE100 decides to resume the RRC connection, in step S211, it initiates a random access procedure with gNB200b.

[0105] A typical random access procedure in the case of RRC resume includes the following 1) to 5). 1) Transmission of random access preamble (Msg1) from UE 100 to gNB 200b 2) Transmission of a random access response (Msg2) from the gNB 200b to the UE 100 3) Transmission of an RRC Resume Request message (Msg3) from the UE 100 to the gNB 200b 4) Transmission of RRC Resume message (Msg4) from gNB 200b to UE 100 5) Transmission of RRC Resume Complete message (Msg5) from UE 100 to gNB 200b On the other hand, in the two-step random access procedure, Msg1 and Msg3 are combined into one message (MsgA), and Msg2 and Msg4 are combined into one message (MsgB).

[0106] In such a random access procedure, the UE 100 transmits Msg1 or MsgA using a special PRACH (Physical Random Access Channel) resource. As a result, the UE 100 notifies the gNB 200b that it holds the RRC connected dedicated setting (step S211a). Alternatively, the UE 100 transmits Msg3, MsgA, or Msg5 including an information element indicating that it holds the RRC connected dedicated setting. As a result, the UE 100 notifies the gNB 200b that it holds the RRC connected dedicated setting (step S211a).

[0107] The gNB 200b that has received the retention notification from the UE 100 determines whether to activate the RRC connected-dedicated setting retained by the UE 100, and transmits an instruction indicating the determination result to the UE 100 (step S212). For example, the gNB 200b may determine to activate the RRC connected-dedicated setting retained by the UE 100 only when the context information of the UE 100 can be acquired from the gNB 200a.

[0108] When the UE 100 receives an instruction to activate the RRC connected-dedicated setting from the gNB 200b, the UE 100 activates the held RRC connected-dedicated setting. On the other hand, when the UE 100 does not receive an instruction to activate the RRC connected-dedicated setting from the gNB 200b, the UE 100 does not activate the held RRC connected-dedicated setting. In this case, the UE 100 may discard the held RRC connected-dedicated setting.

[0109] (Second modified example) Next, a second modification of the above embodiment will be described, focusing mainly on differences from the above embodiment. In this modification, the UE 100 holds the RRC connected-only setting when transitioning from the RRC connected state to the RRC idle state or the RRC inactive state.

[0110] The multicast session (delivery mode 1) is basically a network-controlled delivery mode in which the UE 100 is maintained in an RRC connected state. However, due to temporary network congestion or the like, the UE 100 is transitioned to an RRC idle state or an RRC inactive state.

[0111] On the other hand, it is assumed that the split MBS bearer in the RRC connected-only setting is often set to the UE 100 at the cell edge. For example, since the radio condition of the UE 100 at the cell edge is poor, the gNB 200 may transmit MBS traffic using the PTP leg. Alternatively, since the UE 100 at the cell edge is likely to perform handover, the gNB 200 may transmit MBS traffic using the PTP leg to eliminate packet loss during handover.

[0112] For this reason, in this modification, the UE 100 that transitions to the RRC idle state or the RRC inactive state and holds the RRC connected-only setting notifies the gNB 200 before performing cell reselection to another cell at the cell edge. This enables the gNB 200 (network) to perform mobility control for the UE 100 based on the notification.

[0113] In this modification, when the UE 100 determines that a predetermined condition (trigger condition) related to cell reselection is satisfied in the RRC idle state or the RRC inactive state, the UE 100 starts a random access procedure for the gNB 200. In the random access procedure, the UE 100 transmits a notification indicating that the predetermined condition is satisfied to the gNB 200.

[0114] Fig. 12 is a diagram showing an operation according to a second modification of the embodiment. Here, a case where UE 100 transitions to an RRC inactive state is assumed, but a case where UE 100 transitions to an RRC idle state may also be assumed. That is, the RRC inactive state in Fig. 12 may be read as the RRC idle state.

[0115] As shown in Fig. 12, the operations of steps S301 to S308 are the same as those of the above-mentioned embodiment. However, in this modification, the UE 100 disables and holds the RRC connected dedicated configuration when transitioning to the RRC inactive state (or the RRC idle state). In step S309, the UE 100 continues to receive MBS traffic in the RRC inactive state (or the RRC idle state) using the basic reception configuration.

[0116] In step S310, the UE 100 detects a trigger for cell reselection from the cell of the gNB 200 to another cell. The trigger condition for cell reselection may be a condition that actually triggers cell reselection, or may be a condition that indicates a sign of triggering cell reselection. The trigger condition may include a threshold value (e.g., an RSRP / RSRQ threshold value) set in the UE 100 by the gNB 200 and information (event information) that specifies a comparison target.

[0117] When UE100 detects a trigger for cell reselection, in step S311, it initiates a random access procedure with gNB200.

[0118] In this random access procedure, the UE 100 transmits a notification to the gNB 200 indicating that the trigger condition for cell reselection is satisfied. As a method of such notification, a method similar to the first modification of the above-mentioned embodiment can be used. That is, the UE 100 transmits Msg1 or MsgA using a special PRACH resource to notify the gNB 200 that the trigger condition for cell reselection is satisfied (step S311a). Alternatively, the UE 100 transmits Msg3, MsgA, or Msg5 including an information element indicating that the trigger condition for cell reselection is satisfied to notify the gNB 200 that the trigger condition for cell reselection is satisfied (step S311a). Note that the UE 100 may transmit a measurement report including radio measurement results indicating its own radio situation to the gNB 200 for use in mobility control in step S312.

[0119] In step S312, the gNB 200 performs mobility control (handover control or cell reselection control) for the UE 100 based on the notification received from the UE 100 in step S311a. For example, the gNB 200 transitions the UE 100 to an RRC connected state and then performs handover to another cell. Alternatively, the gNB 200 keeps the UE 100 in an RRC idle state or an RRC inactive state and causes the UE 100 to perform cell reselection to another cell. In this case, the gNB 200 may instruct the UE 100 to discard the RRC connected-only setting.

[0120] (Third modified example) Next, a third modification of the above embodiment will be described, focusing mainly on the differences from the above embodiment.

[0121] In this modification, the UE 100 having the RRC connected dedicated setting in the RRC connected state is prohibited from transitioning to the RRC idle state or the RRC inactive state. Under such a premise, the gNB 200 causes the UE 100 to release (discard) the RRC connected dedicated setting before transitioning the UE 100 to the RRC idle state or the RRC inactive state, and then transitions the UE 100 to the RRC idle state or the RRC inactive state. Then, after the gNB 200 releases the RRC connected dedicated setting, the UE 100 transitions to the RRC idle state or the RRC inactive state.

[0122] FIG. 13 is a diagram showing an operation according to the third modified example of the embodiment.

[0123] As shown in Fig. 13, the operations of steps S401 to S405 are the same as those of the above-described embodiment. However, in step S405, the gNB 200 may identify a UE 100 that can transition to an RRC idle state or an RRC inactive state. For example, the gNB 200 identifies a UE 100 that is not expected to perform uplink transmission for a certain period of time or a UE 100 that does not perform unicast communication. In step S405, the gNB 200 may identify a UE 100 that has transmitted a message prompting the release of an RRC connection, for example, a Release Assistance Information (RAI) message.

[0124] In step S406, gNB200 sends an RRC Reconfiguration message to the identified UE100, the RRC Reconfiguration message including an information element indicating the release of the RRC connected dedicated setting.

[0125] In step S407, in response to receiving the RRC Reconfiguration message in step S406, the UE 100 releases (discards) the RRC connected-dedicated configuration. The UE 100 enters a state in which it has only the PTM MBS configuration (basic reception configuration) among the MBS configurations.

[0126] In step S408, the gNB 200 transmits an RRC Release message to the UE 100 that has released the RRC connected-dedicated configuration. The UE 100 receives the RRC Release message.

[0127] In step S409, the UE 100 transitions to an RRC idle state or an RRC inactive state based on the received RRC Release message.

[0128] In step S410, the UE 100 continues to apply the basic reception configuration.

[0129] In step S411, the UE 100 continues to receive MBS traffic in the RRC idle state or the RRC inactive state using the basic reception configuration.

[0130] In this modification, a scenario in which the MBS configuration is performed by an RRC Reconfiguration message is assumed, but a scenario in which the MBS configuration is performed by an RRC Release message may also be assumed. In a scenario in which the MBS configuration is performed by an RRC Release message, the transmission of the RRC Reconfiguration message in step S406 is not necessary. In such a scenario, the gNB 200 may be prohibited from performing the RRC connected-only configuration by an RRC Release message. For example, an information element regarding the RRC connected-only configuration may be a condition setting that cannot be used in an RRC Release message.

[0131] (Fourth modified example) Next, a fourth modification of the above embodiment will be described, focusing mainly on the differences from the above embodiment.

[0132] In this modification, the MBS setting is common in an area range consisting of a plurality of cells. As a result, the UE 100 that has transitioned to the RRC idle state or the RRC inactive state can continue to receive MBS traffic within the area range without updating the MBS setting. The area range may be defined as an area in which notification is not required according to the first and second modifications of the above-mentioned embodiment.

[0133] Specifically, the UE 100 according to this modification receives an RRC message (RRC Reconfiguration message or RRC Release message) including area information indicating an area range in which the MBS setting is valid from the gNB 200. The UE 100 that has transitioned to the RRC idle state or the RRC inactive state performs MBS reception using the MBS setting within the area range indicated by the area information.

[0134] FIG. 14 is a diagram showing an operation according to the fourth modified example of the embodiment.

[0135] As shown in FIG. 14, the operations of steps S501 to S507 are the same as those of the above-described embodiment. However, in step S502 or S506, the gNB 200 transmits area information together with the MBS setting to the UE 100, thereby setting the area range in which the MBS setting is valid to the UE 100. The area information may be a list consisting of identifiers (cell identifiers) of each cell constituting the area range. Since each cell broadcasts the identifier of its own cell, the UE 100 can determine whether or not the UE 100 is within the area range by using the set list. Alternatively, the area information may be an identifier (area identifier) ​​indicating the area range. Since each cell broadcasts the area identifier of the area range to which the UE 100 belongs, the UE 100 can determine whether or not the UE 100 is within the area range by using the set area identifier.

[0136] In step S507, the UE 100 transitions to an RRC idle state or an RRC inactive state based on the RRC Release message received in step S506.

[0137] In steps S508 and S509, the UE 100 continues to receive MBS traffic using the basic reception setting among the MBS settings set by the gNB 200. Here, the UE 100 considers that the MBS setting is valid within the area range set by the gNB 200, and does not notify the network even when performing cell reselection.

[0138] When the UE 100 moves to a cell outside the area range, the UE 100 receives a new MBS configuration from the cell by performing random access to the cell outside the area range. Alternatively, when the UE 100 detects a cell outside the area range, the UE 100 may receive a new MBS configuration from the cell by performing random access to the current cell before moving outside the area range.

[0139] (Fifth modified example) Next, a fifth modification of the above embodiment will be described, focusing mainly on the differences from the above embodiment.

[0140] In this modification, the gNB 200 notifies the UE 100 by an RRC Release message whether the MBS configuration (specifically, the basic reception configuration) by the RRC Reconfiguration message may be used in the RRC idle state or the RRC inactive state. That is, the UE 100 receives from the gNB 200 an RRC Release message including information indicating whether the MBS configuration received in the RRC connected state is usable in the RRC idle state or the RRC inactive state.

[0141] FIG. 15 is a diagram showing an operation according to the fifth modified example of the embodiment.

[0142] 15, the operations of steps S601 to S609 are the same as those of the above-described embodiment. However, in step S606, the gNB 200 transmits an RRC Release message including any one of the following information A) and B) to the UE 100.

[0143] A) Information indicating whether the MBS configuration configured in the RRC Reconfiguration message in step S602 may be continued to be used in the RRC idle state or the RRC inactive state.

[0144] B) Information indicating the expiration date when the MBS configuration set in the RRC Reconfiguration message in step S602 is used in an RRC idle state or an RRC inactive state. The information indicating the expiration date may be expressed by at least one of a System Frame Number (SFN), a Hyper SFN (H-SFN), and a subframe. The information indicating the expiration date may be a timer value indicating the time length of the expiration date.

[0145] In the above-mentioned case A), UE100 continues to use the MBS setting in the RRC Reconfiguration message of step S602 in RRC idle state or RRC inactive state only if it receives an RRC Release message from gNB200 including information indicating that continued use is permitted (step S606).

[0146] In the above-mentioned case B), UE 100 continues to use the MBS setting in the RRC Reconfiguration message in step S602 in the RRC idle state or the RRC inactive state only within the validity period set in the RRC Release message. Note that, if the validity period is set by a timer value, UE 100 starts a timer (a timer corresponding to the timer value) when transitioning to the RRC idle state or the RRC inactive state (step S607), and continues to use the MBS setting until the timer expires.

[0147] Here, when the expiration date has expired (when the timer has expired), UE 100 that is still interested in receiving MBS may receive a new MBS configuration from gNB 200 by performing random access to gNB 200. In the random access procedure, UE 100 may notify gNB 200 that the access is for updating the MBS configuration. The notification may be indicated by Msg1 / MsgA using a special PRACH resource, or may be indicated in Msg3. Alternatively, when MBS configuration by distribution mode 2 is broadcast in SIB or MCCH, UE 100 may attempt to acquire MBS configuration by distribution mode 2. On the other hand, UE 100 that is no longer interested in receiving MBS when the expiration date has expired may discard the MBS configuration configured in the RRC Reconfiguration message.

[0148] (Sixth modified example) Next, a sixth modification of the above embodiment will be described, focusing mainly on the differences from the above embodiment.

[0149] In this modification, the UE 100 receives an RRC Release message including neighboring cell information. The neighboring cell information includes an identifier of the neighboring cell and an identifier indicating an MBS service (MBS session) provided by the neighboring cell. This allows the UE 100 to preferentially select a cell that provides an MBS service of interest to the UE 100 when performing cell reselection in the RRC idle state or the RRC inactive state. The UE 100 that has transitioned to the RRC idle state or the RRC inactive state controls cell reselection based on the received neighboring cell information.

[0150] FIG. 16 is a diagram showing an operation according to the sixth modified example of the embodiment.

[0151] As shown in Fig. 16, the operations of steps S701 to S709 are the same as those of the above-described embodiment. However, in step S706, the gNB 200 transmits an RRC Release message including neighboring cell information to the UE 100. The gNB 200 may transmit an RRC Release message including neighboring cell information and an MBS setting (specifically, a basic reception setting) to the UE 100.

[0152] The neighboring cell information includes a list of identifiers (cell identifiers) of neighboring cells and identifiers (session identifiers) indicating MBS services provided by the neighboring cells. The UE 100 performs cell reselection by regarding a cell that provides an MBS setting of interest to the UE 100 as the highest priority in cell reselection.

[0153] (Other embodiments) The above-described modified examples are not limited to being implemented independently, but may be implemented in combination of two or more modified examples.

[0154] In the above embodiment, 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). The base station may be a relay node such as an IAB (Integrated Access and Backhaul) node. The base station may be a DU (Distributed Unit) of the IAB node.

[0155] A program may be provided that causes a computer to execute each process performed by the UE 100 or the gNB 200. The program may be recorded in a computer-readable medium. Using the computer-readable medium, it is possible to install the program in the 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, and may be, for example, a recording medium such as a CD-ROM or a DVD-ROM.

[0156] In addition, 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).

[0157] 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, etc. are possible without departing from the spirit of the invention.

[0158] This application claims priority to U.S. Provisional Application No. 63 / 134,280 (filed January 6, 2021), the entire contents of which are incorporated herein by reference.

[0159] (Additional Note) (introduction) A revised work item on Multicast Broadcast Service (MBS) for NR was approved. It was agreed to introduce two delivery modes for MBS as follows:

[0160] In Rel-17, R2 specifies the following two modes: 1: Delivery mode for high QoS (reliability, delay) requirements available in Connected (UE may be able to switch to other states if there is no data reception, but this is yet to be determined). 2: Delivery mode for “low” QoS requirements. UE may receive data even when inactive / idle (details to be determined). R2 assumes (as in R17) that delivery mode 1 is used only for multicast sessions. · R2 assumes that delivery mode 2 is used for broadcast sessions. The applicability of delivery mode 2 to multicast sessions requires further study. No Data: If there is no ongoing data in the multicast session, the UE may remain in RRC Connected. Other cases require further consideration.

[0161] Regarding distribution mode 2, the following MBS setting outline was additionally agreed upon:

[0162] The UE receives the MBS configuration (in case of broadcast / distribution mode 2) via BCCH and / or MCCH (TBD), which can be received in idle / inactive mode. Connected mode needs further study. A notification mechanism is used to notify changes in the MBS control information.

[0163] This addendum considers the control plane aspects of NR MBS, taking into account the LTE eMBMS mechanisms and the latest RAN2 agreements.

[0164] (Discussion) As per the RAN2 agreement, the two delivery modes at this point are summarized in Table 1.

[0165] [Table 1]

[0166] (Distribution mode 1 setting) Delivery mode 1 is considered mainly for data reception in RRC Connected, but configuration aspects are not yet agreed. It could be quite simple that MBS configuration is provided by RRC reconfiguration, but MCCH reception in Connected like LTE eMBMS is still under consideration. Given that delivery mode 1 is expected for high QoS services, it should involve e.g. PTP / PTM split bearer and / or lossless handover. In our view, RRC reconfiguration should be used for configuration of delivery mode 1, since it would be meaningless if these UE specific configurations were provided via MCCH.

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

[0168] On the other hand, WID clearly indicates that RRC Connected and Idle / Inactive should have maximum commonality in terms of MBS configuration, as follows, but RAN2 agreed to separate delivery modes for multicast and broadcast sessions respectively.

[0169] With the aim of maintaining maximum commonality in the configuration of PTM reception between the RRC Connected and RRC Idle / Inactive states, this document specifies the changes required to enable reception of PTM transmissions by UEs in RRC Idle / Inactive state.

[0170] Even though the RRC messages for these delivery modes are different, to achieve the objectives of WID, the structures and IEs of MBS configuration should be aligned as much as possible between the two delivery modes. For example, the RRC reconfiguration for delivery mode 1 includes delivery mode 1 specific information such as PTP / PTM split bearer and handover related information in addition to the MTCH scheduling information, which is a common block with delivery mode 2. Therefore, the details require further study at this point.

[0171] Proposal 2: RAN2 should agree to aim for maximum commonality between the two delivery modes in terms of MBS configuration, e.g., by using common structures and IEs.

[0172] 17 indicates only the MTCH scheduling information, i.e., the MTCH configuration related to the MBS session information. In the case of distribution mode 1, the neighboring cell information is not required.

[0173] Further study is needed to determine whether UEs can be released to idle / inactive when there is no ongoing data for a multicast session. In other words, whether idle / inactive UEs can receive MBS data via delivery mode 1. As agreed by RAN2, the baseline is that UEs should be kept in delivery mode 1, i.e. RRC connected, for multicast sessions that require high QoS. However, other / exceptional cases are still worth considering.

[0174] During email discussions, some companies noted that due to congestion, the network may not be able to keep all UEs connected, while others noted that UEs do not need to stay connected all the time due to uplink activity, QoS requirements, and / or UE power consumption.

[0175] From the RAN2 point of view, it may be considered beneficial for both the network and the UE to support this feature. It is assumed that it is up to the gNB implementation whether / when the UE is released to inactive and up to the core network whether the UE is released to idle. One concern about MBS data reception in idle is that the gNB releases the UE context, whereas the UE context is kept in inactive. This means that the controllability of the gNB may be lost, which may contradict the general delivery mode 1 concept. Therefore, RAN2 should agree that delivery mode 1 may be received by the UE at least in inactive, but further consideration is required in idle.

[0176] Proposal 3: In distribution mode 1, RAN2 should agree that UE can receive distribution mode 1 at least inactively. Further consideration is needed in idle.

[0177] If proposal 3 can be agreed upon, it is not clear how the idle / inactive MBS configuration is provided to the UE. Three options are considered:

[0178] Option 1: RRC reconfiguration An Idle / Inactive UE will continue to apply the MBS configuration provided by RRC Reconfiguration. This option is straightforward since the UE just reuses the MBS configuration originally provided for RRC Connected. However, some UE behavior may need to be considered when transitioning to Idle / Inactive and / or when resuming RRC Connected, e.g. how to handle PTP / PTM split bearer configuration if configured.

[0179] Option 2: RRC Release Idle / inactive UEs apply the MBS configuration provided by RRC release. This option is straightforward but may not be efficient since it is doubtful whether the MBS configuration will be different from the one previously provided by RRC reconfiguration.

[0180] Option 3: Switching distribution mode from Mode 1 to Mode 2 Before the UE is released to idle / inactive, it is switched from distribution mode 1 to distribution mode 2. This option is another easy solution, since distribution mode 2 is designed to be able to receive data in all RRC states as agreed by RAN2. However, packet losses and / or delays can be expected during switching, e.g. due to MCCH acquisition.

[0181] Each option has its pros and cons, but in our view, option 1 is slightly more preferable from the perspective of simplicity and efficiency. RAN2 should consider, but not be limited to, the above options and discuss how to provide a distribution mode 1 configuration for data reception in idle / inactive mode.

[0182] Proposal 4: If proposal 3 can be agreed upon, RAN2 should discuss how the UE is provided with the delivery mode 1 configuration for inactive data reception.

[0183] (Distribution mode 2 setting) In LTE SC-PTM, configuration is provided by two messages: SIB20 and SC-MCCH. SIB20 provides SC-MCCH scheduling information, and SC-MCCH provides SC-MTCH scheduling information including G-RNTI and TMGI, and neighbor cell information.

[0184] The advantage of the LTE two-stage configuration as shown in Figure 18 was that the SC-MCCH scheduling was independent from the SIB20 scheduling in terms of repetition period, duration, modification period etc. This facilitated frequent scheduling / updating of the SC-MCCH, especially for delay-sensitive services and / or UEs that join the session late. According to WID, this is also the case for NR MBS, since one of the applications is group communication etc.

[0185] Observation 1: In LTE, the two-stage configuration with SIB20 and SC-MCCH lends itself to different scheduling of these control channels, which also lends itself to NR MBS.

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

[0187] In addition to Proposal 5, it is envisaged that NR MBS will support the various types of use cases listed in the WID. It is noted that NR MBS should be appropriately designed for different requirements, ranging from delay-sensitive applications such as mission-critical and V2X to delay-tolerant applications such as IoT, in addition to 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 delivery mode 2, while others with "high QoS requirements" require delivery mode 1. In this sense, it is beneficial for gNBs to be able to choose to use delivery mode 2 for multicast sessions.

[0188] Also, since RAN2 has already agreed to allow data reception in RRC connected, it is easy to allow RRC connected UEs to receive MBS configuration. It would be pointless if the UE would have to transition to idle / inactive just to get MCCH. Although it is easy to allow connected UEs to receive MCCH, it may not be optimal in terms of scheduling flexibility (since the UE may need to have "gaps") and / or UE power consumption (since the UE needs to monitor "SC-RNTI" in addition to C-RNTI and G-RNTI). Therefore, whether the UE receives MBS configuration via MCCH or RRC reconfiguration may require further discussion.

[0189] These two challenges remain, but in general there seems to be no technical reason to limit them from our point of view.

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

[0191] Proposal 7: In distribution mode 2, RAN2 should agree that MBS configuration can be received by RRC connected UEs. Whether it is MCCH or RRC reconfiguration needs further study.

[0192] In light of Proposal 6, the control channel design for delivery mode 2 should consider its flexibility and resource efficiency. Otherwise, for example, when delay-tolerant and delay-sensitive services are configured together on one control channel, more signaling overhead may occur because the control channel needs to be scheduled frequently to satisfy the delay requirements from the delay-sensitive service.

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

[0194] Observation 2: The NR MBS control channel for distribution mode 2 needs to be flexible and resource efficient for different types of use cases.

[0195] One possibility is to consider whether it is necessary to separate the configured channels for different use cases, as shown in Figure 19. For example, one MCCH provides frequent delay-sensitive services, and another MCCH provides sparse delay-tolerant services. In LTE SC-PTM, there is a restriction that one cell can have only one SC-MCCH. However, considering that there are more use cases than in LTE, NR MBS distribution mode 2 should remove such restrictions. If multiple MCCHs are allowed in a cell, each MCCH has different scheduling configurations, such as repetition period, that can be optimized for a specific service. How a UE identifies the MCCH that provides the service it is interested in needs further consideration.

[0196] Proposal 8: In distribution mode 2, RAN2 should discuss whether multiple MCCHs are supported in a cell, which was not present in LTE.

[0197] Furthermore, a new paradigm in NR is the support of on-demand SI transmission. This concept can be reused for MCCH in distribution 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 to provide MCCH periodically, i.e., not on-demand, for delay-sensitive services, etc.

[0198] Proposal 9: In delivery mode 2, RAN2 should discuss the option when MCCH is provided on an on-demand basis, which was not present in LTE.

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

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

[0201] (Indication of Interest / Counting) In LTE eMBMS, two methods are specified for the network to collect the UE's receiving / interested services in order to make appropriate decisions on MBMS data delivery including starting / stopping MBMS sessions: MBMS Interest Indication (MII) and MBMS Counting. The MII triggered by the UE contains information related to the interested MBMS frequencies, the interested MBMS services, MBMS priority, and MBMS ROM (receive only mode). The counting response triggered by the network via a counting request for a particular MBMS service contains information related to the interested MBSFN areas and MBMS services.

[0202] These methods were introduced for different purposes: MII is primarily used by the network to ensure that the UE can continue to receive the services it is interested in while in the Connected state, while Counting is used to allow the network to determine whether a sufficient number of UEs are interested in receiving the service.

[0203] Observation 3: In LTE e MBMS, two kinds of UE assistance information are introduced for different purposes: MBMS interest indication is introduced for scheduling in NB, and MBMS counting is introduced for session control in MCE.

[0204] For NR MBS, multicast services such as group communication use cases are expected and the network already has full knowledge of MBS services that UEs in Connected state are receiving / interested in, so assistance information from the UE is not useful for the network, e.g., for PTP / PTM distribution decisions. However, in our understanding, the same is not true for broadcast services and / or UEs in idle / inactive state. Especially for broadcast services, the problem solved by counting with MII in LTE eMBMS, i.e., observation 3, still exists in NR MBS. Therefore, RAN2 needs to consider whether assistance information such as MII and counting can be useful for NR MBS.

[0205] Note that MBMS ROM information in MII and information on MBSFN area in counting response are not required in Rel-17 since ROM and SFN are not supported as described in WID.

[0206] Proposal 11: RAN2 needs to agree to introduce UE assistance information for NR MBS, e.g. MBS Interest Indication and / or MBS Counting.

[0207] If you agree with Proposal 11, it is worth considering an extension on top of LTE eMBMS. In LTE eMBMS, neither MII nor counting can collect information from idle UEs, even if a large proportion of UEs are in RRC idle state and receiving broadcast services. This is, in our understanding, one of the remaining issues for LTE eMBMS from the perspective of session control and resource efficiency.

[0208] In NR MBS, the same problem may exist for idle / inactive UEs. For example, the network does not know if idle / inactive UEs are not receiving / interested in the broadcast service. Thus, the network may continue to provide PTM transmissions even if no UEs are receiving the service. Such unnecessary PTM should be avoided if the gNB is aware of the interest of idle / inactive UEs. Conversely, if PTM stops while there are still idle / inactive UEs receiving the service, many UEs may request a connection at the same time, which is also undesirable.

[0209] It is therefore worth considering whether to introduce mechanisms to collect UE assistance information, specifically for MBMS counting, from idle / inactive UEs. Obviously, it would be desirable for idle / inactive UEs to be able to report information without transitioning to RRC Connected. For example, this could be achieved if PRACH resource partitioning associated to MBS services were introduced for such reporting.

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

Claims

1. A communication control method executed by a user device in a mobile communication system providing a multicast and broadcast service (MBS), comprising: The user equipment in an RRC (Radio Resource Control) connected state receives an RRC Reconfiguration message including an MBS setting required for MBS reception from a base station; The user equipment receives an RRC Release message from the base station, the RRC Release message including information for determining whether the MBS configuration received in the RRC connected state can be continuously used in the RRC inactive state. Communications control method.

2. A user device, A receiving unit that receives an RRC Reconfiguration message including a multicast broadcast service (MBS) setting required for receiving the MBS from a base station when the user equipment is in an RRC (Radio Resource Control) connected state, The receiver receives an RRC Release message from the base station, the RRC Release message including information for determining whether the MBS configuration received in the RRC connected state can be continuously used in the RRC inactive state. User equipment.

3. A chipset for controlling a user equipment, comprising: A process of receiving an RRC Reconfiguration message including a Multicast Broadcast Service (MBS) setting required for receiving MBS from a base station when the user equipment is in an RRC (Radio Resource Control) connected state; receiving, from the base station, an RRC Release message including information for determining whether the MBS configuration received in the RRC connected state can be continuously used in the RRC inactive state; Chipset.

4. A program for controlling a user device, A process of receiving an RRC Reconfiguration message including a Multicast Broadcast Service (MBS) setting required for receiving MBS from a base station when the user equipment is in an RRC (Radio Resource Control) connected state; and receiving, from the base station, an RRC Release message including information for determining whether the MBS configuration received in the RRC connected state can be continuously used in the RRC inactive state. program.

5. A base station, A transmitter that transmits an RRC Reconfiguration message to a user equipment, the RRC Reconfiguration message including a multicast / broadcast service (MBS) setting required for receiving the MBS, when the user equipment is in an RRC (Radio Resource Control) connected state; The transmission unit transmits an RRC Release message to the user equipment, the RRC Release message including information for determining whether the MBS configuration received in the RRC connected state can be continuously used in the RRC inactive state. Base station.

6. A system comprising a user equipment according to claim 2 and a base station according to claim 5.

Images