專利名稱：Umb區(qū)站調(diào)制解調(diào)器架構(gòu)和方法
技術(shù)領(lǐng)域：
本發(fā)明的公開內(nèi)容主要涉及區(qū)站調(diào)制解調(diào)器，更具體地，涉及使用區(qū)站調(diào)制解調(diào) 器進行定時對準(zhǔn)和RF控制。
背景技術(shù)：
無線通信系統(tǒng)已經(jīng)廣泛部署以提供各種類型的通信內(nèi)容，例如，語音、數(shù)據(jù)等。這 些系統(tǒng)可以是多址系統(tǒng)，其能夠通過共享可用系統(tǒng)資源(例如，帶寬和發(fā)射功率)來支持與 多個用戶的通信。這些多址系統(tǒng)的實例包括碼分多址(CDMA)系統(tǒng)、時分多址(TDMA)系統(tǒng)、 頻分多址(FDMA)系統(tǒng)、3GPP LTE系統(tǒng)以及正交頻分多址(OFDMA)系統(tǒng)。通常，無線多址通信系統(tǒng)可以同時支持多個無線終端進行通信。每個終端通過前 向鏈路和反向鏈路(又稱為返回鏈路或上行鏈路)上的傳輸與一個或者多個基站進行通 信。前向鏈路(或下行鏈路)是指從基站到終端的通信鏈路，而反向鏈路(又稱為返回鏈 路或上行鏈路)是指從終端到基站的通信鏈路?？梢酝ㄟ^單輸入單輸出系統(tǒng)、多輸入單輸 出系統(tǒng)或多輸入多輸出(MIMO)系統(tǒng)來建立該通信鏈路。MIMO系統(tǒng)使用多個(Nt)發(fā)射天線和多個(Nk)接收天線進行數(shù)據(jù)傳輸。Nt個發(fā)射 天線和Nk個接收天線組成的MIMO信道可以分解為Ns個獨立信道，其也被稱為空間信道，其 *Ns<min{NT，NK}。Ns個獨立信道中的每一個對應(yīng)于一個維度。如果利用多個發(fā)射天線 和接收天線創(chuàng)建的額外的維數(shù)，則MIMO系統(tǒng)能夠提供更好的性能(例如，更高的吞吐量和 /或更高的可靠性)。例如，MIMO系統(tǒng)可以支持時分雙工(TDD)系統(tǒng)和頻分雙工(FDD)系 統(tǒng)。在TDD系統(tǒng)中，前向鏈路傳輸和反向鏈路傳輸在相同的頻率區(qū)域上，使得互易原理允許 從反向鏈路信道估算前向鏈路信道。這就使得當(dāng)接入點存在多個天線時，接入點可以在前 向鏈路上提取出發(fā)射波束成形增益。當(dāng)今的寬帶無線系統(tǒng)要求效率高、功能強的硬件，例如，專用集成電路(ASIC)，來 支持高速率的數(shù)據(jù)通信，并且也要求高度靈活的裝置來支持多變的控制信道。數(shù)據(jù)信道通 常使用標(biāo)準(zhǔn)調(diào)制技術(shù)，如四相相移鍵控(QPSK)、正交幅度調(diào)制(QAM)等。然而，控制信道(包 括不同的導(dǎo)頻信道)需要特別處理?？刂菩诺辣举|(zhì)上只有較低的吞吐量，但卻要求高可靠 性。因此，控制信道通常采用特殊的調(diào)制方案，不規(guī)則且變化的音調(diào)/正交頻分復(fù)用(OFDM) 符號資源分配，信道特定的跳變，以及在不同信道中重用音調(diào)資源。并且，作為無線標(biāo)準(zhǔn)演 進的一部分，控制信道也在隨著時間改變。不同的標(biāo)準(zhǔn)(例如超移動寬帶(UMB)和長期演進 (LTE))中的控制信道格式在系統(tǒng)中也有很大的區(qū)別且具有靈活性，以便適應(yīng)多功能性的這 種或那種需要。

發(fā)明內(nèi)容
本發(fā)明公開了用于定時對準(zhǔn)和/或RF控制的裝置和方法。根據(jù)一個方面，用于采 樣同步的方法包括從射頻前端(RFFE)接收返回鏈路(RL)時間戳；從導(dǎo)航和定時系統(tǒng)接 收系統(tǒng)時間秒；基于RL時間戳和系統(tǒng)時間秒生成前向鏈路(FL)時間戳；并將FL時間戳和 系統(tǒng)時間秒包括到時間數(shù)據(jù)中。根據(jù)另一個方面，用于RF控制的方法，包括在存儲器中存儲增益信息和選通 控制信息；以及執(zhí)行以下一個或多個步驟發(fā)送第一期望時間戳和增益信息到射頻前端 (RFFE)；發(fā)送第二期望時間戳和txEnable命令到發(fā)送選通控制；或者發(fā)送第三期望時間戳 和rxEnable命令到接收選通控制。根據(jù)另一個方面，用于采樣同步的區(qū)站調(diào)制解調(diào)器(CSM)包括如下配置的處理器 和電路從射頻前端(RFFE)接收返回鏈路(RL)時間戳；從導(dǎo)航和定時系統(tǒng)接收系統(tǒng)時間 秒；基于RL時間戳和系統(tǒng)時間秒生成前向鏈路(FL)時間戳；以及將FL時間戳和系統(tǒng)時間 秒包括到時間數(shù)據(jù)中。根據(jù)另一個方面，用于RF控制的區(qū)站調(diào)制解調(diào)器(CSM)包括如下配置的處理器和 電路在存儲器中存儲增益信息和選通控制信息；以及執(zhí)行以下一個或多個步驟發(fā)送第 一期望時間戳和增益信息到射頻前端(RFFE)；發(fā)送第二期望時間戳和txEnable命令到發(fā) 送選通控制；或者發(fā)送第三期望時間戳和rxEnable命令到接收選通控制。根據(jù)另一個方面，用于采樣同步的設(shè)備包括用于從射頻前端(RFFE)接收返回鏈 路(RL)時間戳的模塊；用于從導(dǎo)航和定時系統(tǒng)接收系統(tǒng)時間秒的模塊；用于基于RL時間 戳和系統(tǒng)時間秒生成前向鏈路(FL)時間戳的模塊；以及用于將FL時間戳和系統(tǒng)時間秒包 括到時間數(shù)據(jù)中的模塊。根據(jù)另一個方面，用于RF控制的設(shè)備，包括用于在存儲器中存儲增益信息和選 通控制信息的模塊；以及用于執(zhí)行以下一個或多個步驟的模塊發(fā)送第一期望時間戳和增 益信息到射頻前端(RFFE)；發(fā)送第二期望時間戳和txEnable命令到發(fā)送選通控制；或者發(fā) 送第三期望時間戳和rxEnable命令到接收選通控制。根據(jù)另一個方面，計算機可讀介質(zhì)包括存儲于其上的程序代碼，所述計算機可讀 介質(zhì)包括用于從射頻前端(RFFE)接收返回鏈路(RL)時間戳的程序代碼；用于從導(dǎo)航 和定時系統(tǒng)接收系統(tǒng)時間秒的程序代碼；用于基于RL時間戳和系統(tǒng)時間秒生成前向鏈路 (FL)時間戳的程序代碼；以及用于將FL時間戳和系統(tǒng)時間秒包括到時間數(shù)據(jù)中的程序代碼。根據(jù)另一個方面，計算機可讀介質(zhì)包括存儲于其上的程序代碼，所述計算機可讀 介質(zhì)包括用于在存儲器中存儲增益信息和選通控制信息的程序代碼；以及用于執(zhí)行以下 一個或多個步驟的程序代碼發(fā)送第一期望時間戳和增益信息到射頻前端(RFFE)；發(fā)送第 二期望時間戳和txEnable命令到發(fā)送選通控制；或者發(fā)送第三期望時間戳和rxEnable命 令到接收選通控制。本發(fā)明的優(yōu)勢包括使用通用串行接口對準(zhǔn)前向鏈接和反向鏈接(通常稱為返回 鏈接)之間的定時參考的能力，以及使用同一通用串行接口提供RF控制功能的能力。需要理解的是，對于本領(lǐng)域技術(shù)人員來說，根據(jù)以下詳細描述，本發(fā)明的其他方面將是顯而易見的，其中以舉例說明的方式示出并且描述了各個方面。附圖和詳細描述應(yīng)當(dāng) 認為是示例性的而不是限定性的。


圖1示出了多址無線通信系統(tǒng)的實例的框圖；圖2示出了無線MIMO通信系統(tǒng)的實例的框圖；圖3示出了有數(shù)個接口的區(qū)站調(diào)制解調(diào)器(CSM)的邏輯架構(gòu)的實例；圖4示出了用于所有CSM的一個管理主機的實例；圖5示出了第一階段超移動寬帶(UMB)接入點(AP)參考設(shè)計架構(gòu)的實例；圖6示出了第二階段UMB AP參考設(shè)計架構(gòu)的實例；圖7示出了在前向鏈路(FL)和返回鏈路(RL)上處理數(shù)據(jù)信道MAC分組所涉及的 關(guān)鍵元件的實例；圖8示出了 CSM消息頭部的實例；圖9示出了業(yè)務(wù)信道分配消息流的實例；圖10示出了前向鏈路(FL)數(shù)據(jù)流和加密掩碼生成的實例；圖11示出了返回鏈路(RL)數(shù)據(jù)流和解密的實例；圖12示出了接入點的示例性框圖；圖13示出了 FL和RL采樣接口的示例性表示；圖14示出了用于采樣同步的示例性流程圖；圖15示出了適用于采樣同步的設(shè)備的實例；圖16示出了用于RF控制的示例性流程圖；圖17示出了適用于RF控制的設(shè)備的實例；圖18示出了包括與存儲器進行通信的處理器的設(shè)備的實例，以用于采樣同步和/ 或RF控制。
具體實施例方式在下文中展示的詳細說明結(jié)合附圖將試圖作為若干個方面對本發(fā)明的說明，但并 不代表本發(fā)明在部署實施時局限于這些方面。本公開中描述的每一個方面，僅僅是作為本 公開的實例或舉例說明被提供，不應(yīng)當(dāng)被認為比其他方面優(yōu)選或者更有利。下文中的詳細 描述包含了用于提供對本公開的完整深入理解的特定細節(jié)。但是，對本領(lǐng)域的技術(shù)人員而 言顯而易見的是，即使沒有這些特定細節(jié)，也能對本公開進行實施。在一些實例中，眾所周 知的結(jié)構(gòu)和設(shè)備以框圖的形式被給出，以避免和本公開的概念相混淆。僅僅是出于方便和 簡潔的原因，可以使用縮略語和其他描述性的術(shù)語，但這不意味著限制本公開的保護范圍。同時，出于簡化解釋的目的，方法被表示和描述為一系列的動作，應(yīng)當(dāng)理解并意識 到，這些動作并沒有先后順序的限制，根據(jù)一個或多個方面，某些動作可能以不同順序發(fā) 生，和/或與本文表示和描述的其他動作同時發(fā)生。例如，本領(lǐng)域的技術(shù)人員能夠理解并意 識到，方法可能可替換地被描述為一系列相互關(guān)聯(lián)的狀態(tài)或事件，比如在狀態(tài)圖中。并且， 并不是需要所有示出的動作來實現(xiàn)根據(jù)一個或多個方面的方法。下文中描述的技術(shù)可以用于各種不同的無線通信系統(tǒng)，例如碼分多址(CDMA)系統(tǒng)、時分多址(TDMA)系統(tǒng)、頻分多址(FDMA)系統(tǒng)、正交FDMA (OFDMA)系統(tǒng)、單載波 FDMA(SC-FDMA)系統(tǒng)等。術(shù)語〃系統(tǒng)〃和〃網(wǎng)絡(luò)〃經(jīng)?？山粨Q使用。CDMA系統(tǒng)可以實現(xiàn) 無線技術(shù)，比如通用陸地?zé)o線接入(UTRA)、cdma2000等。UTRA包括寬帶-CDMA (W-CDMA)和 低碼片速率(LCR)。Cdma2000包括IS-2000、IS-95和IS-856標(biāo)準(zhǔn)。TDMA系統(tǒng)可以實現(xiàn) 諸如全球移動通信系統(tǒng)(GSM)等無線技術(shù)。OFDMA系統(tǒng)可以實現(xiàn)諸如演進UTRA(E-UTRA)、 IEEE 802. 11、IEEE 802. 16、IEEE 802. 20、Flash-OFDM 等無線技術(shù)。UTRA, E-UTRA 禾口 GSM是通用移動通信系統(tǒng)(UTMS)的一部分。長期演化(LTE)是即將推出的使用E-UTRA 的UTMS的一個版本。UTRA、E-UTRA, GSM、UMTS和LTE的描述見于被稱為〃第三代合作伙 伴計劃"(3GPP)的組織的文檔中。Cdma2000的描述見于被稱為"第三代合作伙伴計劃 2" (3GPP2)的組織的文檔中。這些各種無線技術(shù)和標(biāo)準(zhǔn)是現(xiàn)有技術(shù)。此外，單載波頻分多址(SC-FDMA)是另外一種無線通信技術(shù)，它利用單載波調(diào)制 和頻域均衡。SC-FDMA系統(tǒng)和OFDMA系統(tǒng)具有相似的性能和相同的總體復(fù)雜度。由于其固 有的單載波結(jié)構(gòu)，SC-FDMA信號具有更低的峰均功率比(PAPR)。SC-FDMA已引起廣泛的注 意，尤其是在上行鏈路通信中，其中就發(fā)射功率效率而言，較低的PAI^R極大地有益于移動 終端。在3GPP長期演進(LTE)或演進UTRA中，對于上行鏈路多址方案，使用SC-FDMA技術(shù) 在當(dāng)前是一種可行的假設(shè)。所有上述無線通信技術(shù)和標(biāo)準(zhǔn)都可以和本發(fā)明中描述的數(shù)據(jù)中 心式復(fù)用算法一起使用。圖1的框圖示出了多址無線通信系統(tǒng)的例子。如圖1所示，接入點IOO(AP)包括 多組天線，一組包括天線104和106，另一組包括天線108和110，還有一組包括天線112和 114。在圖1中，對于每組天線只示出了兩個天線，但是，對于每個天線組可以使用更多或者 更少的天線。接入終端Iie(AT)與天線112和天線114進行通信，其中天線112和天線114 通過前向鏈路120將信息發(fā)送到接入終端116，通過反向鏈接118從接入終端116接收數(shù) 據(jù)。接入終端122與天線106和天線108進行通信，其中天線106和天線108通過前向鏈 路126將信息發(fā)送到接入終端122，通過反向鏈接124從接入終端122接收數(shù)據(jù)。在FDD系 統(tǒng)中，通信鏈路118、120、124和126可以使用不同頻率進行通信。例如，前向鏈路120可以 使用和反向鏈路118不同的頻率。每組天線和/或其被設(shè)計來進行通信的區(qū)域通常被稱為 接入點的扇區(qū)。在一個例子中，接入點100覆蓋的區(qū)域中，每個天線組被設(shè)計為和扇區(qū)中的 接入終端進行通信。在前向鏈路120和126上的通信中，接入點100的發(fā)射天線利用波束成形以提高 不同接入終端116和124的前向鏈路的信噪比。此外，接入點使用波束成形向其覆蓋范圍 內(nèi)隨機分散的接入終端進行發(fā)射，與接入點使用單一的天線向其所有接入終端進行發(fā)射相 比，這樣對相鄰小區(qū)中的接入終端造成的干擾更少。接入點可以是固定站。接入點也被稱 為接入節(jié)點、基站或本領(lǐng)域已知的一些其他類似的術(shù)語。接入終端也被稱為移動站、用戶設(shè) 備(UE)、無線通信設(shè)備或本領(lǐng)域已知的一些其他類似的術(shù)語。圖2的框圖示出了無線MIMO通信系統(tǒng)的例子。圖2顯示了 MIMO系統(tǒng)200中的接 入點210和接入終端250。在接入點210，從數(shù)據(jù)源212提供多個數(shù)據(jù)流的業(yè)務(wù)數(shù)據(jù)給發(fā)射 (TX)數(shù)據(jù)處理器214。在一個例子中，每一個數(shù)據(jù)流通過各自的發(fā)射天線進行發(fā)射。TX數(shù) 據(jù)處理器214基于為該數(shù)據(jù)流選定的特定編碼方案對業(yè)務(wù)數(shù)據(jù)進行格式化、編碼和交織， 以提供編碼的數(shù)據(jù)。
使用OFDM技術(shù)，每個數(shù)據(jù)流的編碼數(shù)據(jù)可以和導(dǎo)頻數(shù)據(jù)進行多路復(fù)用。導(dǎo)頻數(shù)據(jù) 通常是已知的數(shù)據(jù)模式，以已知的方式被處理，并且可以被接收機系統(tǒng)用于估計信道響應(yīng)。 然后，基于為數(shù)據(jù)流選定的特定調(diào)制調(diào)制方案(比如，BPSK、QSPK、M-PSK或M-QAM)，可以對 每個數(shù)據(jù)流調(diào)制(即，符號映射)復(fù)用的導(dǎo)頻數(shù)據(jù)和編碼數(shù)據(jù)，以提供調(diào)制符號。每個數(shù)據(jù) 流的數(shù)據(jù)率、編碼以及調(diào)制可以由處理器230執(zhí)行的指令決定。然后，針對所有數(shù)據(jù)流的調(diào)制符號被提供到TX MIMO處理器220，TXMIMO處理器 220可以進一步處理這些調(diào)制符號(例如，用于OFDM)。然后，TX MIMO處理器220提供Nt 個調(diào)制符號流到Nt個發(fā)射機(TMTR) 222a到222t。在一個例子中，TX MIMO處理器220給 數(shù)據(jù)流的符號和發(fā)射這些符號的天線應(yīng)用波束成形權(quán)重。每個發(fā)射機222a到222t接收并 處理各自的符號流，以提供一個或多個模擬信號，并進一步調(diào)整(例如，放大、濾波以及上 轉(zhuǎn)換)這些模擬信號，從而提供適合在MIMO信道上傳輸?shù)恼{(diào)制信號。然后，將來自發(fā)射機 222a到222t的Nt個調(diào)制信號分別從Nt個天線224a到224t發(fā)射。在接入終端250，發(fā)射的調(diào)制信號被Nk個天線252a到252r接收，被天線252a到 252r接收的每個信號依次提供到各自的接收機(RCVR) 254a到254r。每一個接收機254a 到254ι 調(diào)整(例如，濾波、放大以及下轉(zhuǎn)換)各自接收到的信號，數(shù)字化調(diào)整的信號以提供 采樣，并進一步處理這些采樣以提供對應(yīng)的"接收到的"符號流。然后，基于特定的接收機處理技術(shù)，RX數(shù)據(jù)處理器260從Nk接收機254a到254r 接收并處理這些Nk個接收到的符號流，以提供Nt個"檢測到的"符號流。接著，RX數(shù)據(jù)處 理器260解調(diào)、去交織并解碼每個檢測到的符號流，以便從數(shù)據(jù)流中恢復(fù)業(yè)務(wù)數(shù)據(jù)。RX數(shù)據(jù) 處理器260的處理和接入點210處的TXMIMO處理器220和TX數(shù)據(jù)處理器214的處理是相 反的。處理器270周期性地決定采用哪個預(yù)編碼矩陣(將在下文中介紹)。處理器270構(gòu) 造由矩陣索引部分和行列值部分組成的反向鏈路消息。反向鏈路消息可能包含各種類型的有關(guān)通信鏈路和/或接收到的數(shù)據(jù)流的信息。 然后，反向鏈路消息經(jīng)TX數(shù)據(jù)處理器238 (該處理器也從數(shù)據(jù)源236接收許多數(shù)據(jù)流的業(yè) 務(wù)數(shù)據(jù))處理、調(diào)制器280調(diào)制、發(fā)射機254a到254r調(diào)整，并發(fā)射回接入點210。在接入點210，從接入終端250發(fā)出的調(diào)制信號經(jīng)天線224a到224t接收、接收機 222a到222t調(diào)整、解調(diào)器240解調(diào)、RX數(shù)據(jù)處理器242處理，以提取出由接入終端250發(fā)送 的反向鏈路消息。接著，處理器230決定使用哪個預(yù)編碼矩陣來確定波束成形權(quán)重，接著， 處理器230對提取到的消息進行處理。本領(lǐng)域的技術(shù)人員應(yīng)該理解，收發(fā)機222a到222t在 前向鏈路上稱為發(fā)射機，在反向鏈路上稱為接收機。類似地，本領(lǐng)域的技術(shù)人員應(yīng)該理解， 收發(fā)機254a到254r在前向鏈路上稱為接收機，在反向鏈路上稱為發(fā)射機。在一個方面，區(qū)站調(diào)制解調(diào)器(CSM)實現(xiàn)接入點210的調(diào)制和解調(diào)功能。特別地， TX數(shù)據(jù)處理器214的調(diào)制器和接入點210的解調(diào)器240可以在整合的CSM中實現(xiàn)。圖3示 出了具有數(shù)個接口的區(qū)站調(diào)制解調(diào)器(CSM)的邏輯架構(gòu)。所有流入和流出CSM的信息可以 通過串行高速IO(sRIO)接口進行傳送。例如，sRIO接口用于和發(fā)送機和接收機的RF部分、 TX數(shù)據(jù)處理器214和RX數(shù)據(jù)處理器242中的媒體訪問控制(MAC)功能、以及處理器230中 的管理面軟件進行通信。MAC功能用于調(diào)節(jié)公共傳輸鏈路的多個用戶。通過直接存儲器寫 操作、sRIO消息以及門鈴(doorbell)，信息通過sRIO接口進行交換。在一個方面，門鈴是 短8比特或16比特的消息。在一個例子中，MAC和管理主機是邏輯實體，并且可以在同一硬件元件上并置。在一個例子中，管理接口提供CSM啟動和配置、自檢測、心跳、調(diào)試和診斷 記錄、統(tǒng)計檢索等機制。調(diào)試記錄是指在運行系統(tǒng)中發(fā)生的事件的可操作記錄。這些通過 消息進行報告并且包含協(xié)議和錯誤事件。診斷記錄被用于診斷或監(jiān)視系統(tǒng)的性能特性。MAC接口用于在CSM和MAC主機之間交換MAC和PHY信息。在前向鏈路(FL)中， MAC接口允許MAC主機向CSM指示將要通過空中鏈路發(fā)送的信息比特，例如，用于以下一個 或多個信道· F-SCCH (前向共享控制信道)· F-ACKCH (前向應(yīng)答信道)· F-SPCH (前向分組開始信道)· F-PQICH (前向?qū)ьl質(zhì)量指示符信道)· F-FOSICH (前向快速其他扇區(qū)干擾信道)· F-IOTCH(前向?qū)岣蓴_信道)· F-RABCH (前向反向活動比特信道)· F-DCH(前向數(shù)據(jù)信道)· F-PBCCH (前向主廣播控制信道)· F-SBCCH (前向輔廣播控制信道)在反向鏈路(RL)上，CSM向MAC主機提供通過空中鏈路接收到的比特，例如，用于 如下的一個或多個信道· R-ODCCH (反向OFDMA專用控制信道)· R-CQICH (反向信道質(zhì)量指示符信道)· R-REQCH (反向請求信道)· R-MQICH (反向MIMO質(zhì)量指示符信道)· R-SFCH(反向子帶反饋信道)· R-BFCH (反向波束反饋信道)· R-CDCCH (反向CDMA專用控制信道)· R-CQICH (反向信道質(zhì)量指示符信道)· R-REQCH (反向請求信道)· R-PAHCH(反向功率放大器凈空信道)· R-PSDCH (反向功率譜密度信道)· R-DCH(反向數(shù)據(jù)信道)除了通過信道發(fā)送的比特，MAC主機還使用消息接口來控制CSM中的各種算法的 行為，以用于功率控制、定時控制和多天線技術(shù)。關(guān)于該信息是如何傳輸?shù)募毠?jié)，將在下文 的RF控制接口部分描述。CSM射頻(RF)接口提供協(xié)議以用于在CSM和RF前端之間傳送時域同相正交(IQ) 基帶采樣控制消息。這個協(xié)議也提供具有網(wǎng)絡(luò)定時參考的CSM同步。在一個方面，接入點可以由多個發(fā)射/接收天線、CSM、MAC主機和管理主機組成。 在一個例子中，CSM可以支持多達4個發(fā)射天線和4個接收天線。CSM需要配置應(yīng)與其相關(guān) 聯(lián)的天線子集。單個MAC主機可以與多個CSM進行接口，以允許支持特定MAC信道上的多 個扇區(qū)載波。CSM配置有相關(guān)聯(lián)的MAC和管理主機。圖4示出了一個用于所有CSM的管理主機的例子。在一個例子中，接入點參考設(shè)計架構(gòu)包含CSM。在參考設(shè)計中，第二層模塊(L2M) 是MAC主機，控制面模塊(CPM)是管理主機。圖5示出了第一階段超移動寬帶(UMB)接入 點(AP)參考設(shè)計架構(gòu)的例子。在這個例子中，CSM是指3個現(xiàn)場可編程門陣列(FPGA)調(diào) 制解調(diào)器模塊(FMM)，其一起實現(xiàn)第一階段CSM功能。圖6示出了第二階段UMB AP參考設(shè)計架構(gòu)的例子。蜂窩調(diào)制解調(diào)器模塊(CMM) 現(xiàn)在包含CSM并且參考設(shè)計支持3個扇區(qū)。在一個方面，CSM實現(xiàn)例如如下的一個或多個 功能 來自編碼MAC信道的前向鏈路(FL)處理以生成基帶IQ采樣。 來自基帶IQ采樣的返回鏈路(又稱為反向鏈路)處理以解碼MAC信道。
可以由MAC主機來調(diào)節(jié)功率控制環(huán)靶(loop-target)?！γ總€接入終端(AT)估計RL定時校正。 在CSM內(nèi)終止混合ARQ (H-ARQ-自動重復(fù)請求)。 在CSM中實現(xiàn)多天線技術(shù)(ΜΙΜΟ-多輸入多輸出，SDMA-空分多址)，以及QORL-準(zhǔn) 正交反向鏈路)但由MAC主機進行控制?！ふ{(diào)試和診斷記錄?！ねㄟ^CSMAPI (應(yīng)用編程接口)中的get/set命令管理CSM配置。MAC主機軟件負責(zé)例如以下的一個或多個功能· FL活動隊列管理·信令協(xié)議分組的簽名/鑒權(quán) 路徑內(nèi)隧道協(xié)議 ·無線鏈路協(xié)議(RLP)-分段和組裝·流和路徑協(xié)議·分組合并(consolidation)協(xié)議·加密/解密支持· FL和RL數(shù)據(jù)信道MAC·開銷消息· R-CDCCH (反向CDMA專用控制信道)和R-ODCCH (反向OFDMA專用控制信道)消 息處理·使用CSM提供的定時校正的RL定時控制回路· FL和RL鏈路適配.FL和RL調(diào)度器·尋呼調(diào)度·連接控制面·信令協(xié)議·調(diào)試和診斷記錄在一個例子中，由CSM中的硬件加速器完成加密和解密。MAC主機通過sRIO接口 控制引擎。圖7示出了在前向鏈路(FL)和返回鏈路(RL)(又稱為反向鏈路)上處理數(shù)據(jù) 信道MAC分組的關(guān)鍵部件。MAC主機以每個流為基礎(chǔ)在外部存儲器中的隊列中存儲FL高層數(shù)據(jù)接收分組?；贔L調(diào)度算法，MAC主機通過sRIO接口從流的子集中將選取的分組復(fù) 制到CSM分組存儲器。MAC主機還指示加密引擎為CSM分組存儲器中的分組構(gòu)造加密屏蔽 位，并將這些屏蔽位存儲到CSM分組存儲器中。MAC主機調(diào)度器確定這些分組中的哪部分需 要在特定的物理層幀中以MAC分組的形式通過空中接口被發(fā)送，并發(fā)送消息到CSM指示它 如何構(gòu)造這些MAC分組。CSM引入分組的對應(yīng)字節(jié)，使用加密屏蔽位執(zhí)行異或操作，并生成 MAC分組，然后，由CSM發(fā)送機鏈的其余部分來處理MAC分組。在RL數(shù)據(jù)信道上接收MAC分組時，CSM處理MAC分組并將所有的PCP (分組封裝 協(xié)議)、路徑、流和MAC分組中的RLP頭部轉(zhuǎn)發(fā)到MAC主機。根據(jù)消息頭部，MAC主機指示加 密引擎對MAC分組中的每個SAR (分段和重組)載荷進行解密，并將結(jié)果寫入恰當(dāng)?shù)腗AC主 機存儲器位置。MAC主機中的RLP處理對來自SAR段的分組進行重組。在一個例子中，CSM API (應(yīng)用編程接口)包含CSM與MAC主機之間以及與管理主 機之間流過sRIO接口的協(xié)議和相關(guān)聯(lián)的消息。以引用方式納入本文的附錄A描述了該API。 通過直接存儲器讀寫操作、sRIO消息和門鈴，信息在sRIO接口上進行交換。例如，對于直 接存儲器存取，使用了標(biāo)準(zhǔn)的RapidIO輸入/輸出事務(wù)NREAD、WRITE、NWRITE和NWRITE_R。 圖8示出了 CSM消息頭部的例子。流過CSM API的消息具有圖8中示出的CSM消息頭部。 表1描述了 CSM消息頭部中各個字段的例子。表 1 在一個方面，CSM包含具有例如以下一個或多個功能的管理接口 開機啟動 機內(nèi)測試 心跳-運送系統(tǒng)時間戳和sRIO設(shè)備ID的消息，該sRIO設(shè)備ID標(biāo)識出CSM應(yīng)當(dāng) 將消息(例如記錄)發(fā)送到的管理主機。缺少來自CSM的心跳響應(yīng)可以被用來檢測CSM故 障以及啟動恢復(fù)過程的需要。 配置-包含各種用于配置CSM操作的配置參數(shù)，例如，RF前端和MAC主機處理器 的sRIO設(shè)備ID、可用的發(fā)射/接收天線的數(shù)目等。 統(tǒng)計 記錄-調(diào)試和診斷
在一個方面，CSM包含具有例如以下一個或多個功能的MAC接口 ·前導(dǎo)數(shù)據(jù)-在超級幀的開始發(fā)送· FLCS描述符_前向鏈路控制段描述符· FL DCH分配和MAC分組描述符
·加密掩碼生成_用于加密FL數(shù)據(jù)·解密請求_用于解密RL數(shù)據(jù)· FL Ack和RL分配請求· RL Ack和FL分配請求.R-DCH MAC 頭部.R-DCH 分配· R-CDCCH-RL CDMA控制信道MAC消息和定時信息· R-ODCCH-RL OFDMA 控制信道 MAC 消息· AT管理-從CSM中添加和刪除移動臺圖9示出了業(yè)務(wù)信道消息流的例子。圖10示出了前向鏈路(FL)數(shù)據(jù)流和加密掩 碼生成的例子。圖11示出了返回(又稱為反向)鏈路(RL)數(shù)據(jù)流和解密的例子。在一個方面，CSM采樣接口提供用于在CSM和射頻前端(RFFE)之間運送時域IQ 基帶采樣的協(xié)議。該協(xié)議還采用網(wǎng)絡(luò)定時參考和穩(wěn)健的差錯/丟失檢測來提供CSM同步。 RFFE通過全球定位衛(wèi)星(GPS)或一些其他機制來維護系統(tǒng)的全局同步，或者，系統(tǒng)可以采 用局限于單個基站的系統(tǒng)時間工作于異步模式。對于UMB同步操作，例如，空中鏈路幀結(jié)構(gòu) 是普遍對準(zhǔn)的并且回到GPS時間的開始進行參考。RFFE必須向CSM提供系統(tǒng)時間參考，使 得CSM可以采用正確的同步來生成底層幀結(jié)構(gòu)。該系統(tǒng)時間參考是自上一個系統(tǒng)時間秒以 來的采樣計數(shù)。采樣計數(shù)時間戳代表緊接著天線處參考的時間戳的采樣的絕對時間。圖12示出了接入點的示例性框圖。GPS接收機將GPS時間輸入到控制卡，控制卡 生成Chipxie時鐘和一秒脈沖給RFFE。RFFE使用這些時鐘來同步采樣時間戳，采樣時間戳 通過sRIO接口發(fā)送到CSM。在一個例子中，對于USB，根據(jù)底層物理層(PHY)結(jié)構(gòu)(循環(huán)前 綴(CP)大小和時分雙工(TDD)中的保護時間)，其幀結(jié)構(gòu)具有不同的重復(fù)速率并在不同尺 度上與秒對準(zhǔn)。因此，幀結(jié)構(gòu)對準(zhǔn)到秒的周期范圍是，例如，從7秒到2219秒。為了免除 RFFE理解PHY參數(shù)或GPS時間的細節(jié)的需要，RFFE僅需要提供從上次系統(tǒng)時間秒脈沖以后 的采樣數(shù)目的計數(shù)器。通過另一種機制將當(dāng)前的GPS或系統(tǒng)時間秒提供給CSM，比如來自控 制器的消息傳遞，其通過CSM應(yīng)用編程接口(API)進行定義。采用當(dāng)前系統(tǒng)時間秒和系統(tǒng) 時間秒內(nèi)的采樣計數(shù)的信息，CSM可以完整地得到系統(tǒng)的幀同步。為了保持差錯穩(wěn)健性，以固定的時間間隔將采樣計數(shù)器時間戳復(fù)用到去往RFFE 以及來自RFFE的采樣流。例如，對于IO-MHz帶寬UMB頻分雙工(FDD)模式，時間戳之間的 采樣段大小是1024次采樣，對于5-MHz帶寬UMB FDD模式，時間戳之間的采樣段大小是512 次采樣。在一個方面，CSM和RFFE使用串行高速IO(sRIO)接口針對前向和反向鏈路傳遞采 樣信息。通過RFFE發(fā)起的sRIO SffRITE, RFFE向CSM發(fā)送反向鏈路(RL)數(shù)據(jù)。通過CSM 發(fā)起的sRIO SffRITE,CSM向RFFE發(fā)送前向鏈路(FL)數(shù)據(jù)。在一個例子中，sRIO接口具有 以下的最小性能要求·在接口上使用64比特的數(shù)據(jù)字。
·每個天線至少2個最大長度的sRIO事務(wù)(256字節(jié))背對背以最大線速率 (IOGbps)是被接受的?！ぴ谛∮?個最大長度sRIO事務(wù)所代表的平均時間內(nèi)，寫設(shè)備不會向相同地址端 口寫入超過3個最大長度sRIO事務(wù)?！に械膕RIO事務(wù)都是依次交付的?！ひ院愣ǖ钠骄俾什捎煤愣ǖ钠骄訒r加抖動來生成來自RFFE的sRIO事務(wù)。 任意sRIO事務(wù)上引入的最大端到端抖動小于士64/采樣率。FL事務(wù)源于RL事 務(wù)，并可以在RL事務(wù)上再現(xiàn)抖動，因此，對于FL事務(wù)抖動容限是雙倍的。例如，對于IO-MHz 帶寬UMB FDD模式，抖動容限為■ < +6. 50微秒，對于RL數(shù)據(jù)和時間戳SWRITES ；■< +13. 0微秒，對于FL數(shù)據(jù)和時間戳SWRITES ；■ IQ數(shù)據(jù)使用全最大長度(256字節(jié))事務(wù)寫入，以最大化sRIO性能。在一個方面，CSM和天線之間的FL路徑延遲和RL路徑延遲被量化。需要該信息來 調(diào)整發(fā)送到CSM的RL時間戳。該調(diào)整允許CSM同步地對準(zhǔn)FL數(shù)據(jù)。在建立該同步之前， 無法傳遞有意義的FL數(shù)據(jù)。時間戳值代表天線處的采樣時間。RFFE必須通過適當(dāng)?shù)仄茣r間戳來解決天線及 其數(shù)字采樣之間的任何延遲。CSM支持對FL時間戳進行可編程提前以解決傳輸延遲、最大 抖動邊界和RFFE內(nèi)的延遲。在一個例子中，該提前小于200微秒。圖13示出了 FL和RL采樣接口的示例性表示。雖然FL和RL都通過一個sRIO接 口與CSM通信，但出于簡單性考慮，它們在圖13中被分開示出。圖13中的例子示出了從接 收天線通過模數(shù)轉(zhuǎn)換器(ADC)到CSM的總系統(tǒng)延遲，CSM通過數(shù)模轉(zhuǎn)換器(DAC)到發(fā)射天線 的延遲等于75毫秒。在這個例子中，75微秒代表CSM與FL和RL上的天線之間的總延遲， 它被用于對FL數(shù)據(jù)的提前定時進行編程，從而將其同步到系統(tǒng)時間秒。在一個方面，當(dāng)CSM從RL接收到時間戳，它在FL上添加針對該時間戳編程的提前 定時。這允許在發(fā)射天線上對FL采樣進行正確同步。在一個方面，采樣流格式具有例如以下一個或多個特征·時間戳計數(shù)器與系統(tǒng)時間秒對準(zhǔn)，使得將0計數(shù)作為一個時間戳值進行發(fā)送。 采樣流包括時間戳，該時間戳表明緊跟著的采樣的系統(tǒng)時間。該時間戳預(yù)期為恒 定的頻率；因此，時間戳之間的采樣數(shù)取決于采樣速率。例如，對于IOMHz帶寬UMB FDD模 式，每1024次采樣即寫入該時間戳?！τ谕降南到y(tǒng)操作，系統(tǒng)時間是GPS時間并與GPS秒對準(zhǔn)。 時間戳包括數(shù)據(jù)流所代表的當(dāng)前操作模式。這是僅用于一致性檢查的靜態(tài)配置。 將基于時間戳之間的采樣計數(shù)以及時間戳之間的定時測量來實現(xiàn)差錯/丟失檢測。在一個方面，表2示出了采樣計數(shù)時間戳格式。表3示出了 RL的采樣數(shù)據(jù)格式。 表4示出了 FL的采樣數(shù)據(jù)格式。表5示出了寄存器編址。表2 表3 表4 表 5 在一個方面，RF控制接口對于接收機增益以及對于TDD模式的發(fā)射和接收選通提 供實時控制。該控制接口被稱為實時的，是因為它提供了同步命令和數(shù)據(jù)的機制。在一個 方面，實時控制接口并非用于靜態(tài)配置，例如合成器及濾波設(shè)置或發(fā)射功率控制。在一個方 面，實時接口并非用于告警；告警必須在其他地方進行處理。增益和選通控制都是如表6所 示的通過對存儲器地址的SWRITE操作來進行的。表7示出了增益控制流的示例性格式。表6 表7 時間戳字段反映了增益變化生效所期望的時間。在一個例子中，RFFE改變增益 (基于增益信息rxGain)的實際時間在期望時間+/_2微秒內(nèi)。如果時間戳的最高有效位 (MSB)被設(shè)置，則RFFE將盡可能快的實現(xiàn)增益變化。CSM在期望時間的最少100微秒內(nèi)提 交增益改變。如果增益控制命令在以前的增益控制命令生效之前被提交，RFFE可以忽略以 前的命令。因此，對增益控制命令不需要緩沖機制。在期望的時間，RFFE調(diào)整其總接收增 益，使得輸入和輸出功率滿足下式rxGain =四舍五入((Pout-Pin)*2)(1)其中，Pin是在天線端口處RFFE對接收功率的估計(dBm)，Pout由下式給出Pout = IOlog (σ 2)(2)其中，ο2是IQ采樣的的平均平方數(shù)字值。因此，rxGain表示天線與到CSM的數(shù) 字RFFE輸出之間的期望增益(以0. 5dB步進)。在一個方面，采用加性高斯白噪聲(AWGN) 信號來進行校準(zhǔn)(calibration)，AWGN信號的帶寬覆蓋系統(tǒng)輸入帶寬。這確保了增益反映 出通帶上的平均增益。由于測量輸入功率在天線端口進行而不是在RFFE輸入處進行，RFFE 必須考慮LNA的所有外部增益和線纜損耗。如果RFFE按多個階段實施增益，則由RFFE決定增益分解。并且，RFFE可以在內(nèi) 部實施各種自動增益控制(AGC)。例如，AGC可以操作于濾波之前的某RF增益階段，以防止 由于信道外干擾造成的過載。但是，在一個方面，如果RFFE在一個階段改變了增益，它將試 圖保持從天線到CSM的總增益恒定。如果RFFE不能維持恒定的增益，它將向CSM報告該狀 況以及任何其他相關(guān)信息。在一個例子中，對于差錯容限，RFFE匹配平均增益是在不同的增益設(shè)置之間采用 +/-0.5dB的相對精度。差錯容限是指整個通帶上的平均增益。該接口并不規(guī)定rxGain值 的任何絕對精度。在該接口中也不規(guī)定其他參數(shù)(例如，標(biāo)稱絕對增益值和有效增益設(shè)置 范圍)，需要通過某些其他靜態(tài)配置將這些參數(shù)傳送給CSM。在另一個方面，Tx和Rx選通命令分別在表8和表9中給出。表8 表9 通過Rx增益控制命令，時間戳字段反映了命令生效的期望時間。在一個例子中， RFFE實施命令的實際時間在期望時間的+/-1微秒內(nèi)。如果設(shè)置了時間戳的最高有效位 (MSB)，RFFE就會盡快實施命令。在一個例子中，CSM在期望時間的最少100微秒(最多10 毫秒)內(nèi)提交命令。此外，任意兩個Rx選通控制命令的時間戳對應(yīng)于最少100微秒的時間 間隔。因此，由于可以最多提前10毫秒提交命令，RFFE需要緩沖最多100個命令。在Tx選通命令中，txEnable比特的值為〃 1 “表明啟用Tx。也就是說，與期望的 時間戳之后的采樣相對應(yīng)的數(shù)據(jù)從天線發(fā)送。相反，txEnable比特的值為"0"表明不發(fā) 送采樣。如果Tx路徑在多個階段實施，控制這些階段的順序和定時將被建立。類似地，在 Rx選通命令中，設(shè)置或不設(shè)置rxEnable比特將啟用或停用Rx路徑。如果Rx路徑在多個階 段實施，控制這些階段的順序和定時將被建立。發(fā)送時間戳和數(shù)據(jù)分組是獨立于是否啟用 Tx或Rx數(shù)據(jù)路徑的。圖14示出了采樣同步過程的示例性流程圖。在框1410中，接收來自射頻前端 (RFFE)的返回鏈路(也稱為反向鏈路)(RL)時間戳。在框1420中，接收來自導(dǎo)航和定時系 統(tǒng)的系統(tǒng)時間秒。在一個例子中，導(dǎo)航和定時系統(tǒng)可以是全球?qū)Ш叫l(wèi)星系統(tǒng)(GNSS)、全球定 位系統(tǒng)(GPS)、俄羅斯GL0NASS(全球?qū)Ш叫l(wèi)星系統(tǒng))、歐盟的伽利略定位系統(tǒng)、印度的區(qū)域 導(dǎo)航衛(wèi)星系統(tǒng)(IRNSS)、中國的北斗衛(wèi)星導(dǎo)航和定位系統(tǒng)等其中之一。雖然圖中給出的框 1410中的步驟發(fā)生在框1420的步驟之前，本領(lǐng)域的技術(shù)人員應(yīng)該理解，在不影響本公開的 保護范圍和精神的情況下，框1410中的步驟和框1420中的步驟在時間順序上可以相互交 換，或者，可同時發(fā)生?？?420之后，在框1430，基于RL時間戳和系統(tǒng)時間秒生成前向鏈路(FL)時間戳。 在一個方面，基于RL時間戳和系統(tǒng)時間秒來調(diào)整FL時間戳?？?430之后，在框1440中，
21將FL時間戳和系統(tǒng)時間秒包括到時間數(shù)據(jù)中?？?440之后，在框1450中，將時間數(shù)據(jù)復(fù) 用到采樣流中。在一個方面，接收RL時間戳和系統(tǒng)時間秒的實體是區(qū)站調(diào)制解調(diào)器(CSM)。 在一個例子中，CSM是圖12所示的接入點框圖的一部分。圖15示出了適合采樣同步的設(shè)備1500的例子。在一個方面，設(shè)備1500由至少一 個處理器實現(xiàn)，處理器包括如本文在框1510、1520、1530、1540和1550所描述的配置為提供 采樣同步的不同方面的一個或多個模塊。。例如，每個模塊包括硬件、固件、軟件或其任意組 合。在一個方面，設(shè)備1500還可以由與至少一個處理器進行通信的至少一個存儲器來實 現(xiàn)。圖16示出了 RF控制的示例流程圖。在框1610中，接收增益信息和選通控制信息。 在框1620中，將增益信息和選通控制信息存儲到存儲器。在一個方面，表6中給出的參數(shù) 被用于框1620中的步驟?？?620之后，在框1630中，發(fā)送第一期望時間戳和增益信息到 射頻前端(RFFE)。在一個方面，第一期望時間戳反映了增益變化起作用的期望時間。在一 個例子中，表7中給出的參數(shù)被用于框1630中的步驟。在一個方面，RFFE使用增益來調(diào)整 其增益設(shè)置。框1630之后，在框1640中，發(fā)送第二期望時間戳和txEnable命令到發(fā)送選通控 制器。第二期望時間戳反映了 txEnable命令生效的期望時間。當(dāng)被執(zhí)行時，txEnable命 令啟用發(fā)送(Tx)路徑。在一個例子中，表8中給出的參數(shù)被用于框1640中的步驟。在一 個例子中，發(fā)送選通控制器是RFFE的部件。框1640之后，在框1650中，發(fā)送第三期望時間戳和rxEnable命令到接收選通控 制器。第三期望時間戳反映了 rxEnable命令生效的期望時間。當(dāng)被執(zhí)行時，rxEnable命 令啟用接收(Rx)路徑。在一個例子中，表9中給出的參數(shù)被用于框1650中的步驟。在一 個例子中，接收選通控制器是RFFE的部件。在一個方面，執(zhí)行圖16中示例流程圖的步驟的實體是區(qū)站調(diào)制解調(diào)器(CSM)。在 一個例子中，CSM是圖12示出接入點框圖中的一部分。在一個方面，獨立地發(fā)送第一期望時 間戳、第二期望時間戳、第三期望時間戳中的每一個。此外，本領(lǐng)域的技術(shù)人員應(yīng)當(dāng)理解，雖 然圖16中示例流程圖給出的是框1630、框1640和框1650的步驟的順序流，本領(lǐng)域的技術(shù) 人員應(yīng)當(dāng)理解，在不影響本發(fā)明的保護范圍和精神的前提下，不同順序的序列也是可能的。 類似地，第一期望時間戳、第二期望時間戳、第三期望時間戳中的每一個也可能在沒有其他 二者的情況下被發(fā)送，不論是否啟用發(fā)送(tx)路徑或接收(rx)路徑。圖17示出了適合RF控制的設(shè)備1700的例子。在一個方面，由至少一個處理器來 實現(xiàn)設(shè)備1700，處理器包括配置為提供在此描述的框1710、1720、1730、1740和1750的不同 方面的RF控制的一個或多個模塊。例如，每個模塊包括硬件、固件、軟件或其任意組合。在 一個方面，由與至少一個處理器進行通信的至少一個存儲器來實現(xiàn)設(shè)備1700。本領(lǐng)域的技術(shù)人員應(yīng)該理解，圖14和圖16的示例流程圖中給出的步驟，在不偏離 本發(fā)明的保護范圍和精神的前提下，其順序可以互換。本領(lǐng)域的技術(shù)人員應(yīng)該理解，上述流 程圖中給出的步驟不是排他的，在不偏離本發(fā)明的保護范圍和精神的前提下，可以加入其 他步驟，也可以刪除示例流程圖中的一個或多個步驟。技術(shù)人員應(yīng)該更進一步意識到，本文中結(jié)合本文公開的例子描述的各種說明性的 組件、邏輯塊、模塊、電路和/或算法步驟，可以實現(xiàn)為電路硬件、固件、計算機軟件或其組合。為了清楚地說明硬件、固件和軟件的這種互換性，上文中提到的各種說明性的組件、塊、 模塊、電路和/或算法步驟，一般都是對其功能進行描述的。該功能是否實現(xiàn)為硬件、固件 或軟件，依賴于整個系統(tǒng)的特定應(yīng)用場景和施加到整個系統(tǒng)的設(shè)計約束。對每一個特定應(yīng) 用，熟練的技術(shù)人員可以以各種方式實現(xiàn)本文中描述的功能，但是這種實現(xiàn)決策不應(yīng)當(dāng)理 解為造成對本公開的保護范圍或精神的偏離。例如，對于硬件實現(xiàn)，處理單元可以在一個或多個專用集成電路(ASIC)、數(shù)字信號 處理器(DSP)、數(shù)字信號處理設(shè)備(DSPD)、可編程邏輯器件(PLD)、現(xiàn)場可編程門陣列、處理 器、控制器、微控制器、微處理器、設(shè)計為能實現(xiàn)這里描述的功能的其他電子單元，或其組合 中實現(xiàn)。對于軟件實現(xiàn)，可以通過執(zhí)行這里描述的功能的模塊(例如，過程、函數(shù)等)來實 現(xiàn)。軟件代碼可以存儲在存儲器單元并由處理器單元執(zhí)行。此外，文中提到的各種說明性 的流程圖、邏輯塊、模塊和/或算法步驟可以編碼為計算機可讀指令，其由本領(lǐng)域已知的任 何計算機可讀介質(zhì)運送或由本領(lǐng)域已知的任何計算機程序產(chǎn)品實現(xiàn)。在一個例子中，本文中提到的各種說明性的組件、流程圖、邏輯塊、模塊、電路和/ 或算法步驟由一個或多個處理器實現(xiàn)或執(zhí)行。在一個方面，處理器耦合到存儲器，存儲器存 儲將由處理器執(zhí)行的數(shù)據(jù)、元數(shù)據(jù)、程序指令等，以便實現(xiàn)或執(zhí)行文中提到的各種流程圖、 邏輯塊和/或模塊。圖18示出了由處理器1810及與其通信的存儲器1820組成的設(shè)備1800。 在一個例子中，設(shè)備1800用于實現(xiàn)圖14說明的算法。在一個例子中，設(shè)備1800用于實現(xiàn) 圖16說明的算法。在一個方面，存儲器1820位于處理器1810內(nèi)部。在另一個方面，存儲 器1820在處理器1810外部。在一個方面，該處理器包括實現(xiàn)或執(zhí)行本文中提到的各種流 程圖、邏輯塊和/或模塊的電路。前述說明的各個方面提供給任何本領(lǐng)域的技術(shù)人員以制造或使用本發(fā)明。對本領(lǐng) 域的技術(shù)人員，顯而易見，可以對這些方面進行各種修改，在不偏離本發(fā)明的保護范圍和精 神的前提下，這里定義的一般原則可以適用于其他方面。附錄 A 目錄1.引言............................................................311.1 目的...........................................................311· 2 范圍...........................................................311. 3 慣例...........................................................311.4修訂歷史.......................................................311.5 參考...........................................................311. 6技術(shù)支持.......................................................331.7 縮略語.........................................................332.系統(tǒng)架構(gòu)及概述..................................................34
2. 1架構(gòu)...........................................................34
2. 1. IUMB網(wǎng)絡(luò)架構(gòu)..................................................34
2. 1. 2UMB AP參考設(shè)計硬件架構(gòu)........................................36
2. 1. 2. 1第 1 階段....................................................36
2. 1. 2. 2 第 2 階段....................................................36
2. 1.3被許可方提供的功能...........................................37
2. 1. 3. 1回程及回程處理.............................................37
2. 1. 3. 2BHQoS.......................................................37
2. 1. 3. 30AM&P 基礎(chǔ)結(jié)構(gòu)..............................................37
2. 1.3.4診斷和調(diào)試記錄.............................................38
2. 1. 3. 5VLAN 使用...................................................38
2. 1. 3. 6網(wǎng)絡(luò)時間協(xié)議以及GPS時間同步................................38
2. 1. 4UMB參考設(shè)計軟件架構(gòu)..........................................38
2. 1.4. 1高通消息傳遞...............................................39
2. 1.4. 2UMB協(xié)議棧軟件架構(gòu)..........................................49
2. 1. 4. 3信令流中的協(xié)議標(biāo)記.........................................52
2. 1. 4. 40AM&P 架構(gòu)..................................................53
2. 1. 4. 5UMB L3M 軟件架構(gòu).............................................62
2. 1. 4. 6 啟動.......................................................67
2. 2系統(tǒng)接口.......................................................69
2. 2. 1空中接口.....................................................69
2. 2. 1. IUMB L2M 軟件架構(gòu).............................................69
2. 2. 2被許可方接口.................................................72
2. 2. 2. IUMB API.....................................................72
2.2. 2. 2CSM API.....................................................72
3.UMB API..........................................................72
3. 1概述...........................................................72
3. 2管理面.........................................................73
3. 2. IUMB消息路由..................................................73
3. 2. 2 控制.........................................................73
3. 2. 3鏡像下載.....................................................73
3. 2. 4配置和統(tǒng)計...................................................73
3. 2. 4. 1硬件/軟件組件配置..........................................73
3. 2. 5 記錄.........................................................73
3. 2. 5. 1調(diào)試記錄...................................................73
3. 2. 5. 2診斷記錄...................................................73
3. 2. 5. 3外部記錄...................................................73
3. 2. 6 故障.........................................................73
25
3. 3 數(shù)據(jù)面.........................................................743. 3. 1 分組流程.....................................................743. 3. 1. IFL 分組處理.................................................743. 3. 1. 2RL 分組處理.................................................743. 3. 1. 3用于切換的RLP分組轉(zhuǎn)發(fā)......................................753. 3. 2 配置.........................................................753.3.2.1L3M 功能....................................................753.3.2.2L2M 功能....................................................753. 3. 2. 3FMM/CMM 功能................................................753. 4 控制面.........................................................763.4.1不透明UMB協(xié)議消息............................................763. 4. 2AT 管理.......................................................763. 4. 3AT 隧道管理...................................................763. 4. 4空中鏈路QoS管理..............................................763. 4. 5 記賬管理.....................................................763. 4. 6RLP認證/加密密鑰管理.........................................763. 4. 7 第二層 AT 管理.................................................764.操作............................................................764. 1 概述...........................................................764. 2 管理...........................................................774. 2.1啟動和初始化.................................................774. 2. 2配置和統(tǒng)計獲取...............................................784. 3 數(shù)據(jù)面.........................................................784. 3. IFL 分組處理...................................................784. 3. 1. IDAP 與 FLSS 在相同位置........................................784. 3. 1. 2DAP 與 FLSS 在不同 AP 上.......................................784. 3. 2RL 分組處理...................................................79 4. 3. 2. IRLSS 使用 DAP 向 AGW 發(fā)送......................................794. 3. 2. 2RLSS 直接向 AGW 發(fā)送..........................................794. 4 控制面.........................................................794. 4.1 上電.........................................................794. 4. 1. 1 使用 EAP 認證上電............................................794. 4. 1. 2 使用 MIP_FAv4 上電...........................................824. 4. 2 切換.........................................................834. 4. 2. 1相同AGW服務(wù)的AP之間的切換.................................834. 4. 2. 2不同AGW服務(wù)的AP之間的切換.................................874. 4. 3 睡眠.........................................................884. 4. 3. 1清除連接關(guān)閉...............................................884. 4. 3. 2 連接丟失...................................................89
4. 4. 4 位置跟蹤.....................................................904. 4. 4. 1成功的位置跟蹤更新.........................................904. 4. 4. 2失敗的位置跟蹤更新.........................................904. 4. 5 尋呼.........................................................904. 4. 5. 1本地尋呼喚醒...............................................904. 4. 5. 2遠程尋呼喚醒...............................................914. 4. 5. 3 失敗的尋呼.................................................914. 4. 6 動態(tài) QoS......................................................924. 4. 6. 1 成功的 QoS 協(xié)商..............................................924. 4. 6. 2 失敗的 QoS 協(xié)商..............................................92圖目錄圖2-1UMB架構(gòu)參考模型..............................................34圖2-2UMB邏輯網(wǎng)絡(luò)架構(gòu)..............................................35圖2-3示出了第1階段UMB AP參考設(shè)計架構(gòu)............................36圖2-3第1階段UMB AP參考設(shè)計架構(gòu)圖................................36圖2-4示出了第2階段UMB AP參考設(shè)計架構(gòu)............................36圖2-4第2階段UMB AP參考設(shè)計架構(gòu)圖................................36圖2-5UMB協(xié)議分布..................................................39圖2-6UNIX消息傳遞架構(gòu).............................................41圖2-7基于RTOS的消息傳遞架構(gòu)......................................42圖 2-8DB GET 消息流.................................................54圖 2_9TYPE_DB_GETKEYS 消息流........................................55圖 2_10TYPE_DB_N0TIFY 消息流........................................56圖 2-11DB_REGISTER 消息流...........................................57圖 2_12DB_SET 消息流................................................58圖2-13批量數(shù)據(jù)獲取消息流..........................................60圖2-14診斷和調(diào)試記錄架構(gòu)..........................................61圖2-15L3M高層軟件架構(gòu).............................................63圖2-16L3M/L2M啟動消息流-第一部分.................................68圖2-17L3M/L2M啟動消息流-第二部分.................................69圖 2-18L2M FL 架構(gòu)..................................................70圖 2-19L2M RL 架構(gòu)..................................................70圖3-1數(shù)據(jù)分組頭部.................................................74圖4-1啟動和初始化——第一部分.....................................77圖4-2啟動和初始化——第二部分.....................................78圖4-3上電-第一頁.................................................79圖4-4上電-第二頁.................................................80圖4-5上電-第三頁.................................................81圖4-6上電-第四頁.................................................82
圖 4-7L2+L3 切換-新 BSE-第一頁.....................................83圖 4-8L2+L3 切換-新 BSE-第二頁.....................................84圖 4-9L2+L3 切換-新 BSE-第三頁.....................................85圖 4-10L2+L3 切換-原 BSE-第一頁....................................86圖 4-11L2+L3 切換-原 BSE-第二頁....................................87圖4-12睡眠-優(yōu)雅關(guān)閉..............................................88圖4-13睡眠-連接丟失..............................................89圖4-14位置跟蹤....................................................90圖4-15遠程尋呼喚醒................................................91圖 4-16QMP 協(xié)商的 QoS................................................92表目錄表1. 1修訂歷史.....................................................31表1. 2參考文檔和標(biāo)準(zhǔn)...............................................31表2. IUMB架構(gòu)參考模型功能單元......................................34表2.2QMessage通用頭部字段.........................................43表2. 3QMessage心跳消息字段.........................................45表2. 4以太網(wǎng)MAC-48布局字段........................................48表2. 5TTLV 布局字段.................................................49表2. 6協(xié)議縮寫.....................................................52表2. 7SNP協(xié)議類型、協(xié)議號和應(yīng)用程序端口.............................52表2. 8工作組編號方案...............................................661.引言1.1 目的本文描述高通公司 和其他公司在3GPP2主持下設(shè)計的UMB API架構(gòu)。本文描述 UMBAPI的所有方面以及硬件和軟件架構(gòu)，包括調(diào)用流程。1. 2 范圍本文的撰寫是為了被許可方理解怎樣使用UMB API構(gòu)建商用AP系統(tǒng)。假設(shè)讀者 熟悉OFDM技術(shù)、CDMA技術(shù)以及已被3GPP2標(biāo)準(zhǔn)化的UMB協(xié)議。本文檔覆蓋高通公司提供 的參考設(shè)計的硬件/軟件架構(gòu)以及消息流圖和消息定義。1. 3 慣例函數(shù)聲明、函數(shù)名、類型聲明和代碼示例以不同的字體給出，例如， include.1. 4修訂歷史本文檔的修訂歷史如表1. 1所示。表1. 1修訂歷史
版本日期說明A2007年4月初始版本 1. 5 參考
28
參考文檔，可能包括高通、標(biāo)準(zhǔn)和資源文檔，在表1. 2中給出。不再適用的參考文 檔從該表中刪除；因此，參考編號可能不是按順序的。表1. 2參考文檔和標(biāo)準(zhǔn) 1. 6技術(shù)支持若需要幫助或澄清本文中的信息，請通過如下鏈接提交服務(wù)請求到高通CMDA技 術(shù)http//support, cdmatecch. com若不能 Web 訪問互聯(lián)網(wǎng)，也可發(fā)送 email 至l| support, cdmatechigualcomm. com.1. 7縮略語術(shù)語及縮略語的定義，參考[Ql].2.系統(tǒng)架構(gòu)及概述2. 1 架構(gòu)本章提供總體UMB網(wǎng)絡(luò)和UMB接入點(AP)的系統(tǒng)架構(gòu)概述。2. 1. IUMB 網(wǎng)絡(luò)架構(gòu)圖2-1示出了 UMB網(wǎng)絡(luò)的架構(gòu)參考模型。該參考模型包括接入終端(AT)和接入 網(wǎng)(AN)之間的空中接口。
圖2-1U MB架構(gòu)參考模型
表2. 1說明了在圖2-1中給出的架構(gòu)參考模型的功能單元。表2. IUMB架構(gòu)參考模型功能單元 圖2-2示出了 UMB系統(tǒng)中各種元件和核心網(wǎng)元件之間的關(guān)系< 圖2-2UMB邏輯網(wǎng)絡(luò)架構(gòu)2. 1. 2UMB AP參考設(shè)計硬件架構(gòu)2. 1. 2. 1 第 1 階段圖2-3示出了第1階段UMBAP參考設(shè)計架構(gòu)
圖2-3第1階段UMBAP參考設(shè)計架構(gòu)圖2. 1. 2. 2第2階段圖2-4示出了第2階段UMB AP參考設(shè)計架構(gòu) 圖2-4第2階段UMBAP參考設(shè)計架構(gòu)圖2. 1. 3被許可方提供的功能被許可方提供的功能是指為了構(gòu)建可用系統(tǒng)，被許可方AP軟件必須提供的所有 功能。這里假設(shè)，參考系統(tǒng)和平臺中運行的CPM以及UMB協(xié)議棧軟件一同被交付，被許可方 必須在最終系統(tǒng)中提供這一軟件。本節(jié)假設(shè)被許可方僅使用L3M/L2M/FMM/CMM模塊。2. 1. 3. 1回程及回程處理這里假設(shè)被許可方需要提供以下功能 到核心網(wǎng)的回程接口 任何需要的防火墻 被許可方特有的網(wǎng)絡(luò)/端口地址轉(zhuǎn)換 具有以下功能的IP中轉(zhuǎn)■中轉(zhuǎn)所有非隧道流量到CPM IP棧
■在單一 L3M系統(tǒng)中，中轉(zhuǎn)所有的GRE和/或L2TPv3流量到L3M的吉比特 (gigabit)以太網(wǎng)接口。■在多L3M系統(tǒng)中，使用非基于IP的中轉(zhuǎn)表來決定對某個特定的數(shù)據(jù)應(yīng)該定向到 哪個L3M2. 1. 3. 2BHQoS在回程聚合能力小于空中接口 RL可能的速率時，在回程接口上使用QoS方法可能 是必要的。L3M將被限制到每個AT、每個流的RL策略，并對流進行DSCP標(biāo)記處理，在L3M 和被許可方提供的以太網(wǎng)之間離開RL。但是，即使采用RL策略，也可能出現(xiàn)所有AT上的聚 合速率超過回程接口能力的情況，因此，回程服務(wù)質(zhì)量(BHQoS)是必要的。如果回程接口相 對于AN的最大RL速率來說過大，那么不要求使用BHQoS。2. 1. 3. 30AM&P 基礎(chǔ)結(jié)構(gòu)假設(shè)，當(dāng)UMB AP參考設(shè)計被集成到被許可方的平臺上時，被許可方會處理整個操 作管理維護和配置(0ΑΜ&Ρ)子系統(tǒng)。這包括以下功能 管理客戶端，例如，CLI和SNMP，以及中間件 對 GET/SET 等命令適配 UMB API 到 / 從 FMM/CMM，L2M 以及 L3M 數(shù)據(jù)庫持久存儲 系統(tǒng)開機和初始化· CPM, L2M 和 L3M 的 OS 集成 系統(tǒng)互聯(lián)拓撲(SRI0，以太網(wǎng))· AMCIPMI 接 口 鏡像服務(wù)器(用于下載代碼到FMM/CMM，L2M和L3M的示例程序) 消息傳遞IPC2. 1.3.4診斷和調(diào)試記錄假設(shè)被許可方會從UMB模塊提供接收調(diào)試/診斷記錄流的方法，并將其聚合到系 統(tǒng)之外。這兩種流內(nèi)運行的協(xié)議仍在制定中。2. 1. 3. 5VLAN 使用UMB參考設(shè)計軟件要求使用802. 3pq的以下功能· VLAN 4080將用于L3M和被許可方以太網(wǎng)之間的所有控制流量· VLAN 4081將用于L3M和被許可方以太網(wǎng)之間的所有IP流量· VLAN 4082將用于L3M和L2M之間的所有流量·以下優(yōu)先級將會被使用 優(yōu)先級0-盡力交付，系統(tǒng)記錄 優(yōu)先級3-信令 優(yōu)先級7-心跳2. 1. 3. 6網(wǎng)絡(luò)時間協(xié)議以及GPS時間同步UMB參考設(shè)計軟件假設(shè)，被許可方AP能夠終止和潛在地分發(fā)NTP時間到UMB軟件 組件中。這使得所有的網(wǎng)絡(luò)協(xié)議調(diào)試使用相同的參考時鐘。此外還假設(shè)GPS時間同步能被 分發(fā)到FMM/CMM模塊。2. 1. 4UMB參考設(shè)計軟件架構(gòu)
UMB設(shè)計包括許多空中接口協(xié)議和許多IP層協(xié)議。這些協(xié)議分布在不同的模塊 中，如圖2-5所示。 圖2-5UMB協(xié)議分布2. 1.4. 1高通消息傳遞2. 1.4. 1. 1 軟件背板為了能在分布式系統(tǒng)中正常工作，軟件必須能夠準(zhǔn)確無縫地和系統(tǒng)中的其他模塊通信，不論其在系統(tǒng)拓撲中的位置。此外，所有軟件組件能夠邏輯地可尋址，以便軟件拓撲 的改變能最小化或被消除。這一能力使得能夠隱藏分布式系統(tǒng)的拓撲，也能實現(xiàn)軟件模塊 之間的故障轉(zhuǎn)移。為了實現(xiàn)這些能力，高通已開發(fā)出可部署分布式系統(tǒng)的軟件背板。這個 背板將被用于構(gòu)建UMB/CSM API。2. 1.4. 1.2軟件背板需求軟件背板必須滿足以下需求 位置透明性_軟件組件不必知道另一個軟件組件的物理位置就能通信。 名字解析_消息傳遞系統(tǒng)應(yīng)該提供模塊將邏輯名稱解析為物理地址。 多播-消息傳遞系統(tǒng)能夠提供模塊來將消息多播到多個接收者。發(fā)送方不必知 道接收者是誰。多播消息應(yīng)該能夠被確認或非確認。已確認的多播消息應(yīng)當(dāng)生成單個確認消息給發(fā)送方。 協(xié)議消息_消息傳遞系統(tǒng)應(yīng)該提供模塊在任意兩個軟件組件之間直接發(fā)送消 息。這些消息應(yīng)該能夠被確認或者非確認。 別名-消息傳遞系統(tǒng)應(yīng)該允許單個組件為其邏輯名稱注冊一組別名，其都映射 到其真實名稱。2. 1.4. 1.3消息傳遞架構(gòu)消息傳遞軟件架構(gòu)將由消息傳遞服務(wù)器(主機)和一組相關(guān)聯(lián)的消息傳遞實例 (客戶端)組成。除了通常的消息傳遞實例功能，消息傳遞服務(wù)器的特殊之處在于其執(zhí)行以 下功能 發(fā)送HB廣播 識別并允許新的消息傳遞客戶端進入系統(tǒng) 管理邏輯名稱和多播注冊表的主復(fù)制 發(fā)出多播以保持客戶端/從屬消息傳遞實例同步通過以下方式修改主機中的表本地接口操作、ioctl、經(jīng)由消息隊列命令以及來 自客戶端/從屬實例的遠程請求。當(dāng)邏輯名稱解析到已知的軟件組件時，每個消息傳遞實例完全能夠本地地或遠程 地傳遞消息，而不需要聯(lián)系服務(wù)器。發(fā)送到未知邏輯名稱的消息將會失敗，不能被正確地發(fā) 送。在這種情況下的錯誤恢復(fù)已超出消息傳遞系統(tǒng)的范疇。每個消息傳遞實例具有提供消息組件注冊到系統(tǒng)中，并接收系統(tǒng)中的任意多播事 件的能力。當(dāng)多播注冊/解除注冊發(fā)生時，都會通過廣播消息通知每個消息傳遞實例。這 種更新消息傳遞數(shù)據(jù)結(jié)構(gòu)使得如果接收到多播事件，消息傳遞實例知道怎樣在系統(tǒng)內(nèi)廣播 該消息。圖2-6示出了 UNIX@消息傳遞架構(gòu) 圖2-6UNIX消息傳遞架構(gòu)圖2-7示出了基于RTOS的消息傳遞架構(gòu)
圖2-7基于RTOS的消息傳遞架構(gòu)
2. 1. 4. 1. 4QMessage 通用頭部
所有在組件間交互的消息使用以下的通用頭部 表2. 2描述QMessage通用頭部字段表2. 2QMessage通用頭部字段 2. 1.4. 1.5 拓撲發(fā)現(xiàn)消息傳遞系統(tǒng)由服務(wù)器和一組潛在的關(guān)聯(lián)消息傳遞實例構(gòu)成。為了系統(tǒng)能有效的 操作，需要消息傳遞服務(wù)器能發(fā)現(xiàn)其他消息傳遞實例的模塊。這可以由消息傳遞服務(wù)器在 初始化完成之后，每一秒發(fā)送心跳消息來實現(xiàn)。通過VLAN4080上的廣播MAC地址發(fā)送心跳。所有已注冊的消息傳遞實例必須響 應(yīng)該消息。任何新的消息傳遞實例可以使用此消息來學(xué)習(xí)應(yīng)向誰發(fā)回響應(yīng)。從不發(fā)送心跳 響應(yīng)到廣播地址，并且必須包含唯一的單播以太網(wǎng)MAC地址。這個新的MAC地址會被服務(wù) 器學(xué)習(xí)到，可以使用SRC MAC地址跟蹤該消息傳遞實例消耗的所有資源。連續(xù)3個請求的 心跳消息響應(yīng)失敗，會導(dǎo)致服務(wù)器刪除該消息傳遞實例，其所有資源被釋放，并發(fā)送多播消 息以通知系統(tǒng)中的其余部分。一旦新的實例響應(yīng)心跳，它還發(fā)送消息以獲取完整的邏輯名字緩存以及多播注冊 表。此外，消息傳遞代碼使用nodelD，即，1字節(jié)值，在內(nèi)部以及內(nèi)部的“消息傳遞”所支持的 協(xié)議中作為48位以太網(wǎng)地址的替代。顯而易見的是，沒有兩個實例可以有相同的nodelD。 在心跳消息中分發(fā)nodelD-以太網(wǎng)映射表。2. 1. 4. 1. 6QMessage 心跳消息心跳消息的特殊在于，它的源和宿都是消息傳遞子系統(tǒng)。它還是維持消息，因而與 其他消息具有不同的格式，如下所示 表2. 3描述了 QMessage心跳消息字段。表2. 3QMessage心跳消息字段 2. 1. 4. 1. 7 邏輯尋址所有的邏輯地址都應(yīng)當(dāng)是基于字符串的名字，類似TCP/IP中的主機名。所有的邏 輯地址都應(yīng)當(dāng)以字符串qmsg://開頭。消息傳遞層包括解析這些邏輯名稱到物理地址的功 能。這減少了應(yīng)用程序?qū)W習(xí)/硬編碼系統(tǒng)服務(wù)所在的物理MAC地址的需要。所有的基于字符串的名稱都解析為以太網(wǎng)硬件地址。注意，這種綁定能夠動態(tài)的 支持進程重啟、獲取新的/不同的動態(tài)端口，也使得應(yīng)用程序移去冗余、負載均衡等。每個 邏輯名稱必須是對所有的物理地址唯一的。如果服務(wù)/應(yīng)用程序在每個網(wǎng)卡上存在，但是 又必須可唯一尋址的，那么需要在邏輯基本名稱后面添加實例號，例如foreignAgent-1， foreignAgent-2等，該實例號與物理地址(例如插槽號)無關(guān)。端口號用于在以太網(wǎng)地址外解復(fù)用消息到軟件組件。換一種說法，以太網(wǎng)地址足 夠?qū)ぶ芬越桓斗纸M到正確的硬件上。但是，若沒有端口號，該分組就可能不能被交付到正確 的軟件組件。端口地址被細分為以下范圍· 0. . 31消息傳遞子系統(tǒng)內(nèi)部使用；對于任何應(yīng)用程序都不可用· 31.. 253單播動態(tài)分配端口· 254無效端口號· 255廣播端口號動態(tài)端口空間只在給定的消息傳遞實例上是唯一的。每個消息傳遞實例必須維護 動態(tài)分配端口的表。2. 1. 4. 1. 8位置透明與名字解析2. 1.4. 1.8. 1消息傳遞資源位置緩存本模塊包含了在CPM上的資源位置主機所知的、邏輯名稱到物理地址映射的緩 存。它由消息傳遞kmod通過老化已存在的條目來按需更新。更新基于卡下降、其他刀片上 分配/回收端口以及其他事件。從服務(wù)器到客戶端的更新通過VLAN4080上的以太網(wǎng)廣播 完成。從客戶端到服務(wù)器的更新通過消息傳遞模塊向資源位置主機發(fā)送單播消息完成。2. 1. 4. 1. 8. 2消息傳遞資源位置服務(wù)器該服務(wù)器運行在CPM上，為CPM轉(zhuǎn)換邏輯名稱到物理名稱，還通過VLAN4080上的 以太網(wǎng)廣播將當(dāng)前緩存更新發(fā)送到系統(tǒng)中的所有刀片。每個邏輯名稱由系統(tǒng)中的任何消息傳遞實例的客戶端來創(chuàng)建。名稱服務(wù)器緩存的管理基本是通過心跳響應(yīng)失敗自動完成。還存在這樣的接口， 它允許清除特定實例的資源。2. 1.4. 1.9 消息類型2. 1. 4. 1. 9. 1 多播消息確認/非確認的多播消息都是接收方不感知的。消息發(fā)送方不知道也不關(guān)心誰是 該消息的接收方。發(fā)送方唯一希望知道的是，系統(tǒng)中已注冊的軟件組件什么時候處理該消
42息。這是通過單個確認消息實現(xiàn)的，其中該確認消息由消息傳遞系統(tǒng)在其為確認消息分配 適當(dāng)?shù)男蛱柡蠡厮椭猎⒌陌l(fā)送方。這種類型的消息必須總是由客戶端注冊并由所有的 接收方確認。對接收已注冊的多播消息的確認失敗會導(dǎo)致FAILURE消息被回送至發(fā)送方。2. 1.4. 1.9. 2 協(xié)議消息協(xié)議消息(也稱為點到點消息)是接收方感知的。特別地，發(fā)送方必須知道該消 息將要被送到的邏輯地址。消息傳遞系統(tǒng)同時支持單播和多播協(xié)議消息。不像多播消息， 這些協(xié)議消息并不注冊到消息傳遞系統(tǒng)中。這種類型的消息將采用不同的通信頭部結(jié)構(gòu)， 在該結(jié)構(gòu)中，發(fā)送方將包括發(fā)送到接收方的邏輯名稱和協(xié)議消息類型。接收方的消息傳遞 層將交付該消息到目的端口，并只需知道該消息是否要求回送確認給發(fā)送方。這些確認需 要由消息傳遞層使用cookie進行在途處理，例如跟蹤進行中的確認的序列號。2. 1. 4. 1. 10以太網(wǎng)地址分配所有基于以太網(wǎng)的系統(tǒng)都要求每個MAC包含在第二層網(wǎng)絡(luò)唯一的MAC地址。系統(tǒng) 允許使用從被許可方的IEEE組織唯一標(biāo)識符(OUI)空間分配的、全局唯一的MAC地址，或 者是生成的僅在系統(tǒng)內(nèi)唯一的MAC-48地址。這并不適用于作為回程網(wǎng)絡(luò)一部分的以太網(wǎng) MAC。那些以太網(wǎng)地址需要是IEEE全局唯一的地址。本節(jié)討論用于創(chuàng)建系統(tǒng)唯一 MAC-48 地址的算法。MAC-48地址算法必須符合以下要求 有辦法保證任何被許可方系統(tǒng)內(nèi)的唯一性，其中提出參考設(shè)計模塊 支持一個CPU服務(wù)于多個以太網(wǎng)MAC的模塊 支持具有多個CPU和以太網(wǎng)MAC的模塊本參考設(shè)計假設(shè)被許可方將會從TBD地址提供8位寄存器可讀，其提供機架內(nèi)唯
的地理位置。
Geo. Location1字節(jié)系統(tǒng)內(nèi)唯一的編號；不對該字段的內(nèi)容做任何假設(shè)；由被許可方 來確保該編號在建立的系統(tǒng)內(nèi)是真正唯一的；否則將會導(dǎo)致消息 傳遞系統(tǒng)及相關(guān)軟件模塊不能正常工作。Spare8位由發(fā)送方設(shè)置為0，被接收方忽略2. 1.4. 1. 11通用消息傳遞類型許多消息都定義為具有固定部分和可變部分?？勺儾糠滞ǔ０ǚQ為TTLV的結(jié) 構(gòu)。本節(jié)描述TTLV結(jié)構(gòu)。
2. 1.4. 2UMB協(xié)議棧軟件架構(gòu)2. 1. 4. 2. IUMB協(xié)議棧高層要求CPM UMB協(xié)議棧實現(xiàn)為支持以下需要 結(jié)構(gòu)化該軟件使得移植到各種CPU和OS易于實現(xiàn)。 允許進行廣泛測試，例如，回環(huán)、芯片組仿真、移動電話仿真、信令測試等。 如果需要的話，允許被許可方利用我們的基礎(chǔ)結(jié)構(gòu)來添加他們的應(yīng)用程序；如 果被許可方選擇不使用我們的基礎(chǔ)結(jié)構(gòu)，允許我們的基礎(chǔ)結(jié)構(gòu)與他們的基礎(chǔ)結(jié)構(gòu)和平共 存。 定義UMB API,以便供應(yīng)商在沒有我們的信令協(xié)議棧但是具有我們的CPM協(xié)議 棧的子集的情況下能夠建立API，以便能和UMB硬件模塊(CSM硬件初始化、鏡像下載等)對接。2. 1.4. 2. 2UMB 協(xié)議棧進程注意，進程是根據(jù)部署的OS的不精確的術(shù)語。在一些操作系統(tǒng)中，它們可能是真 實的進程，但是在其他操作系統(tǒng)中，它們可能是共享公共內(nèi)存空間的任務(wù)或線程。2. 1. 4. 2. 30AM 進程2. 1. 4. 2. 3. IIxmControl此進程，使用UMB API，用于初始化、心跳和控制L2M/L3M參考設(shè)計模塊的狀態(tài)。它 還將Qmessaging路由器表饋送到L3M/L2M。2. 1. 4. 2. 3. 2csmControl此進程，隨sRIO驅(qū)動，用于初始化、心跳、配置和控制CMM/FMM的狀態(tài)。CMM/FMM組 件也通過此進程傳送調(diào)試和診斷記錄。2. 1. 4. 2. 3. 3imageServer此進程負責(zé)下載鏡像到L3M和L2M.2. 1. 4. 2. 3. 4dbServer此進程通過使用XML配置文件并將其內(nèi)容轉(zhuǎn)換為基于TTLV的消息來將配置推送 到應(yīng)用程序。2. 1. 4. 2. 3. 51ogServer此進程負責(zé)以下功能 將所有的記錄配置(級別，每移動設(shè)備的過濾器等)饋送給應(yīng)用程序，使其能進 行實時過濾 從各應(yīng)用程序提取記錄消息，并聚合為記錄文件、syslog等。 為調(diào)試和診斷記錄提供外部接口。2. 1.4. 2. 4UMB協(xié)議信令進程2. 1. 4. 2. 4. IActive Set Mgr本進程是協(xié)議棧的核心。它服務(wù)于以下目的 管理L3M中的移動設(shè)備 管理L2M中的第二層ID
· ICI 通知消息的源和宿· EAP 認證器眷終止KEP信令 終止RCP信令2. 1. 4. 2. 4. 2 Neighbor discovery本進程負責(zé)維護所有的每個鄰居的信息，以及所有鄰居發(fā)現(xiàn)相關(guān)的AT信令。2. 1. 4. 2. 4. 3 pmipClient本進程負責(zé)管理與AGW的PMIP接口。2. 1. 4. 2. 4. 4 Qos MgrQos Mgr執(zhí)行所有從RADIUS配置文件或從AT的QMP信令觸發(fā)的L2M QoS準(zhǔn)入控 制。本進程是隨L3M和L2M的數(shù)據(jù)驅(qū)動準(zhǔn)入控制信令的完整部分。本進程終止基本的Qos管理協(xié)議，并且是計帳的接口。2. 1. 4. 2. 4. 5 Accounting collector本進程管理來自L3M/L2M的收集并且發(fā)送記賬記錄到AGl2. 1. 4. 2. 4. 6 Session Mgr本進程終止來自AT的所有會話層信令，與AT協(xié)商特性。2. 1. 4. 2. 4. 7 Page manager本進程負責(zé)AT位置跟蹤以及AT網(wǎng)絡(luò)尋呼，當(dāng)系統(tǒng)工作在分布式S-RNC模式時。2. 1. 4. 2. 4. 8 DNS resolver本進程負責(zé)解析并緩存來自DNS服務(wù)器的響應(yīng)。使用DNS響應(yīng)消息中的TTL來管 理內(nèi)部緩存。只要積極使用DNS名稱，本進程將自動刷新緩存項目。沒有被刷新的條目將 最終從緩存中移除。2. 1. 4. 2. 4. 9 Authentication client本進程作為協(xié)議棧內(nèi)其他進程的認證/授權(quán)客戶端。本客戶端與配置好的 RADIUS/Diameter 服務(wù)器對接。2. 1. 4. 2. 5 內(nèi)核模塊注意，只有netbsd初始支持內(nèi)核模塊。2. 1. 4. 2. 5. 1 Messaging本內(nèi)核模塊的存在是為了提供基于以太網(wǎng)的通信和多播復(fù)制以及響應(yīng)聚合。此 外，它還負責(zé)CSM模塊的心跳/發(fā)現(xiàn)。2. 1.4.3信令流中的協(xié)議標(biāo)記所有的調(diào)用流程圖顯示了系統(tǒng)中發(fā)送的每個消息的協(xié)議/消息ID對。表2. 6定 義了縮寫到協(xié)議名的映射。表2. 6協(xié)議縮寫 2. 1. 4. 3. IOTA信令分組的動態(tài)路由在消息傳遞系統(tǒng)中，空中(OTA)信令分組必須動態(tài)可路由到不同目的端口。駐留 在L2M中的L2路由器，路由信令分組到/從各個CPM應(yīng)用程序。使用信令網(wǎng)絡(luò)協(xié)議(SNP) 中的協(xié)議類型來路由分組。要路由的分組為 通過本地信令流達到的空中鏈路分組 來自L3M的隧道信令分組為了動態(tài)路由分組，CPM將在L2M啟動時放入如下表格。注意，該表僅供參考。表2. 7 SNP協(xié)議類型、協(xié)議號和應(yīng)用程序端口 2. 1. 4. 4 0ΑΜ&Ρ 架構(gòu)每個軟件組件生成詳細信息部分，包括其所有的配置和統(tǒng)計記錄。記錄可以是單 個的標(biāo)量字段，或者是多個字段。通過32位記錄類型標(biāo)簽以及單一或者復(fù)合的鍵來唯一確 定每個記錄實例。 DBM消息由消息頭部、DBM頭部和載荷組成。以下三個實體是處理UMB參考設(shè)計DBM消息的實體 客戶端——被許可方的軟件，發(fā)起命令提供服務(wù)或從UMB參考設(shè)計進程中獲取 數(shù)據(jù)?？蛻舳说囊粋€例子是CLI或SNMP代理?！?dbserver——與客戶端以及UMB參考設(shè)計進程進行接口的軟件。它是參考 軟件，可能以其現(xiàn)有的情況被使用，或者被修改后使用、或者被被許可方提供的軟件代替。 dbserver進程是本文檔中說明的外部接口的使用者。它必須響應(yīng)來自UMB參考設(shè)計進程的 UMB參考設(shè)計DBM注冊請求。在注冊期間，如果對方進行了請求，則它必須將服務(wù)提供給對 方。它必須中轉(zhuǎn)從客戶端發(fā)起的請求到注冊為處理該消息的UMB參考設(shè)計進程。它必須中 轉(zhuǎn)該消息的響應(yīng)回發(fā)起請求的客戶端。它必須實現(xiàn)客戶端使用的原始素數(shù)據(jù)模型和UMB參 考設(shè)計進程使用的記錄類型數(shù)據(jù)模型之間的映射。它必須實現(xiàn)客戶端使用的DBM消息架構(gòu) 和在本文中說明的UMB參考設(shè)計進程使用的DBM消息架構(gòu)之間的映射。 應(yīng)用程序——是UMB參考設(shè)計線程/任務(wù)/進程。它們向dbserver注冊感興趣 的DBM消息類型，記錄類型，以及鍵名。它們響應(yīng)自客戶端發(fā)起的、由dbserver中轉(zhuǎn)的DBM 消息。dbserver進程應(yīng)當(dāng)實現(xiàn)為給客戶端的請求提供默認值、或者提供已配置的值。 這使得當(dāng)其在啟動時注冊其感興趣的所有DB記錄后，所有的軟件可以有一致的行為。 dbserver進程將響應(yīng)默認值或者已保存的配置值。2. 1. 4. 4. 1 軟件 API本節(jié)說明UMB參考設(shè)計DBM API支持的操作。2. 1. 4. 4. 1. 1 TYPE_DB_GETTYPE_DB_GET操作用于從應(yīng)用程序獲取統(tǒng)計信息。請求TYPE_DB_GET請求的組成如下 記錄類型 鍵 零個或多個要獲取的數(shù)據(jù)字段鍵中不能指定通配符。使用TYPE_DB_GETKEYS消息來解析通配符鍵。如果獲取的記錄類型沒有對應(yīng)鍵名，則指定空鍵。如果指定0個要獲取的數(shù)據(jù)字段，則返回該記錄類型的所有字段，否則，只返回指 定的字段。響應(yīng)
TYPE_DB_GET響應(yīng)的組成如下 記錄類型 結(jié)果——返回0表示成功；所有其他值表示失敗。 請求的鍵 請求的數(shù)據(jù)字段圖 2-8 示出了 TYPE_DB_GET 消息流。 圖2-8DB GET 消息流2. 1. 4. 4. 1. 2TYPE_DB_GETKEYSTYPE_DB_GETKEYS操作用于從應(yīng)用程序獲取可以的統(tǒng)計記錄的鍵名。請求TYPE_DB_GETKEYS 請求的組成如下 記錄類型響應(yīng)TYPE_DB_GETKEYS 響應(yīng)的組成如下 記錄類型·結(jié)果——返回0表示成功 應(yīng)用程序知道的鍵名的列表(僅當(dāng)成功時)圖 2-9 示出了 TYPE_DB_GETKEYS 消息流程。 圖 2_9TYPE_DB_GETKEYS 消息流2. 1. 4. 4. 1. 3 TYPE_DB_N0TIFYTYPE_DB_N0TIFY操作用于通知已訂閱組件關(guān)于記錄的變化。請求TYPE_DB_N0TIFY請求的組成如下 記錄類型 變化類型(插入、更新或刪除) 對應(yīng)于發(fā)生變化的記錄的鍵名 零或多個發(fā)生變化的數(shù)據(jù)字段B 向應(yīng)TYPE_DB_N0TIFY 消息沒有響應(yīng)。圖 2-10 示出了 TYPE_DB_N0TIFY 消息流程。
圖 2-10 TYPE_DB_N0TIFY 消息流
2. 1. 4. 4. 1. 4 TYPE_DB_REGISTERTYPE_DB_REGISTER操作用于針對get/set/notify語義注冊特定的組件到記錄。UMB參考事件進程使用TYPE DB REGISTER消息注冊到dbserver進程，以管理感興 趣的消息類型、記錄類型和鍵名。注冊通常發(fā)生在進程的初始化階段。注冊由dbserver進 程進行維護。當(dāng)管理請求到達時，dbserver進程將該消息轉(zhuǎn)換為UMB參考設(shè)計管理消息并 將其路由到基于消息類型、記錄類型和鍵名、已注冊到該消息的UMB參考設(shè)計進程。如果應(yīng)用程序注冊為TYPE_DB_SET消息，在完成該注冊之后，dbserver進程將中 轉(zhuǎn)所有已配置的、匹配記錄類型和鍵的記錄到該注冊的應(yīng)用程序。將這些作為TYPE_DB_SET 消息發(fā)送到應(yīng)用程序。以這種方式，告知新啟動的進程關(guān)于其當(dāng)前配置。請求TYPE_DB_REGISTER 請求的組成如下 感興趣的記錄類型 鍵名，定義感興趣的鍵值。鍵可能包含通配符，其表明某些或所有字段的所有值 都與該注冊相關(guān)聯(lián)。 感興趣的管理消息類型響應(yīng)TYPE_DB_REGISTER 響應(yīng)的組成如下 記錄類型 結(jié)果——返回0表示成功；所有其他值表示失敗。 請求的鍵 請求的管理消息類型圖 2-11 示出了 TYPE_DB_REGISTER 消息流程。
圖 2-11DB_REGISTER 消息流
2. 1. 4. 4. 1. 5 TYPE_DB_SET
TYPE_DB_SET消息用于通知UMB參考設(shè)計進程關(guān)于記錄即將改變。請求TYPE_DB_SET請求的組成如下 記錄類型 改變的類型(插入、更新或刪除) 鍵，可能是應(yīng)用程序以前并不知道的一個鍵。 將要改變的零個或多個數(shù)據(jù)字段響應(yīng)TYPE_DB_SET響應(yīng)的組成如下 記錄類型 結(jié)果——返回0表示成功；所有其他值表示失敗。 改變的類型(插入、更新或刪除) 請求的鍵 請求的數(shù)據(jù)字段圖2-12 示出了 TYPE_DB_SET 消息流程。 圖2_12DB_SET 消息流2. 1.4. 4. 2 配置沒有任何UMB參考設(shè)計進程可以直接訪問其配置數(shù)據(jù)。訪問配置數(shù)據(jù)由dbserver 進程提供。對于UMB參考設(shè)計進程運行中的配置，將使用以下的數(shù)據(jù)路徑1.配置改變由客戶端發(fā)起，并中轉(zhuǎn)到dbserver進程。2. dbserver進程將其轉(zhuǎn)換為關(guān)于記錄類型和鍵的TYPE_DB_SET請求，并將其發(fā)送 到已注冊為接收該記錄類型和鍵的TYPE_DB_SET請求的UMB參考設(shè)計進程。3.應(yīng)用程序接收或拒絕該請求，并將響應(yīng)發(fā)回dbserver進程。
4.如果請求被接收，配置變化由dbserver進程或一些其他被許可方軟件添加到 配置數(shù)據(jù)庫。5.對與UMB參考設(shè)計進程的初始化，將使用以下數(shù)據(jù)路徑a.作為其初始化的一部分，應(yīng)用程序發(fā)起TYPE_DB_REGISTER請求到dbserver進 程，指示其對某種特定的記錄類型和特定的鍵值(可以是通配符)的TYPE_DB_SET消息感 興趣。b. dbserver進程將該請求添加到其注冊表。c.對于配置數(shù)據(jù)庫中匹配TYPE_DB_REGISTER請求的每個記錄和鍵名，發(fā)生以下 情況i. dbserver進程為該記錄產(chǎn)生TYPE_DB_SET請求，并將其發(fā)送到應(yīng)用程序。ii.應(yīng)用程序接收或拒絕該請求，并且將響應(yīng)發(fā)回dbserver進程。以這種方式，UMB參考設(shè)計進程的新實例得知其配置。TYPE_DB_GET消息通常定 義為獲取記錄類型的數(shù)據(jù)。因此，它可以用于從應(yīng)用程序獲取統(tǒng)計數(shù)據(jù)或者配置數(shù)據(jù)或者 這兩者，也即，由應(yīng)用程序維護的任何記錄類型。然而，實現(xiàn)可以選擇使用TYPE_DB_GET來 僅獲取統(tǒng)計數(shù)據(jù)，并采用不同的數(shù)據(jù)路徑來獲取配置數(shù)據(jù)。例如，響應(yīng)于客戶端的請求， dbserver進程為了獲取UMB參考設(shè)計配置數(shù)據(jù)可以直接訪問配置數(shù)據(jù)庫，而不是為此詢問 UMB參考設(shè)計應(yīng)用程序。2. 1. 4. 4. 3通配符請求除了 TYPE_DB_REGISTER請求，所有包含鍵的UMB參考設(shè)計管理請求都要求該鍵被 全部指定。換句話說，任何數(shù)據(jù)獲取或修改請求中不允許使用通配符。應(yīng)用程序中需要使 用通配符的例子是客戶端支持tab補齊，并且tab解析為鍵名。當(dāng)數(shù)據(jù)請求中需要通配符 時，應(yīng)當(dāng)使用TYPE_DB_GETKEYS請求。2. 1.4. 4. 4批量數(shù)據(jù)請求當(dāng)結(jié)合TYPE_DB_GET消息使用時，TYPE_DB_GETKEYS消息可以供dbserver進程使 用來解析通配符，并且滿足獲取批量數(shù)據(jù)的請求。例如，客戶端可以發(fā)出用于所有NTP服務(wù) 器統(tǒng)計的請求。它向dbserver進程發(fā)出該請求。dbserver進程將此請求轉(zhuǎn)換為UMB參考 設(shè)計管理接口，其通過首先發(fā)出TYPE_DB_GETKEYS請求到已注冊為響應(yīng)記錄類型為NTP_ STATS、任意鍵名的TYPE_DB_GETKEYS請求的UMB參考設(shè)計進程。該應(yīng)用程序用已知鍵的列 表來響應(yīng)dbserver進程的請求。dbserver進程接著對該已知鍵值列表進行迭代，并對每一 個鍵名發(fā)起一個TYPE_DB_GET請求。該應(yīng)用程序響應(yīng)匹配該鍵名的NTP_STATS記錄，該響 應(yīng)由dbserver進程進行聚合，直到得到最終的鍵值。一旦該情況發(fā)生，則將完整的鍵列表 和數(shù)據(jù)返回給客戶端。圖2-13示出了批量數(shù)據(jù)獲取消息流程。 圖2-13批量數(shù)據(jù)獲取消息流2. 1. 4. 4. 5診斷和調(diào)試記錄調(diào)試記錄是指對運行系統(tǒng)中發(fā)生的事件進行可操作的記錄。這些包括協(xié)議事件和 系統(tǒng)的其他的、本質(zhì)上非統(tǒng)計的方面。如果這樣配置，調(diào)試記錄自行流出每個模塊。將該流 作為TTLV編碼流通過q-messaging進行發(fā)送。診斷記錄允許查看單獨用戶或一組用戶的性能特性。它用于診斷或監(jiān)控系統(tǒng)的特 定性能特性。通常，診斷記錄沒有啟用。它和調(diào)試記錄通過不同的流發(fā)送，以便能由CPM上 的記錄服務(wù)器獨立地處理。圖2-14示出了診斷和調(diào)試記錄架構(gòu)。
54
圖2-14診斷和調(diào)試記錄架構(gòu)2. 1. 4. 4. 5. 1 記錄服務(wù)器記錄服務(wù)器提供以下配置數(shù)據(jù)組 調(diào)試記錄過濾器——配置記錄級別/屬性值對 調(diào)試記錄配單元配置——指示是否對于每個單元記錄時間、文件名、函數(shù)名和 行號 可讀的調(diào)試配置——指示是否將可讀的調(diào)試記錄寫入Std0Ut、SySl0g或者均不寫入。· TTLV文件配置——指示是否啟用TTLV文件，如果啟用，保存哪個TTLV標(biāo)記。這 是推動接口。在配置的時間間隔，文件經(jīng)SCP去往遠程機器?！?Diameter配置——指示是否啟用Diameter協(xié)議接口。在啟動時，記錄服務(wù)器注冊為通知任何類型的配置數(shù)據(jù)改變。它驗證任何改變并 且回復(fù)給dbserver進程。記錄服務(wù)器處理來自客戶端的記錄記錄，并決定要寫入的目的 地。記錄服務(wù)器可以將調(diào)試記錄寫入以下的宿 文件· qmsg 端 口 調(diào)試/診斷記錄服務(wù)器(流模式)它作為一個Diameter服務(wù)器并發(fā)送Diameter消息給任何配置的Diameter客戶端。2. 1. 4. 5 UMB L3M 軟件架構(gòu)L3M處理IP分組以支持UMB空中鏈路操作。L3M負責(zé)對數(shù)據(jù)面進行以下操作(在 API的控制下) 針對空中鏈路QoS支持的IPv4分類· IPv4過濾支持· IPv4分片處理· VOIPRoHC 配置支持 每個移動設(shè)備每個流的反向鏈路策略· IPv6 (以后的工作)L3M通過Cavium Networks 58xx NPU實現(xiàn)。Cavium核心被分為運行于Green Hills SystemsuVelOSity RTOS的單個管理核心和運行Cavium Simple Executive的其余核心。 完全根據(jù)Cavium Simple Executive完成IP中轉(zhuǎn)路徑。為了簡化移植到其他RT0S，管理核 心對于進入RTOS的所有調(diào)用使用OS抽象層(OSAL)。使用Cavium Simple Executive的數(shù) 據(jù)路徑核心不需要0SAL，因為Cavium Simple Executive已經(jīng)是獨立于OS無關(guān)的。本節(jié)覆蓋以下控制面主題 啟動和鏡像下載 配置 統(tǒng)計獲取 調(diào)試和診斷記錄· Sff故障報告· RTOS 抽象層圖2-15示出了 L3M高層軟件架構(gòu)
圖2-15L3M高層軟件架構(gòu)該軟件架構(gòu)的許多方面依賴于Cavium OCTEON硬件。由于我們處理的是多核設(shè)備， 存在許多不同的方式來分配工作。如前文中提到的，L3M的首要目的是針對所有用戶業(yè)務(wù) 執(zhí)行IP數(shù)據(jù)路徑處理。為實現(xiàn)此目的，大部分的核心(即，除了一個以外)都致力于處理 用戶數(shù)據(jù)分組。這些核心將稱為分組處理核心(或者PP核心)。剩余的核心將致力于L3M 的總體管理和控制。該核心將稱為管理/控制核心(或者MC核心)。MC核心總是OCTEON 中編號最小的。2. 1. 4. 5. IMC 核心MC核心主要負責(zé)與運行在信令處理器上的協(xié)議棧軟件進行交互和通信。該核心也 負責(zé)分配和維護共享內(nèi)存中的、將會被PP核心訪問的所有每用戶數(shù)據(jù)結(jié)構(gòu)。MC核心將運行在Green Hills System uVelOSity RTOS中。MC核心軟件被分為 少數(shù)的任務(wù)/線程。任務(wù)的初步列表如下
動
管理/消息傳遞任務(wù) 記錄任務(wù) 眷命令行接口任務(wù)
WD0G/LED 任務(wù) 清理任務(wù)
IPSEC/MSK 任務(wù)
2. 1. 4. 5. 2管理/消息傳遞任務(wù)
管理/消息傳遞任務(wù)負責(zé)與運行在CPM上的協(xié)議軟件的所有通信。其涉及以下活 響應(yīng)于UMB協(xié)議棧發(fā)送的命令，添加/刪除每AT的數(shù)據(jù)結(jié)構(gòu)和分類器規(guī)則。
收集統(tǒng)計并將其報告回CPM 代理去往/來自上層的分組 添加/刪除到L3路由表項目的項 硬件/軟件故障報告2. 1. 4. 5. 3 記錄任務(wù)該任務(wù)負責(zé)建立并發(fā)送調(diào)試和診斷記錄消息給運行在CPM上的記錄服務(wù)器應(yīng)用 程序。該任務(wù)還負責(zé)接收和處理由PP核心生成的任何內(nèi)部格式的記錄消息。2. 1.4. 5.4命令行接口任務(wù)命令行接口對于其運行時監(jiān)控和調(diào)整L3M提供冗余支持。它嚴格用于開發(fā)/調(diào)試。2. 1. 4. 5. 5WD0G/LED 任務(wù)WD0G/LED任務(wù)負責(zé)看護核心的硬件看門狗，并且在L3M的LED上顯示任何類型的
有用fe息。2. 1. 4. 5. 6移動管理清理任務(wù)清理任務(wù)負責(zé)檢查標(biāo)記為老化的表/項目的狀態(tài)，但由于該項目可能還在使用而 尚未被刪除。2. 1. 4. 5. 7IPSEC/MSK 任務(wù)本任務(wù)負責(zé)MSK鍵的管理和安全存儲，以支持EAP-ER。2. 1.4. 5.8分組處理核心除了最小編號的核心以外的所有核心，都致力于分組處理任務(wù)。這些核心將不 會運行完全的RT0S。相反，它們的每一個將使用Cavium Simple Executive。Simple Executive負責(zé)硬件初始化并建立C運行環(huán)境。每個核心是單線程的，并將運行以下簡化代 碼片段的實例main (){

} 每個核心將請求來自POW單元的分組進行處理，盡可能快地處理該分組，然后在 需要時釋放該分組。如果由于某種原因(例如，該分組是中間的或最后的IP分片，并且第 一個分片還沒有接收到)分組處理不能繼續(xù)進行，那么需要將該分組排隊，并且在核心能 夠請求新工作以前退出/不調(diào)度該工作。
Wrok_t 女 wk ；
while (1)
{
wk = get—work ()；
wk = process_data_pkt(wk)；
if ( wk )
{
Freek work(wk)；
ι
ι
58
2. 1. 4. 5. 9線程間/核心間通信要求在MC核心上的任務(wù)之間進行的任何通信將通過高通消息傳遞API來完成。這 將要求高通消息傳遞代碼移植到UVelOSity上運行。這提供了統(tǒng)一的方法進行任務(wù)間通信 以及與運行在CPM上的軟件進行通信。PP核心彼此間不需要直接通信，它們也不需要與管理/控制核心上的任何任務(wù)明 確通信。需要從PP核心傳送到MC核心的任何數(shù)據(jù)(反之亦然)將通過Cavium處理器中 的POW單元完成。也就是說，任何核心都能夠創(chuàng)建新的工作并將其提交到POW進行調(diào)度。然 后，基于分組號，POW將該分組引導(dǎo)至合適的核心或核心組進行處理。2. 1. 4. 5. 10共享內(nèi)存和鎖定各種數(shù)據(jù)結(jié)構(gòu)都需要在共享內(nèi)存中維護，因為它們可能需要被所有的N個核心訪 問。自旋鎖用于提供對共享數(shù)據(jù)結(jié)構(gòu)的排他訪問。引用計數(shù)也需要被維護以避免MC核心 移除還在被PP核心使用的每用戶數(shù)據(jù)結(jié)構(gòu)。每個每AT數(shù)據(jù)結(jié)構(gòu)將得到鎖的保護。將使用MIPS核心提供的負載連接的并且是存儲有條件的指令來實現(xiàn)自旋鎖。提 供鎖定例程將會聚集統(tǒng)計信息，該統(tǒng)計信息關(guān)于該鎖被持有的時間以及獲取該鎖所需要的 時間。添加代碼以用于檢查死鎖條件并且如果發(fā)生死鎖條件則進行釋放。每個核心具有其 自己的硬件看門狗定時器以后，我們也將可以檢測這些條件。2. 1.4. 5. 11 工作組編號Cavium POff單元使用分組號來分類并分發(fā)工作(即分組)到各核心。有16種可 能的分組號(0-15)。分組號能由PIP/LPD在分組進入系統(tǒng)時通過各種方式進行分配。最 簡單的情況是默認的分組號被分配給在特定接口上接收到的所有分組。我們將采用這種方 法。此外，當(dāng)新的工作核心軟件由核心軟件創(chuàng)建并提交到POW時，分組號必須明確指明。我 們也將采用該方法。表2. 8示出了當(dāng)前的分組編號方案。表2. 8工作組編號方案
分組名稱說明0控制/管理分配給所有來自控制/管理GigE接口的流量；只有管理/控制核心會 訂閱該組1原始IP數(shù)據(jù)分配給所有來自IP數(shù)據(jù)GigE接口的流量2已哈希的IP數(shù)據(jù)分配給分組格式已被識別并生成了哈希的IP流量3L2/L3分配給所有在L2/L3GGigE接口上接收的流量4分組捕獲分配給所有由分組處理核心捕獲的流量；只有管理/控制核心會訂閱 該組5分組注入由管理/控制核心分配給它注入的所有流量；分組處理核心會訂閱該 組
59 2. 1.4. 6 啟動Cavium SDK包括某版本的開源U-Boot引導(dǎo)加載器軟件，其已被修改為可與 OCTEON 工作。2. 1. 4. 6. 1 U-Boot 改動為適合我們的需求，將對U-Boot源代碼作了以下兩個方面的增強 添加POST和其他診斷代碼 添加使用專有協(xié)議下載鏡像的支持U-Boot當(dāng)前包含基本的IP支持，能使用TFTP從網(wǎng)絡(luò)下載代碼。由于L3M是集成 到AP中的模塊，我們不能依賴于具有可用的IP網(wǎng)絡(luò)來下載代碼。因此，將使用專有的鏡像 下載協(xié)議來代替。該協(xié)議將在以太網(wǎng)上運行，使用高通消息傳遞。CPM將運行鏡像服務(wù)器應(yīng) 用程序，其響應(yīng)鏡像下載請求。精簡版的高通消息傳遞將需要添加到U-Boot中。需要能夠使用固定地址來接收 并響應(yīng)心跳和發(fā)送/接收協(xié)議消息。不需要參與消息傳遞系統(tǒng)的名稱服務(wù)協(xié)議。2. 1.4. 6. 2 啟動順序基于以上信息，L3M啟動順序如下從引導(dǎo)Flash引導(dǎo)進入U-Boot。運行POST并保存結(jié)果到固定的共享內(nèi)存塊。初 始化設(shè)備。引導(dǎo)加載器將在最小編號的核心上運行。其他核心將被復(fù)位掛起。在管理/控制接口上偵聽高通消息傳遞心跳請求。CPM會在VLAN4080優(yōu)先級7上 廣播該心跳。一旦發(fā)現(xiàn)了鏡像服務(wù)器的地址，并且VLAN配置已知，引導(dǎo)代碼將試圖使用鏡像傳 送協(xié)議來下載可工作的鏡像(或多個鏡像)。注意可能有兩個分開的鏡像，一個用于控制核心，即基于RTOS的鏡像，一個用于分組處理核心。如果可能，它們將被合并為單個核心或打包進單個的包。引導(dǎo)代碼然后加載鏡像到存儲器并使得PP核心離開復(fù)位。一旦PP核心運行，弓丨導(dǎo)加載器將需要弓丨導(dǎo)基于RTOS的控制代碼，即基本上跳轉(zhuǎn)至IJ 該控制代碼。此時，RTOS將初始化其擁有的硬件、初始化存儲器，并生成任務(wù)。一旦L3M上電并運行，CPM將通過消息交換來配置它。圖2-16和圖2-17示出了用于使L3M上電離開復(fù)位的消息流。 圖2-16L3M/L2M啟動消息流-第一部分
圖2-17L3M/L2M啟動消息流-第二部分 2. 2系統(tǒng)接口 2. 2. 1空中接口 2. 2. 1. 1 UMB L2M 軟件架構(gòu)
L2M將重用調(diào)試和診斷記錄基礎(chǔ)結(jié)構(gòu)、0SAL、以及已完成用于L3M的高通消息傳遞
2. 2. 1. 1. 1L2M FL 架構(gòu) 圖2-18示出了 L2M FL架構(gòu)。
Ini
62 圖 2-18L2M FL 架構(gòu)2. 2. 1. 1. 2L2M RL 架構(gòu)圖 2-19 示出了 L2M RL 架構(gòu)。 圖 2-19L2MRL 架構(gòu)2. 2. 1. 1. 3L2M 軟件功能L2M為UMB空中鏈路數(shù)據(jù)路徑實現(xiàn)以下功能· FL活動隊列管理 信令協(xié)議分組的簽名/認證 路徑間隧道協(xié)議
無線鏈路協(xié)議(RLP)——分片和重組 流和路徑協(xié)議 分組合并協(xié)議 流量信道MAC 加密密鑰管理支持 開銷消息· R-CDCCH 和 R-0DCCH 消息處理· FL和RL鏈路適配· FL和RL調(diào)度器L2M還為UMB空中鏈路控制面實現(xiàn)以下功能 尋呼調(diào)度 統(tǒng)計收集與獲取 連接控制面 信令協(xié)議 調(diào)試和診斷記錄2. 2. 2被許可方接口2. 2. 2. 1 UMB APIUMB API包含物理層、L2和L3模塊的數(shù)據(jù)路徑API以及信令路徑API。它們共同 提供軟件接口，用于發(fā)送數(shù)據(jù)到UMB參考設(shè)計和/或接收來自UMB參考設(shè)計的數(shù)據(jù)。2. 2. 2. 2 CSM APICSM API是用于發(fā)送數(shù)據(jù)到UMB調(diào)制解調(diào)器參考設(shè)計中的PHY模塊和/或接收 來自UMB調(diào)制解調(diào)器參考設(shè)計中的PHY模塊的數(shù)據(jù)的軟件接口，S卩CMM或FMM。L2M使用 CSMAPI 與 CMM/FMM 通信。3. UMB API3. 1 概述UMB API是消息傳遞API。它可以被視為流過以太網(wǎng)接口的去往L3M、L2M和FMM/ CMM的所有消息的列表。3. 2管理面3. 2. IUMB 消息路由這些消息用于配置FMM/CMM固件、L2M和L3M軟件以及協(xié)議棧之間的內(nèi)部消息路3. 2. 2 控制初始化，心跳，控制L3M、L2M，以及FMM/CMM。3. 2. 3鏡像下載下載鏡像到L3M、L2M 和 FMM/CMM。3. 2. 4配置和統(tǒng)計每個軟件組件將提供它要求的DBM記錄的列表。3. 2. 4. 1硬件/軟件組件配置3. 2. 5 記錄 圖3-1數(shù)據(jù)分組頭部3. 3. 1. IFL 分組處理這些數(shù)據(jù)分組(協(xié)議)是L3M軟件能通過以太網(wǎng)接口接收的分組。3. 3. 1. 2RL 分組處理這些數(shù)據(jù)分組(協(xié)議)是L3M軟件能通過以太網(wǎng)接口發(fā)送的分組。3. 3. 1. 3用于切換的RLP分組轉(zhuǎn)發(fā)這些RLP分組在L2切換時從L2M轉(zhuǎn)發(fā)到新的AP。3. 3. 2 配置3.3.2.1L3M 功能3. 3. 2. 1. IQoS分類及防火墻3. 2. 5. 1 調(diào)試記錄3. 2. 5. 2 診斷記錄3. 2. 5. 3 外部記錄3. 2. 6 故障每個軟件組件將需要詳細描述其可能送出的任何故障。3. 3數(shù)據(jù)面3. 3. 1分組流程IPDataHeaderMessage_c類是所有IP數(shù)據(jù)消息的基類。L2M和L3M之間發(fā)送的每
個數(shù)據(jù)分組都會附有如圖3-1所示的頭部。
65
其以每個AT為基礎(chǔ)添加和刪除防火墻規(guī)則和分類器規(guī)則。3. 3. 2. 1. 2第三層數(shù)據(jù)路徑管理其打開/關(guān)閉TCP MSS調(diào)整和ICMP路徑MTU發(fā)現(xiàn)。3.3.2.2L2M 功能3. 3. 2. 2. IFL 調(diào)度器3. 3. 2. 2. 2RL 調(diào)度器3. 3. 2. 2. 3 鏈路適配3. 3. 2. 2. 4 隊列管理3. 3. 2. 2. 5RLP3. 3. 2. 3FMM/CMM 功能參考[Q2]3. 4控制面3. 4. 1不透明UMB協(xié)議消息這些消息用于發(fā)送UMB協(xié)議消息到AT。這些消息被第二層軟件不透明地對待，即 在RLP中封裝并發(fā)送。這些協(xié)議包括在[S7]中定義的能夠在信令網(wǎng)絡(luò)協(xié)議上運輸?shù)娜魏螀f(xié)議。3. 4. 2AT 管理其從第二層和第三層添加和刪除AT。3. 4. 3AT 隧道管理其添加和刪除用于中轉(zhuǎn)FL流量的AP之間的隧道。3. 4. 4空中鏈路QoS管理其用于配置L2M和L3M，以同時支持預(yù)配置和QMP信號發(fā)送的空中鏈路QoS。3. 4. 5記賬管理其允許CMP棧獲取對AT會話進行記賬必要的FL和RL計數(shù)器。3. 4. 6RLP認證/加密密鑰管理其給CPM提供了基于EAP-ER或KEP協(xié)商結(jié)果推送新的RLP會話密鑰的能力。3. 4. 7 第二層 AT 管理其為L2M中的AT事件提供了中轉(zhuǎn)到CPM進行處理的能力。4.操作4. 1 概述本章說明針對UMB/CSMAPI捕獲使用場景的消息流程圖。每節(jié)示出了使用UMB/ CSMAPI執(zhí)行特定功能的不同場景。4. 2 管理4. 2.1啟動和初始化圖4-1和圖4-2示出了啟動和初始化流程。 圖4-1啟動和初始化——第一部分 圖4-2啟動和初始化——第二部分
4. 2. 2配置和統(tǒng)計獲取
4. 3數(shù)據(jù)面
4. 3. 1FL分組處理
4. 3. 1. 1DAP與FLSS在相同位置
待定
4. 3. 1. 2DAP 與 FLSS 在不同 AP 上
待定
4. 3. 2RL分組處理
4. 3. 2. 1RLSS 使用 DAP 向 AGW 發(fā)送
待定
4. 3. 2. 2RLSS直接向AGW發(fā)送
待定
4. 4控制面
4. 4. 1上電
4. 4. 1. 1使用EAP認證上電
圖4-4上電-第二頁 圖4-5上電-第三頁 圖4-7L2+L3 切換-新 BSE-第一頁
圖 4-8L2+L3 切換-新 BSE-第二頁圖4-10L2+L3 切換-原 BSE-第一頁 圖4-12睡眠-優(yōu)雅關(guān)閉4. 4. 3. 2 連接丟失 圖4-13睡眠-連接丟失4. 4. 4位置跟蹤4. 4. 4. 1成功的位置跟蹤更新 [1012] 圖 4-16QMP 協(xié)商的 QoS4. 4. 6. 2 失敗的 QoS 協(xié)商待定
權(quán)利要求
一種用于采樣同步的方法，包括從射頻前端(RFFE)接收返回鏈路(RL)時間戳；從導(dǎo)航和定時系統(tǒng)接收系統(tǒng)時間秒；基于所述RL時間戳和所述系統(tǒng)時間秒生成前向鏈路(FL)時間戳；以及將所述FL時間戳和所述系統(tǒng)時間秒包括到時間數(shù)據(jù)中。
2.根據(jù)權(quán)利要求1所述的方法，還包括將所述時間數(shù)據(jù)復(fù)用到采樣流。
3.根據(jù)權(quán)利要求2所述的方法，還包括發(fā)送所述采樣流。
4.根據(jù)權(quán)利要求1所述的方法，其中，所述導(dǎo)航和定時系統(tǒng)是全球?qū)Ш叫l(wèi)星系統(tǒng) (GNSS)、俄羅斯GL0NASS(全球?qū)Ш叫l(wèi)星系統(tǒng))、歐盟的伽利略定位系統(tǒng)、印度區(qū)域?qū)Ш叫l(wèi)星 系統(tǒng)(IRNSS)或中國的北斗衛(wèi)星導(dǎo)航和定位系統(tǒng)中的一個。
5.根據(jù)權(quán)利要求1所述的方法，其中，所述導(dǎo)航和定時系統(tǒng)是全球定位系統(tǒng)(GPS)。
6.根據(jù)權(quán)利要求5所述的方法，還包括將所述系統(tǒng)時間秒對準(zhǔn)到所述全球定位系統(tǒng) 的GPS時間。
7.根據(jù)權(quán)利要求1所述的方法，還包括將時間戳計數(shù)器對準(zhǔn)到所述系統(tǒng)時間秒。
8.根據(jù)權(quán)利要求1所述的方法，其中，對于IOMHz帶寬UMB頻分雙工(FDD)模式，每 1024次采樣寫入所述FL時間戳。
9.根據(jù)權(quán)利要求2所述的方法，其中，所述FL時間戳進一步包括所述采樣流所代表 的當(dāng)前操作模式的信息。
10.一種用于RF控制的方法，包括在存儲器中存儲增益信息和選通控制信息；以及 執(zhí)行以下步驟之一a)發(fā)送第一期望時間戳和所述增益信息到射頻前端(RFFE)；b)發(fā)送第二期望時間戳和txEnable命令到發(fā)送選通控制；或者c)發(fā)送第三期望時間戳和rxEnable命令到接收選通控制。
11.根據(jù)權(quán)利要求10所述的方法，還包括接收所述增益信息和所述選通控制信息。
12.根據(jù)權(quán)利要求10所述的方法，其中，所述發(fā)送選通控制和所述接收選通控制是所 述射頻前端(RFFE)的一部分。
13.根據(jù)權(quán)利要求10所述的方法，還包括執(zhí)行以下步驟中尚未執(zhí)行之第二步驟a)發(fā)送所述第一期望時間戳和所述增益信息到所述射頻前端(RFFE)；b)發(fā)送所述第二期望時間戳和txEnable命令到所述發(fā)送選通控制；或者c)發(fā)送所述第三期望時間戳和rxEnable命令到所述接收選通控制。
14.根據(jù)權(quán)利要求13所述的方法，還包括執(zhí)行以下步驟中尚未執(zhí)行之最后步驟a)發(fā)送所述第一期望時間戳和所述增益信息到所述射頻前端(RFFE)；b)發(fā)送所述第二期望時間戳和txEnable命令到所述發(fā)送選通控制；或者c)發(fā)送所述第三期望時間戳和rxEnable命令到所述接收選通控制。
15.根據(jù)權(quán)利要求14所述的方法，其中，所述發(fā)送選通控制和所述接收選通控制是所 述射頻前端(RFFE)的一部分。
16.根據(jù)權(quán)利要求10所述的方法，其中，所述射頻前端(RFFE)的增益的改變發(fā)生在基 于所述增益信息的期望時間的+/_2微秒內(nèi)。
17.根據(jù)權(quán)利要求16所述的方法，其中，所述期望時間是增益改變生效的時間。
18.根據(jù)權(quán)利要求10所述的方法，還包括將以下各項中的至少一項復(fù)用到采樣流第 一期望時間戳、第二期望時間戳、第三期望時間戳、增益信息、txEnable命令或rxEnble命 令。
19.根據(jù)權(quán)利要求18所述的方法，其中，所述增益信息(rxGain)定義為 rxGain =四舍五入((Pout-Pin) *2)，其中，Pin是在天線端口處對接收功率的估計，Pout由下式給出 Pout = 101og(o 2)其中，ο 2是所述采樣流的平均平方數(shù)字值。
20.根據(jù)權(quán)利要求19所述的方法，其中，所述增益信息(rxGain)代表以0.5dB步進的期望增益。
21.一種用于采樣同步的區(qū)站調(diào)制解調(diào)器(CSM)，所述CSM包括如下配置的處理器和電路從射頻前端(RFFE)接收返回鏈路(RL)時間戳； 從導(dǎo)航和定時系統(tǒng)接收系統(tǒng)時間秒；基于所述RL時間戳和所述系統(tǒng)時間秒生成前向鏈路(FL)時間戳；以及 將所述FL時間戳和所述系統(tǒng)時間秒包括到時間數(shù)據(jù)中。
22.根據(jù)權(quán)利要求21所述的區(qū)站調(diào)制解調(diào)器，其中，所述處理器和所述電路進一步配 置為將所述時間數(shù)據(jù)復(fù)用到采樣流。
23.根據(jù)權(quán)利要求22所述的區(qū)站調(diào)制解調(diào)器，其中，所述處理器和所述電路進一步配 置為發(fā)送所述采樣流。
24.根據(jù)權(quán)利要求21所述的區(qū)站調(diào)制解調(diào)器，其中，所述導(dǎo)航和定時系統(tǒng)是全球?qū)Ш?衛(wèi)星系統(tǒng)(GNSS)、俄羅斯GL0NASS(全球?qū)Ш叫l(wèi)星系統(tǒng))、歐盟的伽利略定位系統(tǒng)、印度區(qū)域 導(dǎo)航衛(wèi)星系統(tǒng)(IRNSS)或中國的北斗衛(wèi)星導(dǎo)航和定位系統(tǒng)中的一個。
25.根據(jù)權(quán)利要求21所述的區(qū)站調(diào)制解調(diào)器，其中，所述導(dǎo)航和定時系統(tǒng)是全球定位 系統(tǒng)(GPS)。
26.根據(jù)權(quán)利要求25所述的區(qū)站調(diào)制解調(diào)器，其中，所述處理器和所述電路進一步配 置為將所述系統(tǒng)時間秒對準(zhǔn)到所述全球定位系統(tǒng)的GPS時間。
27.根據(jù)權(quán)利要求21所述的區(qū)站調(diào)制解調(diào)器，所述處理器和所述電路進一步配置為 將時間戳計數(shù)器對準(zhǔn)到所述系統(tǒng)時間秒。
28.根據(jù)權(quán)利要求21所述的區(qū)站調(diào)制解調(diào)器，其中，對于IOMHz帶寬UMB頻分雙工 (FDD)模式，每1024次采樣寫入所述FL時間戳。
29.根據(jù)權(quán)利要求2所述的區(qū)站調(diào)制解調(diào)器，其中，所述FL時間戳進一步包括所述采 樣流所代表的當(dāng)前操作模式的信息。
30.一種用于RF控制的區(qū)站調(diào)制解調(diào)器(CSM)，其包括如下配置的處理器和電路 在存儲器中存儲增益信息和選通控制信息；以及執(zhí)行以下步驟之一a)發(fā)送第一期望時間戳和所述增益信息到射頻前端(RFFE)；b)發(fā)送第二期望時間戳和txEnable命令到發(fā)送選通控制；或者c)發(fā)送第三期望時間戳和rxEnable命令到接收選通控制。
31.根據(jù)權(quán)利要求30所述的區(qū)站調(diào)制解調(diào)器，其中，所述處理器和所述電路進一步配 置為接收所述增益信息和所述選通控制信息。
32.根據(jù)權(quán)利要求30所述的區(qū)站調(diào)制解調(diào)器，其中，所述發(fā)送選通控制和所述接收選 通控制是所述射頻前端(RFFE)的一部分。
33.根據(jù)權(quán)利要求30所述的區(qū)站調(diào)制解調(diào)器，其中，所述處理器和所述電路進一步配 置為執(zhí)行以下步驟中尚未執(zhí)行之第二步驟a)發(fā)送所述第一期望時間戳和所述增益信息到所述射頻前端(RFFE)；b)發(fā)送所述第二期望時間戳和txEnable命令到所述發(fā)送選通控制；或者c)發(fā)送所述第三期望時間戳和rxEnable命令到所述接收選通控制。
34.根據(jù)權(quán)利要求33所述的區(qū)站調(diào)制解調(diào)器，其中，所述處理器和所述電路進一步配 置為執(zhí)行以下步驟中尚未執(zhí)行之最后步驟a)發(fā)送所述第一期望時間戳和所述增益信息到所述射頻前端(RFFE)；b)發(fā)送所述第二期望時間戳和txEnable命令到所述發(fā)送選通控制；或者c)發(fā)送所述第三期望時間戳和rxEnable命令到所述接收選通控制。
35.根據(jù)權(quán)利要求34所述的區(qū)站調(diào)制解調(diào)器，其中，所述發(fā)送選通控制和所述接收選 通控制是所述射頻前端(RFFE)的一部分。
36.根據(jù)權(quán)利要求30所述的區(qū)站調(diào)制解調(diào)器，其中，所述射頻前端(RFFE)的增益的改 變發(fā)生在基于所述增益信息的期望時間的+/_2微秒內(nèi)。
37.根據(jù)權(quán)利要求36所述的區(qū)站調(diào)制解調(diào)器，其中，所述期望時間是增益改變生效的 時間。
38.根據(jù)權(quán)利要求30所述的區(qū)站調(diào)制解調(diào)器，其中，所述處理器和所述電路進一步配 置為將以下各項中的至少一項復(fù)用到采樣流第一期望時間戳、第二期望時間戳、第三期望 時間戳、增益信息、txEnable命令或rxEnble命令。
39.根據(jù)權(quán)利要求38所述的區(qū)站調(diào)制解調(diào)器，其中，所述增益信息(rxGain)定義為rxGain =四舍五入((Pout-Pin) *2)，其中，Pin是在天線端口處對接收功率的估計，Pout由下式給出Pout = 101og(o 2)其中，ο 2是所述采樣流的平均平方數(shù)字值。
40.根據(jù)權(quán)利要求39所述的區(qū)站調(diào)制解調(diào)器，其中，所述增益信息(rxGain)代表以 0. 5dB步進的期望增益。
41.一種用于采樣同步的設(shè)備，包括用于從射頻前端(RFFE)接收返回鏈路(RL)時間戳的模塊；用于從導(dǎo)航和定時系統(tǒng)接收系統(tǒng)時間秒的模塊；用于基于所述RL時間戳和所述系統(tǒng)時間秒生成前向鏈路(FL)時間戳的模塊；以及用于將所述FL時間戳和所述系統(tǒng)時間秒包括到時間數(shù)據(jù)中的模塊。
42.根據(jù)權(quán)利要求41所述的設(shè)備，還包括用于將所述時間數(shù)據(jù)復(fù)用到采樣流的模塊。
43.根據(jù)權(quán)利要求42所述的設(shè)備，還包括用于發(fā)送所述采樣流的模塊。
44.根據(jù)權(quán)利要求41所述的設(shè)備，其中，所述導(dǎo)航和定時系統(tǒng)是全球?qū)Ш叫l(wèi)星系統(tǒng)(GNSS)、俄羅斯GL0NASS (全球?qū)Ш叫l(wèi)星系統(tǒng))、歐盟的伽利略定位系統(tǒng)、印度區(qū)域?qū)Ш叫l(wèi)星 系統(tǒng)(IRNSS)或中國的北斗衛(wèi)星導(dǎo)航和定位系統(tǒng)中的一個。
45.根據(jù)權(quán)利要求41所述的設(shè)備，其中，所述導(dǎo)航和定時系統(tǒng)是全球定位系統(tǒng)(GPS)。
46.根據(jù)權(quán)利要求45所述的設(shè)備，還包括用于將所述系統(tǒng)時間秒對準(zhǔn)到所述全球定 位系統(tǒng)的GPS時間的模塊。
47.根據(jù)權(quán)利要求41所述的設(shè)備，還包括用于將時間戳計數(shù)器對準(zhǔn)到所述系統(tǒng)時間 秒的模塊。
48.根據(jù)權(quán)利要求41所述的設(shè)備，其中，對于IOMHz帶寬UMB頻分雙工(FDD)模式，每 1024次采樣寫入所述FL時間戳。
49.根據(jù)權(quán)利要求42所述的設(shè)備，其中，所述FL時間戳進一步包括所述采樣流所代 表的當(dāng)前操作模式的信息。
50.一種用于RF控制的設(shè)備，包括用于在存儲器中存儲增益信息和選通控制信息的模塊；以及用于執(zhí)行以下步驟之一的模塊a)發(fā)送第一期望時間戳和所述增益信息到射頻前端(RFFE)；b)發(fā)送第二期望時間戳和txEnable命令到發(fā)送選通控制；或者c)發(fā)送第三期望時間戳和rxEnable命令到接收選通控制。
51.根據(jù)權(quán)利要求50所述的設(shè)備，還包括用于接收所述增益信息和所述選通控制信 息的模塊。
52.根據(jù)權(quán)利要求50所述的設(shè)備，其中，所述發(fā)送選通控制和所述接收選通控制是所 述射頻前端(RFFE)的一部分。
53.根據(jù)權(quán)利要求50所述的設(shè)備，還包括用于執(zhí)行以下步驟中尚未執(zhí)行之第二步驟的 模塊a)發(fā)送所述第一期望時間戳和所述增益信息到所述射頻前端(RFFE)；b)發(fā)送所述第二期望時間戳和txEnable命令到所述發(fā)送選通控制；或者c)發(fā)送所述第三期望時間戳和rxEnable命令到所述接收選通控制。
54.根據(jù)權(quán)利要求53所述的設(shè)備，還包括用于執(zhí)行以下步驟中尚未執(zhí)行之最后步驟的 模塊a)發(fā)送所述第一期望時間戳和所述增益信息到所述射頻前端(RFFE)；b)發(fā)送所述第二期望時間戳和txEnable命令到所述發(fā)送選通控制；或者c)發(fā)送所述第三期望時間戳和rxEnable命令到所述接收選通控制。
55.根據(jù)權(quán)利要求54所述的設(shè)備，其中，所述發(fā)送選通控制和所述接收選通控制是所 述射頻前端(RFFE)的一部分。
56.根據(jù)權(quán)利要求50所述的設(shè)備，其中，所述射頻前端(RFFE)的增益的改變發(fā)生在基 于所述增益信息的期望時間的+/_2微秒內(nèi)。
57.根據(jù)權(quán)利要求56所述的設(shè)備，其中，所述期望時間是增益改變生效的時間。
58.根據(jù)權(quán)利要求50所述的設(shè)備，還包括用于將以下各項中的至少一項復(fù)用到采樣流 的模塊第一期望時間戳、第二期望時間戳、第三期望時間戳、增益信息、txEnable命令或 rxEnble 命令。
59.根據(jù)權(quán)利要求58所述的設(shè)備，其中，所述增益信息(rxGain)定義為 rxGain =四舍五入((Pout-Pin) *2)，其中，Pin是在天線端口處對接收功率的估計，Pout由下式給出 Pout = 101og(o 2)其中，ο 2是所述采樣流的平均平方數(shù)字值。
60.根據(jù)權(quán)利要求59所述的設(shè)備，其中，所述增益信息(rxGain)代表以0.5dB步進的期望增益。
61.一種計算機可讀介質(zhì)，包括存儲于其上的程序代碼，所述計算機可讀介質(zhì)包括 用于從射頻前端(RFFE)接收返回鏈路(RL)時間戳的程序代碼；用于從導(dǎo)航和定時系統(tǒng)接收系統(tǒng)時間秒的程序代碼；用于基于所述RL時間戳和所述系統(tǒng)時間秒生成前向鏈路(FL)時間戳的程序代碼；以及用于將所述FL時間戳和所述系統(tǒng)時間秒包括到時間數(shù)據(jù)中的程序代碼。
62.根據(jù)權(quán)利要求61所述的計算機可讀介質(zhì)，還包括用于將所述時間數(shù)據(jù)復(fù)用到采 樣流的程序代碼。
63.根據(jù)權(quán)利要求62所述的計算機可讀介質(zhì)，還包括用于發(fā)送所述采樣流的程序代碼。
64.根據(jù)權(quán)利要求61所述的計算機可讀介質(zhì)，其中，所述導(dǎo)航和定時系統(tǒng)是全球?qū)Ш?衛(wèi)星系統(tǒng)(GNSS)、俄羅斯GL0NASS(全球?qū)Ш叫l(wèi)星系統(tǒng))、歐盟的伽利略定位系統(tǒng)、印度區(qū)域 導(dǎo)航衛(wèi)星系統(tǒng)(IRNSS)或中國的北斗衛(wèi)星導(dǎo)航和定位系統(tǒng)中的一個。
65.根據(jù)權(quán)利要求61所述的計算機可讀介質(zhì)，其中，所述導(dǎo)航和定時系統(tǒng)是全球定位 系統(tǒng)(GPS)。
66.根據(jù)權(quán)利要求65所述的計算機可讀介質(zhì)，還包括用于將所述系統(tǒng)時間秒對準(zhǔn)到所 述全球定位系統(tǒng)的GPS時間的程序代碼。
67.根據(jù)權(quán)利要求61所述的計算機可讀介質(zhì)，還包括用于將時間戳計數(shù)器對準(zhǔn)到所述 系統(tǒng)時間秒的程序代碼。
68.根據(jù)權(quán)利要求61所述的計算機可讀介質(zhì)，對于IOMHz帶寬UMB頻分雙工(FDD)模 式，每1024次采樣寫入所述FL時間戳。
69.根據(jù)權(quán)利要求62所述的計算機可讀介質(zhì)，其中，所述FL時間戳進一步包括所述 采樣流所代表的當(dāng)前操作模式的信息。
70.一種計算機可讀介質(zhì)，包括存儲于其上的程序代碼，所述計算機可讀介質(zhì)包括 用于在存儲器中存儲增益信息和選通控制信息的程序代碼；以及用于執(zhí)行以下步驟之一的程序代碼a)發(fā)送第一期望時間戳和所述增益信息到射頻前端(RFFE)；b)發(fā)送第二期望時間戳和txEnable命令到發(fā)送選通控制；或者c)發(fā)送第三期望時間戳和rxEnable命令到接收選通控制。
71.根據(jù)權(quán)利要求70所述的計算機可讀介質(zhì)，還包括用于接收所述增益信息和所述 選通控制信息的程序代碼。
72.根據(jù)權(quán)利要求70所述的計算機可讀介質(zhì)，其中，所述發(fā)送選通控制和所述接收選通控制是所述射頻前端(RFFE)的一部分。
73.根據(jù)權(quán)利要求70所述的計算機可讀介質(zhì)，還包括用于執(zhí)行以下步驟中尚未執(zhí)行之 第二步驟的程序代碼a)發(fā)送所述第一期望時間戳和所述增益信息到所述射頻前端(RFFE)；b)發(fā)送所述第二期望時間戳和txEnable命令到所述發(fā)送選通控制；或者c)發(fā)送所述第三期望時間戳和rxEnable命令到所述接收選通控制。
74.根據(jù)權(quán)利要求73所述的計算機可讀介質(zhì)，還包括用于執(zhí)行以下步驟中尚未執(zhí)行之 最后步驟的程序代碼a)發(fā)送所述第一期望時間戳和所述增益信息到所述射頻前端(RFFE)；b)發(fā)送所述第二期望時間戳和txEnable命令到所述發(fā)送選通控制；或者c)發(fā)送所述第三期望時間戳和rxEnable命令到所述接收選通控制。
75.根據(jù)權(quán)利要求74所述的計算機可讀介質(zhì)，其中，所述發(fā)送選通控制和所述接收選 通控制是所述射頻前端(RFFE)的一部分。
76.根據(jù)權(quán)利要求70所述的計算機可讀介質(zhì)，其中，所述射頻前端(RFFE)的增益的改 變發(fā)生在基于所述增益信息的期望時間的+/_2微秒內(nèi)。
77.根據(jù)權(quán)利要求76所述的計算機可讀介質(zhì)，其中，所述期望時間是增益改變生效的 時間。
78.根據(jù)權(quán)利要求70所述的計算機可讀介質(zhì)，還包括用于將以下各項中的至少一項 復(fù)用到采樣流的程序代碼第一期望時間戳、第二期望時間戳、第三期望時間戳、增益信息、 txEnable 命令或 rxEnble 命令。
79.根據(jù)權(quán)利要求78所述的計算機可讀介質(zhì)，其中，所述增益信息(rxGain)定義為rxGain =四舍五入((Pout-Pin) *2)，其中，Pin是在天線端口處對接收功率的估計，Pout由下式給出Pout = 101og(o 2)其中，ο 2是所述采樣流的平均平方數(shù)字值。
80.根據(jù)權(quán)利要求79所述的計算機可讀介質(zhì)，其中，所述增益信息(rxGain)代表以 0. 5dB步進的期望增益。
全文摘要
用于采樣同步的裝置和方法，包括從射頻前端(RFFE)接收返回鏈路(RL)時間戳；從導(dǎo)航和定時系統(tǒng)接收系統(tǒng)時間秒；基于RL時間戳和系統(tǒng)時間秒生成前向鏈路(FL)時間戳；并將FL時間戳和系統(tǒng)時間秒包括到時間數(shù)據(jù)中。在一個方面，該裝置和方法用于進行RF控制，其包括在存儲器中存儲增益信息和選通控制信息；并執(zhí)行以下一個或多個步驟發(fā)送第一期望時間戳和增益信息到射頻前端(RFFE)；發(fā)送第二期望時間戳和txEnable命令到發(fā)送選通控制；或者發(fā)送第三期望時間戳和rxEnable命令到接收選通控制。
文檔編號H04W56/00GK101904205SQ200880121411
公開日2010年12月1日 申請日期2008年12月20日 優(yōu)先權(quán)日2007年12月20日
發(fā)明者S·烏帕拉 申請人:高通股份有限公司