tìm hiểu giao thức smpp

SMPP hỗ trợ: − Truyền tin từ một ESME tới một hoặc nhiều đích bằng SMSC; − Một ESME cũng có thể nhận tin bằng SMSC từ các SME khác ví dụ: các mobile station; − Truy vấn trạng thái của mộ

Trang 1

TRƯỜNG ĐẠI HỌC BÁCH KHOA HÀ NỘI

KHOA CÔNG NGHỆ THÔNG TIN

*

****

*

BÁO CÁO THỰC TẬP

Đề tài: Tìm hiểu giao thức SMPP

Thầy hướng dẫn: Đặng Văn ChuyếtSinh viên: Nguyễn Ngọc BảoLớp: KS2 K16

Hà Nội - 2004

Trang 2

MỤC LỤC

CÁC TỪ VIẾT TẮT 7

PHẦN I TỔNG QUAN VỀ SMPP 8

1.1 Định nghĩa giao thức SMPP 9

1.2 Mô tả SMPP Session 9

1.2.1 Lệnh Outbind 10

1.3 Các PDU trong SMPP 11

1.4 Kết kết nối tại tầng mạng của SMPP 12

1.5 Các tin được gửi từ ESME tới SMSC 13

1.5.1 Các tin được phản hồi từ SMSC về ESME 13

1.5.2 Sơ đồ tuần tự của SMPP session - ESME Transmitter 13

1.6 Các tin được gửi từ SMSC tới ESME 14

1.6.1 Tin phản hồi từ ESME về SMSC 14

1.6.2 Sơ đồ tuần tự của SMPP session - ESME Receiver 14

1.7 Trao đổi tin kép giữa SMSC và ESME 15

1.7.1 Typical SMPP session sequence - ESME Transceiver 15

1.8 Bắt lỗi 16

1.9 SMPP Timer 16

1.10 Các chế độ của tin 17

1.10.1 Chế độ Store and Forward 17

1.10.2 Chế độ Datagram 18

1.10.3 Chế độ Transaction 19

1.11 Các loại tin 19

1.11.1 SMSC Delivery Receipt 20

1.11.2 Intermediate Notification 20

1.11.3 SME Delivery Acknowledgement 20

1.11.4 SME Manual/User Acknowledgement 20

1.11.5 Conversation Abort 20

PHẦN II ĐỊNH DẠNG VÀ KIỂU PDU TRONG SMPP 21

2.1 Các định nghĩa về kiểu 21

2.1.1 Kích thước của các trường tham số 21

2.2 Đinh dạng chung của PDU 21

2.2.2 Chiều dài của PDU 22

2.2.3 Kích thước của tin và phần mở rộng của tin 23

Trang 3

2.2.4 Các tham số tùy chọn 23

2.2.4.1 Định dạng tham số tùy chọn 23

2.3 Khả năng tương thích của các phiên bản cũ của giao thức SMPP 23

2.4 Khả năng tương thích của các phiên bản mới của giao thức SMPP 24

PHẦN III CÁC PDU TRONG SMPP 25

3.1 Lệnh “BIND” 25

3.1.1 Cú pháp “BIND_TRANSMITTER” 25

3.1.2 Cú pháp “BIND_TRANSMITTER_RESP” 26

3.1.3 Cú pháp “BIND_RECEIVER” 26

3.1.4 Cú pháp “BIND_RECEIVER_RESP” 27

3.1.5 Cú pháp “BIND_TRANSCEIVER” 28

3.1.6 Cú pháp “BIND_TRANSCEIVER_RESP” 28

3.1.7 Lệnh “OUTBIND” 29

3.1.7.1 Cú pháp “OUTBIND” 29

3.2 Lệnh “UNBIND” 29

3.2.1 Cú pháp “UNBIND” 30

3.2.2 Cú pháp “UNBIND_RESP” 30

3.3 PDU của “GENERIC_NACK” 30

3.3.1 Cú pháp “GENERIC_NACK” 30

3.4 Lệnh “SUBMIT_SM” 30

3.4.1 Cú pháp “SUBMIT_SM” 31

3.4.1.1 Địa chỉ chỉ nguồn và đích 33

3.4.1.2 Quá trình thay thế tin trong “SUBMIT_SM” 33

3.4.2 Cú pháp “SUBMIT_SM_RESP” 34

3.5 Lệnh “SUBMIT_MULTI” 34

3.5.1 Cú pháp “SUBMIT_MULTI” 34

3.5.1.1 Định nghĩa địa chỉ đích dest_address 37

3.5.1.2 Định nghĩa danh sách gửi tin 37

3.5.2 Cú pháp “SUBMIT_MULTI_RESP” 37

3.5.2.1 Truyền không thành công 38

3.6 Lệnh “DELIVER_SM” 38

3.6.1 Cú pháp “DELIVER_SM” 38

3.6.2 Cú pháp “DELIVER_SM_RESP” 41

3.7 Lệnh “DATA_SM” 41

3.7.1 Cú pháp “DATA_SM” 42

3.7.2 Cú pháp “DATA_SM_RESP” 44

3.8 Lệnh “QUERY_SM” 45

3.8.1 Cú pháp “QUERY_SM” 45

3.8.2 Cú pháp “QUERY_SM_RESP” 45

Trang 4

3.9 Lệnh “CANCEL_SM” 46

3.9.1 Cú pháp “CANCEL_SM” 46

3.9.2 Cú pháp “CANCEL_SM_RESP” 47

3.10 Lệnh “REPLACE_SM” 47

3.10.1 Cú pháp “REPLACE_SM” 47

3.10.2 Cú pháp “REPLACE_SM_RESP” 48

3.11 Lệnh “ENQUIRE_LINK” 48

3.11.1 Cú pháp “ENQUIRE_LINK” 48

3.11.2 Cú pháp “ENQUIRE_LINK_RESP” 48

3.12 Lệnh “ALERT_NOTIFICATION” 49

3.12.1 Cú pháp “ALERT_NOTIFICATION” 49

PHẦN IV THAM SỐ TRONG SMPP 50

4.1 Các tham số trong Header của lệnh 50

4.1.1 command_length 50

4.1.2 command_id 50

4.1.2.1 Bộ lệnh của SMPP 50

4.1.3 command_status 51

4.1.4 sequence_number 52

4.2 Các tham số bắt buộc của SMPP 53

4.2.1 system_id 53

4.2.2 password 53

4.2.3 system_type 53

4.2.4 interface_version 53

4.2.5 addr_ton, source_addr_ton, dest_addr_ton, esme_addr_ton 53

4.2.6 addr_npi, source_addr_npi, dest_addr_npi, esme_addr_npi 53

4.2.7 address_range 54

4.2.8 source_addr 54

4.2.9 destination_addr 54

4.2.10 esme_addr 54

4.2.11 service_type 54

4.2.12 esm_class 54

4.2.13 protocol_id 55

4.2.14 priority_flag 55

4.2.15 schedule_delivery_time 56

4.2.16 validity_period 56

4.2.17 registered_delivery 56

4.2.18 replace_if_present_flag 56

4.2.19 data_coding 57

4.2.20 sm_default_msg_id 57

4.2.21 sm_length 57

4.2.22 short_message 57

4.2.23 message_id 58

4.2.24 number_of_dests 58

4.2.25 dest_flag 58

Trang 5

4.2.26 no_unsuccess 58

4.2.27 dl_name 58

4.2.28 message_state 58

4.3 Mô tả tham số tùy chọn của SMPP 58

4.3.1 Nhận dạng các Tag của tham số tùy chọn 58

4.3.2 Định nghĩa các Tag của tham số tùy chọn 59

4.3.2.1 dest_addr_subunit 60

4.3.2.2 source_addr_subunit 60

4.3.2.3 dest_network_type 60

4.3.2.4 source_network_type 60

4.3.2.5 dest_bearer_type 61

4.3.2.6 source_bearer_type 61

4.3.2.7 dest_telematics_id 61

4.3.2.8 source_telematics_id 61

4.3.2.9 qos_time_to_live 62

4.3.2.10 payload_type 62

4.3.2.11 additional_status_info_text 62

4.3.2.12 receipted_message_id 62

4.3.2.13 ms_msg_wait_facilities 62

4.3.2.14 privacy_indicator 63

4.3.2.15 source_subaddress 63

4.3.2.16 dest_subaddress 63

4.3.2.17 user_message_reference 64

4.3.2.18 user_response_code 64

4.3.2.19 language_indicator 64

4.3.2.20 source_port 64

4.3.2.21 destination_port 64

4.3.2.22 sar_msg_ref_num 65

4.3.2.23 sar_total_segments 65

4.3.2.24 sar_segment_seqnum 65

4.3.2.25 sc_interface_version 65

4.3.2.26 display_time 65

4.3.2.27 ms_validity 66

4.3.2.28 dpf_result 66

4.3.2.29 set_dpf 66

4.3.2.30 ms_availability_status 66

4.3.2.31 network_error_code 67

4.3.2.32 message_payload 67

4.3.2.33 delivery_failure_reason 67

4.3.2.34 more_messages_to_send 67

4.3.2.35 message_state 68

4.3.2.36 callback_num 68

4.3.2.37 callback_num_pres_ind 68

4.3.2.38 callback_num_atag 69

4.3.2.39 number_of_messages 69

4.3.2.40 sms_signal 69

4.3.2.41 alert_on_message_delivery 69

4.3.2.42 its_reply_type 69

4.3.2.43 its_session_info 70

Trang 6

4.3.2.44 ussd_service_op 70

PHẦN V VẤN ĐỀ MẠNG VÀ CÁC ĐỊNH NGHĨA CHUNG 71

5.1 Các mã lỗi của mạng 71

5.2 Chiều dài tối đa của tin 71

5.1 Định nghĩa về thời gian 71

5.1.1 Định dạng thời gian 71

5.1.1.1 Định dạng thời gian tuyệt đối 71

5.1.1.2 Định dạng thời gian tương đối 71

5.2 Các định về đồng hồ 71

PHỤ LỤC A BIỂU THỨC QUY TẮC TRONG UNIX 73

PHỤ LỤC B ĐỊNH DẠNG TIN BÁO CÁO 74

PHỤ LỤC C XỬ LÝ NĂM 2000 TRONG SMPP 75

PHỤ LỤC D VÍ DỤ VỀ TIN NGẮN CỦA DỊCH VỤ SMS 76

TÀI LIỆU THAM KHẢO 77

Trang 7

CÁC TỪ VIẾT TẮT

API Application Programming Interface

CDR Call Detail Record

ESME External Short Message Entity

ETSI European Telecommunications Standards Institute

HEADER Leading portion of the SMPP message, common to all SMPP PDUs

MB Message Bureau - This is typically an operator message bureau

MSB Most Significant Byte

MSC Mobile Switching Centre

MS Mobile Station

MWI Message Waiting Indication

NACK Negative Acknowledgement

NSAP Network Service Access Point

PDU Protocol Data Unit

PSSD Process Unstructured Supplementary Services Data

PSSR Process Unstructured Supplementary Services Request

SME Short Message Entity

SMSC Short Message Service Centre

SMPP Short Message Peer to Peer Protocol

UDHI User Data Header Indicator

URL Uniform Resource Locator

USSN Unstructured Supplementary Services Notification

USSR Unstructured Supplementary Services Request

VMA VoiceMail Alert

VPS Voice Processing System

TIA Telecommunications Industry Association

WAP Wireless Application Protocol (http://www.wapforum.org)

WCMP Wireless Control Message Protocol

WDP Wireless Datagram Protocol

Trang 8

PHẦN I TỔNG QUAN VỀ SMPP

Giao thức Short Message Pear to Pear (viết tắt là SMPP) là một chuẩn mở, được thiết kế

để cung cấp các cơ chế truyền dữ liệu một cách linh hoạt cho việc truyền tin ngắn giữa một trung tâm nhắn tin (ví dụ: SMSC) và một hệ thống ứng dụng tin ngắn (ví dụ: WAP Proxy Server, Email Gateway, hoặc những gateway dùng để gửi tin nhắn) Trong tài liệu sẽ sử dụng thuật ngữ SMSC để đại diện cho bất kỳ một server SMPP nào mà một SMPP client (External Short Message Entity - ESME) có thể kết nối được Giao thức SMPP hỗ trợ cho các công nghệ mạng Digital Cellular gồm có: GSM, CDMA, IDMA, iDEN

Giao thức SMPP cho phép một ESME có thể khởi tạo kết nối tại tầng ứng dụng với một SMSC qua mạng TCP/IP hoặc X.25 để gửi và nhận tin ngắn với một SMSC đó ESME cũng

có thể sử dụng SMPP để truy vấn, bỏ qua hoặc thay thế các tin ngắn

SMPP hỗ trợ:

− Truyền tin từ một ESME tới một hoặc nhiều đích bằng SMSC;

− Một ESME cũng có thể nhận tin bằng SMSC từ các SME khác (ví dụ: các mobile station);

− Truy vấn trạng thái của một tin ngắn được lưu trong SMSC;

− Bỏ qua hay thay thế một tin ngắn được lưu trong SMSC;

− Gửi các báo báo;

− Lên lịch gửi tin theo ngày tháng;

− Lựa chọn chế độ của tin, ví dụ: đóng gói hoặc lưu trữ và chuyển tiếp;

− Thiết lập mức độ ưu tiên cho tin ngắn;

− Định nghĩa kiểu định dạng dữ liệu cho tin ngắn;

− Thiết lập khoảng thời gian hợp lệ cho tin ngắn;

− Kết hợp một kiểu dịch vụ với từng tin ngắn, ví dụ: voice mail notification

Tài liệu này sẽ mô tả định dạng của các lệnh và phản hồi có trong giao thức SMPP Hình 1-1 mô tả các giao tiếp có thể sử dụng giao thức SMPP

Hình 1-1 Sơ đồ mô tả các giao tiếp trong mạng di động.

Trang 9

1.1 Định nghĩa giao thức SMPP

SMPP dựa trên sự trao đổi đơn vị dữ liệu (PDU) của giao thức yêu cầu và phản hồi giữa ESME và SMSC qua mạng TCP/IP hoặc X.25 Giao thức SMPP định nghĩa:

− Một tập các lệnh và PDU cho việc trao đổi thông tin giữa ESME và SMSC,

− Dữ liệu mà một ứng dụng của ESME có thể trao đổi với một SMSC trong các lệnh

Tất cả các lệnh phải gồm có PDU của yêu cầu và PDU của phản hồi Tương ứng với một

yêu cầu phải có một phản hồi, chỉ trừ các ngoại lệ đối với PDU alert_notification sẽ không có

phản hồi Việc trao đổi tin giữa ESME và SMSC bằng SMPP có thể chia ra làm 3 nhóm sau:

− Tin được gửi từ ESME (Transmitter) tới SMSC,

− Tin được gửi từ SMSC tới ESME (Receiver),

− Tin được gửi từ ESME (Transceiver) tới SMSC và tin được gửi từ SMSC tới ESME (Transceiver)

Hình 1-2 mô tả 3 nhóm trên, thông tin chi tiết được giải thích tại các đoạn sau

Hình 1-2 Giao tiếp giữa SMSC và ESME 1.2 Mô tả SMPP Session

Một SMPP Session giữa một SMSC và một ESME được khởi tạo bởi ESME trước khi thiết lập một kết nối mạng với SMSC và khi đó sẽ tạo ra một yêu cầu SMPP Bind để mở một SMPP Session Một ESME mong muốn gửi và nhận các tin được yêu cầu để thiếp lập hai kết nối mạng (TCP/IP hoặc X.25) và hai SMPP Session (Transmitter và Receiver) Trong phiên bản hiện tại của giao thức SMPP, một ESME có thể thiết lạp một SMPP Transceiver Session qua một kết nối mạng đơn Trong một SMPP Session, một ESME có thể phát ra một loạt các yêu cầu tới một SMSC và nhận các phản hồi tương ứng với các yêu cầu từ SMSC Tương tự như vậy, SMSC có phát ra các yêu cầu tới ESME và nhận các phản hồi tương ứng Một SMPP Session có thể có các trạng thái sau:

Trang 10

− OPEN (Đã kết nối nhưng chưa Bind) Một ESME đã thiết lập một kết nối mạng

với SMSC nhưng chưa phát yêu cầu Bind

− BOUND_TX ESME đã yêu cầu bind như một ESME Transmitter (phát ra PDU

bind_transmitter) và đã nhận một phản hồi từ SMSC cho phép bind Một ESME

được bind như như một transmitter có thể gửi SMS cho một SMSC để truyền tới một MS hoặc một ESME khác ESME cũng có thể thay thế, truy vấn hoặc bỏ qua một tin ngắn được đệ trình trước đó

− BOUND_RX ESME đã yêu cầu bind như một ESME Receiver (phát ra PDU

bind_receiver) và đã nhận một phản hồi từ SMSC cho phép bind Một ESME được

bind như một receiver có thể nhận tin ngắn từ một SMSC được gửi từ một MS, một ESME khác hoặc bởi chính SMSC (ví dụ: một SMSC gửi báo cáo)

− BOUND_TRX ESME đã yêu cầu bind như một ESME Transceiver (phát ra PDU

bind_transceiver) and đã nhận một phản hồi từ SMSC cho phép bind Một ESME

được bind như như Transceiver hỗ trợ các tất cả các lệnh được hỗ trợ bởi một Transmitter ESME và một Receiver ESME Như vây, một ESME được bind như một Transceiver có thể gửi các tin ngắn tới một SMSC để truyền tới MS hoặc tới một ESME khác ESME cũng có thể nhận các tin ngắn từ một SMSC mà có nguồn gốc từ một MS, từ ESME khác hoặc chính SMSC (ví dụ: SMSC gửi báo cáo)

− CLOSE (Đã thôi bind và ngắt kết nối) Một ESME đã thôi bind khỏi một SMSC

và đã ngắt kết nối mạng SMSC có thể thôi bind khỏi ESME

Hình 1-3 Sơ đồ tuần tự của lệnh outbind

outbind bind_receiver

bind_receiver_res

p deliver_sm deliver_sm_resp

Trang 11

1.3 Các PDU trong SMPP

Bảng 1-1 Danh sách các PDU có trong SMPP và ngữ cảnh sử dụng các PDU

SMPP Session

Phát bởi ESME

Phát bởi SMSC

BOUND_RXBOUND_TRX

YesYesYes

BOUND_RXBOUND_TRX

YesYesYes

BOUND_TRX

YesYes

NoNo

BOUND_TRX

NoNo

YesYes

BOUND_TRX

YesYes

NoNo

BOUND_TRX

NoNo

YesYes

BOUND_RXBOUND_TRX

YesYesYes

BOUND_RXBOUND_TRX

YesYesYes

BOUND_TRX

NoNo

YesYes

BOUND_TRX

YesYes

NoNo

BOUND_TRX

YesYes

NoNo

BOUND_TRX

NoNo

YesYes

Trang 12

cancel_sm BOUND_RX

BOUND_TRX

YesYes

NoNo

BOUND_TRX

NoNo

YesYes

BOUND_RXBOUND_TRX

YesYesYes

BOUND_RXBOUND_TRX

YesYesYes

BOUND_TRX

NoNo

YesYes

BOUND_RXBOUND_TRX

YesYesYes

1.4 Kết kết nối tại tầng mạng của SMPP

Giao tiếp vần chuyển bên dưới giữa SMSC và ESME có thể dựa trên một kết nối mạng TCP/IP hoăck X.25 SMPP là giao thức thuộc tầng ứng dụng không dùng cho các chức năng vận chuyển Tại mức SMPP, ESME và SMSC xử lý các kết nối mạng giống như các chức năng vận chuyển, truyền và nhận các PDU Hình 1-4 mô tả các giao tiếp chung giữa ESME và SMSC

Nếu cần thiết, nó có thể đòi hỏi tầng mạng tại thực thể gửi sẽ phải nắm giữ được sự phân đoạn của các PDU,của SMPP, để truyền như một dãy các gói được phân đoạn qua kết nối mạng Tương tự, tầng mạng tại thực thể nhận cũng phải tổng hợp lại được các PDU trước khi đưa chúng lên tầng SMPP

Hình 1-4 Giao tiếp giữa ESME và SMSC trong SMPP

Trang 13

1.5 Các tin được gửi từ ESME tới SMSC

Một ESME mà gửi các tin ngắn tới một SMSC phải được kết nối tới SMSC như một ESME Transmitter hoặc ESME Transceiver Ví dụ các PDU có thể được gửi từ ESME

Transmitter tới SMSC gồm có: submit_sm, data_sm Thêm vào, để có thể gửi các tin tới

SMSC, một ESME phải sử dụng các định danh của tin được trả lại từ SMSC trong tin báo nhận:

− query_sm: Truy vấn trạng thái của tin được đệ trình trước đó trên SMSC.

− cancel_sm: Bỏ qua việc truyền của một tin được đệ trình trước đó.

− replace_sm: Thay đổi một thông được được đệ trình trước đó.

Các PDU được gửi tới SMSC bởi ESME phải được thông báo nhận một PDU được phản hồi từ SMSC Tham khảo chi tiết trong bảng 1-1 để xem các lệnh có thể được gửi từ một ESME tới SMSC

1.5.1 Các tin được phản hồi từ SMSC về ESME

PDU phản hồi cho việc đệ trình một tin tới SMSC sẽ chứa một định danh của tin (nó là duy nhất đối với mỗi tin) và một trạng thái cho biết tin được ESME đệ trình là hợp lệ hay

không Trong các trường hợp sau đây, SMSC sẽ trả lại một trạng thái lỗi: submit_sm_resp, data_sm_resp, query_sm_resp, cancel_sm_resp, replace_sm_resp.

1.5.2 Sơ đồ tuần tự của SMPP session - ESME Transmitter

Hình 1-5 mô tả các chuỗi các yêu cầu/phản hồi giữa một SMSC và một ESME được bind như một Transmitter

Việc trao đổi PDU của yêu cầu và phản hồi giữa một ESME Transmitter và SMSC có thể xảy ra một cách đồng bộ hoặc bất đồng bộ, như hình vẽ, Do vậy, ESME có thể gửi nhiều yêu cầu tới SMSC, không cần phải đợi tín hiệu đồng bộ tương ứng với các PDU Một dãy các yêu cầu liên tiếp được phát một cách bất đồng bộ bởi một ESME phải tương ứng bằng một dãy các phản hồi tiếp theo từ SMSC Các phản hồi phải được trả lại bởi SMSC theo thứ tự tương ứng với các yêu cầu của ESME ESME phải phản hồi lại SMSC theo thứ tự yêu cầu của SMSC Chỉ có phản hồi liên quan đến một ESME Transmitter trong một session này là

enquire_link_resp Số lượng các tin chưa được giải quyết giữa ESME và SMSC không được

quy định, sẽ do cách triển khai giao thức SMPP trong thực tế, khuyến nghị không được quá

10 tin trong một lần

Trang 14

Hình 1-5 Sơ đồ tuần tự yêu cầu/phản hồi cho một ESME Transmitter.

1.6 Các tin được gửi từ SMSC tới ESME

SMSC có thể gửi các tin ngắn tới một ESME Trong trường hợp này, ESME phải được kết nối tới SMSC như một ESME Receiver hoặc một ESME Transceiver Các ứng dụng điển hình hoạt động theo ESME Receiver gồm có:

− Email gateway: chấp nhận các tin bắt nguồn từ các MS để gửi tới các hòm thư điện

tử của Internet

− SMSC cũng có thể gửi một báo cáo tới ESME chứa trạng thái của một tin ngắn được đệ trình trước đó

Ví dụ các PDU có thể được truyền từ SMSC tới ESME gồm có: deliver_sm, data_sm Các

PDU được truyền SMSC truyền tới ESME phải được thông báo nhận bằng một PDU phản hồi

của ESME, khi ESME nhận được, ngoại trừ PDU alert_notification Xem bảng 1-1 để xem

chi tiết các lệnh có thể được SMSC gửi tới ESME

1.6.1 Tin phản hồi từ ESME về SMSC

PDU phản hồi từ một ESME Receiver phải lưu giữ các định danh quá trình giao dịch

(chứa trong tham số của sequence_number) được gửi bởi SMSC Phản hồi cũng phải đưa

trạng thái của lệnh cho biết tin được SMSC truyền tới ESME là hợp lệ hay không Tiếp theo, ESME trả lại một trạng thái tương ứng Ví dụ các phản hồi có thể được gửi từ một ESME

Receiver tới SMSC: deliver_sm_resp, data_sm_resp

1.6.2 Sơ đồ tuần tự của SMPP session - ESME Receiver

Hình 1-6 mô tả các chuỗi các yêu cầu/phản hồi giữa một SMSC và một ESME được bind như một Receiver

bind_transmitter(1) bind_transmitter_resp(1) submit_sm(2) submit_sm_resp(2) submit_sm(3) submit_sm(4) query_sm(5) submit_sm(6) submit_sm_resp(3) submit_sm_resp(4) query_sm_resp(5) submit_sm_resp(6) unbind(7) unbind_resp(7)

Trang 15

Hình 1-6 Sơ đồ tuần tự các yêu cầu và phản hồi cho một ESME Receiver.

Trao đổi các PDU của yêu cầu và phản hồi giữa SMSC và ESME Receiver có thể xẩy ra

một cách đồng bộ hoặc bất đồng bộ Do vậy, SMSC có thể gửi nhiều yêu cầu deliver_sm tới

ESME, không cần đợi tín hiệu đồng bộ Một dãy các yêu cầu liên tiếp được phát không đồng

bộ bởi một SMSC phải được tương ứng bằng một dãy các phản hồi tương ứng từ ESME ESME phải phản hồi lại cho SMSC theo cùng thứ tự của yêu cầu Số lượng các tin chưa được giải quyết giữa ESME và SMSC không được quy định, sẽ do cách triển khai giao thức SMPP trong thực tế, khuyến nghị không được quá 10 tin trong một lần

1.7 Trao đổi tin kép giữa SMSC và ESME

SMSC và ESME có thể tạo ra session trao đổi đổi thông tin kép (duplex), các tin được trao đổi theo cả hai chiều Trong trường hợp này, ESME phải được kết nối với SMSC như một ESME Transceiver Các ứng dụng điển hình trong trường hợp này gồm có:

− Trao đổi thông tin hai chiều giữa một MS và một ESME, ví dụ WAP Proxy Server Các thuê bao di động khởi tạo một yêu cầu thông tin tới WAP Proxy Server và thông tin phản hồi sẽ được trả lại bằng SMSC tới MS Ví dụ các PDU có

thể gửi trong SMPP Transceiver session: data_sm, submit_sm, deliver_sm.

Để có thể gửi các tin tới SMSC, một ESME phải sử dụng các định danh của tin được trả lại từ SMSC trong thông tin báo nhận:

− query_sm: Truy vấn trạng thái của tin được đệ trình trước đó

− cancel_sm: Bỏ qua việc chuyển tin được đệ trình trước đó

− replace_sm: Thay thế một tin được đệ trình trước đó

Khi nhận được, SMSC phải phản hồi bằng các PDU thông báo nhận, ngoài trừ trường hợp alert_notification Tham chiếu bảng 1-1 để xem các thông tin chi tiết về các lệnh có thể có trong SMPP Transceiver session

1.7.1 Typical SMPP session sequence - ESME Transceiver

Sơ đồ sau mô tả chuỗi các yêu càu và phản hồi giữa SMSC và ESME được bind như Transceiver

bind_receiver(1) bind_receiver_resp(1) deliver_sm(1) deliver_sm_resp(1) deliver_sm(2)

deliver_sm(4) deliver_sm_resp(2) deliver_sm_resp(3) deliver_sm_resp(4) unbind(2) unbind_resp(2) deliver_sm(3)

Trang 16

Hình 1-7 Sơ đồ tuần tự các yêu cầu và phản hồi cho ESME Transceiver.

Các PDU được trao đổi giữa SMSC và ESME Transceiver có thể được tiến hành một cách

đồng bộ hoặc không đông bộ SMSC có thể gửi nhiều yêu cầu data_sm tới ESME mà không

cần phải đợi tín hiệu đồng bộ Các PDU của phản hồi cần phải được ánh xạ tương ứng với các

PDU yêu cầu thông qua tham số sequence_number trong Header ESME phải trả lại các phản

hồi theo thứ tự các yêu cầu nhận được từ SMSC và ngược lại các phản hồi từ SMSC cũng phải theo thứ tự của các yêu cầu nhận được từ ESME Số lượng tối đa các tin cần chờ xử lý được khuyến nghị là 10

1.8 Bắt lỗi

Tất cả các lệnh của SMPP bao gồm một PDU yêu cầu và một PDU phản hồi tương ứng,

trừ ngoại lệ PDU alert_notification là không có phản hồi Trong tất cả các trường hợp, thực

thể nhận phải trả lại PDU phản hồi tương ứng cho một PDU yêu cầu, chỉ định rằng PDU gốc

đã đến đích

Trong trường hợp trong PDU của yêu cầu gốc có chứa lỗi, thực thể nhận phải trả lại phản

hồi bằng một mã lỗi được trèn vào trong trường command_status trong phần header của PDU

phản hồi Nếu thực thể nhận tìm thấy một lỗi trong header của PDU, nó phải trả lại PDU

generic_nak cho người gửi.

1.9 SMPP Timer

Để đảm bảo việc trao đổi của các giao dịch có hiệu lực, mỗi SMPP session phải được quản lý theo thời gian trên cả hai phía ESME và SMSC:

− Mỗi SMPP session cần phải có khoảng thời gian hiệu lực xác định

− Một timer cho phép cả ESME và SMSC có thể truy vấn trạng thái cả SMPP

session thông qua lệnh equire_link.

− Sau một khoảng thời gian không có sự giao dịch, SMPP session phải bị hủy

bind_transceiver (1) bind_transceiver_resp (1) data_sm (1) data_sm_resp (1) data_sm (2)

data_sm (3) data_sm (2) data_sm (3) data_sm_resp (3) data_sm_resp (2)

data_sm_resp (2) data_sm_resp (3) unbind (4) unbind_resp (4)

Trang 17

− Khoảng thời gian giữa một yêu cầu và phản hồi tương ứng cũng phải được xác định.

Xem thông tin chi tiết của SMPP Timer trong mục 6.2.

1.10 Các chế độ của tin

SMPP đưa ra các chế độ của tin, nhưng là tùy chọn Nếu được SMSC hỗ trợ, một ESME

có thể chọn cơ chế truyển tin Cơ chế truyền điển hình có thể được SMSC hỗ trợ là:

− Store and Forward

− Datagram

− Transaction

Các chế độ được mô tả chi tiết tại các đoạn sau

1.10.1 Chế độ Store and Forward

Theo quy ước SMS phải lưu các tin trong kho của SMSC trước khi chuyển tiếp các tin cho việc truyền tới SME của người nhận Trong mô hình này các tin vãn được lưu một cách an

toàn trước khi tất cả các lần cố gắng gửi là thành công Chế độ này sử dụng submit_sm, data_sm, query_sm, replace_sm và cancel_sm Để xác định được tin đã thực sự được truyền hay chưa, ESME phải yêu cầu báo cáo từ SMSC trong submit_sm hoặc data_sm.

Trang 18

Hình 1-8 Sơ đồ tuần tự cho chế độ lưu trữ và chuyển tiếp

độ này thông qua data_sm Tham số esm_class được sử dụng để lựa chọn chế độ Datagram,

xem mục 4.2.12

bind_transmitter bind_transmitter_resp bind_receiver bind_receiver_resp

submit_sm (registered_delivery

= SMSC Deliver Receipt) submit_sm_resp

deliver_sm (esm_class = SMSC Delivery Receipt) deliver_sm_resp

submit_sm (registered_delivery

= SMSC Delivery Receipt) submit_sm_resp

Network Delivery Attempt

= SMSC Delivery Receipt deliver_sm_resp

Wireless Network Protocol SMPP

Trang 19

Hình 1-9 Sơ đồ tuàn tự truyền tin cho chế độ datamgram.

1.10.3 Chế độ Transaction

Chế độ transaction cho phép ESME, đã gửi tin gốc, nhận một thông báo nhận chỉ định tin

có được gửi đến MS thành công hay không trong PDU phản hồi Chế độ này được thiết kế cho các ứng dụng truyền các tin theo thời gian thực khi một ESME yêu cầu truyền đồng bộ end-to-end có thông báo nhận, không cần đến kho lưu trữ của SMSC Các ứng dụng sử dụng chế độ này thường là multicast, truyền tin đến một nhóm Chế độ Transaction chỉ sử dụng

data_sm Tham số esm_class được sử dụng để lựa chọn chế độ, xem mục 4.2.12 Trong chế

độ Transaction, ESME nhận một data_sm_resp chỉ định kết quả của việc truyền end-to-end

Còn trong chế độ Datagram, PDU phản hồi chỉ định rằng tin có được SMSC chấp nhận thông quá kết nối SMPP không

Hình 1-10 Sơ đồ tuần tự truyền tin cho chế độ Transaction 1.11 Các loại tin

Các tin nhắn thông thường và đặc biệt có thể được truyền giữa ESME và SMSC trong

submit_sm, deliver_sm hoặc data_sm Kiểu tin được xác định thông qua tham số esm_class

binding_transceiver binding_transceiver_resp

data_sm (esm_class = datagram) data_sm_resp

data_sm (esm_class = forward)

data_sm_resp

ACK Wireless Network Protocol SMPP

Trang 20

Các loại tin gồm có: SMSC Delivery Receipt, Intermediate Notification, SME Delivery Acknowledgement, SME Manual/User Acknowledgement, Conversation Abort.

1.11.1 SMSC Delivery Receipt

Loại tin này được sử dụng để chứa các thông báo hay báo cáo của SMSC SMSC sẽ dựa vào trạng thái của các tin trong kho lữu trữ để tạo ra tin báo cáo cho đối tượng gửi tin Trong các hệ thống tính cước thường sẽ dựa vào thông tin này để tính cước Các trường có liên quan

trong deliver_sm và data_sm khi truyền loại tin này:

− Địa chỉ nguồn, ví dụ: source_addr_ton, source_addr_npi, source_addr Địa chỉ

nguồn của loại tin này được lấy từ địa chỉ đích có trong tin ngắn gốc

− Địa chỉ đích, ví dụ: dest_addr_ton, dest_addr_npi, destination_addr Địa chỉ đích

được của loại tin này được lấy từ địa chỉ nguồn của tin ngắn gốc

− Thông báo về khả năng chứa của bộ nhớ cho hệ thống Voice Mail,

− Báo cáo kết quả của lần cố gắng truyền tin đầu tiên là thất bại, nhưng các tin vẫn được giữ trong SMSC cho các lần cố gắng truyền tiếp theo

1.11.3 SME Delivery Acknowledgement

SME Delivery Acknowledgement là tin thông báo tin ngắn đã được truyền tới SME, không phải là dấu hiệu xác nhận người sử dụng đã đọc tin Loại tin này không phải được hỗ trợ bởi hầu hết các mạng

1.11.4 SME Manual/User Acknowledgement

Loại tin Manual/User Acknowledgement là một tin trả lời cho tin yêu cầu trả lời Ví dụ, loại tin này có thể chứa một mục trong menu được lựa chọn trong một danh sách của menu

mà đã gửi cho một ứng dụng Loại tin này không được hỗ trợ bởi hẫu hết các mạng

Trang 21

PHẦN II ĐỊNH DẠNG VÀ KIỂU PDU TRONG SMPP

2.1 Các định nghĩa về kiểu

Các kiểu được sử dụng để định nghĩa các tham số trong SMPP:

Integer Là số nguyên dương, được lưu dưới dạng octet Các octet cần phải được

chuyển về MSB trước (Big Endian)

C-Octet String Là một dãy các ký tự ASCII, tận cùng là ký tự NULL để xác định

Octet String A Là một chuỗi các octet, không cần ký tự NULL kết thúc.

2.1.1 Kích thước của các trường tham số

Bảng 2-1 Kích thước các trường tham số

C-Octet String Chuỗi gồm các ký tự ASCII có chiều dài thay đổi từ 1 đến

15 Một chuỗi rỗng cũng chứa ký tự NULL là octet 0x00

Cố định 1

hoặc 17

C-Octet String 1: dùng cho ký tự NULL

17: dùng cho 16 ký tự cộng thêm ký tự NULLThay đổi

0 đến 254

Octet String Chiều dài thay đổi tự 0 đến 254, không cần đến ký tự

NULL

2.2 Đinh dạng chung của PDU

Bảng 2-2 Định dạng tổng quát của PDU trong giao thức SMPP

command status

sequence number

PDU Body

4 octet Length = Giá trị của command length – 4 (octet)

Phần Header là bắt buộc, Body là tùy chọn Định dạng chi tiết được mô tả trong phần 3

Trang 22

command_id 4 Integer Chứa định danh của mỗi PDU, ví dụ:

submit_sm, query_sm,… Mỗi PDU của yêu

cầu được cấp phát một giá trị duy nhất nằm trong khoảng:

0x00000000 - 0x000001FFMỗi PDU của phản hồi được cấp phát một giá trị duy nhất nằm trong khoảng:

0x80000000 - 0x800001FFChú ý: command_id của phản hồi đồng nhất với yêu cầu, chỉ có bit 31 được thiết

lập Phần 4 sẽ mô tả chi tiết command_id.

command_status 4 Integer Chắ trạng thái thành công hay thất bại của

một yêu cầu Nó chỉ liên quan đến PDU của phản hồi, do vậy phải chứa giá trị NULL trong PDU của yêu cầu Danh sách các lỗi được định nghĩa trong phần 4.sequence_number 4 Integer Chứa chỉ số tuần tự để cho phép các yêu

cầu và phản hồi có thể xác định được mối tương quan với nhau, đặc biệt trong trao đổi tin bất đồng bộ Giá trị phải được tăng

tự động bởi các yêu cầu và phải được lữu giữ trong các phản hồi Giá trị của nó nằm trong khoảng:

Thay đổi hỗn tạp Các tham số tùy chọn tương ứng với

trường command_id, xem chi tiết trong

phần 4

Một vài PDU chỉ có phần Header, không có Body, ví dụ: enquire_link.

2.2.2 Chiều dài của PDU

Trường command_length, tại vị trí bắt đầu trong phần Header của PDU, chỉ ra chiều dài

tổng cộng của PDU, tính bằng octet Giá trị của trường này là một số nguyên 4 octet được chuyển đổi về dạng Big Endian Để phân tích được một PDU, ESME hoặc SMSC phải được

trường command_id trước.

Ví dụ: Giả sử ta có một luồng dữ liệu mô tả phần header của một PDU như sau (mô tả dưới dạng hexa):

Trang 23

2.2.3 Kích thước của tin và phần mở rộng của tin

Kích thước của tin ngắn (hoặc dữ liệu của người sử dụng) được định nghĩa trong trường

sm_length của các PDU submit_sm, submit_multi, deliver_sm và replace_sm Kích thước tối

đa được chỉ ra trong trường sm_length là 254 Nếu một ESME muốn đề trình một tin có chiều dài lớn hơn 254 octet thì trường sm_length phải thiết lập là NULL và tham số tùy chọn message_payload phải chỉ ra chiều dài của tin.

SMP hỗ trợ chiều dài tin mở rộng trong các PDU submit_sm, submit_multi, data_sm và deliver_sm.

Chú ý: Chiều dài thật sự của tin có thể truyền tới một MS có thể là khác, tùy theo mạng bên dưới

2.2.4 Các tham số tùy chọn

Các tham số tùy chọn là một cơ chế để sử dụng trong tương lai Chúng luôn luôn xuất hiện tại cuối của PDU ESME hoặc SMSC có thể đưa vào một vài các tham số tùy chọn để sử dụng cho một chức năng mới.

2.2.4.1 Định dạng tham số tùy chọn

Tất cả các tham số tùy chọn được định dạng theo TVL (Tag, Length, Value) Giá trị cho Tag, Length và Value cho mỗi tham số được định nghĩa trong phần 4

Bảng 2-4 Định dạng các tham số tùy chọn

Tag 2 Integer Có giá trị duy nhất đổi với mỗi tham số tùy

chọn

Length 2 Integer Chỉ ra kích thước của trường Value, tính bằng

octet Value Thay đổi Thay đổi Chứa giá trị thực sự của tham số tùy chọn

2.3 Khả năng tương thích của các phiên bản cũ của giao thức SMPP

Để có thể đảm bảo được sự tương thích các thực thể như SMSC và ESME đang sử dụng phiên bản cũ của giao thức SMPP có thể dễ dàng giao tiếp được với các thực thể sử dụng phiên bản mới hơn Do vậy, việc diễn giải SMPP phải đảm bảo được quá trình xử lý thành công và thích hợp với các trường hợp sau:

− Nếu một thực thể của SMPP nhận được một lệnh không được chấp nhận hoặc

không hỗ trợ, nó cần phải trả lại một PDU generic_nack chỉ ra lệnh sai trong

trường command_status

Trang 24

− Khi một thực thể SMPP nhận được một tin chứa các tham số tùy chọn có giá trị Tag như sau:

o Tag được hỗ trợ bởi thực thể đó, tham số tùy chọn được xử lý

o Tag không được chấp nhận, nhưng không mong trờ một lệnh gì, tham số sẽ

bị bỏ qua

o Tag không được chấp nhận hoặc không được hỗ trợ thì tham số đó bị bỏ quan và tham số tiếp theo được xử lý

− Một thực thể SMPP nhận được một giá trị trị tham số như “reserved” thì nên sử

dụng giá trị mặc định được định nghĩa, nếu không thì tham số nên bị bỏ qua

− Nếu tham ssó không được chấp nhận hoặc không hợp lệ, thực thể SMPP nên trả lại một lỗi chỉ ra tham số đó không hợp lệ

− Một thực thể SMPP phát hiện ra rằng một tham số tùy chọn, được yêu cầu trong ngữ cảnh của lệnh, không được đưa ra thì nên trả lại một tin phản hồi về lỗi một tham số tùy chọn cần được cung cấp

− Nếu chiều dài giá trị của tham số tùy chọn không được chấp nhận, thực thể SMPP nên trả lại lỗi chiều dài tham số Mỗi thực thể sẽ định nghĩa ra chiều dài tối đa cho mỗi tham số

2.4 Khả năng tương thích của các phiên bản mới của giao thức SMPP

Để có thể đảm bảo được sự tương thích các thực thể như SMSC và ESME đang sử dụng phiên bản mới của giao thức SMPP có thể dễ dàng giao tiếp được với các thực thể sử dụng phiên bản cũ hơn Do vậy, việc diễn giải SMPP phải đảm bảo được quá trình xử lý thành công

và thích hợp với các trường hợp sau:

− Các PDU đã có không được loại bỏ khỏi giao thức

− Định dạng mới của tin phải giống như định dạng cũ

− Các tham số mới chỉ là thêm vào

− Các tham số tùy chọn không nên bắt buộc

− Các tham số bắt buộc không nên trở thành tùy chọn

− Các tham số bắt buộc thêm không nên đưa vào các PDU sẵn có

− Các tham số bắt buộc đã có không được loại bỏ khỏi các PDU sẵn có

− Giá trị của tất cả các tham số sẵn có không được thay đổi trogn phiên bản mới

Trang 25

PHẦN III CÁC PDU TRONG SMPP

3.1 Lệnh “BIND”

Mục đích của lệnh BIND là để đăng ký một thể hiện của một ESME với hệ thống SMSC

và yêu cầu một SMPP session để đệ trình hoặc gửi tin Có thể xem BIND như là một mẫu

đăng nhập để xác thực ESME trước khi thiết lập kết nối Một ESME có thể bind như một Transmitter, Receiver hoặc Transceiver Có 3 PDU của bind để hỗ trợ một vài các chế độ của

lệnh: bind_transmitter, bind_transceiver và bind_receiver Trường command_id xác định

PDU được sử dụng Một ESME có thể bind như một SMPP Transmitter và Receiver sử dụng

các lệnh bind_transmitter và bind_receiver riêng biệt Nếu một SMSC không hỗ trợ bind_transmitter và bind_receiver thì nó phải trả lại một tin phản hồi thông báo sai mã lệnh

và ESME thử bind lại lần nữa bằng bind_transceiver Tương tự như vậy, nếu một SMSC không hỗ trợ bind_transceiver thì nó phải trả lại tin phản hồi thông báo sai mã lệnh và thử bind lại bằng bind_transmitter hoặc bind_receiver hoặc cả hai bind_transmitter và bind_receiver.

ESME Transmitter Một ESME được bind như một Transmitter được phép gửi cá tin

ngắn tới SMSC và nhận các phản hồi tương ứng từ SMSC Nó không được thiết kết để nhận các tin từ các SME

ESME Receiver Một ESME được bind như Receiver được phép nhận tin ngắn từ SMSC

và trả lại các phản hồi tới SMSC.s

ESME Transceiver Một ESME được bind như một Transceiver được phép gửi các tin

tới SMSC và nhận các tin từ SMSC qua một SMPP session đơn

command_length 4 Integer Kích thước của PDU 4.1.1

command_status 4 Integer Không sử dụng cho PDU

bind_transmitter Phải được

system_id b Thay đổi

max = 16 C-Octet String Định danh của ESME yêu cầu bind như transmitter với

system_type d Thay đổi

max = 13 C-Octet String Định danh của hệ thống ESME 4.2.3

interface_version 1 Integer Chỉ ra phiên bản của giao thức

addr_ton 1 Integer Chỉ ra kiểu số địa chỉ của

ESME Nếu không biết thì thiết lập giá trị NULL

4.2.5

addr_npi 1 Integer Chỉ ra cách đánh số cho địa chỉ 4.2.6

Trang 26

của ESME Nếu không biết thì thiết lập giá trị NULL.

address_range Thay đổi

max = 41 C-Octet String Địa chỉ của ESME Nếu không biết thì thiết lập giá trị NULL 4.2.7

a Không có yêu cầu đặc biệt đối với sequence_number Nó được khuyến nghị sử dụng

chế độ tự động tăng

b Khuyến nghị sử dụng system_id để định danh thực thể bind, ví dụ “SMS_GW”.

c password được sử dụng để xác thực ESME có thể thiết lập giá trị NULL nếu SMSC

cho phép

d system_type là tùy chọn, được dùng để phân loại hệ thống, ví dụ : “BONG_DA”.

3.1.2 Cú pháp “BIND_TRANSMITTER_RESP”

PDU bind_transmitter_resp được sử dụng để trả lời yêu cầu bind_transmitter.

Bảng 3-2 Định dạng của PDU bind_transmitter_resp.

system_id Thay đổi

max = 16 C-Octet String Định danh SMSC với ESME 4.2.1

bind_receiver Phải được thiết

Trang 27

C-Octet String Định danh của hệ thống ESME 4.2.3

SMPP

4.2.4

addr_ton e 1 Integer Chỉ ra kiểu số địa chỉ của

4.2.5

addr_npi e 1 Integer Chỉ ra cách đánh số cho địa chỉ

của ESME Nếu không biết thì thiết lập giá trị NULL

4.2.6

address_range e Thay đổi

max = 41

C-Octet String Một địa chỉ đơn của ESME

hoặc một khoảng địa chỉ Xem phần phụ lục A Nếu không biết thì thiết lập giá trị NULL

cho phép

e Các tham số addr_ton, addr_npi and addr_range có thể được sử dụng bởi ESME để

cung cấp sự nhận dạng các địa chỉ của SME mà ESME cung cấp

Trang 28

Phần body của bind_receiver_resp sẽ không có nếu command_status chỉ ra lệnh không

bind_transceiver Phải được

system_id b Thay đổi

max = 16 C-Octet String Định danh của ESME 4.2.1

password c Thay đổi

C-Octet String Định danh của hệ thống ESME 4.2.3

SMPP

4.2.4

addr_ton e 1 Integer Chỉ ra kiểu số địa chỉ của

4.2.5

addr_npi e 1 Integer Chỉ ra cách đánh số cho địa chỉ

của ESME Nếu không biết thì thiết lập giá trị NULL

4.2.6

address_range e Thay đổi

max = 41

C-Octet String Một địa chỉ đơn của ESME

hoặc một khoảng địa chỉ Xem phần phụ lục A Nếu không biết thì thiết lập giá trị NULL

cho phép

e Các tham số addr_ton, addr_npi and addr_range có thể được sử dụng bởi ESME để

cung cấp sự nhận dạng các địa chỉ của SME mà ESME cung cấp

3.1.6 Cú pháp “BIND_TRANSCEIVER_RESP”

Trang 29

C-Octet String Định danh SMSC với ESME 4.2.1

password a Thay đổi

max = 9 C-Octet String Được sử dụng bởi ESME để xác thực SMSC đã phát lệnh

Mục đích của unbind là để loại bỏ thể hiện của một ESME khỏi SMSC và cho SMSC biết

rằng ESME không cần đến kết nối mạng cho việc đệ trình hoặc truyền các tin unbind có thể

xem như mẫu yêu cầu thoát của SMSC để đóng SMPP session hiện tại

Trang 30

sequence_number 4 Integer Có cùng giá trị với unbind 4.1.4

3.3 PDU của “GENERIC_NACK”

Thông báo từ chối một PDU được gửi mà có header không hợp lệ Một generic_nack sẽ

trả lại trong các trường hợp sau:

− Lỗi command_length, không thích hợp với dữ liệu (quá ngắn hoặc quá dài)

− Không biết command_id

command_status 4 Integer Chỉ ra lý do tại sao lại gửi

sequence_number 4 Integer Có cùng giá trị với PDU gốc

nếu phân tích được, còn không thì thiết lập giá trị NULL

4.1.4

3.4 Lệnh “SUBMIT_SM”

Lệnh này được sử dụng bởi ESME đệ trình một tin ngắn tới SMSC để truyền tin ngắn tới

một SME PDU submit_sm không hỗ trợ chế độ Transaction của tin.

Trang 31

service_type Thay đổi

max = 6 C-Octet String Chỉ ra dịch vụ ứng dụng SMS

Giá trị NULL là giá trị cấu hình mặc địch của SMSC

4.2.11

source_addr_ton 1 Integer Chỉ ra kiểu số cho địa chỉ

nguồn Nếu không biết, thiết lập giá trị NULL

4.2.5

source_addr_npi 1 Integer Chỉ ra cách đánh số cho địa

chỉ nguồn Nếu không biết thì thiết lập giá trị NULL

4.2.6

source_addr Thay đổi

max = 21

C-Octet String

Địa chỉ của SME, thực thể gửi tin

Nếu không biết, thiết lập giá trị NULL

4.2.8

dest_addr_ton 1 Integer Chỉ ra kiểu số cho địa chỉ

đích Nếu không biết, thiết lập giá trị NULL

4.2.5

dest_addr_npi 1 Integer Chỉ ra cách đánh số cho địa

chỉ đích Nếu không biết thì thiết lập giá trị NULL

4.2.6

destination_addr Thay đổi

max = 21

C-Octet String

Địa chỉ đích tin ngắn Ví

dụ địa chỉ của MS

4.2.9

esm_class 1 Integer Chỉ đinh chế độ của tin 4.2.12

protocol_id 1 Integer Định danh giao thức 4.2.13

priority_flag 1 Integer Mức độ ưu tiên 4.2.14

schedule_delivery_time 1 hoặc

17

C-Octet String

Đặt lịch cho SMSC gửi tin ngắn Thiết lập NULL nếu yêu cầu gửi ngay

4.2.15

validity_period 1 hoặc

17

C-Octet String

Khoảng thời gian hợp lệ của tin ngắn Thiết lập NULL nếu sử dụng cấu hình mặc định của SMSC

4.2.16

registered_delivery 1 Integer Chỉ định SMSC gửi báo

replace_if_present_flag 1 Integer Chỉ định tin ngắn có thể

thay đổi được

4.2.18

Trang 32

data_coding 1 Integer Chỉ ra cách mã dữ liệu 4.2.17

sm_default_msg_id 1 Integer Gửi tin ngắn có được từ

danh sách đã được định nghĩa sẵn trên SMSC

Không sử dụng thì thiết lập giá trị NULL

Octet String Nội dung tin ngắn, tối ra là

254 octet, nhưng còn tùy thuộc vào cấu hình mạng

Nếu muốn gửi dữ liệu dài hơn thì phải dùng tham số

message_payload và sm_length thiết lập bằng 0

4.3.2.20

source_addr_subunit TLV The subcomponent in the

destination device which created the user data.

4.3.2.21

Trang 33

WAP

sar_msg_ref_num TLV Số tham chiếu để kết nối

các phần riêng của tin

4.3.2.22

sar_total_segments TLV Số lượng tin ngắn trong tin

cần nối lại

4.3.2.23

sar_segment_seqnum TLV Chỉ ra số tuần tự của một

tin ngắn trong tin cần được nối lại

4.3.2.24

more_messages_to_sen

cần gửi tới SME

4.3.2.34

payload_type TLV Kiểu payload, ví dụ: WDP,

WCMP

4.3.2.10

message_payload TLV Chứa tin được mở rộng,

chiều dài có thể lên đến 64k

4.3.2.32

privacy_indicator TLV Chỉ ra mức riêng tư 4.3.2.14

source_subaddress TLV Địa chỉ nguồn phụ 4.3.2.15

sms_signal TLV Chỉ ra cơ chế thông báo

khi MS nhận được tin 4.3.2.40

ms_validity TLV Chỉ ra thông tin về tính

hợp lệ của tin cho MS 4.3.2.27

number_of_messages TLV Chỉ ra số lượng tin được

lưu trong một mail box

4.3.2.39

alert_on_msg_delivery TLV Yêu cầu báo cáo bằng một

tin báo cáo

trường địa chỉ nguồn Trong trường hợp này, SMSC có thể thay thế bằng một địa chỉ mặc định cho mỗi ESME Đặc tính được thiết kế cho các hệ mơ hồ về địa chỉ nguồn như hệ thống voice mail

3.4.1.2 Quá trình thay thế tin trong “SUBMIT_SM”

Giao thức SMPP đưa lệnh replace_sm cho việc thay thế một tin ngắn đã được đệ trình

trước đó mà chưa dc truyền đến đích Chức năng thay thế có thể được kích hoạt trong PDU

submit_sm, thiết lập giá trị cho replace_if_present_flag = 1 Cách khác, quản trị của SMSC có

thể định nghĩa ra một kiểu dịch vụ đặc biệt để cung cấp chức năng thay thế thông qua trường

service_type Trong trường hợp này, để kích hoạt chức năng thay thế, ta thiết lập giá trị cho trường service_type một giá trị náo đó đã được định nghĩa Cả hai phương pháp trên đều có

Trang 34

thể được sử dụng để thay thế tin ngắn Dữ liệu chứa trong tin ngắn cũ được tìm thấy trong

SMSC phải có địa chỉ nguồn, địa chỉ đích và service_type phải giống như tin nhắn mới được

đệ trình trong submit_sm mới Nếu không tìm thấy tin nhắn cũ trong SMSC thì sẽ trả lại lỗi trong PDU replace_sm_resp.

command_status 4 Integer Chỉ ra kết quả của submit_sm 4.1.3

sequence_number 4 Integer Có cùng giá trị trong PDU

4.2.23

Phần Body của submit_sm_resp sẽ không có nếu command_status có giá trị khác không.

3.5 Lệnh “SUBMIT_MULTI”

Lệnh submit_multi dc sử dụng để đệ trình một tin mà được gửi cho nhiều người nhận

PDU submit_sm không hỗ trợ chế độ Transaction của tin.

service_type Thay đổi

max = 6 C-Octet String Chỉ ra dịch vụ ứng dụng SMS

Giá trị NULL là giá trị cấu hình mặc địch của SMSC

source_addr_ton 1 Integer Chỉ ra kiểu số cho địa chỉ

nguồn Nếu không biết, thiết lập giá trị NULL

4.2.5

Trang 35

source_addr_npi 1 Integer Chỉ ra cách đánh số cho địa

chỉ nguồn Nếu không biết thì thiết lập giá trị NULL

4.2.6

source_addr Thay đổi

max = 21

C-Octet String

Địa chỉ của SME, thực thể gửi tin

Nếu không biết, thiết lập giá trị NULL

4.2.8

number_of_dests 1 Integer Chỉ ra kiểu số cho địa chỉ

4.2.24

dest_address(es) Thay đổi Chứa một hoặc nhiều địa

chỉ của SME, và/hoặc tên các danh sách gửi tin

Bảng3-13

esm_class 1 Integer Chỉ đinh chế độ của tin 4.2.12

protocol_id 1 Integer Định danh giao thức 4.2.13

priority_flag 1 Integer Mức độ ưu tiên 4.2.14

schedule_delivery_time 1 hoặc

17

C-Octet String

Đặt lịch cho SMSC gửi tin ngắn Thiết lập NULL nếu yêu cầu gửi ngay

4.2.15

validity_period 1 hoặc

17

C-Octet String

Khoảng thời gian hợp lệ của tin ngắn Thiết lập NULL nếu sử dụng cấu hình mặc định của SMSC

4.2.16

registered_delivery 1 Integer Chỉ định SMSC gửi báo cáo 4.2.17

replace_if_present_flag 1 Integer Chỉ định tin ngắn có thể

thay đổi được

4.2.18

data_coding 1 Integer Chỉ ra cách mã dữ liệu 4.2.19

sm_default_msg_id 1 Integer Gửi tin ngắn có được từ

danh sách đã được định nghĩa sẵn trên SMSC

Không sử dụng thì thiết lập giá trị NULL

Octet String Nội dung tin ngắn, tối ra là

254 octet, nhưng còn tùy thuộc vào cấu hình mạng

Nếu muốn gửi dữ liệu dài

4.2.22

Trang 36

hơn thì phải dùng tham số

message_payload và sm_length thiết lập bằng 0

4.3.2.20

source_addr_subunit TLV The subcomponent in the

destination device which created the user data.

4.3.2.21

sar_msg_ref_num TLV Số tham chiếu để kết nối

các phần riêng của tin

4.3.2.22

sar_total_segments TLV Số lượng tin ngắn trong tin

cần nối lại

4.3.2.23

sar_segment_seqnum TLV Chỉ ra số tuần tự của một

tin ngắn trong tin cần được nối lại

4.3.2.24

more_messages_to_sen

cần gửi tới SME

4.3.2.34

payload_type TLV Kiểu payload, ví dụ: WDP,

WCMP

4.3.2.10

message_payload TLV Chứa tin được mở rộng,

chiều dài có thể lên đến 64k

4.3.2.32

privacy_indicator TLV Chỉ ra mức riêng tư 4.3.2.14

source_subaddress TLV Địa chỉ nguồn phụ 4.3.2.15

sms_signal TLV Chỉ ra cơ chế thông báo

khi MS nhận được tin 4.3.2.40

ms_validity TLV Chỉ ra thông tin về tính

hợp lệ của tin cho MS 4.3.2.27

number_of_messages TLV Chỉ ra số lượng tin được 4.3.2.39

Trang 37

lưu trong một mail box

alert_on_msg_delivery TLV Yêu cầu báo cáo bằng một

tin báo cáo

dest_flag 1 Integer Chỉ ra địa chỉ đích là tên

danh sách gửi tin hay địa chỉ của SME

4.2.25

SME Address hoặc

Distribution List Name Phụ thuộc vào trường

dest_flag

Bảng3-14 và 3-15

4.2.5

4.2.6

max = 21

C-Octet String Địa chỉ đích tin ngắn Ví dụ địa chỉ của MS 4.2.9

3.5.1.2 Định nghĩa danh sách gửi tin

Bảng 4-15 Định nghĩa danh sách gửi tin

dl_name Thay đổi

max = 21

C-Octet String

Tên của danh sách gửi tin 5.2.27

Trang 38

command_status 4 Integer Chỉ ra kết quả của submit_sm 4.1.3

sequence_number 4 Integer Có cùng giá trị trong PDU

4.2.23

no_unsuccess 1 Interger Số lượng tin được đệ trình tới

SMSC không thành công

5.2.26

unsuccess_sme(s) Thay dổi Chứa 1 hoặc nhiều địa chỉ của

SME và/hoặc tên danh sách gửi tin không thành công

Bảng3-17

3.5.2.1 Truyền không thành công

Bảng 4-17 Địa chỉ gửi không thành công của SME

thước

chiếu

4.2.5

4.2.6

max = 21

C-Octet String

− SMSC Delivery Receipt Là một báo cáo của một tin đã được đệ trình trước đó

của lệnh submit_sm với tham số registered_delivery được thiết lập Trường

short_message chứa nội dung báo cáo.

− SMSC Delivery Acknowledgement Trường short_message chứa nội dung báo

Tiêu đề	Tìm hiểu Giao Thức SMPP
Người hướng dẫn	Đặng Văn Chuyết
Trường học	Hà Nội University of Science and Technology
Chuyên ngành	Information Technology
Thể loại	Báo cáo thực tập
Năm xuất bản	2004
Thành phố	Hà Nội

Định dạng
Số trang	77
Dung lượng	1,46 MB