センダとレシーバ間のリンクを介するトランザクションを実行し、複数のデータメッセージの形のデータ伝送を行う方法であって、各メッセージが少なくとも1つのデータパケットを含む方法であって、レシーバが信頼性のあるコネクションを提供するためにデータパケットを受信した旨の確認応答を発信するステップと、センダが各データメッセージにおいてレシーバに最後のデータパケットであることを通知するステップと、センダが最後のデータメッセージであることをレシーバに通知するステップと、を有することを特徴とする方法。データが所定長ではないことを特徴とする請求項1に記載の方法。メッセージの任意の長さのストリーム様シーケンスの伝送がトランザクションの内部に存在することを特徴とする請求項2に記載の方法。データの転送中パケットシーケンス番号によってデータパケットに連続的に番号づけが行われることを特徴とする請求項1~3のいずれか1項に記載の方法。パケットシーケンス番号がラップアラウンドすることを特徴とする請求項5に記載の方法。データの分割と再組立てとが行われることを特徴とする請求項1~5のいずれか1項に記載の方法。センダとレシーバの間の通信がトランザクションの範囲内で双方向であることを特徴とする請求項1~6のいずれか1項に記載の方法。2つのチャネルであって、一方のチャネルはイニシエータからレスポンダへデータを伝送するようにし、他方のチャネルは反対方向にデータを伝送するように成す2つのチャネルが設けられることを特徴とする請求項7に記載の方法。データの最後のメッセージの送信によりチャネルうちの少なくとも一方が閉じられることを特徴とする請求項8に記載の方法。双方のチャネルの終了処理が行われた場合、トランザクションの終了処理が行われることを特徴とする請求項8または9に記載の方法。パケットがパケットのグループで送信されることを特徴とする請求項1~10のいずれか1項に記載の方法。レシーバがグループからすべてのパケットを受信したとき、グループ全体の確認応答を発信することを特徴とする請求項11に記載の方法。レシーバは、グループの残りのパケットが受信されたことを確認したとき、グループの最後のパケットの確認応答を発信することを特徴とする請求項12に記載の方法。前回のグループの確認応答が受信される前に、後続グループのパケットを送信することも可能である点において未解決パケットグループが存在し得ることを特徴とする請求項11乃至13のいずれか1項に記載の方法。未解決パケットグループが存在できないことを特徴とする請求項11乃至13のいずれか1項に記載の方法。パケットグループの終りを示すパケットの受信前に、欠落パケットを通知する第1のメッセージが送信されることを特徴とする請求項15に記載の方法。パケットグループの終りを示すパケットが受信され、欠落パケットがまだ受信されていない場合、欠落パケットを通知する第2のメッセージが送信されることを特徴とする請求項16に記載の方法。グループのパケットが送信バーストで送信され、特定グループの完了を通知するパケットが特定グループのいくつかのパケットを含む送信バーストの中に含まれないことを特徴とする請求項15乃至17のいずれか1項に記載の方法。特定グループの完了を通知するパケットが後続グループで送信されることを特徴とする請求項18に記載の方法。前回のグループのパケットのすべてについて確認応答が受信された場合にのみ、特定グループの完了を通知するパケットが送信されることを特徴とする請求項18または19に記載の方法。1つの信頼性の高い起動メッセージと1つの信頼性の高い結果メッセージとを有する新しいトランザクションクラスであり、起動と結果メッセージとが信頼性の高いデータメッセージにより条件つきで拡張されることを特徴とする請求項1~20のいずれか1項に記載の方法。トランザクションが、起動メッセージによりいったん開始された場合、ストリームデータメッセージにより継続されることを特徴とする請求項1~21のいずれか1項に記載の方法。センダがデータの上記終了を示すTPIを送信したとき1つのチャネルを介するデータ伝送の終了処理が行われ、該データ伝送がレシーバにより受信されることを特徴とする請求項1~22のいずれか1項に記載の方法。任意の1時点に未解決の2つ以上のトランザクションが存在することを特徴とする請求項1~23のいずれか1項に記載の方法。単一セッションの中に存在するいくつかの非同期トランザクションが存在することを特徴とする請求項1~24のいずれか1項に記載の方法。リンクが無線リンクであることを特徴とする請求項1~25のいずれか1項に記載の方法。無線トランザクションプロトコル規格に準拠して行われることを特徴とする請求項1~26のいずれか1項に記載の方法。各メッセージが少なくとも1つのデータパケットを含む複数のデータメッセージの形のデータ伝送を行うための移動端末装置であって、メモリ内に含まれるアプリケーション、及び、プロトコルスタックを具備し、アプリケーションとプロトコルスタックとは、センダとレシーバの間で無線リンクを介してトランザクションを実行し、センダはメッセージをレシーバへ順に送信し、レシーバは信頼性のあるコネクションを提供するためにパケットを受信した旨の確認応答を発信し、センダは各データメッセージにおいて最後のデータパケットであることをレシーバに通知し、センダは最後のデータメッセージであることをレシーバに通知することを特徴とする移動端末装置。各メッセージが少なくとも1つのデータパケットを含む複数のデータメッセージの形のデータ伝送を行うためのゲートウェイであって、メモリ内に含まれるアプリケーション、及び、プロトコルスタックを具備し、アプリケーションとプロトコルスタックはセンダとレシーバの間で無線リンクを介してトランザクションを実行し、センダはメッセージをレシーバへ順に送信し、レシーバは信頼性のあるコネクションを提供するためにパケットを受信した旨の確認応答を発信し、センダは各データメッセージにおいて最後のデータパケットであることをレシーバに通知し、センダは最後のデータメッセージであることをレシーバに通知することを特徴とするゲートウェイ。複数のデータメッセージの形のデータ受信を行うための複数の移動端末装置を有するデータ伝送システムであって、各移動端末装置はメモリ内に含まれるアプリケーション、及び、プロトコルスタックを具備し、アプリケーションとプロトコルスタックとは、ゲートウェイとの無線リンクを介してトランザクションを実行し、ゲートウェイは移動端末装置へメッセージを順に送信し、移動端末装置はパケットを受信した旨の確認応答を発信して信頼性のあるコネクションを提供し、ゲートウェイは各データメッセージにおいて最後のデータパケットであることを移動端末装置に通知し、ゲートウェイは最後のデータメッセージであることを移動端末装置に通知することを特徴とするデータ伝送システム。複数のデータメッセージの形のデータ伝送を行うための複数の移動端末装置を有するデータ伝送システムであって、各移動端末装置はメモリ内に含まれるアプリケーション、及び、プロトコルスタックを具備し、アプリケーションとプロトコルスタックとは、ゲートウェイとの無線リンクを介してトランザクションを実行し、移動端末装置はゲートウェイへメッセージを順に送信し、ゲートウェイはパケットを受信した旨の確認応答を発信して信頼性のあるコネクションを提供し、移動端末装置は各データメッセージにおいて最後のデータパケットであることをゲートウェイに通知し、移動端末装置はゲートウェイに最後のデータメッセージであることを通知することを特徴とするデータ伝送システム。コンピュータ可読媒体に格納されたコンピュータプログラム製品であって、センダとレシーバの間で無線リンクを介してトランザクションをコンピュータに実行させるコンピュータ可読プログラム手段であって、トランザクションが複数のデータメッセージを含む伝送データを有するコンピュータ可読プログラム手段と、センダに、レシーバへメッセージを順に送信させるコンピュータ可読プログラム手段と、レシーバにパケットを受信した旨の確認応答を発信させて、信頼性のあるコネクションを提供するコンピュータ可読プログラム手段と、最後のデータパケットであることのレシーバへの通知をセンダに行わせるコンピュータ可読プログラム手段と、最後のデータメッセージであることのレシーバへの通知をセンダに行わせるコンピュータ可読プログラム手段と、を有することを特徴とするコンピュータプログラム製品。1つの実施例では、本発明は、任意の長さのデータ伝送を可能にするWAP規格用の新しいトランザクションクラスを提供する。この新しいクラスはクラス3である。このようなデータは、テレビ会議から発信するデータストリームである場合もあれば、マルチメディア用ストリームである場合もあれば、ソフトウェアのダウンロードである場合もある。クラス3トランザクションについて以下説明する。以下のサービスプリミティブがクラス3トランザクション中用いられる:TR-ストリーム起動Invoke;TR-ストリーム結果Result;TR-ストリーム起動データ;TR-ストリーム結果データ;TR-アボート‘TR-’というプレフィックスは、サービスプリミティブがプロトコルスタック内の複数の層の間で使用されていることを意味する。‘S-’というプレフィックスは、サービスプリミティブがWSPなどのセッション層内で使用されていることを示す。以下の解説では、サービスプリミティブは、上位ローカル層または下位ローカル層のいずれかの層からWTPへのリクエストを記述するものである。この結果、トランザクション中ネットワークを介して送信されるヘッダとデータを含む符号化パケットであるPDUが生成される。図1は、データ伝送が行われるクラス3トランザクションの一部を示す図である。このトランザクションは、レスポンダと呼ばれる別の通信エンティティに対して、イニシエータと呼ばれる1つの通信エンティティにより開始される。イニシエータとレスポンダとは2つのチャネルを介して交信を行う。各チャネルはデータフローの方向に従ってセンダとレシーバとを備えている。入力チャネルと出力チャネルとが存在し、入力チャネルはそのデータフローがイニシエータにより確立され、出力チャネルはそのデータフローがレスポンダにより確立される。2つのチャネルが存在するため、イニシエータとレスポンダはデータのセンダ兼レシーバとして各々機能する。チャネルという用語は、メッセージの順序づけられたシーケンスを1方向で伝送するためのストリーム様データ経路を意味する。この用語は物理的エンティティを意味するものではなく、メッセージの順序づけられたシーケンスを1方向で伝送するという上記結果を生む論理的操作を意味するものである。WTPのユーザは、WSPであるか、コネクションを介してWTPと直接通信するアプリケーションかのいずれかであり得る。前者の場合、各トランザクションはセッションの中で達成される。後者の場合、WSPとWSPユーザは単に同じアドレスの四つ組quadrupletに存在するにすぎない。図1は、イニシエータセンダからレスポンダレシーバへ入力チャネルを介して伝送されるメッセージのみを示す。出力チャネルで伝送されるメッセージ、特に、レスポンダによりイニシエータへ伝送されるデータ結果は示されていない。いずれのチャネルにおいても、データの確認応答は該データの反対方向に流れる。図1のトランザクションの詳細な説明を行う前に、簡単な用語でトランザクションの解説を行って、このトランザクションの進み方を例示することにする。ストリーム起動メッセージは入力チャネルで送信される。レスポンダはストリーム結果メッセージを用いて出力チャネルで応答する。次いで、双方のメッセージには追加のストリームデータメッセージが後続してもよい。この追加メッセージは元のメッセージの続きであるとみなされ、追加データを運ぶ。データメッセージが受信されたとき、データメッセージのレシーバがデータメッセージを正確な順番に並べることができるように、この追加データメッセージ内のパケットには連続するPSNが与えられる。トランザクション時のいずれのチャネルもデータ終端メッセージにより終了が可能である。イニシエータとレスポンダの双方がデータ終端メッセージを受信した場合このトランザクションは終了処理が行われる。すべてのメッセージは確認応答を受ける。1つのメッセージは、1つのパケットを含むものであってもよいし、いくつかのパケットに分割されたものであってもよい。クラス3で使用されるPDUは以下のコードを持つ:本発明のPDUの固定ヘッダ構造のフォーマットはWAP規格で使用されるものと同じである。PDUの使用法と動作について以下説明する。トランザクション中、サービスプリミティブは、イニシエータとレスポンダの各々の中のWAPプロトコルスタック内のプロバイダ層とユーザ層との間で起動される。サービスプリミティブにより起動可能な特定のパラメータが以下のパラメータの中から選択される:発アドレス。これは、WTP層へのリクエストを行う装置の一意的アドレスである。このアドレスは、MSISDN番号、IPアドレス、X25アドレスあるいはその他の識別子であってもよい。発ポート番号。これは発アドレスに関連付けられる。着アドレス。これは、WTP層へ発信されるユーザーデータのアドレスである。着アドレスは、MSISDN番号、IPアドレス、X25アドレスあるいはその他の識別子であってもよい。着ポート番号。これは、リクエストされたトランザクションまたは現行トランザクション用着アドレスと関連付けられる。ユーザーデータ。このユーザーデータは、起動されたプリミティブから生成されたメッセージにより運ばれる。WTP層へ発信されたりWTP層から受信されたりするデータ単位SDU。これは、上位層が伝送用としてWTP層へ発信したデータの完全な単位メッセージである。WTP層はデータグラムSDUを伝送し、このデータグラムをそのコンテンツをまったく操作することなくその宛先へ転送する。データ終端。このパラメータは、トランザクションの際にレスポンダへ送信されるユーザーデータの最後の部分が特定のSDUにより担持されていることを示すために使用される。トランザクションハンドル。これは、トランザクションを特定して、受信データをアクティブなトランザクションと関連づけることができるようにするために上位層へ返されるインデックスである。トランザクションハンドルによりトランザクションは一意的に特定される。トランザクションハンドルは、トランザクションの発アドレス、発ポート、着アドレス及び着ポートの別名である。トランザクションハンドルはローカルな重要性しか持たない。エグジット情報。メッセージのシーケンスの送信完了時にメッセージのシーケンスの発信源へ送信される追加ユーザーデータ。このパラメータは、TRストリーム-結果と、TRストリーム-結果-データサービスプリミティブとの中にしか存在しない。図1に戻って、イニシエータとレスポンダのプロトコルスタック内で生じているサービスプリミティブのシーケンス、及び、イニシエータとレスポンダとの間を通るPDUという点からトランザクションについて以下説明する。新しいクラス3トランザクションは、WAEやWSPなどの、WTP層より上位の層WTPユーザイニシエータと呼ばれるによりイニシエータで開始され、WTP層WTPプロバイダイニシエータと呼ばれる内のTRストリーム起動リクエストサービスプリミティブが起動される。新しいトランザクションが起動されると、イニシエータはトランザクション識別子TIDを1だけ増分して、これが新しいトランザクションであることを示す。特定のクラス3トランザクションの範囲内ですべてのPDUを含むすべてのメッセージは同じTIDを持つ。TRストリーム起動リクエストサービスプリミティブを起動することにより、WTPプロバイダイニシエータ内のパラメータが呼び出される。これらのパラメータはトランザクションの設定に必要である。ユーザーデータも含まれる。TRストリーム起動サービスプリミティブの中に含まれるパラメータを以下の表に示す:この表及び下記の諸表の中で、ラベルM、O、Cは以下の意味を持つ:Mはパラメータが必須であり、存在しなければならないことを意味する。Oは、パラメータがオプションであり、省いてもよいことを意味する。Cはパラメータが他のパラメータの値に依存する条件つきであることを意味する。ストリーム起動サービスプリミティブは起動PDUヘッダを受信し、次いで、WTPプロバイダイニシエータは暗黙のパケット番号ゼロを有する起動InvokePDUを送信する。起動PDUは常にトランザクションの第1のメッセージである。起動PDUはTCLパラメータを含む。利用可能なトランザクションクラスは以下に与えられる:この場合、PDUヘッダはトランザクションがクラス3であることを示す。PDUが伝送される初回の場合、ヘッダ内の再送インジケータRIDフィールドはクリアである。クラス3トランザクションであることを示すTCLはクラス0、1、2に対するTCLと同様に2ビットを必要とするにすぎないこと、したがって、WAPと旧版互換性を有することに留意されたい。レスポンダがクラス3トランザクションをサポートしていない場合、トランザクションはレスポンダにより打ち切られる。起動PDUが受信されたとき、WTPプロバイダレスポンダはTIDをチェックし、確認を開始する必要があるかどうかの判定を行う。必要がある場合、WTPプロバイダレスポンダはTID確認処理を開始する。必要がない場合、WTPプロバイダレスポンダはWTPユーザレスポンダへメッセージを転送する。クラス3トランザクションのTID確認処理時に確認応答PDUAckPDUが使用される。図2に示される一例を参照してメッセージの構造について以下説明する。ストリーム起動メッセージのサイズがネットワークのMTUを上回った場合、メッセージは順序づけられた一連のパケットに分割される。本例では、PSN0を持つストリーム起動パケットが存在し、第1の組のパケットは1~16のPSNを持ち、第2の組のパケットは17~33のPSNを持つ。メッセージの伝送開始時に、イニシエータの起動サービスプリミティブ内のデータ終端フラグがクリアされて、さらなるデータパケットが伝送されることを示す。データ終端フラグがクリアされなかった場合、これはさらなるSDUが到来しないことを示すことになる。パケット内でセットされたGTRフラグはグループの終りを示す。パケット内でセットされたTTRフラグはSDUの終りを示す。このTTRフラグによって、2つのSDU間の分割またはメッセージの最後のSDUをマークすることも可能である。DataEndTPIは最後のSDUの最後のパケットに付けられる。起動メッセージから生成される最初のパケットは常に起動PDUヘッダを持ち、図2に示されているような暗黙的にPSN0を持つものとして想定されている。ストリーム起動メッセージが分割される場合、レスポンダは起動PDUをパケット番号ゼロと考え、次の分割された起動PDUを待つ。追加パケットには連続的に増加するPSNを持つ分割されたストリーム起動ヘッダが設けられる。図2では、パケット1~33はこのタイプのPDUを含む。このようなPDUとして以下のようなものがある:これらのパケットはグループで伝送される。グループ伝送については後程さらに詳細に解説する。これらのパケットはグループで確認応答を受ける。クラス3トランザクション時にストリーム起動PDUが分割されているかどうかにかかわりなく、PSNはイニシエータとレスポンダの双方により保持される。これは、センダが次のPSN次のパケットのPSNを認知するようにするためであり、また、レシーバが最後の応答確認済みパケットのPSNを認知し、それによって次の予想されるパケット必ずしも次の受信パケットであるとはかぎらないを認知するようにするためである。ストリーム起動サービスプリミティブの中にデータ終端フラグが設定されている場合、メッセージハンドラはDataEndTPIをPDUのヘッダの固定部に付ける。ストリーム起動メッセージが分割されなかった場合、その起動PDUはDataEndTPIを持つ。ストリーム起動メッセージが分割される場合、最後のメッセージグループの最後の分割パケットはDataEndTPIを持ち、チャネルは閉じられる。PSNはラップアラウンドし、32ビットフィールドを持つ。これは、PSNがラップアラウンドを完了してしまい、PSN番号の再使用が行われるようになる前にデータストリーム内のすべてのパケットが受信されてしまう確率を高くするように、長いデータ伝送時間を可能にするためである。このトランザクションは長い寿命を持つことが可能であるため、PSNまたは時折RIDのみが新しい有効なパケットを古いパケットの複製から区別する。WTPプロバイダイニシエータは起動PDUを送信し、再送タイマを始動させ、再送カウンタをゼロにセットする。さらに、WTPプロバイダイニシエータはPSNをゼロに初期化し、WTPプロバイダレスポンダからの確認応答の待機を開始する。WTPプロバイダレスポンダは、有効なTIDを持つ起動PDUを受信すると、起動メッセージの確認応答を行い、TRストリーム起動指示サービスプリミティブを生成することにより、WTPユーザレスポンダへ上記起動メッセージの転送を行う。再送タイマの期限が切れた再送の時間間隔に達したときに起動PDUまたは他のいずれかのパケットの確認応答がセンダにより受信されなかった場合、再送カウンタが1だけ増分され、グループの最後のパケットが再送され、再送タイマが再開される。すべての再送について、RIDフィールドが設定される。RIDフィールドは変更が行われる唯一のフィールドである。再送回数が最大再送値を上回るまでWTPプロバイダは再送を継続する。再送カウンタが十分に増分され、タイマの期限が切れるまでに確認応答が受信されなかった場合、トランザクションは終了され、ローカルのWTPユーザに通知が行われる。WTPプロバイダレスポンダが起動PDUを受信すると、WTPプロバイダレスポンダにより、最初のパケット起動PDUの確認応答がストリーム確認応答PDUストリームAckPDUを用いて行われる。これはストリームPSNTPIヘッダを有するAckPDUであり、PSNは0である。また、WTPプロバイダレスポンダは、許容されているグループサイズウィンドウをセンダに対して示すためにオプションTPIMaxGroupSizeTPIの形でその最大グループサイズの送信も行う。このグループサイズはセンダにより選択されて、現時点のネットワーク負荷にぴったり合い、かつ、レシーバのウィンドウよりも大きくならないようにすることができる。レシーバによりウィンドウの次の変更が行われるまで最後のウィンドウは有効であり、最後のグループの確認応答にMaxGroupSizeTPIが追加される。レシーバは、ネットワーク用の最適の反応、及び、ネットワークのトラフィック負荷の変化にとって大きすぎないグループサイズを選択することが望ましい。1回のデータグラムで、イニシエータからレスポンダへストリーム起動メッセージ全体の伝送を行うことが可能であり、したがってストリーム起動メッセージ全体の分割と再組立てを行う必要がない場合、ストリーム起動メッセージ全体は起動PDUとして送信される。必要なPDUの数を最小にするために分割が行われない場合であってもこのPDUは再使用される。したがって、パケットがメッセージ内の最後のパケットであることを示すために、TTRフラグはそのヘッダ内で1にセットされる。これらのパケットは送信されグループで確認応答を受ける。分割を行う必要がない場合グループは単一パケットから構成される。パケットグループ内のパケットは単一バッチで送信される。第1のグループはレシーバの状態を確認せずに送信されるので、パケット数は1とすることが望ましい。パッケージ伝送方法を示す2つの代替実施例について以下説明する。伝送方法1伝送方法のこの実施例はstop-and-wait方式ではない。これは、未解決パケットグループが存在する可能性がある、すなわち、前回のグループの確認応答が受信される前に後続グループのパケットの送信が可能であることを意味する。グループの最後のパケットはGTRパケットである。GTRフラグは、そのグループで送信されるすべてのパケットについて確認応答をセンダがリクエストすることを意味する。メッセージ全体の最後のパケットはTTRパケットである。伝送方法1では、GTRフラグが設定されている場合、レシーバは、受信した最後の完全なグループの最後のパケットのPSNを有する確認応答ストリームPSNTPIを持つAckPDUを送信するか、または、確認応答がなされた最後のグループと受信した最後のパケットの間のPSNのリストを有するStreamNackPDUを送信しなければならない。ストリームNackPDUは最も新しいグループからの欠落パケットのPSNを含み、さらに、以前のグループ但し確認応答がなされた最後のグループは含まないからの欠落パケットのPSNを含むものであってもよい。メッセージの最後の各パケットSDUはグループの終りであり、確認応答がなされる必要がある。TTRは確認応答を求める要求でもある。ストリームPSNTPIの中に含まれるPSNは確認応答されるパケットGTRパケットのPSNである。この確認応答は、グループ内のすべてのパケットは着信したが、このグループ以外のすべての他の前回のパケットが受信したことを意味するわけではないという点において、グループ内で累積的である。メッセージは順に送信される。前回のメッセージの伝送が終ってしまうまで新しいメッセージの伝送は開始されない。レシーバは、GTRパケットではないパケットを受信したとき、パケットを格納し、新しいパケットの着信を待つ。レシーバがメッセージのすべてのパケットを受信したすなわち最後のパケットがTTRパケットであるとき、完全なメッセージの再組立てを行うことが可能でなければならない。レシーバは、GTRパケットを受信したとき、そのパケットグループに属するすべてのパケットが受信されたかどうかのチェックを行う。受信されていた場合、レシーバはストリームAckPDUPSNがGTRパケットのPSNに等しくセットされるストリームPSNTPIを担持するをセンダへ送信する。がセットされたGTRを有するパケットが受信されていて、かつグループの1以上のパケットが欠落しているとき、WTPプロバイダは、往復時間の中央値の1/2などのある一定期間待機した後に欠落パケットのリストを有するストリームNackPDUを返送する。グループの状態が時間中変化した場合、すなわち、欠落パケットの中の1つが受信された場合、待ち時間はリセットされる。グループデータの受信の誤りを示すためにストリームNackPDUがクラス3トランザクションのみにおいて使用される。以下にこれを示す:ストリームNackPDUは別のグループに属する他の欠落パケットをリストすることも可能である。こうすれば、現時点のストリームNackPDUが受信され、しかも前回のストリームNackPDUが失われた場合、センダが最後の無応答GTRパケットの再送を行って以前に失われたストリームNackPDUのレシーバによる再送を待機する必要はなくなる。これは以下のように説明することが可能である。第1のグループ内に何らかの欠落パケットが存在し、第2のグループ内に何らかの欠落パケットが存在すると仮定する。レシーバは、第1のグループ用の第1のストリームNAckPDUを送信し、第2のグループ用の第2のストリームNAckPDUを送信する。第1のストリームNAckPDUが失われた場合、センダは第1のグループの状態がどうなっているかわからなくなる。したがって、第1のグループの欠落パケットが第2のストリームNAckPDUの中に含まれていれば、往復の及び関連する再送時間が不要となる。センダは当初のPSNを有するがRIDフラグがセットされた欠落パケットの再送を行う。レシーバは、再送された欠落パケットを含む完全なパケットグループを受信した場合、GTRパケットの確認応答を発信する。第1のグループのサイズはベアラに対応してデフォルトであってもよい。ストリームAckPDUでは、最初のパケットグループの伝送に後続して、レシーバはその現時点のウィンドウパケットスペースを示すためにそのMaxGroupSizeを送信してもよい。ウィンドウパケットスペースとは、任意の時点において未解決であり得るパケットの数であると定義される。このウィンドウパケットスペースはセンダ内及びレシーバ内の双方の中に存在する。この最初の処理後、レシーバはそのウィンドウパケットスペースを用いてデータフローの制御を行うことが可能となる。これを行う1つの方法として単一メッセージの伝送中グループサイズの変更を行う方法がある。利用可能なウィンドウパケットスペースはバイトで表わされる。1グループ内の最大パケット数は最大ベアラパケットサイズにより決定される。1グループ内の伝送可能な最大パケット数は、レシーバで利用可能なデータバッファ数により決定される。ウィンドウパケットスペースは、PSNスペース、すなわち最長未解決パケット最も長い時間確認応答されていないパケットのPSNから始まり、最長未解決パケットのPSNにウィンドウパケットスペース内のパケット数を加算したものに等しいPSNまでのPSNの範囲、に変換される。ある特定グループが確認応答された場合、これがその特定グループに属するすべてのパケットの受信を意味するとしても、必ずしも、その特定グループの前後のいずれかに伝送されたグループのパケットの受信を意味するとはかぎらない。グループの確認応答が着信し、さらに、そのPSN未満のPSNを持つレシーバのPSNスペース内の他のすべてのパケットが受信された場合、PSNスペースの再定義を行うために最長未解決パケットを更新してウィンドウの調整が行われる。このようにして、ウィンドウパケットスペースに対応してとびとびに移動するのではなく、ウィンドウパケットスペースの開始及び終了PSNが1だけ移動することによりPSNスペースは増加的に移動を行うことが可能となる。パケットがセンダにより送信され、レシーバにより受信されたとき、パケット伝送の遅延が未解決パケットへつながる可能性がある。これらの未解決パケットが受信されると最長未解決パケットが受信されるごとに、レシーバは最長未解決パケットを受信した旨の確認応答をセンダへ送信し、そのウィンドウパケットスペースを移動させて次のPSNスペースを占有する。このようにしてPSNスペースは新しい最長未解決パケットから始まることになる。センダは、確認応答を受信すると、そのウィンドウパケットスペースを受信に対応して移動させ、センダとレシーバのウィンドウパケットスペースが対応するようになる。センダは、ウィンドウパケットスペースよりも多い数のパケットを持つグループをつくってはいけない。再送タイマの期限が切れたとき、センダが確認応答を受信していない場合、パケットグループ全体ではなくGTRパケットだけが再送される。ストリームNAckPDU内で、欠落パケットパラメータ数がゼロの値を持つ場合、グループ内のすべてのパケットが再送されなければならない。レシーバは、データ受信用のバッファの空きがない場合に、確認応答と共に0に等しいMaxGroupSizeTPIを送信することによりそのウィンドウを閉じることができる。しかし、レシーバは生じる可能性のある打切りAbortを受信するために1つのパケットバッファを予約しておかなければならない。レシーバを刺激してそのウィンドウに関する情報を与えるために、たとえウィンドウが閉じられていても、センダは1パケットグループGTRパケットを送信する。レシーバは現在の状態を示す確認応答を応答時に送信する。ウィンドウはそのまま閉じていてもよい。ウィンドウが再び開かれると、レシーバは最後のパケットグループの確認応答を繰り返す。この確認応答は、新しい利用可能なウインドウサイズおそらく0以外のを持つMaxGroupSizeTPIを担持する。しかし、センダは開いたウィンドウに関する確認応答を受信しないことも可能である。これは、確認応答が紛失したり、送信されたけれどもまだ受信されていなかったり、あるいは送信さえまだ行われていないという理由などに起因する。センダが確認応答を受信しなかった場合、必要な任意の再送を制御する従来の方法で再送タイマが利用される。いずれの場合にも、レシーバ内のリソース問題に関する情報がセンダに与えられるため、再送タイマは正常の場合よりも大きくなる。伝送方法2伝送方法を示すこの実施例はstop-and-wait方式である。これは未解決パケットグループがあり得ないことを意味する。前回のグループのパケットのすべてについて確認応答が受信されたときにのみ、後続グループ用GTRパケットの送信が行われる。受信された確認応答時のウィンドウパケットスペースに沿うシフト方式の詳細については、上述の方式に対応する。グループの最後のパケットはGTRパケットである。メッセージ全体の最後のパケットグループの最後のパケットはTTRパケットである。伝送方法2では、GTRフラグとTTRフラグとはWAP無線トランザクションプロトコル仕様に記載されているものと同じ意味を持つ。レシーバは、GTRパケットでもTTRパケットでもないパケットを受信すると、パケットを格納し、新しいパケットを待機する。レシーバが完全なパケットグループを受信し、最後のパケットがTTRパケットであるとき、完全なメッセージの再組立てが可能であるべきである。レシーバは、GTRパケットまたはTTRパケットのいずれかを受信し、グループ内のすべてのパケットの受信に成功した場合、ストリームPSNTPIを有するAckPDUをセンダへ送信する。GTRパケットとTTRパケットのいずれかが受信され、グループの1以上のパケットが欠落しているとき、WTPプロバイダは、往復時間の中央値の1/2などのある一定時間待機した後に、欠落パケットの詳細を有するストリームNackPDUを返送する。この時間中グループの状態が変化した場合、すなわち、欠落パケットの中の1つが受信された場合、待ち時間はリセットされる。レシーバは、GTRパケットかTTRパケットのいずれかを受信したとき、そのパケットグループに属するすべてのパケットが受信されたかどうかのチェックを行う。完全なパケットグループが受信された場合、レシーバはGTRパケットまたはTTRパケットのパケットシーケンス番号に等しいPSNを持つストリームPSNTPIヘッダが付されたストリームAckPDUを返送する。ストリームPSNTPIに含まれるPSNは、応答確認済みパケットGTRまたはTTRパケットのPSNである。この確認応答は累積的であり、すべての前回伝送されたパケットが受信された旨の確認応答である。1以上のパケットが欠落している場合、レシーバはストリームNackPDUを用いて応答を行い、欠落パケットはストリームNackPDUの中にリストされる。欠落パケットは当初のPSNを有するがRIDフラグがセットされて再送される。レシーバは、完全なパケットグループを受信すると、再送パケットを含むGTRパケットまたはTTRパケットの確認応答を発信する。再送タイマの期限が切れたとき、センダが確認応答を受信していない場合、パケットグループ全体ではなく、GTRパケットまたはTTRパケットのみが再送される。ストリームNackPDU内で、欠落パケットパラメータ数がゼロの値を持つ場合、グループ内のすべてのパケットが再送される。この伝送方法の情報量の改善を図るために以下の特徴が含まれる。1.グループの伝送中、そのシーケンスの中に何らかのパケットの欠落の存在が特定された場合、レシーバはGTRパケットまたはTTRパケットを待たずにストリームNackPDUの送信を行うことも可能である。したがって、GTRパケットまたはTTRパケットの受信前にある特定パケットに関する第1のストリームNackPDUが送信され、かつ、GTRパケットまたはTTRパケットの受信後にその特定パケットがまだ受信されていない場合、この特定パケットは第2のストリームNackPDUの中に示され、第1、2両方のストリームNackPDUの中で欠落しているパケットとして示されることになる。2.グループサイズはグループウインドウサイズの数値の1/2となるように選択される。グループウインドウサイズが奇数の場合、グループサイズはグループウインドウサイズ-1/2となる。グループサイズの決定は、MaxGroupSizeTPIによってそのウインドウサイズを示すレシーバと、適切なグループサイズを選択するセンダとにより行われる。この伝送システムの動作について以下の例により説明する。ウインドウサイズを11と仮定する。これに応じて、グループサイズは5となる。4つの伝送対象パケットが存在する。第1の送信バーストで、パケット0、1、2、3、4第1のグループのGTRパケット、5、6、7、8が送信される。この第1の送信バーストは第1のグループの全体及び第2のグループの一部である。第2のグループのGTRパケットはこの送信バーストでは送信されない。第2の送信バーストで、送信対象の第1のパケットは第2のグループのGTRパケットであり、第3のグループの一部がそれに続く。第3のグループのGTRパケットはこの送信バーストでは送信されない。後続する送信バーストで、第1のパケットは、先行する送信バーストからの古いグループのGTRパケット、及び、新しいグループのGTRパケットを除く新しいグループのパケットである。各GTRパケットが受信されたとき、そのグループからのパケットのすべてが受信された場合、そのグループの確認応答が送信され、次の送信バーストが発生する。1つだけGTR/TTRパケットが未解決となる可能性がいつでも存在する。この伝送方法の実行時に、レシーバはパケットの不完全なシーケンスの格納並びに後続の送信バーストの格納が可能であり、そのグループの再組立てが可能である必要がある。オーバーラップする伝送部分を含む2つのパケットグループの処理がレシーバにより可能となる必要がある。欠落パケットはストリームNackPDUの中にリストされ、次いで再送される。その間、次のグループのパケットは、すでに伝送されている場合もあれば、レシーバのバッファ内での再組立てを待機している場合もある。伝送方法1と伝送方法2の双方のこのケースでは、TTRにより暗黙のうちにグループの最後にマークがつけられる。DataEndTPIを含むメッセージが確認応答を受けた後は、それ以上多くのデータメッセージをレシーバへ送信することはできない。WTPプロバイダレスポンダの中でメッセージの再組立てが行われる。このメッセージの再組立てが行われと、WTPプロバイダレスポンダは、WTPのユーザレスポンダ内のサービスプリミティブTRStreamInvokeindを起動し、WTPユーザはメッセージを受信し、WTPプロバイダレスポンダ内のサービスプリミティブTRStreamInvokeresを起動する。クラス2のトランザクションでは、単一の起動メッセージは、Ackメッセージの送受信を行うことなく単一の結果メッセージにより確認応答を受けることができる。これは暗黙の確認応答である。クラス3では、同じトランザクションに関する多くのパケット、及び、多くのパケットグループが存在してもよく、このトランザクションは長期間持続することが可能である。したがって、ストリーム結果メッセージの受信は特定の起動メッセージの確認応答を暗黙のうちに行うものではない。その理由はこのストリーム結果メッセージがいくつかの異なる起動メッセージと関連する場合もあるからである。これはストリーム結果メッセージにはPSNや関連する起動メッセージのPSNが含まれないという理由に因るものである。さらにタイミングが重要である。チャネルで送信されるPDUは相手への応答として送信されるわけでは必ずしもない。個々の確認応答GTRパケットについての特定の確認応答及び非GTRパケットについての暗黙の確認応答が個々のパケットについて行われる。ユーザ確認応答機能はクラス3で行われる。WTPユーザによるストリーム起動サービスプリミティブの中に、また、WTPプロバイダによる起動PDUの中にこの機能が設定されている場合、WTPプロバイダの受信によりすべてのメッセージが自動的に確認応答を受けるわけではなく、それらはメッセージに応答するために上位層へ送信される。上位層が応答したとき、WTPプロバイダはメッセージを送信したWTPプロバイダへ確認応答を送信する。上述のように、図1はトランザクション中入力チャネルで伝送されるメッセージを示すだけにすぎない。出力チャネルでも同様のトランザクションが行われる。レスポンダがクラス3ストリーム起動PDUを受信し、このPDUの確認応答を行った後、ストリーム起動PDUはWTPプロバイダレスポンダより上位の1つまたは複数の層に渡されて処理される。結果メッセージが起動メッセージと同じ方法で処理される。データが組み立てられると、WTPユーザレスポンダは、WTPプロバイダレスポンダ内のTR-ストリーム結果リクエストプリミティブを起動することにより結果メッセージの送信を行う。クラス3トランザクション時にストリーム起動メッセージの結果を送信するために、このTR-ストリーム結果プリミティブは使用される。このTR-ストリーム結果プリミティブは以下の表に与えられるパラメータを持つ。結果メッセージは結果PDUを用いてイニシエータへ伝送される。そのサイズに応じて、結果メッセージは分割される場合もあれば、分割されない場合もある。結果PDUが送信された場合、レスポンダは再送タイマを開始し、イニシエータからの確認応答を待機する。イニシエータによる結果PDUの受信後、WTPプロバイダイニシエータはTR結果指示プリミティブを上位のWTPユーザイニシエータへ転送する。DataEndTPIを含むメッセージが確認応答を受けた後トランザクションは終了する。最後のメッセージの最後のグループについてレシーバにより最後の確認応答が送信された後、チャネルに関するセンダとレシーバのそれぞれの管理がクリアされる前にセンダとレシーバの双方は待機を行う必要がある。これは、センダが確認応答を受信しなかった場合センダが最後のグループを再送できるようにするためであり、また、センダがその確認応答を受信したことをレシーバが認知できるようにするためである。図4は、データが拡張された形で伝送されるクラス3トランザクションの一部を示すものである。図1の場合と同じように入力チャネルを介する通信しか示されていない。図4はクラス3トランザクションの開始を示し、このトランザクションではストリーム起動メッセージサイズはネットワーク用MTUを上回るものではなく、分割は行われない。WTPユーザレスポンダによって、WTPプロバイダレスポンダ内のサービスプリミティブTR-Streaminvokereqが起動される。データ終端パラメータがTRストリーム起動リクエストプリミティブの中にセットされていない場合、イニシエータは少なくとももう1つのTR-ストリーム起動データサービスプリミティブを発信する必要がある。これらについて以下検討する。メッセージが追加パケットに分割されないので、WTPプロバイダイニシエータはメッセージ全体を含む起動PDUをWTPプロバイダレスポンダへ送信し、WTPプロバイダレスポンダはWTPユーザレスポンダ内のサービスプリミティブTRStreamInvokeindを起動する。WTPユーザレスポンダは、メッセージを受信すると、WTPプロバイダレスポンダ内のサービスプリミティブTRStreamInvokeresを起動する。WTPプロバイダレスポンダは、PSN0を持つストリームAckをWTPプロバイダイニシエータへ送信する。この送信の結果、WTPプロバイダイニシエータはTRStreamInvokecnfをWTPユーザイニシエータの中で起動する。上記ストリームAckはMaxGroupSizeTPIを担持している。次いで、図3の場合、イニシエータは同じトランザクションの範囲内でさらに多くのデータをレスポンダへ送信する。WTPユーザイニシエータはTRStreamInvokeDatareqサービスプリミティブをWTPプロバイダイニシエータの中で起動して追加データの送信を行う。TR-ストリーム起動データストリーム起動データサービスプリミティブのパラメータを以下に示す。このプリミティブはクラス3トランザクション時にストリーム起動メッセージのデータを継続するために使用される。同様に、ストリーム起動メッセージサイズはネットワーク用MTUを上回るものではなく、従って分割は行なわれない。WTPプロバイダイニシエータは分割された起動PDUをWTPプロバイダレスポンダへ送信する。このPDUは、トランザクションにおいて次のパケットであるためPSN1を持っている。次いでTTRフラグがセットされ、このメッセージ内の最後のパケットであること、及び、確認応答がリクエストされたことが示されることになる。WTPプロバイダイニシエータは分割された起動PDUのヘッダの固定部に付けられたDataEndTPIをWTPプロバイダレスポンダへ送信する。WTPプロバイダレスポンダはWTPユーザレスポンダ内のサービスプリミティブTRStreamInvokeDataindを起動する。WTPユーザレスポンダは、起動メッセージを受信したとき、WTPプロバイダレスポンダ内のサービスプリミティブTRStreamInvokeDataresを起動することにより応答を行う。WTPプロバイダレスポンダは、PSNが1であるストリームPSNTPIが付されたストリームAckPDUをWTPプロバイダイニシエータへ送信する。WTPプロバイダイニシエータはWTPユーザイニシエータ内のサービスプリミティブTRStreamInvokeDatacnfを起動する。イニシエータに送信対象データがそれ以上なくなるとすぐに、データ終端フラグがTR-ストリーム起動データサービスプリミティブにセットされる。イニシエータが、TR-ストリーム起動データサービスプリミティブから開始されたいくつかのさらに多くのデータメッセージを送信する場合、そのメッセージが分割されているか否かにかかわらず、これらのプリミティブが分割されたストリーム起動ヘッダにより与えられる。必要であれば、このメッセージは分割される。ストリーム起動メッセージ後に、クラス3トランザクション追加データがレスポンダへ送信されたとき、分割された起動PDUがあらゆる場合に用いられる。メッセージの分割を行う必要がない場合、このPDUは1パケットメッセージグループの最後のパケットとなる。最後のデータメッセージの場合、DataEndTPIが最後の分割された起動PDUのヘッダの固定部に付けられる。メッセージがメッセージストリームの最後のメッセージである場合、データ終端パラメータはストリーム起動及びストリーム起動データサービスプリミティブの中に含まれる。サービスプリミティブパラメータが設定され、したがって、ローカルなWTPにより、この最後のメッセージの最後のPDUにDataEndが付けられる。レスポンダが起動メッセージに応じてデータを取得すると、WTPユーザレスポンダは、TR-ストリーム結果リクエストサービスプリミティブをWTPプロバイダレスポンダの中で起動することにより結果メッセージの送信を行う。結果メッセージの性質に応じて、結果メッセージを単一メッセージとして送信するか、分割するかのいずれかを行うことが可能である。ストリーム結果メッセージから生成された第1のパケットは結果PDUヘッダを常に担持し、暗黙のパケット番号ゼロを持つものと想定されている。結果メッセージの分割を行う必要がある場合、結果メッセージは追加の分割されたストリーム結果PDUで送信される。WTPユーザレスポンダがデータブロックをさらに送信することが必要な場合、この送信はTR-ストリーム結果データサービスプリミティブを発信することにより達成が可能となる。これらのプリミティブによりいくつかのストリーム結果データメッセージの送信が惹起される。このTR-ストリーム結果データサービスプリミティブを以下の表に示す:たとえメッセージの分割を行う必要がない場合であっても、このサービスプリミティブにより、分割されたストリーム結果PDUが生成される。この場合、このPDUはメッセージの最初のパケット及び最後のパケットとなり、TTRフラグが設定される。ストリーム起動またはストリーム結果メッセージの送信後、PSNカウンタはデータ伝送の終了までクリアされることはない。トランザクション中、イニシエータとレスポンダは、トランザクションが終了するまで、別個のストリーム起動データとストリーム結果データメッセージを必要に応じて用いて各々いくつかのデータブロックを伝送してもよい。レスポンダは、送信対象データがそれ以上なくなるとすぐに、WTPプロバイダレスポンダにおいてWTPユーザレスポンダにより起動され発行されたTR-ストリーム結果の中か、TR-ストリーム結果データサービスプリミティブの中のいずれかに、データ終端パラメータを設定し、データ終端メッセージDataEndTPIヘッダが付されたメッセージを送信することによりそのトランザクションのその側を閉じる。データ終端パラメータがTR-ストリーム結果リクエストプリミティブの中にセットされない場合、レスポンダは少なくとももう1つのTR-ストリーム結果データサービスプリミティブを発行しなければならない。しかし、レスポンダによるチャネルの終了処理は必ずしもトランザクションの終了であるとはかぎらない。なぜなら、レスポンダは、イニシエータのデータ終端メッセージを受信するまでにイニシエータから追加データを受信する場合もあり得る。イニシエータとレスポンダの双方がそのデータ終端メッセージを送信した場合、トランザクションは終了となる。いずれの場合にも、当事者のいずれか一方がトランザクション打切りサービスプリミティブを起動することにより、トランザクションをいつでも打ち切ることができる。このサービスプリミティブは無線トランザクションプロトコル仕様の中に定義されている。チャネルの最後のメッセージが受信されたとき最後のAckPDUが送信される。確認応答の送り手は、例えば確認応答が紛失した場合などに前回のグループの再送処理を可能にするための状態情報を保持する必要がある。待機タイマを利用することによりこの状態情報の保持が可能である。受信され、次いで再組立てが行われたメッセージは、送信メッセージに等しいサイズを有する、WTPプロバイダの上位レベルWTPユーザあるいはどこかへ転送される。WAP規格により定義されるトランザクションクラス1及び2とは異なり、クラス3トランザクションでは、すべてのメッセージが明示的ストリームAckPDUにより確認応答を受け、特定のメッセージを受信した旨が示される。拡大データの転送はオーバーラップする可能性があるDataEndTPIが受信されるまで2つのチャネルが同時に機能している場合がある。言い替えれば、これはストリーム起動データPDUが1つの方向に進み、同時に、ストリーム結果データPDUが反対方向に進む可能性があることを意味するものである。WTPプロバイダイニシエータは、以前のトランザクションの結果が受信されるまで複数のトランザクションを開始することができる。これらのトランザクションは、以後のトランザクションへの応答の方が以前のトランザクションへの応答よりも前に受信されるといった非同期処理が可能である。PDUの固定ヘッダの可変部は1乃至いくつかのTPIから構成されるものであってもよい。TPIの長さは2乃至8ビットとすることができる。注1メッセージの分割と再組立てを行うために分割と再組立てが利用される場合にのみこのTPIは適用可能である。注2このTPIはクラス3トランザクションの中でのみ使用される。エラーTPIはエラーTPIまたはサポートされていないTPIの送り手へ返送される。PDUヘッダの可変部に少量のデータ例えばパフォーマンス測定や統計データなどをピギーバックするためにINFOTPIが使用される。2つのWTPエンティティ間でパラメータの転送を行うためにオプションTPIが使用される。無線トランスポートプロトコル仕様とは異なり、トランザクション時のいずれかの通信相手が任意の時点に任意のAckPDUで最大グループオプションTPIを送信することができることに留意されたい。また、この最大グループオプションTPIをTPIの次の同じタイプまたはトランザクションの終了まで有効なものとすることが望ましい。DataEndTPIを以下のPDUに付けてもよい:起動PDU結果PDU分割された起動PDU分割されたストリーム結果PDUDataEndTPIの意味することはこの方向からトランザクションの通信相手へのデータ伝送がそれ以上存在しないということである。したがって、このDataEndTPIはこの方向からの最後の番号付きパケットである。TRストリーム起動、TR-ストリーム結果、TR-ストリーム起動データあるいはTR-ストリーム結果データサービスプリミティブのいずれかのデータ終端フラグパラメータの設定が行われる場合、最後のメッセージグループの最後のパケットはこのDataEndTPIを担持する。その構造は以下の通りである:クラス3トランザクションでは、AckPDUはパケットシーケンス番号フィールドを持たず、ストリームパケットシーケンス番号TPIがAckPDUヘッダの可変部への付属部として利用される。TPIは上述の2つの伝送方法の場合異なるものとなる。伝送方法1では、AckPDUの中に含まれるPSNは応答確認済みパケットGTRパケットのPSNである。この確認応答はグループ内で累積され、グループ内のすべてのパケットが着信したが、このグループ以外の前回のパケットがすべて受信されわけではない旨の確認応答が行われる。伝送方法2では、AckPDUの中に含まれるPSNは応答確認済みパケットGTRまたはTTRパケットのPSNである。図5は有効なプリミティブシーケンスの表を示す。各行の先頭にあるサービスプリミティブには、Xでマークされる列の中の対応するサービスプリミティブだけが後続することができる。データ終端EndOfDataはサービスプリミティブ内にセットされたフラグを示す。この表は許されるシーケンスを全体的に示すものである。WSP層のレベルでのクラス3トランザクションの利用に関わるステップについて以下説明する。図4は、セッション層の関与を示すために、センダとレシーバ内のより上位の層のレベルでの図3のストリーム起動トランザクションを示す。図4は、センダとレシーバの各々WSPプロバイダ内のWSPユーザにより起動されるセッション層サービスプリミティブを示す。サーバにより実行される動作をリクエストするためにS-ストリームメソッド起動プリミティブが用いられる。S-ストリームメソッド起動プリミティブはSメソッド結果サービスプリミティブと共にしか用いることができない。データ終端フラグはさらに多くのデータリクエストボディの続きが存在するかどうかを示す。データ終端フラグが設定された場合、これはストリーム起動メッセージにより送信されたデータのすべてである。開始された動作リクエストのリクエストボディの続きをサーバへ送信するために、S-ストリーム起動データサービスプリミティブが使用される。先行するS-ストリームメソッド起動プリミティブのデータ終端フラグが0になった後にしか、S-ストリーム起動データサービスプリミティブは起動することはできない。データ終端フラグはさらに多くのデータリクエストボディの続きが存在するかどうかを示す。データ終端フラグが設定され場合、これは最後の送信データである。S-ストリーム結果サービスプリミティブは動作リクエストに対する応答を返送するために用いられる。S-ストリーム結果サービスプリミティブは先行するS-ストリームメソッド起動プリミティブが生じた後にしか起動することはできない。データ終端フラグはさらに多くのデータレスポンスボディの続きが存在するかどうかを示す。データ終端フラグが設定された場合、これはこのストリーム結果メッセージで送信されたデータのすべてである。S-ストリーム結果データプリミティブは、追加の応答データを動作リクエストへ返送するために使用される。S-ストリーム結果データプリミティブは、先行するS-ストリーム起動プリミティブが生じた後にしか、起動することができない。データ終端フラグはさらに多くのデータレスポンスボディの続きが存在するかどうかを示す。データ終端フラグが設定された場合、これは送信されたデータのすべてである。S-ストリームメソッド起動ファシリティでは、以下のPDUすなわちGet、Post、Replyが使用される。これらのPDUはWAP規格の中に定義されている。別のトランザクションの一例としてストリームプッシュトランザクションがある。このストリームプッシュトランザクションもクラス3WTPトランザクションを利用するものであるが、イニシエータの役割を行う。ストリーム起動トランザクションとは対照的にストリームプッシュトランザクションは1方向のみのトランザクションである。サーバがトランザクションを開始し、クライアントはレスポンダである。上述のデータストリームの任意の形で多量のデータをプッシュすることができる。サーバのみがクライアントへデータを送信するので、レスポンダ用チャネルは自動的に閉じられる。ストリームプッシュトランザクションで使用されるサービスプリミティブは以下に定義される:SストリームプッシュSストリームプッシュデータS-ストリームプッシュファシリティでは、WAP規格で定義されたようなPDU確認プッシュPDUが利用される。これらのオプションのファシリティ、プッシュ、確認プッシュ、一時停止、及び、再開および確認応答ヘッダを提供するために、WSPに対する変更を行う必要がある。特に、2つのプロトコルオプションフラグを追加しなければならない。さらに、2つのさらなる能力最大未解決ストリームメソッドリクエスト並びに最大未解決ストリームプッシュリクエストが導入される。第1の起動メッセージがレスポンダにより受信される前に、イニシエータによる第1の起動メッセージ送信、次いで、第2の起動メッセージの送信ストリーム起動メッセージが可能である。レスポンダは、第1に受信する起動メッセージが新しいTIDを持つが、トランザクションが正しく開始されない場合もあるということに気づくことになる。その場合、レスポンダは第2の起動メッセージを棄却する代わりにそれを格納し、起動メッセージを待機する。クラス3トランザクションのいくつかのPDUの連鎖が提供される場合もある。この連鎖は、WAP規格により定義されるようなその他のクラスに対する連鎖と同じルールを利用するものである。本発明は移動端末装置、WAPプロトコルスタック、WAPサーバあるいはWAPゲートウェイの中に一体化して組み込むことが可能である。図6は、インターネット4へのアクセスを行う複数の移動端末装置2を有する通信システムを示す。移動端末装置は、無線ネットワーク8により、及び、無線ネットワーク8を介して受信される信号6を伝送する。これらの信号には、WAPに準拠する無線マークアップ言語WMLとWAPコマンドとが含まれる。WMLは、ナビゲーションサポート、データ入力、ハイパーリンク、テキスト及び画像プレゼンテーション及びフォームを出力するタグベースの表示言語である。WMLはHMTLと類似する閲覧用言語である。ネットワーク8により受信された信号10はプロキシサーバまたはゲートウェイサーバ12への経路選定を行う。サーバ12によってWAPリクエストはHTTPリクエストに変換され、それによって移動端末装置2はウェブサーバ14から情報をリクエストし、したがってインターネット4の閲覧が可能となる。ウェブサーバ14から得られた情報はゲートウェイにより符号化され、好適なフォーマットに変えられ、次いで、この情報をリクエストした移動端末装置2へ無線ネットワークにより伝送される。移動端末装置2はこの情報を処理し、利用する。ウェブサーバ14がWAPWMLフォーマットでコンテンツを出力した場合、サーバ12はウェブサーバ14から直接このようなコンテンツの検索を行うことが可能となる。しかし、ウェブサーバがHTMLなどのWWWフォーマットでコンテンツを出力した場合、フィルタを用いてWWWフォーマットからWAP/WMLフォーマットへそのコンテンツを変換することも可能である。図6はインターネットから得られる情報を示すものではあるが、ゲートウェイ自体が所望の情報を含むものであってもよい。例えば、クライアントはゲートウェイのファイルシステムから情報の検索を行うことも可能である。図7は、コンピュータ20のようなハードウェアの中に具現化されたゲートウェイサーバを示す。コンピュータ20は、ダイナミックメモリ、処理パワー、及び、アプリケーションプログラム、プロトコルスタック及びオペレーティングシステムのような、ゲートウェイサーバの実行に必要なプログラムのすべてを格納するためのメモリを有する。コンピュータ20は、キーボード22とディスプレイ図示せず及びサービスプログラム24などのようなユーザーインターフェースを具備する。サービスプログラム24は、サーバからのWML検索リクエストの処理などの基底にあるプロトコルのイベント用アプリケーションプログラム26と、WAPプロトコルスタック28及びHTTPプロトコルスタック30などのようなプロトコルスタックとを有する。アプリケーションプログラム26は、電話網32、インターネット34及びデータネットワークと回線交換データネットワーク35を含む様々なネットワーク間のコマンド、リクエスト、及び、情報を含むデータフローの制御を行う。コンピュータ20はHTTPプロトコルスタック30とインターフェース36を介してインターネット34と交信を行う。コンピュータ20はインターフェース38と40とを介して電話網34とデータネットワーク35との交信を行う。サービスプログラム24にはHTTPとWAPとの間の変換を行うアプリケーション42も含まれる。通信事業者のネットワークとの適切なハードウェアを通じるデータコネクションを介してSMSメッセージ通信を行うことも可能である。アプリケーションプログラム26とWAPプロトコルスタック28の中に存在する個々のスレッド44は、コンピュータ20内のプロセッサ46を利用して必要な処理タスクを実行する。コンピュータ20のオペレーティングシステム50の範囲内に存在するスレッドサービス48により、プロセッサへのスレッドの割当てが行われる。WAPスタックはデータグラムサービスを提供するいわゆるベアラの上位に組み立てられる。これらのベアラは、例えば、SMSやCSDであってもよい。これらのベアラはそれ自身のプロトコルを持ち、プロトコルスタックの実現を通じて実現される。図8は移動端末装置60の実施態様を示す。移動端末装置60は、中央演算処理装置CPU62、送受信装置64、コンテンツの格納用メモリ66、WAPマイクロブラウザ及び送受信装置64、ディスプレイ70、移動端末装置の電話関連機能用メモリ72を介してデータ転送の制御を行うための関連するプロトコル68を具備する。電話コールを行う際の送受信装置64の動作については説明しない。というのはこれは移動端末装置60の従来方式の電話活動に関する事柄であるからである。CPU62はその他の要素の動作の制御を行う。図9は図6の通信システムを示す。図9は、クライアント例えば移動端末装置、ゲートウェイ、サーバこの場合ウェブサーバなどの細部を示す別の図を示す。以下に、双方向のメッセージストリーミングを用いてWAPを利用する1つの実施例で利用可能な本発明のアプリケーションの若干を提案する。言うまでもなく、アプリケーションレベルでクラス3の機能が実現されているものであれば、これらのアプリケーションのほとんどは既存のWAPスタックを用いて実行可能である。データ転送に関わるトランザクション実行時に、多量データの伝送及びトランザクションの順序という2つの主要考慮事項が存在する。一続きのメッセージの伝送により多量のデータの連続転送が可能になり、さらに、順序づけられたイベントの伝送が可能になる。いくつかのトランザクションを利用する場合、メッセージの送受信の順序は保証されない。したがって、アプリケーションレベルでこの順序の制御を行う必要がある。多くのアプリケーションは、最初の着信が最初に送信されるイベントを伴う少量データの転送を必要とするので順序づけられたイベントの伝送が重要である。本発明はテレビ会議への適用が可能である。配信センターとして機能するWAP利用可能サーバと接続された多数のクライアントを持つようなテレビ会議システムが提供される。各クライアントは、個々の画像またはフレームのストリームの送受信用サーバと2方向ストリームにより接続される。ストリーミングが役に立つためフレームの順序が重要となり、ストリーミングがない場合には、アプリケーション自身がフレームの順序を再構成する必要がある。テレビ会議をWAPと組み合わせると好適である。情報の選択、情報の伝送及び会議のリンクを行うためにWMLデッキとして高度のユーザーインターフェースを設けることが可能である。このサービス全体に単一のWAPサーバを設けることが可能である。WAPベースのビデオサービス用の別の重要な応用領域として、ブルートゥースサービスがある。この場合トランスポートプロトコルとして、ビデオ情報のブラウズ/アクセスを行うためのWAPの利用が可能である。別の実施態様では、家庭用装置または別の装置にミニWAPサーバが設けられ、WAP利用可能クライアントからのアクセスが可能になる。一例として、WAP利用可能のボイスメールサービスがある。このボイスメールサービスにより、メッセージの状態を閲覧するためのWAPブラウザからの接続が可能になり、さらに、メッセージの聴取が可能になる。クライアントからサーバへのチャネルがコマンド送信制御チャネルとして利用され、サーバからクライアントへチャネルを介して音声のストリーミングが行われる。装置へ送信されるコマンドは、スキップメッセージ、削除メッセージ等々を含むものであってもよい。さらに別の実施態様では、遠隔制御システムや遠隔測定システムが提供され、その場合、クライアントは、ストリームの形で着信するリアルタイム圧力データなどの測定データを出力する中央処理サーバと接続し、この制御用サーバはストリームの形で制御情報や要約情報を返送する。ストリームがサポートされたWAPの利用が可能なシステムであれば、WAPが利用可能なクライアントを持つWAPサーバの形でのシステムの実現も可能である。さらに別の実施態様では、サーバーベースのゲーム用システムが提供される。このようなマルチプレイヤーゲームシステムでは、クライアントが接続した集中型ゲームサーバーが提供される。リアルタイムのアクションゲームの場合には、ストリーム様フォーマットで情報が送受信され、その場合イベントの順序が重要となる。例えば、プレイヤーは、殺された後リアルタイムでの通信が許されなくなる場合がある。ゲームサーバーとクライアントとは、イベントが順に着信することを保証する双方向ストリームプロトコルを用いて接続されていてもよい。さらなる実施態様では、WAPベースのインテリジェントマップ/所在位置測定サービスを有するシステムが提供される場合もある。このシステムでは、所在位置情報ストリームがサーバへ送信され、このサーバが今度は地図及び地図座標データを返送する。都市における車の追尾、あるいは、歩行者が特定のショップを見つけることができるようするための歩行者の追尾の場合ように追尾が非常にきめ細くなることに起因して、所在位置の更新が頻繁な場合、双方向のストリームを利用してトランザクションの順序の保存が行われる。さらに別の実施態様では、本発明を利用してインターネットベースのマルチメディアアプリケーションへのアクセスを行うことも可能である。このようなアプリケーションでは、クライアントとの接続用としてTCPストリームが利用される。このようなアプリケーションRealAudioサービスなどがWAP利用可能クライアントと接続された場合、ストリーム様TCPのトランザクション型WTPへの変換を試みる代わりに、WAP内のストリーム様メッセージシーケンスサポートの利用が可能となる。さらに別の実施態様では、音声コマンドの受信及び/又は音声メッセージのユーザへの送信を行う音声制御WAPサービスの提供も可能である。サービス特定コマンドセットの音声認識は、処理パワーと重量という点から軽量の端末装置用として提供するには困難な場合もある。本発明を利用することにより、出力チャネルでの音声データをWAPサーバへ送信することが可能となり、優れた認識/言語選択の達成が可能となる。同様に、戻りチャネルを利用して応答として音/声データを伝えることが可能となる。本発明は、単一のトランザクションの範囲内で任意の長さのメッセージシーケンスの出力に利用可能な新しいトランザクションクラスを提供するものである。本発明は、新しいトランザクションクラス3の新しい特徴に加えて、WAP規格のすべての特徴が保持されているので、WAP規格との互換性を有する。クラス3トランザクションの特定及び処理は別個に行うことも可能である。エラー、バージョン及びTIDの処理方法はWAP規格の場合と同じである。クラス3トランザクションでは、メッセージの処理手順は現行の分割及び再組立て処理を利用する。したがって、個々のSAR処理を定義する必要はない。しかし、本発明では2つの方法で現行の分割及び再組立てが利用されることに留意されたい。本発明では、メッセージがパケットに分割されるクラス2の方法と類似した方法で分割及び再組立てが利用される。さらに本発明では、分割及び再組立てが特定のメッセージに適用されるか否かに関係なく、メッセージのストリームを送信するために分割及び再組立ても利用される。いずれの場合にもPSNが常時使用される。これは唯一のパケットしか存在しない場合、分割及び再組立てが適用されないクラス2のトランザクションとは対照的である。WAPに関して本発明を説明してきたが、通信プロトコルに基づく他のいずれのトランザクションに対しても本発明の適用が可能である。例えば、本発明はIPネットワークでの閲覧に対して適用が可能である。本発明は特に無線ネットワークに適しているが、有線ネットワークにも適用可能である。本発明の特定の実現及び実施態様について解説した。本発明が如上の実施態様の細部に限定されるものではなく、本発明の特徴から逸脱することなく同等の手段を用いて別の実施態様での実現が可能であることは当業者には明らかである。本発明の範囲は添付の特許請求項のみによって限定されるものである。