S1AP基本信令流程.doc

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