LTE 測試文檔（翻譯）

本文轉載自查看原文 2016-06-06 10:52 2305 LTE/ NS3

Testing Documentation 翻譯

（如有不當的地方，歡迎指正！）

1 概述

為了測試和驗證 ns-3 LTE 模塊，文檔提供了幾個 test suites （集成在 ns-3 測試框架中）。為了運行它們，可以按照以下方式配置仿真器的 buid：

$ ./waf configure --enable-tests --enable-modules=lte --enable-examples
$ ./test.py

上述代碼將不僅運行 LTE 模塊的 test suites ，而且包括 LTE 模塊依賴的所有 ns-3 模塊。參見 ns-3 manual 了解更多有關測試框架的信息。

你可以使用下列方式得到一份更加詳細的 HTML 格式的報告：

$ ./test.py -w results.html

使用下列命令單獨運行每個 test suite：

$ ./test.py -s test-suite-name

詳情使用 test.py ，參見 ns-3 manual 了解更多有關測試框架的信息。

2 描述 test suites

2.1 Unit Tests（單元測試）

2.1.1 下行的 SINR 計算

test suite lte-downlink-sinr 檢查下行鏈路的 SINR 計算是否正確執行。下行鏈路的 SINR 計算分配給數據傳輸的每個 RB，通過將考慮基站（eNB）的目標信號功率除以噪聲功率的和加上來自其他基站（干擾信號）在同一RB 上傳輸的功率：

$\gamma = \frac{ P_\mathrm{signal} }{ P_\mathrm{noise} + \sum P_\mathrm{interference} }$

一般來說，不同的信號可以活躍在不同的時間周期。定義 chunk 作為任何兩種類型的事件的時間間隔，要么在波形開始的地方，要么在波形結束的地方。換句話說，chunk 標識一段時間間隔，在該時間間隔內，活躍波形（active waveforms）的設置不會改變。令

表示通用的 chunk，

為 chunk 的持續時間，

為 chunk 的 SINR ，使用上述等式計算。使用下公式列計算平均 SINR $\mathrm{SINR_i}$

（用於 CQI 反饋報告）： $\overline{\gamma}$

$\overline{\gamma} = \frac{ \sum_i {\gamma}_i T_i }{ \sum_i T_{i} }$

test suite 檢查上述計算是否在仿真中正確執行。測試向量通過 Octave 腳本（實現上述等式，重建若干隨機傳輸的信號和干擾信號，模擬這樣一個場景——用戶試圖從基站解碼信號，與此同時面臨來自其他基站的干擾）線下獲得。如果計算值等於測試向量值且容忍為

，則測試通過。容忍旨在考慮典型浮點運算的近似誤差。 $10^{-7}$

2.1.2 上行的 SINR 計算

test suite lte-uplink-sinr 檢查上行鏈路的 SINR 計算是否正確執行。該 test suite 與上一節描述的 lte-downlink-sinr test suite 相同，區別是信號和干擾現在參考用戶（UE）的傳輸，接收由基站執行。該 test suite 重建若干隨機傳輸的信號和干擾信浩，模擬這樣一個場景——基站試圖同時從幾個用戶（與基站在同一個小區）中解碼信號，與此同時面臨來自其他用戶（屬於其他小區）的干擾。

測試向量通過專用的 Octave 腳本獲得。如果計算值等於測試向量值且容忍為

，則測試通過。對於下行 SINR 測試，容忍旨在處理浮點運算的近似值。

2.1.3 E-UTRA Absolute Radio Frequency Channel Number (EARFCN，E-UTRA 絕對無線頻道編號)

test suite lte-earfcn 檢查類 LteSpectrumValueHelper （實現 LTE 頻譜模型）使用的載波頻率，按照 [TS36101] （定義EARFCN）完成。該 test suite 的測試向量包括一系列 EARFCN 值，並且相應的載波頻率是按照規范 [TS36101] 手工計算。如果 LteSpectrumValueHelper 返回的載波頻率與測試向量中每個元素已知的相同，則測試成功。

2.2 System Tests（系統測試）

2.2.1 Dedicated Bearer Deactivation Tests（專用承載去激活測試）

test suite lte-test-deactivate-bearer 創建單個 EnodeB 和3個 UE 的情形。每個 UE 包含一個默認的和一個專用的 EPS 承載，使用相同的承載規范，但是 ARP（地址解析協議）不同。

Test Case Flow 如下： Attach UE -> Create Default+Dedicated Bearer -> Deactivate one of the Dedicated bearer

測試例子進一步去激活（ deactivates ）專用無線承載（第一個用戶（UE_ID=1）的承載 ID 2（LCID=BearerId+2））。通過使用 Simulator::Schedule () 方法，在特定的時延后，用戶可以調度承載去激活。

一旦測試例子執行結束，它會創建 DlRlcStats.txt 和 UlRlcStats.txt。統計數據中需檢查的關鍵字段有：

測試例子分3個時期執行：

第一階段 (0.04s-1.04s)，所有用戶和相應承載 get attached ，且專用承載的數據包流激活。
第二階段 (1.04s-2.04s)，實例化承載去激活，因此相比其他承載，用戶在 UE_ID=1 和 LCID=4 會看到相對較少數目的 TxBytes 。
第三階段 (2.04s-3.04s) ，既然 UE_ID=1 和 LCID=4 的承載去激活已經完成，用戶將不會看到與 LCID=4 相關的任何日志。

測試通過，當且僅當：

IMSI=1 且 LCID=4 在第三階段完全移除
與 IMSI=1 和 LCID=4 相關的 TxBytes 和 RxBytes 無數據包可見

如果上述條件不匹配，則認為測試例子沒有通過。

2.2.2 Adaptive Modulation and Coding Tests（自適應調制和編碼測試）

test suite lte-link-adaptation 提供系統測試，重建單個基站和單個用戶的場景。對於用戶感知到的不同 SNR 值，會創建相應的不同的 test cases。 test 的目標是檢查在每個 test case 中，選定的 MCS 符合一些已知的參考值。這些參考值通過重新實現 Octave （見 src/lte/test/reference/lte_amc.m ）中 Adaptive Modulation and Coding 這一節描述的模型來獲得，用於計算頻譜效率，並且通過手動查閱 [R1-081483] 中的表格確定相應的 MCS index 。生成的測試向量見圖 Test vector for Adaptive Modulation and Coding 。

仿真器使用的 MCS 通過獲取由調度器在 4ms （考慮 CQI 報告中的初始時延，這是必要的）后產生的 tracing 輸出來測量。仿真器計算的 SINR 也是通過使用 LteChunkProcessor 接口獲取的。如果下列兩種條件同時滿足，則測試通過：

仿真器計算的 SINR 符合測試向量的 SNR ，絕對容忍為；
仿真器使用的 MCS index 完全符合測試向量中的 MCS index。

Test vector for Adaptive Modulation and Coding

2.2.3 Inter-cell Interference Tests（小區間干擾測試）

test suite lte-interference 提供系統測試，重建一個小區間干擾場景，有兩個基站，每個基站有一個用戶與其連接，在上行和下行鏈路同時采用自適應調制和編碼（AMC）。圖 Topology for the inter-cell interference test 描述了場景的拓撲結構。參數

表示每個用戶與它連接的基站之間的距離，然而參數

表示干擾距離。我們注意到，這樣的場景拓撲導致上行和下行的干擾距離是相同的；當然，感知到的實際干擾功率是不同的，原因是上行和下行頻帶不同的傳播損耗。通過改變 d_2

和

參數，可以獲得不同的 test cases 。 d_1

_images/lte-interference-test-scenario.png

Topology for the inter-cell interference test

測試向量通過使用專用的 octave 腳本（ src/lte/test/reference/lte_link_budget_interference.m），計算每種 test case 拓撲對應的鏈路預算（包括干擾），輸出作為結果的 SINR 和頻譜效率。后者然后用於確定（與 Adaptive Modulation and Coding Tests 使用的過程相同）？注意到測試向量包含分別用於上行和下行的各自值。

2.2.4 UE Measurements Tests（用戶測量測試）

test suite lte-ue-measurements 提供系統測試，重建的小區間干擾場景與 lte-interference test-suite 中定義的相同。然而，在該測試中，測試的數量通過 RSRP 和 RSRQ 測量值（通過把用戶放入到堆棧的兩個不同點）表示：source—— UE PHY layer， destination—— eNB RRC 。

測試向量通過使用專用的 octave 腳本（src/lte/test/reference/lte-ue-measurements.m）獲得，計算每種 test case 拓撲對應的鏈路預算（包括干擾），輸出作為結果的 RSRP 和 RSRQ 。所得值然后用於檢查物理層用戶測量的正確性。此后，它們必須根據 3GPP 格式轉換，目的是用於檢查它們在基站 RRC 級別的正確性。

2.2.5 UE measurement configuration tests（用戶測量配置測試）

除了前面提及的 test suite，還存在3種其他 test suites 用於測試用戶測量： lte-ue-measurements-piecewise-1、lte-ue-measurements-piecewise-2 和 lte-ue-measurements-handover。這些 test suites 更加關注上報觸發過程，例如，這里已經驗證了基於事件觸發標准的實現的正確性。

更具體的說，測試驗證了基站接收到的每個測量報告的 timing 和 content 。每種 test case 都是一個獨立的 LTE 仿真，並且如果測量報告只在規定的時間發生且顯示正確級別的 RSRP（此刻還沒有驗證 RSRQ ），則 test case 通過。

（1）Piecewise configuration（分段配置）

piecewise configuration 旨在測試特定的用戶測量配置。仿真腳本將對用戶（整個仿真中為活躍態）設置相應的測量配置。

既然參考值是通過手算預先算好的，我們做幾個假設來簡化仿真。首先，信道只受路徑損耗模型的影響（這種情況下，使用 Friis 模型）。其次，使用理想的 RRC 協議，並且禁用 layer 3 filtering 。最后，用戶使用預定義的運動模式——在4個不同的點間移動，如下圖 UE movement trace throughout the simulation in piecewise configuration 。因此，可以更容易確定測量的 RSRP 的波動。

UE movement trace throughout the simulation in piecewise configuration

預定義的點之間的 “teleport” 背后的動機是引進 RSRP 水平的劇烈變化，這將確保進入觸發或測試事件的離開條件觸發。通過執行劇烈的變化，測試可以在更短的時間內運行。

下圖 Measured RSRP trace of an example Event A1 test case in piecewise configuration 表示，在仿真期間使用 piecewise configuration，在物理層的 layer 1 過濾完后測量 RSRP。由於不能使用 layer 3 過濾，因此這些值是精確值（由用戶 RRC 實例使用的），目的是用於估計上報觸發過程。注意，這些值每 200 ms 會更新一次，其中 200 ms 是物理層測量報告的默認過濾周期。該圖也表明，在仿真期間當 Event A1（服務小區比該閾值好）實例的進入和離開條件發生時的時間。

Measured RSRP trace of an example Event A1 test case in piecewise configuration

每個報告標准使用不同的閾值/偏移參數測試幾次。一些測試場景會考慮滯后現象（Hysteresis ）和 time-to-trigger 。下圖 Measured RSRP trace of an example Event A1 with hysteresis test case in piecewise configuration 描述了另一個例子 Event A1 測試的滯后現象。

Measured RSRP trace of an example Event A1 with hysteresis test case in piecewise configuration

Piecewise configuration 用於用戶測量的兩種 test suites 。第一種是 lte-ue-measurements-piecewise-1，此后稱為 Piecewise test #1，仿真一個用戶和一個基站。另一種是 lte-ue-measurements-piecewise-2，仿真一個用戶和兩個基站。

Piecewise test #1 用於測試基於事件的標准，不依賴相鄰小區的存在。這些標准包括 Event A1 和 A2 。在缺乏任何相鄰小區的情況下，其余的事件也會進行簡短地測試，用於確認它們是否正常工作（盡管沒有上報任何東西。下表 UE measurements test scenarios using piecewise configuration #1 列舉了 piecewise test #1 中測試的場景。

UE measurements test scenarios using piecewise configuration #1

Test #	Reporting Criteria	Threshold/Offset	Hysteresis	Time-to-Trigger
1	Event A1	Low	No	No
2	Event A1	Normal	No	No
3	Event A1	Normal	No	Short
4	Event A1	Normal	No	Long
5	Event A1	Normal	No	Super
6	Event A1	Normal	Yes	No
7	Event A1	High	No	No
8	Event A2	Low	No	No
9	Event A2	Normal	No	No
10	Event A2	Normal	No	Short
11	Event A2	Normal	No	Long
12	Event A2	Normal	No	Super
13	Event A2	Normal	Yes	No
14	Event A2	High	No	No
15	Event A3	Zero	No	No
16	Event A4	Normal	No	No
17	Event A5	Normal-Normal	No	No

其他事件例如 Event A3、A4 和 A5 依賴相鄰小區的測量值，因此它們會在 Piecewise test #2 中進行更加完整的測試。仿真會把節點放置在一條直線上，並指示用戶以一種與 Piecewise test #1 相似的方式進行 “jump” 。仿真中禁用切換，因此仿真期間服務小區和相鄰小區的角色不會呼喚。下表 UE measurements test scenarios using piecewise configuration #2 列舉了 Piecewise test #2 中測試的場景。

UE measurements test scenarios using piecewise configuration #2

Test #	Reporting Criteria	Threshold/Offset	Hysteresis	Time-to-Trigger
1	Event A1	Low	No	No
2	Event A1	Normal	No	No
3	Event A1	Normal	Yes	No
4	Event A1	High	No	No
5	Event A2	Low	No	No
6	Event A2	Normal	No	No
7	Event A2	Normal	Yes	No
8	Event A2	High	No	No
9	Event A3	Positive	No	No
10	Event A3	Zero	No	No
11	Event A3	Zero	No	Short
12	Event A3	Zero	No	Super
13	Event A3	Zero	Yes	No
14	Event A3	Negative	No	No
15	Event A4	Low	No	No
16	Event A4	Normal	No	No
17	Event A4	Normal	No	Short
18	Event A4	Normal	No	Super
19	Event A4	Normal	Yes	No
20	Event A4	High	No	No
21	Event A5	Low-Low	No	No
22	Event A5	Low-Normal	No	No
23	Event A5	Low-High	No	No
24	Event A5	Normal-Low	No	No
25	Event A5	Normal-Normal	No	No
26	Event A5	Normal-Normal	No	Short
27	Event A5	Normal-Normal	No	Super
28	Event A5	Normal-Normal	Yes	No
29	Event A5	Normal-High	No	No
30	Event A5	High-Low	No	No
31	Event A5	High-Normal	No	No
32	Event A5	High-High	No	No

注意測試的 time-to-trigger，它們使用 3 種不同的 time-to-trigger 值進行測試， short （短於報告間隔），long（短於過濾測量周期200 ms），和 super （長於 200 ms）。前兩種值確保 time-to-trigger 估計總是使用從物理層接收到的最新測量報告。最后一種負責驗證 time-to-trigger 取消，例如，當來自物理層的測量報告表明，在第一個觸發器觸發前，進入/離開條件不再為真。

（2）Handover configuration（切換配置）

切換配置的目的是驗證在成功發生一次切換后用戶測量配置是否正確更新。基於此目的，仿真構造了使用不同用戶測量配置的 2 個基站，並且用戶將從一個小區切換到另一個小區。用戶位於2個基站之間的一條直線上，切換通過手動調用。每個仿真的持續時間為 2 秒（特別是最后一種 test case），並且切換是在仿真進行到一半時進行精准觸發。

lte-ue-measurements-handover test suite 涉及幾種類型的配置差異。第一種是上報間隔的差異，例如第一個基站配置 480 ms 的上報間隔，第二個基站配置 240 ms 的上報間隔。因此，當用戶執行切換到第二個小區時，新的上報間隔必須生效。如同在 piecewise configuration 中，基站接收到的每種測量報告的 timing 和 content 將被驗證。

test suite 涉及的其他類型的差異主要是事件和閾值/偏移的差別。下表 UE measurements test scenarios using handover configuration 列舉了測試場景。

UE measurements test scenarios using handover configuration

Test #	Test Subject	Initial Configuration	Post-Handover Configuration
1	Report interval	480 ms	240 ms
2	Report interval	120 ms	640 ms
3	Event	Event A1	Event A2
4	Event	Event A2	Event A1
5	Event	Event A3	Event A4
6	Event	Event A4	Event A3
7	Event	Event A2	Event A3
8	Event	Event A3	Event A2
9	Event	Event A4	Event A5
10	Event	Event A5	Event A4
11	Threshold/offset	RSRP range 52 (Event A1)	RSRP range 56 (Event A1)
12	Threshold/offset	RSRP range 52 (Event A2)	RSRP range 56 (Event A2)
13	Threshold/offset	A3 offset -30 (Event A3)	A3 offset +30 (Event A3)
14	Threshold/offset	RSRP range 52 (Event A4)	RSRP range 56 (Event A4)
15	Threshold/offset	RSRP range 52-52 (Event A5)	RSRP range 56-56 (Event A5)
16	Time-to-trigger	1024 ms	100 ms
17	Time-to-trigger	1024 ms	640 ms

2.2.6 Round Robin scheduler performance（RR調度器性能）

test suite lte-rr-ff-mac-scheduler 創建不同的 test case ，單個基站和幾個用戶，全都擁有相同的無線承載規范。在每種 test case 中，用戶從基站獲得相同的 SINR ；不同的 test cases 通過用戶和基站間不同的距離（例如，因此有不同的 SINR 值）和不同的用戶數目來實現。測試包含檢查用戶間獲得的吞吐量性能是否相等，和根據感知的 SINR 匹配參考吞吐量值是否在給定容忍范圍內。

測試向量根據傳輸塊（見 table 7.1.7.2.1-1 of [TS36213]）的值獲得，考慮用戶間物理資源塊的均勻分布，使用 Resource Allocation Type 0 ，定義在 Section 7.1.6.1 of [TS36213]。

令

為 TTI 持續時間，

為用戶數目，

為傳輸帶寬（配置為RBs的數目），

為 RBG 大小，

為在給定 SINR 下使用的調制和編碼方式，

為傳輸塊大小，單位為比特，定義在 3GPP TS 36.213。 S(M, B)

$\tau$

我們首先計算分配給每個用戶的 RBGs 數目

：

$L = \left\lfloor \frac{B}{NG} \right\rfloor$

每個用戶實現的參考吞吐量

（單位為 bit/s）計算公式如下：

$T = \frac{S(M, L G)}{8 \; \tau}$

如果測量的吞吐量匹配參考吞吐量，相對容忍為 0.1，則測試通過。該容忍需要考慮仿真開始時的瞬時動態（例如，CQI 反饋只在幾個子幀后可用），以及在選定仿真時間（0.4s）平均吞吐性能的估計函數的精確度。仿真時間的選擇通過遵循 ns-3 指南調整，保持測試 suite 總的執行時間低，盡管有大量測試情形。在任何情況下，注意，當仿真運行時間越長，可以使用的容忍值會越低。

在圖 fig-lenaThrTestCase1 中，曲線標記為 “RR” 表示用於計算 RR 調度器測試的測試值，在每個測試情形中都是用戶數目和 MCS 索引的函數。

Test vectors for the RR and PF Scheduler in the downlink in a scenario where all UEs use the same MCS

2.2.7 Proportional Fair scheduler performance（PF 調度器性能）

test suite lte-pf-ff-mac-scheduler 使用 PF 調度器創建不同的 test case ，1 個基站和幾個用戶，全都擁有相同的無線承載規范。 test case 分為兩類，目的是從兩方面估計性能，一個是對信道條件的適應性，另一個是從公平性的角度。

在第一類 test case 中，用戶全都放置在距離基站相同的位置，目的是具有相同的 SINR。不同的測試例子通過使用不同的 SINR 值和不同數目的用戶來實現。測試包括檢查得到的吞吐性能是否匹配已知的參考吞吐量和達到給定容忍。當所有用戶具有相同SNR 時，PF 調度器期望當使用所有資源時，每個用戶能得到相同比例的吞吐量。估計參考吞吐量值——通過在給定 SNR，除以用戶總數，划分為單個用戶可實現的吞吐量。

令

為 TTI 持續時間，

為傳輸帶寬（配置為RBs的數目），

為給定 SINR 下的調制和編碼方式，

為傳輸塊大小，每個用戶實現的參考吞吐量

（bit/s）計算為

$T = \frac{S(M,B)}{\tau N}$

圖 fig-lenaThrTestCase1 中標記為“PF”的曲線表示計算的第一類的PF調度器的測試值。

第二類 test case 目的是在一個更加實際的仿真場景（其中用戶具有不同的 SINR，整個仿真中是常數）驗證 PF 調度器的公平性。在這些條件下， PF 調度器將給每個用戶分配一份系統帶寬（與一個用戶可實現的能力成比例，考慮其 SINR ）。具體地，令

為每個用戶使用的調制編碼方式(它是用戶的SINR的確定性函數，因此在場景中已知)。基於MCS，我們可以確定每個用戶

的可實現率

。然后定義每個用戶的可實現率比

：

現在令

為用戶實際實現的吞吐量，作為仿真輸出的一部分。定義用戶得到的吞吐率

為：

$\rho_{T,i} = \frac{T_i}{\sum_{j=1}^N T_j}$

測試包含檢查下來條件是否得到驗證：

$\rho_{R,i} = \rho_{T,i}$

如果得到驗證，根據理論，說明在整個仿真過程中，每個用戶獲得的吞吐量匹配 PF 調度器期望的穩態吞吐量。該測試可以參見 [Holtzman2000] 。從 [Holtzman2000] 的第三節中，我們可以發現

$\frac{T_i}{R_i} = c, \, \forall i$

其中

是常數。通過代入上面的定義

，我們得到

這正是測試中使用的表示。

圖 Throughput ratio evaluation for the PF scheduler in a scenario where the UEs have MCS index 表明測試中得到的結果，其中UEs

位於距離基站不同的位置，它們使用的 MCS 索引分別為 28，24，16，12，6 。從圖中我們可以發現，正如預期的，所得吞吐量與可實現率成比例。換句話說，MCS 索引越大的用戶得到的調度資源越多。

Throughput ratio evaluation for the PF scheduler in a scenario where the UEs have MCS index

2.2.8 Maximum Throughput scheduler performance（MT調度器性能）

test suites lte-fdmt-ff-mac-scheduler 和 lte-tdmt-ff-mac-scheduler 創建不同的 test cases ，一個基站和幾個用戶，全都有相同的無線承載規范，分別使用 Frequency Domain Maximum Throughput (FDMT，頻域最大吞吐量) 調度器和 Time Domain Maximum Throughput (TDMT，時域最大吞吐量) 調度器。換句話說，用戶全都放置在距離基站相同的位置，目的是讓所有用戶都具有相同的 SNR。不同的 test cases 通過使用不同的 SNR 值和不同的用戶數目來實現。測試包括檢查給定容忍值下，所得吞吐量是否匹配已知的參考吞吐量。 FDMT 和 TDMT 調度器預期的行為是，當所有用戶具有相同的 SNR 時，調度器分配所有的 RBGs 給第一個用戶（定義在腳本中）。原因是，當存在多個用戶同時有相同的 SNR 值時，當前的 FDMT 和 TDMT 實現總是選擇服務第一個用戶。我們通過單個用戶在給定 SNR 可實現的吞吐量來計算第一個用戶的參考吞吐量值，而其他用戶的參考吞吐量值為0 。令

為 TTI 間隔，

為傳輸帶寬（配置為 RBs 的數目），

為給定 SNR 下的調制和編碼方式，

為傳輸塊大小（定義在 [TS36213] 中）。每個用戶的參考吞吐量

（ bit/s）計算方式如下：

$T = \frac{S(M,B)}{\tau}$

2.2.9 Throughput to Average scheduler performance（TTA調度器性能）

test suites lte-tta-ff-mac-scheduler 創建不同的 test cases ，一個基站和幾個用戶，使用 TTA 調度器，全都具有相同的無線承載規范。 TTA test case 的網絡拓撲和配置與 MT 調度器的測試一樣，還需要開發更多復雜的 test case 來表明 TTA 調度器的公平性特征。

2.2.10 Blind Average Throughput scheduler performance（有的地方寫的是 Blind Equal Throughput ，簡寫為BET，一個意思）

Test suites lte-tdbet-ff-mac-scheduler 和 lte-fdbet-ff-mac-scheduler 創建不同的 test cases ，使用一個基站和幾個用戶，全都具有相同的無線承載規范。

在 lte-tdbet-ff-mac-scheduler 和 lte-fdbet-ff-mac-scheduler 的第一種 test case 中，用戶全都放置在距離基站相同的位置，其目的是目的是讓所有用戶都具有相同的 SNR。不同的 test cases 通過使用不同的 SNR 值和不同的用戶數目來實現。測試包括檢查給定容忍值下，所得吞吐量是否匹配已知的參考吞吐量。當所有用戶具有相同的 SNR 時， TD-BET 和 FD-BET 預期的行為是每個用戶應獲得相同的吞吐量。然而，在該 test case 中，TD-BET 和 FD-BET 的准確吞吐量值並不相同。

當所有用戶具有相同的 SNR 時，TD-BET 可以看作 PF 的一種特殊情形，其可實現率等於 1。因此，TD-BET 獲得的吞吐量等於 PF 的吞吐量。另一方面，當所有用戶具有相同的 SNR 以及用戶（或 RBG）數目為 RBG（或用戶）數目的整數倍時，FD-BET 與 round robin （RR）調度器的實現過程非常相似。這種情況下，FD-BET 總是給每個用戶分配相同數目的 RBGs。例如，如果基站有 12 個RBGs ，並且有6個用戶，那么每個用戶在每個 TTI 獲得 2 個 RBGs。或者，如果基站有 12 個 RBGs ，並且有 24 個用戶，那么每個用戶每隔2個TTIs 可以獲得 2 個 RBGs 。當用戶（RBG）的數目不是 RBG （UE）數目的整數倍時，FD-BET 將不再遵循 RR 的行為，因為它將給一些用戶分配不同數目的 RBGs ，雖然每個用戶的吞吐量仍然一樣。

第二種類別的測試旨在在一個更加實際的仿真場景中驗證 TD-BET 和 FD-BET 調度器的公平性，其中用戶有不同的 SNR （整個仿真期間為常數）。這種情況下，兩個調度器都應該給每個用戶分配相同數量的平均吞吐量。

特別地，對於 TD-BET，令

為整個仿真時間內分配給用戶 i 的時間片段，

為用戶 i 的整個帶寬可實現率，

為用戶 i 可實現的吞吐量。然后我們可以得到：

$T_i = F_i R^{fb}_i$

TD-BET 中，所有用戶的

和加起來為 1 。從長遠來看，所有用戶具有相同，因此我們可以通過來替換，這樣我們可以得到下列式子：

$T = \frac{1}{ \sum_{i=1}^{N} \frac{1}{R^{fb}_i} }$

2.2.11 Token Band Fair Queue scheduler performance（TBFQ 調度器性能）

test suites lte-fdtbfq-ff-mac-scheduler 和 lte-tdtbfq-ff-mac-scheduler 創建不同的 test cases ，測試 TBFQ 調度器的3個關鍵特質： traffic policing（流量策略）、 fairness（公平性）和 traffic balance（業務均衡）。常數比特率 UDP 業務用於所有 test cases 中的上行和下行鏈路。數據包間隔設置為 1ms 用於保持 RLC 緩存 non-empty 。不同的業務率通過設置不同的數據包大小實現。特別地， test suites 中創建了兩類 flows ：

Homogeneous flow: 具有相同 token generation rate（令牌產生率）和 packet arrival rate（數據包到達率）的 flows
Heterogeneous flow: 具有不同數據包到達率但相同令牌產生率的flows

test case 1 驗證 traffic policing 和 fairness 特征，用於場景——所有用戶放置在距基站相同距離的位置。這種情況下，所有用戶具有相同的 SNR 值。不同的 test cases 通過使用不同的 SNR 值和不同的用戶數目來部署。因為每個 flow 具有相同的業務速率（traffic rate ）和令牌產生率，TBFQ 調度器將在用戶間產生相同的吞吐量，沒有令牌產生率這一約束條件。此外，用戶吞吐量的精確值依賴於 total traffic rate ：

If total traffic rate <= maximum throughput, UE throughput = traffic rate
If total traffic rate > maximum throughput, UE throughput = maximum throughput / N

其中，N 表示連接到基站的用戶數目。這種情況下的最大吞吐量等於把所有 RBs 分配給一個用戶的速率（例如，當距離為0 時，最大吞吐量為 2196000 byte/sec ）。當業務速率小於最大帶寬時， TBFQ 可以通過令牌產生率監督（police ）業務，這樣用戶吞吐量可以等於實際的業務速率（令牌產生率設置為業務產生速率）；在另一方面，當總的業務速率大於最大吞吐量時，基站不能轉發所有業務給用戶。因此，在每個 TTI ，由於大的數據包緩存在 RLC buffer 中，TBFQ 將給一個用戶分配所有 RBGs。在當前 TTI ，當一個用戶被調度時，它的令牌計數器會減少，這樣在下一個 TTI 該用戶就不會被調度。因為每個用戶具有相同的業務產生率，TBFQ 將輪流服務每個用戶，並且每個 TTI 只服務一個用戶（ TD TBFQ 和 FD TBFQ ）。因此，第二種條件下的用戶吞吐量等於最大吞吐量的均勻份額（evenly share）。

test case 2 驗證流量策略和公平性特征，場景為——用戶放置在距基站不同距離的位置。在該場景下，每個用戶具有不同的 SNR 值。與 test case 1 相似的是， test case 2 中的用戶吞吐量也依賴於總的業務速率，但是最大吞吐量不同。假定所有的用戶具有高的業務負載。然后業務將使得基站的 RLC 緩存飽和。在每個 TTI ，在使用最高指標選擇完一個用戶后，由於大的 RLC 緩存區大小，TBFQ 將給該用戶分配所有 RBGs。另一方面，一旦 RLC 緩存飽和，所有用戶總的吞吐量就不能再增加了。此外，正如我們在 test case 1 中討論的，對於 homogeneous flows （具有相同 t_i 和 r_i），從長遠看來，每個用戶將實現相同的吞吐量。因此，我們可以使用和 TD BET 中相同的方法計算最大吞吐量：

$T = \frac{N}{ \sum_{i=1}^{N} \frac{1}{R^{fb}_i} }$

其中，

表示最大吞吐量，

表示用戶 i 的整個帶寬可實現率。

表示用戶數目。

當所有業務速率大於

時，用戶吞吐量等於

。否則，用戶吞吐量等於其業務產生速率。

test case 3 中會創建具有不同的業務速率的 3 種 flows。每個 flow的令牌產生率相同且等於 3 種 flows 的平均業務速率。因為 TBFQ 使用一個共享的 token bank ，有着更低業務負載的用戶貢獻的令牌可以由具有更高業務負載的用戶使用。用這種方法，TBFQ 可以保證每個流的業務速率。雖然我們這里使用 heterogeneous flow ，最大吞吐量的計算與 test case 2 中的一樣。在計算 test case 2 的最大吞吐量時，我們假定所有用戶都可以承受高的業務負載，這樣調度器總是在每個 TTI 給一個用戶所分配有的 RBGs 。該假設在 heterogeneous flow 的情況下也是對的。換句話說，是否這些流具有相同的業務速率和令牌產生率，是否它們的業務速率足夠大，TBFQ 與 test case 2 中的 TBFQ 執行情況一樣。因此， test case 3 的最大帶寬與 test case 2 中的最大帶寬相同。

在 test case 3 的一些 flows 中，盡管所有的 flows 為固定比特率（CBR，Constant Bit Rate ）業務，令牌產生率不等於最大比特率（ MBR，Maximum Bit Rate）。這不符合我們的參數設置規則。實際上業務均衡特征使用在可變比特率（VBR，Variable Bit Rate ）業務中。因為不同用戶的峰值速率可能發生在不同時間，TBFQ 使用共享的 token bank 來平衡這些 VBR 業務。 Test case 3 使用 CBR 業務來驗證這一特點。但是在實際仿真中，推薦設置令牌產生率為 MBR 。

2.2.12 Priority Set scheduler performance（PSS性能）

test suites lte-pss-ff-mac-scheduler 使用單個基站和幾個用戶創建不同的 test cases 。在所有的 test cases 中，我們選擇 FD 調度器中的 PFsch。相同的測試結果也可以通過使用 CoItA 調度器實現。此外，所有的 test cases 並么有定義 nMux ，因此，PSS 中的 TD 調度器將總是選擇總用戶數的一半。

在 lte-pss-ff-mac-scheduler 的第一類test case 中，用戶全都放置在距基站相同距離的位置上，這種情況下，所有用戶具有相同的 SNR 值。不同的 test cases 通過使用不同的 TBR （用於每個用戶）來實現。在每種 test case 中，所有用戶全都具有相同的目標比特率（TBR，Target Bit Rate），TBR 由 EPS 承載設置中的 GBR （保證比特率）配置。如果總的流速（flow rate）低於最大吞吐量，PSS 預期的行為是保證每個用戶的吞吐量至少等於其 TBR 。與 TBFQ 相似，這種情況下的最大吞吐量等於所有 RBGs 分配給一個用戶的速率。當業務速率小於最大帶寬時，用戶吞吐量等於其實際的業務速率；另一方面，用戶吞吐量等於最大吞吐量的 evenly share。

在第一類 test case 中，每個用戶具有相同的 SNR 。因此， PF 調度器由歷史平均吞吐量

確定，因為在 PFsch（CoItA）中每個用戶具有相同的可實現吞吐量

（

）。這意味着，PSS 將與 TD-BET 一樣，在每個 TTI 給一個用戶分配所有的 RBGs 。然后，用戶吞吐量的最大值等於所有 RBGs 分配給該用戶的可實現率。

在 lte-pss-ff-mac-scheduler 的第二類 test case 中，用戶全都放置在距基站相同距離的位置上，這種情況下，所有用戶具有相同的 SNR 值。每個用戶被分配不同的 TBR 值。這種情況下也存在一個最大吞吐量。一旦總的業務速率大於該閾值，一些用戶將不能實現它們的 TBR 。因為沒有衰落，每個 RBGs 頻率的 subband CQIs 是一樣的。因此，在 FD 調度器值，每隔 TTI ，所有 RBGs 的用戶優先級指標全都是相同的。這意味着 FD 調度器總是給一個用戶分配所有 RBGs。因此，在最大吞吐量的情況下， PSS 與 TD-BET 很類似，然后我們有：

其中，

表示最大吞吐量。

表示用戶 i 的整個帶寬可實現率。

表示用戶數目。

2.2.13 Channel and QoS aware scheduler performance（CQA調度器性能）

當 GBR flows 對時延不敏感，通過測量，如果在 RLC 層的可實現吞吐量接近 TBR 時，那么測試 CQA 調度器性能的方式與測試 PSS 性能的方式相似。有了這一點， CQA 調度的性能測試使用與 lte-pss-ff-mac-scheduler 相同的 test case 。此外，在, [Bbojovic2014] 中，當 GBR flows 對時延敏感、考慮不同的 QoE （體驗質量）指標時，可以找到 CQA 調度器的性能估計。

2.2.14 Building Propagation Loss Model（建立傳播損耗模型）

系統測試的目標是驗證 LTE 模塊中 BuildingPathlossModel 的集成。該測試利用 3 個預計算的損耗的集合來生成預期的 SINR （在接收端統計傳輸功率和噪聲功率）。然后將這些 SINR 值與 LTE 仿真（使用 BuildingPathlossModel ）所得結果進行比較。參考損耗值通過使用 Octave 腳本（/test/reference/lte_pathloss.m）離線計算。如果參考損耗值等於仿真器計算的值，且容忍為 0.001 dB（考慮計算中的數值誤差），則每種 test case 通過。

2.2.15 Physical Error Model（物理誤差模型）

test suite lte-phy-error-model 生成不同的 test cases ，用於估計數據和控制誤差模型。對於所關心的數據，測試包含 6 種 test cases ，單個基站和不同數目的用戶，全都有相同的無線承載規范。每種測試是專門為估計特定 TB 大小感知到的誤差率而設計的，目的是根據生成用於 CB （Coding Block，碼塊）大小（模擬 TB 大小）的 BLER ，驗證誤差率對應預期的值。這意味着，例如，通過收集用戶（用戶根據與基站之間的距離，被迫生成這樣一個 TB 大小）的性能，測試將檢查一個TB（大小為

bits）的性能類似於一個CB （大小為

bits ）。為了在 MAC 級別有效地測試 BLER ，我們配置自適應調制和編碼（AMC ，Adaptive Modulation and Coding ）模塊，即 LteAmc 類，通過使用 PiroEW2010 AMC 模型使得它相對信道條件來說不那么健壯，並且考慮目標 BER 0.03（不是默認值 0.00005）來配置選擇 MCS。我們注意到，這些值不會反映實際的 BER，因為它們來自 analytical bound（並不會考慮所有的 transmission chain 方面）；因此，BER 和 BLER 實際上在有經驗地接收 TB 方面一般來說是不同的。

6 種 test cases的參數報告如下：

4 UEs 放置在距離基站 1800 米的距離，意味着使用 MCS 2 (SINR of -5.51 dB) 且TB 大小為 256 bits，輪流產生值為 0.33 的 BLER （見圖 BLER for tests 1, 2, 3. 中的點 A）。
2 UEs 放置在距離基站 1800 米的距離，意味着使用 MCS 2 (SINR of -5.51 dB) 且TB 大小為 528 bits，輪流產生值為 0.11 的 BLER （見圖 BLER for tests 1, 2, 3 中的點 B）。
1 UE 放置在距離基站 1800 米的距離，意味着使用 MCS 2 (SINR of -5.51 dB) 且TB 大小為 1088 bits，輪流產生值為 0.02 的 BLER （見圖 BLER for tests 1, 2, 3 中的點 C）。
1 UE 放置在距離基站 600 米的距離，意味着使用 MCS 12 (SINR of 4.43 dB) 且TB 大小為 4800 bits，輪流產生值為 0.3 的 BLER （見圖 BLER for tests 4, 5. 中的點 D）。
3 UEs 放置在距離基站 600 米的距離，意味着使用 MCS 12 (SINR of 4.43 dB) 且TB 大小為 1632 bits，輪流產生值為 0.55 的 BLER （見圖 BLER for tests 4, 5. 中的點 E）。
1 UE 放置在距離基站 470 米的距離，意味着使用 MCS 16 (SINR of 8.48 dB) 且TB 大小為 7272 bits（分段為 2 個碼塊，分別為 3648 和 3584 bits），輪流產生值為 0.14 的 BLER ，因為每個 CB 的 CBLER 等於0.075 （見圖 BLER for tests 6 中的點 F）。

BLER for tests 1, 2, 3

BLER for tests 4, 5

BLER for test 6

測試條件驗證，在每一個 test case 中，預期正確接收的數據包數符合伯努利分布（置信區間為 99%），其中每個 trail 的成功概率為

，且

為發送數據包的總數目。

PCFICH-PDCCH 信道的誤差模型包含 4 種 test cases ，場景為1個用戶和幾個基站，其中用戶只連接到一個基站，剩余的基站作為干擾對象。數據的誤差是禁用的，目的是驗證由於錯誤解碼 PCFICH-PDCCH 引起的誤差。如前所示，系統被迫以一種不那么保守的方式在 AMC 模塊中工作，用於正確評價邊界條件的結果。 4 種 tests cases 的參數報告如下：

2 eNBs 放置在距離用戶 1078 米的距離，意味着使用 SINR 為 -2.00 dB ，且 TB 大小為 217 bits，輪流產生值為 0.007 的 BLER 。
3 eNBs 放置在距離用戶 1040 米的距離，意味着使用 SINR 為 -4.00 dB ，且 TB 大小為 217 bits，輪流產生值為 0.045 的 BLER 。
4 eNBs 放置在距離用戶 1250 米的距離，意味着使用 SINR 為 -6.00 dB ，且 TB 大小為 133 bits，輪流產生值為 0.206 的 BLER 。
5 eNBs 放置在距離用戶 1260 米的距離，意味着使用 SINR 為 -7.00 dB ，且 TB 大小為 81 bits，輪流產生值為 0.343 的 BLER 。

測試條件驗證了在每種 test case 中，預期正確接收的數據包數目符號伯努利分布（置信區間為 99.8%），其中每個 trail 的成功概率為

，且

為發送數據包的總數目。更大的置信區間是由於量化 MI 和誤差曲線可能產生的誤差。

2.2.16 HARQ Model

test suite lte-harq 包含兩種測試，用於估計 HARQ 模型和誤差模型的相關擴展。測試包含檢查仿真期間接收到的字節數是否符合根據傳輸塊值和 HARQ 動態值所得的預期值。具體地，測試檢查 HARQ 重傳后的所得吞吐量是否為預期值。為了估計預期的吞吐量，先根據下列式子估計預期的 TB 傳遞時間：

其中，

為在第

（例如3GPP命名的 RV）次嘗試成功接收HARQ塊的概率。根據場景，在測試中我們總是使

等於 0.0，而

的值會在兩種測試中變化，具體地：

$\mathrm{T_{test-1}} = 0.0 \times 1 + 0.926 \times 2 + 0.074 \times 3 = 2.074 \mathrm{T_{test-2}} = 0.0 \times 1 + 0.752 \times 2 + 0.248 \times 3 = 2.248$

預期的吞吐量通過計算仿真中可用的傳輸時隙的的數目（例如 TTIs 的數目）和仿真中 TB 的大小，具體地：

其中，

為 1 秒內 TTIs 的數目。測試可以進行在 RR 調度器和 PF 調度器中。如果測量的吞吐量匹配參考吞吐量且相對容忍為 0.1，則測試通過。該容忍需要考慮仿真開始時的瞬時行為和仿真結束時的 on-fly blocks 。

2.2.17 MIMO Model

test suite lte-mimo 旨在驗證系統性能的傳輸方式（Transmission Mode）和通過調度器接口切換的傳輸方式這兩者的增益影響。測試包含檢查在某一個窗口時間（本例中為 0.1 秒）內接收的字節數是否符合根據 [TS36213] 的表格 7.1.7.2.1-1 記錄的傳輸塊大小所得的預期值，類似於調度器的測試執行過程。

測試可以進行在 RR 調度器和 PF 調度器中。如果測量的吞吐量匹配參考吞吐量且相對容忍為 0.1，則測試通過。該容忍需要考慮仿真開始時的瞬時行為和傳輸模式間的過渡階段。

2.2.18 Antenna Model integration（天線模型集成）

test suite lte-antenna 檢查天線模型是否正確集成在LTE 模型中。該 test suite 重建一個仿真場景，一個基站節點位於坐 (0,0,0) ，一個用戶節點位於坐標 (x,y,0) 。基站節點配置為給定方向和波束寬度的 CosineAntennaModel 。相反，用戶使用默認的 IsotropicAntennaModel 。測試檢查接收的上行和下行功率，考慮天線增益的正確值（線下確定）；測試通過比較上行和下行的 SINR 、並檢查兩者是否符合參考值且容忍為

（考慮數值誤差）來實現。通過改變用戶的坐標 x 和 y，以及基站的天線方向和波束寬度，可以提供不同的 test cases。

2.2.19 RLC

兩種 test suites lte-rlc-um-transmitter 和 lte-rlc-am-transmitter 檢查 UM RLC 和 AM RLC 實現是否正確進行。這兩種 suites 通過測試 RLC 實例連接到特定的測試實體（在 MAC 和 PDCP 扮演重要角色）上，分別實現 LteMacSapProvider 和　LteRlcSapUser 接口。提供不同的 test cases（例如，輸入測試向量由一系列來自 MAC 和 PDCP 的原始調用組成）用於檢查下列 cases 中的行為：

one SDU, one PDU： MAC 通知一個傳輸機會（TX opportunity ）導致創建 PDU （正好包含一個完整的SDU）；
segmentation（分段）： MAC 通知多個傳輸機會（TX opportunity ），傳輸機會小於存儲在傳輸緩存中的 SDU 大小，然后分段SDU，因此會生成多個 PDUs ；
concatenation（串聯）： MAC 通知一個傳輸機會（TX opportunity ），傳輸機會大於 SDU，因此多個 SDUs 串聯到同一個 PDU中；
buffer status report（緩存狀態報告）：一系列來自 PDCP 層的新的 SDUs 通知與一系列傳輸機會通知交織在一起，目的是驗證緩存狀態報告過程是否正確。

在所有這些 cases 中，輸出測試向量由輸入測試向量知識和預期行為知識手動確定。這些測試向量專門用於 UM RLC 和 AM RLC（由於它們的不同 behavior）。如果被測試的RLC 實例觸發的原語順序恰好等於輸出測試向量，則每種 test case 會通過。特別地，對於RLC實例發送的每個PDU，需要驗證PDU 的大小和內容以檢查它們與測試向量是否完全匹配。

AM RLC 實現的特點是有一個額外的 test suite， lte-rlc-am-e2e，在存在信道損耗的條件下測試 RLC PDUs 的正確重傳。測試實例化一個 RLC AM 發射機和接收機，並根據固定的損耗概率干預隨機丟包的信道。使用不同的 RngRun 值和不同的損耗概率值對不同的 test cases 進行實例化。如果在仿真結束時所有的 SDUs 正確傳輸給接收 RLC AM 實體的上層，則每個 test case 通過。

2.2.20 RRC

test suite lte-rrc 測試下列方面的正確功能：

MAC 隨機接入
RRC 系統信息獲取
RRC 連接建立
RRC 重配置

test suite 考慮一種類型的場景——4個基站排列在一個正方形布局的100米邊界上。多個用戶位於正方形對角線上的一個特定的點上，用戶被要求連接到第一個基站上。每種 test case 實現該場景的一個實例，使用下列參數的特定值：

用戶數目
每個用戶上激活的數據無線承載的數目
第一個用戶被要求開始連接到基站上的時間
開始連接用戶和用戶的時間間隔；用戶連接的時間因此由 sdf 確定
用戶在正方形對角線上的相對位置，其中值越大表示距離服務基站越遠
布爾標識符表示是否使用理想的或實際的 RRC 協議模型

從用戶開始連接到基站到經過時延 d^e

后，如果每個用戶的測試條件被肯定地估計，那么測試通過。時延 d^e

由下式確定：

$d^e = d^{si} + d^{ra} + d^{ce} + d^{cr}$

其中：

$d^{si}$ 表示用於獲取系統信息所必需的最大時延。設置它為 90ms ，10ms 用於獲取 MIB ，80ms 用於獲取隨后的 SIB2 。

表示 MAC 隨機接入過程的時延。這依賴前導碼碰撞以及上行授權（UL grant）分配資源的可用性。由於缺乏足夠的資源，必要的 RA 嘗試的總數依賴於前導碼碰撞和分配上行確認的失敗。碰撞次數依賴試圖同時接入用戶的數目；我們用 0.99 的 RA 成功概率來估計它，5次嘗試足夠多達 20 個用戶，10 次嘗試足夠多達50個用戶。對於 UL grant，考慮到系統帶寬和默認的用於上行授權的 MCS （MCS 0），在一個TTI 至多只能分配 4 次上行授權；因此對於同時嘗試執行隨機接入的個用戶來說，最大嘗試數為 $\lceil n/4 \rceil$ （由於上行授權問題）。隨機接入嘗試的時間由 LteEnbMac::RaResponseWindowSize 的值決定，為 3ms + ，默認的值為 3ms，加上 1ms 用於新的傳輸調度。

$d^{ce}$ 表示傳輸 RRC CONNECTION SETUP + RRC CONNECTION SETUP COMPLETED 的時延。我們考慮往返時延 10ms ，考慮必須傳輸的 2 個 RRC 數據包和每個 TTI 至多可以傳輸 4 個這樣的數據包，加上 $\lceil 2n/4 \rceil$ 。在干擾很高的情況下，我們建議用戶進行重試嘗試，因此我們加倍值，然后在它的上面再加上（因為超時（timeout）已經清零以前接收到的 SIB2）。

$d^{cr}$ 表示最終需要 RRC CONNECTION RECONFIGURATION 交易的時延。每個承載集合需要交易的數量為 1 。與相似，對於每次交易，考慮往返時延 10ms 加上。時延為 20ms。

LteRrcConnectionEstablishmentTestCase 的基本版本用於測試缺乏信道誤差情況下正確的 RRC 連接建立。對於每個用戶，通過該 test case 要估計的條件為：

用戶的 RRC 狀態為 CONNECTED_NORMALLY
用於配置有基站的 CellId、DlBandwidth、 UlBandwidth、DlEarfcn 和 UlEarfcn
存儲在基站的用戶的 IMSI 是正確的
激活的數據無線承載的數目為預期值，包括基站和用戶
對於每個數據無線承載，下列標識符在用戶和基站之間相匹配：EPS bearer id、DRB id 和LCID

test variant LteRrcConnectionEstablishmentErrorTestCase 是相似的，除了在第一次連接嘗試期間選擇傳輸特定的 RRC 消息中存在誤差外。誤差通過臨時移動用戶到一個遙遠的位置獲得；移動的時間基於預期存在誤差的消息，通過 test case 的每個實例經驗性獲得。在用戶移回到原始位置之前，test case 檢查下列條件至少有一個為假：

用戶的 RRC 狀態為 CONNECTED_NORMALLY
基站有用戶的上下文（context ）
基站上用戶 Context 的 RRC 狀態為 CONNECTED_NORMALLY

此外，估計 LteRrcConnectionEstablishmentTestCase 的所有條件—— 它們預計為真，因為如果連接建立失敗，NAS 會立即重新嘗試連接。

2.2.21 Initial cell selection（初始小區選擇）

test suite lte-cell-selection 負責驗證 Initial Cell Selection 過程。該測試是一個小的網絡仿真，使用 2 個 CSG（閉合用戶組）小區和 2 個 non-CSG （非閉合用戶組）小區。幾個靜態用戶然后放置在預定義的位置。用戶不用連接到任何小區就可以進入任何仿真。初始小區選擇為這些用戶開啟，因此每個用戶將找到最合適的小區並自己連接到小區。

在仿真期間預定義的檢查點時間（check point time），測試驗證每個用戶是否連接到合適的小區。並且，測試也會保證用戶進行了正確地連接，例如，它的最終狀態為 CONNECTED_NORMALLY。下圖 Sample result of cell selection test 描述了網絡部署和預期的結果。當用戶描述為具有 2 個成功的小區選擇時（例如 UE #3 和 #4），則 test case 可以接收其中任何一個。

Sample result of cell selection test

上圖表明 CSG 成員可以連接到 CSG 或 non-CSG 小區，並且只選擇最強小區。另一方面，非成員只能連接到 non-CSG 小區，即使當它們實際上接收了來自 CSG 小區的更強信號。

用於參考目的，下表 UE error rate in Initial Cell Selection test 表示當用戶接收來自控制信道的傳輸時每個用戶的誤差率。基於此信息，UE #3 check point time 完成的時間比其他用戶晚，用於補償其失敗的高風險。

UE error rate in Initial Cell Selection test

UE #	Error rate
1	0.00%
2	1.44%
3	12.39%
4	0.33%
5	0.00%
6	0.00%

該測試使用默認的 Friis 路徑損耗模型，沒有任何信道衰落模型。

2.2.22 GTP-U protocol

unit test suite epc-gtpu 檢查 GTP-U 頭部的編碼和解碼是否正確執行。測試使用一系列已知的值填充頭部，在數據包中添加頭部，然后從數據包中移除頭部。一旦移除，GTP-U 頭部的任何字段不能正確解碼，則測試失敗。這是通過監測解碼的值和已知的值而得到的。

2.2.23 S1-U interface

兩種 test suites （epc-s1u-uplink 和 epc-s1u-downlink）確保 S1-U 接口實現單獨正確進行。這是通過創建一系列仿真場景實現的，其中只使用 EPC 模型，沒有 LTE 模型（例如，沒有 LTE 協議棧，LTE 協議棧由簡單的 CSMA 設備替換）。這會在各種場景中檢查多個基站中的多個 EpcEnbApplication 實例和 SGW/PGW 節點中的 EpcSgwPgwApplication 實例的交互性是否正確執行，場景包括變化的終端用戶（安裝有 CSMA 設備的節點）數目、基站數目和不同的業務模型（數據包大小和總的數據包數目）。每種 test case通過在網絡（分別在上行或下行 test suite 的考慮的用戶或遠程主機）中注射選擇的業務模型並檢查接收端（分別為遠程主機或每個考慮的用戶）是否接收到完全相同的業務模型。如果用戶監測到發射端和接收端的業務模型有任何不匹配，則測試失敗。

2.2.24 TFT classifier

test suite epc-tft-classifier 單獨檢查 EpcTftClassifier 類是否執行正確。這是通過創建不同的 classifier 實例實現的，其中不同的 TFT 實例是激活的，且測試每種 classifier（對一組異構的數據包進行正確分類，包括 IP 和 TCP/UDP 頭部）。提供了幾種 test cases ，目的是檢查用於上行和下行業務的 TFT（例如本地/遠程 IP 地址，本地/遠程端口）的不同匹配方面。每種 test case 對應一個特定的 classifier 實例，給定一組 TFTs 。如果由classfier 返回的承載標識符精確匹配考慮的數據包的預期值，則 test case 通過。

2.2.25 End-to-end LTE-EPC data plane functionality（端到端 LTE-EPC 數據面功能）

test suite lte-epc-e2e-data 確保 LTE-EPC 數據面正確的端對端功能。對於該 suite 中的每種 test case ，使用下列特征創建一個完整的 LTE-EPC 仿真場景：

給定的基站數目
對於每個給定的基站，給定用戶的數目
對於每個用戶，給定激活的 EPS 承載的數目
對於每個激活的 EPS 承載，給定業務模型（將要傳輸的 UDP 數據包和數據包大小）

在隨后的時間間隔，每種測試通過在上行和下行傳輸給定的業務模型實現。如果所有下列條件都滿足，則測試通過：

對於每個激活的 EPS 承載，傳輸的和接收的業務模型（分別在上行的用戶和遠程主機，下行則相反）正好相同
對於每個激活的 EPS 承載和每個方向（上行或下行），相應的無線承載實例上恰好是預期的數據包流數目

2.2.26 X2 handover

test suite lte-x2-handover 檢查 X2 切換過程的正確功能。測試的場景的拓撲結構為兩個基站以一個 X2 接口相連接。每種 test case 是該場景的一個特定實例，由下列參數定義：

初始連接到第一個基站的用戶數目
每個用戶激活的 EPS 承載的數目
一系列將要觸發的切換事件，其中每個事件定義為：+ 切換觸發的開始時間 + 執行切換的用戶的索引 + 源基站的索引 + 目標基站的索引
布爾型標識符，指示目標基站是否允許切換
布爾型標識符，指示是否使用理想的 RRC 協議而不是實際的 RRC 協議
使用的調度器的類型（RR 或 PF）

如果下列條件為真，則3 種 test case 通過：

在時間 0.06s ，測試 CheckConnected 驗證每個用戶是否連接到第一個基站。
對於切換列表中的每個事件：
- 在指定的事件開始時間，指定用戶連接到指定源基站
- 在開始時間后的 0.1s ，指定用戶連接到指定目標基站
- 在開始時間后的 0.6s ，對於每個激活的 EPS 承載，指定用戶的上行和下行 sink 應用已經獲得了許多字節，至少是相應的源應用傳輸的字節數的一半。

只有當下列條件滿足時，才能肯定地估計條件 “UE is connected to eNB”：

基站有用戶（通過用戶RRC恢復得到的RNTI值標識）的上下文（context ）
用戶在基站的 RRC 狀態為 CONNECTED_NORMALLY
用戶的 RRC 狀態為 CONNECTED_NORMALLY
用戶配置有基站的CellId、 DlBandwidth、 UlBandwidth、DlEarfcn 和 UlEarfcn
存儲在基站中的用戶的 IMSI 是正確的
激活的數據無線承載的數目是預期值，同時適用於基站和用戶
對於每個數據無線承載，下列標識符在用戶和基站之間是匹配的： EPS bearer id、 DRB id、LCID

2.2.27 Automatic X2 handover（自動 X2 切換）

test suite lte-x2-handover-measures 檢查切換算法的正確功能。測試的場景的拓撲結構為——以 X2 接口連接的兩個或三個或四個基站。基站位於 X 軸上，以直線排列。用戶沿着 X 軸從相鄰的一個基站移動到下一個基站。每種 test case 是一個特定的實例，由下列參數定義：

X軸上的基站數目
用戶的基站數目
用戶激活的EPS承載數目
一系列將要觸發的 check point 事件，其中每個事件定義如下： + 第一個check point 事件的時間+ 最后一個 check point 事件的時間 + 兩次 check point 事件之間的時間間隔 + 執行切換的用戶的索引 + 用戶必須連接的基站的索引
布爾型標識符，指示是否使用 UDP 業務而不是TCP 業務
使用的調度器類型
使用的切換算法的類型
布爾型標識符，指示是否默認允許切換
布爾型標識符，指示是否使用理想的 RRC 協議而不是實際的 RRC 協議

test suite 由很多 test cases 組成。實際上，它一直是ns-3中最耗時的 test suite 之一。 test cases 結合下列可變的參數一起運行：

基站的數目： 2, 3, 4；
EPS 承載的數目： 0, 1, 2；
RRC：理想的，實際的（見 RRC protocol models）；
MAC 調度器：RR ，PF （見 The FemtoForum MAC Scheduler Interface）；且
切換算法： A2-A4-RSRQ，最強小區（見 Handover algorithm）。

如果下列條件為真，則 test case 通過：

在時間 0.08s，測試 CheckConnected 驗證每個用戶是否連接到第一個基站
對於 check point 列表中的每一個事件：
- 在制定的 check point 時間，指定的用戶連接到指定的基站
- 在 check point 后的 0.5s ，對於每個激活的 EPS 承載，用戶的上行和下行 sink 應用已經獲得了許多字節，至少是相應的源應用傳輸的字節數的一半。

只有當下列條件滿足時，才能肯定地估計條件 “UE is connected to eNB”：

基站有用戶（通過用戶RRC恢復得到的RNTI值標識）的上下文（context ）
用戶在基站的 RRC 狀態為 CONNECTED_NORMALLY
用戶的 RRC 狀態為 CONNECTED_NORMALLY
用戶配置有基站的CellId、 DlBandwidth、 UlBandwidth、DlEarfcn 和 UlEarfcn
存儲在基站中的用戶的 IMSI 是正確的
激活的數據無線承載的數目是預期值，同時適用於基站和用戶
對於每個數據無線承載，下列標識符在用戶和基站之間是匹配的： EPS bearer id、 DRB id、LCID

2.2.28 Handover delays（切換時延）

切換過程包含用戶、源基站和目標基站之間在 RRC 協議和 X2 接口上幾個消息的交換。test suite lte-handover-delay 驗證該過程是否始終如一地花相同的時間。

test suite 將運行幾個切換 test cases 。每種 test case 是一個單獨的仿真，特點為切換是在仿真特定的時間進行。例如，第一個 test case 的切換觸發時間為 +0.100s，而第二個test case 的切換觸發時間為 +0.101s。總共有 10 個test cases，每個測試LTE中不同的子幀。因此最后一個test case切換的時間為 +0.109s 。

test cases 中的仿真場景如下：

啟用 EPC
2 個基站使用圓形的（各項同性的）天線，相隔 1000 米
1 個靜態的用戶恰好位於兩個基站的中間
無應用安裝
無信道衰落
默認的路徑損耗模型（Friis）
0.300s 仿真持續時間

test case 運行如下。在仿真的開始，用戶連接到第一個基站。然后在test case 指定的時間輸入參數，切換請求將明確發送給第二個基站。接着 test case 將記錄開始時間，等待直到切換完成，然后記錄完成時間。如果完成時間和開始時間之間的差小於預定義的閾值，那么測試通過。

在當前ns-3實現中，當使用理想的 RRC 協議模型時典型的切換時間為 4.2141 ms，當使用實際的 RRC 協議模型時，典型的切換時間為 19.9283 ms 。因此，test cases 使用 5 ms 和 20 ms 作為最大閾值。test suite 使用理想的 RRC 協議運行10 個 test cases ，使用實際的RRC協議運行 10 個 test cases 。關於這些模型更詳細的信息參見節 RRC protocol models。

使用子幀作為主要測試參數的動機是，子幀索引是計算法 RA-RNTI（切換過程中由隨機接入使用）的因素之一。 test cases 驗證該計算，利用事實——當該計算被破壞時，切換將被推遲。在默認的仿真配置中，因為一個破壞的RA-RNTI 計算通常為6 ms ，因此可以觀察到切換時延。

2.2.29 Selection of target cell in handover algorithm（切換算法中的目標小區選擇）

基站可以利用 Handover algorithm 在仿真期間自動創建切換策略。策略包括應該執行切換的用戶和用戶執行切換的地點目標小區。

test suite lte-handover-target 驗證切換算法是否做出正確的決策，特別地，在選擇正確的目標小區上。它由幾個短的 test cases 組成，用於不同的網絡拓撲（2×2 網格和 3×2 網格）以及切換算法的類型（A2-A4-RSRQ 切換算法和最強小區切換算法）。

微蜂窩仿真環境中的每種 test case 使用下列參數：

啟用 EPC
幾個圓形的（各項同性的天線）微小區基站，使用矩形網格布局，每個相鄰的點之間的距離為130 m
1 個靜態用戶，位於源小區附近且連接到源小區
沒有控制信道誤差模型control channel error model
無應用安裝
無信道衰落
默認的路徑損耗模型（Friis）
1s 仿真持續時間

為了觸發切換， test case 在 +0.5s 仿真時間會“暫時關閉”源小區。下圖 lte-handover-target test scenario in a 2×2 grid 說明了該過程。這是通過設置源小區的發射功率到一個非常低的值來實現的。因此，切換算法注意到用戶需要切換且幾個相鄰小區同時成為目標小區的候選者。

lte-handover-target test scenario in a 2×2 grid

當用戶面臨不止一個目標小區可選時，test case 會先驗證切換算法然后選擇一個合適的目標小區。

2.2.30 Downlink Power Control（下行功率控制）

test suite lte-downlink-power-control 使用3種不同的方式檢查下行功率控制的正確性：

LteDownlinkPowerControlSpectrumValue test case 檢查 LteSpectrumValueHelper::CreateTxPowerSpectralDensity 是否正確創建了用於下行傳輸的功率譜密度（PSD）值。測試向量包含 EARFCN、系統帶寬、發射功率、每個RB的發射功率、激活的RBs以及預期的發射功率譜密度（ TxPSD）。如果 LteSpectrumValueHelper::CreateTxPowerSpectralDensity 產生的 TxPSD 等於預期的 TxPSD，則測試通過。

LteDownlinkPowerControlTestCase test case 會檢查數據信道和控制信道之間發射功率的差是否等於配置的 PdschConfigDedicated::P_A 值。在用戶 DownlinkSpectrumPhy 中，發射功率的控制信道通過添加到 RsPowerChunkProcessor 列表中的 LteTestSinrChunkProcessor 測量。數據信道的發射功率以一種相似的方式測量，但是必須實現。現在，在用戶 DownlinkSpectrumPhy 中， LteTestSinrChunkProcessor 被添加到 DataPowerChunkProcessor 列表中。測試向量包含一系列所有可用的 P_A 值。如果功率差等於 P_A 值，則測試通過。

LteDownlinkPowerControlRrcConnectionReconfiguration test case 檢查 RrcConnectionReconfiguration 是否正確執行。當 FR 實體得到用戶測量，它會立即調用函數改變該用戶的 P_A 值，並且也觸發連接到該事件的回調函數（callback）。然后，測試檢查是否用戶獲取到 RrcConnectionReconfiguration 消息（該消息觸發回調函數）。最后，它會檢查基站是否接收到 RrcConnectionReconfigurationCompleted 消息，該消息也會觸發回調函數。如果所有事件都發生了，則測試通過。測試執行兩次，一次使用 IdealRrcProtocol ，一次使用 RealRrcProtocol 。

2.2.31 Uplink Power Control Tests（上行功率控制測試）

用戶使用上行功率控制自動改變上行物理信道的發射功率（Tx Power ）等級。發射功率的計算基於路徑損耗、用於傳輸的 RB 數目，一些可配置的參數以及來自基站的 TPC 命令。

test suite lte-uplink-power-control 驗證發射率是否正確被計算。如果計算正確，存在 3 種不同的 test cases：

LteUplinkOpenLoopPowerControlTestCase test case 檢查開環機制條件下的上行功率控制功能。用戶連接到基站並在下行和上行發射數據。啟用使用開環機制的上行功率控制，且用戶每隔 100 ms 改變一次位置。 trace 這些值，如果在每個用戶位置的 PUSCH、PUCCH 和 SRS 的上行發射功率值等於預期的值，則測試通過。

LteUplinkClosedLoopPowerControlAbsoluteModeTestCase test case 檢查閉環機制（Closed Loop mechanism ）和絕對模式（Absolute Mode）條件下的上行功率控制功能。用戶連接到基站且在上行和下行發送數據。啟用閉環機制和絕對模式條件下的上行功率控制。用戶位於距離基站 100 m 的位置，且不會改變其位置。 LteFfrSimple 算法用於基站側設置 DL-DCI 消息中的 TPC 值。基站中的 TPC 配置每隔 100 ms 改變一次。因此，每隔100 ms ，用戶中的上行功率實體應計算所有上行信道的不同發射發射功率等級。trace 這些值，如果使用所有 TCP 值計算的 PUSCH、PUCCH 和 SRS 的上行發射功率的值等於預期的值，則測試通過。

LteUplinkClosedLoopPowerControlAccumulatedModeTestCase test case 檢查閉環機制和累積模式（Accumulative Mode）條件下的閉環上行功率控制功能。用戶連接到基站，且在上行和下行傳輸數據。啟用閉環機制和累積模式條件下的上行功率控制。用戶位於距基站 100 m 的位置，且不會改變其位置。如同在上述 test case 中， LteFfrSimple 算法用於基站側設置 DL-DCI 消息中的 TPC 值，但是在該 case 中，設置在 DL-DCI 中的 TPC 命令只配置了次數，且此后TPC設置為 1，累積模式下映射為 0（TS36.213 Table 5.1.1.1-2）。基站中的 TPC 配置每隔 100 ms 改變一次，用戶累積這些值且基於累積的值計算所有上行信道的發射功率等級。如果計算的發射功率等級低於最小用戶發射功率，用戶應使用最小的發射功率傳輸。如果計算的發射功率高於最大的用戶發射功率，則用戶應使用最大的發射功率傳輸。 trace PUSCH、PUCCH 和 SRS 的發射功率等級，如果它們等於預期的值，則測試通過。

2.2.32 Frequency Reuse Algorithms（頻率復用算法）

test suite lte-frequency-reuse 包含兩種 test cases 。

第一種 test cases 根據頻率復用算法策略檢查是否正確使用 RBGs 。我們測試調度器是否只使用 FR 配置允許的 RBGs 。為了檢查使用了哪些 RBGs ，連接 LteSimpleSpectrumPhy 到下行信道。注意，當發生數據下行信道傳輸時，傳遞信號TxPsd 頻譜值以檢查哪些 RBs 用於傳輸。測試向量包含 Hard 和 Strict FR 算法（使用這種方式檢查其他算法沒有任何意義，因為它們使用整個小區帶寬）的一系列配置。如果沒有不允許使用 RBGs ，則測試通過。

第二種類型的 test cases 檢查是否提供給用戶合適的子頻帶和合適的發射功率。一個使用頻率復用算法，另一個不使用。第二個基站負責在整個系統帶寬生成干擾。由第一個基站提供服務的用戶每隔幾秒時間（相當慢，因為上報新的用戶測量需要時間）會改變位置。為了檢查該用戶使用了哪些 RBGs ，連接 LteSimpleSpectrumPhy 到下行信道。注意，當出現小區１中數據下行信道傳輸時，傳遞信號 TxPsd 頻譜值，以檢查哪些 RBs 用於傳輸以及它們的功率等級。相同的方法可以應用到上行方向，且第二個 LteSimpleSpectrumPhy 連接到上行信道。如果由基站提供服務的用戶，使用頻率復用算法在上行和下行服務時具有預期的 RBs 和預期的功率等級，則測試通過。測試向量包含 Strict FR、 Soft FR、Soft FFR 和 Enchanced FFR算法的一系列配置。每種 FR 算法使用所有的調度器進行測試，調度器支持 FR （例如， PF、PSS、CQA、TD-TBFQ 和 FD-TBFQ）。（Hard FR 並不使用用戶測量，因此使用 Hard FR 執行該類型的測試將毫無意義。）

Distributed FFR 算法的 test case與上述非常相似，但是因為基站需要交換一些信息，因此需要考慮啟用 EPC 和 X2 接口的場景。並且，兩者基站都要使用 Distributed FFR 算法。在第一個小區中有兩個用戶，第二個小區中有一個用戶。每個用戶的位置是變化的（因為需要上報新的用戶測量，所以相當慢），目的是從 Distributed FFR 算法實體中獲取不同的計算結果。為了檢查哪些 RBGs 用於用戶傳輸，連接 LteSimpleSpectrumPhy 到下行信道。注意，當出現數據下行信道傳輸時，傳遞信號 TxPsd 頻譜值，檢查哪些RBs 用於傳輸以及它們的功率等級。同樣的方法適用於上行方向，其次連接 LteSimpleSpectrumPhy 到上行信道。如果由小區２中的基站提供服務的用戶，在上行和下行服務時具有預期的 RBs 和預期的功率等級，則測試通過。測試向量包含 Distributed FFR配置。測試可以在所有的調度器中進行，其中調度器支持 FR （例如　PF、 PSS、 CQA、TD-TBFQ 和 FD-TBFQ）。

2.2.33 Inter-cell Interference with FR algorithms Tests（使用頻率復用算法的小區間干擾測試）

test suite lte-interference-fr 與 lte-interference 非常相似。拓撲（圖 Topology for the inter-cell interference test）是一樣的，並且測試檢查干擾水平。區別是，在該 test case 中，頻率復用算法是可以啟用的，並且我們在不同的 RBGs （不止一個）上檢查干擾水平。例如，當我們在基站上安裝 Hard FR 算法時，前一半系統帶寬分配給一個基站，后半部分系統帶寬分配給第二個基站，相比傳統的干擾場景，干擾水平應該更低。測試向量包含所有可用的頻率復用算法的一系列配置。如果在特定 RBs 上計算的 SINR 等於從 Octave 腳本中獲得的值，則測試通過。

參考文獻：

https://www.nsnam.org/docs/models/html/lte-testing.html

免責聲明！

本站轉載的文章為個人學習借鑒使用，本站對版權不負任何法律責任。如果侵犯了您的隱私權益，請聯系本站郵箱yoyou2525@163.com刪除。

猜您在找 [翻譯]：Cinemachine 官方文檔（0） Smack文檔（翻譯） at for lte LTE Module User Documentation（翻譯1）——背景、使用概述、基本的仿真程序和配置LTE模型參數測試文檔文檔測試測試文檔 FullCalendar 官方文檔翻譯 uWSGI配置文檔翻譯 NoVNC API 文檔翻譯