 |
善于提問，勤于回答，你也是專家
|
 |
問題已開啟
(普通問題)
完整性檢查錯(cuò)誤導(dǎo)致rrc釋放
掉話中有一個(gè)完整性檢查錯(cuò)誤導(dǎo)致rrc釋放的原因，這個(gè)應(yīng)該怎么解決，涉及到哪些參數(shù)，都是哪個(gè)級(jí)別的，應(yīng)該怎么調(diào)
提問者:
• RRC重建占比如何提升 2020-08-18
• NR中，RRC_inactive狀態(tài)下，GNodeB是否有UE的上下文？就像下面的選擇題，總感覺答案不對(duì) 2020-06-16
• lteRRCradiolinkfailure 2020-06-08
• UE無應(yīng)答導(dǎo)致RRC建立失��？ 2019-12-10
• AS和NAS分別是接入層和非接入層？各自的作用是什么？RRC是NAS的子層嗎？它又發(fā)揮了什么樣的作用？ 2019-10-21
• UE無應(yīng)答導(dǎo)致RRC建立失敗 2019-08-07
• 關(guān)于無線鏈路失敗（RRCRadioLinkFailure）誰來解釋一下？ 2019-05-30
• 關(guān)于切換失敗的RRC連接重配消息 2019-05-19
• NR中，RRC_inactive狀態(tài)下，GNodeB是否有UE的上下文？就像下面的選擇題，總感覺答案不對(duì) 2020-06-16
• lteRRCradiolinkfailure 2020-06-08
• UE無應(yīng)答導(dǎo)致RRC建立失��？ 2019-12-10
• AS和NAS分別是接入層和非接入層？各自的作用是什么？RRC是NAS的子層嗎？它又發(fā)揮了什么樣的作用？ 2019-10-21
• UE無應(yīng)答導(dǎo)致RRC建立失敗 2019-08-07
• 關(guān)于無線鏈路失敗（RRCRadioLinkFailure）誰來解釋一下？ 2019-05-30
• 關(guān)于切換失敗的RRC連接重配消息 2019-05-19
問題答案
( 1 )
這個(gè)釋放原因值不是正常值：
正常的原因值如下：
RRC釋放原因：
normal event 正常釋放（比如手動(dòng)斷開連接）
unspecified 不確定性因素導(dǎo)致的釋放
pre-emptive release 信道搶占引起的釋放
re-establishment reject 鏈路重建拒絕
user inactivity 用戶不在活動(dòng)狀態(tài)或者處于非激活狀態(tài)
directed signalling connection reestablishment 直傳信令的連接重建
樓主說的這個(gè)問題解釋如下：
1.1.1
RRC連接建立包括SRB1的建立。在完成S1連接建立之前，也即是在從EPC接收到UE上下文信息之前，E-UTRAN會(huì)完成RRC連接建立。因此，在RRC連接的初始化階段AS的安全性還沒被激活，但E-UTRAN可能配置UE來執(zhí)行測(cè)量報(bào)告。然而，在安全性被激活的時(shí)候UE只會(huì)接受到一個(gè)切換消息。
在從EPC接收到UE上下文之后，E-UTRAN通過初始安全性激活進(jìn)程來激活安全性（也即是加密和完整性保護(hù)）。用于激活安全性的RRC消息（命令和成功響應(yīng)）是進(jìn)行了完整性保護(hù)的，而加密必須在安全性激活進(jìn)程完成之后啟動(dòng)。也就是說，用于響應(yīng)激活安全性的消息是沒被加密的，而隨后的消息（比方說，用于建立SRB2和DRBs）被完整性保護(hù)和加密。
在初始化了初始安全性激活進(jìn)程之后，E-UTRAN發(fā)起SRB2和DRBs的建立，也就是即E-UTRAN可能在收到UE初始安全性激活的確認(rèn)之前開始。不管怎樣，E-UTRAN都會(huì)對(duì)用于建立SRB2和DRBs的RRC連接重配置消息進(jìn)行加密和完整性保護(hù)。如果初始化安全性激活和/或者無線承載建立失敗的話，E-UTRAN應(yīng)該釋放RRC連接（也即是，安全性激活和DRB的建立是由一個(gè)聯(lián)合的S1過程觸發(fā)的，這個(gè)過程不支持部分的成功）。
對(duì)于SRB2和DRBs，安全性總是從一開始就被激活的，即E-UTRAN不會(huì)在激活安全性之前建立這些承載。
RRC連接的釋放是由E-UTRAN發(fā)起的。這個(gè)過程可以用來把UE重新引導(dǎo)到另一個(gè)頻率上或者是其它的RAT。在一些特殊情況下，UE可能直接中止RRC連接，也即是不通知E-UTRAN就轉(zhuǎn)移到RRC_IDLE狀態(tài)。
1.1.2
AS安全性由RRC信令（SRBs）的完整性保護(hù)以及RRC信令和用戶數(shù)據(jù)（DRBs）的的加密組成。
RRC負(fù)責(zé)處理安全性參數(shù)的配置，這些配置是屬于AS配置的一部分：完整性保護(hù)算法、加密算法以及兩個(gè)參數(shù)，keyChangeIndicator和nextHopChainingCount，這兩個(gè)參數(shù)是在切換和/或者連接重建立的時(shí)候，被UE用來用來確定AS安全密匙的。
完整性保護(hù)算法對(duì)于SRB1和SRB2是一樣的。加密算法對(duì)于所有的無線承載（即SRB1、SRB2和DRBs）都是一樣的，完整性保護(hù)算法和加密都不適用于SRB0。
RRC完整性和加密總是一起被激活的。也即是，在一個(gè)消息/進(jìn)程中，RRC完整性和加密從來不會(huì)被去激活的。然而，卻可以轉(zhuǎn)換到一個(gè)”NULL”加密算法（eea0）。
“NULL”完整性保護(hù)算法(eia0)是只用于在有限服務(wù)模式下的UE。如果使用“NULL”完整性保護(hù)算法的話，那么也會(huì)使用“NULL”加密算法。
注1：低層（PDCP）如果檢測(cè)到RRC消息的完整性保護(hù)失敗，就會(huì)丟掉這個(gè)消息，并且通知RRC。
AS使用三種不同的安全性密匙：一個(gè)用于RRC信令的完整性保護(hù)（KRRCint），一個(gè)用于RRC信令的加密（KRRCenc），一個(gè)用于用戶數(shù)據(jù)的加密（KUPenc）。所有這三種AS密匙是從KeNB密匙得來的。密匙KeNB是基于密匙KASME的，密匙KASME是由高層處理。
在建立新的連接后，會(huì)導(dǎo)出新的AS密匙。在連接建立過程中不會(huì)交換任何AS參數(shù)作為輸入用于導(dǎo)出新的AS密鑰。
用于切換的RRC消息的完整性和加密是基于切換之前的安全性配置的基礎(chǔ)，而且這個(gè)動(dòng)作是有源eNB實(shí)施的。
完整性和加密算法僅會(huì)在切換的時(shí)候才改變。四個(gè)AS密匙（KeNB, KRRCint, KRRCenc和KUPenc）是在每次的切換和連接重建立的時(shí)候改變的。keyChangeIndicator是在切換的時(shí)候用的，用來指示UE是否應(yīng)該使用跟最新的有效密匙KASME相關(guān)的密匙。nextHopChainingCount參數(shù)是UE在切換和連接重建立的時(shí)候用于產(chǎn)生新的新的密匙KeNB，而密匙KeNB, 用來導(dǎo)出KRRCint, KRRCenc和KUPenc 密匙。在RRC_CONNECTED狀態(tài)下可以使用小區(qū)內(nèi)切換過程來改變密匙。
對(duì)于每個(gè)無線承載，在每個(gè)方向都維護(hù)一個(gè)獨(dú)立的計(jì)數(shù)器（COUNT，參考TS 36.323 [8]）。對(duì)于每個(gè)DRB，COUNT作為輸入用來加密。而對(duì)于每個(gè)SRB，COUNT作為輸入用于加密和完整性保護(hù)。對(duì)于一個(gè)給定的安全密匙，同一個(gè)COUNT值使用不能超過一次。為了限制信令額外開銷，每個(gè)消息/數(shù)據(jù)包包含一個(gè)短的序列號(hào)（PDCP SN，參見TS 36.323 [8]）。此外，使用計(jì)算器溢出機(jī)制：超幀號(hào)（TX_HFN和RX_HFN，參見TS 36.323 [8]）。HFN需要在UE和eNB之間達(dá)到同步。eNB是負(fù)責(zé)避免對(duì)于同一個(gè)RB標(biāo)志和相同的密匙KeNB的COUNT的重復(fù)使用。比方說，由于數(shù)據(jù)的大量傳送，計(jì)算器滾動(dòng)很快，RBs建立和釋放。為了避免這樣的重復(fù)使用，eNB為連續(xù)建立的RB分配不同的RB標(biāo)識(shí)，觸發(fā)一個(gè)小區(qū)內(nèi)切換或者觸發(fā)一個(gè)RRC_CONNECTED到RRC_IDLE到RRC_CONNECTED的轉(zhuǎn)變。
對(duì)每個(gè)SRB，由RRC提供給低層導(dǎo)出5個(gè)比特用來加密和完整性保護(hù)的輸入的BEARER參數(shù)，也即是對(duì)應(yīng)的srb-Identity的MSB加上0填充為。
完整性檢查錯(cuò)誤就是上述的完整性保護(hù)解調(diào)不出，導(dǎo)致異常釋放。
希望能幫到樓主
正常的原因值如下：
RRC釋放原因：
normal event 正常釋放（比如手動(dòng)斷開連接）
unspecified 不確定性因素導(dǎo)致的釋放
pre-emptive release 信道搶占引起的釋放
re-establishment reject 鏈路重建拒絕
user inactivity 用戶不在活動(dòng)狀態(tài)或者處于非激活狀態(tài)
directed signalling connection reestablishment 直傳信令的連接重建
樓主說的這個(gè)問題解釋如下：
1.1.1 RRC 連接控制
RRC連接建立包括SRB1的建立。在完成S1連接建立之前，也即是在從EPC接收到UE上下文信息之前，E-UTRAN會(huì)完成RRC連接建立。因此，在RRC連接的初始化階段AS的安全性還沒被激活，但E-UTRAN可能配置UE來執(zhí)行測(cè)量報(bào)告。然而，在安全性被激活的時(shí)候UE只會(huì)接受到一個(gè)切換消息。在從EPC接收到UE上下文之后，E-UTRAN通過初始安全性激活進(jìn)程來激活安全性（也即是加密和完整性保護(hù)）。用于激活安全性的RRC消息（命令和成功響應(yīng)）是進(jìn)行了完整性保護(hù)的，而加密必須在安全性激活進(jìn)程完成之后啟動(dòng)。也就是說，用于響應(yīng)激活安全性的消息是沒被加密的，而隨后的消息（比方說，用于建立SRB2和DRBs）被完整性保護(hù)和加密。
在初始化了初始安全性激活進(jìn)程之后，E-UTRAN發(fā)起SRB2和DRBs的建立，也就是即E-UTRAN可能在收到UE初始安全性激活的確認(rèn)之前開始。不管怎樣，E-UTRAN都會(huì)對(duì)用于建立SRB2和DRBs的RRC連接重配置消息進(jìn)行加密和完整性保護(hù)。如果初始化安全性激活和/或者無線承載建立失敗的話，E-UTRAN應(yīng)該釋放RRC連接（也即是，安全性激活和DRB的建立是由一個(gè)聯(lián)合的S1過程觸發(fā)的，這個(gè)過程不支持部分的成功）。
對(duì)于SRB2和DRBs，安全性總是從一開始就被激活的，即E-UTRAN不會(huì)在激活安全性之前建立這些承載。
RRC連接的釋放是由E-UTRAN發(fā)起的。這個(gè)過程可以用來把UE重新引導(dǎo)到另一個(gè)頻率上或者是其它的RAT。在一些特殊情況下，UE可能直接中止RRC連接，也即是不通知E-UTRAN就轉(zhuǎn)移到RRC_IDLE狀態(tài)。
1.1.2 安全性
AS安全性由RRC信令（SRBs）的完整性保護(hù)以及RRC信令和用戶數(shù)據(jù)（DRBs）的的加密組成。RRC負(fù)責(zé)處理安全性參數(shù)的配置，這些配置是屬于AS配置的一部分：完整性保護(hù)算法、加密算法以及兩個(gè)參數(shù)，keyChangeIndicator和nextHopChainingCount，這兩個(gè)參數(shù)是在切換和/或者連接重建立的時(shí)候，被UE用來用來確定AS安全密匙的。
完整性保護(hù)算法對(duì)于SRB1和SRB2是一樣的。加密算法對(duì)于所有的無線承載（即SRB1、SRB2和DRBs）都是一樣的，完整性保護(hù)算法和加密都不適用于SRB0。
RRC完整性和加密總是一起被激活的。也即是，在一個(gè)消息/進(jìn)程中，RRC完整性和加密從來不會(huì)被去激活的。然而，卻可以轉(zhuǎn)換到一個(gè)”NULL”加密算法（eea0）。
“NULL”完整性保護(hù)算法(eia0)是只用于在有限服務(wù)模式下的UE。如果使用“NULL”完整性保護(hù)算法的話，那么也會(huì)使用“NULL”加密算法。
注1：低層（PDCP）如果檢測(cè)到RRC消息的完整性保護(hù)失敗，就會(huì)丟掉這個(gè)消息，并且通知RRC。
AS使用三種不同的安全性密匙：一個(gè)用于RRC信令的完整性保護(hù)（KRRCint），一個(gè)用于RRC信令的加密（KRRCenc），一個(gè)用于用戶數(shù)據(jù)的加密（KUPenc）。所有這三種AS密匙是從KeNB密匙得來的。密匙KeNB是基于密匙KASME的，密匙KASME是由高層處理。
在建立新的連接后，會(huì)導(dǎo)出新的AS密匙。在連接建立過程中不會(huì)交換任何AS參數(shù)作為輸入用于導(dǎo)出新的AS密鑰。
用于切換的RRC消息的完整性和加密是基于切換之前的安全性配置的基礎(chǔ)，而且這個(gè)動(dòng)作是有源eNB實(shí)施的。
完整性和加密算法僅會(huì)在切換的時(shí)候才改變。四個(gè)AS密匙（KeNB, KRRCint, KRRCenc和KUPenc）是在每次的切換和連接重建立的時(shí)候改變的。keyChangeIndicator是在切換的時(shí)候用的，用來指示UE是否應(yīng)該使用跟最新的有效密匙KASME相關(guān)的密匙。nextHopChainingCount參數(shù)是UE在切換和連接重建立的時(shí)候用于產(chǎn)生新的新的密匙KeNB，而密匙KeNB, 用來導(dǎo)出KRRCint, KRRCenc和KUPenc 密匙。在RRC_CONNECTED狀態(tài)下可以使用小區(qū)內(nèi)切換過程來改變密匙。
對(duì)于每個(gè)無線承載，在每個(gè)方向都維護(hù)一個(gè)獨(dú)立的計(jì)數(shù)器（COUNT，參考TS 36.323 [8]）。對(duì)于每個(gè)DRB，COUNT作為輸入用來加密。而對(duì)于每個(gè)SRB，COUNT作為輸入用于加密和完整性保護(hù)。對(duì)于一個(gè)給定的安全密匙，同一個(gè)COUNT值使用不能超過一次。為了限制信令額外開銷，每個(gè)消息/數(shù)據(jù)包包含一個(gè)短的序列號(hào)（PDCP SN，參見TS 36.323 [8]）。此外，使用計(jì)算器溢出機(jī)制：超幀號(hào)（TX_HFN和RX_HFN，參見TS 36.323 [8]）。HFN需要在UE和eNB之間達(dá)到同步。eNB是負(fù)責(zé)避免對(duì)于同一個(gè)RB標(biāo)志和相同的密匙KeNB的COUNT的重復(fù)使用。比方說，由于數(shù)據(jù)的大量傳送，計(jì)算器滾動(dòng)很快，RBs建立和釋放。為了避免這樣的重復(fù)使用，eNB為連續(xù)建立的RB分配不同的RB標(biāo)識(shí)，觸發(fā)一個(gè)小區(qū)內(nèi)切換或者觸發(fā)一個(gè)RRC_CONNECTED到RRC_IDLE到RRC_CONNECTED的轉(zhuǎn)變。
對(duì)每個(gè)SRB，由RRC提供給低層導(dǎo)出5個(gè)比特用來加密和完整性保護(hù)的輸入的BEARER參數(shù)，也即是對(duì)應(yīng)的srb-Identity的MSB加上0填充為。
完整性檢查錯(cuò)誤就是上述的完整性保護(hù)解調(diào)不出，導(dǎo)致異常釋放。
希望能幫到樓主
回答者：
OscarDon
回答時(shí)間：2011-10-19 18:39
14
16
• 浙江省郵電工程建設(shè)有限公司
聘：網(wǎng)優(yōu)日常租賃人員
需求人數(shù)：2 人 地點(diǎn)：煙臺(tái)市
• 成都旗訊通信技術(shù)有限公司 聘：【聯(lián)通項(xiàng)目】招督導(dǎo)、維護(hù)轉(zhuǎn)網(wǎng)優(yōu)
需求人數(shù)：12 人 地點(diǎn)：河北省,遼寧省,吉林省,黑龍江,內(nèi)蒙古
• 杭州東信網(wǎng)絡(luò)技術(shù)有限公司 聘：LTE/5G網(wǎng)絡(luò)中高級(jí)優(yōu)化工程師
需求人數(shù)：2 人 地點(diǎn)：上海市
• 北京宜通華瑞科技有限公司 聘：電信原廠優(yōu)化高級(jí)（江西急聘）
需求人數(shù)：5 人 地點(diǎn)：南昌市
• 西安中興精誠(chéng)通訊有限公司 聘：重慶-網(wǎng)優(yōu)高級(jí)工程師
需求人數(shù)：2 人 地點(diǎn)：重慶市
• 廣東世炬網(wǎng)絡(luò)科技股份有限公司 聘：網(wǎng)管運(yùn)維工程師
需求人數(shù)：2 人 地點(diǎn)：云南省
• 嘉環(huán)科技股份有限公司 聘：網(wǎng)優(yōu)前臺(tái)RF工程師-高級(jí)
需求人數(shù)：2 人 地點(diǎn)：河源市
• 南京華蘇科技有限公司 聘：濟(jì)南省移動(dòng)高端-材料輸出高手優(yōu)先
需求人數(shù)：1 人 地點(diǎn)：濟(jì)南市
• 北京電旗通訊技術(shù)股份有限公司 聘：山東濱州電信
需求人數(shù)：3 人 地點(diǎn)：濱州市
• 廣東華訊工程有限公司 聘：廣東移動(dòng)維護(hù)支撐
需求人數(shù)：2 人 地點(diǎn)：廣州市
需求人數(shù)：2 人 地點(diǎn)：煙臺(tái)市
• 成都旗訊通信技術(shù)有限公司 聘：【聯(lián)通項(xiàng)目】招督導(dǎo)、維護(hù)轉(zhuǎn)網(wǎng)優(yōu)
需求人數(shù)：12 人 地點(diǎn)：河北省,遼寧省,吉林省,黑龍江,內(nèi)蒙古
• 杭州東信網(wǎng)絡(luò)技術(shù)有限公司 聘：LTE/5G網(wǎng)絡(luò)中高級(jí)優(yōu)化工程師
需求人數(shù)：2 人 地點(diǎn)：上海市
• 北京宜通華瑞科技有限公司 聘：電信原廠優(yōu)化高級(jí)（江西急聘）
需求人數(shù)：5 人 地點(diǎn)：南昌市
• 西安中興精誠(chéng)通訊有限公司 聘：重慶-網(wǎng)優(yōu)高級(jí)工程師
需求人數(shù)：2 人 地點(diǎn)：重慶市
• 廣東世炬網(wǎng)絡(luò)科技股份有限公司 聘：網(wǎng)管運(yùn)維工程師
需求人數(shù)：2 人 地點(diǎn)：云南省
• 嘉環(huán)科技股份有限公司 聘：網(wǎng)優(yōu)前臺(tái)RF工程師-高級(jí)
需求人數(shù)：2 人 地點(diǎn)：河源市
• 南京華蘇科技有限公司 聘：濟(jì)南省移動(dòng)高端-材料輸出高手優(yōu)先
需求人數(shù)：1 人 地點(diǎn)：濟(jì)南市
• 北京電旗通訊技術(shù)股份有限公司 聘：山東濱州電信
需求人數(shù)：3 人 地點(diǎn)：濱州市
• 廣東華訊工程有限公司 聘：廣東移動(dòng)維護(hù)支撐
需求人數(shù)：2 人 地點(diǎn)：廣州市
熱點(diǎn)問題
更多精彩
| 聯(lián)系我們 - 問通信專家 | Powered by MSCBSC 移動(dòng)通信網(wǎng) © 2006 - |