Trong chương này sẽ trình bày về các kiến thức sau:

 Giới thiệu chung về VoLTE

 IMS và kiến trúc của nó
 Cấu hình EPS bearers trong VoLTE
 Protocols quan trọng trong VoLTE
 Call flow:
 Attach
 IMS Client Registration
 VoLTE call setup – call flow
 VoLTE call termination
 IMS Deregistration
 Các feature cần thiết trong VoLTE
 RoHC
 TTI-Bundling
 SPS
 SRVCC
1. Giới thiệu chung
LTE là mạng “IP-only”, LTE không có mạng lõi CS, trong khi các node
mạng CS được sử dụng cho dịch vụ thoại. Do đó, để triển khai dịch vụ thoại trong
LTE, ta có thể tận dụng các hệ thống đã có (2G, 3G) bằng cách triển khai Circuit-
Switched Fallback (CSFB). Tuy nhiên, về lâu dài, LTE cần hỗ trợ cả voice và data.
VoLTE (Voice over LTE) là giải pháp cho dịch vụ thoại trên 4G – cuộc gọi VoIP
trên LTE. Một trong những ưu điểm nổi trội của VoLTE là cung cấp dịch vụ thoại
chất lượng cao.
2. IMS
2.1. IMS là gì?
 Để có thể cung cấp các dịch vụ thoại trên nền tảng công nghệ VoIP, cần phải
có IMS (IP Multimedia Subsystem).
 IMS là một hệ thống để thực hiện các dịch vụ đa phương tiện qua mạng IP,
cho phép thực hiện các dịch vụ thoại và data đồng thời.
 IMS có thể thực hiện các cơ chế về bảo mật (authentication, authorization,
integrity protection), cơ chế accounting online và offline…
 IMS có một số ưu điểm chính:
 Cấu trúc linh hoạt
 IMS có thể cung cấp dịch vụ cho các thiết bị trên nhiều mạng truy
nhập khác nhau (E-UTRAN, WLAN, UMTS, cable-modem…).
 IMS cho phép cung cấp các dịch vụ nhanh và linh hoạt, tiết kiệm được
chi phí cho operator.
 Hình 12.1. Mô hình kết nối IMS và các mạng khác
2.2. Kiến trúc IMS
 IMS được thiết kế để có thể hỗ trợ lớp điều khiển (Control Layer) cho các
dịch vụ gói (packet based services). IMS được sử dụng độc lập với công
nghệ truy nhập. Trong môi trường đa truy nhập, IMS đảm bảo các dịch vụ
sẵn sàng cho tất cả các mạng truy nhập.
 Các phần tử trong một hệ thống IMS hoàn chỉnh có thể được chia làm 3 nhóm:
 Các phần tử cơ sở dữ liệu (HSS, SLF)
 Các phần tử điều khiển IMS (P-CSCF, I-CSCF, S-CSCF).
 Các phần tử Control Plane Interworking (MGCF, BGCF, SGW).
 Mạng Viettel khi triển khai dịch vụ VoLTE sẽ có đầy đủ các khối chức n ăng
trên, trong đó HSS được dùng chung với HSS (trong Evolved Packet Core)
đang được sử dụng.
 Hình 12.2. Những thành phần chính của IMS
2.2.1. Phần tử cơ sở dữ liệu (Database Elements)
2.2.1.1. HSS (Home Subscriber Server)
 HSS là phần tử cơ sở dữ liệu chính trong IMS.
 HSS được phát triển từ phần tử HLR (Home Location Register). HSS có các
chức năng của HLR (dữ liệu thuê bao và dữ liệu nh ận th ực) và các ch ức
năng khác như Location Register, IMS Service Profile Processing, IMS
Subscription và Authentication Data.
 HSS được truy cập bởi I-CSCF, S-CSCF và các nền tảng bên ngoài. HSS sử
dụng giao thức Diameter với Diameter Multimedia Application Extension.
2.2.1.2. SLF (Subscription Locator Function)
 SLF được truy cập bởi I-CSCF và S-CSCF để lấy dữ liệu người dùng do
HSS lưu trữ khi có nhiều hơn một HSS được sử dụng trong mạng. Việc truy
vấn dữ liệu sẽ chứa ID của user và phản hồi chứa thông tin HSS chứa dữ liệu
đó.
2.3.2. Phần tử điều khiển IMS (IMS Control Elements)
 Các phần tử điều khiển IMS là các node hoạt động trên các flow về tín hiệu
điều khiển. Các node này chịu trách nhiệm cho việc thiết lập, giám sát, hỗ
trợ và giải phóng các session. Các phần tử này được gọi chung là CSCF
(Call Session Control Functions).
 Có 3 loại CSCF:
 S-CSCF
 I-CSCF
 P-CSCF

Hình 12.3. Kết nối giữa CSCF, HSS và các phần tử khác
2.3.2.1. P-CSCF (Proxy – Call Session Control Function)
 P-CSCF là “contact-point” đầu tiên của IMS.
 Tiếp nhận tất cả SIP signalling từ user.
 Thực hiện Policy and Charging Functions.
 Có thể được đặt ở Home hoặc Visited network.
  Ngoài ra P-CSCF còn thực hiện các chức năng:
 Tiếp nhận các yêu cầu thiết lập Emergency Session.
 Thiết lập Security Associations.
 Compress/Decompress bản tin SIP với user.
 P-CSCF chứa PDF (Policy Decision Function), giúp cấp phép cho
việc sử dụng bearer và quản lý QoS.
2.3.2.2. I-CSCF (Interrogating – Call Session Control Function)
 Chức năng chính của I-CSCF là truy vấn HSS để xác định S-CSCF nào sẽ
phục vụ user. I-CSCF forward các bản tin SIP từ P-CSCF đến S-CSCF và
ngược lại.
 I-CSCF thường là một khối “ẩn” trong IMS của home network, mục đích là
để che giấu thông tin bên trong của home network như cấu hình, dung
lượng, topology… khỏi các thiết bị bên ngoài.
2.3.2.3. S-CSCF (Serving – Call Session Control Function)
 S-CSCF là thành phần điều khiển chính trong IMS. S-CSCF chịu trách
nhiệm quản lý các session. S-CSCF đảm bảo kết nối end-to-end cho các user
và dịch vụ bằng cách tương tác với CSCF, SIP server và Application Server.
 S-CSCF đưa ra quyết định xử lý các yêu cầu dịch vụ từ user dựa vào user
profile (cung cấp bởi HSS) và policy của operator, từ đó forward các bản tin
đến các Application Server thích hợp.
 S-CSCF được đặt tại home network, có thể có nhiều S-CSCF trong mạng. S-
CSCF được thêm vào dựa trên năng lực của node hoặc yêu cầu về dung
lượng của mạng và nếu được yêu cầu thì S-CSCF có thể đươc gán các ch ức
năng dành riêng.
2.3.3. Phần tử Interworking
2.3.3.1. MGCF (Media Gateway Control Function)

 MGCF là một media gateway cho phép giao tiếp giữa IMS và CS user. Tất
cả các tín hiệu điều khiển cuộc gọi đến từ CS user được đưa đến MGCF.
 MGCF thực hiện transcoding (chuyển đổi codec, ví dụ: từ EVRC sang WB-
AMR) và chuyển đổi giao thức giữa RTP (Real-time Protocol – trong IMS)
và PCM (Pulse Coded Modulation – trong mạng CS).
 MGCF chuyển đổi các bản tin báo hiệu, chuyển SIP protocol sang BICC
(Bearer Independent Call Control) và ISDN User Part (ISUP) protocol vốn
được sử dụng trong các hệ thống hiện có.
2.3.3.2. BGCF (Breakout Gateway Control Function)
 BGCF có chức năng là chọn điểm “breakout” ra miền CS.
 Điểm “breakout” này có thể trong cùng mạng hoặc ở một mạng khác:
 Nếu trong cùng mạng, BGCF chọn MGCF.
 Nếu ở mạng khác, BGCF forward session đên BGCF ở mạng được chọn.
3. Cấu hình EPS Bearers trong VoLTE

Hình 12.4. Cấu hình EPS Bearer trong VoLTE

 Có nhiều cách để cấu hình EPS Bearers cho IMS tùy thuộc vào việc UE có
dedicated APN hay multi-purpose APN.
  Dedicated APN cho IMS: UE có một kết nối APN riêng cho IMS. Trong
trường hợp này:
 IMS signalling có thể được mang trên Default bearer cho IMS. Vì báo
hiệu có mức ưu tiên cao nên QCI được set bằng 5.
 IMS signalling được mang trên Default bearer cho IMS với QCI = 5.
 Default bearer được thiết lập ngay khi có kết nối PDN và được duy trì
cho đến khi kết nối PDN chấm dứt. Do đó UE luôn có một signalling
bearer dành cho IMS bất khi cần thiết lập một cuộc gọi thoại.
 Ta vẫn có thể sử dụng dedicated bearer cho IMS signalling, tuy nhiên
trong VoLTE chỉ nên sử dụng một default bearer để giảm số lượng
EPS bearer.
 Dedicated bearer cho voice media được set up khi nào có cuộc gọi
thoại. Bearer này có QCI = 1, thích hợp với việc đàm thoại độ trễ
thấp, tỉ lệ lỗi (error rate) 1% và mức ưu tiên là 2.
4. Protocols quan trọng trong VoLTE
4.1. SIP (Session Initiation Protocol)
 SIP được sử dụng trong IMS để quản lý tất cả các vấn đề liên quan đến
session, bao gồm khởi tạo, điều chỉnh và chấm dứt session. UE và mạng
(được xem như client – server) phải sử dụng các tập Request/Response tiêu
chuẩn trong SIP.
 Hình 12.5. Các tiêu chuẩn Request/Response trong SIP
4.2. SDP (Session Description Protocol)
 SDP được sử dụng cùng với SIP để cho phép xác định các đặc tính của
session và media có liên quan.
 SDP được xem như mô hình Offer/Answer trong đó client đưa ra một tập
các đặc tính mà server sẽ phản hồi, sử dụng để khởi tạo và “thương lượng”
các đặc tính của session.
 Có 3 thành phần thông tin chính trong SDP:
 Session description
 Timing description
 Media description
 SDP chứa các thuộc tính (Attributes). Những thuộc tính này có thể được sử
để cung cấp các thông tin bổ sung về configuration và session.
 Bảng 12.1. Attributes trong SDP

5. Call flow
5.1. Tổng quan các quá trình trong VoLTE

Hình 12.6. Tổng hợp các quá trình trong VoLTE

A. UE thực hiện attach, bao gồm RRC connection setup, authentication, các
quá trình bảo mật, PDN connection setup (thiết lập default và optional
 dedicated bearer – khi), trao đổi thông tin về khả năng thực hiện VoLTE của
UE.
B. IMS client registration: thực hiện quá trình xác thực giữa UE và IMS. Hai
bước rất quan trọng trong quá trình này là xác định P-CSCF (qua P-CSCF
discovery) và đăng ký UE với IMS.
C. Quá trình VoLTE call setup diễn ra sau khi UE đã thực hiện Attach và IMS
registration, đây là quá trình UE thực hiện cuộc gọi VoLTE. Quá trình này
bao gồm tương tác giữa IMS core với LTE core để thiết lập VoLTE media
(chọn lựa codec), thiết lập dedicated EPS bearer (nếu cần thiết), xác định
QoS, và cảnh báo (đổ chuông) UE cả 2 phía.
D. VoLTE call release: giải phóng, kết thúc cuộc gọi.
E. IMS Client deregistration.
5.2. Attach

Hình 12.7. Quá trình Attach

 Loại attach và UE settings trong VoLTE

 Loại attach: Combined Attach – UE có thể attach vào cả mạng 4G và 3G.
 Voice Domain Preference: Ưu tiên IMS PS Voice, tiếp theo là CS Voice.
 UE Usage Setting: Voice Centric.
 Tổng hợp quá trình Attach như sau:
 1. UE đọc thông tin hệ thống (SIB,
MIB), camp vào cell.
2. UE thực hiện RACH và RRC
Connection.
3. UE gửi Attach request
4. UE và network thực hiện các
quá trình xác thực
(Authentication) và bảo mật
(Security).
5. UE và network trao đổi các
thông về UE capability.
6. eNB cấu hình SRB, default
bearer và measurement.
7. Quá trình Attach Accept và
active default bearer.

Hình 12.8. Các bản tin trong quá trình Attach

5.2.1. Camp vào cell, đọc thông tin hệ thống, RACH

- UE camp thành công vào cell,

đọc thông tin hệ thống (MIB,
SIB)
- UE thực hiện RACH với cause
là “Connection Request”

5.2.2. RRC Connection Setup

- UE gửi RRC Connection Request

với UE-ID là một số ngẫu nhiên và
establishmentCause là mo-
Signalling

- RRC Connection Setup từ

network thiết lập SRB1 và Radio
Resource Configurations.
5.2.3. Attach request

ATTACH Request chứa:

- Attach type: Combined attach
- UE Usage setting: Voice centric
- Voice Domain Preference: IMS
PS Voice preferred, CS Voice as
secondary

5.2.4. UE Capability Exchange

Các thông số VoLTE được trao đổi

trong bản tin UE EUTRA
Capabilily gồm:
- PDCP:
+ RoHC profile được hỗ trợ
+ Số lượng tối đa RoHC Context
Sessions
- FeatureGroupIndicator
 FGI gồm 32 bit, mỗi bit tương ứng với một feature nhất định.

Bảng 12.2. Mô tả một số chức năng quan trọng các bit FGI

Hình 12.9. Một số chức năng tương ứng của các bit FGI
5.2.5. RRC Connection Reconfiguration

Qua RRC Connection

Reconfiguration, mạng sẽ cấu hình:
- Các feature RAN liên quan đến
VoLTE.
- Cấu hình cho việc đo đạc.
- SRB2 (cho NAS signalling).
- Default bearer.
5.2.6. Attach accept

Attach accept chứa các thông tin:

- Active default bearer context
request
- PDN address
- APN name
- P-CSCF address
- IMS Voice and PS support
indicator

Attach accept còn chứa EPS network feature support IE, thông tin này chỉ ra
các feature nhất định có được hỗ trợ bởi mạng hay không. Trong số các feature
này, IMS Voice over PS session indicator (IMS VoPS) báo hiệu rằng mạng hỗ trợ
VoLTE.

Hình 12.10. EPS network feature support

5.2.7. Attach complete

Attach complete chứa thông tin xác

nhận Active default bearer context

5.3. IMS Client Registration

Hình 12.11. Quá trình IMS Client Registration

 UE thực hiện quá trình IMS Client Registration (IMS Registration) để đăng
ký với IMS.
 Sau khi hoàn tất, UE và IMS sẽ có các thông tin về nhau, đặc biệt là public
user identities và registration state.
5.3.1. Tổng quan các quá trình xảy ra trong IMS Client Registration

Hình 12.12. Các bước trong quá trình IMS Client Registration (1)

 UE gửi Registration Request đến P-CSCF (UE đã xác định được địa chỉ IP
của P-CSCF trước đó).
 P-CSCF xác định I-CSCF và forward Registration Request đến đó.
 I-CSCF chọn S-CSCF dựa trên thông tin từ HSS.
 Khi nhận được Registration Request, S-CSCF tiến hành xác thực UE qua
Authentication Challenge.
 Vieet them
 Hình 12.13. Các bước trong quá trình IMS Client Registration (2)

 UE gửi phản hồi với Authentication Response. S-CSCF so sánh, kiểm tra
thông tin trong Authentication Response, nếu trùng khớp với thông tin trong
HSS, UE được xác thực thành công, S-CSCF đăng ký UE public identity
đồng thời cập nhật thông tin vào HSS.
 S-CSCF gửi ACK tới UE để xác nhận quá trình IMS Registration thành
công. Thông tin xác nhận này còn chứa Path information (địa chỉ P-CSCF và
S-CSCF dùng cho các tương tác sau này).
5.3.2. Chi tiết các bản tin quan trọng trong quá trình IMS Registration
*P-CSCF Discovery
 UE phải xác định P-CSCF trước khi tiến hành quá trình IMS registration.
 UE có thể nhận biết địa chỉ IP của P-CSCF qua:
 Được cung cấp bởi NAS qua Protocol Configuration Options (giải pháp
tối ưu nhất)
  DHCP
 Được cấu hình trước (được cung cấp bởi ISIM)
 Trường hợp thông thường, UE nhận biết được địa chỉ IP của P-CSCF qua
quá trình Attach:
 Trong bản tin Attach Request, UE gửi P-CSCF Address Request.
 Trong bản tin Attach Accept, UE được cung cấp địa chỉ IP của P-CSCF
để sử dụng trong quá trình IMS Registration.

Hình 12.14. Attach Request và Attach Complete

Hình 12.15. Các bản tin chính trong quá trình IMS Registration
5.3.2.1. SIP Register Request

- Sau khi Default bearer được thiết

lập và UE nhận xác định được địa chỉ
của P-CSCF, UE gửi SIP:REGISTER
request tới P-CSCF để tiến hành
đăng ký với IMS core.

- REGISTER request chỉ chứa

header, không chứa message body.

Hình 12.16. Bản tin SIP REGISTER

Một số thông tin quan trọng trong bản tin SIP REGISTER được mô tả trong
bảng sau:
Header field Mô tả
<Method><URI><SIP Version>
 Method: REGISTER
Request-line
 URI: đích đến của request
 SIP version: 2.0
From (f) ID của bên khởi tạo REGISTER request (MO)
Sử dụng trong trường hợp có nhiều request được gửi từ một
tag
UE
ID của user sẽ đăng ký - đồng nhất với “From” header (khi
To (t)
UE gửi SIP:REGISTER)
 CSeq Gồm 1 sequence number và một method. CSeq được khởi
(Command tạo lúc bắt đầu cuộc gọi và tăng lên mỗi khi có một request
Sequence) mới trong cùng dialog
ID của cuộc gọi, tất cả các bản tin trong cùng session có
Call-ID (i)
cùng Call-ID
MO có thể nhận Response qua địa chỉ này.
Via (v) Cấu trúc: SIP/2.0/UDP <IP address>:port;
branch=<identifier>
Giới hạn số “bước nhảy” một request có thể đi qua để tới
Max-Forwards đích. Giá trị này được tăng lên qua mỗi lần nhảy loop
detector
Contact (m) Địa chỉ IP, port và ID thiết bị (duy nhất) của MO UE
P-Access- Chỉ ra RAN đang được sử dụng để gửi request
Network-Info
Content length Kích thước của message body [byte]. Với bản tin
(l) REGISTER thì l=0
Chứa các thông tin như: Authentication scheme, username,
Authorization
realm (authentication server)
Khoảng thời gian mà REGISTER request còn hiệu lực [s].
Expires
UE cần re-register trong khoảng thời gian này

Bảng 12.3. Các header-field trong SIP REGISTER request

5.3.2.2. SIP: 401 Unauthorized

- Để xác thực UE, S-CSCF gửi

phản hồi với bản tin 401
Unauthorized.

- 401 Unauthorized chứa các tham

số dùng cho việc xác thực.
 Hình 12.17. Bản tin “401 Unauthorized”

Bảng sau mô tả các tham số xác thực trong bản tin 401 Unauthorized:

Tham số Mô tả
Authentication Cơ chế xác thực
Scheme
Server thực hiện việc xác thực, thường chung setting với
realm
REGISTER request
“Challenge” tạo bởi mạng, chứa AUTH và RAND. UE sử
nonce
dụng AUTH để xác thực với mạng và RAND để tạo response
opaque UE sẽ gửi lại cho server (không đổi) ở bản tin request thứ hai.
algorithm Thuật toán sử dụng
Quality of protection: auth (authentication) hoặc auth-int
qop
(Authentication and Integrity)

Bảng 12. Các tham số xác thực trong bản tin 401 Unauthorized
5.3.2.3. Second Register request

REGISTER request thứ hai tương tự

như REGISTER request ban đầu,
ngoại trừ:
- CSeq được tăng lên
- Authorization header được thêm

Hình 12.18. Bản tin Second REGISTER request

5.3.2.4. SIP: 200

Mạng gửi SIP: 200 (OK) để xác

nhận quá trình IMS Registration
hoàn tất.
5.4. VoLTE Call setup - Call flow

Hình 12.19. VoLTE call setup

Hình 12.20. VoLTE call setup call flow

5.4.1. SIP: INVITE
 Sau khi lựa chọn được codec, MO UE gửi SIP INVITE tới MT UE qua IMS
để khởi tạo session. SIP INVITE chứa thông tin về SDP.
 SDP được xem như một mô hình Offer/Answer:
 Client đưa ra các đặc điểm để server phản hồi.
 Answer không đảm bảo sẽ mang những đặc điểm như client đưa ra.

Hình 12.21. Header bản tin SIP INVITE

 Ngoài các thông tin như trong bản tin SIP:REGISTER (Mục 5.3.2.1) như:
CSeq, Call-ID, Via, Max-Forward, Contact (m), P-Access-Network-Infom;
header SIP INVITE còn chứa các thông tin sau:
Bắt buộc Mô tả
Header field (M)/ Tùy
chọn (O)
From (f) M ID của bên khởi tạo INVITE request
To (t) M ID của bên nhận INVITE request
Route O Xác định hướng đi (qua các proxy) cho request
 Được sử dụng để mang ID của UA gửi SIP
P-Preferred-
O message (đã được xác thực bởi quá trình
Identity
authetication)
Allow O Liệt kê các method được hỗ trợ bởi UA
Content-Type O Chỉ ra nội dung của message body
Liệt kê các loại message body nhận được ở
Accept O
response
P-Preferred- Dịch communcations vụ được ưu tiên của request
O
Service
Liệt kê tất cả các extension được hỗ trợ bởi UAC:
- timer: UA hỗ trợ refresh
Supported (k) O - 100rel: UA sẽ xác nhận (acknowledge) tất cả
100-class response
- replaces: hỗ trợ SIP Replaces header
Content- Kích thước của message body [octets]
O
Length (l)
Session- Khoảng thời gian UA muốn binding có hiệu lực [s]
O
Expires
Accept- Cho phép bên gọi được cung cấp tập các feature
O
Contact mong muốn

Bảng 12.22. Các thông tin trong header SIP INVITE

 SIP INVITE body:

Hình 12.23. Body của bản tin SIP INVITE

 Các thông tin trong SIP INVITE body được thể hiện ở bảng sau:
SDP field Mô tả
Owner/Creator Thông tin về chủ session: <username> <session
id> <version> <network type> <address type>
<address>
Connection Information (c) Thông tin kết nối được thiết lập: <network
type><address type> <connection address>
Time Description (t) Thời gian session được active: <start time><stop
time>
Start time và Stop time được set bằng 0 vì không
có khoảng thời gian nào được định trước cho việc
bắt đầu và kết thúc session.
t bắt đầu khi bên được gọi nhấc máy và kết thúc
khi một trong hai bên kết thúc.
Media Description (m) Trường này gồm các thông tin về media session.
Nhiều loại media payload thường được đưa ra để
bên được gọi lựa chọn.
Media Description = <media><port> <transport
protocol><format>

Format:
• 100  AMR-WB tại 16kHz
• 98  AMR tại 8kHz
• 112  telephone-events, DTMF tại 16 kHz
• 101  telephone-events, DTMF tại 8 kHz
Bandwidth information (b) b=<modifier>:<bandwidth value>
Bandwidth information AS: Application-Specific bandwidth modifier
(b):AS (RTP session bandwidth)
MO UE đưa ra băng thông lớn nhất dựa trên:
- Codec format (AMR-NB, AMR-WB)
- Loại địa chỉ (IPv4, IPv6)
- Hiệu suất băng thông hoặc octet-aligned (??)
Bandwidth information RS (RTCP Sender) và RR (RTCP Receiver) xác
(b):RS định băng thông RTCP cho MO UE và MT UE.
Bandwidth information Nếu set cả RS và RR bandwidth modifier bằng 0
(b):RR thì không có RTCP nào được sử dụng
Rtpmap Xác định mapping từ loại RTP payload tới
encoding
fmtp (media) Cung cấp các tham số bổ sung cho media format
 - octet-align: bằng ‘1’ – octet-align được sử dụng.
- mode-change-capability: bằng ‘1’- hỗ trợ thay
đổi code mode, code mode có thể thay đổi trong
cuộc gọi.
- max-red: bằng ‘0’ – không sử dụng redundancy.
fmtp (DTMF) Cung cấp thông tin bổ sung về DTMT format
Sendrecv Chỉ ra bên gửi request muốn gửi và nhận media
với bên nhận request
Ptime <packet time>; độ dài media frame (ms)

Bảng 12. Các trường trong SIP INVITE body

5.4.2. 100 TRYING response

- 100 TRYING response để xác

nhận MT UE đã nhận được SIP
INVITE.
- 100 TRYING chỉ gồm header,
không có phần body.

Hình 12.24. Bản tin SIP: 100 TRYING

5.4.3. 183 Session Progress

- MT UE gửi 183 Session

Progress, chứa phản hồi SDP (chỉ
ra codec được chọn).
- Khi nhận được 183 Session
Progress, IMS core sẽ trigger việc
thiết lập dedicated bearer để mang
payload cuộc gọi thoại cho cả MO
và MT UE.
- IMS core sẽ forward 183 Session
Progress tới MO UE.
- 183 Session Progress chứa 2
codec – MT MT chỉ châp nhận 2
trong 4 codec MO UE đưa ra.

Hình 12.25. 183 Session Progress – Header

 Hình 12.26. 183 Session Progress – Body
*Thiết lập dedicated bearer

Hình 12.27. Quá trình thiết lập cuộc gọi VoLTE

  Trong bản tin RRC Connection Reconfiguration, mạng gửi cấu hình về thiết
lập Active dedicated bearer request.
 Trong bản tin Active dedicated EPS bearer request, UE gửi yêu cầu của
dedicated bearer muốn thiết lập (Bearer ID, QCI, GBR…).
5.4.4. PRACK

MO UE gửi PRACK để xác

nhận đã nhận được 183
Session Progress
 Hình 12.28. PRACK
5.4.5. 200 OK (PRACK)
Xác nhận MT UE đã nhận được PRACK.
5.4.6. SIP: UPDATE

SIP UPDATE được sử dụng để

điều chỉnh các đặc tính
(characteristics), trạng thái của
session.

5.4.7. SIP: 200 OK

Xác nhận MT UE đã nhận được UPDATE
5.4.8. 180 Ringing

- MT UE gửi 180 Ringing tới

MO UE, trigger chuông báo
phía MO UE.

Hình 12.29. Bản tin 180 Ringing

5.4.9. 200 OK (INVITE) và ACK

- MT UE gửi 200 OK
(INVITE) để xác nhận quá
trình từ lúc MO gửi SIP
INVITE hoàn tất.
- MO UE gửi ACK, sau đó
voice path được thiết lập hoàn
toàn.
5.5. VoLTE Call Termination

Hình 12.30. VoLTE Call Release

Hình 12.31. VoLTE Call Termination – Normal Release

- Cuộc gọi VoLTE có thể được kết

thúc bất kỳ từ bên gọi (A) hay bên
được gọi.
- Để kết thúc cuộc gọi, UE gửi
SIP:BYE đến mạng, nếu thành
công, mạng gửi lại SIP:200 (OK)
để xác nhận .
 Hình 12.32. Bản tin SIP:BYE

Hình 12.33. SIP: 200 (OK)

Sau đó IMS trigger deactive Dedicated Radio Bearer.

Hình 12.34. Các bản tin trong quá trình kết thúc cuộc gọi VoLTE
5.6. IMS Deregistration
5.6.1. Các nguyên nhân trigger IMS Deregistration
 UE trigger: tắt máy, disable LTE RAT (ví dụ: ariplane mode).
 Network trigger: mạng detach UE khỏi EPC.
 Service trigger: LTE/IMS registration hết hiệu lực (expire) và UE không thể
register lại; số lần IMS registration fail đạt tới giá trị maximum.
5.6.2. Quá trình IMS Deregistration

Hình 12.35. Quá trình IMS Deregistration

1. UE giải phóng tất cả các dialog liên quan đến deregistered URI(s).
SIP dialog là quan hệ về báo hiệu giữa 2 UE trong cuộc gọi, được thiết lập khi
bắt đầu cuộc gọi và duy trì cho đến khi cuộc gọi kết thúc. SIP dialog được sử
dụng để thiết lập, điều chỉnh và giải phóng IMS multimedia session.
2. UE gửi REGISTER request, trong đó:
 Expire header được set bằng 0  UE muốn deregister.
 Require and Proxy-Require header: “sec-agree” (cho phép “thương
lượng” cơ chế bảo mật chung giữa UE và P-CSCF).
 REGISTER được gửi tới P-CSCF được bảo vệ bởi UEs outbound SA
(Security Association – giữa client port tại UE và server port tại P-
CSCF).
3. P-CSCF xử lý REGISTER request và forward REGISTER tới S-CSCF.
4. S-CSCF thực hiện thủ tục deregistration (Nếu REGISTER request được đánh
dấu là được bảo vệ toàn vẹn (integrity protected)). Bao gồm việc loại bỏ
 public user identity. Tiếp theo, S-CSCF gửi 200 OK tới P-CSCF (qua I-
CSCF).
5. P-CSCF cập nhật thông tin trạng thái về UE registration và trạng thái của SA
khi nhận được 200 OK, và sẽ forward bản tin này tới UE còn lại, UE này sẽ
thực hiện:
 Xóa tất cả các trạng thái registration liên quan đến public user identity đã
deregister.
 Nếu không có public user identity nào được register, UE có thể xóa SA
và các key liên quan.
 Nếu tất cả public user identity được deregister và SA được loại bỏ, UE
không còn nhận được báo hiệu từ P-CSCF.
6. Các feature quan trọng trong VoLTE
6.1. Robust Header Compression (RoHC)
 Trong các ứng dụng streaming, overhead của IP, UDP, RTP là 40 byte
(IPv4) hoặc 60 byte (IPv6). Đối với VoIP, khối lượng này tương ứng với
60% tổng data được truyền đi.
 PDCP sử dụng RoHC để giảm lượng overhead này:
 RoHC sẽ nén 40 hoặc 60 byte overhead vào 1 hoặc 3 byte.
 RoHC profile và các tham số được báo hiệu bởi các lớp cao hơn (RRC).
 RoHC không được sử dụng cho SIP Signalling.
 Hình 12.36. Header compression
 RoHC có 3 mode hoạt động:
Undirectional (U) Optimistic (O) Reliable (R)
Mode Mode Mode
Packet
Không định hướng Hai hướng Hai hướng
direction
Error
Không Một số Nhiều
Feedback
Efficiency Thấp Cao Cao

 Việc lựa chọn RoHC mode tối ưu phụ thuộc vào:


 và chuyển sang các mode khác dựa vào Decompressor feedback.
 Năng lực feedback, xác suất lỗi, ảnh hưởng của sự thay đổi header size…
 Triển khai RoHC phải hỗ trợ cả ba mode hoạt động

Hình 12.37. RoHC mode

UE gửi thông tin về RoHC-profile Network cấu hình RoHC profile

được hỗ trợ qua bản tin UE qua RRC Connection Reconfig
Capability Information
 - RoHC bắt đầu với U-Mode, sau đó chuyển
sang O-Mode
- Sau khi nén, header còn lại 3 byte

Hình 12.38. RoHC Compressor

6.2. TTI-Bundling
 TTI trong LTE ngắn, do đó data rate cao, dù payload nhỏ
 VoIP payload thường khoảng 30 byte.
 UDP và IP header thêm 40-60 byte vào payload.
  Giả sử một VoIP packet chiếm khoảng 40 byte (320 bit, trong 1ms 
320 kbps) sau RoHC, tại biên cell, khả năng cao UE không thể duy trì
UL connection với yêu cầu 320 kbps.
 TTI Bundling cho phép UE truyền cùng một voice frame trong 4 TTI liên
tiếp.
 Retransmission cũng xảy ra ở 4 TTI liên tiếp.
 TTI Bundling được enable bởi eNodeB khi công suất UL của UE bị giới
hạn, thường là ở biên cell.
 Trong TTI Bundling, chỉ cần 1 grant cho cho việc gán tài nguyên UL trên
nhiều TTI.

Hình 12.39. TTI Bundling

Hình 12.40. Quá trình enable TTI Bundling và các bản tin liên quan
6.3. Semi-Persistent Scheduling (SPS)
 SPS là cơ chế lập lịch được kết hợp từ hai cơ chế Persistent Scheduling và
Dynamic Scheduling.
 Persistent Scheduling
Phân bố tài nguyên UL DL “ổn định”
cho toàn bộ cuộc gọi.
Ưu điểm:
- Giảm overhead kênh báo hiệu
Nhược điểm:
- Khả năng tận dụng capacity thấp
- Không sử dụng được phân tập thời
gian và tấn số.
- Việc lập lịch không không quan tâm
điều kiện kênh truyền.
- Không được hỗ trợ trong LTE.
Dynamic Scheduling
Tài nguyên được phân bố động dựa trên
điều kiện kênh truyền.
Ưu điểm:
- Cơ chế lập lịch linh hoạt
- Có thể sử dụng phân tập thời gian và
tấn số
Nhược điểm:
- Tăng việc sử dụng PDCCH: user tăng
 tăng overhead.
- Tăng delay: UE yêu cầu tài nguyên
PUSCH cho mỗi lần truyền data UL
(qua SR)  tăng delay.

*Khối cùng màu: của cùng một user

 SPS sử dụng cơ chế như Persistent Scheduling khi bắt đầu transmission, tài
nguyên được phân bố cho UE trong các khoảng thời gian điều đặn. Tuy
nhiên các tài nguyên này được điều chỉnh khi có transmission mới hoặc
retransmission  Cho phép link adaption.
 Ưu điểm:
 Giảm control overhead so với Dynamic Scheduling.
 Phân bố tài nguyên linh hoạt.
 Nhược điểm:
 Cơ chế lập lịch phức tạp hơn: cần thay đổi, bổ sung eNodeB scheduler và
phần mềm.
7. SRVCC
7.1. SRVCC là gì?
 SRVCC (Single Radio Voice Call Continuity) là giải pháp Handover giữa
VoIP trên IMS trong LTE (VoLTE) và Voice call (CS) trong các hệ thống
hiện có (2G, 3G). Hay nói cách khác SRVCC là sự Handover giữa Packet
call trong LTE và Circuit call trong các hệ thống hiện có (2G, 3G).
 Một số trường hợp SRVCC:
 Trường hợp đơn giản nhất được mô tả như Hình 12.41 : UE đang thực
hiện VoLTE handover về 3G.
 Một trường hợp phức tạp hơn được thể hiện ở Hình 12.42. : UE đang
thực hiện VoLTE đồng thời với một dịch vụ data khác (email, web
browsing…). Trong trường hợp này, radio bearer phía 3G là multi-radio
bearer (CS+PS).
 Ngoài ra còn một số loại khác.

Hình 12.41. UE handover về 3G khi Hình 12.42. UE handover về 3G khi

đang thực hiện VoLTE đang thực hiện VoLTE và một dịch
vụ data khác

7.2. Vì sao cần có SRVCC?

 Phần lớn các operator hiện nay có mạng lưới 3G, 2G rộng khắp. Trong khi
đó LTE là công nghệ mới, việc triển khai LTE giai đoạn đầu khó có thể đạt
được vùng phủ như với công nghê 3G, 2G hiện có.
 Nếu user thực hiện voice call qua IMS với LTE (VoLTE) di chuyển ra khỏi
vùng phủ LTE, khả năng rất lớn cuộc gọi sẽ drop. Triển khai SRVCC giúp
khắc phục vấn đề này nhờ tận dụng được vùng phủ 3G, 2G rộng khắp.
7.3. Kiến trúc SRVCC

Hình 12.43. Kiến trúc SRVCC

 Để hỗ trợ interworking giữa LTE và mạng CS 2G/3G, cần có giao diện Sv

giữa MME và MSC. Giao diện Sv cho phép handover từ data bearers trong
LTE sang circuit bearers trong 2G/3G.
  Ngoài ra SRVCC còn có SCC AS (Service Centralization and Continuity
Application Server), đây là một signalling application dùng để hỗ trợ chuyển
các voice session từ PS sang CS.
7.4. Các loại SRVCC
3GPP
Loại SRVCC Mô tả
Release
Call Continuity từ E-UTRAN
Basic SRVCC Rel 8
sang UTRAN/GRAN
Packet Switched  Circuit Switched call transfer
aSRVCC Rel 10
trong Alerting Phase
Enhanced SRVCC (Support for MSC Server
eSRVCC Rel 10
assisted Mid Call Feature)
vSRVCC Rel 11 Video SRVCC
rSRVCC Rel 11 SRVCC từ UTRAN/GRAN sang E-UTRAN

Bảng 12. Các loại SRVCC

*Ngoài ra còn có bSRVCC (Packet Switched  Circuit Switched call transfer

trước Alerting Phase), tuy nhiên hiện nay chưa được triển khai.
7.5. Thiết lập IMS Session với SRVCC (EPS Core)

Hình 12.44. IMS Session setup

 Để có thể thực hiện SRVCC, SCC AS cần được thêm vào trên đường dẫn
báo hiệu IMS. Tất cả báo hiệu giữa các IMS phải đi qua SCC AS.
 Khi không thực hiện Handover, SCC AS chỉ có nhiệm vụ là forward các bản
tin giữa hai đầu cuối.
 Khi có Handover, SCC AS quản lý, điều chỉnh việc trao đổi các báo hiệu về
điều khiển session.
 Để nhận dạng các cuộc gọi tại SCC AS, UE được gán một giá trị gọi là
STN-SR (Session Transfer Number for Single Radio VCC), Về bản chất,
STN-SR là một số điện thoại. STN-SR cho phép SCC AS nhận dạng cuộc
gọi qua miền PS và CS trong quá trình handover.
 Trong quá trình Attach, UE cung cấp cho MME thông tin về SRVCC
capabilities. MME lấy thông tin thuê bao từ HSS, trong đó chứa STN-SR
được gán cho UE.
 Khi UE gửi bản tin IMS Registration tới S-CSCF, S-CSCF lấy thông tin
thuê bao từ HSS, trong đó chứa STN-SR. Sau đó S-CSCF gửi tất cả các
bản tin qua SCC AS. Nhờ đó SCC AS xác định được STN-SR
 Khi UE muốn thực hiện voice call, UE gửi SIP INVITE tới S-CSCF, S-
CSCF forward bản tin tới SCC AS. SCC AS sẽ “route” cuộc gọi tới MT
UE.
 Như vậy SCC AS có thể nhận biết được trạng thái cuộc gọi của UE.
7.6. Các quá trình trong SRVCC

Hình 12.45. Các quá trình xảy ra trong SRVCC (1)

1. Khi đang thực hiện VoLTE, nếu cường độ tín hiệu UE thu được xuống dưới
một ngưỡng nhất định (event A2), UE đo Inter-RAT frequency, nếu đạt điều
kiện trigger event B2, UE gửi Inter-RAT measurement reports tới eNB.
2. Dựa vào measurement report, source eNB quyết định trigger SRVCC
handover sang UTRAN/GERAN.
3. Nếu target là UTRAN, source eNB gửi thông tin về handover (Target cell
ID, SRVCC HO Indication) tới source MME. SRVCC HO Indication thông
báo cho MME về HO CS+PS.
4. Dựa trên QCI của voice bearer (QCI 1) và SRVCC HO Indication, source
MME tách voice bearer từ các PS bearer để phân bố tới MSC và SGSN
tương ứng.
5. Source MME thực hiện PS-CS handover cho voice bearer bằng cách gửi bản
tin SRVCC PS to CS request (IMSI, target ID, STN-SR, C-MSISDN, MM
 Context, Emergency Indication) tới MSC server. Bản tin này chỉ chứa các
thông tin liên quan đến miền CS. (MME nhận STN-SR và C-MSISDN từ
HSS qua quá trình Attach). MM Context chứa thông tin về bảo mật, trong đó
có CS Security key. Song song với quá trình trên, source MME phân bố PS
bearer về SGSN (Không được thể hiện trong Hình 12.45 – về cơ bản đây là
quá trình PS Handover).
6. Target MSC khởi tạo Session Transfer bằng cách gửi bản tin ISUP IAM
(STN-SR) tới SCC AS. STN-SR trong bản tin này cho phép SCC AS xác
định UE và cuộc gọi đang cần được xử lý.
7. Target MSC gửi bản tin Relocation Request/Handover Request tới RAN để
yêu cầu phân bố tài nguyên cho CS, sau đó RAN phân bố radio bearer cho
cuộc gọi.
8. Khi việc phân bố tài nguyên và session transfer hoàn tất, MSC gửi PS to CS
Response tới MME để thông báo việc thiết đặt tài nguyên ở target network
đã hoàn thành.

Hình 12.46. Các quá trình xảy ra trong SRVCC (2)

 9. Source MME đồng bộ quá trình phân bố bearer và gửi bản tin HO Command
tới source eNB.
10.Source eNB gửi bản tin HO from E-UTRAN Command tới UE.
11.UE camp sang target cell 2G/3G.
12.RNC/BSS detect được việc handover, UE gửi bản tin Handover from E-
UTRAN Complete tới 2G/3G RAN.
13.Target RAN forward bản tin tới MSC
14.CS relocation/handover hoàn tất. MSC gửi bản tin SRVCC PS to CS
Complete Notification tới source MME. Source MME xác nhận bằng cách
gửi bản tin SRVCC PS to CS Complete Acknowledge tới MSC.
7.7. EUTRAN to UTRAN SRVCC Call flow

Hình 12.47. EUTRAN to UTRAN SRVCC Call flow

7.7.1. Attach
UE thông báo MME về SRVCC Capability và voice domain được ưu tiên
trong bản tin Attach request.
7.7.2. PS Voice Call Setup

Các quá trình chính:

- UE gửi SIP INVITE
- Thiết lập dedicated
bearer cho voice.
- UE nhận SIP 200 OK 
thiết lập PS voice call
thành công
- Trao đổi các gói tin RTP
7.7.3. IRAT to UMTS và PS to CS Voice Call Continuity

 eNB gửi cấu hình event A2, UE report event A2

 eNB gửi thông tin về
cấu hình đo event A2

UE report event A2

 eNB cấu hình event B2, UE report event B2

eNB gửi thông tin về

cấu hình đo event B2

UE report event B2
 IRAT HO to UMTS Command

Thông tin UTRAN

Configuration