Cho dịch vụ Premium SMS, ba bảng sau sẽ chứa thông tin được yêu cầu để xác định thuê bao, tương ứng với hệ thống IN Prepaid đó thuộc về và phương pháp tính cước cho thuê bao đó. Có thể dùng DBSC để tạo ra các bảng này.
Service Codes:
Bảng này sẽ chứa thông tin cho CCG để điều khiển logic của hướng tính cước và dial digit cho giá cước dựa trên mã dịch vụ (service code key). Các trường này định nghĩa các thông tin sau:
i. Service code (Mã dịch vụ cho cả bản tin MO và MT)
ii. Charging direction MO (hướng tính cước MO: "1" là có, "0" nếu không tính)
iii. Charging direction MT (hướng tính cước MT: "1" là có, "0" nếu không tính)
iv. Dial digit for MO charge v. Dial digits for MT charge vi. CP ID (For reporting purpose) vii. CP Name (For reporting purpose)
Nếu giá trị (ii) và (iii) ở trên được đặt là ‘0’, CCG sẽ không kích hoạt các phiên CAMEL tới prepaid systems. CCG sẽ tiếp tục phiên SMPP.
Subscriber Ranges:
Bảng này sẽ chứa toàn bộ dải số thuê bao của nhà khai thác, mỗi dải số thuê bao cần chỉ ra hệ thống IN Prepaid với GT address. Các thông tin cần đưa vào như sau:
i. Range of numbers (ví dụ 7889XXXX – 10K numbers) ii. Full GT address
Postpaid Subscribers:
Bảng này chứa các toàn bộ các thông tin thuê bao trả sau, thông tin được đưa vào lưu trữ là số MSISDN của thuê bao. Trong khi xử lý, nếu CCG nhận ra đấy là giao dịch của thuê bao trả sau thì nó bỏ qua xử lý CAMEL cho thuê bao này và tiếp tục phiên giao dịch. Một CDR được tạo ra với các giao dịch của thuê bao trả sau dùng để xử lý cước của hệ thống Billing System của nhà khai thác.
Data Service Mapping:
Giao diện tính cước dịch vụ dữ liệu của CCG yêu cầu ánh xạ tẩt cả các dung lượng dữ liệu với các khả năng tính cước có thể theo từng phiên GPRS của thuê bao.
Có thể tính cước dựa trên dung lượng dữ liệu (tính bằng Kbyte), theo đó CCG có thể đặt trước tài khoản cho mỗi phiên truyền tương ứng với dung lượng dữ liệu là 50KB. Do đó phải yêu cầu IN Prepaid System có 49 tariff destination để có thể tính cước chính xác cho từng KB.
XML Service Charging Mapping:
Trong giao diện tính cước của XML sẽ có 2 thông số trong XML body dùng để chỉ ra phương pháp tính cước cho dịch vụ XML. Các thông số đó là:
i. Subscriber number: số MSISDN
ii. Destination number: Số đích sẽ chỉ ra hệ thống Prepaid và cấu hình tính cước dịch vụ theo kế hoạch giá cước.
Sau đây là sự triển khai Service mapping plan cho hệ thống CCG:
Data input Sheet
Input Paramters
Country Code 84
CCG Prefix 111
Class
Class 1 Num # 1
Class 2 Num # 2
Class 3 Num # 3
Class 4 Num # 4
Volume of data
0- 10 10
10 20- 20
20 30- 30
30 40- 40
40 50- 50
Type of Service
Preimum SMS 0
GPRS 1
XML VAS 2
GPRS
Country
Code CCC Prefix Type of Service Price Code
Service
Class Volume of Data Premium MO
SMS
Country
Code CCC Prefix Type of Service Price Code
Service
Code
XML VAS Country
Code CCC Prefix Type of Service Price Code Contend
ID Sub Content ID Premium MT
SMS
Country
Code CCC Prefix Type of Service Price Code
Service Code
Country Code 84
Prefix 111
Type of Service 0 Preimum SMS
1 GPRS
2 XML VAS Update
Price Code 00 500 VND
01 1000 VND 02 2000 VND 04 4000 VND 05 5000 VND 06 10000 VND 07 15000 VND
Class of Service 1 GPRS Data Class 1
2 GPRS Data Class 2 3 GPRS Data Class 3 4 GPRS Data Class 4
Volume of Data 10 Charging 0-10 KB
20 Charging 10-20 KB 30 Charging 20-30 KB 40 Charging 30-40 KB 50 Charging 40-50 KB
4.8. Cú pháp khi sử ụ d ng giao ti p XML cho 3rd party chargingế Các thông số của bản tin:
Hệ thống CCG sẽ giao tiếp với các thành phần 3rd party trong mạng bằng cách sử dụng XML qua giao thức HTTP. Giao thức này sẽ có một tập lệnh và các phản hồi giữa chúng như sau:
Reserve Request Command
No. Field name Mandatory/Optional 1 Command “Reserve” M
2 Subscriber number M
3 Content ID M
4 Sub-content ID O
Reserve Response Command
No. Field name Mandatory/Optional
1 Command “Reserve
Response” M
2 Subscriber number M
3 Content ID M
4 Sub-content ID O
5 Result code M
6 Transaction ID M
Charge Request Command
No. Field name Mandatory/Optional
1 Command “Charge” M
2 Subscriber number M
3 Content ID M
4 Sub-content ID O
5 Transaction ID (derived
from the Reserve M in Two-Stage Charging Must not be provided in
Charge Response Command
No. Field name Mandatory/Optional
1 Command “Charge
Response” M
2 Subscriber number M
Rollback Request Command
No. Field name Mandatory/Optional 1 Command “Rollback” M
2 Subscriber number M
3 Content ID M
4 Sub-content ID O
5 Transaction ID M
Rollback Response Command
No. Field name Mandatory/Optional
1 Command “Rollback
Response” M
2 Subscriber number M
3 Content ID M
4 Sub-content ID O
5 Result code M
Subscriber Number Parameter
+ Số thuê bao được dùng là MSISDN + Format: String
+ Used in: All
+ Field type: Mandatory
Content ID Parameter
+ Dùng để xác định loại content, và có thể dựa vào nó để xác định giá cước.
+ Format: String + Used in: All
+ Field type: Mandatory
Sub-Content ID Parameter
+ Được sử dụng để phân loại chi tiết hơn các content và xác định các giá cước tương ứng. Trường thông tin này là tùy chọn.
+ Format: String + Used in: All
+ Field type: Optional
Transaction ID Parameter
+ Thông số này được sử dụng trong phương thức tính cước 2 giai đoạn. Nó được sử dụng để quản lý các phiên giao dịch trong hệ thống CCG. Trường thông tin này là bắt buộc.
+ Format: Integer
+ Used in: Reserve, Charge and Rollback commands + Field type: Mandatory
Result Code Parameter
+ Thông số này dùng để mô tả kết quả của yêu cầu nhận được từ hệ thống CCG.
Thông số này có nhiều giá trị tương ứng với các kết quả như (thành công, lỗi vì nguyên nhân gì,…).
+ Format: string
+ Used in: Reserve Response, Charge response and Rollback Response commands
+ Field type: Mandatory Cú pháp của câu lệnh XML:
Reserve Request XML
<SVRequest>
<RequestType>0</CommandType>
<SubscriberNumber>{subscriber’s CLI}</SubscriberNumber>
<ContentId>{ContentId}</ContentId>
<SubContentId>{SubContentId}</SubContentId>
</SVRequest>
Reserve Response XML
<SVRequest_Response>
<SVRequestResult>{0 on success, otherwise error code}</SVRequestResult>
<TransactionId>{The script SLPI}</TransactionId>
</SVRequest_Response>
Charge Request XML
<SVRequest>
<RequestType>1</CommandType>
<SubscriberNumber>{subscriber’s CLI}</SubscriberNumber>
<ContentId>{ContentId}</ContentId>
<SubContentId>{SubContentId}</SubContentId>
</SVRequest>
Charge Response XML
<SVRequest_Response>
<SVRequestResult>{0 on success, otherwise error code}</SVRequestResult>
</SVRequest_Response>
Rollback Request XML:
<SVRequest>
<RequestType>2</CommandType>
<SubscriberNumber>{subscriber’s CLI}</SubscriberNumber>
<ContentId>{ContentId}</ContentId>
Rollback Response XML
<SVRequest_Response>
<SVRequestResult>{0 on success, otherwise error code}</SVRequestResult>
</SVRequest_Response>
4.9. Các thông số báo hi u CAMEL phase 2 cho hệ ốệ th ng 4.9.1. Xác định các thông s cho b n tin ố ả MTP
1. SCP point code
2. SSP CCG- Point Code
3. Signaling Links (connected to CCG platform) parameters:
Thông số Giải thích
E1 # Cấu hình dựa trên trung kế Nằm trong dải từ. 1
đến 4 cho TX 4000 boards và từ 1 đến 8 cho TX 4000C boards.
Time Slot # Timeslot trên trung kế E1. Có gí trị từ 1 đến 31.
Không cấu hình cổngSS7 trên E1 timeslot 0.
ADJACENT_DPC Mã điểm báo hiệu phía đầu cuối của link SS7.
SSF/SUB_SERVICE Giá trị sử dụng trong trường subservice (SSF) của mo hìnhSIO.
Hoặc sử dụng SUB_SERVICE hoặc thông số
LINK_SLC SSF.Link selection code
4.9.2. Xác định các thông s cho b n tin ố ả SCCP
Thông số Giải thích Giá trị mặc định
Protocol ANSI or ITU ITU
Class & error handling
(lớp và giải quyết lỗi)
UDT first byte Class 1
(connectionless).
Trả về gói tin khi Called Party Address Địa chỉ để điều khiển chuyển lỗi.
mạch Route=GT; PC=N;
SSN=Y Calling Party
Address Địa chỉ SCP trong các yêu
cầu chuyển mạch Route=GT; PC=N;
SSN=Y
SSN (SCP) SCP Sub System Number 146
4.9.3. Các tác nghiệp CAMEL phase 2 cho hệ thống
Operation Name Timer / Value Class
ActivityTest Tat 2s 1
Cancel Tcan 2s 1
Connect Tcon 2s 1
Continue Tcue 2s 1
FurnishChargingInformation Tfci 2s 1
ReleaseCall Trc 2s 1
RequestReportBCSMEvent Trrb 2s 1
ResetTimer Trt 2s 1
Apply
Charging 2s 1
EventReportBCSM Terb 2s 1
InitialDP Tidp 4s 1
Apply Charging Report 2s 1
XXX RX by SCP– XXX TX by SCP– Note:
Class 1 – Cả thành công và thất bại được báo cáo. Class 2 – Chỉ có thất bại được báo cáo.
Class 3 – Chỉ có thành công được báo cáo.
Class 4 – Cả thành công và thất bại đều không được báo cáo. 1. InitialDP
Các thông số:
• serviceKey: Dùng để yêu cầu IN service
• calledPartyNumber: dùng để xác định nhóm bị gọi trong hướng chuyển tiếp cuộc gọi, thông số này được dùng trong các trường hợp Mobile Terminating và Mobile Forwarding.
• callingPartyNumber: dùng để xác định nhóm chủ gọi.
• callingPartysCategory: chỉ ra loại nhóm chủ gọi (như thuê thông thường, pay phone,…)
• originalCalledPartyID: mang dialed digits khi cuộc gọi chuyển tiếp định tuyến đến gsmSSF.
• locationNumber: mang địa chỉ vùng địa lý của các dịch vụ di động.
• bearerCapability: chỉ ra loại kết nối bearer capability tới người dùng.
• bearerCap: chứa giá trị cuả thông số ISUP User Service Information, chỉ dùng trong tác nghiệp InitialDP trong ISUP User Service Information.
• eventTypeBCSM: chỉ ra sự kiện được trang bị BCSM DP, có kết quả trong tác nghiệp Initial DP.
• redirectingPartyID: chỉ ra số chỉ mục mà cuộc gọi trực tiếp kết nối đến lần tiếp tới.
• redirectionInformation
• iPSSPCapabilities: chỉ ra tài nguyên gsmSRF được hỗ trợ trong VMSC/GMSC
• additionalCallingPartyNumber: số nhóm chủ gọi được cung cấp bởi hệ thống báo hiệu truy nhập của người dùng chủ gọi.
• highlayerCompatibility: tính năng nâng cao dùng để xác định ISDNteleservice của đầu cuối ISDN được kết nối.
• iMSI: IMSI của thuê bao di động cho dịch vụ CAMEL được yêu cầu, việc mã hóa chi tiết có thể xem ở GSM 09.02 [14].
• subscriberState: trạng thái của thuê bao với dịch vụ CAMEL được yêu cầu (ví dụ Busy, Idle, Not reachable và không được cung cấp từ HLR).
• locationInformation: chỉ ra nơi MS định vị.
• ext-BasicServiceCode.
• callReferenceNumber: Số tham chiếu mạng gắn với cuộc gọi.
• mscAddress: mscId gắn với GMSC/MSC.
• calledPartyBCDNumber: chứa số để xác định nhóm bị gọi trong hướng chuyển tiếp cuộc gọi, bao gồm thông tin lựa chọn dịch vụ và số digits. Thông số này được gửi chỉ trong trường hợp MO.
• time&Timezone: thông số này chứa thời gian mà gsmSSF được kích hoạt, và time zone (thời gian cục bộ) mà gsmSSF gửi yêu cầu đang cư trú.
• gsm-ForwardingPending: thông số này chỉ ra forwarded-to-number được nhận và cuộc gọi sẽ được chuyển tiếp thay vì chuyển tiếp cuộc gọi dịch vụ gia tăng GSM trong GMSC.
• naCarrierInformation: thông số này chứa mã chỉ thị mang và loại lựa chọn truyền dẫn với thuê bao chủ gọi của một cuộc gọi khởi phát di động, số của thuê bao bị gọi và một cuộc gọi kết cuối di động hoặc thuê bao chuyển tiếp của cuộc gọi chuyển tiếp di động.
• gmscAddress: thông số này đưa ra mscId gắn với GMSC.
Cú pháp:
InitialDP ::= OPERATION ARGUMENT
InitialDPArg ERRORS {
MissingCustomerRecord, MissingParameter,
SystemFailure, TaskRefused,
UnexpectedComponentSequence,
UnexpectedDataValue, UnexpectedParameter }
-- Direction: gsmSSF -> gsmSCF, Timer: Tidp
-- Tác nghiệp này được sử dụng sau một TDP để chỉ ra yêu cầu chỉ ra yêu cầu cho dịch vụ.
Ánh xạ giữa bản tin ISUP và bản tin CAP cho tác nghiệp InitialDP:
2. Tác nghiệp Continue
Thông số này được sử dụng để yêu cầu gsmSSF để bắt đầu xử lý cuộc gọi tại DP mà cuộc gọi đang bị treo để chờ chỉ dẫn gsmSCF. gsmSSF sẽ tiếp tục xử lý cuộc gọi mà không có sự thay thế dữ liệu mới từ gsmSCF.
Thông số: None.
Cú pháp:
Continue ::= OPERATION
-- Direction: gsmSCF -> gsmSSF, Timer: Tcue 3. Tác nghiệp RequestReportBCSMEvent (RRB)
Tác nghiệp này được sử dụng để yêu cầu gsmSSF giám sát cho một sự kiện cuộc gọi liên quan (ví dụ các sự kiện BCSM như bận, không trả lời) sau đó gửi một thông báo ngược về cho gsmSCF khi sự kiện được dò thấy.
This operation is used to request the gsmSSF to monitor for a call related event (e.g., - BCSM events such as busy or no
answer), then send a notification back to the gsmSCF when the event is detected.
Các thông số:
• monitorMode: nếu “monitorMode” là “interrupted” thì sự kiện được báo cáo như một yêu cầu, nếu "monitorMode" là "notifyAndContinue" thì sự kiện được báo cáo như một thông báo, nếu "monitorMode" là "transparent" thì sự kiện sẽ không được báo cáo.
• legID: thông số này chỉ ra nhóm trong cuộc gọi cho sự kiện sẽ được báo cáo.
Chỉ có gsmSCF sử dụng lựa chọn “sendingSideID”.
+ sendingSideID: Nếu không có thông số này thì các giá trị mặc định sau dùng cho LegID:
"legID" = 1 cho các sự kiện O-Abandon và T-Abandon,
"legID" = 2 cho các sự kiện RouteSelectFailure, O-Busy, O-NoAnswer, O- Answer, , T-Busy, T-NoAnswer, T-Answer. và
Thông số "legID" parameter sẽ luôn luôn chứa các sự O-Disconnect và T- Disconnect.
• dPSpecificCriteria: thông số này chỉ ra DP được trang bị.
• applicationTimer: thông số này chỉ ra giá trị thời gian NoAnswer cho sự kiện NoAnswer.
Cú pháp:
RequestReportBCSMEvent ::= OPERATION ARGUMENT
RequestReportBCSMEventArg ERRORS {
MissingParameter, SystemFailure, TaskRefused,
UnexpectedComponentSequence, UnexpectedDataValue,
UnexpectedParameter, UnknownLegID }
-- Direction: gsmSCF -> gsmSSF, Timer: Trrb 4. Tác nghiệp EventReportBCSM (ERB)
Tác nghiệp này để thông báo gsmSCF của một sự kiện cuộc gọi liên quan bởi yêu cầu trước đó từ gsmSCF trong một ERB Operation. Sự giám sát nhiều hơn một sự kiện có thể được yêu cầu trong tác nghiệp RequestReportBCSMEvent nhưng mỗi yêu cầu của những sự kiện này được báo cáo trong một EventReportBCSM riêng biệt.
Các thông số:
• eventTypeBCSM: thông số này chỉ ra loại của sự kiện được báo cáo.
• eventSpecificInformationBCSM: thông số này chỉ ra thông tin liên quan của cuộc gọi đặc trưng cho sự kiện.
+ Với RouteSelectFailure nó sẽ chứa "FailureCause", nếu sẵn sàng.
+ Với O Busy nó sẽ chứa "BusyCause", nếu sẵn sàng.- + Với T Busy nó sẽ chứa "BusyCause", nếu sẵn sàng.- + Với O-NoAnswer nó sẽ để trống (empty).
+ Với T NoAnswer nó sẽ chứa chỉ dẫn CallForwarded.- + Với O- hoặc T-Answer nó sẽ để trống (empty).
+ Với O- hoặc T-Disconnect nó sẽ chứa "releaseCause", nếu sẵn sàng.
• legID: thông số này chỉ ra nhóm trong cuộc gọi cho sự kiện được báo cáo.
gsmSSF sẽ chỉ sử dụng tùy chọn "receivingSideID".
+ receivingSideID: Nếu không có, các lựa chọn mặc định sau được sử dụng:
"legID" = 1 cho các sự kiện O-Abandon và T-Abandon,
"legID" = 2 cho các sự kiện RouteSelectFailure, O-Busy, O-NoAnswer, O- Answer, T-Busy, T-NoAnswer, và T-Answer.
Thông số "legID" sẽ luôn luôn được đưa vào cho các sự kiện O-Disconnect và T-Disconnect.
• miscCallInfo: thông số này chỉ ra thông tin DP liên quan.
• messageType: thông số này chỉ ra liệu bản tin có phải là một yêu cầu hay không, ví dụ kết quả từ một RequestReportBCSMEvent với "monitorMode" =
"interrupted", hoặc một thông báo nếu RequestReportBCSMEvent
"monitorMode" = “notifyAndContinue”.
Cú pháp:
EventReportBCSM ::= OPERATION ARGUMENT
EventReportBCSMArg
-- Direction: gsmSSF -> gsmSCF, Timer: Terb 5. Tác nghiệp ReleaseCall
Tác nghiệp này được sử dụng bởi gsmSCF để đưa vào một cuộc gọi đã tồn tại tại bất kỳ phase nào của cuộc gọi cho tất cả các nhóm được yêu cầu trong cuộc gọi. Tác nghiệp này có thể chỉ được gửi trong một quan hệ điều khiển và nó không được phép
• Cause: một số đưa ra một chỉ dẫn tới gsnSSF về lý do giải phóng của cuộc gọi đặc biệt này. Điều này có thể được sử dụng bởi gsmSSF cho các âm đặc trưng phát ra tới các nhóm khác nhau trong cuộc gọi hoặc đưa vào “cause” trong bản tin giải phóng.
Cú pháp:
ReleaseCall ::= OPERATION ARGUMENT
ReleaseCallArg
-- Direction: gsmSCF -> gsmSSF, Timer: Trc
4.10. Một số ết quả khi đem hệ ố k th ng vào hoạt động
1. Giao diện quản lý các server của hệ thống (System manager)
Đây là giao diện đồ họa dùng để quản lý tất cả các dịch vụ của hệ thống CCG, có các chức năng sau:
+ Thi hành các thao tác: Start, stop và restat các dịch vụ như SMPP, DCG, SS7,…
+ Thiết lập các log levels (như all, warning,…) để giám sát thời gian thực cho các dịch vụ.
+ Thống kê dung lượng của hệ thống trong các khoảng thời gian đưa ra.
+ Định nghĩa các thực thể mới của mạng như SMPP clients, SMPP Server, SCP,…
2. Giao diện quản lý dịch vụ (Service manager)
Đây là GUI Dùng để quản lý tất cả các bảng trong DBSC để định nghĩa cho nhiều dịch vụ.
Đây là GUI dùng để:
+ Định nghĩa các CP mới (shord code, CP name, Dialed digits for charging method,…).
+ Định nghĩa các ứng dụng 3rd party mới.
+ Quản lý các thuê bao postpaid (như add new, delete,…)
+ Quản lý các GT tương ứng với các hệ thống trả trước và các dải MSISDN của thuê bao tương ứng,…
3. Giao diện để định nghĩa logic cho các dịch vụ (thi hành theo Scenarios)
Giao diện này dùng để sáng tạo các dịch vụ, định nghĩa sự thi hành logic các dịch vụ theo các scenarios
Ngoài ra còn có các giao diện khác như giao diện quản lý người dùng, phân quyền thao tác và truy cập hệ thống cho các người dùng khác nhau, giao diện quản lý kết nối đối với các SMSC, giao diện quản lý các tài nguyên.
4.11 . Đánh giá
Với sự phát triển của công nghệ thông tin và mạng viễn thông, việc xây dựng một hệ thống ngoài thông minh để tính cước các dịch vụ gia tăng cho mạng là hoàn toàn có thể thực hiện được. Hiện nay ở Việt Nam đã có 3 mạng GSM đang hoạt động là Vinaphone, MobiFone và Viettel, ngoài ra còn có một mạng GSM khác đang trong quá trình thành lập là Gtell; các mạng GSM này đang phát triển lên các mạng 3G.
Việc đầu tư để đưa vào việc sử dụng CAMEL phase 3 cho mạng đang có nhiều khó khăn, do phải thay đổi về giao thức báo hiệu mạng core, thay đổi chương trình xử lý ở các node mạng như gsmSSF, gsmSCF, … và thay đổi giao thức quản lý ở phía đầu cuối hệ thống Prepaid IN. Do đó việc đưa hệ thống CAMEL phase 3 vào hoạt động để tối ưu cho mạng thông minh là việc làm không phải một sớm một chiều. iệc phát V triển hệ thống CCG tính cước online cho các dịch vụ gia tăng của mạng dựa trên giao thức CAMEL phase 2 là cần thiết.