问题现象：:
模块读取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的方式发送数据。