Communication control method and user apparatus

Abstract

To provide a communication control method, a user device, a mobile communication system, a chip set and a program for achieving an improved multicast broadcast service (MBS) in the mobile communication system.SOLUTION: The communication control method includes receiving, by a UE, a PDCP packet from a base station gNB, the PDCP packet being encrypted using a count value including a PDCP sequence number (SN) and a hyper frame number (HFN) and transmitted in an MBS session, generating an inferred HFN by inferring the HFN, attempting to decode the PDCP packet using the inferred count value including the PDCPSN and the HFN included in the received PDCP packet, and determining the inferred hyper frame number as a valid hyper frame number when the decoding is successful.SELECTED DRAWING: Figure 11

Description

[Technical Field]

[0001] The present disclosure relates to a communication control method and a user device used 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 executed by a user device in a mobile communication system that provides a multicast / broadcast service (MBS) from a base station to the user device. The communication control method includes receiving, from the base station, a PDCP packet encrypted using a count value consisting of a PDCP sequence number and a hyperframe number and transmitted in an MBS session, generating a guessed hyperframe number by guessing the hyperframe number, attempting to decode the PDCP packet using the guessed count value consisting of the PDCP sequence number and the guessed hyperframe number included in the received PDCP packet, and, if the decoding is successful, determining the guessed hyperframe number as a valid hyperframe number.

[0005] A communication control method according to a second aspect is a method executed by a user device in a mobile communication system in which a base station provides a multicast / broadcast service (MBS) to the user device, the method comprising: a PDCP entity of the user device updating PDCP variables associated with an MBS session in response to receiving PDCP packets transmitted in the MBS session; and initializing the updated PDCP variables when the MBS session is interrupted, when the MBS session is resumed after being interrupted, or when an instruction to initialize the PDCP variables is received from the base station.

[0006] A communication control method according to a third aspect is a method executed by a user device in a mobile communication system in which a base station provides a multicast / broadcast service (MBS) to the user device, the method comprising: a PDCP entity of the user device updating PDCP variables associated with the MBS session in response to reception of PDCP packets transmitted in the MBS session; when the PDCP entity is re-established, retaining the PDCP variables associated with the MBS session without initializing them; and the PDCP entity continuing reception processing of PDCP packets transmitted in the MBS session based on the retained PDCP variables.

[0007] A fourth aspect of the present invention relates to a communication control method executed by a user device in a mobile communication system that provides a multicast / broadcast service (MBS) from a base station to the user device, the communication control method comprising: a PDCP entity of the user device updating PDCP variables associated with an MBS session in response to receiving PDCP packets transmitted in the MBS session; and receiving notification information from the base station indicating whether the updated PDCP variables can continue to be used in the second cell before the user device performs a handover, RRC re-establishment, or cell reselection from a first cell to a second cell of the base station.

[0008] A communication control method according to a fifth aspect is a method executed by a user device in a mobile communication system that provides a multicast / broadcast service (MBS) from a base station to the user device, the communication control method including: an RLC entity of the user device receiving, from the base station, RLC PDUs that are transmitted in an MBS session and that are obtained by the base station segmenting an RLC SDU; and determining, based on an RLC sequence number included in the RLC PDU first received from the base station, whether to reconstruct the RLC SDU from the first received RLC PDU and RLC PDUs subsequent to the first received RLC PDU.

[0009] A user device according to a sixth aspect includes a processor that executes the communication control method according to any one of the first to fifth aspects. [Brief explanation of the drawings]

[0010] [Figure 1] 1 is a diagram illustrating a configuration of a mobile communication system according to an embodiment. [Figure 2] FIG. 1 is a diagram illustrating a configuration of a UE (user equipment) according to an embodiment. [Figure 3] A diagram showing the configuration of a gNB (base station) according to one embodiment. [Figure 4]FIG. 10 is a diagram showing the configuration of a protocol stack of a radio interface of a user plane that handles data. [Figure 5] FIG. 1 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 illustrating a correspondence relationship between downlink logical channels and transport channels according to an embodiment. [Figure 7] FIG. 1 is a diagram illustrating a method for distributing MBS data according to an embodiment. [Figure 8] FIG. 1 illustrates a split MBS bearer according to one embodiment. [Figure 9] FIG. 10 illustrates example operations related to leg activation and deactivation according to one embodiment. [Figure 10] FIG. 10 is a diagram illustrating a first example of the operation of PDCP according to an embodiment. [Figure 11] FIG. 10 is a diagram illustrating a second example of the operation of PDCP according to an embodiment. [Figure 12] FIG. 10 is a diagram illustrating a third example of the operation of PDCP according to an embodiment. [Figure 13] FIG. 10 is a diagram illustrating a fourth example of the operation of PDCP according to an embodiment. [Figure 14] FIG. 10 is a diagram illustrating a fifth example of the operation of PDCP according to an embodiment. [Figure 15] FIG. 10 is a diagram illustrating a sixth example of operation of PDCP according to an embodiment. [Figure 16] FIG. 10 is a diagram illustrating an example of an RLC operation according to an embodiment. [Figure 17] FIG. 10 is a diagram illustrating an example of an RLC operation according to an embodiment. [Figure 18] FIG. 10 is a diagram for explaining a case in which an existing PDCP functional view is reused. DETAILED DESCRIPTION OF THE INVENTION

[0011] The introduction of multicast and broadcast services into the 5G system (NR) is being considered. The NR multicast and broadcast services are expected to provide improved services compared to the LTE multicast and broadcast services.

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

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

[0014] (Configuration of a mobile communication system) First, the configuration of a mobile communication system according to an 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 conforms to the 5th Generation System (5GS) of the 3GPP standard. In the following description, 5GS will be taken as an example, but the mobile communication system may also be at least partially applied to an LTE (Long Term Evolution) system. Furthermore, the mobile communication system may also be at least partially applied to a 6th Generation (6G) system.

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

[0016] 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).

[0017] The NG-RAN 10 includes a base station (called a "gNB" in a 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 a 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, etc. 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 that performs wireless communication with a UE 100. One cell belongs to one carrier frequency.

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

[0019] 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 NAS (Non-Access Stratum) signaling. The UPF controls data forwarding. The AMF and UPF are connected to the gNB 200 via an NG interface, which is an interface between a base station and a core network.

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

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

[0022] The receiving unit 110 performs various types of reception 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.

[0023] 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 a baseband signal (transmission signal) output by the control unit 130 into a radio signal and transmits it from the antenna.

[0024] 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 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 processes.

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

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

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

[0028] The receiving unit 220 performs various types of reception 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.

[0029] 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 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 processes.

[0030] The backhaul communication unit 240 is connected to neighboring 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., functionally divided), and both units may be connected via an F1 interface.

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

[0032] As shown in Figure 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.

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

[0034] 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 UE 100 and the MAC layer of gNB 200 via a transport channel. The MAC layer of 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 allocated to UE 100.

[0035] The RLC layer transmits data to the RLC layer on the receiving side using the functions of the MAC layer and 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 logical channels.

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

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

[0038] 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).

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

[0040] RRC signaling for various settings is transmitted between the RRC layer of UE100 and the RRC layer of gNB200. 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 UE100 and the RRC of gNB200, UE100 is in an RRC connected state. When there is no connection (RRC connection) between the RRC of UE100 and the RRC of gNB200, UE100 is in an RRC idle state. When the connection between the RRC of UE100 and the RRC of gNB200 is suspended, UE100 is in an RRC inactive state.

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

[0042] The UE 100 has an application layer and the like in addition to the radio interface protocol.

[0043] (MBS) Next, an MBS according to one embodiment will be described. The MBS is a service that enables broadcast or multicast data transmission, i.e., point-to-multipoint (PTM) data transmission, from the NG-RAN 10 to the UE 100. The MBS may also be called an MBMS (Multimedia Broadcast and Multicast Service). Note that use cases (service types) of the MBS include public safety communications, mission-critical communications, V2X (Vehicle to Everything) communications, IPv4 or IPv6 multicast distribution, IPTV (Internet protocol television), group communications, and software distribution.

[0044] 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 the correspondence relationship between downlink logical channels and transport channels according to one embodiment.

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

[0046] The logical channels used for SC-PTM transmission are the Single Cell Multicast Traffic Channel (SC-MTCH) and the Single Cell Multicast Control Channel (SC-MCCH), and the transport channel used for SC-PTM transmission is the Downlink Shared Channel (DL-SCH). SC-PTM transmission is primarily designed 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 Physical Downlink Control Channel (PDCCH) and the Physical Downlink Shared Channel (PDSCH), which enable dynamic resource allocation.

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

[0048] Furthermore, MBS data refers to data provided by an MBS, an MBS control channel refers to an MCCH or SC-MCCH, and an MBS traffic channel refers to an MTCH or SC-MTCH. However, MBS data may also be transmitted via unicast. MBS data may also be referred to as an MBS packet or MBS traffic.

[0049] 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 also be called an MBS service identifier or a multicast group identifier.

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

[0051] 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 of the MBS data (replication), and distributes the data.

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

[0053] In 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) will be referred to as an "MBS connection."

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

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

[0056] On the other hand, in 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) terminates at the UE 100.

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

[0058] The gNB200 can set an MBS bearer separated into a PTP communication path and a PTM communication path (hereinafter referred to as a "split MBS bearer" as appropriate) 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 improve reliability by dual-transmitting the same MBS data using both PTP (PTP communication path) and PTM (PTM communication path).

[0059] The predetermined layer that terminates splitting 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 splitting 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.

[0060] 8 is a diagram showing a split MBS bearer according to one embodiment. Hereinafter, a PTP communication path is referred to as a PTP leg, and a PTM communication path is referred to as a PTM leg. Furthermore, a functional unit corresponding to each layer is referred to as an entity.

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

[0062] Each of the gNB 200 and the UE 100 has two RLC entities, one MAC entity, and one PHY entity, each of which is provided for each leg. A 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.

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

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

[0065] Furthermore, 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.

[0066] 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., the UE 100 performs blind decoding of the PDCCH using the G-RNTI). The UE 100 may monitor the PDCCH only at a scheduling opportunity for the MBS session.

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

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

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

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

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

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

[0073] When performing bearer setup using an RRC message (RRC Reconfiguration message), gNB200 may use the same message to instruct UE100 on the initial state of each leg (i.e., activation or deactivation of each leg). When transmitting an RRC message including bearer setup for a split MBS bearer to UE100, the RRC entity of gNB200 includes an instruction to activate or deactivate each leg in the RRC message along with the bearer setup.

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

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

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

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

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

[0079] UE100 starts the process of receiving data using the C-RNTI in response to receiving an instruction to activate the PTP leg. UE100 starts the process of receiving MBS data using the G-RNTI in response to receiving an instruction to activate the PTM leg. On the other hand, UE100 ends the process of receiving data using the C-RNTI in response to receiving an instruction to deactivate the PTP leg. UE100 ends the process of receiving MBS data using the G-RNTI in response to receiving an instruction to deactivate the PTM leg.

[0080] In step S12, the gNB 200 may transmit (PTM transmission) an instruction to activate or deactivate a PTP leg to the UE 100 via the PTM leg in the activated state. This allows the PTP legs of multiple UEs 100 to be activated or deactivated collectively by PTM.

[0081] The gNB 200 may transmit (PTM transmission) an instruction to deactivate the PTM leg to the UE 100 via the activated PTM leg. This allows the PTM legs of multiple UEs 100 to be deactivated collectively by PTM.

[0082] In step S12, the gNB 200 may transmit (PTP transmission) 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.

[0083] The gNB 200 may transmit (PTP transmission) 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.

[0084] In step S13, in response to receiving the 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 a 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 on the activated leg.

[0085] 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 on the leg.

[0086] In addition, in response to 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.

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

[0088] (PDCP operation example 1) Next, a first operational example of the PDCP according to an embodiment will be described.

[0089] The PDCP entity of UE 100 sets and updates PDCP variables according to the PDCP sequence number (PDCP SN) included in the PDCP packet received from gNB 200. Typically, UE 100 sets the initial value of the PDCP variable to zero and updates (increments, counts up) the PDCP variable according to the reception of packets from gNB 200.

[0090] A PDCP entity of UE 100 that has participated in an MBS session from the beginning can sequentially update the PDCP variables to keep them up to date. On the other hand, a PDCP entity of UE 100 that has participated in an MBS session halfway through may receive a PDCP packet having a PDCP SN value that is significantly different from the initial value, which may prevent the PDCP entity from operating normally (predetermined PDCP operation).

[0091] In the first operational example, the following method enables the UE 100 that has joined the MBS session midway to perform a predetermined PDCP operation normally.

[0092] The PDCP entity of UE 100 sets the PDCP SN included in the PDCP packet first received from gNB 200 as the initial value of a variable (PDCP variable) used for a predetermined PDCP operation. That is, when receiving a PDCP packet transmitted in an MBS session (PTM), the PDCP entity of UE 100 does not set the PDCP variable to zero, but sets the PDCP SN included in the PDCP packet first received from gNB 200 as the initial value of the PDCP variable. This enables the PDCP entity of UE 100, which has joined an MBS session midway, to perform the predetermined PDCP operation normally.

[0093] The predetermined PDCP operation is at least one of a receive window control and a packet reordering operation.

[0094] The PDCP variables used for receiving window control may be at least one of RX_NEXT and RX_DELIV. RX_NEXT contains the sequence number of the PDCP SDU expected to be received next. RX_DELIV contains the sequence number of the oldest PDCP SDU waiting to be received that has not yet been provided to the upper layer. Normally, the initial values ​​of RX_NEXT and RX_DELIV are "0".

[0095] The PDCP variable used for packet reordering may be RX_REORD, which is the sequence number of the PDCP SDU that started the timer indicating the maximum time to wait for packet reordering. For example, if the sequence number of a received packet is smaller than RX_REORD, the UE 100 discards the packet.

[0096] FIG. 10 is a diagram illustrating a first example of the operation of PDCP according to an embodiment.

[0097] As shown in Fig. 10, in step S101, the gNB 200 starts MBS transmission for a certain MBS session. In step S102, the UE 100A, which initially participates in the MBS session, starts MBS reception for the MBS session. The UE 100A is in an RRC connected state, an RRC idle state, or an RRC inactive state. The UE 100A may receive and execute configuration of an MBS bearer (PDCP) from the gNB 200.

[0098] In step S103, the gNB 200 transmits a PDCP packet in PTM via the MBS bearer. The sequence number (PDCP SN) included in the PDCP header of this PDCP packet is assumed to be “0”.

[0099] In step S104, when the PDCP entity of UE100A receives a PDCP packet from gNB200, it sets the PDCP SN "0" contained in the received PDCP packet as the initial value of the PDCP variable and performs a predetermined PDCP operation.

[0100] Thereafter, in step S105, the UE 100B joins the MBS session midway and starts MBS reception for the MBS session. The UE 100B is in an RRC connected state, an RRC idle state, or an RRC inactive state. The UE 100B may receive and execute configuration of an MBS bearer (PDCP) from the gNB 200.

[0101] In step S106, the gNB 200 transmits the PDCP packet in PTM via the MBS bearer. The PDCP SN included in the PDCP header of this PDCP packet is assumed to be “n”, where “n” is an integer greater than or equal to 1.

[0102] In step S107, when the PDCP entity of the UE 100B receives a PDCP packet via the MBS bearer for the first time, it sets the PDCP SN "n" contained in the first received PDCP packet as the initial value of a PDCP variable and performs a predetermined PDCP operation. For example, the PDCP entity of the UE 100B sets RX_DELIV=the sequence number "n" of the packet and RX_NEXT=the sequence number "n" of the packet. Alternatively, it may set (n+1) mod [SN size].

[0103] In step S108, when the PDCP entity of the UE 100A receives the PDCP packet via the MBS bearer, it updates the PDCP variables with the PDCP SN "n" included in the received PDCP packet.

[0104] In step S109, the gNB 200 transmits a PDCP packet in PTM via the MBS bearer. The PDCP SN included in the PDCP header of this PDCP packet is assumed to be “n+1”.

[0105] In step S110, when the PDCP entity of the UE 100B receives the PDCP packet via the MBS bearer, it updates the PDCP variables with the PDCP SN "n+1" included in the received PDCP packet.

[0106] In step S111, when the PDCP entity of the UE 100A receives a PDCP packet via the MBS bearer, it updates the PDCP variables with the PDCP SN "n+1" included in the received PDCP packet.

[0107] In this operation example, the initial values ​​of each PDCP variable are updated based on the received PDCP packet, but this is not limited to this. The initial values ​​of each PDCP variable may be set in the UE 100 by the gNB 200. For example, the UE 100B that performs MBS reception may be given the initial values ​​of each PDCP variable by the gNB 200 when MBS reception setting is performed by dedicated signaling.

[0108] (PDCP operation example 2) Next, a second operational example of the PDCP according to an embodiment will be described, focusing on differences from the first operational example described above.

[0109] In the above-described operation example 1, the PDCP SN was mainly assumed as the PDCP variable managed by the UE 100. In this operation example 2, an example will be described in which the UE 100 also manages the hyperframe number (HFN) as a PDCP variable. The HFN is incremented every time the PDCP SN wraps around. In other words, the HFN is a value that is counted up every time the PDCP SN wraps around.

[0110] For example, the UE 100 manages a COUNT, which is a count value consisting of a PDCP SN and an HFN. The format of RX_DELIV is the same as COUNT, which is HFN+SN. COUNT is also used to encrypt PDCP packets for security purposes.

[0111] In the above-described operation example 1, UE 100B, which joins an MBS session midway, calculates RX_DELIV from the PDCP SN included in the header of the PDCP packet (PDCP PDU) received first in this MBS session. Here, the header of the PDCP PDU includes the PDCP SN but does not include the HFN.

[0112] The initial value of RX_DELIV is 0, and in the case of unicast, both gNB 200 and UE 100 increment the HFN based on the initial value each time the PDCP SN wraps around, thereby synchronizing the HFNs of gNB 200 and UE 100. On the other hand, in the case of multicast, as described above, it is uncertain from which RX_DELIV UE 100 will start receiving PDCP packets, so there is a problem in that a valid HFN (i.e., the HFN managed by gNB 200) cannot be determined by looking at the received PDCP packets alone.

[0113] In this operation example 2, the PDCP entity of UE 100 receives from gNB 200 a PDCP packet that is encrypted using a COUNT consisting of a PDCP SN and an HFN and transmitted in an MBS session. The PDCP entity of UE 100 generates a guessed HFN by guessing the HFN. The PDCP entity of UE 100 attempts to decode the PDCP packet using the guessed COUNT consisting of the PDCP SN and guessed HFN included in the received PDCP packet. If the decoding is successful, the PDCP entity of UE 100 determines the guessed HFN as a valid HFN.

[0114] As a result, even if UE 100 joins an MBS session midway, it can derive a valid HFN by using the security function of PDCP. By managing COUNT using the HFN derived in this way, it is possible to appropriately manage PDCP variables such as RX_DELIV.

[0115] In this operation example 2, UE 100 may receive range information indicating a range of HFNs (hereinafter referred to as "HFN range information") from gNB 200. The PDCP entity of UE 100 may generate a predicted HFN based on the received HFN range information. For example, an HFN included in the range indicated by the received HFN range information is generated as a predicted HFN. Since decrypting an encrypted PDCP packet requires calculation processing, there are issues with the power consumption and response time of UE 100. Therefore, by having gNB 200 notify UE 100 of possible HFNs in advance, the number of predicted HFN candidates generated by the PDCP entity of UE 100 can be reduced, thereby reducing the power consumption and response time of UE 100.

[0116] It is also possible for the gNB200 to notify the UE100 of the HFN value itself. However, the HFN is counted up in accordance with the count up of the PDCP SN. Since there may be a delay between when the gNB200 notifies the UE100 of the current HFN and when the UE100 applies this HFN, the HFN between the gNB200 and the UE100 may become asynchronous.

[0117] 11 is a diagram showing PDCP operation example 2 according to an embodiment. It is assumed that the UE 100 is the UE 100B of the above-described operation example 1, that is, the UE 100 that has joined the MBS session midway.

[0118] As shown in FIG. 11, in step S201, the PDCP entity of UE100 receives a PDCP packet transmitted (e.g., PTM transmitted) from gNB200 in an MBS session.

[0119] In step S202, the PDCP entity of UE 100 acquires the PDCP SN included in the header of the PDCP packet received in step S201. Since UE 100 has joined the MBS session midway, the value of this PDCP SN is assumed to be non-zero.

[0120] In step S203, UE 100 may receive HFN range information from gNB 200. gNB 200 notifies the range (range) of possible HFNs for a certain MBS session. The range may be determined based on the amount of data to be transmitted in the MBS, etc. Note that step S203 may be performed before step S202.

[0121] The HFN value range information may be information that directly indicates the value range of the HFN (for example, "0 to 10"). Alternatively, the HFN value range information may be information that indicates the number of bits of the HFN (for example, "3 bits": equivalent to "0 to 7"). When the HFN value range information is specified as "3 bits", the PDCP entity of UE 100 may manage the HFN so that "0" follows "7".

[0122] The gNB 200 may notify the HFN range information to the UE 100 using a SIB, an MCCH (Multicast Control Channel), an RRC Reconfiguration message, or a PDCP Control PDU. These messages may include the HFN range information and an MBS session identifier (e.g., TMGI, G-RNTI) associated with the HFN range information. These messages may include multiple sets of HFN range information and MBS session identifiers.

[0123] In step S204, the PDCP entity of UE 100 generates a guessed HFN. The PDCP entity of UE 100 generates a guessed HFN by substituting values ​​for the HFN in the order of, for example, 0, 1, 2, etc. If the HFN value range information has been received in step S203, the PDCP entity of UE 100 generates a guessed HFN within the range indicated by the HFN value range information.

[0124] In step S205, the PDCP entity of the UE 100 generates an estimated COUNT including the PDCP SN obtained in step S202 and the estimated HFN generated in step S204.

[0125] In step S206, the PDCP entity of UE 100 attempts to decrypt (decrypt) the PDCP packet received in step S201, using the estimated COUNT generated in step S205. If the decryption of the PDCP packet fails (step S207: NO), the process returns to step S204.

[0126] If the PDCP packet is successfully decoded (step S207: YES), in step S208, the PDCP entity of the UE 100 determines the estimated HFN generated in step S204 as a valid HFN, and stores and manages this HFN. This synchronizes the HFNs between the gNB 200 and the UE 100.

[0127] 11, UE100 may perform handover from the first cell to the second cell of gNB200, RRC re-establishment, or cell reselection. If the MBS session that UE100 has been receiving in the first cell is also provided in the second cell, UE100 can continue MBS reception even after performing handover, RRC re-establishment, or cell reselection. The first cell and the second cell may be managed by different gNB200s.

[0128] Here, in the first cell and the second cell, the PDCP SN may be synchronized between the cells, but the HFN may not be synchronized between the cells. Therefore, the UE 100 may re-execute the same operation as in Fig. 11 in the second cell based on the handover from the first cell to the second cell, the RRC re-establishment, or the cell reselection.

[0129] Before performing handover from the first cell to the second cell, RRC re-establishment, or cell reselection, the UE 100 may receive information from the gNB 200 indicating whether or not it is necessary to re-execute an operation similar to that shown in FIG. 11. If the information indicates that re-execution is not necessary, the UE 100 may retain the managed HFN rather than discard it even after performing handover from the first cell to the second cell, RRC re-establishment, or cell reselection. This eliminates the need for the UE 100 to re-execute an operation similar to that shown in FIG. 11 when the HFNs are synchronized between the first cell and the second cell. Details of such an operation will be described later in Operation Example 6.

[0130] (PDCP operation example 3) Next, a third operational example of the PDCP according to an embodiment will be described, focusing on differences from the first and second operational examples described above.

[0131] As mentioned above, there is no problem if the PDCP SN wraps around because the HFN is counted up when the PDCP SN wraps around. On the other hand, the HFN is not expected to wrap around (i.e., the COUNT does not wrap around). For this reason, it is desirable to be able to initialize a PDCP variable containing the HFN (e.g., COUNT) when the HFN is about to wrap around.

[0132] In operation example 3, the PDCP entity of UE 100 updates the PDCP variables associated with an MBS session in response to receiving a PDCP packet transmitted in the MBS session. When the MBS session is resumed after being interrupted, the PDCP entity of UE 100 initializes the updated PDCP variables (i.e., resets them to zero). In this way, in operation example 3, the PDCP entity of UE 100 initializes the PDCP variables triggered by the resumption of the MBS session. This makes it possible to initialize PDCP variables (e.g., COUNT) including the HFN, for example, when the HFN is about to wrap around.

[0133] 12 is a diagram illustrating a third example of PDCP operation according to an embodiment. UE 100 may be a UE 100 that has joined the MBS session from the beginning. Alternatively, UE 100 may be a UE 100 that has joined the MBS session midway. The gNB 200 may transmit MBS data by multicast to multiple UEs 100 in the RRC connected state.

[0134] As shown in FIG. 12, in step S301, the PDCP entity of UE100 receives a PDCP packet transmitted (e.g., PTM transmitted) from gNB200 in an MBS session.

[0135] In step S302, the PDCP entity of the UE 100 updates a PDCP variable (eg, COUNT) based on the PDCP packet received in step S301. The PDCP variable to be updated may be RX_NEXT and / or RX_DELIV.

[0136] In step S303, the gNB 200 may transmit a session interruption notification indicating the interruption of the MBS session to the UE 100. The session interruption notification may be transmitted by MAC CE. The session interruption notification may be transmitted by SIB, MCCH (Multicast Control Channel), RRC Reconfiguration message, or PDCP Control PDU. The UE 100 detects the interruption of the MBS session in response to receiving the session interruption notification. Alternatively, the UE 100 may determine that the MBS session has been interrupted when it does not receive MBS data in the MBS session for a certain period of time, regardless of the session interruption notification. A timer value that determines this certain period of time may be set to the UE 100 by the gNB 200, for example. The gNB 200 may set a set of this timer value and an MBS session identifier (e.g., TMGI, G-RNTI) to the UE 100.

[0137] Thereafter, in step S304, the gNB 200 may transmit a session resumption notification indicating the resumption of the MBS session to the UE 100. The session resumption notification may be transmitted by a MAC CE. The session resumption notification may be transmitted by an SIB, an MCCH (Multicast Control Channel), an RRC Reconfiguration message, or a PDCP Control PDU. The UE 100 detects the resumption of the MBS session in response to receiving the session resumption notification. Alternatively, the UE 100 may determine that the MBS session has been resumed when it receives MBS data in the MBS session after determining that the MBS session has been suspended, regardless of the session resumption notification.

[0138] In step S305, the PDCP entity of the UE 100 initializes (i.e., resets to zero) updated PDCP variables associated with the MBS session when the MBS session is resumed after being suspended. Similarly, the gNB 200 may initialize updated PDCP variables associated with the MBS session.

[0139] In step S306, the PDCP entity of UE100 receives PDCP packets transmitted from gNB200 in the MBS session.

[0140] In step S307, the PDCP entity of the UE 100 updates a PDCP variable (eg, COUNT) based on the PDCP packet received in step S306.

[0141] In this operation example 3, when the UE 100 detects the interruption of the MBS session in step S303, the UE 100 may initialize the PDCP variables.

[0142] In this operation example 3, when UE 100 detects interruption of the MBS session in step S303 or detects resumption of the MBS session in step S304, UE 100 may re-establish a PDCP entity in step S305. The RRC layer in UE 100 may instruct the PDCP layer to re-establish the PDCP entity. When the PDCP entity is re-established, PDCP variables managed by the PDCP entity are initialized.

[0143] (PDCP operation example 4) Next, a fourth operational example of the PDCP according to an embodiment will be described, focusing on differences from the first to third operational examples described above.

[0144] In the above-described operation example 3, an example was described in which the UE 100 spontaneously initializes the PDCP variables. In contrast, in this operation example 4, the UE 100 initializes the PDCP variables in accordance with reception of an instruction from the gNB 200.

[0145] For example, assume that, in a situation where multiple UEs 100 are receiving MBS data from a gNB 200 via multicast for a certain MBS session, one of the multiple UEs 100 performs handover or RRC re-establishment. Normally, the PDCP entity of the UE 100 is re-established upon handover or RRC re-establishment of the UE 100, and therefore the PDCP variables managed by the PDCP entity are initialized. Alternatively, as described in the above-mentioned PDCP operation example 3, it is necessary to initialize the PDCP variables of one or more UEs receiving the MBS session before the COUNT of the MBS session reaches the upper limit (i.e., when it is about to wrap around).

[0146] In this operation example 4, the PDCP entity of UE 100 updates the PDCP variables associated with the MBS session in response to receiving a PDCP packet transmitted in the MBS session. When the PDCP entity of UE 100 receives an instruction to initialize the PDCP variables from gNB 200, it initializes the updated PDCP variables (i.e., resets them to zero). This makes it possible to initialize PDCP variables including the HFN (e.g., COUNT) when, for example, the HFN is about to wrap around. As described above, since the PDCP variables are initialized when the PDCP entity is re-established, the instruction to initialize the PDCP variables may be an instruction to re-establish the PDCP entity.

[0147] 13 is a diagram showing a fourth example of PDCP operation according to an embodiment. UE 100 may be a UE 100 that has joined the MBS session from the beginning. Alternatively, UE 100 may be a UE 100 that has joined the MBS session midway. The gNB 200 may transmit MBS data by multicast to multiple UEs 100 in an RRC connected state. The gNB 200 may transmit MBS data by multicast to multiple UEs 100 in an RRC idle or inactive state.

[0148] As shown in FIG. 13, in step S401, the PDCP entity of UE100 receives a PDCP packet transmitted (e.g., PTM transmitted) from gNB200 in an MBS session.

[0149] In step S402, the PDCP entity of the UE 100 updates a PDCP variable (e.g., COUNT) based on the PDCP packet received in step S401. The updated PDCP variable may be RX_NEXT and / or RX_DELIV. Similarly, the PDCP entity of the gNB 200 updates a PDCP variable (e.g., COUNT) based on the packet transmitted in step S401.

[0150] Thereafter, in step S403, the gNB 200 transmits an initialization instruction to the UE 100 to instruct the UE 100 to initialize the PDCP variables. As described above, the initialization instruction may be an instruction to re-establish the PDCP entity. The gNB 200 may stop (temporarily stop) transmission of PDCP packets before transmitting the initialization instruction. The gNB 200 may transmit the initialization instruction in response to the PDCP variables of the PDCP entity of the gNB 200 being about to wrap around (for example, when the COUNT upper limit value is reached). The initialization instruction may be transmitted via an RRC Reconfiguration message, a PDCP Control PDU, an SIB, or an MCCH (Multicast Control Channel). The initialization instruction may be transmitted via a MAC CE (Control Element) or an MTCH (Multicast Traffic Channel). Note that it is desirable that the initialization instruction be notified to multiple UEs simultaneously. For example, a MAC CE indicating the initialization instruction may be multiplexed and notified in a transport block including the MTCH to be multicast. These messages may include an initialization instruction and an MBS session identifier (e.g., TMGI, G-RNTI, Session ID) associated with the initialization instruction. A bearer ID (or MBS bearer ID) may be used in addition to or instead of the MBS session identifier.

[0151] The gNB 200 may transmit the initialization instruction in step S403 in response to another UE 100 that receives the same MBS session as the UE 100 via multicast re-establishing a PDCP entity, i.e., in response to the other UE 100 initializing the PDCP variables. As a result, all of the multiple UEs 100 that receive the same MBS session will initialize the PDCP variables.

[0152] In step S404, the PDCP entity of the UE 100 initializes (i.e., resets to zero) the updated PDCP variables associated with the MBS session in response to receiving the initialization instruction in step S403. Similarly, the gNB 200 may initialize the updated PDCP variables associated with the MBS session. The initialization of the PDCP variables may be performed upon re-establishment of the PDCP entity.

[0153] In step S405, the PDCP entity of the UE 100 receives PDCP packets transmitted in the MBS session from the gNB 200. The gNB 200 may resume transmission of PDCP packets in response to the completion of initialization of the PDCP variables of all UEs receiving the multicast.

[0154] In step S406, the PDCP entity of the UE 100 updates a PDCP variable (eg, COUNT) based on the PDCP packet received in step S406.

[0155] Note that, in the above-described operation example 3, similarly to operation example 4, when one UE 100 among the multiple UEs 100 receiving the same MBS session re-establishes a PDCP entity, the other UEs 100 among the multiple UEs 100 may operate to initialize PDCP variables. For example, when one UE 100 among the multiple UEs 100 receiving the same MBS session re-establishes a PDCP entity, the gNB 200 suspends the MBS session and then resumes the MBS session. As a result, all of the multiple UEs 100 receiving the same MBS session initialize their PDCP variables.

[0156] (PDCP operation example 5) Next, a fifth operational example of the PDCP according to an embodiment will be described, focusing on differences from the first to fourth operational examples described above.

[0157] In the above-described operation example 4, an example has been described in which, when a UE 100 re-establishes a PDCP entity, the UE 100 initializes PDCP variables. In this case, as described above, other UEs 100 that receive the same MBS session via multicast may also need to initialize PDCP variables. In other words, re-establishment of a PDCP entity in one UE 100 that receives the same MBS session via multicast may adversely affect the other UEs 100.

[0158] For this reason, in this operation example 5, even if the PDCP entity for the MBS session (MBS bearer) is re-established, the PDCP variables are not initialized and the PDCP variables before re-establishment are continued to be used. That is, the PDCP entity of UE 100 updates the PDCP variables associated with the MBS session in response to reception of PDCP packets transmitted in the MBS session. When the PDCP entity is re-established, UE 100 retains the PDCP variables associated with the MBS session without initializing them. The PDCP entity of UE 100 continues reception processing (PDCP operation) of PDCP packets transmitted in the MBS session based on the retained PDCP variables. This makes it possible to prevent the re-establishment of the PDCP entity in one UE 100 receiving the same MBS session via multicast from adversely affecting other UEs 100.

[0159] 14 is a diagram illustrating a fifth example of PDCP operation according to an embodiment. UE 100 may be a UE 100 that has joined the MBS session from the beginning. Alternatively, UE 100 may be a UE 100 that has joined the MBS session midway. The gNB 200 may transmit MBS data by multicast to multiple UEs 100 in the RRC connected state.

[0160] As shown in FIG. 14, in step S501, the PDCP entity of UE100 receives a PDCP packet transmitted (e.g., PTM transmitted) from gNB200 in an MBS session.

[0161] In step S502, the PDCP entity of the UE 100 updates a PDCP variable (eg, COUNT) based on the PDCP packet received in step S401. The PDCP variable to be updated may be RX_NEXT and / or RX_DELIV.

[0162] In step S503, UE 100 re-establishes a PDCP entity in response to handover or RRC re-establishment. That is, UE 100 deletes the old PDCP entity before handover or RRC re-establishment and generates a new PDCP entity. However, it is assumed that the PDCP variables updated by the old PDCP entity can be retained in a predetermined storage area. Note that UE 100 may receive a re-establishment instruction from gNB 200 instructing the re-establishment of the PDCP entity, and re-establish the PDCP entity in response to the reception of this re-establishment instruction.

[0163] In step S504, UE 100 determines whether the PDCP entity involved in the re-establishment is associated with an MBS session. UE 100 may determine whether the PDCP entity involved in the re-establishment is configured to retain PDCP variables without initializing them. Such configuration may be performed by the gNB 200 to UE 100, for example, by an RRC Reconfiguration message. When UE 100 receives a re-establishment instruction from the gNB 200 instructing the re-establishment of the PDCP entity, UE 100 may determine whether the re-establishment instruction includes information indicating that the PDCP variables are to be retained without being initialized (for example, "COUNT-continued=true"). If the determination in step S504 is "NO", in step S505 UE 100 initializes the PDCP variables updated in step S502.

[0164] If the answer is "YES" in step S504, in step S506, the UE 100 retains the PDCP variables updated in step S502 without initializing them, i.e., the UE 100 resets the PDCP variables retained in a predetermined storage area to the new PDCP entity related to the re-establishment.

[0165] In step S507, the PDCP entity of UE100 receives PDCP packets transmitted from gNB200 in the MBS session.

[0166] In step S508, the PDCP entity of the UE 100 updates a PDCP variable (eg, COUNT) based on the PDCP packet received in step S507.

[0167] In addition, UE100 may re-establish a PDCP entity in response to performing handover or RRC re-establishment from the first cell of gNB200 to the second cell (step S503). If UE100 has been notified by gNB200 before performing handover or RRC re-establishment that PDCP variables can continue to be used in the second cell, UE100 may retain the PDCP variables without initializing them even after performing handover or RRC re-establishment. Such notification information may be transmitted by gNB200 to UE100 in the first cell using an RRC Reconfiguration message or SIB. Operations related to such operations will be described later in Operation Example 6.

[0168] (PDCP operation example 6) Next, a sixth operational example of PDCP according to an embodiment will be described, focusing on differences from the above-described first to fifth operational examples. Fig. 15 is a diagram illustrating the sixth operational example of PDCP according to an embodiment.

[0169] As shown in Fig. 15, the UE 100 may perform handover from a cell C1 (first cell) to a cell C2 (second cell), RRC re-establishment, or cell reselection. Fig. 15 illustrates an example in which the gNB 200A that manages the cell C1 is different from the gNB 200B that manages the cell C2.

[0170] If the MBS session that UE 100 has been receiving in cell C1 is also provided in cell C2, UE 100 can continue receiving MBS even if handover, RRC re-establishment, or cell reselection is performed. Here, even if the PDCP SNs are synchronized between cells in cell C1 and cell C2, the HFNs may not be synchronized between cells. If the HFNs are not synchronized between cells C1 and C2, UE 100 needs to synchronize with the HFN in cell C2, i.e., the HFN managed by gNB 200B, when moving from cell C1 to cell C2.

[0171] In this operation example 6, first, the PDCP entity of the UE 100 updates a PDCP variable (e.g., COUNT) associated with the MBS session in response to reception of a PDCP packet transmitted in the MBS session (step S601). The PDCP variable to be updated may be RX_NEXT and / or RX_DELIV.

[0172] Second, before performing handover from cell C1 to cell C2, RRC re-establishment, or cell reselection, UE 100 receives from the gNB 200A notification information indicating whether the updated PDCP variables can continue to be used in cell C2 (step S602). It is assumed that the gNB 200A knows whether the HFNs are synchronized between cells C1 and C2, for example, through inter-base station communication with the gNB 200B. If the HFNs are synchronized between cells C1 and C2, the gNB 200A transmits notification information indicating that the updated PDCP variables can continue to be used in cell C2. On the other hand, if the HFNs are not synchronized between cells C1 and C2, the gNB 200A transmits notification information indicating that the updated PDCP variables cannot continue to be used in cell C2. The gNB 200A may transmit the notification information using an SIB, an MCCH, an RRC Reconfiguration, or a PDCP Control PDU.

[0173] The notification information may include information indicating an area consisting of one or more cells that can continue to use the updated PDCP variables. For example, the notification information may include a cell ID list consisting of cell IDs of cells that can reuse the PDCP variables used in cell C1.

[0174] Third, the UE 100 performs handover from cell C1 to cell C2, RRC re-establishment, or cell reselection (step S603). Here, if the notification information indicates that the PDCP variables (e.g., COUNT) used in cell C1 can also be used in cell C2, the PDCP entity of the UE 100 continues to use the PDCP variables held in cell C2 and receives PDCP packets from cell C2 (step S604). On the other hand, if the notification information indicates that the PDCP variables used in cell C1 cannot be used in cell C2, the PDCP entity of the UE 100 derives the PDCP variables from the PDCP packet first received in cell C2 (see the above-mentioned operation example 1). Alternatively, if the UE 100 is notified of the HFN used in cell C2 by the gNB 200B, the UE 100 may derive the PDCP variables using the notified HFN.

[0175] (Example of RLC operation) Next, an example of the operation of RLC according to an embodiment will be described. Figures 16 and 17 are diagrams for explaining an example of the operation of RLC according to an embodiment. In this example of operation, the RLC entity of UE 100 receives from gNB 200 an RLC PDU (Protocol Data Unit) that is transmitted in an MBS session and that is obtained by gNB 200 dividing an RLC SDU (Service Data Unit).

[0176] As shown in FIG. 16, in this operation example, it is assumed that the RLC entity of the gNB 200 performs segmentation processing of a PDCP packet (i.e., an RLC SDU) (step S701). Such segmentation processing is sometimes called segmentation. The RLC entity of the gNB 200 assigns a sequence number (SN) to each segment obtained by the segmentation processing to obtain an RLC PDU. FIG. 16 illustrates an example in which the packet is segmented into a total of six RLC PDUs (six segments), SN#0 to #5. The RLC entity of the UE 100 cannot reconstruct the original PDCP packet (RLC SDU) unless it receives all six RLC PDUs. Such a reconstructing processing is sometimes called reassembly. It is assumed that in this operation example, the Unacknowledged Mode (UM) is applied to the RLC.

[0177] In the case of unicast, UE 100 starts receiving from the first RLC PDU (i.e., RLC PDU of SN#0), so there is no major problem. In contrast, in the case of multicast, UE 100 may join an MBS session midway, so it is not necessarily able to receive from RLC PDU of SN#0. If UE 100 cannot receive RLC PDU of SN#0, reconstruction into RLC SDU cannot be completed. RLC SDUs that cannot be reconstructed will be discarded when the timer (T-Reassembly) expires.

[0178] However, when in-order delivery is configured to deliver PDCP packets (RLC SDUs) to the upper layer (i.e., PDCP) in the correct order, there is a problem that delays occur because the next PDCP packet cannot be delivered to the upper layer until the reassembly timer (T-Reassembly) expires.

[0179] In this operation example, when the RLC sequence number included in the RLC PDU first received from the gNB 200 is zero, the RLC entity of the UE 100 that joined the MBS session midway reconstructs an RLC SDU from the first received RLC PDU and the RLC PDUs that follow the first received RLC PDU. In Fig. 16, the RLC entity of the UE 100 has been able to receive RLC PDUs starting from the first RLC PDU (i.e., the RLC PDU with SN#0) (step S702). Therefore, the RLC entity of the UE 100 reconstructs the RLC SDU when all RLC PDUs with SN#0 to #5 are received (step S703), and passes the RLC SDU to an upper layer (i.e., PDCP).

[0180] On the other hand, as shown in FIG. 17 , if the RLC sequence number included in the RLC PDU first received from the gNB 200 is not zero, the RLC entity of the UE 100 discards the first received RLC PDU and any RLC PDUs subsequent to the first received RLC PDU. Specifically, if the RLC sequence number included in the RLC PDU first received from the gNB 200 is not zero, the RLC entity of the UE 100 discards the first received RLC PDU and any RLC PDUs subsequent to the first received RLC PDU, even if the timer (T-Reassembly) has not expired. In this way, by determining whether to reconstruct RLC SDUs from the first received RLC PDU and any RLC PDUs subsequent to the first received RLC PDU based on the RLC sequence number included in the RLC PDU first received from the gNB 200, packets that cannot be reconstructed can be discarded early, thereby suppressing delays.

[0181] 17, the RLC entity of UE 100, which has joined the MBS session midway, checks the sequence number of the RLC PDU first received from gNB 200 and detects that this sequence number is SN#2 (step S711). In this case, the RLC entity of UE 100 discards the RLC PDU of SN#2 and the subsequent RLC PDUs of SN#3 to #5 even if the timer (T-Reassembly) has not expired.

[0182] In this operation example, in order to minimize PDCP packet discarding, it is desirable for gNB200 to reduce the number of RLC divisions in MBS transmission.

[0183] (Other embodiments) The above-described first to sixth operational examples of PDCP according to the embodiment may be applied to the operation of RLC. That is, "PDCP" in the above-described first to sixth operational examples of PDCP according to the embodiment may be read as "RLC."

[0184] The above-described operational flows are not limited to being implemented independently, but can also 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.

[0185] 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 also 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.

[0186] 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 on a computer-readable medium. Using the computer-readable medium, the program can be installed on a computer. Here, the computer-readable medium on which the program is recorded may be a non-transitory recording medium. The non-transitory recording medium is not particularly limited, and may be, for example, a recording medium such as a CD-ROM or a DVD-ROM.

[0187] 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 (System on a chip)).

[0188] 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 can be made within the scope that does not deviate from the gist of the invention.

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

[0190] (Addendum) (PDCP operation) Initial values ​​of the state variables Although the current agreement specifies only RLC UM mode, for service continuity purposes, it is worth considering ways to minimize packet loss at the start of MBS data reception and during dynamic PTM / PTP switching.

[0191] As shown in Figure 18, when reusing the existing PDCP functional view, the PDCP SN is common to both the PTM leg and the PTP leg. Because the PTM leg is used by multiple UEs, the PDCP SN may not be UE-specific and affects both the PTM leg and the PTP leg. This means that if a UE joins a multicast session late, the initial value of each state variable may not always be "0," regardless of whether the first MBS data received is from the PTM leg or the PTP leg. In other words, the PDCP SN initially received by the UE may be any value that is not expected for the current unicast transmission. Also, because the state variables are set to their initial values, PDCP re-establishment for one UE may affect all other UEs. This can lead to unexpected behavior in the receive window, i.e., PDCP PDUs outside the receive window are discarded.

[0192] Observation 2: When a UE joins a multicast session late and two legs are associated with one MRB, the SN of the first received PDCP PDU is not the initial value, i.e., "0", regardless of whether the first received data is from the PTM leg or the PTP leg.

[0193] To solve this problem, the following options were proposed:

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

[0195] This option allows the UE to receive the first transmission of MBS data using existing mechanisms by simply modifying the initial values ​​related to the reception window based on information from the gNB. However, from the PDCP layer perspective, it is doubtful whether the UE will always be able to successfully receive the first transmission intended by the gNB, e.g., due to switching delays, poor radio conditions, or being outside the RLC reconfiguration window. In this case, it is unclear how this option would work.

[0196] Option B: The gNB notifies the UE of the initial HFN, and the UE infers the initial HFN and SN from the first received PDCP PDU.

[0197] Regarding the SN part, this option is similar to the V2X mechanism in Rel-16: for broadcast and groupcast NR sidelink communications, the initial value of the SN part of RX_NEXT is (x+1) modulo (2 [sl-PDCP-SN-Size] ), where x is the SN of the first received PDCP data PDU” and “For broadcast and groupcast NR sidelink communications, the initial value of the SN portion of RX_DELIV is (x-0.5×2 [sl-PDCP-SN-Size-1] ) modulo(2 [sl-PDCP-SN-Size] ), where x is the SN of the first received PDCP data PDU.

[0198] Regarding the HFN portion, the Rel-16 V2X mechanism does not require transmitter and receiver synchronization. In other words, since the HFN is not used for security, "Note: It is up to the UE implementation to select the HFN for RX_NEXT so that the initial value of RX_DELIV is positive." In the case of NR MBS, "RAN2 waits for SA3 to finish investigating the security of the MBS before replying to explain the security aspects of RAN2." Therefore, if the HFN portion needs to be notified at this time, RAN2 must be postponed.

[0199] Based on the above observations, Option B should be the baseline for further discussion. According to Rel-16 sidelink communications for broadcast and groupcast, and considering the progress of SA3 on security for NR MBS, RAN2 should at least agree to allow the UE to set the initial values ​​of state variables from the first received PDCP PDU of MBS data.

[0200] Proposal 3: RAN2 should agree to set the initial value of the SN part of RX_NEXT and RX_DELIV from the first MBS data received by the UE, regardless of whether it is a PTM leg or a PTP leg. Depending on the progress of SA3, further consideration is needed as to whether the HFN part is notified by the gNB.

[0201] (Simultaneous reception and UE assistance information) If Proposal 2 is acceptable, the UE must support simultaneous reception from both the PTM leg and the PTP leg. This means that two legs can be activated simultaneously, similar to existing PDCP packet duplication. Because the PTP leg is received by multiple UEs, i.e., it is not UE-specific, it is considered beneficial for dynamic PTM / PTP switching, as it allows for easy compensation of missing packets not received via the PTM leg. Therefore, RAN2 must agree to simultaneous reception for at least a certain period of time during dynamic PTM / PTP switching.

[0202] Proposal 4: RAN2 should agree that the UE supports simultaneous reception from both the PTM leg and the PTP leg for a certain period of time after dynamic PTM / PTP switching. If Proposal 3 and Proposal 4 are agreeable, the gNB may not actually know the PDCP SN that the UE has successfully started receiving over the PTM leg. In the case of a PTP-to-PTM switch, this means that the gNB may not know which PDCP PDUs need to be sent over the PTP leg and / or when the PTP leg can be deactivated. To solve this problem, it is proposed that the UE notify the gNB of successful PTM reception, which can then be sent over the PTP leg if it has not yet been deactivated. However, it is unclear whether this solution intends to include the PDCP SN in the information.

[0203] Similarly, in the case of a PTM to PTP switch, the gNB may not be aware of the PDCP SN that the UE has finished receiving over the PTM leg, which means that the gNB may not be aware of the PDCP PDU that it starts transmitting over the PTP leg. Therefore, it can be assumed that the UE informs the gNB of the SN information over the activated PTP leg during dynamic PTM / PTP switching.

[0204] If the UE reports SN information during dynamic switching between PTM and PTP, it is easy to reuse the PDCP control PDU. The PDCP status report contains the FMC (first missing PDCP SDU) and an optional bitmap (indicating that the next PDCP SDU is missing or correctly received). On the other hand, reporting the first / last successful PDCP SDU reception over the PTM leg is another option. Therefore, further discussion is needed on what needs to be reported during dynamic switching between PTM and PTP.

[0205] In both of the above cases (i.e., PTP to PTM and PTM to PTP), a PDCP control PDU needs to be triggered upon dynamic switching (e.g., by an activating / deactivating MAC CE) containing PDCP SN information for service continuity.

[0206] Proposal 5: For service continuity, RAN2 should consider whether the UE should send PDCP control PDUs containing PDCP SN information during dynamic switching. The type of PDCP control PDU to be used and the exact meaning of the SN information require further study. [Explanation of symbols]

[0207] 10:NG-RAN (5G RAN) 20:5GC(5G CN) 100:UE 110: Receiving unit 120: Transmitter 130: Control unit 200 :gNB 210: Transmission unit 220: Receiving unit 230: Control unit 240: Backhaul communication unit

Claims

1. A communication control method executed by a user device in a mobile communication system in which a base station provides a multicast broadcast service (MBS) to the user device, comprising: The user equipment receives configuration information related to PDCP from the base station; The user equipment performs a handover or RRC re-establishment from a first cell to a second cell of the base station; The setting information includes notification information indicating whether or not predetermined information regarding the setting of the PDCP for the MBS is to be continuously used at the time of the handover or the time of the RRC re-establishment. Communication control method.

2. If the notification information indicates that the user equipment continues to use the predetermined information, the user equipment continues to use the predetermined information after the handover or the RRC re-establishment. The communication control method according to claim 1.

3. A user device in a mobile communication system that provides a multicast broadcast service (MBS) from a base station to the user device, a receiving unit that receives setting information related to PDCP from the base station; a control unit that performs handover or RRC re-establishment from a first cell to a second cell of the base station, The setting information includes notification information indicating whether or not predetermined information regarding the setting of the PDCP for the MBS is to be continuously used at the time of the handover or the time of the RRC re-establishment. User equipment.

4. A mobile communication system that provides a multicast broadcast service (MBS) from a base station to a user device, comprising: The user equipment receives configuration information regarding PDCP from the base station; the user equipment performs handover or RRC re-establishment from the first cell to the second cell of the base station; The setting information includes notification information indicating whether or not predetermined information regarding the setting of the PDCP for the MBS is to be continuously used at the time of the handover or the time of the RRC re-establishment. Mobile communication system.

5. A chip set for a user device in a mobile communication system that provides a multicast broadcast service (MBS) from a base station to the user device, comprising: The user equipment receives configuration information related to PDCP from the base station; The user equipment performs a handover or RRC re-establishment from a first cell to a second cell of the base station; The setting information includes notification information indicating whether or not predetermined information regarding the setting of the PDCP for the MBS is to be continuously used at the time of the handover or the time of the RRC re-establishment. Chipset.

6. In a mobile communication system in which a base station provides a multicast broadcast service (MBS) to a user device, receiving setting information related to PDCP from the base station; and performing a process of handover or RRC re-establishment from the first cell to the second cell of the base station; The setting information includes notification information indicating whether or not predetermined information regarding the setting of the PDCP for the MBS is to be continuously used at the time of the handover or the time of the RRC re-establishment. program.

Images