Communication control method, user equipment, processor, program, and mobile communication system

Abstract

To provide a communication control method and a user device for achieving an improved multicast / broadcast service.SOLUTION: A communication control method used in a mobile communication system that provides a multicast / broadcast service (MBS) from a base station to a user apparatus, the method comprising: identifying, by the user apparatus, a broadcast session that is an MBS session transmitted by broadcast among MBS sessions in which the user apparatus is interested; and transmitting, by the user apparatus, an MBS interest notification including identification information for identifying the identified broadcast session to the base station.SELECTED DRAWING: Figure 10

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 communication control 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 the steps of: the user device identifying a broadcast session that is an MBS session transmitted by broadcast among MBS sessions in which the user device is interested; and the user device transmitting an MBS interest notification to the base station, the MBS interest notification including identification information that identifies the identified broadcast session.

[0005] A communication control method according to a second aspect is a communication control method used in a mobile communication system that provides a multicast broadcast service (MBS) from a base station to user equipment. The communication control method includes the steps of the user equipment performing a predetermined procedure for a multicast session, which is an MBS session transmitted by multicast, with a core network device, and the user equipment transmitting a message to the base station that includes identification information identifying the multicast session for which the predetermined procedure has been completed. The predetermined procedure is a session join procedure or a session leave procedure.

[0006] A communication control method according to a third aspect is a communication control 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: receiving, from the base station, a stop notification indicating that the base station will stop providing an MBS session that the user device has received from the base station; stopping reception of the MBS session in response to receiving the stop notification; and receiving, from the base station, a resume notification indicating that the base station will resume providing the MBS session.

[0007] A user device according to a fourth aspect includes a processor that executes the communication control method according to any one of the first to third aspects. [Brief explanation of the drawings]

[0008] [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. 2 is a diagram illustrating a correspondence relationship between downlink logical channels and transport channels according to an embodiment. [Figure 7] FIG. 1 is a diagram illustrating a method for distributing MBS data according to an embodiment. [Figure 8] FIG. 1 illustrates an MBS session joining procedure according to one embodiment. [Figure 9] FIG. 1 illustrates an MBS session withdrawal procedure according to one embodiment. [Figure 10] FIG. 4 is a diagram illustrating an example of operation according to the first embodiment. [Figure 11] FIG. 10 is a diagram illustrating an example of operation according to Modification 1 of the first embodiment. [Figure 12] FIG. 10 is a diagram illustrating an example of operation according to Modification 2 of the first embodiment. [Figure 13] FIG. 10 is a diagram illustrating an example of operation according to the second embodiment. [Figure 14] FIG. 10 is a diagram illustrating an example of operation according to the third embodiment. [Figure 15] FIG. 1 is a diagram showing an overview of the agreement regarding MBS setting. [Figure 16] FIG. 10 is a diagram showing the configuration of distribution mode 1. [Figure 17] FIG. 10 is a diagram showing the configuration of settings for distribution mode 2. DETAILED DESCRIPTION OF THE INVENTION

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

[0010] Therefore, an object of the present disclosure is to provide a communication control method and a user device that realize an improved multicast / broadcast service.

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

[0012] (Configuration of a mobile communication system) First, the configuration of a mobile communication system according to an embodiment will be described. Fig. 1 is a diagram showing the configuration of a mobile communication system according to an embodiment. This mobile communication system conforms to the 5th Generation System (5GS) of the 3GPP standard. In the following description, 5GS will be taken as an example, but the mobile communication system may also be at least partially applied to an LTE (Long Term Evolution) system. Furthermore, the mobile communication system may also be at least partially applied to a 6th Generation (6G) system.

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

[0014] The UE 100 is a mobile wireless communication device. The UE 100 may be any device that is used by a user, and may be, for example, 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).

[0015] 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"), a measurement control function for mobility control and scheduling, etc. The term "cell" is used to indicate the smallest unit of a wireless communication area. The term "cell" is also used to indicate a function or resource that performs wireless communication with a UE 100. One cell belongs to one carrier frequency.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[0032] The MAC layer performs data priority control, retransmission processing using Hybrid ARQ (HARQ), random access procedures, etc. Data and control information are transmitted between the MAC layer of UE 100 and the MAC layer of gNB 200 via a transport channel. The MAC layer of 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 UE 100.

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

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

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

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

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

[0038] 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 RRC connection between UE100 and gNB200 is suspended, UE100 is in an RRC inactive state.

[0039] The NAS layer, which is positioned 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 300.

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

[0041] (MBS) Next, an MBS according to one embodiment will be described. The MBS is a service that enables broadcast or multicast data transmission, i.e., point-to-multipoint (PTM) data transmission, from the NG-RAN 10 to the UE 100. The MBS may also be called an MBMS (Multimedia Broadcast and Multicast Service). Note that use cases (service types) of the MBS include public safety communications, mission-critical communications, V2X (Vehicle to Everything) communications, IPv4 or IPv6 multicast distribution, IPTV (Internet protocol television), group communications, and software distribution.

[0042] There are two types of MBS transmission methods in LTE: MBSFN (Multicast Broadcast Single Frequency Network) transmission and SC-PTM (Single Cell Point To Multipoint) transmission. Fig. 6 is a diagram showing the correspondence relationship between downlink logical channels and transport channels according to one embodiment.

[0043] As shown in Figure 6, the logical channels used for MBSFN transmission are the MTCH (Multicast Traffic Channel) and the MCCH (Multicast Control Channel), and the transport channel used for MBSFN transmission is the MCH (Multicast Control Channel). MBSFN transmission is designed primarily for multi-cell transmission, and in an MBSFN area consisting of multiple cells, each cell synchronously transmits the same signal (the same data) in the same MBSFN subframe.

[0044] The logical channels used for SC-PTM transmission are the Single Cell Multicast Traffic Channel (SC-MTCH) and the Single Cell Multicast Control Channel (SC-MCCH), and the transport channel used for SC-PTM transmission is the Downlink Shared Channel (DL-SCH). SC-PTM transmission is primarily designed for single-cell transmission, transmitting data by broadcast or multicast on a cell-by-cell basis. The physical channels used for SC-PTM transmission are the Physical Downlink Control Channel (PDCCH) and the Physical Downlink Control Channel (PDSCH), which enable dynamic resource allocation.

[0045] In the following, an example in which an MBS is provided using a method similar to the SC-PTM transmission method will be mainly described, but an MBS may also be provided using the MBSFN transmission method.

[0046] Furthermore, MBS data refers to data provided by an MBS, an MBS control channel refers to an MCCH or SC-MCCH, and an MBS traffic channel refers to an MTCH or SC-MTCH. However, MBS data may also be transmitted via unicast. MBS data may also be referred to as an MBS packet or MBS traffic.

[0047] A network can provide different MBS services for each MBS session. An MBS session is identified by at least one of a Temporary Mobile Group Identity (TMGI) and a session identifier, and at least one of these identifiers is called MBS identification information. Such MBS identification information may also be called an MBS service identifier or a Group-Network Temporary Identifier (G-RNTI).

[0048] MBS sessions include broadcast sessions and multicast sessions.

[0049] A broadcast session is a session for delivering a broadcast service. The broadcast service provides services to all UEs 100 within a specific service area for applications that do not require high-reliability QoS. The broadcast service is available to UEs 100 in all RRC states (RRC idle state, RRC inactive state, and RRC connected state). MBS data belonging to a broadcast session is transmitted by broadcast.

[0050] A multicast session is a session for delivering a multicast service. The multicast service provides a service to a group of UEs 100 participating in the multicast session for applications that require reliable QoS. The multicast service is mainly available to UEs 100 in the RRC connected state. MBS data belonging to the multicast session is transmitted by multicast.

[0051] FIG. 7 is a diagram showing a method for distributing MBS data according to an embodiment.

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

[0053] From the 5GC20 point of view, two delivery methods are possible: Shared MBS Traffic delivery and Individual MBS Traffic delivery.

[0054] In shared MBS data delivery, a connection is established between NG-RAN 10, which is a 5G radio access network (5G RAN), and 5GC 20, and MBS data is delivered from 5GC 20 to NG-RAN 10. Hereinafter, such a connection (tunnel) will be referred to as an "MBS connection."

[0055] The MBS connection may be referred to as a Shared MBS Traffic delivery connection or a shared transport. The MBS connection terminates at the NG-RAN 10 (i.e., the gNB 200).

[0056] gNB200 selects either PTP (Point-to-Point: unicast) or PTM (Point-to-Multipoint: multicast or broadcast) transmission method at its own discretion, and transmits MBS data to UE100 using the selected transmission method.

[0057] On the other hand, in individual MBS data delivery, a unicast session is established between the NG-RAN 10 and the UE 100, and the MBS data is delivered individually from the 5GC 20 to the UE 100. Such a unicast may be called a PDU session. The unicast (PDU session) terminates at the UE 100.

[0058] (MBS session participation procedure) Next, an MBS session participation procedure according to one embodiment will be described.

[0059] The MBS session join procedure is used by the UE 100 to notify the core network of the UE 100's interest in an MBS session. During the MBS session join procedure, the service area (a service area consisting of multiple cells) of the MBS session can be adjusted according to the interest of each UE 100. This allows for dynamic and efficient use of radio resources. The UE 100 needs to perform the MBS session join procedure to receive a multicast session.

[0060] FIG. 8 is a diagram illustrating an MBS session joining procedure according to one embodiment.

[0061] As shown in FIG. 8, in step S11, the UE 100 is in an RRC connected state.

[0062] In step S12, the UE 100 transmits a session join request message to the AMF 300 (core network device). The session join request message includes MBS identification information that identifies the MBS session in which the UE 100 is interested. The session join request message is a NAS message and is transmitted to the AMF 300 via the gNB 200.

[0063] In step S13, the AMF 300 transmits a session join accept message for accepting the session participation to the UE 100. The session join accept message is a NAS message and is transmitted to the UE 100 via the gNB 200.

[0064] The AMF 300 may notify the gNB 200 of MBS identification information that identifies an MBS session that the UE 100 is interested in. This allows the gNB 200 to know the MBS session that the UE 100 is interested in receiving.

[0065] (MBS session withdrawal procedure) Next, an MBS multicast session leaving procedure according to one embodiment will be described.

[0066] The MBS session leave procedure is used by the UE 100 to inform the core network that the UE 100 is no longer interested in an MBS session. The MBS session leave procedure is required for multicast sessions.

[0067] FIG. 9 is a diagram illustrating an MBS session leave procedure according to one embodiment.

[0068] As shown in FIG. 9, in step S21, the UE 100 is in an RRC connected state.

[0069] In step S22, the UE 100 transmits a session leave request message to the AMF 300. The session leave request message includes MBS identification information that identifies the MBS session in which the UE 100 is no longer interested. The session leave request message is a NAS message, and is transmitted to the AMF 300 via the gNB 200.

[0070] In step S23, the AMF 300 transmits a session leave response message to the UE 100. The session leave response message is a NAS message, and is transmitted to the UE 100 via the gNB 200.

[0071] The AMF 300 may notify the gNB 200 of MBS identification information that identifies an MBS session that the UE 100 has lost interest in. This allows the gNB 200 to know the MBS session that the UE 100 has lost interest in.

[0072] (MBS Interest Notification) Next, an MBS interest notification according to one embodiment will be described.

[0073] In order to maintain MBS service continuity, UE 100 transmits an MBS interest notification regarding an MBS session that UE 100 is interested in receiving to gNB 200. When it is necessary to hand over UE 100, gNB 200 hands over UE 100 to another gNB 200 that provides the same MBS session as the MBS session that UE 100 is interested in receiving. This makes it possible to maintain MBS service continuity for UE 100.

[0074] The MBS interest notification may be an MBS interest notification message that UE100 sends voluntarily or an information element included in this message, or it may be an MBS counting response message that UE100 sends in response to a request from gNB200 or an information element included in this message.

[0075] Such a message (MBS interest notification) is, for example, an RRC message, and includes MBS identification information that identifies an MBS session that the UE 100 is interested in. The MBS interest notification may further include at least one of identification information of a QoS flow corresponding to the MBS session and identification information of a frequency on which the MBS session is provided.

[0076] (First embodiment) As described above, AMF300 identifies MBS sessions in which UE100 is interested through the MBS session join procedure. Because the MBS session join procedure is necessary for multicast sessions, AMF300 identifies multicast sessions in which UE100 is interested. Therefore, gNB200 can identify multicast sessions in which UE100 is interested through signaling with AMF300. For this reason, there is little need for UE100 to transmit MBS interest information related to multicast sessions among MBS sessions from UE100 to gNB200. In particular, in a situation where gNB200 has already identified multicast sessions in which UE100 is interested through signaling with AMF300, if UE100 transmits MBS interest information related to multicast sessions to gNB200, there is a risk that radio resources will be wasted unnecessarily.

[0077] The communication control method according to the first embodiment is a method used in a mobile communication system in which a gNB 200 provides a multicast broadcast service (MBS) to a UE 100. The communication control method according to the first embodiment includes a step in which the UE 100 identifies a broadcast session from among MBS sessions in which the UE 100 is interested, and a step in which the UE 100 transmits an MBS interest notification to the base station, the MBS interest notification including identification information for identifying the identified broadcast session. The identification step includes a step in which the UE 100 identifies the broadcast session based on broadcast session identification information received from the gNB 200.

[0078] FIG. 10 is a diagram illustrating an example of operation according to the first embodiment.

[0079] As shown in Figure 10, in step S101, UE100 is in an RRC connected state in the cell of gNB200.

[0080] In step S102, the UE 100 receives MBS system information from the gNB 200 via a Broadcast Control Channel (BCCH). Note that the system information may be referred to as a System Information Block (SIB). The MBS system information may be transmitted at a scheduled period by a predetermined type of SIB (e.g., SIB type 1), or may be transmitted in response to a request from the UE 100 (i.e., on-demand).

[0081] The MBS system information includes scheduling information required for receiving the MBS control channel used in the cell managed by the gNB 200. For example, the MBS system information includes at least one of information indicating a period during which the content of the MBS control channel (MBS control information) may be changed, information indicating the time interval for transmitting the MBS control channel in terms of the number of radio frames, information indicating the offset of the radio frame in which the MBS control channel is scheduled, and information indicating the subframe in which the MBS control channel is scheduled.

[0082] The MBS control channel carries MBS control information. The MBS control information includes a list of scheduling information required for receiving an MBS traffic channel corresponding to an MBS session. The scheduling information includes MBS identification information that identifies the MBS session corresponding to the MBS traffic channel and DRX information (or scheduling information) for the MBS traffic channel. MBS sessions and MBS traffic channels are associated one-to-one. That is, one MBS traffic channel carries MBS data for only one MBS session.

[0083] In the first embodiment, the MBS system information includes broadcast session identification information. The broadcast session identification information is MBS identification information that identifies only broadcast sessions among MBS sessions. In other words, the broadcast session identification information does not identify multicast sessions. The broadcast session identification information may be a list of MBS identification information that identifies each of multiple broadcast sessions.

[0084] The broadcast session identification information included in the MBS system information identifies a broadcast session provided in a cell managed by the gNB 200. The MBS system information may further include broadcast session identification information that identifies a broadcast session provided in a neighboring cell of the cell managed by the gNB 200.

[0085] In step S103, the UE 100 identifies a broadcast session among the MBS sessions in which the UE 100 is interested, based on the broadcast session identification information included in the MBS system information.

[0086] Specifically, UE100 extracts MBS identification information that identifies MBS sessions in which it is interested that matches broadcast session identification information included in the MBS system information, and identifies the MBS session identified by the extracted MBS identification information as the broadcast session.

[0087] In step S104, UE100 transmits an MBS interest notification to gNB200, which includes MBS identification information that identifies the broadcast session identified in step S103.

[0088] The gNB200 may control the handover of the UE100 based on the MBS interest notification.

[0089] In the first embodiment, the broadcast session identification information may be information for identifying a broadcast session or a multicast session. Such information may be information for identifying a broadcast session or a multicast session associated with one or more MBS identification information.

[0090] In the first embodiment, the broadcast session identification information may be information for identifying an MBS session that is permitted (or requires) the transmission of an MBS interest notification. Such information may be information that is associated with one or more pieces of MBS identification information and that is for permitting (or requiring) the transmission of an MBS interest notification. In this case, UE 100 may identify, based on the information, an MBS session that is permitted (or requires) the transmission of an MBS interest notification from among the MBS sessions in which UE 100 is interested, and transmit identification information of the MBS session together with the MBS interest notification.

[0091] In the first embodiment, when the gNB200 can determine whether or not the UE100 is interested in a certain MBS session through signaling with the AMF300, the gNB200 may identify the MBS session as a multicast session. On the other hand, when the gNB200 can determine whether or not the UE100 is interested in a certain MBS session through signaling with the AMF300, the gNB200 may identify the MBS session as a broadcast session. The gNB200 may determine whether or not to transmit broadcast session identification information and / or the content of the transmission, depending on the result of the identification.

[0092] In the first embodiment, the broadcast session identification information may be included in the MBS control information.

[0093] (Modification 1 of the first embodiment) Next, a first modification of the first embodiment will be described, focusing on differences from the first embodiment. In the first modification, the UE 100 identifies a broadcast session based on information received on an MBS control channel for the broadcast session.

[0094] In variant 1 of the first embodiment, MBS control channels are divided into two types: MBS control channels for broadcast sessions (hereinafter referred to as type 1 MBS control channels) and MBS control channels for multicast sessions (hereinafter referred to as type 2 MBS control channels).

[0095] A Type 1 MBS control channel contains scheduling information for MBS traffic channels corresponding to broadcast sessions, but does not contain scheduling information for MBS traffic channels corresponding to multicast sessions.

[0096] The MBS control information carried by the Type 2 MBS control channel includes scheduling information for MBS traffic channels corresponding to multicast sessions only, and does not include scheduling information for MBS traffic channels corresponding to broadcast sessions.

[0097] The MBS system information includes scheduling information for each of the Type 1 MBS control channel and the Type 2 MBS control channel. The MBS system information may also include identifiers (names) for each of the Type 1 MBS control channel and the Type 2 MBS control channel. Such MBS control channel identifiers may include predetermined tags. For example, the Type 1 MBS control channel may be expressed as "MCCH-broadcast," and the Type 2 MBS control channel may be expressed as "MCCH-multicast." Alternatively, abstract MBS control channel identifiers such as "MCCH-A" and "MCCH-B" may be used. In this case, the MBS system information may include information on which MBS control channels are Type 1 and which are Type 2. Alternatively, the MBS system information may include information on which MBS control channels are permitted to transmit MBS interest notifications.

[0098] In the first modification of the first embodiment, the UE 100 recognizes the MBS session identified by the MBS identification information included in the MBS control information received on the type 1 MBS control channel as a broadcast session.

[0099] In a first modification of the first embodiment, the gNB 200 may transmit only a type 1 MBS control channel in its own cell. In this case, the gNB 200 does not transmit a type 2 MBS control channel in its own cell. The UE 100 recognizes an MBS session identified by MBS identification information included in the MBS control information received on the MBS control channel as a broadcast session, regardless of the type. In this case, the scheduling information of the MBS traffic channel corresponding to the multicast session may be notified to the UE 100 by unicast RRC signaling.

[0100] In a first modification of the first embodiment, the Type 1 and Type 2 MBS control channels may be transmitted in association with different logical channel identifiers (LCIDs) and / or radio network temporary identifiers (RNTIs).

[0101] FIG. 11 is a diagram illustrating an example of operation according to the first modification of the first embodiment.

[0102] As shown in FIG. 11, in step S201, UE100 is in an RRC connected state in the cell of gNB200.

[0103] In step S202, UE100 receives MBS system information from gNB200.

[0104] In step S203, the UE 100 receives a type 1 MBS control channel (MBS control channel for a broadcast session) based on the MBS system information.

[0105] Here, the UE 100 recognizes the MBS session identified by the MBS identification information included in the MBS control information received on the Type 1 MBS control channel as a broadcast session (or an MBS session that permits an MBS interest notification).

[0106] In step S204, UE 100 identifies a broadcast session from among the MBS sessions that UE 100 is interested in. Specifically, UE 100 extracts, from the MBS identification information that identifies the MBS sessions that UE 100 is interested in, information that matches MBS identification information included in the MBS control information received on the type 1 MBS control channel, and identifies the MBS session identified by the extracted MBS identification information as the broadcast session.

[0107] In step S205, UE100 transmits an MBS interest notification to gNB200, which includes MBS identification information that identifies the broadcast session identified in step S204.

[0108] (Modification 2 of the first embodiment) Next, a second modification of the first embodiment will be described, focusing on differences from the first embodiment. In the second modification, the RRC layer of the UE 100 identifies a broadcast session based on identification information acquired from the NAS layer. Hereinafter, the NAS layer will be described as an example of an upper layer, but the NAS layer is not limited to the NAS layer and may be an application layer.

[0109] FIG. 12 is a diagram illustrating an example of operation according to the second modification of the first embodiment.

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

[0111] In step S302, the NAS layer of the UE 100 provides identification information to the RRC layer of the UE 100. The identification information identifies a broadcast session identified in the NAS layer. Here, as described above, since an MBS session join procedure is required for a multicast session, the NAS layer can identify an MBS session that does not require an MBS session join procedure (or an MBS session for which an MBS session join procedure has not been performed / completed) as a broadcast session.

[0112] In step S303, the RRC layer of the UE 100 identifies a broadcast session among the MBS sessions that the UE 100 is interested in. Specifically, the RRC layer identifies the MBS session identified by the identification information acquired from the NAS layer in step S302 as a broadcast session (or an MBS session that requires an MBS interest notification).

[0113] In step S304, the RRC layer of UE100 sends an MBS interest notification to gNB200, which includes MBS identification information that identifies the broadcast session.

[0114] In a second modification, the UE 100 may perform an MBS session participation procedure before step S301. In this case, the identification information in step S302 identifies an MBS session for which the MBS session participation procedure has been completed. In step S303, the RRC layer of the UE 100 identifies an MBS session other than the MBS session identified by the identification information in step S302 as a broadcast session.

[0115] (Second embodiment) Next, a second embodiment will be described, focusing mainly on the differences from the above-described embodiment.

[0116] As described above, for the purpose of MBS service continuity, the gNB 200 can identify multicast sessions in which the UE 100 is interested through signaling with the AMF 300. However, there are cases in which the gNB 200 cannot perform signaling with the AMF 300 due to congestion in the AMF 300, etc. For this reason, the gNB 200 cannot identify multicast sessions in which the UE 100 is interested, and there is a risk that the MBS service continuity cannot be maintained.

[0117] The communication control method according to the second embodiment is a method used in a mobile communication system that provides a multicast broadcast service (MBS) from a gNB 200 to a UE 100. The communication control method according to the second embodiment includes a step in which the UE 100 performs a predetermined procedure for a multicast session with an AMF 300, and a step in which the UE 100 transmits to the gNB 200 a message including identification information that identifies the multicast session for which the predetermined procedure has been completed. The predetermined procedure is a session join procedure or a session leave procedure.

[0118] FIG. 13 is a diagram illustrating an example of operation according to the second embodiment.

[0119] 13, in step S401, the UE 100 performs an MBS session participation procedure with the AMF 300. After performing the MBS session participation procedure, the NAS layer of the UE 100 recognizes the MBS session for which the MBS session participation procedure has been completed.

[0120] After the MBS session join procedure is completed, the UE 100 may transition to an RRC inactive state or an RRC idle state.

[0121] In step S402, the UE 100 is in an RRC connected state.

[0122] In step S403, the UE 100 transmits an RRC message including the MBS identifier of the multicast session for which the MBS session join procedure has been completed to the gNB 200. This allows the gNB 200 to know the MBS session in which the UE 100 is interested.

[0123] In the second embodiment, the UE 100 may perform an MBS session detachment procedure in step S401. In this case, in step S403, the UE 100 transmits an RRC message including an MBS identifier of the multicast session for which the MBS session detachment procedure has been completed to the gNB 200. This allows the gNB 200 to know the MBS session in which the UE 100 has lost interest.

[0124] In the second embodiment, the RRC message in step S403 may include, for each MBS identifier, information indicating a participation status for the multicast session identified by the MBS identifier. The information indicating the participation status is information indicating that an MBS session join procedure has been completed or information indicating that an MBS session leave procedure has been completed.

[0125] (Third embodiment) Next, a third embodiment will be described, focusing mainly on the differences from the above-described embodiments.

[0126] For example, the provision of an MBS session may be stopped and then resumed by a decision of the gNB 200. Even though the provision of the MBS session is stopped, scheduling information of the MBS traffic channel corresponding to the MBS session may be continuously transmitted in the MBS control channel. In this case, the UE 100 unnecessarily continues to receive the MBS session between the suspension and resumption of the provision of the MBS session, resulting in unnecessary power consumption.

[0127] The communication control method according to the third embodiment is a method used in a mobile communication system in which a gNB 200 provides a multicast broadcast service (MBS) to a UE 100. The communication control method according to the third embodiment includes the steps of: receiving, by the UE 100, a stop notification from the gNB 200 indicating that the gNB 200 will stop providing the MBS session that the UE 100 has received from the gNB 200; stopping, by the UE 100, reception of the MBS session in response to receiving the stop notification; and receiving, by the UE 100, a resume notification from the gNB 200 indicating that the gNB 200 will resume providing the MBS session.

[0128] FIG. 14 is a diagram illustrating an example of operation according to the third embodiment.

[0129] 14, in step S501, the gNB 200 transmits MBS system information to the UE 100 via a broadcast control channel. The MBS system information includes scheduling information required for receiving the MBS control channel.

[0130] In step S502, the gNB 200 transmits an MBS control channel (MBS control information) using scheduling according to the MBS system information transmitted in step S501. The MBS control information includes scheduling information required for receiving an MBS traffic channel corresponding to the MBS session.

[0131] The UE 100 receives the MBS control channel according to the scheduling in accordance with the MBS system information received in step S501.

[0132] In step S503, the gNB 200 transmits the MBS traffic channel (MBS data) according to the scheduling in accordance with the MBS control information transmitted in step S502. The UE 100 receives the MBS data based on the scheduling in accordance with the MBS control information received in step S502.

[0133] In step S504, the gNB200 determines to stop providing the MBS session. For example, the gNB200 makes such a decision in response to an instruction from the core network.

[0134] In step S505, the gNB 200 transmits a stop notification to the UE 100 via the MBS control channel, indicating that provision of the MBS session will be stopped. At this point, the gNB 200 may continue to transmit the MBS control information transmitted in step S502. The gNB 200 transmits the stop notification for each MBS session. That is, the stop notification is associated with the MBS session. The stop notification for each MBS session may be transmitted in an RRC message.

[0135] In step S506, in response to the reception of the stop notification, the UE 100 stops receiving the MBS session.

[0136] The UE 100 stops receiving the MBS traffic channel even if it has received the MBS control information in step S505.

[0137] The UE 100 stops receiving the MBS traffic channel even when the MBS control information is applied, for example, the UE 100 stops receiving the MBS traffic channel even during the transmission period of the MBS traffic channel scheduled by the applied MBS control information.

[0138] In step S507, the gNB200 determines to resume providing the MBS session. For example, the gNB200 makes such a decision in response to an instruction from the core network.

[0139] In step S508, the gNB 200 transmits a resumption notification to the UE 100 via the MBS control channel, indicating that provision of the MBS session will be resumed. The gNB 200 may transmit new MBS control information together with the resumption notification. For example, if the gNB 200 needs to change the scheduling of the MBS traffic channel in response to the resumption of the MBS session, the gNB 200 transmits the new MBS control information.

[0140] In step S509, UE 100 resumes reception of the MBS session in response to receiving the resume notification. For example, UE 100 resumes reception of the MBS session based on scheduling according to the MBS control information that has already been applied (for example, the MBS control information received in step S502). In step S508, when UE 100 receives new MBS control information, UE 100 resumes reception of the MBS session based on scheduling according to the new MBS control information.

[0141] In the third embodiment, each of the stop notification and the resume notification may be transmitted in an RRC message.

[0142] In the third embodiment, the resumption notification may be included in a Change Notification message, which is a message for notifying the UE 100 that the content of the MBS control channel has changed.

[0143] In the third embodiment, "stop" may be read as "suspend" or "deactivate", and "restart" may be read as "resume" or "activate".

[0144] (Other embodiments) The above-described embodiments and modifications of the embodiments are not limited to being implemented independently, but can also be implemented by combining two or more embodiments.

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

[0146] 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 (System on a chip)).

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

[0148] This application claims priority to U.S. Provisional Application No. 63 / 167234 (filed March 29, 2021), the entire contents of which are incorporated herein by reference.

[0149] (Appendix 1) (introduction) A revised work item on NR Multicast and Broadcast Services (MBS) was approved in RAN#88. RAN2#112-e agreed to introduce two delivery modes for MBS as follows:

[0150] In the case of Rel-17, R2 specifies two modes. · 1: One delivery mode for high QoS (reliability, delay) requirements available in Connected state (currently undetermined if no data is received, the UE may be able to switch to another state). 2: One delivery mode for "low" QoS requirements. The UE can also receive data in inactive / idle state (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.

[0151] ■ No Data: If there is no data ongoing in the multicast session, the UE can stay in RRC Connected state. Other cases require further consideration.

[0152] Regarding distribution mode 2, the following additional agreement was reached on the outline of MBS settings:

[0153] ■The UE receives the MBS configuration (in broadcast / distribution mode 2) via BCCH and / or MCCH (TBD). This can be received in idle / inactive mode. Connected mode requires further consideration (depending on UE capacity, location of service provided, etc.). A notification mechanism is used to notify changes in MBS control information.

[0154] In RAN2#113-e, the details of Delivery Mode 2 were agreed upon as follows: Both idle / inactive UEs and connected mode UEs can receive MBS services transmitted by NR MBS delivery mode 2 (already agreed broadcast services, others to be determined). Whether a connected mode UE can receive this depends on the network provisioning of the service (e.g., on which frequency), the UE connected mode configuration, and the UE capabilities.

[0155] The two-step based approach (BCCH and MCCH) adopted in LTE SC-PTM is reused for transmitting PTM settings for NR MBS distribution mode 2.

[0156] It is assumed that the LTE SC-PTM mechanism of a connected UE can be reused to receive PTM configuration for NR MBS delivery mode 2, i.e., the broadcast-based method.

[0157] It is assumed that the MCCH change notification mechanism is used to notify the change in MCCH configuration due to the start of a session for NR MBS delivery mode 2 (other cases require further consideration).

[0158] It is assumed that MBS interest indication is supported by UEs in connected mode for broadcast services (usually assuming there are no mandatory network requirements and network action is up to the network).

[0159] MBS interest indication is not supported for UEs in idle / inactive mode with NRMBS delivery mode 2.

[0160] For service continuity purposes, we envision some information being provided to NR MBS Delivery Mode 2 (contents requiring further consideration - e.g., reconsideration based on progress of other groups such as USD, SAI / TMGI, etc.).

[0161] Further study is needed to support frequency-based UE recognition of MBS services for service continuity in NR MBS delivery mode 2 (i.e., reusing the LTE SC-PTM mechanism).

[0162] Support for frequency prioritization during cell reselection for service continuity in NR MBS delivery mode 2 requires further study (i.e., reusing the LTE SC-PTM mechanism).

[0163] P2: It is pending whether UEs receiving multicast can be released into RRC inactive / idle state and continue receiving multicast. Further discussion should restrict RRC to inactive. (Appendix 2)

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

[0165] (Discussion) At this point, according to the RAN2 agreement cited in Section 1 and the report of the LS response to SA2, the characteristics of the two delivery modes can be summarized in Figure 15.

[0166] (Distribution mode 1 settings) Delivery mode 1 primarily considers data reception in the RRC connected state, but the details of the configuration have not yet been agreed upon. Considering that delivery mode 1 will be used for high QoS services, it must include, for example, PTP / PTM split bearer and / or lossless handover. Since it is irrelevant whether these UE-specific configurations are provided via the MCCH, it is quite simple to say that RRC reconfiguration must be used to configure delivery mode 1. The LS response to SA2 indeed confirmed that RRC reconfiguration is used for MBS configuration and session start notification.

[0167] Observation 1: For delivery mode 1, RRC reconfiguration is used for MBS configuration and notification by session start.

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

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

[0170] Even if the RRC messages for these delivery modes are different, to achieve the objectives of WID, the IEs and structure of MBS configuration must be aligned as much as possible between the two delivery modes, as pointed out in the discussion of RAN2#112-e. For example, the RRC reconfiguration for delivery mode 1 includes MTCH scheduling information, which is a common block with delivery mode 2, as well as delivery mode 1-specific information such as PTP / PTM split bearer and handover-related information, which requires further discussion at this point.

[0171] Proposal 1: 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] It should be noted that in Figure 16 "MCCH" refers only to MTCH scheduling information, i.e., MTCH configuration related to MBS session information. For distribution mode 1, neighboring cell information is not required.

[0173] However, further study is needed to determine whether a UE can be released to an idle / inactive state 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 still needed. As agreed by RAN2, the baseline assumption is that delivery mode 1 requires the UE to remain RRC connected for multicast sessions, and high QoS is required. However, other / exceptional cases are worth considering.

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

[0175] The above points may be beneficial for both the network and the UE. However, it is understood that whether / when the UE is released to the inactive state is up to the gNB implementation, and whether the UE is released to the idle state is up to the core network. One concern regarding MBS data reception in the idle state is that if the gNB releases the UE context (which is usually only retained in the inactive state, not the idle state), it could mean that the controllability of the gNB may be lost. This may contradict the concept of distribution mode 1. Therefore, the RAN2#113-e agreement states that "Future discussions should limit RRC to the inactive state." Therefore, RAN2 needs to agree that distribution mode 1 can be received by UEs at least in the inactive state.

[0176] Proposal 2: For delivery mode 1, RAN2 must agree that the UE can receive MBS data at least in the RRC inactive state.

[0177] If proposal 2 is acceptable, it is unclear how the idle / inactive MBS configuration is provided to the UE. Three options are possible:

[0178] Option 1: RRC Reconfiguration A UE in idle / inactive state 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 needs to be clarified when transitioning to idle / inactive state and / or returning to RRC Connected state (e.g. how to handle PTP / PTM split bearer configuration, if configured). Option 2: RRC Release The UE in idle / inactive state applies the MBS configuration provided by the RRC release. Although this option seems simple, it may not be efficient, as it is doubtful whether the MBS configuration will be different from the one previously provided by the RRC reconfiguration. Option 3: Switch the delivery mode from Mode 1 to Mode 2 Before the UE is released to the idle / inactive state, it is switched from distribution mode 1 to distribution mode 2. 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, it may be expected that packet loss and delays may occur during the switchover, for example due to MCCH acquisition.

[0179] Each option has its advantages and disadvantages, but in our view, Option 1 is slightly preferable for simplicity and efficiency. RAN2 needs to explain how to provide UEs with delivery mode 1 configuration for data reception in idle / inactive state, including but not limited to the above options.

[0180] Proposal 3: If Proposal 2 is agreed upon, RAN2 needs to discuss how the delivery mode 1 configuration for data reception in inactive state is provided to the UE.

[0181] (Distribution mode 2 settings) In LTE SC-PTM, the configuration is provided by two messages: SIB20 and SC-MCCH. SIB20 provides SC-MCCH scheduling information. SC-MCCH provides SC-MTCH scheduling information including G-RNTI and TMGI, as well as neighbor cell information. It was agreed to reuse the same mechanism for NR MBS.

[0182] NR MBS is expected to support the various types of use cases outlined in the WID. NR MBS must be appropriately designed for a variety of requirements, from delay-sensitive applications such as mission-critical and V2X to delay-tolerant applications such as IoT, in addition to other aspects of the 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.

[0183] This issue was left for further consideration from RAN2#112-e to RAN2#113-e, but in general, from our point of view there seems to be no technical reason to restrict it.

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

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

[0186] Objective A of the SA2 SI concerns the enablement of general MBS services over 5GS, and use cases identified that could benefit from this capability include (but are not limited to) public safety and mission-critical, V2X applications, transparent IPv4 / IPv6 multicast delivery, IPTV, software delivery over wireless, group communications, and IoT applications.

[0187] Observation 2: The control channel for delivery mode 2 needs to be flexible and resource efficient for different types of use cases.

[0188] One possibility is to consider whether the configuration channels need to be separated for different use cases, as shown in Figure 17. For example, one MCCH may provide frequent delay-sensitive services, while another MCCH may provide sparsely delay-tolerant services. LTE SC-PTM has a restriction that only one SC-MCCH can be used per cell. However, considering that NR MBS distribution mode 2 is expected to support more use cases than LTE, this restriction should be removed. If multiple MCCHs are permitted in a cell, each MCCH has different scheduling settings, such as a recurrence period that can be optimized for a specific service. Further consideration is needed to determine how a UE can identify the MCCH that serves a specific service.

[0189] Proposal 5: For distribution mode 2, RAN2 needs to consider whether the cell supports multiple MCCHs, which was not supported in LTE.

[0190] Furthermore, a new paradigm in NR is the support of on-demand SI transmission. This concept can be reused for MCCH in delivery mode 2, i.e., on-demand MCCH. For example, MCCH for delay-tolerant services is provided on-demand, thus optimizing signaling resource consumption. Of course, the network has another option to provide MCCH periodically, i.e., not on-demand, for example, for delay-sensitive services.

[0191] Proposal 6: For delivery mode 2, RAN2 should discuss options if MCCH, which was not available in LTE, is provided on an on-demand basis.

[0192] Another possibility is to further consider merging these messages, i.e., one-step configuration as shown in Figure 17. For example, the SIB provides MTCH scheduling information directly, i.e., without MCCH, providing optimization for delay-tolerant services and power-sensitive UEs. For example, a UE can request an SIB (on-demand), and the gNB can start providing the SIB and corresponding services after requests from multiple UEs. These UEs do not need to monitor the repeatedly broadcast MCCH.

[0193] Proposal 7: For distribution mode 2, RAN2 should discuss options if multicast reception without MCCH is supported (i.e., one-step configuration), e.g., the SIB provides MTCH scheduling information directly.

[0194] It was agreed to introduce MCCH change notification, which is expected to be similar to the notification in LTE SC-PTM. At the very least, the UE will be notified of MCCH changes upon session start.

[0195] According to the latest LTE specifications, "When the network changes (part of) the SC-MCCH information, it notifies BL UEs, UEs in CE, or UEs other than NB-IoT UEs of the change in the first subframe available for SC-MCCH transmission in a recurrence period." This may be interpreted as meaning that SC-MCCH change notification does not need to be limited to a certain extent at the start of a session.

[0196] If MCCH change notification is not provided during an MBS session, the UE must constantly decode the MCCH at every MCCH change boundary to check whether the MCCH has been updated. This is inefficient in terms of UE power consumption compared to decoding only the MCCH change notification. Therefore, MCCH change notification must be provided every time a configuration change occurs, not just at the start of a session.

[0197] Proposal 8: For distribution mode 2, RAN2 needs to discuss whether MCCH change notification is provided every time MCCH information is changed.

[0198] (Interest Indication / Counting) To enable the network to make appropriate decisions regarding MBMS data delivery, including starting and stopping MBMS sessions, LTE eMBMS defines two methods for collecting UEs' receiving / interested services: MBMS Interest Indication (MII) and MBMS Counting. The MII triggered by the UE contains information related to the target MBMS frequency, target MBMS service, 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 target MBSFN area and MBMS service.

[0199] These methods were introduced for different purposes: MII is primarily used by the network to ensure that the UE continues to receive the service of interest while connected, while counting is used to allow the network to determine whether a sufficient number of UEs are interested in receiving the service.

[0200] Observation 3: In LTE eMBMS, two types of UE assistance information are introduced for different purposes: MBMS Interest Indication for scheduling in the eNB, and MBMS Counting for session control in the MCE.

[0201] For NR MBS, we agreed that MBS interest indication is supported in the RRC connected state, but not in the idle / inactive state. Based on this, it is worth considering additional enhancements to LTE eMBMS. In LTE eMBMS, even if the majority of UEs are receiving broadcast services in the RRC idle state, neither MII nor counting can collect information from idle UEs. This is, in our understanding, one of the remaining issues with LTE eMBMS from the perspective of session control and resource efficiency.

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

[0203] It is therefore worth considering whether to introduce mechanisms to collect UE assistance information, especially MBMS counting, from idle / inactive UEs. Needless to say, it would be desirable for these idle / inactive UEs to be able to report information without going RRC connected. This could be achieved, for example, if PRACH resource partitioning associated with MBS services were introduced for such reporting.

[0204] It is important to note that there is no MCE in NR MBS, which means that the MCE functionality is integrated within the gNB. In this sense, it is RAN2 that decides whether counting is required in NRMBS, regardless of what RAN3 decides in terms of the network interface.

[0205] Proposal 9: RAN2 needs to discuss whether MBS counting is implemented and whether it is 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 user device identifies a broadcast session, which is an MBS session transmitted by broadcast, among MBS sessions in which the user device is interested; The user equipment transmits an MBS interest notification to the base station, the MBS interest notification including identification information that identifies the identified broadcast session; receiving, by the user equipment, first configuration information for a broadcast session via an MBS control channel; receiving, by the user equipment, second configuration information for a multicast session, the multicast session being an MBS session transmitted by multicast, via unicast RRC signaling; The identifying step includes identifying the broadcast session based on the first configuration information received on the MBS control channel; the MBS control channel is a control channel for only an MBS traffic channel corresponding to a broadcast session; Identification information for identifying the multicast session in which the user device is interested is notified from a core network device to the base station. Communication control method.

2. 1. A user equipment in communication with a base station providing a multicast and broadcast service (MBS), comprising: a control unit that identifies a broadcast session that is an MBS session transmitted by broadcast among MBS sessions in which the user device is interested; a transmitter configured to transmit an MBS interest notification to the base station, the MBS interest notification including identification information for identifying the specified broadcast session; a receiving unit configured to receive first setting information for a broadcast session via an MBS control channel; The receiving unit receives second configuration information for a multicast session, which is an MBS session transmitted by multicast, via unicast RRC signaling; The control unit identifies the broadcast session based on the first setting information received on the MBS control channel; the MBS control channel is a control channel for only an MBS traffic channel corresponding to a broadcast session; Identification information for identifying the multicast session in which the user device is interested is notified from a core network device to the base station. User equipment.

3. 1. A processor for controlling a user equipment in communication with a base station providing a multicast and broadcast service (MBS), comprising: A process of identifying a broadcast session, which is an MBS session transmitted by broadcast, from among MBS sessions in which the user device is interested; transmitting an MBS interest notification to the base station, the MBS interest notification including identification information for identifying the specified broadcast session; receiving first configuration information for a broadcast session over an MBS control channel; receiving second configuration information for a multicast session, the MBS session being transmitted by multicast, via unicast RRC signaling; the process of identifying the broadcast session includes a process of identifying the broadcast session based on the first setting information received on the MBS control channel; the MBS control channel is a control channel for only an MBS traffic channel corresponding to a broadcast session; Identification information for identifying the multicast session in which the user device is interested is notified from a core network device to the base station. Processor.

4. A user equipment (UE) communicating with a base station (BS) providing a multicast and broadcast service (MBS) includes: A process of identifying a broadcast session, which is an MBS session transmitted by broadcast, from among MBS sessions in which the user device is interested; transmitting an MBS interest notification to the base station, the MBS interest notification including identification information for identifying the specified broadcast session; receiving first configuration information for a broadcast session over an MBS control channel; receiving second configuration information for a multicast session, the MBS session being transmitted by multicast, via unicast RRC signaling; the process of identifying the broadcast session includes a process of identifying the broadcast session based on the first setting information received on the MBS control channel; the MBS control channel is a control channel for only an MBS traffic channel corresponding to a broadcast session; Identification information for identifying the multicast session in which the user device is interested is notified from a core network device to the base station. program.

5. A mobile communication system that provides a multicast broadcast service (MBS) from a base station to a user device, comprising: the user device, The user device Identifying a broadcast session, which is an MBS session transmitted by broadcast, among the MBS sessions in which the user device is interested; transmitting an MBS interest notification to the base station, the MBS interest notification including identification information that identifies the identified broadcast session; receiving first configuration information for a broadcast session via an MBS control channel; receiving second configuration information for a multicast session via unicast RRC signaling, the multicast session being an MBS session; When identifying the broadcast session, the broadcast session is identified based on the first setting information received on the MBS control channel; the MBS control channel is a control channel for only an MBS traffic channel corresponding to a broadcast session; Identification information for identifying the multicast session in which the user device is interested is notified from a core network device to the base station. Mobile communication system.

Images