韓永濤，王瑞，簡君文

（1 中國聯(lián)通福建分公司網(wǎng)優(yōu)中心,廈門 361008；2 中興通訊公司，深圳 518057）

1 問題的由來

某市蘋果iPad同時(shí)連接WiFi和3G時(shí)，3G無線側(cè)一天之內(nèi)的PS域掉話次數(shù)在2000次左右，而這個(gè)iPad在同省XM時(shí)卻沒有掉話。某市和XM共用了中興核心網(wǎng)CN（SGSN），但是某市使用了中興的RAN（無線接入網(wǎng)），XM使用了華為的RAN。為何iPad只在某市出現(xiàn)這么大量異常掉話？

2 解決思路

蘋果iPad對于我們是個(gè)黑盒子，無法抓取UE側(cè)的任何信息，從失敗的RNC信令并不能直接看出太多線索，并且iPad的內(nèi)部處理機(jī)制都是需要去猜測和推理。我們想構(gòu)造出iPad反復(fù)PDP激活去激活，然后掉話的場景，再用排除法一個(gè)一個(gè)驗(yàn)證到底哪個(gè)原因是造成iPad反復(fù)掉話。掉話都是反復(fù)“①PDP激活②PDP去激活③PDP激活④UE LOST掉話”這樣的流程，并且規(guī)律性地間隔30s左右掉話一次。確認(rèn)版本為3.2（7B367)的iPad，并且內(nèi)部沒有設(shè)置APN。對比了一下PS業(yè)務(wù)的正常信令和異常掉話信令：一個(gè)正常業(yè)務(wù)的釋放會(huì)在PDP激活后，完成RAB Release，然后3s內(nèi)如果沒有其他操作，CN就會(huì)下發(fā)完成Iu_Release_Cmd，釋放該連接。再看看失敗信令流程，是我們在RNC側(cè)跟蹤得到的信令，iPad同時(shí)連接了WiFi和3G，沒有配置APN，也沒有任何人為操作。在13:13:59:090，iPad收到RNC下發(fā)的Radio Bearer Setup，屬于第①個(gè)PDP激活流程。在13:14:00:440，iPad收到RNC下發(fā)的Radio Bearer Release，屬于第②個(gè)PDP去激活流程。在13:14:01:340，iPad發(fā)出Radio Bearer Release Complete，表示第②個(gè)PDP去激活流程結(jié)束。在13:14:01:500，iPad收到RNC下發(fā)的Radio Bearer Setup，屬于第③個(gè)PDP激活流程。在13:14:02:530，雖然第3個(gè)PDP激活成功了，但是UE上報(bào)了RRC Status，Node B報(bào)上行同步失敗，然后RNC報(bào)UE LOST，主動(dòng)請求釋放，產(chǎn)生掉話。

3 分析過程

3.1 反復(fù)的PDP激活去激活的觸發(fā)

為了研究反復(fù)的PDP激活去激活是由網(wǎng)絡(luò)側(cè)發(fā)起還是iPad自身行為，拿到一臺(tái)官方正式版本號(hào)為4.2.1(8C148)的iPad，與某市使用的3.2(7B367)對比。做了如下驗(yàn)證：WiFi源：用聯(lián)通數(shù)據(jù)卡在筆記本A撥號(hào)后，通過無線共享給iPad，來提供WiFi服務(wù)。3G源：iPad的本身內(nèi)接測試SIM卡，注冊到深圳實(shí)驗(yàn)室612的核心網(wǎng)下。iPad版本：官方最新版：4.2.1(8C148)。（1）先關(guān)閉WiFi，重新開機(jī)，3G這邊有PDP激活，做了業(yè)務(wù)請求都是在訪問Apple的網(wǎng)站。（2）再打開WiFi，3G這邊過了5min才去激活，之后就一直沒有再激活了。（3）再關(guān)閉WiFi，用3G登陸新浪，3G的PDP一直保持激活狀態(tài)，沒有去激活。（4）再打開WiFi，同時(shí)保持3G連接，無論是瀏覽網(wǎng)頁還是登陸實(shí)驗(yàn)室的內(nèi)網(wǎng)，業(yè)務(wù)全走WiFi。（5）將筆記本A的撥號(hào)斷開，但iPad保持WiFi連接，再瀏覽網(wǎng)頁過程，3G這邊依然無動(dòng)作，依然保持著第3步中的PDP激活狀態(tài)。（6）iPad斷開WIFI，繼續(xù)瀏覽，數(shù)據(jù)分組從3G上來，之后不做任何操作，SAFARI內(nèi)容清掉后，iPad沒有去激活。（7）再連接WiFi后，運(yùn)行很多軟件，大部分業(yè)務(wù)都走了WiFi，但是3G這邊發(fā)現(xiàn)，iPad偶爾從54895口往17.155.5.239端口發(fā)UDP分組，再從16384、16385端口往17.155.5.240的16386口發(fā)送分組，這些都是Apple的內(nèi)網(wǎng)。（8）此時(shí)關(guān)閉WiFi，iPad還是會(huì)往Apple內(nèi)網(wǎng)發(fā)UDP的分組（44byte）（9）重新開機(jī)后，只開3G，此時(shí)有PDP激活，但是還是沒有PDP去激活。（10）再重新開機(jī)，只開3G，卻沒有PDP激活請求，也沒有DETATCH，然后點(diǎn)了CrazyBird這個(gè)游戲，突然發(fā)生了PDP激活請求。

可得出結(jié)論：出現(xiàn)PDP激活，一定是iPad主動(dòng)發(fā)起了業(yè)務(wù)請求，而且后臺(tái)肯定有些軟件發(fā)起請求。出現(xiàn)PDP去激活，一定是iPad主動(dòng)發(fā)起去激活，但是去激活的原因與當(dāng)前的數(shù)據(jù)量無關(guān)，而是iPad自己去判決，暫時(shí)沒有查出某市出現(xiàn)的循環(huán)PDP激活—去激活—激活的規(guī)律。即使打開WiFi后，iPad也偶爾會(huì)通過3G往Apple的內(nèi)網(wǎng)發(fā)UDP包。

3.2 WiFi打開是否會(huì)激發(fā)iPad掉話

在某市，iPad打開WiFi與關(guān)閉WiFi和PDP激活不帶APN與帶APN進(jìn)行組合測試。

表1 iPad組合測試

從表1可以看到，WiFi是否打開與iPad掉話與否無關(guān)。

3.3 384kbit/s/64kbit/s業(yè)務(wù)子類的功率控制參數(shù)是否有問題

在RNC的網(wǎng)管上查詢（下行/上行）384kbit/s/64kbit/s業(yè)務(wù)子類的功控參數(shù)都存在，索引也沒問題，并且與其他地市沒什么缺漏，設(shè)想如果該參數(shù)有問題，RAB指派應(yīng)該也是不會(huì)成功的。為了進(jìn)一步打消猜疑，在某市網(wǎng)絡(luò)下，用某市的SIM卡，插入到數(shù)據(jù)卡中，配置空白的APN，速率也適配到了（下行/上行）384kbit/s/64kbit/s，但是不會(huì)發(fā)起頻繁PDP激活去激活請求，也沒有掉話。事實(shí)證明，功控參數(shù)是沒有問題的。懷疑點(diǎn)還是放在iPad與網(wǎng)絡(luò)的兼容性上面考慮。

3.4 iPad內(nèi)部自動(dòng)觸發(fā)業(yè)務(wù)

經(jīng)過以上分析，只有iPad會(huì)主動(dòng)發(fā)起多次PDP激活去激活的請求。以下是深圳和某市對比測試，目的是驗(yàn)證是否所有的iPad都會(huì)有某個(gè)內(nèi)部軟件自動(dòng)觸發(fā)業(yè)務(wù)。深圳實(shí)驗(yàn)室，4.2.1版本的iPad：將RNC用戶面的參數(shù)配置錯(cuò)誤，故意構(gòu)造一個(gè)用戶面不通的場景，打開“通知”，配置空白APN，此時(shí)出現(xiàn)頻繁地PDP激活去激活，但是從SGSN側(cè)沒有發(fā)現(xiàn)iPad發(fā)出的上行包，也沒有掉話。將RNC用戶面的參數(shù)配置正確，故意構(gòu)造一個(gè)用戶面正常的場景，打開“通知”，配置空白APN，此時(shí)沒有出現(xiàn)PDP激活去激活現(xiàn)象，從SGSN側(cè)發(fā)現(xiàn)iPad發(fā)了很多上行的UDP分組。某市現(xiàn)網(wǎng)，用3.2(7B367)版本的iPad，發(fā)現(xiàn)頻繁的PDP激活去激活是由“通知”功能引起，只要“通知”功能打開，就會(huì)頻繁地發(fā)生掉話，關(guān)閉后就只有PDP激活，然后轉(zhuǎn)Idle釋放的信令。本次排查的結(jié)論有三個(gè)：（1）“通知”功能，是導(dǎo)致iPad自動(dòng)發(fā)起業(yè)務(wù)請求的直接原因。（2）在深圳，雖然發(fā)生了頻繁的PDP激活去激活現(xiàn)象，但是從SGSN看，iPad本身沒有數(shù)據(jù)分組上來，說明業(yè)務(wù)面不通，也是導(dǎo)致iPad重發(fā)多次業(yè)務(wù)請求的原因之一。（3）深圳的iPad即使發(fā)生了多次PDP激活去激活也沒有掉話，說明這個(gè)iPad版本有可能即使在某市的場景下也不會(huì)掉話。暫時(shí)無法確認(rèn)是否只有3.2(7B367)才有這個(gè)問題。但從全國來看，并非所有城市都出現(xiàn)iPad掉話現(xiàn)象，且3.2（7B367)的版本的終端已經(jīng)很少（只有未升級的水貨有），懷疑和iPad版本也是有關(guān)系的。

3.5 CN（SGSN）的APN策略是否有什么限制

APN更正功能不屬于協(xié)議標(biāo)準(zhǔn)流程，首先來看圖1的PDP激活信令流程。

圖1 PDP激活信令流程

當(dāng)SGSN收到的PDP激活請求時(shí)，會(huì)對其中攜帶的APN進(jìn)行檢查，如APN檢查不通過就會(huì)發(fā)PDP激活拒絕。在實(shí)際商用網(wǎng)絡(luò)中，有很多用戶由于終端的問題，比如很多持有水貨手機(jī)（外國運(yùn)營商定制手機(jī)），其APN不允許修改或不允許新建，導(dǎo)致持這樣手機(jī)根本無法使用PS網(wǎng)絡(luò)；另外，即使有的手機(jī)APN可以修改，很可能用戶嘗試了幾個(gè)不同的APN之后發(fā)現(xiàn)依然無法上網(wǎng)，就不愿意繼續(xù)嘗試了。APN更正功能主要是針對此類問題的提出的，當(dāng)啟用APN更正功能后，在激活過程中APN檢查不通過時(shí)根據(jù)配置會(huì)發(fā)起APN的更正。APN更正策略一般而言有兩類：第一種是更正為用戶對應(yīng)HLR簽約的第一個(gè)APN，好處是用戶即使未設(shè)置APN，當(dāng)該用戶上網(wǎng)時(shí)還是能使用其簽約APN一樣的QoS。第二種是由運(yùn)營商指定的APN，好處是運(yùn)營商設(shè)置方便，但對大部分用戶來說，當(dāng)發(fā)起PS業(yè)務(wù)沒有設(shè)置APN而被使用默認(rèn)APN時(shí)，該用戶使用的QoS往往和其簽約的不同，可能簽約了高速率，但實(shí)際上指派的速率比簽約的低很多。深圳的情況：iPad不設(shè)置APN以及設(shè)置簽約APN進(jìn)行PS撥號(hào)后的信令對比看RAB指派中速率都為交互類2Mbit/s/7.2Mbit/s并且其它QoS選項(xiàng)都一樣，由此可見深圳APN更正設(shè)置采用的是用戶簽約APN，即上面所說的第一種策略。某市的情況：采用第二種策略，iPad在某市不設(shè)置APN時(shí)被指派的APN為Uniwap，被指派的速率為交互類64kbit/s/384kbit/s，而采用簽約APN（3gnet）時(shí)，指派速率為交互類2Mbit/s/7.2Mbit/s，顯而易見，某市APN更正時(shí)選擇的不是用戶簽約的APN，應(yīng)該是運(yùn)營商統(tǒng)一指定的APN。那么，比較兩者的情況，總結(jié)有以下兩點(diǎn)不同，并且針對這兩點(diǎn)不同之處進(jìn)行了有針對性的分析測試。指派速率不同：在實(shí)驗(yàn)室進(jìn)行了64kbit/s/384kbit/s與2Mbit/s/7.2Mbit/s同樣場景下的驗(yàn)證測試，測試結(jié)果正常，排除了指派速率不同的影響；APN映射的地址池對應(yīng)的出局方式不同：有以下兩種：（1）通過WAP網(wǎng)關(guān)，終端側(cè)必需要設(shè)置上網(wǎng)代理網(wǎng)關(guān)地址與端口才能訪問網(wǎng)頁，否則就無法訪問網(wǎng)頁。（2）不通過WAP網(wǎng)關(guān)，終端側(cè)無需設(shè)置上網(wǎng)代理網(wǎng)關(guān)地址與端口，直接可訪問網(wǎng)頁。誠然，某市采用了第1個(gè)方式，深圳采用了第2個(gè)，通過WAP網(wǎng)關(guān)使用WAP上網(wǎng)方式對用戶和運(yùn)營商來說都是好處的，是考慮到很多WAP類網(wǎng)站可免費(fèi)訪問，而NET類網(wǎng)站收費(fèi)，若改為更正為NET，會(huì)導(dǎo)致大量投訴。但是若采用WAP類APN的話，終端側(cè)卻需要增加網(wǎng)關(guān)和端口的設(shè)置，很多客戶不知道要如何設(shè)置，或者覺得設(shè)置繁瑣，這時(shí)終端就不能瀏覽網(wǎng)頁了。為此我們又進(jìn)行了表2所示的對比測試。

表2 對比測試

用深圳和某市的SIM卡在某市的網(wǎng)絡(luò)下，分別向百度做路由trace，可以看出，深圳的SIM卡即使漫游到了某市的網(wǎng)絡(luò)下，出局路由依然是在深圳的GGSN那邊。這也是為什么深圳的SIM卡在配置了空白的APN后，依然可以上網(wǎng)的原因。得出結(jié)論：因?yàn)榭瞻椎腁PN導(dǎo)致某市的SIM卡無法直接瀏覽網(wǎng)頁，無法滿足iPad內(nèi)部的一些軟件的訪問因特網(wǎng)需求，所以iPad不斷發(fā)起業(yè)務(wù)請求，觸發(fā)PDP激活去激活場景，目的就是希望能夠接入，所以CN（SGSN）的APN策略也是影響某市iPad掉話的要因之一。

3.6 iPad版本3.2（7B367)在PDP激活去激活的間隔上的問題

將新版本iPad帶到某市對比舊版iPad，新版iPad的PDP激活和去激活間隔時(shí)間比較長，一般都會(huì)等到CN下發(fā)Iu_Release_Cmd，釋放掉連接之后才發(fā)起下一個(gè)PDP激活請求，所以就沒有問題。舊版本的iPad掉話次數(shù)很多，它一般是第②步與第③步驟之間間隔不到200ms，導(dǎo)致IU還沒來得及釋放，iPad就搶到第③步，然后報(bào)UE LOST掉話，而且從SGSN側(cè)沒有抓到用戶數(shù)據(jù)，說明此時(shí)業(yè)務(wù)面是沒有通的。懷疑正是因?yàn)榕渲昧丝瞻椎腁PN導(dǎo)致實(shí)際無法訪問Internet，所以SGSN這一直沒有收到UE的分組，要是UE的分組到達(dá)了，也就會(huì)很快地激活。新版本的iPad沒有掉話，它在某市網(wǎng)下也會(huì)不定期地發(fā)起PDP激活和去激活請求，但是它第③步來得比較晚，一般大于3s，所以CN能及時(shí)的將IU連接釋放掉。舊版本iPad和新版本iPad配置正確的APN后，都不會(huì)發(fā)生①②③④這樣的往返，懷疑數(shù)據(jù)面如果是通的，iPad就不會(huì)主動(dòng)多次嘗試業(yè)務(wù)發(fā)去激活和激活流程。XM是華為的RAN，中興的SGSN，就沒有報(bào)掉話的現(xiàn)象，但是從目前分析，掉話需要同時(shí)滿足3個(gè)條件才會(huì)發(fā)生：空白的APN導(dǎo)致無法上網(wǎng)；iPad版本比較舊，PDP激活去激活間隔?。籭Pad開啟了“通知”功能，會(huì)主動(dòng)嘗試業(yè)務(wù)請求。需要在XM進(jìn)行對比測試，構(gòu)造出iPad高頻率的激活去激活場景，來復(fù)現(xiàn)掉話的現(xiàn)象，如果XM不掉話，則問題肯定出在RAN側(cè)。

3.7 RAN側(cè)是否有問題

XM與某市共用中興的CN，但是RAN是華為的，用3.2版本的iPad，配置空白的APN，在XM也無法直接瀏覽Internet，并且在SGSN沒有抓到用戶分組，構(gòu)造出了高頻率的激活去激活場景，但是始終沒有掉話。說明某市iPad掉話問題，還是與某市的RAN有關(guān)。經(jīng)過與XM局方溝通，從局方工程師那里將XMRAN側(cè)的碼流全部拷貝出來。查看XM的信令流程，可以看出，3.2版本的iPad在這個(gè)網(wǎng)絡(luò)下，激活—去激活—激活也是完全連著的，并且激活與去激活的間隔也是幾百毫秒。（注：每一次PDP激活，伴隨著RB_SETUP流程，而PDP去激活，伴隨著RB_REL流程）。XM的信令：①PDP激活—②PDP去激活之后，CN沒有下發(fā)Iu釋放，再次PDP激活和去激活多次都成功。某市的信令中，iPad再次PDP激活成功后，會(huì)報(bào)RRC Status，表示此時(shí)狀態(tài)不對了；對比兩個(gè)信令：在PDP去激活時(shí)，某市網(wǎng)絡(luò)在Radio Bearer Release消息填下了如下字段，而XM沒有：

radioBearerRelease.u.later_than_r3.criticalExtensions.u.criticalExtensions.u.r5.radioBearerRelease_r5.m.signallingConnectionRelIn dicationPresent＝1

radioBearerRelease.u.later_than_r3.critical Extensions.u.criticalExtensions.u.r5.radioBearer Release_r5.signallingConnectionRelIndication＝ps_domain

從協(xié)議331解釋看出，在PDP去激活的Radio Bearer Release 消息中的字段signaling Connection Rel是釋放PS域的信令連接，在處理完這條消息后PS域的信令連接被RNC釋放了，UE也會(huì)remove the signaling connection，并且告訴高層。是否UE對這條信元的理解有問題？下面再分析某市的iPad信令，在成功完成PDP激活—PDP去激活的流程后，再一次PDP激活的流程里，iPad收到了CN下發(fā)的downlinkDirectTransfer，是PDP激活接受，其中還是帶了cn DomainIndentity= ps_domian這個(gè)字段。跟著400ms后，UE就報(bào)了RRC Status，提示與接收到的狀態(tài)不對，如下所示：TRRC_UL_DCCH_Message.message.u.rrcStatus.protocolErrorInformation.diagnosticsType.u.type1.u.messageNotCompatible WithReceiverState.rrc_TransactionIdentifier = 0

TRRC_UL_DCCH_Message.message.u.rrc Status.protocolErrorInformation.diagnosticsType.u.type1.u.messageNotCompatibleWithReceiverSta te.receivedMessageType = downlinkDirectTransfer

再查看331協(xié)議里關(guān)于RRC Status的描述，推斷應(yīng)該是UE覺得上一個(gè)Downlink Direct Transfer中提到的PS域的信令連接已經(jīng)沒有了，所以會(huì)上報(bào)了RRC Status，并且會(huì)認(rèn)為這條下行直傳有問題，提示Protocol error，原因是Message not compatible with receiver state。下面追溯一下關(guān)于這個(gè)信令連接的狀態(tài)變化過程：第①個(gè)UE發(fā)的PDP激活請求之前有個(gè)service request，里面有如下字段，提示PS域的信令連接請求TRRC_UL_DCCH_Message.message.u.initialDirectTransfer.v3a0NonCriticalExtensions.laterNonCriticalExtensions.v590NonCritical Extensions.initialDirectTransfer_v590ext.establishmentCause = originatingHighPrioritySig nalling。第②個(gè)UE發(fā)的PDP去激活后，RNC下發(fā)了signallingConnectionRel，將PS域的信令連接釋放了。第③個(gè)UE發(fā)的PDP激活請求中面還是帶了cn_DomainIdentity = ps_domain字段，但是此時(shí)PS域的信令連接已經(jīng)釋放了，iPad也沒有發(fā)信令連接請求。signaling Connection Rel Indication這個(gè)信元是可選字段，并且XM網(wǎng)絡(luò)也沒有，所以需要對比測試下，不填寫這個(gè)該信元看看效果。剛好深圳聯(lián)通有兩個(gè)RNC，一個(gè)RNC是V3.07版本的，包含了這個(gè)字段，另外一個(gè)RNC是V3.09版本的，不包含這個(gè)字段。所以將某市的3.2版本的iPad帶到深圳，分別在V3.07和V3.09版本的RNC下通過手工修改iPad的APN的方式，來觸發(fā)多次PDP激活PDP去激活PDP激活的場景，用于復(fù)現(xiàn)某市iPad掉話的環(huán)境。測試情況如下，證明3.07版本的RNC在PDP去激活的時(shí)候，不應(yīng)該同時(shí)把PS域也釋放掉。在3.09版本下，新舊版的iPad都能夠正常地發(fā)起多次PDP激活—PDP去激活—PDP激活的流程，沒掉話。在3.07版本下，舊版本的iPad復(fù)現(xiàn)了和某市一樣反復(fù)①PDP激活—②PDP去激活—③PDP激活—④UE LOST掉話的流程，而新版本的iPad每次PDP去激活后，都會(huì)等待CN釋放IU連接，依然不會(huì)掉話。

PDP去激活時(shí)RNC下發(fā)的Radio Bearer Release中有signallingConnectionRelIndication＝ps_domain這條信元，會(huì)將iPad的PS域信令連接釋放，然而某市聯(lián)通的舊版本iPad可能沒有理解這個(gè)字段，在200ms后又發(fā)起PDP激活請求，CN這邊也認(rèn)為iPad只是PDP去激活了，PS域信令連接還留著，所以保留有iPad相關(guān)的MM上下文，所以第二次PDP激活會(huì)成功。但其實(shí)此刻iPad的PS域信令連接已經(jīng)被釋放了，并且也沒有重新申請信令連接。所以iPad會(huì)報(bào)RRC Status說明與網(wǎng)絡(luò)的狀態(tài)不一致，關(guān)閉上行功率，之后Node B無法找到iPad，上報(bào)Radio Link Failure，然后RNC主動(dòng)釋放IU連接，報(bào)UE LOST，產(chǎn)生掉話。如果將signallingConnectionRelIndication＝ps_domain這條信元去掉，即使iPad頻繁地發(fā)起PDP激活去激活流程，也不會(huì)掉話。

3.8 最終結(jié)論與解決方案

因?yàn)榘姹緸?.2的iPad沒有設(shè)置APN，所以CN適配到了不恰當(dāng)?shù)腁PN，導(dǎo)致無法直接瀏覽Web，該iPad就會(huì)在3G下頻繁地發(fā)起PDP激活PDP去激活PDP激活的流程，來不斷地嘗試接入Web，并且PDP去激活后200ms以內(nèi)就立刻發(fā)起PDP激活，間隔很短；并且某市V3.07版本的中興RNC在PDP去激活時(shí)，會(huì)通過signallingConnectionRelIndication＝ps_domain這條信元將UE的PS域信令連接釋放掉；并且舊版本的iPad在理解這條信元上有問題，依然立刻發(fā)起了第二次PDP激活，導(dǎo)致iPad與網(wǎng)絡(luò)狀態(tài)不一致?？瞻譇PN、打開通知功能、PDP激活去激活太頻繁、PDP去激活后釋放PS域，當(dāng)且僅當(dāng)這四種偶然糾纏在一起的時(shí)候，就會(huì)發(fā)生一次必然的PS域掉話。

方案1，中興可以出一個(gè)RNC的補(bǔ)丁，刪除Radio Bearer Release信令里的可選字段signalling ConnectionRel Indication = ps_domain。方案2，可以在CN通過修改APN策略，讓空的APN也能映射到HLR優(yōu)選的APN，使得iPad內(nèi)部的軟件的Web請求能夠滿足，來減少PDP激活去激活次數(shù)，來規(guī)避掉話的問題。方案3，可以通知客戶升級iPad。方案4，可以通知客戶關(guān)閉通知功能。方案5，可以通知客戶設(shè)置正確的APN。

4 小結(jié)

我們要有效地將現(xiàn)場客戶反饋的問題，透過現(xiàn)象看到問題本質(zhì)，快速、準(zhǔn)確定位和解決問題，提升客戶滿意度。事件的發(fā)生往往具有一定的偶然性，然而真相總是掩蓋在一些看似毫無關(guān)聯(lián)的現(xiàn)象背后，讓人有著一種捕風(fēng)捉影般的感覺。今后業(yè)務(wù)、網(wǎng)絡(luò)與終端都越來越復(fù)雜，提高系統(tǒng)與不同終端兼容性的能力也越來越重要。