COMMUNICATION CONTROL METHOD, USER EQUIPMENT, CHIPSET, PROGRAM, AND MOBILE COMMUNICATION SYSTEM

Abstract

An embodiment relates to a communication control method for use in a mobile communication system that provides a multicast / broadcast service (MBS) from a base station to user equipment. The communication control method comprises: the base station transmitting, to the user equipment, switching information for switching delivery modes between a first mode in which an MBS configuration is provided by dedicated signaling, and a second mode in which the MBS configuration is provided by broadcast signaling; and the user equipment, having received the switching information, performing mode switching between the first mode and the second mode, on the basis of the switching information.

Description

[Technical Field]

[0001] The present disclosure relates to a communication control method and a user device used 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 used in a mobile communication system in which a base station provides a multicast broadcast service (MBS) to a user device, the communication control method including: transmitting, to the user device, switching information for switching a delivery mode between a first mode in which an MBS setting is provided by dedicated signaling and a second mode in which the MBS setting is provided by broadcast signaling; and, upon receiving the switching information, the user device switching between the first mode and the second mode based on the switching information.

[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, from a base station, switching information for switching a delivery mode between a first mode in which an MBS setting is provided by dedicated signaling and a second mode in which the MBS setting is provided by broadcast signaling, and a controller that switches between the first mode and the second mode based on the switching information. [Brief explanation of the drawings]

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

[0007] The introduction of multicast and broadcast services into the 5G system (NR) is being considered. The NR multicast and broadcast services are expected to 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 the mobile communication system according to the embodiment will be described.

[0011] 1 is a diagram showing the configuration of a mobile communication system according to an embodiment. This mobile communication system conforms to the 3GPP standard 5th Generation System (5GS). In the following description, 5GS is used as an example, but the mobile communication system may also be at least partially based on 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 used by a user. For example, the UE 100 may be a mobile phone terminal (including a smartphone), a tablet terminal, a laptop 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 a "gNB" in a 5G system) 200. The gNBs 200 are connected to each other via an Xn interface, which is an interface between base stations. The gNB 200 manages one or more cells. The gNB 200 performs wireless communication with a UE 100 that has established a connection with its own cell. The gNB 200 has a radio resource management (RRM) function, a routing function for user data (hereinafter simply referred to as "data"), 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 that performs wireless communication with a UE 100. One cell belongs to one carrier frequency.

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

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

[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 types of reception under the control of the control unit 130. The receiving unit 110 includes an antenna and a receiver. The receiver converts a radio signal received by the antenna into a baseband signal (received signal) and outputs the baseband signal to the control unit 130.

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

[0021] The control unit 130 performs various controls 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 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 processes.

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

[0023] As shown in FIG. 3, the gNB 200 includes a transmitter 210, a receiver 220, a controller 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 types of reception under the control of the control unit 230. The receiving unit 220 includes an antenna and a receiver. The receiver converts a radio signal received by the antenna into a baseband signal (received signal) and outputs the baseband signal to the control unit 230.

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

[0027] The backhaul communication unit 240 is connected to neighboring 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., functionally divided), and both units may be connected 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 Figure 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 and Hybrid Automatic Repeat Request (HARQ). Re The MAC layer of the UE 100 performs retransmission processing using a peat reQuest, 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 allocated to the UE 100.

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

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

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

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

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

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

[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 is for applications that do not require highly reliable QoS, and provides service to all UEs 100 within a specific service area. An MBS session used for the broadcast service is called a broadcast session.

[0043] A multicast service provides services to a group of UEs 100 participating in the multicast service, rather than to all UEs 100. An MBS session used for a multicast service is called a multicast session. A multicast service can provide the same content to a group of UEs 100 in a more radio-efficient manner than a broadcast service.

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

[0045] As shown in Figure 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 the MBS traffic from the application service provider, creates copies of the MBS traffic (replication), and distributes the copies.

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

[0047] 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 a multicast session.

[0048] In the 5GC shared MBS traffic delivery method, first, the 5GC 20 receives a single copy of the MBS data packets and distributes those MBS data Packet To The single copy is distributed to a RAN node (i.e., gNB 200), and secondly, the gNB 200 distributes them to one or more UEs 100.

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

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

[0051] The PTP and PTM distribution methods are mainly related to the user plane. There are two distribution modes for controlling MBS traffic distribution: a first mode and a second mode. Figure 7 is a diagram showing the distribution modes according to one embodiment.

[0052] As shown in Fig. 7, the first mode (Delivery mode 1) is a delivery mode that can be used by UE 100 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 UE 100 in an RRC idle state or an RRC inactive state.

[0053] In one embodiment, the configuration of MBS reception in the first mode is performed by dedicated signaling (also referred to as "unicast signaling"). Specifically, the configuration of MBS reception in the first mode is performed by an RRC Reconfiguration message (or an RRC Release message), which is an RRC message transmitted by unicast from the gNB 200 to the UE 100. The first mode enables advanced MBS traffic delivery using a split MBS bearer, which will be described later.

[0054] The MBS reception configuration includes MBS traffic channel information (hereinafter referred to as "MTCH information") regarding the MBS traffic channel carrying 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 the 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 DL-SCH (Downlink Shared Channel), which is a type of transport channel.

[0056] The second mode (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 RRC inactive state, and is a delivery mode for low QoS requirements. The second mode is used for a broadcast session among MBS sessions. However, the second mode may also be applicable to a multicast session.

[0057] The setting of MBS reception in the second mode is performed by broadcast signaling. Specifically, the setting of MBS reception in the second mode is performed by a logical channel, such as a BCCH (Broadcast Control Channel) or an MCCH (Multicast Control Channel), that is broadcast from the gNB 200 to the UE 100. Hereinafter, such a control channel may be referred to as an 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 a TMGI (Temporary Mobile Group Identity), a session identifier, and a group RNTI (Radio Network Temporary Identifier). At least one of the TMGI and the session identifier is called an MBS session identifier. The TMGI, the session identifier, and the group RNTI are collectively called MBS session information. The MBS session identifier may also be called an MBS service identifier or a 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 improve reliability by using both PTP and PTM 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.

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

[0062] 8 is a diagram showing a split MBS bearer according to one embodiment. Hereinafter, a PTP communication path is referred to as a PTP leg, and a PTM communication path is referred to as a PTM leg. Furthermore, a functional unit corresponding to each layer is referred to as an entity.

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

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

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

[0066] 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 must be set from the gNB 200 to the UE 100, and the PTM leg must 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.

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

[0068] 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., the UE 100 performs blind decoding of the PDCCH using the G-RNTI). The UE 100 may monitor the PDCCH only at a scheduling opportunity for the MBS session.

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

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

[0071] When the PTP leg is deactivated, the UE 100 may monitor the PDCCH to which the 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.

[0072] It is assumed that the split MBS bearer described above is set up by an RRC message (e.g., an RRC Reconfiguration message) sent by the RRC entity of gNB200 to the RRC entity of UE100.

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

[0074] 9 is a diagram showing an example of operation in the first mode according to one embodiment, in which non-essential steps are indicated by dashed lines.

[0075] As shown in Fig. 9, in step S11, the UE 100 in the RRC connected state transmits an MBS Interest Indication (MII) message to the gNB 200. The MII message includes MBS session information related to the desired MBS session of the UE 100 (i.e., the MBS session in which the UE 100 is interested in receiving). The gNB 200 learns the desired MBS session of the UE 100 by receiving the MII message. In this operation pattern, the MII message is a type of RRC message.

[0076] In step S12, the gNB 200 transmits MBS configuration required for receiving the desired MBS session of the UE 100 by dedicated signaling. In one embodiment, the dedicated signaling is an RRC Reconfiguration message. However, the dedicated signaling may also be an RRC Release message.

[0077] In step S13, the UE 100 transmits a response message in response to the dedicated signaling received in step S12 to the gNB 200. The response message is, for example, an RRC Reconfiguration Complete message. The gNB 200 receives the response message.

[0078] In step S14, the gNB 200 transmits (e.g., multicasts) MBS traffic via the MTCH in accordance with the MBS configuration set in step S12. Here, the gNB 200 may perform advanced MBS traffic distribution using a split MBS bearer. The UE 100 receives the MBS traffic.

[0079] Fig. 10 is a diagram illustrating a configuration example of an RRC Reconfiguration message according to an embodiment. As illustrated in Fig. 10, the RRC Reconfiguration message transmitted from the gNB 200 to the UE 100 includes, as an information element, an MBS setting required for MBS reception.

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

[0081] The MTCH information may be a common setting for all RRC states (i.e., RRC connected state, RRC idle state, and RRC inactive state). The MTCH information includes MBS session information (at least one of an MBS session identifier and a group RNTI) and MTCH scheduling information. The MTCH scheduling information includes at least one of an MTCH transmission occasion and a transmission BWP (Bandwidth Part).

[0082] Here, the group RNTI is an RNTI commonly assigned to a group of UEs 100. The transmission occasion is a candidate timing (e.g., subframe) at which the gNB 200 transmits MBS traffic using the MTCH. For example, the transmission occasion may include, as its parameters, an On Duration, an Inactivity Timer, a periodicity (cycle) / offset, and a DRX Retransmission Timer. 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 used to limit the operating bandwidth of the UE 100.

[0083] On the other hand, the RRC Connected dedicated configuration includes settings related to a split MBS bearer, such as bearer configuration for a split MBS bearer, dynamic switching configuration between PTP and PTM, and 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 MTCH information. The RRC Connected dedicated configuration may include HARQ feedback configuration.

[0084] (An example of the second mode) Next, an example of the second mode will be described. Fig. 11 is a diagram showing an example of operation in the second mode according to one embodiment. In the second mode, the UE 100 may be in any of the RRC states of an RRC connected state, an RRC idle state, and an RRC inactive state.

[0085] As shown in Fig. 11, in step S21, the gNB 200 transmits MBS settings required for MBS reception by broadcast signaling. The broadcast signaling is signaling that is periodically transmitted by the BCCH and / or the MCCH. In the following, an example in which the broadcast signaling is signaling that is transmitted by the MCCH will be mainly described. The UE 100 receives the broadcast signaling.

[0086] In step S22, the gNB 200 transmits (for example, broadcasts) MBS traffic via the MTCH in accordance with the MBS configuration set in step S21. The UE 100 receives the MBS traffic.

[0087] FIG. 12 is a diagram showing variations of MBS settings in the second mode according to one embodiment.

[0088] As shown in FIG. 12, the gNB 200 provides the UE 100 with scheduling information for the MCCH through a system information block (SIB) transmitted through the BCCH. The UE 100 receives the MCCH (i.e., MBS configuration) based on the SIB received from the gNB 200, and receives the MTCH (i.e., MBS traffic) based on the received MCCH. This configuration is a two-step configuration (T wo This is sometimes called a 1-step configuration.

[0089] Alternatively, the gNB 200 may provide the MBS configuration to the UE 100 by an SIB. In this case, the UE 100 receives the MTCH (i.e., MBS traffic) based on the SIB received from the gNB 200. Such configuration may be referred to as one-step configuration.

[0090] The gNB 200 may configure multiple MCCHs within one of its own cells. Each MCCH may have a different scheduling (e.g., transmission period). Any of the MCCHs may be provided on demand in response to a request from the UE 100.

[0091] 13 is a diagram illustrating an example of the configuration of a broadcast message according to an embodiment. The broadcast message corresponds to broadcast signaling that provides an MBS configuration.

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

[0093] The MBS configuration in the broadcast message includes one or more MTCH information. Figure 13 shows an example in which the broadcast message includes multiple MTCH information corresponding to multiple MBS sessions (multiple MTCHs).

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

[0095] As described above, under the premise that two delivery modes, the first mode and the second mode, coexist, if UE 100 that receives MBS operates fixedly in one of the delivery modes, the following problem may occur.

[0096] First, consider a scenario in which UE 100 in the RRC connected state receives an MBS in the first mode. In such a scenario, if the load on gNB 200 is high or if there is no ongoing data in the multicast session, UE 100 is transitioned to the RRC idle state or the RRC inactive state. This reduces the load on gNB 200 and the load on UE 100. However, transitioning UE 100 to the RRC idle state or the RRC inactive state may cause UE 100 to be unable to continue receiving the MBS.

[0097] Second, consider a scenario in which the UE 100 in the RRC idle state or the RRC inactive state receives MBS data in the second mode. In such a scenario, if the load on the gNB 200 is low, the UE 100 can transition to the RRC connected state and switch to the first mode, enabling advanced MBS traffic delivery using, for example, a split MBS bearer.

[0098] In operation according to one embodiment, mode switching between the first mode and the second mode is enabled by control of the gNB 200. Figure 14 is a diagram illustrating operation according to one embodiment.

[0099] 14, in step S1, the UE 100 operating in the first mode or the second mode receives MBS traffic via an MTCH from the gNB 200. The first mode is a distribution mode in which MBS configuration is provided by dedicated signaling, and the second mode is a distribution mode in which MBS configuration is provided by broadcast signaling.

[0100] In step S2, the gNB 200 transmits switching information for switching the distribution mode between the first mode and the second mode to the UE 100. The switching information may be transmitted by dedicated signaling (e.g., an RRC Reconfiguration message) and / or broadcast signaling (e.g., an SIB, an MCCH, or paging). The UE 100 receives the switching information.

[0101] In step S3, the UE 100 performs mode switching between the first mode and the second mode based on switching information from the gNB 200. Specifically, the UE 100 performs mode switching 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, the UE 100 performs mode switching from the first mode to the second mode based on switching information for switching the distribution mode from the second mode to the first mode. 2 Mode to 1 Switches between modes.

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

[0103] In this way, by switching between the first mode and the second mode under the control of the gNB 200, it becomes possible to appropriately use the first mode and the second mode. Furthermore, even if the mode is switched, it is possible to make it easier for the UE 100 to continue receiving MBS.

[0104] (First operation example) Next, a first operation example according to one embodiment will be described. In the following operation example, mode switching from the first mode to the second mode will be mainly described.

[0105] In this operation example, the gNB200 switches the UE100, which is performing PTM reception in the first mode in the RRC connected state, from the first mode to the second mode before transitioning the UE100 to the RRC idle state or the RRC inactive state. For example, the gNB200 transitions the UE100, starting with the UE100 that has been able to start MBS reception in the second mode, to the RRC idle state or the RRC inactive state in sequence. This allows the UE100 to continue receiving MBSs, while reducing the load on the gNB200 and the UE100.

[0106] Specifically, the gNB 200 transmits switching information for switching to the second mode to the UE 100 operating in the first mode in the RRC connected state. The UE 100 switches from the first mode to the second mode based on the switching information received from the gNB 200.

[0107] After switching from the first mode to the second mode, the UE 100 transitions to an RRC idle state or an RRC inactive state. Then, in the RRC idle state or the RRC inactive state, the UE 100 receives MBS traffic from the gNB 200 using the MBS configuration provided by the broadcast signaling.

[0108] In this operation example, UE 100 may transmit a notification to gNB 200 based on switching from the first mode to the second mode. In response to receiving the notification from UE 100, gNB 200 transitions UE 100 to an RRC idle state or an RRC inactive state. As a result, after gNB 200 confirms that UE 100 can continue receiving MBS, UE 100 can transition to the RRC idle state or the RRC inactive state.

[0109] 15 is a diagram showing a first operation example according to one embodiment, in which non-essential steps are indicated by dashed lines.

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

[0111] In step S102, the gNB 200 and the UE 100 operate in the first mode as described above (see FIG. 9). For example, the UE 100 receives an MBS configuration transmitted from the gNB 200 by dedicated signaling, and receives MBS traffic (MTCH) transmitted from the gNB 200 by PTM using this MBS configuration.

[0112] In step S103, the gNB 200 determines the UE 100 to transition to the RRC idle state or the RRC inactive state, taking into consideration its own load (for example, radio resource usage rate and / or hardware resource usage rate). Here, the description will proceed assuming that the load of the gNB 200 is increasing.

[0113] Here, the gNB 200 may determine a UE 100 that has not had uplink transmission for a certain period of time as a UE 100 to transition to an RRC idle state or an RRC inactive state. The gNB 200 may determine a UE 100 that is interested in an MBS session that has not had downlink transmission for a certain period of time, or a UE 100 that is receiving the MBS traffic (or is participating in the multicast group) as a UE 100 to transition to an RRC idle state or an RRC inactive state. The gNB 200 may determine all UEs 100 that are receiving an MBS session as UEs 100 to transition to an RRC idle state or an RRC inactive state.

[0114] In step S104, the gNB 200 starts transmission in the second mode. Specifically, the gNB 200 starts transmission of second-mode broadcast signaling and / or transmission of second-mode MBS traffic (MTCH). Note that step S104 may be performed after step S105.

[0115] In step S105, an instruction to switch the reception mode to the second mode is transmitted as switching information to the UE 100 determined in step S103. The instruction to switch the reception mode to the second mode includes at least one of the following information.

[0116] MBS session identifier, group RNTI, MBS bearer ID, and / or PTM LCID (Logical Channel ID) of the reception mode switching target (currently receiving MBS session) Group RNTI, MBS bearer ID, and / or PTM LCID after switching the receive mode (MBS session to be received) Timing information indicating the timing of switching the reception mode. This timing information may be expressed as absolute time (such as SFN) and / or relative time (such as timer value).

[0117] In step S106, the UE 100 starts preparation for second mode reception in response to the switching instruction received from the gNB 200. For example, the UE 100 attempts to receive broadcast signaling (SIB and / or MCCH) and MTCH. If the UE 100 has received a timer value in step S105, the UE 100 starts the timer.

[0118] In step S107, UE100 notifies gNB200 of completion of reception preparation in association with second mode reception. UE100 may transmit a notification to gNB200 upon completion of reception of SIB and / or MCCH. UE100 may transmit a notification to gNB200 upon completion of reception of MTCH. This notification may be an RRC message and / or a MAC CE (Control Element). UE100 may transmit, as such a notification, RAI (Release Assistance Information), which is an RRC message for prompting gNB200 to transition to an RRC idle state or an RRC inactive state, to gNB200. UE100 may include information indicating completion of second mode reception preparation in the RAI.

[0119] In step S108, the gNB 200 transmits an RRC Release message to the UE 100 that has completed preparation for reception, based on the notification from the UE 100. As a result, the gNB 200 transitions the UE 100 to an RRC idle state or an RRC inactive state. When transitioning the UE 100 to the RRC inactive state, the gNB 200 transmits an RRC Release message including Suspend Config as an information element. The UE 100 may discard or disable the RRC Connected dedicated configuration configured by the dedicated signaling.

[0120] In step S109, in response to the reception of the RRC Release message, the UE 100 transitions to an RRC idle state or an RRC inactive state.

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

[0122] In step S106, it is also assumed that UE 100 is unable to start second mode reception within the period until the reception mode switching occurrence timing. 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, UE 100 may transmit a notification of failure in reception preparation to gNB 200. When gNB 200 receives a notification of failure in reception preparation from UE 100, it may maintain UE 100 in the RRC connected state.

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

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

[0125] Here, UE 100 can detect packet loss based on discontinuity of packet sequence numbers, for example, in the PDCP layer. However, UE 100 cannot detect packet loss if the PDCP entity for the second mode is a different PDCP entity from the PDCP entity for the first mode (i.e., a newly established PDCP entity). UE 100 cannot detect packet loss even when the PDCP entity is re-established. In addition, there is a risk that the PDCP entity will not be able to continue packet header compression / decompression processing (e.g., RoHC (Robust Header Compression)) and / or security processing.

[0126] Therefore, the UE 100 according to this operation example performs reception processing of the MBS traffic in the second mode by continuously using the PDCP entity used for reception processing of the MBS traffic in the first mode, thereby solving the above-mentioned problem.

[0127] Fig. 16 is a diagram showing a second operation example according to an embodiment. Specifically, Fig. 16 shows the operation of the UE 100 regarding MBS traffic reception.

[0128] As shown in Fig. 16, in step S201, UE 100 receives MBS traffic transmitted in PTM from gNB 200 in the first mode (Delivery mode 1). This MBS traffic belongs to a specific MBS session. In UE 100, a PHY entity, a MAC entity, an RLC entity, and a PDCP entity process the MBS traffic in the first mode. Here, the PDCP entity detects packet loss based on a sequence number included in the header of a packet of MBS traffic (PDCP packet), and also performs header recovery processing using RoHC.

[0129] The gNB200 assigns the same PDCP sequence number to the MBS traffic of the MBS session (specific MBS session) for which the reception mode is to be switched in the first mode and the second mode and transmits the MBS traffic.

[0130] In step S202, when switching the reception mode (for example, when receiving a switching instruction), UE 100 relocates the PDCP entity in the first mode to the second mode. Specifically, UE 100 relocates the PDCP entity that was located as an upper layer of the RLC entity in the first mode to the upper layer of the RLC entity in the second mode. UE 100 may perform the relocation by changing the association between the PDCP entity and the RLC entity (LCID). As a result, the PDCP context information (PDCP sequence number, RoHC context) of the first mode is carried over to the second mode.

[0131] In step S203, UE 100 receives MBS traffic transmitted in PTM from gNB 200 in the second mode (Delivery mode 2). That is, UE 100 continues receiving data for the specific MBS session in the second mode. In UE 100, 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 header recovery processing using RoHC, using PDCP context information inherited from the first mode.

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

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

[0134] In this operation example, the gNB 200 sets a bearer (i.e., a split bearer) that is divided into a first communication path for the first mode (hereinafter referred to as a "leg for the first mode") and a second communication path for the second mode (hereinafter referred to as a "leg for the second mode") for the UE 100. When switching from the first mode to the second mode, the UE 100 switches from the leg for the first mode to the leg for the second mode while maintaining the PDCP entity.

[0135] Fig. 17 is a diagram showing a third operation example according to one embodiment. Specifically, Fig. 17 shows the operation of UE 100 regarding MBS traffic reception. Here, differences from the above-mentioned second operation example will be mainly described.

[0136] 17, in step S301, the UE 100 receives MBS traffic transmitted by PTM from the gNB 200 in the first mode leg. This MBS traffic belongs to a specific MBS session. In the UE 100, a PHY entity, a MAC entity, an RLC entity, and a PDCP entity process the MBS traffic of the first mode leg.

[0137] The gNB200 assigns the same PDCP sequence number to the MBS traffic of the MBS session (specific MBS session) for which the reception mode is to be switched, and transmits the MBS traffic in the first mode leg and the second mode leg.

[0138] In step S302, when switching the reception mode (for example, when receiving a switching instruction), the UE 100 changes the PDCP entity for the first mode so that it is associated with the leg for the second mode (RLC entity, LCID). As a result, the PDCP context information (PDCP sequence number, RoHC context) for the first mode is carried over to the second mode.

[0139] In step S303, UE 100 receives MBS traffic transmitted by PTM from gNB 200 on the leg for the second mode. That is, UE 100 continues receiving data of the specific MBS session in the second mode. The PDCP entity continues packet loss detection processing and header recovery processing by RoHC using the PDCP context information inherited from the first mode. Note that UE 100 may release (delete) the leg for the first mode after switching to the second mode, for example, at the time of receiving an RRC Release message.

[0140] (Fourth operation example) Next, a fourth operation example according to one embodiment will be described, focusing mainly on the differences from the above-described operation examples.

[0141] In the above-described operation example, it is assumed that the MTCH scheduling for the first mode and the MTCH scheduling for the second mode are different for one MBS session. However, by making the MTCH scheduling for the first mode and the second mode the same for the MBS session, mode switching for this MBS session can be facilitated. Furthermore, by making the group RNTI for the first mode and the group RNTI for the second mode the same for the MBS session, mode switching for this MBS session can be facilitated.

[0142] In this operation example, the gNB 200 transmits MTCH scheduling information, which is scheduling information for an MBS traffic channel, by dedicated signaling (i.e., signaling in the first mode). This MTCH scheduling information is associated with one MBS session. Furthermore, the gNB 200 transmits MTCH scheduling information, which is the same as the MTCH scheduling information in the first mode, for this MBS session by broadcast signaling (i.e., signaling in the second mode).

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

[0144] 18 is a diagram showing a fourth operation example according to one embodiment. Here, differences from the first operation example described above will be mainly described. In FIG. 18, non-essential steps are indicated by dashed lines.

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

[0146] In step S402, the gNB 200 and the UE 100 operate in the first mode as described above (see FIG. 9). For example, the UE 100 receives an MBS configuration (MTCH information) transmitted by dedicated signaling from the gNB 200, and receives MBS traffic (MTCH) transmitted by PTM from the gNB 200 using this MTCH information. This MBS traffic belongs to a specific MBS session.

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

[0148] In step S404, the gNB 200 starts transmission in the second mode for the specific MBS session. Specifically, the gNB 200 starts broadcast signaling in the second mode. Send Step S404 may be performed after step S405. Here, the gNB200 transmits, by broadcast signaling, the same MTCH information as the MTCH information transmitted by broadcast signaling in the first mode.

[0149] In step S405, the gNB 200 may transmit the above-mentioned reception mode switching instruction as switching information to the UE 100 determined in step S403. The gNB 200 may transmit to the UE 100 switching information including information indicating that the MTCH scheduling information (MTCH information) is the same, for example, information such as "Same MTCH info{true}". The gNB 200 may transmit to the UE 100 switching information including a notification indicating that the specific MBS session can also be received in the second mode. The gNB 200 may transmit such switching information by broadcast signaling (SIB, etc.).

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

[0151] As in the first operation example described above, the gNB 200 may transition the UE 100 from the RRC connected state to the RRC idle state or the RRC inactive state based on a notification from the UE 100. Here, the UE 100 may transmit a notification (e.g., an RAI) even if the UE 100 is receiving or interested in receiving the specific MBS session in a case where there is no unicast data communication, etc. The gNB 200 may determine that the transition to the second mode is complete when there is no UE 100 receiving the specific MBS session in the first mode.

[0152] (5th operation example) Next, a fifth operation example according to one embodiment will be described, focusing mainly on the differences from the above operation examples.

[0153] As described above, the gNB 200 switches from the first mode to the second mode for a particular MBS session due to its own load, and such a switch to the second mode may be temporary and limited to periods of high load on the gNB 200.

[0154] The specific MBS session switched to the second mode is an MBS session to which the first mode should originally be applied, and therefore it is not preferable for the UE 100, which is originally in the RRC idle state or the RRC inactive state, to start receiving the specific MBS session.

[0155] In this operation example, after switching from the first mode to the second mode, the gNB 200 transmits broadcast signaling (e.g., MCCH or SIB) including MBS session information indicating the MBS session switched from the first mode to the second mode. This allows the UE 100, which was originally in the RRC idle state or the RRC inactive state, to know the MBS session switched to the second mode based on the broadcast signaling. This allows the UE 100 to avoid, for example, starting reception of the MBS session switched to the second mode.

[0156] In this operation example, after switching from the first mode to the second mode, for example, when the gNB 200's own load becomes smaller, the gNB 200 transmits broadcast signaling including MBS session information indicating the MBS session to be switched from the second mode to the first mode. This allows the UE 100 that has switched to the second mode to perform an operation to return to the first mode.

[0157] FIG. 19 is a diagram illustrating a fifth operation example according to an embodiment.

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

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

[0160] In step S503, the gNB200 and the UE100a operate in the first mode as described above for a particular MBS session.

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

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

[0163] In step S506, the gNB 200 transmits, via broadcast signaling (e.g., MCCH) for the second mode, information indicating that the specific MBS session is an MBS session switched from the first mode. The UE 100a and the UE 100b receive this broadcast signaling. Such notification includes MBS session information for the specific MBS session. The notification may be a notification that the specific MBS session will be excluded from the second mode after the UE 100a returns to the RRC connected state.

[0164] In step S507, the UE 100a continues to receive the MBS in the RRC idle state / RRC inactive state.

[0165] On the other hand, even if the UE 100b is interested in receiving the specific MBS session, the UE 100b determines, based on the broadcast signaling in step S506, that it cannot receive the specific MBS session in the RRC idle state / RRC inactive state. In order to receive the specific MBS session, the UE 100b needs to transition to the RRC connected state and obtain an MBS configuration from the gNB 200 through dedicated signaling.

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

[0167] Then, in step S508, the gNB200 determines to switch from the second mode to the first mode for the particular MBS session. For example, the gNB200 determines to switch when its own load becomes smaller.

[0168] In step S509, the gNB 200 transmits switching information for switching from the second mode to the first mode for the specific MBS session. This switching information includes MBS session information for the specific MBS session. This switching information may be transmitted in broadcast signaling (SIB, MCCH, or paging message), MTCH, and / or MAC CE. The UE 100a and the UE 100b receive the switching information from the gNB 200.

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

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

[0171] (Other embodiments) In the above-described operation example, an example of switching from the first PTM mode to the second PTM mode has been mainly described. However, switching from the first PTP mode to the second PTM mode may also be performed. The first mode is primarily intended for the RRC connected state, and the selection of either PTP or PTM depends on the implementation of the gNB200. Therefore, switching from the first PTP mode to the second PTM mode may also be performed. In this case, the UE100 receives MBS traffic transmitted from the gNB200 in PTP in the first mode, and receives MBS traffic transmitted from the gNB200 in PTM in the second mode. Switching from the first mode to the second mode includes switching from PTP to PTM.

[0172] The above-described operation examples are not limited to being carried out independently, and some steps of two or more operation examples can be combined and carried out.

[0173] In the above-described 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). Also, 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.

[0174] 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 on a computer-readable medium. Using the computer-readable medium, the program can be installed on a computer. Here, the computer-readable medium on which the program is recorded may be a non-transitory recording medium. The non-transitory recording medium is not particularly limited, and may be, for example, a recording medium such as a CD-ROM or a DVD-ROM.

[0175] 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 (chipset, SoC).

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

[0177] This application claims priority to U.S. Provisional Application No. 63 / 136,946 (filed January 13, 2021), the entire contents of which are incorporated herein by reference.

[0178] (Addendum) (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:

[0179] 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 that (as in R17) 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 data ongoing in the multicast session, the UE may remain in RRC Connected. Other cases require further consideration.

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

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

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

[0183] (Discussion) As agreed upon by RAN2, the two delivery modes at this time are summarized in Table 1.

[0184] [Table 1]

[0185] (Distribution mode 1 setting) Delivery mode 1 is primarily being considered for data reception in RRC Connected, but configuration aspects have not yet been agreed upon. While it may be quite straightforward for MBS configuration to be provided by RRC reconfiguration, receiving MCCH in Connected, like LTE eMBMS, is still under consideration. Given the high QoS expected for delivery mode 1, it should involve, for example, PTP / PTM split bearers and / or lossless handover. Since these UE-specific configurations are meaningless if provided via MCCH, in our view, RRC reconfiguration should be used to configure delivery mode 1.

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

[0187] 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 on separate delivery modes for multicast and broadcast sessions.

[0188] 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 the RRC Idle / Inactive state.

[0189] Even though the RRC messages for these delivery modes are different, to achieve the objective of WID, the structure and IEs of the 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.

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

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

[0192] Further study is needed to determine whether a UE can be released to idle / inactive status when there is no ongoing data for a multicast session. In other words, whether an idle / inactive UE can receive MBS data via delivery mode 1 is also needed. As agreed by RAN2, the baseline is that a UE should be kept in delivery 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 due to congestion, the network may not be able to keep all UEs connected. Other companies also pointed out that UEs do not need to stay connected all the time due to uplink activity, QoS requirements, and / or UE power consumption.

[0194] From the RAN2 perspective, it may be considered beneficial for both the network and the UE to support this feature. It is assumed that whether / when the UE is released to inactive mode is up to the gNB implementation, and whether the UE is released to idle mode is up to the core network. One concern regarding MBS data reception in idle mode is that the gNB releases the UE context, while the UE context is retained in inactive mode. 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 inactive mode, but further consideration is needed in idle mode.

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

[0196] If proposal 3 is acceptable, it is not clear how the idle / inactive MBS configuration is provided to the UE. Three options are possible:

[0197] Option 1: RRC reconfiguration An idle / inactive UE continues to apply the MBS configuration provided by RRC reconfiguration. This option is simple as the UE simply 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 resuming RRC Connected, e.g., how to handle PTP / PTM split bearer configuration if configured.

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

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

[0200] Each option has its advantages and disadvantages, but in our view, Option 1 is slightly 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 delivery mode 1 configuration for data reception in idle / inactive mode.

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

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

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

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

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

[0206] In addition to Proposal 5, NR MBS is envisioned to support the various types of use cases described in WID. It is noted that NR MBS should be appropriately designed for various 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 other services with "high QoS requirements" require Delivery Mode 1. In this sense, it would be beneficial for gNBs to have the option to use Delivery Mode 2 for multicast sessions.

[0207] 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 had to transition to idle / inactive just to acquire MCCH. While 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 "gap") 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.

[0208] These two challenges remain, but in general, from our perspective there seems to be no technical reason to limit them.

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

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

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

[0212] Objective A of 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.

[0213] Observation 2: The NR MBS control channel for distribution mode 2 needs to be flexible and resource efficient for different 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 delay-sensitive services, while another MCCH may sparsely provide delay-tolerant services. In LTE SC-PTM, a cell is limited to having only one SC-MCCH. However, considering that more use cases than LTE are expected, NR MBS distribution mode 2 should remove this limitation. If multiple MCCHs are permitted in a cell, each MCCH has different scheduling settings, such as a recurrence period, that can be optimized for specific services. Further consideration is needed to determine how a UE identifies the MCCH that provides the service of interest.

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

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

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

[0218] Another possibility that may be further considered is merging these messages, i.e., one-stage configuration, as shown in Figure 12. For example, the SIB provides MTCH scheduling information directly, i.e., without the MCCH. This would provide optimization for delay-tolerant services and / or power-sensitive UEs. For example, a UE may request the 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.

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

[0220] (Indication of Interest / Counting) LTE eMBMS specifies two methods for collecting UE's receiving / interested services, i.e., MBMS Interest Indication (MII) and MBMS Counting, to allow the network to make appropriate decisions on MBMS data delivery, including starting / stopping MBMS sessions. The MII triggered by the UE contains information related to the interested MBMS frequencies, interested MBMS services, MBMS priority, and MBMS ROM (Receive Only Mode). The Counting Response triggered by the network via a Counting Request for a specific MBMS service contains information related to the interested MBSFN area and MBMS service.

[0221] 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 if a sufficient number of UEs are interested in receiving the service.

[0222] 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 the NB, and MBMS Counting is introduced for session control in the MCE.

[0223] For NR MBS, multicast services such as group communication use cases are expected, and the network already has complete knowledge of the MBS services that UEs in the Connected state are receiving / interested in. Therefore, assistance information from the UE, for example, for determining PTP / PTM distribution, is not useful to the network. However, as we understand it, the same does not apply to broadcast services and / or UEs in the 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.

[0224] Note that Rel-17 does not require MBMS ROM information in MII and information about MBSFN area in Counting Response, since ROM and SFN are not supported as described in WID.

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

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

[0227] In NR MBS, the same problem can exist for idle / inactive UEs. For example, the network does not know whether idle / inactive UEs are not receiving / interested in the broadcast service. Therefore, the network may continue to provide PTM transmissions even if no UEs are receiving the service. If the gNB is aware of the interest of idle / inactive UEs, such unnecessary PTM should be avoided. Conversely, if PTM is stopped while there are still idle / inactive UEs receiving the service, many UEs may request a connection at the same time, 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. Obviously, it would be desirable for idle / inactive UEs to be able to report information without transitioning to RRC Connected. This could be achieved, for example, if PRACH resource partitioning associated with MBS services were introduced for such reporting.

[0229] 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 used in a mobile communication system that provides a multicast broadcast service (MBS) from a base station to a user device, comprising: The base station transmits, to the user equipment, switching information for switching a distribution mode between a first mode in which a multicast session is provided based on an MBS configuration provided by dedicated signaling and a second mode in which a multicast session is provided based on an MBS configuration provided by multicast signaling; and the user equipment receiving the switching information switches between the first mode and the second mode based on the switching information; the base station transmitting scheduling information for an MBS traffic channel via the dedicated signaling; The base station further transmits the same scheduling information as the scheduling information by the multicast signaling. Communication control method.

2. The performing of the mode switching includes, when the user equipment receives the switching information, receiving, by multicast signaling, the scheduling information that is the same as the scheduling information received by the dedicated signaling. The communication control method according to claim 1 .

3. A user equipment for use in a mobile communication system providing a multicast broadcast service (MBS), comprising: a receiving unit that receives, from a base station, switching information for switching a distribution mode between a first mode in which a multicast session is provided based on an MBS configuration provided by dedicated signaling and a second mode in which a multicast session is provided based on an MBS configuration provided by multicast signaling; a control unit that switches a distribution mode between the first mode and the second mode based on the switching information, the receiving unit receives scheduling information for an MBS traffic channel from the base station by the dedicated signaling; The receiving unit receives, from the base station, scheduling information that is the same as the scheduling information transmitted by the multicast signaling. User equipment.

4. 1. A chipset for a user equipment for use in a mobile communication system providing a multicast broadcast service (MBS), comprising: receiving switching information from a base station for switching a distribution mode between a first mode in which a multicast session is provided based on an MBS configuration provided by dedicated signaling and a second mode in which a multicast session is provided based on an MBS configuration provided by multicast signaling; a process of switching the distribution mode between the first mode and the second mode based on the switching information; receiving scheduling information for an MBS traffic channel from the base station via the dedicated signaling; receiving, from the base station, scheduling information that is the same as the scheduling information transmitted by the multicast signaling; Chipset.

5. A user device for use in a mobile communication system providing a multicast broadcast service (MBS), receiving switching information from a base station for switching a distribution mode between a first mode in which a multicast session is provided based on an MBS configuration provided by dedicated signaling and a second mode in which a multicast session is provided based on an MBS configuration provided by multicast signaling; a process of switching the distribution mode between the first mode and the second mode based on the switching information; receiving scheduling information for an MBS traffic channel from the base station via the dedicated signaling; receiving, from the base station, scheduling information that is the same as the scheduling information transmitted by the multicast signaling. program.

6. A mobile communication system providing a multicast broadcast service (MBS), comprising: a user equipment and a base station; The user device a receiving unit that receives, from the base station, switching information for switching a distribution mode between a first mode in which a multicast session is provided based on an MBS configuration provided by dedicated signaling and a second mode in which a multicast session is provided based on an MBS configuration provided by multicast signaling; a control unit that switches a distribution mode between the first mode and the second mode based on the switching information, the receiving unit receives scheduling information for an MBS traffic channel from the base station by the dedicated signaling; the receiving unit receives, from the base station, scheduling information that is the same as the scheduling information transmitted by the multicast signaling; The base station a transmitter that transmits the switching information to the user device; the transmitting unit transmits scheduling information of an MBS traffic channel to the user equipment by the dedicated signaling; The transmitting unit transmits the same scheduling information as the scheduling information by the multicast signaling to the user equipment. Mobile communication system.

Images