Communication method, user equipment, network node, chipset and program

Abstract

The communication method according to the first aspect of the present application is used in a mobile communication system supporting a multicast and broadcast service (MBS), and has the steps of a user equipment which has started receiving an MBS session from a base station managing a first packet data convergence protocol (PDCP) variable updated according to reception of a PDCP packet during the MBS session in a PDCP layer, and the user equipment performing control to synchronize the first PDCP variable with a second PDCP variable managed by the base station, in response to determining that reception of the MBS session has been interrupted for a predetermined period of time, synchronizing the first PDCP variable with the second PDCP variable.

Description

TECHNICAL FIELD

[0001] The present disclosure relates to a communication method, a user equipment, and a base station used in a mobile communication system. BACKGROUND

[0002] In the Third Generation Partnership Project (3GPP) standards, a technical specification of New Radio (NR) as a fifth generation (5G) radio access technology has been defined. NR has features such as high speed, large capacity, high reliability, and low latency compared to Long Term Evolution (LTE) as a fourth generation (4G) radio access technology. In 3GPP, a technical specification of establishing a Multicast and Broadcast Service (MBS) of 5G / NR has been discussed (for example, see Non-Patent Literature 1).

[0003] LIST OF CITATIONS

[0004] NON-PATENT LITERATURE

[0005] Non-Patent Literature 1: 3GPP Document: RP-201038, “WID revision: NR Multicast and Broadcast Services” SUMMARY

[0006] It is desirable that the 5G / NR Multicast and Broadcast Service provides enhanced services compared to the 4G / LTE Multicast and Broadcast Service.

[0007] In view of this, the present disclosure provides a communication method, a user equipment, and a base station capable of realizing an enhanced Multicast and Broadcast Service.

[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 receiving, from a base station, a radio resource control (RRC) reconfiguration message including a MBS session identifier of a MBS session, an identifier related to an MRB to which the MBS session is mapped, and a hyper frame number (HFN) corresponding to the MBS session.

[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 receiver configured to receive, from a base station, a radio resource control (RRC) reconfiguration message including a MBS session identifier of a MBS session, an identifier related to an MRB to which the MBS session is mapped, and a hyper frame number (HFN) corresponding to the MBS session.

[0010] In a third aspect, a base station is used in a mobile communication system for supporting a multicast and broadcast service (MBS). The base station includes a transmitter configured to transmit, to a user equipment, a radio resource control (RRC) reconfiguration message including an MBS session identifier of an MBS session, an identifier related to an MRB to which the MBS session is mapped, and a hyper frame number (HFN) corresponding to the MBS session.

[0011] In a fourth 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 managing a first packet data convergence protocol (PDCP) variable that is updated in response to reception of a PDCP packet in the MBS session, the first PDCP variable being managed in a PDCP layer, and in response to determining that reception of the MBS session has been interrupted for a predetermined time, the user equipment performing control to synchronize the first PDCP variable with a second PDCP variable managed by the base station.

[0012] In a fifth 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, upon starting receiving an MBS session from a base station, manage a first packet data convergence protocol (PDCP) variable that is updated in response to reception of a PDCP packet in the MBS session, the first PDCP variable being managed in a PDCP layer. The controller performs control to synchronize the first PDCP variable with a second PDCP variable managed by the base station in response to determining that reception of the MBS session has been interrupted for a predetermined time.

[0013] In a sixth aspect, a base station is used in a mobile communication system for supporting a multicast and broadcast service (MBS). The base station includes a controller configured to, upon starting transmitting an MBS session, manage a first packet data convergence protocol (PDCP) variable that is updated in response to transmission of a PDCP packet in the MBS session, the first PDCP variable being managed in a PDCP layer, a receiver configured to receive, from a user equipment, a request for checking the PDCP variable, and a transmitter configured to transmit, to the user equipment, the PDCP variable in response to the request. BRIEF DESCRIPTION OF DRAWINGS

[0014] Figure 1 FIG. 1 is a diagram illustrating a configuration of a mobile communication system according to an embodiment.

[0015] Figure 2 FIG. 2 is a diagram illustrating a configuration of a user equipment (UE) according to an embodiment.

[0016] Figure 3 FIG. 3 is a diagram illustrating a configuration of a gNB (base station) according to an embodiment.

[0017] Figure 4 is a diagram illustrating a configuration of a protocol stack of a radio interface handling a user plane of data.

[0018] Figure 5 is a diagram illustrating a configuration of a protocol stack of a radio interface handling a control plane of signaling (control signals).

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

[0020] Figure 7 is a diagram illustrating a delivery mode according to an embodiment.

[0021] Figure 8 is a diagram illustrating segmentation of a multicast radio bearer (MRB) according to an embodiment.

[0022] Figure 9 is a diagram illustrating an operation scenario of a mobile communication system according to an embodiment.

[0023] Figure 10 is a diagram illustrating an example of PDCP variables according to an embodiment.

[0024] Figure 11 is a diagram illustrating a PDCP data PDU according to an embodiment.

[0025] Figure 12 is a diagram illustrating an operation of identifying a RCVD COUNT, which is a COUNT value of a received PDCP data PDU in a UE (receive-side PDCP entity), according to an embodiment.

[0026] Figure 13 is a diagram illustrating an operation of a receive-side PDCP entity of a UE according to an embodiment.

[0027] Figure 14 is a diagram illustrating an operation of a UE according to an embodiment.

[0028] Figure 15 is a diagram illustrating an example of an operation of a mobile communication system according to an embodiment.

[0029] Figure 16 is a diagram illustrating another example of an operation of a mobile communication system according to an embodiment.

[0030] Figure 17 is a diagram illustrating PDCP fixed type PTM / PTP switching based on a current protocol. DETAILED DESCRIPTION

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

[0032] Configuration of mobile communication system

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

[0034] 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 can be simply referred to as the RAN 10. The 5GC 20 can be simply referred to as the core network (CN) 20.

[0035] The UE 100 is a mobile wireless communication device. The UE 100 can be any device as long as the UE 100 is used by a user. Examples of the UE 100 include a mobile phone terminal (including a smartphone) or 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 (a vehicle UE), and a flying object or a device provided on a flying object (an aerial UE).

[0036] 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 as an inter-base station interface. Each gNB 200 manages one or more cells. The gNB 200 performs wireless communication with the UE 100 that has established a connection to a cell of the gNB 200. The gNB 200 has a radio resource management (RRM) function, a function of routing user data (hereinafter, simply referred to as “data”), a measurement control function for mobility control and scheduling, and the like. The “cell” is used as a term representing the smallest unit of a wireless communication area. The “cell” is also used as a term representing a function or a resource for performing wireless communication with the UE 100. One cell belongs to one carrier frequency (hereinafter, simply referred to as “frequency”).

[0037] Note that the gNB can be connected to an evolved packet core (EPC) corresponding to a core network of LTE. An 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.

[0038] 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 and the like with respect to 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.

[0039] Figure 2 is a diagram illustrating a configuration of a UE 100 (user equipment) according to the present 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.

[0040] 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 (a reception signal), and outputs the resulting signal to the controller 130.

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

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

[0043] Figure 3 is a diagram illustrating a configuration of a gNB 200 (base station) according to the present 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.

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

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

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

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

[0048] Figure 4 is a diagram showing a configuration of a protocol stack of a radio interface that processes a user plane.

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

[0050] The PHY layer performs encoding and decoding, modulation and demodulation, antenna mapping and de-mapping, and resource mapping and de-mapping. Data and control information are transmitted and received 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 a physical downlink control channel (PDCCH). Specifically, the UE 100 blind-decodes the PDCCH using a radio network temporary identifier (RNTI) and acquires the successfully-decoded DCI as DCI addressed to the UE 100. The DCI transmitted from the gNB 200 is additionally provided with CRC parity bits scrambled by the RNTI.

[0051] The MAC layer performs priority control of data, retransmission processing through hybrid ARQ (HARQ: hybrid automatic repeat request), a random access procedure, and the like. Data and control information are transmitted and received 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 a transmission format (transport block size, modulation and coding scheme (MCS)) in the uplink and the downlink and a resource block to be allocated to the UE 100.

[0052] 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 and received between the RLC layer of the UE 100 and the RLC layer of the gNB 200 via a logical channel.

[0053] The PDCP layer performs header compression / decompression, encryption / decryption, and the like.

[0054] The SDAP layer performs mapping between an IP flow (as a unit of QoS (quality of service) control performed by a core network) and a radio bearer (as a unit of QoS control performed by an access stratum (AS)). Note that when the RAN is connected to an EPC, the SDAP does not need to be provided.

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

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

[0057] 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, re-establishment, and release of radio bearers. When there is a connection (RRC connection) between the RRC of the UE 100 and the RRC of the gNB 200, the UE 100 is in an RRC connected state. When there is no connection (RRC connection) between the RRC of the UE 100 and the RRC of the gNB 200, the UE 100 is in an RRC idle state. When the connection between the RRC of the UE 100 and the RRC of the gNB 200 is suspended, the UE 100 is in an RRC inactive state.

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

[0059] Overview of MBS

[0060] An overview of MBS according to the present 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 communication, mission critical communication, vehicle-to-everything (V2X) communication, IPv4 or IPv6 multicast delivery, Internet Protocol television (IPTV), group communication, and software delivery.

[0061] A broadcast service provides a service to each UE 100 within a certain service area for applications that do not require a high level of reliable QoS. An MBS session for a broadcast service is referred to as a broadcast session.

[0062] A multicast service does not provide a service to each UE 100, but provides a service to a group of UEs 100 participating in the multicast service (multicast session). An MBS session for a multicast service is referred to as a multicast session. The multicast service can provide the same content to the group of UEs 100 by a method having higher radio efficiency than the broadcast service.

[0063] Figure 6 is a diagram illustrating an overview of MBS service delivery according to the present embodiment.

[0064] MBS service (MBS data) is delivered from a single data source (application service provider) to multiple UEs. The 5G CN (5GC) 20 as the 5G core network receives MBS data from the application service provider and performs duplication of the MBS data to deliver the duplication product.

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

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

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

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

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

[0070] The PTP and PTM delivery methods are mainly related to the user plane. Modes for controlling MBS data delivery include two kinds of delivery: a first delivery and a second delivery.

[0071] Figure 7 Fig. 1 is a diagram illustrating a delivery mode according to the present embodiment.

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

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

[0074] The MBS reception configuration includes MBS traffic channel configuration information (hereinafter referred to as "MTCH configuration information") on the configuration of the MBS traffic channel that carries the MBS data. The MTCH configuration information includes MBS session information related to the MBS session and scheduling information of the MBS traffic channel corresponding to the MBS session. The scheduling information of the MBS traffic channel can include a discontinuous reception (DRX) configuration of the MBS traffic channel. The discontinuous reception configuration can include at least one parameter of a timer value for defining an on duration (on duration time: reception period), a timer value for extending the on duration (inactivity timer), a scheduling interval or DRX cycle (scheduling period, DRX cycle), an offset value for the start subframe of the scheduling period or DRX cycle (start offset, DRX cycle offset), a start delay slot value of the on duration timer (slot offset), a timer value for defining the maximum time before retransmission (retransmission timer), and a timer value for defining the minimum interval before the DL assignment of HARQ retransmission (HARQ RTT timer).

[0075] Note that the MBS traffic channel is a kind of logical channel and can be referred to as an MTCH. The MBS traffic channel is mapped to a downlink shared channel (DL-SCH) that is a kind of transport channel.

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

[0077] The MBS reception configuration in the second transmission mode is performed through broadcast signaling. For example, the 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)) that is transmitted from the gNB 200 to the UE 100 through broadcast. For example, the UE 100 can receive the BCCH and the MCCH using a dedicated RNTI that is predefined in the technical specification. The RNTI for BCCH reception can be an SI-RNTI, and the RNTI for MCCH reception can be an MCCH-RNTI.

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

[0079] In the first transmission mode and the second transmission mode, the UE 100 can 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 can be included in the MBS reception configuration (MTCH configuration information).

[0080] The network can provide different MBS services for different MBS sessions. The MBS session is identified by at least one 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 selected from the group consisting of the TMGI, the G-RNTI, 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.

[0081] Figure 8 is a diagram illustrating a split multicast radio bearer (MRB) according to the present embodiment. The MRB can be a type of data radio bearer (DRB). The split MRB can be used in the above-described first transmission mode.

[0082] The gNB 200 can configure the MRB into a PTP communication path and a PTM communication path for the UE 100. This allows the gNB 200 to dynamically switch transmission of MBS data to the UE 100 between PTP (PTP communication path) and PTM (PTM communication path). The gNB 200 can 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 leg, and the PTM communication path is referred to as a PTM leg. A functional unit corresponding to each layer is referred to as an entity.

[0083] The predetermined layer that terminates segmentation is a MAC layer (HARQ), an RLC layer, a PDCP layer, or an SDAP layer. Although examples in which the predetermined layer that terminates segmentation is a PDCP layer will be mainly described below, the predetermined layer can be a MAC layer (HARQ), an RLC layer, or an SDAP layer.

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

[0085] Each of the gNB 200 and the UE 100 includes two RLC entities provided for respective legs: one MAC entity and one PHY entity. The PHY entity can be provided for each leg. Note that in dual connectivity in which the UE 100 communicates with two gNBs 200, the UE 100 can include two MAC entities.

[0086] The PHY entity transmits and receives data of the PTP leg using a cell RNTI (cell radio network temporary identifier (C-RNTI)) that is assigned to the UE 100 one-to-one. The PHY entity transmits and receives data of the PTM leg using a G-RNTI that is assigned to the MBS session one-to-one. The C-RNTI is different for each UE 100, but the G-RNTI is an RNTI that is common to a plurality of UEs 100 that receive one MBS session.

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

[0088] In order to cause the gNB 200 and the UE 100 to perform PTP transmission (unicast) of MBS data using the PTP leg, it is necessary to configure the segmented MRB from the gNB 200 to the UE 100, and it is necessary to activate the PTP leg. In other words, even if the segmented MRB is configured for the UE 100, the gNB 200 cannot perform PTP transmission of MBS data using the PTP leg when the PTP leg is in a deactivated state.

[0089] When the PTM tributary is active, UE 100 monitors the PDCCH that uses the G-RNTI associated with the MBS session (i.e., uses G-RNTI to perform blind decoding of the PDCCH). UE 100 can monitor the PDCCH only at the scheduling time of the MBS session.

[0090] When the PTM tributary is in a deactivated state, the UE 100 does not monitor the PDCCH that has applied G-RNTI associated with the MBS session (i.e., it does not perform blind decoding of the PDCCH using G-RNTI).

[0091] When the PTP tributary is active, UE 100 monitors the PDCCH with C-RNTI applied. When Discontinuous Receiver Optimization (DRX) is configured in the PTP tributary, UE 100 monitors the PDCCH for the configured OnDuration period. When a cell (frequency) associated with an MBS session is specified, UE 100 can monitor the PDCCH for that cell even when the cell is deactivated.

[0092] When the PTP tributary is in an inactive state, UE 100 can monitor the PDCCH with C-RNTI applied to prepare for normal unicast downlink transmissions other than MBS data. Note that when specifying a cell (frequency) associated with an MBS session, UE 100 does not need to monitor the PDCCH for that MBS session.

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

[0094] Operation of mobile communication systems

[0095] Figure 9 This is a diagram illustrating an operational scenario of the mobile communication system 1 according to this embodiment.

[0096] gNB 200 transmits data to multiple UEs 100 via PTM (multicast or broadcast). Figure 9 In the example, UE 100a through UE 100c transmits MBS data for a specific MBS session. The RRC status of each UE 100 can be any state (RRC connected, RRC idle, or RRC inactive). The MBS transmission mode can be either the first transmission mode or the second transmission mode. MBS transmission in the first transmission mode can use PTM tributaries.

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

[0098] In the PDCP layer, each UE 100 includes a PDCP entity 101 associated with the MBS session (specifically, a receive-side PDCP entity associated with the MRB belonging to the MBS session). When each PDCP entity 101 (in Figure 10 In the example, when PDCP entities 101a to 101b) begin the transmission of an MBS session, PDCP entity 101 manages the PDCP variables that are updated in response to the reception of PDCP packets in the MBS session.

[0099] like Figure 10 As shown, a PDCP variable can be a count value (COUNT value), which includes the superframe number (HFN) that counts up each round of PDCP sequence numbering, and the PDCP sequence number (PDCP SN). For example, the COUNT value has a bit length of 32 bits, the PDCP SN has a bit length of 12 bits or 18 bits (SN_length), and the HFN has a bit length obtained by subtracting the bit length of the PDCP SN from the bit length of the COUNT value. The bit length of the PDCP SN can be configured using RRC signaling. Note that the term "PDCP variable" does not necessarily refer to the COUNT value and can also be used as a term to refer to various variables (HFN, PDCP SN, etc.) processed in the PDCP layer.

[0100] Figure 11 This is a diagram illustrating the PDCP packets (specifically, PDCP Data Protocol Data Units (PDUs)) that constitute MBS data. Figure 11 As shown, a 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. A PDCP data PDU may not include a MAC-I. As mentioned above, a PDCP data PDU includes a PDCP SN but not an HFN. Therefore, each of the gNB 200 and UE 100 needs to update the HFN in response to the transmission and reception of the PDCP data PDU, specifically by counting up the HFN each time the PDCP sequence number is rounded.

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

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

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

[0104] Third, when none of the above conditions are met, RCVD_HFN = HFN(RX_DELIV).

[0105] Then, RCVD_COUNT = [RCVD_HFN, RCVD_SN] is set.

[0106] Figure 13 is a diagram illustrating an operation of the receiving side PDCP entity 101 of the UE 100.

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

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

[0109] Next, the receiving side PDCP entity 101 stores the non-discarded PDCP PDUs in a reception buffer (step S17), and when "RCVD_COUNT >= RX_NEXT" (step S18: Yes), the receiving side PDCP entity 101 updates RX_NEXT = RCVD_COUNT + 1 (step S19). Here, RX_NEXT is a variable indicating a count value (RCVD_COUNT) of a PDCP SDU expected to be received next. The initial value of RX_NEXT is zero. When in-order delivery is configured (step S20: Yes), the receiving side PDCP entity 101 decompresses the header of the PDCP PDU and then delivers the result to the upper layer (step S21). Specifically, when "outOfOrderDelivery" is configured in RRC, the receiving side PDCP entity 101 performs the operation of S21. In-order delivery is an operation of delivering a packet to the upper layer without performing sequence control. Thus, as in step S21, immediately after a packet is received and stored in the buffer, the packet is delivered to the upper layer. Note that when step S20 is "No", sequence control is performed.

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

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

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

[0113] As described above, the reception-side PDCP entity 101 of the UE 100 updates the PDCP variables in response to receiving the PDCP packet (PDCP data PDU) from the gNB 200. Specifically, the reception-side PDCP entity 101 of the UE 100 configures the initial value of the PDCP variables to zero, and updates the PDCP variables (increments or counts up the PDCP variables) in response to receiving the packet from the gNB 200.

[0114] With regard to the PDCP packet (PDCP data PDU), the reception-side PDCP entity 101 of the UE 100 discards the PDCP packet when the integrity verification fails, when RCVD_COUNT < RX_DELIV (when it has been received, and the like), when RCVD_COUNT has been received, or the like.

[0115] For example, when the reception-side PDCP entity 101 of the UE 100 cannot receive the packet for a certain period or longer due to a poor radio state or the like, and then starts to receive the packet, the reception-side PDCP entity 101 can not correctly receive the packet. Specifically, when RCVD_SN » SN (RX_DELIV), the packet can be considered to be a previous packet.

[0116] This problem mainly occurs because the HFN is not synchronized between the gNB 200 and the UE 100. This unsynchronized state can occur when the UE 100 cannot receive the MBS reception (PTM reception) for a certain period. In particular, in PTM, there is a tendency to easily occur this state due to reception by multiple UEs and lack of layer 2 feedback. Therefore, the UE 100 cannot properly perform reception window control, packet reordering, and the like in the PDCP layer, and can not be able to properly continue the MBS reception. The present embodiment is an embodiment for solving this problem.

[0117] Figure 14 is a diagram illustrating an operation of the UE 100 according to the present embodiment. The UE 100 is Figure 9 one of the UE 100a to the UE 100c shown.

[0118] In step S1, the UE 100 starts to receive (PTM reception) the MBS session from the gNB 200. The MBS session can be a multicast session or a broadcast session.

[0119] In step S2, the reception-side PDCP entity 101 of the UE 100 manages the PDCP variables (hereinafter referred to as "first PDCP variables") that are updated in response to receiving the PDCP packet in the MBS session.

[0120] In step S3, the UE 100 determines whether the reception of the MBS session has been interrupted for a predetermined time. When the reception of the MBS session has not been interrupted for the predetermined time (step S3: No), the process returns to step S2.

[0121] When it is determined that the reception of the MBS session has been interrupted for the predetermined time (step S3: Yes), in step S4, the UE 100 performs control to synchronize the first PDCP variable managed by the UE 100 with a PDCP variable (hereinafter referred to as a “second PDCP variable”) managed by the gNB 200.

[0122] As described above, in a state in which it can be considered that the HFN is not synchronized between the gNB 200 and the UE 100, by performing control to synchronize the first PDCP variable managed by the UE 100 with the second PDCP variable managed by the gNB 200, the UE 100 can appropriately continue the MBS reception.

[0123] Step S4 can include the following steps: transmitting a request for checking the second PDCP variable to the gNB 200, and receiving the second PDCP variable transmitted from the gNB 200 in response to the request. The UE 100 can apply the second PDCP variable received from the gNB 200 to the first PDCP variable. Thus, the UE 100 can synchronize the first PDCP variable managed by the UE 100 with the second PDCP variable managed by the gNB 200.

[0124] Here, the UE 100 can transmit an RRC message including a request for checking the second PDCP variable and an identifier associated with the request to the gNB 200. The identifier can 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 can be an MBS interest indication message or a UE assistance information message.

[0125] The UE 100 can receive a message including the second PDCP variable and an identifier associated with the second PDCP variable from the gNB 200. The identifier is the same and / or similar to the identifier included in the above-described RRC message. Note that the message does not necessarily include the identifier associated with the second PDCP variable. The message can be UE dedicated signaling (e.g., an RRC reconfiguration message or a MAC control element (MAC CE)). The message can be broadcast signaling (e.g., an MBS-SIB or an MCCH).

[0126] Alternatively, the receiving side PDCP entity 101 of the UE 100 can transmit a PDCP control PDU including a request for checking the second PDCP variable to the gNB 200. In response to receiving the PDCP control PDU, the transmitting side PDCP entity 201 of the gNB 200 can transmit a PDCP control PDU including the second PDCP variable to the receiving side PDCP entity 101 of the UE 100.

[0127] The step S4 can include a step of re-establishing the receiving PDCP entity (the receiving side PDCP entity 101) for the MBS session. Thus, in a state where it can be considered that the HFN is not synchronized between the gNB 200 and the UE 100, the first PDCP variable managed by the UE 100 can be initialized (reset).

[0128] The step S4 can include a step of setting an initial value to the first PDCP variable. The step of setting the initial value can include a step of using a PDCP SN included in a PDCP packet (PDCP data PDU) received from the gNB 200 via the MBS session as at least a part of the initial value. Thus, the latest PDCP SN can be applied as at least a part of the first PDCP variable.

[0129] Figure 15 is a diagram illustrating an example of the operation of the mobile communication system 1 according to the present embodiment.

[0130] In step S101, the gNB 200 can transmit a timer configuration value for measuring a predetermined time to the UE 100. The UE 100 receives the timer configuration value. The UE 100 can be notified of the timer configuration value using UE-specific signaling (e.g., an RRC reconfiguration message). The UE 100 can be notified of the timer configuration value using broadcast signaling (e.g., an MBS-SIB or an MCCH). Note that the timer configuration value can be determined depending on the implementation of the UE 100. The timer configuration value can be configured for each MBS session, each QoS flow, or each G-RNTI.

[0131] In step S102, the gNB 200 starts transmitting MBS data of a certain MBS session to a plurality of UEs 100 (UE 100a to UE 100c in the example) by PTM (multicast or broadcast). The UE 100 starts the reception of the MBS data, and updates the PDCP variable (the first PDCP variable) of the UE 100. Figure 9

[0132] ​In step S103, the UE 100 determines whether or not the MBS reception (PTM reception) of the UE 100 has failed. For example, when the UE 100 fails to decode the MBS data in the lower layer, the UE 100 determines that the MBS reception of the UE 100 has failed. When it is determined that the MBS reception of the UE 100 has failed (step S103: YES), in step S104, the UE 100 starts the timer set with the above-mentioned timer configuration value.

[0133] In step S105, the UE 100 determines whether or not the MBS reception (PTM reception) of the UE 100 has succeeded. For example, when the UE 100 succeeds in decoding the MBS data in the lower layer, the UE 100 determines that the MBS reception of the UE 100 has succeeded. When it is determined that the MBS reception of the UE 100 has succeeded (step S105: YES), in step S106, the UE 100 stops the timer. When the MBS reception of the UE 100 has not succeeded (step S105: NO), the UE 100 does not stop the timer.

[0134] In step S107, the UE 100 determines whether or not the timer has expired. That is, the UE 100 determines whether or not the MBS reception has been interrupted for a predetermined time (a time configured with the timer configuration value). When the timer has not expired (step S107: NO), the UE 100 returns the process to step S105. On the other hand, when the timer has expired (step S107: YES), the UE 100 performs at least one of the processes in steps S108 to S112.

[0135] In step S108, the UE 100 can re-establish the PDCP entity (the reception-side PDCP entity 101) for the MBS reception. With this PDCP re-establishment, for the UE 100, an initial value is automatically assigned to a first PDCP variable (e.g., RX_DELIV). Here, in the UE 100, the RRC layer can instruct the PDCP layer (the reception-side PDCP entity 101) to perform the PDCP re-establishment. The PDCP layer (the reception-side PDCP entity 101) can automatically perform the PDCP re-establishment. When the PDCP layer (the reception-side PDCP entity 101) automatically performs the PDCP re-establishment, the PDCP layer (the reception-side PDCP entity 101) can notify the RRC layer of the PDCP re-establishment.

[0136] In step S109, the UE 100 performs a check request (interrogation) to the gNB 200 for the current COUNT value (the second PDCP variable) managed by the gNB 200. The gNB 200 receives the check request (interrogation).

[0137] In step S110, in response to receiving the check request (interrogation) from the UE 100, the gNB 200 transmits the COUNT value (second PDCP variable) managed by the gNB 200 to the UE 100. The UE 100 receives the COUNT value (second PDCP variable) managed by the gNB 200.

[0138] In step S111, the UE 100 applies the COUNT value (second PDCP variable) received from the gNB 200 as the COUNT value managed by the UE 100. For example, the UE 100 sets the COUNT value (second PDCP variable) received from the gNB 200 as the first PDCP variable (e.g., RX DELIV) of the PDCP entity (reception side PDCP entity 101) for MBS reception.

[0139] In step S112, the UE 100 attempts to receive the MBS session using the first PDCP variable set in step S111.

[0140] As a modification of the above-mentioned timer, the following timer operation can be employed. Specifically, although the UE 100 starts the timer in step S104, the UE 100 can start (or reset and restart) the timer when the UE 100 correctly receives the MBS data in S102. When the timer expires, in the same and / or similar manner as S107, the UE 100 can detect that the MBS reception has been interrupted for a predetermined time. That is, each time the UE 100 correctly receives the MBS data, the UE 100 can start (or reset and restart) the timer, and when the timer expires, the UE 100 can determine that the MBS reception has been interrupted for a predetermined time.

[0141] Figure 16 is a diagram illustrating another example of the operation of the mobile communication system 1 according to the present embodiment. Here, the difference from the operation example illustrated in Figure 15 will be described.

[0142] The operations of steps S201 to S208 are the same and / or similar to the operations of steps S101 to S108 of Figure 15 the mobile communication system 1 according to the present embodiment.

[0143] In step S209, the UE 100 can perform a check request (interrogation) for the current HFN (second PDCP variable) managed by the gNB 200 to the gNB 200. The gNB 200 receives the check request (interrogation).

[0144] In step S210, in response to receiving the check request (interrogation) from the UE 100, the gNB 200 can transmit the HFN (second PDCP variable) managed by the gNB 200 to the UE 100. The UE 100 receives the HFN (second PDCP variable) managed by the gNB 200.

[0145] Alternatively, the UE 100 can infer the HFN (second PDCP variable) managed by the gNB 200. For example, the UE 100 can generate HFN candidates, use the HFN candidates to attempt integrity verification, and determine the HFN candidate that has succeeded in the integrity verification as the HFN (second PDCP variable) managed by the gNB 200.

[0146] In step S211, the UE 100 sets the HFN (second PDCP variable) received in step S210 or the HFN (second PDCP variable) determined by the UE 100 as the HFN part of the COUNT value (first PDCP variable) managed by the UE 100 (e.g., the HFN part of RX DELIV). After the RRC reestablishment (step S208), the UE 100 can set the HFN (second PDCP variable) received in step S210 or the HFN (second PDCP variable) determined by the UE 100 as the initial value of the HFN part of the COUNT value (first PDCP variable) managed by the UE 100.

[0147] In step S212, the UE 100 receives the MBS session (data) from the gNB 200.

[0148] In step S213, the UE 100 acquires the PDCP SN of the first PDCP packet (PDCP data PDU) received from the gNB 200 in step S212. Then, the UE 100 sets the PDCP SN acquired from the first received PDCP packet as the PDCP SN part of the COUNT value (first PDCP variable) managed by the UE 100 (e.g., the PDCP SN part of RX DELIV). After the RRC reestablishment (step S208), the UE 100 can set the PDCP SN acquired from the first received PDCP packet as the initial value of the PDCP SN part of the COUNT value (first PDCP variable) managed by the UE 100.

[0149] Other Embodiments

[0150] The above-described embodiments mainly assume a scenario in which the UE 100 cannot receive the PTM for a certain period of time due to degradation of radio conditions. However, it is also assumed that the gNB 200 intentionally stops transmission for a certain period of time (for reasons such as having no data to transmit). Therefore, as in the above-described embodiments, in the example in which the timer is used to detect a predetermined time of interruption of MBS reception, when the gNB 200 intentionally interrupts MBS transmission for a predetermined time (for reasons such as having no data to transmit), the UE 100 also determines that MBS reception is interrupted, and thus the UE 100 can perform processing that is not otherwise necessary. In view of this, when the gNB 200 intentionally stops MBS transmission, the gNB 200 can transmit a stop indication of the timer to the UE 100. When the UE 100 receives the stop indication, the UE 100 stops the timer. When the gNB 200 resumes MBS transmission, the gNB 200 can transmit a resume indication of the timer to the UE 100. When the UE 100 receives the resume indication, the UE 100 resumes the timer. When resumed, the timer can be reset (i.e., set to 0), or need not be reset (i.e., can resume from the value at the time of being stopped). Alternatively, when the gNB 200 resumes MBS transmission, the gNB 200 can resume transmitting MBS data without transmitting the resume indication. When the UE 100 receives the MBS data, the UE 100 considers that the gNB 200 has resumed MBS transmission, and resumes the timer.

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

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

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

[0154] The phrases "based on" and "dependent on," as used in this disclosure, do not mean "based only on" and "dependent only on," unless explicitly stated otherwise. The phrase "based on" means both "based only on" and "based at least in part on." Similarly, the phrase "dependent on" means both "dependent only on" and "dependent at least in part on." "Obtaining" or "acquiring" can mean obtaining information from stored information, can mean obtaining information from information received from another node, or can mean obtaining information by generating the information. The terms "comprise," "comprises," and "comprising" do not mean "only comprising the recited items," but mean "comprising the recited items, or can comprise additional items." The term "or" used in this disclosure is not intended to be "exclusive or." In addition, any reference in this disclosure to the use of names such as "first" and "second" for elements generally does not limit the number or order of such elements. Such names can be used herein as a convenient method of distinguishing two or more elements. Thus, reference to first and second elements does not mean that only two elements can be employed there or that the first element needs to precede the second element in some manner. For example, when English articles such as "a," "an," and "the" are used in this disclosure, these articles include plural references unless the context clearly dictates otherwise.

[0155] Embodiments have been described in detail above with reference to the accompanying drawings, but the specific configurations are not limited to the above-described configurations, and various design changes can be made without departing from the gist of the present disclosure.

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

[0157] Supplemental note

[0158] 1. Introduction

[0159] The work item on NR Multicast and Broadcast Services (MBS) related to revisions was approved in RAN#88. The objective is to define mobility, including dynamic PTM / PTP handover and service continuity as shown below.

[0160] RAN basic functions for broadcast / multicast of UEs in RRC CONNECTED state are defined.

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

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

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

[0164] In the case of a UE, the gNB dynamically determines which of PTM and PTP will be used to deliver multicast data (shared delivery).

[0165] Further study is needed on how the layer handles reliability (in general), in-order delivery / overlapping handling, and how this layer plays a role in the handover between PTM and PTP.

[0166] In RAN2#113-e, regarding the discussion on L2 reliability in the architecture for dynamic PTM / PTP handover, the following agreements have been reached.

[0167] When both PTM and PTP are RLC UM, there is no L2 ARQ, and the configuration using handover between PTM and PTP with fixed PDCP is supported (e.g., when the service configured for unicast is normally configured in RLC UM).

[0168] In RAN2#113bis-e, further agreements have been reached regarding the architecture and signaling as shown below.

[0169] Agreements

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

[0171] Dynamic PTM / PTP handover is supported with split MRB bearers (type) including a common (single) PDCP entity.

[0172] Basically, no new UE-based signaling for supporting determination of gNB handover is introduced (e.g., PDCP SR for high reliability is not determined).

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

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

[0175] In terms of mobility, in RAN2, only the following basic principles are agreed.

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

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

[0178] In the network, the source gNB can transmit data to the target gNB, and the target gNB delivers the transmitted data. On the other hand, the 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.

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

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

[0181] 2. Discussion

[0182] 3. Split MRB configuration

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

[0184] In general, it can be considered that RRC reconfiguration is used to provide a configuration of a bearer including two logical channels (PTM leg and PTP leg) and to receive information of a multicast session. RAN2 described "Split MRB (agreed during online session) configured with PTM leg and PTP leg is assumed"; 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.

[0185] Observation 1: Before the dynamic PTM / PTP switching operation, it is considered that providing a configuration associating two logical channels with one MRB with RRC reconfiguration is a common understanding.

[0186] 4. Dynamic PTM / PTP switching operation

[0187] 5. Signaling

[0188] It needs to be further studied whether the use of a split MRB and a PTM leg can be activated or deactivated and its details.

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

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

[0191] When receiving an MRB with PTM / PTM (i.e., at the time of switching operation), there are the following four options.

[0192] Option 1: Activation / deactivation-based switching

[0193] The gNB indicates the UE to enable / disable the PTM leg using DCI, MAC CE, RRC signaling, etc. In addition to receiving MBS data via PTM or PTP, this option can handle the case of receiving MBS data via both legs more flexibly, as in split bearer or PDCP packet redundancy. The UE can reduce the power consumption from the deactivated PTM leg. In the implementation of the NW, it should be noted that the continuous activation of the two legs can be determined, and the main idea of the following option 4 can be covered.

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

[0195] The gNB indicates the UE to switch between the PTM leg and the PTP leg using DCI, MAC CE, RRC signaling, etc. This option is the same and / or similar to option 1 described above, and is simple because power is saved by deactivating the PTM leg. However, this option is not very flexible for operations related to split bearers including PDCP packet redundancy. It can be considered that this option only involves switching between the PTM leg and the PTP leg, and both of them cannot be activated.

[0196] Option 3: Switching based on RRC reconfiguration

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

[0198] Option 4: No switching-based signaling

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

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

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

[0202] For "bearer type change" different from dynamic switching, it is considered that bearer type change has the following cases.

[0203] Case 1: MRB with PTM only <- -> MRB with PTP only

[0204] Case 2: Split MRB <- -> MRB with PTM only

[0205] Case 3: Split MRB <- -> MRB with PTP only

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

[0207] Proposal 2: For bearer type change between MRB with PTM only, MRB with PTP only, and Split MRB, RAN2 needs to agree on the use of RRC reconfiguration.

[0208] 6. Behavior of PDCP

[0209] 7. Initial values of state variables

[0210] In addition to RLC UM mode, RAN2 agrees to support RLC AM mode for PTP leg of Split MRB. It is commonly understood that since "RLC-AM does not support PTM (for MBS R17 WI)", L2 reliability depends only on dynamic PTM / PTP switching. Therefore, for service continuity, it is worth investigating how packet loss at the beginning of MBS data reception and dynamic PTM / PTP switching can be greatly reduced.

[0211] As shown in Figure 17 by reusing the existing PDCP functional view, PDCP SN is common for PTM leg and PTP leg. PTM leg is used by multiple UEs, so PDCP SN can not be UE-specific, which affects both PTM leg and PTP leg. 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 leg (PTM leg or PTP leg) the first received MBS data arrives from. That is, the first received PDCP SN by the UE can be any value not assumed in the current unicast transmission. Since the state variables are configured with initial values, PDCP re-establishment of a certain UE can affect all other UEs. This leads to discarding unexpected operations in the reception window, i.e. PDCP PDUs outside the window. It is pointed out that there is a possibility that the same problem also exists in the switching scenario.

[0212] Observation 3: In case the UE joins the multicast session later and is configured with split MRB, it is confirmed that the SN of the first received PDCP PDU is not the initial value (i.e., “0”), regardless of PTM leg or PTP leg.

[0213] To address this issue, the following options are proposed.

[0214] Option A: gNB informs the initial value of COUNT, or RX_NEXT and RX_DELIV, to the UE.

[0215] This option is to simply change the initial value related to the reception window based on the information from the gNB so that the UE can receive the first transmission of MBS data in the existing mechanism. However, from the perspective of the PDCP layer, it is questionable whether the UE can continuously receive the first transmission intended by the gNB due to the delay of the handover, the degradation of the wire-free state, outside the RLC reconfiguration window, etc. In this case, it is not clear how this option works.

[0216] Option B: gNB informs the initial HFN to the UE, and the UE infers the initial HFN and SN from the first received PDCP PDU.

[0217] The SN part is the same and / or similar option as the V2X mechanism of Release 16, which is as follows. “The initial value of the SN part of RX_NEXT is (x+1) modulo (2 [sl-PDCP-SN-Size] ), and x is the SN of the first received PDCP data PDU”, and “In NR sidelink communication for broadcast and groupcast, the initial value of the SN part of RX_DELIV is (x-0.5x2 [sl-PDCP-SN-Size-1] ) modulo (2 [sl-PDCP-SN-Size] ), where x is the SN of the first received PDCP data PDU.

[0218] Regarding the HFN part, in the Release 16 V2X mechanism, the HFN is not used for security purposes, so there is no need for synchronization with the transmitting device and the receiving device. That is, there is a description as follows: “NOTE: The selection of the HFN of RX_NEXT is up to UE implementation to make the initial value of RX_DELIV a positive value.” Regarding NR MBS, “In RAN2, the answer given was to wait for the completion of the study on security related to MBS in SA3 before discussing security in RAN2.” Therefore, in RAN2, the discussion of the HFN part needs to be postponed until after the completion of the study on security related to SA3.

[0219] Based on the above, further discussion is needed based on Option B. According to Rel-16 sidelink for broadcast and groupcast, considering the SA3 development related to security for NR MBS, RAN2 needs to agree at least that the UE configures the initial value of the state variables according to the first received PDCP PDU of MBS data.

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

[0221] 8. Simultaneous reception and UE assistance information

[0222] In particular, in services where reliability is needed, PTP (leg) is configured in RLC AM, and lossless handover in the same and / or similar way as lossless mobility is important for service continuity. When agreeing to Proposal 1, the UE needs to support simultaneous reception from both PTM leg and PTP leg. That is, both legs can be activated simultaneously in the same and / or similar way as existing PDCP packet redundancy. This is for the following reasons: since the PTM leg is received by multiple UEs, this can easily lead to a non-optimal MCS for a specific UE. Therefore, RAN2 needs to agree to employ simultaneous reception for at least a certain period of time at dynamic PTM / PTP handover.

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

[0224] When agreeing to Proposal 3 and Proposal 4, the gNB can not actually know which PDCP SN the UE has started to receive correctly via the PTM leg. In the case of switching from PTP to PTM, the gNB can not know when to use the PTP leg to transmit PDCP PDUs and when it can stop the transmission of the PTP leg. To solve this problem, it is proposed that the UE informs the gNB of the success of PTM reception and performs transmission via the PTP leg. Note that it is not clear whether the UE also needs to include PDCP SN information in the same message.

[0225] Observation 4: In the case of switching from PTP to PTM, the gNB can not know from which PDCP PDU the transmission of the PTP leg needs to be maintained, or from which PDCP PDU the UE correctly receives using the PTM leg.

[0226] In the same and / or similar way, in case of switching from PTM to PTP, the gNB can not know which PDCP SN the UE has correctly received via the PTM leg (especially when the UE's radio status is bad). This means that the gNB can not know which PDCP PDU needs to be used when starting the PTP leg.

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

[0228] Therefore, it is investigated that the UE informs the gNB about the SN information via the PTP leg at dynamic PTM / PTP switching. In reporting the SN information when the UE dynamically switches between PTM and PTP, it is simple to reuse the PDCP control PDU, i.e. the PDCP status report including the FMC (first PDCP SDU not found) and optionally a bitmap indicating whether subsequent PDCP SDUs are not found or correctly received. On the other hand, another option is that the UE reports the SN in which the UE's first / last PDCP PDU reception has been successful via the PTM leg. Therefore, it is needed to further discuss the details to be reported by the UE at dynamic switching between PTM and PTP.

[0229] In either case described above (i.e. the case of switching from PTP to PTM and the case of switching from PTM to PTP), in order to serve continuity, the PDCP control PDU including the PDCP SN information needs to be triggered at dynamic switching (e.g. activation / deactivation of MAC CE).

[0230] Proposal 5: RAN2 needs to investigate whether the UE needs to send the PDCP control PDU including the PDCP SN information at dynamic switching for service continuity. It needs to be further investigated whether the PDCP information report can be reused.

[0231] Another point to be investigated is whether lossless dynamic switching as in Proposal 5 needs to be the same and / or similar to lossless bearer type change. From the perspective of service continuity and lossless mobility, it is considered that the bearer type change including the PTP (leg) with RLC AM needs the same and / or similar reliability as the reliability of dynamic switching. Therefore, RAN2 needs to investigate whether lossless bearer type change needs to be supported. When this is supported, the PDCP control PDU needs to be reused as UE assistance information in the same and / or similar way as Proposal 5.

[0232] Proposal 6: RAN2 needs to discuss whether the same approach can be applied for lossless bearer type change with RRC reconfiguration (i.e. lossless dynamic switching using PDCP Control PDU as in Proposal 5).

[0233] Reference Signs

[0234] 1: Mobile communication system

[0235] 10: RAN

[0236] 20: CN

[0237] 100: UE

[0238] 110: Receiver

[0239] 120: Transmitter

[0240] 130: Controller

[0241] 200: gNB

[0242] 210: Transmitter

[0243] 220: Receiver

[0244] 230: Controller

[0245] 240: Backhaul communicator

Claims

1. A communication method for use in a mobile communication system for supporting multicast and broadcast service (MBS), the communication method comprising: receiving, by a user equipment (UE), a radio resource control (RRC) reconfiguration message from a network node, the RRC reconfiguration message including a MBS session identifier of a MBS session, an identifier related to a MRB to which the MBS session is mapped, and a hyper frame number (HFN) in a packet data convergence protocol (PDCP) variable corresponding to the MBS session; and setting, by the UE, the HFN included in the RRC reconfiguration message to an initial value of the HFN in the PDCP variable corresponding to the MBS session, wherein the PDCP variable corresponding to the MBS session is a variable indicating an oldest PDCP service data unit (SDU) to be received and not yet provided to a higher layer. 2.The communication method of claim 1, wherein the RRC reconfiguration message further includes a PDCP sequence number corresponding to the MBS session. 3.The communication method of claim 1, wherein the UE that has received the RRC reconfiguration message reestablishs a PDCP entity. 4.The communication method of claim 1, wherein the MBS session is a multicast session. 5.The communication method of claim 1, wherein the identifier related to the MRB to which the MBS session is mapped is a MRB identifier. 6.A user equipment (UE) for use in a mobile communication system for supporting multicast and broadcast service (MBS), the UE comprising: a receiver configured to receive a radio resource control (RRC) reconfiguration message from a network node, the RRC reconfiguration message including a MBS session identifier of a MBS session, an identifier related to a MRB to which the MBS session is mapped, and a hyper frame number (HFN) in a packet data convergence protocol (PDCP) variable corresponding to the MBS session; and a controller configured to set the HFN included in the RRC reconfiguration message to an initial value of the HFN in the PDCP variable corresponding to the MBS session, wherein the PDCP variable corresponding to the MBS session is a variable indicating an oldest PDCP service data unit (SDU) to be received and not yet provided to a higher layer. 7.A network node for use in a mobile communication system for supporting multicast and broadcast service (MBS), the network node comprising: a transmitter configured to transmit a radio resource control (RRC) reconfiguration message to a user equipment (UE), the RRC reconfiguration message including a MBS session identifier of a MBS session, an identifier related to a MRB to which the MBS session is mapped, and a hyper frame number (HFN) in a packet data convergence protocol (PDCP) variable corresponding to the MBS session, wherein the PDCP variable corresponding to the MBS session is a variable indicating an oldest PDCP service data unit (SDU) to be received and not yet provided to a higher layer. ​ 8.A mobile communication system comprising the user equipment according to claim 6 and the network node according to claim 7. 9.A chipset for a user equipment, the user equipment being used in a mobile communication system for supporting multicast and broadcast service, MBS, the chipset comprising: circuitry that receives a radio resource control, RRC, reconfiguration message from a network node, the RRC reconfiguration message including a MBS session identifier of a MBS session, an identifier related to an MRB to which the MBS session is mapped, and a hyper frame number, HFN, in a packet data convergence protocol, PDCP, variable corresponding to the MBS session; and circuitry that sets the HFN included in the RRC reconfiguration message to an HFN initial value in the PDCP variable corresponding to the MBS session, wherein the PDCP variable corresponding to the MBS session is a variable indicating an oldest PDCP SDU to be received and not yet provided to a higher layer.

10. A computer program product comprising a computer program, characterized in that, The computer program, when executed by a processor, causes a user equipment used in a mobile communication system for supporting multicast and broadcast service, MBS, to perform the following processing: receiving a radio resource control, RRC, reconfiguration message from a network node, the RRC reconfiguration message including a MBS session identifier of a MBS session, an identifier related to an MRB to which the MBS session is mapped, and a hyper frame number, HFN, in a packet data convergence protocol, PDCP, variable corresponding to the MBS session; setting the HFN included in the RRC reconfiguration message to an HFN initial value in the PDCP variable corresponding to the MBS session, wherein the PDCP variable corresponding to the MBS session is a variable indicating an oldest PDCP SDU to be received and not yet provided to a higher layer.

Images