【資料名稱】：A 國V CSFB 的方案設(shè)計和優(yōu)化

【資料作者】：陳金秀 Eric Xie Nan Zhang

【資料日期】：2013-06-13

【資料語言】：中文

【資料格式】：DOC

【資料目錄和簡介】：

A 國V CSFB 的方案設(shè)計和優(yōu)化

目錄

VHA LTE CSFB 方案設(shè)計和時延優(yōu)化介紹... 3

1概述... 3

1.1 VHA簡介... 3

1.2 VHA LTE 和UMTS 情況介紹... 3

1.3 VHA CSFB 業(yè)務(wù)流程... 3

1.4 VHA CSFB 流程缺陷... 4

2VHA CSFB 業(yè)務(wù)測試結(jié)果... 4

2.1 UE 側(cè)CSFB 業(yè)務(wù)時延分段結(jié)果... 4

2.2 RNC 側(cè)CSFB 業(yè)務(wù)時延分段結(jié)果... 7

2.3 UMTS SIB3 讀取時間和系統(tǒng)消息調(diào)度... 10

2.4 UMTS SRB 承載方式的分析... 12

2.5 RAB Setup Time的分析... 13

2.6 LTE 尋呼發(fā)送發(fā)送時間和可優(yōu)化范圍... 15

3VHA CSFB 業(yè)務(wù)優(yōu)化和測試結(jié)果的測試結(jié)果... 16

3.1 SRB 優(yōu)化調(diào)整的測試結(jié)果... 16

3.2 SIB 優(yōu)化的實驗室測試... 17

3.3 LTE 尋呼發(fā)送發(fā)送時間和可優(yōu)化范圍... 18

3.4 UMTS CellRLActive 優(yōu)化調(diào)整建議和解決方案... 18

4VHA CSFB 業(yè)務(wù)中核心網(wǎng)出現(xiàn)的問題... 20

4.1 CSMT 標(biāo)志造成被叫失敗... 20

4.2 CSFB Proxy + MSC Pooling造成2次LAU和被叫失敗... 21

4.3 基于PS Handover CSFB的高失敗率... 24

4.4 緊急呼叫時主叫號碼不能正常顯示... 25

5經(jīng)驗、教訓(xùn)和需求... 26

5.1 經(jīng)驗總結(jié)... 26

5.2 產(chǎn)品改進(jìn)建議... 27

5.2.1SIB 調(diào)度算法優(yōu)化建議... 27

5.3 交付和維護(hù)工具改進(jìn)建議... 27

5.3.13G PCHR 分析工具的建議... 27

5.4 交付方案的需求建議... 28

5.4.1整個CSFB 流程的指導(dǎo)... 28

5.4.23G 復(fù)雜場景下時延的Checklist 和 指導(dǎo)... 28

5.4.3LTE 尋呼相關(guān)算法文檔需求... 29


VHA LTE CSFB 方案設(shè)計和時延優(yōu)化介紹
1
概述1.1
VHA簡介VHA全稱Vodafone Hutchison Australia, 由澳大利亞Hutchison電信和Vofafone集團(tuán)以50%－50%合資，成立于2009年；在與3Gis合并之后，VHA用戶數(shù)接近700萬，成為澳大利亞第三大電信運營商（Telstra第一，930萬用戶，Optus第二），占據(jù)27%的市場份額，年財政收入40億。
1.2
VHA LTE 和UMTS 情況介紹VHA 是澳洲最后建設(shè)LTE 網(wǎng)絡(luò)的, 但客戶對LTE 網(wǎng)絡(luò)期望很高。 直接采用了20MHz 的頻譜建設(shè)LTE，期望在LTE上能夠打一個翻身仗。 VHA UMTS 網(wǎng)絡(luò)由于是Vodafone 和Huchison 網(wǎng)絡(luò)合并而成，地理分布不是很理想，覆蓋不好。
而且頻率很多，共有4個2100MHz的UMTS 頻點， 2個U850 的頻點，部分郊區(qū)還有1個U900 的頻率。 UMTS 多載波組網(wǎng)復(fù)雜。


1.3
VHA CSFB 業(yè)務(wù)流程
1.4
VHA CSFB 流程缺陷VHA由于核心網(wǎng)版本問題，采用了CSFB代理方案。造成了CSFB的時延過長，每一次CSFB都要做位置區(qū)更新，增加平均3S的時延。

2
VHA CSFB 業(yè)務(wù)測試結(jié)果2.1
UE 側(cè)CSFB 業(yè)務(wù)時延分段結(jié)果現(xiàn)場根據(jù)信令結(jié)果，把整個LTE2LTE的流程劃分為9個階段，并且對每個階段和競爭對手相比。下面是整個CSFB UE 側(cè)的分段對比結(jié)果。

	Stage 1: CSFB request to RRCRelease on LTE	Stage 2: LTE RRCRelease to 1st 3G message	Stage 3: 1st 3G message to CM Service Req	Stage 4: CM Service Req to CM Service Accept	Stage 5: CM Service Accept to MT CSFB Request	Stage 6: MT: CSFB request to RRCRelease on LTE	Stage 7: MTTE RRCRelease to 1st 3G message	Stage 8: MT: 1st 3G message to LAU Success	Stage 9: MTAU Success to Alerting
V	0.1832	0.4041	4.6562	0.3262	1.3547	0.1943	0.4025	4.916	4.8217
T	0.2626	0.419	2.2084	0.1244	1.4145	0.229	0.4257	1.9089	1.4241

針對V出現(xiàn)的時延比較大的階段3，8，9， 又做了進(jìn)一步的時延分段處理。 其中3 和 8 的流程主被叫是一樣的，所以分段分析以被叫8,9 為主。

Stage 8 breakdown	stage 8-1: 1st 3G message to RRC setup request	Stage 8-2: RRC setup request to LAU Request	stage 8-3: LAU request to LAU Accept
V	1.284	0.394	3.2187
T	0.1344	0.3406	1.434

Stage 9 Breakdown	Stage 9-1: LAU Accept to Call confirmed	Stage 9-2: Call confirm to Alerting
V	1.281	3.5704
T	0.1395	1.2847

現(xiàn)場對比了V 和 T 兩家主要不同的詳細(xì)信令。
V：1st 3G message to RRC setup request

T：1st 3G message to RRC setup request

V：Location Updating Request to Location Updating Accept


T：Location Updating Request to Location Updating Accept



V: LAU Accept to Call confirmed

T: LAU Accept to Call confirmed

V:
Call confirm to Alerting



T: Call confirm to Alerting



通過初步的分析，發(fā)現(xiàn)Stage8-1 的流程，UE 收到了很多SIB消息后才發(fā)起RRC建立，其中每次建立發(fā)起都是在SIB3 消息收到后發(fā)起；Stage 8-3 顯示了整個LAU 的流程V 比T 長很多，而且多了幾個Identity Request 的消息請求。其他流程也有一些差別，但總體流程消息差異不大。 區(qū)別在時延特別大。
2.2
RNC 側(cè)CSFB 業(yè)務(wù)時延分段結(jié)果由于UE側(cè)時延分段，不能區(qū)分出時延究竟由于核心網(wǎng)產(chǎn)生的還是由于RAN 產(chǎn)生的， 現(xiàn)場又根據(jù)RNC 信令跟蹤對RAN 側(cè)時延做了詳細(xì)分段分析。 RNC 時延分段就更加細(xì)化分析， 把每個主要和核心網(wǎng)的交互過程都分段開。 下面是詳細(xì)的分段過程， 通過這個分段過程，我們得出了下面一些重點分析點。

No.	問題描述	問題界面
1	SIB3 讀取時間過長	RAN
2	平均RAN 側(cè)處理時延大大超過其他網(wǎng)絡(luò).	RAN
3	核心網(wǎng)時間處理時間過長從"Identity Response" 到 "Authentication request"(390ms)	Core
4	核心網(wǎng)是否可以減少"Identity Request"	Core
5	核心網(wǎng)時間處理時間過長從"tmsi-reallocation-complete" 到 "setup".(1080ms)	Core
6	核心網(wǎng)時間處理時間過長從"Identity Response" 到 "Location update Accept"? (390ms)	Core
7	核心網(wǎng)時間處理時間過長從 "Call Confirm"to "RAB Assignment Req" (1190ms)	Core
8	RAN 側(cè)時間處理時間過長從 RAB Assignment Request 到 RAB Assignment Response (1780ms)	RAN
9	核心網(wǎng)所有信令處理方案都是串行,為什么不能并行.	Core

2.3
UMTS SIB3 讀取時間和系統(tǒng)消息調(diào)度現(xiàn)場通過分析，發(fā)現(xiàn)只有在UE讀取SIB3 后才會發(fā)起RRC Setup Request 的消息，通過分析，由于SIB3 中包含了小區(qū)接入準(zhǔn)許和最小接入電平，UE 只有在讀取SIB3 后才能接入到UMTS 網(wǎng)絡(luò)中，但V的SIB3的調(diào)度周期(1280ms)遠(yuǎn)遠(yuǎn)大于T的SIB3 調(diào)度周期（160ms）, UE 不停地讀取SIB3 的消息。

VHA 的SIB調(diào)度：














T的SIB3調(diào)度



由于T的鄰區(qū)比較少，現(xiàn)場還增加了另外一個鄰區(qū)較多的O的運營商對比數(shù)據(jù)。

同樣O的SIB3 調(diào)度頻率遠(yuǎn)遠(yuǎn)大于V的調(diào)度頻率。
從數(shù)據(jù)對比來看，T和O的調(diào)度算法把SIB3 調(diào)度頻率遠(yuǎn)遠(yuǎn)大于V的調(diào)度頻率。
2.4
UMTS SRB 承載方式的分析現(xiàn)場在對比分析了T和V 的SRB 承載方式后發(fā)現(xiàn)，T的SRB 承載13.6kbps 上，而V的承載，由于最初發(fā)起的RRC 建立請求的原因是使Register，所以SRB 建立在3.4kbps 上了。
T 的SRB 方式

V 的SRB 方式

V 的TTI是40ms, 接著檢查RRC Connection Request 消息，它原因值是：Registration

查了對應(yīng)的配置，在RNC 上配置確實是3.4kbps 的SRB。
2.5
RAB Setup Time的分析在測試過程中，RAB Setup 的流程時延非常長，達(dá)到1.8s 左右。 現(xiàn)場詳細(xì)對了一下時間，發(fā)現(xiàn)RB Setup Request 到RL Reconfiguration 之間間隔時間很長，達(dá)到1.2s, 經(jīng)過查詢。 這個時間和現(xiàn)網(wǎng)的定時器時間有比較大關(guān)系。




同時，客戶對整個3G 網(wǎng)絡(luò)的RAB Setup 的時間進(jìn)行了統(tǒng)計，發(fā)現(xiàn)這個時間存在兩個高峰。

目前參數(shù)MidRateRlActTimeDefOffVal 大部分站點配置70，為700ms，比Default的40（400ms）要超過300ms，這個導(dǎo)致站點的RAB 建立在Single RAB 的時間要長300ms.




2.6
LTE 尋呼發(fā)送發(fā)送時間和可優(yōu)化范圍在分析過程中，發(fā)現(xiàn)了E-NodeB從MME 接收到Paging的時間和從空口發(fā)出的時間不一樣， 需要華為解釋。


當(dāng)前paging周期配置為1280ms，從當(dāng)前參數(shù)的配置，Paging 延遲下發(fā)是正常的，現(xiàn)場又統(tǒng)計了10次Paging時間發(fā)現(xiàn)，分布比較合理。

	Paging from MME	Paging to UE	Offset
11	12.16.49:236	12.16.50.320	1.084
10	12.15.29:033	12.15.29:680	0.647
9	12.14.07:745	12.14.07:761	0.016
8	12.12.11:363	12.12.12:561	1.198
7	12.07.04:037	12.07.04:081	0.044
6	12.05.43:418	12.05.43:443	0.025
5	12.04.43:240	12.04.43:283	0.043
4	12.03.02:024	12.03.02:163	0.139
3	12.01.35:123	12.01.35:123	0
2	11.59.52:105	11.59.52:651	0.546
1	11.58.40:960	11.58.41:044	0.084

3
VHA CSFB 業(yè)務(wù)優(yōu)化和測試結(jié)果的測試結(jié)果3.1
SRB 優(yōu)化調(diào)整的測試結(jié)果根據(jù)現(xiàn)場的情況，現(xiàn)場對站點的SRB 進(jìn)行調(diào)整，從3.4kbps 道13.6kbps，通過測試，發(fā)現(xiàn)CSFB 的時延減少很多：

Testing Scenario	Average Access Time Delay(msec)	% improvement in Latency after change
MOC Default Parameter	17172	34.35
MOC Proposed Parameter	11273
MTC Default Parameter	9633	38.05
MTC Proposed Parameter	5968

起到了非常好的優(yōu)化效果。
3.2
SIB 優(yōu)化的實驗室測試通過機(jī)關(guān)反饋的現(xiàn)有SIB調(diào)度方案，在實驗室進(jìn)行了測試。發(fā)現(xiàn)以下結(jié)論：
在鄰區(qū)配置為中等偏多的時候，即SIB11 在9~12塊的時候，優(yōu)化后的算法增益最大，有0.21s，其他情況下幾乎沒有增益或者有負(fù)的增益。




只有兩個鄰區(qū)的情況








總體測試結(jié)果，優(yōu)化后的SIB調(diào)度方案比T 和 O的讀取時間仍然差好多。


3.3
LTE 尋呼發(fā)送發(fā)送時間和可優(yōu)化范圍根據(jù)機(jī)關(guān)，LTE 尋呼周期可以優(yōu)化為640ms, 這樣優(yōu)化帶來的增益是：在LTE 網(wǎng)絡(luò)中被叫尋呼時間縮短，從平均分布的場景來看平均可以縮短320ms。 負(fù)面影響是：會對手機(jī)用電和尋呼信道的容量造成影響。但這個流程目前只影響了LTE 作為被叫的情況，整個流程平均約300ms 的影響。 這個流程優(yōu)化暫時沒有實施。


3.4
UMTS CellRLActive 優(yōu)化調(diào)整建議和解決方案現(xiàn)場測試的結(jié)果是：對純粹的CS Single RAB 場景，通過優(yōu)化MidRateRlActTimeDefOffVal 從70 到40, 可以在單向縮短300ms 的時延，雙向接近600ms. 目前主要的LTE 雙模終端都會有PS業(yè)務(wù)，絕大部分場景都是Multi RAB場景。Multi RAB 場景下，如果PS RAB 新建，SRB 轉(zhuǎn)換成3.4kbps, 這樣RAB 建立時延優(yōu)化就是在OamGuardValForLowRate 的優(yōu)化處理。 從其他網(wǎng)絡(luò)經(jīng)驗來看， 在Multi-RAB場景下，CS 業(yè)務(wù)先建的概率大概有20%， PS RAB 先建的概率是80%。 目前修改低速業(yè)務(wù)的OamGuardValForLowRate 風(fēng)險很大，所以暫時不做優(yōu)化處理。
l
MidRateRlActTimeDefOffVal:Default time offset used for activating a new configuration if the reconfigured radio link (RL) transmits signaling at a rate of 13.6 kbit/s.
l
OamGuardValForMidRateTime :that the NodeB is allowed to take to process an NBAP RADIO LINK RECONFIGURATION COMMIT message during a reconfiguration if the reconfigured RL transmits signaling at a rate of 13.6 kbit/s.
l
PacketReTransRatio:Retransmission rate of signaling packets in scenarios with composite services.

l
The timer(Single service) = ( MidRateRlActTimeDefOffVal- OamGuardValForMidRateTime ) in current network is 500ms(70).Some cells will be 200ms(40).

l
OamGuardValForLowRate:Time that the NodeB is allowed to take to process an NBAP RADIO LINK RECONFIGURATION COMMIT message during a reconfiguration if the reconfigured RL transmits signaling at a rate of 3.4 kbit/s or 6.8 kbit/s.
l
ActTimeDefOffValForSameCellefault time offset used for activating a new configuration for a reconfiguration performed within the same cell if the reconfigured radio link transmits signaling at a rate of 3.4 kbit/s or 6.8 kbit/s.
l
PacketReTransRatio:Retransmission rate of signaling packets in scenarios with composite services.

l
The timer(Single service) = (ActTimeDefOffValForSameCell- OamGuardValForLowRate) in current network is 800ms.






4
VHA CSFB 業(yè)務(wù)中核心網(wǎng)出現(xiàn)的問題4.1
CSMT 標(biāo)志造成被叫失敗問題描述：
基于重定向的MO/MT CSFB時延較長且MT失敗率過高。
問題分析：
1. 通過Probe trace發(fā)現(xiàn)部分場景UE在收到Paging消息fallback到3G后，在LAU Accept后釋放了RRC。在RRC Release的時候，UE概率性收不到RNC下發(fā)的Paging消息，造成了被叫失敗。即使UE收到了Paging消息，但是由于呼叫之前需要再次連接RRC，也造成了一定的時延，如下圖所示。



經(jīng)調(diào)查發(fā)現(xiàn)客戶MSC版本為Pre-R8，沒有集成R9 Release的CSMT功能。CSMT是3GPP R9 Release新添加的標(biāo)志位，CSFB后UE在LAU請求里攜帶該標(biāo)志位，指示MSC不要在LAU Accept后釋放RRC，以免造成Paging無法收到等問題。

解決方案：
客戶MSC在打上CSMT補丁后，該問題解決。
4.2
CSFB Proxy + MSC Pooling造成2次LAU和被叫失敗問題描述：
基于重定向的MO/MT CSFB時延較長且MT失敗率過高。
問題分析：
1. 通過Probe trace發(fā)現(xiàn)UE收到Paging消息CSFB到3G，在首次LAU Accept后RRC被釋放，然后UE發(fā)起了第二次LAU請求并再次釋放了RRC。兩次LAU后UE才在3G側(cè)收到了Paging消息發(fā)起呼叫。兩次LAU并且兩次RRC釋放造成了時延過長，且UE概率性漏掉Paging消息造成被叫失敗。







2. 分析首次LAU Accept消息，發(fā)現(xiàn)MSC回復(fù)的LAC值并非該小區(qū)所在的實際LAC值990(Hex 03DE),而是一個現(xiàn)網(wǎng)不存在的LAC（Hex FFFA），造成了UE發(fā)起二次LAU請求，第二次LAU UE才拿到了正確的LAC值。


3. 經(jīng)核心網(wǎng)分析，MSC發(fā)送LAC Hex FFFA的原因是由于4G Combined Attach里CSFB Proxy分配的TMSI-NRI未在3G MSC注冊，造成3G MSC誤認(rèn)為該UE是從其他非Pool區(qū)漫游來的用戶，所以在LAU Accept里面發(fā)送了NBLAC（Hex FFFA），要求UE重新發(fā)起LAC選擇MSC Pool，以實現(xiàn)MSC Pool的負(fù)載平衡。


解決方案：
核心網(wǎng)將4G CSFB Proxy分配的NRI在3G MSC注冊后問題解決，UE在3G側(cè)只發(fā)起一次LAU請求，修改后時延縮短且被叫成功率達(dá)到100%。


4.3
基于PS Handover CSFB的高失敗率由于基于Blind Redirection 的CSFB 時延很高，現(xiàn)場嘗試使用基于PSHO 的CSFB 方案，但在測試過程中有大量的呼叫建立不成功。 呼叫建立不成功的主要原因是PS異系統(tǒng)切換成功率比較低，從信令流程來看， 主要失敗是MME觸發(fā)的， E-NodeB向MME發(fā)送切請求， MME 反饋切換請求失敗。

經(jīng)過多次測試下面是分析的結(jié)果：
l

如果CS Voice 請求發(fā)生在UMTS 向LTE后20 Seconds 后，這類失敗不會發(fā)生，如果在20 秒前， 這類失敗很容易發(fā)生；
l
如果DNS 選擇用來做PSHO的SGSN 和 原來3G 向LTE 重選的SGSN 是不同的SGSN，切換不會失��；
l
如果DNS 選擇用來做PSHO的SGSN 和 原來3G 向LTE 重選的SGSN 是相同的SGSN，并且這個間隔小于20s， 失敗率是100%；
l
基于Redirection 的CSFB 是成功的，只有基于HO的CSFB 才失敗。

通過核心網(wǎng)分析，根本原因在于：




u
在3G 重選回LTE 的過程中，如果Combined的HSS和HLR當(dāng)UE 移動到4G 時， HLR 需要向SGSN 發(fā)送“CancelLocation”；
u
如果UE 從3G 重選到4G，在T3 隧道定時器過期時，SGSN 會去除UE 的上下文。但如果CSFB 發(fā)生在UE 重選會LTE 20秒內(nèi)， SGSN仍然保留著UE的上下文， SGSN 會拒絕MME 發(fā)送的HO Requirement；
u
在VHA網(wǎng)絡(luò)由于HSS 和 HLR 是完全分離的，相互之間沒有聯(lián)系，HLR無法得知UE已經(jīng)回到4G并在HSS發(fā)起了注冊，所以不會發(fā)送“Cancel Location”到SGSN。

目前在客戶現(xiàn)有HLR/HSS 分離，所以產(chǎn)生這種CSFB 失敗在所難免。


4.4
緊急呼叫時主叫號碼不能正常顯示在LTE 上進(jìn)行緊急呼叫，盡管呼叫本身能夠建立起來，主叫號碼不能正常顯示。
原因分析：在正常的CSFB 情況下，在呼叫建立之前，會發(fā)生位置更新。但由于緊急呼叫是高優(yōu)先級的呼叫，即使沒有LAU也會建立呼叫，由于沒有LAU，MSC 沒有辦法獲取MSISDN， 所以也沒有辦法把主叫號碼給緊急呼叫中心。



解決方案：
在緊急呼叫的情況下，對MSC 強制一個IMSI 的LAU，通過這樣來得到正確的主叫號碼。

5
經(jīng)驗、教訓(xùn)和需求5.1
經(jīng)驗總結(jié)l
分清界面，時延問題由于及到的網(wǎng)元比較多，所以在時延分段時盡可能地劃分出核心網(wǎng)段和RAN 側(cè)問題，避免混淆。同時要明確地呈現(xiàn)在客戶面前，推動整體流程優(yōu)化
l
處理CSFB 時延問題時，完整地時延分段可以快速地定位問題所在。
l
CSFB 里面需要分清楚CS 業(yè)務(wù)和PS 業(yè)務(wù)分別的流程，避免相互混淆。

l
CSFB 涉及到流程場景比較多，需要在測試時細(xì)化場景，Single RAB 和Multi RAB差異比較大，需要分開場景測試。
l
詳細(xì)地了解核心網(wǎng)組網(wǎng)才能更好地定位相關(guān)問題。
5.2
產(chǎn)品改進(jìn)建議5.2.1
SIB 調(diào)度算法優(yōu)化建議目前我司的SIB調(diào)度方案在CSFB 測試中性能非常不具有競爭力，需要在分析對手的算法基礎(chǔ)上優(yōu)化算法。



5.3
交付和維護(hù)工具改進(jìn)建議5.3.1
3G PCHR 分析工具的建議客戶目前的PCHR 分析工具，可以很快地提供各種信令之間的時延分析，相比較而言，華為的FMA和Omstar 在定制分析上差距都比較大。 華為PCHR 的解析工具需要更加具有可擴(kuò)展性，否則作為維護(hù)工具只能限制有限的功能。 如下圖所示，全網(wǎng)的統(tǒng)計，第三方工具可以在很短的時間內(nèi)完成。



5.4
交付方案的需求建議5.4.1
整個CSFB 流程的指導(dǎo)針對這種Proxy 解決方案的CSFB 流程，目前沒有比較好的文檔來整體描述這個內(nèi)容，導(dǎo)致現(xiàn)場和機(jī)關(guān)分析時，反復(fù)和機(jī)關(guān)說明網(wǎng)絡(luò)的結(jié)構(gòu)。 這個部分機(jī)關(guān)需要完整的劃分一個場景作為優(yōu)化的指導(dǎo)。


5.4.2
3G 復(fù)雜場景下時延的Checklist 和 指導(dǎo)正對CSFB時延，3G 的信令影響因素很多，目前指導(dǎo)書主要針對的是流程是否合理，但沒有針對各個流程時延本身，而且沒有對場景細(xì)化。這個需要補充到CSFB 優(yōu)化過程中。 包含SRB 的Check， Multi-RAB的Check， Timer 的Check。
5.4.3
LTE 尋呼相關(guān)算法文檔需求LTE 尋呼消息周期的優(yōu)化，沒有明確的計算方法說明對Paging 的影響究竟有多大，需要機(jī)關(guān)提供。