Communication control method and user equipment

Abstract

To provide a communication control method and user equipment for achieving an improved multicast / broadcast service (MBS).SOLUTION: A communication control method includes a UE 100 receiving, from a base station gNB200, a packet data convergence protocol (PDCP) packet transmitted in an MBS session S201; generating an inferred hyper frame number (HFN) by inferring the hyper frame number S204; generating an inferred count including a PDCP sequence number included in the PDCP packet received and the inferred HFN S205; attempting decoding of the PDCP packet by using the inferred count S206; and determining the inferred HFN as a valid hyper frame number when the decoding is successful S208.SELECTED DRAWING: Figure 11

Description

[Technical field]

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

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

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

[0004] A communication control method according to a first aspect is a method executed by a user device 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 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 a guessed count value consisting of the PDCP sequence number and the guessed hyperframe number included in the received PDCP packet, and determining the guessed hyperframe number as a valid hyperframe number if the decoding is successful.

[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 a PDCP packet 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, retaining the PDCP variables associated with the MBS session without initializing them when the PDCP entity is re-established, and the PDCP entity continuing a reception process of the PDCP packets transmitted in the MBS session based on the retained PDCP variables.

[0007] A communication control method according to a fourth 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 a PDCP packet transmitted in the MBS session; and receiving, from the base station, notification information indicating whether the updated PDCP variables can be continuously used in the second cell before the user device performs a handover, an RRC re-establishment, or a 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 a user device, the communication control method including: an RLC entity of the user device receiving from the base station an RLC PDU that is transmitted in an MBS session and that is obtained by dividing an RLC SDU by the base station; and determining, based on an RLC sequence number included in the RLC PDU that is first received from the base station, whether to reconstruct the RLC SDU from the first received RLC PDU and an RLC PDU 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 description of the drawings]

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

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

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

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

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

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

[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 receptions under the control of the control unit 130. The receiving unit 110 includes an antenna and a receiver. The receiver converts a radio signal received by the antenna into a baseband signal (received signal) and outputs the baseband signal to the control unit 130.

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

[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 the processing by the processor. The processor may include a baseband processor and a CPU (Central Processing Unit). The baseband processor performs modulation / demodulation and encoding / decoding of baseband signals. The CPU executes programs stored in the memory to perform various processing.

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

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

[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 receptions under the control of the control unit 230. The receiving unit 220 includes an antenna and a receiver. The receiver converts a radio signal received by the antenna into a baseband signal (received signal) and outputs the baseband signal to the control unit 230.

[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 the processing by the processor. The processor may include a baseband processor and a CPU. The baseband processor performs modulation / demodulation and encoding / decoding of baseband signals. The CPU executes programs stored in the memory to perform various processing.

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

[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 FIG. 4, the user plane radio interface protocol includes a physical (PHY) layer, a medium access control (MAC) layer, a radio link control (RLC) layer, a packet data convergence protocol (PDCP) layer, and a service data adaptation protocol (SDAP) layer.

[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 the UE 100 and the MAC layer of the gNB 200 via a transport channel. The MAC layer of the gNB 200 includes a scheduler. The scheduler determines the uplink and downlink transport format (transport block size, modulation and coding scheme (MCS)) and the resource blocks to be assigned to the UE 100.

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

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

[0037] The SDAP layer maps IP flows, which are units for QoS (Quality of Service) control by the core network, to radio bearers, which are units for QoS control by the AS (Access Stratum). Note that if the RAN is connected to the EPC, the 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] Between the RRC layer of the UE 100 and the RRC layer of the gNB 200, RRC signaling for various settings is transmitted. The RRC layer controls logical channels, transport channels, and physical channels according to the establishment, re-establishment, and release of radio bearers. When there is a connection (RRC connection) between the RRC of the UE 100 and the RRC of the gNB 200, the UE 100 is in an RRC connected state. When there is no connection (RRC connection) between the RRC of the UE 100 and the RRC of the gNB 200, the UE 100 is in an RRC idle state. When the connection between the RRC of the UE 100 and the RRC of the gNB 200 is suspended, the UE 100 is in an RRC inactive state.

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

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

[0043] (MBS) Next, an MBS according to an 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 be called a multimedia broadcast and multicast service (MBMS). Note that use cases (service types) of the MBS include public safety communication, mission critical communication, vehicle to everything (V2X) communication, IPv4 or IPv6 multicast distribution, Internet protocol television (IPTV), group communication, 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 a 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 MTCH (Multicast Traffic Channel) and MCCH (Multicast Control Channel), and the transport channel used for MBSFN transmission is MCH (Multicast Channel). MBSFN transmission is designed mainly for multi-cell transmission, and in an MBSFN area consisting of multiple cells, each cell synchronously transmits the same signal (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 designed primarily for single-cell transmission, and transmits data by broadcast or multicast on a cell-by-cell basis. The physical channels used for SC-PTM transmission are the 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] In addition, MBS data refers to data provided by MBS, MBS control channel refers to MCCH or SC-MCCH, and MBS traffic channel refers to MTCH or SC-MTCH. However, MBS data may be transmitted by unicast. MBS data may also be called 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 be called an MBS service identifier or a multicast group identifier.

[0050] FIG. 7 is a diagram showing a method for delivering 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 (replication) of the MBS data, and distributes it.

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

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

[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 the individual MBS data delivery, a unicast session is established between the NG-RAN 10 and the UE 100, and the MBS data is delivered individually from the 5GC 20 to the UE 100. Such a unicast may be called a PDU session. The unicast (PDU session) is terminated at the UE 100.

[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, appropriately referred to as a "split MBS bearer") to the UE100. This allows the gNB200 to dynamically switch the transmission of MBS data to the UE100 between PTP (PTP communication path) and PTM (PTM communication path). Alternatively, the gNB200 can enhance reliability by dually transmitting the same MBS data using both PTP (PTP communication path) and PTM (PTM communication path).

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

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

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

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

[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 the gNB 200 to the UE 100 using a PTM leg, a split MBS bearer needs to be set from the gNB 200 to the UE 100, and the PTM leg needs to be activated. In other words, even if a split MBS bearer is set to the UE 100, the gNB 200 cannot perform PTM transmission of MBS data using this PTM leg if the PTM leg is in a deactivation state.

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

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

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

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

[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 configured 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. Fig. 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), the gNB 200 may instruct the UE 100 of the initial state of each leg (i.e., activation or deactivation of each leg) using the same message. When the RRC entity of the gNB 200 transmits an RRC message including bearer setup of the split MBS bearer to the UE 100, the RRC entity of the gNB 200 includes an instruction to activate or deactivate each leg in the RRC message together with the bearer setup.

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

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

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

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

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

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

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

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

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

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

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

[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 in the leg.

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

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

[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 the UE 100 sets and updates PDCP variables according to the PDCP sequence number (PDCP SN) included in the PDCP packet received from the gNB 200. Usually, the UE 100 sets the initial value of the PDCP variable to zero, and updates (increments, counts up) the PDCP variable in response to reception of a packet from the gNB 200.

[0090] The PDCP entity of UE 100 that has participated in an MBS session from the beginning can sequentially update the PDCP variables to the latest state. On the other hand, the 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, and may not be able to operate the PDCP entity normally (predetermined PDCP operation).

[0091] In the operation example 1, the following method enables UE 100 that has joined an 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 normally perform a predetermined PDCP operation.

[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 the receive 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 that is waiting to be received and has not yet been provided to the upper layer. Usually, 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 operation example of the 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 the setting of an MBS bearer (PDCP) from the gNB 200.

[0098] In step S103, the gNB 200 transmits a PDCP packet by 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 the UE 100A receives a PDCP packet from the gNB 200, it sets the PDCP SN “0” contained in the received PDCP packet as the initial value of a PDCP variable and performs a predetermined PDCP operation.

[0100] After that, 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 the setting 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 equal to or greater than 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" included in the first received PDCP packet as the initial value of the PDCP variable, and performs a predetermined PDCP operation. For example, the PDCP entity of the UE 100B sets RX_DELIV=sequence number "n" of the packet, and sets RX_NEXT=sequence number "n" of the packet. Alternatively, it may set it to (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 by 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 value of each PDCP variable is updated from the received PDCP packet, but this is not limited to the above. The initial value of each PDCP variable may be set in the UE 100 by the gNB 200. For example, the UE 100B that performs MBS mid-reception may be given the initial value 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 operation example of the PDCP according to an embodiment will be described, focusing mainly on differences from the above-described first operation example.

[0109] In the above-mentioned operation example 1, the PDCP SN is 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 when 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 that of COUNT, which is HFN+SN. COUNT is also used for encrypting PDCP packets for security purposes.

[0111] In the above-mentioned operation example 1, the UE 100B that joins the MBS session midway calculates RX_DELIV from the PDCP SN included in the header of the PDCP packet (PDCP PDU) that is first received 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 every time the PDCP SN is wrapped 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 undefined from which RX_DELIV UE 100 starts receiving PDCP packets, so there is a problem that a valid HFN (i.e., the HFN managed by gNB 200) cannot be determined by looking at only the received PDCP packets.

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

[0114] As a result, even if UE 100 joins an MBS session halfway through, 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, UE100 may receive value range information indicating a value range of an HFN (hereinafter, referred to as "HFN value range information") from gNB200. The PDCP entity of UE100 may generate a guessed HFN based on the received HFN value range information. For example, an HFN included in the value range indicated by the received HFN value range information is generated as a guessed HFN. Since calculation processing is required to decrypt an encrypted PDCP packet, there is a problem with the power consumption and response time of UE100. Therefore, by having gNB200 notify UE100 of possible HFNs in advance, the number of guessed HFN candidates generated by the PDCP entity of UE100 can be reduced, and the power consumption and response time of UE100 can be reduced.

[0116] It is also possible for the gNB 200 to notify the UE 100 of the HFN value itself. However, the HFN is counted up according to the count up of the PDCP SN. Since a delay may occur between the time when the gNB 200 notifies the UE 100 of the current HFN and the time when the UE 100 applies this HFN, the HFN may become asynchronous between the gNB 200 and the UE 100.

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

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

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

[0120] In step S203, the UE 100 may receive HFN range information from the gNB 200. The 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 range information may be information that directly indicates the range of the HFN (e.g., "0 to 10"). The HFN range information may also be information that indicates the number of bits of the HFN (e.g., "3 bits": equivalent to "0 to 7"). When the HFN range information is specified as "3 bits", the PDCP entity of UE 100 may manage the HFN so that the next bit after "7" is "0".

[0122] The SIB, the MCCH (multicast control channel), the RRC Reconfiguration message, or the PDCP Control PDU may be used to notify the HFN range information from the gNB 200 to the UE 100. These messages may include the HFN range information and the MBS session identifier (e.g., TMGI, G-RNTI) associated with the HFN range information. These messages may include multiple sets of the HFN range information and the MBS session identifier.

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

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

[0125] In step S206, the PDCP entity of the 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 guessed HFN generated in step S204 as a valid HFN, and stores and manages this HFN. This causes the HFNs between the gNB 200 and the UE 100 to be synchronized.

[0127] After the operation shown in Fig. 11, UE 100 may perform handover from the first cell to the second cell of gNB 200, RRC re-establishment, or cell reselection. If the MBS session that UE 100 has been receiving in the first cell is also provided in the second cell, UE 100 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 gNBs 200.

[0128] Here, in the first cell and the second cell, the PDCP SN is 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 the same operation as in FIG. 11. If the information indicates that re-execution is unnecessary, the UE 100 may hold the managed HFN instead of discarding it even if it performs 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 the same operation as in FIG. 11 when the HFN is 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 operation example of the PDCP according to an embodiment will be described, focusing mainly on differences from the first and second operation examples described above.

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

[0132] In the third operation example, 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 MBS session is resumed after the MBS session is interrupted, the PDCP entity of UE 100 initializes the updated PDCP variables (i.e., resets them to zero). In this way, in the third operation example, the PDCP entity of UE 100 initializes the PDCP variables using the resumption of the MBS session as a trigger. This makes it possible to initialize the PDCP variables (e.g., COUNT) including the HFN when, for example, the HFN is about to wrap around.

[0133] 12 is a diagram showing a third operation example of PDCP according to an embodiment. The UE 100 may be a UE 100 that has joined the MBS session from the beginning. The UE 100 may also be a UE 100 that has joined the MBS session halfway through. The gNB 200 may transmit MBS data by multicast to a plurality of UEs 100 in an 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 that is updated may be RX_NEXT and / or RX_DELIV.

[0136] In step S303, the gNB 200 may transmit a session interruption notification indicating interruption of the MBS session to the UE 100. The session interruption notification may be transmitted by a MAC CE. The session interruption notification may be transmitted by a SIB, an MCCH (multicast control channel), an RRC Reconfiguration message, or a 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 is 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 (for example, 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 a 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 interrupted, 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 the MBS session is 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 a PDCP packet transmitted from gNB200 in the MBS session.

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

[0141] In this operation example 3, when the UE 100 detects 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 the PDCP entity in step S305. In UE 100, the RRC layer may instruct the PDCP layer to re-establish the PDCP entity. When the PDCP entity is re-established, the PDCP variables managed by the PDCP entity are initialized.

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

[0144] In the above-described operation example 3, an example has been 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 response to 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 the gNB 200 by 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 in association with the 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 PDCP operation example 3, before the COUNT of the MBS session reaches the upper limit (i.e., when it is about to wrap around), it is necessary to initialize the PDCP variables of one or more UEs receiving the MBS session.

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

[0147] Fig. 13 is a diagram showing a fourth operation example of PDCP according to an embodiment. The UE 100 may be a UE 100 that has joined the MBS session from the beginning. The UE 100 may also be a UE 100 that has joined the MBS session halfway through. The gNB 200 may transmit MBS data by multicast to a plurality of UEs 100 in an RRC connected state. The gNB 200 may transmit MBS data by multicast to a plurality of 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] After that, in step S403, the gNB 200 transmits an initialization instruction to the UE 100 to instruct initialization of the PDCP variables. As described above, the initialization instruction may be a re-establishment instruction of 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, reaching the COUNT upper limit value). The initialization instruction may be transmitted by an RRC Reconfiguration message, a PDCP Control PDU, an SIB, or an MCCH (multicast control channel). The initialization instruction may be transmitted by a MAC CE (Control Element) or an MTCH (multicast traffic channel). Note that it is desirable to notify a plurality of UEs of the initialization instruction at the same time. 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. In addition to or instead of the MBS session identifier, a Bearer ID (or MBS Bearer ID) may be used.

[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 by multicast and re-establishes 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 initialize the PDCP variables.

[0152] In step S404, the PDCP entity of the UE 100 initializes (i.e., resets) updated PDCP variables associated with the MBS session in response to receiving the initialization instruction in step S403. Similarly, the gNB 200 may initialize 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 the PDCP packet transmitted in the MBS session from the gNB 200. The gNB 200 may resume transmission of the PDCP packet in response to 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] In addition, in the above-mentioned operation example 3, similarly to the 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 operation example of the PDCP according to the embodiment will be described, focusing mainly on differences from the first to fourth operation 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 by 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 by 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 continuously used. That is, the PDCP entity of UE 100 updates the PDCP variables associated with the MBS session in response to reception of a PDCP packet 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 the reception process (PDCP operation) of the PDCP packet 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 by multicast from adversely affecting other UEs 100.

[0159] 14 is a diagram showing a fifth example of PDCP operation according to an embodiment. The UE 100 may be a UE 100 that has joined the MBS session from the beginning. The UE 100 may also be a UE 100 that has joined the MBS session halfway through. The gNB 200 may transmit MBS data by multicast to a plurality of UEs 100 in an 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 association with handover or RRC re-establishment. That is, UE 100 deletes an old PDCP entity before performing 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 held in a predetermined storage area. Note that UE 100 may receive a re-establishment instruction from gNB 200 instructing 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 related to the re-establishment is associated with an MBS session. UE 100 may determine whether the PDCP entity related to the re-establishment is configured to hold PDCP variables without initializing them. Such a setting may be made from gNB 200 to UE 100 by, for example, an RRC Reconfiguration message. When UE 100 receives a re-establishment instruction from gNB 200 instructing re-establishment of the PDCP entity, UE 100 may determine whether information indicating that the PDCP variables are to be held without being initialized (for example, "COUNT-continued=true") is included in the re-establishment instruction. If the result 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 holds the PDCP variables updated in step S502 without initializing them. That is, the UE 100 sets the PDCP variables held in a predetermined storage area again to the new PDCP entity related to the re-establishment.

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

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

[0167] In addition, UE 100 may re-establish a PDCP entity in response to performing handover or RRC re-establishment from the first cell to the second cell of gNB 200 (step S503). If UE 100 is notified by gNB 200 that the PDCP variables can be continuously used in the second cell before performing handover or RRC re-establishment, UE 100 may hold the PDCP variables without initializing them even after performing handover or RRC re-establishment. Such notification information may be transmitted by gNB 200 to UE 100 in the first cell by 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 operation example of the PDCP according to an embodiment will be described, focusing on differences from the above-mentioned first to fifth operation examples. Fig. 15 is a diagram for explaining the sixth operation example of the 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] When the MBS session that the UE 100 has received in the cell C1 is also provided in the cell C2, the UE 100 can continue to receive the MBS even if it performs handover, RRC re-establishment, or cell reselection. Here, even if the PDCP SN is synchronized between the cells in the cells C1 and C2, the HFN may not be synchronized between the cells. When the HFN is not synchronized between the cells C1 and C2, the UE 100 needs to synchronize with the HFN in the cell C2, i.e., the HFN managed by the gNB 200B, when it moves from the cell C1 to the 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] Secondly, before performing handover from cell C1 to cell C2, RRC re-establishment, or cell reselection, UE 100 receives from gNB 200A notification information indicating whether or not the updated PDCP variables can be continuously used in cell C2 (step S602). Note that gNB 200A is assumed to know whether or not the HFN is synchronized between cell C1 and cell C2, for example, by inter-base station communication with gNB 200B. When the HFN is synchronized between cell C1 and cell C2, gNB 200A transmits notification information indicating that the updated PDCP variables can be continuously used in cell C2. On the other hand, when the HFN is not synchronized between cell C1 and cell C2, gNB 200A transmits notification information indicating that the updated PDCP variables cannot be continuously used in cell C2. gNB 200A may transmit the notification information by SIB, MCCH, RRC Reconfiguration, or PDCP Control PDU.

[0173] The notification information may include information indicating an area consisting of one or more cells in which the updated PDCP variables can be continuously used. For example, the notification information may include a cell ID list consisting of cell IDs of cells in which the PDCP variables used in cell C1 can be reused.

[0174] Thirdly, the UE 100 performs handover from the cell C1 to the 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 the cell C1 can also be used in the cell C2, the PDCP entity of the UE 100 continues to use the PDCP variables held in the cell C2 and receives a PDCP packet from the cell C2 (step S604). On the other hand, if the notification information indicates that the PDCP variables used in the cell C1 cannot be used in the cell C2, the PDCP entity of the UE 100 derives the PDCP variables from the PDCP packet first received in the cell C2 (see the above-mentioned operation example 1). Alternatively, if the UE 100 is notified of the HFN in use in the 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 the RLC according to an embodiment will be described. Fig. 16 and Fig. 17 are diagrams for explaining an example of the operation of the RLC according to an embodiment. In this example of the operation, the RLC entity of the UE 100 receives from the gNB 200 an RLC PDU (Protocol Data Unit) that is transmitted in an MBS session and that is obtained by the 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) of SN#0 to #5. The RLC entity of the UE 100 cannot reconstruct the original PDCP packet (RLC SDU) unless it receives all of these six RLC PDUs. Such a reconstruction processing is sometimes called reassembly. It is assumed that, in this operation example, an 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 possible to start receiving from RLC PDU of SN#0. If UE 100 cannot receive RLC PDU of SN#0, reconstruction into RLC SDU cannot be completed. RLC SDU that cannot be reconstructed will be discarded when the timer (T-Reassembly) expires.

[0178] However, when in-order delivery is configured to pass PDCP packets (RLC SDUs) to a higher layer (i.e., PDCP) in order, a problem occurs in that the next PDCP packet cannot be passed to the higher layer until the reassembly timer (T-Reassembly) expires, resulting in a delay.

[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 the RLC SDU from the first received RLC PDU and the RLC PDU following the first received RLC PDU. In FIG. 16, the RLC entity of the UE 100 has been able to receive the first RLC PDU (i.e., the RLC PDU of SN#0) (step S702). Therefore, the RLC entity of the UE 100 reconstructs the RLC SDU when the RLC PDUs of SN#0 to #5 are collected (step S703), and passes the RLC SDU to the upper layer (i.e., PDCP).

[0180] On the other hand, as shown in FIG. 17, when 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 the RLC PDUs subsequent to the first received RLC PDU. Specifically, when 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 the RLC PDUs subsequent to the first received RLC PDU even if the timer (T-Reassembly) has not expired. In this way, by determining whether or not to reconstruct an RLC SDU from the first received RLC PDU and the 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, a packet that cannot be reconstructed can be discarded early, thereby suppressing the occurrence of a delay.

[0181] 17, the RLC entity of UE 100 that 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, even if the timer (T-Reassembly) has not expired, the RLC entity of UE 100 discards the RLC PDU of SN#2 and each of the subsequent RLC PDUs of SN#3 to #5.

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

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

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

[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 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 in a computer-readable medium. Using the computer-readable medium, it is possible to install the program in the computer. Here, the computer-readable medium on which the program is recorded may be a non-transient recording medium. The non-transient recording medium is not particularly limited, and may be, for example, a recording medium such as a CD-ROM or a DVD-ROM.

[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, etc. are possible without departing from the spirit 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] (Additional Note) (PDCP operation) Initial values ​​of state variables Although the current agreement specifies only the RLC UM mode, for the sake of service continuity, it is worth considering how 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. Since the PTM leg is used for multiple UEs, the PDCP SN may not be UE specific and affects both the PTM leg and the PTP leg. This means that in the case of a late joining UE in a multicast session, the initial value of each state variable will not always be "0", regardless of whether the first received MBS data is from the PTM leg or the PTP leg. In other words, the first PDCP SN received by the UE can be any value that is not expected for the current unicast transmission. Also, the PDCP re-establishment of one UE may affect all other UEs because the state variables are set to their initial values. This leads to unexpected behavior in the receiving window, i.e., PDCP PDUs that are outside the receiving 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 informs 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 with the existing mechanisms by simply changing the initial values ​​related to the reception window based on information from the gNB. However, from the PDCP layer point of view, 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, bad radio conditions, or being outside the RLC reconfiguration window. It is unclear how this option would work in this case.

[0196] Option B: The gNB informs 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, i.e., “For broadcast and groupcast NR sidelink communication, 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 part of RX_DELIV is (x-0.5×2 [sl-PDCP-SN-Size-1] ) modulo(2 [sl-PDCP-SN-Size] ), where x is the SN of the first received PDCP Data PDU."

[0198] Regarding the HFN part, the V2X mechanism in Rel-16 does not require the transmitter and receiver to be synchronized. That is, 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 a positive value." In the case of NR MBS, "RAN2 will wait for SA3 to finish its investigation into the security of MBS before replying that it will explain the security aspects of RAN2." Therefore, if the HFN part needs to be notified at this time, RAN2 needs to be postponed.

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

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

[0201] (Concurrent reception and UE assistance information) If Proposal 2 is acceptable, the UE needs to support simultaneous reception from both the PTM and PTP legs, i.e., two legs can be activated at the same time, similar to existing PDCP packet duplication. This is considered beneficial for dynamic PTM / PTP switching, since the PTP leg is received by multiple UEs, i.e., it is not UE specific, and therefore it is easier to compensate for missing packets that were not received over the PTM leg. Therefore, RAN2 needs to agree to simultaneous reception, at least for 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 can be agreed upon, the gNB may not actually know which PDCP SN the UE has started to receive successfully over the PTM leg. In 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 informs the gNB of successful PTM reception, which can be sent over the PTP leg if it has not been deactivated yet. However, it is unclear whether this solution intends to include the PDCP SN in the information.

[0203] Similarly, in case of PTM to PTP switching, 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 PDUs that it starts transmitting over the PTP leg. Therefore, it can be considered that the UE informs the gNB of the SN information over the activated PTP leg upon 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, and exactly, the PDCP status report contains the FMC (first missing PDCP SDU) and an optional bitmap (indicating 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, we need to further discuss what needs to be reported during dynamic switching between PTM and PTP.

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

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

[0207] 10: NG-RAN (5G RAN) 20: 5GC (5G CN) 100:UE 110: Receiving unit 120: Transmitter 130: Control section 200: gNB 210: Transmission unit 220: Receiving unit 230: Control section 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: setting initial values ​​of PDCP variables for the MBS based on a PDCP sequence number included in a PDCP packet first received from the base station; The PDCP variable is a variable used for receiving window control, and indicates a count value of a PDCP SDU expected to be received next, or a count value of a PDCP SDU waiting to be received and not yet provided to an upper layer; receiving an RRC message from the base station, the RRC message including an initialization instruction for instructing initialization of the PDCP variables; The initialization instruction is an instruction to re-establish a PDCP entity. Communications control method.

2. setting the PDCP variable includes setting a value obtained by adding "1" to a PDCP sequence number included in the PDCP packet first received from the base station to the initial value; The PDCP variable indicates a count value of the PDCP SDU that is expected to be received next. The communication control method according to claim 1.

3. A user device in a mobile communication system in which a base station provides a multicast / broadcast service (MBS) to the user device, a control unit that sets an initial value of a PDCP variable for an MBS based on a PDCP sequence number included in a PDCP packet first received from the base station; The PDCP variable is a variable used for receiving window control, and indicates a count value of a PDCP SDU expected to be received next, or a count value of a PDCP SDU waiting to be received and not yet provided to an upper layer; A receiving unit that receives an RRC message including an initialization instruction for instructing initialization of the PDCP variables from the base station, The initialization instruction is an instruction to re-establish a PDCP entity. User equipment.

4. The control unit sets a value obtained by adding "1" to a PDCP sequence number included in the PDCP packet initially received from the base station as the initial value; The PDCP variable indicates a count value of the PDCP SDU that is expected to be received next.

4. A user device according to claim 3.

5. A mobile communication system that provides a multicast and broadcast service (MBS) from a base station to a user device, comprising: The user equipment sets an initial value of a PDCP variable for an MBS based on a PDCP sequence number included in a PDCP packet first received from the base station; The PDCP variable is a variable used for receiving window control, and indicates a count value of a PDCP SDU expected to be received next, or a count value of a PDCP SDU waiting to be received and not yet provided to an upper layer; The user equipment receives an RRC message including an initialization instruction for instructing initialization of the PDCP variables from the base station; The initialization instruction is an instruction to re-establish a PDCP entity. Mobile communication system.

6. The user device sets the initial value to a value obtained by adding "1" to the PDCP sequence number included in the PDCP packet initially received from the base station; The PDCP variable indicates a count value of the PDCP SDU that is expected to be received next.

6. The mobile communication system according to claim 5.

7. A chip set for a user device in a mobile communication system that provides a multicast broadcast service (MBS) from a base station to a user device, comprising: setting initial values ​​of PDCP variables for the MBS based on a PDCP sequence number included in a PDCP packet first received from the base station; The PDCP variable is a variable used for receiving window control, and indicates a count value of a PDCP SDU expected to be received next, or a count value of a PDCP SDU waiting to be received and not yet provided to an upper layer; receiving an RRC message from the base station, the RRC message including an initialization instruction instructing initialization of the PDCP variables; The initialization instruction is an instruction to re-establish a PDCP entity. Chipset.

8. setting the PDCP variable includes setting a value obtained by adding "1" to a PDCP sequence number included in the PDCP packet first received from the base station to the initial value; The PDCP variable indicates a count value of the PDCP SDU that is expected to be received next. The chipset of claim 7.

9. In a mobile communication system in which a base station provides a multicast broadcast service (MBS) to a user device, and executing a process of setting an initial value of a PDCP variable for an MBS based on a PDCP sequence number included in a PDCP packet first received from the base station; The PDCP variable is a variable used for receiving window control, and indicates a count value of a PDCP SDU expected to be received next, or a count value of a PDCP SDU waiting to be received and not yet provided to an upper layer; receiving an RRC message including an initialization instruction from the base station, the RRC message including an initialization instruction for instructing the initialization of the PDCP variables; The initialization instruction is an instruction to re-establish a PDCP entity. program.

10. The process of setting the PDCP variable includes a process of setting the initial value to a value obtained by adding "1" to a PDCP sequence number included in the PDCP packet first received from the base station; The PDCP variable indicates a count value of the PDCP SDU that is expected to be received next. The program according to claim 9.

Images