 |
善于提问，勤于回答，你也是专家
|
 |
请问TD出现“完整性检查错误导致RRC释放”是什么原因导致？
请问TD大唐出现“完整性检查错误导致RRC释放”导致掉线是什么原因？
我要回答
问题答案
这个释放原因值不是正常值：
正常的原因值如下：
RRC释放原因：
normal event 正常释放（比如手动断开连接）
unspecified 不确定性因素导致的释放
pre-emptive release 信道抢占引起的释放
re-establishment reject 链路重建拒绝
user inactivity 用户不在活动状态或者处于非激活状态
directed signalling connection reestablishment 直传信令的连接重建
楼主说的这个问题解释如下：
1.1.1
RRC连接建立包括SRB1的建立。在完成S1连接建立之前，也即是在从EPC接收到UE上下文信息之前，E-UTRAN会完成RRC连接建立。因此，在RRC连接的初始化阶段AS的安全性还没被激活，但E-UTRAN可能配置UE来执行测量报告。然而，在安全性被激活的时候UE只会接受到一个切换消息。
在从EPC接收到UE上下文之后，E-UTRAN通过初始安全性激活进程来激活安全性（也即是加密和完整性保护）。用于激活安全性的RRC消息（命令和成功响应）是进行了完整性保护的，而加密必须在安全性激活进程完成之后启动。也就是说，用于响应激活安全性的消息是没被加密的，而随后的消息（比方说，用于建立SRB2和DRBs）被完整性保护和加密。
在初始化了初始安全性激活进程之后，E-UTRAN发起SRB2和DRBs的建立，也就是即E-UTRAN可能在收到UE初始安全性激活的确认之前开始。不管怎样，E-UTRAN都会对用于建立SRB2和DRBs的RRC连接重配置消息进行加密和完整性保护。如果初始化安全性激活和/或者无线承载建立失败的话，E-UTRAN应该释放RRC连接（也即是，安全性激活和DRB的建立是由一个联合的S1过程触发的，这个过程不支持部分的成功）。
对于SRB2和DRBs，安全性总是从一开始就被激活的，即E-UTRAN不会在激活安全性之前建立这些承载。
RRC连接的释放是由E-UTRAN发起的。这个过程可以用来把UE重新引导到另一个频率上或者是其它的RAT。在一些特殊情况下，UE可能直接中止RRC连接，也即是不通知E-UTRAN就转移到RRC_IDLE状态。
1.1.2
AS安全性由RRC信令（SRBs）的完整性保护以及RRC信令和用户数据（DRBs）的的加密组成。
RRC负责处理安全性参数的配置，这些配置是属于AS配置的一部分：完整性保护算法、加密算法以及两个参数，keyChangeIndicator和nextHopChainingCount，这两个参数是在切换和/或者连接重建立的时候，被UE用来用来确定AS安全密匙的。
完整性保护算法对于SRB1和SRB2是一样的。加密算法对于所有的无线承载（即SRB1、SRB2和DRBs）都是一样的，完整性保护算法和加密都不适用于SRB0。
RRC完整性和加密总是一起被激活的。也即是，在一个消息/进程中，RRC完整性和加密从来不会被去激活的。然而，却可以转换到一个”NULL”加密算法（eea0）。
“NULL”完整性保护算法(eia0)是只用于在有限服务模式下的UE。如果使用“NULL”完整性保护算法的话，那么也会使用“NULL”加密算法。
注1：低层（PDCP）如果检测到RRC消息的完整性保护失败，就会丢掉这个消息，并且通知RRC。
AS使用三种不同的安全性密匙：一个用于RRC信令的完整性保护（KRRCint），一个用于RRC信令的加密（KRRCenc），一个用于用户数据的加密（KUPenc）。所有这三种AS密匙是从KeNB密匙得来的。密匙KeNB是基于密匙KASME的，密匙KASME是由高层处理。
在建立新的连接后，会导出新的AS密匙。在连接建立过程中不会交换任何AS参数作为输入用于导出新的AS密钥。
用于切换的RRC消息的完整性和加密是基于切换之前的安全性配置的基础，而且这个动作是有源eNB实施的。
完整性和加密算法仅会在切换的时候才改变。四个AS密匙（KeNB, KRRCint, KRRCenc和KUPenc）是在每次的切换和连接重建立的时候改变的。keyChangeIndicator是在切换的时候用的，用来指示UE是否应该使用跟最新的有效密匙KASME相关的密匙。nextHopChainingCount参数是UE在切换和连接重建立的时候用于产生新的新的密匙KeNB，而密匙KeNB, 用来导出KRRCint, KRRCenc和KUPenc 密匙。在RRC_CONNECTED状态下可以使用小区内切换过程来改变密匙。
对于每个无线承载，在每个方向都维护一个独立的计数器（COUNT，参考TS 36.323 [8]）。对于每个DRB，COUNT作为输入用来加密。而对于每个SRB，COUNT作为输入用于加密和完整性保护。对于一个给定的安全密匙，同一个COUNT值使用不能超过一次。为了限制信令额外开销，每个消息/数据包包含一个短的序列号（PDCP SN，参见TS 36.323 [8]）。此外，使用计算器溢出机制：超帧号（TX_HFN和RX_HFN，参见TS 36.323 [8]）。HFN需要在UE和eNB之间达到同步。eNB是负责避免对于同一个RB标志和相同的密匙KeNB的COUNT的重复使用。比方说，由于数据的大量传送，计算器滚动很快，RBs建立和释放。为了避免这样的重复使用，eNB为连续建立的RB分配不同的RB标识，触发一个小区内切换或者触发一个RRC_CONNECTED到RRC_IDLE到RRC_CONNECTED的转变。
对每个SRB，由RRC提供给低层导出5个比特用来加密和完整性保护的输入的BEARER参数，也即是对应的srb-Identity的MSB加上0填充为。
完整性检查错误就是上述的完整性保护解调不出，导致异常释放。
希望能帮到楼主
正常的原因值如下：
RRC释放原因：
normal event 正常释放（比如手动断开连接）
unspecified 不确定性因素导致的释放
pre-emptive release 信道抢占引起的释放
re-establishment reject 链路重建拒绝
user inactivity 用户不在活动状态或者处于非激活状态
directed signalling connection reestablishment 直传信令的连接重建
楼主说的这个问题解释如下：
1.1.1 RRC 连接控制
RRC连接建立包括SRB1的建立。在完成S1连接建立之前，也即是在从EPC接收到UE上下文信息之前，E-UTRAN会完成RRC连接建立。因此，在RRC连接的初始化阶段AS的安全性还没被激活，但E-UTRAN可能配置UE来执行测量报告。然而，在安全性被激活的时候UE只会接受到一个切换消息。在从EPC接收到UE上下文之后，E-UTRAN通过初始安全性激活进程来激活安全性（也即是加密和完整性保护）。用于激活安全性的RRC消息（命令和成功响应）是进行了完整性保护的，而加密必须在安全性激活进程完成之后启动。也就是说，用于响应激活安全性的消息是没被加密的，而随后的消息（比方说，用于建立SRB2和DRBs）被完整性保护和加密。
在初始化了初始安全性激活进程之后，E-UTRAN发起SRB2和DRBs的建立，也就是即E-UTRAN可能在收到UE初始安全性激活的确认之前开始。不管怎样，E-UTRAN都会对用于建立SRB2和DRBs的RRC连接重配置消息进行加密和完整性保护。如果初始化安全性激活和/或者无线承载建立失败的话，E-UTRAN应该释放RRC连接（也即是，安全性激活和DRB的建立是由一个联合的S1过程触发的，这个过程不支持部分的成功）。
对于SRB2和DRBs，安全性总是从一开始就被激活的，即E-UTRAN不会在激活安全性之前建立这些承载。
RRC连接的释放是由E-UTRAN发起的。这个过程可以用来把UE重新引导到另一个频率上或者是其它的RAT。在一些特殊情况下，UE可能直接中止RRC连接，也即是不通知E-UTRAN就转移到RRC_IDLE状态。
1.1.2 安全性
AS安全性由RRC信令（SRBs）的完整性保护以及RRC信令和用户数据（DRBs）的的加密组成。RRC负责处理安全性参数的配置，这些配置是属于AS配置的一部分：完整性保护算法、加密算法以及两个参数，keyChangeIndicator和nextHopChainingCount，这两个参数是在切换和/或者连接重建立的时候，被UE用来用来确定AS安全密匙的。
完整性保护算法对于SRB1和SRB2是一样的。加密算法对于所有的无线承载（即SRB1、SRB2和DRBs）都是一样的，完整性保护算法和加密都不适用于SRB0。
RRC完整性和加密总是一起被激活的。也即是，在一个消息/进程中，RRC完整性和加密从来不会被去激活的。然而，却可以转换到一个”NULL”加密算法（eea0）。
“NULL”完整性保护算法(eia0)是只用于在有限服务模式下的UE。如果使用“NULL”完整性保护算法的话，那么也会使用“NULL”加密算法。
注1：低层（PDCP）如果检测到RRC消息的完整性保护失败，就会丢掉这个消息，并且通知RRC。
AS使用三种不同的安全性密匙：一个用于RRC信令的完整性保护（KRRCint），一个用于RRC信令的加密（KRRCenc），一个用于用户数据的加密（KUPenc）。所有这三种AS密匙是从KeNB密匙得来的。密匙KeNB是基于密匙KASME的，密匙KASME是由高层处理。
在建立新的连接后，会导出新的AS密匙。在连接建立过程中不会交换任何AS参数作为输入用于导出新的AS密钥。
用于切换的RRC消息的完整性和加密是基于切换之前的安全性配置的基础，而且这个动作是有源eNB实施的。
完整性和加密算法仅会在切换的时候才改变。四个AS密匙（KeNB, KRRCint, KRRCenc和KUPenc）是在每次的切换和连接重建立的时候改变的。keyChangeIndicator是在切换的时候用的，用来指示UE是否应该使用跟最新的有效密匙KASME相关的密匙。nextHopChainingCount参数是UE在切换和连接重建立的时候用于产生新的新的密匙KeNB，而密匙KeNB, 用来导出KRRCint, KRRCenc和KUPenc 密匙。在RRC_CONNECTED状态下可以使用小区内切换过程来改变密匙。
对于每个无线承载，在每个方向都维护一个独立的计数器（COUNT，参考TS 36.323 [8]）。对于每个DRB，COUNT作为输入用来加密。而对于每个SRB，COUNT作为输入用于加密和完整性保护。对于一个给定的安全密匙，同一个COUNT值使用不能超过一次。为了限制信令额外开销，每个消息/数据包包含一个短的序列号（PDCP SN，参见TS 36.323 [8]）。此外，使用计算器溢出机制：超帧号（TX_HFN和RX_HFN，参见TS 36.323 [8]）。HFN需要在UE和eNB之间达到同步。eNB是负责避免对于同一个RB标志和相同的密匙KeNB的COUNT的重复使用。比方说，由于数据的大量传送，计算器滚动很快，RBs建立和释放。为了避免这样的重复使用，eNB为连续建立的RB分配不同的RB标识，触发一个小区内切换或者触发一个RRC_CONNECTED到RRC_IDLE到RRC_CONNECTED的转变。
对每个SRB，由RRC提供给低层导出5个比特用来加密和完整性保护的输入的BEARER参数，也即是对应的srb-Identity的MSB加上0填充为。
完整性检查错误就是上述的完整性保护解调不出，导致异常释放。
希望能帮到楼主
回答者：OscarDon 回答时间：2013-01-17 23:00
1
0