Service continuity for user equipment device (UE) receiving multicast in radio resource control (RRC) inactive

Abstract

Apparatuses and methods for multicast service continuity for a Radio Resource Control (RRC) User Equipment Device (UE) in mobility are disclosed. In an aspect, a UE receives a multicast service from a first network node of a first cell while operating in an RRC inactive state or an RRC idle state in the first cell. The UE also receives an indication of packet data convergence protocol (PDCP) counter synchronization across a plurality of network nodes for the multicast service, wherein the plurality of network nodes includes the first network node. The UE also selects a second cell for residing. The UE further continues to receive the multicast service in the second cell from a second network node of the second cell based on the PDCP variable continuity, where the plurality of network nodes include the second network node, and where the PDCP variable continuity is responsive to an indication of PDCP counter synchronization.

Description

Technical Field

[0001] Various example embodiments generally relate to wireless networking, and more specifically to service continuity for user equipment (UE) devices that receive multicast while in a radio resource control (RRC) inactive state. Background Technology

[0002] Wireless networking offers significant advantages to user mobility. The ability to maintain connectivity while on the move not only benefits users but also contributes to greater efficiency and productivity for society as a whole. As user expectations for connection reliability, data speed, and device battery life continue to rise, the technologies used for wireless networking must also align with these expectations. Accordingly, continuous focus on improving wireless network technologies is essential. Summary of the Invention

[0003] According to various aspects of this disclosure, a user equipment apparatus includes at least one processor and at least one memory. The at least one memory stores instructions that, when executed by the at least one processor, cause the user equipment apparatus to at least: receive multicast services from a first network node in a first cell while operating in a Radio Resource Control (RRC) inactive state in the first cell; receive an indication for Packet Data Convergence Protocol (PDCP) counter synchronization across multiple network nodes for the multicast services, wherein the multiple network nodes include the first network node; select a second cell for camping; and continue receiving the multicast services from a second network node in the second cell based on PDCP variable continuity, wherein the multiple network nodes include the second network node, and wherein the PDCP variable continuity is responsive to the PDCP counter synchronization indication.

[0004] In one aspect of this disclosure, when executed by at least one processor, the instructions cause the user equipment device to continue receiving multicast services in the second cell by at least one of performing PDCP reconstruction or initialization of PDCP state variables associated with the multicast service in response to an indication of PDCP counter synchronization.

[0005] In one aspect of this disclosure, when executed by at least one processor, the instructions further cause the user equipment device to at least: determine a PDCP variable continuity in response to an indication of PDCP counter synchronization, and when executed by at least one processor, cause the user equipment device to at least: continue receiving multicast services by applying the determined PDCP variable continuity to receive packets associated with the multicast services.

[0006] In one aspect of this disclosure, when executed by at least one processor, the instructions cause a user equipment apparatus to receive an indication of a Logical Channel Identifier (LCID) mapping for a multicast service, at least between a first network node and a second network node. The indication of the LCID mapping is an indication of PDCP counter synchronization and implicitly indicates PDCP counter synchronization across multiple network nodes.

[0007] In one aspect of this disclosure, when executed by at least one processor, the instructions cause a user equipment device to continue receiving multicast services in a second cell by at least applying the PDCP counter of the first cell in the second cell to receive multicast services in response to receiving an LCID mapping.

[0008] In one aspect of this disclosure, the LCID mapping instruction is used to indicate that a first LCID value associated with a first network node is mapped to a second LCID value associated with a second network node, and the instruction, when executed by at least one processor, causes the user equipment device to continue receiving multicast services in the second cell, at least by receiving multicast services via a logical channel identified by the second LCID value.

[0009] In one aspect of this disclosure, when executed by at least one processor, the instructions cause a user equipment device to receive an instruction for PDCP counter synchronization at least by receiving an instruction for PDCP counter synchronization from a first network node prior to selection.

[0010] In one aspect of this disclosure, when executed by at least one processor, the instructions cause the user equipment device to receive the PDCP counter synchronization instruction at least by receiving the PDCP counter synchronization instruction from the second network node after selection.

[0011] In one aspect of this disclosure, when executed by at least one processor, the instruction causes a user equipment device to receive an instruction for PDCP counter synchronization at least by receiving an instruction for PDCP counter synchronization in an RRC release message.

[0012] In one aspect of this disclosure, when executed by at least one processor, the instructions cause a user equipment device to receive an instruction for PDCP counter synchronization at least by receiving an instruction for PDCP counter synchronization in a multicast control channel (MCCH) configuration.

[0013] According to one aspect of this disclosure, a method performed by a user equipment device includes: receiving multicast services from a first network node in a first cell while operating in a Radio Resource Control (RRC) inactive state; receiving an indication for Packet Data Convergence Protocol (PDCP) counter synchronization across multiple network nodes for the multicast services, wherein the multiple network nodes include the first network node; selecting a second cell for camping; and continuing to receive multicast services from a second network node in the second cell based on PDCP variable continuity, wherein the multiple network nodes include the second network node, and wherein the PDCP variable continuity responds to the indication for PDCP counter synchronization.

[0014] In one aspect of this disclosure, continuing to receive multicast services in a second cell includes: in response to an instruction to synchronize the PDCP counter, avoiding at least one of performing PDCP reconstruction or initialization of PDCP state variables (e.g., pre-serializing all PDCP state variables of the first cell) in the second cell associated with the multicast service.

[0015] In one aspect of this disclosure, the method further includes determining PDCP variable continuity in response to an indication of PDCP counter synchronization, and continuing to receive multicast services in the second cell, including receiving multicast services via a logical channel identified by a second LCID value.

[0016] In one aspect of this disclosure, receiving an instruction for PDCP counter synchronization includes sending an instruction for a logical channel identifier (LCID) mapping for a multicast service, at least between a first network node and a second network node.

[0017] In one aspect of this disclosure, the LCID mapping indication is used to indicate that a first LCID value associated with a first network node is mapped to a second LCID value associated with a second network node, and continued reception of multicast service in the second cell includes receiving multicast service via a logical channel identified by the second LCID value. The LCID mapping indication is an indication of PDCP counter synchronization and implicitly indicates PDCP counter synchronization across multiple network nodes.

[0018] In one aspect of this disclosure, receiving a multicast service in a second cell includes, in response to receiving an LCID mapping, applying a PDCP counter of the first cell in the second cell to receive the multicast service.

[0019] In one aspect of this disclosure, receiving an indication for PDCP counter synchronization includes receiving an indication for PDCP counter synchronization from a first network node prior to selection.

[0020] In one aspect of this disclosure, receiving an instruction for PDCP counter synchronization includes receiving an instruction for PDCP counter synchronization from a second network node after selection.

[0021] In one aspect of this disclosure, receiving an indication of PDCP counter synchronization includes receiving an indication of PDCP counter synchronization in an RRC release message.

[0022] In one aspect of this disclosure, receiving an indication of PDCP counter synchronization includes receiving an indication of PDCP counter synchronization in a multicast control channel (MCCH) configuration.

[0023] According to various aspects of this disclosure, a network node includes at least one processor and at least one memory. The at least one memory stores instructions that, when executed by the at least one processor, cause the network node to at least: determine that Packet Data Convergence Protocol (PDCP) counter synchronization across multiple network nodes is applied to a multicast service, wherein the multiple network nodes include network nodes; and in response to the determination, send an indication to a user equipment (UE) device for PDCP counter synchronization across multiple network nodes for the multicast service.

[0024] In one aspect of this disclosure, when executed by at least one processor, the instructions cause a network node to send an indication of PDCP counter synchronization at least by sending an indication of a logical channel identifier (LCID) mapping between the network node and at least another of a plurality of network nodes for a multicast service.

[0025] In one aspect of this disclosure, when executed by at least one processor, the instructions also cause a network node to determine, at least for the multicast service, an LCID mapping between the network node and other network nodes.

[0026] In one aspect of this disclosure, when executed by at least one processor, the instruction causes a network node to send an indication of PDCP counter synchronization to the UE at least in at least one of a Multicast Control Channel (MCCH) configuration or a Radio Resource Control (RRC) release message.

[0027] In one aspect of this disclosure, when executed by at least one processor, the instructions also cause a network node to exchange Logical Channel Identifier (LCID) information associated with a multicast service with at least another network node among a plurality of network nodes.

[0028] In one aspect of this disclosure, LCID information includes indications of one or more Quality of Service Flow Identifiers (QFIs) mapped to an individual LCID associated with a multicast service.

[0029] According to an aspect of this disclosure, a method performed by a network node includes: determining that Packet Data Convergence Protocol (PDCP) counter synchronization across multiple network nodes is applied to a multicast service, wherein the multiple network nodes include network nodes; and in response to the determination, sending an indication to a user equipment (UE) device for PDCP counter synchronization across multiple network nodes for the multicast service.

[0030] In one aspect of this disclosure, sending an indication for PDCP counter synchronization includes sending an indication for a logical channel identifier (LCID) mapping between a network node and at least one other network node among a plurality of network nodes for a multicast service.

[0031] In one aspect of this disclosure, the method also includes determining LCID mappings between network nodes and other network nodes for multicast services.

[0032] In one aspect of this disclosure, sending an indication for PDCP counter synchronization includes sending an indication for PDCP counter synchronization to the UE in at least one of a multicast control channel (MCCH) configuration or radio resource control (RRC) release message.

[0033] In one aspect of this disclosure, the method also includes exchanging Logical Channel Identifier (LCID) information associated with the multicast service with another network node among a plurality of network nodes.

[0034] In one aspect of this disclosure, LCID information includes indications of one or more Quality of Service Flow Identifiers (QFIs) mapped to an individual LCID associated with a multicast service.

[0035] The independent claims provide the subject matter for several aspects. Additional aspects are defined in the dependent claims. Attached Figure Description

[0036] Some exemplary embodiments will now be described with reference to the accompanying drawings.

[0037] Figure 1 This is an illustration of an example embodiment of wireless networking between a network system and a user equipment (UE) according to one aspect of this disclosure; Figure 2 This is an illustration of an example embodiment of a UE communicating with a primary node (MN) and a secondary node (SN) according to an illustrative aspect of this disclosure; Figure 3 This is an illustration of an example embodiment of a multicast service continuity scenario for a radio resource control (RRC) inactive UE in mobility, based on one aspect of this disclosure; Figure 4This is an illustration of an example embodiment of a network protocol architecture for providing multicast services according to one aspect of this disclosure; Figure 5 This is an illustration of an example embodiment of an operation for providing multicast service continuity to an RRC-inactive UE in mobility, according to one aspect of this disclosure; Figure 6 This is an illustration of an example embodiment of an operation for providing multicast service continuity to an RRC-inactive UE in mobility, according to one aspect of this disclosure; Figure 7 This is an illustration of an example embodiment of an operation for providing multicast service continuity to an RRC-inactive UE in mobility, according to one aspect of this disclosure; Figure 8 This is a flowchart illustrating an aspect of multicast service continuity for a UE, based on the present disclosure. Figure 9 This is a flowchart illustrating an example operation of a network node for multicast service continuity, based on an illustrative aspect of this disclosure; and Figure 10 An example embodiment of a component of a UE or network node according to one aspect of this disclosure is shown. Detailed Implementation

[0038] In the following description, certain specific details are set forth in order to provide a thorough understanding of the disclosed aspects. However, those skilled in the art will recognize that the aspects can be practiced without one or more of these specific details or using other methods, components, materials, etc. In other instances, well-known structures associated with transmitters, receivers, or transceivers have not been shown or described in detail to avoid unnecessarily obscuring the description of the aspects.

[0039] Throughout this specification, the reference to "an aspect" or "aspect" means that a particular feature, structure, or characteristic described in connection with that aspect is included in at least one aspect. Therefore, the phrases "in an aspect" or "in one respect" appearing throughout this specification do not necessarily refer to the same aspect. Furthermore, in one or more aspects, a particular feature, structure, or characteristic may be combined in any suitable manner.

[0040] The embodiments described in this disclosure can be implemented in wireless networking devices, such as, but not limited to, devices utilizing Global Microwave Access Interoperability (WiMAX), Global System for Mobile Communications (GSM, 2G), GSM EDGE Radio Access Network (GERAN), General Packet Radio Service (GRPS), Universal Mobile Telecommunications System based on Basic Wideband Code Division Multiple Access (W-CDMA) (UMTS, 3G), High-Speed ​​Packet Access (HSPA), Long Term Evolution (LTE), Advanced LTE, Enhanced LTE (eLTE), 5G New Radio (5G NR), 5G Advanced, 6G (and above), and 802.11ax (Wi-Fi 6), and other wireless networking systems. The term "eLTE" here refers to LTE evolution connected to a 5G core. LTE is also referred to as Evolved UMTS Terrestrial Radio Access (EUTRA) or Evolved UMTS Terrestrial Radio Access Network (EUTRAN).

[0041] In wireless communication technologies, such as the 5th Generation New Radio (5G NR) as defined by the 3rd Generation Partnership Project (3GPP), networks can provide multicast and broadcast system (MBS) services to users on the network. Point-to-point (PTM) transmission can efficiently provide MBS services to multiple users by using the same radio framework as unicast transmission. In a wireless network, a User Equipment (UE) can operate in various Radio Resource Control (RRC) states, such as RRC Idle, RRC Connected, and RRC Inactive. A UE in the RRC Idle state is powered on but may not have any RRC connection established with the network. A UE in the RRC Inactive state has established an RRC connection with the network, but the RRC connection is in a suspended mode (e.g., no active data transmission in the uplink (UL)). A UE in the RRC Connected state has established an RRC connection with the network and has active data transmission on the RRC connection. A UE can transition from one RRC state to another under various conditions. As used in this article, a UE operating in RRC idle state can be referred to as an RRC idle UE, a UE operating in RRC inactive state can be referred to as an RRC inactive UE, and a UE operating in RRC connected state can be referred to as an RRC connected UE.

[0042] 3GPP Release 17 (Rel-17) specifies broadcast reception for all RRC states. However, Rel-17 only enables multicast services to be received by UEs in an RRC connected state. In other words, Rel-17 does not support multicast services for UEs in an RRC inactive state.

[0043] The 5G NR protocol layer architecture can include various protocol layers, such as the Serving Data Adaptation Protocol (SDAP) layer, Packet Data Convergence Protocol (PDCP) layer, Radio Link Control (RLC) layer, Media Access Control (MAC) layer, and Physical (PHY) layer. UEs can receive multicast services via these protocol layers. A PDCP packet counter (referred to as COUNT in NR) can be used to track and / or maintain the packet sequence associated with the multicast service. At this point, each PDCP Data Service Data Unit (SDU) can be associated with a COUNT value. In an example, the PDCP packet counter can be formed by a combination of the PDCP sequence number (PDCP SN) and the superframe number (HFN). Furthermore, various PDCP variables (e.g., RX_NEXT, RX_DELIV, and RX_REORD in NR) can be used to facilitate the tracking of PDCP data reception. Such variables in the PDCP layer can be referred to as PDCP state variables or PDCP status variables.

[0044] Rel-17 provides cross-cell multicast service continuity by applying PDCP counter synchronization for multicast services in network nodes (e.g., base stations (BS) or gNodeBs (gNBs) in the context of 5G NR). That is, each network node in at least one group of network nodes in the network can use the same PDCP counter value (e.g., attached to multicast service data packets) to transmit the same data segments of the multicast service. In this way, when a UE operates in an RRC connected state (e.g., during handover) and moves from one cell to another, the UE can continue to receive the same multicast service with minimal packet loss. Such operation can be achieved by the UE requesting lost packets or detecting and discarding packets received more than once, for example, receiving packets once from the source cell and once from the destination cell during the handover.

[0045] To facilitate PDCP counter synchronization for multicast services, gNBs (or more generally, network nodes) can set the PDCP COUNT counter in a manner common to all gNBs in the system providing the multicast service (which may correspond to the PDCP SN and HFN derived from the sequence numbers of (multiple) Quality of Service (QoS) flows from the core network). Alternatively, shared Next Generation User Plane (NG-U) termination and / or shared Central Unit User Plane (CU-UP) can be used, resulting in a single entity (e.g., the CU-UP) serving all gNBs. Using a single entity to serve these gNBs ensures PDCP COUNT / SN synchronization among these gNBs for multicast services. As used herein, PDCP counters can generally refer to the parameters PDCP COUNT and / or PDCP SN defined by 3GPP.

[0046] To provide scalability and power savings, 3GPP Release 18 (Rel-18) enables UEs in an RRC inactive state to receive multicast services. For example, when a UE is in an RRC inactive state and interested in multicast services, it can apply a multicast service configuration within the cell to begin and / or continue receiving multicast services it has already joined. In examples, the configuration can be provided using a broadcast mode. For instance, the cell can periodically broadcast a System Information Block (SIB) / (Multicast Control Channel) MCCH, allowing an RRC inactive UE to receive the configuration and any updates to it. Furthermore, in some examples, a cell configuring a UE to transition from an RRC connected state to an RRC inactive state can provide this configuration to the current cell in an RRC release message with a suspend configuration; this can be referred to as suspendConfig.

[0047] When multicast service is only provided to UEs in RRC connected state, multicast service continuity during UE mobility may not be an issue because the UE handover is known to the network, and therefore minimizing packet loss for multicast service can be managed by the network. For example, if network nodes do not synchronize their PDCP counters, the UE may be configured with a new PDCP counter configuration in conjunction with the handover. This counter configuration can be called PDCP rebuild. Typically, PDCP rebuild refers to resetting PDCP variables (e.g., PDCP state variables) to new initial values. However, for UEs in RRC inactive or idle state, multicast service continuity may be problematic because the network may not be aware that the UE has selected a new cell for camping. Therefore, RRC inactive UEs are expected to minimize packet loss after camping on a new cell.

[0048] One mobility issue for inactive or idle UEs in RRC is that the UE may not know whether PDCP counter synchronization is applied in the network (or neighboring cells). Therefore, a UE in an inactive RRC state may not know whether it can assume PDCP counter synchronization when selecting a new cell for camping, or whether it must establish a new PDCP counter for the new cell. Without knowing the PDCP counter synchronization applied in the newly selected cell, the UE can assume (by default) that PDCP counter synchronization is not applied in the new cell. Thus, the UE can operate in the new cell by assuming MBS broadcast MBS radio bearer (MRB) behavior: releasing PDCP entities, reading MCCH, and establishing new PDCP entities / variables. Therefore, multicast service continuity cannot be achieved.

[0049] Multicast services or sessions can include multiple QoS flows mapped to radio bearers (which may be called MBS radio bearers (MRBs)). MRBs are further mapped to logical channel identifiers (LCIDs), which are used by the UE to identify packets associated with the multicast service. Because different cells (or different network nodes) can use different MRBs for the same multicast service and can independently map MRBs to LCIDs, another issue with mobility for inactive UEs with RRCs is that the UE may not know how the source cell's MRB is mapped to the target cell's MRB.

[0050] Accordingly, while PDCP counter synchronization can be applied across at least some network nodes (gNBs) in the network, RRC inactive UEs may not be able to achieve service continuity for multicast reception during mobility.

[0051] This disclosure provides techniques for enabling multicast service continuity for an RRC-inactive UE during mobility. According to one aspect of this disclosure, the UE can receive multicast services from a first network node (e.g., a base station, gNB) in a first cell. The UE can receive multicast services while operating in an RRC-inactive state in the first cell. The UE can receive indications of PDCP counter synchronization applied across multiple network nodes for the multicast service, including the first network node. While camped in the first cell (e.g., operating in an RRC-inactive state) and receiving multicast services, the UE can select (or reselect) a second cell different from the first cell for camping. Cell selection (or reselection) can be based on signal measurements (e.g., RSRP measurements). For example, the UE can detect a degradation in signal quality from the first network node and determine that the second cell provides higher signal quality than the first cell. As a result of the cell selection, the UE will switch from receiving from the first cell to receiving from the second cell. When the UE is in a second cell (e.g., still operating in an RRC inactive or idle state), the UE can continue to receive multicast services from a second network node in the second cell based on PDCP variable continuity, where multiple network nodes include the second network node. The UE can determine the PDCP variable continuity based on an indication of PDCP counter synchronization.

[0052] In one aspect, PDCP variable continuity can refer to a UE continuing to track the PDCP counter for data packets received for multicast services in a second cell based on the last PDCP counter received in the first cell. That is, an RRC-inactive UE can continue to receive multicast services after moving to the second cell without performing a PDCP (re)establishment procedure in the second cell, and the variables tracking the PDCP counter (e.g., at the UE's location) are preserved during the move from the first cell to the second cell (e.g., not reset or discarded). In some aspects, multiple network nodes can be part of a network, and the indication of PDCP counter synchronization can include an indication that the PDCP counter is synchronized across all network nodes (e.g., all gNBs) for providing multicast services. In some aspects, multiple network nodes can be part of a network, and the indication of PDCP counter synchronization can include an indication that the PDCP counter is synchronized across some network nodes (e.g., some gNBs) for providing multicast services, but not across all network nodes or a specific network node.

[0053] PDCP counter synchronization can be understood as network nodes synchronizing their PDCP counters by using the same PDCP counter for the same multicast service. This means that data packets are associated with the same PDCP counter value when sent from the first cell and when sent from the second cell. Alternatively, PDCP counter synchronization can be understood as different network nodes using different PDCP counters with a defined constant offset between them. The indication of PDCP counter synchronization can then include an indication of this offset between the first and second cells, and the UE can then offset its PDCP counter accordingly when selecting the second cell without requiring PDCP reconstruction. This synchronization can mean that the same PDCP COUNT or the same PDCP SN value is used to send the same data packets to the UE via the air interface from different network nodes.

[0054] In some aspects, the UE may receive PDCP counter synchronization including an indication of at least an LCID mapping between a first network node and a second network node. In an example, the multicast service may have two QoS streams, for example, one for audio and another for video. The QoS streams may be provided on a certain MRB (e.g., a first MRB) in the first cell, and the MRB may be mapped to a certain LCID (e.g., a first LCID) in the first cell. The LCID mapping may indicate a mapping between the first MRB of the first cell and the second MRB of the second cell and / or a mapping between the first LCID of the first cell and the second LCID of the second cell.

[0055] In some aspects, the UE may receive an indication of PDCP counter synchronization from a first network node (before moving to a second cell). In some aspects, the UE may receive an indication of PDCP counter synchronization from a second network node (when camped on a second cell). In some aspects, the UE may receive an indication of PDCP counter synchronization in an RRC release message (e.g., as part of a suspend configuration in an RRC release message), for example, from a first network node and / or from a second network node (when operating in a second cell). In some aspects, the UE may receive an indication of PDCP counter synchronization in an MCCH configuration, for example, from a first network node (when operating in a first cell) and / or from a second network node (when operating in a second cell).

[0056] According to another aspect of this disclosure, a network node (e.g., a BS or gNB) can determine that PDCP counter synchronization is applied across multiple network nodes for multicast services, wherein the multiple network nodes include the network node. The network node may operate under a Public Terrestrial Mobile Network (PLMN). Therefore, this determination may be based on the configuration performed at the network node by the Operations and Management (OAM) entity in the control of the PLMN. In response to this determination, the network node may send an indication to the UE of LCID mapping for the multicast service across multiple network nodes. The indication of LCID mapping may be sent in an RRC release message and / or MCCH configuration. In some aspects, to determine the LCID mapping, the network node may exchange LCID information with another network node among the multiple network nodes. As part of exchanging LCID information, the network node may send to other network nodes the LCID information of network nodes associated with the QoS flows of the multicast service (i.e., which QoS flows are mapped to which LCIDs in the current cell, indicating QoS flow ID to LCID mapping), and receive from other network nodes the LCID information of other network nodes associated with the multicast service. In this way, a network node can determine its own LCID mapping to the LCIDs of other network nodes, at least in part, based on the LCID information of other network nodes and its own LCID information.

[0057] Various aspects of this disclosure offer a range of advantages. For example, indicating the LCID mapping among multiple network nodes providing multicast service enables an inactive RRC UE to determine which radio bearer and / or which LCID to use to continue receiving multicast service when the inactive RRC UE moves to a new cell served by another network node among the multiple network nodes. Therefore, this disclosure can provide multicast service continuity for inactive RRC UEs in mobility.

[0058] While this disclosure describes multicast service continuity for inactive RRC UEs, aspects of this disclosure are adapted to provide multicast service continuity for idle RRC UEs in mobility.

[0059] Figure 1This is a diagram of an example embodiment of a wireless network between network system 100 and UE 150. Network system 100 may include, for example, one or more network nodes 120, one or more servers 110, and / or one or more network devices 130 (e.g., test devices). Network node 120 will be described in more detail below. As used herein, the term "network device" may refer to any component of network system 100, such as server 110, network node 120, network device 130, any of the foregoing components(s), and / or any other components(s) of network system 100. Examples of network devices include, but are not limited to, devices implementing 5G NR and devices implementing Wi-Fi 6. This disclosure describes embodiments relating to 5G NR and embodiments relating to aspects defined by 3GPP. However, embodiments relating to other wireless networking technologies are contemplated to be covered within the scope of this invention.

[0060] The following description provides further details of examples of network nodes. In a 5G NR network, a gNodeB (also known as a gNB) may include, for example, a node that provides NR user plane and control plane protocol termination to the UE, and is connected to the 5G core (5GC) via an NG interface, for example, according to Section 3.2 of 3GPP TS 38.300 V16.6.0 (2021-06), which is incorporated herein by reference.

[0061] gNB supports various protocol layers, such as Layer 1 (L1) - PHY layer, Layer 2 (L2) and Layer 3 (L3).

[0062] NR's Layer 2 (L2) is divided into the following sublayers: MAC, RLC, PDCP, and SDAP, where, for example: The physical layer provides sublayer transmission channels to the MAC layer; The MAC sublayer provides logical channels to the RLC sublayer; The RLC sublayer provides RLC channels to the PDCP sublayer; The PDCP sublayer provides radio bearers to the SDAP sublayer; The SDAP sublayer provides QoS flows to 5GC; Layer 3 (L3) includes, for example, RRC, as per Section 6 of 3GPP TS 38.300 V16.6.0 (2021-06), which is incorporated herein by reference.

[0063] In radio communications, nodes can be implemented at least partially by a central unit (CU) (e.g., a server or host), which is operatively coupled to one or more distributed units (DUs) (e.g., a wireless head). In embodiments, node operation may be distributed across multiple centralized units (e.g., servers or hosts). In embodiments, network nodes in a 5G wireless network can be implemented based on a so-called CU-DU partitioning. In embodiments, processing tasks can be performed in a CU or a DU, and the transfer of responsibility between the CU and DU can be configured according to a specific implementation.

[0064] The gNB Central Unit (gNB-CU) includes, for example, logical nodes that host, the RRC, SDAP, and PDCP protocols of the gNB, or the RRC and PDCP protocols of the enhanced LTE gNB (en-gNB), and controls the operation of one or more gNB Distributed Units (gNB-DUs). The gNB-CU terminates the F1 interface connected to the gNB-DU. The gNB-CU may also be referred to herein as a CU, Central Unit, Centralized Unit, or Control Unit.

[0065] A gNB Distributed Unit (gNB-DU) includes, for example, a logical node that hosts the RLC, MAC, and PHY layers of a gNB or en-gNB, and whose operation is partially controlled by the gNB-CU. A gNB-DU supports one or more cells. A cell is supported by only one gNB-DU. The gNB-DU terminates the F1 interface connected to the gNB-CU. The gNB-DU may also be referred to herein as a DU or Distributed Unit.

[0066] The gNB-CU-Control Plane (gNB-CU-CP) includes, for example, logical nodes that host the RRC and control plane portion of the PDCP protocol for the gNB-CU of the en-gNB or gNB. The gNB-CU-CP terminates the E1 interface connected to the gNB-CU-User Plane (gNB-CU-UP) and the F1-C interface connected to the gNB-DU.

[0067] The gNB-CU-User Plane (gNB-CU-UP) includes, for example, the user plane portion of the gNB-CU for the en-gNB, and the user plane portions of the gNB-CU for the gNB and the SDAP protocol. The gNB-CU-UP terminates the E1 interface connected to the gNB-CU-CP and the F1-U interface connected to the gNB-DU, as per Section 3.1 of 3GPP TS38.401 V16.6.0 (2021-07), which is incorporated herein by reference.

[0068] Different functional divisions between central and distributed units are possible, for example, referred to as options: Option 1 (similar to 1A): The functional division in this option is similar to the 1A architecture in Dual Connectivity (DC). RRC is in the central unit. PDCP, RLC, MAC, physical layer, and radio frequency (RF) are in the distributed units.

[0069] Option 2 (similar to the 3C division): The functional division in this option is similar to the 3C architecture in a DC (Distributed Control) system. RRC and PDCP are in the central unit. RLC, MAC, physical layer, and RF are in the distributed units.

[0070] Option 3 (Internal partitioning within RLC): Low RLC (part of the RLC functionality), MAC, physical layer, and RF are located in the distributed unit. PDCP and high RLC (another part of the RLC functionality) are located in the central unit.

[0071] Option 4 (RLC-MAC partitioning): MAC, physical layer, and RF are located in the distributed unit. PDCP and RLC are located in the central unit.

[0072] Alternatively, for example, according to Section 11 of 3GPP TR 38.801 V14.0.0 (2017-03), which is incorporated herein by reference.

[0073] As used herein, the term "network node" may refer to any one or any combination thereof of gNB, gNB-CU, gNB-DU, gNB-CU-CP, or gNB-CU-UP.

[0074] Radio access network (RAN) nodes or network nodes, such as gNBs, base stations, gNB-CUs, or gNB-DUs or portions thereof, can be implemented using means, for example, having at least one processor and / or at least one memory having processor-readable instructions (“programs”), which are configured to support and / or provide and / or process functionalities and / or features associated with the CU and / or DU, and / or at least one protocol (sub) layer of the RAN (Radio Access Network), such as layer 2 and / or layer 3. The following will combine... Figure 10 Examples describing such devices and components.

[0075] The gNB-CU and gNB-DU portions can be co-located or physically separated, for example. The gNB-DU can even be further divided into, for example, two parts, one including processing equipment and the other including an antenna. The CU can also be referred to as a baseband unit (BBU), radio equipment control (REC), radio cloud center (RCC), cloud RAN (C-RAN), virtual RAN (V-RAN), open RAN (O-RAN), or a portion thereof. The DU can also be referred to as a radio resource head (RRH), remote radio unit (RRU), radio equipment (RE), radio unit (RU), or a portion thereof. In the various exemplary embodiments of this disclosure, a network node supporting at least one of the RAN central unit control plane functions or Layer 3 protocols can be, for example, a gNB-CU-CP. Similarly, a network node supporting at least one of the RAN distributed unit functions or Layer 2 protocols can be, for example, a gNB-DU.

[0076] A gNB-CU can support one or more gNB-DUs. A gNB-DU can support one or more cells, and therefore can support the serving cell for the UE or candidate cells for handover, dual connectivity and / or carrier aggregation, and other procedures. The following will combine... Figure 2 Examples describing such a process.

[0077] UE 150 may be or include wireless or mobile devices, devices having a radio interface for interacting with a RAN (Radio Access Network), smartphones, in-vehicle devices, Internet of Things (IoT) devices, or M2M devices, and other types of user equipment. Such a UE 150 may include: at least one processor; and at least one memory comprising program code; wherein the at least one memory and the computer program code are configured, together with the at least one processor, to enable the device to perform at least certain operations, such as, for example, an RRC connection to the RAN. Figure 10 Examples of components describing the UE are provided. In an embodiment, UE 150 may be configured to generate messages (e.g., including a cell ID) to be transmitted via radio to the RAN (e.g., to reach and communicate with the serving cell). In an embodiment, UE 150 may generate, send, and receive RRC messages containing one or more RRCPDUs (Packet Data Units). Those skilled in the art will understand the RRC protocol and other processes that the UE may perform.

[0078] Continue to refer to Figure 1In the example of a 5G NR network, network system 100 provides cells that define the coverage area of ​​network system 100. As described above, network system 100 may include a gNB of the 5G NR network, or may include any other device configured to control radio communications and manage radio resources within the cell. As used herein, the term "resource" may refer to radio resources such as resource blocks (RBs), physical resource blocks (PRBs), radio frames, subframes, time slots, subbands, frequency regions, subcarriers, beams, etc. In an embodiment, network node 120 may be referred to as a base station and may use radio resources to communicate with UE 150.

[0079] 3GPP defines 5G NR frequency ranges such as Frequency Range 2 (FR2), covering 24.25 GHz to 52.6 GHz, which includes high frequencies and bands with ultra-wide bandwidths to accommodate high data rate use cases. Such bands may be subject to challenging propagation conditions, such as high path loss, absorption and penetration loss from the environment, and other conditions. To address these conditions, beam management procedures, such as using highly directional beams at network node 120 and UE 150, can be used.

[0080] Network node 120 may transmit broadcast information, such as, but not limited to, SSB, SIB, MCCH, etc., to facilitate UE 150's access to network system 100 and receipt of services from network system 100 (e.g., broadcast, multicast, and / or unicast services). Network node 120 may also transmit various reference signals, such as, but not limited to, channel state information reference signals (CSI-RS) and downlink reference signals (DL-RS), to facilitate channel measurement and reporting and / or beam search and management processes.

[0081] Figure 1 The examples provided are merely illustrative. Those skilled in the art will understand that network system 100 includes... Figure 1 Components not shown in the diagram, and it will be understood that other user equipment devices may communicate with network system 100.

[0082] In some examples, it may be beneficial for the network to utilize dual connectivity and / or carrier aggregation to increase the bandwidth and bit rate used for communication with the UE, as will be discussed below. Figure 2 A more comprehensive discussion.

[0083] Figure 2 This is a diagram illustrating an example embodiment of UE 210 communicating with MN 220 and SN 230. UE 210 can be substantially similar to... Figure 1UE 150. In an embodiment, MN 220 and / or SN 230 can be a 5G NR node (e.g., gNB) or an LTE network node (e.g., eNB) and other types of nodes. In an embodiment, MN 220 and / or SN 230 can be a BS. UE 210 can operate in dual connectivity mode. Dual connectivity allows UE 210 to connect to two network nodes simultaneously (e.g., MN 220 and SN 230 as shown in the figure).

[0084] In this embodiment, MN 220 is connected to a core network such as a 5G core (5GC) and provides control plane connectivity between UE 210 and the core network, while SN 230 is connected to MN 220 (e.g., via the Xn interface) and provides additional resources for user plane services. In this embodiment, MN 220 processes signaling messages, such as RRC signaling messages. In this embodiment, SN 230 may also process signaling messages, such as RRC signaling messages, using signaling radio bearers (SRBs) for LTE networks (e.g., SRB0, SRB1, and / or SRB2) and / or for 5G NR networks (e.g., SRB3). As will be understood by those skilled in the art, RRCs are used by nodes and UEs for various radio resource operations, such as, but not limited to, connection management and mobility functions. As used herein, the terms “transmit” and / or “receive” may refer to wirelessly transmitting and / or receiving on radio resources via a radio propagation channel, respectively. Those skilled in the art will understand RRC and SRB.

[0085] like Figure 2 As further shown in the example, carrier aggregation can be used in conjunction with dual connectivity. Carrier aggregation enables the UE210 to connect to multiple cells simultaneously for operation at multiple frequencies. In embodiments, multiple cells may be located at a single base station and / or a common location (e.g., a small cell or femtocell at a facility). One or more cells available to the UE under carrier aggregation may be referred to as a “cell group”. When carrier aggregation is used with dual connectivity, the MN and / or SN may have cell groups. The cell group of the MN may be referred to as the master cell group (MCG), and the cell group of the SN may be referred to as the secondary cell group (SCG). The MCG includes the primary cell (PCell) and may include one or more secondary cells (SCells). The SCG includes the master cell of the secondary cell group (PSCell) and may include one or more secondary cells (SCells). Figure 2In the example shown, MN 220 includes a PCell 222 and an SCell 224. Similarly, SN230 includes a PCell 232 and an SCell 234. Each of PCell 222, SCell 224, PCell 232, and SCell 234 can be composed of substantially the same components as... Figure 1 The network node 120 operates similarly to other network devices. Those skilled in the art will understand the characteristics and functions of such cells and cell groups.

[0086] Figure 2 The examples are merely illustrative. In embodiments, the number of PCells and SCells in MN and / or SN can vary and can be compared with... Figure 2 The ones shown are different.

[0087] As mentioned above, a UE can move from one area to another, and therefore the handover or mobility process is important for supporting continued communication between the UE and the network. Furthermore, a UE can receive multicast services from a first cell while operating in RRC state, and can select (or reselect) a second cell (the new cell) for camping. It may be expected that an RRC-inactive UE will continue to receive the same multicast services while camped in the second cell.

[0088] Figures 3 to 7 The various mechanisms used to provide multicast service continuity to RRC-inactive UEs in mobility will be discussed in relation to each other.

[0089] Figure 3 This is an illustration of an example embodiment of a multicast service continuity scenario for an RRC-inactive UE in mobility, based on an aspect of this disclosure. Figure 3 As shown, UE 310 can communicate with and be served by network node 320 (e.g., base station, gNB), as indicated by the solid arrow. UE 310 can essentially communicate with... Figure 1 UE 150 and / or Figure 2 Similar to UE 210. Network node 320 can be basically the same as... Figure 1 Network node 120 and / or Figure 2 The PCell 222, SCell 224, PCell232 and SCell 234 are similar.

[0090] At time T1, UE 310 can be in cell 302 operated by network node 320. When UE 310 is operating in RRC inactive state in cell 302, UE 310 can receive multicast service 350 from network node 320 via communication link 342. For example, UE 310 may have previously established an RRC connection with the network of network node 320, but the RRC connection may be in suspended mode. In addition, UE 310 may have performed a PDCP establishment procedure to receive multicast service 350. In the example, network node 320 can utilize the above reference Figure 1 The discussion and references below Figure 4 The protocol layers discussed further (e.g., SDAP, PDCP, RLC, MAC, and PHY) are used to send multicast service 350 to the UE (e.g., UE 310) in cell 302.

[0091] Network node 320 may include a PDCP entity that prepares data for multicast service 350 for transmission in the form of PDCP packets, wherein PDCP counter information (e.g., PDCP SN) is sent along with the data. For example, the PDCP SN of each packet in the packet sequence may increment by 1 sequentially. Another incrementing logic is also possible. As an example, network node 320 may send the nth packet with an attached PDCP SN of N, the next packet with an attached PDCP SN of (N+1) (e.g., the (n+1)th packet), the next packet with an attached PDCP SN of (N+2) (e.g., the (n+2)th packet), and so on. In this way, UE 310 can determine whether a packet is lost based on the PDCP SN of a previously received packet and the PDCP SN of the next received packet. If the previously received packet has a PDCP SN of 4 and the next received packet has a PDCP SN of 5, then no packet is lost. However, if a previously received packet has a PDCP SN of 4 and the next received packet has a PDCP SN of 6, then a lost packet (the packet with PDCP SN of 5) exists. In some examples, when UE 310 detects a lost packet, UE 310 can request a retransmission of the lost packet.

[0092] exist Figure 3In the example shown, UE 310 may be in a state of mobility. For example, at time T2, UE 310 may move to the edge of cell 302. UE 310 may, for example, choose (or reselect) another cell 304 in the network for camping based on signal measurements in cell 302. For example, UE 310 may detect a degradation in signal quality from cell 302 (e.g., based on measurements such as the Received Power of a Layer 1 Reference Signal (RSRP)) and thus search for a neighboring cell (e.g., cell 304) with better signal quality for camping. In general, UE 310 in an RRC inactive state may move to another cell within the network's Radio Access Network (RAN) Notification Area (RNA) while receiving multicast services without notifying the network of the move.

[0093] According to one aspect of this disclosure, UE 310 can receive an indication for PDCP counter synchronization across multiple network nodes (e.g., including network node 320 of cell 302 and network node 330 of cell 304) for multicast service 350. That is, each of the multiple network nodes can append the same PDCP counter information to a single data transmission of multicast service 350 when transmitting a single data transmission. Accordingly, the indication can instruct the network nodes to use the same PDCP counter for multicast service 350. In one aspect, the PDCP counter synchronization indication can be received from network node 320, for example, in an MCCH configuration or RRC release message. In another aspect, after UE 310 camps on cell 304, the PDCP counter synchronization indication can be received from network node 330, for example, in an MCCH configuration.

[0094] UE 310 can determine PDCP variable continuity based on the indication of PDCP counter synchronization. Based on the determined PDCP variable continuity, UE 310 can continue to receive multicast services from network node 320 via communication link 344 while camped in cell 304 (or operating in an RRC inactive or idle state). In this respect, an RRC inactive UE 310 can continue to receive multicast service 350 after moving to cell 304 without performing a PDCP establishment procedure in cell 304, and the variable tracking the PDCP counter (e.g., local at UE 310) can be retained during the move from cell 302 to cell 304 (e.g., not reset or discarded). As an example, if the last packet of multicast service 350 received by UE 310 from network node 320 has a PDCP SN with a value of K, UE 310 can use a variable to record the value K. After UE 310 camps on cell 304, UE 310 can expect to receive the next packet of multicast service 350 from network node 330, where the PDCP SN has a value (K+1). If UE 310 receives the next packet of multicast service 350 with a PDCP SN of value (K+2), without first receiving a packet with a PDCP SN of value (K+1), the UE is able to detect the lost packet because it has information that the network node uses the same PDCP counter for data packets. If UE 310 receives the next packet of multicast service 350 with a PDCP SN of value (K), the UE is able to detect the duplicate packet and discard it.

[0095] In one aspect, the indication of PDCP counter synchronization includes an indication that the PDCP counter is synchronized for multicast service 350 across all network nodes (including network node 320 and network node 330) in the network. In another aspect, the indication of PDCP counter synchronization includes an indication that the PDCP counter is synchronized for multicast service 350 across some network nodes (including network node 320 and network node 330) in the network, but there is at least one network node in the network where PDCP counter synchronization is not applied. Furthermore, the indication of PDCP counter synchronization may indicate one or more specific network nodes (e.g., gNB identifier (ID), cell ID, etc.) to which PDCP counter synchronization is applied. In another aspect, the indication of PDCP counter synchronization includes an indication of the LCID mapping between network node 320 and one or more other network nodes (e.g., network node 330) in the network to which PDCP counter synchronization is applied.

[0096] Figure 3 The examples are merely illustrative. In embodiments, the number of cells in the network and the number of UEs in the cells receiving multicast services can vary and can be compared with... Figure 3 The differences shown.

[0097] Figure 4 This is an illustration of an example embodiment of a network protocol architecture 400 for providing multicast services according to one aspect of this disclosure. In one aspect, Figure 3 Network node 320 and / or network node 330 can utilize architecture 400 to provide multicast service 350.

[0098] Architecture 400 can be part of the user plane of the Uu interface between the UE (e.g., UE 310) and the gNB (e.g., network nodes 320, 330). Figure 4 As shown, architecture 400 includes an SDAP sublayer 410, a PDCP sublayer 420, an RLC sublayer 430, and a MAC sublayer 440. Although not shown, architecture 400 also includes, as referenced above... Figure 1 The PHY layer under discussion provides a transport channel (denoted as DL-SCH) to the MAC sublayer 440. The MAC sublayer 440 provides a logical channel (denoted as MTCH, DTCH) to the RLC sublayer 430. The RLC sublayer 430 provides an RLC channel to the PDCP sublayer 420. The PDCP sublayer 420 provides MRBs (denoted as MRB1, MRB2, ...) to the SDAP sublayer 410.

[0099] The MAC sublayer 440 can perform various functions, including but not limited to Hybrid Automatic Repeat Request (HARQ), multiplexing, and scheduling and / or priority handling. The RLC sublayer 430 can perform various functions, including but not limited to fragmentation and Automatic Repeat Request (ARQ). The PDCP sublayer 420 can perform various functions, including but not limited to maintaining the PDCP SN, header compression, and decompression using the Robust Header Compression (ROHC) protocol. The SDAP sublayer 410 can perform various functions, including but not limited to mapping between QoS flows and MRBs, and marking QoS flow IDs (QFIs) in both downlink and uplink packets.

[0100] Those skilled in the art will understand the HARQ and scheduling and / or priority handling at MAC sublayer 440, the segmentation and ARQ at RLC sublayer 430, the maintenance of PDCP SN and header compression and decompression at PDCP sublayer 420, the mapping between QoS streams and MRB, and the marking of QFI at SDAP sublayer 410.

[0101] In one example, multicast session 402 may include one or more QoS flows associated with one or more multicast services (e.g., multicast service 350). To prevent... Figure 4The graph is cluttered, with only two QoS flows labeled 404 and 406. In one example, multicast session 402 can be identified by a Temporary Mobile Group Identity (TMGI) assigned by the core network. Multicast session 402 can include multiple QoS flows (e.g., a QoS flow 404 for audio and another QoS flow 406 for video) used to transmit data for a certain multicast service from the core network to the gNB (e.g., network node 320 and / or network node 330). The gNB can create an MRB (e.g., MRB1) for QoS flows 404 and 406. MRB1 can be identified by an MRB ID. The gNB can also map MRB1 to logical channel 408, which can be identified by an LCID.

[0102] In one example, network nodes 320 and 330 can each separately and independently map the QoS flows (e.g., QoS flows 404 and 406) of multicast service 350 to MRBs (e.g., MRB1). Furthermore, network nodes 320 and 330 can each separately and independently map the MRBs to LCIDs. Therefore, the same QoS flows for multicast service 350 can be mapped to different MRB IDs and / or different LCIDs at different network nodes. A one-to-one mapping typically exists between MRBs and LCIDs at a given network node.

[0103] As an example, network node 320 (in cell 302) can map QoS flows 404 and 406 to MRB ID1 and LCID 3, while network node 330 (in cell 304) can map QoS flows 404 and 406 to an MRB with MRB ID4 and LCID 2. Thus, to facilitate multicast service continuity for inactive UEs with RRC, network node 320 and / or network node 330 can provide UE 310 with an LCID mapping for multicast service 350. This LCID mapping may include an indication that LCID 3 at network node 320 is mapped to (or corresponds to) LCID 2 at network node 330. Additionally or alternatively, the LCID mapping may also include an indication that MRB ID 1 at network node 320 is mapped to (or corresponds to) MRBID 4 at network node 330. To facilitate LCID mapping, network nodes 320 and 330 can exchange LCID information on communication link 340 (e.g., the Xn interface). When performing such an exchange, they can indicate which LCID is mapped to which QoS flow ID (assigned by the core network and therefore shared across all gNBs). In this way, network nodes 320 and / or 330 can each determine the LCID mapping between network nodes 320 and 330 for multicast service 350 based on the exchanged LCID information.

[0104] Figure 4 The examples are merely illustrative. In embodiments, the mapping from one protocol layer to another can be different and can be consistent with... Figure 4 The mappings shown are different.

[0105] Typically, if PDCP COUNT / SN synchronization is applied in the network, RAN nodes (e.g., network nodes 120, 320, and 330, and network nodes PCell 222, SCell 224, PCell 232, and SCell 234) are configured with information that PDCP counter synchronization is applied in the network (or at least in a portion of the network, such as the vicinity of a particular RAN node). In one aspect, the RAN nodes can notify UEs (e.g., UEs 150, 210, and 310) of this configuration. Notification can be made via an indication from the UE (e.g., a PDCP counter synchronization indication), which is broadcast on the MCCH channel or sent to each UE within an RRC release message with suspendConfig.

[0106] In a first aspect, the PDCP counter synchronization indication can indicate that PDCP COUNT / SN synchronization is applied to all gNBs in the network (e.g., PLMN). In a second aspect, the PDCP counter synchronization indication can indicate that PDCP COUNT / SN synchronization is applied to a specific cell or gNB (per neighboring cell or near neighboring gNB information (e.g., synchronization between cells 1 and 2)). In a third aspect, the PDCP counter synchronization indication can indicate that PDCP COUNT / SN is not synchronized between gNBs. In some aspects, the UE can assume that PDCP COUNT / SN is synchronized among gNBs in the network unless indicated by an indication that PDCP COUNT / SN synchronization is not applied. In a fourth aspect, the PDCP counter synchronization indication can include a mapping from the LCID in the source cell (e.g., cell 302) to the neighboring cell (cell 304). Since the LCID has a one-to-one mapping to the MRB, if the gNB has a synchronized PDCP COUNT / SN, the UE can map the MRB of the source cell to the MRB of the target cell to achieve service continuity. Typically, the PDCP counter synchronization indication can include an LCID mapping in combination with the first or second aspect.

[0107] In some aspects, the LCID mapping to the UE signaling can be an implicit indication of PDCP COUNT / SN synchronization among cells in the network. Accordingly, upon receiving an indication of LCID mapping between the first and second cells, the UE can implicitly determine that the first and second cells use the same PDCP counter for data packets and continue to use the same PDCP counter after cell selection. Therefore, explicit indicators indicating PDCP counter synchronization are not needed in this embodiment.

[0108] On the one hand, when a UE operating in an RRC inactive state knows that its source cell and the target cell it has reselected have PDCP COUNT / SN synchronization, the UE can choose not to rebuild the PDCP entity upon entering the target cell. The UE can determine the variable continuity of PDCP from the source cell to the target cell (e.g., the continuity of the PDCP COUNT and / or PDCP SN). If multicast service is also provided to the UE in the target cell that is in an RRC inactive state, the UE can continue to receive multicast service upon reselecting the target cell. When the UE additionally knows that there is no PDCP COUNT / SN synchronization between gNBs, the UE can rebuild the PDCP entity in the target cell.

[0109] On one hand, the LCID mapping for multicast services can be signaled by the gNB via broadcast on the MCCH. On the other hand, in order for a gNB to know the LCIDs of neighboring gNBs, LCID information can be exchanged among the gNBs via the Xn interface (e.g., communication link 340). The exchanged LCID information may include a list of QFIs mapped to a specific LCID associated with the multicast service at a particular gNB (e.g., for QoS flow 404 and QoS flow 406). Accordingly, each gNB can determine the LCID mapping between its own LCID and the LCIDs of each neighboring gNB associated with the multicast service.

[0110] Typically, a mobile, RRC-inactive UE can receive information related to PDCP counter synchronization for multicast services in various ways, such as in the RRC release message and / or in the MCCH configuration, from the gNB of the source cell or from the gNB of the target cell, as will be referred to below. Figure 5 and 6 A more comprehensive discussion.

[0111] Figure 5This is an illustration of an example embodiment of an operation for providing multicast service continuity to an RRC-inactive UE in mobility, according to one aspect of this disclosure. The operation is implemented in the UE, gNB 1 serving cell 1, and gNB 2 serving cell 2. In one aspect, the UE, gNB 1, cell 1, gNB 2, and cell 2 correspond to UE 310, network node 320, cell 302, network node 330, and cell 304, respectively. In some examples, each of the UE, gNB 1, and gNB 2 can use a device having, as shown in the diagram... Figure 10 The apparatus of the components shown implements the operation. One or more of the following operations may be combined with the operations of this disclosure (e.g., referenced above). Figures 1 to 4 The example discussed is implemented. As shown in the figure, Figure 5 It includes multiple enumeration steps, but Figure 5 The operations in the enumeration process may include additional steps before, after, and between the enumeration steps. In some respects, one or more steps in the enumeration process may be omitted or performed in a different order.

[0112] At 510, gNB 1 is configured to synchronize PDCP counters among multiple gNBs in the PLMN (or typically the network) for providing multicast service A (e.g., multicast service 350). The multiple gNBs may include at least gNB 1 and gNB 2. Typically, gNB 1 may be configured with information to apply PDCP counter synchronization with one or more other gNBs in the PLMN. In some examples, gNB 1 is configured with information to apply PDCP counter synchronization with all gNBs in the PLMN associated with multicast service A. In one aspect, gNB 1 is configured with information that synchronization of the PDCP counter associated with multicast service A with some gNBs in the PLMN, but not all gNBs in the PLMN, is applied. In another aspect, gNB 1 is configured with information that synchronization of the PDCP counter associated with multicast service A with some cell IDs in the PLMN is applied. In one example, gNB 1 is configured for PDCP counter synchronization by the operator, the PLMN's OAM, etc. In other examples, the configuration for PDCP counter synchronization can be pre-configured at gNB 1.

[0113] At 520, gNB 2 is configured to perform PDCP counter synchronization among multiple gNBs in the PLMN for providing multicast service A (e.g., multicast service 350) in the same manner as gNB 1 in 510. Typically, gNB 2 can be configured with information to apply PCDP counter synchronization with one or more other gNBs in the PLMN. In one example, gNB 2 is configured for PDCP counter synchronization by the operator, the PLMN's OAM, etc.

[0114] At position 530, the UE operates in an RRC inactive state in cell 1 and receives multicast service A from gNB1 while operating in an RRC inactive state. In one example, the UE may have already performed a PDCP establishment procedure with gNB1 to receive multicast service A. In this example, gNB1 can create an MRB for one or more QoS flows (e.g., QoS flows 404 and 406) of multicast service A and can map the MRB to a logical channel identified by a certain LCID, as referenced above. Figure 3 The discussion continues. Furthermore, the PCDP entity at gNB 1 can transmit multicast service A data along with a PDCP counter (e.g., PDCP SN) to enable tracking of lost packets received at the UE, as referenced above. Figure 3 The subject of discussion.

[0115] At 540, gNB 1 sends a broadcast MCCH configuration, and the UE receives the broadcast MCCH configuration, which includes an indication of PDCP counter synchronization for multicast service A among multiple gNBs (e.g., at least gNB 1 and gNB 2).

[0116] On one hand, the MCCH configuration may include information indicating that the PDCP COUNT / SN is synchronized within the PLMN (e.g., all gNBs in the PLMN). This indication may be a one-bit flag. For example, the flag may be set to a value of 1 to indicate that PDCP counter synchronization is applied in the PLMN, or set to a value of 0 to indicate that PDCP counter synchronization is not applied in the PLMN, and vice versa.

[0117] On one hand, the MCCH configuration may include information instructing the PDCP COUNT / SN to be synchronized among some gNBs of the PLMN, rather than all gNBs of the PLMN. In an example, this information may include a list of neighboring gNBs and / or adjacent cells of the PDCP COUNT / SN synchronized for multicast service A.

[0118] On one hand, MCCH configuration can include a mapping between the LCID of cell 1 and the LCIDs of neighboring cells (e.g., the LCID of cell 2). For example, an RRC release message can indicate that LCID 1 of cell 1 is mapped to LCID 5 of cell 2, which is associated with multicast service A.

[0119] At 550, the UE, for example, learns (or determines) that the PDCPCOUNT / SN is synchronized in all gNBs of the PLMN, or in some gNBs of the PLMN, based on information in the MCCH configuration received at 540. The UE can also learn the LCID mapping of MRBs in cell 1 (the source cell) and neighboring cells (e.g., cell 2) based on information in the MCCH configuration received at 540. For example, the UE can learn that MRB 1 in cell 1, used to provide multicast service A, is mapped to MRB 4 in cell 2, also used to provide multicast service A. Furthermore, the UE can learn that MRB 1 in cell 1 is mapped to LCDI2, and MRB 4 in cell 2 is mapped to LCDI5.

[0120] At 560, the UE selects (or reselects) a new cell (cell 2) to camp on based on signal measurements (e.g., RSRP). The UE can continue operating in cell 2 in an RRC inactive state.

[0121] At position 570, gNB 2 transmits the SIB and MCCH configuration for cell 2, and the UE receives the SIB and MCCH configuration for cell 2. The UE learns the configuration for multicast service A. For example, gNB 2 periodically transmits the SIB and / or MCCH configuration, where the SIB can indicate scheduling information for the MCCH configuration (e.g., time and / or frequency location). Therefore, the UE can read the SIB from gNB 2 and monitor the MCCH configuration based on the scheduling information. When reading the MCCH configuration(s), the UE learns how to receive multicast service A.

[0122] At 580, the UE does not rebuild the PDCP (upon entering cell 2) and continues to receive multicast service A via the information in the MCCH configuration received at 540, based on the PDCP variable continuity. In other words, the UE can avoid performing the PDCP establishment process in cell 2 and continue using the PDCP entity established in cell 1. The PDCP variable continuity responds to the indication of PDCP counter synchronization. In this respect, the UE can map the MRB in the source cell (cell 1) to the MRB in the target cell (cell 2). Referring to the same example provided at 550, the UE can determine that multicast service A is provided in cell 2 via MRB 4 mapped to LCID5. Accordingly, the UE can continue to receive multicast service A data from the logical channel identified by LCID5 in cell 2. The UE can assume that the PDCP COUNT and / or PDCP SN can continue from the last corresponding PDCPCOUNT and / or PDCP SN received from cell 1. Furthermore, as part of continuing to receive multicast service in the second cell, the UE avoids performing the initialization of PDCP state variables. In other words, the UE can maintain the values ​​of all PDCP state variables of the first cell (e.g., RX_NEXT, RX_DELIV, and RX_REORD in NR).

[0123] On the one hand, the operations at 540, 550, and 570 can be performed after the UE reads the SIB and / or MCCH configuration from gNB 2 of cell 2 at 540. In other words, PDCP synchronization-related information is checked by the UE in the target cell (cell 2) rather than in the source cell (cell 1).

[0124] On one hand, enabling multicast reception for UEs in an RRC inactive state is a per-cell decision. Therefore, in some scenarios, after reading the MCCH configuration at 570, the UE may not find multicast service A provided to UEs in an RRC active state. In this scenario, the UE can reconnect to receive multicast service A in an RRC connected state. On another hand, the UE may receive from gNB 1 an indication that a neighboring cell (e.g., cell 2) does not support multicast services for RRC inactive UEs. On yet another hand, the UE may receive from gNB 1 an indication that a neighboring cell (e.g., cell 2) does not provide multicast service A to any UE because no UE in cell 2 has joined a multicast session for multicast service A.

[0125] Figure 6This is an illustration of an example embodiment of an operation for providing multicast service continuity to an RRC-inactive UE in mobility, according to one aspect of this disclosure. The operation is implemented between the UE, gNB 1 serving cell 1, and gNB 2 serving cell 2. In one aspect, the UE, gNB 1, cell 1, gNB 2, and cell 2 correspond to UE 310, network node 320, cell 302, network node 330, and cell 304, respectively. In some examples, each of the UE, gNB 1, and gNB 2 can use a device having, as shown in the diagram... Figure 10 The apparatus of the components shown is used to implement the operation. One or more of the following operations can be combined with the operations of the present invention (e.g., as referenced above). Figures 1 to 5 The example discussed is implemented. As shown in the figure, Figure 6 It includes multiple enumeration steps, but Figure 6 The operations in the enumeration process may include additional steps before, after, and between the enumeration steps. In some respects, one or more steps in the enumeration process may be omitted or performed in a different order.

[0126] Generally speaking, Figure 6 The operation includes many aspects similar to Figure 5 The characteristics of the operations are as follows. For example, the operations at steps 610, 620, 660, 670, 680, and 690 are similar to those at steps 510, 520, 550, 560, 570, and 580, respectively. Therefore, for the sake of brevity, the details of these steps will not be repeated here, but can be referred to the corresponding descriptions above.

[0127] At 630, in cell 1, the UE operates in RRC connection state and receives multicast service A from gNB 1 while operating in RRC connection state.

[0128] At position 640, gNB 1 sends an RRC release message with suspendConfig, and the UE receives the RRC release message with suspendConfig. This means the UE is released (or transitioned) to an RRC inactive state.

[0129] On one hand, the RRC release message may include information indicating that the PDCP COUNT / SN is synchronized in the PLMN (e.g., all gNBs in the PLMN). This indication may be a one-bit flag. For example, the flag may be set to a value of 1 to indicate that PDCP counter synchronization is applied in the PLMN, or set to a value of 0 to indicate that PDCP counter synchronization is not applied in the PLMN, and vice versa.

[0130] On one hand, the RRC release message may include information instructing the PDCP COUNT / SN to synchronize among some gNBs of the PLMN, but not all gNBs of the PLMN. In an example, this information may include a list of neighboring gNBs and / or adjacent cells of the PDCPCOUNT / SN synchronized for multicast service A.

[0131] On one hand, the RRC release message may include a mapping between the LCID of cell 1 and the LCID of a neighboring cell (e.g., the LCID of cell 2). For example, the RRC release message may indicate that LCID 1 of cell 1 is mapped to LCID 5 of cell 2, which is associated with multicast service A.

[0132] At 650, in response to the RRC release message, the UE is in an RRC inactive state. When the UE operates in the RRC inactive state in cell 1, it receives multicast service A from gNB 1.

[0133] The operation at 660 is basically similar to the operation at 550, but the UE can base its actions on the information in the RRC release message received at 640, instead of... Figure 5 The MCCH configuration in the system is used to obtain (or determine) PDCP counter synchronization and / or LCID mapping information between networks or network nodes associated with multicast service A.

[0134] Although discussed in the context of an inactive UE receiving multicast service A during mobility in RRC. Figure 5 and 6 The operation is similar, but not limited to this. For example, an RRC idle UE in cell 1 can also receive multicast service A, receive PDCP counter synchronization instructions, select cell 2 for camping, and continue to receive multicast service A in cell 2 using the same mechanism as the aforementioned RRC inactive UE.

[0135] Figure 7 This is an illustration of an example embodiment of an operation for providing multicast service continuity to an RRC-inactive UE in mobility, according to one aspect of this disclosure. The operation is implemented in serving cell 1 of gNB 1 and serving cell 2 of gNB 2. In one aspect, gNB 1, cell 1, gNB 2, and cell 2 correspond to network node 320, cell 302, network node 330, and cell 304, respectively. In another aspect, gNB 1, cell 1, gNB 2, and cell 2 correspond to network node 330, cell 304, network node 320, and cell 302, respectively. In some examples, each of gNB 1 and gNB 2 can use a device having, as shown in the figure... Figure 10 The apparatus of the components shown implements the operation. One or more of the following operations may be combined with the operations of this disclosure (e.g., referenced above). Figures 1 to 6The example discussed is implemented. As shown in the figure, Figure 7 It includes multiple enumeration steps, but Figure 7 The operations in the enumeration process may include additional steps before, after, and between the enumeration steps. In some respects, one or more steps in the enumeration process may be omitted or performed in a different order.

[0136] At 710, gNB 1 is configured to synchronize the PDCP counters among multiple gNBs in the PLMN (or typically the network) for providing multicast service A (e.g., multicast service 350). The multiple gNBs may include at least gNB 1 and gNB 2. Typically, gNB 1 may be configured with information to apply PDCP counter synchronization with one or more other gNBs in the PLMN. In some examples, gNB 1 may be configured with information to apply PDCP counter synchronization with all gNBs in the PLMN associated with multicast service A. In one aspect, gNB 1 is configured with information that synchronization of the PDCP counter associated with multicast service A with some gNBs in the PLMN, but not all gNBs in the PLMN, is applied. In another aspect, gNB 1 is configured with information that synchronization of the PDCP counter associated with multicast service A with some cell IDs in the PLMN is applied. In one example, gNB 1 is configured for PDCP counter synchronization by the operator, the PLMN's OAM, etc. In other examples, the configuration for PDCP counter synchronization can be pre-configured at gNB 1.

[0137] At 720, gNB 1 performs setup with the core network for multicast service A (e.g., multicast service 350). Setup may include communicating with the PLMN's core network to retrieve information, such as QoS information, to provide multicast service in one of gNB 1's cells. Such setup may also include retrieving relevant data from the core network to provide it to the UE on the air interface. gNB initiates this setup with the core network once a UE context indicating that the UE has joined a multicast session exists.

[0138] At 730, gNB 2 is configured to perform PDCP counter synchronization among multiple gNBs in the PLMN for providing multicast service A (e.g., multicast service 350) in the same manner as gNB 1 in 510. Typically, gNB 2 can be configured with information to apply PCDP counter synchronization with one or more other gNBs in the PLMN. In one example, gNB 2 is configured for PDCP counter synchronization by the operator, the PLMN's OAM, etc.

[0139] The operations at 710 and 730 can be basically similar to those at 510, 520, 610 and 620.

[0140] At 740, gNB 2 performs setup for multicast service A (e.g., multicast service 350) with the core network.

[0141] In the example, multicast sessions are being conducted for multicast service A at gNB 1 (based on the settings at 720) and gNB 2 (based on the settings at 740), respectively.

[0142] At 750, gNB 1 sends the LCID information for cell 1 associated with multicast service A, along with the LCID-to-QFI mapping, and gNB 2 receives the LCID information for cell 1 associated with multicast service A, along with the LCID-to-QFI mapping. Typically, gNB 1 can send LCID information to each neighboring cell of gNB 1 and map this information to QFIs. For each multicast session at gNB 1 (e.g., multicast service A), the LCID information may include a list of LCIDs for each MRB involved in the multicast session. For each LCID, the LCID information may also include a list of QFIs associated with the corresponding MRB.

[0143] At 760, gNB 2 sends the LCID information for cell 2 associated with multicast service A, and gNB 1 receives the LCID information for cell 2 associated with multicast service A. Typically, gNB 2 may send LCID information to each of its neighboring cells. For each multicast session at gNB 2 (e.g., multicast service A), the LCID information may include a list of LCIDs for each MRB involved in the multicast session. For each LCID, the LCID information may also include multiple lists of QFIs associated with the corresponding MRB.

[0144] In one example, gNB 1 can send the LCID information of cell 1 at 750 as part of an XN setup request. In response, gNB 2 can send the LCID information of cell 2 at 760 as part of an XN setup response. In some examples, gNB 1 can send updates about its LCID information. Similarly, gNB 2 can send updates about its LCID information and / or RAN configuration updates. In such an example, gNB 1 can send the LCID information of cell 1 at 750 as part of a RAN configuration update message. Similarly, gNB 2 can send the LCID information of cell 2 at 760 as part of a RAN configuration update message.

[0145] At 770, gNB 1 can determine the mapping between its own (multiple) LCIDs and the LCIDs of cell 2 based on the LCDI information received at 760. At 780, gNB 2 can determine the mapping between its own (multiple) LCIDs and the LCIDs of cell 1 based on the LCDI information received at 750.

[0146] As an example, at 750, gNB 1 can indicate that MRB 1 is associated with a multicast service, and LCID 3 is associated with QFI 1 and QFI 2 for multicast service A. At 760, gNB 2 can indicate that MRB 2 is associated with a multicast service, and at 760, LCID 5 is associated with QFI 1 and QFI 2 for multicast service A. Thus, at 770, gNB 1 can determine that gNB 1's MRB 1 is mapped to gNB 2's MRB 2, and gNB 1's LCID 3 is mapped to gNB 2's LCID 5 associated with multicast service A. At 780, gNB 2 can determine that gNB 2's MRB 2 is mapped to gNB 1's MRB 1, and gNB 2's LCID 5 is mapped to gNB 1's LCID 3 associated with multicast service A.

[0147] Subsequently, gNB 1 can send an indication for synchronization of the PDCP counter in the PLMN's gNB, wherein the indication may include the mapping determined at 770, to use the referenced above. Figure 5 and Figure 6 The basic mechanism discussed is similar to facilitate multicast service continuity for inactive UEs in mobility for RRC purposes. Similarly, gNB 2 can send an indication of PDCP counter synchronization within the PLMN's gNB, where the indication can include the mapping determined at 780 to use the referenced above. Figure 5 and Figure 6 The basic similar mechanisms discussed here facilitate multicast service continuity for inactive RRC UEs during mobility.

[0148] Figures 5 to 7 The examples are merely illustrative. In embodiments, the number of neighboring cells and the number of UEs within the cell receiving multicast service can vary and can be compared with... Figures 5 to 7 The differences shown.

[0149] Figure 8 This is a flowchart illustrating an exemplary operation of a UE for multicast service continuity according to one aspect of this disclosure. The UE can be similar to the one described above. Figures 5-6 The UEs discussed are 150, 210, 310, and / or UEs. In some examples, the UE can use devices with features such as... Figure 10 The device shown implements the operation using the components. Figure 8 The operations can include those referenced above. Figures 3-7 A similar mechanism to the one discussed. As shown in the figure, Figure 8 It includes multiple enumeration steps, but Figure 8 The operations in the enumeration process may include additional steps before, after, and between the enumeration steps. In some respects, one or more steps in the enumeration process may be omitted or performed in a different order.

[0150] At point 802, the operation includes: while operating in the first cell in an RRC inactive or RRC idle state, receiving multicast services from the first network node of the first cell. The first network node can be similar to the referenced above. Figures 5 to 7 The network nodes discussed are 120, 320, 330, PCell 222, SCell 224, PCell 232, and SCell 234, and / or gNB1 and gNB2. The first cell can be similar to the one described above. Figures 5 to 7 The communities discussed are 302, 304 and / or 1 and 2.

[0151] At 804, the operation includes: receiving an indication for PDCP counter synchronization across multiple network nodes for a multicast service, wherein the multiple network nodes include a first network node.

[0152] On one hand, receiving an indication for PDCP counter synchronization includes receiving an indication of LCID mapping between at least a first network node and a second network node for a multicast service. The indication of LCID mapping is an indication of PDCP counter synchronization and implicitly indicates PDCP counter synchronization across multiple network nodes.

[0153] In one aspect, receiving an indication to synchronize PDCP counters includes receiving an indication to synchronize PDCP counters from a first network node before selection. In another aspect, receiving an indication to synchronize PDCP counters includes receiving an indication to synchronize PDCP counters from a second network node after reselection. In another aspect, receiving an indication to synchronize PDCP counters includes receiving an indication to synchronize PDCP counters in an RRC release message. In yet another aspect, receiving an indication to synchronize PDCP counters includes receiving an indication to synchronize PDCP counters in the MCCH configuration.

[0154] At point 806, the operation involves selecting a second cell for camping. The second cell can be similar to the one described above. Figures 5 to 7 The discussion covers cells 302, 304 and / or cells 1 and 2.

[0155] At 808, the operation includes, based on PDCP variable continuity, continuing to receive multicast services from a second network node in a second cell, wherein the plurality of network nodes includes the second network node, and wherein the PDCP variable continuity is in response to an indication of PDCP counter synchronization. The second network node may be similar to the one referenced above. Figures 5 to 7 The network nodes discussed are network nodes 120, 320, 330, PCell 222, SCell 224, PCell 232, and SCell 234, and / or gNB1 and gNB2. In one aspect, PDCP variable continuity can refer to the UE continuing to track PDCP counters for data packets received for multicast services in a second cell based on the last PDCP counter received in the first cell. Typically, PDCP variable continuity can mean that the UE uses variables of the PDCP context (or PDCP entity) when operating in the first cell and continues to use the same PDCP variables when operating in the second cell without resetting the values ​​of the PDCP variables.

[0156] In one aspect, continuing to receive multicast services in the second cell includes: in response to an instruction to synchronize the PDCP counter, avoiding performing PDCP reconstruction in the second cell associated with the multicast service.

[0157] On one hand, the indication of PDCP counter synchronization at 802 includes an indication of LCID mapping: for multicast service, a first LCID value associated with the first network node is mapped to a second LCID value associated with the second network node, and continuing to receive multicast service in the second cell at 808 includes receiving multicast service via a logical channel identified by the second LCID value. Furthermore, continuing to receive multicast service in the second cell at 808 includes: in response to receiving the LCID mapping, applying the PDCP counter of the first cell in the second cell to receive the multicast service.

[0158] On the other hand, the UE also determines the variable continuity of PDCP in response to the indication of PDCP counter synchronization.

[0159] Figure 9 This is a flowchart illustrating an exemplary operation of a network node for multicast service continuity, based on one aspect of this disclosure. The network node can be similar to the one described above. Figures 5-7 The network nodes discussed are 120, 320, 330, PCell 222, SCell 224, PCell 232, and SCell 234, and / or gNB1 and gNB2. In some examples, network nodes can use those with features such as Figure 10 The device shown implements the operation using the components. Figure 9 The operations can include those referenced above. Figures 3 to 7 A similar mechanism to the one discussed. As shown in the figure, Figure 9 It includes multiple enumeration steps, but Figure 9 The operations in the enumeration process may include additional steps before, after, and between the enumeration steps. In some respects, one or more steps in the enumeration process may be omitted or performed in a different order.

[0160] At 902, the operation includes determining that PDCP counter synchronization across multiple network nodes is applied to the multicast service, where the multiple network nodes include network nodes.

[0161] On one hand, sending the indication for PDCP counter synchronization includes sending an indication for a multicast service, specifying the LCID mapping between the network node and at least one other network node among a plurality of network nodes. On the other hand, the UE determines the LCID mapping between the network node and other network nodes for the multicast service.

[0162] At 904, the operation includes: in response to the determination, sending an indication to UE 150 for PDCP counter synchronization across multiple network nodes for multicast services.

[0163] On one hand, the UE also exchanges LCID information associated with the multicast service with other network nodes (e.g., via the Xn interface) among multiple network nodes. On the other hand, the LCID information includes indications of one or more QFIs mapped to individual LCIDs associated with the multicast service.

[0164] In one aspect, exchanging LCID information associated with a multicast service includes sending the LCID information of the network node associated with the multicast service to other network nodes, and receiving the LCID information of other network nodes associated with the multicast service from other network nodes. In one aspect, sending the LCID information of a network node is in response to receiving the LCID information of other network nodes. In another aspect, receiving the LCID information of other network nodes is in response to sending the LCID information of that network node.

[0165] On one hand, sending the PDCP counter synchronization indication includes sending the PDCP counter synchronization indication to the UE in the RRC release message. On the other hand, sending the PDCP counter synchronization indication includes sending the PDCP counter synchronization indication to the UE in the MCCH configuration.

[0166] Figure 10 An example embodiment is shown, illustrating block diagrams of example components of a UE or network device (or network node). For example, the UE may correspond to the above reference. Figures 5 to 6 The UEs discussed are 150, 210, 310 and / or UEs, and the network devices may correspond to the above references. Figures 5-7The network nodes discussed are network nodes 120, 320, 330, PCell 222, SCell 224, PCell 232, and SCell 234, and / or gNB1 and gNB2. The device includes electronic storage device 1110, processor 1120, memory 1150, and network interface 1140. The various components are communicatively coupled to each other. Processor 1120 can be and may include any type of processor, such as a single-core central processing unit (CPU), multi-core CPU, microprocessor, digital signal processor (DSP), system-on-a-chip (SoC), or any other type of processor. Memory 1150 can be volatile memory, such as RAM, or non-volatile memory, such as NAND flash memory. The memory 1150 includes computer-readable instructions executable by the processor 1120 to enable the device to perform various operations, including indications for PDCP counter synchronization (e.g., including LCID mapping information across (multiple) cells associated with multicast services) and / or operations related to multicast service continuity for RRC inactive UEs and / or RRC idle UEs in mobility as discussed herein.

[0167] Electronic storage device 1110 can be and includes any type of electronic storage device for storing data, such as hard disk drives, solid-state drives, and / or optical disks, as well as other types of electronic storage devices. Electronic storage device 1110 stores software instructions for causing the device to perform its operations, and stores data associated with such operations, such as data related to the 5G NR standard and other data. Network interface 1140 can implement wireless network technologies, such as 5G NR, Wi-Fi 6, and / or other wireless networking technologies, and may include one or more arrays of radiating elements, such as those combined with… Figures 1 to 9 Those described.

[0168] Figure 10 The components shown are merely examples, and those skilled in the art will understand that the apparatus includes other components not shown, and may include multiple components of any of the components shown. Such and other embodiments are contemplated within the scope of this disclosure.

[0169] Other embodiments of this disclosure include the following examples.

[0170] Example 1 includes a method performed by a user equipment device, the method comprising: receiving multicast services from a first network node (e.g., gNB1) of the first cell while operating in a radio resource control (RRC) inactive state or an RRC idle state in the first cell; receiving an indication for synchronization of Packet Data Convergence Protocol (PDCP) counters across multiple network nodes for the multicast services, wherein the multiple network nodes include the first network node; selecting a second cell for camping; and continuing to receive multicast services from a second network node (e.g., gNB2) of the second cell in the second cell based on PDCP variable continuity, wherein the multiple network nodes include the second network node, and wherein the PDCP variable continuity responds to the indication for PDCP counter synchronization.

[0171] In Example 2, the method of Example 1 may optionally include: wherein continuing to receive multicast services in the second cell includes: avoiding performing PDCP reconstruction in the second cell associated with the multicast service.

[0172] In Example 3, the method of any one of Examples 1 to 2 may optionally include: further including: determining PDCP variable continuity in response to an indication of PDCP counter synchronization, wherein continuing to receive multicast service in the second cell includes: receiving packets associated with the multicast service by applying the determined PDCP variable continuity.

[0173] In Example 4, the method of any one of Examples 1 to 3 may optionally include: wherein receiving an indication of PDCP counter synchronization includes: receiving an indication of a logical channel identifier (LCID) mapping for a multicast service, at least between a first network node and a second network node.

[0174] In Example 5, the method of any one of Examples 1 to 4 may optionally include, for the multicast service, an indication of LCID mapping to indicate that a first LCID value associated with a first network node is mapped to a second LCID value associated with a second network node, and continuing to receive the multicast service in the second cell includes: receiving the multicast service via a logical channel identified by the second LCID value. The indication of LCID mapping is an indication of PDCP counter synchronization and implicitly indicates PDCP counter synchronization across multiple network nodes. Continuing to receive the multicast service in the second cell may optionally include: in response to receiving the LCID mapping, applying the PDCP counter of the first cell in the second cell to receive the multicast service.

[0175] In Example 6, the method of any one of Examples 1 to 5 may optionally include: wherein receiving the indication for PDCP counter synchronization includes receiving the indication for PDCP counter synchronization from the first network node prior to reselection.

[0176] In Example 7, the method of any one of Examples 1 to 6 may optionally include: wherein receiving the indication for PDCP counter synchronization includes receiving the indication for PDCP counter synchronization from the second network node after reselection.

[0177] In Example 8, the method of any one of Examples 1 to 7 may optionally include: wherein receiving the indication of PDCP counter synchronization includes receiving the indication of PDCP counter synchronization in the RRC release message.

[0178] In Example 9, the method of any one of Examples 1 to 8 may optionally include: wherein receiving the indication for PDCP counter synchronization includes receiving the indication for PDCP counter synchronization in the multicast control channel (MCCH) configuration.

[0179] Example 10 includes an apparatus comprising at least one processor; and at least one memory storing instructions that, when executed by the at least one processor, cause the network apparatus to perform at least any one of the methods of Examples 1 to 9.

[0180] Example 11 includes an apparatus comprising at least one component for performing the method of any one of Examples 1 to 9.

[0181] Example 12 includes a non-transitory computer-readable medium comprising program code that, when executed by one or more processors, causes one or more processors to perform at least one of the methods of Examples 1 to 9.

[0182] Example 13 includes a method performed by a network node, the method comprising: determining that Packet Data Convergence Protocol (PDCP) counter synchronization across multiple network nodes is applied to a multicast service, wherein the multiple network nodes include network nodes; and in response to the determination, sending an indication to a user equipment (UE) device for PDCP counter synchronization across multiple network nodes for the multicast service.

[0183] In Example 14, the method of Example 13 may optionally include: wherein sending an indication for PDCP counter synchronization includes sending an indication for a logical channel identifier (LCID) mapping between a network node and at least another network node among a plurality of network nodes for a multicast service.

[0184] In Example 15, the method of any of Examples 13 to 14 may optionally include: determining the LCID mapping between network nodes and other network nodes for the multicast service.

[0185] In Example 16, the method of any one of Examples 13 to 15 may optionally include exchanging Logical Channel Identifier (LCID) information associated with the multicast service with another network node among a plurality of network nodes (e.g., via the Xn interface).

[0186] In Example 17, the method of any of Examples 13 to 16 may optionally include, wherein the LCID information includes an indication of one or more Quality of Service Flow Identifiers (QFIs) mapped to an individual LCID associated with the multicast service.

[0187] In Example 18, the method of any one of Examples 13 to 17 may optionally include: wherein exchanging LCID information associated with the multicast service includes: sending LCID information of the network nodes associated with the multicast service to other network nodes; and receiving LCID information of other network nodes associated with the multicast service from other network nodes.

[0188] In Example 19, the method of any one of Examples 13 to 18 may optionally include: wherein sending the LCID information of a network node in response to receiving the LCID information of another network node.

[0189] In Example 20, the method of any one of Examples 13 to 19 may optionally include: wherein receiving LCID information of other network nodes in response to sending LCID information of network nodes.

[0190] In Example 21, the method of any one of Examples 13 to 20 may optionally include: wherein sending the indication for PDCP counter synchronization includes sending the indication for PDCP counter synchronization to the UE in the RRC release message.

[0191] In Example 22, the method of any one of Examples 13 to 21 may optionally include: wherein sending the indication for PDCP counter synchronization includes: sending the indication for PDCP counter synchronization to the UE in the multicast control channel (MCCH) configuration.

[0192] Example 23 includes an apparatus comprising at least one processor; and at least one memory storing instructions that, when executed by the at least one processor, cause the network apparatus to perform at least any one of Examples 13 to 23.

[0193] Example 24 includes an apparatus comprising at least one component for performing the method of any one of Examples 13 to 22.

[0194] Example 25 includes a non-transitory computer-readable medium comprising program code that, when executed by one or more processors, causes one or more processors to perform at least any one of Examples 13 to 22.

[0195] The embodiments and aspects disclosed herein are examples of this disclosure and may be embodied in various forms. For example, although some embodiments herein are described as separate embodiments, each embodiment herein may be combined with one or more other embodiments herein. The specific structural and functional details disclosed herein should not be construed as limiting, but rather serve as the basis for the claims and as a representative basis for teaching those skilled in the art to employ this disclosure differently in virtually any suitably detailed structure. Throughout the description of the accompanying drawings, the same reference numerals may refer to similar or identical elements.

[0196] The phrases “in one aspect,” “in all aspects,” “in some aspects,” or “in other aspects” may each refer to one or more of the same or different aspects according to the invention. The phrase “multiple” may refer to two or more.

[0197] The phrases “in one embodiment,” “in an embodiment,” “in various embodiments,” “in some embodiments,” or “in other embodiments” may each refer to one or more of the same or different embodiments according to this disclosure. A phrase of the form “A or B” means “(A), (B), or (A and B).” A phrase of the form “at least one of A, B, or C” means “(A); (B); (C); (A and B); (A and C); (B and C); or (A, B, and C).”

[0198] Any of the methods, programs, algorithms, or code described herein can be converted into or expressed as a programming language or computer program. As used herein, the terms “programming language” and “computer program” each include any language used to specify instructions to a computer, and include (but are not limited to) the following languages ​​and their derivatives: assembler, Basic, batch file, BCPL, C, C++, Delphi, Fortran, Java, JavaScript, machine code, operating system command languages, Pascal, Perl, PL1, Python, scripting languages, Visual Basic, meta-languages ​​that specify the program itself, and all first, second, third, fourth, fifth, or further generated computer languages. Databases and other data schemas, as well as any other meta-languages, are also included. There is no distinction between languages ​​that are interpreted, compiled, or use compilation and interpretation methods. There is no distinction between a compiled version and a source version of a program. Therefore, a reference to a program in which a programming language may exist in more than one state (such as source, compiled, object, or linked) is a reference to any and all such states. A reference to a program may encompass the actual instructions and / or the intent of those instructions.

[0199] While various aspects of this disclosure have been shown in the accompanying drawings, they are not intended to limit the disclosure thereto, as this disclosure is intended to be as broad as possible within the scope permitted by the art, and this specification should also be interpreted with the corresponding breadth. Therefore, the foregoing description should not be construed as limiting, but merely as exemplary of particular aspects. Those skilled in the art will be able to conceive of other modifications within the scope and spirit of the appended claims.

Claims

1. A user equipment apparatus, comprising: At least one processor; as well as At least one memory stores instructions that, when executed by the at least one processor, cause the user equipment device to at least: While operating in the first cell in a Radio Resource Control (RRC) inactive state or an RRC idle state, the multicast service is received from the first network node of the first cell. Receive an indication for synchronization of Packet Data Convergence Protocol (PDCP) counters across multiple network nodes for a multicast service, wherein the multiple network nodes include the first network node; Select a second residential area for residence; and Based on PDCP variable continuity, the multicast service continues to be received from a second network node in the second cell, wherein the plurality of network nodes includes the second network node, and wherein the PDCP variable continuity is in response to an indication of PDCP counter synchronization.

2. The user equipment apparatus of claim 1, wherein the instructions, when executed by the at least one processor, cause the user equipment apparatus to continue receiving the multicast service in the second cell by at least the following: In response to the indication of PDCP counter synchronization, at least one of PDCP reconstruction or PDCP state variable initialization associated with the multicast service is avoided in the second cell.

3. The user equipment device according to claim 1, When the instructions are executed by the at least one processor, they also cause the user equipment device to at least: In response to the indication of PDCP counter synchronization, the variable continuity of the PDCP is determined; and When the instructions are executed by the at least one processor, the user equipment device causes at least: to continue receiving the multicast service by applying the determined PDCP variable continuity, in order to receive packets associated with the multicast service in the second cell.

4. The user equipment apparatus of claim 1, wherein the instructions, when executed by the at least one processor, cause the user equipment apparatus to receive the indication of PDCP counter synchronization by at least the following: Receive an indication of a logical channel identifier (LCID) mapping for the multicast service, at least between the first network node and the second network node.

5. The user equipment apparatus according to claim 4, The LCID mapping indication is used to indicate that the first LCID value associated with the first network node is mapped to the second LCID value associated with the second network node, and When the instructions are executed by the at least one processor, the user equipment device causes to continue receiving the multicast service in the second cell by at least the following: The multicast service is received via a logical channel identified by the second LCID value.

6. The user equipment apparatus of claim 4, wherein the instructions, when executed by the at least one processor, cause the user equipment apparatus to continue receiving the multicast service in the second cell by at least the following: In response to receiving the LCID mapping, the PDCP counter of the first cell is applied in the second cell to receive the multicast service.

7. The user equipment apparatus of claim 1, wherein the instructions, when executed by the at least one processor, cause the user equipment apparatus to receive the indication of PDCP counter synchronization by at least the following: Prior to the selection, the indication of PDCP counter synchronization is received from the first network node.

8. The user equipment apparatus of claim 1, wherein the instructions, when executed by the at least one processor, cause the user equipment apparatus to receive the indication of PDCP counter synchronization by at least the following: Following the selection, the indication for PDCP counter synchronization is received from the second network node.

9. The user equipment apparatus of claim 1, wherein the instructions, when executed by the at least one processor, cause the user equipment apparatus to receive the indication of PDCP counter synchronization by at least the following: The indication for PDCP counter synchronization is received in the RRC release message.

10. The user equipment apparatus of claim 1, wherein the instructions, when executed by the at least one processor, cause the user equipment apparatus to receive the indication of PDCP counter synchronization by at least the following: The indication of PDCP counter synchronization is received in the multicast control channel (MCCH) configuration.

11. A method performed by a user equipment device, the method comprising: While operating in a Radio Resource Control (RRC) inactive state in the first cell, multicast services are received from the first network node of the first cell; Receive an indication for synchronization of Packet Data Convergence Protocol (PDCP) counters across multiple network nodes for a multicast service, wherein the multiple network nodes include the first network node; Select a second residential area for residence; and Based on PDCP variable continuity, the multicast service continues to be received from a second network node in the second cell, wherein the plurality of network nodes includes the second network node, and wherein the PDCP variable continuity is in response to an indication of PDCP counter synchronization.

12. The method of claim 11, wherein continuing to receive the multicast service in the second cell comprises: In response to the indication of PDCP counter synchronization, at least one of PDCP reconstruction or PDCP state variable initialization is avoided in the second cell associated with the multicast service.

13. The method of claim 11, further comprising: In response to the indication of PDCP counter synchronization, the variable continuity of PDCP is determined in the second cell; as well as The multicast service is continued to be received by applying the determined PDCP variable continuity in order to receive packets associated with the multicast service in the second cell.

14. The method of claim 11, wherein receiving the indication of synchronization of the PDCP counter comprises: Receive an indication of a logical channel identifier (LCID) mapping for the multicast service, at least between the first network node and the second network node.

15. The method of claim 14, wherein the LCID mapping indication is used to indicate that a first LCID value associated with the first network node is mapped to a second LCID value associated with the second network node, and Continuing to receive the multicast service in the second cell includes: The multicast service is received via a logical channel identified by the second LCID value.

16. The method of claim 14, wherein continuing to receive the multicast service in the second cell comprises: In response to receiving the LCID mapping, the PDCP counter of the first cell is applied in the second cell to receive the multicast service.

17. The method of claim 11, wherein receiving the indication of synchronization of the PDCP counter comprises: Prior to the selection, the indication of PDCP counter synchronization is received from the first network node.

18. The method of claim 11, wherein receiving the indication of synchronization of the PDCP counter comprises: Following the selection, the indication for PDCP counter synchronization is received from the second network node.

19. The method of claim 11, wherein receiving the indication of synchronization of the PDCP counter comprises: The indication for PDCP counter synchronization is received in the RRC release message.

20. The method of claim 11, wherein receiving the indication of synchronization of the PDCP counter comprises: The indication of PDCP counter synchronization is received in the multicast control channel (MCCH) configuration.

21. A network node, comprising: At least one processor; as well as At least one memory stores instructions that, when executed by the at least one processor, cause the network node to at least: It is determined that Packet Data Convergence Protocol (PDCP) counter synchronization across multiple network nodes is applied to the multicast service, wherein the multiple network nodes include the network nodes; as well as In response to the determination, an indication for PDCP counter synchronization across the multiple network nodes for the multicast service is sent to the user equipment (UE).

22. The network node of claim 21, wherein the instruction, when executed by the at least one processor, causes the network node to send the indication for PDCP counter synchronization at least by: Send an indication of a logical channel identifier (LCID) mapping between the network node and at least one other network node among the plurality of network nodes for the multicast service.

23. The network node of claim 21, wherein the instructions, when executed by the at least one processor, further cause the network node to at least: For the multicast service, determine the LCID mapping between the network node and other network nodes.

24. The network node of claim 21, wherein the instruction, when executed by the at least one processor, causes the network node to send the indication for PDCP counter synchronization at least by: In at least one of the Multicast Control Channel (MCCH) Configuration or Radio Resource Control (RRC) Release messages, the indication for PDCP counter synchronization is sent to the UE.

25. The network node of claim 21, wherein the instructions, when executed by the at least one processor, further cause the network node to at least: Exchange Logical Channel Identifier (LCID) information associated with the multicast service with another network node among the plurality of network nodes.

26. The network node of claim 25, wherein the LCID information includes an indication of one or more Quality of Service Flow Identifiers (QFIs) mapped to an individual LCID associated with the multicast service.

27. A method performed by a network node, the method comprising: It is determined that Packet Data Convergence Protocol (PDCP) counter synchronization across multiple network nodes is applied to the multicast service, wherein the multiple network nodes include the network nodes; In response to the determination, an indication for PDCP counter synchronization across the multiple network nodes for the multicast service is sent to the user equipment (UE).

28. The method of claim 27, wherein sending the indication for PDCP counter synchronization comprises: Send an indication of a logical channel identifier (LCID) mapping between the network node and at least one other network node among the plurality of network nodes for the multicast service.

29. The method of claim 28, further comprising: For the multicast service, determine the LCID mapping between the network node and other network nodes.

30. The method of claim 27, wherein sending the indication for PDCP counter synchronization comprises: In at least one of the Multicast Control Channel (MCCH) Configuration or Radio Resource Control (RRC) Release messages, the indication for PDCP counter synchronization is sent to the UE.

31. The method of claim 27, further comprising: Exchange Logical Channel Identifier (LCID) information associated with the multicast service with another network node among the plurality of network nodes.

32. The method of claim 31, wherein the LCID information includes an indication of one or more Quality of Service Flow Identifiers (QFIs) mapped to an individual LCID associated with the multicast service.

Images