巧用測試儀器解決錯綜復雜的無線網絡問題

對比正常和故障情況(見圖1，圖2，圖3)，可以發現：

正常情況下注冊是符合規范的。任何手機為了向系統通知其準備激活，開機后的位置更新方式應該采用“IMSI附著”的類型，手機鑒別的方式可按情況選用“TMSI和LAI”或“直接發送IMSI”的方式。為了保密，通常不采用“直接發送IMSI”的方式。

故障手機不但在開機后位置更新方式采用了“一般位置更新”類型，在手機鑒別方式上還選擇了“直接發送IMSI”的方式。通常“一般位置更新”類型用于空閑手機從一個LAC區移動到另一個LAC區時的位置更新，僅作LAI的更新，不需要IMSI的認證。因此，當手機開機后如果采用了此種方式，手機就不會發送 IMSI或TMSI，目的地VLR就沒有途徑得到手機的IMSI及鑒別組信息，既無法從HLR得到手機用戶完整數據，也沒法向手機發出鑒別消息，因此目的地VLR只能通過MSC發出拒絕手機的位置更新申請的消息，拒絕的理由只是簡單地歸類為HLR查詢不到IMSI，導致手機出現“未注冊SIMCard”的現象。

什么導致了位置更新類型的變化?最值得懷疑的對象就是儲存著鑒別信息、存儲著決定位置更新類型的程序SIM卡。在更換了SIM卡后，注冊、通訊恢復正常。是何原因導致了原來SIM卡的設置改變?SIM卡實際就是一張存儲卡，存儲著手機正常通訊需要的程序及信息，其內容在特定的條件下可讀、可寫。當某個誘因出現時，就有可能誘發程序出錯。是否由于系統升級或開通了新的PLMN導致故障發生，需要進一步調查，但是最重要的是通過使用RS的無線儀表，在沒有查網絡端的前提下就準確地完成了定位，迅速地解決了問題。

3.2案例2

(1)問題：某批用于EV-DORevA無線網絡的UIM卡插入AT后開機不能上網。

(2)分析：HLR遺漏IMSI信息導致AT無法注冊，AT鑒權失敗，AN與AT參數協商失敗，UIM卡等問題，都會導致AT與AN不能建立會話連接——即不能上網。為了快速查找問題，我們使用了無線綜測儀CMU200。

(3)方法：一般EV-DO的AT上網的流程為：AT在PRL上查詢是否支持EV-DO及EV-DO的優先頻點。如果支持EV-DO，AT調整頻率到EV-DO的優先頻點(一般為37)，開始與AN作會話參數協商。如果會話協商成功，AN會分配一個惟一接入代號UATI給AT，AN也同時獲得了AT提供的SessionSeed和ESN，為會話連接做準備。AT發出會話連接申請，EV-DO的AAA鑒權服務器要求AT按照CHAP協議輸入用戶名和密碼，完成接入EV-DO網絡的鑒權。接著PDSN也會要求客戶按照CHAP協議輸入互聯網接入用戶名和密碼，完成上網鑒權。隨后建立PPP連接，實現上網功能。分析問題需要重現故障現象。由于待測試AT不能與ROMES相連，所以無法從AT端監測。因此需要搭建一個測試環境，從AN側來確定問題所在。我們采用了案例1中的CMU200+屏蔽箱的方案。

在CMU200上設置AN的頻率為37，設置Subtype為2，支持EV-DORevA版本，下行功率-70dBm，AT開機后發現AT與CMU200(AN)不能完成會話協商。

CMU200側偵測到5個為一組的功率從低到高不斷循環的信號，與CMU200ProbesperSequence的定義值5相符合，因此認為這就是AT 發出的接入試探。由此判斷AT已正常發出無線信號，但是由于物理層承載的協議參數無法在AT與AN之間通過協商達成一致，導致了無法進入Session Open狀態，從而無法建立會話連接。

進一步了解得知此批UIM只能用于指定區域的固定上網點，通過設置10位(16進制)的SectorID實現鎖定指定區域的目的。

按照ANSI41規范，SectorID為6位字長(16進制)。修改CMU200中的SectorID format為人工指定格式，并按照UIM廠商提供的信息輸入10位Sector ID后，AT與CMU200順利完成會話協商，成功連接。

到指定區域驗證，事實果然如此。

3.3案例3

(1)問題：經常收到某區域的GSM客戶投訴：存在單通情況。

(2)分析：由于單通現象出現的概率一般不高，如果需要重現故障、查找導致單通的原因需要耗費大量的人力、時間。無線鏈路上、下行不平衡，基站載波故障，基站基帶板件故障，BSC聲碼器故障，天饋線故障，無線干擾，基站Abits口存在環回，交換機的回音抑制器故障，BSC與MSC的A接口CIC不對應等都會引起單通現象。因此，一般從最簡單、最大可能性的測試做起，使用簡潔的方法，爭取用最少的時間、最少的人力解決問題。

3)方法

分析問題發現，出現投訴的區域分屬不同的基站覆蓋區域，但是卻同屬一個BSC，因此某個基站的無線、硬件故障的可能性不大。因此，排查的主要對象落在了手機、區域干擾和BSC，MSC上。

最容易實施的是檢測投訴客戶手機。在此案例中，更換手機后測試多次仍然存在此故障，可確定不是手機原因。如果懷疑是手機引起的單通，則可以使用 RS的音頻分析儀UPV測試手機音頻收發電路。如圖5所示，在CMU200與手機建立連接后，運行UPV的手機音頻測試軟件，可以自動得到手機的音頻發送響度(SLR)、接收響度(RLR)及頻率響應曲線等量化指標，從而驗證手機的音頻電路。

既然此案例已經確定問題在無線網絡，接著可以先查找是否存在區域干擾。使用ROMES軟件控制掃頻儀TSMx在問題區域查找是否存在同、鄰頻干擾(見圖6)，查找結果為無干擾。

然后就需要作最耗費時間和精力的CIC測試。通常需要一個工程師從交換側把A接口鎖剩兩個CIC(保留1路控制信令鏈路)，另外兩個射頻工程師負責撥號、接通、人工說話、人工接聽、人耳監聽是否存在單通。如果存在單通，此時即可定位此兩個CIC存在問題，接著測試下兩個CIC，如此往復，鎖定有問題的 CIC后即可排除故障。但是，CIC的數量非常龐大，并且為了不影響用戶使用，只能深夜進行，需要耗費非常多的時間和精力。

如果能巧妙利用ROMES路測軟件，就可以節省人力和時間。方法是：使用ROMES軟件控制兩臺測試手機，一臺測試手機A的麥克風線路連接到了PC的聲卡音頻輸出端，另一臺測試手機B耳機線路連接到了自帶小型功放的臺式音箱的音頻輸入端，PC循環播放一段音樂通過音頻線路送到A的音頻接收端，手機A受 ROMES控制，自動循環撥通B手機，呼叫經過基站，然后到BSC，接著連接到交換機，交換機會分配鎖剩的兩個CIC與BSC連接，建立通話。音樂因此也送到了自動接聽的測試手機B的耳機線路上，同時也送到了音箱的音頻輸入端，這時音箱即會播放PC播放的音樂。工程師只需要聆聽音箱是否正常發聲，即可判斷此兩個CIC是否存在問題。如果正常，關閉這兩個CIC，打開下兩個CIC，繼續檢查。由此往復，整個過程只需要一個工程師連續操作。交換工程師如果使用了一個自動鎖定、自動解鎖的程序，測試CIC效率更會得到極大的提高。