Kiến trúc tính cước trực tuyến

Một phần của tài liệu tìm hiểu về giao thức diameter (Trang 76 - 85)

S-CSCF AS MRFC SGSN ISC Ro CAP Hệ thống tính cước trực tuyến Chức năng tính cước phiên (SCF) Chức năng phân loại Chức năng tính cước sự kiện (ECF) Chức năng tương quan Chức năng tính cước kênh mang (BCF)

Hình 2.22: Kiến trúc tính cước IMS trực tuyến

S-CSCF, AS và MRFC là các thực thể IMS có thể thực hiện tính cước trực tuyến. AS và MRFC sử dụng điểm tham chiếu Ro, trong khi S-CSCF sử dụng điểm tham chiếu ISC (điều khiển dịch vụ IMS) để liên lạc với OSC (hệ thống tính cước trực tuyến).

a. Chức năng tính cước sự kiện (ECF)

Khi UE yêu cầu cấp phép tính cước từ AS hoặc MRFC, AS hoặc MRFC liên lạc với ECF (chức năng tính cước sự kiện) thông qua điểm tham chiếu Ro trước khi chuyển giao dịch vụ tới người dùng: ví dụ, người sử dụng có thể gửi một yêu cầu SUBSCRIBE tới một server mới hỏi về hội nghị thoại được thiết lập. ECF hỗ trợ hai mô hình cấp phép khác nhau: tính cước sự kiện trực tiếp và tính cước sự kiện với dành riêng đơn vị.

Trong mô hình tính cước sự kiện trực tiếp ECF sử dụng chức năng phân loại để tìm bảng giá thích hợp cho một sự kiện. Sau khi giải quyết bảng giá và giá, ECF trừ đi một khoản tiền thích hợp từ tài khoản của người dùng và cấp các ACR từ AS hoặc MRFC. Khi sử dụng mô hình này AS hoặc MRFC biết rằng nó có thể chuyển giao dịch vụ được yêu cầu tới bản thân người dùng. Ví dụ AS có thể gửi ACR và nói cho ECF biết về dịch vụ (tức là, một trò chơi cờ) và số đơn vị (tức là, 2) được chuyển giao. Sau đó ECF sử dụng chức năng phân loại để quyết định bảng giá (0.3€) và để tính toán giá dựa trên số đơn vị được chuyển giao (0.6€). Cuối cùng tài khoản của người sử

Nhóm 1 _ D11VT7 77

dụng bị trừ đi 0.6€ và ECF thông báo cho AS biết rằng 2 đơn vị đã được cấp trong ACA (trả lời thanh toán).

Trong tính cước sự kiện với mô hình dàng riêng đơn vị ECF sử dụng chức năng phân loại để quyết định giá của dịch vụ yêu cầu theo thông tin dịch vụ riêng biệt, nếu giá không được định sẵn trong ACR. Khi đó ECF đặt trước một khoản tiền thích hợp từ tài khoản của người dùng và đáp lại lượng tài nguyên tương ứng từ AS hoặc MRFC. Lượng tài nguyên có thể là thời gian hoặc khối lượng dữ liệu cho phép. Khi tài nguyên được cấp tới người dùng đã được dùng hết hoặc dịch vụ đã được chuyển giao thành công hoặc kết thúc, AS hoặc MRFC thông tin cho ECF biết lượng tài nguyên đã dùng hết. Cuối cùng ECF trừ đi lượng đã dùng từ tài khoản của người sử dụng, nhưng có thể đòi hỏi sự tương tác hơn nữa với chức năng phân loại. Mô hình này là thích hợp khi AS hoặc MRFC không thể định rõ trước được hay không dịch vụ có thể được chuyển giao hoặc lượng tài nguyên cần đến không biết trước để dùng cho dịch vụ đặc biệt (ví dụ trong hội nghị).

b. Chức năng tính cước phiên (SCF)

Chức năng tính cước phiên (SCF) là dùng để thực hiện tính cước theo cách sử dụng tài nguyên phiên, dựa trên yêu cầu nhận được từ S-CSCF quan điểm tham chiếu ISC. SCF sẽ có thể điều khiển thiết lập phiên bởi cho phép hoặc từ chối một yêu cầu thiết lập phiên sau khi kiểm tra tài khoản của người dùng. Thêm vào, SCF sẽ có thể kết thúc một phiên hiện thời tức là, tài khoản người dùng đã hết. SCF hỗ trợ tính cước sự kiện với mô hình dành riêng đơn vị cho tính cước sự kiện.

Thiết kế hiện tại buộc phải chấp nhận nhiều vấn đề khắt khe. Điều đó có nghĩa là, ví dụ SCF phải hỗ trợ ngăn xếp giao thức SIP, hoạt động như là AS, duy trì mô hình trạng thái cuộc gọi và thực thi điều khiển ngân sách cho các phiên IMS. Có toàn bộ các chức năng này là một phần của một hệ thống tính cước sẽ làm quá tải hệ thống và dẫn đến một cho hệ thống tính cước rời rạc. Thực tế, có hai tùy chọn để giải quyết vấn đề này: hoặc mở rộng điểm tham chiếu ISC hoặc lựa chọn điểm tham chiếu thích hợp khác. Trong phiên bản 6 đó là điểm tham chiếu Ro. Nó có thể chỉ dẫn một vài loại

cổng hoặc chức năng liên kết nối đang được giới thiệu giữa S-CSCF và SCF.

c. Chức năng tính cước kênh mang (BCF)

SGSN sử dụng điểm tham chiếu dựa trên phần ứng dụng CAMEL (CAP) yêu cầu cho phép sử dụng kênh mang từ chức năng tính cước kênh mang (BCF). BCF điều kiển sử dụng kênh mang (ví dụ: trong điều kiện được chấp nhận thời gian hoặc dung

Nhóm 1 _ D11VT7 78

lượng lưu lượng) BCF tương tác với chức năng phân loại và tài khoản của người dùng. Trong phiên bản 6 các chức năng BCF cần mở rộng để kiểm soát WLAN (mạng vùng nội hạt vô tuyến) và các yêu cầu tính cước dựa trên lưu lượng IP từ GGSN.

d. Chức năng phân loại

Chức năng phân loại thực hiện xác định đơn vị, giá và bảng giá. Trong quá trình xác định đơn vị chức năng phân loại tính toán số lượng đơn vị tiền tệ nhỏ của liên quan phiên (ví dụ: các đơn vị dịch vụ, lưu lượng dữ liệu, thời gian), dựa trên dịch vụ được yêu cầu. Xác định bảng giá nghĩa là tính toán giá sử dụng mạng đối với việc sử dụng của một dịch vụ riêng biệt: ví dụ, bảng giá của phiên IMS thông thường có thể là 0.1€ trên phút. Xác định giá được sử dụng để tính toán giá của số nhất định của các đơn vị tiền tệ. Giá được sử dụng để cập nhập số dư tài khoản (bên nợ hoặc bên vay). Có thể thực hiện chức năng phân loại trước khi hoặc sau khi tiêu dùng dịch vụ.

e. Điểm tham chiếu Ro

Nguyên lý cơ bản

Thanh toán trực tuyến IMS về bản chất sử dụng cùng một giao thức mà được sử dụng cho thanh toán ngoại tuyến. Tuy nhiên, đối với thanh toán trực tiếp thì giao thức có thể bao gồm thêm căp thuộc tính giá trị (AVPs) tồn tại trong các bản tin.

2 trường hợp cho thanh toán trực tuyến được phân biệt.

 Thanh toán sự kiện trực tiếp (IEC) và

 Thanh toán sự kiện với đơn vị dành riêng (ECUR)

Trong trường hợp thanh toán sự kiện trực tiếp (IEC), việc đảm bảo dữ liệu tới AS được thực hiện trong một hoạt động đơn lẻ và đồng thời cũng bao gồm việc khấu trừ đơn vị tiền tệ tương ứng từ tài khoản người dùng. Xử lý tính cước được điều khiển bởi CC-request-Type EVENT_REQUEST tương ứng được gửi với một CCR đưa ra cho thanh toán sự kiện.

Ngược lại, thanh toán với đơn vị dành riêng (ECUR) cũng bao gồm xử lý yêu cầu, dự trữ, giải phóng và trả lại các đơn vị không dùng đến. Việc trừ đi đơn vị tiền tệ tương ứng sau khi kết thúc ECUR. Trong trường hợp này, một kiểu yêu cầu CC yêu cầu khởi tạo/cập nhật/kết thúc được sử dụng để điều khiển phiên thanh toán. Trong suốt một phiên SIP, có thể lặp đi lặp lại hoạt động dành riêng đơn vị và hoạt động tính cước chỉ ra trong TS 32.200.

Nhóm 1 _ D11VT7 79

AS/MRFC có thể áp dụng hoặc IEC, khi mà bản tin CCR sự kiện được tạo ra, hoặc ECUR, sử dụng CC khởi tạo, kết thúc, và cập nhật. Việc quyết định áp dụng IEC hoặc ECUR dựa trên dịch vụ và chính sách của người vận hành.

Thanh toán sự kiện tức thời (IEC)

Hình 2.23 đưa ra giải quyết trên giao diện Ro để thực hiện IEC với hoạt động tính cước đơn vị. Hoạt động tính cước đơn vị như là sự lựa chọn truyền ra bên ngoài đồng thời với truyền dịch vụ và truyền nội dung. AS/MRFC phải đảm bảo rằng các yêu cầu dịch vụ đảm bảo thành công, khi mà ngữ cảnh này được sử dụng.

AS/MRFC ECF

1. YÊU CẦU DỊCH VỤ

4. Thực hiện giám sát tính cước sự kiện 2.CCR (yêu cầu khởi tạo, RSU,

RA)

5. CCA (yêu cầu khởi tạo, RSU)

Hoạt động dành riêng đơn vị

3. Time Tx

6. Truyền dịch vụ

Hình 2.23: IEC – Hoạt động chuyển giao đơn vị

1. AS/MRFC nhận một yêu cầu dịch vụ SIP từ S-CSCF.

2. AS/MRFC thự hiện IEC để thực thi nhiệm vụ, AS/MRFC gửi yêu cầu kiểm soát thanh toán (CCR) với CC-Request AVP đặt thành EVENT_REQUEST (yêu cầu sự kiện) để cho biết thông tin dịch vụ cụ thể tới ECF. Requested_Action

AVP(RA) đặt thành tính cước trực tiếp DIRECT_DEBITING. AS/MRFC có thể thêm (yêu cầu đơn vị dịch vụ) Requested-Service-Unit AVP (RSU) (tiền hoặc thứ khác) trong bản tin yêu cầu.

3. Thời gian mà AS/MRFC bắt đầu gửi bản tin yêu cầu CC_request được giám sát bởi đồng hồ đếm Tx. Dựa trên việc nhận bản tin trả lời kiểm soát giá Credit-

Control-Answer (CCA) AS/MRFC sẽ dừng đồng hồ đếm thời gian Tx.

4. ECF xác định các thông số dịch vụ thích đáng liên quan kết hợp với chức năng tính cước của OCS (hệ thống tính cước trực tuyến- Online Charging System).

Nhóm 1 _ D11VT7 80

5. ECF gửi trả lại bản tin CC-answer với CC-Request-Type AVP đặt thành EVENT_REQUEST để AS/MRFC cấp quyền thực thi dịch vụ. (Đơn vị dữ liệu

Granted-Service-Unit AVP) (GSU) và có thể thông tin về giá Cost-infomation AVP (CI) cho biết giá của dịch vụ được chứa trong bản tin trả lời CC-answer).

Bản tin trả lời CC_answer được kiểm tra bởi AS/MRFC phù hợp và dịch vụ đã yêu cầu được giám sát đồng thời với việc truyền dịch vụ.

Nhóm 1 _ D11VT7 81 ECUR – Các đơn vị dành riêng và hoạt động tính cước đơn vị

Hình 2.24 đưa ra sự giải quyết mà được yêu cầu trên giao diện Ro để thực hiện ECUR với các đơn vị dành riêng và hoạt động tính cước đơn vị. Nhiều sự tái tạo của hoạt động này có thể xảy ra.

AS/MRFC ECF 1. YÊU CẦU DỊCH VỤ 5. Truyền dịch vụ 9. Truyền dịch vụ 3. Thực hiện giám sát tính cước sự kiện 7. Thực hiện giám sát tính cước sự kiện 11. Thực hiện giám sát tính cước 2.CCR (yêu cầu khởi tạo, RSU)

4. CCA (yêu cầu khởi tạo, RSU)

6.CCR (yêu cầu cập nhật, RSU, USU)

8. CCA (yêu cầu cập nhật, GSU,FUI)

10. Yêu cầu kết thúc, USU

12. Yêu cầu kết thúc, CI Hoạt động dành riêng đơn vị

Các đơn vị dành riêng và tính cước các đơn vị

Hoạt động tính cước các đơn vị

Hình 2.24: ECUR – Các đơn vị dành riêng và hoạt động tính cước đơn vị

1. AS/MRFC nhận một dịch vụ SIP liên quan từ S-CSCF. Dịch vụ yêu cầu có thể khởi tạo hoặc người dùng hoặc AS/MRFC.

2. Để thực hiện hoạt động đơn vị dành riêng cho một số lượng các đơn vị (tiền hoặc đơn vị không phải là tiền), AS/MRFC gửi một CCR với CC-Request-Type AVP đặt thành INITIAL-REQUEST tới ECF.

2. Khi mà thông tin giá dịch vụ không được nhận bởi ECF, ECF xác định giá của dịch vụ yêu cầu theo nhận thông tin dịch vụ cụ thể bằng việc đưa ra yêu cầu đánh giá tới chức năng đánh giá. Khi mà giá của dịch vụ có trong yêu cầu, ECF sẽ dành

Nhóm 1 _ D11VT7 82

riêng số lượng tiền cụ thể trong tài khoản. Khi mà tài khoản thanh toán có đủ khả năng, ECF dành tài khoản tương ứng từ tài khoản người dùng.

4. Khi mà sự dành riêng này được tạo ra, ECF gửi trả lại bản tin CC-answer với

CC-Reques-Type đặt thành INTIAL-REQUEST tới AS/MRFC để cấp quyền thực thi

dịch vụ (đơn vị dịch vụ được cấp và có thể thông tin giá cho biết giá dịch vụ được bao gồm trong bản tin CC-answer). Khi được yêu cầu, ECF gửi trả lại (chuyển tiếp thanh toán nội bộ) (AII) AVP với trường giá trị đặt thành giá trị khác không

5. Truyền nội dung và dịch vụ được bắt đầu và các đơn vị dành riêng đồng thời được giám sát.

6. Trong quá trình chuyển dịch vụ, để thực hiện tính cước đơn vị và hoạt động của đơn vị dành riêng đến sau, AS/MRFC gửi một CCR với CC-Request-Type AVP đặt thành (UPDATE-REQUEST), để báo cáo các đơn vị dành riêng đã sử dụng và yêu cầu thêm đơn vị. Bản tin CCR với CC-Request-Type AVP đặt thành (UPDATE- REQUEST) phải được gửi bởi AS/MRFC giữa bản tin yêu cầu khởi tạo (INITIAL_REQUEST) và bản tin kết thúc (TERMINATION_REQUEST) trên yêu cầu của ứng dụng giám sát thanh toán trong khoảng thời gian chuyển tiếp hoặc khi mà thời gian chuyển tiếp trôi qua. AS/MRFC có thể có thể gồm thêm yêu cầu đơn vị dịch vụ AVP (Requested-Service-Unit) (tiền hoặc không phải là tiền) trong bản tin yêu cầu. Đơn vị dịch vụ được sử dụng Used-Service-Unit (USU) AVP được bổ sung trong bản tin CCR để trừ đi các đơn vị từ cả tài khoản người dùng và đơn vị dành riêng.

7. ECF khấu trừ tiền đã sử dụng trong tài khoản. Khi mà ECF không nhận được thông tin giá dịch vụ, ECF xác định giá của dịch vụ yêu cầu theo thông tin dịch vụ cụ thể nhận được bằng việc đưa ra yêu cầu đánh giá tới chức năng đánh giá. Nếu mà giá của dịch vụ có trong yêu cầu, ECF sẽ dành riêng lượng tiền cụ thể trong tài khoản. Tài khoản thanh toán mà có khả năng, thì ECF sẽ dự trữ tiền tương ứng từ tài khoản người dùng

8. Việc khấu trừ và dự trữ được tạo ra, ECF gửi trả lại bản tin CC-answer với kiểu yêu cầu giám sát thanh toán CC-Request-Type đặt thành yêu cầu cập nhật (UPDATE-REQUEST) tới AS/MRFC, để cho phép truyền dịch vụ/nội dung được tiếp tục (Cấp đơn vị dữ liệu mới (GSU) AVP và có thể thông tin giá (Cost Infomation) AVP cho biết giá tổng hợp của dịch vụ có trong bản tin trả lời CC-answer. ECF có thể bao gồm đưa ra đơn vị cuối cùng Final-Unit-Indication (FUI) AVP trong bản tin CCA để đưa ra các đơn vị cấp phát cuối cùng.

Nhóm 1 _ D11VT7 83

9. Truyền nội dung/dịch vụ tiếp tục và đơn vị dành riêng được giám sát đồng thời

10. Khi mà truyền dịch vụ/nội dung được hoàn tất hoặc đơn vị cuối cùng được cấp phát, AS/MRFC gửi CCR với CC-Request-Type AVP đặt thành yêu cầu kết thúc (TERMINATE-REQUEST) để kết thúc hoạt động của phiên thanh toán và báo cáo việc sử dụng các đơn vị

11. ECF khấu trừ tài khoản đã sử dụng từ tài khoản người dùng. Đơn vị dành riêng chưa được dùng đến sẽ được giải phóng khi có thể.

12. ECF xác nhận việc nhận bản tin CCR bằng gửi bản tin CCA với CC- Request-Type AVP cho biết yêu cầu kết thúc (TERMINATE-REQUEST) (có thể thông tin giá AVP cho biết giá tổng của dịch vụ trong bản tin trả lời CC-answer ).

Định dạng bản tin

Cấu trúc cơ bản sau được chia sẻ bởi các bản thanh toán trực tuyến. Đây là định dạng của bản tin yêu cầu CC-Request và trả lời CC-answer định nghĩa trong giao thức cơ bản Diameter.

Bản tin yêu cầu điều khiển giám sát (CCR)

Bảng 2.8: Đưa ra cấu trúc cơ bản của bản tin Diameter CC-Request được sử dụng trong thanh toán trực tuyến IMS.

Nhóm 1 _ D11VT7 84 Bảng 2.9 Nội dung Bản tin trả lời giám sát thanh toán (CCA) đối với thanh

Nhóm 1 _ D11VT7 85

Những AVP Diameter mà được sử dụng cho thanh toán trực tuyến được đánh dấu với chữ “yes”. Những Diameter AVP mà không được sử dụng được đánh dấu với chữ “No”. Việc đưa ra nội dung có thể Yes hoặc No được sử dụng đối với EFC cho mục địch thanh toán.

Những biểu tượng sau được sử dụng trong bảng:

 <AVP> đưa ra một AVP bắt buộc với vị trí cố định trong bản tin

 {AVP}đưa ra một AVP bắt buộc trong bản tin

 [AVP] đưa ra một AVP tùy chọn trong bản tin

 *AVP đưa ra rằng nhiều sự kiện có thể có trong một AVP

Một phần của tài liệu tìm hiểu về giao thức diameter (Trang 76 - 85)

Tải bản đầy đủ (PDF)

(90 trang)