Communication method, user device, mobile communication system, program, and chipset

Abstract

This communication method comprises: a step in which a user device in a wireless resource control (RRC) connected state receives a first multicast configuration including a reference identifier, a fixed parameter value, and a variable parameter value from a network node via a dedicated RRC message; a step in which the user device that has transitioned from the RRC connected state to an RRC inactive state receives a second multicast configuration including the reference identifier and a new variable parameter value from the network node in a multicast control channel (MCCH); and a step in which, on the basis of the reference identifier, the user device in the RRC inactive state updates the variable parameter value received in the dedicated RRC message to the new variable configuration parameter value received in the MCCH.

Description

[Technical Field]

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

[0002] The 3rd Generation Partnership Project (3GPP) (registered trademark; the same applies hereinafter) has defined the technical specifications for NR (New Radio), a fifth-generation (5G) radio access technology. Compared to LTE (Long Term Evolution), a fourth-generation (4G) radio access technology, NR has features such as high speed, large capacity, high reliability, and low latency. 3GPP has also defined the technical specifications for 5G / NR multicast / broadcast services (MBS) (see, for example, Non-Patent Document 1). [Prior art documents] [Non-patent literature]

[0003] [Non-Patent Document 1] 3GPP Technical Specification: TS 38.300 V17.1.0 Summary of the Invention

[0004] A communication method according to a first aspect is a communication method used in a mobile communication system that provides a multicast / broadcast service (MBS), and includes the steps of: a user equipment in a radio resource control (RRC) connected state receiving a first multicast configuration including a reference identifier, a fixed parameter value, and a variable parameter value from a network node (or a network device) in a dedicated RRC message; the user equipment that has transitioned from the RRC connected state to an RRC inactive state receiving a second multicast configuration including the reference identifier and a new variable parameter value from the network node on a multicast control channel (MCCH); and the user equipment in the RRC inactive state converting the variable parameter value received in the dedicated RRC message into the new variable parameter value received on the MCCH based on the reference identifier. Weird Party and updating the parameter value.

[0005] A communication method according to a second aspect is a communication method used in a mobile communication system that provides a multicast / broadcast service (MBS), and includes the steps of: a user equipment in a radio resource control (RRC) connected state and having participated in a multicast session receiving, from a network node, configuration information that sets whether the user equipment will monitor a multicast control channel (MCCH) in an RRC inactive state; and the user equipment that has transitioned from the RRC connected state to the RRC inactive state monitoring the MCCH based on the configuration information. [Brief explanation of the drawings]

[0006] [Figure 1] 1 is a diagram illustrating a configuration of a mobile communication system according to an embodiment. [Figure 2] 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 an 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. 10 is a diagram illustrating the operation of a UE in an RRC inactive state for multicast reception. [Figure 7] FIG. 1 is a diagram illustrating an example of operation of a mobile communication system according to an embodiment. [Figure 8] FIG. 10 is a diagram illustrating an example of operation of a mobile communication system according to a modified example. DETAILED DESCRIPTION OF THE INVENTION

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

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

[0009] The mobile communication system 1 includes a user equipment (UE) 100, a 5G radio access network (NG-RAN) 10, and a 5G core network (5GC) 20. Hereinafter, the NG-RAN 10 may be simply referred to as the RAN 10 (or network 10). The 5GC 20 may be simply referred to as the core network (CN) 20.

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

[0011] The NG-RAN 10 includes a base station (called "gNB" in the 5G system) 200. The gNBs 200 are connected to each other via an Xn interface, which is an interface between base stations. The gNB 200 manages one or more cells. The gNB 200 performs wireless communication with 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 (hereinafter simply referred to as "frequency").

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

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

[0014] 2 is a diagram showing the configuration of a UE 100 (user equipment) according to the embodiment. The UE 100 includes a receiving unit 110, a transmitting unit 120, and a control unit 130. The receiving unit 110 and the transmitting unit 120 constitute a wireless communication unit that performs wireless communication with the gNB 200.

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

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

[0017] The control unit 130 performs various controls and processes in the UE 100. Such processes include processes of each layer described below. The operations of the UE 100 described above and below may be operations under the control of the control unit 230. The control unit 130 includes at least one processor and at least one memory. The memory stores programs executed by the processor and information used in the processing by the processor. The processor may include a baseband processor and a CPU (Central Processing Unit). The baseband processor performs modulation / demodulation and encoding / decoding of baseband signals. The CPU executes programs stored in the memory to perform various processes.

[0018] 3 is a diagram showing the configuration of a gNB 200 (base station) according to an embodiment. The gNB 200 includes a transmitter 210, a receiver 220, a controller 230, and a backhaul communication unit 240. The transmitter 210 and the receiver 220 constitute a wireless communication unit that performs wireless communication with the UE 100. The backhaul communication unit 240 constitutes a network communication unit that performs communication with the CN 20.

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

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

[0021] The control unit 230 performs various controls and processes in the gNB 200. Such processes include processes for each layer, which will be described later. The operations of the gNB 200 described above and below may be operations under the control of the control unit 230. The control unit 230 includes at least one processor and at least one memory. The memory stores programs executed by the processor and information used in the processing by the processor. The processor may include a baseband processor and a CPU. The baseband processor performs modulation / demodulation and encoding / decoding of baseband signals, etc. The CPU executes programs stored in the memory to perform various processes.

[0022] The backhaul communication unit 240 is connected to neighboring base stations via an Xn interface, which is an interface between base stations. The backhaul communication unit 240 is connected to the AMF / UPF 300 via an NG interface, which is an interface between a base station and a core network. Note that the gNB 200 may be configured (i.e., functionally divided) with a CU (Central Unit) and a DU (Distributed Unit), and both units may be connected via an F1 interface, which is a fronthaul interface.

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

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

[0025] 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 UE100 and the PHY layer of gNB200 via a physical channel. The PHY layer of UE100 receives downlink control information (DCI) transmitted from gNB200 on a physical downlink control channel (PDCCH). Specifically, UE100 performs blind decoding of the PDCCH using a radio network temporary identifier (RNTI) and acquires successfully decoded DCI as DCI addressed to the UE. The DCI transmitted from gNB200 has CRC parity bits scrambled by the RNTI added.

[0026] The MAC layer performs data priority control, retransmission processing using Hybrid Automatic Repeat reQuest (HARQ), random access procedures, etc. Data and control information are transmitted between the MAC layer of UE100 and the MAC layer of gNB200 via transport channels. The MAC layer of gNB200 includes a scheduler, which determines the uplink and downlink transport format (transport block size, modulation and coding scheme (MCS)) and the resource blocks to be allocated to UE100.

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

[0028] The PDCP layer performs header compression / decompression, encryption / decryption, etc.

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

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

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

[0032] 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 in accordance with the establishment, re-establishment, and release of radio bearers. When there is a connection (RRC connection) between the RRC of UE100 and the RRC of gNB200, UE100 is in an RRC connected state. When there is no connection (RRC connection) between the RRC of UE100 and the RRC of gNB200, UE100 is in an RRC idle state. When the connection between the RRC of UE100 and the RRC of gNB200 is suspended, UE100 is in an RRC inactive state.

[0033] The NAS layer, which is located above the RRC layer, performs session management, mobility management, etc. NAS signaling is transmitted between the NAS layer of the UE 100 and the NAS layer of the AMF 300A. Note that the UE 100 has an application layer and the like in addition to the radio interface protocol. Also, a layer lower than the NAS layer is referred to as an AS layer.

[0034] (MBS Overview) The mobile communication system 1 can perform resource-efficient distribution by using a multicast / broadcast service (MBS).

[0035] In the case of a multicast communication service (also referred to as "MBS multicast"), the same service and the same specific content data are simultaneously provided to a specific set of UEs. That is, not all UEs 100 within a multicast service area are permitted to receive the data. The multicast communication service is delivered to the UEs 100 using a multicast session, which is a type of MBS session. The UEs 100 can receive the multicast communication service in an RRC connected state using mechanisms such as Point-to-Point (PTP) and / or Point-to-Multipoint (PTM) delivery. The UEs 100 may also receive the multicast communication service in an RRC inactive (or RRC idle) state. Such a delivery mode is also referred to as "Delivery Mode 1".

[0036] In the case of a broadcast communication service (also referred to as "MBS broadcast"), the same service and the same specific content data are simultaneously provided to all UEs 100 in a geographical area. That is, all UEs 100 within the broadcast service area are authorized to receive the data. The broadcast communication service is delivered to the UEs 100 using a broadcast session, which is a type of MBS session. The UEs 100 can receive the broadcast communication service in any of the RRC idle state, RRC inactive state, and RRC connected state. Such a delivery mode is also referred to as "delivery mode 2".

[0037] The main logical channels used for MBS delivery are the Multicast Traffic Channel (MTCH), the Dedicated Traffic Channel (DTCH), and the Multicast Control Channel (MCCH). The MTCH is a PTM downlink channel for transmitting MBS data of either a multicast or broadcast session from the network 10 to the UE 100. The DTCH is a PTP channel for transmitting MBS data of a multicast session from the network 10 to the UE 100. The MCCH is a PTM downlink channel for transmitting MBS broadcast control information associated with one or more MTCHs from the network 10 to the UE 100.

[0038] Regarding the configuration for MBS broadcast, a UE 100 in an RRC idle state, an RRC inactive state, or an RRC connected state receives MBS configuration for a broadcast session (e.g., parameters required for MTCH reception) via the MCCH. The parameters required for MCCH reception (MCCH configuration) are provided via system information. Specifically, System Information Block Type 20 (SIB20) includes the MCCH configuration. SIB Type 21 (SIB21) includes information on service continuity for MBS broadcast reception. The MCCH provides a list of all broadcast services, including ongoing sessions, transmitted on the MTCH. The broadcast session-related information includes an MBS session ID (e.g., a Temporary Mobile Group Identity (TMGI)), associated MTCH scheduling information, and information on neighboring cells providing specific services on the MTCH.

[0039] On the other hand, with regard to MBS multicast, in the current 3GPP technical specifications, the UE 100 can receive data of a multicast session only in the RRC connected state. When the UE 100 that has joined a multicast session is in the RRC connected state and the multicast session is activated, the gNB 200 transmits an RRC reconfiguration message including an MBS configuration for the multicast session to the UE 100. Such an MBS configuration is also referred to as a multicast radio bearer (MRB) configuration, an MTCH configuration, or a multicast configuration. Such an MRB configuration (MRB-ToAddMod) includes other parameters such as an MBS session ID (mbs-SessionId), an MRB ID (mrb-Identity), and a PDCP configuration (pdcp-Config) for the MRB (multicast MRB) to be configured for the UE 100.

[0040] In the following embodiment, an operation that enables the UE 100 in the RRC inactive state to perform multicast reception will be mainly described. Fig. 6 is a diagram showing an overview of the operation.

[0041] Possible solutions for the UE 100 in the RRC inactive state to perform multicast reception include a solution based on delivery mode 1 shown in FIG. 6(a) and a solution based on delivery mode 2 shown in FIG. 6(b).

[0042] In the delivery mode 1-based solution shown in Figure 6(a), in step S1, the gNB 200 transmits an RRC Reconfiguration message including an MBS configuration (multicast configuration) for a multicast session to the UE 100 in the RRC connected state. The UE 100 receives multicast data on the MTCH via the multicast session (multicast MRB) based on the multicast configuration received in the RRC Reconfiguration message.

[0043] In step S2, the gNB 200 transmits an RRC Release message to the UE 100 in the RRC Connected state to transition the UE 100 to the RRC Inactive state. The RRC Release message includes a configuration (Suspend Config.) for the RRC Inactive state.

[0044] In step S3, in response to the reception of the RRC Release message in step S2, the UE 100 transitions from the RRC connected state to the RRC inactive (INACTIVE) state.

[0045] In step S4, the UE 100 in the RRC inactive state continues to use the multicast configuration of step S1 to receive multicast data on the MTCH via the multicast session.

[0046] This enables the UE 100 in the RRC inactive state to perform multicast reception. Note that although an example of performing multicast configuration using an RRC Reconfiguration message has been described, multicast configuration may also be performed using an RRC Release message.

[0047] Both the RRC Reconfiguration message and the RRC Release message are RRC messages transmitted individually to a UE on a Dedicated Control Channel (DCCH), and are hereinafter also referred to as dedicated RRC messages.

[0048] On the other hand, in the delivery mode 2-based solution shown in Fig. 6(b), in step S11, the gNB 200 transmits an RRC Release message to the UE 100 in the RRC Connected state to transition the UE 100 to the RRC Inactive state. The RRC Release message includes a configuration for the RRC Inactive state (Suspend Config.).

[0049] In step S12, in response to the reception of the RRC Release message in step S11, the UE 100 transitions to an RRC inactive (INACTIVE) state.

[0050] In step S13, the gNB 200 transmits an MCCH including an MBS setting (multicast setting) for the multicast session. The UE 100 receives the MCCH. Note that the UE 100 receives the SIB 20 prior to receiving the MCCH, and receives the MCCH based on the SIB 20. The MCCH transmission (and reception) may be performed before step S11 or simultaneously with step S11.

[0051] In step S14, the UE 100 in the RRC inactive state receives multicast data on the MTCH via the multicast session based on the multicast configuration received on the MCCH in step S13. This enables the UE 100 in the RRC inactive state to perform multicast reception.

[0052] (System operation example) In an embodiment, a delivery mode 1 based solution and a delivery mode 2 based solution are combined to enable efficient multicast reception for UEs 100 in an RRC inactive state.

[0053] Specifically, first, when UE 100 is in the RRC connected state, it receives a multicast setting (first multicast setting) in a dedicated RRC message. Second, UE 100 transitions from the RRC connected state to the RRC inactive state. UE 100 in the RRC inactive state may perform multicast reception using the first multicast setting until it receives the second multicast setting. Third, when UE 100 is in the RRC inactive state, it receives a multicast setting (second multicast setting) on ​​the MCCH.

[0054] As described above, MBS multicast can be received only by a specific UE group (a specific UE set). The multicast configuration includes a parameter value such as an identifier of a multicast session (multicast service) received by the specific UE group, for example, at least one of a Temporary Mobile Group Identity (TMGI) and a Group Radio Network Temporary Identifier (G-RNTI).

[0055] Such parameter values ​​are specific to a UE group and may require security (and privacy protection). However, since the MCCH is a logical channel that can be received by all UEs, it is not preferable to transmit parameter values ​​that may require security on the MCCH.

[0056] In the embodiment, parameter values ​​requiring security are set in a dedicated RRC message, and parameter values ​​other than the parameter values ​​are transmitted via the MCCH. That is, parameter values ​​requiring security are not transmitted via the MCCH, and the parameter values ​​transmitted via the dedicated RRC message are continuously used. Hereinafter, the continuously used parameter values ​​are also referred to as fixed parameter values. Meanwhile, parameter values ​​transmitted via the dedicated RRC message and the MCCH and that can be updated are also referred to as variable parameter values.

[0057] 7 is a diagram showing an example of operation of the mobile communication system 1 according to the embodiment. It is assumed that the UE 100 has already joined the multicast session prior to this operation. It is also assumed that the UE 100 is currently receiving or will soon receive multicast data in an RRC connected state.

[0058] In step S101, the gNB 200 transmits a first multicast configuration including a reference identifier, fixed parameter values ​​that are not updated by the MCCH, and variable parameter values ​​that can be updated by the MCCH to the UE 100 in the RRC connected state in a dedicated RRC message. That is, the gNB 200 configures the first multicast configuration individually for the UE. The UE 100 receives the dedicated RRC message including the first multicast configuration from the gNB 200 and stores the first multicast configuration. A part of the first multicast configuration can be updated by the MCCH. Therefore, the first multicast configuration can be considered as a base multicast configuration. Note that some or all of the variable parameter values ​​that can be updated by the MCCH may not be included in the first multicast configuration. In this case, the multicast configuration is not completed until the second multicast configuration described below is received. In other words, by receiving the first multicast configuration and the second multicast configuration, the UE 100 becomes able to receive multicast (MTCH).

[0059] In the illustrated example, the dedicated RRC message including the first multicast configuration is an RRC Reconfiguration message. However, the dedicated RRC message may be an RRC Release message. Alternatively, the fixed parameter values ​​and variable parameter values ​​may be configured in the RRC Reconfiguration message, and the reference identifier may be configured in the RRC Release message.

[0060] The reference identifier is an identifier that can identify the multicast setting and is an identifier other than the TMGI and the G-RNTI. The reference identifier may be an MRB identifier (MRB ID). However, since the MRB ID is unique to the UE, a new identifier unique to the multicast group may be used as the reference identifier.

[0061] The fixed parameter values ​​include the TMGI and / or G-RNTI associated with the multicast session.

[0062] The variable parameter value includes at least one of a transmission period and a transmission duration of an MTCH associated with the multicast session. The variable parameter value may include a PDSCH configuration of the MTCH. The variable parameter value may include at least one of drx-ConfigPTM-List, pdsch-ConfigMTCH, mtch-SSB-MappingWindowList, mtch-SchedulingInfo, pdsch-ConfigIndex, mtch-SSB-MappingWindowIndex, and drx-ConfigPTM, which are specified in the 3GPP technical specifications.

[0063] Here, which parameters (specifically, which information elements in the first multicast configuration) are fixed parameters or variable parameters may be specified in advance in a technical specification, or may be determined by configuration of the gNB 200. In the latter case, for example, in step S101, the gNB 200 may transmit information specifying at least one of the parameter types of fixed parameters and variable parameters to the UE 100. Based on the information, the UE 100 identifies whether each parameter included in the first multicast configuration configured in the dedicated RRC message is a fixed parameter or a variable parameter.

[0064] In step S102, the gNB 200 may transmit multicast data on the MTCH via the multicast session based on the first multicast configuration of step S101. The UE 100 may receive multicast data on the MTCH via the multicast session based on the first multicast configuration of step S101.

[0065] In step S103, the gNB 200 determines to transition the UE 100 from the RRC connected state to the RRC inactive state, and transmits an RRC Release message including "Suspend config." to the UE 100. The UE 100 receives the RRC Release message. Note that the above-described first multicast configuration may be included in the RRC Release message. In this case, step S101 may be unnecessary.

[0066] In step S104, in response to the reception of the RRC Release message in step S103, the UE 100 transitions from the RRC connected state to the RRC inactive state.

[0067] In step S105, the gNB 200 may transmit multicast data on the MTCH via the multicast session based on the first multicast configuration of step S101. The UE 100 that has transitioned to the RRC inactive state may receive multicast data on the MTCH via the multicast session based on the first multicast configuration of step S101.

[0068] In step S106, the gNB200 decides to update the multicast setting (first multicast setting) set in step S101. For example, the gNB200 may decide to change the transmission period of the MTCH associated with the multicast session. The gNB200 may decide to change the transmission duration of the MTCH. The transmission duration refers to the time that one MTCH transmission according to the transmission period lasts.

[0069] In step S107, the gNB 200 transmits a second multicast configuration including the reference identifier and the new variable parameter value on the MCCH to the UE 100. The UE 100 in the RRC inactive state receives the second multicast configuration.

[0070] The reference identifier in the second multicast setting is an identifier for identifying the above-mentioned first multicast setting, and is an MRB identifier or a newly defined identifier. The new variable parameter values ​​in the second multicast setting are parameter values ​​after updating the variable parameter values ​​of the first multicast setting. However, parameter values ​​that are not updated among the variable parameter values ​​may not be included in the second multicast setting.

[0071] The second multicast configuration does not include fixed parameter values, such as TMGI and / or G-RNTI. This can prevent security issues from occurring. For example, it is easy to prevent UEs 100 that are not participating in a multicast session from attempting to receive the multicast session. In addition, since TMGI has a large number of bits, not transmitting TMGI on the MCCH also contributes to reducing MCCH overhead.

[0072] In step S108, the UE 100 in the RRC inactive state converts the variable parameter value received in the dedicated RRC message (first multicast setting) into the variable parameter value received in the new dedicated RRC message (MCCH) (second multicast setting) based on the reference identifier (i.e., using the reference identifier as a key). Weird Party That is, the UE 100 updates the stored variable parameter values ​​to the new variable parameter values ​​while maintaining the stored fixed parameter values. Weird Party In this way, when a reference identifier that matches a reference identifier in the currently stored multicast configuration is included in the second multicast configuration (MCCH), the UE 100 in the RRC inactive state applies the parameters updated in the MCCH to the base multicast configuration.

[0073] In step S109, gNB200 may transmit multicast data on the MTCH via the multicast session based on the second multicast configuration of step S107. UE100 in the RRC inactive state receives multicast data from gNB200 via the multicast session on the MTCH based on the second multicast configuration of step S107, specifically, the updated multicast configuration (fixed parameter values ​​and new variable parameter values) of step S108.

[0074] (Example of behavior change) A modified example of the operation according to the above embodiment will be described. In the above embodiment, it is assumed that the UE 100 in the RRC inactive state monitors the MCCH after multicast configuration is performed using a dedicated RRC message.

[0075] However, in a case where the multicast configuration set by the dedicated RRC message is not updated thereafter, the UE 100 may waste power consumption by monitoring the MCCH. Therefore, in this modification, the gNB 200 is configured to set to the UE 100 whether or not the UE 100 should monitor the MCCH. Specifically, the gNB 200 sets to the UE 100 whether or not the UE 100 should monitor the MCCH while the UE 100 is receiving multicast in an RRC inactive state.

[0076] 8 is a diagram showing an example of operation of the mobile communication system 1 according to this modification. It is assumed that the UE 100 has already joined the multicast session prior to this operation. It is also assumed that the UE 100 is currently receiving or will soon receive multicast data in the RRC connected state. Here, redundant explanations of operations similar to those described above will be omitted.

[0077] In step S201, the gNB 200 transmits multicast configuration to the UE 100 in the RRC connected state in a dedicated RRC message (in the illustrated example, this is an RRC Reconfiguration message; however, this may be an RRC Release message (step S203)). The UE 100 receives the multicast configuration in the dedicated RRC message.

[0078] In step S202, the gNB 200 may transmit multicast data on the MTCH via the multicast session based on the multicast configuration of step S201. The UE 100 may receive multicast data on the MTCH via the multicast session based on the multicast configuration of step S201.

[0079] In step S203, the gNB 200 determines to transition the UE 100 from the RRC connected state to the RRC inactive state, and transmits an RRC Release message including Suspend config. to the UE 100. The UE 100 receives the RRC Release message.

[0080] In the illustrated example, the gNB 200 includes in the RRC Release message configuration information for configuring whether or not the UE 100 monitors the MCCH in the RRC inactive state. That is, the RRC Release message includes configuration information that specifies whether or not to perform an MCCH reception operation when performing (or waiting for) multicast reception in the RRC inactive state. Note that instead of including the configuration information in the RRC Release message (step S203), the configuration information may be included in the RRC Reconfiguration message (step S201). An example of including the configuration information in the RRC Release message (step S203) will be described below. When configuring the UE 100 to monitor the MCCH, the gNB 200 may include the MCCH configuration to be transmitted in the SIB 20 in a dedicated RRC message (RRC Release message or RRC Reconfiguration message) and transmit the message to the UE 100.

[0081] In step S204, in response to the reception of the RRC Release message in step S203, the UE 100 transitions from the RRC connected state to the RRC inactive state.

[0082] In step S205, the UE 100 in the RRC inactive state checks whether or not it is set to perform MCCH monitoring in step S203.

[0083] If MCCH monitoring is configured (step S205: YES), in step S206, UE 100 in the RRC inactive state monitors the MCCH and receives the MCCH (multicast configuration). Note that UE 100 receives SIB20 before receiving the MCCH, and monitors and receives the MCCH based on SIB20. UE 100 receives multicast data on MTCH via a multicast session based on the received MCCH (step S207). UE 100 may receive MCCH after receiving MTCH. That is, MCCH reception (step S206) and MTCH reception (step S207) may be performed in parallel.

[0084] On the other hand, if MCCH monitoring is not configured (step S205: NO), in step S207, UE100 in the RRC inactive state receives multicast data on the MTCH via the multicast session without monitoring the MCCH, continuing to use the multicast configuration of step S201.

[0085] This modification may be based on the operation according to the above-described embodiment. That is, the multicast setting in step S201 (first multicast setting) and the multicast setting in step S205 (second multicast setting) may each include a reference identifier, and the second multicast setting may update the variable parameter value of the first multicast setting.

[0086] (Other embodiments) In the above-described embodiment, multicast reception in the RRC inactive state has been mainly described, but the operation according to the above-described embodiment may also be applied to multicast reception in the RRC idle state. That is, the "RRC inactive state" in the operation according to the above-described embodiment and its modifications may be read as the "RRC idle state." In the RRC idle state, RRC Resume is read as RRC Establishment.

[0087] The above-described operational flows are not limited to being implemented independently, but can also be implemented by combining two or more operational flows. For example, some steps of one operational flow may be added to another operational flow, or some steps of one operational flow may be replaced with some steps of another operational flow. In each flow, it is not necessary to execute all steps, and only some steps may be executed.

[0088] In the above-described embodiment and example, an example in which the base station is an NR base station (gNB) has been described, but the base station may be an LTE base station (eNB) or a 6G base station. The base station may also be a relay node such as an IAB (Integrated Access and Backhaul) node. The base station may also be a DU of the IAB node. The UE 100 may also be an MT (Mobile Termination) of the IAB node.

[0089] Also, the term "network node" primarily refers to a base station, but may also refer to a device in the core network or part of a base station (CU, DU, or RU).

[0090] A program may be provided that causes a computer to execute each process performed by UE100 or gNB200. The program may be recorded on a computer-readable medium. The computer-readable medium can be used to install the program 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. Furthermore, 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).

[0091] As used in this disclosure, the terms "based on" and "depending on / in response to" do not mean "based only on" or "depending only on," unless expressly stated otherwise. The term "based on" means both "based only on" and "based at least in part on." Similarly, the term "depending on" means both "depending only on" and "depending at least in part on." The terms "include," "comprise," and variations thereof do not mean including only the listed items, but may mean including only the listed items or may include additional items in addition to the listed items. Additionally, the term "or," as used in this disclosure, is not intended to mean an exclusive or. Furthermore, any reference to elements using designations such as "first," "second," etc., as used in this disclosure does not generally limit the quantity or order of those elements. These designations may be used herein as a convenient method of distinguishing between two or more elements. Thus, a reference to a first and a second element does not imply that only two elements may be employed therein or that the first element must precede the second element in some way. In this disclosure, where articles are added by translation, such as a, an, and the in English, these articles shall include the plural unless the context clearly indicates otherwise.

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

[0093] This application claims priority from Japanese Patent Application No. 2022-155399 (filed September 28, 2022), the entire contents of which are incorporated herein by reference.

[0094] (Addendum) The following additional notes are about the features of the above-described embodiment.

[0095] (Appendix 1) A communication method used in a mobile communication system that provides a multicast / broadcast service (MBS), comprising: receiving, by a user equipment in a Radio Resource Control (RRC) Connected state, a first multicast configuration from a network node in a dedicated RRC message, the first multicast configuration including a reference identifier, fixed parameter values ​​and variable parameter values; the user equipment having transitioned from the RRC connected state to the RRC inactive state receiving a second multicast configuration from the network node via a multicast control channel (MCCH), the second multicast configuration including the reference identifier and a new variable parameter value; The user equipment in the RRC inactive state transfers the variable parameter value received in the dedicated RRC message to the new variable parameter value received on the MCCH based on the reference identifier. Weird Party and updating the parameter value. Communication method.

[0096] (Appendix 2) The method further comprises the step of the user equipment in the RRC inactive state receiving multicast data from the network node via a multicast session based on the fixed parameter values ​​and the new variable parameter values. 1. A communication method as described in Appendix 1.

[0097] (Appendix 3) The method further includes receiving information from the network node that specifies at least one of a parameter type of a fixed parameter that is not updated by the MCCH and a parameter type of a variable parameter that can be updated by the MCCH. 3. A communication method according to claim 1 or 2.

[0098] (Appendix 4) The fixed parameter value includes at least one of a Temporary Mobile Group Identity (TMGI) and a Group Radio Network Temporary Identifier (G-RNTI). 4. A communication method according to any one of claims 1 to 3.

[0099] (Appendix 5) The variable parameter value includes at least one of a transmission period and a transmission duration of a multicast traffic channel (MTCH). 5. A communication method according to any one of claims 1 to 4.

[0100] (Appendix 6) A communication method used in a mobile communication system that provides a multicast / broadcast service (MBS), comprising: A user equipment (UE) in a radio resource control (RRC) connected state and having joined a multicast session receives, from a network node, configuration information for configuring whether the UE monitors a multicast control channel (MCCH) in an RRC inactive state; The user equipment that has transitioned from the RRC connected state to the RRC inactive state monitors the MCCH based on the configuration information. Communication method.

[0101] (Appendix 7) The method further comprises the step of the user equipment in the RRC connected state transitioning from the RRC connected state to the RRC inactive state in response to receiving an RRC release message from the network node; The configuration information is information included in the RRC release message. 6. A communication method as set forth in Appendix 6.

[0102] (Appendix 8) The method further comprises receiving, by the user equipment in the RRC connected state, an RRC reconfiguration message from the network node, the RRC reconfiguration message including a multicast configuration required for receiving the multicast session; The configuration information is information included in the RRC reconfiguration message. 6. A communication method as set forth in Appendix 6. [Explanation of symbols]

[0103] 1: Mobile communication system 10:RAN 20 :CN 100: UE (user equipment) 110: Receiving unit 120: Transmitter 130: Control unit 200:gNB (base station) 210: Transmission unit 220: Receiving unit 230: Control unit 240: Backhaul communication unit

Claims

1. A communication method for use in a mobile communication system that provides a multicast / broadcast service (MBS), comprising: receiving, from a network node, a radio resource control (RRC) release message for allowing a user equipment in a radio resource control (RRC) connected state and having joined a multicast session to receive the multicast session in an RRC inactive state; The user equipment transitions from the RRC connected state to the RRC inactive state in response to receiving the RRC Release message; The user equipment that has transitioned to the RRC inactive state receives a multicast control channel from the network node when the received RRC Release message does not include predetermined information; and the user equipment that has transitioned to the RRC inactive state receives a multicast traffic channel from the network node when the received RRC Release message includes the predetermined information. Communication method.

2. receiving the multicast traffic channel The user equipment that has transitioned to the RRC inactive state receives the multicast traffic channel even if it does not receive the multicast control channel when the predetermined information is included in the received RRC Release message. The communication method according to claim 1 .

3. A user equipment for use in a mobile communication system providing a multicast / broadcast service (MBS), comprising: a receiving unit that receives, from a network node, an RRC Release message that allows the user equipment, which is in a Radio Resource Control (RRC) connected state and has joined a multicast session, to receive the multicast session in an RRC inactive state; a control unit that transitions the user equipment from the RRC connected state to the RRC inactive state in response to reception of the RRC Release message, The receiving unit If the received RRC Release message does not include predetermined information after the user equipment transitions to the RRC inactive state, receiving a multicast control channel from the network node; After the user equipment transitions to the RRC inactive state, if the received RRC Release message includes the predetermined information, the user equipment receives a multicast traffic channel from the network node. User equipment.

4. A mobile communication system providing a multicast / broadcast service (MBS), comprising: receiving, from a network node, an RRC Release message for allowing a user equipment in a Radio Resource Control (RRC) connected state and having joined a multicast session to receive the multicast session in an RRC inactive state; The user equipment transitions from the RRC connected state to the RRC inactive state in response to receiving the RRC Release message; When the received RRC Release message does not include predetermined information, the user equipment that has transitioned to the RRC inactive state receives a multicast control channel from the network node; The user equipment that has transitioned to the RRC inactive state receives a multicast traffic channel from the network node if the received RRC Release message includes the predetermined information. Mobile communication system.

5. A user equipment for use in a mobile communication system providing a multicast / broadcast service (MBS), receiving, from a network node, a Radio Resource Control (RRC) Release message for allowing the user equipment, which is in a Radio Resource Control (RRC) Connected state and has joined a multicast session, to receive the multicast session in an RRC Inactive state; A process of transitioning the user equipment from the RRC connected state to the RRC inactive state in response to receiving the RRC Release message; receiving a multicast control channel from the network node if the received RRC Release message does not include predetermined information after the user equipment transitions to the RRC inactive state; and receiving a multicast traffic channel from the network node if the predetermined information is included in the received RRC Release message after the user equipment transitions to the RRC inactive state. program.

6. A chipset for a user equipment for use in a mobile communication system providing a multicast / broadcast service (MBS), comprising: receiving, from a network node, a Radio Resource Control (RRC) Release message for allowing the user equipment, which is in a Radio Resource Control (RRC) Connected state and has joined a multicast session, to receive the multicast session in an RRC Inactive state; transitioning the user equipment from the RRC connected state to the RRC inactive state in response to receiving the RRC Release message; receiving a multicast control channel from the network node if the received RRC Release message does not include predetermined information after the user equipment transitions to the RRC inactive state; and receiving a multicast traffic channel from the network node if the received RRC Release message includes the predetermined information after the user equipment transitions to the RRC inactive state. Chipset.

Images