Communication methods, user devices, mobile communication systems, programs, and chipsets

Abstract

This provides a communication method that improves multicast / broadcast services (MBS). [Solution] In a mobile communication system, the communication method includes the steps of: a user device 100 in a radio resource control (RRC) connected state receiving a first multicast setting including a reference identifier, fixed parameter values, and variable parameter values ​​from a network node in a dedicated RRC message; a user device that has transitioned from an RRC connected state to an RRC inactive state receiving a second multicast setting including a reference identifier and new variable parameter values ​​from a network node via a multicast control channel (MCCH); and a user device in an RRC inactive state updating the variable parameter values ​​received in the dedicated RRC message to the new variable setting parameter values ​​received via the MCCH, based on the reference identifier.

Description

Technical Field

[0001] This disclosure relates to a communication method used in a mobile communication system.

Background Art

[0002] In 3GPP (3rd Generation Partnership Project) (registered trademark; the same applies hereinafter), the technical specifications of NR (New Radio), which is a 5th generation (5G) radio access technology, are defined. NR has characteristics such as high speed, large capacity, high reliability, and low latency compared to LTE (Long Term Evolution), which is a 4th generation (4G) radio access technology. In 3GPP, the technical specifications of 5G / NR's multicast / broadcast service (MBS) are defined (see, for example, Non-Patent Document 1).

Prior Art Documents

Non-Patent Documents

[0003]

Non-Patent Document 1

Summary of the Invention

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

[0005] A communication method according to a second embodiment is a communication method used in a mobile communication system that provides multicast / broadcast services (MBS), comprising the steps of: a user device that is in a radio resource control (RRC) connected state and has already joined a multicast session receiving configuration information from a network node to determine whether or not the user device monitors the multicast control channel (MCCH) when the RRC is inactive; and the user device 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 drawing]

[0006] [Figure 1] This diagram shows the configuration of a mobile communication system according to an embodiment. [Figure 2] This diagram shows the configuration of the UE (User Equipment) according to the embodiment. [Figure 3] This diagram shows the configuration of the gNB (base station) according to the 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 diagram shows the operation required for a UE in an RRC inactive state to perform multicast reception. [Figure 7] This figure shows an example of the operation of the mobile communication system according to the embodiment. [Figure 8] This figure shows an example of the operation of a mobile communication system related to the changes. [Modes for carrying out the invention]

[0007] A mobile communication system according to an embodiment will be described with reference to the drawings. In the drawings, identical or similar parts are denoted by the same or similar reference numerals.

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

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

[0010] UE100 is a mobile wireless communication device. UE100 can be any device used by a user. For example, UE100 can be a mobile phone terminal (including smartphones) and / or a tablet terminal, a notebook PC, a communication module (including a communication card or chipset), a sensor or device attached to a sensor, a vehicle or device attached to a vehicle (Vehicle UE), or an aircraft or device attached to an aircraft (Aerial UE).

[0011] 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 (hereinafter simply referred to as "frequency").

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

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

[0014] Figure 2 shows the configuration of UE100 (user device) according to an embodiment. UE100 comprises 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 gNB200.

[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 the radio signal received by the antenna into a baseband signal (received signal) and outputs it to the control unit 130.

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

[0017] The control unit 130 performs various controls and processes in the UE 100. Such processes include the processes of each layer described later. 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 for 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, etc. The CPU executes programs stored in the memory to perform various processes.

[0018] FIG. 3 is a diagram showing the configuration of the gNB 200 (base station) according to the embodiment. The gNB 200 includes a transmission unit 210, a reception unit 220, a control unit 230, and a backhaul communication unit 240. The transmission unit 210 and the reception unit 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 communicates 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 the baseband signal (transmission signal) output by the control unit 230 into a wireless signal and transmits it from the antenna.

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

[0021] The control unit 230 performs various controls and processes in the gNB 200. Such processes include the processes of each layer 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 for 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 an adjacent base station via the Xn interface which is an interface between base stations. The backhaul communication unit 240 is connected to the AMF / UPF 300 via the NG interface which is an interface between the base station and the core network. Note that the gNB 200 is composed of a CU (Central Unit) and a DU (Distributed Unit) (that is, functionally split), and the two units may be connected by the F1 interface which is a front haul interface.

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

[0024] The radio interface protocol of the user plane 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.

[0025] 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. The UE100's PHY layer receives downlink control information (DCI) transmitted from the gNB200 over the physical downlink control channel (PDCCH). Specifically, the UE100 performs blind decoding of the PDCCH using a Radio Network Temporary Identifier (RNTI) and acquires the successfully decoded DCI as the DCI addressed to its own UE. The DCI transmitted from the gNB200 has a CRC parity bit added, which is scrambled by the RNTI.

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

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

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

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

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

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

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

[0033] 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 AMF300A's NAS layer. The UE100 also has application layers and other components in addition to its wireless interface protocol. Furthermore, layers below the NAS layer are referred to as the AS layer.

[0034] (Overview of MBS) Mobile communication system 1 can perform resource-efficient distribution through multicast / broadcast services (MBS).

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

[0036] In the case of broadcast communication services (also known as "MBS broadcast"), the same service and the same specific content data are provided simultaneously to all UE100s within a geographical area. That is, all UE100s within the broadcast service area are permitted to receive the data. The broadcast communication service is delivered to the UE100s using a broadcast session, which is a type of MBS session. The UE100s can receive the broadcast communication service in any of the following states: RRC idle, RRC inactive, and RRC connected. This delivery mode is also known as "delivery mode 2".

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

[0038] Regarding the settings for MBS broadcasts, UE100 in the RRC idle, RRC inactive, or RRC connected state receives MBS settings for broadcast sessions (e.g., parameters required for MTCH reception) via MCCH. The parameters required for MCCH reception (MCCH settings) are provided via system information. Specifically, system information block type 20 (SIB20) contains the MCCH settings. SIB type 21 (SIB21) contains information regarding the continuity of service for MBS broadcast reception. MCCH provides a list of all broadcast services, including ongoing sessions transmitted via MTCH. The relevant information for broadcast sessions includes the MBS session ID (e.g., TMGI (Temporary Mobile Group Identity)), relevant MTCH scheduling information, and information about neighboring cells providing specific services via MTCH.

[0039] On the other hand, with regard to MBS multicast, the current 3GPP technical specifications stipulate that the UE100 can only receive multicast session data when it is in the RRC Connected state. If a UE100 participating in a multicast session is in the RRC Connected state and the multicast session is activated, the gNB200 sends an RRC Reconfiguration message to the UE100 that includes the MBS settings for that multicast session. Such MBS settings are also referred to as multicast radio bearer (MRB) settings, MTCH settings, or multicast settings. Such MRB settings (MRB-ToAddMod) include the MBS session ID (mbs-SessionId), MRB ID (mrb-Identity), and other parameters such as PDCP settings (pdcp-Config) for the MRB (multicast MRB) to be configured on the UE100.

[0040] The following embodiment primarily describes an operation that enables a UE100 in an RRC inactive state to perform multicast reception. Figure 6 is a diagram illustrating an overview of this operation.

[0041] Two possible solutions for a UE100 in an RRC inactive state to perform multicast reception are the distribution mode 1-based solution shown in Figure 6(a) and the distribution mode 2-based solution shown in Figure 6(b).

[0042] In the distribution mode 1-based solution shown in Figure 6(a), in step S1, the gNB200 sends an RRC Reconfiguration message to the RRC-connected UE100, which includes the MBS settings (multicast settings) for the multicast session. Based on the multicast settings received in the RRC Reconfiguration message, the UE100 receives multicast data on the MTCH via the multicast session (multicast MRB).

[0043] In step S2, gNB200 sends an RRC Release message to UE100, which is in the RRC Connected state, to transition UE100 to the RRC Inactive state. This RRC Release message includes the settings for the RRC Inactive state (Suspend Config.).

[0044] In step S3, UE100 transitions from the RRC connected state to the RRC inactive state in response to receiving the RRC Release message in step S2.

[0045] In step S4, the UE100, which is in an RRC inactive state, continues to use the multicast settings from step S1 to receive multicast data on the MTCH via the multicast session.

[0046] This allows the UE100, which is in an RRC inactive state, to receive multicast traffic. While this example demonstrates multicast configuration using the RRC Reconfiguration message, multicast configuration can also be performed using the RRC Release message.

[0047] Both RRC Reconfiguration messages and RRC Release messages are RRC messages transmitted individually to each UE over the dedicated control channel (DCCH), and are hereafter referred to as dedicated RRC messages.

[0048] On the other hand, in the delivery mode 2-based solution shown in Figure 6(b), in step S11, the gNB200 sends an RRC Release message to the UE100 in the RRC connected state to transition the UE100 to the RRC inactive state. This RRC Release message includes a setting for the RRC inactive state (Suspend Config.).

[0049] In step S12, UE100 transitions to the RRC inactive state in response to receiving the RRC Release message in step S11.

[0050] In step S13, gNB200 transmits an MCCH containing the MBS settings (multicast settings) for the multicast session. UE100 receives the MCCH. Prior to receiving the MCCH, UE100 receives an SIB20 and receives the MCCH based on the SIB20. The transmission (and reception) of the MCCH may occur before step S11 or simultaneously with step S11.

[0051] In step S14, the UE100, which is in an RRC inactive state, receives multicast data on the MTCH via the multicast session based on the multicast settings received on the MCCH in step S13. This enables the UE100, which is in an RRC inactive state, to perform multicast reception.

[0052] (Example of system operation) In this embodiment, a distribution mode 1-based solution and a distribution mode 2-based solution are combined to enable the UE100, which is in an RRC inactive state, to efficiently receive multicast traffic.

[0053] Specifically, firstly, when UE100 is in the RRC Connected state, it receives the multicast configuration (first multicast configuration) via a dedicated RRC message. Secondly, UE100 transitions from the RRC Connected state to the RRC Inactive state. In the RRC Inactive state, UE100 may use the first multicast configuration to receive multicast traffic until it receives the second multicast configuration. Thirdly, when UE100 is in the RRC Inactive state, it receives the multicast configuration (second multicast configuration) via MCCH.

[0054] As mentioned above, MBS multicast can only be received by specific UE groups (specific sets of UEs). Multicast configuration includes parameter values ​​such as identifiers for multicast sessions (multicast services) received by specific UE groups, for example, at least one of TMGI (Temporary Mobile Group Identity) and G-RNTI (Group Radio Network Temporary Identifier).

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

[0056] In this embodiment, parameter values ​​requiring security are set in a dedicated RRC message, and the MCCH transmits parameter values ​​other than those parameter values. That is, parameter values ​​requiring security are not transmitted by the MCCH, and the parameter values ​​transmitted in the dedicated RRC message are continuously used. Hereinafter, the parameter values ​​that are continuously used will also be referred to as fixed parameter values. On the other hand, parameter values ​​that are transmitted in the dedicated RRC message and the MCCH and are updatable will also be referred to as variable parameter values.

[0057] Figure 7 shows an example of the operation of the mobile communication system 1 according to the embodiment. Prior to this operation, it is assumed that UE100 has already joined a multicast session. Furthermore, it is assumed that UE100 is receiving multicast data or will receive multicast data while in an RRC connected state.

[0058] In step S101, gNB200 sends a dedicated RRC message to UE100 in the RRC connected state containing a first multicast configuration, which includes a reference identifier, fixed parameter values ​​not updated by MCCH, and variable parameter values ​​that may be updated by MCCH. In other words, gNB200 configures the first multicast configuration individually for each UE. UE100 receives the dedicated RRC message containing the first multicast configuration from gNB200 and stores the first multicast configuration. Part of the first multicast configuration may be updated by MCCH. Therefore, the first multicast configuration can be considered as the base multicast configuration. Note that some or all of the variable parameter values ​​that may be updated by MCCH do not need to 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 and second multicast configurations, UE100 becomes able to receive multicast (MTCH).

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

[0060] The reference identifier is an identifier that can identify the multicast configuration and is an identifier other than TMGI and G-RNTI. The reference identifier may be an MRB identifier (MRB ID). However, since the MRB ID is UE-specific, a new identifier specific 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 the transmission period and transmission duration of the MTCH associated with the multicast session. The variable parameter value may also include the PDSCH setting of the MTCH. The variable parameter value may include at least one of the following as defined in the 3GPP technical specification: drx-ConfigPTM-List, pdsch-ConfigMTCH, mtch-SSB-MappingWindowList, mtch-SchedulingInfo, pdsch-ConfigIndex, mtch-SSB-MappingWindowIndex, and drx-ConfigPTM.

[0063] Here, which parameters (specifically, which information elements in the first multicast configuration) are fixed parameters or variable parameters may be predetermined in the technical specifications, or they may be determined by the settings of the gNB200. In the latter case, the gNB200 may, for example in step S101, send information to the UE100 specifying at least one of the parameter types of fixed parameters and the parameter types of variable parameters. Based on this information, the UE100 determines 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, gNB200 may transmit multicast data over the MTCH via the multicast session based on the first multicast configuration in step S101. UE100 may receive multicast data over the MTCH via the multicast session based on the first multicast configuration in step S101.

[0065] In step S103, gNB200 decides to transition UE100 from the RRC connected state to the RRC inactive state and sends an RRC Release message containing "Suspend config." to UE100. UE100 receives the RRC Release message. Note that the first multicast configuration described above may be included in the RRC Release message. In that case, step S101 may be unnecessary.

[0066] In step S104, UE100 transitions from the RRC connected state to the RRC inactive state in response to receiving the RRC Release message in step S103.

[0067] In step S105, gNB200 may transmit multicast data over the MTCH via the multicast session based on the first multicast configuration in step S101. UE100, having transitioned to the RRC inactive state, may receive multicast data over the MTCH via the multicast session based on the first multicast configuration in step S101.

[0068] In step S106, the gNB200 decides to update the multicast settings (first multicast settings) configured 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 also decide to change the transmission duration of the MTCH. Transmission duration refers to the time that a single MTCH transmission lasts according to the transmission period.

[0069] In step S107, gNB200 sends a second multicast configuration, including a reference identifier and new variable parameter values, to UE100 on the MCCH. UE100, in an RRC inactive state, receives the second multicast configuration.

[0070] The reference identifier in the second multicast configuration is an identifier used to identify the first multicast configuration described above, and is either an MRB identifier or a newly defined identifier. The new variable parameter values ​​in the second multicast configuration are the updated parameter values ​​of the variable parameter values ​​in the first multicast configuration. However, parameter values ​​that are not updated among the variable parameter values ​​do not need to be included in the second multicast configuration.

[0071] The second multicast configuration does not include fixed parameter values, such as TMGI and / or G-RNTI. This helps to prevent security issues. For example, it makes it easier to avoid situations where a UE100 that is not participating in the multicast session attempts to receive that multicast session. Also, because TMGI has a large number of bits, not transmitting TMGI over the MCCH contributes to reducing MCCH overhead.

[0072] In step S108, the RRC-inactive UE100 updates the variable parameter values ​​received in the dedicated RRC message (first multicast configuration) with the new variable parameter values ​​received in the MCCH (second multicast configuration), based on the reference identifier (i.e., using the reference identifier as the key). In other words, the UE100 maintains the stored fixed parameter values ​​while overwriting the stored variable parameter values ​​with the new variable parameter values. Thus, if the RRC-inactive UE100 finds a reference identifier in the second multicast configuration (MCCH) that matches the reference identifier in the currently stored multicast configuration, it applies the parameters updated in the MCCH to the base multicast configuration.

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

[0074] (Example of changes to behavior) An example of a modification to the operation according to the above embodiment will be described. In the above embodiment, it was assumed that after multicast configuration was performed with a dedicated RRC message, the UE100, which was in an RRC inactive state, would monitor the MCCH.

[0075] However, in cases where the multicast settings configured in the dedicated RRC message are not subsequently updated, the UE100 may unnecessarily consume power by monitoring the MCCH. Therefore, in this modification example, the gNB200 will be able to configure whether or not the UE100 should monitor the MCCH. Specifically, the gNB200 will configure whether or not the UE100 should monitor the MCCH while receiving multicast in an RRC inactive state.

[0076] Figure 8 shows an example of the operation of the mobile communication system 1 in relation to this modification example. Prior to this operation, it is assumed that UE100 has already joined the multicast session. Also, it is assumed that UE100 is receiving multicast data or will receive multicast data while in an RRC connected state. Here, redundant explanations of operations similar to those described above are omitted.

[0077] In step S201, gNB200 sends the multicast configuration to UE100, which is in the RRC connected state, as a dedicated RRC message (in the illustrated example, an RRC Reconfiguration message; however, an RRC Release message (step S203) may also be used). UE100 receives the multicast configuration as a dedicated RRC message.

[0078] In step S202, gNB200 may send multicast data over the MTCH via the multicast session based on the multicast settings in step S201. UE100 may receive multicast data over the MTCH via the multicast session based on the multicast settings in step S201.

[0079] In step S203, gNB200 decides to transition UE100 from the RRC connected state to the RRC inactive state and sends an RRC Release message containing "Suspend config." to UE100. UE100 receives the RRC Release message.

[0080] In the illustrated example, gNB200 includes configuration information in the RRC Release message that determines whether UE100 monitors the MCCH when the RRC is inactive. That is, the RRC Release message includes configuration information that specifies whether or not the MCCH should be received when multicast reception is performed (or when waiting) in the RRC inactive state. Note that instead of including this configuration information in the RRC Release message (step S203), it may be included in the RRC Reconfiguration message (step S201). Below, an example of including this configuration information in the RRC Release message (step S203) will be described. When gNB200 configures UE100 to monitor the MCCH, it may include the MCCH setting transmitted by SIB20 in a dedicated RRC message (RRC Release message or RRC Reconfiguration message) and send it to UE100.

[0081] In step S204, UE100 transitions from the RRC connected state to the RRC inactive state in response to receiving the RRC Release message in step S203.

[0082] In step S205, it is checked whether the UE100, which is in an RRC inactive state, was configured in step S203 to perform MCCH monitoring.

[0083] If MCCH monitoring is configured (step S205: YES), in step S206, the UE100, which is in an RRC inactive state, monitors the MCCH and receives the MCCH (multicast setting). Prior to receiving the MCCH, the UE100 receives the SIB20 and monitors and receives the MCCH based on the SIB20. Based on the received MCCH, the UE100 receives multicast data on the MTCH via the multicast session (step S207). The UE100 may receive the MCCH after receiving the MTCH. In other words, MCCH reception (step S206) and MTCH reception (step S207) may be performed in parallel.

[0084] On the other hand, if MCCH monitoring is disabled (step S205: NO), in step S207, the UE100 in the RRC inactive state will continue to use the multicast settings from step S201 to receive multicast data on the MTCH via the multicast session without performing MCCH monitoring.

[0085] This example of modification may be based on the operation of the embodiment described above. 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 values ​​of the first multicast setting.

[0086] (Other embodiments) In the embodiments described above, multicast reception in the RRC inactive state was mainly explained, but the operation according to the embodiments described above may also be applied to multicast reception in the RRC idle state. That is, "RRC inactive state" in the operation according to the embodiments described above and its modified examples may be read as "RRC idle state". In the case of the RRC idle state, RRC Resume is read as RRC Establishment.

[0087] 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. It is not necessary to execute all steps in each flow; only some steps may be executed.

[0088] In the embodiments and examples described above, an example in which the base station is an NR base station (gNB) was described, but the base station may also be an LTE base station (eNB) or a 6G base station. Furthermore, 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 an IAB node. Furthermore, UE100 may be an MT (Mobile Termination) of an IAB node.

[0089] Furthermore, the term "network node" primarily refers to a base station, but may also refer to a core network device or a 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 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).

[0091] The phrases “based on” and “depending on / in response to” used in this disclosure do not mean “based solely on” or “depending solely on” unless otherwise specified. “Based on” means both “based solely on” and “at least partially on.” Similarly, “depending on” means both “at least partially on” and “at least partially on.” The terms “include,” “comprise,” and variations thereof do not mean that only the listed items are included; they mean that only the listed items may be included, or that additional items may be included in addition to the listed items. Furthermore, the term “or” used in this disclosure is not intended to mean exclusive OR. Additionally, any reference to elements using designations such as “first,” “second,” etc., used in this disclosure does not generally limit the quantity or order of those elements. 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 adopted 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 by the context that they are not.

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

[0093] This application claims priority to Japanese Patent Application No. 2022-155399 (filed September 28, 2022), and all of its contents are incorporated into the specification of this application.

[0094] (Note) The features of the above-described embodiment are noted below.

[0095] (Note 1) A communication method used in a mobile communication system that provides multicast / broadcast services (MBS), The steps include: a user device in a Radio Resource Control (RRC) connected state receiving a first multicast configuration from a network node in a dedicated RRC message, which includes a reference identifier, fixed parameter values, and variable parameter values; The user device, which has transitioned from the RRC connected state to the RRC inactive state, receives a second multicast configuration, including the reference identifier and new variable parameter values, from the network node via the multicast control channel (MCCH). The user device in the RRC inactive state updates the variable parameter value received in the dedicated RRC message to the new variable parameter value received by the MCCH, based on the reference identifier. Communication method.

[0096] (Note 2) The user device in the RRC inactive state further has the step of receiving multicast data from the network node via a multicast session based on the fixed parameter value and the new variable parameter value. The communication method described in Appendix 1.

[0097] (Note 3) The further step includes receiving information from the network node specifying at least one of the parameter types of fixed parameters that are not updated by the MCCH and the parameter types of variable parameters that can be updated by the MCCH. The communication method described in Appendix 1 or 2.

[0098] (Note 4) The aforementioned fixed parameter value includes at least one of TMGI (Temporary Mobile Group Identity) and G-RNTI (Group Radio Network Temporary Identifier). The communication method described in any of the appendices 1 to 3.

[0099] (Note 5) The variable parameter value includes at least one of the transmission period and transmission duration of the multicast traffic channel (MTCH). The communication method described in any of the appendices 1 to 4.

[0100] (Note 6) A communication method used in a mobile communication system that provides multicast / broadcast services (MBS), The steps include: a user device that is in a Wireless Resource Control (RRC) connected state and has joined a multicast session receiving configuration information from a network node to determine whether or not the user device monitors the multicast control channel (MCCH) when the RRC is inactive; The user device, which has transitioned from the RRC connected state to the RRC inactive state, monitors the MCCH based on the setting information. Communication method.

[0101] (Note 7) The user device in the RRC connected state further includes the step of transitioning from the RRC connected state to the RRC inactive state in response to receiving an RRC release message from the network node. The aforementioned configuration information is the information contained in the RRC release message. The communication method described in Appendix 6.

[0102] (Note 8) The user device in the RRC connected state further includes the step of receiving an RRC reconfiguration message from the network node, which includes multicast settings necessary for receiving the multicast session. The aforementioned configuration information is the information included in the RRC reset message. The communication method described in Appendix 6. [Explanation of Symbols]

[0103] 1: Mobile communication systems 10: RAN 20 :CN 100: UE (User Device) 110: Receiver 120: Transmitter 130: Control Unit 200:gNB (base station) 210: Transmitter 220: Receiving unit 230: Control Unit 240: Backhaul Communications Department

Claims

1. A communication method used in a mobile communication system that provides multicast / broadcast services (MBS), The user device receives a Wireless Resource Control (RRC) Release message from a network node, The user device transitions from the RRC connected state to the RRC inactive state in response to receiving the RRC Release message. If the user device that has transitioned to the RRC inactive state does not contain predetermined information in the received RRC Release message, it will receive a multicast control channel from the network node. The user device that has transitioned to the RRC inactive state receives a multicast traffic channel from the network node if the received RRC Release message contains the predetermined information. Communication method.

2. A user device used in a mobile communication system that provides multicast / broadcast services (MBS), A receiver unit that receives a Wireless Resource Control (RRC) Release message from a network node, The system includes a control unit that, in response to the receipt of the RRC Release message, transitions the user device from an RRC connected state to an RRC inactive state, The receiving unit is If, after the user device transitions to the RRC inactive state, the received RRC Release message does not contain predetermined information, the multicast control channel is received from the network node. After the user device transitions to the RRC inactive state, if the received RRC Release message contains the predetermined information, a multicast traffic channel is received from the network node. User device.

3. A mobile communication system that provides multicast / broadcast services (MBS), Radio Resource Control (RRC) receives a Release message from a network node. The user device, upon receiving the RRC Release message, transitions from the RRC Connected state to the RRC Inactive state. If the user device that has transitioned to the RRC inactive state does not contain predetermined information in the received RRC Release message, it receives a multicast control channel from the network node. If the user device that has transitioned to the RRC inactive state receives the predetermined information in the received RRC Release message, it receives a multicast traffic channel from the network node. Mobile communication system.

4. User equipment used in mobile communication systems that provide multicast / broadcast services (MBS), The process involves receiving a Release message from a network node in Radio Resource Control (RRC), The process involves transitioning the user device from the RRC connected state to the RRC inactive state in response to the receipt of the RRC Release message, If, after the user device transitions to the RRC inactive state, the received RRC Release message does not contain predetermined information, the process of receiving a multicast control channel from the network node is performed. After the user device transitions to the RRC inactive state, if the received RRC Release message contains the predetermined information, the device will perform the process of receiving a multicast traffic channel from the network node. program.

5. A chipset for user equipment used in a mobile communication system that provides multicast / broadcast services (MBS), Radio Resource Control (RRC) involves receiving a Release message from a network node, In response to receiving the RRC Release message, the user device is transitioned from the RRC connected state to the RRC inactive state. If, after the user device transitions to the RRC inactive state, the received RRC Release message does not contain predetermined information, the multicast control channel is received from the network node. After the user device transitions to the RRC inactive state, if the received RRC Release message contains the predetermined information, it will receive a multicast traffic channel from the network node and perform the following actions: Chipset.

Images