zoukankan      html  css  js  c++  java
  • 测试

    UE的状态转换

    UE的状态转换图为:

    UE RRC State Machine

    UE RRC State Machine

    上面的多数状态都是瞬时的,一旦进入CONNECTED将不会切换回IDLE状态原因有三点:
      1. LTE-EPC模型专注于CONNECTED模式
      2. 无线链路故障没有被建模,因此不能由于无线链路故障而进入IDLE状态
      3. RRC目前的连接、释放既不是由EPC触发也不是由NAS触发

    详细建模IDLE原因有:
      1. 切换UE RRC配置实际需要,初始连接的建立的需要
      2. 将来更容易实现空闲模式小区选择

    初始单元选择

    时序图为:

    lte-cell-selection-timeline

    lte-cell-selection-timeline

    包含三部分: 单元搜索, 系统信息广播, 单元评估

    单元搜索

    小区搜索旨在检测周围的小区并测量来自这些小区中的每一个的接收信号的强度。

    测量基于所接收的PSS(Primary Synchronization Signal)的RSRP(Reference Signal Receiving Power, 参考信号接收功率), PSS由eNodeB通过DL信道的中心72个子载波发送, 因此将小区搜索建模为使用6个RB的DL带宽进行操作. 通过使用测量的RSRP, PHY实体能够生成检测到的小区列表, 每个小区都有其对应的小区ID和平均RSRP

    RRC实体检查报告并简单地选择具有最强RSRP的单元, 然后指示PHY实体与该特定单元同步. 此时单元的实际工作带宽仍然未知, 因此PHY实体仅侦听6个RB的最小带宽. 然而, PHY实体将能够从该特定eNodeB接收系统广播消息

    系统信息广播

    eNodeB以预定义的时间间隔向UE广播系统信息块,
      1. Master Information Block (MIB)
        包含与PHY层相关的参数, 这些参数是在小区配置期间生成, 并且在无线电帧开始时作为控制消息每隔10 ms进行广播
      2. System Information Block Type 1 (SIB1)
        包含有关网络访问的信息, 在无线电帧中间作为控制消息每20ms进行广播, 不用于手动附件方法. 并且UE必须先解码MIB后才能接收到SIB1
      3. System Information Block Type 2 (SIB2)
        包含UL和RACH相关设置, 计划在小区配置后16ms通过RRC协议进行传输, 然后每80ms重复一次(可通过LteEnbRrc::SystemInformationPeriodicity属性进行配置). UE必须驻留到一个单元后才能够收到它的该单元的SIB2

    单元评估

    UE RRC检查在小区搜索中产生的测量报告和由SIB1提供的小区接入信息, 对于一个特定的小区这两个信息一旦通过, UE就会触发评估过程. 这个过程的目的是确定该单元是否适合驻留

    评估标准简化为两个:
      1. Rx级别
      2. 封闭用户组

    第一个标准Rx级别基于单元的测量RSRP: Q_{rxlevmeas}必须大于 Q_{rxlevmin}, 即Q_{rxlevmeas}-Q_{rxlevmin}>0, 其中Q_{rxlevmin}由eNB决定, 并由UE通过SIB1获得

    第二个基本规则是UE不能驻留到具有不同CSG标识的eNodeB. 当该单元未通过CSG标准时, 则该单元被标记为可接受. 在这种情况下, UE RRC实体将告知PHY实体与第二最强小区同步并使用该小区重复初始小区选择过程. 只要没有找到合适的小区, UE将重复这些步骤, 与同时避免已被识别为可接受的小区

    当单元通过上述两个标准时, 该单元被认为是适合的. 然后UE驻留到其上, 此时转变为IDLE_CAMPED_NORMALLY

    此后, 上层可以请求UE进入CONNECTED

    无线接入控制

    eNB会维持附着到它的每个UE的状态, 并且每个UE的状态包含在UeManager类的实例中, 其状态转换图为:

    ENB RRC State Machine for each UE

    ENB RRC State Machine for each UE

    eNB RRC通过回复UE发送的RRC CONNECTION REQUEST信息来控制接入, 回复RRC CONNECTION SETUP表示接纳一个新的UE, RRC CONNECTION REJECT表示拒绝. 在目前的实现中, 这个行为是由ns3::LteEnbRrc::AdmitRrcConnectionRequest这个布尔值来决定. 目前还没有无线电接纳控制算法来动态地决定是否允许新的连接

    RRC时序图

    Sequence diagram of the RRC Connection Establishment procedure

    UE RRC State Machine

    有几个与此过程相关的超时时间列出在下表中. 如果这些定时器中的任何一个到期, 则RRC连接建立过程终止失败. 在这种情况下, 上层(UE NAS)将立即尝试重试该过程, 直到它成功完成

    Sequence diagram of the RRC Connection Establishment procedure
    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协议模型

    RRC消息的发送和接收提供了两种不同的协议模型: 理想协议模型(Ideal RRC protocol model)和实际协议模型(Real RRC protocol model)

    理想协议模型

    协议在类LteUeRrcProtocolIdealLteEnbRrcProtocolIdeal中实现, 所有RRC消息和信息元素以理想的方式在eNB和UE之间传输, 而不消耗无线电资源且没有错误. 从实现的角度来看, 这是通过在UE和eNB RRC实体之间直接传递RRC数据结构来实现的, 而不涉及较低层(PDCP, RLC, MAC, scheduler)

    实际协议模型

    协议在类LteUeRrcProtocolRealLteEnbRrcProtocolReal中实现, 并且旨在建模在实际LTE系统中执行的RRC PDU的传输. 特别是:

    1. 对于正在发送的每个RRC消息, 在RRC PDU和信息元素(IE)经过ASN.1编码之后创建真实RRC PDU
    2. 编码的RRC PDU在信令无线电承载上发送, 并且受到用于数据通信的相同传输建模的影响, 因此包括调度, 无线电资源消耗, 信道错误, 延迟, 重传等

    测试程序

    lte-rrc测试程序检测以下方面:
      - MAC层随机接入
      - RRC系统信息的获取
      - RRC连接的建立
      - RRC重新配置

    测试程序场景

    4个eNB在边长为100米的正方形边上, 对称分布. 多个UE位于对角线上特定位置, 并且连接到第一个eNB上, 每个测试用例指定如下参数:
      1. UE的数量
      2. 每个UE激活的无线承载数量
      3. 第一个UE连接到eNB的时间t_ConnBase
      4. UE连接eNB的时间间隔, 即每个第N个UE连接的时间为t_ConnBase + t_ConnIncrPerUe * N
      5. UE在正方形对角线上的相对位置, 距离连键到的eNB距离越大, 来自其他eNB的干扰越大
      6. 一个指示位指示所用的协议是理想协议模型还是真实协议模型

    完成连接所用的时间为: m_delayConnEnd = dsi + dra + dce + dcr, 其中:
      dsi 接收系统信息所用时间, 共90ms, 其中10ms用于获取MIB, 80ms用于获取SIB2
      dra 随机接入过程的所用的时间, 取决于前导码冲突数量以及UL授权分配的资源可用性. 前导码冲突数量取决于同时访问UE的数量, 为保证99%随机接入成功率, 对于多达20个UE时使用5次尝试, 多达50个UE时, 使用10次尝试. UL授权分配取决于系统带宽和MCS(0)调制方式, 最多可有4个UL授权在一个TTI内, 因此, 对于尝试同时进行RA的UE, 由于UL授权问题导致的最大尝试次数是[n/4]. 接入时间是3+3(接收随机访问响应时长)+1(用于调度新的的传输)
      dce 传输RRC CONNECTION SETUP + RRC CONNECTION SETUP COMPLETED所用时间必须使用2个RRC分组用于传输, 并且每个TTI最多传输4个这样的分组, 所以用时为[2n/4], 再加上往返用时10ms. 当干扰较高时, UE会进行一次重新尝试, 此时dce加倍, 然后在加上dsi(由于超时已重置先前接收到的SIB2)
      dcr RRC CONNECTION RECONFIGURATION事务所需时间. 每个承载激活所需的事务数量为1. 时间处理和dce类似, 对于每次传输为10ms加上[2n/4]. 延时为20ms

    测试通过条件

    测试类(LteRrcConnectionEstablishmentTestCase)在没有信道错误的情况下测试正确的RRC连接建立, 测试通过条件为:
      1. UE处RRC状态在CONNECTED_NORMALLY
      2. UE配置的CellId、DlBandwidth, UlBandwidth, DlEarfcn和UlEarfcn与所连接的eNB一直
      3. eNB存储UE的IMSI是正确的
      4. 在eNB和UE处, 活动数据无线电承载的数量是预期的数据无线电承载
      5. 对于每个数据无线电承载, UE和eNB之间的以下标识符匹配: EPS承载id, DRB id, LCID

    测试类(LteRrcConnectionEstablishmentErrorTestCase)除了在第一次连接尝试期间选择的特定RRC消息的传输中存在错误之外, 其他方面和之前测试类类似. 错误是由于临时将UE移动到较远位置来获得的; 移动的时间是基于希望出错的而确定。测试用例在UE移回原始位置之前检查到以下条件中的至少一个是错误的:
      1. UE处RRC状态在CONNECTED_NORMALLY
      2. 在eNB处存在UE的context
      3. eNB处存放UE的context是CONNECTED_NORMALLY

    NS_TEST_ASSERT_MSG_EQ()
    NS_ASSERT_MSG()

  • 相关阅读:
    LeetCode——Reverse Integer
    多校第一场 费马小定理+模拟+组合数学
    Oracle 物理和逻辑备库健康监測的一个根据
    UFLDL教程笔记及练习答案三(Softmax回归与自我学习***)
    MAC上Nuclide的安装
    free命令具体解释——Linux性能分析
    不同浏览器对于html5 audio标签和音频格式的兼容性
    如何在 Internet Explorer 11中开启 WebGL
    Cocos2d-html5帧动画
    Cocos开发前准备
  • 原文地址:https://www.cnblogs.com/hesper/p/9928446.html
Copyright © 2011-2022 走看看