Techniques for communicating user equipment capability information - Patents.com

Abstract

Certain aspects of the present disclosure provide techniques for communicating user equipment (UE) capability information in a wireless communication network. An example method implemented by a UE includes receiving a request for UE capabilities from a network entity and transmitting a UE capability message in response to the request that distinguishes feature sets that the UE supports in different network types.

Description

[Technical field]

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS This application claims the benefit of and priority to U.S. Provisional Application No. 63 / 257,925, filed October 20, 2021, which is assigned to the assignee of this application and which is expressly incorporated by reference in its entirety as if fully set forth below and for all applicable purposes.

[0002] introduction Aspects of the present disclosure relate to wireless communications and, more specifically, to techniques for communicating user equipment (UE) capability information in wireless communications networks.

[0003] Wireless communication systems have been widely deployed to provide various telecommunication services such as telephony, video, data, messaging, broadcast, or other similar types of services. These wireless communication systems may employ multiple access techniques capable of supporting communication with multiple users by sharing available system resources (e.g., bandwidth, transmit power, or other resources). Multiple access techniques may rely on either code division, time division, frequency division orthogonal frequency division, single carrier frequency division, or time division synchronous code division, to name a few. These and other multiple access techniques have been adopted in various telecommunication standards to provide a common protocol that allows different wireless devices to communicate at city, national, regional, and even global levels.

[0004] Although wireless communication systems have made great technological advances over the years, challenges still exist. For example, complex and dynamic environments can still attenuate or block signals between wireless transmitters and wireless receivers, undermining the various established wireless channel measurement and reporting mechanisms used to manage and optimize the use of finite wireless channel resources. Thus, further improvements in wireless communication systems are needed to overcome various challenges. Summary of the Invention

[0005] One aspect provides a method for wireless communication by a user equipment (UE), the method including receiving a request from a network entity for capabilities of the UE, and transmitting a UE capabilities message in response to the request that distinguishes feature sets supported by the UE in different network types.

[0006] Another aspect provides a method for wireless communication by a network entity that includes transmitting, to a user equipment (UE), a request for UE capabilities and receiving, in response to the request, a UE capabilities message that distinguishes feature sets supported by the UE in different network types.

[0007] Another aspect provides a method for wireless communication by a user equipment (UE), the method including generating a subset of UE capability information and transmitting the subset of UE capability information to a network entity.

[0008] Another aspect provides a method for wireless communication by a network entity, the method including transmitting a request for a subset of user equipment (UE) capability information from a UE and receiving the subset of UE capability information from the UE.

[0009] Another aspect provides a method for wireless communication by a network entity that includes obtaining a subset of user equipment (UE) capability information associated with the UE and transmitting a request to the UE for an additional set of the UE capability information.

[0010] Other aspects provide an apparatus operable, configured, or otherwise adapted to perform the above-mentioned method as well as methods described elsewhere herein; a non-transitory computer-readable medium comprising instructions that, when executed by one or more processors of the apparatus, cause the apparatus to perform the above-mentioned method as well as methods described elsewhere herein; a computer program product embodied on a computer-readable storage medium comprising code for performing the above-mentioned method as well as methods described elsewhere herein; and an apparatus comprising means for performing the above-mentioned method as well as methods described elsewhere herein. By way of example, the apparatus may comprise a processing system, a device having a processing system, or processing systems that cooperate over one or more networks.

[0011] The following description and the annexed drawings set forth certain features by way of example only.

[0012] The accompanying drawings illustrate certain features of the various aspects described herein and are not to be construed as limiting the scope of the disclosure. [Brief description of the drawings]

[0013] [Figure 1] FIG. 1 is a block diagram conceptually illustrating an example wireless communication network. [Diagram 2] FIG. 2 is a block diagram conceptually illustrating an example of a base station and user equipment. [Figure 3A] 1 illustrates various example aspects of a data structure for a wireless communication network. [Figure 3B] 1 illustrates various example aspects of a data structure for a wireless communication network. [Figure 3C] 1 illustrates various example aspects of a data structure for a wireless communication network. [Figure 3D] 1 illustrates various example aspects of a data structure for a wireless communication network. [Figure 4] 1 illustrates an example of a wireless communications network that includes non-terrestrial network (NTN) entities. [Figure 5A] 1 illustrates an exemplary architecture of an NTN. [Figure 5B] 1 illustrates an exemplary architecture of an NTN. [Figure 6] FIG. 1 is a call flow diagram illustrating example operations for communicating user equipment (UE) capability information associated with a terrestrial network (TN) and an NTN. [Figure 7] 13 shows a first structure for a UE capability message. [Figure 8A] 13 shows a first structure variant for the UE capability message. [Figure 8B] 13 shows a first structure variant for the UE capability message. [Figure 8C] 13 shows a first structure variant for the UE capability message. [Figure 8D] 13 shows a first structure variant for the UE capability message. [Figure 9] 13 shows a second structure for the UE capability message. [Figure 10] 13 provides another example of a second structure for the UE capability message. [Figure 11] 13 shows a third structure for a UE capability message. [Figure 12] 1 illustrates a carrier aggregation / dual connectivity configuration for communication by user equipment. [Figure 13] 13 shows a fourth structure for a UE capability message. [Figure 14] 13 shows a fifth structure for a UE capability message. [Figure 15] 6 shows a sixth structure for a UE capability message. [Figure 16A] 13 shows different ways to implicitly indicate support for orbit types in a UE capability message. [Figure 16B] 13 shows different ways to implicitly indicate support for orbit types in a UE capability message. [Figure 16C] 13 shows different ways to implicitly indicate support for orbit types in a UE capability message. [Figure 17A] A different scheme is shown for indicating the frequency bands supported in the TN and NTN in the UE capability message. [Figure 17B] A different scheme is shown for indicating the frequency bands supported in the TN and NTN in the UE capability message. [Figure 17C] A different scheme is shown for indicating the frequency bands supported in the TN and NTN in the UE capability message. [Figure 17D] A different scheme is shown for indicating the frequency bands supported in the TN and NTN in the UE capability message. [Figure 18] FIG. 11 is a flow diagram illustrating an example operation for wireless communication by a UE. [Figure 19] 1 is a flow diagram illustrating example operations for wireless communication by network entities. [Figure 20] FIG. 11 is a flow diagram illustrating an example operation for wireless communication by a UE. [Figure 21] 1 is a flow diagram illustrating an example operation for wireless communication by a network entity, such as a source base station (BS). [Figure 22] 1 is a flow diagram illustrating an example operation for wireless communication by a network entity, such as a target BS. [Diagram 23] 1 illustrates aspects of an exemplary communications device. [Figure 24]1 illustrates aspects of an exemplary communications device. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0014] Aspects of the present disclosure provide apparatuses, methods, processing systems, and computer-readable media for communicating user equipment (UE) capability information indicating support for feature sets in a terrestrial network (TN) and a non-terrestrial network (NTN). In some cases, more specifically, aspects of the present disclosure provide structures for communicating UE capability information. In some cases, the UE capability information may distinguish features supported by the UE for different orbit types. In some cases, the UE capability information may distinguish features supported by the UE for carrier aggregation and dual connectivity. Furthermore, aspects of the present disclosure provide techniques for reducing the amount of information that needs to be signaled in the UE capability information. For example, in some cases, aspects of the present disclosure provide techniques for signaling a subset of the UE capability information.

[0015] Introduction to wireless communication networks FIG. 1 illustrates an example of a wireless communication network 100 in which aspects described herein may be implemented.

[0016] Generally, the wireless communication network 100 includes various network entities (alternatively, network elements or network nodes), which are generally, for example, logical entities associated with communication devices and / or communication functions associated with communication devices. For example, the various functions of the network, as well as the various devices associated with and interacting with the network, may be considered network entities.

[0017] In the illustrated example, the wireless communication network 100 includes a base station (BS) 102, a user equipment (UE) 104, and one or more core networks, such as an Evolved Packet Core (EPC) 160 and a 5G Core (5G Core, 5GC) network 190, which interoperate to provide communication services over various communication links, including wired and wireless links.

[0018] The BS 102 communicates wirelessly with the UE 104 via a communication link 120. The communication link 120 between the BS 102 and the UE 104 may include uplink (UL) (also referred to as reverse link) transmissions from the UE 104 to the BS 102, and / or downlink (DL) (also referred to as forward link) transmissions from the BS 102 to the UE 104. The communication link 120 may use multiple-input and multiple-output (MIMO) antenna technologies, including spatial multiplexing, beamforming, and / or transmit diversity in various aspects.

[0019] Communications using higher frequency bands may have higher path loss and shorter range compared to lower frequency communications. Thus, certain base stations (e.g., 180 in FIG. 1) may utilize beamforming 182 with UE 104 to improve path loss and range. For example, BS 180 and UE 104 may each include multiple antennas, such as antenna elements, antenna panels, and / or antenna arrays, to facilitate beamforming. In some cases, BS 180 may transmit beamformed signals to UE 104 in one or more transmit directions 182′. UE 104 may receive beamformed signals from BS 180 in one or more receive directions 182″. UE 104 may also transmit beamformed signals to BS 180 in one or more transmit directions 182″. BS 180 may also receive beamformed signals from UE 104 in one or more receive directions 182′. The BS 180 and the UE 104 may then perform beam training to determine the best receive and transmit directions for each of the BS 180 and the UE 104. In particular, the transmit and receive directions of the BS 180 may or may not be the same. Similarly, the transmit and receive directions of the UE 104 may or may not be the same.

[0020] In various aspects, the network entities or network nodes may be implemented as aggregate base stations, as distributed base stations, as integrated access and backhaul (IAB) nodes, as relay nodes, as sidelink nodes, to name a few.

[0021] FIG. 2 illustrates an example aspect of the BS 102 and UE 104.

[0022] Generally, the BS 102 includes various processors (e.g., 220, 230, 238, and 240), antennas 234a-t (collectively 234), transceivers 232a-t (collectively 232) including modulators and demodulators, and other aspects that enable wireless transmission of data (e.g., data source 212) and wireless reception of data (e.g., data sink 239). For example, the BS 102 may transmit and receive data between itself and the UE 104. The BS 102 includes a controller / processor 240 that may be configured to implement various functions described herein related to wireless communications.

[0023] Generally, the UE 104 includes various processors (e.g., 258, 264, 266, and 280), antennas 252a-r (collectively 252), transceivers 254a-r (collectively 254) including modulators and demodulators, and other aspects that enable wireless transmission of data (e.g., data source 262) and wireless reception of data (e.g., data sink 260). The UE 104 includes a controller / processor 280 that may be configured to implement various functions described herein relating to wireless communications.

[0024] Figures 3A, 3B, 3C, and 3D illustrate aspects of data structures for a wireless communications network, such as the wireless communications network 100 of Figure 1. In particular, Figure 3A is a diagram 300 illustrating an example of a first subframe in a 5G (e.g., 5G NR) frame structure, Figure 3B is a diagram 330 illustrating an example of a DL channel in a 5G subframe, Figure 3C is a diagram 350 illustrating an example of a second subframe in a 5G frame structure, and Figure 3D is a diagram 380 illustrating an example of a UL channel in a 5G subframe.

[0025] Further discussion regarding Figures 1, 2, 3A, 3B, 3C, and 3D is provided later in this disclosure.

[0026] Aspects Related to Non-Terrestrial Networks Non-terrestrial network (NTN) generally refers to a network or segment of a network that uses RF resources onboard a satellite. NTN signaling can be regenerative (with on-board NTN processing) or transparent (e.g., a so-called bent pipe where the satellite transmits back to Earth what it receives with only amplification and a shift from the uplink frequency to the downlink frequency).

[0027] 4 illustrates an example of a wireless communication network 400 including a non-terrestrial network (NTN) entity 140 (which may be generally referred to as an NTN entity 140) in which aspects of the disclosure may be practiced. In some examples, the wireless communication network 400 may implement aspects of the wireless communication network 100. For example, the wireless communication network 400 may include a BS 102, a UE 104, and an NTN entity 140, such as a satellite. In the case of a terrestrial network, the BS 102 may serve a coverage area or cell 110a, and in the case of an NTN, the non-terrestrial network (NTN) entity 140 may serve a coverage area 110b. Some NTNs may employ aerial platforms (e.g., drones or balloons) and / or space platforms (e.g., satellites).

[0028] The NTN entity 140 may communicate with the BS 102 and the UE 104 as part of wireless communications in the NTN. In the case of a terrestrial network, the UE 104 may communicate with the BS 102 via communication link 414. In the case of NTN wireless communications, the NTN entity 140 may be a serving cell for the UE 104 via communication link 416. In certain aspects, the NTN entity 140 may act as a relay (or remote radio head) for the BS 102 and the UE 104. For example, the BS 102 may communicate with the NTN entity 140 via communication link 418, and a non-terrestrial network entity may relay signaling between the BS 102 and the UE 104 via communication links 416, 418.

[0029] Typical footprint sizes of NTN beams are 100-1000 km for LEO satellites and 200-3500 km for Geostationary orbit (GEO) satellites. As shown in FIG. 5A, an NG-RAN deployment may include satellites and NTN gateways (GWs), which serve as cellular Uu) links between UEs and terrestrial network (TN) gNBs (and 5G core networks). NG-RAN generally represents the radio access network for 5G, providing both NR and LTE radio access. The link between the UE and the satellite is commonly referred to as the service link, and the link between the satellite and the GW is commonly referred to as the feeder link.

[0030] As shown in FIG. 5B, the satellite communicates with multiple different gateways as it moves across its orbit. In the example shown, the satellite moves from GW1 to GW2 as it orbits (at a speed of 7.5 km / s). The uplink signal from the UE experiences a round trip delay (RTD), which is generally the sum of the delay on the service link (DUE) and the delay on the feeder link (DSAT). The maximum RTD is typically about 541.46 ms for a GEO satellite, 25.77 ms for a LEO satellite at an altitude of 600 km, and 41.77 ms for a LEO satellite at an altitude of 1200 km. The UE speed is typically negligible compared to the speed of the LEO satellite.

[0031] Aspects Related to Communication of UE Capability Information In some cases, a UE may communicate with both a terrestrial network (TN) and a non-terrestrial network (NTN) simultaneously. Furthermore, in some cases, a UE may be handed over between a TN and an NTN, or vice versa. As such, a UE may support different features or capabilities for communicating with a TN and an NTN. For example, a UE may support a first set of capabilities in a TN and a second set of capabilities in an NTN. In some cases, capabilities in a TN may also be applicable to an NTN. The UE may indicate these capabilities to a base station (e.g., BS 102) and, in response, receive configuration information that configures the UE to use one or more of these capabilities when communicating with the base station.

[0032] Fifth generation (5G) new radio (NR) NTNs are being developed with the assumption that any legacy NR features (e.g., TN features) may be supported in the NTN, if desired. However, not all legacy UE TN features are applicable to the NTN. Therefore, a capability distinction between TN and NTN may be needed to indicate which features are supported by the UE in the TN and which features are supported by the UE in the NTN.

[0033] Furthermore, in some cases, when communicating in an NTN, certain features may depend on the satellite orbit type. For example, certain frequency bands may be assigned to geosynchronous or geosynchronous orbit (GSO) types and non-GSO (NGSO) types. However, different UE capabilities / features may be required for GSO types as compared to NGSO types. For example, UE capabilities / features may be considered mandatory for NGSO but non-mandatory for GSO. Therefore, capability differentiation between different orbit types may be required to indicate which features are supported by the UE in different orbit types.

[0034] Accordingly, aspects of the present disclosure provide techniques for indicating UE capability information for communicating in TNs and NTNs. For example, such techniques may include transmitting a UE capability message that distinguishes feature sets that the UE supports in different network types. In some cases, the techniques presented herein provide multiple different structures for transmitting the UE capability message.

[0035] Exemplary Call Flow Illustrating Operations for Communicating UE Capability Information 6 is a call flow diagram illustrating example operations 600 for communicating UE capability information related to a TN and an NTN. As shown, the operations 600 may be performed by a network entity 602 and a UE 604. In some cases, the network entity 602 may be an example of the BS 102 shown in Figures 1 and 2, or the NTN entity 140 shown in Figure 4. Additionally, in some cases, the UE 604 may be an example of the UE 104 shown in Figures 1, 2, and 4.

[0036] As shown, the operations 600 begin with the UE 604 receiving a request for UE capabilities from the network entity 602 at 610. The UE 604 then responds to the request by transmitting a UE capabilities message, as shown at 615, that distinguishes feature sets that the UE supports in different network types, such as TN and NTN. In some cases, the features relate to at least one of physical layer processing, medium access control layer processing, packet data convergence protocol (PDCP) processing, radio link control (RLC) processing, mobility, or IP Multimedia Subsystem (IMS).

[0037] In some cases, it may be necessary to differentiate UE capabilities between TN and NTN for the same feature. For example, in some cases, even for one and the same feature, the UE 604 may support this feature for TN but not for NTN, or vice versa. Furthermore, in some cases, the indication of UE capabilities may depend on the availability of internet of things (IoT) opportunities, so techniques may be required to allow the UE 605 to indicate UE capabilities differently between TN and NTN, even for the same feature. Thus, in some cases, the NTN may be defined or treated as a separate RAT (e.g., nr-ntn) from the NR TN. When requesting NTN-related capabilities from the UE 604, the network entity 602 may indicate nr-ntn in the RAT type field of the request (e.g., UE capability inquiry) received by the UE 604 at 610. Different RAT types, such as nr, eutra-nr, eutra, utra-fdd-v1610, etc., may also be indicated in the request.

[0038] Thus, if the UE 604 receives a request including an indication of an NTN RAT type, the UE capability message sent at 615 distinguishes a first feature set that the UE supports in the TN from a second feature set that the UE supports in the NTN. In some cases, the first feature set supported in the TN and the second feature set supported in the NTN may be distinguished in the UE capability message using a different structure.

[0039] A first structure 700 for a UE capability message 702 is shown in Figure 7. The UE capability message 702 may be an example of a UE capability message sent by the UE 604 at 615 in Figure 6. As shown, the UE capability message 702 includes a first container 704 indicating a first set of features that the UE 604 supports in the TN. Additionally, as shown, the UE capability message 702 includes one or more second containers 706 indicating a second set of features that the UE 604 supports in the NTN.

[0040] In some cases, the structure of the one or more second containers 706 for NTN features that the UE 604 supports may be the same or similar to the structure of the first container 704 for TN features that the UE 604 supports. In other words, the one or more second containers 706 for NTN features may reuse the structure of the first container 704 for TN features. For example, the first container 704 and the second container 706 may indicate common features. In other words, the one or more second containers 706 may include fields or information elements (IEs) for the same features as the first container 704. In this case, for TN features that are not applicable to NTN, the UE 604 may indicate the UE capabilities for these features as not supported.

[0041] In other cases, the structure of the one or more second containers 706 may differ from the structure of the first container 704. For example, in this case, for TN features that are not applicable to the NTN RAT type, the one or more second containers 706 may not have fields or IEs for these inapplicable features. That is, the first container 704 for the TN may include fields or IEs for these features, but the one or more second containers 706 may not include fields or IEs for these features.

[0042] In some cases, the UE capability message transmitted by the UE 604 in 615 may distinguish feature sets that the UE 604 supports in NTNs with different orbit types. In some cases, when orbit-specific UE features or capabilities exist, several variations of the first structure 700 shown in FIG. 7 may be considered to distinguish features that the UE 604 supports for different orbit types. For example, FIG. 8A, FIG. 8B, FIG. 8C, and FIG. 8D show different variation structures of the first structure 700 to distinguish UE support of NTN features for NTNs with different orbit types. In some cases, the different orbit types may include two or more of a low earth orbit (LEO) orbit type, a medium earth orbit (MEO) orbit type, a highly elliptical orbit (HEO) orbit type, a geostationary (GEO) orbit type, a non-GEO orbit type, a geosynchronous orbit type (GSO), a non-GSO orbit type, or a high-altitude platform station (HAPS) orbit type. The exemplary variant structures shown in Figures 8A, 8B, 8C, and 8D assume GEO and non-GEO orbit types, although other orbit types may also be supported by the variant structures shown in these figures.

[0043] FIG. 8A shows a first variation structure 800A for the UE capability message 702 transmitted by the UE 604 at 615 in FIG. 6, for example, the one or more second containers 706 in FIG. 7 include separate containers. More specifically, as shown in FIG. 8A, the UE capability message 702 comprises separate containers for NTN features with different orbit types. For example, as shown in FIG. 8A, the UE capability message 702 includes a TN container 802A for indicating one or more TN features that the UE 604 supports. Furthermore, the UE capability message 702 shown in FIG. 8 includes a first NTN container 804A for indicating features that the UE 604 supports for a first orbit type (e.g., GEO orbit type) and a second NTN container 806A for indicating features that the UE 604 supports for a second orbit type (e.g., non-GEO orbit type).

[0044] FIG. 8B illustrates a second variant structure 800B for the UE capability message 702, e.g., the one or more second containers 706 of FIG. 7 comprise one common container. More specifically, in the example illustrated in FIG. 8B, the UE capability message 702 comprises a common container that distinguishes feature sets that the UE 604 supports in NTNs having different trajectory types. For example, as shown, the UE capability message 702 illustrated in FIG. 8B includes a TN container 802B for indicating one or more TN features that the UE 604 supports. Furthermore, the UE capability message 702 illustrated in FIG. 8B includes a common NTN container 804B for indicating NTN features associated with different trajectory types that the UE 604 supports. In other words, the common NTN container 804B can be used to indicate features that the UE 604 supports for a first trajectory type (e.g., a GEO trajectory type) and features that the UE 604 supports for a second trajectory type (e.g., a non-GEO trajectory type).

[0045] In the example shown in Figure 8B, separate bitmaps may be used within the common NTN container 804B to indicate different features supported in NTNs of different trajectory types. For example, in some cases, each bitmap may include multiple bits, with each different bit corresponding to a different trajectory type and indicating whether a particular feature is supported for the corresponding trajectory type.

[0046] As an example, assume that the common NTN container 804B includes at least a first bitmap 806B for a first NTN feature, which includes the following bits 11000. In this example, the first bit may correspond to a GEO orbit type, the second bit may correspond to a MEO orbit type, the third bit may correspond to a LEO orbit type, the fourth bit may correspond to a HEO orbit type, and the fifth bit may correspond to a non-GEO orbit type. In this case, the first bitmap for the first feature may indicate that the UE 604 supports the first feature for GEO and MEO orbit types (e.g., a bit value of "1") and that the UE 604 does not support the first feature for LEO, HEO, or non-GEO orbit types (e.g., a bit value of "0"). Alternatively, a bit value of "0" may indicate that the UE 604 supports the corresponding orbit type, and a bit value of "1" may indicate that the UE 604 does not support the corresponding orbit type.

[0047] FIG. 8C illustrates a third variation structure 800C for the UE capability message 702, e.g., one or more of the second containers 706 of FIG. 7 comprise one common container. More specifically, similar to FIG. 8B, the UE capability message 702 illustrated in FIG. 8C comprises a common container for distinguishing feature sets supported by the UE 604 in NTNs having different trajectory types. However, in FIG. 8C, instead of distinguishing the features supported for different trajectory types using a bitmap, the common container may include separate capability fields for different trajectory types. For example, as shown, the UE capability message 702 illustrated in FIG. 8C includes a TN container 802C for indicating one or more TN features supported by the UE 604. Furthermore, the UE capability message 702 illustrated in FIG. 8C includes a common NTN container 804C for indicating NTN features associated with different trajectory types supported by the UE 604.

[0048] Further, as shown, the common NTN container 804C may include multiple separate fields to distinguish NTN features for different orbit types. For example, as shown, the common NTN container 804C may include a first NTN feature field 806C and a second NTN feature field 808C. In some cases, the first NTN feature field 806C may include capability information indicating that the UE 604 supports a first feature for a first orbit type (e.g., a GEO orbit type), and the second NTN feature field 808C may include capability information indicating that the UE 604 supports a second feature for a second orbit type (e.g., a non-GEO orbit type).

[0049] FIG. 8D illustrates a fourth variant structure 800D for the UE capability message 702, where, for example, one or more of the second containers 706 in FIG. 7 comprise one common container. More specifically, similar to FIG. 8B and FIG. 8C, the UE capability message 702 illustrated in FIG. 8D includes a common container that distinguishes feature sets supported by the UE 604 in NTNs having different trajectory types. However, in the example illustrated in FIG. 8D, the common container further includes a common feature field for indicating a common set of NTN features supported for different trajectory types, as well as multiple trajectory type specific fields for indicating NTN feature sets specific to a particular trajectory type. In other words, the UE capability message 702 illustrated in FIG. 8D includes a combination of at least one structure (e.g., a field) indicating a common feature set supported in different trajectory types and separate structures (e.g., separate fields) indicating different features supported in NTNs of different trajectory types.

[0050] For example, as shown, the UE capability message 702 shown in Figure 8D includes a TN container 802D for indicating one or more TN features supported by the UE 604. Additionally, the UE capability message 702 shown in Figure 8D includes a common NTN container 804D for indicating NTN features associated with different trajectory types supported by the UE 604. Additionally, as shown, the common NTN container 804D includes a common feature field 806D for indicating NTN features supported by the UE 604 that are common to both a first trajectory type (e.g., a GEO trajectory type) and a second trajectory type (e.g., a non-GEO trajectory type). Further, as shown, the common NTN container 804D includes a first orbit type specific field 808D for indicating features that the UE 604 uniquely supports for a first orbit type (e.g., a GEO orbit type) and a second orbit type specific field 810D for indicating features that the UE 604 uniquely supports for a second orbit type (e.g., a non-GEO orbit type).

[0051] In some cases, one of variant structures 800A, 800B, 800C, or 800D may be used to differentiate support by UE 604 for NTNs having different orbit types for features related to at least one of physical layer processing, medium access control (MAC) layer processing, packet data convergence protocol (PDCP) processing, radio link control (RLC) processing, mobility, and IP multimedia subsystem (IMS). For example, physical layer processing related features may include modulation schemes (e.g., higher modulation schemes may not be supported for certain orbit types), hybrid automatic repeat request (HARQ) related features (e.g., number of HARQ processes, HARQ round trip time, HARQ feedback such as disabling HARQ feedback, or DCI format support), processing time (e.g., short processing times may not be supported for certain orbit types), multiple-input multiple-output or beam related features (e.g., spatial relationship related features, channel state information related features, number of higher layers, sounding reference signal (SRS) switching, beam failure recovery (BFR), or parameters such as beamSwitchTiming and beamReportingTiming), extended cyclic prefix (CP) related features, semi persistent signaling (SPS) (e.g., configuration grant type 1 / 2), and / or DCI based bandwidth fraction BWP switching.

[0052] In some cases, PDCP related features may include, for example, sequence number (SN) length (e.g., a longer SN may be required for a particular orbit type, such as a GEO orbit type, due to longer transmission latency), as well as extended timers (e.g., t-PollRetransmit, t-StatusReport, t-reassembly, PDCP discard timers, etc., which may be longer for a particular orbit type, such as a GEO orbit type).

[0053] In some cases, the mobility related features may include one or more inter-RAT handover (HO) features. Additionally, in some cases, the IMS related features may include one or more voice over NR (VoNR) related features. In some cases, the feature layer may include other features related to high speed parameters.

[0054] A second structure 900 for a UE capability message 902 is shown in FIG. 9. The UE capability message 902 may be an example of a UE capability message sent by the UE 604 at 615 in FIG. 6. In contrast to the first structure 700 for a capability message shown in FIG. 7, which includes separate containers for TN features and NTN features, the second structure for the UE capability message 902 shown in FIG. 9 includes a common container 904 indicating a first feature set that the UE 604 supports in the TN and a second feature set that the UE 604 supports in the NTN. In this case, the second feature set that the UE 604 supports in the NTN may be defined as an extension of the first feature set that the UE 604 supports in the TN. For example, in addition to including the first feature set supported in the TN (e.g., UE capabilities in legacy NR), the common container 904 includes an extension 906 that includes a field or IE that indicates a second feature set supported in the NTN (e.g., UE capabilities in NR NTN).

[0055] In some cases, the structure of the extension 906 may be the same as or similar to the structure of a portion of the common container 904 that carries the first set of features supported in the TN. For example, this portion of the common container 904 may be similar to a portion of a legacy NR RAT capability container that would normally carry the first set of features supported in the TN, such as the first container 704 shown in FIG. 7. In other words, the extension 906 for NTN features may reuse the structure of the portion of the common container 904 for TN features (e.g., similar to the first container 704 of FIG. 7 for TN features). In this case, for TN features that are not applicable to the NTN, the UE 604 may indicate the UE capabilities for these features as not supported.

[0056] In other cases, the structure of the extensions 906 may differ from the structure of the portion of the common container 904 for TN features. For example, in this case, for TN features that are not applicable to the NTN RAT type, the extensions 906 may not have fields or IEs for these inapplicable features. That is, the common container may include fields or IEs indicating support for these features in the TN, but the extensions 906 may not include fields or IEs for these features.

[0057] In some cases, as described above, the UE capability message sent by the UE 604 at 615 may distinguish feature sets that the UE 604 supports in NTNs having different orbit types. In this case, a variant structure similar to that shown in Figures 8A, 8B, 8C, and 8D may apply to the second structure 900 and may be used for the UE capability message 902 shown in Figure 9.

[0058] In other cases, a legacy NR container for indicating UE capabilities may apply to TN and NTN by default. However, if orbit-type-specific (e.g., NTN-specific) capabilities need to be signaled differently, an extension of the legacy NR container may be added to distinguish these orbit-type-specific capabilities. In this case, a common set of features that apply to both TN and NTN networks by default may be included in the common container 904. Furthermore, an extension 906 may be used to distinguish features that are supported in only one of the TN or NTN. For example, as shown in FIG. 10, the UE capability message 902 includes a common container 1002 that includes a common set of features that apply to both TN and NTN networks by default. Furthermore, the UE capability message 902 includes an extension 1004 that distinguishes features that are supported in only one of the TN or NTN. In other words, if a first feature is supported in the TN but not in the NTN, the extension 1004 may indicate that this feature is not supported in the NTN. Instead, if the second feature is supported in both the TN and the NTN, then the feature may be included in the common container 1002 and it may be understood that the second feature is supported for both the TN and the NTN. In other words, since the second feature is supported in both the TN and the NTN, it does not need to be indicated separately for both the TN and the NTN.

[0059] A third structure 1100 for a UE capability message 1102 is shown in FIG. 11. The UE capability message 1102 may be an example of a UE capability message sent by the UE 604 at 615 in FIG. 6. As shown, the third structure 1000 is a combination of the first structure 700 and the second structure 900. For example, like the second structure 900 shown in FIG. 9, the UE capability message 1102 in the third structure 1100 includes a common container 1104 indicating a first feature set that the UE 604 supports in the TN and at least a portion of a second feature set that the UE 604 supports in the NTN. In some cases, the common container 1104 may comprise a legacy NR RAT capability container that includes an extension 1106 (e.g., one or more fields / IEs) to indicate the portion of the second feature set that the UE 604 supports in the NTN. 7, the UE capability message 1102 includes a second container 1108 for indicating features that the UE 604 supports for the NTN. More specifically, the second container 1108 may indicate a second portion of a second feature set that the UE supports in the NTN.

[0060] In some cases, when using the third structure 1100 for the UE capability message 1102, the network entity may indicate "nr" and "nr-ntn" in the RAT type field of the request (e.g., UE capability inquiry) received by the UE 604 at 610. Furthermore, when using the third structure 1100 for the UE capability message 1102, support for features in NTN may be grouped into two groups and indicated in the corresponding container (e.g., common container 1104 or second container 1108). In some cases, when indicating support for orbit-specific features / capabilities, a similar variant structure to that shown in Figures 8A, 8B, 8C, and 8D may apply to the third structure 1100 and be used for the UE capability message 1102 shown in Figure 11.

[0061] In some cases, the NTN features may be grouped in different manners. For example, in some cases, the common TN and NTN features may be grouped into a first group and included in the common container 1104. In other words, the common TN and NTN features represent a first feature set that the UE 604 supports in the TN and at least a portion of a second feature set that the UE 604 supports in the NTN, which are shown in the common container 1104. Furthermore, the NTN features that are not common between the TN and the NTN may be grouped into a second group and included in the second container 1108. In other words, the non-common NTN features represent a second portion of the second feature set that the UE supports in the NTN.

[0062] In other cases, NTN features for which the legacy NR RAT UE capability structure already supports sufficient granularity (e.g., capability granularity per band or per band combination) may be grouped in a first group, while NTN features for which the legacy NR RAT UE capability structure does not support sufficient granularity (e.g., capability granularity per UE). In this case, NTN features for which the legacy NR RAT UE capability structure already supports sufficient granularity may be included in the common container 1104, while NTN features for which the legacy NR RAT UE capability structure does not support sufficient granularity may be included in the second container 1108.

[0063] In some cases, the second container is limited to differential UE capabilities compared to the common container 1104. More specifically, the second container 1108 may be used to indicate support for NTN features / capabilities that need to be reported differently than TN features (e.g., not common to TN). For example, if the UE needs to report support for NTN for some feature or capability differently, the second container 1108 includes only the features that need to be reported differently. In some cases, additional containers may also be included in the UE capability message 1102 to indicate differential UE capabilities for different orbit types. For example, in some cases, the second container 1108 may be used to indicate differential UE capabilities for GEO orbit types, while a third container may be used to indicate differential UE capabilities for non-GEO orbit types. In some cases, these techniques may reduce the size of the second container 1108 since only features that are reported differently are included. Any newly introduced NTN-specific capabilities or features may be added to the common container 1104 in the extension 1106. In some cases, an indication of whether the UE needs to report a particular NTN feature or capability differently may also be added to the common container 1104.

[0064] Aspects Related to Signaling of TN-NTN Carrier Aggregation and Dual Connectivity Capability In some cases, carrier aggregation (CA) and dual connectivity (DC) may be used by the UE 604 to communicate with a network such as a TN or NTN. For example, in some cases, the UE may use CA / DC to communicate with a TN base station (e.g., BS 102) using one or more TN carriers and to communicate with an NTN base station (e.g., NTN entity 140) using one or more NTN carriers. The one or more TN carriers and the one or more NTN carriers may be within a particular respective TN-specific frequency band and NTN-specific frequency band. In other cases, the UE may use CA / DC to communicate with two different NTN base stations (e.g., two different NTN entities 140). In some cases, the CA / DC communication may be facilitated through two different base stations from the UE 604 perspective, but from the network perspective, the CA / DC communication may be controlled or operated by only one network entity.

[0065] 12 illustrates a CA / DC configuration for communication by a UE, such as UE 604. As shown, in some cases, the UE may use CA / DC to communicate with a TN base station 1202 using a TN carrier 1204 as well as to communicate with a first NTN base station 1206 using a first NTN carrier 1208. In some cases, the first NTN base station may be associated with a first orbit type (e.g., GEO, LEO, or MEO).

[0066] In other cases, a UE may use CA / DC to communicate with two different NTN base stations that may be associated with different orbit types. Furthermore, in some cases, such CA / DC communication may be inter-band or intra-band. For example, as shown, a UE may use CA / DC, known as inter-band NTN CA / DC, in some cases to communicate with a first NTN base station 1206 using a first NTN carrier 1208 and to communicate with a second NTN base station 1210 using a second NTN carrier 1212. Furthermore, as shown, the first NTN base station 1206 and the second NTN base station 1210 may be of the same orbit type, and thus this type of CA / DC may further be known as intra-orbit CA / DC.

[0067] Additionally, in other cases, a UE may use CA / DC to communicate with a third NTN base station 1214 using the first NTN carrier 1208 and to communicate with a second NTN base station 1210 using the second NTN carrier 1212. Again, this may be known as inter-band NTN CA / DC. However, in this example, the second NTN base station 1210 and the third NTN base station 1214 may be of different orbit types. As such, this type of CA / DC may further be known as inter-orbit CA / DC.

[0068] In other cases, the UE may use CA / DC to communicate with the second NTN base station 1210 using the second NTN carrier 1212 and to communicate with the fourth NTN base station 1216 using the second NTN carrier 1212. This may be known as in-band NTN CA / DC. Further, in this example, the second NTN base station 1210 and the fourth NTN base station 1216 may be of the same orbit type.

[0069] In some cases, when using TN-NTN CA / DC for communication, additional UE capability information may need to be signaled, such as support for one or more TN-NTN band combinations (e.g., combinations of TN and NTN frequency bands that the UE supports for communicating with the TN and NTN using CA / DC). Accordingly, aspects of the present disclosure provide techniques for signaling this additional UE capability information in the UE capability message transmitted by the UE 604 at 615 of FIG.

[0070] For example, in some cases, when UE-NR TN-NTN capabilities need to be signaled, an E-UTRA-NR dual connectivity (EN-DC) approach or an NR-E-UTRA dual connectivity (NE-DC) approach may be used, as shown in Figure 13. For example, Figure 13 shows a fourth structure 1300 for sending a UE capability message to indicate support for features / capabilities related to TN-NTN. As shown, Figure 13 includes a UE capability message 1302, which may be an example of a UE capability message sent by the UE 604 at 615 of Figure 6.

[0071] Further, similar to the EN-DC and NE-DC cases, the UE capability message 1302 includes a first container 1304 (e.g., a UE-NR container for legacy NR features) to indicate a first feature set that the UE 604 supports in the TN. Further, as shown, the UE capability message 1302 includes a second container 1306 (e.g., a UE-NR-NTN container for standalone NTN features) to indicate a second feature set that the UE 604 supports in the NTN. Further, the UE capability message 1302 includes a third container 1308 (e.g., a UE-NR-TN-NTN container for TN-NTN CA / DC features) that includes a TN and NTN feature set. For example, as shown, the third container 1308 may include a set 1310 of TN and NTN band combinations for which the UE 604 supports at least one of carrier aggregation or dual connectivity.

[0072] In some cases, when orbit-specific RATs (e.g., GEO, non-GEO, etc.) are defined and request the UE 604 to indicate support for features / capabilities associated with different NTN orbit types, the third container 1308 may include different TN and NTN band combination sets for each NTN orbit type. The UE may indicate support for features / capabilities associated with different NTN orbit types in separate containers. For example, in some cases, the third container 1308 may be associated with a first orbit type (e.g., GEO orbit type) and may be used to indicate a TN and NTN band combination set for the first orbit type. Furthermore, the UE capability message 1302 may include at least one other container that may be associated with a second orbit type (e.g., non-GEO orbit type) and may be used to indicate another TN and NTN band combination set for the second orbit type. In other words, the TN-NTN CA / DC features supported by the UE for different orbit types may be included in separate containers (e.g., separate UE-NR-TN-NTN containers).

[0073] FIG. 14 illustrates a fifth structure 1400 that may be used to transmit a UE capability message 1402 to indicate support for TN-NTN CA / DC related features / capabilities. In some cases, the UE capability message 1402 may be an example of a UE capability message transmitted by the UE 604 at 615 in FIG. 6. Furthermore, in some cases, the fifth structure 1400 for the UE capability message 1402 may be similar to a structure used for NR-CA / DC. For example, as shown, the UE capability message 1402 includes a first container 1404 (e.g., a UE-NR container for legacy NR features) to indicate a first feature set that the UE 604 supports in the TN. Furthermore, the first container 1404 may be extended to include a portion 1406 (e.g., one or more fields or IEs) that indicates a second feature set that is supported in the NTN (e.g., UE capabilities in the NR NTN). Further, as shown, the portion 1406 may include a set 1408 of band combinations of TNs and NTNs for which the UE 604 supports at least one of carrier aggregation or dual connectivity.

[0074] FIG. 15 illustrates a sixth structure 1500 that may be used to transmit a UE capability message 1502 to indicate support for TN-NTN CA / DC related features / capabilities. In some cases, the UE capability message 1502 may be an example of a UE capability message transmitted by the UE 604 at 615 in FIG. 6. As shown, the sixth structure 1500 for the UE capability message 1502 represents a combination of the fourth structure 1300 shown in FIG. 13 and the fifth structure 1400 shown in FIG. 14. In the example shown in FIG. 15, the UE 604 may indicate support for TN-NTN dual connectivity and carrier aggregation features (e.g., band combination set supported for carrier aggregation and dual connectivity) in a separate container.

[0075] For example, as shown, the UE capability message 1502 includes a first container 1504 (e.g., a UE-NR container for legacy NR features) to indicate a first set of features supported by the UE 604 in the TN. Further, the first container 1504 may be extended to include a portion 1506 (e.g., one or more fields or IEs) indicating a second set of features supported in the NTN (e.g., UE capabilities in NR NTN). Further, as shown, the portion 1506 may include a set of band combinations 1508 of TNs and NTNs for which the UE 604 supports carrier aggregation. As shown, the UE capability message 1502 also includes a second container 1510 (e.g., a UE-NR-NTN container for standalone NTN features) indicating a second set of features supported by the UE 604 in the NTN.

[0076] Further, as shown, the UE capability message 1502 includes a third container 1512 that includes a TN and NTN feature set for the TN-NTN DC (e.g., a UE-NR-TN-NTN container for TN-NTN DC features). For example, as shown, the third container 1512 includes a set 1514 of TN and NTN band combinations for which the UE 604 supports dual connectivity.

[0077] Additional details showing the feature sets supported in NTN with different trajectory types As noted above, in some cases, the UE capability message transmitted by the UE 604 at 615 may distinguish feature sets that the UE 604 supports in NTNs having different orbit types. In some cases, the UE 604 may distinguish feature sets for GEO orbit types from feature sets for non-GEO orbit types, e.g., using one of the variant structures shown in Figures 8A-8D. In other cases, the distinction of feature sets for orbit types may be more granular. For example, in some cases, the UE 604 may distinguish feature sets for LEO, MEO, HEO, and / or GEO orbit types in the UE capability message.

[0078] In some cases, orbit types may be characterized in terms of elevation angles. For example, orbits within a range of elevation angles X to Y may be considered a first orbit type, while orbits in the range of Y to Z may be considered a second orbit type, and so on. More specifically, orbital elevation angles between, for example, 300 km and 36,000 km with a granularity of 2 km may be defined as several different orbit types.

[0079] Furthermore, in some cases, since the UE 604 may not be aware of the orbit type, but may be aware of the communication characteristics associated with the orbit type, communication characteristics such as latency levels (one-way or round trip time) and environmental changes (e.g., radio quality changes due to satellite movement) may be considered when differentiating between feature sets supported by the UE 604. More specifically, for example, latency levels from 20 ms to 600 ms with a granularity of 20 ms may be defined as several different orbit types.

[0080] In some cases, in addition to indicating the feature sets that the UE 604 supports for different trajectory types, the UE 604 may also indicate whether the UE 604 supports these different trajectory types to get started. The UE 604 may indicate support for the trajectory types in different manners, such as via an implicit indication, an explicit indication, or a combination thereof.

[0081] In some cases, the UE may implicitly indicate support for the trajectory type in different manners, as shown in Figures 16A, 16B, and 16C. In some cases, the different manners of indicating support for the trajectory type may be applicable to the second structure 900 shown in Figure 9 for the capability message sent at 615 in Figure 6 and the third structure 1100 shown in Figure 11 for the capability message sent at 615.

[0082] 16A illustrates a first scheme for implicitly indicating support for a trajectory type in a UE capability message 1602. In some cases, the UE capability message 1602 includes the UE capability message sent by the UE 604 in 615 and incorporates the second structure 900 shown in FIG. 9. For example, the UE capability message 1602 includes a common container 1604 (e.g., similar to the common container 904 shown in FIG. 9) that includes a common feature set that applies by default to both TN and NTN networks and an extension that includes a field or IE that indicates a second feature set supported in the NTN (e.g., UE capabilities in an NR NTN).

[0083] Further, as shown, the common container 1604 includes a band combination list 1606. The band combination list 1606 includes a set of frequency bands that the UE 604 supports in the TN and NTN. For example, as shown, the band combination list 1606 indicates that the UE 604 supports frequency bands n1 and n3 in the TN and frequency bands n400 and n401 in the NTN. In some cases, the frequency bands n400 and n401 may comprise the same physical frequency band, but may be used to distinguish whether the UE 604 supports this physical frequency band for different NTN orbit types. For example, in some cases, an index of the frequency band n400 in the band combination list 1606 may implicitly indicate that the UE 604 supports the physical frequency band for a LEO orbit type, while an index of the frequency band n401 may implicitly indicate that the UE 604 supports the physical frequency band for a MEO orbit type.

[0084] 16B illustrates a second scheme for implicitly indicating support for a trajectory type in a UE capability message 1602. As shown, the second scheme for implicitly indicating support for a trajectory type includes a band combination set IE defined for each trajectory type. In some cases, the band combination set may include a bit set associated with each frequency band indicated in the band combination list 1606. For example, as shown, frequency band n1 is associated with a first bit set 1608 in the band combination list 1606, and frequency band n3 is associated with a second bit set 1610 in the band combination list 1606.

[0085] The first bit set 1608 includes a first bit set to indicate support by the UE 604 of frequency band n1 for different orbit types. For example, in some cases, when a first bit of the first bit set 1608 is set to a value of “1”, this may indicate that the UE 604 supports frequency band n1 for a LEO orbit type. Furthermore, when a second bit of the first bit set 1608 is set to a value of “1”, this may indicate that the UE 604 supports frequency band n1 for a MEO orbit type. Each remaining bit of the first bit set 1608 may indicate whether the UE 604 supports frequency band n1 for the remaining orbit type (e.g., HEO, GEO, non-GEO, etc.). In some cases, a value of “0” rather than a value of “1” in the first bit set 1608 may indicate that the UE 604 supports the n1 band for the corresponding orbit type.

[0086] Similarly, the second bit set 1610 includes a second bit set to indicate support by the UE 604 of frequency band n3 for a different orbit type. For example, in some cases, when a first bit of the second bit set 1610 is set to a value of “1”, this may indicate that the UE 604 supports frequency band n3 for a LEO orbit type. However, when a second bit of the second bit set 1610 is set to a value of “0”, this may indicate that the UE 604 does not support frequency band n3 for a MEO orbit type. Each remaining bit of the second bit set 1610 may indicate whether the UE 604 supports frequency band n3 for the remaining orbit type (e.g., HEO, GEO, non-GEO, etc.). In some cases, a value of “0” rather than a value of “1” in the second bit set 1610 may indicate that the UE 604 supports the n3 band for the corresponding orbit type.

[0087] FIG. 16C illustrates a third manner for implicitly indicating support for an orbit type in the UE capability message 1602. As shown, the third manner of implicitly indicating support for an orbit type includes repeating the same frequency band or band number in the band combination list 1606. For example, as shown, frequency band n400 may be repeated twice in the band combination list 1606. In some cases, each repetition of frequency band n400 may indicate support for a different orbit type. For example, if the band combination list 1606 does not include a repetition of frequency band n400, this may indicate that the UE 604 supports frequency band n400 for a LEO orbit type. Furthermore, if the band combination list 1606 includes one repetition of frequency band n400, as shown in FIG. 16C, this may indicate that the UE 604 supports frequency band n400 for a LEO orbit type and a MEO orbit type. Additional repetitions, such as two repetitions, of frequency band n400 may indicate that UE 604 supports frequency band n400 for a LEO orbit type, a MEO orbit type, and a GEO orbit type, etc.

[0088] As mentioned above, in some cases, the UE 604 may explicitly indicate support for different orbit types. For example, the UE 604 may provide different explicit indications in the UE capability message transmitted at 615 indicating which orbit types the UE 604 supports. In some cases, the explicit indications may be indicated for each frequency band in the band combination list. For example, in some cases, the UE 604 may provide a first explicit indication that the UE 604 supports frequency band n400 for a LEO orbit type and may also provide a second explicit indication that the UE 604 does not support frequency band n400 for a MEO orbit type. In some cases, the explicit indications may use the general name of the orbit type, such as LEO, MEO, GEO, etc.

[0089] In some cases, rather than explicitly indicating the different orbit types that the UE 604 supports, the UE 604 may instead indicate the different orbit elevation angles that may be supported by the UE 604. The different orbit elevation angles may each be associated with a range and granularity (e.g., orbit elevation angles from 300 km to 36,000 km with a granularity of 2 km). Thus, the UE 604 may indicate which elevation angles within the range the UE 604 may support.

[0090] Whether the UE 604 implicitly or explicitly indicates the orbit types supported, the UE 604 may either indicate each orbit type that the UE 604 supports or may indicate the highest orbit type supported by the UE 604. In some cases, when the highest orbit type supported by the UE 604 is indicated, this may imply that lower orbit types are also supported by the UE 604.

[0091] Additional details on indicating frequency bands supported by NTN As mentioned above, in some cases, the UE capability message sent by the UE 604 at 615 may indicate a first feature set that the UE 604 supports in the TN and a second feature set that the UE 604 supports in the NTN. In some cases, the first feature set may include frequency bands supported by the UE 604 in the TN, and the second feature set may include frequency bands supported by the UE 604 in the NTN. In some cases, the frequency bands supported by the UE 604 may be indicated in one or more band combination lists in the UE capability message. Figures 17A, 17B, 17C, and 17D show different ways to indicate frequency bands supported by the UE 604 in the TN and NTN.

[0092] 17A illustrates a first scheme for indicating frequency bands supported by a UE 604 in a TN and an NTN in a UE capability message 1702. In some cases, the UE capability message 1702 includes a UE capability message sent by the UE 604 in 615 and incorporates the second structure 900 illustrated in FIG. 9. For example, the UE capability message 1702 includes a first container 1704 (e.g., similar to the common container 904 illustrated in FIG. 9) that includes a common feature set that applies by default to both TN and NTN networks and an extension that includes a field or IE that indicates a second feature set supported in the NTN (e.g., UE capabilities in an NR NTN).

[0093] Further, as shown, the first container 1704 includes a band combination list 1706. The first band combination list 1706 includes a set of frequency bands that the UE 604 supports in the TN and the NTN. In some cases, in the first band combination list 1706, the UE 604 may use NTN-specific band definitions for the frequency bands supported by the UE 604 in the NTN to distinguish the frequency bands supported by the UE 604 in the NTN from the frequency bands supported by the UE 604 in the TN. For example, as shown in FIG. 17A, the UE 604 may indicate that the UE 604 supports frequency bands n1 and n3 in the TN by indicating these frequency bands in the first band combination list 1706. Further, the UE 604 may indicate an NTN-specific frequency band, such as n400, to indicate that the UE 604 supports frequency band n400 in the NTN.

[0094] 17B illustrates a second scheme for indicating the frequency bands supported by the UE 604 in the TN and NTN in a UE capability message 1702. As shown, the second scheme for indicating the supported frequency bands includes the use of separate band combination lists for the TN and NTN. For example, as shown in FIG. 17B, the UE capability message 1702 has a structure similar to the first structure 700 illustrated in FIG. 7, including a first container 1704 indicating a first feature set supported by the UE 604 in the TN and a second container 1708 indicating a second feature set supported by the UE 604 in the NTN.

[0095] In some cases, the first feature set may include a set of frequency bands supported by the UE 604 in the TN and may be indicated in a first band combination list 1706 included in the first container 1704. Additionally, the second feature set may include a set of frequency bands supported by the UE 604 in the NTN and may be indicated in a second band combination list 1710 included in the second container 1708. In some cases, when indicating the frequency bands supported by the UE 604 in the NTN in the second band combination list 1710 rather than indicating NTN-specific frequency bands as in the first scheme described above with respect to FIG. 17A, the UE 604 may instead include an indication of an existing TN frequency band and an indication of NTN support capability for that frequency band. For example, as shown, the UE 604 may indicate support for TN frequency bands n1 and n3 in the first band combination list 1706. Further, the UE 604 may also indicate frequency bands n1 and n3 in the second band combination list 1710 to indicate that the UE 604 supports these frequency bands in the NTN.

[0096] 17C illustrates a third scheme for indicating frequency bands supported by the UE 604 in the TN and NTN in a UE capability message 1702. As shown, the structure of the UE capability message 1702 in FIG. 17C may be the same or similar to the second structure 900 shown in FIG. 9. As shown, the third scheme for indicating the supported frequency bands includes a Band Combination Set IE defined for each frequency band. In some cases, each Band Combination Set IE may include a bit set associated with the respective frequency band, and the bit set may be set to indicate whether the UE 604 supports the respective frequency band in the NTN.

[0097] For example, the UE capabilities message 1702 includes a first container 1704 (e.g., similar to the common container 904 shown in FIG. 9 ) that includes a common feature set that applies by default to both the TN network and the NTN network, and an extension that includes a field or IE that indicates a second feature set supported in the NTN (e.g., UE capabilities in an NR NTN).

[0098] Further, the first container 1704 includes a first band combination list 1706. Further, as shown, the first band combination list 1706 includes a set of frequency bands, such as frequency bands n1 and n3, that the UE 604 supports in the TN. Each of the frequency bands n1 and n3 may be associated with a band combination set IE that includes a bit set that may be used to indicate whether the UE 604 supports the frequency bands n1 and n3 in the NTN. For example, as shown, the frequency band n1 may be associated with a first band combination set IE that includes a first bit set 1712, and the frequency band n3 may be associated with a second band combination IE that includes a second bit set 1714. In some cases, one or more bits or the first bit set 1712 may be set (e.g., to a bit value of "1") to indicate that the UE 604 supports the frequency band n1 in the NTN. Similarly, one or more bits or the second set of bits 1714 may be set (e.g., to a bit value of "1") to indicate that the UE 604 supports frequency band n3 in the NTN. In some cases, a bit value of "0" rather than a bit value of "1" may indicate that the UE 604 supports a corresponding frequency band in the NTN, such as frequency band n1.

[0099] 17D illustrates a fourth scheme for indicating frequency bands supported by the UE 604 in the TN and NTN in a UE capability message 1702. As shown, the fourth scheme for indicating the supported frequency bands includes the use of a band combination list to indicate the frequency bands supported for the TN and a separate bitmap to indicate the frequency bands supported in the NTN. For example, as shown in FIG. 17D, the UE capability message 1702 has a structure similar to the first structure 700 illustrated in FIG. 7, including a first container 1704 indicating a first feature set supported by the UE 604 in the TN and a second container 1708 indicating a second feature set supported by the UE 604 in the NTN.

[0100] As described above, the first feature set may include a set of frequency bands supported by the UE 604 in the TN and may be indicated in a first band combination list 1706 included in the first container 1704. Additionally, the second feature set may include a set of frequency bands supported by the UE 604 in the NTN. However, unlike the frequency bands supported by the UE 604 in the TN, the set of frequency bands supported by the UE 604 in the NTN may be indicated in the second container 1708 using a new capability IE, such as a bitmap.

[0101] For example, as shown, the second container 1708 includes a bitmap 1716 including a plurality of bits. In some cases, each bit of the plurality of bits of the bitmap 1716 in the second container 1708 may correspond to a different frequency band indicated in the first band combination list 1706 of the first container 1704. As an example, a first bit of the bitmap 1716 may correspond to a frequency band n1 indicated in the first band combination list 1706 of the first container 1704. Similarly, a second bit of the bitmap 1716 may correspond to a frequency band n3 indicated in the first band combination list 1706 of the first container 1704. Thus, the UE 604 may selectively set the first bit and the second bit to indicate whether the UE 604 supports frequency bands n1 and n3 in the NTN. For example, as shown, the UE 604 may set the first bit and the second bit to a value of "1," indicating that the UE 604 supports frequency bands n1 and n3 in the NTN. In some cases, a bit value of "0" may be used instead of a bit value of "1" to indicate that the UE 604 supports frequency bands n1 and n3 in the NTN.

[0102] Exemplary Method for Communicating UE Capability Information FIG. 18 illustrates a method 1800 for wireless communication by a UE, such as the UE 104 in the wireless communication network 100 of FIG. 1 and / or the UE 604 shown in FIG. 6, to communicate UE capability information.

[0103] As shown, method 1800 begins at step 1810 where the UE receives a request from a network entity for capabilities of the UE.

[0104] In step 1820, the UE responds to the request by sending a UE capabilities message that distinguishes feature sets that the UE supports in different network types.

[0105] In some cases, the UE capability message distinguishes a first set of features that the UE supports in a terrestrial network (TN) from a second set of features that the UE supports in a non-terrestrial network (NTN).

[0106] In some cases, the request includes a radio access technology (RAT) type that indicates the NTN as a separate RAT.

[0107] In some cases, the UE capability message distinguishes the feature sets that the UE supports in NTNs with different orbit types.

[0108] In some cases, the different orbit types include two or more of a low Earth orbit (LEO) orbit type, a medium Earth orbit (MEO) orbit type, a highly elliptical orbit (HEO) orbit type, a geostationary orbit (GEO) orbit type, or a non-GEO orbit type.

[0109] In some cases, the UE capability message includes a first container indicating a first set of features supported by the UE in the TN and one or more second containers indicating a second set of features supported by the UE in the NTN.

[0110] In some cases, the one or more second containers include separate containers for NTNs having different trajectory types.

[0111] In some cases, the one or more second containers include a common container that distinguishes feature sets supported by the UE in NTNs having different orbit types.

[0112] In some cases, the common container includes at least one of separate bitmaps indicating different features supported in NTNs of different trajectory types, separate capability fields for different trajectory types, or a combination of at least one structure indicating a common set of features supported in different trajectory types and separate structures indicating different features supported in NTNs of different trajectory types.

[0113] In some cases, the one or more second containers differentiate UE support for features related to at least one of physical layer processing, Packet Data Convergence Protocol (PDCP) processing, Radio Link Control (RLC) processing, mobility, or IP Multimedia Subsystem (IMS) for NTNs having different orbit types.

[0114] In some cases, the first container and one or more second containers indicate common features, and for a feature that is not applicable to the NTN, the UE indicates in the one or more second containers that the feature is not supported.

[0115] In some cases, the UE capability message includes a common container, which indicates a first set of features that the UE supports in the TN and a second set of features that the UE supports in the NTN.

[0116] In some cases, a common set of features in the common container applies by default to both TN and NTN networks, and the common container includes extensions that distinguish features that are supported in only one of the TN or NTN networks.

[0117] In some cases, the UE capability message includes a first container indicating a first feature set that the UE supports in the TN and a first portion of a second feature set that the UE supports in the NTN, and at least a second container indicating a second portion of the second feature set that the UE supports in the NTN.

[0118] In some cases, the second container is restricted to differential UE capabilities compared to the first container.

[0119] In some cases, the second feature set indicates a set of TN and NTN band combinations for which the UE supports at least one of carrier aggregation or dual connectivity.

[0120] In some cases, the UE capability message includes at least one of a container including TN and NTN band combinations for different NTN orbit types, or one or more orbit-specific containers each indicating the TN and NTN band combinations for a corresponding NTN orbit.

[0121] In some cases, the UE capability message implicitly indicates the orbit associated with one of the bands of the band combination via at least one of the bands defined for the NTN per orbit type, a set of band combinations defined per orbit type, or repeating the same band number for different orbit types.

[0122] In some cases, the UE capability message explicitly indicates the trajectory associated with one band of the band combination.

[0123] In some cases, the UE capability message indicates that the UE supports features in the frequency band via at least one of an NTN-specific band definition or an indication of an existing band and NTN support capability for that band.

[0124] In some cases, the second feature set indicates a TN and NTN band combination set for which the UE supports carrier aggregation, and the UE capability message further distinguishes a third feature set that the UE supports in the NTN terrestrial from the second feature set that the UE supports in the NTN, and the third feature set indicates a TN and NTN band combination set for which the UE supports dual connectivity, and the second feature set and the third feature set are included in separate containers in the UE capability message.

[0125] FIG. 19 illustrates a method 1900 for wireless communication by a network entity, such as a source BS (eg, BS 102 of FIGS. 1 and 2 and / or NTN entity 140 of FIG. 4), to communicate UE capability information.

[0126] As shown, method 1900 begins at step 1910 where a network entity sends a request to a user equipment (UE) for capabilities of the UE.

[0127] In step 1920, the network entity receives a UE capabilities message in response to the request that distinguishes feature sets that the UE supports in different network types.

[0128] In some cases, the UE capability message distinguishes a first set of features that the UE supports in a terrestrial network (TN) from a second set of features that the UE supports in a non-terrestrial network (NTN).

[0129] In some cases, the request includes a radio access technology (RAT) type that indicates the NTN as a separate RAT.

[0130] In some cases, the UE capability message distinguishes the feature sets that the UE supports in NTNs with different orbit types.

[0131] In some cases, the different orbit types include two or more of a low Earth orbit (LEO) orbit type, a medium Earth orbit (MEO) orbit type, a highly elliptical orbit (HEO) orbit type, a geostationary orbit (GEO) orbit type, or a non-GEO orbit type.

[0132] In some cases, the UE capability message includes a first container indicating a first set of features supported by the UE in the TN and one or more second containers indicating a second set of features supported by the UE in the NTN.

[0133] In some cases, the one or more second containers include separate containers for NTNs having different trajectory types.

[0134] In some cases, the one or more second containers include a common container that distinguishes feature sets supported by the UE in NTNs having different orbit types.

[0135] In some cases, the common container includes at least one of separate bitmaps indicating different features supported in NTNs of different trajectory types, separate capability fields for different trajectory types, or a combination of at least one structure indicating a common set of features supported in different trajectory types and separate structures indicating different features supported in NTNs of different trajectory types.

[0136] In some cases, the one or more second containers differentiate UE support for features related to at least one of physical layer processing, Packet Data Convergence Protocol (PDCP) processing, Radio Link Control (RLC) processing, mobility, or IP Multimedia Subsystem (IMS) for NTNs having different orbit types.

[0137] In some cases, the first container and one or more second containers indicate common features, and for a feature that is not applicable to the NTN, the UE indicates in the one or more second containers that the feature is not supported.

[0138] In some cases, the UE capability message includes a common container, which indicates a first set of features that the UE supports in the TN and a second set of features that the UE supports in the NTN.

[0139] In some cases, a common set of features in the common container applies by default to both TN and NTN networks, and the common container includes extensions that distinguish features that are supported in only one of the TN or NTN networks.

[0140] In some cases, the UE capability message includes a first container indicating a first feature set that the UE supports in the TN and a first portion of a second feature set that the UE supports in the NTN, and at least a second container indicating a second portion of the second feature set that the UE supports in the NTN.

[0141] In some cases, the second container is restricted to differential UE capabilities compared to the first container.

[0142] In some cases, the second feature set indicates a set of TN and NTN band combinations for which the UE supports at least one of carrier aggregation or dual connectivity.

[0143] In some cases, the UE capability message includes at least one of a container including TN and NTN band combinations for different NTN orbit types, or one or more orbit-specific containers, each indicating the TN and NTN band combinations for a corresponding NTN orbit.

[0144] In some cases, the UE capability message implicitly indicates the orbit associated with one of the bands of the band combination via at least one of the bands defined for the NTN per orbit type, a set of band combinations defined per orbit type, or repeating the same band number for different orbit types.

[0145] In some cases, the UE capability message explicitly indicates the trajectory associated with one band of the band combination.

[0146] In some cases, the UE capability message indicates that the UE supports features in the frequency band via at least one of an NTN-specific band definition or an indication of an existing band and NTN support capability for that band.

[0147] In some cases, the second feature set indicates a TN and NTN band combination set for which the UE supports carrier aggregation, and the UE capability message further distinguishes a third feature set that the UE supports in the NTN terrestrial from the second feature set that the UE supports in the NTN, and the third feature set indicates a TN and NTN band combination set for which the UE supports dual connectivity, and the second feature set and the third feature set are included in separate containers in the UE capability message.

[0148] Aspects Related to Indicating a Subset of UE Capability Information In the case of a handover (HO) of a UE (e.g., UE 604) from a source BS in a network to a target BS in the network, the source base station may need to know the specific UE capabilities related to the target frequency and RAT associated with the target base station. For example, in the case of a handover from NTN to TN (e.g., the UE is handed over from an NTN BS to a TN BS), the NTN BS may need to know the TN capabilities or features (e.g., supported frequency bands, subcarrier spacing, bandwidth, etc.) supported by the UE to determine the appropriate target system, frequency, and measurement configuration. In the case of a HO from NTN to TN, this implies that the NTN BS needs to send a request (e.g., the request received by the UE 604 at 610 in FIG. 6) over the NTN radio for both NTN UE capabilities and TN UE capabilities from the UE. Because the NTN may have a narrow BW (e.g., GEO), requesting both NTN UE capabilities and TN capabilities results in the UE consuming a significant amount of time, frequency, and power resources to transmit the NTN and TN capability information. This problem is generally applicable to any case of mobility from a BS associated with a narrow BW to a BS associated with a wider BW (e.g., mobility from an earlier generation to a later generation).

[0149] Thus, aspects of the present disclosure provide techniques to help avoid situations in which a UE consumes a significant amount of time, frequency, and power resources transmitting UE capability information to a BS associated with a narrow BW. For example, in some cases, such techniques may include only transmitting a partial set of UE capability information, thereby limiting the amount of UE capability information that needs to be transmitted by the UE in, for example, the UE capability message transmitted at 615 of FIG. 6. Thus, by limiting the amount of UE capability information that needs to be transmitted, the UE may not need to spend as much time or power transmitting UE capability information, which can reduce power consumption and save time and frequency resources in the network.

[0150] It should be noted that these techniques may apply to any mobility scenario (e.g., NTN to NTN HO, TN to NTN HO, etc.), as well as non-mobility scenarios such as initial access. For example, during initial access, the network may derive only a minimum set of UE capabilities to save radio resources, or due to which the network may support only features corresponding to a partial set of UE capability information. In any case, the UE capability information may be indicated in two steps, such as a first step in which a partial set of UE capability information is communicated, and a second step in which a complete set of UE capability information is communicated. Furthermore, it should be noted that although the source BS and the target BS may appear as two different entities from the perspective of the UE 604, the source BS and the target BS may be controlled or operated by a single network entity.

[0151] FIG. 20 illustrates a method 2000 for wireless communication by a UE, such as the UE 104 in the wireless communication network 100 of FIG. 1 and / or the UE 604 shown in FIG. 6, to communicate a subset of UE capability information.

[0152] As shown, method 2000 begins at step 2010, where the UE generates a subset of UE capability information. In some cases, the UE capability information in the subset of UE capability information may indicate one or more features or one or more capabilities that the UE supports for communication in a particular network (e.g., a TN and / or NTN), as described above.

[0153] In step 2020, the UE transmits a partial set of UE capability information to a network entity. In some cases, the UE may transmit the partial set of UE capability information in a UE capability message, such as the UE capability message transmitted by the UE 604 in 615 of FIG. 6. Thus, in some cases, the UE may transmit the partial set of UE capability information in a UE capability message using one or more of the structures shown in FIG. 7, FIG. 8A, FIG. 8D, FIG. 9, FIG. 11, FIG. 13-FIG. 15, FIG. 16A-FIG. 16C, or FIG. 17A-FIG. 17D. In such cases, the partial set of UE capability information indicates feature sets that the UE supports in different network types. Furthermore, in some cases, the partial set of UE capability information distinguishes a first feature set that the UE supports in the TN from a second feature set that the UE supports in the NTN.

[0154] In some cases, the subset of UE capability information generated by the UE in block 1802 is related to the mobility of the UE (e.g., handover of the UE from a source BS to a target BS) and includes at least one of one or more supported RATs, one or more supported core network (CN) types, one or more supported frequency bands, one or more supported SCSs, or one or more supported BWs.

[0155] In some cases, the subset of UE capability information generated by the UE in step 2010 includes at least one of: one or more supported measurement capabilities, one or more supported mobility capabilities, one or more supported random access channel (RACH) capabilities (e.g., two-step RACH capabilities).

[0156] In some cases, the subset of UE capability information generated by the UE in block 1802 may include a minimum set of UE capability information that the UE should report (e.g., supported frequency bands, SCS, and BW), as well as an additional set of UE capability information (e.g., supported measurement / mobility capabilities or features).

[0157] In some cases, the UE may receive a trigger indicating whether the UE should generate a subset or a complete set of UE capability information. The trigger may include an explicit trigger or an implicit trigger. For example, in some cases, the UE may receive a request for UE capabilities from a network entity that explicitly indicates that the request is for a subset of UE capability information. In some cases, the network entity may include a base station (e.g., BS 102 shown in Figures 1 and 2) or another UE (e.g., in the case of sidelink communication). In some cases, the request may be received in a UE capability inquiry message (such as the request received by the UE 604 at 610 in Figure 6) or in system information.

[0158] In some cases, for a particular RAT network type (e.g., NTN), the UE may be configured to report a partial set of UE capability information unless a request for UE capabilities indicates that the request is for a complete set of UE capability information. In such a case, not receiving a request for a complete set of UE capability information may implicitly trigger the UE to generate a partial set of UE capability information in block 1802.

[0159] In the case of mobility, after the UE is handed over from the source BS to the target BS, the target BS may subsequently request the UE to send an additional set of UE capability information. For example, in some cases, when handing over the UE to the target BS, the source BS may generate a partial set of UE capability information and send it to the target BS. In some cases, the source BS may indicate to the target BS that the partial set of UE capability information was generated by the source BS. In some cases, the source BS may transmit at least one of the partial set of UE capability information or an indication that the partial set of UE capability information was generated by the source BS via an inter-node message or a network interface (e.g., an X2 interface, an Xn interface, etc.).

[0160] When the UE is subsequently handed over to the target BS, the target BS may request an additional set of UE capability information, for example to supplement the partial set of UE capability information received from the source BS. In some cases, the additional set of UE capability information requested by the target BS may include UE capability information that is not included in the partial set of UE capability information. In other cases, the additional set of UE capability information includes a complete set of UE capability information, including the UE capability information included in the partial set of UE capability information.

[0161] In some cases, the target BS may request an additional (e.g., complete) set of UE capabilities after HO is completed, which may cause unnecessary steps and lead to wasted power consumption and time and frequency resources. Thus, in some cases, to avoid the wasted power consumption and time and frequency resources associated with requesting an additional set of UE capability information after handover is completed, the target BS may instead request the additional set of UE capability information during handover.

[0162] For example, in some cases, the UE may be requested to generate an additional set of UE capability information based on the UE capability request or inquiry. In some cases, the request for the additional set of UE capability information may be included in the handover command received from the source BS, or the request for the additional set of UE capability information may be multiplexed with the handover command received from the source BS. In other cases, the UE may be triggered to generate and send an additional set of UE capabilities implicitly based on the type of handover. For example, when the type of handover includes a handover from an NTN to a TN, the UE may be triggered by default to generate and send an additional (e.g., complete) set of UE capability information after the handover is completed. In this case, the target BS does not need to send a request for additional UE capability information after the handover is completed, thereby saving time, frequency, and power resources.

[0163] In some cases, when a request for additional UE capability information is received during handover, the UE may begin generating a UE capability message containing the additional UE capability information at the time the request is received or after the handover is completed (e.g., after the random access procedure with the target BS is completed).

[0164] In some cases, a handover of a UE from a source BS to a target BS may fail for various reasons. When this occurs, the UE may initiate a radio resource control (RRC) re-establishment procedure. In such a case, a request for additional UE capability information may be sent by the target BS in an RRC message, such as an RRC re-establishment message, an RRC reconfiguration message, or an RRC resume message. In some cases, rather than the target BS sending a request in an RRC message, the UE may be implicitly triggered to generate additional UE capability information based on the type of cell to which the target BS belongs. For example, in some cases, when the handover fails, the UE may determine that the target BS belongs to a TN cell. Thus, in response to determining that the target BS belongs to a TN cell, the UE may be implicitly triggered to generate an additional set of UE capability information.

[0165] In some cases, in the case of an RRCresume procedure, a request for additional UE capability information may be sent in the RRCresume message.

[0166] FIG. 21 illustrates a method 2100 for wireless communication by a network entity, such as a source BS (eg, BS 102 of FIGS. 1 and 2 and / or NTN entity 140 of FIG. 4), to communicate a subset of UE capability information.

[0167] As shown, method 2100 begins at step 2110 where a source BS sends a request to a user equipment (UE) for a subset of UE capability information.

[0168] In step 2120, the source BS receives a partial set of UE capability information from the UE.

[0169] In some cases, the subset of the UE capability information indicates feature sets that the UE supports in different network types.

[0170] In some cases, the subset of UE capability information distinguishes a first set of features that the UE supports in a terrestrial network (TN) from a second set of features that the UE supports in a non-terrestrial network (NTN).

[0171] In some cases, the subset of the UE capability information is related to the mobility of the UE and includes at least one of: one or more supported radio access technologies (RATs), one or more supported core network (CN) types, one or more supported frequency bands, one or more supported subcarrier spacings (SCSs), or one or more supported bandwidths (BWs).

[0172] In some cases, the subset of UE capability information includes at least one of: one or more supported measurement capabilities, one or more supported mobility capabilities, or one or more supported random access channel (RACH) capabilities.

[0173] In some cases, the subset of UE capability information includes a minimum set of UE capability information that the UE should report and an additional set of UE capability information.

[0174] In some cases, the method 2100 further includes sending a handover command to the UE to hand over the UE from the network entity to another network entity, and sending another request to the UE for an additional set of UE capability information.

[0175] In some cases, the other requests are sent within the handover command or are multiplexed and sent along with the handover command.

[0176] FIG. 22 illustrates a method 2200 for wireless communication by a network entity, such as a target BS (eg, BS 102 of FIGS. 1 and 2 and / or NTN entity 140 of FIG. 4), to communicate a subset of UE capability information.

[0177] As shown, method 2200 begins at step 2210 where a target BS obtains a subset of user equipment (UE) capability information associated with the UE.

[0178] In step 2220, the target BS sends a request to the UE for an additional set of UE capability information.

[0179] In some cases, the subset of the UE capability information indicates feature sets that the UE supports in different network types.

[0180] In some cases, the subset of UE capability information distinguishes a first set of features that the UE supports in a terrestrial network (TN) from a second set of features that the UE supports in a non-terrestrial network (NTN).

[0181] In some cases, the subset of the UE capability information is related to the mobility of the UE and includes at least one of: one or more supported Radio Access Technologies (RATs), one or more supported Core Network (CN) types, one or more supported frequency bands, one or more supported Subcarrier Spacings (SCSs), or one or more supported Bandwidths (BWs).

[0182] In some cases, the subset of UE capability information includes at least one of: one or more supported measurement capabilities, one or more supported mobility capabilities, or one or more supported random access channel (RACH) capabilities.

[0183] In some cases, the subset of UE capability information includes a minimum set of UE capability information that the UE should report and an additional set of UE capability information.

[0184] In some cases, the additional set of UE capability information includes UE capability information that is not included in the partial set of UE capability information.

[0185] In some cases, the additional set of UE capability information includes a complete set of UE capability information, including the UE capability information included in the partial set of UE capability information.

[0186] In some cases, the request for an additional set of UE capability information is sent in or multiplexed with the handover command.

[0187] In some cases, the request for the additional set of UE capability information is sent in a Radio Resource Control (RRC) re-establishment message, an RRC reconfiguration message, or an RRC resume message.

[0188] In some cases, the additional set of UE capability information is received after completion of a handover associated with the UE.

[0189] In some cases, a subset of the UE capability information is received from another network entity.

[0190] Exemplary Wireless Communication Device 23 illustrates aspects of an exemplary communications device. In some examples, the communications device ERROR!REFERENCE SOURCE NOT FOUND.00 may be a network entity, such as the BS 102 described with respect to FIGS. 1 and 2, or the NTN entity 140 described with respect to FIG. 4. In some cases, the network entity may include the source BS, and in other cases, the network entity may include the target BS.

[0191] The communications device 2300 includes a processing system 2302 coupled to a transceiver 2308 (e.g., a transmitter and / or receiver). The transceiver 2308 is configured to transmit and receive signals for the communications device 2300 via an antenna 2310, such as various signals as described herein. The processing system 2302 may be configured to perform processing functions for the communications device 2300, including processing signals received by the communications device 2300 and / or signals to be transmitted.

[0192] The processing system 2302 includes one or more processors 2320. In various aspects, the one or more processors 2320 may represent one or more of the receive processor 238, the transmit processor 220, the TX MIMO processor 230, and / or the controller / processor 240, as described with respect to FIG. 2. The one or more processors 2320 are coupled to a computer-readable medium / memory 2330 via a bus 2306. In certain aspects, the computer-readable medium / memory 2330 is configured to store instructions (e.g., computer-executable code) that, when executed by the one or more processors 2320, cause the one or more processors 2320 to perform one or more of the operations shown in FIG. 6 and the methods 1800 and 2000 described with respect to FIG. 19, FIG. 21, or FIG. 22, or any aspects related thereto. It should be noted that a reference to a processor of the communications device 2300 performing a function may include one or more processors of the communications device 2300 performing that function.

[0193] In the shown example, computer readable medium / memory 2330 stores code (e.g., executable instructions) for transmitting 2331, code for receiving 2332, and code for obtaining 2333. Processing of codes 2331-2333 may cause communications device 2300 to perform one or more of the operations shown in Figure 6 and methods 1800 and 2000 described with respect to Figures 19, 21, or 22, or any aspect related thereto.

[0194] The one or more processors 2320 include circuits configured to implement (e.g., execute) code stored in the computer-readable medium / memory 2430, including a circuit 2321 for transmitting, a circuit 2322 for receiving, and a circuit 2323 for acquiring. Processing using the circuits 2321-2323 may cause the communications device 2300 to perform one or more of the operations shown in Figure 6 and the methods 1800 and 2000 described with respect to Figures 19, 21, or 22, or any aspect related thereto.

[0195] Various components of the communications device 2400 may provide means for performing one or more of the operations illustrated in Figure 6 and the methods 1800 and 2000 described with respect to Figures 19, 21, or 22, or any aspects related thereto. The means for transmitting, sending, or outputting for transmission may include the transceiver 232 and / or antenna(s) 234 of the BS 102 illustrated in Figure 2, and / or the transceiver 2308 and antenna 2310 of the communications device 2300 in Figure 23. The means for receiving or obtaining may include the transceiver 232 and / or antenna(s) 234 of the BS 102 illustrated in Figure 2, and / or the transceiver 2308 and antenna 2310 of the communications device 2300 in Figure 23.

[0196] 24 illustrates an aspect of an example communications device 2400. In some aspects, the communications device 2400 is user equipment, such as the UE 104 described with respect to FIGS.

[0197] The communications device 2400 includes a processing system 2402 coupled to a transceiver 2408 (e.g., a transmitter and / or receiver). The transceiver 2408 is configured to transmit and receive signals for the communications device 2400 via an antenna 2410, such as various signals as described herein. The processing system 2402 may be configured to perform processing functions for the communications device 2400, including processing signals received by the communications device 2400 and / or signals to be transmitted.

[0198] The processing system 2402 includes one or more processors 2420. In various aspects, the one or more processors 2420 may represent one or more of the receive processor 258, the transmit processor 264, the TX MIMO processor 266, and / or the controller / processor 280 as described with respect to FIG. 2. The one or more processors 2420 are coupled to a computer-readable medium / memory 2430 via a bus 2406. In certain aspects, the computer-readable medium / memory 2430 is configured to store instructions (e.g., computer executable code) that, when executed by the one or more processors 2420, cause the one or more processors 2420 to perform one or more of the operations illustrated in FIG. 6, as well as the methods 1800 and 2000 described with respect to FIG. 18 or FIG. 20, or any aspects related thereto. It should be noted that a reference to a processor performing a function of the communications device 2400 may include one or more processors performing that function of the communications device 2400.

[0199] In the shown example, computer readable medium / memory 2430 stores code (e.g., executable instructions) for receiving 2431 and code for transmitting 2432. Processing of codes 2431-2432 may cause communications device 2400 to perform one or more of the operations shown in Figure 6 and methods 1800 and 2000 described with respect to Figures 18 or 20, or any aspect related thereto.

[0200] The one or more processors 2420 include circuitry configured to implement (e.g., execute) code stored in a computer-readable medium / memory 2430, including a circuitry 2421 for receiving and a circuitry 2422 for transmitting. Processing using the circuits 2421-2422 may cause the communications device 2400 to perform one or more of the operations shown in Figure 6 and the methods 1800 and 2000 described with respect to Figures 18 or 20, or any aspect related thereto.

[0201] Various components of the communications device 2400 may provide means for performing one or more of the operations shown in Figure 6 and the methods 1800 and 2000 described with respect to Figure 18 or Figure 20, or any aspects related thereto. For example, the means for transmitting, the means for sending, or the means for outputting for transmission may include the transceiver 254 and / or the antenna(s) 252 of the UE 104 shown in Figure 2, and / or the transceiver 2408 and the antenna 2410 of the communications device 2400 in Figure 24. The means for receiving or the means for obtaining may include the transceiver 254 and / or the antenna(s) 252 of the UE 104 illustrated in Figure 2, and / or the transceiver 2408 and the antenna 2410 of the communications device 2400 in Figure 24.

[0202] Illustrative clauses The following numbered clauses describe example implementations.

[0203] Clause 1: A method for wireless communication by a user equipment (UE), comprising: receiving a request from a network entity for capabilities of the UE; and, in response to the request, transmitting a UE capabilities message that distinguishes feature sets supported by the UE in different network types.

[0204] Clause 2: The method of clause 1, wherein the UE capability message distinguishes a first set of features supported by the UE in a terrestrial network (TN) from a second set of features supported by the UE in a non-terrestrial network (NTN).

[0205] Clause 3: The method of clause 2, wherein the request includes a radio access technology (RAT) type that indicates the NTN as a separate RAT.

[0206] Clause 4: The method of clause 2 or 3, wherein the UE capability message distinguishes feature sets supported by the UE in NTNs having different orbit types.

[0207] Clause 5: The method of clause 4, wherein the different orbit types include two or more of a low Earth orbit (LEO) orbit type, a medium Earth orbit (MEO) orbit type, a highly elliptical orbit (HEO) orbit type, a geostationary orbit (GEO) orbit type, or a non-GEO orbit type.

[0208] Clause 6: The method described in clause 4 or 5, wherein the UE capability message includes a first container indicating a first set of features supported by the UE in the TN and one or more second containers indicating a second set of features supported by the UE in the NTN.

[0209] Clause 7: The method of clause 6, wherein the one or more second containers include separate containers for NTNs having different trajectory types.

[0210] Clause 8: The method of clause 6, wherein the one or more second containers include a common container that distinguishes feature sets supported by the UE in NTNs having different orbit types.

[0211] Clause 9: The common container includes at least one of separate bitmaps indicating different features supported in NTNs of different trajectory types, separate capability fields for different trajectory types, or a combination of at least one structure indicating a common set of features supported in different trajectory types and separate structures indicating different features supported in NTNs of different trajectory types; The method described in clause 8.

[0212] Clause 10: A method according to any one of clauses 6 to 9, wherein the one or more second containers differentiate UE support for features relating to at least one of physical layer processing, Packet Data Convergence Protocol (PDCP) processing, Radio Link Control (RLC) processing, mobility, or IP Multimedia Subsystem (IMS) for NTNs having different orbit types.

[0213] Clause 11: The method of clause 10, wherein the first container and one or more second containers indicate common features, and for a feature that is not applicable to the NTN, the UE indicates in the one or more second containers that the feature is not supported.

[0214] Clause 12: A method according to any one of clauses 2 to 5, wherein the UE capability message includes a common container, the common container indicating a first set of features supported by the UE in the TN and a second set of features supported by the UE in the NTN.

[0215] Clause 13: The method of clause 12, wherein the common set of features in the common container applies by default to both TN and NTN networks, and the common container includes extensions that distinguish features that are supported in only one of the TN or NTN.

[0216] Clause 14: A method according to any one of clauses 2 to 5, wherein the UE capability message includes a first container indicating a first feature set supported by the UE in the TN and a first part of a second feature set supported by the UE in the NTN, and at least a second container indicating a second part of the second feature set supported by the UE in the NTN.

[0217] Clause 15: The method of clause 14, wherein the second container is restricted to differential UE capabilities compared to the first container.

[0218] Clause 16: The method of any one of clauses 2 to 5, wherein the second feature set indicates a TN and NTN band combination set for which the UE supports at least one of carrier aggregation or dual connectivity.

[0219] Clause 17: The method described in clause 16, wherein the UE capability message includes at least one of a container including TN and NTN band combinations for different NTN orbit types, or one or more orbit-specific containers each indicating TN and NTN band combinations for a corresponding NTN orbit.

[0220] Clause 18. The method according to clause 16 or 17, wherein the UE capability message implicitly indicates the orbit associated with one band of the band combination via at least one of the bands defined for the NTN per orbit type, a set of band combinations defined per orbit type, or repeating the same band number for different orbit types.

[0221] Clause 19: The method according to clause 16 or 17, wherein the UE capability message explicitly indicates an orbit associated with one band of the band combination.

[0222] Clause 20: The method described in clause 16 or 17, wherein the UE capability message indicates that the UE supports a feature in the frequency band via at least one of an NTN-specific band definition or an indication of an existing band and NTN support capability for that band.

[0223] Clause 21: The method of any one of clauses 2 to 5, wherein the second feature set indicates a TN and NTN band combination set for which the UE supports carrier aggregation, the UE capability message further distinguishes a third feature set supported by the UE on NTN terrestrial from the second feature set supported by the UE on NTN, the third feature set indicates a TN and NTN band combination set for which the UE supports dual connectivity, and the second feature set and the third feature set are included in separate containers in the UE capability message.

[0224] Clause 22: A method for wireless communication by a network entity, comprising: sending a request to a user equipment (UE) for UE capabilities; and receiving, in response to the request, a UE capabilities message that distinguishes feature sets supported by the UE in different network types.

[0225] Clause 23: The method of clause 22, wherein the UE capability message distinguishes a first set of features supported by the UE in a terrestrial network (TN) from a second set of features supported by the UE in a non-terrestrial network (NTN).

[0226] Clause 24: The method of clause 23, wherein the request includes a radio access technology (RAT) type indicating the NTN as a separate RAT.

[0227] Clause 25: The method according to clause 23 or 24, wherein the UE capability message distinguishes feature sets supported by the UE in NTNs having different orbit types.

[0228] Clause 26: The method of clause 25, wherein the different orbit types include two or more of a low Earth orbit (LEO) orbit type, a medium Earth orbit (MEO) orbit type, a highly elliptical orbit (HEO) orbit type, a geostationary orbit (GEO) orbit type, or a non-GEO orbit type.

[0229] Clause 27: The method described in clause 25 or 26, wherein the UE capability message includes a first container indicating a first set of features supported by the UE in the TN and one or more second containers indicating a second set of features supported by the UE in the NTN.

[0230] Clause 28: The method of clause 27, wherein the one or more second containers include separate containers for NTNs having different trajectory types.

[0231] Clause 29: The method of clause 27, wherein the one or more second containers include a common container that distinguishes feature sets supported by the UE in NTNs having different orbit types.

[0232] Clause 30: The common container includes at least one of separate bitmaps indicating different features supported in NTNs of different trajectory types, separate capability fields for different trajectory types, or a combination of at least one structure indicating a common set of features supported in different trajectory types and separate structures indicating different features supported in NTNs of different trajectory types; The method described in clause 29.

[0233] Clause 31: A method according to any one of clauses 27 to 30, wherein the one or more second containers differentiate UE support for features relating to at least one of the following: physical layer processing, Packet Data Convergence Protocol (PDCP) processing, Radio Link Control (RLC) processing, mobility, or IP Multimedia Subsystem (IMS) for NTNs having different orbit types.

[0234] Clause 32: The method of clause 31, wherein the first container and one or more second containers indicate common features, and for a feature that is not applicable to the NTN, the UE indicates in the one or more second containers that the feature is not supported.

[0235] Clause 33: The method of clause 23, wherein the UE capability message includes a common container, the common container indicating a first set of features supported by the UE in the TN and a second set of features supported by the UE in the NTN.

[0236] Clause 34: The method of clause 33, wherein the common set of features in the common container applies by default to both TN and NTN networks, and the common container includes extensions that distinguish features that are supported in only one of the TN or NTN networks.

[0237] Clause 35: The method described in clause 23, wherein the UE capability message includes a first container indicating a first feature set supported by the UE in the TN and a first part of a second feature set supported by the UE in the NTN, and at least a second container indicating a second part of the second feature set supported by the UE in the NTN.

[0238] Clause 36: The method of clause 35, wherein the second container is restricted to differential UE capabilities compared to the first container.

[0239] Clause 37: The method of clause 23, wherein the second set of features indicates a set of TN and NTN band combinations for which the UE supports at least one of carrier aggregation or dual connectivity.

[0240] Clause 38: The method described in clause 37, wherein the UE capability message includes at least one of a container including TN and NTN band combinations for different NTN orbit types, or one or more orbit-specific containers each indicating TN and NTN band combinations for a corresponding NTN orbit.

[0241] Clause 39: The method according to clause 37 or 38, wherein the UE capability message implicitly indicates the orbit associated with one band of the band combination via at least one of the bands defined for the NTN per orbit type, a set of band combinations defined per orbit type, or repeating the same band number for different orbit types.

[0242] Clause 40: The method according to clause 37 or 38, wherein the UE capability message explicitly indicates an orbit associated with one band of the band combination.

[0243] Clause 41: A method according to any one of clauses 37 to 40, wherein the UE capability message indicates that the UE supports a feature in the frequency band via at least one of an NTN-specific band definition, or an indication of an existing band and NTN support capability for that band.

[0244] Clause 42: The method described in Clause 23, wherein the second feature set indicates a TN and NTN band combination set for which the UE supports carrier aggregation, the UE capability message further distinguishes a third feature set supported by the UE on NTN terrestrial from the second feature set supported by the UE in the NTN, the third feature set indicates a TN and NTN band combination set for which the UE supports dual connectivity, and the second feature set and the third feature set are included in separate containers in the UE capability message.

[0245] Clause 43: A method for wireless communication by a user equipment (UE), comprising: generating a subset of UE capability information; and transmitting the subset of UE capability information to a network entity.

[0246] Clause 44: The method according to clause 43, wherein the subset of UE capability information indicates feature sets supported by the UE in different network types.

[0247] Clause 45: The method of clause 44, wherein the subset of UE capability information distinguishes a first set of features supported by the UE in a terrestrial network (TN) from a second set of features supported by the UE in a non-terrestrial network (NTN).

[0248] Clause 46: A method according to any one of clauses 43 to 45, wherein the subset of UE capability information is related to the mobility of the UE and includes at least one of: one or more supported Radio Access Technologies (RATs), one or more supported Core Network (CN) types, one or more supported frequency bands, one or more supported Subcarrier Spacings (SCSs), or one or more supported Bandwidths (BWs).

[0249] Clause 47: A method according to any one of clauses 43 to 46, wherein the subset of UE capability information includes at least one of: one or more supported measurement capabilities, one or more supported mobility capabilities, or one or more supported Random Access Channel (RACH) capabilities.

[0250] Clause 48: The method according to any one of clauses 43 to 47, wherein the partial set of UE capability information includes a minimum set of UE capability information that the UE should report and an additional set of UE capability information.

[0251] Clause 49: The method of any one of clauses 43 to 48, further comprising receiving a request for capabilities of the UE from a network entity, the request indicating that the request is for a subset of the UE capability information.

[0252] Clause 50: A method according to any one of clauses 43 to 49, wherein for a particular Radio Access Technology (RAT) network type, the UE is configured to report a partial set of UE capability information unless a request for UE capabilities indicates that the request is for a complete set of UE capability information.

[0253] Clause 51: The method of any one of clauses 43 to 50, further comprising receiving a request from a network entity for an additional set of UE capability information.

[0254] Clause 52: The method of clause 51, wherein the additional set of UE capability information includes UE capability information not included in the partial set of UE capability information.

[0255] Clause 53: The method of clause 51, wherein the additional set of UE capability information comprises a complete set of UE capability information including the UE capability information included in the partial set of UE capability information.

[0256] Clause 54: The method according to any one of clauses 51 to 53, wherein the UE generates at least an additional set of UE capability information after receiving a request from the network entity.

[0257] Clause 55: A method as described in clause 54, wherein the request is received in the handover command or multiplexed with the handover command.

[0258] Clause 56: The method according to clause 54 or 55, wherein the UE generates an additional set of UE capability information based on the type of network to which the target cell belongs.

[0259] Clause 57: The method according to any one of clauses 54 to 56, wherein the request is received in a Radio Resource Control (RRC) re-establishment message, an RRC reconfiguration message, or an RRC resumption message.

[0260] Clause 58: The method according to any one of clauses 51 to 57, wherein the UE generates an additional set of UE capability information after completion of the handover.

[0261] Clause 59: A method for wireless communication by a network entity, the method comprising: sending a request to a user equipment (UE) for a subset of UE capability information; and receiving the subset of UE capability information from the UE.

[0262] Clause 60: The method according to clause 59, wherein the subset of UE capability information indicates feature sets supported by the UE in different network types.

[0263] Clause 61: The method of clause 60, wherein the subset of UE capability information distinguishes a first set of features supported by the UE in a terrestrial network (TN) from a second set of features supported by the UE in a non-terrestrial network (NTN).

[0264] Clause 62: A method according to any one of clauses 59 to 61, wherein the subset of UE capability information is related to the mobility of the UE and includes at least one of: one or more supported Radio Access Technologies (RATs), one or more supported Core Network (CN) types, one or more supported frequency bands, one or more supported Subcarrier Spacings (SCSs), or one or more supported Bandwidths (BWs).

[0265] Clause 63: A method according to any one of clauses 59 to 62, wherein the subset of UE capability information includes at least one of: one or more supported measurement capabilities, one or more supported mobility capabilities, or one or more supported Random Access Channel (RACH) capabilities.

[0266] Clause 64: The method according to any one of clauses 59 to 63, wherein the partial set of UE capability information includes a minimum set of UE capability information that the UE should report and an additional set of UE capability information.

[0267] Clause 65: The method of any one of clauses 59 to 64, further comprising: sending a handover command to the UE for handing over the UE from the network entity to another network entity; and sending another request to the UE for an additional set of UE capability information.

[0268] Clause 66: A method according to clause 65, wherein the other request is sent within the handover command or multiplexed with and sent together with the handover command.

[0269] Clause 67: A method for wireless communication by a network entity, the method comprising: obtaining a subset of UE capability information associated with a user equipment (UE); and sending a request to the UE for an additional set of UE capability information.

[0270] Clause 68: The method according to clause 67, wherein the subset of the UE capability information indicates feature sets supported by the UE in different network types.

[0271] Clause 69: The method of clause 68, wherein the subset of UE capability information distinguishes a first set of features supported by the UE in a terrestrial network (TN) from a second set of features supported by the UE in a non-terrestrial network (NTN).

[0272] Clause 70: A method according to any one of clauses 67 to 69, wherein the subset of UE capability information is related to the mobility of the UE and includes at least one of: one or more supported Radio Access Technologies (RATs), one or more supported Core Network (CN) types, one or more supported frequency bands, one or more supported Subcarrier Spacings (SCSs), or one or more supported Bandwidths (BWs).

[0273] Clause 71: A method according to any one of clauses 67 to 70, wherein the subset of UE capability information includes at least one of: one or more supported measurement capabilities, one or more supported mobility capabilities, or one or more supported Random Access Channel (RACH) capabilities.

[0274] Clause 72: The method according to any one of clauses 67 to 71, wherein the partial set of UE capability information includes a minimum set of UE capability information that the UE should report and an additional set of UE capability information.

[0275] Clause 73: The method according to any one of clauses 67 to 72, wherein the additional set of UE capability information includes UE capability information not included in the partial set of UE capability information.

[0276] Clause 74: The method according to any one of clauses 67 to 72, wherein the additional set of UE capability information comprises a complete set of UE capability information including the UE capability information included in the partial set of UE capability information.

[0277] Clause 75: The method according to any one of clauses 67 to 74, wherein the request for the additional set of UE capability information is sent in the handover command or multiplexed with the handover command.

[0278] Clause 76: The method according to any one of clauses 67 to 75, wherein the request for the additional set of UE capability information is sent in a Radio Resource Control (RRC) re-establishment message, an RRC reconfiguration message, or an RRC resume message.

[0279] Clause 77: The method according to any one of clauses 67 to 76, wherein an additional set of UE capability information is received after completion of a handover associated with the UE.

[0280] Clause 78: The method according to any one of clauses 67 to 77, wherein the partial set of UE capability information is received from another network entity.

[0281] Clause 79: An apparatus comprising a memory having executable instructions and one or more processors, the one or more processors configured to execute the executable instructions to cause the apparatus to perform a method according to any one of clauses 1 to 78.

[0282] Clause 80: An apparatus comprising means for carrying out the method according to any one of clauses 1 to 78.

[0283] Clause 81: A non-transitory computer-readable medium comprising executable instructions that, when executed by one or more processors of a device, cause the device to perform a method according to any one of clauses 1 to 78.

[0284] Clause 82: A computer program product embodied on a computer-readable storage medium comprising code for performing the method according to any one of clauses 1 to 78.

[0285] Additional Wireless Communication Network Considerations The techniques and methods described herein may be used for a variety of wireless communication networks. Although aspects may be described herein using terminology commonly associated with 3G, 4G, and / or 5G wireless technology, aspects of the present disclosure may be applicable to other communication systems and standards not explicitly mentioned herein.

[0286] Returning to FIG. 1, various aspects of the disclosure may be implemented within an exemplary wireless communication network 100.

[0287] 1 illustrates various exemplary UEs 104, which may include, more generally, a cellular phone, a smartphone, a session initiation protocol (SIP) phone, a laptop, a personal digital assistant (PDA), a satellite radio, a global positioning system, a multimedia device, a video device, a digital audio player, a camera, a game console, a tablet, a smart device, a wearable device, a vehicle, an electric meter, a gas pump, a large or small kitchen appliance, a healthcare device, an implant, a sensor / actuator, a display, an Internet of Things (IoT) device, an always on (AON) device, an edge processing device, or other similar devices. The UEs 104 may also be referred to more generally as a mobile device, a wireless device, a wireless communication device, a station, a mobile station, a subscriber station, a mobile subscriber station, a mobile unit, a subscriber unit, a wireless unit, a remote unit, a remote device, an access terminal, a mobile terminal, a wireless terminal, a remote terminal, a handset, etc.

[0288] 1 illustrates various exemplary BSs 102, which may more generally include a NodeB, an enhanced NodeB (eNB), a next generation enhanced NodeB (ng-eNB), a next generation NodeB (gNB or gNodeB), an access point, a base transceiver station, a radio base station, a radio transceiver, a transceiver function, a transmission / reception point, etc. Each of the BSs 102 may provide communication coverage in a respective geographic coverage area 110, which may sometimes be referred to as a cell and may overlap in some cases (e.g., a small cell 102′ may have a coverage area 110′ that overlaps with a macro cell's coverage area 110). A BS may provide communication coverage for, for example, a macrocell (covering a relatively large geographic area), a picocell (covering a relatively smaller geographic area, such as a sports stadium), a femtocell (covering a relatively smaller geographic area (e.g., a home)), and / or other types of cell.

[0289] Although the BS 102 is shown in various aspects as a unified communications device, the BS 102 may be implemented in various configurations. For example, one or more components of a base station may be distributed, including a central unit (CU), one or more distributed units (DU), one or more radio units (RU), a radio unit (RU), a Near-Real Time (Near-RT) RAN Intelligent Controller (RIC), or a Non-Real Time (Non-RT) RIC, to name a few. In another example, various aspects of a base station may be virtualized. More generally, a base station (e.g., the BS 102) may include components located at a single physical location or components located at various physical locations. In examples where a base station includes components located at various physical locations, the various components may each perform functions such that the various components collectively achieve similar functionality as a base station located at a single physical location. In some cases, base stations including components located in various physical locations may be referred to as a disaggregated radio access network architecture, such as an Open RAN (O-RAN) or Virtualized RAN (VRAN) architecture.

[0290] Different BSs 102 in the wireless communication network 100 may also be configured to support different radio access technologies, such as 3G, 4G, and 5G. For example, a BS 102 configured for 4G LTE (collectively referred to as Evolved Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access Network (E-UTRAN)) may interface with the EPC 160 through a first backhaul link 132 (e.g., an S1 interface). A BS 102 configured for 5G (e.g., 5G NR or Next Generation RAN (NG-RAN)) may interface with the 5GC 190 through a second backhaul link 184. The BSs 102 may communicate with each other directly or indirectly (e.g., through the EPC 160 or the 5GC 190) through a third backhaul link 134 (e.g., an X2 interface), which may be wired or wireless.

[0291] The wireless communications network 100 may subdivide the electromagnetic spectrum into various classes, bands, channels, or other characteristics. In some aspects, the subdivision is provided based on wavelength and frequency, where the frequency may also be referred to as a carrier, subcarrier, frequency channel, tone, or subband. For example, 3GPP currently defines Frequency Range 1 (FR1) as including 600 MHz to 6 GHz, which is often (interchangeably) referred to as "sub-6 GHz." Similarly, 3GPP currently defines Frequency Range 2 (FR2) as including 26 to 41 GHz, which is sometimes (interchangeably) referred to as "millimeter wave" ("mmW" or "mmWave"). A base station (e.g., mmWave base station such as BS 180) configured to communicate using mmWave / near-mmWave radio frequency bands may utilize beamforming (e.g., 182) with UEs (e.g., 104) to improve path loss and range.

[0292] The communication link 120 between the BS 102 and, for example, the UE 104 may pass one or more carriers that may have different bandwidths (e.g., 5, 10, 15, 20, 100, 400, and other MHz) and may be aggregated in various manners. The carriers may or may not be adjacent to each other. The allocation of carriers may be asymmetric for DL ​​and UL (e.g., more or fewer carriers may be allocated for DL ​​than UL).

[0293] The wireless communication network 100 further includes a Wi-Fi AP 150 in communication with a Wi-Fi station (STA) 152 via a communication link 154, for example, in the 2.4 GHz and / or 5 GHz unlicensed frequency spectrum.

[0294] Particular UEs 104 may communicate with each other using device-to-device (D2D) communication links 158. The D2D communication links 158 may use one or more sidelink channels, such as a physical sidelink broadcast channel (PSBCH), a physical sidelink discovery channel (PSDCH), a physical sidelink shared channel (PSSCH), and a physical sidelink control channel (PSCCH).

[0295] The EPC 160 may include various functional components, including, in the illustrated example, a Mobility Management Entity (MME) 162, other MMEs 164, a Serving Gateway 166, a Multimedia Broadcast Multicast Service (MBMS) Gateway 168, a Broadcast Multicast Service Center (BM-SC) 170, and a Packet Data Network (PDN) Gateway 172. The MME 162 may be in communication with a Home Subscriber Server (HSS) 174. The MME 162 is a control node that handles signaling between the UE 104 and the EPC 160. In general, the MME 162 provides bearer and connection management.

[0296] Generally, all user Internet protocol (IP) packets are forwarded through the Serving Gateway 166, which itself is connected to the PDN Gateway 172. The PDN Gateway 172 provides UE IP address allocation as well as other functions. The PDN Gateway 172 and the BM-SC 170 are connected to IP Services 176, which may include, for example, the Internet, an Intranet, IP Multimedia Subsystem (IMS), Packet Switched (PS) streaming services, and / or other IP services.

[0297] The BM-SC 170 may provide functionality for MBMS user service provisioning and delivery. The BM-SC 170 may act as an entry point for content provider MBMS transmissions, may be used to authorize and initiate MBMS bearer services in the public land mobile network (PLMN), and may be used to schedule MBMS transmissions. The MBMS Gateway 168 may be used to deliver MBMS traffic to BSs 102 that belong to a Multicast Broadcast Single Frequency Network (MBSFN) area broadcasting a particular service, and may be responsible for session management (start / stop) and collecting eMBMS related charging information.

[0298] The 5GC 190 may include various functional components, including an Access and Mobility Management Function (AMF) 192, other AMFs 193, a Session Management Function (SMF) 194, and a User Plane Function (UPF) 195. The AMF 192 may communicate with a Unified Data Management (UDM) 196.

[0299] The AMF 192 is a control node that handles signaling between the UE 104 and the 5GC 190. The AMF 192 provides, for example, quality of service (QoS), flow and session management.

[0300] Internet Protocol (IP) packets are forwarded through UPF 195, which connects to IP services 197 and provides UE IP address allocation as well as other functions for 5GC 190. IP services 197 may include, for example, Internet, Intranet, IMS, PS streaming services, and / or other IP services.

[0301] Returning to FIG. 2, various example components of the BS 102 and UE 104 that may be used to implement aspects of the present disclosure are shown.

[0302] For an exemplary downlink transmission example, the BS 102 includes a transmit processor 220 that may receive data from a data source 212 and control information from a controller / processor 240. The control information may be for a physical broadcast channel (PBCH), a physical control format indicator channel (PCFICH), a physical HARQ indicator channel (PHICH), a physical downlink control channel (PDCCH), a group common PDCCH (GC PDCCH), etc. In some examples, the data may be for a physical downlink shared channel (PDSCH), etc.

[0303] The transmit processor 220 may process (e.g., encode and symbol map) the data and control information to obtain data symbols and control symbols, respectively. The transmit processor 220 may also generate reference symbols, such as for a primary synchronization signal (PSS), a secondary synchronization signal (SSS), a PBCH demodulation reference signal (DMRS), and a channel state information reference signal (CSI-RS).

[0304] The transmit (TX) multiple-input multiple-output (MIMO) processor 230 may perform spatial processing (e.g., precoding) on ​​the data symbols, control symbols, and / or reference symbols, if applicable, and may provide output symbol streams to modulators (MODs) in transceivers 232a-t. Each modulator in transceivers 232a-t may process a respective output symbol stream to obtain an output sample stream. Each modulator may further process (e.g., convert to analog, amplify, filter, and upconvert) the output sample stream to obtain a downlink signal. The downlink signals from the modulators in transceivers 232a-t may be transmitted via antennas 234a-t, respectively.

[0305] To receive downlink transmissions, the UE 104 may include antennas 252a-252r, which may receive downlink signals from the BS 102 and provide received signals to demodulators (DEMODs) 254a-254r, respectively, within the transceivers. Each demodulator within the transceivers 254a-254r may condition (e.g., filter, amplify, downconvert, and digitize) a respective received signal to obtain input samples. Each demodulator may further process the input samples to obtain received symbols.

[0306] A MIMO detector 256 may obtain received symbols from all demodulators in transceivers 254a-254r, perform MIMO detection on the received symbols if applicable, and provide detected symbols. A receive processor 258 may process (e.g., demodulate, deinterleave, and decode) the detected symbols and provide decoded data for the UE 104 to a data sink 260 and provide decoded control information to the controller / processor 280.

[0307] For an example uplink transmission, the UE 104 further includes a transmit processor 264 that may receive and process data (e.g., for a PUSCH) from a data source 262 and control information (e.g., for a physical uplink control channel (PUCCH)) from a controller / processor 280. The transmit processor 264 may also generate reference symbols for a reference signal (e.g., for a sounding reference signal (SRS)). The symbols from the transmit processor 264 may be precoded by a TX MIMO processor 266, if applicable, further processed by a modulator in the transceivers 254a-254r (e.g., for SC-FDM, etc.), and transmitted to the BS 102.

[0308] At the BS 102, the uplink signals from the UE 104 may be received by antennas 234a-t, processed by demodulators in transceivers 232a-t, detected by a MIMO detector 236 if applicable, and further processed by a receive processor 238 to obtain decoded data and control information sent by the UE 104. The receive processor 238 may provide the decoded data to a data sink 239 and the decoded control information to a controller / processor 240.

[0309] Memories 242 and 282 may store data and program codes for BS 102 and UE 104, respectively.

[0310] A scheduler 244 may schedule UEs for data transmission on the downlink and / or uplink.

[0311] In various aspects, the BS 102 may be described as transmitting and receiving various types of data associated with the methods described herein. In these contexts, "transmitting" may refer to various mechanisms for outputting data, such as outputting data from the data source 212, the scheduler 244, the memory 242, the transmit processor 220, the controller / processor 240, the TX MIMO processor 230, the transceivers 232a-t, the antennas 234a-t, and / or other aspects described herein. Similarly, "receiving" may refer to various mechanisms for obtaining data, such as obtaining data from the antennas 234a-t, the transceivers 232a-t, the RX MIMO detector 236, the controller / processor 240, the receive processor 238, the scheduler 244, the memory 242, and other aspects described herein.

[0312] In various aspects, the UE 104 may similarly be described as transmitting and receiving various types of data associated with the methods described herein. In these contexts, "transmitting" may refer to various mechanisms for outputting data, such as outputting data from the data source 262, memory 282, transmit processor 264, controller / processor 280, TX MIMO processor 266, transceivers 254a-t, antennas 252a-t, and / or other aspects described herein. Similarly, "receiving" may refer to various mechanisms for obtaining data, such as obtaining data from the antennas 252a-t, transceivers 254a-t, RX MIMO detector 256, controller / processor 280, receive processor 258, memory 282, and other aspects described herein.

[0313] In some aspects, the processor may be configured to perform various operations, such as those associated with the methods described herein, to transmit (output) data to or receive (obtain) data from another interface configured to transmit or receive data, respectively.

[0314] As mentioned above, FIGS. 3A, 3B, 3C, and 3D illustrate various example aspects of data structures that may be used in the wireless communication network 100 of FIG.

[0315] A wireless communication system may utilize orthogonal frequency division multiplexing (OFDM) with cyclic prefix (CP) on the uplink and downlink. Such a system may also support half-duplex operation using time division duplexing (TDD). OFDM and single-carrier frequency division multiplexing (SC-FDM) partition the system bandwidth into multiple orthogonal subcarriers (e.g., as shown in FIGS. 3B and 3D). Each subcarrier may be modulated with data. Modulation symbols may be sent in the frequency domain with OFDM and in the time domain with SC-FDM.

[0316] The wireless communication frame structure may be frequency division duplex (FDD) where, for a particular set of subcarriers, subframes within the set of subcarriers are dedicated for either DL or UL. The wireless communication frame structure may also be time division duplex (TDD) where, for a particular set of subcarriers, subframes within the set of subcarriers are dedicated for both DL and UL.

[0317] In Figures 3A and 3C, the wireless communication frame structure is TDD, where D is DL, U is UL, and X is flexible for use between DL / UL. The UE may be configured with the slot format through a received slot format indicator (SFI) (dynamically through DL control information (DCI) or semi-statically / statically through radio resource control (RRC) signaling). In the example shown, a 10 ms frame is divided into ten equally sized 1 ms subframes. Each subframe may include one or more time slots. In some examples, each slot may include 7 or 14 symbols depending on the slot configuration. A subframe may also include a minislot, which generally has fewer symbols than an entire slot. Other wireless communication technologies may have different frame structures and / or different channels.

[0318] In general, the number of slots in a subframe is based on the slot configuration and numerology. For slot configuration 0, the different numerologies (μ) 0-5 allow 1, 2, 4, 8, 16, and 32 slots per subframe, respectively. For slot configuration 1, the different numerologies 0-2 allow 2, 4, and 8 slots per subframe, respectively. Thus, for slot configuration 0 and numerology μ, there are 14 symbols / slot and 2μ slots / subframe. Subcarrier spacing and symbol length / duration are functions of numerology. Subcarrier spacing is 2 μ×15 kHz, where μ is the numerology 0-5. Thus, numerology μ=0 has a subcarrier spacing of 15 kHz, and numerology μ=5 has a subcarrier spacing of 480 kHz. The symbol length / duration is inversely proportional to the subcarrier spacing. Figures 3A, 3B, 3C, and 3D provide an example of slot configuration 0 with 14 symbols per slot and numerology μ=2 with 4 slots per subframe. The slot duration is 0.25 ms, the subcarrier spacing is 60 kHz, and the symbol duration is approximately 16.67 μs.

[0319] A resource grid may be used to represent the frame structure, as shown in Figures 3A, 3B, 3C, and 3D. Each time slot includes a resource block (RB) (also called physical RB (PRB)), which spans 12 consecutive subcarriers. The resource grid is divided into multiple resource elements (REs). The number of bits carried by each RE depends on the modulation scheme.

[0320] As shown in Figure 3A, some of the REs carry reference (pilot) signals (RS) for UEs (e.g., UE 104 in Figures 1 and 2). The RS may include demodulation RS (DMRS) and channel state information reference signal (CSI-RS) for channel estimation at the UE. The RS may also include beam measurement RS (BRS), beam refinement RS (BRRS), and phase tracking RS (PT-RS).

[0321] 3B shows an example of various DL channels within a subframe of a frame. The physical downlink control channel (PDCCH) carries DCI in one or more control channel elements (CCEs), each CCE containing 9 RE groups (REGs), each REG containing 4 consecutive REs within an OFDM symbol.

[0322] A primary synchronization signal (PSS) may be present in symbol 2 of a particular subframe of a frame. The PSS is used by the UE (e.g., 104 in FIGS. 1 and 2) to determine subframe / symbol timing and physical layer identification information.

[0323] A Secondary Synchronization Signal (SSS) may be present in symbol 4 of a particular subframe of a frame. The SSS is used by the UE to determine the group number of the physical layer cell identity and the timing of the radio frame.

[0324] Based on the physical layer identity and the group number of the physical layer cell identity, the UE can determine a physical cell identifier (PCI). Based on the PCI, the UE can determine the location of the above-mentioned DMRS. A physical broadcast channel (PBCH) carrying a master information block (MIB) may be logically grouped with a PSS and an SSS to form a synchronization signal (SS) / PBCH block. The MIB provides the number of RBs in the system bandwidth and a system frame number (SFN). A physical downlink shared channel (PDSCH) carries user data, broadcast system information not transmitted over the PBCH, such as a system information block (SIB), and paging messages.

[0325] As shown in FIG. 3C, some of the REs carry DMRS (denoted as R for one particular configuration, but other DMRS configurations are possible) for channel estimation at the base station. The UE may transmit DMRS for PUCCH and DMRS for PUSCH. The PUSCH DMRS may be transmitted in the first one or two symbols of the PUSCH. The PUCCH DMRS may be transmitted in different configurations depending on whether a short or long PUCCH is transmitted and depending on the specific PUCCH format used. The UE 104 may also transmit a sounding reference signal (SRS). The SRS may be transmitted, for example, in the last symbol of a subframe. The SRS may have a comb structure, and the UE may transmit the SRS in one of the combs. The SRS may be used by the base station for channel quality estimation to enable frequency-dependent scheduling on the UL.

[0326] 3D shows an example of various UL channels within a subframe of a frame. The PUCCH, in one configuration, may be located as shown. The PUCCH carries uplink control information (UCI), such as scheduling requests, channel quality indicators (CQI), precoding matrix indicators (PMI), rank indicators (RI), and HARQ ACK / NACK feedback. The PUSCH carries data and may also be used to carry buffer status reports (BSR), power headroom reports (PHR), and / or UCI.

[0327] Additional Considerations The foregoing description is provided to enable any person skilled in the art to practice the various aspects described herein. The embodiments discussed herein are not intended to limit the scope, applicability, or aspects described in the claims. Various modifications to these aspects will be readily apparent to those skilled in the art, and the general principles defined herein may be applied to other aspects. For example, changes may be made in the function and arrangement of the elements discussed without departing from the scope of the disclosure. Various embodiments may omit, substitute, or add various steps or components as appropriate. For example, the methods described may be performed in an order different from that described, and various actions may be added, omitted, or combined. Also, features described with respect to some embodiments may be combined in some other embodiments. For example, an apparatus may be implemented or a method may be practiced using any number of the aspects described herein. Additionally, the scope of the disclosure is intended to encompass such apparatus or methods practiced using other structures, functions, or structures and functions in addition to or other than the various aspects of the disclosure described herein. It should be understood that any aspect of the disclosure disclosed herein may be embodied by one or more elements of a claim.

[0328] The various illustrative logic blocks, modules, and circuits described in connection with this disclosure may be implemented or performed using a general purpose processor, a digital signal processor (DSP), an ASIC, a field programmable gate array (FPGA) or other programmable logic device (PLD), discrete gate or transistor logic, discrete hardware components, or any combination thereof designed to perform the functions described herein. A general purpose processor may be a microprocessor, but in the alternative, the processor may be any commercially available processor, controller, microcontroller, or state machine. A processor may also be implemented as a combination of computing devices, such as a combination of a DSP and a microprocessor, multiple microprocessors, one or more microprocessors in conjunction with a DSP core, a system on a chip (SoC), or any other such configuration.

[0329] As used herein, a phrase referring to "at least one of" a list of items refers to any combination of those items, including single members. By way of example, "at least one of a, b, or c" is intended to encompass a, b, c, ab, ac, bc, and abc, as well as any combination having multiples of the same element (e.g., aa, aaa, aab, aac, abb, acc, bb, bbb, bbc, cc, and ccc, or any other permutation of a, b, and c).

[0330] As used herein, the term "determining" encompasses a wide variety of actions. For example, "determining" can include calculating, computing, processing, deriving, investigating, looking up (e.g., looking up in a table, database, or another data structure), ascertaining, and the like. Also, "determining" can include receiving (e.g., receiving information), accessing (e.g., accessing data in a memory), and the like. Also, "determining" can include resolving, selecting, electing, establishing, and the like.

[0331] The methods disclosed herein include one or more actions for achieving the method. The actions of the methods may be interchanged with one another without departing from the scope of the claims. In other words, unless a specific order of actions is specified, the order and / or use of specific actions may be modified without departing from the scope of the claims. Furthermore, the various operations of the methods described above may be performed by any suitable means capable of performing the corresponding functions. These means may include various hardware and / or software components, including, but not limited to, circuits, application specific integrated circuits (ASICs), or processors, and / or various hardware and / or software modules.

[0332] The following claims are not intended to be limited to the embodiments set forth herein, but are to be accorded the full scope consistent with the language of the claims. Within the claims, reference to an element by the singular is not intended to mean "the only one," unless specifically recited as such, but rather "one or more." The term "several," unless specifically recited otherwise, refers to one or more. Claim elements are not to be construed under the provisions of 35 U.S.C. § 112(f) unless the element is expressly recited using the phrase "means for." All structural and functional equivalents to the elements of the various embodiments described throughout this disclosure that are known or later become known to those of skill in the art are expressly incorporated herein by reference and are intended to be encompassed by the claims. Furthermore, nothing disclosed herein is intended to be made public, regardless of whether such disclosure is expressly recited in the claims.

Claims

1. 1. A method for wireless communication by a user equipment (UE), comprising: receiving a request for capabilities of the UE from a network entity; transmitting, in response to the request, a UE capability message distinguishing feature sets supported by the UE in different network types, the UE capability message distinguishing a first feature set supported by the UE in a terrestrial network (TN) from a second feature set supported by the UE in a non-terrestrial network (NTN); The UE capability message includes a common container, the common container comprising: the first feature set supported by the UE in the TN; the second feature set supported by the UE in an NTN; and indicates, a common set of features in the common container applies by default to both TN and NTN networks; transmitting the common container including extensions that distinguish features supported in only one of TN or NTN; A method comprising:

2. The method of claim 1 , wherein the request includes a radio access technology (RAT) type that indicates NTN as a separate RAT.

3. The method of claim 1 , wherein the UE capability message distinguishes feature sets supported by the UE in NTNs with different orbit types.

4. The different trajectory types are:

4. The method of claim 3, comprising two or more of a low earth orbit (LEO) orbit type, a medium earth orbit (MEO) orbit type, a highly elliptical orbit (HEO) orbit type, a geostationary orbit (GEO) orbit type, or a non-GEO orbit type.

5. The method of claim 1 , wherein the second feature set indicates a set of TN and NTN band combinations for which the UE supports at least one of carrier aggregation or dual connectivity.

6. 1. A method for wireless communication by a network entity, comprising: sending a request to a user equipment (UE) for capabilities of said UE; receiving, in response to the request, a UE capability message distinguishing feature sets supported by the UE in different network types, the UE capability message distinguishing a first feature set supported by the UE in a terrestrial network (TN) from a second feature set supported by the UE in a non-terrestrial network (NTN); The UE capability message includes a common container, the common container comprising: the first feature set supported by the UE in the TN; the second feature set supported by the UE in an NTN; and indicates, a common set of features in the common container applies by default to both TN and NTN networks; receiving the common container including an extension that distinguishes features supported in only one of TN or NTN; A method comprising:

7. The method of claim 6 , wherein the request includes a radio access technology (RAT) type that indicates NTN as a separate RAT.

8. The method of claim 6 , wherein the UE capability message distinguishes feature sets supported by the UE in NTNs with different orbit types.

9. The different trajectory types are:

10. The method of claim 8, comprising two or more of a low earth orbit (LEO) orbit type, a medium earth orbit (MEO) orbit type, a highly elliptical orbit (HEO) orbit type, a geostationary orbit (GEO) orbit type, or a non-GEO orbit type.

10. 7. The method of claim 6, wherein the second feature set indicates a set of TN and NTN band combinations for which the UE supports at least one of carrier aggregation or dual connectivity.

11. A user equipment (UE), comprising: means for receiving a request for capabilities of the UE from a network entity; means for transmitting, in response to the request, a UE capability message distinguishing feature sets supported by the UE in different network types, the UE capability message distinguishing a first feature set supported by the UE in a terrestrial network (TN) from a second feature set supported by the UE in a non-terrestrial network (NTN); The UE capability message includes a common container, the common container comprising: the first feature set supported by the UE in the TN; the second feature set supported by the UE in an NTN; and indicates, a common set of features in the common container applies by default to both TN and NTN networks; the common container includes extensions that distinguish features that are supported in only one of TN or NTN; A user equipment (UE) comprising:

12. The UE of claim 11, further comprising means for performing the method of any one of claims 2 to 5.

13. A method for transmitting a request to a user equipment (UE) for capabilities of said UE; means for receiving, in response to the request, a UE capability message distinguishing feature sets supported by the UE in different network types, the UE capability message distinguishing a first feature set supported by the UE in a terrestrial network (TN) from a second feature set supported by the UE in a non-terrestrial network (NTN); The UE capability message includes a common container, the common container comprising: the first feature set supported by the UE in the TN; the second feature set supported by the UE in an NTN; and indicates, a common set of features in the common container applies by default to both TN and NTN networks; the common container includes extensions that distinguish features that are supported in only one of TN or NTN; A network entity comprising:

14. A network entity as described in claim 13, further comprising means for performing a method as described in any one of claims 7 to 10.

15. A computer program comprising instructions which, when executed by a computer, cause the computer to perform a method according to any one of claims 1 to 5 or claims 6 to 10.

Images