S1AP基本信令流程.doc

S1AP基本信令流程1. 概述LTE的系統(tǒng)架構(gòu)分為兩部分，包括演進(jìn)后的核心網(wǎng)EPC（MME/S-GW）和演進(jìn)后的接入網(wǎng)E-UTRAN。演進(jìn)后的系統(tǒng)僅存在分組交換域。LTE接入網(wǎng)僅由演進(jìn)后的節(jié)點(diǎn)B（evolved NodeB）組成，提供到UE的E-UTRA控制面與用戶(hù)面的協(xié)議終止點(diǎn)。eNB之間通過(guò)X2接口進(jìn)行連接。LTE接入網(wǎng)與核心網(wǎng)之間通過(guò)S1接口進(jìn)行連接，S1接口支持多-多聯(lián)系方式。與3G網(wǎng)絡(luò)架構(gòu)相比，接入網(wǎng)僅包括eNB一種邏輯節(jié)點(diǎn)，網(wǎng)絡(luò)架構(gòu)中節(jié)點(diǎn)數(shù)量減少，網(wǎng)絡(luò)架構(gòu)更加趨于扁平化。扁平化網(wǎng)絡(luò)架構(gòu)降低了呼叫建立時(shí)延以及用戶(hù)數(shù)據(jù)的傳輸時(shí)延，也會(huì)降低OPEX與CAPEX。1.1 E-UTRAN接口的通用協(xié)議模型E-UTRAN接口的通用協(xié)議模型如下圖所示，適用于E-UTRAN相關(guān)的所有接口，即S1和X2接口。1.2 S1接口S1接口是MME/S-GW網(wǎng)關(guān)與eNB之間的接口，S1接口與3G UMTS系統(tǒng)Iu接口的不同之處在于，Iu接口連接包括3G核心網(wǎng)的PS域和CS域，S1接口只支持PS域。1.2.1 S1接口的用戶(hù)平面用戶(hù)平面接口位于E-NodeB和S-GW之間，S1接口用戶(hù)平面（S1-UP）的協(xié)議棧如下圖所示。S1-UP的傳輸網(wǎng)絡(luò)層基于IP傳輸，UDP/IP之上的GTP-U用來(lái)傳輸S-GW與eNB之間的用戶(hù)平面PDU。1.2.2 S1接口控制面S1控制平面接口位于E-NodeB和MME之間，傳輸網(wǎng)絡(luò)層是利用IP傳輸，這點(diǎn)類(lèi)似于用戶(hù)平面；為了可靠的傳輸信令消息，在IP曾之上添加了SCTP；應(yīng)用層的信令協(xié)議為S1-AP。S1接口控制面協(xié)議棧如下圖所示：2. 典型信令流程分析2.1 開(kāi)機(jī)附著流程2.1.1 正常流程UE剛開(kāi)機(jī)時(shí)，先進(jìn)行物理下行同步，搜索測(cè)量進(jìn)行小區(qū)選擇，選擇到一個(gè)suitable或者acceptable小區(qū)后，駐留并進(jìn)行附著過(guò)程。附著流程圖如下：說(shuō)明：1) 步驟12會(huì)建立S1連接，標(biāo)志著NAS signaling connection建立完成。2) 如果消息2帶了UE Radio Capability IE，則沒(méi)有4過(guò)程3) 發(fā)起UE上下文釋放（即811）的條件：-eNodeB-initiated with cause e.g. O&M Intervention, Unspecified Failure, User Inactivity, Repeated RRC signalling Integrity Check Failure, Release due to UE generated signalling connection release, etc.; or- MME-initiated with cause e.g. authentication failure, detach, etc.4) 消息3說(shuō)明：該消息為MME向eNB發(fā)起的初始上下文建立請(qǐng)求，請(qǐng)求eNB建立承載資源，同時(shí)帶安全上下文，可能帶用戶(hù)無(wú)線能力、切換限制列表等參數(shù)。UE的安全能力參數(shù)是通過(guò)attach request消息帶給核心網(wǎng)的，核心網(wǎng)再通過(guò)該消息送給eNB。UE的網(wǎng)絡(luò)能力（安全能力）信息改變的話，需要發(fā)起TAU。2.1.2 異常流程case1（核心網(wǎng)拒絕）2.1.3 異常流程case2（RRC重配消息丟失或者沒(méi)收到RRC重配完成消息或者eNB內(nèi)部配置UE的安全參數(shù)等失敗）2.2 UE發(fā)起的service request流程2.2.1 正常流程UE在IDLE模式下，需要發(fā)送業(yè)務(wù)數(shù)據(jù)時(shí)，發(fā)起service request過(guò)程，流程圖如下：2.2.2 異常流程case1（核心網(wǎng)拒絕）2.2.3 異常流程case2（RRC重配消息丟失或者eNB內(nèi)部配置UE的安全參數(shù)失敗或者沒(méi)有建立起來(lái)一個(gè)非GBR承載）同2.1.32.2.4 異常流程case3（eNB建立專(zhuān)用承載失?。┤绻鹐NB建立專(zhuān)用承載失敗，則回復(fù)給核心網(wǎng)Initial context setup response，帶失敗列表，告知核心網(wǎng)專(zhuān)用承載建立失敗，核心網(wǎng)會(huì)本地去激活該專(zhuān)用承載。流程圖同2.2.1正常流程。2.2.5 異常流程case4（eNB建立默認(rèn)承載失?。?.3 網(wǎng)絡(luò)發(fā)起的paging流程2.3.1 S_TMSI尋呼UE在IDLE模式下，當(dāng)網(wǎng)絡(luò)需要給該UE發(fā)送數(shù)據(jù)（業(yè)務(wù)或者信令）時(shí)，發(fā)起尋呼過(guò)程，流程圖如下：2.3.2 IMSI尋呼當(dāng)網(wǎng)絡(luò)發(fā)生錯(cuò)誤需要恢復(fù)時(shí)（例如S-TMSI不可用），可發(fā)起IMSI尋呼，UE收到后執(zhí)行本地detach，然后再開(kāi)始attach。2.4 TAU流程去附當(dāng)UE進(jìn)入一個(gè)小區(qū)，該小區(qū)所屬TAI不在UE保存的TAI list內(nèi)時(shí)，UE發(fā)起正常TAU流程，分為IDLE和CONNECTED（即切換時(shí)）下。如果TAU accept分配了一個(gè)新的GUTI，則UE需要回復(fù)TAU complete，否則不用回復(fù)。2.4.1 正常流程case1（IDLE下發(fā)起的）IDLE下，如果有上行數(shù)據(jù)或者上行信令（與TAU無(wú)關(guān)的）發(fā)送，UE可以在TAU request消息中設(shè)置an active標(biāo)識(shí)，來(lái)請(qǐng)求建立用戶(hù)面資源，并且TAU完成后保持NAS信令連接。如果沒(méi)有設(shè)置active標(biāo)識(shí)，則TAU完成后釋放NAS信令連接。IDLE下發(fā)起的不設(shè)置active標(biāo)識(shí)的正常TAU流程圖如下：說(shuō)明：1）如果TAU accept未分配一個(gè)新的GUTI，則無(wú)過(guò)程6；2.4.2 正常流程case2（CONNECTED下發(fā)起的）說(shuō)明：1）如果TAU accept未分配一個(gè)新的GUTI，則無(wú)過(guò)程4；2）CONNECTED下發(fā)起的TAU，完成后不會(huì)釋放NAS信令連接；不能帶active標(biāo)識(shí)。2.4.3 異常流程同2.2.22.2.52.5 去附著流程2.5.1 關(guān)機(jī)去附著UE關(guān)機(jī)時(shí)，需要發(fā)起去附著流程，來(lái)通知網(wǎng)絡(luò)釋放其保存的該UE的所有資源，流程圖如下：說(shuō)明：IDLE和CONNECTED下發(fā)起的區(qū)別同上面TAU的區(qū)別；2.5.2 非關(guān)機(jī)去附著case1（IDLE下）2.5.3 非關(guān)機(jī)去附著case2（CONNECTED下）2.6 專(zhuān)用承載建立流程2.6.1 正常流程專(zhuān)用承載建立可以由UE或者M(jìn)ME主動(dòng)發(fā)起，eNB不能主動(dòng)發(fā)起，并且只能在connected下發(fā)起該流程。說(shuō)明：1）如果是MME主動(dòng)發(fā)起的承載建立流程，則無(wú)步驟1；2）UE發(fā)起的承載建立流程，核心網(wǎng)可以回復(fù)承載建立、修改流程；2.6.2 異常流程case1（核心網(wǎng)拒絕）2.6.3 異常流程case2（eNB本地建立失敗，核心網(wǎng)主動(dòng)發(fā)起的建立）如果eNB建立失敗，會(huì)回復(fù)E-RAB SETUP RESPONSE，帶失敗建立的承載列表，并帶原因值，核心網(wǎng)應(yīng)該根據(jù)原因值處理2.6.4 異常流程case3（eNB未等到RRC重配完成消息，回復(fù)失?。?.6.5 異常流程case4（UE NAS層拒絕）如果是UE的NAS層拒絕，則核心網(wǎng)收到后會(huì)給eNB發(fā)送E-RAB釋放消息，來(lái)釋放剛剛建立的S1承載，此時(shí)不帶NAS PDU。2.6.6 異常流程case5（上行直傳NAS消息丟失）如果核心網(wǎng)沒(méi)有收到UE回復(fù)的NAS消息，會(huì)重發(fā)請(qǐng)求消息，重發(fā)4次后，如果還沒(méi)收到應(yīng)答則放棄。2.7 專(zhuān)用承載修改流程專(zhuān)用承載修改可以由UE 、MME主動(dòng)發(fā)起，不能由eNB主動(dòng)發(fā)起，只能在connected下發(fā)起該流程。2.7.1 正常流程case1（修改QoS）說(shuō)明：1）MME主動(dòng)發(fā)起的承載建立/修改/釋放無(wú)步驟1；2）eNB主動(dòng)發(fā)起的釋放，步驟1改為發(fā)送E-RAB RELEASE INDICATION消息給MME；3）UE發(fā)起的承載修改流程，核心網(wǎng)可以回復(fù)承載建立、修改、釋放流程。2.7.2 正常流程case2（不修改QoS，只修改TFT）不修改QoS，只修改TFT參數(shù)時(shí)，為上下行直傳消息，與eNB無(wú)關(guān)。2.7.3 異常流程case1（核心網(wǎng)拒絕）如果拒絕原因值是unknown EPS bearer context，UE會(huì)本地去激活存在的專(zhuān)用承載。2.7.4 異常流程case2（eNB回復(fù)失?。〆NB回復(fù)失敗區(qū)分為：eNB本