4.5.1. Cấu hình hệ thống DCG (Data charging gateway)
Hình sau mô tả cấu hình hệ thống DCG trong mạng GPRS được phát triển dựa trên mạng GSM. Hai thực thể chính trong mạng GPRS đó là SGSN và GGSN.
Hình 4.24: Hệ thống DCG kết nối với mạng GPRS để tính cước online cho các dịch vụ dữ liệu
GGSN đáp ứng cho việc kết nối tới mạng chuyển mạch gói dữ liệu PDN, PDN có thể như là Internet, VPNs, internal operator intranet,…
GGSN phiên dịch định danh của thuê bao di động thành một địa chỉ IP, theo đó người dùng di động có thể xem như là một người dùng Internet.
BSC
MSC PSTN
VLR
HLR
SGSN
Radius
Telephone Network NetworkSS7
Mobile Packet Data Sub network-
Packet Network DCG
Các thành phần của hệ thống DCG như sau:
Packet Router Bộ định tuyến gói tin Packet Router &
Analyzer (PRA) (Bộ phân tích và định tuyến gói tin)
PRA kết nối ngay sau GGSN, thành phần này hoạt động như một “router gateway” và chặn bất kỳ gói tin nào đi qua DCG.
PRA hỗ trợ phân tích gói IP thời gian thực cho các trường sau:
• Source IP
• Destination IP
• Destination Port
Sau đó PRA quyết định, tùy theo trạng thái thuê bao hiện tại và IP/port đích đến, liệu có chặn việc truyền hoặc nhận gói tin của thuê bao không (ví dụ trong trường hợp thuê bao hết tiền trong tài khoản) hoặc cho gói tin đi qua nó đến đích.
PRA sao chép ra ngoài một gói tin đưa đến lớp cao hơn cho việc xử lý và tính cước.
Charging Gateway
Function (CGF) Chức năng cổng tính cước
• Session Manager (Quản lý phiên)
Chức năng này đáp ứng cho các phiên IP dựa trên IP/Port nguồn và IP/Port đích.
Cho giao thức HTTP (port=80), nó cho phép phân tích gói tin sâu hơn như HTTP và URL.
• Packet Classifier (Bộ phân loại gói)
Chức năng này phân loại các gói thành “các lớp” để cho phép các giá khác nhau cho các gói khác nhau.
• Fillter (Bộ lọc)
Module này đếm số lượng gói thành các bytes đối với mỗi phiên truyền của mỗi thuê bao.
• Token Manager (Bộ quản lý thẻ)
Module này tập hợp lại số bytes tích lũy đã được sử dụng và trong trường hợp số lượng lớn nhất cho phép (quota) đã được sử dụng hết, bộ quản lý thẻ sẽ yêu cầu một quota khác từ IN Prepaid.
RADIUS Client Đây là Sniff Radius (Radius cho việc nghe ngóng) cho lưu lượng chuyển qua Hub, đặc biệt là các yêu cầu Start Accounting và Stop Accounting.
Khi GGSN yêu cầu một IP từ Radius/AAA Server thì Radius Client của DCG sẽ giám sát yêu cầu, và gửi tới RTB server một tập MSISDN và IP tương ứng.
Hình vẽ sau chỉ ra quy trình sự kiện hoặc phiên truyền dữ liệu bắt đầu và được kết thúc bởi thuê bao. Ở đây ta dùng hình thức tính cước dựa trên dung lượng data:
Data Script - Normal Start ,
Termination after Radius stop — initiated by subscriber
Radius
PRA CGF SLEE Prepaid
Packet
Account Start
Start Script
Get Qouta
1. Authorize Subscriber 2. Send Sub Filter Index 3. Furnish Qouta Response
Apply Charging Filter Index
Packet Packet
Packet Packet
Packet
Account Stop Apply Charging
Report User Remove
Release Radius
Stop Session
Hình 4.25: Quá trình tính cước thời gian thực cho dữ liệu qua DCG Flow Based Charging
HTTP (Get)
GGSN Packet
Analyzer
HTTP (Get) Source IP = A
Source Port = a Dest IP = X Dest Port = 80
1. Subscriber:
A = Allowed/ Prohibited 2. Prohibited Destination:
Dest IP/Port = X/80 HTTP (Get)
HTTP (Get) HTTP (Get)
CGF
Application Analyzer 1. Analyze HTTP (URL) 2. Performs Redirect functionality Packet Classifier 1. Classify the packet based on the IP/Post and HTTP URL
Filter
1. Accumulates the traffic per subscriber based on Dest IP/Port and URL Token Manager 1. deduct the accumulated traffic from the token.
2. Request new token.
SLEE
Get Token
Prepaid
Get Qouta
Hình 4.26: Quy trình xử lý của các module trong DCG
Các giao diện:
• Radius/AAA Server– CGF: Bắt đầu và kết thúc tính cước dựa vào accounting các gói tin start và stop.
• PRA– CGF: RBT báo cho PMC biết trạng thái cuả người dùng, tập bị chặn các IP/Port và PMC gửi các gói dữ liệu tới RBT để phân tích.
• CGF– SLEE: RBT khởi động một SLEE script cho mỗi phiên dữ liệu. Script này thông báo tới RBT khi thực hiện ApplyCharging và nhận ApplyChargingReport từ RBT.
• SLEE –Prepaid System: Với việc tính cước dựa trên volume, SLEE trao đổi thông tin tính cước với IN Prepaid thông qua một charging API.
4.5.2. Kiến trúc của hệ thống – Tổ chức phần mềm
Dựa trên các chức năng và ý tưởng tổ chức hệ thống tính cước online cho dịch vụ gia tăng, sau đây ta đưa ra một mô hình đáp ứng được các yêu cầu của hệ thống:
Kiến trúc phần mềm của CCG (CCG SW architecture):
Hình 4.27: Kiến trúc phần mềm của CCG Các thực thể chức năng CCG SW:
o HTTP Server
o SLEE – Service Logic Execution Environment o DBSC (Database Service Creator)
o DMS (Database Management System - SQL) o Storage and Reporting
o Application (User Interface)
Phần mềm của hệ thống CCG được kiến trúc phân lớp và chia thành 4 lớp chức năng, sau đây là chức năng của từng lớp:
1. Lớp giao thức (Protocol Layer)
Lớp này có 4 modules chính làm nhiệm vụ giao tiếp với các hệ thống ngoài để gửi và nhận các yêu cầu cho việc tính cước các dịch vụ Online:
CAMEL Phase 2 module: Giao tiếp với hệ thống IN của mạng qua giao thức CAMEL phase 2.
SMPP Client/Server: Module này đảm nhận việc nhận và chuyển tiếp các bản tin SMS. Nó giao tiếp với các SMSC của mạng với chức năng là 1 SMPP client và một mặt nó giao tiếp với SMPP Gateway của mạng với chức năng là một SMPP Server.
HTTP: Module này thiết kế để giao tiếp với các hệ thống ứng dụng cho các dịch vụ 3rd party. Các yêu cầu cho việc tính cước các dịch vụ 3rd party được gửi và nhận qua Module này.
DCG: DCG được thiết kế với các chức năng như ở phần trên đã xem xét. DCG là cầu nối trung gian giữa mạng GPRS và mạng số liệu (như Internet, Wap,…) và thực hiện việc nhận thực tài khoản thuê bao, trừ cước khi thuê bao sử dụng dịch vụ GPRS.
2. Lớp Môi trường thi hành Logic dịch vụ (SLEE Layer)
Đây là lớp quan trọng nhất trong kiến trúc của hệ thống CCG, chức năng của nó như sau:
+ Đảm bảo logic của cuộc gọi hoạt động được chính xác (theo đúng các yêu cầu về quá trình cuộc gọi).
+ Phân tích các yêu cầu và lấy thông tin để đưa ra thuê bao nào là thuê bao trả trước, thuê bao nào là trả sau để ra quyết định tính cước.
+ Kích hoạt module của các lớp khác để hoạt động đúng logic 3. Lớp dịch vụ (Service Layer)
Lớp này cho phép nhà khai thác định nghĩa các dịch vụ và cập nhật các thay đổi của các dịch vụ này như: thay đổi giá cước, thay đổi địa chỉ dịch vụ, xóa dịch vụ,…
Lớp này có một công cụ gọi là DBSC (Database Service Creation)được sử dụng cho việc tạo ra các bảng (tables) trong Database. Các bảng này sẽ được tích hợp với các service scripts đang chạy trong SLEE và sử dụng các thông tin trong bảng (được
định nghĩa bởi người sử dụng) để thực hiện các yêu cầu tính cước theo các scenarios được yêu cầu.
DBSC được sử dụng định nghĩa các dịch vụ như sau:
Định nghĩa tính cước SMPP:
Dùng DBSC để tạo ra các bảng mới cho các dịch vụ SMS, các bảng này gọi là
“content to DA conversion”. Bảng này sẽ dịch các content address thành các destination address theo đó cho phép tính cước thuê bao (DA) với các content nhận được. Bảng này được mô tả như sau:
Điều này có nghĩa là khi content1 được tìm thấy trong bản tin SMPP, thuê bao DA *12345 sẽ được tính cước cho bản tin này.
Tất cả các định nghĩa và xử lý của tables được thực hiện qua 1 WEB dựa trên GUI và thuận tiện cho việc thay đổi cập nhật.
Định nghĩa tính cước XML/HTTP:
Sử dụng DBSC cho việc định nghĩa các table cho việc tính cước các dịch vụ 3rd party qua giao tiếp XML/HTTP. Bảng này được gọi là “XML field to DA conversion”. Bảng này sẽ dịch một input field trong các bản tin XML (sau khi phân tích) thành destination address theo đó cho phép tính cước thuê bao (DA) cho việc nhận và sử dụng các dịch vụ.
Mô tả của bảng này như sau:
Điều này có nghĩa là trường C được tìm thấy trong nội dung của XML nhận được, tài khoản của thuê bao DA #123245 sẽ được tính cước cho dịch vụ
Tất cả các định nghĩa và xử lý của tables được thực hiện qua 1 WEB dựa trên GUI và thuận tiện cho việc thay đổi cập nhật.
Định nghĩa tính cước data:
Không giống với 2 định nghĩa dịch vụ ở trên (sử dụng DBSC), sự định nghĩa Content address Destination Address
Content1 *12345
XML field contents (to be defined by the platform user)
Destination Address
Field C #12345
Định nghĩa tính cước sẽ bao gồm thành phần cho việc tính cước như trường thông tin đưa ra và giá cước.
4. Lớp giao diện (Interface Layer)
Lớp này xác định các giao diện cho phép người quản lý có thể giao tiếp với lớp 3 để quản lý và cập nhật các dịch vụ, và các thông tin quản lý khác của hệ thống (như cập nhật thuê bao postpaid, xuất ra các thống kê về số lượng dịch vụ được quản lý tính cước trên CCG. Các giao diện cho các giao tiếp này bao gồm:
o XML/HTTP SOAP CLI, o Batch API,
o Export service.