Communication control method, user equipment, base station, mobile communication system, program, and chipset

Abstract

To provide improved multicast and broadcast services. [Solution] The first aspect of the communication control method is a communication control method used in a mobile communication system that provides a multicast broadcast service (MBS). The communication control method comprises: a user device in an RRC (Radio Resource Control) connected state receiving multicast data, which is MBS data transmitted by multicast, from a base station; and the user device, which does not support receiving the multicast data in an RRC inactive state, transmitting status information to the base station indicating the RRC connected state as the RRC state desired by the user device.

Description

Technical Field

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

Background Art

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

Prior Art Documents

Non-Patent Documents

[0003]

Non-Patent Document 1

Summary of the Invention

[0004] The communication control method according to the first aspect is a communication control method used in a mobile communication system that provides a multicast / broadcast service (MBS). The communication control method includes: a user device in the RRC connected state receiving multicast data, which is MBS data transmitted by multicast, from a base station; and when the user device supports receiving the multicast data in the RRC inactive state, the user device transmitting state information indicating the RRC inactive state as the RRC state desired by the user device to the base station.

[0005] The second aspect of the communication control method is a communication control method used in a mobile communication system that provides a multicast broadcast service (MBS). The communication control method comprises: a user device in an RRC connected state receiving multicast data, which is MBS data transmitted by multicast, from a base station; the user device receiving a request from the base station to transition to an RRC inactive state; and the user device transmitting an acknowledgment to the base station if the user device supports receiving the multicast data in the RRC inactive state.

[0006] A third aspect of the communication control method is a communication control method used in a mobile communication system that provides multicast broadcast services (MBS). The communication control method includes, if the user device supports receiving multicast data in an RRC inactive state, transmitting capability information to a base station indicating that the user device supports receiving multicast data in an RRC inactive state.

[0007] The user device according to the fourth embodiment includes a processor that executes a communication control method according to any one of the first to third embodiments. [Brief explanation of the drawing]

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

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

[0010] Therefore, this disclosure aims to realize improved multicast and broadcast services.

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

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

[0013] As shown in Figure 1, the mobile communication system includes User Equipment (UE) 100, a 5G Next Generation Radio Access Network (NG-RAN) 10, and a 5G Core Network (5GC) 20.

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

[0015] NG-RAN 10 includes base stations (referred to as "gNB" in the 5G system) 200. The gNBs 200 are interconnected via the Xn interface, which is an interface between base stations. The gNB 200 manages one or more cells. The gNB 200 performs wireless communication with the UE 100 that has established a connection with its cell. The gNB 200 has functions such as a radio resource management (RRM) function, a routing function for user data (hereinafter simply referred to as "data"), and a measurement control function for mobility control and scheduling. A "cell" is used as a term indicating the smallest unit of a wireless communication area. A "cell" is also used as a term indicating a function or resource for performing wireless communication with the UE 100. One cell belongs to one carrier frequency.

[0016] Note that the gNB can also be connected to the EPC (Evolved Packet Core), which is the core network of LTE. The base station of LTE can also be connected to the 5GC. The base station of LTE and the gNB can also be connected via an interface between base stations.

[0017] The 5GC 20 includes an AMF (Access and Mobility Management Function) and a UPF (User Plane Function) 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 performs transfer control of data. The AMF and the UPF are connected to the gNB 200 via the NG interface, which is an interface between the base station and the core network.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[0035] 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, SDAP is not required.

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

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

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

[0039] 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 AMF300B's NAS layer.

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

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

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

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

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

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

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

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

[0048] An MBS session includes multicast sessions and broadcast sessions.

[0049] A multicast session is a session for distributing multicast services. Multicast services provide services to a group of UE100s participating in the multicast session for applications requiring high reliability QoS. Multicast sessions are available to UE100s in an RRC connected state. Multicast sessions may also be available to UE100s in an RRC inactive state. In the following, MBS data transmitted via multicast (MBS data belonging to a multicast session) will be referred to as multicast data.

[0050] A broadcast session is a session for delivering broadcast services. Broadcast services provide services to all UE100s within a specific service area. Broadcast sessions are available to UE100s in all RRC states (RRC idle, RRC inactive, and RRC connected).

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

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

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

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

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

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

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

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

[0059] The gNB200 can configure the UE100 with an MBS bearer separated into a PTP communication path and a PTM communication path (hereinafter referred to as a "split MBS bearer" as appropriate). This allows the gNB200 to dynamically switch the transmission of MBS data to the UE100 between PTP (PTP communication path) and PTM (PTM communication path). Alternatively, the gNB200 can enhance reliability by using both PTP (PTP communication path) and PTM (PTM communication path) to transmit the same MBS data twice.

[0060] The predetermined layer terminating the split is a MAC layer (HARQ), an RLC layer, a PDCP layer, or an SDAP layer. The following explanation will primarily focus on an example where the predetermined layer terminating the split is a PDCP layer. However, the predetermined layer may also be a MAC layer (HARQ), an RLC layer, or an SDAP layer.

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

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

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

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

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

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

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

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

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

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

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

[0072] (Receiving multicast data while RRC is inactive) Next, we will describe the reception of multicast data in an RRC inactive state according to one embodiment.

[0073] In one embodiment, if UE100 supports receiving multicast data in the RRC inactive state (receive function), it continues to receive multicast data even when transitioning from the RRC connected state to the RRC inactive state. In this case, UE100 continues to apply the MBS settings provided by the RRC Reconfiguration message when in the RRC connected state as the MBS settings used in the RRC inactive state. That is, UE100 reuses the MBS settings provided when in the RRC connected state.

[0074] In other words, when UE100 is in the RRC Connected state, it receives an RRC Reconfiguration message (RRC message) from the base station that contains the MBS settings necessary for MBS reception. After transitioning from the RRC Connected state to the RRC Inactive state, UE100 performs MBS reception using the MBS settings received while in the RRC Connected state.

[0075] Such MBS settings may include basic reception settings, which are fundamental settings for MBS reception, and RRC connected-only settings, which are applicable only to MBS reception in the RRC connected state.

[0076] The basic receive settings are common to all RRC states (i.e., RRC Connected state, RRC Idle state, and RRC Inactive state). The basic receive settings include MTCH scheduling information. The MTCH scheduling information includes at least one of the following: group RNTI (G-RNTI), MBS session identifier, transmit occasion, and transmit BWP (Bandwidth Part).

[0077] Here, the group RNTI is the RNTI commonly assigned to a group of UE100s. The transmit occasion is a candidate timing (e.g., subframe) for the gNB200 to transmit MBS traffic using the MTCH. The transmit BWP is the BWP for which the gNB200 transmits MBS traffic using the MTCH. The BWP is a bandwidth portion narrower than the frequency bandwidth of a single cell, and is intended to limit the operating bandwidth of the UE100.

[0078] On the other hand, RRC Connected-only settings include settings related to the split MBS bearer, and for example, at least one of the following: split MBS bearer settings, dynamic switching settings between PTP and PTM, and PTP leg settings. Note that PTM leg settings can be used even in the RRC idle or RRC inactive state, and may therefore be included in the basic receive settings. RRC Connected-only settings may also include HARQ feedback settings.

[0079] (First action pattern) Next, a first operation pattern according to one embodiment will be described.

[0080] When the gNB200 transmits multicast data, congestion may occur, making it desirable to transition some of the UE100s receiving multicast data to an RRC inactive state. However, the gNB200 does not know which UE100s should be transitioned to the RRC inactive state. Congestion can occur, for example, due to uplink transmissions (uplink data, CSI (Channel State Information) feedback, etc.) by UE100s receiving multicast data. The congestion can be resolved by transitioning these UE100s to the RRC inactive state.

[0081] In the first operation pattern, if UE100 supports receiving multicast data in the RRC inactive state, UE100 sends status information to gNB200 indicating the RRC inactive state as the desired RRC state. As a result, gNB200 understands that it will not cause any problems to transition UE100 to the RRC inactive state, and can transition UE100 to the RRC inactive state if congestion occurs.

[0082] In the first operating pattern, if UE100 does not support receiving multicast data in the RRC inactive state, UE100 sends status information to gNB200 indicating the RRC connected state as the desired RRC state. As a result, gNB200 understands that UE100 should not be allowed to transition to the RRC inactive state, and will not allow UE100 to transition to the RRC inactive state even in congested conditions.

[0083] Figure 9 shows an example of operation of the first operation pattern according to one embodiment. In the initial state of Figure 9, UE100 is in the RRC connected state and the MBS setting is set from gNB200 to UE100.

[0084] As shown in Figure 9, in step S101, UE100 receives multicast data from gNB200. Specifically, UE100 receives multicast data using the MBS settings configured by gNB200.

[0085] In addition, UE100 may transmit uplink data associated with multicast data in step S102. The uplink data associated with multicast data is the uplink data associated with the multicast session to which the multicast data belongs. For example, if the multicast session corresponds to a group call service, the uplink data associated with the multicast session is the data corresponding to the utterances in that group call.

[0086] In step S103, UE100 decides to send state information to gNB200 indicating the preferred RRC state. For example, UE100 decides to send state information when normal unicast data transmission and reception are not expected. UE100 may also decide to send state information in response to instructions from gNB200. Such instructions may be a request for the transmission of preferred RRC state, or an inquiry for preferred RRC state. Such instructions may be transmitted via unicast signaling (using C-RNTI), multicast signaling (using G-RNTI), and / or broadcast signaling (using SI-RNTI). Note that SI (system Information)-RNTI is an RNTI used for transmitting and receiving system information blocks. UE100 may also decide to send state information when it is time to do so, if gNB200 has configured it to send state information periodically.

[0087] In step S104, UE100 determines whether it supports receiving multicast data in an RRC inactive state.

[0088] If UE100 determines that it supports receiving multicast data in an RRC inactive state (step S104: YES), in step S105, UE100 sends state information (Preferred RRC-state: inactive) to gNB200 indicating the RRC inactive state as the RRC state preferred by UE100. Such state information is sent, for example, in a UE Assistance Information message, which is a type of RRC message.

[0089] If it is determined that receiving multicast data in an RRC inactive state is not supported (step S104: NO), in step S106, UE100 may send state information to gNB200 indicating the RRC connected state as the RRC state desired by UE100 (Preferred RRC-state: connected). In this case, UE100 does not have to send state information.

[0090] Here, if UE100 transmits uplink data in step S102, UE100 may further consider whether the transmission of such uplink data is expected and set the content of the state information to be transmitted. Specifically, if the transmission of such uplink data is not expected, UE100 transmits state information indicating the RRC inactive state (Preferred RRC-state: inactive) to gNB200. If the transmission of such uplink data is expected, UE100 transmits state information indicating the RRC connected state (Preferred RRC-state: connected) to gNB200.

[0091] If UE100 has set the status information content in accordance with the fact that normal unicast data transmission and reception are not expected, it may rewrite the set content in accordance with the reception of multicast data. For example, UE100 sets the status information content to "idle" (Preferred RRC-state: idle) or "outOfConnected" (Preferred RRC-state: outOfConnected) in accordance with the fact that normal unicast data transmission and reception are not expected. In this case, UE100, which supports receiving multicast data in the RRC inactive state, will rewrite the content to "inactive" in accordance with the reception of multicast data. Note that "outOfConnected" indicates that the RRC state desired by UE100 is the RRC idle state or the RRC inactive state. As another example, UE100 sets the status information content to "idle", "inactive", or "outOfConnected" in accordance with the fact that normal unicast data transmission and reception are not expected. In this case, UE100, which does not support receiving multicast data in the RRC inactive state, will rewrite the content to "connected" in accordance with the reception of multicast data.

[0092] In the following explanation, we will proceed assuming that UE100 has sent status information indicating an RRC inactive state to gNB200.

[0093] In step S107, the gNB200 detects that congestion has occurred. Note that if the gNB200 transmits an instruction in step S103, the detection of congestion may be performed before step S103. In other words, the gNB200 may transmit an instruction in response to the detection of congestion.

[0094] In step S108, gNB200 identifies the UE100 that will transition to the RRC inactive state.

[0095] Here, the gNB200 may identify the UE100 that has transmitted status information indicating an RRC inactive state among the UE100s that are receiving multicast data as the UE100 to transition to the RRC inactive state. The gNB200 can identify the UE100s that are receiving multicast data by receiving information from the UE100s in advance via MBS interest indication messages (MII).

[0096] The gNB200 may further consider the movement status of the UE100 to identify which UE100 should transition to the RRC inactive state. Specifically, the gNB200 may identify which UE100 should transition to the RRC inactive state if it does not move.

[0097] In the case of a moving UE100, the gNB200 may need to perform handover control to ensure the continuity of MBS services. Therefore, it is desirable to keep a moving UE100 in the RRC connected state. In contrast, a stationary UE100 does not have this need, so there is no problem in transitioning a stationary UE100 to the RRC inactive state.

[0098] Furthermore, gNB200 may identify UE100s that have stayed in its cell for a predetermined amount of time as non-moving UE100s. Alternatively, gNB200 may identify non-moving UE100s based on location information periodically received from UE100s. Or, gNB200 may identify non-moving UE100s by receiving notification of their movement status from UE100s. Such notification may be made at the request of gNB200 and / or at the discretion of UE100 itself (for example, in response to a change in its movement status). Such movement status may be notified using MBS interest indications (MIIs). Such movement status may also be notified in conjunction with interest information for MBS reception.

[0099] In step S109, gNB200 sends an RRC Release message to UE100 identified in step S108. UE100 receives the RRC Release message. If gNB200 transitions UE100 to the RRC inactive state, it sends an RRC Release message to UE100 that includes the suspend config as an information element. The RRC Release message may also include the timer value of the timer that measures the waiting time.

[0100] In step S110, UE100 transitions to the RRC inactive state based on the received RRC Release message.

[0101] In step S111, UE100 continues to receive multicast data in the RRC inactive state. For example, UE100 reuses the MBS settings provided when RRC was connected to receive multicast data.

[0102] In step S112, the gNB200 detects that the congestion has been resolved.

[0103] In step S113, gNB200 sends authorization information that allows UE100, which is in the RRC inactive state, to transition to the RRC connected state. UE100 receives the authorization information from gNB200. Here, gNB200 may send the authorization information by broadcast or multicast. For example, gNB200 may send the authorization information in a System Information Block (SIB). gNB200 may send the authorization information in a Control Element (MAC CE). The MAC CE uses G-RNTI and is sent on the MBS Traffic Channel (MTCH). gNB200 may send the authorization information on the MBS Control Channel (MCCH). gNB200 may send the authorization information by TMGI paging. TMGI paging is group paging for a group of UE100s (a group corresponding to TMGI) that receive MBS sessions corresponding to multicast data. The gNB200 may send authorization information to each of the UE100s identified in step S108 using individual paging.

[0104] In step S114, UE100 transitions to the RRC Connected state in response to the receipt of authorization information. Specifically, UE100 sends an RRC Resume Request message to gNB200 by performing a random access procedure to gNB200, and transitions to the RRC Connected state upon receiving an RRC Resume message from gNB200. If the RRC Release message received in step S109 includes a timer value, UE100 may start the timer in response to the transition to the RRC Inactive state and transition to the RRC Connected state when the timer expires. The expiration of the timer may indicate permission to transition to the RRC Connected state. In this case, UE100 may send an RRC Resume Request message to gNB200 in response to the timer expiration. Alternatively, UE100 may send an RRC Resume Request message to gNB200 after the timer expires, at the time it wishes to transition to the RRC Connected state (for example, when uplink data transmission becomes necessary).

[0105] (Second action pattern) Next, we will mainly explain the differences between the second operation pattern according to one embodiment and the operation pattern described above.

[0106] In the second operation pattern, UE100, which is in the RRC connected state, receives a request from gNB200 to transition to the RRC inactive state. If UE100 supports receiving multicast data in the RRC inactive state, it sends an acknowledgment to gNB200 in response to the request. As a result, gNB200 understands that it will not cause any problems to transition UE100 to the RRC inactive state, and can transition UE100 to the RRC inactive state if congestion occurs.

[0107] Figure 10 shows an example of operation of the second operation pattern according to one embodiment. In the initial state of Figure 10, UE100 is in the RRC connected state and the MBS setting is set from gNB200 to UE100.

[0108] As shown in Figure 10, the operation of steps S201 to S202 is the same as the operation of steps S101 to S102.

[0109] In step S203, the gNB200 detects that congestion has occurred.

[0110] In step S204, gNB200 sends a request message to UE100, which is receiving multicast data, to request a transition to the RRC inactive state. The request message may also be a message to inquire whether it is acceptable to transition UE100 to the RRC inactive state. The request message may include an MBS session identifier (TMGI, Session ID, G-RNTI, etc.) corresponding to the multicast data. The request message may also include information indicating the time to be maintained in the RRC inactive state.

[0111] The gNB200 may send the request message by broadcast or multicast. For example, the gNB200 may send the request message using SIB. The gNB200 may send the request message using MCCH. The gNB200 may send the request message using MAC CE multiplexed on MTCH.

[0112] In step S205, UE100 determines whether or not it supports receiving multicast data in an RRC inactive state.

[0113] If UE100 determines that it supports receiving multicast data in an RRC inactive state (step S205: YES), in step S206, UE100 sends an acknowledgment to gNB200 for the request message. UE100 may also send the acknowledgment as an RRC message (UE Assistance Information message, MBS Interest Indication message, etc.). For example, UE100 sends status information indicating an RRC inactive state (Preferred RRC-state: inactive) as the acknowledgment. UE100 may also send the acknowledgment via MAC CE.

[0114] If it is determined that receiving multicast data in an RRC inactive state is not supported (step S205: NO), in step S207, UE100 may send a negative response to the request message to gNB200. However, in this case, UE100 does not have to send a negative response.

[0115] Here, if UE100 transmits uplink data in step S202, UE100 may further consider whether the transmission of such uplink data is expected and set the content of the response to the request message accordingly. Specifically, if the transmission of such uplink data is not expected, UE100 sends an acknowledgment to gNB200. UE100 may also send an acknowledgment to gNB200 if the transmission of uplink data corresponding to the MBS session identifier included in the request message is not expected. In the following explanation, we will proceed assuming that UE100 has sent an acknowledgment to gNB200.

[0116] In step S208, gNB200 identifies the UE100 to transition to the RRC inactive state. Here, the UE100 that sent an acknowledgment may be identified as the UE100 to transition to the RRC inactive state. As in step S108, gNB200 may further consider the movement state of the UE100 to identify the UE100 to transition to the RRC inactive state.

[0117] The operation in steps S209 to S214 is the same as the operation in steps S109 to S114.

[0118] (Third action pattern) Next, we will explain the differences between the third operation pattern according to one embodiment and the operation pattern described above.

[0119] In the third operating pattern, if UE100 supports receiving multicast data in the RRC inactive state, it sends capability information to gNB200 indicating that UE100 supports receiving multicast data in the RRC inactive state. As a result, gNB200 understands that it is acceptable to transition UE100 to the RRC inactive state, and can transition UE100 to the RRC inactive state if congestion occurs.

[0120] Figure 11 shows an example of operation of the third operation pattern according to one embodiment. In the initial state of Figure 11, UE100 is in the RRC connected state and the MBS setting is set from gNB200 to UE100.

[0121] As shown in Figure 11, the operation of step S301 is the same as the operation of step S101.

[0122] In step S302, UE100 sends capability information to gNB200 indicating that UE100 supports receiving multicast data in an RRC inactive state (receiving function). The capability information is sent in a UE Capability Information message. UE100 may also send capability information in response to receiving a capability inquiry message (UE Capability Enquiry message) from gNB200. UE100 may also send capability information to gNB200 before receiving multicast data. Note that this capability information is different from capability information indicating that UE100 supports receiving MBS data.

[0123] In step S303, the gNB200 detects that congestion has occurred.

[0124] In step S304, gNB200 identifies the UE100 to transition to the RRC inactive state. Here, gNB200 may identify a UE100 that has transmitted capability information indicating support for receiving multicast data in the RRC inactive state as the UE100 to transition to the RRC inactive state. As in step S108, gNB200 may further consider the mobile state of the UE100 to identify the UE100.

[0125] The operation in steps S305 to S310 is the same as the operation in steps S109 to S114.

[0126] (Other embodiments) The above-described operation patterns can be performed not only individually but also in combination of two or more operation patterns. For example, some steps of one operation pattern may be added to another operation pattern. Alternatively, some steps of one operation pattern may be replaced with some steps of another operation pattern.

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

[0128] A program may be provided that causes a computer to perform each of the processes that UE100 or gNB200 performs. 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.

[0129] Alternatively, the circuits that perform each process carried out by the UE100 or gNB200 may be integrated, and at least a portion of the UE100 or gNB200 may be configured as a semiconductor integrated circuit (chipset, SoC (System on a Chip)).

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

[0131] This application claims priority to Japanese Patent Application No. 2021-080060 (filed May 10, 2021), and all of its contents are incorporated into the specification of this application. [Explanation of Symbols]

[0132] 10: NG-RAN (5G RAN) 20:5GC(5G CN) 100 :UE 110: Receiver 120: Transmitter 130: Control Unit 200 :gNB 210: Transmitter 220: Receiving unit 230: Control Unit 240: Backhaul Communications Department

Claims

1. A communication control method used in a mobile communication system that provides multicast broadcast services (MBS), A user device in RRC (Radio Resource Control) connected state receives multicast data, which is MBS data transmitted via multicast, from a base station. The user device, which does not support receiving multicast data in an RRC inactive state, transmits status information to the base station indicating the RRC connected state as the RRC state desired by the user device. Communication control method.

2. User equipment used in a mobile communication system that provides multicast broadcast services (MBS), When the user device is in an RRC connected state, the receiving unit receives multicast data, which is MBS data transmitted by multicast, from the base station. The system includes a transmission unit that, if the user device does not support receiving multicast data in an RRC inactive state, transmits status information to the base station indicating the RRC connected state as the RRC state desired by the user device. User device.

3. A base station used in a mobile communication system that provides multicast broadcast services (MBS), When the user device is in an RRC connected state, a transmission unit transmits multicast data, which is MBS data transmitted by multicast, to the user device. If the user device does not support receiving the multicast data in the RRC inactive state, the receiving unit receives status information from the user device indicating the RRC connected state as the RRC state desired by the user device. Equipped with Base station.

4. A mobile communication system that provides multicast broadcast services (MBS), The User device is When the user device is in the RRC connected state, it receives multicast data, which is MBS data transmitted by multicast, from the base station. If the user device does not support receiving the multicast data in the RRC inactive state, the user device transmits status information indicating the RRC connected state as the desired RRC state to the base station. Mobile communication system.

5. A program to be executed by user equipment used in a mobile communication system that provides multicast broadcast services (MBS), When the user device is in an RRC connected state, the process involves receiving multicast data, which is MBS data transmitted by multicast, from the base station. If the user device does not support receiving multicast data in an RRC inactive state, the user device will perform the following process: transmit status information indicating the RRC connected state as the desired RRC state to the base station. program.

6. A chipset for user equipment used in a mobile communication system that provides multicast broadcast services (MBS), When the user device is in an RRC connected state, the process involves receiving multicast data, which is MBS data transmitted by multicast, from the base station. If the user device does not support receiving multicast data in an RRC inactive state, the user device performs the following process: transmit status information indicating the RRC connected state as the desired RRC state to the base station. Chipset.

Images