Multiple transmit and receive point operation

Abstract

Transmissions supporting multiple Hybrid Automatic Repeat Request Acknowledgments (HARQ-ACKs) within a single time slot may include encoding a first HARQ-ACK and a second HARQ-ACK within that single time slot for transmission to a base station. The first HARQ-ACK may be transmitted via a first Physical Uplink Control Channel (PUCCH), and the second HARQ-ACK may be transmitted via a second PUCCH. Based on encoding the first and second HARQ-ACKs within that single time slot, one or more additional uplink (UL) signals that conflict with at least one of the first and second HARQ-ACKs within that single time slot can be responded to based on the UE's configuration.

Description

Technical Field

[0001] This application relates to wireless communication systems in general, and includes multiple transmit and receive point (TRP) operations. Background Technology

[0002] Wireless mobile communication technologies use various standards and protocols to transmit data between base stations and wireless mobile devices. Wireless communication system standards and protocols may include 3GPP Long Term Evolution (LTE) (e.g., 4G) or New Radio (NR) (e.g., 5G); the Institute of Electrical and Electronics Engineers (IEEE) 802.16 standard, commonly referred to by the industry organization as Global Microwave Access Interoperability (WiMAX); and the IEEE 802.11 standard for Wireless Local Area Networks (WLANs), commonly referred to by the industry organization as Wi-Fi. In the 3GPP Radio Access Network (RAN) of an LTE system, base stations may include RAN nodes such as Evolved Universal Terrestrial Radio Access Network (E-UTRAN) Node B (also commonly referred to as Evolved Node B, Enhanced Node B, eNodeB, or eNB) and / or the Radio Network Controller (RNC) in the E-UTRAN, which communicates with wireless communication equipment called User Equipment (UE). In fifth-generation (5G) wireless RANs, RAN nodes may include 5G nodes, NR nodes (also known as Next Generation Node B or g NodeB (gNB)).

[0003] The RAN uses Radio Access Technology (RAT) to communicate between RAN nodes and UEs. The RAN may include Global System for Mobile Communications (GSM), Enhanced Data Rate GSM Evolution (EDGE) RAN (GERAN), Universal Terrestrial Radio Access Network (UTRAN), and / or E-UTRAN, which provides access to communication services through the core network. Each RAN operates according to a specific 3GPP RAT. For example, GERAN implements the GSM and / or EDGE RAT, UTRAN implements the Universal System for Mobile Communications (UMTS) RAT or other 3GPP RATs, E-UTRAN implements the LTE RAT, and NG-RAN implements the 5G RAT. In some deployments, E-UTRAN may also implement the 5G RAT.

[0004] 5G NR frequency bands can be divided into two distinct frequency ranges. Frequency range 1 (FR1) includes bands below 6 GHz, some of which may be used by previous standards but could potentially be extended to cover new spectrum offerings from 410 MHz to 7125 MHz. Frequency range 2 (FR2) includes bands from 24.25 GHz to 52.6 GHz. The millimeter wave (mmWave) bands in FR2 have a shorter range but higher available bandwidth than those in FR1. Those skilled in the art will recognize that these frequency ranges, presented by way of example, may vary over time or in different regions. Attached Figure Description

[0005] To facilitate identification of any particular element or action being discussed, one or more of the most significant digits in the reference numerals refer to the drawing number in which the element was first introduced.

[0006] Figure 1 An aspect of the subject matter according to one implementation scheme is shown.

[0007] Figure 2 An aspect of the subject matter according to one implementation scheme is shown.

[0008] Figure 3 A method according to one implementation scheme is shown.

[0009] Figure 4 A method according to one implementation scheme is shown.

[0010] Figure 5 A method according to one implementation scheme is shown.

[0011] Figure 6 A system according to one implementation is shown.

[0012] Figure 7 An infrastructure setup according to one implementation scheme is shown.

[0013] Figure 8 A platform based on one implementation scheme is shown.

[0014] Figure 9 An apparatus according to one embodiment is shown.

[0015] Figure 10 An exemplary interface according to one implementation is shown.

[0016] Figure 11 The components according to one implementation are shown. Detailed Implementation

[0017] 3GPP Release 16 (Rel-16) includes enhancements to support multiple transmit and receive point (TRP) operations, including: 1. Multiple downlink control information (DCI) multiple TRP (MTRP) operations (MDCI MTRP), which may include two TRPs that each schedule independent downlink control information (DCI) and two physical downlink shared channels (PDSCHs) for UE reception; and 2. Single DCI multiple TRP operations (SDCI MTRP), which includes: a. Spatial domain multiplexing (SDM) scheme, which includes two fully overlapping PDSCHs of the same transport block (TB); b. Frequency domain multiplexing (FDMScheme A), which includes a single PDSCH transmitted from two TRPs in an interleaved manner (i.e., only one TB is transmitted); c. FDMScheme B, which includes two PDSCHs transmitted in an interleaved manner from a TRP (i.e., two TBs in the same TB are transmitted), d. Time Division Multiplexing (TDMScheme A), which includes intra-slot PDSCH repetition of the same TB, and e. Scheme 4, which includes up to 16 inter-slot PDSCH repetitions.

[0018] As further discussed throughout this disclosure, several issues remain despite the enhancements associated with MTRP described above. First, uplink control information (UCI) multiplexing is discussed for the case of two physical uplink control channels (PUCCHs) with hybrid automatic repeat request acknowledgment (HARQ-ACK) within a single timeslot. Second, the generation of a Type I HARQ codebook for TDMSchemeA is discussed. For background, TDMSchemeA includes two PDSCHs within a timeslot, both having the same duration and similar resource allocation, differing only in that their start symbols have a constant offset. Furthermore, the Type I HARQ codebook can be a static (or semi-static) codebook comprising all HARQ-ACK data for any possible PDSCH reception. While such a codebook may have significant overhead, it also allows for simpler generation by the UE.

[0019] Third, the default Transport Configuration Indicator (TCI) for CCSs with MDCI MTRP and the default TCI for CCSs with SDCI MTRP. Specifically, the default beam can be particularly useful when the UE does not have enough time to switch beams or if the beam is not configured (in which case the default beam is used). Each of these issues and solutions will now be discussed in turn.

[0020] Figure 1A time slot environment 100 is shown, which has multiple HARQ-ACKs (i.e., HARQ-ACK 106 and HARQ-ACK 108) via two PUCCHs within a single time slot 112 on timeline 110, as well as PUSCH 102 and PUCCH 104. For multi-DCI-based multi-TRP operations, two separate HARQ-ACK PUCCHs within a time slot are supported under the following three schemes: 1. Long PUCCH + Long PUCCH; 2. Long PUCCH + Short PUCCH; and 3. Short PUCCH + Long PUCCH. For the purposes of this disclosure, a long PUCCH can be considered as a PUCCH with a length between four and fourteen symbols and more than two UCI bits, while a short PUCCH can be considered as a PUCCH with a length of one or two symbols and one or two UCI bits.

[0021] It is worth noting that prior to Rel-16, multiple HARQ-ACKs within a time slot were not supported. Aside from recent changes in support, allowing multiple HARQ-ACKs introduces complexity for the UE regarding how to handle this support. Specifically, it raises decisions about how to multiplex each transmission, which transmissions (if any) to discard, etc. For example, regarding... Figure 1 For example, the UE will attempt to determine how to combine / multiplex the two HARQ-ACKs (or discard one of them), then attempt to multiplex (or discard) another PUCCH (i.e., PUCCH 104), and finally determine how to combine (or discard) PUSCH 102 with another multiplexed PUCCH that was not discarded. However, it should be noted that Figure 1 The exemplary time slot environment described is merely one implementation and is therefore not intended to be limiting in any way. For example, as an alternative to or supplement to PUSCH 102 and / or PUCCH 104, time slot 112 may optionally or additionally include scheduling requests or other uplink signaling.

[0022] Therefore, to address these issues, the following methods can be implemented: 1. When a UE is configured to transmit more than one HARQ-ACK PUCCH within a time slot, the UE may not be configured to handle other PUCCH transmissions that conflict within the same time slot; 2. When a UE is configured to transmit more than one HARQ-ACK PUCCH within a time slot, the UE may not be configured to handle PUSCH transmissions that conflict within the same time slot; 3. When a UE is configured to transmit more than one HARQ-ACK PUCCH simultaneously within a time slot, the UE may be configured to handle other PUCCH transmissions that conflict within the same time slot. In this implementation, the application, based on the general UCI multiplexing rules determined by the PUCCH resources (i.e., 1. determination regarding the multiplexing or discarding of two HARQ-ACKs, 2. determination regarding the multiplexing or discarding of additional PUCCHs, and 3. determination regarding the multiplexing or discarding of additional PUSCHs or other uplink signaling (e.g., scheduling requests)), has the following alternatives: a. multiplexing two HARQ-ACKs; b. multiplexing only the first HARQ-ACK if the PUCCH payload is limited; and c. multiplexing only the second HARQ-ACK if the PUCCH payload is limited; and 4. when the UE is configured to transmit more than one HARQ-ACK PUCCH simultaneously in a time slot, the UE is configured to have conflicting PUCCH and PUSCH transmissions in the same time slot. In such implementations, the same general UCI multiplexing rules as described above apply (i.e., 1. determination regarding the multiplexing or discarding of both HARQ-ACKs, 2. determination regarding the multiplexing or discarding of the additional PUCCH, and 3. determination regarding the multiplexing or discarding of the additional PUSCH or other uplink signaling (e.g., scheduling requests)). Alternatively, the UE may use one of the following options to perform PUCCH and PUSCH multiplexing: a. multiplexing both HARQ-ACKs; b. multiplexing only the first HARQ-ACK if the PUSCH payload is limited; or c. multiplexing only the second HARQ-ACK if the PUSCH payload is limited.

[0023] As background for the generation of the MTRP Type I codebook for TDMSchemeA, the Type I HARQ-ACK codebook is a semi-static HARQ-ACK codebook based on the following: 1. Possible PDSCH-HARQ-ACK timing, including a configured K1 offset. Specifically, for each HARQ-ACK, the gNB can schedule the offset between the PDSCH and when the associated HARQ-ACK is transmitted by the UE. The gNB can then decode the received HARQ-ACK during the scheduled time slot. Additionally, K1 includes a table provided to the UE by the gNB. The gNB can then indicate to the UE, within this table, a specific value, position, or timing applied to the offset (i.e., when a HARQ-ACK in response to the PDSCH can be transmitted, or a range of that time); and 2. Configured start and length indicators (SLIVs) for possible time-slotted PDSCHs, which allows the gNB to indicate to the UE the precise position of the PDSCH in the time domain. Again, the SLIV includes a table and is provided to the UE by the gNB. The position of the PDSCH is also dynamically indicated via DCI (note that only the first PDSCH in TDMSchemeA is configured under SLIV). Additionally, if the transmission is valid, the HARQ-ACK is retained in the codebook.

[0024] Figure 2 A TDMSchemeA environment 200 comprising two PDSCHs (i.e., PDSCH 202 and PDSCH 204) within time slot 208 on timeline 206 is shown. In this TDMSchemeA, the offset from the end of the first PDSCH 202 to the beginning of the second PDSCH 204 is statically configured by Radio Resource Control (RRC). Notably, the two PDSCHs (i.e., PDSCH 202 and PDSCH 204) appear identical because they have the same relative position in frequency and the same duration in time. The only perceptible difference is the offset between the start symbol offsets of each PDSCH, which is statically configured.

[0025] For each TDMSchemeA Single DCI (SDCI) Multiple TRP (MTRP) schedule and Type I HARQ-ACK codebook, HARQ-ACK is retained via the following three options: 1. Only when the first PDSCH (e.g., PDSCH 202) is valid; 2. Only when the second PDSCH (e.g., PDSCH 204) is valid; or 3. Only when both the first and second PDSCHs are valid. It is worth noting that, for the purposes of this disclosure, a PDSCH is considered valid if it does not conflict with any uplink (UL) signal.

[0026] As background to the default TCI for cross-carrier scheduling (CCS) with multiple DCI or single DCI multiple TRP operations, the UE may not know the quasi-coordinated location (QCL) relationship for receiving the corresponding PDSCH before detecting the PDCCH. It is noteworthy that if the attributes of the channel transmitting the symbol of the second antenna port can be inferred from the channel transmitting the symbol of the first antenna port, then the first and second antenna ports can be quasi-coordinated. Furthermore, the default TCI can be used to indicate the QCL, thereby allowing the UE to receive / decode the PDSCH corresponding to the PDCCH. Additionally, the default TCI can be determined using a control resource set (CORESET) associated with the scheduling cell, which includes a set of physical resources for carrying the PDCCH / DCI and a set of parameters. Furthermore, the CORESET may include an identifier (ID) parameter and a parameter called CORESETPoolIndex, which includes 0, 1, or 2 values ​​that can be used to determine the default TCI (always including two values ​​when MDCI MTRP is supported).

[0027] As a general procedure for determining the default TCI (or default beam), the scheduling cell can initiate the process by transmitting the scheduling DCI. The UE can then decode the scheduling DCI in a specific CORESET, which includes the CORESETPoolIndex parameter decoded as part of the decoding of the scheduling DCI. Now, to find the default beam (or, in this case, the default TCI), the UE looks at the latest PDCCH monitoring slot, where the UE can monitor multiple CORESETs. A subset (possibly all) of these CORESETs can have the same CORESETPoolIndex parameter value as the scheduling DCI. From all CORESETs with the same CORESETPoolIndex parameter value as the scheduling DCI, the UE can select the CORESET with the lowest ID and use the corresponding beam as the default beam.

[0028] In more specific cases, the default TCI for cross-carrier scheduling (CCS) with multiple DCI and multiple TRP operations can be determined by utilizing the following solutions: 1. Follow the scheduling cell (i.e., the cell sending the scheduling DCI), which can always be configured with an MDCI MTRP such that the default TCI includes the CORESET with the lowest ID in the latest PDCCH monitoring slot and the same CORESETPoolIndex value as the scheduling DCI; or 2. Follow the scheduled cell (i.e., the cell sending the PDSCH) such that: a. if the scheduled cell is configured with an MDCI MTRP (i.e., two CORESETPoolIndex values), the default TCI includes the CORESET with the lowest ID in the latest PDCCH monitoring slot and the same CORESETPoolIndex value as the scheduling DCI; or b. if the scheduled cell is not configured with an MDCI MTRP. For MTRP, the default TCI includes: i. the CORESET with the lowest ID in the latest PDCCH monitoring slot (and assumes the same beam for PDSCH without considering the scheduling CORESETPoolIndex); or ii. the active PDSCH TCI with the lowest index in the scheduled cell.

[0029] Regarding the default TCI for CCS with single DCI and multiple TRP operations, the following solutions can be used: 1. The default TCI is the TCI code point active on the PDSCH with the lowest ID, which has two TCI states in the scheduled cell; 2. The default TCI is the TCI code point active on the PDSCH with the lowest ID, which has two TCI states in the scheduled cell; or 3. When no TCI code point has two TCI states: a. The default TCI is the TCI code point active on the PDSCH with the lowest ID; b. The default TCI is the CORESET with the lowest ID; or c. The default TCI is the CORESET with the lowest ID in the latest PDCCH monitoring slot. It is worth noting that the code point can include a numerical value defining the code space. Furthermore, the code point can include a single character or an indication format.

[0030] Figure 3A method 300 for supporting the transmission of multiple HARQ-ACKs within a single time slot is illustrated. In block 302, method 300 encodes a first Hybrid Automatic Repeat Request Acknowledgment (HARQ-ACK) and a second HARQ-ACK within a single time slot for transmission to a base station, the first HARQ-ACK being transmitted via a first Physical Uplink Control Channel (PUCCH) and the second HARQ-ACK being transmitted via a second PUCCH. In block 304, based on the encoding of the first and second HARQ-ACKs within the single time slot, method 300 responds to one or more additional uplink (UL) signals that conflict with at least one of the first and second HARQ-ACKs within the single time slot, based on the UE's configuration.

[0031] For example, in one embodiment, the UE configuration may include avoiding the transmission of additional UL signals via PUCCH that would conflict with at least one of the first HARQ-ACK and the second HARQ-ACK within the single time slot. In another embodiment, the UE configuration may include avoiding the transmission of additional UL signals via PUSCH that would conflict with at least one of the first HARQ-ACK and the second HARQ-ACK within the single time slot.

[0032] In another embodiment, method 300 may further include, when the UE configuration includes transmitting an additional UL signal via PUCCH that would conflict with at least one of the first HARQ-ACK and the second HARQ-ACK in the single time slot, multiplexing both the first HARQ-ACK and the second HARQ-ACK, and multiplexing the additional UL signal via PUCCH with the multiplexed first HARQ-ACK and the second HARQ-ACK.

[0033] In another embodiment, method 300 may further include: when the UE configuration includes transmitting an additional UL signal via PUCCH that will conflict with at least one of the first HARQ-ACK and the second HARQ-ACK in the single time slot, multiplexing both the first HARQ-ACK and the second HARQ-ACK; if the payload of the UL signal via PUCCH is limited, multiplexing the first HARQ-ACK with the UL signal via PUCCH; or if the payload of the UL signal via PUCCH is limited, multiplexing the second HARQ-ACK with the UL signal via PUCCH.

[0034] In another embodiment, method 300 may further include, when the UE configuration includes transmitting a first additional UL signal via PUCCH and a second additional UL signal via PUSCH that would conflict with at least one of the first HARQ-ACK and the second HARQ-ACK in the single time slot, multiplexing both the first HARQ-ACK and the second HARQ-ACK, multiplexing the first additional UL signal via PUCCH with the multiplexed first HARQ-ACK and the second HARQ-ACK, and multiplexing the second additional UL signal via PUSCH with the multiplexed first HARQ-ACK and the second HARQ-ACK and the multiplexed first additional UL signal via PUCCH.

[0035] In another embodiment, method 300 may further include: when the UE configuration includes transmitting a first additional UL signal via PUCCH and a second additional UL signal via PUSCH that would conflict with at least one of the first HARQ-ACK and the second HARQ-ACK in the single time slot, multiplexing both the first HARQ-ACK and the second HARQ-ACK; if the payload of the second additional UL signal via PUSCH is limited, then multiplexing the first HARQ-ACK with the second additional UL signal via PUSCH; or, if the payload of the second additional UL signal via PUSCH is limited, then multiplexing the second HARQ-ACK with the second additional UL signal via PUSCH.

[0036] Figure 4 A method 400 for generating a Type I Hybrid Automatic Repeat Request Acknowledgment (HARQ-ACK) codebook for TDMScheme A is illustrated. In block 402, method 400 generates a Type I Hybrid Automatic Repeat Request Acknowledgment (HARQ-ACK) codebook for Time Domain Multiplexing Scheme A (TDMScheme A). For example, the Type I HARQ-ACK codebook for TDMScheme A may include a semi-static HARQ-ACK codebook. In block 404, method 400 decodes a first DL signal received via a first PDSCH and a second DL signal received via a second PDSCH. In block 406, method 400 processes a K1 offset table associated with determining when at least one HARQ-ACK is transmitted in response to decoding the first DL signal received via the first PDSCH and the second DL signal received via the second PDSCH. The K1 offset table may be received from a base station (e.g., gNB). Then, the base station can indicate to the UE within this table the specific value, location, or timing applied to the offset (i.e., when or when a HARQ-ACK in response to the PDSCH can be transmitted, or the range of that time).

[0037] In block 408, method 400 processes a start and length indicator (SLIV) table for a time-slotted PDSCH, which is associated with determining the precise time-domain location of at least one of a first DL signal received via a first PDSCH and a second DL signal received via a second PDSCH. The SLIV table can be received from the base station. The SLIV table allows the base station to indicate the precise time-domain location of the PDSCH to the UE. In block 410, method 400 retains a HARQ-ACK in the generated HARQ-ACK codebook based on the validity of one or both of the first and second PDSCHs, wherein a given PDSCH is valid when it does not conflict with any uplink (UL) signal.

[0038] For example, in one embodiment, retaining HARQ-ACK in the codebook based on the validity of one or both of the first PDSCH and the second PDSCH includes retaining HARQ-ACK in the codebook only when the first PDSCH is valid. In another embodiment, retaining HARQ-ACK in the codebook based on the validity of one or both of the first PDSCH and the second PDSCH includes retaining HARQ-ACK in the codebook only when the second PDSCH is valid. In yet another embodiment, retaining HARQ-ACK in the codebook based on the validity of one or both of the first PDSCH and the second PDSCH includes retaining HARQ-ACK in the codebook only when both the first PDSCH and the second PDSCH are valid.

[0039] Figure 5 A method 500 for determining a default TCI for decoding / receiving downlink signals via the PDSCH is illustrated. In block 502, method 500 decodes a first downlink (DL) signal received from a scheduling cell via the physical downlink control channel (PDCCH), wherein decoding includes determining a multiple transmit and receive point (MTRP) configuration for both the scheduling cell and the scheduled cell scheduled by the scheduling cell. For example, the scheduling cell may always support MDCI MTRP, while the scheduled cell may support SDCI MTRP or MDCI MTRP. In block 504, method 500 determines a default transport configuration indicator (TCI) for cross-carrier scheduling (CCS) with MTRP based at least in part on the determined MTRP configuration of either or both of the scheduling cell and the scheduled cell.

[0040] For example, in one implementation, when the default TCI is determined to be at least partially based on the DCI MTRP configuration of the scheduled cell, the default TCI includes the control resource set (CORESET) with the lowest identifier (ID) and CORESETPoolIndex value in the most recent PDCCH monitoring slot, the CORESETPoolIndex value including the same value as the CORESETPoolIndex value of the scheduled DCI. In another implementation, the default TCI is determined to be at least partially based on the MTRP configuration of the scheduled cell.

[0041] In another implementation, when the determined MTRP configuration of the scheduled cell supports multi-DCI MTRP, the default TCI includes the control resource set (CORESET) with the lowest identifier (ID) and CORESETPoolIndex value in the most recent PDCCH monitoring slot, where the CORESETPoolIndex value includes the same value as the CORESETPoolIndex value of the scheduled DCI. In another implementation, when the MTRP configuration of the scheduled cell does not support multi-DCI MTRP, the default TCI also includes: the control resource set (CORESET) with the lowest identifier (ID) in the most recent PDCCH monitoring slot, or the activated PDSCH TCI with the lowest index in the scheduled cell.

[0042] In one implementation, when both the scheduled cell and the determined MTRP configuration of the scheduling cell support a single DCI MTRP, the default TCI includes an activated TCI code point for the PDSCH with the lowest identifier (ID), which has two TCI states in the scheduling cell.

[0043] In one implementation, when both the scheduled cell and the scheduled cell's determined MTRP configuration support a single DCIMTRP and neither the activated TCI code point for PDSCH in the scheduled cell nor the activated TCI code point for PDSCH in the scheduled cell includes two TCI states, the default TCI includes: the activated TCI code point for PDSCH in the scheduled cell or the activated TCI code point for PDSCH in the scheduled cell with the lowest identifier (ID), the control resource set (CORESET) with the lowest ID, or the CORESET with the lowest ID in the latest PDCCH monitoring slot.

[0044] Finally, in block 506, method 500 uses the determined default TCI to decode the second DL signal received via the Physical Downlink Shared Channel (PDSCH) that corresponds to the first DL signal received via the PDCCH.

[0045] Figure 6 Exemplary architectures of network system 600 according to various implementations are shown. The following description is provided for example system 600 operating in combination with LTE system standards and 5G or NR system standards provided by 3GPP technical specifications. However, the exemplary implementations are not limited in this respect, and the implementations can be applied to other networks that benefit from the principles described herein, such as future 3GPP systems (e.g., sixth generation (6G)) systems, IEEE 802.16 protocols (e.g., WMAN, WiMAX, etc.), etc.

[0046] like Figure 6 As shown, system 600 includes UE 622 and UE 620. In this example, UE 622 and UE 620 are shown as smartphones (e.g., handheld touchscreen mobile computing devices that can connect to one or more cellular networks), but may also include any mobile or non-mobile computing device, such as consumer electronics devices, mobile phones, smartphones, feature phones, tablets, wearable computing devices, personal digital assistants (PDAs), pagers, wireless handheld devices, desktop computers, laptops, in-vehicle infotainment (IVI), in-vehicle entertainment (ICE) devices, instrument clusters (ICs), head-up displays (HUDs), onboard diagnostics (OBD) devices, dashtop mobile equipment (DME), mobile data terminals (MDTs), electronic engine management systems (EEMS), electronic / engine electronic control units (ECUs), electronic / engine electronic control modules (ECMs), embedded systems, microcontrollers, control modules, engine management systems (EMS), connected or “smart” appliances, MTC devices, M2M, IoT devices, etc.

[0047] In some implementations, UE 622 and / or UE 620 may be IoT UEs, which may include a network access layer designed to utilize low-power IoT applications with short-lived UE connections. IoT UEs may utilize technologies such as M2M or MTC to exchange data with MTC servers or devices via PLMN, ProSe, or D2D communication, sensor networks, or IoT networks. M2M or MTC data exchange may be machine-initiated data exchange. An IoT network describes interconnected IoT UEs, which may include uniquely identifiable embedded computing devices (within the internet infrastructure) with short-lived connections. IoT UEs may execute background applications (e.g., keeping track of activity messages, status updates, etc.) to facilitate connectivity within the IoT network.

[0048] UE 622 and UE 620 can be configured to connect to an access node or radio access node (shown as (R)AN 608), for example, communicatively coupled. In embodiments, (R)AN 608 can be an NG RAN or SG RAN, E-UTRAN, or a legacy RAN such as UTRAN or GERAN. As used herein, the term "NG RAN," etc., can refer to (R)AN 608 operating in an NR or SG system, and the term "E-UTRAN," etc., can refer to (R)AN 608 operating in an LTE or 4G system. UE 622 and UE 620 utilize connections (or channels) (shown as connection 604 and connection 602, respectively), each connection including a physical communication interface or layer (discussed in further detail below).

[0049] In this example, connections 604 and 602 are air interfaces for communication coupling and are compatible with cellular communication protocols such as GSM, CDMA, PTT, POC, UMTS, 3GPP LTE, SG, NR, and / or any other communication protocols discussed herein. In an implementation, UE 622 and UE 620 may also exchange communication data directly via ProSe interface 610. ProSe interface 610 may alternatively be referred to as sidelink (SL) interface 110 and may include one or more logical channels, including but not limited to PSCCH, PSSCH, PSDCH, and PSBCH.

[0050] UE 620 is shown configured to access AP 612 (also known as a "WLAN node," "WLAN," "WLAN terminal," "WT," etc.) via connection 624. Connection 624 may include local wireless connectivity, such as a connection consistent with any IEEE 802.11 protocol, where AP 612 will include Wi-Fi. ®( ) router. In this example, AP 612 may be connected to the Internet but not to the core network of the wireless system (described in further detail below). In various implementations, UE 620, (R)AN 608, and AP 612 may be configured to utilize LWA operation and / or LWIP operation. LWA operation may involve UE 620 in RRC_CONNECTED being configured by RAN node 614 or RAN node 616 to utilize the radio resources of LTE and WLAN. LWIP operation may involve UE 620 using WLAN radio resources (e.g., connection 624) via IPsec protocol tunneling to authenticate and encrypt packets (e.g., IP packets) transmitted through connection 624. IPsec tunneling may include encapsulating the entire original IP packet and adding a new packet header to protect the original header of the IP packet.

[0051] (R)AN 608 may include one or more AN nodes, such as RAN node 614 and RAN node 616, that implement connection 604 and connection 602. As used herein, the terms “access node,” “access point,” etc., can describe equipment that provides radio baseband functionality for data and / or voice connections between the network and one or more users. These access nodes may be referred to as BS, gNB, RAN node, eNB, NodeB, RSU, TRxP, or TRP, etc., and may include ground stations (e.g., terrestrial access points) or satellite stations that provide coverage within a geographic area (e.g., a cell). As used herein, the terms “NG RAN node,” etc., can refer to a RAN node (e.g., gNB) operating in an NR or SG system, while the terms “E-UT RAN node,” etc., can refer to a RAN node (e.g., eNB) operating in an LTE or 4G system 600. According to various implementation schemes, RAN node 614 or RAN node 616 may be implemented as one or more of dedicated physical devices such as macro cell base stations and / or low-power (LP) base stations for providing smaller coverage areas, smaller user capacity or higher bandwidth compared to macro cells.

[0052] In some implementations, all or part of RAN node 614 or RAN node 616 may be implemented as one or more software entities running on a server computer as part of a virtual network, which may be referred to as CRAN and / or Virtual Baseband Unit Pool (vBBUP). In these implementations, CRAN or vBBUP may implement RAN function partitioning, such as PDCP partitioning, where the RRC and PDCP layers are operated by CRAN / vBBUP, while other L2 protocol entities are operated by individual RAN nodes (e.g., RAN node 614 or RAN node 616); MAC / PHY partitioning, where the RRC, PDCP, RLC, and MAC layers are operated by CRAN / vBBUP, and the PHY layer is operated by individual RAN nodes (e.g., RAN node 614 or RAN node 616); or “lower PHY” partitioning, where the upper portion of the RRC, PDCP, RLC, MAC, and PHY layers is operated by CRAN / vBBUP, and the lower portion of the PHY layer is operated by individual RAN nodes. This virtualization framework allows idle processor cores of RAN node 614 or RAN node 616 to execute other virtualized applications. In some specific implementations, each RAN node can represent a connection via each F1 interface ( Figure 6 (Not shown) Individual gNB-DUs connected to the gNB-CU. In these specific implementations, the gNB-DU may include one or more remote radio head units or RFEMs, and the gNB-CU may be operated by a server (not shown) located in (R)AN 608 or by a server pool in a manner similar to CRAN / vBBUP. Additionally or alternatively, one or more of RAN nodes 614 or 616 may be next-generation eNBs (ng-eNBs), which are RAN nodes that provide E-UTRA user plane and control plane protocol termination to UE 622 and UE 620 and are connected to the SGC via the ng interface (discussed below). In V2X scenarios, one or more of RAN nodes 614 or 616 may be RSUs or act as RSUs.

[0053] The term "roadside unit" or "RSU" can refer to any traffic infrastructure entity used for V2X communication. An RSU can be implemented in or by a suitable RAN node or a stationary (or relatively stationary) UE, wherein an RSU implemented in or by a UE can be referred to as a "UE-type RSU," an RSU implemented in or by an eNB can be referred to as an "eNB-type RSU," an RSU implemented in or by a gNB can be referred to as a "gNB-type RSU," and so on. In one example, an RSU is a computing device coupled to radio frequency circuitry located on the roadside, which provides connectivity support to passing vehicle UEs (vUEs). An RSU may also include internal data storage circuitry for storing intersection map geometry, traffic statistics, media, and applications / software for sensing and controlling ongoing vehicle and pedestrian traffic. An RSU can operate on the 5.9 GHz Direct Near Range Communication (DSRC) band to provide extremely low-latency communication required for high-speed events, such as collision avoidance and traffic warnings. Alternatively or in addition to this, the RSU may operate on the cellular V2X band to provide the aforementioned low-latency communications and other cellular communication services. Alternatively or in addition to this, the RSU may operate as a Wi-Fi hotspot (2.4 GHz band) and / or provide connectivity to one or more cellular networks to provide uplink and downlink communications. Some or all of the computing device and the RSU's radio frequency circuitry may be packaged in a weather-resistant package suitable for outdoor installation and may include a network interface controller to provide wired connectivity (e.g., Ethernet) to traffic signal controllers and / or backhaul networks.

[0054] RAN node 614 and / or RAN node 616 may terminate the air interface protocol and may be the first point of contact for UE 622 and UE 620. In some implementations, RAN node 614 and / or RAN node 616 may perform various logical functions of (R)AN 608, including but not limited to Radio Network Controller (RNC) functions such as radio bearer management, uplink and downlink dynamic radio resource management and data packet scheduling, and mobility management.

[0055] In the implementation, UE 622 and UE 620 may be configured to communicate with each other or with RAN node 614 and / or RAN node 616 on a multi-carrier communication channel using OFDM communication signals, according to various communication technologies such as, but not limited to, OFDMA communication technology (e.g., for downlink communication) or SC-FDMA communication technology (e.g., for uplink and ProSe or sidelink communication), although the scope of the implementation is not limited in this respect. The OFDM signal may include multiple orthogonal subcarriers.

[0056] In some implementations, the downlink resource grid can be used for downlink transmissions from RAN node 614 and / or RAN node 616 to UE 622 and UE 620, while uplink transmissions can utilize similar techniques. The grid can be a time-frequency grid, referred to as a resource grid or time-frequency resource grid, which represents the physical resources in the downlink within each time slot. This time-frequency plane representation is common practice for OFDM systems, making radio resource allocation intuitive. Each column and row of the resource grid corresponds to an OFDM symbol and an OFDM subcarrier, respectively. The duration of the resource grid in the time domain corresponds to a time slot in a radio frame. The smallest time-frequency unit in the resource grid is represented as a resource element. Each resource grid comprises multiple resource blocks that describe the mapping of certain physical channels to resource elements. Each resource block comprises a set of resource elements; in the frequency domain, this can represent the minimum amount of resources currently available for allocation. Such resource blocks are used to transmit several different physical downlink channels.

[0057] According to various implementations, UE 622 and UE 620, as well as RAN node 614 and / or RAN node 616, transmit (e.g., transmit and receive) data via licensed media (also referred to as “licensed spectrum” and / or “licensed band”) and unlicensed shared media (also referred to as “unlicensed spectrum” and / or “unlicensed band”). Licensed spectrum may include channels operating in the frequency range of approximately 400 MHz to approximately 3.8 GHz, while unlicensed spectrum may include a 5 GHz band.

[0058] To operate in unlicensed spectrum, UEs 622 and 620, along with RAN node 614 or RAN node 616, may use LAA, eLAA, and / or feLAA mechanisms. In these specific implementations, UEs 622 and 620, along with RAN node 614 or RAN node 616, may perform one or more known media sensing and / or carrier sensing operations to determine whether one or more channels in the unlicensed spectrum are unavailable or otherwise occupied before transmission in the unlicensed spectrum. Media / carrier sensing operations may be performed according to a Listen-After-Speak (LBT) protocol.

[0059] LBT is a mechanism by which equipment (e.g., UE 622 and UE 620, RAN node 614 or RAN node 616, etc.) senses a medium (e.g., a channel or carrier frequency) and transmits when that medium is sensed to be idle (or when a specific channel in that medium is sensed to be unoccupied). The medium sensing operation may include CCA, which utilizes at least ED to determine the presence of other signals on the channel in order to determine whether the channel is occupied or idle. This LBT mechanism allows cellular / LAA networks to coexist with existing systems in unlicensed spectrum and with other LAA networks. ED may include sensing RF energy in the intended transmission band over a period of time and comparing the sensed RF energy with a predefined or configured threshold.

[0060] Typically, existing systems in the 5GHz band are WLANs based on IEEE 802.11 technology. WLANs employ a contention-based channel access mechanism called CSMA / CA. Here, when a WLAN node (e.g., a mobile station (MS) such as UE 622, AP612, etc.) intends to transmit, the WLAN node can first perform CCA before transmitting. Additionally, in cases where more than one WLAN node senses the channel as idle and transmits simultaneously, a backoff mechanism is used to avoid collisions. This backoff mechanism can be a counter randomly introduced within the CWS, which increases exponentially upon collision and resets to a minimum value upon successful transmission. The LBT mechanism designed for LAA is somewhat similar to WLAN's CSMA / CA. In some specific implementations, the LBT process for DL ​​or UL transmission bursts (including PDSCH or PUSCH transmissions) can have a variable-length LAA contention window between the X and Y ECCA time slots, where X and Y are the minimum and maximum values ​​of the LAA's CWS. In one example, the minimum CWS for LAA transmission can be 9 microseconds (µs); however, the size of the CWS and MCOT (e.g., transmission burst) can be based on government regulatory requirements.

[0061] The LAA mechanism is built upon the CA technology of LTE-Advanced systems. In CA, each aggregated carrier is called a CC. A CC can have a bandwidth of 1.4MHz, 3MHz, 5MHz, 10MHz, 15MHz, or 20MHz, and a maximum of five CCs can be aggregated, thus the maximum aggregated bandwidth is 100MHz. In FDD systems, the number of aggregated carriers can differ for DL ​​and UL, where the number of UL CCs is equal to or less than the number of DL component carriers. In some cases, individual CCs can have different bandwidths than the other CCs. In TDD systems, the number of CCs and the bandwidth of each CC are usually the same for DL ​​and UL.

[0062] The CA also includes individual serving cells to provide individual CCs. The coverage of serving cells can differ, for example, because CCs on different frequency bands will experience different path losses. The primary serving cell, or PCell, provides PCCs for both UL and DL and handles activities related to RRC and NAS. Other serving cells are called SCells, and each SCell provides individual SCCs for both UL and DL. SCCs can be added and removed as needed, while changing the PCC may require the UE to undergo a handover. In LAA, eLAA, and feLAA, some or all of the SCells can operate in unlicensed spectrum (referred to as "LAA SCells"), and LAA SCells are assisted by PCells operating in licensed spectrum. When a UE is configured to have more than one LAA SCell, the UE can receive UL grants on the configured LAA SCells, indicating different PUSCH start positions within the same subframe.

[0063] The PDSCH carries user data and higher-layer signaling to UEs 622 and 620. Among other information, the PDCCH carries information about the transmission format and resource allocation related to the PDSCH channel. It can also inform UEs 622 and 620 about the transmission format, resource allocation, and HARQ information related to the uplink shared channel. Typically, downlink scheduling (allocating control and shared channel resource blocks to UE 620 within the cell) can be performed at either RAN node 614 or RAN node 616 based on channel quality information fed back from either UE 622 or UE 620. Downlink resource allocation information can be transmitted on the PDCCH used (e.g., allocated to) each of UEs 622 and UE 620.

[0064] PDCCH uses CCEs to transmit control information. Before being mapped to resource elements, the complex-valued symbols of the PDCCH can first be organized into quadruplets, which can then be arranged using a sub-block interleaver for rate matching. One or more of these CCEs can be used to transmit each PDCCH, where each CCE can correspond to nine sets, called REGs, each with four physical resource elements. Four Quadrature Phase Shift Keying (QPSK) symbols can be mapped to each REG. Depending on the DCI size and channel conditions, one or more CCEs can be used to transmit the PDCCH. Four or more different PDCCH formats defined in LTE with different numbers of CCEs (e.g., aggregation levels, L=1, 2, 4, or 8) can exist.

[0065] Some implementations may use the concept of resource allocation for control channel information, which is an extension of the above concept. For example, some implementations may utilize EPDCCH, which uses PDSCH resources for control information transmission. One or more ECCEs may be used to transmit EPDCCH. Similarly, each ECCE may correspond to a set of nine, each consisting of four physical resource elements, called EREG. In some cases, an ECCE may have a different number of EREGs.

[0066] RAN node 614 or RAN node 616 may be configured to communicate with each other via interface 630. In embodiments where system 600 is an LTE system (e.g., when CN 606 is an EPC), interface 630 may be an X2 interface. The X2 interface may be defined between two or more RAN nodes connected to the EPC (e.g., two or more eNBs, etc.), and / or between two eNBs connected to the EPC. In some specific implementations, the X2 interface may include an X2 user plane interface (X2-U) and an X2 control plane interface (X2-C). X2-U may provide flow control mechanisms for user packets transmitted via the X2 interface and may be used to transmit information about the delivery of user data between eNBs. For example, X2-U may provide specific sequence number information about user data transmitted from MeNB to SeNB; information about the successful in-order delivery of PDCP PDUs from SeNB to UE 622 for user data; information about PDCP PDUs not delivered to UE 622; information about the current minimum expected buffer size at SeNB for transmitting user data to the UE; and so on. The X2-C provides LTE intra-eNB access mobility functions, including context transmission from the source eNB to the destination eNB, user plane transmission control, load management functions, and inter-cell interference coordination functions.

[0067] In implementations where system 600 is an SG or NR system (e.g., when CN 606 is an SGC), interface 630 may be an Xn interface. The Xn interface is defined between two or more RAN nodes connected to the SGC (e.g., two or more gNBs, etc.), between a RAN node 614 (e.g., a gNB) connected to the SGC and an eNB, and / or between two eNBs connected to the 5GC (e.g., CN 606). In some specific implementations, the Xn interface may include an Xn user plane (Xn-U) interface and an Xn control plane (Xn-C) interface. Xn-U provides non-guaranteed delivery of user plane PDUs and supports / provides data forwarding and flow control functions. Xn-C provides management and error handling functions for managing the functionality of the Xn-C interface; mobility support for UE 622 in connected modes (e.g., CM-CONNECTED) includes functions for managing UE mobility in connected modes between one or more RAN nodes 614 or RAN nodes 616. Mobility support may include context transfer from the old (source) serving RAN node 614 to the new (destination) serving RAN node 616; and control of the user plane tunnel between the old (source) serving RAN node 614 and the new (destination) serving RAN node 616. The Xn-U protocol stack may include a transport network layer built on top of the Internet Protocol (IP) transport layer, and a GTP-U layer on top of the UDP and / or IP layers for carrying user plane PDUs. The Xn-C protocol stack may include an application layer signaling protocol (referred to as the Xn Application Protocol (Xn-AP)) and a transport network layer built on top of SCTP. SCTP may be on top of the IP layer and provides guaranteed delivery of application layer messages. In the transport IP layer, point-to-point transmission is used to deliver signaling PDUs. In other specific implementations, the Xn-U protocol stack and / or the Xn-C protocol stack may be the same as or similar to the user plane and / or control plane protocol stacks shown and described herein.

[0068] (R)AN 608 is shown as a communication-coupled ground to the core network—in this embodiment, communication-coupled to CN 606. CN 606 may include one or more network elements 632 configured to provide various data and telecommunications services to customers / subscribers (e.g., users of UE 622 and UE 620) connected to CN 606 via (R)AN 608. Components of CN 606 may be implemented in a single physical node or in separate physical nodes, including components for reading and executing instructions from machine-readable or computer-readable media (e.g., non-transitory machine-readable storage media). In some embodiments, NFV may be used to virtualize any or all of the aforementioned network node functions via executable instructions stored in one or more computer-readable storage media (described in further detail below). A logical instance of CN 606 may be referred to as a network slice, and a logical instance of a portion of CN 606 may be referred to as a network subslice. NFV architectures and infrastructure may be used to virtualize one or more network functions onto physical resources comprising a combination of industry-standard server hardware, storage hardware, or switches (or alternatively, performed by proprietary hardware). In other words, an NFV system can be used to perform a virtual or reconfigurable concrete implementation of one or more EPC components / functions.

[0069] Generally, application server 618 can be a component that provides IP bearer resources for applications to use with the core network (e.g., UMTS PS domain, LTE PS data service, etc.). Application server 618 can also be configured to support one or more communication services for UE 622 and UE 620 via EPC (e.g., VoIP sessions, PTT sessions, group communication sessions, social networking services, etc.). Application server 618 can communicate with CN 606 via IP communication interface 636.

[0070] In this implementation, CN 606 may be an SGC, and (R)AN 116 may be connected to CN 634 via NG interface 606. In this implementation, NG interface 634 may be divided into two parts: an NG user plane (NG-U) interface 626, which carries traffic data between RAN node 614 or RAN node 616 and the UPF; and an S1 control plane (NG-C) interface 628, which is the signaling interface between RAN node 614 or RAN node 616 and the AMF.

[0071] In one implementation, CN 606 may be an SG CN, while in other implementations, CN 606 may be an EPC. When CN 606 is an EPC, (R)AN 116 may be connected to CN 606 via S1 interface 634. In one implementation, S1 interface 634 may be divided into two parts: an S1 user plane (S1-U) interface 626, which carries traffic data between RAN node 614 or RAN node 616 and the S-GW; and an S1-MME interface 628, which is the signaling interface between RAN node 614 or RAN node 616 and the MME.

[0072] Figure 7 Examples of infrastructure equipment 700 according to various implementation schemes are shown. Infrastructure equipment 700 may be implemented as a base station, radio head unit, RAN node, AN, application server, and / or any other element / device discussed herein. In other examples, infrastructure equipment 700 may be in or implemented by a UE.

[0073] Infrastructure equipment 700 includes application circuitry 702, baseband circuitry 704, one or more radio front-end modules 706 (RFEM), memory circuitry 708, a power management integrated circuit (shown as PMIC 710), a power tee circuitry 712, network controller circuitry 714, a network interface connector 720, satellite positioning circuitry 716, and user interface circuitry 718. In some embodiments, infrastructure equipment 700 may include additional components such as memory / storage devices, displays, cameras, sensors, or input / output (I / O) interfaces. In other embodiments, these components may be included in more than one device. For example, the circuitry may be individually included in more than one device for CRAN, vBBU, or other similar specific implementations. Application circuitry 702 includes, but is not limited to, one or more processors (or processor cores), cache memory, and one or more low-dropout regulators (LDOs), an interrupt controller, and serial interfaces such as SPI, I... 2The application circuit 702 may include a C or general-purpose programmable serial interface module, a real-time clock (RTC), a timer-counter including an interval timer and a watchdog timer, general-purpose input / output (I / O or IO), a memory card controller such as a Secure Digital (SD) Multimedia Card (MMC) or similar, a Universal Serial Bus (USB) interface, a Mobile Industry Processor Interface (MIPI) interface, and a Joint Test Access Group (JTAG) test access port. The processor (or core) of the application circuit 702 may be coupled to or may include a memory / storage element and may be configured to execute instructions stored in the memory / storage device to enable various applications or operating systems to run on the infrastructure apparatus 700. In some specific implementations, the memory / storage element may be on-chip memory circuitry that may include any suitable volatile and / or non-volatile memory, such as DRAM, SRAM, EPROM, EEPROM, flash memory, solid-state memory, and / or any other type of memory device technology, such as those discussed herein.

[0074] The processor of application circuit 702 may include, for example, one or more processor cores (CPU), one or more application processors, one or more graphics processing units (GPUs), one or more Reduced Instruction Set Computing (RISC) processors, one or more Acorn RISC machine (ARM) processors, one or more Complex Instruction Set Computing (CISC) processors, one or more digital signal processors (DSPs), one or more FPGAs, one or more PLDs, one or more ASICs, one or more microprocessors or controllers, or any suitable combination thereof. In some embodiments, application circuit 702 may include or may be a dedicated processor / controller for operation according to the various embodiments herein. As an example, the processor of application circuit 702 may include one or more Intel Pentium processors. ® Core ® or Xeon ® Processor; Advanced MicroDevices (AMD) Ryzen ® Processor, Accelerated Processing Unit (APU) or Epyc ® Processor; ARM-based processors licensed by ARM Holdings, Ltd., such as the ARM Cortex-A series processors and ThunderX2 processors provided by Cavium™, Inc. ®; MIPS-based designs from MIPS Technologies, Inc., such as the MIPS Warrior P-class processor; etc. In some implementations, the infrastructure equipment 700 may not utilize the application circuitry 702 and may instead include a dedicated processor / controller to process, for example, IP data received from the EPC or 5GC.

[0075] In some embodiments, application circuitry 702 may include one or more hardware accelerators, which may be microprocessors, programmable processing devices, etc. These hardware accelerators may include, for example, computer vision (CV) and / or deep learning (DL) accelerators. For example, programmable processing devices may be one or more field-programmable devices (FPDs), such as field-programmable gate arrays (FPGAs); programmable logic devices (PLDs), such as complex PLDs (CPLDs), high-capacity PLDs (HCPLDs); ASICs, such as structured ASICs; programmable SoCs (PSoCs); and so on. In such embodiments, the circuitry of application circuitry 702 may include logic blocks or logic architectures, and other interconnect resources that can be programmed to perform various functions such as processes, methods, functions, etc., as discussed in the various embodiments herein. In such embodiments, the circuitry of application circuitry 702 may include memory cells (e.g., erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), flash memory, static memory (e.g., static random access memory (SRAM), antifuse, etc.)) for storing logic blocks, logic architectures, data, etc., in lookup tables (LUTs). Baseband circuitry 704 may be implemented, for example, as a soldered substrate comprising one or more integrated circuits, a single-package integrated circuit soldered to a main circuit board, or a multi-chip module containing two or more integrated circuits.

[0076] User interface circuitry 718 may include one or more user interfaces designed to enable a user to interact with infrastructure equipment 700 or peripheral component interfaces, wherein the peripheral component interfaces are designed to enable peripheral components to interact with infrastructure equipment 700. User interfaces may include, but are not limited to, one or more physical or virtual buttons (e.g., a reset button), one or more indicators (e.g., light-emitting diodes (LEDs)), a physical keyboard or keypad, a mouse, a touchpad, a touchscreen, a speaker or other audio transmitting device, a microphone, a printer, a scanner, a headset, a display screen or display device, etc. Peripheral component interfaces may include, but are not limited to, non-volatile memory ports, universal serial bus (USB) ports, audio jacks, power interfaces, etc.

[0077] Radio front-end module 706 may include a millimeter-wave (mmWave) radio front-end module (RFEM) and one or more sub-millimeter-wave radio frequency integrated circuits (RFICs). In some embodiments, the one or more sub-millimeter-wave RFICs may be physically separated from the millimeter-wave RFEM. The RFIC may include connectors to one or more antennas or antenna arrays, and the RFEM may be connected to multiple antennas. In another embodiment, both millimeter-wave and sub-millimeter-wave radio functions may be implemented in the same physical radio front-end module 706 that combines both millimeter-wave antennas and sub-millimeter-wave components.

[0078] The memory circuitry 708 may include one or more of the following: volatile memory, including dynamic random access memory (DRAM) and / or synchronous dynamic random access memory (SDRAM); and non-volatile memory (NVM), including high-speed electrically erasable memory (commonly referred to as "flash memory"), phase-change random access memory (PRAM), magnetoresistive random access memory (MRAM), etc., and may be combined with Intel... ® and Micron ® A three-dimensional (3D) XPOINT memory. The memory circuit 708 can be implemented as one or more of the following: a solder-in packaged integrated circuit, a socket memory module, and an insert memory card.

[0079] The PMIC 710 may include a voltage regulator, surge protector, power alarm detection circuitry, and one or more backup power sources, such as batteries or capacitors. The power alarm detection circuitry can detect one or more of a power outage (undervoltage) and a power surge (overvoltage) condition. The power tee circuit 712 can provide power drawn from the network cable to provide both power and data connectivity to the infrastructure equipment 700 using a single cable.

[0080] Network controller circuitry 714 may provide connectivity to a network using standard network interface protocols such as Ethernet, GRE-tunneled Ethernet, Multiprotocol Label Switching (MPLS)-based Ethernet, or some other suitable protocol. Network connectivity may be provided to / from infrastructure equipment 700 via a physical connection via network interface connector 720, which may be an electrical connection (typically referred to as a "copper interconnect"), an optical connection, or a wireless connection. Network controller circuitry 714 may include one or more dedicated processors and / or FPGAs for communicating using one or more of the aforementioned protocols. In some implementations, network controller circuitry 714 may include multiple controllers for providing connectivity to other networks using the same or different protocols.

[0081] Positioning circuit 716 includes circuitry for receiving and decoding signals transmitted / broadcast by a positioning network of a Global Navigation Satellite System (GNSS). Examples of navigation satellite constellations (or GNSS) include the U.S. Global Positioning System (GPS), Russia's Global Navigation System (GLONASS), the European Union's Galileo system, China's BeiDou Navigation Satellite System, regional navigation systems, or GNSS augmentation systems (e.g., using the Indian constellation (NAVIC), Japan's Quasi-Zenith Satellite System (QZSS), France's Doppler orbit chart and satellite integrated radio positioning (DORIS), etc.). Positioning circuit 716 includes various hardware components (e.g., hardware devices such as switches, filters, amplifiers, antenna elements, etc.) for facilitating OTA communication to communicate with components of the positioning network, such as navigation satellite constellation nodes. In some embodiments, positioning circuit 716 may include a micro-technology (micro PNT) IC for positioning, navigation, and timing, which performs position tracking / estimation using a master timing clock in the absence of GNSS assistance. The positioning circuit 716 may also be part of or interact with the baseband circuit 704 and / or the radio front-end module 706 to communicate with nodes and components of the positioning network. The positioning circuit 716 may also provide location data and / or time data to the application circuit 702, which can use the data to synchronize operations with various infrastructures, etc. Figure 7 The components shown can communicate with each other using interface circuitry, which may include any number of bus and / or interconnect (IX) technologies, such as Industry Standard Architecture (ISA), Extended ISA (EISA), Peripheral Component Interconnect (PCI), Peripheral Component Interconnect Extended (PCix), PCI Express (PCie), or any number of other technologies. The bus / IX may be a proprietary bus, for example, used in a SoC-based system. Other bus / IX systems, such as I... 2 Interfaces include C-type interface, SPI interface, point-to-point interface, and power bus, etc.

[0082] Figure 8 Examples of platform 800 according to various embodiments are shown. In embodiments, computer platform 800 may be adapted to function as a UE, application server, and / or any other element / device discussed herein. Platform 800 may include any combination of the components shown in the examples. Components of platform 800 may be implemented as integrated circuits (ICs), portions of ICs, discrete electronic devices, or other modules, logic, hardware, software, firmware, or combinations thereof adapted within computer platform 800, or may be implemented as components otherwise integrated within the chassis of a larger system. Figure 8 The block diagram is intended to show a high-level view of the components of the computer platform 800. However, some of the components shown may be omitted, additional components may be present, and different arrangements of the components shown may occur in other specific implementations.

[0083] Application circuit 802 includes circuitry such as, but not limited to, one or more processors (or processor cores), cache memory, and LDOs, interrupt controllers, serial interfaces (such as SPI), and I / O pins. 2 The application circuit 802 may include one or more of the following: a C or general-purpose programmable serial interface module, an RTC, timers (including interval timers and watchdog timers), general-purpose I / O, a memory card controller (such as an SD MMC or similar controller), a USB interface, a MIPI interface, and a JTAG test access port. The processor (or core) of the application circuit 802 may be coupled to or may include a memory / storage element, and may be configured to execute instructions stored in the memory / storage element to enable various applications or operating systems to run on platform 800. In some specific implementations, the memory / storage element may be on-chip memory circuitry that may include any suitable volatile and / or non-volatile memory, such as DRAM, SRAM, EPROM, EEPROM, flash memory, solid-state memory, and / or any other type of memory device technology, such as those discussed herein.

[0084] The processor of application circuit 802 may include, for example, one or more processor cores, one or more application processors, one or more GPUs, one or more RISC processors, one or more ARM processors, one or more CISC processors, one or more DSPs, one or more FPGAs, one or more PLDs, one or more ASICs, one or more microprocessors or controllers, multi-threaded processors, ultra-low voltage processors, embedded processors, some other known processing elements, or any suitable combination thereof. In some embodiments, application circuit 802 may include or may be a dedicated processor / controller for operation according to various embodiments herein.

[0085] As an example, the processor of application circuit 802 may include Intel-based processors. ® Architecture ™ processors, such as Quark ™ Atom ™ i3, i5, i7 or MCU-level processors, or available from Intel. ® Another processor of this type from the company. The processor for Application Circuit 802 can also be one or more of the following: Advanced Micro Devices (AMD) Ryzen. ® Processor or Accelerated Processing Unit (APU); from Apple ® Inc.'s AS-A9 processor, from Qualcomm ®Snapdragon by Technologies, Inc. ™ Processor, Texas Instruments, Inc. ® Open MultimediaApplications Platform (OMAP) ™ Processors; MIPS-based designs from MIPS Technologies, Inc., such as the MIPS Warrior M-class, Warrior I-class, and Warrior P-class processors; ARM-based designs licensed from ARM Holdings, Ltd., such as the ARM Cortex-A, Cortex-R, and Cortex-M series processors; etc. In some specific implementations, application circuitry 802 may be part of a system-on-a-chip (SoC), where application circuitry 802 and other components are formed as a single integrated circuit or a single package, such as those from Intel. ® Edison of the Corporation ™ Or Galileo ™ SoC board.

[0086] In addition to or alternatively, application circuitry 802 may include circuitry such as, but not limited to, one or more field-programmable devices (FPDs) such as FPGAs; programmable logic devices (PLDs) such as complex PLDs (CPLDs), high-capacity PLDs (HCPLDs); ASICs such as structured ASICs; programmable SoCs (PSoCs); and so on. In such embodiments, the circuitry of application circuitry 802 may include logic blocks or logic architectures, and other interconnect resources that can be programmed to perform various functions such as processes, methods, functions, etc., as discussed in the various embodiments herein. In such embodiments, the circuitry of application circuitry 802 may include memory cells (e.g., erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), flash memory, static memory (e.g., static random access memory (SRAM), fuses, etc.)) for storing logic blocks, logic architectures, data, etc., in lookup tables (LUTs), etc.

[0087] The baseband circuit 804 can be implemented, for example, as a soldered substrate, which includes one or more integrated circuits, a single packaged integrated circuit soldered to a main circuit board, or a multi-chip module containing two or more integrated circuits.

[0088] The radio front-end module 806 may include a millimeter-wave (mmWave) radio front-end module (RFEM) and one or more sub-millimeter-wave radio frequency integrated circuits (RFICs). In some embodiments, the one or more sub-millimeter-wave RFICs may be physically separated from the millimeter-wave RFEM. The RFIC may include connectors to one or more antennas or antenna arrays, and the RFEM may be connected to multiple antennas. In another embodiment, the radio functions of both millimeter-wave and sub-millimeter-wave technologies may be implemented in the same physical radio front-end module 806 that combines both millimeter-wave and sub-millimeter-wave technologies.

[0089] Memory circuitry 808 may include any number and type of memory devices for providing a fixed amount of system memory. For example, memory circuitry 808 may include one or more of the following: volatile memory, including random access memory (RAM), dynamic RAM (DRAM), and / or synchronous dynamic RAM (SD RAM); and non-volatile memory (NVM), including high-speed electrically erasable memory (commonly referred to as flash memory), phase-change random access memory (PRAM), magnetoresistive random access memory (MRAM), etc. Memory circuitry 808 may be developed according to the Joint Electronic Equipment Committee (JEDEC) design based on low-power double data rate (LPDDR), such as LPDDR2, LPDDR3, LPDDR4, etc. Memory circuitry 808 may be implemented as one or more of the following: solder-in packaged integrated circuits, single-die package (SDP), dual-die package (DDP), or quad-die package (Q17P), socket memory modules, dual in-line memory modules (DIMMs) (including micro DIMMs or mini DIMMs, and / or soldered to a motherboard via a ball grid array (BGA)). In a low-power implementation, memory circuitry 808 may be an on-chip memory or register associated with application circuitry 802. To provide persistent storage for information such as data, applications, operating systems, etc., memory circuitry 808 may include one or more mass storage devices, which may include, in particular, solid-state drives (SSDDs), hard disk drives (HDDs), miniature HDDs, resistance-changing memory, phase-change memory, holographic memory, or chemical memory. For example, computer platform 800 may be integrated with Intel... ® and Micron ® 3D XPOINT memory.

[0090] The removable storage circuitry 826 may include devices, circuitry, enclosures / housings, ports, or sockets for coupling portable data storage devices to the platform 800. These portable data storage devices may be used for mass storage and may include, for example, flash memory cards (e.g., Secure Digital (SD) cards, MicroSD cards, xD picture cards, etc.), as well as USB flash drives, optical discs, external HDDs, etc.

[0091] Platform 800 may also include interface circuitry (not shown) for connecting external devices to platform 800. External devices connected to platform 800 via this interface circuitry include sensor 822 and electromechanical components (shown as EMC 824), as well as a removable memory device coupled to removable memory 826.

[0092] Sensor 822 includes devices, modules, or subsystems designed to detect events or changes in their environment and transmit information about the detected events (sensor data) to other devices, modules, subsystems, etc. Examples of such sensors include, in particular: inertial measurement units (IMUs) including accelerometers, gyroscopes, and / or magnetometers; microelectromechanical systems (MEMS) or nanoelectromechanical systems (NEMS) including triaxial accelerometers, triaxial gyroscopes, and / or magnetometers; level sensors; flow sensors; temperature sensors (e.g., thermistors); pressure sensors; barometric pressure sensors; gravimeters; altimeters; image capture devices (e.g., cameras or lensless aperture sensors); light detection and ranging (LiDAR) sensors; proximity sensors (e.g., infrared radiation detectors, etc.), depth sensors, ambient light sensors, ultrasonic transceivers; microphones or other similar audio capture devices; etc.

[0093] EMC 824 includes devices, modules, or subsystems intended to enable platform 800 to change its state, position, and / or orientation, or to move or control mechanisms or (sub)systems. Additionally, EMC 824 can be configured to generate messages / signaling and send messages / signaling to other components of platform 800 to indicate the current state of EMC 824. Examples of EMC 824 include one or more power switches, relays (including electromechanical relays (EMRs) and / or solid-state relays (SSRs)), actuators (e.g., valve actuators, etc.), audible generators, visual warning devices, motors (e.g., DC motors, stepper motors, etc.), wheels, propellers, pawls, clamps, hooks, and / or other similar electromechanical components. In embodiments, platform 800 is configured to operate one or more EMC 824s based on one or more captured events and / or commands or control signals received from a service provider and / or various clients. In some specific implementations, interface circuitry can connect platform 800 to positioning circuitry 816. Positioning circuit 816 includes circuitry for receiving and decoding signals transmitted / broadcast by a GNSS positioning network. Examples of navigation satellite constellations (or GNSS) may include the US GPS, Russia's GLONASS, the EU's Galileo system, China's BeiDou Navigation Satellite System, regional navigation systems, or GNSS augmentation systems (e.g., NAVIC, Japan's QZSS, France's DORIS, etc.). Positioning circuit 816 includes various hardware components (e.g., hardware devices such as switches, filters, amplifiers, antenna elements, etc.) for facilitating OTA communication to communicate with components of the positioning network, such as navigation satellite constellation nodes. In some embodiments, positioning circuit 816 may include a miniature PNT IC that performs position tracking / estimation using a master timing clock without GNSS assistance. Positioning circuit 816 may also be part of or interact with baseband circuitry 804 and / or radio front-end module 806 to communicate with nodes and components of the positioning network. The positioning circuit 816 can also provide location data and / or time data to the application circuit 802, which can use the data to synchronize operations with various infrastructures (e.g., radio base stations) for use in turn-by-turn navigation applications, etc.

[0094] In some implementations, this interface circuitry can connect platform 800 to a near-field communication circuitry (shown as NFC circuitry 812). NFC circuitry 812 is configured to provide contactless near-field communication based on a radio frequency identification (RFID) standard, where a magnetic field sensor is used to enable communication between NFC circuitry 812 and an NFC-enabled device (e.g., an "NFC contact point") external to platform 800. NFC circuitry 812 includes an NFC controller coupled to an antenna element and a processor coupled to the NFC controller. The NFC controller may be a chip / IC that provides NFC functionality to NFC circuitry 812 by executing NFC controller firmware and an NFC stack. The NFC stack may be executed by the processor to control the NFC controller, and the NFC controller firmware may be executed by the NFC controller to control the antenna element to transmit near-field RF signals. The RF signals may power passive NFC tags (e.g., microchips embedded in stickers or wristbands) to transmit stored data to NFC circuitry 812, or initiate data transfer between NFC circuitry 812 and another active NFC device (e.g., a smartphone or an NFC-enabled POS terminal) located near platform 800.

[0095] The drive circuitry 818 may include software and hardware elements for controlling specific devices embedded in, attached to, or otherwise communicatively coupled to the platform 800. The drive circuitry 818 may include various drivers that allow other components of the platform 800 to interact with or control various input / output (I / O) devices that may exist within or be connected to the platform. For example, the drive circuitry 818 may include a display driver for controlling and allowing access to a display device, a touchscreen driver for controlling and allowing access to a touchscreen interface of the platform 800, a sensor driver for obtaining sensor readings of sensor 822 and controlling and allowing access to sensor 822, an EMC driver for obtaining actuator position of EMC 824 and / or controlling and allowing access to EMC 824, a camera driver for controlling and allowing access to an embedded image capture device, and an audio driver for controlling and allowing access to one or more audio devices.

[0096] A power management integrated circuit (shown as PMIC 810) (also referred to as a "power management circuit") manages the power supplied to various components of platform 800. Specifically, relative to baseband circuit 804, PMIC 810 controls power selection, voltage scaling, battery charging, or DC-DC conversion. PMIC 810 is typically included when platform 800 can be powered by battery 814, for example, when the device is included in a UE.

[0097] In some implementations, the PMIC 810 can be controlled or otherwise integrated into various power-saving mechanisms of the platform 800. For example, if the platform 800 is in the RRC_Connected state, where it remains connected to the RAN node as it anticipates receiving traffic soon, it can enter a state known as Discontinuous Receive Mode (DRX) after a period of inactivity. During this state, the platform 800 can power down for short intervals to conserve power. If there is no data traffic activity over an extended period, the platform 800 can transition to the RRC_Idle state, in which it disconnects from the network and does not perform operations such as channel quality feedback, handover, etc. The platform 800 enters a very low-power state and performs paging, where it periodically wakes up to listen to the network and then power down again. The platform 800 may not receive data in this state; to receive data, it must transition back to the RRC_Connected state. Additional power-saving modes can allow the device to be unavailable from the network for longer than the paging interval (ranging from a few seconds to several hours). During this period, the device is completely unable to connect to the network and can be completely powered off. Any data sent during this time will result in significant latency, which is assumed to be acceptable.

[0098] Battery 814 can power platform 800, but in some examples, platform 800 may be mounted in a fixed location and may have a power source coupled to the grid. Battery 814 may be a lithium-ion battery, a metal-air battery such as a zinc-air battery, an aluminum-air battery, a lithium-air battery, etc. In some specific implementations, such as in V2X applications, battery 814 may be a typical lead-acid automotive battery.

[0099] In some implementations, battery 814 may be a "smart battery," which includes or is coupled to a battery management system (BMS) or battery monitoring integrated circuit. The BMS may be included in platform 800 to track the state of charge (SoCh) of battery 814. The BMS can be used to monitor other parameters of battery 814, such as the state of health (SoH) and state of function (SoF) of battery 814, to provide fault prediction. The BMS can transmit information about battery 814 to application circuitry 802 or other components of platform 800. The BMS may also include an analog-to-digital converter (ADC) that allows application circuitry 802 to directly monitor the voltage of battery 814 or the current from battery 814. Battery parameters can be used to determine actions that platform 800 can perform, such as transmission frequency, network operation, sensing frequency, etc.

[0100] A power block coupled to the power grid or other power source can be coupled to the BMS to charge battery 814. In some examples, a wireless power receiver can replace the power block to obtain power wirelessly, for example, via a loop antenna in computer platform 800. In these examples, wireless battery charging circuitry can be included in the BMS. The specific charging circuitry chosen may depend on the size of battery 814 and therefore on the required current. Charging can be performed using aviation fuel standards published by the Aviation Fuel Alliance, the Qi wireless charging standard published by the Radio Power Alliance, or the Rezence charging standard published by the Radio Power Alliance.

[0101] User interface circuitry 820 includes various input / output (I / O) devices present within or connected to platform 800, and includes one or more user interfaces designed to enable user interaction with platform 800 and / or peripheral component interfaces designed to enable interaction with peripheral components of platform 800. User interface circuitry 820 includes input device circuitry and output device circuitry. Input device circuitry includes any physical or virtual device for accepting input, particularly including one or more physical or virtual buttons (e.g., a reset button), a physical keyboard, a keypad, a mouse, a touchpad, a touchscreen, a microphone, a scanner, a headset, etc. Output device circuitry includes any physical or virtual device for displaying information or otherwise conveying information such as sensor readings, actuator positions, or other similar information. Output device circuitry may include any number and / or combination of audio or visual displays, particularly one or more simple visual outputs / indicators such as binary status indicators (e.g., light-emitting diodes (LEDs) and multi-character visual outputs), or more complex outputs such as display devices or touchscreens (e.g., liquid crystal displays (LCDs), LED displays, quantum dot displays, projectors, etc.), wherein the output of characters, graphics, multimedia objects, etc., is generated or produced by the operation of platform 800. Output device circuitry may also include speakers or other audio transmitting devices, printers, etc. In some embodiments, sensor 822 may be used as input device circuitry (e.g., image capture devices, motion capture devices, etc.) and one or more EMCs may be used as output device circuitry (e.g., actuators for providing haptic feedback, etc.). In another example, NFC circuitry may be included for reading electronic tags and / or connecting to another NFC-enabled device, the NFC circuitry including an NFC controller and processing device coupled to an antenna element. Peripheral component interfaces may include, but are not limited to, non-volatile memory ports, USB ports, audio jacks, power interfaces, etc.

[0102] Although not shown, components of Platform 800 may communicate with each other using suitable bus or interconnect (IX) technologies, which may include any number of technologies, including ISA, EISA, PCI, PCix, PCie, Time Triggered Protocol (TTP) systems, FlexRay systems, or any number of other technologies. The bus / IX may be a proprietary bus / IX, for example, used in a SoC-based system. Other bus / IX systems, such as I... 2 Interfaces include C-type interface, SPI interface, point-to-point interface, and power bus, etc.

[0103] Figure 9 Example components of a device 900 according to some embodiments are shown. In some embodiments, device 900 may include at least application circuitry 906, baseband circuitry 904, radio frequency (RF) circuitry (shown as RF circuitry 902), front-end module (FEM) circuitry (shown as FEM circuitry 932), one or more antennas 930, and power management circuitry (PMC) (shown as PMC 934) coupled together as shown. Components of the illustrated device 900 may be included in a UE or RAN node. In some embodiments, device 900 may include fewer components (e.g., the RAN node may not utilize application circuitry 906, but instead include a processor / controller to process IP data received from the EPC). In some embodiments, device 900 may include additional components such as memory / storage devices, displays, cameras, sensors, or input / output (I / O) interfaces. In other embodiments, the following components may be included in more than one device (e.g., circuitry may be individually included in more than one device for a cloud-RAN (C-RAN) specific implementation).

[0104] Application circuitry 906 may include one or more application processors. For example, application circuitry 906 may include circuitry such as, but not limited to, one or more single-core or multi-core processors. The one or more processors may include any combination of general-purpose processors and special-purpose processors (e.g., graphics processors, application processors, etc.). These processors may be coupled to or may include memory / storage devices and may be configured to execute instructions stored in the memory / storage device to enable various applications or operating systems to run on device 900. In some embodiments, the processor of application circuitry 906 may process IP data packets received from the EPC.

[0105] Baseband circuitry 904 may include circuitry, such as, but not limited to, one or more single-core or multi-core processors. Baseband circuitry 904 may include one or more baseband processors or control logic components to process baseband signals received from the receive signal path of RF circuitry 902 and generate baseband signals for the transmit signal path of RF circuitry 902. Baseband circuitry 904 may interact with application circuitry 906 to generate and process baseband signals and control the operation of RF circuitry 902. For example, in some embodiments, baseband circuitry 904 may include a third-generation (3G) baseband processor (3G baseband processor 908), a fourth-generation (4G) baseband processor (4G baseband processor 910), a fifth-generation (5G) baseband processor (5G baseband processor 912), or other existing, under development, or future generations of baseband processors 914 (e.g., second-generation (2G), sixth-generation (6G), etc.). Baseband circuitry 904 (e.g., one or more baseband processors in a baseband processor suite) can handle various radio control functions that enable communication with one or more radio networks via RF circuitry 902. In other embodiments, some or all of the functions of the exemplified baseband processor may be included in modules stored in memory 920 and executed via a central processing unit (CPU 916). Radio control functions may include, but are not limited to, signal modulation / demodulation, encoding / decoding, RF shifting, etc. In some embodiments, the modulation / demodulation circuitry of baseband circuitry 904 may include Fast Fourier Transform (FFT), precoding, or constellation mapping / demapping functions. In some embodiments, the encoding / decoding circuitry of baseband circuitry 904 may include convolution, tail-biting convolution, turbo, Viterbi, or low-density parity-check (LDPC) encoder / decoder functions. Implementations of modulation / demodulation and encoder / decoder functions are not limited to these examples, and other suitable functions may be included in other embodiments.

[0106] In some embodiments, the baseband circuitry 904 may include a digital signal processor (DSP), such as one or more audio DSPs 918. The one or more audio DSPs 918 may include elements for compression / decompression and echo cancellation, and in other embodiments may include other suitable processing elements. In some embodiments, components of the baseband circuitry may be suitably combined in a single chip, a single chipset, or disposed on the same circuit board. In some embodiments, some or all of the components of the baseband circuitry 904 and the application circuitry 906 may be implemented together, for example, on a system-on-a-chip (SoC).

[0107] In some implementations, baseband circuit 904 can provide communication compatible with one or more radio technologies. For example, in some implementations, baseband circuit 904 can support communication with the Evolved Universal Terrestrial Radio Access Network (EUTRAN) or other Wireless Metropolitan Area Networks (WMAN), Wireless Local Area Networks (WLAN), or Wireless Personal Area Networks (WPAN). Implementations in which baseband circuit 904 is configured to support radio communication with more than one radio protocol may be referred to as multimode baseband circuits.

[0108] RF circuit 902 enables communication with a wireless network via a non-solid medium using modulated electromagnetic radiation. In various embodiments, RF circuit 902 may include switches, filters, amplifiers, etc., to facilitate communication with the wireless network. RF circuit 902 may include a receive signal path that includes circuitry for down-converting the RF signal received from FEM circuit 932 and providing a baseband signal to baseband circuit 904. RF circuit 902 may also include a transmit signal path that includes circuitry for up-converting the baseband signal provided by baseband circuit 904 and providing an RF output signal for transmission to FEM circuit 932.

[0109] In some embodiments, the receive signal path of RF circuit 902 may include mixer circuit 922, amplifier circuit 924, and filter circuit 926. In some embodiments, the transmit signal path of RF circuit 902 may include filter circuit 926 and mixer circuit 922. RF circuit 902 may also include synthesizer circuit 928 for synthesizing frequencies used by mixer circuit 922 for both the receive and transmit signal paths. In some embodiments, mixer circuit 922 for the receive signal path may be configured to down-convert the RF signal received from FEM circuit 932 based on the synthesized frequency provided by synthesizer circuit 928. Amplifier circuit 924 may be configured to amplify the down-converted signal, and filter circuit 926 may be a low-pass filter (LPF) or band-pass filter (BPF) configured to remove unwanted signals from the down-converted signal to generate an output baseband signal. The output baseband signal may be provided to baseband circuit 904 for further processing. In some embodiments, although not required, the output baseband signal may be a zero-frequency baseband signal. In some implementations, the mixer circuit 922 for receiving the signal path may include a passive mixer, but the scope of the implementation is not limited in this respect.

[0110] In some implementations, the mixer circuit 922 of the transmit signal path can be configured to up-convert the input baseband signal based on the synthesized frequency provided by the synthesizer circuit 928 to generate an RF output signal for the FEM circuit 932. The baseband signal can be provided by the baseband circuit 904 and can be filtered by the filter circuit 926.

[0111] In some embodiments, the mixer circuit 922 for the receive signal path and the mixer circuit 922 for the transmit signal path may include two or more mixers and may be arranged for quadrature downconversion and upconversion, respectively. In some embodiments, the mixer circuit 922 for the receive signal path and the mixer circuit 922 for the transmit signal path may include two or more mixers and may be arranged for image rejection (e.g., Hartley image rejection). In some embodiments, the mixer circuit 922 for the receive signal path and the mixer circuit 922 may be arranged for direct downconversion and direct upconversion, respectively. In some embodiments, the mixer circuit 922 for the receive signal path and the mixer circuit 922 for the transmit signal path may be configured for superheterodyne operation.

[0112] In some embodiments, the output baseband signal and the input baseband signal may be analog baseband signals, although the scope of the embodiments is not limited in this respect. In some alternative embodiments, the output baseband signal and the input baseband signal may be digital baseband signals. In these alternative embodiments, RF circuitry 902 may include analog-to-digital converter (ADC) and digital-to-analog converter (DAC) circuitry, and baseband circuitry 904 may include a digital baseband interface for communicating with RF circuitry 902.

[0113] In some dual-mode implementations, separate radio IC circuits can be provided to process signals for each spectrum, but the scope of the implementation is not limited in this respect.

[0114] In some implementations, synthesizer circuit 928 may be a fractional-N synthesizer or a fractional-N / N+1 synthesizer, but the scope of implementations is not limited in this respect, as other types of frequency synthesizers may also be suitable. For example, synthesizer circuit 928 may be a Δ-∑ synthesizer, a frequency multiplier, or a synthesizer including a phase-locked loop with a frequency divider.

[0115] Synthesizer circuit 928 can be configured to synthesize an output frequency based on the frequency input and the divider control input for use by mixer circuit 922 of RF circuit 902. In some embodiments, synthesizer circuit 928 may be a fractional N / N+1 synthesizer.

[0116] In some implementations, the frequency input may be provided by a voltage-controlled oscillator (VCO), although this is not mandatory. The divider control input may be provided by baseband circuitry 904 or application circuitry 906 (such as an application processor) according to the desired output frequency. In some implementations, the divider control input (e.g., N) may be determined from a lookup table based on the channel indicated by application circuitry 906.

[0117] The synthesizer circuit 928 of the RF circuit 902 may include a frequency divider, a delay-locked loop (DLL), a multiplexer, and a phase accumulator. In some embodiments, the frequency divider may be a dual-mode divider (DMD), and the phase accumulator may be a digital phase accumulator (DPA). In some embodiments, the DMD may be configured to divide the input signal by N or N+1 (e.g., based on carry) to provide a fractional division ratio. In some example embodiments, the DLL may include a cascaded, tunable delay element, a phase detector, a charge pump, and a set of D-type flip-flops. In these embodiments, the delay elements may be configured to divide the VCO cycle into Nd equal phase groups, where Nd is the number of delay elements in the delay line. Thus, the DLL provides negative feedback to help ensure that the total delay through the delay line is one VCO cycle.

[0118] In some embodiments, synthesizer circuitry 928 may be configured to generate a carrier frequency as the output frequency, while in other embodiments, the output frequency may be a multiple of the carrier frequency (e.g., twice the carrier frequency, four times the carrier frequency) and may be used in conjunction with quadrature generator and frequency divider circuitry to generate multiple signals having multiple different phases relative to each other at that carrier frequency. In some embodiments, the output frequency may be the LO frequency (fLO). In some embodiments, RF circuitry 902 may include an IQ / polarity converter.

[0119] FEM circuit 932 may include a receive signal path, which may include circuitry configured to operate on RF signals received from one or more antennas 930, amplify the received signals, and provide an amplified version of the received signals to RF circuit 902 for further processing. FEM circuit 932 may also include a transmit signal path, which may include circuitry configured to amplify transmit signals provided by RF circuit 902 for transmission by one or more of the one or more antennas 930. In various embodiments, amplification via the transmit signal path or the receive signal path may be performed only in RF circuit 902, only in FEM circuit 932, or in both RF circuit 902 and FEM circuit 932.

[0120] In some embodiments, FEM circuit 932 may include a TX / RX switch to switch between transmit and receive mode operation. FEM circuit 932 may include a receive signal path and a transmit signal path. The receive signal path of FEM circuit 932 may include an LNA to amplify the received RF signal and provide the amplified received RF signal as an output (e.g., provided to RF circuit 902). The transmit signal path of FEM circuit 932 may include a power amplifier (PA) to amplify the input RF signal (e.g., provided by RF circuit 902), and one or more filters to generate an RF signal for subsequent transmission (e.g., through one or more antennas in one or more antennas 930).

[0121] In some implementations, the PMC 934 can manage the power supplied to the baseband circuitry 904. Specifically, the PMC 934 can control power selection, voltage scaling, battery charging, or DC-DC conversion. The PMC 934 is typically included when the device 900 can be battery powered, for example, when the device 900 is included in a UE. The PMC 934 can improve power conversion efficiency while providing the desired implementation size and thermal characteristics.

[0122] Figure 9 The PMC 934 is shown coupled only to the baseband circuit 904. However, in other embodiments, the PMC 934 may additionally or alternatively be coupled to other components, such as, but not limited to, the application circuit 906, the RF circuit 902, or the FEM circuit 932, and perform similar power management operations for these components.

[0123] In some implementations, the PMC 934 can control or otherwise become part of various power-saving mechanisms of the device 900. For example, if the device 900 is in the RRC_Connected state, where the device is still connected to the RAN node because it expects to receive traffic immediately, it can enter a state called Discontinuous Receive Mode (DRX) after a period of inactivity. During this state, the device 900 can be powered down for short intervals, thereby saving power.

[0124] If there is no data traffic activity during the extended period, device 900 can transition to the RRC_Idle state, in which the device disconnects from the network and does not perform operations such as channel quality feedback or handover. Device 900 enters a very low power state and performs paging, in which the device periodically wakes up again to listen to the network, and then powers off again. Device 900 cannot receive data in this state, and in order to receive data, the device must transition back to the RRC_Connected state.

[0125] An additional power-saving mode allows the device to be unavailable from the network for periods exceeding the paging interval (ranging from seconds to hours). During this time, the device is completely unconnected to the network and can be completely powered off. Any data sent during this period will incur significant latency, which is assumed to be acceptable.

[0126] The processors of application circuitry 906 and baseband circuitry 904 can be used as elements to execute one or more instances of the protocol stack. For example, the processor of baseband circuitry 904 can be used alone or in combination to execute layer 3, layer 2, or layer 1 functions, while the processor of application circuitry 906 can utilize data received from these layers (e.g., packet data) and further execute layer 4 functions (e.g., Transport Communication Protocol (TCP) and User Datagram Protocol (UDP) layers). As mentioned herein, layer 3 may include the Radio Resource Control (RRC) layer, which will be described in further detail below. As mentioned herein, layer 2 may include the Media Access Control (MAC) layer, Radio Link Control (RLC) layer, and Packet Data Convergence Protocol (PDCP) layer, which will be described in further detail below. As mentioned herein, layer 1 may include the physical (PHY) layer of the UE / RAN node, which will be described in further detail below.

[0127] Figure 10 An exemplary interface 1000 of a baseband circuit according to some embodiments is shown. As discussed above, Figure 9 The baseband circuitry 904 may include a 3G baseband processor 908, a 4G baseband processor 910, a 5G baseband processor 912, other baseband processors 914, a CPU 916, and a memory 920 utilized by the processors. As shown, each processor may include a corresponding memory interface 1002 for sending / receiving data to / from the memory 920.

[0128] The baseband circuit 904 may also include one or more interfaces for communicatively coupling to other circuits / devices, such as a memory interface 1004 (e.g., an interface for sending / receiving data to / from a memory external to the baseband circuit 904) or an application circuit interface 1006 (e.g., an interface for sending / receiving data to / from a memory external to the baseband circuit 904). Figure 9 Application circuit 906 is an interface for sending / receiving data), and RF circuit interface 1008 (e.g., for sending / receiving data to / from...). Figure 9 The RF circuit 902 is an interface for transmitting / receiving data, and the wireless hardware connection interface 1010 is used for transmitting / receiving data to / from near field communication (NFC) components, Bluetooth, etc. ® Components (e.g., Bluetooth) ® Low power consumption, Wi-Fi ®Interfaces for sending / receiving data to / from components and other communication components) and power management interface 1012 (e.g., an interface for sending / receiving power or control signals to / from the PMC 934).

[0129] Figure 11 This is a block diagram illustrating a component 1100, according to some exemplary embodiments, capable of reading instructions from a machine-readable or computer-readable medium (e.g., a non-transitory machine-readable storage medium) and capable of executing any one or more of the methods discussed herein. Specifically, Figure 11 A schematic diagram of hardware resource 1102 is shown, which includes one or more processors 1106 (or processor cores), one or more memory / storage devices 1114, and one or more communication resources 1124, each of which is communicatively coupled via bus 1116. For implementations utilizing node virtualization (e.g., NFV), an executable hypervisor 1122 can be used to provide an execution environment for one or more network slices / subslices to utilize hardware resource 1102.

[0130] Processor 1106 (e.g., a central processing unit (CPU), a reduced instruction set computing (RISC) processor, a complex instruction set computing (CISC) processor, a graphics processing unit (GPU), a digital signal processor (DSP) (such as a baseband processor), an application-specific integrated circuit (ASIC), a radio frequency integrated circuit (RFIC), another processor, or any suitable combination thereof) may include, for example, processor 1108 and processor 1110.

[0131] The memory / storage device 1114 may include main memory, disk storage devices, or any suitable combination thereof. The memory / storage device 1114 may include, but is not limited to, any type of volatile or non-volatile memory, such as dynamic random access memory (DRAM), static random access memory (SRAM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), flash memory, solid-state storage devices, etc.

[0132] Communication resource 1124 may include interconnect or network interface components or other suitable devices for communicating with one or more peripheral devices 1104 or one or more databases 1120 via network 1118. For example, communication resource 1124 may include wired communication components (e.g., for coupling via Universal Serial Bus (USB), cellular communication components, NFC components, Bluetooth, etc. ® Components (e.g., Bluetooth) ® Low power consumption, Wi-Fi ® Components and other communication components.

[0133] Instructions 1112 may include software, programs, applications, applets, or other executable code for causing at least one processor in processor 1106 to perform any or more of the methods discussed herein. Instructions 1112 may reside wholly or partially within at least one processor in processor 1106 (e.g., within the processor's cache memory), memory / storage device 1114, or any suitable combination thereof. Furthermore, any portion of instructions 1112 may be transferred from peripheral device 1104 or database 1120 to hardware resource 1102. Therefore, the memory of processor 1106, memory / storage device 1114, peripheral device 1104, and database 1120 are examples of computer-readable and machine-readable media.

[0134] For one or more embodiments, at least one of the components shown in one or more of the foregoing figures may be configured to perform one or more operations, techniques, processes, and / or methods described in the Embodiments section below. For example, the baseband circuitry described above in conjunction with one or more of the foregoing figures may be configured to operate according to one or more of the examples below. As another example, circuitry associated with the UE, base station, network element, etc., described above in conjunction with one or more of the foregoing figures may be configured to operate according to one or more of the examples shown in the Examples section below.

[0135] Example Section

[0136] The following examples relate to other implementation schemes.

[0137] Example 1A may include an apparatus for a user equipment (UE) comprising: one or more processors; and a memory storing instructions that, when executed by the one or more processors, configure the apparatus to: encode a first Hybrid Automatic Repeat Request Acknowledgment (HARQ-ACK) and a second HARQ-ACK in a single time slot for transmission to a base station, the first HARQ-ACK being transmitted via a first Physical Uplink Control Channel (PUCCH) and the second HARQ-ACK being transmitted via a second PUCCH; and, based on the encoding of the first HARQ-ACK and the second HARQ-ACK in the single time slot, respond to one or more additional uplink (UL) signals that conflict with at least one of the first HARQ-ACK and the second HARQ-ACK in the single time slot, based on the configuration of the UE.

[0138] Example 2A may include the apparatus according to Example 1A, wherein the UE is configured to avoid transmitting additional UL signals via PUCCH that would conflict with at least one of the first HARQ-ACK and the second HARQ-ACK within the single time slot.

[0139] Example 3A may include the apparatus according to Example 1A, wherein the UE is configured to avoid transmitting additional UL signals via PUSCH that would conflict with at least one of the first HARQ-ACK and the second HARQ-ACK within the single time slot.

[0140] Example 4A may include the apparatus according to Example 1A, wherein the instructions further configure the apparatus to: when the UE configuration includes transmitting an additional UL signal via PUCCH that would conflict with at least one of the first HARQ-ACK and the second HARQ-ACK in the single time slot: multiplex both the first HARQ-ACK and the second HARQ-ACK; and multiplex the additional UL signal via PUCCH with the multiplexed first HARQ-ACK and the second HARQ-ACK.

[0141] Example 5A may include the apparatus according to Example 1A, wherein the instructions further configure the apparatus to: when the UE configuration includes transmitting an additional UL signal via PUCCH that will conflict with at least one of the first HARQ-ACK and the second HARQ-ACK in the single time slot: multiplex both the first HARQ-ACK and the second HARQ-ACK; if the payload of the UL signal via PUCCH is limited, multiplex the first HARQ-ACK with the UL signal via PUCCH; or, if the payload of the UL signal via PUCCH is limited, multiplex the second HARQ-ACK with the UL signal via PUCCH.

[0142] Example 6A may include the apparatus according to Example 1A, wherein the instruction further configures the apparatus to: when the UE configuration includes transmitting a first additional UL signal via PUCCH and a second additional UL signal via PUSCH that would conflict with at least one of the first HARQ-ACK and the second HARQ-ACK in the single time slot: multiplex both the first HARQ-ACK and the second HARQ-ACK; multiplex the first additional UL signal via PUCCH with the multiplexed first HARQ-ACK and the second HARQ-ACK; and multiplex the second additional UL signal via PUSCH with the multiplexed first HARQ-ACK and the second HARQ-ACK and the multiplexed first additional UL signal via PUCCH.

[0143] Example 7A may include the apparatus according to Example 1A, wherein the instruction further configures the apparatus to: when the UE configuration includes transmitting a first additional UL signal via PUCCH and a second additional UL signal via PUSCH that would conflict with at least one of the first HARQ-ACK and the second HARQ-ACK in the single time slot: multiplex both the first HARQ-ACK and the second HARQ-ACK; if the payload of the second additional UL signal via PUSCH is limited, then multiplex the first HARQ-ACK with the second additional UL signal via PUSCH; or, if the payload of the second additional UL signal via PUSCH is limited, then multiplex the second HARQ-ACK with the second additional UL signal via PUSCH.

[0144] Example 8A may include a method for a user equipment (UE) to use for wireless communication, the method comprising: encoding a first hybrid automatic repeat request acknowledgment (HARQ-ACK) and a second HARQ-ACK in a single time slot for transmission to a base station, the first HARQ-ACK being transmitted via a first physical uplink control channel (PUCCH) and the second HARQ-ACK being transmitted via a second PUCCH; and responding, based on the encoding of the first HARQ-ACK and the second HARQ-ACK in the single time slot, to one or more additional uplink (UL) signals that conflict with at least one of the first HARQ-ACK and the second HARQ-ACK in the single time slot, based on the configuration of the UE.

[0145] Example 9A may include the method according to Example 8A, wherein the UE is configured to avoid transmitting additional UL signals via PUCCH that would conflict with at least one of the first HARQ-ACK and the second HARQ-ACK within the single time slot.

[0146] Example 10A may include the method according to Example 8A, wherein the UE is configured to avoid transmitting additional UL signals via PUSCH that would conflict with at least one of the first HARQ-ACK and the second HARQ-ACK within the single time slot.

[0147] Example 11A may include the method according to Example 8A, further comprising: when the UE configuration includes transmitting an additional UL signal via PUCCH that will conflict with at least one of the first HARQ-ACK and the second HARQ-ACK in the single time slot: multiplexing both the first HARQ-ACK and the second HARQ-ACK; and multiplexing the additional UL signal via PUCCH with the multiplexed first HARQ-ACK and the second HARQ-ACK.

[0148] Example 12A may include the method according to Example 8A, further comprising: when the UE configuration includes transmitting an additional UL signal via PUCCH that will conflict with at least one of the first HARQ-ACK and the second HARQ-ACK in the single time slot: multiplexing both the first HARQ-ACK and the second HARQ-ACK; if the payload of the UL signal via PUCCH is limited, multiplexing the first HARQ-ACK with the UL signal via PUCCH; or, if the payload of the UL signal via PUCCH is limited, multiplexing the second HARQ-ACK with the UL signal via PUCCH.

[0149] Example 13A may include the method according to Example 8A, further comprising: when the UE configuration includes transmitting a first additional UL signal via PUCCH and a second additional UL signal via PUSCH that would conflict with at least one of the first HARQ-ACK and the second HARQ-ACK in the single time slot: multiplexing both the first HARQ-ACK and the second HARQ-ACK; multiplexing the first additional UL signal via PUCCH with the multiplexed first HARQ-ACK and the second HARQ-ACK; and multiplexing the second additional UL signal via PUSCH with the multiplexed first HARQ-ACK and the second HARQ-ACK and the multiplexed first additional UL signal via PUCCH.

[0150] Example 14A may include the method according to Example 8A, further comprising: when the UE configuration includes transmitting a first additional UL signal via PUCCH and a second additional UL signal via PUSCH that would conflict with at least one of the first HARQ-ACK and the second HARQ-ACK in the single time slot: multiplexing both the first HARQ-ACK and the second HARQ-ACK; if the payload of the second additional UL signal via PUSCH is limited, multiplexing the first HARQ-ACK with the second additional UL signal via PUSCH; or, if the payload of the second additional UL signal via PUSCH is limited, multiplexing the second HARQ-ACK with the second additional UL signal via PUSCH.

[0151] Example 15A may include an apparatus for a user equipment (UE) comprising: one or more processors; and a memory storing instructions that, when executed by the one or more processors, configure the apparatus to: generate a Type I Hybrid Automatic Repeat Request Acknowledgment (HARQ-ACK) codebook for Time Domain Multiplexing Scheme A (TDMScheme A), the generation including: decoding a first DL signal received via a first PDSCH and a second DL signal received via a second PDSCH; processing a K1 offset table, the K1 offset table being associated with determining when to... The transmission of at least one HARQ-ACK is associated with the K1 offset table received from the base station; processing a start and length indicator (SLIV) table of a time-slotted PDSCH, the SLIV table being associated with determining the precise time-domain position of at least one of a first DL signal received via a first PDSCH and a second DL signal received via a second PDSCH, the SLIV table being received from the base station; and retaining the HARQ-ACK in the generated HARQ-ACK codebook based on the validity of one or both of the first and second PDSCHs, wherein a given PDSCH is valid when it does not conflict with any uplink (UL) signal.

[0152] Example 16A may include the apparatus according to Example 15A, wherein retaining HARQ-ACK in the codebook based on the validity of one or both of the first PDSCH and the second PDSCH includes retaining HARQ-ACK in the codebook only when the first PDSCH is valid.

[0153] Example 17A may include the apparatus according to Example 15A, wherein retaining HARQ-ACK in the codebook based on the validity of one or both of the first PDSCH and the second PDSCH includes retaining HARQ-ACK in the codebook only when the second PDSCH is valid.

[0154] Example 18A may include the apparatus according to Example 15A, wherein retaining HARQ-ACK in the codebook based on the validity of one or both of the first PDSCH and the second PDSCH includes retaining HARQ-ACK in the codebook only when both the first PDSCH and the second PDSCH are valid.

[0155] Example 19A may include a method for a user equipment (UE) to use for wireless communication, the method comprising: generating a Type I Hybrid Automatic Repeat Request Acknowledgment (HARQ-ACK) codebook for a Time Domain Multiplexing Scheme A (TDMScheme A), the generation comprising: decoding a first DL signal received via a first PDSCH and a second DL signal received via a second PDSCH; processing a K1 offset table associated with determining when at least one HARQ-ACK is transmitted in response to decoding the first DL signal received via the first PDSCH and the second DL signal received via the second PDSCH, the K1 offset table being... The offset table is received from the base station; a start and length indicator (SLIV) table of time-slotted PDSCHs is processed, which is associated with determining the precise position in the time domain of at least one of a first DL signal received via a first PDSCH and a second DL signal received via a second PDSCH, which is received from the base station; and HARQ-ACK is retained in the generated HARQ-ACK codebook based on the validity of one or both of the first and second PDSCHs, wherein a given PDSCH is valid when it does not conflict with any uplink (UL) signal.

[0156] Example 20A may include the method according to Example 19A, wherein retaining HARQ-ACK in the codebook based on the validity of one or both of the first PDSCH and the second PDSCH includes retaining HARQ-ACK only when the first PDSCH is valid.

[0157] Example 21A may include the method according to Example 19A, wherein retaining HARQ-ACK in the codebook based on the validity of one or both of the first PDSCH and the second PDSCH includes retaining HARQ-ACK in the codebook only when the second PDSCH is valid.

[0158] Example 22A may include the method according to Example 19A, wherein retaining HARQ-ACK in the codebook based on the validity of one or both of the first PDSCH and the second PDSCH includes retaining HARQ-ACK in the codebook only when both the first PDSCH and the second PDSCH are valid.

[0159] Example 23A may include a computer-readable storage medium comprising instructions that, when executed by one or more processors of a user equipment (UE) configured to determine a default TCI for decoding downlink signals via the PDSCH, cause the one or more processors to: decode a first downlink (DL) signal received from a scheduling cell via a physical downlink control channel (PDCCH), wherein decoding includes determining a multiple transmit and receive point (MTRP) configuration for both the scheduling cell and a scheduled cell scheduled by the scheduling cell; determining a default transport configuration indicator (TCI) for cross-carrier scheduling (CCS) with MTRP based at least in part on the determined MTRP configuration of either or both of the scheduling cell and the scheduled cell; and decoding a second DL signal received via the physical downlink shared channel (PDSCH) corresponding to the first DL signal received via the PDCCH using the determined default TCI.

[0160] Example 24A may include the computer-readable storage medium according to Example 23A, wherein when the default TCI is determined to be at least partially based on the MTRP configuration of the scheduled cell, the default TCI includes the control resource set (CORESET) with the lowest identifier (ID) and CORESETPoolIndex value in the most recent PDCCH monitoring slot, the CORESETPoolIndex value including the same value as the CORESETPoolIndex value of the scheduled DCI.

[0161] Example 25A may include the computer-readable storage medium according to Example 23A, wherein the determination of the default TCI is based at least in part on the DCI MTRP configuration of the scheduled cell.

[0162] Example 26A may include the computer-readable storage medium according to Example 25A, wherein when the determined MTRP configuration of the scheduled cell supports multiple DCI MTRP, the default TCI includes the control resource set (CORESET) with the lowest identifier (ID) and CORESETPoolIndex value in the most recent PDCCH monitoring slot, the CORESETPoolIndex value including the same value as the CORESETPoolIndex value for scheduling downlink control information (DCI).

[0163] Example 27A may include the computer-readable storage medium according to Example 25A, wherein when the MTRP configuration of the scheduled cell does not support multiple DCI MTRP, the default TCI further includes: a control resource set (CORESET) with the lowest identifier (ID) in the most recent PDCCH monitoring slot; or an activated PDSCH TCI with the lowest index in the scheduled cell.

[0164] Example 28A may include the computer-readable storage medium according to Example 23A, wherein when the determined MTRP configuration of the scheduled cell and the scheduled cell both support a single DCI MTRP, the default TCI includes an activated TCI code point for the PDSCH with the lowest identifier (ID), which has two TCI states in the scheduled cell.

[0165] Example 29A may include the computer-readable storage medium according to Example 23A, wherein when the determined MTRP configuration of the scheduled cell and the scheduling cell both support a single DCI MTRP, the default TCI includes an activated TCI code point for the PDSCH with the lowest identifier (ID), which has two TCI states in the scheduled cell.

[0166] Example 30A may include the computer-readable storage medium according to Example 23A, wherein when the determined MTRP configurations of the scheduled cell and the scheduling cell both support a single DCI MTRP and neither the activated TCI code point for PDSCH in the scheduled cell nor the activated TCI code point for PDSCH in the scheduling cell includes two TCI states, the default TCI includes: the activated TCI code point for PDSCH in the scheduled cell or the activated TCI code point for PDSCH in the scheduling cell with the lowest identifier (ID); the control resource set (CORESET) with the lowest ID; or the CORESET with the lowest ID in the latest PDCCH monitoring slot.

[0167] Example 31A may include a method for a user equipment (UE) to use for wireless communication, the method comprising: decoding a first downlink (DL) signal received from a scheduling cell via a physical downlink control channel (PDCCH), wherein decoding includes determining a multiple transmit and receive point (MTRP) configuration for both the scheduling cell and a scheduled cell scheduled by the scheduling cell; determining a default transport configuration indicator (TCI) for cross-carrier scheduling (CCS) with MTRP based at least in part on the determined MTRP configuration of either or both of the scheduling cell and the scheduled cell; and decoding a second DL signal received via a physical downlink shared channel (PDSCH) corresponding to the first DL signal received via the PDCCH using the determined default TCI.

[0168] Example 32A may include the method according to Example 31A, wherein when the default TCI is determined to be at least partially based on the MTRP configuration of the scheduled cell, the default TCI includes the control resource set (CORESET) with the lowest identifier (ID) and CORESETPoolIndex value in the most recent PDCCH monitoring slot, the CORESETPoolIndex value including the same value as the CORESETPoolIndex value of the scheduled DCI.

[0169] Example 33A may include the method according to Example 31A, wherein the default TCI is determined at least in part based on the DCI MTRP configuration of the scheduled cell.

[0170] Example 34A may include the method according to Example 33A, wherein when the determined MTRP configuration of the scheduled cell supports multiple DCI MTRP, the default TCI includes the control resource set (CORESET) with the lowest identifier (ID) and CORESETPoolIndex value in the most recent PDCCH monitoring slot, the CORESETPoolIndex value including the same value as the CORESETPoolIndex value for scheduling downlink control information (DCI).

[0171] Example 35A may include the method according to Example 33A, wherein when the MTRP configuration of the scheduled cell does not support multiple DCI MTRP, the default TCI further includes: the control resource set (CORESET) with the lowest identifier (ID) in the most recent PDCCH monitoring slot; or the activated PDSCH TCI with the lowest index in the scheduled cell.

[0172] Example 36A may include the method according to Example 31A, wherein when the determined MTRP configuration of the scheduled cell and the scheduled cell both support a single DCI MTRP, the default TCI includes an activated TCI code point for the PDSCH with the lowest identifier (ID), which has two TCI states in the scheduled cell.

[0173] Example 37A may include the method according to Example 31A, wherein when the determined MTRP configuration of the scheduled cell and the scheduling cell both support a single DCI MTRP, the default TCI includes an activated TCI code point for the PDSCH with the lowest identifier (ID), which has two TCI states in the scheduled cell.

[0174] Example 38A may include the method according to Example 31A, wherein when the determined MTRP configurations of the scheduled cell and the scheduled cell both support a single DCI MTRP and neither the activated TCI code point for PDSCH in the scheduled cell nor the activated TCI code point for PDSCH in the scheduled cell includes two TCI states, the default TCI includes: the activated TCI code point for PDSCH in the scheduled cell or the activated TCI code point for PDSCH in the scheduled cell with the lowest identifier (ID); the control resource set (CORESET) with the lowest ID; or the CORESET with the lowest ID in the latest PDCCH monitoring slot.

[0175] Example 1B may include an apparatus comprising one or more elements for performing the method or any other method or process described herein, as described in any of the above embodiments or related to them.

[0176] Example 2B may include one or more non-transitory computer-readable media, the one or more non-transitory computer-readable media including instructions that, when executed by one or more processors of an electronic device, cause the electronic device to perform one or more elements of the method or any other method or process described herein, as described in any of the above embodiments or related to them.

[0177] Example 3B may include an apparatus comprising one or more elements of a logic component, module, or circuit for performing one or more elements of the method or any other method or process described herein, as described in any of the above embodiments or related to them.

[0178] Example 4B may include any of the methods, techniques, or processes, or parts or components thereof, described or associated with any of the above examples.

[0179] Example 5B may include an apparatus comprising one or more processors and one or more computer-readable media, the one or more computer-readable media including instructions that, when executed by the one or more processors, cause the one or more processors to perform any of the methods, techniques, or processes or portions thereof described in or associated with any of the above embodiments.

[0180] Example 6B may include the signal or part or component thereof that is described or associated with any of the above examples.

[0181] Example 7B may include datagrams, packets, frames, segments, protocol data units (PDUs) or messages or parts or components thereof as described in or related to any of the above examples, or otherwise described in this disclosure.

[0182] Example 8B may include a data-encoded signal or part or component thereof that is in or related to any of the above examples, or otherwise described in this disclosure.

[0183] Example 9B may include signals or portions or components thereof encoded as datagrams, packets, frames, segments, PDUs or messages as described in any of the above examples or in connection with them, or otherwise described in this disclosure.

[0184] Example 10B may include an electromagnetic signal carrying computer-readable instructions, wherein execution of the computer-readable instructions by one or more processors will cause the one or more processors to perform any of the methods, techniques or processes, or portions thereof, as described in or related to any of the above embodiments.

[0185] Example 11B may include a computer program comprising instructions, wherein execution of the program by a processing element will cause the processing element to perform any of the methods, techniques, or processes or portions thereof described in or associated with any of the above embodiments.

[0186] Example 12B may include signals in a wireless network as shown and described herein.

[0187] Example 13B may include a method of communicating in a wireless network as shown and described herein.

[0188] Example 14B may include a system for providing wireless communication as shown and described herein.

[0189] Example 15B may include a device for providing wireless communication as shown and described herein.

[0190] Unless otherwise expressly stated, any of the above embodiments may be combined with any other embodiment (or combination of embodiments). The foregoing description of one or more specific embodiments provides illustration and description, but is not intended to be exhaustive or to limit the scope of the embodiments to the precise forms disclosed. In view of the teachings above, modifications and variations are possible, or modifications and variations may be obtained from the practice of various embodiments.

[0191] Implementations and specific embodiments of the systems and methods described herein may include various operations embodied in machine-executable instructions to be executed by a computer system. The computer system may include one or more general-purpose or special-purpose computers (or other electronic devices). The computer system may include hardware components, including specific logical components for performing the operations, or may include a combination of hardware, software, and / or firmware.

[0192] It should be recognized that the systems described herein include descriptions of specific implementations. These implementations may be combined into a single system, partially integrated into other systems, divided into multiple systems, or otherwise partitioned or combined. Furthermore, it is conceivable to use parameters, attributes, aspects, etc., of one implementation in another implementation. For clarity, these parameters, attributes, aspects, etc., are described only in one or more implementations, and it should be recognized that unless specifically stated herein, these parameters, attributes, aspects, etc., may be combined with or substituted for parameters, attributes, aspects, etc., of another implementation.

[0193] As is widely recognized, the use of personally identifiable information should comply with privacy policies and practices that are generally accepted to meet or exceed industry or governmental requirements for protecting user privacy. Specifically, personally identifiable information data should be managed and processed to minimize the risk of unintentional or unauthorized access or use, and the nature of authorized use should be clearly explained to users.

[0194] Although the foregoing has been described in considerable detail for clarity, it will be apparent that certain changes and modifications can be made without departing from the principles of the invention. It should be noted that many alternative ways exist to implement both the processes and apparatus described herein. Therefore, embodiments of the invention should be considered illustrative rather than restrictive, and this specification is not limited to the details given herein, but can be modified within the scope of the appended claims and their equivalents.

Claims

1. An apparatus for a user equipment (UE), the apparatus comprising: One or more processors; and A memory storing instructions that, when executed by the one or more processors, configure the device to: Encode a first Hybrid Automatic Repeat Request Acknowledgment (HARQ-ACK) and a second HARQ-ACK within a single time slot for transmission to the base station. The first HARQ-ACK is transmitted via a first Physical Uplink Control Channel (PUCCH), and the second HARQ-ACK is transmitted via a second PUCCH. Based on encoding the first HARQ-ACK and the second HARQ-ACK within the single time slot, and based on the UE's configuration, responding to one or more additional uplink (UL) signals that conflict with at least one of the first HARQ-ACK and the second HARQ-ACK within the single time slot, and The instructions also configure the device to transmit a first additional UL signal via PUCCH and a second additional UL signal via the Physical Uplink Shared Channel (PUSCH) that would conflict with at least one of the first HARQ-ACK and the second HARQ-ACK within the single time slot. Both the first HARQ-ACK and the second HARQ-ACK are reused; Multiplex the first additional UL signal via PUCCH with the multiplexed first HARQ-ACK and second HARQ-ACK; and The second additional UL signal via PUSCH is multiplexed with the multiplexed first HARQ-ACK and second HARQ-ACK and the multiplexed first additional UL signal via PUCCH.

2. The apparatus of claim 1, wherein the instructions further configure the apparatus to: when the configuration of the UE includes avoiding transmission of an additional UL signal via PUCCH that would conflict with at least one of the first HARQ-ACK and the second HARQ-ACK in the single time slot, in response to recognizing that the additional UL signal would conflict with at least one of the first HARQ-ACK and the second HARQ-ACK in the single time slot, avoid transmission of the additional UL signal via PUCCH.

3. The apparatus of claim 1, wherein the instructions further configure the apparatus to: when the configuration of the UE includes avoiding transmission of an additional UL signal via PUSCH that would conflict with at least one of the first HARQ-ACK and the second HARQ-ACK in the single time slot, in response to recognizing that the additional UL signal would conflict with at least one of the first HARQ-ACK and the second HARQ-ACK in the single time slot, avoid transmission of the additional UL signal via PUSCH.

4. The apparatus of claim 1, wherein the instructions further configure the apparatus to: when the configuration of the UE includes transmitting an additional UL signal via PUCCH that would conflict with at least one of the first HARQ-ACK and the second HARQ-ACK within the single time slot: Reuse both the first HARQ-ACK and the second HARQ-ACK; and The additional UL signal via PUCCH is multiplexed with the multiplexed first HARQ-ACK and second HARQ-ACK.

5. The apparatus of claim 1, wherein the instructions further configure the apparatus to: when the configuration of the UE includes transmitting an additional UL signal via PUCCH that would conflict with at least one of the first HARQ-ACK and the second HARQ-ACK within the single time slot: Both the first HARQ-ACK and the second HARQ-ACK are reused; If the payload of the UL signal via PUCCH is limited, the first HARQ-ACK is multiplexed with the UL signal via PUCCH; or If the payload of the UL signal via PUCCH is limited, the second HARQ-ACK is multiplexed with the UL signal via PUCCH.

6. A method for a user equipment (UE) to use for wireless communication, comprising: Encode a first Hybrid Automatic Repeat Request Acknowledgment (HARQ-ACK) and a second HARQ-ACK within a single time slot for transmission to the base station. The first HARQ-ACK is transmitted via a first Physical Uplink Control Channel (PUCCH), and the second HARQ-ACK is transmitted via a second PUCCH. Based on encoding the first HARQ-ACK and the second HARQ-ACK within the single time slot, and based on the UE's configuration, responding to one or more additional uplink (UL) signals that conflict with at least one of the first HARQ-ACK and the second HARQ-ACK within the single time slot, and The method further includes: When the configuration of the UE includes transmitting a first additional UL signal via PUCCH and a second additional UL signal via the Physical Uplink Shared Channel (PUSCH) that would conflict with at least one of the first HARQ-ACK and the second HARQ-ACK in the single time slot: Both the first HARQ-ACK and the second HARQ-ACK are reused; Multiplex the first additional UL signal via PUCCH with the multiplexed first HARQ-ACK and second HARQ-ACK; and The second additional UL signal via PUSCH is multiplexed with the multiplexed first HARQ-ACK and second HARQ-ACK and the multiplexed first additional UL signal via PUCCH.

7. The method of claim 6, wherein when the configuration of the UE includes avoiding transmission of an additional UL signal via PUCCH that would conflict with at least one of the first HARQ-ACK and the second HARQ-ACK in the single time slot, transmission of the additional UL signal via PUCCH is avoided in response to recognizing that the additional UL signal would conflict with at least one of the first HARQ-ACK and the second HARQ-ACK in the single time slot.

8. The method of claim 6, wherein when the configuration of the UE includes avoiding transmission of an additional UL signal via PUSCH that would conflict with at least one of the first HARQ-ACK and the second HARQ-ACK in the single time slot, transmission of the additional UL signal via PUSCH is avoided in response to the recognition that the additional UL signal would conflict with at least one of the first HARQ-ACK and the second HARQ-ACK in the single time slot.

9. The method of claim 6, further comprising: When the configuration of the UE includes transmitting an additional UL signal via PUCCH that would conflict with at least one of the first HARQ-ACK and the second HARQ-ACK within the single time slot: Reuse both the first HARQ-ACK and the second HARQ-ACK; and The additional UL signal via PUCCH is multiplexed with the multiplexed first HARQ-ACK and second HARQ-ACK.

10. The method of claim 6, further comprising: When the configuration of the UE includes transmitting an additional UL signal via PUCCH that would conflict with at least one of the first HARQ-ACK and the second HARQ-ACK within the single time slot: Both the first HARQ-ACK and the second HARQ-ACK are reused; If the payload of the UL signal via PUCCH is limited, the first HARQ-ACK is multiplexed with the UL signal via PUCCH; or If the payload of the UL signal via PUCCH is limited, the second HARQ-ACK is multiplexed with the UL signal via PUCCH.

11. An apparatus for supporting multiple Hybrid Automatic Repeat Request Acknowledgment (HARQ-ACK) transmissions within a single time slot, the apparatus comprising: Apparatus for performing the operations included in the method according to any one of claims 6 to 10.

Images