Communication control method, user device, and processor

Abstract

A communication control method according to a first aspect of the present invention is executed by a user device in a mobile communication system that provides a multicast service to the user device from a network. The communication control method comprises: performing processing for monitoring, in a radio resource control (RRC) idle state or an RRC inactive state, a group notification that indicates the activation of a multicast session in which the user device is participating and that is sent from the network to a group to which the user device belongs; performing processing for transitioning, in response to reception of the group notification, to an RRC connected state in order to receive the multicast session; and performing control such that the processing for monitoring or the processing for transitioning is not performed if there is no longer interest in the multicast session in the RRC idle state or the RRC inactive state. The processing for monitoring includes monitoring of the group notification when the user device has interest in the multicast session. The processing for transitioning includes transitioning to the RRC connected state in response to receiving the group notification when the user device has interest in the multicast session.

Description

Technical Field

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

Background Art

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

Prior Art Documents

Non-Patent Documents

[0003]

Non-Patent Document 1

Summary of the Invention

[0004] A communication control method according to the first embodiment is a communication control method performed by a user device in a mobile communication system that provides multicast services from a network to the user device, comprising: performing a process to monitor a group notification, which is a notification indicating the activation of a multicast session in which the user device is participating and is transmitted from the network to a group to which the user device belongs, in an RRC idle state or an RRC inactive state; performing a process to transition to an RRC connected state for receiving the multicast session in response to the receipt of the group notification; and controlling the monitoring process or the transition process not to be performed when the user device loses interest in the multicast session in the RRC idle state or the RRC inactive state, wherein performing the monitoring process includes monitoring the group notification when the user device is interested in the multicast session, and performing the transition process includes transitioning to the RRC connected state in response to the receipt of the group notification when the user device is interested in the multicast session.

[0005] A communication control method according to a second embodiment is a communication control method to be performed in a mobile communication system that provides multicast services from a network to a user device, wherein the user device manages a COUNT value as a PDCP (Packet Data Convergence Protocol) variable, and this management includes obtaining a PDCP SN (Sequence Number) included in the header of the first PDCP packet received by multicast from the network, and using the obtained PDCP SN as part of the COUNT value.

[0006] A third aspect of the communication control method is a communication control method to be performed in a mobile communication system that provides multicast services from a network to a user device, the method comprising: the user device, after joining a multicast session, receiving a paging message containing the TMGI (Temporary Mobile Group Identity) of the multicast session in which it is participating while in an RRC inactive state; and transitioning to an RRC connected state in response to receiving the paging message containing the TMGI.

[0007] A fourth aspect of the communication control method is a communication control method to be performed in a mobile communication system that provides multicast services from a network to a user device, comprising: a base station transmitting a paging message including TMGI as a group notification; and the user device monitoring the paging message at the user device's paging opportunity, wherein the transmission includes transmitting the paging message including TMGI at a timing based on a paging request from the AMF (Access and Mobility Management Function).

[0008] A fifth aspect of the communication control method is a communication control method to be performed in a mobile communication system that provides multicast broadcast service (MBS) from a base station to a user device, wherein the base station that transmits MBS data in an MBS session transmits an initial value of at least one of a PDCP variable and an RLC variable that the user device should use to receive the MBS data.

[0009] A communication control method according to the sixth aspect is a communication control method performed by a user device in a mobile communication system that provides multicast services from a network to the user device, comprising: performing a session participation procedure for a multicast session with the network; obtaining period information from the network indicating the period during which the user device remains in a state of participation in the multicast session; performing the session participation procedure or session continuation procedure with the network before or at the expiration of the period indicated by the period information if the user device is interested in the multicast session; and controlling the network not to perform the session participation procedure or session continuation procedure with the network before or at the expiration of the period indicated by the period information if the user device is not interested in the multicast session.

[0010] A seventh aspect of the communication control method is a communication control method to be performed in a mobile communication system that provides multicast services from a network to a user device, comprising: the user device performing a random access procedure to a base station included in the network while in an RRC idle state or RRC inactive state; the user device sending a notification to the base station during the random access procedure indicating that the user device has left a multicast session in which it is participating; and the user device terminating the random access procedure without transitioning to an RRC connected state. [Brief explanation of the drawing]

[0011] [Figure 1] This figure shows the configuration of a mobile communication system according to one embodiment. [Figure 2] This diagram shows the configuration of a UE (User Equipment) according to one embodiment. [Figure 3] This diagram shows the configuration of a gNB (base station) according to one embodiment. [Figure 4]This diagram shows the protocol stack configuration of the user plane wireless interface that handles data. [Figure 5] This diagram shows the protocol stack configuration of the wireless interface of the control plane that handles signaling (control signals). [Figure 6] This figure shows the correspondence between the logical channel and the transport channel of a downlink according to one embodiment. [Figure 7] This figure shows a method for distributing MBS data according to one embodiment. [Figure 8] This figure shows a split MBS bearer according to one embodiment. [Figure 9] This diagram shows the basic operation in the first operation pattern of a mobile communication system according to one embodiment. [Figure 10] This figure shows an example of a first operation pattern of a mobile communication system according to one embodiment. [Figure 11] This figure shows another example of the first operating pattern of a mobile communication system according to one embodiment. [Figure 12] This figure shows an example of a second operation pattern of a mobile communication system according to one embodiment. [Figure 13] This figure shows an example of a third operation pattern of a mobile communication system according to one embodiment. [Figure 14] This diagram shows the operation related to the example change. [Modes for carrying out the invention]

[0012] The introduction of multicast broadcast services into 5G systems (NR) is being considered. It is desirable that NR multicast broadcast services provide improved service compared to LTE multicast broadcast services.

[0013] Therefore, an object of the present disclosure is to provide a communication control method for realizing an improved multicast broadcast service.

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

[0015] (Configuration of Mobile Communication System) First, the configuration of the mobile communication system according to the 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 complies with the 5th generation system (5GS) of the 3GPP standard. Hereinafter, the 5GS will be described as an example, but the LTE (Long Term Evolution) system may be at least partially applied to the mobile communication system. Further, the 6th generation (6G) system may be at least partially applied to the mobile communication system.

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

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

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

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

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

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

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

[0023] The receiving unit 110 performs various types of reception under the control of the control unit 130. The receiving unit 110 includes an antenna and a receiver. The receiver converts the radio signal received by the antenna into a baseband signal (received signal) and outputs it to the control unit 130.

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

[0025] The control unit 130 performs various controls on the UE100. The control unit 130 includes at least one processor and at least one memory. The memory stores programs executed by the processor and information used for processing by the processor. The processor may include a baseband processor and a CPU (Central Processing Unit). The baseband processor performs modulation, demodulation, encoding, and decoding of baseband signals. The CPU executes programs stored in memory and performs various processing.

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

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

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

[0029] The receiving unit 220 performs various types of reception under the control of the control unit 230. The receiving unit 220 includes an antenna and a receiver. The receiver converts the radio signal received by the antenna into a baseband signal (received signal) and outputs it to the control unit 230.

[0030] The control unit 230 performs various controls in the gNB200. The control unit 230 includes at least one processor and at least one memory. The memory stores programs executed by the processor and information used for processing by the processor. The processor may include a baseband processor and a CPU. The baseband processor performs modulation, demodulation, encoding, and decoding of baseband signals. The CPU executes programs stored in memory and performs various processing.

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

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

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

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

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

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

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

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

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

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

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

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

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

[0044] (MBS) Next, an MBS according to one embodiment will be described. MBS is a service that enables broadcast or multicast, that is, one-to-many (PTM: Point To Multipoint) data transmission from NG-RAN10 to UE100. MBS may also be called MBMS (Multimedia Broadcast and Multicast Service). Use cases (service types) of MBS include public security communications, mission-critical communications, V2X (Vehicle to Everything) communications, IPv4 or IPv6 multicast distribution, IPTV (Internet Protocol Television), group communications, and software distribution.

[0045] 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. Figure 6 shows the correspondence between the logical channel and the transport channel of a downlink according to one embodiment.

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

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

[0048] The following primarily describes an example of MBS being provided using a method similar to the SC-PTM transmission method, but MBS may also be provided using the MBSFN transmission method. Furthermore, the description will primarily focus on an example of MBS being provided via multicast. Therefore, MBS may be interpreted as multicast. However, MBS may also be provided via broadcast.

[0049] Furthermore, MBS data refers to data provided by MBS. The MBS control channel refers to MCCH or SC-MCCH. The MBS traffic channel refers to MTCH or SC-MTCH. However, MBS data may also be transmitted via unicast. MBS data may also be called MBS packets or MBS traffic.

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

[0051] Figure 7 shows a method for distributing MBS data according to one embodiment.

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

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

[0054] In shared MBS data distribution, a connection is established between NG-RAN10, a 5G wireless access network (5G RAN), and 5GC20, and MBS data is distributed from 5GC20 to NG-RAN10. Hereafter, this connection (tunnel) will be referred to as the "MBS connection".

[0055] An MBS connection may also be called a Shared MBS Traffic Delivery connection or a shared transport. The MBS connection terminates at NG-RAN10 (i.e., gNB200). The MBS connection may have a one-to-one correspondence with an MBS session.

[0056] The gNB200 selects either PTP (Point-to-Point: unicast) or PTM (Point-to-Multipoint: multicast or broadcast) as its own decision and sends MBS data to the UE100 using the selected transmission method.

[0057] On the other hand, in individual MBS data distribution, a unicast session is established between NG-RAN10 and UE100, and MBS data is individually distributed from 5GC20 to UE100. Such a unicast may also be called a PDU (Protocol Data Unit) session. The unicast (PDU session) terminates at UE100.

[0058] (Split MBS Bearer) Next, a split MBS bearer according to one embodiment will be described.

[0059] 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 data to the UE100 between PTP (PTP communication path) and PTM (PTM communication path). Alternatively, the gNB200 can enhance reliability by using both PTP (PTP communication path) and PTM (PTM communication path) to transmit the same MBS data twice.

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

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

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

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

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

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

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

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

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

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

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

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

[0072] (Operation of mobile communication systems) Next, the operation of the mobile communication system 1 according to one embodiment will be described.

[0073] In the following, we primarily assume that UE100, in an RRC connected state, receives MBS data (i.e., multicast data) transmitted via multicast from gNB200. Therefore, the MBS session is assumed to be a multicast session. Furthermore, the MBS session identifier is assumed to be a multicast session identifier (e.g., TMGI, Session ID, or G-RNTI). The multicast session is mapped to a PTM leg or PTM bearer (multicast bearer). An MBS traffic channel (MTCH) is used to transmit multicast data from gNB200 to UE100.

[0074] In the following, it is assumed that after UE100 joins a multicast session, it transitions to the RRC idle or RRC inactive state and waits for the multicast session to start. UE100 receives a group notification, which is a notification indicating the activation of the multicast session it is participating in, sent from the network to the group to which UE100 belongs, while in the RRC idle or RRC inactive state. Upon receiving the group notification, UE100 transitions to the RRC connected state and receives multicast data for that multicast session from gNB200.

[0075] Figure 9 shows the basic operation of the mobile communication system 1 in its first operating pattern. Hereafter, gNB200 and AMF300 will be collectively referred to as the "network." The AMF300 is an example of a core network (CN) device. The AMF300 manages MBS sessions (multicast sessions) in cooperation with a session management device. The session management device is another example of a CN device.

[0076] As shown in Figure 9, in step S101, UE100 is in the RRC connected state. UE100 is assumed to have taken an interest in a multicast session (hereinafter referred to as the "target multicast session"). "Taking an interest in a multicast session" means that the upper layer of UE100 requests or desires to receive the multicast session. The upper layer includes the NAS layer. The upper layer may further include applications.

[0077] In step S102, UE100 (NAS entity) performs a multicast session join procedure on the network to join the target multicast session. For example, UE100 joins the target multicast session by sending a first NAS message to AMF300 requesting to join the target multicast session and receiving a second NAS message from AMF300 acknowledging its participation in the target multicast session. "Joining the target multicast session" means registering UE100 as a member of the UE group (multicast group) that receives the multicast session with the CN device. Note that participation in a multicast session may be performed when the multicast session is active (transmitting). Alternatively, participation in a multicast session may be performed when it is inactive (waiting to start transmission or transmission is interrupted).

[0078] In step S103, UE100 transitions to either the RRC idle state or the RRC inactive state. Specifically, UE100 transitions to either the RRC idle state or the RRC inactive state by receiving an RRC release message from gNB200. Prior to step S103, UE100 may send gNB200 an RRC message (e.g., a UE Assistance Information message) containing informational elements prompting UE100 to transition to the RRC idle state or the RRC inactive state. gNB200 may decide to transition UE100 to either the RRC idle state or the RRC inactive state depending on whether the multicast session of interest to UE100 is in an invalid state.

[0079] In step S104, UE100 begins monitoring for group notifications from gNB200. The group notification may be a paging message sent from gNB200. Alternatively, the group notification may be a message sent from gNB200 over the multicast control channel (MCCH). The group notification may be sent in response to a multicast session being enabled from an inactive state. The group notification may also notify the start of a multicast session. In the following, it is primarily assumed that the group notification is a paging message. UE100 monitors for group notifications during paging opportunities (POs) of periodically configured paging frames (PFs).

[0080] In step S105, gNB200 sends a group notification to the group that includes UE100 or to a group of interest to UE100. gNB200 may also send a group notification (paging message) to UE100 in response to a paging request from AMF300. The group notification may include at least one of the following: a multicast session identifier indicating the group, an identifier for each UE belonging to the group, and a multicast session identifier associated with that identifier. Upon receiving a group notification containing its own identifier, UE100 can recognize that the target multicast session it has joined has been activated. "The target multicast session being activated" may also mean that the transmission of multicast data has begun in the target multicast session. Alternatively, "the target multicast session being activated" may mean that the target multicast session is in a state where it can begin transmitting multicast data.

[0081] In step S106, UE100 performs a random access procedure on gNB200 to receive the target multicast session.

[0082] In step S107, UE100 transitions to the RRC connected state via a random access procedure.

[0083] In step S108, UE100 receives multicast data for the target multicast session from gNB200 in the RRC connected state. Before receiving the data, gNB200 may configure UE100 for receiving the target multicast session. This configuration may be, for example, an RRC Reconfiguration message including MRB (Multicast Radio Bearer) configuration.

[0084] In this basic operation, UE100 may lose interest in the target multicast session after transitioning to the RRC idle or RRC inactive state in step S103. "Losing interest in the target multicast session" means that the upper layer of UE100 no longer requests or desires to receive the target multicast session. For example, this would occur if a user closes an IPTV application. In such a case, UE100 may transition to the RRC connected state and then leave the target multicast session by performing a multicast session departure procedure. "Leaving the target multicast session" means unregistering UE100 from the CN device as a member of the UE group (multicast group) that receives the multicast session. For example, UE100 leaves the target multicast session by sending a third NAS message to AMF300 requesting departure from the target multicast session and receiving a fourth NAS message from AMF300 acknowledging the departure from the target multicast session.

[0085] If the UE100, having lost interest in the target multicast session, were to perform group notification monitoring or transition to the RRC Connected state, it would increase the UE100's power consumption and decrease the efficiency of wireless resource utilization. For example, transitioning to the RRC Connected state solely to perform the multicast session exit procedure is inefficient. For example, it would be more efficient to transition to the RRC Connected state when unicast data communication is needed later and perform the multicast session exit procedure at that time.

[0086] (1) First operation pattern Next, a first operation pattern of the mobile communication system 1 according to one embodiment will be described.

[0087] In the first operating pattern, the UE100 monitors for group notifications, which are notifications indicating the activation of multicast sessions (target multicast sessions) in which it is participating, and which are sent from the network to the group to which it belongs or to a group of interest, while in the RRC idle or RRC inactive state. Upon receiving a group notification, the UE100 transitions to the RRC connected state to receive the multicast session. However, if the UE100 loses interest in the multicast session while in the RRC idle or RRC inactive state, it is controlled not to monitor for group notifications or transition to the RRC connected state. This prevents the UE100 from operating inefficiently.

[0088] Figure 10 shows an example of the first operation pattern of the mobile communication system 1. Here, we will mainly explain the differences from the basic operation described above.

[0089] As shown in Figure 10, in step S111, the UE100, which is in the RRC connected state, is assumed to have become interested in a certain multicast session (hereinafter referred to as the "target multicast session").

[0090] In step S112, UE100 (NAS entity) performs a multicast session join procedure on the network (AMF300) to join the target multicast session.

[0091] In step S113, UE100 transitions to either the RRC idle state or the RRC inactive state.

[0092] In step S114, UE100 (AS entity) begins monitoring group notifications from gNB200. The AS entity may also be an RRC entity. The group notification may be a paging message sent from gNB200. Alternatively, the group notification may be a message sent from gNB200 over a multicast control channel (MCCH). In the following, we will primarily assume that the group notification is a paging message. UE100 monitors the group notification at paging opportunities (POs) of periodically configured paging frames (PFs). That is, UE100 periodically monitors the group notification.

[0093] In step S115, UE100 is deemed to have lost interest in the target multicast session. UE100 may also notify the AS entity (e.g., the RRC entity) that it has lost interest in the target multicast session.

[0094] In step S116, the UE100 (AS entity) stops periodic monitoring of group notifications. For example, in the UE100, the control unit 130 controls the receiving unit 110 so that it does not monitor group notifications. This reduces the processing load and power consumption of the UE100. When paging is used as a group notification, and the opportunities for receiving (sending) group notifications and normal paging (paging for unicast communication) are the same, the control to not monitor group notifications means that the UE100 omits the receiving process related to the group notification at that receiving opportunity. Omitting the receiving process includes, for example, not monitoring the RNTI dedicated to group notifications, not demodulating the message portion dedicated to group notifications, and not checking the group notification information elements in the paging message (e.g., multicast session identifier or this list). In addition to these, if the opportunities for receiving (sending) group notifications and normal paging are different, the UE100 does not perform a receiving operation (does not wake up) at the opportunity to receive group notifications. Even if monitoring of group notifications is stopped, monitoring of normal paging should continue.

[0095] For example, when using paging (group paging) as a group notification, there are two possible configurations for the PF / PO that monitors group paging: 1) a PF / PO dedicated to group paging (separate from unicast paging), and 2) the same PF / PO as for normal paging. In case 1), UE100 only needs to stop monitoring the PF / PO for group paging. In case 2), the PF / PO is the same as for normal paging, so UE100 does not monitor only the part related to group paging. For example, UE100 may choose not to monitor a dedicated RNTI for group paging (e.g., GP-RNTI) if one is defined, or it may choose not to check the group identifier (list) in the paging message.

[0096] Subsequently, in step S117, UE100 performs a random access procedure on gNB200 for purposes other than receiving a multicast session, such as the occurrence of uplink data to be transmitted or the occurrence of downlink data to be received (i.e., receiving normal / unicast paging).

[0097] In step S118, UE100 transitions to the RRC connected state.

[0098] In step S119, UE100 (NAS entity) performs the session exit procedure for the target multicast session on the network (AMF300). This allows the session exit procedure to be performed efficiently.

[0099] Figure 11 shows another example of the first operation pattern of the mobile communication system 1. Here, we will mainly explain the differences from the basic operation described above.

[0100] As shown in Figure 11, in step S121, the UE100, which is in the RRC connected state, is assumed to have become interested in a certain multicast session (hereinafter referred to as the "target multicast session").

[0101] In step S122, UE100 (NAS entity) performs a multicast session join procedure on the network (AMF300) to join the target multicast session.

[0102] In step S123, UE100 transitions to either the RRC idle state or the RRC inactive state.

[0103] In step S124, UE100 begins monitoring group notifications from gNB200.

[0104] In step S125, UE100 is deemed to have lost interest in the target multicast session. The NAS entity in UE100 may notify the AS entity (e.g., the RRC entity) that it has lost interest in the target multicast session.

[0105] In step S126, gNB200 sends a group notification addressed to the group including UE100. gNB200 may also send a group notification (paging message) to UE100 in response to a paging request from AMF300. The group notification may include the identifier of each UE belonging to the group and the multicast session identifier associated with that identifier. Upon receiving a group notification containing its own identifier, UE100 can recognize that the target multicast session it joined has been activated.

[0106] In step S127, the AS entity (access layer entity) of UE100 is controlled not to transition to the RRC connected state even if it receives a group notification addressed to it. The AS entity may also be an RRC entity. In UE100, the AS entity may notify the NAS entity of the multicast session identifier included in the group notification addressed to UE100 (specifically, the multicast session identifier associated with the identifier of UE100). If the NAS entity determines that it has no interest in the multicast session indicated by the notified multicast session identifier, it will not request the AS entity to perform the process of transitioning to the RRC connected state. On the other hand, if the NAS entity determines that it has interest in the multicast session indicated by the notified multicast session identifier, it may request the AS entity to perform the process of transitioning to the RRC connected state.

[0107] Subsequently, in step S128, UE100 performs a random access procedure on gNB200 for purposes other than receiving a multicast session, such as the occurrence of uplink data to be transmitted or the occurrence of downlink data to be received (i.e., receiving normal / unicast paging).

[0108] In step S129, UE100 transitions to the RRC connected state.

[0109] In step S130, UE100 (NAS entity) performs the session exit procedure for the target multicast session on the network (AMF300). This allows the session exit procedure to be performed efficiently.

[0110] (2) Second operation pattern Next, a second operation pattern of the mobile communication system 1 according to one embodiment will be described.

[0111] As described above, even if the CN device recognizes that UE100 is participating in the target multicast session, it is possible that UE100 has lost interest in the target multicast session. In other words, there is a concern that a mismatch may occur between UE100's interest state and its participation state. However, explicitly leaving the session requires sending a NAS message, which leads to the inefficient operation described above. Therefore, the second operation pattern describes an operation that allows UE100 to implicitly (automatically) leave the session. Furthermore, this operation can resolve the aforementioned mismatch problem even if UE100 moves out of range or is powered off.

[0112] In the second operational pattern, UE100 performs the session join procedure for the target multicast session with the network. UE100 obtains duration information from the network (AMF300) indicating the period during which it will remain a participant in the target multicast session. This duration may also be called the validity period or participation duration, but will be referred to as the validity period below.

[0113] If UE100 is interested in the target multicast session, it will perform a session join procedure or a rejoin procedure with AMF300 before or at the expiration of the validity period indicated by the validity period information. On the other hand, if UE100 is not interested in the target multicast session, it will be controlled not to perform a session join procedure or a rejoin procedure with AMF300 before or at the expiration of the validity period indicated by the validity period information. As a result, UE100, having lost interest in the target multicast session, can implicitly (automatically) leave the target multicast session by not performing a session join procedure or a rejoin procedure.

[0114] Figure 12 shows an example of the second operation pattern of the mobile communication system 1. Here, we will mainly explain the differences from the basic operation described above.

[0115] As shown in Figure 12, in step S201, the UE100, which is in the RRC connected state, is assumed to have become interested in a certain multicast session (the target multicast session).

[0116] In steps S202 and S203, UE100 (NAS entity) performs a multicast session join procedure on the network (AMF300) to join the target multicast session.

[0117] Specifically, in step S202, UE100 (NAS entity) sends a NAS message (first NAS message) to AMF300 requesting participation in the target multicast session. The first NAS message may include the identifier of UE100 and the multicast session identifier of the target multicast session. UE100 may also include information indicating the desired validity period in the first NAS message.

[0118] In step S203, upon receiving the first NAS message, the AMF300 sends a second NAS message to the UE100 (NAS entity) approving its participation in the target multicast session. The AMF300 may also include validity period information in the second NAS message. If the first NAS message contains information indicating the validity period desired by the UE100, the AMF300 may determine the validity period based on that information and include validity period information indicating the determined validity period in the second NAS message.

[0119] The validity period information may be a timer value indicating the validity period. The validity period information may also be information indicating the end date of the validity period in absolute time. In the following, we will assume that the validity period information is a timer value.

[0120] In step S204, when UE100 (NAS entity) obtains validity period information (timer value) from the network, for example, when it obtains validity period information (timer value) from the second NAS message, it starts the timer set to that timer value. Note that this timer may only be started and operated when UE100 is in the CM_IDLE state. The CM_IDLE state means that UE100 does not have a NAS signaling connection. After receiving the second NAS message, the timer may be started or restarted (reset and started) in response to UE100 transitioning to CM_IDLE. The timer may be stopped in response to transitioning to CM_CONNECTED.

[0121] In step S205, the timer expires. The processes in steps S206 to S209, described below, may be performed before step S205.

[0122] In step S206, UE100 (NAS entity) determines whether or not it is interested in the target multicast session.

[0123] If it is determined that the target multicast session is of interest (step S206: YES), in steps S207 and S208, the UE100 (NAS entity) performs a multicast session join / continue procedure on the network (AMF300) to join (or continue joining) the target multicast session.

[0124] Specifically, in step S207, UE100 (NAS entity) sends a NAS message (first NAS message) to AMF300 requesting to join (or continue joining) the target multicast session. The first NAS message may include the identifier of UE100 and the multicast session identifier of the target multicast session. UE100 may also include information indicating the desired validity period in the first NAS message.

[0125] In step S208, upon receiving the first NAS message, the AMF300 sends a second NAS message to the UE100 (NAS entity) approving participation in (or continued participation in) the target multicast session. The AMF300 may also include validity period information in the second NAS message. If the first NAS message contains information indicating the validity period desired by the UE100, the AMF300 may determine the validity period based on that information and include validity period information indicating the determined validity period in the second NAS message.

[0126] The validity period information may be a timer value indicating the validity period. The validity period information may also be information indicating the end date of the validity period as an absolute time.

[0127] In step S209, when UE100 (NAS entity) obtains validity period information (timer value) from the network, for example, when it obtains the validity period information (timer value) from the second NAS message, it starts the timer set to that timer value. Note that, as described above, this timer may only be started and operated when UE100 is in the CM_IDLE state. Also, if the second NAS message for continued approval in step S208 does not contain validity period information (timer value), the value obtained in the second NAS message for the initial approval in step S203 may be applied.

[0128] Thus, if UE100 is still interested in the target multicast session, the validity period is renewed, and UE100 remains a participant in the target multicast session.

[0129] On the other hand, if it is determined that the UE100 is no longer interested in the target multicast session (step S206: NO), the UE100 will not perform the multicast session join / continue procedure. If the AMF300 does not receive a multicast session join / continue request from the UE100 within the validity period, or within a predetermined time after the expiration of the validity period, the AMF300 will assume that the UE100 is no longer interested in the target multicast session (or that the UE100 has moved out of range or been powered off), and will manage the UE100 as having left the target multicast session.

[0130] (3) Third operation pattern Next, a third operation pattern of the mobile communication system 1 according to one embodiment will be described.

[0131] As mentioned above, it is inefficient for UE100 to transition to the RRC Connected state simply to notify of session departure. In the third operating pattern, UE100 notifies of session departure during the random access procedure and terminates the random access procedure without transitioning to the RRC Connected state, thereby streamlining the notification of session departure.

[0132] In the third operation pattern, UE100 performs a random access procedure to gNB200 while in the RRC idle or RRC inactive state. During the random access procedure, UE100 sends a notification to gNB200 indicating that it is leaving the multicast session in which it is participating (the target multicast session). Then, UE100 terminates the random access procedure without transitioning to the RRC connected state.

[0133] The random access procedure includes sending a random access preamble to the gNB200 using the PRACH (Physical Random Access Channel) resource. The UE100 may also send a random access preamble using the PRACH resource for session departure to the gNB200 as a notification indicating session departure. The gNB200 identifies the UE100 that sent the notification indicating session departure and notifies the CN device (AMF300) of the UE100's session departure.

[0134] Figure 13 shows an example of the third operation pattern of the mobile communication system 1. Here, we will mainly explain the differences from the basic operation described above.

[0135] As shown in Figure 13, in step S301, the UE100, which is in the RRC connected state, is assumed to have become interested in a certain multicast session (the target multicast session).

[0136] In step S302, UE100 (NAS entity) performs a multicast session join procedure on the network (AMF300) to join the target multicast session.

[0137] In step S303, UE100 transitions to either the RRC idle state or the RRC inactive state.

[0138] In step S304, UE100 (NAS entity) is deemed to have lost interest in the target multicast session. UE100 may also notify the AS entity (e.g., RRC entity) that it has lost interest in the target multicast session.

[0139] In step S305, UE100 (AS entity) receives PRACH information from gNB200 indicating the configuration of PRACH resources. The PRACH information may also be broadcast from gNB200 in the system information. For example, a portion of the configured PRACH resources may be a resource area for session departure notifications (e.g., a dedicated resource area). The resource area for session departure notifications may include multiple sub-resource areas separated by multicast session identifiers.

[0140] In step S306, UE100 (AS entity) selects a PRACH resource from the PRACH resources indicated by the PRACH information that is included in the resource area for session departure notifications. Here, UE100 (AS entity) may also select a sub-resource area associated with the multicast session identifier of the target multicast session.

[0141] In step S307, UE100 (AS entity) sends a random access preamble (Msg1) to gNB200 using the PRACH resource selected in step S306. gNB200 considers that UE100, which sent the random access preamble, has notified of session departure because the PRACH resource for session departure notification is applied to the random access preamble.

[0142] In step S308, gNB200 sends a random access response (Msg2) to UE100.

[0143] In step S309, upon receiving a random access response (Msg2), UE100 sends a connection request message (Msg3) to gNB200. The connection request message (Msg3) may be an RRC Setup Request message or an RRC Resume Request message. The connection request message (Msg3) may include at least one of the following: the identifier of UE100, information indicating that it is leaving a multicast session, and the multicast session identifier of the target multicast session. Based on the information contained in the connection request message (Msg3), gNB200 identifies the UE100 and recognizes that it is leaving a multicast session. gNB200 may also identify the UE100 after contention resolution by Msg4, as described below. If the connection request message (Msg3) is an RRC Resume Request message, i.e., if the UE100 is in an RRC inactive state, gNB200 may identify the UE context of the UE100 that it holds.

[0144] In step S310, gNB200 sends an RRC release message as Msg4 to UE100. As a result, UE100 remains in the RRC idle or RRC inactive state. However, if there is other data transmission or reception for UE100, gNB200 may transition UE100 to the RRC connected state by sending an RRC Setup message or an RRC Resume message as Msg4.

[0145] In step S311, gNB200 notifies AMF300 of UE100's departure from the multicast session. For example, gNB200 makes this notification by sending an NG-AP message on the NG interface. gNB200 may also generate a NAS message on behalf of UE100 and make the notification via the NAS message. Such a message may include the identifier of UE100 and the multicast session identifier of the target multicast session. Note that the processing in step S311 may be performed before step S310.

[0146] In this operation pattern, a 4-step random access procedure is used as an example, but a 2-step random access procedure may also be used. In a 2-step random access procedure, UE100 sends Msg1 and Msg3 together as MsgA to gNB200, and gNB200 sends Msg2 and Msg4 together as MsgB to UE100.

[0147] (Examples of changes to the operation of mobile communication systems) Next, we will describe an example of a change in the operation of mobile communication system 1. This example of a change may be applied not only to multicast but also to broadcast MBS services.

[0148] The UE100's PDCP entities set and update PDCP variables according to the PDCP sequence number (PDCP SN) contained in the PDCP packets received from the gNB200. Typically, the UE100 sets the initial value of the PDCP variables to zero and updates (increments, counts up) the PDCP variables as packets are received from the gNB200. A UE100 PDCP entity that has been participating in an MBS session from the beginning can sequentially update its PDCP variables to the latest state. The PDCP variables include the PDCP SN and the hyperframe number (HFN). The HFN is incremented when the PDCP SN completes a full cycle. In other words, the HFN is a value that counts up each time the PDCP SN completes a full cycle. For example, the UE100 and gNB200 manage a count value called COUNT, which consists of the PDCP SN and HFN.

[0149] A PDCP entity in UE100 that joins an MBS session midway cannot perform the predetermined PDCP operation correctly because it does not know the current PDCP variables (especially the HFN part). The predetermined PDCP operation is at least one of receive window control and packet reordering. The PDCP variable used for receive window control may be at least one of RX_NEXT and RX_DELIV. RX_NEXT consists of the sequence number of the PDCP SDU that is expected to be received next. RX_DELIV consists of the sequence number of the oldest PDCP SDU that is waiting to be received and has not yet been provided to the upper layer. Normally, the initial values ​​of RX_NEXT and RX_DELIV are "0". The PDCP variable used for packet reordering may be RX_REORD. RX_REORD is the sequence number of the PDCP SDU that started the timer indicating the maximum time to wait for packet reordering. For example, UE100 discards a received packet if its sequence number is smaller than RX_REORD. Furthermore, the PDCP variable (COUNT value) is also used for encrypting PDCP packets for security purposes.

[0150] In particular, the initial value of RX_DELIV is 0, and in the case of unicast, both gNB200 and UE100 synchronize their HFNs by incrementing the HFN each time the PDCP SN wraps around, based on the initial value. In the case of multicast, since it is uncertain which RX_DELIV the UE100 will start receiving PDCP packets from, it is not possible to determine the valid HFN (i.e., the HFN managed by gNB200) by looking only at the received PDCP packets. Note that the header of a PDCP PDU contains the PDCP SN, but not the HFN. In the following, a PDCP variable is defined as at least one of the HFN and COUNT values.

[0151] In this modified example, gNB200, which transmits MBS data in an MBS session, transmits the initial values ​​of PDCP variables that UE100, which joins the MBS session midway, should use to receive the MBS data, via multicast or broadcast within the MBS session. That is, gNB200 transmits the current PDCP variables in the MBS data transmission (MBS traffic channel). gNB200 may also periodically transmit the initial values ​​of PDCP variables that UE100, which joins the MBS session midway, should use to receive the MBS data, via multicast or broadcast. Upon receiving the initial values ​​of PDCP variables from gNB200, UE100 performs MBS data reception processing using the received initial values ​​of PDCP variables. This makes it possible for UE100, which joins the MBS session midway, to perform PDCP processing appropriately.

[0152] Figure 14 shows the operation related to this modification example.

[0153] As shown in Figure 14, the gNB200 starts transmitting MBS data for a given MBS session. The gNB200 transmits the MBS data and updates the PDCP variables.

[0154] In step S402, UE100 joins the MBS session late (joins midway). However, because UE100 does not know the current COUNT value (especially the HFN portion), it cannot perform PDCP processing on the data packets (PDCP packets) that make up the MBS data. UE100 may obtain the PDCP SN contained in the header of the first PDCP packet received from gNB200 and use the obtained PDCP SN as part of the COUNT value it manages.

[0155] In step S403, the gNB200 periodically transmits the COUNT value (or HFN) of the currently transmitted MBS data packet (PDCP packet), or the COUNT value (or HFN) of the next MBS data packet (PDCP packet) to be transmitted, via multicast or broadcast. Specifically, the gNB200 transmits the current COUNT value (or HFN) on the MBS traffic channel using G-RNTI. For example, the gNB200 transmits the initial value of the PDCP variable in at least one of the following: MAC CE (Control Element), RLC Control PDU, and PDCP Control PDU. When using MAC CE, the gNB200 may transmit a set of multicast session identifier (TMGI) and COUNT value. When using PDCP / RLC Control PDU, the UE100 can identify it as the COUNT value of the bearer / LCH to which the PDCP / RLC Control PDU belongs. Here, if received at a lower layer (e.g., MAC), the lower layer will notify the upper layer (e.g., PDCP) of the COUNT value (or HFN).

[0156] In step S404, UE100 (PDCP entity) sets the PDCP variable notified by gNB200 as the initial value of the PDCP variable it manages.

[0157] In step S405, the gNB200 transmits MBS data packets (PDCP packets) via multicast or broadcast.

[0158] In step S406, UE100 performs PDCP processing on the MBS data packets (PDCP packets) received from gNB200 using the PDCP variables it manages, and updates the PDCP variables it manages.

[0159] Furthermore, the operation described in this modification example may be applied to the operation of RLC, and "PDCP" may be read as "RLC". The initial value of the PDCP variable may be the initial value of the RLC variable. In addition, although this modification example describes an example in which the initial value of the PDCP variable that a UE100 joining an MBS session midway through sends to receive MBS data is transmitted via multicast or broadcast in the MBS session, the gNB200 may also transmit the said initial value of the PDCP variable via broadcast using system information (SIB).

[0160] (Other embodiments) Each of the above-described operation flows can be performed not only independently, but also in combination of two or more operation flows. For example, some steps of one operation flow may be added to another operation flow. Or, some steps of one operation flow may be replaced with some steps of another operation flow.

[0161] In the above embodiment, an example was described in which the base station is an NR base station (gNB), but the base station may also be an LTE base station (eNB). Furthermore, the base station may be a relay node such as an IAB (Integrated Access and Backhaul) node. The base station may also be a DU (Distributed Unit) of an IAB node.

[0162] A program may be provided that causes a computer to execute each process performed by the UE100 or gNB200. The program may be recorded on a computer-readable medium. Using a computer-readable medium, it is possible to install the program on a computer. Here, the computer-readable medium on which the program is recorded may be a non-transient recording medium. The non-transient recording medium is not particularly limited, but may be a recording medium such as a CD-ROM or DVD-ROM. Alternatively, the circuits that execute each process performed by the UE100 or gNB200 may be integrated, and at least a part of the UE100 or gNB200 may be configured as a semiconductor integrated circuit (chipset, SoC: System on a Chip).

[0163] The terms "based on" and "depending on" used in this disclosure do not mean "based solely on" or "depending solely on" unless otherwise specified. The term "based on" means both "based solely on" and "at least partially on." Similarly, the term "depending on" means both "at least partially on" and "at least partially on." Also, "obtain / acquire" may mean obtaining information from stored information, obtaining information from information received from other nodes, or obtaining information by generating it. The terms "include," "comprise," and their variations do not mean to include only the listed items, but may include only the listed items, or may include additional items in addition to the listed items. Also, the term "or" used in this disclosure is not intended to mean exclusive OR. Furthermore, any reference to elements using designations such as "first," "second," etc., used in this disclosure does not limit the quantity or order of those elements in general. These designations may be used herein as a convenient way to distinguish between two or more elements. Therefore, references to the first and second elements do not imply that only two elements may be employed therein, or that the first element must precede the second element in any way. In this disclosure, where articles are added by translation, such as a, an, and the in English, these articles shall be plural unless it is clearly indicated otherwise by the context.

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

[0165] This application claims priority to U.S. Provisional Application No. 63 / 186512 (filed May 10, 2021), the entirety of which is incorporated into the specification of this application.

Claims

1. A communication control method performed by a user device in a mobile communication system that provides broadcast / multicast services (MBS) from a network to a user device, Monitoring a group notification that indicates the activation of an MBS multicast session in which the user device is participating, and which is sent from the network to the group to which the user device belongs, in an RRC (Radio Resource Control) idle state or RRC inactive state, Upon receiving the aforementioned group notification, the system transitions to the RRC connected state for receiving the aforementioned MBS multicast session. The system also includes the ability to control the monitoring of the dedicated RNTI (Radio Network Temporary Identifier) ​​for group notifications when the user leaves the MBS multicast session. Communication control method.

2. A user device that supports the reception of broadcast / multicast services (MBS), The system monitors group notifications, which indicate the activation of an MBS multicast session in which the user device is participating and which are sent from the network to the group to which the user device belongs, in the RRC (Radio Resource Control) idle state or RRC inactive state. The control unit, upon receiving the aforementioned group notification, transitions to the RRC connected state for receiving the aforementioned MBS multicast session. The control unit controls the monitoring of the group notification's dedicated RNTI (Radio Network Temporary Identifier) ​​to cease when the user leaves the MBS multicast session. User device.

3. A processor for controlling user equipment that supports the reception of broadcast / multicast services (MBS), A process to monitor a group notification, which indicates the activation of an MBS multicast session in which the user device is participating and is sent from the network to the group to which the user device belongs, in an RRC (Radio Resource Control) idle state or RRC inactive state, In response to receiving the aforementioned group notification, the process transitions to the RRC connected state in order to receive the aforementioned MBS multicast session. If the user leaves the aforementioned MBS multicast session, the system will execute a process to control the monitoring of the group notification's dedicated RNTI (Radio Network Temporary Identifier) ​​so that it does not perform the monitoring. Processor.

Images