irat專題r9csfb案例集RIM全稱為其作用就是用于GERAN

【IRAT專題】R9CSFB案例RIM類問RIMRIM介RIM：全稱為RANInformationManagement，其作用就是用于GERAN、UTRAN、E-UTRAN接入網間通過網進行信息交換。RIM過程涉及的網元主要是eNodeB、MME、SGSN、RNC/BSCMME和SGSN主要是對交RIM的作RIM的主要作用就是獲取對端的信息，根據其目的不同，獲取的信息是不一致的，主要包1eNodeBRIMRNC/BSCFlashCSFBCCO/NACCCSFB2eNodeBRIMRNC獲取外部小區(qū)的負載信息，可以用于異系統(tǒng)MLBCSFB流程(6.0MLB的負載平衡時獲取對端負載信息，但是NACC開關控制CCOwith/withoutflashCSFBCSFB flash重定向開關控制除上述以外的其它重定向(MODENODEBALGOSWITCH:RIM需要獲取的信UTRAN獲?。篠IB1/3/5/7GERANRIM的方eRAN6.0MMLMODENODEBALGOSWITCH:RimSwitch=UTRAN_RIM_SWITCH-1&GERAN_RIM_SWITCH-1;//RIM開SingleSingleReportUTRANRIMRIM獲取對端信息，就是采用SingleReport方式。而到GERANRIMGERAN信息。MultipleMultipleReport用于多次的信息交換，由源側發(fā)起請求后，目標側響應，后續(xù)目標側信息發(fā)生變化，目標側主動通知源側；當UTRANRIMMultipleReport。RIM的編碼方式與該編碼方式當與eNodeB進行RIM消息交互的網設備均為設備，并且對端設備采用RIM私有編方式時，要求eNodeB設置為私有編方式。62F290(616進制)PLMN6226，F22F，最終翻轉8：私有編碼補充03C(316進制，12bit)：RNCID107158(416進制，16bit)：CellID1048.018-25.413-25.401-62F290(616進制)PLMN，如前所示，兩位翻轉為：26203C(316進制，12bit)：RNCID，直接轉十進制，RNC7153(416進制，16bit)：CellID，直接轉十進制，Cell0如果需要修改編碼方式，比如從私有協議修改為標準協議，或者從標準協議修改為私RIM的前提下修改。當前實MultipleReportRIM只有針對協議版本Release9（含）以上的MME，eNodeB才會觸發(fā)Multiplereport流程。MultiplereportRIM的觸發(fā)條件有兩個：RIMUTRAN外部小區(qū)。例如，當RIMUTRANRIM流程；而若UTRAN外部小RIMRIM流程。CCEMMultiRIM重發(fā)嘗試，采用懲罰拉長重發(fā)間隔的方法，第一次重發(fā)的間隔時間為T，則第N次重發(fā)間隔為N*T。T2小時，N10，重試成功后，所有懲罰數據。超過最大嘗試次數依然沒有成功則不在進行周期重試。后續(xù)依賴于MultiRIM。RANINFORMATIONREQUESTeNodeB分批請求，不區(qū)分運營商和鏈路，每K秒發(fā)送一個請求。K4RIM問題現軟件版本：BTS3900LTEC國某局點客戶在測試快速CSFB時，發(fā)現會對RNC發(fā)來的RIM請求比如下圖所示，從序號4459，RNC每隔1min就不斷重復發(fā)送RIMreporteNB，eNB60.而在此之前，eNBRIMreport問題分經過分析消息內容，比照協議規(guī)定，確認如下時段沒有發(fā)送ACK響應是因為，eNodeB側將請求消息中的RSN和自己發(fā)的RSN來做比對，如果接收到RSNeNodeB根據協議，eNodeB不應該判斷對端發(fā)來的RSN，只是和本地——的目的是，在響應消息中攜帶——的目的是，如果對端再來一條請求消息，用來做判斷，如果比48.108eNB發(fā)送的最后一條RIM請求消息中攜帶RSNId ，見下圖但是對端RNC回復的消息中RSN信元為 （見下圖），小于eNB發(fā)送的請求消息中的RSNID。直到在11:48:17，RNC回復的消息中RSN信元 （見下圖），大eNBRSNID，eNBACK同時DBG日志中對應時段存在判斷RSNID出錯的記錄eNB問題根當前實現不符合協議，即eNodeB側將請求消息中的RSN和自己發(fā)的RSN來RSNeNodeBeNB解決方這個問題 復位后很容易觸發(fā)，但是一般持續(xù)較短時間后會自動恢復觸發(fā)：在復位后，會初始化RSN，從2011-1-10:00:00開始到當前的秒RNCRIMRSN自愈：RNC在未收到RIM響應后，會每隔一分鐘重新發(fā)送，每次重發(fā)對RSN做累加，累加值0x ），所以一會就能達到eNodeB的RSNeNBFlashCSFB類問參數設置問題導致L—>UFlashCSFBFlashCSFBRIMRRCReleaseIDUEUTRAN網絡，并免去了讀UTRAN小區(qū)系統(tǒng)消息的時間。RIM2R8RedirectCSFBFlashCSFBR9RedirectCSFB，因此從終端，eNodeB和網側都必須保證支持R9Release。DSPUTRANRIMINFO查看是否已經獲取到了目標小區(qū)的系統(tǒng)消息。如圖3，eNodeB沒有獲取到目標小區(qū)的系統(tǒng)消息。步驟2：分析S1口信令，發(fā)現沒有觸發(fā)RIM流程。正常的RIM請求是通過RIM觸發(fā)的條件。License情況，FlashCSFallbacktoUTRAN(FDD)UranFlashRedirectSwitch-1、UTRAN_RIM_SWITCH-1、MmeRelease=Release_R10均設5RIM流程，eNodeBRIM2小時后再發(fā)RIM開關重新開關一次。步驟5：現場重現開關RIMSwitch后，信令中就到了RIM請求消RNCRIMRNCRIMCSFB開關9。FAST_CS_FB_BASEDON_RIM_SWITCHON，而根據該參數描OFFRIMCSFB10。步驟6RIM回復消息S1AP_MME_DIRECT_INFO_TRANSF，11RIMRNC回復的S1AP_MME_DIRECT_INFO_TRANSFran-info-err消息，如圖13，cause RNC14步驟7：檢查RIM請求消息中攜帶的目標小區(qū)ID，如圖15，請求的cell-id UtranFddTddType=UTRAN_FDD,RacCfgInd=CFG,Rac=115,PScrambCode=200,根據UTRAN小區(qū)標識計算公式：UTRANCellIdentity=RncId×65536+CellId=1112*65536= ，和S1口RIM請求消息中發(fā)出的cell-id一致。經RNC側核查，并沒有RNC=1112，CellId=9999這個小區(qū)。OFFCELLFlashCSFB參數設置問題導致L—>GFlashCSFBFlashCSFBRIMRRCRelease目標小區(qū)ID以及目標小區(qū)的系統(tǒng)消息，使UE更快的接入目標GERAN，并免去了GERAN小區(qū)系統(tǒng)消息的時間。RIM2R8RedirectCSFBFlashCSFBR9RedirectCSFB，因此從終端，eNodeB和網側都必須保證支持R9Release。DSPGERANRIMINFO查看是否已經獲取到了目標小區(qū)的系統(tǒng)消息。如圖3，eNodeB沒有獲取到目標小區(qū)的系統(tǒng)消息。步驟2：分析S1口信令是否RIM流程正常，如圖4，eNodeB發(fā)起了RIM3eNodeBRIMLicense、參數設置、UE能力支持是RIM的觸發(fā)條件，因此不需要檢查這些配置。4GERANRIMOFF，eNACCSPTOFFUPRIM5。步驟5GERAN側開啟相關參數后，重新測試收到了RIM回復消息GERANRIMSUP和eNACCSPTOFFFlashCSFBeNACCSPTRIMSUP為UP。RIMFlashCSFB一線使用FlashCSFBtoUTRAN，同時打開了RIM算法開關但是MMLDSPLTE側分析：從S1標口分析看，LTERIM（S1AP_MME_DIRECT_INFO_TRANSF）。因此，從流程上看，RIM流程是走通了 RIM消息，發(fā)現對端反饋的UTRAN系統(tǒng)消息字段為空，同時PDU-ERRORUTRAN回了系統(tǒng)消息，但是并沒有把UTRAN的系統(tǒng)消息帶給LTELRIM狀態(tài)信息。3G3GdebugLog RR_ERR_IUITF_0444DEBUGINFO:pMsg->InterSysInfoTransfType.u.RimTransf.RimInfo.usLenis!LogIndex: RR_ERR_PATCH_RAB_0008 RR_ERR_PATCH ,Log RR_ERR_PATCH_RAB_0006 RR_ERR_PATCH ,Log RR_ERR_PATCH_RAB_0007 RR_ERR_PATCH ,上邊的補丁日志顯示，在iuitf模塊獲取小區(qū)id時認為數據不對，CN。CNRNCRNCID12RSN2218但是從下圖中的碼流按照編碼方式解讀發(fā)現：PLMN（72F4 RNCid（000）+cellid（2E23）+補充比特（0），其實RNCID=00，3GCellID，RNCCNLTEUTRANMMLRNC*65535+CellIDUTRAN在eRAN6.0SPC170版本以前，RIM采用的編碼方式是的私有編碼方式，這種編碼方LCellIDURNCID。1MML幫助的計算方式填寫UTRANCellIDMML幫助填寫的話并不會影響到異系統(tǒng)的切換、重定向。僅僅影響RIM的獲取。2LTEeRAN6.0SPC170協議缺陷導致復位后概率性出現FlashCSFB不生效的問題一線發(fā)現，復位后，FlashCSFB的生效率下降明顯（從100%下降到FlashCSFB生效率=（"L.FlashCSFB.E2W"+"L.FlashCSFB.E2G"）1.通過操作日志確認，FlashCSFBFlashCSFBeNodeB（UTRAN）RIMeNodeBUTRAN2、通過counter確認，復位以后，發(fā)送了RIM請求，但是沒有收到對端RIM3、通過標口確認，UTRANLTERIM通過標口分析，在15:43發(fā)起多次RIM請求消息，只收到RIMRIMRIMcellid外，其余信元無異常。通過RNC的日志分析，是由于發(fā)送的RSN與RNCRNCRIM4、結合協議分析，協議缺陷導致LTE復位后，如果LTERIM請求中的比RNC自己的RSN“OLDER”，則RNC不會響應LTE的RIM請3GPP48018RSN控制器會一個RIMSequenceNumber，這個RIMSequenceNumber主要有RIMREQRIMINFOPDUPDUPDURSNPDUACKPDUERRORPDURSNRSN0~2^32-1,RSNRSNRSN(RSNX，givenRSNXRSN，RSN2RSNX“older”RSNXRNCRSNRSNRSN8c.1.5.3。如果滿足該規(guī)則，RNCRSNRSNX，如RNCRIMRNCRIMRSNRNCRSNOLDER，RNCRIM5、為什么會LTE復位后出現該問題eNodebRSNRSNRIMREQPDUeNodeBRNCeNodeBRSNRNCeNodebMULTIPLE_REPORT_SETTING_RSNRSNRIMFlashCSFB1、eNodeBRIMRSN2、由于協議缺陷，eNodeBRNCRSNRNCRIMRSNRNCRSNOLDER，RNCRIM3CSFBeNodeBRIMflashCSFBeNodeBRNC1、eNodeB7.0SPC230方案1：RNCRIMFastCSFBRNCRSN。MMLSETURRCTRLSWITCH:打開開關：SETURRCTRLSWITCH:RNCeNodeBRIMeNodeBRNCRSNMMLMODENODEBALGOSWITCH:打開開關：MODENODEBALGOSWITCH:RimSwitch=UTRAN_RIM_SWITCH-方案2RNCR15SPC518RIM10器。當定時器超時后，RNCRIMeNodeB2、eNodeB：7.0SPC2307.0SPC230，eNodeBRIMeNodeB后RSN不，使用當前時間和基準時間的差值，計算RSN初始值，保證復位前后RSN值符合協議RN為什 某局點反饋發(fā)現現網個別小區(qū)沒有觸發(fā)R9CSFB，但是查看已經成功獲取RIMR9CSFB（Flash1R9CSFBMODENODEBALGOSWITCH:HoAlgoSwitch=UtranCsfbSwitch-UTRAN401311圖1配置的UTRAN外部小區(qū)信2、查看獲取到的UTRAN系統(tǒng)信息發(fā)現，已經有40131的RIM信息，如2。圖2獲取到的UTRAN小區(qū)信3、按照上述情況，正常應該觸發(fā)R9CSFB，查看標口圖3，這次CSFB卻是R8CSFB，UTR