EP4736550A1

EP4736550A1 - Enabling paging for a further reduced capacity user equipment

Info

Publication number: EP4736550A1
Application number: EP24761458.9A
Authority: EP
Inventors: Chih-Hsiang Wu
Original assignee: Google LLC
Current assignee: Google LLC
Priority date: 2023-08-10
Filing date: 2024-08-08
Publication date: 2026-05-06
Also published as: CN121620985A; WO2025034935A1

Abstract

A method in a core network (CN) for determining a capability of a user equipment (UE) includes transmitting, from the CN to a radio access network (RAN), a first paging message including a first user equipment (UE) capability of a first UE and for a first UE type associated with a reduced UE capability for paging the first UE; and transmitting, from the CN to the RAN, a second paging message including a second UE capability of a second UE and for a second UE type associated with a further reduced UE capability for paging the second UE.

Description

ENABLING PAGING FOR A FURTHER REDUCED CAPABILITY USER EQUIPMENT

CROSS-REFERENCE TO RELATED APPLICATIONS

[0001] This application claims priority to and the benefit of the filing date of provisional U.S. Patent Application No. 63/532,015 entitled “ENABLING PAGING FOR A FURTHER REDUCED CAPABILITY USER EQUIPMENT,” filed on August 10, 2023. The entire contents of the provisional applications are hereby expressly incorporated herein by reference.

FIELD OF THE DISCLOSURE

[0002] This disclosure relates to wireless communications and, more particularly, to enabling paging for UEs with further reduced capability (fRedCap).

BACKGROUND

[0003] The background description provided herein is for the purpose of generally presenting the context of the disclosure. Work of the presently named inventors, to the extent it is described in this background section, as well as aspects of the description that may not otherwise qualify as prior art at the time of filing, are neither expressly nor impliedly admitted as prior art against the present disclosure.

[0004] In telecommunication systems, the Packet Data Convergence Protocol (PDCP) sublayer of the radio protocol stack provides services such as transfer of user-plane data, ciphering, integrity protection, etc. For example, the PDCP layer defined for the Evolved Universal Terrestrial Radio Access (EUTRA) radio interface and New Radio (NR) provides sequencing of protocol data units (PDUs) in the uplink direction (from a user device, also known as a user equipment (UE), to a base station) as well as in the downlink direction (from the base station to the UE). Further, the PDCP sublayer provides services for signaling radio bearers (SRBs) to the Radio Resource Control (RRC) sublayer. The PDCP sublayer also provides services for data radio bearers (DRBs) to a Service Data Adaptation Protocol (SDAP) sublayer or a protocol layer such as an Internet Protocol (IP) layer, an Ethernet protocol layer, and an Internet Control Message Protocol (ICMP) layer. Generally speaking, the UE and a base station use SRBs to exchange RRC messages as well as non-access stratum (NAS) messages, and use DRBs to transport data on a user plane. [0005] Base stations that operate according to modem requirements support significantly larger bandwidth than base stations that operate according to older requirements. Accordingly, user equipment units (UEs) can support a 100 MHz bandwidth in frequency range 1 (FR1) and a 400 MHz bandwidth in a frequency range 2 (FR2).

[0006] However, normal-capability UEs (i.e., UEs conforming to older requirements) may coexist with reduced-capability UEs. Compared to normal-capability UEs, reduced-capability UEs (also referred to as RedCap UEs) tend to have a lower bandwidth capability, a reduced processing capability, and/or fewer antennas. RedCap UEs also, depending on the device, lack support for dual connectivity and/or carrier aggregation. RedCap UEs have been established with a framework for enabling reduced capability NR devices suitable for a range of use cases, including industrial sensors, video surveillance, and wearables use cases, with requirements on low UE complexity and sometimes also on low UE power consumption. However, techniques for determining whether a UE is a normal-capability UE, a RedCap UE configured according to older protocols, or a RedCap UE configured according to modem protocols is desired.

SUMMARY

[0007] To further expand the market for RedCap use cases with relatively low cost, low energy consumption, and low data rate requirements, techniques to support UEs with further complexity reduction are desired. In particular, RedCap should provide NR support for low-tier devices between existing low power, wide area (LPWA) UEs and the capabilities of RedCap UEs. The supported peak data rate for RedCap UEs targets to 10Mbps lower than the peak data rate supported by older RedCap UEs.

[0008] If a base station is unaware of whether a UE is a normal-capability UE, an older RedCap UE or a more modern RedCap UE, the base station can page the UE in a manner that the UE does not support.

[0009] In some aspects, the techniques described herein relate to a method implemented in a core network (CN), the method including: transmitting, from the CN to a radio access network (RAN), a first paging message including a first user equipment (UE) capability of a first UE and for a first UE type associated with a reduced UE capability for paging the first UE; and transmitting, from the CN to the RAN, a second paging message including a second UE capability of a second UE and for a second UE type associated with a further reduced UE capability for paging the second UE.

[0010] In some aspects, the techniques described herein relate to a method implemented in a distributed unit (DU) of a distributed radio access network (RAN) node including a centralized unit (CU), the method including: receiving, at the DU from the CU, a first paging message including one of (i) a first user equipment (UE) capability for a first UE type associated with a reduced UE capability or (ii) a second UE capability for a second UE type associated with a further reduced UE capability; generating, at the DU, a second paging message for a UE; and in a first instance, when the first paging message includes the first UE capability, transmitting, from the DU to the UE, the second paging message based on the first UE capability; in a second instance, when the first paging message includes the second UE capability, transmitting, from the DU to the UE, the second paging message based on the second UE capability.

[0011] In further aspects, the techniques described herein related to an apparatus, operating as a network node, comprising processing hardware and configured to implement a method according to any one of the preceding aspects.

BRIEF DESCRIPTION OF THE DRAWINGS

[0012] Fig. 1A is a block diagram of an example system in which a RAN implements the techniques of this disclosure for identifying different types of UEs;

[0013] Fig. IB is a block diagram of an example base station in which a central unit (CU) and a distributed unit (DU) can operate in the system of Fig. 1A;

[0014] Fig. 2A is a block diagram of an example protocol stack according to which the UE of Fig. 1A communicates with base stations;

[0015] Fig. 2B is a block diagram of an example protocol stack according to which the UE of Fig. 1A communicates with a CU and a DU;

[0016] Fig. 3 A is a messaging diagram of an example scenario in which a DU receives a MAC PDU including an RRC request and a logical channel identity (LCID), determines a type of the UE based on the LCID and indicates a different type to a CU and the CU determines a type of the UE based on the indicated type; [0017] Fig. 3B is a messaging diagram of an example scenario in which a DU receives a MAC PDU including an RRC request and a logical channel identity (LCID), determines a type of the UE based on the LCID and indicates the determined type to a CU and the CU determines a type of the UE based on the indicated type;

[0018] Fig. 3C is a messaging diagram of an example scenario in which a base station receives an RRC request from a UE, determines a type of the UE based on a random access preamble or a random access resource and indicates a different type to a CU and the CU determines a type of the UE based on the indicated type;

[0019] Fig. 3D is a messaging diagram of an example scenario in which a base station receives an RRC request from a UE, determines a type of the UE based on a random access preamble or a random access resource and indicates the determined type to a CU and the CU determines a type of the UE based on the indicated type;

[0020] Fig. 3E is a messaging diagram of an example scenario in which a DU receives a MAC PDU including an RRC request and a logical channel identity (LCID), determines a type of the UE based on the LCID and indicates a different type to a CU and the CU determines a type of the UE based on the RRC request;

[0021] Fig. 3F is a messaging diagram of an example scenario in which a DU receives a MAC PDU including an RRC request and a logical channel identity (LCID), determines a type of the UE based on a random access preamble or a random access resource and indicates a different type to a CU and the CU determines a type of the UE based on the RRC request;

[0022] Fig. 4 is a messaging diagram of an example scenario in which a UE, a DU, a CU, and a CN perform connection establishment, data communication, and connection release operations to transmit information regarding UE capability from the UE to the CN;

[0023] Figs. 5 and 6 are messaging diagrams of example scenarios in which a UE, a first base station, a second base station, and a CN perform connection establishment, data communication, and/or connection release operations to transmit information regarding UE capability from the CN and/or UE to the second base station; [0024] Fig. 7 is a flow diagram of an example method for including a first and second UE capability in radio paging information for the UE and transmitting the radio paging information to a CN, which can be implemented in a RAN node of Fig. 1 A;

[0025] Fig. 8 is a flow diagram of an example method for receiving a first and second UE capability from a first base station and transmitting, to a second base station the first and second UE capability in a paging message for the UE, which can be implemented in a CN of Fig. 1 A;

[0026] Fig. 9A is a flow diagram of an example method for receiving UE radio paging information for a UE from a first base station, including a first UE capability and a second UE capability, and transmitting the UE radio paging information to a second base station, which can be implemented in a CN of Fig. 1 A;

[0027] Fig. 9B is a flow diagram of an example method similar to that of Fig. 9A, but in which the UE radio paging information includes a first UE capability but not a second UE capability;

[0028] Fig. 9C is a flow diagram of an example method similar to that of Fig. 9A, but in which the UE radio paging information includes a second UE capability but not a first UE capability;

[0029] Fig. 10A is a flow diagram of an example method for receiving a message from a CN including a first UE capability and a second UE capability, generating a paging message, and transmitting the paging message using radio resources and/or a configuration based on the first UE capability or the second UE capability, which can be implemented in a RAN node of Fig. 1A;

[0030] Fig. 10B is a flow diagram of an example method similar to that of Fig. 10A, but in which the message from the CN includes a first UE capability but not a second UE capability;

[0031] Fig. 10C is a flow diagram of an example method similar to that of Fig. 10 A, but in which the message from the CN includes a second UE capability but not a first UE capability;

[0032] Fig. 11 A is a flow diagram of an example method for receiving a message from a CU including a first UE capability and a second UE capability, generating a paging message, and transmitting the paging message using radio resources and/or a configuration based on the first UE capability or the second UE capability, which can be implemented in a DU of Fig. IB; [0033] Fig. 1 IB is a flow diagram of an example method similar to that of Fig. HA, but in which the message from the CU includes a first UE capability but not a second UE capability;

[0034] Fig. 11C is a flow diagram of an example method similar to that of Fig. 11 A, but in which the message from the CU includes a second UE capability but not a first UE capability;

[0035] Fig. 12A is a flow diagram of an example method for determining whether to transmit a paging message using a first radio resource or second radio resource based on whether an interface message for paging a UE includes a first UE capability or second UE capability, which can be implemented in a RAN node of Fig. 1 A;

[0036] Fig. 12B is a flow diagram of an example method similar to that of Fig. 12 A, but in which the RAN node makes the determination based on whether the interface message includes a first UE capability;

[0037] Fig. 12C is a flow diagram of an example method similar to that of Fig. 12 A, but in which the RAN node determines whether to transmit the paging message using a first radio resource, second radio resource, or third radio resource;

[0038] Fig. 13A is a flow diagram of an example method for receiving a message from another RAN node including a first UE capability and second UE capability, generating a paging message, and transmitting the paging message using radio resources determined based on the first UE capability and the second UE capability, which can be implemented in a RAN node (e.g., a base station) of Fig. 1A;

[0039] Fig. 13B is a flow diagram of an example method similar to that of Fig. 13 A, but in which the message from the other RAN node includes a first UE capability but not a second UE capability;

[0040] Fig. 13C is a flow diagram of an example method similar’ to that of Fig. 13 A, but in which the message from the other RAN node includes a second UE capability but not a first UE capability;

[0041] Fig. 14A is a flow diagram of an example method for receiving a paging message including a first UE capability and a second UE capability, and transmitting a message to the DU including the first UE capability and the second UE capability, which can be implemented in a CU of Fig. IB; [0042] Fig. 14B is a flow diagram of an example method similar to that of Fig. 14A, but in which the paging message includes a first UE capability but not a second UE capability; and

[0043] Fig. 14C is a flow diagram of an example method similar to that of Fig. 14A, but in which the paging message includes a second UE capability but not a first UE capability.

DETAILED DESCRIPTION OF THE DRAWINGS

[0044] Generally speaking, the techniques of this disclosure enable a RAN to determine whether a UE is a reduced capability UE or a normal capability UE.

[0045] Fig. 1A depicts an example wireless communication system 100 that can communicate with reduced capability and normal capability UEs according to techniques of this disclosure. The wireless communication system 100 includes UE 102 and UE 103, as well as base stations 104, 106A, 106B of a radio access network (RAN) (e.g., RAN 105) that are connected to a core network (CN) 110. The base stations 104, 106A, 106B can be any suitable type, or types, of base stations, such as an evolved node B (eNB), a next-generation eNB (ng-eNB), or a 5G Node B (gNB), for example. As a more specific example, the base station 104 can be an eNB or a gNB, and the base stations 106A and 106B can be gNBs.

[0046] In an example communication network 100A of Fig. 1A, a UE 101 is a reduced capability (RedCap) UE, a UE 102 is a further reduced capability (fRedCap) UE, and a UE 103 is or a normal capability UE. For example, the UE 101 can conform to the RedCap requirements described in various standards documents (e.g., 3GPP technical specification (TS) 38.306, RP- 201368, Rl-2005233, 3GPP technical report (TR) 38.875, and/or agreements in the RANl#101- e and RANl#102-e meetings). In another example, the UE 102 can conform to the further RedCap (fRedCap) requirements described in standards documents (e.g., RP-223544 and/or RP- 231488). In contrast, the UE 102 can conform to the evolved mobile broadband (eMBB) or ultra-reliable low-latency communication (URLLC) requirements for 5G NR and support a 100 MHz BW in FR1 for bands where 100MHz channel is available, support a 400 MHz BW in FR2 (if implemented in the UE 103), and/or support four-layer multiple input, multiple output (MIMO) functionality in high bands in FR1. In some embodiments, the UE 101 is a RedCap UE due to hardware constraints. In other embodiments, the UE 102 is a fRedCap UE due to hardware constraints. In yet other embodiments, the UE 102 includes hardware that can support RedCap UE capabilities and fRedCap UE capabilities. In one implementation in such cases, the UE 102 is configured (e.g., by a software setting) to operate as either a RedCap UE or a fRedCap UE. In other implementations, when the UE 102 camps on a cell of the RAN 105, the UE 102 determines to operate or operates as either a RedCap UE or a fRedCap UE based on system information received on the cell. In yet other implementations, the UE 102 operates as either a RedCap UE or a fRedCap UE depending on a configuration received from the RAN 105. For example, if the UE 102 receives a configuration including configuration parameters for the RedCap UE, the UE 102 operates as a RedCap UE and communicates with the RAN 105 in accordance with the configuration parameters. If the UE 102 receives a configuration including configuration parameters for the fRedCap UE, the UE 102 operates as a fRedCap UE and communicates with the RAN 105 in accordance with the configuration parameters. In some implementations, the UE 102 receives a dedicated message including the configuration from a base station (e.g., the base station 104, 106A or 106B) of the RAN 105. For example, the dedicated message is an RRC message such as an RRCReconfiguration message, an RRCSetup message or an RRCResume message. Although three UE capability types are discussed throughout this disclosure, the techniques described apply to distinguishing a larger number of UE capability types should they be defined in the future.

[0047] The base station 104 supports a cell 124, the base station 106A supports a cell 126A, and the base station 106B supports a cell 126B. The cell 124 partially overlaps with both of cells 126A and 126B, such that the UE 101, 102 or 103 can be in range to communicate with the base station 104 while simultaneously being in range to communicate with the base station 106A or 106B (or in range to detect or measure the signal from both base stations 106 A and 106B). The overlap can make it possible for the UE 101, 102 or 103 to hand over between cells (e.g., from the cell 124 to the cell 126A or 126B) or base stations (e.g., from the base station 104 to the base station 106A or base station 106B) before the UE 102 experiences radio link failure, for example. Moreover, the overlap allows the various dual connectivity (DC) scenarios discussed below. For example, the UE 103 can communicate in DC with the base station 104 (operating as an MN) and the base station 106A (operating as an SN) and, upon completing a handover to base station 106B, can communicate with the base station 106B (operating as an MN). As another example, the UE 103 can communicate in DC with the base station 104 (operating as an MN) and the base station 106 A (operating as an SN) and, upon completing an SN change, can communicate with the base station 104 (operating as an MN) and the base station 106B (operating as an SN).

[0048] More particularly, when the UE 103 is in DC with the base station 104 and the base station 106 A, 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 106A operates as a secondary gNB (SgNB) or a secondary ng-eNB (Sng-eNB).

[0049] The UE 101 or 102 can use a radio bearer (e.g., a DRB or an SRB) that terminates at a base station (e.g., the base station 104). The UE 103 can use a radio bearer (e.g., a DRB or an SRB) that at different times terminates at an MN (e.g., the base stationl04) or an SN (e.g., the base station 106A). For example, after handover or SN change to the base station 106B, the UE 101, 102 or 103 can use a radio bearer (e.g., a DRB or an SRB) that at different times terminates at the base station 106B. The UE 101, 102 or 103 can apply one or more security keys when communicating on the radio bearer, in the uplink (from the UE 101, 102 or 103 to a base station) and/or downlink (from a base station to the UE 101, 102 or 103) direction. In communication with a base station, the UE 101, 102 or 103 transmits data via the radio bearer on (z.e., within) an uplink bandwidth pail (BWP) of a cell to the base station and/or receives data via the radio bearer on a downlink BWP of the cell from the base station. The uplink BWP can be an initial uplink BWP or a dedicated uplink BWP, and the downlink BWP can be an initial DL BWP or a dedicated downlink BWP.

[0050] The base station 104 includes processing hardware 130, which can include one or more general -purpose processors (e.g., central processing units (CPUs)) and a computer-readable memory storing machine -readable instructions executable on the one or more general-purpose processor(s), and/or special-purpose processing units. The processing hardware 130 in the example implementation in Fig. 1A includes a base station communication controller 132 that is configured to communicate with normal capability UEs, RedCap UEs and/or further RedCap UEs. For example, the base station communication controller 132 can be configured to support Radio Resource Control (RRC), medium access control (MAC), and physical layer configurations, procedures, and messaging associated with handover procedures. In some implementations, the communication module 132 can be configured to communicate with normal capability UEs and support messaging associated with PSCell addition or change procedures, carrier aggregation (CA) configuration procedures, and/or to support the necessary operations.

[0051] The base station 106A includes processing hardware 140, which can include one or more general-purpose processors (e.g., CPUs) and a computer-readable memory storing machine-readable instructions executable on the general-purpose processor(s), and/or specialpurpose processing units. The processing hardware 140 in the example implementation of Fig. 1A includes a base station communication controller 142 similar to the base station communication controller 132. While not shown in Fig. 1A, the base station 106B can include processing hardware similar to the processing hardware 130 of the base station 104 or the processing hardware 140 of the base station 106A.

[0052] The UE 102 includes processing hardware 150, which can include one or more general -purpose processors (e.g., CPUs) and a computer-readable memory storing machine- readable instructions executable on the general-purpose processor(s), and/or special-purpose processing units. The processing hardware 150 in the example implementation of Fig. 1A includes a UE communication controller 152 that is configured to manage or control one or more RRC, MAC, and physical layer configurations and/or procedures in accordance with any of the implementations discussed below, when the UE 102 communicates with a base station. In some implementations, the UE 102 is a fRedCap UE and the UE communication controller 152 is implemented to support configurations and/or procedures specific for fRedCap operation. In some implementations, the UE communication controller 152 might be implemented to support neither carrier aggregation (CA) nor dual connectivity (DC).

[0053] The CN 110 can be an evolved packet core (EPC) 111 or a fifth-generation core (5GC) 160, both of which are depicted in Fig. 1A. The base station 104 can be an eNB supporting an SI interface for communicating with the EPC 111, an ng-eNB supporting an NG interface for communicating with the 5GC 160, or a gNB that supports an NR radio interface as well as an NG interface for communicating with the 5GC 160. The base station 106A can be an EUTRA- NR DC (EN-DC) gNB (en-gNB) with an SI interface to the EPC 111, an en-gNB that does not connect to the EPC 111, a gNB that supports the NR radio interface and an NG interface to the 5GC 160, or a ng-eNB that supports an EUTRA radio interface and an NG interface to the 5GC 160. To directly exchange messages with each other during the scenarios discussed below, the base stations 104, 106A, and 106B can support an X2 or Xn interface.

[0054] Among other components, the EPC 111 can 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 transfer user-plane packets related to audio 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 the UE 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 Session Management Function (SMF) 166. The UPF 162 is generally configured to transfer user-plane packets related to audio calls, video calls, Internet traffic, etc., the AMF 164 is configured to manage authentication, registration, paging, and other related functions, and the SMF 166 is configured to manage PDU sessions.

[0055] Generally, the wireless communication network 100 can include any suitable number of base stations supporting NR cells and/or EUTRA cells. More particularly, the EPC 111 or the 5GC 160 can be connected to any suitable number of base stations supporting NR cells and/or EUTRA cells. Although the examples below refer specifically to specific CN types (EPC, 5GC) and RAT types (5G NR and EUTRA), in general the techniques of this disclosure can also apply to other suitable radio access and/or core network technologies such as sixth generation (6G) radio access and/or 6G core network or 5G NR-6G DC, for example.

[0056] Fig. IB depicts an example, distributed or disaggregated implementation of any one or more of the base stations 104, 106A, 106B. In this implementation, the base station 104, 106A, or 106B includes a central unit (CU) 172 and one or more DUs 174. The CU 172 includes processing hardware, such as one or more general-purpose processors (e.g., CPUs) and a computer-readable memory storing machine-readable instructions executable on the general- purpose processor(s), and/or special-purpose processing units. For example, the CU 172 can include the processing hardware 130 or 140 of Fig. 1A.

[0057] Each of the DUs 174 also includes processing hardware that can include one or more general -purpose processors (e.g., CPUs) and computer-readable memory storing machine- readable instructions executable on the one or more general-purpose processors, and/or specialpurpose processing units. For example, the processing hardware can include a medium access control (MAC) controller configured to manage or control one or more MAC operations or procedures (e.g., a random access procedure), 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 106A) operates as an MN or an SN. The process hardware can also include a physical layer controller configured to manage or control one or more physical layer operations or procedures.

[0058] In some implementations, the CU 172 can include a logical node CU-CP 172A that hosts the control plane part of the Packet Data Convergence Protocol (PDCP) protocol of the CU 172. The CU 172 can also include logical node(s) CU-UP 172B that hosts the user plane part of the PDCP protocol and/or Service Data Adaptation Protocol (SDAP) protocol of the CU 172.

The CU-CP 172A can transmit control information (e.g., RRC messages, Fl application protocol messages), and the CU-UP 172B can transmit the data packets (e.g., SDAP PDUs or Internet Protocol packets).

[0059] The CU-CP 172A can be connected to multiple CU-UP 172B through the El interface. The CU-CP 172A selects the appropriate CU-UP 172B for the requested services for the UE 102. In some implementations, a single CU-UP 172B can be connected to multiple CU-CP 172A through the El interface. The CU-CP 172A can be connected to one or more DU 174s through an FLC interface. The CU-UP 172B can be connected to one or more DU 174 through the Fl-U interface under the control of the same CU-CP 172A. In some implementations, one DU 174 can be connected to multiple CU-UP 172B under the control of the same CU-CP 172A. In such implementations, the connectivity between a CU-UP 172B and a DU 174 is established by the CU-CP 172A using Bearer Context Management functions.

[0060] Fig. 2A illustrates, in a simplified manner, an example protocol stack 200 according to which the UE 102 can communicate with an eNB/ng-eNB or a gNB (e.g., one or more of the base stations 104, 106).

[0061] In the example stack 200, a physical layer (PHY) 202A of EUTRA provides transport channels to the EUTRA MAC sublayer 204A, which in turn provides logical channels to the EUTRA RLC sublayer 206A. The EUTRA RLC sublayer 206A in turn provides RLC channels to an EUTRA PDCP sublayer 208 and, in some eases, to 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. The NR RLC sublayer 206B in turn provides data transfer services to the NR PDCP sublayer 210. The NR PDCP sublayer 210 in turn can provide data transfer services to Service Data Adaptation Protocol (SDAP) 212 or a radio resource control (RRC) sublayer (not shown in Fig. 2A). The UE 102, in some implementations, supports both the EUTRA and the NR stack as shown in Fig. 2A, to support handover between EUTRA and NR base stations and/or to support DC over EUTRA and NR interfaces. Further, as illustrated in Fig. 2A, the UE 102 can support layering of NR PDCP 210 over EUTRA RLC 206A, and SDAP sublayer 212 over the NR PDCP sublayer 210.

[0062] The EUTRA PDCP sublayer 208 and the NR PDCP sublayer 210 receive packets (e.g., from an Internet Protocol (IP) layer, layered directly or indirectly over the PDCP layer 208 or 210) that can be referred to as service data units (SDUs), and output packets (e.g., to the RLC layer 206 A or 206B) that can be referred to as protocol data units (PDUs). Except where the difference between SDUs and PDUs is relevant, this disclosure for simplicity refers to both SDUs and PDUs as “packets.”

[0063] On a control plane, the EUTRA PDCP sublayer 208 and the NR PDCP sublayer 210 can provide signaling radio bearers (SRBs) or RRC sublayer (not shown in Fig. 2A) to exchange RRC messages or non-access-stratum (NAS) messages, for example. On a user plane, the EUTRA PDCP sublayer 208 and the NR PDCP sublayer 210 can provide DRBs to support data exchange. Data exchanged on the NR PDCP sublayer 210 can be SDAP PDUs, Internet Protocol (IP) packets or Ethernet packets.

[0064] Fig. 2B illustrates, in a simplified manner, an example protocol stack 250 which the UE 102 can communicate with a DU (e.g., DU 174) and a CU (e.g., CU 172). The radio protocol stack 200 is functionally split as shown by the radio protocol stack 250 in Fig. 2B. The CU at any of the base stations 104 or 106 can hold all the control and upper layer functionalities (e.g., RRC 214, SDAP 212, NR PDCP 210), while the lower layer operations (e.g., NR RLC 206B, NR MAC 204B, and NR PHY 202B) are delegated to the DU. To support connection to a 5GC, NR PDCP 210 provides SRBs to RRC 214, and NR PDCP 210 provides DRBs to SDAP 212 and SRBs to RRC 214. [0065] Figs. 3A-3F and 4 are messaging diagrams of example scenarios in which nodes of a RAN identify a capability type of a UE during connection establishment. UE types may correspond to different capability types of UEs. For example, this disclosure refers to RedCap UEs as a first UE type, and fRedCap UEs as a second UE type. Although two UE capability types are discussed throughout this disclosure, the techniques described apply to distinguishing a larger number of UE capability types should they be defined in the future. Generally speaking, events in Figs. 3A-3F that are identical are labeled with the same reference numbers. Events in Figs. 3A-3F and 4 that are similar are labeled with similar reference numbers (e.g., event 302 is similar’ to event 402, etc.), with differences discussed below where appropriate. With the exception of the differences shown in the figures and discussed below, any of the alternative implementations discussed with respect to a particular event (e.g., for messaging and processing) may apply to events labeled with similar reference numbers in other figures.

[0066] Turning first to Fig. 3A, in a scenario 300A, the base station 104 includes a CU 172 and a DU 174. In some implementations, initially, the DU 174 initiates an Fl setup procedure with the CU 172 by transmitting 302 an Fl Setup Request message to the DU 174. In response, the CU 172 transmits 304 an Fl Setup Response message to the DU 174. Depending on the implementation, the DU 174 includes DU configuration information for one or more cells in the Fl Setup Request message. In some implementations, the DU configuration information includes reduced capability (RedCap) information, further reduced capability (fRedCap) information, System Information IE(s), and/or slice supporting information, as described below. In some implementations, the CU 172 includes CU configuration information for one or more cells in the Fl Setup Response message. The Fl Setup Request and the Fl Setup Response message are non-UE associated signaling messages.

[0067] In some implementations, the DU 174 includes RedCap information (e.g., an information element (IE)) in the Fl Setup Request message. In some implementations, the DU 174 configures the RedCap information for a corresponding cell operated by the DU 174, and the RedCap information indicates whether RedCap UEs are allowed to access the corresponding cell. In some implementations, the RedCap UEs include different types of RedCap UEs, such as RedCap UEs with one receiving chain or antenna, RedCap UEs with two receiving chains or antennas, and RedCap UEs that support half-duplex operation. In some implementations, the RedCap information indicates which types of RedCap UEs have access to the corresponding cell. In some implementations, the CU 172 uses the RedCap information to determine that the corresponding cell is a suitable target cell in case of subsequent outgoing mobility involving RedCap UEs. In some implementations, the RedCap information is a RedCap Broadcast Information IE. In other implementations, the DU 174 includes the RedCap information in a RedCap Broadcast Information IE in the Fl Setup Request message. In some implementations, DU 174 includes multiple sets of RedCap information, one for each corresponding cell in the Fl Setup Request message. In some implementations, the multiple sets of RedCap information have the same content or different contents. In some implementations, the RedCap UEs are particular RedCap UEs that support particular RedCap functionalities (e.g., RedCap UEs that support RedCap functionalities defined according to 3GPP standards).

[0068] In some implementations, the DU 174 includes fRedCap information (e.g., an information element (IE)) in the Fl Setup Request message. In some implementations, the DU 174 configures the fRedCap information for a corresponding cell operated by the DU 174, and the fRedCap information indicates whether fRedCap UEs are allowed to access the corresponding cell. In some implementations, the fRedCap UEs include different types of fRedCap UEs, such as fRedCap UEs with one receiving chain or antenna, fRedCap UEs with two receiving chains or antennas, and fRedCap UEs that support half-duplex operation. In some implementations, the fRedCap information indicates which types of fRedCap UEs have access to the corresponding cell. In some implementations, the CU 172 uses the fRedCap information to determine that the corresponding cell is a suitable target cell in case of subsequent outgoing mobility involving fRedCap UEs. In some implementations, the fRedCap information is a fRedCap Broadcast Information IE different from a RedCap Broadcast Information IE. In other implementations, the DU 174 includes the fRedCap information in a RedCap Broadcast Information IE in the Fl Setup Request message. In such cases, the DU 174 includes RedCap information and fRedCap information in a RedCap Broadcast Information IE for the corresponding cell in the Fl Setup Request message. In some implementations, the DU 174 includes multiple sets of fRedCap information, one for each corresponding cell in the Fl Setup Request message. In some implementations, the multiple sets of fRedCap information have the same content or different contents. In some implementations, the fRedCap UEs are particular fRedCap UEs that support particular fRedCap functionalities (e.g., fRedCap UEs that support fRedCap functionalities defined according to 3GPP standards).

[0069] In some implementations, in the Fl Setup Request message, the DU 174 includes a System Information IE for a cell operated by the DU 174. In some implementations, the System Information IE includes a master information block (MIB) and/or one or more system information blocks (SIB(s)). In some implementations, the DU 174 configures the MIB and SIB(s) for normal-capability UEs, RedCap UEs, and/or fRedCap UEs. In other implementations, in the Fl Setup Request message, the DU 174 includes a first System Information IE and a second System Information IE for a cell operated by the DU 174. In some implementations, the first System Information IE includes an MIB and/or SIB(s) for normal-capability UEs, and the second System Information IE includes an MIB and/or SIB(s) for RedCap UEs and/or fRedCap UEs. In yet other implementations, in the Fl Setup Request message, the DU 174 includes a first System Information IE, a second System Information IE, and a third System Information IE for a cell operated by the DU 174. In some implementations, the first System Information IE includes an MIB and/or SIB(s) for normal-capability UEs, the second System Information IE includes an MIB and/or SIB(s) for RedCap UEs, and/or the third System Information IE includes an MIB and SIB(s) for fRedCap UEs. In some implementations, the SIB(s) above include an SIB1, an SIB 17, and/or an SIB 20.

[0070] In some implementations, in the Fl Setup Request message, the DU 174 includes slice supporting information (e.g., an IE) for a corresponding cell operated by the DU 174. The slice supporting information indicates one or more slices supported on the corresponding cell for normal-capability UEs, RedCap UEs, and/or fRedCap UEs. In other implementations, in the Fl Setup Request message, the DU 174 includes first slice supporting information (e.g., an IE) and second slice supporting information (e.g., an IE) for a corresponding cell operated by the DU 174. The first slice supporting information indicates one or more slices supported on the corresponding cell for normal-capability UEs, and the second slice supporting information indicates one or more slices supported on the corresponding cell for RedCap UEs and/or fRedCap UEs. In yet other implementations, in the Fl Setup Request message, the DU 174 includes first slice supporting information (e.g., an IE), second slice supporting information (e.g., an IE), and third slice supporting information (e.g., an IE) for a corresponding cell operated by the DU 174. The first slice supporting information indicates one or more slices supported on the corresponding cell for normal-capability UEs, the second slice supporting information indicates one or more slices supported on the corresponding cell for RedCap UEs, and the third slice supporting information indicates one or more slices supported on the corresponding cell for fRedCap UEs.

[0071] In some implementations, the CU configuration information includes SIB(s). For example, the SIB(s) include SIB2, SIB3, SIB4, SIB5, SIB6, SIB7, SIB8, and/or SIB9. In some implementations, the CU configuration information for each cell is different.

[0072] In some implementations, the DU 174 initiates a DU configuration update procedure with the CU 172 to update at least a portion of the DU configuration information. Upon initiating the DU configuration update procedure, the DU 174 transmits 306 a DU Configuration Update message, including new DU configuration information, to the CU 172 to update the DU configuration information included in the Fl Setup Request message. In some implementations, the new DU configuration information includes new RedCap information, new fRedCap information, new System Information IE(s), and/or new slice supporting information. In response to the DU Configuration Update message, the CU 172 transmits 308 a DU Configuration Update Acknowledge message to the DU 174. In some implementations, the CU 172 includes new CU configuration information for one or more cells in the DU Configuration Update Acknowledge message to update the CU configuration information in the Fl Setup Response message. In some alternative implementations, the DU 174 transmits 306 a DU Configuration Update message to the CU 172 to include the DU configuration information or at least a portion of the DU configuration information instead of the Fl Setup Request message. In some implementations, the CU 172 includes the CU configuration information for one or more cells in the DU Configuration Update Acknowledge message, as described for the Fl Setup Response message. The DU Configuration Update message and the DU Configuration Update Acknowledge message are non-UE associated signaling messages.

[0073] In some implementations, the DU 174 performs separate procedures with the CU 172 to transmit, to the CU 172, different configuration information for normal-capability UEs, RedCap UEs, and/or fRedCap UEs. For example, the DU 174 performs a first procedure with the CU 172 by transmitting a first message including first configuration information for normal- capability UEs to the CU 172. In response, the CU 172 transmits a second message to the DU 174. The DU 174 performs a second procedure with the CU 172 by transmitting a third message including second configuration information for RedCap UEs and/or fRedCap UEs to the CU 172. In response, the CU 172 transmits a fourth message to the DU 174. In some alternative implementations, the DU 174 performs a second procedure with the CU 172 by transmitting a third message including second configuration information for RedCap UEs, to the CU 172, and performs a third procedure with the CU 172 by transmitting a fifth message including third configuration information for fRedCap UEs to the CU 172. In some implementations, the CU 172 transmits a fourth message and a sixth message to the DU 174 in response to the third message and the fifth message, respectively. In some implementations, the procedures include Fl setup procedures and/or DU configuration update procedures. In cases where the procedures are Fl setup procedures, the first message, the third message, and/or the fifth message arc Fl Setup Request messages, and the second message, the fourth message, and/or the sixth message arc Fl Setup Response messages. In cases where the procedures arc DU configuration update procedures, the first message, the third message, and/or the fifth message arc Fl Setup Request messages, and the second message, the fourth message, and/or the sixth message are Fl Setup Response messages.

[0074] The DU 174 periodically transmits (e.g., broadcast) 312 system information on a cell (e.g., cell 124). In some implementations, the system information includes an MIB and SIB(s). In some implementations, the DU 174 periodically transmits 312 the system information after performing the Fl setup procedure and/or the DU configuration update procedure. In further implementations, the DU 174 transmits the MIB and the SIB((s) to the CU 172 as described above.

[0075] In some implementations, the UE 102 initially operates 310 in an idle state (e.g., the RRC_IDLE state), an inactive state (e.g., the RRC_INACTIVE state), a connected state (e.g., the RRC_CONNECTED state) with a failure (e.g., radio link failure), or, more generally, in a state in which there is no active radio connection between the UE 102 and the base station 104.

[0076] The UE 102 initiates a procedure to establish or restore a radio connection with the base station 104. In particular, in some implementations, the UE 102 performs a random access procedure with the DU 174. Depending on the implementation, the random access procedure is a two-step or a four-step procedure. In a four-step procedure between a UE and a DU, the UE 102 transmits 314 a random access (RA) preamble, which is also referred to as “Msgl,” to the DU 174 (step 1); the DU 174 transmits 316 a random access response (RAR), or “Msg2,” to the UE 102 (step 2); the UE 102 transmits 318 a scheduled transmission, or “Msg3,” to the DU 174 (step 3); and the DU 174 transmits a contention resolution, or “Msg4,” to the UE 102 (step 4). The scheduled transmission includes a UL MAC PDU that includes a logical channel identity (LCID) and an RRC request. In a two-step procedure, the UE 102 transmits 314 an RA preamble and 318 a payload, or “MsgA,” to the DU 174 (step 1), and the DU 174 transmits a contention resolution, or “MsgB,” to the UE 102 (step 2). More particularly, the MsgA includes two parts sent on different occasions: the RA preamble transmitted via a PRACH occasion (e.g., similar to Msgl of the four-step procedure), and the payload transmitted via a PUSCH occasion (e.g., similar to Msg3 of the four-step procedure). The payload includes a UL MAC PDU that includes an LCID and an RRC request. In some implementations, the LCID identifies a UL logical channel where the RRC request belongs. For example, the UL logical channel is a UL common control channel (CCCH).

[0077] In some implementations, if the UE 102 operates 310 in an idle or an inactive state, the RRC request message signals a transition to a connected state (e.g., an RRCSetupRequest message or an RRCResumeRequesl message). In further implementations, if the UE 102 operates 310 in a connected state, the RRC request message instructs recovery of a radio link failure or other failure (e.g., an RRCReestablishmentRequest message). In some implementations, the UE 102 generates a UL-CCCH-Message message, including the RRC request message, and includes the UL-CCCH-Message message in the UL MAC PDU 318. In other implementations, the UE 102 generates a UL-CCCH1 -Message message, including the RRC request message, and includes the UL-CCCH1 -Message message in the UL MAC PDU 318. In the description herein, in some implementations, the RRC request message is equivalent to the UL-CCCH-Message message or the UL-CCCHl-Message message.

[0078] When the DU 174 receives 318 the UL MAC PDU, the DU 174 retrieves the LCID and the RRC request from the UL MAC PDU. In some implementations, the DU 174 determines 320 a UE type of the UE 102 based on the LCID. For example, if the LCID is a first value, the DU 174 determines 320 that the UE 102 is a first UE type (e.g., a RedCap UE). If the LCID is a second value, the DU 174 determines 320 that the UE 102 is a second UE type (e.g., a fRedCap UE). If the LCID is a third value, the DU 174 determines 320 that the UE 102 is a third UE type (e.g., a normal capability UE). When the UE 102 is a fRedCap UE, the UE 102 sets the LCID to the second value and includes the LCID in the UL MAC PDU. Therefore, the DU 174 determines 320 that the DU 102 is the second UE type.

[0079] After determining that the UE 102 is the second UE type, the DU 174 transmits 322 a DU-to-CU message to the CU 172, including the RRC request and an indication of the first UE type instead of an indication of the second UE type. In some implementations, the DU-to-CU message is an Initial UL RRC Message Transfer message. If the DU 174 determines 320 that the UE 102 is the first UE type, the DU 174 transmits 322 the DU-to-CU message to the CU 172. When the CU 172 receives 322 the DU-to-CU message, the CU 172 determines 324 that the UE 102 is the first UE type based on the indication. There are some benefits to the DU 174 using the same indication for UEs of the first UE type and for UEs of the second UE type. First, using the same indication simplifies UE handling in the CU 172. That is, the CU 172 manages UEs of the first UE type and UEs of the second UE type in the same way. Second, when the first UE type is a RedCap UE, the indication of the RedCap UE has been defined (e.g., in 3GPP Release 17). Thus, there is no need to define a new indication for the fRedCap UE in the DU-to-CU message (e.g., in 3GPP Release 18). Thus, the CU 172 does not need to be updated to support fRedCap UEs.

[0080] In some implementations, the CU 172 transmits a BS-to-CN message to a CN (e.g., the CN 110) or an AMF (e.g., the AMF 164), including an indication of the first UE type for the UE 102. Thus, in some such implementations, the CN 110 determines that the UE 102 is the first UE type, based on the indication of the first UE type. In some implementations, the CN 110 applies a charging policy or rate for the first UE type for the UE 102 to charge data traffic communicated with the UE 102 based on the indication or determination. In some such cases, the CN 110 applies the same charging policy or rate for the first UE type and the second UE type, and applies a different charging policy or rate for the third UE type. In some implementations, the BS-to-CN message is an Initial UE Message message. In some implementations, the AMF 164 transmits a message including an indication of the first UE type to an SMF (e.g., the SMF 166) after receiving the BS-to-CN message. Thus, in some such implementations, the SMF 166 takes proper handlings for the UE 102, based on the indication of the first UE type.

[0081] In some implementations, if the DU 174 determines 320 that the UE 102 is the third UE type, the DU 174 refrains from including an indication of a UE type in the DU-to-CU message 322. In further implementations, if the DU 174 determines 320 that the UE 102 is the third UE type, the DU 174 includes an indication of the third UE type in the DU-to-CU message 322.

[0082] In response to the RRC request message, the CU 172 transmits generates an RRC response message for the UE 102 and transmits 326 a CU-to-DU message including the RRC response message to the DU 174. In turn, the DU 174 transmits 328 the RRC response message to the UE 102. In some implementations, the DU 174 includes an LCID and the RRC response message in a DL MAC PDU and transmits 328 the DL MAC PDU to the UE 102. In some implementations, the LCID identifies a DL logical channel where the RRC response message belongs. For example, the DL logical channel is a DL common control channel (CCCH). In some implementations, the CU 172 generates a DL-CCCH-Message message, including the RRC response message, and includes the DL-CCCH-Message message in the DL MAC PDU 328. In the description herein, in some implementations, the RRC response message is equivalent to the DL-CCCH-Message message.

[0083] In some implementations, the RRC response message 326, 328 is an RRCSetup message, an RRCResume message, or an RRCReestablishment message, depending on whether the RRC request message 318 is an RRCSetupRequest message, an RRCResumeRequest message, or an RRCReestablishmentRequest message. In some implementations, the RRC response message 328 is an RRC reject message (e.g., an RRCReject message) in response to an RRCSetupRequest message or an RRCResumeRequest message. In some implementations, if the RRC response message is neither an RRC reject message nor an RRC release message, the UE 102 transitions 330 to the connected state and transmits 332 an RRC complete message to the DU 174 in response to the RRC response message. In turn, the DU 174 transmits 334 the RRC complete message to the CU 172. Depending on the implementation, the RRC complete message is an RRCSetupComplete message, an RRCResumeComplete message, or an RRCReestablishmentComplete message, in accordance with the RRC response message 328. [0084] In some implementations, the UE 102 includes an LCID and the RRC complete message in a UL MAC PDU and transmits 332 the UL MAC PDU to the DU 174. In some implementations, the LCID identifies a UL logical channel where the RRC complete message belongs. Lor example, the UL logical channel is a UL Dedicated Control Channel (DCCH). The DU 174 retrieves the LCID and the RRC complete message from the UL MAC PDU 332 and transmits 324 a DU-to-CU message including the RRC complete message to the CU 172. In some implementations, the UE 102 generates a UL-DCCH-Message message including the RRC complete message, generates a UL PDCP PDU including the UL-CCCH-Message message, generates a UL RLC PDU including the UL PDCP PDU, and includes the UL RLC PDU in the UL MAC PDU 332. In the description herein, in some implementations, the RRC complete message is equivalent to the UL-DCCH-Message message.

[0085] In some implementations, if the RRC response message is an RRC reject message or an RRC release message, the UE 102 stays in the original state as event 310 and refrains from transmitting an RRC complete message to the base station 104.

[0086] In some implementations, after identifying 320 the UE 102 as the second UE type, the DU 174 includes, in the DU-to-CU message 322, configuration parameters (e.g., a cell group configuration) that the second UE type supports for the UE 102. The CU 172 includes the configuration parameters in the RRC response message. In some implementations, if the DU 174 determines that that the UE 102 is the first UE type, the DU 174 still includes, in the DU-to- CU message 322, configuration parameters that the second UE type supports for the UE 102. In such cases, the DU 174 unifies configurations of the first UE type and the second UE type. In further implementations, if the DU 174 determines that the UE 102 is the first UE type, the DU 174 includes, in the DU-to-CU message 322, configuration parameters (e.g., a cell group configuration) that the first UE type supports for the UE 102. In some implementations, if the DU 174 determines that the UE 102 is the third UE type, the DU 174 includes, in the DU-to-CU message 322, configuration parameters (e.g., a cell group configuration) that the third UE type supports for the UE 102.

[0087] In some implementations, the DU 174 generates first downlink control information (DCI), including parameters that a UE is to use for receiving downlink transmissions and transmitting uplink transmissions. In some implementations, based on the determination 320, the DU 174 generates the parameters conforming to predetermined capabilities for the second UE type. The DU 174 transmits the first DCI to the UE 102 before transmitting 328 the DL MAC PDU, such that, in some implementations, the UE 102 configures itself to receive 328 the DL MAC PDU in accordance with the first DCI. Likewise, in further implementations, if the DU 174 determines that the UE 102 is the first UE type, the DU 174 generates a second DCI for the UE 102 that includes parameters that the first UE type supports. In some implementations, the base station 104 transmits the second DCI to the UE 102 before transmitting 328 the DL MAC PDU. Alternatively, if the DU 174 determines that the UE 102 is the first UE type, the DU 174 generates a second DCI for the UE 102 that includes parameters that the second UE type supports, similar to the first DCI. The base station 104 in some implementations transmits the second DCI to the UE 102 before transmitting 328 the DL MAC PDU. Likewise, in further implementations, if the DU 174 determines that the UE 102 is the third UE type, the DU 174 generates a third DCI for the UE 102 that includes parameters that the third UE type supports. In some implementations, the base station 104 transmits the third DCI to the UE 102 before transmitting 328 the DL MAC PDU.

[0088] In some cases regarding the first DCI, the DU 174 includes, in the first DCI, parameters scheduling a PDSCH transmission to the UE 102, where the PDSCH transmission includes the DL MAC PDU 328. In some implementations, the parameters include a first time domain resource assignment field and/or a first frequency domain resource assignment field for the PDSCH transmission. In some implementations, the DU 174 sets the first time domain resource assignment field to a first value conforming to one or more predetermined capabilities for the second UE type. In further implementations, the DU 174 sets the first time domain resource assignment field to a first predetermined value. In some implementations, the DU 174 sets the first frequency domain resource assignment field to a first value conforming to the one or more predetermined capabilities for the second UE type. In further implementations, the DU 174 sets the first frequency domain resource assignment field to a first predetermined value. In such implementations, the UE 102 receives the PDSCH transmission at time domain resources (e.g., symbols) in accordance with the first time domain resource assignment field, and/or in frequency domain resources in accordance with the first frequency domain resource assignment field. [0089] In some implementations, the DU 174 includes a first PDSCH-to-HARQ feedback timing indicator in the first DO. In some implementations, the DU 174 sets the first PDSCH-to- HARQ feedback timing indicator to a first value conforming to the one or more predetermined capabilities for the second UE type. Thus, in some such implementations, the UE 102 transmits a HARQ feedback in accordance with the first value. In further implementations, the DU 174 sets the first PDSCH-to-HARQ feedback timing indicator to a predetermined value. Depending on the implementation, the HARQ feedback is a HARQ acknowledgement or a HARQ negative acknowledgement.

[0090] In some cases regarding the second DCI, the DU 174 includes, in the second DCI, parameters scheduling a PDSCH transmission to the UE 102, where the PDSCH transmission includes the DL MAC PDU 328. In some implementations, the parameters include a second time domain resource assignment field and/or a second frequency domain resource assignment field for the PDSCH transmission. In some implementations, the DU 174 sets the second time domain resource assignment field to a second value conforming to the one or more predetermined capabilities for the first UE type. In further implementations, the DU 174 sets the second time domain resource assignment field to a second predetermined value. In still further implementations, the DU 174 sets the second time domain resource assignment field to the same value as the first time domain resource assignment field. In some implementations, the DU 174 sets the second frequency domain resource assignment field to a second value conforming to the one or more predetermined capabilities for the first UE type. In further implementations, the DU 174 sets the second frequency domain resource assignment field to a second predetermined value. In still further implementations, the DU 174 sets the second frequency domain resource assignment field to the same value as the first time domain resource assignment field. In such implementations, the UE 102 (e.g., in cases for the first UE type) receives the PDSCH transmission at time domain resources (e.g., symbols) in accordance with the second time domain resource assignment field, and/or in frequency domain resources in accordance with the second frequency domain resource assignment field.

[0091] In some implementations, the DU 174 includes a second PDSCH-to-HARQ feedback timing indicator in the second DCI. In some implementations, the DU 174 sets the second PDSCH-to-HARQ feedback timing indicator to a second value conforming to the one or more predetermined normal capabilities. For example, the second value corresponds to an earlier time resource compared to the first PDSCH-to-HARQ feedback timing indicator because the first UE type is capable of processing the PDSCH transmission more quickly than the second UE type. In some implementations, the UE 102 (e.g., in cases for the second UE type) transmits a HARQ feedback in accordance with the second value. In further implementations, the DU 174 sets the second PDSCH-to-HARQ feedback timing indicator to the same value as the first PDSCH-to- HARQ feedback timing indicator. Depending on the implementation, the HARQ feedback is a HARQ acknowledgement or a HARQ negative acknowledgement.

[0092] In some cases regarding the third DCI, the DU 174 includes, in the third DCI, parameters scheduling a PDSCH transmission to the UE 102 (e.g., in cases for the third UE type), where the PDSCH transmission includes the DL MAC PDU 328. In some implementations, the parameters include a third time domain resource assignment field and/or a third frequency domain resource assignment field for the PDSCH transmission. In some implementations, the DU 174 sets the third time domain resource assignment field to a third value conforming to the one or more predetermined capabilities for the third UE type. In further implementations, the DU 174 sets the third time domain resource assignment field to a third predetermined value. In still further implementations, the DU 174 sets the third time domain resource assignment field to the same value as the first or second time domain resource assignment field. In some implementations, the DU 174 sets the third frequency domain resource assignment field to a third value conforming to the one or more predetermined capabilities for the third UE type. In further implementations, the DU 174 sets the third frequency domain resource assignment field to a third predetermined value. In still further implementations, the DU 174 sets the third frequency domain resource assignment field to the same value as the first or second time domain resource assignment field. In such implementations, the UE 102 (e.g., in cases for the third UE type) receives the PDSCH transmission at time domain resources (e.g., symbols) in accordance with the third time domain resource assignment field, and/or in frequency domain resources in accordance with the third frequency domain resource assignment field.

[0093] In some implementations, the DU 174 includes a third PDSCH-to-HARQ feedback timing indicator in the third DCI. In some implementations, the DU 174 sets the third PDSCH- to-HARQ feedback timing indicator to a third value conforming to the one or more predetermined capabilities for the third UE type. For example, the third value corresponds to an earlier time resource compared to the first or second PDSCH-to-HARQ feedback timing indicator because the third UE type is capable of processing the PDSCH transmission more quickly than the first or second UE type. In some implementations, the UE 102 (e.g., in some cases for the third UE type) transmits a HARQ feedback in accordance with the third value. In further implementations, the DU 174 sets the third PDSCH-to-HARQ feedback timing indicator the same value as the first or second PDSCH-to-HARQ feedback timing indicator. Depending on the implementation, the HARQ feedback is a HARQ acknowledgement or a HARQ negative acknowledgement.

[0094] In some implementations, the DU 174 transmits the first DCI on a time and frequency resource. Depending on the implementation, the time and frequency resource is on a first control resource set (CORESET) or a first search space. In some implementations, the DU 174 broadcasts a first SIB on the cell, including first configuration parameters configuring the first CORESET or first search space for the second UE type. The UE 102 (e.g., in cases for the second UE type) receives the first SIB and receives the first DCI on the time and frequency resource on the first CORESET or first search space in accordance with the first configuration parameters.

[0095] In other implementations, the DU 174 transmits the second DCI on a time and frequency resource. In some implementations, the time and frequency resource is on a second CORESET or a second search space. In some implementations, the DU 174 broadcasts a second SIB on the cell, including second configuration parameters configuring the second CORESET or second search space for the first UE type. The UE 102 (e.g., in cases for the first UE type) receives the second SIB and receives the second DCI on the time and frequency resource on the second CORESET or second search space in accordance with the second configuration parameters. Alternatively, the DU 174 transmits the second DCI on the first CORESET or first search space, such as in cases where the DU 174 configures the first CORESET or first search space for both the first UE type and second UE type.

[0096] In yet other implementations, the DU 174 transmits the third DCI on a time and frequency resource. In some implementations, the time and frequency resource is on a third CORESET or a third search space. In some implementations, the DU 174 broadcasts a third SIB on the cell, including third configuration parameters configuring the third CORESET or third search space for the third UE type. The UE 102 (e.g., in cases for the third UE type) receives the third SIB and receives the third DCI on the time and frequency resource on the third CORESET or third search space in accordance with the third configuration parameters. Alternatively, the DU 174 transmits the third DCI on the second CORESET or second search space, such as in cases where the DU 174 configures the second CORESET or second search space for both the first UE type and third UE type.

[0097] In some implementations, the first, second, and/or third SIBs are the same SIB or different SIBs. In some implementations, the first, second, and/or third CORESETs are the same CORESET or different CORESETs. In some implementations, the first, second, and/or third search spaces are the same search space or different search spaces.

[0098] In some implementations, the DU 174 broadcasts an SIB on the cell, including a first PUCCH configuration (e.g., PUCCH-ConfigCommon IE) that configures PUCCH resource(s) for UEs of the second UE type. The UE 102 (e.g., in cases for the second UE type) transmits the HARQ feedback on a first PUCCH resource configured by the first PUCCH configuration. In some implementations, the UE 102 determines the first PUCCH resource based on a PUCCH resource indicator in the first DCI. Depending on the implementation, the SIB is an SIB1 or an SIB described above.

[0099] In some implementations, the DU 174 configures the first PUCCH configuration for UEs of the first UE type. The UE 102 (e.g., in cases for the first UE type) transmits the HARQ feedback on a first PUCCH resource configured by the first PUCCH configuration. In some implementations, the UE 102 determines the first PUCCH resource based on a PUCCH resource indicator in the second DCI. In some alternative implementations, the DU 174 broadcasts an SIB on the cell, including a second PUCCH configuration (e.g., PUCCH-ConfigCommon IE) that configures PUCCH resource(s) for UEs of the first UE type. The UE 102 (e.g., in cases for the first UE type) transmits the HARQ feedback on a second PUCCH resource configured by the second PUCCH configuration. In some implementations, the UE 102 determines the second PUCCH resource based on a PUCCH resource indicator in the second DCI. Depending on the implementation, the SIB is an SIB1 or an SIB described above. [0100] In some implementations, the DU 174 broadcasts an SIB on the cell, including a third PUCCH configuration (e.g., PUCCH-ConfigCommon IE) that configures PUCCH resource(s) for UEs of the third type. The UE 102 (e.g., in cases for the third UE type) transmits the HARQ feedback on a third PUCCH resource configured by the third PUCCH configuration. In some implementations, the UE 102 determines the third PUCCH resource according to a PUCCH resource indicator in third DCI. Depending on the implementation, the SIB is an SIB 1 or an SIB described above.

[0101] In some implementations, the PUCCH resource(s) configured in the first, second, and/or third PUCCH configurations are exclusive. In other implementations, one or more of the PUCCH resource(s) configured in the first, second, and/or third PUCCH configurations are the same. Depending on the implementation, the remainder in the first, second, and/or third PUCCH configurations is the same or different. In such cases, the DU 174 does not configure more than one UE to transmit HARQ feedback on the same PUCCH resource in the same time instance.

[0102] In other implementations, the base station 104 broadcasts an SIB including a PUCCH configuration (e.g., PUCCH-ConfigCommon IE) that configures PUCCH resource(s) for UEs of the first UE type, the second UE type, and the third UE type. In such cases, the DU 174 does not configure more than one UE to transmit HARQ feedback on the same PUCCH resource in the same time instance. The UE 102 transmits the HARQ feedback on a PUCCH resource configured by the PUCCH configuration. In some implementations, the UE 102 determines the PUCCH resource according to a PUCCH resource indicator in first DCI. Depending on the implementation, the SIB is an SIB1 or an SIB described above.

[0103] In some implementations, the DU 174 configures a DL bandwidth part (BWP) and a UL BWP of the cell for communication with UEs of the first UE type, the second UE type, or the third UE type. In some implementations, the DU 174 broadcasts an SIB on the cell, including a DL BWP configuration and a UL BWP configuration configuring the DL BWP and the UL BWP, respectively. Depending on the implementation, the SIB is an SIB1 or an SIB described above. In other implementations, the DU 174 transmits an RRC reconfiguration message to each UE, including a DL BWP configuration and a UL BWP configuration configuring the DL BWP and the UL BWP, respectively. The DU 174 communicates with UEs of the first, second, and/or third UE type on the cell via the DL BWP and UL BWP. [0104] In other implementations, the DU 174 configures a first DL BWP and a first UL BWP of the cell for UEs of the first UE type and the second UE type, and configures a second DL BWP and a second UL BWP of the cell for UEs of the third UE type. In some implementations, the DU 174 broadcasts a first SIB on the cell, including a first DL BWP configuration and a first UL BWP configuration configuring the first DL BWP and the first UL BWP, respectively. Depending on the implementation, the first SIB is an SIB 1 or another SIB described above. In some implementations, the DU 174 broadcasts a second SIB on the first cell, including a second DL BWP configuration and a second UL BWP configuration configuring the second DL BWP and the second UL BWP, respectively. Depending on the implementation, the second SIB is an SIB1 or another SIB described above. In some implementations, the first SIB and the second SIB are the same SIB (e.g., the same instance or different instances) or different SIBs. In other implementations, the DU 174 transmits an RRC reconfiguration message to each UE of the first UE type or the second UE type, including a first DL BWP configuration and a first UL BWP configuration configuring the first DL BWP and the first UL BWP, respectively. In other implementations, the DU 174 transmits an RRC reconfiguration message to each UE of the third UE type, including a second DL BWP configuration and a second UL BWP configuration configuring the second DL BWP and the second UL BWP, respectively. The DU 174 communicates with UEs of the first UE type and/or second UE type on the cell, via the first DL BWP and first UL BWP, and communicates with UEs of the third UE type via the second DL BWP and second UL BWP.

[0105] In yet other implementations, the DU 174 configures a first DL BWP and a first UL BWP of the cell for UEs of the first UE type, configures a second DL BWP and a second UL BWP for UEs of the second UE type, and configures a third DL BWP and a third UL BWP of the cell for UEs of the third UE type. In some implementations, the DU 174 broadcasts a first SIB on the cell, including a first DL BWP configuration and a first UL BWP configuration configuring the first DL BWP and the first UL BWP, respectively. Depending on the implementation, the first SIB is an SIB 1 or another SIB described above. In some implementations, the DU 174 broadcasts a second SIB on the first cell, including a second DL BWP configuration and a second UL BWP configuration configuring the second DL BWP and the second UL BWP, respectively. Depending on the implementation, the second SIB is an SIB1 or another SIB described above. In some implementations, the DU 174 broadcasts a third SIB on the first cell, including a third DL BWP configuration and a third UL BWP configuration configuring the third DL BWP and the third UL BWP, respectively. Depending on the implementation, the third SIB is an SIB 1 or another SIB described above. In some implementations, the first SIB, the second SIB, and the third SIB are the same SIB (e.g., the same instance or different instances) or different SIBs. In other implementations, the DU 174 transmits an RRC reconfiguration message to each UE of the second UE type, including a first DL BWP configuration and a first UL BWP configuration configuring the first DL BWP and the first UL BWP, respectively. In other implementations, the DU 174 transmits an RRC reconfiguration message to each UE of the first UE type, including a second DL BWP configuration and a second UL BWP configuration configuring the second DL BWP and the second UL BWP, respectively. In other implementations, the DU 174 transmits an RRC reconfiguration message to each UE of the third UE type, including a third DL BWP configuration and a third UL BWP configuration configuring the third DL BWP and the third UL BWP, respectively. The DU 174 communicates with UEs of the second UE type on the cell via the first DL BWP and first UL BWP, communicates with UEs of the first UE type on the cell via the second DL BWP and second UL BWP, and communicates with UEs of the third UE type via the third DL BWP and third UL BWP.

[0106] The events 314, 316, 318, 320, 322, 324, 326, 328, 330, 332, and 334 are collectively referred to in Fig. 3A as a connection establishment procedure or a connection resume procedure 390A.

[0107] Fig. 3B illustrates a scenario 300B similar to the scenario 300A of Fig. 3A, except that the scenario 300B includes events 323 and 325 instead of events 322 and 324. In the scenario 300B, the DU 174 transmits 323 a DU-to-CU message, including the RRC request message and an indication of the second UE type, to the CU 172. The DU-to-CU message 323 is similar to the DU-to-CU message 322 except that the DU-to-CU message 323 includes the indication of the second UE type instead of the indication of the first UE type. Thus, the CU 172 determines 325 that the UE 102 is the second UE type, based on the indication of the second UE type. Thus, the CU 172 takes proper handlings for the UE 102, based on the indication of the second UE type.

[0108] In some implementations, the CU 172 transmits a BS-to-CN message to a CN (e.g., the CN 110) or an AMF (e.g., the AMF 164), including an indication of the second UE type for the UE 102. Thus, in some implementations, the CN 110 determines that the UE 102 is the second UE type, based on the indication of the second UE type. In some implementations, the CN 110 applies a charging policy or rate for the second UE type for the UE 102 to charge data traffic communicated with the UE 102 based on the indication or determination. In some such cases, the CN 110 applies different charging policies or rates for the first UE type, the second UE type, and/or the third UE type. In some implementations, the BS-to-CN message is an Initial UE Message message. In some implementations, the AMF 164 transmits a message including an indication of the second UE type to an SMF (e.g., the SMF 166) after receiving the BS-to-CN message. Thus, in some implementations, the SMF 166 takes proper handlings for the UE 102 based on the indication of the second UE type.

[0109] The events 314, 316, 318, 320, 323, 325, 326, 328, 330, 332, and 334 are collectively referred to in Fig. 3B as a connection establishment procedure or a connection resume procedure 390B.

[0110] Turning to Fig. 3C, a scenario 300C is similar to the scenarios 300A and 300B, except that the scenario 300C includes event 321 instead of event 320. In the scenario 300C, the DU 174 determines 321 that the UE 102 is the second UE type when (i) the RA preamble 314 is configured specifically for the second UE type or (ii) the DU 174 receives 314 the RA preamble on time and frequency resources particularly configured for the second UE type. Based on the determination, the DU 174 transmits 322 the DU-to-CU message, including the RRC request message and the indication of the first UE type, to the CU 172.

[0111] In some implementations, if the DU 174 receives, from a UE, an RA preamble not configured specifically for the second UE type (e.g., the RA preamble is configured for the first UE type or the third UE type), the DU 174 determines that the UE is the first UE type or the third UE type.

[0112] The events 314, 316, 318, 321, 322, 324, 326, 328, 330, 332, and 334 are collectively referred to in Fig. 3C as a connection establishment procedure or a connection resume procedure 390C.

[0113] Turning to Fig. 3D, a scenario 300D is similar to the scenarios 300A-C. In the scenario 300D, based on the determination 321, the DU 174 transmits 323 the DU-to-CU message, including the RRC request message and the indication of the second UE type, to the CU 172. The events 314, 316, 318, 321, 323, 325, 326, 328, 330, 332, and 334 are collectively referred to in Fig. 3D as a connection establishment procedure or a connection resume procedure 390D.

[0114] Turning to Fig. 3E, a scenario 300E is similar to the scenarios 300A-D. In the scenario 300E, the CU 172 determines 327 that the UE 102 is the second UE type based on the RRC request message. In some implementations, because the UE 102 is the second UE type, the UE 102 generates the RRC request message (i.e., a type 2 RRC request message) in accordance with a format of the type 2 RRC request message. If the UE 102 is the first UE type or the third UE type, the RRC request message is a type 1 RRC request message. Thus, when the CU 172 receives the RRC request message in accordance with the format of the type 2 RRC request message, the CU 172 determines that the UE 102 is the second UE type despite the CU 172 receiving the indication of the first UE type 322. In other words, the CU 172 discards or ignores the indication of the first UE type 322.

[0115] In some implementations, if the UE 102 is the second UE type and operates 310 in the idle state, the type 2 RRC request message is an RRCSetupRequestl message. In some implementations, if the UE 102 is the first or third UE type and operates 310 in the idle state, the type 2 RRC request message is an RRCSetupRequest message. In some implementations, if the UE 102 is the second UE type and operates 310 in the connected state, the RRC request message is an RRCReestablishmentRequestl message. If the UE 102 is the first or third UE type and operates 310 in the connected state, the RRC request message is an RRCReestablishmentRequest message. In some implementations, if the UE 102 is the second UE type and operates 310 in the inactive state, the RRC request message is an RRCResumeRequest2 message or an RRCResumeRequest3 message. If the UE 102 is the first or third UE type and operates 310 in the inactive state, the RRC request message is an RRCResumeRequest message or an RRCResumeRequestl message.

[0116] In some alternative implementations, the UE 102 sets the LCID to the first value instead of the second value, and the DU 174 determines that the UE 102 is the first UE type, based on the first value of the LCID. A benefit of using the first value is to save a reserved value of the LCID for use in the future. [0117] The events 314, 316, 318, 320, 322, 327, 326, 328, 330, 332, and 334 are collectively referred to in Fig. 3E as a connection establishment procedure or a connection resume procedure 390E.

Turning to Fig. 3F, a scenario 300F is similar to the scenarios 300A-E. In some alternative implementations, the DU 174 configures the same RA resources for both the first UE type and the second UE type. The RA resources include RA preambles and/or time and frequency resources for a physical RA channel (PRACH). In some such cases, the DU 174 determines that the UE 102 is the first UE type when the DU 174 receives 314 the RA preamble in accordance with the RA resources. A benefit of configuring the same RA resources for both the first UE type and the second UE type is to save RA resources.

[0118] The events 314, 316, 318, 321, 322, 327, 326, 328, 330, 332, and 334 are collectively referred to in Fig. 3F as a connection establishment procedure or a connection resume procedure 390F.

[0119] Turning now to Fig. 4, in a scenario 400, the base station 104 includes a CU 172 and a DU 174. Events 402, 404, 406, 408, 410, 412, and 490 are similar to the events 302, 304, 306, 308, 310, 312, and 390A-390F, respectively. While or after performing a connection establishment procedure 490 with the UE 102, the CU 172 transmits 414 an Initial UE Message message to the CN 110. In some implementations, the CU 172 receives, from the UE 102, a NAS message in an RRC complete message in the connection establishment procedure and includes the NAS message in the Initial UE Message message. After receiving the Initial UE Message message, the CN 110 transmits 416 an Initial Context Setup Request message to the CU 172 to establish a UE context (c.g., an initial UE context) for the UE 102 at the CU 172.

[0120] After receiving 416 the Initial Context Setup Request message, the CU 172 performs 418 a security activation procedure with the UE 102 to activate security protection for communication between the UE 102 and CU 172. In the procedure 418, the CU 172 transmits a Security Mode Command message to the UE 102 via the DU 174. In response, the UE 102 activates security protection and transmits a Security Mode Complete message to the CU 172 via the DU 174. The CU 172 then transmits 420 CU-to-DU message including a UE Capability Enquiry message to the DU 174. In turn, the DU 174 transmits 422 the UE Capability Enquiry message to the UE 102. In response, the UE 102 transmits 424 a UE Capability Information message to the DU 174. In turn, the DU 174 transmits 426 a DU-to-CU message, including the UE Capability Information message, to the CU 172. In some implementations, the UE 102 includes at least one first UE capability for a first UE type and/or at least one second UE capability for a second UE type in the UE Capability Information message. To simplify the following description, “first UE capability” and “second UE capability” are used to represent the “at least one first UE capability” and “at least one second UE capability”.

[0121] In some implementations, one of the first UE type and the second UE type is a RedCap UE type and the other UE type is a fRedCap UE type. In some implementations, the UE 102 includes the first UE capability and/or the second UE capability in a capability container (e.g., NR-UE-Capability IE or UE-CapabilityRAT-ContainerList IE) and includes the capability container in the UE Capability Information message. In some implementations, the UE 102 includes additional capabilities in the capability container. In some implementations, the additional capabilities are independent of UE types. In other implementations, the additional capabilities apply to the first UE type, the second UE type, and other UE type(s) (e.g., normal capability UE).

[0122] In some implementations, the first UE capability applies to the second UE type in addition to the first UE type. The second UE capability does not apply to the first UE type. In such cases, if the UE 102 operates as or supports the second UE type, the UE 102 includes the first UE capability and the second UE capability in the capability container or UE Capability Information message. When the CU 172 receives the first UE capability and the second UE capability, the CU 172 determines that the UE 102 is the second UE type and is not the first UE type. If the UE 102 operates as or supports the first UE type, the UE 102 includes the first UE capability in the capability container or UE Capability Information message and does not include a UE capability for the second UE type in the UE Capability Information message. When the CU 172 receives the first UE capability and does not receive a UE capability for the second UE type from the UE 102, the CU 172 determines that the UE 102 is the first UE type. In some implementations, if the UE 102 supports the first UE type and the second UE type, the 102 includes, in the capability container or UE Capability Information message, an indication (e.g., a UE capability) indicating support of a dual UE type (i.e., support of the first UE type and the second UE type). If the UE 102 does not support the dual UE type, the UE 102 does not include the indication in the UE Capability Information message. When the CU 172 receives the indication, CU 172 determines that the UE 102 is the dual UE type. If the CU 172 does not receive the indication, the CU 172 determines that the UE 102 is the first UE type or the second UE type as described above. In some implementations, the first UE capability is not applicable to UE types other than the first UE type and the second UE type. In other implementations, the first UE capability applies to the first UE type, the second UE type, and a third UE type (e.g., normal capability UE).

[0123] In other implementations, the first UE capability does not apply to the second UE type. The second UE capability does not apply to the first UE type. In such cases, if the UE 102 operates as or supports the second UE type, the UE 102 includes the second UE capability in the capability container or UE Capability Information message and does not include the first UE capability in the UE Capability Information message. When the CU 172 receives the second UE capability, the CU 172 determines that the UE 102 is the second UE type. If the UE 102 operates as or supports the first UE type, the UE 102 includes the first UE capability in the capability container or UE Capability Information message and does not include the second UE capability in the UE Capability Information message. When the CU 172 receives the first UE capability, the CU 172 determines that the UE 102 is the first UE type. In some implementations, if the UE 102 supports the dual UE type, the UE 102 includes the first UE capability and the second UE capability in the capability container or UE Capability Information message. When the CU 172 receives the first UE capability and the second UE capability, the CU 172 determines that the UE 102 is the dual UE type.

[0124] After receiving the first UE capability and/or the second UE capability 426, the CU 172 transmits 428 the first UE capability and/or the second UE capability to the CN 110 (e.g., the AMF 164). In some implementations, the CU 172 transmits 428 a BS-to-CN message including the capability container to the CN 110. In other implementations, the CU 172 includes the capability container in an inter-node message (e.g., UERadioAccessCapabilitylnformationf includes the inter-node message in a BS-to-CN message, and transmits 428 the BS-to-CN message. The CN 110 stores the capability container or the inter-node message. The next time that the UE 102 connects to the CN 110 via a base station (e.g., the base station 104, 106A, or 106B), the CN 110 sends the capability container or the inter-node message to the base station, so that the base station does not need to transmit a UE Capability Enquiry message to the UE 102 in order to obtain the capability container. In some implementations, the BS-to-CN message is a specifically defined message (e.g., defined in 3GPP TS 38.413).

[0125] In some implementations, the CU 172 generates UE radio paging information (e.g., UERadioPayiny Information)' including the first UE capability and/or the second UE capability. In some implementations, the CU 172 includes the UE radio paging information in the BS-to-CN message 428. In other implementations, the CU 172 transmits an addition BS-to-CN message including the UE radio paging information to the CN 110. In some implementations, the additional BS-to-CN message is a specifically defined message (e.g., as defined in 3GPP TS 38.413).

[0126] In some implementations, the CU 172 receives a CN-to-BS message, including the capability container, from the CN 110 instead of the UE 102. Therefore, the CU 172 does not transmit a UE Capability Enquiry message to the UE 102, and events 420, 422, 424, and 426 are omitted. In some implementations, the CN-to-BS message is the Initial Context Setup Request message 416. In other implementations, the CN-to-BS message is a Connection Establishment Indication message, a UE Information Transfer message, or a DE NAS Transport message. In yet other implementations, the CN-to-BS message is a specifically defined message (e.g., as defined in 3GPP TS 38.413).

[0127] In some implementations, the CU 172 transmits a CU-to-DU message, including the capability container the first UE capability and/or the second UE capability, to the DU 174. For example, the CU-to-DU message is a UE Context Setup Request message or a UE Context Modification Request message. Thus, the DU 174 determines the UE 102 is the first UE type, the second UE type, or the dual UE type as described above for the CU 172.

[0128] After receiving the capability container or the UE Capability Information message, the CU 172 performs 430 an RRC reconfiguration procedure with the UE 102. In the procedure 430, the CU 172 transmits an RRC reconfiguration message (e.g., RRCReconfiguralion message), including configuration parameters, to the UE 102 via the DU 174. In some implementations, the base station 104 determines the configuration parameters based on the UE type of the UE 102 and the UE capability of the UE 102. Thus, the base station 104 ensures that the configuration parameters do not exceed the capabilities of the UE 102. In some implementations, the CU 172 transmit a CU-to-DU message to the DU 174. In some implementations, the CU 172 includes the capability container in the CU-to-DU message. In further implementations, the DU 174 determines that the UE 102 is the first UE type, the second UE type, or the dual UE type as described above for the CU 172. In response, the DU 174 transmits a DU-to-CU message including the configuration parameters. In some implementations, the DU 174 determines the configuration parameters based on the UE type of the UE 102 and the UE capability of the UE 102. Thus, the DU 174 ensures that the configuration parameters do not exceed the capabilities of the UE 102. In some implementations, the CU-to-DU message is a UE Context Setup Request message or a UE Context Modification Request message. In some implementations, the DU-to- CU message is a UE Context Setup Response message or a UE Context Modification Response message. In other implementations, the DU-to-CU message is a UE Context Modification Required message.

[0129] When the UE 102 receives the configuration parameters in the RRC reconfiguration message, the UE 102 applies the configuration parameters to communicate with the DU 174 or the base station 104. The UE 102 transmits an RRC reconfiguration complete message (e.g., RRCReconfigurationComplete message) message to the CU 172 via the DU 174 in response to the RRC reconfiguration message.

[0130] After performing the RRC reconfiguration procedure, the UE 102 communicates 432 with the base station 104 in accordance with the configuration parameters and communicates 432 data with the CN 110 via the base station 104. In some implementations, after a certain period of data inactivity for the UE 102, the base station 104 determines that neither the base station 104 nor the UE 102 has transmitted any data in the downlink direction or the uplink direction, respectively, during the period. In response to the determination, the CU 172 determines to instruct the UE 102 to transition to an idle or inactive state. To instruct the UE 102 to transition to the idle or inactive state, the CU 172 transmits 436 a CU-to-DU message including an RRC release message (e.g., RRCRelease message or RRCConnectionRelease message) to the DU 174. In turn, the DU 174 transmits the RRC release message to the UE 102. The UE 102 transitions 440 to the idle or inactive state upon receiving the RRC release message. In some implementations, the CU 172 transmits 433 a BS-to-CN message to the CN 110 upon determining to instruct the UE 102 to enter the idle or inactive state. In response, the CN 110 transmits 434 a UE Contest Release Command message to the CU 172. After receiving the message 434, the CU 172 transmits 436 the RRC release message. In some implementations, the message 433 is a UE Contest Release Request message to request release of a UE context of the UE 102 at the CU 172. In other implementations, the BS-to-CN message is a notification informing the CN 110 that the UE 102 is entering the idle or inactive state or that the CU 172 is releasing a UE context of the UE 102. The UE 102 operates 440 in the idle or inactive state camps on a cell of the base station 104.

[0131] The events 490, 414, 416, 418, 420, 422, 424, 426, 428, 430, 432, 433, 434, 436, and 438 are collectively referred to in Fig. 4 as procedures 480 for connection establishment, data communication, and connection release.

[0132] Turning next to Fig. 5, in a scenario 500, the UE 102 initially operates 510 in an idle state and the base station 106A includes a CU 172 and a DU 174. Events 502, 504, 506, 508, 510, and 512 are similar to the events 302, 304, 306, 308, 310, and 312, respectively. In some scenarios and implementations, the UE 102, a base station (e.g., the base station 106A, 106B, or 104), and the CN 110 perform connection establishment, data communication, and connection release procedures, similar to the event 480. The connection release procedure is similar to the events 433, 434, 436, and 438. After (e.g., in response to) performing the connection release procedure, the UE 102 transitions 510 to the idle state. The UE 102 in the idle state 510 selects or reselects a cell of the base station 106A (i.e., the cell operated by the DU 174), similar to the event 440.

[0133] The CN 110 (e.g., AMF 164) later determines to page the UE 102 (e.g., in order to transmit data to the UE 102 or due to receiving a mobile terminated call). In some implementations, in response to the determination, the CN 110 transmits 514 a CN-to-BS Paging message and transmits 518 a CN-to-BS Paging message to the base station 104 (e.g., a CU of the base station 104) and the CU 172, respectively. The CN 110 includes a UE ID of the UE 102 in the messages 514 and 518. In some implementations, the CN 110 includes, in the messages 514 and 518, at least one first UE capability for the first UE type and/or the at least one second UE capability for the second UE type for paging the UE 102. To simplify the following description, “first UE capability” and “second UE capability” are used to represent the “at least one first UE capability” and “at least one second UE capability”. In some implementations, the CN 110 includes, in the CN-to-BS message 518, UE radio paging information including the first UE capability and/or the second UE capability. In further implementations, the CN 110 receives the UE radio paging information as described for Fig. 4. In some implementations, descriptions described for Figs. 3A-3F and 4 apply to the first UE type, the second UE type, the first UE capability, and/or the second UE capability. In some implementations, the CN-to-BS Paging messages are NG application protocol (NGAP) Paging messages.

[0134] In response to receiving 518 the message, the CU 172 transmits 520 a CU-to-DU Paging (e.g., a F1AP Paging message) to the DU 174 to page the UE 102. In some implementations, the CU 172 includes the UE ID in the CU-to-DU Paging message. In some implementations, the CU 172 includes the first UE capability and/or the second UE capability in the CU-to-DU Paging message. In some implementations, the CN 110 includes discontinuous reception (DRX) information for the UE 102 in the messages 514, 518 and the CU 172 includes the DRX information in the CU-to-DU Paging message. In some implementations, the DRX information is pre-defined NR Paging extended DRX (eDRX) information (e.g., as defined in 3GPP TS 38.413 and/or 38.473). In other implementations, the DRX information is specifically defined NR Paging eDRX information (e.g., as defined in 3GPP TS 38.413 and/or 38.473).

[0135] In response to receiving the CU-to-DU Paging message, the DU 174 transmits 524 a UE Paging message, including the UE ID, on the cell of the base station 106A to page the UE 102. In some implementations, the DU 174 determines 522 radio resources and/or configuration(s) for paging the UE 102 based on the first UE capability, the second UE capability, and/or the DRX information and transmits 524 the UE Paging message using the radio resources and/or configuration(s). The DU 174 determines the radio resources and/or configuration(s) that ensures that the UE 102 can receive the UE Paging message given UE capabilities of the UE 102.

[0136] In response to receiving the message 514, the base station 104 transmits 516 a UE Paging (e.g., an RRC Paging message), including the UE ID, to page the UE 102. In some implementations, a CU of the base station 104 transmits a CU-to-DU Paging message to a DU of the base station 104 to page the UE 102, similar to the CU-to-DU Paging message 520, and the DU transmits 516 the UE Paging message in response to receiving the CU-to-DU Paging message. In some implementations, the base station 104 or the DU of the base station 104 determines radio resources and/or configuration(s) for paging the UE 102 based on the first UE capability, the second UE capability, and/or the DRX information and transmits 516 the UE Paging message using the radio resources and/or configuration(s). The base station 104 or the DU of the base station 104 determines the radio resources and/or configuration(s) that ensures that the UE 102 can receive the UE Paging message given UE capabilities of the UE 102.

[0137] Because the UE 102 camps on the cell of the base station 106A, the UE 102 receives 524 the UE Paging message and does not receive 516 the UE Paging message. In response to receiving 524 the UE Paging message, the UE 102 performs 581 connection establishment, data communication, and connection release procedures with the base station 106A and the CN 110, similar to the event 480. After the connection release in the event 581, the UE 102 transitions 541 to the idle state and, in some implementations, selects a cell of a base station (e.g., the base station 106A, 106B, or 104), similar to the events 440 and 540.

[0138] Turning next to Fig. 6, in a scenario 600, the UE (e.g., UE 102) initially operates 610 in an inactive state and the base station 106B includes a CU 172 and a DU 174. Events 602, 604, 606, 608, 610, 612, 616, 620, 622, 624, and 690 are similar to the events 302, 304, 306, 308, 310, 312, 516, 520, 522, 524, and 390A-F, respectively. In some scenarios and implementations, the UE 102, the base station 106A, and the CN 110 perform connection establishment, data communication, and connection release procedures, similar to the event 480. The connection release procedure is similar to the events 433, 434, 436, and 438. After (e.g., in response to) performing the connection release procedure, the UE 102 transitions 610 to the inactive state. The UE 102 in the idle state 610 selects or reselects a cell of the base station 106B (i.e., the cell operated by the DU 174), similar to the event 440.

[0139] Later in time, the CN 110 (e.g., UPF 162) transmits 615 a DL data packet for the UE 102 to the base station 106A (e.g., a CU of the base station 106A). In response to receiving the DL data packet, the base station 106A transmits 616 a UE Paging message and transmits 618 a BS-to-BS Paging message to the CU 172. The base station 106A includes a UE ID of the UE 102 in the messages 618. In some implementations, the base station 106A includes, in the messages 618, at least one first UE capability for the first UE type and/or at least one second UE capability for the second UE type for paging the UE 102. To simplify the following description, “first UE capability” and “second UE capability” are used to represent the “at least one first UE capability” and “at least one second UE capability”. In some implementations, the base station 106A includes, in the BS-to-BS message 618, UE radio paging information including the first UE capability and/or the second UE capability. In some implementations, before receiving 615 the DL data packet, the base station 106A receives 614 a CN-to-BS message including the first UE capability, the second UE capability, and/or the UE radio paging information from the CN 110. In some implementations, the CN-to-BS message is a specifically defined message (e.g., defined in 3GPP TS 38.413). In some implementations, descriptions described for Figs. 3A-3F and 4 apply to the first UE type, the second UE type, the first UE capability, and/or the second UE capability.

[0140] In some implementations, the base station 106 A includes DRX information for the UE 102 in the message 618. In some implementations, the DRX information is pre-defined NR Paging eDRX information (e.g., defined in 3GPP TS 38.413 and/or 38.473). In other implementations, the DRX information is specifically defined NR Paging eDRX information (e.g., defined in 3GPP TS 38.413 and/or 38.473). In some implementations, the base station 106 receives the DRX information in the CN-to-BS message 614.

[0141] In response to receiving the message 618, the CU 172 transmits 620 a CU-to-DU Paging (e.g., a F1AP Paging message), including the UE ID, the first UE capability, and/or the second UE capability, to the DU 174 to page the UE 102. In some implementations, the CU 172 includes the UE ID in the CU-to-DU Paging message. In some implementations, the CU 172 includes the first UE capability and/or the second UE capability in the CU-to-DU Paging message. In some implementations, the CU 172 includes the DRX information in the CU-to-DU Paging message.

[0142] In response to receiving the CU-to-DU Paging message, the DU 174 transmits 524 a UE Paging message, including the UE ID, on the cell of the base station 106A to page the UE 102. In some implementations, the DU 174 determines 622 radio resources and/or configuration(s) for paging the UE 102, based on the first UE capability, the second UE capability, and/or the DRX information, and transmits 624 the UE Paging message using the radio resources and/or configuration(s). The DU 174 determines the radio resources and/or configuration(s) that ensure that the UE 102 can receive the UE Paging message given UE capabilities of the UE 102. Similarly, the base station 106A transmits 616 the UE Paging message as described above.

[0143] Because the UE 102 camps on the cell of the base station 106B, the UE 102 receives 624 the UE Paging message and does not receive 616 the UE Paging message. In response to receiving the UE Paging message 624, the UE 102 performs 690 a connection resume procedure with the base station 106B, similar to the events 390A-F. During the connection resume procedure, the base station 106B performs 690 a UE context retrieval procedure with the base station 106A and performs 626 a Path Switch procedure with the CN 110. After or while performing the UE context retrieval procedure, the base station 106A transmits 628 the DL data packet to the base station 106B. After transmitting an RRC response message to the UE 102 or receiving an RRC complete message from the UE 102 in the procedure 690, the CU 172 transmits 630 the DL data packet to the DU 174. In turn, the DU 174 transmits 632 the DL data packet to the UE 102.

[0144] Next, several example methods, that can be implemented in a RAN node such as a CN, a base station, a DU, or a CU are discussed next with reference to Figs. 7-14. Descriptions described for Figs. 3A-6 can apply to Figs. 7-14. To simplify the following description, “capability” is used to represent “capability or capabilities” or “at least one capability”.

[0145] Turning first to Fig. 7, an example method 700 can be implemented in a RAN node (e.g., the base station 104, 106A, or 106B, or the CU 172, DU 174, 174A, or 174B of the base station 104, 106A, or 106B). The method 700 begins at block 702, where the RAN node communicates with a UE (e.g., events 314, 316, 318, 328, 328, 332, 390A-F in Figs. 3A-3F, events 490, 418 in Fig. 4). At block 704, the RAN node receives a first UE capability for a first UE type and a second UE capability for a second UE type for the UE (e.g., events 424, 426). At block 706, the RAN node includes the first UE capability in UE radio paging information for paging the UE. At block 708, the RAN node includes the second UE capability in UE radio paging information. At block 710, the RAN node transmits the UE radio paging information to the CN (e.g., event 428 in Fig. 4).

[0146] In some implementations, the RAN node receives the first UE capability and the second UE capability from the UE. In other implementations, the RAN node receives the first UE capability and the second UE capability from the CN (e.g., an AMF). In some implementations, the RAN node receives a capability container (e.g., NR-UE-Capability IE or UE-CapabilityRAT-ContainerEist IE) for the UE from the UE or the CN. In some implementations, the RAN node transmits the capability container to the CN. In some implementations, the RAN node retrieves the first UE capability and the second UE capability from the capability container.

[0147] In some implementations, the first UE type and the second UE type are a RedCap UE type and an fRedCap UE type, respectively. In some implementations, the first UE capability applies to the second UE type in addition to the first UE type, and the second UE capability does not apply to the first UE type. In some implementations, the UE is the second UE type and is not the first UE type. In other implementations, the UE is a dual UE type supporting the first UE type and the second UE type.

[0148] Turning to Fig. 8, an example method 800 can be implemented in a CN (e.g., the CN 110 or AMF 164). The method 800 begins at block 802, where the CN receives a first UE capability for a first UE type for a UE from a first base station (e.g., event 428 in Fig. 4). At block 804, the CN receives a second UE capability for a second UE type for the UE from the first base station (e.g., event 428 in Fig. 4). At block 806, the CN includes the first UE capability in a CN-to-BS Paging message. At block 808, the CN includes the second UE capability in the CN-to-BS Paging message for paging the UE. At block 810, the CN transmits the CN-to-BS Paging message to a second base station to page the UE (e.g., event 518 in Fig. 5). At block 812, the CN receives a plurality of UE capabilities for the UE from the first base station (e.g., event 428 in Fig. 4). At block 814, the CN transmits, to the second base station, a CN-to-BS message including the plurality of UE capabilities for the second base station to communicate with the UE (e.g., events 416, 614 in Figs. 4 and 6).

[0149] Descriptions for Fig. 7 can apply to Fig. 8. In some implementations, the CN-to-BS message is a specifically defined message (e.g., defined in 3GPP TS 38.413). In other implementations, the CN-to-BS message is an NG application protocol (NGAP) message. In some implementations, the plurality of UE capabilities include the first UE capability, the second UE capability, and additional UE capabilities. In some implementations, the additional UE capabilities include capabilities applicable for the first UE type, the second UE type, and a third UE type (e.g., a normal capability UE). [0150] In some implementations, the CN transmits another CN-to-BS Paging message for paging the UE to the first base station or a third base station, similar to the CN-to-BS message of block 806 (e.g., event 514 in Fig. 5).

[0151] Turning to Fig. 9A, an example method 900A can be implemented in a CN (e.g., the CN 110 or AMF 164). The method 900A begins at block 902, where the CN receives UE radio paging information for a UE from a first base station, and where the UE radio paging information includes a first UE capability and a second UE capability for a first UE type and a second UE type, respectively (e.g., event 428 in Fig. 4). In some implementations, the UE is the second UE type and is not the first UE type. In other implementations, the UE is a dual UE type supporting the first UE type and the second UE type.

[0152] At block 904, the CN transmits, to a second base station, a CN-to-BS message including the UE radio paging information to page the UE (e.g., events 416, 518, 614 in Figs. 4- 6). At block 906, the CN receives a plurality of UE capabilities for the UE from the first base station (e.g., event 428 in Fig. 4). At block 908, the CN transmits, to the second base station, a CN-to-BS message including the plurality of UE capabilities for the second base station to communicate with the UE (e.g., events 416, 614 in Figs. 4 and 6).

[0153] Fig. 9B is a flow diagram of an example method 900B similar to the method 900A, except that the method 900B includes block 903 instead of block 902. At block 903, the CN receives UE radio paging information for a UE from a first base station, where the UE radio paging information includes a first UE capability for a first UE type and does not include a second UE capability for a second UE type.

[0154] Fig. 9C is a flow diagram of an example method 900C similar to the method 900A, except that the method 900B includes block 901 instead of block 902. At block 901, the CN receives UE radio paging information for a UE from a first base station, where the UE radio paging information does not include a first UE capability for a first UE type and includes a second UE capability for a second UE type.

[0155] Descriptions for Figs. 7 and 8 can apply to Figs. 9A, 9B, and 9C.

[0156] Turning to Fig. 10A, an example method 1000A can be implemented in a base station (e.g., the base station 104, 106A, or 106B). The method 1000A begins at block 1002, where the base station receives a CN-to-BS message for a UE from a CN, and where the CN-to-BS message includes a first UE capability and a second UE capability for a first UE type and a second UE type, respectively (e.g., events 416, 514, 516, 614, 616 in Figs. 4-6). In some implementations, the UE is the second UE type and is not the first UE type. In other implementations, the UE is a dual UE type supporting the first UE type and the second UE type.

[0157] At block 1004, the base station generates a paging message including a UE ID of the UE. At block 1006, the base station determines a radio resource and/or a configuration for transmitting the paging message, based on the first UE capability and the second UE capability (e.g., events 522, 622 in Figs. 5 and 6). At block 1008, the base station transmits the paging message using the radio resource and/or configuration (e.g., events 524, 624 in Figs. 5 and 6).

[0158] Fig. 10B is a flow diagram of an example method 1000B similar to the method 1000A, except that the method 1000B includes blocks 1003 and 1007 instead of blocks 1002 and 1006. At block 1003, the base station receives a CN-to-BS message for a UE from a CN, where the CN-to-BS message includes a first UE capability for a first UE type and does not include a second UE capability for a second UE type (e.g., events 416, 514, 516, 614, 616 in Figs. 4-6). At block 1007, the base station determines a radio resource and/or a configuration, for transmitting the paging message, based on the first UE capability (e.g., events 522, 622 in Figs. 5 and 6). Unlike Fig. 10A, the base station determines the radio resource and/or the configuration without considering the second UE capability.

[0159] Fig. 10C is a flow diagram of an example method 1000C similar to the method 1000A, except that the method 1000C includes blocks 1001 and 1005 instead of blocks 1002 and 1006. At block 1001, the base station receives a CN-to-BS message for a UE from a CN, where the CN-to-BS message does not include a first UE capability for a first UE type and includes a second UE capability for a second UE type (e.g., events 416, 514, 516, 614, 616 in Figs. 4-6). At block 1005, the base station determines a radio resource and/or a configuration, for transmitting the paging message, based on the second UE capability (e.g., events 522, 622 in blocks 5 and 6). Unlike Fig. 10A, the base station determines the radio resource and/or the configuration without considering the first UE capability.

[0160] Descriptions for Figs.7-9C can apply to Figs. 10A, 10B, and 10C. [0161] Turning to Fig. 11 A, an example method 1100A can be implemented in a DU (e.g., the DU 174, 174A, 174B of the base station 104, 106A, or 106B). The method 1100A begins at block 1102, where the DU receives, from a CU, a CU-to-DU Paging message for paging a UE, and where the CU-to-DU Paging message includes a first UE capability and a second UE capability for a first UE type and a second UE type, respectively (e.g., events 520, 620 in Figs. 5 and 6). In some implementations, the UE is the second UE type and is not the first UE type. In other implementations, the UE is a dual UE type supporting the first UE type and the second UE type.

[0162] At block 1104, the DU generates a paging message including a UE ID of the UE. At block 1106, the DU determines a radio resource and/or a configuration, for transmitting the paging message, based on the first UE capability and the second UE capability (e.g., events 522, 622 in Figs. 5 and 6). At block 1108, the DU transmits the paging message using the radio resource and/or configuration (e.g., events 524, 624 in Figs. 5 and 6).

[0163] In some implementations, the DU receives a CU-to-DU message including the first UE capability and/or the second UE capability from the CU. In other implementations, the DU receives, from the CU, a CU-to-DU message including a capability container, and the capability container includes the first UE capability and/or the second UE capability. In some implementations, the CU-to-DU message is an F1AP message, a UE Context Setup Request message, a UE Context Modification Request message, or a DL RRC Message Transfer message.

[0164] Fig. 1 IB is a flow diagram of an example method 1100B similar to the method 1100A, except that the method 1100B includes blocks 1103 and 1107 instead of blocks 1102 and 1106. At block 1103, the DU receives, from a CU, a CU-to-DU Paging message for paging a UE, where the CU-to-DU Paging message includes a first UE capability for a first UE type and does not include a second UE capability for a second UE type (e.g., events 520, 620 in Figs. 5 and 6). At block 1107, the DU determines a radio resource and/or a configuration, for transmitting the paging message, based on the first UE capability (e.g., events 522, 622 in Figs. 5 and 6). Unlike Fig. 11 A, the DU determines the radio resource and/or the configuration without considering the second UE capability. [0165] Fig. 11C is a flow diagram of an example method 1100C similar to the method 1100A, except that the method 1100C includes blocks 1101 and 1105 instead of blocks 1102 and 1106. At block 1101, the DU receives, from a CU, a CU-to-DU Paging message for paging a UE, where the CU-to-DU Paging message does not include a first UE capability for a first UE type and includes a second UE capability for a second UE type (e.g., events 520, 620 in Figs. 5 and 6). At block 1107, the DU determines a radio resource and/or a configuration, for transmitting the paging message, based on the second UE capability (e.g., events 522, 622 in Figs. 5 and 6). Unlike Fig. 11 A, the DU determines the radio resource and/or the configuration without considering the first UE capability.

[0166] Descriptions for Figs.7-10C can apply to Figs. 11 A, 11B, and 11C.

[0167] Turning now to Fig. 12A, an example method 1200A can be implemented in a RAN node (e.g., the base station 104, 106A, or 106B, or the DU 174, 174A, or 174B of the base station 104, 106A, or 106B). The method 1200A begins at block 1202, where the RAN node receives an interface message for paging a UE (e.g., events 416, 514, 516, 614, 616, 520, 620 in Figs. 4-6), and where the interface message includes a UE ID of the UE. At block 1204, the RAN node generates a paging message including the UE ID in response to the interface message. At block 1206A, the RAN node determines whether the interface message includes a first UE capability for a first UE type and/or a second UE capability for a second UE type. If the RAN node determines that the interface message includes a first UE capability for a first UE type and/or a second UE capability for a second UE type at block 1206 A, the flow proceeds to block 1208. At block 1208, the RAN node transmits the paging message to the UE using a first radio resource and/or a first configuration (e.g., event 524, 624). Otherwise, if the RAN node determines that the interface message includes neither a first UE capability for a first UE type nor a second UE capability for a second UE type at block 1206 A, the flow proceeds to block 1210. At block 1210, the RAN node transmits the paging message to the UE using a second radio resource and/or a second configuration. In some implementations, the interface message includes a third UE capability not for the first UE type and the second UE type and the RAN node determines the second radio resource and/or the second configuration base on the third capability. [0168] Fig. 12B is a flow diagram of an example method 1200B similar to the method 1200A, except that the method 1200B includes block 1206B instead of block 1206A. At block 1206B, the RAN node determines whether the interface message includes a first UE capability for a first UE type. If the RAN node determines that the interface message includes a first UE capability for a first UE type at block 1206B, the flow proceeds to block 1208. Otherwise, if the RAN node determines that the interface message does not include a first UE capability for a second UE type at block 1206B, the flow proceeds to block 1210.

[0169] Fig. 12C is a flow diagram of an example method 1200C similar to the method 1200A, except that the method 1200C includes block 1212. If the RAN node determines that the interface message includes a first UE capability for a first UE type at block 1206A, the flow proceeds to block 1208. If the RAN node determines that the interface message includes a second UE capability for a second UE type at block 1206A, the flow proceeds to block 1212. At block 1212, the RAN node transmits the paging message to the UE using a third radio resource and/or a third configuration.

[0170] Descriptions for Figs.7-11C can apply to Figs. 12A, 12B, and 12C.

[0171] Turning next to Fig. 13A, an example method 1300A can be implemented in a first base station (e.g., the base station 104, 106A, or 106B). The method 1300A begins at block 1302, where the first base station receives a CN-to-BS message for a UE from a second base station, where the BS-to-BS message includes a first UE capability and a second UE capability for a first UE type and a second UE type, respectively (e.g., event 618 in Fig. 6). In some implementations, the UE is the second UE type and is not the first UE type. In other implementations, the UE is a dual UE type supporting the first UE type and the second UE type.

[0172] At block 1304, the first base station generates a paging message including a UE ID of the UE. At block 1306, the first base station determines a radio resource and/or a configuration, for transmitting the paging message, based on the first UE capability and the second UE capability (e.g., event 622 in Fig. 6). At block 1308, the first base station transmits the paging message using the radio resource and/or configuration (e.g., event 624 in Fig. 6).

[0173] Fig. 13B is a flow diagram of an example method 1300B similar to the method 1300A, except that the method 1300B includes blocks 1303 and 1307 instead of blocks 1302 and 1306. At block 1303, the first base station receives a BS-to-BS message for a UE from a second base station, where the BS-to-BS message includes a first UE capability for a first UE type and does not include a second UE capability for a second UE type (e.g., events 618 in Fig. 6). At block 1307, the first base station determines a radio resource and/or a configuration, for transmitting the paging message, based on the first UE capability (e.g., event 622 in Fig. 6). Unlike Fig. 13A, the first base station determines the radio resource and/or the configuration without considering the second UE capability.

[0174] Fig. 13C is a flow diagram of an example method 1300C similar to the method 1300A, except that the method 1300C includes blocks 1301 and 1305 instead of blocks 1302 and 1306. At block 1301, the first base station receives a BS-to-BS message for a UE from a second base station, where the BS-to-BS message does not include a first UE capability for a first UE type and includes a second UE capability for a second UE type (e.g., event 618 in Fig. 6). At block 1305, the first base station determines a radio resource and/or a configuration, for transmitting the paging message, based on the second UE capability (e.g., event 622 in Fig. 6). Unlike Fig. 13 A, the first base station determines the radio resource and/or the configuration without considering the first UE capability.

[0175] Descriptions for Figs.7-12C can apply to Figs. 13 A, 13B, and 13C.

[0176] Turning now to Fig. 14A, an example method 1400A can be implemented in a CU

(e.g., the CU 172 of the base station 104, 106A, or 106B). The method 1400A begins at block 1402A, where the CU receives an interface paging message for a UE, and where the interface paging message includes a first UE capability and a second UE capability for a first UE type and a second UE type, respectively (e.g., events 416, 514, 516, 614, 616, 618 in Figs. 4-6). In some implementations, the UE is the second UE type and is not the first UE type. In other implementations, the UE is a dual UE type supporting the first UE type and the second UE type. In some implementations, the interface paging message is a CN-to-BS Paging message, and the CU receives the CN-to-BS Paging message from a CN. In other implementations, the interface paging message is a BS-to-BS Paging message and the CU receives the BS-to-BS Paging message from a base station. [0177] At block 1404A, the CU generates a CU-to-DU Paging message including a UE ID of the UE, the first UE capability, and the second UE capability. At block 1406, the CU transmits the CU-to-DU Paging message to a DU (e.g., events 520, 620 in Figs. 5 and 6).

[0178] Fig. 14B is a flow diagram of an example method 1400B similar to the method 1400A, except that the method 1400B includes blocks 1402B and 1404B instead of blocks 1402 A and 1404A. At block 1402B, the CU receives an interface paging message for a UE, where the interface paging message includes a first UE capability for a first UE type and does not include a second UE capability for a second UE type (e.g., events 416, 514, 516, 614, 616, 618 in Figs. 4- 6). At block 1404B, the CU generates a CU-to-DU Paging message including a UE ID of the UE and the first UE capability.

[0179] Fig. 14C is a flow diagram of an example method 1400C similar to the method 1400A, except that the method 1400C includes blocks 1402C and 1404C instead of blocks 1402A and 1404A. At block 1402C, the CU receives an interface paging message for a UE, where the interface paging message does not include a first UE capability for a first UE type and includes a second UE capability for a second UE type (e.g., events 416, 514, 516, 614, 616, 618 in Figs. 4- 6). At block 1404C, the CU generates a CU-to-DU Paging message including a UE ID of the UE and the second UE capability.

[0180] Example 1. A method implemented in a core network (CN), the method comprising: transmitting, from the CN to a radio access network (RAN), a first paging message including a first user equipment (UE) capability of a first UE and for a first UE type associated with a reduced UE capability for paging the first UE; and transmitting, from the CN to the RAN, a second paging message including a second UE capability of a second UE and for a second UE type associated with a further reduced UE capability for paging the second UE.

[0181] Example 2. The method of example 1, wherein: the first UE capability is based on one or more first hardware components of the first UE; and the second UE capability is based on one or more second hardware components of the second UE.

[0182] Example 3. The method of either one of examples 1 or 2, further comprising: receiving, from the UE via the RAN, at least one of the first UE capability or the second UE capability. [0183] Example 4. The method of example 3, wherein: the receiving includes receiving the at least one of the first UE capability or the second UE capability from a first RAN node of the RAN; and at least one of the transmitting of the first paging message or the transmitting of the second paging message is via a second RAN node of the RAN.

[0184] Example 5. The method of either one of examples 1 or 2, further comprising: determining, at the CN, at least one of the first UE capability or the second UE capability.

[0185] Example 6. The method of example 1, wherein the first paging message further includes first discontinuous reception (DRX) information and the second paging message further includes second DRX information.

[0186] Example 7. The method of example 6, wherein at least one of the first DRX information or the second DRX information is extended DRX (eDRX) information.

[0187] Example 8. A method implemented in a distributed unit (DU) of a distributed radio access network (RAN) node including a centralized unit (CU), the method comprising: receiving, at the DU from the CU, a first paging message including one of (i) a first user equipment (UE) capability for a first UE type associated with a reduced UE capability or (ii) a second UE capability for a second UE type associated with a further reduced UE capability; generating, at the DU, a second paging message for a UE; and in a first instance, when the first paging message includes the first UE capability, transmitting, from the DU to the UE, the second paging message based on the first UE capability; in a second instance, when the first paging message includes the second UE capability, transmitting, from the DU to the UE, the second paging message based on the second UE capability.

[0188] Example 9. The method of example 8, wherein the transmitting includes: in the first instance, transmitting the second paging message to the UE using a first radio resource; and in the second instance, transmitting the second paging message to the UE using a second radio resource.

[0189] Example 10. The method of either one of examples 8 or 9, wherein the first paging message includes a UE identity (ID) for the UE.

[0190] Example 11. The method of any one of examples 8-10, wherein the first paging message further includes discontinuous reception (DRX) information. [0191] Example 12. The method of example 11, further comprising: determining, using at least one of the DRX information, the first UE capability, or the second UE capability, one or more radio resources for transmitting the second paging message.

[0192] Example 13. The method of example 11 or 12, wherein the DRX information is extended DRX (eDRX) information.

[0193] Example 14. The method of any one of examples 8-13, wherein the at least one of the first UE capability or the second UE capability is based on one or more hardware components associated with the UE.

[0194] Example 15. An apparatus, operating as a network node, comprising processing hardware and configured to implement a method according to any one of the preceding examples.

[0195] Example 16. A method implemented in a centralized unit (CU) of a distributed radio access network (RAN) node including a distributed unit (DU), the method comprising: receiving, at the CU from a core network (CN), a first paging message including one of (i) a first user equipment (UE) capability for a first UE type associated with a reduced UE capability or (ii) a second UE capability for a second UE type associated with a further reduced UE capability; transmitting, from the CU to the DU, a second paging message including the one of the first UE capability or the second UE capability to cause the DU to determine radio resources for paging the UE based on the at least one of the first UE capability or the second UE capability.

[0196] Example 17. The method of example 16, wherein the second paging message further includes discontinuous reception (DRX) information.

[0197] Example 18. The method of example 17, wherein the DRX information is extended DRX (eDRX) information.

[0198] Example 19. The method of either one of examples 17 or 18, further comprising: receiving, from the CN, the DRX information.

[0199] Example 20. The method of any one of examples 16-19, wherein the second paging message includes a UE identity (ID) for the UE. [0200] Example 21. An apparatus, operating as a network node, comprising processing hardware and configured to implement a method according to any one of examples 16-20.

[0201] The following additional considerations apply to the foregoing discussion.

[0202] Generally speaking, description for one of the above figures can apply to another of the above figures. Examples, implementations and methods described above can be combined, if there is no conflict. An event or block described above can be optional or omitted. For example, an event or block with dashed lines in the figures can be optional. In some implementations, “message” is used and can be replaced by “information element (IE)”. In some implementations, “IE” is used and can be replaced by “field”. The description for the CU or DU can apply to an aggregated base station implementing communication functions of CU and DU for communicating with a UE. In case of the aggregated base station, the messages exchanged between the CU and DU can be omitted or seen as internal computer instructions or internal messages exchanged between different processes in the aggregated base station.

[0203] A user device in which the techniques of this disclosure can be implemented (e.g., the UE 102) can be any suitable device capable of wireless communications such as a smartphone, a tablet computer, a laptop computer, a mobile gaming 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. Further, the user device in some cases may be embedded in an electronic system such as the head unit of a vehicle or an advanced driver assistance system (ADAS). Still further, the user device can operate as an internet-of-things (loT) device or a mobile-internet device (MID). Depending on the type, the user device can include one or more general-purpose processors, a computer-readable memory, a user interface, one or more network interfaces, one or more sensors, etc.

[0204] Certain embodiments are described in this disclosure as including logic or a number of components or modules. Modules may can be software modules (e.g., code stored on non- transitory machine-readable medium) or hardware modules. A hardware module is a tangible unit capable of performing certain operations and may be configured or arranged in a certain manner. A hardware module can comprise dedicated circuitry or logic that is permanently configured (e.g., as a special-purpose processor, such as a field programmable gate array (FPGA) or an application- specific integrated circuit (ASIC)) to perform certain operations. A hardware module may also comprise programmable logic or circuitry (e.g., as encompassed within a general-purpose processor or other programmable processor) that is temporarily configured by software to perform certain operations. The decision to implement a hardware module in dedicated and permanently configured circuitry, or in temporarily configured circuitry (e.g., configured by software) may be driven by cost and time considerations.

[0205] When implemented in software, the techniques can be provided as pail of the operating system, a library used by multiple applications, a particular software application, etc. The software can be executed by one or more general-purpose processors or one or more specialpurpose processors.

[0206] Upon reading this disclosure, those of skill in the art will appreciate still additional alternative structural and functional designs for identifying devices of different capabilities through the disclosed principles herein. Thus, while particular embodiments and applications have been illustrated and described, it is to be understood that the disclosed embodiments are not limited to the precise construction and components disclosed herein. Various modifications, changes and valuations, which will be apparent to those of ordinary skill in the art, may be made in the arrangement, operation and details of the method and apparatus disclosed herein without departing from the spirit and scope defined in the appended claims.

Claims

What is claimed is:

1. A method implemented in a core network (CN), the method comprising: transmitting, from the CN to a radio access network (RAN), a first paging message including a first user equipment (UE) capability of a first UE and for a first UE type associated with a reduced UE capability for paging the first UE; and transmitting, from the CN to the RAN, a second paging message including a second UE capability of a second UE and for a second UE type associated with a further reduced UE capability for paging the second UE.

2. The method of claim 1, wherein: the first UE capability is based on one or more first hardware components of the first UE; and the second UE capability is based on one or more second hardware components of the second UE.

3. The method of either one of claims 1 or 2, further comprising: receiving, from the UE via the RAN, at least one of the first UE capability or the second UE capability.

4. The method of claim 3, wherein: the receiving includes receiving the at least one of the first UE capability or the second UE capability from a first RAN node of the RAN ; and at least one of the transmitting of the first paging message or the transmitting of the second paging message is via a second RAN node of the RAN.

5. The method of either one of claims 1 or 2, further comprising: determining, at the CN, at least one of the first UE capability or the second UE capability.

6. The method of claim 1, wherein the first paging message further includes first discontinuous reception (DRX) information and the second paging message further includes second DRX information.

7. The method of claim 6, wherein at least one of the first DRX information or the second DRX information is extended DRX (eDRX) information.

8. A method implemented in a distributed unit (DU) of a distributed radio access network (RAN) node including a centralized unit (CU), the method comprising: receiving, at the DU from the CU, a first paging message including one of (i) a first user equipment (UE) capability for a first UE type associated with a reduced UE capability or (ii) a second UE capability for a second UE type associated with a further reduced UE capability; generating, at the DU, a second paging message for a UE; and in a first instance, when the first paging message includes the first UE capability, transmitting, from the DU to the UE, the second paging message based on the first UE capability; in a second instance, when the first paging message includes the second UE capability, transmitting, from the DU to the UE, the second paging message based on the second UE capability.

9. The method of claim 8, wherein the transmitting includes: in the first instance, transmitting the second paging message to the UE using a first radio resource; and in the second instance, transmitting the second paging message to the UE using a second radio resource.

10. The method of either one of claims 8 or 9, wherein the first paging message includes a UE identity (ID) for the UE.

11. The method of any one of claims 8-10, wherein the first paging message further includes discontinuous reception (DRX) information.

12. The method of claim 11, further comprising: determining, using at least one of the DRX information, the first UE capability, or the second UE capability, one or more radio resources for transmitting the second paging message.

13. The method of claim 11 or 12, wherein the DRX information is extended DRX (eDRX) information.

14. The method of any one of claims 8-13, wherein the at least one of the first UE capability or the second UE capability is based on one or more hardware components associated with the UE.

15. An apparatus, operating as a network node, comprising processing hardware and configured to implement a method according to any one of the preceding claims.