COMMUNICATION METHOD, USER EQUIPMENT, PROCESSOR, PROGRAM, AND MOBILE COMMUNICATION SYSTEM

Abstract

To provide a communication method and user equipment that can achieve an improved multicast broadcast service.SOLUTION: In a mobile communication system providing a multicast broadcast service (MBS), a communication method executed by user equipment UE 100 includes the steps of: receiving, from a base station gNB 200, configuration information by which a multicast traffic channel (MTCH) associated with an MBS radio bearer (MRB) is configured; and determining, based on the configuration information, whether the type of a session transmitted on the MTCH is a multicast session or a broadcast session.SELECTED DRAWING: Figure 11

Description

[Technical Field]

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

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

[0003] [Non-Patent Document 1] 3GPP contribution: RP-201038, “WID revision: NR Multicast and Broadcast Services” Summary of the Invention

[0004] A communication method according to a first aspect is a method executed by a user device in a mobile communication system that provides a multicast / broadcast service (MBS), the method comprising: receiving, from a base station, configuration information for configuring a multicast traffic channel (MTCH) associated with an MBS radio bearer (MRB); and determining, based on the configuration information, whether a session type transmitted by the MTCH is a multicast session or a broadcast session.

[0005] A user device according to a second aspect is a user device in a mobile communication system that provides a multicast / broadcast service (MBS). The user device includes a processor that performs the following operations: receiving, from a base station, configuration information for configuring a multicast traffic channel (MTCH) associated with an MBS radio bearer (MRB); and determining, based on the configuration information, whether the session type transmitted by the MTCH is a multicast session or a broadcast session. [Brief explanation of the drawings]

[0006] [Figure 1] 1 is a diagram illustrating a configuration of a mobile communication system according to an embodiment. [Figure 2] 1 is a diagram illustrating a configuration of a UE (user equipment) according to an embodiment. [Figure 3] A diagram showing the configuration of a gNB (base station) according to an embodiment. [Figure 4] FIG. 10 is a diagram showing the configuration of a protocol stack of a radio interface of a user plane that handles data. [Figure 5] FIG. 1 is a diagram showing the configuration of a protocol stack of a radio interface of a control plane that handles signaling (control signals). [Figure 6] FIG. 1 is a diagram illustrating an overview of MBS traffic distribution according to an embodiment. [Figure 7] FIG. 10 is a diagram illustrating a distribution mode according to the embodiment. [Figure 8] FIG. 10 is a diagram illustrating an example of internal processing related to MBS reception in a UE according to an embodiment. [Figure 9] FIG. 10 is a diagram illustrating another example of internal processing related to MBS reception in the UE according to the embodiment. [Figure 10] FIG. 10 is a diagram illustrating the operation of a UE regarding data inactivity monitoring according to the first embodiment. [Figure 11] FIG. 2 is a diagram illustrating an operation of the mobile communication system according to the first embodiment. [Figure 12]FIG. 10 is a diagram illustrating an operation of the mobile communication system according to the second embodiment. [Figure 13] FIG. 11 is a diagram illustrating an example of the configuration of an RRC System Info Request message according to the second embodiment. DETAILED DESCRIPTION OF THE INVENTION

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

[0008] It is expected that 5G / NR multicast broadcast services will provide improved services compared to 4G / LTE multicast broadcast services.

[0009] Therefore, an object of the present disclosure is to provide a communication method and a user device that enable an improved multicast broadcast service to be realized.

[0010] [First embodiment]

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[0027] The user plane radio interface protocol includes a physical (PHY) layer, a medium access control (MAC) layer, a radio link control (RLC) layer, a packet data convergence protocol (PDCP) layer, and a service data adaptation protocol (SDAP) layer.

[0028] The PHY layer performs encoding / decoding, modulation / demodulation, antenna mapping / demapping, and resource mapping / demapping. Data and control information are transmitted between the PHY layer of UE100 and the PHY layer of gNB200 via a physical channel. The PHY layer of UE100 receives downlink control information (DCI) transmitted from gNB200 on a physical downlink control channel (PDCCH). Specifically, UE100 performs blind decoding of the PDCCH using a radio network temporary identifier (RNTI) and acquires successfully decoded DCI as DCI addressed to the UE. The DCI transmitted from gNB200 has CRC parity bits scrambled by the RNTI added.

[0029] The MAC layer performs data priority control, retransmission processing using Hybrid ARQ (HARQ), random access procedures, etc. Data and control information are transmitted between the MAC layer of UE 100 and the MAC layer of gNB 200 via a transport channel. The MAC layer of gNB 200 includes a scheduler. The scheduler determines the uplink and downlink transport format (transport block size, modulation and coding scheme (MCS)) and the resource blocks to be allocated to UE 100.

[0030] The RLC layer transmits data to the RLC layer on the receiving side using the functions of the MAC layer and PHY layer. Data and control information are transmitted between the RLC layer of the UE 100 and the RLC layer of the gNB 200 via logical channels.

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

[0032] The SDAP layer maps IP flows, which are the units for QoS control by the core network, to radio bearers, which are the units for QoS control by the AS (Access Stratum). Note that if the RAN is connected to the EPC, SDAP is not necessary.

[0033] FIG. 5 is a diagram showing the configuration of a protocol stack of a radio interface of a control plane that handles signaling (control signals).

[0034] The protocol stack of the radio interface of the control plane has a Radio Resource Control (RRC) layer and a Non-Access Stratum (NAS) layer instead of the SDAP layer shown in FIG.

[0035] RRC signaling for various settings is transmitted between the RRC layer of UE100 and the RRC layer of gNB200. The RRC layer controls logical channels, transport channels, and physical channels according to the establishment, re-establishment, and release of radio bearers. When there is a connection (RRC connection) between the RRC of UE100 and the RRC of gNB200, UE100 is in an RRC connected state. When there is no connection (RRC connection) between the RRC of UE100 and the RRC of gNB200, UE100 is in an RRC idle state. When the connection between the RRC of UE100 and the RRC of gNB200 is suspended, UE100 is in an RRC inactive state.

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

[0037] (MBS Overview) An overview of the MBS according to the first embodiment will be described. The MBS is a service that enables broadcast or multicast, i.e., point-to-multipoint (PTM) data transmission from the NG-RAN 10 to the UE 100. Possible use cases (service types) of the MBS include public safety communications, mission-critical communications, V2X (Vehicle to Everything) communications, IPv4 or IPv6 multicast distribution, IPTV, group communications, and software distribution.

[0038] The broadcast service is for applications that do not require highly reliable QoS, and provides service to all UEs 100 within a specific service area. An MBS session used for the broadcast service is called a broadcast session.

[0039] A multicast service provides a service not to all UEs 100 but to a group of UEs 100 participating in the multicast service (multicast session). An MBS session used for a multicast service is called a multicast session. A multicast service can provide the same content to a group of UEs 100 in a more wirelessly efficient manner than a broadcast service.

[0040] FIG. 6 is a diagram showing an outline of MBS traffic distribution according to the first embodiment.

[0041] MBS traffic (MBS data) is distributed from a single data source (application service provider) to multiple UEs. A 5G core network (5GC) 20 receives the MBS data from the application service provider, creates a copy of the MBS data (replication), and distributes it.

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

[0043] In the 5GC individual MBS traffic delivery method, the 5GC 20 receives a single copy of MBS data packets and delivers individual copies of those MBS data packets to individual UEs 100 via a PDU session for each UE 100. Therefore, one PDU session for each UE 100 needs to be associated with the multicast session.

[0044] In the 5GC shared MBS traffic delivery method, the 5GC 20 receives a single copy of MBS data packets and delivers the single copy of those MBS packets to a RAN node (i.e., the gNB 200). The gNB 200 receives the MBS data packets via an MBS tunnel connection and delivers them to one or more UEs 100.

[0045] From the perspective of the RAN (5G RAN) 10, there are two possible delivery methods for transmitting MBS data over the air in the 5GC shared MBS traffic delivery method: PTP (Point-to-Point) and PTM (Point-to-Multipoint). PTP stands for unicast, and PTM stands for multicast and broadcast.

[0046] In the PTP distribution method, the gNB 200 distributes individual copies of the MBS data packet wirelessly to each UE 100. On the other hand, in the PTM distribution method, the gNB 200 distributes a single copy of the MBS data packet wirelessly to a group of UEs 100. The gNB 200 can dynamically determine whether to use PTM or PTP as the distribution method for MBS data for one UE 100.

[0047] The PTP distribution method and the PTM distribution method are mainly related to the user plane. There are two control modes for MBS data distribution: a first distribution mode and a second distribution mode.

[0048] FIG. 7 is a diagram showing distribution modes according to the first embodiment.

[0049] The first delivery mode (Delivery mode 1: DM1) is a delivery mode that can be used by the UE 100 in the RRC connected state and is a delivery mode for high QoS requirements. The first delivery mode is used for a multicast session among MBS sessions. However, the first delivery mode may also be used for a broadcast session. The first delivery mode may also be available to the UE 100 in the RRC idle state or the RRC inactive state.

[0050] The setting of MBS reception in the first distribution mode is performed by UE-dedicated signaling. For example, the setting of MBS reception in the first distribution mode is performed by an RRC Reconfiguration message (or an RRC Release message), which is an RRC message transmitted by unicast from the gNB 200 to the UE 100.

[0051] The MBS reception configuration includes MBS traffic channel configuration information (hereinafter referred to as "MTCH configuration information") related to the configuration of an MBS traffic channel that transmits MBS data. The MTCH configuration information includes MBS session information (including an MBS session identifier, described later) related to an MBS session and scheduling information for the MBS traffic channel corresponding to this MBS session. The MBS traffic channel scheduling information may include discontinuous reception (DRX) configuration for the MBS traffic channel. The discontinuous reception configuration may include one or more parameters: a timer value (On Duration Timer) that defines the on duration (on duration: reception period), a timer value (Inactivity Timer) that extends the on duration, a scheduling interval or DRX cycle (scheduling period, DRX cycle), a start subframe offset value (Start Offset, DRX Cycle Offset) for the scheduling or DRX cycle, a start delay slot value (Slot Offset) for the on duration timer, a timer value (Retransmission Timer) that defines the maximum time until retransmission, and a timer value (HARQ RTT Timer) that defines the minimum interval until DL allocation for HARQ retransmission.

[0052] The MBS traffic channel is a type of logical channel and is sometimes referred to as an MTCH. The MBS traffic channel is mapped to a downlink shared channel (DL-SCH), which is a type of transport channel.

[0053] The second delivery mode (Delivery mode 2: DM2) is a delivery mode that can be used not only by the UE 100 in the RRC connected state but also by the UE 100 in the RRC idle state or the RRC inactive state, and is a delivery mode for low QoS requirements. The second delivery mode is used for a broadcast session among MBS sessions. However, the second delivery mode may also be applicable to a multicast session.

[0054] The setting of MBS reception in the second distribution mode is performed by broadcast signaling. For example, the setting of MBS reception in the second distribution mode is performed by a logical channel broadcast from the gNB 200 to the UE 100, such as a broadcast control channel (BCCH) and / or a multicast control channel (MCCH). The UE 100 can receive the BCCH and the MCCH using, for example, a dedicated RNTI predefined in a technical specification. The RNTI for BCCH reception may be SI-RNTI, and the RNTI for MCCH reception may be MCCH-RNTI.

[0055] In the second distribution mode, UE100 may receive MBS data in the following three procedures. First, UE100 receives MCCH configuration information via an SIB (MBS SIB) transmitted on the BCCH from gNB200. Second, UE100 receives an MCCH from gNB200 based on the MCCH configuration information. The MCCH transmits the MTCH configuration information. Third, UE100 receives an MTCH (MBS data) based on the MTCH configuration information. Hereinafter, MTCH configuration information and / or MCCH configuration information may be referred to as MBS reception configuration.

[0056] In the first distribution mode and the second distribution mode, the UE 100 may receive the MTCH using a group RNTI (G-RNTI) assigned by the gNB 200. The G-RNTI corresponds to an RNTI for MTCH reception. The G-RNTI may be included in the MBS reception configuration (MTCH configuration information).

[0057] The network can provide different MBS services for each MBS session. An MBS session is identified by at least one of a Temporary Mobile Group Identity (TMGI), a source-specific IP multicast address (consisting of a source unicast IP address of an application function, application server, etc., and an IP multicast address indicating the destination address), a session identifier, and a G-RNTI. At least one of the TMGI, the source-specific IP multicast address, and the session identifier is called an MBS session identifier. The TMGI, the source-specific IP multicast address, the session identifier, and the G-RNTI are collectively called MBS session information.

[0058] Fig. 8 is a diagram showing an example of internal processing related to MBS reception of the UE 100 according to the first embodiment. Fig. 9 is a diagram showing another example of internal processing related to MBS reception of the UE 100 according to the first embodiment.

[0059] An MBS Radio Bearer (MRB) is a radio bearer that carries a multicast session or a broadcast session. That is, an MRB may be associated with a multicast session or a broadcast session.

[0060] The MRB and corresponding logical channels (e.g., MTCH) are configured in the UE 100 from the gNB 200 by RRC signaling. The MRB configuration procedure may be separated from the data radio bearer (DRB) configuration procedure. In RRC signaling, one MRB can be configured as "PTM only," "PTP only," or "both PTM and PTP." The type of such an MRB can be changed by RRC signaling.

[0061] 8 shows an example in which a multicast session and a dedicated traffic channel (DTCH) are associated with MRB#1, a multicast session and MTCH#1 are associated with MRB#2, and a broadcast session and MTCH#2 are associated with MRB#3. That is, MRB#1 is a PTP-only MRB, MRB#2 is a PTM-only MRB, and MRB#3 is a PTM-only MRB. Note that DTCH is scheduled using the cell RNTI (C-RNTI). MTCH is scheduled using the G-RNTI.

[0062] The PHY layer of the UE 100 processes user data (received data) received on a PDSCH, which is one of the physical channels, and transmits the data to a downlink shared channel (DL-SCH), which is one of the transport channels. The MAC layer (MAC entity) of the UE 100 processes the data received on the DL-SCH and transmits the received data to a corresponding logical channel (corresponding RLC entity) based on a logical channel identifier (LCID) included in a header (MAC header) included in the received data.

[0063] 9 shows an example in which a DTCH and an MTCH are associated with an MRB associated with a multicast session. Specifically, one MRB is split into two legs, one leg associated with a DTCH and the other leg associated with an MTCH. The two legs are combined in the PDCP layer (PDCP entity). That is, the MRB is an MRB for both PTM and PTP. Such an MRB is sometimes called a split MRB.

[0064] (Data Inactivity Monitoring) Data inactivity monitoring according to the first embodiment will be described. UE 100 in an RRC connected state performs data inactivity monitoring when a data inactivity timer (dataInactivityTimer) is set by the gNB 200. Data inactivity monitoring is a process for releasing the RRC connection of UE 100 in response to no communication with the gNB 200 being performed for a certain period of time. UE 100 starts or restarts the data inactivity timer every time communication with the gNB 200 is performed. When the data inactivity timer expires, UE 100 autonomously releases the RRC connection (i.e., autonomously transitions to an RRC idle state).

[0065] FIG. 10 is a diagram showing the operation of the UE 100 regarding data inactivity monitoring according to the first embodiment.

[0066] In step S11, the RRC entity of the UE 100 sets a data inactivity timer (dataInactivityTimer) in the MAC entity.

[0067] In step S12, the MAC entity of the UE 100 determines whether it has transmitted or received a MAC SDU. For example, the MAC entity of the UE 100 determines whether it has received a MAC SDU for a DTCH, a dedicated control channel (DCCH), or a common control channel (CCCH). The MAC entity of the UE 100 also determines whether it has transmitted a MAC SDU for a DTCH or a DCCH.

[0068] In the first embodiment, in step S12, the MAC entity of UE 100 also determines whether or not a MAC SDU has been received for an MTCH. However, the MAC entity of UE 100 applies data inactivity monitoring only to an MTCH transmitting a multicast session, and does not apply data inactivity monitoring to an MTCH transmitting a broadcast session. That is, in step S12, the MAC entity of UE 100 determines whether or not a MAC SDU has been received for an MTCH associated with a multicast session, but does not determine whether or not a MAC SDU has been received for an MTCH associated with a broadcast session.

[0069] If the result of step S12 is YES, the MAC entity of the UE 100 starts or restarts a data inactivity timer (dataInactivityTimer) in step S13, and then returns the process to step S12.

[0070] If the result of step S12 is NO, in step S14, the MAC entity of the UE 100 determines whether a data inactivity timer (dataInactivityTimer) has expired. The data inactivity timer expires when a period of time during which no MAC SDUs are transmitted or received for a logical channel to which data inactivity monitoring is applied lasts for the timer value of the data inactivity timer.

[0071] If the data inactivity timer has expired (step S14: YES), in step S15, the MAC entity of the UE 100 notifies the RRC entity of the expiration of the data inactivity timer.

[0072] In step S16, in response to the expiration of the data inactivity timer, the RRC entity of the UE 100 performs a process of releasing the RRC connection, and as a result, the UE 100 transitions to an RRC idle state.

[0073] (Mobile communication system operation) The operation of the mobile communication system 1 according to the first embodiment will be described.

[0074] As described above, the MAC entity of the UE 100 applies data inactivity monitoring only to the MTCH (MRB) that transmits a multicast session, and does not apply data inactivity monitoring to the MTCH (MRB) that transmits a broadcast session. Therefore, the UE 100 in which the MTCH (MRB) is configured needs to be able to identify whether the type of session transmitted by the MTCH (MRB) is a multicast session or a broadcast session.

[0075] In the first embodiment, an operation for the UE 100 to identify whether the type of session transmitted by the configured MTCH (MRB) is a multicast session or a broadcast session will be described. Hereinafter, an MTCH (or MRB) transmitting a multicast session will be referred to as an MTCH for multicast (or MRB for multicast). Also, an MTCH (or MRB) transmitting a broadcast session will be referred to as an MTCH for broadcast (or MRB for broadcast).

[0076] In the first embodiment, the UE 100 receives configuration information (MTCH configuration information) for configuring a multicast traffic channel (MTCH) associated with an MBS radio bearer (MRB) from the gNB 200. Based on the MTCH configuration information or the MBS data transmitted on the MTCH, the UE 100 determines whether the type of session transmitted by the MRB or the MTCH is a multicast session or a broadcast session. This makes it possible to appropriately determine whether the configured MTCH (MRB) is a multicast MTCH (multicast MRB) or a broadcast MTCH (broadcast MRB).

[0077] In addition, determining whether a configured MTCH (MRB) is a multicast MTCH (MRB) or a broadcast MTCH (MRB) may mean determining whether data inactivity monitoring is applied to the configured MTCH (MRB). Specifically, determining that a configured MTCH (MRB) is a multicast MTCH (MRB) may mean determining that data inactivity monitoring is applied to the configured MTCH (MRB). Also, determining that a configured MTCH (MRB) is a broadcast MTCH (MRB) may mean determining that data inactivity monitoring is not applied to the configured MTCH (MRB).

[0078] UE100 may determine whether the type of session transmitted by the MTCH (MRB) is a multicast session or a broadcast session based on at least one of the information contained in the MTCH configuration information that configures the MTCH (MRB), the type of message that transmits the MTCH configuration information, and the type of channel that transmits the MTCH configuration information.

[0079] When the UE 100 is in an RRC connected state and the identified session type is a multicast session, the UE 100 applies data inactivity monitoring to the configured MTCH. Here, the determination of whether or not to subject the MTCH to data inactivity monitoring may be performed by the RRC entity of the UE 100. The RRC entity may notify the MAC entity of information indicating the result of the determination. As described above, data inactivity monitoring is performed by the MAC entity. Therefore, the RRC entity identifies the session type (i.e., whether or not data inactivity monitoring needs to be applied) for each MTCH (MRB) and notifies the MAC entity of the result. This allows the MAC entity to appropriately determine whether or not data inactivity monitoring needs to be applied for each MTCH.

[0080] FIG. 11 is a diagram showing the operation of the mobile communication system 1 according to the first embodiment.

[0081] In step S101, the gNB 200 transmits an RRC reconfiguration message or an MCCH including MTCH configuration information to the UE 100. The UE 100 receives the MTCH configuration information. Note that although it is assumed that the UE 100 is in an RRC connected state, the UE 100 may be in an RRC idle state or an RRC inactive state.

[0082] In step S102, the RRC entity of UE 100 determines whether the type of session transmitted by the configured MTCH (MRB) is a multicast session or a broadcast session, based on the MTCH configuration information received in step S101 or the MBS data transmitted on the MTCH. UE 100 may determine whether data inactivity monitoring is to be applied to the configured MTCH (MRB) based on the MTCH configuration information received in step S101 or the MBS data transmitted on the MTCH. Note that if multiple MTCHs are configured for UE 100, UE 100 performs this determination for each configured MTCH. The RRC entity of UE 100 may notify a lower layer (e.g., a MAC entity) of the determined session type and / or information on whether data inactivity monitoring is required.

[0083] The RRC entity of the UE 100 may use any of the following first to fifth identification methods to perform such identification.

[0084] ·First identification method The MTCH configuration information includes, for each MTCH or for each G-RNTI, information indicating whether the MTCH is a multicast MTCH or a broadcast MTCH, or information indicating whether data inactivity monitoring is applied to the MTCH. Based on the information included in the MTCH configuration information, the RRC entity of the UE 100 determines whether the type of session transmitted by the MTCH is a multicast session or a broadcast session (i.e., whether data inactivity monitoring is applied to the MTCH (MRB)).

[0085] ·Second identification method The MTCH configuration information includes an MBS session identifier (e.g., TMGI) for each MTCH. The NAS layer of UE 100 notifies the AS layer of the MBS session identifier (TMGI) to which UE 100 has joined the multicast session. The AS layer of UE 100 compares the MBS session identifier (TMGI) notified from the NAS layer with the MBS session identifier (TMGI) included in the MTCH configuration information received in step S101, and identifies the MTCH (MRB) corresponding to the MBS session identifier (TMGI) that matches the MBS session identifier (TMGI) notified from the NAS layer as the MTCH for multicast (MRB for multicast).

[0086] ·Third identification method The MTCH configuration information includes a HARQ feedback configuration associated with the MTCH. The UE 100 determines that data inactivity monitoring is not applied to an MTCH for which HARQ feedback is not configured, and determines that data inactivity monitoring is applied to an MTCH for which HARQ feedback (e.g., a PUCCH resource for HARQ feedback) is not configured. Note that, for a UE 100 for which HARQ feedback for MBS reception is configured, the gNB 200 can determine whether the UE 100 has transitioned to the RRC idle state through data inactivity monitoring based on the HARQ feedback.

[0087] ·Fourth identification method The MTCH configuration information is included in a first information element (e.g., RadioBearerConfig or mrb-ToAddModList) in an RRC Reconfiguration message transmitted from the gNB 200 to the UE 100 on the DL-DCCH. Alternatively, the MTCH configuration information is included in a second information element (e.g., MBS Broadcast Configuration) transmitted from the gNB 200 to the UE 100 on the MCCH. When the MTCH configuration information is transmitted by any of the DL-DCCH, the RRC Reconfiguration message, and the first information element, the UE 100 determines that the type of session transmitted by the MTCH corresponding to the MTCH configuration information is a multicast session (i.e., data inactivity monitoring is applied to the MTCH). On the other hand, when the MTCH configuration information is transmitted by any of the MCCH and the second information element, the UE 100 determines that the type of session transmitted by the MTCH corresponding to the MTCH configuration information is a broadcast session (i.e., data inactivity monitoring is not applied to the MTCH).

[0088] ·Fifth identification method The MTCH set in step S101 transmits MBS data to the UE 100. Here, the MAC PDU constituting the MBS data may include information for identifying multicast / broadcast in its header. Based on the information included in the MAC PDU header, the UE 100 may identify whether the type of session transmitted by the MTCH is a multicast session or a broadcast session (i.e., whether data inactivity monitoring is applied to the MTCH).

[0089] If the session type identified in step S102 is a multicast session (step S103: YES), the MAC entity of UE 100 applies data inactivity monitoring to the MTCH set in step S101. On the other hand, if the session type identified in step S102 is a broadcast session (step S103: NO), the MAC entity of UE 100 does not apply data inactivity monitoring to the MTCH set in step S101.

[0090] The UE 100 may identify the LCID space to which the logical channel ID (LCID) assigned to the configured MTCH belongs by any of the above-described first to fifth identification methods. A common LCID space is used for the PTP of the multicast session and the DTCH / DRB of the unicast session, but a reserved LCID (different from the LCID space of the DTCH / DRB of the unicast session) is used for the PTM / MTCH of the broadcast session. Therefore, the UE 100 can determine whether the LCID space is for multicast or broadcast (whether data inactivity monitoring is required) based on the LCID space. Therefore, the UE 100 may identify whether the session type transmitted by the MTCH is a multicast session or a broadcast session (i.e., whether data inactivity monitoring is applied to the MTCH) by taking the identified LCID space into consideration.

[0091] [Second embodiment] The second embodiment will be described mainly focusing on the differences from the first embodiment described above.

[0092] The second embodiment is an embodiment assuming the above-described second delivery mode (Delivery mode 2). In the second delivery mode, the gNB 200 can provide the UE 100 with the MBS SIB and / or the MCCH on demand (i.e., in response to a request from the UE 100). Specifically, instead of constantly transmitting the MBS SIB and / or the MCCH, the gNB 200 transmits (broadcasts) the MBS SIB and / or the MCCH only when requested by the UE 100. This can reduce the radio resources and power consumption required to transmit the MBS SIB and / or the MCCH.

[0093] Here, when on-demand transmission is applied to both the MBS SIB and the MCCH, the UE 100 may need to transmit a transmission request for the MBS SIB and a transmission request for the MCCH separately to the gNB 200. In this case, making two transmission requests increases radio resource consumption and power consumption. In the second embodiment, a new mechanism of a single transmission request for requesting both the transmission of the MBS SIB and the transmission of the MCCH is introduced.

[0094] In the second embodiment, first, UE100 transmits a single transmission request to gNB200 to request both transmission of an MBS SIB and transmission of an MCCH. Second, UE100 receives the MBS SIB transmitted from gNB200 in response to the single transmission request. Third, UE100 receives the MCCH transmitted from gNB200 in response to the single transmission request, based on the MBS SIB. This eliminates the need for UE100 to transmit a transmission request for MBS SIB and a transmission request for MCCH separately to gNB200, even when on-demand transmission is applied to both MBS SIB and MCCH. This makes it possible to reduce radio resource consumption and power consumption.

[0095] UE 100, which has transmitted the single transmission request, may start an operation for receiving the MCCH after receiving the MBS SIB. After transmitting the single transmission request, UE 100 starts an operation for receiving the MBS SIB (for example, monitoring the MBS SIB), but does not start an operation for receiving the MCCH (for example, monitoring the MCCH). Then, UE 100 starts an operation for receiving the MCCH after receiving the MBS SIB. This makes it possible to reduce power consumption associated with MCCH reception.

[0096] The UE 100 may determine whether to request at least one of the transmission of an MBS SIB and the transmission of an MCCH. In response to a determination to request both the transmission of an MBS SIB and the transmission of an MCCH, the UE 100 may transmit a single transmission request to the gNB 200 to request both the transmission of an MBS SIB and the transmission of an MCCH. In contrast, in response to a determination to request only the transmission of an MBS SIB, the UE 100 may transmit a transmission request to the gNB 200 to request only the transmission of an MBS SIB. In response to a determination to request only the transmission of an MCCH, the UE 100 may transmit a transmission request to the gNB 200 to request only the transmission of an MCCH.

[0097] FIG. 12 is a diagram showing the operation of the mobile communication system 1 according to the second embodiment.

[0098] In step S201, the UE 100 is interested in receiving an MBS (specifically, receiving an MTCH).

[0099] In step S202, UE 100 recognizes that gNB 200 is not broadcasting the MBS SIB (and MCCH). For example, when UE 100 receives SIB type 1 from gNB 200 and the SI scheduling information in SIB type 1 indicates that the MBS SIB (and MCCH) is not broadcast, UE 100 determines that gNB 200 is not broadcasting the MBS SIB (and MCCH) and that they are provided on demand.

[0100] In step S203, the UE 100 transmits a single transmission request to the gNB 200 to request both the transmission of the MBS SIB and the transmission of the MCCH. The single transmission request may be a random access preamble transmitted using a physical random access channel (PRACH) resource dedicated to requesting the transmission of at least the MBS SIB. Such a dedicated PRACH resource may be a time-frequency resource or a preamble sequence. Alternatively, the single transmission request may be an RRC message (RRCSystemInfoRequest message) including an information element requesting the transmission of at least the MBS SIB.

[0101] In step S204, the gNB 200 that has received the single transmission request starts transmitting the MBS SIB and the MCCH. After receiving the single transmission request, the gNB 200 may periodically transmit each of the MBS SIB and the MCCH for a certain period of time. The certain period may be the same for the MBS SIB and the MCCH, or may be different.

[0102] On the other hand, the UE 100 that has received the single transmission request starts monitoring the MBS SIB. For example, the UE 100 performs a receiving process of the PDCCH using the system information RNTI (SI-RNTI) at the receiving opportunity of the MBS SIB indicated by the SI scheduling information. At this point, the UE 100 does not need to start monitoring the MCCH.

[0103] In step S205, UE 100 receives the MBS SIB transmitted from gNB 200. In response to receiving the MBS SIB, UE 100 starts MCCH monitoring based on the MCCH configuration information in the received MBS SIB. For example, UE 100 performs PDCCH reception processing using the MCCH-RNTI at an opportunity to receive the MCCH indicated by the MCCH configuration information. UE 100 may start MCCH monitoring within a certain period after transmitting the transmission request in step S203. UE 100 may complete MCCH acquisition within a certain period after transmitting the transmission request in step S203. The certain period may be notified to UE 100 by gNB 200. Note that in step S205, UE 100 may start MCCH reception immediately after receiving the MBS SIB. For example, UE 100 may start MCCH reception in the slot in which the MBS SIB is received or the slot following that slot, or may start MCCH reception at the first MCCH reception opportunity indicated by the MCCH setting information in the MBS SIB or before that MCCH reception opportunity. Here, the first MCCH reception opportunity may be the next MCCH reception opportunity after receiving the MBS SIB, or may be the first MCCH reception opportunity after an MCCH modification period boundary (MCCH Modification Boundary). The first MCCH reception opportunity may be the first MCCH reception opportunity in an SSB (beam) received by UE 100.

[0104] In step S206, the UE 100 receives the MCCH transmitted from the gNB 200. The UE 100 starts MTCH monitoring based on the MTCH configuration information in the received MCCH. For example, the UE 100 performs reception processing of the PDCCH using the G-RNTI at an opportunity to receive the MTCH indicated by the MTCH configuration information.

[0105] In step S207, UE100 receives the MTCH transmitted from gNB200.

[0106] Note that, although a single transmission request requesting transmission of both the MBS SIB and the MCCH has been described in FIG. 12 , the transmission request may request transmission of only one of the MBS SIB and the MCCH. That is, the MBS SIB / MCCH transmission request may indicate one request pattern selected by the UE 100 from three patterns: "both the MBS SIB and the MCCH," "MBS SIB only," and "MCCH only." Note that, when the UE 100 transmits a transmission request for "MCCH only" to the gNB 200, the UE 100 may start MCCH reception immediately after transmitting the transmission request. For example, the UE 100 may start MCCH reception in the slot in which the MBS SIB is received or the slot following that slot, or may start MCCH reception in the slot in which the transmission request is transmitted or the slot following that slot, or may start MCCH reception at the first MCCH reception opportunity indicated in the MCCH setting information in the MBS SIB or before the first MCCH reception opportunity. Here, the first MCCH reception opportunity may be the next MCCH reception opportunity after receiving an MBS SIB, the next MCCH reception opportunity after transmitting the transmission request, or the first MCCH reception opportunity after an MCCH modification period boundary. The first MCCH reception opportunity may be the first MCCH reception opportunity in an SSB (beam) received by the UE 100.

[0107] First, a case where an MBS SIB / MCCH transmission request is configured using a random access preamble will be described.

[0108] For example, the gNB 200 notifies the UE 100 of a first PRACH resource set corresponding to "both MBS SIB and MCCH," a second PRACH resource set corresponding to "only MBS SIB," and a third PRACH resource set corresponding to "only MCCH" by an SIB (e.g., SIB type 1). The PRACH resource sets differ from each other in time-frequency resources and / or preamble sequences.

[0109] Based on the content notified by the gNB 200 in the SIB, the UE 100 transmits a random access preamble (MBS SIB / MCCH transmission request) using a PRACH resource set corresponding to the MBS SIB or MCCH that the UE 100 requests to transmit. For example, when the UE 100 requests transmission of "both MBS SIB and MCCH", the UE 100 transmits the random access preamble using a PRACH resource selected from the first PRACH resource set. When the UE 100 requests transmission of "only MBS SIB", the UE 100 transmits the random access preamble using a PRACH resource selected from the second PRACH resource set. When the UE 100 requests transmission of "only MCCH", the UE 100 transmits the random access preamble using a PRACH resource selected from the third PRACH resource set.

[0110] Second, a case where an MBS SIB / MCCH transmission request is configured using an RRCSystemInfoRequest message will be described. In this case, the UE 100 transmits to the gNB 200 an RRCSystemInfoRequest message including an information element indicating one request pattern selected by the UE 100 from three patterns: "both MBS SIB and MCCH," "MBS SIB only," and "MCCH only."

[0111] FIG. 13 is a diagram illustrating an example of the configuration of an RRC System Info Request message according to the second embodiment.

[0112] The RRCSystemInfoRequest message includes at least one of "requested-SI-List", which is a list indicating the type of SIB requested to be transmitted, "requested-MBS-SIB-and-MCCH", which indicates a request to transmit both the MBS SIB and the MCCH, and "requested-MCCH", which indicates a request to transmit the MCCH. For example, when requesting the transmission of "both the MBS SIB and the MCCH", the UE 100 transmits an RRCSystemInfoRequest message including "requested-MBS-SIB-and-MCCH". When requesting the transmission of "only the MBS SIB", the UE 100 transmits an RRCSystemInfoRequest message including "requested-SI-List", which indicates the MBS SIB. When requesting the transmission of "only the MCCH", the UE 100 transmits an RRCSystemInfoRequest message including "requested-MCCH". Note that "requested-MBS-SIB-and-MCCH" and "requested-MCCH" are each configured as a 1-bit flag.

[0113] Note that one cell of the gNB200 may have multiple MCCHs. Each MCCH may be associated with a different TMGI. Each MCCH may have a different transmission period. When one cell of the gNB200 has multiple MCCHs, the "requested-MCCH" may be configured as a list having multiple bits. In this case, each bit may be associated with the order of the MCCH list broadcast in the MBS SIB (the order in which only MCCHs that are not broadcast by the gNB200 or are on-demand are extracted).

[0114] [Other embodiments] The above-mentioned operational flows are not limited to being implemented independently, but can also be implemented by combining two or more operational flows. For example, some steps of one operational flow may be added to another operational flow, or some steps of one operational flow may be replaced with some steps of another operational flow.

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

[0116] A program may be provided that causes a computer to execute each process performed by UE100 or gNB200. The program may be recorded on a computer-readable medium. Using the computer-readable medium, the program can be installed on a computer. Here, the computer-readable medium on which the program is recorded may be a non-transitory recording medium. The non-transitory recording medium is not particularly limited, and may be, for example, a recording medium such as a CD-ROM or DVD-ROM. Furthermore, circuits that execute each process performed by UE100 or gNB200 may be integrated, and at least a part of UE100 or gNB200 may be configured as a semiconductor integrated circuit (chipset, SoC).

[0117] The above describes the embodiments in detail with reference to the drawings, but the specific configuration is not limited to that described above, and various design changes can be made within the scope that does not deviate from the gist of the invention.

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

[0119] This application claims priority to U.S. Provisional Application No. 63 / 262,459 (filed October 13, 2021), the entire contents of which are incorporated herein by reference.

Claims

1. A communication method performed by a user device in a mobile communication system providing a multicast broadcast service (MBS), comprising: receiving configuration information from a network node for configuring a traffic channel (MTCH) for an MBS radio bearer (MRB); The receiving step includes: receiving the configuration information through dedicated RRC signaling when the type of the session transmitted by the MTCH is a multicast session; receiving the configuration information by broadcast signaling when the type of the session transmitted by the MTCH is a broadcast session; A PDCP (Packet Data Convergence Protocol) entity corresponding to one of the MRBs associated with a multicast session is associated with both a dedicated traffic channel (DTCH) for one PTP (Point to Point) transmission and the MTCH for one PTM (Point to Multipoint) transmission; The DTCH and MTCH are associated with a downlink shared channel (DL-SCH), Communication method.

2. A user equipment for use in a mobile communication system providing a multicast broadcast service (MBS), comprising: a receiving unit configured to receive configuration information for configuring a traffic channel (MTCH) for an MBS radio bearer (MRB) from a network node; The receiving unit receives the configuration information by dedicated RRC signaling when a type of a session transmitted by the MTCH is a multicast session; The receiving unit receives the setting information by broadcast signaling when a type of a session transmitted by the MTCH is a broadcast session; A PDCP (Packet Data Convergence Protocol) entity corresponding to one of the MRBs associated with a multicast session is associated with both a dedicated traffic channel (DTCH) for one PTP (Point to Point) transmission and the MTCH for one PTM (Point to Multipoint) transmission; The DTCH and MTCH are associated with a downlink shared channel (DL-SCH), User equipment.

3. A device for use in a user device for carrying out the communication method according to claim 1. Processor.

4. The communication method according to claim 1 is executed by a user device. program.

5. The user equipment according to claim 2 and a network node. Mobile communication system.

Images