周代衛(wèi) 周宇 孫向前
【摘 要】針對移動終端初始化時對UICC訪問過程的優(yōu)化需求,介紹了UICC初始化過程中的分階段分析方法,并分別從時間參數(shù)、APDU命令和訪問文件等四個方面結(jié)合具體實(shí)驗(yàn)數(shù)據(jù)加以整理和分析,最后從數(shù)據(jù)傳輸、APDU命令和訪問文件等方面提出合理的UICC訪問優(yōu)化建議。
【關(guān)鍵詞】UICC 機(jī)卡接口 APDU命令 文件訪問 訪問優(yōu)化
中圖分類號:TN929.5 文獻(xiàn)標(biāo)識碼: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等。其作為通用智能卡平臺,可同時支持一項(xiàng)或多項(xiàng)業(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è)備的使用體驗(yàn)有了更高的要求,特別是開機(jī)速度、短信和聯(lián)系人存貯容量與讀取速度等方面。而多模多卡智能終端的廣泛使用,以及日益復(fù)雜的UICC業(yè)務(wù)功能和逐步提高的卡片容量等因素都對終端設(shè)備初始化時的用戶體驗(yàn)帶來了一定的影響。因此,根據(jù)UICC相關(guān)技術(shù)規(guī)范和功能特點(diǎn),結(jié)合實(shí)際對比測試數(shù)據(jù),對影響用戶體驗(yàn)的各因素做詳細(xì)的比較和分析,并提出對UICC初始化的優(yōu)化建議顯得尤為必要,特別是從UICC的應(yīng)用層面做訪問優(yōu)化。
2 分析方法
2.1 分析背景
當(dāng)前移動終端和UICC支持的應(yīng)用和業(yè)務(wù)越來越豐富和復(fù)雜,用戶在開機(jī)初始化時需等待的時間也越來越長,這無疑對用戶體驗(yàn)帶來了負(fù)面影響。而縱觀整個初始化過程,UICC的初始化訪問成為耗時的重要因素之一。
終端設(shè)備在初始化時與UICC相關(guān)的操作通常包含如下三方面:
(1)終端設(shè)備的操作:包含終端軟件初始化,終端發(fā)送給UICC的APDU(Application Protocol Data Unit)命令的準(zhǔn)備和處理,以及移動網(wǎng)絡(luò)的注冊登記。
(2)UICC和終端設(shè)備機(jī)卡接口的操作:包括機(jī)卡接口上的數(shù)據(jù)傳輸,該接口須符合ETSI TS 102 221或TS 102 600的要求。
(3)UICC的操作:包括UICC軟件初始化和對APDU命令的處理。
通常耗費(fèi)在第一項(xiàng)和第三項(xiàng)上的時間受諸多因素的影響,如:終端設(shè)備和UICC的硬件規(guī)格,終端提供給UICC的電壓、電流和時鐘信號頻率,終端的讀卡策略與先后順序,搜索和注冊網(wǎng)絡(luò)的快慢,以及終端和UICC各自操作系統(tǒng)的軟件架構(gòu)和執(zhí)行效率等。對于第二項(xiàng),由于需遵循標(biāo)準(zhǔn)的技術(shù)規(guī)范且受外部影響較小,因此將成為本文的討論重點(diǎn)。
為進(jìn)一步明晰UICC開機(jī)初始化時的優(yōu)化方向,首先需理清在UICC訪問過程中進(jìn)行了何種操作,讀取了哪些文件以及相應(yīng)耗費(fèi)的時間。然而無法將市面上所有終端設(shè)備和各種類型的UICC逐一做對比實(shí)驗(yàn)和數(shù)據(jù)分析,比較適用的方法是隨機(jī)選取幾款較為典型的終端和普遍使用的UICC作為樣本加以分析。
2.2 實(shí)驗(yàn)方法
針對上述分析背景中的介紹,對比實(shí)驗(yàn)可以分為如下三個階段:
階段一:使用抓包工具抓取開機(jī)初始化時卡接口上所有通信數(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)階段一
階段一是為了獲取機(jī)卡接口上完整數(shù)據(jù)流,具體實(shí)驗(yàn)步驟如下:
1)將抓包工具連接上終端設(shè)備和UICC,并準(zhǔn)備抓取數(shù)據(jù);
2)終端設(shè)備開機(jī)直至初始化完成;
3)停止抓包并將抓取的數(shù)據(jù)保存成Log文件;
4)整理并分析抓取的Log文件中APDU的數(shù)量、字節(jié)數(shù)和訪問文件等;
5)重復(fù)步驟1~4,并取五次平均值。
(2)階段二
階段二是為了排除初始化時終端設(shè)備自身的處理時間而集中于卡接口,步驟如下:
1)將插入U(xiǎn)ICC的讀卡器連上PC端;
2)使用并過濾階段一中抓取的Log創(chuàng)建APDU Database;
3)將Database中的APDU以UICC支持的最快速率發(fā)送給UICC,并測量各APDU所耗費(fèi)的時間以及總共消耗的時間;
4)記錄并分析測量的數(shù)據(jù)結(jié)果。
(3)階段三
階段三是為了驗(yàn)證在選用最佳操作參數(shù)后可節(jié)省的時間。如果階段二中PC已經(jīng)選用了最大波特率,則階段三可跳過。
3 UICC訪問分析
按照上一章的實(shí)驗(yàn)分析方法,本章將基于實(shí)際測試數(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訪問時間分析
按照第二章的實(shí)驗(yàn)方法,從Log中ATR TA1和PPS1的參數(shù)來看,所有的終端都支持并使用ISO/IEC 7816機(jī)卡接口,且能正確選擇UICC所支持的最快速率傳輸數(shù)據(jù),因此階段三的測試可以省略。
(1)數(shù)據(jù)傳輸時間DTT
在ISO/IEC 7816接口上,每一個APDU Byte均被添加上一個起始位(start bit),一個校驗(yàn)位(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,主要是因?yàn)榭?和卡4支持的最大波特率為223.2kbps,而卡2和卡3只有111.6kbps,因此卡1和卡4的平均DTT約為1.6s,而卡2和卡3約為3.6s。
(2)UICC處理時間UPT
UPT受多重因素的影響,如:UICC硬件規(guī)格、軟件性能、收到的APDU命令、機(jī)卡接口電流特性和時鐘頻率等,而其硬件結(jié)構(gòu)和軟件實(shí)現(xiàn)將不在本文的討論范圍內(nèi)。
UPT的測量結(jié)果是由UAT減去DTT得出,集中在1.7s到29.2s間,平均為12.0s,占UAT的82.2%。
(3)終端處理時間TPT
TPT也受多重因素的影響,如:終端硬件規(guī)格、軟件性能、發(fā)送的APDU命令和終端正在運(yùn)行的其他業(yè)務(wù)活動等,而其軟硬件性能和其他業(yè)務(wù)活動將不在本文的討論范圍內(nèi),而終端發(fā)送的APDU命令將是本文的討論重點(diǎn),其總量的減少將導(dǎo)致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為機(jī)卡接口上從收到第一個APDU到空閑態(tài)下最后一個APDU間的時間間隔,并無精準(zhǔn)的界定方法,不過可采取逐步逼近的方法來測量。
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)容、終端的實(shí)現(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)
在測試實(shí)驗(yàn)中,一些特定EF(Elementary File)文件被READ BINARY和READ RECORD重復(fù)執(zhí)行了多次,當(dāng)讀取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上,顯然改進(jìn)終端和UICC硬件規(guī)格及軟件實(shí)現(xiàn)方式能顯著優(yōu)化初始化過程。不過這和當(dāng)前可用技術(shù)、軟硬件效率和成本相關(guān),而這些通常都不在ETSI和其他標(biāo)準(zhǔn)開發(fā)組織的技術(shù)討論范圍內(nèi)。
4.1 數(shù)據(jù)傳輸
因終端均選擇了UICC所支持的最大傳輸速率,當(dāng)前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是否有更新的機(jī)制,這些不必要的READ命令將可以有效的避免,也將極大地降低READ/SEARCH命令的數(shù)量和傳輸時間,同時減少總的UAT。
從對訪問文件的分析可知,不同終端和UICC組合將導(dǎo)致讀取的文件也各不相同,然而都存在一些文件被多次讀取。這些頻繁訪問文件包括電話簿、短信和運(yùn)營商首選網(wǎng)絡(luò)列表。如果用戶選擇在UICC以外存儲電話簿和短信,如手機(jī)內(nèi)存,也將有利于減少UICC初始化時間。
4.3 優(yōu)化建議
基于對上述UICC訪問過程的分析,特提出如下優(yōu)化建議:
(1)增加一種可選機(jī)制使終端可檢測EF文件是否有更新,該機(jī)制能有效減少機(jī)卡接口間的數(shù)據(jù)量和APDU命令處理時間,這將節(jié)省約8.4s的時間或者UAT的58%,同時也不會影響到終端用戶的使用習(xí)慣和體驗(yàn)。
(2)擴(kuò)展SEARCH RECORD命令以減少READ RECORD的使用,SEARCH RECORD通過對整個線性固定(Linear fixed)或循環(huán)(Cyclic)文件的搜索來找出特定模式或內(nèi)容的Record。實(shí)際上SEARCH RECORD并未被所有終端廠商高效利用,可能是因?yàn)檫@個命令在實(shí)現(xiàn)廠商需求時不夠彈性化,而對該命令的擴(kuò)展將可以減少對READ RECORD的使用,從而降低APDU命令處理時間和數(shù)據(jù)傳輸時間。
(3)使UICC能提供更高的數(shù)據(jù)傳輸速率以節(jié)省時間,不過此機(jī)制節(jié)省的時間相對有限,且會伴隨硬件成本的提升。
當(dāng)前終端設(shè)備的UICC平均初始化時間在37.6s左右,以上機(jī)制將可節(jié)省至少10s的時間,效率提升26.6%以上。不過需注意的是,第一種和第二種機(jī)制不需要對硬件部分做更改與升級,這意味著在顯著提升用戶體驗(yàn)的同時無須增加終端設(shè)備硬件成本。
參考文獻(xiàn):
[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)
在測試實(shí)驗(yàn)中,一些特定EF(Elementary File)文件被READ BINARY和READ RECORD重復(fù)執(zhí)行了多次,當(dāng)讀取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上,顯然改進(jìn)終端和UICC硬件規(guī)格及軟件實(shí)現(xiàn)方式能顯著優(yōu)化初始化過程。不過這和當(dāng)前可用技術(shù)、軟硬件效率和成本相關(guān),而這些通常都不在ETSI和其他標(biāo)準(zhǔn)開發(fā)組織的技術(shù)討論范圍內(nèi)。
4.1 數(shù)據(jù)傳輸
因終端均選擇了UICC所支持的最大傳輸速率,當(dāng)前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是否有更新的機(jī)制,這些不必要的READ命令將可以有效的避免,也將極大地降低READ/SEARCH命令的數(shù)量和傳輸時間,同時減少總的UAT。
從對訪問文件的分析可知,不同終端和UICC組合將導(dǎo)致讀取的文件也各不相同,然而都存在一些文件被多次讀取。這些頻繁訪問文件包括電話簿、短信和運(yùn)營商首選網(wǎng)絡(luò)列表。如果用戶選擇在UICC以外存儲電話簿和短信,如手機(jī)內(nèi)存,也將有利于減少UICC初始化時間。
4.3 優(yōu)化建議
基于對上述UICC訪問過程的分析,特提出如下優(yōu)化建議:
(1)增加一種可選機(jī)制使終端可檢測EF文件是否有更新,該機(jī)制能有效減少機(jī)卡接口間的數(shù)據(jù)量和APDU命令處理時間,這將節(jié)省約8.4s的時間或者UAT的58%,同時也不會影響到終端用戶的使用習(xí)慣和體驗(yàn)。
(2)擴(kuò)展SEARCH RECORD命令以減少READ RECORD的使用,SEARCH RECORD通過對整個線性固定(Linear fixed)或循環(huán)(Cyclic)文件的搜索來找出特定模式或內(nèi)容的Record。實(shí)際上SEARCH RECORD并未被所有終端廠商高效利用,可能是因?yàn)檫@個命令在實(shí)現(xiàn)廠商需求時不夠彈性化,而對該命令的擴(kuò)展將可以減少對READ RECORD的使用,從而降低APDU命令處理時間和數(shù)據(jù)傳輸時間。
(3)使UICC能提供更高的數(shù)據(jù)傳輸速率以節(jié)省時間,不過此機(jī)制節(jié)省的時間相對有限,且會伴隨硬件成本的提升。
當(dāng)前終端設(shè)備的UICC平均初始化時間在37.6s左右,以上機(jī)制將可節(jié)省至少10s的時間,效率提升26.6%以上。不過需注意的是,第一種和第二種機(jī)制不需要對硬件部分做更改與升級,這意味著在顯著提升用戶體驗(yàn)的同時無須增加終端設(shè)備硬件成本。
參考文獻(xiàn):
[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)
在測試實(shí)驗(yàn)中,一些特定EF(Elementary File)文件被READ BINARY和READ RECORD重復(fù)執(zhí)行了多次,當(dāng)讀取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上,顯然改進(jìn)終端和UICC硬件規(guī)格及軟件實(shí)現(xiàn)方式能顯著優(yōu)化初始化過程。不過這和當(dāng)前可用技術(shù)、軟硬件效率和成本相關(guān),而這些通常都不在ETSI和其他標(biāo)準(zhǔn)開發(fā)組織的技術(shù)討論范圍內(nèi)。
4.1 數(shù)據(jù)傳輸
因終端均選擇了UICC所支持的最大傳輸速率,當(dāng)前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是否有更新的機(jī)制,這些不必要的READ命令將可以有效的避免,也將極大地降低READ/SEARCH命令的數(shù)量和傳輸時間,同時減少總的UAT。
從對訪問文件的分析可知,不同終端和UICC組合將導(dǎo)致讀取的文件也各不相同,然而都存在一些文件被多次讀取。這些頻繁訪問文件包括電話簿、短信和運(yùn)營商首選網(wǎng)絡(luò)列表。如果用戶選擇在UICC以外存儲電話簿和短信,如手機(jī)內(nèi)存,也將有利于減少UICC初始化時間。
4.3 優(yōu)化建議
基于對上述UICC訪問過程的分析,特提出如下優(yōu)化建議:
(1)增加一種可選機(jī)制使終端可檢測EF文件是否有更新,該機(jī)制能有效減少機(jī)卡接口間的數(shù)據(jù)量和APDU命令處理時間,這將節(jié)省約8.4s的時間或者UAT的58%,同時也不會影響到終端用戶的使用習(xí)慣和體驗(yàn)。
(2)擴(kuò)展SEARCH RECORD命令以減少READ RECORD的使用,SEARCH RECORD通過對整個線性固定(Linear fixed)或循環(huán)(Cyclic)文件的搜索來找出特定模式或內(nèi)容的Record。實(shí)際上SEARCH RECORD并未被所有終端廠商高效利用,可能是因?yàn)檫@個命令在實(shí)現(xiàn)廠商需求時不夠彈性化,而對該命令的擴(kuò)展將可以減少對READ RECORD的使用,從而降低APDU命令處理時間和數(shù)據(jù)傳輸時間。
(3)使UICC能提供更高的數(shù)據(jù)傳輸速率以節(jié)省時間,不過此機(jī)制節(jié)省的時間相對有限,且會伴隨硬件成本的提升。
當(dāng)前終端設(shè)備的UICC平均初始化時間在37.6s左右,以上機(jī)制將可節(jié)省至少10s的時間,效率提升26.6%以上。不過需注意的是,第一種和第二種機(jī)制不需要對硬件部分做更改與升級,這意味著在顯著提升用戶體驗(yàn)的同時無須增加終端設(shè)備硬件成本。
參考文獻(xiàn):
[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