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个主要部分:
- Measurement configuration (handled by LteUeRrc::ApplyMeasConfig)
- Performing measurements (handled by LteUeRrc::DoReportUeMeasurements)
- Measurement report triggering (handled by LteUeRrc::MeasurementReportTriggering)
- 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标准被支持. 支持的基于事件的触发条件列表如下
| Name | Description |
| Event A1 | Serving cell becomes better than threshold |
| Event A2 | Serving cell becomes worse than threshold |
| Event A3 | Neighbour becomes offset dB better than serving cell |
| Event A4 | Neighbour becomes better than threshold |
| Event A5 | Serving becomes worse than threshold1 AND neighbour becomes better than threshold2 |
在基于事件的触发器中要检查的两个主要条件是进入条件和离开条件。关于这两者的更多细节可以在[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)将立即尝试重试该过程, 直到它成功完成
| Name | Location | Timer starts | Timer stops | Default duration | When timer expired |
| Connection request timeout | eNodeB RRC | New UE context added | Receive RRC CONNECTION REQUEST | 15 ms | Remove UE context |
| Connection timeout (T300 timer) | UE RRC | Send RRC CONNECTION REQUEST | Receive RRC CONNECTION SETUP or REJECT | 100 ms | Reset UE MAC |
| Connection setup timeout | eNodeB RRC | Send RRC CONNECTION SETUP | Receive RRC CONNECTION SETUP COMPLETE | 100 ms | Remove UE context |
| Connection rejected timeout | eNodeB RRC | Send RRC CONNECTION REJECT | Never | 30 ms | Remove UE context |
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