Communication control method and user device

Abstract

A communication control method according to a first aspect of the present invention is a method used in a mobile communication system that provides multicast and broadcast service (MBS) to user equipment from a base station. The communication control method comprises: the user device receiving MBS data sent from the base station via one transmission method among PTP transmission and PTM transmission; and, in accordance with the transmission method being switched between the PTP transmission and the PTM transmission, the user device sending the base station a message including information representing a sequence number of a received packet related to the switching.

Description

[Technical field]

[0001] The present disclosure relates to a communication control method and a user device for use in a mobile communication system. [Background technology]

[0002] In recent years, the fifth generation (5G) mobile communication system has been attracting attention. NR (New Radio), the radio access technology (RAT) of the 5G system, has features such as high speed, large capacity, high reliability, and low latency compared to LTE (Long Term Evolution), the fourth generation radio access technology. [Prior art documents] [Non-patent literature]

[0003] [Non-Patent Document 1] 3GPP technical specification "3GPP TS 38.300 V16.3.0 (2020-09)" Summary of the Invention

[0004] A communication control method according to a first aspect is a method used in a mobile communication system that provides a multicast broadcast service (MBS) from a base station to a user device. The communication control method includes the steps of: receiving MBS data transmitted from the base station by the user device in one of a PTP transmission and a PTM transmission transmission method; and transmitting a message including information indicating a sequence number of a received packet related to the switching to the base station by the user device in response to the switching of the transmission method between the PTP transmission and the PTM transmission.

[0005] A communication control method according to a second aspect is a method used in a mobile communication system that provides a multicast / broadcast service (MBS) from a base station to a user device. The communication control method includes the steps of: the user device performing a PTM monitoring operation to attempt to receive MBS data transmitted from the base station via a PTM communication path; and the user device stopping the PTM monitoring operation in response to detection of deterioration of a measurement value indicating communication quality of the PTM communication path.

[0006] A user device according to a third aspect includes a processor that executes the communication control method according to the first or second aspect. [Brief description of the drawings]

[0007] [Figure 1] 1 is a diagram showing a configuration of a mobile communication system according to an embodiment; [Diagram 2] FIG. 1 is a diagram illustrating a configuration of a UE (user equipment) according to an embodiment. [Diagram 3] A diagram showing the configuration of a gNB (base station) according to one embodiment. [Figure 4] A diagram showing the configuration of a protocol stack of a wireless interface of a user plane that handles data. [Diagram 5] FIG. 2 is a diagram showing the configuration of a protocol stack of a radio interface of a control plane that handles signaling (control signals). [Figure 6] FIG. 2 is a diagram showing a correspondence relationship between downlink logical channels and transport channels according to an embodiment. [Figure 7] FIG. 2 is a diagram illustrating a method for distributing MBS data according to an embodiment. [Figure 8] A diagram showing a split MBS bearer according to one embodiment. [Figure 9] FIG. 13 illustrates an example operation for leg activation and deactivation according to one embodiment. [Figure 10]FIG. 11 is a diagram illustrating an example of an operation of switching from PTP transmission to PTM transmission according to an embodiment. [Figure 11] FIG. 13 is a diagram illustrating an example of the configuration of an SN notification message according to an embodiment. [Figure 12] FIG. 11 is a diagram illustrating an example of an operation of switching from PTM transmission to PTP transmission according to an embodiment. [Figure 13] FIG. 11 is a diagram illustrating an example of an operation related to a PTM monitor operation according to an embodiment. [Figure 14] A diagram showing PDCP anchor PTM / PTP switching based on the current agreement. [Figure 15] A diagram showing PDCP anchor PTM RLC-UM / PTP RLC-UM switching based on agreement. [Figure 16] A diagram showing an example of A1+B1 of PTM RLC-UM+PTP RLC-AM. [Figure 17] A diagram showing an example of A2+B1 of PTM RLC-UM+PTP RLC-AM. [Figure 18] A diagram showing an example of A3+B2(+B1) of PTM RLC-AM+PTP RLC-AM. [Figure 19] FIG. 1 shows a summary of possible options for L2 reliability. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0008] The introduction of multicast and broadcast services to the 5G system (NR) is being considered. It is hoped that the NR multicast and broadcast services will provide improved services compared to the LTE multicast and broadcast services.

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

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

[0011] (Configuration of a mobile communication system) First, a configuration of a mobile communication system according to an embodiment will be described. FIG. 1 is a diagram showing a configuration of a mobile communication system according to an embodiment. This mobile communication system complies with the 3GPP standard 5th Generation System (5GS). In the following description, 5GS will be taken as an example, but the mobile communication system may be at least partially applied to an LTE (Long Term Evolution) system. Also, the mobile communication system may be at least partially applied to a 6th Generation (6G) system.

[0012] As shown in FIG. 1, the mobile communication system includes a user equipment (UE) 100, a 5G radio access network (NG-RAN) 10, and a 5G core network (5GC) 20.

[0013] The UE 100 is a mobile wireless communication device. The UE 100 may be any device that is used by a user, and may be, for example, a mobile phone terminal (including a smartphone), a tablet terminal, a notebook PC, a communication module (including a communication card or a chipset), a sensor or a device provided in a sensor, a vehicle or a device provided in a vehicle (Vehicle UE), and / or an aircraft or a device provided in an aircraft (Aerial UE).

[0014] The NG-RAN 10 includes a base station (called "gNB" in the 5G system) 200. The gNBs 200 are connected to each other via an Xn interface, which is an interface between base stations. The gNB 200 manages one or more cells. The gNB 200 performs wireless communication with the UE 100 that has established a connection with its own cell. The gNB 200 has a radio resource management (RRM) function, a routing function for user data (hereinafter simply referred to as "data"), a measurement control function for mobility control and scheduling, and the like. The term "cell" is used to indicate the smallest unit of a wireless communication area. The term "cell" is also used to indicate a function or resource for performing wireless communication with the UE 100. One cell belongs to one carrier frequency.

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

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

[0017] FIG. 2 is a diagram showing a configuration of a UE 100 (user equipment) according to an embodiment.

[0018] As shown in FIG. 2, the UE 100 includes a receiving unit 110, a transmitting unit 120, and a control unit .

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

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

[0021] The control unit 130 performs various controls in the UE 100. The control unit 130 includes at least one processor and at least one memory. The memory stores programs executed by the processor and information used in the 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. The CPU executes programs stored in the memory to perform various processing.

[0022] FIG. 3 is a diagram showing the configuration of a gNB 200 (base station) according to one embodiment.

[0023] As shown in FIG. 3, the gNB 200 includes a transmitter 210, a receiver 220, a control unit 230, and a backhaul communication unit 240.

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

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

[0026] The control unit 230 performs various controls in the gNB 200. The control unit 230 includes at least one processor and at least one memory. The memory stores programs executed by the processor and information used in the processing by the processor. The processor may include a baseband processor and a CPU. The baseband processor performs modulation / demodulation and encoding / decoding of baseband signals. The CPU executes programs stored in the memory to perform various processing.

[0027] The backhaul communication unit 240 is connected to adjacent base stations via an inter-base station interface. The backhaul communication unit 240 is connected to the AMF / UPF 300 via a base station-core network interface. Note that the gNB is composed of a CU (Central Unit) and a DU (Distributed Unit) (i.e., the functions are divided), and both units may be connected to each other via an F1 interface.

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

[0029] As shown in FIG. 4, the user plane radio interface protocol includes a physical (PHY) layer, a medium access control (MAC) layer, a radio link control (RLC) layer, a packet data convergence protocol (PDCP) layer, and a service data adaptation protocol (SDAP) layer.

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

[0031] The MAC layer performs data priority control, retransmission processing using hybrid ARQ (HARQ), random access procedures, etc. Data and control information are transmitted between the MAC layer of the UE 100 and the MAC layer of the gNB 200 via a transport channel. The MAC layer of the gNB 200 includes a scheduler. The scheduler determines the uplink and downlink transport format (transport block size, modulation and coding scheme (MCS)) and the resource blocks to be assigned to the UE 100.

[0032] The RLC layer transmits data to the RLC layer on the receiving side by using the functions of the MAC layer and the PHY layer. Data and control information are transmitted between the RLC layer of the UE 100 and the RLC layer of the gNB 200 via a logical channel.

[0033] The PDCP layer performs header compression / decompression and encryption / decryption.

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

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

[0036] As shown in FIG. 5, the protocol stack of the radio interface of the control plane has a Radio Resource Control (RRC) layer and a Non-Access Stratum (NAS) layer instead of the SDAP layer shown in FIG.

[0037] Between the RRC layer of the UE 100 and the RRC layer of the gNB 200, RRC signaling for various settings is transmitted. The RRC layer controls logical channels, transport channels, and physical channels according to the establishment, re-establishment, and release of radio bearers. When there is a connection (RRC connection) between the RRC of the UE 100 and the RRC of the gNB 200, the UE 100 is in an RRC connected state. When there is no connection (RRC connection) between the RRC of the UE 100 and the RRC of the gNB 200, the UE 100 is in an RRC idle state. When the connection between the RRC of the UE 100 and the RRC of the gNB 200 is suspended, the UE 100 is in an RRC inactive state.

[0038] The NAS layer, which is located above the RRC layer, performs session management, mobility management, etc. NAS signaling is transmitted between the NAS layer of the UE 100 and the NAS layer of the AMF 300B.

[0039] In addition, the UE 100 has an application layer and the like in addition to the protocol of the radio interface.

[0040] (MBS) Next, an MBS according to an embodiment will be described. The MBS is a service that enables broadcast or multicast data transmission from the NG-RAN 10 to the UE 100, that is, point-to-multipoint (PTM) data transmission. The MBS may be called a multimedia broadcast and multicast service (MBMS). Note that use cases (service types) of the MBS include public safety communication, mission critical communication, vehicle to everything (V2X) communication, IPv4 or IPv6 multicast distribution, IPTV, group communication, and software distribution.

[0041] There are two types of MBS transmission methods in LTE: MBSFN (Multicast Broadcast Single Frequency Network) transmission and SC-PTM (Single Cell Point To Multipoint) transmission. Fig. 6 is a diagram showing a correspondence relationship between downlink logical channels and transport channels according to one embodiment.

[0042] As shown in FIG. 6, the logical channels used for MBSFN transmission are MTCH (Multicast Traffic Channel) and MCCH (Multicast Control Channel), and the transport channel used for MBSFN transmission is MCH (Multicast Traffic Channel). t MBSFN transmission is primarily designed for multi-cell transmission, where each cell in an MBSFN area transmits the same signal (the same data) synchronously in the same MBSFN subframe.

[0043] The logical channels used for SC-PTM transmission are the SC-MTCH (Single Cell Multicast Traffic Channel) and the SC-MCCH (Single Cell Multicast Control Channel), and the transport channel used for SC-PTM transmission is the DL-SCH (Downlink Shared Channel). SC-PTM transmission is designed primarily for single-cell transmission, and transmits data by broadcast or multicast on a cell-by-cell basis. The physical channels used for SC-PTM transmission are the PDCCH (Physical Downlink Control Channel) and the PDSCH (Physical Downlink Shared It is a QoS Channel, which allows dynamic resource allocation.

[0044] In the following, an example in which an MBS is provided using a method similar to the SC-PTM transmission method will be mainly described, but an MBS may also be provided using the MBSFN transmission method. Also, an example in which an MBS is provided by multicast will be mainly described. Therefore, MBS may be read as multicast. However, an MBS may also be provided by broadcast.

[0045] Moreover, MBS data refers to data provided by the MBS. The MBS control channel refers to the MCCH or SC-MCCH. The MBS traffic channel refers to the MTCH or SC-MTCH. However, the MBS data may be transmitted by unicast. The MBS data may also be called an MBS packet or MBS traffic.

[0046] A network can provide different MBS services for each MBS session. An MBS session is identified by at least one of a Temporary Mobile Group Identity (TMGI) and a session identifier, and at least one of these identifiers is called an MBS session identifier. Such an MBS session identifier may be called an MBS service identifier or a multicast group identifier.

[0047] FIG. 7 is a diagram showing a method for distributing MBS data according to an embodiment.

[0048] As shown in Fig. 7, MBS data (MBS Traffic) is distributed from a single data source (application service provider) to multiple UEs. A 5G CN (5GC) 20, which is a 5G core network, receives the MBS data from the application service provider, creates a copy (replication) of the MBS data, and distributes it.

[0049] From the 5GC20 point of view, two delivery methods are possible: Shared MBS Traffic delivery and Individual MBS Traffic delivery.

[0050] In the shared MBS data delivery, a connection is established between NG-RAN 10, which is a 5G radio access network (5G RAN), and 5GC 20, and MBS data is delivered from 5GC 20 to NG-RAN 10. Hereinafter, such a connection (tunnel) is referred to as an "MBS connection."

[0051] The MBS connection may be referred to as a Shared MBS Traffic delivery connection or a shared transport. The MBS connection terminates in the NG-RAN 10 (i.e., the gNB 200). The MBS connection may have a one-to-one correspondence with the MBS session.

[0052] gNB200 selects either PTP (Point-to-Point: unicast) or PTM (Point-to-Multipoint: multicast or broadcast) transmission method at its own discretion, and transmits MBS data to UE100 using the selected transmission method.

[0053] On the other hand, in the individual MBS data delivery, a unicast session is established between the NG-RAN 10 and the UE 100, and the MBS data is delivered individually from the 5GC 20 to the UE 100. Such a unicast may be called a PDU session. The unicast (PDU session) is terminated at the UE 100.

[0054] (Split MBS Bearer) Next, a split MBS bearer according to one embodiment will be described.

[0055] The gNB200 can set an MBS bearer separated into a PTP communication path and a PTM communication path (hereinafter, appropriately referred to as a "split MBS bearer") to the UE100. This allows the gNB200 to dynamically switch the transmission of MBS data to the UE100 between PTP (PTP communication path) and PTM (PTM communication path). Alternatively, the gNB200 can enhance reliability by dually transmitting the same MBS data using both PTP (PTP communication path) and PTM (PTM communication path).

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

[0057] 8 is a diagram showing a split MBS bearer according to an embodiment. In the following, a PTP communication path is called a PTP leg, and a PTM communication path is called a PTM leg. In addition, a functional unit corresponding to each layer is called an entity.

[0058] As shown in Fig. 8, each of the PDCP entity of the gNB 200 and the PDCP entity of the UE 100 separates an MBS bearer, which is a bearer (data radio bearer) used for MBS, into a PTP leg and a PTM leg. Note that a PDCP entity is provided for each bearer.

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

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

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

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

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

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

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

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

[0067] It is assumed that the split MBS bearer described above is configured by an RRC message (e.g., an RRC Reconfiguration message) sent by the RRC entity of gNB200 to the RRC entity of UE100.

[0068] (Activating and Deactivating Legs) Next, activation and deactivation of legs according to an embodiment will be described. Fig. 9 is a diagram showing an example of operations related to activation and deactivation of legs according to an embodiment.

[0069] As shown in Fig. 9, in step S11, the RRC entity of the gNB 200 transmits an RRC message including the configuration of the split MBS bearer (split bearer) shown in Fig. 8 to the UE 100. The RRC message is, for example, an RRC Reconfiguration message. The RRC entity of the UE 100 establishes the split MBS bearer based on the configuration included in the RRC message received from the gNB 200. In the following, an example in which the UE 100 establishes one split MBS bearer will be mainly described, but the UE 100 may establish multiple split MBS bearers according to the configuration from the gNB 200.

[0070] When performing bearer setup using an RRC message (RRC Reconfiguration message), the gNB 200 may instruct the UE 100 of the initial state of each leg (i.e., activation or deactivation of each leg) using the same message. When the RRC entity of the gNB 200 transmits an RRC message including bearer setup of the split MBS bearer to the UE 100, the RRC entity of the gNB 200 includes an instruction to activate or deactivate each leg in the RRC message together with the bearer setup.

[0071] Such an RRC message may include at least one of an identifier of the leg (PTP leg, PTM leg) to be instructed and an identifier indicating either activation or deactivation. The RRC message may include an identifier (e.g., TMGI, G-RNTI, session identifier, QoS flow identifier, bearer identifier) ​​associated with the MBS session (split MBS bearer) to be instructed.

[0072] In step S12, gNB200 sends an instruction to UE100 to activate or deactivate the PTP leg and the PTM leg individually.

[0073] Here, the MAC entity of the gNB 200 may transmit a MAC control element (MAC CE) including the instruction to the UE 100. The MAC entity of the UE 100 receives the MAC CE from the gNB 200. Alternatively, the PHY entity of the gNB 200 may transmit downlink control information (DCI) including the instruction to the UE 100. The PHY entity of the UE 100 receives the DCI from the gNB 200.

[0074] Such a MAC CE or DCI may include at least one of an identifier of the leg (PTP leg, PTM leg) to be instructed and an identifier indicating either activation or deactivation. The MAC CE or DCI may include an identifier (e.g., TMGI, G-RNTI, session identifier, QoS flow identifier, bearer identifier) ​​associated with the MBS session (split MBS bearer) to be instructed.

[0075] By using the MAC CE or DCI to indicate the activation and deactivation of each leg, more dynamic control is possible than when using RRC messages.

[0076] In response to receiving an instruction to activate the PTP leg, the UE 100 starts a data reception process using the C-RNTI. In response to receiving an instruction to activate the PTM leg, the UE 100 starts a MBS data reception process using the G-RNTI. On the other hand, in response to receiving an instruction to deactivate the PTP leg, the UE 100 ends a data reception process using the C-RNTI. In response to receiving an instruction to deactivate the PTM leg, the UE 100 ends a MBS data reception process using the G-RNTI.

[0077] In step S12, the gNB 200 may transmit (PTM transmit) an instruction to activate or deactivate the PTP leg to the UE 100 via the PTM leg in the activated state. This makes it possible to collectively activate or deactivate the PTP legs of multiple UEs 100 by PTM.

[0078] The gNB 200 may transmit (PTM transmit) an instruction to deactivate the PTM leg to the UE 100 via the PTM leg in the activated state. This makes it possible to collectively deactivate the PTM legs of multiple UEs 100 by PTM.

[0079] In step S12, the gNB 200 may transmit (PTP transmit) an instruction to activate or deactivate the PTM leg to the UE 100 via the PTP leg in the activated state. This allows the PTM leg to be individually activated or deactivated for each UE 100.

[0080] The gNB 200 may transmit (PTP transmit) an instruction to deactivate the PTP leg to the UE 100 via the PTP leg in the activated state. This allows the PTP leg to be deactivated individually for each UE 100.

[0081] In step S13, in response to receiving an instruction to activate at least one of the PTP leg and the PTM leg from the gNB 200 in step S12, the UE 100 may transmit a response to the received instruction to the gNB 200. This response may be transmitted, for example, from the MAC entity of the UE 100 to the gNB 200 via the PTP leg. After transmitting the response, the UE 100 may start a data reception operation in the activated leg.

[0082] The gNB 200 transmits data through the activated leg in response to receiving the response from the UE 100. That is, after receiving the response, the gNB 200 starts a data transmission operation in the leg.

[0083] In addition, upon receiving an instruction to deactivate at least one of the PTP leg and the PTM leg from gNB200 in step S12, UE100 may send a response to the received instruction to gNB200.

[0084] The PDCP entity of the UE 100 may perform a process of discarding duplicate packets of two identical MBS packets transmitted by duplication when both the PTP leg and the PTM leg are activated.

[0085] When the PTP leg is deactivated, the RRC entity of the UE 100 may transmit a message (RAI: Release Assistance Information / preference) to the gNB 200 to prompt the gNB 200 to release the RRC connection. Alternatively, the UE 100 may be permitted to transmit the RAI even when dynamic switching between the PTP leg and the PTM leg is being set.

[0086] (Switching between PTP and PTM transmission) Next, switching between PTP transmission and PTM transmission according to an embodiment will be described.

[0087] When a split MBS bearer is assumed, PTP transmission may be a method of transmitting MBS data from the gNB 200 to the UE 100 using a PTP leg (PTP communication path). PTM transmission may be a method of transmitting MBS data from the gNB 200 to the UE 100 using a PTM leg (PTM communication path). The switching operation between PTP transmission and PTM transmission may be an operation of ending MBS data transmission of one of the transmission methods of PTP transmission and PTM transmission and starting MBS data transmission of the other transmission method at the same time. During such switching, MBS data (MBS packets) transmitted from the gNB 200 to the UE 100 may be lost, resulting in a gap.

[0088] In addition, when switching from PTP transmission to PTM transmission, there is a problem as to when the gNB200 stops PTP transmission. Conversely, when switching from PTM transmission to PTP transmission, there is a problem as to from which packet the gNB200 starts PTP transmission. In other words, there is a problem that it is difficult to appropriately control PTP transmission when switching between PTP transmission and PTM transmission.

[0089] In one embodiment, the UE 100 receives MBS data transmitted from the gNB 200 in either the PTP transmission or the PTM transmission. Thereafter, in response to the transmission method being switched between the PTP transmission and the PTM transmission, the UE 100 transmits to the gNB 200 a message (hereinafter referred to as an "SN notification message") including information indicating a sequence number (SN) of a received packet related to the switching. The SN may be a PDCP SN given on a PDCP packet basis. The SN may be a COUNT value for identifying a PDCP packet. The COUNT value is composed of a Hyper Frame Number (HFN) and a PDCP SN. The SN may be an RLC SN given on an RLC packet basis. In the following, the case where the SN is the PDCP SN is mainly assumed. For this reason, the term "packet" refers to a PDCP packet.

[0090] In this way, by transmitting an SN notification message including SN information of a received packet related to switching between PTP transmission and PTM transmission from UE100 to gNB200, gNB200 can grasp the reception state of MBS packets in UE100. Therefore, it becomes possible to appropriately control PTP transmission when switching between PTP transmission and PTM transmission. For example, gNB200 controls PTP transmission so as to fill the SN gap between PTP transmission and PTM transmission. The SN gap refers to the difference between the SN of a PTP transmission packet and the SN of a PTM transmission packet.

[0091] In one embodiment, the UE 100 may transmit an SN notification message in response to detecting an SN gap between the PTP transmission and the PTM transmission when switching between the PTP transmission and the PTM transmission. The UE 100 may determine that an SN gap has occurred when the SN of the PTP transmission packet and the SN of the PTM transmission packet are discontinuous. The UE 100 may not transmit an SN notification message to the gNB 200 when not detecting an SN gap between the PTP transmission and the PTM transmission when switching between the PTP transmission and the PTM transmission.

[0092] (1) Switching from PTP transmission to PTM transmission Next, switching from PTP transmission to PTM transmission according to an embodiment will be described.

[0093] In switching from PTP transmission to PTM transmission, the UE 100 transmits to the gNB 200 an SN notification message including at least one of information indicating the SN of the packet first received in the PTM transmission and information indicating the SN of the packet to be last received in the PTP transmission. Then, based on such an SN notification message, the gNB 200 transmits to the UE 100, by PTP transmission, one or more packets (i.e., MBS packets not yet received by the UE 100) corresponding to the SN gap between the PTP transmission and the PTM transmission. This makes it possible to complement the gap that occurs when switching from the PTP transmission to the PTM transmission by the PTP transmission. After completing the PTP transmission of such an unreceived MBS packet, the gNB 200 may stop the PTP transmission (for example, deactivate the PTP leg). Alternatively, when the UE 100 receives the unreceived MBS packet by PTP transmission, the UE 100 may determine that the PTP transmission has ended and deactivate the PTP leg. In this case, the gNB 200 does not need to explicitly deactivate the PTP leg after the PTP transmission ends. The UE 100 autonomously deactivates the PTP leg when the unreceived MBS packet is received by PTP transmission, even if the UE 100 does not receive a deactivation instruction for the PTP leg from the gNB 200. The UE 100 may be allowed to autonomously deactivate the PTP leg when permission for autonomous deactivation of the PTP leg is set in advance by the gNB 200.

[0094] 10 is a diagram showing an example of an operation of switching from PTP transmission to PTM transmission according to an embodiment. In this example of operation, it is assumed that the UE 100 is in an RRC connected state, and a PTP leg is set in the UE 100. However, the PTP bearer may be set in the UE 100 without assuming a split MBS bearer. In other words, it is sufficient that a PTP communication path is set in the UE 100.

[0095] As shown in Fig. 10, in step S101, the gNB 200 transmits MBS data to the UE 100 by PTP transmission via a PTP communication path. The MBS data is composed of multiple packets with consecutive SNs. The UE 100 receives the MBS data via the PTP communication path.

[0096] In step S102, the gNB 200 instructs the UE 100 to receive MBS data by PTM transmission. That is, the gNB 200 transmits a switching instruction from PTP transmission to PTM transmission to the UE 100. This switching instruction is transmitted from the gNB 200 to the UE 100 via a PTP communication path. The UE 100 receives the switching instruction from the gNB 200. Here, the switching instruction from PTP transmission to PTM transmission may be an RRC Reconfiguration message for setting a PTM bearer and / or an instruction for activating a PTM leg (e.g., MAC CE or DCI). The switching instruction from PTP transmission to PTM transmission may be an instruction for deactivating a PTP leg.

[0097] In step S103, the gNB 200 transmits MBS data to the UE 100 by PTM transmission via a PTM communication path (PTM leg or PTM bearer). Note that the PTM transmission may be performed while MBS data transmission is already being performed to another UE. That is, the UE 100 may start receiving the MBS data after a delay from the PTM transmission in which MBS data transmission has already started. The UE 100 receives the MBS data via the PTM communication path. Here, the UE 100 identifies the SN of the packet first received in the PTM transmission by acquiring the SN included in the packet first received via the PTM communication path.

[0098] UE 100 may determine the SN of the last packet to be received in PTP transmission based on the SN of the first packet received in PTM transmission. For example, if the SN of the first packet received in PTM transmission is "#30", the SN of the last packet to be received in PTP transmission should be "#29" to avoid gaps.

[0099] In step S104, UE 100 may determine whether there is an SN gap between PTP transmission and PTM transmission. If the SN of the last packet received in PTP transmission and the SN of the first packet received in PTM transmission are discontinuous, UE 100 detects an SN gap. For example, if the SN of the last packet received in PTP transmission is "#10" and the SN of the first packet received in PTM transmission is "#30", the SNs are discontinuous, and UE 100 detects an SN gap.

[0100] In step S105, UE100 transmits an SN notification message including at least one of information indicating the SN of the packet received first in PTM transmission and information indicating the SN of the packet to be received last in PTP transmission to gNB200 via the PTP communication path. gNB200 receives the SN notification message from UE100 via the PTP communication path. Note that the SN notification message may be transmitted only when permitted by gNB200. For example, UE100 is configured in advance by gNB200 as to whether or not to transmit the SN notification message using RRC Reconfiguration.

[0101] For example, the SN notification message may include the SN of the first packet received in the PTM transmission. The SN notification message may include information indicating each SN from the SN of the last packet received in the PTP transmission to the SN of the first packet received in the PTM transmission.

[0102] Alternatively, the SN notification message may include the SN of the packet that is to be received last in the PTP transmission. The SN notification message may include information indicating each SN from the SN of the packet that is received last in the PTP transmission to the SN of the packet that is to be received last in the PTP transmission. The SN notification message may include the SNs of a plurality of packets corresponding to the gap. For example, if the SN of the packet already received in the PTP transmission is #20 and the SN of the packet first received in the PTM transmission is #30, the UE 100 includes SNs #21 to #29 in the SN notification message.

[0103] If the result of step S104 is "YES", UE100 may transmit an SN notification message to gNB200, and if the result of step S104 is "NO", UE100 may not transmit an SN notification message to gNB200. If the result of step S104 is "NO", UE100 may transmit a PTM reception success notification to gNB200 indicating that a packet has been received by PTM transmission. Note that, when UE100 transmits an SN notification message to gNB200, it may not transmit a PTM reception success notification to gNB200. The PTM reception success notification may be a PTM reception start notification.

[0104] The transmission trigger for the SN notification message may be any of the following: 1) when the first packet is received in PTM transmission, 2) when N (N≧2) consecutive packets are received in PTM transmission, or 3) when an instruction to receive MBS data in PTM transmission (e.g., the instruction in step S102) is received from gNB200. When the transmission trigger is 2) above, the number of packets to be counted (i.e., the value of “N”) may be set in advance by gNB200 to UE100.

[0105] The SN notification message may be any one of 1) a PDCP Control PDU (Protocol Data Unit), 2) an RLC Control PDU, and 3) an RRC message. The PDCP Control PDU used as the SN notification message may be a Status PDU or a new Control PDU. The RLC Control PDU used as the SN notification message may be a Status PDU or a new Control PDU.

[0106] In step S106, the gNB 200 determines whether or not there is an SN gap between the PTP transmission and the PTM transmission, based on the SN notification message received from the UE 100. If the gNB 200 knows the SN of a packet whose transmission in the PTP transmission has been completed, it can determine whether or not there is an SN gap by comparing the SN of the packet whose transmission in the PTP transmission has been completed with the SN indicated by the SN notification message.

[0107] As an example, assume that the SN of a packet that has been completely transmitted by PTP transmission is "#10" and the SN of the first packet received by PTM transmission is "#30". In this case, the gNB 200 compares the SN "#30" included in the SN notification message with the SN "#10" and detects an SN gap since the two are discontinuous. The gNB 200 may decide to transmit packets from SN "#11" to SN "#29" to the UE 100 by PTP transmission.

[0108] As another example, assume that the SN of a packet that has been completely transmitted by PTP transmission is "#10" and the SN of the packet that UE100 wants to receive last by PTP transmission is "#29". In this case, gNB200 compares SN "#29" included in the SN notification message with SN "#10" and detects an SN gap since the two are discontinuous. gNB200 may decide to transmit packets from SN "#11" to SN "#29" to UE100 by PTP transmission.

[0109] If the result of step S106 is "YES", in step S107, the gNB200 transmits one or more packets corresponding to the detected gap (i.e., MBS packets not yet received by the UE100) to the UE100 by PTP transmission. On the other hand, if the result of step S106 is "NO", the gNB200 does not need to execute step S107.

[0110] The UE 100 may receive packets transmitted in such a PTP transmission and, if the gap is filled, may transmit a successful reception notification of the PTM transmission to the gNB 200. As described above, the UE 100 may voluntarily deactivate a PTP leg.

[0111] In step S108, the gNB 200 stops PTP transmission to the UE 100. In the case of a split MBS bearer, the gNB 200 may send a deactivation instruction for the PTP leg to the UE 100. In the case of a non-split MBS bearer, the gNB 200 may send a release instruction for the PTP bearer to the UE 100.

[0112] Here, an example of the SN notification message will be described. Here, a case where the SN notification message is configured by utilizing the Status PDU (PDCP status report) of PDCP will be described. Fig. 11 is a diagram showing an example of the configuration of the SN notification message according to one embodiment.

[0113] As shown in FIG. 11, the PDCP status report has as its main components a 1-bit “D / C” field, a 3-bit “PDU Type” field, a 32-bit “FMC (First Missing COUNT)” field, and a variable-length “Bitmap” field.

[0114] The "D / C" field indicates whether this PDCP PDU is a PDCP Data PDU or a PDCP Control PDU. The PDCP Status Report corresponds to the PDCP Control PDU.

[0115] The "PDU Type" field indicates whether this PDCP Control PDU is a "PDCP status report," "Interspersed ROHC feedback," or "EHC feedback."

[0116] The "FMC (First Missing COUNT)" field indicates the count value (COUNT) of the first missing PDCP SDU in the reordering window. The count value (COUNT) is composed of the HFN (Hyper Frame Number) and the PDCP SN.

[0117] The "Bitmap" field indicates the PDCP SDUs that were lost and those that were correctly received by the receiving PDCP entity. Specifically, the "Bitmap" field indicates the reception status of the PDCP SDUs after the FMC with "0" (missing) or "1" (correctly received).

[0118] When switching from PTP transmission to PTM transmission, the gap between the SN of the last packet received in PTP transmission and the SN of the first packet received in PTM transmission may be reported as the SN of the missing packet (NACK). Also, the FMC may indicate the next packet after the packet already received in PTP transmission. The bitmap may be configured with the upper limit of the bitmap being the packet before the first packet received in PTM transmission.

[0119] (2) Switching from PTM transmission to PTP transmission Next, switching from PTM transmission to PTP transmission according to an embodiment will be described.

[0120] In switching from PTM transmission to PTP transmission, the UE 100 transmits to the gNB 200 an SN notification message including at least one of information indicating the SN of the packet last received in the PTM transmission and information indicating the SN of the packet to be first received in the PTP transmission. The gNB 200 then determines the SN of the packet to be transmitted in the PTP transmission based on the SN notification message. This makes it possible to control the PTP transmission so that no gap occurs when switching from the PTM transmission to the PTP transmission.

[0121] 12 is a diagram showing an example of an operation of switching from PTM transmission to PTP transmission according to an embodiment. In this example of operation, it is assumed that the UE 100 is in an RRC connected state and a PTM leg is set in the UE 100. However, the PTM bearer may be set in the UE 100 without assuming a split MBS bearer. In other words, it is sufficient that a PTM communication path is set in the UE 100.

[0122] As shown in Fig. 12, in step S201, the gNB 200 transmits MBS data to the UE 100 by PTM transmission via a PTM communication path. The MBS data is composed of multiple packets with consecutive SNs. The UE 100 receives the MBS data via the PTM communication path.

[0123] In step S202, the gNB 200 instructs the UE 100 to receive MBS data by PTP transmission. That is, the gNB 200 transmits a switching instruction from PTM transmission to PTP transmission to the UE 100. This switching instruction is transmitted from the gNB 200 to the UE 100 via a PTP communication path or a PTM communication path. The UE 100 receives the switching instruction from the gNB 200. Here, the switching instruction from PTM transmission to PTP transmission may be an RRC Reconfiguration message that sets a PTP bearer and / or an instruction to activate a PTP leg (e.g., MAC CE or DCI). The instruction in step S202 may be an instruction to deactivate a PTM leg. In this case, the UE 100 may stop the reception process of the PTM leg of the split bearer or release the PTM bearer. Furthermore, the UE 100 may temporarily continue the PTM leg reception process or the PTM bearer in order to improve service continuity (that is, after a certain period of time has elapsed, the UE 100 stops the PTM leg reception process or releases the PTM bearer).

[0124] In step S203, the UE 100 transmits an SN notification message including at least one of information indicating the SN of the packet last received in the PTM transmission and information indicating the SN of the packet to be received first in the PTP transmission to the gNB 200 via the PTP communication path. The gNB 200 receives the SN notification message from the UE 100 via the PTP communication path.

[0125] Here, UE 100 may determine the SN of the packet to be received first in PTP transmission based on the SN of the packet received last in PTM transmission. For example, if the SN of the packet received last in PTM transmission is "#15", the SN of the packet to be received first in PTP transmission will be "#16" in order to prevent a gap from occurring.

[0126] The trigger for transmitting the SN notification message may be either 1) when the last packet is received in PTM transmission, or 2) when an instruction to receive MBS data in PTP transmission (e.g., the instruction in step S202) is received from gNB200.

[0127] The SN notification message may be any one of 1) a PDCP Control PDU (Protocol Data Unit), 2) an RLC Control PDU, and 3) an RRC message. The PDCP Control PDU used as the SN notification message may be a Status PDU and / or a new Control PDU. The RLC Control PDU used as the SN notification message may be a Status PDU and / or a new Control PDU.

[0128] In step S204, the gNB 200 determines the SN of a packet to start transmission in PTP transmission based on the SN notification message from the UE 100. As an example, when the SN notification message indicates that the SN of the packet last received in PTM transmission is "#10", the gNB 200 may determine to start PTP transmission from a packet with SN "#11" for the UE 100. As another example, when the SN notification message indicates that the SN of a packet to be received first in PTP transmission is "#11", the gNB 200 may determine to start PTP transmission from a packet with SN "#11" for the UE 100.

[0129] In step S205, the gNB 200 performs PTP transmission to the UE 100 from the packet of the SN determined in step S204 (i.e., transmits MBS data to the UE 100 via a PTP communication path). In the case of a split MBS bearer, the gNB 200 may transmit a deactivation instruction for the PTM leg to the UE 100. In the case of a non-split MBS bearer, the gNB 200 may transmit a release instruction for the PTM bearer to the UE 100.

[0130] (PTM monitor operation) Next, a PTM monitoring operation according to an embodiment will be described. A UE 100 in which a PTM communication path (PTM leg or PTM bearer) is set performs a PTM monitoring operation. As described above, the PTM monitoring operation may be an operation of monitoring a PDCCH to which a G-RNTI associated with an MBS session is applied in a state in which a PTM leg is activated.

[0131] However, since the PTM communication path is mainly used for multicasting to multiple UEs 100, it is difficult to perform individual adaptive control (e.g., adaptive modulation and coding) for each UE 100 according to the radio conditions. For this reason, it is considered that a UE 100 in a poor radio condition cannot normally receive MBS data transmitted by PTM transmission. If such a UE 100 performs a PTM monitoring operation, it wastes power and is inefficient. Therefore, it is preferable for the UE 100 to stop the PTM monitoring operation when the radio conditions become poor.

[0132] In one embodiment, the UE 100 performs a PTM monitoring operation to attempt to receive MBS data transmitted from the gNB 200 via a PTM communication path. In the following, it is assumed that a split MBS bearer is set in the UE 100 and the PTM leg is in an activated state. Such a UE 100 performs a PTM monitoring operation. The UE 100 stops the PTM monitoring operation in response to detecting deterioration of a measurement value indicating the communication quality of the PTM leg.

[0133] In this manner, by UE 100 stopping the PTM monitoring operation in response to detection of deterioration of the measurement value indicating the communication quality of the PTM leg, it is possible to prevent UE 100 from consuming power unnecessarily.

[0134] In addition, the measurement value indicating the communication quality of the PTM leg may be a common measurement value to the measurement value indicating the communication quality of the PTP leg, or may be a measurement value different from the measurement value indicating the communication quality of the PTP leg. PTP If the legs are configured in the same cell, the PTM leg and PTPA common measurement value may be used for the legs. PTP If the legs are configured in separate cells, measurements dedicated to the PTM leg may be used.

[0135] Furthermore, the measurement value indicating the communication quality may be at least one of the RSRP, RSRQ, and SINR of the wireless signal from the gNB 200. The measurement value indicating the communication quality may be a reception error rate of the MBS data and / or the number of consecutive detections of reception errors.

[0136] When the UE 100 stops the PTM monitoring operation, the UE 100 may transmit a notification indicating the stop of the PTM monitoring operation to the gNB 200. This allows the gNB 200 to understand that the UE 100 cannot receive the MBS data transmitted by PTM transmission. For such a UE 100, the gNB 200 may transmit the MBS data by, for example, PTP transmission. In the case of PTP transmission, it is possible to perform individual adaptive control according to the radio condition, so that even a UE 100 in a poor radio condition can receive the MBS data.

[0137] 13 is a diagram showing an example of a PTM monitoring operation according to an embodiment. In this example, it is assumed that the UE 100 is in an RRC connected state and a split MBS bearer is set in the UE 100.

[0138] As shown in FIG. 13, in step S301, the gNB 200 transmits configuration information including a threshold value of the PTM radio condition to the PTM leg or PTP The gNB 200 may transmit the PTM radio state threshold to the UE 100 via the leg. The gNB 200 may set the PTM radio state threshold to the UE 100 by an RRC Reconfiguration message or an SIB. The UE 100 sets the threshold specified by the gNB 200.

[0139] In step S302, the UE 100 starts a PTM monitoring operation and an operation of measuring the communication quality of the PTM leg.

[0140] In step S303, the gNB 200 may transmit the MBS data to the UE 100 by PTM transmission via the PTM leg. The UE 100 may receive the PTM data by a PTM monitoring operation.

[0141] In step S304, the UE 100 compares the measurement value indicating the communication quality of the PTM leg with a threshold value, and determines whether the communication quality of the PTM leg has deteriorated below the threshold value. The communication quality being deteriorated below the threshold value may be that the RSRP, RSRQ, or SINR is below the threshold value, or that the reception error rate or the number of consecutive reception error detections is above the threshold value.

[0142] If the communication quality of the PTM leg has deteriorated below the threshold (step S304: YES), in step S305, the UE 100 stops the monitoring operation of the PTM leg. In this case, in step S306, the UE 100 may transmit a notification indicating the stop of the monitoring operation of the PTM leg to the gNB 200 via the PTP leg. In addition, the UE 100 may transmit the above-mentioned SN notification message to the gNB 200.

[0143] After stopping the monitoring operation of the PTM leg, the UE 100 may continue to measure the RSRP, the RSRQ, or the SINR. When the RSRP, the RSRQ, or the SINR improves, the UE 100 may resume the monitoring operation of the PTM leg. The UE 100 may transmit a notification indicating that the monitoring operation of the PTM leg has been resumed to the gNB 200 via the PTP leg. The UE 100 may also transmit the above-mentioned SN notification message to the gNB 200.

[0144] (Other embodiments) In the above embodiment, an example in which the PTP communication path is configured by the PTP leg and the PTM communication path is configured by the PTM leg using the split MBS bearer has been mainly described. However, the PTP communication path may be configured by the first radio bearer for PTP and the PTM communication path may be configured by the second radio bearer for PTM using two radio bearers (two data radio bearers). In addition, the PTP transmission may be a method of transmitting MBS data from the gNB 200 to the UE 100 using the PTP bearer, which is the first data radio bearer for PTP, as the PTP communication path. The PTM transmission may be a method of transmitting MBS data from the gNB 200 to the UE 100 using the PTM bearer, which is the second data radio bearer for PTM, as the PTM communication path. Under such a premise, the above-mentioned SN notification message may include information indicating an MBS service (or session). The information may be, for example, a TMGI, a Session ID, or a G-RNTI. This makes it easier for gNB200 to understand which MBS bearer the SN notification message corresponds to, even when changing the bearer.

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

[0146] In the above embodiment, an example in which the base station is an NR base station (gNB) has been described, but the base station may be an LTE base station (eNB). The base station may also be a relay node such as an IAB (Integrated Access and Backhaul) node. The base station may also be a DU (Distributed Unit) of the IAB node.

[0147] A program may be provided that causes a computer to execute each process performed by the UE 100 or the gNB 200. The program may be recorded in a computer-readable medium. Using the computer-readable medium, it is possible to install the program in the computer. Here, the computer-readable medium on which the program is recorded may be a non-transient recording medium. The non-transient recording medium is not particularly limited, and may be, for example, a recording medium such as a CD-ROM or a DVD-ROM.

[0148] In addition, circuits that execute 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).

[0149] The above describes the embodiments in detail with reference to the drawings, but the specific configuration is not limited to that described above, and various design changes, etc. are possible without departing from the spirit of the invention.

[0150] This application claims priority to U.S. Provisional Application No. 63 / 164682 (filed March 23, 2021), the entire contents of which are incorporated herein by reference.

[0151] (Appendix 1) (MRB settings (preparation)) The architecture of PDCP anchor PTM / PTP switching can be interpreted as shown in Figure 14, based on the current agreement.

[0152] In general, RRC reconfiguration can be considered to be used to provide a bearer setup including two logical channels (PTM leg and PTP leg) along with information for receiving a multicast session.

[0153] Therefore, in preparation for dynamic PTM / PTP switching, RAN2 must first ensure that RRC reconfiguration provides a configuration to associate the two logical channels with one Multicast Radio Bearer (MRB).

[0154] Before the dynamic PTM / PTP switching operation, RAN2 must ensure that the configuration associating two logical channels with one MRB is provided by RRC reconfiguration.

[0155] Dynamic PTM / PTP switching operation Signaling When an MRB using PTM / PTP is configured, the UE must monitor both the G-RNTI of the PTM leg and the C-RNTI of the PTP leg.

[0156] In LTE SC-PTM, the SC-PTM reception opportunities are independent of the unicast DRX scheme and are separate DRX.

[0157] This concept could become a baseline for NR MBS, since coordinating the two DRXs would be very difficult since the G-RNTI is received by multiple UEs, while the C-RNTI is UE specific.

[0158] This means that if the UE needs to constantly monitor the G-RNTI, the UE will need to wake up frequently, which will result in additional power consumption.

[0159] On the other hand, a UE in CONNECTED state needs to monitor the C-RNTI for unicast reception, i.e., C-DRX, which is not an additional burden for the UE.

[0160] The UE needs to wake up at the PTM leg transmission (i.e., G-RNTI) like the SC-MTCH in LTE SC-PTM, and also at the PTP leg transmission (i.e., C-RNTI), which is the same as when using C-DRX.

[0161] PTM / PTP There are four options for receiving MRBs using: Option 1: Activation / Deactivation based switching The gNB indicates to the UE which leg is to be activated / deactivated by DCI, MAC CE, RRC signaling, etc. The PTM leg and PTP leg are assumed to be associated with the PDCP layer in line with the RAN2 agreement. This option becomes more flexible if MBS data is received over two legs, i.e. split bearer and PDCP packet duplication. The UE can reduce power consumption from the deactivated leg. While deactivation of the PTM leg is beneficial as it allows the UE to skip G-RNTI monitoring, it is unclear whether deactivation of the PTP leg can contribute to power saving in terms of wake-up, i.e. on-duration. The UE needs to monitor the C-RNTI according to C-DRX as long as it is in the RRC connection. Option 2: Switching order / command-based switching The gNB instructs the UE to switch between PTM and PTP legs, for example by DCI, MAC CE or RRC signaling. This option is straightforward and similar to option 1 above. It is the same in that the PTM and PTP legs are associated with the PDCP layer as per the RAN2 agreement and power savings are obtained by deactivating PTM. However, since this option is only for switching between PTM and PTP legs and not for activating both, it does not provide flexibility for split bearer-like operations including duplication of PDCP packets. Option 3: RRC reconfiguration based switching The gNB reconfigures the UE with either PTM or PTP as MRB via RRC reconfiguration, i.e. it does not associate the PTM and PTP legs with one MRB, i.e. it is a kind of "bearer type change" that is not consistent with the RAN2 agreement, since it is unclear how the PDCP anchors these legs during the switchover. There is also a question as to how this option can "dynamically" switch between PTM and PTP. Option 4: No signaling-based switching Whenever an MRB is configured with two legs, the UE should always attempt to receive from both the PTM and PTP legs, which is in line with the RAN2 agreement since the two legs are anchored by PDCP. This option guarantees maximum scheduling flexibility from the gNB perspective, while there is no opportunity to save power from the UE perspective.

[0162] Based on the above observations, option 1 is the most suitable in terms of scheduling flexibility, UE power consumption, and consistency with current agreements.

[0163] Option 4 can be considered a subset of option 1, where the PTM leg is always active.

[0164] Regarding the signaling layer, the MAC CE may be simple since activation / deactivation is mainly related to DRX operation.

[0165] Therefore, RAN2 needs to agree that at least the PTM leg can be activated / deactivated via MAC CE.

[0166] RAN2 needs to agree to introduce a MAC CE to activate / deactivate at least the PTM leg of the MRB for dynamic PTM / PTP switching.

[0167] (introduction) Based on the email discussion "[AT113-e]

[0038] [MBS] Decision on UP Architecture (Chair)", RAN2#113-e proceeded with the design of the L2 architecture with the following agreement:

[0168] When both PTM and PTP are RLC-UM, configuration without L2 ARQ and with PDCP-anchored PTM-PTP switching is supported (e.g. for services normally configured with RLC UM for unicast).

[0169] To our understanding, the reliability of L2 is not guaranteed by the agreement since it relies only on RLC-UM in both the PTP and PTM legs. Therefore, in this contribution, we discuss possible solutions for the reliability of L2.

[0170] (Discussion) ·background The agreement for RAN2#113-e can be represented as in Figure 15. This is similar to the existing split bearer architecture.

[0171] The agreement clearly states that "PTM and PTP are both RLC-UM and are configurations without L2 ARQ". This means that the current architecture does not do RLC-AM nor PDCP retransmissions. Obviously, this architecture cannot contribute to improving L2 reliability. Therefore, a reliable multicast session can only be provided by PTP with RLC-AM (i.e. it cannot be done without the "split bearer" architecture mentioned above). This means that nothing has been improved from traditional unicast transmission, especially in terms of spectral efficiency. Therefore, RAN2 needs to introduce some mechanisms to improve L2 reliability, based on proposal 1 from the email discussion below:

[0172] In case A, the table has the following options: A1: No L2 ARQ for PTM A2: L2 ARQ with PDCP for PTM A3: L2 ARQ with RLC-AM for PTM In case B, the table has the following options: B1: PDCP anchored PTM / PTP switching B2: RLC anchored PTM / PTP switching

[0173] Proposal 1: Discussion on whether to support any of the following: · A1+B1 of PTM RLC-UM+PTP RLC-AM may have some data recovery during the switching procedure. ·PTM RLC-UM+PTP RLC-AM A2+B1 ·A3+B2(+B1) of PTM RLC-AM+PTPRLC-AM

[0174] At this point, a reliable multicast session cannot be set up without the currently agreed PTM-PTP "split bearer" architecture, i.e. PDCP anchor, RLC-UM and L2 ARQ, but due to L2 reliability constraints it can only be provided by PTP with RLC-AM, i.e. a single RLC.

[0175] RAN2 needs to introduce additional mechanisms to improve the reliability of L2.

[0176] A1+B1 in PTM RLC-UM+PTP RLC-AM will likely involve some data recovery in the switching procedure.

[0177] This option can be interpreted as shown in Figure 16.

[0178] It is assumed that the reliability of L2 is guaranteed only by the PTP leg. For example, when the radio conditions deteriorate, data reception switches from the PTM leg to the PTP leg. In other words, the PTM leg can be used only when the radio conditions are good and stable.

[0179] For the A1+B1 option, the reliability of L2 is guaranteed by the PTP leg, while the PTM leg can only be used when the radio conditions are good and stable. This option has limited impact within the PDCP layer, since it is assumed that the existing RLC functionality can be reused, i.e. AM mode for the PTP leg and UM mode for the PTM leg.

[0180] For the A1+B1 option, the PDCP specifications are affected, but the RLC specifications are not expected to be affected.

[0181] As indicated in the option name, i.e. "Some type of data recovery in switchover procedure", This option , is assumed to be based on the current PDCP status report sent during the switchover procedure. It is clear that the PDCP status report can be sent via the PTP leg instead of the PTM leg.

[0182] In the current PDCP specification, a receiving PDCP entity triggers a PDCP status report as follows:

[0183] In case of an AMDRB configured by higher layers to send PDCP status reports in the UL (statusReportRequired in TS 38.331), the receiving PDCP entity shall trigger a PDCP status report in the following cases: - Upper layer requests re-establishment of the PDCP entity Upper layer requests PDCP data recovery Upper layer requests UL data switch · Higher layers reconfigure the PDCP entity to release DAPS and daps-SourceRelease as specified in TS 38.331.

[0184] Regarding the first condition, i.e. “higher layers request re-establishment of the PDCP entity”, a single PDCP entity in the gNB cannot simply re-establish a PDCP entity for an MRB (Multicast Radio Bearer) since it is established with multiple UEs, regardless of whether it is associated with a PTP leg or a PTM leg.

[0185] Regarding the second condition, i.e. "higher layers request PDCP data recovery", this is related to PDCP data recovery procedures related to UL retransmissions such as handover, etc. Therefore, it is not related to NR MBS since there is only DL data transmission.

[0186] Regarding the third and fourth conditions, i.e. "higher layers request UL data switching" and "higher layers reconfigure the PDCP entity to release configured DAPS and daps-SourceRelease", these are related to DAPS handover, therefore they are not used for PTM / PTP switching.

[0187] Based on the above observations, the existing conditions cannot be used for data recovery during PTM / PTP switching. Therefore, a new trigger condition is needed to send the PDCP status report. The new trigger condition could be the first packet received over the activated leg, e.g., the PTP leg in case of PTM / PTP switching, rather than at the time of switching.

[0188] For the A1+B1 option, new trigger conditions may be needed to send a PDCP status report (or a new PDCP control PDU for feedback) during PTM / PTP switching. The PDCP status report is configured with an FMC indicating the First Missing COUNT and optionally a bitmap indicating per bit position if the next PDCP SDU was correctly received or missing. Our understanding is that it could be reused for this option, but does not preclude introducing a new PDCP control PDU for feedback at this time.

[0189] For the A1+B1 option, the existing PDCP status report format can be reused.

[0190] PTM RLC-UM+PTP RLC-AM A2+B1 This option can be interpreted as shown in Figure 17.

[0191] It is conceivable to use either the PTM leg or the PTP leg to compensate for packets missing from the PTM leg, which improves spectral efficiency compared to the A1+B1 option above, since the PTM leg can be used even when radio conditions are relatively poor and / or unstable.

[0192] In the case of the A2+B1 option, the reliability of L2 can be guaranteed by the PTP leg assistance, so that the PTM leg can be used even in relatively poor and unstable radio conditions. As with the A1+B1 option above, this option is not expected to affect the RLC layer, so its impact on the specification is limited within the PDCP layer.

[0193] For the A2+B1 option, the PDCP specification is affected but the RLC specification is expected to be unaffected. A2 intends "L2 ARQ with PDCP for PTM" as shown in Figure 17, but the existing ARQ functionality is in the RLC layer but not in the PDCP layer. Therefore, it is clear that a new ARQ functionality is required in the PDCP specification.

[0194] For the A2+B1 option, a new ARQ function needs to be specified in the PDCP layer. This can be considered as the baseline ARQ function in the RLC specification. For example, the procedure is described in Section 5.3. 、S The STATUS PDU format is described in 6.2.2.5. This is an ACK / NACK type ARQ mechanism, and feedback is sent via the STATUS PDU.

[0195] In the current RLC specification, a STATUS PDU is triggered by two conditions:

[0196] An AM RLC entity transmits a status PDU to a peer AMRLC entity to provide positive and / or negative acknowledgment of an RLC SDU (or part of them). The triggers to initiate a status report are: Polling from peer AMRLC entities - Detection of AMDPDU reception failure

[0197] Regarding the first condition, i.e. “polling from an equivalent AM RLC entity”, it can be reused since the gNB may send polls to one or multiple UEs, but it may be necessary to add a polling bit (P) field to the PDCP data PDU.

[0198] Regarding the second condition, i.e. "detection of AMD PDU reception failure", the concept can be reused since the UE may detect PDCP reception failure in some way. Currently, it is detected by RLC when t-Reassembly expires, but a discussion may be needed on how to detect reception failure in PDCP. If the RLC ARQ mechanism is reused, the same optimizations are expected in the following A3+B2 options, e.g. additional conditions forcing the reception window to move.

[0199] For the A2+B1 option, the RLC ARQ mechanism, including the format of the STATUS PDU, can be the baseline for PDCP ARQ, but some details, such as how reception failure is detected, need to be changed. Another possibility is to consider a new, non-intrusive ARQ mechanism, which can be seen as a kind of NACK-only ARQ mechanism. In this case, the current PDCP status report could be the baseline, assuming that only FMC is reported. As with the A1+B1 option above, new trigger conditions are needed for the PDCP status report (or a new PDCP control PDU). Also, as with the RLC ARQ baseline above, some discussion needs to be done on how reception failure is detected and / or how the reception window is managed if introduced.

[0200] For the A2+B1 option, the PDCP status report (or a new PDCP control PDU for feedback) can be another baseline for the PDCP ARQ, but new trigger conditions and associated actions may need to be specified, such as how to detect reception impairments and / or how to manage the reception window.

[0201] A3+B2(+B1) of PTM RLC-AM+PTP RLC-AM This option can be interpreted as shown in Figure 18.

[0202] Similar to the A2+B1 option above, it can be considered to use either the PTM leg or the PTP leg to make up for packets missing from the PTM leg. The PTM leg can be used even when the radio conditions are relatively poor and / or unstable, improving the spectral efficiency compared to the A1+B1 option above. Furthermore, retransmissions can be performed per RLC segment, which is different from the A2+B1 option above, which performs retransmissions per PDCP SDU. Therefore, this option can be considered the best performing among the candidate options in terms of spectral efficiency.

[0203] In the case of the A3+B2 option, the reliability of L2 can be guaranteed by PTP leg support, so that the PTM leg can be used even when the radio conditions are relatively poor and unstable.

[0204] In the case of the A3+B2 option, retransmissions can be performed for each RLC segment. Unlike the other options, the PTP leg and the PTM leg are anchored at the RLC layer. Therefore, this option does not fundamentally affect the PDCP specification, except for the A1+B1 option mentioned above, which depends on whether it is used with this option. That is, the same effect may be expected in the PDCP specification in this case.

[0205] For the A3+B2 option, the PDCP specifications are not expected to be affected, but will depend on whether other options are used together.

[0206] The main impact can be considered as being introduced in the RLC specification. However, at least for ARQ, no impact (or only minor) is expected, since it mainly depends on the gNB implementation. In fact, if all UEs can receive all the last missing RLC PDUs in time, it is also possible to simply reuse the existing ARQ, since there are no problems with the reception window. Since retransmissions can be performed via the PTP leg in addition to the PTM leg, the PTP leg can be considered reliable enough since it is a fundamental assumption for other options related to B1. However, some new conditions are proposed to force the reception window (RX_Next) to move in case of an error.

[0207] For the A3+B2 option, the RLC specifications are expected to be unaffected (or only slightly affected). (summary) The results of the findings are summarized in FIG.

[0208] It is clear that the A2+B1 option has less merits than the other options, namely A1+B1 and A3+B2. The A3+B2 option can be considered the best approach, while RAN2 has the following caveat: "Operational assumption: RLC-AM for PTM is not supported (this could be reconsidered, but for this to change, proponents of RLC-AM for PTM would need to demonstrate a need)," which needs to be reconsidered from the perspective of technical reasons.

[0209] RAN2 needs to agree to deploy A1+B1 (i.e., PDCP anchor and data recovery during switching) and / or A3+B2 (i.e., RLC anchor and RLC AM for PTM).

Claims

1. A communication control method used in a mobile communication system that provides a multicast broadcast service (MBS) from a base station to a user device, comprising: The user device receives MBS data transmitted from the base station using any one of a PTP (Point-to-Point: unicast) transmission and a PTM (Point-to-Multipoint: multicast or broadcast) transmission method; In response to the transmission method being switched between the PTP transmission and the PTM transmission, the user equipment transmits a message to the base station, the message including information indicating a sequence number of a received packet related to the switching; If the switching is a switching from the PTP transmission to the PTM transmission, transmitting the message includes transmitting the message after receiving MBS data in the PTM transmission; The message includes at least one of information indicating a sequence number of a packet received first in the PTM transmission and information indicating a sequence number of a packet to be received last in the PTP transmission. Communications control method.

2. Transmitting the message includes transmitting the message in response to the user equipment detecting a gap in sequence numbers between the PTP transmission and the PTM transmission. The communication control method according to claim 1 .

3. The method further includes transmitting, based on the message, one or more packets in the PTP transmission to the user device corresponding to a gap in sequence numbers between the PTP transmission and the PTM transmission. The communication control method according to claim 1 .

4. If the switching is a switching from the PTM transmission to the PTP transmission, The message includes at least one of information indicating a sequence number of a packet received last in the PTM transmission and information indicating a sequence number of a packet to be received first in the PTP transmission. The communication control method according to claim 1 or 2.

5. The base station further includes determining a sequence number of a start packet of transmission in the PTP transmission based on the message. The communication control method according to claim 4.

6. A processor for executing the communication control method according to claim 1 User equipment.

Images