Enabling communications for user equipments with further reduced capabilities

Abstract

A method in a user equipment (UE) for transmitting capability information of the UE includes receiving, at the UE, a UE capability request from a radio access network (RAN) node; generating a UE capability information message at the UE by including one of (i) a first UE capability of a first UE type associated with a reduced UE capability, or (ii) a second UE capability of a second UE type associated with a further reduced UE capability, and avoiding including a different of (i) the first UE capability or (ii) the second UE capability; and transmitting the UE capability information message from the UE to the RAN node in response to the UE capability request.

Description

[0001] Cross-references to related applications

[0002] This application claims priority and benefit to Provisional U.S. Patent Application No. 63 / 532,002, filed August 10, 2023, entitled “Enabling Communication for a FURTHER REDUCED CAPABILITY USER EQUIPMENT”. The entire contents of that provisional application are hereby expressly incorporated herein by reference. Technical Field

[0003] This disclosure relates to wireless communications, and more specifically to enabling communications for user equipment (UE) with further reduced capabilities (fRedCap). Background Technology

[0004] The background description provided herein is for the purpose of presenting the general context of this disclosure. The work of the currently named inventors (to the extent described in this background section) and aspects of the specification that might not have been considered prior art at the time of filing are neither expressly nor impliedly acknowledged as prior art to this disclosure.

[0005] In telecommunications systems, the Packet Data Convergence Protocol (PDCP) sublayer of the radio protocol stack provides services such as user plane data transmission, encryption, and integrity protection. For example, the PDCP layer for the Evolved Universal Terrestrial Radio Access (EUTRA) radio interface and New Radio (NR) definitions provides the sequencing of Protocol Data Units (PDUs) in the uplink direction (from the user equipment (UE) to the base station) and in the downlink direction (from the base station to the UE). Furthermore, the PDCP sublayer provides Signaling Radio Bearer (SRB) services to the Radio Resource Control (RRC) sublayer. The PDCP sublayer also provides Data Radio Bearer (DRB) services to the Serving Data Adaptation Protocol (SDAP) sublayer or protocol layers such as the Internet Protocol (IP) layer, Ethernet layer, and Internet Control Message Protocol (ICMP) layer. Generally, the UE and base station use SRBs to exchange RRC messages and Non-Access Stratum (NAS) messages, and use DRBs to transmit data on the user plane.

[0006] Base stations operating according to modern requirements support greater bandwidth than those operating according to older requirements. Therefore, a User Equipment Unit (UE) can support 100 MHz bandwidth in frequency range 1 (FR1) and 400 MHz bandwidth in frequency range 2 (FR2).

[0007] However, UEs with normal capabilities (i.e., UEs compliant with older requirements) can coexist with UEs with reduced capabilities. Compared to UEs with normal capabilities, UEs with reduced capabilities (also known as RedCap UEs) tend to have lower bandwidth capabilities, reduced processing power, and / or fewer antennas. Depending on the device, RedCap UEs also lack support for dual connectivity and / or carrier aggregation. RedCap UEs have established a framework for enabling NR devices with reduced capabilities suitable for a range of use cases, including industrial sensors, video surveillance, and wearable devices, where low UE complexity and sometimes low power consumption are required. However, techniques are needed to determine whether a UE is a UE with normal capabilities, a RedCap UE configured according to older protocols, or a RedCap UE configured according to modern protocols. Summary of the Invention

[0008] To further expand the market for RedCap use cases, which are relatively low-cost, low-power, and have low data rate requirements, technologies are needed to support UEs with further reduced complexity. Specifically, RedCap should provide NR support for lower-level devices between existing low-power wide-area (LPWA) UEs and RedCap UEs. The target peak data rate supported by RedCap UEs is 10 Mbps lower than the peak data rate supported by older RedCap UEs.

[0009] If a base station does not know whether a UE is a capable UE, an older RedCap UE, or a more modern RedCap UE, it may attempt to communicate with the modern RedCap UE in a manner that the UE does not support. Alternatively, a base station that mistakenly assumes a particular UE is a modern RedCap UE may unnecessarily avoid using NR technologies and features when communicating with the UE, leading to inefficiency.

[0010] In some aspects, the technology described herein relates to a method implemented in a user equipment (UE), the method comprising: receiving a UE capability request from a radio access network (RAN) node at the UE; generating a UE capability information message at the UE by including one of: (i) a first UE capability of a first UE type associated with a reduced UE capability, or (ii) a second UE capability of a second UE type associated with a further reduced UE capability, and avoiding including a different item of: (i) the first UE capability or (ii) the second UE capability; and transmitting the UE capability information message from the UE to the RAN node in response to the UE capability request.

[0011] In some aspects, the technology described herein relates to a method implemented in a radio access network (RAN) node, the method comprising: transmitting a UE capability query from the RAN node to a user equipment (UE); receiving at the RAN node, in response to the UE capability query, one of the following: (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 a first UE configuration parameter corresponding to the first UE type from the RAN node to the UE when the first UE capability is received; and in a second instance, transmitting a second UE configuration parameter corresponding to the second UE type from the RAN node to the UE when the second UE capability is received. Attached Figure Description

[0012] Figure 1A This is a block diagram of an example system in which the RAN implements the technology disclosed herein for identifying different types of UEs;

[0013] Figure 1B The central unit (CU) and distributed unit (DU) can be located within this unit. Figure 1A A block diagram of an example base station operating in the system;

[0014] Figure 2A This is a block diagram of an example protocol stack. Figure 1A The UE communicates with the base station according to this protocol stack;

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

[0016] Figure 3A This is a message passing diagram of an example scenario in which the DU receives a MAC PDU including an RRC request and a Logical Channel Identifier (LCID), determines the UE type based on the LCID and indicates different types to the CU, and the CU determines the UE type based on the indicated type;

[0017] Figure 3B This is a message passing diagram of an example scenario in which the DU receives a MAC PDU including an RRC request and a Logical Channel Identifier (LCID), determines the UE type based on the LCID and indicates the determined type to the CU, and the CU determines the UE type based on the indicated type;

[0018] Figure 3CThis is a message passing diagram of an example scenario in which the base station receives an RRC request from the UE, determines the UE type based on the random access preamble or random access resources, indicates different types to the CU, and the CU determines the UE type based on the indicated type.

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

[0020] Figure 3E This is a message passing diagram of an example scenario in which the DU receives a MAC PDU including an RRC request and a Logical Channel Identifier (LCID), determines the UE type based on the LCID and indicates different types to the CU, and the CU determines the UE type based on the RRC request;

[0021] Figure 3F This is a message passing diagram of an example scenario in which the DU receives a MAC PDU including an RRC request and a Logical Channel Identifier (LCID), determines the UE type based on a random access preamble or random access resources, indicates different types to the CU, and the CU determines the UE type based on the RRC request;

[0022] Figure 4 This is a message passing diagram of an example scenario in which the UE, DU, CU, and CN perform connection establishment, data communication, and connection release operations to transmit information about the UE's capabilities from the UE to the CN;

[0023] Figure 5 This is a flowchart of an example method for receiving communication parameters from the RAN based on the UE's capabilities. Figure 1A Implemented in the UE;

[0024] Figure 6 This is a flowchart illustrating an example method for determining whether a UE is accessing a cell as a first-type or second-type UE and communicating with the RAN. This method can be implemented in... Figure 1A Implemented in the UE;

[0025] Figure 7A This is a flowchart of an example method for determining whether to transmit a message to the RAN containing either a first UE type or both a first and a second UE type based on whether the UE is a second UE type. This method can... Figure 1A Implemented in the UE;

[0026] Figure 7B Is with Figure 7AA flowchart illustrating a similar but different example method for determining whether the UE is transmitting UE capabilities of either the first or second UE type;

[0027] Figure 8A This is a flowchart of an example method for determining whether to include UE capabilities of a second UE type based on whether the UE is a second UE type. This method can... Figure 1A Implemented in the UE;

[0028] Figure 8B Is with Figure 8A A flowchart illustrating a similar but different example method for determining whether a UE capability includes a first UE type or a second UE type;

[0029] Figure 9A This is a flowchart of an example method for determining whether to transmit a message to the RAN including UE capabilities of a first UE type, UE capabilities of a first UE type and UE capabilities of a second UE type, or UE capabilities of a second UE type and UE capabilities of both the first UE type and the second UE type. This method can... Figure 1A Implemented in the UE;

[0030] Figure 9B Is with Figure 9A A flowchart of an example method that is similar to, but determines, whether to transmit a message that includes UE capabilities of a second UE type, UE capabilities of a first UE type, or UE capabilities of both the first and second UE types;

[0031] Figure 9C Is with Figure 9A A flowchart of an example method for transmitting messages that include UE capabilities of a first UE type, UE capabilities of a first UE type and UE capabilities of a second UE type, or UE capabilities of a first UE type and UE capabilities of both UE types;

[0032] Figure 9D Is with Figure 9A A flowchart of an example method that is similar to, but specifically determines, whether to transmit messages including UE capabilities of a first UE type, UE capabilities of a second UE type, or UE capabilities of a first UE type and UE capabilities of both UE types;

[0033] Figure 10A This is a flowchart of an example method for determining whether to include dual-UE type UE capabilities based on whether the UE is a dual-UE type UE. This method can be implemented in... Figure 1A Implemented in the UE;

[0034] Figure 10B Is with Figure 10AA flowchart of an example method for determining whether to include UE capabilities of dual UE types or UE capabilities of the second UE type based on whether the UE is a second UE type or a dual UE type;

[0035] Figure 11A This is a flowchart of an example method for receiving configuration parameters that do not conform to UE capabilities and ignoring those parameters. This method can be used in... Figure 1A Implemented in the UE;

[0036] Figure 11B Is with Figure 11A A similar flowchart illustrates how the UE determines whether to continue communicating with the RAN after ignoring configuration parameters or to execute the RRC connection reconstruction process.

[0037] Figure 12 This is a flowchart of an example method for transmitting configuration parameters to a UE of a first UE type or a second UE type. This method can... Figure 1A Implemented in RAN nodes;

[0038] Figure 13A This is a flowchart of an example method for determining whether to include configuration parameters for the first or second UE type based on whether the RAN receives the UE capability of a UE of the second UE type. This method can be used in... Figure 1A Implemented in RAN nodes; and

[0039] Figure 13B Is with Figure 13A A similar flowchart illustrates an example method for determining whether the RAN node receives UE capabilities of the first UE type or the second UE type. Detailed Implementation

[0040] Generally speaking, the technology disclosed herein enables the RAN to determine whether the UE is a UE with reduced capabilities or a UE with normal capabilities.

[0041] Figure 1A An example wireless communication system 100 is depicted, which can communicate with both UEs with reduced capabilities and UEs with normal capabilities, based on the techniques and capabilities described in this disclosure. The wireless communication system 100 includes UEs 102 and 103 and base stations 104, 106A, and 106B connected to a core network (CN) 110 via a radio access network (RAN) (e.g., RAN 105). Base stations 104, 106A, and 106B can be any one or more suitable types of base stations, such as, for example, evolved Node B (eNB), next-generation eNB (ng-eNB), or 5G Node B (gNB). As a more specific example, base station 104 can be an eNB or a gNB, and base stations 106A and 106B can be gNBs.

[0042] exist Figure 1AIn the example communication network 100A, UE 101 is a RedCap UE, UE 102 is a further RedCap UE, and UE 103 is a normal-capability UE. For example, UE 101 may comply with the RedCap requirements described in various standard documents (e.g., 3GPP Technical Specification (TS) 38.306, RP-201368, R1-2005233, 3GPP Technical Report (TR) 38.875 and / or the protocols in RAN1#101-e and RAN1#102-e meetings). In another example, UE 102 may comply with the further RedCap (fRedCap) requirements described in standard documents (e.g., RP-223544 and / or RP-231488). In contrast, UE 102 may meet the requirements of 5G NR's Evolved Mobile Broadband (eMBB) or Ultra Reliable Low Latency Communication (URLLC) and support 100 MHz BW in FR1 for the available bands of 100 MHz channels, 400 MHz BW bandwidth in FR2 (if implemented in UE 103), and / or support four-layer multiple-input multiple-output (MIMO) functionality in the high-frequency bands of FR1. In some embodiments, UE 101 is a RedCap UE due to hardware constraints. In other embodiments, UE 102 is an fRedCap UE due to hardware constraints. In yet another embodiment, UE 102 includes hardware capable of supporting both RedCap UE and fRedCap UE capabilities. In one implementation where such a case exists, UE 102 is configured (e.g., via software settings) to operate as either a RedCap UE or an fRedCap UE. In other implementations, when UE 102 is camped on the cell of RAN 105, UE 102 determines whether to operate as a RedCap UE or an fRedCap UE based on system information received on that cell. In yet another implementation, UE 102 operates as a RedCap UE or an fRedCap UE depending on the configuration received from RAN 105. For example, if UE 102 receives a configuration including RedCap UE configuration parameters, UE 102 operates as a RedCap UE and communicates with RAN 105 according to those parameters. If UE 102 receives a configuration including fRedCap UE configuration parameters, UE 102 operates as an fRedCap UE and communicates with RAN 105 according to those parameters. In some implementations, UE 102 receives a dedicated message including that configuration from a base station of RAN 105 (e.g., base station 104, 106A, or 106B).For example, dedicated messages are RRC messages, such as RRCReconfiguration, RRCSetup, or RRCResume. Although three UE capability types have been discussed throughout this disclosure, the described techniques are applicable to distinguishing a greater number of UE capability types should more UE capability types be defined in the future.

[0043] Base station 104 supports cell 124, base station 106A supports cell 126A, and base station 106B supports cell 126B. Cell 124 partially overlaps with cells 126A and 126B, allowing UEs 101, 102, or 103 to be within range of communication with base station 104 while simultaneously being within range of communication with base station 106A or 106B (or within range of detecting or measuring signals from both base stations 106A and 106B). For example, this overlap allows UEs 101, 102, or 103 to handover between cells (e.g., from cell 124 to cell 126A or 126B) or between base stations (e.g., from base station 104 to base station 106A or 106B) before UE 102 experiences a radio link failure. Furthermore, this overlap allows for various dual-connectivity (DC) scenarios discussed below. For example, UE 103 can communicate with base station 104 (operating as MN) and base station 106A (operating as SN) in the DC, and after completing the handover to base station 106B, it can communicate with base station 106B (operating as MN). As another example, UE 103 can communicate with base station 104 (operating as MN) and base station 106A (operating as SN) in the DC, and after completing the SN change, it can communicate with base station 104 (operating as MN) and base station 106B (operating as SN).

[0044] More specifically, when UE 103 is in a DC with base station 104 and base station 106A, base station 104 operates as a primary eNB (MeNB), primary ng-eNB (Mng-eNB), or primary gNB (MgNB), and base station 106A operates as a secondary gNB (SgNB) or secondary ng-eNB (Sng-eNB).

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

[0046] Base station 104 includes processing hardware 130, which may include one or more general-purpose processors (e.g., central processing unit (CPU)) and computer-readable memory storing machine-readable instructions that can be executed on one or more general-purpose processors, and / or dedicated processing units. Figure 1A In the example implementation, the processing hardware 130 includes a base station communication controller 132 configured to communicate with a capable UE, a RedCap UE, and / or a further RedCap UE. For example, the base station communication controller 132 may be configured to support Radio Resource Control (RRC), Media Access Control (MAC), and physical layer configuration, procedures, and messaging associated with handover processes. In some implementations, the communication module 132 may be configured to communicate with a capable UE and support messaging associated with PSCell addition or modification procedures, carrier aggregation (CA) configuration procedures, and / or support necessary operations.

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

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

[0049] CN 110 can be either the Evolved Packet Core (EPC) 111 or the 5th Generation Core (5GC) 160; both are... Figure 1A The base station 104 can be an eNB supporting an S1 interface for communication with EPC 111, an ng-eNB supporting an NG interface for communication with 5GC 160, or a gNB supporting an NR radio interface and an NG interface for communication with 5GC 160. The base station 106A can be an EUTRA-NR DC (EN-DC) gNB (en-gNB) with an S1 interface to EPC 111, an en-gNB not connected to EPC 111, a gNB supporting an NR radio interface and an NG interface to 5GC 160, or an ng-eNB supporting an EUTRA radio interface and an NG interface to 5GC 160. To directly exchange messages with each other during the scenarios discussed below, base stations 104, 106A, and 106B can support X2 or Xn interfaces.

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

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

[0052] Figure 1B Example distributed or decomposed implementations of any one or more of base stations 104, 106A, and 106B are depicted. In this implementation, base station 104, 106A, or 106B includes a central unit (CU) 172 and one or more individual units (DUs) 174. CU 172 includes processing hardware, such as one or more general-purpose processors (e.g., CPUs) and computer-readable memory storing machine-readable instructions executable on the general-purpose processor, and / or dedicated processing units. For example, CU 172 may include... Figure 1A The processing hardware is 130 or 140.

[0053] Each of DU 174 also includes processing hardware, which may 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 dedicated processing units. For example, the processing hardware may include: a Media Access Control (MAC) controller configured to manage or control one or more MAC operations or procedures (e.g., random access procedures); and a Radio Link Control (RLC) controller configured to manage or control one or more RLC operations or procedures when the base station (e.g., base station 106A) operates as an MN or SN. The processing hardware may also include a physical layer controller configured to manage or control one or more physical layer operations or procedures.

[0054] In some implementations, CU 172 may include a logical node CU-CP 172A that hosts the control plane portion of the Packet Data Convergence Protocol (PDCP) protocol for CU 172. CU 172 may also include a logical node CU-UP 172B that hosts the user plane portion of the PDCP protocol and / or the Service Data Adaptation Protocol (SDAP) protocol for CU 172. CU-CP 172A may transmit control information (e.g., RRC messages, F1 application protocol messages), and CU-UP 172B may transmit data packets (e.g., SDAPPDU or Internet Protocol packets).

[0055] CU-CP 172A can connect to multiple CU-UP 172Bs via the E1 interface. CU-CP 172A selects the appropriate CU-UP 172B for the service requested by UE 102. In some implementations, a single CU-UP 172B can connect to multiple CU-CP 172A via the E1 interface. CU-CP 172A can connect to one or more DU 174s via the F1-C interface. CU-UP 172Bs can connect to one or more DU 174s via the F1-U interface under the control of the same CU-CP 172A. In some implementations, a DU 174 can connect to multiple CU-UP 172Bs under the control of the same CU-CP 172A. In such implementations, the connection between CU-UP 172Bs and DU 174s is established by CU-CP 172A using bearer context management functions.

[0056] Figure 2A An example protocol stack 200 is shown in a simplified manner, which UE 102 can use to communicate with eNB / ng-eNB or gNB (e.g., one or more of base stations 104, 106).

[0057] In example stack 200, the EUTRA physical layer (PHY) 202A provides a transport channel to the EUTRA MAC sublayer 204A, which in turn provides a logical channel to the EUTRA RLC sublayer 206A. The EUTRA RLC sublayer 206A then provides an RLC channel to the EUTRA PDCP sublayer 208 and, in some cases, to the NR PDCP sublayer 210. Similarly, the NRPHY 202B provides a transport channel to the NR MAC sublayer 204B, which in turn provides a logical channel to the NR RLC sublayer 206B. The NR RLC sublayer 206B then provides data transmission services to the NR PDCP sublayer 210. The NR PDCP sublayer 210 can then provide data transmission services to the Serving Data Adaptation Protocol (SDAP) 212 or the Radio Resource Control (RRC) sublayer. Figure 2A (Not shown in the image) provides data transmission services. In some implementations, UE 102 supports both EUTRA and NR stacks, such as... Figure 2A As shown, this supports handover between EUTRA and NR base stations and / or supports DCs via EUTRA and NR interfaces. Further, as... Figure 2A As shown, UE102 can support the layering of NR PDCP 210 on top of EUTRA RLC 206A, and the layering of SDAP sublayer 212 on top of NR PDCP sublayer 210.

[0058] EUTRA PDCP sublayer 208 and NR PDCP sublayer 210 receive packets that can be referred to as Service Data Units (SDUs) (e.g., from Internet Protocol (IP) layers that are directly or indirectly layered on PDCP layers 208 or 210), and output packets that can be referred to as Protocol Data Units (PDUs) (e.g., output to RLC layers 206A or 206B). Except where the difference between SDU and PDU is relevant, for simplicity, this disclosure refers to both SDU and PDU as “packets”.

[0059] On the control plane, EUTRA PDCP sublayer 208 and NR PDCP sublayer 210 can provide signaling radio bearer (SRB) or RRC sublayer ( Figure 2A (Not shown) to exchange, for example, RRC messages or Non-Access Stratum (NAS) messages. On the user plane, EUTRA PDCP sublayer 208 and NR PDCP sublayer 210 can provide DRBs to support data exchange. The data exchanged on NR PDCP sublayer 210 can be SDAP PDUs, Internet Protocol (IP) packets, or Ethernet packets.

[0060] Figure 2BAn example protocol stack 250 is shown in a simplified manner, illustrating how UE 102 can communicate with DU (e.g., DU 174) and CU (e.g., CU 172). The radio protocol stack 200 is functionally broken down as follows: Figure 2B The radio protocol stack 250 is shown in the diagram. The CU at either base station 104 or 106 can retain all control and upper-layer functions (e.g., RRC 214, SDAP 212, NR PDCP 210), while lower-layer operations (e.g., NR RLC 206B, NR MAC 204B, and NR PHY 202B) are delegated to the DU. To support connectivity to the 5GC, NR PDCP 210 provides SRBs to RRC 214, and NR PDCP 210 provides DRBs to SDAP 212 and SRBs to RRC 214.

[0061] Figures 3A to 3F and Figure 4 This is a message passing diagram illustrating an example scenario where RAN nodes identify the UE's capability type during connection establishment. UE types can correspond to different UE capability types. For example, this disclosure refers to RedCap UE as the first UE type and fRedCap UE as the second UE type. Although two UE capability types are discussed throughout this disclosure, the described techniques are applicable to distinguishing a larger number of UE capability types should more UE capability types be defined in the future. Generally, Figures 3A to 3F The same events are labeled with the same reference numerals in the attached figures. Figures 3A to 3F and Figure 4 Similar events in the figures are labeled with similar reference numerals (e.g., event 302 is similar to event 402, etc.), and the differences will be discussed below where appropriate. Apart from the differences shown in the figures and discussed below, any of the alternative implementations discussed for specific events (e.g., those used for messaging and processing) can be applied to other events labeled with similar reference numerals in the figures.

[0062] First turn Figure 3AIn scenario 300A, base station 104 includes CU 172 and DU 174. In some implementations, DU 174 initially initiates an F1 establishment process with CU 172 by transmitting a 302 F1 Establishment Request message to DU 174. In response, CU 172 transmits a 304 F1 Establishment Response message to DU 174. Depending on the implementation, DU 174 includes DU configuration information for one or more cells in the F1 Establishment Request message. In some implementations, the DU configuration information includes Capability Reduction (RedCap) information, Further Capability Reduction (fRedCap) information, System Information (IE), and / or Slice Support Information, as described below. In some implementations, CU 172 includes CU configuration information for one or more cells in the F1 Establishment Response message. The F1 Establishment Request and F1 Establishment Response messages are non-UE-related signaling messages.

[0063] In some implementations, DU 174 includes RedCap information (e.g., an Information Element (IE)) in the F1 Establishment Request message. In some implementations, DU 174 configures RedCap information for the corresponding cell operated by DU 174, and the RedCap information indicates whether a RedCap UE is allowed to access the corresponding cell. In some implementations, RedCap UEs include different types of RedCap UEs, such as RedCap UEs with one receive chain or antenna, RedCap UEs with two receive chains or antennas, and RedCap UEs supporting half-duplex operation. In some implementations, the RedCap information indicates which types of RedCap UEs can access the corresponding cell. In some implementations, CU 172 uses the RedCap information to determine whether the corresponding cell is a suitable target cell in cases involving subsequent outbound mobility of the RedCap UE. In some implementations, the RedCap information is a RedCap Broadcast Information IE. In other implementations, DU 174 includes RedCap information in the RedCap Broadcast Information IE in the F1 Establishment Request message. In some implementations, DU 174 includes multiple sets of RedCap information, with each corresponding cell in the F1 setup request message corresponding to one set of RedCap information. In some implementations, the multiple sets of RedCap information may have the same or different content. In some implementations, the RedCap UE is a specific RedCap UE that supports a specific RedCap function (e.g., a RedCap UE that supports RedCap functions defined according to 3GPP standards).

[0064] In some implementations, DU 174 includes fRedCap information (e.g., an Information Element (IE)) in the F1 setup request message. In some implementations, DU 174 configures fRedCap information for the corresponding cell operated by DU 174, and the fRedCap information indicates whether an fRedCap UE is allowed to access the corresponding cell. In some implementations, fRedCap UEs include different types of fRedCap UEs, such as fRedCap UEs with one receive chain or antenna, fRedCap UEs with two receive chains or antennas, and fRedCap UEs supporting half-duplex operation. In some implementations, the fRedCap information indicates which types of fRedCap UEs can access the corresponding cell. In some implementations, CU 172 uses the fRedCap information to determine whether the corresponding cell is a suitable target cell in cases involving subsequent outbound mobility of the fRedCap UE. In some implementations, the fRedCap information is a different fRedCap broadcast information IE from the RedCap broadcast information IE. In other implementations, DU 174 includes fRedCap information in the RedCap broadcast information IE of the F1 setup request message. In this case, DU 174 includes both RedCap information and fRedCap information in the RedCap broadcast information IE of the corresponding cell in the F1 setup request message. In some implementations, DU 174 includes multiple sets of fRedCap information, with each corresponding cell in the F1 setup request message corresponding to one set of fRedCap information. In some implementations, the multiple sets of fRedCap information have the same or different content. In some implementations, the fRedCap UE is a specific fRedCap UE that supports a specific fRedCap function (e.g., an fRedCap UE that supports the fRedCap function defined according to the 3GPP standard).

[0065] In some implementations, DU 174 includes the system information IE of the cell operated by DU 174 in the F1 establishment request message. In some implementations, the system information IE includes a main information block (MIB) and / or one or more system information blocks (SIBs). In some implementations, DU 174 configures the MIB and SIB for a capable UE, a RedCap UE, and / or a fRedCap UE. In other implementations, DU 174 includes a first system information IE and a second system information IE of the cell operated by DU 174 in the F1 establishment request message. In some implementations, the first system information IE includes the MIB and / or SIB of a capable UE, while the second system information IE includes the MIB and / or SIB of a RedCap UE and / or a fRedCap UE. In yet another implementation, DU 174 includes a first system information IE, a second system information IE, and a third system information IE of the cell operated by DU 174 in the F1 establishment request message. In some implementations, the first system information IE includes the MIB and / or SIB of a normally functioning UE, the second system information IE includes the MIB and / or SIB of a RedCap UE, and / or the third system information IE includes the MIB and SIB of a RedCap UE. In some implementations, the aforementioned SIBs include SIB1, SIB17, and / or SIB20.

[0066] In some implementations, the F1 establishment request message includes DU 174, which includes slice support information (e.g., IE) for the corresponding cell operated by DU 174. The slice support information indicates one or more slices supported on the corresponding cell of a capable UE, a RedCap UE, and / or a fRedCap UE. In other implementations, the F1 establishment request message includes first slice support information (e.g., IE) and second slice support information (e.g., IE) for the corresponding cell operated by DU 174. The first slice support information indicates one or more slices supported on the corresponding cell of a capable UE, while the second slice support information indicates one or more slices supported on the corresponding cell of a RedCap UE and / or a fRedCap UE. In yet another implementation, the F1 establishment request message includes first slice support information (e.g., IE), second slice support information (e.g., IE), and third slice support information (e.g., IE) for the corresponding cell operated by DU 174. The first slice support information indicates one or more slices supported on the corresponding cell of a UE with normal capability; the second slice support information indicates one or more slices supported on the corresponding cell of a RedCap UE; and / or the third slice support information indicates one or more slices supported on the corresponding cell of a RedCap UE.

[0067] In some implementations, the CU configuration information includes SIBs. For example, SIBs may include SIB2, SIB3, SIB4, SIB5, SIB6, SIB7, SIB8, and / or SIB9. In some implementations, the CU configuration information is different for each cell.

[0068] In some implementations, DU 174 initiates a DU configuration update procedure with CU 172 to update at least a portion of the DU configuration information. After initiating the DU configuration update procedure, DU 174 transmits a DU configuration update message (306) including new DU configuration information to CU 172 to update the DU configuration information included in the F1 establishment request message. In some implementations, the new DU configuration information includes new RedCap information, new fRedCap information, new system information (IE), and / or new slice support information. In response to the DU configuration update message, CU 172 transmits a DU configuration update confirmation message (308) to DU 174. In some implementations, CU 172 includes new CU configuration information for one or more cells in the DU configuration update confirmation message to update the CU configuration information in the F1 establishment response message. In some alternative implementations, DU 174 transmits a DU configuration update message (306) to CU 172 to include DU configuration information or at least a portion of the DU configuration information instead of the F1 establishment request message. In some implementations, CU 172 includes CU configuration information for one or more cells in the DU configuration update confirmation message, as described for the F1 setup response message. The DU configuration update message and the DU configuration update confirmation message are non-UE-related signaling messages.

[0069] In some implementations, DU 174 and CU 172 perform separate procedures to transmit different configuration information for a capable UE, a RedCap UE, and / or an fRedCap UE to CU 172. For example, DU 174 performs a first procedure with CU 172 by transmitting a first message to CU 172 containing first configuration information for a capable UE. In response, CU 172 transmits a second message to DU 174. DU 174 performs a second procedure with CU 172 by transmitting a third message to CU 172 containing second configuration information for the RedCap UE and / or the fRedCap UE. In response, CU 172 transmits a fourth message to DU 174. In some alternative implementations, DU 174 performs a second procedure with CU 172 by transmitting a third message to CU 172 containing second configuration information for the RedCap UE, and a third procedure with CU 172 by transmitting a fifth message to CU 172 containing third configuration information for the fRedCap UE. In some implementations, CU 172 transmits a fourth message and a sixth message to DU 174 in response to the third and fifth messages, respectively. In some implementations, these processes include an F1 establishment process and / or a DU configuration update process. Where these processes are F1 establishment processes, the first, third, and / or fifth messages are F1 establishment request messages, while the second, fourth, and / or sixth messages are F1 establishment response messages. Where these processes are DU configuration update processes, the first, third, and / or fifth messages are F1 establishment request messages, while the second, fourth, and / or sixth messages are F1 establishment response messages.

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

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

[0072] UE 102 initiates a process to establish or restore a radio connection with base station 104. Specifically, in some implementations, UE 102 performs a random access procedure with DU 174. Depending on the implementation, the random access procedure is a two-step or four-step process. In the four-step process between the UE and DU, UE 102 transmits 314 Random Access (RA) preamble to DU 174 (step 1), also known as “Msg1”; DU 174 transmits 316 Random Access Response (RAR) or “Msg2” to UE 102 (step 2); UE 102 transmits 318 Scheduled Transport or “Msg3” to DU 174 (step 3); and DU 174 transmits conflict resolution or “Msg4” to UE 102 (step 4). The scheduled transport includes a UL MAC PDU containing a Logical Channel Identifier (LCID) and an RRC request. In the two-step process, UE 102 transmits the 314 RA preamble and the 318 payload or "MsgA" to DU 174 (step 1), while DU 174 transmits the conflict resolution or "MsgB" to UE 102 (step 2). More specifically, MsgA comprises two parts transmitted at different times: the RA preamble transmitted via the PRACH timing (e.g., similar to Msg1 in the four-step process), and the payload transmitted via the PUSCH timing (e.g., similar to Msg3 in the four-step process). The payload includes a UL MACPDU containing the LCID and the RRC request. In some implementations, the LCID identifies the UL logical channel to which the RRC request belongs. For example, the UL logical channel is the UL Common Control Channel (CCCH).

[0073] In some implementations, if UE 102 operates in an idle or inactive state 310, an RRC request message signals a transition to a connected state (e.g., an RRCSetupRequest message or an RRCResumeRequest message). In further implementations, if UE 102 operates in a connected state 310, an RRC request message indicates recovery from a radio link failure or other fault (e.g., an RRCReestablishmentRequest message). In some implementations, UE 102 generates a UL-CCCH-Message message that includes the RRC request message and also includes the UL-CCCH-Message message in the UL MAC PDU 318. In other implementations, UE 102 generates a UL-CCCH1-Message message that includes the RRC request message and also 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-CCCH1-Message message.

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

[0075] After determining that UE 102 is the second UE type, DU 174 transmits a 322 DU to CU message to CU 172. This message includes an RRC request and an indication of the first UE type, not the second UE type. In some implementations, the DU to CU message is an Initial UL RRC Message Transfer message. If DU 174 determines that UE 102 is the first UE type, then DU 174 transmits the 322 DU to CU message to CU 172. When CU 172 receives the 322 DU to CU message, CU 172 determines that UE 102 is the first UE type based on this indication. There are several advantages to DU 174 using the same indication for both the first and second UE types. First, using the same indication simplifies UE handling in CU 172. That is, CU 172 manages both the first and second UE types in the same way. Secondly, when the first UE type is a RedCap UE, the indication for RedCap UEs has already been defined (e.g., in 3GPP Release 17). Therefore, there is no need to define new indications for fRedCap UEs in the DU to CU message (e.g., in 3GPP Release 18). Therefore, CU172 does not need to be updated to support fRedCap UEs.

[0076] In some implementations, CU 172 transmits a BS-to-CN message to the CN (e.g., CN 110) or AMF (e.g., AMF 164), which includes an indication of a first UE type for UE 102. Therefore, in some such implementations, CN 110 determines that UE 102 is a first UE type based on the indication of the first UE type. In some implementations, CN 110 applies a charging policy or rate to the first UE type of UE 102 based on this indication or determination to charge for data traffic communicating with UE 102. In some such cases, CN 110 applies the same charging policy or rate to the first UE type and the second UE type, while applying a different charging policy or rate to the third UE type. In some implementations, the BS-to-CN message is an Initial UE Message. In some implementations, AMF 164 transmits a message including an indication of the first UE type to the SMF (e.g., SMF 166) after receiving the BS-to-CN message. Therefore, in some such implementations, SMF 166 handles UE 102 appropriately based on an indication of the first UE type.

[0077] In some implementations, if DU 174 determines that UE 102 is a third UE type, then DU 174 avoids including an indication of the UE type in the DU-to-CU message 322. In a further implementation, if DU 174 determines that UE 102 is a third UE type, then DU 174 includes an indication of the third UE type in the DU-to-CU message 322.

[0078] In response to the RRC request message, CU 172 transmits or generates an RRC response message for UE 102 and transmits a CU-DU message 326, including the RRC response message, to DU 174. DU 174 then transmits an RRC response message 328 to UE 102. In some implementations, DU 174 includes an LCID and the RRC response message in a DL MAC PDU and transmits a DL MAC PDU 328 to UE 102. In some implementations, the LCID identifies the DL logical channel to which the RRC response message belongs. For example, the DL logical channel is the DL Common Control Channel (CCCH). In some implementations, CU 172 generates a DL-CCCH-Message message that includes the RRC response message and includes the DL-CCCH-Message message in a DL MAC PDU 328. In the description herein, in some implementations, the RRC response message is equivalent to the DL-CCCH-Message message.

[0079] In some implementations, RRC response messages 326 and 328 are RRCSetup, RRCResume, or RRCReestablishment messages, depending on whether RRC request message 318 is an RRCSetupRequest, RRCResumeRequest, or RRCReestablishmentRequest message. In some implementations, in response to an RRCSetupRequest or RRCResumeRequest message, RRC response message 328 is an RRC rejection message (e.g., an RRCReject message). In some implementations, if the RRC response message is neither an RRC rejection nor an RRC release message, UE 102 transitions to the connected state 330 and transmits an RRC Complete message 332 to DU 174 in response to the RRC response message. DU 174 then transmits an RRC Complete message 334 to CU 172. Depending on the implementation, the RRC Complete message is an RRCSetupComplete, RRCResumeComplete, or RRCReestablishmentComplete message, depending on the RRC response message 328.

[0080] In some implementations, UE 102 includes the LCID and RRC completion message in the UL MAC PDU and transmits UL MAC PDU 332 to DU 174. In some implementations, the LCID identifies the UL logical channel to which the RRC completion message belongs. For example, the UL logical channel is the UL Dedicated Control Channel (DCCH). DU 174 retrieves the LCID and RRC completion message from UL MAC PDU 332 and transmits DU-CU message 324, including the RRC completion message, to CU 172. In some implementations, UE 102 generates a UL-DCCH-Message message including the RRC completion message, generates a UL PDCPPDU including the UL-CCCH-Message message, generates a UL RLC PDU including the UL PDCP PDU, and includes the UL RLC PDU in UL MAC PDU 332. In the description herein, in some implementations, the RRC completion message is equivalent to the UL-DCCH-Message message.

[0081] In some implementations, if the RRC response message is an RRC rejection message or an RRC release message, then UE 102 remains in its original state as in event 310 and avoids transmitting an RRC completion message to base station 104.

[0082] In some implementations, after identifying UE 102 as the second UE type (320), DU 174 includes configuration parameters (e.g., cell group configuration) supported by the second UE type for UE 102 in the DU to CU message 322. CU 172 includes these configuration parameters in the RRC response message. In some implementations, if DU 174 determines that UE 102 is the first UE type, DU 174 still includes the configuration parameters supported by the second UE type for UE 102 in the DU to CU message 322. In this case, DU 174 unifies the configurations of the first and second UE types. In a further implementation, if DU 174 determines that UE 102 is the first UE type, DU 174 includes the configuration parameters (e.g., cell group configuration) supported by the first UE type for UE 102 in the DU to CU message 322. In some implementations, if DU 174 determines that UE 102 is a third UE type, then DU 174 includes the configuration parameters (e.g., cell group configuration) supported by the third UE type for UE 102 in the DU to CU message 322.

[0083] In some implementations, DU 174 generates a first downlink control information (DCI) including parameters for the UE to receive downlink transmissions and transmit uplink transmissions. In some implementations, based on determination 320, DU 174 generates parameters conforming to predetermined capabilities of a second UE type. DU 174 transmits the first DCI to UE 102 before transmitting 328 DL MAC PDUs, such that in some implementations, UE 102 configures itself to receive 328 DL MAC PDUs according to the first DCI. Similarly, in a further implementation, if DU 174 determines that UE 102 is a first UE type, DU 174 generates a second DCI for UE 102, which includes parameters supported by the first UE type. In some implementations, base station 104 transmits the second DCI to UE 102 before transmitting 328 DL MAC PDUs. Alternatively, if DU 174 determines that UE 102 is a first UE type, then DU 174 generates a second DCI for UE 102, similar to the first DCI, which includes parameters supported by the second UE type. In some implementations, base station 104 transmits the second DCI to UE 102 before transmitting the 328 DL MAC PDU. Similarly, in a further implementation, if DU 174 determines that UE 102 is a third UE type, then DU 174 generates a third DCI for UE 102, which includes parameters supported by the third UE type. In some implementations, base station 104 transmits the third DCI to UE 102 before transmitting the 328 DL MAC PDU.

[0084] In some cases regarding the first DCI, DU 174 includes parameters for scheduling PDSCH transmissions to UE 102 within the first DCI, wherein the PDSCH transmission includes DL MAC PDU 328. In some implementations, these parameters include a first time-domain resource allocation field and / or a first frequency-domain resource allocation field for the PDSCH transmission. In some implementations, DU 174 sets the first time-domain resource allocation field to a first value conforming to one or more predetermined capabilities of the second UE type. In a further implementation, DU 174 sets the first time-domain resource allocation field to a first predetermined value. In some implementations, DU 174 sets the first frequency-domain resource allocation field to a first value conforming to one or more predetermined capabilities of the second UE type. In a further implementation, DU 174 sets the first frequency-domain resource allocation field to a first predetermined value. In this implementation, UE 102 receives PDSCH transmissions at time-domain resources (e.g., symbols) according to a first time-domain resource assignment field, and / or receives PDSCH transmissions in frequency-domain resources according to a first frequency-domain resource assignment field.

[0085] In some implementations, DU 174 includes a first PDSCH-to-HARQ feedback timing indicator in the first DCI. In some implementations, DU 174 sets the first PDSCH-to-HARQ feedback timing indicator to a first value conforming to one or more predetermined capabilities of the second UE type. Therefore, in some such implementations, UE 102 transmits HARQ feedback according to the first value. In a further implementation, DU 174 sets the first PDSCH-to-HARQ feedback timing indicator to a predetermined value. Depending on the implementation, the HARQ feedback is either a HARQ acknowledgment or a HARQ negative acknowledgment.

[0086] In some cases regarding the second DCI, DU 174 includes parameters for PDSCH transmissions scheduled to UE 102, where the PDSCH transmission includes DL MAC PDU 328. In some implementations, these 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, DU 174 sets the second time-domain resource assignment field to a second value conforming to one or more predetermined capabilities of the first UE type. In a further implementation, DU 174 sets the second time-domain resource assignment field to a second predetermined value. In an even further implementation, 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, DU 174 sets the second frequency-domain resource assignment field to a second value conforming to one or more predetermined capabilities of the first UE type. In a further implementation, DU 174 sets the second frequency-domain resource assignment field to a second predetermined value. In a further implementation, DU 174 sets the second frequency domain resource assignment field to the same value as the first time domain resource assignment field. In such an implementation, UE 102 (e.g., in the case of a first UE type) receives PDSCH transmissions at time domain resources (e.g., symbols) according to the second time domain resource assignment field, and / or receives PDSCH transmissions in frequency domain resources according to the second frequency domain resource assignment field.

[0087] In some implementations, DU 174 includes a second PDSCH to HARQ feedback timing indicator in the second DCI. In some implementations, DU 174 sets the second PDSCH to HARQ feedback timing indicator to a second value that conforms to one or more predetermined normalization capabilities. For example, the second value corresponds to an earlier time resource than the first PDSCH to HARQ feedback timing indicator because the first UE type is able to process PDSCH transmissions faster than the second UE type. In some implementations, UE 102 (e.g., in the case of the second UE type) transmits HARQ feedback based on the second value. In a further implementation, DU 174 sets the second PDSCH to HARQ feedback timing indicator to the same value as the first PDSCH to HARQ feedback timing indicator. Depending on the implementation, the HARQ feedback is a HARQ acknowledgment or a HARQ negative acknowledgment.

[0088] In some cases concerning the third DCI, DU 174 includes parameters in the third DCI for PDSCH transmissions scheduled to UE 102 (e.g., in the case of a third UE type), where the PDSCH transmission includes DL MAC PDU 328. In some implementations, these 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, DU 174 sets the third time-domain resource assignment field to a third value conforming to one or more predetermined capabilities of the third UE type. In a further implementation, DU 174 sets the third time-domain resource assignment field to a third predetermined value. In an even further implementation, 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, DU 174 sets the third frequency-domain resource assignment field to a third value conforming to one or more predetermined capabilities of the third UE type. In a further implementation, DU 174 sets the third frequency-domain resource assignment field to a third predetermined value. In a further implementation, 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 an implementation, UE 102 (e.g., in the case of a third UE type) receives PDSCH transmissions at time domain resources (e.g., symbols) according to the third time domain resource assignment field, and / or receives PDSCH transmissions in frequency domain resources according to the third frequency domain resource assignment field.

[0089] In some implementations, DU 174 includes a third PDSCH to HARQ feedback timing indicator in the third DCI. In some implementations, DU 174 sets the third PDSCH to HARQ feedback timing indicator to a third value that conforms to one or more predetermined capabilities of the third UE type. For example, the third value corresponds to an earlier time resource than the first or second PDSCH to HARQ feedback timing indicator because the third UE type is able to process PDSCH transmissions faster than the first or second UE type. In some implementations, UE 102 (e.g., in some cases for the third UE type) transmits HARQ feedback based on the third value. In a further implementation, DU 174 sets the third PDSCH to HARQ feedback timing indicator to the same value as the first or second PDSCH to HARQ feedback timing indicator. Depending on the implementation, the HARQ feedback is a HARQ acknowledgment or a HARQ negative acknowledgment.

[0090] In some implementations, DU 174 transmits the first DCI on time and frequency resources. Depending on the implementation, the time and frequency resources reside on a first control resource set (CORESET) or a first search space. In some implementations, DU 174 broadcasts a first SIB on the cell, which includes first configuration parameters configuring the first CORESET or the first search space for the second UE type. UE 102 (e.g., in the case of the second UE type) receives the first SIB and the first DCI on the time and frequency resources of the first CORESET or the first search space according to the first configuration parameters.

[0091] In other implementations, DU 174 transmits the second DCI on time and frequency resources. In some implementations, the time and frequency resources reside on a second CORESET or a second search space. In some implementations, DU 174 broadcasts a second SIB on the cell, the second SIB including second configuration parameters configuring the second CORESET or second search space for the first UE type. UE 102 (e.g., in the case of the first UE type) receives the second SIB and the second DCI on the time and frequency resources of the second CORESET or second search space according to the second configuration parameters. Alternatively, such as where DU 174 configures the first CORESET or first search space for both the first and second UE types, DU 174 transmits the second DCI on the first CORESET or first search space.

[0092] In other implementations, DU 174 transmits the third DCI on time and frequency resources. In some implementations, the time and frequency resources are located on a third CORESET or a third search space. In some implementations, DU 174 broadcasts a third SIB on the cell, which includes third configuration parameters configuring the third CORESET or third search space for a third UE type. UE 102 (e.g., in the case of a third UE type) receives the third SIB and the third DCI on time and frequency resources in the third CORESET or third search space according to the third configuration parameters. Alternatively, such as in cases where DU 174 configures a second CORESET or second search space for both the first and third UE types, DU 174 transmits the third DCI on the second CORESET or second search space.

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

[0094] In some implementations, DU 174 broadcasts an SIB on the cell, which includes a first PUCCH configuration (e.g., PUCCH-ConfigCommon IE) configuring PUCCH resources for a UE of the second UE type. UE 102 (e.g., in the case of the second UE type) transmits HARQ feedback on the first PUCCH resources configured via the first PUCCH configuration. In some implementations, UE 102 determines the first PUCCH resource based on a PUCCH resource indicator in the first DCI. Depending on the implementation, the SIB is SIB1 or the SIB described above.

[0095] In some implementations, DU 174 configures a first PUCCH configuration for a UE of a first UE type. UE 102 (e.g., in the case of the first UE type) transmits HARQ feedback on the first PUCCH resource configured via the first PUCCH configuration. In some implementations, UE 102 determines the first PUCCH resource based on a PUCCH resource indicator in a second DCI. In some alternative implementations, DU 174 broadcasts an SIB on the cell that includes a second PUCCH configuration (e.g., PUCCH-ConfigCommon IE) for configuring PUCCH resources for a UE of the first UE type. UE 102 (e.g., in the case of the first UE type) transmits HARQ feedback on the second PUCCH resource configured via the second PUCCH configuration. In some implementations, UE 102 determines the second PUCCH resource based on a PUCCH resource indicator in a second DCI. Depending on the implementation, the SIB is SIB1 or the SIB described above.

[0096] In some implementations, DU 174 broadcasts an SIB on the cell, which includes a third PUCCH configuration (e.g., PUCCH-ConfigCommon IE) configuring PUCCH resources for a third UE type. UE 102 (e.g., in the case of a third UE type) transmits HARQ feedback on the third PUCCH resources configured via the third PUCCH configuration. In some implementations, UE 102 determines the third PUCCH resource based on the PUCCH resource indicator in the third DCI. Depending on the implementation, the SIB is SIB1 or the SIB described above.

[0097] In some implementations, the PUCCH resources configured in the first, second, and / or third PUCCH configurations are mutually exclusive. In other implementations, one or more of the PUCCH resources configured in the first, second, and / or third PUCCH configurations are the same. Depending on the implementation, the remaining parts of the first, second, and / or third PUCCH configurations may be the same or different. In such cases, DU 174 does not configure more than one UE to transmit HARQ feedback on the same PUCCH resource in the same instance at the same time.

[0098] In other implementations, base station 104 broadcasts an SIB that includes a PUCCH configuration (e.g., PUCCH-ConfigCommon IE) configuring PUCCH resources for UEs of the first, second, and third UE types. In this case, DU 174 does not configure more than one UE to transmit HARQ feedback on the same PUCCH resource in the same instance at the same time. UE 102 transmits HARQ feedback on the PUCCH resource configured by the PUCCH configuration. In some implementations, UE 102 determines the PUCCH resource based on the PUCCH resource indicator in the first DCI. Depending on the implementation, the SIB is SIB1 or the SIB described above.

[0099] In some implementations, DU 174 configures the cell's DL Bandwidth Part (BWP) and UL BWP for communication with UEs of a first, second, or third UE type. In some implementations, DU 174 broadcasts an SIB on the cell, which includes DL BWP and UL BWP configurations respectively. Depending on the implementation, the SIB is SIB1 or the aforementioned SIBs. In other implementations, DU 174 transmits an RRC reconfiguration message to each UE, which includes DL BWP and UL BWP configurations respectively. DU 174 communicates with UEs of the first, second, and / or third UE types on the cell via the DL BWP and ULBWP.

[0100] In other implementations, DU 174 configures the cell's first DLBWP and first UL BWP for UEs of a first UE type and a second UE type, and configures the cell's second DL BWP and second UL BWP for UEs of a third UE type. In some implementations, DU 174 broadcasts a first SIB on the cell, which includes a first DL BWP configuration and a first UL BWP configuration respectively configuring the first DL BWP and the first UL BWP. Depending on the implementation, the first SIB is SIB1 or another SIB mentioned above. In some implementations, DU 174 broadcasts a second SIB on the first cell, which includes a second DL BWP configuration and a second UL BWP configuration respectively configuring the second DL BWP and the second UL BWP. Depending on the implementation, the second SIB is SIB1 or another SIB mentioned 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, DU 174 transmits an RRC reconfiguration message to each UE of a first UE type or a second UE type. This RRC reconfiguration message includes a first DL BWP configuration and a first UL BWP configuration, respectively. In other implementations, DU 174 transmits an RRC reconfiguration message to each UE of a third UE type. This RRC reconfiguration message includes a second DL BWP configuration and a second UL BWP configuration, respectively. DU 174 communicates with UEs of the first UE type and / or the second UE type on the cell via the first DL BWP and the first UL BWP, and communicates with UEs of the third UE type via the second DL BWP and the second UL BWP.

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

[0102] Events 314, 316, 318, 320, 322, 324, 326, 328, 330, 332, and 334 are in Figure 3AIn this context, it is collectively referred to as the connection establishment process or connection recovery process 390A.

[0103] Figure 3B It shows the relationship with Figure 3A Scenario 300B is similar to Scenario 300A, except that Scenario 300B includes events 323 and 325 instead of events 322 and 324. In Scenario 300B, DU 174 transmits a DU-to-CU message 323 to CU 172. This DU-to-CU message includes an RRC request message and an indication of a second UE type. DU-to-CU message 323 is similar to DU-to-CU message 322, except that DU-to-CU message 323 includes an indication of a second UE type instead of an indication of a first UE type. Therefore, CU 172 determines that UE 102 is a second UE type based on the indication of the second UE type. Therefore, CU 172 takes appropriate action against UE 102 based on the indication of the second UE type.

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

[0105] Events 314, 316, 318, 320, 323, 325, 326, 328, 330, 332, and 334 are in Figure 3B In this context, it is collectively referred to as the connection establishment process or connection recovery process 390B.

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

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

[0108] Events 314, 316, 318, 321, 322, 324, 326, 328, 330, 332, and 334 are in Figure 3C These are collectively referred to as the connection establishment process or connection recovery process 390C.

[0109] Turning Figure 3D Scenario 300D is similar to Scenario 300A-C. In Scenario 300D, based on determination 321, DU 174 transmits a DU-to-CU message 323 to CU 172. This DU-to-CU message includes an RRC request message and an indication of the second UE type. Events 314, 316, 318, 321, 323, 325, 326, 328, 330, 332, and 334 are... Figure 3D In this context, it is collectively referred to as the connection establishment process or connection recovery process 390D.

[0110] Turning Figure 3E Scenario 300E is similar to Scenario 300A-D. In Scenario 300E, CU 172 determines that UE 102 is a second UE type based on the RRC request message. In some implementations, because UE 102 is a second UE type, UE 102 generates an RRC request message according to the format of a Type 2 RRC request message (i.e., a Type 2 RRC request message). If UE 102 is a first UE type or a third UE type, then the RRC request message is a Type 1 RRC request message. Therefore, when CU 172 receives an RRC request message according to the format of a Type 2 RRC request message, although CU 172 receives an indication for the first UE type 322, CU 172 still determines that UE 102 is a second UE type. In other words, CU 172 discards or ignores the indication for the first UE type 322.

[0111] In some implementations, if UE 102 is a second UE type and operates in an idle state 310, the type 2 RRC request message is an RRCSetupRequest1 message. In some implementations, if UE 102 is a first or third UE type and operates in an idle state 310, the type 2 RRC request message is an RRCSetupRequest message. In some implementations, if UE 102 is a second UE type and operates in a connected state 310, the RRC request message is an RRCReestablishmentRequest1 message. If UE 102 is a first or third UE type and operates in a connected state 310, the RRC request message is an RRCReestablishmentRequest message. In some implementations, if UE 102 is a second UE type and operates in an inactive state 310, the RRC request message is an RRCResumeRequest2 message or an RRCResumeRequest3 message. If UE 102 is a first or third UE type and operates in an inactive state 310, the RRC request message is either an RRCResumeRequest message or an RRCResumeRequest1 message.

[0112] In some alternative implementations, UE 102 sets the LCID to a first value instead of a second value, and DU 174 determines whether UE 102 is a first UE type based on the first value of the LCID. The advantage of using the first value is that it preserves a reserved value for the LCID for future use.

[0113] Events 314, 316, 318, 320, 322, 327, 326, 328, 330, 332, and 334 are in Figure 3E In this context, it is collectively referred to as the connection establishment process or connection recovery process 390E.

[0114] Turning Figure 3F Scenario 300F is similar to Scenario 300A-E. In some alternative implementations, DU 174 configures the same RA resources for both the first UE type and the second UE type. RA resources include the RA preamble and / or the time and frequency resources of the physical RA channel (PRACH). In some such cases, when DU 174 receives the RA preamble based on the RA resources, DU 174 determines that UE 102 is the first UE type. The benefit of configuring the same RA resources for both the first UE type and the second UE type is the saving of RA resources.

[0115] Events 314, 316, 318, 321, 322, 327, 326, 328, 330, 332, and 334 are in Figure 3F In this context, it is collectively referred to as the connection establishment process or connection recovery process 390F.

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

[0117] Upon receiving the Initial Context Setup Request message 416, CU 172 and UE 102 execute the Security Activation procedure 418 to activate security protection for communication between UE 102 and CU 172. In procedure 418, CU 172 transmits a Security Mode Command message to UE 102 via DU 174. In response, UE 102 activates security protection and transmits a Security Mode Complete message to CU 172 via DU 174. Then, CU 172 transmits a CU-DU message 420 to DU 174, which includes a UE Capability Enquiry message. Subsequently, DU 174 transmits a UE Capability Enquiry message 422 to UE 102. In response, UE 102 transmits a UE Capability Information message 424 to DU 174. Subsequently, DU 174 transmits a 426 DU-to-CU message to CU 172, which includes a UE Capability Information message. In some implementations, UE 102 includes at least one first UE capability of a first UE type and / or at least one second UE capability of a second UE type in the UE Capability Information message. For the sake of simplicity in the following description, "first UE capability" and "second UE capability" are used to refer to "at least one first UE capability" and "at least one second UE capability".

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

[0119] In some implementations, the first UE capability applies to both the first and second UE types. The second UE capability does not apply to the first UE type. In such cases, if UE 102 operates as or supports the second UE type, UE 102 includes both the first and second UE capabilities in its capability container or UE Capability Information message. When CU 172 receives both the first and second UE capabilities, CU 172 determines that the UE is the second UE type, not the first UE type. If UE 102 operates as or supports the first UE type, UE 102 includes the first UE capability in its capability container or UE Capability Information message, but does not include the second UE type's UE capability in the UE Capability Information message. When CU 172 receives the first UE capability from UE 102 but does not receive the second UE type's UE capability, CU 172 determines that UE 102 is the first UE type. In some implementations, if UE 102 supports both a first UE type and a second UE type, UE 102 includes an indication (e.g., UE capability) of support for both UE types (i.e., support for both the first and second UE types) in its capability container or UE Capability Information message. If UE 102 does not support both UE types, it does not include this indication in the UE Capability Information message. When CU 172 receives this indication, CU 172 determines that UE 102 is a dual UE type. If CU 172 does not receive the indication, CU 172 determines that UE 102 is either the first UE type or the second UE type as described above. In some implementations, the first UE capability is not applicable to any UE type and therefore is not applicable to either the first or second UE type. In other implementations, the first UE capability is applicable to the first UE type, the second UE type, and a third UE type (e.g., a UE with normal capabilities).

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

[0121] In some implementations, CU 172 transmits a BS-to-CN message including a capability container to CN 110 (e.g., AMF 164). In some implementations, CU 172 includes the capability container in an inter-node message (e.g., UERadioAccessCapabilityInformation) and also includes the inter-node message in the BS-to-CN message. CN 110 stores the capability container or the inter-node message. The next time UE 102 connects to CN 110 via a base station (e.g., base station 104, 106A, or 106B), 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 UECapability Enquiry message to UE 102 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).

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

[0123] In some implementations, CU 172 transmits a CU-DU message, including a capability container, to DU 174. For example, the CU-DU message is a UE Context Setup Request message or a UE Context Modification Request message. Therefore, DU 174 determines whether UE 102 is a first UE type, a second UE type, or a dual UE type, as described above with respect to CU 172.

[0124] Upon receiving a capability container or UE Capability Information message, CU172 and UE 102 perform the 430 RRC reconfiguration procedure. In procedure 430, CU 172 transmits an RRC reconfiguration message (e.g., an RRCReconfiguration message) including configuration parameters to UE 102 via DU 174. In some implementations, base station 104 determines the configuration parameters based on the UE type and capabilities of UE 102. Therefore, base station 104 ensures that the configuration parameters do not exceed the capabilities of UE 102. In some implementations, CU 172 transmits a CU-to-DU message to DU 174. In some such implementations, CU 172 includes a capability container in the CU-to-DU message. In a further such implementation, DU 174 determines whether UE 102 is a first UE type, a second UE type, or a dual UE type, as described above for CU 172. In response, DU 174 transmits a DU-to-CU message including configuration parameters. In some implementations, DU 174 determines the configuration parameters based on the UE type and UE capabilities of UE 102. Therefore, DU 174 ensures that the configuration parameters do not exceed the capabilities of 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 Request message. In other implementations, the DU-to-CU message is a UE Context Modification Request message.

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

[0126] After performing the RRC reconfiguration process, UE 102 communicates 432 with base station 104 according to the configuration parameters and transmits 432 data to CN 110 via base station 104.

[0127] Next turn Figure 5 Example method 500 can be implemented in a UE (e.g., UE 102). Method 500 begins at block 502, where the UE communicates with the RAN (e.g., Figures 3A to 3F Events 314, 316, 318, 328, 328, 332, 390A-F, Figure 4 Events 490 and 418 in the diagram). At box 504, the UE transmits at least one first UE capability of the first UE type to the RAN (e.g., ...). Figure 4 Event 424 in the diagram). At box 506, the UE transmits at least one second UE capability of the second UE type to the RAN (e.g., Figure 4 Event 424 in the diagram). At box 508, the UE transmits to the RAN UE capabilities indicating support for both the first and second UE types (e.g., ...). Figure 4 Event 424 in the diagram). At box 510, the UE receives configuration parameters from the RAN for either the first UE type or the second UE type (e.g., ...). Figure 4 Event 430 in the diagram). At box 512, the UE communicates with the RAN according to configuration parameters (e.g., Figure 4 Event 432 in the middle).

[0128] 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 these configuration parameters for the first UE type. Otherwise, if the UE only supports the second UE type, the RAN configures these configuration parameters only for the second UE type. In some implementations, at least one first UE capability also applies to the second UE type. In such cases, if the UE operates only as or supports the second UE type, the UE transmits at least one first UE capability and at least one second UE capability to the RAN. In other implementations, UE capabilities defined for or required by the first UE type do not apply to the second UE type. In such cases, if the UE operates only as or supports the second UE type, the UE transmits at least one second UE capability to the RAN and avoids transmitting UE capabilities of the first UE type to the RAN.

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

[0130] In some implementations, the configuration parameters include physical layer configuration parameters. In some implementations, the UE receives an RRC message from the RAN that includes the configuration parameters. 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 (DCI) from the RAN that includes the configuration parameters. In still other implementations, the UE receives an RRC message from the RAN—including a portion of the configuration parameters—and receives the DCI—including the remainder of the configuration parameters.

[0131] In some implementations, the first UE type and the second UE type are RedCap UE type and fRedCapUE type, respectively.

[0132] Next turn Figure 6 Example method 600 can be implemented in a UE (e.g., UE 102). Method 600 begins at box 602, where the UE selects a cell in the RAN (e.g., events 310, 410). In some implementations, the UE selects a cell by performing cell selection or cell reselection. At box 604, the UE determines whether the cell allows a UE of the first UE type to access the cell. If the UE determines at box 604 that the cell allows a UE of the first UE type to access the cell, the process continues to box 606. At box 606, the UE accesses the cell as a UE of the first UE type and communicates with the RAN (e.g., ...). Figure 3A Events 314, 316, 318, and 390A-F in -F Figure 4 (Event 490 in the diagram). Otherwise, if the UE determines at box 604 that the cell prohibits UEs of the first UE type from accessing the cell, the procedure continues to box 608. At box 608, the UE determines whether the cell allows UEs of the second UE type to access the cell. If the UE determines at box 608 that the cell allows UEs of the second UE type to access the cell, the procedure continues to box 610. At box 610, the UE accesses the cell as a UE of the second UE type and communicates with the RAN. Otherwise, if the UE determines at box 608 that the cell prohibits UEs of the second UE type from accessing the cell, the procedure continues to box 612. At box 612, the UE avoids accessing the cell.

[0133] In some implementations, one of the first UE type and the second UE type is a RedCap UE type, while the other UE type is an fRedCap UE type. In other implementations, one of the first UE type and the second UE type is a RedCap UE type, while the other UE type is a normally functional UE type. In still other implementations, one of the first UE type and the second UE type is an fRedCap UE type, while the other UE type is a normally functional UE type. In some implementations, the UE further considers UE subtypes (e.g., 1RX, 2Rx, and HDD).

[0134] 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 a UE of a first UE type is allowed to access the cell, and second information indicating whether a UE of a second UE type is allowed to access the cell. In some implementations, the system information includes an IE or field (also referred to herein as "IE / field") that includes the first and second information. In other implementations, the system information includes a first IE / field and a second IE / field, which respectively include the first and second information.

[0135] Next turn Figure 7A Example method 700A can be implemented in a UE (e.g., UE 102). Method 700A begins at block 702, where the UE communicates with the RAN (e.g., Figure 3A Events 314, 316, 318, 328, 332, and 390A-F in -F Figure 4 Events 490, 418, and 422 in the diagram). At box 704, the UE determines whether it is a second UE type. If the UE determines at box 704 that it is a second UE type, the process continues to box 706. At box 706, the UE transmits a message to the RAN, wherein the message includes at least one UE capability of the first UE type and at least one UE capability of the second UE type (e.g., events 490, 418, and 422). Figure 4 Event 424 in the diagram). Otherwise, if the UE determines at box 704 that the UE is not the second UE type (e.g., the UE determines that the UE is the first UE type), the process continues to box 708. At box 708, the UE transmits a message to the RAN, wherein the message includes at least one UE capability of the first UE type, but does not include UE capabilities of the second UE type (e.g., event 424 in the diagram). Figure 4 Event 424 in the middle.

[0136] In some implementations, the first UE type and the second UE type are RedCap UE type and fRedCap UE type, respectively. In some implementations, at least one UE capability of the first UE type is applicable to the second UE type. Therefore, even if the UE is the second UE type, the UE will still transmit at least one UE capability of the first UE type to the RAN. In some implementations, when the RAN receives at least one UE capability of the first UE type and at least one UE capability of the second UE type, the RAN determines that the UE is the second UE type, not the first UE type. When the RAN receives at least one UE capability of the first UE type from the UE but does not receive any UE capability of the second UE type, the RAN determines that the UE is the first UE type.

[0137] Figure 7B This is a flowchart of an example method 700B, similar to method 700A, except that method 700B includes block 707 instead of block 706. If the UE determines at block 704 that the UE is not the second UE type (e.g., the UE determines that the UE is the first UE type), the process continues to block 707. At block 707, the UE transmits a message to the RAN, wherein the message includes at least one UE capability of the second UE type, but does not include UE capabilities of the first UE type (e.g., ...). Figure 4 Event 424 in the middle.

[0138] Unlike Figure 7A At least one UE capability of the first UE type is not applicable to the second UE type. Therefore, when a UE is of either the first UE type or the second UE type, the UE avoids transmitting the UE capabilities of the other UE type to the RAN.

[0139] Next turn Figure 8A Example method 800A can be implemented in a UE (e.g., UE 102). Method 800A begins at block 802, where the UE communicates with the RAN (e.g., Figure 3A Events 314, 316, 318, 328, 332, and 390A-F in -F Figure 4 Events 490, 418, and 422 in the sequence. At box 804, the UE includes at least one UE capability of the first UE type in the message. At box 806, the UE determines whether it is a second UE type. If the UE determines at box 806 that it is a second UE type, the process continues to box 808. At box 808, the UE includes at least one UE capability of the second UE type in the message. The process continues from box 808 to box 810. Otherwise, if the UE determines at box 806 that it is not a second UE type (e.g., the UE determines it is a first UE type), the process skips box 808 and continues to box 810. At box 810, the UE transmits a message to the RAN (e.g., ...). Figure 4 Event 424 in the middle.

[0140] In some implementations, at least one UE capability of the first UE type is applicable to the second UE type. Therefore, even if the UE is of the second UE type, the UE will transmit at least one UE capability to the RAN.

[0141] Figure 8B This is a flowchart of example method 800B, similar to method 800A. The process continues from box 802 to box 806. If the UE determines at box 806 that the UE is not the second UE type (e.g., the UE determines that the UE is the first UE type), the process continues to box 804. The process continues from box 804 to box 810.

[0142] Unlike Figure 8A At least one UE capability of the first UE type is not applicable to the second UE type. Similarly, at least one UE capability of the second UE type is not applicable to the first UE type. Therefore, when a UE is of either the first or the second UE type, the UE avoids transmitting the UE capabilities of the other UE type to the RAN.

[0143] Turn now Figure 9A Example method 900A can be implemented in a UE (e.g., UE 102). Method 900A begins at block 902, where the UE communicates with the RAN (e.g., Figure 3A Events 314, 316, 318, 328, 332, and 390A-F in -F Figure 4 Events 490, 418, and 422 in the diagram. At box 904, the UE determines whether it is a first UE type, a second UE type, or a dual UE type. If the UE determines at box 904 that it is a second UE type, the process continues to box 906. At box 906, the UE transmits a message to the RAN, wherein the message includes at least one UE capability of the first UE type and at least one UE capability of the second UE type (e.g., ...). Figure 4 (Event 424 in the diagram). If the UE determines at box 904 that it is the first UE type, the process continues to box 908. At box 908, the UE transmits a message to the RAN, which includes at least one UE capability of the first UE type, but does not include UE capabilities of the second UE type (e.g., ...). Figure 4 (Event 424 in the diagram). If the UE determines at box 904 that it is a dual UE type, the process continues to box 910. At box 910, the UE transmits a message to the RAN, which includes at least one UE capability of the first UE type, at least one UE capability of the second UE type, and UE capabilities indicating support for both the first and second UE types (e.g., ...). Figure 4Event 424 in the middle.

[0144] against Figure 7A The examples and implementations described can be applied to Figure 9A .

[0145] When the RAN receives at least one UE capability of a first UE type, at least one UE capability of a second UE type, and a UE capability indicating support for the first UE type and the second UE type, the RAN determines to communicate with the UE using at least one UE capability conforming to the first UE type or the second UE type, predefined UE capabilities, and / or required configuration parameters.

[0146] Figure 9B This is a flowchart of an example method 900B, similar to method 900A, except that method 900B includes block 907 instead of block 910. If the UE determines at block 904 that the UE is a second UE type, the process continues to block 907. At block 907, the UE transmits a message to the RAN, wherein the message includes at least one UE capability of the second UE type, but does not include UE capabilities of the first UE type (e.g., ...). Figure 4 (Event 424 in the diagram). If the UE determines at box 904 that the UE is a dual UE type, the process continues to box 906.

[0147] Unlike Figure 9A At least one UE capability of the first UE type is not applicable to the second UE type. Therefore, when the UE is of the second UE type, the UE avoids transmitting the UE capabilities of the first UE type to the RAN.

[0148] Figure 9C This is a flowchart of an example method 900C, similar to methods 900A-B, except that method 900C includes block 911 instead of block 910. If the UE determines at block 904 that it is a dual-UE type, the process continues to block 911. At block 911, the UE transmits a message to the RAN, wherein the message includes at least one UE capability of the first UE type and at least one UE capability of the dual-UE type (e.g., ...). Figure 4 (Event 424 in the text). In some implementations, where the UE is a dual UE type, the UE does not transmit or avoids transmitting UE capabilities specific to the second UE type to the RAN. In other implementations, where the UE is a dual UE type, the UE transmits UE capabilities specific to the second UE type to the RAN.

[0149] Figure 9DThis is a flowchart of example method 900D, similar to methods 900A-C. If the UE determines at box 904 that it is a second UE type, the process continues to box 907. If the UE determines at box 904 that it is a dual UE type, the process continues to box 911.

[0150] Turn now Figure 10A Example method 1000A can be implemented in a UE (e.g., UE 102). Method 1000A begins at block 1002, where the UE communicates with the RAN (e.g., Figure 3A Events 314, 316, 318, 328, 332, and 390A-F in -F Figure 4 Events 490, 418, and 422 in the sequence. At box 1004, the UE includes at least one UE capability of a first UE type in the message. At box 1006, the UE includes at least one UE capability of a second UE type in the message. At box 1008, the UE determines whether it is a dual UE type. If the UE determines at box 1008 that it is a dual UE type, the process continues to box 1010. At box 1010, the UE includes at least one UE capability of a dual UE type in the message. The process continues from box 1010 to box 1012. Otherwise, if the UE determines at box 1008 that it is not a dual UE type (e.g., the UE is either a first UE type or a second UE type), the process skips box 1010 and continues to box 1012. At box 1012, the UE transmits a message to the RAN (e.g., ...). Figure 4 Event 424 in the middle.

[0151] Figure 10B This is a flowchart of an example method 1000B, similar to method 1000A, except that method 1000B includes box 1009 instead of box 1008. The process continues from box 1004 to box 1009. If the UE determines at box 1009 that it is a dual UE type, the process continues to box 1010. If the UE determines that it is a second UE type, the process continues to box 1006. The process continues from boxes 1010 and 1006 to box 1012.

[0152] Unlike Figure 10A At least one UE capability of the first UE type is not applicable to the second UE type. Similarly, at least one UE capability of the second UE type is not applicable to the first UE type. Therefore, when a UE is of either the first or the second UE type, the UE avoids transmitting the UE capabilities of the other UE type to the RAN.

[0153] The above examples and implementation methods are applicable to Figure 10A and Figure 10B .

[0154] Turn now Figure 11A Example method 1100A can be implemented in a UE (e.g., UE 102). Method 1100A begins at block 1102, where the UE communicates with the RAN (e.g., Figure 3A Events 314, 316, 318, 328, 332, and 390A-F in -F Figure 4 Events 490, 418, and 422 (in the diagram). At box 1104, the UE transmits at least one RedCap UE capability to the RAN (e.g., Figure 4 Event 424 in the diagram). At box 1106, the UE transmits at least one fRedCap UE capability to the RAN (e.g., Figure 4 Event 424 in the diagram). At box 1108, the UE receives configuration parameters from the RAN that do not conform to at least one RedCap UE capability and / or at least one fRedCap UE capability (e.g., Figure 4 (Event 430 in the diagram). At box 1010, the UE ignores or discards the configuration parameters. At box 1012, the UE continues to communicate with the RAN after ignoring or discarding the configuration parameters.

[0155] Figure 11B This is a flowchart of an example method 1100B, similar to method 1100A, except that method 1100B includes blocks 1111 and 1114. At block 1111, the UE determines whether it has received configuration parameters in an RRC message. If the UE determines at block 1111 that it has not received configuration parameters in an RRC message (e.g., it received configuration parameters in a DCI), the process continues to block 1112. Otherwise, if the UE determines at block 1111 that it has received configuration parameters in an RRC message, the process continues to block 1114. At block 1114, the UE performs an RRC connection re-establishment procedure.

[0156] In some implementations, during the RRC connection re-establishment process, the UE transmits an RRCReestablishmentRequest message to the RAN, receives an RRCReestablishment message from the RAN, and transmits an RRCReestablishmentComplete message to the RAN.

[0157] The above examples and implementation methods are applicable to Figure 11A and Figure 11B .

[0158] Turn now Figure 12Example method 1200 can be implemented in a RAN node (e.g., DU 174, 174A, or 174B of base station 104, 106A, or 106B, or base station 104, 106A, or 106B). Method 1200 begins at block 1202, where the RAN node communicates with the UE (e.g., Figures 3A to 3F Events 314, 316, 318, 328, 328, 332, 390A-F, Figure 4 Events 490 and 418 in the diagram). At box 1204, the RAN node receives at least one first UE capability of a UE of the first UE type (e.g., Figure 4 Event 424 or 416 in the code. At box 1206, the RAN node receives at least one second UE capability of the second UE type (e.g., Figure 4 Events 424 or 416 in the diagram). At box 1208, the RAN node receives the UE's UE capabilities, which indicate support for a first UE type and a second UE type (e.g., ...). Figure 4 Events 424 or 416 in the diagram). At box 1210, the RAN node transmits configuration parameters for the first UE type or the second UE type to the UE (e.g., events 424 or 416 in the diagram). Figure 4 Event 430 in the diagram). At box 1212, the RAN communicates with the UE according to configuration parameters (e.g., Figure 4 Event 432 in the middle).

[0159] In some implementations, the RAN node receives at least one first UE capability, at least one second UE capability, and UE capabilities from the UE. In other implementations, the RAN node receives at least one first UE capability, at least one second UE capability, and UE capabilities from the CN (e.g., CN 110 or AMF 164). In some implementations, where the RAN node is a DU, the DU receives at least one first UE capability, at least one second UE capability, and UE capabilities from the CU. In some implementations, the CU receives at least one first UE capability, at least one second UE capability, and UE capabilities from the UE or the CN. In some implementations, the DU transmits configuration parameters to the UE via a protocol between the UE and the DU (e.g., PHY 202B or MAC 204B). In other implementations, the DU transmits configuration parameters to the UE via a protocol between the UE and the CU (e.g., RRC 214).

[0160] Next turn Figure 13AExample method 1300A can be implemented in a RAN node (e.g., DU174, 174A, or 174B of base stations 104, 106A, or 106B, or base stations 104, 106A, or 106B). Method 1300A begins at block 1302, wherein the RAN node receives at least one UE capability of a UE of a first UE type (e.g., Figure 4 (Events 424 or 416 in the diagram). At box 1304, the RAN node determines whether it has received the UE capability of the UE of the second UE type. If the RAN determines at box 1304 that it has not received the UE capability of the UE of the second UE type, the process continues to box 1306. At box 1306, the RAN node transmits at least one first configuration parameter of the first UE type to the UE (e.g., ...). Figure 4 Event 430 in the block. At box 1308, the RAN node communicates with the UE according to at least one first configuration parameter (e.g., Figure 4 Event 432 in the diagram). Otherwise, if the RAN determines at block 1304 that the RAN node has received the UE capability of the UE of the second UE type, the process continues to block 1310. At block 1310, the RAN node transmits at least one second configuration parameter of the second UE type to the UE (e.g., ...). Figure 4 Event 430 in the diagram). At box 1312, the RAN node communicates with the UE according to at least one second configuration parameter (e.g., Figure 4 Event 432 in the middle).

[0161] Figure 13B This is a flowchart of an example method 1300B, similar to method 1300A, except that method 1300B includes blocks 1303 and 1305 instead of blocks 1302 and 1304. Method 1300B begins at block 1303, where the process starts. At block 1305, the RAN node determines whether it has received UE capability of a first UE type or UE capability of a second UE type. If the RAN node determines that it has received UE capability of the first UE type, the process continues to blocks 1306 and 1308. Otherwise, if the RAN node determines that it has received UE capability of the second UE type, the process continues to blocks 1310 and 1312.

[0162] The above examples and implementation methods are applicable to Figures 12 to 13B .

[0163] Example 1. A method implemented in a user equipment (UE), the method comprising: receiving a UE capability request from a radio access network (RAN) node at the UE; generating a UE capability information message at the UE by including one of: (i) a first UE capability of a first UE type associated with a reduction in UE capability, or (ii) a second UE capability of a second UE type associated with a further reduction in UE capability, and avoiding including a different item of: (i) the first UE capability or (ii) the second UE capability; and transmitting the UE capability information message from the UE to the RAN node in response to the UE capability request.

[0164] Example 2. The method described in Example 1 further includes: receiving UE configuration parameters from the RAN node at the UE based on the UE capability information message, the UE configuration parameters corresponding to one of the first UE type or the second UE type.

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

[0166] Example 4. The method as described in Example 3 further includes: in a first instance: when the received UE configuration parameters do not include receiving the radio resource message, discarding the UE configuration parameters at the UE and continuing to communicate with the RAN node at the UE; and in a second instance: when the received UE configuration parameters do include receiving the radio resource message, performing a reconstruction procedure with the RAN node at the UE.

[0167] Example 5. The method as described in any one of Examples 1 to 4, wherein the generation is based on whether the UE has the first UE type or the second UE type.

[0168] Example 6. The method as described in any one of Examples 1 to 4, wherein the generation 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 of a third UE type associated with a normal UE capability; and avoiding including the first UE type and the second UE type.

[0169] Example 7. The method described in Example 6, wherein the generation is based on whether the UE has the first UE type, the second UE type, or the third UE type.

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

[0171] Example 9. A method implemented in a radio access network (RAN) node, the method comprising: transmitting a UE capability query from the RAN node to a user equipment (UE); receiving at the RAN node, in response to the UE capability query, one of the following: (i) a first UE capability corresponding to a first UE type associated with a reduction in UE capability, or (ii) a second UE capability corresponding to a second UE type associated with a further reduction in UE capability; and in a first instance, transmitting a first UE configuration parameter corresponding to the first UE type from the RAN node to the UE when the first UE capability is received; and in a second instance, transmitting a second UE configuration parameter corresponding to the second UE type from the RAN node to the UE when the second UE capability is received.

[0172] Example 10. The method as described in Example 9, wherein receiving the first UE capability or the second UE capability includes receiving a UE capability container that includes the first UE capability or the second UE capability.

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

[0174] Example 12. The method as described in any one of Examples 10 or 11 further includes: transmitting the UE capability container from the RAN node to the core network (CN).

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

[0176] Example 14. The method as described in any one of Examples 9 to 12, wherein the configuration parameter is associated with at least one of physical layer configuration or cell configuration.

[0177] Example 15. An apparatus that operates as a distributed radio access network (RAN) node, including processing hardware and configured to implement the method according to any one of Examples 9 to 14.

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

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

[0180] Generally, the description of one of the above figures can be applied to another of the above figures. If there is no conflict, the examples, implementations, and methods described above can be combined. The events or boxes described above can be optional or omitted. For example, events or boxes with dashed lines in the figures can be optional. In some implementations, "message" is used and "information element (IE)" can be used instead of "message." In some implementations, "IE" is used and "field" can be used instead of "IE." The description of the CU or DU is applicable to aggregated base stations that implement communication functions between the CU and DU and the UE. In the case of an aggregated base station, the messages exchanged between the CU and DU can be omitted or regarded as internal computer instructions or internal messages exchanged between different processes in the aggregated base station.

[0181] User devices (e.g., UE 102) that can implement the technologies disclosed herein can be any suitable device capable of wireless communication, such as smartphones, tablet computers, laptop computers, mobile game consoles, point-of-sale (POS) terminals, health monitoring devices, drones, cameras, media streaming dongles or other personal media devices, wearable devices such as smartwatches, wireless hotspots, femtocells, or broadband routers. Furthermore, in some cases, the user device can be embedded in electronic systems such as a vehicle's main unit or an advanced driver assistance system (ADAS). Even further, the user device can operate as an Internet of Things (IoT) device or a mobile internet device (MID). Depending on the type, the user device may include one or more general-purpose processors, computer-readable storage, a user interface, one or more network interfaces, one or more sensors, etc.

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

[0183] When implemented in software, these technologies can be provided as part of an operating system, a library used by multiple applications, or a specific software application. The software can be executed by one or more general-purpose processors or one or more dedicated processors.

[0184] Upon reading this disclosure, those skilled in the art will understand the additional alternative structural and functional designs used to identify devices with different capabilities based on the principles disclosed herein. Therefore, while specific embodiments and applications have been shown and described, it should be understood that the disclosed embodiments are not limited to the precise constructions and components disclosed herein. Various modifications, alterations, and changes that will be apparent to those skilled in the art to the arrangement, operation, and details of the methods and apparatus disclosed herein may be made without departing from the spirit and scope defined in the appended claims.

Claims

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

2. The method of claim 1, further comprising: receiving, at the UE, a UE configuration parameter from the RAN node according to the UE capability information message, the UE configuration parameter 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 receiving the UE configuration parameter includes receiving a radio resource message containing the UE configuration parameter.

4. The method of claim 3, further comprising: in a first instance: discarding, at the UE, the UE configuration parameter when receiving the UE configuration parameter 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 receiving the UE configuration parameter does include receiving the radio resource message. the generating is based on whether the UE is of the first UE type or the second UE type.

5. The method of any one of claims 1 to 4, wherein, the generating occurs in a first instance, and the method further comprises:

6. The method of any one of claims 1 to 4, wherein, in a second instance, generating the UE capability information message by: including a third UE capability of a third UE type associated with a normal UE capability; and avoiding including the first UE type and the second UE type.

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

8. A device operating as a user equipment, UE, comprising processing hardware and configured to implement a method according to any 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 query; ​ receiving, at the RAN node and in response to the UE capability enquiry, one of: (i) a first UE capability associated with a reduced UE capability corresponding to a first UE type, or (ii) a second UE capability associated with a further reduced UE capability corresponding to a second UE type; and transmitting, from the RAN node to the UE, first UE configuration parameters corresponding to the first UE type when the first UE capability is received; transmitting, from the RAN node to the UE, second UE configuration parameters corresponding to the second UE type when the second UE capability is received.

10. The method of claim 9, wherein, receiving the first UE capability or the second UE capability comprises receiving a UE capability container comprising 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 any one of claims 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 to 12, wherein, the UE is a first UE, the method further comprising: receiving, at the CU, a third UE capability corresponding to a third UE type of a second UE, the third UE type being 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 to 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 to 14.

Images