JP4334770B2 - 通信装置と信頼性が高く遅延が短いパケット通信方法 - Google Patents

Description

【０００１】
発明の属する技術分野
本発明は、例えばインターネットと称するパケット交換ネットワークとコンピュータの間に確立した接続を介してデータパケットを送るための通信装置と方法に関するものである。
【０００２】
発明の背景
近年のデータ処理及び通信技術の進歩に伴い、現代社会の多くの側面、例えば科学及び軍事の世界あるいは急速に発展しつつあるビジネスと個人利用、においてデータ交換ネートワークの確立が必須となっている。この最も良い例が、インターネットと称する世界規模の通信網において躍進しているサービスの提供とサービス需要である。基本的には、「インターネット」という用語は、非常に良く知られた言葉であるが、この言葉は単に他のネットワークから構成されたネットワークを意味するに過ぎず、いわゆるワールドワイド「インターネット」はその一例に過ぎない。
【０００３】
ネットワークにおいて広く使用されているデータ交換の基本はパケット交換によるものである。つまり、送信すべきデータをユニットに分割する。ユニットの送受信規則とユニットの構成に関する規則はいわゆるプロトコルによって定められている。プロトコルとは送信側と受信側の通信を可能にする規則の集合であり、規則とは、送信側と受信側を拘束するプロトコルの下で受信側がデータを解釈して対応することができるようにするためには、送信データをどのように構成して送るべきかを定めるものである。
【０００４】
異なるネットワーク間すなわち多くのソフトウエアとハードウエアの間でのデータ交換を可能にする重要な概念は、プロトコルの階層化である。これは、多くのプロトコル（スウィートと呼ばれることも有る)が、階層化されたレイヤ構造をしており、各レイヤが固有の機能と責任を有するというものである。図３ないし５を参照してこの点を簡単に説明する。この概念に関するより詳細な解説は、Ｗ．リチャード スティーブンス著「図解ＴＣＰ／ＩＰ，第１巻，プロトコル」、１９９４年、アディソン ウェズリー社刊に記載されている。
【０００５】
通信制御プロトコル(ＴＣＰ)とインターネットプロトコル(ＩＰ)はインターネット上で通信を行うことができるプロトコルの一例である。しかし、通常ＴＣＰ／ＩＰと呼ばれているものは他のプロトコルも含むものである。いわゆるＴＣＰ／ＩＰスウィートは、図３に示したように４つの階層を有する。リンクレイヤは、ケーブルや無線通信のような物理通信媒体に対するデータの入出力を取り扱う。代表的な場合は、リンクレイヤはＯＳと対応するネットワークインターフェースの中のデバイスドライバに組み込まれている。ネットワークレイヤはネットワークの中でのパケットの移動つまりルーティングを行う。ＩＰはネットワークレイヤプロトコルの一例である。搬送レイヤは上位のアプリケーションレイヤに対してデータの流れを供給する。ＴＣＰは搬送レイヤの一例である。ＴＣＰに代わるものとして利用者データグラムプロトコル(ＵＤＰ)がある。アプリケーションレイヤとしてはデータを送受信するプログラムつまりe-mailプログラムがある。
【０００６】
２点間における相互通信の概要を図４に示す。データはまず階層を通じて下に降ろされ送信側の物理接続に入力され、次に受信側の階層を情報に移動する。この移動が実線の矢印で示されている。所定のレイヤにおいて当該レイヤに与えられたプロトコルに従ってデータ処理を行うエレメントは（図４に示した搬送レイヤにおけるＴＣＰ)は、ピアとも呼ばれる。換言すれば、図４に例示した搬送レイヤはＰＣＴピアによって処理される。図４の下部に示した物理接続は、接続の種類によっては当該レイヤの１つ以上のプロトコルでもありえることに注意する必要がある。この点は以下においてさらに詳細に説明する。
【０００７】
図５は、レイヤ間のデータ搬送を示したものである。パケットの典型的な基本構造は２つの部分、つまりヘッダとペイロード部分からなる。ヘッダはペイロード部分に含まれるデータのタイプと対応するレイヤの通信制御に関する情報を有する。図５に示されているように、アプリケーションレイヤにおいて、利用者のデータにヘッダが追加される。その結果として得られるデータユニット又はパケットが搬送レイヤに送られ、そこでＴＣＰヘッダが追加される。このＴＣＰヘッダは受信側のＴＣＰピアのための情報を含む。その結果得られるパケットは場合によってはＴＣＰセグメントとも呼ばれる。このＴＣＰセグメントはネットワークレイヤに送られ、ここで図５に示した例に従えば、ルーティング情報を含むＩＰヘッダが追加される。その結果のパケットはＩＰデータグラムと呼ばれることも有る。最終的に、ＩＰデータグラムはリンクレイヤに送られ、リンクレイヤプロトコル(ＬＬＰ)に関するヘッダ、つまりポイントからポイントへのプロトコル（ＰＰＰ)が追加される。その結果として得られるパケットは一般にフレームと称する。フレームには、受信側でフレームの開始と終了を認識できるように、開始フラグと終了フラグが追加される。このような上位レイヤのパケットを下位レイヤのパケットに埋め込む手続をカプセル化(encapsulation)と称する。
【０００８】
受信側では、利用者のデータは、図５に示したのとは逆の順序で逆カプセル化(de-encapsulation)を行うことによって取り出される。上述の説明は一例であって多くの変形が可能であることは注意する必要がある。例えば、プロトコルによってはヘッダだけでなくテーラを追加するものもある。
【０００９】
パケットはアプリケーションレイヤから出発しなければならないわけではなく、ずっと下位のレイヤが、当該レイヤにのみ関する情報を受信側の対応するピアに送り届けるために、パケットを作成しても良いことは注意が必要である。この例として、リンク制御プロトコル(ＬＣＰ)パケットを、上位の階層のデータを送る前に送り、前記ＬＣＰパケットがリンクレイヤピアによって調整可能および／またはネゴをすることができる(物理的に確立された）リンクを形成するために使用することが挙げられる。
【００１０】
図４は、４つのピアが送受信のそれぞれの側にある概念を示すものである。現実の状態はもっと複雑である。図６は、ＩＰ‐ホスト１とＩＰ‐ホスト２の間の通信の概念を示すものである。図の最上部は物理通信パスを示し、図の下の部分は種々のプロトコルに対応する論理通信パスを表す。図６に示した例はＧＳＭネットワークを介したインターネット接続に関するものである。
【００１１】
ＩＰ‐ホスト１はラップトップコンピュータであっても良い。端末適用機能ＴＡＦは、移動局ＭＳつまり移動電話に接続されたＰＣＭＣＩＡインターフェースカードによって果たされる。移動局ＭＳは、基地局制御装置ＢＳＣに接続された無線基地局ＢＴＳと通信を行う。公衆切替電話網ＰＳＴＮへの接続は、無線基地局ＢＴＳと対応する移動スイッチングセンタＭＳＣのインターワーキング機能ＩＷＦ内のモデムによって公衆切替電話網ＰＳＴＮと接続される。ＧＳＭがデジタル回線なので、ＴＡＦはモデムではないことに注意する必要がある。最終的に、ＰＳＴＮはインターネットサービスプロバイダＩＳＰへの接続を提供し、ＩＳＰがインターネットへのゲートウエイとなる。インターネットと、ＩＰ‐ホスト１からのe-mailが送られるパーソナルコンピュータであるＩＰ‐ホスト２との物理接続は図示されていない。
【００１２】
図６の下部に示されているように、ＴＣＰピア、ＩＰピアとＰＰＰピアがＩＰ‐ホスト１に埋め込まれている。対応するＴＣＰピアとＩＰピアはＩＰ‐ホスト２に設けられ、ＩＰピアとＰＰＰピアはインターネットサービスプロバイダＩＳＰに設けられている。
【００１３】
階層化スキームの重要な側面の一つは、異なる階層は「透明」なことである。これは、あるレイヤのピアは別のレイヤで発生することに対して自明であることを意味する。例えば、ＰＰＰピアは、ＩＰ‐ホスト１とインターネットサービスプロバイダＩＳＰとの間に擬似的なＰＰＰ接続を確立する。２つのＰＰＰピアは使用されている物理接続の種類によらず独立に動く、つまり、下位のレイヤにどのプロトコルが使用されているかとは独立に動く。同様に、ＰＰＰピアは上位のレイヤから到来するパケットを透明に、つまりその中身を感知することなく通過させる。
【００１４】
図６に示した例では、移動ステーションＭＳと無線基地局ＢＴＳとの間に前方誤差修正(ＦＥＣ)レイヤとインターリーブレイヤが設けられ、レイヤ２の伝送(Ｌ２Ｒ)と無線接続プロトコル(ＲＬＰ)による接続が、端末適合機能ＴＡＦと移動スイッチングセンタＭＳＣとの間に確立され、Ｖ．４２とＶ．３２インターフェースが、中間動作機能ＩＷＦとインターネットプロバイダＩＳＰとの間に確立される。これらのプロトコルは、ＲＬＰ以外全て既知なので、以下においてはこれ以上詳細な記述を行わないことにする。
【００１５】
ＲＬＰは上位の階層からのデータの移動を担当するものでは有るが、カプセル化によってこれを行うのではなく、つまり、上位の階層のデータユニットを１つの下位のレイヤのデータユニットとするのではなく、ＲＬＰは分割を行う、つまり、上位の１つのデータユニットを複数のセグメントに分割して、それぞれのセグメントを１つの下位のデータユニットに挿入することに留意する必要がある。換言すれば、ＲＬＰデータユニットはそれが取り扱う上位のレイヤのデータユニット（つまりＰＰＰフレーム)よりも小さい。上位のレイヤのデータユニットを下位のレイヤのデータユニットに挿入する基本的な考え方は、本明細書では埋め込みと称し、カプセル化と分割とを包括する概念である。
【００１６】
上の記載からも理解されるように、異なるプロトコルに対応したパケットは、場合に応じて、フレーム、セグメント、データグラム等のような異なる呼び名で呼ばれる。明確化のために、本明細書では「パケット」の用語を、定義された構文を有し、プロトコルによって予め定められたデータ構造を有するデータユニットを包括的に意味するものとする。「データ構造」とは、規定された位置(アドレス)に有る特定のデータが対応するプロトコルに従って特定の意味を有することを意味する。この一例を、高レヴェルデータリンク制御プロトコル(ＨＤＬＣ)に基づくフレーム構造を示す図７を参照して説明する。ＨＤＬＣは非常に基本的なプロトコルであり、ＰＰＰはＨＤＬＣの基本特性の多くを採用している。
【００１７】
図７に、アドレスフィールド、制御フィールド、情報フィールド及びチェックフィールドを有するＨＤＬＣフレームを示す。ＨＤＬＣでは、アドレスフィールド、制御フィールド及び情報フィールドは可変長であるが、チェックフィールドはプロトコルによって定められた固定長を有する。例えば、情報フィールドは単に制御フィールドに続きチェック値の前の８文字である。
【００１８】
従ってフィールドは前述の意味において規定された位置の例であり、プロトコルは特定のフィールド内の特定の数が予め定められた方法に従って解釈されるべきことを定める、つまり、その値はプロトコルによって定められる特定の意味を有する。
【００１９】
本発明が解決する課題
パケットを送る際は、通信信頼性モードを付与することが知られている。つまり、上述のＨＤＬＣは２つの通信信頼性、つまりいわゆる数値化されたモード（またはＩ‐モード)及びいわゆる無番（ＵＩ‐モード)モードである。
【００２０】
番号つきのモードにおいて、送り出されたパケットが受け取りピアで正しく受け取られなかった場合には、送り側のピアは当該パケットを再度送信する。送信されたパケットの数に基づいて、このようにして、遅延を生じはするが全てのパケットが正しく伝達される。パケットが正しく受信された旨の情報は受信ピアから送信ピアへの確認メッセージによって一般に伝達され、送信と再送信の正確な流れの制御は移動ウインドウによって（いわゆるウインドウベースフロー制御によって)、送信側は確認を受領する前に複数のパケットを送信することによって、つまり、パケットを送信するたびに個々のパケットについての受信確認をすることなく行われる。このフロー制御は当該技術において、例えば前出のスティーブンスの著書によって良く知られているのでここで繰り返すことはしない。
【００２１】
番号つきのモードとは異なり、無番モードにおいては再送信は行われない。これは、パケットが正しく受信されたか否かとは無関係に、パケットは所定の順序で送信されるだけであることを意味する。このモードは送信が早い特徴を有するが、伝送の信頼性は物理接続の品質に依存する。
【００２２】
伝送の信頼性は無線接続の場合に、特に問題となる。図６に示した例では、無線接続プロトコルＲＬＰが使用されている。ＲＬＰの全ての知られている設定は番号付のモードを使用するように固定されている。このようにして、通信品質が大きく変動する無線接続による信頼性の有るデータの伝送が確保されている。図６に示すように、移動局ＭＳが接続のセットアップにおいて、ＲＬＰを実行することが内容に要求することができるように（図６に示した例では透明回路切替ＧＳＭデータサービスとも呼ばれる)システムを構成することが知られている。これによって伝送遅延を縮小することができるが、その代わりに伝送の信頼性は低下することになる。
【００２３】
問題はＲＬＰや無線接続に限定されるものではなく、上述の番号付モードのように信頼性の有るモードを提供するどのようなプロトコルに関しても存在する。
【００２４】
さらに、一般的に、特定のレイヤにおいてパケットを送信するために何れのモードを選択すべきかという問題も存在する。
【００２５】
ブレーク他によるコメント募集(ＲｆＣ)２４７５、１９９８年１２月により（http://www.ietf.org/html.charters/diffserv-charger.html)、異なるサービスのためのアーキテクチャーが知られている。ＲｆＣ２４７５はパスに存在するノードにおける特定のホップごとの前進挙動(ＰＨＢ)を受け取ることができるようにパケットをクラス分類して指標をつけることを提案している。所定のプロトコルレイヤに属するパケットのヘッダのヘッダ情報はそのプロトコルレイヤの操作にのみ使用されるものである。区別されたサービスアーキテクチャは、ネットワークに入ってくるトラヒックをネットワークの境界においてクラス分けして場合によっては条件付けを行い、異なる挙動の集合に対応付けるモデルに基づくものである。それぞれの挙動の集合は単一の区別されたサービス(ＤＳ)コードポイントによって区別される。トラヒックストリーム中のパケットをパケットヘッダ中の一部に含まれる内容に基づいて選別するパケット分類機能が記述されている。すでに述べたように、ＩＰレイヤに属するＤＳコードポイントやＤＳフィールドは、そのＩＰレイヤにおいてのみ使用される。ＤＳコードポイントのみに基づいてパケットを分類する挙動集合分類手段が記載されている。同様に、１つ以上のヘッダフィールドの組み合わせからなる値によってパケットを分類する多フィールド分類手段が記載されている。
国際公開公報ＷＯ９５ ３１０６０Ａは、メッセージの種類に基づいてデータパケットを伝送する方法を開示するものである。データは情報源から端末まで伝送されるに際して、ネットワークインターフェースは、送られるメッセージの種類に基づいてパケットスイッチネットワークか回路スイッチネットワークかを選択することができる。開示された方法の目的は、パケットスイッチネットワークか回路スイッチネットワークのいずれかを通じて、最適パスを使用するようデータを適切にルーティングすることである。例えば、電子メールのような短いメッセージはパケットスイッチネットワークを通じて送る必要があるのに対して、ファイル転送のような長いメッセージは回路スイッチネットワークを通じて送る必要がある。
【００２６】
本発明の目的
上述の問題を解決し、より効率的にモードの選択制御を行うことができる、つまり送信信頼性と送信速度の関係を改善することのできるプロトコルを実現するメカニズムを提供することが本発明の目的である。
【００２７】
発明の記述
上記の目的は、所定の第２のプロトコルによって規定された第２の構造を有するデータパケットを受け取るように構成された、第１の所定のプロトコルによって規定される第１のデータ構造を有するデータパケットを作成し、前記の第１の構造のデータパケット１つ以上に前記第２の構造を有するデータパケットを埋め込んで前記第１の構造のデータパケットを作成する通信装置であって、前記第２の構造を有するデータパケットの内容に基づいて、所定の規則に従って前記第２の構造を有するデータパケットを区別するように構成された判別手段を有する独立請求項に記載された装置によって達成する。
【００２８】
発明の好ましい実施態様は従属請求項に記載されている。
【００２９】
本発明に従えば、プロトコルの実行は送信されるデータのタイプに依存し、送信に関連するパラメータの設定を自動的に送信されるパケットの内容に応じて調整するレイヤにおいて行うことができる。換言すれば、本発明はデータが上位のレイヤから受け取られたものであることを考慮して、カプセル化又、セグメント化、さらに転送（リンクに直接かあるいは低層のレイヤを介してであるかにかかわらず)、調整可能なパラメータに関してクラス分類に従ってパケットごとにパラメータが自動的に調整される異なるカテゴリーに分類される。
【００３０】
内容という用語はいかなる内容をも含む広い意味で使用する。判別のために使用する特定のタイプの内容は下位のレイヤの分類操作を考慮して特定のレイヤにおいてパケットの製作時にデータに注意して追加されても良い、つまり、上位のレイヤプロトコルの所定のフィールドを利用して、上位のレイヤのピアが下位のレイヤでの処理に影響を与えるために上位のレイヤのピアが下位のレイヤのピアに対して情報を特定することも可能であるし、あるいは、下位のレイヤにおける判別処理は独立にかつ個々に、上位のレイヤからの影響無しに、下位のレイヤに対して情報を伝達することを意図していないデータつまりヘッダのプロトコルＩＤを分析することによって行うことも可能であることに留意する必要がある。
【００３１】
本発明は、従って、全てのレイヤは互いに独立に用いられなければならないという強固に確立された規準と基本的に矛盾するものである。これまで知られていたものとは対照的に、接続を確立する際に、下位のレイヤにおいて、上位のレイヤに特定のパラメータ（つまり信頼性)をセットさせる可能性に対して、本発明は所定のレイヤにおける所定のプロトコルに情報を与え、柔軟にかつそれ自身の決定に従って連続的にどの種類のパケットが送信されるかに従ってパラメータを設定するものである。
【００３２】
本発明の好ましい実施例によれば、前記の調整可能なパラメータは信頼性モードに関連し、信頼性モード(番号つき又は無番のモード)は、判別結果に従って、埋め込みを行うレイヤにおいて自動的に調整される。
【００３３】
この好ましい実施例によれば、本発明が適用される送信信頼性モードが異なるデータパケットが複数のピアの間で自動的に同時送信することができる利点を有する。例えば、セグメンテーションによってＰＰＰパケットの埋め込みを行い、上位のレイヤのパケットのカプセル化を行うＩＰあるいはより上位のＴＣＰやＵＤＰにおけるＲＬＰの埋め込みに本発明を利用すれば、本発明に基づくＲＬＰの実行によってＵＤＰパケットを含むパケットとＴＣＰパケットを含むパケットとを区別することができ、したがって、ＲＬＰレイヤにおいて、ＵＤＰパケットは無番モードで送信しＴＣＰパケットは番号つきモードで送信することが可能になる。
【００３４】
この例ですでに述べたように、信頼性モードの設定に関する実施例は好ましくはリンクレイヤのプロトコル（例えばＲＬＰ)の実行に適用されるものである。同様に、カテゴリへの分類は好ましくは、分類された上位のレイヤパケットの信頼性規定を考慮して行われる。上述の例では、ＵＤＰパケットは無番モードで送信されるカテゴリに分類されるが、このことはＵＤＰが誤差を含むパケットの再送信を行わないことを考慮すると長所である。対照的に、ＴＣＰは再送信の可能性を提供する。本発明を適用することによって、ＴＣＰパケットとＵＤＰパケットをＲＬＰレイヤで同時送信することが可能であり、この方式にもかかわらずＲＬＰレイヤにおけるそれぞれのパケットの通信信頼性モードは、ＴＣＰパケットを番号つきモードの必要な所望の信頼性の下で送信し、ＵＤＰパケットを同様に番号つきのモードで送信しながら再送信による不要な遅延を生じることがない。
【００３５】
上述の例に関しては、発明には非常に大きな利点がある。ＰＰＰは、ＩＰ、ＬＣＰ（リンク制御プロトコル)、ＰＡＰ(パスワード認証プロトコル)等のような複数のプロトコルをシリアルリンクを介して同時に伝送するために使用される。ＰＰＰプロトコル識別子は、特定のＰＰＰパケットにどのプロトコルデータユニット(ＰＤＵ)またはプロトコルパケットが含まれているかを表示する。ＰＰＰによって送信されるＩＰは、ＴＣＰ、ＵＤＰ及びＩＣＭＰ(インターネット制御メッセージプロトコル)複数プロトコルのパケットを送信することができ、これらのプロトコルもまたＩＰヘッダの中のプロトコル識別によって区別される。ＰＰＰによって送信されるプロトコルは、信頼性と遅延に関するトレードオフ要求が異なる。したがって、特定のデータストリームに対して番号つきモードが好ましいか、あるいは無番モードが好ましいかは一様でない。より具体的には、ＬＣＰやＰＡＰのような信号メッセージは番号つきモードで送信する必要があり、実時間データストリーム（例えば、ＵＤＰパケットで送信されるインターネット電話会話の音声信号）は通常データ喪失に強いが遅延に敏感なので、無番モードによる送信が好ましい。
【００３６】
従来知られている実施方法とシステムではこの問題を解決することができない。ＲＬＰが番号つきのモードに固定して動いていれば、実時間のＵＤＰデータストリームを番号つきのモードを必要としているデータストリーム（例えばＴＣＰ)と移動計算装置の上で同時に送信することはできない。ＲＬＰが使用されていなければ、回路切替接続が達成された後は、つまり課金が開始された後は、無番モードでＬＣＰパケットのデータが変容する可能性があるので、ＰＰＰ接続を行うことができない。したがって、利用者は使用料を支払わなければならないにもかかわらず必要なサービスを受けることができない。
【００３７】
本発明は、ＲＬＰの実行が自動的にＬＣＰメッセージを番号つきモードで送って安全なＰＰＰリンクを達成し、続いて無番モードでＵＤＰパケットを含むＰＰＰパケットを送ることで、遅延を生じさせずにこの問題を解消するものである。さらに、同一の接続において異なる時間に種類の異なるパケットを送るこの問題を解決するだけでなく、本発明は同時に２つの（信頼性に関して）互いに対立するストリームを並行して送信する、例えば上述のＵＤＰデータストリームと同時にＴＣＰパケットを送信することを可能にするものである。
【００３８】
上述のプロトコルと上述の状態は本発明の実施例と利点を説明するために用いた例に過ぎない点に留意する必要がある。すでに述べたように、信頼性の設定に関する実施例は２つ以上の信頼性モードを許容するプロトコルの実行に用いることができる。例えば、本発明はＬＬＣ（論理リンク制御）パケットをＲＬＣ（無線リンク制御）リンク上で送信する場合にも使用することができる。同様に、実施の位置は上述の図６に示した例に限定されず、与えられたプロトコルにおいて適当又は必要な位置であれば何処にでも用いることができる。例えば、一般パケット無線サービス(ＧＰＲＳ)においては、ＴＡＦとＧＳＮ（ＧＰＲＳサポートノード)である。
【００３９】
結果的には、このことは、本発明を信頼性モードの設定に適用することによって自動的に、提供または選択された通信信頼性モードの数に対応して、特定のパケットを特定の仮想チャネルに設定する、仮想的通信信頼性チャネルが提供されることを意味する。上述の例では、番号つきチャネルと無番チャネルが提供され、ＴＣＰパケット（より正確に言えばＴＣＰパケットを埋め込んだパケット)が番号つきチャネルで送られＵＤＰパケットが無番チャネルで送られるように、２つの送信信頼性モードが使用されているので、２つの仮想的チャネルが提供されることになる。
【００４０】
上述の例をより一般的に表現すれば、本発明は、運転モード（ＡＲＱのこの意味においては信頼性モード) の選択が埋め込まれたパケットの内容に基づくことができるＡＲＱ準拠誤り修正（ＡＲＱは自動繰り返し要求)に適用することができる。適用可能なモードは当然２つ、つまり、非信頼（ＵＩモード)と信頼（Ｉモード)、に限定されず、非信頼（ＵＩモード)と信頼（Ｉモード)に加えて前記の２つのモードに加えてシーケンス中の配信又はシーケンス外の配信による半信頼モードを有するなどもっと数が多くても良い。
【００４１】
上述のように、本発明は信頼性モードの設定に提供することができるが、これに限定されるわけではない。全く反対に、本発明は上位のレイヤのパケットを下位のレイヤに埋め込むことに関する全ての種類の処理モードの設定又は調整に対して適用することができる。より具体的には、本発明は、少なくとも２つのモードを有する全ての通信スキームに対して適用することができる。例えば、受信側が誤りを有するフレームを廃棄する、受信側が誤りを有するフレームに標識をつけるが廃棄しない、あるいは、受信側が誤りを有するフレームに標識もせずに廃棄もせず、判別操作は当然これらのうちの２つのモード又は３つのモード全てにもとづくものであるような動作モードを有するＦＣＳ（フレームチェックシーケンス）エラー検出通信スキームである。あるいは、本発明は、２つあるいはそれ以上のＦＥＣスキームを使用した動作モードを使用したＦＥＣ準拠エラー修正（前方エラー制御)に適用することもできる。あるいは、本発明は、例えば、２つあるいはそれ以上のインターリーブスキームを利用した動作モードを利用したインターリーブに基づくエラー防止通信スキームに適用することができる。あるいは、本発明は、例えば、２つ又はそれ以上のパワーレベルを利用した動作モードを利用したパワー制御通信スキームに適用することができる。さらに本発明は、例えば、２つ又はそれ以上の拡散係数を使用した拡散に基づく(例えばＣＤＭＡのようなスペクトル拡散技術）通信スキームに適用することができる。また本発明は、例えば２つ又はそれ以上のフレーム長を採ることができる動作モードを利用したフレーム長制御通信スキームに対して適用することができる。また、本発明は、例えばＧＰＲＳ通信規準のような１、２、３、・・・８倍スロット割り当てのような適当な動作モードを利用したバンド幅保存制御通信スキームに提供することができる。
【００４２】
本発明の重要な利点の一つは、本発明は基本的にプロトコルの変更を必要とせず、ピア実行の変更のみによって適合性や移行の問題を生じずにどのような内容に対しても広く適用可能な点である。
【００４３】
本発明の他の好ましい実施例によれば、本発明は、上位のレイヤのパケット又はデータユニットが下位のレイヤで埋め込まれるときに上位のレイヤのピアによって特定された通信品質の要求に従って、仮想のレイヤでパケット通信を行うことができる(たとえばＱｏＳ(サービス品質)要求および／又は通信特性) 。上位のレイヤのピアはそのレイヤのパケットを下位のレイヤに品質要求を送るためのビークルとして使用する、つまり、前記品質要求を両方のレイヤにおいて理解される標準化されたスキームが存在する。たとえば、これは上位のレイヤパケットのヘッダ中の所定のフィールドを使用して、そのフィールドに含まれる内容を標準化することによって行われる。他の表現をすれば、上位のレイヤから下位のレイヤに品質要求を伝達するためにある種の制御チャネルが提供されている。この品質要求は上位のレイヤパケットやフロー（フローは特定することができる連続したパケットである)をオペレーティングモードのために下位のレイヤに伝達されるだけでなく、前記品質要求に基づいて少なくとも一部については、それ自身によってオペレーションモードを動的に適用する。
【００４４】
通信品質要求は、上位のレイヤが下位のレイヤに対して特定のオペレーティングモードを設定させる品質命令と指定使用することができる制御情報であるか、あるいは、下位のレイヤが当該品質要求を搬送している特定のパケットに対して当該品質要求に従って自由に動作モードを選択するが、上位のレイヤは下位のレイヤがどのモードを選択するかについて直接制御を行わないものであることに留意する必要がある。
【００４５】
本発明の上記以外の側面と利点は、本発明の好ましい実施態様を示す図面を参照して行う以下の発明の好ましい実施例についての詳細な説明によって一層明らかになるはずである。
【００４６】
通信信頼性モードの設定に関する実施例を示して本発明について説明することにする。既に述べたように、これは本発明の好ましい実施例であり、本発明の説明のために記述するものである。しかし、発明は全ての種類の調製可能なパラメータを設定することに適用可能で、セキュリティモードの設定に使用することもできる。
【００４７】
図１を参照して本発明の基本構成について説明する。この実施例の場合は、レイヤｎの通信プロトコルを装備した通信装置が上位のレイヤ(ｎ＋１)からパケットを受け取り、このパケットをレイヤｎのパケットに埋め込む。既に述べたように、「埋め込む」という言葉は、カプセル化およびセグメント化の両方を含む概念である。説明の重複を避けるために、本発明の導入部分の記載はすべて本発明の説明に取り込まれていることに注意する必要がある。
【００４８】
たとえば、レイヤｎのプロトコルはＲＬＰであり、レイヤ（ｎ＋１）のパケットはＰＰＰフレームであってもよく、この場合には埋め込みは、ＰＰＰフレーム又はパケットを複数のＲＬＰパケットへの分割を意味することになる。ＰＰＰフレームは典型的には１５００バイトの長さを有し、それに対してＲＬＰフレームは典型的には３０バイトの長さしかない。別の例を示せば、レイヤｎのプロトコルがＰＰＰであって、レイヤ（ｎ＋１)のプロトコルがより上位の適当なプロトコル、たとえば図５に示したようなプロトコルであって、この場合には埋め込みはカプセル化によって行われる。
【００４９】
本発明によれば、実施例は判別装置１を具備しており、これがレイヤｎ＋１のパケットを受け取り、この判別装置が受け取ったパケットをあらかじめ定められたクラス分類規則に従って判別する。つまり、判別装置が受け取ったパケットの特定の特徴を確認し、受け取ったパケットをその特徴に基づいて分類することを意味する。この例の１つとして、レイヤｎのパケットがＰＰＰフレームであって、受け取ったＰＰＰフレームの個々のヘッダをチェックしてこのフレームによってどの種類の情報が送られているかを決定し、その結果に従ってフレームをクラス分類する。たとえば、フレームがＬＣＰ情報を搬送していれば、これは「信頼性の高い伝送」に分類され、これがＵＤＰ情報を搬送していれば、「信頼性は要求されていない」カテゴリに分類される。
【００５０】
上述のプロトコルとカテゴリは例示に過ぎないものであり、本発明は受信したパケットをその内容にしたがってクラス分類することができる全ての形式のディスクリミネータに関連するものである。したがって、これらのパケットのプロトコルは何でもよくパケットがクラス分類されるカテゴリの数は任意である。このカテゴリの数はレイヤｎのプロトコルが提供する通信信頼性モードの数と同じであっても良いが、レイヤｎのプロトコルが２つ以上のモードを提供する場合にはそれよりも少なくても良い。
【００５１】
判別の結果、つまり、クラス分類は制御手段２に伝達され、制御手段２は次に通信信頼性設定コマンドによって埋め込み手段３を制御する。換言すれば、判別装置は埋め込まれるべきパケットを埋め込み手段３にし、そこでレイヤｎの１つ以上のパケットに埋め込まれ、レイヤｎのそれぞれのパケットに対して対応するフラグによって適宜設定されている通信信頼性モードが通信信頼性設定コマンドに従って設定される。
【００５２】
次に、このようにして作成されたレイヤｎのパケットは、次の処理ステージに対して伝達される。次の処理ステージはアプリケーションによって異なり、所望のあるいは必要な方法に従って適宜選択されることができる。たとえば、レイヤｎのパケットが次の（図示しない）仮想レイヤ（ｎ−１）に直接進むことが意図されていれば、レイヤｎのパケットは次のレイヤの入力バッファにただ渡されるだけであってもよい。しかし、もし、パケットを確立されたリンクを通じて送り出すことが想定されている場合は、それらは出力バッファに置かれ、該当する状況に応じて適宜制御されることが好ましい。その種の出力バッファからのデータ送信の適当な制御はアプリケーションに依存する、つまりレイヤｎのプロトコルとそのリンクに依存する。
【００５３】
上述の記載から理解されるように、本発明は、１つのレイヤのパケットを他のレイヤのパケットに埋め込み、少なくとも２つの異なる信頼性モードを提供するどのようなプロトコルに対しても適用することができるので非常に柔軟性が高い。
【００５４】
図２は、本発明にかかる方法を示すフローチャートである。第１のステップＳ１では、より上位のレイヤのパケットが受信されたか否かが判断される。上位のレイヤのパケットが受信されたときは、処理はＳ２に進み、受信されたパケットはあらかじめ定められたクラス分類規則に従って判別される。次にステップＳ３において、受信されたパケットは所定のレイヤの１つ又はそれ以上のパケットに埋め込まれ（図１ではｎ）、パケットそれぞれの通信信頼性モードは判別結果に従って設定される。最終的に、埋め込まれたパケットは次のステージに送られ、そこで図２に示した処理によってパケットはステップＳ４で送信のために出力バッファに送られる。
【００５５】
図１に示したシステムに対応し、かつ入出力バッファを具備するシステムを図８に示す。図に示されているように、図８に示した装置もまた判別装置１、制御手段２と埋め込み手段３とを有し、さらに入力バッファ４と出力バッファ５が図示されているが、これらは共に制御手段２に接続されてこれによって制御されている。この動作は図１に関して説明したものと同様であるが、レイヤｎのパケットが入力バッファ４を通じて判別装置１に供給され、そこでは制御手段２が入力バッファ４がパケットを判別装置１に適宜渡すように制御し、図８に一例を例示したように、埋め込み手段３がレイヤｎのパケットを出力バッファに送り、次にレイヤｎのこのパケットが制御手段２の制御の元で送り出されるされる点が異なっている。
【００５６】
既に記載したように、本発明は、適当などのようなフロー制御をを選択することができるという柔軟性を有する。たとえば、上述の番号つきモードと無番モードのような２つの通信信頼性モードが存在する場合、レイヤｎの対応するパケットは出力バッファ５の別々のキューに入れておくことができる。換言すれば、レイヤｎのパケットに対して設定することができる通信信頼性モードが２つあれば、出力バッファは番号つきのモードのパケット用のキューと無番パケット用のキューの２つを具備することになる。
【００５７】
一般的に、図８に示したこのシステムの１つの実施例では、出力バッファ５は、通信信頼性モードそれぞれに対応してキューを有しており、パケットは判別装置１によって判別されてそれぞれのキューに収用される。それぞれのキュー内のパケットは適当な又は所望のどのような方法によっても取り扱うことができる、つまり、それぞれのキューにあらかじめ設定した優先順位を設けることもできる（固有の信頼性モード）。番号つきのモードと無番モードのみを有する場合の例は、第１に送り出すべきパケットに関しては番号つきのパケットと無番のパケットの間に基本的な優先順位は無いが（これらのパケットはどのキューにあったかとは無関係にＦＩＦＯで扱われる）、再送しなければならない番号つきのパケットは優先順位が高く、したがって優先的に送信される。このような場合には、番号つきのモードのキューからのフローの制御は、これらのパケットを単に適当な順序で送信することによって行われる。
【００５８】
しかし、以下に他の実施例を用いて説明するように、上記とは異なる方法を採用することも可能である。
【００５９】
本発明の好ましい実施例を図９ａと９ｂに示す。図２との関連で既に説明したステップには同じ引用番号をつけた。図９ａと９ｂに示した方法は、番号つきの信頼性モード（Ｉ−モード)と無番の信頼性モード（ＵＩ−モード)を提供するプロトコルが実行される場合に対応する。換言すれば、番号つきのモードでは、正しく受信したことは確認パッケージによって送信側のピアに知らされ受信側のピアによってパケットが正しく受信されなかったときは当該パケットは再送信されるが、無番モードでは再送信は行われない。
【００６０】
図９では、図２に示したものと同じ又はそれに対応するステップには同じ番号を付与してある。第１のステップＳ１では、上位のレイヤのパケットが受信されたか否かが決定される。仮にそうであれば、処理はステップＳ２１に進み、そこで受信された上位のレイヤのパケットに含まれるプロトコルＩＤが分析される。たとえば、仮に受信された上位のパケットが図５の底部に示すようにＰＰＰフレームであれば、プロセスは単に開始フラグから直接続くＰＰＰヘッダをチェックするだけである。次に、ステップＳ２２において、確認されたプロトコルＩＤが番号つきモードのものであるか否かが判断され、この分類は前述のあらかじめ設定された規則にしたがって行われる。仮に、ＰＰＰパケットの場合は、前記の規則はＬＣＰパケットを番号付のモードに入れるようにするものであることが好ましい。何故なら、ＬＣＰパケットは高レベルの信頼性が必要なリンク確立手順の一部だからである。したがって、ステップＳ２２において、処理の結果ＬＣＰ情報が送られてきたと判断されると、処理はステップＳ３１のほうに枝分かれし、そこで受信された上位のレイヤのパケットは本発明が実行されているレイヤの１つ又はそれ以上のパケットに埋め込まれ、埋め込まれたパケットそれぞれの信頼性モードは、各パケットの対応する信頼性モードフラグを設定して番号つきのモードに設定する。
【００６１】
ステップＳ２２で特定されたプロトコルＩＤは番号つきモードのものではないことが確認されると、ステップＳ２３において、プロトコルＩＤが無番モードのものであるか否かが判断される。そうであれば、処理はステップＳ３２に進み、そこで、受信された上位のレイヤのパケットは本発明が実施されているレイヤの１つ又は２つ以上のパケットに埋め込まれて、前記１つ又は２つ以上のパケットのそれぞれの信頼性モードは適当なフラグを設定することによって無番モードに設定される。ステップＳ２２とＳ２３の結果が共に否定的であれば、ステップＳ２４は受信されたパケットのプロトコルレイヤまでチェックが行われることを示しており、次のヘッダがチェックされる。図５の底部に示した例に戻れば、これは、ＴＣＰ、ＵＤＰまたはＩＣＭＰデータを識別するためのプロトコルＩＤを含むＩＰヘッダである。次にステップＳ２１からＳ２４を繰り返す。もし識別されたプロトコルＩＤが再度番号つきモードか無番モードかを特定できないときは、処理は再度プロトコルレイヤ、図５に示した例の場合にはＴＣＰヘッダにあがる。
【００６２】
一般に、所定のプロトコルパケットと番号つきモード又は無番モードの関係は判断ステップＳ２２とＳ２３から参照される表に記憶されている。理想的には、全ての可能なプロトコルが表に記録されており、受信されたパケットは全て番号つきのモードか無番モードに分類されることが望ましい。しかし、経済性の観点から、図９ａ、と９ｂに示したプロセスにフェールセーフシステム、つまり、次のプロトコルレイヤにあがることができる回数が制限されているカウンタがステップＳ２４に設けられており、あらかじめ定められた回数を超えると受信されたパケットに対してデフォルトモードを設定するようになっていることが好ましい。このデフォルトモードは、番号付モードであっても無番モードであっても良い、当然、別のフェイルセーフ構造も可能であり、必要又は所望に応じて選択することができる。
【００６３】
図９ｂに戻れば、ステップＳ３１とＳ３２の後、処理はステップＳ４に進み、パケットは図２に示したものと同様に、出力バッファに送られる。処理は次にステップＳ１に戻って、次の上位レイヤパケットが受信されるのを待つ。
【００６４】
一般的には、図９に示した方法によれば、データパケットはパケットの内容に関する情報を含む１つ以上のセクションを有し（プロトコルの階層をカプセル化したパケット)、判別手段は前記１つ以上のセクションを分析してその内容に従ってデータパケットを判別する。より正確に言えば、前記の１つ以上のセクションは対応するプロトコルレイヤに対応し、パケットの内容が関連づけられているプロトコルを識別することができるプロトコル識別情報を含むパケットヘッダである。パケットヘッダはプロトコルレイヤによって階層構造を有しており、判別されるべきパケットに関しては、判別装置はまず第１の上位レイヤのプロトコルに対応するヘッダのプロトコル識別子を決定し、次にこのプロトコル識別子を記憶された規則と照らし合わせてプロトコル識別子とあらかじめ設定された通信信頼性モードを対応させる。さらに、判別装置は前記パケットの通信信頼性モードを、もしこのプロトコル識別子が記憶されている規則の中に発見できればあらかじめ定められていた対応に基づいて通信信頼性モードを設定し、もし前記プロトコル識別子が記憶されている規則の中に発見できなければ、階層上１つ上位の次のプロトコルに関連づけられたヘッダに含まれるプロトコル識別子を読み出して前記次のプロトコル識別子を通信信頼性モードを関連付ける記憶された規則と比較する。ここで、プロトコル識別子を確定して比較する処理を、パケット中の判別すべく決定されたプロトコル識別子が規則の１つにしたがってあらかじめ定められた通信信頼性モードの一つに対応付けられて通信信頼性モードが当該判別されるべきパケットに対して設定されるか、あるいは、フェイルセーフ条件が満足されて当該判別すべきパケットに対してデフォルト通信信頼性モードが設定される。
【００６５】
本発明は上位のレイヤパケットをリンクを介して送信するパケットに埋め込む際に分割を行うプロトコルであって、番号つきモードと無番モードの２種類の通信信頼性モードを実行するものに適用されるのが好ましい。この種のプロトコルとしては、上述のＲＬＰやＲＬＣのような無線リンク状の通信を取り扱うプロトコルを挙げることができる。
【００６６】
この種のプロトコルに対する本発明の適用は、図８および９に示した実施例に従って行われるのが好ましい。
【００６７】
このような場合には、本発明は送信すべきパケットの埋め込みに関して特徴を有するだけでなく、送信側のピアからそのような埋め込まれたリンクレイヤプロトコルを受信することに関しても、受信ピアとしての実行特性に関して特徴を有するのが好ましい。
【００６８】
以下においては、送信機および受信機として使用されるリンクレイヤプロトコルのピアのいくつかの基本的なメカニズムを、ＰＰＰフレームを分割して埋め込むリンクレイヤプロトコルの例としてＲＬＰを使って説明することにする。ただし、これらのプロトコルは説明のために例示しただけであって、ここに説明したメカニズムは他のどのようなプロトコルに対しても、適当であれば適用できることに留意する必要がある。
【００６９】
基本構成に基づけば、ＲＬＰ送信装置は上位のレイヤから受け取ったデータストリーム、つまりＰＰＰフレーム、を分析し、それぞれの上位レイヤフレームをどのモードで、つまり番号つきモードか無番モードで、送信すべきかを決定する。この処理は図８と９とに示した方法で実行されたのでここでは繰り返して説明しない。出力バッファからのフロー制御は、番号つきモードと無番モードのＲＬＰパケットの(番号つきモードのパケットに関して、何故なら無番モードは常に１度送られるだけだからである）第１の送信はＦＩＦＯにしたがって行われる。しかし、再送信しなければならない番号つきモードのＲＬＰパケットは高い優先順位を持っており、したがって、常に可能な限り速やかに送られる。
【００７０】
ＲＬＰ受信装置は無番モードと番号つきモードのパケットを分離してそれぞれ固有の別のバッファ又は少なくとも別のキューに入れる。ＲＬＰ送信装置と同様に、ＲＬＰ受信装置は常にそれぞれのバッファに含まれるデータを分析してこれによってより上位のレイヤフレームを判別する。より上位のレイヤフレームが一度だけ受信されると、受信側の上位のレイヤに送られる。無番モードで送信されたパケットに関しては、より高いレイヤのパケットのデリミタ(つまり開始又は終了フラグ)が再送信が行われないために通信途中で変わってしまっている可能性があるので、問題が起こる場合がある。この場合は、ＲＬＰ受信装置は無番モードのパケットのために固定バッファリミットを使用し、これを越えた無番モードのパケットはデリミタが受信されたか否かとは無関係に上位のレイヤに送られる。より正確に言えば、固定のバッファ限界を超過すると、ＲＬＰ受信装置は次の上位レイヤパケットデリミタが検出されるまでＲＬＰは受信した全ての無番モードのＲＬＰパケットを１つ上のレイヤに送る。前記の上位のレイヤパケットデリミタを新しい開始点として、ＲＬＰ受信装置はまた上位レイヤのパケットデリミタが次に到着するのを待つことができる、つまり、次の完全な上位レイヤパケットが受信されるのを待つことができる。
【００７１】
ＲＬＰ受信装置が各上位レイヤパケットを区別する方法は、ＲＬＰ送信装置が送信するデータの中に上位レイヤのデリミタを検出したらそれを全てコピーしてから送信させることである。換言すれば、データをその内容によって判別する代わりに、ＲＬＰ送信機もまた１つ上位のレイヤつまりＰＰＰのデリミタを探し、検出したデリミタの隣に必ず同じデリミタを挿入する。この方法は越えられてしまった固定バッファリミットがＲＬＰの受信特性内であるとき、つまり、送信機側のデリミタのコピーが送信機のバッファリミット特性と組み合わせられたときに利点がある。
【００７２】
ＲＬＰの送信側と受信側に関連する他のメカニズムについて説明する。送信側の特徴は前と同様、つまり、送信機は受け取ったデータストリームを分析して上位のレイヤのフレームをどのモードで、つまり番号つきモードか無番モードか、送信すべきかを決定する。出力バッファからのフロー制御は、再送信される番号つきモードのパケットが常に最も高い優先順位を有するようなやり方で行われる。ＲＬＰの受信特性に関しては、前述の例と同様に、受信機は受信した番号つきモードパケットと無番パケットとをそれぞれに固有のバッファ又はキューに収用する。この場合は、受信装置だけが上位のレイヤパケットを判別するために番号つきモードのパケット(ＰＰＰフレーム)を解析する。一般に、受信装置は番号つきのモードと無番モードのパケットを、番号付のモードは正しい順で渡さなければならないという通常の制約の下で、上位のレイヤにすぐに渡す。換言すれば、これは、上位のレイヤに正しい順序で渡すために一定数のパケットを記憶しなければならないことになるのを回避するために、再送信が行われている番号付きパケットの場合を除いて、受信バッファは通常は受信したパケットを保持することはせずに即刻次に引き渡す。
【００７３】
受信機が受信側でどのような順序でパケットを上位のレイヤに渡すかに関するこの規則によって４つの状態が区別される。
(ａ)無番モードのパケットのみが送信されており（たとえば、ＵＤＰセッションと呼ばれる、送信側がＵＤＰパケットのみを送信している状態)、まったく問題が無い。
(ｂ)番号つきモードのパケットのみが送信されており（たとえば、ＴＣＰセッションと呼ばれる、送信側がＴＣＰパケットのみを送信している状態)、やはりまったく問題が無い。
(ｃ)無番モードのパケットに続いて番号つきモードのパケットが送信されている(たとえばＵＤＰセッションに続いてＴＣＰセッションが行われている)、同様にまったく問題が無い。
(ｄ)番号つきモードパケットに続いて無番モードのパケットが送信されている(たとえば、ＴＣＰセッションに続いてＵＤＰセッションが、あるいは、ＵＤＰセッションとＴＣＰセッションがパラレルに送信されている)、番号つきモードのパケットが再送信を必要とするときに無番モードのパケットを受けとると問題が起こりえる。
【００７４】
(ｄ)に記載した問題を解決するために、以下のメカニズムを使用することができる。番号つきモードで送信した上位レイヤのパケットが完全に受信されていない以上(ＴＣＰパケットの終了を示すＰＰＰフレームデリミタを含むパケットが再送信されなければならない)、無番モードのパケットは一時退避させられなければならない。バッファは番号つきモードパケット全体が受信されて受け渡されるまでは上位レイヤに渡されることは無い。番号つきモードパケットが完全に受信されて１つ上位のレイヤに渡された後、無番モードパケットを含むバッファが渡される。それ以降は通常のオペレーションが続く。
【００７５】
上記に示したメカニズムの好ましい実施例に拠れば、受信機はさらにどのパケットデリミタが現在使用されているかに関する知識又は情報を有している。デフォールトデリミタは１つ上のレイヤの通常のパケットのデリミタ（つまりＰＰＰフレームデリミタ)であるが、もし他のデリミタを使用しなければならないなら、２つのリンクレイヤ、つまり２つのＲＬＰピア相互の間で取り決めることができる。これは換言すれば、上位レイヤのプロトコルパケットを処理すること、１つ以上のプロトコルの処理もできることを意味している。ＰＰＰフレームがＲＬＰパケットに埋め込まれた前記の例においては、これはＲＬＰの実行はＰＰＰを埋め込むだけでなく、ＰＰＰと同じレイヤに属する他のプロトコルのフレームを埋め込むことも可能であることを意味する。受信機がこの情報を受け取る方法は種々考えられる。リンクパラメータを相互間で決定する標準ＨＤＬＣフレームである、特別な信号フレームやＸＩＤフレームを使用したＤＨＬＣ（たとえばＧＳＭやＲＬＰ)に基づくリンクレイヤプロトコルの場合は、新しいパラメータを有する前記ＸＩＤフレームを使用することができる。
【００７６】
送信特性のみに関連する別のメカニズムについて説明する。換言すれば、受信機についてはなんら変更が無い。したがって、受信機は常に無番モードパケットを受信したときは無番モードパケットを、番号付のパケットは通常通り順序に従って送り出す。したがって、上位のレイヤのパケット（つまりＰＰＰフレーム)が受信機の側で正しく受け渡されることを確保するのは送信機である。これは、送信機が無番モードのセッションを開始する前に、無番モードのパケットは完全に終了していなければならない、つまり番号つきモードのパケットが受信機によって認識されなければならないことを意味している。受信機構を変更しないのでこのメカニズムを導入するのは容易であるが、無番モードセッションと番号つきモードセッションとが切り替わるときに遅延を生じる。
【００７７】
最後に、別のメカニズムは送信機の出力バッファを、送信機で無番モードセッションが行われているときは、無番モードを示すフラグを有するＲＬＰフレームで全ての無番モードパケットを連続的に送信するというように制御する方法である。
【００７８】
既に述べたように、上述の例は好ましい実施例としてＲＬＰとＰＰＰを使用した場合について例示したが、このメカニズムはこれらのプロトコルに限定されるわけではない。むしろこれらは適当な特徴を有するプロトコルであればどのようなプロトコルにも使用できるものである。
【００７９】
上述の実施例では、埋め込まれるパケットのパケットヘッダの特定のフィールド、つまり上位レイヤのＩＤフィールド、を用いて判別を行うこと、および、番号つきモードと無番モードである信頼性に関する２つの動作モードを使用したＡＲＱ−準拠誤り回復を用いた特定の通信スキームに基づいて発明を説明した。しかし、本発明はいかなる意味においてもこれらに限定されるものではない。
【００８０】
本発明はパケットどのような場所にあるかに無制限に、たとえばＤＳフィールドはＩＰオプションなどに限らず、またどのようなパケットの内容かに限らず判別を行う方法を提供することができる。ＡＲＱに関連付けられた動作モードに関しては、既に記載した番号モードと無番モードに加えて混合モードを使用するなど２つより多いモードを使用することもできる。
【００８１】
本発明は、ＡＲＱの通信スキームつまり誤り回復に関しても制限されず、どのような形のフォワード誤り修正を使用した動作モードに対しても適用することができる。より詳細には、本発明は少なくとも２つの異なる動作モード、たとえばＦＣＳ−に基づく誤り検出（ＦＣＳはフレームチェックシーケンスを意味する)つまり受信機が誤りを有するフレームを廃棄するか、受信機は誤りを有するフレームに標識をつけるが廃棄しないか、受信機は誤りを含むフレームを標識付けもせず廃棄もしないか、２つのモード又は３つのモードの間で区別する動作モード全てに対して適用することができる。本発明はまた、２つ以上のＦＥＣスキムを使用したＦＥＣ−に基づく（フォワード誤り訂正)誤り訂正通信スキーム、に対して適用することもできる。あるいは、本発明は２つ以上のインターリーブスキームを使用した動作モードを用いたインターリーブに基づく誤り防止通信スキームに対しても適用することができる。さらに、本発明は、２つ以上のパワーレベルを使用した動作モードのパワー制御通信スキームに使用することもできる。さらに、本発明は、２つ以上の拡散係数を使用した動作モードを使用する拡散に基づく誤り防止(たとえばＣＤＭＡのようなスペクトル拡散技術)通信スキームに適用することができる。さらに、本発明は、フレーム長として２つ以上の長さを選択することができる動作モードを利用したフレーム長制御通信スキームに適用することができる。さらに本発明は、１，２，３，．．．または８時間スロット割り当てのような動作モードつまりＧＰＲＳ通信標準を利用したバンド幅保存制御の通信スキームに適用することができる。
【００８２】
当然ながら、これらの通信スキームと動作モードはどのような任意の組み合わせも適当であれば可能である。これはたとえば番号付けられたモードと無番モードおよび４つのパワーレベルが８つのモードつまり(Ｉ−モード、パワーレベル１)、(Ｉ−モード、パワーレベル２)、．．．、（ＵＩ−モード、パワーレベル４)と組み合わせられるパワー制御モードとＡＲＱ−関連モードの組み合わせからなる一般的な動作モードにおいて判別を行うことが可能であることを意味する。既に述べたように、具体的なアプリケーションに好適なものであれば、任意の組み合わせが可能である。
【００８３】
次に、図１０を参照してさらに別の好ましい実施例について説明する。この好ましい実施例の場合には、本発明は、たとえばＱｏＳ（クオリティオブサービス)要求および／または上位のレイヤのピアによって特定されて前記上位のレイヤのパケット又はデータユニットが下位のレイヤに埋め込まれる通信特性のような通信品質要求に従って下位のレイヤにおけるパケット通信方法に適用される。
【００８４】
以下の記載においては、Ｌ３という用語は、たとえばＩＰｖ４やＩＰｖ６のようなネットワークレイヤプロトコルを指すものとして使用する。図３を参照。Ｌ３プロトコルによるデータユニット(ＰＤＵ)は、パケットと呼ばれ、ＰＤＵヘッダはパケットヘッダと呼ばれる。Ｌ１／Ｌ２という用語は、たとえば、特定のネットワークの物理および／またはリンクのレイヤのようなＬ３レイヤ下位の１つ又は２つ以上のプロトコルを示す。ベアラという用語は、Ｌ１／Ｌ２の全て固定された動作モードが固定されたＱｏＳ（クオリティオブサービス)セッティングであって、全てのＬ１／Ｌ２動作モードが中間に設けられたＬ１／Ｌ２（たとえば無線)の時刻毎の条件に依存して動的に適用されるものを意味する。ピアという用語はプロセスに関連して使用されたときは、特定のレイヤにおいて共通のプロトコルで通信を行うプロセスを意味する。一例として、ＷＷＷクライアントとアプリケーションレイアでＨＴＴＰプロトコルで通信を行っているサーバ、トランスポートレイア上のＴＣＰ送信機と受信機、があり図６を参照されたい。以下の文脈においては、ピアという用語は常にＬ３に直接又は間接的に基づくプロトコルで通信するピアを意味する。フローという用語は、ピアからピアへのＬ３パケットに基づく（パケット切り替え)通信であって、ソースアドレス、ソースポート、あて先アドレス−あて先ポートおよびプロトコルＩＤで識別されるものを意味する。換言すれば、フローは特定のＱoＳ要求を有すると考えられている。ＱｏＳ要求は時間の経過と共に変化することがある。
【００８５】
ピア（たとえばレガシーＷＷＷブラウザ)がフローのためにＱｏＳ要求を選択したといった場合は、これは同時にピアのために別のプロセスがそうさせることを含むことに留意する必要がある。
【００８６】
図１０は、ＩＰパケットに適合した移動電話に好適にリンクした（図１０にはいわゆるブルートゥースリンクが示されている)移動ＩＰ−ホストを示す。電話は無線アクセスネットワークを通じて無線のリンクを確立することができ、ＧＳＭ、ＧＰＲＳやＷ−ＣＤＭＡのようなどのような通信標準を使用することもできる。無線アクセスネットワークは、２つだけを図１０に示したが非常に多くのホストが接続されているインターネットに接続されている。
【００８７】
図の下の部分には通信状況が示されている。ピアＡ．１とＢ．１は移動局の例として示されており、ピアＡ．２とＢ．２はそれぞれ対応する相手方である。これらのピアはＱｏＳ要求および／または通信特性、一般的には制御情報としての品質要求をＬ３レイヤに通過させる。ピアはＬ３ピアかＬ３よりも上位のレイヤのプロトコルである。これは、Ｌ３ヘッダの所定のフィールドを品質要求に関連するものとして特定して、Ｌ３レイヤが、ピアがそのＱｏＳ要求および／または優先度をフロー毎又はパケット毎のレベルとして使用されるようにすることで行われる。
【００８８】
Ｌ３パケットの判別は、Ｌ１／Ｌ２のそれぞれの側の制御装置又は制御プロセス１１によって行われ、制御装置等は判別結果に従ってアダプタ又はアダプタプロセス１２を制御する。制御プロセス１１は、パケット毎のＱｏＳ要求および／または特性を読んで、対応するＬ１／Ｌ２動作モードおよび／またはネットワークの特性にマップする。適用プロセス１２はＬ１／Ｌ２の動作モードをパケット毎に適合させることができ、この決定を少なくとも一部は制御装置から提供された情報に基づいて行う。典型的な場合には、Ｌ１／Ｌ２動作モードの適用はＬ１／Ｌ２の下に存在する媒体の測定状況に基づいて行われる。
【００８９】
結果的に、本発明は動的に適応する、パケット毎に対応可能で、フロー／パケットのＱｏＳ要求と／または特性にアクセス可能な制御プロセスを有し、これらをそれぞれ提供プロセスおよび／またはＬ１／Ｌ２スケジューラを制御するために使用することができるＬ１／Ｌ２を有することになる。
【００９０】
例として、Ｌ１／Ｌ２のＴＣＰへの最適適用は、Ｉ−モードまたはそれ以外の通信スキーム、例えばスループットを最も高くするように最適化するにはＦＥＣ、においてＡＲＱ−に基づく誤り回復を使用する。（ＴＣＰフローであることを示す)プロトコルＩＤフィールドを読み取ることで制御装置は、例えば移動端末ＴＣＰのフローであるというような妥当な判断をすることができる。実時間ＩＰ上の音声通信フロー（セッションの開始プロトコルを有しない無線放送)についての最適適用は、ＡＲＱに基づく誤り回復（ＵＩモード)もそれ以外の通信スキームも有さない、つまり、ＦＥＣはソース送信率と残存誤りが最も小さくなるように最適化される。パケットヘッダのＤＳフィールドを読み取ることで、制御装置は、移動端末実時間ＩＰ上の音声フローに最適な判断をすることができる。
【００９１】
上述の実施例は既知のＬ１／Ｌ２プロトコルの実行が有する問題を解決することができる。現在のネットワーク（無線ネットワーク)におけるＬ１／Ｌ２は、それぞれが異なるＱｏＳ要求をもつ可能性がある別のフローを同時に送信しなければならない。しかし、現在のネットワーク上のＬ１／Ｌ２はそれぞれのフローが有するＱｏＳ要求を完全に満足させるレベルにまで降りることはできず、またフローのそれぞれのパケットが有するＱｏＳ要求を満足させるようにさらに一段下の層まで降りることもできない。後者は、ＱｏＳ要求が時間と共に変化して同一のフローのパケットのＱｏＳが異なる場合に必要になる。代わりに、現在のネットワークは最大限１つ以上のベアラを同時にサポートすることができる。しかし、フローの方法はこのベアラにマップされておりこれらのフローのＱｏＳ要求に直接関連付けられているわけではなく、パケット毎のネットワークオペレータチャージ特性のような基準に基づいている（ＧＰＲＳ通信システムで行われているように)。その結果問題になるのは、フロー／パケットのいくつかについてはＱｏＳ要求が満たされないか、いくつかのフロー／パケットについてはＱｏＳ要求が満たされはするが最適な方法では満たされない（ＴＣＰウィンドウフローのために選択されたＦＥＣスキームが、最適なＦＥＣスキームが提供する下位ビットレートに比較して強すぎる)というものであるか、フロー／パケットのＱｏＳ要求が過剰に満たされてネットワーク資源が無駄になるというものである。
【００９２】
Ｌ１／Ｌ２のフローのＱｏＳ要求に対する適用は、優先権に基づくトラヒックの計画概念とは独立である。例えば、実時間音声ストリームは、最大努力又はある種の予測的ＱｏＳトラヒッククラスとされているか否かとは無関係に特定のＱｏＳ要求をもつことができる。
【００９３】
この実施例は、Ｌ１／Ｌ２をそれぞれのフロー又はパケット毎のＱｏＳに対して動的に適合させることによってこの問題を解決する。本方法は以下に示した機能とそれらを実現する内部構造を有する：
−機能１：ここのフロー／パケットのＱｏＳ要求が排他的に特定されて、当該スキームをサポートするいずれのネットワークにおいてもセマンテックが同じになるような標準スキーム；
−機能２：Ｌ１／Ｌ２を制御プロセスから供給された動作モードに従って適応させる適応プロセス。動作モードはローカルなつまり、当該Ｌ１／Ｌ２のネットワークに固有のＱｏＳに対してのみ意味を有する形で、明示的にあるいは暗示的に提供されても良い。適応プロセスは、制御プロセスから提供された動作モードとＬ１／Ｌ２の下層に位置する当該媒体（無線)の条件に関する測定情報を組み合わせて最終的に動作モードを決定することができる。これはしかし実行に関する詳細に過ぎない。
−機能３：制御チャネルにアクセスを有して、フロー／パケット毎のＱｏＳ要求が与えられたときにフロー／パケット毎に適合プロセスを制御することができる制御プロセス；および、
−機能４：フロー／パケット毎のＱｏＳ要求が制御プロセスにとって利用できるようにする制御チャネル。
【００９４】
適応と制御プロセスはそれぞれ分散プロセスである可能性があり、Ｌ１／Ｌ２通信スキーム毎に１プロセスか、全てのＬ１／Ｌ２通信スキーム全てに対する単一の適応／制御プロセスである。これもまた実行に関する詳細に過ぎない。上述の機能は、パケット毎に又は少なくともパケットシーケンスに対するものであることが必要である。つまり、ＦＥＣを一つのパケットから別のものに対して又は少なくとも１つのパケットシーケンスから別のパケットシーケンスに対して代える事は可能である。
【００９５】
ＲｆＣ２４７５の現状から知られていることに関しては、ＲｆＣはＬ１／Ｌ２を動的に適応させることをいささかも示唆するものではないことに留意されたい。先行技術からはＬ１／Ｌ２をここのパケット／フローのＱｏＳに対して適応させることはまったく知られておらず（機能２)、機能を有する制御プロセスを用いることは知られていない。
【００９６】
従来技術に属するネットワークの例としてＧＳＭ−ＣＳＤまたはＧＰＲＳ通信システムを使用して、いずれのネットワークもフロー／パケット適応をサポートする機能を有していないことをいろいろなシナリオによって示すことができる。
【００９７】
例えば、図１０にし示した、ピアＡ．１、Ｂ．１、Ａ．２およびＢ．２を有する構成（本発明の特徴は有していないとする）を考えると、ＧＳＭ−ＣＳＤとＧＰＲＳのＬ１／Ｌ２に物理的には（つまり、Ａ．１とＢ．１)近い従来型のネットワークは、当該ピアにおいて明示的に知られたＱｏＳにしたがってＬ１／Ｌ２を適応させる直接的制御チャネル（あるいはそのために動くプロセス)を有する。例えば、ピアＡ．１とＢ．１はＡＴコマンド解釈装置に対してアクセスすることができ、それを通じて信頼性のあるリンクレイヤプロトコル(ＲＬＰ)を動かすか否かを決定することができる。しかし、一方、Ａ．２とＢ．２はそれらが始まったときのＴＣＰフローに対するＬ１／Ｌ２と異なるＬ１／Ｌ２に対して適応することはできない。ピアＡ．２とＢ．２に関しては適応を行わせることのできる制御プロセス(機能３）も存在しない。
【００９８】
ＧＳＭ−ＣＳＤは異なるＱｏＳ要求を有する複数のフローを同時に送信しなければならないにもかかわらず、回路の起動コールにおいては固定されたモード（ＦＥＣスキームとＩモード誤り回復)で動作することができるだけである。
【００９９】
本発明を具体的な実施例に基づいて記載したが、実施例は説明の明確さと完全な説明のために記載したに過ぎず発明は添付のクレームによって解釈されるものなので、実施例の記載によって日本発明がこれらの実施例に限定されるものと解釈してはならない。請求の範囲に記載された符号は、請求項の理解を助けるためにつけたもので、請求項の範囲をこれらに限定する意味のものではない。
【図面の簡単な説明】
【図１】 本発明に基づく通信装置を示す概念図である。
【図２】 本発明に基づく方法の実施例を示すフローチャートである。
【図３】 ＴＣＰ／ＩＰを例にとってプロトコルの階層構造を示した概念図である。
【図４】 図３に示したレイヤの中をパケットが流れる状態を示した概念図である。
【図５】 図３と図４の次のプロトコルレイヤにおけるカプセル化の概念を示した概念図である。
【図６】 回路切り替えＧＳＭリンクを介して２つのＩＰホストの間の接続とこれに対応するプロトコルの階層構造を例示した概念図である。
【図７】 ＨＤＬＣフレームの基本構造を示すものである。
【図８】 本発明に基づく好ましい実施例のブロック図である。
【図９】 本発明に基づく好ましい方法の実施例を示すフローチャートである。
【図１０】 本発明の別の好ましい実施例を説明する図である。

Claims (28)

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. 前記通信装置は、前記リンクを通じて前記第１の構造を有するデータパケットを受信することを特徴とする請求項２６または２７に記載の方法。

Images