CN115804056A - Physical downlink control channel repetition configuration and physical downlink shared channel start configuration and processing time indication - Google Patents

Abstract

Apparatus, systems, methods, and machine-readable media of a User Equipment (UE). The apparatus includes one or more processors configured to: decoding a message from an NR node B (gNB) indicating a repetition count for a Physical Downlink Control Channel (PDCCH) carrying Downlink Control Information (DCI); and determining a repetition count from the message.

Description

Physical downlink control channel repetition configuration and physical downlink shared channel start configuration and processing time indication

Cross Reference to Related Applications

The present application claims the benefits and priority of U.S. provisional patent application No.63/063,089 entitled "PDCCH repetition configuration" and filed on 8/7/2021 and U.S. provisional patent application No.63/062,877 entitled "PDSCH starting configuration and processing time indication" and filed on 8/7/2020. The disclosure of the prior application is considered part of the disclosure of the present application and is hereby incorporated by reference into the disclosure of the present application.

Background

Various embodiments may relate generally to the field of wireless communications, and more specifically to the field of communications in cellular networks that conform to one of the more third generation partnership project (3 GPP) specifications.

Drawings

In the drawings, which are not necessarily drawn to scale, like numerals may describe similar components in different views. Like numerals having different letter suffixes may represent different instances of similar components. The drawings illustrate generally, by way of example, but not by way of limitation, various embodiments discussed in the present document.

Fig. 1 illustrates an inter-CORESET approach for PDCCH repetition and soft combining, where different CORESETs are associated with different TCI states.

Fig. 2 illustrates the inter-CORESET method for repetition or soft combining.

Fig. 3 illustrates CCE aggregation performed as part of soft combining, where overlapping search spaces are involved.

Fig. 4 illustrates an intra-CORESET method for PDCCH repetition across monitoring occasions.

Fig. 5 illustrates an intra-core method for SS set based PDCCH, wherein different SS sets of the same core set are associated with different TCI states.

Fig. 6 shows a set of slots illustrating various possibilities for transmitting DCI via one or two PDCCHs.

Fig. 7 shows cross-slot repetition of DCI.

Fig. 8 shows an example of PDSCH processing time ambiguity due to PDCCH repetition.

Fig. 9 illustrates a wireless network in accordance with various embodiments.

Fig. 10 illustrates a User Equipment (UE) and a Radio Access Node (RAN) in wireless communication, in accordance with various embodiments.

Fig. 11 illustrates components capable of reading instructions from a machine-readable or computer-readable medium and performing any one or more of the methodologies discussed herein, according to some example embodiments.

Fig. 12 shows a flow chart for a process according to the first embodiment.

Fig. 13 shows a flow chart for a process according to the second embodiment.

Detailed Description

The following detailed description refers to the accompanying drawings. The same reference numbers may be used in different drawings to identify the same or similar elements. In the following description, for purposes of explanation and not limitation, specific details are set forth such as particular structures, architectures, interfaces, techniques, etc. in order to provide a thorough understanding of the various aspects of the various embodiments. However, it will be apparent to those skilled in the art having the benefit of the present disclosure that the various aspects of the embodiments may be practiced in other examples that depart from these specific details. In certain instances, descriptions of well-known devices, circuits, and methods are omitted so as not to obscure the description of the various embodiments with unnecessary detail. For the purposes of this document, the phrases "a or B" and "a/B" mean (a), (B), or (a and B).

I. Physical downlink control channel repetition configuration

PDCCH reliability scheme

Some embodiments relate to an enhanced 5G new air interface (NR) Rel-17 Multiple Input Multiple Output (MIMO) enhanced Work Item (WI) for physical Downlink (DL) control channel (PDCCH). Some embodiments relate to mechanisms for PDCCH repetition and for mapping Transmission Configuration Indicator (TCI) status to PDCCH.

PDCCH repetitions from different Transmit Receive Points (TRPs) (different TCI states) may be configured based on a control resource set (CORESET), a Synchronization Signal (SS) set, or a monitoring occasion.

Built on the signaling framework present in Rel-15 and Rel-16, some embodiments herein allow the network to allocate PDCCH repetitions from different TRPs (different TCI states).

A selection diversity scheme is where a User Equipment (UE) may receive multiple copies of the same Downlink Control Information (DCI). The Network (NW) essentially transmits the same DCI multiple times using the Rel-15/16 principle, and each repetition may have a different Aggregation Level (AL). There is no expectation that the UE should try soft combining of different repetitions, and this is not taken into account in the Blind Decoding (BD) constraints. On the UE side, selection diversity may be implemented, where each BD candidate is treated in the same way as Rel-15.

The soft combining scheme is a case where the UE is expected to attempt soft combining of 2 PDCCH candidates and soft combining attempts are considered in the BD constraint. On the UE side, soft combining may imply additional storage and combining of PDCCH candidates and additional decoding attempts.

Furthermore, soft combining schemes can be classified as joint coding (similar to scheme 2a mentioned below) or repetition (similar to scheme 2b mentioned below, but including chase combining). Note that joint coding will naturally be limited to AL level 16 (AL 16) performance. No significant difference between the two schemes is expected in terms of performance.

High level PDCCH reliability schemes may be classified as-1) selection diversity; 2a) Soft combining with joint coding; 2b) With repeated soft combining.

BD/Control Channel Element (CCE) allocation for PDCCH reliability schemes

As described in the previous section, three different 2-TRP PDCCH schemes-System Frame Number (SFN), selective diversity, and soft combining-can be considered. SFN is considered specification transparent because the BD/CCEs in SFN are assigned the same as Rel-15. Note that the NW may (dynamically) choose to transmit only from TRP-1, only from TRP-2, or both TRP-1 and TRP-2, but TRP transmission is transparent to the UE.

For selection diversity or soft combining schemes, CCE provisioning may be considered to be generally additive between TRP-1 and TRP-2, as channel estimates cannot be reused across TRPs. At the same time, we envision that the channel estimates can be reused completely within the same TRP/CORESET across SS sets and AL based on the Rel-15 rule. In terms of BD provisioning, we can assume the same guiding principle: the NW may (dynamically) select to transmit only from TRP-1, only from TRP-2, or from both TRP-1 and TRP-2. As an example, TRP-1 may choose to transmit AL16 PDCCH without repetition or with two repetitions using AL8+ AL8 from TRP-1+ TRP-2, respectively, in order to transmit a specific ultra-reliable low latency communication (URLLC) packet. Based on the above principles, it is envisaged that, similar to CCE allocation, BD allocation for selection diversity schemes is generally additive between TRP-1 and TRP-2, and only certain selected candidates and certain selected ALs may be allocated for repetition in order to save the total BD/CCE consumption in the slot.

The BD allocation for the soft combining scheme may vary based on the exact scheme used. In general, guidelines may be followed in which the NW is able to (dynamically) select from TRP-1 or TRP-2 transmissions, and thus, BD allocations may be formulated as follows according to some embodiments:

-BD (candidate from TRP-1) + BD (candidate from TRP-2) + BD (soft merge candidate from TRP-1, 2); or

BD (candidate from TRP-1) + BD (soft combining candidate from TRP-1, 2) -in this case TRP-2 can send PDCCH only when TRP-1 is also sending.

According to one proposal, the PDCCH repetition scheme allows the NW to (dynamically) choose to send DCI only from TRP-1 or only from TRP-2 without repetition, or to send DCI from both TRP-1 and TRP-2 in case of repetition.

According to a related proposal, the following BD/CCE allocation principles may be considered for repetition:

CCE assignment may involve CCE (TRP-1) + CCE (TRP-2);

BD allocations for selection diversity may involve BD (candidate from TRP-1) + BD (candidate from TRP-2);

BD allocation for soft combining may involve BD (candidate from TRP-1) + BD (candidate from TRP-2) + BD (soft candidate from TRP-1, TRP-2)

Given that BD/CCE capacity is limited at the UE, some flexibility may be desired in partitioning BD/CCEs across TRPs. As an example, the BD/CCE partitioning may be 80-20 between TRP-1 and TRP-2, where TRP-1 assumes the role of the primary TRP for URLLC transmissions. In other words, the BD/CCE count should not simply be doubled, but should be able to flexibly adjust to different deployment requirements.

Thus, according to one related proposal, flexible BD/CCE partitioning (for repetition) across TRPs should be allowed in cases where TRP-1 and TRP-2 may not consume equal BD/CCE capacity (which is limited at the UE).

Making modifications in the context of maximum reliability targets may also be helpful in determining whether AL16 type reliability is sufficient, whether different AL levels may be required, and whether repetition may be spread out both within and across slots, for example. For example, a) AL8 (TRP-1) + AL8 (TRP-2), or b) AL16 (TRP-1) + AL16 (TRP-2), or c) includes higher repetitions of coverage (PDCCH repetition within or across slots).

Example I-1-CORESET Interval Process

Referring now to fig. 1, fig. 1 illustrates an inter-CORESET method for PDCCH repetition and soft combining, where different CORESETs are associated with different TCI states. Specifically, FIG. 1 shows a set (100) of two CORESETs 102 and 104 corresponding to CORESET-1 and CORESET-2, respectively. In the illustrated embodiment, CORESET-1 corresponds to TRP1 and SS 1, and CORESET-2 corresponds to TRP2 and SS 2. Each CORESET includes 8 PDCCH candidates at AL2 and 8 PDCCH candidates at AL 4.

At a high level, in the method of fig. 1, each CORESET is associated with a different TRP (TCI state). As an example, CORESET-1, SS set-1 and TCI-StateId-1 are from TRP-1, while CORESET-2, SS set-2 and TCI-StateId-2 are from TRP-2. For soft combining, a given value of candidate m for SS-1/AL4 may be combined with the same value of candidate m for SS-2/AL 4. The arrows between candidates m in fig. 1 show examples of possible combinations according to the above-described regime.

The method illustrated in fig. 1 may naturally provide full flexibility in partitioning BD/CCE between TRP-1 and TRP-2 with the current signaling framework. Unequal resource partitioning within candidates (e.g., where candidates from different TCI states and different ALs are to be soft-combined) would require changes to the CCE hashing function to allow CCE aggregation beyond 2, 4, 8, 16 (e.g., AL2+ AL6 soft-combining to AL 8).

Referring now to fig. 2, fig. 2 also relates to an inter-CORESET method for repetition or soft combining. In fig. 2, a set of (200) CORESET comprising CORESET-1 202 and CORESET-2 204 is shown, each CORESET comprising 4 PDCCH candidates at AL 4. As shown in fig. 2, the candidates from CORESET-1 and CORESET-2 may be subjected to soft combining by repetition 206 or by joint coding to produce a soft combined CORESET 208 with the candidates at AL 8.

As shown, for example, in fig. 3, a set of CORESET 300 includes CORESET-1 302 and CORESET-2 304, and CCE aggregation may be performed as part of soft combining, where overlapping search spaces are involved. In fig. 3, candidates having the same m value and corresponding to the same AL level (in this case, AL 2) may be merged. According to the embodiment of fig. 3, a new UE-specific search space may be defined that includes CCE/BD candidates monitored by the UE from two or more CORESET, e.g., for AL =2 · L CCEs, where CORESET is Time Division Multiplexed (TDM) by presenting candidate offsets relative to each other in the time domain, as shown in fig. 3, to allow time for beam switching in frequency range 2 (FR 2).

For selection diversity, no restriction on the search space or CORESET overlap is necessary. For soft combining, it is good if the search spaces are non-overlapping (which may be typical). It can be assumed that the search spaces are overlapping, but the BD candidates for soft combining are non-overlapping (the hash function start position is CORESET dependent-an offset may be possible).

Example I-2-CORESET in-line Process

Example I-2 a-repeated within CORESET method with Cross-monitoring opportunities

Referring now to fig. 4, fig. 4 illustrates an intra-CORESET method for PDCCH repetition across monitoring occasions, where CORESET 400 includes monitoring occasions (Mo) Mo-1 and Mo-2 associated with different TCI states (TCI-1 and TCI-2, respectively).

At a high level, for the embodiment of fig. 4, each Monitoring Occasion (MO) may be associated with a different TRP (TCI-State), while both monitoring occasions may be associated with the same SS set/CORESET, as shown. In this case, the flexibility of allocating BD/CCE candidates across two TPRs is naturally limited by the current signaling framework. However, the embodiment of fig. 4 consumes less UE resources in terms of CORESET and SS set.

Example I-2 b-CORESET IN-PROCESS WITH REPEATION OVER SS SET

Referring now to fig. 5, fig. 5 illustrates an intra-core method for SS set based PDCCH, wherein different SS sets of the same core set are associated with different TCI states. Specifically, FIG. 5 shows a set (500) of two SS sets 502 and 504 corresponding to SS-1 and SS-2, respectively. In the illustrated embodiment, SS-1 corresponds to TRP1 and SS-2 corresponds to TRP2. Each SS set includes 8 PDCCH candidates at AL2 and 8 PDCCH candidates at AL 4. Thus, SS-1 and SS-2 have the same number of CCEs corresponding to the candidates.

According to the embodiment of fig. 5, selection diversity may be supported, but limited to the same CORESET (compared to the case between CORESETs where no such limitation exists). In addition, soft combining may be supported if SS-1 and SS-2 are non-overlapping. Hence, physically overlapping BD candidates (as indicated by the double-headed arrows in fig. 5), otherwise pairs of BD candidates with the same AL would overlap in terms of physical resources, and these BD candidates would not be available for PDCCH scheduling (especially for larger ALs).

Based on the above, some embodiments propose any of the following frameworks for PDDCH repeat studies:

an inter-CORESET method, wherein TRP-1 is associated with CORESET-1 and TRP-2 is associated with CORESET-2. This allows a full flexibility in partitioning BD/CCEs between TRP-1 and TRP-2; and/or

CORESET method, in which TRP-1 is associated with monitoring occasions 1 and T

TRP-2 associated with monitoring opportunity-2 (possibly for the same set of SSs and the same CORESET). This approach provides limited flexibility in dividing BD/CCE between TRP-1 and TRP-2, but consumes less UE resources in terms of CORESET and SS sets.

Some embodiments herein include support for one or more of the following PDCCH candidate repetition types:

-intercoreset for repetition across TRP;

-within CORESET with repeats across the SS set;

-within CORESET with repeats across MO;

-a UE configured to expect DCI repetition from any combination of the above; or

-a UE to which one or more of the following are indicated: SS set, MO, slot, DCI or BD candidates for repetition

According to some embodiments, one or more of the following may be true: MOs are implicit (same MO), slots are implicit (same slot), DCI is implicit (common DCI across SS set only), AL is implicit (common AL only), or BD candidates are implicit (common BD candidates only).

For soft combining, BD candidate m of SS-1/AL4 may be combined with BD candidate m of SS-2/AL4 to produce a repetition of the jointly encoded AL8 (ordered by TRP-0 then TRP-1) or AL 4.

For soft combining, BD candidate m of SS-1/AL4 may be combined with all BD candidates of SS-2/AL4 to produce a repetition of the jointly encoded AL8 (ordered by TRP-0 then TRP-1) or AL 4.

PDSCH Start configuration and processing time indication

Some embodiments relate to the 5G NR Release 17MIMO enhancement work item on enhancement of PDCCH. Some embodiments include a method for determining PDSCH starting and PDSCH processing times due to PDCCH repetitions.

PDSCH starting time ambiguity and PDSCH processing time ambiguity can be addressed by embodiments of the way in which the number of repetitions is indicated by using DCI.

Built on the signaling framework present in Rel-15 and Rel-16, some embodiments herein enable the network to allocate PDCCH repetitions from different TRPs (e.g., different TCI states).

Referring now to fig. 6, fig. 6 shows a set of time slots 602, 604, and 606 corresponding to cases 1, 2, and 3, respectively, as will be explained in further detail below. In particular, rel-16URLLC has introduced a (RRC-configurable) PDSCH start reference to scheduling PDCCH start symbol changes. In the latter context, the different network operations that can be envisaged correspond to cases 1, 2 and 3, as follows:

a. case 1. The network transmits DCI only in PDCCH-1 (AL 16), where the PDSCH starting reference should obviously be PDCCH-1;

b. case 2. The network transmits DCI only in PDCCH-2 (AL 16), where the PDSCH reference should obviously be PDCCH-2; and

c. case 3. The network sends DCI in PDCCH-1 and PDCCH-2 (AL 8 for each). Here, the UE may decode DCI from PDCCH-1 or PDCCH-2, in which case PDSCH starting reference would be ambiguous.

Rel-15 Start and Length Indicator Value (SLIV) references are slot boundaries. Thus, if duplicate DCI is received in PDCCH-1 and PDCCH-2, there is no ambiguity in the PDSCH starting reference. However, rel-16 introduces ambiguity in the PDSCH start time for repeated DCI, since Rel-16URLLC has introduced a (RRC-configurable) PDSCH start reference corresponding to the scheduling PDCCH start symbol, as explained in the context of fig. 6.

To address ambiguity, according to an embodiment, the DCI field may include a "duplicate" field that is set to 1 for cases 1 and 2 and set to 2 for case 3. In this case, the same principle can be used to associate the PDSCH (even in the case of the Rel-15 SLIV reference described above) with a unique monitoring occasion for PDSCH.

According to some embodiments, when configured with a SLIV reference as a starting symbol for a PDSCH monitoring occasion, the UE expects not to receive multiple repetitions of DCI 1_2 (or multiple repetitions with different starting symbols for the monitoring occasion). However, the UE may be provided with an indication of some combination of repeated SS sets, MOs within a slot, MOs across slots, and/or candidates within each AL that can potentially be used for DCI 1 _2that is to be repeated. Examples of indications for possible 2 PDCCH repetitions of DCI may include the following combinations:

combination-1:

is a repeat pair for a 2TRP repeat; and

combination-2:

is a repeat pair for a 1TRP repeat;

according to some embodiments, the UE may use a fixed rule based on the indication to determine a monitoring occasion for the PDSCH; for example, the fixed rule for the UE may include the latest monitoring occasion in a slot within the indicated combination. Combinations may be selected based on BD.

According to some embodiments, for example, in the repetition field, the DCI may indicate whether DCI repetition is used and, if so, which type of repetition is used, where the value:

0 indicates no repetition → SLIV reference is to be used according to the decoded DCI;

1 indicates repetition → to use SLIV references according to fixed rules based on the indicated combination corresponding to DCI repetition. For example, a fixed rule may specify that the latest MO within combination-1 is used to monitor PDSCH; and

2 indicates repetition → to use SLIV references according to fixed rules based on the indicated combination corresponding to DCI repetition. For example, a fixed rule may specify that the latest MO within combination-2 is used to monitor PDSCH;

one embodiment may include: the principles outlined above are used to associate the PDSCH (even with the Rel-15 SLIV reference) with a unique monitoring occasion for HARQ-ACK bit positions in the dynamic codebook.

One embodiment may include: the principles outlined above are used to solve the processing time problem as set forth in fig. 7 and 8.

In particular, fig. 7 shows a set (700) of two consecutive slots 702 and 704 with a crossing slot repetition of DCI. For example, there may be: 4 repetitions of DCI, two in each slot; or 3 repetitions of DCI, where one in slot 702 and two in slot 704; or any other configuration for repetition. If there is no overlap between any repeated DCI and the associated PDSCH monitoring occasion, there is no delay, as shown in the example of fig. 7.

Fig. 8 shows an example of PDSCH processing time ambiguity due to PDCCH repetition. Referring now to fig. 8, DCI/PDCCH repetitions may result in overlapping symbols for DCI repetitions and PDSCH monitoring occasions, e.g., in the case of cross-slot repetitions, as shown in the context of fig. 7. Specifically, fig. 8 shows a slot 800 including repeated DCI in PDCCH-1 and PDCCH-2, where the symbols of PDCCH-2 overlap with the symbols of PDSCH. In this case, the processing time of the PDSCH is delayed by the overlapping symbol (in the illustrated case, it is the duration of PDCCH-2). In the case of fig. 8, if the PDSCH is scheduled by PDCCH-1, the processing time will not be delayed.

According to one embodiment, the network operates in any of the following ways:

sending PDCCH-1 with AL16 without repetition;

sending PDCCH-1 and PDCCH-2, both with AL 8.

In both cases, the UE may be able to decode DCI from PDCCH-1. However, if the second option is used, this difference in NW operation may be indicated to the UE so as not to delay PDSCH processing time until the end of PDCCH-2. The solution proposal according to one embodiment includes the "repeat" fields as follows:

for PDCCH-1 with AL16 without repetition, repetition field =1; and

for PDCCH-1 and PDCCH-2 with AL8 each for soft combining, the field =2 is repeated.

System and implementation

Fig. 9-11 illustrate various systems, devices, and components that may implement aspects of the disclosed embodiments.

Fig. 9 illustrates a network 900 in accordance with various embodiments. The network 800 may operate in a manner consistent with 3GPP technical specifications for LTE or 5G/NR systems. However, the example embodiments are not so limited, and the described embodiments may be applied to other networks (e.g., future 3GPP systems, etc.) that benefit from the principles described herein.

Network 900 may include UEs 902, and UEs 902 may include any mobile or non-mobile computing device designed to communicate with RAN904 via an over-the-air connection. The UE902 may be communicatively coupled with the RAN904 over a Uu interface. The UE902 may include, but is not limited to, a smart phone, a tablet computer, a wearable computer device, a desktop computer, a laptop computer, in-vehicle infotainment, an in-vehicle entertainment device, a dashboard, a head-mounted display device, an on-board diagnostic device, a dashboard mobile device, a mobile data terminal, an electronic engine management system, an electronic/engine control unit, an electronic/engine control module, an embedded system, a sensor, a microcontroller, a control module, an engine management system, a networking appliance, a machine type communication device, an M2M or D2D device, an IoT device, and so forth.

In some embodiments, network 900 may include multiple UEs directly coupled to each other via a sidelink interface. The UE may be an M2M/D2D device that communicates using a physical sidelink channel (e.g., without limitation, PSBCH, PSDCH, PSSCH, PSCCH, PSFCH, etc.).

In some embodiments, the UE902 may additionally communicate with the AP 906 via an over-the-air connection. The AP 906 may manage WLAN connections, which mayFor offloading some/all of the network traffic from RAN 904. The connection between the UE902 and the AP 906 may conform to any IEEE 902.11 protocol, where the AP 906 may be wireless fidelity (wifi)

A router. In some embodiments, UE902, RAN904, and AP 906 may utilize cellular-WLAN aggregation (e.g., LWA/LWIP). cellular-WLAN aggregation may involve: the UE902 is configured by the RAN904 to utilize both cellular radio resources and WLAN resources.

RAN904 may include one or more access nodes (e.g., AN 908). The AN 908 may terminate air interface protocols for the UE902 by providing access stratum protocols including RRC, PDCP, RLC, MAC, and L1 protocols. In this manner, the AN 908 may enable data/voice connectivity between the CN920 and the UE 902. In some embodiments, the AN 908 may be implemented in a discrete device or as one or more software entities running on a server computer as part of, for example, a virtual network (which may be referred to as a CRAN or a pool of virtual baseband units). AN 908 may be referred to as BS, gNB, RAN node, eNB, ng-eNB, nodeB, RSU, TRxP, TRP, etc. The AN 908 can be a macrocell base station or a low power base station that provides a femtocell, picocell, or other similar cell with smaller coverage area, smaller user capacity, or higher bandwidth than a macrocell.

In embodiments where the RAN904 comprises multiple ANs, they may be coupled to each other via AN X2 interface (if the RAN904 is AN LTE RAN) or AN Xn interface (if the RAN904 is a 5G RAN). The X2/Xn interfaces (which may be separated into control/user plane interfaces in some embodiments) may allow the AN to communicate information related to handover, data/context transfer, mobility, load management, interference coordination, etc.

The ANs of RAN904 may each manage one or more cells, groups of cells, component carriers, etc., to provide UE902 with AN air interface for network access. The UE902 can simultaneously connect with multiple cells provided by the same or different ANs of the RAN 904. For example, the UE902 and RAN904 may use carrier aggregation to allow the UE902 to connect with multiple component carriers (each corresponding to a Pcell or Scell). In a dual connectivity scheme, the first AN may be a primary node providing AN MCG and the second AN may be a secondary node providing AN SCG. The first/second AN may be any combination of eNB, gNB, ng-eNB, etc.

RAN904 may provide an air interface over a licensed spectrum or an unlicensed spectrum. To operate in unlicensed spectrum, the node may use LAA, eLAA and/or feLAA mechanisms based on CA technology with PCells/Scell. Prior to accessing the unlicensed spectrum, the node may perform a medium/carrier sensing operation based on, for example, a listen-before-talk (LBT) protocol.

In a V2X scenario, the UE902 or AN 908 may be or may act as AN RSU, which may refer to any traffic infrastructure entity for V2X communications. The RSU may be implemented in or by a suitable AN or stationary (or relatively stationary) UE. An RSU implemented in or by: for a UE, it may be referred to as "UE type RSU"; for an eNB, it may be referred to as "eNB-type RSU"; for gNB, it may be referred to as "gNB type RSU"; and the like. In one example, the RSU is a computing device coupled with radio frequency circuitry located at the curb side that provides connection support to passing vehicle UEs. The RSU may also include internal data storage circuitry for storing intersection map geometry, traffic statistics, media, and applications/software to sense and control ongoing vehicle and pedestrian traffic. The RSU may provide extremely low latency communications required for high speed events (e.g., collision avoidance, traffic warnings, etc.). Additionally or alternatively, the RSU may provide other cellular/WLAN communication services. The components of the RSU may be enclosed in a weatherproof enclosure suitable for outdoor installation and may include a network interface controller for providing a wired connection (e.g., ethernet) to a traffic signal controller or a backhaul network.

In some embodiments, RAN904 may be an LTE RAN 910 with an eNB (e.g., eNB 912). The LTE RAN 910 may provide an LTE air interface with the following characteristics: SCS at 15 kHz; a CP-OFDM waveform for DL and an SC-FDMA waveform for UL; a turbo code for data and a TBCC code for control; and the like. The LTE air interface may rely on: a CSI-RS for CSI acquisition and beam management; PDSCH/PDCCH DMRS for PDSCH/PDCCH demodulation; and CRS for cell search and initial acquisition, channel quality measurement, and channel estimation with respect to coherent demodulation/detection at the UE. The LTE air interface may operate over the sub-6GHz band.

In some embodiments, RAN904 may be NG-RAN914 with a gNB (e.g., gNB 916) or NG-enodebs (e.g., NG-eNB 918). The gNB 916 may connect with the 5G-enabled UE using a 5G NR interface. The gNB 916 may be connected to the 5G core through an NG interface, which may include an N2 interface or an N3 interface. The NG-eNB 918 may also be connected with the 5G core over the NG interface, but may be connected with the UE via the LTE air interface. The gNB 916 and ng-eNB 918 may connect with each other through an Xn interface.

In some embodiments, the NG interface may be divided into two parts: a NG user plane (NG-U) interface that carries traffic data between nodes of the NG-RAN914 and the UPF 948 (e.g., an N3 interface); and a NG control plane (NG-C) interface, which is a signaling interface (e.g., N2 interface) between a node of the NG-RAN914 and the AMF 944.

The NG-RAN914 may provide a 5G-NR air interface with the following characteristics: variable SCS; CP-OFDM for DL, CP-OFDM for UL, and DFT-s-OFDM; a polarization code for control, a repetition code, a simplex code, and a Reed-Muller code, and LDPC for data. Similar to the LTE air interface, the 5G-NR air interface may rely on CSI-RS, PDSCH/PDCCH DMRS. The 5G-NR air interface may not use CRS, but may use: PBCH DMRS for PBCH demodulation; PTRS for phase tracking of PDSCH; and tracking the reference signal for time tracking. The 5G-NR air interface may operate over the FR1 frequency band, which includes the sub-6GHz frequency band, or the FR2 frequency band, which includes frequency bands from 24.25GHz to 52.6 GHz. The 5G-NR air interface may include SSBs, which are regions of a downlink resource grid including PSS/SSS/PBCH.

In some embodiments, the 5G-NR air interface may utilize BWP for various purposes. For example, BWP may be used for dynamic adaptation of SCS. For example, the UE902 may be configured with multiple BWPs, with each BWP configuration having a different SCS. When the change of BWP is indicated to the UE902, the transmitted SCS is also changed. Another example use case for BWP relates to power saving. In particular, the UE902 may be configured with multiple BWPs with different amounts of frequency resources (e.g., PRBs) to support data transmission in different traffic load scenarios. BWPs containing a smaller number of PRBs may be used for data transmission with small traffic load while allowing power saving at the UE902 and in some cases at the gNB 916. BWPs containing a larger number of PRBs may be used in scenarios with higher traffic load.

RAN904 is communicatively coupled with CN920, which comprises a network element, to provide various functions to support data and telecommunications services for customers/subscribers (e.g., users of UE 902). The components of CN920 may be implemented in one physical node or in separate physical nodes. In some embodiments, NFV may be utilized to virtualize any or all functions provided by network elements of CN920 onto physical computing/storage resources in servers, switches, and the like. The logical instantiation of a CN920 may be referred to as a network slice, while the logical instantiation of a portion of a CN920 may be referred to as a network subslice.

In some embodiments, the CN920 may be an LTE CN 922, which may also be referred to as an EPC. The LTE CN 922 may include an MME924, an SGW 926, an SGSN 928, an HSS 930, a PGW 932, and a PCRF 934, which are coupled with one another by interfaces (or "reference points"), as shown. The functions of the elements of LTE CN 922 may be briefly introduced as follows.

The MME924 may implement mobility management functions to track the current location of the UE902 to facilitate paging, bearer activation/deactivation, handover, gateway selection, authentication, etc.

The SGW 926 may terminate the S1 interface towards the RAN and route data packets between the RAN and the LTE CN 922. SGW 926 may be a local mobility anchor for inter-RAN node handovers and may also provide an anchor for inter-3 GPP mobility. Other responsibilities may include lawful interception, charging, and some policy enforcement.

The SGSN 928 may track the location of the UE902 and perform security functions and access control. Further, the SGSN 928 may perform EPC inter-node signaling for mobility between different RAT networks; PDN and S-GW selection specified by MME 924; MME selection for handover; and so on. An S3 reference point between MME924 and SGSN 928 may enable user and bearer information exchange for inter-3 GPP network access mobility in idle/active state.

HSS 930 may include a database for network users (which includes subscription-related information) to support the handling of communication sessions by network entities. HSS 930 may provide support for routing/roaming, authentication, authorization, naming/addressing resolution, location dependencies, etc. An S6a reference point between the HSS 930 and the MME924 may enable the transfer of subscription and authentication data for authenticating/authorizing user access to the LTE CN 920.

The PGW 932 may terminate the SGi interface towards a Data Network (DN) 936, which may include an application/content server 938. The PGW 932 may route data packets between the LTE CN 922 and the data network 936. The PGW 932 may be coupled with the SGW 926 through an S5 reference point to facilitate user plane tunneling and tunnel management. PGW 932 may also include nodes (e.g., PCEFs) for policy enforcement and charging data collection. Further, the SGi reference point between the PGW 932 and the data network 936 may be an operator external public, private PDN, or an operator internal packet data network (e.g., for provisioning IMS services). PGW 932 may be coupled with PCRF 934 via a Gx reference point.

PCRF 934 is the policy and charging control element of LTE CN 922. The PCRF 934 may be communicatively coupled to the application/content server 938 to determine appropriate QoS and charging parameters for the service flow. The PCRF 932 may provision the association rules (via the Gx reference point) into the PCEF with the appropriate TFTs and QCIs.

In some embodiments, CN920 may be 5GC 940.5GC 940 may include AUSF 942, AMF944, SMF 946, UPF 948, NSSF 950, NEF952, NRF954, PCF 956, UDM 958, and AF 960, coupled to each other by interfaces (or "reference points"), as shown. The function of the elements of the 5GC 940 can be briefly described as follows.

The AUSF 942 may store data for authentication of the UE902 and handle authentication related functions. AUSF 942 may facilitate a generic authentication framework for various access types. AUSF 942 may exhibit a Nausf service based interface in addition to the illustrated communication with other elements of the 5GC 940 via reference points.

The AMF944 may allow other functions of the 5GC 940 to communicate with the UE902 and the RAN904 and subscribe to notifications of mobility events for the UE 902. The AMF944 may be responsible for registration management (e.g., for registering the UE 902), connection management, reachability management, lawful interception of mobility management and AMF related events, and access authentication and authorization. AMF944 may provide transport for SM messages between UE902 and SMF 946 and acts as a transparent proxy for routing SM messages. The AMF944 may also provide for transmission of SMS messages between the UE902 and the SMSF. The AMF944 may interact with the AUSF 942 and the UE902 to perform various security anchoring and context management functions. Further, the AMF944 may be a termination point for a RAN CP interface that may include or be an N2 reference point between the RAN904 and the AMF 944; and the AMF944 may be the termination point of NAS (N1) signaling and perform NAS ciphering and integrity protection. The AMF944 may also support NAS signaling with the UE902 over the N3 IWF interface.

SMF 946 may be responsible for SM (e.g., session establishment between UPF 948 and AN 908, tunnel management); UE IP address assignment and management (including optional authorization); selection and control of the UP function; configuring traffic steering at the UPF 948 to route traffic to the correct destination; terminating the interface towards a policy control function; controlling a portion of policy enforcement, charging, and QoS; lawful interception (for SM events and interface to the LI system); terminate the SM portion of the NAS message; a downlink data notification; initiate AN-specific SM message sent on N2 to AN 908 via AMF 944; and determining the SSC pattern for the session. SM may refer to the management of PDU sessions, while a PDU session or "session" may refer to a PDU connection service that provides or enables an exchange of PDUs between the UE902 and the data network 936.

The UPF 948 may serve as an anchor point for intra-RAT and inter-RAT mobility, an interconnected external PDU session point to the data network 936, and a branch point for supporting multi-homed PDU sessions. The UPF 948 may also perform packet routing and forwarding, perform packet inspection, enforce the user plane part of policy rules, lawful intercept packets (UP collection), perform traffic usage reporting, perform QoS processing for the user plane (e.g., packet filtering, gating, UL/DL rate enforcement), perform uplink traffic verification (e.g., SDF to QoS flow mapping), transport level packet marking in uplink and downlink, and perform downlink packet buffering and downlink data notification triggering. The UPF 948 may include an uplink classifier to support routing of traffic flows to a data network.

The NSSF 950 may select a set of network slice instances that serve the UE 902. NSSF 950 may also determine allowed NSSAIs and mappings to subscribed S-NSSAIs, if desired. The NSSF 950 may also determine the set of AMFs or list of candidate AMFs to be used to serve the UE902 based on a suitable configuration and possibly by querying the NRF 954. The selection of a set of network slice instances for the UE902 may be triggered by the AMF944 with which the UE902 registers by interacting with the NSSF 950, which may result in a change in the AMF. NSSF 950 may interact with AMF944 via an N22 reference point; and may communicate with another NSSF in the visited network via an N31 reference point (not shown). Further, NSSF 950 may expose an interface based on the NSSF service.

NEF952 may securely open services and capabilities provided by 3GPP network functions for third parties, internal opening/reopening, AF (e.g., AF 960), edge computing or fog computing systems, etc. In these embodiments, NEF952 may authenticate, authorize or restrict AF. NEF952 may also translate information exchanged with AF 960 and information exchanged with internal network functions. For example, the NEF952 may convert between an AF service identifier and internal 5GC information. NEF952 may also receive information from other NFs based on the capabilities of the other NFs that are open. This information may be stored as structured data at NEF952 or at data store NF using a standardized interface. The stored information may then be re-opened by NEF952 to other NFs and AFs, or used for other purposes (e.g., analysis). Further, NEF952 may expose an interface based on the Nnef service.

NRF954 may support a service discovery function, receive NF discovery requests from NF instances, and provide information of discovered NF instances to NF instances. NRF954 also maintains information of available NF instances and the services it supports. As used herein, the terms "instantiation", and the like may refer to the creation of an instance, and "instance" may refer to the specific occurrence of an object (which may occur, for example, during execution of program code). Further, NRF954 may expose an interface based on an nrrf service.

PCF 956 may provide policy rules to control plane functions to enforce them and may also support a unified policy framework to regulate network behavior. The PCF 956 may also implement a front end to access subscription information related to policy decisions in the UDR of the UDM 958. In addition to communicating with functions through reference points as shown, PCF 956 also exhibits an Npcf service-based interface.

The UDM 958 may process the subscription-related information to support processing of the communication session by the network entity, and may store subscription data for the UE 902. For example, subscription data may be passed via an N8 reference point between UDM 958 and AMF 944. The UDM 958 may include two portions: front end and UDR are applied. The UDR may store subscription data and policy data for UDM 958 and PCF 956, and/or structured data for open and application data for NEF952 (including PFD for application detection, application request information for multiple UEs 902). UDR 221 may expose an Nudr service-based interface to allow UDM 958, PCF 956, and NEF952 to access a particular set of stored data, as well as read, update (e.g., add, modify), delete, and subscribe to notifications of relevant data changes in the UDR. The UDM may include a UDM-FE that hosts processing credentials, location management, subscription management, and the like. Several different front ends may serve the same user in different transactions. The UDM-FE accesses subscription information stored in the UDR and performs authentication credential processing, user identification processing, access authorization, registration/mobility management and subscription management. The UDM 958 may also expose a Nudm service based interface in addition to communicating with other NFs through reference points as shown.

The AF 960 may provide application impact on traffic routing, provide access to NEF, and interact with the policy framework for policy control.

In some embodiments, the 5GC 940 may implement the edge calculation by selecting an operator/third party service to be geographically close to the point at which the UE902 attaches to the network. This reduces the delay and load on the network. To provide an edge calculation implementation, the 5GC 940 may select the UPF 948 near the UE902 and perform traffic steering from the UPF 948 to the data network 936 via the N6 interface. This may be based on UE subscription data, UE location and information provided by the AF 960. In this way, the AF 960 may affect UPF (re) selection and traffic routing. Based on operator deployment, the network operator may allow AF 960 to interact directly with the relevant NFs when AF 960 is considered a trusted entity. Further, the AF 960 may expose an interface based on the Naf service.

The data network 936 may represent various network operator services, internet access, or third party services that may be provided by one or more servers, including, for example, an application/content server 938.

Fig. 10 schematically illustrates a wireless network 1000 in accordance with various embodiments. The wireless network 1000 may include a UE 1002, the UE 1002 in wireless communication with AN 1004. The UE 1002 and AN 1004 may be similar to, and substantially interchangeable with, like-named components described elsewhere herein.

UE 1002 may be communicatively coupled with AN 1004 via connection 1006. Connection 1006 is shown as an air interface to enable communicative coupling and may conform to a cellular communication protocol (e.g., an LTE protocol or a 5G NR protocol operating at mmWave or sub-6GHz frequencies).

UE 1002 may include a host platform 1008, host platform 1008 coupled with a modem platform 1010. The host platform 1008 may include application processing circuitry 1012, and the application processing circuitry 1012 may be coupled with protocol processing circuitry 1014 of the modem platform 1010. The application processing circuitry 1012 may run various applications for the UE 1002 that present/assimilate application data. The application processing circuitry 1012 may also implement one or more layers of operations to send and receive application data to and from a data network. These layer operations may include transport (e.g., UDP) and internet (e.g., IP) operations.

Protocol processing circuitry 1014 may implement one or more layers of operations to facilitate the sending or receiving of data over connection 1006. Layer operations implemented by the protocol processing circuit 1014 may include, for example, MAC, RLC, PDCP, RRC, and NAS operations.

The modem platform 1010 may further include digital baseband circuitry 1016, the digital baseband circuitry 1016 may implement one or more layer operations as a "lower" layer of operations performed by the protocol processing circuitry 1014 in the network protocol stack. These operations may include, for example: PHY operations including one or more of: HARQ-ACK functionality, scrambling/descrambling, coding/decoding, layer mapping/demapping, modulation symbol mapping, received symbol/bit metric determination, multi-antenna port precoding/decoding (which may include one or more of space-time, space-frequency, or spatial coding), reference signal generation/detection, preamble sequence generation and/or decoding, synchronization sequence generation/detection, control channel signal blind decoding, and other related functions.

Modem platform 1010 may further include transmit circuitry 1018, receive circuitry 1020, RF circuitry 1022, and RF front end (RFFE) 1024, which may include or be connected to one or more antenna panels 1026. Briefly, the transmit circuit 1018 may include a digital-to-analog converter, a mixer, an Intermediate Frequency (IF) component, and the like; the receive circuitry 1020 may include analog-to-digital converters, mixers, IF components, and the like; RF circuitry 1022 may include low noise amplifiers, power tracking components, and so forth; RFFE 1024 may include filters (e.g., surface/bulk acoustic wave filters), switches, antenna tuners, beamforming components (e.g., phased array antenna components), and so on. The selection and arrangement of the components of transmit circuitry 1018, receive circuitry 1020, RF circuitry 1022, RFFE 1024, and antenna panel 1026 (generally referred to as "transmit/receive components") may be specific to the specifics of the particular implementation (e.g., whether the communication is Time Division Multiplexed (TDM) or Frequency Division Multiplexed (FDM), in mmWave or sub-6gHz frequencies, etc.). In some embodiments, the transmit/receive components may be arranged in multiple parallel transmit/receive chains, may be provided in the same or different chips/modules, and so on.

In some embodiments, the protocol processing circuit 1014 may include one or more instances of control circuitry (not shown) to provide control functionality for the transmit/receive components.

UE reception may be established by and via antenna panel 1026, RFFE 1024, RF circuitry 1022, receive circuitry 1020, digital baseband circuitry 1016, and protocol processing circuitry 1014. In some embodiments, the antenna panel 1026 can receive transmissions from the AN 1004 via receive beamformed signals received by multiple antennas/antenna elements of one or more of the antenna panels 1026.

UE transmission may be established by and via protocol processing circuitry 1014, digital baseband circuitry 1016, transmit circuitry 1018, RF circuitry 1022, RFFE 1024, and antenna panel 1026. In some embodiments, the transmit components of UE 1004 may apply spatial filters to the data to be transmitted to form the transmit beams transmitted by the antenna elements of antenna panel 1026.

Similar to the UE 1002, the AN 1004 may include a host platform 1028, the host platform 1028 coupled with a modem platform 1030. Host platform 1028 may include application processing circuitry 1032, application processing circuitry 1032 coupled to protocol processing circuitry 1034 of modem platform 1030. The modem platform may further include digital baseband circuitry 1036, transmit circuitry 1038, receive circuitry 1040, RF circuitry 1042, RFFE circuitry 1044, and antenna panel 1046. The components of the AN 1004 may be similar to, and substantially interchangeable with, the synonymous components of the UE 1002. In addition to performing data transmission/reception as described above, the components of AN 1008 may perform various logical functions including, for example, RNC functions (e.g., radio bearer management, uplink and downlink dynamic radio resource management, and data packet scheduling).

Fig. 11 is a block diagram illustrating components capable of reading instructions from a machine-readable or computer-readable medium (e.g., a non-transitory machine-readable storage medium) and performing any one or more of the methodologies discussed herein, according to some example embodiments. In particular, fig. 11 shows a diagrammatic representation of hardware resources 1100, hardware resources 1100 including one or more processors (or processor cores) 1110, one or more memory/storage devices 1120, and one or more communication resources 1130, each of which may be communicatively coupled via a bus 1140 or other interface circuitry. For embodiments that utilize node virtualization (e.g., NFV), hypervisor 1102 may be executed to provide an execution environment for one or more network slices/subslices to utilize hardware resources 1100.

Processor 1110 may include, for example, processor 1112 and processor 1114. Processor 1110 may be, for example, 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 DSP (e.g., baseband processor), an ASIC, an FPGA, a Radio Frequency Integrated Circuit (RFIC), another processor (including those discussed herein), or any suitable combination thereof.

Memory/storage 1120 may include main memory, disk storage, or any suitable combination thereof. The memory/storage 1120 may include, but is not limited to, any type of volatile, non-volatile, or semi-volatile memory (e.g., 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, etc.).

Communication resources 1130 may include interconnect or network interface controllers, components, or other suitable devices to communicate with one or more peripherals 1104 or one or more databases 1106 or other network elements via network 1108. For example, communication resources 1130 may include wired communication components (e.g., for coupling via USB, ethernet, etc.), cellular communication components, NFC components, and the like,

(or low power consumption)

) A component,

Components and other communication components.

The instructions 1150 may include software, programs, applications (applications), applets (applets), applications (apps), or other executable code for at least causing any processor 1110 to perform any one or more of the methods discussed herein. The instructions 1150 may reside, completely or partially, within at least one of the processor 1110 (e.g., within a cache memory of the processor), the memory/storage 1120, or any suitable combination thereof. Further, any portion of instructions 1150 may be communicated to hardware resources 1100 from any combination of peripherals 1104 or database 1106. Thus, the memory of processor 1110, memory/storage 1120, peripherals 1104, and database 1106 are examples of computer-readable and machine-readable media.

For one or more embodiments, at least one of the components set forth in one or more of the foregoing figures may be configured to perform one or more operations, techniques, procedures, and/or methods set forth in the example section below. For example, the baseband circuitry described above in connection with one or more of the foregoing figures may be configured to operate in accordance with one or more of the examples set forth below. For another example, circuitry associated with a UE, base station, network element, etc., as described above in connection with one or more of the preceding figures, may be configured to operate in accordance with one or more of the examples set forth below in the examples section.

Example procedure：

Fig. 12 illustrates a process 1200 according to an embodiment. At operation 1202, the process includes: a message for a User Equipment (UE) is encoded indicating a repetition count for a Physical Downlink Control Channel (PDCCH) carrying Downlink Control Information (DCI). At operation 1204, the process includes: the message is sent to a communication resource of the gNB for transmission to the UE.

Fig. 13 illustrates a process 1300 according to an embodiment. At operation 1302, the process includes: decoding a message from an NR node B (gNB) indicating a repetition count for a Physical Downlink Control Channel (PDCCH) carrying Downlink Control Information (DCI). At operation 1304, the process includes: a repetition count is determined from the message.

Example (c):

example 1 includes: an apparatus of a new air interface (NR) User Equipment (UE), the apparatus comprising: a memory; and one or more processors coupled to the memory, the memory storing instructions, and the one or more processors to implement the instructions to: decoding a message from an NR node B (gNB) indicating a repetition count for a Physical Downlink Control Channel (PDCCH) carrying Downlink Control Information (DCI); and determining the repetition count from the message.

Example 2 includes: the subject matter of example 1, the one or more processors to: decoding the PDCCH based on the repetition count.

Example 3 includes: the subject matter of example 1, wherein a repetition count of 1 is used to indicate no repetitions and a repetition count greater than 1 is used to indicate a number of repetitions corresponding to the repetition count.

Example 4 includes: the subject matter of example 1, wherein the message comprises a Radio Resource Control (RRC) message when the repetition count is greater than 1 and a DCI when the repetition count is 1.

Example 5 includes: the subject matter of any of examples 1-4, the one or more processors to: determining a starting location of downlink communications to the UE based on the repetition count.

Example 6 includes: the subject matter of example 5, wherein the downlink communication is one of a Physical Downlink Shared Channel (PDSCH) or a hybrid automatic repeat request (HARQ) in a dynamic codebook.

Example 7 includes: the subject matter of example 5, the one or more processors to: determining a processing time for the downlink communication based on the repetition count.

Example 8 includes: the subject matter of example 5, wherein the starting position corresponds to a symbol number or a slot number.

Example 9 includes: the subject matter of example 1, the message comprising an indication of a merging value corresponding to repetition information for the DCI, the repetition information comprising pairs of repetition information, each pair of repetition information comprising a set of synchronization signals and a monitoring opportunity, the pairs being different from each other, each pair corresponding to a repeated instance of the DCI.

Example 10 includes: the subject matter of example 9, wherein the combined value provides an indication corresponding to a number of the repeated Transmission Reception Points (TRPs).

Example 11 includes: the subject matter of example 9, the one or more processors to: implementing a fixed rule to determine a monitoring occasion for downlink communication to the UE based on the combined value.

Example 12 includes: the subject matter of any of examples 1-4 and 9-11, further comprising a communication resource coupled to the one or more processors to communicate with the gNB.

Example 13 includes: a method for execution at an apparatus of a new air interface (NR) node B (gNB), the method comprising: encoding a message for a User Equipment (UE) indicating a repetition count for a Physical Downlink Control Channel (PDCCH) carrying Downlink Control Information (DCI); and send the message to a communication resource of the gNB for transmission to the UE.

Example 14 includes: the subject matter of example 13, wherein a repetition count of 1 is used to indicate no repetitions and a repetition count greater than 1 is used to indicate a number of repetitions corresponding to the repetition count.

Example 15 includes: the subject matter of example 13, wherein the message comprises a Radio Resource Control (RRC) message when the repetition count is greater than 1 and a DCI when the repetition count is 1.

Example 16 includes: the subject matter of any of examples 13-15, the repetition count corresponding to a starting location of downlink communications to the UE based on the repetition count.

Example 17 includes: the subject matter of example 16, wherein the downlink communication is one of a Physical Downlink Shared Channel (PDSCH) or a hybrid automatic repeat request (HARQ) in a dynamic codebook.

Example 18 includes: the subject matter of example 16, wherein the starting position corresponds to a symbol number or a slot number.

Example 19 includes: the subject matter of example 13, the message comprising an indication of a merging value corresponding to repetition information for the DCI, the repetition information comprising pairs of repetition information, each pair of repetition information comprising a set of synchronization signals and a monitoring opportunity, the pairs being different from each other, each pair corresponding to a repeated instance of the DCI.

Example 20 includes: the subject matter of example 19, wherein the combined value provides an indication corresponding to a number of the repeated Transmit Receive Points (TRPs).

Example 21 includes: the subject matter of any of examples 13-15 and 19-20, further comprising: communicating with the UE using the communication resources.

Example 22 includes: an apparatus of a new air interface (NR) node B (gNB), the apparatus comprising: a memory; and one or more processors coupled to the memory, the memory storing instructions, and the one or more processors to implement the instructions to: encoding a message for a User Equipment (UE) indicating a repetition count for a Physical Downlink Control Channel (PDCCH) carrying Downlink Control Information (DCI); and send the message to a communication resource of the gNB for transmission to the UE.

Example 23 includes: the subject matter of example 22, wherein a repetition count of 1 is used to indicate no repetitions and a repetition count greater than 1 is used to indicate a number of repetitions corresponding to the repetition count.

Example 24 includes: the subject matter of example 22, wherein the message comprises a Radio Resource Control (RRC) message when the repetition count is greater than 1 and DCI when the repetition count is 1.

Example 25 includes: the subject matter of any of examples 22-24, the repetition count corresponding to a starting location of downlink communications to the UE based on the repetition count.

Example 26 includes: the subject matter of example 25, wherein the downlink communication is one of a Physical Downlink Shared Channel (PDSCH) or a hybrid automatic repeat request (HARQ) in a dynamic codebook.

Example 27 includes: the subject matter of example 25, wherein the starting position corresponds to a symbol number or a slot number.

Example 28 includes: the subject matter of example 22, the message comprising an indication of a merging value corresponding to repetition information for the DCI, the repetition information comprising pairs of repetition information, each pair of repetition information comprising a set of synchronization signals and a monitoring opportunity, the pairs being different from each other, each pair corresponding to a repeated instance of the DCI.

Example 29 includes: the subject matter of example 28, wherein the combined value provides an indication corresponding to a number of the repeated Transmit Receive Points (TRPs).

Example 30 includes: the subject matter of any of examples 22-24 and 28-29, further comprising: the communication resources are coupled to the one or more processors.

Example 31 includes: a method for execution at an apparatus of a new air interface (NR) User Equipment (UE), the method comprising: decoding a message from an NR node B (gNB) indicating a repetition count for a Physical Downlink Control Channel (PDCCH) carrying Downlink Control Information (DCI); and determining the repetition count from the message.

Example 32 includes: the subject matter of example 31, further comprising: decoding the PDCCH based on the repetition count.

Example 33 includes: the subject matter of example 31, wherein a repetition count of 1 is used to indicate no repetitions and a repetition count greater than 1 is used to indicate a number of repetitions corresponding to the repetition count.

Example 34 includes: the subject matter of example 31, wherein the message comprises a Radio Resource Control (RRC) message when the repetition count is greater than 1 and DCI when the repetition count is 1.

Example 35 includes: the subject matter of any of examples 31-34, further comprising: determining a starting location of downlink communications to the UE based on the repetition count.

Example 36 includes: the subject matter of example 35, wherein the downlink communication is one of a Physical Downlink Shared Channel (PDSCH) or a hybrid automatic repeat request (HARQ) in a dynamic codebook.

Example 37 includes: the subject matter of example 35, further comprising: determining a processing time for the downlink communication based on the repetition count.

Example 38 includes: the subject matter of example 35, wherein the starting position corresponds to a symbol number or a slot number.

Example 39 includes: the subject matter of example 31, the message comprising an indication of a merging value corresponding to repetition information for the DCI, the repetition information comprising pairs of repetition information, each pair of repetition information comprising a set of synchronization signals and a monitoring opportunity, the pairs being different from each other, each pair corresponding to a repeated instance of the DCI.

Example 40 includes: the subject matter of example 39, wherein the combined value provides an indication corresponding to a number of the repeated Transmit Receive Points (TRPs).

Example 41 includes: the subject matter of example 39, further comprising: implementing a fixed rule to determine a monitoring occasion for downlink communication to the UE based on the combined value.

Example 42 includes: the subject matter of any one of examples 31-34 and 39-41, further comprising: communicate with the gNB using communication resources of the UE.

Example 43 includes: a machine-readable medium comprising code that, when executed, causes a machine to perform the subject matter of any of examples 13-21 and 31-42.

Example 44 includes: an apparatus comprising means for performing the subject matter of any of examples 13-21 and 31-42.

Example 1A may include: a method of PDCCH repetition from multiple TRPs.

Example 2A may include: the method of example 1A or some other example herein, wherein one or more of the following repetition types are supported: between CORESET for repeats across TRP; within CORESET with repeats across the SS set; CORESET with repeats across MOs.

Example 3A may include: the method of example 2A or some other example herein, wherein the UE is configured to: it may expect DCI repetition from any combination of the above.

Example 4A may include: the method of example 2A or some other example herein, wherein, across two PDCCHs to be combined, an MO is implicit (same MO), a slot is implicit (same slot), a DCI is implicit (common DCI across only SS sets), an AL is implicit (common AL only), and a candidate is implicit (common candidate only).

Example 5A may include: the method of example 2A or some other example herein, wherein the UE is indicated for repeated SS sets, MOs, slots, DCI, candidates.

Example 6A may include: the method of example 2A or some other example herein, wherein for soft combining, candidate m for SS-1/AL4 can be combined with candidate m for SS-2/AL4 to produce a repetition of jointly coded AL8 (ordered by TRP-0 then TRP-1) or AL 4.

Example 7A may include: the method as in example 2A or some other example herein, wherein for soft combining, candidate m for SS-1/AL4 may be combined with all candidates for SS-2/AL4 to produce a repetition of jointly coded AL8 (ordered by TRP-0 then TRP-1) or AL 4.

Example 8A may include: a method, comprising: receiving configuration information for CORESET; and monitoring DCI having a repetition based on the CORESET under one or more of the following repetition patterns: between CORESET for repeats across TRP; within CORESET with repeats across the SS set; and/or CORESET with repeats across MOs.

Examples Z01 may include: an apparatus comprising means for performing a method described in or relating to any of examples 1-8, or one or more elements of any other method or process described herein.

Example Z02 may include: one or more non-transitory computer-readable media comprising 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 methods described in or relating to any of examples 1-8, or any other method or process described herein.

Example Z03 can include: an apparatus comprising logic, modules, or circuitry to perform a method described in or relating to any of examples 1-8, or one or more elements of any other method or process described herein.

Example Z04 may include: a method, technique or process as described in or relating to any one of examples 1-8 or a part or portion thereof.

Example Z05 can include: an apparatus, comprising: one or more processors; and one or more computer-readable media comprising instructions that, when executed by the one or more processors, cause the one or more processors to perform the methods, techniques, or processes described in or related to any of examples 1-8 or portions thereof.

Example Z06 may include: a signal as described in or relating to any one of examples 1 to 8 or a part or portion thereof.

Example Z07 can include: a datagram, packet, frame, segment, protocol Data Unit (PDU), or message as described in or relating to any one of examples 1-8, or portions or parts thereof, or otherwise described in this disclosure.

Example Z08 may include: a signal encoded with data described in or relating to any one of examples 1-8 or a portion or part thereof, or otherwise described in this disclosure.

Example Z09 can include: a signal encoded by a datagram, packet, frame, segment, protocol Data Unit (PDU), or message as described in or relating to any one of examples 1-8, or portions or parts thereof, or otherwise described in this disclosure.

Example Z10 may include: an electromagnetic signal carrying computer-readable instructions, wherein execution of the computer-readable instructions by one or more processors causes the one or more processors to perform a method, technique or process described in or relating to any one of examples 1-8 or portions thereof.

Example Z11 may include: a computer program comprising instructions, wherein execution of the program by a processing element causes the processing element to perform any one of, or a portion of, the methods, techniques, or processes described in or relating to examples 1-8.

Example Z12 may include: a signal in a wireless network as shown and described herein.

Example Z13 may include: a method of communicating in a wireless network as shown and described herein.

Example Z14 may include: a system for providing wireless communication as shown and described herein.

Example Z15 may include: an apparatus for providing wireless communication as shown and described herein.

Any of the above examples can be combined with any other example (or combination of examples) unless explicitly stated otherwise. The foregoing description of one or more implementations provides illustration and description, but is not intended to be exhaustive or to limit the scope of the embodiments to the precise form disclosed. Modifications and variations are possible in light of the above teachings or may be acquired from practice of various embodiments.

Claims (25)

1. An apparatus of a new air interface (NR) User Equipment (UE), the apparatus comprising: a memory; and one or more processors coupled to the memory, the memory storing instructions, and the one or more processors to implement the instructions to:

decoding a message from a NR node B (gNB) indicating a repetition count for a Physical Downlink Control Channel (PDCCH) carrying Downlink Control Information (DCI); and

determining the repetition count from the message.

2. The apparatus of claim 1, the one or more processors to:

decoding the PDCCH based on the repetition count.

3. The apparatus of claim 1, wherein a repetition count of 1 is used to indicate no repetitions and a repetition count greater than 1 is used to indicate a number of repetitions corresponding to the repetition count.

4. The apparatus of claim 1, wherein the message comprises a Radio Resource Control (RRC) message when the repetition count is greater than 1 and DCI when the repetition count is 1.

5. The apparatus of any one of claims 1-4, the one or more processors to:

determining a starting location of downlink communications to the UE based on the repetition count.

6. The apparatus of claim 5, wherein the downlink communication is one of a Physical Downlink Shared Channel (PDSCH) or a hybrid automatic repeat request (HARQ) in a dynamic codebook.

7. The apparatus of claim 5, the one or more processors to:

determining a processing time for the downlink communication based on the repetition count.

8. The apparatus of claim 5, wherein the starting position corresponds to a symbol number or a slot number.

9. The apparatus of claim 1, the message comprising an indication of a merging value corresponding to repetition information for the DCI, the repetition information comprising pairs of repetition information, each pair of repetition information comprising a set of synchronization signals and a monitoring opportunity, the pairs being different from each other, each pair corresponding to a repeating instance of the DCI.

10. The apparatus of claim 9, wherein the combined value provides an indication corresponding to a number of the repeated Transmission Receive Points (TRPs).

11. The apparatus of claim 9, the one or more processors to:

implementing a fixed rule to determine a monitoring occasion for downlink communication to the UE based on the combined value.

12. The apparatus of any of claims 1-4 and 9-11, further comprising communication resources coupled to the one or more processors to communicate with the gNB.

13. A method for execution at an apparatus of a new air interface (NR) node B (gNB), the method comprising:

encoding a message for a User Equipment (UE) indicating a repetition count for a Physical Downlink Control Channel (PDCCH) carrying Downlink Control Information (DCI); and

sending the message to communication resources of the gNB for transmission to the UE.

14. The method of claim 13, wherein a repetition count of 1 is used to indicate no repetitions and a repetition count greater than 1 is used to indicate a number of repetitions corresponding to the repetition count.

15. The method of claim 13, wherein the message comprises a Radio Resource Control (RRC) message when the repetition count is greater than 1 and a DCI when the repetition count is 1.

16. The method of claim 13, the repetition count corresponding to a starting location of downlink communications to the UE based on the repetition count.

17. The method of claim 16, wherein the downlink communication is one of a Physical Downlink Shared Channel (PDSCH) or a hybrid automatic repeat request (HARQ) in a dynamic codebook.

18. The method of claim 16, wherein the starting position corresponds to a symbol number or a slot number.

19. The method of claim 13, the message including an indication of a merging value corresponding to repetition information for the DCI, the repetition information including pairs of repetition information, each pair of repetition information including a set of synchronization signals and a monitoring opportunity, the pairs being different from each other, each pair corresponding to a repeating instance of the DCI.

20. The method of claim 19, wherein the combined value provides an indication corresponding to a number of the repeated Transmission Reception Points (TRPs).

21. The method of claim 13, further comprising:

communicating with the UE using the communication resources.

22. An apparatus of a new air interface (NR) node B (gNB), the apparatus comprising: a memory; and one or more processors coupled to the memory, the memory storing instructions, and the one or more processors to implement the instructions to:

encoding a message for a User Equipment (UE) indicating a repetition count for a Physical Downlink Control Channel (PDCCH) carrying Downlink Control Information (DCI); and

sending the message to communication resources of the gNB for transmission to the UE.

23. The apparatus of claim 22, the repetition count corresponding to a starting position of a downlink communication to the UE based on the repetition count, wherein the downlink communication is one of a Physical Downlink Shared Channel (PDSCH) or a hybrid automatic repeat request (HARQ) in a dynamic codebook.

24. A machine-readable medium comprising code, which when executed, causes a machine to perform the method of any of claims 13-21.

25. An apparatus, comprising: means for performing the method of any of claims 13-21.

Images