周代衛(wèi)　周宇　孫向前

【摘 要】針對移動終端初始化時對UICC訪問過程的優(yōu)化需求，介紹了UICC初始化過程中的分階段分析方法，并分別從時間參數(shù)、APDU命令和訪問文件等四個方面結(jié)合具體實驗數(shù)據(jù)加以整理和分析，最后從數(shù)據(jù)傳輸、APDU命令和訪問文件等方面提出合理的UICC訪問優(yōu)化建議。

【關(guān)鍵詞】UICC 機卡接口 APDU命令 文件訪問 訪問優(yōu)化

中圖分類號：TN929.5 文獻標識碼：A 文章編號：1006-1010（2014）-03-

1 引言

通用集成電路卡（UICC，Universal Integrated Circuit Card）作為移動通信系統(tǒng)中全球用戶身份識別模塊（USIM，Universal Subscriber Identity Module）的主要載體，已廣泛應(yīng)用于各制式的移動通信系統(tǒng)中，如GSM、WCDMA、TD-SCDMA、CDMA2000、LTE等。其作為通用智能卡平臺，可同時支持一項或多項業(yè)務(wù)應(yīng)用，如USIM、ISIM（IMS SIM）、CSIM（CDMA SIM），以及近場通信（NFC，Near Field Communication）、SWP/HCI（Single Wire Protocol/Host Controller Interface）和物聯(lián)網(wǎng)嵌入式SIM卡等功能。

隨著移動終端設(shè)備的快速發(fā)展和普及，用戶對終端設(shè)備的使用體驗有了更高的要求，特別是開機速度、短信和聯(lián)系人存貯容量與讀取速度等方面。而多模多卡智能終端的廣泛使用，以及日益復(fù)雜的UICC業(yè)務(wù)功能和逐步提高的卡片容量等因素都對終端設(shè)備初始化時的用戶體驗帶來了一定的影響。因此，根據(jù)UICC相關(guān)技術(shù)規(guī)范和功能特點，結(jié)合實際對比測試數(shù)據(jù)，對影響用戶體驗的各因素做詳細的比較和分析，并提出對UICC初始化的優(yōu)化建議顯得尤為必要，特別是從UICC的應(yīng)用層面做訪問優(yōu)化。

2 分析方法

2.1 分析背景

當前移動終端和UICC支持的應(yīng)用和業(yè)務(wù)越來越豐富和復(fù)雜，用戶在開機初始化時需等待的時間也越來越長，這無疑對用戶體驗帶來了負面影響。而縱觀整個初始化過程，UICC的初始化訪問成為耗時的重要因素之一。

終端設(shè)備在初始化時與UICC相關(guān)的操作通常包含如下三方面：

（1）終端設(shè)備的操作：包含終端軟件初始化，終端發(fā)送給UICC的APDU（Application Protocol Data Unit）命令的準備和處理，以及移動網(wǎng)絡(luò)的注冊登記。

（2）UICC和終端設(shè)備機卡接口的操作：包括機卡接口上的數(shù)據(jù)傳輸，該接口須符合ETSI TS 102 221或TS 102 600的要求。

（3）UICC的操作：包括UICC軟件初始化和對APDU命令的處理。

通常耗費在第一項和第三項上的時間受諸多因素的影響，如：終端設(shè)備和UICC的硬件規(guī)格，終端提供給UICC的電壓、電流和時鐘信號頻率，終端的讀卡策略與先后順序，搜索和注冊網(wǎng)絡(luò)的快慢，以及終端和UICC各自操作系統(tǒng)的軟件架構(gòu)和執(zhí)行效率等。對于第二項，由于需遵循標準的技術(shù)規(guī)范且受外部影響較小，因此將成為本文的討論重點。

為進一步明晰UICC開機初始化時的優(yōu)化方向，首先需理清在UICC訪問過程中進行了何種操作，讀取了哪些文件以及相應(yīng)耗費的時間。然而無法將市面上所有終端設(shè)備和各種類型的UICC逐一做對比實驗和數(shù)據(jù)分析，比較適用的方法是隨機選取幾款較為典型的終端和普遍使用的UICC作為樣本加以分析。

2.2 實驗方法

針對上述分析背景中的介紹，對比實驗可以分為如下三個階段：

階段一：使用抓包工具抓取開機初始化時卡接口上所有通信數(shù)據(jù)，可使用終端Logging或COMPRION IT3/Move等工具；

階段二：借助PC和讀卡器測量階段一中抓取的數(shù)據(jù)序列時間，可使用COMPRION MoVie或Gemalto Card Admin等工具；

階段三（可選）：如果終端初始化時沒有選擇UICC所支持的最大波特率（Baud rate），則使用最大波特率重復(fù)階段二。

注：對比測試時保持PIN碼、FDN、BDN等關(guān)閉，且只有一種卡應(yīng)用。

（1）階段一

階段一是為了獲取機卡接口上完整數(shù)據(jù)流，具體實驗步驟如下：

1）將抓包工具連接上終端設(shè)備和UICC，并準備抓取數(shù)據(jù)；

2）終端設(shè)備開機直至初始化完成；

3）停止抓包并將抓取的數(shù)據(jù)保存成Log文件；

4）整理并分析抓取的Log文件中APDU的數(shù)量、字節(jié)數(shù)和訪問文件等；

5）重復(fù)步驟1～4，并取五次平均值。

（2）階段二

階段二是為了排除初始化時終端設(shè)備自身的處理時間而集中于卡接口，步驟如下：

1）將插入UICC的讀卡器連上PC端；

2）使用并過濾階段一中抓取的Log創(chuàng)建APDU Database；

3）將Database中的APDU以UICC支持的最快速率發(fā)送給UICC，并測量各APDU所耗費的時間以及總共消耗的時間；

4）記錄并分析測量的數(shù)據(jù)結(jié)果。

（3）階段三

階段三是為了驗證在選用最佳操作參數(shù)后可節(jié)省的時間。如果階段二中PC已經(jīng)選用了最大波特率，則階段三可跳過。

3 UICC訪問分析

按照上一章的實驗分析方法，本章將基于實際測試數(shù)據(jù)分別從時間參數(shù)、APDU命令和訪問文件等方面對UICC初始化過程加以分析。

3.1 時間參數(shù)

終端初始化時UICC訪問過程中主要考察分析的時間參數(shù)有：endprint

（1）數(shù)據(jù)傳輸時間DTT（Data Transmission Time）：用于衡量初始化時數(shù)據(jù)傳輸?shù)目倳r間；

（2）UICC處理時間UPT（UICC Processing Time）：用于衡量UICC處理APDU所用的總時間；

（3）終端處理時間TPT（Terminal Processing Time）：用于衡量終端收到Response之后到發(fā)送APDU之前的總處理時間；

（4）UICC訪問時間UAT（UICC Access Time）：用于衡量初始化時UICC訪問的總時間，它包含DTT和UPT，代表了終端初始化時訪問UICC所需要的總時間；

（5）UICC初始化時間UIT（UICC Initialization Time）：用于衡量初始化時UICC上電或重置后到UICC訪問完畢間的總時間，包括UAT和TPT以及終端搜網(wǎng)注冊時間。

3.2 UICC訪問時間分析

按照第二章的實驗方法，從Log中ATR TA1和PPS1的參數(shù)來看，所有的終端都支持并使用ISO/IEC 7816機卡接口，且能正確選擇UICC所支持的最快速率傳輸數(shù)據(jù)，因此階段三的測試可以省略。

（1）數(shù)據(jù)傳輸時間DTT

在ISO/IEC 7816接口上，每一個APDU Byte均被添加上一個起始位（start bit），一個校驗位（parity bit）和一個停止位（stop bit），所以每個Byte需要傳輸11比特的TPDU數(shù)據(jù)。而數(shù)據(jù)總量和數(shù)據(jù)傳輸速率將直接影響到DTT的結(jié)果。

終端發(fā)送給UICC和UICC返回的TPDU Byte總數(shù)，以及數(shù)據(jù)傳輸時間DTT和其在UAT中的占比如表1所示。

從表1中可知DTT集中在1.2s到4.6s之間，平均為2.6s，占UAT的18.8%。DTT對比結(jié)果如圖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硬件規(guī)格、軟件性能、收到的APDU命令、機卡接口電流特性和時鐘頻率等，而其硬件結(jié)構(gòu)和軟件實現(xiàn)將不在本文的討論范圍內(nèi)。

UPT的測量結(jié)果是由UAT減去DTT得出，集中在1.7s到29.2s間，平均為12.0s，占UAT的82.2%。

（3）終端處理時間TPT

TPT也受多重因素的影響，如：終端硬件規(guī)格、軟件性能、發(fā)送的APDU命令和終端正在運行的其他業(yè)務(wù)活動等，而其軟硬件性能和其他業(yè)務(wù)活動將不在本文的討論范圍內(nèi)，而終端發(fā)送的APDU命令將是本文的討論重點，其總量的減少將導致TPT和UAT的降低。

TPT的測量結(jié)果是由UIT減去UAT得出，集中在0.9s到48.7s間，平均為23.0s，占UIT的61.2%。

（4）UICC訪問時間UAT

UAT的測量結(jié)果可參考表2的測試數(shù)據(jù)，集中在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到空閑態(tài)下最后一個APDU間的時間間隔，并無精準的界定方法，不過可采取逐步逼近的方法來測量。

UIT的測量結(jié)果可參考表3的數(shù)據(jù)，集中在8s到62s的范圍內(nèi)，平均為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命令分析

終端初始化時發(fā)送給UICC的APDU命令序列和數(shù)量將直接影響UICC的訪問時間。

（1）APDU命令的數(shù)量

通過對Log的分析，終端發(fā)送給UICC的APDU命令和數(shù)量各不相同，這與UICC文件結(jié)構(gòu)、文件內(nèi)容、終端的實現(xiàn)方式和支持的功能相關(guān)，其浮動范圍在332至1 378之間，如圖3所示：

圖3 APDU命令數(shù)量

（2）READ/SEARCH命令

測試Log顯示，APDU命令中READ BINARY和READ RECORD占了很大的比例，一些終端還同時使用了SEARCH RECORD，這三種命令占APDU命令總數(shù)的35%到83%，平均約占59.8%，如圖4所示：

READ/SEARCH命令從UICC中讀取了大量的數(shù)據(jù)，約占總數(shù)據(jù)量的34%到88%，平均為66.7%，詳見表4所示：

同樣，READ/SEARCH命令也消耗了大量的時間，范圍從1.8s到22.4s，平均約為8.4s，占UAT的57.5%，如圖5所示。

3.4 文件訪問分析

終端通過READ BINARY和READ RECORD等命令訪問了很多UICC文件并讀取了大量的數(shù)據(jù)，對這些文件的歸類和分析一定程度上將有助于優(yōu)化UICC訪問流程。endprint

（1）訪問文件的數(shù)量

終端初始化時訪問的文件數(shù)量因終端和UICC的不同組合而異，且每款終端都有特定的UICC文件訪問流程。但訪問的文件數(shù)量依賴于UICC上存在的文件，其數(shù)量在56到114個之間，平均為84個，同時有很多文件被多次讀取，SELECT命令的總數(shù)量在105到327個之間，平均每個文件被選擇了1.7到3.3次，如圖6所示。

（2）頻繁訪問文件FVF（Frequently Visited File）

在測試實驗中，一些特定EF（Elementary File）文件被READ BINARY和READ RECORD重復(fù)執(zhí)行了多次，當讀取EF文件中的記錄（Record）時，其長度可能很短，而READ RECORD命令只能一次讀取一份記錄，因此這些文件會被頻繁訪問并讀取多次，如電話簿、短信和首選網(wǎng)絡(luò)等。

表5列出了通過READ RECORD或READ BINARY命令訪問10次以上的文件。文件名一欄列出了文件路徑和名稱，數(shù)據(jù)長度一欄列出了READ RECORD和READ BINARY命令從該文件中讀取的數(shù)據(jù)長度。

表6列出了FVF的數(shù)量和其占總訪問文件數(shù)的百分比，以及READ RECORD和READ BINARY所訪問的FVF次數(shù)和占所有READ命令的百分比。

總體而言，F(xiàn)VF因終端和UICC的組合而異，且只占總訪問文件的少數(shù)，但對這些FVF的讀取卻占了大量的時間，如圖7所示。

4 總結(jié)

以上對UICC訪問的分析顯示初始化過程中大部分時間消耗在終端和UICC上，顯然改進終端和UICC硬件規(guī)格及軟件實現(xiàn)方式能顯著優(yōu)化初始化過程。不過這和當前可用技術(shù)、軟硬件效率和成本相關(guān)，而這些通常都不在ETSI和其他標準開發(fā)組織的技術(shù)討論范圍內(nèi)。

4.1 數(shù)據(jù)傳輸

因終端均選擇了UICC所支持的最大傳輸速率，當前UICC支持最快223.2kbps。提供更高的基于ISO/IEC 7816接口的波特率或者采用高速USB接口將有助于加速UICC初始化過程。然而即使數(shù)據(jù)傳輸是瞬間完成的，根據(jù)之前的測試結(jié)果，平均節(jié)省的時間也只有2.6s左右。

4.2 APDU命令和文件訪問

從對UICC APDU命令的分析可知，READ BINARY/READ RECORD/SEARCH RECORD這三個命令消耗了8.4s左右，大約占UAT的58%。如果在兩個連續(xù)的初始化過程中終端沒有換卡，則很多文件都沒有改變。如果存在一種檢測EF是否有更新的機制，這些不必要的READ命令將可以有效的避免，也將極大地降低READ/SEARCH命令的數(shù)量和傳輸時間，同時減少總的UAT。

從對訪問文件的分析可知，不同終端和UICC組合將導致讀取的文件也各不相同，然而都存在一些文件被多次讀取。這些頻繁訪問文件包括電話簿、短信和運營商首選網(wǎng)絡(luò)列表。如果用戶選擇在UICC以外存儲電話簿和短信，如手機內(nèi)存，也將有利于減少UICC初始化時間。

4.3 優(yōu)化建議

基于對上述UICC訪問過程的分析，特提出如下優(yōu)化建議：

（1）增加一種可選機制使終端可檢測EF文件是否有更新，該機制能有效減少機卡接口間的數(shù)據(jù)量和APDU命令處理時間，這將節(jié)省約8.4s的時間或者UAT的58%，同時也不會影響到終端用戶的使用習慣和體驗。

（2）擴展SEARCH RECORD命令以減少READ RECORD的使用，SEARCH RECORD通過對整個線性固定（Linear fixed）或循環(huán)（Cyclic）文件的搜索來找出特定模式或內(nèi)容的Record。實際上SEARCH RECORD并未被所有終端廠商高效利用，可能是因為這個命令在實現(xiàn)廠商需求時不夠彈性化，而對該命令的擴展將可以減少對READ RECORD的使用，從而降低APDU命令處理時間和數(shù)據(jù)傳輸時間。

（3）使UICC能提供更高的數(shù)據(jù)傳輸速率以節(jié)省時間，不過此機制節(jié)省的時間相對有限，且會伴隨硬件成本的提升。

當前終端設(shè)備的UICC平均初始化時間在37.6s左右，以上機制將可節(jié)省至少10s的時間，效率提升26.6%以上。不過需注意的是，第一種和第二種機制不需要對硬件部分做更改與升級，這意味著在顯著提升用戶體驗的同時無須增加終端設(shè)備硬件成本。

參考文獻：

[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）訪問文件的數(shù)量

終端初始化時訪問的文件數(shù)量因終端和UICC的不同組合而異，且每款終端都有特定的UICC文件訪問流程。但訪問的文件數(shù)量依賴于UICC上存在的文件，其數(shù)量在56到114個之間，平均為84個，同時有很多文件被多次讀取，SELECT命令的總數(shù)量在105到327個之間，平均每個文件被選擇了1.7到3.3次，如圖6所示。

（2）頻繁訪問文件FVF（Frequently Visited File）

在測試實驗中，一些特定EF（Elementary File）文件被READ BINARY和READ RECORD重復(fù)執(zhí)行了多次，當讀取EF文件中的記錄（Record）時，其長度可能很短，而READ RECORD命令只能一次讀取一份記錄，因此這些文件會被頻繁訪問并讀取多次，如電話簿、短信和首選網(wǎng)絡(luò)等。

表5列出了通過READ RECORD或READ BINARY命令訪問10次以上的文件。文件名一欄列出了文件路徑和名稱，數(shù)據(jù)長度一欄列出了READ RECORD和READ BINARY命令從該文件中讀取的數(shù)據(jù)長度。

表6列出了FVF的數(shù)量和其占總訪問文件數(shù)的百分比，以及READ RECORD和READ BINARY所訪問的FVF次數(shù)和占所有READ命令的百分比。

總體而言，F(xiàn)VF因終端和UICC的組合而異，且只占總訪問文件的少數(shù)，但對這些FVF的讀取卻占了大量的時間，如圖7所示。

4 總結(jié)

以上對UICC訪問的分析顯示初始化過程中大部分時間消耗在終端和UICC上，顯然改進終端和UICC硬件規(guī)格及軟件實現(xiàn)方式能顯著優(yōu)化初始化過程。不過這和當前可用技術(shù)、軟硬件效率和成本相關(guān)，而這些通常都不在ETSI和其他標準開發(fā)組織的技術(shù)討論范圍內(nèi)。

4.1 數(shù)據(jù)傳輸

因終端均選擇了UICC所支持的最大傳輸速率，當前UICC支持最快223.2kbps。提供更高的基于ISO/IEC 7816接口的波特率或者采用高速USB接口將有助于加速UICC初始化過程。然而即使數(shù)據(jù)傳輸是瞬間完成的，根據(jù)之前的測試結(jié)果，平均節(jié)省的時間也只有2.6s左右。

4.2 APDU命令和文件訪問

從對UICC APDU命令的分析可知，READ BINARY/READ RECORD/SEARCH RECORD這三個命令消耗了8.4s左右，大約占UAT的58%。如果在兩個連續(xù)的初始化過程中終端沒有換卡，則很多文件都沒有改變。如果存在一種檢測EF是否有更新的機制，這些不必要的READ命令將可以有效的避免，也將極大地降低READ/SEARCH命令的數(shù)量和傳輸時間，同時減少總的UAT。

從對訪問文件的分析可知，不同終端和UICC組合將導致讀取的文件也各不相同，然而都存在一些文件被多次讀取。這些頻繁訪問文件包括電話簿、短信和運營商首選網(wǎng)絡(luò)列表。如果用戶選擇在UICC以外存儲電話簿和短信，如手機內(nèi)存，也將有利于減少UICC初始化時間。

4.3 優(yōu)化建議

基于對上述UICC訪問過程的分析，特提出如下優(yōu)化建議：

（1）增加一種可選機制使終端可檢測EF文件是否有更新，該機制能有效減少機卡接口間的數(shù)據(jù)量和APDU命令處理時間，這將節(jié)省約8.4s的時間或者UAT的58%，同時也不會影響到終端用戶的使用習慣和體驗。

（2）擴展SEARCH RECORD命令以減少READ RECORD的使用，SEARCH RECORD通過對整個線性固定（Linear fixed）或循環(huán)（Cyclic）文件的搜索來找出特定模式或內(nèi)容的Record。實際上SEARCH RECORD并未被所有終端廠商高效利用，可能是因為這個命令在實現(xiàn)廠商需求時不夠彈性化，而對該命令的擴展將可以減少對READ RECORD的使用，從而降低APDU命令處理時間和數(shù)據(jù)傳輸時間。

（3）使UICC能提供更高的數(shù)據(jù)傳輸速率以節(jié)省時間，不過此機制節(jié)省的時間相對有限，且會伴隨硬件成本的提升。

當前終端設(shè)備的UICC平均初始化時間在37.6s左右，以上機制將可節(jié)省至少10s的時間，效率提升26.6%以上。不過需注意的是，第一種和第二種機制不需要對硬件部分做更改與升級，這意味著在顯著提升用戶體驗的同時無須增加終端設(shè)備硬件成本。

參考文獻：

[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）訪問文件的數(shù)量

終端初始化時訪問的文件數(shù)量因終端和UICC的不同組合而異，且每款終端都有特定的UICC文件訪問流程。但訪問的文件數(shù)量依賴于UICC上存在的文件，其數(shù)量在56到114個之間，平均為84個，同時有很多文件被多次讀取，SELECT命令的總數(shù)量在105到327個之間，平均每個文件被選擇了1.7到3.3次，如圖6所示。

（2）頻繁訪問文件FVF（Frequently Visited File）

在測試實驗中，一些特定EF（Elementary File）文件被READ BINARY和READ RECORD重復(fù)執(zhí)行了多次，當讀取EF文件中的記錄（Record）時，其長度可能很短，而READ RECORD命令只能一次讀取一份記錄，因此這些文件會被頻繁訪問并讀取多次，如電話簿、短信和首選網(wǎng)絡(luò)等。

表5列出了通過READ RECORD或READ BINARY命令訪問10次以上的文件。文件名一欄列出了文件路徑和名稱，數(shù)據(jù)長度一欄列出了READ RECORD和READ BINARY命令從該文件中讀取的數(shù)據(jù)長度。

表6列出了FVF的數(shù)量和其占總訪問文件數(shù)的百分比，以及READ RECORD和READ BINARY所訪問的FVF次數(shù)和占所有READ命令的百分比。

總體而言，F(xiàn)VF因終端和UICC的組合而異，且只占總訪問文件的少數(shù)，但對這些FVF的讀取卻占了大量的時間，如圖7所示。

4 總結(jié)

以上對UICC訪問的分析顯示初始化過程中大部分時間消耗在終端和UICC上，顯然改進終端和UICC硬件規(guī)格及軟件實現(xiàn)方式能顯著優(yōu)化初始化過程。不過這和當前可用技術(shù)、軟硬件效率和成本相關(guān)，而這些通常都不在ETSI和其他標準開發(fā)組織的技術(shù)討論范圍內(nèi)。

4.1 數(shù)據(jù)傳輸

因終端均選擇了UICC所支持的最大傳輸速率，當前UICC支持最快223.2kbps。提供更高的基于ISO/IEC 7816接口的波特率或者采用高速USB接口將有助于加速UICC初始化過程。然而即使數(shù)據(jù)傳輸是瞬間完成的，根據(jù)之前的測試結(jié)果，平均節(jié)省的時間也只有2.6s左右。

4.2 APDU命令和文件訪問

從對UICC APDU命令的分析可知，READ BINARY/READ RECORD/SEARCH RECORD這三個命令消耗了8.4s左右，大約占UAT的58%。如果在兩個連續(xù)的初始化過程中終端沒有換卡，則很多文件都沒有改變。如果存在一種檢測EF是否有更新的機制，這些不必要的READ命令將可以有效的避免，也將極大地降低READ/SEARCH命令的數(shù)量和傳輸時間，同時減少總的UAT。

從對訪問文件的分析可知，不同終端和UICC組合將導致讀取的文件也各不相同，然而都存在一些文件被多次讀取。這些頻繁訪問文件包括電話簿、短信和運營商首選網(wǎng)絡(luò)列表。如果用戶選擇在UICC以外存儲電話簿和短信，如手機內(nèi)存，也將有利于減少UICC初始化時間。

4.3 優(yōu)化建議

基于對上述UICC訪問過程的分析，特提出如下優(yōu)化建議：

（1）增加一種可選機制使終端可檢測EF文件是否有更新，該機制能有效減少機卡接口間的數(shù)據(jù)量和APDU命令處理時間，這將節(jié)省約8.4s的時間或者UAT的58%，同時也不會影響到終端用戶的使用習慣和體驗。

（2）擴展SEARCH RECORD命令以減少READ RECORD的使用，SEARCH RECORD通過對整個線性固定（Linear fixed）或循環(huán)（Cyclic）文件的搜索來找出特定模式或內(nèi)容的Record。實際上SEARCH RECORD并未被所有終端廠商高效利用，可能是因為這個命令在實現(xiàn)廠商需求時不夠彈性化，而對該命令的擴展將可以減少對READ RECORD的使用，從而降低APDU命令處理時間和數(shù)據(jù)傳輸時間。

（3）使UICC能提供更高的數(shù)據(jù)傳輸速率以節(jié)省時間，不過此機制節(jié)省的時間相對有限，且會伴隨硬件成本的提升。

當前終端設(shè)備的UICC平均初始化時間在37.6s左右，以上機制將可節(jié)省至少10s的時間，效率提升26.6%以上。不過需注意的是，第一種和第二種機制不需要對硬件部分做更改與升級，這意味著在顯著提升用戶體驗的同時無須增加終端設(shè)備硬件成本。

參考文獻：

[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