114 調查局特考三等 電子科學組 通信與系統 考古題詳解

核心觀念

正交方形 16QAM 將資訊分別調變到同相軸 $I$ 與正交軸 $Q$。每個符號承載 $\log_2 16=4$ 個位元；兩軸彼此正交，因此可把 16QAM 視為兩個獨立的四電平 PAM 訊號。

題目未指定星座圖的位元標記方式。以下採用常見的相鄰點 Gray 編碼；若使用不同標記，BER 可能不同。AWGN 的同調接收可視為在 $I$、$Q$ 軸各加入變異數為 $N_0/2$ 的高斯雜訊。

解題方法：由四電平 PAM 推導 BER

令每軸四個振幅為 $-3a,-a,a,3a$，相鄰決策門檻位於 $-2a,0,2a$。每軸平均符號能量為

兩軸能量相加，故 16QAM 平均符號能量為 $E_s=10a^2$。每符號有 4 個位元，因此

令 $x=a/\sigma$，可得

每軸採用 Gray 標記 $00,01,11,10$。對四電平 PAM 逐一加總各判決區域造成的位元差異，平均每軸每位元錯誤率為

代入 $x=\sqrt{\frac{4}{5}\frac{E_b}{N_0}}$，得到 Gray 編碼 16QAM 的 BER：

核心觀念

本題考傅立葉轉換的定義、廣義函數 $1/t$ 的轉換，以及希爾伯特轉換（Hilbert transform）與其在通訊系統中的用途。由於 $1/t$ 在 $t=0$ 不可直接積分，以下以柯西主值（Cauchy principal value）解讀。

採用角頻率 $\omega$ 的傅立葉轉換定義：

在此慣例下，基本轉換對為：

其中 $\operatorname{sgn}(\omega)$ 是符號函數：$\omega>0$ 時為 $1$，$\omega<0$ 時為 $-1$。$\omega=0$ 處的值不影響此廣義函數轉換。

解題方法

題目給定：

利用線性性，將常數 $-j$ 提到傅立葉轉換之外：

因此：

若採用以頻率 $f$ 為變數的定義 $H(f)=\int h(t)e^{-j2\pi ft}\,dt$，答案相同，只需將 $\operatorname{sgn}(\omega)$ 改寫為 $\operatorname{sgn}(f)$。

轉換核函數的意義

標準希爾伯特轉換的時域核函數是：

核心觀念

RAKE 接收機利用無線通道的多重路徑傳播特性，將同一個傳送訊號經不同路徑抵達接收端的多個延遲版本分別接收，再依通道狀態加權並合併，以提升接收訊號的訊雜比與可靠度。

各路徑的延遲若足以區分，接收機便可用不同的「指狀單元」（finger）對準各路徑的到達時間。各指狀單元解展頻並估計通道增益後，再由合併器（常用最大比合併）相干合併。RAKE 因各指狀單元像耙子齒般收集多條路徑的能量而得名。

解題方法

作答時依序說明三件事：多重路徑如何提供可利用的分集、接收機如何同步及估計各路徑、各路徑訊號如何加權合併。方塊圖則依訊號處理順序標示同步、指狀解展頻、通道估計、合併與判決等模組。

（一）工作原理

無線通道中的反射、繞射與散射會使同一訊號沿不同路徑到達接收端。以簡化的基頻模型表示，接收訊號為

其中 $L$ 為可解析的多重路徑數，$h_\ell$ 與 $\tau_\ell$ 分別為第 $\ell$ 條路徑的複數通道增益與延遲，$s(t)$ 為傳送訊號，$n(t)$ 為雜訊。

RAKE 以多個指狀單元分別對準不同路徑延遲 $\tau_\ell$，將各路徑的訊號解展頻並估計其通道增益，最後把各路徑的訊號合併。這使原本可能因相位抵消而衰落的能量得以從其他路徑補回，形成多重路徑分集增益。

（二）在無線通訊中的作用與運作方式

作用

在 CDMA 等直接序列展頻系統中，RAKE 接收機可利用可解析的多重路徑能量，改善接收訊號的訊雜比、降低衰落造成的錯誤，並提升通訊可靠度。它不會把所有路徑都視為有害干擾，而是將延遲可區分的路徑當作分集訊號來源。

運作流程

1. 搜尋與同步： 搜尋器分析接收訊號的相關性，找出可解析路徑的延遲位置，並指派指狀單元追蹤這些延遲。
2. 各指狀單元解展頻： 第 $\ell$ 個指狀單元依估計的延遲 $\hat{\tau}_\ell$，將接收訊號與對應的展頻碼對齊並相關，取得該路徑的符號或判決統計量 $z_\ell$。
3. 通道估計與權重設定： 估計各路徑的通道係數 $\hat h_\ell$，依通道品質設定合併權重。常見的最大比合併會補償各路徑相位，並按其通道強度加權。
4. 合併與判決： 將各路徑輸出加權相加，形成合併結果，再進行解調或位元判決。

以最大比合併為例，若各路徑雜訊變異數相同，合併統計量可寫成

核心觀念

OFDM（正交分頻多工）將高速資料串流分成多個低速平行串流，分別調變到彼此正交的子載波上。理想情況下，接收端在每個 OFDM 符號的有效區間內執行 FFT，即可分離各子載波。

本題重點是說明兩種干擾的成因與抑制方式：

• ISI（符號間干擾）：多重路徑延遲使前一個 OFDM 符號的能量延伸到下一個符號。
• ICI（子載波間干擾）：子載波間的正交性遭破壞，使其他子載波的訊號洩漏至欲接收的子載波。

ISI 與 ICI 的成因及解決方法

ISI：符號間干擾

無線通道中的多重路徑會使同一訊號經不同路徑抵達接收端，形成延遲擴散。若通道的最大延遲超過 OFDM 符號的循環字首長度，前一符號的延遲訊號便會進入目前符號的有效取樣區間，造成 ISI。

解決方法：

1. 加入循環字首（Cyclic Prefix, CP）：將 OFDM 符號尾端的一段取樣複製到符號前端。若 CP 長度不小於通道最大延遲擴散，接收端移除 CP 後，FFT 的有效區間便不受前一符號干擾。
2. 增加 CP 長度：在通道延遲擴散較大的環境中，適度延長 CP；代價是傳輸效率降低。
3. 使用通道等化或時間域處理：若 CP 不足或通道條件特殊，可搭配等化器抑制殘餘干擾。

CP 是循環延伸，並非新增資訊。若有效符號長度為 $N$，CP 長度為 $N_{\mathrm{CP}}$，其傳輸效率為

ICI：子載波間干擾

理想 OFDM 子載波的頻率間隔為 $\Delta f=1/T_u$，其中 $T_u$ 為有效符號時間，因此在 FFT 區間內彼此正交。以下因素會破壞正交性：

• 載波頻率偏移（CFO）：發射端與接收端振盪器頻率不一致，或存在都卜勒頻移。
• 取樣時脈偏差：取樣頻率不準確，造成子載波頻率間隔與 FFT 視窗不匹配。
• 相位雜訊與快速通道變化：符號期間內相位或通道變化，使子載波能量擴散。
• FFT 視窗同步錯誤：FFT 區間未正確落在有效符號區間。

解決方法：

1. 載波同步：利用前導碼、訓練符號或導頻估計 CFO 與相位誤差，再進行頻率與相位補償。
2. 取樣時脈同步：校正取樣頻率及取樣時刻。
3. FFT 視窗同步：使 FFT 視窗落在 CP 保護範圍內，並涵蓋完整的有效符號區間。
4. 通道估測與等化：以導頻估計各子載波通道響應，進行頻域等化；若通道在符號期間變化明顯，需搭配追蹤或補償。
5. 降低都卜勒影響：在高速移動環境中，可採用更強的同步與通道追蹤設計。

**辨別重點：**CP 主要用來處理多重路徑造成的 ISI，並在 CP 足夠且同步正確時維持各子載波的正交性；它不能單獨消除 CFO、時脈偏差或相位雜訊所造成的 ICI。

完整 OFDM 系統方塊圖

核心觀念

本題在比較兩種通道錯誤更正碼的結構、解碼方式與效能特性，並依封包長度、延遲需求選擇適用的碼。

LDPC（低密度同位檢查碼）是線性區塊碼，以稀疏的同位檢查矩陣 $H$ 定義合法碼字 $x$：

Turbo Code 則通常由兩個或多個卷積碼編碼器及交錯器組成，解碼端以軟性輸入軟性輸出（SISO）解碼器反覆交換資訊，逐步改善判決。

兩者都能在適當碼長與解碼器設計下逼近通道容量；差異主要在編碼結構、解碼平行化、迭代需求，以及短碼長時的實際效能。

（一）LDPC 與 Turbo Code 優劣比較

LDPC 的主要優勢

1. 長碼長時錯誤更正效能佳 LDPC 可透過稀疏圖上的迭代訊息傳遞解碼，在長區塊下達到接近通道容量的效能，且具良好的錯誤更正能力。

2. 解碼易於平行化，適合高速實作 LDPC 解碼依 Tanner graph 上的節點與邊傳遞訊息，可同時處理多個節點或訊息，利於平行硬體架構，因此適合高資料率應用。

LDPC 的主要劣勢

1. 短碼長時效能較不理想 LDPC 的效能優勢通常在較長區塊較能發揮；短封包下，有限碼長效應可能使其錯誤率表現不如 Turbo Code 等方案。

2. 解碼器及矩陣結構設計較複雜 LDPC 的效能與 $H$ 矩陣的結構、節點度數及排程方式有關。高效能實作須處理大量訊息儲存與運算，硬體設計及功耗管理具有挑戰。

與 Turbo Code 的比較

Turbo Code 的迭代軟性解碼具有良好的錯誤更正效能，特別是在中短碼長時常有競爭力；但反覆解碼會增加延遲與運算量，平行化程度也通常不如 LDPC 解碼架構。

（一）HTTP/2 與 HTTP/3 在資料流控制上的主要差異

核心觀念

本題考的是接收端如何限制傳送端的資料量，以及多工資料流間是否會互相影響。流量控制的目的在於避免接收端緩衝區被資料塞滿；它不同於壅塞控制，後者是為了避免網路路徑過載。

解題方法

先看流量控制由哪一層負責，再比較控制單位與更新方式，最後說明封包遺失對多工資料流的影響。

HTTP/2 的傳送端必須同時遵守該資料流視窗與連線視窗限制。若某資料流或整條連線的額度不足，傳送端須等接收端釋出額度，才能繼續傳送受控的資料。

HTTP/3 的資料流控制由 QUIC 處理，HTTP 層不用另設 HTTP/2 式的流量控制框架。QUIC 的連線層額度仍會限制所有資料流的總量，因此 HTTP/3 並非沒有連線層流量控制；