Communication method, user device, processor, program, and mobile communication system

Abstract

A communication method according to a first aspect of the present invention is executed by a user device in a mobile communication system for providing a multicast broadcast service (MBS). The communication method comprises: a step for receiving MBS data from a base station via a multicast radio bearer (MRB); a step for receiving, from the base station, a radio resource control (RRC) reconfiguration message for instructing a bearer type change for the MRB; a step for triggering, in response to the fact that the bearer type change instructed by the RRC reconfiguration message is a change to a MRB type of an acknowledged mode (AM), transmission of a PDCP status report indicating the data reception situation in a PDCP entity associated with the MRB; and a step for transmitting the PDCP status report to the base station.

Description

Technical Field

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

Background Art

[0002] In the 3GPP (3rd Generation Partnership Project) standard, the technical specifications of NR (New Radio), which is the 5th generation (5G) radio access technology, are defined. NR has characteristics such as high speed, large capacity, high reliability, and low latency compared to LTE (Long Term Evolution), which is the 4th generation (4G) radio access technology. In 3GPP, discussions are being held to formulate the technical specifications of the 5G / NR multicast broadcast service (MBS) (see, for example, Non-Patent Document 1).

Prior Art Documents

Non-Patent Documents

[0003]

Non-Patent Document 1

Summary of the Invention

[0004] It is desired that the 5G / NR multicast broadcast service provides a service improved from the 4G / LTE multicast broadcast service.

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

[0006] The communication method according to the first aspect is a communication method executed by a user equipment in a mobile communication system that provides a multicast / broadcast service (MBS), and includes steps of receiving MBS data from a base station via a multicast radio bearer (MRB), receiving a radio resource control (RRC) reconfiguration message for instructing a bearer type change of the MRB from the base station, triggering transmission of a PDCP status report indicating a data reception status in a PDCP entity associated with the MRB in response to the bearer type change instructed by the RRC reconfiguration message being a change to an acknowledged mode (AM) MRB type, and transmitting the PDCP status report to the base station.

[0007] The communication method according to the second aspect is a communication method executed by a user equipment in a mobile communication system that provides a multicast / broadcast service (MBS), and includes steps of receiving MBS data from a base station via a multicast radio bearer (MRB), spontaneously triggering transmission of a PDCP status report indicating a data reception status in a PDCP entity associated with the MRB in response to a transition from an RRC idle state or an RRC inactive state to an RRC connected state and / or occurrence of discard of MBS data packets in an RLC layer, and transmitting the PDCP status report to the base station.

[0008] The communication method according to the third aspect is a communication method executed by a base station in a mobile communication system that provides a multicast broadcast service (MBS), and includes a step of transmitting MBS data to a user equipment via a multicast radio bearer (MRB), and a step of transmitting an RRC reconfiguration message to the user equipment, which is a message instructing a bearer type change of the MRB and includes a first information element instructing re-establishment of a PDCP entity associated with the MRB, and a step of receiving a PDCP status report transmitted from the user equipment based on the first information element. The step of transmitting the RRC reconfiguration message includes a step of transmitting the RRC reconfiguration message further including a second information element instructing to maintain the state of the header compression protocol of the PDCP entity when the first information element is included in the RRC reconfiguration message.

[0009] The user equipment according to the fourth aspect is a user equipment used in a mobile communication system that provides a multicast broadcast service (MBS), and includes a receiving unit that receives MBS data from a base station via a multicast radio bearer (MRB) and receives an RRC reconfiguration message instructing a bearer type change of the MRB from the base station, and a control unit that triggers transmission of a PDCP status report indicating a data reception status in a PDCP entity associated with the MRB in response to the bearer type change instructed by the RRC reconfiguration message being a change to an AM (Acknowledged Mode) MRB type, and a transmitting unit that transmits the PDCP status report to the base station.

Brief Description of the Drawings

[0010]

Figure 1

Figure 2

Figure 3

Figure 4

Figure 5

Figure 6

Figure 7

Figure 8

Figure 9

Figure 10

Figure 11

Figure 12

Figure 13

Figure 14

Figure 15

Figure 16

Figure 17

Figure 18

Figure 19

Figure 20

Figure 21

Figure 22

Embodiments for Carrying Out the Invention

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

[0012] [First Embodiment] (Configuration of Mobile Communication System) FIG. 1 is a diagram showing the configuration of the mobile communication system according to the first embodiment. The mobile communication system 1 complies with the 5th generation system (5GS) of the 3GPP standard. Hereinafter, the 5GS will be described as an example, but the LTE (Long Term Evolution) system may be at least partially applied to the mobile communication system. Also, the 6th generation (6G) system may be at least partially applied to the mobile communication system.

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

[0014] UE100 is a mobile wireless communication device. UE100 can be any device as long as it is used by a user. For example, UE100 can be a mobile phone terminal (including smartphones), a tablet terminal, a notebook PC, a communication module (including a communication card or a chipset), a sensor or a device provided for a sensor, a vehicle or a device provided for a vehicle (Vehicle UE), an aircraft or a device provided for an aircraft (Aerial UE).

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

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

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

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

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

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

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

[0022] FIG. 3 is a diagram showing the configuration of the gNB 200 (base station) according to the first embodiment. The gNB 200 includes a transmission unit 210, a reception unit 220, a control unit 230, and a backhaul communication unit 240. The transmission unit 210 and the reception unit 220 constitute a radio communication unit that performs radio communication with the UE 100. The backhaul communication unit 240 constitutes a network communication unit that communicates with the CN 20.

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

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

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

[0026] The backhaul communication unit 240 is connected to an adjacent base station via the Xn interface, which is an interface between base stations. The backhaul communication unit 240 is connected to the AMF / UPF 300 via the NG interface, which is an interface between the base station and the core network. Note that the gNB 200 is composed of a CU (Central Unit) and a DU (Distributed Unit) (i.e., functionally split), and the two units may be connected by the F1 interface, which is a fronthaul interface.

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

[0028] The radio interface protocol of the user plane has a physical (PHY) layer, a MAC (Medium Access Control) layer, an RLC (Radio Link Control) layer, a PDCP (Packet Data Convergence Protocol) layer, and an SDAP (Service Data Adaptation Protocol) layer.

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

[0030] The MAC layer performs priority control of data, retransmission processing by Hybrid Automatic Repeat reQuest (HARQ), and random access procedures, etc. Between the MAC layer of UE100 and the MAC layer of gNB200, data and control information are transmitted via the transport channel. The MAC layer of gNB200 includes a scheduler. The scheduler determines the uplink and downlink transport formats (transport block size, modulation and coding scheme (MCS)) and the resource blocks allocated to UE100.

[0031] The RLC layer transmits data to the RLC layer on the receiving side by utilizing the functions of the MAC layer and the PHY layer. Between the RLC layer of UE100 and the RLC layer of gNB200, data and control information are transmitted via the logical channel.

[0032] The PDCP layer performs functions such as header compression / expansion and encryption / decryption.

[0033] The SDAP layer performs the mapping between the IP flow, which is the unit for the core network to perform Quality of Service (QoS) control, and the radio bearer, which is the unit for the Access Stratum (AS) to perform QoS control. When the RAN is connected to the EPC, the SDAP may not be required.

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

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

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

[0037] The NAS layer located above the RRC layer performs session management, mobility management, etc. NAS signaling is transmitted between the NAS layer of UE100 and the NAS layer of AMF300A. Note that UE100 has an application layer etc. in addition to the protocol of the radio interface. Also, the layer below the NAS layer is called the AS layer.

[0038] (Overview of MBS) The overview of MBS according to the first embodiment will be described. MBS is a service that enables the NG-RAN10 to transmit data to UE100 in a broadcast or multicast manner, that is, one-to-many (PTM: Point To Multipoint). As use cases (service types) of MBS, public security communication, mission-critical communication, V2X (Vehicle to Everything) communication, IPv4 or IPv6 multicast distribution, IPTV (Internet protocol television), group communication, and software distribution, etc. are assumed.

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

[0040] The multicast service provides services not to all UEs 100 but to a group of UEs 100 that participate in the multicast service (multicast session). The MBS session used for the multicast service is called a multicast session. According to the multicast service, the same content can be provided to a group of UEs 100 in a more radio-efficient way compared to the broadcast service.

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

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

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

[0044] In the 5GC Individual MBS Traffic delivery method, 5GC 20 receives a single copy of the MBS data packet and distributes individual copies of those MBS data packets to individual UEs 100 via a PDU session for each UE 100. Therefore, it is necessary to associate one PDU session for each UE 100 with the multicast session.

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

[0046] From the perspective of the RAN (5G RAN) 10, for the wireless transmission of MBS data in the 5GC common MBS traffic distribution method, two distribution methods, PTP (Point-to-Point) and PTM (Point-to-Multipoint), are possible. PTP means unicast, and PTM means multicast and broadcast.

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

[0048] The PTP distribution method and the PTM distribution method mainly relate to the user plane. As control modes for MBS data distribution, there are two distribution modes, a first distribution mode and a second distribution mode.

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

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

[0051] The setting of MBS reception in the first delivery mode is performed by UE-dedicated signaling. For example, the setting of MBS reception in the first delivery mode is performed by an RRC Reconfiguration message (or an RRC Release message), which is an RRC message transmitted unicast from the gNB200 to the UE100.

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

[0053] Note that the MBS traffic channel is a type of logical channel and may be called MTCH. The MBS traffic channel is mapped to a downlink shared channel (DL-SCH: Down Link - Shared CHannel), which is a type of transport channel.

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

[0055] The setting of MBS reception in the second delivery mode is performed by broadcast signaling. For example, the setting of MBS reception in the second delivery mode is performed by a logical channel, such as a broadcast control channel (BCCH) and / or a multicast control channel (MCCH), which is broadcast from the gNB200 to the UE100. The UE100 can receive the BCCH and MCCH using, for example, 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.

[0056] In the second delivery mode, the UE 100 may receive MBS data in the following three procedures. First, the UE 100 receives MCCH configuration information by means of an SIB (MBS SIB) transmitted on the BCCH from the gNB 200. Second, the UE 100 receives the MCCH from the gNB 200 based on the MCCH configuration information. The MCCH transmits MTCH configuration information. Third, the UE 100 receives the 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 MBS reception settings.

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

[0058] Note that the network can provide different MBS services for each MBS session. The MBS session is identified by at least one of a TMGI (Temporary Mobile Group Identity), a source-specific IP multicast address (composed of a source unicast IP address such as an application function or an application server and an IP multicast address indicating a destination address), a session identifier, and a G-RNTI. At least one of the TMGI, the source-specific IP multicast address, and the session identifier is 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.

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

[0060] One multicast bearer (MRB) is one radio bearer that transmits a multicast session or a broadcast session. That is, there are cases where a multicast session is associated with an MRB and cases where a broadcast session is associated with an MRB.

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

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

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

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

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

[0066] gNB200 transmits MBS data of a certain MBS session to a plurality of UEs 100 (UE100a to UE100c in the example of FIG. 10) by PTM (multicast or broadcast). The RRC state of each UE100 may be any state (RRC connected state, RRC idle state, RRC inactive state). The MBS delivery mode may be the first delivery mode or the second delivery mode.

[0067] gNB200 has, in the PDCP layer, a transmission-side PDCP entity 201 associated with the MBS session (specifically, a transmission-side PDCP entity associated with a multicast radio bearer (MRB) belonging to the MBS session). When starting the transmission of the MBS session, the transmission-side PDCP entity 201 manages PDCP state variables that are updated in response to the transmission of PDCP data PDUs (Protocol Data Units) in the MBS session.

[0068] Each UE 100 has, at the PDCP layer, a receiving-side PDCP entity 101 associated with the MBS session (specifically, a receiving-side PDCP entity associated with the MRB belonging to the MBS session). Each receiving-side PDCP entity 101 (in the example of FIG. 10, receiving-side PDCP entities 101a to 101c) manages a PDCP state variable that is updated in response to the reception of PDCP data PDUs in the MBS session when starting to receive the MBS session.

[0069] Note that the gNB 200 has an RRC entity 202 that transmits and receives RRC signaling with each UE 100. Each UE 100 has an RRC entity 102 (RRC entities 102a to 102c) that transmits and receives RRC signaling with the gNB 200. The RRC entity 102 of the UE 100 controls the receiving-side PDCP entity 101 of the UE 100 based on the RRC signaling received from the RRC entity 202 of the gNB 200.

[0070] As shown in FIG. 11, the PDCP state variable may be a count value (COUNT value) consisting of a hyperframe number (HFN) that is incremented every time the PDCP sequence number makes a full circle, and a PDCP sequence number (PDCP SN). For example, the COUNT value has a bit length of 32 bits, the PDCP SN has a bit length (SN_length) of 12 bits or 18 bits, and the HFN has a bit length obtained by subtracting the bit length of the PDCP SN from the bit length of the COUNT value. The bit length of the PDCP SN may be set by RRC signaling. The PDCP SN bit length may be a default value (a predetermined fixed value). Note that the term "PDCP state variable" is used not only to refer to the COUNT value, but also as a term referring to various variables handled by the PDCP layer (HFN or PDCP SN, or TX_NEXT, RX_NEXT, RX_DELIV, and RX_REORD, etc.).

[0071] FIG. 12 is a diagram showing an example of a PDCP data PDU that constitutes MBS data. As shown in FIG. 12, the PDCP data PDU has a PDCP SN, data, and a MAC-I. The PDCP SN is a sequence number sequentially assigned to the PDCP data PDU. The data corresponds to a PDCP SDU (Service Data Unit). The MAC-I corresponds to a message authentication code. The PDCP data PDU may not have a MAC-I. Thus, although the PDCP data PDU has a PDCP SN, it does not have an HFN. Therefore, each of the gNB 200 and the UE 100 needs to update the HFN according to the transmission and reception of the PDCP data PDU. Specifically, it needs to count up every time the PDCP sequence number wraps around.

[0072] FIG. 13 is a diagram showing an operation of specifying an RCVD_COUNT, which is a COUNT value of a PDCP data PDU received in the UE 100 (reception-side PDCP entity 101). Here, the PDCP SN included in the received PDCP data PDU is referred to as RCVD_SN.

[0073] First, if RCVD_SN < SN(RX_DELIV) - Window_Size then RCVD_HFN = HFN(RX_DELIV) + 1 Here, RX_DELIV is a variable representing the oldest PDCP SDU that is waiting to be received and has not yet been provided to the upper layer. The initial value of RX_DELIV is zero. In PTM reception, the initial value of RX_DELIV may be set using the SN of the first received packet. Window_Size is a constant indicating the size of the reordering window.

[0074] Second, if RCVD_SN ≥ SN(RX_DELIV) + Window_Size then RCVD_HFN = HFN(RX_DELIV) - 1 It is.

[0075] Thirdly, when none of the above conditions are met, RCVD_HFN = HFN(RX_DELIV) It is.

[0076] And RCVD_COUNT = [RCVD_HFN, RCVD_SN] is set to.

[0077] (Overview of PDCP Status Report) Here, a general PDCP status report will be described. The UE 100 transmits a PDCP status report (Status Report) indicating the data reception status in the PDCP layer to the gNB 200. The gNB 200 can identify the missing PDCP packets (PDCP SDUs) based on the PDCP status report from the UE 100 and retransmit the identified PDCP packets to the UE 100.

[0078] FIG. 14 is a diagram showing the operation of the receiving-side PDCP entity 101 of the UE 100 regarding the PDCP status report. Note that FIG. 14 is a citation from the 3GPP technical specification "TS38.323" of the PDCP layer.

[0079] The receiving-side PDCP entity 101 of the UE 100 triggers the transmission of a PDCP status report when any of the following conditions are met for a data radio bearer (DRB: Data Radio Bearer) in the acknowledged mode (AM: Acknowledged Mode) set by the upper layer (RRC layer) to transmit the PDCP status report: · The upper layer requests a PDCP entity re-establishment; · The upper layer requests a PDCP data recovery; · The upper layer requests a uplink data switching; · The upper layer reconfigures the PDCP entity to release DAPS.

[0080] FIG. 15 is a diagram showing the operation of the RRC entity 102 of the UE 100 regarding the PDCP status report. Note that FIG. 15 is a citation from the 3GPP technical specification “TS38.331” of the RRC layer.

[0081] For each DRB identifier (drb-Identity) included in the drb-ToAddModList, which is part of the current UE configuration, the RRC entity 102 of the UE 100 · If reestablishPDCP is set, reestablishes the PDCP entity of that DRB; · If recoverPDCP is set, triggers the PDCP entity of that DRB to perform data recovery.

[0082] Thus, according to the operation of the existing technical specifications for the DRB, the UE 100 triggers the transmission of the PDCP status report in response to being instructed by the RRC signaling from the gNB 200 to perform PDCP reestablishment or PDCP recovery. Note that whether to apply the PDCP status report to the MRB and how to trigger the PDCP status report when applying it to the MRB are not specified in the existing technical specifications.

[0083] FIG. 16 is a diagram showing a configuration example of a PDCP status report. Note that at the head of a PDCP control PDU constituting the PDCP status report, a D / C field indicating that the PDU is a control PDU and a PDU type field indicating that the PDU is a PDCP status report may be provided.

[0084] In configuration example 1 shown in FIG. 16, the PDCP status report includes fields of FMC (First missing COUNT) and a bitmap. In the FMC field, the COUNT value of the first missing PDCP SDU within the reordering window, that is, RX_DELIV, is set. In the bitmap field, bits associated with each PDCP PDU are set, with "1" set when received correctly and "0" set when missing.

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

[0086] (Operation according to the first embodiment) As described above, the RRC entity 202 of gNB 200 can change the bearer type of the MRB by means of RRC signaling transmitted to the RRC entity 102 of UE 100, specifically, by means of an RRC Reconfiguration message. Here, a processing delay occurs from the time UE 100 receives the RRC Reconfiguration message until the RRC reconfiguration process is completed. During this delay time, reception of MBS data becomes impossible, and there is a problem that packet loss of MBS data packets, that is, packet loss, occurs in UE 100.

[0087] As described above, the PDCP layer has a PDCP status report as a mechanism capable of compensating for packet loss. Specifically, UE 100 transmits a PDCP status report indicating the data reception status in the PDCP layer to gNB 200. Based on the PDCP status report from UE 100, gNB 200 can identify the missing PDCP packets and retransmit the identified PDCP packets to UE 100.

[0088] The first embodiment is an embodiment in which UE 100 spontaneously triggers transmission of a PDCP status report, so that packet loss caused by a change in the bearer type of the MRB can be compensated for by the PDCP status report. Specifically, for the PDCP status report, new transmission trigger conditions related to MBS reception are introduced.

[0089] FIG. 17 is a diagram showing the operation of UE 100 according to the first embodiment.

[0090] In step S1, UE 100 receives MBS data from gNB 200 via the MRB. As described above, MRB The bearer types of are of three types: "PTM only", "PTP only", or "both PTM and PTP" (that is, split MRB).

[0091] In step S2, UE100 receives from gNB200 an RRC Reconfiguration message that instructs the bearer type change of the MRB. The RRC Reconfiguration message includes a configuration for performing the bearer type change of the established MRB. For example, the RRC Reconfiguration message may include the bearer identifier of the MRB and bearer type information indicating the target bearer type of the MRB.

[0092] In step S3, UE100 determines whether the bearer type change instructed by the RRC Reconfiguration message received in step S2 is a predetermined bearer type change.

[0093] If the bearer type change is a predetermined bearer type change (step S3: YES), in step S4, UE100 spontaneously triggers the transmission of a PDCP status report indicating the data reception status in the PDCP entity (receiving-side PDCP entity 101) associated with the MRB.

[0094] In step S5, UE100 transmits the PDCP status report to gNB200.

[0095] In this way, when UE100 is instructed by gNB200 to perform a predetermined bearer type change, UE100 spontaneously triggers the transmission of a PDCP status report. Thereby, packet loss caused by the bearer type change of the MRB can be compensated by the PDCP status report.

[0096] Here, "spontaneously trigger" means that UE100 triggers the transmission of a PDCP status report without being explicitly instructed by gNB200 to trigger the transmission of the PDCP status report. For example, UE100 triggers the transmission of a PDCP status report in response to a predetermined bearer type change without being instructed by RRC signaling from gNB200 to perform PDCP re-establishment or PDCP recovery.

[0097] Performing PDCP re-establishment or PDCP recovery for the purpose of triggering the transmission of PDCP status reports can be inefficient. However, according to the first embodiment, it is possible to trigger the transmission of PDCP status reports without PDCP re-establishment or PDCP recovery. Also, by limiting the bearer type change that triggers the transmission of PDCP status reports to a predetermined bearer type change, for example, for an MBS service where packet loss is tolerated, it is possible not to trigger the transmission of PDCP status reports.

[0098] Such an operation is applied to the bearer type change of an established MRB and is not applied when establishing a new MRB. That is, when UE100 establishes a new MRB, it does not perform a spontaneous transmission trigger of PDCP status reports.

[0099] (Example of the First Embodiment) Based on the operation according to the above-described first embodiment, the first to third examples according to the first embodiment will be described.

[0100] (1) First Example In this example, the predetermined bearer type change is a change to an MRB type of PTP (Point-To-Point) only or a change to a split MRB. That is, UE100 triggers the transmission of PDCP status reports only when (only) it is changed to PTP only or a split MRB.

[0101] Here, the bearer type change to PTP only or a split MRB has the following four patterns: 1) PTM only → PTP only; 2) PTM only → split MRB; 3) PTP only → split MRB; 4) Split MRB → PTP only.

[0102] Since there is no uplink path for the MRB with only PTM, even if it attempts to send a PDCP status report, it cannot be sent. Also, it is considered that the MRB with only PTM does not require as high reliability as the MRB with only PTP and the split MRB. Therefore, in this embodiment, the transmission of the PDCP status report is triggered only when it is changed to the MRB with only PTP or the split MRB.

[0103] FIG. 18 is a diagram showing the operation of the receiving-side PDCP entity 101 of the UE 100 according to this embodiment. In FIG. 18, the parts different from FIG. 14 are underlined. However, the "DRB" in FIG. 18 may be read as "MRB".

[0104] For the UE 100, statusReportRequired is set in the PDCP entity of the MRB (receiving-side PDCP entity 101), and when the upper layer reconfigures the PDCP entity to change the bearer type to a PTP-only MRB or a Split MRB, the PDCP status report is triggered.

[0105] (2) Second Embodiment In this embodiment, the predetermined bearer type change is a change to the MRB type of AM (Acknowledged Mode). That is, the UE 100 triggers the transmission of the PDCP status report only when it is changed to the AM MRB.

[0106] The MRB with only PTM is considered to be treated as an MRB of UM (Unacknowledged Mode). Also, since PTM (especially PTM only) has better radio resource utilization efficiency than PTP, it is considered that the gNB 200 has the motivation to make the UE 100 use PTM (-only) as much as possible.

[0107] In this case, it is considered that the gNB 200 makes a distinction such that, for example, when the radio condition is good, it uses PTM (-only) (i.e., UM MRB), and when the radio condition deteriorates, it uses only PTP or split MRB (i.e., AM MRB) by changing the bearer type. Note that the radio condition can be determined, for example, based on existing measurement reports.

[0108] Here, for services that require a certain level of high reliability, the following methods can be used as packet loss compensation when changing the bearer type: · Change from AM to UM; In AM (PTP), transmit in advance the packets that are earlier than the SN of UM (PTM). · Change from UM to AM; Transmit later in AM (PTP) the packets that were lost in UM (PTM). Here, a PDCP status report is required.

[0109] Therefore, in this embodiment, when the UE 100 is changed to the AM MRB, it performs a spontaneous transmission trigger of the PDCP status report. The change to the AM MRB (MRB reconfiguration) has the following two patterns: 1) UM MRB → AM MRB; 2) AM MRB → AM MRB; for example, in the case of changing from split MRB to only PTP MRB.

[0110] FIG. 19 is a diagram showing the operation of the receiving - side PDCP entity 101 of the UE 100 according to this embodiment. In FIG. 19, the parts different from FIG. 14 are underlined. However, the "DRB" in FIG. 19 may be read as "MRB".

[0111] The UE 100 has statusReportRequired set for the PDCP entity of the MRB (the receiving-side PDCP entity 101), and when the upper layer reconfigures the PDCP entity to change the bearer type to an AM MRB, it triggers a PDCP status report.

[0112] (3) Third Embodiment In this embodiment, the predetermined bearer type change is a change from an MRB type for PTM only to another MRB type. That is, the UE 100 triggers a PDCP status report only when it is changed from PTM only to other than PTM only.

[0113] The split MRB can perform packet loss compensation using the PTP leg, but when performing packet loss compensation for an MRB for PTM only, a bearer type change is always required. Therefore, it is set to trigger a PDCP status report only when it is changed from PTM only to other than PTM only.

[0114] FIG. 20 is a diagram showing the operation of the receiving-side PDCP entity 101 of the UE 100 according to this embodiment. In FIG. 20, the parts different from FIG. 14 are underlined. However, "DRB" in FIG. 20 may be read as "MRB".

[0115] The UE 100 has statusReportRequired set for the PDCP entity of the MRB (the receiving-side PDCP entity 101), and when the upper layer reconfigures the PDCP entity to change the bearer type from PTP-only to other type, it triggers a PDCP status report.

[0116] [Second Embodiment] The second embodiment will be mainly described with differences from the above-described first embodiment.

[0117] In the second embodiment, a scenario is mainly assumed in which the UE 100 that performs MBS reception (PTM reception) in the RRC idle state or the RRC inactive state transitions to the RRC connected state by a random access procedure. In such a scenario, during the execution of the random access procedure, the UE 100 cannot perform MBS reception, and packet loss of MBS data may occur. The second embodiment is an embodiment that can compensate for such packet loss.

[0118] For example, when the UE 100 transitions to the RRC connected state, it spontaneously triggers the transmission of a PDCP status report. The RRC entity 102 of the UE 100 notifies the receiving-side PDCP entity 101 that it has transitioned to the RRC connected state, and the receiving-side PDCP entity 101 may spontaneously trigger the transmission of a PDCP status report in response to the notification. However, packet loss may not occur even when the random access procedure is executed. Therefore, the UE 100 may spontaneously trigger a PDCP status report when packet discard occurs in the RLC. Specifically, the receiving-side PDCP entity 101 of the UE 100 may spontaneously trigger a PDCP status report when notified of packet discard from the RLC layer.

[0119] FIG. 21 is a diagram showing the operation of the UE 100 according to the second embodiment.

[0120] In step S11, the UE 100 in the RRC idle state or the RRC inactive state receives MBS data from the gNB 200 via the MRB.

[0121] In step S12, the UE 100 determines whether at least one of the conditions that the UE 100 has transitioned from the RRC idle state or the RRC inactive state to the RRC connected state and that packet discard of MBS data packets has occurred in the RLC layer is satisfied.

[0122] When at least one of the conditions is satisfied (step S12: YES), in step S13, the UE 100 spontaneously triggers the transmission of a PDCP status report indicating the data reception status in the PDCP entity associated with the MRB.

[0123] In step S14, the UE 100 transmits the PDCP status report to the gNB 200.

[0124] [Third Embodiment] Regarding the third embodiment, differences from the above-described first and second embodiments will be mainly described.

[0125] In the third embodiment, the point that the gNB 200 instructs the UE 100 to change the bearer type for the MRB is the same as in the first and second embodiments. However, when giving the instruction, the gNB 200 causes the UE 100 to trigger a PDCP status report. Specifically, the gNB 200 includes, in an RRC message (RRC reconfiguration message) for instructing the bearer type change of the MRB, a first information element (reestablishPDCP) for instructing the reestablishment of the PDCP entity (receiving-side PDCP entity 101) associated with the MRB.

[0126] However, when instructing such RRC re - establishment, the header compression protocol in the PDCP entity (the receiving - side PDCP entity 101), specifically, the operation of RoHC (Robust Header Compression) is reset, and the RoHC context is also reset. The RoHC context includes fixed values in the header and information for predicting values in the header, and is the information necessary for the UE100 to restore the compressed header. When the RoHC context is also reset, after the bearer type change, it is necessary to transmit and receive uncompressed complete headers, resulting in the problem of increased overhead.

[0127] Therefore, in the third embodiment, when the gNB200 includes the first information element (reestablishPDCP) in the RRC re - configuration message instructing the bearer type change of the MRB, the gNB200 includes the second information element (drb - ContinueROHC) instructing to maintain the state of the header compression protocol (for example, the RoHC context) of the PDCP entity (the receiving - side PDCP entity 101) of the UE100 in the RRC re - configuration message. Thereby, since the state of the header compression protocol (for example, the RoHC context) of the PDCP entity (the receiving - side PDCP entity 101) of the UE100 is maintained, it is possible to transmit and receive compressed headers even after the bearer type change.

[0128] FIG. 22 is a diagram showing the operation of the mobile communication system 1 according to the third embodiment.

[0129] In step S101, the UE100 receives MBS data from the gNB200 via the MRB.

[0130] In step S102, gNB200 determines a bearer type change for the MRB. Specifically, gNB200 determines a change among three types: PTP only, PTM only, and split MRB (PTP leg and PTM leg). For example, gNB200 makes the determination in step S102 according to a radio quality report from UE100 and / or the radio resource status of gNB200, etc.

[0131] In step S103, gNB200 sends an RRC reconfiguration message for bearer type change to UE100. The RRC reconfiguration message includes a setting for performing a bearer type change of the established MRB. For example, the RRC reconfiguration message may include the bearer identifier of the MRB and bearer type information indicating the destination bearer type of the MRB. Here, gNB200 sets "reestablishPDCP“true”" and "drb - ContinueROHC“true”" in the RRC reconfiguration message in association with the MRB identifier.

[0132] In step S104, UE100 that has received the RRC reconfiguration message re - establishes the PDCP entity (the receiving - side PDCP entity 101) according to "reestablishPDCP“true”" included in the RRC reconfiguration message, and triggers the transmission of a PDCP status report in response to the re - establishment (see the PDCP operation in FIG. 14). Here, UE100 continues the RoHC process according to "reestablishPDCP“true”" included in the RRC reconfiguration message (specifically, continues to use the RoHC context used until just before and maintains the RoHC state).

[0133] In step S105, UE100 sends a PDCP status report to gNB200. gNB200 receives the PDCP status report.

[0134] [Other Embodiments] Each of the above operation flows can be implemented not only separately and independently, but also by combining two or more operation flows. For example, some steps of one operation flow may be added to another operation flow, or some steps of one operation flow may be replaced with some steps of another operation flow.

[0135] In the above embodiments and examples, an example where the base station is an NR base station (gNB) has been described, but the base station may be an LTE base station (eNB) or a 6G base station. Further, the base station may be a relay node such as an IAB (Integrated Access and Backhaul) node. The base station may be the DU of the IAB node. Also, the user equipment may be the MT (Mobile Termination) of the IAB node.

[0136] A program may be provided to cause a computer to execute each process performed by UE100 or gNB200. The program may be recorded on a computer-readable medium. By using a computer-readable medium, it is possible to install the program on a computer. Here, the computer-readable medium on which the program is recorded may be a non-transitory recording medium. The non-transitory recording medium is not particularly limited, and may be, for example, a recording medium such as a CD-ROM or a DVD-ROM. Also, a circuit that executes each process performed by UE100 or gNB200 may be integrated, and at least a part of UE100 or gNB200 may be configured as a semiconductor integrated circuit (chip set, SoC: System on a chip).

[0137] As described above, the embodiments have been described in detail with reference to the drawings, but the specific configuration is not limited to the above, and various design changes and the like can be made without departing from the gist.

[0138] As used in this disclosure, the recitations “based on” and “depending on” do not mean “only based on” or “only depending on” unless otherwise specified. The recitation “based on” means both “only based on” and “at least partially based on”. Similarly, the recitation “depending on” means both “only depending on” and “at least partially depending on”. Also, “obtain / acquire” may mean obtaining information from stored information, obtaining information from information received from other nodes, or obtaining the information by generating the information. The terms “include”, “comprise”, and variations thereof do not mean only including the recited items, and may mean including only the recited items or including further items in addition to the recited items. Also, the term “or” as used in this disclosure is not intended to be exclusive. Further, any reference to elements using designations such as “first”, “second”, etc. in this disclosure does not generally limit the quantity or order of those elements. These designations may be used in this specification as a convenient way to distinguish between two or more elements. Thus, a reference to first and second elements does not mean that only two elements can be employed there or that the first element must precede the second element in any form. In this disclosure, for example, when articles are added by translation, such as a, an, and the in English, these articles are assumed to include a plurality unless it is shown otherwise from the context.

[0139] This application claims priority to U.S. Provisional Application No. 63 / 255,579, filed Oct. 14, 2021, the entire content of which is incorporated herein by reference.

[0140] (Appendix) 1. Introduction In RAN2#115e, the working items of the NR multicast and broadcast service (MBS) reached the following agreement on the continuity of the multicast service.

[0141] In RRC signaling, one MRB can be configured with PTM only, PTP only, or both PTM and PTP. Any of PTM, PTM+PTP, or PTP only can be changed by RRC signaling.

[0142] In the RRC signal, support DL with only UM RLC configuration for PTM, DL and UL AM RLC configurations for PTP, and DL with only UM RLC configuration for PTP. Further consideration is required for supporting DL and UL UM RLC configurations for PTP.

[0143] Further consideration will be given to whether PDCP SR can occur with the change of bearer type in the RRC signal and how PDCP SR occurs if it occurs.

[0144] Deactivation / activation of PTM beyond RRC reconfiguration in accordance with the above first agreement is not supported.

[0145] In the set of PTM PDCP state variables being configured, the SN part of the COUNT value of these variables is set according to the SN of the first packet received (by the UE) and the HFN indicated by the gNB as necessary.

[0146] Initialize the PTM RLC entity of the MRB configuration and set the values of RX_Next_Highest and RX_Next_Reassembly according to the SN of the first received packet including the SN.

[0147] With the MRB configuration, the 0RLC state variable of the PTP RLC reception window can be set to the initial value (0).

[0148] In this appendix, the remaining issues regarding the service continuity of multicast are discussed.

[0149] 2. Discussion 2.1 PDCP Status Report at Bearer Type Change In RAN2#115e, the following open issues were agreed upon.

[0150] In the RRC signal, support DL only for the UM RLC configuration of PTM, DL and UL AM RLC configurations of PTP, and DL only for the UM RLC configuration of PTP. Further study is required for supporting the DL and UL UM RLC configurations of PTP.

[0151] Further study will be conducted on the possibility of generating PDCP SR associated with the bearer type change of the RRC signal and the method of generating PDCP SR when it occurs.

[0152] According to the current PDCP specification, the PDCP status report is mainly triggered by RRC at the occurrence of the following events for AM DRB (and in some cases UM DRB).

[0153] In the case of an AM DRB configured by the upper layer to send a PDCP status report on the uplink (statusReportRequired in TS 38.331), the receiving PDCP entity needs to trigger a PDCP status report in the following cases. - The upper layer requests the re-establishment of the PDCP entity. - The upper layer requests PDCP data recovery. - The upper layer requests uplink data switching. - The upper layer reconfigures the PDCP entity to release DAPS, and daps-SourceRelease is configured in TS 38.331.

[0154] In the case of a UM DRB configured by the upper layer to send PDCP status reports (statusReportRequired in TS 38.331) on the uplink, the receiving PDCP entity shall trigger a PDCP status report in the following cases. The upper layer requests an uplink data handover.

[0155] In MBS, MRBs for PTM only are configured only with RLC UM, while MRBs for PTP only and the PTP leg of split MRBs are configured with RLC UM or RLC AM. These are referred to as UM MRBs and AM MRBs respectively.

[0156] According to the current RRC specification, the UE's performance requirement regarding the processing delay of RRC reconfiguration is defined as 10 ms. Therefore, the UE may miss MBS transmissions during RRC reconfiguration for bearer type changes, and the missing packets need to be compensated after the bearer type change. In this sense, PDCP status reports should be supported to meet a higher reliability requirement than at least that required by certain MBS services.

[0157] Also, it is worth considering in which cases PDCP status reports are necessary. In the case of AM MRBs, since "high QoS" MBS services are generally assumed, it is obvious that reliability is required during bearer type changes. When changing the bearer type between AM MRBs, it includes the case of changing from a UM MRB to an AM MRB.

[0158] Proposal 1: RAN2 should agree that PDCP status reports are supported for at least lossless bearer type changes between AM MRBs and from UM MRBs to AM MRBs.

[0159] Generally, it is considered that the UM MRB does not require reliability, i.e., lossless, when changing the bearer type. However, whether to use the UM MRB for "high QoS" MBS services can actually be left to the implementation of the NW. For UEs with good radio conditions, only the PTM MRB is used, and when the radio conditions deteriorate beyond a certain level, the NW can efficiently utilize resources by reconfiguring to a PTP-only MRB (or split MRB). Considering that in the current specification, in some cases, the UM DRB is recognized to trigger a PDCP status report, it is easily apparent that the NW can set whether to require a PDCP status report for the UM MRB. In this case, for the PTP-only MRB and the PTP leg of the split MRB, it is necessary to set DL / UL bidirectional UM, i.e., the DL RLC entity for receiving MBS data and the UL RLC entity for sending PDCP status reports.

[0160] Proposal 2: RAN2 should agree that whether to use a PDCP status report when changing the bearer type of the UM MRB depends on the NW implementation. For this purpose, a specification that can configure PTP with DL / UL bidirectional RLC UM is required.

[0161] 2.2. PDCP / RLC State Variables of PTM 2.2.1. Initial Values At RAN2#115e, the following description was agreed upon.

[0162] Regarding the set of PTM PDCP state variables being configured, the SN part of the COUNT value of these variables is set according to the SN of the first received packet (by the UE) and the HFN indicated by the gNB as necessary.

[0163] Initialize the PTM RLC entity of the MRB configuration and set the values of RX_Next_Highest and RX_Next_Reassembly according to the SN of the first received packet including the SN.

[0164] The term "according to" in the two contracts intends the following three options.

[0165] Option 1: The initial value of each state variable is simply set to the SN of the first received packet.

[0166] Option 2: The Rel-16 V2X solution is reused.

[0167] For PDCP "RX_NEXT", "The initial value of the SN part of RX_NEXT is (x + 1) modulo (2 [sl-PDCP-SN-Size] ), where x is the SN of the first received PDCP data PDU". For PDCP "RX_DELIV", "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". For RLC UM "RX_Next_Reassembly", "It is initialized to the SN of the first received UMD PDU containing the SN". For RLC UM "RX_Next_Highest", "It is initialized to the SN of the first received UMD PDU containing the SN".

[0168] Option 3: A new mechanism for RLC UM is introduced.

[0169] For PDCP state variables, either Option 1 or Option 2 can be applied. For RLC UM "RX_Next_Reassembly", it is initialized to a value before "RX_Next_Highest". For RLC UM "RX_Next_Highest", similar to Option 2 above, "It is initialized to the SN of the first received UMD PDU containing the SN".

[0170] In the PDCP state variables, in the case of Option 2, the packet to be received next, RX_NEXT, is set to ([Sequence Number (SN) of the first received packet] + 1). RX_DELIV, which is the first packet not delivered to the upper layer, is set to ([Sequence Number (SN) of the first received packet] - [1 / 4 of the SN length]). This means that even if old packets are received after the first received packet, rearrangement can be performed. Therefore, Option 2 is considered to be more reliable than Option 1.

[0171] Proposal 3: Similar to Rel-16 V2X, RAN2 should agree with PDCP that the initial value of RX_NEXT is ([Sequence Number (SN) of the first received packet] + 1) modulo (2^[PDCP SN length]).

[0172] Proposal 4: Similar to Rel-16 V2X, RAN2 should agree with PDCP that the initial value of RX_DELIV is {[Sequence Number (SN) of the first received packet] - 2^([PDCP SN length] - 2)} modulo (2^[PDCP SN length]).

[0173] Regarding the RLC state variables, Option 1 and Option 2 are exactly the same. Also, Option 2 and Option 3 are the same in terms of RX_Next_Highest. Therefore, RAN2 only needs to confirm that there is no other solution for the initial value of RX_Next_Highest.

[0174] Proposal 5: Similar to Rel-16 V2X, RAN2 should agree with RLC UM that the initial value of RX_Next_Highest is the Sequence Number (SN) of the first received packet.

[0175] Regarding RX_Next_Reassembly, Option 2 is different from Option 3. The advantage of Option 3 is similar to that of Option 2 of the PDCP state variable. That is, it is possible to avoid discarding old packets received after the first received packet. It has also been pointed out that this problem occurs only when RLC segmentation is performed, but it is always good if packet loss can be minimized.

[0176] Proposal 6: RAN2 should discuss for RLC UM whether the initial value of RX_Next_Reassembly is the SN of the first received packet (the same as Rel-16 V2X) or the previous value of RX_Next_Highest.

[0177] 2.2.2. HFN Provisioning 1) Whether SA3 uses HFN for security, 2) Whether PDCP status reports are supported because COUNT has an HFN part as described in RAN2#115e, etc. PDCP status reports have already been agreed to be supported in the case of handover and are also likely to be supported in the case of bearer type change as in Section 2.1. Therefore, as agreed by RAN2, HFN needs to be indicated by the gNB.

[0178] Furthermore, it should be discussed how the gNB provides the HFN to the UE. The following options can be considered as methods for providing the HFN. Alt.1: RRC Reconfiguration Alt.2: PDCP Control PDU Alt.3: MCCH Alt.4: SIB Alt.5: Header of PDCP Data PDU

[0179] Alternative 1 is considered simple because the gNB needs to configure the MRB for multicast for the UE by means of RRC reconfiguration, that is, since the HFN is set together with the MRB. However, RRC reconfiguration is dedicated signaling for a specific UE and is basically only used in Delivery mode 1 (DM1), and has the drawback that the processing is slightly heavier compared to Alt.2. Also, there is a certain timing gap between the reception of the RRC reconfiguration and the first received packet, which may cause HFN asynchrony. Furthermore, additional information may be required to indicate to which MRB the HFN is applied.

[0180] Alternative 2 is considered to be lighter and more efficient signaling because the gNB can indicate the HFN on PTM. Since the PDCP entity is associated with the MRB, the mapping between the additional information HFN and the MRB is not required. That is, the PDCP entity that receives this PDCP control PDU may simply apply the HFN as the initial value. This is generally used in both Delivery mode 1 and Delivery mode 2 (DM2). Also, since the same PDCP entity processes these PDCP PDUs, it may be possible to minimize the timing gap between the PDCP control PDU and the first received packet. However, there is concern that the PDCP control PDU is not security protected.

[0181] Alternative 3 is another possibility, but the MCCH is only applicable to Delivery mode 2, and it is not considered preferable to impose the additional burden of acquiring the MCCH on UEs that receive Delivery mode 1. Also, there may be a certain timing gap between the reception of the MCCH and the first received packet. Furthermore, similar to Alt.1, additional information such as the mapping between the HFN and the MRB may be required, so it is not preferable to impose the acquisition of the MCCH.

[0182] Alt.4 is considered as a normal provisioning method. The SIB is basically applicable to both the first delivery mode 1 and the second delivery mode, but it is still unclear whether the UE connected for multicast reception is obliged to monitor the SIB. Concerns include that, similar to Alt.2, the SIB is not security protected, that, similar to Alt.1, additional information such as the mapping between HFN and MRB occurs, and that a certain timing gap occurs between SIB reception and the first received packet. Also, when applying on-demand SI, the UE needs to send an on-demand SI request message before obtaining the SIB, which may cause a delay in HFN initialization.

[0183] Alt.5 has advantages similar to Alt.2. That is, it can be delivered in the PTM mode, no additional information is required, and it is a common solution for both the first delivery mode and the second delivery mode. Since the first packet received by Alt.5 transmits the HFN together, the most important advantage is, theoretically, the timing gap. However, assuming that the HFN is included in the header of the first received packet, it is questionable how the gNB knows the first received packet of the UE considering that the packet has started to be transmitted to other UEs via PTM. Otherwise, the gNB always needs to include the HFN in each data packet. The concern is that, similar to Alt.2, the PDCP header is not security protected. Since HFN provisioning is regarded as C-plane signaling similar to other alternatives including Alt.2, it is a bit strange from the perspective of concepts / principles. On the other hand, Alt.5 uses U-plane data.

[0184] Viewed from another angle, it can be seen that there are differences in the HFN provision methods between the first delivery mode (DM1) and the second delivery mode (DM2). Generally, DM1 (or multicast) is safer than DM2 (or broadcast). This is because the configuration is provided by dedicated signaling (also, session participation procedures are available in NAS). In this sense, HFN also needs to be provided securely in DM1. In this case, the simplest solution is Alt.1, but it is not suitable for realizing the commonality between DM1 and DM2. Alt.2 is assumed to be able to ensure a certain degree of security compared to Alt.3, Alt.4, and Alt.5 when the PDCP control PDU is transmitted with the C-RNTI. On the other hand, DM2 should not obligate the UE to transition to CONNECTED and is only aimed at obtaining the HFN. To support DM2, the HFN is provided periodically in a broadcast manner (i.e., using the G-RNTI, MCCH-RNTI, or SI-RNTI).

[0185] As described above, (as also summarized in the following table), it can be said that it is slightly preferable for the HFN to be provided via the PDCP control PDU (i.e., Alt.2) because a balance between performance and security is achieved and it is a solution common to both delivery modes (i.e., DM1 and DM2).

[0186] Proposal 7: RAN2 should agree that the initial value of the HFN is provided via the PDCP control PDU.

[0187] Proposal 8: If Proposal 7 is agreeable, RAN2 should further agree that the PDCP control PDU (for HFN provisioning) can be transmitted together with the G-RNTI and C-RNTI.

[0188]

Table 1

[0189] 2.2.3. Data Reception before HFN Initialization The UE may receive data before receiving the HFN. This is because the reception timing of the HFN and the first received packet may be different due to out-of-order delivery (e.g., retransmission in a bad radio condition and / or retransmission during handover, etc.). And / or it depends on which option in Section 2.2.2 is selected. Furthermore, since the PTM transmission has already started sending to other UEs, the UE can receive data as soon as it sets the MRB.

[0190] Place See 1: The UE may receive MBS data via PTM before HFN initialization.

[0191] In the current PDCP specification, when the RRC requests the establishment, re-establishment, or suspension of a PDCP entity, RX_NEXT and RX_DELIV are (re)set to their initial values. Naturally, the initialization of the COUNT value is performed before data reception. Therefore, from the perspective of PDCP, even if the lower layer has completed the preparation for data reception, the data may not be received. That is, even if the RLC layer sends an RLC SDU (PDCP PDU) to the PDCP layer, the data may not be received. Even if PDCP accepts these PDCP PDUs, since the HFN is still non-aulistic, these PDUs are discarded due to a failure in integrity verification.

[0192] Place See 2: Before the initialization of the HFN, according to the current specification, PDCP PDUs from the lower layer may not be accepted or may be discarded at the PDCP layer.

[0193] Therefore, all (part of) the extensions of the initialization of the SN state variables described in Section 2.2.1 and, as described in Section 2.2.2, aim to minimize packet loss. One simple way is for the PDCP to temporarily buffer these PDUs before PDCP processing and start processing these PDUs after the initialization of the HFN.

[0194] Proposal 9: RAN2 should discuss how the UE processes the data packets received before the initialization of the HFN.

[0195] 2.2.4. Request for HFN Provisioning Another possible issue is whether the UE is permitted to query the gNB about the current HFN. Especially in the case of PTM-only MRBs, for example, due to coverage holes or interference, if the UE cannot receive packets for a certain period, the HFN may become asynchronous. Another case is when the HFN is provided only at the activation of the MBS session (as briefly described in Section 2.2.2), and the UE needs the HFN when it later joins an already activated MBS session.

[0196] Therefore, if the UE becomes aware of the need for HFN provisioning, it is convenient to be able to request the gNB to provide the current HFN. For example, further consideration is needed on how to send the request via RRC signaling or PDCP control PDUs. Under the same conditions, the UE may not receive the next packet outside the reception window. In this case, the UE can reset all state variables to their initial values.

[0197] Proposal 10: RAN2 should discuss whether the UE is permitted to request the gNB to provide the current HFN of the MBS session.

[0198] RAN2 should discuss whether the UE can reset the state variable when it fails to receive the MBS session for a certain period of time.

[0199] 2.3. Lossless Mobility Operation 「 RAN2 aims to support lossless handover for MBS-MBS mobility for services that require it (the details of the scenario are undetermined, but at least PTP-PTP), and "from the UE side, PDCP status reports may also be supported". These agreements mean that when the MRB is composed of PTP only, it is a mechanism very similar to the existing unicast handover. , this RAN2 aims to support lossless handover for MBS-MBS mobility for services that require it (the details of the scenario are undetermined, but at least PTP-PTP), and "from the UE side, PDCP status reports may also be supported". These agreements mean that when the MRB is composed of PTP only, it is a mechanism very similar to the existing unicast handover.

[0200] Finding 3: To support lossless handover, it is possible to reuse the existing handover mechanism for unicast for MRBs composed of PTP only.

[0201] Therefore, for handovers involving PTM (-leg), that is, for MRBs composed of PTM only and split MRBs including PTP legs and PTM legs, it is necessary to consider them.

[0202] A split MRB can be regarded as a PTP-only MRB when not using the PTM leg. Therefore, based on the conventional unicast handover, lossless handover can be easily supported. The basic procedure for a split MRB is considered as follows.

[0203] Step 1: The PTP leg of the split MRB is used by lossless dynamic switching in the source cell as needed. Step 2: The UE performs a lossless handover, such as a PTP-PTP handover (or like a unicast handover). Step 3: The PTM leg of the split MRB is used by lossless dynamic switching in the target cell as needed.

[0204] At this time, the lossless dynamic switching ensured by the NW implementation will play an important role.

[0205] Finding 4: For the lossless handover of the split MRB, lossless dynamic PTM / PTP switching is essential.

[0206] For MRBs with only PTM, very similar procedures can be applied as follows.

[0207] Step 1: In the source cell, reconfigure the MRB for PTM to an MRB for PTP (or a split MRB) by changing the lossless bearer type. Step 2: The UE performs a lossless handover as a PTP-PTP handover (or like a unicast handover). Step 3: By changing the lossless bearer type, if necessary, in the target cell, the MRB with only PTP (or split MRB) can be reconfigured to an MRB with only PTM.

[0208] In this case, the change of the lossless bearer type described in Section 2.1 is also important for the lossless handover.

[0209] Finding 5: For the lossless handover of an MRB with only PTM, changing the lossless bearer type is essential.

[0210] From the above, the key points of the basic procedure for lossless handover are to use the PTP leg or reconfigure the MRB with only PTM (= Step 1), and the handover execution is the same as the existing unicast handover without any extension.

[0211] Proposal 12: RAN2 should agree that the basic lossless handover of MRB must always include PTP (-leg). That is, either the PTP leg of the split MRB is used, or the PTM-only MRB is reconfigured into a PTP-only MRB (or split MRB) before performing the handover.

[0212] Proposal 13: RAN2 should agree that the execution of the MRB handover is the same as the unicast handover, that is, no extension is required for the basic lossless handover.

[0213] Next, the most interesting advanced procedure is the direct PTM-PTM handover. That is, a UE receiving MBS via PTM (-leg) performs a lossless handover. This can reduce the signaling overhead and complexity of the above basic handover procedure. That is, steps 1 and 3 can be skipped. Furthermore, such a direct PTM-PTM lossless handover is expected, especially for split MRBs with PTP legs set. That is, it is used for services that require higher reliability. However, it has already passed the midpoint of the Release 17 time frame, and the WID only states that it "specifies the support of basic mobility with service continuity". Therefore, the advanced lossless handover needs to be postponed until a future release.

[0214] Finding 6: The advanced lossless handover of a UE receiving MBS service via PTM (-leg), that is, the "direct PTM-PTM handover", is considered useful for specific services, but may need to be postponed to a future release considering the remaining time of the Rel17 time frame.

[0215] 2.4. Multicast MBS Interest Indication RAN2 currently assumes that MBS Interest Indication is supported in broadcast sessions but not in multicast sessions. RAN2 #115e reached an agreement on the basic content of MBS Interest Indication as follows.

[0216] In the case of CONNECTED The UE reports the following MBS Interest information (as LTE SC-PTM). MBS frequency list The priority between receiving all the listed MBMS frequencies and receiving any unicast bearer TMGI list If reporting of MBS frequencies is permitted, the MBS frequencies reported by the UE are sorted in descending order of interest, similar to LTE SC-PTM.

[0217] In the case of a multicast session, since there is an upper-layer session participation procedure in the multicast session, it is generally understood that the core network notifies the gNB of the UE's interests. This applies to MBS services that the UE is interested in. Also, the gNB may know the MBS frequencies and the cells that provide the MBS services the UE is interested in. However, since the priority between MBS reception and unicast is purely AS-related information, it may not be provided by the core network.

[0218] Finding 7: In a multicast session, the core network provides the gNB with the MBS services that are of interest to the UE, and the gNB may know the MBS frequencies / cells. However, the core network and the gNB may not know the UE's AS priority between MBS and unicast.

[0219] Priority information is considered to be useful for the gNB as well, such as in scheduling and handover decisions, similar to LTE eMBMS, and is also related to service continuity. Therefore, the UE needs to notify the gNB of its priority information for multicast sessions as well. In this sense, RAN2 should agree that MBS Interest Indication should also be supported for multicast services / delivery mode 1.

[0220] Proposal 14: RAN2 should agree that MBS Interest Indication is also supported in multicast sessions / delivery mode 1, at least for the UE to notify the gNB of the priority between MBS reception and unicast reception.

Explanation of symbols

[0221] 1: Mobile communication system 10: RAN 20: CN 100: UE 101: Receiving side PDCP entity 110: Receiver 120: Transmitter 130: Control unit 200: gNB 201: Transmitting side PDCP entity 210: Transmitter 220: Receiver 230: Control unit 240: Backhaul communication unit

Claims

1. A communication method in a mobile communication system that provides a multicast broadcast service (MBS), comprising: a user equipment receiving MBS data from a network node via a multicast radio bearer (MRB); the user equipment receiving, from the network node, a radio resource control (RRC) reconfiguration message for instructing a bearer type change of the MRB; in response to the bearer type change instructed by the RRC reconfiguration message being a change from a specific MRB type to an acknowledged mode (AM) MRB type, triggering transmission of a PDCP status report indicating a data reception status in a PDCP entity associated with the MRB; the user equipment transmitting the PDCP status report to the network node. A communication method.

2. The change from the specific MRB type to the AM MRB type is a change from an unacknowledged mode (UM) MRB type to the AM MRB type, or a change from an AM MRB type to an AM MRB type with a different bearer configuration. The communication method according to Claim 1.

3. The user equipment further comprises spontaneously triggering transmission of a PDCP status report indicating a data reception status in a PDCP entity associated with the MRB in response to the user equipment transitioning from an RRC idle state or an RRC inactive state to an RRC connected state and / or occurrence of discard of MBS data packets in an RLC layer. The communication method according to Claim 1.

4. The network node transmits, to the user equipment, an RRC reconfiguration message that is a message for instructing a bearer type change of the MRB and includes a first information element for instructing re-establishment of a PDCP entity associated with the MRB; the network node further comprises receiving a PDCP status report transmitted from the user equipment based on the first information element. Sending the RRC reconfiguration message includes sending the RRC reconfiguration message that further includes a second information element for instructing to maintain the state of the header compression protocol of the PDCP entity when including the first information element in the RRC reconfiguration message. The communication method according to claim 1.

5. A user equipment used in a mobile communication system that provides a multicast / broadcast service (MBS), a receiving unit that receives MBS data from a network node via a multicast radio bearer (MRB) and receives an RRC reconfiguration message for instructing a bearer type change of the MRB from the network node; a control unit that triggers transmission of a PDCP status report indicating a data reception status in a PDCP entity associated with the MRB in response to the bearer type change instructed by the RRC reconfiguration message being a change from a specific MRB type to an AM (Acknowledged Mode) MRB type; and a transmitting unit that transmits the PDCP status report to the network node. User equipment.

6. A processor used in a user equipment and executing the communication method according to claim 1

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

8. A mobile communication system having the user equipment according to claim 5 and a network node ​

Images