4.3. Nguyên tắc của tính cước dựa trên CAMEL phase 2 đối với các dịch vụ gia tăng
4.3.2. Ứng dụng của CAMEL phase 2 tính cước online cho các dịch vụ gia tăng
4.3.2.3. Tính cước dịch vụ 3 rd Party
CCG sẽ hỗ trợ một giao tiếp mở XML cho giao diện HTTP. Giao diện này cho phép nhà khai thác phát triển hoặc nhà cung cấp 3rd Party sử dụng CCG để thực hiện tính cước online cho các ứng dụng của họ.
Giao diện HTTP/XML của CCG có các đặc tính sau:
• Nhiều Users/Clients: Nhiều clients có thể kết nối đồng thời đến hệ thống, thi hành nhiều nhiệm vụ khác nhau và sử dụng cho các dịch vụ khác nhau đồng thời.
• Redundancy: Cấu hình dự phòng load balancing giữa nhiều thành phần mạng (theo sự ưu tiên định nghĩa trước) theo hướng phát. Giải pháp đưa ra là dùng chức năng IP Active Standby cho hướng nhận, đảm bảo clients luôn luôn có - thể kết nối đến hệ thống bằng cách sử dụng cùng địa chỉ IP.
• HTTP 1.1 Complient (RFC 2616): giao diện này hỗ trợ phương pháp POST/GET trong cả hai hướng phát và thu. HTTPS qua SSL cũng được hỗ trợ cho hướng nhận.
• Full XML Support over HTTP: Bất kỳ định dạng tự do XML nào có thể sẽ được gửi tới hệ thống và từ hệ thống kích hoạt chức năng yêu cầu dịch vụ. Nhà khai thác sử dụng một giao diện đồ họa UI cho việc định nghĩa định dạng của tài liệu XML và các phần liên quan trong nó phục vụ cho các thông số input/output.
• SOAP (v1.1): Hệ thống dùng SOAP 1.1 complient. Nhà khai thác có thể định nghĩa khối xây dựng độc lập dịch vụ (SIB’s – Service Independent Building blocks) để sử dụng hoặc là Web service (bên nhận RX) hoặc là SOAP clients – (phát – TX).
• Hỗ trợ WSDL 1.1 Một WSDL file có thể được nhập vào hệ thống, và sử – dụng một wizard (thuật sỹ) dựa trên ứng dụng. Tất cả SIB’s đại diện cho dịch vụ SOAP có thể được tự động sinh ra. Những SIB’s này có thể được sử dụng sau đó với một WFCE (Work Flow Creation Environment script).
Ứng dụng CAP2 cho tính cước các dịch vụ 3rd party:
Giao tiếp giữa hệ thống CCG và các hệ thống ứng dụng 3rd party và IN:
3rd party element CCG Prepaid platform
HTTP/XML SS7/CAMEL
Hình 4.14: Kết nối của CCG với 3rd party
A. Tính cước 2 giai đoạn (two-stage charging):
Tính cước 2 giai đoạn được sử dụng khi cần xác nhận là thuê bao đủ tiền trong tài khoản trước khi tính cươc sự kiện.
Scenario 1: tính cước thành công
Sau đây là mô tả quy trình cuộc gọi khi thuê bao đủ tiền trong tài khoản:
3rd party element CCG Prepaid platform
Reserve (req)
IDP
RRBE + Continue
Reserve Ack (Resp)
T1 = 100 sec Charge (req)
ERB=Answer
ERB=Rel 1 sec
Charge (resp=OK) HTTP transaction 1
HTTP transaction 2
Hình 4.15: Tính cước thành công dịch vụ 3rd part
1. Giao dịch HTTP đầu tiên được bắt đầu bởi thành phần 3rd party kích hoạt kiểm tra tiền trong tài khoản trả trước của thuê bao.
2. Khi tài khoản còn đủ (OK), một bản tin Acknowledge được gửi tới thành phần 3rd party với một ID nhận biết cho giao dịch (Transaction ID).
3. Khi đó hệ thống cũng khởi động với một timer tại cuối giao dịch HTTP 1 (timer được thiết lập ở đây là 100s) trong khi giao dịch HTTP 2 được yêu cầu khởi động. Nếu HTTP 2 không xảy ra, thì một quy trình xử lý cuộc gọi khác được yêu cầu (mô tả ở scenarios sau).
4. Trong phiên giao dịch này, một bản tin tính cước được gửi từ thành phần 3rd party với một ID nhận biết giao dịch để yêu cầu hoạt động tính cước đến hệ thống CCG sử dụng giao thức CAMEL. CCG gửi các bản tin Answer/release trong thời gian cách nhau khoảng 1s tới IN.
Scenario 2: Rollback
Quy trình gửi bản tin CCG platform được yêu cầu thực hiện hoạt động rollback cho giao dịch của một thuê bao nào đó:
3rd party element CCG Prepaid platform
Reserve (req)
IDP
RRBE + Continue Reserve Ack (Resp)
Transaction ID
T1 = 100 sec Rollback (req)
Transaction ID
ERB=Rel
Rollback (resp=OK) HTTP transaction 1
HTTP transaction 2
Hình 4.16: Thuê bao không sử dụng dịch vụ thành công, CCG ko trừ tài khoản 1. Giao dịch HTTP đầu tiên được bắt đầu bởi thành phần 3rd party kích hoạt kiểm tra tiền trong tài khoản trả trước của thuê bao.
2. Khi tài khoản còn đủ (OK), một bản tin Acknowledge được gửi tới thành phần 3rd party với một ID nhận biết cho giao dịch (Transaction ID).
3. Nếu thành phần 3rd party nhận được một bản tin lỗi từ SMSC (nội dung bản tin bị lỗi), khi đó cần thiết phải rollback (trở lại trạng thái cũ) cho giao dịch. Do đó thành phần 3rdparty cần phát ra một bản tin rollback gửi đến CCG platform để CCG gửi yêu cầu giải phóng tài khoản tới IN prepaid, sau đó CCG gửi trả về bản tin ACK (rollback thành công) cho thành phần 3rd party.
Scenario 3: Prepaid Platform Reject
Quy trình cuộc gọi khi thuê bao không đủ tiền trong tài khoản trả trước của nó ở IN prepaid system hoặc các nguyên nhân khác do nhà khai thác định nghĩa (ví dụ như tài khoản hết hạn sử dụng, thuê bao không ở trong trạng thái active,…).
3rd party element CCG Prepaid platform
Reserve (req)
IDP
ReleaseCall
Reserve Nack (Resp = prepaid failure) HTTP transaction 1
Hình 4.17: Tài khoản ko đủ để sử dụng dịch vụ hoặc thuê bao ko hợp lệ
1. Giao dịch HTTP đầu tiên được bắt đầu bởi thành phần 3rd party kích hoạt kiểm tra tiền trong tài khoản trả trước của thuê bao.
2. Nếu số tiền trong tài khoản thuê bao không đủ cho giao dịch, hệ thống IP prepaid gửi cho CCG một bản tin Release call (kết thúc cuộc gọi), CCG theo đó sẽ kết thúc giao dịch HTTP 1 và gửi bản tin Reserse NAK (đặt trước tài khoản không thành công) cho 3rdParty để kết thúc giao dịch này.
Scenario 4: Thời gian giữa việc đặt trước tài khoản và quá hạn tính cước
Hình vẽ sau mô tả quy trình bản tin thời gian giữa HTTP 1 và 2 quá hạn với các nguyên nhân khác nhau:
3rd party element CCG Prepaid platform
Reserve (req)
IDP
RRBE + Continue
Reserve Ack (Resp)
T1 = 100 sec HTTP transaction 1
Charge (req)
Charge Nack (resp=timer expired) HTTP transaction 2
ERB = Rel
Hình 4.18: Quá hạn thời gian đặt trước tài khoản
1. Khi giao dịch HTTP 1 kết thúc, một timer T1được thiết lập 100 s.
2. Nếu giao dịch HTTP 2 không được khởi động trước khi quá hạn T1, thì tài khoản đặt trước được giải phóng. Khi CCG nhận được bản tin yêu cầu tính cước, nó sẽ trả một bản tin NAK với nguyên nhân cho thành phần 3rd party (quá hạn thời gian).
Scenario 5: Thiếu thông số thứ tự (sequence) (vi phạm giao thức)
Hình vẽ sau mô tả quy trình bản tin khi bản tin nhận bị sai thứ tự xử lý. Ví dụ này minh họa nhận 2 lần một bản tin reserve:
3rd party element CCG Prepaid platform
Reserve (req)
IDP
RRBE + Continue
Reserve Ack (Resp)
T1 = 100 sec HTTP transaction 1
Reserve Nack (resp=missed sequence)
ERB = Rel Reserve (req)
Hình 4.19: Lỗi thiếu số thứ tự cho giao dịch của thuê bao
Sau khi giao dịch HTTP đầu tiên được kết thúc thành công, CCG đang đợi để bắt đầu giao dịch HTTP thứ 2. Nếu CCG nhận một bản tin Reserve khác mà không có sequence (thay vì nhận bản tin tính cước), CCG sẽ hủy bỏ giao dịch này.
B. Tính cước một giai đoạn
Tính cước một giai đoạn đoạn được sử dụng khi muốn tính cước cho một sự kiện ngay lập tức sử dụng một giao dịch HTTP duy nhất, do đó tính cước một giai đoạn khong cần chờ sự xác nhận thông tin từ hệ thống prepaid của IN.
Sau đây là các scenarios cho việc tính cước 1 giai đoạn, các tình huống thông thường:
Scenario 1: Successful Charge (tính cước thành công)
3 party element CCG Prepaid platform
Charge (req)
IDP
RRBE + Continue
Charge Ack (resp) HTTP transaction 1
Answer
REL
Hình 4.20: Tính cước 1 giai đoạn thành công
Theo quy trình bản tin cuộc gọi này, sequence được yêu cầu trong bản tin tính cước gửi từ thành phần 3rd party cho CCG đêr CCG gửi lệnh tính cước tới IN ngay khi nhận được yêu cầu từ thành phần 3rd party. Theo quy trình cuộc gọi này không cần thiết phải có ID nhận dạng trong bản tin tính cước.
Scenario 2: Prepaid Platform Reject
CCG có thể gặp phải một tính huống tính cước không thành công trong phương pháp tính cước một giai đoạn. Điều này có thể xảy ra nếu không đủ tiền trong tài khoản của thuê bao hoặc trong trường hợp thuê bao không hợp lệ hoặc thuê bao không còn hoạt động (de-active status).
3rd party element CCG Prepaid platform
Charge (req)
IDP
ReleaseCall
Charge Nack (resp) HTTP transaction 1
Hình 4.21: Thuê bao không đủ tài khoản hoặc không hợp lệ trên hệ thống trả trước
Sau khi có yêu cầu tính cước từ thành phần 3rd party, CCG gửi yêu cầu tính cước trong bản tin IDP gửi tới IN prepaid. Nếu IN prepaid trả về cho CCG một bản tin ReleaseCall (tức là số tiền trong tài khoản thuê bao đã hết, hoặc thuê bao không hợp, ….), ngay lập tức CCG gửi một bản tin NAK trả về cho thành phần 3rd