Ims VHT Call Flow v1.2

Call flow hệ thống IMS
MỤC LỤC
1 GIỚI THIỆU.................................................................................................................................4
1.1 Thuật ngữ...............................................................................................................................4

1.2 Tài liệu tham khảo.................................................................................................................5
2 CALL FLOW IMS.......................................................................................................................6
2.1 Quản lý thuê bao....................................................................................................................6
2.1.1 Registration......................................................................................................................6
2.1.2 Re-registration................................................................................................................14
2.1.3 De-registration...............................................................................................................17
2.1.4 User Profile update........................................................................................................20
2.1.5 Provisioning...................................................................................................................21
2.2 Basic call.............................................................................................................................22
2.2.1 IMS to IMS......................................................................................................................22
2.2.2 IMS to PSTN...................................................................................................................36
2.2.3 PTSN/CS to IMS.............................................................................................................46
2.3 ICS call................................................................................................................................55
2.3.1 VoLTE to ICS..................................................................................................................55
2.3.2 CS/PSTN to ICS..............................................................................................................66
2.4 SRVCC................................................................................................................................75
2.4.1 Handover of an Active Call............................................................................................75
2.5 SMS.....................................................................................................................................77
2.5.1 SMSoIP – MO over LTE.................................................................................................77
2.5.2 MO Delivery Report.......................................................................................................78
2.5.3 SMSoIP – MT over LTE.................................................................................................79
2.5.4 Failure when send message of LTE-terminal.................................................................81
2.6 Supplementary service........................................................................................................83
2.6.1 Dịch vụ OIP....................................................................................................................83
2.6.2 Dịch vụ OIR....................................................................................................................85
2.6.3 Dịch vụ TIP....................................................................................................................88
2.6.4 Dịch vụ TIR....................................................................................................................89
2.6.5 Dịch vụ Call Barring......................................................................................................91
/
2.6.6 Dịch vụ CF.....................................................................................................................95
2.6.7 Dịch vụ CW..................................................................................................................105
2.6.8 Dịch vụ CH...................................................................................................................111
2.6.9 Multi-party call (Ad hoc Conference)..........................................................................119
2.7 Emergency Call.................................................................................................................123
2.7.1 CSFB for VoLTE UE in LTE emergency call...............................................................123
2.7.2 CSFB khi P-CSCF điều hướng VoLTE UE in LTE emergency call.............................125
2.8 Charging............................................................................................................................126
2.8.1 Offline...........................................................................................................................126
2.8.2 Online...........................................................................................................................133
2.9 Một số dịch vụ đặc biệt.....................................................................................................142
2.9.1 CRBT............................................................................................................................142
2.9.2 MCA/Voice mail...........................................................................................................145
2.9.3 Call blocking................................................................................................................149
2.9.4 Announcement..............................................................................................................150
2.9.5 Transcode.....................................................................................................................155
2.9.6 MultiSIM:.....................................................................................................................158
/
1 GIỚI THIỆU
1.1 Thuật ngữ
Thuật ngữ Định nghĩa
AF Application Function
AS Application Server
BGF Border Gateway Function
BGCF Breakout Gateway Control Function
CAMEL Customised Application Mobile Enhanced Logic
CAP Camel Application Part
CDR Charging Data Record
CS Circuit Switched
CSCF Call Session Control Function
DNS Domain Name System
ENUM E.164 Number Mapping
HSS Home Subscriber Server
IBCF Interconnection Border Control Function
ICS IMS Centralized Service
I-CSCF Interrogating-Call Session Control Function
IMS IP Multimedia Core Network Subsystem
IM-SSF IP Multimedia Service Switching Function
IP-SM-GW IP Short Message Gateway
MAP Mobile Application Part
MGCF Media Gateway Control Function
MMTEL Multimedia Telephony
MRFC Multimedia Resource Function Controller
PCC Policy Charging Control
PCEF Policy and Charging Enforcement Function
/
PCRF Policy and Charging Rule Function
P-CSCF Proxy-Call Session Control Function
PDN Packet Data Network
QoS Quality of Service
SBC Session Border Control
SCCAS Service Centrallization and Continuity Application Server
S-CSCF Serving-Call Session Control Function
SS7 Signalling System 7
SIP Session Initiation Protocol
SRVCC Single Radio Voice Call Continuity
UE User Equipment
1.2 Tài liệu tham khảo

Tên tài liệu Ngày phát hành Nguồn Ghi chú
3GPP TS 23228 3GPP Tài liệu mô tả hệ thống
IMS
/
2 CALL FLOW IMS
2.1 Quản lý thuê bao
2.1.1 Registration
Các điều kiện tiên quyết:
- A (VoLTE UE) thiết lập kết nối với EPC qua APN ims
- UE phải tuân theo chuẩn GSMA IR.92
- The UE xác định địa chỉ P-CSCF thông qua thủ “P-CSCF discovery mechanism”.
- UE được trang bị USIM (T-IMPU được chuyển từ IMSI)
- UE đăng kí “reg” event sau khi đăng kí thành công IMS
- HSS đã cấu hình profie cho thuê bao
- Thông tin dịch vụ của A được cấu hình qua MMTEL và lưu trên HSS như “transparent
data”
2.1.1.1 Đăng kí cơ bản
Khi người dùng bật máy lên, điện thoại sẽ thực hiện attach vào mạng 4G (EPC), sau khi attach
thành công, lấy được địa chỉ P-CSCF, UE thực hiện gửi REGISTER tới P-CSCF để đăng kí dịch
vụ IMS
Luồng bản tin:
/
Bước Mô tả
1 UE gửi bản tin REGISTER tới P-CSCF.

UE nên thêm các tham số dưới đây vào trường Contact để chỉ ra khả năng và mong
muốn của nó:
 +g.3gpp.icsi-ref= urn:urn-7:3gpp-service.ims.icsi.mmtel; audio; video;

(chỉ ra hỗ trợ MMtel service)
 +g.3gpp.smsip (hỗ trợ SMS over IP)
 +sip.instance="<urn:gsma:imei:<IMEI of the UE-A>>"
 P-Access-Network-Info: 3GPP-E-UTRAN-FDD;utran-cell-id-3gpp
UE cũng chỉ ra yêu cầu cho IPsec ở header Require và Proxy-Require với giá trị
“sec-agree”
/
UE chỉ ra các tham số về việc thiết lập IPsec của nó trong trường Security-Client
2 P-CSCF thêm địa chỉ của pcscf vào trường Path.

P-CSCF thêm trường Feature-Caps có các tham số sau:
 g.3gpp.atcf=<STN-SR>
 g.3gpp.atcf-mgmt-uri=<ATCF mgmt URI>
 g.3gpp.atcf-path=<ATCF URI>
P-CSCF gửi REGISTER tới I-CSCF dựa vào tên domain của nhà mạng đăng kí
trong Request URI của bản tin REGISTER
3 I-CSCF thực hiện truy vấn HSS bằng việc gửi UAR để lấy thông tin server được
cấp để xử lý nghiệp vụ đăng kí cho thuê bao
UAR chứa các AVP quan trọng sau:
 User-Name: IMPI
 Public-Identity: IMPU
 User-Authorization-Type: REGISTRATION
4 HSS phản hồi UAA chứa AVP
 Server-capabilities chứa danh sách các tính năng cần có đối với server thực
hiện nghiệp vụ đăng kí và AVP
 Experimental-Result có giá trị là DIAMETER_FIRST_REGISTRATION
5 I-CSCF chọn S-CSCF dựa vào server capabilities mà HSS cung cấp và gửi
REGISTER tới S-CSCF
6 S-CSCF gửi MAR tới HSS để lấy thông tin xác thực với cơ chế xác thực là Diagest-
AKAv1-MD5
7 HSS tạo ra vectoc xác thực AKA. Vector bao gồm RAND, AUTN, XRES, CK và IK
8 HSS trả về MAA với vector xác thực AKA AV cho S-CSCF
9-10 S-CSCF giữ lại XRES và gửi bản tin trả lời 401 Unauthorized tới P-CSCF qua I-
CSCF.
Bản tin 401 (Unauthorized) chứa RAND, AUTN, CK và IK trong trường WWW-
Authenticate
11 P-CSCF lưu lại IK, CK trong bản tin 401 (Unauthorized) và xóa chúng đi.
P-CSCF thêm trường Security-Server chứa các thông tin liên quan đến việc thiết lập
IPsec phía server
12 UE xác thực nhà mạng bằng việc sử dụng AUTN và tính response.
UE gửi REGISTER tới P-CSCF với chuỗi response trong header Authorization
/
UE cung cấp tham số IPSec qua trường Security-Client và Security-Verify
Bản tin này được gửi qua kênh bảo mật IPsec

 User-Name: IMPI
15 HSS trả về UAA chứa AVP:
 Server-name : S-CSCF URI

 Experimental-Result: DIAMETER_SUBSEQUENT_REGISTRATION
16 I-CSCF chọn S-CSCF dựa vào Server-name và gửi bản tin REGISTER tới S-CSCF
17 S-CSCF so sánh RES từ UE và XRES từ HSS trả về. Nếu giống nhau, xác thực
thành công
S-CSCF thực hiện liên kết IMPU và địa chỉ contact của UE
18 S-CSCF thông báo HSS việc A đăng kí và lấy thông tin profile của thuê bao thông
qua bản tin SAR.
19 HSS trả lời bản tin SAA mang thông tin profile của A
20- S-CSCF gửi 200 OK tới P-CSCF qua I-CSCF

21
22 P-CSCF gửi 200 OK tới UE
Sau khi lấy profile của thuê bao A về, S-CSCF thực hiện phân tích iFC và thực hiện 3 rd
registration đối với các AS thỏa mãn iFC
2.1.1.2 Đăng kí MMTEL
MMTEL là một trong những AS thỏa mãn điều kiện 3rd registration do đó, S-CSCF sẽ thực hiện
thủ tục 3rd registration với MMTEL AS
/
Luồng bản tin:
Bướ
Mô tả
c
1 S-CSCF kiểm tra iFC và thực hiện 3rd party registration với MMTEL
2-3 MMTEL thực hiện gửi UDR(Data-Reference=IMSPublicIdentities) lên HSS để lấy

thông tin danh sách IMPU được đăng kí
HSS trả về UDA mang AVP-User-Data chứa danh sách IMPU được phép sử dụng
dịch vụ
4-5 MMTEL thực hiện gửi UDR(Data-Reference=RepositoryData) lên HSS để lấy

thông tin dịch vụ của thuê bao
HSS trả về UDA mang AVP-User-Data chứa dịch vụ của thuê bao
6-7 MMTEL thực hiện gửi SNR(Data-Reference=RepositoryData) để đăng kí theo dõi

sự thay đổi giá trị của RepositoryData (dịch vụ của thuê bao)
HSS trả về UDA chứa Expire-Time là thời gian được phép đăng kí. Khi sắp hết hạn
MMTEL nên gửi SNR lại để thực hiện đăng kí lại.
8 MMTEL phản hồi lại 200 OK cho REGISTER
2.1.1.3 Đăng ký SCC AS

SCC AS là một trong những AS thỏa mãn điều kiện 3 rd registration do đó, S-CSCF sẽ thực hiện
thủ tục 3rd registration với SCC AS
Luồng bản tin:
/
Bước Mô tả
1 S-CSCF kiểm tra iFC và thực hiện 3rd party registration với SCC AS
2-3 SCC AS thực hiện gửi UDR(Data-Reference=IMSPublicIdentities) lên HSS để lấy

dịch vụ
4-5 SCC AS thực hiện gửi UDR(Data-Reference=UE SRVCC Capability) lên HSS dể
lấy khả năng xử lý SRVCC của UE
HSS trả về UDA mang AVP-User-Data chứa khả năng xử lý SRVCC của UE
6-7 SCC AS thực hiện gửi UDR(Data-Reference=C-MSISDN) lên HSS lấy số điện
thoại của UE
HSS trả về UDA mang AVP-User-Data số điện thoại của A
8-9 SCC AS thực hiện gửi UDR(Data-Reference=STN-SR) lên HSS lấy số STN-SR
HSS trả về UDA mang AVP-User-Data số STN-SR của A
10-11 Nếu số STN-SR khác với số STN-SR nhận được trong bản tin REGISTER, SCC
AS thực hiện gửi PUR để cập nhật lại số STN-SR lên HSS
/
HSS phản hồi lại PUA thông báo cập nhật thành công
12-13 SCC AS thực hiện gửi bản tin MESSAGE mang XML mô tả thông tin liên quan để
SRVCC của thuê bao A tới P-CSCF qua S-CSCF
14-15 P-CSCF phản hồi lại 200 OK cho bản tin MESSAGE
16 SCC AS phản hồi lại bản tin 200 OK cho bản tin REGISTER
2.1.1.4 Đăng kí IP-SM-GW

IP-SM-GW là một trong những AS thỏa mãn điều kiện 3 rd registration do đó, S-CSCF sẽ thực
hiện thủ tục 3rd registration với IP-SM-GW
Luồng bản tin:
Bướ
Mô tả
c
1 S-CSCF kiểm tra iFCs của và khởi tạo 3rd party registration tới IP-SM-GW
S-CSCF gửi REGISTER tới IM-SM-GW
2-3 SCC AS thực hiện gửi UDR(Data-Reference=IMSPublicIdentities) lên HSS để lấy

dịch vụ
4-5 SCC AS thực hiện gửi UDR(Data-Reference=C-MSISDN) lên HSS lấy số điện
/
thoại của UE
HSS trả về UDA mang AVP-User-Data số điện thoại của A
6-7 SCC AS thực hiện gửi UDR(Data-Reference=IMSI) lên HSS lấy số điện thoại của
UE
HSS trả về UDA mang AVP-User-Data số IMSI của A
8-9 IP-SM-GW cập nhật địa chỉ IP-SM-GW thông qua PUR/PUA với Data-Reference =
SMSRegistrationInfo
10 IP-SM-GW thực hiện gửi 200 OK cho REGISTER
2.1.1.5 UE Subscribe
Sau khi nhận 200 OK của REGISTER, UE thực hiện gửi bản tin SUBSCRIBE với Event là “reg”
để thực hiện đăng kí theo dõi sự thay đổi của trạng thái đăng kí dịch vụ IMS của nó
Luồng bản tin:
Bướ
Mô tả
c
1 UE gửi SUBSCRIBE tới P-CSCF để đăng kí theo dõi trạng thái đăng kí của nó
2 P-CSCF định tuyến bản tin SUBSCRIBE tới S-CSCF
3-4 S-CSCF chấp nhận việc đăng kí và phản hồi 200 OK tới UE
5-6 S-CSCF thông báo tới UE (qua P-CSCF) trạng thái đăng kí hiện tại của nó bằng việc
gửi NOTIFY có body mạng thông tin trạng thái đăng kí của UE.
/
7-8 UE phản hồi lại 200 OK cho bản tin NOTIFY tới S-CSCF qua P-CSCF
2.1.2 Re-registration
Khi UE đăng kí thành công, nhà mạng cho phép UE sử dụng trong một khoảng thời gian nhất
định. Do đó, trước khi hết thời gian này, UE phải thực hiện thủ tục re-registration để gia hạn dịch
vụ.
Luồng bản tin:
Bước Mô tả
1 UE gửi bản tin REGISTER tới P-CSCF.

UE nên thêm các tham số dưới đây vào trường Contact để chỉ ra khả năng và mong
muốn của nó:
/
 +g.3gpp.icsi-ref= urn:urn-7:3gpp-service.ims.icsi.mmtel; audio; video;
(chỉ ra hỗ trợ MMtel service)
 +g.3gpp.smsip (hỗ trợ SMS over IP)
 +sip.instance="<urn:gsma:imei:<IMEI of the UE-A>>"
 P-Access-Network-Info: 3GPP-E-UTRAN-FDD;utran-cell-id-3gpp
UE cũng chỉ ra yêu cầu cho IPsec ở header Require và Proxy-Require với giá trị
“sec-agree”
UE chỉ ra các tham số về việc thiết lập IPsec của nó trong trường Security-Client

 User-Name: IMPI

5 I-CSCF gửi REGISTER tới S-CSCF
6 S-CSCF gửi MAR tới HSS để lấy thông tin xác thực với cơ chế xác thực là Diagest-
AKAv1-MD5
7 HSS tạo ra vectoc xác thực AKA. Vector bao gồm RAND, AUTN, XRES, CK và IK
8 HSS trả về MAA với vector xác thực AKA AV cho S-CSCF
9-10 S-CSCF giữ lại XRES và gửi bản tin trả lời 401 Unauthorized tới P-CSCF qua I-
CSCF.
Bản tin 401 (Unauthorized) chứa RAND, AUTN, CK và IK trong trường WWW-
Authenticate
/
11 P-CSCF lưu lại IK, CK trong bản tin 401 (Unauthorized) và xóa chúng đi.
P-CSCF thêm trường Security-Server chứa các thông tin liên quan đến việc thiết lập
IPsec phía server
12 UE xác thực nhà mạng bằng việc sử dụng AUTN và tính response.
UE gửi REGISTER tới P-CSCF với chuỗi response trong header Authorization
UE cung cấp tham số IPSec qua trường Security-Client và Security-Verify
Bản tin này được gửi qua kênh bảo mật IPsec

 User-Name: IMPI

16 I-CSCF chọn S-CSCF dựa vào Server-name và gửi bản tin REGISTER tới S-CSCF
17 S-CSCF so sánh RES từ UE và XRES từ HSS trả về. Nếu giống nhau, xác thực
thành công
S-CSCF thực hiện liên kết IMPU và địa chỉ contact của UE
18 S-CSCF gửi bản tin SAR thông báo HSS việc A đăng kí đăng kí lại của UE.
Trong bản tin có AVP quan trọng:
 Server-Assignment-Type: RE_REGISTRATION
19 HSS trả lời bản tin SAA
/
20- S-CSCF gửi 200 OK tới P-CSCF qua I-CSCF
21
22 P-CSCF gửi 200 OK tới UE
23 S-CSCF dựa vào iFC, thực hiện gửi REGISTER lên các AS áp dụng 3rd registration
23 AS thực hiện gia hạn thời gian đăng kí cho người dùng sau đó gửi 200 OK cho
REGISTER về S-CSCF
2.1.3 De-registration
2.1.3.1 Người dùng hủy đăng kí
Khi người dùng tắt máy, hoặc chủ động chuyển sang chế độ máy bay, UE sẽ thực hiện gửi De-
registration trước khi tắt máy hoặc chuyển chế độ.
Luồng bản tin:
Bước Mô tả
1 UE gửi bản tin (de)REGISTER tới P-CSCF. Với giá trị tham số expire trong trường
Contact là 0
2 P-CSCF gửi REGISTER tới the I-CSCF.

P-CSCF xác định I-CSCF dựa trên registrar domain name. P-CSCF thực hiện DNS
query (SRV record) để lấy địa chỉ IP của I-CSCF.
3 I-CSCF truy vấn HSS qua UAR trạng thái đăng kí của A
4 HSS phản hồi UAA mang thông tin S-CSCF đã được cấp cho UE trước đó
/
5 I-CSCF gửi REGISTER tới S-CSCF nhận được trong UAA.
6-7 S-CSCF đánh dấu UE thực hiện hủy đăng kí và thực hiện cập nhật trạng thái hủy
đăng ký lên HSS bằng việc gửi SAR (điều này chỉ xảy ra khi Contact cuối cùng liên
kết với IMPU bị xóa bỏ)
8-9 S-CSCF gửi 200 OK to P-CSCF qua I-CSCF
10 P-CSCF gửi 200 Ok tới UE. Sau đó, P-CSCF xóa IPsec SA.
11-12 S-CSCF thông báo về việc UE hủy đăng ký. Nó gửi NOTIFY với
State=“terminated” trong reginfo+xml.
13-14 UE phản hồi lại 200 OK cho bản tin NOTIFY tới S-CSCF
2.1.3.2 Network hủy đăng ký
2.1.3.2.1 Timeout
Khi hết thời gian đăng kí mà UE không gửi bản tin REGISTER để đăng kí lại, S-CSCF sẽ thực
hiện thủ tục dưới đây để hủy đăng kí
Luồng bản tin:
Bướ
Mô tả
c
1 Khi timer đăng kí của UE hết hạn, S-CSCF thực hiện thủ tục hủy đăng kí timeout
2 S-CSCF thực hiện gửi SAR thông báo trạng thái đăng kí của UE với Server-
Assignment-Type=TIMEOUT_DEREGISTRATION
3 HSS trả lời SAA thông báo đã thay đổi trạng thái đăng kí thành công
4-5 S-CSCF gửi NOTIFY thông báo trạng thái đăng kí của UE qua P-CSCF
6-7 UE gửi 200 OK cho NOTIFY tới S-CSCF
/
2.1.3.2.2 HSS
Khi nhà mạng muốn thực hiện hủy đăng kí của thuê bao, thực hiện tác động vào HSS để HSS
thực hiện yêu cầu S-CSCF hủy đăng kí dịch vụ của thuê bao
Luồng bản tin:
Bướ
Mô tả
c
1 HSS quyết định hủy đăng kí và gửi RTR tới S-CSCF thông báo trạng thái UE trên
HSS bị hủy. với AVP Deregistration-Reason:PERMANENT_TERMINATION
2 S-CSCF trả lời RTA, xác nhận việc hủy đăng kí
5-6 S-CSCF gửi NOTIFY thông báo trạng thái đăng kí của UE qua P-CSCF
7-8 UE gửi 200 OK cho NOTIFY tới S-CSCF
2.1.3.3 Hủy đăng kí với TAS

Khi UE thực hiện hủy đăng ký hay network hủy đăng kí, S-CSCF sẽ thực hiện thủ tục dưới đây
để thực hiện 3rd de-registration
2.1.3.3.1 Hủy đăng kí trên MMTEL
Luồng bản tin:
Bướ Mô tả
/
c
1 Dựa vào iFC, S-CSCF thực hiện gửi bản tin REGISTER với trường Expire=0 lên
MMTEL AS
2 MMTEL AS gửi SNR lên HSS để hủy việc theo dõi sự thay đổi dịch vụ của thuê
bao
3 HSS trả lời SNA cho MMTEL AS
4 MMTEL AS trả lời bản tin 200 OK cho REGISTER
2.1.3.3.2 Hủy đăng kí trên SCC AS hoặc IP-SM-GW
Luồng nghiệp vụ:
Bướ
Mô tả
c
1 Dựa vào iFC, S-CSCF thực hiện gửi bản tin REGISTER với trường Expire=0 lên
SCC AS hoặc IP-SM-GW
2 AS thực hiện xóa các thông tin đang lưu cho UE và gửi lại bản tin 200 OK cho
REGISTER
2.1.4 User Profile update

2.1.4.1 HSS thông báo sự thay đổi tới S-CSCF
Khi các thông tin profile của user bị thay đổi trên HSS có liên quan đến S-CSCF, HSS sẽ thực
hiện thủ tục này để cung cấp lại các thông tin thay đổi cho S-CSCF
Luồng bản tin:
/
Bướ
Mô tả
c
1 HSS gửi hiện tạo Push-Profile-Request(PPR) mang thông tin thay đổi gửi tới S-
CSCF
2 S-CSCF phản hồi lại PPA.
2.1.4.2 HSS thông báo sự thay đổi tới MMTEL

Do MMTEL AS thực hiện đăng kí theo dõi sự thay đổi của Repository Data nên khi có sự thay
đổi giá trị này, HSS sẽ khởi tạo thủ tục dưới đây để thông báo cho MMTEL biết
Luồng bản tin:
Bướ
Mô tả
c
1 HSS gửi hiện tạo Push-Notify-Request(PNR) mang AVP-User-Data gửi tới

MMTEL
2 MMTEL phản hồi lại PNA
/
2.1.5 Provisioning
Khi nhân viên chăm sóc thực hiện tạo mới, thay đổi, hay xóa dịch vụ của thuê bao. Luồng nghiệp
vụ dưới đây sẽ được áp dụng
Luồng bản tin:
Bướ
Mô tả
c
1 Nhà mạng thực hiện gửi Create/set/delete dịch vụ của thuê bao tới MMTEL
2-3 MMTEL thực hiện gửi UDR(Data-Reference=IMSPublicIdentities) lên HSS để lấy

dịch vụ
4-5 MMTEL thực hiện gửi UDR(Data-Reference=RepositoryData) lên HSS để lấy

thông tin dịch vụ của thuê bao
HSS trả về UDA mang AVP-User-Data chứa dịch vụ của thuê bao
6-7 MMTEL gửi PUR cập nhật lại thông tin liên quan để dịch vụ của thuê bao trong
trường RepositoryData
HSS gửi lại PUA thông báo cập nhật thành công
8 MMTEL phản hồi lại thực hiện thành công lệnh của nhà mạng
/
2.2 Basic call
2.2.1 IMS to IMS
2.2.1.1 Khởi tạo cuộc gọi
Giả sử:
- Thuê bao A và B đã đăng kí thành công vào mạng IMS

- A thực hiện gọi B
- Hệ thống chỉ có 1 node đối với mỗi phần tử
- Để giản lược flow bản tin 100 trying, 200 OK cho PRACK, ACK cho 200 OK của
INVITE không được vẽ trong flow này
Luồng bản tin:
Kí hiệu:
Bản tin xuất phát từ các phần tử mạng phục vụ UE A
Bản tin xuất phát từ các phần tử mạng phục vụ UE B
/
/
Bước Mô tả
/
1 A muốn thực hiện gọi cho B, A gửi SIP INVITE tới P-CSCF
INVITE sip:+84978257645@ims.mnc004.mcc452.3gppnetwork.org;user=phone
SIP/2.0
P-Preferred-Identity: <sip:
+841646617292@ims.mnc004.mcc452.3gppnetwork.org>
Accept-Contact:*;+g.3gpp.icsi-ref="urn%3Aurn-7%3A3gpp-
service.ims.icsi.mmtel";video
Contact:<sip:+841646617292@100.95.0.5:6400>;
+sip.instance="<urn:gsma:imei:35473708-467498-0>";+g.3gpp.icsi-ref="urn
%3Aurn-7%3A3gpp-service.ims.icsi.mmtel";+g.3gpp.mid-call;+g.3gpp.srvcc-
alerting;+g.3gpp.ps2cs-srvcc-orig-pre-alerting;video
2-3 P-CSCF nhận INVITE, và yêu cầu BGF cung cấp một context mới cho thuê bao A
qua H.248 add/addreply.
4 P-CSCF dựa vào Service-Route đã lưu sau khi đăng kí thành công thực hiện gửi
bản tin tới S-CSCF đang phục vụ thuê bao
5-6 Dựa trên iFC, S-CSCF gửi INVITE tới MMTEL để thực hiện các dịch vụ liên quan
đến MO. Sau khi thực hiện xong, MMTEL gửi lại INVITE tới S-CSCF
7-8 Khi list iFC là rỗng, S-CSCF thực hiện truy vấn ENUM cho số B number và Enum
trả về địa chỉ đich cần định tuyến đến
9 S-CSCF dựa vào kết quả truy vấn Enum thực hiện gửi SIP INVITE tới I-CSCF
10-11 I-CSCF thực hiện gửi LIR tới HSS để tìm địa chỉ S-CSCF của thuê bao B, HSS trả
lời LIA mang địa chỉ của S-CSCF
12 I-CSCF dựa vào kết quả trả về của HSS thực hiện gửi SIP INVITE tới S-CSCF
đến MT. Sau khi thực hiện xong, MMTEL gửi lại INVITE tới S-CSCF
15 Khi list iFC cần thực hiện hết, S-CSCF quyết định gửi INVITE tới P-CSCF đang có
kết nối với thuê bao B.(dựa vào thông tin Path header đã binding với UE khi đăng
kí thành công)
16-17 P-CSCF nhận INVITE, và yêu cầu BGF cung cấp một context mới cho thuê bao B
18 P-CSCF thực hiện gửi INVITE tới UE_B trên kênh truyền security đã thiết lập
19 UE_B trả lời 183 Session progress mạng SDP-B tới P-CSCF của B
20-21 P-CSCF gửi AA Request (AAR) tới PCRF yêu cầu thiết lập bear cho thuê bao B
/
AVPs được set như sau:
 Media- Component-Description
o Media Type : AUDIO
o Media-Sub-Component for RTP
 Flow status : ENABLED (1)
 AF-Charging-Identifier: ICID (IMS-Charging-Identifier)
PCRF phản hồi lại AA Answer(AAA) cho P-CSCF của B
22-23 P-CSCF gửi H.248 Modify request để cập nhật SDP-B vào context của B
24-31 Mạng IMS phục vụ thuê bao B phản hồi 183 mang SDP-B về mạng khởi tạo cuộc
gọi A
32-33 P-CSCF của thuê bao A nhận 183 và thực hiện yêu cầu tạo bear cho thuê bao A
bằng việc gửi AAR tới PCRF
PCRF phản hồi lại AA Answer(AAA) cho P-CSCF của A
34-35 P-CSCF gửi H.248 Modify request để cập nhật SDP B vào context của A
36 P-CSCF chuyển tiếp bản tin 183 tới UE mang thông tin SDP của B
37-46 UE_A gửi PRACK tới UE_B xác nhận đã nhận được 183
47 UE_A gửi UPDATE mang SDP offer của A sau khi thương lượng
48-49 P-CSCF của A gửi MODIFY/MODIFY reply để thay đổi thông tin media context
của thuê bao A
50-57 Mạng IMS của A thực hiện gửi UPDATE sang mạng IMS B theo Record-route đã
lưu khi thực hiện khởi tạo dialog của INVITE đầu tiên
58-59 P-CSCF của B gửi modify/modify reply để thay đổi thông tin media context của
thuê bao B
60 P-CSCF của B chuyển tiếp UPDATE tới B
61 UE_B gửi 200 OK cho UPDATE mang thông tin SDP answer
62-63 P-CSCF của B gửi modify/modify reply để thay đổi thông tin media context của
/
thuê bao B
64-71 Mạng IMS phục vụ thuê bao B phản hồi 200 mang SDP-B về mạng khởi tạo cuộc
gọi A
72 P-CSCF của A gửi MODIFY/MODIFY reply để thay đổi thông tin media context
của thuê bao A
73 P-CSCF chuyển tiếp bản tin 200 OK tới UE_A
74-83 UE_B gửi 180 ringing đến UE_A thông báo đang rung chuông, A khi nhận đc thực
hiện phát nhạc chuông local của UE_A
84 UE_B nhấc máy, B gửi 200 OK
85-86 P-CSCF của B gửi MODIFY/MODIFY reply để thay đổi thông tin media context
của thuê bao B
87-98 Mạng IMS phục vụ thuê bao B phản hồi 200 của INVITE mang SDP-B về mạng
khởi tạo cuộc gọi A
100- P-CSCF của A gửi MODIFY/MODIFY reply để thay đổi thông tin media context
101 của thuê bao A
102 P-CSCF chuyển tiếp 200 OK tới UE_A và bắt đầu cuộc thoại
2.2.1.2 Kết thúc cuộc gọi
2.2.1.2.1 MO kết thúc cuộc gọi
Giả sử:
- A và B đang trong cuộc gọi

- A thực hiện gác máy
Luồng bản tin:
Kí hiệu:
/
Bước Mô tả
1-10 Bên A gác máy, A gửi SIP BYE tới B thông quan mạng IMS(định tuyến bản tin
theo Record-Route của dialog)
11 UE_B gửi 200 OK cho BYE tới P-CSCF theo Via
12-13 P-CSCF gửi Session termination request(STR) tới PCRF yêu cầu giải phóng
bearer cấp cho UE B và PCRF phản hồi lại thành công Session Termination
answer (STA)
14-15 P-CSCF gửi H.248 “Subtract” tới BGF để xóa tài nguyên đã cấp cho B và BGF
phản hồi “Subtract Reply”
16-17 200 OK được route tới MMTEL MT.
18-19 MMTEL MT gửi Accounting request(ACR-STOP) tới CDF yêu cầu chấm dứt
charging cho B, và CDF trả lời Accounting answer(ACA)
20-23 200 OK được route tới MMTEL MO.
24-25 MMTEL MO gửi Accounting request(ACR-STOP) tới CDF yêu cầu chấm dứt
/
charging cho A, và CDF trả lời Accounting answer(ACA)
26-27 200 OK được gửi tới P-CSCF MO
bearer cấp cho UE A và PCRF phản hồi lại thành công Session Termination
answer (STA)
30-31 P-CSCF gửi H.248 “Subtract” tới BGF để xóa tài nguyên đã cấp cho A và BGF
32 P-CSCF gửi 200 OK của BYE cho UE_A
2.2.1.2.2 MT kết thúc cuộc gọi
Giả sử:

- B thực hiện gác máy
Luồng bản tin:
Kí hiệu:
/
Bước Mô tả
1-10 Bên B gác máy, B gửi SIP BYE tới A thông qua mạng IMS(định tuyến bản tin
11 UE_A gửi 200 OK cho BYE tới P-CSCF theo Via
answer (STA)
16-17 200 OK được route tới MMTEL MO.
20-23 200 OK được route tới MMTEL MT.
/
charging cho B, và CDF trả lời Accounting answer(ACA)
26-27 200 OK được gửi tới P-CSCF MT
answer (STA)
32 P-CSCF gửi 200 OK của BYE cho UE_B
2.2.1.2.3 MO hủy cuộc gọi
Giả sử:

- Chuông đang reo
- A gác máy
- Bản tin 200 OK cho CANCEL, ACK của 487 không vẽ trong flow này
Luồng bản tin:
Kí hiệu:
/
Bước Mô tả
1-10 Khi chuông đang reo, A bâm Cancel cuộc gọi, khi đó UE_A gửi SIP CANCEL
tới P-CSCF thực hiện hủy cuộc gọi, CANCEL được gửi hop by hop tới UE_B
11 UE_B gửi 487 Request terminated tới P-CSCF thông báo kết thúc dialog
answer (STA)
16-23 487 Request terminated được route tới P-CSCF MO.
answer (STA)
/
28 P-CSCF gửi 487 Request terminated tới UE_A
2.2.1.2.4 MT từ chối cuộc gọi
Giả sử:

- Chuông đang reo
- B reject cuộc gọi
- Bản tin ACK của bản tin 486 User busy không vẽ trong flow này
Luồng bản tin:
Kí hiệu:
Bước Mô tả
1 Khi chuông đang reo, B bấm reject cuộc gọi, khi đó UE_B gửi 486 User busy tới
P-CSCF thực hiện hủy cuộc gọi.
answer (STA)
/
6-13 486 User busy được route tới P-CSCF MO.
answer (STA)
18 P-CSCF gửi 486 User busy tới UE_A
2.2.1.2.5 MMTEL MO timeout
Giả sử:

- Chuông reo quá thời gian timer ringing trên MMTEL MO
- ACK của 487 Request terminated không vẽ trong flow này
Luồng bản tin:
Kí hiệu:
/
Bước Mô tả
1-7 Chuông reo quá 45s, MMTEL của A kích hoạt timer của 180ringing, gửi
CANCEL về phía UE_B
answer (STA)
answer (STA)
/
2.2.1.2.6 MT timeout
Giả sử:

- Chuông reo quá thời gian timer ringing trên MMTEL MT
- ACK của 487 Request Terminated không vẽ trong flow này
Luồng bản tin:
Kí hiệu:
Bước Mô tả
1-3 Chuông reo quá 45s, MMTEL của B kích hoạt timer của 180ringing, gửi
CANCEL về phía UE_B
answer (STA)
/
answer (STA)
2.2.2 IMS to PSTN

Giả sử:

- Để giản lược flow bản tin 100 trying, 200 OK cho PRACK, ACK cho 200 OK của
INVITE không được vẽ trong flow này
Luồng bản tin:
/
Bước Mô tả
/
SIP/2.0
Contact:<sip:+841646617292@100.95.0.5:6400>;
2-3 P-CSCF nhận INVITE, và yêu cầu BGF cung cấp một context mới cho thuê bao A
4 P-CSCF dựa vào Service-Route đã lưu sau khi đăng kí thành công thực hiện gửi
bản tin tới S-CSCF đang phục vụ thuê bao
đến MO. Sau khi thực hiện xong, MMTEL gửi lại INVITE tới S-CSCF
7-8 Khi list iFC là rỗng, S-CSCF thực hiện truy vấn ENUM cho số B number và
ENUM trả về Not found, S-CSCF thực hiện function của BGCF để tìm địa chỉ
MGCF
9 S-CSCF thực hiện gửi SIP INVITE tới MGCF, MGCF thực hiện gửi IAM sang
miền PSTN/CS
10 MGCF gửi 183 Session Progress mang thông tin phía code answer
11-13 S-CSCF chuyển tiếp 183 tới P-CSCF
14-15 P-CSCF gửi AA Request (AAR) tới PCRF yêu cầu thiết lập bear cho thuê bao A
PCRF phản hồi lại AA Answer(AAA) cho P-CSCF của B
16-17 P-CSCF gửi H.248 Modify request để cập nhật SDP-B vào context của A
18 P-CSCF chuyển tiếp 183 về UE_A
19-23 UE_A gửi PRACK tới UE_B xác nhận đã nhận được 183
/
24 UE_A gửi UPDATE mang SDP offer của A sau khi thương lượng tới P-CSCF
25-26 P-CSCF của A gửi modify/modify reply để thay đổi thông tin media context của
thuê bao A
27-30 Mạng IMS của A thực hiện gửi UPDATE sang tới MGCF để route sang mạng
PSTN/CS của B theo Record-route đã lưu khi thực hiện khởi tạo dialog của
INVITE đầu tiên
31-34 MGCF trả lời 200 OK mang SDP answers
37 P-CSCF chuyển tiếp 200 OK của UPDATE về UE
38-42 MGCF nhận ACM từ bên PSTN/CS, gửi 180 ringing về UE_A thông báo UE_B
đầu xa đang rung chuông
43 MGCF nhận ANM và thực hiện gửi 200 OK cho INVITE
44 S-CSCF chuyển tiếp 200 OK tới MMTEL
45-46 MMTEL trigger charging offline gửi ACR/ACA tới CDF
47-48 MMTEL gửi 200 OK về S-CSCF để gửi 200 tới UE
49-50 P-CSCF nhận 200 OK cập nhật lại thông tin media đầu B number vào context của
A
51 P-CSCF chuyển tiếp 200 OK tới UE_A
Giả sử:

Luồng bản tin:
/
Bước Mô tả
1-5 Bên A gác máy, A gửi SIP BYE tới B thông quan mạng IMS(định tuyến bản tin
6-16 MGCF gửi 200 OK cho BYE tới UE_A xác nhận đã chấm dứt cuộc thoại
8-9 Khi MMTEL nhận 200 OK của BYE, kick hoạt ACR(Stop) chấm dứt charging
offline
answer (STA)
Giả sử:

Luồng bản tin:
/
Bước Mô tả
1-5 Bên B gác máy, MGCF thay mặt B gửi SIP BYE tới A thông qua mạng IMS(định
tuyến bản tin theo Record-Route của dialog)
6-16 UE_A gửi 200 OK cho BYE tới MGCF qua mạng IMS core
answer (STA)
Giả sử:

- Chuông đang reo
- A gác máy
- Bản tin 200 OK của CANCEL, bản tin ACK của 487 Request Terminated không vẽ trong
flow này
Luồng bản tin:
/
Bước Mô tả
1-5 Khi chuông đang reo, A gác máy, A gửi SIP CANCEL tới B thực hiện hủy cuộc
gọi
6-14 MGCF thay mặt B gửi 487 Terminated request tới UE_A.
answer (STA)
Giả sử:

- Chuông đang reo
- Bản tin ACK của 486 User busy không vẽ trong flow này
Luồng bản tin:
/
Bước Mô tả
1-9 Chuông đăng reo, bên B gác máy, MGCF thay mặt B gửi response 486 User
busy tới A thông qua mạng IMS(định tuyến bản tin theo Record-Route của
dialog)
answer (STA)
2.2.2.2.5 MO timeout
Giả sử:

- Chuông reo quá thời gian ringing, MMTEL MO kích hoạt timer
- Bản tin ACK của 487 Request Terminated không vẽ trong flow này
Luồng bản tin:
/
Bước Mô tả
1-2 Khi chuông đang reo, MMTEL kích hoạt timer ringing, MMTEL gửi SIP
CANCEL tới B qua MGCF thực hiện hủy cuộc gọi
3-11 MGCF thay mặt B gửi 487 Terminated request tới UE_A.
answer (STA)
Giả sử:

- Chuông reo quá 45s
- ACK của 487 không vẽ trong flow này
Luồng bản tin:
/
Bước Mô tả
1-9 Chuông reo quá thời gian chờ 45s, bên mạng PSTN/CS của B thực hiện giải
phóng cuộc gọi, MGCF thay mặt B gửi response 480 với cause code là 18 tới A
thông qua mạng IMS(định tuyến bản tin theo Record-Route của dialog)
answer (STA)
2.2.3 PTSN/CS to IMS

Giả sử:
- A đang attached vào miền CS/PSTN

- B đang registered vào mạng IMS Sử dụng mod precondition
- Để giản lược flow 100 trying, 200 OK cho PRACK, ACK cho INVITE không được vẽ
trong flow này
Luồng bản tin:
/
/
Bước Mô tả
1 MSC nhận cuộc gọi từ UE A, MSC thực hiện gửi MAP SRI tới HLR
2 HLR trả lời lại MAP-SRI result với T-CSI(Terminating camel subscription
information), mang thông tin SCC AS
3 Dựa vào T-CSI, MSC gửi CAP-IDP tới SCC-AS
4 SCC-AS phân tích B number và thêm IMRN prefix vào B number và gửi CAP-
CONNECT tới MGCF
5 MSC dựa vào IMRN thực hiện routing BICC IAM tới MGCF
6 MGCF thiết lập tài nguyên media cho cuộc gọi bằng việc gửi H.248 ADD/ADD
reply
7 MGCF xóa IMRN, gửi SIP INVITE tới I-CSCF

INVITE tel:B; SIP/2.0
P-Asserted-Identity: tel:A
service.ims.icsi.mmtel"
8-9 I-CSCF gửi Location Information Request (LIR) tới HSS để tìm S-CSCF của B
10 I-CSCF gửi bản tin INVITE tới S-CSCF
11-12 Dựa vào iFC, S-CSCF gửi INVITE tới MMtel-AS để thực hiện các dịch vụ MT
13-14 Dựa vào iFC, S-CSCF gửi INVITE tới SCC AS để thực hiện neo lại phiên phục
vụ cho việc xử lý handover
15 S-CSCF dựa vào Path để gửi INVITE tới P-CSCF
16-17 P-CSCF gửi ADD/ADD reply tạo context cho UE_B
18 P-CSCF chuyển tiếp INVITE tới UE_B mang SDP của đầu khởi tạo cuộc gọi
19 UE-B phản hồi 183 mang SDP của nó
20-21 P-CSCF nhận 183 thực hiện lênh AAR yêu cầu PCRF khởi tạo bearer dedicated
cho UE_B
22-23 P-CSCF cập nhật thông tin liên quan đến media vào context của B qua
MODIFY/MODIFY reply
24-30 P-CSCF chuyển tiếp 183 mang SDP của B tới MGCF
31-32 MGCF thực hiện modify/modify reply để cập nhật thông tin media cho đầu khởi
tạo cuộc gọi
/
33-40 MGCF gửi PRACK tới UE-B thông báo đã nhận được bản tin 183
41-47 MGCF gửi UPDATE mang SDP của đầu khởi tạo cuộc gọi sẽ sử dụng
48-49 P-CSCF nhận UPDATE thực hiện thay đổi thông tin liên quan đến cuộc gọi về
đầu khởi tạo trong context của UE-B
50 P-CSCF chuyển UPDATE về UE-B
51 UE-B gửi lại 200 OK cho UPDATE mang SDP xác nhận lại thông tin session của
B
52-53 P-CSCF nhận UPDATE thực hiện thay đổi thông tin liên quan đến cuộc gọi về
bên nhận trong context của UE-B
54-60 P-CSCF gửi 200 OK tới MGCF
61-62 MGCF cập nhật thông tin SDP của đầu bên nhận vào context của A
63-70 UE_B gửi 180 ringing tới MGCF thông báo đang rung chuông
71-81 B nhấc máy, UE-B thực hiện gửi 200 OK tới MGCF
72-73 P-CSCF nhận 200 OK, thực hiện cập nhật SDP trong 200 OK vào context của B
78-79 MTAS nhận 200 OK thực hiện trigger charging offline ACR(START)
82-83 MGCF nhận 200 OK thực hiện gửi modify/modify
Giả sử:

Luồng bản tin:
/
Bước Mô tả
1-8 Bên A gác máy, MGCF gửi SIP BYE tới B thông quan mạng IMS(định tuyến bản
tin theo Record-Route của dialog)
9-22 UE_B gửi 200 OK cho BYE tới MGCF xác nhận đã chấm dứt cuộc thoại
answer (STA)
23-24 MGCF gửi H.248 “Subtract” tới IM-MGW để xóa tài nguyên đã cấp cho A và
IM-MGW phản hồi “Subtract Reply”
Giả sử:

Luồng bản tin:
/
Bước Mô tả
1-8 Bên B gác máy, UE-B gửi SIP BYE tới A thông qua mạng IMS(định tuyến bản
tin theo Record-Route của dialog) tới MGCF
9-10 MGCF gửi SUBSTRACT/SUBSTRACT reply tới IM-MGW thực hiện giải
phóng
11-24 MGCF thay mặt UE-A gửi 200 OK tới UE-B xác nhận kết thúc cuộc gọi
answer (STA)
Giả sử:

- Chuông đang reo
- A gác máy
- Bản tin 200 OK của CANCEL, bản tin ACK của 487 Request Terminated không vẽ trong
flow này
Luồng bản tin:
/
Bước Mô tả
1-8 Khi chuông đang reo, A gác máy, MGCF thay mặt A gửi SIP CANCEL tới B
thực hiện hủy cuộc gọi
9-20 UE B phản hồi 487 Request Terminated cho INVITE tới MGCF
answer (STA)
Giả sử:

- Chuông đang reo
- Bản tin ACK của 486 User busy không vẽ trong flow này
Luồng bản tin:
/
Bước Mô tả
1 Chuông đăng reo, bên B gác máy, UE B gửi response 486 User busy tới P-CSCF
answer (STA)
6-12 P-CSCF chuyển tiếp response 486 User busy tới MGCF
2.2.3.2.5 MO Time out
Khi bên MO timeout, MSC sẽ gửi REL tới MGCF, MGCF thực hiện gửi CANCEL về phía UE
B. Luồng bản tin đi tương tự trường hợp A chủ động hủy cuộc gọi trong phần 2.2.3.2.3
2.2.3.2.6 MT Time out
Giả sử:

- Bản tin ACK của 487 Request Terminated không vẽ trong flow này
Luồng bản tin:
/
Bước Mô tả
1-5 Chuông reo quá thời gian chờ 45s, MTEL của B thực hiện giải phóng cuộc gọi,
MMTEL gửi CANCEL tới UE-B
6 UE-B phản hồi 487 Request Terminated cho INVITE tới P-CSCF
answer (STA)
11-17 P-CSCF chuyển tiếp 487 Request Terminated tới MGCF
/
2.3 ICS call
2.3.1 VoLTE to ICS
Giả sử:
- Thuê bao A và B là thuê bao VoLTE

- A đang registered vào mạng IMS
- B đang attached trong miền CS
- Để giản lược flow 100 trying, 200 OK cho PRACK, ACK cho INVITE không được vẽ
trong flow này
Luồng bản tin:
Kí hiệu:
/
/
Bước Mô tả
/
SIP/2.0
Contact:<sip:+841646617292@100.95.0.5:6400>;
2-3 P-CSCF yêu cầu BGF tạo một context cho A qua H.248 add/add reply
4 P-CSCF gửi bản tin INVITE tới S-CSCF
5-6 Dựa trên iFC S-CSCF gửi bản tin INVITE tới SCC AS, SCC AS lưu lại contact
và location information sau đó SCC-AS gửi lại INVITE tới S-CSCF
7-8 S-CSCF gửi bản tin INVITE tới MMTEL để thực hiện các service liên quan đến
MO sau đó gửi trả lại S-CSCF
9-10 S-CSCF thực hiện query DNS cho B number và lấy được một địa chỉ SIP
S-CSCF thực hiện hiện DNS địa chỉ sip đó để lấy IP của terminating I-CSCF
11 I-CSCF gửi SIP INVITE tới S-CSCF
12-13 I-CSCF gửi LIR tới HSS để tìm S-CSCF phục vụ thuê bao B, HSS trả lời LIA
với địa chỉ của S-CSCF
15-16 S-CSCF kiểm tra UE chưa đăng kí, thực hiện truy vấn HSS để lấy thông tin
profile liên quan đến UE thông qua SAR/SAA
17 Dựa trên iFC, S-CSCF gửi bản tin INVITE tới MMTEL để thực hiện các dịch
vụ liên quan đến bên nhận
18-21 Do chưa có thông tin của thuê bao, MMTEL thực hiện truy vấn HSS qua
UDR/UDA để lấy các thông tin cần thiết(IRS, repository data)
22 MMTEL gửi lại INVITE cho S-CSCF
23 Dựa trên iFC, S-CSCF gửi INVITE tới SCC AS
24-25 SCC AS nhận INVITE, thực hiện truy vấn HSS để biết thông tin access của UE
MT qua UDR(T-ADS), HSS trả về UDA mang thông tin chỉ ra UE đang ở miền
CS
/
26 SCC AS thay đổi request uri thành CSRN+B number rồi trả lại INVITE cho S-
CSCF
27-28 S-CSCF thực hiện DNS(request uri) để tìm hướng đi tiếp nhưng DNS server trả
về not found.
29 BGCF thực hiện gửi INVITE tới MGCF để thực hiện tới miền CS
30-31 MGCF nhận INVITE thực hiện yêu cầu IM-MGW tạo context cho cuộc gọi qua
ADD/ADD reply
32-43 MGCF phản hồi 183 Session Progress mang thông tin SDP answer tới P-CSCF
44-45 P-CSCF thực hiện yêu cầu PCRF thiết lập bearer dành riêng cho UE_A qua Rx
AAR/AAA
46-47 P-CSCF yêu cầu BGF cập nhật thông tin media đầu xa vào context qua H248
Modify/modify reply
49-61 UE gửi lại PRACK cho bản tin 183 xác nhận đã nhận được 183
62 UE-A xác nhận lại việc sử dụng codec trong phiên qua UPDATE gửi tới P-
CSCF
63-64 P-CSCF yêu cầu BGF cập nhật thông tin media đầu gần vào context qua H248
Modify/modify reply
65-76 P-CSCF chuyển tiêp bản tin UPDATE mang SDP của A tới MGCF
77-78 MGCF thực hiện gửi MODIFY/MODIFY reply để cập nhật thông tin sesison
vào context trên IM-MGW
79-93 MGCF phản hồi 200 ok cho UPDATE tới UE_A
Modify/modify reply
94-107 MGCF gửi 180ringing tới UE_A thông báo đầu nhận cuộc gọi đang đổ chuông
108-126 MGCF gửi 200 OK tới UE_A thông báo đầu nhận cuộc gọi đã nhấc máy
112-113 MMTEL MT kích hoạt charging offline cho UE MT qua ACR(START)
118-119 MMTEL MO kích hoạt charging offline cho UE MO qua ACR(START)
Modify/modify reply

/
Giả sử:

Luồng bản tin:
Bước Mô tả
1-13 Bên A gác máy, UE A gửi SIP BYE tới B thông quan mạng IMS(định tuyến bản
tin theo Record-Route của dialog)
14-15 MGCF gửi SUBSTRACT/SUBSTRACT reply tới IM-MGW thực hiện giải
phóng
16-36 MGCF thay mặt UE-B gửi 200 OK cho BYE xác nhận
20-21 MMTEL của B nhận 200 OK, kích hoạt ACR(STOP) cho offline charging của B
26-27 MMTEL của B nhận 200 OK, kích hoạt ACR(STOP) cho offline charging của B
32-33 P-CSCF gửi Session termination request(STR) tới PCRF để giải phóng bearer
/
Giả sử:

Luồng bản tin:
Bước Mô tả
1-14 Bên B gác máy, MGCF thay mặt B gửi SIP BYE tới A thông qua mạng IMS(định
tuyến bản tin theo Record-Route của dialog)
15 UE-A gửi 200 OK cho BYE tới P-CSCF
16-17 P-CSCF gửi Session termination request(STR) tới PCRF để giải phóng bearer
20-35 P-CSCF chuyển tiếp bản tin 200 OK tới
24-25 MTAS MO gửi Accounting request(ACR-STOP) tới CDF yêu cầu chấm dứt
/
30-31 MTAS MT gửi Accounting request(ACR-STOP) tới CDF yêu cầu chấm dứt
36-37 MGCF gửi H.248 “Subtract” tới BGF để xóa tài nguyên đã cấp cho A và BGF
Giả sử:

- Chuông đang reo
- A gác máy
- Bản tin 200 OK của CANCEL, ACK của 487 Requet terminated không vẽ trong flow này
Luồng bản tin:
Bước Mô tả
1-8 Khi chuông đang reo, A gác máy, UE A gửi SIP CANCEL tới B thực hiện hủy
cuộc gọi
14-15 MGCF gửi H.248 “Subtract” tới IM-MGW để xóa tài nguyên đã cấp cho B và
/
16-32 MGCF thay mặt UE B phản hồi 487 Terminated request cho INVITE tới UE_A
answer (STA)
Giả sử:

- Chuông đang reo
- ACK của 486 không vẽ trong flow này
Luồng bản tin:
Bước Mô tả
1-2 Khi chuông đang reo, MGCF nhận được thống báo UE B gác máy, nó gửi H.248
“Subtract” tới IM-MGW để xóa tài nguyên đã cấp cho B và IM-MGW phản hồi
“Subtract Reply”
3-19 MGCF thay mặt UE_B gửi 486 User busy tới UE_A
/
answer (STA)
Giả sử:

- Bản tin ACK của 487 Request terminated không vẽ trong flow này
Luồng bản tin:
Bước Mô tả
1-8 Chuông reo quá thời gian chờ 45s, MMTEL của A thực hiện giải phóng cuộc gọi,
MMTEL của A gửi CANCEL tới UE-B
11-27 MGCF thay mặt UE-B phản hồi 487 Request Terminated cho INVITE tới UE-A
/
answer (STA)
2.3.1.2.6 MT imeout
Giả sử:

- Bản tin ACK của 487 Request terminated không vẽ trong flow này
Luồng bản tin:
Bước Mô tả
1-4 Chuông reo quá thời gian chờ 45s, MMTEL của B thực hiện giải phóng cuộc gọi,
MMTEL gửi CANCEL tới UE-B
7-23 MGCF thay mặt UE-B phản hồi 487 Request Terminated cho INVITE tới UE-A
/
answer (STA)
2.3.2 CS/PSTN to ICS

Cuộc gọi CS/PSTN xảy ra khi thuê bao A là thuê bao 2G/3G hoặc PSTN thực hiện khởi tạo cuộc
gọi tới thuê bao B (là thuê bao VoLTE nhưng đang truy nhập vào miền 2G/3G).
Luồng bản tin:
Kí hiệu:
/
/
Bước Mô tả
1 MSC nhận cuộc gọi từ UE A, MSC thực hiện gửi MAP SRI tới HLR
2 HLR trả lời lại MAP-SRI result với T-CSI(Terminating camel subscription
information), mang thông tin SCC AS
3 Dựa vào T-CSI, MSC gửi CAP-IDP tới SCC-AS
4 SCC-AS phân tích B number và thêm IMRN prefix vào B number và gửi CAP-
CONNECT tới MGCF
5 MSC dựa vào IMRN thực hiện routing BICC IAM tới MGCF
6 MGCF thiết lập tài nguyên media cho cuộc gọi bằng việc gửi H.248 ADD/ADD
reply
7 MGCF xóa IMRN, gửi SIP INVITE tới I-CSCF

INVITE tel:B; SIP/2.0
P-Asserted-Identity: tel:A
service.ims.icsi.mmtel"
8 I-CSCF gửi LIR tới HSS để tìm S-CSCF phục vụ thuê bao B, HSS trả lời LIA với
địa chỉ của S-CSCF
9 I-CSCF gửi INVITE tới S-CSCF
10-11 S-CSCF kiểm tra UE chưa đăng kí, thực hiện truy vấn HSS để lấy thông tin
profile liên quan đến UE thông qua SAR/SAA
12 Dựa trên iFC, S-CSCF gửi bản tin INVITE tới MMTEL để thực hiện các dịch vụ
liên quan đến bên nhận
13-16 Do chưa có thông tin của thuê bao, MMTEL thực hiện truy vấn HSS qua
UDR/UDA để lấy các thông tin cần thiết(IRS, repository data)
17 MMTEL gửi lại INVITE cho S-CSCF
18 Dựa trên iFC, S-CSCF gửi INVITE tới SCC AS
19-20 SCC AS nhận INVITE, thực hiện truy vấn HSS để biết thông tin access của UE
MT qua UDR(T-ADS), HSS trả về UDA mang thông tin chỉ ra UE đang ở miền
CS
21 SCC AS thay đổi request uri thành CSRN+B number rồi trả lại INVITE cho S-
CSCF
22-23 S-CSCF thực hiện DNS(request uri) để tìm hướng đi tiếp nhưng DNS server trả
/
về not found.
24 BGCF thực hiện gửi INVITE tới MGCF B để thực hiện tới miền CS
25 MGCF B nhận INVITE thực hiện yêu cầu IM-MGW tạo context cho cuộc gọi
qua ADD/ADD reply
26 MGCF B thực hiện gửi BICC IAM về MSC đang phục vụ thuê bao B
27-32 MGCF B phản hồi lại 183 Session Progress mang SDP của MGW B tới MGCF A
33 MGCF A gửi MODIFY tới IM-MGW A cập nhật thông tin media của phiên.
IM-MGW A phản hồi lại MODIFY reply
34-40 MGCF A gửi UPDATE mang SDP IM-MGW A tới MGCF B
41 MGCF B gửi MODIFY tới IM-MGW B cập nhật thông tin media của phiên.
IM-MGW B phản hồi lại MODIFY reply
42-48 MGCF B phản hồi lại 200 OK cho UPDATE mang SDP của MGW B tới MGCF
A
49 MGCF A gửi MODIFY tới IM-MGW A cập nhật thông tin media của phiên.
IM-MGW A phản hồi lại MODIFY reply
50 MGCF B nhận BICC ACM từ miền PSTN/CS của B
51-57 MGCF B gửi 180 Ringing tới MGCF A
58 MGCF A gửi BICC ACM tới miền PSTN/CS của A
59 MGCF B nhận BICC ANM từ miền PSTN/CS của B
60-66 MGCF B gửi 200 OK cho INVITE tới MGCF A
67 MGCF A gửi BICC ANM tới miền PSTN/CS của A
Kí hiệu:
/
Bước Mô tả
1-7 Bên A gác máy, MGCF nhận được bản tin REL từ miền PSTN/CS của A
MGCF gửi SIP BYE tới B thông quan mạng IMS(định tuyến bản tin theo Record-
Route của dialog)
8 MGCF B thực hiện gửi SUBTRACT tới IM-MGW B để xóa tài nguyên đã cấp cho
B
9-15 MGCF B phản hồi lại 200 OK cho BYE tới MGCF A
16 MGCF A thực hiện gửi SUBTRACT tới IM-MGW A để xóa tài nguyên đã cấp cho
A
Kí hiệu:
/
Bướ Mô tả
c
1-7 Bên B gác máy, MGCF B nhận được bản tin REL từ miền PSTN/CS của B
MGCF B gửi SIP BYE tới MGCF A theo Record-Route
A
9-15 MGCF A phản hồi lại 200 OK cho BYE tới MGCF B
B
/
Bướ Mô tả
c
1-7 Khi cuộc chuông đang reo, bên A gác máy, MGCF A nhận được bản tin REL từ
miền PSTN/CS của A
MGCF A gửi SIP CANCEL tới MGCF B theo Record-Route
B
9-15 MGCF B gửi 487 Request Terminated tới MGCF A
A
Kí hiệu:
/
Bướ Mô tả
c
1 Khi cuộc chuông đang reo, MGCF B nhận được bản tin REL từ miền PSTN/CS của
B.
MGCF B thực hiện gửi SUBTRACT tới IM-MGW B để xóa tài nguyên đã cấp cho
B
2-8 MGCF B gửi 486 User Busy tới MGCF A theo Record-Route
A
Kí hiệu:
/
Bướ Mô tả
c
1-7 Khi cuộc chuông đang reo, mạng PSTN/CS của A kích hoạt timer ringing do B
không nhấc máy, MGCF A nhận được bản tin REL từ miền PSTN/CS của A
MGCF A gửi SIP CANCEL tới MGCF B theo Record-Route
B
A
Kí hiệu:
/
Bướ Mô tả
c
1-4 Khi cuộc chuông đang reo, MMTEL MT kích hoạt timer ringing do B không nhấc
máy, MMTEL MT gửi SIP CANCEL tới MGCF B
B
A
2.4 SRVCC
2.4.1 Handover of an Active Call
Luồng bản tin mô tả SRVCC từ E-UTRAN xuống UTRAN, với các Giả sử sau:
- A (VoLTE UE đang attached E-UTRAN) gọi thuê bao B (VoLTE UE)

- UE-A di chuyển từ E-UTRAN cell xuống UTRAN cell
- Để cuộc gọi diễn ra liên tục, hệ thống thực hiện thủ tục SRVCC (Single Radio Voice call
continuity) PS to CS handover cho voice call
/
Bước Mô tả
1 A (VoLTE UE) và B (VoLTE UE) đang trong cuộc gọi

UE-A di chuyển tới nơi mà độ mạnh tín hiệu của UTRAN lớn hơn E-UTRAN. UE
gửi Measurement Reports tới eNodeB
2 Dựa vào UE measurement reports eNodeB quyết định thực hiện Handover về
UTRAN.
3 eNodeB gửi yêu cầu mang Target ID và SRVCC HO Indication tới MME.
4 Dựa trên QCI và SRVCC HO indication, MME tách voice bearer từ non-voice
bearer và khởi tạo thủ tục PS to CS handover cho voice bearer
5 MME gửi SRVCC PS to CS Request(MSI, Target ID, STN-SR và C-MSISDN) tới

MSC
6-7 The MSC-A thực hiện resource allocation với target RAN qua bản tin Relocation
Request / Relocation Request Acknowledge.
8 MSC-A tương tác với MGW-A để chuẩn bị tài nguyên
9-11 MSC Server khởi tạo the Session Transfer sử dụng số STN-SR tới IMS.
/
MSC-S gửi INVITE tới P-CSCF(ATCF) qua I-CSCF.
I-CSCF truy vấn HSS để lấy thông tin định tuyến của P-CSCF(ATCF)
12-13 PCRF gửi Abort Session Request (ASR) với Abort-Cause-AVP = 3

(PS_TO_CS_HANDOVER) để thông báo dedicated bearer cho voice đã bị giải
phóng
14-15 P-CSCF gửi Session Terminaiton Request(STR) lên PCRF để kết thúc session.
PCRF trả lời Session Termination Answer(STA).
16-17 P-CSCF tương tác với BGF thực hiện thay đổi thông tin media trong cuộc gọi
handover qua H.248 MODIFY/MODIFY Reply
18-19 P-CSCF phản hồi 200 OK cho INVITE mang SDP của BGF.
Sau đó cuộc gọi được tiếp tục như sau:
UE-A (3G CS) ---- CS media ----MGW(A) ------ PS media ---- BGF (A) ---- PS
media ---- BGF (B) ---- PS media ---- UE-B (VoLTE user)
20-22 ATCF thông báo SCC-AS về việc HO bằng việc với INVITE có R-URI là ATU-
STI.
Bản tin INVITE bao gồm Target-Dialog mang thông tin dialog đã thiết lập trước đó
giữa ATCF và SCC AS, R-URI là ATU-STI định danh cho SCC AS, PAI là C-
MSISDN của thuê bao A
I-CSCF truy vấn HSS với LIR(Public-Identity là số ATU-STI)
I-CSCF lấy địa chỉ SCC AS trong bản tin LIA do HSS trả về và chuyển tiếp bản tin
tới SCC AS
23-24 SCC-AS phản hồi 200 OK tới P-CSCF/ATCF
25-26 PCRF gửi Abort Session Request (ASR) với Abort-Cause-AVP =

0(BEARER_RELEASED) để thông báo default bearer cho UE A đã bị giải phóng
27-28 P-CSCF gửi Session Terminaiton Request(STR) lên PCRF để kết thúc session.
PCRF trả lời Session Termination Answer(STA).
29-30 P-CSCF gửi BYE tới SCC AS để kết thúc dialog đã thiết lập trước khi handover
với SCC AS
31-32 SCC-AS phản hồi 200 OK tới P-CSCF(ATCF)
/
2.5 SMS
2.5.1 SMSoIP – MO over LTE
Bước Mô tả
1 UE-A1 gửi SIP MESSAGE với Content-Type: application/vnd.3gpp.sms.

Body mang RP-DATA message.
UE gửi the MESSAGE tới P-CSCF
2 P-CSCF gửi bản tin MESSAGE tới S-CSCF
3 Dựa trên iFC, S-CSCF gửi bản tin MESSAGE tới IP-SM-GW
4 IP-SM-GW gửi MO-FSM request tới SMSC (nếu có nhiều SMSC có thể thực hiện
round robin)
5-7 IP-SM-GW gửi 202 Accept phản hồi lại UE
8 SMS-C gửi bản tin phản hồi MO-FSM response với SMS-SUBMIT-REPORT tới
IP-SM-GW
9 IP-SM-GW tạo SIP MESSAGE (Content-Type: Application/vnd.3gpp.sms với

body là
SMS-SUBMIT-REPORT) gửi tới I-CSCF
10-11 I-CSCF thực hiện truy vấn HSS để lấy địa chỉ S-CSCF qua LIR
12 I-CSCF gửi MESSAGE tới S-CSCF
13-14 S-CSCF gửi MESSAGE tới UE qua P-CSCF
/
2.5.2 MO Delivery Report
Bước Mô tả
1 SMSC nhận delivery report từ bên B, thực hiện truy vấn HLR để lấy thông tin định
tuyến qua SRI-SM request
2 HLR cấu hình chức năng SMS Home router với IP-SM-GW là Home Router.
HLR chuyển tiếp SRI-SM request sang IP-SM-GW
3 IP-SM-GW thực hiện vai trò của home router và gửi SRI-SM tới HLR
4 HLR phản hồi SRI-SM tới IP-SM-GW mang thông tin IMSI, VMSC
5 IP-SM-GW gửi lại SRI-SM response tới SMSC. Nó mang IMSI: Correl ID và
Location: IP-SM-GW GT
6 Dựa vào thông tin định tuyến nhận được trong SRI-SM, SMS-C gửi MT-FSM
(Mobile Termination – Forward Short Message) tới IP-SM-GW
7 IP-SM-GW đối chiếu MT-FSM request sử dụng correlation ID và quyết định gửi
tới UE qua miền IMS.
IP-SM-GW tạo SIP MESSAGE (Content-Type: Application/vnd.3gpp.sms với
body là
SMS-DELIVER-REPORT) tới UE-A
/
13-16 UE gửi 200 OK phản hồi bản tin MESSAGE tới IP-SM-GW
17 IP-SM-GW gửi bản tin phản hồi MT-FSM tới SMSC
18 IP-SM-GW cập nhật lên HLR với ReportSM-DS.
2.5.3 SMSoIP – MT over LTE
Bước Mô tả
/
7 IP-SM-GW đối chiều MT-FSM request sử dụng correlation ID và quyết định gửi
tới UE qua miền IMS.
IP-SM-GW tạo SIP MESSAGE (Content-Type: Application/vnd.3gpp.sms với
body là
13-16 UE gửi 200 OK phản hồi bản tin MESSAGE tới IP-SM-GW
17-19 UE gửi delivery report tới IP-SM-GW qua SIP MESSAGE.

Trong body của SIP MESSAGE mang bản tin RP-ACK.
20-22 IP-SM-GW gửi lại bản tin phản hồi 202 Accept tới UE-B
23 IP-SM-GW gửi bản tin phản hồi MT-FSM response tới SMS-C với SMS delivery
report.
24 IP-SM-GW thông báo việc gửi tin nhắn SMS tới HLR qua MAP Report SM
/
2.5.4 Failure when send message of LTE-terminal
Bướ
Mô tả
c
7 IP-SM-GW đối chiếu MT-FSM request sử dụng correlation ID và quyết định gửi tới
UE qua miền IMS.
IP-SM-GW tạo SIP MESSAGE (Content-Type: Application/vnd.3gpp.sms với body
là
/
11 S-CSCF kiểm tra thuê bao không đăng kí hoặc việc gửi tới UE B xảy ra lỗi
12 S-CSCF phản hồi lại 4xx/5xx/6xx tới IP-SM-GW
13 IP-SM-GW gửi bản tin MT-FSM request tới VMSC để gửi tin nhắn tới UE-B theo
miền CS
14 VMSC phản hồi MT-FSM response thông báo gửi tin nhắn thành công
15 IP-SM-GW gửi bản tin phản hồi MT-FSM response tới SMS-C với SMS delivery
report.
16 IP-SM-GW thông báo việc gửi tin nhắn SMS tới HLR qua MAP Report SM
/
2.6 Supplementary service
Kiến trúc dịch vụ IMS
2.6.1 Dịch vụ OIP

Định nghĩa dịch vụ:
- Originating Identification Presentation – OIP – là dịch vụ cho phép thuê bao đích (called)
có thể thấy được định danh của thuê bao gọi (calling) trên thiết bị của mình khi nhận
được yêu cầu thiết lập cuộc gọi.
- Dịch vụ OIP được thực hiện trên MMTel phục vụ thuê bao nhận (called).
Luồng bản tin:
Kí hiệu:
A-UE: Thuê bao thực hiện cuộc gọi
B-UE: Thuê bao đăng ký dịch OIP
A-TAS: TAS phục vụ thuê bao A-UE
B-TAS: TAS phục vụ thuê bao B-UE
/
Bướ Mô tả
c
1-4 A muốn thực hiện gọi cho B, A-UE gửi SIP INVITE tới B-UE. Bản tin 100 Trying
phản hồi cho bản tin SIP INVITE
3 Khi nhận được bản tin INVITE yêu cầu thiết lập cuộc gọi, MMTel của thuê bao
nhận sẽ thực hiện các bước sau:
- Kiểm tra việc đăng ký/kích hoạt dịch vụ OIP của thuê bao nhận và cấu hình
của nhà mạng.
- Thực hiện chỉnh sửa bản tin INVITE và gửi đến thuê bao nhận.
5-7 B-UE gửi bản tin 200 OK tới A-UE
Xử lý bản tin:
Trạng thái dịch vụ Kiểm tra bản tin Xử lý bản tin
Register N/A - MMTel sẽ xoá các trường P-Asserted-

OIP Identity, nếu có.
- MMTel sẽ xoá trường Privacy, nếu có.
Không xoá Privacy nếu có giá trị “id”
- MMTel thay đổi giá trị của trường
From thành
/
<sip:anonymous@anonymous.invalid>
Active OIR - MMTel xoá trường Privacy, nếu có. (Không

N/A
override xoá Privacy nếu có giá trị “id”)
Không có Privacy
hoặc Privacy = - Áp dụng thủ tục bình thường
“none”
- MMTel sẽ xoá các P-Asserted-

Privacy = “id”
Identity, nếu có.
- MMTel xoá tất cả các trường chứa

Not thông tin thuê bao mức “header”.
register - Xoá giá trị “header”
OIP Not active Privacy = “header” - Thêm giá trị “id” vào Privacy
OIR override - MMTel thay đổi giá trị của trường
From thành
- MMTel xoá tất cả các trường chứa

thông tin thuê bao mức “user”.
- Xoá giá trị “user”
Privacy = “user”
- MMTel thay đổi giá trị của trường
From thành
2.6.2 Dịch vụ OIR

- Originating Identification Restriction – OIR – là dịch vụ cho phép thuê bao gọi (calling)
ẩn thông tin định danh của mình trên thiết bị của thuê bao đích (called) khi yêu cầu thiết
lập cuộc gọi.
- Dịch vụ OIR được thực hiện trên MMTel của calling khi gửi yêu cầu thiết lập cuộc gọi
đến called.
Luồng bản tin:
Kí hiệu:
/
Xử lý bản tin
Register - Thay đổi From thành

OIR <sip:anonymous@anonym
Permanent ous.invalid>
N/A Không chứa Privacy
- MMTel thêm Privacy với
giá trị theo cấu hình
restriction của nhà mạng.
N/A Privacy = “none” - Thay đổi From thành

<sip:anonymous@anonym
ous.invalid>
- MMTEL xoá giá trị “none”
và thêm giá trị của Privacy
theo cấu hình restriction
của nhà mạng
/
- Thay đổi From thành
ous.invalid>
N/A Privacy khác “none” - MMTEL thêm giá trị theo
cấu hình restriction của
nhà mạng vào trường
Privacy, nếu chưa có
Privacy có giá trị “none” - Thay đổi From thành

hoặc có giá trị như cấu <sip:anonymous@anonym
hình của nhà mạng ous.invalid>
- MMTel thêm Privacy với

giá trị theo cấu hình
restriction của nhà mạng.
Không có Privacy
Restricted
ous.invalid>

Privacy có giá trị khác
Register ous.invalid>
“none” hoặc có giá trị
OIR - MMTEL thêm giá trị theo
khác cấu hình của nhà
Temporary cấu hình restriction của
mạng
Không có Privacy hoặc - Áp dụng thủ tục bình

Privacy = “none” thường
- MMTEL thêm giá trị theo

cấu hình restriction của
Not Restricted Privacy có giá trị khác
“none” hoặc có giá trị
khác cấu hình của nhà
mạng Thay đổi From thành
<sip:anonymous@anonymous.inv
alid>
Not active - Áp dụng thủ tục bình

N/A N/A
OIR thường
/
2.6.3 Dịch vụ TIP
- Terminating Identification Presentation – là dịch vụ cho phép thuê bao gọi (calling) thấy
được định danh của thuê bao đích (called) trong quá trình yêu cầu thiết lập cuộc gọi.
- Dịch vụ TIP được thực hiện trên MMTel của calling khi gửi yêu cầu thiết lập cuộc gọi
đến called.
Luồng bản tin:
Kí hiệu:
Xử lý bản tin
Active TIP TIR Override INVITE có trường - Áp dụng thủ tục bình
Supported với giá trị là thường
”from-change”
/
- MMTel sẽ xoá Privacy,
Bản tin SIP Response
nếu có.
không có Privacy hoặc
(Không xoá Privacy
Privacy với bất kỳ giá trị
trong trường hợp có giá
nào
trị là “id”)
INVITE có trường
- Áp dụng thủ tục bình
Supported có giá trị là
thường
”from-change”
Bản tin SIP Response

- Áp dụng thủ tục bình
không có Privacy hoặc
TIR Not- thường
Privacy = “none”
Override
- MMTel sẽ thêm giá trị
Bản tin SIP Response có “id” vào trường Privacy,
Privacy với bất kỳ giá trị nếu chưa có
khác “none” - Xoá các P-Asserted-
Identity, nếu có
- MMTel sẽ xoá giá trị

N/A Bản tin INVITE “from-change” nếu có
trong Supported
Not active - MMTel sẽ xoá các P-

TIP Bản tin SIP Response Asserted-Identity và
không chứa Privacy hoặc Privacy, nếu có.
N/A
có Privacy với bất kỳ giá (Không xoá Privacy
trị nào trong trường hợp có giá
trị là “id”)
2.6.4 Dịch vụ TIR

- Terminating Identification Restriction – TIR – là dịch vụ cho phép thuê bao đích (called)
ẩn thông tin của mình trên thiết bị của thuê bao gọi (calling) trong quá trình thiết lập cuộc
gọi.
- Dịch vụ TIR được thực hiện trên MMTel của called khi nhận được yêu cầu thiết lập cuộc
gọi từ calling.
Luồng bản tin:
Kí hiệu:
/
Xử lý bản tin
INVITE có Supported
MMTel sẽ xoá giá trị “from-
N/A với giá trị là “from-
change”
change”
SIP Response không có

Privacy hoặc có Privacy MMTel thêm Privacy với giá trị
Active TIR N/A
với bất kỳ giá trị khác là “id”, nếu chưa có
Permanent
“none”
mode
- MMTel sẽ xoá giá trị
“none”.
SIP Response có Privacy
N/A - Thêm giá trị “id” vào
với giá trị là “none”
trường Privacy, nếu chưa
có
/
SIP Response không có - MMTel sẽ thêm Privacy
Privacy có giá trị là “id”
Active TIR Restricted
SIP Response có Privacy - Áp dụng thủ tục bình
Temporary
với bất kỳ giá trị nào thường
mode
Not- - Áp dụng thủ tục bình
N/A
Restricted thường
2.6.5 Dịch vụ Call Barring

2.6.5.1 Dịch vụ OCB
Giả sử:
- Thuê bao A đã đăng kí thành công vào mạng IMS

- Thuê bao A đăng ký dịch vụ chặn cuộc gọi đi (OCB) đến thuê bao B
- Thuê bao A thực hiện gọi cho thuê bao B
- Chặn cuộc gọi đi gồm các loại sau: Chặn quốc tế, chặn theo số điện thoại, chặn theo
nhóm số điện thoại, chặn theo thời gian, chặn cuộc gọi video, chặn cuộc gọi khi roaming
Luồng bản tin:
Kí hiệu:
UE-A: Thuê bao đăng ký dịch vụ OCB
UE-B: Thuê bao nằm trọng tập bị chặn của thuê bao UE-A
S-CSCF: S-CSCF phục vụ thuê bao UE-A
O-TAS: TAS phục vụ thuê bao UE-A
/
sd Barring of All Outgoing Calls
UE-A S-CSCF O TAS UE-B
1. INVITE()
2. 100 Trying()
3. iFC()
4. INVITE()
5. 100 Trying()
OCB
6. 603-Decline()
7. 603-Decline()
8. ACK()
9. ACK()
Bướ Mô tả
c
1-5 Bản tin SIP INVITE được gửi tới O-TAS. O-TAS kiểm tra có UE-A có đăng ký
dịch vụ OCB hay không? Và thuê bao UE-B có nằm trong tập bị chặn hay không. và
dịch vụ OCB đối với
6-7 O-TAS gửi bản tin 603-Decline tới UE-A
8-9 UE-A gửi bản tin ACK tới O-TAS
2.6.5.2 Dịch vụ ACR

Giả sử:

- Thuê bao B đăng ký dịch vụ chặn cuộc gọi đến ẩn danh (ACR) đối với thuê bao A
- Thuê bao A thực hiện gọi ẩn danh cho thuê bao B.
Luồng bản tin:
Kí hiệu:
UE-A: Thuê bao thực hiện cuộc gọi ẩn danh
UE-B: Thuê bao đăng ký dịch vụ chặn cuộc gọi đến ẩn danh (ACR)
S-CSCF: S-CSCF phục vụ thuê bao UE-B
/
T-TAS: TAS phục vụ thuê bao UE-B
sd Anonymous Communication Rej ection
Gate S-CSCF TAS UE-B
1. INVITE()
2. 100 Trying()
3. iFC()
4. INVITE()
5. 100 Trying()
6. ACR
7. 433 Anonymity()
8. 433 Anonymity()
9. ACK()
10. ACK()
Bước Mô tả
1-2 UE-A gửi bản tin SIP INVITE tới S-CSCF phục vụ thuê bao UE-B. Bản tin
INVITE chứa “Privacy header” được gán một trong các giá trị: "id" hoặc "header"
hoặc "user".
3 S-CSCF thực hiện đánh giá iFC và xác định UE-B đăng ký ACR.
4-5 S-CSCF gửi bản tin INVITE đến ICB AS (T-TAS) và T-TAS gửi trả lại bản tin 100
Trying
6 T-TAS phục vụ thuê bao UE-B xác định cuộc gọi đến từ thuê bao UE-A là cuộc gọi
ẩn danh
7-8 T-TAS gửi bản tin 433-Anonymity tới UE-A
9 - 10 UE-A gửi bản tin ACK tới UE-B
2.6.5.3 Dịch vụ ICB

Giả sử:

- Thuê bao B đăng ký dịch vụ chặn cuộc gọi đến (ICB) đối với thuê bao A
/
- Chặn cuộc gọi đến (ICB) gồm các loại sau: Chặn theo số điện thoại, chặn theo nhóm số
điện thoại, chặn theo thời gian, chặn cuộc gọi video/voice, chặn cuộc gọi được chuyển
tiếp, chặn cuộc gọi ẩn danh.
Luồng bản tin:
Kí hiệu:
UE-A: Thuê bao thực hiện cuộc gọi
UE-B: Thuê bao đăng ký dịch vụ chặn cuộc gọi đến và thuê bao UE-A nằm trong tập bị chặn
S-CSCF: S-CSCF phục vụ thuê bao UE-B
T-TAS: TAS phục vụ thuê bao UE-B
sdICR
GATE S-CSCF T-TAS UE-B
1. INVITE
2. 100 Trying
3. iFC()
4. INVITE
5. 100 Trying
6. ICR
7. 603 Decline
8. 603 Decline
9. ACK
10. ACK
Bước Mô tả
1-2 UE-A gửi bản tin SIP INVITE tới S-CSCF phục vụ thuê bao UE-B. Bản tin
INVITE chứa “Privacy header” được gán một trong các giá trị: "id" hoặc "header"
hoặc "user".
3 S-CSCF thực hiện đánh giá iFC và xác định UE-B đăng ký ICB.
/
4-5 S-CSCF gửi bản tin INVITE đến ICB AS (T-TAS) và T-TAS gửi trả lại bản tin 100
Trying
6 T-TAS phục vụ thuê bao UE-B xác định UE-A nằm trong tập bị chặn.
7-8 TAS gửi bản tin 603-Decline tới UE-A
9 - 10 UE-A gửi bản tin ACK tới UE-B
2.6.6 Dịch vụ CF
Communication Forwarding (CF) là dịch vụ cho phép chuyển hướng cuộc gọi tới một thuê bao
đích khác
2.6.6.1 Dịch vụ CFU
- Communication Forwarding Unconditional – CFU – là dịch vụ cho phép thuê bao đích
chuyển hướng cuộc gọi tới một thuê bao khác trong mọi trường hợp.
Giả sử:

- Thuê bao B đăng ký dịch vụ CFU và chuyển tiếp cuộc gọi cho thuê bao C
- Thuê bao B nhận được cuộc gọi từ thuê bao A sẽ chuyển tiếp cuộc gọi cho thuê bao C.
Luồng bản tin:
Kí hiệu:
B-UE: Thuê bao đăng ký dịch CFU, thực hiện chuyển hướng cuộc gọi của A-UE tới C-UE
C-UE: Thuê bao nhận cuộc gọi được chuyển hướng từ thuê bao B-UE
C-TAS: TAS phục vụ thuê bao C-UE
/
sd CFU
A-UE A-TAS B-TAS B-UE C-TAS C-UE
1. INVITE(URI=SIPURI-B)
2. 100 Trying()
4. 100 Trying()
5. CFU Logic
6. 181-Call is being forwarded()
7. 181-Call is being forwarded()

8. INVITE(URI=SIPURI-C)
9. 100 Trying()
11. 100 Trying()
12. 200 OK()
13. 200 OK()
14. 200 OK()
15. 200 OK()
16. ACK()
17. ACK()
18. ACK()
19. ACK()
20. RTP
21. BYE()
22. BYE()
23. BYE()
24. BYE()
25. 200 OK()
26. 200 OK()
27. 200 OK()
28. 200 OK()
Bước Mô tả
1-4 A muốn thực hiện gọi cho B, A-UE gửi SIP INVITE tới P-CSCF phục vụ A-UE
và P-CSCF gửi chuyển tiếp bản tin tới B-TAS. Bản tin 100 Trying phản hồi cho
bản tin SIP INVITE.
5 B-TAS thực hiện thủ tục kiểm tra dịch vụ CFU có active hay không bằng cách
kiểm tra trong file cấu hình có được ở bản tin UDA.
6-7 Nếu giá trị trong thẻ <notify-caller> là true thì B-TAS thực hiện gửi bản tin “181-
Call is being forwared” tới A-UE
7-11 B-TAS gửi bản tin SIP INVITE (SIPURI là C-UE) tới C-UE
12-15 C-UE gửi bản tin 200 OK về A-UE
16-19 A-UE gửi bản tin ACK tới C-UE
20 Luồng RTP giữa A-UE và C-UE được thiết lập.
21-24 Sau khi đàm thoại và giả sử thuê bao C-UE thực hiện kết thúc cuộc gọi. C-UE gửi
bản tin BYE kết thúc cuộc gọi về A-UE
25-28 A-UE gửi bản tin 200 OK tới C-UE
/
2.6.6.2 Dịch vụ CFB
- Communication Forwarding Busy – CFB – là dịch vụ cho phép thuê bao đích chuyển
hướng cuộc gọi tới một thuê bao khác khi thuê bao đích đang bậnsss.
Giả sử:

- Thuê bao B đăng ký dịch vụ CFB và chuyển tiếp cuộc gọi cho thuê bao C
- Thuê bao B nhận được cuộc gọi từ thuê bao A sẽ chuyển tiếp cuộc gọi cho thuê bao C.
Luồng bản tin:
Kí hiệu:
B-UE: Thuê bao đăng ký dịch CFB, thực hiện chuyển hướng cuộc gọi của A-UE tới C-UE
/
sd CFB
2. 100 Trying()
4. 100 Trying()
6. 100 Trying()
7. 486 Busy Here()
8. CFB Logic
9. 181 Call is being forwarded()

12. 100 Trying()
14. 100 Trying()
15. Ringing()
16. Ringing()
17. Ringing()
19. 200 OK()
18. Ringing()
20. 200 OK()
21. 200 OK()

22. 200 OK()
23. ACK()
24. ACK()
25. ACK()
26. ACK()
27. RTP
28. BYE()
29. BYE()
30. BYE()
31. BYE()
32. 200 OK()
33. 200 OK()
34. 200 OK()
35. 200 OK()
Bước Mô tả
1-6 A muốn thực hiện gọi cho B, A-UE gửi SIP INVITE tới P-CSCF phục vụ A-UE và
P-CSCF gửi chuyển tiếp bản tin tới B-TAS. Bản tin 100 Trying phản hồi cho bản
tin SIP INVITE.
7 B-UE đang bận (đang trong một cuộc gọi khác hoặc bấm Busy), sẽ gửi về bản tin
486-Busy Here tới B-TAS, B-TAS sẽ kiểm tra trong file cấu hình xem B-UE có
đăng ký dịch vụ CFB hay không.
8 - 10 Nếu B-UE đăng ký dịch vụ CFB và giá trị trong thẻ <notify-caller> là “true” thì B-
TAS gửi bản tin SIP 181-Call is being forwarded tới A-UE.
11-14 B-TAS gửi bản tin INVITE tới thuê bao đích là C-UE với header “To” header trong
bản tin SIP INVITE là SIPURI-C. Bản tin 100 Trying phản hồi cho bản tin SIP
INVITE.
/
15-18 C-UE gửi bản tin SIP 180-Ringing về A-UE
19-22 C-UE gửi bản tin SIP 200 OK về A-UE
23-26 A-UE gửi bản tin ACK về C-UE
28-31 Sau khi đàm thoại và giả sử thuê bao C-UE thực hiện kết thúc cuộc gọi. C-UE gửi
bản tin BYE kết thúc cuộc gọi về A-UE
32-35 A-UE gửi bản tin phản hồi 200 OK tới C-UE
2.6.6.3 Dịch vụ CFNL

- Communication Forwarding on Not Logged in – CFNL – là dịch vụ cho phép thuê bao
đích chuyển hướng cuộc gọi tới một thuê bao khác khi thuê bao đích chưa register vào
mang (logged in).
Giả sử:
- Thuê bao A đã đăng kí thành công vào mạng IMS

- Thuê bao B đăng ký dịch vụ CFNL và chuyển tiếp cuộc gọi cho thuê bao C
- B-TAS phục vụ thuê bao B xác định thuê bao B chưa register vào mạng nên sẽ chuyển
hướng cuộc gọi tới thuê bao C.
Luồng bản tin:
Kí hiệu:
/
sd CFNL
2. 100 Trying()
4. 100 Trying()
5. CFNL Logic
6. 181 Call is being forwared()
7. 181 Call is being forwared()

9. 100 Trying()
11. 100 Trying()
12. Ringing()
13. Ringing()
14. Ringing()
15. Ringing()
16. 200 OK()
17. 200 OK()
18. 200 OK()
19. 200 OK()
20. ACK()
21. ACK()
22. ACK()
23. ACK()
24. RTP
25. BYE()
26. BYE()
27. BYE()
28. BYE()
29. 200 OK()
30. 200 OK()
31. 200 OK()
32. 200 OK()
Bước Mô tả
P-CSCF gửi chuyển tiếp bản tin tới B-TAS. Bản tin 100 Trying phản hồi cho bản
tin SIP INVITE.
5 B-TAS kiểm tra B-UE có đăng ký dịch vụ CFNL hay không. Nếu có thì thực hiện
thủ tục chuyển hướng cuộc gọi.
6-7 Nếu thuê bao B-UE đăng ký dịch vụ CFNL và giá trị trong thẻ <notify-caller> là
“true” thì gửi bản tin SIP 181-Call is being forwarded tớis A-UE.
8-11 B-TAS gửi chuyển tiếp bản tin SIP INVITE tới thuê bao đích C-UE với header
“To” là SIPURI-C. Bản tin 100 Trying phản hồi cho bản tin SIP INVITE.
12-15 C-UE gửi bản tin Sip 180-Ringing về A-UE
/
25-28 Sau khi đàm thoại và giả sử C-UE thực hiện kết thúc cuộc gọi. C-UE gửi bản tin
BYE kết thúc cuộc gọi về A-UE
2.6.6.4 Dịch vụ CFNRy

- Communication Forwarding on No Reply – CFNR – là dịch vụ cho phép thuê bao đích
chuyển hướng cuộc gọi tới một thuê bao khác khi thuê bao đích không trả lời cuộc goi.
Giả sử:

- Thuê bao B đăng ký dịch vụ CFNR và chuyển tiếp cuộc gọi cho thuê bao C
- Thuê bao B nhận được tín hiệu cuộc gọi nhưng không trả lời cuộc gọi, sau một khoảng
thời gian thì cuộc gọi sẽ được chuyển tiếp tới thuê bao C.
Luồng bản tin:
Kí hiệu:
/
sd CFNR
2. 100 Trying()
4. 100 Trying()
6. 100 Trying()
7. 180 Ringing()
8. Start timer
9. 180 Ringing()
10. 180 Ringing()
11. End timer
12. Cancel()
13. 200 OK (Cancel)
16. 487 Request Terminated()
17. ACK()
19. 100 Trying()
21. 100 Trying()
22. 180 Ringing()

23. 180 Ringing()
24. 180 Ringing()
26. 200 OK(INVITE)
25. 180 Ringing()
27. 200 OK(INVITE)
28. 200 OK(INVITE)
29. 200 OK(INVITE)
30. ACK()
31. ACK()
32. ACK()
33. ACK()
34. RTp
35. BYE()
36. BYE()
37. BYE()
38. BYE()
39. 200 OK()
40. 200 OK()
41. 200 OK()

42. 200 OK()
Bước Mô tả
P-CSCF gửi chuyển tiếp bản tin tới B-UE. Bản tin 100 Trying phản hồi cho bản tin
SIP INVITE.
7-10 B-UE gửi bản tin SIP 180 Ringing B-TAS. B-TAS sẽ thực hiện bật timer (bước 8)
và gửi chuyển tiếp bản tin 180 Ringing tới A-UE.
11 Sau khoảng thời gian timeout thì timer kết thúc.
/
12 Nếu B-UE đăng ký dịch vụ CFNR thì B-TAS gửi bản tin CANCEL tới B-UE.
13 B-UE gửi bản tin 200 OK (CANCEL) về B-TAS.
14-15 Nếu giá trị trong thẻ <notify-caller> là “true” thì B-TAS gửi bản tin SIP 181-Call
is being forwarded tới A-UE.
16 B-UE sau khi nhận được bản tin CANCEL và phản hồi bằng bản tin 200 OK
(CANCEL) thì sẽ gửi bản tin SIP 487 Request Terminated tới B-TAS.
17 B-TAS phản hồi bản tin 487 Request Terminated bằng bản tin ACK.
18-21 B-TAS gửi bản tin SIP INVITE tới thuê bao đích C-UE với header “To” là
SIPURI-C. Bản tin 100 Trying phản hồi cho bản tin SIP INVITE.
22-25 C-UE gửi bản tin SIP 180 Ringing tới A-UE.
26-29 C-UE gửi bản tin 200 OK (INVITE) tới A-UE.
2.6.6.5 Dịch vụ CFNRc

- Communication Forwarding on Subscriber Not Reachablel – CFNRc – là dịch vụ cho

phép thuê bao đích chuyển hướng cuộc gọi tới một thuê bao khác khi network không thể
paging tới thuê bao đích.
Giả sử:

- Thuê bao B đăng ký dịch vụ CFNRc và chuyển tiếp cuộc gọi cho thuê bao C
- S-CSCF không thể paging được thuê bao B. Do đó, cuộc gọi được chuyển tiếp tới thuê
bao C.
Luồng bản tin:
Kí hiệu:
B-UE: Thuê bao đăng ký dịch CFNRc, thực hiện chuyển hướng cuộc gọi của A-UE tới C-UE
/
A - S-TAS: S-CSCF phục vụ thuê bao A-UE
B - S-TAS: S-CSCF phục vụ thuê bao B-UE
C - S-TAS: S-CSCF phục vụ thuê bao C-UE
sd CFNRc
A-UE A - S-CSCF B-TAS B - S-CSCF B - P-CSCF B-UE C - S-CSCF C-UE
7. Request Timeout
8. 408 Request Ti meout()
9. 408 Request Ti meout()
10. CFNRc logic
12. 181 Call i s being forwarded()
16. 180 Ri nging()
17. 180 Ringi ng()
18. 180 Ri nging()
19. 180 Ringi ng()
20. 180 Ri nging()

22. 200 OK()
21. 180 Ri nging()

23. 200 OK()
24. 200 OK()
25. 200 OK()
26. 200 OK()
27. 200 OK()
28. ACK()
29. ACK()
30. ACK()
31. ACK()
32. ACK()
33. ACK()
34. RTP
35. BYE()
36. BYE()
37. BYE()
38. BYE()
39. BYE()
40. BYE()
41. 200 OK()
42. 200 OK()
43. 200 OK()
44. 200 OK()
45. 200 OK()
46. 200 OK()
Bước Mô tả
1-6 A muốn thực hiện gọi cho B, A-UE gửi SIP INVITE tới B-UE. Tại mỗi node, khi
/
nhận được bản tin INVITE thì phản hồi bằng bản tin SIP 100 Trying.
7 Tuy nhiên, do B – P-CSCF phục B-UE không thể paging tới B-UE trong khoảng
thời gian timeout.
8-9 B – P-CSCF gửi bản tin SIP 408 Request Timeout tới B-TAS.
10 B-TAS kiểm tra dịch vụ CNNRc đối với thuê bao B-UE.
11-12 Nếu thuê bao B-UE đăng ký dịch vụ CFNRc và giá trị trong thẻ <notify-caller> là
“true” thì B-TAS gửi bản tin SIP 181-Call is being forwarded tớis A-UE.
13-15 B-TAS gửi chuyển tiếp bản tin SIP INVITE tới thuê bao đích C-UE với header
“To” là SIPURI-C. Tại mỗi node, khi nhận được bản tin INVITE thì phản hồi bằng
bản tin SIP 100 Trying.
16-21 C-UE gửi bản tin Sip 180-Ringing về A-UE
2.6.7 Dịch vụ CW
- Communication Waiting – CW – là dịch vụ cho phép thuê bao vẫn có thể nhận được tín
hiệu cuộc gọi tới trong khi đang đàm thoại. Và:
o Thuê bao có thể kết thúc cuộc gọi hiện hành để trả lời cuộc gọi mới
o Hoặc tạm thời ngưng cuộc gọi hiện hành (nếu dung dịch vụ Call Hold) để chuyển
sang cuộc gọi mới.
o Hoặc vẫn giữ cuộc gọi hiện hành và không trả lời cuộc gọi mới.
Các cơ chế thực hiện dịch vụ CW:
- Thực hiện CW dựa vào tín hiệu của network (CW based network)
- Thực hiện CW dựa vào tín hiệu của user (CW based user)
- Thực hiện CW dựa vào tín hiệu timer (CW based timer)
2.6.7.1 Dịch vụ CW based network
Giả sử:
/
- Thuê bao A, B và C đã đăng kí thành công vào mạng IMS
- Thuê bao A và B đang đàm thoại
- Thuê bao B đăng ký dịch vụ CW
- Thuê bao C thực hiện gọi cho thuê bao B
- Network xác định thuê bao B đang bận, thực hiện dịch vụ CW đối với cuộc gọi từ thuê
bao C đến thuê bao B.
Luồng bản tin:
Kí hiệu:
A-UE: Thuê bao đang đàm thoại với thuê bao B-UE
B-UE: Thuê bao đăng ký dịch CW và đang trong cuộc đàm thoại với thuê bao A-UE
C-UE: Thuê bao thực hiện cuộc gọi tới thuê bao B-UE
B - S-CSCF: S-CSCF phục vụ thuê bao B-UE
sd Netw ork based CW
O-Gate B - TAS B - S-CSCF B - UE
1. INVIT E()
2. INVITE()
2a. the AS determines the

approaching NDUB’ condition
and inserts a CW indication in
the INVITE request
3. INVIT E([CW indication])
4. INVITE([CW indication])
5. 180 Ringing()
6. 180 Ringing()
5a. Possibility for User B to

6a. the AS inserts a Alert-Info react: release session, inv oke
header w ith a CW urn into the HOLD, ...]?not part of CW
180 Ringing response
7. 180 Ringing([Alert-Info:
urn:alert:service:
call-waiting])
7a. the AS has the

possibility to generate a CW
announcement
8. 180 Ringing([Alert-Info:urn:alert:service:call-waiting])
9. 200 OK()
10. 200 OK()
11. 200 OK()
12. 200 OK()
/
Bước Mô tả
1-2 A-UE đang đàm thoại với B-UE.

C-UE muốn thực hiện gọi cho B-Ue, C-UE gửi SIP INVITE tới B-UE. Bản tin 100
Trying phản hồi cho bản tin SIP INVITE.
2a B-TAS kiểm tra B-UE có đăng ký dịch vụ CW theo cơ chế “approaching NDUB”
hay không? Thông tin đăng ký dịch vụ CW được lấy trong file cấu hình ở bản tin
UDA.
3-4 B-TAS chèn thẻ “CW indication” vào bản tin SIP INVITE và gửi chuyển tiếp tới
B-UE.
5-6 B-UE gửi bản tin SIP 180 Ringing tới B-TAS
6a B-TAS chèn thêm thẻ “CW indication” vào bản tin SIP 180 Ringing.
7-8 B-TAS gửi chuyển tiếp bản tin SIP 180 Ringing (đã chèn thẻ “CW indication”) tới
C-UE
7a B-TAS có thể thực hiện thủ tục phát thông báo (optional)
9 - 12 B-UE gửi bản tin 200 OK về A-UE
2.6.7.2 Dịch vụ CW based user

Giả sử:

- Thuê bao B đang bận (đang trong một cuộc gọi khác) sẽ gửi tín hiệu “CW indication” tới
network.
- MMTel phục vụ thuê bao B-UE nhận được bản tin 200 OK trước khi CW timer kết thúc
Luồng bản tin:
Kí hiệu:
/
sd CW Successful communication establishment
A-Gate B - TAS B - S-CSCF B - UE
1. INVIT E()
2. INVITE()
3. INVITE()
4. INVIT E()
5. 183 Session Progress()

urn:alert:service:call-waiting])
10a. CW timer starts
[9a. Possibility for

User B to react:
release session,
inv oke HOLD, ...]?not
12. 180 Ringing([Alert-Info:urn:alert:service:call-waiting]) part of CW
11a. AS may initiate CW

announcement
13. 200 OK()
14. 200 OK()
14a. CW timer stops
15. 200 OK()
16. 200 OK()
Bước Mô tả

5-8 B-UE gửi bản tin phản hồi SIP 180 Session Progress tới UE-C.
9-12 B-UE gửi bản tin SIP 180 Ringing chèn thêm chỉ thị “CW indication” tới C-UE
10a B-TAS bật CW timer.
11a B-TAS có thể gửi thông báo cuộc gọi đang CW cho C-UE
13-16 B-UE gửi bản tin 200 OK tới C-UE.
14a B-TAS nhận được bản tin 200 OK trước khi timer kết thúc
/
2.6.7.3 Dịch vụ CW based timer
Giả sử:

- Thuê bao B đang bận (đang trong một cuộc gọi khác) sẽ gửi tín hiệu “CW indication” tới
network.
- MMTel phục vụ thuê bao B-UE không nhận được bản tin 200 OK trước khi CW timer
kết thúc
Luồng bản tin:
Kí hiệu:
/
sd Timer expires
A-Gate B - TAS B - S-CSCF B - UE
1. INVITE()
2. INVITE()
3. INVITE()
4. INVITE()

10a. CW timer starts
[9a. Possibility for

11. 180 Ringing([Alert-Info: User B to react:
urn:alert:service:call-waiting]) release session,
inv oke HOLD, ...]?not
part of CW
12. 180 Ringing([Alert-Info:urn:alert:service:call-waiting])
11a. AS may initiate CW

announcement
11b. CW timer expires
13. CANCEL()
14. CANCEL()
15. 480 Temporarily unavailable()
16. 480 Temporarily unavailable()
Bước Mô tả

5-8 B-UE gửi bản tin phản hồi SIP 180 Session Progress tới UE-C.
9-12 B-UE gửi bản tin SIP 180 Ringing chèn thêm chỉ thị “CW indication” tới C-UE.
10a B-TAS bật CW timer.
11a B-TAS có thể gửi thông báo cuộc gọi đang CW cho C-UE.
11b CW timer timeout trước khi nhận được bản tin 200 OK từ B-UE.
13-14 B-TAS gửi bản tin CANCEL tới B-UE.

/
15-16 B-TAS gửi bản tin SIP 480 Temporarily tới A-UE.
2.6.8 Dịch vụ CH
Định nghĩa dịch vụ: Communication Hold – CH – là dịch vụ cho phép một một thuê bao tạm
dừng luồng/các luồn media (Call Hold) của một cuộc gọi và sau đó có thể phục hồi (Call
Resume) lại cuộc gọi.
2.6.8.1 HOLD Communication
2.6.8.1.1 HOLD communication with announcement
Giả sử:

- Thuê bao A đăng ký dịch vụ CH
- Thuê bao A thực hiện gọi cho thuê bao B và tiến hành đàm thoại
- Thuê bao A chủ động thực hiện thủ tục CH để tạm dừng luồng media giữa thuê bao A và
thuê bao B.
- Phát thông báo áp dụng dịch vụ CH cho cuộc gọi tới thuê bao B
Luồng bản tin:
Kí hiệu:
B-UE: Thuê bao đăng ký dịch CH
A – S-CSCF: S-CSCF phục vụ thuê bao A-UE
B – S-CSCF: S-CSCF phục vụ thuê bao B-UE
A-TAS/MRF: TAS/MRF phục vụ thuê bao A-UE
B-TAS/MRF: TAS/MRF phục vụ thuê bao B-UE
/
sd HOLD communication w ith announcement
A - UE A - S-CSCF A - TAS/MRF B - TAS/MRF B - S-CSCF B - UE
RTP
RTCP
1. INVITE(a=sendonly)
3. Reserv e resources
4. INVIT E(a=sendonly)
7. INVIT E(a=sendonly)
9. 200 OK(a=recvonly)
14. Start playing announcement
17. ACK()
18. ACK()
19. ACK()
20. ACK()
21. ACK()
22. ACK()
23. ACK()
RTCP
Bước Mô tả
1-2 Thuê bao A-UE và B-UE đang đàm thoại.

Thuê bao A-UE thực hiện thủ tục tạm dừng cuộc gọi (Call Hold) bằng cách gửi bản
tin SIP INVITE tới A-TAS/MRF chứa SDP thay đổi như sau:
- a=sendonly: nếu luồng media của cuộc gọi là “sendrecv media stream”
3 A-TAS/MRF cấu hình bearer thông báo cho B-UE.
4-8 A-TAS/MRF gửi chuyển tiếp bản tin SIP INVITE tới B-UE.
9-13 B-UE gửi bản tin SIP 200 OK với SDP a=recvonly tới A-TAS/MRF.
14 A-TAS/MRF phát thông báo tới B-UE.
15-16 A-TAS/MRF gửi chuyển tiếp bản tin 200 OK tới A-UE.
17-23 A-UE gửi bản tin ACK tới B-UE
24 Chỉ còn luồng RTCP trao đổi giữa A-UE và A-TAS/MRF. Luồng RTP giữa A-UE
và B-UE đã tạm dừng.
/
2.6.8.1.2 HOLD communication with modification of the SDP answer
Giả sử:

thuê bao B.
- Phát thông báo áp dụng dịch vụ CH cho cuộc gọi tới thuê bao B
Luồng bản tin:
Kí hiệu:
/
sd HOLD communication w ith modification of the SDP answ er
A - UE A - S-CSCF A - TAS/MRF B - TAS/MRF B - S-CSCF B - UE
RTP
RTCP
1. INVITE(sendonly)
3. Reserv e resources
14. Start playing announcement
15. 200 OK(a=recvonly,

b=AS:0, b=RS:800,
b=RR:800)
16. 200 OK(a=recvonly,

b=AS:0, b=RS:800,
b=RR:800)
17. ACK()
18. ACK()
19. ACK()
20. ACK()
21. ACK()
22. ACK()
23. ACK()
24. RTCP
Bước Mô tả
1-2 Thuê bao A-UE và B-UE đang đàm thoại.

Thuê bao A-UE thực hiện thủ tục tạm dừng cuộc gọi (Call Hold) bằng cách gửi bản
tin SIP INVITE tới A-TAS/MRF chứa SDP thay đổi như sau:
- a=sendonly
3 A-TAS/MRF cấu hình bearer thông báo cho B-UE.
4-8 A-TAS/MRF gửi chuyển tiếp bản tin SIP INVITE tới B-UE.
9-13 B-UE gửi bản tin SIP 200 OK với SDP a=recvonly tới A-TAS/MRF.
14 A-TAS/MRF phát thông báo tới B-UE.
15-16 A-TAS/MRF gửi chuyển tiếp bản tin 200 OK tới A-UE.
24 Chỉ còn luồng RTCP trao đổi giữa A-UE và A-TAS/MRF. Luồng RTP giữa A-UE
/
và B-UE đã tạm dừng.
2.6.8.1.3 HOLD communication without announcement
Giả sử:

thuê bao B.
- Không phát thông báo áp dụng dịch vụ CH cho cuộc gọi tới thuê bao B
Luồng bản tin:
Kí hiệu:
/
sd HOLD communication w ithout announcement
A - UE A - S-CSCF A - TAS B - TAS B - S-CSCF B - UE
RTP
15. ACK()
16. ACK()
17. ACK()
18. ACK()
19. ACK()
20. ACK()
21. ACK()
no RTP
Bước Mô tả
1-7 A-UE muốn phục hồi cuộc gọi với B-UE.

A-UE gửi bản tin SIP INVITE tới B-UE để phục hồi session bằng cách thay đổi SDP
trong bản tin SIP INVITE.
- “a=sendonly”: nếu luồng cuộc gọi trước đây là “sendrecv media stream”.
- “a=inactive”: nếu luồng cuộc gọi trước đây là “reconly media stream”.
15- A-UE gửi bản tin ACK tới B-UE

21
2.6.8.2 Resume Communication

Định nghĩa: Resume Communication – là quá trình hồi phục một cuộc gọi đã tạm dừng trước đó
(được thực hiện qua quá trình Hold Communication).
2.6.8.2.1 RESUME communication with announcement
Giả sử:
/
- Thuê bao A thực hiện gọi cho thuê bao B và đàm thoại. Sau đó, thuê bao A thực hiện
Hold cuộc gọi.
- Thuê bao A tiến hành thủ tục phục hồi cuộc gọi với thuê bao B.
- Thông tin phục hồi cuộc gọi được gửi tới thuê bao B
Luồng bản tin:
Kí hiệu:
sd RESUME communication w ith announcement
RTCP
1. INVITE(sendrecv)
2. INVITE(sendrecv)
3. Stop play announcement
4. INVITE(sendrecv)
5. INVITE(sendrecv)
6. INVITE(sendrecv)
7. INVITE(sendrecv)
8. INVITE(sendrecv)
9. 200 OK(recvonly)
10. 200 OK(sendrecv)
13. INVITE(sendrecv)
14. Realease resources
17. ACK()
18. ACK()
19. ACK()
20. ACK()
21. ACK()
22. ACK()
23. ACK()
24. RTP
25. RTCP
/
Bước Mô tả

A-UE gửi bản tin SIP INVITE tới B-UE để phục hồi session bằng cách thay đổi
SDP trong bản tin SIP INVITE.
- “a=sendrecv”: nếu luồng cuộc gọi trước đây là “sendonly media stream”. Giá trị
có thể vắng mặt vì mặc định là sendrecv.
3 A-TAS thực hiện thủ tục dừng phát thông báo
4-8 A-TAS gửi chuyển tiếp bản tin INVITE tới B-UE
9-16 B-UE gửi bản tin 200 OK tới A-UE với SDP a=sendrecv
15 A-TAS/MRF giải phóng tài nguyên dành cho phát thông báo
24-25 Luồng RTP và RTCP được thiết lập giữa A-UE và B-UE
2.6.8.2.2 RESUME communication without announcement
Giả sử:

- Thuê bao A thực hiện gọi cho thuê bao B sau đó tiến hành Hold cuộc gọi.
- Thuê bao A tiến hành thủ tục phục hồi cuộc gọi với thuê bao B.
- Thông tin phục hồi cuộc gọi không được gửi tới thuê bao B
Luồng bản tin:
Kí hiệu:
/
sd RESUME communication w ithout announcement
No TCP
1. INVITE(a=sendrecv)
8. 200 OK(a=sendrecv)
15. ACK()
16. ACK()
17. ACK()
18. ACK()
19. ACK()
20. ACK()
21. ACK()
RTP
Bước Mô tả

A-UE gửi bản tin SIP INVITE tới B-UE để phục hồi session bằng cách thay đổi SDP
trong bản tin SIP INVITE.
- “a=sendrecv”: nếu luồng cuộc gọi trước đây là luồng media. Giá trị bỏ giá trị này vì
mặc định sendrecv.
- “a=recvonly”: nếu luồng cuộc gọi trước đây không phải là luồng media.
2.6.9 Multi-party call (Ad hoc Conference)

Giả sử:
Dịch vụ kết hợp 2 phiên multimedia đang hoạt động giữa UE 1 và UE 2, UE 1 và UE 3 thành
một conference giữa UE1, UE 2 và UE 3.
/
Luồng bản tin:
/
Bước Mô tả
1 UE 1 đang thực hiện cuộc gọi với UE 2.
2 UE 1 đặt UE 2 ở chế độ HOLD.
3 UE 1 thực hiện cuộc gọi đến UE 3.
4 UE 1 gửi bản tin INVITE đến S-CSCF để chuyển tiếp đến Conference Server yêu
cầu thực hiện thiết lập conference giữa UE 1, UE 2 và UE 3.
5 S-CSCF gửi bản tin INVITE đến MTAS.
6 MTAS gửi bản tin INVITE có chứa SDP của UE 1 đến MRFC để thiết lập phiên
multimedia giữa UE 1 và MRFP.
7 MRFC phản hồi lại bản tin 200 OK chứa SDP của MRFP.
8 MTAS phản hồi bản tin 200 OK chứa SDP của MRFP chọn với UE 1 đến S-
/
CSCF.
9 S-CSCF chuyển tiếp bản tin 200 OK đến UE 1.
10 UE 1 gửi ACK cho S-CSCF.
11 S-CSCF chuyển tiếp ACK cho MTAS.
12 MTAS gửi ACK cho MRFC.
13 Kênh multimedia được thiết lập giữa UE 1 và Conference Server (AS + MRFC +
MRFP).
14 UE 1 gửi REFER đến UE 2 với trường Refer-To: Conference Server để transfer

cuộc gọi giữa UE 1 và UE 2 thành UE 2 và MRFP.
15 S-CSCF gửi REFER đến UE 2.
16 UE 2 phản hồi lại 200 OK của REFER tới S-CSCF.
17 S-CSCF chuyển tiếp 200 OK của REFER đến UE 1.
18 UE 2 gửi NOTIFY với body là dòng Request Line của 100 Trying đến S-CSCF
để thông báo về việc bản tin REFER đang được xử lý.
19 S-CSCF chuyển tiếp bản tin NOTIFY đến UE 1.
20 UE 1 phản hồi với 200 OK cho NOTIFY đến S-CSCF.
21 S-CSCF chuyển tiếp 200 OK đến UE 2.
22 UE 2 sau khi nhận được REFER đến CS sẽ gửi bản tin INVITE đến S-CSCF.
23 S-CSCF gửi INVITE của UE 2 đến MTAS.
24 MTAS gửi INVITE chứa SDP của UE 2 đến MRFC để thiết lập phiên multimedia
giữa UE 2 và MRFP.
25 MRFC phản hồi với 200 OK chứa SDP của MRFP chọn với UE 2.
26 MTAS gửi 200 OK đến S-CSCF.
28 UE 2 phản hồi ACK đến S-CSCF.
29 S-CSCF chuyển tiếp ACK đến MTAS.
30 MTAS gửi ACK đến MRFC.
31 Kênh multimedia được thiết lập giữa CS và UE 2.
32 UE 2 gửi NOTIFY có body là Request Line của 200 OK để thông báo là đã

transfer cuộc gọi giữa UE 1 và UE 2 thành CS và UE 2 thành công.
/
33 S-CSCF chuyển tiếp bản tin NOTIFY đến UE 1.
34 UE 1 phản hồi lại 200 OK cho NOTIFY.
36 UE 1 gửi BYE đến UE 2 để kết thúc phiên giữa UE 1 và UE 2.
37 S-CSCF chuyển tiếp BYE đến UE 2.
38 UE 2 phản hồi lại 200 OK cho BYE.
40-64 Tương tự các bước 14-39.
2.7 Emergency Call

2.7.1 CSFB for VoLTE UE in LTE emergency call
Giả sử:
- UE có khả năng CSFB

- UE nhận ra được số khẩn cấp
- UE được cấu hình CSFB khi thực hiện gọi số khẩn cấp
- UE được đặt ở vị trí có cả E-UTRAN và UTRAN/GERAN
- UE thực hiện đăng kí vào EPC và CS core cùng lúc
Luồng bản tin:
/
Bước Mô tả
1 Người dùng thực hiện cuộc gọi khẩn cấp. UE nhận ra số khẩn cấp và thực hiện
CSFB
2 UE gửi bản tin Extended Service Request tới MME chỉ rằng nó cần giải phóng E-
UTRAN và bị chuyển hướng xuống WCDMA hoặc GSM
Giả sử rằng UE đang ở trạng thái ECM-IDLE
3 MME gửi Initial Context Setup Request tới eNodeB chỉ ra yêu cầu CSFB
4 eNodeB gửi lại Initial Context Setup Response tới MME.
5 eNodeB trigger Radio Resource Control (RRC) connection release tới UE để điều
hướng UE tới GSM hoặc WCDMA.
6 eNodeB gửi UE Context Release Request với cause code là CS fall back tới MME.
7 MME gửi Release Access Bearers Request tới Service Gateway (SGW).
8 MME gửi UE Context Release Command tới eNodeB
9 SGW gửi Release Access Bearers Response tới MME.
10 eNodeB gửi UE Context Release Complete tới MME.
11 Nếu UE hoặc GERAN không hỗ trợ Dual Transfer Mode (DTM), MME gửi
/
Suspend Notification tới SGW cho mỗi PDN connection trong khoảng thời gian
thực hiện CSFB xuống GSM.
12 SGW đánh dấu non-GBR bearers là trạng thái suspended, và chuyển tiếp Suspend
Notification tới PGW. Khi nhận được Suspend Acknowledge từ PGW, SGW
chuyển tiếp Suspend Acknowledge tới MME
13 CSFB hoàn thành và UE thực hiện cuộc gọi ở miền CS
14 UE gửi bản tin CC SETUP tới MSC
15 MSC gửi IAM để thiết lập cuộc gọi tới MSC đích
16 MSC nhận ACM từ MSC đích
17 MSC thông báo UE qua bản tin CC ALERT
18 MSC nhận ANM từ MSC đích
19 MSC gửi bản tin CC CONNECT tới UE
2.7.2 CSFB khi P-CSCF điều hướng VoLTE UE in LTE emergency call
Giả sử:
- UE có khả năng CSFB

- UE không nhận ra được số khẩn cấp
- UE được cấu hình CSFB khi thực hiện gọi số khẩn cấp
- UE được đặt ở vị trí có cả E-UTRAN và UTRAN/GERAN
- UE thực hiện đăng kí vào EPC và CS core cùng lúc
- SBG cấu hình:
 Redirect reason:"Emergency call over LTE is not supported"
 Redirect emergency call to CS: true
Luồng bản tin:
/
Bướ
Mô tả
c
1 UE khởi tạo VoLTE call cho số khẩn cấp (911)
2 SBG nhân ra số khẩn cấp, thực hiện điều hướng UE thực hiện gọi qua miền CS
3 SBG gửi 380 Alternative Service tới UE mang XML body chỉ ra:
 Type:emergency
 Reason: Emergency call over LTE is not supported
4 UE thực hiện CSFB và khởi tạo CS call. (tham khảo2.7.1)
2.8 Charging
Có nhiều khối trong mạng IMS có khả năng thực hiện việc tính cước offline và online, và các
thời điểm kích hoạt tính cước là linh hoạt (vd: ACR có thể được gửi sau 200 OK-INVITE hoặc
sau ACK của 200 OK-INVITE), nên theo nghiệp vụ thực tế đang triển khai, phần dưới đây chỉ
mô tả việc tính cước ở khối AS.
Có nhiều thành phần mạng có khả năng yêu cầu AS thực hiện tính cước, vd: UE, PCSCF
(SUBSCRIBE), thành phần mạng khác..., phần dưới mô tả việc AS tính cước cho UE.
Nghiệp vụ tính cước ở AS chỉ được diễn ra khi AS có thông tin địa chỉ của khối CDF (cho tính
cước offline) hoặc khối OCS (cho tính cước online). Thông tin này có trong bản tin SAA trong
quá trình đăng kí, trong AVP: Charging-Information(618).
2.8.1 Offline
2.8.1.1 Session Based
2.8.1.1.1 Session thiết lập thành công

/
Tính cước offline theo cơ chế session based được thực hiện sau khi cuộc gọi đã thiết lập thành
công. Theo TS 32.260, có 2 thời điểm để xác định cuộc gọi thiết lập thành công: 200 OK của
INVITE và ACK của 200 OK – INVITE, mô tả dưới đây coi ACK của 200 OK - INVITE làm
mốc để kích hoạt tính cước offline
- ACR: Accounting-Request - ACA: Accounting-Answer

- CDR: Charging Data Record
Bướ
Mô tả
c
1 UE yêu cầu sử dụng dịch vụ bằng việc gửi bản tin INVITE để thiết lập call session
2 AS xác nhận call session được thiết lập xong khi nó nhận được 200 OK của
/
INVITE, hoặc ACK của 200 OK – INVITE.
Thực tế đang triển khai là dùng mốc ACK của 200 OK – INVITE.
3 Bản tin ACR với Accounting-Record-Type AVP có giá trị START_RECORD được
gửi từ AS đến CDF. Bản tin này cần chứa các thông tin căn bản để thực hiện tính
cước:
- MO address: AVP Calling-Party-Address (831)
- MT address: AVP Called-Party-Address(832)
- Start Time: AVP SIP-Response-Timestamp (835)
- Stop Time: AVP SIP-Request-Timestamp ở ACR (2301)
- ICID: AVP IMS-Charging-Identifier (841)
- SDP information: SDP-Session-Description (842)
Các AVP trên đều nằm trong AVP IMS-Information (876) / nằm trong AVP
Service-Information(873)
4 CDF kiểm tra các thông tin trong bản tin ACR và sinh một CDR cho cuộc gọi mới.
5 Sau khi thực hiện xong yêu cầu tính cước của AS, CDF phản hồi lại bằng bản tin
ACA (START_RECORD).
Bản tin ACA này chứa AVP Acct-Interim-Interval (85) mô tả thời gian tính bằng
giây mà AS phải gửi bản tin ACR (INTERIM_RECORD) tiếp theo nếu session kéo
dài.
Nếu ACA (START_RECORD) không chứa AVP Acct-Interim-Interval hoặc giá trị
của AVP này là 0, nghĩa là AS không cần gửi bản tin ACR(INTERIM_RECORD)
6 Sau khoảng thời gian được mô tả ở AVP AII mà session vẫn tồn tại, hoặc nếu
session có thay đổi các giá trị SDP (trong bản tin re-INVITE), AS cần gửi bản tin
ACR(INTERIM_RECORD) tới CDF.
Nếu là interim timer đã hết, ACR (INTERIM_RECORD) về cơ bản giống với
ACR(START_RECORD)
Nếu là session thay đổi, ACR(INTERIM_RECORD) cần chứa thông tin các thay
đổi của session
7 CDF thực hiện cập nhật các thay đổi của session – nếu có, theo mô tả trong bản tin
ACR(INTERIM_RECORD).
ACA (INTERIM_RECORD), bản tin này cũng chứa AVP Acct-Interim-Interval
(85) như bản tin ACA(START_RECORD)
9,12 Quá trình gửi và nhận ACR/ACA với Accounting-Record-Type AVP có giá trị
INTERIM_RECORD được tiếp tục diễn ra nếu session kéo dài cho đến khi AS nhận
/
được BYE cho session.
Khi nhận được BYE, MTAS gửi ACR (STOP_RECORD) tới CDR, ACR này chứa
thời gian nhận được BYE của session.
10,1 Khi nhận được ACR(STOP_RECORD), CDF thực hiện cập nhật CDR, đóng CDR
1 của session và phản hồi lại MTAS bằng bản tin ACA(STOP_RECORD)
2.8.1.1.2 Session thiết lập không thành công
2.8.1.1.2.1 UE hủy session

UE có nhiều cách hủy session, vd: MT không nhấc máy, MT reject call bằng 486 Busy Here,
MO gửi CANCEL... Mô tả dưới đây lấy bản tin 486(Busy here) làm đại diện cho hành động UE
hủy session.
Bướ
Mô tả
c
2 AS thực hiện dịch vụ call cho UE, gửi bản tin INVITE sang Outgoing Dialoge
3 MT từ chối thiết lập session bằng bản tin 486-Busy here
4 AS phản hồi lại phía MT bản tin ACK và chuẩn bị gửi bản tin ACR thông báo
session thiết lập không thành công tới CDF
5 Bản tin ACR với Accounting-Record-Type AVP có giá trị EVENT_RECORD được
gửi từ AS đến CDF
6 AS chuyển tiếp bản tin 486-Busy Here đến MO và chờ đợi ACK và ACA
7,8 MO phản hồi lại ACK chấp nhận ngừng thiết lập session và CDF gửi ACA thông
/
báo đã nhận được ACR(EVENT) cho việc session thiết lập không thành công
2.8.1.1.2.2 AS hủy session
Bướ
Mô tả
c
2 AS không thể thiết lập session cho UE, gửi bản tin ACR thông báo session thiết lập
không thành công tới CDF
3 AS không thể thiết lập session cho UE, gửi bản tin 606 Not Acceptable tới MO để
hủy session
4, 5 MO phản hồi lại ACK chấp nhận ngừng thiết lập session và CDF gửi ACA thông
báo đã nhận được ACR(EVENT) cho việc session thiết lập không thành công
/
2.8.1.2 Event Based
- ACR: Accounting-Request
- ACA: Accounting-Answer
Bướ
Mô tả
c
1 UE yêu cầu sử dụng dịch vụ của nhà mạng bằng việc gửi bản tin request:
REGISTER, MESSAGE, INVITE, NOTIFY, SUBSCRIBE, REFER, PUBLISH,
UPDATE, INVITE (cho các dịch vụ trên AS, mô tả rõ hơn ở phần 9.1.3 bên dưới)
2 Sau khi thực hiện xong mỗi request nhận được, AS gửi bản tin kích hoạt việc
charging offline ACR với Accounting-Record-Type AVP có giá trị
EVENT_RECORD.
4 CDF nhận được bản tin ACR, kiểm tra các thông tin trong bản tin ACR và thực hiện
yêu cầu tính cước của AS, tạo CDR tương ứng.
ACA (EVENT_RECORD)
/
2.8.1.3 Tính cước Offline cho các dịch vụ trên AS
Ngoại trừ với dịch vụ CB (Communication Barring) thì AS kích hoạt ACR (Event) khi nhận
được INVITE, còn với các dịch vụ khác có tên trong chỉ tiêu kĩ thuật, thì AS kích hoạt ACR
(Event) sau khi nhận được 200 OK của INVITE.
Phần dưới mô tả nghiệp vụ chung cho các dịch vụ trên AS (ngoại trừ dịch vụ CB)
Bướ
Mô tả
c
1 UE khởi tạo session bằng việc gửi bản tin request: INVITE
2 Sau khi nhận được 200 OK cho INVITE, AS kiểm tra dịch vụ supplementary
service tương ứng đã được sử dụng trong session và kích hoạt bản tin ACR
(EVENT_RECORD) tương ứng với dịch vụ đó
4 CDF nhận được bản tin ACR, kiểm tra các thông tin trong bản tin ACR và thực hiện
yêu cầu tính cước của AS, tạo CDR tương ứng.
ACA (EVENT_RECORD)
2.8.1.4 Các AVP chính trong bản tin ACR/ACA

Phân loại: M – bắt buộc, OM: bắt buộc nếu nhà mạng yêu cầu, OC: Tùy chọn
/
2.8.1.4.1 ACR
Command code: 271
Phân
AVP Mô Tả
loại
Để xác định session tính cước offline theo từng AS (có thể có giá trị là
Session-Id M
incoming call-ID tới AS hoặc nhà mạng tùy chọn)
Origin-Host M Địa chỉa của AS tạo ra bản tin ACR
Origin-Realm M Tên miền của AS tạo ra bản tin ACR
Destination-Realm M Tên miền của CDF
Có giá trị “event” cho kiểu event based và “start”, “interim”, “stop” cho kiểu
Accounting-Record-Type M
session based
Accounting-Record-Number M Thứ tự bản tin ACR, theo từng session-id, tăng 1 đơn vị theo từng bản tin
Acct-Application-Id OM Có giá trị là 3 cho tính cước offline.
User-Name OC IMPI của MO, AS có IMPI này ở 3rd party registration.
Destination-Host OC Địa chỉ của CDF.
Acct-Interim-Interval OC Thời gian interim mong muốn của AS.
Event-Timestamp OC Thời điểm bản tin ACR được khởi tạo
Service-Information OM Là một group AVP. Mô tả cụ thể về dịch vụ IMS mà AS hỗ trợ.
2.8.1.4.2 ACA
Command code: 271
AVP Phân loại Mô Tả

Session-Id M Xác định session tính cước offline cho từng AS (có thể có giá trị là
incoming call-ID hoặc nhà mạng tùy chọn).
Result-Code M - 1xxx (Informational)
- 2xxx (Success)
- 3xxx (Protocol Errors)
- 4xxx (Transient Failures)
- 5xxx (Permanent Failure).
Origin-Host M Địa chỉ của CDF
Origin-Realm M Tên miền của CDF
Accounting-Record-Type M Có giá trị “event” cho kiểu event based và “start”, “interim”, “stop”
cho kiểu session based
Accounting-Record-Number M Thứ tự bản tin ACA cho ACR tương ứng
Acct-Application-Id OM Có giá trị là 3 cho tính cước offline.
Acct-Interim-Interval OC Thời gian interim cho phép.
2.8.2 Online
2.8.2.1 Session Based
2.8.2.1.1 Session thiết lập thành công
/
- CCR: Credit Control Request - CCA: Credit Control Answer
- USU: Used-Service-Unit - GSU: Granted-Service-Unit
Bước Mô tả
2 AS thực hiện gửi bản tin CCR yêu cầu OCS thực hiện tính cước cho UE. Bản tin
CCR này chứa AVP CC-Request-Type có giá trị INITIAL, thể hiện yêu cầu tính
cước cho bản tin INVITE khởi tạo cuộc gọi. Bản tin này cần chứa các thông tin
căn bản để thực hiện tính cước:
- MO address: AVP Calling-Party-Address (831)
/
- MT address: AVP Called-Party-Address(832)
- Start Time: AVP SIP-Response-Timestamp (835)
- Stop Time: AVP SIP-Request-Timestamp ở ACR (2301)
- ICID: AVP IMS-Charging-Identifier (841)
- SDP information: SDP-Session-Description (842)
Các AVP trên đều nằm trong AVP IMS-Information (876) / nằm trong AVP
Service-Information(873)
3 OCS kiểm tra các thông tin trong bản tin CCR, tính cước và phản hồi lại bằng bản
tin CCA với Result-Code AVP có giá trị là 2xxx (Success). Đồng thời CCA này
có thêm AVP Granted-Service-Unit là thời gian AS cho phép UE sử dụng dịch vụ
IMS.
4 AS kiểm tra giá trị của AVP GSU trong bản tin CCA và thực hiện tiếp các nghiệp
vụ cần thiết để thiết lập cuộc gọi
5 Sau khi nhận được 200 OK – INVITE báo hiệu cuộc gọi được thiết lập thành
công, AS chuẩn bị để gửi bản tin CCR update trạng thái cuộc gọi đến OCS
6 Bản tin CCR được đính kèm AVP CC-Request-Type có giá trị là UPDATE, AVP
Reporting-Reason có giá trị là 6 (RATING_CONDITION_CHANGE), và AVP
Used-Service-Unit có giá trị là 0.
IMS.
8 AS gửi 200 OK – INVITE về UE và bắt đầu bộ đếm thời gian với giá trị là thời
gian GSU ở bản tin CCA (UPDATE)
10 Sau khoảng thời gian được mô tả ở AVP GSU mà session vẫn tồn tại thì AS cần
gửi một bản tin CCR khác để yêu cầu OCS cho phép cuộc gọi được tiếp tục. bản
tin CCR này đính kèm AVP CC-Request-Type có giá trị là UPDATE, AVP
Reporting-Reason có giá trị là 3 (QUOTA_EXHAUSTED), và AVP Used-
Service-Unit có giá trị là x
IMS.
12 Khi nhận được bản tin BYE yêu cầu kết thúc session, AS chuẩn bị để tạo bản tin
CCR cập nhật thời gian gọi và yêu cầu OCS tính cước.
/
13 Bản tin CCR tương ứng với bản tin BYE được AS gửi đính kèm AVP CC-
Request-Type có giá trị là TTERMINATION, AVP Reporting-Reason có giá trị là
2 (FINAL), và AVP Used-Service-Unit có giá trị là thời gian tính từ lúc nhận được
bản tin CCA gần nhất tới thời điểm hiện tại.
14, 15 AS tiếp tục nghiệp vụ kết thúc cuộc gọi và chờ bản tin CCA từ OCS
tin CCA với Result-Code AVP có giá trị là 2xxx (Success).
2.8.2.1.2 Session thiết lập không thành công
2.8.2.1.2.1 UE hủy session

UE có nhiều cách hủy session, vd: MT không nhấc máy, MT reject call bằng 486 Busy Here,
MO gửi CANCEL... Mô tả dưới đây lấy bản tin 486(Busy here) làm đại diện cho hành động UE
hủy session.
Bướ
Mô tả
c
CCR này chứa AVP CC-Request-Type có giá trị INITIAL.
tin CCA với Result-Code AVP có giá trị là 2xxx (Success). Đồng thời CCA này có
thêm AVP Granted-Service-Unit là thời gian AS cho phép UE sử dụng dịch vụ
IMS.
/
4 AS kiểm tra giá trị của AVP GSU trong bản tin CCA và thực hiện tiếp các nghiệp
vụ cần thiết để thiết lập cuộc gọi
5 MT từ chối thiết lập session bằng bản tin 486-Busy here
6 AS thông báo session không khởi tạo thành công bằng việc gửi bản tin CCR với
AVP CC-Request-Type có giá trị là TERMINATION, AVP Reporting-Reason có
giá trị là 2 (FINAL), và AVP Used-Service-Unit có giá trị là 0 tới OCS.
7,8 MO phản hồi lại ACK chấp nhận ngừng thiết lập session và OCS gửi CCA thông
báo đã nhận được CCR(TERMINATION)
2.8.2.1.2.2 AS hủy session
Bướ
Mô tả
c
CCR này chứa AVP CC-Request-Type có giá trị INITIAL.
tin CCA với Result-Code AVP có giá trị là 2xxx (Success). Đồng thời CCA này có
thêm AVP Granted-Service-Unit là thời gian AS cho phép UE sử dụng dịch vụ IMS.
4 AS không thể thiết lập session cho UE, gửi bản tin 606 Not Acceptable tới MO để
hủy session
5 AS thông báo session không khởi tạo thành công bằng việc gửi bản tin CCR với
AVP CC-Request-Type có giá trị là TERMINATION, AVP Reporting-Reason có
/
giá trị là 2 (FINAL), và AVP Used-Service-Unit có giá trị là 0 tới OCS.
6, 7 MO phản hồi lại ACK chấp nhận ngừng thiết lập session và OCS gửi CCA thông
báo đã nhận được CCR(TERMINATION)
2.8.2.2 Event Based
- CCR: Credit Control Request - CCA: Credit Control Answer

- USU: Used-Service-Unit - RSU: Requested-Service-Unit
- GSU: Granted-Service-Unit
Bướ
Mô tả
c
1 UE yêu cầu sử dụng dịch vụ tới AS
2 AS trước khi thực hiện dịch vụ cho UE, cần gửi bản tin CCR với AVP CC-Request-
Type có giá trị là EVENT
4 AS sau khi nhận được CCA với Result-Code có giá trị là 2xxx thì tiếp tục thực hiện
dịch vụ mà UE yêu cầu.
2.8.2.3 Tính cước Online cho các dịch vụ trên AS

AS chỉ hỗ trợ được nghiệp vụ tính cước online cho 5 dịch vụ: CONF, CDIV, ETC, FA, CUG.
/
Bướ
Mô tả
c
1 UE yêu cầu sử dụng dịch vụ tới AS
2 AS trước khi thực hiện dịch vụ cho UE, cần gửi bản tin CCR với AVP CC-Request-
Type có giá trị là EVENT, (spec không mô tả rõ AVP nào để mô tả các
supplementary service)
4 AS sau khi nhận được CCA với Result-Code có giá trị là 2xxx thì tiếp tục thực hiện
dịch vụ mà UE yêu cầu.
2.8.2.4 OCS yêu cầu AS ngừng cung cấp dịch vụ
/
Bướ
Mô tả
c
1 AS đang phục vụ UE khi nhận được bản tin Abort-Session-Request yêu cầu ngừng
cung cấp dịch vụ từ OCS sẽ dừng việc phục vụ UE và chuẩn bị để phản hồi lại ÓC
bằng bản tin Abort-Session-Answer
2 AS gửi bản tin Abort-Session-Answer thể hiện sẽ dừng cung cấp dịch vụ cho UE và
chuẩn bị để gửi BYE đến MO, MT
3, 4 AS gửi bản tin BYE đến MO, MT thông báo dừng cung cấp dịch vụ
5 AS gửi bản tin CCR đến OCS thông báo việc ngừng session
/
6 OCS thông báo đã xác nhận ngừng session của UE
7,8 MO, MT thông báo chấp nhận dừng session
2.8.2.5 Các AVP chính trong bản tin CCR/CCA

Phân loại: M – bắt buộc, OM: bắt buộc nếu nhà mạng yêu cầu, OC: Tùy chọn
2.8.2.5.1 CCR
Command code: 272
AVP Yêu cầu Mô tả

Session-Id M Để xác định session tính cước offline theo từng AS (có thể có giá trị là incoming
call-ID tới AS hoặc nhà mạng tùy chọn)
Origin-Host M Địa chỉa của AS tạo ra bản tin CCR.
Origin-Realm M Tên miền của AS tạo ra bản tin CCR.
Destination-Realm M Tên miền của OCS.
Auth-Application-Id M Có giá trị là 4 thể hiện đây là bản tin của nghiệp vụ charging online.
Service-Context-Id M Mô tả thông tin của bản tin CCR theo technical release nào.
Có định dạng:
"extensions".MNC.MCC."Release"."service-context" "@" "domain"
- “extensions” là giá trị tùy chọn của nhà mạng
- “Release ” là thông tin bản technical release mà AS dùng để tạo bản tin
ACR
- "service-context" "@" "domain" là giá trị tối thiểu phải có. Có nhiều giá
trị cho các dịch vụ khác nhau. vd :
32274@3gpp.org for SMS service charging
32275@3gpp.org for MMTel service charging

CC-Request-Type M AVP này để phân loại các bản tin CCR, có giá trị và ý nghĩa tương ứng:
Initial: 1
Update: 2
Termination: 3
Event: 4
CC-Request- M Thứ tự bản tin CCR, theo từng session-id, tăng 1 đơn vị theo từng bản tin
Number
Destination-Host OC Địa chỉ của OCS.
User-Name OC IMPI của MO, AS có IMPI này ở 3rd party registration
Event-Timestamp OC Thời điểm bản tin CCR được khởi tạo
Termination-Cause OC Mô tả lý do kết thúc session trong bản tin CCR(Termination).
Requested-Action OC Mô tả hành động tính cước theo kiểu event based. vd: DIRECT_DEBITING,
REFUND-ACCOUNT
Service-Information OM Là một group AVP. Mô tả cụ thể về dịch vụ IMS mà AS hỗ trợ
2.8.2.5.2 CCA
/
Information Element Category Description
Session-Id M Có giá trị giống với giá trị trong bản tin CCR tương ứng.
Result-Code M - 1xxx (Informational)
- 2xxx (Success)
- 3xxx (Protocol Errors)
- 4xxx (Transient Failures)
5xxx (Permanent Failure).
Origin-Host M Địa chỉa của OCS
Origin-Realm M Tên miền của OCS
Auth-Application-Id M Có giá trị là 4 thể hiện đây là bản tin của nghiệp vụ charging
online
CC-Request-Type M Initial: 1
Update: 2
Termination: 3
Event: 4
CC-Request-Number M Thứ tự bản tin CCA, giống với bản tin CCR tương ứng
Multiple-Services-Credit-Control OC Mô tả thời gian OCS cho phép UE dùng dịch vụ trên AS.
Service-Information OC This parameter holds the individual service specific parameters as
defined in the corresponding 'middle tier' TS.
2.9 Một số dịch vụ đặc biệt

2.9.1 CRBT
Giả sử:
- UE-B đăng kí dịch vụ CRBT
- A và B đang registered ở mạng IMS
- A thực hiện khởi tạo cuộc gọi cho B
- Call flow mô tả bắt đầu từ khi UE-B rung chuông.
Luồng bản tin:
/
Bước Mô tả
1-3 UE-B gửi 180 Ringing tới MMTEL B
/
4 MMTEL trigger INVITE tới hệ thống CRBT qua MGCF
5 MGCF yêu cầu IM-MGW thực hiện chuẩn bị tài nguyên cho phiên qua H.248
ADD(mang SDP của BGF A). IM-MGW trả lời lại H.248 ADD reply
6 MGCF gửi INVITE tới CRBT yêu cầu phát nhạc chờ mang SDP của IM-MGW
7 Hệ thống CRBT phản hồi 200 OK mang SDP của hệ thống CRBT tới MGCF
8 MGCF cập nhật thông tin SDP của hệ thống CRBT xuống IM-MGW qua
Modify/Modify reply
9 MGCF trả lời 200 OK tới MMTEL B mang SDP của IM-MGW
10-15 MMTEL tạo 183 Session Progress mang SDP của IM-MGW tới P-CSCF của A
16 P-CSCF cập nhật thông tin SDP của hệ thống IM-MGW xuống BGF qua
Modify/Modify reply
17 P-CSCF gửi bản tin 183 tới UE-B
18 UE B gửi UPDATE mang SDP của nó tới P-CSCF
19 P-CSCF cập nhật thông tin SDP của UE-B xuống BGF qua Modify/Modify reply
20-25 P-CSCF của A chuyển tiếp UPDATE mang SDP của BGF tới MMTEL B
26-35 MMTEL B phản hồi 200 OK cho UPDATE mang SDP answers của IM-MGW
27-28 MMTEL gửi ACK tới CRBT thông báo bắt đầu phát nhạc
34 P-CSCF cập nhật thông tin SDP của IM-MGW xuống BGF qua Modify/Modify
reply
Bây giờ luồng RTP như sau:
UE-A<------PS media ----BGF(A) <------ PS media ---- IM-MGW <----CS media
---- vCRBT
36 UE-B nhấc máy, UE-B gửi 200 ok cho INVITE tới P-CSCF của B
37 P-CSCF của B cập nhật thông tin SDP của B tới BGF(B) qua Modify/Modify reply
38-39 P-CSCF của B gửi 200 OK tới MMTEL của B
40-41 MMTEL B gửi BYE tới CRBT kết thúc phiên phát nhạc
42-44 CRBT phản hồi 200 ok cho BYE
43 MGCF gửi Subtract/Subtract reply giải phóng tài nguyên ở IM-MGW
45-52 MMTEL B gửi 200 ok cho INVITE tới UE-A
/
2.9.2 MCA/Voice mail
Dịch vụ Miss Call Alerting (MCA) và Voice mail được tích hợp với hệ thống IMS dựa trên dịch
vụ CFNRc.
Trong trường hợp thuê bao tắt máy hoặc không liên lạc được, MMTEL AS sẽ thực hiện chuyển
tiếp cuộc gọi về tổng đài +84980000173
Đối với thuê bao đăng kí dịch vụ MCA hay voice mail, thuê bao sẽ được cấu hình dịch vụ
CFNRc với số điện thoại chuyển tiếp là +84980000173.
Chú ý: Thuê bao sẽ không thể đăng kí cùng lúc MCA và Voice mail
2.9.2.1 MCA
Luồng bản tin:
Kí hiệu:
/
Bước Mô tả
1-15 UE A khởi tạo cuộc gọi cho UE-B tương tự như cuộc gọi basic từ VoLTE tới
VoLTE
16-17 P-CSCF B thực hiện gửi request tới UE B nhưng xảy ra timeout. P-CSCF phản hồi
lại bản tin 408 Request timeout
18-24 MMTEL B gửi bản tin 181 tới UE-A thông báo xảy ra việc chuyển tiếp cuộc gọi
25 MMTEL B tạo bản tin INVITE với request URI là số tổng đài MCA tel:
+84980000173
26 S-CSCF thực hiện ENUM query để lấy địa chỉ SIP
27 ENUM response not found
28 S-CSCF thực hiện gửi xuống miền CS, S-CSCF gửi INVITE tới MGCF
29 MGCF gửi INVITE tới GMSC

/
30 GMSC gửi INVITE tới MCA server
31-42 MCA phản hồi lại 480 Temporary Unavailable
2.9.2.2 Voice mail

Luồng bản tin:
Kí hiệu:
/
Bước Mô tả
1-15 UE A khởi tạo cuộc gọi cho UE-B tương tự như cuộc gọi basic từ VoLTE tới
/
VoLTE
16-17 P-CSCF B thực hiện gửi request tới UE B nhưng xảy ra timeout. P-CSCF phản hồi
lại bản tin 408 Request timeout
18-24 MMTEL B gửi bản tin 181 tới UE-A thông báo xảy ra việc chuyển tiếp cuộc gọi
25 MMTEL B tạo bản tin INVITE với request URI là số tổng đài MCA tel:
+84980000173
26 S-CSCF thực hiện ENUM query để lấy địa chỉ SIP
27 ENUM response not found
28 S-CSCF thực hiện gửi xuống miền CS, S-CSCF gửi INVITE tới MGCF
29 MGCF gửi INVITE tới GMSC
30 GMSC gửi INVITE tới MCA server
31-43 MCA phản hồi lại 200 OK cho INVITE
41 P-CSCF gửi AAR tới PCRF thiết lập bearer.

PCRF thiết lập bearer xong và trả lời lại AAA.
42 P-CSCF gửi Modify tới BGF để cập nhật thông tin media của phiên.
BGF gửi lại Modify reply.
44-54 Sau khi ghi âm xong, UE A kết thúc cuộc gọi, UE A gửi BYE tới MCA
55-67 MCA phản hồi lại 200 OK cho BYE
65 P-CSCF gửi STR tới PCRF để giải phóng bearer.

PCRF giải phóng bearer và trả lời lại STA.
66 P-CSCF gửi Subtract tới BGF để giải phóng tài nguyên cấp cho A
BGF gửi lại Subtract reply.
2.9.3 Call blocking

(Chưa có giải pháp cụ thể)
/
2.9.4 Announcement
2.9.4.1 Announcement khi thuê bao chủ động hủy cuộc gọi khi nghe một phần thông báo
Bước Mô tả
1 UE A gửi bản tin INVITE (call id 1) đến S-CSCF.
2 S-CSCF chuyển tiếp bản tin INVITE đến MTAS.
3 MTAS gửi bản tin INVITE (call id 2) đến phía S-CSCF.
4 S-CSCF chuyển tiếp bản tin INVITE đến phía MT.
5 Phía MT gửi trả lại bản tin chứa mã lỗi (404, 604 …) về S-CSCF.
6 S-CSCF chuyển tiếp bản tin chứa mã lỗi lên MTAS. MTAS kiểm tra xem chức
năng phát thông báo có được cho phép không, nếu có chức năng phát thông báo
thì thực hiện tiếp bước 7, nếu không thì MTAS trả bản tin chứa mã lỗi về S-CSCF
để S-CSCF chuyển tiếp về UE A.
7 MTAS gửi bản tin INVITE (call id 3) có chứa SDP của UE A lên MRFC.
8 MRFC trả về 200 OK có chứa SDP của MRFP.
9 MTAS gửi bản tin SIP 183 (call id 1) có chứa SDP của MRFP đến S-CSCF.
/
10 S-CSCF chuyển tiếp bản tin SIP 183 về UE A.
11 MTAS gửi bản tin ACK (call id 3) về MRFC.
12 Luồng RTP được thiết lập sau khi MRFC nhận ACK.
13 UE A quyết định hủy cuộc gọi sau khi nghe thông báo, UE A gửi bản tin
CANCEL lên S-CSCF.
14 S-CSCF trả lại 200 Canceling.
15 S-CSCF chuyển tiếp bản tin CANCEL lên MTAS.
16 MTAS trả lại 200 Canceling.
17 MTAS gửi bản tin BYE đến MRFC để thông báo việc hủy luồng RTP và giải
phóng tài nguyên.
18 MRFC gửi bản tin 200 OK cho BYE.
19 MTAS gửi SIP 487 cho S-CSCF.
20 S-CSCF phản hồi ACK cho MTAS.
21 S-CSCF gửi 487 cho UE-A.
22 UE-A phản hồi ACK cho S-CSCF.
2.9.4.2 Annoucement khi MTAS chủ động kết thúc cuộc gọi khi MRFC phát hết thông báo
Bước Mô tả
/
5 Phía MT gửi trả lại bản tin chứa mã lỗi (404, 604 …) về S-CSCF.
6 S-CSCF chuyển tiếp bản tin chứa mã lỗi lên MTAS. MTAS kiểm tra xem chức
năng phát thông báo có được cho phép không, nếu có chức năng phát thông báo
thì thực hiện tiếp bước 7, nếu không thì MTAS trả bản tin chứa mã lỗi về S-CSCF
để S-CSCF chuyển tiếp về UE A.
13 MRFC nhận thấy đã phát xong thông báo mà phía UE chưa hủy cuộc gọi nên
MRFC gửi BYE cho MTAS để kết thúc việc phát thông báo.
14 MTAS trả lại 200 OK.
15 MTAS gửi trả bản tin chứa mã lỗi cho S-CSCF để kết thúc cuộc gọi.
16 S-CSCF chuyển tiếp bản tin chứa mã lỗi về cho UE A.
/
2.9.4.3 Ringback Tone
Bước Mô tả
5 Phía MT gửi trả lại bản tin SIP 180 về S-CSCF.
6 S-CSCF chuyển tiếp bản tin SIP 180 lên MTAS. MTAS kiểm tra xem chức năng
phát thông báo có được cho phép không, nếu có chức năng phát thông báo thì
thực hiện tiếp bước 7 đến hết, nếu không thì chỉ thực hiện bước 7 đến 8.
7 MTAS gửi bản tin SIP 180 đến S-CSCF.
8 S-CSCF chuyển tiếp bản tin SIP 180 đến UE A.
/
15 S-CSCF nhận được bản tin 200 OK từ UE B.
16 S-CSCF gửi bản tin 200 OK lên MTAS.
17 MTAS gửi trả bản tin BYE đến MRFC để kết thúc việc phát nhạc chuông.
18 MRFC gửi lại 200 OK cho BYE.
19 MTAS gửi bản tin 200 OK (call id 1) chứa UE B SDP về S-CSCF.
20 S-CSCF chuyển tiếp bản tin 200 OK về UE A.
2.9.5 Transcode
2.9.5.1 Transcode khi MT UE đưa ra gợi ý về codec
Bước Mô tả
/
4 S-CSCF chuyển tiếp bản tin INVITE đến phía UE B.
5 Phía UE B gửi trả lại bản tin chứa mã lỗi SIP 488 bên trong có SDP của UE B ghi
lại các codec mà UE B hỗ trợ về S-CSCF.
transcode có được cho phép không, nếu có chức năng transcode thì thực hiện tiếp
bước 7 đến hết, nếu không thì MTAS trả bản tin chứa mã lỗi về S-CSCF để S-
CSCF chuyển tiếp về UE A.
7 MTAS gửi bản tin INVITE (call id 3) có chứa SDP của UE B lên MRFC.
9 MTAS gửi bản tin ACK lên MRFP.
10 MTAS gửi bản tin INVITE (call id 4) có chứa SDP của MRFP đến S-CSCF để
thiết lập phiên giữ MRFP và UE B.
11 S-CSCF gửi bản tin INVITE (call id 4) đến UE B.
12 MTAS gửi bản tin INVITE (call id 5) có chứa SDP của UE A đến MRFC.
13 MRFC gửi trả lại 200 OK cho MTAS.
14 S-CSCF trả lại ACK cho MRFC.
15 UE B gửi 180 Ringing về cho S-CSCF.
16 S-CSCF gửi 180 Ringing đến MTAS.
17 MTAS gửi lại 180 Ringing cho S-CSCF.
18 S-CSCF gửi 180 Ringing cho UE A.
19 UE B gửi lại 200 OK cho S-CSCF có chứa UE B SDP.
20 S-CSCF gửi 200 OK lên MTAS.
21 MTAS gửi bản tin 200 OK có chứa SDP mà MRFP chọn cho UE A đến S-CSCF.
22 S-CSCF chuyển tiếp 200 OK cho UE A.
/
2.9.5.2 Transcode khi MT UE không đưa ra gợi ý về codec
Bước Mô tả
4 S-CSCF chuyển tiếp bản tin INVITE đến phía UE B.
5 Phía UE B gửi trả lại bản tin chứa mã lỗi SIP 488 bên trong không có SDP của
UE B về S-CSCF.
transcode có được cho phép không, nếu có chức năng transcode thì thực hiện tiếp
bước 7 đến hết, nếu không thì MTAS trả bản tin chứa mã lỗi về S-CSCF để S-
CSCF chuyển tiếp về UE A.
7 MTAS gửi bản tin INVITE (call id 3) lên MRFC.

/
9 MTAS gửi bản tin INVITE (call id 4) có chứa SDP của MRFP đến S-CSCF để
thiết lập phiên giữ MRFP và UE B.
10 S-CSCF gửi bản tin INVITE (call id 4) đến UE B.
11 MTAS gửi bản tin INVITE (call id 5) có chứa SDP của UE A đến MRFC.
12 MRFC gửi trả lại 200 OK cho MTAS.
13 S-CSCF trả lại ACK cho MRFC.
14 UE B gửi 180 Ringing về cho S-CSCF.
15 S-CSCF gửi 180 Ringing đến MTAS.
16 MTAS gửi lại 180 Ringing cho S-CSCF.
17 S-CSCF gửi 180 Ringing cho UE A.
18 UE B gửi lại 200 OK cho S-CSCF có chứa UE B SDP.
19 S-CSCF gửi 200 OK lên MTAS.
20 MTAS gửi bản tin ACK (call id 3) có chứa SDP của UE B đến cho MRFC.
21 MTAS gửi bản tin 200 OK có chứa SDP mà MRFP chọn cho UE A đến S-CSCF.
22 S-CSCF chuyển tiếp 200 OK cho UE A.
2.9.6 MultiSIM:
2.9.6.1 Originating Call từ Primary Device: Flow cuộc gọi tương tự MO VoLTE và MO ICS
/
2.9.6.2 VoLTE Originating Call từ Companion Device:
Bước Mô tả
1 CD gửi INVITE đến số B đến P-CSCF.
2 P-CSCF gửi bản tin INVITE đến CSCF với PAI và From là MSISDN PD.
3 Bản tin INVITE sẽ được gửi đến mạng IMS core nguồn và sẽ được gửi SCCAS.
4 SCCAS gửi INVITE đến S-CSCF
5 S-CSCF gửi INVITE đến MMTEL

MMTEL check thuê bao có dịch vụ FIP dành cho multisim. MMTEL update thông
7
tin PAI và FROM bằng số PD (số chính), sau đó gửi INVITE ra S-CSCF
Cuộc gọi tiếp tục thiết lập như cuộc gọi MO VoLTE thông thường với calling là
8-15
PD
/
2.9.6.3 Originating Call từ Companion Device trên CS:
Bước Mô tả
1 CD gửi setup lên MSC MO
2 MSC check GSAaddress thuê bao CD là GT SCCAS. MSC gửi IDP lên SCCAS
3 MTAS check skey=1, trả CAP Connect với called party number trong dải IMRN
4 MSC gửi bản tin IAM đến MGCF
5 MGCF gửi INVITE với called là IMRN đến I-CSCF
6 I-CSCF gửi LIR lên HSS để truy vấn server name của IMRN. HSS trả LIA với server name là SCCAS
cấp dải IMRN tại bước 3.
7 I-CSCF gửi INVITE đến SCCAS
8 SCCAS thay IMRN bằng called nhận được trong bản tin IDP gửi lên ở bước 2. Đồng thời add thêm
trường ORIG trong trường ROUTE trong bản tin INVITE gửi đến I-CSCF.
9 I-CSCF gửi LIR lên HSS để truy vấn server name của calling. HSS trả LIA với server name là S-
CSCF phục vụ thuê bao multisim
10 I-CSCF gửi INVITE đến S-CSCF, trường PAI, From là số CD
11 S-CSCF gửi INVITE đến SCCAS MO, trường PAI, From là số CD
12 SCCAS gửi INVITE đến S-CSCF, trường PAI, From là số CD
13 S-CSCF gửi INVITE đến MMTEL MO, trường PAI, From là số CD
MMTEL check thuê bao calling có dịch vụ FIP dành cho multisim. MMTEL update thông tin PAI và
14 FROM bằng số PD (số chính), sau đó gửi INVITE ra S-CSCF. Cuộc gọi sau đó như cuộc gọi MO
thông thường từ số PD
/
2.9.6.4 Originating Call từ Companion Device trên CS:
Serving network Home network
Remote PD-UE CD-UE

I/S- HP-
SCC- HSS P-CSCF B PB1
End CSCF TRIM MTAS
AS
1. SIP INVITE Req
URI=PD
PEM:supported
Supported:100rel,pre
condition 2. LIR/LIA
SDP-A
3. SIP INVITE Req
URI=PD
4. SIP INVITE Req URI=PD

PEM:supported
Supported:100rel,precondition
5.Execute Terminating MTAS service
MS Subscriber provisioned with FCD
service. MTAS simultaneously Forks
INVITE to PD(Refer step 6) and
CD(Refer step 16)
Acce pt-con tact: *;impi-pd
Accept-contact: *;+sip.instance=pd;explicit;req uire
Accept-contact: *;cscapab le=true
8. SCC-AS
7. SIP INVITE Req URI=PD performs T-ADS
Accept-contact: *;imp i-pd
Accept-conta ct: *;+sip.instance=pd;explicit;require
procedure
Accept-contact: *;cscapable=true 9. Sh-Pull(-
Response)
10. SIP INVITE Req URI=PD (IMPU:IMPI-1),
Accept-conta ct: *;+sip.instance=pd;explicit;require
TADS information
12. SIP INVITE Req
URI=PD
PEM:supported
Supported:100rel,pre
condition
SDP-A
13. 183 Session progress
14. 183 Session progress/PRACK/200 OK(PRACK) Require:100rel,precondition
PEM:inactive SDP-AB
Require:100rel,precondition
SDP-AB
15. SIP UPDATE/200 OK (UPDATE)
SDP(A’)/SDP-A’B’
16. 180 Ringing

Accept-contact: * ;impi-cd
Accept-contact: *;+sip.instance=cd;exp licit;req uire
Accept-contact: *;cscapable=false
Accept-contact: *;impi-cd
Accept-conta ct: *;+sip.instance=cd;explicit;require 20. SCC-AS
Acce pt-con tact: *;cscapab le=false
performs T-ADS
procedure
21. Sh-Pull(-
Response)
(IMPU:IMPI-2),
TADS information
11. SIP INVITE Req URI=PD 23. SIP INVITE Req URI=PD
PEM:supported
Supported:100rel,precondition
SDP-A
24. 183 Session progress
25. 183 Session progress/PRACK/200 OK(PRACK) Require:100rel,precondition
PEM:inactive SDP-AB1
Require:100rel,precondition
SDP-AB1
26. SIP UPDATE/200 OK (UPDATE)
SDP(A1’)/SDP-A1’B1’
27. 180 Ringing
28. 200 OK (INVITE) - Answer

29.CANCEL/200OK(CANCEL)
30. 200 OK (INVITE) -Answer/ACK
31.487 Request Terminated/ACK
32. ACK for 200 OK (IVNITE) - Answer
Conversation established Remote End and CD device
Bước Mô tả
1-4 Flow cuộc gọi như MT thông thường đến PD
MTAS check profile mmtel có dịch vụ FCD. MTAS thiết lập đồng thời các bản tin INVITE
5
đến PD và các CD với trường accept-contact:impi của PD hoặc CD
6-32 Sau đó cuộc gọi thiết lập đến các số PD và CD như luồng MT thông thường

Ims VHT Call Flow v1.2

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Ims VHT Call Flow v1.2

Uploaded by

Copyright:

Available Formats

Call flow hệ thống IMS

1.1 Thuật ngữ...............................................................................................................................4

Thuật ngữ Định nghĩa

BGF Border Gateway Function

BGCF Breakout Gateway Control Function

CAMEL Customised Application Mobile Enhanced Logic

CAP Camel Application Part

CDR Charging Data Record

CSCF Call Session Control Function

DNS Domain Name System

ENUM E.164 Number Mapping

HSS Home Subscriber Server

IBCF Interconnection Border Control Function

ICS IMS Centralized Service

I-CSCF Interrogating-Call Session Control Function

IMS IP Multimedia Core Network Subsystem

IM-SSF IP Multimedia Service Switching Function

IP-SM-GW IP Short Message Gateway

MAP Mobile Application Part

MGCF Media Gateway Control Function

MMTEL Multimedia Telephony

MRFC Multimedia Resource Function Controller

PCC Policy Charging Control

PCEF Policy and Charging Enforcement Function

P-CSCF Proxy-Call Session Control Function

PDN Packet Data Network

QoS Quality of Service

SBC Session Border Control

SCCAS Service Centrallization and Continuity Application Server

S-CSCF Serving-Call Session Control Function

SS7 Signalling System 7

SIP Session Initiation Protocol

SRVCC Single Radio Voice Call Continuity

1.2 Tài liệu tham khảo

1 UE gửi bản tin REGISTER tới P-CSCF.

 +g.3gpp.icsi-ref= urn:urn-7:3gpp-service.ims.icsi.mmtel; audio; video;

2 P-CSCF thêm địa chỉ của pcscf vào trường Path.

4 HSS phản hồi UAA chứa AVP

13 P-CSCF thêm địa chỉ của pcscf vào trường Path.

15 HSS trả về UAA chứa AVP:

 Server-name : S-CSCF URI

20- S-CSCF gửi 200 OK tới P-CSCF qua I-CSCF

22 P-CSCF gửi 200 OK tới UE

2-3 MMTEL thực hiện gửi UDR(Data-Reference=IMSPublicIdentities) lên HSS để lấy

4-5 MMTEL thực hiện gửi UDR(Data-Reference=RepositoryData) lên HSS để lấy

6-7 MMTEL thực hiện gửi SNR(Data-Reference=RepositoryData) để đăng kí theo dõi

8 MMTEL phản hồi lại 200 OK cho REGISTER

2.1.1.3 Đăng ký SCC AS

2-3 SCC AS thực hiện gửi UDR(Data-Reference=IMSPublicIdentities) lên HSS để lấy

2.1.1.4 Đăng kí IP-SM-GW

2-3 SCC AS thực hiện gửi UDR(Data-Reference=IMSPublicIdentities) lên HSS để lấy

10 IP-SM-GW thực hiện gửi 200 OK cho REGISTER

2 P-CSCF định tuyến bản tin SUBSCRIBE tới S-CSCF

1 UE gửi bản tin REGISTER tới P-CSCF.

2 P-CSCF thêm địa chỉ của pcscf vào trường Path.

4 HSS trả về UAA chứa AVP:

 Server-name : S-CSCF URI

5 I-CSCF gửi REGISTER tới S-CSCF

13 P-CSCF thêm địa chỉ của pcscf vào trường Path.

15 HSS trả về UAA chứa AVP:

 Server-name : S-CSCF URI

19 HSS trả lời bản tin SAA

22 P-CSCF gửi 200 OK tới UE