Techniques for communicating user equipment capability information

Abstract

This application provides techniques for transmitting user equipment (UE) capability information in a wireless communication network. An exemplary method performed by the UE includes the following steps: receiving a request for UE capabilities from a network entity; and responding to the request by transmitting UE capability information that distinguishes a set of features supported by the UE in different network types.

Description

Technical Field

[0001] This patent application claims priority to U.S. Application No. 18 / 047,077, filed October 17, 2022, which claims the benefit and priority of U.S. Provisional Application No. 63 / 257,925, filed October 20, 2021, pursuant to which the aforementioned application is assigned to the assignee of this application and the entire contents of the aforementioned application are expressly incorporated herein by reference, as fully set forth below, and for all applicable purposes.

[0002] The contents of this case pertain to wireless communications, and more specifically, to technologies used for transmitting user equipment (UE) capability information in wireless communication networks. Prior Technology

[0003] Wireless communication systems are widely deployed to provide a variety of telecommunications services, such as telephone, video, data, messaging, broadcasting, or other similar services. These wireless communication systems may employ multiplexing access technologies that support communication with multiple users by sharing available system resources (e.g., bandwidth, transmission power, or other resources). For example, multiplexing access technologies may rely on any of code division, time division, frequency division orthogonal frequency division, single-carrier frequency division, or time division synchronous code division. These and other multiplexing access technologies have been adopted in various telecommunications standards to provide common protocols that enable different wireless devices to communicate at the city, national, regional, and even global levels.

[0004] Despite significant technological advancements in wireless communication systems over the years, challenges remain. For example, complex and dynamic environments can still attenuate or block signals between wireless transmitters and receivers, disrupting established wireless channel measurement and reporting mechanisms used to manage and optimize the use of limited wireless channel resources. Therefore, there is a need for further improvements to wireless communication systems to overcome these challenges. Summary of the Invention

[0005] One approach provides a method for wireless communication by a user equipment (UE). The method includes the steps of: receiving a request for capabilities of the UE from a network entity; and responding to the request by transmitting UE capability information, the UE capability information distinguishing a set of features supported by the UE in different network types.

[0006] Another approach provides a method for wireless communication by a network entity. The method includes the steps of: transmitting a request for capabilities of a user equipment (UE) to a user equipment (UE); and receiving a UE capability message in response to the request, the UE capability message distinguishing a set of features supported by the UE in different network types.

[0007] Another approach provides a method for wireless communication by a user equipment (UE). The method includes the steps of: generating a partial set of UE capability information; and transmitting the partial set of UE capability information to a network entity.

[0008] Another approach provides a method for wireless communication by a network entity. The method includes the steps of: transmitting a request for a partial set of UE capability information from a user equipment (UE); and receiving a partial set of UE capability information from the UE.

[0009] Another approach provides a method for wireless communication by a network entity. The method includes the steps of: obtaining a partial set of UE capability information associated with a user equipment (UE); and transmitting a request to the UE for an additional set of UE capability information.

[0010] Other forms are provided: an apparatus operable to, configured to, or otherwise adapted to perform the methods described above and elsewhere herein; a non-transitory computer-readable medium including instructions that, when executed by one or more processors of the apparatus, cause the apparatus to perform the methods described above and elsewhere herein; a computer program product embodied on a computer-readable storage medium including code for performing the methods described above and elsewhere herein; and an apparatus including components for performing the methods described above and elsewhere herein. For example, an apparatus may include a processing system, a device having a processing system, or a processing system cooperating via one or more networks.

[0011] For illustrative purposes, the following description and figures illustrate certain features. Simple Explanation of the Diagram

[0012] The accompanying drawings illustrate certain features of the various states described herein, and are not intended to limit the scope of the subject matter.

[0013] Figure 1 is a block diagram conceptually illustrating an exemplary wireless communication network.

[0014] Figure 2 is a block diagram that conceptually illustrates various forms of base stations and user equipment (UE) instances.

[0015] Figures 3A, 3B, 3C, and 3D illustrate various exemplary configurations of data structures for wireless communication networks.

[0016] Figure 4 illustrates an example of a wireless communication network that includes non-terrestrial network (NTN) entities.

[0017] Figures 5A and 5B illustrate exemplary architectures of NTN.

[0018] Figure 6 is a dialing flowchart illustrating an exemplary operation for transmitting user equipment (UE) capability information related to terrestrial networks (TN) and NTN.

[0019] Figure 7 illustrates the first structure used for UE capability information.

[0020] Figures 8A, 8B, 8C, and 8D illustrate variations of the first structure used for UE capability messages.

[0021] Figure 9 illustrates the second structure used for UE capability information.

[0022] Figure 10 provides another illustration of the second structure used for UE capability information.

[0023] Figure 11 illustrates the third structure used for UE capability information.

[0024] Figure 12 illustrates a carrier aggregation / dual connectivity configuration for communication by user equipment.

[0025] Figure 13 illustrates the fourth structure used for UE capability information.

[0026] Figure 14 illustrates the fifth structure used for UE capability information.

[0027] Figure 15 illustrates the sixth structure used for UE capability information.

[0028] Figures 16A, 16B, and 16C illustrate different ways of implicitly indicating support for track types in UE capability messages.

[0029] Figures 17A, 17B, 17C, and 17D illustrate different ways of indicating the frequency bands supported in TN and NTN within the UE capability message.

[0030] Figure 18 is a flowchart illustrating an exemplary operation for wireless communication by a UE.

[0031] Figure 19 is a flowchart illustrating an exemplary operation for wireless communication by a network entity.

[0032] Figure 20 is a flowchart illustrating an exemplary operation for wireless communication by a UE.

[0033] Figure 21 is a flowchart illustrating an exemplary operation for wireless communication by a network entity (such as a source base station (BS)).

[0034] Figure 22 is a flowchart illustrating an exemplary operation for wireless communication by a network entity (such as a target BS).

[0035] Figure 23 illustrates various forms of an exemplary communication device.

[0036] Figure 24 illustrates various forms of an exemplary communication device. Implementation

[0037] Various embodiments of this invention provide apparatus, methods, processing systems, and computer-readable media for transmitting user equipment (UE) capability information indicating support for a set of features in terrestrial networks (TN) and non-terrestrial networks (NTN). In some cases, more specifically, various embodiments of this invention provide structures for transmitting UE capability information. In some cases, the UE capability information can be distinguished between features supported by the UE for different track types. In some cases, the UE capability information can be distinguished between features supported by the UE for carrier aggregation and dual connectivity. Furthermore, various embodiments of this invention provide techniques for reducing the amount of information that needs to be signaled within the UE capability information. For example, in some cases, various embodiments of this invention provide techniques for signaling a portion of the UE capability information. Introduction to wireless communication networks

[0038] Figure 1 illustrates an example in which the various types of wireless communication networks 100 described herein can be implemented.

[0039] Typically, a wireless communication network 100 includes various network entities (or network elements or network nodes), which are usually logical entities associated with, for example, communication devices and / or communication functions associated with communication devices. For example, various functions of the network and various devices associated with and interacting with the network can be considered network entities.

[0040] In the illustrated example, the wireless communication system 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 (5GC) network 190) that interact to provide communication services via various communication links (including wired and wireless links).

[0041] BS 102 communicates wirelessly with UE 104 via communication link 120. Communication link 120 between BS 102 and UE 104 may include uplink (UL) (also known as reverse link) transmission from UE 104 to BS 102 and / or downlink (DL) (also known as forward link) transmission from BS 102 to UE 104. Communication link 120 may use multiple-input multiple-output (MIMO) antenna technology, which in various configurations includes spatial multiplexing, beamforming, and / or transmit diversity.

[0042] Compared to lower-frequency communications, communications using higher frequency bands may have higher path loss and shorter range. Therefore, some base stations (e.g., 180 in Figure 1) can 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 transmission directions 182'. UE 104 may receive beamformed signals from BS 180 in one or more reception directions 182''. UE 104 may also transmit beamformed signals to BS 180 in one or more transmission directions 182''. BS 180 may receive beamformed signals from UE 104 in one or more reception directions 182''. Subsequently, BS 180 and UE 104 can perform beamforming to determine the optimal receive and transmit directions for each of BS 180 and UE 104. Note that the transmit and receive directions for BS 180 may or may not be the same. Similarly, the transmit and receive directions for UE 104 may or may not be the same.

[0043] In each of the various forms, network entities or network nodes can be implemented as aggregated base stations, decomposed base stations, integrated access and backhaul (IAB) nodes, relay nodes, and sidelink nodes. Here are a few examples.

[0044] Figure 2 illustrates various forms of exemplary BS 102 and UE 104.

[0045] Typically, BS 102 includes various processors (e.g., 220, 230, 238, and 240), antennas 234a-t (collectively referred to as 234), transceivers 232a-t (collectively referred to as 232) (which includes modulators and demodulators), and other configurations for wireless transmission of data (e.g., data source 212) and wireless reception of data (e.g., data slot 239). For example, BS 102 can transmit and receive data between itself and UE 104. BS 102 includes a controller / processor 240, which can be configured to implement the various wireless communication-related functions described herein.

[0046] Typically, UE 104 includes various processors (e.g., 258, 264, 266, and 280), antennas 252a-r (collectively referred to as 252), transceivers 254a-r (collectively referred to as 254) (which includes modulators and demodulators), and other configurations that enable the wireless transmission of data (e.g., data source 262) and the wireless reception of data (e.g., data slot 260). UE 104 includes a controller / processor 280, which can be configured to implement the various wireless communication-related functions described herein.

[0047] Figures 3A, 3B, 3C, and 3D illustrate various data structures for wireless communication networks (such as the wireless communication network 100 of Figure 1). Specifically, Figure 3A is a schematic diagram 300 illustrating an example of a first sub-frame within a 5G (e.g., 5G NR) frame structure; Figure 3B is a schematic diagram 330 illustrating an example of a DL channel within a 5G sub-frame; Figure 3C is a schematic diagram 350 illustrating an example of a second sub-frame within a 5G frame structure; and Figure 3D is a schematic diagram 380 illustrating an example of a UL channel within a 5G sub-frame.

[0048] Further discussion of Figures 1, 2, 3A, 3B, 3C, and 3D will be provided later in this article. Various forms related to non-terrestrial networks

[0049] Non-terrestrial networks (NTNs) generally refer to networks or segments of networks that use airborne RF resources on satellites. NTN signal transmission can be regenerable (in the case of airborne NTN processing) or transparent (e.g., so-called bends, where the satellite transmits what it receives back to Earth only after amplification and shifting from uplink to downlink frequencies).

[0050] Figure 4 illustrates an example of a wireless communication network 400 including a non-terrestrial network (NTN) entity 140 (which may generally be referred to as NTN entity 140), in which various forms of the present invention can be implemented. In some instances, wireless communication network 400 can implement various forms of wireless communication network 100. For example, wireless communication network 400 may include BS 102, UE 104, and NTN entity 140 (such as a satellite). In the case of a terrestrial network, BS 102 may serve a coverage area or cell 110a, and in the case of a non-terrestrial network (NTN), NTN entity 140 may serve a coverage area 110b. Some NTNs may employ airborne platforms (e.g., drones or balloons) and / or spaceborne platforms (e.g., satellites).

[0051] As part of the radio communication within the NTN, NTN entity 140 can communicate with BS 102 and UE 104. In the case of a terrestrial network, UE 104 can communicate with BS 102 via communication link 414. In the case of NTN radio communication, NTN entity 140 can be a serving cell for UE 104 via communication link 416. In some configurations, NTN entity 140 can act as a repeater (or remote radio head) for BS 102 and UE 104. For example, BS 102 can communicate with NTN entity 140 via communication link 418, and non-terrestrial network entities can relay signals between BS 102 and UE 104 via communication links 416 and 418.

[0052] For LEO satellites, the typical coverage area (footprint) of the NTN beam is 100 to 1000 km, and for GEO satellites, it is 200 to 3500 km. As shown in Figure 5A, NG-RAN deployments can include satellites and NTN gateways (GWs), which act as cellular Uu links between the UE and the terrestrial network (TN) gNB (and the 5G core network). NG-RAN typically stands for Radio Access Network for 5G, providing both NR and LTE radio access. The link between the UE and the satellite is typically called the serving link, while the link between the satellite and the GW is typically called the feeder link.

[0053] As shown in Figure 5B, as the satellite moves across its orbit, it communicates with different gateways. 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 typically the sum of the delay on the serving link (DUE) and the delay on the feeder link (DSAT). For GEO satellites, the maximum RTD is typically approximately 541.46 ms, for LEO satellites at an altitude of 600 km, the maximum RTD is typically approximately 25.77 ms, and for LEO satellites at an altitude of 1200 km, the maximum RTD is typically approximately 41.77 ms. Compared to the speed of the LEO satellite, the UE speed can typically be ignored. Various states related to transmitting UE capability information

[0054] In some cases, the UE can communicate simultaneously with both the terrestrial network (TN) and the non-terrestrial network (NTN). Furthermore, in some cases, the UE can interleave between the TN and NTN, and vice versa. Accordingly, the UE can support different features or capabilities for communicating with the TN and NTN. For example, the UE can support a first set of capabilities in the TN and a second set of capabilities in the NTN. In some cases, capabilities in the TN can also be applied to the NTN. The UE can indicate these capabilities to the base station (e.g., BS 102) and, in response, receive configuration information for configuring the UE to use one or more of these capabilities when communicating with the base station.

[0055] A fifth-generation (5G) new radio (NR) NTN has been developed, which assumes that any legacy NR features (e.g., TN features) can be supported in the NTN (if needed). However, not all legacy UE TN features are applicable to the NTN. Therefore, a capability distinction between TN and NTN may be necessary to indicate which features the UE supports in the TN and which features the UE supports in the NTN.

[0056] Furthermore, in some cases, certain characteristics may depend on the satellite orbit type when communicating in an NTN. For example, certain frequency bands may be allocated to geostationary or geosynchronous orbit (GSO) types and non-GSO (NGSO) types. However, different UE capabilities / features may be required for GSO types compared to NGSO types. For example, UE capabilities / features may be considered mandatory in NGSO but not in GSO. Accordingly, a capability distinction between different orbit types may be needed to indicate which features the UE supports in different orbit types.

[0057] Therefore, various forms of the content of this application provide techniques for indicating UE capability information used for communication in TN and NTN. For example, such techniques may include transmitting UE capability messages that distinguish the set of features supported by the UE in different network types. In some cases, the techniques proposed herein provide different structures for transmitting UE capability messages. The diagram illustrates an exemplary dialing procedure for transmitting UE capability information.

[0058] Figure 6 is a dialing flowchart illustrating an exemplary operation 600 for transmitting UE capability information related to TN and NTN. As illustrated, operation 600 can be performed by network entity 602 and UE 604. In some cases, network entity 602 can be an instance of BS 102 shown in Figures 1 and 2 or NTN entity 140 shown in Figure 4. Furthermore, in some cases, UE 604 can be an instance of UE 104 shown in Figures 1, 2, and 4.

[0059] As illustrated, operation 600 begins at 610 with UE 604 receiving a request for UE capabilities from network entity 602. Subsequently, as shown at 615, UE 604 responds to the request by transmitting UE capability information that distinguishes the set of features supported by the UE in different network types (such as TN and NTN). In some cases, the features involve at least one of the following: entity layer processing, media access control layer processing, packet data convergence protocol (PDCP) processing, radio link control (RLC) processing, and mobility or IP multimedia subsystem (IMS).

[0060] 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 the same feature, UE 604 may support the feature for TN but not for NTN, and vice versa. Furthermore, in some cases, the indication of UE capabilities may depend on the availability of Internet of Things (IoT) opportunities, and accordingly, technology may be needed to allow UE 605 to differentiate between TN and NTN capabilities (even for the same feature). Therefore, in some cases, NTN may be defined or considered a separate RAT (e.g., nr-ntn) from NR TN. When requesting NTN-related capabilities from UE 604, network entity 602 may indicate nr-ntn in the RAT type field of the request (e.g., UE capability query) received by UE 604 at 610. Different RAT types, such as nr, eutra-nr, eutra, utra-fdd-v1610, etc., may also be indicated within the request.

[0061] Therefore, when UE 604 receives a request including an indication of the NTN RAT type, the UE capability message transmitted at 615 distinguishes between the first set of features supported by the UE in the TN and the second set of features supported by the UE in the NTN. In some cases, the first set of features supported in the TN and the second set of features supported in the NTN may be distinguished in the UE capability message using different structures.

[0062] Figure 7 illustrates a first structure 700 for UE capability message 702. UE capability message 702 may be an example of the UE capability message transmitted by UE 604 at 615 in Figure 6. As illustrated, UE capability message 702 includes a first container 704 indicating a first set of features supported by UE 604 in the TN. Furthermore, as illustrated, UE capability message 702 includes one or more second containers 706 indicating a second set of features supported by UE 604 in the NTN.

[0063] In some cases, the structure of one or more second containers 706 for NTN features supported by UE 604 may be the same as or similar to the structure of the first container 704 for TN features supported by UE 604. In other words, 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 shared features. In other words, 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, UE 604 may indicate that the UE capability for such features is not supported.

[0064] In other cases, the structure of 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, one or more second containers 706 may not have fields or IEs for such inapplicable features. That is, although the first container 704 for TN may include fields or IEs for such features, one or more second containers 706 may not include fields or IEs for such features.

[0065] In some cases, the UE capability information transmitted by UE 604 at point 615 can distinguish the set of features supported by UE 604 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 can be considered to distinguish the features supported by UE 604 for different orbit types. For example, FIG. 8A, FIG. 8B, FIG. 8C and FIG. 8D illustrate different variations of the first structure 700 for distinguishing UE support for NTN features used in NTNs with different orbit types. In some cases, different orbit types may include two or more of the following: Low Earth Orbit (LEO) orbit type, Medium Earth Orbit (MEO) orbit type, Highly Elliptical Orbit (HEO) orbit type, Geostationary Orbit (GEO) orbit type, Non-GEO orbit type, Geosynchronous Orbit (GSO) orbit type, Non-GSO orbit type, or High Altitude Platform Station (HAPS) orbit type. The exemplary variant structures shown in Figures 8A, 8B, 8C, and 8D assume GEO and non-GEO orbital types, but the variant structures shown in these figures can also support other orbital types.

[0066] Figure 8A illustrates a first variant structure 800A for the UE capability message 702 transmitted by UE 604 at 615 in Figure 6, where, for example, one or more second containers 706 of Figure 7 include separate containers. More specifically, as shown in Figure 8A, the UE capability message 702 includes separate containers for NTN features with different track types. For example, as shown in Figure 8A, the UE capability message 702 includes a TN container 802A for indicating one or more TN features supported by UE 604. Furthermore, the UE capability message 702 shown in Figure 8 includes a first NTN container 804A for indicating features supported by UE 604 for a first track type (e.g., GEO track type) and a second NTN container 806A for indicating features supported by UE 604 for a second track type (e.g., non-GEO track type).

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

[0068] In the example illustrated in Figure 8B, individual bitmaps can be used within the shared NTN container 804B to indicate different features supported in NTNs of different track types. For example, in some cases, each bitmap may include a plurality of bits, each different bit corresponding to a different track type, and indicating whether a specific feature is supported for the corresponding track type.

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

[0070] Figure 8C illustrates a third variant structure 800C for UE capability message 702, where one or more second containers 706 of Figure 7 include a common container. More specifically, as with Figure 8B, the UE capability message 702 illustrated in Figure 8C includes a common container that distinguishes the set of features supported by UE 604 in NTNs with different track types. However, in Figure 8C, the common container may include separate capability fields for different track types, instead of using bit mapping to distinguish features supported for different track types. For example, as illustrated, the UE capability message 702 illustrated in Figure 8C includes a TN container 802C for indicating one or more TN features supported by UE 604. Furthermore, the UE capability message 702 illustrated in Figure 8C includes a common NTN container 804C for indicating NTN features associated with different track types supported by UE 604.

[0071] Furthermore, as illustrated, the shared NTN container 804C may include a plurality of individual fields to distinguish NTN features for different track types. For example, as illustrated, the shared 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 UE 604 supports a first feature for a first track type (e.g., a GEO track type), and the second NTN feature field 808C may include capability information indicating that UE 604 supports a second feature for a second track type (e.g., a non-GEO track type).

[0072] Figure 8D illustrates a fourth variant structure 800D for UE capability message 702, where one or more second containers 706 of Figure 7 include a common container. More specifically, as with Figures 8B and 8C, the UE capability message 702 illustrated in Figure 8D includes a common container that distinguishes the set of features supported by UE 604 in NTNs with different track types. However, in the example illustrated in Figure 8D, the common container also includes a common feature field for indicating a common set of NTN features supported for different track types, and a plurality of track type-specific fields for indicating a set of NTN features specific to a particular track type. In other words, the UE capability message 702 illustrated in Figure 8D includes a combination of at least one structure (e.g., a field) indicating a common set of features supported in different track types and individual structures (e.g., fields) indicating different features supported in NTNs of different track types.

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

[0074] In some cases, one of the variant architectures 800A, 800B, 800C, or 800D can be used to differentiate NTNs with different track types from the support provided by UE 604 for features associated with at least one of the following: physical layer processing, media 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 some track types), Hybrid Automatic Repeat Request (HARQ) related features (e.g., number of HARQ procedures, 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 some track types), MIMO or beam-related features (e.g., spatial relationship-related features, channel status information-related features, higher layer number, sounding reference signal (SRS) switching, beam failure recovery (BFR), or parameters such as beamSwitchTiming and beamReportingTiming), extended cyclic prefix (CP) related features, semi-persistent signal delivery (SPS) (e.g., configured allowable type 1 / 2), and / or DCI-based bandwidth portion BWP switching.

[0075] In some cases, PDCP-related features may include, for example, sequence number (SN) length (e.g., a longer SN may be required for certain track types, such as GEO track types, due to longer transmission delays) and extended timers (e.g., t-PollRetransmit, t-StatusReport, t-reassembly, PDCP discard timers, etc., which may be longer for certain track types, such as GEO track types).

[0076] In some cases, mobility-related features may include one or more RAT (Round-Ahead Inter-Hover) features. Additionally, in some cases, IMS-related features may include one or more features related to NR speech (VoNR). In some cases, the feature layer includes other features related to high-speed parameters.

[0077] Figure 9 illustrates a second structure 900 for UE capability message 902. UE capability message 902 can be an example of the UE capability message transmitted by UE 604 at 615 in Figure 6. In contrast to the first structure 700 for capability messages illustrated in Figure 7, which includes separate containers for TN and NTN features, the second structure for UE capability message 902 illustrated in Figure 9 includes a shared container 904 indicating a first set of features supported by UE 604 in the TN and a second set of features supported by UE 604 in the NTN. In this case, the second set of features supported by UE 604 in the NTN can be defined as an extension of the first set of features supported by UE 604 in the TN. For example, in addition to including the first set of features supported in the TN (e.g., UE capabilities in conventional NR), the shared container 904 includes an extension 906, which includes a field or IE indicating the second set of features supported in the NTN (e.g., UE capabilities in NR NTN).

[0078] In some cases, the structure of extension 906 can be the same as or similar to the structure of a portion of the common container 904 carrying a first set of features supported in the TN. For example, this portion of the common container 904 can be similar to a portion of a conventional NR RAT capability container that typically carries a first set of features supported in the TN, such as the first container 704 illustrated in FIG. 7. In other words, extension 906 for NTN features can reuse the structure of this portion of the common container 904 for TN features (e.g., similar to the first container 704 for TN features in FIG. 7). In this case, for TN features that are not applicable to the NTN, UE 604 can indicate that the UE capability for such features is not supported.

[0079] In other cases, the structure of extension 906 may differ from the structure of the portion of the common container 904 used for TN features. For example, in this case, extension 906 may not have fields or IEs for TN features that are not applicable to the NTN RAT type. That is, although the common container includes fields or IEs for indicating support for such features in the TN, extension 906 may not include fields or IEs for such features.

[0080] In some cases, as mentioned above, the UE capability message transmitted by UE 604 at 615 can distinguish the set of features supported by UE 604 in NTNs with different track types. In this case, variant structures similar to those illustrated in Figures 8A, 8B, 8C, and 8D can be applied to the second structure 900, and to the UE capability message 902 illustrated in Figure 9.

[0081] In other cases, the conventional NR container used to indicate UE capabilities can be pre-applied to both TN and NTN. However, if it is necessary to differentiate the transmission of track-type specific (e.g., NTN-specific) capabilities, an extension to the conventional NR container can be added to distinguish such track-type specific capabilities. In this case, a common feature set can be included in a common container 904 pre-applied to both TN and NTN networks. Furthermore, extension 906 can be used to distinguish features supported in only one of the TN or NTN. For example, as shown in FIG10, UE capability message 902 includes a common container 1002, which includes a common feature set pre-applied to both TN and NTN networks. Further, UE capability message 902 includes extension 1004, which distinguishes features 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, extension 1004 can indicate that the feature is not supported in the NTN. Otherwise, if the second feature is supported in both the TN and NTN, then the feature can be included within the common container 1002, and it can be understood that the second feature is supported for both the TN and NTN. In other words, because the second feature is supported in both the TN and NTN, it does not need to be indicated separately for the TN and NTN.

[0082] Figure 11 illustrates a third structure 1100 for UE capability message 1102. UE capability message 1102 may be an example of the UE capability message transmitted by UE 604 at 615 in Figure 6. As illustrated, the third structure 1000 is a combination of the first structure 700 and the second structure 900. For example, similar to the second structure 900 illustrated in Figure 9, the UE capability message 1102 in the third structure 1100 includes a common container 1104 that indicates at least a portion of a first set of features supported by UE 604 in the TN and a second set of features supported by UE 604 in the NTN. In some cases, the common container 1104 may include a conventional NR RAT capability container that includes an extension 1106 (e.g., one or more fields / IEs) for indicating a portion of the second set of features supported by UE 604 in the NTN. Further, similar to the first structure 700 shown in Figure 7, the UE capability message 1102 includes a second container 1108 for indicating features supported by UE 604 for the NTN. More specifically, the second container 1108 may indicate a second portion of a second set of features supported by the UE in the NTN.

[0083] In some cases, when the third structure 1100 is used for 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 query) received by UE 604 at 610. Further, when the third structure 1100 is used for UE capability message 1102, support for features in the NTN may be categorized 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 track-specific features / capabilities, variant structures similar to those illustrated in Figures 8A, 8B, 8C, and 8D may be applied to the third structure 1100 and for the UE capability message 1102 illustrated in Figure 11.

[0084] In some cases, NTN features can be classified in different ways. For example, in some cases, shared TN and NTN features can be classified into a first group and included within a shared container 1104. In other words, shared TN and NTN features represent at least a portion of the first set of features supported by UE 604 in the TN and the second set of features supported by UE 604 in the NTN, as indicated within the shared container 1104. Further, NTN features that are not shared between the TN and NTN can be classified into a second group and included within a second container 1108. In other words, non-shared NTN features represent a second portion of the second set of features supported by UE in the NTN.

[0085] In other cases, NTN features that already support sufficient granularity (e.g., per-band or per-band combination capability granularity) for their traditional NR RAT UE capability architecture can be classified into the first group, while NTN features that do not support sufficient granularity (e.g., per-UE capability granularity) for their traditional NR RAT UE capability architecture can be included in the common container 1104, while NTN features that do not support sufficient granularity for their traditional NR RAT UE capability architecture can be included in the second container 1108.

[0086] In some cases, the second container, compared to the shared container 1104, is limited to differentiated UE capabilities. More specifically, the second container 1108 can be used to indicate support for NTN features / capabilities that need to be reported differently from TN features (e.g., not shared for TN). For example, if a UE needs to report support for some features or capabilities differently for NTN, the second container 1108 only contains those features that need to be reported differently. In some cases, additional containers can also be included within the UE capability message 1102 to indicate differentiated UE capabilities for different track types. For example, in some cases, the second container 1108 can be used to indicate differentiated UE capabilities for GEO track types, while a third container can be used to indicate differentiated UE capabilities for non-GEO track types. In some cases, these techniques can reduce the size of the second container 1108 because it only includes differentiated reported features. Any newly introduced NTN-specific capabilities or features can be added to the shared container 1104 within extension 1106. In some cases, an indication can also be added to the common container 1104 regarding whether the UE needs to report certain NTN features or capabilities differently. Status patterns related to TN-NTN carrier aggregation and dual connectivity capabilities for signal transmission

[0087] In some cases, carrier aggregation (CA) and dual connectivity (DC) can be used by UE 604 to communicate with a network (such as a TN or NTN). For example, in some cases, the UE can use CA / DC to communicate with a TN base station (e.g., BS 102) using one or more TN carriers, and 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 can be within certain respective TN-specific frequency bands and NTN-specific frequency bands. In other cases, the UE can use CA / DC to communicate with two different NTN base stations (e.g., two different NTN entities 140). In some cases, although CA / DC communication may be facilitated via two different base stations from the perspective of UE 604, from the perspective of the network, CA / DC communication may be controlled or operated by only one network entity.

[0088] Figure 12 illustrates a CA / DC configuration for communication by a UE (such as UE 604). As illustrated, in some cases, the UE can use the CA / DC to communicate with a TN base station 1202 using a TN carrier 1204, and 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).

[0089] In other cases, the UE can use a CA / DC to communicate with two different NTN base stations, which may be associated with different track types. Furthermore, in some cases, this CA / DC communication can be inter-band or intra-band. For example, as illustrated, in some cases, the UE can use a CA / DC to communicate with a first NTN base station 1206 using a first NTN carrier 1208 and with a second NTN base station 1210 using a second NTN carrier 1212, referred to as inter-band NTN CA / DC. Further, as illustrated, the first NTN base station 1206 and the second NTN base station 1210 may have the same track type, and accordingly, this type of CA / DC can be further referred to as intra-track CA / DC.

[0090] Furthermore, in other cases, the UE can use a CA / DC to communicate with a third NTN base station 1214 using a first NTN carrier 1208, and with a second NTN base station 1210 using a second NTN carrier 1212. Again, this situation can be referred to as an inter-band NTN CA / DC. However, in this example, the second NTN base station 1210 and the third NTN base station 1214 can have different track types. Accordingly, this type of CA / DC can be further referred to as an inter-track CA / DC.

[0091] In other cases, the UE can use CA / DC to communicate with the second NTN base station 1210 using the second NTN carrier 1212, and also to communicate with the fourth NTN base station 1216 using the second NTN carrier 1212. This situation can be referred to as in-band NTN CA / DC. Furthermore, in this example, the second NTN base station 1210 and the fourth NTN base station 1216 can have the same track type.

[0092] In some cases, when using a TN-NTN CA / DC for communication, it may be necessary to signal additional UE capability information, such as support for one or more TN-NTN band combinations (e.g., combinations of TN and NTN bands supported by the UE for communication with TN and NTN using CA / DC). Therefore, various embodiments of this invention provide techniques for signaling such additional UE capability information within the UE capability message transmitted by UE 604 at 615 in FIG. 6.

[0093] For example, in some cases, when it is necessary to transmit UE-NR TN-NTN capabilities via signaling, the E-UTRA-NR dual connectivity (EN-DC) or NR-E-UTRA dual connectivity (NE-DC) method can be used, as shown in Figure 13. For example, Figure 13 illustrates a fourth structure 1300 for transmitting UE capability messages to indicate support for TN-NTN related features / capabilities. As illustrated, Figure 13 includes UE capability message 1302, which may be an example of the UE capability message transmitted by UE 604 at 615 in Figure 6.

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

[0095] In some cases, when defining a track-specific RAT (e.g., GEO, non-GEO, etc.), UE 604 is required to indicate support for features / capabilities associated with different NTN track types. The third container 1308 may include a different set of TN and NTN band combinations for each NTN track type. The UE may indicate support for features / capabilities associated with different NTN track types in a separate container. For example, in some cases, the third container 1308 may be associated with a first track type (e.g., GEO track type) and indicate a set of TN and NTN band combinations for the first track type. Furthermore, the UE capability message 1302 may include at least one other container associated with a second track type (e.g., non-GEO track type) and indicate another set of TN and NTN band combinations for the second track type. In other words, TN-NTN CA / DC features supported by the UE for different track types may be included in a separate container (e.g., a separate UE-NR-TN-NTN container).

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

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

[0098] For example, as illustrated, UE capability message 1502 includes a first container 1504 (e.g., a UE-NR container for legacy NR features) indicating a first set of features supported by UE 604 in the TN. Furthermore, 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 the NR NTN). Further, as illustrated, portion 1506 may include a set 1508 of TN and NTN band combinations in which UE 604 supports carrier aggregation. As illustrated, 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 UE 604 in the NTN.

[0099] Furthermore, as illustrated, the UE capability message 1502 includes a third container 1512 (e.g., a UE-NR-TN-NTN container for TN-NTN DC features), which includes a set of TN and NTN features for TN-NTN DC. For example, as illustrated, the third container 1512 includes a set of TN and NTN band combinations 1514 in which UE 604 supports dual connectivity. Additional details regarding the set of features supported in NTNs with different orbit types.

[0100] As mentioned above, in some cases, the UE capability message transmitted by UE 604 at 615 can distinguish the feature sets supported by UE 604 in NTNs with different track types. In some cases, UE 604 can, for example, use a variant structure of the variant structures illustrated in Figures 8A-8D to distinguish the feature sets for GEO track types from those for non-GEO track types. In other cases, the distinction between feature sets for track types can be more granular. For example, in some cases, UE 604 can distinguish the feature sets in the UE capability message for LEO track types, MEO track types, HEO track types, and / or GEO track types.

[0101] In some cases, track type can be characterized based on elevation. For example, a track within the elevation range of X and Y can be considered a first track type, while a track within the range of Y and Z can be considered a second track type, and so on. More specifically, track elevations with subtle differences, such as 2 km, between 300 km and 36,000 km can be defined as several different track types.

[0102] Furthermore, in some cases, when distinguishing the set of features supported by UE 604, communication characteristics (such as latency levels (one-way or round-trip time) and environmental variations (e.g., radio quality variations due to satellite movement) can be considered. This is because UE 604 may not know the orbit type, but may know the communication characteristics associated with the orbit type. More specifically, for example, a latency level with a subtle difference of 20 ms between 20 ms and 600 ms can be defined as several different orbit types.

[0103] In some cases, in addition to indicating the set of features supported by UE 604 for different track types, UE 604 may also indicate whether UE 604 supports such different track types to begin with. UE 604 may indicate support for track types in different ways, such as via implicit indication, explicit indication, or a combination thereof.

[0104] In some cases, the UE may implicitly indicate support for track types in different ways, as shown in Figures 16A, 16B, and 16C. In some cases, the different ways of indicating support for track types may be applied to the second structure 900 illustrated in Figure 9 for transmitting the capability message at 615 in Figure 6 and the third structure 1100 illustrated in Figure 11 for transmitting the capability message at 615.

[0105] Figure 16A illustrates a first method for implicitly indicating support for track types in UE capability message 1602. In some cases, UE capability message 1602 includes UE capability messages transmitted by UE 604 at 615, and incorporates a second structure 900 illustrated in Figure 9. For example, UE capability message 1602 includes a common container 1604 (e.g., similar to common container 904 illustrated in Figure 9) which includes a set of common features pre-defined for both TN and NTN networks; and an extension that includes a field or IE indicating a second set of features supported in NTN (e.g., UE capabilities in NR NTN).

[0106] Furthermore, as illustrated, the shared container 1604 includes a frequency band combination list 1606. The frequency band combination list 1606 includes the set of frequency bands supported by UE 604 in the TN and NTN. For example, as illustrated, the frequency band combination list 1606 indicates that UE 604 supports frequency bands n1 and n3 in the TN and frequency bands n400 and n401 in the NTN. In some cases, frequency bands n400 and n401 may include the same physical frequency band, but can be used to distinguish whether UE 604 supports that physical frequency band for different NTN track types. For example, in some cases, the indication of frequency band n400 in the frequency band combination list 1606 may implicitly indicate that UE 604 supports that physical frequency band for the LEO track type, while the indication of frequency band n401 may implicitly indicate that UE 604 supports that physical frequency band for the MEO track type.

[0107] Figure 16B illustrates a second method for implicitly indicating support for track types in UE capability message 1602. As illustrated, this second method for implicitly indicating support for track types involves a set of frequency band combinations IE defined for each track type. In some cases, the set of frequency band combinations may include a set of bits associated with each frequency band indicated in the frequency band combination list 1606. For example, as illustrated, frequency band n1 is associated with the first set of bits 1608 in the frequency band combination list 1606, and frequency band n3 is associated with the second set of bits 1610 in the frequency band combination list 1606.

[0108] The first bit set 1608 includes a set of first bits used to indicate UE 604's support for band n1 for different track types. For example, in some cases, when the first bit in the first bit set 1608 is set to a value of "1", this can indicate that UE 604 supports band n1 for the LEO track type. Furthermore, when the second bit in the first bit set 1608 is set to a value of "1", this can indicate that UE 604 supports band n1 for the MEO track type. The remaining bits of each of the first bit sets 1608 can indicate whether UE 604 supports band n1 for the remaining track types (e.g., HEO, GEO, non-GEO, etc.). In some cases, a value of "0" (instead of a value of "1") in the first bit set 1608 can indicate that UE 604 supports band n1 for the corresponding track type.

[0109] Similarly, the second bit set 1610 includes a second bit set for indicating the support of UE 604 for band n3 for different track types. For example, in some cases, when the first bit in the second bit set 1610 is set to a value of "1", this can indicate that UE 604 supports band n3 for the LEO track type. However, when the second bit in the second bit set 1610 is set to a value of "0", this can indicate that UE 604 does not support band n3 for the MEO track type. The remaining bits of each of the second bit sets 1610 can indicate whether UE 604 supports band n3 for the remaining track types (e.g., HEO, GEO, non-GEO, etc.). In some cases, a value of "0" (instead of a value of "1") in the second bit set 1610 can indicate that UE 604 supports band n3 for the corresponding track type.

[0110] Figure 16C illustrates a third method for implicitly indicating support for a track type in UE capability message 1602. As illustrated, this third method for implicitly indicating support for a track type involves repeating the same band or band number in band combination list 1606. For example, as illustrated, band n400 may be repeated twice in band combination list 1606. In some cases, each repetition of band n400 may indicate support for different track types. For example, when band combination list 1606 does not include any repetition of band n400, this may indicate that the UE supports band n400 for the LEO track type. Further, when band combination list 1606 includes a single repetition of band n400, as shown in Figure 16C, this may indicate that UE 604 supports band n400 for both LEO and MEO track types. Additional repetitions (such as two repetitions) of band n400 can instruct UE 604 to support band n400 for LEO, MEO, and GEO orbit types, etc.

[0111] As mentioned above, in some cases, UE 604 can explicitly indicate support for different track types. For example, UE 604 can provide different explicit indications within the UE capability message transmitted at 615, indicating which track types UE 604 supports. In some cases, the explicit indication can be per-band indication in the band combination list. For example, in some cases, UE 604 can provide a first explicit indication that UE 604 supports band n400 for the LEO track type, and can also provide a second explicit indication that UE 604 does not support band n400 for the MEO track type. In some cases, the explicit indication can use common names for track types, such as LEO, MEO, GEO, etc.

[0112] In some cases, UE 604 may instead indicate the different orbital elevations that UE 604 can support, rather than explicitly indicating the different orbital types supported by UE 604. Different orbital elevations may each be associated with a range and nuance (e.g., an orbital elevation between 300 km and 36,000 km with a nuance of 2 km). Accordingly, UE 604 may indicate which elevation falls within the range that UE 604 can support.

[0113] Whether UE 604 implicitly or explicitly indicates the supported track types, UE 604 can indicate every track type supported by UE 604, or it can indicate the highest track type supported by UE 604. In some cases, when the highest track type supported by UE 604 is indicated, this may mean that lower track types are also supported by UE 604. Additional details regarding the frequency bands supported in NTN

[0114] As mentioned above, in some cases, the UE capability message transmitted by UE 604 at 615 may indicate a first set of features supported by UE 604 in the TN and a second set of features supported by UE 604 in the NTN. In some cases, the first set of features may include frequency bands supported by UE 604 in the TN, and the second set of features may include frequency bands supported by UE 604 in the NTN. In some cases, the frequency bands supported by UE 604 may be indicated in one or more frequency band combination lists in the UE capability message. Figures 17A, 17B, 17C, and 17D illustrate different ways of indicating the frequency bands supported by UE 604 in the TN and NTN.

[0115] Figure 17A illustrates a first method for indicating the frequency bands supported by UE 604 in TN and NTN within UE capability message 1702. In some cases, UE capability message 1702 includes UE capability messages transmitted by UE 604 at 615, and incorporates a second structure 900 illustrated in Figure 9. For example, UE capability message 1702 includes a first container 1704 (e.g., similar to the shared container 904 illustrated in Figure 9), which includes a set of shared features pre-defined for both TN and NTN networks; and an extension including a field or IE indicating a second set of features supported in NTN (e.g., UE capabilities in NR NTN).

[0116] Furthermore, as illustrated, the first container 1704 includes a first frequency band combination list 1706. The first frequency band combination list 1706 includes the set of frequency bands supported by UE 604 in the TN and NTN. In some cases, to distinguish between frequency bands supported by UE 604 in the NTN and frequency bands supported by UE 604 in the TN within the first frequency band combination list 1706, UE 604 may use NTN-specific frequency band definitions for the frequency bands supported by UE 604 in the NTN. For example, as shown in FIG17A, UE 604 may include frequency bands n1 and n3 within the first frequency band combination list 1706, indicating that UE 604 supports these frequency bands in the TN. Furthermore, UE 604 may indicate NTN-specific frequency bands (such as n400) to indicate that UE 604 supports frequency band n400 in the NTN.

[0117] Figure 17B illustrates a second method for indicating the frequency bands supported by UE 604 in the TN and NTN within UE capability message 1702. As illustrated, the second method for indicating the supported frequency bands involves the use of separate lists of frequency band combinations for the TN and NTN. For example, as shown in Figure 17B, UE capability message 1702 has a structure similar to the first structure 700 shown in Figure 7, including a first container 1704 indicating a first set of features supported by UE 604 in the TN and a second container 1708 indicating a second set of features supported by UE 604 in the NTN.

[0118] In some cases, the first feature set may include the set of frequency bands supported by UE 604 in the TN, and may be indicated in a first frequency band combination list 1706 included within the first container 1704. Additionally, the second feature set may include the set of frequency bands supported by UE 604 in the NTN, and may be indicated in a second frequency band combination list 1710 included within the second container 1708. In some cases, when indicating frequency bands supported by UE 604 in the NTN in the second frequency band combination list 1710, UE 604 may alternatively include an indication of existing TN frequency bands and an indication of NTN support capabilities for those bands, instead of indicating NTN-specific frequency bands as described above with respect to FIG1A. For example, as illustrated, UE 604 may indicate support for TN frequency bands n1 and n3 in the first frequency band combination list 1706. In addition, UE 604 may also indicate bands n1 and n3 in the second band combination list 1710 to indicate that UE 604 supports such bands in NTN.

[0119] Figure 17C illustrates a third method for indicating the frequency bands supported by UE 604 in the TN and NTN within UE capability message 1702. As illustrated, the structure of UE capability message 1702 in Figure 17C may be the same as or similar to the second structure 900 illustrated in Figure 9. As illustrated, the third method for indicating the supported frequency bands involves a frequency band combination set IE defined for each frequency band. In some cases, each frequency band combination set IE may include a set of bits associated with its respective frequency band, which may be configured to indicate whether UE 604 supports its respective frequency band in the NTN.

[0120] For example, as illustrated, UE capability information 1702 includes a first container 1704 (e.g., similar to the common container 904 shown in FIG9), which includes a set of common features pre-defined for both TN and NTN networks; and an extension, which includes a field or IE indicating a second set of features supported in NTN (e.g., UE capabilities in NR NTN).

[0121] Furthermore, the first container 1704 includes a first frequency band combination list 1706. Further, as illustrated, the first frequency band combination list 1706 includes a set of frequency bands supported by UE 604 in the TN, such as frequency bands n1 and n3. Each of frequency bands n1 and n3 may be associated with a frequency band combination set IE, which includes a set of bits that can be used to indicate whether UE 604 supports frequency bands n1 and n3 in the NTN. For example, as illustrated, frequency band n1 may be associated with a first frequency band combination set IE including a first bit set 1712, and frequency band n3 may be associated with a second frequency band combination IE including 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 UE 604 supports frequency band n1 in the NTN. Similarly, one or more bits or a second set of bits 1714 can be set (e.g., to a bit value of "1") to indicate that UE 604 supports band n3 in the NTN. In some cases, a bit value of "0" (instead of a bit value of "1") can indicate that UE 604 supports the corresponding band in the NTN, such as band n1.

[0122] Figure 17D illustrates a fourth method for indicating the frequency bands supported by UE 604 in the TN and NTN within UE capability message 1702. As illustrated, this fourth method for indicating supported frequency bands involves the use of a list of frequency band combinations for indicating frequency bands supported for the TN and separate bit maps for indicating frequency bands supported in the NTN. For example, as shown in Figure 17D, UE capability message 1702 has a structure similar to the first structure 700 illustrated in Figure 7, including a first container 1704 indicating a first set of features supported by UE 604 in the TN and a second container 1708 indicating a second set of features supported by UE 604 in the NTN.

[0123] As mentioned above, the first feature set may include the set of frequency bands supported by UE 604 in the TN, and may be indicated in the first frequency band combination list 1706 included in the first container 1704. Furthermore, the second feature set may include the set of frequency bands supported by UE 604 in the NTN. However, unlike the frequency bands supported by UE 604 in the TN, the set of frequency bands supported by UE 604 in the NTN may be indicated in the second container 1708 using new capabilities (IEs) such as bit mapping.

[0124] For example, as illustrated, the second container 1708 includes a bit image 1716, which includes a plurality of bits. In some cases, each of the plurality of bits in the bit image 1716 in the second container 1708 may correspond to a different frequency band indicated in the first frequency band combination list 1706 of the first container 1704. As an example, the first bit in the bit image 1716 may correspond to frequency band n1 indicated in the first frequency band combination list 1706 of the first container 1704. Similarly, the second bit in the bit image 1716 may correspond to frequency band n3 indicated in the first frequency band combination list 1706 of the first container 1704. Therefore, the UE 604 can selectively set the first and second bits to indicate whether the UE 604 supports frequency bands n1 and n3 in the NTN. For example, as illustrated, UE 604 can set the first and second bits to a value of "1" to indicate that UE 604 supports bands n1 and n3 in the NTN. In some cases, a bit value of "0" (instead of a bit value of "1") can be used to indicate that UE 604 supports bands n1 and n3 in the NTN. Exemplary method for transmitting UE capability information

[0125] Figure 18 illustrates a method 1800 for transmitting UE capability information via wireless communication by a UE (such as UE 104 in the wireless communication network 100 of Figure 1 and / or UE 604 illustrated in Figure 6).

[0126] As illustrated, method 1800 begins at step 1810 with the UE receiving a request for the UE's capabilities from a network entity.

[0127] At step 1820, the UE responds to the request by transmitting UE capability information, which distinguishes the set of features supported by the UE in different network types.

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

[0129] In some cases, the request includes indicating the NTN as a RAT type of standalone radio access technology (RAT).

[0130] In some cases, UE capability information distinguishes the set of features supported by the UE in NTNs with different track types.

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

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

[0133] In some cases, one or more second containers may include separate containers for NTNs with different track types.

[0134] In some cases, one or more second containers include a shared container that distinguishes the set of features supported by the UE in NTNs with different track types.

[0135] In some cases, a shared container includes at least one of the following: a separate bit map indicating different features supported in NTNs of different orbit types, a separate capability field for different orbit types, or a combination of at least one structure indicating a set of shared features supported in different orbit types and a separate structure indicating different features supported in NTNs of different orbit types.

[0136] In some cases, for NTNs with different track types, one or more second containers differentiate UE support for features associated with 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).

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

[0138] In some cases, the UE capability message includes a shared container that indicates: 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.

[0139] In some cases, the set of common features in a shared container is pre-applied to both TN and NTN networks, and the shared container includes extensions that differentiate between features 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 set of features supported by the UE in the TN and a first portion of a second set of features supported by the UE in the NTN; and at least a second container indicating a second portion of the second set of features supported by the UE in the NTN.

[0141] In some cases, the second container may be limited to different UE capabilities compared to the first container.

[0142] In some cases, the second feature set indicates the set of TN and NTN band combinations in 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 the following: a container for TN and NTN band combinations for different NTN track types, or one or more track-specific containers, each track-specific container indicating the TN and NTN band combination for the corresponding NTN track.

[0144] In some cases, UE capability information implicitly indicates the track associated with a band in a band combination via at least one of the following: a band for each track type defined by the NTN, a set of band combinations defined for each track type, or by repeating the same band number for different track types.

[0145] In some cases, the UE capability message explicitly indicates the track associated with the frequency band in the frequency band combination.

[0146] In some cases, UE capability information indicates that the UE supports features in a frequency band via at least one of the following: NTN-specific frequency band definitions, or indications of existing frequency bands and NTN support capabilities for those frequency bands.

[0147] In some cases, the second feature set indicates the set of TN and NTN band combinations in which the UE supports carrier aggregation. The UE capability message further distinguishes the third feature set supported by the UE in the NTN ground from the second feature set supported by the UE in the NTN. The third feature set indicates the set of TN and NTN band combinations in which the UE supports dual connectivity. The second and third feature sets are included in separate containers in the UE capability message.

[0148] Figure 19 illustrates a method 1900 for transmitting UE capability information via wireless communication by network entities (such as source BS (e.g., BS 102 in Figures 1 and 2 and / or NTN entity 140 in Figure 4)).

[0149] As illustrated, method 1900 begins at step 1910 with the network entity transmitting a request for the capabilities of the user equipment (UE) to the user equipment.

[0150] At step 1920, the network entity receives a UE capability message in response to the request, which distinguishes the set of features supported by the UE in different network types.

[0151] In some cases, the UE capability message distinguishes between the first set of features supported by the UE in a terrestrial network (TN) and the second set of features supported by the UE in a non-terrestrial network (NTN).

[0152] In some cases, the request includes indicating the NTN as a RAT type of standalone radio access technology (RAT).

[0153] In some cases, UE capability information distinguishes the set of features supported by the UE in NTNs with different track types.

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

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

[0156] In some cases, one or more second containers may include separate containers for NTNs with different track types.

[0157] In some cases, one or more second containers include a shared container that distinguishes the set of features supported by the UE in NTNs with different track types.

[0158] In some cases, a shared container includes at least one of the following: a separate bit map indicating different features supported in NTNs of different orbit types, a separate capability field for different orbit types, or a combination of at least one structure indicating a set of shared features supported in different orbit types and a separate structure indicating different features supported in NTNs of different orbit types.

[0159] In some cases, for NTNs with different track types, one or more second containers differentiate UE support for features associated with 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).

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

[0161] In some cases, the UE capability message includes a shared container that indicates: 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.

[0162] In some cases, the set of common features in a shared container is pre-applied to both TN and NTN networks, and the shared container includes extensions that differentiate between features supported in only one of the TN or NTN networks.

[0163] 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 a first portion of a second set of features supported by the UE in the NTN; and at least a second container indicating a second portion of the second set of features supported by the UE in the NTN.

[0164] In some cases, the second container may be limited to different UE capabilities compared to the first container.

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

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

[0167] In some cases, UE capability information implicitly indicates the track associated with a band in a band combination via at least one of the following: a band for each track type defined by the NTN, a set of band combinations defined for each track type, or by repeating the same band number for different track types.

[0168] In some cases, the UE capability message explicitly indicates the track associated with the frequency band in the frequency band combination.

[0169] In some cases, UE capability information indicates that the UE supports features in a frequency band via at least one of the following: NTN-specific frequency band definitions, or indications of existing frequency bands and NTN support capabilities for those frequency bands.

[0170] In some cases, the second feature set indicates the set of TN and NTN band combinations in which the UE supports carrier aggregation. The UE capability message further distinguishes the third feature set supported by the UE in the NTN ground from the second feature set supported by the UE in the NTN. The third feature set indicates the set of TN and NTN band combinations in which the UE supports dual connectivity. The second and third feature sets are included in separate containers in the UE capability message. Status related to a portion of the UE capability information

[0171] In the case of a UE (e.g., UE 604) handing over from a source base station (HO) to a target base station in the network, the source base station may need to know certain UE capabilities related to the target frequency and RAT associated with the target base station. For example, for an NTN to TN handover (e.g., where the UE handovers from an NTN BS to a TN BS), the NTN BS may need to know the TN capabilities or features supported by the UE (e.g., supported bands, subcarrier spacing, bandwidth, etc.) to determine the appropriate target system, frequency, and measurement configuration. In the case of an NTN to TN HO, this means that the NTN BS needs to transmit requests for NTN UE capabilities and TN UE capabilities from the UE via the NTN radio unit (e.g., the request received by UE 604 at 610 in Figure 6). Since the NTN may have a narrow BW (e.g., GEO), requesting both NTN UE capabilities and TN capabilities will cause the UE to consume significant time, frequency, and power resources to transmit this NTN and TN capability information. This issue typically applies to any situation involving mobility, from BS associated with a narrow BW to BS associated with a wider BW (e.g., mobility from an earlier generation to a later generation).

[0172] Therefore, various forms of this application provide techniques to help avoid situations where the UE consumes significant time, frequency, and power resources to transmit UE capability information to the BS associated with a narrow BW. For example, in some cases, such techniques may involve transmitting only a portion of the UE capability information, thereby limiting the amount of UE capability information that needs to be transmitted by the UE (e.g., in the UE capability message transmitted at 615 in Figure 6). Accordingly, by limiting the amount of UE capability information that needs to be transmitted, the UE can reduce the time or power required to transmit UE capability information, thereby reducing power consumption and saving time and frequency resources within the network.

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

[0174] Figure 20 illustrates a method 2000 for transmitting a portion of UE capability information via wireless communication by a UE (such as UE 104 in the wireless communication network 100 of Figure 1 and / or UE 604 illustrated in Figure 6).

[0175] As illustrated, method 2000 begins at step 2010 with the UE generating a partial set of UE capability information. In some cases, as described above, the UE capability information within the partial set of UE capability information may indicate one or more features or capabilities supported by the UE for communication in a network (e.g., TN and / or NTN).

[0176] At step 2020, the UE transmits a partial set of UE capability information to the network entity. In some cases, the UE may transmit a partial set of UE capabilities in a UE capability message (such as the UE capability message transmitted by UE 604 at 615 in FIG. 6). Therefore, in some cases, the UE may use one or more of the structures illustrated in FIG. 7, FIG. 8A8D, FIG. 9, FIG. 11, FIG. 13-15, FIG. 16A-16C, or FIG. 17A-17D to transmit a partial set of UE capability information within the UE capability message. In this case, the partial set of UE capability information indicates the set of features supported by the UE in different network types. Furthermore, in some cases, the partial set of UE capability information distinguishes between 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.

[0177] In some cases, a portion of the UE capability information generated by the UE in block 1802 is related to the UE’s mobility (e.g., the UE’s handover from the source BS to the target BS) and includes at least one of the following: 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.

[0178] In some cases, the partial set of UE capability information generated by the UE at step 2010 includes at least one of the following: one or more supported measurement capabilities, one or more supported mobility capabilities, and one or more supported random access channel (RACH) capabilities (e.g., 2-step RACH capability).

[0179] In some cases, the partial set of UE capability information generated by the UE in block 1802 may include the minimum set of UE capability information that the UE wants to 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).

[0180] In some cases, the UE may receive a trigger instructing the UE to generate either a partial set of UE capability information or a complete set of UE capability information. This trigger may be explicit or implicit. For example, in some cases, the UE may receive a request for UE capabilities from a network entity that explicitly indicates the request is for a partial set of UE capability information. In some cases, the network entity may include a base station (e.g., BS 102 illustrated 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 query message (such as the request received by UE 604 at 610 in Figure 6) or in system information.

[0181] In some cases, for certain RAT network types (e.g., NTN), the UE can be configured to report a partial set of UE capability information unless the request for the UE's capabilities indicates that the request is for the complete set of UE capability information. In this case, in block 1802, the UE can be implicitly triggered to generate a partial set of UE capability information by not receiving a request for the complete set of UE capability information.

[0182] In operational scenarios, after the UE is handed over from the source BS to the target BS, the target BS may subsequently request the UE to transmit 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 following via inter-node messages or network interfaces (e.g., X2 interface, Xn interface, etc.): a partial set of UE capability information, or an indication that the partial set of UE capability information was generated by the source BS.

[0183] Subsequently, once the UE is delivered 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 not included in the partial set of UE capability information. In other cases, the additional set of UE capability information includes the complete set of UE capability information, which includes the UE capability information included in the partial set of UE capability information.

[0184] In some cases, the target BS may request an additional (e.g., complete) set of UE capabilities after completing the handover, which may result in unnecessary steps, as well as power consumption and wasted time and frequency resources. Therefore, in some cases, to avoid the power consumption and wasted time and frequency resources associated with requesting an additional set of UE capability information after the handover is completed, the target BS may alternatively request an additional set of UE capability information during the handover.

[0185] For example, in some cases, the UE may be requested to generate an additional set of UE capability information based on a UE capability request or query. In some cases, the request for the additional set of UE capability information may be included within a delivery command received from the source BS, or the request for the additional set of UE capability information may be multiplexed with the delivery command received from the source BS. In other cases, the UE may be triggered to implicitly generate and transmit an additional set of UE capabilities based on the delivery type. For example, when the delivery type includes NTN to TN delivery, the UE may be pre-triggered to generate and transmit an additional (e.g., complete) set of UE capability information after the completion of the delivery. In this case, the target BS may not need to transmit a request for additional UE capability information after the completion of the delivery, thereby saving time, frequency, and power resources.

[0186] In some cases, when a request for additional UE capability information is received during delivery, the UE may begin generating a UE capability message that includes the additional UE capability information upon receiving the request or after delivery is completed (e.g., after completing the random access procedure with the target BS).

[0187] In some cases, handover from the source BS to the target BS may fail for various reasons. When this happens, the UE can initiate a Radio Resource Control (RRC) re-establishment procedure. In this case, a request for additional UE capability information can be transmitted by the target BS in an RRC message (such as an RRC re-establishment message, RRC reconfiguration message, or RRC recovery message). In some cases, the UE can implicitly trigger the generation of additional UE capability information based on the cell type to which the target BS belongs, rather than the target BS transmitting the request in an RRC message. For example, in some cases, when handover fails, the UE can determine that the target BS belongs to a TN cell. Therefore, in response to the determination that the target BS belongs to a TN cell, the UE can be implicitly triggered to generate an additional set of capability information.

[0188] In some cases, for RRC recovery procedures, requests for additional UE capability information can be transmitted within the RRC recovery message.

[0189] Figure 21 illustrates a method 2100 for transmitting a partial set of UE capability information via wireless communication by network entities (such as source BS (e.g., BS 102 in Figures 1 and 2 and / or NTN entity 140 in Figure 4)).

[0190] As illustrated, method 2100 begins at step 2110 with the source BS transmitting a request for a partial set of UE capability information from the user equipment (UE).

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

[0192] In some cases, a partial set of UE capability information indicates the set of features supported by the UE in different network types.

[0193] In some cases, a portion of the UE capability information distinguishes between the first set of features supported by the UE in terrestrial networks (TN) and the second set of features supported by the UE in non-terrestrial networks (NTN).

[0194] In some cases, a portion of the UE capability information is related to the UE’s mobility and includes at least one of the following: 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 (SCS), or one or more supported bandwidths (BW).

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

[0196] In some cases, a partial set of UE capability information includes: the minimum set of UE capability information that the UE needs to report, and an additional set of UE capability information.

[0197] In some cases, method 2100 also includes the following steps: transmitting a handover command to the UE to hand over the UE from one network entity to another; and transmitting another request to the UE for an additional set of UE capability information.

[0198] In some cases, another request is transmitted within the delivery command, or multiplexed with the delivery command and transmitted together with the delivery command.

[0199] Figure 22 illustrates a method 2200 for transmitting a partial set of UE capability information via wireless communication by network entities (such as target BS (e.g., BS 102 in Figures 1 and 2 and / or NTN entity 140 in Figure 4)).

[0200] As illustrated, method 2200 begins at step 2210 with the target BS obtaining a partial set of UE capability information associated with the user equipment (UE).

[0201] At step 2220, the target BS transmits a request to the UE for an additional set of UE capability information.

[0202] In some cases, a partial set of UE capability information indicates the set of features supported by the UE in different network types.

[0203] In some cases, a portion of the UE capability information distinguishes between the first set of features supported by the UE in terrestrial networks (TN) and the second set of features supported by the UE in non-terrestrial networks (NTN).

[0204] In some cases, a portion of the UE capability information is related to the UE’s mobility and includes at least one of the following: 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 (SCS), or one or more supported bandwidths (BW).

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

[0206] In some cases, a partial set of UE capability information includes: the minimum set of UE capability information that the UE needs to report, and an additional set of UE capability information.

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

[0208] In some cases, the additional set of UE capability information includes the complete set of UE capability information, which in turn includes UE capability information that is included in the partial set of UE capability information.

[0209] In some cases, requests for additional sets of UE capability information are transmitted in the handover command or multiplexed with the handover command.

[0210] In some cases, requests for additional sets of UE capability information are transmitted in Radio Resource Control (RRC) re-establishment messages, RRC reconfiguration messages, or RRC recovery messages.

[0211] In some cases, an additional set of UE capability information is received after the completion of the delivery associated with the UE.

[0212] In some cases, a portion of the UE capability information is received from another network entity. Exemplary wireless communication device

[0213] Figure 23 illustrates various forms of exemplary communication devices. In some instances, communication device 2300 may be a network entity, such as, for example, BS 102 described with respect to Figures 1 and 2 and NTN entity 140 described with respect to Figure 4. In some cases, the network entity may include a source BS, while in other cases, the network entity may include a target BS.

[0214] The communication 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 communication device 2300 via an antenna 2310, such as the various signals described herein. The processing system 2302 may be configured to perform processing functions for the communication device 2300, including processing signals received and / or to be transmitted by the communication device 2300.

[0215] Processing system 2302 includes one or more processors 2320. In various configurations, the one or more processors 2320 may represent one or more of the receive processor 238, transmit processor 220, TX MIMO processor 230, and / or controller / processor 240 as described with respect to FIG. 2. The one or more processors 2320 are coupled to computer-readable media / memory 2330 via bus 2306. In some configurations, computer-readable media / 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 illustrated in FIG. 6, as well as methods 1800 and 2000 described with respect to FIG. 19, FIG. 21, or FIG. 22, or any configuration thereof. Note that references to processor execution functions of communication device 2300 may include one or more processors of communication device 2300 performing that function.

[0216] In the illustrated example, the computer can read the media / memory 2330 storing code (e.g., executable instructions) 2331 for transmission, code 2332 for receiving, and code 2333 for acquisition. Processing of codes 2331-2333 can cause the communication device 2300 to perform one or more of the operations illustrated in FIG. 6, as well as methods 1800 and 2000 described with respect to FIG. 19, FIG. 21, or FIG. 22, or any state therein.

[0217] One or more processors 2320 include circuitry configured to implement (e.g., execute) code stored in computer-readable media / memory 2430, including circuitry 2321 for transmission, circuitry 2322 for reception, and circuitry 2323 for acquisition. Processing using circuitry 2321-2323 can cause communication device 2300 to perform one or more of the operations illustrated in FIG. 6, as well as methods 1800 and 2000 described with respect to FIG. 19, FIG. 21, or FIG. 22, or any manner thereof.

[0218] Various components of communication device 2400 may provide components for performing one or more of the operations illustrated in FIG. 6, as well as methods 1800 and 2000 described with respect to FIG. 19, FIG. 21, or FIG. 22, or any similar configuration thereof. Components for transmission, sending, or output may include transceiver 232 and / or antenna 234 of BS 102 shown in FIG. 2 and / or transceiver 2308 and antenna 2310 of communication device 2300 in FIG. 23. Components for receiving or acquiring may include transceiver 232 and / or antenna 234 of BS 102 shown in FIG. 2 and / or transceiver 2308 and antenna 2310 of communication device 2300 in FIG. 23.

[0219] Figure 24 illustrates various configurations of an exemplary communication device 2400. In some configurations, the communication device 2400 is a user equipment, such as the UE 104 described above with respect to Figures 1 and 2.

[0220] The communication 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 communication device 2400, such as the various signals described herein, via an antenna 2410. The processing system 2402 may be configured to perform processing functions for the communication device 2400, including processing signals received and / or to be transmitted by the communication device 2400.

[0221] Processing system 2402 includes one or more processors 2420. In various configurations, the one or more processors 2420 may represent one or more of the receive processor 258, transmit processor 264, TX MIMO processor 266, and / or controller / processor 280 as described with respect to FIG. 2. The one or more processors 2420 are coupled to computer-readable media / memory 2430 via bus 2406. In some configurations, computer-readable media / 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 methods 1800 and 2000 described with respect to FIG. 18 and FIG. 20, or any configuration thereof. Note that references to processors performing the functions of communication device 2400 may include one or more processors performing that function of communication device 2400.

[0222] In the illustrated example, the computer can read media / memory 2430 to store code (e.g., executable instructions) 2431 for receiving and code 2432 for transmitting. Processing of codes 2431-2432 can cause communication device 2400 to perform one or more of the operations illustrated in FIG. 6, as well as methods 1800 and 2000 described with respect to FIG. 18 and FIG. 20, or any state associated therewith.

[0223] One or more processors 2420 include circuitry configured to implement (e.g., execute) code stored in computer-readable media / memory 2430, including circuitry 2421 for receiving and circuitry 2422 for transmitting. Processing using circuitry 2421-2422 can cause communication device 2400 to perform one or more of the operations illustrated in FIG. 6, as well as methods 1800 and 2000 described with respect to FIG. 18 and FIG. 20, or any manner thereof.

[0224] Various components of the communication device 2400 may provide means for performing one or more of the operations illustrated in FIG. 6, as well as methods 1800 and 2000 described with respect to FIG. 18 and FIG. 20, or any similar forms thereof. For example, means for transmitting, sending, or outputting may include transceiver 254 and / or antenna 252 of UE 104 shown in FIG. 2 and / or transceiver 2408 and antenna 2410 of communication device 2400 in FIG. 24. Means for receiving or acquiring may include transceiver 254 and / or antenna 252 of UE 104 shown in FIG. 2 and / or transceiver 2408 and antenna 2410 of communication device 2400 in FIG. 24. Exemplary terms

[0225] Implementation examples are described in the following numbered clauses:

[0226] Clause 1: A method for wireless communication by a user equipment (UE), comprising the steps of: receiving a request for capabilities of the UE from a network entity; and responding to the request by transmitting UE capability information, the UE capability information distinguishing a set of features supported by the UE in different network types.

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

[0228] Clause 3: The method of Clause 2, wherein the request includes indicating the NTN as a RAT type of standalone radio access technology (RAT).

[0229] Clause 4: The method of any one of Clauses 2-3, wherein the UE capability information distinguishes the set of features supported by the UE in NTNs with different track types.

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

[0231] Clause 6: The method of any one of Clauses 4-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.

[0232] Clause 7: The method of Clause 6, wherein one or more second containers include separate containers for NTNs with different track types.

[0233] Clause 8: The method of Clause 6, wherein one or more second containers include a common container, the common container distinguishing the set of features supported by the UE in NTNs with different track types.

[0234] Clause 9: The method of Clause 8, wherein the common container comprises at least one of the following: a separate bit map indicating different features supported in NTNs of different orbit types, a separate capability field for different orbit types, or a combination of at least one structure indicating a set of common features supported in different orbit types and a separate structure indicating different features supported in NTNs of different orbit types.

[0235] Clause 10: The method of any one of Clauses 6-9, wherein for NTNs with different track types, one or more second containers distinguish UE support for features associated with 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).

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

[0237] Clause 12: The method of any one of Clauses 2-5, wherein the UE capability message includes a shared 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.

[0238] Clause 13: The method of Clause 12, wherein: the common feature set in the common container is pre-applied to both TN and NTN networks; and the common container includes extensions that differentiate features supported in only one of the TN or NTN networks.

[0239] Clause 14: The method of any one of Clauses 2-5, wherein the UE capability message includes: a first container indicating a first set of features supported by the UE in the TN and a first portion of a second set of features supported by the UE in the NTN; and at least a second container indicating a second portion of the second set of features supported by the UE in the NTN.

[0240] Clause 15: The method of Clause 14, wherein the second container is limited to differentiated UE capabilities compared to the first container.

[0241] Clause 16: The method of any one of Clauses 2-5, wherein the second feature set indicates a set of TN and NTN band combinations in which the UE supports at least one of carrier aggregation or dual connectivity.

[0242] Clause 17: The method of Clause 16, wherein the UE capability message includes at least one of the following: a container for TN and NTN band combinations for different NTN track types; or one or more track-specific containers, each track-specific container indicating a TN and NTN band combination for the corresponding NTN track.

[0243] The method of any one of Clauses 18, 16-17, wherein the UE capability message implicitly indicates the track associated with the band in the band combination by at least one of the following: for the band of each track type defined by the NTN, for the set of band combinations defined by each track type, or by repeating the same band number for different track types.

[0244] Clause 19: The method of any one of Clauses 16-17, wherein the UE capability message explicitly indicates the track associated with the frequency band in the frequency band combination.

[0245] Clause 20: The method of any one of Clauses 16-17, wherein the UE capability message indicates that the UE supports a feature in a frequency band by at least one of the following: NTN-specific frequency band definition; or indication of an existing frequency band and NTN support capabilities for that frequency band.

[0246] Clause 21: The method of any one of Clauses 2-5, wherein: the second feature set indicates a set of TN and NTN band combinations in which the UE supports carrier aggregation; the UE capability message further distinguishes a third feature set supported by the UE in the NTN terrestrial from the second feature set supported by the UE in the NTN; the third feature set indicates a set of TN and NTN band combinations in which the UE supports dual connectivity; and the second and third feature sets are included in separate containers in the UE capability message.

[0247] Clause 22: A method for wireless communication by a network entity, comprising the steps of: transmitting a request for capabilities of a user equipment (UE) to a user equipment (UE); and receiving a UE capability message in response to the request, the UE capability message distinguishing a set of features supported by the UE in different network types.

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

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

[0250] Clause 25: The method of any one of Clauses 23-24, wherein the UE capability information distinguishes the set of features supported by the UE in NTNs with different track types.

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

[0252] Clause 27: The method of any one of Clauses 25-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.

[0253] Clause 28: The method of Clause 27, wherein one or more second containers include separate containers for NTNs with different track types.

[0254] Clause 29: The method of Clause 27, wherein one or more second containers include a common container that distinguishes the set of features supported by the UE in NTNs with different track types.

[0255] Clause 30: The method of Clause 29, wherein the common container comprises at least one of the following: a separate bit map indicating different features supported in NTNs of different orbit types, a separate capability field for different orbit types, or a combination of at least one structure indicating a set of common features supported in different orbit types and a separate structure indicating different features supported in NTNs of different orbit types.

[0256] Clause 31: The method of any one of Clauses 27-30, wherein for NTNs with different track types, one or more second containers distinguish UE support for features associated with 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).

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

[0258] Clause 33: The method of Clause 23, wherein the UE capability message includes a shared 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.

[0259] Clause 34: The method of Clause 33, wherein: the common feature set in the common container is pre-applied to both TN and NTN networks; and the common container includes extensions that differentiate features supported in only one of the TN or NTN networks.

[0260] Clause 35: The method of Clause 23, wherein the UE capability message includes: a first container indicating a first set of features supported by the UE in the TN and a first portion of a second set of features supported by the UE in the NTN; and at least a second container indicating a second portion of the second set of features supported by the UE in the NTN.

[0261] Clause 36: The method of Clause 35, wherein the second container is limited to differentiated UE capabilities compared to the first container.

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

[0263] Clause 38: The method of Clause 37, wherein the UE capability message includes at least one of the following: a container for TN and NTN band combinations for different NTN track types, or one or more track-specific containers, each track-specific container indicating a TN and NTN band combination for the corresponding NTN track.

[0264] Clause 39: The method of any one of Clauses 37-38, wherein the UE capability information implicitly indicates the track associated with the band in the band combination by at least one of the following: for the band of each track type defined by the NTN, the set of band combinations defined by each track type, or by repeating the same band number for different track types.

[0265] Clause 40: The method of any one of Clauses 37-38, wherein the UE capability message explicitly indicates the track associated with the frequency band in the frequency band combination.

[0266] Clause 41: The method of any one of Clauses 37-40, wherein the UE capability message indicates that the UE supports a feature in a frequency band by at least one of the following: NTN-specific frequency band definition, or indication of an existing frequency band and NTN support capabilities for that frequency band.

[0267] Clause 42: The method of Clause 23, wherein: the second feature set indicates a set of TN and NTN band combinations in which the UE supports carrier aggregation; the UE capability message further distinguishes a third feature set supported by the UE in the NTN ground from the second feature set supported by the UE in the NTN; the third feature set indicates a set of TN and NTN band combinations in which the UE supports dual connectivity; and the second and third feature sets are included in separate containers in the UE capability message.

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

[0269] Clause 44: The method of Clause 43, wherein a portion of the UE capability information indicates the set of features supported by the UE in different network types.

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

[0271] Clause 46: The method of any one of Clauses 43-45, wherein a portion of the UE capability information is related to the UE’s mobility and includes at least one of the following: 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).

[0272] Clause 47: The method of any one of Clauses 43-46, wherein a portion of the UE capability information includes at least one of the following: one or more supported measurement capabilities; one or more supported mobility capabilities; or one or more supported random access channel (RACH) capabilities.

[0273] Clause 48: The method of any one of Clauses 43-47, wherein a portion of the set of UE capability information comprises: a minimum set of UE capability information to be reported by the UE; and an additional set of UE capability information.

[0274] Clause 49: The method of any one of Clauses 43-48 also includes the following steps: receiving a request for a capability of the UE from a network entity, the request indicating that the request is a partial set of capability information for the UE.

[0275] Clause 50: The method of any one of Clauses 43-49, wherein for certain Radio Access Technology (RAT) network types, the UE is configured to report a partial set of UE capability information, unless the request for the UE's capabilities indicates that the request is for the complete set of UE capability information.

[0276] Clause 51: The method of any one of Clauses 43-50 also includes the following steps: receiving a request from a network entity for an additional set of UE capability information.

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

[0278] Clause 53: The method of Clause 51, wherein the additional set of UE capability information includes the complete set of UE capability information, and the complete set of UE capability information includes UE capability information included in the partial set of UE capability information.

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

[0280] Clause 55: The method of Clause 54, wherein the request is received in or in connection with a delivery order.

[0281] Clause 56: The method of any one of Clauses 54-55, wherein the UE generates an additional set of UE capability information based on the network type to which the target cell belongs.

[0282] Clause 57: The method of any one of Clauses 54-56, wherein the request is received in a Radio Resource Control (RRC) Re-establishment message, an RRC Reconfiguration message, or an RRC Recovery message.

[0283] Clause 58: The method of any one of Clauses 51-57, wherein the UE generates an additional set of UE capability information after the completion of the delivery.

[0284] Clause 59: A method for wireless communication by a network entity, comprising the steps of: transmitting a request for a portion of a set of UE capability information from a user equipment (UE); and receiving a portion of a set of UE capability information from the UE.

[0285] Clause 60: The method of Clause 59, wherein a portion of the UE capability information indicates the set of features supported by the UE in different network types.

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

[0287] Clause 62: The method of any one of Clauses 59-61, wherein a portion of the UE capability information is related to the UE’s mobility and includes at least one of the following: 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).

[0288] Clause 63: The method of any one of Clauses 59-62, wherein a portion of the UE capability information includes at least one of the following: one or more supported measurement capabilities; one or more supported mobility capabilities; or one or more supported random access channel (RACH) capabilities.

[0289] Clause 64: The method of any one of Clauses 59-63, wherein a portion of the set of UE capability information comprises: a minimum set of UE capability information to be reported by the UE; and an additional set of UE capability information.

[0290] Clause 65: The method of any one of Clauses 59-64 also includes the steps of: transmitting a handover command to the UE to hand over the UE from one network entity to another network entity; and transmitting another request to the UE for an additional set of UE capability information.

[0291] Clause 66: The method of Clause 65, wherein another request is transmitted within a delivery order, or multiplexed with a delivery order and transmitted together with a delivery order.

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

[0293] Clause 68: The method of Clause 67, wherein a portion of the UE capability information indicates the set of features supported by the UE in different network types.

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

[0295] Clause 70: The method of any one of Clauses 67-69, wherein a portion of the UE capability information is related to the UE’s mobility and includes at least one of the following: 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).

[0296] Clause 71: The method of any one of Clauses 67-70, wherein a portion of the UE capability information includes at least one of the following: one or more supported measurement capabilities; one or more supported mobility capabilities; or one or more supported random access channel (RACH) capabilities.

[0297] Clause 72: The method of any one of Clauses 67-71, wherein a portion of the set of UE capability information comprises: a minimum set of UE capability information to be reported by the UE; and an additional set of UE capability information.

[0298] Clause 73: The method of any one of Clauses 67-72, wherein the additional set of UE capability information includes UE capability information not included in the partial set of UE capability information.

[0299] Clause 74: The method of any one of Clauses 67-72, wherein the additional set of UE capability information includes the complete set of UE capability information, and the complete set of UE capability information includes UE capability information included in the partial set of UE capability information.

[0300] Clause 75: The method of any one of Clauses 67-74, wherein the request for an additional set of UE capability information is transmitted in a delivery command or multiplexed with a delivery command.

[0301] Clause 76: The method of any one of Clauses 67-75, wherein the request for an additional set of UE capability information is transmitted in a Radio Resource Control (RRC) re-establishment message, an RRC reconfiguration message, or an RRC recovery message.

[0302] Clause 77: The method of any one of Clauses 67-76, wherein an additional set of UE capability information is received after the completion of a delivery associated with the UE.

[0303] Clause 78: The method of any one of Clauses 67-77, wherein a portion of the set of UE capability information is received from another network entity.

[0304] Clause 79: An apparatus comprising: a memory including executable instructions; one or more processors configured to execute the executable instructions and to cause the apparatus to perform any one of Clauses 1-78.

[0305] Clause 80: An apparatus comprising: a component for performing the method of any one of Clauses 1-78.

[0306] Clause 81: A non-transitory computer-readable medium comprising executable instructions, wherein when executed by one or more processors of the device, the executable instructions cause the device to perform any of the methods described in Clauses 1-78.

[0307] Clause 82: A computer program product embodied on a computer-readable storage medium, comprising code for performing any one of the methods in Clauses 1-78. Additional wireless communication network considerations

[0308] The techniques and methods described herein can be used in a variety of wireless communication networks. Although variations may be described herein using terms commonly associated with 3G, 4G, and / or 5G wireless technologies, the variations of the content herein are equally applicable to other communication systems and standards not explicitly mentioned herein.

[0309] Returning to Figure 1, the various states of the content in this case can be executed within the exemplary wireless communication network 100.

[0310] Figure 1 illustrates various exemplary UE 104s, which may more generally include: cellular phones, smartphones, SIP phones, laptops, personal digital assistants (PDAs), satellite radio units, global positioning systems, multimedia devices, video devices, digital audio players, cameras, game consoles, tablet devices, smart devices, wearable devices, vehicles, electricity meters, air pumps, large or small kitchen appliances, medical devices, implants, sensors / actuators, displays, Internet of Things (IoT) devices, always-on (AON) devices, edge processing devices, or other similar devices. UE 104 may also be more generally referred to as a mobile device, wireless device, wireless communication device, station, mobile station, subscriber station, mobile subscriber station, mobile unit, subscriber unit, wireless unit, remote unit, remote device, access terminal, mobile terminal, wireless terminal, remote terminal, mobile phone, and others.

[0311] Figure 1 illustrates various exemplary BS 102s, which may more generally include: NodeBs (nodes), enhanced NodeBs (eNBs), next-generation enhanced NodeBs (ng-eNBs), next-generation NodeBs (gNBs or gNodeBs), access points, base station transceivers, radio base stations, radio transceivers, transceiver functions, transmit / receive points, and others. Each of the BS 102s may provide communication coverage for its 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 the coverage area 110 of a macro cell). BSs may provide communication coverage for, for example, macro cells (covering relatively large geographic areas), pico cells (covering relatively small geographic areas, such as stadiums), femto cells (relatively small geographic areas (e.g., residential areas)), and / or other types of cells.

[0312] Although BS 102 is illustrated as a single communication device in various configurations, it can be implemented in a variety of configurations. For example, one or more elements of the base station can be decomposed into a central unit (CU), one or more distributed units (DU), one or more radio units (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 instance, the various configurations of the base station can be virtualized. More generally, a base station (e.g., BS 102) can include elements located at a single physical location or elements located at various physical locations. In instances where the base station includes elements located at various physical locations, the various elements can each perform functions independently, such that the various elements collectively achieve functions similar to a base station located at a single physical location. In some configurations, a base station including elements located at various physical locations can be referred to as a decomposed radio access network architecture, such as an open RAN (O-RAN) or virtualized RAN (VRAN) architecture.

[0313] Different BSs 102 within the wireless communication network 100 can 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 Evolutionary Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access Network (E-UTRAN)) can be connected to the EPC 160 via a first backhaul link 132 (e.g., S1 interface). A BS 102 configured for 5G (e.g., 5G NR or Next Generation RAN (NG-RAN)) can be connected to the 5GC 190 via a second backhaul link 184. BSs 102 can communicate directly or indirectly (e.g., via EPC 160 or 5GC 190) on a third backhaul link 134 (e.g., X2 interface), which can be wired or wireless.

[0314] Wireless communication network 100 can subdivide the electromagnetic spectrum into various categories, bands, channels, or other characteristics. In some cases, the subdivision is based on wavelength and frequency, where frequency may also be referred to as carrier, subcarrier, frequency channel, tone, or subband. For example, 3GPP currently defines frequency range 1 (FR1) as including 600 MHz–6 GHz, which is often (interchangeably) referred to as “below 6 GHz”. Similarly, 3GPP currently defines frequency range 2 (FR2) as including 26–41 GHz, which is sometimes (interchangeably) referred to as “millimeter wave” (“mmW” or “mmWave”). Base stations configured to communicate using mmWave / near mmWave radio frequency bands (e.g., mmWave base stations, such as BS 180) can utilize beamforming (e.g., 182) with UEs (e.g., 104) to improve path loss and range.

[0315] The communication link 120 between BS 102 and, for example, UE 104 can be via one or more carriers, which can have different bandwidths (e.g., 5, 10, 15, 20, 100, 400, and other MHz), and can be aggregated in various modes. The carriers can be adjacent to each other or can be non-adjacent to each other. The allocation of carriers can be asymmetrical with respect to DL and UL (e.g., more or fewer carriers can be allocated to DL compared to UL).

[0316] The wireless communication system 100 also includes a Wi-Fi AP 150, which communicates with the Wi-Fi station (STA) 152 via a communication link 154 in, for example, unlicensed spectrum of 2.4 GHz and / or 5 GHz.

[0317] Some UEs 104 can communicate with each other using device-to-device (D2D) communication links 158. The D2D communication link 158 can use one or more sideline channels, such as physical sideline broadcast channel (PSBCH), physical sideline explore channel (PSDCH), physical sideline shared channel (PSSCH), and physical sideline control channel (PSCCH).

[0318] EPC 160 may include various functional elements, including: Mobility Management Entity (MME) 162 in the illustrated example, other MMEs 164, Service Gateway 166, Multimedia Broadcast Multicast Service (MBMS) Gateway 168, Broadcast Multicast Service Center (BM-SC) 170, and Packet Data Network (PDN) Gateway 172. MME 162 can communicate with Home Subscriber Server (HSS) 174. MME 162 is the control node that handles signaling between UE 104 and EPC 160. Typically, MME 162 provides bearer and connectivity management.

[0319] Typically, user Internet Protocol (IP) packets are transmitted via Serving Gateway 166, which is itself connected to PDN Gateway 172. PDN Gateway 172 provides IP address allocation and other functions to the UE. PDN Gateway 172 and BM-SC 170 are connected to IP Service 176, which may include, for example, the Internet, intranet, IP Multimedia Subsystem (IMS), Packet Switched (PS) streaming services, and / or other IP services.

[0320] The BM-SC 170 provides functionality for MBMS user service provisioning and delivery. The BM-SC 170 can act as an entry point for MBMS transmissions to content providers, authorize and initiate MBMS bearer services within the Public Land Mobile Network (PLMN), and schedule MBMS transmissions. The MBMS gateway 168 can distribute MBMS traffic to BS 102 belonging to the Multicast-Broadcast Single Frequency Network (MBSFN) area, and can be responsible for communication period management (start / stop) and collecting eMBMS-related billing information.

[0321] 5GC 190 may include various functional elements, including: Access and Mobility Management Function (AMF) 192, other AMFs 193, Communication Management Function (SMF) 194, and User Plane Function (UPF) 195. AMF 192 can communicate with Unified Data Management (UDM) 196.

[0322] AMF 192 is the control node that handles signaling between UE 104 and 5GC 190. AMF 192 provides, for example, Quality of Service (QoS) procedures and communication period management.

[0323] Internet Protocol (IP) packets are transmitted via UPF 195, which connects to IP service 197 and provides IP address allocation for the UE and other functions for 5GC 190. IP service 197 may include, for example, Internet, intranet, IMS, PS streaming service and / or other IP services.

[0324] Returning to Figure 2, various exemplary elements of BS 102 and UE 104 are illustrated, which can be used to implement various forms of the content of this case.

[0325] Regarding the exemplary downlink transmission, BS 102 includes a transmission processor 220, which can receive data from data source 212 and control information from controller / processor 240. The control information can be used for the Entity Broadcast Channel (PBCH), Entity Control Format Indicator Channel (PCFICH), Entity HARQ Indicator Channel (PHICH), Entity Downlink Control Channel (PDCCH), Group Shared PDCCH (GC PDCCH), and other channels. In some instances, the data can be used for the Entity Downlink Shared Channel (PDSCH).

[0326] The transmission processor 220 can process (e.g., encode and symbol map) data and control information separately to obtain data symbols and control symbols. The transmission processor 220 can also generate reference symbols, such as those used for the primary synchronization signal (PSS), secondary synchronization signal (SSS), PBCH demodulation reference signal (DMRS), and channel status information reference signal (CSI-RS).

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

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

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

[0330] Regarding exemplary uplink transmissions, UE 104 also includes a transmission processor 264, which can receive and process data from data source 262 (e.g., for PUSCH) and control information from controller / processor 280 (e.g., for Physical Uplink Control Channel (PUCCH)). Transmission processor 264 can also generate reference symbols for reference signals (e.g., for Sounding Reference Signal (SRS)). Symbols from transmission processor 264 can be pre-encoded by TX MIMO processor 266 (if applicable), further processed by modulators in transceivers 254a-254r (e.g., for SC-FDM), and transmitted to BS 102.

[0331] At BS 102, uplink signals from UE 104 can be received by antennas 234a-t, processed by demodulators in transceivers 232a-232t, detected by MIMO detector 236 (if applicable), and further processed by receiver processor 238 to obtain decoded data and control information transmitted by UE 104. Receiver processor 238 can provide decoded data to data slot 239 and decoded control information to controller / processor 240.

[0332] Memory 242 and 282 can store data and code for BS 102 and UE 104, respectively.

[0333] Scheduler 244 can schedule UEs to perform data transmission on downlink and / or uplink.

[0334] In each of the various states, BS 102 can be described as transmitting and receiving various types of data associated with the methods described herein. In this context, "transmitting" can refer to various mechanisms for outputting data, such as outputting data from data source 212, scheduler 244, memory 242, transmission processor 220, controller / processor 240, TX MIMO processor 230, transceiver 232a-t, antenna 234a-t, and / or other states described herein. Similarly, "receiving" can refer to various mechanisms for acquiring data, such as acquiring data from antenna 234a-t, transceiver 232a-t, RX MIMO detector 236, controller / processor 240, receiver processor 238, scheduler 244, memory 242, and other states described herein.

[0335] In various states, UE 104 can also be described as transmitting and receiving various types of data associated with the methods described herein. In such contexts, "transmitting" can refer to various mechanisms for outputting data, such as outputting data from data source 262, memory 282, transmission processor 264, controller / processor 280, TX MIMO processor 266, transceiver 254a-t, antenna 252a-t, and / or other states described herein. Similarly, "receiving" can refer to various mechanisms for acquiring data, such as acquiring data from antenna 252a-t, transceiver 254a-t, RX MIMO detector 256, controller / processor 280, receiver processor 258, memory 282, and other states described herein.

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

[0337] As described above, Figures 3A, 3B, 3C and 3D illustrate various exemplary configurations of data structures that can be used in the wireless communication network 100 of Figure 1.

[0338] Wireless communication systems can utilize Orthogonal Frequency Division Multiplexing (OFDM) with a Cyclic Prefix (CP) on both the uplink and downlink. Such systems can also support half-duplex operation using Time Division Duplex (TDD). OFDM and Single-Carrier Frequency Division Multiplexing (SC-FDM) divide the system bandwidth (e.g., as illustrated in Figures 3B and 3D) into multiple orthogonal subcarriers. Each subcarrier can be modulated using data. Modulation symbols are transmitted in the frequency domain using OFDM and in the time domain using SC-FDM.

[0339] The wireless communication frame structure can be Frequency Division Duplex (FDD), in which a specific set of subcarriers and subframes within that set are dedicated to either DL or UL. Alternatively, the wireless communication frame structure can be Time Division Duplex (TDD), in which a specific set of subcarriers and subframes within that set are dedicated to both DL and UL.

[0340] In Figures 3A and 3C, the radio communication frame structure is TDD, where D is DL, U is UL, and X is flexible for use between DL and UL. The UE can configure the slot format via the received slot format indicator (SFI) (dynamically via DL control information (DCI) or semi-statically / statically via radio resource control (RRC) signals). In the illustrated example, a 10 ms frame can be divided into 10 equal-sized 1 ms sub-frames. Each sub-frame can include one or more slots. In some instances, each slot can include 7 or 14 symbols, depending on the slot configuration. Sub-frames can also include micro-slots, which typically have fewer symbols compared to the entire slot. Other radio communication technologies may have different frame structures and / or different channels.

[0341] Typically, the number of slots within a subframe can be based on the slot configuration and numerical scheme. For slot configuration 0, different numerical schemes (µ) 0 to 5 consider 1, 2, 4, 8, 16, and 32 slots per subframe, respectively. For slot configuration 1, different numerical schemes 0 to 2 consider 2, 4, and 8 slots per subframe, respectively. Accordingly, for slot configuration 0 and numerical scheme µ, there are 14 symbols / slot and 2µ slots / subframe. The subcarrier spacing and symbol length / duration are functions of the numerical scheme. The subcarrier spacing can be equal to 2µ × 15 kHz, where µ is the numerical scheme from 0 to 5. Thus, numerical scheme µ=0 has a subcarrier spacing of 15 kHz, and numerical scheme µ=5 has a subcarrier spacing of 480 kHz. The symbol length / duration is inversely related to the subcarrier spacing. Figures 3A, 3B, 3C, and 3D provide examples of a slot configuration of 0 with 14 symbols per slot and a numerical scheme of µ=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.

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

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

[0344] Figure 3B illustrates examples of various DL channels within sub-frames of a frame. The physical downlink control channel (PDCCH) carries the DCI within one or more control channel elements (CCEs), each CCE comprising nine RE groups (REGs), each REG comprising four consecutive REs in an OFDM symbol.

[0345] The primary synchronization signal (PSS) can be located within symbol 2 of a specific subframe of the frame. The PSS is used by the UE (e.g., 104 in Figures 1 and 2) to determine the subframe / symbol timing and entity layer identification.

[0346] The Secondary Synchronization Signal (SSS) can be located within symbol 4 of a specific sub-frame of the frame. The SSS is used by the UE to determine the physical layer cell identifier group number and the radio frame timing.

[0347] Based on the entity layer identifier and entity layer cell identifier group number, the UE can determine the entity cell identifier (PCI). Based on the PCI, the UE can determine the location of the aforementioned DMRS. The entity broadcast channel (PBCH) (which carries the main information block (MIB)) can be logically grouped with the PSS and SSS to form a synchronization signal (SS) / PBCH block. The MIB provides the number of RBs and the system frame number (SFN) in the system bandwidth. The entity downlink shared channel (PDSCH) carries user data, broadcast system information not transmitted via the PBCH (such as the system information block (SIB)), and paging messages.

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

[0349] Figure 3D illustrates examples of various UL channels within sub-frames of a frame. The PUCCH can be located as indicated in one configuration. 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 can also be used to carry buffer status reports (BSR), power headroom reports (PHR), and / or UCI. Additional considerations

[0350] The foregoing description is provided to enable any person skilled in the art to implement the various forms described herein. The examples discussed herein are not limited to the scope, applicability, or forms set forth in the claims. Various modifications to these forms will be readily apparent to those skilled in the art, and the general principles defined herein can be applied to other forms. For example, changes can be made to the function and arrangement of the elements discussed without departing from the scope of this application. Various procedures or elements may be omitted, substituted, or added as appropriate in the various examples. For example, the described method may be performed in a different order than that described, and various actions may be added, omitted, or combined. Furthermore, features described with respect to some examples may be combined with those of other examples. For example, an apparatus or method may be implemented using any number of forms set forth herein. Moreover, the scope of this application is intended to cover such apparatus or methods implemented using structures, functions, or structures and functions other than those disclosed herein or different from those disclosed herein. It should be understood that any form of the disclosure herein may be represented by one or more elements of the request.

[0351] The various illustrative logic blocks, modules, and circuits described in connection with this case may be implemented or executed using a general-purpose processor, digital signal processor (DSP), ASIC, field-programmable gate array (FPGA) or other programmable logic device (PLD), individual gate or transistor logic, individual hardware element, or any combination thereof designed to perform the functions described herein. The general-purpose processor may be a microprocessor, but alternatively, the processor may be any commercially available processor, controller, microcontroller, or state machine. The 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 combined with a DSP core, a system-on-a-chip (SoC), or any other such configuration.

[0352] As used herein, the phrase "at least one of" in a list of items refers to any combination of those items, including a single member. For example, "at least one of a, b, or c" is intended to cover a, b, c, ab, ac, bc, and abc, as well as any combination with multiples of the same element (e.g., aa, aaa, aab, aac, abb, acc, bb, bbb, bbc, cc, and ccc, or any other ordering of a, b, and c).

[0353] As used herein, the term "decision" encompasses a wide variety of actions. For example, "decision" can include calculation, operation, processing, deduction, investigation, examination (e.g., examining a table, database, or other data structure), ascertainment, etc. Furthermore, "decision" can include receiving (e.g., receiving information), accessing (e.g., accessing data in memory), etc. Additionally, "decision" can include parsing, selecting, choosing, creating, etc.

[0354] The methods disclosed herein include one or more actions for implementing the methods. These actions can be interchanged without departing from the scope of the request. In other words, unless a specific order of actions is specified, the order and / or use of a particular action can be modified without departing from the scope of the request. Furthermore, the various operations of the methods described above can be performed by any suitable component capable of performing the corresponding function. Components can include various hardware and / or software elements and / or modules, including but not limited to circuits, application-specific integrated circuits (ASICs), or processors.

[0355] The appended claims are not intended to be limited to the forms shown herein, but are given the full scope consistent with the language of the claims. Within the claims, unless expressly stated otherwise, references to elements in the singular form are not intended to mean "one and only one," but rather "one or more." Unless expressly stated otherwise, the term "some" refers to one or more. No element of the claims is to be interpreted pursuant to Article 18, Paragraph 8 of the Implementing Regulations of the Patent Law, unless the element is expressly described using the phrase "component for...". All structural and functional equivalents of the elements of the various forms described herein, which are expressly incorporated herein by reference and intended to be included by the claims, are known to or will be known later by a person skilled in the art. Furthermore, nothing disclosed herein is intended to be offered to the public, whether or not such disclosure is expressly stated in the claims.

[0356] 100: Wireless communication network 102:BS 102': Small cells 104:UE 110: Geographical coverage area 110': Coverage area 110a: Coverage Area 110b: Coverage Area 120: Communication Link 132: First reload link 134: Third reload link 140: NTN Entity 150: Wi-Fi AP 152: Wi-Fi Station (STA) 154: Communication Link 158:D2D communication link 160:EPC 162: Management Entity (MME) 164: Other MMEs 166: Service Gateway 168: Multimedia Broadcast Multicast Service (MBMS) Gateway 170: Broadcast Multicast Service Center (BM-SC) 172: PDN Gateway 174: Home Subscriber Server (HSS) 176: IP Service 180:BS 182: Beamforming 182': Transmission direction 182'': Receive direction / transmit direction 184: Second reload link 190:5GC 192: Access and Mobility Management Functions (AMF) 193: Other AMF 194: Communication Management Function (SMF) 195: User Plane Function (UPF) 196: Unified Data Management (UDM) 197: IP Service 212: Source 220: Transmission Processor 230: Transfer (TX) Multiple-Input Multiple-Output (MIMO) Processor 232a: Transceiver 232t: Transceiver 234a: Antenna 234t: Antenna 236: MIMO Detector 238: Receiver Processor 239: Data Slot 240: Controller / Processor 242: Memory 244: Scheduler 252a: Antenna 252r: Antenna 254a: Transceiver 254r: Transceiver 256: MIMO Detector 258: Receiver Processor 260: Data Slot 262: Source 264: Transmission Processor 266:TX MIMO processor 280: Controller / Processor 282: Memory 300: Schematic diagram 330: Schematic diagram 350: Schematic diagram 380: Schematic diagram 400: Wireless communication network 414: Communication Link 416: Communication Link 418: Communication Link 602: Network Entity 604:UE 610: Steps 615: Steps 700: First Structure 702: UE Capability Message 704: First Container 706: Second Container 800A: First variant structure 800B: Second variant structure 800C: Third variant structure 800D: Fourth Variant Structure 802A:TN container 802B:TN container 802C:TN container 802D:TN container 804A: First NTN Container 804B: Shared NTN container 804C: Shared NTN container 804D: Shared NTN container 806A: Second NTN Container 806B: First Metaimage 806C: First NTN Feature Field 806D: Shared Feature Fields 808C: Second NTN Feature Field 808D: First track type specific field 810D: Second track type specific field 900: Second Structure 902: UE Capability Message 904: Shared container 906: Extension 1002: Shared Container 1004: Extension 1100: Third Structure 1102: UE Capability Message 1104: Shared Container 1106: Extension 1108: Second Container 1202:TN Base Station 1204: TN carrier 1206: First NTN Base Station 1208: First NTN carrier 1210: Second NTN Base Station 1212: Second NTN carrier 1214: Third NTN Base Station 1216: Fourth NTN Base Station 1300: Fourth Structure 1302: UE Capability Message 1304: First Container 1306: Second Container 1308: Third Container 1310: Combination of TN and NTN frequency bands 1400: Fifth Structure 1402: UE Capability Message 1404: First Container 1406: Part 1408: Combination of TN and NTN frequency bands 1500: Sixth Structure 1502: UE Capability Message 1504: First Container 1506: Part 1508: Combination of TN and NTN frequency bands 1510: Second Container 1512: Third Container 1514: Combination of TN and NTN frequency bands 1602: UE Capability Message 1604: Shared container 1606: List of Frequency Band Combinations 1608: The first element set 1610: Second-bit set 1702: UE Capability Message 1704: First Container 1706: List of First Frequency Band Combinations 1708: Second Container 1710: Second Frequency Band Combination List 1712: First element set 1714: Second-bit set 1800: Method 1810: Steps 1820: Steps 1900: Method 1910: Steps 1920: Steps 2000: Method 2010: Steps 2020: Steps 2100: Method 2110: Steps 2120: Steps 2200: Method 2210: Steps 2220: Steps 2300: Communication equipment 2302: Processing System 2306: Busbar 2308: Transceiver 2310: Antenna 2320: Processor 2321: Circuit system used for transmission 2322: Circuit system for receiving 2323: Circuit system used for acquisition 2330: Computer-readable media / memory 2331: Code used for transmission 2332: Code used for receiving 2333: The code used to obtain 2400: Communication equipment 2402: Processing System 2406: Busbar 2408: Transceiver 2410: Antenna 2420: Processor 2421: Circuit system for receiving 2422: Circuit system used for transmission 2430: Computer-readable media / memory 2431: Code used for receiving 2432: Code used for transmission D: Downlink DUE: Delay GW1: Gate GW2: Gate U: Uplink Uu: Link X: Flexible

[0357] Domestic storage information (please note in order of storage institution, date, and number) none Overseas storage information (please note in the order of storage country, institution, date, and number) none

Claims

1. A method for wireless communication by a user equipment (UE), comprising the steps of: receiving a request for capabilities of the UE from a network entity; and responding to the request by transmitting a UE capability message, the UE capability message distinguishing a set of features supported by the UE in different network types, wherein the UE capability message distinguishes a first set of features supported by the UE in a terrestrial network (TN) and a second set of features supported by the UE in a non-terrestrial network (NTN), wherein the UE capability message includes a common container indicating: the first set of features supported by the UE in the TN; and the second set of features supported by the UE in the NTN, and wherein a common set of features in the common container is pre-applied to both the TN network and the NTN network; and the common container includes an extension distinguishing features supported in only one of the TN or NTN.

2. The method according to claim 1, wherein the claim includes indicating the NTN as a RAT type of a separate Radio Access Technology (RAT).

3. According to the method of request item 1 or 2, wherein the UE capability information distinguishes the set of features supported by the UE in NTNs with different track types.

4. According to the method of claim 3, wherein the different orbit types include two or more of the following: 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 according to request item 1, wherein the second feature set indicates a set of TN and NTN frequency band combinations in which the UE supports at least one of carrier aggregation or dual connectivity.

6. A method for wireless communication by a network entity, comprising the steps of: transmitting a request for capabilities of a user equipment (UE) to a user equipment (UE); and receiving a UE capability message in response to the request, the UE capability message distinguishing a set of features supported by the UE in different network types, wherein the UE capability message distinguishes a first set of features supported by the UE in a terrestrial network (TN) and a second set of features supported by the UE in a non-terrestrial network (NTN), and wherein the UE capability message includes a common container indicating: the first set of features supported by the UE in the TN; and the second set of features supported by the UE in the NTN, and wherein a common set of features in the common container is pre-applied to both the TN and NTN networks; and the common container includes an extension distinguishing features supported in only one of the TN or NTN networks.

7. The method according to claim 6, wherein the claim includes indicating the NTN as a RAT type of a separate Radio Access Technology (RAT).

8. According to the method of request item 6 or 7, wherein the UE capability message distinguishes the set of features supported by the UE in NTNs with different track types.

9. The method according to claim 8, wherein the different orbit types include two or more of the following: 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. The method according to claim 6, wherein the second feature set indicates a set of TN and NTN band combinations in which the UE supports at least one of carrier aggregation or dual connectivity.

11. A user equipment (UE), comprising: A component for receiving a request for the capabilities of a UE from a network entity; The system also includes components for transmitting a UE capability message in response to the request, the UE capability message distinguishing between sets of features supported by the UE in different network types, wherein the UE capability message distinguishes between a first set of features supported by the UE in a terrestrial network (TN) and a second set of features supported by the UE in a non-terrestrial network (NTN), wherein the UE capability message includes a common container indicating: the first set of features supported by the UE in the TN; and the second set of features supported by the UE in the NTN, and wherein a common set of features in the common container is pre-applied to both the TN and NTN networks; and the common container includes an extension that distinguishes between features supported in only one of the TN or NTN networks.

12. The user equipment (UE) according to request item 11, the UE further includes a component for performing the method described in any one of requests 2 to 5.

13. A network entity, comprising: A component for transmitting a request for the capabilities of a user equipment (UE); The system includes a component for receiving a UE capability message in response to the request, the UE capability message distinguishing between sets of features supported by the UE in different network types, wherein the UE capability message distinguishes between a first set of features supported by the UE in a terrestrial network (TN) and a second set of features supported by the UE in a non-terrestrial network (NTN), and wherein the UE capability message includes a common container indicating: the first set of features supported by the UE in the TN; and the second set of features supported by the UE in the NTN, and wherein a common set of features in the common container is pre-applied to both the TN and NTN networks; and the common container includes an extension that distinguishes between features supported in only one of the TN or NTN networks.

14. The user equipment (UE) according to request item 13, the UE further includes a component for performing the method described in any one of requests 7 to 10.

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

Images