Extended One-Shot HARQ-ACK Codebook Transmission

Abstract

According to some embodiments, a method implemented by a wireless device for transmitting a Type-3 Hybrid Automatic Repeat Request-Acknowledgement (HARQ-ACK) codebook includes receiving downlink control information (DCI) requesting a Type-3 HARQ-ACK codebook and an indication of a priority associated with the Type-3 HARQ-ACK codebook, and transmitting the Type-3 HARQ-ACK codebook to a network node based on the DCI request and the priority indication.

Description

Technical Field

[0001] Embodiments of the present disclosure are directed to wireless communication, and more particularly to transmitting an extended one-shot hybrid automatic repeat request acknowledgement (HARQ ACK) codebook.

Background Art

[0002] Generally, all terms used herein should be interpreted according to their ordinary meaning in the relevant technical field, unless a different meaning is clearly given and / or implied from the context in which the term is used. All references to an element, apparatus, component, means, step, etc. should be construed openly as referring to at least one instance of the element, apparatus, component, means, step, etc., unless otherwise explicitly stated. None of the steps of any of the methods disclosed herein need to be performed in the exact order disclosed, unless the step is explicitly described as following or preceding another step and / or it is implicit that the step must follow or precede another step. Any feature of any of the embodiments disclosed herein may, where appropriate, be applied to any other embodiment. Similarly, any advantage of any of the embodiments may be applied to any other embodiment, and vice versa. Other objects, features, and advantages of the enclosed embodiments will become apparent from the following description.

[0003] The New Radio (NR) standards in the Third Generation Partnership Project (3GPP) provide services for multiple use cases, including advanced mobile broadband (eMBB), ultra-high reliability low-latency communication (URLLC), and machine-type communication (MTC). Each of these services has different technical requirements. For example, the general requirements for eMBB are high data rates with moderate latency and moderate coverage, while URLLC services require low-latency, high-reliability transmission, but with a potentially moderate data rate.

[0004] One solution for low-latency data transmission is shorter transmission time intervals. In NR, in addition to single-slot transmission, mini-slot transmission is also used to reduce latency. Mini-slots are a concept used in scheduling. Downlink, mini-slots can consist of 2, 4, or 7 orthogonal frequency division multiplexing (OFDM) symbols, while uplink, mini-slots can be any number of OFDM symbols from 1 to 14. The concepts of slots and mini-slots are not specific to any particular service. Mini-slots may be used for eMBB, URLLC, or other services.

[0005] Figure 1 is a time and frequency diagram showing an example of radio resources in NR. The horizontal axis represents time, and the other axis represents frequency. Each resource element corresponds to one OFDM subcarrier within one OFDM symbol interval.

[0006] In 3GPP NR, downlink control information (DCI) transmitted over the physical downlink control channel (PDCCH) is used to indicate downlink data-related information, uplink-related information, power control information, slot format instructions, and more. Different DCI formats are associated with each control signal, and UEs identify them based on different Radio Network Temporary Identifiers (RNTIs).

[0007] The UE is configured by upper-layer signaling that monitors DCIs of different resources with different periodicities. DCI formats 1_0, 1_1, and 1_2 are used to schedule downlink data transmitted over a physical downlink shared channel (PDSCH) and include time and frequency resources for downlink transmission, as well as modulation and coding information, HARQ (Hybrid Auto Retransmission Request) information, etc.

[0008] For downlink semi-persistent scheduling (SPS) and uplink configured grant type 2, some scheduling, including periodicity, is provided by the higher-layer configuration, while the remainder of the scheduling information, such as time-domain and frequency-domain resource allocation and modulation coding, is provided by DCI in the PDCCH.

[0009] Uplink control information (UCI) is control information sent by the user equipment (UE) to the gNB. It consists of a hybrid ARQ acknowledgment (HARQ-ACK), which is feedback information indicating whether the transport block reception was successful for the received downlink transport block. It includes channel status information (CSI) related to downlink channel conditions, which provides the gNB with channel-related information useful for downlink scheduling, including information about multi-antenna and beam shaping schemes. The UCI also includes a scheduling request (SR), which indicates that uplink resources are needed for uplink data transmission.

[0010] UCI is typically transmitted over the Physical Uplink Control Channel (PUCCH). However, if a UE is transmitting data over a PUSCH when a valid PUSCH resource is already present, the UCI can be multiplexed with the uplink data and transmitted over the PUSCH instead, provided the timeline requirements for UCI multiplexing are met.

[0011] The UE uses the Physical Uplink Control Channel (PUCCH) to send a HARQ-ACK feedback message in response to the reception of downlink data transmissions. The UE also uses it to send a CSI or request an uplink grant to transmit uplink data.

[0012] NR includes multiple PUCCH formats that support different UCI payload sizes. PUCCH formats 0 and 1 support UCIs of 2 bits or less, while PUCCH formats 2, 3, and 4 can support UCIs of more than 2 bits. Regarding PUCCH transmission duration, PUCCH formats 0 and 2 are considered short PUCCH formats that support PUCCH durations of one or two OFDM symbols, while PUCCH formats 1, 3, and 4 are considered long formats that can support PUCCH durations of 4 to 14 symbols.

[0013] NR also includes generating and transmitting HARQ feedback. The procedure for receiving a downlink transmission is as follows: The UE first monitors and decodes the PDDCH in slot n, which points to the downlink data scheduled within the slot n+K0 (where K0 is greater than or equal to 0). The UE then decodes the data in the corresponding PDSCH. Based on the decoding result, the UE sends a proper decoded acknowledgment (ACK) or negation acknowledgment (NACK) to the gNB at time slot n+K0+K1 (if slot aggregation n+K0 is replaced by the slot where the PDSCH ends). Both K0 and K1 are indicated in the DCI. The resource for sending the acknowledgment is indicated by the PUCCH resource indicator (PRI) field in the DCI, which points to one of the PUCCH resources set up by the upper layer.

[0014] Depending on the downlink / uplink slot configuration, or whether carrier aggregation or code block group (CBG) transmissions are used on the downlink, it may be necessary to multiplex feedback to several PDSCHs in a single feedback. This is done by configuring the HARQ-ACK codebook. In NR, the UE can be configured to multiplex the A / N bits using a semi-static or dynamic codebook.

[0015] Figure 2 shows the transmission timeline for a scenario involving two PDSCHs and one feedback. In the illustrated example, a total of four PUCCH resources are configured, and the PRI indicates that PUCCH2 is used for HARQ feedback. The timing of sending the HARQ feedback is determined based on both the PDSCH transmission slot (K0) referencing the PDCCH slot and the PUCCH slot (K1) containing the HARQ feedback. The following describes how PUCCH2 is selected from the four PUCCH resources, based on the 3GPP Rel-15 procedure.

[0016] NR Rel-15 allows a UE to be configured with up to four PUCCH resource sets for transmitting HARQ-ACK information. Each set is associated with a range of UCI payload bits containing the HARQ-ACK bits. The first set is always associated with one or two HARQ-ACK bits and therefore contains only PUCCH format 0 or 1, or both. If other sets are configured, their payload value range (minimum maximum) is provided by the configuration, excluding the maximum value of the last set for which the default value is used, and the minimum value of the second set being 3. The first set can contain up to 32 PUCCH resources in PUCCH format 0 or 1. The other sets can contain up to 8 bits in format 2, 3, or 4.

[0017] As described above, the UE determines the slot for sending the HARQ-ACK bit in the PUCCH corresponding to the PDSCH scheduled or activated by the DCI, via the K1 value provided by the configuration or the corresponding DCI field. The UE forms a codebook from the HARQ-ACK bits, including the associated PUCCH in the same slot, via the corresponding K1 value.

[0018] The UE determines the PUCCH resource set whose codebook size falls within the corresponding range of the payload values ​​associated with that set.

[0019] The UE determines the PUCCH resources of a set if the set is configured with up to eight PUCCH resources, based on the fields in the last DCI associated with the corresponding PDSCH. If the set is the first set and is configured with more than eight resources, the PUCCH resources of that set are determined by the fields in the last DCI associated with the corresponding PDSCH and an implicit rule based on the Control Channel Element (CCE).

[0020] A PUCCH resource for HARQ-ACK transmission may overlap in time with other PUCCH resources for CSI and / or SR transmission, as well as other PUCCH resources for PUSCH transmission in the slot. In the case of overlapping PUCCH and / or PUSCH resources, the UE first resolves any overlap between PUCCH resources by determining which PUCCH resource holds the entire UCI (including the HARQ-ACK bits) so that the UCI multiplexing timeline requirements are met. There may be partial or complete CSI bit withdrawals to multiplex the UCI on the determined PUCCH resource. Next, the UE resolves any overlap between PUCCH and PUSCH resources by multiplexing the UCI on the PUSCH resource, provided that the timeline requirements for UCI multiplexing are met.

[0021] As mentioned above, the codebook consists of either a semi-static (Type 1) HARQ codebook or a dynamic (Type 2) HARQ codebook. A Type 1 or semi-static codebook consists of a bit sequence in which each element contains A / N bits from possible allocations in a particular slot, carrier, or transport block (TB). If the UE is configured with a CBG and / or Time-Domain Resource Allocation (TDRA) table containing multiple entries, multiple bits are generated for each slot and TB (see below). The codebook is derived regardless of the actual PDSCH scheduling. The size and format of the semi-static codebook are pre-configured based on the parameters mentioned. The disadvantage of the semi-static HARQ ACK codebook is that its size is fixed and the bits are stored in the feedback matrix regardless of whether there is a transmission or not.

[0022] If the UE has a TDRA table with multiple time-domain resource allocation entries, the table is pruned (i.e., entries are removed based on a specified algorithm) to derive a TDRA table containing only non-overlapping time-domain allocations. Then, one bit is stored in the HARQ CB for each non-overlapping entry (assuming the UE can support receiving multiple PDSCHs in a slot).

[0023] In Type 2 or Dynamic HARQ codebooks, the A / N bit is present in the codebook only if a corresponding transmission is scheduled. To avoid any confusion between the gNB and UE regarding the number of PDSCHs to which the US must send feedback, a Counter Downlink Allocation Indicator (DAI) field exists in the downlink allocation, which shows the cumulative number of {serving cell, PDCCH opportunity} pairs for which the PDSCH has been scheduled for the UE up to the current PDCCH. In addition, there is another field called Total DAI, which, if present, shows the total number of {serving cell, PDCCH opportunity} up to all PDCCHs (including it) of the current PDCCH monitoring opportunity. The timing for sending HARQ feedback is determined based on both the PDSCH transmission slot (K0) referencing the PDCCH slot and the PUCCH slot (K1) containing the HARQ feedback.

[0024] Rel-16 includes an extended dynamic codebook, or an extended Type 2 codebook based on a Type 2 codebook, which allows for the retransmission of HARQ feedback corresponding to the HARQ process used. If, for either reason, the scheduled codebook is not received, the gNB can request a retransmission of the feedback. A new Feedback Indicator (NFI), a toggle bit, is added to the DCI to indicate whether the HARQ-ACK feedback from the UE has been received by the gNB. If toggled, the UE assumes that the reported feedback was properly received. Otherwise, if the gNB failed to receive the scheduled PUCCH, the UE is expected to retransmit the feedback. In the latter case, the DAI (C / T-DAI) is not reset; instead, the DAI accumulates within the PDSCH group until the NFI for the PDSCH group is toggled.

[0025] Because the initiation of additional HARQ feedback reports occurs with ambiguous timing relationships to associated PDSCHs, PDSCH grouping is introduced. A PDSCH group is defined as a PDSCH originally indicated as holding HARQ-ACK information in the same PUCCH. PDSCH grouping allows the gNB to explicitly indicate which codebooks are missing. The group index is explicitly signaled in the scheduling DCI. Two PDSCH groups are supported when extended dynamic codebooks are configured. Along with the group ID, the gNB signals a request group ID, which is a 1-bit field. By referring to the group ID (ID), request ID (RI), and the value of the NFI field in the DCI, the UE can determine whether the next feedback opportunity should indicate only the initial transmission or also indicate a retransmission of feedback corresponding to the indicated group and associated PDSCH.

[0026] Similar to NR, the DAI value is also included in the uplink grant scheduling PUSCH. As an additional feature, gNB can resolve any potential ambiguity on the UE side by showing the DAI value for each group separately in the uplink grant.

[0027] NR also includes a one-shot (Type 3) HARQ codebook. The UE can be configured to monitor feedback requests for the HARQ-ACK codebook, including all downlink HARQ processes. Feedback can be requested in downlink DCI format 1_1. In response to a trigger, the UE reports HARQ-ACK feedback for all downlink HARQ processes. The feedback format can be configured to be part of the one-shot HARQ feedback to the component carrier, whether CBG-based HARQ-ACK or TB-based HARQ-ACK.

[0028] In addition, to resolve any possible ambiguity between the gNB and the UE that may occur due to possible misdetection of the PDCCH, the UE can be configured to report the corresponding latest NDI value of the latest received PDSCH for its HARQ process together with the corresponding HARQ-ACK of the received PDSCH. From the perspective of the gNB, when the NDI value is the same as the last transmitted value, it indicates that the reported HARQ-ACK feedback properly corresponds to the HARQ process that includes the pending feedback. Otherwise, the mismatch indicates that the UE is reporting old feedback.

[0029] Rel-15 supports the repetition of PUCCH over multiple slots. This is useful, for example, for increasing coverage. Only the long PUCCH formats, i.e., formats 1, 3, and 4, are supported. The number of repetitions (2, 4, or 8 slots) is semi-statically configured by the upper layer parameter nrofSlots of PUCCH-FormatConfig in the PUCCH-config IE. The same resource allocation (e.g., the same number of consecutive symbols, the same start symbol) is used for each repetition over multiple slots. See Section 9.2.6 of TS 38.213 for a complete description.

[0030] The semi-static configuration of the number of PUCCH repetitions by nrofSlots of PUCCH-FormatConfig is done separately for each PUCCH format. Once configured, it applies to all PUCCH resources of that particular format.

[0031] NR also includes sub-slot HARQ-ACK. NR Rel-16 includes extensions to HARQ-ACK feedback to support different services and also for possible high-speed HARQ-ACK feedback for URLLC, supporting more than one PUCCH to hold HARQ-ACK within a slot. This includes new HARQ-ACK timings within a sub-slot unit, i.e., K1 indication within a sub-slot unit. The sub-slot settings of PUCCHs holding HARQ-ACK can be set from two options, namely "2 symbols × 7" and "7 symbols × 2" for sub-slot lengths of 2 symbols and 7 symbols respectively. The indication of K1 is the same as in Rel-15, i.e., K1 is indicated by DCI scheduling PDSCH. For determining the HARQ-ACK timing, there is an association of the scheduled PDSCH with the sub-slot setting such that if the scheduled PDSCH ends in sub-slot n, the corresponding HARQ-ACK is reported in sub-slot n + K1. In a sense, the sub-slot-based HARQ-ACK timing works similar to the slot-based procedure of Rel-15 by replacing the unit of K1 from slot to sub-slot.

[0032] There are some restrictions regarding PUCCH resources for sub-slot HARQ-ACK. That is, only one PUCCH resource setting is used for all sub-slots of a certain slot. Further, any PUCCH resource for sub-slot HARQ-ACK cannot cross the sub-slot boundary.

[0033] Figure 3 shows an example of associating each PDSCH with a certain sub-slot for HARQ feedback by using the K1 value in a sub-slot unit. Specifically, the indication of K1 is based on the sub-slot of the "7 symbols × 2" setting for two PUCCHs in two sub-slots holding the HARQ feedback of PDSCH transmission.

[0034] NR also includes HARQ-ACK priority indications. Rel-16 allows for two levels of PHY priority to be indicated in the DCI for HARQ-ACK corresponding to dynamically scheduled PDSCHs, or in the RRC configured for HARQ-ACK corresponding to each downlink SPS configuration. Priority indications can be used to determine the priority of HARQ-ACK codebooks for uplink collision handling. NR Rel-16 supports up to two HARQ-ACK codebooks with different priorities configured simultaneously. This includes slot-based and sub-slot-based, both slot-based, or both sub-slot-based.

[0035] Currently, several challenges exist. For example, existing solutions do not facilitate the use of Type 3 HARQ-ACK codebooks with priority indices. In Type 3 HARQ-ACK codebook configurations, HARQ-ACK bits designated as high priority are not distinguished from those designated as low priority. Existing solutions do not assign different physical priority levels (high priority, low priority) to Type 3 HARQ-ACK codebooks for uplink prioritization and multiplexing procedures. Existing solutions only facilitate the use of DCI format 1_1 to trigger Type 3 HARQ codebooks. Other examples include ZTE ET AL's "On the scope of unlicensed band URLLC / IIoT operation," 3GPP DRAFT;RP-200816, 3GPP Third Generation Partnership Project, June 22, 2020; HUAWEI ET AL's "Compatibility analysis between Rel-16 URLLC and Rel-16 NR-U," 3GPP DRAFT;RP-200892, 3GPP Third Generation Partnership Project, June 22, 2020; and VIVO's "Views on the objectives for unlicensed band URLLC / IIoT operation," 3GPP DRAFT; RP-200947, Third Generation Partnership Project (3GPP), can be found on June 22, 2020. [Overview of the project]

[0036] Based on the above description, several challenges currently exist regarding the transmission of one-shot hybrid automatic retransmission request acknowledgment (HARQ ACK) codebooks. Several aspects of this disclosure and their embodiments may provide solutions to these or other challenges. For example, certain embodiments extend existing type 3 HARQ-ACK codebooks. Specifically, certain embodiments support extended type 3 HARQ-ACK codebook configurations that take into account different priority indices of HARQ-ACK bits. Certain embodiments assign different physical priority levels (high priority, low priority) to extended type 3 HARQ-ACK codebooks for uplink prioritization and multiplexing procedures. Certain embodiments enable various DCI formats to trigger extended type 3 HARQ codebooks.

[0037] According to some embodiments, a method implemented by a wireless device to transmit a Type 3 HARQ-ACK codebook includes receiving a DCI requesting a Type 3 HARQ-ACK codebook and a priority instruction associated with the Type 3 HARQ-ACK codebook, and transmitting the Type 3 HARQ-ACK codebook to a network node based on the DCI request and priority instruction.

[0038] In certain embodiments, a priority instruction is associated with a HARQ-ACK bit corresponding to one of several PDSCHs, and only the HARQ bits associated with the PDSCH are included in the Type 3 HARQ-ACK codebook. In some embodiments, the Type 3 HARQ-ACK codebook includes HARQ-ACK bits for all HARQ processes, regardless of the priority instruction.

[0039] In certain embodiments, a Type 3 HARQ-ACK codebook transmission is in an uplink conflict with another transmission, and the conflict is resolved based on a priority instruction. The priority instruction may be included in the DCI request. For example, the DCI request may include a priority associated with the DCI and a separate priority associated with the Type 3 HARQ-ACK codebook transmission. In some embodiments, the priority associated with the Type 3 HARQ-ACK codebook may be the same as the priority associated with the DCI. In some embodiments, the DCI request includes transmission parameters for the Type 3 HARQ-ACK codebook transmission (e.g., BLER target, MCS, transmit power, etc.), and the priority instruction is based on the transmission parameters.

[0040] In certain embodiments, the priority instruction may indicate the physical uplink control channel (PUCCH) setting to use for Type 3 HARQ-ACK codebook transmissions.

[0041] In certain embodiments, the Type 3 HARQ-ACK codebook is transmitted via PUCCH. In some embodiments, the DCI request is for scheduling PUSCH data, and the Type 3 HARQ-ACK codebook is transmitted via physical PUCCH.

[0042] In a particular embodiment, the DCI request includes one of DCI format 0_1, DCI format 0_2, DCI format 1_2, and DCI format 1_1.

[0043] According to some embodiments, the wireless device comprises a processing circuit capable of operating to carry out any of the wireless device methods described above.

[0044] Also disclosed is a computer program product comprising a non-temporary computer-readable medium for storing computer-readable program code, wherein the computer-readable program code, when executed by a processing circuit, is operable to perform one of the methods performed by the wireless device described above.

[0045] According to some embodiments, a method implemented by a network node to receive a Type 3 HARQ-ACK codebook includes sending a DCI requesting a Type 3 HARQ-ACK codebook and a priority instruction associated with the Type 3 HARQ-ACK codebook to a wireless device, and receiving a Type 3 HARQ-ACK codebook from the wireless device based on the DCI request and priority instruction.

[0046] According to some embodiments, the network node comprises processing circuitry capable of performing any of the network node methods described above.

[0047] Also disclosed is a computer program product comprising a non-temporary computer-readable medium for storing computer-readable program code, wherein the computer-readable program code, when executed by a processing circuit, is operable to perform one of the methods performed by the network nodes described above.

[0048] Some embodiments may offer one or more of the following technical advantages. For example, certain embodiments extend the Type 3 HARQ-ACK codebook to support the transmission of dropped HARQ-ACK bits that could not be transmitted previously due to uplink resource contention. Such cases commonly occur when wireless systems serve mixed traffic of eMBB and URLLC data.

[0049] For a more complete understanding of the disclosed embodiments and their features and advantages, refer to the following description in conjunction with the accompanying drawings. [Brief explanation of the drawing]

[0050] [Figure 1] This is a time and frequency diagram showing an example of radio resources in New Radio (NR). [Figure 2] This diagram shows the transmission timeline for a scenario that includes two PDSCHs and one feedback. [Figure 3] This figure shows an example where each PDSCH is associated with a sub-slot for HARQ feedback by using the K1 value in the sub-slot unit. [Figure 4] A block diagram showing an example of a wireless network. [Figure 5] This figure shows an example of user equipment according to several embodiments. [Figure 6] This is a flowchart illustrating an example method in a wireless device according to several embodiments. [Figure 7] This flowchart shows an example method in a network node according to several embodiments. [Figure 8] This is a schematic block diagram of wireless devices and network nodes in a wireless network according to several embodiments. [Figure 9] This figure shows an example of a virtualization environment according to several embodiments. [Figure 10] This figure shows an example of a communication network connected to a host computer via an intermediate network, according to several embodiments. [Figure 11] This figure shows an example of a host computer that communicates with user equipment via a base station through a partial wireless connection, according to several embodiments. [Figure 12] This flowchart shows the implementation methods according to several embodiments. [Figure 13] This flowchart shows a method implemented in a communication system according to several embodiments. [Figure 14]This flowchart shows a method implemented in a communication system according to several embodiments. [Figure 15] This flowchart shows a method implemented in a communication system according to several embodiments. [Modes for carrying out the invention]

[0051] As described above, several challenges currently exist regarding the transmission of one-shot hybrid automatic retransmission request acknowledgment (HARQ ACK) codebooks. Several aspects of this disclosure and their embodiments may provide solutions to these or other challenges. For example, certain embodiments extend existing type 3 HARQ-ACK codebooks. Specifically, certain embodiments support extended type 3 HARQ-ACK codebook configurations that take into account different priority indices of HARQ-ACK bits. Certain embodiments assign different physical priority levels (high priority, low priority) to extended type 3 HARQ-ACK codebooks for uplink prioritization and multiplexing procedures. Certain embodiments enable various DCI formats to trigger extended type 3 HARQ codebooks.

[0052] Specific embodiments are described in more detail with reference to the accompanying drawings. However, other embodiments are included within the scope of the subject matter disclosed herein, and the disclosed subject matter should not be construed as being limited only to the embodiments described herein. Rather, these embodiments are provided as examples to convey the scope of the subject matter to those skilled in the art.

[0053] In some embodiments, a Type 3 hybrid HARQ-ACK codebook is configured for a physical downlink shared channel (PDSCH) of a given priority index. In this embodiment, the Type 3 HARQ-ACK codebook is configured for a PDSCH of only a given priority index, if different priority indices are assigned to the PDSCH. A Type 3 HARQ-ACK codebook is also known as a one-shot HARQ-ACK codebook. In the following discussion, the term (extended) Type 3 HARQ-ACK codebook is generally used to indicate an extension / modification of the Rel-16 Type 3 HARQ-ACK codebook. It is understood that the 3GPP specification may use different specific terminology for extensions.

[0054] The examples described below assume that priority indices have non-negative integer values, with higher priority index values ​​indicating higher priority designations. For example, Rel-16 provides two levels of priority indices {0,1}, where transmissions with priority index=1 are processed with higher priority than transmissions with priority index=0. While it is possible to have more than two levels of priority indices, for simplicity, the following considerations assume two levels of priority indices {0,1}. It will be understood by those skilled in the art that the same design principles can be applied to systems with more than two levels of priority indices.

[0055] Instead of using a Type 3 HARQ-ACK codebook to transmit all HARQ-ACK bits regardless of priority index, some embodiments use a Type 3 HARQ-ACK codebook configuration that includes only HARQ-ACK bits in response to a PDSCH of a given priority index. For a system with two levels of priority, it is possible to configure a first Type 3 HARQ-ACK codebook associated with priority index 0 and a second Type 3 HARQ-ACK codebook associated with priority index 1.

[0056] In the extension, if the Downlink Control Information (DCI) requests a Type 3 codebook, and (a) the priority field is not set in the DCI, the Type 3 codebook includes all HARQ-ACK bits for all HARQ processes regardless of priority; (b) the priority field in the DCI is set to high priority, the Type 3 codebook includes only the HARQ-ACK bits associated with HARQ processes whose feedback is considered high priority; and (c) the priority field in the DCI is set to low priority, the Type 3 codebook includes only the HARQ-ACK bits associated with HARQ processes whose feedback is considered low priority.

[0057] For systems involving mixed eMBB-URLLC traffic, Rel-16 specifies that lower-priority uplink transmissions will be dropped if they conflict with higher-priority uplink transmissions. Potentially dropped uplink transmissions include HARQ-ACK bits associated with eMBB PDSCHs. Generally, HARQ-ACK bits associated with eMBB PDSCHs are expected to have priority index 0, and HARQ-ACK bits associated with URLLC PDSCHs are expected to have priority index 1. A type 3 HARQ-ACK codebook associated with priority index 0 can subsequently be triggered for the purpose of providing another opportunity to transmit a dropped HARQ-ACK bit associated with an eMBB PDSCH. Some embodiments may not necessarily support a type 3 HARQ-ACK codebook associated with priority index 1, as transmission of a HARQ-ACK codebook associated with priority index 1 takes precedence in the event of a conflict.

[0058] The triggering of a Type 3 HARQ-ACK codebook associated with priority index 0 can be achieved by a DCI configured in the priority indicator field. In other words, a DCI format having both of the following fields can trigger a Type 3 HARQ-ACK codebook associated with a particular priority index: (a) The “Priority Indicator” field. The presence or absence of this field may be determined by the Radio Resource Control (RRC) set via a parameter, e.g., “priorityIndicatorForDCI-Format1-1”. If present, it can be a 1-bit field with possible values ​​of 0 (indicating low priority) and 1 (indicating high priority). When set, the Physical Uplink Control Channel (PUCCH) resource for a given priority value is defined in one of two RRC settings PUCCH-Config IE. This can be a fixed link, where PUCCH-Config-0 always corresponds to feedback indicated by a priority value of 0, and PUCCH-Config-1 always corresponds to feedback indicated by a priority value of 1. Additionally, each PUCCH-Config can be RRC configurable for the corresponding priority value of the Extended Type 3 HARQ feedback. (b) The "One-Shot HARQ-ACK Request" field. The presence or absence of this field can be set in the RRC via the parameter "pdsch-HARQ-ACK-OneShotFeedback-r16". If present, it can be a 1-bit field with possible values ​​of 0 (indicating no trigger for a one-shot HARQ-ACK) and 1 (indicating a trigger for a one-shot HARQ-ACK).

[0059] In some embodiments, when the UE receives a DCI in which the “Priority Indicator” field is present and has a value of 0 and the “One-Shot HARQ-ACK Request” field is present and has a value of 1, the UE configures a Type 3 HARQ-ACK codebook that includes a HARQ-ACK associated with a low-priority HARQ-ACK bit. In this case, the Type 3 HARQ-ACK codebook configuration must include a HARQ-ACK bit associated with a low-priority PDSCH and exclude a HARQ-ACK bit associated with a high-priority PDSCH. The PDSCH includes both dynamically scheduled PDSCHs and semi-permanently scheduled PDSCHs.

[0060] In one example, the size of a Type 3 HARQ-ACK codebook is determined according to all HARQ processes, and the bit positions for excluded priority levels (e.g., high priority) HARQ-ACKs are always assigned "NACK" to exclude the HARQ-ACK bits for a specific priority level (e.g., high priority). In another example, the size of a Type 3 HARQ-ACK codebook is determined according to the included priority levels (e.g., low priority) HARQ processes, and there are no bit positions for excluded priority levels (e.g., high priority) HARQ-ACKs.

[0061] Some embodiments include DCI formats for triggering extended type 3 HARQ-ACK codebooks. The Rel-16 specification allows triggering type 3 HARQ-ACK using only DCI format 1_1. Certain embodiments remove this limitation. For example, in some embodiments, any DCI format that allows configurable DCI fields can be used for triggering.

[0062] For example, when DCI schedules a PDSCH transmission using DCI format 1_2, certain embodiments include a new field for a "one-shot HARQ-ACK request". The presence or absence of this field may be RRC configurable by a new RRC parameter (i.e., a higher-layer parameter). For example, if the higher-layer parameter "pdsch-HARQ-ACK-OneShotFeedback-format1_2" is set, the "one-shot HARQ-ACK request" field has a field size of 1 bit; otherwise, the field size is 0 bits.

[0063] In the baseline, the Type 3 HARQ-ACK codebook, like Rel-16, includes all HARQ-ACK bits for all CCs set for UEs in the PUCCH group.

[0064] In one embodiment, a Type 3 HARQ-ACK codebook includes all HARQ-ACK bits regardless of their corresponding priority.

[0065] In another embodiment, a Type 3 HARQ-ACK codebook includes all HARQ-ACK bits that did not have the opportunity to be sent. For example, low-priority HARQ-ACK bits withdrawn in resource contention procedures, or HARQ-ACK bits indicated by non-numeric K1 values, both of which can jointly be designated as pending HARQ-ACK bits. This is a property associated with each HARQ process. If a new downlink allocation is received indicating the same HARQ process with pending HARQ-ACKs, the pending indication for the HARQ-ACKs of this indicated HARQ process is cleared. HARQ-ACK bits that had the opportunity to be sent are not included. In such an example, the "One-Shot HARQ-ACK Request" field can be understood as a field indicating the transmission of pending HARQ-ACK feedback.

[0066] While this discussion focuses on the basic Type 3 HARQ-ACK codebook procedure, other associated features can be configured similarly. For example, the HARQ-ACK bit can be either a CBG-level ACK / NACK or a TB-level ACK / NACK, depending on the RRC configuration (e.g., RRC parameter pdsch-HARQ-ACK-OneShotFeedbackCBG). In another example, the NDI bit may or may not be included for each reported ACK / NACK, depending on the RRC configuration (e.g., RRC parameter pdsch-HARQ-ACK-OneShotFeedbackNDI).

[0067] In another embodiment, the extended type 3 HARQ-ACK codebook includes only the HARQ-ACK bits of a predefined subset of HARQ processes. For example, it includes only the HARQ processes to which the PDSCH is initially dynamically scheduled, excluding HARQ processes used by SPS PDSCHs (including retransmissions of SPS PDSCHs dynamically scheduled by CS-RNTI). In one lower embodiment, the HARQ processes used by SPS are defined by an addressable HARQ process ID according to the formula specified in section 5.3.1 of TS 38.321. In another example, it includes only the HARQ-ACK bits of SPS PDSCHs, excluding the HARQ-ACK bits of dynamically scheduled PDSCHs.

[0068] In one embodiment, given HARQ process IDs ranging from 0 to N (assuming N is 15), a type 3 codebook can be instructed to include the HARQ-ACK bit for the following: ● A DCI requesting a Type 3 codebook containing HARQ-ACK bits for specific (bitmapped) HARQ process IDs, e.g., HARQ IDs 1, 5, and 7. ●Specific sets of HARQ IDs: For example, an RRC table can be constructed, allowing different HARQ IDs to be grouped together, for instance, HARQ IDs 0, 1, and 2 could be assigned to group index 1, and HARQ IDs 1, 5, and 6 to group index 2, and DCI could request a type 3 codebook for a specific group index. Alternatively, ●For all HARQ process IDs preceding ID X, for example, if DCI indicates X as 4, the UE will respond with a Type 3 codebook including the HARQ bits for the following: ○ Four recent scheduled HARQ processes ○Other options could be the following: ●HARQ ID 0-4, or ●HARQ ID NX~N (i.e., 12~16), or ● The first four HARQ process IDs, i.e., HARQ IDs 0-3, or ●The last four HARQ process IDs, namely HARQID 13-16.

[0069] In one embodiment, an extended type 3 HARQ-ACK codebook contains only the HARQ-ACK bits for a specific subset of HARQ processes. This subset can be specified by the standard, RRC-configured, or signaled by the DCI. If the subset is signaled by the DCI, there may be several predefined subsets, specified by the standard or RRC-configured, and the UE uses one of these subsets depending on the content of the DCI. The selection of a subset may be based on an explicit field in the DCI or by an implicit rule. In one example embodiment, different PUCCH resources are associated with different subsets, and the UE uses the subset associated with the PUCCH resource being used.

[0070] In another example, an extended type 3 HARQ-ACK codebook includes only the HARQ-ACK bits for scheduled cells indicated by the DCI. This functionality can be configurable by being dynamically indicated on / off in the RRC or DCI bits. It is intended to allow the network to obtain the HARQ-ACK bits for these HARQ processes that would not otherwise be sent due to lower priority, while keeping overhead to a minimum.

[0071] In one embodiment, an extended type 3 HARQ-ACK codebook includes only the HARQ-ACK bits of a subset of HARQ processes whose most recent HARQ-ACK timing value is equal to a non-numeric K1. Generally, the HARQ-ACK timing value is indicated by the "PDSCH-to-HARQ_feedback timing indicator" field in the downlink DCI format, e.g., format 1_1 or 1_2. The HARQ-ACK timing value can also be assigned by other means; for example, a UE may specify the HARQ-ACK timing of a withdrawn HARQ-ACK bit as a non-numeric K1.

[0072] The above behavior, in which the Extended Type 3 HARQ-ACK codebook includes only the HARQ-ACK bits of a subset of HARQ processes whose latest HARQ-ACK timing value is equal to a non-numeric value K1, can be demonstrated by one of the following means: -In one version, the instructions are set semi-statically by higher-layer parameters. -In another version, the DCI field also exhibits behavior that triggers a Type 3 HARQ-ACK codebook. -In yet another version, the DCI field “Priority Indicator” in DCI format 1_1 or 1_2 is used to indicate behavior. In this case, the priority indicator field may remain associated with the index of the HARQ-ACK codebook corresponding to the PUCCH-config, but may not be used for uplink collision handling. For example, a PUCCH containing a type 3 HARQ-ACK codebook is always processed with either low or high priority for uplink collision / duplicate handling purposes. Alternatively, a new DCI field could be introduced to demonstrate such behavior.

[0073] In some embodiments, the UE reports only a subset of HARQ processes corresponding to the indicated priority. After receiving a DCI request for a Type 3 codebook without scheduling downlink / uplink data, the UE reports pending / withdrawn feedback corresponding to the indicated priority.

[0074] The embodiments can be used in combination. For example, an extended type 3 HARQ-ACK codebook includes only previously withdrawn HARQ-ACK bits for dynamically scheduled PDSCHs.

[0075] In the embodiments described above, it is assumed that DCI indicates that an Extended Type 3 HARQ-ACK can also schedule a PDSCH. An Extended Type 3 HARQ-ACK codebook request can also be signaled without scheduling a PDSCH.

[0076] Some embodiments include transmit parameter settings for an extended type 3 HARQ-ACK codebook. In one embodiment, the transmit parameter settings for an extended type 3 HARQ-ACK codebook are determined by the contents held in the codebook. The transmit parameter settings can be RRC configured.

[0077] For example, if a one-shot codebook contains only low-priority HARQ-ACK bits, the transmit parameters can be associated with a higher BLER target, e.g., BLER target = 1e-2. For instance, a high code rate, a small number of resource elements, and a low transmit power level.

[0078] If the one-shot codebook includes high-priority HARQ-ACK bits (and may or may not include low-priority HARQ-ACK bits), you need to choose transmit parameters that achieve a low BLER target, for example, BLER target = 1e-4. For example, a low code rate, a large number of resource elements, and a high transmit power level.

[0079] Some embodiments include priority derivation based on transmit power settings. For example, transmit parameters such as BLER target, code rate, MCS, and transmit power may be signaled, and the priority of Type 3 codebooks (known as one-shot codebooks) is determined based on the signaled transmit parameter settings.

[0080] For example, if a Type 3 codebook conflicts with another codebook, and if the Type 3 codebook is set to a "relatively" high BLER target, high coding rate, high MC, or low transmit power, the Type 3 codebook is implicitly considered to have lower priority than the other codebook, and therefore, a priority-based conflict resolution principle can be implemented in which the lower-priority codebook is not transmitted.

[0081] If a Type 3 codebook conflicts with another codebook, and if the Type 3 codebook is set to a "relatively" low BLER target, low coding rate, low MC, or high transmit power, the Type 3 codebook is implicitly considered to have higher priority than the other codebook, and thus a priority-based conflict resolution principle can be implemented in which only the higher-priority codebook is transmitted and the others are not.

[0082] If a Type 3 codebook (without explicit priority designation) conflicts with another codebook that has explicitly designated a higher priority, the Type 3 codebook is considered to have lower priority than the other codebook. Therefore, a priority-based conflict resolution principle can be implemented where only the higher-priority codebook is transmitted and the others are not.

[0083] If a Type 3 codebook (without explicit priority designation) conflicts with another codebook that has a lower priority explicitly designated, the Type 3 codebook is considered to have higher priority than the other codebook. Therefore, a priority-based conflict resolution principle can be implemented where only the higher-priority codebook is transmitted and the others are not.

[0084] Some embodiments include prioritizing extended type 3 HARQ-ACK codebooks. For the purpose of resolving uplink resource conflicts, it may be necessary to specify a priority index for type 3 HARQ-ACK codebooks when they are triggered.

[0085] If a Type 3 HARQ-ACK codebook is triggered by a DCI that does not include the "Priority Indicator" field, for example, the Type 3 HARQ-ACK codebook will be assigned a priority index of 0 (i.e., low priority) for the purpose of resolving uplink resource contention.

[0086] When a Type 3 HARQ-ACK codebook is triggered by a DCI that includes a "Priority Indicator" field, for example, the same priority index as the "Priority Indicator" of the same DCI is assigned to the Type 3 HARQ-ACK codebook. That is, if the DCI that triggers the Type 3 HARQ-ACK has a "Priority Indicator" field with a value of 0, the Type 3 HARQ-ACK is assigned a priority index of 0 (i.e., low priority). On the other hand, if the DCI that triggers the Type 3 HARQ-ACK has a "Priority Indicator" field with a value of 1, the Type 3 HARQ-ACK is assigned a priority index of 1 (i.e., high priority).

[0087] In another example, a Type 3 HARQ-ACK codebook is given a fixed priority index, without considering the “priority indicator” field. For example, a Type 3 HARQ-ACK codebook is always given a priority index of 1 because it contains a complete list of all HARQ-ACK bits that did not have the opportunity to be sent.

[0088] Because there is a priority index for Type 3 HARQ-ACKs, if a resource conflict occurs, it is compared to the priority index value of other HARQ-ACK feedbacks. One way to resolve resource conflicts is that HARQ-ACKs with a high priority index are retained, and HARQ-ACKs with a low priority index are dropped.

[0089] In one embodiment, if a Type 3 HARQ-ACK codebook is assigned priority index 0 and such Type 3 HARQ-ACK codebook is withdrawn due to resource contention, two solutions are possible. (a) The relevant HARQ-ACK bits can be stored by the UE and await another transmission opportunity. For example, a withdrawn HARQ-ACK bit can be transmitted in another later triggered Type 3 HARQ-ACK codebook. This has the advantage of not requiring retransmission of the relevant PDSCH and only another attempt at the HARQ-ACK response. (b) Alternatively, the associated HARQ-ACK bits are not saved for another transmission opportunity. In this case, the associated PDSCH can be scheduled for retransmission.

[0090] In one embodiment, the UE does not expect a Type 3 HARQ-ACK codebook to conflict with other high-priority uplink transmissions. This requires the gNB to trigger it only if the Type 3 HARQ-ACK codebook is to be transmitted by the UE (i.e., not withdrawn in a resource contention procedure).

[0091] In one non-limiting embodiment, the priority of Type 3 codebooks can be predetermined according to one of the following options: ● Priority Index 0 < Priority of Type 3 Codebook < Priority Index 1, or ●Priority Index 0 < Priority Index 1 < Priority of Type 3 Codebook, or ●Type 3 codebook priority < priority index 0 < priority index 1.

[0092] In another embodiment, the Type 3 codebook includes HARQ-ACK feedback for all HARQ processes, regardless of their associated priority. The size of the Type 3 codebook can be reduced, for example, by considering only activated cells instead of all configured cells.

[0093] In some embodiments, a Type 3 CB consists of two (or more) subcodebooks. In one embodiment, after receiving a DCI request for a Type 3 codebook, instead of responding with a codebook containing a HARQ-ACK bit regardless of priority, the UE sends two separate Type 3 codebooks, one containing a HARQ-ACK bit associated with a low priority (hereinafter referred to as CB#0) and the other containing a HARQ-ACK bit associated with a high priority (hereinafter referred to as CB#1). Furthermore, the priority of each codebook is the same as the priority of the HARQ bits it holds, i.e., CB#0 is set to low priority and CB#1 is set to high priority.

[0094] Furthermore, the transmit settings for CB#0 and CB#1 codebooks can be the same or different (except for time-frequency resources). For example, CB#1 can be set to a relatively low BLER target or a low MCS scheme, or a low coding rate or high transmit power.

[0095] A triggering DCI may include transmission parameters for one codebook, and transmission parameters for the other codebook may be similarly directly indicated in the DCI, or derived from the transmission parameters of the DCI for one codebook. Derivation may be a function of RRC parameter setting; for example, if the DCI indicates a power level X for a high-priority codebook, the power level for a low-priority codebook may be derived as X / Y (where Y can be explained in the RRC setting).

[0096] In some embodiments, an extended type 3 HARQ-ACK codebook is used in combination with a type 1 or type 2 HARQ-ACK codebook. In these embodiments, the UE can operate with either an extended type 3 HARQ-ACK codebook or a type X (where X is either 1 or 2) HARQ-ACK codebook, and the DCI may indicate, for example, if the codebook is supposed to be type 3 or type X by a 1-bit field "One-Shot HARQ-ACK Request". Depending on the "Priority Indicator" field of the DCI, the UE behaves differently. ● If "Priority Indicator" = 0 or does not exist ○ If "One-shot HARQ-ACK request" = 0 or does not exist, ●UE constitutes the HARQ-ACK bit with priority index 0 in the Type X HARQ-ACK codebook (legacy behavior). Otherwise (i.e., "one-shot HARQ-ACK request" = 1), the UE constitutes the HARQ-ACK bits of the Type 3 HARQ-ACK codebook for all HARQ-ACK bits with priority index 0, including those canceled by PUCCH contention. ● Otherwise (i.e., "priority indicator" = 1) ○ If "One-shot HARQ-ACK request" = 0 or does not exist, ●UE constitutes N HARQ-ACK bits with priority index 1 in the Type X HARQ-ACK codebook (legacy behavior). Otherwise (i.e., "one-shot HARQ-ACK request" = 1), the UE constructs the HARQ-ACK bits of the Type 3 HARQ-ACK codebook for the N HARQ-ACK bits at priority index 1, but also constructs all the HARQ-ACK bits at priority index 0, which would otherwise be canceled by the transmission of the HARQ-ACK bits at priority index 1.

[0097] These embodiments allow the gNB to control whether high and low priority index HARQ-ACKs should be multiplexed or whether low priority HARQ-ACKs should be canceled (in case of conflict) according to the Rel-16 prioritization procedure.

[0098] In one variation, the UE may be shown an invalid PUCCH resource or invalid HARQ-ACK timing in a previous DCI for a high priority index, for example, a PDSCH-to-HARQ_feedback timing indicator that is impossible depending on the UE's processing capabilities. If, in a later DCI, the UE is configured with an extended type 3 HARQ-ACK code, and the DCI indicates “Priority Indicator” = 1, “One-Shot HARQ-ACK Request” = 1, and the indicated PUCCH resource is valid to send a HARQ-ACK, then the UE will include N HARQ-ACK bits for priority index 1 (as scheduled by the later DCI) and HARQ-ACK bits for priority index 1 that were not sent by being invalid (as scheduled by the earlier DCI). In some examples, the UE will also include HARQ-ACK bits for priority index 0 that are canceled.

[0099] In generalization, if the “One-Shot HARQ-ACK Request” field (or a similar field requiring feedback) is set to 1, the other “Priority Indicator” field is used to indicate the type of feedback the UE should send. In another example, if the “Priority Indicator” is reinterpreted as a serving cell indicator and is set to 1, the UE will respond to the HARQ process through the served cell indicated by this DCI. This makes it possible to reduce the overhead of uplink HARQ feedback. This method may require that the PUCCH resource holding type 3 feedback is pre-configured, either with the default priority (i.e., 0) or with a higher priority (i.e., 1).

[0100] Some embodiments select a PUCCH for an extended type 3 codebook. For example, after the UE determines a priority for a type 3 codebook as triggered by DCI, the priority may be used to determine the associated PUCCH-Config IE from the upper layer, thereby providing the parameters used for PUCCH transmission. PUCCH parameters may include K1 (for PUCCH timing), sub-slot / slot settings, PUCCH resource set settings, and / or power control. The priority may also be used to associate the priority with the PUCCH holding the type 3 codebook. This association may be necessary for conflict resolution if the PUCCH overlaps with other PUCCH / PUSCH resources.

[0101] The following rules may apply to HARQ codebook transmissions in PUCCH if at least one of the PUCCHs contains a Type 3 HARQ codebook. ● If the first DCI triggers a Type 3 codebook that has an associated PUCCH in a slot / sub-slot, the UE is not expected to receive a second DCI after the first DCI which indicates a PUCCH that is not a Type 3 HARQ-ACK codebook (i.e., a Type 1 or Type 2 codebook) that overlaps with the PUCCH associated with the Type 3 codebook. ● If a first PUCCH containing a Type 3 HARQ codebook overlaps with a second PUCCH containing a non-Type 3 HARQ codebook (i.e., a Type 1 or Type 2 codebook), the second PUCCH is withdrawn. In this case, the DCI that triggers the Type 3 codebook is after the DCI associated with the withdrawn PUCCH. ○In this case, the UE expects the priority associated with the first PUCCH (i.e., including the Type 3 codebook) to be the same as or higher than the priority associated with the withdrawn PUCCH (i.e., including the Type 1 or Type 2 codebook). ○Withdrawals will be implemented as long as the UE processing timeline is met. ●If the first PUCCH (corresponding to the previous DCI), which includes a Type 3 HARQ codebook, overlaps with the second PUCCH (corresponding to the later DCI), which also includes a Type 3 HARQ codebook, the first PUCCH will be withdrawn. ○In this case, the UE expects the priority of the first PUCCH to be the same as or lower than the priority of the second PUCCH. ○Withdrawals will be implemented as long as the UE processing timeline is met.

[0102] Some embodiments include simultaneous support for rel-16 type 3 codebooks and extended type 3 codebooks. Depending on the values ​​simultaneously shown for at least the “Priority Indicator” and “One-Shot HARQ-ACK Request” fields in the DCI format, the UE determines whether a rel-16 type 3 codebook should be followed or if it is new behavior (i.e., an extended type 3 codebook). The following table provides an example. TIFF0007846084000001.tif133170

[0103] As another variation, some embodiments include new fields to distinguish the behavior of rel-16 or the new extended type 3 codebook.

[0104] Figure 4 shows an example of a wireless network according to a particular embodiment. The wireless network may comprise and / or interface with any type of communication, telecommunications, data, cellular, and / or wireless network, or other similar types of systems. In some embodiments, the wireless network may be configured to operate according to a particular standard or other type of predefined rules or procedures. Thus, a particular embodiment of the wireless network may implement communication standards such as the Pan-European Digital Mobile Telephone System (GSM), Universal Mobile Telecommunications System (UMTS), Long Term Evolution (LTE), and / or other suitable 2G, 3G, 4G, or 5G standards, wireless local area network (WLAN) standards such as the IEEE 802.11 standard, and / or any other suitable wireless communication standards such as Global Interoperability for Microwave Access (WiMAX), Bluetooth, Z-Wave, and / or ZigBee standards.

[0105] Network 106 may comprise one or more backhaul networks, core networks, IP networks, public switched telephone networks (PSTN), packet data networks, optical networks, wide area networks (WANs), local area networks (LANs), wireless local area networks (WLANs), wired networks, wireless networks, metropolitan area networks, and other networks for enabling communication between devices.

[0106] Network node 160 and WD 110 comprise various components, which will be described in more detail later. These components cooperate to provide functionality for the network node and / or wireless device, such as providing wireless connectivity in the wireless network. In different embodiments, the wireless network may comprise any number of wired or wireless networks, network nodes, base stations, controllers, wireless devices, relay stations, and / or any other components or systems that can facilitate or participate in the communication of data and / or signals, whether via wired or wireless connections.

[0107] As used herein, a network node refers to a device that is capable, configured, and / or operable to communicate directly or indirectly with a wireless device and / or with other network nodes or devices in a wireless network for the purpose of enabling and / or providing wireless access to a wireless device and / or performing other functions (e.g., administration) in the wireless network.

[0108] Examples of network nodes include, but are not limited to, access points (APs) (e.g., wireless access points) and base stations (BSs) (e.g., wireless base stations, node B, evolved node B (eNB), and NR node B (gNB)). Base stations may be categorized based on the amount of coverage they provide (or, in other words, the base station's transmit power level), in which case they may be called femto base stations, pico base stations, micro base stations, or macro base stations.

[0109] A base station can be a relay node or relay donor node that controls relays. Network nodes may also include one or more (or all) parts of a distributed radio base station, such as a centralized digital unit and / or remote radio unit (RRU), sometimes called a remote radio head (RRH). Such a remote radio unit may or may not be integrated with an antenna as an antenna-integrated radio. Parts of a distributed radio base station are sometimes called nodes in a distributed antenna system (DAS). Further examples of network nodes include MSR equipment such as multistandard radio (MSR) BS, network controllers such as radio network controllers (RNC) or base station controllers (BSC), base transceiver stations (BTS), transmit points, transmit nodes, multicell / multicast cooperative entities (MCE), core network nodes (e.g., MSC, MME), O&M nodes, OSS nodes, SON nodes, positioning nodes (e.g., E-SMLC), and / or MDT.

[0110] As another example, a network node may be a virtual network node, as will be discussed in more detail later. However, more generally, a network node can represent any suitable device (or group of devices) that is configured, set up, and / or operational to enable, and / or provide access to a wireless network to wireless devices, or to wireless devices that have accessed the wireless network.

[0111] In Figure 4, the network node 160 includes a processing circuit 170, a device-readable medium 180, an interface 190, auxiliary equipment 184, a power supply 186, a power circuit 187, and an antenna 162. While the network node 160 shown in the illustrative wireless network of Figure 4 may represent a device including the illustrated combination of hardware components, other embodiments may comprise network nodes with different combinations of components.

[0112] It should be understood that a network node comprises any preferred combination of hardware and / or software required to carry out the tasks, features, functions, and methods disclosed herein. Furthermore, although the components of network node 160 are illustrated as a single box located within a larger box, or as a single box nested within multiple boxes, in practice a network node may comprise multiple different physical components that constitute a single illustrated component (for example, device-readable media 180 may comprise multiple separate hard drives and multiple RAM modules).

[0113] Similarly, network node 160 may be assembled from multiple physically distinct components (e.g., node B components and RNC components, or BTS components and BSC components), each of which may have its own components. In some scenarios where network node 160 has multiple distinct components (e.g., BTS components and BSC components), one or more of the distinct components may be shared among several network nodes. For example, a single RNC may control multiple node Bs. In such a scenario, each unique node B-RNC pair may, in some cases, be considered a single distinct network node.

[0114] In some embodiments, the network node 160 may be configured to support multiple radio access technologies (RATs). In such embodiments, some components may be duplicated (e.g., separate device-readable media 180 for different RATs), and some components may be reused (e.g., the same antenna 162 may be shared by RATs). The network node 160 may also include multiple sets of various illustrated components for different radio technologies, such as GSM, WCDMA, LTE, NR, WiFi, or Bluetooth radio technologies, integrated into the network node 160. These radio technologies may be integrated into the same or different chips or sets of chips, and other components within the network node 160.

[0115] The processing circuit 170 is configured to perform any decision operation, calculation operation, or similar operation (e.g., several acquisition operations) provided herein by the network node. These operations performed by the processing circuit 170 may include processing the information acquired by the processing circuit 170, for example by converting the acquired information into other information, comparing the acquired or converted information with information stored in the network node, and / or performing one or more operations based on the acquired or converted information and as a result of the decisions made by the processing.

[0116] The processing circuit 170 may include one or more combinations of microprocessors, controllers, microcontrollers, central processing units, digital signal processors, application-specific integrated circuits, field-programmable gate arrays, or any other suitable computing devices, resources, or combinations of hardware, software, and / or encoded logic, which are capable of operating to provide the functionality of the network node 160, either on its own or in combination with other network node 160 components such as a device-readable medium 180.

[0117] For example, the processing circuit 170 may execute instructions stored in the device-readable medium 180 or instructions stored in the memory within the processing circuit 170. Such functionality may include providing any of the various wireless features, functions, or benefits discussed herein. In some embodiments, the processing circuit 170 may include a system-on-a-chip (SOC).

[0118] In some embodiments, the processing circuit 170 may include one or more of the radio frequency (RF) transceiver circuit 172 and the baseband processing circuit 174. In some embodiments, the radio frequency (RF) transceiver circuit 172 and the baseband processing circuit 174 may be on separate chips (or sets of chips), boards, or units such as radio and digital units. In alternative embodiments, some or all of the RF transceiver circuit 172 and the baseband processing circuit 174 may be on the same chip or set of chips, board, or unit.

[0119] In some embodiments, some or all of the functionality described herein as being provided by a network node, base station, eNB, or other such network device may be implemented by a processing circuit 170 that executes instructions stored in a device-readable medium 180 or in memory within the processing circuit 170. In alternative embodiments, some or all of the functionality may be provided by the processing circuit 170 without executing instructions stored in a separate or individual device-readable medium, such as in a hardwired manner. In any of these embodiments, the processing circuit 170 may be configured to implement the described functionality, whether or not it executes instructions stored in a device-readable storage medium. The benefits provided by such functionality are enjoyed by the processing circuit 170 alone, or by the network node 160 as a whole, but not limited to other components of the network node 160, and / or generally by the end user and the wireless network.

[0120] The device-readable medium 180 may, for the time being, include any form of volatile or non-volatile computer-readable memory, including persistent storage, solid memory, remote-mount memory, magnetic media, optical media, random-access memory (RAM), read-only memory (ROM), mass storage media (e.g., hard disk), removable storage media (e.g., flash drive, compact disc (CD), or digital video disc (DVD)), and / or any other volatile or non-volatile, non-temporary device-readable and / or computer-executable memory device for storing information, data, and / or instructions that can be used by the processing circuit 170. The device-readable medium 180 may store any suitable instructions, data, or information, including other instructions that can be executed by the processing circuit 170 and used by the network node 160, including applications that include one or more computer programs, software, logic, rules, code, tables, etc. The device-readable medium 180 may be used to store any calculations performed by the processing circuit 170 and / or any data received via the interface 190. In some embodiments, the processing circuit 170 and the device-readable medium 180 may be considered integrated.

[0121] Interface 190 is used for wired or wireless signaling and / or data transmission between network node 160, network 106, and / or WD110. As shown in the figure, interface 190 includes a port / terminal 194 for sending and receiving data to and from network 106, for example, via a wired connection. Interface 190 also includes a wireless front-end circuit 192, which is coupled to or, in some embodiments, may be part of antenna 162.

[0122] The wireless front-end circuit 192 comprises a filter 198 and an amplifier 196. The wireless front-end circuit 192 may be connected to an antenna 162 and a processing circuit 170. The wireless front-end circuit may be configured to adjust signals communicated between the antenna 162 and the processing circuit 170. The wireless front-end circuit 192 may receive digital data to be sent to other network nodes or WDs via the wireless connection. The wireless front-end circuit 192 may convert the digital data into a wireless signal with appropriate channel and bandwidth parameters using a combination of the filter 198 and / or the amplifier 196. The wireless signal may then be transmitted via the antenna 162. Similarly, when receiving data, the antenna 162 may collect a wireless signal, which is then converted into digital data by the wireless front-end circuit 192. The digital data may then be passed to the processing circuit 170. In other embodiments, the interface may comprise different components and / or different combinations of components.

[0123] In some alternative embodiments, the network node 160 may not include a separate radio front-end circuit 192; instead, the processing circuit 170 may have a radio front-end circuit and be connected to the antenna 162 without a separate radio front-end circuit 192. Similarly, in some embodiments, all or part of the RF transceiver circuit 172 may be considered part of the interface 190. In yet another embodiment, the interface 190 may include one or more ports or terminals 194, the radio front-end circuit 192, and the RF transceiver circuit 172 as part of a radio unit (not shown), and the interface 190 may communicate with a baseband processing circuit 174 which is part of a digital unit (not shown).

[0124] Antenna 162 may include one or more antennas or antenna arrays configured to transmit and / or receive radio signals. Antenna 162 may be coupled to the radio front-end circuit 192 and may be any type of antenna capable of transmitting and receiving data and / or signals wirelessly. In some embodiments, antenna 162 may comprise one or more omnidirectional sector or panel antennas capable of transmitting / receiving radio signals between 2 GHz and 66 GHz, for example. Omnidirectional antennas may be used to transmit / receive radio signals in any direction, sector antennas may be used to transmit / receive radio signals from devices within a specific area, and panel antennas may be line-of-sight antennas used to transmit / receive radio signals in a relatively straight line. In some cases, the use of two or more antennas may be referred to as MIMO. In some embodiments, antenna 162 may be separate from the network node 160 and may be connectable to the network node 160 through an interface or port.

[0125] Antenna 162, interface 190, and / or processing circuit 170 may be configured to perform any receiving operations and / or certain acquisition operations as described herein as being performed by a network node. Any information, data, and / or signals may be received from a wireless device, another network node, and / or any other network equipment. Similarly, antenna 162, interface 190, and / or processing circuit 170 may be configured to perform any transmitting operations as described herein as being performed by a network node. Any information, data, and / or signals may be transmitted to a wireless device, another network node, and / or any other network equipment.

[0126] The power circuit 187 may include or be coupled to a power management circuit and be configured to supply power to the components of the network node 160 to perform the functionality described herein. The power circuit 187 may receive power from a power supply 186. The power supply 186 and / or the power circuit 187 may be configured to supply power to the various components of the network node 160 in a manner suitable for each component (for example, at the voltage and current levels required for each component). The power supply 186 may be included in the power circuit 187 and / or the network node 160, or it may be outside the power circuit 187 and / or the network node 160.

[0127] For example, network node 160 may be connectable to an external power source (e.g., an electrical outlet) via an input circuit or interface such as an electrical cable, thereby supplying power to power circuit 187. As a further example, power supply 186 may include a power source in the form of a battery or battery pack connected to or integrated into power circuit 187. The battery may provide backup power in the event of an external power failure. Other types of power sources, such as photovoltaic devices, may also be used.

[0128] Alternative embodiments of network node 160 may include additional components other than those shown in Figure 4 that are responsible for providing several aspects of the network node's functionality, including any functionality described herein and / or any functionality necessary to support the subject matter described herein. For example, network node 160 may include user interface equipment that enables the input of information to and from network node 160. This may enable a user to perform diagnostic, maintenance, repair, and other management functions related to network node 160.

[0129] As used herein, a wireless device (WD) refers to a device that is capable of, configured, and / or operational for communicating wirelessly with network nodes and / or other wireless devices. Unless otherwise stated, the term WD may be used herein interchangeably with user equipment (UE). Wireless communication may involve transmitting and / or receiving wireless signals using electromagnetic waves, radio waves, infrared waves, and / or other types of signals suitable for transmitting information in the air.

[0130] In some embodiments, the WD may be configured to transmit and / or receive information without direct human interaction. For example, the WD may be designed to transmit information to the network on a predetermined schedule when triggered by an internal or external event, or in response to a request from the network.

[0131] Examples of WDs include, but are not limited to, smartphones, mobile phones, cell phones, voice over IP (VoIP) phones, wireless local loop phones, desktop computers, personal digital assistants (PDAs), wireless cameras, gaming consoles or devices, music storage devices, playback devices, wearable devices, wireless endpoints, mobile stations, tablets, laptop computers, laptop embedded devices (LEEs), laptop onboard devices (LMEs), smart devices, wireless customer equipment (CPEs), and in-vehicle wireless terminal devices. WDs can support D2D (device-to-device) communication by implementing 3GPP standards for sidelink communication, V2V (Vehicle-to-Vehicle), V2I (Vehicle-to-Infrastructure), and V2X (Vehicle-to-Everything), and in this case, they are sometimes called D2D communication devices.

[0132] In another specific example, in an Internet of Things (IoT) scenario, a WD may represent a machine or other device that performs monitoring and / or measurement and transmits the results of such monitoring and / or measurement to another WD and / or network node. In this case, a WD may be a machine-to-machine (M2M) device, which is sometimes called an MTC device in the context of 3GPP. For example, a WD may be a UE implementing the 3GPP Narrowband Internet of Things (NB-IoT) standard. Examples of such machines or devices include sensors, measuring devices such as power meters, industrial machinery, or household or personal electrical appliances (e.g., refrigerators, televisions, etc.), or personal wearables (e.g., watches, fitness trackers, etc.).

[0133] In other scenarios, a WD may represent a vehicle or other device, which may be capable of monitoring its operational status and / or reporting on its operational status, or performing other functions associated with its operation. A WD as described above may represent a wireless connection endpoint, in which case the device may be called a wireless terminal. Furthermore, a WD as described above may be mobile, in which case the device may be called a mobile device or mobile terminal.

[0134] As illustrated, the wireless device 110 includes an antenna 111, an interface 114, a processing circuit 120, a device-readable medium 130, a user interface device 132, an auxiliary device 134, a power supply 136, and a power circuit 137. The WD 110 may include one or more sets of illustrated components for different wireless technologies supported by the WD 110, such as, for example, GSM, WCDMA, LTE, NR, WiFi, WiMAX, or Bluetooth wireless technologies. These wireless technologies may be integrated into the same or different chips or sets of chips as the other components within the WD 110.

[0135] Antenna 111 may include one or more antennas or antenna arrays configured to transmit and / or receive radio signals and connected to interface 114. In some alternative embodiments, antenna 111 may be separate from WD 110 and connectable to WD 110 through an interface or port. Antenna 111, interface 114, and / or processing circuitry 120 may be configured to perform any receive or transmit operations described herein as being performed by the WD. Any information, data, and / or signals may be received from network nodes and / or other WDs. In some embodiments, the radio front-end circuitry and / or antenna 111 may be considered an interface.

[0136] As shown in the figure, interface 114 comprises a wireless front-end circuit 112 and an antenna 111. The wireless front-end circuit 112 comprises one or more filters 118 and an amplifier 116. The wireless front-end circuit 112 is connected to the antenna 111 and a processing circuit 120 and is configured to adjust the signals communicated between the antenna 111 and the processing circuit 120. The wireless front-end circuit 112 may be coupled to or be part of the antenna 111. In some embodiments, WD 110 may not include a separate wireless front-end circuit 112; rather, the processing circuit 120 may comprise the wireless front-end circuit and be connected to the antenna 111. Similarly, in some embodiments, some or all of the RF transceiver circuit 122 may be considered part of interface 114.

[0137] The wireless front-end circuit 112 can receive digital data to be sent to other network nodes or WDs via the wireless connection. The wireless front-end circuit 112 can convert the digital data into a wireless signal with appropriate channel and bandwidth parameters using a combination of filter 118 and / or amplifier 116. The wireless signal can then be transmitted via antenna 111. Similarly, when receiving data, antenna 111 can collect a wireless signal, which is then converted into digital data by the wireless front-end circuit 112. The digital data can then be passed to processing circuit 120. In other embodiments, the interface may comprise different components and / or different combinations of components.

[0138] The processing circuit 120 may comprise one or more combinations of microprocessors, controllers, microcontrollers, central processing units, digital signal processors, application-specific integrated circuits, field-programmable gate arrays, or other suitable computing devices, resources, or combinations of hardware, software, and / or encoded logic, either alone or in combination with other WD 110 components such as the device-readable medium 130, that are capable of operating to provide the functionality of the WD 110. Such functionality may include providing any of the various radio features or benefits described herein. For example, the processing circuit 120 may execute instructions stored in the device-readable medium 130 or instructions stored in memory within the processing circuit 120 in order to provide the functionality disclosed herein.

[0139] As shown in the figure, the processing circuit 120 includes one or more of the RF transceiver circuit 122, the baseband processing circuit 124, and the application processing circuit 126. In other embodiments, the processing circuit may comprise different components and / or different combinations of components. In some embodiments, the processing circuit 120 of the WD 110 may comprise a SOC. In some embodiments, the RF transceiver circuit 122, the baseband processing circuit 124, and the application processing circuit 126 may reside on separate chips or sets of chips.

[0140] In alternative embodiments, some or all of the baseband processing circuit 124 and the application processing circuit 126 may be combined into a single chip or set of chips, while the RF transceiver circuit 122 may be on a separate chip or set of chips. In further alternative embodiments, some or all of the RF transceiver circuit 122 and the baseband processing circuit 124 may be on the same chip or set of chips, while the application processing circuit 126 may be on a separate chip or set of chips. In yet another alternative embodiment, some or all of the RF transceiver circuit 122, the baseband processing circuit 124, and the application processing circuit 126 may be combined on the same chip or set of chips. In some embodiments, the RF transceiver circuit 122 may be part of the interface 114. The RF transceiver circuit 122 may adjust the RF signal for the processing circuit 120.

[0141] In some embodiments, some or all of the functionality described herein as being implemented by WD may be provided by the processing circuit 120 executing instructions stored in a device-readable medium 130, which in some embodiments may be a computer-readable storage medium. In alternative embodiments, some or all of the functionality may be provided by the processing circuit 120 without executing instructions stored in a separate or individual device-readable storage medium, such as in a hardwired manner.

[0142] In any of these embodiments, the processing circuit 120 can be configured to perform the described functionality, with or without executing instructions stored in the device-readable storage medium. The benefits provided by such functionality are enjoyed by the processing circuit 120 alone, or by the WD 110, and / or generally by the end user and the wireless network, although not limited to other components of the WD 110.

[0143] The processing circuit 120 may be configured to perform any decision operation, calculation operation, or similar operation (e.g., several acquisition operations) as described herein as being performed by the WD. These operations, such as those performed by the processing circuit 120, may include processing the information acquired by the processing circuit 120, for example by converting the acquired information into other information, comparing the acquired or converted information with information stored by the WD 110, and / or performing one or more operations based on the acquired or converted information and as a result of the decisions made by the processing.

[0144] The device-readable medium 130 may be operable to store computer programs, software, applications (including one or more of logic, rules, code, tables, etc.), and / or other instructions that can be executed by the processing circuit 120. The device-readable medium 130 may include computer memory (e.g., random access memory (RAM) or read-only memory (ROM)), mass storage media (e.g., hard disks), removable storage media (e.g., compact discs (CDs) or digital video discs (DVDs)), and / or any other volatile or non-volatile, non-temporary device-readable, and / or computer-executable memory devices that store information, data, and / or instructions that can be used by the processing circuit 120. In some embodiments, the processing circuit 120 and the device-readable medium 130 may be integrated.

[0145] The user interface device 132 may provide components that enable a human user to interact with the WD 110. Such interaction can take many forms, such as visual, auditory, or tactile. The user interface device 132 may be operable to produce output to the user and to enable the user to provide input to the WD 110. The type of interaction may vary depending on the type of user interface device 132 installed on the WD 110. For example, if the WD 110 is a smartphone, the interaction may be via a touchscreen; if the WD 110 is a smart meter, the interaction may be through a screen that provides usage (e.g., the number of gallons used) or a speaker that provides an audible alarm (e.g., if smoke is detected).

[0146] The user interface device 132 may include interfaces, devices, and circuits for input, as well as interfaces, devices, and circuits for output. The user interface device 132 is configured to allow information to be input to the WD 110 and is connected to the processing circuit 120 so that the processing circuit 120 can process the input information. The user interface device 132 may include, for example, a microphone, proximity or other sensors, keys / buttons, a touch display, one or more cameras, a USB port, or other input circuits. The user interface device 132 is also configured to allow information to be output from the WD 110 and so that the processing circuit 120 can output information from the WD 110. The user interface device 132 may include, for example, a speaker, a display, a vibration circuit, a USB port, a headphone interface, or other output circuits. Using one or more input and output interfaces, devices, and circuits of the user interface device 132, the WD 110 may communicate with an end user and / or a wireless network, enabling the end user and / or the wireless network to benefit from the functionality described herein.

[0147] The auxiliary device 134 is operable to provide more specific functionality that may not be implemented by the WD in general. This may include specialized sensors for taking measurements for various purposes, interfaces for additional types of communication such as wired communication, and so on. The inclusion and types of components of the auxiliary device 134 may vary depending on the embodiment and / or scenario.

[0148] In some embodiments, the power supply 136 may be in the form of a battery or battery pack. Other types of power supplies may also be used, such as an external power supply (e.g., an electrical outlet), a photovoltaic device, or a battery. The WD 110 may further comprise a power circuit 137 that delivers power from the power supply 136 to various parts of the WD 110 that require power from the power supply 136 to perform any functionality described or suggested herein. In some embodiments, the power circuit 137 may comprise a power management circuit.

[0149] The power circuit 137 may, in addition or alternatively, be operable to receive power from an external power source, in which case the WD 110 may be connectable to the external power source (such as an electrical outlet) via an input circuit or interface such as a power cable. The power circuit 137 may also be operable in some embodiments to deliver power from an external power source to power supply 136. This may be, for example, for charging power supply 136. The power circuit 137 may perform any formatting, conversion, or other modifications to the power from power supply 136 to make that power suitable for each component of the WD 110 being powered.

[0150] The subject matter described herein can be implemented in any suitable type of system using any preferred components, but the embodiments disclosed herein are described with respect to wireless networks, such as the illustrative wireless network shown in Figure 4. For simplicity, the wireless network in Figure 4 illustrates only network 106, network nodes 160 and 160b, and WDs 110, 110b, and 110c. In practice, a wireless network may further include any additional elements suitable for supporting communication between wireless devices, or between wireless devices and other communication devices, such as fixed telephones, service providers, or other arbitrary network nodes or end devices. Of the illustrated components, network node 160 and wireless devices (WDs) 110 are illustrated with additional details. A wireless network may provide communication and other types of services to one or more wireless devices to facilitate wireless devices accessing the wireless network and / or using services provided by or through the wireless network.

[0151] Figure 5 shows an example of a user device according to several embodiments. As used herein, a user device or UE does not necessarily have a user in the sense of a human user who owns and / or operates the device in question. Instead, a UE may represent a device (e.g., a smart sprinkler controller) that is intended for sale to or operation by a human user, but may not be associated with a specific human user, or may not initially be associated with a specific human user. Alternatively, a UE may represent a device (e.g., a smart electricity meter) that is not intended for sale to or operation by an end user, but may be associated with or operated for the benefit of a user. UE 200 may be any UE specified by the Third Generation Partnership Project (3GPP), including NB-IoT UEs, Machine-Type Communications (MTC) UEs, and / or Enhanced MTC (eMTC) UEs. UE 200 is an example of a WD configured for communication under one or more communication standards published by 3GPP, such as the GSM, UMTS, LTE, and / or 5G standards of the Third Generation Partnership Project (3GPP), as shown in Figure 5. As stated above, the terms WD and UE can be used interchangeably. Thus, although Figure 5 is a UE, the components considered herein are equally applicable to WDs, and vice versa.

[0152] In Figure 5, the UE 200 includes an input / output interface 205, a radio frequency (RF) interface 209, a network connectivity interface 211, memory 215 (including random access memory (RAM) 217, read-only memory (ROM) 219, and storage medium 221, etc.), a communication subsystem 231, a power supply 213, and / or any other optional components, or any combination thereof, and processing circuitry 201 operably coupled to them. The storage medium 221 includes an operating system 223, an application program 225, and data 227. In other embodiments, the storage medium 221 may include other similar types of information. Some UEs may use all the components shown in Figure 5, or only a subset of those components. The level of integration between components may vary from UE to UE. Furthermore, some UEs may include multiple instances of components, such as multiple processors, memory, transceivers, transmitters, and receivers.

[0153] In Figure 5, the processing circuit 201 may be configured to process computer instructions and data. The processing circuit 201 may be configured to implement one or more programmable, general-purpose processors, or any combination thereof, such as one or more hardware-implemented state machines (e.g., discrete logic, FPGA, ASIC, etc.), any sequential state machine capable of executing machine instructions stored in memory as machine-readable computer programs, programmable logic with appropriate firmware, or a microprocessor or digital signal processor (DSP) with appropriate software. For example, the processing circuit 201 may include two central processing units (CPUs). The data may be information in a form suitable for use by a computer.

[0154] In the illustrated embodiment, the input / output interface 205 may be configured to provide an input device, an output device, or a communication interface to an input / output device. The UE 200 may be configured to use an output device via the input / output interface 205.

[0155] Output devices may use the same type of interface port as input devices. For example, a USB port may be used to provide input to and output from the UE 200. Output devices can be speakers, sound cards, video cards, displays, monitors, printers, actuators, emitters, smart cards, other output devices, or any combination thereof.

[0156] The UE 200 may be configured to use input devices via the input / output interface 205 to allow users to capture information into the UE 200. Input devices may include touch-sensitive or presence-sensitive displays, cameras (e.g., digital cameras, digital video cameras, webcams, etc.), microphones, sensors, mice, trackballs, directional pads, trackpads, scroll wheels, smart cards, etc. Presence-sensitive displays may include capacitive or resistive touch sensors that sense user input. Sensors may include, for example, accelerometers, gyroscopes, tilt sensors, force sensors, magnetometers, light sensors, proximity sensors, other similar sensors, or any combination thereof. For example, input devices may include accelerometers, magnetometers, digital cameras, microphones, and light sensors.

[0157] In Figure 5, the RF interface 209 may be configured to provide a communication interface to RF components such as transmitters, receivers, and antennas. The network connection interface 211 may be configured to provide a communication interface to network 243a. Network 243a may encompass wired and / or wireless networks, such as local area networks (LANs), wide area networks (WANs), computer networks, wireless networks, communication networks, other similar networks, or any combination thereof. For example, network 243a may include a Wi-Fi network. The network connection interface 211 may be configured to include receiver and transmitter interfaces used to communicate with one or more other devices on the communication network according to one or more communication protocols, such as Ethernet, TCP / IP, SONET, ATM, etc. The network connection interface 211 may implement receiver and transmitter functionality suitable for communication network links (e.g., optical, electrical, etc.). The transmitter and receiver functions may share circuit components, software, or firmware, or alternatively, may be implemented separately.

[0158] RAM 217 may be configured to interface with processing circuit 201 via bus 202 to provide storage or caching of data or computer instructions during the execution of software programs such as the operating system, application programs, and device drivers. ROM 219 may be configured to provide computer instructions or data to processing circuit 201. For example, ROM 219 may be configured to store immutable low-level system code or data for basic system functions, such as basic input / output (I / O), startup, or receiving keystrokes from the keyboard, which are stored in non-volatile memory.

[0159] The storage medium 221 may be configured to include memory such as RAM, ROM, programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), magnetic disk, optical disk, floppy disk, hard disk, removable cartridge, or flash drive. For example, the storage medium 221 may be configured to include an operating system 223, an application program 225 such as a web browser application, a widget or gadget engine, or another application, and data files 227. The storage medium 221 may store a wide variety of operating systems or combinations of operating systems for use by the UE 200.

[0160] The storage medium 221 may be configured to include several physical drive units, such as a redundant array of independent disks (RAID), a floppy disk drive, flash memory, a USB flash drive, an external hard disk drive, a thumb drive, a pen drive, a key drive, a high-density digital versatile disk (HD-DVD) optical disk drive, an internal hard disk drive, a Blu-ray optical disk drive, a holographic digital data storage (HDDS) optical disk drive, an external mini dual in-line memory module (DIMM), synchronous dynamic random access memory (SDRAM), an external microDIMM SDRAM, smart card memory such as a subscriber identification module or removable user identification (SIM / RUIM) module, other memory, or any combination thereof. The storage medium 221 may enable the UE 200 to access computer executable instructions, application programs, etc., stored in temporary or non-temporary memory media, to offload data, or to upload data. Products such as products utilizing a communication system may be tangibly embodied in the storage medium 221, and the storage medium 221 may include device-readable media.

[0161] In Figure 5, the processing circuit 201 may be configured to communicate with network 243b using the communication subsystem 231. Networks 243a and 243b may be the same one or more networks, or different one or more networks. The communication subsystem 231 may be configured to include one or more transceivers used to communicate with network 243b. For example, the communication subsystem 231 may be configured to include one or more transceivers used to communicate with one or more remote transceivers of another wirelessly wirelessly capable device, such as another WD, UE, or base station of a radio access network (RAN), according to one or more communication protocols, such as IEEE 802.2, CDMA, WCDMA, GSM, LTE, UTRAN, or WiMax. Each transceiver may include a transmitter 233 and / or a receiver 235, each implementing transmitter or receiver functionality (e.g., frequency allocation) suitable for a RAN link. Furthermore, the transmitter 233 and receiver 235 of each transceiver may share circuit components, software, or firmware, or alternatively, may be implemented separately.

[0162] In the illustrated embodiment, the communication functions of the communication subsystem 231 may include data communication, voice communication, multimedia communication, short-range communication such as Bluetooth, near-field communication, location-based communication such as the use of a Global Positioning System (GPS) to determine location, other similar communication functions, or any combination thereof. For example, the communication subsystem 231 may include cellular communication, Wi-Fi communication, Bluetooth communication, and GPS communication. The network 243b may encompass wired and / or wireless networks, such as a local area network (LAN), a wide area network (WAN), a computer network, a wireless network, a communication network, another similar network, or any combination thereof. For example, the network 243b may be a cellular network, a Wi-Fi network, and / or a near-field network. The power supply 213 may be configured to provide alternating current (AC) or direct current (DC) power to the components of the UE 200.

[0163] The features, benefits, and / or functions described herein may be implemented in one of the components of the UE 200 or divided across multiple components of the UE 200. Furthermore, the features, benefits, and / or functions described herein may be implemented in any combination of hardware, software, or firmware. In one example, the communication subsystem 231 may be configured to include any of the components described herein. Furthermore, the processing circuit 201 may be configured to communicate with any of such components via the bus 202. In another example, any of such components may be represented by a program instruction stored in memory that, when executed by the processing circuit 201, performs the corresponding function described herein. In yet another example, the functionality of any of such components may be divided between the processing circuit 201 and the communication subsystem 231. In yet another example, the non-computationally intensive functions of any of such components may be implemented in software or firmware, and the computationally intensive functions may be implemented in hardware.

[0164] Figure 6 is a flowchart illustrating an example method in a wireless device according to several embodiments. In a particular embodiment, one or more steps in Figure 6 may be performed by the wireless device 110 described with respect to Figure 4.

[0165] The method begins in step 612, in which a wireless device (e.g., wireless device 110) receives a DCI requesting a Type 3 HARQ-ACK codebook and a priority instruction associated with the Type 3 HARQ-ACK codebook. In certain embodiments, the priority instruction is associated with HARQ-ACK bits corresponding to one of a plurality of PDSCHs, and only the HARQ bits associated with the PDSCH are included in the Type 3 HARQ-ACK codebook. In some embodiments, the Type 3 HARQ-ACK codebook includes HARQ-ACK bits for all HARQ processes, regardless of the priority instruction.

[0166] In certain embodiments, a Type 3 HARQ-ACK codebook transmission is in an uplink conflict with another transmission, and the conflict is resolved based on a priority instruction. The priority instruction may be included in the DCI request. For example, the DCI request may include a priority associated with the DCI and a separate priority associated with the Type 3 HARQ-ACK codebook transmission. In some embodiments, the priority associated with the Type 3 HARQ-ACK codebook may be the same as the priority associated with the DCI. In some embodiments, the DCI request includes transmission parameters for the Type 3 HARQ-ACK codebook transmission (e.g., BLER target, MCS, transmit power, etc.), and the priority instruction is based on the transmission parameters.

[0167] In certain embodiments, the priority instruction may indicate the physical uplink control channel (PUCCH) setting to use for Type 3 HARQ-ACK codebook transmissions.

[0168] In a particular embodiment, the DCI request includes one of DCI format 0_1, DCI format 0_2, DCI format 1_2, and DCI format 1_1.

[0169] In certain embodiments, the DCI and priority indicators include any of the DCI and priority indicators described with respect to any of the embodiments and examples described above.

[0170] In step 614, based on the DCI request and priority instructions, the wireless device sends a Type 3 HARQ-ACK codebook to the network node. In some embodiments, the DCI request is for scheduling PUSCH data, and the Type 3 HARQ-ACK codebook is sent via a physical PUSCH.

[0171] Method 600 in Figure 6 may be modified, added to, or omitted. In addition, one or more steps in Method 6 in Figure 6 may be performed in parallel or in any preferred order.

[0172] Figure 7 is a flowchart illustrating an example method in a network node according to several embodiments. In a particular embodiment, one or more steps in Figure 7 may be performed by the network node 160 described with respect to Figure 4.

[0173] The method begins in step 712, in which a network node (e.g., network node 160) sends a DCI requesting a Type 3 HARQ-ACK codebook and a priority instruction associated with the Type 3 HARQ-ACK codebook to the wireless device. The DCI and priority instruction are described in Figure 6 and with reference to the embodiments and examples described above.

[0174] In step 714, based on the DCI request and priority instructions, the network node receives a Type 3 HARQ-ACK codebook from the wireless device. The Type 3 HARQ-ACK codebook is described in Figure 6 and with reference to the embodiments and examples described above.

[0175] Method 700 in Figure 7 may be modified, added to, or omitted. In addition, one or more steps in the method in Figure 6 may be performed in parallel or in any preferred order.

[0176] Figure 8 shows a schematic block diagram of two devices in a wireless network (for example, the wireless network shown in Figure 4). The devices include a wireless device and a network node (for example, wireless device 110 and network node 160 shown in Figure 4). Devices 1600 and 1700 are operable to perform the exemplary methods described with reference to Figures 6 and 7, and optionally any other processes or methods disclosed herein. It should also be understood that the methods in Figures 6 and 7 are not necessarily performed by devices 1600 and / or 1700 alone. At least some operations of the methods may be performed by one or more other entities.

[0177] The virtual devices 1600 and 1700 may comprise processing circuits that may include one or more microprocessors or microcontrollers, as well as other digital hardware that may include a digital signal processor (DSP), dedicated digital logic, etc. The processing circuits may include one or more types of memory, such as read-only memory (ROM), random access memory, cache memory, flash memory devices, optical storage devices, etc., and may be configured to execute program code stored in memory. In some embodiments, the program code stored in memory may include program instructions for executing one or more communication and / or data communication protocols, as well as instructions for performing one or more of the techniques described herein.

[0178] In some implementations, the processing circuit may be used to cause the receiving module 1602, the transmitting module 1606, and any other suitable unit of the device 1600 to perform the corresponding function according to one or more embodiments of the present disclosure. Similarly, the processing circuit described above may be used to cause the receiving module 1702, the transmitting module 1706, and any other suitable unit of the device 1700 to perform the corresponding function according to one or more embodiments of the present disclosure.

[0179] As shown in Figure 8, the device 1600 includes a receiving module 1602 configured to receive DCI according to any of the embodiments and examples described herein. The transmitting module 1606 is configured to transmit a Type 3 HARQ-ACK codebook according to any of the embodiments and examples described herein.

[0180] As shown in Figure 8, the apparatus 1700 includes a receiving module 1702 configured to receive a Type 3 HARQ-ACK codebook according to any of the embodiments and examples described herein. The transmitting module 1706 is configured to transmit DCI according to any of the embodiments and examples described herein.

[0181] Figure 9 is a schematic block diagram showing a virtualization environment 300 in which functions implemented by several embodiments may be virtualized. In this context, virtualization means creating a virtual version of an apparatus or device, which may include virtualizing hardware platforms, storage devices, and networking resources. As used herein, virtualization may apply to a node (e.g., a virtualized base station or a virtualized radio access node) or a device (e.g., a UE, a radio device, or any other type of communication device) or a component of that device, relating to an implementation in which at least a portion of the functionality is implemented as one or more virtual components (e.g., via one or more applications, components, functions, virtual machines, or containers running on one or more physical processing nodes in one or more networks).

[0182] In some embodiments, some or all of the functions described herein may be implemented as virtual components, executed by one or more virtual machines implemented in one or more virtual environments 300 hosted by one or more hardware nodes 330. Furthermore, in embodiments where the virtual nodes are not wireless access nodes or do not require wireless connectivity (e.g., core network nodes), the network nodes may be fully virtualized.

[0183] The functionality may be implemented by one or more applications 320 (which may alternatively be referred to as software instances, virtual appliances, network functions, virtual nodes, virtual network functions, etc.) that are operable to implement some of the features, functions, and / or benefits of the embodiments disclosed herein. The applications 320 run in a virtualized environment 300 that provides hardware 330 comprising a processing circuit 360 and memory 390. The memory 390 contains instructions 395 that can be executed by the processing circuit 360, thereby enabling the applications 320 to operate to provide one or more of the features, benefits, and / or functions disclosed herein.

[0184] The virtualization environment 300 comprises a general-purpose or dedicated network hardware device 330 having one or more sets of processors or processing circuits 360, where the set of processors or processing circuits 360 may be commercial off-the-shelf (COTS) processors, dedicated application-specific integrated circuits (ASICs), or any other type of processing circuit including digital or analog hardware components or dedicated processors. Each hardware device may include memory 390-1, which may be non-persistent memory for temporarily storing instructions 395 or software executed by the processing circuits 360. Each hardware device may also include one or more network interface controllers (NICs) 370, also known as network interface cards, where the network interface controllers (NICs) 370 include a physical network interface 380. Each hardware device may also include a non-temporary, persistent, machine-readable storage medium 390-2 storing software 395 and / or instructions executable by the processing circuits 360. Software 395 may include any type of software, including software for instantiating one or more (also called hypervisors) virtualization layers 350, software for running virtual machines 340, and software that enables the performance of the functions, features, and / or benefits described in relation to some embodiments described herein.

[0185] A virtual machine 340 comprises virtual processing, virtual memory, virtual networking or interfaces, and virtual storage, and may run on a corresponding virtualization layer 350 or hypervisor. Different embodiments of the virtual appliance 320 may be implemented in one or more of the virtual machines 340, and the implementation may be carried out in different ways.

[0186] During operation, the processing circuit 360 executes software 395 to instantiate the hypervisor or virtualization layer 350, which may sometimes be called a virtual machine monitor (VMM). The virtualization layer 350 may present a virtual operating platform to the virtual machine 340 that resembles networking hardware.

[0187] As shown in Figure 9, hardware 330 may be a standalone network node with general or specific components. Hardware 330 may be equipped with antenna 3225 and may implement several functions through virtualization. Alternatively, hardware 330 may be part of a larger cluster of hardware (for example, in the case of a data center or customer premises equipment (CPE)) where many hardware nodes cooperate and are managed via Management and Orchestration (MANO) 3100, which oversees the lifecycle management of application 320.

[0188] Hardware virtualization is sometimes referred to as network function virtualization (NFV). NFV can be used to consolidate many types of network equipment onto industry-standard high-capacity server hardware, physical switches, and physical storage, allowing them to be deployed in data centers and customer premises equipment.

[0189] In the context of NFV, a virtual machine 340 can be a software implementation of a physical machine that runs programs as if they were running on a physical, non-virtualized machine. Each virtual machine 340, and a portion of the hardware 330 on which it runs, forms a separate virtual network element (VNE), whether that hardware is dedicated to that virtual machine and / or shared by that virtual machine with other virtual machines 340.

[0190] Furthermore, in the context of NFV, a virtual network function (VNF) is responsible for handling specific network functions running on one or more virtual machines 340 on the hardware networking infrastructure 330, and corresponds to application 320 in Figure 18.

[0191] In some embodiments, one or more radio units 3200, each including one or more transmitters 3220 and one or more receivers 3210, may be coupled to one or more antennas 3225. The radio units 3200 may communicate directly with hardware nodes 330 via one or more suitable network interfaces and may be used in combination with virtual components to provide a virtual node with radio capabilities, such as a radio access node or base station.

[0192] In some embodiments, some signaling may be implemented using a control system 3230, which may be used as an alternative for communication between the hardware node 330 and the wireless unit 3200.

[0193] Referring to Figure 10, according to one embodiment, the communication system includes a communication network 410, such as a 3GPP type cellular network, comprising an access network 411, such as a radio access network, and a core network 414. The access network 411 comprises a plurality of base stations 412a, 412b, 412c, such as NBs, eNBs, gNBs, or other types of radio access points, each defining a corresponding coverage area 413a, 413b, 413c. Each base station 412a, 412b, 412c is connectable to the core network 414 via a wired or wireless connection 415. A first UE 491 located in coverage area 413c is configured to wirelessly connect to a corresponding base station 412c or to be paged by a corresponding base station 412c. A second UE 492 in coverage area 413a is configured to wirelessly connect to a corresponding base station 412a. Although multiple UEs 491, 492 are shown in this example, the disclosed embodiments are equally applicable to situations where only one UE is in the coverage area, or where only one UE is connected to the corresponding base station 412.

[0194] The communication network 410 is connected to a host computer 430, which may be embodied in the hardware and / or software of a standalone server, a cloud implementation server, a distributed server, or as a processing resource in a server farm. The host computer 430 may be owned or controlled by a service provider, or operated by or on behalf of a service provider. Connections 421 and 422 between the communication network 410 and the host computer 430 may extend directly from the core network 414 to the host computer 430, or via an optional intermediate network 420. The intermediate network 420 may be one of a public network, a private network, or a hosted network, or a combination of two or more of these, and if an intermediate network 420 exists, it may be a backbone network or the internet, and in particular, the intermediate network 420 may comprise two or more subnets (not shown).

[0195] The communication system in Figure 10, as a whole, enables connectivity between the connected UEs 491, 492 and the host computer 430. The connectivity can be described as an over-the-top (OTT) connection 450. The host computer 430 and the connected UEs 491, 492 are configured to communicate data and / or signaling over the OTT connection 450, using the access network 411, the core network 414, an optional intermediate network 420, and possible further infrastructure (not shown) as intermediaries. The OTT connection 450 can be transparent in the sense that the involved communication devices through which the OTT connection 450 passes are unaware of the routing of uplink and downlink communications. For example, base station 412 may not be aware of, or does not need to be aware of, the past routing of incoming downlink communications with data originating from the host computer 430 that should be forwarded (e.g., handed over) to the connected UE 491. Similarly, base station 412 does not need to be aware of the future routing of outgoing uplink communications originating from UE 491 and destined for host computer 430.

[0196] Figure 11 shows an example host computer communicating with user equipment via a base station through a partial wireless connection, according to several embodiments. Next, an exemplary implementation of the UE, base station, and host computer, according to one embodiment discussed in the previous paragraph, will be described with reference to Figure 11. In the communication system 500, the host computer 510 includes hardware 515, including a communication interface 516 configured to set up and maintain wired or wireless connections to the interfaces of different communication devices of the communication system 500. The host computer 510 further includes processing circuitry 518, which may have storage and / or processing capabilities. In particular, the processing circuitry 518 may comprise one or more programmable processors, application-specific integrated circuits, field-programmable gate arrays, or a combination thereof (not shown), adapted to execute instructions. The host computer 510 further includes software 511, which is stored in or accessible by the host computer 510 and executable by the processing circuitry 518. The software 511 includes a host application 512. The host application 512 may operate to provide services to a remote user, such as a UE 530 connected via an OTT connection 550 that terminates at the UE 530 and the host computer 510. When providing services to a remote user, the host application 512 may provide user data transmitted using the OTT connection 550.

[0197] The communication system 500 further includes a base station 520 provided to the communication system, the base station 520 comprising hardware 525 that enables the base station 520 to communicate with a host computer 510 and a UE 530. The hardware 525 may include a communication interface 526 for setting up and maintaining wired or wireless connections with interfaces of different communication devices of the communication system 500, and a wireless interface 527 for setting up and maintaining at least a wireless connection 570 with a UE 530 located within a coverage area (not shown in Figure 11) served by the base station 520. The communication interface 526 may be configured to facilitate a connection 560 to the host computer 510. The connection 560 may be direct, or the connection 560 may pass through the core network of the communication system (not shown in Figure 11) and / or one or more intermediate networks outside the communication system. In the illustrated embodiment, the hardware 525 of the base station 520 further includes a processing circuit 528, which may comprise one or more programmable processors, application-specific integrated circuits, field-programmable gate arrays, or a combination thereof (not shown), adapted to execute instructions. The base station 520 further includes software 521 which is stored internally or accessible via an external connection.

[0198] The communication system 500 further includes the UE 530 already mentioned. The hardware 535 of the UE 530 may include a radio interface 537 configured to set up and maintain a radio connection 570 with a base station serving the coverage area in which the UE 530 is currently located. The hardware 535 of the UE 530 further includes a processing circuit 538, which may comprise one or more programmable processors, application-specific integrated circuits, field-programmable gate arrays, or a combination thereof (not shown) adapted to execute instructions. The UE 530 further includes software 531, which is stored in or accessible by the UE 530 and executable by the processing circuit 538. The software 531 includes a client application 532. The client application 532 may operate to provide services to human or non-human users via the UE 530 with the support of a host computer 510. On the host computer 510, the running host application 512 can communicate with the running client application 532 via the UE 530 and an OTT connection 550 terminating at the host computer 510. When providing services to a user, the client application 532 can receive request data from the host application 512 and provide user data in response to the request data. The OTT connection 550 can transfer both the request data and the user data. The client application 532 can interact with the user to generate the user data that the client application 532 provides.

[0199] Note that the host computer 510, base station 520, and UE 530 shown in Figure 11 may be similar to or equivalent to the host computer 430, one of the base stations 412a, 412b, and 412c, and one of the UEs 491 and 492 in Figure 9, respectively. In other words, the internal workings of these entities may be as shown in Figure 11, while the surrounding network topology may be that of Figure 9.

[0200] In Figure 11, the OTT connection 550 is depicted abstractly to illustrate communication between the host computer 510 and the UE 530 via the base station 520, without explicit reference to the intermediary devices and the precise routing of messages through these devices. The network infrastructure may determine the routing, and the network infrastructure may be configured to hide the routing from the UE 530, or from the service provider operating the host computer 510, or both. While the OTT connection 550 is active, the network infrastructure may further make decisions to dynamically change the routing (for example, based on network load balancing considerations or reconfiguration).

[0201] The radio connection 570 between the UE 530 and the base station 520 follows the teachings of embodiments described throughout this disclosure. One or more of the various embodiments improve the performance of the OTT services provided to the UE 530 by using an OTT connection 550 in which the radio connection 570 forms the final segment. More precisely, the teachings of these embodiments may improve signaling overhead and reduce latency, which may provide faster internet access for users.

[0202] Measurement procedures may be provided for monitoring data rate, latency, and other factors, which are improved in one or more embodiments. Optional network functionality may further be available for reconfiguring the OTT connection 550 between the host computer 510 and the UE 530 in response to variations in the measurement results. The measurement procedures and / or network functionality for reconfiguring the OTT connection 550 may be implemented in the software 511 and hardware 515 of the host computer 510, or in the software 531 and hardware 535 of the UE 530, or both. In embodiments, sensors (not shown) may be deployed in or in connection with the communication device through which the OTT connection 550 passes, and the sensors may participate in the measurement procedures by supplying values ​​of the monitored quantities illustrated above, or by supplying values ​​of other physical quantities through which the software 511, 531 can calculate or estimate the monitored quantities. The reconfiguration of the OTT connection 550 may include message formatting, retransmission settings, preferred routing, etc., and the reconfiguration may not need to affect the base station 520, and may be unknown to or imperceptible to the base station 520. Such procedures and functionalities may be known and practiced in the art. In some embodiments, the measurement may involve proprietary UE signaling that facilitates the measurement of the host computer 510, such as throughput, propagation time, latency, etc. The measurement may be implemented in such a way that the OTT connection 550 is used to cause the software 511 and 531 to send messages, particularly empty or "dummy" messages, while the software 511 and 531 monitor propagation time, errors, etc.

[0203] Figure 12 is a flowchart illustrating a method implemented in a communication system according to one embodiment. The communication system may include a host computer, a base station, and an UE, which may be described with reference to Figures 10 and 11. For simplicity, only a drawing reference to Figure 12 is included in this section.

[0204] In step 610, the host computer provides user data. In an optional substep 611 of step 610, the host computer provides user data by executing a host application. In step 620, the host computer initiates a transmission that carries the user data to the UE. In an optional step 630, the base station transmits the user data carried in the transmission initiated by the host computer to the UE, in accordance with the teachings of the embodiments described throughout this disclosure. In an optional step 640, the UE executes a client application associated with the host application executed by the host computer.

[0205] Figure 13 is a flowchart illustrating a method implemented in a communication system according to one embodiment. The communication system may include a host computer, a base station, and an UE, which may be described with reference to Figures 10 and 11. For simplicity, only a drawing reference to Figure 13 is included in this section.

[0206] In step 710 of the method, the host computer provides user data. In an optional substep (not shown), the host computer provides user data by executing a host application. In step 720, the host computer initiates a transmission to carry the user data to the UE. The transmission may proceed via a base station in accordance with the teachings of embodiments described throughout this disclosure. In (optional) step 730, the UE receives the user data carried in the transmission.

[0207] Figure 14 is a flowchart illustrating a method implemented in a communication system according to one embodiment. The communication system may include a host computer, a base station, and an UE, which may be described with reference to Figures 10 and 11. For simplicity, only a drawing reference to Figure 14 is included in this section.

[0208] In (optional) step 810, the UE receives input data provided by the host computer. In addition or alternatively, in step 820, the UE provides user data. In (optional) substep 821 of step 820, the UE provides user data by running a client application. In (optional) substep 811 of step 810, the UE runs a client application that provides user data in response to received input data provided by the host computer. When providing user data, the run client application may further consider user input received from the user. Regardless of the particular manner in which the user data is provided, in (optional) substep 830, the UE initiates transmission of the user data to the host computer. In step 840 of the method, the host computer receives the user data transmitted from the UE in accordance with the teachings of the embodiments described throughout this disclosure.

[0209] Figure 15 is a flowchart illustrating a method implemented in a communication system according to one embodiment. The communication system may include a host computer, a base station, and an UE, which may be described with reference to Figures 10 and 11. For simplicity, only a drawing reference to Figure 15 is included in this section.

[0210] In (optional) step 910, the base station receives user data from the UE, in accordance with the teachings of embodiments described throughout this disclosure. In (optional) step 920, the base station initiates a transmission of the received user data to the host computer. In (optional) step 930, the host computer receives the user data carried in the transmission initiated by the base station.

[0211] The term "unit" may have its usual meaning in the field of electronics, electrical devices, and / or electronic devices, and may include, for example, electrical and / or electronic circuits, devices, modules, processors, memories, logical solids and / or individual devices, computer programs or instructions, etc., for performing their respective tasks, procedures, calculations, outputs, and / or display functions, such as those described herein.

[0212] Without departing from the scope of the present invention, modifications, additions, or omissions may be made to the systems and apparatus disclosed herein. The components of the systems and apparatus may be integrated or separated. Furthermore, the operation of the systems and apparatus may be performed by more, fewer, or other components. In addition, the operation of the systems and apparatus may be performed using any preferred logic, including software, hardware, and / or other logic. As used herein, “each” refers to each member of a set or each member of a subset of a set.

[0213] Without departing from the scope of the present invention, the methods disclosed herein may be modified, added to, or omitted. The methods may include more, fewer, or other steps. In addition, the steps may be carried out in any preferred order.

[0214] The above description includes numerous specific details. However, it should be understood that embodiments can be implemented without these specific details. In other cases, well-known circuits, structures, and techniques are not shown in detail so as not to obscure the understanding of this description. Those skilled in the art will be able to implement appropriate functionality using the included description without excessive experimentation.

[0215] References herein to “one embodiment,” “an embodiment,” and “exemplary embodiment” indicate that the embodiments described may include certain features, structures, or characteristics, but not all embodiments may necessarily include those features, structures, or characteristics. Furthermore, such phrases do not necessarily refer to the same embodiments. Moreover, when certain features, structures, or characteristics are described in relation to an embodiment, it is stated that implementing such features, structures, or characteristics in relation to other embodiments, whether explicitly described or not, is within the knowledge of those skilled in the art.

[0216] While this disclosure has described several embodiments, modifications and substitutions of embodiments will be obvious to those skilled in the art. Therefore, the above description of embodiments does not limit this disclosure. Other changes, substitutions, and modifications are possible without departing from the scope of this disclosure, as defined by the following claims.

[0217] At least some of the following abbreviations may be used in this disclosure. In the event of any inconsistency between abbreviations, the preference for how the abbreviation is used above should be given. If an abbreviation is listed multiple times below, the first listing should be given preference over subsequent listings. 1x RTT CDMA2000 1x wireless transmission technology 3GPP Third Generation Partnership Project 5G (5th generation) ACK / NACK Acknowledgment / Negative Response BCCH Broadcast Control Channel BCH Broadcast Channel CA Career Aggregation CBRA Competition-Based Random Access CC Carrier Component CDMA Code Division Multiplexing Access CFRA (Competitive Free Random Access) CG-set Grant CGI Cell Global Identifier CP cyclic prefix CQI Channel Quality Information C-RNTI Cell RNTI CSI Channel Status Information DCCH Dedicated Control Channel DCI Downlink Control Information DFTS-OFDM Discrete Fourier Transform Diffusion OFDM DL Downlink DM recovery DMRS demodulation reference signal DRX intermittent reception DTX intermittent transmission Dedicated DTCH traffic channel E-CID Extended Cell ID (Positioning Method) E-SMLC Evolved Serving Mobile Location Center ECGI Evolved CGI eNB E-UTRAN Node B ePDCCH Extended Physical Downlink Control Channel E-SMLC Evolved Serving Mobile Location Center E-UTRA Evolved UTRA E-UTRAN Evolved UTRAN FDD Frequency Division Duplexing GERAN GSM EDGE Radio Access Network Base stations in gNB NR GNSS (Global Navigation Satellite System) GSM (Pan-European Digital Mobile Telephone System) HO Handover HSPA High-Speed ​​Packet Access HRPD High-Speed ​​Packet Data IAB Wireless Access Backhaul Integrated Transmission LOS line of sight LTE Long-Term Evolution MAC Media Access Control MCS Modulation Encoding Scheme Minimizing MDT drive tests MIB Master Information Block MME Mobility Management Entity MSC Mobile Switching Center NPDCCH Narrowband Physical Downlink Control Channel NR new radio OFDM (Orthogonal Frequency Division Multiplexing) OFDMA (Orthogonal Frequency Division Multiple Access) OSS Operation Support System OTDOA Observation Arrival Time Difference O&M operation and maintenance PBCH Physical Broadcast Channel P-CCPCH Primary Common Control Physical Channel PCell Primary Cell PDCCH Physical Downlink Control Channel PDSCH Physical Downlink Shared Channel PGW Packet Gateway PLMN Public Land Mobile Network PMI Precoder Matrix Indicator PRACH Physical Random Access Channel PRS positioning reference signal PSS primary synchronization signal PUCCH Physical Uplink Control Channel PUR Pre-configured Uplink Resources PUSCH Physical Uplink Shared Channel RACH Random Access Channel QAM (Quaternary Amplitude Modulation) RA (Random Access) RAN (Radio Access Network) RAT (Radio Access Technology) RLF Wireless Link Failure RLM Wireless Link Management RNC Wireless Network Controller RNTI (Radio Network Temporary Identifier) RRC (Radio Resource Control) RRM Wireless Resource Management RS reference signal RSCP Received Signal Code Power RSRP reference symbol received power or Reference signal received power RSRQ reference signal reception quality or Reference symbol reception quality RSSI Received Signal Strength Indicator RSTD reference signal time difference SCH Synchronization Channel SCell 2nd Cell SDU Service Data Unit SFN System Frame Number SGW Serving Gateway SI System Information SIB System Information Block SNR (Signal-to-Noise Ratio) SON Self-Optimizing Network SPS Semi-Persistent Scheduling SUL Auxiliary Uplink SS synchronization signal SSB Synchronization Signal Block SSS secondary synchronization signal TA Timing Advance TDD Time Division Duplex TDOA arrival time difference TO Sending Opportunity TOA arrival time TSS 3rd synchronous signal TTI transmission time interval UE User Equipment UL Uplink URLLC: Ultra-high reliability, low latency communication UMTS Universal Mobile Telecommunication System USIM (Universal Subscriber Identification Module) UTDOA Uplink Arrival Time Difference UTRA Universal Terrestrial Radio Access UTRAN Universal Terrestrial Radio Access Network WCDMA WideCDMA WLAN (Wide Local Area Network)

Claims

1. A method implemented by a wireless device for transmitting a Type 3 Hybrid Automatic Retransmission Request Acknowledgment (HARQ-ACK) codebook, Receiving downlink control information (DCI) requesting a Type 3 HARQ-ACK codebook and priority instructions associated with the Type 3 HARQ-ACK codebook (612), Based on the DCI request and the priority instructions, transmit the Type 3 HARQ-ACK codebook to the network node (614) Includes, A method in which only the HARQ-ACK bits associated with the scheduled cell indicated by the DCI are included in the Type 3 HARQ-ACK codebook.

2. The method according to claim 1, wherein a transmission of the type 3 HARQ-ACK codebook is in an uplink conflict with another transmission, and the conflict is resolved based on the priority indication.

3. The method according to claim 1 or 2, wherein the priority instruction is included in the DCI requirement.

4. The method according to claim 3, wherein the DCI request includes a priority associated with the DCI and a separate priority associated with the transmission of the Type 3 HARQ-ACK codebook.

5. The method according to claim 1 or 2, wherein the DCI request includes transmission parameters for the transmission of the Type 3 HARQ-ACK codebook, and the priority instruction is based on the transmission parameters.

6. The method according to any one of claims 1 to 5, wherein the priority instruction indicates a physical uplink control channel (PUCCH) setting to be used for the type 3 HARQ-ACK codebook transmission.

7. The method according to any one of claims 1 to 6, wherein the type 3 HARQ-ACK codebook is transmitted via a physical uplink control channel (PUCCH).

8. The method according to any one of claims 1 to 7, wherein the DCI request is for scheduling physical uplink shared channel (PUCCH) data, and the type 3 HARQ-ACK codebook is transmitted via the physical uplink control channel (PUCCH).

9. The method according to any one of claims 1 to 8, wherein the DCI requirement includes one of DCI format 0_1, DCI format 0_2, DCI format 1_2, and DCI format 1_1.

10. A wireless device (110) capable of transmitting a Type 3 Hybrid Automatic Retransmission Request Acknowledgment (HARQ-ACK) codebook, A processing circuit (120) is provided which is operable to perform the method according to any one of claims 1 to 9. Wireless device.

11. A method implemented by a network node to receive a Type 3 Hybrid Automatic Retransmission Request Acknowledgment (HARQ-ACK) codebook, Transmitting downlink control information (DCI) requesting a Type 3 HARQ-ACK codebook and priority instructions associated with the Type 3 HARQ-ACK codebook to a wireless device (712), Based on the DCI request and the priority instructions, receive the Type 3 HARQ-ACK codebook from the wireless device (714) Includes, A method in which only the HARQ-ACK bits associated with the scheduled cell indicated by the DCI are included in the Type 3 HARQ-ACK codebook.

12. The method according to claim 11, wherein a transmission of the type 3 HARQ-ACK codebook is in an uplink conflict with another transmission, and the conflict is resolved based on the priority instruction.

13. The method according to claim 11 or 12, wherein the priority instruction is included in the DCI requirement.

14. The method according to claim 13, wherein the DCI request includes a priority associated with the DCI and a separate priority associated with the transmission of the Type 3 HARQ-ACK codebook.

15. The method according to claim 11 or 12, wherein the DCI request includes transmission parameters for the transmission of the Type 3 HARQ-ACK codebook, and the priority instruction is based on the transmission parameters.

16. The method according to any one of claims 11 to 15, wherein the priority instruction indicates a physical uplink control channel (PUCCH) setting to be used for the type 3 HARQ-ACK codebook transmission.

17. The method according to any one of claims 11 to 16, wherein the type 3 HARQ-ACK codebook is transmitted via a physical uplink control channel (PUCCH).

18. The method according to any one of claims 11 to 17, wherein the DCI request is for scheduling physical uplink shared channel (PUCCH) data, and the type 3 HARQ-ACK codebook is transmitted via the physical uplink control channel (PUCCH).

19. The method according to any one of claims 11 to 18, wherein the DCI requirement includes one of DCI format 0_1, DCI format 0_2, DCI format 1_2, and DCI format 1_1.

20. A network node (160) capable of receiving a Type 3 Hybrid Auto-Retransmission Request Acknowledgment (HARQ-ACK) codebook, The invention comprises a processing circuit (170) that is operable to perform the method described in any one of claims 11 to 19. Network node.

Images