EP4736484A1

EP4736484A1 - Enabling communication for a further reduced capability user equipment

Info

Publication number: EP4736484A1
Application number: EP24762143.6A
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: WO2025034932A1; CN121646940A

Abstract

A method in a user equipment (UE) for transmitting capability information of a UE includes receiving, at the UE and from a radio access network (RAN) node, a UE capability request; generating, at the UE, a UE capability information message by: including one of (i) a first 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, and refraining from including a different one of (i) the first UE capability or (ii) the second UE capability; and transmitting, from the UE to the RAN node responsive to the UE capability request, the UE capability information message.

Description

PATENT APPLICATION

Attorney Docket No.: 31730/306434-00

ENABLING COMMUNICATION 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,002 entitled “ENABLING COMMUNICATION 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 communication for UEs with further reduced capability (IRedCap).

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 PATENT APPLICATION

Attorney Docket No.: 31730/306434-00 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 attempt to communicate with a modem RedCap UE in a manner that the UE does not support. Alternatively, the base station that incorrectly assumes a particular UE is a modem RedCap UE can unnecessarily refrain from using NR techniques and features when communicating with a UE, resulting in inefficiencies. PATENT APPLICATION

Attorney Docket No.: 31730/306434-00

[0009] In some aspects, the techniques described herein relate to a method implemented in a user equipment (UE), the method including: receiving, at the UE and from a radio access network (RAN) node, a UE capability request; generating, at the UE, a UE capability information message by: including one of (i) a first 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, and refraining from including a different one of (i) the first UE capability or (ii) the second UE capability; and transmitting, from the UE to the RAN node responsive to the UE capability request, the UE capability information message.

[0010] In some aspects, the techniques described herein relate to a method implemented in a radio access network (RAN) node, the method including: transmitting, from the RAN node to a user equipment (UE), a UE capability enquiry; receiving, at the RAN node and responsive to the UE capability enquiry, one of (i) a first UE capability corresponding to a first UE type associated with a reduced UE capability or (ii) a second UE capability corresponding to a second UE type associated with a further reduced UE capability; and in a first instance, transmitting, from the RAN node to the UE and when receiving the first UE capability, first UE configuration parameters corresponding to the first UE type; in a second instance, transmitting, from the RAN node to the UE and when receiving the second UE capability, second UE configuration parameters corresponding to the second UE type.

BRIEF DESCRIPTION OF THE DRAWINGS

[0011] 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;

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

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

[0014] 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;

[0015] 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 PATENT APPLICATION

Attorney Docket No.: 31730/306434-00

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;

[0016] 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;

[0017] 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;

[0018] 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;

[0019] 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;

[0020] 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;

[0021] 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;

[0022] Fig. 5 is a flow diagram of an example method for receiving communication parameters from a RAN in accordance with a UE capability, which can be implemented in a UE of Fig. 1A; PATENT APPLICATION

Attorney Docket No.: 31730/306434-00

[0023] Fig. 6 is a flow diagram of an example method for determining whether to access a cell and communicate with a RAN as a UE of a first or second type, which can be implemented in a UE of Fig. 1A;

[0024] Fig. 7 A is a flow diagram of an example method for determining whether to transmit a message to the RAN including a UE capability for a first UE type or a first and second UE type based on whether the UE is a second UE type, which can be implemented in a UE of Fig. 1A;

[0025] Fig. 7B is a flow diagram of an example method similar to that of Fig. 7A, but in which the UE determines whether to transmit a UE capability for a first UE type or a second UE type;

[0026] Fig. 8A is a flow diagram of an example method for determining whether to include a UE capability for a second UE type based on whether the UE is a second UE type, which can be implemented in a UE of Fig. 1 A;

[0027] Fig. 8B is a flow diagram of an example method similar to that of Fig. 8A, but in which the UE determines whether to include a UE capability for the first UE type or the second UE type;

[0028] Fig. 9A is a flow diagram of an example method for determining whether to transmit a message to the RAN including a UE capability for a first UE type, a UE capability for a first UE type and a UE capability for a second UE type, or a UE capability for a second UE type as well as a UE capability for the first UE type and the second UE type, which can be implemented in a UE of Fig. 1A;

[0029] Fig. 9B is a flow diagram of an example method similar to that of Fig. 9A, but in which the determination is whether to transmit a message including a UE capability for a second UE type, a UE capability for a first UE type, or a UE capability for a first UE type and a UE capability for a second UE type;

[0030] Fig. 9C is a flow diagram of an example method similar to that of Fig. 9A, but in which the determination is whether to transmit a message including a UE capability for a first UE type, a UE capability for a first UE type and a UE capability for a second UE type, or a UE capability for a first UE type as well as a UE capability for a dual UE type; PATENT APPLICATION

Attorney Docket No.: 31730/306434-00

[0031] Fig. 9D is a flow diagram of an example method similar to that of Fig. 9A, but in which the determination is whether to transmit a message including a UE capability for a first UE type, a UE capability for a second UE type, or a UE capability for a first UE type as well as a UE capability for a dual UE type;

[0032] Fig. 10A is a flow diagram of an example method for determining whether to include a UE capability for a dual UE type based on whether the UE is a dual UE type UE, which can be implemented in a UE of Fig. 1 A;

[0033] Fig. 10B is a flow diagram of an example method similar to that of Fig. 10A, but in which the determination is whether to include a UE capability for a dual UE type or a UE capability for a second UE type based on whether the UE is a second UE type or dual UE type;

[0034] Fig. 11 A is a flow diagram of an example method for receiving configuration parameters not conforming to a UE capability and ignoring the configuration parameters, which can be implemented in a UE of Fig. 1 A;

[0035] Fig. 1 IB is a flow diagram of an example method similar to that of Fig. 11 A, but in which the UE determines whether to continue to communicate with the RAN after ignoring the configuration parameters or perform an RRC connection reestablishment procedure;

[0036] Fig. 12 is a flow diagram of an example method for transmitting configuration parameters to a UE for a first UE type or a second UE type, which can be implemented in a RAN node of Fig. 1A;

[0037] Fig. 13A is a flow diagram of an example method for determining whether to include a configuration parameter for a first UE type or a second UE type based on whether the RAN receives a UE capability of a UE for a second UE type, which can be implemented in a RAN node of Fig. 1A; and

[0038] Fig. 13B is a flow diagram of an example method similar to that of Fig. 13 A, but in which the determination is based on whether the RAN node receives a UE capability of a first UE type or a UE capability of a second UE type. PATENT APPLICATION

Attorney Docket No.: 31730/306434-00

DETAILED DESCRIPTION OF THE DRAWINGS

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

[0040] 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 106 A and 106B can be gNBs.

[0041] In an example communication network 100A of Fig. 1 A, 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 (IRedCap) 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 PATENT APPLICATION

Attorney Docket No.: 31730/306434-00

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 RRCReconfiguralion 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.

[0042] 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 106 A 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 106 A (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).

[0043] More particularly, when the UE 103 is in DC with the base station 104 and the base station 106A, the base station 104 operates as a master eNB (MeNB), a master ng-eNB (Mng- PATENT APPLICATION

Attorney Docket No.: 31730/306434-00 eNB), or a master gNB (MgNB), and the base station 106A operates as a secondary gNB (SgNB) or a secondary ng-eNB (Sng-eNB).

[0044] 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 part (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.

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

[0046] 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 PATENT APPLICATION

Attorney Docket No.: 31730/306434-00 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.

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

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

[0049] 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 PATENT APPLICATION

Attorney Docket No.: 31730/306434-00 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.

[0050] 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 1 1 1 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.

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

[0052] 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 PATENT APPLICATION

Attorney Docket No.: 31730/306434-00 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.

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

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

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

[0056] 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 cases, 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 PATENT APPLICATION

Attorney Docket No.: 31730/306434-00 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.

[0057] 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.”

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

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

[0060] 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 PATENT APPLICATION

Attorney Docket No.: 31730/306434-00 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.

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

[0062] 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 PATENT APPLICATION

Attorney Docket No.: 31730/306434-00

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).

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

[0064] 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 PATENT APPLICATION

Attorney Docket No.: 31730/306434-00 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.

[0065] 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. PATENT APPLICATION

Attorney Docket No.: 31730/306434-00

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

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

[0068] 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 normalcapability 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 PATENT APPLICATION

Attorney Docket No.: 31730/306434-00 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 are Fl Setup Response messages. In cases where the procedures are 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.

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

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

[0071] 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). PATENT APPLICATION

Attorney Docket No.: 31730/306434-00

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).

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

[0073] 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. PATENT APPLICATION

Attorney Docket No.: 31730/306434-00

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

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

[0076] 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 PATENT APPLICATION

Attorney Docket No.: 31730/306434-00 third UE type, the DU 174 includes an indication of the third UE type in the DU-to-CU message 322.

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

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

[0079] 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. For 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 PATENT APPLICATION

Attorney Docket No.: 31730/306434-00 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.

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

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

[0082] 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 PATENT APPLICATION

Attorney Docket No.: 31730/306434-00

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.

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

[0084] In some implementations, the DU 174 includes a first PDSCH-to-HARQ feedback timing indicator in the first DCI. 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 PATENT APPLICATION

Attorney Docket No.: 31730/306434-00 on the implementation, the HARQ feedback is a HARQ acknowledgement or a HARQ negative acknowledgement.

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

[0086] 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- PATENT APPLICATION

Attorney Docket No.: 31730/306434-00

HARQ feedback timing indicator. Depending on the implementation, the HARQ feedback is a HARQ acknowledgement or a HARQ negative acknowledgement.

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

[0088] 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 PATENT APPLICATION

Attorney Docket No.: 31730/306434-00 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.

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

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

[0091] 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 PATENT APPLICATION

Attorney Docket No.: 31730/306434-00 cases where the DU 174 configures the second CORESET or second search space for both the first UE type and third UE type.

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

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

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

[0095] In some implementations, the DU 174 broadcasts an SIB on the cell, including a third PUCCH configuration (e.g., PUCCPI-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 PATENT APPLICATION

Attorney Docket No.: 31730/306434-00 resource indicator in third DCI. Depending on the implementation, the SIB is an SIB 1 or an SIB described above.

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

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

[0098] In some implementations, the DU 174 configures a DL bandwidth pail (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.

[0099] 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. PATENT APPLICATION

Attorney Docket No.: 31730/306434-00

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.

[0100] 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 SIB1 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 PATENT APPLICATION

Attorney Docket No.: 31730/306434-00 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.

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

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

[0103] 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, PATENT APPLICATION

Attorney Docket No.: 31730/306434-00 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.

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

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

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

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

[0108] 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. PATENT APPLICATION

Attorney Docket No.: 31730/306434-00

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

[0110] 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 RRCResumeRequest 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.

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

[0112] 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. PATENT APPLICATION

Attorney Docket No.: 31730/306434-00

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

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

[0115] 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 490 a connection establishment procedure 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 (e.g., an initial UE context) for the UE 102 at the CU 172.

[0116] 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 a 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 PATENT APPLICATION

Attorney Docket No.: 31730/306434-00 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”.

[0117] 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 regardless of 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).

[0118] 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 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 UE 102 includes, in the capability container or UE Capability Information message, an indication (e.g., a UE capability) for 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 PATENT APPLICATION

Attorney Docket No.: 31730/306434-00 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).

[0119] 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 Infomation message. When the CU 172 receives the second UE capability, the CU 172 determines that the UE 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.

[0120] In some implementations, the CU 172 transmits a BS-to-CN message, including the capability container, to the CN 110 (e.g., the AMF 164). In some implementations, the CU 172 includes the capability container in an inter-node message (e.g., UERadioAccessCapabilitylnformation) and includes the inter-node message in 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 an NG application protocol (NGAP) message (e.g., as defined in 3GPP TS 38.413).

[0121] 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 PATENT APPLICATION

Attorney Docket No.: 31730/306434-00 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 DL NAS Transport message. In yet other implementations, the CN-to-BS message is an NGAP message (e.g., as defined in 3GPP TS 38.413).

[0122] In some implementations, the CU 172 transmits a CU-to-DU message, including the capability container, 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 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.

[0123] 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., RRCReconfiguration 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 capabilities of the UE 102. In some implementations, the CU 172 transmit a CU-to-DU message to the DU 174. In some such implementations, the CU 172 includes the capability container in the CU-to-DU message. In further such 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 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. PATENT APPLICATION

Attorney Docket No.: 31730/306434-00

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

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

[0126] Turning next to Fig. 5, an example method 500 can be implemented in a UE (e.g., the UE 102). The method 500 begins at block 502, where the UE communicates with a RAN (e.g., events 314, 316, 318, 328, 328, 332, 390A-F in Figs. 3A-3F, events 490, 418 in Fig. 4). At block 504, the UE transmits at least one first UE capability for a first UE type to the RAN (e.g., event 424 in Fig. 4). At block 506, the UE transmits at least one second UE capability for a second UE type to the RAN (e.g., event 424 in Fig. 4). At block 508, the UE transmits a UE capability to the RAN, indicating support for the first UE type and the second UE type (e.g., event 424 in Fig. 4). At block 510, the UE receives, from the RAN, configuration parameters for the first UE type or the second UE type (e.g., event 430 in Fig. 4). At block 512, the UE communicates with the RAN in accordance with the configuration parameters (e.g., event 432 in Fig. 4).

[0127] In some implementations, if the UE supports both the first UE type and the second UE type (i.e. , the UE is a dual UE type), the RAN configures the configuration parameters for the first UE type. Otherwise, if the UE only supports the second UE type, the RAN only configures the configuration parameters for the second UE type. In some implementations, the at least one first UE capability also applies to the second UE type. In such cases, if the UE only operates as or supports the second UE type, the UE transmits the at least one first UE capability and the at least one second UE capability to the RAN. In other implementations, UE capabilities defined or required for the first UE type do not apply to the second UE type. In such cases, if the UE only operates as or supports the second UE type, the UE transmits the at least one second UE capability to the RAN and refrains from transmitting a UE capability for the first UE type to the RAN. PATENT APPLICATION

Attorney Docket No.: 31730/306434-00

[0128] When the RAN configures configuration parameters for the first UE type, the RAN ensures that the configuration parameters conform to the at least one first UE capability and/or or predefined UE capabilities or requirements for the first type UE. When the RAN configures configuration parameters for the second UE type, the RAN ensures that the configuration parameters conform to the at least one second UE capability and/or predefined UE capabilities or requirements for the first type UE. In some implementations, the predefined UE capabilities or requirements are specifically defined UE capabilities or requirements (e.g., defined in 3GPP TS 38.306, 38.133 and/or 38.101).

[0129] In some implementations, the configuration parameters include physical layer configuration parameters. In some implementations, the UE receives an RRC message, including the configuration parameters, from the RAN. For example, the RRC message is an RRCReconfiguration message, an RRCSetup message or an RRCResume message. In other implementations, the UE receives downlink control information (DO), including the configuration parameters, from the RAN. In yet other implementations, the UE receives an RRC message, including a portion of the configuration parameters, from the RAN, and receives DCI, including the rest of the configuration parameters.

[0130] In some implementations, the first UE type and the second UE type are a RedCap UE type and an fRedCap UE type, respectively.

[0131] Turning next to Fig. 6, an example method 600 can be implemented in a UE (e.g., the UE 102). The method 600 begins at block 602, where the UE selects a cell in a RAN (e.g., events 310, 410). In some implementations, the UE selects the cell due to performing cell selection or cell rcsclcction. At block 604, the UE determines whether the cell allows UEs of a first UE type to access the cell. If the UE determines that the cell allows UEs of the first UE type to access the cell at block 604, the flow proceeds to block 606. At block 606, the UE accesses the cell and communicates with the RAN as a UE of the first UE type (e.g., events 314, 316, 318 390A-F in Figs. 3A-F, event 490 in Fig. 4). Otherwise, if the UE determines that the cell prohibits UEs of the first UE type from accessing the cell at block 604, the flow proceeds to block 608. At block 608, the UE determines whether the cell allows UEs of a second UE type to access the cell. If the UE determines that the cell allows UEs of the second UE type to access the cell at block 608, the flow proceeds to block 610. At block 610, the UE accesses the cell and PATENT APPLICATION

Attorney Docket No.: 31730/306434-00 communicates with the RAN as a UE of the second UE type. Otherwise, if the UE determines that the cell prohibits UEs of the second UE type from accessing the cell at block 608, the flow proceeds to block 612. At block 612, the UE refrains from accessing the cell.

[0132] In some implementations, one of the first UE type and the second UE type is a RedCap UE type, and the other is a IRedCap UE type. In other implementations, one of the first UE type and the second UE type is a RedCap UE type, and the other is a normal capability UE type. In yet other implementations, one of the first UE type and the second UE type is a fRedCap UE type, and the other is a normal capability UE type. In some implementations, the UE further considers UE sub-types: (e.g., 1RX, 2Rx, and HDD).

[0133] In some implementations, the UE receives system information (e.g., one or more SIBs) from the RAN on the cell (e.g., event 312). The system information includes first information indicating whether UEs of the first UE type are allowed to access the cell and includes second information indicating whether UEs of the second UE type are allowed to access the cell. In some implementations, the system information includes an IE or field (also rc I erred to herein as “lE/field”) that includes the first information and the second information. In other implementations, the system information includes a first lE/field and a second lE/field including the first information and the second information, respectively.

[0134] Turning next to Fig. 7A, an example method 700A can be implemented in a UE (e.g., the UE 102). The method 700A begins at block 702, where the UE communicates with a RAN (e.g., events 314, 316, 318, 328, 332, 390A-F in Figs. 3A-F, events 490, 418, 422 in Fig. 4). At block 704, the UE determines whether the UE is a second UE type. If the UE determines that the UE is the second UE type at block 704, the flow proceeds to block 706. At block 706, the UE transmits a message to the RAN, where the message includes at least one UE capability for the first UE type and includes at least one UE capability for the second UE type (e.g., event 424 in Fig. 4). Otherwise, if the UE determines that the UE is not the second UE type at block 704 (e.g., the UE determines that the UE is a first UE type), the flow proceeds to block 708. At block 708, the UE transmits a message to the RAN, where the message includes at least one UE capability for the first UE type and does not include a UE capability for the second UE type (e.g., event 424 in Fig. 4). PATENT APPLICATION

Attorney Docket No.: 31730/306434-00

[0135] In some implementations, the first UE type and the second UE type are a RedCap UE type and a fRedCap UE type, respectively. In some implementations, the at least one UE capability for the first UE type applies to the second UE type. Thus, even if the UE is the second UE type, the UE transmits the at least one UE capability for the first UE type to the RAN. In some implementations, when the RAN receives the at least one UE capability for the first UE type and the at least one UE capability for the second UE type, the RAN determines that the UE is the second UE type and is not the first UE type. When the RAN receives the at least one UE capability for the first UE type and does not receive a UE capability for the second UE type from the UE, the RAN determines that the UE is the first UE type.

[0136] Fig. 7B is a flow diagram of an example method 700B similar to the method 700A, except that the method 700B includes block 707 instead of block 706. If the UE determines that the UE is not the second UE type at block 704 (e.g., the UE determines that the UE is a first UE type), the flow proceeds to block 707. At block 707, the UE transmits a message to the RAN, where the message includes at least one UE capability for the second UE type and does not include a UE capability for the first UE type (e.g., event 424 in Fig. 4).

[0137] Unlike Fig. 7A, the at least one UE capability for the first UE type does not apply to the second UE type. Thus, when the UE is one of the first UE type or the second UE type, the UE refrains from transmitting a UE capability for the other UE type to the RAN.

[0138] Turning next to Fig. 8A, an example method 800A can be implemented in a UE (e.g., the UE 102). The method 800A begins at block 802, where the UE communicates with a RAN (e.g., events 314, 316, 318, 328, 332, 390A-F in Figs. 3A-F, events 490, 418, 422 in Fig. 4). At block 804, the UE includes at least one UE capability for a first UE type in a message. At block 806, the UE determines whether the UE is a second UE type. If the UE determines that the UE is the second UE type at block 806, the flow proceeds to block 808. At block 808, the UE includes at least one UE capability for the second UE type in the message. The flow proceeds to block 810 from block 808. Otherwise, if the UE determines that the UE is not the second UE type at block 806 (e.g., the UE determines that the UE is a first UE type), the flow skips block 808 and proceeds to block 810. At block 810, the UE transmits the message to the RAN (e.g., event 424 in Fig. 4). PATENT APPLICATION

Attorney Docket No.: 31730/306434-00

[0139] In some implementations, the at least one UE capability for the first UE type applies to the second UE type. Thus, even if the UE is the second UE type, the UE transmits the at least one UE capability to the RAN.

[0140] Fig. 8B is a flow diagram of an example method 800B similar to the method 800A. The flow proceeds to block 806 from block 802. If the UE determines that the UE is not the second UE type at block 806 (e.g., the UE determines that the UE is a first UE type), the flow proceeds to block 804. The flow proceeds to block 810 from block 804.

[0141] Unlike Fig. 8A, the at least one UE capability for the first UE type does not apply to the second UE type. Likewise, the at least one UE capability for the second UE type does not apply to the first UE type. Thus, when the UE is one of the first UE type or the second UE type, the UE refrains from transmitting a UE capability for the other UE type to the RAN.

[0142] Turning now to Fig. 9A, an example method 900A can be implemented in a UE (e.g., the UE 102). The method 900A begins at block 902, where the UE communicates with a RAN (e.g., events 314, 316, 318, 328, 332, 390A-F in Figs. 3A-F, events 490, 418, 422 in Fig. 4). At block 904, the UE determines whether the UE is a first UE type, a second UE type, or a dual UE type. If the UE determines that the UE is the second UE type at block 904, the flow proceeds to block 906. At block 906, the UE transmits a message to the RAN, where the message includes at least one UE capability for the first UE type and includes at least one UE capability for the second UE type (e.g., event 424 in Fig. 4). If the UE determines that the UE is the first UE type at block 904, the flow proceeds to block 908. At block 908, the UE transmits a message to the RAN, where the message includes at least one UE capability for the first UE type and does not include a UE capability for the second UE type (e.g., event 424 in Fig. 4). If the UE determines that the UE is the dual UE type at block 904, the flow proceeds to block 910. At block 910, the UE transmits a message to the RAN, where the message includes the at least one UE capability for the first UE type, the at least one UE capability for the second UE type, and a UE capability indicating support for the first UE type and the second UE type (e.g., event 424 in Fig. 4).

[0143] Examples and implementations described for Fig. 7A can apply to Fig. 9A.

[0144] When the RAN receives the at least one UE capability for the first UE type, the at least one UE capability for the second UE type, and the UE capability indicating support for the first PATENT APPLICATION

Attorney Docket No.: 31730/306434-00

UE type and the second UE type, the RAN determines to communicate with the UE using configuration parameters that conform to the at least one UE capability, predefined UE capabilities, and/or requirements for the first type UE or the second UE type.

[0145] Fig. 9B is a flow diagram of an example method 900B similar to the method 900A, except that the method 900B includes block 907 instead of block 910. If the UE determines that the UE is a second UE type at block 904, the flow proceeds to block 907. At block 907, the UE transmits a message to the RAN, where the message includes at least one UE capability for the second UE type and does not include a UE capability for the first UE type (e.g., event 424 in Fig. 4). If the UE determines that the UE is a dual UE type at block 904, the flow proceeds to block

906.

[0146] Unlike Fig. 9A, the at least one UE capability for the first UE type does not apply to the second UE type. Thus, when the UE is the second UE type, the UE refrains from transmitting a UE capability for the for the first UE type to the RAN.

[0147] Fig. 9C is a flow diagram of an example method 900C similar to the method 900A-B, except that the method 900C includes block 911 instead of block 910. If the UE determines that the UE is a dual UE type at block 904, the flow proceeds to block 911. At block 911, the UE transmits a message to the RAN, where the message includes at least one UE capability for the first UE type and at least one UE capability for the dual UE type (e.g., event 424 in Fig. 4). In some implementations, in cases where the UE is the dual UE type, the UE does not transmit or refrains from transmitting a UE capability specific for the second UE type to the RAN. In other implementations, in cases where the UE is the dual UE type, the UE transmits a UE capability specific for the second UE type to the RAN.

[0148] Fig. 9D is a flow diagram of an example method 900D similar to the method 900A-C. If the UE determines that the UE is a second UE type at block 904, the flow proceeds to block

907. If the UE determines that the UE is a dual UE type at block 904, the flow proceeds to block 911.

[0149] Turning now to Fig. 10A, an example method 1000A can be implemented in a UE (e.g., the UE 102). The method 1000A begins at block 1002, where the UE communicates with a RAN (e.g., events 314, 316, 318, 328, 332, 390A-F in Figs. 3A-F, events 490, 418, 422 in Fig. PATENT APPLICATION

Attorney Docket No.: 31730/306434-00

4). At block 1004, the UE includes at least one UE capability for a first UE type in a message.

At block 1006, the UE includes at least one UE capability for a second UE type in a message. At block 1008, the UE determines whether the UE is a dual UE type. If the UE determines that the UE is the dual UE type at block 1008, the flow proceeds to block 1010. At block 1010, the UE includes at least one UE capability for the dual UE type in the message. The flow proceeds to block 1012 from block 1010. Otherwise, if the UE determines that the UE is not the dual UE type at block 1008 (e.g., the UE is either the first UE type or the second UE type), the flow skips block 1010 and proceeds to block 1012. At block 1012, the UE transmits the message to the RAN (e.g., event 424 in Fig. 4).

[0150] Fig. 10B is a flow diagram of an example method 1000B similar to the method 1000A, except that the method 1000B includes block 1009 instead of block 1008. The flow proceeds to block 1009 from block 1004. If the UE determines that the UE is the dual UE type at block 1009, the flow proceeds to block 1010. If the UE determines that the UE is the second UE type, the flow proceeds to block 1006. The flow proceeds to block 1012 from blocks 1010 and 1006.

[0151] Unlike Fig. 10A, the at least one UE capability for the first UE type does not apply to the second UE type. Likewise, the at least one UE capability for the second UE type does not apply to the first UE type. Thus, when the UE is one of the first UE type or the second UE type, the UE refrains from transmitting a UE capability for the other UE type to the RAN.

[0152] Example and implementations described above can apply to Figs. 10A and 10B.

[0153] Turning now to Fig. 11 A, an example method 1100A can be implemented in a UE (e.g., the UE 102). The method 1100A begins at block 1102, where the UE communicates with a RAN (e.g., events 314, 316, 318, 328, 332, 390A-F in Figs. 3A-F, events 490, 418, 422 in Fig.

4). At block 1104, the UE transmits at least one RedCap UE capability to the RAN (e.g., event 424 in Fig. 4). At block 1106, the UE transmits at least one fRedCap UE capability to the RAN (e.g., event 424 in Fig. 4). At block 1108, the UE receives, from the RAN, configuration parameters not conforming to the at least one RedCap UE capability and/or the at least one fRedCap UE capability (e.g., event 430 in Fig. 4). At block 1010, the UE ignores or discards the configuration parameters. At block 1012, the UE continues to communicate with the RAN after ignoring or discarding the configuration parameters. PATENT APPLICATION

Attorney Docket No.: 31730/306434-00

[0154] Fig. 1 IB is a flow diagram of an example method 1100B similar to the method 1100A, except that the method 1100B includes blocks 1111 and 1114. At block 1111, the UE determines whether the UE receives the configuration parameters in an RRC message. If the UE determines that the UE receives the configuration parameters not in an RRC message at block 1111 (e.g., the UE receives the configuration parameters in a DCI), the flow proceeds to block 1112. Otherwise, if the UE determines that the UE receives the configuration parameters in an RRC message at block 1111, the flow proceeds to block 1114. At block 1114, the UE performs a RRC connection reestablishment procedure.

[0155] In some implementations, in the RRC connection reestablishment procedure, the UE transmits an RRCReestablishmentRequest message to the RAN, receives an RRCReestablishment message from the RAN, and transmits an RRCReestablishmentComplete message to the RAN.

[0156] Example and implementations described above can apply to Figs. 11 A and 1 IB.

[0157] Turning now to Fig. 12, an example method 1200 can be implemented in a RAN node (e.g., the DU 174, 174A, or 174B of the base station 104, 106A, or 106B, or the base station 104, 106A, or I06B). The method 1200 begins at block 1202, 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 1204, the RAN node receives at least one first UE capability of the UE for a first UE type (e.g., event 424 or 416 in Fig. 4). At block 1206, the RAN node receives at least one second UE capability of the UE for a second UE type (e.g., event 424 or 416 in Fig. 4). At block 1208, the RAN node receives a UE capability of the UE, indicating support for the first UE type and the second UE type (e.g., event 424 or 416 in Fig. 4). At block 1210, the RAN node transmits, to the UE, configuration parameters for the first UE type or the second UE type (e.g., event 430 in Fig. 4). At block 1212, the RAN communicates with the UE in accordance with the configuration parameters (e.g., event 432 in Fig. 4).

[0158] In some implementations, the RAN node receives the at least one first UE capability, the at least one second UE capability, and the UE capability from the UE. In other implementations, the RAN node receives the at least one first UE capability, the at least one second UE capability, and the UE capability from a CN (e.g., the CN 110 or AMF 164). In some implementations, in cases where the RAN node is a DU, the DU receives the at least one first UE capability, the at least one second UE capability, and the UE capability from a CU. In some PATENT APPLICATION

Attorney Docket No.: 31730/306434-00 implementations, the CU receives the at least one first UE capability, the at least one second UE capability, and the UE capability from the UE or the CN. In some implementations, the DU transmits the configuration parameters to the UE via a protocol (e.g., PHY 202B or MAC 204B) between the UE and the DU. In other implementations, the DU transmits the configuration parameters to the UE via a protocol (e.g., RRC 214) between the UE and the CU.

[0159] Turning next to Fig. 13 A, an example method 1300A can be implemented in a RAN node (e.g., the DU 174, 174A, or 174B of the base station 104, 106A, or 106B, or the base station 104, 106A, or 106B). The method 1300A begins at block 1302, where the RAN node receives at least one UE capability of the UE for a first UE type (e.g., event 424 or 416 in Fig. 4). At block 1304, the RAN node determines whether the RAN node receives a UE capability of the UE for a second UE type. If the RAN determines that the RAN node does not receive a UE capability of the UE for a second UE type at block 1304, the flow proceeds to block 1306. At block 1306, the RAN node transmits at least one first configuration parameter for the first UE type to the UE (e.g., event 430 in Fig. 4). At block 1308, the RAN node communicates with the UE in accordance with the at least one first configuration parameter (e.g., event 432 in Fig. 4). Otherwise, if the RAN determines that the RAN node receives a UE capability of the UE for a second UE type at block 1304, the flow proceeds to block 1310. At block 1310, the RAN node transmits at least one second configuration parameter for the second UE type to the UE (e.g., event 430 in Fig. 4). At block 1312, the RAN node communicates with the UE in accordance with the at least one second configuration parameter (e.g., event 432 in Fig. 4).

[0160] 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 1305 instead of blocks 1302 and 1304. The method 1300B begins at block 1303, where the flow starts. At block 1305, the RAN node determines whether the RAN node receives a UE capability for a first UE type or a UE capability of the UE for a second UE type. If the RAN node determines that the RAN node receives a UE capability of the UE for the first UE type, the flow proceeds to blocks 1306 and 1308.

Otherwise, if the RAN node determines that the RAN node receives a UE capability of the UE for the second UE type, the flow proceeds to blocks 1310 and 1312.

[0161] Example and implementations described above can apply to Figs. 12-13B. PATENT APPLICATION

Attorney Docket No.: 31730/306434-00

[0162] Example 1. A method implemented in a user equipment (UE), the method comprising: receiving, at the UE and from a radio access network (RAN) node, a UE capability request; generating, at the UE, a UE capability information message by: including one of (i) a first 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, and refraining from including a different one of (i) the first UE capability or (ii) the second UE capability; and transmitting, from the UE to the RAN node responsive to the UE capability request, the UE capability information message.

[0163] Example 2. The method of example 1, further comprising: receiving, at the UE from the RAN node and in accordance with the UE capability information message, UE configuration parameters corresponding to one of the first UE type or the second UE type.

[0164] Example 3. The method of example 2, further comprising: determining, at the UE, whether to continue communicating with the RAN node based on whether the receiving the UE configuration parameters includes receiving a radio resource message containing the UE configuration parameters.

[0165] Example 4. The method of example 3, further comprising: in a first instance: discarding, at the UE, the UE configuration parameters when the receiving the UE configuration parameters does not include receiving the radio resource message, and continuing, at the UE, to communicate with the RAN node; and in a second instance: performing, at the UE, a reestablishment procedure with the RAN node when the receiving the UE configuration parameters does include receiving the radio resource message.

[0166] Example 5. The method of any one of examples 1-4, wherein the generating is based on whether the UE has the first UE type or the second UE type.

[0167] Example 6. The method of any one of examples 1-4, wherein the generating occurs in a first instance and the method further comprises: in a second instance, generating the UE capability information message by: including a third UE capability for a third UE type associated with a normal UE capability, and refraining from including the first UE type and the second UE type. PATENT APPLICATION

Attorney Docket No.: 31730/306434-00

[0168] Example 7. The method of example 6, wherein the generating is based on whether the UE has the first UE type, the second UE type, or the third UE type.

[0169] Example 8. An apparatus, operating as a user equipment (UE), comprising processing hardware and configured to implement a method according to any one of the preceding examples.

[0170] Example 9. A method implemented in a radio access network (RAN) node, the method comprising: transmitting, from the RAN node to a user equipment (UE), a UE capability enquiry; receiving, at the RAN node and responsive to the UE capability enquiry, one of (i) a first UE capability corresponding to a first UE type associated with a reduced UE capability or (ii) a second UE capability corresponding to a second UE type associated with a further reduced UE capability; and in a first instance, transmitting, from the RAN node to the UE and when receiving the first UE capability, first UE configuration parameters corresponding to the first UE type; in a second instance, transmitting, from the RAN node to the UE and when receiving the second UE capability, second UE configuration parameters corresponding to the second UE type.

[0171] Example 10. The method of example 9, wherein the receiving the first UE capability or the second UE capability includes receiving a UE capability container including the first UE capability or the second UE capability.

[0172] Example 11. The method of example 10, wherein the UE capability container is a UE- CapabilityRAT-ContainerList information element (IE).

[0173] Example 12. The method of either of example 10 or 11, further comprising: transmitting, from the RAN node to a core network (CN), the UE capability container.

[0174] Example 13. The method of any one of examples 9-12, wherein the UE is a first UE, further comprising: receiving, at the CU, a third UE capability corresponding to a third UE type for a second UE, the third UE type associated with a normal UE capability; and transmitting, to the UE, normal UE configuration parameters corresponding to the third UE type.

[0175] Example 14. The method of any one of examples 9-12, wherein the configuration parameters are associated with at least one of a physical layer configuration or a cell configuration. PATENT APPLICATION

Attorney Docket No.: 31730/306434-00

[0176] Example 15. An apparatus, operating as a distributed radio access network (RAN) node, comprising processing hardware and configured to implement a method according to any one of examples 9-14.

[0177] Example 16. A method implemented in a radio access network (RAN) node, the method comprising: receiving, at the RAN node and from the CN, one of (i) a first UE capability corresponding to a first UE type associated with a reduced UE capability or (ii) a second UE capability corresponding to a second UE type associated with a further reduced UE capability; and in a first instance, transmitting, from the RAN node to the UE and when receiving the first UE capability, first UE configuration parameters corresponding to the first UE type; in a second instance, transmitting, from the RAN node to the UE and when receiving the second UE capability, second UE configuration parameters corresponding to the second UE type.

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

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

[0180] 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 PATENT APPLICATION

Attorney Docket No.: 31730/306434-00 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.

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

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

[0183] 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 variations, 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

PATENT APPLICATION Attorney Docket No.: 31730/306434-00 What is claimed is:

1. A method implemented in a user equipment (UE), the method comprising: receiving, at the UE and from a radio access network (RAN) node, a UE capability request; generating, at the UE, a UE capability information message by: including one of (i) a first 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, and refraining from including a different one of (i) the first UE capability or (ii) the second UE capability; and transmitting, from the UE to the RAN node responsive to the UE capability request, the UE capability information message.

2. The method of claim 1, further comprising: receiving, at the UE from the RAN node and in accordance with the UE capability information message, UE configuration parameters corresponding to one of the first UE type or the second UE type.

3. The method of claim 2, further comprising: determining, at the UE, whether to continue communicating with the RAN node based on whether the receiving the UE configuration parameters includes receiving a radio resource message containing the UE configuration parameters.

4. The method of claim 3, further comprising: in a first instance: discarding, at the UE, the UE configuration parameters when the receiving the UE configuration parameters does not include receiving the radio resource message, and continuing, at the UE, to communicate with the RAN node; and in a second instance: PATENT APPLICATION

Attorney Docket No.: 31730/306434-00 performing, at the UE, a reestablishment procedure with the RAN node when the receiving the UE configuration parameters does include receiving the radio resource message.

5. The method of any one of claims 1-4, wherein the generating is based on whether the UE has the first UE type or the second UE type.

6. The method of any one of claims 1-4, wherein the generating occurs in a first instance and the method further comprises: in a second instance, generating the UE capability information message by: including a third UE capability for a third UE type associated with a normal UE capability, and refraining from including the first UE type and the second UE type.

7. The method of any one of claims 1-6, further comprising: selecting a cell of the RAN node; in a first instance, when the UE has the first UE type and the cell allows access to the first UE type, accessing the cell and communicating with the RAN node via the cell as the first UE type; in a second instance, when the UE has the second UE type and the cell allows access to the second UE type, accessing the cell and communicating with the RAN node via the cell as the second UE type.

8. An apparatus, operating as a user equipment (UE), comprising processing hardware and configured to implement a method according to any one of the preceding claims.

9. A method implemented in a radio access network (RAN) node, the method comprising: transmitting, from the RAN node to a user equipment (UE), a UE capability enquiry; receiving, at the RAN node and responsive to the UE capability enquiry, one of (i) a first UE capability corresponding to a first UE type associated with a reduced UE capability or (ii) a PATENT APPLICATION

Attorney Docket No.: 31730/306434-00 second UE capability corresponding to a second UE type associated with a further reduced UE capability; and in a first instance, transmitting, from the RAN node to the UE and when receiving the first UE capability, first UE configuration parameters corresponding to the first UE type; in a second instance, transmitting, from the RAN node to the UE and when receiving the second UE capability, second UE configuration parameters corresponding to the second UE type.

10. The method of claim 9, wherein the receiving the first UE capability or the second UE capability includes receiving a UE capability container including the first UE capability or the second UE capability.

11. The method of claim 10, wherein the UE capability container is a UE- CapabilityRAT-ContainerList information element (IE).

12. The method of either of claim 10 or 11, further comprising: transmitting, from the RAN node to a core network (CN), the UE capability container.

13. The method of any one of claims 9-12, wherein the UE is a first UE, further comprising: receiving, at the CU, a third UE capability corresponding to a third UE type for a second UE, the third UE type associated with a normal UE capability; and transmitting, to the UE, normal UE configuration parameters corresponding to the third UE type.

14. The method of any one of claims 9-12, wherein the configuration parameters are associated with at least one of a physical layer configuration or a cell configuration.

15. An apparatus, operating as a distributed radio access network (RAN) node, comprising processing hardware and configured to implement a method according to any one of claims 9-14.