tìm hiểu giao thức smpp

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ết
Sinh viên: Nguyễn Ngọc Bảo
Lớp: KS2 K16
Hà Nội - 2004
1
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
2
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
3
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
4
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

5
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
6
CÁC TỪ VIẾT TẮT
ACK Acknowledgement
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 ()
WCMP Wireless Control Message Protocol
WDP Wireless Datagram Protocol
7
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.
8
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:
9
− 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.
1.2.1. Lệnh Outbind
Mục đích của lệnh outbind là cho phép SMSC ra hiệu cho một ESME khởi tạo yêu cầu
bind_receiver tới SMSC. Để ví dụ, khi SMSC có các tin chưa giải quyết xong mà cần gửi cho
ESME. Một Outbind SMPP session giữa một SMSC và một ESME có thể được khởi tạo bởi
SMSC trước khi thiết lập một kết nối mạng với ESME. Một khi một kết nối mạng được thiết
lập, SMSC bind tới ESME bằng việc phát một yêu cầu outbind. ESME phản hồi bằng yêu cầu
bind_receiver, SMSC sẽ trả lời bằng bind_receiver_resp. Nếu ESME không chấp nhận
outbind session (ví dụ: lỗi system_id, hoặc sai mật khẩu,…) thì ESME ngắt kết nối mạng.
Hình 1-3. Sơ đồ tuần tự của lệnh outbind
ESME
ESME
SMSC
SMSC
outbind
bind_receiver
bind_receiver_res
p
deliver_sm
deliver_sm_resp
10
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.
Tên
Trạng thái của
SMPP Session
Phát bởi
ESME
Phát bởi
SMSC

bind_transmitter OPEN Yes No
bind_transmitter_resp OPEN No Yes
bind_receiver OPEN Yes No
bind_receiver_resp OPEN No Yes
bind_transceiver OPEN Yes No
bind_transceiver_resp OPEN No Yes
outbind OPEN No Yes
unbind BOUND_TX
BOUND_RX
BOUND_TRX
Yes
Yes
Yes
Yes
Yes
Yes
unbind_resp BOUND_TX
BOUND_RX
BOUND_TRX
Yes
Yes
Yes
Yes
Yes
Yes
submit_sm BOUND_TX
BOUND_TRX
Yes
Yes
No

No
submit_sm_resp BOUND_TX
BOUND_TRX
No
No
Yes
Yes
submit_sm_multi BOUND_TX
BOUND_TRX
Yes
Yes
No
No
submit_sm_multi_resp BOUND_TX
BOUND_TRX
No
No
Yes
Yes
data_sm BOUND_TX
BOUND_RX
BOUND_TRX
Yes
Yes
Yes
Yes
Yes
Yes
data_sm_resp BOUND_TX
BOUND_RX

BOUND_TRX
Yes
Yes
Yes
Yes
Yes
Yes
deliver_sm BOUND_RX
BOUND_TRX
No
No
Yes
Yes
deliver_sm_resp BOUND_RX
BOUND_TRX
Yes
Yes
No
No
query_sm BOUND_RX
BOUND_TRX
Yes
Yes
No
No
query_sm_resp BOUND_RX
BOUND_TRX
No
No
Yes

Yes
11
cancel_sm BOUND_RX
BOUND_TRX
Yes
Yes
No
No
cancel_sm_resp BOUND_RX
BOUND_TRX
No
No
Yes
Yes
replace_sm BOUND_TX Yes No
replace_sm_resp BOUND_TX No Yes
enquire_link BOUND_TX
BOUND_RX
BOUND_TRX
Yes
Yes
Yes
Yes
Yes
Yes
enquire_link_resp BOUND_TX
BOUND_RX
BOUND_TRX
Yes
Yes

Yes
Yes
Yes
Yes
alert_notification BOUND_RX
BOUND_TRX
No
No
Yes
Yes
generic_nack BOUND_TX
BOUND_RX
BOUND_TRX
Yes
Yes
Yes
Yes
Yes
Yes
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

12
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.
13
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.
ESME
ESME
SMSC
SMSC
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)
14
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.
ESME
ESME
SMSC
SMSC
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)
15
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.
ESME
ESME
SMSC
SMSC
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)
16
− 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.
17
Hình 1-8. Sơ đồ tuần tự cho chế độ lưu trữ và chuyển tiếp
1.10.2. Chế độ Datagram
Chế độ Datagram phỏng theo datagram ở trong các giao thức truyền thông khác như

truyền UDP datagram và không lưu trữ giống như trong chế độ Store and Forward. Trong chế
độ này các thực thể gửi (ví dụ: ESME) sẽ không nhận bất kỳ thông báo nhận nào. Các chức
năng điển hình sử dụng chế độ này là nhật ký truyền. Chế độ này được sử dụng cho các ứng
dụng cần tốc độ cao, không cần đến các chức năng lưu trữ và cố gắng gửi. SMPP hỗ trợ chế
độ 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.
ESME SMSC MS
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
ACK
Network Delivery Attempt
NACK
Network Delivery Attempt
ACK
deliver_sm (esm_class
= SMSC Delivery Receipt
deliver_sm_resp
Wireless Network ProtocolSMPP

18
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.
ESME SMSC MS
binding_transceiver
binding_transceiver_resp
data_sm
(esm_class = datagram)
data_sm_resp
Network Delivery Attempt
ACK
Wireless Network ProtocolSMPP
ESME SMSC MS
binding_transmitter
binding_transmitter_resp
data_sm
(esm_class = forward)

data_sm_resp
Network Delivery Attempt
ACK
Wireless Network ProtocolSMPP
19
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.
− esm_class
− message_state
− network_error_code
− receipted_message_id
1.11.2. Intermediate Notification
Intermediate Notification là một loại tin đặc biệt mà SMSC có thể gửi tới ESME để một
mobile ngắt việc truyền tin. Nó cung cấp một trạng thái trung gian của tin đang có gắng
truyền. Các trường hợp điển hình được sử dụng hiện này:
− 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.
1.11.5. Conversation Abort
Loại tin này được sử dụng để tương tác với các dịch vụ thoại được định nghĩa trong
CDMA. Nó được sử dụng để thông báo bỏ qua một cuộc nói chuyện. Nó có thể được chứa
trong deliver_sm hoặc data_sm. Loại tin này không được hỗ trợ trong hầu hết các mạng.
20
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
dấu hiệu kết thúc.
C-Octet String (Decimal). Là một chuỗi các ký tự, mỗi ký tự mô tả các số hệ
mười từ 0 đến 9, kết thúc bằng ký tự NULL.
C-Octet String (Hex). Là một chuỗi ký tự ASCII, mỗi ký tự mô tả các số theo hệ
hexa từ 0 đến F, kết thúc bằng ký từ NULL.
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ố
Kích thước
(octet)
Kiểu Mô tả
4 Integer Kích thước cố định là 4 octet, tương đương là số 32 bit
Thay đổi
1 đến 16

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ự NULL
Thay đổ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
SMPP PDU
PDU Header (bắt buộc) PDU Body (tùy chọn)
command
length
command
id
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.
21
2.2.1. Cách bố trí của PDU
Bảng 2-3. Mô tả định dạng của PDU
H
E

A
D
E
R
Tên trường Kích
thước
Kiểu Mô tả
command_length 4 Integer Chỉ ra kích thước tổng cộng của PDU, tính
bằng octet.
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 - 0x000001FF
Mỗ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 - 0x800001FF
Chú ý: 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:
0x00000001 - 0x7FFFFFFF.
B
O
D
Y
Các tham số
bắt buộc
Thay đổi hỗn tạp Các tham số bắt buộc tương ứng với
trường command_id, xem chi tiết trong
phần 4.
Các tham số
tùy chọn
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):
22
00 00 00 2F 00 00 00 02 00 00 00 00 00 00 00 01
53 4D 50 50 33 54 45 53 54 00 73 65 63 72 65 74
30 38 00 53 55 42 4D 49 54 31 00 00 01 01 00
Header được phân tích như sau:

00 00 00 2F command_length 0x0000002F
00 00 00 02 command_id 0x00000002 (bind_transmitter)
00 00 00 00 command_status 0x00000000
00 00 00 01 sequence_number 0x00000001
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
Tên tham số Kích thước Kiểu Mô tả
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.
23
− 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
24
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.
3.1.1. Cú pháp “BIND_TRANSMITTER”

Bảng 3-1. Định dạng của PDU bind_transmitter.
H
E
A
D
E
R
Tên trường Kích
thước
Kiểu Mô tả Tham
chiếu
command_length
4 Integer Kích thước của PDU 4.1.1
command_id
4 Integer Mã lệnh 4.1.2
command_status
4 Integer Không sử dụng cho PDU
bind_transmitter. Phải được
thiết lập là NULL
4.1.3
sequence_number
a
4 Integer Thiết lập mã số tuần tự duy
nhất tương ứng với
bind_transmitter_resp
4.1.4
B
O
D
Y

system_id
b
Thay đổi
max = 16
C-Octet String Định danh của ESME yêu cầu
bind như transmitter với
SMSC.
4.2.1
password
c
Thay đổi
max = 9
C-Octet String Mật khẩu dùng để ESME
chứng thực với SMSC
4.2.2
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
SMPP
4.2.4
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
25