SMPPとは？SMSのセッションプロトコル
専門用語に頼らずにSMPPを解説します。バインド、ウィンドウ、PDU、配信レシートの経路、そして大量送信時にセッションの形が重要になる理由。
SMPPは、プラットフォームが永続的なセッションを通じてメッセージセンターとショートメッセージをやり取りするためのプロトコルです。バインドで方向を宣言し、セッションはスループットのウィンドウを持ち、配信レシートはPDUとして返ってきます。リクエスト／レスポンス型のAPIではありません。
主な情報
- SMPPは、バインドの方向を宣言した永続的なセッションです。
- バインドには、スループットの割り当てと、未応答リクエストのウィンドウがあります。
- PDUは、16バイトのヘッダーとコマンド固有のボディで構成されます。
- 配信レシートはセッション上で非同期に届きます。メッセージIDで照合してください。
このページの内容
呼び出しではなく、セッション
SMPPは、自社のプラットフォームとメッセージセンターの間で接続を開いたままにします。プラットフォームは一度だけ認証し、何をしたいかを宣言したうえで、同じセッション上でメッセージを送信し、イベントを受信します。メッセージセンターは、配信レシートや着信メッセージを送るために新しいリクエストを待ちません。報告すべきことがあれば、PDUをプッシュします。
この形は、途切れなく続くメッセージの流れに適しています。セッションの状態がすでに確立されており、配信レシートのチャネルもすでに開いているため、メッセージごとのオーバーヘッドは小さくなります。一方で、HTTPクライアントにはない状態をクライアント側で管理する必要があります。バインドの状態、処理中のウィンドウ、キープアライブのタイミング、再接続の挙動です。
バインドで方向を宣言する
バインドとは、認証済みのセッションに方向を加えたものです。トランスミッターバインドはメッセージを送信します。レシーバーバインドは、端末発信（MO）メッセージと配信レシートを受信します。トランシーバーバインドは、1つのセッションでその両方を行います。プロバイダーはバインドごとに認証情報を発行し、開けるバインドの数を制限することがあります。
規模を拡大するときは、1つのバインドを割り当て以上に押し込むのではなく、バインドを追加してください。1つのバインドには、1つのスループット割り当てと、1つの未応答リクエストのウィンドウがあります。ピーク時にそれ以上が必要なら、追加のバインドを依頼してトラフィックを分散します。1つのバインドでウィンドウを超えて送信し続けると、スロットリング、タイムアウト、再試行が発生します。これらはネットワーク障害のように見えますが、原因はクライアント側にあります。
バインド、送信、配信レシート
- アプリケーション（ESME）
- bind_transceiver セッションを開く
- SMSC
- submit_sm_resp 配信受付済み
- 配信確認
テキストによる説明
アプリケーションがバインドを開き、メッセージセンターが応答します。アプリケーションはsubmit_smでショートメッセージを送信し、メッセージID付きのsubmit_sm_respを受け取ります。その後、メッセージセンターが配信レシートを含むdeliver_sm PDUを送信します。アプリケーションはdeliver_sm_respでこれに応答します。作業が終わると、unbindでセッションを閉じます。
ウィンドウは守るべき取り決め
ウィンドウとは、クライアントが応答を待たずに未応答のまま保持できるリクエストの数です。目安ではありません。ウィンドウを超えて送信すると、メッセージセンターはスロットリングをかけます。同じペースで再試行を続ければ、キューは膨らみます。送信ごとに応答コードを読み、スロットリングされたら速度を落とし、次のバーストの前にウィンドウが空くのを待ってください。
キープアライブのトラフィックがセッションを維持します。enquire_linkを一度も送らないクライアントは、最初の送信が失敗するまで、切れた接続に留まり続けることがあります。切断のたびに即座に再接続するクライアントは、プロバイダーに過剰な負荷をかけることがあります。バックオフを使い、再接続の頻度に上限を設け、バインドの停止時間がトラフィックの許容範囲を超えたらアラートを出してください。
1つのPDUをフィールドごとに
- command_length
- 53
- command_id
- 0x00000004
- command_status
- 0x00000000
- sequence_number
- 1
- service_type
- source_addr_ton
- 1
- source_addr_npi
- 1
- source_addr
- 12345
- dest_addr_ton
- 1
- dest_addr_npi
- 1
- destination_addr
- 15551234567
- esm_class
- 0x00
- protocol_id
- 0x00
- priority_flag
- 0
- schedule_delivery_time
- validity_period
- registered_delivery
- 0x01
- replace_if_present_flag
- 0x00
- data_coding
- 0x00
- sm_default_msg_id
- 0x00
- sm_length
- 4
- short_message
- 54657374
- テキスト
- Test
テキストによる説明
すべてのPDUは、4バイトのコマンド長、4バイトのコマンドID、4バイトのコマンドステータス、4バイトのシーケンス番号で始まります。その後にボディが続きます。submit_smの場合、ボディには送信元アドレスと宛先アドレス、ショートメッセージ、データ符号化方式、registered delivery（配信レシート要求）フラグが含まれます。オプションパラメーターは、TLV（タグ・長さ・値）フィールドとして送られます。
あるメッセージの一日
クライアントはトランシーバーバインドを開き、バインド応答を読み取ります。メッセージを送信し、応答に含まれるメッセージIDを保存します。メッセージセンターは、メッセージを接続先ネットワークへルーティングします。数分後、配信レシートを含むdeliver_sm PDUが届きます。そこには元のメッセージID、状態、そして多くの場合ネットワークコードが含まれます。クライアントは配信レシートに応答し、その状態を自身の記録と突き合わせます。
各ステップには、それぞれ失敗のパターンがあります。バインドは、認証情報の誤りやインターフェースバージョンの不一致で拒否されることがあります。送信は、スロットリングされることも、拒否されることも、受け付けられた後に配信レシートで失敗となることもあります。配信レシートが、コードの有効期限が切れた後に届くこともあります。クライアントは、メッセージIDを保存し、遅れて届いた配信レシートも受け付け、ユーザーが何をしたかについてはアプリケーション自身の状態を信頼できる情報源とするように設計してください。
ルートをデバッグする前に、配信レシートをデコードする
配信レシートをSMPPおよびDLRデコーダーに貼り付けて、各フィールドを読んでください。メッセージID、状態、完了日時、エラーコードを確認します。状態がDELIVRDでない場合、エラーコードをプロバイダーのコード表と照らし合わせて読むと、番号、端末、ネットワークのどれがメッセージを拒否したのかを判断する手がかりになります。プロバイダーにルートの変更を依頼する前に、これを行ってください。
配信レシートとデバッグ
配信レシートは非同期です。deliver_sm PDUとしてセッション上に届き、その形式はメッセージセンターによって異なります。新しい実装では、状態をmessage_state TLVフィールドで伝えます。古い実装では、id、stat、errなどのキーと値のペアを含むテキスト形式の配信レシートを、short_messageフィールドに入れます。どちらか一方を前提とせず、両方を解析してください。
到着順ではなく、メッセージIDで照合してください。1秒違いで送信した2つのメッセージの配信レシートが逆の順序で返ってくることがあり、再試行によって重複が生じることもあります。送信時にIDを保存し、配信レシートが届いたらレコードを更新し、同じIDに対する2通目の配信レシートは、状態がより新しい場合を除いて無視してください。接続ガイドでは、これを運用手順として整理しています。
理解度チェック
-
再試行の頻度を上げるよりも、バインドを追加するほうが効果的なのはなぜですか？
1つのバインドには1つのウィンドウがあります。バインドを追加すれば容量が増えますが、満杯のウィンドウに対して再試行しても、キューと遅延が増えるだけです。
-
メッセージIDはどこから来ますか？
メッセージセンターがsubmit_sm_respで返します。それを保存し、後から届く配信レシートをそのIDで照合してください。
-
配信済みを示す配信レシートは、何を証明しますか？
ネットワークがメッセージを受け付け、端末までの経路に配信したことです。人がそれを読んだことは証明しません。
回答は要求したときに表示されます。採点、保存、送信は一切行いません。
よくある質問
始めるのにSMPPは必要ですか？
バインドとは何ですか？
PDUとは何ですか？
SMPPをパブリックインターネット上で使えますか？
長いメッセージはどのように扱われますか？
関連
- SMPPとHTTPによる接続
バインド、ウィンドウ、配信レポートを壊さずにテストルートを本番へ移行します。バインド、スループット、キープアライブ、エンコーディング、コールバック、障害対応を扱います。
- RFQ・RFPテンプレートパック
SMS卸売、eSIMとデータ、IoT、中国向け接続の各見積依頼に必要な項目一覧と、そのままRFQとして送信できるオンラインチェックリストです。
- ルートテストのサンプルレポート
ルートテストのレポートを匿名化した静的サンプルです。ルートテストで確認する項目、失敗の読み方、ルートの見直しにつながる条件を示します。
実践する
トラフィック、接続先、必要な測定内容をお知らせください。次のステップをご案内します。