1. 機卡鎖定

問題現象：:

模塊讀取SIM卡，第一次上線後入網功能和業務功能全部正常（在不斷線的情況下一直正常）。第二次上線後無法註冊網絡。

問題原因：

研發最初定位原因為網絡服務被限制，但運營商查詢後台業務正常。

後續卡商參與分析並提供了模塊和SIM卡之間的交互信息。

卡端獲取IMEI的過程：

1、終端發送Terminal Profile

2、卡片發送”Provide Local Information”指令，獲取終端的IMEI值

3、終端發送”Provide Local Information”的Terminal Response

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

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

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

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

2. 設備綁定

問題現象：

SIM卡插到模塊上能正常使用，更換到另外一個模塊則無法註冊網絡。

問題原因:

運營商查看SIM卡對應的後台服務，已經處於未激活的狀態。

重新激活後，SIM卡能正常使用。把SIM卡再次更換一個設備，則無法註冊。

經運營商確認，該卡第一次註冊網絡後，會綁定IMEI號，也就是通常所說的設備綁定。只能固定使用同一個IMEI號。

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

3. SIM卡文件損壞

問題現象：

SIM卡使用一段時間後，出現無法註冊網絡的情況。

問題分析：

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

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

對上述文件做空間分析分析後，對6F5B文件所在Flash區域做壽命分析發現，起壽命已經達到了極限，終端無法進行正常的選擇和讀寫該文件。

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

在國際規範中規定卡片文件級更新次數不少於10萬次。

問題原因:

模塊頻繁讀寫SIM卡文件，導致SIM卡文件損壞，最終無法註冊網絡。

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

4. SIM卡協議不規範

問題現象：

模塊使用特定SIM卡無法PS網絡，但在手機上可以正常使用。

問題分析：

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

查看兩個模塊的開機註冊網絡log，發現讀取SIM卡EF文件的命令參數P1有區別：

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

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

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

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

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

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

問題原因:

SIM卡協議不完全符合規範，讀取文件失敗，導致無法註冊PS網絡。

5. PLMN未加入列表

問題現象：

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

問題原因：

模塊未加入相應的PLMN名稱，模塊認為是非法的運營商名稱，導致無法註冊網絡。

6. SIM卡未開通4G業務

問題現象：

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

問題分析：

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

和運營商確定，該卡未開通4G業務。

在註冊4G網絡時，收到reject原因為MISSING OR UNKNOWN APN，不能自動切換到3G小區註冊。而當地4G信號良好，模塊一直嘗試註冊4G，導致模塊一直無法註冊上網。

問題解決方案：

當註冊4G網絡連續失敗3次，並且原因是ESM_FAILURE時，鎖定到3G/2G模式，不再註冊4G小區。掉電恢復4G/3G/2G。

7. PA損壞

問題現象：

模塊無法註冊網絡。

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

問題分析：

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

可能的原因：

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

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

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

8. FLASH被改寫

問題現象：

模塊無法註冊網絡，經判斷模塊無法正常開機。

問題分析：

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

b. JTAG類工具跟蹤調試

一般為boot階段的Flash數據被改寫，各模塊均出現過類似問題。

問題解決方案：

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

b. 模塊軟件採用備份機制進行規避。

9. TCP本地端口固定

問題現象：

模塊通過TCP連接服務器，由於斷電等異常情況未正常關閉TCP連接。

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

問題原因：

客戶在調用AT+MIPOPEN=1,local port,”服務器IP”,remote port時，設置了local port參數，每次建立連接時都使用同樣的本地端口。

客戶使用的SIM卡為物聯網卡且綁定了IP地址。

有些服務器在連接異常斷開後，短時間內不允許同一IP地址同一端口號的連接再次接入。

問題解決方案：

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

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

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

10. 心跳間隔太長

問題現象：

模塊TCP連接經常斷開。

問題原因：

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

終端如果在一段時間內，沒有交互數據業務，網絡側會釋放相應的資源，且無任何信令下發。普通SIM卡更容易發生這種情況。

因此在正常的業務數據交互之外，需增加TCP心跳機制，以一定時間間隔向服務器發送心跳包。

該時間間隔，視運營商當地網絡而定，有些可能幾個小時，有些可能1分鐘。在印尼有測到過45秒時間的。

11. 運營商防火牆

問題現象：

在當地用物聯網卡測試10次以內，就會出現無法連接服務器的問題，需要重新撥號或者重啟恢復。

在其他城市採用該物聯網測試，不能復現問題現象。

在當地使用公網卡進行測試，沒有問題。

問題分析：

經運營商分析，由於現網升級改造試點，在改造過程中需要對華為防火牆的策略進行更新。

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

問題解決方案：

運營商側，華為防火牆軟件打補丁。

12. QOS協商

問題現象：

設備連接服務器困難。 查看模塊AT交互log，模塊在PDP激活之後，連接客戶服務器經常失敗。失敗概率大概在90%以上。

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

問題分析：

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

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

正常情況：

異常情況：

網絡下發的ACTIVATE PDP CONTEXT ACCEPT中Relibility Class為5.

終端上報ACTIVATE PDP CONTEXT REQUEST中Relibility Class是3，網絡在ACTIVATE PDP CONTEXT ACCEPT中下發是5

Reliability Class的取值，取決於終端請求、HLR簽約、網絡支持QoS中的最大值。根據3GPP協議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

網絡側下發的SDU error ratio為1e-3

網絡根據SDU error ratio取值，自動將Reliability Class修改為5。

從模塊側的交互流程來看：

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

b. 網絡回復的Reliability是5，即Unack RLC mode

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

問題解決方案：

模塊修改軟件，即使網絡下發的QOS Reliability協商結果為5，仍然按照ACK RLC mode的方式發送數據。