SMPP là một giao thức ở tầng ứng dụng và không có chức năng truyền dữ liệu. Do đó, kết nối mạng cơ bản được mặc định sẽ truyền dữ liệu từ điểm tới điểm một cách thành công, bao gồm việc mã hoá gói tin, kiểm soát luồng dữ liệu và xử lý lỗi. Do đó, tại mức SMPP, ESME và SMSC phải dựa vào kết nối mạng có thể tin cậy được, để vận chuyển, truyền và nhận các gói tin PDUs [12].
Hình 1.8: Mô hình SMPP giao diện SMSC – ESME [12].
Nếu được yêu cầu, lớp mạng ở thực thể gửi được mặc định là có thể quản lý việc phân mảnh các bản tin PDU để truyền dẫn. Tương tự, lớp mạng ở thực thể nhận sẽ
ghép các phân mảnh thành một bản tin PDU trước khi chuyển toàn bộ bản tin SMPP PDU tới lớp SMPP [12].
1.3.2.4. Các bản tin SMPP đƣợc gửi từ ESME tới SMSC [12]
Một ESME gửi tin nhắn tới SMSC phải được kết nối với SMSC như một ESME Transmitter hoặc ESME Transceiver.
Ví dụ về các bản tin SMPP có thể được gửi từ ESME transmitter tới SMSC như sau: submit_sm
data_sm
Ngoài việc gửi các bản tin gửi tới SMSC, ESME có thể thực hiện các thao tác SMPP sau đây để nhận thông báo phản hồi của SMSC về việc đã nhận được tin nhắn:
query_sm – truy vấn SMSC cho trạng thái của tin nhắn đã gửi trước.
cancel_sm – huỷ việc gửi tin đã nhắn.
replace_sm – thay thế các tin nhắn đã gửi trước đó.
Bản tin PDU của SMPP đã gửi tới SMSC từ ESME phải được SMSC xác nhận là đã nhận được, bằng một bản tin PDU.
a) Bản tin phản hồi từ SMSC tới ESME
Bản tin SMPP xác nhận SMSC đã nhận được gói tin nhắn phải bao gồm một nhận dạng tin nhắn (đây là định dạng duy nhất cho mỗi bản tin) và một trạng thái cảnh báo ESME là tin nhắn gửi đi là hợp lệ hay không hợp lệ. Trong trường hợp thứ hai, SMSC sẽ trả về trạng thái lỗi tương ứng.
submit_sm_resp
data_sm_resp
query_sm_resp
cancel_sm_resp
b) Trình tự giao dịch SMPP của ESME Transmitter
Hình 1.9: Trình tự giao dịch SMPP của ESME Transmitter [12].
Việc trao đổi các gói tin yêu cầu và phản hồi giữa SMSC và ESME Transmitter có thể xảy ra một cách đồng bộ hoặc không đồng bộ. Vì vậy, một ESME có thể gửi nhiều yêu cầu tới SMSC mà không phải đợi để nhận các gói tin phản hồi tương ứng.
Ngay sau khi ESME gửi một loạt các yêu cầu SPMPP liên tiếp một cách không đồng bộ, một chuỗi các phản hồi tương ứng sẽ được gửi đi từ SMSC.
Các phản hồi được trả về từ SMSC phải cùng thứ tự với các yêu cầu gửi từ ESME. Tuy nhiên, điều này là không bắt buộc trong giao thức SMPP và ESME phải có khả năng quản lý các phản hồi không theo thứ tự.
ESME phải gửi các phản hồi cho SMSC theo cùng thứ tự với các yêu cầu. Gói tin PDU duy nhất phù hợp khi một ESME Transmitter trả về trong một phiên gửi là gói tin enquire_link_resp.
Lƣu ý: Số lượng tối đa của các thao tác SMPP chưa xử lý xong giữa ESME và
SMSC (và ngược lại) không được quy định rõ trong bản mô tả giao thức SMPP và bị chi phối bởi cách thực hiện SMPP trong SMSC. Tuy nhiên, số lượng chưa giải quyết xong tại bất kì thời điểm nào được khuyến cáo là tối đa 10 bản tin [12].
1.3.2.5. Các tin nhắn SMPP gửi từ SMSC tới ESME [12]
SMSC có thể gửi tin đến ESME. Trong trường hợp này, ESME phải được kết nối với SMSC như một ESME Receiver hay ESME Transceiver.
Các ứng dụng điển hình cho phép ESME hoạt động như một SMPP Receiver là: Một cổng giao tiếp email, nhận tin nhắn từ trạm phát sóng di động và chuyển
nó tới một hòm thư điện tử trên mạng internet.
SMSC cũng có thể gửi tin “đã gửi” tới ESME trong đó chứa trạng thái chuyển tin của tin nhắn trước đó.
Ví dụ của bản tin SMPP mà được gửi từ SMSC tới ESME Receiver như sau: deliver_sm
data_sm
Các gói tin PDUs được gửi từ SMSC tới ESME phải được ESME phản hồi là đã nhận được bằng một gói tin PDU, trừ trường hợp của bản tin alert_notification.
a) Các bản tin SMPP phản hồi từ ESME tới SMSC
(được lưu trong tham số sequence_number) được gửi bởi SMSC. Bản tin này cũng phải bao gồm cả trạng thái câu lệnh mà thông báo cho SMSC về trạng thái tin nhắn gửi tới ESME là hợp lệ hay không hợp lệ. Trong trường hợp thứ hai, ESME phải trả về trạng thái lỗi tương ứng.
Ví dụ của bản tin phản hồi được gửi từ ESME Receiver tới SMSC như sau: deliver_sm_resp
data_sm_resp
b) Trình tự giao dịch SMPP của ESME Receiver
Hình 1.10: Trình tự giao dịch SMPP của ESME Receiver [12].
Việc trao đổi các bản tin yêu cầu và phản hồi giữa SMSC và ESME Receiver có thể được tiến hành đồng thời hoặc không đồng thời. Vì vậy, SMSC có thể gửi nhiều bản tin yêu cầu deliver_sm tới ESME mà không phải đợi để nhận các bản tin phản hồi tương ứng.
Một loạt các yêu cầu liên tiếp một cách không đồng bộ của SMSC phải được nối tiếp bởi một chuỗi các phản hồi tương ứng từ ESME.
ESME phải luôn gửi lại các bản tin phản hồi cho SMSC theo cùng một thứ tự với các bản tin yêu cầu đã nhận. Tuy nhiên, việc này là không bắt buộc trong giao thức SMPP và SMSC phải có khả năng quản lý các phản hồi gửi về không đúng thứ tự.
SMSC phải luôn trả về các bản tin phản hồi tới ESME theo đúng thứ tự của các bản tin yêu cầu ban đầu. Tuy nhiên, điều này là không bắt buộc trong giao thức SMPP và ESME phải có khả năng quản lý các phản hồi gửi về không đúng thứ tự.
Lƣu ý: Số lượng tối đa của các thao tác chưa được xử lý giữa ESME và
SMSC (và ngược lại) không được quy định rõ trong bản mô tả giao thức SMPP và bị chi phối bởi cách thực hiện SMPP trong SMSC. Tuy nhiên, số lượng chưa giải quyết xong tại bất kì thời điểm nào được khuyến cáo là tối đa 10 bản tin [12].
1.3.2.6. Quản lý lỗi trong SMPP
Mọi giao dịch trong giao thức SMPP đều bao gồm một PDU yêu cầu và PDU phản hồi tương ứng, trừ trường hợp của bản tin alert_notification (không có phản hồi). Trong tất cả các trường hợp khác, thực thể nhận bản tin phải gửi lại bản tin phản hồi tương ứng,và thông báo rằng đã được nhận tin. Cho tới khi bản tin phản hồi đến được với đối tượng gửi tin, thì bản tin PDU mới được coi là gửi đến đích an toàn [12].
Trong trường hợp bản tin yêu cầu có lỗi, thực thể nhận bản tin phải gửi phản hồi kèm mã lỗi tương ứng trong trường command_status ở tiêu đề của bản tin PDU trả về.
Nếu thực thể nhận tin phát hiện lỗi trong tiêu đề của bản tin PDU, thực thể này sẽ gửi một bản tin generic_nak cho đối tượng gửi tin [12].
1.4. Các công trình nghiên cứu ứng dụng nhắn tin
Qua quá trình nghiên cứu, tác giả đã tìm hiểu các sản phẩm dịch vụ nhắn tin trong và ngoài nước. Rất nhiều doanh nghiệp đã nghiên cứu và phát triển các sản phẩm liên quan đến dịch vụ tin nhắn. Việt Nam có các sản phẩm phần mềm nhắn tin như sau:
iNet Smart SMS do các doanh nghiệp Công ty cổ phần INET[4]. VCTel SMSMedia do Công ty cổ phần VCTel phát triển[14].
SiTek SMS Công ty cổ phần Công nghệ Sài Gòn Sitek phát triển [11].
Trên thế giới, chúng ta có các sản phẩm như BulkSMS Text Messeger (sản phẩm của công ty Celerity Systems (Pty) Ltd.), Ozeki NG-SMS Gateway [2].
Các giải pháp cho các phần mềm ứng dụng trên có ưu điểm và nhược điểm sau: Ưu điểm:
Các phần mềm trong và ngoài nước đều có thể cho phép các doanh nghiệp có giải pháp nhắn tin quảng cáo thông tin các sản phẩm dịch vụ của doanh nghiệp của mình.
Nhược điểm
- Đối với các phần mềm trong nước, các phần mềm chủ yếu áp dụng cho các doanh nghiệp vừa và nhỏ, việc triển khai đến các hệ thốngứng dụng lớn như ngân hàng, các nhà mạng viễn thông là hoàn toàn gặp khó khăn khi phải xử lý thông tin lớn, thông thường là tốc độ rất chậm và không đáp ứng được.
- Đối với các giải pháp phần mềm nước ngoài: Có thể áp dụng với doanh nghiệp lớn, tuy nhiên việc chi phí triển khai và tính bảo mật thông tin là không đảm bảo.
1.5. Mục tiêu của luận văn.
Trên đây, tác giả đã tóm tắt các công nghệ viễn thông như mạng di động GSM, các thế hệ mạng di động từ 1G đến 4G, khái niệm SMS-Gateway và giao
thức SMPP. Tác giả cũng liệt kê một số sản phẩm ứng dụng tin nhắn phổ biến trên thị trường, phân tích ưu điểm và nhược điểm của các ứng dụng này. Qua các kiến thức đã tìm hiểu được, trong các chương tiếp theo, tác giả sẽ phải thực hiện những nhiệm vụ chính sau:
1) Tìm hiểu kho dữ liệu viễn thông hiện có của doanh nghiệp Mobifone KV1. 2) Xây dựng gói ứng dụng xử lý dữ liệu, kết nối tổng đài SMSC và thực hiện
nhắn tin CSKH dựa trên các hàm OpenSMPP API (gói thư viện Java mã nguồn mở cài đặt giao thức SMPP).
CHƢƠNG 2: TỔNG QUAN VỀ DỮ LIỆU KHÁCH HÀNG TẠI CÔNG TY DỊCH VỤ MOBIFONE KHU VỰC 1
Hiện nay, Công ty Dịch vụ viễn thông Mobifone Khu vực 1 quản lý hơn 30 triệu thuê bao khách hàng. Với số lượng thuê bao rất lớn, Công ty cần phải có một qui trình quản lý dữ liệu hết sức chặt chẽ, những chính sách chăm sóc khách hàng đặc biệt. Với sự phát triển và cạnh tranh rất khốc liệt trong thị trường viễn thông, tài sản giá trị nhất của doanh nghiệp là dữ liệu khách hàng sẽ mang đến thành công cho các doanh nghiệp khi họ biết khai thác và phân tích.
Trong Chương 2, tác giả sẽ tóm tắt qui trình quản lý dữ liệu, chăm sóc khách hàng tại Công ty Dịch vụ khu vực 1. Việc quản lý dữ liệu khách hàng (thuê bao trả trước, thuê bao trả sau) bao gồm việc quản lý dữ liệu khách hàng trên hệ thống Tính cước và quản lý khách hàng tập trung (TC&QLKH), hệ thống Quản lý đăng ký thông tin thuê bao trả trước 1414 (Hệ thống 1414) và quản lý hồ sơ khách hàng (trên máy tính và trên giấy tờ).
2.1. ịnh nghĩa Dữ liệu khách hàng
Là những thông tin về khách hàng và việc sử dụng dịch vụ của khách hàng do chính khách hàng cung cấp được ghi trong "Hợp đồng cung cấp và sử dụng dịch vụ điện thoại di động" (đối với thuê bao trả tiền sau – MobiGold) và trong “Bản khai thông tin thuê bao di động trả trước”, Phiếu cung cấp và thay đổi dịch vụ điện thoại di động trả trước (đối với thuê bao trả tiền trước). Dữ liệu khách hàng bao gồm cả thông tin mà khách hàng yêu cầu trong quá trình sử dụng dịch vụ như: Đăng ký, hủy dịch vụ,…Dữ liệu khách hàng được lưu giữ trong hệ thống TC&QLKH tập trung [13].
Ngoài hệ thống TC&QLKH lưu trữ dữ liệu khách hàng, hiện còn có các hệ thống khác như hệ thống lưu lượng, hệ thống dữ liệu vị trí thuê bao, hệ thống Doanh thu thông tin,...Tác giả sẽ trình bày tổng quan về các hệ thống hiện có tại Công ty.
Hình 2.1: Sơ đồ kiến trúc tổng thể của hệ thống cơ sở dữ liệu
Hình 2.1 mô tả cơ sở dữ liệu được thiết kế và phát triển trên hệ quản trị CSDL Oracle11g lưu các thông tin kinh doanh của Công ty được tổng hợp từ các nguồn như: Hệ thống TC&QLKH, Bán hàng tập trung, DMS, Điểm bán lẻ 1414, VLR, Lưu lượng, dump IN, CDR,…
STT Hệ thống Dữ liệu thu thập 1 TC&QLKH (Hệ thống tính cước và quản lý khách hàng tập trung)
-Dữ liệu thuê bao trả sau, trả trước. -Dữ liệu phát triển thuê bao.
-Dữ liệu biến động thuê bao trả sau, trả trước (chặn một chiều, hai chiều, rời mạng)
-Dữ liệu tác động vào thuê bao. -Dữ liệu địa bàn.
STT Hệ thống Dữ liệu thu thập
-Dữ liệu đơn vị điểm giao dịch (cửa hàng VMS, đại lý chuyên Mobifone)
2 BHTT (Hệ thống quản lý bán hàng tập trung)
-Danh sách các đơn vị bán hàng (Chi nhánh, cửa hàng, đại lý ủy quyền)
-Dữ liệu doanh thu bán hàng: thẻ, MobiEz, AirTime, bộ kit, …
-Thông tin kho hàng, giao dịch.
3 DMS (Hệ thống báo cáo phát triển thuê)
-Số liệu thuê bao trả trước phát triển mới toàn Công ty.
-Số liệu thuê bao trả sau phát triển mới toàn Công ty.
-Số liệu thuê bao thực trả trước toàn Công ty. -Số liệu thuê bao thực trả sau toàn Công ty. -Các số liệu như trên của các Công ty khác.
4
Điểm bán lẻ 1414 (Hệ thống quản lý điểm bán lẻ kích hoạt và đăng ký thông tin thuê bao trả
trước)
-Danh sách chi tiết ĐBL: Tên, mã, địa chỉ, trạng thái.
-Danh sách số EZ của ĐBL: Số ISDN, mã ĐBL, trạng thái.
-Số liệu kích hoạt thuê bao trả trước qua hệ thống nhắn tin 1414 từ các điểm bán lẻ.
5
VLR
(Hệ thống quản lý dữ liệu thuê bao trên VLR)
-Dữ liệu tổng hợp & chi tiết thuê bao cập nhật VLR trên Cell theo kỳ.
-Dữ liệu tổng hợp thuê bao cập nhật VLR theo LAC theo ngày.
6
CDR Dump (Hệ thống quản lý CDR
file tập trung)
-Dữ liệu thuê bao phát sinh cước.
-Tổng hợp dữ liệu thuê bao trả sau, trả trước phát sinh cước theo địa bàn chi nhánh, tổ kinh doanh.
STT Hệ thống Dữ liệu thu thập
-Xác định vị trí thuê bao.
7
Lưu lượng (Hệ thống quản lý số liệu lưu lượng của Trung tâm)
-Dữ liệu lưu lượng chi tiết 2G/3G hàng ngày của các quận huyện, tổ kinh doanh, chi nhánh thuộc Công ty.
-Danh sách Cell. -Dữ liệu trạm 2G/3G. 8 IN Dump (Hệ thống quản lý IN dump file)
-Dữ liệu thuê bao trả trước trên IN/ICC gồm: trạng thái thuê bao, ngày DEACT, INACT, DELETE, các loại tài khoản.
-Dữ liệu nạp thẻ của thuê bao: thẻ vật lý, MobiEz.
9 Hệ thống tính Doanh thu tiêu dùng
-Dữ liệu doanh thu tiêu dùng trả trước tới từng thuê bao.
-Dữ liệu doanh thu tiêu dùng trả sau tới từng thuê bao.
-Dữ liệu doanh thu tiêu dùng tới địa bàn.
10 Hệ thống báo cáo DSS
-Danh sách thuê bao phát sinh cước theo địa bàn quận huyện, phường xã.
-Danh sách thuê bao rời mạng theo địa bàn quận huyện, phường xã.
2.2. Hệ thống tính cƣớc và quản lý khách hàng tập trung
Đây là hệ thống lưu trữ cơ sở dữ liệu liệu thông tin khách hàng là các thuê bao trả sau của Công ty 1 quản lý, dữ liệu bao gồm:
Dữ liệu lịch sử tác động thay đổi thông tin của các thuê bao trả sau.
Dữ liệu danh mục các lý do các tác động thay đổi thông tin thuê bao trả sau. Dữ liệu đăng ký sử dụng các dịch vụ của thuê bao trả sau và thông tin các loại
dịch vụ.
Cước phát sinh của khách hàng.
Lịch sử thanh toán cước của khách hàng. Tình trạng nợ cước của khách hàng.
Thông tin các đơn vị thu cước và nhân viên thu cước.
Thông tin tình hình nộp tiền thu cước về Trung tâm của các đơn vị thu cước. Dữ liệu các thông tin khuyến mại.
Thông tin các chương trình khuyến mại.
Thông tin thuê bao tham gia các chương trình khuyến mại. Số tiền đã thực hiện khuyến mại cho các thuê bao.
Dữ liệu gói cước cho thuê bao trả sau Thông tin các loại gói cước.
Danh sách các thuê bao sử dụng gói cước. Dữ liệu doanh thu của các gói cước.
Dữ liệu thông tin địa bàn do công ty quản lý.
Dữ liệu thông tin các đơn vị kinh doanh như cửa hàng VMS, đại lý chuyên Mobifone, đại lý ủy quyền…
Dữ liệu thông tin khách hàng là các thuê bao trả trước của công ty quản lý.