CSFB業(yè)務流程中MME和CSFBMSC尋呼參數(shù)設置研究圖文精

1、CSFB 業(yè)務流程中(MME 和 CSFB MSC尋呼參數(shù)設置研究1. 引言CS Fallback語音業(yè)務,是一種協(xié)議規(guī)定的電路域回落語音解決方案。用戶 同時注冊在 EPS (Evolved Packet System網(wǎng)絡和傳統(tǒng)的電路域網(wǎng)絡,發(fā)起語音 業(yè)務時,由 EPS 網(wǎng)絡指示用戶回落到目標電路域網(wǎng)絡之后,再發(fā)起語音業(yè)務。 該語音解決方案就是 Circuit Switched Fallback in Evolved Packet System, 簡稱 CS Fallback (或 CSFB 。在 CSFB 過程中,存在一個重要的流程 尋呼,不同設 備上尋呼參數(shù)的設置對于業(yè)務流程成功和用戶感知

2、都有非常重要的影響, 本文主 要討論一下 MME 和 CSFB MSC上尋呼參數(shù)的設置。2. CSFB實現(xiàn)原理LTE 網(wǎng)絡部署初期,一般是 LTE 做熱點覆蓋。此時 LTE 覆蓋的面積小,且 連續(xù)覆蓋小。 從 LTE 是后期建網(wǎng)來考慮, 在 LTE 建網(wǎng)時應合理地規(guī)劃 TA(Tracking Area , 即將 TA 覆蓋范圍的 2G/3G LA(Location Area規(guī)劃為由同一個 MSC Server管理, 這樣, 當 UE 做聯(lián)合 TA/LA更新時, 才能做 LA 更新選擇到當前 2G/3G RAN對應的 MSC Server,以盡量避免 MSC Server更新不及時而導致漫游重呼

3、(Roaming Retry的發(fā)生。 MME 可以覆蓋多個熱點地區(qū), 采用 IP 組網(wǎng)和多個 MSC Server 相連。需要在 MME 上配置數(shù)據(jù),將 TA 映射成對應的 VLR number,從 而選定對端 SGs 接口的 MSC Server。2.1 網(wǎng)絡架構圖CS Fallback是通過重用 Gs 接口的方法來實現(xiàn)的,即 MME (Mobility Management Entity和 MSC (Mobile Switching Center Server 之間存在一個類 似現(xiàn)有 SGSN (Serving GPRS Support Node和 MSC Server之間 Gs 接口的

4、SGs 接口。 CS Fallback邏輯架構如圖 1所示。 圖 1 CS Fallback邏輯架構2.2 SGs接口CS Fallback特性中,最主要的接口是 SGs 接口,它是 MME 和 MSC Server之間的接口, 用來處理 EPS 和 CS 域之間的移動性管理和語音業(yè)務尋呼。 SGs 接 口中, SGsAP (SGs Application Part作為 SGs 的應用層協(xié)議。 SCTP 協(xié)議作為 傳輸層協(xié)議,用于保證傳輸?shù)目煽啃?。該接口可實現(xiàn)功能如下:1 移動性管理:SGs 接口類似于 3G 的 Gs 接口,通過該接口可以完成聯(lián)合附著、聯(lián)合位置更新、 IMSI/EPS det

5、ach功能。2 語音尋呼:UE 的主叫業(yè)務不經(jīng)過 SGs 接口,因為 MME 收到帶有 UE 發(fā)送的 CSFB 標識(指示回落后,直接通過 eNodeB 指示 UE 回落到 CS 域。 當 UE 有被叫業(yè)務時, Paging 消息經(jīng) CS 發(fā)送到 MME , 由 MME 發(fā)起回落流程。被叫回落流程和主叫回落流程類似。SMS 傳輸功能:對于 SMS 業(yè)務, EPC 網(wǎng)絡并不會要求終端回落到傳統(tǒng)電路 域再發(fā)送或者接收短消息,而是直接在 EPC 網(wǎng)絡中用 LTE NAS信令直接傳遞, 大幅提升了 SMS 業(yè)務效率。SGs 接口協(xié)議棧如圖 2所示。 圖 2 SGs接口協(xié)議棧2.3 語音主叫業(yè)務如圖 3

6、所示, UE 發(fā)起 CS Fallback語音主叫業(yè)務, MME 指示 eNodeB (evolved NodeB 需要將 UE 回落到 GERAN/UTRAN網(wǎng)絡, eNodeB 指示 UE 回落到 GERAN/UTRAN網(wǎng)絡, UE 在 GERAN/UTRAN網(wǎng)絡發(fā)起主叫語音業(yè)務。 圖 3 語音主叫流程1. UE 發(fā)起 CS Fallback語音業(yè)務請求。2. (可選 MME 向 MSC Server發(fā)送 SGsAP-SERVICE-REQUEST 消息, 攜帶信元 MO Fallback indicator,指示主叫側 UE 回落。3. MME 發(fā)送 S1-AP UE CONTEXT M

7、ODIFICATION REQUEST消息給 eNodeB ,包含 CS Fallback Indicator。該消息指示 eNodeB , UE 因 CS Fallback業(yè)務需要回落到 UTRAN/GERAN。4. eNodeB 要求 UE 開始系統(tǒng)的小區(qū)測量,并獲得 UE 上報的測量報告,確定重定向的 目標系統(tǒng)小區(qū)。然后向 UE 發(fā)送目標系統(tǒng)具體的無線配置信息,并釋放連接。5. UE 接入目標系統(tǒng)小區(qū),發(fā)起 CS 域的業(yè)務請求 CM Service Request。6. 如果目標系統(tǒng)小區(qū)歸屬的 MSC Server與 UE 附著 EPS 網(wǎng)絡時登記的 MSC Server不 同,則該 M

8、SC Server收到 UE 的業(yè)務請求時,由于沒有該 UE 的信息,可以采取隱 式位置更新流程,接受用戶請求。如果 MSC Server不支持隱式位置更新,且 MSC Server 沒有用戶數(shù)據(jù)(即服務 MSC Server與 EPS/IMSI登記的 MSC Server不同, 則拒絕該用戶的業(yè)務請求。 如果 MSC Server拒絕用戶的業(yè)務請求會導致 UE 發(fā)起一 個 CS 域位置更新流程。7. CS 域語音呼叫建立流程。2.4 語音被叫業(yè)務如圖 4所示, MSC Server收到對 UE 的被叫語音請求,通過存在的 SGs 關 聯(lián)和 MME 信息,向該 MME 發(fā)起尋呼請求。 MME

9、通過 eNodeB 在空口尋呼該 UE ,并指示 UE 回落到目標 GERAN/UTRAN網(wǎng)絡。 UE 接入到目標網(wǎng)絡后,在 電路域繼續(xù)進行語音呼叫。圖 4 語音被叫流程 1. MSC Server收到入局 IAM 消息。2. MSC Server根據(jù)存在的 SGs 關聯(lián)和 MME 信息,發(fā)送 SGsAP-PAGING-REQUEST 消息 (攜帶 IMSI , TMSI , Service indicator , CLI , LAC , Channel needed信元 給 MME 。3. MME 發(fā)送 Paging 消息給 eNodeB 。 eNodeB 發(fā)起空口的 Paging 流程。4

10、. UE 建立連接并發(fā)送 Extended Service Request消息給 MME 。5. MME 發(fā)送 SGsAP-SERVICE-REQUEST 消息給 MSC Server 。 MSC Server 收到此消息,不再向 MME 重發(fā)尋呼請求消息。為避免呼叫接續(xù)過程中,主叫等待時間過長, MSC Server收到 包含空閑態(tài)指示的 SGsAP-SERVICE-REQUEST 消息,先通知主叫,呼叫正在接續(xù)過程中。 6. MME 發(fā)送 Initial UE Context Setup消息給 eNodeB ,包含 CS Fallback Indicator。該 消息指示 eNodeB ,

11、 UE 因 CSFB 業(yè)務需要回落到 UTRAN/GERAN。7. UE 從 E-UTRAN 回落到 UTRAN/GERAN。8. 伴隨著空口、 A/Iu-CS接口連接的建立, UE 回 Paging Response消息或者位置更新請求 消息給 MSC Server。即使 BSC/RNC沒有向該 UE 發(fā)起過尋呼請求,這里的 BSC/RNC需要 能處理 UE 的尋呼響應。如果尋呼響應消息中的位置區(qū)信息和 VLR 中保存的不一致,則 VLR 在業(yè)務接入成功之后將 SGs 關聯(lián)置為沒有關聯(lián)。9. MSC Server收到 UE 的尋呼響應后,停掉尋呼響應定時器并建立 CS 連接。3. CSFB中

12、的尋呼流程CSFB 組網(wǎng)下, 當用戶作為被叫時, MSC Server會通過 SGs 接口下發(fā) Paging Request 消息, MME 尋呼手機, 并指示 UE 需要回落到 2G/3G, UE 在回落到 2G/3G后,向 MSC Server回應尋呼響應,如圖 5所示。圖 5 CSFB終結語音呼叫流程針對此流程有個關鍵點需要關注:1、 無線側 RNC/BSC一定要配置正確的 4G 鄰區(qū), 否則會導致無法收到 Paging Response 尋呼響應消息,對該 4G 用戶的終結呼叫拆線。 2、核心網(wǎng)側(MME 和 CSFB MSC一定要配置正確的尋呼策略和尋呼時 長,否則會發(fā)生 UE 回應

13、尋呼響應時, MSC 側已尋呼超時,對該 4G 用戶終結呼 叫拆線。以下主要討論 MME 和 CSFB MSC上尋呼策略和尋呼時長的設置。3.1 現(xiàn)網(wǎng)信令追蹤消息分析為了更好的說明相關尋呼參數(shù)的設置, 我們先來看一段在 MME 設備上抓取 的現(xiàn)網(wǎng) CSFB 流程語音被叫業(yè)務的消息追蹤,結合信令消息進行分析說明。 圖 6 跟蹤消息截圖從追蹤的消息來看, CSFB MSC通過 SGS 接口一共向 MME 發(fā)送了三次 SGSAP_MM_PAGING_REQ,第一次發(fā)送之后等待了 6S 發(fā)起第二次,第二次發(fā) 送之后等待了 5S 發(fā)起第三次, 沒有發(fā)起第四次, 所以 CSFB MSC上設置的尋呼 次數(shù)一

14、共是三次, 時長應該是 6S-5S-XS , 這個 “X” 表示根據(jù)現(xiàn)有的消息無法判斷 第三次發(fā)起后 CSFB MSC的等待時長。 但是, 在第三次發(fā)起之后等待了 6S , MME 出現(xiàn)了一條內(nèi)部消息 AC_US_RESET_CONN_RSP,如圖 7所示。 圖 7 AC_US_RESET_CONN_RSP這條消息的內(nèi)容是e-MM-TIMEOUT-REGISTIDLE-WAIT-EXTENDED-SERVICE-REQ , 從這條消息 可以看出,第三次 SPU_S1AP_PAGING_REQ流程超時了,而超時是由 MME 判 斷的,而且超時后并沒有任何消息通過 SGS 接口反饋給 CSFB M

15、SC。3.2 MME 尋呼相關參數(shù)的設置 3.1 節(jié)中對現(xiàn)網(wǎng)信令追蹤消息做了分析，可以看出只有在第三次的 SPU_S1 AP_PAGING_REQ 流程超時后， MME 發(fā)揮了作用， 在內(nèi)部消息中判斷流程超時， 并記錄了 CHR，之后也沒有觸發(fā)其他動作，那么在 MME 上，尋呼參數(shù)到底是 怎么設置的呢？ 查詢 EMM（EPS Mobility Management）參數(shù)： LST EMM:; %LST EMM:;% RETCODE = 0 操作成功 T3422(s = 6 N3422(次數(shù) = 4 T3450(s = 6 N3450(times = 4 T3460(s = 6 N3460(ti

16、mes = 4 T3470(s = 6 N3470(times = 4 T3412(min = 54 T3402(min = 12 T3413(s = 6 N3413(times = 2 重尋呼間隔遞增值(s = 0 移動可達定時器(min = 58 不可達用戶隱式分離定時器(min = 0 GUTI 重分配定時器(h = 0 Attach 或 TAU 中重分配 GUTI = 重分配 GUTI Handover 準備定時器(s = 10 源側 Handover 完成定時器(s = 10 目標側 Handover 完成定時器(s = 10 T3 定時器(s = 10 切換流程資源釋放定時器定時器

17、(s = 2 (結果個數(shù) = 1 -END 根據(jù)現(xiàn)網(wǎng)的配置，和尋呼相關的參數(shù)有兩個 T3413 和 N3413: 1、 T3413 參數(shù)的含義為： 此定時器用于控制 MME 發(fā)起尋呼與 UE 響應的時 間間隔。在 MME 發(fā)送 Paging Request 消息后啟動，在收到 Service Request 消息 后停止，超時后，MME 重發(fā) Paging Request 消息。 2、N3413 參數(shù)的含義為：該參數(shù)用于指定在尋呼流程中，沒有收到 UE 的 響應消息，MME 重復發(fā)送 Paging Request 消息的次數(shù)。 也就是說 MME 設置的尋呼方式是一共尋呼 3 次，每次等待 6S

18、，一共 18S 后沒有收到回應，認為尋呼超時。從 3.1 節(jié)中的消息看出，在 CSFB 業(yè)務流程中 MME 收到 SGS 接口的 SGSAP_MM_PAGING_REQ 的消息后就下發(fā)尋呼，但是 時間間隔并不是每次都是 6S，而且第二次、第三次的尋呼都收收到 SGS 接口的 SGSAP_MM_PAGING_REQ 的消息后發(fā)起的， 也就是說， MME 設備上的尋呼參 數(shù)幾乎沒有生效。在 CSFB 流程中發(fā)起的尋呼究竟應該遵循什么原則呢？從 3GPP 規(guī)范中我們可以看出一些端倪，如圖 8 所示。 圖 8 3GPP TS 23.272 V12.1.0 3GPP 協(xié)議 TS 23.272 V12.1

19、.0 版本中第 7 節(jié)有描述，MSC 負責 SGS 接口上 尋呼消息的定時器、排隊和轉發(fā)，而 MME 不使用本身的尋呼方案。這就解釋了 3.1 節(jié)中消息的表現(xiàn)。為了進一步印證這一原則，我們把 MME 上的 T3413 修改 為 4S，N3413 仍然為 2，再一次進行消息跟蹤，如圖 9 所示。 圖 9 跟蹤消息截圖 從抓取的消息可以驗證 MME 確實遵循了協(xié)議的規(guī)定， 不使用自身的尋呼方 案，第一次尋呼 4S 超時后，MME 只是自身記錄了尋呼超時，但是沒有觸發(fā)任 何其他的動作，等待第二次收到 SGS 接口發(fā)來的尋呼消息后，才出發(fā)了第二次 尋呼。接下來，我們需要驗證 CSFB MSC 設備上是

20、否確實設置的尋呼方案為 3 次，且間隔為 6S-5S-XS。 3.3 CSFB MSC 尋呼相關參數(shù)的設置 我們在 CSFB MSC 上查詢相關參數(shù)： %LST PGCTRL:;% RETCODE = 0 操作成功。 LAI 號碼 = e 尋呼類型 = 所有尋呼類型 呼叫優(yōu)先級 = 所有優(yōu)先級 緊急容災數(shù)據(jù)標志 = 否 尋呼次數(shù) = 3 首次尋呼時長 = 6 第二次尋呼時長 = 5 第三次尋呼時長 = 4 第四次尋呼時長 = 4 第五次尋呼時長 = 4 TMSI/IMSI 指示 = 首次尋呼(0-使用 TMSI = 第二次尋呼(0-使用 TMSI = 第三次尋呼(0-使用 TMSI = 第四次尋呼(0-使用 TMSI = 第五次尋呼(0-使用 TMSI 所有 RAN 尋呼指示 = 首次尋呼(0-1 個 LAI = 第二次尋呼(0-1 個 LAI = 第三次尋呼(0-1 個 LAI = 第四次尋呼(0-1 個 LAI = 第五次尋呼(0-1 個 LAI LAI 類型 = LAI -END 下面來解讀下 CSFB MSC 上尋呼參數(shù)的配置： 1、LAI 號碼中“e”為通配符，表示所