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