Communication method, user equipment, mobile communication system, chipset and program product

Abstract

A communication method for use in a mobile communication system for supporting a multicast and broadcast service (MBS), the communication method comprising the steps of: receiving, by a user equipment, a configuration of a multicast radio bearer from a base station, the multicast radio bearer is associated with a radio link control (RLC) entity for point-to-point (PTP) transmission and an RLC entity for point-to-multipoint (PTM) transmission; and the user equipment processes the multicast radio bearer as an AM multicast radio bearer according to the fact that the RLC entity for the PTP transmission is an acknowledgement mode AM RLC entity.

Description

[0001] This application is a divisional application of the patent application (filing date: August 3, 2022, international application number PCT / JP2022 / 029766, entered the Chinese national phase on April 2, 2024, Chinese national phase application number 202280067081.X, invention title "Communication method and user equipment"). Technical Field

[0002] The present disclosure relates to a communication method and a user equipment used in a mobile communication system. Background Art

[0003] In the 3rd Generation Partnership Project (3GPP) standard, the technical specifications of New Radio (NR) as the 5th Generation (5G) radio access technology have been defined. Compared with Long Term Evolution (LTE) as the 4th Generation (4G) radio access technology, NR has characteristics such as high speed, large capacity, high reliability, and low latency. In 3GPP, the technical specifications for establishing multicast and broadcast services (MBS) for 5G / NR have been discussed (for example, see Non-Patent Document 1).

[0004] Citation List

[0005] Non-Patent Document

[0006] Non-Patent Document 1: 3GPP document: RP-201038, "WID revision: NR Multicast and Broadcast Services" Summary of the Invention

[0007] It is desired that the 5G / NR multicast and broadcast service provides enhanced services compared to the 4G / LTE multicast and broadcast service.

[0008] In view of this, the present disclosure provides a communication method and a user equipment capable of implementing enhanced multicast and broadcast services.

[0009] In a first aspect, a communication method is used in a mobile communication system for supporting multicast and broadcast services (MBS). The communication method includes: a user equipment that has started receiving an MBS session determines whether a predetermined condition indicating that the reception has started in the middle of the MBS session is satisfied; and when it is determined that the predetermined condition is satisfied, the user equipment sends lost packet identification information to the base station, the lost packet identification information indicating a group of lost packets from the start of the MBS session until the start of the reception.

[0010] In a second aspect, a user equipment is used in a mobile communication system for supporting multicast and broadcast services (MBS). The user equipment includes: a controller configured to determine whether a predetermined condition indicating that the reception has started midway through the MBS session is satisfied after starting to receive an MBS session from a base station; and a transmitter configured to, when it is determined that the predetermined condition is satisfied, send lost packet identification information to the base station, the lost packet identification information indicating a group of lost packets from the start of the MBS session until the start of the reception.

[0011] In a third aspect, a communication method is used in a mobile communication system for supporting multicast and broadcast services (MBS). The communication method includes: a user equipment receiving configuration information from a base station, the configuration information for configuring a split radio bearer to be split into a point-to-point PTP branch and a point-to-multipoint PTM branch; and the user equipment determining whether the split radio bearer is an acknowledged mode AM bearer or an unacknowledged mode UM bearer based on radio link control RLC modes configured for each of the PTP branch and the PTM branch.

[0012] In a fourth aspect, a user equipment is used in a mobile communication system for supporting multicast and broadcast services (MBS). The user equipment includes: a receiver configured to receive configuration information from a base station, the configuration information for configuring a split radio bearer to be split into a point-to-point PTP branch and a point-to-multipoint PTM branch; and a controller configured to determine whether the split radio bearer is an acknowledged mode AM bearer or an unacknowledged mode UM bearer based on radio link control RLC modes configured for each of the PTP branch and the PTM branch. Description of the Drawings

[0013] Figure 1 is a diagram showing the configuration of a mobile communication system according to an embodiment.

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

[0015] Figure 3 is a diagram showing the configuration of a gNB (base station) according to an embodiment.

[0016] Figure 4 is a diagram showing the configuration of a protocol stack of a radio interface of a user plane for processing data.

[0017] Figure 5 is a diagram showing the configuration of a protocol stack of a radio interface of a control plane for processing signaling (control signals).

[0018] Figure 6It is a diagram showing an overview of MBS service transmission according to an embodiment.

[0019] Figure 7 It is a diagram showing a transmission mode according to an embodiment.

[0020] Figure 8 It is a diagram showing a split multicast radio bearer (MRB) according to an embodiment.

[0021] Figure 9 It is a diagram showing the operation of the PDCP layer in a mobile communication system according to an embodiment.

[0022] Figure 10 It is a diagram showing a COUNT value according to an embodiment.

[0023] Figure 11 It is a diagram showing a PDCP data PDU according to an embodiment.

[0024] Figure 12 It is a diagram showing an operation for identifying RCVD_COUNT.

[0025] Figure 13 It is a diagram showing the operation of the receiving-side PDCP entity of a UE.

[0026] Figure 14 It is a diagram showing the operation of a UE according to a first embodiment.

[0027] Figure 15 It is a diagram showing an example of the operation of a mobile communication system according to a first embodiment.

[0028] Figure 16 It is a diagram showing configuration examples 1 to 3 of a PDCP status report according to a first embodiment.

[0029] Figure 17 It is a diagram showing a configuration example of an RRC message according to a first embodiment.

[0030] Figure 18 It is a diagram showing a first modification example of the operation according to a first embodiment.

[0031] Figure 19 It is a diagram showing a second modification example of the operation according to a first embodiment.

[0032] Figure 20 It is a diagram showing the operation of a UE according to a second embodiment.

[0033] Figure 21 It is a diagram showing the switching of PDCP fixed types PTM / PTP based on the current protocol. Detailed Description

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

[0035] First Embodiment

[0036] Configuration of Mobile Communication System

[0037] Figure 1 FIG. is a diagram showing the configuration of a mobile communication system 1 according to the first embodiment. The mobile communication system 1 conforms to the fifth-generation system (5GS) of the 3GPP standard. The following description takes 5GS as an example, but the Long-Term Evolution (LTE) system can be at least partially applied to the mobile communication system. The sixth-generation (6G) system can be at least partially applied to the mobile communication system.

[0038] The mobile communication system 1 includes a user equipment (UE) 100, a 5G radio access network (next-generation 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.

[0039] The UE 100 is a mobile radio communication device. The UE 100 can be any device as long as it is used by a user. Examples of the UE 100 include a mobile phone terminal (including a smart phone), a tablet terminal, a notebook PC, a communication module (including a communication card or a chipset), a sensor or a device provided on the sensor, a vehicle or a device provided on the vehicle (vehicle UE), and a flying object or a device provided on the flying object (air UE).

[0040] The NG-RAN 10 includes a base station (referred to as a "gNB" in the 5G system) 200. The gNBs 200 are interconnected via an Xn interface that is an interface between base stations. Each gNB 200 manages one or more cells. The gNB 200 performs wireless communication with the UE 100 that has established a connection to the cell of the gNB 200. The gNB 200 has a radio resource management (RRM) function, a function of routing user data (hereinafter simply referred to as "data"), a measurement control function for mobility control and scheduling, and the like. "Cell" is a term used to represent the smallest unit of a wireless communication area. "Cell" is also used as a term to represent 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").

[0041] Note that the gNB can be connected to the evolved packet core (EPC) corresponding to the core network of LTE. The LTE base station can also be connected to the 5GC. The LTE base station and the gNB can be connected via an inter-base station interface.

[0042] The 5GC 20 includes an access and mobility management function (AMF) and a user plane function (UPF) 300. The AMF performs various types of mobility control, etc. 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 transmission. The AMF and the UPF are connected to the gNB 200 via the NG interface, which is an interface between the base station and the core network.

[0043] Figure 2 FIG. is a diagram showing the configuration of a UE 100 (user equipment) according to the first embodiment. The UE 100 includes a receiver 110, a transmitter 120, and a controller 130. The receiver 110 and the transmitter 120 constitute a wireless communicator that performs wireless communication with the gNB 200.

[0044] The receiver 110 performs various types of reception under the control of the controller 130. The receiver 110 includes an antenna and receiving equipment. The receiving equipment converts the radio signal received through the antenna into a baseband signal (received signal), and outputs the obtained signal to the controller 130.

[0045] The transmitter 120 performs various types of transmission under the control of the controller 130. The transmitter 120 includes an antenna and transmitting equipment. The transmitting equipment converts the baseband signal (transmitted signal) output by the controller 130 into a radio signal, and transmits the obtained signal through the antenna.

[0046] The controller 130 performs various types of control and processing in the UE 100. Such processing includes processing of each layer to be described later. The controller 130 includes at least one processor and at least one memory. The memory stores programs to be executed by the processor and information to be used for the processing performed by the processor. The processor may include a baseband processor and a central processing unit (CPU). The baseband processor performs modulation and demodulation, encoding and decoding, etc. of the baseband signal. The CPU executes the programs stored in the memory, thereby performing various types of processing.

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

[0048]

[0048] The transmitter 210 performs various types of transmissions under the control of the controller 230. The transmitter 210 includes an antenna and a transmission device. The transmission device converts the baseband signal (transmission signal) output by the controller 230 into a radio signal and transmits the resulting signal through the antenna.

[0049]

[0049] The receiver 220 performs various types of receptions under the control of the controller 230. The receiver 220 includes an antenna and a reception device. The reception device converts the radio signal received through the antenna into a baseband signal (reception signal) and outputs the resulting signal to the controller 230.

[0050]

[0050] The controller 230 performs various types of control and processing in the gNB 200. Such processing includes the processing of each layer to be described later. The controller 230 includes at least one processor and at least one memory. The memory stores programs to be executed by the processor and information to be used for the processing performed by the processor. The processor may include a baseband processor and a CPU. The baseband processor performs modulation and demodulation, encoding and decoding, etc. of the baseband signal. The CPU executes the programs stored in the memory, thereby performing various types of processing.

[0051]

[0051] The backhaul communicator 240 is connected to an adjacent base station via the Xn interface between the base stations. The backhaul communicator 240 is connected to the AMF / UPF 300 via the NG interface between the base station and the core network. Note that the gNB 200 may include a central unit (CU) and a distributed unit (DU) (i.e., the functions are divided), and these two units may be connected via the F1 interface as a fronthaul interface.

[0052] Figure 4 Figure 4 is a diagram showing the configuration of the protocol stack of the radio interface of the user plane for processing data.

[0053]

[0053] The radio interface protocol of the user plane includes a physical (PHY) layer, a media 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.

[0054] The PHY layer performs encoding and decoding, modulation and demodulation, antenna mapping and demapping, and resource mapping and demapping. Data and control information are transmitted between the PHY layer of UE 100 and the PHY layer of gNB 200 via the physical channels. Note that the PHY layer of UE 100 receives the downlink control information (DCI) sent from gNB 200 through the physical downlink control channel (PDCCH). Specifically, UE 100 blindly decodes the PDCCH using the radio network temporary identifier (RNTI), and obtains the successfully decoded DCI as the DCI addressed to UE 100. The DCI sent from gNB 200 is appended with CRC parity bits scrambled by the RNTI.

[0055] The MAC layer performs priority control of data, retransmission processing through hybrid ARQ (HARQ: Hybrid Automatic Repeat reQuest), 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 the transport channels. The MAC layer of gNB 200 includes a scheduler. The scheduler determines the transmission format (transmission block size, modulation and coding scheme (MCS)) in the uplink and downlink and the resource blocks to be allocated to UE 100.

[0056] The RLC layer sends 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 UE 100 and the RLC layer of gNB 200 via the logical channels.

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

[0058] The SDAP layer performs the mapping between IP flows (as the unit of QoS (Quality of Service) control performed by the core network) and radio bearers (as the unit of QoS control performed by the access stratum (AS)). Note that when the RAN is connected to the EPC, it is not necessary to provide the SDAP.

[0059] Figure 5 is a diagram showing the configuration of the protocol stack of the radio interface of the control plane that processes signaling (control signals).

[0060] The protocol stack of the radio interface of the control plane includes the radio resource control (RRC) layer and the non-access stratum (NAS) layer, rather than Figure 4 the SDAP layer shown in

[0061] RRC signaling for various configurations is sent between the RRC layer of UE 100 and the RRC layer of gNB 200. The RRC layer controls logical channels, transport channels, and physical channels based on the establishment, re - establishment, and release of radio bearers. When there is a connection (RRC connection) between the RRC of UE 100 and the RRC of gNB 200, UE 100 is in the RRC connected state. When there is no connection (RRC connection) between the RRC of UE 100 and the RRC of gNB 200, UE 100 is in the RRC idle state. When the connection between the RRC of UE 100 and the RRC of gNB 200 is suspended, UE 100 is in the RRC inactive state.

[0062] The NAS layer, which is above the RRC layer, performs session management, mobility management, etc. NAS signaling is sent between the NAS layer of UE 100 and the NAS layer of AMF 300A. Note that in addition to the protocols of the radio interface, UE 100 includes an application layer. Layers lower than the NAS layer are called the AS layer.

[0063] Overview of MBS

[0064] An overview of MBS according to the first embodiment will be described. MBS is a service in which NG - RAN 10 can provide broadcast or multicast, i.e., point - to - multi - point (PTM) data transmission to UE100. It is assumed that the use cases (service types) of MBS include public - safety communication, mission - critical communication, vehicle - to - everything (V2X) communication, IPv4 or IPv6 multicast delivery, Internet Protocol Television (IPTV), group communication, and software delivery.

[0065] The broadcast service provides services to each UE 100 within a specific service area for applications that do not require highly reliable QoS. The MBS session for the broadcast service is called a broadcast session.

[0066] The multicast service does not provide services to each UE 100, but provides services to a group of UE100 participating in the multicast service (multicast session). The MBS session for the multicast service is called a multicast session. The multicast service can provide the same content to the group of UE 100 by a method that is more radio - efficient than the broadcast service.

[0067] Figure 6 It is a diagram showing an overview of MBS service delivery according to the first embodiment.

[0068] The MBS service (MBS data) is transmitted from a single data source (application service provider) to multiple UEs. 5G CN (5GC) 20, as the 5G core network, receives MBS data from the application service provider and performs replication of the MBS data to transmit the replicated products.

[0069] From the perspective of the 5GC 20, two multicast delivery methods are possible: 5GC shared MBS service delivery and 5GC individual MBS service delivery.

[0070] In the 5GC individual MBS service delivery method, the 5GC 20 receives a single copy of the MBS data packet and delivers respective copies of these MBS data packets to each UE 100 via the PDU session of each UE 100. Therefore, one PDU session of each UE 100 needs to be associated with the multicast session.

[0071] In the 5GC shared MBS service delivery method, the 5GC 20 receives a single copy of the MBS data packet and delivers this single copy of the MBS data packet to the RAN node (i.e., gNB 200). The gNB 200 receives the MBS data packet via the MBS tunnel connection and delivers the MBS data packet to one or more UEs 100.

[0072] From the perspective of the RAN (5G RAN) 10, for the radio transmission of MBS data in the 5GC shared MBS service delivery method, two delivery methods are possible: the point-to-point (PTP) delivery method and the point-to-multipoint (PTM) delivery method. PTP represents unicast, and PTM represents multicast and broadcast.

[0073] In the PTP delivery method, the gNB 200 wirelessly delivers respective copies of the MBS data packet to each UE 100. On the other hand, in the PTM delivery method, the gNB 200 wirelessly delivers a single copy of the MBS data packet to a group of UEs 100. The gNB 200 can dynamically determine whether to use the PTM delivery method or the PTP delivery method as the method for delivering MBS data to a UE 100.

[0074] The PTP and PTM delivery methods are mainly related to the user plane. The modes for controlling MBS data delivery include two delivery modes: the first delivery mode and the second delivery mode.

[0075] Figure 7 FIG. shows the delivery mode according to the first embodiment.

[0076] 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 the multicast session among MBS sessions. Note that the first delivery mode can be used for the broadcast session. The first delivery mode can be available for the UE 100 in the RRC idle state or the RRC inactive state.

[0077] The MBS reception configuration in the first transmission mode is performed through UE-specific signaling. For example, the MBS reception configuration in the first transmission mode is performed through an RRC reconfiguration message (or an RRC release message), which is an RRC message unicast from gNB 200 to UE 100.

[0078] The MBS reception configuration includes MBS traffic channel configuration information (hereinafter referred to as "MTCH configuration information") regarding 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 discontinuous reception (DRX) configuration of the MBS traffic channel. The discontinuous reception configuration may include at least one of the following parameters: a timer value (on-duration timer) for defining an on-period (on-duration: reception period), a timer value (inactivity timer) for extending the on-period, a scheduling interval or a DRX cycle (scheduling period, DRX cycle), an offset value (start offset, DRX cycle offset) of the starting subframe for the scheduling period or the DRX cycle, a starting delay slot value (slot offset) of the on-period timer, a timer value (retransmission timer) for defining the longest time before retransmission, and a timer value (HARQ RTT timer) for defining the minimum interval before a DL assignment for HARQ retransmission.

[0079] Note that the MBS traffic channel is a logical channel and may be referred to as MTCH. The MBS traffic channel is mapped to a downlink shared channel (DL-SCH), which is a transmission channel.

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

[0081] The MBS reception configuration in the second transmission mode is performed via broadcast signaling. For example, the MBS reception configuration in the second transmission mode is performed using logical channels (e.g., Broadcast Control Channel (BCCH) and / or Multicast Control Channel (MCCH)) sent from gNB 200 to UE 100 via broadcast. For example, UE 100 may receive BCCH and MCCH using a dedicated RNTI predefined in the technical specifications. The RNTI for BCCH reception may be SI-RNTI, and the RNTI for MCCH reception may be MCCH-RNTI.

[0082] In the second transmission mode, UE 100 may receive MBS data in the following three procedures. First, on the System Information Block (MBS-SIB) sent by gNB 200 on BCCH, UE 100 receives MCCH configuration information. Second, UE 100 receives MCCH from gNB 200 based on the MCCH configuration information. MTCH configuration information is sent on the MCCH. Third, UE 100 receives MTCH (MBS data) based on the MTCH configuration information. Hereinafter, the MTCH configuration information and / or the MCCH configuration information may be referred to as the MBS reception configuration.

[0083] In the first and second transmission modes, UE 100 may use the Group RNTI (G-RNTI) assigned from gNB 200 to receive MTCH. The G-RNTI corresponds to the RNTI for MTCH reception. The G-RNTI may be included in the MBS reception configuration (MTCH configuration information).

[0084] The network may provide different MBS services for different MBS sessions. An MBS session is identified by at least one selected from the group consisting of: Temporary Mobile Group Identity (TMGI), source-specific IP multicast address (which includes a source unicast IP address such as an application function and an application server and an IP multicast address indicating a destination address), session identifier, and G-RNTI. At least one selected from the group consisting of TMGI, G-RNTI, source-specific IP multicast address, and session identifier is referred to as an MBS session identifier. TMGI, source-specific IP multicast address, session identifier, and G-RNTI are collectively referred to as MBS session information.

[0085] Figure 8 FIG. is a diagram showing a split Multicast Radio Bearer (MRB) according to a first embodiment. The MRB may be a type of Data Radio Bearer (DRB). The split MRB may be used in the first transmission mode described above.

[0086] The gNB 200 may configure the MRB split into the PTP communication path and the PTM communication path for the UE 100. This allows the gNB 200 to dynamically switch the transmission of MBS data to the UE 100 between PTP (PTP communication path) and PTM (PTM communication path). The gNB 200 may use both PTP (PTP communication path) and PTM (PTM communication path) to perform the repeated transmission of the same MBS data to enhance reliability. Hereinafter, the PTP communication path is referred to as the PTP branch, and the PTM communication path is referred to as the PTM branch. The functional unit corresponding to each layer is called an entity.

[0087] The predetermined layer at which the split is terminated is the MAC layer (HARQ), the RLC layer, the PDCP layer, or the SDAP layer. Although an example in which the predetermined layer at which the split is terminated is the PDCP layer will be mainly described below, the predetermined layer may be the MAC layer (HARQ), the RLC layer, or the SDAP layer.

[0088] Each of the PDCP entity of the gNB 200 and the PDCP entity of the UE 100 splits the MRB (which is the bearer (data radio bearer) for MBS) into a PTP branch and a PTM branch. Note that a PDCP entity is provided for each bearer.

[0089] Each of the gNB 200 and the UE 100 includes two RLC entities provided for the corresponding branches: one MAC entity and one PHY entity. The PHY entity may be provided for each branch. Note that in a dual connection in which the UE 100 communicates with two gNB 200s, the UE 100 may include two MAC entities.

[0090] The PHY entity uses the cell RNTI (cell radio network temporary identifier (C-RNTI)) assigned to the UE 100 one-to-one to transmit and receive data of the PTP branch. The PHY entity uses the G-RNTI assigned to the MBS session one-to-one to transmit and receive data of the PTM branch. The C-RNTI is different for each UE 100, but the G-RNTI is a RNTI common to multiple UEs 100 receiving one MBS session.

[0091] In order to perform PTM transmission (multicast or broadcast) of MBS data from the gNB 200 to the UE 100 using the PTM branch, it is necessary to configure the split MRB from the gNB 200 to the UE 100, and it is necessary to activate the PTM branch (activation). In other words, even if the split MRB is configured for the UE 100, when the PTM branch is in the deactivated state, the gNB 200 cannot use the PTM branch to perform PTM transmission of MBS data.

[0092] In order for the gNB 200 and the UE 100 to use the PTP branch to perform PTP transmission (unicast) of MBS data, it is necessary to configure split MRBs from the gNB 200 to the UE 100, and it is necessary to activate the PTP branch. In other words, even if split MRBs are configured for the UE 100, when the PTP branch is in the deactivated state, the gNB 200 cannot use the PTP branch to perform PTP transmission of MBS data.

[0093] When the PTM branch is in the activated state, the UE 100 monitors the PDCCH that applies the G-RNTI associated with the MBS session (i.e., performs blind decoding of the PDCCH using the G-RNTI). The UE 100 can monitor the PDCCH only at the scheduling occasion of the MBS session.

[0094] When the PTM branch is in the deactivated state, the UE 100 does not monitor the PDCCH that applies the G-RNTI associated with the MBS session (i.e., does not perform blind decoding of the PDCCH using the G-RNTI).

[0095] When the PTP branch is in the activated state, the UE 100 monitors the PDCCH that applies the C-RNTI. When discontinuous reception (DRX) in the PTP branch is configured, the UE 100 monitors the PDCCH during the configured OnDuration period. When specifying the cell (frequency) associated with the MBS session, even when the cell is deactivated, the UE 100 can monitor the PDCCH for that cell.

[0096] When the PTP branch is in the deactivated state, the UE 100 can monitor the PDCCH that applies the C-RNTI to prepare for normal unicast downlink transmission other than MBS data. Note that when specifying the cell (frequency) associated with the MBS session, the UE 100 does not need to monitor the PDCCH for that MBS session.

[0097] Note that it is assumed that the above split MRBs are configured by an RRC message (e.g., an RRC reconfiguration message) from the RRC entity of the gNB 200 to the RRC entity of the UE 100.

[0098] Operations of the PDCP layer

[0099] Figure 9 is a diagram showing the operations of the PDCP layer in the mobile communication system 1 according to the first embodiment.

[0100] The gNB 200 multicasts (or broadcasts) to multiple UEs 100 via PTM (in Figure 9In the example, MBS data of a certain MBS session is sent to UEs 100a to 100c. The RRC state of each UE 100 can be any state (RRC connected state, RRC idle state, or RRC inactive state). The MBS transmission mode can be the first transmission mode or the second transmission mode. In the first transmission mode, MBS transmission can use the PTM branch.

[0101] In the PDCP layer, gNB 200 includes a PDCP entity 201 associated with the MBS session (specifically, a transmitting-side PDCP entity associated with a multicast radio bearer (MRB) belonging to the MBS session). When the PDCP entity 201 starts transmitting the MBS session, the PDCP entity 201 manages PDCP variables updated in response to the transmission of PDCP packets in the MBS session.

[0102] In the PDCP layer, each UE 100 includes a PDCP entity 101 associated with the MBS session (specifically, a receiving-side PDCP entity associated with an MRB belonging to the MBS session). When each PDCP entity 101 (in Figure 10 the example, PDCP entities 101a to 101b) starts transmitting the MBS session, the PDCP entity 101 manages PDCP variables updated in response to the reception of PDCP packets in the MBS session.

[0103] As Figure 10 shown, the PDCP variable can be a count value (COUNT value), which includes a hyperframe number (HFN) that counts up whenever the PDCP sequence number goes through a round 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 of 12 bits or 18 bits (SN_length), 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 can be configured using RRC signaling. Note that the term "PDCP variable" does not necessarily indicate the COUNT value and can also be used as a term indicating various variables (HFN, PDCP SN, etc.) processed in the PDCP layer.

[0104] Figure 11 is a diagram showing PDCP packets (specifically, PDCP data protocol data units (PDUs)) constituting MBS data. As Figure 11As shown, the PDCP data PDU includes a PDCP SN, data, and a MAC-I. The PDCP SN is a sequence number assigned sequentially to the PDCP data PDU. The data corresponds to a PDCP service data unit (SDU). The MAC-I corresponds to a message authentication code. The PDCP data PDU may not include a MAC-I. As described above, the PDCP data PDU includes a PDCP SN but does not include an HFN. Therefore, each of the gNB 200 and the UE 100 needs to update the HFN in response to the transmission and reception of the PDCP data PDU. Specifically, the HFN is incremented whenever the PDCP sequence number goes through a cycle.

[0105] Figure 12 FIG. is a diagram showing an operation for identifying RCVD_COUNT, which is a COUNT value of a PDCP data PDU received in the UE 100 (receiving-side PDCP entity). Here, the PDCP SN included in the received PDCP data PDU is referred to as RCVD_SN.

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

[0107] Second, when RCVD_SN ≥ SN(RX_DELIV) + Window_Size, RCVD_HFN = HFN(RX_DELIV) - 1.

[0108] Third, when neither of the above conditions is satisfied, RCVD_HFN = HFN(RX_DELIV).

[0109] Then, set RCVD_COUNT = [RCVD_HFN, RCVD_SN].

[0110] Figure 13 FIG. is a diagram showing an operation of the receiving-side PDCP entity 101 of the UE 100.

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

[0112] When the receiving - side PDCP entity 101 succeeds in the integrity verification (step S12: No), and the count value (RCVD_COUNT) is less than RX_DELIV (step S14: Yes) or RCVD_COUNT has been received (step S16: Yes), the receiving - side PDCP entity 101 discards the PDCP PDU (step S15).

[0113] Next, the receiving - side PDCP entity 101 stores the undiscarded PDCP PDUs in the receive buffer (step S17), and when "RCVD_COUNT≥RX_NEXT" (step S18: Yes), the receiving - side PDCP entity 101 updates RX_NEXT = 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. When out - of - order delivery is configured (step S20: Configured), the receiving - side PDCP entity 101 decompresses the header of the PDCP PDU and then delivers the result to the upper layer (step S21). Specifically, when "outOfOrderDelivery" is configured in the RRC, the receiving - side PDCP entity 101 performs the operation of S21. Out - of - order delivery is an operation of delivering packets to the upper layer without performing sequence control. Therefore, as in step S21, immediately after the packet is received and stored in the buffer, the packet is delivered to the upper layer. Note that when step S20 is "No", sequence control is performed.

[0114] When "RCVD_COUNT = RX_DELIV" (step S22: Yes), the receiving - side PDCP entity 101 decompresses the headers of all COUNT consecutive PDCP SDUs starting from COUNT = RX_DELIV and then delivers the result to the upper layer (step S23), and updates RX_DELIV to the first (lowest) COUNT value that has not been delivered to the upper layer (step S24).

[0115] When T-Reordering is running and “RX_DELIV ≥ RX_REORD” (step S25: Yes), the receiving-side PDCP entity 101 stops and resets T-Reordering (step S26). Here, T-Reordering is a timer for detecting the loss of PDCP data PDUs. RX_REORD is a variable indicating the COUNT value after the COUNT value associated with the PDCP data PDU that triggered T-Reordering.

[0116] When T-Reordering is stopped and “RX_DELIV < RX_REORD” (step S27: Yes), the receiving-side PDCP entity 101 updates RX_REORD = RX_NEXT and starts T-Reordering.

[0117] Operation of the mobile communication system

[0118] Based on the above configuration and operation assumptions, the operation of the mobile communication system 1 according to the first embodiment will be described.

[0119] In Figure 9 In the operation scenario shown, the UE 100 (one of UE 100a to UE 100c) may not necessarily be able to start MBS reception at the time point when the gNB 200 starts providing an MBS session (multicast session or broadcast session). For example, one of the UEs 100 may start MBS reception in the middle of an MBS session. In this case, the UE 100 cannot receive packets (e.g., PDCP data PDUs) from the start (provision start) of the MBS session until the start of MBS reception, so these packets are lost.

[0120] Here, when the MBS session is a session for streaming data transmission, the loss of packets is not particularly a problem. On the contrary, when the MBS session is a session for downloading a file (e.g., software transmission), the resulting incomplete file is a problem. The first embodiment is an embodiment that can retransmit a group of lost packets to the UE 100 in the AS layer.

[0121] Figure 14 It is a diagram showing the operation of the UE 100 according to the first embodiment. The RRC state of the UE 100 can be any state (RRC connected state, RRC idle state, or RRC inactive state). Note that at the time point of performing the transmission to the gNB 200, the UE 100 is in the RRC connected state. The MBS transmission mode can be the first transmission mode. The MBS transmission mode can be the second transmission mode.

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

[0123] In step S2, the UE 100 determines whether a predetermined condition indicating that MBS reception has started midway through the MBS session is satisfied. When it is determined that the predetermined condition is not satisfied (step S2: No), the UE 100 continues MBS reception without performing the processing of steps S3 and S4.

[0124] The predetermined condition may be the following condition: joining the MBS session midway. The UE 100 can determine that it has joined the MBS session midway based on, for example, one of the following methods 1 to 10.

[0125] Method 1: In the case of the first transmission mode (DM1), after the UE 100 participates in the MBS session through the NAS procedure, when MBS configuration (e.g., MRB configuration) is performed using RRC reconfiguration from the gNB 200 within a certain period (e.g., immediately thereafter), the UE 100 can determine that the UE 100 has (most likely) participated in the MBS session midway, and when MBS configuration is performed after that certain period, the UE 100 can determine that the UE 100 has (most likely) participated in the MBS session from the beginning. This certain period can be configured for the UE 100 from the gNB 200 or the AMF 300A. This certain period can be a timer value (e.g., a timer value indicating a time range), or can be a counter value (e.g., a counter value indicating a range of system frame numbers).

[0126] Method 2: In the case of the first transmission mode (DM1), after the UE 100 participates in the MBS session through the NAS procedure, the UE 100 monitors a group notification (paging) indicating the start (activation) of the MBS session, and when MBS configuration (e.g., MRB configuration) is performed using RRC reconfiguration after receiving the group notification, the UE 100 can determine that the UE 100 has participated in the MBS session from the beginning, and when MBS configuration (e.g., MRB configuration) is performed using RRC reconfiguration without receiving the group notification, the UE 100 can determine that the UE 100 has (most likely) participated in the MBS session midway.

[0127] Method 3: In the case of the second transmission mode (DM2), when the UE 100 receives an MBS configuration (e.g., MTCH scheduling configuration) on the MCCH after receiving a change notification (MCCH change notification) and the start of a session, the UE 100 may determine that the UE 100 has been participating in the MBS session from the beginning. When an MBS configuration already exists as a result of checking the MCCH without receiving a change notification, the UE 100 may determine that the UE 100 has joined the MBS session midway.

[0128] Method 4: When the AMF 300A permits a participation request from the UE 100 during the MBS session participation process in the NAS procedure, the UE 100 may determine whether the UE 100 has joined the MBS session from the start or midway by obtaining information from the AMF 300A indicating that the session is being transmitted (is active) or information indicating that the session is stopped (is suspended, is in an inactive state, or is configured).

[0129] Method 5: When there is a description of the (approximate) start time of the MBS session in the user service description (USD) pre-stored in the UE 100, based on the information in the USD, the UE 100 may determine whether the UE 100 has participated in the MBS session from the start or midway.

[0130] Method 6: When the UE 100 is notified from a higher layer (e.g., the application layer) that a file is incomplete (cannot be recovered), the UE 100 may determine that the UE 100 has joined the MBS session midway. This notification may be sent from the application layer to the NAS layer and from the NAS layer to the AS layer.

[0131] Method 7: In the UE 100, when the NAS layer notifies the AS layer that the MBS session has been joined midway, the AS may recognize that the MBS session has been joined midway.

[0132] Method 8: The UE 100 may be notified from the gNB 200 that the MBS session is in progress (or has started). For example, in the case of the first transmission mode (DM1), when the gNB 200 performs an MBS configuration (e.g., MRB configuration) using RRC reconfiguration, the UE 100 may determine whether it has joined the MBS session midway by being notified of an "intermediate participation flag" (or "a flag indicating joining the MBS session from the start") associated with the MBS configuration (e.g., MRB configuration).

[0133] Method 9: gNB 200 may perform a notification or information provision (which may be broadcast on the SIB and / or MCCH, or may be performed using RRC reconfiguration) to UE 100 indicating the file restoration of an executable MBS session (e.g., MRB), or indicating that the previous data of the MBS session is stored, or indicating that file restoration of the MBS session is allowed. Based on this notification, UE 100 may implicitly determine that UE 100 has participated in the MBS session in the middle. Such a notification may be a notification according to the first variant example to be described later.

[0134] Method 10: In a session, in the header of MBS data (e.g., the header of a PDCP data PDU), a 1-bit flag may be defined, which indicates whether it is the first packet or an intermediate packet (or not the first packet). UE 100 receives the MBS data, and based on the flag stored in the header of the MBS data, UE 100 may determine whether UE 100 has participated in the MBS session in the middle.

[0135] The predetermined condition may be the following condition: the sequence number (SN) of the first MBS packet received by UE 100 regarding the MBS session is not the initial value. For example, when the PDCP SN included in the PDCP data PDU which is the first one received by UE 100 regarding the MBS session is not zero, UE 100 may determine that the MBS reception has started in the middle of the MBS session. Here, zero is an example of the initial value. Note that although it is not necessarily required to use the PDCP SN, and the RLC SN may be alternatively used to perform the determination, the example where the sequence number is the PDCP SN will be mainly described below. The sequence number may be the COUNT value (HFN + PDCP SN) described above.

[0136] When it is determined that the predetermined condition is satisfied (step S2: Yes), in step S3, UE 100 sends lost packet identification information to gNB 200, and the lost packet identification information indicates the group of lost packets from the start of the MBS session until the start of the MBS reception. The lost packet identification information includes information indicating the sequence number (e.g., PDCP SN) of the last lost packet in the group of lost packets. Therefore, gNB 200 can identify up to which packet (e.g., PDCP data PDU) UE 100 has failed to receive. The information indicating the sequence number of the last lost packet may be the sequence number of the last lost packet itself. The information indicating the sequence number of the last lost packet may be a value obtained by adding 1 to the sequence number of the last lost packet (i.e., the sequence number of the first packet received by UE 100).

[0137] Here, the UE 100 (receiving - side PDCP entity 101) can send a PDCP control PDU including lost packet identification information to the transmitting - side PDCP entity 201 of the gNB 200 as a PDCP status report. Since the bearer (MRB) and the PDCP entity are related one - to - one, by sending a PDCP status report regarding the bearer, the lost packet identification information can be smoothly notified to the gNB 200. For example, as Figure 8 shown, the UE 100 can use the PTM branch to receive MBS data and use the PTP branch to send a PDCP status report to the gNB 200.

[0138] Alternatively, the UE 100 can send an RRC message to the gNB 200. The RRC message includes lost packet identification information and an identifier associated with the lost packet identification information. The identifier can include the MBS session identifier of the MBS session and / or an identifier related to the MRB mapped to the MBS session (e.g., MRB identifier, MTCH identifier, QoS flow identifier, etc.). For example, the RRC message can be an MBS interest indication message or a UE assistance information message.

[0139] The gNB 200 that has received the lost packet identification information from the UE 100 sends (re - transmits) the lost packet group indicated by the lost packet identification information indication to the UE 100.

[0140] In step S4, the UE 100 receives the lost packet group from the gNB 200. The UE 100 can receive the lost packet group sent from the gNB 200 through PTP. For example, as Figure 8 shown, the UE 100 can use the PTM branch to receive MBS data and use the PTP branch to receive the lost packet group re - transmitted by the gNB 200. Note that the UE 100 can use the PTM branch to receive the lost packet group re - transmitted by the gNB 200.

[0141] As described above, according to the first embodiment, when the UE 100 determines that a predetermined condition indicating that MBS reception has started midway through the MBS session is satisfied, the UE 100 sends lost packet identification information indicating the lost packet group from the start of the MBS session until the start of MBS reception to the gNB 200. Therefore, the gNB 200 can perform re - transmission of the lost packet group to the UE 100.

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

[0143] In step S101, gNB 200 starts to provide an MBS session (multicast session or broadcast session). Specifically, gNB 200 starts to send MBS data regarding the MBS session in PTM. Figure 15 An example is shown where another UE interested in receiving the MBS session starts MBS reception from the start time point of the MBS session (step S102). The sequence number (SN) of the first packet received by such another UE is zero.

[0144] Note that gNB 200 stores the transmitted packets and their sequence numbers associated with each other, thereby preparing for retransmission of the lost packet group. For example, the transmitting side PDCP entity 201 of gNB 200 sends a PDCP data PDU including a PDCP SN, and stores a copy of the PDCP data PDU in a buffer.

[0145] In step S103, UE 100 starts to receive the MBS session. The sequence number (SN) of the first packet received by UE 100 is X.

[0146] In step S104, UE 100 identifies the lost packet group. UE 100 can check the SN of the first packet received from gNB 200 and detect the loss of data. For example, when it is assumed that gNB 200 starts transmitting from SN = 0 and the first packet received by UE 100 from gNB 200 is SN = 100, it can be determined that the packet group with SN = 0 to 99 is lost.

[0147] In step S105, UE 100 sends to gNB 200 lost packet identification information indicating the lost packet group identified in step S103. UE 100 uses a PDCP control PDU (PDCP status report) or an RRC message to send the lost packet identification information to gNB 200.

[0148] Figure 16 FIG. is a diagram showing Configuration Examples 1 to 3 of a PDCP status report according to the first embodiment. At the start of a PDCP control PDU (PDCP status report), a D / C field and a PDU type field may be provided. The D / C field indicates that the PDCP PDU is a control PDU, and the PDU type field indicates that the PDCP PDU is a PDCP status report. In the PDU type field, information indicating an MBS-specific PDCP status report may be set.

[0149] In Configuration Example 1, the PDCP status report includes the following fields: First Missing COUNT (FMC), and a bitmap. In the FMC field, the COUNT value of the first missing PDCP SDU in the reordering window is set, i.e., RX_DELIV. In the bitmap field, a bit associated with each PDCP PDU is set, and when the PDCP PDU is correctly received, "1" is set, while when the PDCP PDU is missing, "0" is set.

[0150] In Configuration Example 2, the PDCP status report includes the following fields: FMC, and Last Missing COUNT (LMC). In the LMC field, the sequence number (COUNT value) of the last packet in the missing packet group is set. In the LMC field, the COUNT value of the first successfully received packet (LMC + 1, e.g., First Success COUNT (FSC)) can be set. In the above Configuration Example 1, the bit length of the bitmap field can be relatively long (e.g., 200 bits for a bitmap of 200 packets); however, by providing the LMC field instead of the bitmap field, the bit length of the PDCP status report can be reduced.

[0151] In Configuration Example 3, the PDCP status report includes the LMC field. Since gNB 200 knows the first transmitted packet (corresponding to FMC), by being informed of the LMC, gNB can identify which data is missing from which data. According to Configuration Example 3, by making the FMC field unnecessary, the bit length of the PDCP status report can be reduced compared to Configuration Example 2.

[0152] Figure 17 A configuration example of the RRC message according to the first embodiment is shown. For example, the RRC message can be an MBS interest indication message or a UE assistance information message sent from UE100 to gNB 200.

[0153] 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 can be the same as and / or similar to the configuration of the above PDCP status report. To generate such an RRC message in the RRC layer, the receiving-side PDCP entity 101 of UE 100 can provide information related to the missing packet group to the RRC layer.

[0154] Return reference Figure 15 , in step S105, gNB 200 receives the missing packet identification information from UE 100.

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

[0156] Note that due to limitations such as the buffer capacity of the gNB 200, it can be assumed that the gNB 200 cannot retransmit all lost packet groups to the UE 100. Only in this case, the UE 100 can use a higher layer mechanism (e.g., File Delivery over Unidirectional Transport (FLUTE), etc.) to attempt file recovery. FLUTE is a higher layer data recovery mechanism defined in IETF RFC 6726 / RFC 3926, and the UE 100 subsequently obtains the lost data (FLUTE blocks) from the application server via unicast.

[0157] First variant example

[0158] Considering the limitations of the buffer capacity of the gNB 200, it is not considered preferable for the UE 100 to request the gNB 200 to perform retransmissions without limit. Therefore, the gNB 200 can send to the UE 100 information for controlling the transmission of the lost packet identification information of the UE 100.

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

[0160] In step S131, the gNB 200 sends to the UE 100 control configuration information for controlling the transmission of the lost packet identification information of the UE 100. The gNB 200 can use the SIB, MCCH, RRC message (RRC reconfiguration message), MAC header, MAC control element (CE), or PDCP control PDU to send the control configuration information to the UE 100. The gNB 200 can send an identifier associated with the control configuration information to the UE 100 together with the control configuration information. The identifier can include the MBS session identifier of the MBS session and / or an identifier related to the MRB mapped to the MBS session (e.g., MRB identifier, MTCH identifier, QoS flow identifier, etc.).

[0161] For example, in step S131, the gNB 200 can send range information as the control configuration information to the UE 100, and the range information indicates the range of the sequence numbers of the lost packet group that allows the UE 100 to indicate by the lost packet identification information. In step S105, the UE 100 can send the lost packet identification information indicating the lost packet group within the range specified by the gNB 200 based on the range information from the gNB 200.

[0162] As described above, the gNB 200 configures or notifies the UE 100 of the previous range of SNs that can be notified for data recovery (e.g., within 1000 packets (SNs), etc.). This range can be determined depending on the data buffering amount (capacity) of the gNB 200. The gNB 200 can send information indicating the minimum sequence number among multiple pieces of data buffered in the gNB 200. The gNB 200 can send information indicating the number of packets of the data buffered in the gNB 200 as range information. The UE 100 sends the lost packet identification information within the range configured or notified by the gNB 200 to the gNB 200. For example, the UE 100 can set the lower limit value of this range as the FMC to be included in the lost packet identification information. Alternatively, when the group of lost packets identified by the UE 100 exceeds the range configured or notified by the gNB 200, the UE 100 can determine not to send the lost packet identification information to the gNB 200. In this case, the UE 100 can determine to perform the high-layer file recovery (such as FLUTE) as described above. Here, in the UE 100, the AS layer can report to the high layer (NAS or application) that file recovery in the AS layer cannot be performed (integrity cannot be guaranteed).

[0163] Alternatively, in step S131, the gNB 200 can send the notification information indicating whether the gNB 200 stores (buffers) the first transport packet of the MBS session to the UE 100 as control configuration information. The UE 100 can determine whether to send the lost packet identification information to the gNB 200 based on the notification information from the gNB 200. When the gNB 200 does not store the first transport packet, the data recovery in the AS layer cannot be fully recovered. Therefore, when the notification information indicates that the gNB 200 does not store the first transport packet, the UE 100 can determine not to send the lost packet identification information to the gNB 200. On the contrary, when the notification information indicates that the gNB 200 stores the first transport packet, the UE 100 can send the lost packet identification information to the gNB 200 (step S105). The notification information can be information indicating whether the gNB 200 stores the transport packet with its sequence number being zero as the first transport packet. That is, the notification information can be information for notifying whether retransmission can be performed starting from the first packet.

[0164] Second variant

[0165] The UE 100 needs to include a PTP communication path with the gNB 200 in order to send the lost packet identification information to the gNB 200 as a PDCP control PDU (PDCP status report). For example, the PTP communication path can be Figure 8The PTP branch shown. Thus, a UE 100 that does not include a PTP communication path with the gNB 200 may request the gNB 200 to establish a PTP communication path so as to be able to send lost packet identification information to the gNB 200.

[0166] Figure 19 FIG. is a diagram showing a second variant 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.

[0167] In step S151, when the UE 100 does not include a PTP communication path associated with the MBS session (i.e., when the UE 100 uses only PTM MRBs to perform MBS data reception), the UE 100 sends request information for requesting the configuration of a PTP communication path to the gNB 200. The UE 100 may send this request information to the gNB 200 using an RRC message sent 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 for requesting the configuration of a PTP branch, information indicating a desire to perform data recovery, information indicating a need for uplink transmission, or information indicating a need to split an MRB. The RRC message may also include an identifier associated with the request information. The identifier may be a bearer ID of the target MRB, an RLC channel ID, an LCID, or an MBS session identifier (e.g., TMGI).

[0168] In step S152, in response to receiving the request information from the UE 100, the gNB 200 configures a PTP communication path for the UE 100. For example, the gNB 200 may perform a configuration change from an MRB to a split MRB. The gNB 200 may change the MRB to a PTP-only MRB.

[0169] In step S105, the UE 100 sends a PDCP status report regarding the PTP communication path configured in step S152 to the gNB 200.

[0170] Second Embodiment

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

[0172] Depending on whether the corresponding RLC mode is the acknowledged mode (AM) or the unacknowledged mode (UM), the data radio bearer (DRB) is classified as either an AM DRB or a UM DRB. Specifically, when the mode of the RLC entity associated with the DRB is AM, the UE 100 determines that the DRB is an AM DRB, and when the mode of the RLC entity associated with the DRB is UM, the UE 100 determines that the DRB is a UM DRB. For example, the triggering conditions for PDCP status reports regarding the DRB differ depending on whether the DRB is an AM DRB or a UM DRB.

[0173] Here, for a split MRB, there are two branches and two corresponding RLC entities (see Figure 8 ). For example, the PTM branch only supports UM, and the PTP branch supports both the AM and UM RLC modes. Therefore, a method for determining whether the split MRB is an AM bearer or a UM bearer is considered necessary.

[0174] Figure 20 is a diagram showing the operation of the UE 100 according to the second embodiment.

[0175] In step S201, the UE 100 receives from the gNB 200 configuration information for configuring a split radio bearer (split MRB) to be split into a PTP branch and a PTM branch. Such configuration information can be sent from the gNB 200 to the UE 100 using UE-specific RRC signaling (e.g., an RRC reconfiguration message). Here, the UE 100 is configured by the gNB 200 with the RLC mode of each of the RLC entity handling the PTP branch and the RLC entity handling the PTM branch.

[0176] 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 branch. For example, the UE 100 can determine that the configured split radio bearer (split MRB) is an AM bearer (AM MRB) according to whether the RLC mode configured for the PTP branch or the PTM branch is AM. The UE 100 can determine that the split radio bearer (split MRB) is a UM bearer (UM MRB) according to whether the RLC mode configured for the PTP branch or the PTM branch is UM.

[0177] Specifically, when configuring the RLC entity of the PTP branch with AM for the configured split MRB or configuring the RLC entity of the PTM branch with AM, the UE 100 may determine that the split MRB is an AM MRB. When configuring the PTP branch with two-way UM and / or configuring the PTM branch with two-way UM, the UE 100 may determine that the split MRB is an AM MRB.

[0178] When configuring the RLC entity of the PTP branch with UM for the configured split MRB and configuring the RLC entity of the PTM branch with UM, the UE 100 may determine that the split MRB is a UM MRB. When configuring the PTP branch with one-way UM and configuring the PTM branch with one-way UM, the UE 100 may determine that the split MRB is a UM MRB.

[0179] As a variant of the second embodiment, the gNB 200 may configure for the UE 100 whether the split MRB is an AM MRB or a UM MRB (i.e., which mode the split MRB is considered to be). The UE 100 may determine whether the split MRB is an AM MRB or a UM MRB according to the configured MRB mode.

[0180] Specifically, the gNB 200 explicitly configures for the UE 100 whether the MRB is considered to be an AM MRB or a UM MRB. For example, when the gNB 200 configures the split MRB for the UE 100 using RRC reconfiguration, the gNB 200 includes the mode identifier (AM MRB or UM MRB) associated with the split MRB in this configuration. The UE 100 determines whether the split MRB is an AM MRB or a UM MRB based on the mode identifier.

[0181] Other embodiments

[0182] The above operation processes can be implemented separately and independently, and can also be implemented through the combination of two or more of the operation processes. For example, some steps in one operation process can be applied to another operation process. Some steps of one operation process can be replaced by some steps of another operation process.

[0183] In the above embodiments and examples, examples of the base station being an NR base station (i.e., gNB) are described; however, the base station may be an LTE base station (i.e., eNB) or a 6G base station. The base station may be a relay node, such as an integrated access and backhaul (IAB) node. The base station may be the DU of the IAB node. The user equipment may be the mobile terminal (MT) of the IAB node.

[0184] A program that enables a computer to execute each process performed by the UE 100 or the gNB 200 can be provided. The program can be recorded in a computer-readable medium. Using the computer-readable medium enables the program to be installed on the computer. Here, the computer-readable medium on which the program is recorded can be a non-transitory recording medium. The non-transitory recording medium is not specifically limited and can be, for example, a recording medium such as a CD-ROM or a DVD-ROM. The circuits for performing the processing to be performed by the UE 100 or the gNB 200 can be integrated, and at least a part of the UE 100 or the gNB 200 can be implemented as a semiconductor integrated circuit (chipset, system-on-chip (SoC)).

[0185] Unless otherwise explicitly stated, the phrases "based on" and "depending on" used in this disclosure do not mean "only based on" and "only depending on". The phrase "based on" means both "only based on" and "at least partially based on". Similarly, the phrase "depending on" means both "only depending on" and "at least partially depending on". "Obtain" or "acquire" can mean obtaining information from the stored information, can mean obtaining information from the information received from another node, or can mean obtaining information by generating information. The terms "include", "comprise" and their variants do not mean "only include the item", but mean "can only include the item" or "can not only include the item but also include other items". The term "or" used in this disclosure is not intended to be an "exclusive or". In addition, any reference to elements using names such as "first" and "second" in this disclosure generally does not limit the number or order of these elements. These names can be used herein as a convenient method for distinguishing two or more elements. Therefore, the reference to the first element and the second element does not mean that only two elements can be adopted there or the first element needs to be before the second element in some way. For example, when adding English articles such as "a", "an" and "the" in this disclosure through translation, these articles include the plural unless otherwise explicitly indicated in the context.

[0186] The embodiments have been described in detail above with reference to the accompanying drawings, but the specific configuration is not limited to the above configuration, and various design changes can be made without departing from the gist of this disclosure.

[0187] This application claims the priority of U.S. Provisional Patent Application No. 63 / 229,158 (filed on August 4, 2021), the entire content of which is incorporated herein by reference.

[0188] Supplementary Notes

[0189] 1. Introduction

[0190] Revised work items related to NR multicast and broadcast services (MBS) were approved in RAN#88. The purpose is to define mobility, including dynamic PTM / PTP handover and service continuity as shown below.

[0191] The RAN basic functions for broadcast / multicast of UEs in RRC connected state were defined.

[0192] Support for dynamic changes in the delivery of broadcast / multicast services between multicast (PTM) and unicast (PTP) that provide service continuity for a specific UE was defined.

[0193] Support for basic mobility with service continuity was defined.

[0194] Regarding dynamic PTM / PTP handover, in RAN2, some agreements related to this topic have been reached. RAN2#111-e has the following agreements.

[0195] In the case of UEs, the gNB dynamically determines which of PTM and PTP will be used for transmitting multicast data (shared transmission).

[0196] Further research is needed on layer handling reliability (in general), cases of ordered transmission / duplicate handling, and how this layer functions in the handover between PTM and PTP.

[0197] In RAN2#113-e, the following agreements have been reached regarding the discussion related to L2 reliability in the architecture of dynamic PTM / PTP handover.

[0198] When both PTM and PTP are RLC UM, there is no L2 ARQ, and support for the configuration of handover with a fixed PDCP between PTM and PTP is provided (e.g., when a service usually configured for unicast in RLC UM).

[0199] In RAN2#113bis-e, the following further agreements have been reached regarding the architecture and signaling.

[0200] Agreement

[0201] It should be noted that the following agreements are only based on the determination of the architecture so far. The discussion on reliability has not been completed. In other words, this is different from the case other than RLC UM + RLC UM. Further research is needed on the handover between PTM and PTP in another such case.

[0202] Support for dynamic PTM / PTP handover is provided using a split MRB bearer (type) including a common (single) PDCP entity.

[0203] Basically, new UE-based signaling for supporting gNB handover has not been introduced yet (e.g., PDCP SR for high reliability has not been determined).

[0204] Assuming a split MRB configured with PTM and PTP branches (agreed during an online session), the use of the PTP branch cannot be deactivated after the necessary split MRB configuration (i.e., the UE does not need to continuously monitor the C-RNTI).

[0205] Assuming a split MRB configured with PTM and PTP branches (agreed during an online session), further study is needed on whether the use of the PTM branch of the split MRB can be activated or deactivated and its details.

[0206] In terms of mobility, in RAN2, only the basic principles listed below are agreed.

[0207] The goal of R2 is to support lossless handover for MBS-MBS mobility of services that require this (details of the scenario are not determined; at least PTP-PTP).

[0208] To support lossless handover of 5G MBS services, at least it is not necessary to ensure the synchronization of DL PDCP SN and the continuity between the source cell and the target cell in the network. The specific method design for achieving this may be related to WG RAN3.

[0209] In the network, the source gNB can transmit data to the target gNB, and the target gNB delivers the transmitted data. On the other hand, SN STATUS TRANSFER needs to be enhanced to cover the PDCP SN of MBS data. Next, the UE receives MBS in the target cell according to the target configuration.

[0210] From the UE, PDCP status reporting can also be supported.

[0211] In the supplementary notes, the remaining issues of dynamic PTM / PTP handover and mobility with service continuity based on the agreed architecture (i.e., using a PDCP-fixed split MRB) will be described.

[0212] 2. Discussion

[0213] 3. Split MRB Configuration

[0214] Based on the current protocol, the architecture of PDCP-fixed PTM / PTP handover (i.e., split MRB) can be explained as Figure 21 shown.

[0215] Generally speaking, it can be considered that the RRC reconfiguration is used to provide a bearer configuration including two logical channels (PTM branch and PTP branch) and to receive information of a multicast session. RAN2 describes "assuming a split MRB configured with a PTM branch and a PTP branch (agreed during an online session)"; however, it is generally understood that providing a configuration where two logical channels are associated with one multicast radio bearer with RRC reconfiguration is already a preparation for dynamic PTM / PTP handover.

[0216] Observation 1: Before the dynamic PTM / PTP handover operation, it is generally understood that providing a configuration where two logical channels are associated with one MRB with RRC reconfiguration.

[0217] 4. Dynamic PTM / PTP handover operation

[0218] 5. Signaling

[0219] It is necessary to further study whether the use of split MRB and PTM branch can be activated or deactivated and its details.

[0220] When a split MRB including a PTM branch / PTP branch is configured, the UE needs to monitor both the G-RNTI of the PTM branch and the C-RNTI of the PTP branch. In LTE SC-PTM, "the reception timing of SC-PTM is independent of the unicast DRX scheme", that is, the DRX is different. The G-RNTI is received by multiple UEs, while the C-RNTI is UE-specific, and the two DRXs are significantly coordinated, so this concept can be the basis of NRMBS. This means that when the UE needs to continuously monitor the G-RNTI, the UE needs to wake up frequently, and this can lead to further power consumption. On the other hand, the UE in the connected state needs to monitor the C-RNTI (i.e., C-DRX) for unicast reception; however, this is not an additional burden on the UE.

[0221] Observation 2: In addition to the transmission timing of the PTP branch (i.e., C-RNTI) that is the same as C-DRX, the UE also needs to wake up for the transmission timing of the PTM branch (i.e., G-RNTI), as in the SC-MTCH timing of LTE SC-PTM.

[0222] When receiving an MRB with PTM / PTM (i.e., during the handover operation), there are the following four options.

[0223] Option 1: Handover based on activation / deactivation

[0224] The gNB uses DCI, MAC CE, RRC signals, etc. to indicate to the UE to enable / disable the PTM branch. In addition to receiving MBS data via PTM or PTP, this option can also handle more flexibly the situation of receiving MBS data via two branches, such as in split bearers or PDCP packet redundancy. The UE can reduce the power consumption from the deactivated PTM branch. In the implementation of the NW, it should be noted that the continuous activation of the two branches can be determined, and the main idea of Option 4 below can be covered.

[0225] Option 2: Handover sequence / command-based handover

[0226] The gNB uses DCI, MAC CE, RRC signaling, etc. to indicate to the UE to switch between the PTM branch and the PTP branch. This option is the same as and / or similar to Option 1 above, and is simple because power is saved by deactivating the PTM branch. However, this option is less flexible for operations related to split bearers including PDCP packet redundancy. It can be considered that this option only involves the handover between the PTM branch and the PTP branch, and both of them cannot be activated.

[0227] Option 3: RRC reconfiguration-based handover

[0228] The gNB reconfigures PTM or PTP with RRC reconfiguration as the MRB for the UE. That is, the PTM branch and the PTP branch are not associated with one MRB. That is, it is similar to "bearer type change" and is inconsistent with the split MRB architecture. This option involves L3, so how to perform "dynamic" handover between PTM and PTP remains an issue.

[0229] Option 4: No handover-based signaling

[0230] When two branches are configured for split MRB, the UE needs to continuously attempt to receive from both the PTM branch and the PTP branch. With this option, from the perspective of the gNB, the maximum scheduling flexibility is ensured, but the UE has no opportunity to save energy.

[0231] To sum up, it can be said that in terms of scheduling flexibility, UE power consumption, and consistency with the split MRB architecture, Solution 1 is the most suitable solution. When the PTM branch is continuously active, Option 4 can be regarded as a subset of Option 1. Regarding the signaling layer, MAC CE can be simple because activation / deactivation is mainly related to DRX operations. Therefore, RAN2 needs to agree that the PTM branch of the split MRB can be activated / deactivated via MAC CE.

[0232] Recommendation 1: For dynamic PTM / PTP handover, RAN2 needs to agree to introduce MAC CE to activate / deactivate the PTM branch of the split MRB.

[0233] Regarding "bearer type change" which is different from dynamic handover, it is considered that the bearer type change has the following situations.

[0234] Situation 1: MRB for only PTM ←→ MRB for only PTP

[0235] Situation 2: Split MRB ←→ MRB for only PTM

[0236] Situation 3: Split MRB ←→ MRB for only PTP

[0237] In this case of bearer type change, it is simple to use RRC reconfiguration (i.e., option 3).

[0238] Solution 2: For the bearer type change between MRB for only PTM, MRB for only PTP, and split MRB, RAN2 needs to agree to the use of RRC reconfiguration.

[0239] 6. Behavior of PDCP

[0240] 7. Initial values of state variables

[0241] Except for the RLC UM mode, RAN2 agrees to support the RLC AM mode for the PTP branch of the split MRB. It is generally understood that since "RLC-AM does not support PTM (for MBS R17 WI)", the L2 reliability only depends on the dynamic PTM / PTP handover. Therefore, for the sake of service continuity, it is worth studying how to greatly reduce the packet loss when starting MBS data reception and dynamic PTM / PTP handover.

[0242] As Figure 21 shown, by reusing the existing PDCP functional view, the PDCP SN is common for both the PTM branch and the PTP branch. The PTM branch is used by multiple UEs, so the PDCP SN may not be UE-specific, which will affect both the PTM branch and the PTP branch. This means that when a UE participates in a multicast session late, regardless of which branch (PTM branch or PTP branch) the first received MBS data arrives from, the initial value of each state variable cannot be continuously set to "0". That is, the first PDCP SN received by the UE can be any value not assumed in the current unicast transmission. Since the state variables are configured with initial values, the PDCP re-establishment of a certain UE may affect all other UEs. This results in discarding the unexpected operations in the receive window, that is, the PDCP PDUs outside the window. The possibility of the same problem existing in the handover scenario is pointed out.

[0243] Observation 3: In the case where the UE joins the multicast session late and is configured with split MRBs, for both the PTM branch and the PTP branch, it is confirmed that the SN of the first received PDCP PDU is not the initial value (i.e., "0").

[0244] To solve this problem, the following options are proposed.

[0245] Option A: The gNB notifies the UE of the initial value of COUNT, or RX_NEXT and RX_DELIV.

[0246] This option is used to simply change the initial value related to the receive window based on the information from the gNB, so that the UE can receive the first transmission of MBS data in the existing mechanism. However, from the perspective of the PDCP layer, due to reasons such as the delay of handover, the deterioration of the radio state, and outside the RLC reconfiguration window, it is a problem whether the UE can continuously and correctly receive the first transmission intended by the gNB. In this case, it is not clear how this option works.

[0247] Option B: The gNB notifies the UE of the initial HFN, and the UE infers the initial HFN and SN based on the first received PDCP PDU.

[0248] The SN part is an option that is the same as and / or similar to the V2X mechanism of Release 16, as follows. "The initial value of the SN part of RX_NEXT is (x + 1) modulo (2 [sl-PDCP-SN-Size] ), and x is the SN of the first received PDCP data PDU", and "in NR sidelink communication for broadcast and multicast, 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.

[0249] Regarding the HFN part, in the Release 16 V2X mechanism, for security reasons, the HFN is not used, so synchronization between the sending device and the receiving device is not required. That is, there is the following description: "Note: The selection of the HFN of RX_NEXT depends on the implementation of the UE so that the initial value of RX_DELIV is positive". Regarding NR MBS, "in RAN2, before discussing the security aspects in RAN2, the answer given is to wait until the research related to the security of MBS in SA3 is completed". Therefore, in RAN2, the discussion of the HFN part needs to be postponed until after the completion of the research related to security in SA3.

[0250] In summary, further discussion needs to be based on Option B. According to the version 16 secondary link communication for broadcast and multicast, considering the development of SA3 related to the security of NR MBS, RAN2 needs to at least agree that the UE configures the initial value of the status variable according to the first received PDCP PDU of the MBS data.

[0251] Option 3: RAN2 needs to agree that for both the PTM branch and the PTP branch, the UE configures the initial value of the SN part of RX_NEXT and RX_DELIV according to the first received MBS data. Whether to notify the HFN part from the gNB depends on the progress of SA3 and further study is required.

[0252] 8. Simultaneous reception and UE assistance information

[0253] Specifically, in services that require reliability, PTP (branch) is configured in RLC AM, and for service continuity, it is important to perform lossless handover in the same and / or similar way as lossless mobility. When agreeing to Proposal 1, the UE needs to support receiving from both the PTM branch and the PTP branch simultaneously. That is, both branches can be activated simultaneously in the same and / or similar way as the existing PDCP packet redundancy. This is for the following reason: Since the PTM branch is received by multiple UEs, this may easily lead to non-optimal MCS for a specific UE. Therefore, RAN2 needs to agree to adopt simultaneous reception for at least a certain period during dynamic PTM / PTP handover.

[0254] Option 4: RAN2 needs to agree to support the UE receiving from both the PTM branch and the PTP branch simultaneously for a certain period after dynamic PTM / PTP handover.

[0255] When agreeing to Proposal 3 and Proposal 4, the gNB may not actually know which PDCP SN the UE has started to correctly receive via the PTM branch. In the case of switching from PTP to PTM, the gNB may not know when to use the PTP branch to send PDCP PDUs and when to stop sending on the PTP branch. To solve this problem, it is proposed that the UE notify the gNB of the successful reception of PTM and perform transmission via the PTP branch. Note that it is not clear whether the UE also needs to include PDCP SN information in the same message.

[0256] Observation 4: In the case of switching from PTP to PTM, the gNB may not know from which PDCP PDU to start maintaining the transmission on the PTP branch, or from which PDCP PDU the UE starts to correctly receive using the PTM branch.

[0257] In a similar and / or identical manner, in the case of switching from PTM to PTP, the gNB may not know which PDCP SN the UE has correctly received via the PTM branch (especially when the UE's radio state is poor). This means that the gNB may not know which PDCP PDU to use when starting the PTP branch.

[0258] Observation 5: In the case of switching from PTM to PTP, the gNB may not know which PDCP PDU to start transmitting the PTP branch from or which PDCP PDU the UE has correctly received via the PTM branch.

[0259] Therefore, the following is studied: When dynamically switching between PTM / PTP, the UE notifies the SN information to the gNB via the PTP branch. When reporting the SN information when the UE dynamically switches between PTM and PTP, it is simple to reuse the PDCP control PDU, that is, the PDCP status report including FMC (First PDCP SDU not found) and optionally including a bitmap (indicating whether subsequent PDCP SDUs are not found or correctly received). On the other hand, another option is for the UE to report the SN via the PTM branch, in which the first / last PDCP PDU reception of the UE has been successful. Therefore, the details of what the UE needs to report when dynamically switching between PTM and PTP need to be further discussed.

[0260] In any of the above cases (i.e., the case of switching from PTP to PTM and the case of switching from PTM to PTP), for the sake of service continuity, a PDCP control PDU including PDCP SN information needs to be triggered during dynamic switching (e.g., activation / deactivation of MAC CE).

[0261] Solution 5: RAN2 needs to study whether the UE needs to send a PDCP control PDU including PDCP SN information during dynamic switching for the sake of service continuity. It needs to be further studied whether the PDCP information reporting can be reused.

[0262] Another point that needs to be studied is whether a lossless bearer type change identical and / or similar to the lossless dynamic switching in Proposal 5 is required. From the perspectives of service continuity and lossless mobility, it is considered that the bearer type change including PTP (branch) with RLC AM requires the same and / or similar reliability as the dynamic switching. Therefore, RAN2 needs to study whether a lossless bearer type change needs to be supported. When this is supported, the PDCP control PDU needs to be reused as UE assistance information in the same and / or similar manner as in Proposal 5.

[0263] Suggestion 6: RAN2 needs to discuss whether the same solution as that for the lossless bearer type change with RRC reconfiguration (i.e., the lossless dynamic switching of PDCP control PDUs as used in Suggestion 5) can be applied.

[0264] Reference numeral

[0265] 1: Mobile communication system

[0266] 10: RAN

[0267] 20: CN

[0268] 100: UE

[0269] 110: Receiver

[0270] 120: Transmitter

[0271] 130: Controller

[0272] 200: gNB

[0273] 210: Transmitter

[0274] 220: Receiver

[0275] 230: Controller

[0276] 240: Backhaul communicator.

Claims

1. A communication method used in a mobile communication system for supporting Multicast and Broadcast Services (MBS), the communication method comprising the following steps: The user equipment receives a configuration of a multicast radio bearer from a base station, the multicast radio bearer being associated with a Radio Link Control (RLC) entity for Point-to-Point (PTP) transmission and an RLC entity for Point-to-Multipoint (PTM) transmission; And The user equipment processes the multicast radio bearer as an AM multicast radio bearer according to whether the RLC entity for PTP transmission is an Acknowledged Mode (AM) RLC entity.

2. The communication method according to claim 1, wherein According to the RLC entity for PTP transmission being an Unacknowledged Mode (UM) RLC entity and the RLC entity for PTM transmission being a UM RLC entity, the user equipment processes the multicast radio bearer as a UM multicast radio bearer.

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

4. A user equipment used in a mobile communication system for supporting Multicast and Broadcast Services (MBS), the user equipment comprising: A receiver that receives a configuration of a multicast radio bearer from a base station, the multicast radio bearer being associated with a Radio Link Control (RLC) entity for Point-to-Point (PTP) transmission and an RLC entity for Point-to-Multipoint (PTM) transmission; And A controller that processes the multicast radio bearer as an AM multicast radio bearer according to whether the RLC entity for PTP transmission is an Acknowledged Mode (AM) RLC entity.

5. A mobile communication system, comprising a base station and the user equipment according to claim 4.

6. A chipset, comprising means for executing the communication method according to claim 1.

7. A computer program product, comprising a computer program which, when executed by a processor of a user equipment, causes the user equipment to execute the communication method according to claim 1.

Images