1. 機卡鎖定

問題現(xiàn)象：:

模塊讀取SIM卡，第一次上線后入網(wǎng)功能和業(yè)務(wù)功能全部正常（在不斷線的情況下一直正常）。第二次上線后無法注冊網(wǎng)絡(luò)。

問題原因：

研發(fā)最初定位原因為網(wǎng)絡(luò)服務(wù)被限制，但運營商查詢后臺業(yè)務(wù)正常。

后續(xù)卡商參與分析并提供了模塊和SIM卡之間的交互信息。

卡端獲取IMEI的過程：

1、終端發(fā)送Terminal Profile

2、卡片發(fā)送"Provide Local Information"指令，獲取終端的IMEI值

3、終端發(fā)送"Provide Local Information"的Terminal Response

4、卡片判斷終端返回的IMEI格式合法，則保存到卡內(nèi)。

5、如果步驟2之后，終端一直不能發(fā)送"Provide Local Information"的Terminal Response，則在第5個Status指令（A0F2/80F2）后，將卡片鑒權(quán)鎖定。

下面是對于主動式命令"Provide Local Information"的描述。具體的信息可以查看GSM11.14

模塊未能正確響應Provide Local Information要求獲取IMEI值的請求，導致SIM卡鑒權(quán)被鎖定。該鎖定無法通過運營商后臺恢復，只能返回SIM卡商進行處理。

2. 設(shè)備綁定

問題現(xiàn)象：

SIM卡插到模塊上能正常使用，更換到另外一個模塊則無法注冊網(wǎng)絡(luò)。

問題原因:

運營商查看SIM卡對應的后臺服務(wù)，已經(jīng)處于未激活的狀態(tài)。

重新激活后，SIM卡能正常使用。把SIM卡再次更換一個設(shè)備，則無法注冊。

經(jīng)運營商確認，該卡第一次注冊網(wǎng)絡(luò)后，會綁定IMEI號，也就是通常所說的設(shè)備綁定。只能固定使用同一個IMEI號。

測試過程中，修改模塊的IMEI號始終為同一個，就可以更換模塊進行測試。

3. SIM卡文件損壞

問題現(xiàn)象：

SIM卡使用一段時間后，出現(xiàn)無法注冊網(wǎng)絡(luò)的情況。

問題分析：

SIM卡商使用Micropross MP300 TC3、金普斯讀卡器等設(shè)備，對SIM卡文件系統(tǒng)進行掃描測試，發(fā)現(xiàn)EFSTART-HFN(6F5B)無法讀取。

6F5B文件為終端入網(wǎng)必須要進行選擇和讀寫的文件，參考國際規(guī)范《3GPP TS31.102》，如果這個文件損壞，就會導致終端無法入網(wǎng)。

對上述文件做空間分析分析后，對6F5B文件所在Flash區(qū)域做壽命分析發(fā)現(xiàn)，起壽命已經(jīng)達到了極限，終端無法進行正常的選擇和讀寫該文件。

SIM卡商提供了模塊對該文件的讀寫次數(shù)統(tǒng)計，一天讀寫次數(shù)達到幾千次。也提供了部分手機的對比測試，如華為榮耀6，一天更新該文件的次數(shù)僅為個位數(shù)。

在國際規(guī)范中規(guī)定卡片文件級更新次數(shù)不少于10萬次。

問題原因:

模塊頻繁讀寫SIM卡文件，導致SIM卡文件損壞，最終無法注冊網(wǎng)絡(luò)。

另外一個常見的原因，是客戶設(shè)計不合理，在異常情況下反復重啟模塊，長年累月導致SIM卡文件損壞，俗稱"燒卡"。

4. SIM卡協(xié)議不規(guī)范

問題現(xiàn)象：

模塊使用特定SIM卡無法PS網(wǎng)絡(luò)，但在手機上可以正常使用。

問題分析：

使用相同SIM卡，對比其他模塊可以注冊PS。

查看兩個模塊的開機注冊網(wǎng)絡(luò)log，發(fā)現(xiàn)讀取SIM卡EF文件的命令參數(shù)P1有區(qū)別：

如下是正常模塊的log，P1的值是8

如下是異常模塊的log，P1的值是0

根據(jù)10221協(xié)議，如下圖，當P1為0時，是通過在當前路徑下查找和訪問此file ID，也就是相對路徑訪問。

當P1為8時，是從MF開始通過絕對路徑選擇EF文件

根據(jù)102.221 Table 8.1,不管之前選擇的是哪個文件，根據(jù)File ID 都應該可以選擇到USIM ADF。

所以異常模塊訪問EF文件P1為0（selecf DF,EF or MF by File ID）是符合規(guī)范的，但是相對路徑訪問EF文件失敗，說明注冊網(wǎng)絡(luò)時，在當前路徑下無法查找到此file ID，可以判斷在SIM卡中此file ID的位置是有問題的，此SIM卡不符合規(guī)范。

問題原因:

SIM卡協(xié)議不完全符合規(guī)范，讀取文件失敗，導致無法注冊PS網(wǎng)絡(luò)。

5. PLMN未加入列表

問題現(xiàn)象：

使用特定PLMN名稱的SIM卡，模塊無法注冊。

問題原因：

模塊未加入相應的PLMN名稱，模塊認為是非法的運營商名稱，導致無法注冊網(wǎng)絡(luò)。

6. SIM卡未開通4G業(yè)務(wù)

問題現(xiàn)象：

使用特定SIM卡，4G模塊無法注冊。

問題分析：

手動鎖定2/3G則可以注冊，鎖定4G無法注冊。

和運營商確定，該卡未開通4G業(yè)務(wù)。

在注冊4G網(wǎng)絡(luò)時，收到reject原因為MISSING OR UNKNOWN APN，不能自動切換到3G小區(qū)注冊。而當?shù)?G信號良好，模塊一直嘗試注冊4G，導致模塊一直無法注冊上網(wǎng)。

問題解決方案：

當注冊4G網(wǎng)絡(luò)連續(xù)失敗3次，并且原因是ESM_FAILURE時，鎖定到3G/2G模式，不再注冊4G小區(qū)。掉電恢復4G/3G/2G。

7. PA損壞

問題現(xiàn)象：

模塊無法注冊網(wǎng)絡(luò)。

在現(xiàn)場可通過模塊工作電流大致判斷是否硬件問題。

問題分析：

拿到客戶返回的不良品進行硬件測試，確認PA損壞或部分損壞。

可能的原因：

a. 客戶工廠貼片流程不合理：多次過爐 / 模塊二次貼片間隔時間過長 / 溫濕度控制缺失 / 靜電防護不夠

b. 模塊自身物料批次原因，PA易損壞。

c. 供電電壓有大幅度波動，長時間工作會損壞PA。

8. FLASH被改寫

問題現(xiàn)象：

模塊無法注冊網(wǎng)絡(luò)，經(jīng)判斷模塊無法正常開機。

問題分析：

a. 將flash數(shù)據(jù)導出，燒到正常模塊上看是否開機

b. JTAG類工具跟蹤調(diào)試

一般為boot階段的Flash數(shù)據(jù)被改寫，各模塊均出現(xiàn)過類似問題。

問題解決方案：

a. 審核客戶電源和開機時序方面的設(shè)計，消除隱患。

b. 模塊軟件采用備份機制進行規(guī)避。

9. TCP本地端口固定

問題現(xiàn)象：

模塊通過TCP連接服務(wù)器，由于斷電等異常情況未正常關(guān)閉TCP連接。

模塊重新建立連接時，無法連接服務(wù)器。可能需要等待幾個小時才能重新連接。

問題原因：

客戶在調(diào)用AT+MIPOPEN=1,local port,"服務(wù)器IP",remote port時，設(shè)置了local port參數(shù)，每次建立連接時都使用同樣的本地端口。

客戶使用的SIM卡為物聯(lián)網(wǎng)卡且綁定了IP地址。

有些服務(wù)器在連接異常斷開后，短時間內(nèi)不允許同一IP地址同一端口號的連接再次接入。

問題解決方案：

a. 應用程序建立TCP連接時，隨機生成本地端口號

b. 應用程序不指定本地端口號

模塊第一次建立連接時隨機生成，再次建立時將端口號順序+1 或者 每次建立連接都隨機生成。

10. 心跳間隔太長

問題現(xiàn)象：

模塊TCP連接經(jīng)常斷開。

問題原因：

TCP連接斷開，是因為模塊發(fā)送數(shù)據(jù)沒有收到服務(wù)器的ACK包回應，重傳次數(shù)達到上限。

終端如果在一段時間內(nèi)，沒有交互數(shù)據(jù)業(yè)務(wù)，網(wǎng)絡(luò)側(cè)會釋放相應的資源，且無任何信令下發(fā)。普通SIM卡更容易發(fā)生這種情況。

因此在正常的業(yè)務(wù)數(shù)據(jù)交互之外，需增加TCP心跳機制，以一定時間間隔向服務(wù)器發(fā)送心跳包。

該時間間隔，視運營商當?shù)鼐W(wǎng)絡(luò)而定，有些可能幾個小時，有些可能1分鐘。在印尼有測到過45秒時間的。

11. 運營商防火墻

問題現(xiàn)象：

在當?shù)赜梦锫?lián)網(wǎng)卡測試10次以內(nèi)，就會出現(xiàn)無法連接服務(wù)器的問題，需要重新?lián)芴柣蛘咧貑⒒謴汀?/p>

在其他城市采用該物聯(lián)網(wǎng)測試，不能復現(xiàn)問題現(xiàn)象。

在當?shù)厥褂霉W(wǎng)卡進行測試，沒有問題。

問題分析：

經(jīng)運營商分析，由于現(xiàn)網(wǎng)升級改造試點，在改造過程中需要對華為防火墻的策略進行更新。

在策略更新進行的同時用戶上線，省側(cè)MME和南方基地GGSN1之間新建會話，觸發(fā)了華為防火墻軟件版本BUG，導致會話異常，致使省側(cè)MME無法收到回包，用戶上線失敗。、

問題解決方案：

運營商側(cè)，華為防火墻軟件打補丁。

12. QOS協(xié)商

問題現(xiàn)象：

設(shè)備連接服務(wù)器困難。 查看模塊AT交互log，模塊在PDP激活之后，連接客戶服務(wù)器經(jīng)常失敗。失敗概率大概在90%以上。

該問題只在固定城市出現(xiàn)，湖南省其他城市則沒有。

問題分析：

在省移動公司進行了對比驗證。

正常情況與異常情況下，省會城市（正常）和故障城市（異常）SIM卡簽約數(shù)據(jù)一致

正常情況：

異常情況：

網(wǎng)絡(luò)下發(fā)的ACTIVATE PDP CONTEXT ACCEPT中Relibility Class為5.

終端上報ACTIVATE PDP CONTEXT REQUEST中Relibility Class是3，網(wǎng)絡(luò)在ACTIVATE PDP CONTEXT ACCEPT中下發(fā)是5

Reliability Class的取值，取決于終端請求、HLR簽約、網(wǎng)絡(luò)支持QoS中的最大值。根據(jù)3GPP協(xié)議23.107 V3.4.0 9.12.3，

Table 7: Rules for determining R97/98 attributes from R99 attributes

終端請求的是3，對應的SDU error ratio為1e-4

HLR簽約的是3，對應的SDU error ratio為1e-3

網(wǎng)絡(luò)側(cè)下發(fā)的SDU error ratio為1e-3

網(wǎng)絡(luò)根據(jù)SDU error ratio取值，自動將Reliability Class修改為5。

從模塊側(cè)的交互流程來看：

a. 在做PDP激活時，模塊設(shè)置的QOS Reliability是3，請求ACK RLC mode

b. 網(wǎng)絡(luò)回復的Reliability是5，即Unack RLC mode

c. 在tbf剛開始時，網(wǎng)絡(luò)沒有給模塊usf，接收的數(shù)也是bfi，監(jiān)測到usf是無效的，正好跟未生效的usf是一樣的，導致在沒有檢查有效性的情況下，發(fā)送了數(shù)據(jù)，而數(shù)據(jù)是Unack RLC mode的，不會重傳，導致網(wǎng)絡(luò)收不到模塊發(fā)送的數(shù)據(jù)

問題解決方案：

模塊修改軟件，即使網(wǎng)絡(luò)下發(fā)的QOS Reliability協(xié)商結(jié)果為5，仍然按照ACK RLC mode的方式發(fā)送數(shù)據(jù)。