TWI747166B - 移動通信中用戶裝置處理時間線增強的方法和裝置 - Google Patents

Abstract

描述了關於移動通信中的用戶裝置和網絡裝置的處理時間線增強的各種解決方案。一種裝置可以確定服務的延遲要求是否小於閾值。在所述服務的延遲要求不小於閾值的情況下，所述裝置可以使用第一處理時間能力來執行傳輸。在所述服務的延遲要求小於閾值的情況下，所述裝置可以使用第二處理時間能力來執行所述傳輸。當使用所述第二處理時間能力時，所述裝置可以應用調度限制/優化來執行所述傳輸。

Description

移動通信中用戶裝置處理時間線增強的方法和裝置

本公開總體上涉及移動通信，並且更具體地，涉及關於移動通信中的用戶裝置和網絡裝置的處理時間線（timeline）增強。

除非本文另外指出，否則本節中描述的方法不是下面列出的申請專利範圍的先前技術，並且不因被包括在本節中而被承認為先前技術。

在新無線電（NR）中，用於上行鏈路發送（例如，物理上行鏈路共享信道（Physical Uplink Shared Channel，PUSCH）準備）和下行鏈路接收（例如，物理下行鏈路共享信道（Physical Downlink Shared Channel，PDSCH）處理）的更積極（aggressive）的用戶裝置（UE）處理時間線被提出以減少傳輸延遲（latency）並促進上行/下行傳輸。例如，UE處理時間N1被定義為PDSCH譯碼和混合自動重傳請求確認（HARQ-ACK）回饋準備所需的時間。UE處理時間N2被定義為PUSCH準備時間。UE處理時間線可以由N1和/或N2控制。在NR中討論了對UE處理時間線的進一步增強，以進一步減少延遲並容納更多數量的上行鏈路/下行鏈路傳輸。

為了滿足超可靠和低延遲通信（URLLC）業務（traffic）在延遲和可靠性方面的嚴格要求，在某些情況下可能需要進一步減少最小UE處理時間。新的減少的處理時間能力可以允許改進的基於HARQ的操作，並有可能在延遲預算內容納複數個HARQ傳輸。

然而，進一步減少UE處理時間將導致UE複雜性增加以及UE實現方面的額外負擔。強制最小化UE處理時間將對UE實現和成本帶來嚴峻挑戰。因此，關注對處理時間改進方面具有最關鍵要求(critical requirement)且具有更大潛力的一些特定使用示例是合理的。因此，需要一種中間解決方案以允許在一些關鍵使用示例中應用嚴格的處理時間要求，同時又不會給整個UE實現和體系結構帶來很大壓力。

因此，對於新開發的無線通信網絡來說，如何改善UE處理時間線並避免在UE實現和架構上增加複雜度成為重要的方面。因此，需要為UE提供合適的方案，以縮短處理時間，並在設計複雜度上保持一定的靈活性。

以下發明內容僅是說明性的，而無意以任何方式進行限制。即，提供以下概述以介紹本文描述的新穎和非顯而易見的技術的概念，重點，益處和優點。選擇的實施方式在下面的詳細描述中進一步描述。因此，以下發明內容既不旨在標識所要求保護的主題的必要特徵，也不旨在用於確定所要求保護的主題的範圍。

本公開的目的是提出解決上述情形的解決方案或方案，所述解決方案或方案涉及關於移動通信中的用戶裝置和網絡裝置的處理時間線增強的問題。

在一方面，一種方法可以包括裝置確定服務的延遲要求是否小於閾值。所述方法還可以包括在所述服務的延遲要求不小於所述閾值的情況下使用第一處理時間能力來執行傳輸。所述方法可以進一步包括在所述服務的延遲要求小於所述閾值的情況下，使用第二處理時間能力來執行所述傳輸。所述方法可以進一步包括當使用第二處理時間能力時，所述裝置應用排程限制/優化（scheduling restriction/optimization）來執行所述傳輸。

在一方面，一種裝置可以包括收發器，所述收發器在操作期間與無線網絡的網絡節點無線通信。所述裝置還可以包括通信地耦合到所述收發器的處理器。所述處理器在操作期間可執行包括確定服務的延遲要求是否小於閾值的操作。所述處理器還可以執行包括在所述服務的延遲要求不小於所述閾值的情況下使用第一處理時間能力來執行傳輸的操作。所述處理器可以進一步執行包括在所述服務的延遲要求小於所述閾值的情況下，使用第二處理時間能力來執行所述傳輸的操作。所述處理器可以進一步執行包括在使用所述第二處理時間能力時應用排程限制/優化來執行所述傳輸的操作。

值得注意的是，儘管本文提供的描述可能是在某些無線電接入技術，網絡和網絡拓撲的情形中，例如長期演進（LTE）， LTE-Advanced，LTE-Advanced Pro，第五代（5G），新無線電（NR），物聯網（IoT），窄帶物聯網（NB-IoT）和工業物聯網（IIoT），所提出的概念，方案以及它們的任何變體/衍生物可以在或被其他類型的無線電接入技術，網絡和網絡拓撲實現。因此，本公開的範圍不限於本文描述的示例。

本文公開了要求保護的主題的詳細實施例和實施方式。然而，應當理解，所公開的實施例和實施方式僅是可以以各種形式體現的所要求保護的主題的說明。然而，本公開可以以許多不同的形式來體現，並且不應被解釋為限於在此闡述的示例性實施例和實施方式。相反，提供這些示例性實施例和實施方式是為了使本公開的描述透徹和完整，並將本公開的範圍充分傳達給所屬技術領域具有通常知識者。在下面的描述中，可以省略眾所周知的特徵和技術的細節，以避免所呈現的實施例和實施方式中不必要地混淆。總覽

根據本公開的實施方式涉及與關於移動通信中的用戶裝置和網絡裝置的處理時間線增強有關的各種技術，方法，方案和/或解決方案。根據本公開，可以單獨地或聯合地實現複數種可能的解決方案。即，儘管以下可能描述了這些可能的解決方案，但是這些可能的解決方案中的兩個或更多個可以以一種組合或另一種組合來實現。

在NR中，提出了用於上行鏈路發送（例如，PUSCH準備）和下行鏈路接收（例如，PDSCH處理）的更積極的UE處理時間線，以減少傳輸延遲並在URLLC延遲預算內實現額外的HARQ重傳，從而改善可靠性和系統效率。例如，UE處理時間N1被定義為PDSCH譯碼和HARQ-ACK回饋準備所需的時間。UE處理時間N2被定義為PUSCH準備時間。UE處理時間線可以由N1和/或N2控制。在NR中討論了對UE處理時間線的進一步增強，以進一步減少延遲並容納更多數量的上行鏈路/下行鏈路傳輸。

為了滿足URLLC業務在延遲和可靠性方面的嚴格要求，在某些延遲關鍵的使用示例中可能需要進一步減少最小UE處理時間。新的減少的處理時間能力可以允許改進的基於HARQ的操作，並有可能在延遲預算內容納複數個HARQ傳輸。然而，進一步減少UE處理時間將導致UE複雜性增加以及增加UE實現的額外負擔。例如，為了進一步減少UE的處理時間，可能需要通過具有更好性能的硬件組件來實現UE，這導致更高的製造成本。為了縮短UE處理時間線，還可以在UE上進行更複雜和大量的計算，這導致進一步的功耗和復雜的UE實現。強制最小化UE處理時間將對UE實現和成本带来嚴峻挑戰。因此，關注一些在改進處理時間方面具有最關鍵要求且更具潛力的特定使用示例是合理的。因此，需要一種中間解決方案以允許在一些關鍵使用示例上应用嚴格的處理時間要求，同時仍不對整個UE實現和體系結構施加很大壓力。

鑑於以上內容，本公開提出了關於UE和網絡裝置的處理時間線增強的複數種方案。根據本公開的方案，將提出一些將有助於以非常小的性能影響來降低UE實現的複雜性的排程限制。UE可以被配置為確定服務的延遲要求，以用於確定是否應用排程限制/優化。對於對延遲要求不嚴格的某些通用服務，UE可能不需要應用排程限制。對於對延遲要求嚴格的某些特定服務，UE可以應用排程限制/優化以減少處理時間。因此，UE可以具有增強處理時間線的靈活性，而不會給UE實現和架構帶來很大壓力。

第1圖示出了根據本公開的实施方式的方案下的示例表100。場景100包括UE和網絡節點，其可以是無線通信網絡(例如，LTE網絡，LTE-Advanced網絡，LTE-Advanced Pro網絡，5G網絡，NR網絡，IoT網絡，NB-IoT網絡或IIoT網絡)的一部分。表100描述了第三代合作夥伴計劃(3GPP)版本15和版本16中的一些URLLC示例。從表100中可以看出，版本16工廠自動化示例(factory automation use case)在版本15和版本16的所有示例中對延遲和可靠性方面具有最嚴格的要求。然而，用於工廠自動化的URLLC業務是 周期性的和確定性的，因此是可預測的，並且能力# 3可以限於週期性和確定性的業務(例如，用於工廠自動化)。該業務模型屬性非常重要，並且可以減少UE處理時的不確定性。因此，在封包的接收或發送之前，UE可以預期大量的優化。另外，工廠自動化示例與小封包尺寸(例如32字節)相關聯，該小封包尺寸也可以用於進一步的優化。

結果，可以考慮使用示例和服務類型以引入新的UE處理時間能力(例如，能力# 3)。新的UE處理時間能力(例如，能力# 3)可以用於關鍵示例(例如，工廠自動化)。可以為增強型URLLC(eURLLC)引入具有受限業務類型的新UE處理時間功能。使用版本15 UE處理時間功能(例如功能# 2)可以輕鬆滿足表100中列出的其餘示例(例如，配電，運輸行業和版本15的所有使用示例)的要求。

具體地，UE可以被配置為確定傳輸的使用示例和/或服務類型。然後，UE可能能夠根據使用示例/服務類型的要求確定適當的UE處理時間能力來執行傳輸。例如，UE可以被配置為確定服務的延遲要求是否小於閾值。UE可以被配置為在服務的延遲要求不小於閾值(例如1ms)的情況下使用第一處理時間能力(例如，能力# 2)來執行傳輸。UE可以被配置為在服務的延遲要求小於閾值(例如1ms)的情況下使用第二處理時間能力(例如，能力# 3)來執行傳輸。UE可以被配置為在使用第二處理時間能力時應用排程限制/優化來執行傳輸。可以引入一些排程限制以進一步簡化UE處理並減輕對UE實現的壓力。UE可以使用排程限制/優化來減少處理時間以滿足關鍵延遲要求。這裡的傳輸可以包括初始傳輸和重傳。這裡的服務可以包括URLLC服務或eURLLC服務。

第一處理時間能力(例如，能力# 2)可以包括第一正常處理時間N1和第二正常處理時間N2。第二處理時間能力(例如，能力# 3)可以包括第一特定處理時間N1’和第二特定處理時間N2’。第一特定處理時間N1’小於第一正常處理時間N1。第二特定處理時間N2’小於第二正常處理時間N2。 N1和N1’可以被定義為PDSCH譯碼和HARQ-ACK回饋準備所需的時間。N2和N2’可以被定義為PUSCH準備時間。正常處理時間和特定處理時間的值可以預先存儲在UE中，也可以由網絡節點配置。例如，特定處理時間N1’/ N2’可以由無線電資源控制（RRC）信令配置或動態地被通知。UE可以被配置為接收特定處理時間的配置。

在一些實施方式中，排程限制/優化可以包括傳輸塊大小（Transport Block Size，TBS）限制。例如，排程限制/優化可以包括TBS值的限制範圍。下行接收和/或上行發送的TBS不能超過限制範圍。網絡節點可以經由無線電資源控制（RRC）信令來配置5〜10個TBS值。備選地，排程限制/優化可以包括TBS或資料速率的上限。備選地，排程限制/優化可以包括限制的最大帶寬（BW）大小。通常，減少不確定性的範圍將大大有助於減少UE處理時間。利用這樣的排程限制，由於封包大小被限制在小範圍內，因此可以減少UE處理時間（例如，下行鏈路資料譯碼時間和/或上行鏈路資料準備時間）。另一方面，UE可以受益於TBS的先驗/預先知識（prior/advance knowledge）或固定的TBS。可以預先用信號通知TBS或將其固定為半靜態地配置給UE的一個常數。TBS或TBS範圍的先驗/預先知識使UE可以預料很多處理和校準（例如，用戶平面（U平面）和/或第1層（L1）準備），這可以為UE節省時間以當封包到達時能專注於封包譯碼或封包準備。

在一些實施方式中，排程限制/優化可以包括取消/去除對碼塊組（Code Block Group，CBG）傳輸和3GPP加密的支持。UE可以被配置為一次不同時接收和/或發送複數個CB（例如，CBG）。類似地，UE可以被配置為在執行傳輸時不執行加密以節省時間。備選的，排程限制/優化可以包括取消/去除對混合自動重傳請求確認（HARQ）碼本的支持。UE可以被配置為單獨發送HARQ回饋（例如，確認（ACK）/否定確認（NACK）），而不是將複數個ACK / NACK組裝為HARQ碼本以減少延遲。

在一些實施方式中，排程限制/優化可以包括：將HARQ回饋限制為特定的物理上行鏈路控制信道（PUCCH）格式（例如，PUCCH format_0）；以及取消HARQ回饋和其他上行鏈路控制信息（Uplink Control Information，UCI）的複用。具體地，HARQ回饋的準備和傳輸將消耗大量的UE處理時間並且可以被簡化。一種可能是將HARQ回饋限制為特定的PUCCH格式，並將HARQ回饋與所有其他UCI信息解耦。例如，僅允許關於PUCCH資源的HARQ-ACK報告，並且不允許在同一PUCCH上多路復用信道狀態信息（CSI）。CSI回饋可以在不同的PUCCH上發送或由UE丟棄。這可以節省HARQ-ACK和CSI復用方面的時間。因此，UE可以被配置為僅在特定的PUCCH格式上發送HARQ回饋。UE可以被配置為不將HARQ回饋與另一UCI復用。

在一些實施方式中，確保小的UCI有效載荷意味著使用基於序列的（sequence based）編碼或Reed-Muller編碼而不是Polar編碼，這將有助於減少處理時間。因此，排程限制/優化可以包括使用基於序列的編碼或Reed-Muller編碼來編碼UCI有效載荷。可以將UCI有效載荷限制為較小的大小（例如，UCI位數≤11）。與UCI位數≥11相比，在這種情況下可以減少UE處理時間N1。

在一些實施方式中，PUCCH格式的先驗/預先知識可能是非常有益的。UE可能不需要譯碼下行鏈路控制信息（DCI）來確定PUCCH格式，並且UE可以提前知道PUCCH資源集和UCI有效載荷。此外， PUCCH在時間中（in time）的位置和發射功率控制（Transmit Power Control，TPC）命令的預先知識（advance knowledge）可能也非常有用。當前，UE需要完成PDCCH譯碼以確定PUCCH在時間中的位置。通過PUCCH在時間中的位置的預先知識，UE可以節省用於譯碼PDCCH的時間。類似地，UE可以通過TPC命令的預先知識來節省時間。因此，UE可以被配置為接收PUCCH格式或TPC命令的先驗/預先知識。UE可以被配置為在不對DCI進行譯碼的情形下根據所述預先知識確定PUCCH格式或TPC命令。PUCCH相關信息的先驗/預先知識可以幫助加快UE處理時間。

在一些實施方式中，為了幫助改善PUSCH處理時間（例如，N2），取消/去除對PUSCH的UCI搭載（piggy-backing）的支持將有助於減少PUSCH處理時間。將上行鏈路ACK / NACK與上行鏈路PUSCH資料分開將有助於減少PUSCH處理時間。因此，排程限制/優化可以包括取消對PUSCH傳輸上的UCI 搭載的支持。 UE可以被配置為不將UCI和PUSCH資料一起發送。另一方面，可以為PUSCH重傳引入可能的優化。第1層（L1）和第2層（L2）在重傳中可能需要較少的處理。初始傳輸中使用的某些資料和參數可以在重傳中重複使用，以減少UE處理時間。

所有前述的減少UE處理時間的提議可以被指定，並且可以半靜態或動態地對UE啟用/禁用這些提議。可以將前述排程限制定義為UE能力（例如，能力＃3），並且UE可以在滿足延遲要求的同時報告其對該功能的支持或不支持。例如，當eURLLC業務具有嚴格的延遲要求時，UE可以報告其是否支持CSI的HARQ-ACK復用。說明性實施

第2圖示出了根據本公開的實施方式的示例性通信裝置210和示例性網絡裝置220。通信裝置210和網絡裝置220中的每一個可執行各種功能以實現本文描述的，關於無線通信中用戶裝置和網絡裝置的處理時間線增強的方案，技術，過程和方法，包括上述場景/機制以及下面描述的過程300。

通信裝置210可以是電子裝置的一部分，所述電子裝置可以是諸如便攜式或移動裝置，可穿戴裝置，無線通信裝置或計算裝置之類的UE。例如，通信裝置210可以被實現在智能電話，智能手錶，個人數位助理，數位照相機或諸如平板計算機，膝上型計算機或筆記本計算機的計算裝置中。通信裝置210也可以是機器類型裝置的一部分，該機器類型裝置可以是IoT，NB-IoT或IIoT裝置，例如固定裝置或靜止裝置，家用裝置，有線通信裝置或計算裝置。例如，通信裝置210可以被實現在智能恆溫器，智能冰箱，智能門鎖，無線揚聲器或家庭控制中心中。替代地，通信裝置210可以以一個或複數個集成電路（IC）芯片的形式實現，例如但不限於，一個或複數個單核處理器，一個或複數個多核處理器，一個或複數個精簡指令集計算（RISC）處理器，或一個或複數個複雜指令集計算（CISC）處理器。通信裝置210可以包括第2圖所示的那些組件中的至少一些，例如，諸如處理器212。通信裝置210可以進一步包括與本公開所提議的方案不相關的一個或複數個其他組件（例如，內部電源，顯示裝置和/或用戶接口裝置），並且為了簡化和簡潔起見，通信裝置210的這樣的組件既未在第2圖示出，下面也不將描述。

網絡裝置220可以是電子裝置的一部分，所述電子裝置可以是諸如基站，小型小區，路由器或網關之類的網絡節點。例如，網絡裝置220可以在LTE，LTE-Advanced或LTE-Advanced Pro網絡中的eNodeB中或在5G，NR，IoT，NB-IoT或IIoT網絡中的gNB中實現。備選地，網絡裝置220可以以一個或複數個IC芯片的形式實現，例如但不限於，一個或複數個單核處理器，一個或複數個多核處理器，或一個或複數個RISC或CISC處理器。網絡裝置220可以包括第2圖所示的那些組件中的至少一些，例如，諸如處理器222。網絡裝置220可以進一步包括與本公開的所提議的方案不相關的一個或複數個其他組件（例如，內部電源，顯示裝置和/或用戶接口裝置），並且為了簡化和簡潔起見，網絡裝置220的這樣的組件既未在第2圖中示出，下面也不將描述。

在一方面，處理器212和處理器222中的每一個可以以一個或複數個單核處理器，一個或複數個多核處理器或一個或複數個CISC處理器的形式實現。即，即使在本文中使用單數術語“處理器”來指代處理器212和處理器222，根據本發明，處理器212和處理器222中的每一個在一些實施方式中可包括複數個處理器，而在其他實施方式中可包括單個處理器。在另一方面，處理器212和處理器222中的每一個可以以具有電子組件的硬件（以及可選地，固件）的形式實現，所述電子組件包括例如但不限於一個或複數個電晶體，一個或複數個二極管，一個或複數個電容器，一個或複數個電阻器，一個或複數個電感器，一個或複數個憶阻器和/或一個或複數個變容二極管，其被配置和佈置為實現根據本公開的特定目的。換句話說，在至少一些實施方式中，處理器212和處理器222中的每一個是專門設計，佈置和配置為執行包括減少根據本公開的各種實施方式的裝置（例如，由通信裝置210表示）和網絡（例如，如由網絡裝置220所表示的）中的功耗的特定任務的專用機器。

在一些實施方式中，通信裝置210還可以包括收發器216，所述收發器耦合到處理器212並且能夠無線地發送和接收資料。在一些實施方式中，通信裝置210可以進一步包括記憶體214，所述記憶體214耦合到處理器212並且能夠被處理器212訪問並且在其中存儲資料。在一些實施方式中，網絡裝置220還可以包括耦合到處理器222並且能夠無線發送和接收資料的收發器226。在一些實施方式中，網絡裝置220可以進一步包括耦合至處理器222並且能夠被處理器222訪問並在其中存儲資料的記憶體224。因此，通信裝置210和網絡裝置220可以分別經由收發器216和收發器226彼此無線通信。為了幫助更好地理解，在移動通信環境的情形中提供了對通信裝置210和網絡裝置220中的每一個的操作，功能和能力的以下描述，在所述通信環境中，通信裝置210被實現為通信裝置或UE，或者在通信裝置或UE中實現。網絡裝置220被實現為通信網絡中的網絡節點或在通信網絡的網絡節點中實現。

在一些實施方式中，處理器212可以被配置為確定傳輸的使用示例和/或服務類型。然後，處理器212可能能夠根據使用示例/服務類型的要求確定適當的UE處理時間能力來執行傳輸。例如，處理器212可以被配置為確定服務的延遲要求是否小於閾值。處理器212可以被配置為在服務的延遲要求不小於閾值（例如1ms）的情況下使用第一處理時間能力（例如，能力＃2）來執行傳輸。處理器212可以被配置為在服務的延遲要求小於閾值（例如1ms）的情況下使用第二處理時間能力（例如，能力＃3）來執行傳輸。處理器212可以被配置為在使用第二處理時間能力時應用排程限制/優化來執行傳輸。處理器212可以使用排程限制/優化來減少處理時間以滿足關鍵延遲要求。

在一些實施方式中，排程限制/優化可以包括TBS限制。例如，處理器212可以被配置為限制TBS值的範圍。下行接收和/或上行發送的TBS不能超過限制範圍。網絡裝置220可以經由RRC信令來配置5〜10個TBS值。備選的，處理器212可以被配置為限制TB大小或資料速率的上限。備選的，處理器212可以被配置為限制最大BW尺寸。由於這種排程限制，封包大小被限制在小範圍內，因此處理器212可以減少處理時間（例如，下行鏈路資料譯碼時間和/或上行鏈路資料準備時間）。另一方面，處理器212可以受益於TBS的先驗/預先知識或固定的TBS。可以預先用信號通知TBS或將其固定為半靜態配置給處理器212的一個常數。TBS或TBS範圍的先驗/預先知識使處理器212可以預料很多處理和校準，這可以為處理器212節省時間以便當封包到達時，將注意力集中在封包譯碼或封包準備上。

在一些實施方式中，處理器212可以被配置為取消/去除對CBG傳輸和3GPP加密的支持。處理器212可以被配置為一次不同時接收和/或發送複數個CB（例如，CBG）。類似地，處理器212可以被配置為在執行傳輸時不執行加密以節省時間。備選地，排程限制/優化可以包括取消/去除對HARQ碼本的支持。處理器212可以被配置為經由收發器216單獨地發送HARQ回饋（例如，ACK / NACK），而不是將複數個ACK / NACK組裝為HARQ碼本以減少延遲。

在一些實施方案中，處理器212可經配置以將HARQ回饋限制為特定的PUCCH格式（例如，PUCCH format_0），並且取消HARQ回饋與其他UCI的複用。處理器212可以被配置為將HARQ回饋與所有其他UCI信息解耦。例如，僅允許關於PUCCH資源的HARQ-ACK報告，並且不允許在同一PUCCH上的CSI復用。處理器212可以經由收發器216在不同的PUCCH上發送CSI回饋或丟棄CSI回饋。這可以節省HARQ-ACK和CSI復用方面的時間。因此，處理器212可以被配置為經由收發器216僅在特定的PUCCH格式上發送HARQ回饋。處理器212可以被配置為不將HARQ回饋與另一UCI復用。

在一些實施方式中，確保小的UCI有效載荷意味著使用基於序列的編碼或Reed-Muller編碼而不是Polar編碼，這將有助於減少處理時間。因此，處理器212可以被配置為使用基於序列的編碼或Reed-Muller編碼來編碼UCI有效載荷。可以將UCI有效載荷限制為較小的大小（例如，UCI位數≤11）。

在一些實施方式中，PUCCH格式的先驗/預先知識可能是非常有益的。處理器212可能不需要譯碼DCI以確定PUCCH格式。處理器212可以具有PUCCH資源集和UCI有效載荷的預先知識。此外， PUCCH在時間中的位置和TPC命令的預先知識可能也非常有用。當前，處理器212可能需要完成PDCCH譯碼來確定PUCCH在時間中的位置。利用PUCCH在時間中的位置的預先知識，處理器212可以節省用於譯碼PDCCH的時間。類似地，處理器212可以利用TPC命令的預先知識來節省時間。因此，處理器212可以被配置為經由收發器216接收PUCCH格式或TPC命令的先驗/預先知識，處理器212可以被配置為在不對DCI進行譯碼的情形下根據先驗知識確定PUCCH格式或TPC命令。處理器212可以根據PUCCH相關信息的先驗/預先知識來加速UE處理時間。

在一些實施方式中，為幫助改善PUSCH處理時間（例如，N2），處理器212可經配置以取消/移除對PUSCH上的UCI搭載的支持以減少PUSCH處理時間。將上行鏈路ACK / NACK與上行鏈路PUSCH資料分開將有助於減少PUSCH處理時間。因此，處理器212可以被配置為取消對PUSCH傳輸上的UCI 搭載的支持。處理器212可以被配置為不將PUSCH資料和UCI一起發送。另一方面，可以為PUSCH重傳引入可能的優化。處理器212可以將在初始傳輸中使用的一些資料和參數重用於重新傳輸以減少UE處理時間。

在一些實現中，可以將前述排程限制定義為UE能力（例如，能力＃3），並且處理器212可以在滿足延遲要求的同時報告其對該功能的支持或不支持。例如，當eURLLC業務具有嚴格的延遲要求時，處理器212可以經由收發器216報告其對是否支持HARQ-ACK與CSI的復用。說明性過程

第3圖示出了根據本公開的實施方式的示例過程300。過程300可以是以上關於本公開的UE處理時間線增強的場景/方案的部分或全部的示例實施方式。過程300可以表示通信裝置210的特徵的實現的一方面。過程300可以包括一個或複數個操作，動作或功能，如方框310、320、330和340中的一個或複數個所示。儘管被示為離散的方框，取決於期望的實現，可以將過程300的各個框劃分為另外的框，組合為更少的框或將其消除。此外，過程300的框可以按照第3圖中所示的順序執行或以其他順序排列。過程300可以由通信裝置210或任何合適的UE或機器類型的裝置來實現。僅出於說明性目的而非限制，下面在通信裝置210的情形中描述過程300。過程300可以在框310處開始。

在310，過程300可以包括裝置210的處理器212確定服務的延遲要求是否小於閾值。過程300可以從310進行到320。

在320處，過程300可包括處理器212在服務的延遲要求不小於閾值的情況下使用第一處理時間能力來執行傳輸。處理300可以從320進行到330。

在330處，過程300可包括處理器212在服務的延遲要求小於閾值的情況下使用第二處理時間能力來執行傳輸。過程300可以從330進行到340。

在340，過程300可以包括處理器212在使用第二處理時間能力時應用排程限制/優化來執行傳輸。

在一些實施方式中，排程限制/優化可以包括TBS值的限制範圍，或 TBS/資料速率的上限。

在一些實現中，排程限制/優化可以包括受限的最大BW大小。

在一些實現中，排程限制/優化可以包括取消對CBG傳輸或HARQ碼本的支持。

在一些實現中，排程限制/優化可以包括將HARQ回饋限制為特定的PUCCH格式。

在一些實現中，排程限制/優化可以包括取消對HARQ回饋和其他UCI的複用。

在一些實現中，排程限制/優化可以包括使用基於序列的編碼或Reed-Muller編碼來編碼UCI有效載荷。

在一些實施方式中，排程限制/優化可以包括取消對PUSCH傳輸上的UCI搭載的支持。

在一些實施方式中，過程300可以包括處理器212接收PUCCH格式的預先知識。過程300可以進一步包括處理器212在不譯碼DCI的情況下根據預先知識確定PUCCH格式。

在一些實施方式中，服務可以包括URLLC服務或eURLLC服務。補充說明

本文描述的主題有時示出包含在不同其他組件內或與不同其他組件連接的不同組件。要理解的是，這樣描繪的架構僅僅是示例，並且實際上可以實施可實現相同的功能的許多其他架構。在概念上，實現同一功能的任何佈置的複數個組件是有效地“關聯的”，以實現期望的功能。因此，組合以實現特定功能的任何兩個組件可以被視為彼此“相關聯”，以實現期望的功能，而不考慮架構或中間組件。同樣地，如此關聯的任何兩個組件也可以被視為彼此“可操作地連接”或“可操作地耦接”以實現期望的功能，並且能夠如此關聯的任何兩個組件也可以被視為“可操作地彼此耦接”以實現所需的功能。可操作耦接的具體示例包括但不限於物理上可配對和/或物理上相互作用的組件和/或可無線交互和/或無線作用的組件和/或邏輯上相互作用和/或邏輯上可交互的組件。

此外，關於本文使用的任何複數和/或單數，所屬技術領域具有通常知識者可以從適合上下文和/或申請的角度將複數轉換為單數和/或將單數轉換為複數。本文各種單數/複數的闡述僅僅為清楚起見。

此外，所屬技術領域具有通常知識者將理解，通常，本文使用的術語，尤其是所附申請專利範圍中的術語，例如所附申請專利範圍的正文，通常旨在作為“開放式”的術語，例如，術語“包括”應解釋為“包括但不限於”，術語“具有”應解釋為“至少具有”，複數術語“包括”應解釋為“包括但不限於”，所屬技術領域具有通常知識者將進一步理解，如果意圖引入特定數量到申請專利範圍中的敘述，則在申請專利範圍中將明確地陳述這樣的意圖，並且在沒有這樣的敘述的情況下，不存在這樣的意圖。例如，為了幫助理解，以下所附申請專利範圍可以包含介紹性短語“至少一個”和“一個或複數個”來介紹申請專利範圍的敘述。然而，這些短語的使用不應被解釋為暗示由不定冠詞“一”或“一個”介紹的申請專利範圍敘述限制為任何特定申請專利範圍僅包含一個這樣的敘述的實施，即使相同的申請專利範圍包括介紹性的短語“一個或複數個”或“至少一個”，並且諸如“一個”或“一個”的不定冠詞，例如“一個”和/或“一個”應所述被解釋為“至少一個”或“一個或複數個”；這種解釋同樣適用於使用定冠詞來介紹申請專利範圍的敘述。另外，即使明確地引用了特定數量的介紹性的申請專利範圍敘述，所屬技術領域具有通常知識者將認識到，這種敘述應被解釋為至少表示所引用的數量，例如，簡單敘述的“兩個敘述”，沒有其他修飾語，表示至少兩個敘述，或兩個或複數個敘述。此外，在使用類似於“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”的可能性。

從前述內容可以理解，本文已經出於說明的目的描述了本公開的各種實現，並且在不脫離本公開的範圍和精神的情況下可以進行各種修改。因此，本文公開的各種實現不旨在限制由所附申請專利範圍指示的真實範圍和精神。

100:示例表 210:通信裝置 220:網絡裝置 310，320，330，340 :方框 214，224:記憶體 212，222:處理器 216，226:收發器 300:過程

包括附圖以提供對本公開的進一步理解，並且附圖被併入本公開並構成本公開的一部分。附圖示出了本公開的實施方式，並且與說明書一起用於解釋本公開的原理。可以理解的是，附圖不一定按比例繪製，因為為了清楚地示出本公開的概念，某些組件可能被顯示為與實際實現中的尺寸不成比例。 第1圖是描繪根據本公開的實施方式的方案下的示例表的圖。 第2圖是根據本公開的實施方式的示例通信裝置和示例網絡裝置的框圖。 第3圖是根據本公開的實施方式的示例過程的流程圖。

100:示例表

Claims (20)

1. 一種處理時間線增強的方法，包括：裝置的處理器確定服務的延遲要求是否小於閾值；在所述服務的延遲要求不小於所述閾值的情況下，所述處理器使用第一處理時間能力來執行傳輸；在所述服務的延遲要求小於所述閾值的情況下，所述處理器使用第二處理時間能力來執行所述傳輸；和當使用所述第二處理時間能力時，所述處理器應用排程限制來執行所述傳輸。
2. 根據申請專利範圍第1項所述的方法，其中所述排程限制包括傳輸塊大小值的限制範圍，或傳輸塊大小或資料速率的上限。
3. 根據申請專利範圍第1項所述的方法，其中所述排程限制包括受限制的最大帶寬大小。
4. 根據申請專利範圍第1項所述的方法，其中所述排程限制包括取消對碼塊組傳輸或混合自動重傳請求確認碼本的支持。
5. 根據申請專利範圍第1項所述的方法，其中所述排程限制包括將混合自動重發請求確認回饋限制為特定的物理上行鏈路控制信道格式。
6. 根據申請專利範圍第1項所述的方法，其中所述排程限制包括取消混合自動重複請求確認回饋和其他上行鏈路控制信息的複用。
7. 如申請專利範圍第1項所述的方法，其中所述排程限制包括使用基於序列的編碼或Reed-Muller編碼來編碼上行鏈路控制信息有效載荷。
8. 根據申請專利範圍第1項所述的方法，其中所述排程限制包括取消對物理上行鏈路共享信道傳輸上的上行鏈路控制信息搭載的支持。
9. 根據申請專利範圍第1項所述的方法，還包括： 所述處理器接收物理上行鏈路控制信道格式的預先知識；和所述處理器在不對下行控制信息進行譯碼的情形下，根據所述預先知識確定所述物理上行鏈路控制信道格式。
10. 根據申請專利範圍第1項所述的方法，其中所述服務包括超可靠和低延遲通信服務或增強型超可靠和低延遲通信服務。
11. 一種通信裝置，包括：收發器，其在操作過程中與無線網絡的網絡節點進行無線通信；和通信耦合到所述收發器的處理器，以便在操作期間，所述處理器執行的操作包括：確定服務的延遲要求是否小於閾值；在所述服務的延遲要求不小於所述閾值的情況下，使用第一處理時間能力來執行傳輸；在所述服務的延遲需求小於所述閾值的情況下，使用第二處理時間能力來執行所述傳輸；和當使用所述第二處理時間能力時，應用排程限制來執行所述傳輸。
12. 根據申請專利範圍第11項所述的裝置，其中所述排程限制包括傳輸塊大小值的限制範圍，或所述傳輸塊大小或資料速率的上限。
13. 根據申請專利範圍第11項所述的裝置，其中所述排程限制包括受限制的最大帶寬大小。
14. 根據申請專利範圍第11項所述的裝置，其中所述排程限制包括取消對碼塊組傳輸或混合自動重傳請求確認碼本的支持。
15. 根據申請專利範圍第11項所述的裝置，其中所述排程限制包括將混合自動重傳請求確認回饋限制為特定的物理上行鏈路控制信道格式。
16. 根據申請專利範圍第11項所述的裝置，其中所述排程限制 包括取消混合自動重複請求確認回饋和其他上行鏈路控制信息的複用。
17. 根據申請專利範圍第11項所述的裝置，其中所述排程限制包括使用基於序列的編碼或Reed-Muller編碼來編碼上行鏈路控制信息有效載荷。
18. 根據申請專利範圍第11項所述的裝置，其中所述排程限制包括取消對物理上行鏈路共享信道傳輸上的上行鏈路控制信息搭載的支持。
19. 根據申請專利範圍第11項所述的裝置，其中在操作期間，所述處理器還執行以下操作：經由所述收發器接收物理上行鏈路控制信道格式的預先知識；和在不對下行控制信息進行譯碼的情況下，根據所述預先知識確定物理上行鏈路控制信道格式。
20. 根據申請專利範圍第11項所述的裝置，其中所述服務包括超可靠和低延遲通信服務或增強型超可靠和低延遲通信服務。

Images