3G/4G基站物理層黑匣子驗(yàn)證方法

　　引言

　　電信時(shí)代尚未達(dá)到頂峰。預(yù)計(jì)到 2016年用戶數(shù)據(jù)傳輸速率將達(dá)到每月 6 EB.新通信技術(shù)的發(fā)展旨在確保滿足日益增加的數(shù)據(jù)傳輸速率要求。3GPP 標(biāo)準(zhǔn)逐步發(fā)展，以確保滿足這些要求。與此同時(shí)，運(yùn)營商為提供良好的用戶覆蓋體驗(yàn)而引入了小型蜂窩需求，蜂窩拓?fù)湟舶l(fā)生了改變。

　　在這種有利的情況下，半導(dǎo)體公司提供了廣泛的產(chǎn)品組合，以應(yīng)對(duì)不同的業(yè)務(wù)情況?；緛碇v，物理層(L1)的產(chǎn)品包括片上系統(tǒng)(SoC)、基于 FPGA(現(xiàn)場可編程門陣列)的解決方案、多核數(shù)字信號(hào)處理器(DSP)、基帶加速器、ASIC(特定應(yīng)用集成電路)、網(wǎng)絡(luò)處理器或這些元件的組合。從硬件方面來看，這些都是非常復(fù)雜的平臺(tái)，具有大容量和豐富的功能集。 這是將為此類平臺(tái)編寫的軟件分割成更小的功能部件、通常來自于不同來源和供應(yīng)商的主要原因： 例如，物理層(L1)、數(shù)據(jù)鏈路和網(wǎng)絡(luò)層(L2-L3)、操作系統(tǒng)(OS)、板級(jí)支持包(BSP)等。每個(gè)功能部件都有其自身的挑戰(zhàn)和性能要求。 因此每個(gè)部件都需要獨(dú)立進(jìn)行測試，確保完全符合產(chǎn)品要求。

　　在此類混合系統(tǒng)中，測試通常分兩個(gè)階段進(jìn)行：

　　- 單獨(dú)測試每個(gè)軟件模塊

　　· 這個(gè)階段確保每個(gè)組件或模塊獨(dú)立工作正常，由測試儀或控制臺(tái)激勵(lì)。

　　- 系統(tǒng)集成測試 (SIT)

　　· 這一階段確保所有組件以正確的方式協(xié)同工作。

　　· 所有模塊的輸入測試空間通常過大，在本階段無法覆蓋;因此本階段不注重覆蓋范圍。

　　測試和釋放流程需要考慮這兩個(gè)測試階段。盡管L1在SIT驗(yàn)證過程中進(jìn)行了檢驗(yàn)，但如果驗(yàn)證目的是特定的物理層功能，那么本階段不一定需要提供所需的控制力。 這是因?yàn)閺?qiáng)加特定L1流的決策源自高層邏輯。此外，在 SIT 驗(yàn)證過程中，測試結(jié)論只能基于特定流程(如成功的UE附著或獲得給定的吞吐量)的輸出，在這種情況下，L1 的行為對(duì)測試結(jié)果有很大影響?？梢哉f，SIT 驗(yàn)證階段間接測試了L1 的功能。為了充分控制和驗(yàn)證 L1 獨(dú)立工作時(shí)的功能，必須定義一個(gè)獨(dú)特的控制層，從而應(yīng)對(duì)上述規(guī)定的限制。

　　圖 1 協(xié)議實(shí)體與 L1交互簡圖

　　將驗(yàn)證功能只集中于L1,會(huì)剝奪高層實(shí)體的功能，使其只能提供最小功能，甚至還可能將一些層一起丟棄。例如，為了保持一致統(tǒng)一的L1行為，需要定義一個(gè)調(diào)度邏輯，來取代MAC,無需考慮實(shí)際部署中有效的限制。 但不再需要與 PDCP和 IP協(xié)議棧進(jìn)行交互，因?yàn)閺腖1的角度來看，用戶平面數(shù)據(jù)最終被作為一系列傳輸塊饋送。RRC邏輯被剝奪了其非接入層特權(quán)，只能管理來往于物理層的控制消息流。 在典型的小型蜂窩環(huán)境下，用來與L1進(jìn)行交互的一組消息通常遵從FAPI 規(guī)范或其衍生規(guī)范。

　　環(huán)境設(shè)置

　　飛思卡爾黑匣子的目的是提供面向自動(dòng)化測試環(huán)境的解決方案，取代全協(xié)議測試，使用模擬高層(L2-3)軟件包，以驗(yàn)證飛思卡爾的物理層軟件解決方案。它擁有測試解決方案的基本功能，如捕捉和上報(bào)測試結(jié)果，還顯示來自軟件架構(gòu)不同點(diǎn)的大量日志，這些點(diǎn)包括： L1、模擬高層(L2)和測試腳本。黑匣子所用的環(huán)境包含以下各項(xiàng)：

　　· DUT - 被測設(shè)備 3G/4G 基站

　　· CCE - 中央控制節(jié)點(diǎn)

　　· L2STUB - 功能剝離的高層

　　· 輪詢代理 - 定期查詢數(shù)據(jù)庫獲得可執(zhí)行的任務(wù)(包含要運(yùn)行的測試及其輸入?yún)?shù))的代理

　　· TM - 測試終端設(shè)備，第三方 UE(用戶設(shè)備)模擬器

　　· VSA - 矢量信號(hào)分析儀

　　· VSG - 矢量信號(hào)發(fā)生器

　　· Web服務(wù)器

　　測試可從開發(fā)人員計(jì)算機(jī)上的終端上運(yùn)行，也可以使用Web服務(wù)器間接地運(yùn)行，這個(gè)服務(wù)器提供一個(gè)運(yùn)行各種套件或測試用例的接口。測試套件可直接由用戶排隊(duì)，并動(dòng)態(tài)執(zhí)行，也可以安排為定期運(yùn)行。輪詢代理定期查詢?nèi)蝿?wù)隊(duì)列，可按優(yōu)先級(jí)對(duì)任務(wù)排序，如果有任務(wù)可執(zhí)行，則開始執(zhí)行包含在套件中的測試用例。 所有信息被傳送到中央控制節(jié)點(diǎn)，中央控制節(jié)點(diǎn)負(fù)責(zé)運(yùn)行測試腳本，并與 L2STUB 和 TM 進(jìn)行通信，以發(fā)送測試中指定的命令，并收集信息和調(diào)試消息進(jìn)行記錄。此外，它還可以作為決策點(diǎn)，根據(jù)測試用例定義所用的腳本內(nèi)容做出“通過/未通過/錯(cuò)誤”等測試結(jié)果判定。

　　圖 2 飛思卡爾黑匣子設(shè)置

　　數(shù)據(jù)庫用于存儲(chǔ)任務(wù)隊(duì)列、測試結(jié)果、任務(wù)歷史和日志。Web 服務(wù)器使用數(shù)據(jù)庫中的信息來生成報(bào)告，渲染網(wǎng)頁。

　　L2STUB 的主要目的是生成話務(wù)和 FAPI 配置消息。 它擁有最小的高層邏輯，提供多種選項(xiàng)，用于處理上下行鏈路的調(diào)度請(qǐng)求、混合自動(dòng)重傳請(qǐng)求重新傳輸、邏輯信道復(fù)用，此外，還提供有關(guān)L1狀態(tài)的統(tǒng)計(jì)數(shù)據(jù)，如循環(huán)冗余校驗(yàn)、誤碼率等。測試腳本能夠控制 L2STUB 和 TM,如下圖所示：

　　圖 3 飛思卡爾黑匣子設(shè)置

　　測試終端設(shè)備和 VSA/VSG 模擬具有特定功能的移動(dòng)臺(tái)/用戶設(shè)備 (UE) 的行為。 測試終端設(shè)備可有兩種操作模式：

　　- 完整的協(xié)議棧模式

　　· 在這種模式下，實(shí)施OSI 協(xié)議棧的L1-L3,TM 如同普通 UE一樣運(yùn)行。

　　· 通過TM 進(jìn)行的測試必須在基站側(cè)通過完整的協(xié)議棧來執(zhí)行。

　　· L1 的信令通過標(biāo)準(zhǔn)的信令信道進(jìn)行

　　- L1 獨(dú)立模式(黑匣子模式)

　　· 在這種模式下，在TM內(nèi)只實(shí)施L1.

　　· 通過TM 進(jìn)行的測試可在基站側(cè)通過L2 存根+ L1來執(zhí)行。

　　· TM 只處理物理信道

　　· 任何 L1 信令都通過借助腳本發(fā)送的專用命令執(zhí)行

　　VSA 和 VSG 僅僅是 L1 設(shè)備，只能解碼或生成物理信道。它們用來更精細(xì)地控制 L1,通常用于一致性測試。該術(shù)語表示根據(jù)所有設(shè)備必須遵從的標(biāo)準(zhǔn)給出的某些預(yù)定義測試用例。[!--empirenews.page--]

　　VSA 是一個(gè)信號(hào)分析儀，具有頻譜分析功能。它擁有多個(gè)功能，如：

　　- 顯示信號(hào)質(zhì)量指標(biāo)(誤差矢量幅度、峰值因子、峰均功率比)

　　- 檢測特定物理信道的存在

　　- 檢測編碼傳輸塊的內(nèi)容。

　　VSG 是矢量信號(hào)發(fā)生器。 它擁有多個(gè)功能，如：

　　- 應(yīng)用無線信道模式

　　- 應(yīng)用噪聲

　　- 生成物理信道

　　- 引起誤碼

　　- 創(chuàng)建預(yù)定義的一致性測試配置

　　這兩種設(shè)備都可以通過腳本進(jìn)行指揮，可用于一致性測試套件。

　　自動(dòng)化

　　黑匣子支持全自動(dòng)化：用戶只需觸發(fā)測試，然后查看結(jié)果。“通過/未通過”測試結(jié)果由腳本結(jié)果決定，被聚集在一起，并呈現(xiàn)為一個(gè)網(wǎng)頁。

　　所描述的解決方案可實(shí)現(xiàn)參數(shù)覆蓋，支持非回歸測試，以及逆向測試的受控環(huán)境。如果用戶請(qǐng)求運(yùn)行非回歸測試套件，則需要提供帶有測試狀態(tài)報(bào)告的電子郵件。中央控制節(jié)點(diǎn)在數(shù)據(jù)庫中查詢只關(guān)于非回歸過程中運(yùn)行的測試的信息，并生成一個(gè)表格，其中包含：測試狀態(tài)、輸入?yún)?shù)、測試時(shí)長及Web服務(wù)器的鏈接，用戶可在Web服務(wù)器上找到運(yùn)行測試的過程中所生成的所有日志。我們可以將所有這些匯總成一個(gè)黑匣子所需要的有限狀態(tài)機(jī)。

　　圖 4 自動(dòng)化中使用的黑匣子有限狀態(tài)機(jī)

　　設(shè)置非回歸測試套件定期運(yùn)行(例如在夜間)，但只有當(dāng)CVS(并發(fā)版本系統(tǒng))中的開發(fā)人員查看了二進(jìn)制文件的時(shí)間戳并執(zhí)行后，成功編寫了運(yùn)行在DSP 和 L2STUB 上的軟件時(shí)，才能觸發(fā)非回歸測試。

　　用戶可將場景定義為一個(gè)腳本，并創(chuàng)建一個(gè)套件(可從Web服務(wù)器圖形界面觸發(fā)該套件)，表示實(shí)際腳本前后運(yùn)行的規(guī)定流程中要運(yùn)行一批腳本和輸入?yún)?shù)。

　　此外，發(fā)生硬件故障或不可恢復(fù)的軟件錯(cuò)誤時(shí)，或新測試用例開始時(shí)，如果要求設(shè)置不變，則還可支持從腳本重新啟動(dòng)設(shè)備。獲得授權(quán)后，用戶可重新啟動(dòng)基站和測試終端。

　　案例研究

　　上述解決方案已經(jīng)在飛思卡爾 BSC913x 平臺(tái)上實(shí)施并驗(yàn)證，在飛思卡爾 PowerPC 處理器 e500 上部署L2STUB,物理層(DUT)在 StarCore? SC3850 上運(yùn)行。 BSC9131的框圖如圖 5 所示。BSC9131 還充分利用了名為 MAPLE-B2F 的基帶加速器。

　　L2STUB 通過專有的處理器間通信機(jī)制管理 FAPI 消息流。描述既定驗(yàn)證情境的命令由最終用戶在中央控制節(jié)點(diǎn)通過解析語言預(yù)定義。指定了多個(gè)不同的 API,以獨(dú)立地分別控制TM、VSA 和VSG。

　　圖 5 BSC9131框圖

　　(圖字)StarCore? SC3850 ;DSP內(nèi)核;32KB L1 I 緩存;32KB L1 D緩存;基于Power Architecture的e500 內(nèi)核;32位DDR3/3L 內(nèi)存控制器;MAPLE-B2F基帶加速器 LTE/MTS/CDMA2K;射頻接口(JESD207/ADI)和MaxPHY;多核結(jié)構(gòu);時(shí)鐘/重置;DMA;安全引擎V4.4;USB 2.0;以太網(wǎng)

　　上述設(shè)置是完全自動(dòng)化的，可充分利用這個(gè)特點(diǎn);現(xiàn)在已經(jīng)設(shè)想了對(duì) L1 驗(yàn)證的主要范圍進(jìn)行多個(gè)擴(kuò)展。例如，黑匣子設(shè)置支持持續(xù)集成，作為一個(gè)開發(fā)實(shí)踐，確保已公布的代碼不會(huì)在特定的開發(fā)分支導(dǎo)致回歸。這與非回歸測試不同，區(qū)別在于防止錯(cuò)誤代碼序列進(jìn)入開發(fā)分支，而不是在公布后才發(fā)現(xiàn)。

　　全自動(dòng)化還為建立地域上分散的測試環(huán)境創(chuàng)造了一個(gè)條件，這個(gè)測試環(huán)境將許多驗(yàn)證節(jié)點(diǎn)集群在一起。

　　飛思卡爾解決方案是一個(gè) 3GPP 協(xié)議棧，可適應(yīng) 3G 解決方案(UMTS - 通用陸地移動(dòng)系統(tǒng))或4G 解決方案(E-UTRA - 演進(jìn)的通用陸地?zé)o線接入)。黑匣子方法對(duì)于這種情況有所裨益，它分離測試L1,不受上層的影響。 可確定的潛在問題包括：

　　- SC3850 內(nèi)核、MAPLE-B2F的硬件問題或相關(guān)的附件硬件支持。

　　- SC3850的L1軟件代碼

　　- MAPLE-B2F的L1微代碼

　　結(jié)束語

　　本文介紹的解決方案用于在更加復(fù)雜的SoC中只測試L1軟件和硬件解決方案。結(jié)果表明，與完整的協(xié)議測試解決方案相比，該解決方案能夠最佳地覆蓋L1參數(shù)，而且參數(shù)空間更寬。

　　L1黑匣子測試需要?jiǎng)冸x L2實(shí)現(xiàn)，使其只能提供最小的功能。此外，它還需要來自第三方、普遍被接受的測試設(shè)備。此類測試環(huán)境的成本比系統(tǒng)集成測試方法低很多，并支持更精確的問題跟蹤，避免軟件的獨(dú)立部件發(fā)生軟件Bug交互。

　　此外，測試環(huán)境的一個(gè)重要方面是自動(dòng)化，用于連接測試方案、測試執(zhí)行和測試報(bào)告，以運(yùn)行多個(gè)測試套件。