Techniques for pucch operation with multi-trp

Abstract

Techniques for physical uplink control channel (PUCCH) operation with multiple transmission and reception points (multi-TRP) are disclosed. In some embodiments, determining a PUCCH transmission repetition can include determining that an original PUCCH transmission overlaps a slot boundary between a first slot for the PUCCH transmission and a second slot for the PUCCH transmission, and configuring a PUCCH repetition of the original PUCCH transmission. The PUCCH repetition can include one or more symbols of the original PUCCH transmission and can be located in one or more slots other than the first slot and the second slot. The PUCCH repetition can be configured by a downlink control information (DCI) configuration including a physical downlink shared channel to hybrid automatic repeat request acknowledgement feedback (PDSCH to HARQ_feedback) timing indicator, a PUCCH repetition number field configuring a number of transmissions of the PUCCH repetition, or a PUCCH resource indicator field configuring a number of transmissions of the PUCCH repetition.

Description

Technical Field

[0001] This application relates to wireless communication systems in general. Background Technology

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

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

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

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

[0006] Figure 1 The procedure for configuring Physical Uplink Control Channel (PUCCH) repetition according to some implementation schemes is shown.

[0007] Figure 2 The procedure for configuring PUCCH repetitive scheduling is shown according to some implementation schemes.

[0008] Figure 3A A diagram is shown illustrating an exemplary minimum timing offset that reflects the minimum hybrid automatic repeat request acknowledgment (HARQ-ACK) processing time for the Physical Downlink Shared Channel (PDSCH) according to some implementation schemes.

[0009] Figure 3B A diagram showing a first repeating pattern and a second repeating pattern according to some implementation schemes is presented.

[0010] Figure 4 The process for PUCCH repetition according to some implementation schemes is shown.

[0011] Figure 5 A diagram illustrating a PUCCH repeating solution according to some implementation schemes is shown.

[0012] Figure 6 Another process for PUCCH repetition is shown according to some implementation schemes.

[0013] Figure 7 Another diagram illustrating a PUCCH repeating solution according to some implementation schemes is shown.

[0014] Figure 8 An exemplary architecture of a network system according to some implementation schemes is shown.

[0015] Figure 9The basic structural equipment according to some implementation schemes is shown.

[0016] Figure 10 The platform is shown according to some implementation schemes.

[0017] Figure 11 System components according to some implementation schemes are shown.

[0018] Figure 12 A table for Media Access Control-Control Element (MAC-CE) according to some implementation schemes is shown. Detailed Implementation

[0019] In New Radio (NR) Physical Uplink Control Channel (PUCCH) design, the PUCCH can have one of the following formats: PUCCH Format 0: 1 to 2 symbols, 1 to 2 payload bits; PUCCH Format 1: 4 or more symbols, 1 to 2 payload bits; PUCCH Format 2: 1 to 2 symbols, more than 2 payload bits; PUCCH Format 3: 4 or more symbols, more than 2 payload bits; PUCCH Format 4: 4 or more symbols, more than 2 payload bits. PUCCH slot aggregation is permitted. For example, Radio Resource Control (RRC) can configure the nrofSlots parameter in the PUCCH-FormatConfig parameter of the PUCCH configuration parameters. Furthermore, the PUCCH beam can be changed via Media Access Control (MAC) Control Elements (CE) (MAC-CE). For example, RRC can configure a list of PUCCH-SpatialRelationInfo parameters in the PUCCH-Config parameter, and MAC-CE can be used to activate a specific beam for a specific PUCCH resource. Only one beam can be configured for a single PUCCH resource.

[0020] In 3GPP Release 16, for multiple transmit and receive points (multiple TRP) operations, Physical Downlink Shared Channel (PDSCH) reliability can be enhanced by using Downlink Control Information (DCI) to allow for more dynamic PDSCH aggregation, and multiple beams can be configured for the same PDSCH with multiple transmit opportunities. Embodiments of this disclosure can enhance PUCCH reliability, including, for example, for multiple TRP operations. In some embodiments, DCI is used to configure dynamic PUCCH repetition. In some embodiments, PUCCH repetition enhancements are provided. In some embodiments, PUCCH beam configuration enhancements are provided. In some embodiments, a default beam is provided when PUCCH-SpatialRelationInfo is not provided.

[0021] As described above, in some implementations, DCI can be used to configure dynamic PUCCH repetition based on one or more of the following solutions.

[0022] Solution 1.1

[0023] In some implementations, DCI can be used to configure dynamic PUCCH repeating by enhancing the DCI field "PDSCH to HARQ_Feedback Timing Indicator". For example, code points can be configured for the DCI field "PDSCH to HARQ_Feedback Timing Indicator". Code points can be configured in the dl-DataToUL-ACK parameter, dl-DataToUL-ACK-r16 parameter, or dl-DataToUL-ACKForDCIFormat1_2 parameter in the PUCCH-Config parameters. For each code point, RRC can configure the following information simultaneously: timing offset, which can be, for example, a value in the range of 0 to 15; and the number of PUCCH repeats, which can be, for example, a value in the range of 1 to N, where N is at least greater than 8. Alternatively, the number of repeats can be left unconfigured; in this case, the number of repeats can be assumed to be 1.

[0024] Solution 1.2

[0025] In some implementations, DCI can be used to configure dynamic PUCCH repetition by introducing a new DCI field. For example, the new DCI field could be the number of PUCCH repetitions. The value of the new DCI field can be from 1 to N, where N is at least greater than 8. If the new DCI field is not configured, the number of repetitions can be assumed to be 1.

[0026] Solution 1.3

[0027] In some implementations, DCI can be used to configure dynamic PUCCH repeating by configuring the DCI field "PUCCH Resource Indicator". PUCCH-resource configuration can be enhanced by adding a configuration information element (IE) for the number of repeats. The value of the number of repeats and / or the PUCCH Resource Indicator can be from 1 to N, where N is at least greater than 8. When no value is configured for the number of repeats and / or the PUCCH Resource Indicator, the value is assumed to be 1.

[0028] Solution 1.4

[0029] In some implementations, PUCCH aggregation (or repetition) enhancements may be constrained to a specific PUCCH format among those discussed above. For example, enhancements may be available only for long PUCCH formats, such as one, a subset of, or all of the following formats: PUCCH format 1, PUCCH format 3, and PUCCH format 4.

[0030] In some implementations, one or more of the following solutions may be used to provide PUCCH repetition enhancement.

[0031] Solution 2.1

[0032] In some implementations, when scheduling PUCCH repetition, the user equipment (UE) is allowed to operate in two possible repetition modes: mode 1, in which the PUCCH is repeated back to back, and a constant can also be configured between PUCCH repetitions; or mode 2, in which the PUCCH is repeated in consecutive time slots, and the same time domain allocation can be used in each time slot.

[0033] Solution 2.2

[0034] In some implementations, the UE can report the maximum number of PUCCH repetitions that the UE can transmit within a time slot. For example, the candidate values ​​for the maximum number of PUCCH repetitions that the UE can transmit within a time slot can be 2, 4, or 7. For example, if the number of repetitions within a time slot exceeds the UE's capacity, additional repetitions can be allocated in the next available time slot using the same time-domain resources as repetitions that do not exceed the capacity.

[0035] Solution 2.3

[0036] In some implementations, a minimum timing offset is determined between the PDSCH and PUCCH used for Hybrid Automatic Repeat Request Acknowledgment (HARQ-ACK) and / or between the Channel State Information Reference Signal (CSI-RS) / Synchronization Signal Block (SSB) measurement on the PUCCH and the corresponding CSI report. For example, the minimum timing offset may be based on the first PUCCH transmission timing. In another example, the minimum timing offset may be based on any PUCCH transmission timing. In some implementations, the minimum timing offset must satisfy a PUCCH minimum timing offset requirement; in this case, the UE will only transmit PUCCH repeats that satisfy that PUCCH minimum timing offset requirement.

[0037] Solution 2.4

[0038] In some implementations, when a single PUCCH transmission opportunity exists across a time slot boundary, the following alternative solutions exist for repeated PUCCH transmissions. Alternative Solution 1: PUCCH repetition is permitted and transmitted by the UE as usual. Alternative Solution 2: The repeated PUCCH is truncated (e.g., no symbol of the original PUCCH exceeding the time slot boundary is transmitted during the repetition).

[0039] Alternative Option 3: The repeated PUCCH is segmented (e.g., the original PUCCH is split into two repeated PUCCHs, where the first repeated PUCCH contains all the symbols of the first time slot and the second repeated PUCCH contains all the symbols of the second time slot).

[0040] Alternative Option 4: Skip the entire PUCCH repetition.

[0041] Solution 2.5

[0042] In some implementations, when a single PUCCH transmission becomes invalid (e.g., the single PUCCH transmission has at least one symbol configured as a downlink (DL) symbol, the uplink transmission of the single PUCCH transmission has been preempted, and / or the single PUCCH transmission conflicts with other higher priority channels and is dropped), PUCCH repetition may be provided according to one or more of the following alternatives.

[0043] Alternative Option 1: The repeated PUCCH is truncated, where, for example, the original PUCCH symbol is not emitted in addition to the DL symbol of the original PUCCH.

[0044] Alternative Option 2: Segment the repeated PUCCH based on the DL symbols of the original PUCCH, wherein, for example, the first segment includes symbols up to the DL symbol, and the second segment includes symbols following the DL symbol.

[0045] Alternative Option 3: Skip the entire PUCCH repetition.

[0046] In some implementations, the PUCCH beam configuration is enhanced according to one or more of the following solutions.

[0047] Solution 3.1

[0048] In some implementations, when configuring PUCCH repetition, multiple beams (e.g., 2 beams) can be configured for the PUCCH. For example, the configuration can specify the following beam patterns: a sequential pattern following the pattern {beam 1, beam 2, beam 1, beam 2...}; or a cyclic pattern following the pattern {beam 1, beam 1, beam 2, beam 2...}.

[0049] Solution 3.2

[0050] In some implementations, the DCI can explicitly indicate the PUCCH beam. For example, a new field in the DCI can be introduced to configure the PUCCH beam. For example, the new field can include one or two quasi-co-located (QCL) configurations. For example, when the new field includes two QCL configurations, two reference signals (RS) can be configured for QCL-type A or QCL-type D or both, and each RS can be a synchronization signal block (SSB), a channel state information reference signal (CSI-RS), or a sounding reference signal (SRS).

[0051] Solution 3.3

[0052] In some implementations, the PUCCH-SpatialRelationInfo parameter can be enhanced to allow the configuration of two PUCCH beams. For example, a PUCCH-SpatialRelationInfo codepoint can be configured to contain two PUCCH-SpatialRelationInfo parameters. For example, a single PUCCH-SpatialRelationInfo parameter can be configured to contain two beams (e.g., the referenceSignal parameter).

[0053] Solution 3.4

[0054] In some implementations, the MAC-CE is allowed to activate the relationship between two PUCCH spaces used for PUCCH resources. For example, this solution could modify an existing MAC-CE as follows (e.g.) Figure 12 Table 1200 in the table reflects 3GPP version 16. Figure 6 .1.3.18-1).

[0055] For example, an additional octet line (e.g., another S0 to S7) can be added below octet 3 and used to configure the second PUCCH beam. Furthermore, for example, for each octet line of the last two lines (e.g., octet 3 and the additional octet line), only a single PUCCH spatial relation (e.g., the PUCCH-SpatialRelationInfo parameter) can be activated. In another example, both lines can activate the same PUCCH spatial relation. In yet another example, the two lines can activate different PUCCH spatial relations.

[0056] In some implementations, the default beam can be used when the PUCCH-SpatialRelationInfo parameter is not provided according to the following solution.

[0057] Solution 4.1

[0058] In some implementations, when the PUCCH-SpatialRelationInfo parameter is not provided and the UE is configured with PUCCH repetition, a default beam can be provided according to the following alternatives: Alternative 1: Default to the PDSCH-activated Transmit Configuration Indicator (TCI) codepoint, where the lowest index has two TCI states. Alternative 2: For each beam, default to the CORESETPoolIndex parameter with the lowest ID. Alternative 3: Default to the PDSCH-activated TCI codepoint with only the lowest ID. Alternative 4: Default to the CORESET with the lowest ID in the most recent PDCCH monitoring slot.

[0059] The various solutions will now be explained in further detail with reference to the accompanying drawings. It should be noted that each of these solutions may be implemented by a UE (e.g., the UE executes one or more blocks of the disclosed process), by a combination of the UE and other system components, or by system components other than the UE. The order of the blocks described in the disclosed process may differ from the order shown in the figures. One or more blocks of the disclosed process may be combined with each other (including from different processes) and / or removed. Processes may be combined with each other such that blocks from one or more processes are used with blocks from one or more other processes to form a combined process.

[0060] Figure 1 A process 100 for configuring PUCCH repeating is illustrated according to some embodiments. In some embodiments, DCI can be used to configure dynamic PUCCH repeating. For example, configuring DCI can configure dynamic PUCCH repeating.

[0061] At box 102, Multiple Transmit and Receive Point (Multiple TRP) operation is defined. In some implementations, the UE may determine that it is configured for multiple TRP operation and PUCCH. In some implementations, the network may determine that the UE is configured for multiple TRP operation and PUCCH.

[0062] At box 104, PUCCH repeat is configured. In some embodiments, the DCI is configured to configure PUCCH repeat. In some embodiments, the DCI is configured using the DCI field “PDSCH to HARQ_Feedback Timing Indicator”. For example, code points (e.g., reflecting one or more values ​​of desired settings or parameters, such as numerical values) can be configured for the DCI field “PDSCH to HARQ_Feedback Timing Indicator”. For example, code points can be configured in the dl-DataToUL-ACK parameter, the dl-DataToUL-ACK-r16 parameter, or the dl-DataToUL-ACKForDCIFormat1_2 parameter in the PUCCH-Config parameters. In some embodiments, the DCI field PDSCH to HARQ_Feedback Timing Indicator is configured by Radio Resource Control (RRC) to configure the number of PUCCH repeats (e.g., the number of PUCCH repeats). In some embodiments, for one or more code points, the RRC configures the timing offset and / or the number of PUCCH repeats. For example, this configuration of the timing offset and the number of PUCCH repeats can be performed simultaneously. For example, the timing offset can be a value ranging from 0 to 15. For example, the number of PUCCH repetitions can be a value ranging from 1 to N, where N is at least greater than 8. In some implementations, if the number of PUCCH repetitions is not configured, the number of repetitions is assumed to be 1. For example, the number of PUCCH repetitions can be the number of times the transmitted PUCCH is repeated.

[0063] In some implementations, the DCI is configured to configure PUCCH repetition by introducing or including a new DCI field. For example, the new DCI field could be the number of PUCCH repetitions. In some implementations, the value of the new DCI field could be from 1 to N, where N is at least greater than 8. In some implementations, if the new DCI field is not configured, the number of repetitions is assumed to be 1. For example, the number of PUCCH repetitions could be the number of times the PUCCH is emitted.

[0064] In some implementations, the DCI is configured to configure PUCCH repetition by configuring the DCI field "PUCCH Resource Indicator". For example, a configuration information element (IE) for the number of repetitions is used to configure the PUCCH Resource Indicator field. In some implementations, the value of the number of repetitions and / or the PUCCH Resource Indicator can be from 1 to N, where N is at least greater than 8. In some implementations, the value is assumed to be 1 when the number of repetitions and / or the PUCCH Resource Indicator is not configured. For example, the number of PUCCH repetitions can be the number of times the PUCCH is emitted.

[0065] In some implementations, PUCCH repetition using DCI (e.g., enhanced PUCCH repetition) is constrained to a certain PUCCH format. For example, a PUCCH may have one of the following formats: PUCCH format 0: 1 to 2 symbols, 1 to 2 bits payload; PUCCH format 1: 4 or more symbols, 1 to 2 bits payload; PUCCH format 2: 1 to 2 symbols, more than 2 bits payload; PUCCH format 3: 4 or more symbols, more than 2 bits payload; PUCCH format 4: 4 or more symbols, more than 2 bits payload. In some implementations, PUCCH repetition is configured only for one, a subset of, or all of the above PUCCH formats. In some implementations, PUCCH repetition is configured only for one, a subset of, or all of PUCCH formats 1, 3, and / or 4.

[0066] In some implementations, multiple beams are configured in a PUCCH repetitive configuration. For example, multiple beams (e.g., two beams) may be configured for the PUCCH. In some implementations, the multiple beams are configured in a certain pattern. For example, the pattern may be a sequential pattern, in which the first and second beams are configured to transmit according to the pattern: {first beam, second beam, first beam, second beam... and so on in multiple cycles}. In another example, the pattern may be a cyclic pattern, in which the first and second beams are configured to transmit according to the pattern: {first beam, first beam, second beam, second beam... and so on in multiple cycles}.

[0067] In some implementations, the DCI can explicitly indicate the PUCCH beam used for PUCCH repetition configuration. For example, a new field in the DCI can be introduced to configure the PUCCH beam. For example, the new field can contain one or two quasi-co-located (QCL) configurations. For example, when the new field contains two QCL configurations, two reference signals (RS) can be configured for QCL-type A or QCL-type D or both, and each RS can be a synchronization signal block (SSB), a channel state information reference signal (CSI-RS), or a sounding reference signal (SRS).

[0068] In some implementations, the PUCCH-SpatialRelationInfo parameter can be enhanced to allow a configuration of two PUCCH beams for PUCCH repetition configuration. For example, a PUCCH-SpatialRelationInfo codepoint can be configured to contain two PUCCH-SpatialRelationInfo parameters. For example, a single PUCCH-SpatialRelationInfo parameter can be configured to contain two beams (e.g., the referenceSignal parameter).

[0069] In some implementations, the MAC-CE is allowed to activate the relationship between two PUCCH spaces used for PUCCH resources (e.g., for PUCCH repetition configuration). For example, this solution can modify an existing MAC-CE (such as...) Figure 12 Table 1200 in the table reflects 3GPP version 16. Figure 6 .1.3.18-1).

[0070] In some implementations, an additional octet line with S0 through S7 is added below octet 3 and used to configure the second PUCCH beam. In some implementations, for each octet line of the last two lines (e.g., octet 3 and the additional octet line), only a single PUCCH spatial relation (e.g., the PUCCH-SpatialRelationInfo parameter) can be activated. In another example, the same PUCCH spatial relation can be activated in both lines. In yet another example, different PUCCH spatial relations can be activated in both lines.

[0071] In some implementations, a default beam is used when the PUCCH-SpatialRelationInfo parameter is not provided. In some implementations, when the PUCCH-SpatialRelationInfo parameter is not provided and the UE is configured with PUCCH repetition, a default beam may be provided according to the following alternative schemes. In some implementations, in Alternative Scheme 1, each beam defaults to a PDSCH-activated Transmit Configuration Indicator (TCI) codepoint, where the lowest index has two TCI states. In some implementations, in Alternative Scheme 2, each beam defaults to a CORESET with the lowest ID per CORESETPoolIndex parameter. In some implementations, in Alternative Scheme 3, each beam defaults to a PDSCH-activated TCI codepoint with only the lowest ID. In some implementations, in Alternative Scheme 4, each beam defaults to a CORESET with the lowest ID in the most recent PDCCH monitoring slot.

[0072] At box 106, one or more PUCCH repeats are emitted according to the PUCCH repeating configuration.

[0073] Figure 2 A procedure 200 for configuring PUCCH repetitive scheduling is shown according to some implementation schemes.

[0074] At box 202, the PUCCH repetition configuration is determined. In some implementations, the UE determines that it is configured for PUCCH repetition. In some implementations, the network determines that the UE is configured for PUCCH repetition. In some implementations, PUCCH repetition is configured as discussed in box 104.

[0075] At box 204, PUCCH repetition parameters are reported. In some implementations, the UE configured for PUCCH repetition reports or transmits PUCCH repetition parameters to the network. For example, the UE may report the maximum number of PUCCH repetitions that the UE is capable of or configured to transmit within a time slot. In some implementations, candidate values ​​for the number of repetitions are 2, 4, or 7. In some implementations, when the number of repetitions within a time slot exceeds the UE's capacity, additional repetitions are transmitted in the next available time slot. In some implementations, these additional repetitions are transmitted in the next available time slot using the same time-domain resources allocated as repetitions that do not exceed the capacity. In some implementations, the next available time slot is a time slot adjacent to the current time slot. In some implementations, the next available time slot is not adjacent to the current time slot and is located in one or more time slots away from the current time slot.

[0076] At box 206, the minimum timing offset for PUCCH repetition is determined. In some embodiments, the minimum timing offset determines when the first PUCCH can be scheduled. In some embodiments, the minimum timing offset is between the PDSCU and its corresponding PUCCH used for HARQ-ACK, and reflects the minimum HARQ-ACK processing time. In some embodiments, the minimum timing offset is between the CSI-RS / SSB measurement on the PUCCH and the corresponding CSI report.

[0077] In some implementations, the minimum timing offset is based on the first PUCCH transmission timing. In some implementations, the minimum timing offset is based on any PUCCH transmission timing. In some implementations, the minimum timing offset must satisfy the PUCCH minimum timing offset requirement. For example, the UE will only transmit PUCCH repetitions that satisfy the PUCCH minimum timing offset requirement.

[0078] As described, in some embodiments, the minimum timing offset reflects the minimum HARQ-ACK processing time. In some embodiments, the first PUCCH repetition timing satisfies the minimum HARQ-ACK processing time associated with the PDSCH. In some embodiments, the first PUCCH repetition timing or any other PUCCH repetition timing satisfies the minimum HARQ-ACK processing time associated with the PDSCH. In some embodiments, the UE does not need to transmit PUCCH repetition timings that do not satisfy the minimum HARQ-ACK processing time associated with the PDSCH. In some embodiments, the UE transmits PUCCH repetition timings that satisfy the minimum HARQ-ACK processing time associated with the PDSCH.

[0079] Figure 3A Figure 300 illustrates an exemplary minimum timing offset reflecting the minimum HARQ-ACK processing time 302 for PDSCH 304, according to some embodiments. In Figure 300, PUCCH 306, 308, 310, and 312 are PUCCH transmissions that may occur for PDSCH 304. As shown by Figure 300, the minimum HARQ-ACK processing time 302 extends from PDSCH 304 (e.g., from after the last symbol of PDSCH 304) through a portion of slot 4. Therefore, in the example shown, PUCCH 306 and 308 do not satisfy the minimum timing offset because PUCCH 306 and 308 are within the minimum HARQ-ACK processing time 302. PUCCH 306 and 308 may therefore not be the first PUCCH transmission after PDSCH 304. In the example shown, PUCCH 310 and 312 conform to the minimum timing offset because they are located in slots 5 and 6, which follow slots 1, 2, 3, and 4, which are covered by the minimum HARQ-ACK processing time 302. Therefore, since PUCCH 310 conforms to the minimum timing offset, the first PUCCH transmission after PDSCH 304 can be PUCCH 310, and the repeating PUCCH can be PUCCH 312.

[0080] Return to Figure 2 At box 208, PUCCH repetition is scheduled. In some implementations, the scheduled PUCCH repetition conforms to the minimum timing offset of the PUCCH repetition. In some implementations, PUCCH repetition scheduling provides the ability for the UE to operate in a first repetition mode and / or a second repetition mode. Figure 3BFigure 314 illustrates a first repetition mode and a second repetition mode according to some embodiments. In the first repetition mode, PUCCH repetitions are repeated consecutively. In some embodiments, constants may also be configured between PUCCH repetitions. In some embodiments, the consecutive repetitions overlap with one or more time slot boundaries. As shown in Figure 314, in the first repetition mode 316, PUCCH repetitions 318, 320, 322, and 324 are repeated consecutively and overlap with the boundaries between time slots 1, 2, and 3. In the second repetition mode, PUCCH repetitions are repeated in consecutive time slots, and one or more time slot boundaries do not overlap with the PUCCH. In some embodiments, the repetitions may use the same time domain allocation within each time slot. As shown in Figure 314, in the second repetition mode 326, PUCCH repetitions 328, 330, 332, and 334 are repeated in consecutive time slots, and the time slots do not overlap with the PUCCH.

[0081] At box 210, one or more PUCCH repeats are transmitted repeatedly based on the scheduled / already scheduled PUCCH.

[0082] Figure 4 A procedure 400 for PUCCH repetition is illustrated according to some embodiments. At block 402, PUCCH repetition configuration is determined. In some embodiments, the UE determines that it is configured for PUCCH repetition. In some embodiments, the network determines that the UE is configured for PUCCH repetition. In some embodiments, this block may be the same as or similar to block 202. In some embodiments, PUCCH repetition is configured as discussed in block 104.

[0083] At box 404, the original PUCCH transmission overlapping with a time slot boundary is identified. For example, a time slot boundary could be the boundary between a first time slot used for PUCCH transmission and a second time slot used for PUCCH transmission. In some embodiments, the original PUCCH transmission overlaps with a single time slot boundary. In some embodiments, the original PUCCH transmission overlaps with one or more time slot boundaries. In some embodiments, the original PUCCH transmission overlaps with two or more time slot boundaries.

[0084] At box 406, the PUCCH repetition technique for the original PUCCH transmission that overlaps with one or more time slot boundaries is identified. Figure 5 Figure 500 illustrates various PUCCH repetition techniques / solutions according to some implementation schemes. For example, Figure 5 Figure 502 shows the original PUCCH 504 overlapping with the time slot boundary 506 between time slot 1 and time slot 2.

[0085] In some implementations, PUCCH repetition is a repetition of the original PUCCH transmission. In solution 508, PUCCH repetition 510 is permitted and transmitted by the UE in time slots 3 and 4 and across the boundary 512 between time slots 3 and 4 (e.g., repetition 510 overlaps with boundary 512). PUCCH repetition 510 is a repetition of the original PUCCH 504 and includes all symbols of PUCCH 504.

[0086] In some implementations, a PUCCH repeat is a truncated version of the original PUCCH transmission. For example, in solution 514, one or more or all of the symbols of the original PUCCH 504 that extend beyond or overlap with slot boundary 506 are not transmitted in the repeat. Therefore, one or more symbols transmitted in the repeat are in repeat PUCCH 516, and the truncated remaining symbols 518 of the original PUCCH 504 that are located after slot boundary 520 are not transmitted in the repeat.

[0087] In some implementations, a PUCCH repeat is a segmented version of the original PUCCH transmission. For example, in solution 522, the original PUCCH 504 is segmented into repeat PUCCH 524 and repeat PUCCH '526 for repeating, wherein the segmentation occurs at slot boundary 528. Here, repeat PUCCH 524 includes one or more or all symbols of the original PUCCH 504 from slot 1, and repeat PUCCH '526 includes one or more or all symbols of the original PUCCH 504 from slot 2.

[0088] In some implementations, PUCCH repetition is skipped, such as Figure 5 Solution 530 is shown. For example, PUCCH duplicates can be generated, but not sent. In another example, PUCCH duplicates are not generated at all.

[0089] return Figure 4 At box 408, one or more PUCCH repeats are emitted according to the determined repeats. If a PUCCH repeat is skipped, no PUCCH repeat is emitted.

[0090] Figure 6 A process 600 for PUCCH repetition according to some embodiments is shown. At block 602, an invalid original PUCCH transmission is determined. For example, this determination may include one or more of the following: determining that the original PUCCH transmission has at least one symbol configured as a downlink (DL) symbol; determining that the original PUCCH transmission has a preempted uplink transmission; and / or determining that the original PUCCH transmission collides with one or more other higher priority channels and is dropped.

[0091] At box 604, the PUCCH repetition used for the identified invalid original PUCCH emission is determined. Figure 7 Figure 700 illustrates a PUCCH repetition solution according to some implementations. In some implementations, the original PUCCH includes one or more downlink (DL) symbols. For example, Figure 702 shows an original PUCCH 704 including DL symbol 706. Although the original PUCCH 704 spans the slot boundary between slot 1 and slot 2, the original PUCCH does not need to span the slot boundary and can be contained in a single slot.

[0092] In some implementations, PUCCH repetition is a truncated version of the original PUCCH based on the position of the DL symbol within the original PUCCH. For example, in solution 708, repetitive PUCCH 710 includes symbols from the original PUCCH 704 to DL symbol 706, where DL symbol 706 is represented by DL 712 in repetitive PUCCH 710. Symbols of the original PUCCH 704 located outside or after DL symbol 706 are not transmitted in repetitive PUCCH 710. In some implementations, DL 712 is not included in repetitive PUCCH 710.

[0093] In some implementations, PUCCH repetition is a segmented version of the original PUCCH based on the position of the DL symbol within the original PUCCH. For example, in solution 714, the first segmented repetition PUCCH 716 includes a symbol located up to (e.g., before) the DL symbol 706 in the original PUCCH 704 and does not include that DL symbol, and the second segmented repetition PUCCH 720 includes a symbol located after the DL symbol 706 in the original PUCCH 704 and does not include that DL symbol. Region 718 reflects the position that the DL symbol 706 of the original PUCCH 704 would have been in the repetition if included. In some implementations, the DL symbol is included in one or both of the first segmented repetition PUCCH 716 and / or the second segmented repetition PUCCH 720.

[0094] In some implementations, PUCCH repetition is skipped, such as Figure 7 Solution 722 is shown. For example, PUCCH duplicates can be generated, but not sent. In another example, PUCCH duplicates are not generated at all.

[0095] return Figure 6 At box 606, one or more PUCCH repeats are emitted according to the determined repeats. If a PUCCH repeat is skipped, no PUCCH repeat is emitted.

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

[0097] like Figure 8 As shown, system 800 includes UE 822 and UE 820. In this example, UE 822 and UE 820 are shown as smartphones (e.g., handheld touchscreen mobile computing devices that can connect to one or more cellular networks), but may also include any mobile or non-mobile computing device, such as consumer electronics devices, mobile phones, smartphones, feature phones, tablets, wearable computing devices, personal digital assistants (PDAs), pagers, wireless handheld devices, desktop computers, laptops, in-vehicle infotainment (IVI), in-vehicle entertainment (ICE) devices, instrument cluster (IC), head-up display (HUD) devices, onboard diagnostic (OBD) devices, dashboard mobile equipment (DME), mobile data terminal (MDT), electronic engine management system (EEMS), electronic / engine electronic control unit (ECU), electronic / engine electronic control module (ECM), embedded systems, microcontrollers, control modules, engine management system (EMS), connected or “smart” appliances, MTC devices, M2M, IoT devices, etc.

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

[0099] UE 822 and UE 820 can be configured to connect to an access node or radio access node (shown as (R)AN 808), for example, through communication coupling. In implementations, (R)AN 808 can be an NG RAN or SG RAN, E-UTRAN, or a legacy RAN such as UTRAN or GERAN. As used herein, the term "NG RAN," etc., can refer to (R)AN 808 operating in an NR or SG system, and the term "E-UTRAN," etc., can refer to (R)AN 808 operating in an LTE or 4G system. UE 822 and UE 820 utilize connections (or channels) (shown as connection 804 and connection 802, respectively), each of which includes a physical communication interface or layer (discussed in further detail below).

[0100] In this embodiment, connection 804 and connection 802 are air interfaces for communication coupling and can be consistent with cellular communication protocols, such as GSM, CDMA network protocols, PTT, POC, UMTS, 3GPP LTE, SG, NR, and / or any other communication protocols discussed herein. In this implementation, UE 822 and UE 820 can also directly exchange communication data via ProSe interface 810. ProSe interface 810 may alternatively be referred to as sidelink (SL) interface 110 and may include one or more logical channels, including but not limited to PSCCH, PSSCH, PSDCH, and PSBCH.

[0101] UE 820 is shown configured to access AP 812 (also known as a "WLAN node", "WLAN", "WLAN terminal", "WT", etc.) via connection 824. Connection 824 may include a local wireless connection, such as a connection consistent with any IEEE 802.11 protocol, where AP 812 will include Wireless Fibre. Router. In this embodiment, AP 812 may connect to the Internet but not to the core network of the wireless system (described in further detail below). In various implementations, UE 820, (R)AN 808, and AP 812 may be configured to utilize LWA operation and / or LWIP operation. LWA operation may involve UE 820 in RRC_CONNECTED being configured by RAN node 814 or RAN node 816 to utilize the radio resources of LTE and WLAN. LWIP operation may involve UE 820 using WLAN radio resources (e.g., connection 824) via IPsec protocol tunneling to authenticate and encrypt packets (e.g., IP packets) transmitted through connection 824. IPsec tunneling may include encapsulating the entire original IP packet and adding a new packet header to protect the original header of the IP packet.

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

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

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

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

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

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

[0108] According to various implementations, UE 822 and UE 820 and RAN node 814 and / or RAN node 816 transmit data (e.g., transmit and receive data) through licensed media (also referred to as “licensed spectrum” and / or “licensed band”) and unlicensed shared media (also referred to as “unlicensed spectrum” and / or “unlicensed band”). Licensed spectrum may include channels operating in the frequency range of approximately 400 MHz to approximately 3.8 GHz, while unlicensed spectrum may include a 5 GHz band.

[0109] To operate in unlicensed spectrum, UE 822 and UE 820, along with RAN node 814 and / or RAN node 816, may use LAA, eLAA, and / or feLAA mechanisms. In these specific implementations, UE 822 and UE 820, along with RAN node 814 or RAN node 816, may perform one or more known medium sensing and / or carrier sensing operations before transmitting in the unlicensed spectrum to determine whether one or more channels in the unlicensed spectrum are unavailable or otherwise occupied. The medium / carrier sensing operations may be performed according to a Talk-After-Listen (LBT) protocol.

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

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

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

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

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

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

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

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

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

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

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

[0121] In this implementation, CN 806 may be an SGC, and (R)AN 116 may be connected to CN 806 via NG interface 834. In this implementation, NG interface 834 may be divided into two parts: an NG user plane (NG-U) interface 826, which carries traffic data between RAN node 814 or RAN node 816 and the UPF; and an S1 control plane (NG-C) interface 828, which is the signaling interface between RAN node 814 or RAN node 816 and the AMF.

[0122] In one implementation, CN 806 may be an SG CN, while in other implementations, CN 806 may be an EPC. When CN 806 is an EPC, (R)AN 116 may be connected to CN 806 via S1 interface 834. In one implementation, S1 interface 834 may be divided into two parts: an S1 user plane (S1-U) interface 826, which carries traffic data between RAN node 814 or RAN node 816 and the S-GW; and an S1-MME interface 828, which is the signaling interface between RAN node 814 or RAN node 816 and the MME.

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

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

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

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

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

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

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

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

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

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

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

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

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

[0136] For example, the processor of application circuit 1002 may include a processor based on... Architecture Core TM processors, such as Quark TM Atom TM i3, i5, i7 or MCU-level processors, or available from Another such processor from the Corporation. The processor for application circuit 1002 may also be one or more of the following: Advanced Micro Devices (AMD). Processor or Accelerated Processing Unit (APU); from Inc.'s AS-A9 processor, from

[0137] Snapdragon by Technologies, Inc. TM Processor, Texas Instruments OpenMultimedia Applications Platform(OMAP) TM Processors; MIPS-based designs from MIPS Technologies, Inc., such as the MIPS Warrior M-class, Warrior I-class, and Warrior P-class processors; ARM-based designs licensed from ARM Holdings, Ltd., such as the ARM Cortex-A, Cortex-R, and Cortex-M series processors; etc. In some specific implementations, application circuitry 1002 may be part of a system-on-a-chip (SoC), where application circuitry 1002 and other components are formed as a single integrated circuit or a single package, such as... company( Edison Corporation TM Or Galileo TM SoC board.

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

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

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

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

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

[0143] Platform 1000 may also include interface circuitry (not shown) for connecting external devices to platform 1000. External devices connected to platform 1000 via this interface circuitry include sensor 1022 and electromechanical components (shown as EMC 1024), as well as a removable memory device coupled to removable memory 1026.

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

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

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

[0147] The driving circuit 1018 may include software and hardware elements for controlling specific devices embedded in, attached to, or otherwise communicatively coupled to the platform 1000. The driving circuit 1018 may include various drivers that allow other components of the platform 1000 to interact with or control various input / output (I / O) devices that may exist within or be connected to the platform. For example, the driving circuit 1018 may include: a display driver for controlling and allowing access to a display device; a touchscreen driver for controlling and allowing access to a touchscreen interface of the platform 1000; a sensor driver for acquiring sensor readings of the sensor 1022 and controlling and allowing access to the sensor 1022; an EMC driver for acquiring the actuator position of the EMC 1024 and / or controlling and allowing access to the EMC 1024; a camera driver for controlling and allowing access to an embedded image capture device; and an audio driver for controlling and allowing access to one or more audio devices.

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

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

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

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

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

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

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

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

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

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

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

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

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

[0161] Example Section

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

[0163] Example 1 may include a method for determining physical uplink control channel (PUCCH) transmission repetition. The method may include: determining that the original PUCCH transmission overlaps with a time slot boundary, the time slot boundary being a boundary between a first time slot used for PUCCH transmission and a second time slot used for PUCCH transmission; and configuring PUCCH repetition of the original PUCCH transmission, wherein the PUCCH repetition includes one or more symbols of the original PUCCH transmission and is located in one or more time slots other than the first and second time slots, and wherein the PUCCH repetition is configured by downlink control information (DCI) configuration, the DCI configuration including a physical downlink shared channel to hybrid automatic repeat request acknowledgment feedback (PDSCH to HARQ_feedback) timing indicator, a PUCCH repetition count field configuring the number of transmissions for the PUCCH repetition, or a PUCCH resource indicator field configuring the number of transmissions for the PUCCH repetition. The method may further include: transmitting the PUCCH repetition.

[0164] Example 2 may include the method of Example 1, wherein the DCI configuration includes the PDSCH to HARQ_feedback timing indicator, and wherein the PDSCH to HARQ_feedback timing indicator is configured by Radio Resource Control (RRC) to configure the number of times the PUCCH is repeated, wherein the number of times the PUCCH is repeated is a value in the range of 1 to N, wherein N is greater than 8.

[0165] Example 3 may include the method of Example 1, wherein the DCI configuration includes the PUCCH repetition count field, and wherein the value of the PUCCH repetition count field is the number of times the PUCCH is repeated and is in the range of 1 to N, wherein N is greater than 8.

[0166] Example 4 may include the method of Example 1, wherein the DCI configuration includes the PUCCH resource indicator field, and wherein the value of the PUCCH resource indicator field is the number of times the PUCCH is repeated and is in the range of 1 to N, wherein N is greater than 8.

[0167] Example 5 may include the method of Example 1, wherein the PUCCH repeat is constrained to PUCCH format 1, PUCCH format 3 or PUCCH format 4.

[0168] Example 6 may include the method of Example 1, wherein the PUCCH repeat includes all symbols emitted by the original PUCCH.

[0169] Example 7 may include the method of Example 1, wherein the PUCCH repeat is a truncated version of the original PUCCH transmission, the truncated version excluding any symbols of the original PUCCH transmission that overlap with the slot boundary.

[0170] Example 8 may include the method of Example 1, wherein the PUCCH repeat is a segmented version of the original PUCCH transmission, the segmented version being formed by a first repeating PUCCH segment and a second repeating PUCCH segment, the first repeating PUCCH segment including all symbols of the original PUCCH transmission located in the first time slot, and the second repeating PUCCH segment including all symbols of the original PUCCH transmission located in the second time slot.

[0171] Example 9 may include the method of Example 1, wherein the PUCCH repetition is a first PUCCH repetition that satisfies the minimum HARQ-ACK processing time associated with the PDSCH.

[0172] Example 10 may include the method of Example 1, wherein the PUCCH repeat satisfies the minimum HARQ-ACK processing time associated with the PDSCH, and wherein the user equipment (UE) is configured to transmit the PUCCH repeat and not transmit one or more other PUCCH repeats that do not satisfy the minimum HARQ-ACK processing time associated with the PDSCH.

[0173] Example 11 may include the method of Example 1, wherein the PUCCH repeat is one of a plurality of PUCCH repeats scheduled to be consecutive and overlapping one or more time slot boundaries.

[0174] Example 12 may include the method of Example 1, wherein the PUCCH repeat is one of a plurality of PUCCH repeats scheduled in consecutive time slots and not overlapping with any time slot boundaries.

[0175] Example 13 may include the method of Example 12, wherein the plurality of PUCCHs repeatedly use the same time domain allocation in each of these consecutive time slots.

[0176] Example 14 may include the method of Example 1, wherein the original PUCCH transmission includes downlink (DL) symbols.

[0177] Example 15 may include the method of Example 14, wherein the PUCCH repeat is a truncated version of the original PUCCH emission, the truncated version excluding any symbols of the original PUCCH emission that are located after the DL symbol.

[0178] Example 16 may include the method of Example 14, wherein the PUCCH repeat is a segmented version of the original PUCCH, the segmented version being formed by a first repeating PUCCH segment and a second repeating PUCCH segment, the first repeating PUCCH segment including all symbols emitted by the original PUCCH preceding the DL symbol, and the second repeating PUCCH segment including all symbols emitted by the original PUCCH following the DL symbol.

[0179] Example 17 may include the method of Example 1, and further includes: reporting the maximum number of times a PUCCH is repetitive within a time slot when the user equipment is configured to transmit.

[0180] Example 18 may include a non-transitory computer-readable storage medium comprising instructions that, when executed by a processor, cause the processor to: determine that a raw physical uplink control channel (PUCCH) transmission overlaps with a timeslot boundary, the timeslot boundary being a boundary between a first timeslot used for PUCCH transmission and a second timeslot used for PUCCH transmission; configure a PUCCH repetition of the raw PUCCH transmission, wherein the PUCCH repetition includes one or more symbols of the raw PUCCH transmission and is located in one or more timeslots other than the first and second timeslots, and wherein the PUCCH repetition is configured by downlink control information (DCI) configuration, the DCI configuration including a physical downlink shared channel to hybrid automatic repeat request acknowledgment feedback (PDSCH to HARQ_feedback) timing indicator, a PUCCH repetition count field configuring the number of transmissions for the PUCCH repetition, or a PUCCH resource indicator field configuring the number of transmissions for the PUCCH repetition. These instructions, when executed by the processor, cause the processor to: transmit the PUCCH repetition.

[0181] Example 19 may include the non-transitory computer-readable storage medium of Example 18, wherein the PUCCH repeat is a truncated version of the original PUCCH transmission, the truncated version excluding any symbols of the original PUCCH transmission that overlap with the slot boundary.

[0182] Example 20 may include a computing device for determining physical uplink control channel (PUCCH) transmission repetition. The computing device may include: a processor; and a memory storing instructions that, when executed by the processor, configure the device to: determine that the original PUCCH transmission overlaps with a time slot boundary, the time slot boundary being a boundary between a first time slot used for PUCCH transmission and a second time slot used for PUCCH transmission; and configure PUCCH repetition of the original PUCCH transmission, wherein the PUCCH repetition includes one or more symbols of the original PUCCH transmission and is located in one or more time slots other than the first and second time slots, and wherein the PUCCH repetition is configured by downlink control information (DCI) configuration, the DCI configuration including a physical downlink shared channel to hybrid automatic repeat request acknowledgment feedback (PDSCH to HARQ_feedback) timing indicator, a PUCCH repetition count field configuring the number of transmissions for the PUCCH repetition, or a PUCCH resource indicator field configuring the number of transmissions for the PUCCH repetition. These instructions, when executed by the processor, can further configure the device to emit the PUCCH repeat.

[0183] Example 21 may include the computing device of Example 20, wherein the PUCCH repeat is a truncated version of the original PUCCH transmission, the truncated version excluding any symbols of the original PUCCH transmission that overlap with the time slot boundary.

[0184] Example 22 may include an apparatus comprising means for performing one or more elements of the method or any other method or process described herein, as described in any of the above examples or related to them.

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

[0186] Example 24 may include an apparatus comprising one or more elements of a logic component, module, or circuit for performing one or more of the methods or processes described in or associated with any of the above examples or any other methods or processes described herein.

[0187] Example 25 may include any method, technique, or process, or part or component thereof, that is described in or related to any of the above examples.

[0188] Example 26 may include an apparatus comprising: one or more processors and one or more computer-readable media, the one or more computer-readable media including instructions that, when executed by the one or more processors, cause the one or more processors to perform a method, technique, or process, or a portion thereof, as described in or associated with any of the above embodiments.

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

[0190] Embodiment 28 may include datagrams, packets, frames, segments, protocol data units (PDUs) or messages, or portions or components thereof, as described in any of the above embodiments or in connection with them, or otherwise as described in this disclosure.

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

[0192] Embodiment 30 may include a signal or part or component thereof encoded as a datagram, packet, frame, segment, PDU or message as described in any of the above embodiments or in connection with them, or otherwise described in this disclosure.

[0193] Example 31 may include an electromagnetic signal carrying computer-readable instructions, wherein execution of the computer-readable instructions by one or more processors will cause the one or more processors to perform any of the methods, techniques or processes, or portions thereof, as described in or associated with any of the above examples.

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

[0195] Example 33 may include signals in a wireless network as shown and described herein.

[0196] Example 34 may include methods for communicating in a wireless network as shown and described herein.

[0197] Example 35 may include a system for providing wireless communication as shown and described herein.

[0198] Example 36 may include a device for providing wireless communication as shown and described herein.

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

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

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

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

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

Claims

1. A method for determining repetition of Physical Uplink Control Channel (PUCCH) transmissions, comprising: The original PUCCH transmission is determined to overlap with a time slot boundary, which is the boundary between a first time slot used for PUCCH transmission and a second time slot used for PUCCH transmission. Configure PUCCH repetition for the original PUCCH transmission, wherein the PUCCH repetition includes one or more symbols of the original PUCCH transmission and is located in one or more time slots other than the first time slot and the second time slot, and wherein the PUCCH repetition is configured by downlink control information (DCI) configuration, the DCI configuration including a physical downlink shared channel to hybrid automatic repeat request acknowledgment feedback timing indicator, i.e., a PDSCH to HARQ_feedback timing indicator, and a PUCCH repetition count field configuring the number of transmissions for the PUCCH repetition or a PUCCH resource indicator field configuring the number of transmissions for the PUCCH repetition, wherein the PUCCH repetition count field or the PUCCH resource indicator field includes a value indicating the number of transmissions for the PUCCH repetition; and The PUCCH is emitted repeatedly.

2. The method of claim 1, wherein the DCI configuration includes the PDSCH to HARQ_feedback timing indicator, and wherein the PDSCH to HARQ_feedback timing indicator is configured by Radio Resource Control (RRC) to configure the number of times the PUCCH is repeated, wherein the number of times is a value in the range of 1 to N, where N is greater than 8.

3. The method of claim 1, wherein the DCI configuration includes the PUCCH repetition count field, and wherein the value of the PUCCH repetition count field is the number of times the PUCCH is repeated and is in the range from 1 to N, where N is greater than 8.

4. The method of claim 1, wherein the DCI configuration includes the PUCCH resource indicator field, and wherein the value of the PUCCH resource indicator field is the number of times the PUCCH is repeated and is in the range from 1 to N, where N is greater than 8.

5. The method of claim 1, wherein the PUCCH repeat is constrained to PUCCH format 1, PUCCH format 3 or PUCCH format 4.

6. The method of claim 1, wherein the PUCCH repeat comprises all symbols emitted by the original PUCCH.

7. The method of claim 1, wherein the PUCCH repeat is a truncated version of the original PUCCH transmission, the truncated version excluding any symbols of the original PUCCH transmission that overlap with the slot boundary.

8. The method of claim 1, wherein the PUCCH repeat is a segmented version of the original PUCCH transmission, the segmented version being formed by a first repeating PUCCH segment and a second repeating PUCCH segment, the first repeating PUCCH segment including all symbols of the original PUCCH transmission located in the first time slot, and the second repeating PUCCH segment including all symbols of the original PUCCH transmission located in the second time slot.

9. The method of claim 1, wherein the PUCCH repetition is a first PUCCH repetition that satisfies the minimum HARQ-ACK processing time associated with the PDSCH.

10. The method of claim 1, wherein the PUCCH repeat satisfies the minimum HARQ-ACK processing time associated with the PDSCH, and wherein the user equipment (UE) is configured to transmit the PUCCH repeat and not transmit one or more other PUCCH repeats that do not satisfy the minimum HARQ-ACK processing time associated with the PDSCH.

11. The method of claim 1, wherein the PUCCH repeat is one of a plurality of PUCCH repeats scheduled to be consecutive and overlapping one or more time slot boundaries.

12. The method of claim 1, wherein the PUCCH repeat is one of a plurality of PUCCH repeats scheduled in consecutive time slots and not overlapping with any time slot boundaries.

13. The method of claim 12, wherein the plurality of PUCCHs are repeated in each of the consecutive time slots using the same time domain allocation.

14. The method of claim 1, wherein the original PUCCH transmission includes a downlink DL symbol.

15. The method of claim 14, wherein the PUCCH repeat is a truncated version of the original PUCCH emission, the truncated version excluding any symbols of the original PUCCH emission following the DL symbol.

16. The method of claim 14, wherein the PUCCH repeat is a segmented version of the original PUCCH, the segmented version being formed by a first repeating PUCCH segment and a second repeating PUCCH segment, the first repeating PUCCH segment including all symbols emitted by the original PUCCH preceding the DL symbol, and the second repeating PUCCH segment including all symbols emitted by the original PUCCH following the DL symbol.

17. The method according to claim 1, further comprising: The report states that user equipment is configured to repeat PUCCHs a maximum number of times within a time slot.

18. A non-transitory computer-readable storage medium, the computer-readable storage medium comprising instructions that, when executed by a processor, cause the processor to: The original physical uplink control channel (PUCCH) transmission overlaps with the time slot boundary, which is the boundary between the first time slot used for PUCCH transmission and the second time slot used for PUCCH transmission. Configure PUCCH repetition for the original PUCCH transmission, wherein the PUCCH repetition includes one or more symbols of the original PUCCH transmission and is located in one or more time slots other than the first time slot and the second time slot, and wherein the PUCCH repetition is configured by downlink control information (DCI) configuration, the DCI configuration including a physical downlink shared channel to hybrid automatic repeat request acknowledgment feedback timing indicator, i.e., a PDSCH to HARQ_feedback timing indicator, and a PUCCH repetition count field configuring the number of transmissions for the PUCCH repetition or a PUCCH resource indicator field configuring the number of transmissions for the PUCCH repetition, wherein the PUCCH repetition count field or the PUCCH resource indicator field includes a value indicating the number of transmissions for the PUCCH repetition; and The PUCCH is emitted repeatedly.

19. The non-transitory computer-readable storage medium of claim 18, wherein the PUCCH repeat is a truncated version of the original PUCCH transmission, the truncated version excluding any symbols of the original PUCCH transmission that overlap with the slot boundary.

20. A computing device for determining repetition of Physical Uplink Control Channel (PUCCH) transmissions, the computing device comprising: processor; as well as The memory stores instructions that, when executed by the processor, configure the device to: The original PUCCH transmission is determined to overlap with a time slot boundary, which is the boundary between a first time slot used for PUCCH transmission and a second time slot used for PUCCH transmission. Configure PUCCH repetition for the original PUCCH transmission, wherein the PUCCH repetition includes one or more symbols of the original PUCCH transmission and is located in one or more time slots other than the first time slot and the second time slot, and wherein the PUCCH repetition is configured by downlink control information (DCI) configuration, the DCI configuration including a physical downlink shared channel to hybrid automatic repeat request acknowledgment feedback timing indicator, i.e., a PDSCH to HARQ_feedback timing indicator, and a PUCCH repetition count field configuring the number of transmissions for the PUCCH repetition or a PUCCH resource indicator field configuring the number of transmissions for the PUCCH repetition, wherein the PUCCH repetition count field or the PUCCH resource indicator field includes a value indicating the number of transmissions for the PUCCH repetition; and The PUCCH is emitted repeatedly.

21. The computing device of claim 20, wherein the PUCCH repeat is a truncated version of the original PUCCH transmission, the truncated version excluding any symbols of the original PUCCH transmission that overlap with the slot boundary.

22. An apparatus for determining repetition of Physical Uplink Control Channel (PUCCH) transmissions, comprising: A means for performing the operations included in the method according to any one of claims 1-17.

Images