1

これらすべてのETSIGSMドキュメントに基づいてSMSPDUを処理するためのコードを書いています。私が質問する必要があることが1つあります。PDUには、ユーザーデータの長さフィールドとそれに続くユーザーデータが含まれます。GSM 03.40によると、UDLフィールドは、非圧縮のGSMデフォルトアルファベットが使用されている場合のユーザーデータのセプテットの数です。ただし、データが圧縮されている場合、UDLはユーザーデータのオクテット数であるとも言われています。

引用符を参照してください：

TPユーザーデータがGSM7ビットのデフォルトのアルファベットを使用してコーディングされている場合、[TPユーザーデータの長さ]フィールドは、後続の[TPユーザーデータ]フィールド内のセプテットの数を整数で表します。

[...]

TPユーザーデータが圧縮GSM7ビットデフォルトアルファベットまたは圧縮8ビットデータまたは圧縮UCS2[24]データを使用してコーディングされている場合、TPユーザーデータ長フィールドは、TPユーザーデータフィールド内の圧縮後のオクテット数の整数表現を提供します。フォローする。

問題は、7ビットデータが圧縮され、圧縮されたユーザーデータのオクテット数が7の倍数である場合、最後のオクテットの最後の7ビットがフィルビットであるか実数文字であるかがわからないことです。つまり、圧縮がオンの場合、7オクテットには7ビット文字または8文字の7ビット文字を含めることができます。また、UDLフィールドがオクテットの数である場合、それらの7つのオクテットに7文字または8文字が含まれているかどうかをどのように知ることができますか？UDLにセプテットの数が含まれていれば、すべてが明確になりますよね？それで、私はドキュメントを誤解しましたか、それともそれは本当にこのように機能しますか？

誰かがそれが実際にどのように機能するかを私に説明してもらえますか？前もって感謝します！

4

2 に答える 2

2

既にお気づきのように、MMS メッセージを作成するには、テキスト メッセージの前に UDH を追加する必要があります。UDH はペイロードの一部になるため、セグメントごとに送信できる文字数が減ります。

ペイロードの一部になっているため、ペイロードのデータ要件 (7 ビット) を確認する必要があります。ただし、UDH は 8 ビットであるため、明らかに事態が複雑になります。

例として、次の UDH を検討してください (連結メッセージの UDH です)。

050003000302
  • 05 は UDH の長さです (続く 5 オクテット)
  • 00 は IEI です
  • 03 は IEDL (さらに 3 オクテット) です。
  • 00 は参照です (この番号は、連結された各メッセージ UDH で同じでなければなりません)
  • 03 はメッセージの最大数です
  • 02 は現在のメッセージ番号です。

これは合計 6 オクテットで、48 ビットに相当します。これで問題ありませんが、UDH は実際には SMS メッセージの一部であるため、実際のメッセージが 7 重奏境界で始まるようにビットを追加する必要があります。セプテット境界は 7 ビットごとであるため、この場合、UDH を 49 ビットにするためにデータを 1 ビット追加する必要があります。その後、標準の GSM-7 エンコード文字を追加できます。

詳細については、こちらからご覧ください。

于 2013-02-25T07:12:30.270 に答える
1

つまり、データ コーディング スキーム バイトの圧縮ビットの意味を誤解していたということです。7 ビット アルファベット パッキング方式 (1 バイト内に少なくとも 1 文字が格納される) を指していると思いましたが、ハフマン圧縮を指しています。

したがって、上記の質問はちょっとばかげていました。そのために残念 ：-）。

于 2010-08-31T16:46:19.837 に答える