VoWi-Fi技術(shù)的實現(xiàn)原理與架構(gòu)分析

曹 磊，王 波，邵 震，沈 驍，李一明

（1.中國電信集團公司 北京 100033；2.中國電信股份有限公司上海研究院 上海 200122）

1 引言

很長一段時間以來，隨著移動互聯(lián)網(wǎng)業(yè)務(wù)的高速發(fā)展，電信運營商始終專注于網(wǎng)絡(luò)功能的增強和性能的升級，以應(yīng)對呈爆發(fā)式增長的數(shù)據(jù)業(yè)務(wù)，而對于語音業(yè)務(wù)則甚少關(guān)注，但隨著LTE網(wǎng)絡(luò)的規(guī)模發(fā)展，VoLTE技術(shù)已經(jīng)成為移動通信業(yè)的熱點。

2014年蘋果推出iOS 8.0操作系統(tǒng)中的Wi-Fi calling（Wi-Fi呼叫）技術(shù)，支持基于3GPP S2b方案[1]的VoWi-Fi，T-Mobile、EE等多家運營商同步提供了相應(yīng)的VoWi-Fi商用產(chǎn)品，同時對Wi-Fi calling技術(shù)在終端產(chǎn)業(yè)鏈上的支持力度也得到了大幅提升，更多的如三星、HTC等Andriod終端也陸續(xù)開始支持3GPP S2b方案。

對于電信運營商而言，VoWi-Fi技術(shù)可以利用近幾年已在室內(nèi)大量建設(shè)的Wi-Fi網(wǎng)絡(luò)，彌補蜂窩網(wǎng)室外基站對室內(nèi)的覆蓋不夠而使得用戶接收信號較差的不足，在提高資源利用率的同時有效提升語音業(yè)務(wù)的用戶滿意度。對用戶而言，使用VoWi-Fi業(yè)務(wù)可以在基本不改變業(yè)務(wù)使用習(xí)慣的基礎(chǔ)上，在更多的區(qū)域內(nèi)使用語音業(yè)務(wù)，從而降低國際漫游費用的支出。

本文將主要介紹基于3GPP S2b方案的VoWi-Fi技術(shù)的實現(xiàn)及關(guān)鍵問題的分析，并簡單介紹了其他VoWi-Fi實現(xiàn)方案，最后提出了對電信級VoWi-Fi運營的建議。

2 基于3GPP S2b方案的VoWi-Fi組網(wǎng)架構(gòu)

圖1是基于3GPP S2b方案的VoWi-Fi與VoLTE組網(wǎng)架構(gòu)，其中虛線部分為VoWi-Fi涉及的接口，實線部分為VoLTE涉及的接口，PGW作為跨網(wǎng)絡(luò)切換的錨點。

3GPP在引入演進的分組核心網(wǎng)（EPC）之初就將非3GPP網(wǎng)絡(luò)接入作為目標(biāo)架構(gòu)的一部分，Wi-Fi接入3GPP EPC架構(gòu)可以分為S2a、S2b和S2c 3種場景[1]。

·S2a方案是基于授信Wi-Fi網(wǎng)絡(luò)與EPC互通，采用GTP/PMIP的S2a接口（授信非3GPP網(wǎng)絡(luò)與PGW之間）。這種方案中Wi-Fi網(wǎng)絡(luò)通過運營商城域網(wǎng)與移動網(wǎng)絡(luò)的PGW相連，因此需要對城域網(wǎng)的網(wǎng)關(guān)設(shè)備BRAS進行改造，以支持移動性的要求。

·S2b方案是應(yīng)用于非授信Wi-Fi網(wǎng)絡(luò)，Wi-Fi網(wǎng)絡(luò)基于ePDG設(shè)備接入EPC網(wǎng)絡(luò)。S2b方案要求終端和ePDG之間建立IPSec隧道，因此需要終端支持IPSec。

·S2c方案是一種基于終端的Wi-Fi網(wǎng)絡(luò)與EPC互通解決方案，UE和PGW之間通過DSMIP隧道連接，這樣UE和EPC網(wǎng)絡(luò)交互的數(shù)據(jù)可以在固網(wǎng)與城域網(wǎng)之間實現(xiàn)透傳，這種方案要求終端支持DSMIPv6。

在S2b方案中，網(wǎng)絡(luò)側(cè)通過新增ePDG網(wǎng)元來實現(xiàn)業(yè)務(wù)從Wi-Fi網(wǎng)絡(luò)接入EPC，ePDG網(wǎng)元部署在公網(wǎng)上（也可以部署在內(nèi)網(wǎng)中）。終端和ePDG之間使用SWu接口，該接口通過IKEv2[2]消息傳遞用戶認(rèn)證信息，在認(rèn)證通過后在終端和ePDG間建立IPSec隧道[3]來承載用戶的Wi-Fi數(shù)據(jù)流；ePDG與3GPP AAA服務(wù)器間使用SWm接口，此接口通過Diameter消息傳遞用戶認(rèn)證信息；ePDG與PGW之間則使用S2b接口，此接口使用GTP/PMIP建立Wi-Fi UE與PGW的會話（session）。3GPP S2b方案中的語音流最終從EPC網(wǎng)絡(luò)通過PGW進入IMS核心網(wǎng)，實現(xiàn)與運營商所提供的VoLTE業(yè)務(wù)相同的管控。

S2b方案支持Wi-Fi UE從其他運營商或私有的非授信Wi-Fi網(wǎng)絡(luò)接入移動運營商的EPC網(wǎng)絡(luò)中，因此要求終端支持建立IPSec隧道。由于IPSec的額外開銷較大，對終端功耗有很大的影響，直至Wi-Fi calling的出現(xiàn)才使得此方案有了用武之地。目前在Wi-Fi calling技術(shù)中S2b方案僅承載Wi-Fi語音流，對數(shù)據(jù)流（上網(wǎng)業(yè)務(wù)等）不進行統(tǒng)一控制，即IPSec隧道僅封裝語音流，這樣能降低對終端處理能力的要求，也能節(jié)省終端的功耗。

3 基于3GPP S2b的VoWi-Fi方案的關(guān)鍵問題

3.1 用戶認(rèn)證

要使用VoWi-Fi業(yè)務(wù)，用戶需進行3個步驟的認(rèn)證注冊過程。

第1步，在Wi-Fi網(wǎng)絡(luò)注冊。用戶首先需要在Wi-Fi網(wǎng)絡(luò)進行接入認(rèn)證，確定能成功登入Internet，這一認(rèn)證方式及流程由該Wi-Fi網(wǎng)絡(luò)自行決定。該Wi-Fi網(wǎng)絡(luò)可以是用戶歸屬運營商的Wi-Fi網(wǎng)絡(luò)，也可以是用戶家庭、商家或其他電信運營商的Wi-Fi網(wǎng)絡(luò)。Wi-Fi的加密方式由該Wi-Fi網(wǎng)絡(luò)自行定義，可以是不加密的，也可以是加密的。EPC網(wǎng)絡(luò)注冊流程如圖2所示。

第2步，在EPC網(wǎng)絡(luò)注冊。用戶在Wi-Fi網(wǎng)絡(luò)通過認(rèn)證登入Internet后，需要繼續(xù)在EPC網(wǎng)絡(luò)進行接入認(rèn)證。該認(rèn)證過程由終端觸發(fā)，例如在蘋果iOS操作系統(tǒng)中，當(dāng)用戶打開“Wi-Fi calling”使能開關(guān)時，終端會使用DNS方式發(fā)現(xiàn)ePDG網(wǎng)元，并通過ePDG和3GPP AAA網(wǎng)元在EPC網(wǎng)絡(luò)進行注冊。測試結(jié)果顯示，此步驟（從第一條IKE_SA_init消息到最后一條IKE auth answer消息）耗時在1 s左右。EPC網(wǎng)絡(luò)注冊流程如圖2所示。

圖1 基于3GPP S2b方案的VoWi-Fi與VoLTE組網(wǎng)架構(gòu)

第3步，在IMS網(wǎng)絡(luò)注冊。用戶在EPC網(wǎng)絡(luò)注冊成功后，將繼續(xù)在IMS核心網(wǎng)進行注冊。這一過程在EPC網(wǎng)絡(luò)注冊成功后自動觸發(fā)。只有在IMS注冊成功后，用戶才可以正常使用VoWi-Fi的主/被叫業(yè)務(wù)和發(fā)送/接收短信業(yè)務(wù)。

3個步驟的認(rèn)證過程如圖3所示。

上述3個認(rèn)證過程中，第2個步驟即用戶在EPC網(wǎng)絡(luò)的注冊是S2b方案的關(guān)鍵，3GPP定義在這一過程中使用基于USIM卡的EAP-AKA[4]認(rèn)證算法，在認(rèn)證過程中EAP-AKA認(rèn)證算法封裝在IKEv2消息中。

3.2 語音流的安全傳輸

由于S2b針對的是非授信的Wi-Fi網(wǎng)絡(luò)，因此必須保障用戶語音業(yè)務(wù)的安全性。S2b方案在終端與ePDG間建立加密的IPSec隧道，ePDG與PGW間建立GTP/PMIP隧道，這樣用戶數(shù)據(jù)全程都封裝在隧道中，終端與ePDG間的IPSec隧道解決了ePDG網(wǎng)元以下段在非授信網(wǎng)絡(luò)中的業(yè)務(wù)安全性問題，ePDG與PGW間則采用與EPC網(wǎng)絡(luò)相同的安全機制，這樣可以有效實現(xiàn)語音流的端到端安全傳輸。語音流的傳輸示意如圖4所示。

3.3 VoWi-Fi與VoLTE的無縫切換

在S2b方案中，語音流通過Wi-Fi網(wǎng)絡(luò)接入PGW后，以PGW作為錨點，可以實現(xiàn)LTE網(wǎng)絡(luò)和Wi-Fi網(wǎng)絡(luò)間的無縫切換，確保了跨網(wǎng)絡(luò)切換時語音業(yè)務(wù)的連續(xù)性。用戶語音數(shù)據(jù)的切換如圖5所示。

無論是從VoWi-Fi切換到VoLTE，還是從VoLTE切換到VoWi-Fi，都是先在目標(biāo)網(wǎng)絡(luò)建立新的連接，之后將業(yè)務(wù)承載到新的連接上，再拆除源網(wǎng)絡(luò)上的連接。在這一過程中，由于錨點PGW的存在，無論用戶在Wi-Fi網(wǎng)絡(luò)上附著還是在LTE網(wǎng)絡(luò)上附著，用戶的IP地址均由PGW分配，因此在切換過程中，用戶發(fā)起目標(biāo)網(wǎng)絡(luò)的連接建立請求時，只需在GTPv2消息（若采用S2b GTP）中攜帶在源網(wǎng)絡(luò)獲取的IP地址，PGW就可識別該連接建立請求是一個切換過程的連接建立而不是一個新建連接的建立，這樣PGW只需在目標(biāo)網(wǎng)絡(luò)上將原IP地址分配給終端，即可保證用戶的IP地址不變，從而實現(xiàn)了業(yè)務(wù)的連續(xù)性。當(dāng)從VoWi-Fi切換到VoLTE時，終端在LTE網(wǎng)絡(luò)下可以發(fā)送“Handover”指示，此時EPC網(wǎng)絡(luò)可依照跨eNode B切換流程進行處理，但當(dāng)VoLTE切換到VoWi-Fi時，終端在Wi-Fi網(wǎng)絡(luò)下無法發(fā)送“Handover”指示（3GPP標(biāo)準(zhǔn)不作定義要求），此時則通過終端上報在LTE網(wǎng)絡(luò)獲取的IP地址，由ePDG發(fā)起“Handover”指示來實現(xiàn)，如圖6所示。

圖2 EPC網(wǎng)絡(luò)注冊流程

圖3 基于S2b的VoWi-Fi的認(rèn)證注冊過程

圖4 VoWi-Fi語音流的傳輸示意

圖5 用戶語音數(shù)據(jù)切換示意

切換測試中分別定義了用戶面和信令面兩種切換時延（以VoLTE切換到VoWi-Fi為例）。

（1）用戶面

用戶面切換時延是監(jiān)測PGW的GTP接口，以在LTE側(cè)最后一個報文以及Wi-Fi側(cè)第一個報文之間的時間差。統(tǒng)計的抓取分組示意如圖7所示，虛線框內(nèi)為LTE側(cè)的最后一個報文，實線框內(nèi)為Wi-Fi側(cè)的第一個報文，用戶面切換時延可以反映出用戶對業(yè)務(wù)發(fā)生切換的真實感受。

（2）信令面

信令面切換時延則是監(jiān)測ePDG側(cè)的信令，統(tǒng)計ePDG從初始切換的第一條IKE_SA消息到最后一條專有承載建立完成的create bearer response消息之間的時間差。如圖8所示，虛線框內(nèi)為IKE_SA_init消息，實線框內(nèi)為create bearer response消息，信令面切換時延是便于網(wǎng)絡(luò)側(cè)對網(wǎng)內(nèi)用戶的切換情況進行統(tǒng)計，由于在信令面的切換完成前，用戶的接入網(wǎng)并未切換，因此業(yè)務(wù)也不會中斷。

從目前實驗室測試結(jié)果看，在無線環(huán)境良好的情況下，VoWi-Fi與VoLTE間的切換時延是百毫秒級的，用戶幾乎無感知。目前信令切換時延稍長，但對切換時通話質(zhì)量無任何影響。在切換過程中，當(dāng)專用承載未能建立起來時，語音流可臨時走缺省承載，當(dāng)專用承載建立后，語音流再切換至專有承載。具體測試結(jié)果見表1。

3.4 VoWi-Fi的語音編碼

VoWi-Fi的語音編碼方案完全參照VoLTE，編碼格式和速率在UE與IMS平臺協(xié)商后確認(rèn)，在圖9中的測試編碼格式為AMR-WB，編碼速率為12.65 kbit/s。

4 其他的VoWi-Fi實現(xiàn)方案

除了基于3GPP S2b的VoWi-Fi方案外，目前業(yè)界還有其他幾種VoWi-Fi實現(xiàn)方式。

圖6 VoLTE無縫切換到VoWi-Fi的實現(xiàn)

圖7 抓取分組示意

圖8 抓取分組示意

表1 VoWi-Fi與VoLTE的無縫切換時延測試結(jié)果

圖9 VoWi-Fi的語音編碼協(xié)商

4.1 普通App的OTT方式

有代表性的包括微信電話、Skype等，其主要通過在終端上安裝App客戶端軟件的方式實現(xiàn)基本的VoIP，其存在的主要問題有各種通話軟件與現(xiàn)有電信網(wǎng)絡(luò)以及通話軟件間均難以互通；實時被叫需要App客戶端軟件時刻開啟，這樣也就難以保障語音的隨時可達；一般無法實現(xiàn)Wi-Fi網(wǎng)絡(luò)與移動蜂窩網(wǎng)的切換等。雖然，類似易信電話的應(yīng)用能通過在運營商網(wǎng)絡(luò)中部署IP電話網(wǎng)關(guān)來增強實現(xiàn)App客戶端到現(xiàn)有電信網(wǎng)絡(luò)號碼的主叫能力，但始終無法實現(xiàn)App客戶端的被叫功能。OTT方式的VoWi-Fi實現(xiàn)組網(wǎng)如圖10所示。

4.2 App+信令網(wǎng)關(guān)方式

有代表性的如Wi-Fi-phone等，這種方式是運營商定制的VoWi-Fi方案，其除了在終端上安裝客戶端軟件外，還需在運營商網(wǎng)絡(luò)內(nèi)部署Wi-Fi-phone平臺，并利用信令網(wǎng)關(guān)實現(xiàn)與HLR互通，由此將Wi-Fi網(wǎng)絡(luò)視為移動蜂窩網(wǎng)中的一個普通基站，從而完成用戶在移動核心網(wǎng)中的位置注冊、IMS的注冊及呼叫信令接續(xù)。與普通App的OTT方式相比，這種方式可以通過App語音平臺來實現(xiàn)原有的運營商分配的號碼與App ID的綁定，從而完成用戶的主/被叫接續(xù)，但與3GPP S2b方案相比，其作為一種App的拓展，使用時仍然要求App客戶端軟件時刻開啟，并且無法實現(xiàn)Wi-Fi網(wǎng)絡(luò)與移動蜂窩網(wǎng)的切換，同時對移動核心網(wǎng)有新增網(wǎng)元的改造要求。App+信令網(wǎng)關(guān)方式的VoWi-Fi實現(xiàn)組網(wǎng)如圖11所示。

App+信令網(wǎng)關(guān)方式中的IMS網(wǎng)絡(luò)注冊過程為：App客戶端通過Wi-Fi進入Internet并連接到Wi-Fi-phone平臺，由Wi-Fi-phone平臺完成客戶端的鑒權(quán)后，向IMS發(fā)起標(biāo)準(zhǔn)注冊過程。

圖10 OTT方式的VoWi-Fi實現(xiàn)方案

圖11 App+信令網(wǎng)關(guān)方式的VoWi-Fi實現(xiàn)方案

主叫處理過程：由App客戶端發(fā)起的呼叫通過Wi-Fi與Internet發(fā)送到Wi-Fi-phone平臺中的信令網(wǎng)關(guān)，由信令網(wǎng)關(guān)解密后發(fā)送至IMS；呼叫到達IMS后由IMS負(fù)責(zé)處理將呼叫路由到MSC完成后續(xù)呼叫。

被叫處理過程：App客戶端在Wi-Fi-phone平臺完成鑒權(quán)后，平臺會通知HLR進行用戶位置的注冊，當(dāng)前用戶的位置就是處于Wi-Fi-phone平臺覆蓋區(qū)域，平臺需分配被叫路由的TLDN（temporary local directory number，臨時本地號碼）號段。主叫MSC根據(jù)TLDN分析，選GWC（gateway controller，網(wǎng)關(guān)控制器）方向進行路由；GWC基于TLDN的分析選定IMS方向，GWC與IMS間走信令鏈路途經(jīng)Wi-Fi-phone平臺，由平臺完成該TLDN與原手機號碼變換，IMS收到的被叫號已變?yōu)樵撟缘氖謾C號，最終由IMS完成呼叫接續(xù)。

4.2 Google推出的Project Fi業(yè)務(wù)

近期Goole推出了Project Fi業(yè)務(wù)，該業(yè)務(wù)除實現(xiàn)VoWi-Fi外，還可通過與T-Mobile、Sprint合作，實現(xiàn)與這兩個運營商的移動蜂窩網(wǎng)之間的語音切換，目前僅有一款終端（NeXus 6）支持該業(yè)務(wù)。目前Google尚未公布其具體的實現(xiàn)方案，據(jù)新聞報道中提及T-Mobile US CEO透露“Project Fi實現(xiàn)LTE與Wi-Fi的無縫切換不是使用Wi-Fi calling技術(shù)”[5]。由于現(xiàn)階段信息公開的局限，后續(xù)將進一步對Project Fi的實現(xiàn)機制進行研究分析。

5 VoWi-Fi發(fā)展建議

近階段VoWi-Fi能成為業(yè)界聚焦的熱點，主要在于其能形成對VoLTE的有效補充，運營商可以利用數(shù)量龐大的Wi-Fi公共熱點和家庭Wi-Fi覆蓋的資源優(yōu)勢解決VoLTE業(yè)務(wù)覆蓋不連續(xù)性的問題，VoWi-Fi將與VoLTE同步融合并一起作為基礎(chǔ)的語音業(yè)務(wù)能力提供給用戶。因此，VoWi-Fi從提供業(yè)務(wù)的能力上來說，需要繼承現(xiàn)有電路域語音業(yè)務(wù)的基本業(yè)務(wù)及補充業(yè)務(wù)能力；而從用戶使用習(xí)慣上來說，也需要延續(xù)現(xiàn)有的操作體驗，應(yīng)與VoLTE的操作體驗保持統(tǒng)一性。

目前國內(nèi)通信市場仍處于LTE的牌照發(fā)放后的網(wǎng)絡(luò)建設(shè)初期，LTE網(wǎng)絡(luò)使用高頻段進行部署，短期內(nèi)無法達到900 MHz GSM或者800 MHz CDMA網(wǎng)絡(luò)的覆蓋水平。加之運營商對于高層住宅樓宇中移動語音業(yè)務(wù)的覆蓋與質(zhì)量問題，始終沒有找到好的技術(shù)手段加以應(yīng)對，這也給VoWi-Fi帶來一個較好的發(fā)展時機，部署時應(yīng)重點考慮以下幾方面的問題。

（1）技術(shù)方案的選擇

基于3GPP S2b方案的VoWi-Fi技術(shù)方案與前文所述幾種技術(shù)方案相比，最大的區(qū)別在于將語音業(yè)務(wù)完整地接入運營商的EPC與IMS網(wǎng)絡(luò)中，從而可以在移動分組域中實現(xiàn)對Wi-Fi語音業(yè)務(wù)的管理與控制。同時能實現(xiàn)與電信網(wǎng)絡(luò)號碼的互通以及與LTE網(wǎng)絡(luò)間語音業(yè)務(wù)的無縫切換，Wi-Fi calling以此作為VoLTE業(yè)務(wù)的強力補充，能有效解決LTE網(wǎng)絡(luò)覆蓋不足所帶來的VoLTE業(yè)務(wù)不連續(xù)性的問題。除此以外，Wi-Fi calling這項功能內(nèi)置于終端中，用戶無需下載安裝App，其撥打/接聽電話和收發(fā)短信等操作也與現(xiàn)有電路域語音業(yè)務(wù)及運營商提供的VoLTE業(yè)務(wù)所要求的操作完全一致，這樣的使用方式保證了用戶的體驗，更易于接受。

（2）對現(xiàn)有網(wǎng)絡(luò)的改造

由于基于3GPP S2b方案本身是針對非授信的Wi-Fi網(wǎng)絡(luò)，因此對運營商的Wi-Fi網(wǎng)絡(luò)無特殊改造要求，而對于移動網(wǎng)絡(luò)，需要在EPC中新增ePDG網(wǎng)元作為Wi-Fi側(cè)接入網(wǎng)關(guān)，新增或升級3GPP AAA網(wǎng)元支持對用戶的EAP-AKA認(rèn)證算法。

（3）對關(guān)鍵網(wǎng)元ePDG的功能和部署要求

ePDG設(shè)備作為S2b方案的關(guān)鍵網(wǎng)元，需要具備以下主要功能。

·支持將用戶側(cè)IKEv2認(rèn)證消息轉(zhuǎn)換為EPC要求的Diameter消息，發(fā)送到3GPP AAA服務(wù)器進行用戶認(rèn)證。

·支持與用戶建立IPSec隧道，將用戶語音流封裝于其中。

·支持與PGW建立GTP/PMIP隧道，將用戶語音流封裝于其中，建議采用S2b GTP。

·由于ePDG網(wǎng)元暴露在公網(wǎng)上，需要考慮對網(wǎng)元實施安全性保護。

·有別于國外運營商的集中部署方式，在國內(nèi)分省部署時需要解決省際漫游的問題。

·加快融合VoWi-Fi功能的VoLTE終端研制。

基于3GPP S2b方案的VoWi-Fi更依賴于終端的生態(tài)系統(tǒng)支持，目前在歐美地區(qū)獲得了蘋果的iOS終端和三星、HTC等Andriod終端的支持，終端產(chǎn)業(yè)鏈已經(jīng)初具規(guī)模，因此需要制定相關(guān)行業(yè)或企業(yè)的終端規(guī)范來推進國內(nèi)主流終端廠商迅速開展融合VoWi-Fi功能的VoLTE終端的研制。同時，針對IPSec隧道的耗電性能、語音業(yè)務(wù)的LTE優(yōu)先功能等技術(shù)細(xì)節(jié)進行探討與功能完善，提前做好商用終端的準(zhǔn)備。

（4）VoWi-Fi業(yè)務(wù)質(zhì)量

通常Wi-Fi網(wǎng)絡(luò)是以承載數(shù)據(jù)上網(wǎng)業(yè)務(wù)為主，其QoS保障能力與LTE網(wǎng)絡(luò)存在一定差距。盡管關(guān)于Wi-Fi網(wǎng)絡(luò)服務(wù)質(zhì)量的標(biāo)準(zhǔn)已經(jīng)發(fā)布，但目前Wi-Fi設(shè)備對其支持率較低，因此用戶未來能否獲取與VoLTE一致的VoWi-Fi業(yè)務(wù)質(zhì)量體驗有待進一步評估。

6 結(jié)束語

本文從組網(wǎng)、接入認(rèn)證、傳輸安全性與VoLTE的無縫切換、語音編碼以及部署建議等方面分析了基于S2b方案的VoWi-Fi技術(shù)實現(xiàn)，同時對其他VoWi-Fi實現(xiàn)方案的優(yōu)缺點進行了分析，將有助于運營商提前做好各方面的技術(shù)準(zhǔn)備，加快VoWi-Fi的商用進程。

1 3GPP TS23.402.Architecture Enhancements for Non-3GPP Accesses,2011

2 IETF RFC5996.Internet Key Exchange Protocol Version 2(IKEv2),2010

3 IETF RFC4301.Security Architecture for the Internet Protocol,2005

4 IETF RFC4187.Extensible Authentication Protocol Method for 3rd Generation Authentication and Key Agreement(EAP-AKA),2006

5 Google不是想做運營商,是玩運營商,http://www.aiweibang.com/yuedu/23436242.html Google wants to do more than be an operator,http://www.aiweibang.com/yuedu/23436242.html