UICC初始化访问分析与优化

周代卫　周宇　孙向前

【摘 要】针对移动终端初始化时对UICC访问过程的优化需求，介绍了UICC初始化过程中的分阶段分析方法，并分别从时间参数、APDU命令和访问文件等四个方面结合具体实验数据加以整理和分析，最后从数据传输、APDU命令和访问文件等方面提出合理的UICC访问优化建议。

【关键词】UICC 机卡接口 APDU命令 文件访问 访问优化

中图分类号：TN929.5 文献标识码：A 文章编号：1006-1010（2014）-03-

1 引言

通用集成电路卡（UICC，Universal Integrated Circuit Card）作为移动通信系统中全球用户身份识别模块（USIM，Universal Subscriber Identity Module）的主要载体，已广泛应用于各制式的移动通信系统中，如GSM、WCDMA、TD-SCDMA、CDMA2000、LTE等。其作为通用智能卡平台，可同时支持一项或多项业务应用，如USIM、ISIM（IMS SIM）、CSIM（CDMA SIM），以及近场通信（NFC，Near Field Communication）、SWP/HCI（Single Wire Protocol/Host Controller Interface）和物联网嵌入式SIM卡等功能。

随着移动终端设备的快速发展和普及，用户对终端设备的使用体验有了更高的要求，特别是开机速度、短信和联系人存贮容量与读取速度等方面。而多模多卡智能终端的广泛使用，以及日益复杂的UICC业务功能和逐步提高的卡片容量等因素都对终端设备初始化时的用户体验带来了一定的影响。因此，根据UICC相关技术规范和功能特点，结合实际对比测试数据，对影响用户体验的各因素做详细的比较和分析，并提出对UICC初始化的优化建议显得尤为必要，特别是从UICC的应用层面做访问优化。

2 分析方法

2.1 分析背景

当前移动终端和UICC支持的应用和业务越来越丰富和复杂，用户在开机初始化时需等待的时间也越来越长，这无疑对用户体验带来了负面影响。而纵观整个初始化过程，UICC的初始化访问成为耗时的重要因素之一。

终端设备在初始化时与UICC相关的操作通常包含如下三方面：

（1）终端设备的操作：包含终端软件初始化，终端发送给UICC的APDU（Application Protocol Data Unit）命令的准备和处理，以及移动网络的注册登记。

（2）UICC和终端设备机卡接口的操作：包括机卡接口上的数据传输，该接口须符合ETSI TS 102 221或TS 102 600的要求。

（3）UICC的操作：包括UICC软件初始化和对APDU命令的处理。

通常耗费在第一项和第三项上的时间受诸多因素的影响，如：终端设备和UICC的硬件规格，终端提供给UICC的电压、电流和时钟信号频率，终端的读卡策略与先后顺序，搜索和注册网络的快慢，以及终端和UICC各自操作系统的软件架构和执行效率等。对于第二项，由于需遵循标准的技术规范且受外部影响较小，因此将成为本文的讨论重点。

为进一步明晰UICC开机初始化时的优化方向，首先需理清在UICC访问过程中进行了何种操作，读取了哪些文件以及相应耗费的时间。然而无法将市面上所有终端设备和各种类型的UICC逐一做对比实验和数据分析，比较适用的方法是随机选取几款较为典型的终端和普遍使用的UICC作为样本加以分析。

2.2 实验方法

针对上述分析背景中的介绍，对比实验可以分为如下三个阶段：

阶段一：使用抓包工具抓取开机初始化时卡接口上所有通信数据，可使用终端Logging或COMPRION IT3/Move等工具；

阶段二：借助PC和读卡器测量阶段一中抓取的数据序列时间，可使用COMPRION MoVie或Gemalto Card Admin等工具；

阶段三（可选）：如果终端初始化时没有选择UICC所支持的最大波特率（Baud rate），则使用最大波特率重复阶段二。

注：对比测试时保持PIN码、FDN、BDN等关闭，且只有一种卡应用。

（1）阶段一

阶段一是为了获取机卡接口上完整数据流，具体实验步骤如下：

1）将抓包工具连接上终端设备和UICC，并准备抓取数据；

2）终端设备开机直至初始化完成；

3）停止抓包并将抓取的数据保存成Log文件；

4）整理并分析抓取的Log文件中APDU的数量、字节数和访问文件等；

5）重复步骤1～4，并取五次平均值。

（2）阶段二

阶段二是为了排除初始化时终端设备自身的处理时间而集中于卡接口，步骤如下：

1）将插入UICC的读卡器连上PC端；

2）使用并过滤阶段一中抓取的Log创建APDU Database；

3）将Database中的APDU以UICC支持的最快速率发送给UICC，并测量各APDU所耗费的时间以及总共消耗的时间；

4）记录并分析测量的数据结果。

（3）阶段三

阶段三是为了验证在选用最佳操作参数后可节省的时间。如果阶段二中PC已经选用了最大波特率，则阶段三可跳过。

3 UICC访问分析

按照上一章的实验分析方法，本章将基于实际测试数据分别从时间参数、APDU命令和访问文件等方面对UICC初始化过程加以分析。

3.1 时间参数

终端初始化时UICC访问过程中主要考察分析的时间参数有：endprint

（1）数据传输时间DTT（Data Transmission Time）：用于衡量初始化时数据传输的总时间；

（2）UICC处理时间UPT（UICC Processing Time）：用于衡量UICC处理APDU所用的总时间；

（3）终端处理时间TPT（Terminal Processing Time）：用于衡量终端收到Response之后到发送APDU之前的总处理时间；

（4）UICC访问时间UAT（UICC Access Time）：用于衡量初始化时UICC访问的总时间，它包含DTT和UPT，代表了终端初始化时访问UICC所需要的总时间；

（5）UICC初始化时间UIT（UICC Initialization Time）：用于衡量初始化时UICC上电或重置后到UICC访问完毕间的总时间，包括UAT和TPT以及终端搜网注册时间。

3.2 UICC访问时间分析

按照第二章的实验方法，从Log中ATR TA1和PPS1的参数来看，所有的终端都支持并使用ISO/IEC 7816机卡接口，且能正确选择UICC所支持的最快速率传输数据，因此阶段三的测试可以省略。

（1）数据传输时间DTT

在ISO/IEC 7816接口上，每一个APDU Byte均被添加上一个起始位（start bit），一个校验位（parity bit）和一个停止位（stop bit），所以每个Byte需要传输11比特的TPDU数据。而数据总量和数据传输速率将直接影响到DTT的结果。

终端发送给UICC和UICC返回的TPDU Byte总数，以及数据传输时间DTT和其在UAT中的占比如表1所示。

从表1中可知DTT集中在1.2s到4.6s之间，平均为2.6s，占UAT的18.8%。DTT对比结果如图1所示，图中卡1和卡4的DTT明显小于卡2和卡3，主要是因为卡1和卡4支持的最大波特率为223.2kbps，而卡2和卡3只有111.6kbps，因此卡1和卡4的平均DTT约为1.6s，而卡2和卡3约为3.6s。

（2）UICC处理时间UPT

UPT受多重因素的影响，如：UICC硬件规格、软件性能、收到的APDU命令、机卡接口电流特性和时钟频率等，而其硬件结构和软件实现将不在本文的讨论范围内。

UPT的测量结果是由UAT减去DTT得出，集中在1.7s到29.2s间，平均为12.0s，占UAT的82.2%。

（3）终端处理时间TPT

TPT也受多重因素的影响，如：终端硬件规格、软件性能、发送的APDU命令和终端正在运行的其他业务活动等，而其软硬件性能和其他业务活动将不在本文的讨论范围内，而终端发送的APDU命令将是本文的讨论重点，其总量的减少将导致TPT和UAT的降低。

TPT的测量结果是由UIT减去UAT得出，集中在0.9s到48.7s间，平均为23.0s，占UIT的61.2%。

（4）UICC访问时间UAT

UAT的测量结果可参考表2的测试数据，集中在4.8s到31.7s间，平均为14.6s，占UIT的38.8%。

表2 UICC访问时间（s）

UICC #1 UICC #2 UICC #3 UICC #4

终端 #1 17.7 7.9 8.3 31.7

终端 #2 19.1 14.2 5.1 15.3

终端 #3 18.8 13.9 4.8 18.0

（5）UICC初始化时间UIT

UIT为机卡接口上从收到第一个APDU到空闲态下最后一个APDU间的时间间隔，并无精准的界定方法，不过可采取逐步逼近的方法来测量。

UIT的测量结果可参考表3的数据，集中在8s到62s的范围内，平均为37.6s。

表3 UICC初始化时间（s）

UICC #1 UICC #2 UICC #3 UICC #4

终端 #1 40 23 57 62

终端 #2 20 49 23 23

终端 #3 45 54 8 47

UPT、TPT和DTT在UIT中的平均值分布如图2所示：

图2 UIT时间分布

3.3 APDU命令分析

终端初始化时发送给UICC的APDU命令序列和数量将直接影响UICC的访问时间。

（1）APDU命令的数量

通过对Log的分析，终端发送给UICC的APDU命令和数量各不相同，这与UICC文件结构、文件内容、终端的实现方式和支持的功能相关，其浮动范围在332至1 378之间，如图3所示：

图3 APDU命令数量

（2）READ/SEARCH命令

测试Log显示，APDU命令中READ BINARY和READ RECORD占了很大的比例，一些终端还同时使用了SEARCH RECORD，这三种命令占APDU命令总数的35%到83%，平均约占59.8%，如图4所示：

READ/SEARCH命令从UICC中读取了大量的数据，约占总数据量的34%到88%，平均为66.7%，详见表4所示：

同样，READ/SEARCH命令也消耗了大量的时间，范围从1.8s到22.4s，平均约为8.4s，占UAT的57.5%，如图5所示。

3.4 文件访问分析

终端通过READ BINARY和READ RECORD等命令访问了很多UICC文件并读取了大量的数据，对这些文件的归类和分析一定程度上将有助于优化UICC访问流程。endprint

（1）访问文件的数量

终端初始化时访问的文件数量因终端和UICC的不同组合而异，且每款终端都有特定的UICC文件访问流程。但访问的文件数量依赖于UICC上存在的文件，其数量在56到114个之间，平均为84个，同时有很多文件被多次读取，SELECT命令的总数量在105到327个之间，平均每个文件被选择了1.7到3.3次，如图6所示。

（2）频繁访问文件FVF（Frequently Visited File）

在测试实验中，一些特定EF（Elementary File）文件被READ BINARY和READ RECORD重复执行了多次，当读取EF文件中的记录（Record）时，其长度可能很短，而READ RECORD命令只能一次读取一份记录，因此这些文件会被频繁访问并读取多次，如电话簿、短信和首选网络等。

表5列出了通过READ RECORD或READ BINARY命令访问10次以上的文件。文件名一栏列出了文件路径和名称，数据长度一栏列出了READ RECORD和READ BINARY命令从该文件中读取的数据长度。

表6列出了FVF的数量和其占总访问文件数的百分比，以及READ RECORD和READ BINARY所访问的FVF次数和占所有READ命令的百分比。

总体而言，FVF因终端和UICC的组合而异，且只占总访问文件的少数，但对这些FVF的读取却占了大量的时间，如图7所示。

4 总结

以上对UICC访问的分析显示初始化过程中大部分时间消耗在终端和UICC上，显然改进终端和UICC硬件规格及软件实现方式能显著优化初始化过程。不过这和当前可用技术、软硬件效率和成本相关，而这些通常都不在ETSI和其他标准开发组织的技术讨论范围内。

4.1 数据传输

因终端均选择了UICC所支持的最大传输速率，当前UICC支持最快223.2kbps。提供更高的基于ISO/IEC 7816接口的波特率或者采用高速USB接口将有助于加速UICC初始化过程。然而即使数据传输是瞬间完成的，根据之前的测试结果，平均节省的时间也只有2.6s左右。

4.2 APDU命令和文件访问

从对UICC APDU命令的分析可知，READ BINARY/READ RECORD/SEARCH RECORD这三个命令消耗了8.4s左右，大约占UAT的58%。如果在两个连续的初始化过程中终端没有换卡，则很多文件都没有改变。如果存在一种检测EF是否有更新的机制，这些不必要的READ命令将可以有效的避免，也将极大地降低READ/SEARCH命令的数量和传输时间，同时减少总的UAT。

从对访问文件的分析可知，不同终端和UICC组合将导致读取的文件也各不相同，然而都存在一些文件被多次读取。这些频繁访问文件包括电话簿、短信和运营商首选网络列表。如果用户选择在UICC以外存储电话簿和短信，如手机内存，也将有利于减少UICC初始化时间。

4.3 优化建议

基于对上述UICC访问过程的分析，特提出如下优化建议：

（1）增加一种可选机制使终端可检测EF文件是否有更新，该机制能有效减少机卡接口间的数据量和APDU命令处理时间，这将节省约8.4s的时间或者UAT的58%，同时也不会影响到终端用户的使用习惯和体验。

（2）扩展SEARCH RECORD命令以减少READ RECORD的使用，SEARCH RECORD通过对整个线性固定（Linear fixed）或循环（Cyclic）文件的搜索来找出特定模式或内容的Record。实际上SEARCH RECORD并未被所有终端厂商高效利用，可能是因为这个命令在实现厂商需求时不够弹性化，而对该命令的扩展将可以减少对READ RECORD的使用，从而降低APDU命令处理时间和数据传输时间。

（3）使UICC能提供更高的数据传输速率以节省时间，不过此机制节省的时间相对有限，且会伴随硬件成本的提升。

当前终端设备的UICC平均初始化时间在37.6s左右，以上机制将可节省至少10s的时间，效率提升26.6%以上。不过需注意的是，第一种和第二种机制不需要对硬件部分做更改与升级，这意味着在显著提升用户体验的同时无须增加终端设备硬件成本。

参考文献：

[1] 3GPP TS 31.101 V11.0.0. UICC-terminal interface； Physical and logical characteristics[S].

[2] 3GPP TS 31.102 V12.2.0. Characteristics of Universal Subscriber Identity Module（USIM） application[S].

[3] 3GPP TS 31.110 V4.1.0. Numbering system for telecommunication IC card applications[S].

[4] 3GPP TS 31.220 V11.0.0. Characteristics of the Contact Manager for 3GPP UICC applications[S].

[5] ISO/IEC 7816 Series（2006）. Identification cards—Integrated circuit cards[S].

[6] ETSI TS 101 220 V1.0.0. ETSI numbering system for telecommunication application providers[S].

[7] ETSI TS 102 221 V11.1.0. UICC-Terminal interface； Physical and logical characteristics[S].

[8] ETSI Tdoc SCP（13）000272r1. LS on UICC Access Optimization[S].★endprint

（1）访问文件的数量

终端初始化时访问的文件数量因终端和UICC的不同组合而异，且每款终端都有特定的UICC文件访问流程。但访问的文件数量依赖于UICC上存在的文件，其数量在56到114个之间，平均为84个，同时有很多文件被多次读取，SELECT命令的总数量在105到327个之间，平均每个文件被选择了1.7到3.3次，如图6所示。

（2）频繁访问文件FVF（Frequently Visited File）

在测试实验中，一些特定EF（Elementary File）文件被READ BINARY和READ RECORD重复执行了多次，当读取EF文件中的记录（Record）时，其长度可能很短，而READ RECORD命令只能一次读取一份记录，因此这些文件会被频繁访问并读取多次，如电话簿、短信和首选网络等。

表5列出了通过READ RECORD或READ BINARY命令访问10次以上的文件。文件名一栏列出了文件路径和名称，数据长度一栏列出了READ RECORD和READ BINARY命令从该文件中读取的数据长度。

表6列出了FVF的数量和其占总访问文件数的百分比，以及READ RECORD和READ BINARY所访问的FVF次数和占所有READ命令的百分比。

总体而言，FVF因终端和UICC的组合而异，且只占总访问文件的少数，但对这些FVF的读取却占了大量的时间，如图7所示。

4 总结

以上对UICC访问的分析显示初始化过程中大部分时间消耗在终端和UICC上，显然改进终端和UICC硬件规格及软件实现方式能显著优化初始化过程。不过这和当前可用技术、软硬件效率和成本相关，而这些通常都不在ETSI和其他标准开发组织的技术讨论范围内。

4.1 数据传输

因终端均选择了UICC所支持的最大传输速率，当前UICC支持最快223.2kbps。提供更高的基于ISO/IEC 7816接口的波特率或者采用高速USB接口将有助于加速UICC初始化过程。然而即使数据传输是瞬间完成的，根据之前的测试结果，平均节省的时间也只有2.6s左右。

4.2 APDU命令和文件访问

从对UICC APDU命令的分析可知，READ BINARY/READ RECORD/SEARCH RECORD这三个命令消耗了8.4s左右，大约占UAT的58%。如果在两个连续的初始化过程中终端没有换卡，则很多文件都没有改变。如果存在一种检测EF是否有更新的机制，这些不必要的READ命令将可以有效的避免，也将极大地降低READ/SEARCH命令的数量和传输时间，同时减少总的UAT。

从对访问文件的分析可知，不同终端和UICC组合将导致读取的文件也各不相同，然而都存在一些文件被多次读取。这些频繁访问文件包括电话簿、短信和运营商首选网络列表。如果用户选择在UICC以外存储电话簿和短信，如手机内存，也将有利于减少UICC初始化时间。

4.3 优化建议

基于对上述UICC访问过程的分析，特提出如下优化建议：

（1）增加一种可选机制使终端可检测EF文件是否有更新，该机制能有效减少机卡接口间的数据量和APDU命令处理时间，这将节省约8.4s的时间或者UAT的58%，同时也不会影响到终端用户的使用习惯和体验。

（2）扩展SEARCH RECORD命令以减少READ RECORD的使用，SEARCH RECORD通过对整个线性固定（Linear fixed）或循环（Cyclic）文件的搜索来找出特定模式或内容的Record。实际上SEARCH RECORD并未被所有终端厂商高效利用，可能是因为这个命令在实现厂商需求时不够弹性化，而对该命令的扩展将可以减少对READ RECORD的使用，从而降低APDU命令处理时间和数据传输时间。

（3）使UICC能提供更高的数据传输速率以节省时间，不过此机制节省的时间相对有限，且会伴随硬件成本的提升。

当前终端设备的UICC平均初始化时间在37.6s左右，以上机制将可节省至少10s的时间，效率提升26.6%以上。不过需注意的是，第一种和第二种机制不需要对硬件部分做更改与升级，这意味着在显著提升用户体验的同时无须增加终端设备硬件成本。

参考文献：

[1] 3GPP TS 31.101 V11.0.0. UICC-terminal interface； Physical and logical characteristics[S].

[2] 3GPP TS 31.102 V12.2.0. Characteristics of Universal Subscriber Identity Module（USIM） application[S].

[3] 3GPP TS 31.110 V4.1.0. Numbering system for telecommunication IC card applications[S].

[4] 3GPP TS 31.220 V11.0.0. Characteristics of the Contact Manager for 3GPP UICC applications[S].

[5] ISO/IEC 7816 Series（2006）. Identification cards—Integrated circuit cards[S].

[6] ETSI TS 101 220 V1.0.0. ETSI numbering system for telecommunication application providers[S].

[7] ETSI TS 102 221 V11.1.0. UICC-Terminal interface； Physical and logical characteristics[S].

[8] ETSI Tdoc SCP（13）000272r1. LS on UICC Access Optimization[S].★endprint

（1）访问文件的数量

终端初始化时访问的文件数量因终端和UICC的不同组合而异，且每款终端都有特定的UICC文件访问流程。但访问的文件数量依赖于UICC上存在的文件，其数量在56到114个之间，平均为84个，同时有很多文件被多次读取，SELECT命令的总数量在105到327个之间，平均每个文件被选择了1.7到3.3次，如图6所示。

（2）频繁访问文件FVF（Frequently Visited File）

在测试实验中，一些特定EF（Elementary File）文件被READ BINARY和READ RECORD重复执行了多次，当读取EF文件中的记录（Record）时，其长度可能很短，而READ RECORD命令只能一次读取一份记录，因此这些文件会被频繁访问并读取多次，如电话簿、短信和首选网络等。

表5列出了通过READ RECORD或READ BINARY命令访问10次以上的文件。文件名一栏列出了文件路径和名称，数据长度一栏列出了READ RECORD和READ BINARY命令从该文件中读取的数据长度。

表6列出了FVF的数量和其占总访问文件数的百分比，以及READ RECORD和READ BINARY所访问的FVF次数和占所有READ命令的百分比。

总体而言，FVF因终端和UICC的组合而异，且只占总访问文件的少数，但对这些FVF的读取却占了大量的时间，如图7所示。

4 总结

以上对UICC访问的分析显示初始化过程中大部分时间消耗在终端和UICC上，显然改进终端和UICC硬件规格及软件实现方式能显著优化初始化过程。不过这和当前可用技术、软硬件效率和成本相关，而这些通常都不在ETSI和其他标准开发组织的技术讨论范围内。

4.1 数据传输

因终端均选择了UICC所支持的最大传输速率，当前UICC支持最快223.2kbps。提供更高的基于ISO/IEC 7816接口的波特率或者采用高速USB接口将有助于加速UICC初始化过程。然而即使数据传输是瞬间完成的，根据之前的测试结果，平均节省的时间也只有2.6s左右。

4.2 APDU命令和文件访问

从对UICC APDU命令的分析可知，READ BINARY/READ RECORD/SEARCH RECORD这三个命令消耗了8.4s左右，大约占UAT的58%。如果在两个连续的初始化过程中终端没有换卡，则很多文件都没有改变。如果存在一种检测EF是否有更新的机制，这些不必要的READ命令将可以有效的避免，也将极大地降低READ/SEARCH命令的数量和传输时间，同时减少总的UAT。

从对访问文件的分析可知，不同终端和UICC组合将导致读取的文件也各不相同，然而都存在一些文件被多次读取。这些频繁访问文件包括电话簿、短信和运营商首选网络列表。如果用户选择在UICC以外存储电话簿和短信，如手机内存，也将有利于减少UICC初始化时间。

4.3 优化建议

基于对上述UICC访问过程的分析，特提出如下优化建议：

（1）增加一种可选机制使终端可检测EF文件是否有更新，该机制能有效减少机卡接口间的数据量和APDU命令处理时间，这将节省约8.4s的时间或者UAT的58%，同时也不会影响到终端用户的使用习惯和体验。

（2）扩展SEARCH RECORD命令以减少READ RECORD的使用，SEARCH RECORD通过对整个线性固定（Linear fixed）或循环（Cyclic）文件的搜索来找出特定模式或内容的Record。实际上SEARCH RECORD并未被所有终端厂商高效利用，可能是因为这个命令在实现厂商需求时不够弹性化，而对该命令的扩展将可以减少对READ RECORD的使用，从而降低APDU命令处理时间和数据传输时间。

（3）使UICC能提供更高的数据传输速率以节省时间，不过此机制节省的时间相对有限，且会伴随硬件成本的提升。

当前终端设备的UICC平均初始化时间在37.6s左右，以上机制将可节省至少10s的时间，效率提升26.6%以上。不过需注意的是，第一种和第二种机制不需要对硬件部分做更改与升级，这意味着在显著提升用户体验的同时无须增加终端设备硬件成本。

参考文献：

[1] 3GPP TS 31.101 V11.0.0. UICC-terminal interface； Physical and logical characteristics[S].

[2] 3GPP TS 31.102 V12.2.0. Characteristics of Universal Subscriber Identity Module（USIM） application[S].

[3] 3GPP TS 31.110 V4.1.0. Numbering system for telecommunication IC card applications[S].

[4] 3GPP TS 31.220 V11.0.0. Characteristics of the Contact Manager for 3GPP UICC applications[S].

[5] ISO/IEC 7816 Series（2006）. Identification cards—Integrated circuit cards[S].

[6] ETSI TS 101 220 V1.0.0. ETSI numbering system for telecommunication application providers[S].

[7] ETSI TS 102 221 V11.1.0. UICC-Terminal interface； Physical and logical characteristics[S].

[8] ETSI Tdoc SCP（13）000272r1. LS on UICC Access Optimization[S].★endprint