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

Abstract

Apparatuses, systems, methods, and machine-readable media of a user equipment (UE). The apparatus includes one or more processors to: decode 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 determine the repetition count from the message.

Description

[0001] Cross-reference to related applications

[0002] This application claims the benefit and priority of U.S. Provisional Patent Application No. 63 / 063,089, filed August 7, 2021, entitled “PDCCH repetition configuration”, and U.S. Provisional Patent Application No. 63 / 062,877, filed August 7, 2020, entitled “PDSCH starting configuration and processing time indication”. The disclosure of the prior applications is considered part of the disclosure of this application and is hereby incorporated by reference. Background Technology

[0003] Various embodiments can generally relate to the field of wireless communications, and more specifically, to communications in cellular networks that comply with one of the more 3rd Generation Partnership Project (3GPP) specifications. Attached Figure Description

[0004] In the accompanying drawings, which are not necessarily drawn to scale, the same reference numerals may describe similar components in different views. The same numbers with different letter suffixes may represent different instances of similar components. The accompanying drawings illustrate, by way of example and not limitation, the various embodiments discussed in this document.

[0005] Figure 1 The method for CORESET repetition and soft merging of PDCCH is shown, where different CORESETs are associated with different TCI states.

[0006] Figure 2 The CORESET method for repeated or soft merging is shown.

[0007] Figure 3 The diagram illustrates a CCE aggregation performed as part of a soft merge, where an overlapping search space is involved.

[0008] Figure 4 The CORESET method for PDCCH repetition across monitoring times is shown.

[0009] Figure 5 The CORESET intra-method for PDCCH based on SS sets is shown, where different SS sets of the same CORESET are associated with different TCI states.

[0010] Figure 6 This shows a set of time slots illustrating the various possibilities of sending DCI via one or two PDCCHs.

[0011] Figure 7 This shows the cross-slot repetition of DCI.

[0012] Figure 8 An example of PDSCH processing time ambiguity caused by PDCCH duplication is shown.

[0013] Figure 9 Wireless networks according to various embodiments are shown.

[0014] Figure 10 The illustrations depict user equipment (UE) and radio access node (RAN) in wireless communication according to various embodiments.

[0015] Figure 11 Components according to some example embodiments are shown, which are capable of reading instructions from a machine-readable or computer-readable medium and performing any one or more methods discussed herein.

[0016] Figure 12 A flowchart for a process according to a first embodiment is shown.

[0017] Figure 13 A flowchart for the process according to the second embodiment is shown. Detailed Implementation

[0018] The following detailed description refers to the accompanying drawings. The same reference numerals may be used in different drawings to identify the same or similar elements. In the following description, specific details (e.g., particular structures, architectures, interfaces, technologies, etc.) are set forth for purposes of explanation and not limitation in order to provide a thorough understanding of various aspects of the various embodiments. However, it will be apparent to those skilled in the art that they benefit from this disclosure that various aspects of the various embodiments may be practiced in other examples departing from these specific details. In some cases, descriptions of well-known devices, circuits, and methods have been 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).

[0019] I. Physical downlink control channel reconfiguration

[0020] PDCCH Reliability Solution

[0021] Some embodiments relate to 5G New Radio (NR) Rel-17 Multiple-Input Multiple-Output (MIMO) Enhancement Work Item (WI) with respect to enhancements to the Physical Downlink (DL) Control Channel (PDCCH). Some embodiments relate to mechanisms for PDCCH repetition and mechanisms for mapping Transport Configuration Indicator (TCI) states to the PDCCH.

[0022] PDCCH repetition from different transmit / receive points (TRPs) (different TCI states) can be configured based on the control resource set (CORESET), synchronization signal (SS) set, or monitoring timing.

[0023] Built on the signaling framework that exists in Rel-15 and Rel-16, some embodiments of this paper allow the network to assign PDCCH repetitions from different TRPs (different TCI states).

[0024] Selective diversity is a scenario where a user equipment (UE) can 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 can have a different aggregation level (AL). There is no expectation that the UE should attempt soft combining of different repetitions, and this is not considered in blind decoding (BD) constraints. On the UE side, selective diversity can be implemented where each BD candidate is treated in the same way as Rel-15.

[0025] The soft-merging scheme is the scenario where the UE is expected to attempt soft merging of two PDCCH candidates, and soft-merging attempts are considered within the BD limit. On the UE side, soft merging may mean additional storage and merging of PDCCH candidates, as well as additional decoding attempts.

[0026] Furthermore, soft merging schemes can be categorized as joint encoding (similar to scheme 2a mentioned below) or repetition (similar to scheme 2b mentioned below, but including tracking merging). Note that joint encoding will naturally be limited by AL level 16 (AL16) performance. In terms of performance, no significant difference is expected between the two schemes.

[0027] High-level PDCCH reliability schemes can be classified as: 1) selection diversity; 2a) soft merging with joint coding; 2b) soft merging with repetition.

[0028] BD / Control Channel Element (CCE) Allocation for PDCCH Reliability Scheme

[0029] As mentioned above, three different 2-TRP PDCCH schemes can be considered—System Frame Number (SFN), Selective Diversity, and Soft Combining. SFN is considered canonical transparent because the BD / CCE allocation in SFN is the same as in Rel-15. Note that NW can (dynamically) choose to transmit only from TRP-1, only from TRP-2, or from both TRP-1 and TRP-2, but TRP transmissions are transparent to the UE.

[0030] For the choice of diversity or soft combining schemes, CCE allocation can be considered generally additive between TRP-1 and TRP-2 because channel estimates cannot be reused across TRPs. Meanwhile, we envision that channel estimates can be fully reused across SS sets and ALs within the same TRP / CORESET, based on the Rel-15 rule. For BD allocation, we can assume the same guiding principle: NW can (dynamically) choose to transmit only from TRP-1, only from TRP-2, or from both TRP-1 and TRP-2. As an example, TRP-1 can choose to transmit AL16 PDCCH without duplication, or transmit with two duplications using AL8+AL8 from TRP-1+TRP-2 respectively, to transmit specific Ultra-Reliable Low-Latency Communication (URLLC) packets. Based on the above principles, it can be envisioned that, similar to CCE allocation, the BD allocation used to select diversity schemes is typically additive between TRP-1 and TRP-2, and only certain selected candidates and certain selected ALs can be allocated for repetition in order to save the total BD / CCE consumption in the time slot.

[0031] The BD allocation for soft merging schemes can vary depending on the specific scheme used. Generally, the guiding principle that the NW can be dynamically selected from either TRP-1 or TRP-2 transmissions can be followed, and therefore, the BD allocation can be formulated according to some embodiments as follows:

[0032] -BD(candidates from TRP-1) + BD(candidates from TRP-2) + BD(soft merge candidates from TRP-1 and TRP-2); or

[0033] -BD(candidate from TRP-1)+BD(soft merge candidate from TRP-1 and 2)——In this case, TRP-2 can send PDCCH only if TRP-1 is also sending.

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

[0035] Based on the relevant proposals, the following BD / CCE allocation principle can be considered for repetition:

[0036] • CCE allocation can involve CCE(TRP-1) + CCE(TRP-2);

[0037] • The BD allocation used for selecting diversity can involve BD (candidates from TRP-1) + BD (candidates from TRP-2);

[0038] • BD allocation for soft merging can involve BD (candidates from TRP-1) + BD (candidates from TRP-2) + BD (soft candidates from TRP-1 and TRP-2)

[0039] Given that BD / CCE capacity is limited at the UE, some flexibility may be desired in allocating BD / CCE across TRPs. As an example, the BD / CCE allocation between TRP-1 and TRP-2 could be 80-20, 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 rather should be able to be flexibly adjusted according to different deployment needs.

[0040] Therefore, according to a related proposal, flexible BD / CCE partitioning (for duplication) 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).

[0041] Modifications made within the context of maximizing reliability objectives may also be helpful in situations such as determining whether AL16 type reliability is sufficient, whether different AL levels might be needed, and whether repetitions can be deployed both within and across time slots. Examples include a) AL8(TRP-1) + AL8(TRP-2), or b) AL16(TRP-1) + AL16(TRP-2), or c) including higher repetitions with coverage (PDCCH repetitions within or across time slots).

[0042] Example I-1 – CORESET Inter-method

[0043] Now refer to Figure 1 , Figure 1 This illustrates the CORESET method for PDCCH repetition and soft merging, where different CORESETs are associated with different TCI states. Specifically, Figure 1 A set of two CORESETs 102 and 104 (100) corresponding to CORESET-1 and CORESET-2 are shown. In the illustrated embodiment, CORESET-1 corresponds to TRP1 and SS1, and CORESET-2 corresponds to TRP2 and SS2. Each CORESET includes 8 PDCCH candidates at AL2 and 8 PDCCH candidates at AL4.

[0044] At the high level, Figure 1In this method, each CORESET is associated with a different TRP (TCI state). As an example, CORESET-1, SS set-1, and TCI-StateId-1 come from TRP-1, while CORESET-2, SS set-2, and TCI-StateId-2 come from TRP-2. For soft merging, a candidate m with a given value of SS-1 / AL4 can be merged with a candidate m with the same value of SS-2 / AL4. Figure 1 The arrows between the candidate m in the diagram illustrate examples of possible mergers according to the above-described system.

[0045] Example shown in Figure 1 The approach described in the text can naturally provide full flexibility in partitioning BD / CCE between TRP-1 and TRP-2 using the current signaling framework. Inequal resource partitioning within candidates (e.g., in cases where candidates from different TCI states and different ALs are to be soft-merged) will require changes to the CCE hash function to allow CCE aggregations of more than 2, 4, 8, or 16 (e.g., soft merging AL2+AL6 to obtain AL8).

[0046] Now refer to Figure 2 , Figure 2 It also involves CORESET methods for repeated or soft merges. Figure 2 The diagram shows a set of (200) CORESETs, including CORESET-1 202 and CORESET-2 204, each CORESET including four PDCCH candidates at AL4. Figure 2 As shown, candidates from CORESET-1 and CORESET-2 may undergo repetition 206 or be soft-merged via joint encoding to produce a soft-merged CORESET 208 with candidates at AL8.

[0047] For example Figure 3 As shown, a set of CORESET 300 includes CORESET-1 302 and CORESET-2 304, and CCE aggregation can be performed as part of a soft merge, where an overlapping search space is involved. Figure 3 In this context, candidates with the same m value and corresponding to the same AL rank (in this case, AL2) can be merged. Figure 3 In one embodiment, a new UE-specific search space can be defined, which includes CCE / BD candidates monitored by the UE from two or more CORESETs, for example, for AL = 2·L CCEs, where the CORESETs are time-division multiplexed (TDM) by presenting candidate offsets relative to each other in the time domain, such as... Figure 3 As shown, this allows for the time available for beam switching within frequency range 2 (FR2).

[0048] For selection diversity, restrictions on search space or CORESET overlap are not necessary. For soft merge, this is good if the search spaces are non-overlapping (this is likely the typical case). It is conceivable that the search spaces overlap, but the BD candidates for soft merge are non-overlapping (the starting position of the hash function depends on the CORESET—offsets can be possible).

[0049] Example 1-2 – CORESET Intra-method

[0050] Example I-2a – A repeating CORESET method with cross-monitoring timing

[0051] Now refer to Figure 4 , Figure 4 The CORESET method for repeating PDCCH across monitoring times is shown, wherein CORESET 400 includes monitoring times (Mo) MO-1 and MO-2 associated with different TCI states (TCI-1 and TCI-2, respectively).

[0052] At the high level, for Figure 4 In this embodiment, each monitoring opportunity (MO) can be associated with a different TRP (TCI-State), while two monitoring opportunities can be associated with the same SS set / CORESET, as shown in the figure. In this case, the flexibility of allocating BD / CCE candidates across two TPRs is naturally limited by the current signaling framework. However, Figure 4 The implementation consumes fewer UE resources in terms of CORESET and SS sets.

[0053] Example I-2b – CORESET Intra-method with Repetition Across SS Sets

[0054] Now refer to Figure 5 , Figure 5 This illustrates a CORESET-based method for PDCCH based on SS sets, where different SS sets within the same CORESET are associated with different TCI states. Specifically, Figure 5 Two SS sets 502 and 504, corresponding to SS-1 and SS-2 respectively, are shown. 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 AL4. Therefore, SS-1 and SS-2 have the same number of CCEs corresponding to the candidates.

[0055] according to Figure 5In some embodiments, selection diversity can be supported, but is limited to the same core set (compared to the case between core sets where this limitation does not exist). Furthermore, soft merging can be supported if SS-1 and SS-2 are non-overlapping. Therefore, physically overlapping BD candidates (such as...) Figure 5 (As shown by the double-headed arrows in the middle), otherwise BD candidate pairs with the same AL will overlap in terms of physical resources, and these BD candidates will be unavailable for PDCCH scheduling (especially for larger ALs).

[0056] Based on the above, some embodiments propose any of the following frameworks for PDDCH replication studies:

[0057] • Inter-CORESET method, where TRP-1 is associated with CORESET-1 and TRP-2 is associated with CORESET-2. This allows for fully flexible partitioning of BD / CCE between TRP-1 and TRP-2; and / or

[0058] • In the CORESET method, TRP-1 is associated with monitoring timing 1 and T.

[0059] • TRP-2 associated with monitoring timing-2 (possibly for the same SS set and the same CORESET). This approach offers limited flexibility in partitioning BD / CCE between TRP-1 and TRP-2, but consumes fewer UE resources in terms of CORESET and SS set.

[0060] Some embodiments in this document include support for one or more of the following PDCCH candidate repeat types:

[0061] - Used for repeated CORESETs across TRPs;

[0062] - Duplicate CORESETs across SS sets;

[0063] - With repeating CORESET across MO;

[0064] - UEs configured to anticipate DCI repetitions from any of the above combinations; or

[0065] - One or more of the following are indicated to the UE: SS set, MO, time slot, DCI or BD candidate for repetition

[0066] According to some embodiments, one or more of the following can be true: MO is implicit (same MO), time slot is implicit (same time slot), DCI is implicit (common DCI across SS sets only), AL is implicit (common AL only), or BD candidate is implicit (common BD candidate only).

[0067] For soft merging, the BD candidate m of SS-1 / AL4 can be merged with the BD candidate m of SS-2 / AL4 to produce a joint encoded AL8 (sorted by TRP-0 then TRP-1) or a repetition of AL4.

[0068] For soft merging, the BD candidate m of SS-1 / AL4 can be merged with all BD candidates of SS-2 / AL4 to produce a jointly encoded AL8 (sorted by TRP-0 then TRP-1) or a repetition of AL4.

[0069] II. PDSCH Initial Configuration and Processing Time Indication

[0070] Some embodiments relate to 5G NR Release 17 MIMO enhancement work items regarding PDCCH enhancements. Some embodiments include methods for determining PDSCH initiation and PDSCH processing time due to PDCCH repetition.

[0071] The ambiguity of PDSCH start time and PDSCH processing time can be resolved by using an embodiment that indicates the number of repetitions via DCI.

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

[0073] Now refer to Figure 6 , Figure 6 The diagram 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. Specifically, Rel-16 URLLC has introduced (RRC-configurable) PDSCH start references that change the scheduling PDCCH start symbol. In the latter context, different network operations can be envisioned corresponding to cases 1, 2, and 3, as follows:

[0074] a. Case 1. The network only sends DCI in PDCCH-1 (AL16), where the starting reference of PDSCH should obviously be PDCCH-1;

[0075] b. Scenario 2. The network only sends DCI in PDCCH-2 (AL16), where PDSCH reference should obviously be PDCCH-2; and

[0076] c. Scenario 3. The network transmits DCI in PDCCH-1 and PDCCH-2 (AL8 for each). In this case, the UE can decode the DCI from either PDCCH-1 or PDCCH-2, and the PDSCH start reference will be ambiguous.

[0077] The Rel-15 start and length indicator value (SLIV) reference is a slot boundary. Therefore, if a repeated DCI is received in PDCCH-1 and PDCCH-2, there is no ambiguity in the PDSCH start reference. However, due to... Figure 6 As explained in the context, Rel-16 URLLC has introduced a (RRC-configurable) PDSCH start reference corresponding to the scheduling PDCCH start symbol, thus Rel-16 introduces ambiguity regarding the PDSCH start time for repeated DCI.

[0078] To resolve ambiguity, according to an embodiment, the DCI field may include a “repeat” field, which is set to 1 for cases 1 and 2, and to 2 for case 3. In this case, the same principle can be used to associate PDSCH (even in the case referenced in Rel-15 SLIV above) with the unique monitoring timing used for PDSCH.

[0079] According to some embodiments, when an SLIV reference is configured as the start symbol for PDSCH monitoring timing, the UE is expected not to receive multiple repetitions of DCI 1_2 (or multiple repetitions with different start symbols for monitoring timing). However, the UE can be provided with indications of certain combinations of SS sets, MOs within time slots, MOs across time slots, and / or candidate combinations within each AL that could potentially be used for repetitions of DCI 1_2 that are to occur. Examples of indications for possible two PDSCH repetitions for DCI could include the following combinations:

[0080] Combination-1: {SS set #1, MO #1} ←→ {SS set #2, MO #1} is a repeating pair used for 2TRP repeats; and

[0081] Combination-2: {SS set #3, MO #1} ←→ {SS set #3, MO #2} is a repeating pair used for 1TRP repeating;

[0082] According to some embodiments, the UE can use fixed rules based on the above indications to determine the monitoring timing for PDSCH; for example, the UE's fixed rules may include the latest monitoring timing in the time slots within the indicated combination. Combinations can be selected based on BD.

[0083] According to some embodiments, for example, in the repetition field, DCI can indicate whether DCI repetition is used, and if so, what type of repetition is used, where the value is:

[0084] • 0 indicates no repetition → SLIV reference should be used based on the decoded DCI;

[0085] • 1. Indication Repetition → Based on the indicated combination corresponding to the DCI repetition, use SLIV references according to fixed rules. For example, a fixed rule could specify using the latest MO within combination-1 to monitor PDSCH; and

[0086] • 2. Indication Repetition → Based on the indicated combination corresponding to the DCI repetition, use SLIV references according to fixed rules. For example, a fixed rule could specify using the latest MO within combination-2 to monitor PDSCH;

[0087] One embodiment may include using the principles outlined above to associate the PDSCH (even with Rel-15 SLIV references) with a unique monitoring timing for the HARQ-ACK bit position in the dynamic codebook.

[0088] One embodiment may include: using the principles outlined above to address processing time issues, such as... Figure 7 and Figure 8 The points raised in the document.

[0089] Specifically, Figure 7 This illustrates a set of two consecutive time slots 702 and 704 with cross-slot repetition of DCI. For example, there could be: four repetitions of DCI, with two in each time slot; or three repetitions of DCI, with one in time slot 702 and two in time slot 704; or any other configuration for repetition. There is no delay if there is no overlap between any repeated DCI and the associated PDSCH monitoring timing, such as... Figure 7 As shown in the example.

[0090] Figure 8 This illustrates an example of PDSCH processing time ambiguity caused by PDCCH duplication. Now refer to... Figure 8 DCI / PDCCH repetition can lead to overlapping symbols used for DCI repetition and PDSCH monitoring timing, such as in the case of cross-slot repetition. Figure 7 As shown in the context. Specifically, Figure 8 The diagram shows a time slot 800 for repeated DCIs 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 PDSCH is delayed by the overlapping symbol (in the illustrated case, the duration of PDCCH-2). Figure 8 In the case that PDSCH is scheduled by PDCCH-1, the processing time will not be delayed.

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

[0092] • Send PDCCH-1 with AL16, without duplication;

[0093] • Send PDCCH-1 and PDCCH-2, both with AL8.

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

[0095] • For PDCCH-1 with AL16 that has no duplicates, the duplicate field = 1; and

[0096] • For PDCCH-1 and PDCCH-2, both with AL8, used for soft merging, the repeating field = 2.

[0097] System and Implementation

[0098] Figures 9-11 Various systems, devices, and components are shown that can implement aspects of the disclosed embodiments.

[0099] Figure 9 Network 900 is illustrated according to various embodiments. Network 800 may operate in a manner consistent with 3GPP technical specifications for LTE or 5G / NR systems. However, the example embodiments are not limited thereto, and the described embodiments can be applied to other networks (e.g., future 3GPP systems, etc.) that benefit from the principles described herein.

[0100] Network 900 may include UE 902, which may include any mobile or non-mobile computing device designed to communicate with RAN 904 via an over-the-air connection. UE 902 may be communicatively coupled to RAN 904 via a Uu interface. UE 902 may include, but is not limited to, smartphones, tablets, wearable computing devices, desktop computers, laptops, in-vehicle infotainment systems, in-vehicle entertainment systems, dashboards, head-mounted displays, onboard diagnostic equipment, dashboard mobile devices, mobile data terminals, electronic engine management systems, electronic / engine control units, electronic / engine control modules, embedded systems, sensors, microcontrollers, control modules, engine management systems, networked devices, machine-type communication devices, M2M or D2D devices, IoT devices, etc.

[0101] In some embodiments, network 900 may include multiple UEs that are directly coupled to each other via sidelink interfaces. The UEs may be M2M / D2D devices that communicate using physical sidelink channels (e.g., but not limited to PSBCH, PSDCH, PSSCH, PSCCH, PSFCH, etc.).

[0102] In some embodiments, UE 902 may additionally communicate with AP 906 via an over-the-air connection. AP 906 may manage a WLAN connection, which may be used to offload some / all network services from RAN 904. The connection between UE 902 and AP 906 may conform to any IEEE 902.11 protocol, wherein AP 906 may be a Wireless Fibre Channel device. Router. In some embodiments, UE 902, RAN 904, and AP 906 may utilize cellular-WLAN aggregation (e.g., LWA / LWIP). Cellular-WLAN aggregation may involve UE 902 being configured by RAN 904 to utilize both cellular radio resources and WLAN resources.

[0103] RAN 904 may include one or more access nodes (e.g., AN 908). AN 908 can terminate the air interface protocol for UE 902 by providing access layer protocols including RRC, PDCP, RLC, MAC, and L1 protocols. In this way, AN 908 can provide data / voice connectivity between CN 920 and UE 902. In some embodiments, 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 CRAN or a virtual baseband unit pool). AN 908 may be referred to as BS, gNB, RAN node, eNB, ng-eNB, NodeB, RSU, TRxP, TRP, etc. AN 908 may be a macrocell base station or a low-power base station, with the low-power base station used to provide femtocells, picocells, or other similar cells that have a smaller coverage area, smaller user capacity, or higher bandwidth compared to macrocells.

[0104] In embodiments where RAN 904 includes multiple ANs, they can be coupled to each other via an X2 interface (if RAN 904 is an LTE RAN) or an Xn interface (if RAN 904 is a 5G RAN). The X2 / Xn interfaces (in some embodiments, they can be separated into control / user plane interfaces) can allow ANs to pass information related to handover, data / context delivery, mobility, load management, interference coordination, etc.

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

[0106] RAN 904 can provide an air interface on licensed or unlicensed spectrum. For operation in unlicensed spectrum, nodes can use LAA, eLAA, and / or feLAA mechanisms based on CA technology with PCells / Scells. Before accessing unlicensed spectrum, nodes can perform medium / carrier sensing operations based on, for example, a Listen-Before-Speak (LBT) protocol.

[0107] In V2X scenarios, UE 902 or AN 908 can be or may act as an RSU, where RSU can refer to any traffic infrastructure entity used for V2X communication. An RSU can be implemented in, or by, a suitable AN or a stationary (or relatively stationary) UE. An RSU implemented in or by the following can be referred to as a "UE-type RSU" for a UE; an "eNB-type RSU" for an eNB; a "gNB-type RSU" for a gNB; and so on. In one example, an RSU is a computing device coupled to radio frequency circuitry located at the roadside that provides connectivity support to passing vehicle UEs. 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 provide extremely low-latency communication required for high-speed events such as collision avoidance, traffic warnings, etc. Additionally or alternatively, an RSU can provide other cellular / WLAN communication services. RSU components can be enclosed in a weatherproof enclosure suitable for outdoor installation and may include a network interface controller for providing wired connectivity (e.g., Ethernet) to traffic signal controllers or backhaul networks.

[0108] In some embodiments, RAN 904 may be an LTE RAN 910 with an eNB (e.g., eNB 912). LTE RAN 910 may provide an LTE air interface with the following characteristics: a 15 kHz SCS; CP-OFDM waveforms for DL ​​and SC-FDMA waveforms for UL; turbo codes for data and TBCC codes for control; etc. The LTE air interface may rely on: 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 in the sub-6 GHz band.

[0109] In some embodiments, RAN 904 may be an NG-RAN 914 with gNBs (e.g., gNB 916) or ng-eNBs (e.g., ng-eNB 918). gNB 916 can connect to a 5G-enabled UE using a 5G NR interface. gNB 916 can connect to the 5G core via an NG interface, which may include an N2 interface or an N3 interface. ng-eNB 918 can also connect to the 5G core via an NG interface, but can connect to the UE via an LTE air interface. gNB 916 and ng-eNB 918 can connect to each other via an Xn interface.

[0110] In some embodiments, the NG interface can be divided into two parts: the NG user plane (NG-U) interface, which carries service data between the NG-RAN 914 node and the UPF 948 (e.g., the N3 interface); and the NG control plane (NG-C) interface, which is the signaling interface between the NG-RAN 914 node and the AMF 944 (e.g., the N2 interface).

[0111] NG-RAN 914 can provide a 5G-NR air interface with the following characteristics: variable SCS; CP-OFDM for DL, CP-OFDM and DFT-s-OFDM for UL; polar codes, repetition codes, simplex codes and Reed-Muller codes for control, and LDPC for data. Similar to the LTE air interface, the 5G-NR air interface can rely on CSI-RS and PDSCH / PDCCH DMRS. The 5G-NR air interface may not use CRS, but can use: PBCH DMRS for PBCH demodulation; PTRS for phase tracking of the PDSCH; and a tracking reference signal for time tracking. The 5G-NR air interface can operate on the FR1 band, including the sub-6GHz band, or the FR2 band, including the band from 24.25GHz to 52.6GHz. The 5G-NR air interface may include an SSB, which is a region of the downlink resource grid including PSS / SSS / PBCH.

[0112] In some embodiments, the 5G-NR air interface can utilize BWPs for various purposes. For example, BWPs can be used for dynamic adaptation of SCS. For instance, UE 902 can be configured with multiple BWPs, each configured with a different SCS. When a BWP is indicated to UE 902 for a change, the transmitted SCS also changes. Another example of a BWP use case relates to power saving. Specifically, multiple BWPs with different amounts of frequency resources (e.g., PRBs) can be configured for UE 902 to support data transmission under different traffic load scenarios. A BWP containing a smaller number of PRBs can be used for data transmission with low traffic loads, while allowing power saving at UE 902 and, in some cases, at gNB 916. A BWP containing a larger number of PRBs can be used for scenarios with high traffic loads.

[0113] RAN 904 is communicatively coupled to CN 920, which includes network elements, to provide various functions to support data and telecommunications services for customers / subscribers (e.g., users of UE 902). Components of CN 920 can be implemented in a single physical node or in separate physical nodes. In some embodiments, NFV can be utilized to virtualize any or all functions provided by the network elements of CN 920 onto physical computing / storage resources such as servers and switches. A logical instantiation of CN 920 can be referred to as a network slice, while a logical instantiation of a portion of CN 920 can be referred to as a network subslice.

[0114] In some embodiments, CN 920 may be an LTE CN 922, which may also be referred to as an EPC. The LTE CN 922 may include an MME 924, an SGW 926, an SGSN 928, an HSS 930, a PGW 932, and a PCRF 934, which are coupled to each other via an interface (or “reference point”), as shown in the figure. The functions of the components of the LTE CN 922 can be briefly described below.

[0115] MME 924 enables mobility management functions to track the current location of UE 902, facilitating paging, bearer activation / deactivation, handover, gateway selection, authentication, and more.

[0116] The SGW 926 can terminate the S1 interface toward the RAN and route data packets between the RAN and the LTE CN 922. The SGW 926 can serve as a local mobility anchor for handover between RAN nodes and can also provide anchoring for inter-3GPP mobility. Other responsibilities may include lawful interception, charging, and some policy enforcement.

[0117] The SGSN 928 can track the location of UE 902 and perform security functions and access control. Furthermore, the SGSN 928 can perform EPC inter-node signaling for mobility between different RAT networks; PDN and S-GW selection specified by the MME 924; MME selection for handover; etc. The S3 reference point between the MME 924 and the SGSN 928 enables the exchange of user and bearer information for 3GPP indirect access mobility in idle / active states.

[0118] The HSS 930 may include a database for network users (containing subscription-related information) to support network entities in handling communication sessions. The HSS 930 can provide support for routing / roaming, authentication, authorization, naming / addressing resolution, location dependencies, etc. The S6a reference point between the HSS 930 and the MME 924 enables the transmission of subscription and authentication data for authenticating / authorizing user access to the LTE CN 920.

[0119] The PGW 932 can terminate its SGi interface toward a data network (DN) 936, which may include an application / content server 938. The PGW 932 can route data packets between the LTE CN 922 and the data network 936. The PGW 932 can be coupled to the SGW 926 via an S5 reference point to facilitate user plane tunneling and tunnel management. The PGW 932 may also include nodes for policy enforcement and charging data collection (e.g., PCEF). Furthermore, the SGi reference point between the PGW 932 and the data network 936 can be an external public, private PDN, or an internal packet data network (e.g., for IMS service allocation). The PGW 932 can be coupled to the PCRF 934 via a Gx reference point.

[0120] PCRF 934 is the policy and charging control element of LTE CN 922. PCRF 934 can be communicatively coupled to application / content server 938 to determine appropriate QoS and charging parameters for service flows. PCRF 932 can assign association rules (via Gx reference point) to PCEF using appropriate TFTs and QCIs.

[0121] In some embodiments, CN 920 may be 5GC 940. 5GC 940 may include AUSF 942, AMF 944, SMF 946, UPF 948, NSSF 950, NEF 952, NRF 954, PCF 956, UDM 958, and AF 960, which are coupled to each other via interfaces (or "reference points"), as shown in the figure. The functionality of the components in 5GC 940 can be briefly described below.

[0122] The AUSF 942 can store data for UE 902 authentication and handle authentication-related functions. The AUSF 942 facilitates a universal authentication framework for various access types. In addition to communicating with other components of the 5GC 940 via a reference point, as shown, the AUSF 942 can also demonstrate an interface based on Nausf services.

[0123] The AMF 944 allows other functions of the 5GC 940 to communicate with UE 902 and RAN 904 and subscribe to notifications regarding mobility events for UE 902. The AMF 944 can handle registration management (e.g., for registering UE 902), connection management, reachability management, mobility management, lawful interception of AMF-related events, and access authentication and authorization. The AMF 944 can provide transport for SM messages between UE 902 and SMF 946 and act as a transparent broker for routing SM messages. The AMF 944 can also provide transport for SMS messages between UE 902 and the SMSF. The AMF 944 can interact with AMF 942 and UE 902 to perform various security anchoring and context management functions. Furthermore, the AMF 944 can be the termination point of the RAN CP interface, which may include or be the N2 reference point between the RAN 904 and the AMF 944; and the AMF 944 can be the termination point of NAS (N1) signaling, performing NAS encryption and integrity protection. The AMF 944 can also support NAS signaling with the UE 902 via the N3 IWF interface.

[0124] SMF 946 can be responsible for SM (e.g., session establishment and tunnel management between UPF 948 and AN 908); UE IP address allocation and management (including optional authorization); selection and control of UP functions; configuring service bootstrapping at UPF 948 to route services to the correct destination; terminating the interface for policy control functions; controlling policy enforcement, accounting, and QoS as part of the process; lawful interception (for SM events and interfaces to the LI system); terminating the SM portion of NAS messages; downlink data notification; initiating AN-specific SM information sent to AN 908 on N2 via AMF 944; and determining the SSC mode of the session. SM can refer to the management of the PDU session, while a PDU session or “session” can refer to the PDU connectivity service that provides or enables the exchange of PDUs between UE 902 and data network 936.

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

[0126] The NSSF 950 can select a set of network slice instances to serve UE 902. If needed, the NSSF 950 can also determine the allowed NSSAIs and the mapping to subscribed S-NSSAIs. The NSSF 950 can also, based on appropriate configuration and possibly by querying the NRF 954, determine the set of AMFs or a list of candidate AMFs to serve UE 902. The selection of a set of network slice instances for UE 902 can be triggered by the AMF 944 to which UE 902 is registered, through interaction with the NSSF 950, which may result in a change of AMF. The NSSF 950 can interact with AMF 944 via reference point N22; and can communicate with another NSSF in the visited network via reference point N31 (not shown). Furthermore, the NSSF 950 can expose an interface based on NNSSF services.

[0127] The NEF 952 can securely expose services and capabilities provided by 3GPP network functions to third parties, internal open / reopened systems, AFs (e.g., AF 960), edge computing, or fog computing systems. In these embodiments, the NEF 952 can authenticate, authorize, or restrict AFs. The NEF 952 can also translate information exchanged with AF 960 and information exchanged with internal network functions. For example, the NEF 952 can translate between AF service identifiers and internal 5GC information. The NEF 952 can also receive information from other NFs based on the capabilities of other open NFs. This information can be stored as structured data at the NEF 952 or stored at a data storage NF using a standardized interface. The stored information can then be reopened by the NEF 952 to other NFs and AFs, or used for other purposes (e.g., analysis). Furthermore, the NEF 952 can expose interfaces based on Nnef services.

[0128] NRF 954 supports service discovery, receiving NF discovery requests from NF instances and providing information about discovered NF instances to those instances. NRF 954 also maintains information about available NF instances and the services they support. As used herein, the terms "instantiate," "instantiation," etc., can refer to the creation of an instance, and "instance" can refer to the concrete occurrence of an object (which may occur, for example, during the execution of program code). Furthermore, NRF 954 can demonstrate interfaces based on NRF services.

[0129] PCF 956 can provide policy rules to control plane functions for enforcement and can also support a unified policy framework for governing network behavior. PCF 956 can also implement a front-end to access subscription information related to policy decisions in the UDR of UDM 958. In addition to communicating with functions via reference points as shown, PCF 956 also demonstrates an interface based on Npcf services.

[0130] The UDM 958 can process subscription-related information to support network entities in handling communication sessions and can store subscription data for UE 902. For example, subscription data can be passed via the N8 reference point between the UDM 958 and AMF 944. The UDM 958 can include two parts: an application front-end and a UDR. The UDR can store subscription and policy data for the UDM 958 and PCF 956, and / or structured data for open access and application data for NEF 952 (including PFDs for application detection and application request information for multiple UE 902s). The UDR 221 can expose a Nudr-based service interface to allow the UDM 958, PCF 956, and NEF 952 to access a specific 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 can include a UDM-FE, which handles credential processing, location management, subscription management, etc. Several different front-ends can serve the same user in different transactions. The UDM-FE accesses subscription information stored in the UDR and performs authentication credential processing, user identity processing, access authorization, registration / mobility management, and subscription management. In addition to communicating with other NFs via reference points as shown, the UDM 958 can also demonstrate interfaces based on Nudm services.

[0131] The AF 960 can provide application impact on service routing, provide access to NEF, and interact with the policy framework for policy control.

[0132] In some embodiments, the 5GC 940 can implement edge computing by selecting operator / third-party services as geographically proximate points where UE 902 attaches to the network. This reduces latency and load on the network. To provide edge computing implementation, the 5GC 940 can select a UPF 948 proximate to UE 902 and perform service routing from the UPF 948 to the data network 936 via the N6 interface. This can be based on UE subscription data, UE location, and information provided by the AF 960. In this way, the AF 960 can influence UPF (re)selection and service routing. Based on operator deployment, when the AF 960 is considered a trusted entity, the network operator can allow the AF 960 to interact directly with the relevant NF. Furthermore, the AF 960 can expose interfaces based on Naf services.

[0133] Data network 936 can refer to various network operator services, Internet access, or third-party services that can be provided by one or more servers (including, for example, application / content server 938).

[0134] Figure 10 A wireless network 1000 according to various embodiments is schematically illustrated. The wireless network 1000 may include a UE 1002, which wirelessly communicates with an AN 1004. The UE 1002 and AN 1004 may be similar to and substantially interchangeable with components of the same name described elsewhere herein.

[0135] UE 1002 can be communicatively coupled to AN 1004 via connection 1006. Connection 1006 is shown as an air interface for communication coupling and can conform to cellular communication protocols (e.g., LTE protocol or 5G NR protocol operating at mmWave or sub-6GHz frequencies).

[0136] UE 1002 may include a host platform 1008, which is coupled to a modem platform 1010. Host platform 1008 may include application processing circuitry 1012, which may be coupled to protocol processing circuitry 1014 of modem platform 1010. Application processing circuitry 1012 may run various applications for giving / receiving application data for UE 1002. Application processing circuitry 1012 may also implement one or more layer operations to send / receive application data to / from a data network. These layer operations may include transport (e.g., UDP) and Internet (e.g., IP) operations.

[0137] Protocol processing circuitry 1014 can implement one or more layer operations to facilitate the transmission or reception of data via connection 1006. Layer operations implemented by protocol processing circuitry 1014 may include, for example, MAC, RLC, PDCP, RRC, and NAS operations.

[0138] The modem platform 1010 may also include a digital baseband circuit 1016, which can implement one or more layer operations as "lower" layer operations performed by the protocol processing circuit 1014 in the network protocol stack. These operations may include, for example, PHY operations, including one or more of the following: HARQ-ACK function, scrambling / descrambling, encoding / 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, blind decoding of control channel signals, and other related functions.

[0139] The modem platform 1010 may also include transmitting circuitry 1018, receiving circuitry 1020, RF circuitry 1022, and RF front-end (RFFE) 1024, which may include or be connected to one or more antenna panels 1026. In short, transmitting circuitry 1018 may include a digital-to-analog converter, mixer, intermediate frequency (IF) component, etc.; receiving circuitry 1020 may include an analog-to-digital converter, mixer, IF component, etc.; RF circuitry 1022 may include a low-noise amplifier, power amplifier, power tracking component, etc.; RFFE 1024 may include filters (e.g., surface acoustic wave filters), switches, antenna tuners, beamforming components (e.g., phased array antenna components), etc. The selection and arrangement of components (generally referred to as "transmit / receive components") of the transmitting circuit 1018, receiving circuit 1020, RF circuit 1022, RFFE 1024, and antenna panel 1026 can be specific to implementation details (e.g., whether the communication is time division multiplexing (TDM) or frequency division multiplexing (FDM), in mmWave or sub-6 GHz frequency, etc.). In some embodiments, the transmit / receive components can be arranged in multiple parallel transmit / receive chains, can be located in the same or different chips / modules, etc.

[0140] In some embodiments, the protocol processing circuit 1014 may include one or more instances of control circuitry (not shown) to provide control functions for the transmitting / receiving components.

[0141] UE reception can be established via and through antenna panel 1026, RFFE 1024, RF circuit 1022, receiving circuit 1020, digital baseband circuit 1016, and protocol processing circuit 1014. In some embodiments, antenna panel 1026 can receive transmissions from AN 1004 via receive beamforming signals received by a plurality of antennas / antenna elements of one or more antenna panels 1026.

[0142] UE transmission can be established via and through protocol processing circuitry 1014, digital baseband circuitry 1016, transmission circuitry 1018, RF circuitry 1022, RFFE 1024, and antenna panel 1026. In some embodiments, the transmission components of UE 1004 may apply a spatial filter to the data to be transmitted to form a transmission beam emitted by the antenna elements of antenna panel 1026.

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

[0144] Figure 11 This is a block diagram illustrating components according to some example embodiments, which are capable of reading instructions from a machine-readable or computer-readable medium (e.g., a non-transitory machine-readable storage medium) and performing any or more methods discussed herein. Specifically, Figure 11 The diagram illustrates hardware resource 1100, which includes 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 bus 1140 or other interface circuitry. In embodiments utilizing node virtualization (e.g., NFV), a hypervisor 1102 may be executed to provide an execution environment for one or more network slices / subslices to utilize hardware resource 1100.

[0145] 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., a baseband processor), an ASIC, an FPGA, a radio frequency integrated circuit (RFIC), another processor (including those discussed herein), or any suitable combination thereof.

[0146] The memory / storage device 1120 may include main memory, disk storage, or any suitable combination thereof. The memory / storage device 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.).

[0147] Communication resource 1130 may include an interconnect or network interface controller, component, or other suitable device for communicating with one or more peripheral devices 1104 or one or more databases 1106 or other network elements via network 1108. For example, communication resource 1130 may include wired communication components (e.g., for coupling via USB, Ethernet, etc.), cellular communication components, NFC components, etc. (or low power consumption) ) components, Components and other communication components.

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

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

[0150] Implementation process :

[0151] Figure 12 A process 1200 according to an embodiment is illustrated. In operation 1202, the process includes: encoding a message for a user equipment (UE) indicating a repetition count for a physical downlink control channel (PDCCH) carrying downlink control information (DCI). In operation 1204, the process includes: sending the message to communication resources of a gNB for transmission to the UE.

[0152] Figure 13 The process 1300 according to an embodiment is illustrated. In operation 1302, the process includes: decoding a message from an NR node B (gNB) indicating a duplicate count for the Physical Downlink Control Channel (PDCCH) used to carry downlink control information (DCI). In operation 1304, the process includes: determining the duplicate count from the message.

[0153] Example:

[0154] Example 1 includes: an apparatus for a New Radio (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 being configured to implement the instructions to: decode 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 determine the repetition count from the message.

[0155] Example 2 includes the subject matter as described in Example 1, wherein the one or more processors are configured to: decode the PDCCH based on the repetition count.

[0156] Example 3 includes a subject as described in Example 1, wherein a repetition count of 1 indicates no repetitions, while a repetition count greater than 1 indicates the number of repetitions corresponding to the repetition count.

[0157] Example 4 includes a subject as described in Example 1, wherein the message includes a Radio Resource Control (RRC) message when the repetition count is greater than 1, and includes a DCI message when the repetition count is 1.

[0158] Example 5 includes: a subject as described in any one of Examples 1-4, wherein the one or more processors are configured to: determine the starting position of downlink communication to the UE based on the repetition count.

[0159] Example 6 includes the subject matter as described in Example 5, wherein the downlink communication is either a Physical Downlink Shared Channel (PDSCH) or a Hybrid Automatic Repeat Request (HARQ) in a dynamic codebook.

[0160] Example 7 includes the subject matter as described in Example 5, wherein the one or more processors are configured to: determine the processing time for the downlink communication based on the repetition count.

[0161] Example 8 includes a subject as described in Example 5, wherein the starting position corresponds to a symbol number or a time slot number.

[0162] Example 9 includes a subject as described in Example 1, wherein the message includes an indication of a merged value corresponding to repetition information for the DCI, the repetition information including repetition information pairs, each repetition information pair including a set of synchronization signals and a monitoring timing, these pairs being different from each other, each pair corresponding to a repetition instance of the DCI.

[0163] Example 10 includes a subject as described in Example 9, wherein the merged value provides an indication of the number of repeated transmit-receive points (TRPs).

[0164] Example 11 includes the subject matter as described in Example 9, wherein the one or more processors are configured to: implement fixed rules to determine the timing of monitoring for downlink communication to the UE based on the merged value.

[0165] Example 12 includes a subject as described in any one of Examples 1-4 and 9-11, and further includes communication resources coupled to the one or more processors to communicate with the gNB.

[0166] Example 13 includes: a method for performing at an apparatus in a New Radio (NR) Node B (gNB), the method comprising: encoding a message for a User Equipment (UE), the message indicating a repetition count of a Physical Downlink Control Channel (PDCCH) for carrying downlink control information (DCI); and sending the message to communication resources of the gNB for transmission to the UE.

[0167] Example 14 includes a subject as described in Example 13, wherein a repetition count of 1 indicates no repetitions, while a repetition count greater than 1 indicates the number of repetitions corresponding to the repetition count.

[0168] Example 15 includes a subject as described in Example 13, wherein the message includes a Radio Resource Control (RRC) message when the repetition count is greater than 1, and includes a DCI message when the repetition count is 1.

[0169] Example 16 includes a subject as described in any one of Examples 13-15, wherein the repetition count corresponds to the starting position of downlink communication to the UE based on the repetition count.

[0170] Example 17 includes the subject matter as described in Example 16, wherein the downlink communication is either a Physical Downlink Shared Channel (PDSCH) or a Hybrid Automatic Repeat Request (HARQ) in a dynamic codebook.

[0171] Example 18 includes a subject as described in Example 16, wherein the starting position corresponds to a symbol number or a time slot number.

[0172] Example 19 includes a subject as described in Example 13, wherein the message includes an indication of a merged value corresponding to repetition information for the DCI, the repetition information including repetition information pairs, each repetition information pair including a set of synchronization signals and a monitoring timing, these pairs being different from each other, each pair corresponding to a repetition instance of the DCI.

[0173] Example 20 includes a subject as described in Example 19, wherein the merged value provides an indication of the number of repeated transmit-receive points (TRPs).

[0174] Example 21 includes the subject matter as described in any one of Examples 13-15 and 19-20, and further includes communicating with the UE using the communication resources.

[0175] Example 22 includes: an apparatus for a New Radio 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 implementing the instructions to: encode a message for a User Equipment (UE), the message indicating a repetition count for a Physical Downlink Control Channel (PDCCH) carrying Downlink Control Information (DCI); and transmit the message to communication resources of the gNB for transmission to the UE.

[0176] Example 23 includes a subject as described in Example 22, wherein a repetition count of 1 indicates no repetitions, while a repetition count greater than 1 indicates the number of repetitions corresponding to the repetition count.

[0177] Example 24 includes a subject as described in Example 22, wherein the message includes a Radio Resource Control (RRC) message when the repetition count is greater than 1, and includes a DCI message when the repetition count is 1.

[0178] Example 25 includes a subject as described in any one of Examples 22-24, wherein the repetition count corresponds to the starting position of downlink communication to the UE based on the repetition count.

[0179] Example 26 includes the subject matter as described in Example 25, wherein the downlink communication is either a Physical Downlink Shared Channel (PDSCH) or a Hybrid Automatic Repeat Request (HARQ) in a dynamic codebook.

[0180] Example 27 includes a subject as described in Example 25, wherein the starting position corresponds to a symbol number or a time slot number.

[0181] Example 28 includes a subject as described in Example 22, wherein the message includes an indication of a merged value corresponding to repetition information for the DCI, the repetition information including repetition information pairs, each repetition information pair including a set of synchronization signals and a monitoring timing, these pairs being different from each other, each pair corresponding to a repetition instance of the DCI.

[0182] Example 29 includes a subject as described in Example 28, wherein the merged value provides an indication of the number of repeated transmit-receive points (TRPs).

[0183] Example 30 includes the subject matter as described in any one of Examples 22-24 and 28-29, and further includes the communication resource coupled to the one or more processors.

[0184] Example 31 includes: a method for execution at an apparatus of a New Radio (NR) User Equipment (UE), the method comprising: decoding a message from an NR Node B (gNB) indicating a repetition count of a Physical Downlink Control Channel (PDCCH) for carrying downlink control information (DCI); and determining the repetition count from the message.

[0185] Example 32 includes the subject as described in Example 31, and further includes decoding the PDCCH based on the repeat count.

[0186] Example 33 includes a subject as described in Example 31, wherein a repetition count of 1 indicates no repetitions, while a repetition count greater than 1 indicates the number of repetitions corresponding to the repetition count.

[0187] Example 34 includes a subject as described in Example 31, wherein the message includes a Radio Resource Control (RRC) message when the repetition count is greater than 1, and includes a DCI message when the repetition count is 1.

[0188] Example 35 includes a subject as described in any one of Examples 31-34, and further includes determining the starting position of downlink communication to the UE based on the repetition count.

[0189] Example 36 includes the subject matter as described in Example 35, wherein the downlink communication is either a Physical Downlink Shared Channel (PDSCH) or a Hybrid Automatic Repeat Request (HARQ) in a dynamic codebook.

[0190] Example 37 includes the subject matter as described in Example 35, and further includes determining the processing time for the downlink communication based on the repetition count.

[0191] Example 38 includes a subject as described in Example 35, wherein the starting position corresponds to a symbol number or a time slot number.

[0192] Example 39 includes a subject as described in Example 31, wherein the message includes an indication of a merged value corresponding to repetition information for the DCI, the repetition information including repetition information pairs, each repetition information pair including a set of synchronization signals and a monitoring timing, these pairs being different from each other, each pair corresponding to a repetition instance of the DCI.

[0193] Example 40 includes a subject as described in Example 39, wherein the merged value provides an indication of the number of repeated transmit-receive points (TRPs).

[0194] Example 41 includes the subject matter as described in Example 39, and further includes: implementing fixed rules to determine the timing of monitoring for downlink communication to the UE based on the merged value.

[0195] Example 42 includes the subject matter as described in any one of Examples 31-34 and 39-41, and further includes communicating with the gNB using the communication resources of the UE.

[0196] Example 43 includes: a machine-readable medium comprising code that, when executed, causes the machine to perform a subject as described in any one of Examples 13-21 and 31-42.

[0197] Example 44 includes: an apparatus comprising components for performing the subject matter as described in any one of Examples 13-21 and 31-42.

[0198] Example 1A may include a method for repeating PDCCH from multiple TRPs.

[0199] Example 2A may include: the method described in Example 1A or some other examples herein, wherein one or more of the following repetition types are supported: inter-CORESET repetition for repetition across TRP; intra-CORESET repetition with repetition across SS sets; intra-CORESET repetition with repetition across MO.

[0200] Example 3A may include: the method described in Example 2A or some other examples herein, wherein the UE is configured such that it can anticipate DCI repetition from any of the above combinations.

[0201] Example 4A may include the method described in Example 2A or some other examples herein, wherein across the two PDCCHs to be merged, MO is implicit (same MO), time slot is implicit (same time slot), DCI is implicit (common DCI across SS sets only), AL is implicit (common AL only), and candidate is implicit (common candidate only).

[0202] Example 5A may include: the method described in Example 2A or some other examples herein, wherein the UE is indicated for repeating SS sets, MOs, slots, DCIs, and candidates.

[0203] Example 6A may include: the method described in Example 2A or some other examples herein, wherein, for soft merging, candidate m of SS-1 / AL4 may be merged with candidate m of SS-2 / AL4 to produce a joint encoded AL8 (ordered by TRP-0 then TRP-1) or a repetition of AL4.

[0204] Example 7A may include: the method described in Example 2A or some other examples herein, wherein, for soft merging, candidate m of SS-1 / AL4 may be merged with all candidates of SS-2 / AL4 to produce a jointly encoded AL8 (sorted by TRP-0 then TRP-1) or a repetition of AL4.

[0205] Example 8A may include: a method comprising: receiving configuration information for a CORESET; and monitoring DCI with repetition based on the CORESET under one or more of the following repetition modes: repetition between CORESETs across TRPs; repetition within a CORESET across SS sets; and / or repetition within a CORESET across MOs.

[0206] Example Z01 may include: an apparatus comprising one or more elements for performing the method described or associated with any of Examples 1-8, or any other method or process described herein.

[0207] Example Z02 may include: 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 methods described or associated with any of Examples 1-8, or any other methods or processes described herein.

[0208] Example Z03 may include: an apparatus comprising logic, modules, or circuitry including one or more elements for performing the methods described or associated with any of Examples 1-8, or any other methods or processes described herein.

[0209] Example Z04 may include: a method, technique or process described or associated with any of Examples 1-8 or any part thereof.

[0210] Example Z05 may include: an apparatus comprising: one or more processors; and 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 the methods, techniques, or processes described or associated with any one or more of Examples 1-8.

[0211] Example Z06 may include: a signal described or associated with any of Examples 1-8 or any part or portion thereof.

[0212] Example Z07 may include: a datagram, packet, frame, segment, protocol data unit (PDU) or message described or associated with any of Examples 1-8 or in part or in part thereof, or otherwise described in this disclosure.

[0213] Example Z08 may include: a signal encoded by data described or related to any of Examples 1-8 or any part thereof, or otherwise described in this disclosure.

[0214] Example Z09 may include: a signal encoded by a datagram, packet, frame, segment, protocol data unit (PDU) or message described or associated with any of Examples 1-8 or in part or in part of them, or otherwise described in this disclosure.

[0215] Example Z10 may include: an electromagnetic signal carrying computer-readable instructions, wherein one or more processors execute the computer-readable instructions to cause the one or more processors to perform the methods, techniques or processes described or related to any one or more of Examples 1-8.

[0216] Example Z11 may include: a computer program including instructions, wherein the processing element executes the program to cause the processing element to perform the methods, techniques or processes described or related to any one or a portion of Examples 1-8.

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

[0218] Example Z13 may include: a method for communicating in a wireless network as shown and described herein.

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

[0220] Example Z15 may include: a device for providing wireless communication as shown and described herein.

[0221] Unless otherwise expressly stated, any of the foregoing examples may be combined with any other example (or combination of examples). The foregoing description of one or more implementations is illustrative and descriptive, but is not intended to be exhaustive or to limit the scope of the embodiments to the precise forms disclosed. Modifications and variations are possible in light of the foregoing teachings, or may be obtained from practice with various embodiments.

Claims

1. An apparatus for a new air interface (NR) user equipment, the apparatus comprising processing circuitry and a radio frequency (RF) interface coupled to the processing circuitry, the processing circuitry being configured to: In a time slot, monitor the first PDCCH candidate m carrying the first downlink control information (DCI) in the first search space (SS) of the first control resource set (CORESET) and the second PDCCH candidate m carrying the second DCI in the second SS of the second CORESET, wherein, The first DCI carried by the first PDCCH candidate and the second DCI carried by the second PDCCH candidate are duplicates of each other; as well as Decode the first DCI and the second DCI.

2. The apparatus according to claim 1, wherein the processing circuit is used for: Decode the first configuration information corresponding to the first CORESET; Decode the second configuration information corresponding to the second CORESET; and Based on the first configuration information and the second configuration information, monitor the first PDCCH candidate and the second PDCCH candidate.

3. The apparatus according to any one of claims 1-2, wherein, The first PDCCH candidate and the second PDCCH candidate have the same aggregation level L.

4. The apparatus according to any one of claims 1-2, wherein, The first CORESET and the second CORESET are associated with the first Transport Configuration Indicator (TCI) and the second TCI state, respectively.

Images