Enabling idle paging opportunities for inactivity

Abstract

A network node, such as a distributed unit (DU) and a central unit (CU) of a distributed base station, executes a method for managing a paging operation. An exemplary method for determining a paging occasion executed by the DU includes receiving an indication from the CU by the DU regarding whether a user equipment (UE) operating in an inactive state associated with a protocol for controlling radio resources supports determining a paging occasion in an inactive state using a parameter defined for determining a paging occasion in an idle state (1102), determining by the DU a paging occasion in an inactive state based on the indication (1104), and paging by the DU the UE operating in an inactive state at the paging occasion in the inactive state (1106).

Description

[Technical Field]

[0001] The present disclosure relates to wireless communications, and more particularly, to managing paging operations for inactive user equipment. [Background technology]

[0002] The description of the background art provided herein is intended to provide a general context for the present disclosure. The work of the inventors named herein, to the extent described in this Background section, and aspects of the present disclosure that may not be prior art at the time of filing, are not admitted, expressly or implicitly, as prior art to the present disclosure.

[0003] In telecommunications systems, the Packet Data Convergence Protocol (PDCP) sublayer of the radio protocol stack provides services such as transport, ciphering, and integrity protection of user plane data. For example, the PDCP layer defined for the Evolved Universal Terrestrial Radio Access (EUTRA) air interface (see 3GPP specification TS 36.323 ("3GPP" is a registered trademark)) and New Radio (NR) (see 3GPP specification TS 38.323) provides sequencing of protocol data units (PDUs) in the uplink direction (from a user device, also known as user equipment (UE), to a base station) and the downlink direction (from a base station to a UE). Furthermore, the PDCP sublayer provides services related to signaling radio bearers (SRBs) to the Radio Resource Control (RRC) sublayer. The PDCP sublayer also provides services related to Data Radio Bearers (DRBs) to protocol layers such as the Service Data Adaptation Protocol (SDAP) sublayer or the Internet Protocol (IP) layer, the Ethernet protocol layer, and the Internet Control Message Protocol (ICMP) layer. Generally, the UE and the base station can exchange RRC messages and Non-Access Stratum (NAS) messages using SRBs and can transfer data on the user plane using DRBs.

[0004] The RRC sublayer defines an RRC_IDLE state in which the UE does not have an active radio connection with a base station, an RRC_CONNECTED state in which the UE has an active radio connection with a base station, and an RRC_INACTIVE state to allow the UE to transition back to the RRC_CONNECTED state more quickly due to Radio Access Network (RAN) level base station coordination and RAN paging procedures.

[0005] In some scenarios, the UE operates in a state in which the radio resource control connection with the RAN is inactive (e.g., RRC_IDLE or RRC_INACTIVE state) and then transitions to the connected state. Generally, in the inactive state, the radio connection between the UE and the radio access network (RAN) is suspended. Later, when the UE is triggered to transmit data (e.g., by making a call, launching a browser) or receiving a paging message from a base station, the UE can transition to the connected state. To perform the transition, the UE can request the base station to establish a radio connection (e.g., by sending an RRC Setup Request message to the base station) or request the base station to resume a suspended radio connection (e.g., by sending an RRC Resume Request message to the base station), so that the base station can configure the UE to operate in the connected state.

[0006] In some cases, a UE in RRC_IDLE or RRC_INACTIVE state has only one or a few relatively small packets to send, or a base station has only one or a few relatively small packets to send to a UE operating in RRC_IDLE or RRC_INACTIVE state. In these cases, a UE in RRC_IDLE or RRC_INACTIVE state can perform early data communication without transitioning to RRC_CONNECTED state, for example, using techniques specified in sections 7.3a-7.3d of 3GPP specification 36.300 v16.4.0.

[0007] A UE in RRC_INACTIVE state monitors both CN-initiated and RAN-initiated paging. For example, 3GPP specification 38.300 v16.7.0 describes how a UE's paging occasions (POs) for CN-initiated and RAN-initiated paging are based on the same UE ID, resulting in overlapping POs for both CN-initiated and RAN-initiated paging. Thus, a UE in RRC_INACTIVE state may monitor both CN-initiated and RAN-initiated paging in overlapping POs.

[0008] To determine the PO, the UE uses the DRX cycle (i.e., parameter T) to determine the PO. However, the DRX cycle in the RRC_INACTIVE state may be different from the DRX cycle in the RRC_IDLE state. Therefore, a UE that calculates the PO using the DRX cycle calculates a different PO depending on whether the UE is operating in the RRC_INACTIVE state or the RRC_IDLE state.

[0009] To address this PO discrepancy, 3GPP has agreed on a new feature: a UE operating in RRC_INACTIVE state that supports this new feature will determine the PO using the same parameters (e.g., index i_s) that the UE uses to determine the PO in RRC_IDLE state.

[0010] To configure the UE to utilize this new feature, the base station (e.g., gNB or ng-eNB) may, for example, send an RRC release message to the UE to transition the UE from RRC_CONNECTED state to RRC_INACTIVE state. If both the UE and the base station support the new feature (i.e., calculating PO in the inactive state using the same index i_s as in the RRC_IDLE state), the base station may include a useIdlePO configuration in the RRC release message to enable the UE to use the new feature.

[0011] However, it is unclear how a distributed base station, including a CU and a DU, utilizes the useIdlePO configuration to determine paging occasions for UEs. For example, a DU responsible for paging UEs may not know whether a UE operating in an inactive state supports determining paging occasions using parameters normally used for the idle state. [Prior art documents] [Non-patent literature]

[0012] [Non-Patent Document 1] 3GPP specification TS 36.323 [Non-patent document 2] 3GPP specification TS 38.323 [Non-patent document 3] 3GPP Specification 36.300 v16.4.0, Sections 7.3a-7.3d [Non-patent document 4] 3GPP Specification 38.300 v16.7.0 [Non-patent document 5] 3GPP TS 38.331 [Non-patent document 6] 3GPP TS 36.331 [Non-Patent Document 7] 3GPP TS 38.473 [Non-patent document 8] 3GPP TS 37.473 [Non-Patent Document 9] 3GPP TS 38.413 [Non-Patent Document 10] 3GPP TS 38.423 Summary of the Invention [Means for solving the problem]

[0013] To address the challenges associated with implementing the above-identified functionality in a distributed base station, the CU may send a notification to the DU including an indication regarding whether a UE operating in an inactive state (e.g., RRC_INACTIVE) supports determining paging occasions for the inactive state using parameters used for determining paging occasions for the idle state. For example, the CU may include such an indication in a paging message that causes the DU to page the UE. After receiving the paging message, the DU can determine paging occasions for the UE operating in the inactive state based on the indication included in the paging message. Thus, if the UE supports determining paging occasions for the inactive state using parameters used for the idle state, the DU can calculate paging occasions for the inactive state using such idle state parameters. Otherwise, the DU can calculate paging occasions for the inactive state using parameters defined for determining paging occasions for the inactive state.

[0014] Additionally, in the paging message, the CU may also include a useIdlePO configuration that the DU may take into account when determining paging occasions for the UE.

[0015] One exemplary embodiment is a method for determining paging occasions performed by a central unit (CU) and distributed units (DUs) of a distributed base station, the method including: receiving, by the DU, an indication from the CU regarding whether a user equipment (UE) operating in an inactive state associated with a protocol for controlling radio resources supports determining an inactive state paging occasion using parameters defined for determining idle state paging occasions; determining, by the DU, an inactive state paging occasion based on the indication; and paging, by the DU, the UE operating in the inactive state at the inactive state paging occasion.

[0016] Another exemplary embodiment is a method for managing paging occasion determination, performed by a central unit (CU) and distributed units (DUs) of a distributed base station including the CU and the DUs, comprising: determining, by the CU, to page a user equipment (UE) operating in an inactive state associated with a protocol for controlling radio resources; and sending, by the CU to the DU, a paging message for causing the DU to page the UE, the paging message including an indication as to whether the UE operating in the inactive state supports determining paging occasions in the inactive state using parameters defined for determining paging occasions in the idle state.

[0017] A further exemplary embodiment is a network node configured to perform any one of the above methods. [Brief explanation of the drawings]

[0018] [Figure 1A]FIG. 1 is a block diagram of an example wireless communication system in which a core network (CN), a base station (BS), and user equipment (UE) manage paging for unicast services and multicast and / or broadcast services (MBS), in accordance with various embodiments. [Figure 1B] 1B is a block diagram of an exemplary base station (BS) including a central unit (CU) and a distributed unit (DU) that may operate within the system of FIG. 1A. [Figure 2A] 1B is a block diagram of an example protocol stack by which the UE of FIG. 1A communicates with a base station. [Figure 2B] 1B is a block diagram of an example protocol stack by which the UE of FIG. 1A can communicate with the DU and CU of the base station. [Figure 3A] 1 illustrates an exemplary scenario in which a BS configures a UE operating in an inactive state to determine paging occasions using idle state parameters and pages the UE for transmission of unicast data. [Figure 3B] 1 illustrates an exemplary scenario in which a BS configures a UE operating in an inactive state to determine paging occasions using idle state parameters and pages the UE for transmission of multicast data. [Figure 3C] 1 illustrates an exemplary scenario in which a BS configures a UE operating in an inactive state to determine paging occasions using idle state parameters and pages the UE for transmission of unicast data, including RAN paging. [Figure 3D] 1 illustrates an exemplary scenario in which a BS configures a UE operating in an inactive state to determine paging occasions using idle state parameters and pages the UE for transmission of multicast data, including RAN paging. [Figure 4A]1 illustrates an example scenario in which a UE performs a RAN notification area (RNA) update, transitions from a previous serving BS to a new BS, and the new BS transitions the UE back to an inactive state after UE context relocation. [Figure 4B] 1 illustrates an example scenario in which a UE performs an RNA update, transitions from a previous serving BS to a new BS, and the previous serving BS transitions the UE back to an inactive state without UE context relocation. [Figure 4C] 1 illustrates an exemplary scenario in which a UE performs an RNA update, transitions from a previous serving BS to a new BS, and the new BS transitions the UE to a connected state after the UE context is relocated. [Figure 5A] 10 is a flow diagram of an example method for transitioning a UE to an inactive state following an RNA update and configuring the UE to use the useIdlePO configuration after the RNA update. [Figure 5B] 10 is a flow diagram of an example method for transitioning a UE to an inactive state following an RNA update and configuring the UE to retain the useIdlePO configuration after the RNA update. [Figure 5C] 10 is a flow diagram of an example method for transitioning a UE to an inactive state following an RNA update and causing the UE to release the useIdlePO configuration after an RNA update. [Figure 5D] 10 is a flow diagram of an example method for transitioning a UE to an inactive state following an RNA update and causing the UE to release a useIdlePO configuration by sending a specific indication to the UE after the RNA update. [Figure 5E] 10 is a flow diagram of an example method for transitioning a UE to an inactive state following an RNA update and configuring the UE to use a useIdlePO configuration after the RNA update based on the capabilities of the UE. [Figure 6] 10 is a flow diagram of an example method for determining whether to transition a UE to an inactive state or a connected state after an RNA update based on a received useIdlePO configuration for the UE. [Figure 7] 10 is a flow diagram of an example method for determining whether to include a full configuration indication when transitioning a UE back to an inactive state after an RNA update. [Figure 8] 10 is a flow diagram of an example method for determining a paging occasion based on a configuration for a UE. [Figure 9] 1 is a flow diagram of an example method for determining state transitions and paging occasions for a UE based on a configuration for the UE. [Figure 10] 10 is a flow diagram of an example method for transitioning a UE to an inactive state following an RNA update and determining whether to configure the UE to use the useIdlePO configuration based on neighboring node capabilities. [Figure 11] 10 is a flow diagram of an example method for determining paging occasions that may be implemented in a DU. [Figure 12] 10 is a flow diagram of an example method for managing paging occasion determination that may be implemented in a CU. DETAILED DESCRIPTION OF THE INVENTION

[0019] Generally, one or more nodes of a wireless communication system (e.g., a CN, a base station, a RAN node, a CU, and / or a DU) implement the techniques of this disclosure to manage paging of UEs for multicast and / or broadcast services (MBS), and in some scenarios in coordination with managing paging of UEs for unicast services.

[0020] 1A illustrates an example wireless communication system 100 in which techniques for managing paging for unicast and multicast and / or broadcast service (MBS) information may be implemented. The wireless communication system 100 includes user equipment (UE) 102A, 102B, 102C, and 102D (UE 102 may refer to UE 102A, 102B, 102C, and / or 102D) and base stations 104, 106 of a radio access network (RAN) 105 connected to a core network (CN) 110. In other implementations or scenarios, the wireless communication system 100 may instead include more or fewer UEs and / or more or fewer base stations than shown in FIG. 1A. The base stations 104, 106 may be any suitable type or types of base stations, such as, for example, evolved Node Bs (eNBs), next generation eNBs (ng-eNBs), or 5G Node Bs (gNBs). As a more detailed example, the base station 104 may be an eNB or a gNB, and the base station 106 may be a gNB.

[0021] The base station 104 supports a cell 124, and the base station 106 supports a cell 126. The cell 124 partially overlaps with the cell 126, such that the UE 102A can be within range to communicate with the base station 106 (or within range to detect or measure a signal from the base station 106) while simultaneously being within range to communicate with the base station 104. The overlap may enable, for example, the UE 102A to handover between cells (e.g., from the cell 124 to the cell 126) or between base stations (e.g., from the base station 104 to the base station 106) before the UE 102A experiences a radio link failure. Furthermore, this overlap enables various dual connectivity (DC) scenarios. For example, the UE 102A can communicate DC with the base station 104 (acting as a master node (MN)) and the base station 106 (acting as a secondary node (SN)). When the UE 102A is in DC with the base station 104 and the base station 106, the base station 104 operates as a master eNB (MeNB), a master ng-eNB (Mng-eNB), or a master gNB (MgNB), and the base station 106 operates as a secondary gNB (SgNB) or a secondary ng-eNB (Sng-eNB).

[0022] During non-MBS (unicast) operation, the UE 102A may use radio bearers (e.g., DRBs or SRBs) terminated at the MN (e.g., base station 104) or SN (e.g., base station 106) at different times. For example, after a handover to the base station 106 or a change of SN, the UE 102A may use radio bearers (e.g., DRBs or SRBs) terminated at the base station 106. The UE 102A may apply one or more security keys when communicating on radio bearers in the uplink (UE 102A to base station) and / or downlink (base station to UE 102A) directions. During non-MBS operation, the UE 102A transmits data to a base station via radio bearers on (i.e., within) the uplink (UL) bandwidth part (BWP) of the cell and / or receives data from a base station via radio bearers on the downlink (DL) BWP of the cell. The UL BWP may be an initial UL BWP or a dedicated UL BWP, and the DL BWP may be an initial DL BWP or a dedicated DL BWP. The UE 102A may receive paging, system information, a public warning message, or a random access response on the DL BWP. During this non-MBS operation, the UE 102A may be in a connected state. Alternatively, if the UE 102A supports small data transmission in the idle or inactive state, the UE 102A may be in an idle or inactive state.

[0023] During MBS operation, the UE 102A may use an MBS radio bearer (MRB) terminated at the MN (e.g., base station 104) or SN (e.g., base station 106) at different times. For example, after a handover or SN change, the UE 102A may use an MRB terminated at the base station 106, which may be operating as an MN or SN. In some scenarios, the base station (e.g., MN or SN) may transmit MBS data to the UE 102A via the MRB on unicast radio resources (i.e., radio resources dedicated to the UE 102A). In other scenarios, the base station (e.g., MN or SN) may transmit MBS data from the base station to the UE 102A via the MRB on multicast radio resources (i.e., radio resources common to the UE 102A and one or more other UEs) or on a cell's DL BWP. The DL BWP may be an initial DL BWP, a dedicated DL BWP, or an MBS DL BWP (i.e., a DL BWP specific to the MBS or not for unicast).

[0024] The base station 104 includes processing hardware 130, which may include one or more general-purpose processors (e.g., central processing units (CPUs)), computer-readable memory that stores machine-readable instructions executable on the one or more general-purpose processors, and / or special-purpose processing units. The processing hardware 130 of the example implementation of FIG. 1A includes an MBS controller 132 configured to manage or control transmission of MBS information received from the CN 110 or edge server. For example, the MBS controller 132 may be configured to support radio resource control (RRC) configurations, procedures and messaging related to MBS procedures, and / or other operations related to those configurations and / or procedures, as described below. The processing hardware 130 may also include a non-MBS controller 134 configured to manage or control one or more RRC configurations and / or RRC procedures when the base station 104 operates as an MN or SN during non-MBS operation. Additionally, the processing hardware 130 of the exemplary implementation includes one or more paging controllers 136 configured to manage MBS and non-MBS (e.g., unicast services) paging operations with one or more UEs operating in the RRC_INACTIVE or RRC_IDLE states.

[0025] The base station 106 includes processing hardware 140, which may include one or more general-purpose processors (e.g., CPUs), computer-readable memory that stores machine-readable instructions executable on the general-purpose processors, and / or special-purpose processing units. The processing hardware 140 in the example implementation of FIG. 1A includes an MBS controller 142, a non-MBS controller 144, and one or more paging controllers 146, which may be similar to the controllers 132, 134, and 136, respectively, of the base station 130. Although not shown in FIG. 1A, the RAN 105 may include additional base stations with processing hardware similar to the processing hardware 130 of the base station 104 and / or the processing hardware 140 of the base station 106. The base stations 104, 106 also include hardware for communicating wirelessly with other devices, including the UE 102A, such as antennas, transceivers, emitters, and / or receivers.

[0026] The UE 102A includes processing hardware 150, which may include one or more general-purpose processors (e.g., CPUs), computer-readable memory that stores machine-readable instructions executable on the general-purpose processors, and / or special-purpose processing units. The processing hardware 150 of the example implementation of FIG. 1A includes an MBS controller 152 configured to manage or control reception of MBS information. For example, the UE's MBS controller 152 may be configured to support RRC configuration, procedures and messaging related to MBS procedures, and / or other operations related to those configurations and / or procedures, as described below. The processing hardware 150 may also include a non-MBS controller 154 configured to manage or control one or more RRC configurations and / or RRC procedures according to any of the implementations described below when the UE 102A communicates with the MN and / or SN during non-MBS operation. Additionally, the processing hardware 150 of the exemplary implementation includes one or more paging controllers 156 configured to manage MBS and non-MBS (e.g., unicast services) paging operations with one or more base stations (e.g., BSs 104, 106) when the UE 102A is operating in an RRC_INACTIVE or RRC_IDLE state. Although not shown in FIG. 1A , the UEs 102B, 102C, 102D may include processing hardware similar to the processing hardware 150 of the UE 102A. The UE 102A also includes hardware for communicating wirelessly with other devices, including the RAN 105, such as antennas, transceivers, emitters, and / or receivers.

[0027] The CN 110 may be an Evolved Packet Core (EPC) 111 or a 5th Generation Core (5GC) 160, both of which are shown in FIG. 1A . The base station 104 may be an eNB supporting an S1 interface for communicating with the EPC 111, an ng-eNB supporting an NG interface for communicating with the 5GC 160, or a gNB supporting an NR air interface and an NG interface for communicating with the 5GC 160. The base station 106 may be a EUTRA-NR DC (EN-DC) gNB (en-gNB) with an S1 interface to the EPC 111, an en-gNB that does not connect to the EPC 111, a gNB supporting an NR air interface and an NG interface to the 5GC 160, or an ng-eNB supporting an EUTRA air interface and an NG interface to the 5GC 160. The base stations 104 and 106 may support an X2 or Xn interface to exchange messages directly with each other during the scenarios described below.

[0028] Among other components, the EPC 111 may include a Serving Gateway (SGW) 112, a Mobility Management Entity (MME) 114, and a Packet Data Network Gateway (PGW) 116. The SGW 112 is generally configured to forward user plane packets related to voice calls, video calls, Internet traffic, etc., and the MME 114 is configured to manage authentication, registration, paging, and other related functions. The PGW 116 provides connectivity from a UE (e.g., UE 102A or 102B) to one or more external packet data networks, e.g., an Internet network and / or an Internet Protocol (IP) Multimedia Subsystem (IMS) network. The 5GC 160 includes a User Plane Function (UPF) 162, and an Access and Mobility Management (AMF) 164 and / or a Session Management Function (SMF) 166. The UPF 162 is generally configured to forward user plane packets related to voice calls, video calls, Internet traffic, etc., the AMF 164 is generally configured to manage authentication, registration, paging, and other related functions, and the SMF 166 is generally configured to manage PDU sessions.

[0029] The UPF 162, the AMF 164, and / or the SMF 166 may be configured to support MBS. For example, the SMF 166 may be configured to manage or control the forwarding of MBS, configure the UPF 162 and / or the RAN 105 for MBS flows, and / or manage or configure one or more MBS or PDU sessions for MBS for a UE (e.g., UE 102A or 102B). The UPF 162 is configured to forward MBS data packets related to voice, video, Internet traffic, etc. to the RAN 105. The UPF 162 and / or the SMF 166 may be configured for both non-MBS unicast services and MBS, or for MBS only, as indicated by the prefix “(MB-)” shown in FIG. 1A .

[0030] Generally, the wireless communication system 100 may include any suitable number of base stations supporting NR and / or EUTRA cells. More specifically, the EPC 111 or 5GC 160 may be connected to any suitable number of base stations supporting NR and / or EUTRA cells. While the examples below refer specifically to particular CN types (EPC, 5GC) and RAT types (5G NR and EUTRA), generally, the techniques described herein may also be applied to other suitable radio access and / or core network technologies, such as, for example, sixth-generation (6G) radio access and / or 6G core networks or 5G NR-6G DC.

[0031] In different configurations or scenarios of the wireless communication system 100, the base station 104 may operate as an MeNB, an Mng-eNB, or an MgNB, and the base station 106 may operate as an SgNB or an Sng-eNB. The UE 102A may communicate with the base station 104 and the base station 106 via the same radio access technology (RAT), such as EUTRA or NR, or via different RATs.

[0032] When the base station 104 is an MeNB and the base station 106 is an SgNB, the UE 102A may be in EN-DC with the MeNB 104 and the SgNB 106. When the base station 104 is an Mng-eNB and the base station 106 is an SgNB, the UE 102A may be in Next Generation (NG) EUTRA-NR DC (NGEN-DC) with the Mng-eNB 104 and the SgNB 106. When the base station 104 is an MgNB and the base station 106 is an SgNB, the UE 102A may be in NR-NR DC (NR-DC) with the MgNB 104 and the SgNB 106. When the base station 104 is an MgNB and the base station 106 is an Sng-eNB, the UE 102A may be in NR-EUTRA DC (NE-DC) with the MgNB 104 and the Sng-eNB 106.

[0033] 1B shows an exemplary distributed implementation of a base station 170, which may be base station 104 or 106. In this implementation, base station 170 includes a central unit (CU) 172 and one or more distributed units (DUs) 174. CU 172 includes processing hardware, such as one or more general-purpose processors (e.g., CPUs) and computer-readable memory that stores machine-readable instructions executable on the general-purpose processor(s), and / or special-purpose processing units. For example, CU 172 may include some or all of processing hardware 130 or 140 of FIG. 1A.

[0034] Each of the DUs 174 also includes processing hardware, which may include one or more general-purpose processors (e.g., CPUs), computer-readable memory that stores machine-readable instructions executable on the one or more general-purpose processors, and / or special-purpose processing units. For example, the processing hardware may include a medium access control (MAC) controller configured to manage or control one or more MAC operations or procedures (e.g., random access procedures), and a radio link control (RLC) controller configured to manage or control one or more RLC operations or procedures when the base station (e.g., base station 104) operates as an MN or SN. The processing hardware may also include a physical (PHY) layer controller configured to manage or control one or more PHY layer operations or procedures.

[0035] In some implementations, the CU 172 may include one or more logical nodes (CU-CP 172A) that host the control plane portion of the Packet Data Convergence Protocol (PDCP) protocol of the CU 172 and / or the Radio Resource Control (RRC) protocol of the CU 172. The CU 172 may also include one or more logical nodes (CU-UP 172B) that host the user plane portion of the PDCP protocol of the CU 172 and / or the Service Data Adaptation Protocol (SDAP) protocol. The CU-CP 172A may transmit non-MBS control information and MBS control information, and the CU-UP 172B may transmit non-MBS data packets and MBS data packets, as described herein.

[0036] The CU-CP 172A may be connected to multiple CU-UPs 172B through an E1 interface. The CU-CP 172A selects an appropriate CU-UP 172B for a requested service for the UE 102A. In some implementations, a single CU-UP 172B may be connected to multiple CU-CPs 172A through an E1 interface. The CU-CP 172A may be connected to one or more DUs 174 through an F1-C interface. The CU-UP 172B may be connected to one or more DUs 174 through an F1-U interface under the control of the same CU-CP 172A. In some implementations, one DU 174 may be connected to multiple CU-UPs 172B under the control of the same CU-CP 172A. In such implementations, the connection between the CU-UP 172B and the DU 174 is established by the CU-CP 172A using a bearer context management function.

[0037] 2A illustrates a simplified example protocol stack 200 by which a UE 102 (e.g., a UE 102A, 102B, 102C, or 102D) may communicate with an eNB / ng-eNB 201A or a gNB 201B (e.g., one or more of a base station 104, 106). In the example protocol stack 200, a EUTRA PHY sublayer 202A provides transport channels to a EUTRA MAC sublayer 204A, which in turn provides logical channels to a EUTRA RLC sublayer 206A. Furthermore, the EUTRA RLC sublayer 206A provides RLC channels to a EUTRA PDCP sublayer 208 and possibly an NR PDCP sublayer 210. Similarly, the NR PHY 202B provides transport channels to the NR MAC sublayer 204B, which in turn provides logical channels to the NR RLC sublayer 206B. Furthermore, the NR RLC sublayer 206B provides RLC channels to the NR PDCP sublayer 210. In some implementations, the UE 102A supports both the EUTRA stack and the NR stack as shown in FIG. 2A to support handover between EUTRA and NR base stations and / or to support data communication over the EUTRA and NR interfaces. Furthermore, as shown in FIG. 2A, the UE 102A can support the layering of the NR PDCP 210 on the EUTRA RLC 206A and the SDAP sublayer 212 on the NR PDCP sublayer 210. The sublayers are also referred to herein simply as "layers."

[0038] The EUTRA PDCP sublayer 208 and the NR PDCP sublayer 210 receive packets that may be referred to as service data units (SDUs) (e.g., from an IP layer layered directly or indirectly on the PDCP layer 208 or 210) and output packets that may be referred to as protocol data units (PDUs) (e.g., to the RLC layer 206A or 206B). For simplicity, this disclosure refers to both SDUs and PDUs as "packets" unless the distinction between SDUs and PDUs is important. Packets can be MBS packets or non-MBS packets. MBS packets may include, for example, application content for MBS services (e.g., IPv4 / IPv6 multicast distribution, IPTV, wireless software distribution, group communications, IoT applications, V2X applications, and / or emergency messages related to public safety). As another example, MBS packets may include application control information for MBS services.

[0039] In the control plane, the EUTRA PDCP sublayer 208 and the NR PDCP sublayer 210 can provide, for example, SRBs for exchanging RRC messages or non-access stratum (NAS) messages. In the user plane, the EUTRA PDCP sublayer 208 and the NR PDCP sublayer 210 can provide DRBs for supporting the exchange of data. The data exchanged over the NR PDCP sublayer 210 can be, for example, SDAP PDUs, IP packets, or Ethernet packets.

[0040] In a scenario where the UE 102A or 102B operates in an EN-DC with the base station 104 operating as an MeNB and the base station 106 operating as an SgNB, the wireless communication system 100 can provide the UE 102A or 102B with an MN-terminated bearer using the EUTRA PDCP sublayer 208 or an MN-terminated bearer using the NR PDCP sublayer 210. In various scenarios, the wireless communication system 100 can also provide the UE 102A or 102B with an SN-terminated bearer using only the NR PDCP sublayer 210. The MN-terminated bearer may be an MCG bearer, a split bearer, or an MN-terminated SCG bearer. The SN-terminated bearer may be an SCG bearer, a split bearer, or an SN-terminated MCG bearer. The MN-terminated bearer may be an SRB (e.g., SRB1 or SRB2) or a DRB. The SN terminated bearer may be an SRB or a DRB.

[0041] In some implementations, a base station (e.g., base stations 104, 106) broadcasts MBS data packets over one or more MBS radio bearers (MRBs), and the UE 102A receives the MBS data packets over the MRBs. The base station may include a configuration for the MRBs in multicast configuration parameters (also referred to as MBS configuration parameters), described below. In some implementations, the base station broadcasts the MBS data packets over the RLC sublayer 206, the MAC sublayer 204, and the PHY sublayer 202, and the UE 102A correspondingly receives the MBS data packets using the PHY sublayer 202, the MAC sublayer 204, and the RLC sublayer 206. In such implementations, the base station and the UE 102A may not use the PDCP sublayer 208 and the SDAP sublayer 212 to communicate the MBS data packets. In another implementation, the base station transmits the MBS data packets via the PDCP sublayer 208, the RLC sublayer 206, the MAC sublayer 204, and the PHY sublayer 202, and correspondingly, the UE 102A receives the MBS data packets using the PHY sublayer 202, the MAC sublayer 204, the RLC sublayer 206, and the PDCP sublayer 208. In such an implementation, the base station and the UE 102A may not use the SDAP sublayer 212 to communicate the MBS data packets. In yet another implementation, the base station transmits the MBS data packets via the SDAP sublayer 212, the PDCP sublayer 208, the RLC sublayer 206, the MAC sublayer 204, and the PHY sublayer 202, and correspondingly, the UE 102A receives the MBS data packets using the PHY sublayer 202, the MAC sublayer 204, the RLC sublayer 206, the PDCP sublayer 208, and the SDAP sublayer 212.

[0042] 2B illustrates a simplified example protocol stack 250 by which a UE 102 (e.g., UE 102A, 102B, 102C, or 102D) can communicate with a DU (e.g., DU 174) and a CU (e.g., CU 172). The radio protocol stack 200 is functionally divided as illustrated by the radio protocol stack 250 of FIG. 2B. The CU of either base station 104 or 106 can retain all control and upper layer functions (e.g., RRC 214, SDAP 212, NR PDCP 210), while lower layer operations (e.g., NR RLC 206B, NR MAC 204B, and NR PHY 202B) are delegated to the DU. To support a connection to 5GC, the NR PDCP 210 provides an SRB to the RRC 214, and the NR PDCP 210 provides a DRB to the SDAP 212 and an SRB to the RRC 214.

[0043] Some example scenarios in which a UE and / or RAN perform methods for supporting paging occasion determination will now be described with reference to Figures 3A-3D and 4A-4C. Generally, similar events in Figures 3A-3D and 4A-4C are labeled with the same reference numbers, and differences are described below where appropriate. In the following description, the connected, inactive, and idle states may be, for example, the RRC_CONNECTED, RRC_INACTIVE, and RRC_IDLE states, respectively.

[0044] 3A, in a scenario 300A, a base station (BS) 104 including a CU 172 and a DU 174 and / or other DUs (not shown in FIG. 3A) sends an RRC release message to the UE 102A to transition the UE 102A to an inactive state, and then pages the UE 102A according to a paging occasion (PO) determined by the base station 104. The UE 102A monitors for paging at the determined PO based on the useIdlePO configuration received in the RRC release message.

[0045] In scenario 300A, initially, UE 102A operates in either a connected state according to a configuration or an inactive state according to a suspend configuration (302). CU 172 sends 304 to DU 174 an RRC release message (e.g., an RRCRelease message defined in 3GPP TS 38.331 or an RRCConnectionRelease message defined in 3GPP TS 36.331) that includes an RRC release message, where the RRC release message further includes a suspend configuration (e.g., suspendConfig) and / or a useIdlePO configuration. DU 174 then sends 306 the RRC release message to UE 102A. In some implementations, if included in the RRC release message, the useIdlePO configuration is placed within a container IE (e.g., suspendConfig or cellReselectionPriorities) of the RRC release message. The useIdlePO configuration enables the UE 102A to calculate paging occasions using parameters for the idle state while the UE is operating in an inactive state. In other implementations, when included in an RRC release message, the useIdlePO configuration is not placed in a container IE. In response to the CU-to-DU interface message, in some implementations, the DU 174 sends a DU-to-CU interface message to the CU 172. In some implementations, the CU-to-DU interface message that the CU sends (304) can be a UE CONTEXT RELEASE COMMAND message or a DL RRC MESSAGE TRANSFER message, and the DU-to-CU interface message can be a UE CONTEXT RELEASE COMPLETE message, as defined in 3GPP TS 38.473 or 37.473.

[0046] Events 302, 304, and 306 may be collectively referred to as a connection release with suspendConfig procedure 362. The UE then transitions 308 to an inactive state.

[0047] In some scenarios and implementations, the CU 172 receives data for the UE 102A (e.g., unicast service data such as MBS data, Internet Protocol (IP) packets, Ethernet packets, etc.) from the CN 110 (309). In response to receiving the data (309), the CU 172 transmits a CU-to-DU interface message including a useIdlePO configuration and / or a UE radio capability for paging IE for the UE 102A (316). The UE radio capability for paging IE may include an inactiveStatePODetermination indication (inactiveStatePO). When included, the inactiveStatePODetermination indication indicates that the UE 102A operating in the inactive state supports using parameters for the idle state to determine paging occasions for the inactive state. For example, inactiveStatePODetermination may have a value “supported.” The CU 172 may further include a UE-specific DRX cycle configuration for the UE 102A in the CU-to-DU interface message. In some implementations, the CU 172 receives an NGAP message including a UE radio capability IE for paging from the CN 110, for example, while the UE 102A is operating in a connected or inactive state (302). For example, the NGAP message can be an INITIAL CONTEXT SETUP REQUEST message, a UE CONTEXT MODIFICATION REQUEST message, a HANDOVER REQUEST message, or a PATH SWITCH REQUEST ACKNOWLEDGE message. In other implementations, the CU 172 may receive an XnAP message including a UE radio capability IE for paging from the BS 106 or a CU of the BS 106, for example, while the UE 102A is operating in a connected or inactive state (302).For example, the XnAP message can be a HANDOVER REQUEST message, a RETRIEVE UE CONTEXT RESPONSE message, or a RAN PAGING message. In yet another implementation, the CU 172 can generate a UE radio capability IE for paging from the UE Capability IE (e.g., a UE-NR-Capability IE or a UE-EUTRA-Capability IE) of the UE 102A, for example, while the UE 102A is operating in a connected or inactive state (302). For example, the CU 172 can receive a UECapabilityInformation message including the UE capability IE from the UE 102A. In another example, the CU 172 can receive the UE capability IE in an XnAP message from the base station 106. In yet another example, the CU 172 can receive the UE capability IE in an NGAP message from the CN 110.

[0048] In some implementations, the UE radio capability IE for paging may be a UERadioPagingInformation IE defined in TS 38.331 or TS 36.331. In some implementations, the UE radio capability IE for paging includes information of supported NR bands (e.g., supportedBandListNRforPaging IE), an indication of supporting wake-up signaling, an indication of supporting paging early indication, and / or information of supported downlink scheduling offsets for one or more types and one or more frequency ranges. For example, the downlink scheduling offset information includes dl-SchedulingOffset-PDSCH-TypeA-FDD-FR1, dl-SchedulingOffset-PDSCH-TypeA-TDD-FR1, dl-SchedulingOffset-PDSCH-TypeA-TDD-FR2, dl-SchedulingOffset-PDSCH-TypeB-FDD-FR1, dl-SchedulingOffset-PDSCH-TypeB-TDD-FR1, and / or dl-SchedulingOffset-PDSCH-TypeB-TDD-FR2.

[0049] Alternatively, instead of receiving 309 data, CU 172 may receive 310 a CN-to-BS interface message from CN 110 that includes a UE radio capabilities IE for paging. In some implementations, the CN-to-BS interface message is an NGAP PAGING message defined in 3GPP TS 38.413. In such a case, CU 172 may include the received UE radio capabilities IE for paging in the CU-to-DU interface message that CU 172 sends 316.

[0050] In some implementations, the CU-to-DU interface message sent (316) by the CU 172 is an F1AP PAGING message defined in 3GPP TS 38.473. In other implementations, the CU-to-DU interface message sent (316) by the CU 172 is a W1AP PAGING message defined in 3GPP TS 37.473.

[0051] After receiving the CU-to-DU interface message (316), the DU 174 determines a paging occasion for the UE 102A based on the received UE radio capability IE for paging, the useIdlePO configuration, and / or the UE-specific DRX cycle configuration (318). In some implementations, the DU 174 determines a (first) paging occasion for the UE 102A in accordance with parameters used for the idle state in response to receiving the useIdlePO configuration. The DU 174 transmits one or more paging messages (e.g., Paging messages defined in 3GPP TS 38.331 or 36.331) to the UE 102A within / on the (first) paging occasion (320). In such a case, the UE 102A determines its paging occasion in accordance with parameters used for the idle state in response to receiving the useIdlePO configuration.

[0052] In some implementations, if there is no useIdlePO configuration, the DU 174 calculates a (second) paging occasion for the UE 102A using parameters for the inactive state. In such a case, the DU 174 transmits one or more paging messages (e.g., Paging messages defined in 3GPP TS 38.331 or 36.331) to the UE 102A within / on the (second) paging occasion (320). In response to or because there is no useIdlePO configuration, the UE 102A also determines its paging occasion according to the parameters used for the inactive state.

[0053] Events 316 , 318 , and 320 may be collectively referred to as a session activation notification procedure 380 .

[0054] In response to the paging message that the UE 102A receives (320), the UE 102A activates (322) data reception. In response to the activation of data reception (322) or the reception of the paging message (320), the UE 102A can perform (330) a random access procedure and / or an RRC resumption procedure with the DU 174. In the RRC resumption procedure, the UE 102A sends (332) an RRC resumption request message (e.g., an RRCResumeRequest message or an RRCConnectionResumeRequest message) to the DU 174. The DU 174 sends (334) an INITIAL UL RRC MESSAGE TRANSFER message containing the RRC resumption request message to the CU 172. The CU 172 sends (336) a UE CONTEXT SETUP REQUEST message to the DU 174. In response, the DU 174 sends a UE CONTEXT SETUP RESPONSE message to the CU 172 (338). The CU 172 generates an RRC resumption message (e.g., an RRCResume message or an RRCConnectionResume message) and sends a DL RRC MESSAGE TRANSFER message containing the RRC resumption message to the DU 174 (340). The DU 174 sends the RRC resumption message to the UE 102A (350). In response to receiving the RRC resumption message, the UE 102A transitions to a resumed state (345) and sends an RRC resumption complete message (e.g., an RRCResumeComplete message or an RRCConnectionResumeComplete message) to the DU 174 (352). The DU 174 forwards the RRC resumption complete message to the CU 172 in a UL RRC MESSAGE TRANSFER message (353).

[0055] Events 330 , 332 , 334 , 336 , 338 , 340 , 350 , 345 , 352 , and 353 may be collectively referred to as a connection resumption procedure 382 .

[0056] When receiving data (310), the CU 172 transmits the data to the DU 174 (311), which in turn transmits the data to the UE 102A (312). The CN 110 transmits (324) the (subsequent) data to the CU 172, which in turn transmits (326) the (subsequent) data to the DU 174. The DU 174 then transmits (328) the (subsequent) data to the UE 102A. Events 324, 326, and 328 may be collectively referred to as data transmission 392.

[0057] In some scenarios and implementations, the DU 174 may include a small data transmission indication in the paging message. In such cases, the CU 172 refrains from sending an RRC resume message in response to or after receiving the RRC resume request message, and events 340, 350, and 345 may be omitted. Thus, the UE 102A remains in an inactive state and receives data from the DU 174 (312). When the CN 110 transmits subsequent data (324), the UE 102A, operating in an inactive state, receives subsequent data from the DU 174 (328).

[0058] In some implementations, the UE 102A and the DU 174 may determine the PO and paging frame (PF) according to the following equations and parameters:

[0059] The SFN of a PF is determined by (SFN + PF_offset) mod T = (T div N)*(UE_ID mod N).

[0060] The index (i_s) indicating the index of the PO is determined by i_s = floor(UE_ID / N) mod Ns.

[0061] T is the DRX cycle configuration of the UE 102A (T is determined by the shortest value between the UE-specific DRX value in the UE-specific DRX configuration, if configured by RRC and / or higher layers, and the default DRX value broadcast in the system information. In idle state, if no UE-specific DRX cycle configuration is configured by higher layers, the default value applies). N is the total number of paging frames in T (configured by nAndPagingFrameOffset with values ​​T, T / 2, T / 4, T / 8, or T / 16).

[0062] 3B, scenario 300B is similar to scenario 300A. However, in scenario 300B, CN 110 requests BS 104 to page UEs that have previously indicated interest in a particular multicast and / or broadcast service (MBS), and CU 172 receives MBS data or CN-to-BS interface messages for the MBS from CN 110 instead of unicast data. The differences between the scenario of FIG. 3B and the scenario of FIG. 3A are described below.

[0063] In scenario 300B, the UE 102 (e.g., UE 102A, UE 102B, UE 102C, and / or UE 102D), the DU 174, and the CU 172 first perform a connection release procedure using suspendConfig (362). The UE 102 transitions to an inactive state (308). The CN 110, the BS 104, and the UE 102 then perform an MBS session activation procedure 373 in which the BS 104 (and particularly the DU 174 of the BS 104) pages the UE 102A (and possibly other involved UEs operating in an idle or inactive state, e.g., UE 102B, 102C, and / or 102D) for MBS services, and the UE 102 activates reception of MBS content data (323).

[0064] After the UE 102 transitions to the inactive state (308), the CU 172 may receive a CN-to-BS interface message from the CN 110 (314), the message being a single (e.g., only one) message containing multicast or group paging instructions for a set of one or more (but typically multiple or a group) UEs that are interested in the MBS service (e.g., UEs 102A, 102B, 102C, and / or 102D), are operating in an idle or inactive state, and should be paged for the MBS service. Such a message sent at event 314 is generally referred to herein as a “group paging message” or a “multicast paging message.” The CN to BS interface message sent by the CN 110 (314) may include an MBS Session ID and / or an indication of the identity of UEs that have previously indicated interest in the MBS service, including the UE 102, and / or a UE Radio Capability IE for each paging, which may each include an inactiveStatePODetermination indication for the UEs, including the UE 102, and / or a UE-specific DRX for each of the UEs, including the UE 102. In some implementations, the CN to BS interface message is a MULTICAST GROUP PAGING message defined for 3GPP TS 38.413.

[0065] Alternatively, after the UE 102 transitions to the inactive state (308), the CU 172 may receive (313) MBS data (e.g., IP packets or Ethernet packets) from the CN 110, similar to event 309. In such a case, the CU 172 may obtain the useIdlePO configuration, the UE radio capability for paging IE, and / or the UE-specific DRX cycle configuration for the UE 102, as described above.

[0066] In response to receiving 313 the MBS data or receiving 314 the CN-to-BS message, CU 172 sends 315 a CU-to-DU interface message including the MBS session ID and / or an indication of the identities of UEs that previously indicated interest in the MBS service and / or the UE radio capability IE for each paging, which may each include an inactiveStatePODetermination indication for UEs including UE 102, and / or the respective useIdlePO configurations for UEs including UE 102, and / or the respective UE-specific DRX for UEs including UE 102. In some implementations, the CU-to-DU interface message is also a multicast paging message and may be an F1AP PAGING message or the new F1AP MULTICAST GROUP PAGING message defined for 3GPP TS 38.473.

[0067] In some circumstances (and as described elsewhere herein with respect to other exemplary scenarios), such as when at least a portion of the UE radio capability IE for paging was previously stored in the CU 172 and / or the DU 174, the UE radio capability IE for paging may be excluded from the multicast paging message sent by the CN 110 at event 314 or by the CU 172 at event 315.

[0068] After receiving (315) the CU-to-DU interface message, the DU 174 determines (319) paging occasions for UEs, including the UE 102, based on the received UE radio capability IE, the respective useIdlePO configurations, and / or the respective UE-specific DRX for each paging. In some implementations, the DU 174 determines (321) a (first) paging occasion for the UEs, including the UE 102, according to parameters used for the idle state in response to receiving the respective useIdlePO configurations for the UEs, including the UE 102. The DU 174 transmits (321) one or more paging messages (e.g., Paging messages defined in 3GPP TS 38.331 or 36.331) including an MBS session ID to the UEs, including the UE 102, within / on the (first) paging occasion. In such a case, the UE 102 determines its paging occasion according to parameters used for the idle state in response to receiving the useIdlePO configuration.

[0069] In some implementations, if there is no useIdlePO configuration for the UEs including the UE 102, the DU 174 uses parameters for the inactive state to calculate a (second) paging occasion for the UEs including the UE 102. In such a case, the DU 174 transmits (320) one or more paging messages (e.g., Paging messages defined in 3GPP TS 38.331 or 36.331) including the MBS session ID to the UEs including the UE 102 within / on the (second) paging occasion. In response to or because there is no useIdlePO configuration, the UE 102 also determines its paging occasion according to the parameters used for the inactive state.

[0070] Events 313 / 314, 315, 319, and 321 may collectively be referred to as a session activation notification procedure 373. Events 315, 319, and 321 may collectively be referred to as a RAN session activation notification procedure 381 for a CU-DU split base station, whereby UE 102 activates 323 MBS data reception.

[0071] The UE 102 performs a connection resumption procedure with the base station 104 (382). The CU 172 may transmit the MBS data to the DU 174 if the MBS data is received at event 313 (319), and the DU 174 transmits the MBS data to UEs, including the UE 102 (321). The CN 110 transmits the MBS data to the CU 172 (325), and the CU 172 transmits the MBS data to the DU 174 (327). Furthermore, the DU 174 transmits the MBS data to UEs, including the UE 102 (329). Events 325, 327, and 329 may be collectively referred to as MBS data transmission 393.

[0072] Turning to Figure 3C, in scenario 300C, the scenario includes an XnAP RAN paging procedure. Initially, UE 102A is within the cell coverage of BS 104, and BS 104, the previous serving base station, transitions UE 102A to the inactive state as described in scenarios 300A and 300B. Then, UE 102A moves from the cell coverage of BS 104 to the cell coverage of BS 106 while operating in the inactive state. The differences between the scenario of Figure 3C and the scenarios of Figures 3A and 3B are described below.

[0073] First, UE 102A performs a connection release procedure with BS 104 using suspendConfig (362), as described in scenario 300A. UE 102A transitions to an inactive state (308). UE 102A then enters the cell coverage of BS 106 and leaves the cell coverage of BS 104.

[0074] Similar to scenario 300A, CN 110 may send (309) data to BS 104 or may send (310) a CN-to-BS interface message including a UE radio capabilities for paging IE, which may include an inactiveStatePODetermination indication for UE 102A. BS 104 may perform session activation procedure 380 within its cell coverage as described in scenario 300A, but may not reach UE 102A because UE 102A leaves its cell coverage. BS 104 sends (364) a BS-to-BS interface message including a UE capabilities for paging IE, which may include an inactiveStatePODetermination indication for UE 102A, and / or a useIdlePO configuration and / or UE-specific DRX, to BS 106, which is one of the base stations within the configured RAN notification area. In some implementations, the BS to BS interface message is the RAN PAGING message defined in 3GPP TS 38.423.

[0075] If the BS 106 is an aggregated base station (i.e., no CU-DU split), the BS 106 determines a paging occasion based on the UE radio capability IE, the useIdlePO configuration, and / or the UE-specific DRX for the received paging for the UE 102A (338). In some implementations, the BS 106, in response to receiving the useIdlePO configuration, determines a (first) paging occasion for the UE 102A according to parameters used for the idle state. The BS 106 transmits one or more paging messages (e.g., Paging messages defined in 3GPP TS 38.331 or 36.331) to the UE 102A within / on the (first) paging occasion (390). In such a case, the UE 102A, in response to receiving the useIdlePO configuration, determines its paging occasion according to parameters used for the idle state.

[0076] In some implementations, in the absence of a useIdlePO configuration, the BS 106 calculates a (second) paging occasion for the UE 102A using parameters for the inactive state. In such a case, the BS 106 transmits one or more paging messages (e.g., Paging messages defined in 3GPP TS 38.331 or 36.331) to the UE 102A within / on the (second) paging occasion (390). In response to, or because of, the absence of a useIdlePO configuration, the UE 102A also determines its paging occasion according to the parameters used for the inactive state.

[0077] If the BS 106 has a CU-DU split architecture, the determination of the paging occasion and the transmission of the paging message are similar to event 380, which is the session activation notification procedure for the UE 102A and the CU / DU of the BS 106.

[0078] The UE 102A thereby activates data reception (322). The UE 102A may perform a random access procedure with the BS 106 (311). The UE 102A sends an RRC resume request message including the I-RNTI to the BS 106 (344). The BS 106 sends a RETRIEVE UE CONTEXT REQUEST message to the BS 104 by resolving the identity of the gNB included in the I-RNTI (346). In response, the BS 104 sends a RETRIEVE UE CONTEXT RESPONSE message including an RRC context container (e.g., a HandoverPreparationInformation message defined in 3GPP TS 38.331) that may include the UE's capabilities (e.g., the UE's radio capabilities for paging, which may include a ue-CapabilityRAT-List and / or an inactiveStatePODetermination indication) and / or a useIdlePO configuration (348). The BS 106 sends an RRC Resume message to the UE 102A (350). The UE 102A transitions to the Connected state (345). The UE sends an RRC Resume Complete message to the BS 106 (352). The BS 106 may send an Xn-U Address Indication message to the BS 104 for data transfer (354). The BS 106 sends a PATH SWITCH REQUEST message to the CN 110 (356). In response, the CN 110 sends a RETRIEVE UE CONTEXT REQUEST ACKNOWLEDGE message to the BS 106 (358). The BS 106 sends a UE CONTEXT RELEASE message to the BS 104 (360). Events 331, 344, 346, 348, 350, 345, 352, 354, 356, 358, and 360 may collectively be referred to as a connection resumption procedure with UE context retrieval 383. If received at event 310, BS 104 may forward data to BS 106 (323), and BS 106 transmits the data to UE 102A (324).CN 110 transmits the data to BS 106 (344), which transmits the data to UE 102A (345).

[0079] 3D, scenario 300D is similar to scenarios 300A, 300B, and 300C and includes MBS paging and UE context retrieval. The scenario also includes an XnAP RAN paging procedure when UE 102A and UE 102B move from the cell coverage of BS 104 to the cell coverage of BS 106, as described in scenarios 300A and 300B. The differences between the scenario of FIG. 3D and the scenarios of FIG. 3A, 3B, and 3C are described below.

[0080] Initially, UEs 102A, 102B, 102C, and 102D are within the cell coverage of BS 104. UEs 102C and 102D perform a connection release procedure with BS 104 using suspendConfig (362). UEs 102A and 102B also perform a connection release procedure with BS 104 using suspendConfig (362). UEs 102A, 102B, 102C, and 102D transition to an inactive state (308, 309). UEs 102A and 102B then leave the cell coverage of BS 104 and enter the cell coverage of BS 106, while UEs 102C and 102D remain within the cell coverage of BS 104.

[0081] The CN 110 then initiates (373) a session activation notification for the MBS with the BS 104, and the cell coverage of the BS 104 is reached. The UEs 102C and 102D thereby activate (323) MBS reception. The UEs 102C and 102D perform (382) a connection resumption procedure with the BS 104. An MBS data transmission 393 may occur from the CN 110 to the BS 104 and then to the UEs, including the UEs 102C and 102D.

[0082] BS 104 sends to BS 106, one of the BSs in the configured RAN notification area, a BS-to-BS interface message (363) including the MBS Session ID and / or an indication of the identities of UEs that have previously indicated interest in the MBS service, including UEs 102A and 102B, and / or the UE Radio Capabilities IE for each paging, which may each include an inactiveStatePODetermination indication for the UEs, including UEs 102A and 102B, and / or the respective useIdlePO configurations and / or the UE-specific DRX for each of the UEs, including UEs 102A and 102B. In some implementations, the BS-to-BS interface message is a RAN MULTICAST GROUP PAGING message defined in 3GPP TS 38.423.

[0083] After receiving the BS-to-BS interface message (363), if the BS 106 is an aggregation base station (i.e., without CU-DU splitting), the BS 106 determines (339) paging occasions for the UEs, including UE 102A and 102B, based on the UE radio capability IE, the respective useIdlePO configurations, and / or the respective UE-specific DRX for each received page. In some implementations, the BS 106 determines (first) paging occasions for the UEs, including UE 102A and 102B, according to parameters used for idle state in response to receiving the respective useIdlePO configurations for the UEs, including UE 102A and 102B. The BS 106 transmits (391) one or more paging messages (e.g., Paging messages defined in 3GPP TS 38.331 or 36.331) including the MBS session ID to the UEs, including UE 102A and UE 102B, within / over the (first) paging occasion. In such a case, UE 102A and UE 102B, in response to receiving the useIdlePO configuration, determine their paging occasions according to the parameters used for the idle state.

[0084] In some implementations, if there is no useIdlePO configuration for the UEs, including UEs 102A and 102B, BS 106 calculates a (second) paging occasion for the UEs, including UEs 102A and 102B, using parameters for the inactive state. In such a case, BS 106 transmits one or more paging messages (e.g., Paging messages defined in 3GPP TS 38.331 or 36.331) including the MBS session ID to the UEs, including UEs 102A and 102B, within / on the (second) paging occasion (391). In response to or because there is no useIdlePO configuration, UEs 102A and 102B again determine their paging occasion according to the parameters used for the inactive state.

[0085] If the BS 106 has a CU-DU split architecture, the determination of the paging occasion and the transmission of the paging message are similar to event 381, which is the session activation notification procedure for the UE 102A and the CU / DU of the BS 106.

[0086] Events 363, 339, and 391 may collectively be referred to as a RAN session activation procedure 375 involving Xn RAN paging for MBS, whereby UEs 102A and 102B activate 323 MBS reception.

[0087] The UEs 102A and 102B perform a connection resumption procedure with UE context retrieval (383) with the BS 106, the BS 104, and the CN 110. If received at event 373, the BS 104 may forward the MBS data to the BS 106 (346), and the BS 106 transmits the MBS data to the UE 102A (347). The CN 110 transmits the MBS data to the BS 106 (348), and the BS 106 transmits the MBS data to the UEs 102A and 102B (349).

[0088] 4A-4C, scenarios 400A, 400B, and 400C involve a UE-triggered RAN Notification Area (RNA) update procedure involving context retrieval over the Xn interface. The RNA update procedure may be triggered when the UE exits a configured RAN or periodically.

[0089] 4A , BS 104 may, at some point, perform a BS configuration update procedure (e.g., an NG-RAN node configuration update) with BS 106 by sending 404 a BS configuration update message to BS 106 and receiving 406 a BS configuration update acknowledgement message from BS 106. In some implementations, the BS configuration update procedure exchanges the BS's capabilities to support aligning paging occasions for RRC idle and inactive states, as described in the previous example scenario. In other implementations, this capability is exchanged via OAM (Operations, Administration, and Maintenance).

[0090] First, the UE 102A performs a connection release procedure with the BS 104 using suspendConfig (362) and transitions to an inactive state (408). The UE 102A then enters the cell coverage of the BS 106 and decides to perform an RNA update. The UE 102A may perform a random access procedure with the BS 106 (431). The UE 102A sends an RRC resume request message to the BS 106 with a cause RNA update and the I-RNTI allocated by the BS 104 (445). The BS 106 sends a RETRIEVE UE CONTEXT REQUEST message with the cause RNA update to the BS 104 (447). The BS 104 decides to relocate the UE context of the UE 102A to the BS 106 and sends to the BS 106 a RETRIEVE UE CONTEXT RESPONSE message that includes the UE's capabilities (e.g., the UE's radio capabilities for paging, which may include a ue-CapabilityRAT-List and / or an inactiveStatePODetermination indication), and / or a useIdlePO configuration, and / or an RRC context container (e.g., the HandoverPreparationInformation message defined in 3GPP TS 38.331) that may include a UE-specific DRX (448). In some implementations, the UE-specific DRX is not placed in the RRC context container but is included separately in the RETRIEVE UE CONTEXT RESPONSE message. At event 418, the BS 106 decides to transition the UE 102A to an inactive state and determines a paging occasion based on the information received regarding the inactive state from the RETRIEVE UE CONTEXT RESPONSE message. In some implementations, the determination of the paging occasion at event 418 may be similar to events 318, 319, 338, or 339 described in scenarios 300A through 300D. BS 106 may send an Xn-U ADDRESS INDICATION message to BS 104 for data transfer (454).The BS 106 sends a PATH SWITCH REQUEST message to the CN 110 (456). In response, the CN 110 sends a PATH SWITCH REQUEST ACKNOWLEDGE message to the BS 106 (458). The BS 106 sends a UE CONTEXT RELEASE message to the BS 104 to release the context for the UE 102A (460). The BS 106 sends an RRC release message to the UE 102A (465), which may or may not include a useIdlePO configuration. After receiving the RRC release message, the UE 102A remains in an inactive state and derives paging occasions according to the configuration.

[0091] 4B, scenario 400B also illustrates an RNA update similar to scenario 400A, except that the previous serving base station, BS 104, decides not to relocate the UE context and configures the UE to remain in an inactive state. The differences between the scenario of FIG. 4B and the scenario of FIG. 4A are explained below.

[0092] Similar to scenario 400A, BS 104 and BS 106 may at some point perform a BS configuration update procedure to exchange capabilities to support aligned paging occasions for the RRC idle and inactive states. UE 102A performs a connection release procedure with BS 104 using suspendConfig (362) and transitions to the inactive state (408). UE 102A then moves into the cell coverage of BS 106.

[0093] The UE 102A may decide to initiate an RNA update and perform a random access procedure with the BS 106 (431). The UE 102A sends an RRC resume request message to the BS 106 with the cause of the RNA update and the I-RNTI allocated by the BS 104 (445). The BS 106 sends a RETRIEVE CONTEXT REQUEST message with the cause of the RNA update to the BS 104 (447). At event 468, the BS 104 decides to transition the UE 102A to an inactive state without relocating the UE context of the UE 102A and determines whether the BS 106 supports the useIdlePO feature. The BS 104 sends a RETRIEVE UE CONTEXT FAILURE message with an RRC release message that may or may not include the useIdlePO configuration (449). BS 106 sends an RRC release message to UE 102A (465).

[0094] 4C, scenario 400C is similar to scenario 400A, except that BS 106 decides to resume the UE RRC connection after UE context retrieval. The differences between the scenario of FIG. 4C and the scenarios of FIG. 4A and FIG. 4B are explained below.

[0095] Similar to scenario 400A, BS 104 and BS 106 may at some point perform a BS configuration update procedure to exchange capabilities to support aligned paging occasions for the RRC idle and inactive states. UE 102A performs a connection release procedure with BS 104 using suspendConfig (362) and transitions to the inactive state (408). UE 102A then moves into the cell coverage of BS 106.

[0096] UE 102A may decide to initiate an RNA update and perform a random access procedure with BS 106 (431). UE 102A sends an RRC resume request message to BS 106 with the cause of the RNA update and the I-RNTI allocated by BS 104 (445). BS 106 sends a RETRIEVE UE CONTEXT REQUEST message with the cause of the RNA update to BS 104 (447). The BS 104 decides to relocate the UE context of the UE 102A to the BS 106 and sends a RETRIEVE UE CONTEXT RESPONSE message to the BS 106, including the UE's capabilities (e.g., the UE's radio capabilities for paging, which may include a ue-CapabilityRAT-List and / or an inactiveStatePODetermination indication), and / or a useIdlePO configuration, and / or an RRC context container (e.g., HandoverPreparationInformation defined in 3GPP TS 38.331) that may include a UE-specific DRX (448). In some implementations, the UE-specific DRX is not placed in the RRC context container but is included separately in the RETRIEVE UE CONTEXT RESPONSE message. The BS 106 decides to transition the UE 102A to the connected state and sends an RRC resume message to the UE 102A (450). The UE 102A transitions to a connected state (450) and sends an RRC resume complete message to the BS 106 (452). The BS 106 may send an Xn-U address indication to the BS 104 for data transfer (454). The BS 106 sends a path switch request message to the CN 110 (456). In response, the CN 110 sends a path switch request acknowledgement message to the BS 106 (458). The BS 106 sends a UE context release message to the BS 104 (460).

[0097] Some example methods that may be performed by the devices shown in Figures 1A-1B will now be described with reference to Figures 5A-5E and 6-12. As indicated at various points below, the example methods shown in Figures 5A-5E and 6-12 may be implemented during scenarios 300A-300D and 400A-400C described above.

[0098] Referring now to FIG. 5A, FIG. 5A illustrates an example method 500A for determining a paging configuration for a UE operating in an inactive state, such as UE 102A, that may be implemented, for example, in a base station, such as BS 106, or a CU of a base station, such as CU 172, of FIGS. 4A-4C.

[0099] The method begins at block 502, in which a base station receives an RRC Resume Request message from a UE operating in an inactive state (e.g., event 445 in FIGS. 4A-4C ). In block 504, the base station, in response to receiving the RRC Resume Request message, sends a RETRIEVE UE CONTEXT REQUEST message for the UE to a second RAN node (e.g., event 447 in FIGS. 4A-4C ). In block 506, the base station receives a RETRIEVE UE CONTEXT RESPONSE message from the second RAN node (e.g., event 448 in FIGS. 4A and 4C ) that includes a useIdlePO configuration for the UE. In block 508, the base station determines to continue configuring the useIdlePO configuration for the UE. In block 510, the base station generates an RRC Release message that includes the useIdlePO configuration in response to the determination. In block 512, the base station sends an RRC release message to the UE to leave the UE in an inactive state (e.g., event 462 in FIG. 4A). Blocks 508, 510, and 512 may be collectively referred to as event 550.

[0100] In some implementations, the useIdlePO configuration is set to the value "true" so that the base station (or a DU of the base station) calculates a PO for the UE according to the parameters used for the idle state. In other implementations, the useIdlePO configuration is not present so that the base station (or a DU of the base station) calculates paging occasions for the UE using the parameters for the inactive state. In some implementations, if included, the useIdlePO configuration is placed in a container IE (e.g., suspendConfig or cellReselectionPriorities) and configures the UE to use the parameters for the idle state to calculate paging occasions while the UE operates in the inactive state. In other implementations, if included, the useIdlePO configuration is not placed in a container IE.

[0101] 5B, which illustrates an example method 500B, similar to method 500A, for determining a paging configuration for a UE operating in an inactive state, such as UE 102A. Method 500B may be implemented, for example, in a base station, such as BS 106, or a CU of a base station, such as CU 172, of FIGS. 4A-4C.

[0102] The method begins at block 502, in which a base station receives an RRC Resume Request message from a UE operating in an inactive state (e.g., event 445 in FIGS. 4A-4C ). In block 504, the base station, in response to receiving the RRC Resume Request message, sends a RETRIEVE UE CONTEXT REQUEST message for the UE to a second RAN node (e.g., event 447 in FIGS. 4A-4C ). In block 506, the base station receives a RETRIEVE UE CONTEXT RESPONSE message from the second RAN node (e.g., event 448 in FIGS. 4A and 4C ) that includes a useIdlePO configuration for the UE. In block 508, the base station determines to continue configuring the useIdlePO configuration for the UE. In block 511, the base station, in response to the determination, generates an RRC Release message that does not include the useIdlePO configuration. In block 512, the base station sends an RRC release message to the UE to leave the UE in an inactive state (e.g., event 462 in FIG. 4A). Blocks 508, 511, and 512 may be collectively referred to as event 551.

[0103] In some implementations, the useIdlePO configuration is set to the value "true" so that the base station (or a DU of the base station) calculates a PO for the UE according to the parameters used for the idle state. In other implementations, the useIdlePO configuration is not present so that the base station (or a DU of the base station) calculates paging occasions for the UE using the parameters for the inactive state. In some implementations, if included, the useIdlePO configuration is placed in a container IE (e.g., suspendConfig or cellReselectionPriorities) and configures the UE to use the parameters for the idle state to calculate paging occasions while the UE operates in the inactive state. In other implementations, if included, the useIdlePO configuration is not placed in a container IE.

[0104] 5C, which illustrates an example method 500C, similar to methods 500A and 500B, for determining a paging configuration for a UE operating in an inactive state, such as UE 102A. Method 500C may be implemented, for example, in a base station, such as BS 106, or a CU of a base station, such as CU 172, of FIGS.

[0105] The method begins at block 502, in which a base station receives an RRC Resume Request message from a UE operating in an inactive state (e.g., event 445 in FIGS. 4A-4C ). In block 504, the base station, in response to receiving the RRC Resume Request message, sends a RETRIEVE UE CONTEXT REQUEST message for the UE to a second RAN node (e.g., event 447 in FIGS. 4A-4C ). In block 506, the base station receives a RETRIEVE UE CONTEXT RESPONSE message from the second RAN node (e.g., event 448 in FIGS. 4A and 4C ) that includes a useIdlePO configuration for the UE. In block 509, the base station determines to release the useIdlePO configuration for the UE. In block 511, in response to the determination, the base station generates an RRC Release message that does not include the useIdlePO configuration. In block 512, the base station sends an RRC Release message to the UE to leave the UE in an inactive state (e.g., event 462 in FIG. 4A ). Blocks 509 , 511 , and 512 may collectively be referred to as event 552 .

[0106] In some implementations, the first RAN node determines to release the useIdlePO configuration because the first RAN node does not support the useIdlePO configuration, and in such a case, the first RAN node refrains from sending an RRC message (e.g., an RRC resume message) to the UE that includes a complete configuration indication to release the useIdlePO configuration.

[0107] 5D, which shows an example method 500D, similar to methods 500A, 500B, and 500C, for determining a paging configuration for a UE operating in an inactive state, such as UE 102A. Method 500D may be implemented, for example, in a base station, such as BS 106, or a CU of a base station, such as CU 172, of FIGS.

[0108] The method begins at block 502, in which a base station receives an RRC Resume Request message from a UE operating in an inactive state (e.g., event 445 in FIGS. 4A-4C ). In block 504, the base station, in response to receiving the RRC Resume Request message, sends a RETRIEVE UE CONTEXT REQUEST message for the UE to a second RAN node (e.g., event 447 in FIGS. 4A-4C ). In block 506, the base station receives a RETRIEVE UE CONTEXT RESPONSE message from the second RAN node (e.g., event 448 in FIGS. 4A and 4C ) that includes a useIdlePO configuration for the UE. In block 509, the base station determines to release the useIdlePO configuration for the UE. In block 514, in response to the determination, the base station generates an RRC Release message that includes an indication to release the useIdlePO configuration. In block 512, the base station sends an RRC release message to the UE to leave the UE in an inactive state (e.g., event 462 in FIG. 4A). Blocks 509, 514, and 512 may be collectively referred to as event 553.

[0109] In some implementations, the indication may be a new field or IE that indicates to the UE to release the useIdlePO configuration.

[0110] 5E, which illustrates an example method 500E, similar to methods 500A, 500B, 500C, and 500D, for determining a paging configuration for a UE operating in an inactive state, such as UE 102A. Method 500E may be implemented, for example, in a base station, such as BS 106, or a CU of a base station, such as CU 172, of FIGS. 4A-4C.

[0111] The method begins at block 502, in which a base station receives an RRC Resume Request message from a UE operating in an inactive state (e.g., event 445 in FIGS. 4A-4C ). In block 504, the base station, in response to receiving the RRC Resume Request message, sends a RETRIEVE UE CONTEXT REQUEST message for the UE to a second RAN node (e.g., event 447 in FIGS. 4A-4C ). In block 505, the base station receives a RETRIEVE UE CONTEXT RESPONSE message from the second RAN node (e.g., event 448 in FIGS. 4A and 4C ) including an inactiveStatePODetermination capability for the UE. In block 507, the base station determines to configure a useIdlePO configuration for the UE based on the inactiveStatePODetermination capability. In block 510, the base station generates an RRC Release message including the useIdlePO configuration in response to the determination. In block 512, the base station sends an RRC release message to the UE to leave the UE in an inactive state (eg, event 462 in FIG. 4A).

[0112] Referring now to Figure 6, Figure 6 shows an example method 600, similar to methods 500A-500E, for determining a paging configuration for a UE operating in an inactive state, such as UE 102A. Method 600 may be implemented, for example, in a base station, such as BS 106, or a CU of a base station, such as CU 172, of Figures 4A-4C.

[0113] The method begins at block 602, in which a base station receives an RRC Resume Request message from a UE operating in an inactive state (e.g., event 445 in FIGS. 4A-4C). In block 604, the base station sends a RETRIEVE UE CONTEXT REQUEST message for the UE to a second RAN node in response to receiving the RRC Resume Request message (e.g., event 447 in FIGS. 4A-4C). In block 606, the base station receives a RETRIEVE UE CONTEXT RESPONSE message including a useIdlePO configuration for the UE from the second RAN node (e.g., event 448 in FIG. 4A). In block 608, the base station determines whether to transition the UE to an inactive state or a connected state. If the determination is to transition to an inactive state, flow proceeds to block 610, in which the base station performs 550, 551, 552, or 553 (e.g., event 462 in FIG. 4A). On the other hand, if the determination is that the UE should be transitioned to the connected state, flow proceeds to block 612 where the base station releases the useIdlePO configuration for the UE in response to the transition of the UE to the connected state. In block 614, the base station sends an RRC resume message to the UE to transition the UE to the connected state (e.g., event 450 of FIG. 4C).

[0114] In some implementations, the first RAN node determines to transition the UE to a connected state because the first RAN node does not support the useIdlePO configuration. In other implementations, the first RAN node determines to transition the UE to a connected state because the RAN node does not support RNA updates without a state transition. In yet other implementations, the first RAN node determines to transition the UE to a connected state because the first RAN node and the UE need to communicate data with each other.

[0115] 7, which illustrates an example method 700, similar to method 600, for determining a paging configuration for a UE operating in an inactive state, such as UE 102A. Method 700 may be implemented, for example, in a base station, such as BS 106, or a CU of a base station, such as CU 172, of FIGS. 4A-4C.

[0116] The method begins at block 702, in which a base station receives an RRC resume request message from a UE operating in an inactive state (e.g., event 445 in FIGS. 4A-4C). In block 704, the base station sends a RETRIEVE UE CONTEXT REQUEST message for the UE to a second RAN node in response to receiving the RRC resume request message (e.g., event 447 in FIGS. 4A-4C). In block 706, the base station receives a RETRIEVE UE CONTEXT RESPONSE message from the second RAN node (e.g., event 448 in FIG. 4A) that includes a configuration for the UE. In block 708, the base station determines that the configuration is not supported or decides to release the configuration. In block 710, the base station determines whether the configuration is for an inactive state. For example, the useIdlePO configuration is a configuration used for a UE operating in an inactive state. If the determination is YES (i.e., the configuration is for an inactive state), the flow proceeds to block 714 where the base station generates an RRC Resume message that does not include an indication of the complete configuration. The flow then proceeds to block 716 where the base station sends an RRC Resume message to the UE to transition the UE to a Connected state (e.g., event 450 of FIG. 4C). The base station may then release the configuration in block 718, for example, because the base station does not support the configuration or does not want to enable the configuration. There may not be a strict order of blocks (712, 716) and 718.

[0117] On the other hand, if the determination is NO (i.e., the configuration is not for the inactive state), the flow proceeds to block 712 where the base station generates an RRC Resume message including an indication of the complete configuration. The flow then proceeds further to block 716 where the base station sends an RRC Resume message to the UE to transition the UE to a Connected state (e.g., event 450 of FIG. 4C). The base station may then release the configuration in block 718, for example, because the base station does not support the configuration or does not want to enable the configuration. There may not be a strict order of blocks (712, 716) and 718.

[0118] Referring now to FIG. 8, FIG. 8 illustrates an example method 800 for determining a paging configuration for a UE operating in an inactive state that may be implemented, for example, in a UE such as UE 102A of FIGS. 3A-3D and 4A-4C.

[0119] The method begins at block 802, in which the UE receives a first RRC release message from the RAN (e.g., event 306 of FIG. 3A or event 362 of FIG. 4A) including a parent IE that includes a useIdlePO configuration. At block 804, the UE transitions to an inactive state in response to the RRC release message (e.g., event 308 of FIG. 3A or event 408 of FIG. 4A). At block 806, the UE determines a paging occasion for the idle state using parameters for the idle state to receive a paging message from the RAN while the UE is operating in the inactive state. At block 808, the UE attempts to receive a paging message from the RAN on a paging occasion for the idle state while the UE is operating in the inactive state. At block 810, the UE sends an RRC resume request message to the RAN while the UE is operating in the inactive state. In block 812, the UE receives a second RRC release message from the RAN in response to the RRC Resume Request message that does not include the useIdlePO configuration (e.g., event 462 in FIG. 4A ). In block 814, the UE 102A determines whether the second RRC release message includes a parent IE of the useIdlePO configuration. For example, the parent IE is a container IE described above, such as the suspendConfig IE or the CellReselectionPriorities IE. If the determination is YES (i.e., the second RRC release message includes a parent IE of the useIdlePO configuration), the flow proceeds to block 816, where the UE releases the useIdlePO configuration. In block 818, the UE determines a paging occasion for the inactive state using parameters for the inactive state to receive a paging message from the RAN while operating in the inactive state. In block 820, the UE attempts to receive a paging message on a paging occasion for the inactive state while the UE is operating in the inactive state.

[0120] On the other hand, if the determination at block 814 is NO (i.e., the second RRC release message does not include a parent IE for the useIdlePO configuration), the flow proceeds to block 822, where the UE retains the useIdlePO configuration. In block 824, the UE determines a paging occasion for the idle state using parameters for the idle state to receive a paging message while the UE is operating in an inactive state. In block 826, the UE attempts to receive a paging message from the RAN on a paging occasion for the idle state while the UE is operating in an inactive state.

[0121] When the UE operates in an inactive state with a gNB in ​​the RAN, the parent IE in some implementations may be the SuspendConfig IE defined in 3GPP TS 38.331. Alternatively, the parent IE may be the CellReselectionPriorities IE defined in 3GPP TS 38.331. Further alternatively, the parent IE may be a (new) IE that is neither the SuspendConfig IE nor the CellReselectionPriorities IE. In this case, the parent IE may be the RRCRelease-v16xy-IEs IE, where x and y are integers, x > 6 (for example, x may be 7 or 8), and y >= 0.

[0122] When the UE operates in an inactive state with an ng-eNB of the RAN, the parent IE in some implementations may be the RRC-InactiveConfig-v17xy IE defined in 3GPP TS 36.331, where x and y are integers, x >= 0, and y >= 0. Alternatively, the parent IE may be the RRC-InactiveConfig-v16xy IE defined in 3GPP TS 36.331, where x and y are integers, x > 6 (e.g., x may be 7 or 8), and y >= 0.

[0123] Referring now to FIG. 9, FIG. 9 illustrates an example method 900 for determining a paging configuration for an inactive UE that may be implemented in a UE such as, for example, UE 102A of FIGS. 3A-3D and 4A-4C.

[0124] The method begins at block 902, in which the UE receives a useIdlePO configuration from the RAN while operating in a connected or inactive state (e.g., event 306 of FIG. 3A or event 362 of FIG. 4A). In block 904, the UE may transition from the connected state to the inactive state. In block 906, the UE determines a paging occasion for the idle state using parameters for the idle state to receive a paging message from the RAN while operating in the inactive state. In block 908, the UE attempts to receive a paging message from the RAN on a paging occasion for the idle state while operating in the inactive state. In block 910, the UE transitions to the connected or idle state. In block 912, the UE releases the useIdlePO configuration in response to transitioning to the connected or idle state. In block 914, the UE may transition to the inactive state. In block 916, the UE may determine a paging occasion for the inactive state using the parameters for the inactive state to receive a paging message from the RAN while operating in the inactive state. In block 918, the UE may attempt to receive a paging message on a paging occasion for the idle state while operating in the inactive state.

[0125] 10, which illustrates an example method 1000 for determining a paging configuration for a UE operating in an inactive state, such as UE 102A. Method 1000 may be implemented, for example, in a base station, such as BS 104 of FIG. 4B, or in a CU of a base station, such as CU 172.

[0126] The method begins at block 1002, in which the base station sends an RRC release message including a useIdlePO configuration to transition the UE to an inactive state (e.g., event 362 in FIGS. 4A-4C ). In block 1004, the base station receives a RETRIEVE UE CONTEXT REQUEST message from a second RAN node for the UE operating in an inactive state (e.g., event 447 in FIGS. 4A-4C ). In block 1006, the base station determines whether the second RAN node supports the useIdlePO configuration. If the determination is YES (i.e., the useIdlePO configuration is supported), flow proceeds to block 1008, in which the base station performs blocks 508 and 510, or blocks 508 and 511. Then, in block 1012, the base station sends a RETRIEVE UE CONTEXT FAILURE message including the RRC release message to the second RAN node.

[0127] On the other hand, if the determination is NO (i.e., the useIdlePO configuration is not supported), the flow proceeds to block 1010 where the base station performs blocks 509 and 511 or blocks 509 and 514. Then, in block 1012, the base station sends a RETRIEVE UE CONTEXT FAILURE message containing an RRC release message to the second RAN node.

[0128] 11 shows a method 1100 for determining a paging occasion that may be performed by a DU (e.g., DU 174). In block 1102, the DU receives an indication from a CU (e.g., CU 172) regarding whether a UE (e.g., UE 102) operating in an inactive state associated with a protocol for controlling radio resources supports determining an inactive state paging occasion using parameters defined for determining an idle state paging occasion (e.g., events 316, 315). The DU 174 determines an inactive state paging occasion based on the indication in block 1104 (e.g., events 318, 319) and pages the UE operating in an inactive state on the inactive state paging occasion in block 1106 (e.g., events 320, 321).

[0129] 12 illustrates a method 1200 for managing paging occasion determination that may be performed by a CU (e.g., CU 172). In block 1202, the CU determines to page a UE (e.g., UE 102) operating in an inactive state associated with a protocol for controlling radio resources (e.g., in response to events 309, 310, 313, 314). In block 1204, the CU sends a paging message to a DU (e.g., DU 174) to cause the DU to page the UE, the paging message including an indication as to whether the UE operating in the inactive state supports determining paging occasions in the inactive state using parameters defined for determining paging occasions in the idle state (e.g., events 316, 315).

[0130] The following list of examples reflects various embodiments expressly contemplated herein.

[0131] Example 1 is a method for determining a paging occasion, executed by a central unit (CU) and a distributed unit (DU) of a distributed base station including the CU and includes the steps of receiving, from the DU, an indication by the DU regarding whether a user equipment (UE) operating in an inactive state associated with a protocol for controlling radio resources supports determining an inactive state paging occasion using parameters defined for determining an idle state paging occasion; determining, by the DU, an inactive state paging occasion based on the indication; and paging, by the DU, the UE operating in the inactive state at the inactive state paging occasion.

[0132] Example 2 is the method of Example 1, wherein receiving the indication includes receiving an indication indicating that the UE supports determining an inactive paging occasion using parameters defined for determining an idle paging occasion, and determining the inactive paging occasion includes determining the inactive paging occasion using parameters defined for determining an idle paging occasion.

[0133] Example 3 is the method of Example 1, wherein receiving the indication includes receiving an indication indicating that the UE does not support determining inactive paging occasions using parameters defined for determining idle paging occasions, and determining inactive paging occasions includes determining inactive paging occasions using parameters defined for determining inactive paging occasions.

[0134] Example 4 is the method of any one of the preceding examples, further including receiving, by the DU, from the CU, a configuration that enables the UE to determine inactive state paging occasions using parameters defined for determining idle state paging occasions, wherein the determination of inactive state paging occasions is further based on the configuration.

[0135] Example 5 is the method of any one of the previous examples, wherein receiving an indication includes receiving an inactiveStatePODetermination indication.

[0136] Example 6 is the method of any one of the preceding examples, wherein receiving the indication includes receiving the indication in a paging message.

[0137] Example 7 is the method of example 6, wherein the paging message is formatted according to a protocol having termination points at the CU and the DU.

[0138] Example 8 is a method for managing paging occasion determination, executed by a central unit (CU) and a distributed unit (DU) of a distributed base station including the CU and the DU, comprising: determining, by the CU, to page a user equipment (UE) operating in an inactive state associated with a protocol for controlling radio resources; and sending, by the CU to the DU, a paging message to cause the DU to page the UE, the paging message including an indication as to whether the UE operating in the inactive state supports determining paging occasions in the inactive state using parameters defined for determining paging occasions in the idle state.

[0139] Example 9 is the method of example 8, further comprising receiving an indication at the CU from another base station before sending the paging message.

[0140] Example 10 is the method of example 9, wherein receiving the indication includes receiving a RAN PAGING message that includes the indication.

[0141] Example 11 is the method of Example 8, further including, before sending the paging message, receiving a UE capabilities information element from at least one of the UE, a core network (CN), or another base station; and determining, by the CU, based on the UE capabilities information element, whether the UE supports determining paging occasions in an inactive state using parameters defined for determining paging occasions in an idle state.

[0142] Example 12 is the method of any one of Examples 8 to 11, further including sending, by the CU in a paging message to the DU, a configuration that enables the UE to determine paging occasions in an inactive state using parameters defined for determining paging occasions in an idle state.

[0143] Example 13 is the method of any one of examples 8 to 12, wherein sending a paging message including an indication includes sending a paging message including an inactiveStatePODetermination indication.

[0144] Example 14 is the method of any one of examples 8 to 13, wherein transmitting the paging message includes transmitting a paging message formatted according to a protocol having termination points at the CU and the DU.

[0145] Example 15 is a network node of a distributed base station, the network node including processing hardware and configured to implement a method according to any one of the previous examples.

[0146] The following explanations may apply to the above explanations.

[0147] In general, a description of one of the above figures may apply to another of the above figures. The above-mentioned examples, implementations, and methods may be combined where there is no contradiction. The above-mentioned events or blocks may be optional or omitted. For example, dashed events or blocks in the figures or information elements in parentheses may be optional. In some implementations, "message" is used and may be replaced by "information element (IE)." In some implementations, "IE" is used and may be replaced by "field." In some implementations, "configuration" may be replaced by "configurations" or configuration parameters. In some implementations, "MBS" may be replaced by "multicast" or "broadcast."

[0148] A user device (e.g., UE 102) on which the above-described methods may be implemented can be any suitable device capable of wireless communication, such as a smartphone, a tablet computer, a laptop computer, a mobile game console, a point-of-sale (POS) terminal, a health monitoring device, a drone, a camera, a media streaming dongle or another personal media device, a wearable device such as a smartwatch, a wireless hotspot, a femtocell, or a broadband router. Furthermore, in some cases, the user device may be integrated into an electronic system such as a vehicle head unit or an advanced driver assistance system (ADAS). Furthermore, the user device may operate as an Internet of Things (IoT) device or a mobile internet device (MID). Depending on the type, the user device may include one or more general-purpose processors, computer-readable memory, a user interface, one or more network interfaces, one or more sensors, etc.

[0149] Certain embodiments are described in this disclosure as including logic or several components or modules. The modules may be software modules (e.g., code or machine-readable instructions stored on a non-transitory machine-readable medium) or hardware modules. A hardware module is a tangible unit capable of performing specific operations and may be configured or arranged in a specific way. A hardware module may include dedicated circuitry or logic that is permanently configured to perform specific operations (e.g., as a field programmable gate array (FPGA) or application-specific integrated circuit (ASIC), dedicated processor such as a digital signal processor (DSP)) or the like. A hardware module may also include programmable logic or circuitry that is temporarily configured by software to perform specific operations (e.g., as contained within a general-purpose processor or other programmable processor). The decision to implement a hardware module in dedicated permanently configured circuitry or temporarily configured circuitry (e.g., configured by software) may be driven by cost and time considerations.

[0150] When implemented in software, the methods may be provided as part of an operating system, a library used by multiple applications, a specific software application, etc. The software may be executed by one or more general-purpose processors or one or more special-purpose processors. [Explanation of symbols]

[0151] 100 Wireless Communication System 102UE 102A UE 102B UE 102C UE 102D UE 104 Base station 106 Base Station 105 RAN 110CN 111 EPC 112 SGW 114 MME 116 PGW 124 cells 126 cells 130 Processing Hardware 132 MBS Controller 134 Non-MBS Controller 136 Paging Controller 140 Processing Hardware 142 MBS Controller 144 Non-MBS Controller 146 Paging Controller 150 Processing Hardware 152 MBS Controller 154 Non-MBS Controller 156 Paging Controller 160 5GC 162 UPF 164 AMF 166 SMF 170 base station 172 CU 172A CU-CP 172B CU-UP 174 DU 200 Protocol Stack 201A eNB / ng-eNB 201B gNB 202A EUTRA PHY sublayer 202B NR PHY 204A EUTRA MAC Sublayer 204B NR MAC sublayer 206A EUTRA RLC Sublayer 206B NR RLC sublayer 208 EUTRA PDCP Sublayer 210 NR PDCP Sublayer 212 SDAP Sublayer 250 Protocol Stack

Claims

1. 1. A method for determining a paging occasion, the method being performed by a central unit (CU) (172) and a distributed unit (DU) (174) of a distributed base station (104, 106, 170, 201A, 201B) including the DU, receiving (315, 316) by the DU (174) from the CU (172) an information element indicating that a user equipment (UE) (102) operating in an inactive state associated with a protocol for controlling radio resources supports determining paging occasions in an inactive state using parameters defined for determining paging occasions in an idle state; determining, by the DU (174), paging occasions for the inactive state using the parameters (318, 319); paging (320, 321) the UE (102) operating in the inactive state at the paging occasion of the inactive state by the DU (174); A method comprising:

2. The method of claim 1, wherein the reception of the information element occurs at a first instance; the determination of the inactive paging opportunity occurs at the first instance; the paging of the UE occurs at the first instance, and the parameter is a first parameter; The method comprises: In a second instance, receiving an indication that the UE (102) does not support determining paging occasions in the inactive state using the first parameter defined for determining paging occasions in the idle state; in the second instance, determining a paging occasion for the inactive state using a second parameter defined for determining a paging occasion for the inactive state; The method of claim 1 further comprising:

3. receiving, by the DU (174) from the CU (172), a configuration (304, 315, 316) that enables the UE (102) to determine a paging occasion in the inactive state using the parameters defined for determining a paging occasion in the idle state; The method of claim 1 , wherein the steps of determining paging occasions for the inactive state (318, 319) are further based on the configuration.

4. The step of receiving the information element (315, 316) The method of claim 1 , comprising receiving an inactiveStatePODetermination information element.

5. The step of receiving the information element (315, 316) The method of claim 1 , comprising receiving the information element in a paging message.

6. The method of claim 5, wherein the paging message is formatted according to a protocol having termination points at the CU (172) and the DU (174).

7. 1. A method for managing paging occasion determination, the method being performed by a central unit (CU) (172) of a distributed base station (104, 106, 170, 201A, 201B) including a CU (172) and distributed units (DUs) (174), the method comprising: A step (315, 316) of transmitting a paging message to the DU (174) by the CU (172) to cause the DU (174) to page the UE (102), the UE operates in an inactive state associated with a protocol for controlling radio resources using parameters defined for determining idle paging occasions; Steps (315, 316), wherein the paging message includes an information element indicating that the UE (102) operating in the inactive state supports determining paging occasions in the inactive state using the parameter; A method comprising:

8. 8. The method of claim 7, further comprising receiving (363, 364) the information element at the CU (172) from another base station before transmitting (315, 316) the paging message.

9. receiving the information element, The method of claim 8 , comprising receiving a RAN PAGING message including the information element.

10. receiving (310, 314) a UE capability information element from a core network (CN) before sending (315, 316) said paging message; determining, by the CU (172), based on the UE capability information element, whether the UE (102) supports determining paging occasions in the inactive state using the parameters defined for determining paging occasions in the idle state; 8. The method of claim 7, further comprising:

11. 8. The method of claim 7, further comprising: transmitting, by the CU (172) to the DU (174) in the paging message, a configuration (315, 316) that enables the UE (102) to determine a paging occasion in the inactive state using the parameters defined for determining a paging occasion in the idle state.

12. transmitting (315, 316) the paging message including the information element; The method of claim 7, further comprising transmitting the paging message including an inactiveStatePODetermination information element.

13. The steps of transmitting the paging message (315, 316) 8. The method of claim 7, comprising transmitting the paging message formatted according to a protocol having termination points at the CU (172) and the DU (174).

14. A network node (172, 174) of a distributed base station (104, 106, 170, 201A, 201B), comprising processing hardware (130, 140) and a transceiver, and configured to implement the method of any one of claims 1 to 13.

Images