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

Abstract

The first aspect relates to a communication method used in a mobile communication system supporting multicast and broadcast services (MBS), the communication method comprising: a step in which a user equipment that has started receiving an MBS session from a base station determines whether a predetermined condition indicating that reception starts from the middle of the MBS session is satisfied; and if it is determined that the predetermined condition is satisfied, the user equipment sends to the base station lost packet identification information indicating a group of lost packets between the start of the MBS session and the start of reception.

Description

Technical Field

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

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

[0003] Reference List

[0004] Non-patent literature

[0005] Non-patent literature 1: 3GPP document: RP-201038, "WID revision: NR Multicast and Broadcast Services" Summary of the invention

[0006] 5G / NR multicast and broadcast services are expected to provide enhanced services compared to 4G / LTE multicast and broadcast services.

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

[0008] In a first aspect, a communication method is used in a mobile communication system for supporting a multicast and broadcast service (MBS). The communication method includes: a user equipment that has started receiving an MBS session from a base station 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 lost packet group from the start of the MBS session until the start of the reception.

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

[0010] In a third aspect, a communication method is used in a mobile communication system for supporting a multicast and broadcast service (MBS). The communication method includes: a user equipment receives configuration information from a base station, the configuration information being used to configure 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 determines whether the split radio bearer is an acknowledged mode AM bearer or an unacknowledged mode UM bearer based on a radio link control RLC mode configured for each of the PTP branch and the PTM branch.

[0011] In a fourth aspect, a user equipment is used in a mobile communication system for supporting a multicast and broadcast service (MBS). The user equipment comprises: a receiver configured to receive configuration information from a base station, the configuration information being used to configure 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 a radio link control RLC mode configured for each of the PTP branch and the PTM branch. BRIEF DESCRIPTION OF THE DRAWINGS

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

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

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

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

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

[0017] Figure 6 is a diagram showing an overview of MBS service delivery according to an embodiment.

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

[0019] Figure 8 is a diagram illustrating split multicast radio bearers (MRBs) according to an embodiment.

[0020] Fig. 9is a diagram illustrating an operation of a PDCP layer in a mobile communication system according to an embodiment.

[0021] Fig.10 is a diagram showing COUNT values ​​according to an embodiment.

[0022] Fig.11 is a diagram illustrating a PDCP data PDU according to an embodiment.

[0023] Fig.12 is a diagram showing an operation for identifying RCVD_COUNT.

[0024] Fig.13 is a diagram illustrating the operation of a receiving-side PDCP entity of a UE.

[0025] Fig.14 is a diagram showing the operation of the UE according to the first embodiment.

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

[0027] Fig.16 are diagrams showing configuration examples 1 to 3 of a PDCP status report according to the first embodiment.

[0028] Fig.17 is a diagram showing a configuration example of an RRC message according to the first embodiment.

[0029] Fig.18 is a diagram showing a first modification example of the operation according to the first embodiment.

[0030] Fig.19 is a diagram showing a second modification of the operation according to the first embodiment.

[0031] Fig. 20 is a diagram showing the operation of the UE according to the second embodiment.

[0032] Fig.21 is a diagram showing switching of PDCP fixed type PTM / PTP based on the current protocol. DETAILED DESCRIPTION

[0033] A mobile communication system according to an embodiment is 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.

[0034] First embodiment

[0035] Configuration of mobile communication system

[0036] Figure 11 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 fifth generation system (5GS) of the 3GPP standard. The following description takes 5GS as an example, but the long term evolution (LTE) system may be at least partially applied to the mobile communication system. The sixth generation (6G) system may be at least partially applied to the mobile communication system.

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

[0038] UE 100 is a mobile wireless communication device. UE 100 may be any device as long as UE 100 is used by a user. Examples of 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 a sensor, a vehicle or a device provided on a vehicle (vehicle UE), and a flying object or a device provided on a flying object (air UE).

[0039] 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 which is an interface between base stations. Each gNB 200 manages one or more cells. The gNB 200 performs wireless communication with the UE 100 which 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, referred to as "data"), a measurement control function for mobility control and scheduling, and the like. "Cell" is used as a term representing the smallest unit of a wireless communication area. "Cell" is also used as a term representing a function or resource used to perform wireless communication with the UE 100. One cell belongs to one carrier frequency (hereinafter referred to as "frequency").

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

[0041] 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 an NG interface, which is an interface between a base station and a core network.

[0042] Figure 2 1 is a diagram showing a 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.

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

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

[0045] The controller 130 performs various types of control and processing in the UE 100. Such processing includes processing of various layers 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 processing 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 of baseband signals, etc. The CPU executes the program stored in the memory, thereby performing various types of processing.

[0046] Figure 3 2 is a diagram showing a 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 performs communication with the CN 20.

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

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

[0049] The controller 230 performs various types of control and processing in the gNB 200. Such processing includes processing of various layers 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 processing by the processor. The processor may include a baseband processor and a CPU. The baseband processor performs modulation and demodulation, encoding and decoding of baseband signals, etc. The CPU executes the program stored in the memory, thereby performing various types of processing.

[0050] The backhaul communicator 240 is connected to the neighboring 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) (ie, the functions are divided), and the two units may be connected via the F1 interface as the fronthaul interface.

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

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

[0053] 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 the UE 100 and the PHY layer of the gNB 200 via a physical channel. Note that the PHY layer of the UE 100 receives downlink control information (DCI) transmitted from the gNB 200 through the physical downlink control channel (PDCCH). Specifically, the UE 100 blindly decodes the PDCCH using the radio network temporary identifier (RNTI) and acquires the successfully decoded DCI as the DCI addressed to the UE 100. The DCI transmitted from the gNB 200 is attached with CRC parity bits scrambled by the RNTI.

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

[0055] The RLC layer transmits data to the RLC layer of 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.

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

[0057] The SDAP layer performs 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, SDAP does not need to be provided.

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

[0059] 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, instead of Figure 4 The SDAP layer shown in .

[0060] RRC signaling for various configurations is transmitted between the RRC layer of the UE 100 and the RRC layer of the gNB 200. The RRC layer controls logical channels, transport channels, and physical channels according to the establishment, reestablishment, 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 the 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 the 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 the RRC inactive state.

[0061] The NAS layer located above the RRC layer performs session management, mobility management, etc. NAS signaling is transmitted between the NAS layer of the UE 100 and the NAS layer of the AMF 300A. Note that the UE 100 includes an application layer in addition to the protocol of the radio interface. A layer lower than the NAS layer is called an AS layer.

[0062] Overview of MBS

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

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

[0065] The multicast service does not provide services to each UE 100, but provides services to a group of UEs 100 participating in the multicast service (multicast session). An MBS session for multicast services is called a multicast session. Multicast services can provide the same content to the group of UEs 100 in a method with higher radio efficiency than broadcast services.

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

[0067] MBS services (MBS data) are transmitted from a single data source (application service provider) to multiple UEs. 5G CN (5GC) 20 as a 5G core network receives MBS data from the application service provider and performs replication of the MBS data to transmit a replication product.

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

[0069] In the 5GC individual MBS service delivery method, the 5GC 20 receives a single copy of the MBS data packet and transmits individual 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.

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

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

[0072] In the PTP transmission method, the gNB 200 wirelessly transmits individual copies 100 of the MBS data packet to each UE. On the other hand, in the PTM transmission method, the gNB 200 wirelessly transmits 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 transmission method or the PTP transmission method as a method for transmitting MBS data to one UE 100.

[0073] The PTP and PTM transmission methods are mainly related to the user plane.The mode for controlling MBS data transmission includes two transmission modes: a first transmission mode and a second transmission mode.

[0074] Figure 7 is a diagram showing a transmission mode according to the first embodiment.

[0075] The first transmission mode (Transmission Mode 1 (DM1)) is a transmission mode that can be used by the UE 100 in the RRC connected state, and is a transmission mode for high QoS requirements. The first transmission mode is used for a multicast session among MBS sessions. Note that the first transmission mode can be used for a broadcast session. The first transmission mode can be available to the UE 100 in the RRC idle state or the RRC inactive state.

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

[0077] The MBS reception configuration includes MBS service channel configuration information (hereinafter referred to as "MTCH configuration information") regarding the configuration of the MBS service channel carrying MBS data. The MTCH configuration information includes MBS session information related to the MBS session and scheduling information of the MBS service channel corresponding to the MBS session. The scheduling information of the MBS service channel may include a discontinuous reception (DRX) configuration of the MBS service channel. The discontinuous reception configuration may include at least one parameter of the following: a timer value (on duration timer) for defining an on period (on duration: receiving period), a timer value (inactive timer) for extending the on period, a scheduling interval or a DRX cycle (scheduling period, DRX cycle), an offset value (starting offset, DRX cycle offset) for the starting subframe of the scheduling period or the DRX cycle, a starting delay time slot value (time slot offset) of the on period timer, a timer value (retransmission timer) for defining the maximum time before retransmission, and a timer value (HARQ RTT timer) for defining the minimum interval before DL assignment of HARQ retransmission.

[0078] Note that the MBS traffic channel is a 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 transport channel.

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

[0080] MBS reception configuration in the second transmission mode is performed by broadcast signaling. For example, MBS reception configuration in the second transmission mode is performed using a logical channel (e.g., a broadcast control channel (BCCH) and / or a multicast control channel (MCCH)) sent from the gNB 200 to the UE 100 by broadcast. For example, the UE 100 may receive the BCCH and the MCCH using a dedicated RNTI predefined in the technical specification. The RNTI for BCCH reception may be an SI-RNTI, and the RNTI for MCCH reception may be an MCCH-RNTI.

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

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

[0083] The network can provide different MBS services for different MBS sessions. The MBS session is identified by at least one item selected from the group consisting of a temporary mobile group identity (TMGI), a 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), a session identifier, and a G-RNTI. At least one item selected from the group consisting of a TMGI, a G-RNTI, a source-specific IP multicast address, and a session identifier is referred to as an MBS session identifier. The TMGI, the source-specific IP multicast address, the session identifier, and the G-RNTI are collectively referred to as MBS session information.

[0084] Figure 8 is a diagram showing a split multicast radio bearer (MRB) according to a first embodiment. An MRB may be a type of data radio bearer (DRB). Split MRB may be used in the above-mentioned first transmission mode.

[0085] The gNB 200 may configure MRB splitting into a PTP communication path and a 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 perform repeated transmission of the same MBS data using both PTP (PTP communication path) and PTM (PTM communication path) to enhance reliability. Hereinafter, the PTP communication path is referred to as a PTP branch, and the PTM communication path is referred to as a PTM branch. The functional unit corresponding to each layer is referred to as an entity.

[0086] The predetermined layer for terminating segmentation is a MAC layer (HARQ), an RLC layer, a PDCP layer, or an SDAP layer. Although the following mainly describes an example in which the predetermined layer for terminating segmentation is a PDCP layer, the predetermined layer may be a MAC layer (HARQ), an RLC layer, or an SDAP layer.

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

[0088] Each of the gNB 200 and the UE 100 includes two RLC entities provided for the corresponding branch: a MAC entity and a PHY entity. A PHY entity may be provided for each branch. Note that in a dual connectivity where the UE 100 communicates with two gNBs 200, the UE 100 may include two MAC entities.

[0089] The PHY entity uses a cell RNTI (cell radio network temporary identifier (C-RNTI)) assigned one-to-one to the UE 100 to send and receive data of the PTP branch. The PHY entity uses a G-RNTI assigned one-to-one to the MBS session to send and receive data of the PTM branch. 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.

[0090] In order to perform PTM transmission (multicast or broadcast) of MBS data from gNB 200 to UE 100 using a PTM branch, a split MRB needs to be configured from gNB 200 to UE 100, and the PTM branch needs to be activated (activation). In other words, even if a split MRB is configured for UE 100, when a PTM branch is in a deactivated state, gNB 200 cannot perform PTM transmission of MBS data using the PTM branch.

[0091] In order for the gNB 200 and the UE 100 to use the PTP branch to perform PTP transmission (unicast) of the MBS data, a split MRB needs to be configured from the gNB 200 to the UE 100, and the PTP branch needs to be activated. In other words, even if a split MRB is 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 the MBS data.

[0092] When the PTM branch is in an activated state, the UE 100 monitors the PDCCH to which the G-RNTI associated with the MBS session is applied (ie, blind decoding of the PDCCH is performed using the G-RNTI). The UE 100 may monitor the PDCCH only at the scheduling occasion of the MBS session.

[0093] When the PTM branch is in the deactivated state, the UE 100 does not monitor the PDCCH to which the G-RNTI associated with the MBS session is applied (ie, does not perform blind decoding of the PDCCH using the G-RNTI).

[0094] When the PTP branch is in the activated state, the UE 100 monitors the PDCCH to which the C-RNTI is applied. When discontinuous reception (DRX) in the PTP branch is configured, the UE 100 monitors the PDCCH during the configured OnDuration period. When a cell (frequency) associated with an MBS session is specified, the UE 100 can monitor the PDCCH for the cell even when the cell is deactivated.

[0095] When the PTP branch is in the deactivated state, the UE 100 may monitor the PDCCH to which the C-RNTI is applied to prepare for normal unicast downlink transmission except for MBS data. Note that when specifying a cell (frequency) associated with an MBS session, the UE 100 does not need to monitor the PDCCH for that MBS session.

[0096] Note that it is assumed that the above-mentioned split MRB is configured by an RRC message (e.g., an RRC reconfiguration message) sent by the RRC entity of gNB 200 to the RRC entity of UE 100.

[0097] PDCP layer operations

[0098] Fig. 9 is a diagram showing the operation of the PDCP layer in the mobile communication system 1 according to the first embodiment.

[0099] The gNB 200 transmits a signal to multiple UEs 100 (in Fig. 9In the example of UE 100a to UE 100c, the MBS data of a certain MBS session is sent. 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. MBS transmission in the first transmission mode can use a PTM branch.

[0100] In the PDCP layer, the gNB 200 includes a PDCP entity 201 associated with an 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 transmission of the MBS session, the PDCP entity 201 manages PDCP variables updated in response to transmission of PDCP packets in the MBS session.

[0101] In the PDCP layer, each UE 100 includes a PDCP entity 101 associated with an MBS session (specifically, a receiving-side PDCP entity associated with an MRB belonging to the MBS session). Fig.10 In the example of FIG. 1 , when the PDCP entity 101a starts transmission of an MBS session from the PDCP entity 101b to the PDCP entity 101a, the PDCP entity 101 manages PDCP variables that are updated in response to reception of PDCP packets in the MBS session.

[0102] like Fig.10 As shown, the PDCP variable may be a count value (COUNT value) including a hyperframe number (HFN) that counts up each time the PDCP sequence number performs 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 (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 configured using RRC signaling. Note that the term "PDCP variable" does not necessarily indicate a COUNT value, and may also be used as a term indicating various variables (HFN, PDCP SN, etc.) handled in the PDCP layer.

[0103] Fig.11 is a diagram showing a PDCP packet (specifically, a PDCP data protocol data unit (PDU)) constituting MBS data. Fig.11As shown, the PDCP data PDU includes 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 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 makes a full round.

[0104] Fig.12 FIG. is a diagram showing an operation for identifying RCVD_COUNT, where RCVD_COUNT is the COUNT value of the 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.

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

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

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

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

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

[0110] 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 a 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 higher layer of the integrity verification failure and discards the PDCP PDU (step S13).

[0111] When the receiving side PDCP entity 101 succeeds in 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).

[0112] Next, the receiving side PDCP entity 101 stores the PDCP PDU that is not discarded in the receiving buffer (step S17), and when "RCVD_COUNT≥RX_NEXT" (step S18: yes), the receiving side PDCP entity 101 updates to 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 transmits the result to the upper layer (step S21). Specifically, when "outOfOrderDelivery" is configured in RRC, the receiving side PDCP entity 101 performs the operation of S21. Out-of-order delivery is an operation of transmitting packets to a higher layer without performing sequence control. Therefore, as in step S21, immediately after the packet is received and stored in the buffer, the packet is transferred to the upper layer. Note that when step S20 is "No", sequential control is performed.

[0113] 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 transmits the result to the upper layer (step S23), and updates RX_DELIV to the first (lowest) COUNT value that has not been transmitted to the upper layer (step S24).

[0114] 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 loss of PDCP data PDUs. RX_REORD is a variable indicating a COUNT value after the COUNT value associated with the PDCP data PDU for triggering T-Reordering.

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

[0116] Operation of mobile communication systems

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

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

[0119] Here, when the MBS session is a session for streaming data delivery, the loss of packets is not particularly a problem. In contrast, when the MBS session is a session for downloading files (e.g., software delivery), files resulting in incomplete files are a problem. The first embodiment is an embodiment in which a lost packet group can be retransmitted to the UE 100 in the AS layer.

[0120] 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, or RRC inactive state). Note that at the point in time when transmission to gNB 200 is performed, UE 100 is in the RRC connected state. The MBS transmission mode may be the first transmission mode. The MBS transmission mode may be the second transmission mode.

[0121] 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 from gNB 200 through PTM (MBS reception). When UE 100 starts MBS reception, UE 100 establishes a receiving-side PDCP entity 101 that handles a multicast radio bearer (MRB) associated with the MBS session.

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

[0123] The predetermined condition may be the following condition: the MBS session is joined midway. The UE 100 may determine to join the MBS session midway based on, for example, one of the following methods 1 to 10.

[0124] Method 1: In the case of the first delivery mode (DM1), after the UE 100 participates in the MBS session through the NAS procedure, when the MBS configuration (e.g., MRB configuration) is performed by RRC reconfiguration from the gNB 200 within a certain period (e.g., immediately thereafter), the UE 100 can determine that the UE 100 (most likely) has participated in the MBS session in the middle, and when the MBS configuration is performed after the certain period has passed, the UE 100 can determine that the UE 100 (most likely) has participated in the MBS session from the beginning. The certain period may be configured for the UE 100 from 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 may be a counter value (e.g., a counter value indicating a range of system frame numbers).

[0125] Method 2: In the case of the first transmission mode (DM1), after UE 100 participates in the MBS session through the NAS procedure, UE 100 monitors the 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, UE 100 can determine that 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, UE 100 can determine that UE 100 has (most likely) participated in the MBS session midway.

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

[0127] Method 4: When the AMF 300A allows the participation request from the UE 100 in the MBS session participation procedure in the NAS procedure, the UE 100 can determine whether the UE 100 has joined the MBS session from the beginning or in the middle by obtaining information indicating that the session is being sent (is active) or information indicating that the session is stopped (is suspended, is inactive, or is configured) from the AMF 300A.

[0128] 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, the UE 100 can determine whether the UE 100 has participated in the MBS session from the beginning or in the middle based on the information of the USD.

[0129] Method 6: When the UE 100 is notified from a higher layer (eg, application layer) that the file is incomplete (cannot be restored), the UE 100 may determine that the UE 100 has already participated in the MBS session midway. The notification may be notified from the application layer to the NAS layer, and from the NAS layer to the AS layer.

[0130] Method 7: In the UE 100, when the NAS layer notifies the AS layer that the MBS session is joined midway, the AS can recognize that the MBS session is joined midway.

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

[0132] Method 9: The 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) indicating that file recovery of an MBS session (e.g., MRB) may be performed (or indicating that previous data of the MBS session is stored, or indicating that file recovery of the MBS session is allowed) to the UE 100, and based on the notification, the UE 100 may implicitly determine that the UE 100 has been in the middle of participating in the MBS session. Such a notification may be a notification according to the first variant to be described later.

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

[0134] The predetermined condition may be a condition that the sequence number (SN) of the MBS packet first received by the UE 100 regarding the MBS session is not an initial value. For example, when the PDCP SN included in the PDCP data PDU first received by the UE 100 regarding the MBS session is not zero, the UE 100 may determine that the MBS reception has started in the middle of the MBS session. Here, zero is an example of an initial value. Note that although the PDCP SN does not necessarily need to be used and the RLC SN may be used instead to perform the determination, an example in which 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.

[0135] When it is determined that the predetermined condition is satisfied (step S2: yes), in step S3, UE 100 transmits lost packet identification information indicating a lost packet group from the start of the MBS session until the start of MBS reception to gNB 200. The lost packet identification information includes information indicating the sequence number (e.g., PDCP SN) of the last lost packet of the lost packet group. Therefore, gNB 200 can recognize until 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).

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

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

[0138] The gNB 200, which has received the lost packet identification information from the UE 100, sends (retransmits) the lost packet group indicated by the lost packet identification information to the UE 100.

[0139] In step S4, UE 100 receives a lost packet group from gNB 200. UE 100 may receive a lost packet group sent from gNB 200 via PTP. Figure 8 As shown, UE 100 can use the PTM branch to receive MBS data, and use the PTP branch to receive lost packet groups retransmitted by gNB 200. Note that UE 100 can use the PTM branch to receive lost packet groups retransmitted by gNB 200.

[0140] As described above, according to the first embodiment, when UE 100 determines that a predetermined condition indicating that MBS reception has started in the middle of an MBS session is satisfied, UE 100 transmits lost packet identification information indicating a lost packet group from the start of the MBS session until the start of MBS reception to gNB 200. Therefore, gNB 200 can perform retransmission of the lost packet group to UE 100.

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

[0142] In step S101, gNB 200 starts to provide an MBS session (multicast session or broadcast session). Specifically, gNB 200 starts to send MBS data about the MBS session in PTM. Fig.15 An example is shown in which 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.

[0143] Note that the gNB 200 stores the transmitted packets and their sequence numbers in association with each other, thereby preparing for retransmission of lost packet groups. For example, the transmitting-side 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.

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

[0145] In step S104, UE 100 identifies the lost packet group. UE 100 may 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 transmission from SN=0 and the first packet received by UE 100 from gNB 200 is SN=100, it may be determined that the packet group of SN=0 to 99 is lost.

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

[0147] Fig.16 1 is a diagram showing configuration examples 1 to 3 of the PDCP status report according to the first embodiment. At the beginning of the PDCP control PDU (PDCP status report), a D / C field and a PDU type field may be provided, the D / C field indicating that the PDCP PDU is a control PDU, and the PDU type field indicating that the PDCP PDU is a PDCP status report. In the PDU type field, information indicating an MBS-dedicated PDCP status report may be set.

[0148] In configuration example 1, the PDCP status report includes the following fields: First Loss COUNT (FMC), and Bitmap. In the FMC field, the COUNT value of the first lost PDCP SDU in the reordering window, i.e., RX_DELIV, is set. In the bitmap field, a bit associated with each PDCP PDU is set, and when the PDCP PDU is correctly received, "1" is set, and when the PDCP PDU is lost, "0" is set.

[0149] In configuration example 2, the PDCP status report includes the following fields: FMC, and last loss COUNT (LMC). In the LMC field, the sequence number (COUNT value) of the last packet in the lost packet group is set. In the LMC field, the COUNT value of the first successfully received packet (LMC+1, for example, first success COUNT (FSC)) can be set. In the above configuration example 1, the bit length of the bitmap field can be longer (for example, a bitmap of 200 packets is 200 bits); however, by providing the LMC field instead of the bitmap field, the bit length of the PDCP status report can be reduced.

[0150] In configuration example 3, the PDCP status report includes the LMC field. Since the gNB 200 knows the first transmission packet (corresponding to the FMC), by being informed of the LMC, the gNB can identify from which data to which data is lost. 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.

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

[0152] The RRC message includes an MRB identifier (bearer ID, RLC channel ID, LCID, etc.) or an MBS session identifier (TMGI, etc.) and lost packet identification information. The configuration of the lost packet identification information may be the same and / or similar to the configuration of the above-mentioned PDCP status report. In order to generate such an RRC message in the RRC layer, the receiving side PDCP entity 101 of the UE 100 may provide the RRC layer with information related to the lost packet group.

[0153] Return to reference Fig.15 In step S105, gNB 200 receives lost packet identification information from UE 100.

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

[0155] Note that due to the limitation of the buffer capacity of the gNB 200, etc., 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 try file recovery. FLUTE is a higher layer data recovery mechanism defined in IETF RFC 6726 / RFC 3926, and the UE 100 then obtains the lost data (FLUTE blocks) from the application server via unicast.

[0156] First Modification

[0157] By considering the limitation of the buffer capacity of the gNB 200, it is considered not preferable that the UE 100 can request the gNB 200 to perform retransmission without restriction. Therefore, the gNB 200 can send information for controlling the transmission of the lost packet identification information of the UE 100 to the UE 100.

[0158] Fig.18 1 is a diagram showing a first modification 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.

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

[0160] For example, in step S131, the gNB 200 may send range information as control configuration information to the UE 100, the range information indicating the range of sequence numbers of the lost packet group that the UE 100 is allowed to indicate through the lost packet identification information. In step S105, the UE 100 may send 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.

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

[0162] Alternatively, in step S131, the gNB 200 may send notification information indicating whether the gNB 200 has stored (buffered) the first transmission packet of the MBS session to the UE 100 as control configuration information. The UE 100 may 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 transmission packet, data recovery in the AS layer cannot be fully recovered. Therefore, when the notification information indicates that the gNB 200 has not stored the first transmission packet, the UE 100 may 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 has stored the first transmission packet, the UE 100 may send the lost packet identification information to the gNB 200 (step S105). The notification information may be information indicating whether the gNB 200 stores the transmission packet whose sequence number is zero as the first transmission packet. That is, the notification information may be information for notifying whether retransmission can be performed starting from the first packet.

[0163] Second Modification

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

[0165] Fig.19 1 is a diagram showing a second modification 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.

[0166] 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 a PTM-only MRB to perform MBS data reception), the UE 100 sends request information for requesting configuration of the PTP communication path to the gNB 200. The UE 100 may send the 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 configuration of a PTP branch, information indicating a desire to perform data recovery, information indicating that uplink transmission is required, or information indicating that an MRB needs to be split. The RRC message may also 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., a TMGI) of a target MRB.

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

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

[0169] Second embodiment

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

[0171] A data radio bearer (DRB) is classified into one of an AM DRB and a UM DRB depending on whether the corresponding RLC mode is an acknowledged mode (AM) or an unacknowledged mode (UM). 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, a triggering condition for a PDCP status report on a DRB is different depending on whether the DRB is an AM DRB or a UM DRB.

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

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

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

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

[0176] Specifically, when the RLC entity of the PTP branch is configured with AM or the RLC entity of the PTM branch is configured with AM with respect to the configured split MRB, the UE 100 may determine that the split MRB is an AM MRB. When the PTP branch is configured with bidirectional UM and / or the PTM branch is configured with bidirectional UM, the UE 100 may determine that the split MRB is an AM MRB.

[0177] When the RLC entity of the PTP branch is configured with UM and the RLC entity of the PTM branch is configured with UM with respect to the configured split MRB, the UE 100 may determine that the split MRB is a UM MRB. When the PTP branch is configured with unidirectional UM and the PTM branch is configured with unidirectional UM, the UE 100 may determine that the split MRB is a UM MRB.

[0178] As a variation of the second embodiment, the gNB 200 may configure whether the split MRB is an AM MRB or a UM MRB (i.e., which mode the split MRB 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 configured MRB mode.

[0179] Specifically, the gNB 200 explicitly configures to the UE 100 whether the MRB is considered to be an AM MRB or a UM MRB. For example, when the gNB 200 configures a split MRB for the UE 100 using 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.

[0180] Other embodiments

[0181] The above operation flow can be implemented individually and independently, and can also be implemented by combining two or more of the operation flows. For example, some steps in one operation flow can be applied to another operation flow. Some steps in one operation flow can be replaced by some steps in another operation flow.

[0182] In the above embodiments and examples, an example in which the base station is an NR base station (i.e., gNB) is 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 a DU of an IAB node. The user equipment may be a mobile terminal (MT) of an IAB node.

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

[0184] Unless otherwise expressly stated, the phrases "based on" and "depending on" used in this disclosure do not mean "based only on" and "depending only on". The phrase "based on" means both "based only on" and "based at least in part on". Similarly, the phrase "depending on" means "depending only on" and "depending at least in part on". "Obtaining" or "obtaining" can mean obtaining information from stored information, can mean obtaining information from information received from another node, or can mean obtaining information by generating information. The terms "including", "comprising" and their variants do not mean "including only the items", but mean "can only include the items" or "can include not only the items but also 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 does not generally limit the number or order of these elements. These names can be used as a convenient method to distinguish two or more elements in this article. Therefore, the reference to the first element and the second element does not mean that only two elements can be used there or that the first element needs to be in some way before the second element. For example, when English articles such as "a", "an" and "the" are added in this disclosure by translation, these articles include plural unless the context clearly indicates otherwise.

[0185] 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 may be made without departing from the gist of the present disclosure.

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

[0187] Additional Notes

[0188] 1. Introduction

[0189] A revised work item related to NR Multicast and Broadcast Service (MBS) was approved in RAN#88. The aim is to define mobility including dynamic PTM / PTP handover and service continuity as shown below.

[0190] Defines the RAN basic functions for broadcast / multicast for UEs in RRC connected state.

[0191] Support for dynamic change of broadcast / multicast service delivery between multicast (PTM) and unicast (PTP) providing service continuity for specific UEs is defined.

[0192] Support for basic mobility with service continuity is defined.

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

[0194] In the case of UE, the gNB dynamically determines which of PTM and PTP will be used to transmit the multicast data (shared transmission).

[0195] Further study is needed on how the layer handles reliability (in general), cases of in-order delivery / overlapping processing, and further study is needed on how the layer functions in switching between PTM and PTP.

[0196] In RAN2#113-e, the following agreement has been reached in the discussion related to L2 reliability in the architecture of dynamic PTM / PTP switching.

[0197] When both PTM and PTP are RLC UM, there is no L2 ARQ, and configurations using switching between PTM and PTP with fixed PDCP are supported (eg, when services for unicast are normally configured in RLC UM).

[0198] In RAN2#113bis-e, further agreement has been reached on architecture and signaling as shown below.

[0199] protocol

[0200] It should be noted that the following protocol is based only on the architecture determined so far. Discussions on reliability have not yet been completed. In other words, this is a different case from RLC UM+RLC UM. Further research is needed on the switching between PTM and PTP in this other case.

[0201] Dynamic PTM / PTP switching is supported using split MRB bearer (type) including a common (single) PDCP entity.

[0202] Basically, no new UE-based signaling has been introduced to support determining gNB handover (e.g., PDCP SR for high reliability has not been determined).

[0203] Assuming a split MRB with PTM legs and PTP legs is configured (negotiated during an online session), the use of the PTP legs cannot be deactivated after the necessary split MRB configuration (ie, the UE does not need to continuously monitor the C-RNTI).

[0204] Assuming a split MRB with PTM legs and PTP legs is configured (agreed during an online session), further study is needed to determine whether the use of the PTM legs of the split MRB can be activated or deactivated and the details of this.

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

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

[0207] In order to support lossless handover of 5G MBS services, at least the synchronization of DL PDCP SN and continuity between source and target cells need not be ensured in the network. The specific method design for achieving this may be related to WG RAN3.

[0208] In the network, the source gNB can transmit data to the target gNB, and the target gNB transmits 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 the MBS in the target cell through the target cell according to the target configuration.

[0209] From the UE, PDCP status reporting may also be supported.

[0210] In a supplementary note, the remaining issues of dynamic PTM / PTP switching and mobility provided with service continuity based on the agreed architecture (ie, using split MRB fixed to PDCP) will be described.

[0211] 2. Discussion

[0212] 3. Split MRB configuration

[0213] Based on the current protocol, the architecture of PTM / PTP switching fixed to PDCP (i.e., split MRB) can be as follows Fig.21 Explain as shown.

[0214] In general, it can be considered that RRC reconfiguration is used to provide a bearer configuration including two logical channels (PTM leg and PTP leg) and information for receiving a multicast session. RAN2 describes "assuming a split MRB configured with PTM leg and PTP leg (negotiated during online session)"; however, it is considered that providing a configuration in which two logical channels are associated with one multicast radio bearer with RRC reconfiguration is already a common understanding as a preparation for dynamic PTM / PTP switching.

[0215] Observation 1: Prior to the dynamic PTM / PTP switching operation, it was considered a common understanding to provide a configuration of associating two logical channels with one MRB with RRC reconfiguration.

[0216] 4. Dynamic PTM / PTP switching operation

[0217] 5. Signaling

[0218] Further studies are needed to investigate whether the use of split MRB and PTM branches can be activated or deactivated and their details.

[0219] 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, DRX is different. G-RNTI is received by multiple UEs, while 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, a UE in a connected state needs to monitor the C-RNTI (ie, C-DRX) for unicast reception; however, this is not an additional burden on the UE.

[0220] Observation 2: In addition to the transmission occasion of the PTP branch (ie, C-RNTI) same as C-DRX, the UE also needs to wake up for the transmission occasion of the PTM branch (ie, G-RNTI) as in the SC-MTCH occasion of LTE SC-PTM.

[0221] When receiving an MRB with PTM / PTM (ie, at the time of a handover operation), there are the following four options.

[0222] Option 1: Switching based on activation / deactivation

[0223] The gNB uses DCI, MAC CE, RRC signaling, etc. to instruct the UE to enable / disable the PTM branch. In addition to receiving MBS data via PTM or PTP, this option can also more flexibly handle the case of receiving MBS data via two branches, such as in split bearer or PDCP packet redundancy. The UE can reduce power consumption from the deactivated PTM branch. In the implementation of the NW, it should be noted that the continued activation of the two branches can be determined, and the subject matter of the following option 4 can be covered.

[0224] Option 2: Switching order / command-based switching

[0225] The gNB uses DCI, MAC CE, RRC signaling, etc. to instruct the UE to switch between PTM branches and PTP branches. This option is the same 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 switching between PTM branches and PTP branches, and both of them cannot be activated.

[0226] Option 3: Handover based on RRC reconfiguration

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

[0228] Option 4: No handover-based signaling

[0229] When two branches are configured for split MRB, the UE needs to continuously try to receive from both the PTM branch and the PTP branch. With this option, maximum scheduling flexibility is ensured from the gNB's perspective, but there is no opportunity for energy saving for the UE.

[0230] In summary, it can be said that option 1 is the most suitable option in terms of scheduling flexibility, UE power consumption, and consistency with the split MRB architecture. When the PTM branch is continuously active, option 4 can be considered as a subset of option 1. Regarding the signaling layer, the MAC CE can be simple because the activation / deactivation is mainly related to the DRX operation. Therefore, RAN2 needs to agree that the PTM branch can be activated / deactivated via MAC CE.

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

[0232] Regarding "bearer type change" which is different from dynamic switching, the bearer type change is considered to have the following cases.

[0233] Case 1: PTM-only MRB ←→ PTP-only MRB

[0234] Case 2: Split MRB ←→ PTM-only MRB

[0235] Case 3: Split MRB ←→ PTP-only MRB

[0236] In the case of this bearer type change, it is straightforward to use RRC reconfiguration (ie, option 3).

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

[0238] 6. PDCP Behavior

[0239] 7. Initial values ​​of state variables

[0240] In addition to RLC UM mode, RAN2 agreed to support RLC AM mode for splitting the PTP legs of MRBs. It is generally understood that since "RLC-AM does not support PTM (for MBS R17 WI)", L2 reliability depends only on dynamic PTM / PTP switching. Therefore, it is worth studying how to greatly reduce the packet loss at the start of MBS data reception and dynamic PTM / PTP switching for service continuity.

[0241] like Fig.21 As shown, by reusing the existing PDCP functional view, the PDCP SN is common for 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 affects both the PTM branch and the PTP branch. This means that when a UE participates in a multicast session later, the initial value of each state variable cannot be continuously set to "0" regardless of which branch (PTM branch or PTP branch) the first received MBS data arrives from. That is, the PDCP SN first received by the UE can be any value that is not assumed in the current unicast transmission. Since the state variables are configured as initial values, the PDCP re-establishment of a certain UE may affect all other UEs. This results in the discarding of unexpected operations in the receive window, i.e., PDCP PDUs outside the window. The possibility of the same problem also existing in the switching scenario is pointed out.

[0242] Observation 3: In the case where the UE joins the multicast session late and is configured with split MRB, both the PTM branch and the PTP branch confirm that the SN of the first received PDCP PDU is not the initial value (ie, "0").

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

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

[0245] This option is used to simply change the initial value related to the receive window based on 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, it is questionable whether the UE can continue to correctly receive the first transmission intended by the gNB due to delays in handover, degradation of the wireless state, being outside the RLC reconfiguration window, etc. In this case, it is unclear how this option works.

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

[0247] The SN part is an option that is the same and / or similar to the V2X mechanism of Release 16, which is shown below. "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 auxiliary link communications 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.

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

[0249] In summary, further discussion is needed based on Option B. According to Release 16 auxiliary 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 state variable according to the first received PDCP PDU of MBS data.

[0250] Solution 3: RAN2 needs to agree that, regardless of PTM leg or PTP leg, the UE configures the initial value of the SN part of RX_NEXT and RX_DELIV based on the first received MBS data. Whether the HFN part is notified from the gNB depends on the progress of SA3 and requires further study.

[0251] 8. Simultaneous reception and UE assistance information

[0252] Specifically, in services that require reliability, PTP (branch) is configured in RLC AM, and for the sake of service continuity, it is important to perform lossless switching in the same and / or similar manner as lossless mobility. When agreeing to Recommendation 1, the UE needs to support receiving from both the PTM branch and the PTP branch at the same time. That is, the two branches can be activated simultaneously in the same and / or similar manner as the existing PDCP packet redundancy. This is for the following reasons: 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 of time when dynamically switching PTM / PTP.

[0253] Solution 4: RAN2 needs to agree to support the UE receiving from both the PTM branch and the PTP branch at the same time within a certain period after the dynamic PTM / PTP switching.

[0254] When agreeing to Recommendations 3 and 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 the PTP branch will be used to send the PDCP PDU and when the transmission of the PTP branch can be stopped. To solve this problem, it is proposed that the UE informs the gNB of the successful PTM reception and performs the transmission via the PTP branch. Note that it is not clear whether the UE also needs to include the PDCP SN information in the same message.

[0255] Observation 4: In case of switching from PTP to PTM, the gNB may not know from which PDCP PDU to start maintaining the PTP branch, or from which PDCP PDU the UE should correctly start receiving using the PTM branch.

[0256] In the same and / or similar manner, in case of switching from PTM to PTP, the gNB may not know which PDCP SN the UE correctly received via the PTM leg (especially when the UE's radio status is poor). This means that the gNB may not know which PDCP PDU it needs to use when starting the PTP leg.

[0257] Observation 5: In case of switching from PTM to PTP, the gNB may not know from which PDCP PDU the transmission of the PTP leg needs to be started or which PDCP PDU the UE has correctly received via the PTM leg.

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

[0259] In any of the above cases (i.e., switching from PTP to PTM and 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).

[0260] Solution 5: RAN2 needs to study whether the UE needs to send PDCP control PDU including PDCP SN information during dynamic handover for service continuity. Further study is needed to determine whether PDCP information reporting can be reused.

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

[0262] Recommendation 6: RAN2 needs to discuss whether the same scheme as lossless bearer type change with RRC reconfiguration (i.e. lossless dynamic switching using PDCP Control PDUs as in Recommendation 5) can be applied.

[0263] Reference numerals

[0264] 1: Mobile communication system

[0265] 10: RAN

[0266] 20: CN

[0267] 100: UE

[0268] 110: Receiver

[0269] 120: Transmitter

[0270] 130: Controller

[0271] 200: gNB

[0272] 210: Transmitter

[0273] 220: Receiver

[0274] 230: Controller

[0275] 240: Backhaul communicator.

Claims

1. A communication method used in a mobile communication system for supporting a multicast and broadcast service 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 having a point-to-point PTP branch and a point-to-multipoint PTM branch; as well as The user equipment determines, based on the configuration, whether the multicast radio bearer is an acknowledged mode AM bearer or an unacknowledged mode UM bearer, The user equipment processes the multicast radio bearer as an AM bearer according to the radio link control RLC mode configured for the PTP branch or the PTM branch being AM.

2. The communication method according to claim 1, wherein: In a case where the RLC entity of the PTP branch is configured with AM, or in a case where the RLC entity of the PTM branch is configured with AM, the user equipment processes the multicast radio bearer as an AM multicast radio bearer MRB.

3. The communication method according to claim 1 or 2, wherein: The user equipment processes the multicast radio bearer as a UM bearer according to the RLC mode configured for the PTP branch or the PTM branch being UM.

4. The communication method according to claim 3, wherein: In the case that the RLC entity of the PTP branch is configured with UM, and in the case that the RLC entity of the PTM branch is configured with UM, the user equipment processes the multicast radio bearer as a UM multicast radio bearer MRB.

5. A user equipment used in a mobile communication system for supporting a multicast and broadcast service MBS, the user equipment comprising: a receiver configured to receive, from a base station, a configuration of a multicast radio bearer having a point-to-point PTP branch and a point-to-multipoint PTM branch; as well as a controller configured to determine whether the multicast radio bearer is an acknowledged mode AM bearer or an unacknowledged mode UM bearer based on the configuration, The controller is configured to process the multicast radio bearer as an AM bearer according to a radio link control RLC mode configured for the PTP branch or the PTM branch being AM.

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

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

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

Images