教育部補助「行動寬頻尖端技術跨校教學聯盟第二期計畫 -- 行動寬頻網路與應用 -- 小細胞基站聯盟中心」 模組名稱： 「LTE-Small Cell 核心網路架構及服務」 單元-A6：LTE-Small Cell 多媒體影音串流服務 計畫主持人：許蒼嶺 (國立中山大學 電機工程學系) 授課教師：萬欽德.

Presentation on theme: "教育部補助「行動寬頻尖端技術跨校教學聯盟第二期計畫 -- 行動寬頻網路與應用 -- 小細胞基站聯盟中心」 模組名稱： 「LTE-Small Cell 核心網路架構及服務」 單元-A6：LTE-Small Cell 多媒體影音串流服務 計畫主持人：許蒼嶺 (國立中山大學 電機工程學系) 授課教師：萬欽德."— Presentation transcript:

1 教育部補助「行動寬頻尖端技術跨校教學聯盟第二期計畫 -- 行動寬頻網路與應用 -- 小細胞基站聯盟中心」 模組名稱： 「LTE-Small Cell 核心網路架構及服務」 單元-A6：LTE-Small Cell 多媒體影音串流服務 計畫主持人：許蒼嶺 (國立中山大學 電機工程學系) 授課教師：萬欽德 (國立高雄第一科技大學 電腦與通訊工程系)

2 課程單元目標 了解 Media Streaming 了解 Streaming Stored Multimedia
了解 Session Initiation Protocol (SIP) 了解 SIP協定與步驟 了解 Voice over LTE 之網路架構與QoS

3 Media Streaming

4 Multimedia Networking
Classes of MM applications: Streaming stored audio and video Streaming live audio and video Real-time interactive audio and video Fundamental characteristics: Typically delay sensitive end-to-end delay delay jitter But loss tolerant: infrequent losses cause minor glitches Antithesis of data, which are loss intolerant but delay tolerant. Jitter is the variability of packet delays within the same packet stream.

5 Streaming Streaming: media stored at source transmitted to client
Streaming: client playout begins before all data has arrived timing constraint for still-to-be transmitted data: in time for playout Adapted from Kurose & Ross slides

6 Multimedia: Quality of Service
Multimedia applications: network audio and video (“continuous media”) Network provides application with level of performance needed for application to function. QoS Adapted from Kurose & Ross slides

7 Streaming Stored Multimedia
Streaming: at this time, client playing out early part of video, while server still sending later part of video 3. video received, played out at client Cumulative data 2. video sent 1. video recorded network delay time Adapted from Kurose & Ross slides

8 Delay Jitter constant bit rate transmission client reception
Cumulative data time variable network delay (jitter) client reception rate playout at client client playout buffered data Adapted from Kurose & Ross slides

9 Streaming Stored Multimedia: Interactivity
VCR-like functionality: client can pause, rewind, FF, push slider bar 10 sec initial delay OK 1-2 sec until command effect OK RTSP often used (more later) Timing constraint for still-to-be transmitted data: in time for playout Adapted from Kurose & Ross slides

10 Streaming Live Multimedia
Examples: Internet radio talk show Live sporting event Streaming playback buffer playback can lag tens of seconds after transmission still have timing constraint Interactivity fast forward impossible rewind, pause possible! Adapted from Kurose & Ross slides

11 Interactive, Real-Time Multimedia
Applications: IP telephony, video conference, distributed interactive worlds End-end delay requirements: audio: < 150 msec good, < 400 msec OK includes application-level (packetization) and network delays higher delays noticeable, impair interactivity Session initialization how does callee advertise its IP address, port number, encoding algorithms? Adapted from Kurose & Ross slides

12 Internet Multicasting
Adapted from Kurose & Ross slides

13 Multicast: Connecting Multiple Users
Unicast: connecting two users Multicast: connecting multiple users Conference call Event broadcast Chat room Supporting multicast Multiple unicast Inefficient Build a multicast tree Assume cost on links Adapted from Kurose & Ross slides

14 The Multicast Problem Given: Network
Given: User Requests (and quality of service requirements) Establish: Efficient distribution (trees) Adapted from Kurose & Ross slides

15 The Need for Multicasting
Use bandwidth efficiently Replace many unicast connections with one multicast connection Duplicate packets only when necessary Theoretical model Links have cost Find the minimum cost multicast tree 3 times the traffic Adapted from Kurose & Ross slides

16 Streaming Stored Multimedia: Interactivity

17 Streaming Stored Multimedia
Application-level streaming techniques for making the best out of best effort service: client side buffering use of UDP versus TCP multiple encodings of multimedia Media Player Jitter removal Decompression Error concealment Graphical user interface with controls for interactivity Adapted from Kurose & Ross slides

18 Streaming Multimedia: Client Buffering
constant bit rate video transmission variable network delay client video reception constant bit rate video playout at client client playout delay Cumulative data buffered video time Client-side buffering, playout delay compensate for network-added delay, delay jitter Adapted from Kurose & Ross slides

19 Streaming Multimedia: Client Buffering
constant drain rate, d variable fill rate, x(t) buffered video Client-side buffering, playout delay compensate for network-added delay, delay jitter Adapted from Kurose & Ross slides

20 Streaming Multimedia: UDP vs. TCP
Server sends at rate appropriate for client (oblivious to network congestion!) Often send rate = encoding rate = constant rate Then, fill rate = constant rate - packet loss Short playout delay (2-5 seconds) to compensate for network delay jitter Error recover: time permitting TCP Send at maximum possible rate under TCP Fill rate fluctuates due to TCP congestion control Larger playout delay: smooth TCP delivery rate HTTP/TCP passes more easily through firewalls Adapted from Kurose & Ross slides

21 Streaming Multimedia: Client Rate(s)
1.5 Mbps encoding 28.8 Kbps encoding Q: How to handle different clients receive rate capabilities? 0.5+ Kbps ADSL 100Mbps Ethernet A: Server stores, transmits multiple copies of video, encoded at different rates. Adapted from Kurose & Ross slides

22 User Control of Streaming Media: RTSP
HTTP Does not target multimedia content No commands for fast forward, etc. RTSP: RFC 2326 Client-server application layer protocol. For user to control display: rewind, fast forward, pause, resume, repositioning, etc… What it doesn’t do: Does not define how audio/video is encapsulated for streaming over network Does not restrict how streamed media is transported; it can be transported over UDP or TCP Does not specify how the media player buffers audio/video Adapted from Kurose & Ross slides

23 Session Initiation Protocol — An Introduction

24 SIP Session Initiation Protocol (SIP) Comes from IETF
SIP long-term vision All telephone calls and video conference calls take place over the Internet People are identified by names or addresses, rather than by phone numbers. You can reach any IP device, no matter where the device roams. Adapted from Kurose & Ross slides

25 SIP Services Setting up a call Determine current IP address of callee.
Provides mechanisms for caller to let callee know she wants to establish a call Provides mechanisms so that caller and callee can agree on media type and encoding. Provides mechanisms to end call. Determine current IP address of callee. Maps mnemonic identifier to current IP address Call management Add new media streams during call Change encoding during call Invite others Transfer and hold calls Adapted from Kurose & Ross slides

26 Setting Up a Call to a Known IP Address
Alice’s SIP invite message indicates her port number & IP address. Indicates encoding that Alice prefers to receive (PCM ulaw) Bob’s 200 OK message indicates his port number, IP address & preferred encoding (GSM) SIP messages can be sent over TCP or UDP; here sent over RTP/UDP. Default SIP port number is 5060. Adapted from Kurose & Ross slides

27 Setting Up a Call (more)
Codec negotiation: Suppose Bob doesn’t have PCM ulaw encoder. Bob will instead reply with 606 Not Acceptable Reply and list encoders he can use. Alice can then send a new INVITE message, advertising an appropriate encoder. Rejecting the call Bob can reject with replies “busy,” “gone,” “payment required,” “forbidden”. Media can be sent over RTP or some other protocol. Adapted from Kurose & Ross slides

28 Example of SIP message INVITE sip:bob@domain.com SIP/2.0
Via: SIP/2.0/UDP From: To: Call-ID: Content-Type: application/sdp Content-Length: 885 c=IN IP m=audio RTP/AVP 0 Notes: HTTP message syntax sdp = session description protocol Call-ID is unique for every call. Here we don’t know Bob’s IP address. Intermediate SIP servers will be necessary. Alice sends and receives SIP messages using the SIP default port number 5060. Alice specifies in Via: header that SIP client sends and receives SIP messages over UDP Adapted from Kurose & Ross slides

29 Name Translation and User Location
Caller wants to call callee, but only has callee’s name or address. Need to get IP address of callee’s current host: user moves around DHCP protocol user has different IP devices (PC, PDA, car device) Result can be based on: time of day (work, home) caller (don’t want boss to call you at home) status of callee (calls sent to voic when callee is already talking to someone) Service provided by SIP servers: SIP registrar server SIP proxy server Adapted from Kurose & Ross slides

30 SIP Registrar When Bob starts SIP client, client sends SIP REGISTER message to Bob’s registrar server (similar function needed by Instant Messaging) Register Message: REGISTER sip:domain.com SIP/2.0 Via: SIP/2.0/UDP From: To: Expires: 3600 Adapted from Kurose & Ross slides

31 SIP Proxy Alice send’s invite message to her proxy server
contains address Proxy responsible for routing SIP messages to callee possibly through multiple proxies. Callee sends response back through the same set of proxies. Proxy returns SIP response message to Alice contains Bob’s IP address Note: proxy is analogous to local DNS server Adapted from Kurose & Ross slides

32 Example Caller jim@umass.edu with places a call to keith@upenn.edu
Jim sends INVITE message to umass SIP proxy. Proxy forwards request to upenn registrar server. upenn server returns redirect response, indicating that it should try (4) umass proxy sends INVITE to eurecom registrar. (5) eurecom registrar forwards INVITE to , which is running keith’s SIP client. (6-8) SIP response sent back (9) Media sent directly between clients. Note: also a SIP ack message, which is not shown. Adapted from Kurose & Ross slides

33 Session Initiation Protocol (SIP)協定

34 SIP SIP (Session Initiation Protocol)協定是IETF提出的， 是一個應用層的信令控制協議。
會話的參與者可以通過組播（multicast）、網狀單 播（unicast）或兩者的混合體進行通信。 在VoLTE中，IMS對業務的控制全部通過SIP消息 完成。 SIP有兩種類型的消息：  請求：從客戶機發到伺服器的消息。  回應：從伺服器發到客戶機的消息。

35 SIP SIP 協定 建立, 修改和終止多媒體會談(Session) 以文字為基礎的協定易於實做 只與信令(Signaling)部分有關係
Create, Modify, Terminate Multimedia Sessions 使用 IP 與傳輸層之傳輸方式無關 TCP或UDP封裝 支援平行搜尋 使用者可註冊於多個使用者裝置(User Equipment) Client / Server 架構

36 SIP Protocol Stack SIP 的傳送是使用QCI 5 bearer.

37 Protocol Stack

38 SIP 訊息 SIP常用的請求消息包括下列幾種，： SIP方法 描述 定義文檔 INVITE
表示一個用戶端發起或被邀請參加電話會議（indicates a client is being invited to participate in a call session） RFC3261 ACK 確認客戶已經收到一個INVITE請求的最終響應（Confirms that the client has received a final response to an INVITE request） BYE 終止一個呼叫，可以由主叫或被叫方發起（Terminates a call and can be sent by caller or the callee） OPTIONS 查詢伺服器的能力（Queries the capabilities of servers） CANCEL 取消所有正在處理中的請求（Cancel any pending request） REGISTER 向標題欄位中的SIP伺服器發起地址清單註冊（Registers the address listed in the To header field with SIP Server） PRACK 臨時確認（Provisional acknowledgement） RFC3262 SUBSCRIBE 向伺服器訂閱某個事件通知（Subscribes for an Event of Notification from the Notifier） RFC3265 NOTIFY 向訂閱都發送一個新的事件（Notify the subscriber of a new Event） UPDATE 在沒有修改對話狀態的情況下修改會話（Modifies the state of a session without changing the state of the dialog） RFC3311 PUBLISH 發佈一個事件到伺服器（Publishes an event to the Server） RFC3903 INFO 會話過程中發送一個會話消息，但不修改會話狀態（Sends mid-session information that does not modify the session state） RFC6086 REFER 請求收件人發出SIP請求（Asks recipient to issue SIP request(call transfer)） RFC3515 MESSAGE 使用SIP傳輸即時消息（Transports instant messages using SIP） RFC3248

39 SIP 訊息 Request Response INVITE ACK OPTIONS BYE CANCEL REGISTER
1xx Informational 2xx Successful 3xx Redirection 4xx Client Error 5xx Server Error 6xx Global Error

40 SIP 訊息 回應訊息包含數字回應代碼 臨時回應（1XX）：臨時回應被伺服器用來指示進程，但是不終結SIP事物。
最終回應（2XX，3XX，4XX，5XX，6XX）：最終回應終止SIP事物。 說明 範例 1xx Informational (代表請求已收到) 100 Trying 180 Ringing 181 Call is Being Forwarded 183 Session Progressing 2xx Success (代表請求已被成功處理) 200 OK 202 Acceptable 3xx Redirection (代表重新導向) 300 Multiple Choices 301 Moved Permanently 302 Moved Temporarily 4xx Client Error (代表用戶端錯誤) 401 Unauthorized 406 Not Acceptable 407 Proxy Authentication Required 486 Busy Here 487 Request Terminated 4 88 Not Acceptable Here 5xx Server Error (代表伺服器端錯誤) 502 Bad Gateway 503 Service Unavailable 6xx Global Failure (代表整體網路環境錯誤) 600 Busy Everywhere 603 Decline

41 VoIP 基本呼叫流程 Client (Caller) Server (Callee) INVITE+SDP 100: Trying
180: Ringing 200: OK+SDP ACK RTP

42 VoIP 基本呼叫流程 Client (Caller) Server (Callee) INVITE+SDP(80K)
100: Trying 180: Ringing 200: OK+SDP(50k) CANCEL 無法建立連線

43 通訊建立初期會發生的問題 Session time 太長 SDP交換資料不足 QoS來不及處理
電話鈴聲響起之前(180 ringing傳送前)，必須把 所有事情都準備好。 某些情況下我們需要Provisional responses reliability 雖然SIP可以用簡單的Invite , ok 訊息來建立一通電話，但是在3g或是更實際的應用上，可能會發生一些問題， 例如session建立後, 對方的鈴聲響了，可是打電話的一方才發現網路資源(QoS)不足或是對方回應的200ok描寫的媒體能力不符合 ，必須重新建立連線,會導致ghost ringing情形(rfc3312), 但是通常要保留網路資源(qos)，一定得先獲得對方的codec參數,ip,port等相關資訊 ,這些都必需要經由sip交換才能獲得(先有雞還是先有蛋問題)。另一個問題是session建立時間可能較長,雙方並不知道現在建立到何種程度的連線 (因為Provisional responses 送出去，也得不到回應)。

44 SIP PRACK method Reliability of Provisional Responses in the SIP (RFC 3261) 讓 Provisional Responses 也有ACK回應 有更多訊息、時間可以做QoS或媒體溝通能力的準備 INVITE+SDP 200: OK (回應 PRACK) Client (Caller) Server (Callee) 183 Session Progress +SDP PRACK (回應183)

45 SIP QoS B A INVITE + SDP1 (QoS) 183: Progress + SDP2 RESERVATION PRACK
200:OK (PRACK) RESERVATION INVITE + SDP1 (QoS) UPDATE +SDP3 200:OK (UPDATE) +SDP4 180: Ringing A -> INVITE(含SDP,QOS要求)-> B (通常A不希望此時B的電話鈴叫,因為還沒做好雙向QOS準備) B同意 A 的QOS要求，並且開始操作 B->A 線路的QoS 但是需要 A 去執行 A->B的QoS 因此 B回應一個 183 (Session Progress) response 給A 請A開始做A->B的QoS, 並且QOS做好後，要回個確認給B (使用UPDATE) (此時B也開始做他自已的QOS要求) 183原本是不會回應的，因為是屬於暫時性的回應provisional responses 但是RFC 新增了一個PRACK方法, 因此 183 的SIP訊息內容加入tag:100rel 表示收到這訊息要回應 PRACK B結束了QOS要求，但是還不會讓電話鈴叫 當A完成QoS要求，會在送一個update 給 b (最後QOS,CODEC的結果) b會回應200 ok (最後qos,codec的結果) b電話才開始叫

46 SDP 會談描述協定制訂在RFC 2327 加強與補充SIP描述Media不足之處
SDP, Session Description Protocol 加強與補充SIP描述Media不足之處 SDP也是用文本格式描述的，一個SDP Description可以包含很多行，每一行的格式如 下：  Type = Value (Type只用一個字母來表示；一個 SDP) Description通常有一個Session-level和多個 Media-level資訊組成

47 SDP 必要欄位(Mandatory Fields) 選項欄位(Optional Fields)
(v)Protocol version－指出協定使用版本 (o)Origin－會談擁有者 (s)Session name－會談名稱或主題 (t)Time description－會談起始結束時間 (m)Media description－使用媒體類型 選項欄位(Optional Fields) (i)Session information－會談補充資訊 (u)URI－會談資訊從哪個URI獲得 (e) Address－代表會談的電子郵件位址 (p)Phone Number－代表會談的電話號碼 (c)Connection information－連線資訊(連線、網路、位址) (b)Bandwidth description－頻寬要求 (r)Repeat information－指出RTP重複次數 (z)Time zone adjustments－不同時區，時區的調整 (k)Encryption key－會談加密使用的金鑰 (a)Attributes－額外屬性的描述

48 SIP 訊息 – 範例 INVITE sip:bob@zzz.edu SIP/2.0
Via: SIP/2.0/UDP pc33.yyy.edu Max-Forwards: 70 To: Bob From: Alice Call-ID: CSeq: INVITE Contact: Content-Type: application/sdp Content-Length: 142 SIP v=0 o=Alice IN IP s=Phone Call c=IN IP t=0 0 m=audio RTP/AVP 0 a=rtpmap:0 PCMU/8000 SDP

49 SIP 訊息 INVITE sip:bob@zzz.edu SIP/2.0 Via: SIP/2.0/UDP pc33.yyy.edu
Method 即 命令 Request URI SIP 協定版本 INVITE SIP/2.0 Via: SIP/2.0/UDP pc33.yyy.edu Max-Forwards: 70 To: Bob From: Alice Call-ID: CSeq: INVITE Contact: Content-Type: application/sdp Content-Length: 142

50 SIP 訊息 Via: SIP/2.0/UDP pc33.yyy.edu Max-Forwards: 70
To: Bob From: Alice Call-ID: CSeq: INVITE Contact: Content-Type: application/sdp Content-Length: 142

51 SIP 訊息 Max-Forwards: 70 To: Bob <sip:bob@zzz.edu>
最多可以被幾個Server轉傳 Max-Forwards: 70 To: Bob From: Alice Call-ID: CSeq: INVITE Contact: Content-Type: application/sdp Content-Length: 142

52 SIP 訊息 To: Bob <sip:bob@zzz.edu>
　　　　 目的地位址 To: Bob From: Alice Call-ID: CSeq: INVITE Contact: Content-Type: application/sdp Content-Length: 142

53 SIP 訊息 From: Alice <sip:alice@yyy.edu>;tag=1928301774
　　　　　來源位址 　　　　　　虛擬的隨機亂數 (當作是ID使用) From: Alice Call-ID: CSeq: INVITE Contact: Content-Type: application/sdp Content-Length: 142

54 SIP 訊息 Call-ID: a84b4c76e66710@pc33.yyy.edu CSeq: 314159 INVITE
在網域內獨一無二的識別碼 Call-ID: CSeq: INVITE Contact: Content-Type: application/sdp Content-Length: 142

55 SIP 訊息 CSeq: 314159 INVITE Contact: <sip:alice@pc33.yyy.edu>
遞增的序號 CSeq: INVITE Contact: Content-Type: application/sdp Content-Length: 142

56 SIP 訊息 Contact: <sip:alice@pc33.yyy.edu>
Content-Type: application/sdp Content-Length: 142

57 SIP 訊息 Content-Type: application/sdp Content-Length: 142
用來描述附加的訊息主體格式 (如果有的話) Content-Type: application/sdp Content-Length: 142

58 SIP 訊息 用來描述附加的訊息主體的內容長度 (Octets) Content-Length: 142

59 SDP 的欄位 v= (protocol version)
o= (owner/creator and session identifier) o=<username> <session id> <version> <network type> <address type> <address> Username 不可以含有空格 Session id 和version 建議使用Network Time Protocol (NTP)的時間戳記來確保值的唯一性 例如: o=john IN IP s= (session name string) 例如: s=SDP Seminar t= (start time and stop time) 例如: t= (通常設為0)

60 SDP 的欄位 m= (media name and transport address) e= (email address)
m=<media> <port> <transport> <format list> m=<media> <port>/<number of ports> <transport> <format list> 例如: m=video /2 RTP/AVP 0 <media> "audio", "video", "application", "data" and "control“ <transport> RTP/AVP - the IETF's Realtime Transport Protocol using the Audio/Video profile carried over UDP e= ( address) 例如: (John Doe) 或者 e=John Doe p= (phone number) 例如: p= 或者 p= u-law PCM, single channel, audio sampled at 8KHz

61 SDP 的欄位 c= (connection information)
c=<network type> <address type> <connection address> 例如: c=IN IP /127 通常這個連線位址是一個 class D的 IP 群播位址, <base multicast address>/<ttl>/<number of addresses> 例如: c=IN IP /127/3 指的是多個 c=IN IP /127, c=IN IP /127, c=IN IP /127

62 SDP的欄位 SDP 的欄位 a = (Attributes)
a=rtpmap:<payload type> <encoding name>/<clock rate> [/<encoding parameters>] 將一個RTP封包類型對應到用來編碼此封包格式的編碼名稱 例如： m=audio RTP/AVP a=rtpmap:96 L8/8000 a=rtpmap:97 L16/8000 a=rtpmap:98 L16/11025/2 RTP/AVP 會有三種編號 96,97,98, 分別對應到編碼/取樣率(L8/8000, L16/8000, L16/11025/2)

63 IMS 的 SIP 流程 UE A P-CSCF A S-CSCF A S-CSCF B P-CSCF B UE B I-CSCF B
e.g.Invite 183 session Send INVITE to SIP URI of user B Set contact to own IP adr/port Pre-load stored Service-Route into Route Pre-load stored P-CSCF into Route(top) (37) Store Contact of UE B (38) Store (Reversed) Record-Route (5) Remove own entry from Route (6) Add own entry to Record-Route&via (7) Route on to next hop in Route (36) Remove own Via entry/ send to next (8) Remove own entry from Route (9) Add own entry to Record-Route&via (10) Perform Filtering Contact AS’s if applicable (11) Query DNS for domain of user B’s SIP URI (12) Route to address received from DNS (35) Remove own Via entry/send to next Remove own entry from Route Add own entry to via (not to Record-Route) Query SLF for HSS address of user B Query HSS for S-CSCF address of user B Route to S-CSCF address received from HSS remove own via entry / send to next Add own entry to Record-Route Perform Filtering Contact AS’s if applicable Replace SIP URI of user B with registered Contact Put stored Path to UE B into Route header Route on to next hop in Route header Route to request URI= IP adr of UE B Save Contact of UE A Create response Set Contact to own IP adr/port Copy Record-route &Via to response Send response based on Via header

64 Voice over LTE (VoLTE)

65 VoLTE 簡介 VoLTE 即 Voice over LTE，是基於LTE網路傳送語音的技術。
配合 IMS (IP Multimedia Subsystem) 的管理機制，可提供全 IP 網路實現數據與語音服務。 4G 用戶利用 LTE 網路傳送語音和影像等服務，不需要回到 3G 網路。 快速的通話連接，VoLTE 最快可於1秒內響鈴、接通電話 高品質的語音通話，能讓聲音更立體、話質更清晰，另外還能隨時切換語音與視訊通話。 遠傳電信與台灣之星 2015年6月10日皆宣布通過 NCC 的 VoLTE（Voice over LTE）系統審驗，台灣大哥大2015年6月12日也宣布通過NCC審驗。 全球已有7個國家、16家業者的 VoLTE 服務進入商轉模式，包括美國T-Mobile、AT&T，韓國 SKT、LG U+、日本 DOCOMO、香港電訊 PCCW 等電信商。 目前支援 VoLTE 系統的品牌手機不多，得等待手機韌體升級，並通過行動網路測試後，才能達到真正普及。 業者要持續優化現有的 4G 網路，隨著提高基地覆蓋率，才能提供較為穩定的 VoLTE 服務。 IMS全稱為“IP Multimedia Subsystem”，即：IP多媒體子系統，包括IMS核心網和IMS AS VoLTE終端通過LTE無線網接入EPC核心網，EPC核心網根據EPC HSS中的簽約數據，為用戶建立預設承載，使用戶能夠正常使用互聯網業務（always online）。 在VoLTE終端接入LTE/EPC網路的過程中，網路告知終端“網路支持VoLTE業務”，VoLTE終端發起IMS APN承載建立請求，LTE/EPC為用戶建立IMS APN預設承載（承載建立過程中需開啟PCC流程），VoLTE終端經由LTE/EPC網路提供的IMS APN IP通道接入IMS核心網進行註冊，鑒權通過後，IMS核心網根據用戶的IMS簽約信息完成用戶在相應IMS AS的註冊。 後續，VoLTE用戶發起呼叫，呼叫請求通過LTE/EPC網路提供的IMS APN IP通道送至IMS核心網及用戶註冊的IMS AS，IMS AS負責用戶呼叫的處理； IMS核心網負責根據呼叫請求中的被叫號碼進行路由，接續被叫，若被叫位於IMS網內，則在IMS網內接續被叫，若被叫為其它運營商用戶或被叫位於2/3G網，則IMS核心網將呼叫接續至電路域關口局。 在用戶媒體面連接建立之前，IMS核心網會通知PCRF，在LTE/EPC網內為VoLTE用戶建立IMSAPN專用承載的IP通道，保障用戶的語音業務質量。

66 VoLTE 簡介 4G LTE 主要是以提供數據服務為主，為滿足用戶語音通話需求,發展出
CSFB（Circuit Switched Fallback）、 SVLTE（Simultaneous Voice and LTE）& SGLTE (Simultaneous GSM and LTE)、 SRVCC (Single Radio Voice Call Continuity) VoLTE (Voice over LTE) 。 SvLTE CSFB SRVCC VoLTE LTE佈署初期，未佈署IMS 終端可採用SvLTE雙待方式，語音業務仍由CS提供 開始佈署IMS，並對CS域進行升級改造 終端可採用CSFB方式，語音業務仍由CS提供 IMS已佈署，開始提供VoLTE服務 終端可採用SRVCC方式，保證切換到CS域時的語音連續性 CS用戶全部遷移至IMS 終端只需支援VoLTE，不需切換 LTE熱點覆蓋 LTE規模覆蓋 LTE連續覆蓋 LTE完全覆蓋 SRVCC方案適用于運營商已經部署了IMS網路，在LTE網路已經能夠提供基於分組域的語音業務，但是LTE還沒有達到全網覆蓋的場景。 SRVCC與CSFB方式不同的是，CSFB是在LTE和2G/3G重疊覆蓋區域內發生回落，而SRVCC則是在LTE網路失去覆蓋的時候，才發生到2G/3G網路電路域間的切換。 由於CS語音會導致TD-LTE下頻繁的模式切換，影響使用者的業務體驗；另外，CSFB技術要求TD-LTE和2G/3G同覆蓋，並對網路和終端都提出了新要求(需要升級UE、MME、MSC、E-UTRAN、SGSN等網路設備以及需要終端支援CSFB功能等)，因此，CSFB技術只是在TD-LTE網路中提供語音業務的一種過渡方案。 SRVCC技術需要部署IMS網路和SRVCC AS(應用伺服器)；需要升級現網部分MSCServer；需要e-UTRAN、MME和HSS支援，另外，也需要終端支援IMS用戶端和SRVCC能力。 SRVCC的基本工作流程為：為了實現SRVCC，話音呼叫錨定在IMS系統中。當發起TD-LTE到2G/3G的域轉移時，MME(具有UESRVCC相關資訊)首先從TD-LTE網路獲得切換指示，然後觸發到MSCServer的SRVCC流程，MSCServer發起到IMS的會話轉移流程，並且完成到目標社區的CS切換流程。切換完成後，MSCServer向MME發送回應(其中包括必要的切換命令資訊)，並轉給UE用於接入2G/3G網路。這樣，語音呼叫就從TD-LTE轉移到2G/3G網路了，並借此保持了語音業務的連續性。 資料來源:

67 VoLTE 簡介 OTT（Over-The-Top）:僅利用運營商的網路，而服務由運營商之外的第三方提供 SVLTE & SGLTE:
VOIP網路電話，利用網路來進行通話的服務，語音服務交給OTT業者(Skype, Line, Whatsapp, Viber, Facebook)。 OTT 通話並沒有顯示電話號碼, 也比較受到網路狀況影響而產生不佳的通話品質, 甚至中途斷訊。 SVLTE & SGLTE: SVLTE 與 SGLTE，即雙待手機方式 (前者是 LTE+CDMA,後者是 LTE+GSM)，透過手機本身支援雙電 信系統，讓手機同時工作在 LTE 和 CS (Circuit Switched) 方式，前者提供數據業務，後者提供語音業 務。 CSFB（Circuit Switched Fallback）: 自LTE網路換至 2G/3G 交換式網路 (Circuit-Switch Domain) 的一種機制。電信商不需部署 IMS，只需 要升級 MSC (mobile service switching center) 就可以支持，目前多數電信業者大都採取此項語音服務 技術方案，被視為 IMS (VoLTE) 部署之前的過渡方案。 VoLTE (Voice over LTE): VoLTE 是利用LTE的網路的封包交換來產生語音通話 MSC: mobile switch service center 技術 優點 缺點 OTT (網路電話 VOIP) 互打免費 沒有號碼，通話不穩定 SVLTE (雙卡雙待手機) 手機可支援，無關網路 手機昂貴，選擇性少，耗電 CSFB (語音服務轉為 2G/3G) 目前多數採行的方案 通話延遲，通話時上網慢 VoLTE (LTE語音技術) 品質好，通話快速 訊號涵蓋率要高 資料來源:

68 VoLTE 簡介 LTE手機使用3G的線路來做語音通話的話，大概需要6-8秒的連接時間，若使用 VoLTE 的話只需花 3秒左右即可連接通話。 若發話端或受信端一為非支援VoLTE手機的狀態下，其通話連結的速度就無法像都是支援 VoLTE 功能手機 相互通話來的快速。 VoLTE 所使用的聲音周波區域帶相較於現在3G通話技術所使用的最高3.4KHz還要來的更廣，最廣 可以到達7KHz，這樣的特性使得女性或是音域較高的聲音可以被清楚的呈現。 根據 CS FallBack 技術的特性，一般的LTE手機需在通話時切換至3G的線路傳送語音，網路通訊有 最高384 kbps的速度上限，若要一邊進行語音通話一邊聯網傳送大量的資料較困難。相較之下，若 是使用 VoLTE 來進行通話最大的瞬間通信數量最大可到達150Mbps。 相較於3G視訊電話的176×144 ppi，15fps， VoLTE 目前可以支援最高640×480 ppi，20fps的影像通 話，影像通話解析度更高，雜訊更少，不論影像或是通話都更清晰，這樣的影像通話不但可以是直 接以影像通話的方式撥出，也可以在通話的途中切換為影像通話。 利用 VoLTE 進行通話可以如一般通話般顯示電話號碼, 若沒有使用SIM卡無法進行 VoLTE的通話。 VoLTE 2G/3G 呼叫延遲 0.5-2 秒 5-8 秒 語音品質 頻率：50~7000Hz 編解碼：AMR-WB 23.85Kbps 頻率：300~3400Hz 編解碼：AMR-NB 12.2Kbps 視訊品質 典型解析度：480*640 解析度：176*144

69 VoLTE 簡介 VoLTE 的推動障礙 電信業者推行 VoLTE 必須佈署IMS, LTE訊號涵蓋率需80%才能推動, 才不致於掉 話、斷線或是打不通。 目前坊間可以支援 VoLTE 手機並不多,需軔體更新，並符合該電信業者系統規格。 不同系統或不同國家的 VoLTE 的服務需使用到連結電話的「POI (Point of interface)」功能去做相互的資料交換，若要相互支援需將現行的電路交換(Circuit Switched)技術轉換為以IP為基礎的技術。 目前IMS漫遊協議尚未統一，很多 VoLTE 僅限於雙方都必須使用同業者及支援 VoLTE 手機才有辦法生效。 VoLTE開啟了向移動寬頻語音演進之路，給運營商帶來兩方面的優勢，一是提升無線頻譜利用率、降低網路成本。LTE的下行鏈路速率為5 bit/s/Hz，(3-4 倍於R6 HSDPA)；上行鏈路為2.5 bit/s/Hz，(2-3 倍於R6 HSUPA)[8]。另一個價值就是提升用戶體驗，VoLTE的體驗明顯優於傳統電路交換網路語音。首先，高品質語音和視訊編解碼的引入顯著提高了通信品質；其次，VoLTE的呼叫連接時間大幅縮短，VoLTE比電路交換網路呼叫縮短一半以上。

70 VoLTE 原理 LTE 在實體層使用 OFDM 作為主要調變的方式
將頻寬上面分為多個子載波 (subcarrier)，每個子載波再使用不同的調 變方式去作傳輸，調變方式有可能是 QPSK、16QAM、64QAM。 若是要高可靠性就使用 QPSK，若是要高傳輸速率就使用 64QAM。 優點是相當的彈性，缺點就因為被切割得很細，所以容易有額外的時間 上的傳輸錯誤 inter-symbol interference (ISI)，或是載波頻率上的錯誤 inter-carrier interference (ICI)。 最小的調變單位是 Resource Element (RE)。每個 RE 可以表示2bits、 4bits 或 6bits，跟調變的方式有關。

71 VoLTE 原理 根據LTE的頻寬設定，1.4MHz、3MHz、5MHz、 10MHz、15MHz、20MHz會有不同的數量的RB可 作分配。 在0.5ms的時間內，每個RE最多傳送6個bits。所以 0.5ms之內可以傳送84個RE，相當於1008kbits/sec (84*6bits/0.5ms) ，就是1Mbits/s左右。 Channel bandwidth(MHz) 1.4 3 5 10 15 20 Transmission bandwidth configuration (NRB) 6 25 50 75 100

72 VoLTE 原理 在時域上，LTE最小資源調度單位是一個 TTI，即 1ms；在頻域上，LTE最小的資源調度單位是一個 資源塊（resource block，RB）。 若採用AMR-NB編碼，其速率為12.2kbps，典型的VoIP封包傳送週 期為20ms，VoIP封包的20ms週期內才傳送224 bit。 VoLTE 的資源調度時間單位為1ms，相較於傳統VoIP，VoLTE 僅僅 使用了5%的時間。VoLTE 可以安排更多的使用者充分利用剩下的 95%的時間。 這一單位資源用來傳送一個VoIP封包是非常充足的。

73 VoLTE 原理 LTE最大單載波為20MHz，20MHz除以180KHz （一個RB），約等於100。也就是，20MHz單載波 在1ms內可支援100個用戶同時通話，那麼在20ms 內 VoLTE 就可支援2000個用戶同時通話。 這是在理想RF條件下，沒有考慮實際限制。不過， 即使只有50%的效率，一個 VoLTE 區塊也能同時 支持1000個使用者通話。

74 Voice over LTE 網路架構

75 VoLTE 網路架構 LTE 的網路架構主要分為無線部分 E-UTRAN (Evolved Universal Terrestrial Radio Access Network) 與核心網路部分 EPC (Evolved Packet Core)。 E-UTRAN 為無線部分的架構，包含了 UE 及 eNB (Evolved Node B)，eNB 為 基地台，可做無線資源的管理。 UE 與 eNB 之間經由 LTE-Uu 通訊。 HSS：歸屬使用者伺服器，即IMS的資料庫。它包含使用者設定檔，執行用戶的身份驗證和授權，並可提供有關使用者物理位置的資訊。 LTE-Uu

76 VoLTE 網路架構 在訊息傳輸方面分為Control-plane與User-plane，用以區分網路控制封 包及用戶實際傳輸的資料封包；
Control-plane 傳輸路徑為 UE<->eNB<->MME User-plane 傳輸路徑為 UE<->eNB<->S-GW<->P-GW； VoLTE 採用 IMS 作為業務控制層系統，EPC 僅作為承載層； SIP 協定 只在終端和 IMS 支援。

77 VoLTE 網路架構 EPC 是核心網路的部分，在設計上採 All-IP 的架構，可兼容舊有通訊系統 (如 2G、3G 等) 及 IP 網路系統 (如 WLAN、WiMAX 等)。 EPC 設計上採水平對等架構。其要由三個部分組成: MME (Mobility Management Entity)、S-GW (Serving Gateway)及 P-GW (Packet Data Network Gateway)。 MME 為核心網路的管理者；處理 Control-plane 訊息，如移動性、身分認證等安全性管理 S-GW 管理系統內User-plane訊息；包括Routing/Forwarding 資料封包、Mobility Anchor (處理 eNB 間的換 手)；用以做 LTE 與 3GPP 系統間(如 2G/3G 等)的相容切換。 P-GW 負責User-plane 的外部連線(Internet)；用以做LTE與非3GPP系統(如WLAN、WiMAX等) 的相容切換。 LTE-Uu 可分為三層: Layer 3: NAS (Non-Access Stratum) 是做移動性管理、Bearers 設定、用戶的附著與認證等。 RRC (Radio Resource Control) 是做無線資源的管理與 RRC 之下各層的設定。 Layer 2: PDCP (Packet Data Convergence Protocol)用來處理標頭壓縮及加密動作。 RLC (Radio Link Control)包含了重傳機制及為了配合下層 MAC 的各個 frame 大小進行封包的分割與重組。 MAC (Medium Access Control)則主要做 QoS 的排程動作。 Layer 1: PHY (Physical)將資料轉為實體訊號發送。

78 VoLTE 網路架構 在 IMS (IP Multimedia subsystem) 中有四種不同類型的呼叫會話控制功 能（CSCF）：
proxy call session control function（P-CSCF） IMS中用戶的第一個聯繫點（在信令平面），從SIP的角度來看，它是一個出 站/入站的SIP代理伺服器，所有的SIP信令，無論是來自使用者設備UE，還是 發送給UE的，都必須經過P-CSCF。 serving call session control function（S-CSCF） IMS的核心所在，它為UE進行會話控制和註冊請求，在同一個運營商的網路 中，可以有多個S-CSCF。 interrogating call session control function（I-CSCF） I-CSCF是一個運營商網路內部的接觸點，所有與這個網路運營商的使用者連 接都要經過這個實體。在一個網路中可以有多個I-CSCF。 從HSS獲取下一個節點的名稱（如S-CSCF或AS）。 請求路由到S-CSCF或AS。 emergency call session control function（E-CSCF） 處理IMS緊急請求

79 VoLTE 網路架構 EPC 是核心網路的部分，在設計上採All-IP的架構，可兼容舊有通訊系統(如 2G、3G 等)及 IP 網路系統(如 WLAN、WiMAX 等)。 EPC設計上採水平對等架構。其要由三個部分組成:MME (Mobility Management Entity)、S-GW (Serving Gateway)及 P-GW (Packet Data Network Gateway)。 MME為核心網路的管理者；處理 Control-plane 訊息，如移動性、身分認證等安全性管理 S-GW管理系統內User-plane訊息；包括Routing/Forwarding 資料封包、Mobility Anchor(處理 eNB 間的換手)； 用以做 LTE 與 3GPP 系統間(如 2G/3G 等)的相容切換。 P-GW負責User-plane 的外部連線(Internet)；用以做LTE與非3GPP系統(如WLAN、WiMAX等)的相容切換。 eNB 會透過 S1介面與核心網路通訊，S1 介面亦分成 Control-plane 的 S1-MME介面(與 MME 連結)和 User-plane 的 S1-U 介面(與 S-GW 連結)， S1-MME介面在傳輸層使用 SCTP (Stream Control Transmission Protocol)，此協議結合了 TCP 與 UDP 的特點，具有不錯的可靠性與高效性。 S1-U 介面較特別之處在於GTP-U (GPRS Tunneling Protocol for the user plane) ，User-plane 的 封包會以穿隧的方式在UE與P-GW 間傳輸，中間經過 eNB、S-GW。用戶可使用 IPv4, IPv6 或 PPP 在核心網路中傳送。

80 VoLTE 網路架構 LTE-Uu 可分為三層:
Layer 3: NAS (Non-Access Stratum) 是做移動性管理、Bearers 設定、用戶的附著與認證等。 RRC (Radio Resource Control) 是做無線資源的管理與 RRC 之下各層的設定。 Layer 2: PDCP (Packet Data Convergence Protocol)用來處理標頭壓縮及加密動作。 RLC (Radio Link Control)包含了重傳機制及為了配合下層 MAC 的各個 frame 大小進行封 包的分割與重組。 MAC (Medium Access Control)則主要做 QoS 的排程動作。 Layer 1: PHY (Physical)將資料轉為實體訊號發送。 為了減少與核心網路溝通的延遲，除了移動性管理UE需與核心網路通訊外， 其他層皆在UE 與 eNB 間通訊。

81 VoLTE 網路架構 MME主要任務是： 接入控制: 移動性管理: 會話管理功能: 網域選擇功能: 用戶身份識別、驗證、加密和許可控制
對UE當前位置和對UE連結狀態的跟蹤和記 錄 為UE建立一个或多個PDN連接 支持UE在LTE系统内漫游 控制UE在2G/3G網路和LTE網路間的重選、 切换 會話管理功能: 管理EPC承載的建立、修改和釋放 與2G/3G網路交互操作時，完成EPC承載與 2G/3G PDP上下文的有效映射 網域選擇功能: 根據APN和使用者簽約資料選擇合適路由 為UE選擇合適的PGW、SGW和目的 MME(S1切換) 當UE切换到2G/3G網路時，為UE選擇SGSN IMS IMS PDP上下文，是指PDP啟動GGSN之間建立鏈路的過程。在LTE中的上下文主要是指EPS承載上下文，是建立UE與P-GW之間的連接鏈路的過程。上下文會話的建立包含四部分:當終端與MME之間要通信時，需要先建立上下文會話請求，這是由MME發起的。在物件的啟動過程中創建上下文，物件被配置為要求某些自動服務，如同步、事務、即時啟動、安全性等等。具體來說就是各個變數和資料，包括所有的寄存器變數、進程打開的檔、記憶體資訊等。在該UE未分離前，這些資訊都是必須要保存下來。 一個業務GPRS支撐節點（Serving GPRS Support Node，簡稱：SGSN）負責在它的地理位置服務區域內從移動台接收或向其發送數據包。它的任務包括數據包路由和傳輸、可移動性管理（mobility management，附著/分離和位置管理）、邏輯鏈路管理（logical link management）以及鑒權和計費功能。SGSN的位置暫存器存儲所有在它上面註冊的GPRS用戶的位置信息（例如，當前蜂窩、當前VLR）和用戶概要（例如IMSI、包數據網絡中所使用的地址）。

82 VoLTE 網路架構 S-GW是使用者層面的“代理伺服器”管理在2G，3G和LTE的移 動存取。 S-GW的主要任務是：
管理在eNodeB間移動和切換; 管理2G/3G和LTE之間的移動; 協助eNodeB間切換的數據轉發; 封包繞送和轉發; 合法監聽漫遊; 數據漫遊計費。 IMS IMS IMS

83 VoLTE 網路架構 P-GW是3GPP和非3GPP之間的用戶 平面訪問。 P-GW主任務是：
前往PDN（即互聯網/企業內部網/運營服務） 的閘道器; 封包路由和轉發; 承載管理; 客戶端的IP地址分配; 策略和計費執行功能; 離線/在線數據的計費; 封包過濾; 合法監聽; 管理3GPP和非3GPP接入系統之間的移動 PCRF選擇功能 IMS IMS IMS

84 VoLTE 網路架構 HSS(Home Subscriber Server)包含用戶訂閱相關數據
存儲使用者簽約資訊、使用者驗證、位置資訊管理等 使用者資料包括： 主要是IMSI、MSISDN、IMEI等 IMSI: SIM卡ID MSISDN: phone number IMEI: mobile phone ID EPS APN簽約資訊，主要是APN簽約上下文； QOS簽約資料，能支持3GPP TS23.203定義的最大速率； PDN Type； 位置相關資訊 使用者計費相關資訊 驗證資訊，以及使用者驗證演算法標識 PCRF(Policy and Charging Rules Function)提供計費和策略規則給P-GW，轉換從 應用服務器(AS)來的應用層會話數據(例如，SDP的內容)到3GPP特定參數。 International Mobile Subscriber Identity (IMSI)每一個用戶所擁有的獨特ID，通常寫在SIM卡中 The IMEI is the mobile phone‘s identity which is burned into the phone. The IMSI is the identity of the SIM card. And MSISDN is the phone number APN（Access Point Name），即“接入點名稱”，是您在通過手機上網時必須配置的一個參數 HSS中，用戶手機在發起分組業務時也可向網路側MME（Mobility Management Entity，移動管理實體）提供APN。MME根據使用者所提供的APN，通過DNS（Domain Name Server，功能變數名稱伺服器）進行功能變數名稱解析，從而獲取到PGW的IP地址，將用戶接入到APN對應的PDN中。 MME存儲APN與PGW位址對應表，通過不同的APN選擇不同的PGW。APN的獲取方式如下： 用戶提供 用戶定制 MME指定 用戶可以啟動多個PDP上下文，每個PDP上下文與一個APN相聯繫。使用者選擇不同的APN的目的就是通過不同的PGW選擇外部網路。 APN需要通過DNS進行功能變數名稱解析才能獲取PGW或外部網路節點的真實的IP位址。 GPRS專網系統終端上網登錄伺服器平臺的流程為： 1）用戶發出GPRS登錄請求，請求中包括由運營商為GPRS專網系統專門分配的專網APN； 2）根據請求中的APN，SGSN向DNS伺服器發出查詢請求，找到與企業伺服器平臺連接的GGSN，並將用戶請求通過GTP隧道封裝送給GGSN； 3）GGSN將使用者認證資訊（包括手機號碼、使用者帳號、密碼等）通過專線送至Radius進行認證； 4）Radius認證伺服器看到手機號等認證資訊，確認是合法使用者發來的請求，向DHCP伺服器請求分配用戶位址； 5）Radius認證通過後，由Radius向GGSN發送攜帶使用者位址的確認資訊； 6）用戶得到了IP位址，就可以攜帶資料包，對GPRS專網系統資訊查詢和業務處理平臺進行訪問。 MME->SGSN PGW->GGSN

85 VoLTE 網路架構 在IMS(IP Multimedia subsystem)中有四種不同類型的呼叫會話控制功能 （CSCF）：
proxy call session control function（P-CSCF）， serving call session control function（S-CSCF）， interrogating call session control function（I-CSCF）， emergency call session control function（E-CSCF）。

86 VoLTE 網路架構 P-CSCF（Proxy Call Session Control Function 代理會話控制功能）:
是IMS中用戶的第一個聯繫點（在信令平面），從SIP的角度來看，它是一個 出站/入站的SIP代理伺服器，所有的SIP信令，無論是來自使用者設備UE，還 是發送給UE的，都必須經過P-CSCF。 UE使用本地端CSCF發現機制可以獲得P-CSCF的位址。 P-CSCF將驗證請求轉發給指定的目標，並且處理和轉發回應。P-CSCF的任 務包括： SIP壓縮，IPSec的安全相關性，與PCRF互動，網路地址轉換（NAT）控制和緊 急會話偵測。 當業者提出計費策略，P-CSCF轉傳會話和媒體相關訊息給PCRF。PCRF根據所 接收到的訊息，得到授權的IP QoS信息，並且傳遞計費規則到接入閘道器（例 如，P-GW）。 此外，經由PCRF和P-CSCF，IMS能夠提供計費相關資訊到接入網路，也可以 接收來自接入網路的計費相關資訊。

87 VoLTE 網路架構 S-CSCF（Serving Call Session Control Function, 服務會話控制功能）: 是IMS的核 心所在，它為UE進行會話控制和註冊請求，在同一個運營商的網路中，可以有多 個S-CSCF。 S-CSCF負責註冊流程，路由決策和維護會話狀態和儲存服務設定。當用戶發送一個註 冊請求，它將被送到S-CSCF，S-CSCF從HSS下載認證資料。根據認證資料，S-CSCF 對UE產生認證請求，並在接收到回應後，驗證它的正確性。之後，用戶能夠發起並接 收IMS服務。 S-CSCF從HSS下載服務設定，該服務設定包含S-CSCF需要提供的媒體類型。 當S-CSCF接收經由P-CSCF的UE請求，進一步發送請求之前，它需要決定是否要通知 AS，要連接哪個AS。跟AS溝通之後，S-CSCF繼續傳送會話或者轉送到其他網域（CS 或另一個IP網路）。 當UE使用MSISDN號碼，S-CSCF轉換MSISDN號碼為SIP URI的格式。

88 VoLTE 網路架構 I-CSCF（Interrogating Call Session Control Function 協商會話控制功能）: I-CSCF是一個運營商網路內部的接觸點，所有與這個網路運營商的使用者連接都要經過 這個實體。在一個網路中可以有多個I-CSCF。I-CSCF有三個任務: 從HSS獲取下一個節點的名稱（如S-CSCF或AS）。 請求路由到S-CSCF或AS。 E-CSCF (Emergency Call Session Control Function 緊急呼叫會話控制功能): E-CSCF是一個專門的功能，處理IMS緊急請求，例如119，火警和急救。 E-CSCF的主要 任務是選擇一個急救中心來傳送緊急請求。 選擇標準是根據主叫用戶的位置和可能的類型的緊急情況（如警察，海岸警衛隊）。一 旦適當的緊急中心選擇出來，E-CSCF將請求路由到緊急中心。

89 VoLTE 網路架構 IMS註冊流程 HSS LTE/EPC IMS 5.終端IP地址+ P-CSCF分配
3.位置登錄(供VoLTE使用的APN DL) 1.電源ON 9a.登錄+認證手續 9c.服務訊息 4.創建VoLTE用承載 2.聯結請求 VoLTE終端 eNodeB MME/SGW PGW P-CSCF S-CSCF AS 7.設定完成 (P-CSCF位址) 6.載體回應 (P-CSCF位址) 8. IMS登錄請求 9b. 認證手續 連接過程完成之後，終端發起IMS註冊過程（圖3⑧），其中，在所述登記請求信號的終端是終端標識符IMEI（國際移動設備識別碼）和IMS語音服務示值：必須（ICSI IMS通信服務標識符）。這些信息將被用於諸如業務控制和計費控制。 則IMS註冊請求經由P-CSCF的終端信號到達S-CSCF，在S-CSCF執行對HSS（圖3⑨a），在S-CSCF註冊過程，其中，S-CSCF獲取用於用戶認證所需的信息，執行與終端（圖的認證過程。 3⑨b）。認證成功後，S-CSCF在完成下載（圖3⑨c）保持從HSS的用戶的服務控制信息後，通過通知登記完成到終端（圖3⑩），IMS註冊控制結束。 10. IMS登錄完成 SIP用承載 LTE/EPC IMS

90 語音編碼 AMR(Adaptive Multi-Rate)，主要用於移動設備的音訊，壓縮比比較大，用於人 聲，效果較好。
2/3使用的語音編碼格式為AMR-NB，語音頻寬範圍：200Hz-3400Hz，8KHz取樣速率 VoLTE使用AMR-WB編碼，提供語音頻寬範圍達到50Hz-7KHz，16KHz取樣速率，用 戶可主觀感受到話音比以前更加自然、舒適和易於分辨。 AMR-NB共有16種編碼方式，0-7對應8種不同的編碼方式，8-15用於噪音或者保 留用。 AMR-WB同樣也有16種語音編碼，目前主要使用2和8兩種 Frame Type Mode Indication Mode Request Frame content (AMR mode, comfort noise, or other) AMR 4,75 kbit/s 1 AMR 5,15 kbit/s 2 AMR 5,90 kbit/s 3 AMR 6,70 kbit/s (PDC-EFR) 4 AMR 7,40 kbit/s (TDMA-EFR) 5 AMR 7,95 kbit/s 6 AMR 10,2 kbit/s 7 AMR 12,2 kbit/s (GSM-EFR) 8 - AMR SID 9 GSM-EFR SID 10 TDMA-EFR SID 11 PDC-EFR SID 12-14 For future use 15 No Data (No transmission/No reception) Frame Type Mode Indication Mode Request Frame content (AMR-WB mode, comfort noise, or other) AMR-WB 6.60 kbit/s 1 AMR-WB 8.85 kbit/s 2 AMR-WB kbit/s 3 AMR-WB kbit/s 4 AMR-WB kbit/s 5 AMR-WB kbit/s 6 AMR-WB kbit/s 7 AMR-WB kbit/s 8 AMR-WB kbit/s 9 - AMR-WB SID (Comfort Noise Frame) 10-13 For future use 14 speech lost 15 No Data (No transmission/No reception)

91 RoHC強健性標頭壓縮協議 在LTE中，為了提供語音業務接近電路交換網路的效率，必須對IP/UDP/RTP標 頭進行壓縮。
規定PDCP子層支援強健性標頭壓縮協議(ROHC, Robust Header Compression)來進行 標頭壓縮，並且同時支持IPv4和IPv6。 對於一個含有32 Byte有效負載的VoIP傳輸來說，RTP、UDP和IPv6標頭合併有 60 Bytes，而RTP、UDP和IPv4標頭有40 Bytes，即增加188%和125%的開銷。 採用ROHC壓縮技術，標頭可壓縮成4～6個Bytes，即12.5%～18.8%的相對開銷。 VoIP封包僅在初次傳輸時，發送資料標頭的靜態資訊（如IP位址等），後續不 再重複發送，其他資訊可由上下文推算（如SN號碼），IP標頭壓縮可大大降低 開銷，提高資料業務輸送量。 在LTE中，為了在封包交換網路(Packet Switch Network)提供語音業務且到達接近常規電路交換網路的效率，必須對IP/UDP/RTP標頭進行壓縮。採用標頭壓縮技術能有效提高頻譜利用率。在LTE系統中，規定PDCP子層支援強健性標頭壓縮協議(ROHC, Robust Header Compression)來進行標頭壓縮，並且同時支持IPv4和IPv6。 對於一個含有32 Byte有效負載的VoIP傳輸來說，RTP、UDP和IPv6標頭合併有60 Byte，而RTP、UDP和IPv4標頭有40 Byte，即增加188%和125%的開銷。為了解決這個問題，在LTE系統中PDCP子層採用ROHC標頭壓縮技術，標頭可壓縮成4～6個位元組，即12.5%～18.8%的相對開銷，從而提高了通道的效率和分組資料的有效性。 封包僅在初次傳輸時，發送資料標頭的靜態資訊（如IP位址等），後續不再重複發送，其他資訊可由上下文推算（如SN號碼和IP-ID號都是以1為單位遞增），IP標頭壓縮可大大降低頭開銷，提高VoLTE語音使用者容量，提高資料業務輸送量，增強邊緣覆蓋。 PDCP(ROHC, Security) RLC(segmentation/Concatenation) MAC(Scheduling, Multiplexing, HARQ) PHY

92 TTI bundling (1/4) LTE中實體層調度的基本單位是1ms，小時間間隔可以使得LTE中應用的時間延遲較小。然 而，在某些區域邊緣，覆蓋受限的情況下，UE由於受到其本身發射功率的限制，在1ms的 時間間隔內，可能無法滿足資料發送的誤塊率（Block Error Rate, BLER）要求。 例如長度為33個位元組的VoIP封包（包含L1/L2層的標頭資訊）在1ms的時間內發送，實體層的速 率需要達到312kbps。對於某些情況下的LTE社區邊緣可能無法達到這一要求。 對於上述情況的VOIP封包，LTE中可以在RLC層對其進行分割（Segmentation），對於每一 分段採用獨立的HARQ(Hybrid Automatic Repeat Request)分別進行傳輸。 HARQ = FEC + ARQ。 FEC(Forward Error Correction)指的是添加在資料中，並且可以糾錯的那些FEC code，比如 Reed- Solomon 碼 (RS code)、Hamming(7,4) 碼； 傳統的ARQ只在資料末添加一點redundant bits，作為偵錯碼，比如 cyclic redundancy check (CRC)、 同位元檢查(parity bit)。 HARQ就是資料連同FEC code, parity bit 一起傳，如果parity bit告知內有錯誤，即用FEC code糾正錯 誤，糾正失敗的話才採用ARQ的機制，因此ARQ在HARQ中可算是一備案，明顯的，用FEC code需 要多傳比較多的bit，因此需付出代價。 正常的HARQ機制下，如果接收端（eNodeB）解碼資料失敗，eNodeB就會回覆NACK或者 DTX(Discontinuous Transmission)消息，然後UE會重新發送資料，如此一來，資料交付就會得到保 證。然而，這種重傳機制會引起一定的延遲（比如，在FDD中，單個重傳會導致8ms的延遲）。這 種延遲在某些即時通信（如VoLTE）中會帶來很差的用戶體驗。此外，RLC層分割的方法會帶來 額外的標頭開銷和系統控制信令的開銷。

93 TTI bundling (2/4) TTI(transmission time interval) Bundling 是3GPP在LTE 網路針對VoIP服務所提出改善涵蓋的功 能。 當基地台偵測到手機終端已無法再增加發射功率而接收越來越差時，導致封包遺失率增 加，可對於上行的連續TTI進行綁定，分配給同一UE，這些上行的TTI中，發送的是相同 內容的不同RV(redundancy versions)版本。 可以提高資料解碼成功的機率，提高LTE的上行覆蓋範圍，代價是增加了一些時間延遲。 正常情況下，當UE收到eNodeB發來的一個授權（DCI 0）後，就會在PUSCH(Physical Uplink Shared CHannel)發送（接收到這個授權後的4ms) 連續4個子訊框。 相對於HARQ，當UE處於社區邊緣時，TTI bundling可以連續重複發送4個相同的VoIP封包， 可以增加接收端資料接收的準確性。 當這4個捆綁的封包傳送完成後，將會發送一個聯合的ACK/NACK。

94 TTI bundling (3/4) 系統根據UE功率餘量回報（power headroom）來決定是否啟動TTI bundling。UE功率餘量表示當前UE功率離最大功率限制還有多少空間，由UE通知eNodeB，eNodeB在某個給定的時間段內，通過計算UE可用功率是否低於某個門檻值（例如：發射功率已接近UE的最大發射功率，但SINR值依舊很低），從而決定是否使用TTI bundling功能。 TTI Bundling模式的配置，是通過上層信令中的參數ul-SCH-Config:ttiBundling來進行的。觸發條件可以是UE上報了上行功率受限等。 TTI Bundling 模式只對UL-SCH(Uplink Shared Channel)有效。 上行子訊框0、1、2、3綁定在一起，通過HARQ Process 0進行傳輸。子訊框0到3分別發送相同傳輸塊的不同冗餘版本RV0，RV1，RV2，RV3。eNodeB有4ms的處理時間（包括傳輸延遲）。在子訊框7，eNodeB會通過PHICH來發送ACK或NACK。HARQ Process 0對應的TTI Bundling 將從子訊框16開始進行重傳。 對於普通非綁定的上行子幀，其重傳的時間是8ms，對於綁定的上行子幀，其重傳的時間為16ms。 功率餘裕回報(Power Headroom Report)告知用戶端可用功率的範圍 FDD模式下，非TTI Bundling的上行訊框，存在8個HARQ的進程。TTI Bundling的HARQ進程有4個。

95 TTI bundling (4/4) TTI Bundling將同一個封包在連續不同的TTI 發送，不同TTI 中的同一個封包 則使用不同的偵錯/除錯位元(error detection/error correction bits)，優點是可節 省封包重傳機制所需的大量的標頭位元。 採用TTI bundling有兩個好處。 第一，避免過多的HARQ重傳，造成一定的延遲（比如，在FDD中，單個重傳會 導致8ms的延遲）。這種延遲在UE處於社區邊緣時，某些即時通信（如VoLTE） 中會帶來很差的用戶體驗； 第二，四個連續訊框可以立刻提高接收成功率，4個連續重複的封包更有利於接收 端解碼，相當於減少了系統對社區邊緣的最小信噪比要求。

96 SPS 半持續調度 (1/4) Semi-Persistent Scheduling支援VoIP業務。
語音封包的尺寸小，發送頻繁；而LTE發送數據封包時，上下行鏈路都 要分配物理資源塊（PRB），就會消耗更多的無線資源。 在語音對話中，每隔20ms發送一個語音包，在靜默期沒有語音數據傳 輸, 只有由於背景噪聲，就取消PRB資源分配。 在上行方向，可以定義接收到多少個空數據包來確定取消資源分配；在下行方向，發送無線資源控制（RRC）消息來取消。

97 SPS 半持續調度 (2/4) LTE與之前的無線系統，最大的差別就是共用資源。
當UE需要發送上行資料時，UE向eNodeB發送SR (Scheduling Request）請求，eNodeB收到SR請求後，根據網路的資源情況， 向UE發送上行調度授權。 UE獲得了相應的UL Grant，UE將BSR(緩衝區狀態報告)給eNodeB， 告訴eNodeB現在有這麼多資料需要發送出去。eNodeB根據BSR 資訊，並結合整個網路的狀況，分給UE資源，通過 PDCCH(Physical Downlink Control Channel)的UL Grant告訴給UE。 UE進行相應的調度(包括通道優先順序等)，將資源發送出去。 動態調度可以將資源有效利用，分配給其他的UE。整個系統的資 源利用率就有很大的提升。但是，底層的信令通訊很多，這樣也 會佔用一部分資源。

98 SPS 半持續調度 (3/4) 語音，通常是20ms一個資料封包。不需要每次都進行PDCCH的信令溝通。如 果將資源固定分配，則傳送過程中不再需要將相應的資源資訊通知UE，這樣 就可以節省底層的信令的資訊。 VoIP業務的狀態分為啟動期和靜默期，在啟動期，資料封包的發包間隔為20ms， 可以由一條信令分配頻域資源，以後每隔20ms就“自動”用分配的頻域資源傳 輸新來的封包。重傳封包由於其不可預測性，所以動態的調度每一次重傳，因 而叫“半”持續調度。 SPS週期調度時不需要每次都發送PDCCH，理論上可以提高系統使用者容量。 SPS調度方式可以減少控制通道的資源開銷和延遲抖動。 每個封包的大小固定為35~47 Byte。暫態時的封包大小由於沒有壓縮，封包大 小為92 Byte，在靜默期，封包的發送間隔為160ms，每個封包的大小固定為 10~22Byte，這樣規律的發送方式適用SPS調度。 SPS相當於給用戶分配了固定的PDSCH，可以減少PDCCH佔用數，但會增加 PDSCH佔用數，是否開啟需對兩者進行權衡。 在標準中，VoIP業務不能同時採用SPS調度和上行TTI bundling，但可僅針對邊 緣用戶使用TTI bundling。 PDSCH:主要用來乘載Data的Channel PDCCH:用作分配資源或是指示其他control資訊的Channel

99 SPS 半持續調度 (4/4) 參數 參數值 時間週期 語音包傳輸時間間隔: ~20ms 語音靜默期: ~160ms 速率
AMR-NB :12.2kbps  AMR-WB: 23.85kbps 負載淨荷（非壓縮） 語音包大小: ~32 bytes+ IP 包頭(IPV4 40 bytes， IPV6 60bytes)

100 QoS of LTE Voice Services

101 LTE QoS EPS中，與QoS控制有關的是承載(Bearer)，即相同承載上的所有資料流將獲得相同的QoS 保障（如調度策略，緩衝佇列管理，鏈路層配置等），不同的QoS保障需要不同類型的 EPS承載來提供， 承載的QoS是由eNodeB來控制的，每個承載都有相應的QoS參數QCI（QoS Class Identifier）。 根據QoS的不同，EPS Bear可以劃分為兩大類：GBR(Guaranteed Bit Rate)和Non-GBR。 GBR:即使在網路資源緊張的情況下，相應的bit rate也能夠保持。 MBR(Maximum Bit Rate)參數定義了GBR Bear在資源充足的條件下，能夠達到的速率上限。MBR的值有可 能大於或等於GBR的值。 Non-GBR指的是在網路擁擠的情況下，需要承受降低速率的要求，Non-GBR承載不需要佔用固定 的網路資源，可以長時間地建立。 LTE中共有9種不同的QCI， 在VoLTE業務中主要用到了QCI 1、QCI 2、QCI 5 普通的資料業務主要是QCI 8/9 IMS信令使用QCI 5 語音業務使用QCI 1、QCI 5、QCI 8/9 視頻電話業務使用QCI 1、QCI 2、QCI 5、QCI 8/9。

102 LTE QoS QCI 1 GBR 2 100 ms 10-2 VOIP 4 150 ms 10-3 電話會議, 會話視頻 (直播流媒體)
資源類型（Resource Type） 優先順序（Priority） 延遲 （Packet Delay） 封包遺失率（Packet Error Loss rate） 典型業務（Example Services） 1 GBR 2 100 ms 10-2 VOIP 4 150 ms 10-3 電話會議, 會話視頻 (直播流媒體) 3 50 ms 即時線上遊戲, 即時工業監控 5 300 ms 10-6 非會話視頻(緩衝流媒體) Non-GBR IMS 信令 6 視頻(緩衝流媒體) 7 視頻(直播流媒體), 話音業務 互動式遊戲 8 , MSN, QQ, WWW P2P檔共用 9

103 語音品質分析 主動式評價方法主要由ITU標準組織定義 被動式語音質量評價方法主要有兩種。
PESQ和POLQA是目前仍然廣泛使用的語音質量評價方法 ITU-T建議P.830描述了對語音的主觀評定方法-MOS（Mean Opinion Score）方法。 特定的發話者與聽話者在特定的環境下，通過收集測試者在各種不同情景下的主 觀感受，根據分析法則得出該語音的品質。P.830對測試的要求非常嚴格，所有的 操作都要嚴格地服從操作流程。 PESQ演算法(ITU­T P.862)將話音的頻率、響度等物理特性與人類心理上的感知特 性的對應關用數學模型來模擬主觀評價。提取出的語音特徵都是與主觀感覺直接 相關的。 有如下主要缺點：處理CDMA編碼（如EVRC）不夠準確；在特定的GSM/WCDMA網 路條件下過於敏感；不能處理超寬帶語音信號。 ITU­T於2011年初正式發布為ITU­T P.863標準。主要特點可以支援最新的語音編碼 和網路傳輸技術，用於3G，4G/LTE，VoIP網路時具有更高的準確性，支援超寬帶 （50Hz~14KHz）語音傳輸。 被動式語音質量評價方法主要有兩種。 直接從變化的IP網路參數（如丟包、抖動和延遲）預測語音質量，如R­factor 方法； 由音頻信號測量語音質量（例如編解碼器、回聲），如ITU組織P.563標準。 被動式評價並非真實測量最終用戶的實際體驗，而是通過抓取網路參數或語 音參數通過數學模型“預測”感知語音質量。

104 VoLTE QoS 參數 參數值 頻寬 推薦值: AMR-NB 12.2 kbps 優選值: AMR-WB 23.85kbps MOS值
MOS: ~3.6 desired， ~3.8 preferred  MOS: ~3.8 desired， ~ 4 preferred 封包遺失率 封包遺失率< 0.5% 抖動 抖動 < 50 ms / reception point 延遲 端到端延遲 < 250ms POLQA MOS:提供傳輸品質的數字指示 MOS Quality 5 Excellent 4 Good 3 Fair 2 Poor 1 Bad

105 指標分類 指標名稱 定義 資源佔用類（7） 上行RB數 每秒上行調度RB數/每秒上行實際調度次數*100% 下行RB數 每秒下行調度RB數/每秒下行實際調度次數*100% 上行MCS 每秒上行調度MCS值之和/每秒實際調度次數*100% 下行MCS 每秒下行調度MCS值之和/每秒實際調度次數*100% 上行終端發射功率 每秒內終端發射功率的平均值 GSM通話時長占比 指定時間內終端在GSM制式下的通話時間 / 指定時間內終端總通話時間*100% 呼叫eSRVCC切換占比 發生eSRVCC切換的呼叫次數 / 總呼叫次數*100% 語音品質類（12） MoS MoS輸出的平均意見得分（PoLQA演算法） BLER 初傳BLER （初傳次數-初傳成功次數）/初傳次數*100% 剩餘BLER （初傳次數-多次重傳後成功次數）/初傳次數*100% 語音丟包率 （發送封包數-接收封包數）/發送封包數*100% 抖動 接收端RTP/PDCP層封包延遲時間變化量 呼叫建立延遲 終端發出的第一條隨機接入消息到接收到網路側下發的SIP 180 Ring消息時間差 IP包延遲 從主叫發出到被叫接收的RTP層封包時間差 端到端延遲 主叫端語音編碼器輸入到被叫端解碼輸出的時間差 上行速率 過去一秒內，上行PDCP層發送的總bit數 下行速率 過去一秒內，下行PDCP層接收的總bit數 切換中斷延遲 網內控制面 終端在來源社區收到RRC重配消息指示切換，到終端在目標社區收到RRC重配消息指示切換完成的時間差 網內用戶面 來源社區最後一個PDCP層封包到目標社區接收到的第一個PDCP層封包的時間差 網間控制面 接口 從eNodeB下發Handover Command到終端向BSS發送HO Complete的時間差 核心網 MME向eMSC發送PS to CS Request，到收到PS to CS Complete/Ack的時間差 網間用戶面 來源社區最後一個PDCP層封包到目標社區建立專有通道恢復話音的時間差 話音掛機延遲 主叫端發起BYE Message到收到網路側下發的SIP 200 OK消息差 RRC重建延遲 從終端發生RLF（Radio Link Failure，無線鏈路失敗）的時刻，到終端發出RRC Connection Reestablishment Complete的時刻 KPI指標類（9） IMS註冊成功率 IMS註冊成功次數 /終端開機次數*100% 話音接通成功率 成功完成呼叫次數/終端發起呼叫總數*100% 掉話率 掉話次數/成功建立呼叫次數*100% 網內切換成功率 切換成功次數/切換請求次數*100% eSRVCC切換成功率 eSRVCC切換成功次數/eSRVCC切換嘗試次數*100% 呼叫成功率 呼叫成功次數/EPC發起呼叫請求總次數*100% 平均長保時間 使用者保持通話狀態時間的平均值 緊急呼叫建立成功率 撥打緊急呼叫成功接通次數/總撥打次數*100% 里程掉話比 掉話次數 / 呼叫行駛的里程數（km）*100%

106 VoLTE Call 使用者發出INVITE P-CSCF轉給S-CSCF ◦ S-CSCF對請求進行解析、完成繞徑 轉發請求給請求目標
請求對象接受會談 回應SIP Response 200 OK 請求對象不接受 回應CANCEL訊息

107 VoLTE Call Flow 1.使用者設備生成一個INVITE請求，並把它送到IMS，告知caller設備中QoS的先決條件。
2.P-CSCF回復caller設備“100 Trying”,表示呼叫建立正在進行當中。 3.SIP協定讓IMS去詢問callee設備，是否有能力去接受這個資訊。如果callee設備回復“200 OK”說明該設備有IMS能力。 4. callee設備接收INVITE的請求，包括通信的先決條件聲明，傳輸介質，編碼，協定等。

108 VoLTE Call Flow 5.如果先決條件的機制被支援，P-CSCF將會返回183進度資訊，並將caller設備和callee設備的通信能力進行比較，決定使用的編碼。 6.caller設備告知callee設備PRACK， callee設備返回“200 OK”，雙方使用者設備的EPS承載啟動。 7.caller設備發出UPDATE消息，告知它的先決條件已經滿足。 8.兩邊的使用者設備通過“200 OK”消息得知QoS承載已經建立，目標設備開始響鈴。 9. callee設備發出“180 RINGING”消息給IMS，IMS將其傳給caller設備。 10.當雙方設備接收到“200 OK”消息以後就對其進行確認，完成SIP流程。 183 (Session in process) 用於開啟 (UE1 所希望的 SDP 的) one-way audio path from called end to calling end. 所帶著的 SDP 是 UE2 所希望的 media capacity. 同時要求對方送 PRACK (Provisional Response ACK). PRACK 是 因為 SIP 用 UDP 傳, 為確保對方有收到自己的資料, 所以要求對方送回暫 時性的 response