TWI729354B

TWI729354B - 行動通訊之緊密下行鏈路控制資訊設計和操作

Info

Publication number: TWI729354B
Application number: TW108106490A
Authority: TW
Inventors: 穆罕默德阿利比艾勒馬利; 拉哈文達瑪戴那哈里羅摩克里希那
Original assignee: 新加坡商聯發科技（新加坡）私人有限公司
Priority date: 2018-02-26
Filing date: 2019-02-26
Publication date: 2021-06-01
Also published as: CN110419256A; TW201937953A; WO2019161804A1; US20190268207A1

Abstract

描述了關於行動通訊中的用戶設備和網路裝置的緊密下行鏈路控制資訊（DCI）設計和操作的各種解決方案。一裝置可以確定在第一子載波間隔（subcarrier spacing，SCS）上支援緊密DCI。該裝置可以在第一SCS上監視緊密DCI。該裝置在執行高可靠性服務時可以利用控制通道中的緊密DCI。

Description

行動通訊之緊密下行鏈路控制資訊設計和操作

本公開總體上關於行動通訊，更具體地，關於行動通訊中用戶設備(user equipment，UE)和網路裝置之緊密(compact)下行鏈路控制資訊(downlink control information，DCI)設計和操作。

除非在本文中另外指示，否則本部分中描述的方法不是對於下面列出申請專利範圍的現有技術，並且不因包含在該部分中而被承認是現有技術。

在新無線電(New Radio，NR)中，對於端到端延遲和可靠性具有高要求的新興應用，支援超可靠和低延遲通訊(ultra-reliable and low latency communication，URLLC)。一般的URLLC可靠性要求是大小為32位元組的封包應當以10^-5的成功概率在1毫秒的端到端延遲內傳輸。URLLC訊務通常較為零散且短，而對低延遲和高可靠性的要求較為嚴格。例如，URLLC的控制可靠性必須比10^-6 BLER的資料可靠性更加嚴格。

對於延遲敏感高的傳輸，正常DCI的一些欄位不適用或者沒有意義。DCI的可靠性取決於大小。在傳輸資源相同的情況下，DCI的大小越小，由於較低的編碼增益，可靠性越好。使用正常DCI來獲得相同的可靠性需要增加聚合級別(aggregation level)，如此具有的缺點是阻塞可能性(blocking probability)。此外，較小的頻寬部分(bandwidth part)可能無法適應更高的聚合級別。由於正常的DCI大小較大，並且對於URLLC控制傳輸其效率低，因而需要緊密的DCI設計。

可以預期將來有各種各樣的URLLC服務，每種服務針對不同的使用實例。因此，如何滿足嚴格的可靠性要求將成為新開發的通訊系統中的新問題。需要提供適當緊密的DCI設計和操作以減小DCI大小並提高控制信號傳輸的可靠性。

以下發明內容僅是例示性的，並且不旨在以任何方式限制。即，提供以下發明內容以引入這裡所描述的新穎且非明顯技術的概念、亮點、益處以及優點。下面詳細的描述中進一步描述了選擇的實現方式。因此，以下發明內容不旨在識別所要求保護主題之必要特徵，也不旨在用於確定所要求保護主題的範圍。

本公開的目的是提出解決方案或機制，以解決上述在行動通訊中關於用戶設備和網路裝置的緊密DCI設計和操作的上述問題。

在一個方面，一種方法可以涉及裝置確定在第一SCS上支援緊密DCI。該方法還可以涉及該裝置在第一SCS上監視緊密DCI。該方法還可以涉及該裝置使用控制通道中的緊密DCI來執行高可靠性服務。

在一個方面，一種裝置可以包括能夠與無線網路的網路節點無線通訊的收發器。該裝置還可以包括通訊地耦接到收發器的處理器。處理器能夠確定在第一SCS上支援緊密DCI。處理器還能夠在第一SCS上監視緊密DCI。處理器還能夠使用控制通道中的緊密DCI來執行高可靠性服務。

值得注意的是，儘管這裡提供的描述可以在某些無線電接入技術、網路和網路拓撲的背景下，例如長期演進(Long-Term Evolution，LTE)、LTE-A、LTE-A Pro、5G、新無線電(New Radio，NR)、物聯網(Internet-of-Things，IoT)和窄帶物聯網(Narrow Band Internet of Things，NB-IoT)，所提出的概念、方案及其任何變體/衍生物可以在、用於和通過其他類型的無線電接入技術、網路和網路拓撲實現。因此，本公開的範圍不限於本文描述的示例。

100、201~203、301~303、401~403、500、601~602、701~702、801~802:場景

910:通訊裝置

920:網路裝置

912、922:處理器

900:通訊系統

914、924:記憶體

916、926:收發器

1000:過程

1010、1020、1030:框

附圖被包括進來以提供對本公開之進一步理解，併入本發明並構成本公開之一部分。附圖例示了本公開之實現方式，並且與說明書一起用於說明本公開之原理。能理解的是，附圖不一定是按比例的，因為為了清楚地例示本發明之構思，一些元件可以被顯示為與實際實現方式中之尺寸不成比例。

第1圖示出了根據本公開的實現方式的方案下的示例性場景。

第2圖示出了根據本公開的實現方式的方案下的示例性場景。

第3圖示出了根據本公開的實現方式的方案下的示例性場景。

第4圖示出了根據本公開的實現方式的方案下的示例性場景。

第5圖示出了根據本公開的實現方式的方案下的示例性場景。

第6圖示出了根據本公開的實現方式的方案下的示例性場景。

第7圖示出了根據本公開的實現方式的方案下的示例性場景。

第8圖示出了根據本公開的實現方式的方案下的示例性場景。

第9圖示出了根據本公開的實現方式的示例通訊裝置和示例網路裝置。

第10圖示出了根據本公開的實現方式的示例過程的流程。

這裡公開了所要求保護主題內容的詳細實施例和實現方式。然而，應當理解，公開的詳細實施例和實現方式僅為了示例體現為各種形式的所要求保護的主題內容。然而本公開可以體現為多種不同形式，不應理解為僅限於示例的實施例和實現方式。提供這些示例的實施例和實現方式以使得本公開的描述全面且完整並且能夠向本領域具有通常知識者全面傳遞本公開的範圍。在下面之描述中，省略了已知特徵和技術的細節，以避免不必要地使得本發明的實施例和實現方式變得模糊。

概述：本公開的實現方式涉及與行動通訊中用戶設備和網路裝置的緊密DCI設計和操作有關的各種技術、方法、方案和/或解決方案。根據本公開，可以單獨地或聯合地實現許多可能的解決方案。也就是說，儘管可以在下面分別描述這些可能的解決方案，但是這些可能的解決方案中的兩個或更多個可以以一種組合或另一種組合的方式實現。

在NR中，對於端到端延遲和可靠性具有高要求的新興應用，支援URLLC。一般的URLLC可靠性要求是大小為32位元組的封包應當以10^-5的成功概率在1毫秒的端到端延遲內傳輸。URLLC訊務通常較為零散且短，而對低延遲和高可靠性的要求較為嚴格。例如，URLLC的控制可靠性必須比高達10^-6 BLER的資料可靠性更加嚴格。

對於延遲敏感性高的傳輸，正常DCI的一些欄位不適用或者沒有意義。DCI的可靠性取決於大小。在傳輸資源相同的情況下，DCI的大小越小，由於較低的編碼增益，可靠性越好。使用正常DCI來獲得相同的可靠性需要增加聚合級別(aggregation level)，如此具有的缺點是阻塞可能性(blocking probability)。此外，較小的頻寬部分(bandwidth part)可能無法適應更高的聚合級別。由於正常的DCI大小較大，並且對於URLLC控制傳輸其效率低，因而需要緊密的DCI設計。

鑒於以上所述，本公開提出了關於用戶設備(UE)和網路裝置的緊密DCI設計和操作的多種方案。根據本公開的方案，可以定義用於URLLC的緊密DCI格式並將其用於URLLC服務。緊密DCI的位元欄位可以被精心設計以減小DCI的大小。用於URLLC的緊密DCI設計可以提高控制通道的可靠性。這種設計還可以減少對更高聚合級別的需求以滿足可靠性，從而降低了阻塞可能性。

緊密DCI可以添加需要由UE監視的DCI格式。這可以增加UE處盲解碼的數量。為了控制UE複雜性，對UE在指定時間段(例如，搜索空間或時槽持續時間等)內應執行的盲解碼的數量通常存在限制。對盲解碼數量的限制可以取決於操作設置，例如子載波間隔(subcarrier spacing，SCS)。第1圖示出了根據本公開的實現方式的方案下的示例場景100。場景100涉及UE和網路裝置，場景100可以是無線通訊網路(例如，LTE網路、LTE-A網路、LTE-A Pro網路、5G網路、NR網路、IoT網路或NB-IoT網路)的一部分。第1圖示出了針對不同SCS對每個時槽的物理下行鏈路控制通道(physical downlink control channel，PDCCH)盲解碼的最大數量的限制的示例表。如圖所示，較高的SCS對盲解碼的數量的限制較低。因此，在較大SCS時監視具有不同大小的多個DCI是不可行的。另一方面，可能的傳輸/重傳次數可以取決於SCS。利用15kHz SCS，網路裝置可能在延遲時間限制內沒有機會進行重傳，因為較大的符號持續時間會增加延遲時間。因此，具有可靠的PDCCH(例如，通過緊密的DCI設計)是重要的。對於30kHz、60kHz或120kHz SCS，在延遲時間限制內有更多機會進行重傳。因此，與較小的SCS相比，可以放寬PDCCH的可靠性。

第2圖示出了根據本公開的實現方式的方案下的示例性場景201、202和203。場景201、202和203涉及UE和網路裝置，其可以是無線通訊網路 (例如，LTE網路、LTE-A網路、LTE-A Pro網路、5G網路、NR網路、IoT網路或NB-IoT網路)的一部分。鑒於在盲解碼的數量和延遲時間限制內可能的重傳次數的限制方面可能SCS之間的差異，緊密DCI設計和/或操作應該是依賴於SCS。具體地，可以僅針對某些特定SCS支援緊密DCI。例如，在場景201中，可以僅針對15kHz SCS支援緊密DCI，並且在其他SCS(例如，30kHz，60kHz和120kHz)中可以不支援緊密DCI。在場景202中，可以僅針對15kHz和30kHz SCS支援緊密DCI，並且其他SCS(例如，60kHz和120kHz)可以不支援緊密DCI。在場景203中，可以僅針對15kHz、30kHz和60kHz SCS支援緊密DCI，並且其他SCS(例如，120kHz或更高SCS)可以不支援緊密DCI。

第3圖示出了根據本公開的實現方式的方案下的示例性場景301、302和303。場景301、302和303涉及UE和網路裝置，其可以是無線通訊網路(例如，LTE網路、LTE-A網路、LTE-A Pro網路、5G網路、NR網路、IoT網路或NB-IoT網路)的一部分。可以限制在特定SCS上對緊密DCI的監視。當UE被配置為監視緊密DCI時，可以在UE應當監視的其他DCI格式上配置一些限制。

具體地，不期望UE在某些SCS的同一監視時機內監視緊密DCI和正常DCI兩者，以滿足盲解碼次數的預算。正常DCI可以包括，例如但不限於，DCI格式0_1和DCI格式1_1。UE可以被配置為確定在第一SCS上是否支援緊密DCI。在第一SCS上支援緊密DCI的情況下，UE可以被配置為在第一SCS上監視緊密DCI。UE可以在第一SCS上監視緊密DCI和正常DCI兩者。因此，UE可以被配置為在執行高可靠性服務(例如，URLLC)時在控制通道(例如，PDCCH)中使用緊密DCI。另外，UE可以被配置為確定在第二SCS上是否支援緊密DCI。第一SCS可以小於第二SCS。當在第二SCS上不支援緊密DCI的情況下，UE可以被配置為取消對第二SCS上緊密DCI和正常DCI兩者的監視。UE可以被配置為在第二SCS上不監視緊密DCI並且僅監視正常DCI，以減少盲解碼的數量。

例如，在場景301中，僅僅對於15kHz SCS，支援緊密DCI。UE可以被配置為僅針對15kHz SCS監視緊密DCI和正常DCI。對於30kHz、60kHz和120kHz SCS，UE可以不監視緊密DCI而僅監視正常DCI。在場景302中，UE可以被配置為僅針對15kHz和30kHz SCS，監視緊密DCI和正常DCI。在場景303中，UE可以被配置為僅針對15kHz、30kHz和60kHz SCS監視緊密DCI和正常DCI。

第4圖示出了根據本公開的實現方式的方案下的示例性場景401、402和403。場景401、402和403涉及UE和網路裝置，其可以是無線通訊網路(例如，LTE網路、LTE-A網路、LTE-A Pro網路、5G網路、NR網路、IoT網路或NB-IoT網路)的一部分。緊密DCI的大小可取決於SCS。UE可以被配置為根據SCS(例如，第一SCS或第二SCS)確定緊密DCI大小。例如，在場景401中，對於15kHz SCS，緊密DCI大小可以與其他DCI格式不同。其他DCI格式可以包括，例如但不限於，回退(fallback)DCI(例如，DCI格式0_0或DCI格式1_0)和正常DCI(例如，DCI格式0_1或DCI格式1_1)。對於SCS>15kHz，緊密DCI可以與回退DCI大小或正常DCI大小相同。可以使用一些顯式或隱式方法來識別具有相同大小的DCI格式。在場景402中，對於15kHz和30kHz SCS，緊密DCI大小可以與其他DCI格式不同。對於60kHz和120kHz SCS，緊密DCI可以與回退DCI大小或的正常DCI大小相同。在場景403中，對於15kHz、30kHz和60kHz SCS，緊密DCI大小可以與其他DCI格式不同。對於120kHz SCS，緊密DCI可以與回退DCI大小或正常DCI大小相同。

在一些實現方式中，DCI大小的增加會影響控制通道的可靠性。不同的DCI大小會增加DCI格式並因此增加盲解碼的數量。因此，根據本公開的實現方式，緊密DCI可以被配置為具有固定大小，而與有效(active)頻寬部分(bandwidth part，BWP)無關。固定的緊密DCI大小要求頻域資源分配(frequency domain resource allocation，FD-RA)欄位具有固定數量的位元，而與BWP大小無關。因此，可以為FD-RA配置固定解譯(interpretation)並將其應用於所有BWP。例如，'N'可以表示FD-RA所需的位元數。N可以被定義為在第三代合作夥伴計畫(3rd Generation Partnership Project，3GPP)規範中是固定的或者由高層配置(例如，無線電資源控制(radio resource control，RRC)配置)配置。'B'可以表示基於資源塊(resource block，RB)的BWP。FD-RA的粒度(granularity)可以定義為(N，B)的函數，使得Granularity=f(N,B)。UE可以被配置為根據基於BWP的選擇(例如，B)和FD-RA所需的位元數(例如，N)的函數，確定RB粒度。對於較小的BWP，用於分配的RB粒度可以被確定為單個RB。對於較大的BWP，用於分配的RB粒度可以被確定為多個RB。因此，基於數位學(numerology)的緊密DCI設計和操作能夠減少UE處的盲解碼的數量。固定的緊密DCI大小(不管BWP如何)能夠減小DCI大小並提高可靠性。

在一些實現方式中，可針對緊密DCI減少若干位元欄位。一些DCI欄位的大小可以取決於SCS。這樣的DCI欄位可以包括，例如但不限於，冗餘版本(redundancy version，RV)索引欄位、混合自動重傳請求(hybrid automatic repeat request，HARQ)進程的最大數量、下行鏈路指配索引、物理上行鏈路控制通道(physical uplink control channel，PUCCH)資源、或者物理下行鏈路共用通道(physical downlink shared channel，PDSCH)-HARQ定時指示符。緊密DCI的一些或所有條目的位元欄位的大小可以是固定的。例如，可以在3GPP規範中定義位元欄位。或者，緊密DCI的位元欄位也可以通過高層信令(例如，RRC信令)或通過層1(L1)信令來配置。

在一些實現方式中，在較小SCS(例如，第一SCS)上DCI的RV索引欄位可以包括比更大SCS(例如，第二SCS)更少的位元。具體地，對於較大的SCS，存在更多的傳輸機會，因此可以放寬每次傳輸的目標BLER並且可以使用更高的碼率。在這種情況下，可以通過使用增量冗餘(incremental redundancy，IR)組合來實現增益，因此需要用於每次傳輸/重傳的不同RV版本。因此，可以將更多位元分配給DCI中的RV索引欄位。對於較小的SCS，傳輸機會較少，並且目標BLER可能非常小，因此會選擇較低的碼率。在這種情況下，從IR組合無法獲得增益或餘量(margin)。因此，不需要更多RV版本。可以將較少的位元分配給DCI中的RV索引欄位。

在一些實現方式中，在較小SCS(例如，第一SCS)上HARQ進程的最大數量可以小於較大SCS(例如，第二SCS)。具體地，HARQ進程的總/最大數量可以取決於在傳輸的往返時間(round trip time，RTT)內可以支援多少個並行的HARQ進程。RTT可以被定義為下行鏈路(downlink，DL)PDSCH傳輸與HARQ回饋之間的時間。RTT可以至少取決於用於PDSCH解碼的UE處理時間(例如，N1)，其是SCS的函數。第5圖示出了根據本公開的實現方式的方案下的示例場景500。對於較大的RTT，可以支援更多的HARQ進程。因此，可以分配更多位元來表示HARQ進程的數量。對於較短的RTT，可以支援較少的HARQ過程。因此，可以分配較少的位元來表示HARQ進程的數量。因此，與較大的SCS相比，對於較小的SCS，HARQ過程的總/最大數量可以更少。

在一些實現方式中，與較大的SCS(例如，第二SCS)相比，在較小SCS(例如，第一SCS)上的下行鏈路指配索引(downlink assignment index，DAI)可以包括更少的位元。具體地，下行鏈路指配索引可以用於累積先前傳輸的HARQ回饋位元，該HARQ回饋位元在單個上行鏈路(UL)PUCCH傳輸中通過碼本(codebook)傳輸。第6圖示出了根據本公開的實現方式的方案下的示例場景601和602。對於較大的SCS，如場景601所示，網路裝置可以具有更多的傳輸機會。網路裝置可以將UE配置為累積在單個/少數PUCCH資源中傳輸的HARQ回饋位元。因此，較大的SCS需要下行鏈路指配索引中更多位元，以便為網路裝置在處理HARQ回饋位元時提供更大的靈活性。對於較小的SCS，如場景602中所示，由於延遲時間限制，網路裝置不將UE配置為累積先前傳輸上的HARQ回饋位元，因此需要非常少的位元來表示下行鏈路指配索引。

在一些實現方式中，在較大SCS(例如，第二SCS)上配置的PUCCH資源小於較小SCS(例如，第一SCS)。具體地，由於傳輸機會的數量隨著SCS而增加，網路裝置可以更靈活地為較大的SCS分配PUCCH資源。第7圖示出了根據本公開的實現方式的方案下的示例場景701和702。對於較大的SCS，如場景701所示，每個UL時槽需要較少的PUCCH資源，因為網路裝置在未來UL時槽中分配資源時具有靈活性並且仍然可以滿足延遲時間限制。網路裝置可以具有更多的UL機會來分配PUCCH資源，因此可以縮短PUCCH資源指示符欄位。因此，對於較高的SCS可以配置較少的資源，以便減少PUCCH資源指示符的位元數。對於較小的SCS，如場景702所示，在UL時槽中可能需要更多的PUCCH資源，因為由於延遲時間限制，回饋機會較少。網路裝置具有較少的UL機會來分配PUCCH資源，因此可以配置更多的PUCCH資源。因此，對於較低的SCS需要配置更多資源，以便滿足延遲時間限制。

在一些實現方式中，相比較大的SCS(例如，第二SCS)，在較小SCS(例如，第一SCS)上配置的HARQ定時指示符可以包括更少的位元。具體地，PDSCH-HARQ回饋定時指示符(PDSCH-to-HARQ feedback timing indicator)可以用於向UE指示時槽，該時槽用於發送對應於接收到的PDSCH HARQ回饋。第8圖示出了根據本公開的實現方式的方案下的示例場景801和 802。對於較大的SCS，如場景801所示，在UL時槽中存在更多用於HARQ回饋傳輸的機會，因此HARQ定時指示符可以具有更多條目(例如，需要更多位元來表示)。網路裝置可以具有更多靈活性來指示HARQ回饋定時。因此，可以為HARQ回饋定時指示符配置更多位元。對於較小的SCS，如場景802中所示，由於HARQ重傳的機會較少，並且考慮到URLLC的延遲時間要求，因此期望HARQ定時指示符可以指向最早的時槽。例如，時槽號指示(例如，K1)可以在小SCS中指向0或1，對於此欄位時槽號指示僅需要1個位元。因此，可以為HARQ回饋定時指示符配置較少位元。

說明性實現

第9圖示出了根據本公開的實現方式的示例通訊裝置910和示例網路裝置920。通訊裝置910和示例網路裝置920包括在通訊系統900中。通訊裝置910和網路裝置920中的每一個可以執行各種功能以實現本文描述的關於無線通訊中的用戶設備和網路裝置的緊密DCI設計和操作的方案、技術、過程和方法，包括上述場景以及下面描述的過程1000。

通訊裝置910可以是電子裝置的一部分，該電子裝置可以是諸如可擕式或行動裝置的UE、可穿戴裝置、無線通訊裝置或計算裝置。例如，通訊裝置910可以在智慧手機、智慧手錶、個人數位助理、數位相機或諸如平板電腦、膝上型電腦或筆記型電腦的計算設備中實現。通訊裝置910還可以是機器型裝置的一部分，機器型裝置可以是諸如不可移動或固定裝置的IoT或NB-IoT裝置、家庭裝置、有線通訊裝置或計算裝置。例如，通訊裝置910可以在智慧恒溫器、智慧冰箱、智慧門鎖、無線揚聲器或家庭控制中心中實現。或者，通訊裝置910可以以一個或多個積體電路(integrated-circuit，IC)晶片的形式實現，例如但不限於，一個或多個單核處理器、一個或多個多核處理器、一個或多個精簡指令集計算(reduced-instruction-set-computing，RISC)處理器或一個或多個複雜指令集計算(complex-instruction-set-computing，CISC)處理器。通訊裝置910可以包括第9圖中所示的那些元件中的至少一些，例如，處理器912等。通訊裝置910還可以包括與本公開的提出的方案無關的一個或多個其他元件(例如，內部電源、顯示裝置和/或用戶介面設備)，並且因此，為了簡單和簡潔起見，下面第9圖中並未描述通訊裝置910的這些元件。

網路裝置920可以是電子設備的一部分，電子設備可以是諸如基站、小型細胞(cell)、路由器或閘道的網路節點。例如，網路裝置920可以在LTE、LTE-A或LTE-A Pro網路中的eNodeB中實現，或者在5G、NR、IoT或NB-IoT網路中的gNB中實現。或者，網路裝置920可以以一個或多個IC晶片的形式實現，例如但不限於，一個或多個單核處理器、一個或多個多核處理器、一個或多個RISC處理器、或者一個或更多CISC處理器。網路裝置920可以包括第9圖中所示的元件中的至少一部分，例如，處理器922等。網路裝置920還可以包括與本公開的提出的方案不相關的一個或多個其他元件(例如，內部電源、顯示設備和/或用戶介面設備)，並且為了簡單和簡潔起見，下面第9圖中並未描述網路裝置920的這些元件。

在一個方面，處理器912和處理器922中的每一個可以以一個或多個單核處理器、一個或多個多核處理器、一個或多個RISC處理器、或者一個或更多CISC處理器的形式實現。也就是說，即使這裡使用單數術語“處理器”來指代處理器912和處理器922，但是根據本公開處理器912和處理器922中的每一個在一些實現方式中可以包括多個處理器並且在其他實現方式中可以包括單個處理器。在另一方面，處理器912和處理器922中的每一個均可以以硬體(以及可選地，韌體)的形式實現，硬體具有的電子元件包括例如但不限於一個或多個電晶體、一個或多個二極體、一個或多個電容器、一個或多個電阻器、一個或多個電感器、被配置和佈置成實現特定目的的一個或多個憶阻器 (memristors)和/或一個或多個變容二極體。換句話說，在至少一些實施方式中，處理器912和處理器922中的每一個可以是專用器件，其被專門設計、佈置和配置成根據本公開的各種實施方式在設備(例如，如通訊裝置910所示)和網絡(例如，如網路裝置920所示)中執行特定任務(包括功耗降低)。

在一些實現方式中，通訊裝置910還可以包括耦接到處理器912並且能夠無線地發送和接收資料的收發器916。在一些實現方式中，通訊裝置910還可以包括記憶體914，記憶體914耦接到處理器912並且能夠由處理器912存取其中資料。在一些實現方式中，網路裝置920還可以包括耦接到處理器922並且能夠無線地發送和接收資料的收發器926。在一些實現方式中，網路裝置920還可以包括記憶體924，記憶體924耦接到處理器922並且能夠由處理器922存取其中資料。因此，通訊裝置910和網路裝置920可以分別經由收發器916和收發器926彼此無線通訊。為了幫助更好地理解，以下對通訊裝置910和網路裝置920中的每一個的操作、功能和性能的下述描述是基於行動通訊環境，其中通訊裝置910在通訊裝置或UE中實現或者被實現為通訊裝置或者UE，網路裝置920在通訊網路的網路節點中實現或者被實現為通訊網路的網路節點。

在一些實現方式中，緊密DCI設計和/或操作可以被配置為依賴於SCS。通訊裝置910和/或網路裝置920可以被配置為針對某些特定SCS支援緊密DCI。例如，通訊裝置910和/或網路裝置920可以被配置為僅針對15kHz SCS支援緊密DCI，並且通訊裝置910和/或網路裝置920可以被配置為針對其他SCS(例如，30kHz、60kHz和120kHz)不支援緊密DCI。

在一些實現方式中，對緊密DCI的監視可以限制在特定SCS上。當處理器912被配置為監視緊密DCI時，可以在處理器912應當監視的其他DCI格式上配置一些限制。具體地，不期望處理器912在某些SCS的同一監視時機中監視緊密DCI和正常DCI兩者，以滿足盲解碼次數的預算。正常DCI可以包括，例如但不限於，DCI格式0_1和DCI格式1_1。處理器912可以被配置為確定在第一SCS上是否支援緊密DCI。在第一SCS上支援緊密DCI的情況下，處理器912可以被配置為經由收發器916在第一SCS上監視緊密DCI。處理器912可以在第一SCS上監視緊密DCI和正常DCI兩者。因此，處理器912可以被配置為在控制通道(例如，PDCCH)中使用緊密DCI來執行高可靠性服務(例如，URLLC)。另外，處理器912可以被配置為確定在第二SCS上是否支援緊密DCI。第一SCS可以小於第二SCS。在第二SCS上不支援緊密DCI的情況下，處理器912可以被配置為取消對在第二SCS上緊密DCI和正常DCI兩者的監視。處理器912可以被配置為在第二SCS上不監視緊密DCI而僅監視正常DCI，以減少盲解碼的數量。例如，僅對於15kHz SCS，緊密DCI被支援。處理器912可以被配置為經由收發器916僅針對15kHz SCS監視緊密DCI和正常DCI。處理器912可以對於30kHz、60kHz和120kHz SCS，不監視緊密DCI而僅監視正常DCI。

在一些實現方式中，緊密DCI的大小可取決於SCS。處理器912可以被配置為根據SCS(例如，第一SCS或第二SCS)確定緊密DCI大小。例如，對於15kHz SCS，緊密DCI大小可以與其他DCI格式不同。其他DCI格式可以包括，例如但不限於，回退DCI(例如，DCI格式0_0或DCI格式1_0)和正常DCI(例如，DCI格式0_1或DCI格式1_1)。對於SCS>15kHz，緊密DCI可以與回退DCI大小或正常DCI大小相同。處理器912可以使用一些顯式或隱式方法來識別具有相同大小的DCI格式。

在一些實現方式中，處理器922可被配置為對緊密DCI使用固定大小而不管BWP。固定的緊密DCI大小要求FD-RA欄位具有固定數量的位元，而與BWP大小無關。因此，處理器922可以配置FD-RA的固定解譯並且應用於所有BWP。處理器912可以被配置為根據基於BWP的選擇(例如，B) 和FD-RA所需的位元數(例如，N)的函數，確定RB粒度。對於較小的BWP，處理器912可以將RB粒度確定為單個RB。對於較大的BWP，處理器912可以將RB粒度確定為多個RB。因此，基於數位學的緊密DCI設計和操作能夠減少通訊設備910處的盲解碼的數量。無論BWP如何，固定的緊密DCI大小能夠減小DCI大小並提高可靠性。

在一些實現方式中，對於緊密DCI可以減少位元欄位的數量。某些DCI欄位的大小可以取決於SCS。緊密DCI的一些或所有條目的位元欄位大小可以是固定的。例如，可以在3GPP規範中定義位元欄位。或者，網路裝置920可以通過高層信令(例如，RRC信令)或通過L1信令來配置緊密DCI的位元欄位。

在一些實現方式中，相比較大SCS(例如，第二SCS)，處理器922可以為較小SCS(例如，第一SCS)上DCI的RV索引欄位配置較少的位元。對於較大的SCS，存在更多的傳輸機會，因此可以放寬每次傳輸的目標BLER並且可以使用更高的碼率。在這種情況下，可以通過使用IR組合來實現增益，因此針對每次傳輸/重傳需要不同RV版本。因此，處理器922可以為DCI中的RV索引欄位分配更多位元。對於較小的SCS，傳輸的機會較少，並且目標BLER可以非常小，因此可以選擇較低的碼率。在這種情況下，IR組合無法獲得增益或餘量。因此，處理器922可以將較少的位元分配給DCI中的RV索引欄位。

在一些實現方式中，處理器922可以將較小SCS(例如，第一SCS)上HARQ進程的最大數量配置為小於較大的SCS(例如，第二SCS)。對於較大的RTT，可以支援更多的HARQ進程。因此，處理器922可以分配更多位元來表示HARQ進程的數量。對於較短的RTT，可以支援很少的HARQ進程。因此，處理器922可以分配較少的位元來表示HARQ進程的數量。

在一些實現方式中，處理器922可將較小SCS(例如，第一SCS) 上的DAI配置為包括比較大SCS(例如，第二SCS)更少的位元。對於較大的SCS，處理器922可以具有更多的傳輸機會。處理器922可以配置通訊裝置910累積HARQ回饋位元以在單個/少數PUCCH資源中的傳輸。因此，處理器922對於較大SCS需要下行鏈路指配索引中更多位元，以在處理HARQ回饋位元時提供更大的靈活性。對於較小的SCS，由於延遲時間限制，處理器922可以不配置通訊裝置910累積先前傳輸上的HARQ回饋位元。因此，處理器922可以使用非常少的位元來表示下行鏈路指配索引。

在一些實現方式中，相比較小的SCS(例如，第一SCS)，處理器922可以在較大的SCS(例如，第二SCS)上配置更少的PUCCH資源。對於較大的SCS，處理器922需要每個UL時槽較少的PUCCH資源，因為處理器922可以在未來UL時槽中分配資源時具有靈活性並且仍然可以滿足延遲時間限制。處理器922可以具有更多UL機會來分配PUCCH資源，因此可以縮短PUCCH資源指示符欄位。因此，處理器922可以對於較高的SCS配置較少資源，以便減少PUCCH資源指示符的位元數。對於較小的SCS，處理器922在UL時槽中要求更多的PUCCH資源，由於延遲時間限制，回饋機會較少。處理器922可以具有較少的UL機會來分配PUCCH資源，因此可以配置更多的PUCCH資源。因此，處理器922可以對較低SCS配置較多資源以便滿足延遲時間限制。

在一些實現方式中，與較大SCS(例如，第二SCS)相比，處理器922可將較小SCS(例如，第一SCS)上的HARQ定時指示符配置為包括較少的位元。對於較大的SCS，處理器912可以在UL時槽中具有更多機會用於HARQ回饋傳輸，因此HARQ定時指示符可以具有更多條目(例如，需要更多位元來表示)。處理器922可以具有更大靈活性來指示HARQ回饋定時。因此，處理器922可以為HARQ回饋定時指示符配置更多位元。對於較小的SCS，由於處理器912可以具有較少的HARQ重傳機會並且考慮到URLLC的延遲時間要求，因此期望HARQ定時指示符可以指向最早的時槽。例如，時槽號指示(例如，K1)可以在小SCS中指向0或1，對於此欄位時槽號指示僅需要1個位元。因此，處理器922可以為HARQ回饋定時指示符配置較少的位元。

示例性過程

第10圖示出了根據本公開的實現方式的示例過程1000。過程1000可以是關於根據本公開的緊密DCI設計和操作的上述場景的示例實現方式，無論是部分的還是完全的。過程1000可以表示通訊裝置910的多個特徵的實現方式。過程1000可以包括如框1010、1020和1030中的一個或多個所示的一個或多個操作、動作或功能。儘管被示出為離散的框，根據所需的實現方式，過程1000的各個框可以被劃分為附加的框、組合成更少的框或者被取消。此外，過程1000的框可以按照第10圖中所示的順序執行，或者，可以按照不同的順序執行。過程1000可以由通訊裝置910或任何合適的UE或機器類型的設備實現。僅出於說明性目的而非限制，下面以通訊裝置910為背景描述過程1000。過程1000在框1010處開始。

在1010處，過程1000可以涉及裝置910的處理器912確定在第一SCS上支援緊密DCI。過程1000可以從1010進行到1020。

在1020處，過程1000可以涉及處理器912在第一SCS上監視緊密DCI。過程1000可以從1020進行到1030。

在1030處，過程1000可以涉及處理器912使用控制通道中緊密DCI來執行高可靠性服務。

在一些實現方式中，過程1000可以涉及處理器912在第一SCS上監視緊密DCI和正常DCI兩者。

在一些實現方式中，過程1000可以涉及處理器912確定第二SCS上不支援緊密DCI。過程1000還可以涉及處理器912取消對第二SCS上緊密 DCI和正常DCI兩者的監視。第一SCS可以小於第二SCS。

在一些實現方式中，可以根據第一SCS來確定緊密DCI的大小。

在一些實現方式中，緊密DCI的大小可以是固定的，而與BWP無關。

在一些實現方式中，在第一SCS上RV索引欄位可以包括比第二SCS更少的位元。

在一些實現方式中，在第一SCS上最大HARQ進程數量可以小於第二SCS。

在一些實現方式中，在第一SCS上的下行鏈路指配索引可以包括比第二SCS更少的位元。

在一些實現方式中，在第二SCS上配置的PUCCH資源可以小於第一SCS。

在一些實現方式中，在第一SCS上HARQ回饋定時指示符可以包括比第二SCS更少的位元。

補充說明

本文中所描述之主題有時例示了包含在不同的其它部件之內或與其連接的不同部件。要理解的是，這些所描繪架構僅是示例，並且實際上能夠實施實現相同功能的許多其它架構。在概念意義上，實現相同功能的部件的任意佈置被有效地“關聯”成使得期望之功能得以實現。因此，獨立於架構或中間部件，本文中被組合為實現特定功能之任何兩個部件能夠被看作彼此“關聯”成使得期望之功能得以實現。同樣，如此關聯之任何兩個部件也能夠被視為彼此“在操作上連接”或“在操作上耦接”，以實現期望功能，並且能夠如此關聯的任意兩個部件還能夠被視為彼此“在操作上可耦接”，以實現期望的功能。在操作在可耦接之特定示例包括但不限於實體上能配套和/或實體上交互的部件和/或可無線地交互和/或無線地交互的部件和/或邏輯上交互和/或邏輯上可交互的部件。

此外，關於本文中任何複數和/或單數術語的大量使用，本領域具備通常知識者可針對上下文和/或應用按需從複數轉化為單數和/或從單數轉化為複數。為了清楚起見，本文中可以明確地闡述各種單數/複數互易。

另外，本領域具備通常知識者將理解，通常，本文中所用術語且尤其是在所附申請專利範圍(例如，所附申請專利範圍之主體)中所使用的術語通常意為“開放”術語，例如，術語“包含”應被解釋為“包含但不限於”，術語“具有”應被解釋為“至少具有”，術語“包括”應解釋為“包括但不限於”，等等。本領域具備通常知識者還將理解，如果引入之申請專利範圍列舉之特定數目是有意的，則這種意圖將在申請專利範圍中明確地列舉，並且在這種列舉不存在時不存在這種意圖。例如，作為理解之幫助，所附申請專利範圍可以包含引入申請專利範圍列舉之引入性短語“至少一個”和“一個或更多個”之使用。然而，這種短語的使用不應該被解釋為暗示申請專利範圍列舉透過不定冠詞“一”或“一個”的引入將包含這種所引入之申請專利範圍列舉之任何特定申請專利範圍限制於只包含一個這種列舉的實現方式，即使當同一申請專利範圍包括引入性短語“一個或更多”或“至少一個”以及諸如“一”或“一個”這樣的不定冠詞(例如，“一和/或一個”應被解釋為意指“至少一個”或“一個或更多個”)時，這同樣適用於用來引入申請專利範圍列舉之定冠詞的使用。另外，即使明確地列舉了特定數量之所引入之申請專利範圍列舉，本領域技術人員也將認識到，這種列舉應被解釋為意指至少所列舉之數量(例如，在沒有其它之修飾語之情況下，“兩個列舉”之無遮蔽列舉意指至少兩個列舉或者兩個或更多個列舉)。此外，在使用類似於“A、B和C中之至少一個等”之慣例之那些情況下，在本領域技術人員將理解這個慣例之意義上，通常意指這種解釋(例如，“具有A、B和C中之至少一個之系統”將包括但不限於單獨具有A、單獨具有B、單獨具有C、一同具有A和B、一同具有A和C、一同具有B和C和/或一同具有A、B和C等之系統)。在使用類似於“A、B或C等中之至少一個”之慣例之那些情況下，在本領域技術人員將理解這個慣例之意義上，通常意指這樣之解釋(例如，“具有A、B或C中至少一個之系統”將包括但不限於單獨具有A、單獨具有B、單獨具有C、一同具有A和B、一同具有A和C、一同具有B和C、和/或一同具有A、B和C等之系統)。本領域技術人員還將理解，無論在說明書、申請專利範圍還是附圖中，實際上呈現兩個或更多個另選之項之任何轉折詞語和/或短語應當被理解為構想包括這些項中之一個、這些項中之任一個或者這兩項之可能性。例如，短語“A或B”將被理解為包括“A”或“B”或“A和B”之可能性。

根據上述內容，將領會的是，本文中已經為了例示之目的而描述了本公開之各種實現方式，並且可以在不脫離本公開之範圍和精神之情況下進行各種修改。因此，本文中所公開之各種實現方式不旨在是限制性的，真正之範圍和精神由所附之申請專利範圍指示。

201~203‧‧‧場景

Claims

一種緊密下行鏈路控制資訊設計和操作方法，包括：由裝置的處理器根據子載波間隔(subcarrier spacing，SCS)確定是否支援緊密(compact)下行鏈路控制資訊(downlink control information，DCI)，並且確定在第一SCS上支援所述緊密DCI；由所述處理器在所述第一SCS上監視所述緊密DCI；以及由所述處理器利用控制通道中所述緊密DCI執行高可靠性服務。
如申請專利範圍第1項所述的方法，還包括：由所述處理器在所述第一SCS上監視所述緊密DCI和正常DCI。
如申請專利範圍第2項所述的方法，還包括：由所述處理器確定第二SCS上不支援所述緊密DCI；以及由所述處理器取消對所述第二SCS上所述緊密DCI和所述正常DCI的監視，其中所述第一SCS小於所述第二SCS。
如申請專利範圍第1項所述的方法，其中，根據所述第一SCS確定所述緊密DCI的大小。
如申請專利範圍第1項所述的方法，其中，所述緊密DCI的大小是固定的，與有效頻寬部分(bandwidth part，BWP)無關。
如申請專利範圍第3項所述的方法，其中，所述第一SCS上冗餘版本(redundancy version，RV)索引欄位包括比所述第二SCS少的位元。
如申請專利範圍第3項所述的方法，其中，所述第一SCS上混合自動重傳請求(hybrid automatic repeat request，HARQ)進程的最大數量小於所述第二SCS。
如申請專利範圍第3項所述的方法，其中，所述第一SCS上的下行鏈路指配索引包括比所述第二SCS更少的位元。
如申請專利範圍第3項所述的方法，其中，在所述第二SCS上配置的物理上行鏈路控制通道(physical uplink control channel，PUCCH)資源小於所述第一SCS。
如申請專利範圍第3項所述的方法，其中，所述第一SCS上混合自動重傳請求(hybrid automatic repeat request，HARQ)回饋定時指示符包括比所述第二SCS少的位元。
一種用於緊密下行鏈路控制資訊設計和操作的裝置，包括：收發器，能夠與無線網路的網路節點無線通訊；以及處理器，通訊地耦接到所述收發器，所述處理器能夠：根據子載波間隔(subcarrier spacing，SCS)確定是否支援緊密(compact)下行鏈路控制資訊(downlink control information，DCI)；確定在第一SCS上支援所述緊密DCI；經由所述收發器在所述第一個SCS上監視所述緊密DCI；以及利用控制通道中所述緊密DCI執行高可靠性服務。
如申請專利範圍第11項所述的裝置，其中，所述處理器還能夠：經由所述收發器在所述第一個SCS上監視所述緊密DCI和正常DCI。
如申請專利範圍第12項所述的裝置，其中，所述處理器還能夠：確定在第二SCS上不支援所述緊密DCI；以及由所述處理器取消對所述第二SCS上所述緊密DCI和所述正常DCI的監視，其中所述第一SCS小於所述第二SCS。
如申請專利範圍第11項所述的裝置，其中，根據所述第一SCS確定所述緊密DCI的大小。
如申請專利範圍第11項所述的裝置，其中，所述緊密DCI的大小是固定的，與有效頻寬部分(bandwidth part，BWP)無關。
如申請專利範圍第13項所述的裝置，其中，在所述第一SCS上冗餘版本(redundancy version，RV)索引欄位包括比所述第二SCS少的位元。
如申請專利範圍第13項所述的裝置，其中，在所述第一SCS上混合自動重傳請求(hybrid automatic repeat request，HARQ)進程的最大數量小於所述第二SCS。
如申請專利範圍第13項所述的裝置，其中，所述第一SCS上的下行鏈路指配索引包括比所述第二SCS少的位元。
如申請專利範圍第13項所述的裝置，其中，在所述第二SCS上配置的物理上行鏈路控制通道(physical uplink control channel，PUCCH)資源小於所述第一SCS。
如申請專利範圍第13項所述的裝置，其中，在所述第一SCS上混合自動重傳請求(hybrid automatic repeat request，HARQ)回饋定時指示符包括比所述第二SCS少的位元。