Communication control method, user equipment, chip set, program, and mobile communication system

Abstract

To provide a communication control method and user equipment for achieving an improved multicast broadcast service (MBS).SOLUTION: A method for use in a mobile communication system that provides a multicast broadcast service (MBS) from a base station gNB to user equipment UE includes: receiving, by the user equipment, MBS data transmitted from the base station through a transmission scheme of either PTP transmission or PTM transmission; and transmitting, by the user equipment in response to switching of the transmission scheme between the PTP transmission and the PTM transmission, a message that includes information indicating a sequence number of a received packet related to the switching, to the base station.SELECTED DRAWING: Figure 13

Description

Technical Field

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

Background Art

[0002] In recent years, the fifth-generation (5G) mobile communication system has attracted attention. NR (New Radio), which is a radio access technology (RAT) of the 5G system, has characteristics such as high speed, large capacity, high reliability, and low latency compared to LTE (Long Term Evolution), which is a fourth-generation radio access technology.

Prior Art Documents

Non-Patent Documents

[0003]

Non-Patent Document 1

Summary of the Invention

[0004] The communication control method according to the 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 user device receiving MBS data transmitted from the base station by either a PTP transmission or a PTM transmission; and in response to the transmission method being switched between the PTP transmission and the PTM transmission, the user device transmitting a message including information indicating a sequence number of a received packet related to the switch to the base station.

[0005] The communication control method according to the 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 equipment. The communication control method includes: the user equipment performing a PTM monitoring operation of attempting to receive MBS data transmitted from the base station via a PTM communication path; and the user equipment stopping the PTM monitoring operation in response to detecting a deterioration in a measurement value indicating the communication quality of the PTM communication path.

[0006] The user equipment according to the third aspect includes a processor that executes the communication control method according to the first or second aspect.

Brief Description of Drawings

[0007]

Figure 1

Figure 2

Figure 3

Figure 4

Figure 5

Figure 6

Figure 7

Figure 8

Figure 9

Figure 10

Figure 11

Figure 12

Figure 13

Figure 14

Figure 15

Figure 16

Figure 17

Figure 18

Figure 19

Mode for Carrying Out the Invention

[0008] It is considered to introduce a multicast / broadcast service into a 5G system (NR). The multicast / broadcast service of NR is desired to provide a service improved from the multicast / broadcast service of LTE.

[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] With reference to the drawings, a mobile communication system according to an embodiment will be described. In the description of the drawings, the same or similar parts are denoted by the same or similar reference numerals.

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

[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 movable wireless communication device. The UE 100 can be any device used by a user. For example, the UE 100 can be 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 on the sensor, a vehicle or a device provided on the vehicle (Vehicle UE), and / or an aircraft or a device provided on the aircraft (Aerial UE).

[0014] NG-RAN 10 includes base stations (referred to as "gNB" in the 5G system) 200. The gNBs 200 are interconnected via the 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 cell. The gNB 200 has functions such as a radio resource management (RRM) function, a routing function for user data (hereinafter simply referred to as "data"), and a measurement control function for mobility control and scheduling. "Cell" is used as a term indicating the smallest unit of a wireless communication area. "Cell" is also used as a term indicating a function or resource for performing wireless communication with the UE 100. One cell belongs to one carrier frequency.

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

[0016] The 5GC 20 includes an AMF (Access and Mobility Management Function) and a UPF (User Plane Function) 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 NAS (Non-Access Stratum) signaling. The UPF performs transfer control of data. The AMF and the UPF are connected to the gNB 200 via the NG interface, which is an interface between the base station and the core network.

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

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

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

[0020] The transmitting unit 120 performs various transmissions under the control of the control unit 130. The transmitting unit 120 includes an antenna and a transmitter. The transmitter converts the baseband signal (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 for the processing by the processor. The processor may include a baseband processor and a CPU (Central Processing Unit). The baseband processor performs modulation / demodulation and encoding / decoding of the baseband signal, etc. The CPU executes the programs stored in the memory to perform various processes.

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

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

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

[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 the radio signal received by the antenna into a baseband signal (received signal) and outputs it 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 for 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, etc. The CPU executes programs stored in the memory to perform various processes.

[0027] The backhaul communication unit 240 is connected to an adjacent base station via a 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., functionally split), and the two units may be connected by 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 radio interface protocol of the user plane has a physical (PHY) layer, a MAC (Medium Access Control) layer, an RLC (Radio Link Control) layer, a PDCP (Packet Data Convergence Protocol) layer, and an SDAP (Service Data Adaptation Protocol) layer.

[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 functions such as prioritized control of data, retransmission processing by Hybrid ARQ (HARQ), and random access procedures. Between the MAC layer of UE100 and the MAC layer of gNB200, data and control information are transmitted via transport channels. The MAC layer of gNB200 includes a scheduler. The scheduler determines the transport format (transport block size, modulation and coding scheme (MCS)) for the uplink and downlink and the resource blocks allocated to UE100.

[0032] The RLC layer uses the functions of the MAC layer and the PHY layer to transmit data to the RLC layer on the receiving side. Between the RLC layer of UE100 and the RLC layer of gNB200, data and control information are transmitted via logical channels.

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

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

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

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

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

[0038] The NAS layer located above the RRC layer performs session management, mobility management, etc. NAS signaling is transmitted between the NAS layer of UE100 and the NAS layer of AMF300B.

[0039] Note that UE100 has an application layer, etc., in addition to the protocol of the radio interface.

[0040] (MBS) Next, the MBS according to an embodiment will be described. MBS is a service that enables the NG-RAN10 to transmit data to UE100 by broadcast or multicast, that is, one-to-many (PTM: Point To Multipoint). MBS may be called MBMS (Multimedia Broadcast and Multicast Service). Note that the use cases (service types) of MBS include public security communication, mission-critical communication, V2X (Vehicle to Everything) communication, IPv4 or IPv6 multicast distribution, IPTV, group communication, and software distribution, etc.

[0041] In LTE, there are two types of MBS transmission methods: MBSFN (Multicast Broadcast Single Frequency Network) transmission and SC-PTM (Single Cell Point To Multipoint) transmission. FIG. 6 is a diagram showing the correspondence between the downlink logical channel and transport channel according to an 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 Channel). MBSFN transmission is mainly designed for multi-cell transmission, and in an MBSFN area composed of multiple cells, each cell synchronously transmits the same signal (same data) in the same MBSFN subframe.

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

[0044] In the following, an example of providing MBS using a method similar to the SC-PTM transmission method will be mainly described, but MBS may be provided using the MBSFN transmission method. Also, an example of providing MBS by multicast will be mainly described. For this reason, MBS may be read as multicast. However, MBS may be provided by broadcast.

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

[0046] The network can provide different MBS services for each MBS session. An MBS session is identified by at least one of the TMGI (Temporary Mobile Group Identity) and the session identifier, and at least one of these identifiers is called the MBS session identifier. Such an MBS session identifier may also 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 a plurality of UEs. The 5G CN (5GC) 20, which is a 5G core network, receives MBS data from the application service provider, creates (Replication) copies of the MBS data, and distributes them.

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

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

[0051] The MBS connection may also be referred to as a Shared MBS Traffic delivery connection or a shared transport. The MBS connection terminates at NG-RAN10 (i.e., gNB200). The MBS connection may correspond one-to-one with an MBS session.

[0052] gNB200 selects either a 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 Individual MBS Traffic delivery, a unicast session is established between NG-RAN10 and UE100, and MBS data is individually delivered from 5GC20 to UE100. Such a unicast may also be referred to as a PDU session. The unicast (PDU session) terminates at UE100.

[0054] (Split MBS bearer) Next, the split MBS bearer according to an embodiment will be described.

[0055] gNB200 can set up for UE100 an MBS bearer (hereinafter, appropriately referred to as a "split MBS bearer") separated into a PTP communication path and a PTM communication path. Thereby, gNB200 can dynamically switch the transmission of MBS data to UE100 between PTP (PTP communication path) and PTM (PTM communication path). Alternatively, gNB200 can enhance reliability by simultaneously transmitting the same MBS data redundantly 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 where 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] FIG. 8 is a diagram showing a split MBS bearer according to an embodiment. In the following, the PTP communication path is referred to as a PTP leg, and the PTM communication path is referred to as a PTM leg. Also, a functional unit corresponding to each layer is referred to as an entity.

[0058] As shown in FIG. 8, each of the PDCP entity of gNB200 and the PDCP entity of UE100 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 gNB200 and UE100 has two RLC entities provided for each leg, one MAC entity, and one PHY entity. The PHY entity may be provided for each leg. Note that in the case of dual connectivity where UE100 communicates with two gNB200s, UE100 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 UE100. 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 UE100, but the G-RNTI is a common RNTI for multiple UE100s that receive one MBS session.

[0061] In order for the gNB200 to perform PTM transmission (multicast or broadcast) of MBS data to the UE100 using the PTM leg, a split MBS bearer must be set up from the gNB200 to the UE100 and the PTM leg must be activated. In other words, even if a split MBS bearer is set up from the gNB200 to the UE100, the gNB200 cannot perform PTM transmission of MBS data using this PTM leg if the PTM leg is in the deactivated state.

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

[0063] When the PTM leg is activated, UE100 monitors a Physical Downlink Control Channel (PDCCH) to which a G-RNTI associated with an MBS session is applied (i.e., performs blind decoding of the PDCCH using the G-RNTI). UE100 may monitor the PDCCH only during the scheduling opportunity of the MBS session.

[0064] When the PTM leg is deactivated, UE100 does not monitor a PDCCH to which a G-RNTI associated with an MBS session is applied (i.e., does not perform blind decoding of the PDCCH using the G-RNTI).

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

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

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

[0068] (Activation and Deactivation of Legs) Next, the activation and deactivation of legs according to an embodiment will be described. FIG. 9 is a diagram showing an operation example related to the activation and deactivation of legs according to an embodiment.

[0069] As shown in FIG. 9, in step S11, the RRC entity of gNB200 transmits an RRC message including the setting of the split MBS bearer (split bearer) shown in FIG. 8 to UE100. The RRC message is, for example, an RRC Reconfiguration message. The RRC entity of UE100 establishes a split MBS bearer based on the setting included in the RRC message received from gNB200. Hereinafter, an example in which there is one split MBS bearer established by UE100 will be mainly described, but UE100 may establish a plurality of split MBS bearers according to the setting from gNB200.

[0070] When performing bearer setting in an RRC message (RRC Reconfiguration message), gNB200 may instruct UE100 of the initial state of each leg (that is, activation or deactivation of each leg) in the same message. When the RRC entity of gNB200 transmits an RRC message including the bearer setting of the split MBS bearer to UE100, it includes an instruction for activation or deactivation of each leg in the RRC message together with the bearer setting.

[0071] Such an RRC message may include at least one of an identifier of a leg (PTP leg, PTM leg) to be instructed and an identifier indicating either activation or deactivation. The RRC message may include an identifier (for example, 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 individually activate or deactivate the PTP leg and the PTM leg.

[0073] Here, the MAC entity of gNB200 may send a MAC control element (MAC CE) containing the instruction to UE100. The MAC entity of UE100 receives the MAC CE from gNB200. Alternatively, the PHY entity of gNB200 may send downlink control information (DCI) containing the instruction to UE100. The PHY entity of UE100 receives the DCI from gNB200.

[0074] Such a MAC CE or DCI may include at least one of an identifier of the leg (PTP leg, PTM leg) targeted by the instruction 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) targeted by the instruction.

[0075] By using the MAC CE or DCI to instruct the activation and deactivation of each leg, dynamic control is possible compared to the case of using RRC messages.

[0076] Upon receiving an instruction to activate the PTP leg, UE100 starts receiving data using C-RNTI. Upon receiving an instruction to activate the PTM leg, UE100 starts receiving MBS data using G-RNTI. On the other hand, upon receiving an instruction to deactivate the PTP leg, UE100 ends receiving data using C-RNTI. Upon receiving an instruction to deactivate the PTM leg, UE100 ends receiving MBS data using G-RNTI.

[0077] In step S12, gNB200 may transmit (PTM transmission) to UE100 an instruction to activate or deactivate the PTP leg via the PTM leg in the activated state. Thereby, the PTP legs of multiple UEs 100 can be collectively activated or deactivated by PTM.

[0078] gNB200 may transmit (PTM transmission) to UE100 an instruction to deactivate the PTM leg via the PTM leg in the activated state. Thereby, the PTM legs of multiple UEs 100 can be collectively deactivated by PTM.

[0079] In step S12, gNB200 may transmit (PTP transmission) to UE100 an instruction to activate or deactivate the PTM leg via the PTP leg in the activated state. Thereby, the PTM leg can be individually activated or deactivated for each UE100.

[0080] gNB200 may transmit (PTP transmission) to UE100 an instruction to deactivate the PTP leg via the PTP leg in the activated state. Thereby, the PTP leg can be individually deactivated for each UE100.

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

[0082] In response to receiving the response from UE100, gNB200 transmits data via the activated leg. That is, after receiving the response, gNB200 starts the data transmission operation on that leg.

[0083] Note that UE100 may transmit a response to the received instruction to gNB200 in response to receiving an instruction from gNB200 in step S12 to deactivate at least one of the PTP leg and the PTM leg.

[0084] When both the PTP leg and the PTM leg are activated, the PDCP entity of UE100 may perform duplicate packet discarding processing on two identical MBS packets transmitted by duplication.

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

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

[0087] In the case of assuming a split MBS bearer, PTP transmission may be a method of transmitting MBS data from gNB200 to UE100 using a PTP leg (PTP communication path). PTM transmission may be a method of transmitting MBS data from gNB200 to UE100 using a PTM leg (PTM communication path). The switching operation between PTP transmission and PTM transmission may be an operation of starting the MBS data transmission of the other transmission method simultaneously with the end of the MBS data transmission of one of the PTP transmission and PTM transmission. During such a switch, MBS data (MBS packets) transmitted from gNB200 to UE100 may be lost and a gap may occur.

[0088] Also, when switching from PTP transmission to PTM transmission, there is a problem of when gNB200 stops PTP transmission. Conversely, when switching from PTM transmission to PTP transmission, there is a problem of from which packet gNB200 starts PTP transmission. That is, 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, UE100 receives MBS data transmitted from gNB200 by either PTP transmission or PTM transmission. Then, in response to the transmission method being switched between PTP transmission and PTM transmission, UE100 transmits a message (hereinafter referred to as an "SN notification message") including information indicating the sequence number (SN) of the received packets regarding the switch to gNB200. The SN may be a PDCP SN assigned in units of PDCP packets. The SN may be a COUNT value for identifying a PDCP packet. The COUNT value is composed of an HFN (Hyper Frame Number) and a PDCP SN. The SN may be an RLC SN assigned in units of RLC packets. Hereinafter, it is mainly assumed that the SN is a PDCP SN. For this reason, a packet refers to a PDCP packet.

[0090] By transmitting, from the UE 100 to the gNB 200, an SN notification message including SN information of received packets related to the switching between PTP transmission and PTM transmission in this way, the gNB 200 can grasp the reception state of MBS packets in the UE 100. Therefore, it becomes possible to appropriately control PTP transmission when switching between PTP transmission and PTM transmission. For example, the gNB 200 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 PTP transmission packets and the SN of PTM transmission packets.

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

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

[0093] In the process of switching from PTP transmission to PTM transmission, UE 100 sends a SN notification message including at least one of the information indicating the SN of the packet first received in PTM transmission and the information indicating the SN of the packet that UE 100 desires to receive last in PTP transmission to gNB 200. Then, based on such a SN notification message, gNB 200 sends one or more packets corresponding to the SN gap between PTP transmission and PTM transmission (i.e., MBS packets not received by UE 100) to UE 100 in PTP transmission. Thereby, the gap generated during the switching from PTP transmission to PTM transmission can be complemented by PTP transmission. After finishing the PTP transmission of such non-received MBS packets, gNB 200 may stop the PTP transmission (for example, deactivate the PTP leg). Alternatively, when UE 100 receives the non-received MBS packets in PTP transmission, UE 100 may determine that the PTP transmission has ended and deactivate the corresponding PTP leg. In this case, gNB 200 does not need to explicitly deactivate the PTP leg after the end of PTP transmission. Even if UE 100 does not receive the PTP leg deactivation instruction from gNB 200, UE 100 may spontaneously deactivate the PTP leg when receiving the non-received MBS packets in PTP transmission. UE 100 may be allowed to spontaneously deactivate the PTP leg if the spontaneous deactivation of the PTP leg is previously set by gNB 200.

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

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

[0096] In step S102, gNB 200 instructs UE 100 to receive MBS data by PTM transmission. That is, gNB 200 transmits a switching instruction from PTP transmission to PTM transmission to UE 100. This switching instruction is assumed to be transmitted from gNB 200 to UE 100 via the PTP communication path. UE 100 receives the switching instruction from 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, gNB 200 transmits MBS data to UE 100 by PTM transmission via a PTM communication path (PTM leg or PTM bearer). It should be noted that the PTM transmission may already be performing MBS data transmission to another UE. That is, UE 100 may start receiving late for a PTM transmission in which MBS data transmission has already started. UE 100 receives the MBS data via the PTM communication path. Here, UE 100 specifies the SN of the first packet received by PTM transmission by obtaining the SN included in the first packet received via the PTM communication path.

[0098] UE100 may determine the SN of the packet that it desires to receive last in PTP transmission based on the SN of the packet that it receives first in PTM transmission. For example, if the SN of the packet that is received first in PTM transmission is "#30", then in order to avoid a gap, the SN of the packet that is desired to be received last in PTP transmission would be "#29".

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

[0100] In step S105, UE100 transmits an SN notification message including at least one of the information indicating the SN of the packet that is received first in PTM transmission and the information indicating the SN of the packet that it desires to receive 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 it is permitted by gNB200. For example, UE100 has the transmission permission of the SN notification message set in advance from gNB200 using RRC Reconfiguration.

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

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

[0103] When the result in step S104 is “YES”, UE100 may send the SN notification message to gNB200, and when the result in step S104 is “NO”, UE100 may not need to send the SN notification message to gNB200. When the result in step S104 is “NO”, UE100 may send a PTM reception success notification indicating that a packet has been received in PTM transmission to gNB200. Note that when UE100 sends the SN notification message to gNB200, it may not need to send the PTM reception success notification to gNB200. The PTM reception success notification may be a PTM reception start notification.

[0104] The transmission trigger of the SN notification message may be any one of 1) when the first packet is received in PTM transmission, 2) when N (N≥2) consecutive packets are received in PTM transmission, and 3) when an instruction to receive MBS data in PTM transmission (for example, the instruction in step S102) is received from gNB200. When using 2) as the transmission trigger, the number of packets to be counted (that is, the value of “N”) may be set in advance from gNB200 to UE100.

[0105] The SN notification message may be any one of 1) PDCP Control PDU (Protocol Data Unit), 2) RLC Control PDU, and 3) 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 there is an SN gap between PTP transmission and PTM transmission based on the SN notification message received from the UE 100. If the gNB 200 knows the SN of the packet whose transmission in PTP transmission has been completed, it can determine the presence or absence of the SN gap by comparing the SN of the packet whose transmission in PTP transmission has been completed with the SN indicated by the SN notification message.

[0107] As an example, assume that the SN of the packet whose transmission in PTP transmission has been completed is "#10" and the SN of the first packet received in 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 since the two are discontinuous, it detects the SN gap. The gNB 200 may decide to transmit the packets from SN "#11" to SN "#29" to the UE 100 in PTP transmission.

[0108] As another example, assume that the SN of the packet whose transmission in PTP transmission has been completed is "#10" and the SN of the packet that the UE 100 wants to receive last in PTP transmission is "#29". In this case, the gNB 200 compares the SN "#29" included in the SN notification message with the SN "#10", and since the two are discontinuous, it detects the SN gap. The gNB 200 may decide to transmit the packets from SN "#11" to SN "#29" to the UE 100 in PTP transmission.

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

[0110] UE100 receives the packets transmitted by such PTP transmission, and when the gap is filled, UE100 may send a reception success notification of PTM transmission to gNB200. As described above, UE100 may spontaneously deactivate the PTP leg.

[0111] In step S108, gNB200 stops the PTP transmission to UE100. In the case of a split MBS bearer, gNB200 may send an instruction to deactivate the PTP leg to UE100. In the case of not a split MBS bearer, gNB200 may send an instruction to release the PTP bearer to UE100.

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

[0113] As shown in FIG. 11, the PDCP status report mainly includes a 1-bit "D / C" field, a 3-bit "PDU Type" field, a 32-bit "FMC (First Missing COUNT)" field, and a variable-bit "Bitmap" field.

[0114] The "D / C" field is a field indicating whether this PDCP PDU is a PDCP Data PDU or a PDCP Control PDU. The PDCP status report corresponds to a PDCP Control PDU.

[0115] The "PDU Type" field is a field indicating whether this PDCP Control PDU is any of "PDCP status report", "Interspersed ROHC feedback", and "EHC feedback".

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

[0117] The "Bitmap" field is a field indicating the missing PDCP SDUs and the PDCP SDUs correctly received by the receiving PDCP entity. Specifically, the "Bitmap" field indicates the reception status of the PDCP SDUs after FMC as "0" (missing) or "1" (correctly received).

[0118] Regarding the switch 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, FMC may indicate the packet next to the packet already received in PTP transmission. The upper limit of the Bitmap may be configured with the packet before the first packet received in PTM transmission as the Bitmap.

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

[0120] In the switch from PTM transmission to PTP transmission, the UE 100 transmits an SN notification message including at least one of information indicating the SN of the packet last received in PTM transmission and information indicating the SN of the packet that the UE 100 desires to receive first in PTP transmission to the gNB 200. Then, the gNB 200 determines the SN of the transmission start packet in PTP transmission based on such an SN notification message. Thereby, PTP transmission can be controlled so that no gap occurs during the switch from PTM transmission to PTP transmission.

[0121] FIG. 12 is a diagram showing an operation example of the switch from PTM transmission to PTP transmission according to an embodiment. In this operation example, it is assumed that the UE 100 is in the RRC connected state and the PTM leg is set to the UE 100. However, the PTM bearer may be set to the UE 100 without assuming a split MBS bearer. That is, it is sufficient that a PTM communication path is set to 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 the PTM communication path. The MBS data is composed of a plurality of packets with consecutive SNs. The UE 100 receives the MBS data via the PTM communication path.

[0123] In step S202, gNB200 instructs UE100 to receive MBS data via PTP transmission. That is, gNB200 sends a switching instruction from PTM transmission to PTP transmission to UE100. This switching instruction is assumed to be sent from gNB200 to UE100 via the PTP communication path or the PTM communication path. UE100 receives the switching instruction from gNB200. Here, the switching instruction from PTM transmission to PTP transmission may be an RRC Reconfiguration message for setting up a PTP bearer and / or an instruction for activating a PTP leg (e.g., MAC CE or DCI). The instruction in step S202 may also be an instruction for deactivating the PTM leg. In this case, UE100 may stop receiving the PTM leg of the split bearer or release the PTM bearer. Alternatively, UE100 may temporarily continue receiving the PTM leg or the PTM bearer to enhance service continuity (i.e., after a certain period of time, UE100 stops receiving the PTM leg or releases the PTM bearer).

[0124] In step S203, UE100 sends an SN notification message including at least one of information indicating the SN of the packet last received via PTM transmission and information indicating the SN of the packet that UE100 desires to receive first via PTP transmission to gNB200 via the PTP communication path. gNB200 receives the SN notification message from UE100 via the PTP communication path.

[0125] Here, UE100 may determine the SN of the packet that UE100 desires to receive first via PTP transmission based on the SN of the packet last received via PTM transmission. For example, if the SN of the packet last received via PTM transmission is "#15", then in order to avoid a gap, the SN of the packet that UE100 desires to receive first via PTP transmission would be "#16".

[0126] The transmission trigger of 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 (for example, 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, or 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, based on the SN notification message from UE100, gNB200 determines the SN of the transmission start packet in PTP transmission. As an example, if the SN notification message indicates that the SN of the last received packet in PTM transmission is "#10", gNB200 may determine to start PTP transmission from the packet with SN "#11" to UE100. As another example, if the SN notification message indicates that the SN of the packet to be received first in PTP transmission is "#11", gNB200 may determine to start PTP transmission from the packet with SN "#11" to UE100.

[0129] In step S205, gNB200 performs PTP transmission to UE100 from the packet with the SN determined in step S204 (that is, transmits MBS data to UE100 via the PTP communication path). In the case of a split MBS bearer, gNB200 may send an instruction to deactivate the PTM leg to UE100. In the case of not a split MBS bearer, gNB200 may send an instruction to release the PTM bearer to UE100.

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

[0131] However, since the PTM communication path is mainly used for multicast to a plurality of UEs 100, it is difficult to perform individual adaptive control (e.g., adaptive modulation and coding) according to the radio state for each UE 100. For this reason, it is considered that a UE 100 with a poor radio state cannot normally receive MBS data transmitted by PTM transmission. Such a UE 100 consumes power uselessly when executing the PTM monitor operation, which is inefficient. Therefore, it is preferable that the UE 100 stops the PTM monitor operation when the radio state deteriorates.

[0132] In one embodiment, the UE 100 performs a PTM monitor operation of attempting to receive MBS data transmitted from the gNB 200 via the 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 the PTM monitor operation. The UE 100 stops the PTM monitor operation in response to detecting a deterioration in a measurement value indicating the communication quality of the PTM leg.

[0133] In this way, by stopping the PTM monitor operation in response to the UE 100 detecting a deterioration in a measurement value indicating the communication quality of the PTM leg, it is possible to prevent the UE 100 from consuming power uselessly.

[0134] Note that the measurement value indicating the communication quality of the PTM leg may be the same as the measurement value indicating the communication quality of the PTP leg or a different measurement value from the measurement value indicating the communication quality of the PTP leg. For example, when the PTM leg and the PTP leg of the UE 100 are set in the same cell, a common measurement value may be used for the PTM leg and the PTP leg. When the PTM leg and the PTP leg of the UE 100 are set in different cells, a measurement value dedicated to the PTM leg may be used.

[0135] Also, the measurement value indicating the communication quality may be at least one of RSRP, RSRQ, and SINR of the radio signal from the gNB 200. The measurement value indicating the communication quality may be the reception error rate of the MBS data and / or the number of times of continuously detecting reception errors.

[0136] When the UE 100 stops the PTM monitoring operation, the UE 100 may send a notification indicating the stop of the PTM monitoring operation to the gNB 200. Thereby, the gNB 200 can recognize 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, since individual adaptive control according to the radio state can be performed, even a UE 100 with a poor radio state can receive the MBS data.

[0137] FIG. 13 is a diagram showing an operation example related to the PTM monitoring operation according to an embodiment. In this operation example, it is assumed that the UE 100 is in the 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 may transmit setting information including the threshold of the PTM radio state to the UE 100 via the PTM leg or the PTP leg. The gNB 200 may also set the threshold of the PTM radio state for the UE 100 in the RRC Reconfiguration message or the SIB. The UE 100 sets the threshold specified by the gNB 200.

[0139] In step S302, UE100 starts a PTM monitoring operation and a measurement operation of the communication quality of the PTM leg.

[0140] In step S303, gNB200 may transmit MBS data to UE100 via the PTM leg by PTM transmission. UE100 may receive the PTM data by the PTM monitoring operation.

[0141] In step S304, UE100 compares a 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 compared to the threshold value. That the communication quality has deteriorated compared to the threshold value may mean that the RSRP, RSRQ, or SINR has fallen below the threshold value, or that the reception error rate or the number of consecutive reception error detections has exceeded the threshold value.

[0142] If the communication quality of the PTM leg has deteriorated compared to the threshold value (step S304: YES), in step S305, UE100 stops the monitoring operation of the PTM leg. In this case, in step S306, UE100 may transmit a notification indicating the stop of the monitoring operation of the PTM leg to gNB200 via the PTP leg. Also, UE100 may transmit the above-described SN notification message to gNB200.

[0143] After stopping the monitoring operation of the PTM leg, UE100 may continue to measure the RSRP, RSRQ, or SINR. If the RSRP, RSRQ, or SINR improves, UE100 may resume the monitoring operation of the PTM leg. UE100 may transmit a notification indicating the resumption of the monitoring operation of the PTM leg to gNB200 via the PTP leg. Also, UE100 may transmit the above-described SN notification message to gNB200.

[0144] (Other embodiments) In the above-described embodiments, an example in which a split MBS bearer is used to configure a PTP communication path with a PTP leg and a PTM communication path with a PTM leg has been mainly described. However, two radio bearers (two data radio bearers) may be used to configure a PTP communication path with a first radio bearer for PTP and a PTM communication path with a second radio bearer for PTM. Also, PTP transmission may be a method of transmitting MBS data from gNB200 to UE100 using a PTP bearer, which is a first data radio bearer for PTP, as a PTP communication path. PTM transmission may be a method of transmitting MBS data from gNB200 to UE100 using a PTM bearer, which is a second data radio bearer for PTM, as a PTM communication path. Under such a premise, the above-described SN notification message may include information indicating an MBS service (or session). The information may be, for example, TMGI, Session ID, or G-RNTI. Thereby, even when gNB200 changes a bearer, it becomes easier to grasp which MBS bearer the SN notification message corresponds to.

[0145] Each of the above-described operation flows is not limited to being implemented separately and independently, and two or more operation flows can be combined and implemented. For example, some steps of one operation flow may be added to another operation flow. Also, some steps of one operation flow may be replaced with some steps of another operation flow.

[0146] In the above-described embodiments, 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). Also, the base station may be a relay node such as an IAB (Integrated Access and Backhaul) node. The base station may be a DU (Distributed Unit) of an IAB node.

[0147] A program may be provided that causes a computer to execute each process performed by the UE100 or the gNB200. The program may be recorded on a computer-readable medium. By using a computer-readable medium, it is possible to install the program on a computer. Here, the computer-readable medium on which the program is recorded may be a non-transitory recording medium. The non-transitory recording medium is not particularly limited, and may be, for example, a recording medium such as a CD-ROM or a DVD-ROM.

[0148] Further, circuits that execute each process performed by the UE100 or the gNB200 may be integrated, and at least a part of the UE100 or the gNB200 may be configured as a semiconductor integrated circuit (chipset, SoC).

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

[0150] This application claims the priority of US Provisional Application No. 63 / 164,682 (filed on March 23, 2021), and all of its contents are incorporated herein by reference.

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

[0152] Generally, RRC reconfiguration can be regarded as being used to provide a bearer configuration including two logical channels (PTM leg and PTP leg) together with information for receiving a multicast session.

[0153] Therefore, RAN2 needs to first confirm that the configuration associating two logical channels with one multicast radio bearer (MRB) is provided by RRC reconfiguration for the preparation of dynamic PTM / PTP switching.

[0154] RAN2 needs to confirm that the configuration associating two logical channels with one MRB is provided by RRC reconfiguration before the dynamic PTM / PTP switching operation.

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

[0156] In LTE SC-PTM, the opportunity for SC-PTM reception is independent of the unicast DRX scheme and is individual DRX.

[0157] Since the G-RNTI is received by multiple UEs and the C-RNTI is UE-specific, it is very difficult to adjust the two DRXs, so this concept may become the baseline for NR MBS.

[0158] This means that when the UE needs to always monitor the G-RNTI, the UE needs to wake up frequently, which results in additional power consumption.

[0159] On the other hand, a connected UE 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 during PTM leg transmission (i.e., G-RNTI) like during SC-MTCH in LTE SC-PTM, and also needs to wake up during PTP leg transmission (i.e., C-RNTI), which is the same as when using C-DRX.

[0161] There are the following four options for receiving an MRB using PTM / PTP. · Option 1: Switching based on activation / deactivation base The gNB indicates to the UE which leg is to be activated / deactivated by means of DCI, MAC CE, RRC signaling, etc. The PTM leg and the PTP leg are assumed to be associated with the PDCP layer in accordance with the RAN2 agreement. This option becomes more flexible when MBS data is received via two legs, i.e., like split bearer and PDCP packet replication. The UE can reduce the power consumption from the deactivated leg. The deactivation of the PTM leg is beneficial as the UE can skip G-RNTI monitoring, but it is unclear whether the deactivation of the PTP leg can contribute to power saving from the perspective of startup, i.e., on-period. The UE needs to monitor the C-RNTI according to C-DRX as long as it is in the RRC connection. · Option 2: Switching based on switching order / command The gNB instructs the UE to switch the PTM leg and the PTP leg, for example, by means of DCI, MAC CE, or RRC signaling. This option is simple and is the same as Option 1 above. It is the same in that the PTM leg and the PTP leg are associated with the PDCP layer in accordance with the RAN2 agreement and power saving can be obtained by deactivating the PTM. However, this option is only for switching the PTM leg and the PTP leg and not for activating both, so there is no flexibility for operations such as split bearer including PDCP packet replication. · Option 3: Switching based on RRC reconfiguration The gNB reconfigures the UE using either PTM or PTP as the MRB by means of RRC reconfiguration. That is, the PTM leg and the PTP leg are not associated with one MRB. That is, it is a kind of "bearer type change" that does not conform to the RAN2 agreement because it is unclear how PDCP anchors these legs during the switching. There are also doubts about how this option can "dynamically" switch between PTM and PTP. · Option 4: No signaling-based switching When the MRB is configured with two legs, the UE should always attempt to receive from both the PTM leg and the PTP leg. Since the two legs are anchored by PDCP, it is in line with the RAN2 agreement. This option provides no opportunity for power saving from the UE's perspective while ensuring maximum scheduling flexibility from the gNB's perspective.

[0162] Based on the above findings, Option 1 is the most suitable from the perspectives of scheduling flexibility, UE power consumption, and consistency with the current agreement.

[0163] Option 4 can be regarded as a subset of Option 1 when the PTM leg is always active.

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

[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 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 (Chairperson)", RAN2#113-e advanced the design of the L2 architecture with the following agreement.

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

[0169] In our understanding, since the reliability of L2 depends only on RLC-UM for both the PTP leg and the PTM leg, it is not guaranteed by the agreement. Therefore, in this contribution, possible solutions regarding the reliability of L2 will be explained.

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

[0171] This agreement clearly states that "both PTM and PTP are in RLC-UM and do not use L2 ARQ". This means that in the current architecture, neither RLC-AM nor PDCP retransmission is performed. Clearly, this architecture cannot contribute to improving the reliability of L2. Therefore, a reliable multicast session can only be provided by PTP using RLC-AM (i.e., it cannot be implemented without the above "split bearer" architecture). This means that nothing is improved from the conventional unicast transmission, especially in terms of spectral efficiency. Therefore, RAN2 needs to introduce some mechanisms to improve the reliability of L2 based on Proposal 1 from the following email discussion.

[0172] For case A, the following options are available in the table. · A1: No L2 ARQ for PTM · A2: L2 ARQ by PDCP for PTM · A3: L2 ARQ by RLC-AM for PTM For case B, the following options are available in the table. ·B1: PDCP-anchored PTM / PTP Switching ·B2: RLC-anchored PTM / PTP Switching

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

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

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

[0176] A1 + B1 of PTM RLC-UM + PTP RLC-AM probably involves some data recovery during the switching procedure.

[0177] [[ID=2,7]] This option can be interpreted as shown in Figure 16.

[0178] It is considered that the reliability of L2 is guaranteed only by the PTP leg. For example, when the radio condition deteriorates, data reception switches from the PTM leg to the PTP leg. That is, the PTM leg can be used only when the radio condition is good and stable.

[0179] In the case of the A1 + B1 option, the reliability of L2 is guaranteed by the PTP leg, but the PTM leg can only be used when the radio condition is good and stable. Since this option is assumed to reuse the existing RLC functions, i.e., the AM mode of the PTP leg and the UM mode of the PTM leg, the impact within the PDCP layer is limited.

[0180] In the case of the A1 + B1 option, it is expected that the PDCP specification will be affected, but the RLC specification will not be affected.

[0181] As shown in the option name, i.e., "Certain data recovery in the handover procedure", this option is assumed to be based on the current PDCP status report transmitted during the handover procedure. It is clear that the PDCP status report can be transmitted via the PTP leg rather than the PTM leg.

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

[0183] In the case of an AM DRB (statusReportRequired in TS 38.331) set by the upper layer to transmit a PDCP status report on the UL, the receiving PDCP entity needs to trigger the PDCP status report in the following cases. · The upper layer requests re - establishment of the PDCP entity · The upper layer requests PDCP data recovery · The upper layer requests UL data handover · The upper layer re - configures the PDCP entity to release DAPS and daps - SourceRelease configured in TS 38.331.

[0184] Regarding the initial condition, i.e., "the upper layer requests re - establishment of the PDCP entity", since a single PDCP entity in the gNB is established for multiple UEs regardless of whether it is associated with the PTP leg or the PTM leg, it is not possible to easily re - establish the PDCP entity of the MRB (Multicast Radio Bearer).

[0185] Regarding the second condition, i.e., "the upper layer requests recovery of PDCP data", it is associated with the procedure for recovering PDCP data related to UL re - transmission such as handover. Therefore, since there is only DL data transmission, it is not associated with NR MBS.

[0186] Regarding the third and fourth conditions, i.e., "the upper layer requests UL data switching" and "the upper layer re - configures the PDCP entity to release the configured DAPS and daps - SourceRelease", these are related to DAPS handover. Therefore, these are not used for PTM / PTP switching.

[0187] Based on the above findings, the existing conditions cannot be used for data recovery during PTM / PTP switching. Therefore, a new trigger condition is required to send a PDCP status report. The new trigger condition may be the first packet received via the activated leg instead of at the time of switching, for example, the PTP leg in the case of PTM / PTP switching.

[0188] In the case of the A1+B1 option, new trigger conditions may be required to send a PDCP status report (or a new PDCP control PDU for feedback) during PTM / PTP switching. The PDCP status report is set with an FMC indicating the First Missing COUNT and, optionally, a bitmap indicating for each bit position whether the next PDCP SDU was correctly received or missing. In our understanding, this option can also be reused, but does not prevent the introduction of a new PDCP control PDU for feedback at this time.

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

[0190] A2+B1 for PTM RLC-UM+PTP RLC-AM 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 supplement the missing packets from the PTM leg. Since the PTM leg can be used even when the radio condition is relatively poor and / or unstable, the spectral efficiency is improved compared to the above A1+B1 option.

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

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

[0194] In the case of the A2 + B1 option, it is necessary to specify a new ARQ function at the PDCP layer. This can be regarded as the baseline ARQ function of the RLC specification. For example, for the procedure, see Section 5.3, and for the STATUS PDU format, see 6.2.2.5. This is an ACK / NACK type ARQ mechanism, and the feedback is transmitted via the STATUS PDU.

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

[0196] The AM RLC entity sends a STATUS PDU to the equivalent AM RLC entity to provide positive and / or negative confirmation responses for the RLC SDUs (or parts thereof). The triggers for starting a status report are as follows. · Polling from the peer AM RLC entity · Detection of reception failure of the AM DPDU

[0197] Regarding the first condition, i.e., "polling from the equivalent AM RLC entity", it can be reused because the gNB may send polling to one or more 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 reception failure of the AM DPDU", this concept can be reused because the UE may detect a reception failure at the PDCP in some way. Currently, it is detected by the RLC when the expiration time of t - Reassembly expires, but discussions may be needed on how to detect reception failures at the PDCP. If the RLC ARQ mechanism is reused, the same optimizations are expected for the following A3 + B2 option. For example, additional conditions such as forcibly moving the reception window.

[0199] In the case of the A2 + B1 option, the RLC ARQ mechanism including the format of the STATUS PDU can be used as the baseline for PDCP ARQ, but details such as the method for detecting reception failures need to be changed. As another possibility, a new ARQ mechanism without problems can be considered. This can be regarded as a kind of ARQ mechanism with only NACK. In this case, assuming that only FMC is reported, the current PDCP status report may become the baseline. Similar to the above A1 + B1 option, new trigger conditions are required for the PDCP status report (or a new PDCP control PDU for feedback). Also, similar to the above RLC ARQ baseline, it is necessary to discuss the method for detecting reception failures and / or the method for managing the reception window when introduced.

[0200] In the case of the A2 + B1 option, the PDCP status report (or a new PDCP control PDU for feedback) can be used as another baseline for PDCP ARQ, but it may be necessary to specify operations related to new trigger conditions such as the method for detecting reception failures and / or the method for managing the reception window.

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

[0202] Similar to the above A2 + B1 option, it can be considered to use either the PTM leg or the PTP leg to supplement the missing packets from the PTM leg. Since the PTM leg can be used even when the radio condition is relatively poor and / or unstable, the spectral efficiency is improved compared to the above A1 + B1 option. Furthermore, retransmission can be performed for each RLC segment. This is different from the above A2 + B1 option that performs retransmission for each PDCP SDU. Therefore, this option can be regarded as having the best performance among the candidate options from the perspective of spectral efficiency.

[0203] In the case of the A3 + B2 option, since the reliability of L2 can be guaranteed by PTP leg support, the PTM leg can be used even when the wireless condition is relatively poor and unstable.

[0204] In the case of the A3 + B2 option, retransmission can be performed for each RLC segment. Different from other options, the PTP leg and the PTM leg are anchored to the RLC layer. Therefore, this option basically does not affect the PDCP specification, but it depends on whether the above A1 + B1 option is used in this option. That is, in this case, the same impact may be predicted in the PDCP specification.

[0205] In the case of the A3 + B2 option, it is not expected that the PDCP specification will be affected, but it depends on whether other options are used together.

[0206] It can be considered that the main impact is introduced into the RLC specification. However, at least for ARQ, since it mainly depends on the implementation of the gNB, it is expected that there is no impact (or the impact is minor). In fact, if all UEs can receive all the missing RLC PDUs in time, there is no problem with the reception window, so it is also possible to reuse the existing ARQ as it is. Since retransmission can be performed via the PTP leg in addition to the PTM leg, the PTP leg can be regarded as sufficiently reliable because it is a basic assumption for other options related to B1. However, some new conditions for forcibly moving the reception window (RX_Next) in case of errors have been proposed.

[0207] In the case of the A3 + B2 option, it is expected that the RLC specification has no impact (or minor impact). (Summary) The results of the findings are summarized in Figure 19.

[0208] The A2+B1 option clearly has fewer merits compared to other options, namely the A1+B1 option and the A3+B2 option. The A3+B2 option can be regarded as the best approach. On the other hand, in RAN2, it is stated that "Prerequisite for operation: RLC-AM for PTM is not supported (can be reconsidered, but this means that supporters of RLC-AM for PTM need to demonstrate the necessity for changing this).", which needs to be reconsidered from a technical reason perspective.

[0209] RAN2 needs to agree to introduce A1+B1 (i.e., the PDCP anchor and data recovery during switching), and / or A3+B2 (i.e., the 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 network device to a user device, comprising: the user device receiving, from the network device, a threshold value of radio quality related to reception of a multicast session; the user device measuring the radio quality of a serving cell when receiving the multicast session; the user device transmitting predetermined information to the serving cell when a measured value indicating the radio quality is equal to or lower than the threshold value. A communication control method.

2. A user device that communicates with a network device that provides a multicast broadcast service (MBS), comprising: a receiving unit that receives, from the network device, a threshold value of radio quality related to reception of a multicast session; a control unit that measures the radio quality of a serving cell when receiving the multicast session; a transmitting unit that transmits predetermined information to the serving cell when a measured value indicating the radio quality is equal to or lower than the threshold value. A user device.

3. A chipset that controls a user device that communicates with a network device that provides a multicast broadcast service (MBS), comprising: a process of receiving, from the network device, a threshold value of radio quality related to reception of a multicast session; a process of measuring the radio quality of a serving cell when the user device receives the multicast session; a process of transmitting predetermined information to the serving cell when a measured value indicating the radio quality of the user device is equal to or lower than the threshold value. A chipset.

4. A program for controlling a user device that communicates with a network device that provides a multicast broadcast service (MBS), comprising: a process of receiving, from the network device, a threshold value of radio quality related to reception of a multicast session; a process of measuring the radio quality of a serving cell when the user device receives the multicast session; a process of causing the user device to transmit predetermined information to the serving cell when a measured value indicating the radio quality of the user device is equal to or lower than the threshold value. A program.

5. A mobile communication system having a user device and a network device that provides a multicast broadcast service (MBS) to the user device, wherein the user device receives a wireless quality threshold related to reception of a multicast session from the network device, wherein the user device measures the wireless quality of a serving cell when receiving the multicast session, and wherein the user device transmits predetermined information to the serving cell when a measured value indicating the wireless quality is equal to or less than the threshold. A mobile communication system.

Images