手机登网速度研究

0. 前言

有个客户反复投诉我们，说客户在漫游时登陆网络很慢，甚至有长达十几分钟没有信号，给客户的体验非常不好。之前做了很久的调查，把卡上的Multi IMSI应用做了各种针对性的优化，但是一直得不到明显的改善。

前几天客户来了新的投诉，我们的SIM卡在非漫游的情况下，第一次登网很慢，大概需要3~5分钟，但是别人的卡登网就很快，基本在10秒以内。所以他的客户体验非常不好。

一看这是个好机会啊，条件约束较多，可以排除不少变量。赶紧寄读卡器和空白卡片到客户那里，做本地测试，终于找到真正原因。

在此也衷心感谢ASR的伙伴（虽然他应该看不到），给了我非常明确的方向。

1. 分析过程

整件事情从事后倒回来看，似乎很简单。但是在整个分析过程中，因为涉及到太多因素，需要一一排查，抽丝剥茧，花了很长的时间才最终定位。

1.1 网络端：

• 客户本身是虚商，是否合作网络有意无意，或者在流程上的限制，导致登网较慢？例如第一次收到附着请求后，需要在后台激活一次？

  A：无法分析。

• 客户有自己的HSS，但是分布位置未知。是否存在网络延迟，导致鉴权较慢？

  A：延迟未知。但是根据手机Log来看，鉴权请求本身就在很晚才发送。所以这个因素应该可以排除。

1.2 手机端

• 客户反馈在LTE模式登网较慢，在2G模式较快。是否和网络制式相关？例如现在2G退网是大势所趋，在海外很多国家都开始退网。可能正好客户的合作伙伴2G没退网，所以很快就能搜索到？

  A：无法确认。但是这个猜测非常有可能。

• 各种型号的手机，登网速度不一。有长有短。

  A：在之前调查过程中，确实发现手机表现不一。但是找不到共性。

1.3 卡端

• 卡片硬件处理速度跟不上？

  A：理论上不会。因为随着技术进步，卡片的主频一直在上升。但是机卡通道的通信速率受到规范限制。

• 卡片COS跟特定手机的波形匹配有问题？

  A：有这个怀疑，但是用示波器做了底层信号分析，并没有找到证据。

• 卡片应用有问题？

  A：已经采用了各种手段，包括位置探测，事件处理，定时发起等各种手段。而且这次实际上不涉及到号码切换，完全可以把应用可能给排除掉。

• 卡片Profile有问题？

  A: 考虑过各种附着失败可能性，例如由于虚商或各种因素，导致附着失败，合作方PLMN被写入FPLMN。所以专门开发了应用FPLMN Cleaner。

  A：考虑过卡片登网优先网络选择，更新各个LOCI文件中的值；

  A：在中国做过模拟测试，发现某些手机在某些特定文件会停止交互一段时间，原因未知，只能从机卡交互看到手机停止向SIM卡发送APDU指令。

2. 结论

之前最多只能用我们的跟踪仪来跟踪机卡交互。这次我们客户创造性的抓了手机基带芯片的Log；我研究了两天高通的QCAT工具，居然在里面找到了怎么过滤APDU指令。而更关键的帮助在于ASR的小伙伴明确指出，这个是选网问题。他能看出来手机是在全频段全频点搜网，所以附着才会这么慢。

问题最终得到解决，是找客户拿了一批数据，每种配置做一张全新的测试卡，进行各种配置的测试。简单说结论如下：

• 原因：客户是虚商，卡内IMSI的MCC-MNC并不存在于接入网。如果卡端Profile没有做相应配置，手机在空口找不到对应的PLMN ID，就需要全频段搜网。
• 方法：LOCI文件和EHPLMN有大用

当然，我们后续还需要在全世界进行测试，确保不会引起其他附着问题。毕竟归根结底，卡只能提供信息，终端到底怎么理解和执行，并不在我们的控制范围之内。

3. 选网过程

3GPP TS 23.122详细解释了如何选网。按照这个规范所讲，在自动模式下，选网优先级如下

RPLMN > EHPLMN/HPLMN > PLMNwAct > OPLMNwAct > 其他高质量PLMN随机排序 > 信号强度排序

3.1 RPLMN

RPLMN，就是Registered PLMN。从网上信息来看，是由EPC传送给UE，但是UE具体怎么管理，没找到明确说法，可能是SoC自行决定。到目前为止（2022.04.02），没有找到RPLMN在卡中明确的存储位置。

根据ASR的说法，他们处理方式为存储到卡上的LOCI文件中。这个说法完全可以采信，也跟我们平时的经验相符合。我们平时在跟踪机卡交互的时候，能看到手机在鉴权成功后，都会更新对应文件，包括各种Key文件以及LOCI文件。

3.1.1 LOCI 文件分类和内容

按照TS 31.102，有如下几种LOCI文件，分别对应不同的网络制式

• EF_6F7E_LOCI - 对应2G网络

  文件内容为：TMSI | LAI | RFU | LU_Status

• EF_6F73_PSLOCI

  文件内容为：P-TMSI | P-TMSI SV | RAI | RAU_Status

• EF_6FE3_EPSLOCI

  文件内容为：GUTI | Last Visited RTAI | EPSU_Status

• EF_4F01_5GS3GPPLOCI

  文件内容为：5G-GUTI | Last Visited RTAI | 5GSU_Status

• EF_4F02_5GSN3GPPLOCI

  文件内容格式同上，用于非3GPP网络，可以忽略

可以看出，格式基本一致，这些LOCI文件会保存如下信息

• 终端临时标识
• 上次登网信息
• 位置更新状态

到目前为止，都是我们以前就知道的信息。而下面部分就是这次新得到信息

3.1.2 位置更新状态

按照TS 31.102，可以看出来，位置更新状态字节的含义基本一致如下：

• 00 - Updated
• 01 - Not Updated
• 02 - 2G - PLMN not allowed; 3G/4G - Roaming Not Allowed
• 03 - 2G - Location Area not allowed

一般来讲，我们是把这个字节更新为01，有三个原因

• 3GPP在TS 31.102中的建议值是0x01
• 全球各大运营商的默认值也是0x01
• 非官方：根据实践来看，如果这个字节设置为0x01，设备开机会主动发起附着请求。以前中国移动有要求开发一个“强制鉴权”特性，就是通过这个字节来进行控制。

但是，按照SoC小伙伴的信息，如果我们把这个值设置为01，则设备会认为文件中“上次登网信息”中的信息是无效的。

所以，我们虽然写了网络PLMN ID在文件中，这个值事实上没有被设备用于加快网络选择。

而实验结果也证实了这点。我们把这个字节改为0x00后，同款小米10的登网速度就立刻降到了10秒以内。

3.1.3 LOCI文件的优先级

因为这里有5个LOCI文件。那到底哪个的优先级更高呢？我把问题抛给了SoC小伙伴，得到的答复是：

1. 他们目前的设备还不支持5G
2. PSLOCI一般不用（注：根据我的观察，这个文件应该是和访问技术有关。以前的log就更新的PSLOCI文件，新的Log就更新EPSLOCI。应该是因为现在主流是4G LTE网络，3G在退网）
3. LOCI和EPSLOCI一般来讲是放的同样的PLMN ID

3.2 EHPLMN/HPLMN

EHPLMN就是等效HPLMN，特别适合虚商，或者有几个MNC ID的运营商。例如中国移动，就在自己的Profile里面把所有的MNC都写了进去。

按照规范要求，设备先看有不有EHPLMN，有的话就用这个文件内的PLMN ID去搜网。如果没有，就用HPLMN。

这个步骤有两个坑：

• 大坑：如果EHPLMN存在，那么设备搜网就以它为准，不会再去搜HPLMN。所以如果有这个文件，就要写完整。不然可能反而更慢
• 天坑：在USIM卡上，有个文件叫做EF_HPLMNwAct。它的文件内容和编码格式跟另两个EF_PLMNwAct和EF_OPLMNwAct一模一样，名字看起来也很相似，似乎作用也会和另外两个一样，提供HPLMN让设备快速搜网的。然而并不是！在TS 23.122中，明确指出"HPLMN是从IMSI中获得"，而EF_HPLMNwAct其实只是提供对应的访问技术

3.3 HPLMN和OPLMN

这两个文件理论上可以帮助设备快速寻网。但是实际上还不清楚，在等待客户的进一步测试。

4. 关于高通QCAT的使用

4.1 如何获取基带log

每个手机厂商都有自己的指令。小米是用键盘拨号*#*#995995#*#*就可以开始和停止抓取基带log，然后在sdcard/diag_logs...目录下可以找到对应的qmdl文件。然而用最新的小米12做了测试，抓出来的是qmdl2，里面信息量非常少，用Realme抓出来的也是同样的情况。

4.2 如何分析基带log

刚才举例的是小米，使用的是高通的基带芯片。所以取出来的日志文件就可以用高通的日志分析工具QCAT来进行分析。其他的基带厂商也需要自己的工具，具体怎么找到好用的工具，属于技术人员必备技能，就不详f细解释。

日志里面包含了所有的信息，非常详细。做为智能卡商，我们不需要知道这么多的信息。只需要注意下面三点

4.2.1 过滤器设置

使用过滤器，可以快速筛选出需要的数据。其中0x19B7就代表APDU指令，必须选择。为了协助分析，可以再把MM相关选上，可以看到一些网络信号相关的信息。

下面是一些我认为比较有用的参数

• 0x19B7 UIM APDU
• 0x7130 UMTS NAS_GMM State
• 0x7131 UMTS NAS_MM State
• 0x7132 UMTS RAS_REG State
• 0x7150 UMTS NAS EPLMN List Log Packet
• 0xB0F5 LTE NAS EMM USIM Service Table
• 0xB0F7 LTE NAS EMM RRC Service Request

4.2.2 敏感数据处理

在机卡交互的APDU中，日志或者工具隐藏了一些敏感数据。例如各种临时Key，临时标识，鉴权数据等，而统一显示为0xFF。需要小心分辨到底是被隐藏了，还是卡上原始数据如此。

4.2.3 文件选择

为了加快终端对USIM卡的操作速度，技术规范中制定了SFI（短文件标识符）。终端可以通过SFI，直接对EF进行操作，而不用先进行选择文件，从而可以节约至少一条APDU指令的时间。

但是这个对我们的log解读会造成一些困扰。因为我们记文件ID很熟，但是SFI确实记不住。在APDU编码中，对于二进制文件的读写操作，编码方式为在P1中指定想要操作的SFI。b8b7b6 = '100'标明使用SFI，b5~b1 = SFI。简单说就是对二进制文件，需要再对SFI加8才是实际的APDU中的值。

另外，SFI是在当前DF才有唯一性。所以还需要往前面的APDU指令交互检查，看到底是在哪个DF下。

下面是分析Log常用的一些SFI：

文件名	文件ID	SFI	APDU
EF_IMSI	ADF_USIM_EF_6F07	0x07	0x87
EF_LOCI	ADF_USIM_EF_6F7E	0x0B	0x8B
EF_PSLOCI	ADF_USIM_EF_6F73	0x0C	0x8C
EF_EPSLOCI	ADF_USIM_EF_6FE3	0x1E	0x9E
EF_5GS3GPPLOCI	DF_5GS_EF_4F01	0x01	0x81
EF_5GSN3GPPLOCI	DF_5GS_EF_4F02	0x02	0x82

5 参考规范

TS 23.122 v16.9.0 Non-Access-Stratum (NAS) functions related to Mobile Station (MS) in idle mode

TS 31.102 v16.4.0 Characteristics of the Universal Subscriber Identity Module (USIM) application