JP2003515280A

JP2003515280A - データ伝送

Info

Publication number: JP2003515280A
Application number: JP2001538354A
Authority: JP
Inventors: ゲレンダイ，マグドルナ; トツ，ミハーリュ; パッレル，ガーボル
Original assignee: Nokia Oyj
Current assignee: Nokia Oyj
Priority date: 1999-11-17
Filing date: 2000-11-07
Publication date: 2003-04-22
Also published as: AU1399101A; JP5038515B2; US7542472B1; WO2001037507A2; CN1451217A; JP2011205639A; WO2001037507A3; EP1232615A2; CN100370791C; EP1764966A1; FI19992470A

Abstract

(57)【要約】本発明は、移動端末装置とゲートウェイ間のリンクを介するデータ伝送に関わるトランザクションの実行方法に関する。上記データは、各メッセージが少なくとも１つのデータパケットを有する複数のデータメッセージの形をしている。メッセージの数は予め決められていない。上記方法は信頼性のあるコネクションを提供するために移動端末装置がデータパケットを受信した旨の確認応答を発信し、ゲートウェイが各データメッセージ内の最後のデータパケットをレシーバに通知し、センダが最後のデータメッセージを上記レシーバに通知するステップを有する。本発明は、無線トランザクションプロトコルに準拠して実行されるトランザクションに特に適用可能である。

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-Str
eam Invoke Data.reqサービスプリミティブをＷＴＰプロバイダ（イニシエータ
）の中で起動して追加データの送信を行う。ＴＲ−ストリーム起動データ（スト
リーム起動データ）サービスプリミティブのパラメータを以下に示す。このプリ
ミティブはクラス３トランザクション時にストリーム起動メッセージのデータを
継続するために使用される。

【表８】

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

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

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

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

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

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

【表９】

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

【表１０】

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

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

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

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

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

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

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

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

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

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

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

【表１２】

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

【表１３】

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

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

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

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

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

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

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

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

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

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

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

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

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

【表１８】Ｓストリームプッシュデータ

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

【図面の簡単な説明】

【図１】分割を利用するトランザクションを示す。

【図２】メッセージの構造を示す。

【図３】分割を利用しないトランザクションを示す。

【図４】図３のトランザクションの別図を示す。

【図５】有効なサービスプリミティブシーケンスの表を示す。

【図６】通信システムを示す。

【図７】ゲートウェイを示す。

【図８】移動端末装置を示す。

【図９】異なる形で図６に準拠するシステムを示す。

【手続補正書】特許協力条約第３４条補正の翻訳文提出書

【提出日】平成１４年１月７日（２００２．１．７）

【手続補正１】

【補正対象書類名】明細書

【補正対象項目名】特許請求の範囲

【補正方法】変更

【補正の内容】

【特許請求の範囲】

【手続補正２】

【補正対象書類名】明細書

【補正対象項目名】０００７

【補正方法】変更

【補正の内容】

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

【手続補正３】

【補正対象書類名】明細書

【補正対象項目名】００１８

【補正方法】変更

【補正の内容】

【００１８】本発明の第１の態様によれば、請求項１に従うトランザクションの実行方法が
提供される。

【手続補正４】

【補正対象書類名】明細書

【補正対象項目名】００３０

【補正方法】変更

【補正の内容】

【００３０】本発明の第２の態様によれば、請求項３１に従ってデータ伝送を行うための移
動端末装置が提供される。

【手続補正５】

【補正対象書類名】明細書

【補正対象項目名】００３１

【補正方法】変更

【補正の内容】

【００３１】本発明の第３の態様によれば、請求項３２に従ってデータ伝送を行うゲートウ
ェイが提供される。

【手続補正６】

【補正対象書類名】明細書

【補正対象項目名】００３２

【補正方法】変更

【補正の内容】

【００３２】本発明の第４の態様によれば、請求項３３に従うデータ伝送システムが提供さ
れる。

【手続補正７】

【補正対象書類名】明細書

【補正対象項目名】００３３

【補正方法】変更

【補正の内容】

【００３３】本発明の第５の態様によれば、請求項３４に従うデータ伝送システムが提供さ
れる。

【手続補正８】

【補正対象書類名】明細書

【補正対象項目名】００３４

【補正方法】変更

【補正の内容】

【００３４】本発明の第６の態様によれば、請求項３５に従うコンピュータ・プログラム製
品が提供される。

───────────────────────────────────────────────────── フロントページの続き (81)指定国ＥＰ(ＡＴ，ＢＥ，ＣＨ，ＣＹ，ＤＥ，ＤＫ，ＥＳ，ＦＩ，ＦＲ，ＧＢ，ＧＲ，ＩＥ，ＩＴ，ＬＵ，ＭＣ，ＮＬ，ＰＴ，ＳＥ，ＴＲ)，ＯＡ(ＢＦ，ＢＪ，ＣＦ，ＣＧ，ＣＩ，ＣＭ，ＧＡ，ＧＮ，ＧＷ，ＭＬ，ＭＲ，ＮＥ，ＳＮ，ＴＤ，ＴＧ)，ＡＰ(ＧＨ，ＧＭ，ＫＥ，ＬＳ，ＭＷ，ＭＺ，ＳＤ，ＳＬ，ＳＺ，ＴＺ，ＵＧ，ＺＷ)，ＥＡ(ＡＭ，ＡＺ，ＢＹ，ＫＧ，ＫＺ，ＭＤ，ＲＵ，ＴＪ，ＴＭ)，ＡＥ，ＡＧ，ＡＬ，ＡＭ，ＡＴ，ＡＵ，ＡＺ，ＢＡ，ＢＢ，ＢＧ，ＢＲ，ＢＹ，ＢＺ，ＣＡ，ＣＨ，ＣＮ，ＣＲ，ＣＵ，ＣＺ，ＤＥ，ＤＫ，ＤＭ，ＤＺ，ＥＥ，ＥＳ，ＦＩ，ＧＢ，ＧＤ，ＧＥ，ＧＨ，ＧＭ，ＨＲ，ＨＵ，ＩＤ，ＩＬ，ＩＮ，ＩＳ，ＪＰ，ＫＥ，ＫＧ，ＫＰ，ＫＲ，ＫＺ，ＬＣ，ＬＫ，ＬＲ，ＬＳ，ＬＴ，ＬＵ，ＬＶ，ＭＡ，ＭＤ，ＭＧ，ＭＫ，ＭＮ，ＭＷ，ＭＸ，ＭＺ，ＮＯ，ＮＺ，ＰＬ，ＰＴ，ＲＯ，ＲＵ，ＳＤ，ＳＥ，ＳＧ，ＳＩ，ＳＫ，ＳＬ，ＴＪ，ＴＭ，ＴＲ，ＴＴ，ＴＺ，ＵＡ，ＵＧ，ＵＳ，ＵＺ，ＶＮ，ＹＵ，ＺＡ，ＺＷＦターム(参考） 5K030 HA08 HD03 JA05 JL01 LA02 LB11 LE14 5K034 AA05 DD01 EE03 EE11 FF02 FF11 HH01 HH02 HH07 HH08 HH11 HH12 LL01 MM25 MM26 MM39 NN16 NN26 5K067 AA11 BB04 CC08 CC14 DD24 DD51 EE02 EE10

Claims

【特許請求の範囲】

【請求項１】センダとレシーバ間のリンクを介するトランザクションを実
行し、複数のデータメッセージの形のデータ伝送を行う方法であって、各メッセ
ージが少なくとも１つのデータパケットを含む方法であって、レシーバが信頼性のあるコネクションを提供するためにデータパケットを受信
した旨の確認応答を発信するステップと、センダが各データメッセージにおいてレシーバに最後のデータパケットである
ことを通知するステップと、センダが最後のデータメッセージであることをレシーバに通知するステップと
、を有することを特徴とする方法。
【請求項２】データが所定長ではないことを特徴とする請求項１に記載の
方法。
【請求項３】メッセージの任意の長さのストリーム様シーケンスの伝送が
トランザクションの内部に存在することを特徴とする請求項２に記載の方法。
【請求項４】データの転送中パケットシーケンス番号によってデータパケ
ットに連続的に番号づけが行われることを特徴とする請求項１〜３のいずれか１
項に記載の方法。
【請求項５】パケットシーケンス番号がラップアラウンドすることを特徴
とする請求項５に記載の方法。
【請求項６】データの分割と再組立てとが行われることを特徴とする請求
項１〜５のいずれか１項に記載の方法。
【請求項７】センダとレシーバの間の通信がトランザクションの範囲内で
双方向であることを特徴とする請求項１〜６のいずれか１項に記載の方法。
【請求項８】２つのチャネルであって、一方のチャネルはイニシエータか
らレスポンダへデータを伝送するようにし、他方のチャネルは反対方向にデータ
を伝送するように成す２つのチャネルが設けられることを特徴とする請求項７に
記載の方法。
【請求項９】データの最後のメッセージの送信によりチャネルうちの少な
くとも一方が閉じられることを特徴とする請求項８に記載の方法。
【請求項１０】双方のチャネルの終了処理が行われた場合、トランザクシ
ョンの終了処理が行われることを特徴とする請求項８または９に記載の方法。
【請求項１１】パケットがパケットのグループで送信されることを特徴と
する請求項１〜１０のいずれか１項に記載の方法。
【請求項１２】レシーバがグループからすべてのパケットを受信したとき
、グループ全体の確認応答を発信することを特徴とする請求項１１に記載の方法
。
【請求項１３】レシーバは、グループの残りのパケットが受信されたこと
を確認したとき、グループの最後のパケットの確認応答を発信することを特徴と
する請求項１２に記載の方法。
【請求項１４】前回のグループの確認応答が受信される前に、後続グルー
プのパケットを送信することも可能である点において未解決パケットグループが
存在し得ることを特徴とする請求項１１乃至１３のいずれか１項に記載の方法。
【請求項１５】未解決パケットグループが存在できないことを特徴とする
請求項１１乃至１３のいずれか１項に記載の方法。
【請求項１６】パケットグループの終りを示すパケットの受信前に、欠落
パケットを通知する第１のメッセージが送信されることを特徴とする請求項１５
に記載の方法。
【請求項１７】パケットグループの終りを示すパケットが受信され、欠落
パケットがまだ受信されていない場合、欠落パケットを通知する第２のメッセー
ジが送信されることを特徴とする請求項１６に記載の方法。
【請求項１８】グループのパケットが送信バーストで送信され、特定グル
ープの完了を通知するパケットが特定グループのいくつかのパケットを含む送信
バーストの中に含まれないことを特徴とする請求項１５乃至１７のいずれか１項
に記載の方法。
【請求項１９】特定グループの完了を通知するパケットが後続グループで
送信されることを特徴とする請求項１８に記載の方法。
【請求項２０】前回のグループのパケットのすべてについて確認応答が受
信された場合にのみ、特定グループの完了を通知するパケットが送信されること
を特徴とする請求項１８または１９に記載の方法。
【請求項２１】１つの信頼性の高い起動メッセージと１つの信頼性の高い
結果メッセージとを有する新しいトランザクションクラスであり、起動と結果メ
ッセージとが信頼性の高いデータメッセージにより条件つきで拡張されることを
特徴とする請求項１〜２０のいずれか１項に記載の方法。
【請求項２２】トランザクションが、起動メッセージによりいったん開始
された場合、ストリームデータメッセージにより継続されることを特徴とする請
求項１〜２１のいずれか１項に記載の方法。
【請求項２３】センダがデータの上記終了を示すＴＰＩを送信したとき１
つのチャネルを介するデータ伝送の終了処理が行われ、該データ伝送がレシーバ
により受信されることを特徴とする請求項１〜２２のいずれか１項に記載の方法
。
【請求項２４】任意の１時点に未解決の２つ以上のトランザクションが存
在することを特徴とする請求項１〜２３のいずれか１項に記載の方法。
【請求項２５】単一セッションの中に存在するいくつかの非同期トランザ
クションが存在することを特徴とする請求項１〜２４のいずれか１項に記載の方
法。
【請求項２６】リンクが無線リンクであることを特徴とする請求項１〜２
５のいずれか１項に記載の方法。
【請求項２７】無線トランザクションプロトコル規格に準拠して行われる
ことを特徴とする請求項１〜２６のいずれか１項に記載の方法。
【請求項２８】各メッセージが少なくとも１つのデータパケットを含む複
数のデータメッセージの形のデータ伝送を行うための移動端末装置であって、メ
モリ内に含まれるアプリケーション、及び、プロトコルスタックを具備し、アプ
リケーションとプロトコルスタックとは、センダとレシーバの間で無線リンクを
介してトランザクションを実行し、センダはメッセージをレシーバへ順に送信し
、レシーバは信頼性のあるコネクションを提供するためにパケットを受信した旨
の確認応答を発信し、センダは各データメッセージにおいて最後のデータパケッ
トであることをレシーバに通知し、センダは最後のデータメッセージであること
をレシーバに通知することを特徴とする移動端末装置。
【請求項２９】各メッセージが少なくとも１つのデータパケットを含む複
数のデータメッセージの形のデータ伝送を行うためのゲートウェイであって、メ
モリ内に含まれるアプリケーション、及び、プロトコルスタックを具備し、アプ
リケーションとプロトコルスタックはセンダとレシーバの間で無線リンクを介し
てトランザクションを実行し、センダはメッセージをレシーバへ順に送信し、レ
シーバは信頼性のあるコネクションを提供するためにパケットを受信した旨の確
認応答を発信し、センダは各データメッセージにおいて最後のデータパケットで
あることをレシーバに通知し、センダは最後のデータメッセージであることをレ
シーバに通知することを特徴とするゲートウェイ。
【請求項３０】複数のデータメッセージの形のデータ受信を行うための複
数の移動端末装置を有するデータ伝送システムであって、各移動端末装置はメモ
リ内に含まれるアプリケーション、及び、プロトコルスタックを具備し、アプリ
ケーションとプロトコルスタックとは、ゲートウェイとの無線リンクを介してト
ランザクションを実行し、ゲートウェイは移動端末装置へメッセージを順に送信
し、移動端末装置はパケットを受信した旨の確認応答を発信して信頼性のあるコ
ネクションを提供し、ゲートウェイは各データメッセージにおいて最後のデータ
パケットであることを移動端末装置に通知し、ゲートウェイは最後のデータメッ
セージであることを移動端末装置に通知することを特徴とするデータ伝送システ
ム。
【請求項３１】複数のデータメッセージの形のデータ伝送を行うための複
数の移動端末装置を有するデータ伝送システムであって、各移動端末装置はメモ
リ内に含まれるアプリケーション、及び、プロトコルスタックを具備し、アプリ
ケーションとプロトコルスタックとは、ゲートウェイとの無線リンクを介してト
ランザクションを実行し、移動端末装置はゲートウェイへメッセージを順に送信
し、ゲートウェイはパケットを受信した旨の確認応答を発信して信頼性のあるコ
ネクションを提供し、移動端末装置は各データメッセージにおいて最後のデータ
パケットであることをゲートウェイに通知し、移動端末装置はゲートウェイに最
後のデータメッセージであることを通知することを特徴とするデータ伝送システ
ム。
【請求項３２】コンピュータ可読媒体に格納されたコンピュータプログラ
ム製品であって、センダとレシーバの間で無線リンクを介してトランザクションをコンピュータ
に実行させるコンピュータ可読プログラム手段であって、トランザクションが複
数のデータメッセージを含む伝送データを有するコンピュータ可読プログラム手
段と、センダに、レシーバへメッセージを順に送信させるコンピュータ可読プログラ
ム手段と、レシーバにパケットを受信した旨の確認応答を発信させて、信頼性のあるコネ
クションを提供するコンピュータ可読プログラム手段と、最後のデータパケットであることのレシーバへの通知をセンダに行わせるコン
ピュータ可読プログラム手段と、最後のデータメッセージであることのレシーバへの通知をセンダに行わせるコ
ンピュータ可読プログラム手段と、を有することを特徴とするコンピュータプロ
グラム製品。