 |
善于提問，勤于回答，你也是專家
|
 |
問題已開啟
(普通問題)
完整性檢查錯(cuò)誤導(dǎo)致rrc釋放
掉話中有一個(gè)完整性檢查錯(cuò)誤導(dǎo)致rrc釋放的原因，這個(gè)應(yīng)該怎么解決，涉及到哪些參數(shù)，都是哪個(gè)級別的，應(yīng)該怎么調(diào)
提問者:
• RRC重建占比如何提升 2020-08-18
• NR中，RRC_inactive狀態(tài)下，GNodeB是否有UE的上下文？就像下面的選擇題，總感覺答案不對 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的上下文？就像下面的選擇題，總感覺答案不對 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會完成RRC連接建立。因此，在RRC連接的初始化階段AS的安全性還沒被激活，但E-UTRAN可能配置UE來執(zhí)行測量報(bào)告。然而，在安全性被激活的時(shí)候UE只會接受到一個(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都會對用于建立SRB2和DRBs的RRC連接重配置消息進(jìn)行加密和完整性保護(hù)。如果初始化安全性激活和/或者無線承載建立失敗的話，E-UTRAN應(yīng)該釋放RRC連接（也即是，安全性激活和DRB的建立是由一個(gè)聯(lián)合的S1過程觸發(fā)的，這個(gè)過程不支持部分的成功）。
對于SRB2和DRBs，安全性總是從一開始就被激活的，即E-UTRAN不會在激活安全性之前建立這些承載。
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ù)算法對于SRB1和SRB2是一樣的。加密算法對于所有的無線承載（即SRB1、SRB2和DRBs）都是一樣的，完整性保護(hù)算法和加密都不適用于SRB0。
RRC完整性和加密總是一起被激活的。也即是，在一個(gè)消息/進(jìn)程中，RRC完整性和加密從來不會被去激活的。然而，卻可以轉(zhuǎn)換到一個(gè)”NULL”加密算法（eea0）。
“NULL”完整性保護(hù)算法(eia0)是只用于在有限服務(wù)模式下的UE。如果使用“NULL”完整性保護(hù)算法的話，那么也會使用“NULL”加密算法。
注1：低層（PDCP）如果檢測到RRC消息的完整性保護(hù)失敗，就會丟掉這個(gè)消息，并且通知RRC。
AS使用三種不同的安全性密匙：一個(gè)用于RRC信令的完整性保護(hù)（KRRCint），一個(gè)用于RRC信令的加密（KRRCenc），一個(gè)用于用戶數(shù)據(jù)的加密（KUPenc）。所有這三種AS密匙是從KeNB密匙得來的。密匙KeNB是基于密匙KASME的，密匙KASME是由高層處理。
在建立新的連接后，會導(dǎo)出新的AS密匙。在連接建立過程中不會交換任何AS參數(shù)作為輸入用于導(dǎo)出新的AS密鑰。
用于切換的RRC消息的完整性和加密是基于切換之前的安全性配置的基礎(chǔ)，而且這個(gè)動(dòng)作是有源eNB實(shí)施的。
完整性和加密算法僅會在切換的時(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)切換過程來改變密匙。
對于每個(gè)無線承載，在每個(gè)方向都維護(hù)一個(gè)獨(dú)立的計(jì)數(shù)器（COUNT，參考TS 36.323 [8]）。對于每個(gè)DRB，COUNT作為輸入用來加密。而對于每個(gè)SRB，COUNT作為輸入用于加密和完整性保護(hù)。對于一個(gè)給定的安全密匙，同一個(gè)COUNT值使用不能超過一次。為了限制信令額外開銷，每個(gè)消息/數(shù)據(jù)包包含一個(gè)短的序列號（PDCP SN，參見TS 36.323 [8]）。此外，使用計(jì)算器溢出機(jī)制：超幀號（TX_HFN和RX_HFN，參見TS 36.323 [8]）。HFN需要在UE和eNB之間達(dá)到同步。eNB是負(fù)責(zé)避免對于同一個(gè)RB標(biāo)志和相同的密匙KeNB的COUNT的重復(fù)使用。比方說，由于數(shù)據(jù)的大量傳送，計(jì)算器滾動(dòng)很快，RBs建立和釋放。為了避免這樣的重復(fù)使用，eNB為連續(xù)建立的RB分配不同的RB標(biāo)識，觸發(fā)一個(gè)小區(qū)內(nèi)切換或者觸發(fā)一個(gè)RRC_CONNECTED到RRC_IDLE到RRC_CONNECTED的轉(zhuǎn)變。
對每個(gè)SRB，由RRC提供給低層導(dǎo)出5個(gè)比特用來加密和完整性保護(hù)的輸入的BEARER參數(shù)，也即是對應(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會完成RRC連接建立。因此，在RRC連接的初始化階段AS的安全性還沒被激活，但E-UTRAN可能配置UE來執(zhí)行測量報(bào)告。然而，在安全性被激活的時(shí)候UE只會接受到一個(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都會對用于建立SRB2和DRBs的RRC連接重配置消息進(jìn)行加密和完整性保護(hù)。如果初始化安全性激活和/或者無線承載建立失敗的話，E-UTRAN應(yīng)該釋放RRC連接（也即是，安全性激活和DRB的建立是由一個(gè)聯(lián)合的S1過程觸發(fā)的，這個(gè)過程不支持部分的成功）。
對于SRB2和DRBs，安全性總是從一開始就被激活的，即E-UTRAN不會在激活安全性之前建立這些承載。
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ù)算法對于SRB1和SRB2是一樣的。加密算法對于所有的無線承載（即SRB1、SRB2和DRBs）都是一樣的，完整性保護(hù)算法和加密都不適用于SRB0。
RRC完整性和加密總是一起被激活的。也即是，在一個(gè)消息/進(jìn)程中，RRC完整性和加密從來不會被去激活的。然而，卻可以轉(zhuǎn)換到一個(gè)”NULL”加密算法（eea0）。
“NULL”完整性保護(hù)算法(eia0)是只用于在有限服務(wù)模式下的UE。如果使用“NULL”完整性保護(hù)算法的話，那么也會使用“NULL”加密算法。
注1：低層（PDCP）如果檢測到RRC消息的完整性保護(hù)失敗，就會丟掉這個(gè)消息，并且通知RRC。
AS使用三種不同的安全性密匙：一個(gè)用于RRC信令的完整性保護(hù)（KRRCint），一個(gè)用于RRC信令的加密（KRRCenc），一個(gè)用于用戶數(shù)據(jù)的加密（KUPenc）。所有這三種AS密匙是從KeNB密匙得來的。密匙KeNB是基于密匙KASME的，密匙KASME是由高層處理。
在建立新的連接后，會導(dǎo)出新的AS密匙。在連接建立過程中不會交換任何AS參數(shù)作為輸入用于導(dǎo)出新的AS密鑰。
用于切換的RRC消息的完整性和加密是基于切換之前的安全性配置的基礎(chǔ)，而且這個(gè)動(dòng)作是有源eNB實(shí)施的。
完整性和加密算法僅會在切換的時(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)切換過程來改變密匙。
對于每個(gè)無線承載，在每個(gè)方向都維護(hù)一個(gè)獨(dú)立的計(jì)數(shù)器（COUNT，參考TS 36.323 [8]）。對于每個(gè)DRB，COUNT作為輸入用來加密。而對于每個(gè)SRB，COUNT作為輸入用于加密和完整性保護(hù)。對于一個(gè)給定的安全密匙，同一個(gè)COUNT值使用不能超過一次。為了限制信令額外開銷，每個(gè)消息/數(shù)據(jù)包包含一個(gè)短的序列號（PDCP SN，參見TS 36.323 [8]）。此外，使用計(jì)算器溢出機(jī)制：超幀號（TX_HFN和RX_HFN，參見TS 36.323 [8]）。HFN需要在UE和eNB之間達(dá)到同步。eNB是負(fù)責(zé)避免對于同一個(gè)RB標(biāo)志和相同的密匙KeNB的COUNT的重復(fù)使用。比方說，由于數(shù)據(jù)的大量傳送，計(jì)算器滾動(dòng)很快，RBs建立和釋放。為了避免這樣的重復(fù)使用，eNB為連續(xù)建立的RB分配不同的RB標(biāo)識，觸發(fā)一個(gè)小區(qū)內(nèi)切換或者觸發(fā)一個(gè)RRC_CONNECTED到RRC_IDLE到RRC_CONNECTED的轉(zhuǎn)變。
對每個(gè)SRB，由RRC提供給低層導(dǎo)出5個(gè)比特用來加密和完整性保護(hù)的輸入的BEARER參數(shù)，也即是對應(yīng)的srb-Identity的MSB加上0填充為。
完整性檢查錯(cuò)誤就是上述的完整性保護(hù)解調(diào)不出，導(dǎo)致異常釋放。
希望能幫到樓主
回答者：
OscarDon
回答時(shí)間：2011-10-19 18:39
14
16
• 成都旗訊通信技術(shù)有限公司
聘：電聯(lián)招聘督導(dǎo)、傳輸、維護(hù)轉(zhuǎn)網(wǎng)優(yōu)
需求人數(shù)：12 人 地點(diǎn)：浙江省,江蘇省,河北省,山西省,遼寧省
• 錦華技術(shù)（蘭州）有限公司 聘：杭州5G中興中級/高級后臺
需求人數(shù)：5 人 地點(diǎn)：杭州市,寧波市,嘉興市,溫州市,紹興市
• 北京電旗通訊技術(shù)股份有限公司 聘：網(wǎng)優(yōu)實(shí)習(xí)生通信應(yīng)屆生（云南）
需求人數(shù)：1 人 地點(diǎn)：昆明市,思茅市,昭通市
• 河北中創(chuàng)盈和通信科技有限公司 聘：中級前臺/寧夏中衛(wèi)
需求人數(shù)：2 人 地點(diǎn)：寧夏
• 南京格安信息系統(tǒng)有限責(zé)任公司 聘：5G工程單驗(yàn)人員
需求人數(shù)：10 人 地點(diǎn)：北京市
• 西安長河通訊有限責(zé)任公司 聘：網(wǎng)絡(luò)優(yōu)化工程師
需求人數(shù)：4 人 地點(diǎn)：渭南市,商洛市,漢中市,安康市
• 嘉環(huán)科技股份有限公司 聘：湖南電信原廠優(yōu)化招聘
需求人數(shù)：10 人 地點(diǎn)：長沙市,永州市,郴州市,衡陽市
• 重慶信科通信工程有限公司 聘：西安GSC項(xiàng)目經(jīng)理
需求人數(shù)：2 人 地點(diǎn)：西安市
• 南京華蘇科技有限公司 聘：性能后臺-深圳移動(dòng)日常
需求人數(shù)：3 人 地點(diǎn)：深圳市
• 廣州楚晨網(wǎng)絡(luò)科技有限公司 聘：后臺高級網(wǎng)絡(luò)優(yōu)化工程師
需求人數(shù)：6 人 地點(diǎn)：廣東省
需求人數(shù)：12 人 地點(diǎn)：浙江省,江蘇省,河北省,山西省,遼寧省
• 錦華技術(shù)（蘭州）有限公司 聘：杭州5G中興中級/高級后臺
需求人數(shù)：5 人 地點(diǎn)：杭州市,寧波市,嘉興市,溫州市,紹興市
• 北京電旗通訊技術(shù)股份有限公司 聘：網(wǎng)優(yōu)實(shí)習(xí)生通信應(yīng)屆生（云南）
需求人數(shù)：1 人 地點(diǎn)：昆明市,思茅市,昭通市
• 河北中創(chuàng)盈和通信科技有限公司 聘：中級前臺/寧夏中衛(wèi)
需求人數(shù)：2 人 地點(diǎn)：寧夏
• 南京格安信息系統(tǒng)有限責(zé)任公司 聘：5G工程單驗(yàn)人員
需求人數(shù)：10 人 地點(diǎn)：北京市
• 西安長河通訊有限責(zé)任公司 聘：網(wǎng)絡(luò)優(yōu)化工程師
需求人數(shù)：4 人 地點(diǎn)：渭南市,商洛市,漢中市,安康市
• 嘉環(huán)科技股份有限公司 聘：湖南電信原廠優(yōu)化招聘
需求人數(shù)：10 人 地點(diǎn)：長沙市,永州市,郴州市,衡陽市
• 重慶信科通信工程有限公司 聘：西安GSC項(xiàng)目經(jīng)理
需求人數(shù)：2 人 地點(diǎn)：西安市
• 南京華蘇科技有限公司 聘：性能后臺-深圳移動(dòng)日常
需求人數(shù)：3 人 地點(diǎn)：深圳市
• 廣州楚晨網(wǎng)絡(luò)科技有限公司 聘：后臺高級網(wǎng)絡(luò)優(yōu)化工程師
需求人數(shù)：6 人 地點(diǎn)：廣東省
熱點(diǎn)問題
更多精彩
| 聯(lián)系我們 - 問通信專家 | Powered by MSCBSC 移動(dòng)通信網(wǎng) © 2006 - |