Điểm trung tâm trong kiến trúc tính cước ngoại tuyến là chức năng tập hợp tính cước (CCF – Charing Collection Function). CCF nhận thông tin tính toán từ các thực thể IMS qua điểm tham chiếu Rf. Hơn nữa CCF xử lý dữ liệu nhận được và sau đó xây dựng và định dạng bản ghi dữ liệu cước CDR (charing data record) hiện thời. CDR được chuyển tới hệ thống hóa đơn, nhận được nhờ cung cấp CDR cuối cùng, cùng với thông tin tính cước nhận được từ các nguồn khác như là (ví dụ chức năng cổng tính cước, hoặc CGF-Charing Gateway Function). Hình 2.12 mô tả kiến trúc tính cước ngoại tuyến trong một trường hợp ở nơi cả hai phần chủ gọi và phần bị gọi đều đang sử dụng chuyển vùng IMS. Khi người dùng không chuyển vùng ở đó sẽ duy nhất một CCF liên quan.
Nhóm 1 _ D11VT7 58
Bp
hách (B) Hệ thống hóa đơn Hệ thống hóa đơn
Hệ thống hóa đơn Hệ thống hóa đơn CCF CCF CCF CCF CGF CGF Bi Rf AS AS MRFC MRFC S-CSCF S-CSCF I-CSCF I-CSCF BGCF BGCF MGCF MGCF P-CSCF P-CSCF GGSN GGSN SGSN SGSN Nhà (A) Nhà (B) Khách (A) Rf Bi Rf Rf Bi Bp Ga Ga Khách (B)
Hình 2.12: Kiến trúc tính cước IMS ngoại tuyến
a. Chức năng tập hợp tính cước CCF
Cách sử dụng của CCF cho phép một nhà vận hành có điểm tham chiếu đơn hướng về hệ thống hóa đơn, CCF chuyển giao thông tin tính cước từ các thực thể IMS (AS, MRFC, S-CSCF, I-CSCF, P-CSCF, BGCF, MGCF) tới các hệ thống hóa đơn tự chọn của nhà vận hành mạng. Các chức năng chính của CCF là:
Tập hợp thông tin thanh toán từ các thực thể IMS và tạo thông tin thanh toán chung;
Tương quan, hợp nhất, lọc các trường không cần thiết và thêm vào thông tin nhà vận hành riêng biệt để nhận thông tin thanh toán;
Tạo các CDR sau khi tiền xử lý;
Chuyển các CDR tới hệ thống hóa đơn;
Đệm CDR khi hệ thống hóa đơn bận;
CCF có thể thực hiện như là một trung tâm, phần tử mạng riêng hoặc như là một chức năng tích hợp cứ trú trong các thực thể IMS. Có một CCF đơn giảm bớt tải của thực thể IMS bởi vì nó không cần thiết để đệm và hoàn trả các CDR hiện thời.
Nhóm 1 _ D11VT7 59
b. Chức năng cổng tính cước
CGF trong miền chuyển mạch gói (PS) cung cấp một cơ chế để chuyển giao thông tin tính cước từ các node SGSN và GGSN tới các hệ thống hóa đơn đã được chọn của nhà vận hành mạng. Các chức năng chính của CGF cho miền PS là nguyên lý tương đương cho các CCF sử dụng trong miền IMS. Một điểm khác là CGF nhận các CDR hợp lệ từ SGSN và GGSN.
c. Hệ thống hóa đơn
CCF và CGF gửi các CDR tới hệ thống hóa đơn tạo ra hóa đơn thực sự (ví dụ gửi tới thuê bao mỗi tháng một lần). Hóa đơn sẽ bao gồm ví dụ số phiên, đích, khoảng thời gian và loại phiên (âm thanh, hình ảnh).
d. Điểm tham chiếu Rf (Diameter)
Nguyên lý cơ bản
Chức năng tính cước ngoại tuyến dựa trên thông tin báo cáo từ các nút mạng IMS dựa trên việc nhận một vài phương pháp SIP khác nhau hoặc bản tin ISUP, đa số thông tin liên quan đến thanh toán được chứa trong những bản tin này. Báo cáo này được tiến hành bằng việc gửi bản tin yêu cầu thanh toán Diameter (ACR) (Bắt đầu, chuyển tiếp và dừng) từ các nút IMS tới CCF.
Diameter client sử dụng ACR bắt đầu, chuyên tiếp và dừng trong các thủ tục có liên quan đến các phiên SIP. Người dùng sử dụng các ACR sự kiện cho các phiên SIP không thành công và cho các thủ tục phiên không liên quan.
Nhà vận hành lựa chọn các bản tin phương pháp SIP hoặc ISUP để khởi động ACR. Tuy nhiên, hai mục bắt buộc đã được định nghĩa:
Bất cứ khi nào 200 OK SIP, xác nhận một INVITE SIP khởi tạo, được nhận hoặc MGFC nhận một trả lời ISUP, ACR sẽ bắt đầu được gửi tới CCF.
Bất cứ khi nào nhận được BYE SIP hoặc MGCF nhận một xóa ISUP, sẽ dừng gửi ACR tới CCF.
Bảng 2.3 mô tả tất cả các ACR có thể được gửi từ một P-CSCF, I-CSCF, S- CSCF, MGCF hoặc BGCF. Một danh sách nút cụ thể ACR, với các AVP được mô tả chi tiết trong phần sau.
Nhóm 1 _ D11VT7 60 Bảng 2.3: Bản tin yêu cầu thanh toán khởi sự bởi SIP hoặc bản tin ISUP
cho tất cả các nút IMS trừ MRFC và AS
Bản tin Diameter
Khởi sự bởi SIP/Bản tin ISUP Bắt buộc/ (adsbygoogle = window.adsbygoogle || []).push({});
Cấu hình
ACR (bắt đầu)
SIP 200 OK xác nhận một khởi tạo SIP
INVITE Bắt buộc
ISUP: ANM (có thể dùng được cho MGCF) Bắt buộc
ACR (chuyển tiếp)
SIP 200 OK xác nhận một SIP RE-INVITE hoặc SIP UPDATE (thay đổi trong thành phần phương tiện)
Cấu hình
AVP kết thúc (Acct-Interm-Interval) Cấu hình
ACR (dừng)
Bản tin SIP BYE (cả 2 trường hợp kết thúc
phiên bình thường và bất bình thường) Bắt buộc
ISUP: REL (có thể dùng cho MGCF) Bắt buộc
ACR (Sự kiện)
SIP 200 OK xác nhận phiên không liên quan đến các bản tin SIP là: SIP NOTIFY SIP MESSAGE SIP REGISTER SIP SUBCRIBER Cấu hình Cấu hình Cấu hình Cấu hình Đáp ứng SIP cuối cùng (4xx, 5xx, 6xx), cho
biết rằng một phiên SIP không thành công Cấu hình *
Đáp ứng SIP cuối cùng (4xx, 5xx, 6xx), chỉ
Nhóm 1 _ D11VT7 61
không thành công
SIP CANCEL, chỉ định sự bải bỏ của phiên
SIP Cấu hình *
I-CSCF hoàn thành một truy vấn Cx mà đưa
Nhóm 1 _ D11VT7 62 Bảng 2.4 Bản tin yêu cầu thanh toán khởi tạo bởi các phương pháp SIP đối
với MRFC Bản tin Diameter Trigger Bắt buộc/Cấu hình ACR (bắt đầu) SIP 200 OK xác nhận một SIP INVITE cho khởi tạo một phiên hội thảo đa phương tiện không dự tính trước
Bắt buộc
ACR (chuyển
tiếp)
SIP ACK xác nhận một SIP INVITE để
kết nối một UE tới phiên hội thảo Bắt buộc
ACR (dừng) (adsbygoogle = window.adsbygoogle || []).push({});
Kết thúc AVP (AVP-interim-Interval) Cấu hình
Bản tin SIP BYE Bắt buộc
SIP final đáp ứng với lỗi mà là 4xx, 5xx, 6xx chỉ định sự kết thúc của một phiên
Bắt buộc
Các AS hỗ trợ 4 kiểu ACR (Bắt đầu/chuyển tiếp/dừng/sự kiện). Sử dụng bản tin ACR bắt đầu, chuyển tiếp và dừng (Tính cước phiên) ngược với ACR sự kiện (tính cước sự kiện) tùy thuộc vào các nhà cung cấp dịch vụ bởi server ứng dụng. Ví dụ các luồng cho một AS tận dụng thanh toán sự kiện và một AS sử dụng thanh toán phiên được đưa ra trong sau.
Nhóm 1 _ D11VT7 63 UE P-CSCF CCF (Khách) S-CSCF CCF (nhà) Mạng khách Mạng nhà
Báo hiệu SIP
Giám sát dịch vụ
Giám sát dịch vụ
Mở P-CSCF CDR
Mở một S-CSCF CDR
Báo hiệu SIP Thiết lập phiên SIP 1. INVITE 1. INVITE 1. INVITE 2. 200 OK (Mời) 2. 200 OK (Mời) 2. 200 OK
5. Yêu cầu thanh toán (Bắt đầu)
3. Yêu cầu thanh toán (bắt đầu)
6. Yêu cầu
thanh toán 4. Trả lời thanh
toán
Hình 2.13: Biểu đồ chuỗi bản tin cho thiết lập phiên (di động)
Hình 2.13 đưa ra sự giải quyết Diameter mà yêu cầu giữa CSCF và CCF trong suốt phiên thiết lập tạo ra bởi UE
1. Phiên được khởi tạo;
2. Đích trả lời và đáp ứng cuối cùng được nhận;
3. Dựa trên nhận đáp ứng cuối cùng, S-CSCF gửi một yêu cầu thanh toán với kiểu bản ghi thanh toán chỉ định là START_RECORD để ghi lại bắt đầu của phiên người dùng và bắt đầu của thành phần phương tiện trong S-CSCF CDR;
4. CCF xác nhận việc nhận dữ liệu và mở ra S-CSCF CDR; 5. Giống với 3, nhưng cho P-CSCF;
6. Giống với 4, nhưng tạo ra P-CSCF CDR;
Thiết lập phiên-Di động kết thúc
Hình 2.14 đưa ra giải quyết Diameter mà yêu cầu giữa CSCF và CCF trong suốt phiên thiết lập mà được kết thúc tới một nút di động.
Nhóm 1 _ D11VT7 64
UE P-CSCF CCF
(Khách) S-CSCF
CCF (adsbygoogle = window.adsbygoogle || []).push({});
(nhà) I-CSCF
Báo hiệu SIP
Báo hiệu SIP
Thiết lập phiên SIP
1. Mời Yêu cầu Cx với
HSS Tạo I-CSCF CDR Giám sát dịch vụ Mở S-CSCF CDR Mở P-CSCF CDR 1. Mời
2. Yêu cầu thanh toán (sự kiện) 3. Trả lời thanh toán 1. Mời 1. Mời 4. 200 OK 4. 200 OK
5. Yêu cầu thanh toán (Bắt đầu)
4. 200 OK
4. 200 OK
7. Yêu cầu thanh toán (bắt đầu)
8. Trả lời thanh toán 6. Trả lời thanh toán
Mạng khách Mạng nhà
Hình 2.14: Bảng chuỗi bản tin cho thiết lập phiên (kết thúc di động)
1. Phiên được khởi tạo;
2. Dựa trên hoàn thành Truy vấn Cx, I-CSCF gửi một yêu cầu thanh toán với kiểu bản ghi thanh toán đặt thành EVENT (sự kiện);
3. CCF xác nhận dữ liệu đã được nhận và tạo ra I-CSCF CDR; 4. Đích trả lời và đáp ứng cuối cùng được gửi;
5-8. Những bước này được mô tả giống như trong phần trên;
Thủ tục giữa phiên
Hình 2.15 đưa ra sự giải quyết Diameter mà được yêu cầu giữa CSCF và CCF khi một UE tạo ra SIP (Re-) INVITE hoặc SIP UPDATE trong giữa phiên, để thay đổi thành phần môi trường, hoặc khi mà được giữ lại và thủ tục tiếp tục lại.
Nhóm 1 _ D11VT7 65
UE P-CSCF CCF
(Khách) S-CSCF
CCF (Nhà)
Tiếp diễn phiên SIP
Giám sát dịch vụ
Báo hiệu SIP
Giám sát dịch vụ
Cập nhật S-CSCF CDR Cập nhật P-CSCF
CDR (adsbygoogle = window.adsbygoogle || []).push({});
Tiếp tục phiên SIP 1. Mời/Cập nhật 1. Mời/Cập nhật 1. Mời/Cập nhật 2. 200 OK(mời/cập nhật) 2. 200 OK (Mời/cập nhật) 2. 200 OK (Mời/Cập nhật)
5. Yêu cầu thanh toán (chuyển tiếp)
3. Yêu cầu thanh toán (chuyển tiếp)
6. Trả lời thanh toán 4. Trả lời thanh toán
Mạng khách Mạng nhà
Hình 2.15: Biểu đồ chuỗi bản tin đối với môi trường thay đổi
1. Thay đổi thông tin môi trường được nhận từ thuê bao; 2. Đích xác nhận thay đổi môi trường;
3. S-CSCF gửi yêu cầu thanh toán với kiểu bản ghi thanh toán chỉ định INTERIM_RECORD để ghi lại sự thay đổi của thành phần trong S-CSCF CDR;
4. CCF xác nhận việc nhận dữ liệu và cập nhật S-CSCF CDR; 5. Giống với 3 nhưng là của P-CSCF;
6. Giống với4 nhưng là của P-CSCF CDR;
Từ bỏ phiên – Di động khởi tạo
Hình 2.16 đưa ra sự giải quyết Diameter giữa CSCF và CCF cho từ bỏ phiên mà khởi tạo bởi UE
Nhóm 1 _ D11VT7 66 UE P-CSCF CCF (khách) S-CSCF CCF (nhà) Mạng nhà Mạng khách Đóng S-CSCF CDR Đóng P-CSCF CDR 1. BYE 5. Trả lời thanh toán 3. Trả lời thanh toán 6. 200 OK 6. 200 OK 6. 200 OK Giám sát dịch vụ 1. BYE 1. BYE
2. Yêu cầu thanh toán (dừng)
4. Yêu cầu thanh toán (dừng)
6. 200 OK
Hình 2.16: Biểu đồ chuỗi bản tin cho từ bỏ phiên
1. Phiên được bỏ đi;
2. Tại phiên kết thúc, P-CSCF gửi yêu cầu thanh toán với kiểu bản ghi thanh toán chỉ định STOP_RECORD để ghi lại dừng phiên và dừng lại của thành phần trong P-CSCF CDR;
3. CCF xác nhận nhận dữ liệu và đóng P-CSCF CDR; 4. Giống 2 nhưng là S-CSCF;
5. Giống 3, đóng S-CSCF CDR; 6. Việc dỡ bỏ đã được xác nhận;
Dỡ bỏ phiên- Mạng khởi tạo
Trong trường hợp mạng khởi tạo phiên gỡ bỏ, nút IMS gửi một bản tin SIP BYE mà được đáp ứng với một bản tin SIP 200 OK. Bản tin thanh toán cho trường hợp này giống với di động khởi tạp dỡ bỏ phiên mô tả trong phần trên.
Phiên dỡ bỏ - CCF khởi tạo
Nhà vận hành IMS có thể yêu cầu dỡ bỏ phiên SIP trên khởi tại điều kiện gặp phải, ví dụ ngay sau khi có sự gian lận được phát hiện
Nhóm 1 _ D11VT7 67
Hình 2.17 đưa ra sự giải quyết Diameter mà yêu cầu để dỡ bỏ trên phiên SIP đang tiếp diễn.
UE P-CSCF CCF
(khách) S-CSCF CCF (nhà)
Mạng nhà (adsbygoogle = window.adsbygoogle || []).push({});
Mạng khách
Phiên SIP đang tiếp diễn
Đóng S-CSCF CDR Đóng P-CSCF CDR 1. BYE 1. BYE 1. BYE
2. Yêu cầu thanh toán (dừng) 4. Yêu cầu thanh toán
(dừng) 5. Trả lời thanh toán 3. Trả lời thanh toán 6. 200 OK 7. 200 OK 8. 200 OK
Hình 2.17: Biều đồ chuỗi bản tin đối với mang khởi tạo gỡ bỏ phiên
1. S-CSCF khởi tạo gỡ bỏ phiên SIP với yêu cầu SIP BYE tới các thành phần đầu và cuối.
2. Với quá trình kết thúc phiên, P-CSCF gửi yêu cầu thanh toán với kiểu bản ghi thanh toán chỉ định là STOP_RECORD để ghi lại dừng phiên và dừng thành phần trong P-CSCF CDR;
3. CCF xác nhận việc nhận dữ liệu và đóng P-CSCF CDR; 4. Giống với 2, nhưng dành cho S-CSCF;
5. Giống với 3, nhưng là cho S-CSCF CDR;
6-8 S-CSCF gửi bản tin đáp ứng 200 OK từ các thành phần đầu đến thành phần kết thúc;
Thiết lập phiên – PSTN khởi tạo
Hình 2.18 đưa ra giải quyết Diameter mà yêu cầu giữa MGCF và CCF trong suốt phiên thiết lập khởi tạo từ phía PSTN
Nhóm 1 _ D11VT7 68
PSTN MGCF CCF
Mạng nhà
Báo hiệu SIP/ISUP
Mở MGCF CDR
Báo hiệu SIP
Thiết lập phiên 1. IAM
2. Mời
3. 200 OK (Mời) 4. ANM
5. Yêu cầu thanh toán (Bắt đầu)
6. Trả lời thanh toán
Hình 2.18: Biều đồ chuỗi bản tin cho thiết lập phiên (PSTN khởi tạo)
1. Phiên được tạo ra từ PSTN;
2. Phiên được đặt khởi tạo trong IMS;
3. Đích trả lời và đáp ứng cuối cùng được nhận; 4. MGCF chuyển bản tin trả lời tới PSTN;
5. Dựa trên nhận đáp ứng cuối cùng, MGCF gửi yêu cầu thanh toán với kiểu bản ghi thanh toán chỉ định là START_RECORD để ghi lại bắt đầu phiên người dùng và bắt đầu của thành phần trong MGCF CDR;
6. CCF xác nhận nhận dữ liệu và mở MGCF CDR. (adsbygoogle = window.adsbygoogle || []).push({});
Thiết lập phiên – IMS khởi tạo
Hình 2.19 đưa ra giải quyết Diameter mà yêu cầu giữa BGCF, MGCF và CCF trong suốt phiên thiết lập khởi tạo từ phía IMS.
1. Phiên được tạo ra từ IMS;
2. Phiên hướng về PSTN được thiết lập; 3. Đích trả lời và bản tin trả lời được nhận;
Nhóm 1 _ D11VT7 69
5. Dựa trên việc nhận bản tin trả lời, MGCF gửi một yêu cầu thanh toán với kiểu bản ghi thanh toán chỉ định là START_RECORD để ghi lại bắt đầu phiên người dùng và bắt đầu của thành phần phương tiện trong MGCF CDR;
6. CCF xác nhận việc nhận dữ liệu và mở MGCF CDR.;
BGCF MGCF CCF PSTN
Mạng nhà
Báo hiệu SIP/ISUP
Mở MGCF CDR
Mở BGCF CDR
Báo hiệu SIP/ISUP
Thiết lập phiên 1. Mời 1. Mời 2. IAM 3. ANM 4. 200 OK (Mời)
4. 200 OK 5. Yêu cầu thanh
toán (bắt đầu)
6. Trả lời thanh toán 7. Yêu cầu thanh toán
(bắt đầu)
8. Trả lời thanh toán
Hình 2.19: Biểu đồ chuỗi bản tin cho thiết lập phiên (IMS khởi tạo)
7. Dựa trên nhận bản tin 200 OK, BGCF gửi một yêu cầu thanh toán với kiểu bản ghi thanh toán chỉ định là START_RECORD để ghi lại bắt đầu phiên người dùng và bắt đầu của thành phần trong BGCF CDR;
8. CCF xác nhận nhận dữ liệu và mở ra BGCF CDR;
Phiên dỡ bỏ- PSTN khởi tạo
Hình 2.20 đưa ra giải quyết mà yêu cầu giữa BGCF, MGCF và CCF khi PSTN khởi tạo dỡ bỏ
Nhóm 1 _ D11VT7 70
2. Dựa trên việc nhận bản tin gỡ bỏ, MGCF gửi một yêu cầu thanh toán với kiểu bản ghi thanh toán chỉ định STOP-RECORD để ghi lại sự dừng lại của phiên trong MGCF CDR;
BGCF MGCF CCF PSTN
3. RLC Phiên đang diễn ra Mạng nhà Đóng MGCF CDR Đóng BGCF CDR 1. REL 2. BYE 2. BYE
4. Yêu cầu thanh toán (dừng)
5. Trả lời thanh toán 6. Yêu cầu thanh toán (adsbygoogle = window.adsbygoogle || []).push({});
(Dừng)
7. Trả lời thanh toán
Hình 2.20: Biểu đồ chuỗi bản tin cho dỡ bỏ phiên (PSTN khởi tạo)
3. CCF xác nhận việc nhận dữ liệu và đóng MGCF CDR; 4. Giống 4, nhưng cho BGCF
5. Giống 5, nhưng đối với BGCF
Gỡ bỏ phiên – IMS khởi tạo
Hình 2.21 đưa ra sự giải quyết Diameter mà được yêu cầu giữa BGCF, MGCF và CCF khi IMS khởi tại gỡ bỏ phiên.
1. Việc gỡ bỏ phiên được khởi tạo từ phía IMS; 2. Bản tin gỡ bỏ được gửi hướng về PSTN; 3. Xác nhận bản tin gỡ bỏ được nhận từ PSTN;