無線通訊從1980年發展至今，已經過30多個年頭。從最開始的類比語音通訊一直發展至現今的第叁代以及第四代行動通訊無線資料傳輸，由于頻寬和傳輸速度的提升，可進行的服務亦從語音一直進步到高畫質、低延遲的影音傳輸；而世界第一個長程演進計畫（LTE）網路于2010年在歐洲建置后，美洲及亞洲電信商近年來也已大舉布建。

　　LTE可提供大于100Mbit/s下行、50Mbit/s上行的傳輸速率以及極低的傳輸延遲，使得多樣性的高頻寬應用蓬勃發展，但由于LTE是以網際網路協定（IP）為基礎的系統，故不像傳統第二代以及第叁代行動通訊系統具備語音通訊的電路交換專用通道，所以語音通訊在LTE上成為一個非常有趣的議題。

　　在2011年底，基于希冀LTE語音技術能標準化以及一致性的塬則，系統業者以及通訊設備商一同制定在LTE上所採用的語音以及簡訊規範，這份規範即為全球行動通訊系統協會（GSMA）IR92--IMS Profile for Voice and SMS，也就是LTE語音通話（Voice over LTE， VoLTE）。

　　IR92定義VoLTE功能

　　IR92裡定義VoLTE的功能特性、媒體格式支援以及在行動通訊網路中使用的機制；VoLTE功能特性在IR92裡面被分為四個部分，分別為標準IMS 功能--SIP註冊、認證、位址格式以及通話的建立和結束等等細節；附屬應用服務（Supplementary Service， SS）包括來電等待（Communication Waiting）、來電號碼顯示限制（Originting Identification Restriction）、撥號不顯示號碼（Terminating Identification Restriction）、來電轉接（Communication Forwarding）等功能；還有通話建立條件以及基于IP網路下的簡訊服務（SMS Over IP）等四個部分。

　　媒體格式支援部分，IR92定義使用的語音通訊編碼分別為AMR（Adaptive Multi-Rate）和AMR-WB（Adaptive Multi-Rate Wideband），在RTP Profile的部分則必須支援AVP（Audio Video Profile），傳輸方式則使用UDP（User Datagram Protocol），另外由于須要對媒體資料傳輸進行控制，行動裝置也必須支援RTCP（RTP Control Protocol）。

　　IP資料在行動網路進行傳輸時，因為傳輸的環境跟頻寬都較有線網路嚴苛，故須用不同的機制來進行最佳化。由于LTE是以IP為基礎的網路，并大量使用網際網路通訊協定第六版（IPv6）來因應IP位址的不足，但IPv6應用于長時間小資料的語音通訊上會有表頭資料大小占整體資料比率太高的問題，故IR92 也定義裝置必須支援RoHC（Robust Header Compression）對IP表頭進行壓縮，以傳送差異化的資料替代整個表頭的傳送，此方法可有效降低傳輸IP表頭所占用的資料量（圖1）。

　　圖1 VoLTE信令子層

　　值得一提的是IR92是一份概略的文件，詳細的流程以及技術細節主要仍須參考RFC以及第叁代合作伙伴計畫（3GPP）內的文件，其中3GPP TS24.229 IP Multimedia Call Control Based on Session Initiation Protocol（SIP） and Session Description Protocol（SDP）這份文件定義了VoLTE的詳細信令流程。

　　當行動裝置連上LTE網路后，會進行P-CSCF（Proxy Call Session Control Function）找尋，待獲得P-CSCF的IP位址后就會發送REGISTER訊息進行註冊，P-CSCF會檢查行動裝置的REGISTER訊息找到對應的S-CSCF（Serving Call Session Control Function）將訊息轉送，此時S-CSCF會要求行動裝置進行認證，將認證須要使用的參數夾帶在Unauthorized訊息裡，透過P-CSCF 轉送此訊息以對行動裝置要求進行驗證，待行動裝置將認證參數和本身有的金鑰進行演算后，再將演算結果透過P-CSCF回傳至S-CSCF，S-CSCF收到訊息后進行驗證，若驗證成功則會發送OK的訊息至行動裝置以完成註冊程序。

　　當行動裝置要進行通話時，會發送INVITE的訊息給CSCF，此訊息包含欲進行通訊的行動裝置SIP位置、本身支援的語音編碼格式以及想要的服務品質 （Quality of Service， QoS）等參數，CSCF收到后會回應Trying訊息，并將INVITE訊息轉至收話的行動裝置，而收話的行動裝置即會回覆內含其支援的語音編碼格式的 Session Progress訊息，并開始要求網路進行VoLTE通話專屬通道的建立，待發話端行動裝置收到Session Progress訊息后，將依據雙方支援的語音編碼格式選擇一個適用的編碼，透過PRACK訊息傳送至收話端行動裝置，同時間也開始進行VoLTE通話專屬通道的建立，若收話端同意此設定，則會回應OK訊息，并同時向發話端發送響鈴的Ringing訊息，當發話端收到Ringing訊息后，會回應 PRACH訊息表示收到響鈴，此時收話端也會回應OK訊息，待收話端接起電話后，會發送另一道OK訊息來回應最一開始的INVITE訊息，待發話端回應 ACK后即表示此通VoLTE通話成功建立；若任何一端結束通話后，將發送BYE的訊息給對方，并開始釋放VoLTE通話專屬通道，而對方則會回應OK訊息以同意結束通話，這樣的一套流程即為VoLTE通話時所須經歷的標準流程（圖2）。

　　圖2 VoLTE裝置語音通訊信令流程圖

　　行動裝置在附屬應用服務相關的設定會存在XCAP Server（eXtensible Markup Language Configuration Access Protocol Server），相關的技術文件為3GPP 24.623。XCAP Server提供HTTP（HyperText Transfer Protocol）介面，讓行動裝置上的XCAP使用者介面可以依使用者需求更改附屬應用服務相關設定，而每個行動裝置都有其專屬的設定檔，裡面記載如來電忙碌時轉接的號碼、來電未接時轉接的號碼，以及去電時是否要顯示號碼等設定參數。例如，當使用者撥打VoLTE語音電話但對方沒有回應時，CSCF會去 XCAP Server查詢對方的XCAP設定檔，若發現裡面有設定來電未接的轉接號碼時，則會將此通電話轉到設定的號碼去。