LTE信令流程介紹

技術(shù)文件技術(shù)文件名稱：LTE信令流程介紹技術(shù)文件編號(hào)：版本：擬制審核會(huì)簽標(biāo)準(zhǔn)化批準(zhǔn)目錄TOC\o"1-3"\h\z1概念介紹 51.1控制面和用戶面協(xié)議棧 51.2承載概念 51.3連接概念 62開機(jī)附著流程 72.1正常流程 72.2異常流程 102.2.1RRC連接建立失敗 102.2.2核心網(wǎng)拒絕 112.2.3eNB未等到Initialcontextsetuprequest消息 122.2.4RRC重配消息丟失或者沒收到RRC重配完成消息或者eNB內(nèi)部配置UE的安全參數(shù)等失敗 133UE發(fā)起的servicerequest流程 153.1正常流程 153.2異常流程 173.2.1RRC連接建立失敗 173.2.2核心網(wǎng)拒絕 1832.3eNB未等到Initialcontextsetuprequest消息 193.2.4RRC重配消息丟失或者eNB內(nèi)部配置UE的安全參數(shù)失敗或者沒有建立起來一個(gè)非GBR承載 193.2.5eNB建立專用承載失敗 193.2.6eNB建立默認(rèn)承載失敗 194網(wǎng)絡(luò)發(fā)起的paging流程 214.1S_TMSI尋呼 214.2IMSI尋呼 215TAU流程： 215.1正常流程 225.1.1IDLE下發(fā)起的 225.1.2CONNECTED下發(fā)起的 265.2異常流程 266去附著 276.1關(guān)機(jī)去附著 276.2非關(guān)機(jī)去附著 277切換流程 298專用承載建立流程 318.1正常流程 318.2異常流程 338.2.1核心網(wǎng)拒絕 338.2.2eNB本地建立失?。ê诵木W(wǎng)主動(dòng)發(fā)起的建立） 338.2.3eNB未等到RRC重配完成消息，回復(fù)失敗 358.2.4UENAS層拒絕 358.2.5上行直傳NAS消息丟失 379專用承載修改流程 389.1正常流程 389.1.1修改QoS 399.1.2不修改QoS，只修改TFT 409.2異常流程 419.2.1核心網(wǎng)拒絕 419.2.2eNB回復(fù)失敗 419.2.3UENAS層拒絕 419.2.4上行直傳NAS消息丟失 4110專用承載釋放流程 4211空口RRC信令 431概念介紹1.1控制面和用戶面協(xié)議?？刂泼鎱f(xié)議棧用戶面協(xié)議棧1.2承載概念EPSbearer:AnEPSbeareruniquelyidentifiestrafficflowsthatreceiveacommonQoStreatmentbetweenaUEandaPDNGWE-RAB:AnE-RABuniquelyidentifiestheconcatenationofanS1BearerandthecorrespondingDataRadioBearer.WhenanE-RABexists,thereisaone-to-onemappingbetweenthisE-RABandanEPSbeareroftheNonAccessStratum.DataRadioBearer:theDataRadiobearertransportsthepacketsofanE-RABbetweenaUEandaneNB.Thereisanone-to-onemappingbetweentheE-RABandtheDataRadioBearer。（eNB）Figure13.1-1:EPSBearerServiceArchitectureDefaultBearer:TheEPSbearerwhichisfirstestablishedforanewPDNconnectionandremainsestablishedthroughoutthelifetimeofthePDNconnection.Non-GBRbearer:AnEPSbearerthatusesnetworkresourcesthatarenotrelatedtoaguaranteedbitrate(GBR)value.GBRbearer:relatedtoaguaranteedbitrate(GBR)value.1.3連接概念Uu（X1）:interfacebetweenanUEandE-UTRAN.S1:interfacebetweenaneNBandanEPC,providinganinterconnectionpointbetweentheE-UTRANandtheEPC.UE-associatedlogicalS1-connection:TheUE-associatedlogicalS1-connectionusestheidentitiesMMEUES1APIDandeNBUES1APIDaccordingtodefinitionin[23.401].ForareceivedUEassociatedS1-APmessagetheMMEidentifiestheassociatedUEbasedontheMMEUES1APIDIEandtheeNBidentifiestheassociatedUEbasedontheeNBUES1APIDIE.TheUE-associatedlogicalS1-connectionmayexistbeforetheS1UEcontextissetupineNB.NASsignallingconnection:isapeertopeerS1modeconnectionbetweenUEandMME.ANASsignallingconnectionconsistsoftheconcatenationofanRRCconnectionviathe"LTE-Uu"interfaceandanS1APconnectionviatheS1interface.2開機(jī)附著流程2.1正常流程UE剛開機(jī)時(shí)，先進(jìn)行物理下行同步，搜索測(cè)量進(jìn)行小區(qū)選擇，選擇到一個(gè)suitable或者acceptable小區(qū)后，駐留并進(jìn)行附著過程。附著完成后，默認(rèn)承載建立成功，UE可獲得PDNaddress信息。附著流程圖如下：說明：1）步驟1～5會(huì)建立RRC連接，步驟6、9會(huì)建立S1連接，完成這些過程即標(biāo)志著NASsignallingconnection建立完成，見24.301。2）消息7的說明：UE剛開機(jī)第一次attach，使用的IMSI，無Identity過程；后續(xù)，如果有有效的GUTI，使用GUTIattach，核心網(wǎng)才會(huì)發(fā)起Identity過程（為上下行直傳消息）。3）消息10~12的說明：如果消息9帶了UERadioCapabilityIE，則eNB不會(huì)發(fā)送UECapabilityEnquiry消息給UE，即沒有10~12過程；否則會(huì)發(fā)送，UE上報(bào)無線能力信息后，eNB再發(fā)UECapabilityInfoIndication，給核心網(wǎng)上報(bào)UE的無線能力信息。為了減少空口開銷，在IDLE下MME會(huì)保存UERadioCapability信息，在INITIALCONTEXTSETUPREQUEST消息會(huì)帶給eNB，除非UE在執(zhí)行attach或者"firstTAUfollowingGERAN/UTRANAttach"or"UEradiocapabilityupdate"TAU過程（也就是這些過程MME不會(huì)帶UERadioCapability信息給eNB，并會(huì)把本地保存的UERadioCapability信息刪除，eNB會(huì)問UE要能力信息，并報(bào)給MME。注："UEradiocapabilityupdate"TAUisonlysupportedforchangesofGERANandUTRANradiocapabilitiesinECM-IDLE.）。在CONNECTED下，eNB會(huì)一直保存UERadioCapability信息。UE的E_UTRAN無線能力信息如果發(fā)生改變，需要先detach，再attach。4）發(fā)起UE上下文釋放（即21～25）的條件：- eNodeB-initiatedwithcausee.g.O&MIntervention,UnspecifiedFailure,UserInactivity,RepeatedRRCsignallingIntegrityCheckFailure,ReleaseduetoUEgeneratedsignallingconnectionrelease,etc.;or-MME-initiatedwithcausee.g.authenticationfailure,detach,etc.5）eNB收到msg3以后，DCM給USM配置SRB1，配置完后發(fā)送msg4給UE；eNB在發(fā)送RRCConnectionReconfiguration前，DCM先給USM配置DRB/SRB2等信息，配置完后發(fā)送RRCConnectionReconfiguration給UE，收到RRCConnectionReconfigurationComplete后，控制面再通知用戶面資源可用。6）消息13~15的說明：eNB發(fā)送完消息13，并不需要等收到消息14，就直接發(fā)送消息15。7）如果發(fā)起IMSIattach時(shí)，UE的IMSI與另外一個(gè)UE的IMSI重復(fù)，并且其他UE已經(jīng)attach，則核心網(wǎng)會(huì)釋放先前的UE。如果IMSI中的MNC與核心網(wǎng)配置的不一致，則核心網(wǎng)會(huì)回復(fù)attachreject。8）消息9的說明：該消息為MME向eNB發(fā)起的初始上下文建立請(qǐng)求，請(qǐng)求eNB建立承載資源，同時(shí)帶安全上下文，可能帶用戶無線能力、切換限制列表等參數(shù)。UE的安全能力參數(shù)是通過attachrequest消息帶給核心網(wǎng)的，核心網(wǎng)再通過該消息送給eNB。UE的網(wǎng)絡(luò)能力（安全能力）信息改變的話，需要發(fā)起TAU。2.2異常流程2.2.1RRC連接建立失敗2.2.2核心網(wǎng)拒絕1）如果是ESM過程導(dǎo)致的拒絕（比如默認(rèn)承載建立失?。艜?huì)帶PDNCONNECTIVITYREJECT消息，EMM層拒絕，只有ATTACHREJECT消息。2）常見的拒絕原因有：IMSI中的MNC與核心網(wǎng)配置的不一致。2.2.3eNB未等到Initialcontextsetuprequest消息2.2.4RRC重配消息丟失或者沒收到RRC重配完成消息或者eNB內(nèi)部配置UE的安全參數(shù)等失敗3UE發(fā)起的servicerequest流程3.1正常流程UE在IDLE模式下，需要發(fā)送業(yè)務(wù)數(shù)據(jù)時(shí)，發(fā)起servicerequest過程，流程圖如下：3.2異常流程3.2.1RRC連接建立失敗處理同2.2.1。3.2.2核心網(wǎng)拒絕3.2.3eNB未等到Initialcontextsetuprequest消息處理同2.2.3，區(qū)別在于servicerequest過程失敗沒有重發(fā)。3.2.4RRC重配消息丟失或者eNB內(nèi)部配置UE的安全參數(shù)失敗或者沒有建立起來一個(gè)非GBR承載同2.2.4，區(qū)別在于servicerequest過程失敗沒有重發(fā)。3.2.5eNB建立專用承載失敗當(dāng)attach成功，建立一個(gè)專用承載后，如果RRC連接釋放進(jìn)入了IDLE，下次UE發(fā)起數(shù)據(jù)時(shí)會(huì)發(fā)起servicerequest，該過程會(huì)為默認(rèn)承載和專用承載建立對(duì)應(yīng)的DRB等參數(shù)。如果eNB建立專用承載失敗，則回復(fù)給核心網(wǎng)Initialcontextsetupresponse，帶失敗列表，告知核心網(wǎng)專用承載建立失敗，核心網(wǎng)會(huì)本地去激活該專用承載；同時(shí)RRCConnectionReconfiguration消息也不會(huì)帶該專用承載的DRB，UE收到后發(fā)現(xiàn)該專用承載對(duì)應(yīng)的DRB沒有建立起來，也會(huì)本地去激活該承載，這樣UE和核心網(wǎng)承載保持一致。流程圖同2.1正常流程。3.2.6eNB建立默認(rèn)承載失敗場(chǎng)景同上，當(dāng)建立的這個(gè)專用承載也為非GBR承載時(shí)，eNB可能會(huì)成功建立該專用承載，而失敗建立默認(rèn)非GBR承載，這樣回復(fù)給核心網(wǎng)Initialcontextsetupresponse，帶失敗列表，核心網(wǎng)發(fā)現(xiàn)默認(rèn)承載建立失敗時(shí)，會(huì)本地detach該UE；同時(shí)RRCConnectionReconfiguration消息也不會(huì)帶該默認(rèn)承載的DRB，UE收到后發(fā)現(xiàn)默認(rèn)承載對(duì)應(yīng)的DRB沒有建立起來，也會(huì)本地去激活該默認(rèn)承載，以及關(guān)聯(lián)的專用承載，從而本地detach（只有一個(gè)默認(rèn)承載時(shí)），這樣UE和核心網(wǎng)承載保持一致。流程圖如下：4網(wǎng)絡(luò)發(fā)起的paging流程4.1S_TMSI尋呼UE在IDLE模式下，當(dāng)網(wǎng)絡(luò)需要給該UE發(fā)送數(shù)據(jù)（業(yè)務(wù)或者信令）時(shí)，發(fā)起尋呼過程，流程圖如下：4.2IMSI尋呼當(dāng)網(wǎng)絡(luò)發(fā)生錯(cuò)誤需要恢復(fù)時(shí)（例如S-TMSI不可用），可發(fā)起IMSI尋呼，UE收到后執(zhí)行本地detach，然后再開始attach。5TAU流程：當(dāng)UE進(jìn)入一個(gè)小區(qū)，該小區(qū)所屬TAI不在UE保存的TAIlist內(nèi)時(shí)，UE發(fā)起正常TAU流程，分為IDLE和CONNECTED（即切換時(shí)）下。如果TAUaccept分配了一個(gè)新的GUTI，則UE需要回復(fù)TAUcomplete，否則不用回復(fù)。5.1正常流程5.1.1IDLE下發(fā)起的IDLE下，如果有上行數(shù)據(jù)或者上行信令（與TAU無關(guān)的）發(fā)送，UE可以在TAUrequest消息中設(shè)置an"active"標(biāo)識(shí)，來請(qǐng)求建立用戶面資源，并且TAU完成后保持NAS信令連接。如果沒有設(shè)置"active"標(biāo)識(shí)，則TAU完成后釋放NAS信令連接。IDLE下發(fā)起的也可以帶EPSbearercontextstatusIE，如果UE帶該IE，MME回復(fù)消息也帶該IE，雙方EPS承載通過這個(gè)IE保持同步。IDLE下發(fā)起的不設(shè)置"active"標(biāo)識(shí)的正常TAU流程圖如下：說明：1）如果TAUaccept未分配一個(gè)新的GUTI，則無過程11、12；2）步驟1～5完成RRC連接建立，步驟6、9完成S1連接建立；3）步驟13～15釋放NAS信令連接，IDLE下發(fā)起的不設(shè)置"active"標(biāo)識(shí)時(shí)，核心網(wǎng)在完成TAU后會(huì)釋放NAS信令連接。IDLE下發(fā)起的設(shè)置"active"標(biāo)識(shí)的正常TAU流程圖如下：5.1.2CONNECTED下發(fā)起的說明：1）如果TAUaccept未分配一個(gè)新的GUTI，則無過程6、7；2）切換下發(fā)起的TAU，完成后不會(huì)釋放NAS信令連接；3）CONNECTED下發(fā)起的TAU，不能帶"active"標(biāo)識(shí)。5.2異常流程異常流程同3.2。6去附著6.1關(guān)機(jī)去附著UE關(guān)機(jī)時(shí)，需要發(fā)起去附著流程，來通知網(wǎng)絡(luò)釋放其保存的該UE的所有資源，流程圖如下：說明：1）IDLE和CONNECTED下發(fā)起的區(qū)別同上面TAU的區(qū)別；2）如果是非關(guān)機(jī)去附著，則會(huì)收到MME的DetachAccept響應(yīng)消息和eNB的RRCConnectionRelease消息。6.2非關(guān)機(jī)去附著IDLE下發(fā)起的非關(guān)機(jī)去附著CONNECTED下發(fā)起的非關(guān)機(jī)去附著7切換流程當(dāng)UE在CONNECTED模式下時(shí)，eNodeB可以根據(jù)UE上報(bào)的測(cè)量信息來判決是否需要執(zhí)行切換，如果需要切換，則發(fā)送切換命令給UE，UE不區(qū)分切換是否改變了eNodeB。非競(jìng)爭(zhēng)切換流程圖如下：8專用承載建立流程8.1正常流程專用承載建立可以由UE或者M(jìn)ME主動(dòng)發(fā)起，eNB不能主動(dòng)發(fā)起，并且只能在connected下發(fā)起該流程。說明：1）如果是MME主動(dòng)發(fā)起的承載建立流程，則無步驟1、2；2）UE發(fā)起的承載建立流程，核心網(wǎng)可以回復(fù)承載建立、修改流程；3）可以同時(shí)建立多個(gè)專用承載，但目前還不支持。8.2異常流程8.2.1核心網(wǎng)拒絕1）如果拒絕原因值是"unknownEPSbearercontext"，UE會(huì)本地去激活存在的默認(rèn)承載。8.2.2eNB本地建立失?。ê诵木W(wǎng)主動(dòng)發(fā)起的建立）如果eNB建立失敗，會(huì)回復(fù)E-RABSETUPRESPONSE，帶失敗建立的承載列表，并帶原因值，核心網(wǎng)應(yīng)該根據(jù)原因值處理（目前eNB的實(shí)現(xiàn)是：如果eNB本地建立失敗，即還沒有給UE發(fā)送RRC重配消息，這時(shí)eNB會(huì)發(fā)送NASNONDELIVERYINDICATION給MME）。但目前核心網(wǎng)沒有查看原因值，都給UE下發(fā)了DeactivateEPSbearercontextrequest消息（與協(xié)議不符），UE