RRC

特點

RRC模型在模擬器中提供以下功能

• 生成(在eNB中)和解釋(在UE中)信息塊(尤其是MIB和SIB1, SIB2)
  
• 初始化小區選擇
  
• RRC連接建立過程
  
• RRC重新配置程序, 支持以下方式: 重新配置SRS配置索引 + 重新配置PHY TX模型(MIMO) + 重新配置UE測量值 + 數據無線承載裝置 + 切換
  
• RRC的連接重建, 支持使用方式: 切換

結構

RRC模型分為以下組成部分:

• RRC實體是: LteUeRrc和LteEnbRrc, 這兩個分別在UE和eNB處實現RRC的狀態機制
  
• RRC的SAP有LteUeRrcSapProvider, LteUeRrcSapUser, LteEnbRrcSapProvider, LteEnbRrcSapUser它們允許RRC實體發送和接收RRC消息和信息部分
  
• RRC協議類有兩種不同的模型用來傳輸RRC消息, 分別是LteUeRrcProtocolIdeal, LteEnbRrcProtocolIdeal, LteUeRrcProtocolReal, LteEnbRrcProtocolReal

除此之外，RRC組件使用各種其他SAPs來與協議棧的其余部分進行交互。以下連接中提供了所有SAPs表現形式LTE radio protocol stack architecture for the UE on the data plane, LTE radio protocol stack architecture for the UE on the control plane, LTE radio protocol stack architecture for the eNB on the data plane and LTE radio protocol stack architecture for the eNB on the control plane.

UE RRC State Machine

下圖展示了UE RRC實體的狀態轉換機制

需要指出的是, 大多數狀態是暫時的, 即, 一旦UE進入連接狀態, 他將不會切換會任何的IDLE狀態. 這麽做有如下幾點原因:

• 正如在設計準則中所闡述的那樣, LTE-EPC仿真模型專註於CONNECTED模式
  
• 無線鏈路故障暫時沒有建模, 正如在Radio Link Failure中所討論的那樣, UE不能由於無線電鏈路故障而進入IDLE模式
  
• RRC目前的連接釋放既不是由EPC觸發, 也不是由NAS觸發

然而, 我們仍然選擇詳細的建模IDLE狀態是因為:

• 對於切換來講, 一個真實的UE RRC配置是一個必要的特性, 並且為了有一個更清晰的實現, 在初始連接建立時使用相同的UE RRC配置是有意義的
  
• 它將使空閑模式單元選擇變得更加泳衣, 這是一個非常理想的特性

ENB RRC State Machine

eNB RRC維持著每個連接到該單元的UE. 從實現的角度來看, 每個UE的狀態都被包含在了UeManager類中. 狀態機制如下圖

Initial Cell Selection

初始單元選擇是一個空閑模式的過程, 當UE沒有駐留或附著到eNB時執行此過程. 該過程的目的是為了找到一個適合的單元並附著到其上以通過對蜂窩網絡的接入.

這通常是在模擬開始時所完成, 正如下圖(初始單元選擇和時間相關事件)所展示一樣. 上面的部分是初始單元選擇在第一次就成功, 下圖是首次未成功並在第二次嘗試時成功. 該時序假定使用的是真實的RRC協議棧模型(RRC protocol models)並且沒有傳輸錯誤.

該模型是基於3GPP IDLE模式規範, 如在[TS36300], [TS36304], 和[TS36331]中. 然而, 在模擬器中IDLE模型的仍然缺少正確的實現, 因此我們保留了幾個簡化的假設:

• 不支持多載波頻率
  
• 不支持多個公共陸地移動網絡(PLMN)標識(即多個網絡運營商)
  
• RSRQ值未被使用
  
• 不支持存儲的信息單元格選擇
  
• "Any Cell Selection"和駐留到一個可接收的單元並未被支持
  
• 不支持將單元標記為禁止或保留
  
• 不支持單元重新選擇, 因此當初始單元選擇發生後UE不可能駐留到不同的單元, 並且
  
• UE的閉合用戶組(CSG)白名單僅包含一個CSG標識

另外值得註意的是初始單元選擇僅使用於EPC啟動的模擬. 僅LTE模擬必須選擇手動附著方法. 關於其他使用的更多信息請參考用戶文檔的Network Attachment部分

下一小節將介紹初始單元選擇的不同部分，即單元搜索、系統信息廣播和單元選擇評估。

Cell Search

小區搜索旨在檢測周圍的單元並測量來自這些單元中的每一個接收的信號的強度. 其中一個單元將成為UE加入蜂窩網絡的入口點.

測量值是基於即受到的PSS中的RSRP, 由第一層過濾, 並且由PHY層來執行, 正如先前在 UE PHY Measurement Model中所詳盡描述的那樣. PSS由eNodeB通過DL信道的中心72個子載波發送([TS36300]), 因此, 我們將小區搜索建模為使用6個RB的DL帶寬進行操作. 值得註意的是RSRQ在模擬器開始時並不能被獲得. 所以, 單元搜索時, LteUePhy::RsrqUeMeasThreshold屬性並不應用.

通過使用RSRQ, PHY實體可以生成一張已搜索到的單元列表, 每個都有其對應的單元ID和相應的相應的平均RSRQ. 該列表通過CPHY SAP周期性地推送到RRC實體作為測量報告

RRC實體檢查報告並簡單地選擇具有最強RSRP的小區, 如[TS36304]的第5.2.3.1節所示. 然後, 它指示PHY實體與該特定單元同步. 此時單元的實際工作帶寬仍然未知, 因此PHY實體僅偵聽6個RB的最小帶寬. 然而, PHY實體將能夠從這個特定的eNodeB接收系統廣播消息，這是下一小節的主題.

Broadcast of System Information

系統信息塊由eNodeB以預定義的時間間隔向UE廣播, 改編自[TS36331]的第5.2.1.2節. 支持的系統信息塊有:

• Master Information Block(MIB)
  
• 　　包含與PHY層相關的參數, 這些參數在小區配置期間生成, 並在無線電幀開始時每隔10 ms作為控制消息廣播
  
• System Information Block Type 1(SIB1)
  
• 　　包含有關網絡訪問的信息, 在無線電幀中間每20毫秒作為控制消息廣播. 不能用於手動附件方法. UE必須先解碼MIB才能接收到SIB1
• System Information Block Type 2(SIB2)
• 　　包含UL和RACH相關設置, 計劃在小區配置後16ms通過RRC協議進行傳輸, 然後每80ms重復一次（可通過LteEnbRrc::SystemInformationPeriodicity屬性進行配置. UE必須駐留到一個小區才能夠收到它的SIB2。

系統信息的接收是UE在生命周期中發展的基礎. MIB能夠使UE初始配置的6個RBs的下行帶寬擴展到實際所操作的帶寬. SIB1提供單元選擇評估所需的信息(將在下一小節中進行解釋). 最後, 在允許UE切換到CONNECTED狀態之前, 需要獲得SIB2。

Cell Selection Evaluation

UE RRC檢查單元搜索中生成的測量報告和SIB1提供的單元訪問信息. 一旦對於一個特定的單元這兩個信息都可以獲得到, UE即開始觸發評估過程. 這個過程的目的是判斷這個單元是否適合駐留.

評估過程是[TS36304]第5.2.3.2節的略微簡化版本. 它包含以下標準:

• Rx等級標準
  
• 封閉用戶組(CSG)標準

第一個Rx等級標準是基於單元RSRP測量值: Q_{rxlevmeas}, 這個值必須大於所要求的最小值Q_{rxlevmin}. 即Q_{rxlevmeas} - Q_{rxlevmin} > 0, 其中Q_{rxlevmin}是由UE從每個eNodeN的SIB1中獲取的.

最後一個標準CSG, 他是由被稱為CSG指示的true-or-false參數和簡單數字CSG標識的組合. 基本規則是UE不能駐留到具有不同CSG標識的eNodeB. 但是, 只有當CSG指示被視為真實時, 才會強制執行此規則. 更多細節參見用戶文檔Network Attachment

當一個單元通過上述的所有標準後, 這個單元被視為合適的. 然後UE會駐留到這個單元中(即轉變為IDLE_CAMPED_NORMALLY狀態)

在這之後, 上層會要求UE進入CONNECTED模式. 更多細節見RRC connection establishment

另一方面, 當著個單元沒有通過CGS標準時, 該單元就會被標註為acceptable(Section 10.1.1.1 [TS36300]). 這種情況下, RRC實體會讓其PHY實體同步到第二個最強的單元, 並使用該單元重復初始單元選擇過程. 只要沒有合適的單元被發現, 這個UE將會重復執行上述過程, 與此同時將會避開那些別標準為acceptable的單元.

Radio Admission Control

eNB RRC通過回復UE發送的RRC CONNECTION REQUEST信息的RRC CONNECTION SETUP或 RRC CONNECTION REJECT來支持無線接納控制, 判斷是否接納一個新的UE. 在目前的實現中, 這個行為是由ns3::LteEnbRrc::AdmitRrcConnectionRequest這個布爾值來決定. 目前沒有無線電接納控制算法可動態地決定是否允許新的連接

Radio Bearer Configuration

在RRC中已經就無線電承載的建立做出了一些實現選擇:
　　根據以下策略，配置三個邏輯信道組（四個可用）用於上行鏈路緩沖區狀態報告:
　　　　LCG 0用於信令無線電承載
　　　　LCG 1用於GBR數據無線電承載
　　　　LCG 2用於非GBR數據無線電承載

Radio Link Failure

由於在此階段RRC僅支持CONNECTED模式, 因此不處理無線鏈路故障(RLF). 原因是RLF(當RRC重新建立失敗時)的可能結果之一是離開RRC CONNECTED通知NAS RRC連接失敗. 為了適當地建模RLF, 應該支持RRC空閑模式, 包括特別是空閑模式小區(重新)選擇

目前的模型中, 當一個UE有著較壞的連接質量並且沒有切換(即沒有相鄰的單元, 或切換失敗, 或切換閥值配置錯誤), 它將會繼續保持和同一個eNB進行聯系, 然而調度器將會停止分配傳輸資源

UE RRC Measurement Model

UE RRC Measurements support

UE RRC實體為UE測量提供支持, 特別地, 它執行了[TS36331]第5.5節所述的程序, 但有以下簡化假設:

• 僅支持E-UTRA頻率內測量, 這意味著:
  
• 　　仿真過程中只使用一個測量對象　　
• 　　測量間隙不需要進行測量　　
• 　　事件B1和B2未實現　　
• 僅支持reportStrongestCells用途，而不支持reportCGI和reportStrongestCellsForSON用途　　
• 不支持s-Measure　　
• 現階段, LTE模塊支持載波聚合, 未實現事件A6
  
• 不支持速度相關的觸發時間縮放（[TS36331]的第5.5.6.2節）

Overall design

該模型基於UE測量消費者的概念, UE測量消費者是可以請求eNodeB RRC實體提供UE測量報告的實體. 消費者例如是切換算法, 其基於UE測量報告來計算切換決定。測試用例和用戶程序也可能成為消費者. 圖Relationship between UE measurements and its consumers描述了這些實體之間的關系。

RRC級別的整個UE測量功能分為4個主要部分:

1. Measurement configuration (handled by LteUeRrc::ApplyMeasConfig)
   
2. Performing measurements (handled by LteUeRrc::DoReportUeMeasurements)
   
3. Measurement report triggering (handled by LteUeRrc::MeasurementReportTriggering)
   
4. Measurement reporting (handled by LteUeRrc::SendMeasurementReport)

接下來的小結將會闡述以上4個部分

Measurement configuration

一個eNodeB RRC實體通過發送配置參數到UE RRC實體來配置UE測量. 該組參數在RRC連接重新配置消息（RRC連接重新配置）的MeasConfig信息元素（IE）內定義。

eNodeB RRC實體實現[TS36331]的第5.5.2節中描述的配置參數和過程，具有以下簡化假設：

• 配置（即添加，修改和刪除）只能在模擬開始之前完成
  
• 連接到eNodeB的所有UE將以相同的方式配置，即不支持為特定UE配置特定測量; 並且
  
• 假設在PCI和E-UTRAN全局小區標識符(EGCI)之間存在一對一映射. 這與UE PHY Measurements Model中描述的PCI建模假設一致。

這裏的eNodeB RRC實例充當消費者和所連接的UE之間的中介.在模擬開始時, 每個使用者向eNodeB RRC實例提供所需的UE度量配置. 然後, eNodeB RRC將配置分發給附加的UEs.

用戶可以使用多種方法自定義測量配置. 有關這些方法的說明, 參閱Configure UE measurements一節

Performing measurements

UE RRC周期性地從UE PHY接收RSRP和RSRQ測量，如UE PHY Measurements Model所述. 第3層過濾將應用於這些接收的測量. 過濾的實現遵循[TS36331]的第5.5.3.2節:

F_n = (1 - a) × F_{n-1} + a × M_n

其中:

• M_n是物理層最新收到的測量結果
  
• F_n是更新的過濾測量結果
  
• F_{n-1}是舊的過濾測量結果, 這裏F_0 = M_1(即第一次測量值沒有被過濾); 並且
  
• a = (1/2)^(k/4), 這裏的k是QuantityConfig提供的可配置filterCoefficent

k = 4是默認值, 但可以通過在LteEnbRrc中設置RsrpFilterCoefficient和RsrqFilterCoefficient屬性來配置.
因此當k = 0將禁用第3層過濾. 另一方面，過去的測量可以通過使用更大的k值來擴大對過濾結果的影響

Measurement reporting triggering

在該部分中, UE RRC將通過有效測量配置列表並根據[TS36331]的第5.5.4節檢查是否滿足觸發條件. 當滿足來自所有有效測量配置的至少一個觸發條件時, 將啟動測量報告過程（在下一小節中描述）。

3GPP定義了兩種triggerType: periodical and event-based. 目前只有event-based標準被支持. 支持的基於事件的觸發條件列表如下

在基於事件的觸發器中要檢查的兩個主要條件是進入條件和離開條件。關於這兩者的更多細節可以在[TS36331]的第5.5.4節中找到

通過引入滯後和觸發時間來進一步配置基於事件的觸發器. 滯後(H_ys)定義進入和離開條件之間的距離，單位為dB. 類似地, 觸發時間引入進入和離開條件的延遲, 但是作為一個時間單位。

不支持定期類型的報告觸發器, 但可以使用基於事件的觸發器輕松獲取其行為. 這可以通過以始終滿足進入條件的方式配置測量來完成, 例如通過將事件A1的閾值設置為0(最小級別). 因此, 測量報告將始終在每個特定時間間隔觸發, 時間間隔由LteRrcSap::ReportConfigEutra中的reportInterval字段確定, 因此產生與定期報告相同的行為

作為關於3GPP規範的限制, 當前模型不支持任何特定於小區的配置. 這些配置參數在測量對象中定義. 因此, 不支持將黑色單元列表合並到觸發過程中.此外, 也不支持小區特定的偏移(即, Q_cn和Q_cp在事件A3, A4和A5中). 始終假定值為0來代替它們

Measurement reporting

該部分處理通過RRC協議從UE RRC實體向服務eNodeB實體提交測量報告. 采用了幾種簡化假設:

• reportAmount不適用（即始終假定為無限
  
• 在測量報告中, 始終假定reportQuantity為BOTH, 即, 無論triggerQuantity如何, 始終都會報告RSRP和RSRQ

Handover

Handover algorithm

No-op handover algorithm

A2-A4-RSRQ handover algorithm

Strongest cell handover algorithm

Neighbour Relation

LTE模塊支持簡化的自動鄰居關系(ANR)功能. 這由LteAnr類處理, 該類通過ANR SAP接口與eNodeB RRC實例交互

Neighbour Relation Table

ANR保持鄰居關系表(Neighbour Relation Table NRT)，類似於[TS36300]的第22.3.2a節中的描述. 表中的每個條目稱為鄰居關系(Neighbour Relation NR), 表示檢測到的相鄰單元, 其中包含以下布爾字段:

• No Remove
  
• 　　表示不應從NRT中刪除NR. 對於用戶提供的NR, 默認情況下為true, 否則為false
  
• No X2
• 　　表示NR不應使用X2接口來啟動針對目標小區的eNodeB的過程. 對於用戶提供的NR. 默認為false, 否則為true
  
• No HO
• 　　表示由於切換原因, eNodeB不會使用NR. 在大多數情況下都是如此, 除非NR是用戶提供的並且是網絡檢測的

每個NR條目可能至少具有以下屬性中的一個:

• User-provider
  
• 　　這種類型的NR是按照模擬用戶的指示創建的. 例如, 在用戶發起的2個eNodeB之間建立X2連接時自動創建NR, 例如, 如X2-based handover中所述. 創建用戶提供的NR的另一種方法是顯式調用AddNeighbourRelation函數
  
• Network-detected
  
• 　　由於發現附近的小區，在模擬期間自動創建這種類型的NR

為了自動創建網絡檢測到的NR, ANR利用UE測量. 換句話說, ANR是UE測量的消費者, 如圖Relationship between UE measurements and its consumers. RSRQ和事件A4(鄰居變得優於閾值)用於報告配置. 默認事件A4閾值設置為可能的最低值, 即最大檢測能力, 但可以通過設置LteAnr類的Threshold屬性來更改. 註意, A2-A4-RSRQ切換算法也使用類似的報告配置. 盡管相似, 但當ANR和該切換算法在eNodeB中都是活動的時, 它們使用單??獨的報告配置

另請註意, 不支持自動設置X2接口. 這就是為什麽在檢測到網絡但不是用戶檢測到的NR中, No X2和No HO字段為真的原因

Role of ANR in Simulation

ANR SAP接口提供ANR和eNodeB RRC之間的通信方法. eNodeB RRC使用一些接口函數與NRT交互, 如下所示:

• AddNeighbourRelation
  
• 　　(eNodeB RRC --> ANR)將新的用戶提供的NR條目添加到NRT中
• GetNoRemove
  
• 　　(eNodeB RRC --> ANR)獲取給定單元ID的NR條目的No Remove字段的值。
• GetNoHo
  
• 　　(eNodeB RRC --> ANR)獲取給定小區ID的NR條目的No HO字段的值
• GetNoX2
  
• 　　(eNodeB RRC --> ANR)獲取給定單元ID的NR條目的No X2字段的值

存在其他接口功能以支持ANR作為UE測量消費者的角色，如下所示:

• AddUeMeasReportConfigForAnr
  
• 　　由ANR用於通過傳遞期望的報告配置來請求來自eNodeB RRC實體的測量報告. 該配置將應用於所有未來連接的UE.
• ReportUeMeas
  
• 　　基於之前在AddUeMeasReportConfigForAnr中配置的UE測量, UE可以向eNodeB提交測量報告, eNodeB RRC實體使用ReportUeMeas接口將這些測量報告轉發給ANR

有關用法和所需參數的更多詳細信息, 請參閱LteAnrSap類的相應API文檔

ANR被eNodeB RRC實例用作數據結構以跟蹤附近相鄰小區的情況. ANR還幫助eNodeB RRC實例確定是否可以執行到相鄰小區的切換過程. 這通過如下方法來實現: 如果目標小區的NR條目具有No HO和No X2字段都設置為假, 則eNodeB RRC將僅允許發生切換過程

默認情況下, 在模擬中的每個eNodeB實例中啟用ANR. 可以通過將LteHelper類中的AnrEnabled屬性設置為false來禁用它

RRC sequence diagrams

在本節中, 我們提供了一些序列圖, 用於解釋正在建模的最重要的RRC過程

RRC connection establishment

圖Sequence diagram of the RRC Connection Establishment procedure表示了如何建模RRC連接建立過程, 突出顯示RRC層在UE和eNB處的角色, 以及與其他層的交互

有幾個與此過程相關的超時, 超時時間在Timers in RRC connection establishment procedure列出. 如果這些定時器中的任何一個到期, 則RRC連接建立過程終止失敗. 在這種情況下, 上層(UE NAS)將立即嘗試重試該過程, 直到它成功完成

RRC connection reconfiguration

圖Sequence diagram of the RRC Connection Reconfiguration procedure表示了如何針對未提供MobilityControlInfo的情況(即, 不執行切換)對RRC連接重新配置過程進行建模

圖Sequence diagram of the RRC Connection Reconfiguration procedure for the handover case表示了如何針對提供MobilityControlInfo的情況建模RRC連接重新配置過程, 即, 要執行切換. 如[TS36331]中所規定的, 在接收到切換消息之後, UE嘗試根據在[TS36321]中定義的隨機接入資源選擇在第一可用RACH時機訪問目標小區, 即切換是異步的. 因此, 當在目標小區中為隨機接入分配專用前導碼時, E-UTRA應確保其可從UE可能使用的第一RACH時機獲得. 在成功完成切換後, UE發送用於確認切換的消息. 註意, 在這種情況下的隨機接入過程是基於非競爭的，因此在真實的LTE系統中, 它與在建立的RRC連接中使用的略有不同. 還要註意, 通過從目標eNB發送到源eNB的X2切換請求ACK消息中包括的切換命令來發信號通知RA前導ID; 特別地, 前導碼包含在RACH-ConfigDedicated IE中, 它是MobilityControlInfo的一部分

RRC protocol models

如前所述, 我們為RRC消息的傳輸和接收提供了兩種不同的模型: Ideal和Real. 它們中的每一個都在以下小節描述.

Ideal RRC protocol model

根據該類型, 在類和LteUeRrcProtocolIdeal和LteEnbRrcProtocolIdeal中實現, 所有RRC消息和信息元素以理想的方式在eNB和UE之間傳輸, 而不消耗無線電資源且沒有錯誤. 從實現的角度來看, 這是通過在UE和eNB RRC實體之間直接傳遞RRC數據結構來實現的, 而不涉及較低層(PDCP, RLC, MAC, 調度器)

Real RRC protocol model

該模型在類LteUeRrcProtocolReal和LteEnbRrcProtocolReal中實現, 並且旨在建模通常在真實LTE系統中執行的RRC PDU的傳輸. 特別是:

• 對於正被發送的每個RRC消息, 在[TS36331]中指定的RRC PDU和信息元素(IE)的ASN.1編碼之後創建真實RRC PDU. 對於包括在PDU中的IE進行了一些簡化, 即, 僅包括那些對於模擬目的有用的IE. 有關詳細列表, 請參閱lte-rrc-sap.h中定義的IE並與[TS36331]進行比較
  
• 編碼的RRC PDU在信令無線電承載上發送, 並且受到用於數據通信的相同傳輸建模的影響, 因此包括調度, 無線電資源消耗, 信道錯誤, 延遲, 重傳等

Signaling Radio Bearer model

現在開始描述用於Real RRC協議模型的信令無線電承載模型

SRB0 消息(CCCH承載):

• RrcConnectionRequest: 在實際LTE系統中, 這是在RAR中的UL Grant中指定的資源上發送的RLC TM SDU(不在UL DCI中); 原因是現階段C-RNTI還不知道. 在模擬器中, 這被建模為真實的RLC TM RLC PDU, 其UL資源在調用SCHED_DL_RACH_INFO_REQ時由調度器分配
  
• RrcConnectionSetup: 在模擬器中, 這在實際LTE系統中實現, 即, 在由常規UL DCI指示的資源上發送的RLC TM SDU, 由在映射到LCID 0(CCCH)的RLC TM實例觸發的SCHED_DL_RLC_BUFFER_REQ分配

SRB1消息(DCCH承載):

• 在模擬器中建模的所有SRB1消息（例如，RrcConnectionCompleted）如在真實LTE系統中那樣實現，即，使用通過緩沖器狀態報告分配的DL資源在RLC AM上發送的真實RLC SDU. 有關詳細信息, 參閱RLC模型文檔

SRB2消息(DCCH承載):

• 根據[TS36331], "SRB1用於RRC消息(其可以包括搭載的NAS消息)以及用於在建立SRB2之前的NAS消息, 全部使用DCCH邏輯信道", 而“SRB2用於NAS消息, 使用DCCH邏輯信道", "SRB2的優先級低於SRB1，並且在安全激活後始終由E-UTRAN配置". 建模安全相關方面不是LTE仿真模型的要求, 因此我們總是使用SRB1並且從不激活SRB2

ASN.1 encoding of RRC IE’s

RRC SAP中定義的消息(對所有Ue/Enb SAP user/provider來說是通用的)在透明容器中傳輸到Ue/Enb或從Ue/Enb傳輸. 不同信息單元的編碼格式在[TS36331]中指定, 在未對齊變體中使用ASN.1規則. Ns3/Lte中的實現分為以下幾類:

• Asn1Header: 包含基本ASN類型的編碼/解碼
  
• RrcAsn1Header: 繼承Asn1Header並包含[TS36331]中定義的常見IE的編碼/解碼
  
• Rrc specific messages/IEs classes: RRC SAP標頭中定義的每個消息的類

Asn1Header class - Implementation of base ASN.1 types

根據ITU-T X.691中的打包編碼規則, 該類實現了序列化/反序列化[TS36331]中使用的ASN.1類型的方法. 考慮的類型是:

• Boolean: 一個使用一個bit的布爾值(1=true, 0=false)
  
• Integer: 約束整數(定義了最小值和最大值)使用最小位數來編碼其範圍(max-min + 1)
  
• Bitstring: 雙字符串將逐位復制到序列化緩沖區
  
• Octetstring: 目前尚未使用
  
• Sequence: 序列生成一個前導碼, 指示是否存在可選字段和默認字段. 它還添加了一個指示擴展標記存在的位.
  
• Sequence...Of: 類型序列...將序列的元素數量編碼為整數(後續元素需要在之後編碼)
  
• Choice: 指示正在編碼選擇集中的哪個元素
  
• Enumeration: 序列化為一個整數，指示在枚舉中使用的值, 枚舉中的元素數作為上限
  
• Null: 雖然定義了序列化函數以在規範和實現之間提供更清晰的映射，但是不對null值進行編碼

該類繼承自ns-3 Header, 但Deserialize()函數被聲明為純虛擬, 因此繼承的類必須實現它. 原因是反序列化將檢索RRC消息中的元素, 每個元素包含不同的信息元素.

另外, 必須註意, 並且由於優化的編碼, 特定類型/消息的結果字節長度可以根據可選字段的存在而變化. 因此, 序列化的位將使用PreSerialize()函數進行處理, 將結果保存在m_serializationResult Buffer中. 由於ns3緩沖區中的讀/寫方法是以字節為基礎定義的, 因此序列化位存儲在m_serializationPendingBits屬性中, 直到設置了8位並且可以寫入緩沖區叠代器. 最後, 在調用Serialize()時, m_serializationResult屬性的內容將被復制到Buffer::Iterator參數

RrcAsn1Header : Common IEs

由於一些信息元素被用於多個RRC消息，因此該類實現了以下常見的IE:

• SrbToAddModList
  
• DrbToAddModList
  
• LogicalChannelConfig
  
• RadioResourceConfigDedicated
  
• PhysicalConfigDedicated
  
• SystemInformationBlockType1
  
• SystemInformationBlockType2
  
• RadioResourceConfigCommonSIB

Rrc specific messages/IEs classes

以下RRC SAP已實施:

• RrcConnectionRequest
  
• RrcConnectionSetup
  
• RrcConnectionSetupCompleted
  
• RrcConnectionReconfiguration
  
• RrcConnectionReconfigurationCompleted
  
• HandoverPreparationInfo
  
• RrcConnectionReestablishmentRequest
  
• RrcConnectionReestablishment
  
• RrcConnectionReestablishmentComplete
  
• RrcConnectionReestablishmentReject
  
• RrcConnectionRelease

Lte Design Documentation之RRC