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

Abstract

To realize an improved multicast and broadcast service.SOLUTION: A communication method used in a mobile communication system for supporting a multicast and broadcast service (MBS) includes: receiving, by a user device from a network node, the settings of a multicast radio bearer associated with a radio link control (RLC) entity for point-to-point (PTP) transmission and a RLC entity for point-to-multipoint (PTM) transmission; and handling, by the user device, the multicast radio bearer as an AM multicast radio bearer according to the fact that the RLC entity for PTP transmission is an acknowledged mode (AM) RLC entity.SELECTED DRAWING: Figure 20

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 below) standard specifies the technical specifications of NR (New Radio), a fifth-generation (5G) wireless access technology. Compared with LTE (Long Term Evolution), a fourth-generation (4G) wireless access technology, NR has features such as high speed, large capacity, high reliability, and low latency. Discussions are underway in 3GPP to formulate technical specifications for 5G / NR multicast broadcast service (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] It is expected that 5G / NR multicast broadcast services will provide improved services over 4G / LTE multicast broadcast services.

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

[0006] A communication method according to a first aspect is a communication method used in a mobile communication system supporting a multicast broadcast service (MBS), and includes the steps of: a user device that has started receiving an MBS session from a base station determining whether a predetermined condition indicating that the reception started in the middle of the MBS session is satisfied; and, if the user device determines that the predetermined condition is satisfied, transmitting missing packet identification information to the base station indicating a group of packets that were missed between the start of the MBS session and the start of the reception.

[0007] A user device according to a second aspect is a user device used in a mobile communication system supporting a multicast broadcast service (MBS), and has a control unit that, after starting reception of an MBS session from a base station, determines whether a predetermined condition indicating that the reception started in the middle of the MBS session is met, and a transmission unit that, if it is determined that the predetermined condition is met, transmits to the base station missing packet identification information indicating a group of packets that were missed between the start of the MBS session and the start of the reception.

[0008] A communication method according to a third aspect is a communication method used in a mobile communication system supporting a multicast broadcast service (MBS), and includes the steps of: a user equipment receiving, from a base station, configuration information for configuring a split radio bearer split into a PTP (Point-to-Point) leg and a PTM (Point-to-Multipoint) leg; and the user equipment determining, based on an RLC (Radio Link Control) mode configured for each leg, whether the split radio bearer is an AM (Acknowledged Mode) bearer or a UM (Unacknowledged Mode) bearer.

[0009] A user equipment according to a fourth aspect is a user equipment used in a mobile communication system supporting a multicast broadcast service (MBS), and has a receiving unit that receives configuration information from a base station for configuring a split radio bearer split into a PTP (Point-to-Point) leg and a PTM (Point-to-Multipoint) leg, and a control unit that determines whether the split radio bearer is an AM (Acknowledged Mode) bearer or a UM (Unacknowledged Mode) bearer based on an RLC (Radio Link Control) mode configured for each leg. [Brief description of the drawings]

[0010] [Figure 1] 1 is a diagram showing a configuration of a mobile communication system according to an embodiment. [Diagram 2] FIG. 2 is a diagram showing a configuration of a UE (user equipment) according to an embodiment. [Diagram 3] A diagram showing the configuration of a gNB (base station) according to an embodiment. [Figure 4] A diagram showing the configuration of a protocol stack of a wireless interface of a user plane that handles data. [Diagram 5] FIG. 2 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. 2 is a diagram showing an overview of MBS traffic distribution according to an embodiment. [Figure 7] FIG. 13 is a diagram illustrating a distribution mode according to the embodiment. [Figure 8] FIG. 2 is a diagram showing a split multicast radio bearer (MRB) according to an embodiment. [Figure 9] FIG. 2 is a diagram showing the operation of a PDCP layer in the mobile communication system according to the embodiment. [Figure 10] FIG. 13 is a diagram showing a COUNT value according to the embodiment. [Figure 11] FIG. 13 is a diagram showing a PDCP data PDU according to an embodiment. [Figure 12] FIG. 13 is a diagram showing an operation for identifying an RCVD_COUNT. [Figure 13] A diagram showing the operation of a receiving PDCP entity of a UE. [Figure 14] FIG. 2 is a diagram illustrating the operation of a UE according to the first embodiment. [Figure 15] FIG. 2 is a diagram showing an example of the operation of the mobile communication system according to the first embodiment. [Figure 16] 1A to 1C are diagrams illustrating configuration examples 1 to 3 of a PDCP status report according to the first embodiment. [Figure 17] FIG. 2 is a diagram illustrating an example of the configuration of an RRC message according to the first embodiment. [Figure 18] FIG. 11 is a diagram illustrating a first modified example of the operation according to the first embodiment. [Figure 19] FIG. 11 is a diagram showing a second modified example of the operation according to the first embodiment. [Figure 20] FIG. 11 is a diagram illustrating the operation of a UE according to the second embodiment. [Figure 21] A diagram showing PDCP-fixed PTM / PTP switching based on the current agreement. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

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

[0012] [First embodiment] (Configuration of a mobile communication system) FIG. 1 is a diagram showing a configuration of a mobile communication system 1 according to a first embodiment. The mobile communication system 1 complies with 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 to a Long Term Evolution (LTE) system. Also, the mobile communication system may be at least partially applied to a sixth generation (6G) system.

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

[0014] The UE 100 is a mobile wireless communication device. The UE 100 may be any device that is used by a user. For example, the UE 100 is 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).

[0015] 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 the 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, and the like. 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 for performing wireless communication with the UE 100. One cell belongs to one carrier frequency (hereinafter simply referred to as "frequency").

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

[0017] 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 Non-Access Stratum (NAS) signaling. The UPF controls data forwarding. The AMF and the UPF are connected to the gNB 200 via an NG interface, which is an interface between a base station and a core network.

[0018] 2 is a diagram showing a 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 configure a wireless communication unit that performs wireless communication with the gNB 200.

[0019] The receiving unit 110 performs various receptions 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.

[0020] The transmission unit 120 performs various transmissions under the control of the control unit 130. The transmission 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.

[0021] The control unit 130 performs various controls and processes in the UE 100. Such processes include processes of each layer described below. 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.

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

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

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

[0025] The control unit 230 performs various controls and processes in the gNB 200. Such processes include processes of each layer described below. 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.

[0026] The backhaul communication unit 240 is connected to adjacent 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 to each other via an F1 interface, which is a fronthaul interface.

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

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

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

[0030] The MAC layer performs data priority control, retransmission processing using Hybrid Automatic Repeat reQuest (HARQ), random access procedures, etc. Data and control information are transmitted between the MAC layer of UE100 and the MAC layer of gNB200 via a transport channel. The MAC layer of gNB200 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 assigned to UE100.

[0031] The RLC layer transmits data to the RLC layer on the receiving side by using the functions of the MAC layer and the 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 a logical channel.

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

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

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

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

[0036] Between the RRC layer of the UE 100 and the RRC layer of the gNB 200, RRC signaling for various settings is transmitted. 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 the UE 100 and the RRC of the gNB 200, the UE 100 is in an RRC connected state. When there is no connection (RRC connection) between the RRC of the UE 100 and the RRC of the gNB 200, the UE 100 is in an RRC idle state. When the connection between the RRC of the UE 100 and the RRC of the gNB 200 is suspended, the UE 100 is in an RRC inactive state.

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

[0038] (Overview of MBS) 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 communication, mission-critical communication, V2X (Vehicle to Everything) communication, IPv4 or IPv6 multicast distribution, IPTV (Internet protocol television), group communication, and software distribution.

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

[0040] The multicast service provides services not to all UEs 100 but to a group of UEs 100 participating in the multicast service (multicast session). The MBS session used in the multicast service is called a multicast session. The multicast service allows the same content to be provided to a group of UEs 100 in a more wirelessly efficient manner than the broadcast service.

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

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

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

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

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

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

[0047] In the PTP distribution method, the gNB 200 distributes individual copies of the MBS data packets 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 to one UE 100.

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

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

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

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

[0052] The MBS reception configuration includes MBS traffic channel configuration information (hereinafter referred to as "MTCH configuration information") related to the configuration of the MBS traffic channel carrying MBS data. The MTCH configuration information includes MBS session information related to the MBS session and scheduling information of the MBS traffic channel corresponding to the MBS session. The scheduling information of the MBS traffic channel may include a discontinuous reception (DRX) configuration of the MBS traffic channel. The discontinuous reception configuration may include one or more parameters of a timer value (On Duration Timer) defining an on-duration (On Duration: reception period), a timer value (Inactivity Timer) extending the on-duration, a scheduling interval or DRX cycle (Scheduling Period, DRX Cycle), an offset value of the start subframe of the scheduling or DRX cycle (Start Offset, DRX Cycle Offest), a start delay slot value of the on-duration timer (Slot Offset), a timer value (Retransmission Timer) defining the maximum time until retransmission, and a timer value (HARQ RTT Timer) defining the minimum interval until DL allocation of HARQ retransmission.

[0053] The MBS traffic channel is a type of logical channel and may be referred to as an MTCH. The MBS traffic channel is mapped to a Down Link-Shared CHannel (DL-SCH), which is a type of transport channel.

[0054] The second delivery mode (Delivery mode 2: DM2) is a delivery mode that can be used by UE 100 in the RRC connected state as well as UE 100 in the RRC idle state or 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.

[0055] 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 MCCH using a dedicated RNTI predefined in the technical specifications, for example. The RNTI for BCCH reception may be SI-RNTI, and the RNTI for MCCH reception may be MCCH-RNTI.

[0056] In the second distribution mode, UE 100 may receive MBS data in the following three procedures. First, UE 100 receives MCCH setting information by SIB (MBS-SIB) transmitted on BCCH from gNB 200. Second, UE 100 receives MCCH from gNB 200 based on MCCH setting information. MCCH transmits MTCH setting information. Third, UE 100 receives MTCH (MBS data) based on MTCH setting information. Hereinafter, MTCH setting information and / or MCCH setting information may be referred to as MBS reception setting.

[0057] 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 setting (MTCH setting information).

[0058] 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 or application server, etc., and an IP multicast address indicating a destination address), a session identifier, and a G-RNTI. At least one of the TMGI, G-RNTI, source-specific IP multicast address, and session identifier is called an MBS session identifier. The TMGI, source-specific IP multicast address, session identifier, and G-RNTI are collectively called MBS session information.

[0059] FIG. 8 is a diagram showing a split multicast radio bearer (MRB) according to the first embodiment. The MRB may be a type of data radio bearer (DRB). The split MRB may be used in the first delivery mode described above.

[0060] The gNB200 can set an MRB separated into a PTP communication path and a PTM communication path to the UE100. 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 improve reliability by dually transmitting the same MBS data using both PTP (PTP communication path) and PTM (PTM communication path). In the following, the PTP communication path is called a PTP leg, and the PTM communication path is called a PTM leg. In addition, the functional units corresponding to each layer are called entities.

[0061] The predetermined layer that terminates the split is the MAC layer (HARQ), the RLC layer, the PDCP layer, or the SDAP layer. In the following, an example in which the predetermined layer that terminates the split is the PDCP layer will be mainly described, but the predetermined layer may be the MAC layer (HARQ), the RLC layer, or the SDAP layer.

[0062] Each of the PDCP entity of the gNB 200 and the PDCP entity of the UE 100 separates the MRB, which is a bearer (data radio bearer) used for the MBS, into a PTP leg and a PTM leg. Note that a PDCP entity is provided for each bearer.

[0063] Each of the gNB 200 and the UE 100 has two RLC entities provided for each leg, one MAC entity, and one PHY entity. The PHY entity may be provided for each leg. In the case of dual connectivity in which the UE 100 communicates with two gNBs 200, the UE 100 may have two MAC entities.

[0064] The PHY entity transmits and receives data of the PTP leg using a Cell Radio Network Temporary Identifier (C-RNTI) that is assigned one-to-one to the UE 100. The PHY entity transmits and receives data of the PTM leg using a G-RNTI that is assigned one-to-one to the MBS session. The C-RNTI is different for each UE 100, but the G-RNTI is a common RNTI for multiple UEs 100 receiving one MBS session.

[0065] In order to perform PTM transmission (multicast or broadcast) of MBS data from the gNB 200 to the UE 100 using a PTM leg, a split MRB must be set from the gNB 200 to the UE 100, and the PTM leg must be activated. In other words, even if a split MRB is set in the UE 100, the gNB 200 cannot perform PTM transmission of MBS data using this PTM leg if the PTM leg is in a deactivation state.

[0066] In addition, in order for the gNB200 and the UE100 to perform PTP transmission (unicast) of MBS data using a PTP leg, a split MRB must be set from the gNB200 to the UE100, and the PTP leg must be activated. In other words, even if a split MRB is set in the UE100, the gNB200 cannot perform PTP transmission of MBS data using this PTP leg if the PTP leg is in an inactive state.

[0067] In a state in which the PTM leg is activated, the UE 100 monitors a PDCCH to which a G-RNTI associated with an MBS session is applied (i.e., the UE 100 performs blind decoding of the PDCCH using the G-RNTI). The UE 100 may monitor the PDCCH only at a scheduling opportunity for the MBS session.

[0068] In a state in which the PTM leg is deactivated, the UE 100 does not monitor the PDCCH to which the G-RNTI associated with the MBS session is applied (that is, does not perform blind decoding of the PDCCH using the G-RNTI).

[0069] UE 100 monitors the PDCCH to which C-RNTI is applied when the PTP leg is activated. When discontinuous reception (DRX) is set in the PTP leg, UE 100 monitors the PDCCH during the set on validity period (OnDuration). When a cell (frequency) associated with an MBS session is specified, UE 100 may monitor the PDCCH of the cell even if the cell is deactivated.

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

[0071] In addition, it is assumed that the split MRB as described above is configured by an RRC message (e.g., an RRC Reconfiguration message) transmitted by the RRC entity of gNB200 to the RRC entity of UE100.

[0072] (PDCP layer operation) FIG. 9 is a diagram showing the operation of the PDCP layer in the mobile communication system 1 according to the first embodiment.

[0073] The gNB 200 transmits MBS data of a certain MBS session to multiple UEs 100 (UEs 100a to 100c in the example of FIG. 9) by PTM (multicast or broadcast). The RRC state of each UE 100 may be any state (RRC connected state, RRC idle state, RRC inactive state). The MBS delivery mode may be a first delivery mode or a second delivery mode. The MBS delivery in the first delivery mode may use a PTM leg.

[0074] The gNB 200 has a PDCP entity 201 associated with the MBS session in the PDCP layer (specifically, a transmitting PDCP entity associated with a multicast radio bearer (MRB) belonging to the MBS session). When the PDCP entity 201 starts transmission of the MBS session, it manages PDCP variables that are updated in response to the transmission of PDCP packets in the MBS session.

[0075] Each UE 100 has a PDCP entity 101 associated with the MBS session (specifically, a receiving PDCP entity associated with the MRB belonging to the MBS session) in the PDCP layer. When each PDCP entity 101 (PDCP entities 101a and 101b in the example of FIG. 9) starts transmission of an MBS session, it manages PDCP variables that are updated in response to reception of a PDCP packet in the MBS session.

[0076] As shown in Fig. 10, the PDCP variable may be a count value (COUNT value) consisting of a hyperframe number (HFN) that is counted up every time the PDCP sequence number goes around, and a PDCP sequence number (PDCP SN). For example, the COUNT value has a bit length of 32 bits, the PDCP SN has a bit length (SN_length) of 12 bits or 18 bits, and the HFN has a bit length obtained by subtracting the bit length of the PDCP SN from the bit length of the COUNT value. The bit length of the PDCP SN may be set by RRC signaling. Note that the term "PDCP variable" is not limited to referring to the COUNT value, but is also used as a term to refer to various variables (HFN, PDCP SN, etc.) handled in the PDCP layer.

[0077] FIG. 11 is a diagram showing a PDCP packet constituting MBS data, specifically, a PDCP data PDU (Protocol Data Unit). As shown in FIG. 11, the PDCP data PDU has a PDCP SN, data, and a MAC-I. The PDCP SN is a sequence number sequentially assigned to the PDCP data PDU. The data corresponds to a PDCP SDU (Service Data Unit). The MAC-I corresponds to a message authentication code. The PDCP data PDU may not have a MAC-I. In this way, the PDCP data PDU has a PDCP SN but does not have an HFN. Therefore, each of the gNB 200 and the UE 100 needs to update the HFN in response to transmission and reception of the PDCP data PDU, specifically, needs to count up the HFN every time the PDCP sequence number goes around once.

[0078] 12 is a diagram showing an operation of identifying RCVD_COUNT, which is the COUNT value of a received PDCP data PDU, in the UE 100 (receiving side PDCP entity 101). Here, the PDCP SN included in the received PDCP data PDU is called RCVD_SN.

[0079] First, RCVD_SN <SN(RX_DELIV)-Window_Size If RCVD_HFN = HFN (RX_DELIV) + 1 Here, RX_DELIV is a variable that indicates the oldest PDCP SDU that is waiting to be received and has not yet been provided to the upper layer. The initial value of RX_DELIV is zero. Window_Size is a constant that indicates the size of the reordering window.

[0080] Secondly, RCVD_SN≧SN(RX_DELIV)+Window_Size If RCVD_HFN = HFN (RX_DELIV) - 1 It is.

[0081] Third, if none of the above conditions are met, RCVD_HFN=HFN(RX_DELIV) It is.

[0082] and, RCVD_COUNT=[RCVD_HFN,RCVD_SN] is set to

[0083] FIG. 13 is a diagram showing the operation of the receiving PDCP entity 101 of the UE 100. As shown in FIG.

[0084] First, when the receiving PDCP entity 101 receives a PDCP PDU, it performs security processing (specifically, deciphering / integrity verification) on the PDCP PDU using a count value (RCVD_COUNT) (step S11). If the integrity verification fails (step S12: Yes), it notifies the upper layer of the failure of the integrity verification and discards the PDCP PDU (step S13).

[0085] If the integrity verification is successful (step S12: No), if the count value (RCVD_COUNT) is smaller than RX_DELIV (step S14: Yes), or if RCVD_COUNT has already been received (step S16: Yes), the receiving PDCP entity 101 discards the PDCP PDU (step S15).

[0086] Next, the receiving PDCP entity 101 stores the PDCP PDUs that were not discarded in the receiving buffer (step S17), and if "RCVD_COUNT≧RX_NEXT" (step S18: Yes), updates RX_NEXT to RCVD_COUNT+1 (step S19). Here, RX_NEXT is a variable indicating the count value (RCVD_COUNT) of the PDCP SDU expected to be received next. The initial value of RX_NEXT is zero. If out-of-order delivery is configured (step S20: Configured), the receiving PDCP entity 101 decompresses the header of the PDCP PDU and passes it to the upper layer (step S21). Specifically, the receiving PDCP entity 101 performs the operation of S21 when "outOfOrderDelivery" is set in RRC. Out of order delivery is an operation of passing a packet to the upper layer without performing order control. Therefore, as in step S21, when a packet is received and stored in a buffer, the packet is immediately passed to the upper layer. If step S20 is "No," sequence control is performed.

[0087] If "RCVD_COUNT=RX_DELIV" (step S22: Yes), the receiving PDCP entity 101 decompresses the headers of all PDCP SDUs with consecutive COUNTs starting from COUNT=RX_DELIV, passes them to a higher layer (step S23), and updates RX_DELIV to the first (youngest) COUNT value that has not been passed to a higher layer (step S24).

[0088] When the receiving-side PDCP entity 101 has T-Reordering in operation and "RX_DELIV ≧ RX_REORD" (step S25: Yes), it stops and resets T-Reordering (step S26). Here, T-Reordering is a timer used to detect the loss of PDCP data PDUs. RX_REORD is a variable indicating the COUNT value following the COUNT value associated with the PDCP data PDU that triggered T-Reordering.

[0089] When the receiving-side PDCP entity 101 has T-Reordering stopped and "RX_DELIV < RX_REORD" (step S27: Yes), it updates RX_REORD = RX_NEXT and starts T-Reordering.

[0090] (Operation of the mobile communication system) Based on the above-described configuration and operation, the operation of the mobile communication system 1 according to the first embodiment will be described.

[0091] In the operation scenario shown in FIG. 9, the UE 100 (any one of UE100a to UE100c) does not necessarily start MBS reception immediately when the gNB 200 starts providing an MBS session (multicast session or broadcast session). For example, any UE 100 may start MBS reception in the middle of an MBS session. In that case, the UE 100 cannot receive each packet (e.g., each PDCP data PDU) from the start of the MBS session (start of provision) to the start of MBS reception, and each such packet is in a state of being missing.

[0092] Here, if the MBS session is a session for streaming data distribution, the loss of packets does not cause any problem. On the other hand, if the MBS session is a session for downloading a file such as software distribution, it is a problem if the file is incomplete. The first embodiment is an embodiment that enables the retransmission of a group of lost packets to the UE 100 in the AS layer.

[0093] Fig. 14 is a diagram showing the operation of UE 100 according to the first embodiment. The RRC state of UE 100 may be any state (RRC connected state, RRC idle state, RRC inactive state). However, UE 100 is assumed to be in the RRC connected state at the time of transmission to gNB 200. The MBS delivery mode may be the first delivery mode. Also, the MBS delivery mode may be the second delivery mode.

[0094] In step S1, UE 100 starts receiving an MBS session (multicast session or broadcast session) from gNB 200. That is, UE 100 starts receiving MBS data transmitted by PTM from gNB 200 (MBS reception). When starting MBS reception, UE 100 establishes a receiving side PDCP entity 101 that handles a multicast radio bearer (MRB) associated with the MBS session.

[0095] In step S2, the UE 100 determines whether a predetermined condition indicating that the MBS reception has started in the middle of the MBS session is satisfied. If it is determined that the predetermined condition is not satisfied (step S2: No), the UE 100 continues the MBS reception without performing the processes of steps S3 and S4.

[0096] The predetermined condition may be a condition that the UE 100 has joined the MBS session halfway through. The UE 100 can determine that the UE 100 has joined the MBS session halfway through, for example, by any one of the following methods 1 to 10.

[0097] Method 1: In the case of the first distribution mode (DM1), if MBS setting (e.g., MRB setting) is performed by RRC Reconfiguration from the gNB 200 within a certain period (e.g., immediately after) after participating in an MBS session by a NAS procedure, the UE 100 can determine that the UE 100 has participated in the MBS session midway (high probability), and if MBS setting is performed after the certain period, the UE 100 can determine that the UE 100 has participated in the MBS session from the beginning (high probability). The certain period may be set in the UE 100 by the gNB 200 or the AMF 300A. The certain period may be a timer value (e.g., a timer value indicating a time range) or a counter value (e.g., a counter value indicating a range of system frame numbers).

[0098] Method 2: In the case of the first distribution mode (DM1), after joining an MBS session through a NAS procedure, UE100 monitors a Group Notification (paging) indicating the start (activation) of the MBS session, and if MBS setting (e.g., MRB setting) is performed by RRC Reconfiguration after receiving a Group Notification, it can determine that the UE has joined the MBS session from the beginning, and if MBS setting (e.g., MRB setting) is performed by RRC Reconfiguration without receiving a Group Notification, it can determine that the UE has joined the MBS session midway (highly likely).

[0099] Method 3: In the case of the second distribution mode (DM2), if UE100 receives a Change Notification (MCCH change notification) associated with the start of a session and then receives a corresponding MBS setting (e.g., MTCH scheduling setting) on ​​the MCCH, it can determine that it has participated in the MBS session from the beginning.If UE100 does not receive a Change Notification and checks the MCCH to find that the corresponding MBS setting already exists, it can determine that it has participated in the MBS session partway through.

[0100] Method 4: In an MBS session participation procedure using a NAS procedure, when AMF300A grants permission to a participation request from UE100, UE100 can determine whether it has joined the MBS session from the beginning or in the middle by obtaining information from AMF300A indicating that the session is in transmission (active) or information indicating that the session is stopped (suspended, inactive, or configured).

[0101] Method 5: If the (approximate) start time of the MBS session is described in the USD (User Service Description) that UE100 holds in advance, UE100 can determine from the information in the USD whether it has joined the MBS session from the beginning or joined midway through.

[0102] Method 6: When the UE 100 is notified from a higher layer (for example, an application layer) that the file is not complete (that restoration is impossible), the UE 100 can determine that the UE 100 has joined the MBS session halfway through. The notification may be notified from the application layer to the NAS layer, and from the NAS layer to the AS layer.

[0103] Method 7: In the UE 100, when the AS layer is notified by the NAS layer that the UE 100 has joined the MBS session midway, the AS can recognize that the UE 100 has joined the MBS session midway.

[0104] Method 8: The UE 100 may be notified that the MBS session is in progress (or has already started) by the gNB 200. For example, in the case of the first distribution mode (DM1), when the gNB 200 performs MBS setting (e.g., MRB setting) in RRC Reconfiguration, the UE 100 is notified of a "participation in progress flag" (or a "flag indicating participation from the beginning") associated with the MBS setting (e.g., MRB setting) to determine whether or not the UE 100 is participating in the session in progress.

[0105] Method 9: The gNB 200 notifies or provides information (may be notified by SIB and / or MCCH, or may be RRC Reconfiguration) to the UE 100 that file recovery of the MBS session (for example, the MRB) is possible (or that past data of the MBS session is held, or that file recovery of the MBS session is permitted), and the UE 100 may determine that it has implicitly joined the MBS session midway based on the notification. Such a notification may be a notification in a first modified example described later.

[0106] Method 10: A one-bit flag indicating whether the packet is the first packet or an intermediate packet (or not the first packet) in the session may be defined in the header of the MBS data (e.g., the header of the PDCP data PDU). The UE 100 receives the MBS data and can determine whether or not the UE 100 has joined the MBS session midway based on the flag stored in the header of the MBS data.

[0107] The predetermined condition may be a condition that the sequence number (SN) of the MBS packet that UE 100 receives first for the MBS session is not an initial value. For example, when the PDCP SN included in the PDCP data PDU that UE 100 receives first for the MBS session is not zero, UE 100 may determine that MBS reception has started in the middle of the MBS session. Here, zero is an example of an initial value. Note that the determination may be made using not only the PDCP SN but also the RLC SN, but an example in which the sequence number is the PDCP SN will be mainly described below. Also, the sequence number may be the above-mentioned COUNT value (HFN+PDCP SN).

[0108] When it is determined that the predetermined condition is satisfied (step S2: Yes), in step S3, UE100 transmits missing packet identification information indicating a group of packets that are missing from the start of the MBS session to the start of MBS reception to gNB200. The missing packet identification information includes information indicating a sequence number (e.g., PDCP SN) of the last missing packet of the group of missing packets. This allows gNB200 to know up to which packet (e.g., PDCP data PDU) UE100 has not been able to receive. The information indicating the sequence number of the last missing packet may be the sequence number of the last missing packet itself. Alternatively, the information indicating the sequence number of the last missing packet may be a value obtained by adding 1 to the sequence number of the last missing packet (i.e., the sequence number of the packet first received by UE100).

[0109] Here, the UE 100 (receiving PDCP entity 101) may transmit a PDCP control PDU including the missing packet identification information as a PDCP status report to the transmitting PDCP entity 201 of the gNB 200. Since there is a one-to-one relationship between a bearer (MRB) and a PDCP entity, the missing packet identification information can be smoothly notified to the gNB 200 by transmitting the PDCP status report on the bearer. For example, as shown in Fig. 8, the UE 100 may receive MBS data in a PTM leg and transmit a PDCP status report to the gNB 200 in a PTP leg.

[0110] Alternatively, the UE 100 may transmit an RRC message including missing packet identification information and an identifier associated with the missing packet identification information to the gNB 200. The identifier may include at least one of an MBS session identifier of the MBS session and an identifier related to an MRB to which the MBS session is mapped (e.g., an MRB identifier, an MTCH identifier, or a QoS flow identifier, etc.). The RRC message may be, for example, an MBS Interest Indication message or a UE Assistance Information message.

[0111] Upon receiving missing packet identification information from UE 100, gNB 200 transmits (retransmits) to UE 100 the group of missing packets indicated by the missing packet identification information.

[0112] In step S4, UE 100 receives the missing packets from gNB 200. UE 100 may receive the missing packets transmitted from gNB 200 by PTP. For example, UE 100 may receive MBS data in a PTM leg and receive the missing packets retransmitted by gNB 200 in a PTP leg as shown in Fig. 8. However, UE 100 may receive the missing packets retransmitted by gNB 200 in a PTM leg.

[0113] In this way, according to the first embodiment, when the UE 100 determines that a predetermined condition indicating that MBS reception has started in the middle of an MBS session is satisfied, the UE 100 transmits missing packet identification information indicating a group of packets that have been missed from the start of the MBS session to the start of the MBS reception to the gNB 200. This enables the gNB 200 to retransmit the group of missing packets to the UE 100.

[0114] FIG. 15 is a diagram showing an example of the operation of the mobile communication system 1 according to the first embodiment.

[0115] In step S101, the gNB 200 starts providing an MBS session (multicast session or broadcast session). Specifically, the gNB 200 starts transmitting MBS data in PTM for the MBS session. FIG. 15 shows an example in which another UE interested in receiving the MBS session starts MBS reception from the start of the MBS session (step S102). The sequence number (SN) of the packet first received by the other UE is assumed to be zero.

[0116] In addition, the gNB 200 prepares for retransmission of a group of missing packets by storing the transmitted packets in association with their sequence numbers. For example, the transmitting PDCP entity 201 of the gNB 200 transmits a PDCP data PDU including a PDCP SN and stores a copy of the PDCP data PDU in a buffer.

[0117] In step S103, the UE 100 starts receiving the MBS session. It is assumed that the sequence number (SN) of the packet that the UE 100 receives first is X.

[0118] In step S104, UE 100 identifies a missing packet group. UE 100 may check the SN of the packet first received from gNB 200 and detect that data is missing. For example, assuming that gNB 200 starts transmission from SN=0, if the packet that UE 100 first receives from gNB 200 is SN=100, it can be determined that a packet group with SN=0 to 99 is missing.

[0119] In step S105, the UE 100 transmits missing packet identification information indicating the group of missing packets identified in step S103 to the gNB 200. The UE 100 transmits the missing packet identification information to the gNB 200 by a PDCP control PDU (PDCP status report) or an RRC message.

[0120] 16 shows configuration examples 1 to 3 of a PDCP status report according to the first embodiment. At the beginning of a PDCP control PDU (PDCP status report), a D / C field indicating that the PDCP PDU is a control PDU and a PDU type field indicating that the PDCP PDU is a PDCP status report may be provided. Information indicating that the PDCP status report is dedicated to MBS may be set in the PDU type field.

[0121] In the first example configuration, the PDCP status report includes the fields of FMC (First missing COUNT) and bitmap. The FMC field is set to the COUNT value of the first missing PDCP SDU in the reordering window, i.e., RX_DELIV. The bitmap field is set to a bit associated with each PDCP PDU, and is set to "1" if the PDU was received correctly and "0" if the PDU was missing.

[0122] In the second configuration example, the PDCP status report includes the fields of FMC and LMC (Last missing COUNT). The sequence number (COUNT value) of the last packet of the missing packets is set in the LMC field. The COUNT value (LMC+1, for example, First Successful COUNT: FSC) of the first successfully received packet may be set in the LMC field. In the first configuration example described above, the bit length of the bitmap field may be long (for example, a bitmap for 200 packets is 200 bits), but by providing the LMC field instead of the bitmap field, the bit length of the PDCP status report can be shortened.

[0123] In the configuration example 3, the PDCP status report includes an LMC field. Since the gNB 200 knows the first transmission packet (corresponding to FMC), if the LMC is known, it can grasp the extent of data loss. According to the configuration example 3, the bit length of the PDCP status report can be shortened compared to the configuration example 2 by eliminating the need for the FMC field.

[0124] 17 shows a configuration example of an RRC message according to the first embodiment. For example, the RRC message may be an MBS Interest Indication message or a UE Assistance Information message transmitted by the UE 100 to the gNB 200.

[0125] The RRC message includes an MRB identifier (bearer ID, RLC channel ID, LCID, etc.) or an MBS session identifier (TMGI, etc.) and missing packet identification information. The configuration of the missing packet identification information may be similar to the configuration of the PDCP status report described above. To generate such an RRC message at the RRC layer, the receiving PDCP entity 101 of the UE 100 may provide information about the missing packets to the RRC layer.

[0126] Returning to FIG. 15, gNB200 receives missing packet identification information from UE100 in step S105.

[0127] In step S106, the gNB 200 transmits (retransmits) the missing packet group indicated by the missing packet identification information to the UE 100. The UE 100 receives the missing packet group from the gNB 200.

[0128] Note that there may be cases where gNB 200 is unable to retransmit all of the missing packets to UE 100 due to limitations in the buffer capacity of gNB 200, etc. Only in such cases may UE 100 attempt file recovery using an upper layer mechanism such as FLUTE (File Delivery over Unidirectional Transport). FLUTE is an upper layer data recovery mechanism defined in IETF RFC6726 / RFC3926, and UE 100 later obtains the missing data (FLUTE Block) from an application server by unicast.

[0129] [First change example] Considering the limitation of the buffer capacity of the gNB 200, it is considered undesirable for the UE 100 to be able to unlimitedly request retransmission from the gNB 200. For this reason, the gNB 200 may transmit, to the UE 100, information for controlling the transmission of missing packet identification information by the UE 100.

[0130] 18 is a diagram showing a first modified example of the operation of the mobile communication system 1 according to the first embodiment. Here, differences from the above-described first embodiment will be described.

[0131] In step S131, the gNB 200 transmits to the UE 100 control setting information for controlling transmission of missing packet identification information by the UE 100. The gNB 200 may transmit the control setting information to the UE 100 in a SIB, an MCCH, an RRC message (RRC Reconfiguration message), a MAC header, a MAC CE (Control Element), or a PDCP control PDU. The gNB 200 may transmit to the UE 100 an identifier associated with the control setting information together with the control setting information. The identifier may include at least one of an MBS session identifier of an MBS session and an identifier related to an MRB to which the MBS session is mapped (for example, an MRB identifier, an MTCH identifier, or a QoS flow identifier, etc.).

[0132] For example, in step S131, gNB200 may transmit, as control configuration information to UE100, range information indicating a range of sequence numbers of a group of missing packets that UE100 is permitted to indicate by the missing packet identification information. In step S105, UE100 may transmit missing packet identification information indicating a group of missing packets within a range specified by gNB200, based on the range information from gNB200.

[0133] In this way, the gNB 200 sets or notifies the UE 100 of a range of past SNs (for example, within 1,000 packets (SNs)) that may be notified for data recovery. The range may be determined according to the data buffer amount (capability) of the gNB 200. The gNB 200 may transmit information indicating the smallest sequence number of data buffered by the gNB 200 as range information. The gNB 200 may also transmit information indicating the number of packets of data buffered by the gNB 200 as range information. The UE 100 transmits missing packet identification information to the gNB 200 within the range set or notified by the gNB 200. For example, the UE 100 may set a lower limit value of the range as an FMC to be included in the missing packet identification information. Alternatively, the UE 100 may decide not to transmit the missing packet identification information to the gNB 200 when the group of missing packets identified by the UE 100 exceeds the range set or notified by the gNB 200. In that case, the UE 100 may decide to execute file recovery (FLUTE, etc.) of the upper layer as described above. Here, in the UE 100, the AS layer may report to an upper layer (NAS or an application) that file recovery in the AS layer is impossible (integrity cannot be guaranteed).

[0134] Alternatively, in step S131, the gNB 200 may transmit, as control configuration information, notification information indicating whether or not the gNB 200 holds (buffers) the first delivery packet of the MBS session to the UE 100. The UE 100 may determine whether or not to transmit missing packet identification information to the gNB 200 based on the notification information from the gNB 200. If the gNB 200 does not hold the first delivery packet, data recovery at the AS layer cannot fully recover the packet. Therefore, if the notification information indicates that the gNB 200 does not hold the first delivery packet, the UE 100 may determine not to transmit the missing packet identification information to the gNB 200. In contrast, if the notification information indicates that the gNB 200 holds the first delivery packet, the UE 100 may transmit the missing packet identification information to the gNB 200 (step S105). The notification information may be information indicating whether or not the gNB 200 holds a delivery packet with a sequence number of zero as the first delivery packet. In other words, the notification information may be information notifying whether or not retransmission is possible from the first packet.

[0135] [Second modification example] In order for UE100 to transmit missing packet identification information to the gNB200 as a PDCP control PDU (PDCP status report), it is necessary for UE100 to have a PTP communication path with the gNB200. For example, the PTP communication path may be the PTP leg shown in Fig. 8. Therefore, UE100 that does not have a PTP communication path with the gNB200 may request the gNB200 to establish a PTP communication path so as to be able to transmit missing packet identification information to the gNB200.

[0136] 19 is a diagram showing a second modified example of the operation of the mobile communication system 1 according to the first embodiment. Here, differences from the above-described first embodiment will be described.

[0137] In step S151, when the UE 100 does not have a PTP communication path associated with the MBS session, that is, when the UE 100 is receiving MBS data in an MRB with only PTM, the UE 100 transmits request information to the gNB 200 to request the establishment of a PTP communication path. The UE 100 may transmit the request information to the gNB 200 by an RRC message transmitted on a signaling radio bearer (SRB). The RRC message may be an MBS Interest Indication message or a UE Assistance Information message. The request information may be information requesting the establishment of a PTP leg, information indicating that data recovery is desired, information indicating that uplink transmission is required, or information indicating that a split MRB is required. The RRC message may further include an identifier associated with the request information. The identifier may be a bearer ID, an RLC Channel ID, an LCID, or an MBS session identifier (e.g., TMGI) of the target MRB.

[0138] In step S152, the gNB 200 sets a PTP communication path to the UE 100 in response to receiving the request information from the UE 100. For example, the gNB 200 may change the setting of the MRB to a split MRB. The gNB 200 may also change the setting of the MRB to a PTP-only MRB.

[0139] In step S105, UE100 transmits a PDCP status report to gNB200 on the PTP communication path established in step S152.

[0140] [Second embodiment] The second embodiment will be described mainly with respect to the differences from the above-mentioned first embodiment.

[0141] A data radio bearer (DRB) is classified into either an AM DRB or a UM DRB depending on whether the corresponding RLC mode is AM (Acknowledged Mode) or UM (Unacknowledged Mode). Specifically, the UE 100 determines that the DRB is an AM DRB when the mode of the RLC entity associated with the DRB is AM, and determines that the DRB is a UM DRB when the mode of the RLC entity associated with the DRB is UM. For example, the trigger condition of a PDCP status report for a DRB differs depending on whether the DRB is an AM DRB or a UM DRB.

[0142] Here, there are two legs for split MRB and two corresponding RLC entities (see Figure 8). For example, PTM leg supports only UM, and PTP leg supports both AM and UM RLC modes. Therefore, it is considered necessary to have a method to determine whether the split MRB is an AM bearer or a UM bearer.

[0143] FIG. 20 is a diagram showing an operation of the UE 100 according to the second embodiment.

[0144] In step S201, the UE 100 receives configuration information for configuring a split radio bearer (split MRB) split into a PTP leg and a PTM leg from the gNB 200. Such configuration information may be transmitted from the gNB 200 to the UE 100 by UE-dedicated RRC signaling (e.g., an RRC Reconfiguration message). Here, the RLC modes of the RLC entity handling the PTP leg and the RLC entity handling the PTM leg are configured in the UE 100 by the gNB 200.

[0145] In step S202, the UE 100 determines whether the configured split radio bearer (split MRB) is an AM bearer (AM MRB) or a UM bearer (UM MRB) based on the RLC mode configured for each leg. For example, the UE 100 may determine that the configured split radio bearer (split MRB) is an AM bearer (AM MRB) depending on the RLC mode configured for the PTP leg or the PTM leg being AM. The UE 100 may determine that the configured split radio bearer (split MRB) is a UM bearer (UM MRB) depending on the RLC mode configured for the PTP leg or the PTM leg being UM.

[0146] Specifically, for a configured split MRB, the UE 100 may determine that the split MRB is an AM MRB if the RLC entity of the PTP leg is configured in AM or if the RLC entity of the PTM leg is configured in AM. The UE 100 may determine that the split MRB is an AM MRB if the PTP leg is configured in bi-directional UM and / or if the PTM leg is configured in bi-directional UM.

[0147] For a configured split MRB, the UE 100 may determine that the split MRB is a UM MRB if the RLC entity of the PTP leg is configured in UM and the RLC entity of the PTM leg is configured in UM. The UE 100 may determine that the split MRB is a UM MRB if the PTP leg is configured in uni-directional UM and the PTM leg is configured in uni-directional UM.

[0148] As a modification of the second embodiment, the gNB 200 may set whether the split MRB is an AM MRB or a UM MRB (i.e., which mode it is considered to be) to the UE 100. The UE 100 may determine whether the split MRB is an AM MRB or a UM MRB according to the set MRB mode.

[0149] Specifically, the gNB 200 explicitly configures the UE 100 as to whether the MRB is to be regarded as an AM MRB or as a UM MRB. For example, when the gNB 200 configures the UE 100 with a split MRB by RRC Reconfiguration, the gNB 200 includes a mode identifier (AM MRB or UM MRB) associated with the split MRB in the configuration. The UE 100 determines whether the split MRB is an AM MRB or a UM MRB based on the mode identifier.

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

[0151] In the above-mentioned 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 be a relay node such as an IAB (Integrated Access and Backhaul) node. The base station may be a DU of the IAB node. The user equipment may be an MT (Mobile Termination) of the IAB node.

[0152] A program may be provided that causes a computer to execute each process performed by UE100 or gNB200. The program may be recorded in a computer-readable medium. Using the computer-readable medium, it is possible to install the program in 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, and may be, for example, a recording medium such as a CD-ROM or a DVD-ROM. In addition, a circuit that executes each process performed by UE100 or gNB200 may be integrated, and at least a part of UE100 or gNB200 may be configured as a semiconductor integrated circuit (chip set, SoC: System on a chip).

[0153] As used in this disclosure, the terms "based on" and "depending on" do not mean "based only on" or "depending only on," unless otherwise specified. 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 "based at least in part on." Additionally, "obtain / acquire" may mean obtaining information from stored information, from information received from other nodes, or by generating information. The terms "include," "comprise," and variations thereof do not mean including only the items listed, but may include only the items listed, or may include additional items in addition to the items listed. Additionally, the term "or" as used in this disclosure is not intended to be an exclusive or. Additionally, any reference to elements using designations such as "first," "second," etc., as used in this disclosure is not intended to 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 a first and a second element does not imply that only two elements may be employed therein or that the first element must precede the second element in some manner. In this disclosure, where articles are added by translation, such as a, an, and the in English, these articles are intended to include the plural unless the context clearly indicates otherwise.

[0154] 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, etc. are possible without departing from the spirit of the invention.

[0155] This application claims priority to U.S. Provisional Application No. 63 / 229158 (filed August 4, 2021), the entire contents of which are incorporated herein by reference.

[0156] [Note] 1. Introduction A revised work item on NR Multicast and Broadcast Services (MBS) was approved in RAN#88, which includes the objectives of specifying dynamic PTM / PTP switching and mobility with service continuity as follows: Specifies the basic RAN functions for broadcast / multicast for UE in RRC connected state. It specifies support for dynamic change of broadcast / multicast service delivery between multicast (PTM) and unicast (PTP) with service continuity for a particular UE. Provide support for basic mobility with service continuity.

[0157] Regarding dynamic PTM / PTP switching, RAN2 has already reached some agreements related to this topic. RAN2#111-e had the following agreements: For the UE, the gNB dynamically decides whether to deliver multicast data via PTM or PTP (shared delivery). More work is needed on how the layer handles reliability (in general), in-order delivery / duplicate handling, and how it works with switching between PTM and PTP.

[0158] In RAN2#113-e, the architecture for dynamic PTM / PTP switching was agreed upon in conjunction with discussions on L2 reliability as follows: When both PTM and PTP are RLC UM, configuration with no L2 ARQ and switching between PTM and PTP with fixed PDCP is supported (e.g. for services normally configured with RLC UM for unicast).

[0159] For RAN2#113bis-e further agreement was reached on architecture and signalling as follows: agreement Please note that the following agreements are based only on architectural decisions so far. The reliability discussion is not over yet, i.e. cases other than RLC UM+RLC UM. The switch between PTM and PTP in these other cases requires further study. Dynamic PTM / PTP switching is supported for split MRB bearers (types) with a common (single) PDCP entity. As a basis, no new UE-based signaling is introduced to support gNB switch decisions (e.g., PDCP SR for high reliability is pending). Assuming a split MRB configured on the PTM leg and the PTP leg (agreed during the online session), the use of the PTP leg cannot be deactivated after the required split MRB configuration (i.e. the UE must always monitor the C-RNTI). Considering a split MRB set up with a PTM leg and a PTP leg (agreed upon during an online session), whether and how the use of the PTM leg of the split MRB is subject to activation or deactivation requires further study.

[0160] Regarding the mobility aspect, RAN2 only agreed to the basic principles listed below: R2 is intended to support lossless handover for MBS-MBS mobility for services that require this (scenario details are yet to be determined, at least PTP-PTP). To support lossless handover of 5G MBS services, at least DL PDCP SN synchronization and continuity between source and target cells must be guaranteed on the network side. The design of specific approaches to achieve this may be of interest to WG RAN3. From the network side, the source gNB may forward data to the target gNB, and the target gNB delivers the forwarded data. Meanwhile, the SN STATUS TRANSFER needs to be extended to cover the PDCPSN of the MBS data. Then, the UE receives the MBS in the target cell by the target cell according to the target configuration. From the UE side, PDCP status reporting may also be supported.

[0161] This appendix describes the remaining issues of dynamic PTM / PTP switching and mobility with service continuity based on the agreed architecture, i.e. using split MRB anchored to PDCP.

[0162] 2. Discussion 3. Split MRB Settings The architecture of PTM / PTP switching anchored to PDCP, i.e. split MRB, can be interpreted as shown in Figure 21 based on the current agreement.

[0163] In general, RRC reconfiguration can be considered to be used to provide a bearer configuration including two logical channels (PTM leg and PTP leg) along with information for receiving a multicast session. Although RAN2 states that "a split MRB (agreed in online session) configured with PTM leg and PTP leg is assumed", it seems to be commonly understood that the configuration associating two logical channels to one multicast radio bearer is provided by RRC reconfiguration in preparation for dynamic PTM / PTP switching.

[0164] Observation 1: It appears to be a common understanding that the configuration of associating two logical channels to one MRB is provided by RRC reconfiguration prior to dynamic PTM / PTP switching operations.

[0165] 4. Dynamic PTM / PTP switching operation 5. Signaling Whether and how the use of the PTM leg of a split MRB may be subject to activation or deactivation requires further study.

[0166] When a split MRB with PTM leg / PTP leg is configured, the UE needs to monitor both the G-RNTI of the PTM leg and the C-RNTI of the PTP leg. In LTE SC-PTM, the SC-PTM reception opportunity is independent of the unicast DRX scheme, i.e., the DRX is separate. This concept could be the basis for NR MBS, since the G-RNTI is received by multiple UEs, whereas the C-RNTI is UE-specific, and the alignment of the two DRXs is very difficult. This means that if the UE has to constantly monitor the G-RNTI, it will need to wake up frequently, which will cause additional power consumption. On the other hand, a connected UE needs to monitor the C-RNTI, i.e., the C-DRX, for unicast reception, but this is not an additional burden for the UE.

[0167] Observation 2: The UE needs to wake up on PTM leg transmission opportunities (i.e., G-RNTI) like SC-MTCH opportunities in LTE SC-PTM in addition to the same PTP leg transmission opportunities (i.e., C-RNTI) as C-DRX.

[0168] When receiving an MRB with PTM / PTM, that is, when switching, there are four options:

[0169] Option 1: Activation / Deactivation-Based Switching The gNB instructs the UE to activate / deactivate the PTM leg by DCI, MAC CE, or RRC signaling, etc. This option can be more flexible when MBS data is received over two legs, such as split bearer or PDCP packet duplication, in addition to MBS data reception over either PTM or PTP. The UE can reduce power consumption from the deactivated PTM leg. Note that the NW implementation may decide to keep two legs active at all times, which can cover the intent of option 4 below.

[0170] Option 2: Switching Order / Command-Based Switching The gNB instructs the UE to switch between the PTM leg and the PTP leg by DCI, MAC CE, or RRC signaling. This option is similar to option 1 above and is simple in terms of power saving by deactivating the PTM leg. However, it lacks flexibility in split bearer-like operation including duplication of PDCP packets. This option seems to only switch between the PTM leg and the PTP leg, but not to activate both.

[0171] Option 3: RRC reconfiguration based switching The gNB reconfigures the UE as either PTM or PTP MRB via RRC reconfiguration, i.e. it does not associate PTM and PTP legs with one MRB, i.e. it is like a "bearer type change" and is inconsistent with the split MRB architecture. Also, this option involves L3, so it is questionable how "dynamic" the switch between PTM and PTP can be.

[0172] Option 4: No signaling based switching The UE must always attempt to receive from both the PTM and PTP legs when a split MRB has two legs configured. This option ensures maximum scheduling flexibility from the gNB's perspective, but does not provide any power saving opportunities for the UE.

[0173] In conclusion, option 1 is the most suitable option in terms of scheduling flexibility, UE power consumption, and compatibility with the split MRB architecture. Option 4 can be considered as a subset of option 1, if the PTM leg is always active. For the signaling layer, MAC CE may be easy, since activation / deactivation is mostly related to DRX operation. Therefore, RAN2 should agree that the PTM leg can be activated / deactivated via MAC CE.

[0174] Proposal 1: For dynamic PTM / PTP switching, RAN2 should agree to introduce a MAC CE to activate / deactivate the PTM leg of the split MRB.

[0175] Regarding "bearer type change," which is different from dynamic switching, the following cases are considered to be involved in bearer type change. Case 1: PTM-only MRB ←→ PTP-only MRB Case 2: Split MRB <-> PTM-only MRB Case 3: Split MRB <-> PTP-only MRB

[0176] In such a case of bearer type change, it is easier to use RRC reconfiguration, i.e. option 3.

[0177] Proposal 2: For bearer type changes between PTM-only MRB, PTP-only MRB, and split MRB, RAN2 should agree to use RRC reconfiguration.

[0178] 6. PDCP Actions 7. Initial values ​​of state variables In addition to RLC UM mode, RAN2 agreed to support RLC AM mode for the PTP leg of split MRB. It is also commonly understood that L2 reliability depends only on dynamic PTM / PTP switching because "RLC-AM does not support PTM (for MBS R17 WI)". Therefore, it is worth considering how to reduce packet loss when starting to receive MBS data or when switching dynamically between PTM / PTP for service continuity.

[0179] As shown in Figure 21, if the existing PDCP functional view is reused, the PDCP SN is common for the PTM leg and the PTP leg. Since the PTM leg is used by multiple UEs, the PDCP SN may not be UE specific and affects both the PTM leg and the PTP leg. This means that if a UE joins a multicast session late, the initial value of each state variable cannot always be "0", regardless of whether the first received MBS data comes from the PTM leg or the PTP leg. In other words, the PDCP SN that the UE first receives may be any value that is not expected for this unicast transmission. Also, since the state variables are set to their initial values, the PDCP re-establishment of one UE may affect all other UEs. This will result in unexpected behavior in the receiving window, i.e., discarding PDCP PDUs outside the window. It has been pointed out that the same problem may exist in handover scenarios.

[0180] Observation 3: For a UE that joins a multicast session late and has split MRB configured, it has been observed that the SN of the first received PDCP PDU is not the initial value (i.e., "0") regardless of whether it is on a PTM leg or a PTP leg.

[0181] To solve this problem, the following options are proposed:

[0182] Option A: The gNB notifies the UE of the initial value of COUNT, or RX_NEXT and RX_DELIV. This option simply modifies the initial value for the reception window based on information from the gNB so that the UE can receive the first transmission of MBS data with existing mechanisms. However, from the PDCP layer point of view, it is questionable whether the UE can always successfully receive the first transmission intended by the gNB due to switching delays, poor radio conditions, being outside the RLC reconstruction window, etc. It is unclear how this option works in this case.

[0183] Option B: The gNB informs the UE of the initial HFN, and the UE infers the initial HFN and SN from the first received PDCP PDU. For the SN part, the options are the same as those of the V2X mechanism in Rel-16, namely: “The initial value of the SN part of RX_NEXT is (x+1) modulo(2 [sl-PDCP-SN-Size] ), where x is the SN of the first received PDCP data PDU. In NR sidelink communication for broadcast and groupcast, the initial value of the SN part of RX_DELIV is (x-0.5×2 [sl-PDCP-SN-Size-1] )modulo(2 [sl-PDCP-SN-Size] ), where x is the SN of the first received PDCP Data PDU.”

[0184] For the HFN part, the Rel-16 V2X mechanism does not require transmitter and receiver synchronization since it does not use HFN for security purposes. That is, "NOTE: It is up to the UE implementation to select the HFN for RX_NEXT so that the initial value of RX_DELIV is a positive value." For NR MBS, "RAN2 responds that it will wait for SA3 to complete the study on security of MBS before discussing security aspects in RAN2." Therefore, RAN2 should postpone the discussion of the HFN part until SA3 completes the study on security.

[0185] For the above reasons, further discussion should be carried out based on option B. According to Rel-16 sidelink communication of broadcast and groupcast, and taking into account the progress of SA3 on security of NR MBS, RAN2 should at least agree that the UE sets the initial value of the state variables from the first received PDCP PDU of MBS data.

[0186] Proposal 3: RAN2 should agree to set the initial value of the SN part of RX_NEXT and RX_DELIV from the first MBS data received by the UE, regardless of the PTM leg or PTP leg. Whether the HFN part is notified by the gNB depends on the progress of SA3 and needs further consideration.

[0187] 8. Simultaneous reception and UE assistance information In particular, PTP (legs) are configured in RLC AM for services that require reliability, and lossless switching is important for service continuity as well as lossless mobility. If proposal 1 is agreed upon, the UE needs to support simultaneous reception from both PTM and PTP legs, i.e., two legs can be activated at the same time, similar to the existing PDCP packet duplication. This is because the PTM leg is received by multiple UEs and can easily not be the optimal MCS for a particular UE. Therefore, RAN2 should agree to adopt the use of simultaneous reception at least for a certain period of time during dynamic PTM / PTP switching.

[0188] Proposal 4: RAN2 should agree that the UE supports simultaneous reception from both the PTM leg and the PTP leg for a certain period of time after dynamic PTM / PTP switching.

[0189] If Proposal 3 and Proposal 4 are agreed, there is a possibility that the gNB does not actually know whether the UE has started to receive which PDCP SN through the PTM leg successfully. When switching from PTP to PTM, the gNB may not know which PDCP PDUs it should send on the PTP leg and when it can stop sending on the PTP leg. To solve this problem, it is proposed that the UE should notify the gNB of successful PTM reception and send it through the PTP leg. However, it is unclear whether the UE should also include the PDCP SN information in the same message.

[0190] Observation 4: When switching from PTP to PTM, the gNB may not know from which PDCP PDUs it needs to keep transmitting on the PTP leg or from which PDCP PDUs the UE can successfully start receiving on the PTM leg.

[0191] Similarly, when switching from PTM to PTP, the gNB may not know which PDCP SN the UE successfully received over the PTM leg (especially if the UE is in poor radio conditions), which means that the gNB may not know which PDCP PDU to use at the start of the PTP leg.

[0192] Observation 5: When switching from PTM to PTP, the gNB may not know from which PDCP PDU the PTP leg needs to start transmitting, or which PDCP PDU the UE has successfully received over the PTM leg.

[0193] Therefore, it is considered that the UE notifies the gNB of the SN information via the PTP leg during dynamic PTM / PTP switching. When the UE reports the SN information during dynamic switching between PTM and PTP, it is easy to reuse the PDCP control PDU, i.e., the PDCP status report including FMC (first PDCP SDU not found) and optional bitmap (indicating whether subsequent PDCP SDUs are missing or correctly received). On the other hand, it is also an option for the UE to report the SN of the first / last PDCP PDU successfully received via the PTM leg. Therefore, further discussion is required on what the UE reports during dynamic switching between PTM and PTP.

[0194] In both of the above cases (i.e., switching from PTP to PTM and switching from PTM to PTP), upon dynamic switching (e.g., activation / deactivation of MAC CE), a PDCP control PDU containing PDCP SN information for service continuity needs to be triggered.

[0195] Proposal 5: RAN2 should consider whether UE should send PDCP control PDU including PDCP SN information during dynamic switching for service continuity. Whether PDCP information report can be reused needs further study.

[0196] Another issue is whether lossless bearer type change is necessary, similar to lossless dynamic switching as in proposal 5. Bearer type change including PTP (leg) with RLC AM is considered to require reliability similar to dynamic switching from the viewpoint of service continuity and lossless mobility. Therefore, RAN2 should consider whether to support lossless bearer type change. If it does, PDCP control PDU should be reused as UE assistance information, similar to proposal 5.

[0197] Proposal 6: RAN2 should discuss whether lossless bearer type change with RRC reconfiguration, i.e. the same solution as lossless dynamic switching by PDCP control PDU as in Proposal 5, is applicable. [Explanation of symbols]

[0198] 1: Mobile communication systems 10:RAN 20 :CN 100:UE 110: Receiving unit 120: Transmitter 130: Control section 200: gNB 210: Transmission unit 220: Receiving unit 230: Control section 240: Backhaul communication unit

Claims

1. A communication method for use in a mobile communication system supporting a Multicast Broadcast Service (MBS), comprising: A user equipment receives from a network node a configuration of a multicast radio bearer associated with a radio link control (RLC) entity for point-to-point (PTP) transmission and a point-to-multipoint (PTM) transmission; and treating the multicast radio bearer as an AM (Acknowledged Mode) multicast radio bearer by the user equipment in response to the RLC entity for the PTP transmission being an AM RLC entity. Communication methods.

2. The user equipment treats the multicast radio bearer as a UM multicast radio bearer in response to the RLC entity for the PTP transmission being a UM (Unacknowledged Mode) RLC entity and the RLC entity for the PTM transmission being a UM RLC entity. The communication method according to claim 1 .

3. The user equipment treats the multicast radio bearer as an AM multicast radio bearer in response to the RLC entity for the PTP transmission being an AM RLC entity and the RLC entity for the PTM transmission being a UM RLC entity. The communication method according to claim 1 or 2.

4. A user equipment for use in a mobile communication system supporting a Multicast Broadcast Service (MBS), comprising: a receiving unit for receiving from a network node a configuration of a multicast radio bearer associated with a radio link control (RLC) entity for point-to-point (PTP) transmission and a point-to-multipoint (PTM) transmission; a control unit that treats the multicast radio bearer as an AM multicast radio bearer when the RLC entity for the PTP transmission is an AM (Acknowledged Mode) RLC entity. User equipment.

5. A mobile communication system comprising a user equipment and a network node according to claim 4.

6. A chipset comprising means for performing the communication method of claim 1.

7. A program for causing a user device to execute the communication method according to claim 1.

Images