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