5G NR PDCCH：UE 已配置 USS 後，為什麼仍需要監控 CSS？¶

狀態：已發布
領域：無線通訊／5G NR／PDCCH Receiver
基準版本：3GPP Release 18 V18.5.0（i50）
理解確認：Kent 已於 2026-08-27 完成核心概念問答
內容核准：Kent 已於 2026-08-27 核准本文發布

這篇文章回答什麼問題？

UE 進入 RRC_CONNECTED 並配置 UE-specific Search Space（USS）後，為什麼仍可能需要監控 Common Search Space（CSS）？當 CSS 與 USS 的 PDCCH candidates 使用相同 CCE、相同 DCI payload size，甚至相同 scrambling 時，接收器如何計數 Blind Decode、避免重複運算，並防止把同一串 bits 解讀成不同 DCI？本文從 Search Space、DCI format、scrambling、RNTI、Polar decoding hypothesis 到規格中的 candidate overlap 規則，建立可直接用於接收器設計與除錯的判斷流程。

規格版本

本文已核對 3GPP TS 38.211 V18.5.0、TS 38.212 V18.5.0、TS 38.213 V18.5.0 與 TS 38.331 V18.5.0 的官方 i50 文件。Release 不同時，新增的 DCI format、Search Space extension 與 capability 規則可能不同。

適用範圍

本文聚焦 NR PDCCH 的 CSS／USS monitoring、DCI 0_0／1_0／0_1／1_1 與 candidate overlap。它不展開完整 PDCCH Polar list decoder、所有 Release 17／18 multicast DCI，或每一種跨載波 Search Space sharing。文中的接收器流程是依規格整理的工程模型，不代表特定晶片內部架構。

先看結論¶

USS 不會取代 CSS。 UE 依 Active DL BWP 上的 Search Space 配置、Monitoring Occasion 與當下程序，監控適用的 CSS 和 USS；但也不是在 RRC_CONNECTED 後無條件監控全部 CSS。
CSS 不只承載所有 UE 共用的訊息。 Type3 CSS 可用 C-RNTI、CS-RNTI 或 MCS-C-RNTI 傳送特定 UE 的 DCI 0_0／1_0 fallback scheduling。
USS 不只承載 DCI 0_1／1_1。 SearchSpace 的 ue-Specific 配置可選 0_0／1_0，或 0_1／1_1；後續 Release 另有擴充格式。
相同 CCE 不等於相同 decoding hypothesis。 還必須比較 DCI size、PDCCH scrambling、CRC-scrambling RNTI、DCI format 與 Search Space context。
相同 DCI size 本身不足以消除重複 decoding。 不同 CCE 會帶來不同接收 LLR；不同 scrambling 也會產生不同 descrambled LLR。
Fallback DCI 不等於弱訊號模式。 DCI 0_0／1_0 是較精簡、配置依賴較少的基本排程格式，不應簡化成「RF 差才用」。
CSS 1_0 與 USS 1_1 若所有可區分條件都相同，會形成真正語意歧義。 1_0 與 1_1 沒有可直接在相同 decoded bits 中辨識兩者的專用 format bit；網路設計應以不同 CCE、size、scrambling 或 RNTI 等方式消除歧義。

一、先分清 CORESET、Search Space 與 DCI¶

CORESET：PDCCH 可以落在哪些實體資源¶

Control Resource Set（CORESET）定義 PDCCH 可使用的時頻資源與 CCE／REG mapping。它回答的是：

PDCCH 可能出現在哪一塊實體資源？

Search Space Set：UE 在何時搜尋哪些 candidates¶

Search Space Set 定義：

關聯的 CORESET。
Monitoring periodicity／offset。
Slot 內 monitoring symbols。
各 Aggregation Level 的 candidate 數量。
Search Space 類型與可監控 DCI formats。

它回答的是：

UE 應在何時、哪些 CCE candidate、以哪些 DCI hypotheses 搜尋 PDCCH？

DCI：成功解碼後的控制內容¶

接收器概念流程是：

Search Space configuration
→ 產生 PDCCH candidates
→ 從 CORESET 取出 candidate 對應 RE
→ Descrambling／Rate recovery
→ Polar decoding
→ RNTI／CRC check
→ 依 DCI format 與 Search Space context 解析欄位

因此，「解 CSS」不是把整個 CORESET 無差別解一次，而是在 CSS 的 Monitoring Occasion 對其 candidates 執行指定的 decoding hypotheses。

二、CSS 與 USS 不是替代關係¶

TS 38.213 §10.1 說明 UE 的 PDCCH candidates 由一組或多組 CSS／USS sets 定義。USS 的出現只是增加 UE-specific 搜尋配置，不會自動取消 CSS 的程序用途。

是否監控某個 Search Space，至少要看：

1. 它是否配置在目前的 Active DL BWP？
2. 當前 Slot／Symbol 是否是它的 Monitoring Occasion？
3. UE 當下是否適用對應程序、DCI format 與 RNTI？
4. Candidate 是否落在 UE capability 與 BD／CCE 限制內？

所以較精確的說法是：

UE 配置 USS 後，仍須依 Active DL BWP 配置與當下程序監控適用 CSS；USS 不會取代 SI、Random Access、Paging／Short Message、Group-common control 或 fallback scheduling 所需要的 CSS。

三、RRC_CONNECTED UE 可能遇到哪些 CSS？¶

以下是 TS 38.213 V18.5.0 §10.1 的主要分類；Release 17／18 另有 Type0B、Type1A、Type2A 等擴充。

CSS 類型	主要配置／用途	典型 DCI／RNTI	RRC_CONNECTED 下的意義
Type0	SIB1	DCI 1_0／SI-RNTI	Active BWP 配置與程序適用時仍可能需要
Type0A	其他 System Information	DCI 1_0／SI-RNTI	依 SI acquisition 與 RRC 程序決定
Type1	Random Access	RA-RNTI、MsgB-RNTI、TC-RNTI	Connected UE 在 UL sync、BFR、handover 等情況仍可能 RA
Type2	Paging／Short Message	DCI 1_0／P-RNTI	可涉及 SI change、ETWS／CMAS 等 indication
Type3	Configured common search space	C-RNTI、CS-RNTI、MCS-C-RNTI、SFI-RNTI、INT-RNTI、TPC-RNTI 等	最常與 USS 並存，支援 fallback scheduling 與 group-common control

為什麼 Type3 CSS 特別重要？¶

在正常 RRC_CONNECTED、沒有進行 Random Access 或 SI acquisition 時，Type3 CSS 最可能持續與 USS 並存。它可承載：

Type3 CSS
├─ 特定 UE 的 fallback scheduling
│  └─ DCI 0_0／1_0，CRC 可由 C-RNTI 等 scrambling
│
└─ Group-common control
   ├─ SFI-RNTI
   ├─ INT-RNTI
   ├─ TPC-PUSCH-RNTI
   ├─ TPC-PUCCH-RNTI
   └─ TPC-SRS-RNTI

Common Search Space 的 common 描述 Search Space／candidate 的配置方式，不表示其中只能放所有 UE 共用的訊息。

四、DCI format 與 CSS／USS 的合法組合¶

TS 38.331 的 SearchSpace IE 定義：

searchSpaceType = common
→ 可配置 dci-Format0-0-AndFormat1-0
→ 也可配置 DCI 2_x 等 group-common formats

searchSpaceType = ue-Specific
→ formats0-0-And-1-0
或 formats0-1-And-1-1
→ 後續 Release 另有 0_2／1_2 等擴充

因此：

組合	是否成立
CSS 監控 0_0／1_0	可以，由配置與 CSS 類型決定
USS 監控 0_0／1_0	可以
USS 監控 0_1／1_1	可以
CSS 監控 0_1／1_1	不屬於此基本 SearchSpace 配置

常見配置可能是：

Type3 CSS → DCI 0_0／1_0
USS       → DCI 0_1／1_1

但不能把它誤認為唯一配置。

五、Fallback 與 Non-fallback 的真正差別¶

Fallback DCI 0_0／1_0¶

主要特性：

欄位較精簡。
對 UE-specific RRC 配置的依賴較少。
適合基本 UL／DL scheduling。
可依配置在 CSS 或 USS 監控。

Non-fallback DCI 0_1／1_1¶

主要特性：

在 USS 中監控。
欄位較完整，且更依賴 UE-specific 配置。
可支援更多 BWP、Carrier、MIMO、SRS、Antenna port 與 HARQ 相關控制。

不該如何理解 Fallback？¶

錯誤簡化：

Fallback = 弱訊號時才使用
Non-fallback = 強訊號時使用

較正確的理解：

Fallback
→ 較精簡、配置依賴較少的 scheduling format

Non-fallback
→ 功能較完整、配置依賴較高的 scheduling format

Fallback 仍依賴 Search Space、CORESET、BWP、RNTI 與部分 RRC context；它不是任何配置不同步時都保證可解的「全域安全格式」。

接收器可把一個 hypothesis 拆成：

Candidate CCE set
× Aggregation Level
× DCI payload size
× PDCCH scrambling hypothesis
× CRC-scrambling RNTI hypothesis
× DCI format
× Search Space／BWP context

只有在規格允許，而且關鍵維度等價時，才可能共用或消除 decoding。

為什麼不同 CCE 必須分別 Decode？¶

不同 CCE
→ 不同 PDCCH RE／接收樣本
→ 不同 LLR
→ 必須個別 Rate recovery、Polar decoding 與 CRC check

即使 DCI size、scrambling 與 RNTI 相同，只要 CCE 不同，實體輸入就不同。

為什麼不同 Scrambling 也必須分開？¶

相同接收 RE
× 不同 scrambling sequence
→ 不同 descrambled LLR
→ 不同 decoding hypothesis

TS 38.211 §7.3.2.3 定義 PDCCH scrambling；USS 在配置 pdcch-DMRS-ScramblingID 時，可使用對應 identity 與 C-RNTI 形成的 scrambling context，其他情況則依條文使用 cell identity／對應值。判斷 candidate 是否可去重時，不能省略 identical scrambling 條件。

為什麼不同 Payload Size 不能只 Decode 一次？¶

令：

A = DCI payload bits
CRC = 24 bits
K = A + 24
E = PDCCH rate-matched coded bits

同一 Aggregation Level 可提供相同的 E，但不同 A 會改變 K，也可能改變 Polar code construction、Information／Frozen bit 位置與 Rate recovery／decoding hypothesis。

接收器必須先選定配置允許的 DCI size，再執行相應 Polar decoding，最後才用 CRC／RNTI 驗證。CRC 不是讓一次通用 decoding 自動辨識任意 DCI length 的工具。

七、為什麼 DCI Size Alignment 必要？¶

若每個 candidate 都嘗試大量 payload sizes，複雜度會近似沿著以下維度增加：

Candidate 數
× DCI sizes
× Scrambling hypotheses
× RNTI hypotheses
× Polar list-decoding 成本

代價包括：

基頻運算量與功耗。
PDCCH processing latency。
Decoder memory／buffer。
硬體 decoder 並行需求。
多次嘗試累積的 false-alarm 風險。

TS 38.212 §7.3.1.0 因此規定 DCI size alignment、padding／truncation，並限制 UE 每個 cell 所需監控的不同 DCI sizes。

一個常被說得太廣的 Padding 規則¶

Release 18 V18.5.0 的條文是：

USS 中的 DCI 0_1／1_1
若與另一個 USS 中的 DCI 0_0／1_0 同長
→ 在 0_1／1_1 加一個 zero-padding bit

條文寫的是 another UE-specific search space。不能把它擴張成「只要 CSS 的 1_0 與 USS 的 1_1 同長，規格一定自動加一 bit」。

八、CSS／USS Candidate 重疊如何處理？¶

一般 Candidate Monitoring 計數規則¶

TS 38.213 §10.1 規定：若較小 Search Space Set index 已有 candidate，而另一 candidate 在相同 CORESET 使用：

相同的一組 CCE。
Identical scrambling。
相同 DCI size。

則後面的 candidate 不再另計一次 monitoring。這是 Blind Decode／candidate counting 的去重規則。

它不能被簡化成：

只要 CCE 重疊，永遠 CSS 優先

規格明確指定的 Fallback 特例¶

TS 38.213 §10.1 另有更具體的條件：

第一個 candidate：CSS，監控 DCI 0_0／1_0
第二個 candidate：USS，監控 DCI 0_0／1_0
兩者不含 searchSpaceLinkingId
位於 Active DL BWP 的 CORESET 0
DCI 0_0／1_0 size 相同
使用相同的一組 CCE
Identical scrambling
CRC scrambled by C-RNTI、MCS-C-RNTI 或 CS-RNTI

符合時，UE只解 CSS candidate 所關聯的 DCI 0_0／1_0。

原始討論若只寫成「相同 CCE、相同 payload size時 CSS 優先」，會漏掉 CORESET 0、identical scrambling、DCI pair、RNTI 與 searchSpaceLinkingId 等條件。

九、同一串 Bits 為什麼可能對應不同參數？¶

Physical decoding 與 Semantic parsing 必須分開：

接收 LLR
→ Polar decoding
→ decoded bit vector
→ 套用 DCI format＋Search Space＋BWP context
→ 最終 scheduling parameters

以 DCI 0_0 的 Frequency-domain Resource Assignment 為例，TS 38.212 §7.3.1.0 區分：

CSS 中的 DCI 0_0：依 Initial UL BWP 大小決定。
USS 中的 DCI 0_0：一般依 Active UL BWP 大小決定。

假設：

CSS context：Initial UL BWP = 48 RB
USS context：Active UL BWP  = 50 RB
RIV = 100

兩邊 FDRA 都可能是 11 bits，但 RIV 解讀結果不同：

CSS／48 RB → RB_start = 4，L_RB = 3
USS／50 RB → RB_start = 0，L_RB = 3

因此，即使 Polar decoder 得到同一串 bits，後續套用不同 BWP context，仍可能產生不同資源配置。Overlap 規則不只節省運算，也必須提供唯一的語意路徑。

十、特別案例：CSS 的 DCI 1_0 與 USS 的 DCI 1_1 同長且 CCE 重疊¶

這個案例不能直接套用上一節「CSS 與 USS 都是 0_0／1_0」的明確特例。

情況 A：PDCCH Scrambling 不同¶

同一組接收 symbols
├─ CSS descrambling hypothesis → Decode → CRC check
└─ USS descrambling hypothesis → Decode → CRC check

Descrambled LLR 不同，因此是不同 hypotheses。哪一條 CRC pass，可協助識別實際傳輸路徑。

情況 B：PDCCH Scrambling 相同，但 CRC-scrambling RNTI 不同¶

例如 CSS 使用程序性／common RNTI，USS 的 1_1 使用 C-RNTI。UE 可用不同 RNTI masks 驗證 CRC，藉此識別適用的 hypothesis。

情況 C：所有可區分條件都相同¶

假設：

CSS：DCI 1_0，CRC scrambled by C-RNTI
USS：DCI 1_1，CRC scrambled by同一個 C-RNTI
相同 CCE／Aggregation Level
相同 DCI payload size
Identical PDCCH scrambling

這會形成真正的 semantic ambiguity：

DCI 1_0 與 1_1 的 Identifier for DCI formats 都是 1，只表示 DL DCI。
相同 RNTI 讓 CRC check 無法指出應採 1_0 還是 1_1。
相同 size 與 scrambling 也無法提供額外區分。
同一 decoded bit vector 可被兩種欄位結構解析，但結果可能不同。

TS 38.213 的一般 candidate rule可讓重疊 candidate不重複計入 monitoring；但本文核對到的明確「只解 CSS」條文，是前述 CSS／USS 都監控 0_0／1_0 的 CORESET 0 特例，不能直接外推成混合 1_0／1_1 時的通用格式判定規則。

因此工程上不應期待 UE 從 CRC 猜出 1_0 或 1_1。gNB 的 Search Space 與 scheduler設計應以至少一種方式消除歧義：

使用不同 CCE。
使用不同 PDCCH scrambling。
讓 DCI payload sizes 不同。
使用可區分的 CRC-scrambling RNTI／程序。
不在該完全重疊 candidate 上傳送語意無法識別的 DCI 1_1。

十一、接收器判斷流程¶

CSS 與 USS candidates 是否使用相同 CCE set？
│
├─ 否
│  → 不同實體輸入，分別 Decode
│
└─ 是
   │
   ├─ DCI size 不同
   │  → 不同 Polar hypotheses，分別 Decode
   │
   └─ DCI size 相同
      │
      ├─ PDCCH scrambling 不同
      │  → 不同 descrambled LLR，分別 Decode
      │
      └─ PDCCH scrambling 相同
         │
         ├─ RNTI／CRC hypothesis 可區分
         │  → 依各自 hypothesis驗證
         │
         └─ RNTI／CRC hypothesis也相同
            │
            ├─ 符合 TS 38.213 明確 overlap 特例
            │  → 按該條文指定路徑處理
            │
            └─ 不符合明確特例且 formats語意不同
               → 不可由 CRC 猜測；配置／排程必須避免歧義

十二、接收器與除錯清單¶

配置面¶

Active DL BWP 上有哪些 CSS／USS sets？
每個 Search Space 關聯哪個 CORESET？
searchSpaceType 與 dci-Formats 配置為何？
Monitoring periodicity、offset、symbols 與 candidate counts 是否正確？
Type3 CSS 是否配置 C-RNTI fallback scheduling 或 group-common DCI？

Candidate 產生面¶

CSS 與 USS 的 Search Space Set index。
Aggregation Level 與 candidate index。
First CCE 與完整 CCE set。
searchSpaceLinkingId 是否存在。
是否因 BD／non-overlapped CCE limits 被移除或未配置 monitoring。

Decode hypothesis 面¶

DCI payload size 是否經正確 alignment？
PDCCH scrambling identity 與 RNTI context 是否正確？
CRC 應嘗試哪些 RNTI masks？
同長 DCI 是否被錯誤當成同一 format？
CSS／USS parsing 是否套用正確 BWP size？

常見症狀¶

症狀	優先檢查
USS DCI 偶發解不到	Candidate overlap、scrambling、BD allocation、Search Space Set index
CRC pass 但 PDSCH 資源錯誤	DCI format／Search Space／BWP context是否用錯
1_0／1_1 同長時結果不穩定	是否存在相同 CCE、scrambling、RNTI 的 semantic ambiguity
重複消耗 Polar decoder 資源	Candidate 去重條件是否少檢查 size 或 identical scrambling
切換 BWP 後 0_0 資源錯位	Initial／Active BWP 的 FDRA context是否混用

十三、對原始討論的整理與修正¶

原始方向	判定	整理後表述
有 USS 後仍需監控 CSS	保留但加條件	依 Active BWP 配置、Monitoring Occasion與程序監控適用 CSS，不是無條件監控全部 CSS
CSS 只傳共同訊息	修正	Type3 CSS也可用 C-RNTI傳送特定 UE 的 fallback DCI
CSS配置 DCI 0_1	移除	0_1／1_1屬於 USS 的基本配置
USS只配置 0_1／1_1	修正	USS也可配置 0_0／1_0
Fallback是訊號差時的安全模式	修正	Fallback是較精簡、配置依賴較少的基本 scheduling format
相同 CCE與 size就只解一次	修正	還需 identical scrambling、format、RNTI與具體規格條件
相同 size可由 CRC自動辨識 format	修正	UE需先建立 size／Polar hypothesis；若 size、scrambling與 RNTI皆相同，CRC未必能區分 1_0／1_1
CSS與 USS重疊永遠 CSS優先	移除	明確 CSS解碼特例具有 0_0／1_0、CORESET 0等限制，不可通用外推
1_1與 CSS 1_0同長必定自動加一 bit	修正	TS 38.212明文 padding條件指向另一個 USS中的 0_0／1_0，不宜擴張至 CSS

十四、核心心智模型¶

Search Space不是單純的「去哪裡找」；
它也是 decoding hypothesis與 DCI parsing context的一部分。

相同 CCE
≠ 相同接收假設

相同 DCI size
≠ 相同 DCI format

CRC pass
≠ 自動知道應按哪個 Search Space context解析

最終可濃縮成一句話：

UE 必須以 CCE、size、scrambling、RNTI、DCI format與 Search Space context共同識別 PDCCH；只有在規格明確允許且所有關鍵條件等價時，才能安全消除重複 decoding。

延伸閱讀¶

回到〈L1 通訊：學術 vs 工程〉主題地圖。
若想延伸到低位元 UCI 的接收假設，可閱讀〈PUCCH Format 0：SR、HARQ-ACK 與 Cyclic Shift〉。
後續可再討論 PDCCH candidate hashing、Blind Decode capability 與跨載波 Search Space sharing。

來源¶

3GPP TS 38.211 V18.5.0，§7.3.2.3，官方 archive 38211-i50：https://www.3gpp.org/ftp/Specs/archive/38_series/38.211/38211-i50.zip
3GPP TS 38.212 V18.5.0，§7.3.1.0、§7.3.1.1、§7.3.1.2，官方 archive 38212-i50：https://www.3gpp.org/ftp/Specs/archive/38_series/38.212/38212-i50.zip
3GPP TS 38.213 V18.5.0，§10.1，官方 archive 38213-i50：https://www.3gpp.org/ftp/Specs/archive/38_series/38.213/38213-i50.zip
3GPP TS 38.331 V18.5.0，PDCCH-Config／SearchSpace IE與 SI acquisition程序，官方 archive 38331-i50：https://www.3gpp.org/ftp/Specs/archive/38_series/38.331/38331-i50.zip