LTE 測試文檔（翻譯）

時間 2019-11-15

標籤 lte 測試文檔翻譯简体版

原文原文鏈接

Testing Documentation 翻譯

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

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 上傳輸的功率：node

$\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 描述了場景的拓撲結構。參數

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

表示干擾距離。咱們注意到，這樣的場景拓撲致使上行和下行的干擾距離是相同的；固然，感知到的實際干擾功率是不一樣的，緣由是上行和下行頻帶不一樣的傳播損耗。經過改變

和

參數，能夠得到不一樣的 test cases 。

_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 A三、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。

$\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^{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 腳本中得到的值，則測試經過。