JP5038515B2 - データ伝送 - Google Patents

Description

データ伝送
本発明はデータ伝送に関する。本発明は、特定的には、移動端末装置への、及び、移動端末装置からのデータ伝送に関するものである。但しこれ以外を排除するものではない。このデータはインターネットを用いて得られたものであってもよい。

移動セルラ端末装置の利用の増加に伴い、無線リンクを介するデータの送受信を行うような端末装置に対する要望が増大している。この目的のために、携帯電話と接続した携帯用コンピュータや一体型コンピュータ／セルラ電話装置が利用される場合もある。このようなデータ伝送の１例としてインターネットの閲覧がある。

“インターネット”という用語は、通常、モデムを介して通信ネットワークへ接続された端末装置（典型的にはＰＣ）を用いてアクセス可能な情報を記述するために一般に使用される。コンテンツは、アクセス用コンピュータから離れた遠隔地にある多くの様々なサイトに格納することが可能である。但しこれら遠隔地にあるサイトの各々は通信ネットワークとリンクされている。コンテンツは、ハイパーテキストマークアップ言語（ＨＴＭＬ）を用いて構成することが可能である。インターネットは、転送制御プロトコル（ＴＣＰ）、ユーザーデータグラムプロトコル（ＵＤＰ）、インターネットプロトコル（ＩＰ）などのいくつかのプロトコルを利用する通信システムの仕様規格により機能可能となるように成され、インターネットの多数の様々な構成要素の周りのデータフローの制御が行われる。ＴＣＰとＵＤＰは、順序立った信頼性の高いデータ転送あるいは独立したデータパケットの信頼性の高くない転送などの異なるサービス品質特性を持つインターネットデータの伝送に関わる。ＩＰはデータの組み立て及びルート選定に関わる。それらの上に、インターネットを介して入手可能な様々な種類の情報を管理し、操作するための別のアプリケーション専用プロトコル（ＨＴＭＬコンテンツアクセス用ＨＴＴＰ、ファイルアクセス用ＦＴＰ、ｅ−メールアクセス用ＳＭＴＰなど）を設けることも可能である。

インターネットは、物理的には、例えばローカルエリアネットワーク（ＬＡＮ）、局所電話網、及び国際電話網などの通信ネットワーク階層及びデータ通信ネットワーク階層から構成される。これらのネットワークはいわゆる“ルータ”により内部的及び外部的に接続されていて、ルータは、発ホストまたは伝送用チェーンの前のルータからデータを受信し、着ホストまたは伝送用チェーンの次のルータへのデータの経路選定を行う。

インターネットへのアクセスの取得には移動端末装置のような端末装置とサーバ間のセッションの実行が含まれる。セッションとは、明確に定義された始端部と終端部とを備え、同意された特性を有する端末装置とサーバ間の一連のインタラクションである。典型的には、セッションには、セッションの確立要求を別のピアへ通知するピアが含まれ、双方のピアはセッションの特性のネゴシエーションを行い、これらのピアは様々なトランザクション時に係り合い、これらピアのうちの一方によりセッションの終了が行われる。ネゴシエーションが行われる特性は、典型的には、交換されるパケット長、理解可能で、操作可能なキャラクタセットと、使用プロトコルのバージョンである。

マルチメディア及びその他の無線サービスに対する要求が高まるにつれて、利用可能な無線帯域も増加し、したがって無線で多量のデータ転送を行う必要性も増加する。

移動端末装置間相互の通信の標準化を行うために、無線アプリケーション用プロトコル（ＷＡＰ）が提案されている。このプロトコルは、業界で広く採用されている１組の仕様で、無線通信ネットワークを介する動作を行うためのアプリケーションとサービスの開発に適している。ＷＡＰは、移動電話、ポケベル、個人用情報機器（ＰＤＡ）などの無線装置用アプリケーションのフレームワークとネットワークプロトコルとを指定するものである。ＷＡＰは、ＧＳＭ−９００、ＧＳＭ−１８００、ＧＳＭ−１９００、ＣＤＭＡ ＩＳ−９５、ＴＤＭＡ ＩＳ−１３６、広帯域ＩＳ−９５、及び、ＩＭＴ−２０００、ＵＭＴＳ、Ｗ−ＣＤＭＡのような第３世代システムを含むいくつかの様々なシステムに対して適用可能である。

ＷＡＰは構成要素すなわち層をベースとするアーキテクチャを有する：
アプリケーション層（無線アプリケーション環境すなわちＷＡＥと呼ばれる）は汎用アプリケーション環境である。その目的は、通信事業者及びサービスプロバイダが様々な無線プラットフォームに対してアプリケーション及びサービスを提供することを可能にする相互運用環境を設けることである。
セッション層（無線セッションプロトコルすなわちＷＳＰと呼ばれる）は、２つのセッションサービス用の一貫したインターフェースをアプリケーション層に提供するものである。第１のセッションは、トランザクション層プロトコルＷＴＰ（以下参照）の上位層で動作するコネクション指向型サービスである。第２のセッションは、保証型または非保証型データグラムサービスＷＤＰ（以下参照）の上位層で動作するコネクションレスサービスである。
トランザクション層（無線トランザクションプロトコルすなわちＷＴＰと呼ばれる）は、移動端末装置のような“シン”クライアントでの実行に適した軽量トランザクション指向型プロトコルを提供するデータグラムサービスの上位層で実行される。ＷＴＰは保証型または非保証型無線データグラムネットワークを介して動作し、以下の特徴を提供する：
トランザクション要求の３つのクラス
クラス０は信頼性の高くない１方向リクエスト用である。
クラス１は信頼性の高い１方向リクエスト用である。
クラス２は信頼性の高い２方向リクエスト−応答用トランザクションである。
ＷＴＰユーザが各受信メッセージの確認をトリガーするオプションのユーザ間信頼性
確認応答時のオプションの帯域外データ
送信メッセージの数を減らすためのプロトコルデータ単位（ＰＤＵ）連鎖及び遅延確認応答
非同期トランザクション
セキュリティ層（無線トランスポート層セキュリティすなわちＷＴＬＳと呼ばれる）。この層は業界規格トランスポート層セキュリティ（ＴＬＳ）プロトコル規格に基づくものである。この層は狭帯域通信チャネルを介して最適化される。この層にはデータ保全、プライバシー、認証及びサービス拒否保護が含まれる。アプリケーションは、そのネットワーク要件に依存するＷＴＬＳ特性と、基底にあるネットワークの特徴とを選択的に可能にしたり、不能にしたりすることができる。
トランスポート層（無線データグラムプロトコルＷＤＰと呼ばれる）。ＷＤＰ層は、様々なネットワークタイプによりサポートされるデータ処理可能ベアラサービスの上位層で動作する。一般的トランスポートサービスとして、ＷＤＰはＷＡＰの上位層プロトコルへの一貫したサービスを提供し、利用可能なベアラサービスの中の１つを介して透過的に通信を行う。
これらの層は、上記の層により、並びに、他のサービス及びアプリケーションによりアクセス可能なアーキテクチャの層の各々と共にプロトコルスタック内に設けられる。これらのプロトコルは様々な異なるベアラサービスを介して動作するように設計されている。このアーキテクチャ及びプロトコル層が記載されている仕様はhttp//www.wapforum.org/から入手可能である。

ＷＡＰはトランザクションに基づいている。ほとんどのトランザクションはプッシュ型かプル型（リクエスト−応答）のいずれかのタイプである。プッシュ型トランザクションでは、ピアは具体的にリクエストされなかった情報を送信し、プル型トランザクションでは、ピアは別のピアから情報を受信する旨のリクエストを具体的に行う。プル型トランザクションは、クライアント（センダ）とサーバ（レシーバ）間のＷＡＰでの起動トランザクションの形をとる場合もある。このようなトランザクションには、サーバへリクエスト（起動）を送信するクライアントと、リクエストに対応するデータを含む応答（結果）を返すサーバとが関与する。クライアントとサーバの双方はＷＡＰプロトコルスタックを持ち、各スタック内の層の間で起動されるサービスプリミティブによりリクエストと応答とが行われ、その結果プロトコルデータ単位の形のメッセージが適切なベアラ層を介してクライアントとサーバ間で流れる。サービスプリミティブは、セッション層とアプリケーション環境（ＷＡＥ）との間のような、プロトコル層と、それを使用する別のエンティティとの間の情報と制御の論理的交換を表す。サービスプリミティブは、コマンド、及び，特定の提供サービスと関連するコマンドに対するそれぞれの応答とから構成される。通信リンクの一方の側にあるピアでサービスプリミティブが起動されるとその結果としてリンクの他方の側のピアにイベントが生じる。

本明細書では、メッセージという用語はサービスプリミティブとＰＤＵの双方の意味で使用される。サービスプリミティブリクエストの中に現れるメッセージとは、サービスデータ単位（ＳＤＵ）を示す論理的抽象概念であり、その結果、このメッセージはサービスプリミティブの表示の際にＳＤＵとしてピア側に現れる。本ケースの場合、ＳＤＵはサービスプリミティブ内のユーザーデータフィールドである。

メッセージのいずれかがベアラサービスの最大転送単位（ＭＴＵ）サイズ（ある特定ベアラにより指定されるような単一パケットの最大サイズ）を上回る長さを持つ場合には、メッセージの送信前にメッセージは分割されてＷＴＰ層の中で一続きのパケットになる。これらのパケットは個々にもしくはグループで伝送され、次いで、受信されるとすぐに再組立てが行われる。この処理はセル分割＆組立て（ＳＡＲ）と呼ばれる。再組立ての際にパケットの順序を再現することができるように、ＳＡＲによって、連続するシーケンス番号が分割データパケットに割り当てられる。ＷＡＰでは、分割されたメッセージの最大サイズは２５６パケットである。各パケットが１〜２キロバイト（典型的には１.５キロバイト）の最大サイズを有するので、メッセージの最大サイズは典型的には０.５メガバイト未満となる。

データパケットが受信され、ＷＴＰによりメッセージの再組立てが行われると、この再組立てメッセージはＷＴＰユーザ、すなわちＷＴＰのすぐ上位に在るＷＳＰまたはアプリケーションへ渡される。しかし、ＷＴＰは、いったん分割されたデータパケットのすべてが着信すると、再組立てメッセージを上位レベルへ出力するにすぎないため、これはセンダとレシーバがメッセージの最大サイズに等しいデータバッファを使用しなければならないことを意味する。

データ転送単位はＰＤＵである。ＰＤＵは整数個のオクテットを有し、ヘッダ（固定部と可変部とを含む）と、（何らかのデータが存在する場合には）データとから構成される。上記固定部には一貫したかつ良好な通信に必要な情報が含まれる。上記固定部だけに付ける必要がある可変部には、絶対的に必要というわけではないオプション情報が含まれる。ヘッダの固定部には頻繁に使用されるパラメータと、特定のＰＤＵを特定するコードとが含まれる。固定部の長さと構造はＰＤＵコードにより定義される。一般に使用されるＰＤＵには、Ｉｎｖｏｋｅ（起動）、Ｒｅｓｕｌｔ（結果）、Ａｃｋｎｏｗｌｅｄｇｅ（確認応答）、Ａｂｏｒｔ（アボート）が含まれる。ＷＡＰで一般に使用されるＰＤＵコードは無線トランザクションプロトコル仕様に定義されている。

ＰＤＵヘッダの固定部のパラメータには以下のものが含まれる：
可変部の中のいずれかのトランスポート情報項目（ＴＰＩ）の存在を示す継続フラグ（ＣＯＮ）。
伝送グループ（ＧＴＲパケット）の最後のパケットを示すグループトレーラ（ＧＴＲ）フラグ。
分割されたメッセージの最後のパケット（ＴＴＲパケット）を示す伝送トレーラ（ＴＴＲ）フラグ。
分割されたメッセージとデータパケットの番号付けに使用されるパケットシーケンス番号（ＰＳＮ）。パケットシーケンス番号は順に配列されたデータフロー内部のデータパケットの位置を示す。このパラメータの長さは８ビットである。
ネットワークにより二重化されたパケットと、センダにより再送されたパケットとのレシーバによる識別を可能にする再送インジケータ（ＲＩＤ）。
パケットを特定のトランザクションと関連づけるトランザクション識別子（ＴＩＤ）。
起動メッセージの中に所望のトランザクションクラスを示すトランザクションクラス（ＴＣＬ）。トランザクションクラス（ＴＣＬ）はイニシエータにより選択される。
イニシエータがＴＩＤ値を“ラップ”したとき、すなわちＴＩＤ値の範囲が増えすぎたために次のＴＩＤ値がその範囲の最小値から再スタートするため、前回のＴＩＤ値よりも小さくなる場合にセットされるＴＩＤ新規フラグ。
セットされた場合、イニシエータがサーバＷＴＰユーザからのユーザ確認応答を要求していることを示すＵ／Ｐフラグ。Ｕ／Ｐフラグはすべての受信メッセージの確認をＷＴＰユーザに行わせる。
現在のグループの受信中に欠落したパケット数を示すパラメータである欠落パケット数。このパラメータがゼロ値の場合、グループ内のすべてのパケットは欠落している。ゼロ値でない場合、このパラメータの後に、欠落パケットのパケット番号がリストされる。
再送がリクエストされる欠落パケットのパケットシーケンス番号のリストであるパラメータである欠落パケットのＰＳＮ。

ＰＤＵヘッダの可変部は使用頻度の低いパラメータを定義するために使用される。可変パラメータはトランスポート情報項目（ＴＰＩ）の中に担持される。これらのパラメータは、最大グループサイズとグループ遅延をピアに対して示すようないくつかの目的のために使用してもよい。

端末装置及びサーバ内のデータバッファは伝送データを保持できる大きさを持つ必要がある。ＷＡＰ規格では、１つのメッセージは、１つのトランザクション内でセンダからレシーバへ送信される。データが単一ブロック内に存在し、例えば１００ＫＢの長さのメッセージであれば、レシーバはメッセージ全体を格納するために１００ＫＢのデータバッファを必要とする。しかし、格納する必要のない或る種のメッセージがあるため、そのメッセージの目的にとってデータバッファは不要となる。それは、テレビ電話からのデータストリームのケースである。このデータストリームは、表示用として直接ビデオディスプレイへの送信が可能であるため、このデータストリームを格納する必要はない。

ＴＣＰは有線ネットワークで多量のデータ伝送を行うために利用される。しかし、ＴＣＰは特に無線ネットワークに適したものではない。ＴＣＰは双方向のコネクションの設定を必要とする。ＴＣＰはトランザクションを遅くする原因となる。無線環境では頻繁に生じるパケット紛失が発生した場合、ＴＣＰでは確認応答が累積する。これらの累積した確認応答は過度のデータトラフィックを発生させるので望ましいものではない。有線ネットワークでは、パケットが紛失するとこの原因は一般にルータの輻輳状態に起因するとされる。これに対処するために、センダによるデータ伝送レートが下げられるので、データ伝送にさらに時間がかかることになる。無線ネットワークでは、パケット紛失はありふれた現象であり、セルのハンドオーバーや無線リンク内で生じたエラーなどの輻輳状態とは関連性のないいくつかの要因に起因する場合がある。したがって、パケット紛失は必ずしも伝送レートを低下すべき理由になるとはかぎらない。

「ＷＴＰ無線アプリケーション用プロトコル無線トランザクションプロトコル仕様」（バージョン１９９８年４月３０日） 「ＷＡＰ白書」（ＡＶシステム無線、１９９９年２月）

本発明の第１の態様によれば、センダとレシーバ間のリンクを介するトランザクションの実行方法であって、複数のデータメッセージの形のデータ伝送を行う方法が提供され、各メッセージには少なくとも１つのデータパケットが含まれる。
上記方法は以下のステップを有する：
レシーバがデータパケットの受信に対して確認応答を行い、信頼性のあるコネクションを提供するように成すステップと、
センダが、各データメッセージ内の最後のデータパケットであることをレシーバに通知するステップと、
センダが最後のデータメッセージであることをレシーバに通知するステップ。

言うまでもなく、レシーバがデータパケットを受信した旨の確認応答を発信すると述べる場合、ある種の環境では、データパケットが実際には受信されない場合もある。このような環境では、レシーバは、単数または複数のパケットが受信されなかった旨をセンダに通知することになる。

好適にはリンクが無線リンクであることが望ましい。

好適には、メッセージが所定の長さを持たないことが望ましい。本文脈では、“所定の”とは、受信完了前にいくつのメッセージあるいはいくつのパケットが受信される可能性があるかをレシーバが認知していることを意味する。本発明の１つの実施例では、データは１つのメッセージしか含まないものであってもよい。

本文脈では、“信頼性の高い”とは、確認応答の結果、レシーバがメッセージを受信したことがセンダにより認知されることを意味する。一続きの信頼性の高いデータパケットを提供することにより、データメッセージの伝送はデータストリームの特性を持つ。個々のパケットは信頼の高い受信が行われるので、任意の長さのメッセージ全体を含むための大きなバッファを設ける必要はない。テレビ会議の伝送を行う場合、伝送は莫大なデータ量となる可能性があり、したがって莫大なバッファを必要とすることになる。

１つの実施例では、本発明は、ＷＡＰ規格とアーキテクチャの多くの特徴を利用しているため、トランザクションデータ量が拡大してもＷＡＰと旧版互換性を有する。本発明は、シーケンシャルな個々のトランザクションを利用して行う可能なデータ転送よりも多量のデータの効果的転送を行うものである。本発明により、トランザクション内部でのメッセージの任意の長さのストリーム様シーケンスの伝送が可能になる。

好適には、ＷＡＰ規格の範囲内で本発明を利用することが望ましい。本発明により、１つの信頼性の高い起動メッセージと、１つの信頼性の高い結果メッセージとを持つ新しいトランザクションクラスの基礎を形成することも可能である。起動メッセージ及び結果メッセージは信頼性の高いデータメッセージを用いて条件付きで拡張され、それによって多量のデータ伝送が行われる。

好適には、任意の１時点に２つ以上の未解決トランザクションが存在できることが望ましい。好適には、単一セッションの中にいくつかの非同期トランザクションが存在することができることが望ましい。

好適には、パケットがパケットグループで送信されることが望ましい。レシーバは、すべてのパケットがグループから受信されたときグループ全体に対して確認応答を行ってもよい。上記グループ全体に対する確認応答は、レシーバが、そのグループのその他のパケットの受信を確認したとき、１グループの最後のパケットの確認応答の発信により行ってもよい。このようにして、グループの確認応答により最後のパケット以外のパケットは暗黙のうちに確認応答を受けることになる。

好適には、データメッセージの転送中データパケットに連続番号をつけることが望ましい。ＳＡＲなどの分割及び再組立て技法を利用してもよい。しかし、分割を用いなくてもよい。好適には、一続きのデータパケットがＰＳＮにより順序づけられることが望ましい。この順序づけにより欠落パケットの特定が可能になる。ラップアラウンドを行うＰＳＮを設けることにより任意の長さのデータメッセージの出力を行うことができる。

好適には、センダとレシーバの間の通信がトランザクションの範囲内で双方向であることが望ましい。２つのチャネルを設けることにより、一方のチャネルをイニシエータからレスポンダへのデータ伝送用とし、他方のチャネルを反対方向へのデータ伝送用としてもよい。２つのチャネルを設けることにより、本発明は全二重の信頼性の高いトランザクションサービスを提供するものとなる。好適には、データの最後のメッセージの送信によりチャネルの各々が閉じられることが望ましい。１つのＷＳＰセッションはこのタイプのいくつかのトランザクションを含むものであってもよい。本発明では双方向通信がサポートされる。

トランザクションは起動コマンドにより開始してもよい。このトランザクションは、いったん開始された場合、ストリームデータコマンドにより継続することも可能である。本発明に準拠するデータメッセージはトランザクションのイニシエータまたはレスポンダのいずれかにより伝送してもよい。好適には、センダがＤａｔａＥｎｄ ＴＰＩを送信し、レシーバによりＤａｔａＥｎｄ ＴＰＩが受信されたとき、１つのチャネルを介するデータ伝送の終了処理が行われることが望ましい。双方のチャネルを介する伝送の終了処理が行われた場合、トランザクションを終了してもよい。

本発明の第２の態様によれば、複数のデータメッセージの形のデータ伝送を行うための移動端末装置が提供され、各メッセージには少なくとも１つのデータパケットが含まれる。移動端末装置はメモリ内に含まれるアプリケーション、及び、プロトコルスタックを具備し、アプリケーションとプロトコルスタックは、センダとレシーバの間で無線リンクを介してトランザクションを実行する。その場合、センダはメッセージをレシーバへ順に送信し、レシーバは信頼性のあるコネクションを提供するためにパケットを受信した旨の確認応答を発信し、センダは各データメッセージにおいて最後のデータパケットであることをレシーバに通知し、センダは最後のデータメッセージであることをレシーバに通知する。

本発明の第３の態様によれば、複数のデータメッセージの形のデータ伝送を行うためのゲートウェイが提供され、各メッセージには少なくとも１つのデータパケットが含まれる。上記ゲートウェイはメモリ内に含まれるアプリケーション、及び、プロトコルスタックを具備し、アプリケーションとプロトコルスタックは、センダとレシーバの間で無線リンクを介してトランザクションを実行する。さらにその場合、センダはメッセージをレシーバへ順に送信し、レシーバは信頼性のあるコネクションを提供するためにパケットを受信した旨の確認応答を発信し、さらに、センダは各データメッセージにおいて最後のデータパケットであることをレシーバに通知し、センダは最後のデータメッセージであることをレシーバに通知する。

本発明の第４の態様によれば、複数のデータメッセージの形のデータ受信を行うための複数の移動端末装置を有するデータ伝送システムが提供され、各移動端末装置はメモリ内に含まれるアプリケーション、及び、プロトコルスタックを具備し、アプリケーションとプロトコルスタックとは、ゲートウェイとの無線リンクを介してトランザクションを実行する。その場合、ゲートウェイは移動端末装置へメッセージを順に送信し、移動端末装置はパケットを受信した旨の確認応答を発信して信頼性のあるコネクションを提供し、ゲートウェイは各データメッセージにおいて最後のデータパケットであることを移動端末装置に通知し、ゲートウェイは最後のデータメッセージであることを移動端末装置に通知するようにする。

本発明の第５の態様によれば、複数のデータメッセージの形のデータ伝送を行うための複数の移動端末装置を有するデータ伝送システムが提供され、各移動端末装置はメモリ内に含まれるアプリケーション、及び、プロトコルスタックを具備し、アプリケーションとプロトコルスタックとは、ゲートウェイとの無線リンクを介してトランザクションを実行する。その場合、移動端末装置はゲートウェイへメッセージを順に送信し、ゲートウェイはパケットを受信した旨の確認応答を発信して信頼性のあるコネクションを提供し、さらに、移動端末装置は各データメッセージにおいて最後のデータパケットであることをゲートウェイに通知し、移動端末装置はゲートウェイに最後のデータメッセージであることを通知するようにする。

本発明の第６の態様によれば、コンピュータ可読媒体に格納されたコンピュータプログラム製品が提供され、コンピュータプログラム製品には、以下の、
センダとレシーバの間で無線リンクを介してトランザクションをコンピュータに実行させるコンピュータ可読プログラム手段であって、トランザクションが複数のデータメッセージを含む伝送データを有するように成すコンピュータ可読プログラム手段と、
センダに、レシーバへメッセージを順に送信させるコンピュータ可読プログラム手段と、
レシーバにパケットを受信した旨の確認応答を発信させて、信頼性のあるコネクションを提供するように成すコンピュータ可読プログラム手段と、
最後のデータパケットであることのレシーバへの通知をセンダに行わせるコンピュータ可読プログラム手段と、
最後のデータメッセージであることのレシーバへの通知をセンダに行わせるコンピュータ可読プログラム手段と、が含まれる。

本発明の第７の態様によれば、センダとレシーバの間のリンクを介するトランザクションの実行方法であって、複数のデータパケットの形の所定長ではないデータの伝送方法が提供され、上記方法には、以下の、
上記パケットに対してパケットシーケンス番号を適用するステップであって、上記パケットシーケンス番号が、第１のパケットシーケンス番号により定義される第１の端から、最後のパケットシーケンス番号により定義される第２の端までの範囲を持つように成すステップと、
上記パケットシーケンス番号が、その範囲の端のうちの一方に達したとき、上記パケットシーケンス番号のラップアラウンドを行うステップと、が含まれる。

上記パケットシーケンス番号は各パケット用として連続していることが望ましいが、１つのパケットから次のパケットへ増減してもよい。上記パケットシーケンス番号は１つのパケットから次のパケットへ１ずつ段階的に変化してもよいし、あるいは、１以外の２や別の整数ずつ段階的に変化してもよい。

添付図面を参照しながら単に例示として本発明の実施例を以下説明する。

分割を利用するトランザクションを示す。 メッセージの構造を示す。 分割を利用しないトランザクションを示す。 図３のトランザクションの別図を示す。 有効なサービスプリミティブシーケンスの表を示す。 通信システムを示す。 ゲートウェイを示す。 移動端末装置を示す。 異なる形で図６に準拠するシステムを示す。

１つの実施例では、本発明は、任意の長さのデータ伝送を可能にするＷＡＰ規格用の新しいトランザクションクラスを提供する。この新しいクラスはクラス３である。このようなデータは、テレビ会議から発信するデータストリームである場合もあれば、マルチメディア用ストリームである場合もあれば、ソフトウェアのダウンロードである場合もある。

クラス３トランザクションについて以下説明する。以下のサービスプリミティブがクラス３トランザクション中用いられる：
ＴＲ−ストリーム起動（Ｉｎｖｏｋｅ）；
ＴＲ−ストリーム結果（Ｒｅｓｕｌｔ）；
ＴＲ−ストリーム起動データ；
ＴＲ−ストリーム結果データ；
ＴＲ−アボート
‘ＴＲ−’というプレフィックスは、サービスプリミティブがプロトコルスタック内の複数の層の間で使用されていることを意味する。‘Ｓ−’というプレフィックスは、サービスプリミティブが（ＷＳＰなどの）セッション層内で使用されていることを示す。

以下の解説では、サービスプリミティブは、上位ローカル層または下位ローカル層のいずれかの層からＷＴＰへのリクエストを記述するものである。この結果、トランザクション中ネットワークを介して送信される（ヘッダとデータを含む）符号化パケットであるＰＤＵが生成される。

図１は、データ伝送が行われるクラス３トランザクションの一部を示す図である。このトランザクションは、レスポンダと呼ばれる別の通信エンティティに対して、イニシエータと呼ばれる１つの通信エンティティにより開始される。イニシエータとレスポンダとは２つのチャネルを介して交信を行う。各チャネルはデータフローの方向に従ってセンダとレシーバとを備えている。入力チャネルと出力チャネルとが存在し、入力チャネルはそのデータフローがイニシエータにより確立され、出力チャネルはそのデータフローがレスポンダにより確立される。２つのチャネルが存在するため、イニシエータとレスポンダはデータのセンダ兼レシーバとして各々機能する。“チャネル”という用語は、メッセージの順序づけられたシーケンスを１方向で伝送するためのストリーム様データ経路を意味する。この用語は物理的エンティティを意味するものではなく、メッセージの順序づけられたシーケンスを１方向で伝送するという上記結果を生む論理的操作を意味するものである。

ＷＴＰのユーザは、ＷＳＰであるか、コネクションを介してＷＴＰと直接通信するアプリケーションかのいずれかであり得る。前者の場合、各トランザクションはセッションの中で達成される。後者の場合、ＷＳＰとＷＳＰユーザは単に同じアドレスの四つ組（quadruplet）に存在するにすぎない。

図１は、イニシエータ（センダ）からレスポンダ（レシーバ）へ入力チャネルを介して伝送されるメッセージのみを示す。出力チャネルで伝送されるメッセージ、特に、レスポンダによりイニシエータへ伝送されるデータ結果は示されていない。いずれのチャネルにおいても、データの確認応答は該データの反対方向に流れる。

図１のトランザクションの詳細な説明を行う前に、簡単な用語でトランザクションの解説を行って、このトランザクションの進み方を例示することにする。ストリーム起動メッセージは入力チャネルで送信される。レスポンダはストリーム結果メッセージを用いて出力チャネルで応答する。次いで、双方のメッセージには追加のストリームデータメッセージが後続してもよい。この追加メッセージは元のメッセージの続きであるとみなされ、追加データを運ぶ。データメッセージが受信されたとき、データメッセージのレシーバがデータメッセージを正確な順番に並べることができるように、この追加データメッセージ内のパケットには連続するＰＳＮが与えられる。トランザクション時のいずれのチャネルもデータ終端メッセージにより終了が可能である。イニシエータとレスポンダの双方がデータ終端メッセージを受信した場合このトランザクションは終了処理が行われる。すべてのメッセージは確認応答を受ける。１つのメッセージは、１つのパケットを含むものであってもよいし、いくつかのパケットに分割されたものであってもよい。

クラス３で使用されるＰＤＵは以下のコードを持つ：

本発明のＰＤＵの固定ヘッダ構造のフォーマットはＷＡＰ規格で使用されるものと同じである。ＰＤＵの使用法と動作について以下説明する。

トランザクション中、サービスプリミティブは、イニシエータとレスポンダの各々の中のＷＡＰプロトコルスタック内のプロバイダ層とユーザ層との間で起動される。サービスプリミティブにより起動可能な特定のパラメータが以下のパラメータの中から選択される：
発アドレス。これは、ＷＴＰ層へのリクエストを行う装置の一意的アドレスである。このアドレスは、ＭＳＩＳＤＮ番号、ＩＰアドレス、Ｘ.２５アドレスあるいはその他の識別子であってもよい。
発ポート番号。これは発アドレスに関連付けられる。
着アドレス。これは、ＷＴＰ層へ発信されるユーザーデータのアドレスである。着アドレスは、ＭＳＩＳＤＮ番号、ＩＰアドレス、Ｘ.２５アドレスあるいはその他の識別子であってもよい。
着ポート番号。これは、リクエストされたトランザクションまたは現行トランザクション用着アドレスと関連付けられる。
ユーザーデータ。このユーザーデータは、起動されたプリミティブから生成されたメッセージにより運ばれる。ＷＴＰ層へ発信されたりＷＴＰ層から受信されたりするデータ単位（ＳＤＵ）。これは、上位層が伝送用としてＷＴＰ層へ発信したデータの完全な単位（メッセージ）である。ＷＴＰ層はデータグラムＳＤＵを伝送し、このデータグラムをそのコンテンツをまったく操作することなくその宛先へ転送する。
データ終端。このパラメータは、トランザクションの際にレスポンダへ送信されるユーザーデータの最後の部分が特定のＳＤＵにより担持されていることを示すために使用される。
トランザクションハンドル。これは、トランザクションを特定して、受信データをアクティブなトランザクションと関連づけることができるようにするために上位層へ返されるインデックスである。トランザクションハンドルによりトランザクションは一意的に特定される。トランザクションハンドルは、トランザクションの発アドレス、発ポート、着アドレス及び着ポートの別名である。トランザクションハンドルはローカルな重要性しか持たない。
エグジット情報。メッセージのシーケンスの送信完了時にメッセージのシーケンスの発信源へ送信される追加ユーザーデータ。このパラメータは、ＴＲストリーム−結果と、ＴＲストリーム−結果−データサービスプリミティブとの中にしか存在しない。

図１に戻って、イニシエータとレスポンダのプロトコルスタック内で生じているサービスプリミティブのシーケンス、及び、イニシエータとレスポンダとの間を通るＰＤＵという点からトランザクションについて以下説明する。新しいクラス３トランザクションは、ＷＡＥやＷＳＰなどの、ＷＴＰ層より上位の層（ＷＴＰユーザ（イニシエータ）と呼ばれる）によりイニシエータで開始され、ＷＴＰ層（ＷＴＰプロバイダ（イニシエータ）と呼ばれる）内のＴＲストリーム起動リクエストサービスプリミティブが起動される。新しいトランザクションが起動されると、イニシエータはトランザクション識別子（ＴＩＤ）を１だけ増分して、これが新しいトランザクションであることを示す。特定のクラス３トランザクションの範囲内で（すべてのＰＤＵを含む）すべてのメッセージは同じＴＩＤを持つ。

ＴＲストリーム起動リクエストサービスプリミティブを起動することにより、ＷＴＰプロバイダ（イニシエータ）内のパラメータが呼び出される。これらのパラメータはトランザクションの設定に必要である。ユーザーデータも含まれる。ＴＲストリーム起動サービスプリミティブの中に含まれるパラメータを以下の表に示す：

この表及び下記の諸表の中で、ラベルＭ、Ｏ、Ｃは以下の意味を持つ：
Ｍはパラメータが必須であり、存在しなければならないことを意味する。
Ｏは、パラメータがオプションであり、省いてもよいことを意味する。
Ｃはパラメータが他のパラメータの値に依存する条件つきであることを意味する。

ストリーム起動サービスプリミティブは起動ＰＤＵヘッダを受信し、次いで、ＷＴＰプロバイダ（イニシエータ）は暗黙のパケット番号ゼロを有する起動（Ｉｎｖｏｋｅ）ＰＤＵを送信する。起動ＰＤＵは常にトランザクションの第１のメッセージである。起動ＰＤＵはＴＣＬパラメータを含む。利用可能なトランザクションクラスは以下に与えられる：

この場合、ＰＤＵヘッダはトランザクションがクラス３であることを示す。ＰＤＵが伝送される初回の場合、ヘッダ内の再送インジケータ（ＲＩＤ）フィールドはクリアである。クラス３トランザクションであることを示すＴＣＬはクラス０、１、２に対するＴＣＬと同様に２ビットを必要とするにすぎないこと、したがって、ＷＡＰと旧版互換性を有することに留意されたい。レスポンダがクラス３トランザクションをサポートしていない場合、トランザクションはレスポンダにより打ち切られる。

起動ＰＤＵが受信されたとき、ＷＴＰプロバイダ（レスポンダ）はＴＩＤをチェックし、確認を開始する必要があるかどうかの判定を行う。必要がある場合、ＷＴＰプロバイダ（レスポンダ）はＴＩＤ確認処理を開始する。必要がない場合、ＷＴＰプロバイダ（レスポンダ）はＷＴＰユーザ（レスポンダ）へメッセージを転送する。クラス３トランザクションのＴＩＤ確認処理時に確認応答ＰＤＵ（Ａｃｋ ＰＤＵ）が使用される。

図２に示される一例を参照してメッセージの構造について以下説明する。ストリーム起動メッセージのサイズがネットワークのＭＴＵを上回った場合、メッセージは順序づけられた一連のパケットに分割される。本例では、ＰＳＮ０を持つストリーム起動パケットが存在し、第１の組のパケットは１〜１６のＰＳＮを持ち、第２の組のパケットは１７〜３３のＰＳＮを持つ。メッセージの伝送開始時に、イニシエータの起動サービスプリミティブ内のデータ終端フラグがクリアされて、さらなるデータパケットが伝送されることを示す。データ終端フラグがクリアされなかった場合、これはさらなるＳＤＵが到来しないことを示すことになる。パケット内でセットされたＧＴＲフラグはグループの終りを示す。パケット内でセットされたＴＴＲフラグはＳＤＵの終りを示す。このＴＴＲフラグによって、２つのＳＤＵ間の分割またはメッセージの最後のＳＤＵをマークすることも可能である。ＤａｔａＥｎｄ ＴＰＩは最後のＳＤＵの最後のパケットに付けられる。

起動メッセージから生成される最初のパケットは常に起動ＰＤＵヘッダを持ち、（図２に示されているような）暗黙的にＰＳＮ０を持つものとして想定されている。ストリーム起動メッセージが分割される場合、レスポンダは起動ＰＤＵをパケット番号ゼロと考え、次の分割された起動ＰＤＵを待つ。追加パケットには連続的に増加するＰＳＮを持つ分割されたストリーム起動ヘッダが設けられる。図２では、パケット１〜３３はこのタイプのＰＤＵを含む。このようなＰＤＵとして以下のようなものがある：

これらのパケットはグループで伝送される。グループ伝送については後程さらに詳細に解説する。これらのパケットはグループで確認応答を受ける。

クラス３トランザクション時にストリーム起動ＰＤＵが分割されているかどうかにかかわりなく、ＰＳＮはイニシエータとレスポンダの双方により保持される。これは、センダが次のＰＳＮ（次のパケットのＰＳＮ）を認知するようにするためであり、また、レシーバが最後の応答確認済みパケットのＰＳＮを認知し、それによって次の予想されるパケット（必ずしも次の受信パケットであるとはかぎらない）を認知するようにするためである。ストリーム起動サービスプリミティブの中にデータ終端フラグが設定されている場合、メッセージハンドラはＤａｔａＥｎｄ ＴＰＩをＰＤＵのヘッダの固定部に付ける。ストリーム起動メッセージが分割されなかった場合、その起動ＰＤＵはＤａｔａＥｎｄ ＴＰＩを持つ。ストリーム起動メッセージが分割される場合、最後のメッセージグループの最後の分割パケットはＤａｔａＥｎｄ ＴＰＩを持ち、チャネルは閉じられる。

ＰＳＮはラップアラウンドし、３２ビットフィールドを持つ。これは、ＰＳＮがラップアラウンドを完了してしまい、ＰＳＮ番号の再使用が行われるようになる前にデータストリーム内のすべてのパケットが受信されてしまう確率を高くするように、長いデータ伝送時間を可能にするためである。このトランザクションは長い寿命を持つことが可能であるため、ＰＳＮ（または時折ＲＩＤ）のみが新しい有効なパケットを古いパケットの複製から区別する。

ＷＴＰプロバイダ（イニシエータ）は起動ＰＤＵを送信し、再送タイマを始動させ、再送カウンタをゼロにセットする。さらに、ＷＴＰプロバイダ（イニシエータ）はＰＳＮをゼロに初期化し、ＷＴＰプロバイダ（レスポンダ）からの確認応答の待機を開始する。ＷＴＰプロバイダ（レスポンダ）は、有効なＴＩＤを持つ起動ＰＤＵを受信すると、起動メッセージの確認応答を行い、ＴＲストリーム起動指示サービスプリミティブを生成することにより、ＷＴＰユーザ（レスポンダ）へ上記起動メッセージの転送を行う。

再送タイマの期限が切れた（再送の時間間隔に達した）ときに起動ＰＤＵまたは他のいずれかのパケットの確認応答がセンダにより受信されなかった場合、再送カウンタが１だけ増分され、グループの最後のパケットが再送され、再送タイマが再開される。すべての再送について、ＲＩＤフィールドが設定される。ＲＩＤフィールドは変更が行われる唯一のフィールドである。再送回数が最大再送値を上回るまでＷＴＰプロバイダは再送を継続する。再送カウンタが十分に増分され、タイマの期限が切れるまでに確認応答が受信されなかった場合、トランザクションは終了され、ローカルのＷＴＰユーザに通知が行われる。

ＷＴＰプロバイダ（レスポンダ）が起動ＰＤＵを受信すると、ＷＴＰプロバイダ（レスポンダ）により、最初のパケット（起動ＰＤＵ）の確認応答がストリーム確認応答ＰＤＵ（ストリームＡｃｋ ＰＤＵ）を用いて行われる。これはストリームＰＳＮ ＴＰＩヘッダを有するＡｃｋ ＰＤＵであり、ＰＳＮは０である。また、ＷＴＰプロバイダ（レスポンダ）は、許容されているグループサイズウィンドウをセンダに対して示すためにオプションＴＰＩ（ＭａｘＧｒｏｕｐＳｉｚｅ ＴＰＩ）の形でその最大グループサイズの送信も行う。このグループサイズはセンダにより選択されて、現時点のネットワーク負荷にぴったり合い、かつ、レシーバのウィンドウよりも大きくならないようにすることができる。レシーバによりウィンドウの次の変更が行われるまで最後のウィンドウは有効であり、最後のグループの確認応答にＭａｘＧｒｏｕｐＳｉｚｅ ＴＰＩが追加される。レシーバは、ネットワーク用の最適の反応、及び、ネットワークのトラフィック負荷の変化にとって大きすぎないグループサイズを選択することが望ましい。

１回のデータグラムで、イニシエータからレスポンダへストリーム起動メッセージ全体の伝送を行うことが可能であり、したがってストリーム起動メッセージ全体の分割と再組立てを行う必要がない場合、ストリーム起動メッセージ全体は起動ＰＤＵとして送信される。必要なＰＤＵの数を最小にするために分割が行われない場合であってもこのＰＤＵは再使用される。したがって、パケットがメッセージ内の最後のパケットであることを示すために、ＴＴＲフラグはそのヘッダ内で１にセットされる。

これらのパケットは送信されグループで確認応答を受ける。分割を行う必要がない場合グループは単一パケットから構成される。パケットグループ内のパケットは単一バッチで送信される。第１のグループはレシーバの状態を確認せずに送信されるので、パケット数は１とすることが望ましい。パッケージ伝送方法を示す２つの代替実施例について以下説明する。

伝送方法１
伝送方法のこの実施例はｓｔｏｐ−ａｎｄ−ｗａｉｔ方式ではない。これは、未解決パケットグループが存在する可能性がある、すなわち、前回のグループの確認応答が受信される前に後続グループのパケットの送信が可能であることを意味する。

グループの最後のパケットはＧＴＲパケットである。ＧＴＲフラグは、そのグループで送信されるすべてのパケットについて確認応答をセンダがリクエストすることを意味する。メッセージ全体の最後のパケットはＴＴＲパケットである。

伝送方法１では、ＧＴＲフラグが設定されている場合、レシーバは、受信した最後の完全なグループの最後のパケットのＰＳＮを有する確認応答（ストリームＰＳＮ ＴＰＩを持つＡｃｋ ＰＤＵ）を送信するか、または、確認応答がなされた最後のグループと受信した最後のパケットの間のＰＳＮのリストを有するＳｔｒｅａｍ Ｎａｃｋ ＰＤＵを送信しなければならない。ストリームＮａｃｋ ＰＤＵは最も新しいグループからの欠落パケットのＰＳＮを含み、さらに、以前のグループ（但し確認応答がなされた最後のグループは含まない）からの欠落パケットのＰＳＮを含むものであってもよい。

メッセージの最後の各パケット（ＳＤＵ）はグループの終りであり、確認応答がなされる必要がある。ＴＴＲは確認応答を求める要求でもある。

ストリームＰＳＮ ＴＰＩの中に含まれるＰＳＮは確認応答されるパケット（ＧＴＲパケット）のＰＳＮである。この確認応答は、グループ内のすべてのパケットは着信したが、このグループ以外のすべての他の前回のパケットが受信したことを意味するわけではないという点において、グループ内で累積的である。

メッセージは順に送信される。前回のメッセージの伝送が終ってしまうまで新しいメッセージの伝送は開始されない。レシーバは、ＧＴＲパケットではないパケットを受信したとき、パケットを格納し、新しいパケットの着信を待つ。レシーバがメッセージのすべてのパケットを受信した（すなわち最後のパケットがＴＴＲパケットである）とき、完全なメッセージの再組立てを行うことが可能でなければならない。レシーバは、ＧＴＲパケットを受信したとき、そのパケットグループに属するすべてのパケットが受信されたかどうかのチェックを行う。受信されていた場合、レシーバはストリームＡｃｋ ＰＤＵ（ＰＳＮがＧＴＲパケットのＰＳＮに等しくセットされるストリームＰＳＮ ＴＰＩを担持する）をセンダへ送信する。がセットされたＧＴＲを有するパケットが受信されていて、かつグループの１以上のパケットが欠落しているとき、ＷＴＰプロバイダは、往復時間の中央値の１／２などのある一定期間待機した後に欠落パケットのリストを有するストリームＮａｃｋ ＰＤＵを返送する。グループの状態が時間中変化した場合、すなわち、欠落パケットの中の１つが受信された場合、待ち時間はリセットされる。グループデータの受信の誤りを示すためにストリームＮａｃｋ ＰＤＵがクラス３トランザクションのみにおいて使用される。以下にこれを示す：

ストリームＮａｃｋ ＰＤＵは別のグループに属する他の欠落パケットをリストすることも可能である。こうすれば、現時点のストリームＮａｃｋ ＰＤＵが受信され、しかも前回のストリームＮａｃｋ ＰＤＵが失われた場合、センダが最後の無応答ＧＴＲパケットの再送を行って以前に失われたストリームＮａｃｋ ＰＤＵのレシーバによる再送を待機する必要はなくなる。これは以下のように説明することが可能である。第１のグループ内に何らかの欠落パケットが存在し、第２のグループ内に何らかの欠落パケットが存在すると仮定する。レシーバは、第１のグループ用の第１のストリームＮＡｃｋ ＰＤＵを送信し、第２のグループ用の第２のストリームＮＡｃｋ ＰＤＵを送信する。第１のストリームＮＡｃｋ ＰＤＵが失われた場合、センダは第１のグループの状態がどうなっているかわからなくなる。したがって、第１のグループの欠落パケットが第２のストリームＮＡｃｋ ＰＤＵの中に含まれていれば、往復の及び関連する再送時間が不要となる。センダは当初のＰＳＮを有するがＲＩＤフラグがセットされた欠落パケットの再送を行う。レシーバは、再送された欠落パケットを含む完全なパケットグループを受信した場合、ＧＴＲパケットの確認応答を発信する。

第１のグループのサイズはベアラに対応してデフォルトであってもよい。ストリームＡｃｋ ＰＤＵでは、最初のパケットグループの伝送に後続して、レシーバはその現時点のウィンドウパケットスペースを示すためにそのＭａｘＧｒｏｕｐＳｉｚｅを送信してもよい。ウィンドウパケットスペースとは、任意の時点において未解決であり得るパケットの数であると定義される。このウィンドウパケットスペースはセンダ内及びレシーバ内の双方の中に存在する。

この最初の処理後、レシーバはそのウィンドウパケットスペースを用いてデータフローの制御を行うことが可能となる。これを行う１つの方法として単一メッセージの伝送中グループサイズの変更を行う方法がある。利用可能なウィンドウパケットスペースはバイトで表わされる。１グループ内の最大パケット数は最大ベアラパケットサイズにより決定される。１グループ内の伝送可能な最大パケット数は、レシーバで利用可能なデータバッファ数により決定される。

ウィンドウパケットスペースは、ＰＳＮスペース、すなわち最長未解決パケット（最も長い時間確認応答されていないパケット）のＰＳＮから始まり、最長未解決パケットのＰＳＮにウィンドウパケットスペース内のパケット数を加算したものに等しいＰＳＮまでのＰＳＮの範囲、に変換される。ある特定グループが確認応答された場合、これがその特定グループに属するすべてのパケットの受信を意味するとしても、必ずしも、その特定グループの前後のいずれかに伝送されたグループのパケットの受信を意味するとはかぎらない。グループの確認応答が着信し、さらに、そのＰＳＮ未満のＰＳＮを持つレシーバのＰＳＮスペース内の他のすべてのパケットが受信された場合、ＰＳＮスペースの再定義を行うために最長未解決パケットを更新してウィンドウの調整が行われる。このようにして、ウィンドウパケットスペースに対応してとびとびに移動するのではなく、ウィンドウパケットスペースの開始及び終了ＰＳＮが１だけ移動することによりＰＳＮスペースは増加的に移動を行うことが可能となる。

パケットがセンダにより送信され、レシーバにより受信されたとき、パケット伝送の遅延が未解決パケットへつながる可能性がある。これらの未解決パケットが受信されると最長未解決パケットが受信されるごとに、レシーバは最長未解決パケットを受信した旨の確認応答をセンダへ送信し、そのウィンドウパケットスペースを移動させて次のＰＳＮスペースを占有する。このようにしてＰＳＮスペースは新しい最長未解決パケットから始まることになる。センダは、確認応答を受信すると、そのウィンドウパケットスペースを受信に対応して移動させ、センダとレシーバのウィンドウパケットスペースが対応するようになる。

センダは、ウィンドウパケットスペースよりも多い数のパケットを持つグループをつくってはいけない。

再送タイマの期限が切れたとき、センダが確認応答を受信していない場合、パケットグループ全体ではなくＧＴＲパケットだけが再送される。

ストリームＮＡｃｋ ＰＤＵ内で、欠落パケットパラメータ数がゼロの値を持つ場合、グループ内のすべてのパケットが再送されなければならない。

レシーバは、データ受信用のバッファの空きがない場合に、確認応答と共に０に等しいＭａｘＧｒｏｕｐＳｉｚｅ ＴＰＩを送信することによりそのウィンドウを閉じることができる。しかし、レシーバは生じる可能性のある打切り（Ａｂｏｒｔ）を受信するために１つのパケットバッファを予約しておかなければならない。レシーバを刺激してそのウィンドウに関する情報を与えるために、たとえウィンドウが閉じられていても、センダは１パケットグループ（ＧＴＲパケット）を送信する。レシーバは現在の状態を示す確認応答を応答時に送信する。ウィンドウはそのまま閉じていてもよい。ウィンドウが再び開かれると、レシーバは最後のパケットグループの確認応答を繰り返す。この確認応答は、新しい利用可能なウインドウサイズ（おそらく０以外の）を持つＭａｘＧｒｏｕｐＳｉｚｅ ＴＰＩを担持する。しかし、センダは開いたウィンドウに関する確認応答を受信しないことも可能である。これは、確認応答が紛失したり、送信されたけれどもまだ受信されていなかったり、あるいは送信さえまだ行われていないという理由などに起因する。センダが確認応答を受信しなかった場合、必要な任意の再送を制御する従来の方法で再送タイマが利用される。いずれの場合にも、レシーバ内のリソース問題に関する情報がセンダに与えられるため、再送タイマは正常の場合よりも大きくなる。

伝送方法２
伝送方法を示すこの実施例はｓｔｏｐ−ａｎｄ−ｗａｉｔ方式である。これは未解決パケットグループがあり得ないことを意味する。前回のグループのパケットのすべてについて確認応答が受信されたときにのみ、後続グループ用ＧＴＲパケットの送信が行われる。受信された確認応答時のウィンドウパケットスペースに沿うシフト方式の詳細については、上述の方式に対応する。

グループの最後のパケットはＧＴＲパケットである。メッセージ全体の最後のパケットグループの最後のパケットはＴＴＲパケットである。伝送方法２では、ＧＴＲフラグとＴＴＲフラグとはＷＡＰ無線トランザクションプロトコル仕様に記載されているものと同じ意味を持つ。

レシーバは、ＧＴＲパケットでもＴＴＲパケットでもないパケットを受信すると、パケットを格納し、新しいパケットを待機する。レシーバが完全なパケットグループを受信し、最後のパケットがＴＴＲパケットであるとき、完全なメッセージの再組立てが可能であるべきである。レシーバは、ＧＴＲパケットまたはＴＴＲパケットのいずれかを受信し、グループ内のすべてのパケットの受信に成功した場合、（ストリームＰＳＮ ＴＰＩを有する）Ａｃｋ ＰＤＵをセンダへ送信する。ＧＴＲパケットとＴＴＲパケットのいずれかが受信され、グループの１以上のパケットが欠落しているとき、ＷＴＰプロバイダは、往復時間の中央値の１／２などのある一定時間待機した後に、欠落パケットの詳細を有するストリームＮａｃｋ ＰＤＵを返送する。この時間中グループの状態が変化した場合、すなわち、欠落パケットの中の１つが受信された場合、待ち時間はリセットされる。

レシーバは、ＧＴＲパケットかＴＴＲパケットのいずれかを受信したとき、そのパケットグループに属するすべてのパケットが受信されたかどうかのチェックを行う。完全なパケットグループが受信された場合、レシーバはＧＴＲパケットまたはＴＴＲパケットのパケットシーケンス番号に等しいＰＳＮを持つストリームＰＳＮ ＴＰＩヘッダが付されたストリームＡｃｋ ＰＤＵを返送する。ストリームＰＳＮ ＴＰＩに含まれるＰＳＮは、応答確認済みパケット（ＧＴＲまたはＴＴＲパケット）のＰＳＮである。この確認応答は累積的であり、すべての前回伝送されたパケットが受信された旨の確認応答である。

１以上のパケットが欠落している場合、レシーバはストリームＮａｃｋ ＰＤＵを用いて応答を行い、欠落パケットはストリームＮａｃｋ ＰＤＵの中にリストされる。欠落パケットは当初のＰＳＮを有するがＲＩＤフラグがセットされて再送される。レシーバは、完全なパケットグループを受信すると、再送パケットを含むＧＴＲパケットまたはＴＴＲパケットの確認応答を発信する。

再送タイマの期限が切れたとき、センダが確認応答を受信していない場合、パケットグループ全体ではなく、ＧＴＲパケットまたはＴＴＲパケットのみが再送される。

ストリームＮａｃｋ ＰＤＵ内で、欠落パケットパラメータ数がゼロの値を持つ場合、グループ内のすべてのパケットが再送される。

この伝送方法の情報量の改善を図るために以下の特徴が含まれる。
１．グループの伝送中、そのシーケンスの中に何らかのパケットの欠落の存在が特定された場合、レシーバはＧＴＲパケットまたはＴＴＲパケットを待たずにストリームＮａｃｋ ＰＤＵの送信を行うことも可能である。したがって、ＧＴＲパケットまたはＴＴＲパケットの受信前にある特定パケットに関する第１のストリームＮａｃｋ ＰＤＵが送信され、かつ、ＧＴＲパケットまたはＴＴＲパケットの受信後にその特定パケットがまだ受信されていない場合、この特定パケットは第２のストリームＮａｃｋ ＰＤＵの中に示され、第１、２両方のストリームＮａｃｋ ＰＤＵの中で欠落しているパケットとして示されることになる。
２．グループサイズはグループウインドウサイズの数値の１／２となるように選択される。グループウインドウサイズが奇数の場合、グループサイズは（（グループウインドウサイズ）−１）／２となる。グループサイズの決定は、ＭａｘＧｒｏｕｐＳｉｚｅ ＴＰＩによってそのウインドウサイズを示すレシーバと、適切なグループサイズを選択するセンダとにより行われる。この伝送システムの動作について以下の例により説明する。ウインドウサイズを１１と仮定する。これに応じて、グループサイズは５となる。４つの伝送対象パケットが存在する。第１の送信バーストで、パケット０、１、２、３、４（第１のグループのＧＴＲパケット）、５、６、７、８が送信される。この第１の送信バーストは第１のグループの全体及び第２のグループの一部である。第２のグループのＧＴＲパケットはこの送信バーストでは送信されない。第２の送信バーストで、送信対象の第１のパケットは第２のグループのＧＴＲパケットであり、第３のグループの一部がそれに続く。第３のグループのＧＴＲパケットはこの送信バーストでは送信されない。後続する送信バーストで、第１のパケットは、先行する送信バーストからの古いグループのＧＴＲパケット、及び、新しいグループのＧＴＲパケットを除く新しいグループのパケットである。各ＧＴＲパケットが受信されたとき、そのグループからのパケットのすべてが受信された場合、そのグループの確認応答が送信され、次の送信バーストが発生する。１つだけＧＴＲ／ＴＴＲパケットが未解決となる可能性がいつでも存在する。この伝送方法の実行時に、レシーバはパケットの不完全なシーケンスの格納並びに後続の送信バーストの格納が可能であり、そのグループの再組立てが可能である必要がある。オーバーラップする伝送部分を含む２つのパケットグループの処理がレシーバにより可能となる必要がある。欠落パケットはストリームＮａｃｋ ＰＤＵの中にリストされ、次いで再送される。その間、次のグループのパケットは、すでに伝送されている場合もあれば、レシーバのバッファ内での再組立てを待機している場合もある。

伝送方法１と伝送方法２の双方のこのケースでは、ＴＴＲにより暗黙のうちにグループの最後にマークがつけられる。

ＤａｔａＥｎｄ ＴＰＩを含むメッセージが確認応答を受けた後は、それ以上多くのデータメッセージをレシーバへ送信することはできない。

ＷＴＰプロバイダ（レスポンダ）の中でメッセージの再組立てが行われる。このメッセージの再組立てが行われと、ＷＴＰプロバイダ（レスポンダ）は、ＷＴＰのユーザ（レスポンダ）内のサービスプリミティブTR-Stream Invoke.indを起動し、ＷＴＰユーザはメッセージを受信し、ＷＴＰプロバイダ（レスポンダ）内のサービスプリミティブTR-Stream Invoke.resを起動する。

クラス２のトランザクションでは、単一の起動メッセージは、Ａｃｋメッセージの送受信を行うことなく単一の結果メッセージにより確認応答を受けることができる。これは暗黙の確認応答である。クラス３では、同じトランザクションに関する多くのパケット、及び、多くのパケットグループが存在してもよく、このトランザクションは長期間持続することが可能である。したがって、ストリーム結果メッセージの受信は特定の起動メッセージの確認応答を暗黙のうちに行うものではない。その理由はこのストリーム結果メッセージがいくつかの異なる起動メッセージと関連する場合もあるからである。これはストリーム結果メッセージにはＰＳＮや関連する起動メッセージのＰＳＮが含まれないという理由に因るものである。さらにタイミングが重要である。チャネルで送信されるＰＤＵは相手への応答として送信されるわけでは（必ずしも）ない。個々の確認応答（ＧＴＲパケットについての特定の確認応答及び非ＧＴＲパケットについての暗黙の確認応答）が個々のパケットについて行われる。

ユーザ確認応答機能はクラス３で行われる。（ＷＴＰユーザによるストリーム起動サービスプリミティブの中に、また、ＷＴＰプロバイダによる起動ＰＤＵの中に）この機能が設定されている場合、ＷＴＰプロバイダの受信によりすべてのメッセージが自動的に確認応答を受けるわけではなく、それらはメッセージに応答するために上位層へ送信される。上位層が応答したとき、ＷＴＰプロバイダはメッセージを送信したＷＴＰプロバイダへ確認応答を送信する。

上述のように、図１はトランザクション中入力チャネルで伝送されるメッセージを示すだけにすぎない。出力チャネルでも同様のトランザクションが行われる。レスポンダがクラス３ストリーム起動ＰＤＵを受信し、このＰＤＵの確認応答を行った後、ストリーム起動ＰＤＵはＷＴＰプロバイダ（レスポンダ）より上位の１つまたは複数の層に渡されて処理される。結果メッセージが起動メッセージと同じ方法で処理される。データが組み立てられると、ＷＴＰユーザ（レスポンダ）は、ＷＴＰプロバイダ（レスポンダ）内のＴＲ−ストリーム結果リクエストプリミティブを起動することにより結果メッセージの送信を行う。クラス３トランザクション時にストリーム起動メッセージの結果を送信するために、このＴＲ−ストリーム結果プリミティブは使用される。このＴＲ−ストリーム結果プリミティブは以下の表に与えられるパラメータを持つ。

結果メッセージは結果ＰＤＵを用いてイニシエータへ伝送される。そのサイズに応じて、結果メッセージは分割される場合もあれば、分割されない場合もある。結果ＰＤＵが送信された場合、レスポンダは再送タイマを開始し、イニシエータからの確認応答を待機する。イニシエータによる結果ＰＤＵの受信後、ＷＴＰプロバイダ（イニシエータ）はＴＲ結果指示プリミティブを上位のＷＴＰユーザ（イニシエータ）へ転送する。

ＤａｔａＥｎｄ ＴＰＩを含むメッセージが確認応答を受けた後トランザクションは終了する。

最後のメッセージの最後のグループについてレシーバにより最後の確認応答が送信された後、チャネルに関するセンダとレシーバのそれぞれの管理がクリアされる前にセンダとレシーバの双方は待機を行う必要がある。これは、センダが確認応答を受信しなかった場合センダが最後のグループを再送できるようにするためであり、また、センダがその確認応答を受信したことをレシーバが認知できるようにするためである。

図４は、データが拡張された形で伝送されるクラス３トランザクションの一部を示すものである。図１の場合と同じように入力チャネルを介する通信しか示されていない。図４はクラス３トランザクションの開始を示し、このトランザクションではストリーム起動メッセージサイズはネットワーク用ＭＴＵを上回るものではなく、分割は行われない。ＷＴＰユーザ（レスポンダ）によって、ＷＴＰプロバイダ（レスポンダ）内のサービスプリミティブＴＲ−Ｓｔｒｅａｍ ｉｎｖｏｋｅ.ｒｅｑが起動される。データ終端パラメータがＴＲストリーム起動リクエストプリミティブの中にセットされていない場合、イニシエータは少なくとももう１つのＴＲ−ストリーム起動データサービスプリミティブを発信する必要がある。これらについて以下検討する。メッセージが追加パケットに分割されないので、ＷＴＰプロバイダ（イニシエータ）はメッセージ全体を含む起動ＰＤＵをＷＴＰプロバイダ（レスポンダ）へ送信し、ＷＴＰプロバイダ（レスポンダ）はＷＴＰユーザ（レスポンダ）内のサービスプリミティブTR-Stream Invoke.indを起動する。ＷＴＰユーザ（レスポンダ）は、メッセージを受信すると、ＷＴＰプロバイダ（レスポンダ）内のサービスプリミティブTR-Stream Invoke.resを起動する。ＷＴＰプロバイダ（レスポンダ）は、ＰＳＮ０を持つストリームＡｃｋをＷＴＰプロバイダ（イニシエータ）へ送信する。この送信の結果、ＷＴＰプロバイダ（イニシエータ）はTR-Stream Invoke.cnfをＷＴＰユーザ（イニシエータ）の中で起動する。上記ストリームＡｃｋはＭａｘＧｒｏｕｐＳｉｚｅ ＴＰＩを担持している。

次いで、図３の場合、イニシエータは同じトランザクションの範囲内でさらに多くのデータをレスポンダへ送信する。ＷＴＰユーザ（イニシエータ）はTR-Stream Invoke Data.reqサービスプリミティブをＷＴＰプロバイダ（イニシエータ）の中で起動して追加データの送信を行う。ＴＲ−ストリーム起動データ（ストリーム起動データ）サービスプリミティブのパラメータを以下に示す。このプリミティブはクラス３トランザクション時にストリーム起動メッセージのデータを継続するために使用される。

同様に、ストリーム起動メッセージサイズはネットワーク用ＭＴＵを上回るものではなく、従って分割は行なわれない。ＷＴＰプロバイダ（イニシエータ）は分割された起動ＰＤＵをＷＴＰプロバイダ（レスポンダ）へ送信する。このＰＤＵは、トランザクションにおいて次のパケットであるためＰＳＮ１を持っている。次いでＴＴＲフラグがセットされ、このメッセージ内の最後のパケットであること、及び、確認応答がリクエストされたことが示されることになる。ＷＴＰプロバイダ（イニシエータ）は分割された起動ＰＤＵのヘッダの固定部に付けられたＤａｔａＥｎｄ ＴＰＩをＷＴＰプロバイダ（レスポンダ）へ送信する。ＷＴＰプロバイダ（レスポンダ）はＷＴＰユーザ（レスポンダ）内のサービスプリミティブTR-Stream Invoke Data.indを起動する。

ＷＴＰユーザ（レスポンダ）は、起動メッセージを受信したとき、ＷＴＰプロバイダ（レスポンダ）内のサービスプリミティブTR-Stream Invoke Data.resを起動することにより応答を行う。ＷＴＰプロバイダ（レスポンダ）は、ＰＳＮが１であるストリームＰＳＮ ＴＰＩが付されたストリームＡｃｋ ＰＤＵをＷＴＰプロバイダ（イニシエータ）へ送信する。ＷＴＰプロバイダ（イニシエータ）はＷＴＰユーザ（イニシエータ）内のサービスプリミティブTR-Stream Invoke Data.cnfを起動する。

イニシエータに送信対象データがそれ以上なくなるとすぐに、データ終端フラグがＴＲ−ストリーム起動データサービスプリミティブにセットされる。

イニシエータが、ＴＲ−ストリーム起動データサービスプリミティブから開始されたいくつかのさらに多くのデータメッセージを送信する場合、そのメッセージが分割されているか否かにかかわらず、これらのプリミティブが分割されたストリーム起動ヘッダにより与えられる。必要であれば、このメッセージは分割される。ストリーム起動メッセージ後に、クラス３トランザクション追加データがレスポンダへ送信されたとき、分割された起動ＰＤＵがあらゆる場合に用いられる。メッセージの分割を行う必要がない場合、このＰＤＵは１パケットメッセージグループの最後のパケットとなる。

最後のデータメッセージの場合、ＤａｔａＥｎｄ ＴＰＩが最後の分割された起動ＰＤＵのヘッダの固定部に付けられる。メッセージがメッセージストリームの最後のメッセージである場合、データ終端パラメータはストリーム起動及びストリーム起動データサービスプリミティブの中に含まれる。サービスプリミティブパラメータが設定され、したがって、ローカルなＷＴＰにより、この最後のメッセージの最後のＰＤＵにＤａｔａＥｎｄが付けられる。

レスポンダが起動メッセージに応じてデータを取得すると、ＷＴＰユーザ（レスポンダ）は、ＴＲ−ストリーム結果リクエストサービスプリミティブをＷＴＰプロバイダ（レスポンダ）の中で起動することにより結果メッセージの送信を行う。結果メッセージの性質に応じて、結果メッセージを単一メッセージとして送信するか、分割するかのいずれかを行うことが可能である。ストリーム結果メッセージから生成された第１のパケットは結果ＰＤＵヘッダを常に担持し、暗黙のパケット番号ゼロを持つものと想定されている。結果メッセージの分割を行う必要がある場合、結果メッセージは追加の分割されたストリーム結果ＰＤＵで送信される。

ＷＴＰユーザ（レスポンダ）がデータブロックをさらに送信することが必要な場合、この送信はＴＲ−ストリーム結果データサービスプリミティブを発信することにより達成が可能となる。これらのプリミティブによりいくつかのストリーム結果データメッセージの送信が惹起される。このＴＲ−ストリーム結果データサービスプリミティブを以下の表に示す：

たとえメッセージの分割を行う必要がない場合であっても、このサービスプリミティブにより、分割されたストリーム結果ＰＤＵが生成される。この場合、このＰＤＵはメッセージの最初のパケット及び最後のパケットとなり、ＴＴＲフラグが設定される。

ストリーム起動またはストリーム結果メッセージの送信後、ＰＳＮカウンタはデータ伝送の終了までクリアされることはない。

トランザクション中、イニシエータとレスポンダは、トランザクションが終了するまで、別個のストリーム起動データとストリーム結果データメッセージを必要に応じて用いて各々いくつかのデータブロックを伝送してもよい。

レスポンダは、送信対象データがそれ以上なくなるとすぐに、ＷＴＰプロバイダ（レスポンダ）においてＷＴＰユーザ（レスポンダ）により起動され発行されたＴＲ−ストリーム結果の中か、ＴＲ−ストリーム結果データサービスプリミティブの中のいずれかに、データ終端パラメータを設定し、データ終端メッセージ（ＤａｔａＥｎｄ ＴＰＩヘッダが付されたメッセージ）を送信することによりそのトランザクションのその側を閉じる。データ終端パラメータがＴＲ−ストリーム結果リクエストプリミティブの中にセットされない場合、レスポンダは少なくとももう１つのＴＲ−ストリーム結果データサービスプリミティブを発行しなければならない。しかし、レスポンダによるチャネルの終了処理は必ずしもトランザクションの終了であるとはかぎらない。なぜなら、レスポンダは、イニシエータのデータ終端メッセージを受信するまでにイニシエータから追加データを受信する場合もあり得る。イニシエータとレスポンダの双方がそのデータ終端メッセージを送信した場合、トランザクションは終了となる。いずれの場合にも、当事者のいずれか一方がトランザクション打切りサービスプリミティブを起動することにより、トランザクションをいつでも打ち切ることができる。このサービスプリミティブは無線トランザクションプロトコル仕様の中に定義されている。

チャネルの最後のメッセージが受信されたとき最後のＡｃｋ ＰＤＵが送信される。確認応答の送り手は、（例えば確認応答が紛失した場合などに）前回のグループの再送処理を可能にするための状態情報を保持する必要がある。待機タイマを利用することによりこの状態情報の保持が可能である。

受信され、次いで再組立てが行われたメッセージは、送信メッセージに等しいサイズを有する、ＷＴＰプロバイダの上位レベル（ＷＴＰユーザあるいはどこか）へ転送される。

ＷＡＰ規格により定義されるトランザクションクラス１及び２とは異なり、クラス３トランザクションでは、すべてのメッセージが明示的ストリームＡｃｋ ＰＤＵにより確認応答を受け、特定のメッセージを受信した旨が示される。拡大データの転送はオーバーラップする可能性がある（ＤａｔａＥｎｄ ＴＰＩが受信されるまで２つのチャネルが同時に機能している場合がある）。言い替えれば、これはストリーム起動データＰＤＵが１つの方向に進み、同時に、ストリーム結果データＰＤＵが反対方向に進む可能性があることを意味するものである。

ＷＴＰプロバイダ（イニシエータ）は、以前のトランザクションの結果が受信されるまで複数のトランザクションを開始することができる。これらのトランザクションは、以後のトランザクションへの応答の方が以前のトランザクションへの応答よりも前に受信されるといった非同期処理が可能である。

ＰＤＵの固定ヘッダの可変部は１乃至いくつかのＴＰＩから構成されるものであってもよい。ＴＰＩの長さは２乃至８ビットとすることができる。

注１）メッセージの分割と再組立てを行うために分割と再組立てが利用される場合にのみこのＴＰＩは適用可能である。
注２）このＴＰＩはクラス３トランザクションの中でのみ使用される。

エラーＴＰＩはエラーＴＰＩまたはサポートされていないＴＰＩの送り手へ返送される。ＰＤＵヘッダの可変部に少量のデータ（例えばパフォーマンス測定や統計データなど）をピギーバックするためにＩＮＦＯ ＴＰＩが使用される。２つのＷＴＰエンティティ間でパラメータの転送を行うためにオプションＴＰＩが使用される。無線トランスポートプロトコル仕様とは異なり、トランザクション時のいずれかの通信相手が任意の時点に任意のＡｃｋ ＰＤＵで最大グループオプションＴＰＩを送信することができることに留意されたい。また、この最大グループオプションＴＰＩをＴＰＩの次の同じタイプまたはトランザクションの終了まで有効なものとすることが望ましい。ＤａｔａＥｎｄ ＴＰＩを以下のＰＤＵに付けてもよい：
起動ＰＤＵ
結果ＰＤＵ
分割された起動ＰＤＵ
分割されたストリーム結果ＰＤＵ
ＤａｔａＥｎｄ ＴＰＩの意味することはこの方向からトランザクションの通信相手へのデータ伝送がそれ以上存在しないということである。したがって、このＤａｔａＥｎｄ ＴＰＩはこの方向からの最後の番号付きパケットである。ＴＲストリーム起動、ＴＲ−ストリーム結果、ＴＲ−ストリーム起動データあるいはＴＲ−ストリーム結果データサービスプリミティブのいずれかのデータ終端フラグパラメータの設定が行われる場合、最後のメッセージグループの最後のパケットはこのＤａｔａＥｎｄ ＴＰＩを担持する。その構造は以下の通りである：

クラス３トランザクションでは、Ａｃｋ ＰＤＵはパケットシーケンス番号フィールドを持たず、ストリームパケットシーケンス番号ＴＰＩがＡｃｋ ＰＤＵヘッダの可変部への付属部として利用される。ＴＰＩは上述の２つの伝送方法の場合異なるものとなる。伝送方法１では、Ａｃｋ ＰＤＵの中に含まれるＰＳＮは応答確認済みパケット（ＧＴＲパケット）のＰＳＮである。この確認応答はグループ内で累積され、グループ内のすべてのパケットが着信したが、このグループ以外の前回のパケットがすべて受信されわけではない旨の確認応答が行われる。伝送方法２では、Ａｃｋ ＰＤＵの中に含まれるＰＳＮは応答確認済みパケット（ＧＴＲまたはＴＴＲパケット）のＰＳＮである。

図５は有効なプリミティブシーケンスの表を示す。各行の先頭にあるサービスプリミティブには、Ｘでマークされる列の中の対応するサービスプリミティブだけが後続することができる。データ終端（End-Of-Data）はサービスプリミティブ内にセットされたフラグを示す。この表は許されるシーケンスを全体的に示すものである。

ＷＳＰ層のレベルでのクラス３トランザクションの利用に関わるステップについて以下説明する。図４は、セッション層の関与を示すために、センダとレシーバ内のより上位の層のレベルでの図３のストリーム起動トランザクションを示す。図４は、センダとレシーバの各々ＷＳＰプロバイダ内のＷＳＰユーザにより起動されるセッション層サービスプリミティブを示す。

サーバにより実行される動作をリクエストするためにＳ−ストリームメソッド起動プリミティブが用いられる。Ｓ−ストリームメソッド起動プリミティブはＳメソッド結果サービスプリミティブと共にしか用いることができない。

データ終端フラグはさらに多くのデータ（リクエストボディの続き）が存在するかどうかを示す。データ終端フラグが設定された場合、これはストリーム起動メッセージにより送信されたデータのすべてである。

開始された動作リクエストのリクエストボディの続きをサーバへ送信するために、Ｓ−ストリーム起動データサービスプリミティブが使用される。先行するＳ−ストリームメソッド起動プリミティブのデータ終端フラグが０になった後にしか、Ｓ−ストリーム起動データサービスプリミティブは起動することはできない。

データ終端フラグはさらに多くのデータ（リクエストボディの続き）が存在するかどうかを示す。データ終端フラグが設定され場合、これは最後の送信データである。

Ｓ−ストリーム結果サービスプリミティブは動作リクエストに対する応答を返送するために用いられる。Ｓ−ストリーム結果サービスプリミティブは先行するＳ−ストリームメソッド起動プリミティブが生じた後にしか起動することはできない。

データ終端フラグはさらに多くのデータ（レスポンスボディの続き）が存在するかどうかを示す。データ終端フラグが設定された場合、これはこのストリーム結果メッセージで送信されたデータのすべてである。

Ｓ−ストリーム結果データプリミティブは、追加の応答データを動作リクエストへ返送するために使用される。Ｓ−ストリーム結果データプリミティブは、先行するＳ−ストリーム起動プリミティブが生じた後にしか、起動することができない。

データ終端フラグはさらに多くのデータ（レスポンスボディの続き）が存在するかどうかを示す。データ終端フラグが設定された場合、これは送信されたデータのすべてである。

Ｓ−ストリームメソッド起動ファシリティでは、以下のＰＤＵすなわちＧｅｔ、Ｐｏｓｔ、Ｒｅｐｌｙが使用される。これらのＰＤＵはＷＡＰ規格の中に定義されている。

別のトランザクションの一例としてストリームプッシュトランザクションがある。このストリームプッシュトランザクションもクラス３ＷＴＰトランザクションを利用するものであるが、イニシエータの役割を行う。ストリーム起動トランザクションとは対照的にストリームプッシュトランザクションは１方向のみのトランザクションである。サーバがトランザクションを開始し、クライアントはレスポンダである。上述のデータストリームの任意の形で多量のデータをプッシュすることができる。サーバのみがクライアントへデータを送信するので、レスポンダ用チャネルは自動的に閉じられる。

ストリームプッシュトランザクションで使用されるサービスプリミティブは以下に定義される：
Ｓストリームプッシュ

Ｓストリームプッシュデータ

Ｓ−ストリームプッシュファシリティでは、ＷＡＰ規格で定義されたようなＰＤＵ確認プッシュＰＤＵが利用される。

これらのオプションのファシリティ、プッシュ、確認プッシュ、一時停止、及び、再開および確認応答ヘッダを提供するために、ＷＳＰに対する変更を行う必要がある。特に、２つのプロトコルオプションフラグを追加しなければならない。さらに、２つのさらなる能力（最大未解決ストリームメソッドリクエスト並びに最大未解決ストリームプッシュリクエスト）が導入される。

第１の起動メッセージがレスポンダにより受信される前に、イニシエータによる第１の起動メッセージ送信、次いで、第２の起動メッセージの送信（ストリーム起動メッセージ）が可能である。レスポンダは、第１に受信する起動メッセージが新しいＴＩＤを持つが、トランザクションが正しく開始されない場合もあるということに気づくことになる。その場合、レスポンダは第２の起動メッセージを棄却する代わりにそれを格納し、起動メッセージを待機する。

クラス３トランザクションのいくつかのＰＤＵの連鎖が提供される場合もある。この連鎖は、ＷＡＰ規格により定義されるようなその他のクラスに対する連鎖と同じルールを利用するものである。

本発明は移動端末装置、ＷＡＰプロトコルスタック、ＷＡＰサーバあるいはＷＡＰゲートウェイの中に一体化して組み込むことが可能である。

図６は、インターネット４へのアクセスを行う複数の移動端末装置２を有する通信システムを示す。移動端末装置は、無線ネットワーク８により、及び、無線ネットワーク８を介して受信される信号６を伝送する。これらの信号には、ＷＡＰに準拠する無線マークアップ言語（ＷＭＬ）とＷＡＰコマンドとが含まれる。ＷＭＬは、ナビゲーションサポート、データ入力、ハイパーリンク、テキスト及び画像プレゼンテーション及びフォームを出力するタグベースの表示言語である。ＷＭＬはＨＭＴＬと類似する閲覧用言語である。ネットワーク８により受信された信号１０はプロキシサーバまたはゲートウェイサーバ１２への経路選定を行う。サーバ１２によってＷＡＰリクエストはＨＴＴＰリクエストに変換され、それによって移動端末装置２はウェブサーバ１４から情報をリクエストし、したがってインターネット４の閲覧が可能となる。ウェブサーバ１４から得られた情報はゲートウェイにより符号化され、好適なフォーマットに変えられ、次いで、この情報をリクエストした移動端末装置２へ無線ネットワークにより伝送される。移動端末装置２はこの情報を処理し、利用する。ウェブサーバ１４がＷＡＰ/ＷＭＬフォーマットでコンテンツを出力した場合、サーバ１２はウェブサーバ１４から直接このようなコンテンツの検索を行うことが可能となる。しかし、ウェブサーバが（ＨＴＭＬなどの）ＷＷＷフォーマットでコンテンツを出力した場合、フィルタを用いてＷＷＷフォーマットからＷＡＰ／ＷＭＬフォーマットへそのコンテンツを変換することも可能である。

図６はインターネットから得られる情報を示すものではあるが、ゲートウェイ自体が所望の情報を含むものであってもよい。例えば、クライアントはゲートウェイのファイルシステムから情報の検索を行うことも可能である。

図７は、コンピュータ２０のようなハードウェアの中に具現化されたゲートウェイサーバを示す。コンピュータ２０は、ダイナミックメモリ、処理パワー、及び、アプリケーションプログラム、プロトコルスタック及びオペレーティングシステムのような、ゲートウェイサーバの実行に必要なプログラムのすべてを格納するためのメモリを有する。コンピュータ２０は、キーボード２２とディスプレイ（図示せず）及びサービスプログラム２４などのようなユーザーインターフェースを具備する。サービスプログラム２４は、サーバからのＷＭＬ検索リクエストの処理などの基底にあるプロトコルのイベント用アプリケーションプログラム２６と、ＷＡＰプロトコルスタック２８及びＨＴＴＰプロトコルスタック３０などのようなプロトコルスタックとを有する。アプリケーションプログラム２６は、電話網３２、インターネット３４及びデータネットワークと回線交換データネットワーク３５を含む様々なネットワーク間のコマンド、リクエスト、及び、情報を含むデータフローの制御を行う。コンピュータ２０はＨＴＴＰプロトコルスタック３０とインターフェース３６を介してインターネット３４と交信を行う。コンピュータ２０はインターフェース３８と４０とを介して電話網３４とデータネットワーク３５との交信を行う。サービスプログラム２４にはＨＴＴＰとＷＡＰとの間の変換を行うアプリケーション４２も含まれる。通信事業者のネットワークとの適切なハードウェアを通じるデータコネクションを介してＳＭＳメッセージ通信を行うことも可能である。

アプリケーションプログラム２６とＷＡＰプロトコルスタック２８の中に存在する個々のスレッド４４は、コンピュータ２０内のプロセッサ４６を利用して必要な処理タスクを実行する。コンピュータ２０のオペレーティングシステム５０の範囲内に存在するスレッドサービス４８により、プロセッサへのスレッドの割当てが行われる。

ＷＡＰスタックは（データグラムサービスを提供する）いわゆるベアラの上位に組み立てられる。これらのベアラは、例えば、ＳＭＳやＣＳＤであってもよい。これらのベアラはそれ自身のプロトコルを持ち、プロトコルスタックの実現を通じて実現される。

図８は移動端末装置６０の実施態様を示す。移動端末装置６０は、中央演算処理装置（ＣＰＵ）６２、送受信装置６４、コンテンツの格納用メモリ６６、ＷＡＰマイクロブラウザ及び送受信装置６４、ディスプレイ７０、移動端末装置の電話関連機能用メモリ７２を介してデータ転送の制御を行うための関連するプロトコル６８を具備する。電話コールを行う際の送受信装置６４の動作については説明しない。というのはこれは移動端末装置６０の従来方式の電話活動に関する事柄であるからである。ＣＰＵ６２はその他の要素の動作の制御を行う。

図９は図６の通信システムを示す。図９は、クライアント（例えば移動端末装置、ゲートウェイ、サーバ（この場合ウェブサーバなど））の細部を示す別の図を示す。

以下に、双方向のメッセージストリーミングを用いてＷＡＰを利用する１つの実施例で利用可能な本発明のアプリケーションの若干を提案する。言うまでもなく、アプリケーションレベルでクラス３の機能が実現されているものであれば、これらのアプリケーションのほとんどは既存のＷＡＰスタックを用いて実行可能である。

データ転送に関わるトランザクション実行時に、多量データの伝送及びトランザクションの順序という２つの主要考慮事項が存在する。一続きのメッセージの伝送により多量のデータの連続転送が可能になり、さらに、順序づけられたイベントの伝送が可能になる。いくつかのトランザクションを利用する場合、メッセージの送受信の順序は保証されない。したがって、アプリケーションレベルでこの順序の制御を行う必要がある。多くのアプリケーションは、最初の着信が最初に送信されるイベントを伴う少量データの転送を必要とするので順序づけられたイベントの伝送が重要である。

本発明はテレビ会議への適用が可能である。配信センターとして機能するＷＡＰ利用可能サーバと接続された多数のクライアントを持つようなテレビ会議システムが提供される。各クライアントは、個々の画像またはフレームのストリームの送受信用サーバと２方向ストリームにより接続される。ストリーミングが役に立つためフレームの順序が重要となり、ストリーミングがない場合には、アプリケーション自身がフレームの順序を再構成する必要がある。テレビ会議をＷＡＰと組み合わせると好適である。情報の選択、情報の伝送及び会議のリンクを行うためにＷＭＬデッキとして高度のユーザーインターフェースを設けることが可能である。このサービス全体に単一のＷＡＰサーバを設けることが可能である。ＷＡＰベースのビデオサービス用の別の重要な応用領域として、ブルートゥースサービスがある。この場合トランスポートプロトコルとして、ビデオ情報のブラウズ／アクセスを行うためのＷＡＰの利用が可能である。

別の実施態様では、家庭用装置または別の装置にミニＷＡＰサーバが設けられ、ＷＡＰ利用可能クライアントからのアクセスが可能になる。一例として、ＷＡＰ利用可能のボイスメールサービスがある。このボイスメールサービスにより、メッセージの状態を閲覧するためのＷＡＰブラウザからの接続が可能になり、さらに、メッセージの聴取が可能になる。クライアントからサーバへのチャネルがコマンド送信制御チャネルとして利用され、サーバからクライアントへチャネルを介して音声のストリーミングが行われる。装置へ送信されるコマンドは、スキップメッセージ、削除メッセージ等々を含むものであってもよい。

さらに別の実施態様では、遠隔制御システムや遠隔測定システムが提供され、その場合、クライアントは、ストリームの形で着信する（リアルタイム圧力データなどの）測定データを出力する中央処理サーバと接続し、この制御用サーバはストリームの形で制御情報や要約情報を返送する。ストリームがサポートされたＷＡＰの利用が可能なシステムであれば、ＷＡＰが利用可能なクライアントを持つＷＡＰサーバの形でのシステムの実現も可能である。

さらに別の実施態様では、サーバーベースのゲーム用システムが提供される。このようなマルチプレイヤーゲームシステムでは、クライアントが接続した集中型ゲームサーバーが提供される。リアルタイムのアクションゲームの場合には、ストリーム様フォーマットで情報が送受信され、その場合イベントの順序が重要となる。例えば、プレイヤーは、“殺された”後リアルタイムでの通信が許されなくなる場合がある。ゲームサーバーとクライアントとは、イベントが順に着信することを保証する双方向ストリームプロトコルを用いて接続されていてもよい。

さらなる実施態様では、ＷＡＰベースのインテリジェントマップ／所在位置測定サービスを有するシステムが提供される場合もある。このシステムでは、所在位置情報ストリームがサーバへ送信され、このサーバが今度は地図及び地図座標データを返送する。（都市における車の追尾、あるいは、歩行者が特定のショップを見つけることができるようするための歩行者の追尾の場合ように）追尾が非常にきめ細くなることに起因して、所在位置の更新が頻繁な場合、双方向のストリームを利用してトランザクションの順序の保存が行われる。

さらに別の実施態様では、本発明を利用してインターネットベースのマルチメディアアプリケーションへのアクセスを行うことも可能である。このようなアプリケーションでは、クライアントとの接続用としてＴＣＰストリームが利用される。このようなアプリケーション（ＲｅａｌＡｕｄｉｏサービスなど）がＷＡＰ利用可能クライアントと接続された場合、ストリーム様ＴＣＰのトランザクション型ＷＴＰへの変換を試みる代わりに、ＷＡＰ内のストリーム様（メッセージシーケンス）サポートの利用が可能となる。

さらに別の実施態様では、音声コマンドの受信及び／又は音声メッセージのユーザへの送信を行う音声制御ＷＡＰサービスの提供も可能である。サービス特定コマンドセットの音声認識は、処理パワーと重量という点から軽量の端末装置用として提供するには困難な場合もある。本発明を利用することにより、出力チャネルでの音声データをＷＡＰサーバへ送信することが可能となり、優れた認識／言語選択の達成が可能となる。同様に、戻りチャネルを利用して応答として音／声データを伝えることが可能となる。

本発明は、単一のトランザクションの範囲内で任意の長さのメッセージシーケンスの出力に利用可能な新しいトランザクションクラスを提供するものである。本発明は、新しいトランザクションクラス３の新しい特徴に加えて、ＷＡＰ規格のすべての特徴が保持されているので、ＷＡＰ規格との互換性を有する。クラス３トランザクションの特定及び処理は別個に行うことも可能である。エラー、バージョン及びＴＩＤの処理方法はＷＡＰ規格の場合と同じである。

クラス３トランザクションでは、メッセージの処理手順は現行の分割及び再組立て処理を利用する。したがって、個々のＳＡＲ処理を定義する必要はない。しかし、本発明では２つの方法で現行の分割及び再組立てが利用されることに留意されたい。本発明では、メッセージがパケットに分割されるクラス２の方法と類似した方法で分割及び再組立てが利用される。さらに本発明では、分割及び再組立てが特定のメッセージに適用されるか否かに関係なく、メッセージのストリームを送信するために分割及び再組立ても利用される。いずれの場合にもＰＳＮが常時使用される。これは唯一のパケットしか存在しない場合、分割及び再組立てが適用されないクラス２のトランザクションとは対照的である。

ＷＡＰに関して本発明を説明してきたが、通信プロトコルに基づく他のいずれのトランザクションに対しても本発明の適用が可能である。例えば、本発明はＩＰネットワークでの閲覧に対して適用が可能である。本発明は特に無線ネットワークに適しているが、有線ネットワークにも適用可能である。

本発明の特定の実現及び実施態様について解説した。本発明が如上の実施態様の細部に限定されるものではなく、本発明の特徴から逸脱することなく同等の手段を用いて別の実施態様での実現が可能であることは当業者には明らかである。本発明の範囲は添付の特許請求項のみによって限定されるものである。

Claims (33)

1. 各メッセージがサービスデータ単位を表し、かつ、少なくとも１つのデータパケットを含む複数のデータメッセージの形で、無線トランザクション・プロトコル（ＷＴＰ）層上の無線リンクを介して、レシーバにデータを伝送するステップであって、トランザクションの各データパケットが同じトランザクション識別子を有する、ステップと、
   信頼性のあるコネクションを提供するように、前記無線トランザクション・プロトコル（ＷＴＰ）層上で、データパケットの受信確認を、前記無線リンクを介して、前記レシーバから受信するステップと、
   対応する前記サービスデータ単位の伝送を示すように、各データメッセージにおいて最後のデータパケットであることを前記レシーバに通知するステップと、
   前記複数のデータメッセージの最後のデータメッセージであることを前記レシーバに通知するステップと、を含む方法。
2. データが所定長ではない、請求項１に記載の方法。
3. メッセージの任意の長さのストリーム様シーケンスの伝送がトランザクションの内部に存在する、請求項２に記載の方法。
4. 前記データの転送中に、パケットシーケンス番号によって前記データパケットに連続的に番号づけが行われる、請求項１ないし３のいずれか１項に記載の方法。
5. 各メッセージが、連続するパケットシーケンス番号を有するパケットを含み、
   前記パケットシーケンス番号の前記シーケンスが、１つのメッセージから次のメッセージへ連続する、請求項４に記載の方法。
6. 前記パケットシーケンス番号がラップアラウンドする、請求項４ないし５のいずれか１項に記載の方法。
7. 前記データの分割と再組立てとが行われる、請求項１ないし６のいずれか１項に記載の方法。
8. センダと前記レシーバとの間の通信が、前記トランザクションの範囲内で双方向である、請求項１ないし７のいずれか１項に記載の方法。
9. ２つのチャネルであって、一方のチャネルはイニシエータからレスポンダへデータを伝送するものであり、他方のチャネルは反対方向にデータを伝送するものである、２つのチャネルが設けられる、請求項８に記載の方法。
10. 前記データの最後のメッセージの送信により、前記チャネルうちの少なくとも一方が閉じられる、請求項９に記載の方法。
11. 双方のチャネルの終了処理が行われた場合、前記トランザクションの終了処理が行われる、請求項９または１０に記載の方法。
12. 前記データパケットがパケットのグループで送信される、請求項１ないし１１のいずれか１項に記載の方法。
13. 前記レシーバが、前記グループからすべてのパケットを受信したとき、グループ全体の確認応答を行う、請求項１２に記載の方法。
14. 前記レシーバは、前記グループの残りのパケットが受信されたことを確認したとき、グループの最後のパケットの確認応答を行う、ことを特徴とする請求項１３に記載の方法。
15. 前回のグループの確認応答が受信される前に、後続グループのパケットを送信することができる点において未解決パケットグループが存在し得る、請求項１２ないし１４のいずれか１項に記載の方法。
16. 未解決パケットグループが存在できない、請求項１２ないし１４のいずれか１項に記載の方法。
17. パケットグループの終りを示すパケットの受信前に、欠落パケットを通知する第１のメッセージが送信される、請求項１６に記載の方法。
18. パケットグループの終りを示す前記パケットが受信され、前記欠落パケットがまだ受信されていない場合、前記欠落パケットを通知する第２のメッセージが送信される、請求項１７に記載の方法。
19. グループのパケットが送信バーストで送信され、特定グループの完了を通知するパケットが、前記特定グループのいくつかのパケットを含む前記送信バーストの中に含まれない、請求項１６ないし１８のいずれか１項に記載の方法。
20. 特定グループの完了を通知する前記パケットが後続グループで送信される、請求項１９に記載の方法。
21. 前回のグループの前記パケットのすべてについて確認応答が受信された場合に、特定グループの完了を通知する前記パケットが送信されるだけである、請求項１９または２０に記載の方法。
22. １つの信頼性の高い起動メッセージと１つの信頼性の高い結果メッセージとを有する新しいトランザクションクラスであり、前記起動と結果メッセージとが信頼性の高いデータメッセージにより条件つきで拡張される、請求項１ないし２１のいずれか１項に記載の方法。
23. 前記トランザクションが、起動メッセージによりいったん開始された場合、
    ストリームデータメッセージにより継続される、請求項１ないし２２のいずれか１項に記載の方法。
24. センダがデータの終了を示すＴＰＩを送信し、該ＴＰＩが前記レシーバに受信されるとき、１つのチャネルを介するデータ伝送の終了処理が行われ、該データ伝送がレシーバにより受信される、請求項１ないし２３のいずれか１項に記載の方法。
25. 任意の１時点に未解決の２つ以上のトランザクションが存在する、請求項１ないし２４のいずれか１項に記載の方法。
26. 単一セッションの中に存在するいくつかの非同期トランザクションが存在する、請求項１ないし２５のいずれか１項に記載の方法。
27. トランザクションの第１のメッセージが、前記トランザクションが任意の長さを持つデータストリームを有することを示すトランザクションクラスパラメータを含む起動ＰＤＵである、請求項１ないし２６のいずれか１項に記載の方法。
28. 各メッセージがサービスデータ単位を表し、かつ、少なくとも１つのデータパケットを含む複数のデータメッセージの形で、無線トランザクション・プロトコル（ＷＴＰ）層上の無線リンクを介して、レシーバでデータを受信するステップであって、前記トランザクションの各データパケットが同じトランザクション識別子を有する、ステップと、
    信頼性のあるコネクションを提供するように、前記無線トランザクション・プロトコル（ＷＴＰ）層上で、前記レシーバによりデータパケットの確認応答を行うステップと、
    対応する前記サービスデータ単位の伝送を示すように、前記レシーバにおける各データメッセージの最後のデータパケットであることの通知を受信するステップと、
    前記複数のデータメッセージの最後のデータメッセージであることの通知を前記レシーバにおいて受信するステップと、を含む方法。
29. 各メッセージがサービスデータ単位を表し、かつ、少なくとも１つのデータパケットを含むように構成される複数のデータメッセージの形のデータ伝送を行うための移動端末装置（２、６０）であって、トランザクションの各データパケットが同じトランザクション識別子を有し、
    前記移動端末装置は、メモリ内に含まれるアプリケーション（２６）と、無線トランザクション・プロトコル（ＷＴＰ）のプロトコルスタック（６８）を具備し、
    前記アプリケーションと前記プロトコルスタックとが、前記移動端末装置とレシーバ（１２）との間で無線リンク（６）を介してトランザクションを実行し、
    前記移動端末装置は、前記メッセージを前記レシーバへ順に送信し、信頼性のあるコネクションを提供するように、前記無線トランザクション・プロトコル（ＷＴＰ）層上で、前記パケットの受信の確認応答を、無線リンクを介して、前記レシーバから受信し、
    対応する前記サービスデータ単位の伝送を示すように、各データメッセージにおいて最後のデータパケットであることを前記レシーバに通知し、
    前記複数のデータメッセージの最後のデータメッセージであることを前記レシーバに通知するように構成される、移動端末装置。
30. 各メッセージがサービスデータ単位を表し、かつ、少なくとも１つのデータパケットを含む複数のデータメッセージの形のデータ伝送を行うゲートウェイ（１２、２０）であって、トランザクションの各データパケットが同じトランザクション識別子を有し、
    メモリ内に含まれるアプリケーション（２６）と、無線トランザクション・プロトコル（ＷＴＰ）のプロトコルスタック（２８）を具備し、
    前記アプリケーションと前記プロトコルスタックとが、前記ゲートウェイとレシーバ（２、６０）との間で無線リンク（６）を介して、トランザクションを実行し、
    前記ゲートウェイは、前記メッセージを前記レシーバへ順に送信し、
    信頼性のあるコネクションを提供するように、前記無線トランザクション・プロトコル（ＷＴＰ）層上で、前記パケットの受信の確認応答を、無線リンクを介して、前記レシーバから受信し、
    対応する前記サービスデータ単位の伝送を示すように、各データメッセージにおいて最後のデータパケットであることを前記レシーバに通知し、
    前記複数のデータメッセージの最後のデータメッセージであることを前記レシーバに通知するように構成される、ゲートウェイ。
31. 少なくとも１つの移動端末装置（２、６０）を有するデータ伝送システムであって、移動端末装置は、メモリ内に含まれるアプリケーション（２６）と、
    無線トランザクション・プロトコル（ＷＴＰ）のプロトコルスタック（６８）と、を備え、
    各メッセージがサービスデータ単位を表し、
    少なくとも１つのデータパケットを具備するように構成される複数のデータメッセージの形のデータの受信が可能であり、トランザクションの各データパケットが同じトランザクション識別子を有し、
    前記移動端末装置の前記アプリケーション及び前記プロトコルスタックは、
    ゲートウェイ（１２、２０）を備えた無線リンク（６）を介して任意数のデータメッセージを有するトランザクションの実行が可能であり、
    前記ゲートウェイは、前記移動端末装置へ順に、無線トランザクション・プロトコル（ＷＴＰ）層上で、前記メッセージを送信することが可能であり、
    前記移動端末装置は、信頼性のあるコネクションを提供するように、無線トランザクション・プロトコル層上の無線リンクを介して、前記パケットの受信の確認応答が可能であり、
    前記ゲートウェイは、対応する前記サービスデータ単位の伝送を示すように、各データメッセージにおいて最後のデータパケットであることを前記移動端末装置に通知することが可能であり、
    前記ゲートウェイは、前記複数のデータメッセージの最後のデータメッセージであることを前記移動端末装置に通知することが可能である、データ伝送システム。
32. 少なくとも１つの移動端末装置（２、６０）を有するデータ伝送システムであって、前記移動端末装置は、
    メモリ内に含まれるアプリケーション（２６）と、無線トランザクション・プロトコル（ＷＴＰ）のプロトコルスタック（６８）を備え、
    各データメッセージがサービスデータ単位を表し、かつ、少なくとも１つのデータパケットを具備するように構成される複数のデータメッセージの形のデータの伝送が可能であり、トランザクションの各データパケットが同じトランザクション識別子を有し、
    前記アプリケーション及び前記プロトコルスタックは、ゲートウェイ（１２、２０）を備えた無線リンク（６）を介して任意数のデータメッセージを有するトランザクションの実行が可能であり、
    前記移動端末装置は、前記メッセージを前記ゲートウェイへ順に送信することが可能であり、
    前記ゲートウェイは、信頼性のあるコネクションを提供するように、無線トランザクション・プロトコル層上の無線リンクを介して、前記パケットの受信確認応答を行うことが可能であり、
    前記移動端末装置は、対応する前記サービスデータ単位の伝送を示すように、各データメッセージにおいて最後のデータパケットであることを前記ゲートウェイに通知することが可能であり、
    前記移動端末装置は、前記複数のデータメッセージの最後のデータメッセージであることを前記ゲートウェイに通知することが可能である、データ伝送システム。
33. コンピュータプログラムコードを格納するコンピュータ可読記憶媒体であって、該コンピュータプログラムコードが、センダとレシーバ（２、１２）の間で無線リンク（６）を介してトランザクションをコンピュータに実行させるコンピュータ可読プログラム手段であって、前記トランザクションが、各メッセージがサービスデータ単位を表し、少なくとも１つのデータパケットを含む複数のデータメッセージを含む伝送データを有し、トランザクションの各データパケットが同じトランザクション識別子を有する、コンピュータ可読プログラム手段と、
    前記センダに、前記メッセージを前記レシーバへ順に無線トランザクション・プロトコル（ＷＴＰ）層上で、送信させるコンピュータ可読プログラム手段と、
    信頼性のあるコネクションを提供するように、前記無線トランザクション・プロトコル（ＷＴＰ）層上の前記無線リンクを介して、前記レシーバにパケットの受信確認応答を行わせるコンピュータ可読プログラム手段と、
    対応する前記サービスデータ単位の伝送を示すように、最後のデータパケットであることの前記レシーバへの通知を前記センダに行わせるコンピュータ可読プログラム手段と、
    前記複数のデータメッセージの最後のデータメッセージであることの前記レシーバへの通知を前記センダに行わせるコンピュータ可読プログラム手段と、を備える、コンピュータ可読記憶媒体。

Images