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

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

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

【資料語(yǔ)言】：中文

【資料格式】：DOC

【資料目錄和簡(jiǎn)介】：

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

目錄

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

1概述... 3

1.1 VHA簡(jiǎn)介... 3

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

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

1.4 VHA CSFB 流程缺陷... 4

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

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

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

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

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

2.5 RAB Setup Time的分析... 13

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

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

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

3.2 SIB 優(yōu)化的實(shí)驗(yàn)室測(cè)試... 17

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

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

4VHA CSFB 業(yè)務(wù)中核心網(wǎng)出現(xiàn)的問(wè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 緊急呼叫時(shí)主叫號(hào)碼不能正常顯示... 25

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

5.1 經(jīng)驗(yàn)總結(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整個(gè)CSFB 流程的指導(dǎo)... 28

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

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


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


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

2
VHA CSFB 業(yè)務(wù)測(cè)試結(jié)果2.1
UE 側(cè)CSFB 業(yè)務(wù)時(shí)延分段結(jié)果現(xiàn)場(chǎng)根據(jù)信令結(jié)果，把整個(gè)LTE2LTE的流程劃分為9個(gè)階段，并且對(duì)每個(gè)階段和競(jìng)爭(zhēng)對(duì)手相比。下面是整個(gè)CSFB UE 側(cè)的分段對(duì)比結(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

針對(duì)V出現(xiàn)的時(shí)延比較大的階段3，8，9， 又做了進(jìn)一步的時(shí)延分段處理。 其中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)場(chǎng)對(duì)比了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



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

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

2.3
UMTS SIB3 讀取時(shí)間和系統(tǒng)消息調(diào)度現(xiàn)場(chǎng)通過(guò)分析，發(fā)現(xiàn)只有在UE讀取SIB3 后才會(huì)發(fā)起RRC Setup Request 的消息，通過(guò)分析，由于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)場(chǎng)還增加了另外一個(gè)鄰區(qū)較多的O的運(yùn)營(yíng)商對(duì)比數(shù)據(jù)。

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

V 的SRB 方式

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

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




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

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




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


當(dāng)前paging周期配置為1280ms，從當(dāng)前參數(shù)的配置，Paging 延遲下發(fā)是正常的，現(xiàn)場(chǎng)又統(tǒng)計(jì)了10次Paging時(shí)間發(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)化和測(cè)試結(jié)果的測(cè)試結(jié)果3.1
SRB 優(yōu)化調(diào)整的測(cè)試結(jié)果根據(jù)現(xiàn)場(chǎng)的情況，現(xiàn)場(chǎng)對(duì)站點(diǎn)的SRB 進(jìn)行調(diào)整，從3.4kbps 道13.6kbps，通過(guò)測(cè)試，發(fā)現(xiàn)CSFB 的時(shí)延減少很多：

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)化的實(shí)驗(yàn)室測(cè)試通過(guò)機(jī)關(guān)反饋的現(xiàn)有SIB調(diào)度方案，在實(shí)驗(yàn)室進(jìn)行了測(cè)試。發(fā)現(xiàn)以下結(jié)論：
在鄰區(qū)配置為中等偏多的時(shí)候，即SIB11 在9~12塊的時(shí)候，優(yōu)化后的算法增益最大，有0.21s，其他情況下幾乎沒(méi)有增益或者有負(fù)的增益。




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








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


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


3.4
UMTS CellRLActive 優(yōu)化調(diào)整建議和解決方案現(xiàn)場(chǎng)測(cè)試的結(jié)果是：對(duì)純粹的CS Single RAB 場(chǎng)景，通過(guò)優(yōu)化MidRateRlActTimeDefOffVal 從70 到40, 可以在單向縮短300ms 的時(shí)延，雙向接近600ms. 目前主要的LTE 雙模終端都會(huì)有PS業(yè)務(wù)，絕大部分場(chǎng)景都是Multi RAB場(chǎng)景。Multi RAB 場(chǎng)景下，如果PS RAB 新建，SRB 轉(zhuǎn)換成3.4kbps, 這樣RAB 建立時(shí)延優(yōu)化就是在OamGuardValForLowRate 的優(yōu)化處理。 從其他網(wǎng)絡(luò)經(jīng)驗(yàn)來(lái)看， 在Multi-RAB場(chǎng)景下，CS 業(yè)務(wù)先建的概率大概有20%， PS RAB 先建的概率是80%。 目前修改低速業(yè)務(wù)的OamGuardValForLowRate 風(fēng)險(xiǎn)很大，所以暫時(shí)不做優(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)的問(wèn)題4.1
CSMT 標(biāo)志造成被叫失敗問(wèn)題描述：
基于重定向的MO/MT CSFB時(shí)延較長(zhǎng)且MT失敗率過(guò)高。
問(wèn)題分析：
1. 通過(guò)Probe trace發(fā)現(xiàn)部分場(chǎng)景UE在收到Paging消息fallback到3G后，在LAU Accept后釋放了RRC。在RRC Release的時(shí)候，UE概率性收不到RNC下發(fā)的Paging消息，造成了被叫失敗。即使UE收到了Paging消息，但是由于呼叫之前需要再次連接RRC，也造成了一定的時(shí)延，如下圖所示。



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

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







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


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


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


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

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

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

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




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

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


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



解決方案：
在緊急呼叫的情況下，對(duì)MSC 強(qiáng)制一個(gè)IMSI 的LAU，通過(guò)這樣來(lái)得到正確的主叫號(hào)碼。

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

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



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



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


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