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

ウィキペディアから、無料の百科事典
ナビゲーションにジャンプ 検索にジャンプ

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

SMPPは、多くの場合、サードパーティ(ニュース組織などの付加価値サービスプロバイダー)がメッセージをまとめて送信できるようにするために使用されますが、SMSピアリングにも使用される場合があります。SMPPは、 EMSボイスメール通知、セルブロードキャストWAPプッシュメッセージ( MMS通知の配信に使用)などのWAPメッセージ、 USSDメッセージなどのショートメッセージを伝送できます。UMTSIS-95(CDMA)、CDMA2000ANSI-136などの非GSMSMSプロトコルの汎用性とサポートのため(TDMA)およびiDEN 、SMPPは、 SS7ネットワーク の外部でのショートメッセージ交換に最も一般的に使用されるプロトコルです。

歴史

SMPP(Short Message Peer-to-Peer)は元々 、アイルランドの小さな会社であるAldisconによって設計され、後にLogicaに買収されました(2016年以降、Mavenirにいくつかの変更が加えられました)。このプロトコルは元々、SS7テスト機器を使用してメッセージを送信せずにSMSCの機能をテストするために、開発者であるIanJChambersによって作成されました。1999年、LogicaはSMPPをSMPP Developers Forumに正式に引き渡し、後にSMS Forumに名前が変更され、現在は解散しています。元の引き渡し条件の一部として、SMSフォーラムの解散により、SMPPの所有権はMavenirに戻りました。

現在まで、SMPPの開発は中断され、SMSフォーラムは解散しています。SMSフォーラムのWebサイトから:

2007年7月31日-世界のワイヤレス業界の利益のためにSMS(ショートメッセージサービス)を開発、育成、促進することを使命とする非営利組織であるSMSフォーラムは、2007年7月27日までに解散します。

ニュースに添付されたプレスリリースは、サイトがまもなく停止されることを警告するために使用されました。それにもかかわらず、サイトはほとんど機能しており、仕様をダウンロードできました(2012年1月31日現在)。2021年4月12日現在、ウェブサイトの所有者が変更されており、仕様はミラーサイトからのみダウンロードできます。

1995年、ETSIはSMPPプロトコルをテクニカルレポートTR03.39に含めました。[3]

操作

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

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

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

メッセージ交換は、各ピアが送信される各PDUの応答を待機する同期、または他のピアによってスキュー順序で待機および確認応答されることなく複数の要求を発行できる非同期の場合があります。未確認のリクエストの数はウィンドウと呼ばれます。最高のパフォーマンスを得るには、通信側の両方を同じウィンドウサイズで構成する必要があります。

バージョン

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

  • SMPP 3.3は最も古いバージョンです(制限はありますが、まだ広く使用されています)。GSMのみをサポートします。送信されたメッセージごとに即時応答を生成します。
  • SMPP 3.4は、オプションのtag-length-value(TLV)パラメーター、非GSM SMSテクノロジーのサポート、およびトランシーバーのサポート(メッセージを送受信できる単一接続)を追加します。ESMEトランスミッタとSMSC間のSMPP要求および応答PDUの交換は、同期的または非同期的に発生する可能性があります。
  • SMPP5.0はSMPPの最新バージョンです。セルブロードキャスト、スマートフロー制御のサポートを追加します。2019年現在、広く使用されていません。

該当するバージョンは、bindコマンドのinterface_versionパラメーターで渡されます。

PDUフォーマット(バージョン3.4以降)

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

SMPP PDU
PDUヘッダー(必須) PDU本体(オプション)
コマンド
の長さ
コマンド
ID
コマンド
ステータス
シーケンス
番号
PDU本体
4オクテット 長さ=(コマンドの長さの値-4)オクテット

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_smPDUのバイナリエンコーディングの例ですデータは16進オクテット値で単一のダンプとして表示され、その後にそのPDUのヘッダーと本文の内訳が続きます。

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

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

繰り返しになりますが、仕様からsubmit_sm PDUの定義を読み取ると、これがすべて明確になります。

PDUヘッダー

'command_length'、(60)... 00 00 00 3C
'command_id'、(4)... 00 00 00 04
'command_status'、(0)... 00 00 00 00
'sequence_number'、(5)... 00 00 00 05

PDU本体

'service_type'、()... 00
'source_addr_ton'、(2)... 02
'source_addr_ npi '、(8)... 08
'source_addr'、(555)... 35 35 35 00
'dest_addr_ton'、(1)... 01
'dest_addr_ npi '、(1)... 01
'dest_addr'、(555555555)... 35 35 35 35 35 35 35 35 35 00
'esm_class'、(0)... 00
'protocol_id'、(0)... 00
'priority_flag'、(0)... 00
'schedule_delivery_time'、(0)... 00
'validity_period'、(0)... 00
'registered_delivery'、(0)... 00
'replace_if_present_flag'、(0)... 00
'data_coding'、(3)... 03
'sm_default_msg_id'、(0)... 00
'sm_length'、(15)... 0F
'short_message'、(こんにちはウィキペディア)... 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 意味
0 SMSCデフォルトアルファベット(SMPP 3.4)/ MC固有(SMPP 5.0)
1 IA5(CCITT T.50)/ ASCII(ANSI X3.4)
2 オクテット未指定(8ビットバイナリ)
3 ラテン語1(ISO-8859-1
4 オクテット未指定(8ビットバイナリ)
5 JIS(X 0208-1990
6 キリル文字(ISO-8859-5
7 ラテン語/ヘブライ語(ISO-8859-8
8 UCS2(ISO / IEC-10646
9 ピクトグラムエンコーディング
10 ISO-2022-JP(音楽コード)
11 予約済み
12 予約済み
13 拡張漢字JIS(X 0212-1990)
14 KS C 5601
15-191 予約済み
192-207 GSMMWI制御-GSM03.38を参照
208-223 GSMMWI制御-GSM03.38を参照
224-239 予約済み
240-255 GSMメッセージクラス制御-GSM03.38を参照

data_coding=4またはの意味は8SMPP3.3と同じです。1〜15の範囲の他の値は、SMPP3.3で予約されています。残念ながら、data_coding =0が明確にGSM7ビットのデフォルトアルファベットであったSMPP3.3とは異なり、SMPP3.4以降ではGSM7ビットのデフォルトアルファベットがこのリストになく、data_coding=0さまざまなショートメッセージサービスセンターで異なる場合があります。ISO-8859-1ASCII、GSM 7ビットのデフォルトのアルファベット、UTF-8、またはESMEごとに構成可能。を使用する場合data_coding=0、両側(ESMEとSMSC)は、それが同じエンコーディングであると見なす必要があります。それ以外の場合は、を使用しないことをお勧めしますdata_coding=0GSM 7ビットのデフォルトのアルファベット、一部のショートメッセージサービスセンターを使用するのは難しいかもしれませんが必要data_coding=0です、他の例:data_coding=241

広く受け入れられているにもかかわらず、SMPPには多くの問題のある機能があります。

  • data_codingGSM7ビットのデフォルトアルファベットの場合はありません
  • 標準化されていない意味data_coding=0
  • Shift-JISエンコーディングのサポートが不明確
  • submit_sm_respSMPPバージョン間の非互換性
  • SMPP 3.3 SMSC配信レシート、特にメッセージID形式の使用

GSM7ビットのデフォルトアルファベットのdata_codingはありません

SMPP3.3のdata_coding値はGSM03.38に基づいていますが、SMPP 3.4以降、GSM 7ビットアルファベット(GSM 03.38 のdata_coding値はありません。ただし、特にGSMモバイルネットワーク上のSMSCへのSMPP接続では、DCS=0がGSM7ビットアルファベットを示すのが一般的です。

data_coding=0の標準化されていない意味

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

Shift-JISエンコーディングのサポートが不明確

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

SMPPバージョン間のsubmit_sm_respの非互換性

submit_smが失敗すると、SMSCはsubmit_sm_respcommand_statusの値がゼロ以外のaと「空の」message_idを返します。

  • message_id fieldSMPP 3.3は、 「存在しない場合、このフィールドには単一のNULLバイトが含まれている必要がある」と明示的に述べています。PDUの長さは少なくとも17オクテットです。
  • SUBMIT_SM_RESPSMPP 3.4のセクションには、「フィールドにゼロ以外の値が含まれているsubmit_sm_resp場合、PDU本体は返されません」という不幸な注記が含まれています。この場合、PDUの長さは16オクテットです。command_status
  • SMPP 5.0は、それがメッセージmessage_idのタイプC-オクテット文字列の必須パラメータであることを指定するだけsubmit_sm_respです。セクション3.1.1NULL設定によると、「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応答に関する機関を含め、実装において非常に愚かでしたが、bind_transceiver応答など。ベンダーに対して行う推奨事項..上記のように..両方のバリアントを受け入れます。ただし、本体が空の場合とない場合で、NACKedsubmit_sm_respdeliver_sm_respPDUを発行できるようにすることも賢明です。これらの2つのPDUの場合、その空の本体は、ストリームの最後にある単一のNULLオクテットのように見えます。私がNACKedリクエストでダミーボディと呼ぶものを含めるためにこの機能が必要になる理由は、方程式の反対側が、欠落したボディを許容するように実装を変更できないか、変更したくない場合があるためです。(私はAldiscon / LogicaでSMPP仕様の3つのバージョンに取り組み、Openmind Networks用のESMEソリューションを設計しました)

— コーマックロング

SMPP3.3SMSC配信レシートのメッセージID

SMPP 3.3で配達領収書を渡す唯一の方法は、情報をテキスト形式でshort_messageフィールドに入力することです。ただし、テキストの形式はSMPP 3.4の付録Bに記載されていますが、SMPP 3.4はその目的receipted_message_idでTLVを使用する場合があります(使用する必要があります)。message_stateSMPP 3.3では、メッセージIDは最大8文字のC-Octet文字列(16進数)であると規定されていますが(さらに'\ 0'で終了)、SMPP 3.4仕様では、配信レシート形式のidフィールドはC-Octet文字列であると規定されています。 (10進数)最大10文字。これにより、SMPPの実装が2つのグループに分割されます。

  • Delivery Receipt本文のidフィールドに整数メッセージIDの10進表現を使用し、フィールドに整数メッセージIDの16進表現を使用message_idするreceipted_message_id実装
  • message_idパラメータとDeliveryReceipt本文のidフィールドの両方で同じ16進数(または同じ任意の文字列)を使用する実装

ただし、SMPP 3.4仕様では、納品書の形式はSMSCベンダー固有であると規定されているため、仕様に含まれる形式は1つの可能性にすぎません。上記のように、SMPP 3.4receipted_message_idmessage_state使用する場合は、メッセージの結果を伝えるためにTLVを使用する必要があります。

拡張性、互換性、相互運用性

バージョン3.4でTLVパラメータが導入されて以来、SMPPは拡張可能なプロトコルと見なされる可能性があります。可能な限り最高の互換性と相互運用性を実現するために、どの実装でもインターネットのロバストネス原則を適用する必要があります。タスクを実行するために必要な最小限の機能セットを使用する必要があります。そして、目標がコミュニケーションであり、混乱しないことである場合、各実装は、標準でマイナーな不適合を克服する必要があります。

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

あるバージョンのSMPPに適用できる情報は、多くの場合、別のバージョンのSMPPにあります。たとえば、SMPP 3.4の場合は、上記のSMPP3.3の配信レシートの唯一のメカニズムを説明しています。

セキュリティ

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

も参照してください

参照

  1. ^ 「GSM03.40ショートメッセージサービス(SMS)の技術的実現」 3GPP、2003-12-03
  2. ^ 「ショートメッセージピアツーピアプロトコル仕様v5.0」 (PDF)
  3. ^ フリートヘルムヒレブランド(2010)。ショートメッセージサービス(SMS):パーソナルグローバルテキストメッセージングの作成ワイリーp。112. ISBN 978-0-470-68865-6
  4. ^ ニールクロフト(2012)。「フォレンジックについて:サイレントSMS攻撃」IEEE土井10.1109/ISSA.2012.6320454ISSN2330-9881_  {{cite journal}}引用ジャーナルには|journal=ヘルプ)が必要です
  5. ^ A.Henry-Labordère; ヴィンセントジョナック(2004)。モバイルネットワークでのSMSとMMSのインターワーキングアーテックハウスpp。137–138。ISBN 1-58053-890-8
  6. ^ 「セキュアショートメッセージピアツーピアプロトコル」、International Journal of Electronic Commerce Studies、2012年

外部リンク