ショートメッセージ ピアツーピア

通信業界におけるショートメッセージピアツーピア（SMPP ）は、外部ショートメッセージエンティティ（ESME）、ルーティングエンティティ（RE）、およびSMSC間のショートメッセージ^[1]データの転送のための柔軟なデータ通信インターフェースを提供するために設計されたオープンな業界標準プロトコルです。^[2]

SMPP は、多くの場合、第三者 (ニュース組織などの付加価値サービス プロバイダーなど) がメッセージを一括して送信できるようにするために使われますが、SMS ピアリングにも使われることがあります。SMPP は、 EMS、ボイスメール通知、セル ブロードキャスト、WAPプッシュメッセージ ( MMS通知の配信に使用)を含むWAP メッセージ、 USSDメッセージなどのショートメッセージを伝送できます。汎用性が高く、 UMTS、IS-95 (CDMA)、CDMA2000、ANSI-136 (TDMA)、iDENなどの非GSM SMS プロトコルをサポートしているため、 SMPP はSS7ネットワーク外でのショート メッセージ交換に最も一般的に使われるプロトコルです。

SMPP (Short Message Peer-to-Peer) は、もともとアイルランドの小さな会社であるAldisconによって設計され、後にLogicaに買収されました(2016 年以降は、いくつかの変更を経てMavenirに買収されました)。このプロトコルは、もともと開発者の Ian J Chambers によって、メッセージを送信するために SS7 テスト機器を使用せずに SMSCの機能をテストするために作成されました。

1995年にETSIはSMPPプロトコルを技術報告書TR 03.39に含めました。^[3]

1999 年に、Logica は SMPP を正式に SMPP 開発者フォーラムに引き渡しました。このフォーラムは後に SMS フォーラムに改名されました。

SMSフォーラムは2007年に解散し、次のような発表がありました。「SMSフォーラムは、世界のワイヤレス業界の利益のためにSMS（ショートメッセージサービス）を開発、育成、促進することを使命とする非営利団体であり、2007年7月27日までに解散します。」^[4] 当初の譲渡条件の一部として、SMPPの所有権はMavenirに戻りました。

SMPP は、名前に「ピアツーピア」とありますが、クライアント サーバー モデルの操作を使用します。ショート メッセージ サービス センター (SMSC) は通常、ESME からの接続を待機するサーバーとして機能します。SMPP を SMS ピアリングに使用する場合、送信側の MC は通常、クライアントとして機能します。

このプロトコルは、 OSIレイヤー4（TCPセッションまたはX.25 SVC3）接続を介して交換される要求/応答PDU（プロトコルデータユニット、またはパケット）のペアに基づいています。 ^[5] TCP経由で動作する場合、SMPPにIANAによって割り当てられた既知のポートは2775ですが、メッセージング環境では複数の任意のポート番号が使用されることがよくあります。

メッセージを交換する前に、bind コマンドを送信して確認応答を得る必要があります。bind コマンドは、どの方向にメッセージを送信できるかを決定します。bind_transmitter はクライアントがサーバーにメッセージを送信することのみを許可し、bind_receiver はクライアントがメッセージを受信することのみを意味し、bind_transceiver (SMPP 3.4 で導入) は双方向のメッセージ転送を許可します。^[6] bind コマンドでは、ESME は system_id、system_type、および password を使用して自身を識別します。ESME アドレスを格納するために設計された address_range フィールドは通常空のままです。bind コマンドには、使用する SMPP プロトコルのバージョンを指定する interface_version パラメータが含まれています。

メッセージ交換は、各ピアが送信されている各 PDU に対する応答を待機する同期方式と、複数の要求を待機せずに発行し、他のピアによって斜めの順序で確認応答される非同期方式があります。確認応答されていない要求の数はウィンドウと呼ばれます。最高のパフォーマンスを得るには、通信する両側で同じウィンドウ サイズを設定する必要があります。

SMPP 標準は、時間の経過とともに進化してきました。最も一般的に使用される SMPP のバージョンは次のとおりです。

• SMPP 3.3 は最も古く使用されているバージョンです (制限があるにもかかわらず、現在でも広く使用されています)。GSM のみをサポートします。送信されたメッセージごとに即時応答を生成します。
• SMPP 3.4 では、オプションのタグ、長さ、値(TLV) パラメータ、非 GSM SMS テクノロジのサポート、トランシーバサポート (メッセージを送受信できる単一の接続) が追加されています。ESME トランスミッタと SMSC 間の SMPP 要求および応答 PDU の交換は、同期または非同期で発生する場合があります。
• SMPP 5.0 は SMPP の最新バージョンであり、セル ブロードキャスト、スマート フロー制御のサポートが追加されています。2023 年現在^{[アップデート]}、広く使用されていません。

適用可能なバージョンは、bind コマンドの interface_version パラメータで渡されます。

SMPP PDU は効率性を高めるためにバイナリ エンコードされています。ヘッダーで始まり、その後に本体が続く場合があります。

各 PDU はヘッダーで始まります。ヘッダーは 4 つのフィールドで構成され、各フィールドの長さは 4 オクテットです。

command_length

PDUの全体の長さをオクテット単位で表したもの（command_lengthフィールド自体を含む）。各PDUには16オクテットのヘッダーが含まれている必要があるため、16以上である必要があります。

command_id

SMPP 操作 (またはコマンド) を識別します。最上位ビットがクリアされている場合、これは要求操作です。それ以外の場合は応答です。

command_status

リクエストでは常に0の値を持ち、レスポンスでは操作の結果に関する情報を持ちます。

sequence_number

SMPP セッション内で要求と応答を関連付けるために使用され、非同期通信を可能にします (スライディング ウィンドウ方式を使用)

SMPP のすべての数値フィールドはビッグ エンディアン順序を使用します。つまり、最初のオクテットが最上位バイト (MSB) になります。

これは、60 オクテットのsubmit_sm PDUのバイナリ エンコードの例です。データは 16 進オクテット値で単一のダンプとして表示され、その後にその PDU のヘッダーと本体の内訳が続きます。

エンコードがフィールド定義ごとにどのように一致するかを理解するには、SMPP 仕様の submit_sm PDU の定義と比較するのが最適です。

値の内訳は、括弧内に小数点が示され、その後に 16 進数値が示されます。1 つまたは複数の 16 進オクテットが付加されている場合は、指定されたフィールド サイズで 1 つ以上のオクテット エンコーディングが使用されているためです。

繰り返しになりますが、仕様から submit_sm PDU の定義を読むと、すべてがより明確になります。

'コマンド長'、(60) ... 00 00 00 3C
'コマンドID', (4) ... 00 00 00 04
'コマンドステータス'、(0) ... 00 00 00 00
'シーケンス番号'、(5) ... 00 00 00 05

'サービスタイプ', () ... 00
'ソースアドレス'、(2) ... 02
'source_addr_npi '、(8) ... 08
'ソースアドレス'、(555) ... 35 35 35 00
'宛先アドレス', (1) ... 01
'dest_addr_npi '、(1) ... 01
'宛先アドレス', (555555555) ... 35 35 35 35 35 35 35 35 35 00
'esm_class', (0) ... 00
'プロトコルID', (0) ... 00
'優先度フラグ'、(0) ... 00
'配送スケジュール', (0) ... 00
'有効期間'、(0) ... 00
'登録配送'、(0) ... 00
'存在する場合は置き換える'、(0) ... 00
'データコーディング'、(3) ... 03
'sm_default_msg_id'、(0) ... 00
'sm_length'、(15) ... 0F
'short_message'、（こんにちはWikipedia）... 48 65 6C 6C 6F 20 57 69 6B 69 70 65 64 69 61

short_message フィールドのテキストは、data_coding と一致している必要があることに注意してください。data_coding が 8 (UCS2) の場合、テキストは UCS-2BE (またはその拡張であるUTF-16BE ) である必要があります。data_coding が 7 ビット エンコーディングを示している場合、各セプテットは short_message フィールドの個別のオクテットに格納されます (最上位ビットは 0 に設定されます)。SMPP 3.3 の data_coding は、GSM 03.38の TP-DCS 値を正確にコピーしたため、GSM 7 ビット デフォルト アルファベット、UCS2、またはバイナリ メッセージにのみ適しています。SMPP 3.4 では、data_coding 値の新しいリストが導入されました。

data_coding=4またはの意味は、8SMPP 3.3 と同じです。1 ～ 15 の範囲のその他の値は、SMPP 3.3 で予約されています。残念ながら、data_coding=0 が明確に GSM 7 ビットのデフォルト アルファベットであった SMPP 3.3 とは異なり、SMPP 3.4 以降では GSM 7 ビットのデフォルト アルファベットがこのリストに存在せず、data_coding=0さまざまなショート メッセージ サービス センターごとに異なる場合があります。ISO -8859-1、ASCII、GSM 7 ビットのデフォルト アルファベット、UTF-8の場合があり、ESME ごとに構成することもできます。 を使用する場合はdata_coding=0、両側 (ESME と SMSC) で必ずこれを同じエンコーディングとして扱う必要があります。それ以外の場合は、 を使用しない方がよいでしょうdata_coding=0。GSM 7 ビットのデフォルト アルファベットの使用は難しい場合があります。一部のショート メッセージ サービス センターでは が必要でdata_coding=0、他のセンターでは などが必要ですdata_coding=241。

SMPP は広く受け入れられているものの、次のような問題のある特徴がいくつかあります。

• data_codingGSM 7ビットデフォルトアルファベットの場合はいいえ
• 標準化されていない意味data_coding=0
• Shift-JISエンコードのサポートが不明
• submit_sm_respSMPPバージョン間の非互換性
• SMPP 3.3 SMSC配信確認書の使用、特にその中のメッセージID形式

SMPP 3.3 の data_coding 値はGSM 03.38に基づいていますが、SMPP 3.4 以降では GSM 7 ビット アルファベット ( GSM 03.38 ) の data_coding 値はありません。ただし、DCS=0 は、特に GSM モバイル ネットワーク上の SMSC への SMPP 接続の場合、GSM 7 ビット アルファベットを示すのが一般的です。7 ビット アルファベットが GSM のようにパックされて 140 オクテットで 160 文字を送信できるのか、それとも各 7 ビット文字が 1 オクテット全体を占めるのか (ASCII のように上位ビットが 0 に設定される) も不明瞭です。

SMPP 3.4 および 5.0 によれば、これはdata_coding=0「SMSC デフォルト アルファベット」を意味します。実際にどのエンコードになるかは、SMSC のタイプとその構成によって異なります。

CDMA 標準 C.R1001 のエンコードの 1 つは、日本語に使用されるShift-JISです。SMPP 3.4 および 5.0 では、日本語に 3 つのエンコード (JIS、ISO-2022-JP、拡張漢字 JIS) が指定されていますが、いずれも CDMA MSG_ENCODING 00101 と同じではありません。SMPP では、Shift-JIS でメッセージを伝送するために、ピクトグラム エンコード (data_coding=9) が使用されているようです。

submit_sm が失敗すると、SMSC はsubmit_sm_respcommand_status の値がゼロ以外で、message_id が「空」であるメッセージを返します。

• SMPP 3.3 では、message_id field「このフィールドが存在しない場合は、1 つの NULL バイトを含める必要があります」と明示的に規定されています。PDU の長さは少なくとも 17 オクテットです。
• SUBMIT_SM_RESPSMPP 3.4 のセクションには、「フィールドにゼロ以外の値が含まれているsubmit_sm_resp場合、PDU 本体は返されません」という残念な注意事項がありますcommand_status。この場合、PDU の長さは 16 オクテットになります。
• message_idSMPP 5.0 では、メッセージの C オクテット文字列タイプの必須パラメータが指定されているだけですsubmit_sm_resp。セクション 3.1.1 NULL 設定によると、「NULL 文字列」は 0x00 としてエンコードされます。PDU の長さは少なくとも 17 オクテットです。

最高の互換性を確保するには、submit_sm_resp通信に使用される SMPP 標準のバージョンに関係なく、すべての SMPP 実装で、否定の両方のバリエーションを受け入れる必要があります。

エラー シナリオの本来の意図は、PDU 応答で本文が返されないことでした。これは、すべての Aldiscon/Logica SMSC および他のほとんどのベンダーで示された標準的な動作でした。SMPP 3.4 が WAP フォーラムで取り上げられたとき、NACK された応答に本文を含めるかどうかについていくつかの説明が求められ、セクションsubmit_smやbind_transceiverセクションを含む仕様のいくつかの場所でこれを明確にするための措置が講じられました。実行すべきだったのは、最終的に V5.0 で追加した説明、つまりエラー応答に本文を含めるべきではないという説明を追加することでした。一部のベンダーは、拒否された応答には本文を含めbind_transmitterながら、応答には含めないなど、実装において非常に愚かでした。ベンダーへの推奨事項は、上記のように、両方のバリアントを受け入れることです。ただし、空の本文の有無にかかわらず、NACK された PDUおよびPDU をbind_transceiver発行できるようにすることも賢明です。これら 2 つの PDU の場合、その空の本文は、ストリームの最後にある単一の NULL オクテットのように見えます。 NACK されたリクエストにダミーボディと呼ばれるものを含めるこの機能が必要な理由は、方程式の反対側では、ボディの欠落を許容するために実装を変更できないか、変更したくない可能性があるためです。(私は Aldiscon/Logica で SMPP 仕様の 3 つのバージョンに取り組み、Openmind Networks の ESME ソリューションを設計しました)submit_sm_respdeliver_sm_resp

— コーマック・ロング^{[この引用には出典が必要です]}

SMPP 3.3 で配信確認を渡す唯一の方法は、フィールドにテキスト形式で情報を入力することですshort_message。ただし、テキストの形式は SMPP 3.4 の付録 B で説明されていますが、SMPP 3.4 ではこの目的で TLV を使用できます (使用する必要があります) receipted_message_id。SMPP message_state3.3 では、メッセージ ID は最大 8 文字 (末尾の '\0' を含む) の C オクテット文字列 (16 進数) であると規定されていますが、SMPP 3.4 仕様では、配信確認形式の ID フィールドは最大 10 文字の C オクテット文字列 (10 進数) であると規定されています。これにより、SMPP 実装は 2 つのグループに分かれます。

• 配信受領書本体のIDフィールドに整数メッセージIDの10進表現を使用し、フィールドmessage_idとreceipted_message_idフィールドに整数メッセージIDの16進表現を使用する実装
• message_idパラメータと配信受領書本体のIDフィールドの両方に同じ16進数（または同じ任意の文字列）を使用する実装

ただし、SMPP 3.4 仕様では、配信受領書の形式は SMSC ベンダー固有であると規定されているため、仕様に含まれる形式は単なる 1 つの可能性にすぎません。前述のように、SMPP 3.4 を使用する場合はreceipted_message_id、message_stateメッセージの結果を伝達するために TLV を使用する必要があります。

バージョン 3.4 で TLV パラメータが導入されて以来、SMPP は拡張可能なプロトコルとみなされるようになりました。互換性と相互運用性を可能な限り高めるためには、実装でインターネットの堅牢性の原則を適用する必要があります。「送信するものは慎重に、受信するものは寛容に」。タスクの達成に必要な最小限の機能セットを使用する必要があります。また、目的がコミュニケーションであり、議論ではない場合、各実装では標準との軽微な不適合を克服する必要があります。

• generic_nack認識されない SMPP コマンドに対してはで応答しますcommand_status=3が、通信は停止しません。
• 認識されない、予期しない、またはサポートされていない TLV パラメータは無視します。
• PDU の境界は常に PDU のcommand_lengthフィールドによって示されます。メッセージ フィールドはいずれも PDU の末尾を超えてはなりません。フィールドが適切に終了していない場合は、PDU の末尾で切り捨てられたものとして扱われ、それ以降の PDU には影響しません。

SMPP の 1 つのバージョンに適用可能な情報は、多くの場合、別のバージョンの SMPP でも見つかります。たとえば、SMPP 3.4 の場合、上記の SMPP 3.3 の配信確認の唯一のメカニズムが説明されています。

SMPPプロトコルはクリアテキストバイナリプロトコルに基づいて設計されており、SMS経由のワンタイムパスワードなどの潜在的に機密性の高い情報に使用する場合は考慮する必要があります。ただし、必要に応じてSSL/TLS経由のSMPPの実装もあります。^[7]

• ユニバーサル コンピュータ プロトコル/外部マシン インターフェイス (UCP/EMI)
• メッセージ配信用コンピュータ インターフェイス (CIMD)
• リッチコミュニケーションサービス

• ショートメッセージ ピアツーピア プロトコル仕様 v3.3
• ショートメッセージ ピアツーピア プロトコル仕様 v3.4
• ショートメッセージ ピアツーピア プロトコル仕様 v5.0
• GSM / UMTS 向け SMPP v3.4 プロトコル実装ガイド
• SMPP v3.4 WAP 実装ガイド
• Javaで実装されたSMPP
• SMPP ワイヤーシャーク