(57)【特許請求の範囲】
【請求項１】
対向するピアとマルチリンクポイントツーポイントプロトコル（ＰＰＰ）リンクをネゴシエートするステップを含むパケットエンドポイントにおいて使用するための方法において、
前記ネゴシエートするステップは、前記対向するピアにメッセージを送信するステップをさらに含み、前記メッセージは、特定のＰＰＰリンクにおける幾つかのクラスのアイデンティフィケーションおよび特定のＰＰＰリンクにおけるクラスの各タイプを含む
ことを特徴とする方法。
【請求項２】
前記メッセージは、特定のＰＰＰリンクにおけるクラスの数を表すフィールドを含む
ことを特徴とする請求項１記載の方法。
【請求項３】
前記メッセージは、特定のＰＰＰリンクにおける各クラスのタイプを表すフィールドを含む
ことを特徴とする請求項１記載の方法。
【請求項４】
各クラスフィールドのタイプは、幾つかのビットを含み、各ビット位置の値は、特定のクラスが特定のＰＰＰリンク上にあるかどうかを表すことを特徴とする請求項３記載の方法。
【請求項５】
前記メッセージは、「非共有ＱｏＳ」オプションメッセージである
ことを特徴とする請求項１記載の方法。
【請求項６】
前記ネゴシエートするステップは、第２のメッセージを前記対向するピアに送信するステップをさらに含み、前記第２のメッセージは、異なるサービスコードポイントを特定のＰＰＰクラスにマップする情報を含む
ことを特徴とする請求項１記載の方法。
【請求項７】
前記第２のメッセージは、特定のＰＰＰクラスを同定するためのクラス番号フィールドと、その値が特定のＰＰＰクラスにマップされる異なるコードポイント値の数を表す少なくとも１つのフィールドを含む
ことを特徴とする請求項６記載の方法。
【請求項８】
前記第２のメッセージが、特定のＰＰＰクラスを同定するためのクラス番号フィールド、特定のＰＰＰクラスにマップされる異なるコードポイント値の数を同定するためのコードポイントフィールド、およびコードポイントフィールドの値に等しい数の幾つかのフィールドを含み、前記幾つかのフィールドの各々は、特定の差分のコードポイント値を同定する
ことを特徴とする請求項６記載の方法。
【請求項９】
前記メッセージは、「ＱｏＳエンハンスドマルチリンクヘッダフォーマット」オプションメッセージである
ことを特徴とする請求項６記載の方法。
【請求項１０】
前記ネゴシエートするステップは、第２のメッセージを前記対向するピアに送信するステップをさらに含み、前記第２のメッセージは、特定のＰＰＰクラスを使用することになるセッションの数を同定する情報を含む
ことを特徴とする請求項１記載の方法。
【請求項１１】
前記第２のメッセージは、前記特定のＰＰＰクラスを同定するためのクラス番号フィールド、およびその値が特定のＰＰＰクラスを使用するセッションの数を表す少なくとも１つのフィールドを含む
ことを特徴とする請求項１０記載の方法。
【請求項１２】
前記第２のメッセージは、特定のＰＰＰクラスを同定するためのクラス番号フィールド、その値が特定のＰＰＰクラスを使用するセッションの数を同定する幾つかのセッションフィールド、およびセッションフィールドの数の値に等しい数の幾つかのフィールドを含み、前記幾つかのセッションフィールドの各々は、そのセッションの記述を提供する
ことを特徴とする請求項１０記載の方法。
【請求項１３】
前記メッセージは、「ＱｏＳエンハンスドマルチリンクヘッダフォーマット」オプションメッセージである
ことを特徴とする請求項１０記載の方法。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は、通信に係り、特に、パケット通信システムに関する。
【０００２】
【従来の技術】
ＣＤＭＡ（キャリア分割多元接続）パケットデータサービスは、ネットワークに基づくインタネットプロトコル（ＩＰ）により移動体ユーザにワイヤレスデータサービスを提供する１つの方法である。例えば、Ｔｏｍ  Ｈｉｌｌｅｒによる“ＷｉｒｅｌｅｓｓＩＰ  Ｎｅｔｗｏｒｋ  Ａｒｃｈｉｔｅｃｔｕｒｅ  ｂａｓｅｄ  ｏｎ  ＩＥＴＦ  Ｐｒｏｔｏｃｏｌｓ”，  ＴＲ４５．６−３Ｇ／９９．０５．１７．０６  を参照のこと。ＴＲ４５．６において、ポイントツーポイントプロトコル（ＰＰＰ）は、移動体端末、または移動体ノード（ＭＮ）とパケットデータサービングノード（ＰＤＳＮ）との間のリンクレイヤとして使用される。
【０００３】
サービス品質（ＱｏＳ）機能を提供するようにＰＰＰを強化することが提案されてきた。１つの提案は、「リアルタイムフレーミング」である。例えば、Ｃ．  Ｂｏｒｍａｎｎによる“ＰＰＰ  ｉｎ  ａ  ｒｅａｌ−ｔｉｍｅ  ｏｒｉｅｎｔｅｄ  ＨＤＬＣ−ｌｉｋｅ  ｆｒａｍｉｎｇ”，  ｗｏｒｋ  ｉｎ  ｐｒｏｇｒｅｓｓ，  （ｄｒａｆｔ−ｉｅｔｆ−ｉｓｓｌｌ−ｉｓｓｌｏｗ−ｒｔｆ−０５．ｔｘｔ），  Ａｐｒｉｌ  １９９９  を参照のこと。別のアプローチは、「マルチクラスマルチリンクＰＰＰ」である。例えば、Ｃ．  Ｂｏｒｍａｎｎ  による“Ｔｈｅ  Ｍｕｌｔｉｃｌａｓｓ  Ｅｘｔｅｎｓｉｏｎ  ｔｏ  Ｍｕｌｔｉｌｉｎｋ  ＰＰＰ”，  ｗｏｒｋ  ｉｎ  ｐｒｏｇｒｅｓｓ，  （ｄｒａｆｔ−ｉｅｔｆ−ｉｓｓｌｌ−ｉｓｓｌｏｗ−ｍｃｍｌ−０６．ｔｘｔ），  Ｊｕｎｅ  １９９９  を参照のこと。
【０００４】
【発明が解決しようとする課題】
不都合なことに、これらの修正の両方は、ワイヤレスアクセスネットワークに適さない。例えば、ＰＰＰピア（ｐｅｅｒ）はベアラトラヒックが受信中のインタフェースに現れるときにのみ異なるクラスのサービスを感知するので、リアルタイムフレーミングは十分でない。しかし、ワイヤレスアクセスネットワークに対して、この情報は、ベアラトラヒックが現れる前に、どのタイプのワイヤレスリンクをアクティブにするかを決定するために必要である。マルチクラスマルチリンクＰＰＰに関して、このアプローチは、複数のリンクにおけるトランスポートのための各パケットを壊す。また、マルチクラスマルチリンクＰＰＰは、マルチリンクＰＰＰセッションのためのクラスの最大数を特定するが、クラス定義を特定しない。
【０００５】
【課題を解決するための手段】
マルチリンクＰＰＰは、ワイヤレス環境においてより柔軟なサービス品質（ＱｏＳ）サポートを提供するように強化される。特に、本発明により、マルチリンクＰＰＰは、パケットインタフェースまたはパケットエンドポイント（ｐａｃｋｅｔ  ｅｎｄｐｏｉｎｔ）が対向するＰＰＰピア（ｏｐｐｏｓｉｔｅ  ＰＰＰ  ｐｅｅｒ）にメッセージを送信することができるように強化される。ここで、このメッセージは、特定のＰＰＰリンクにおけるクラスの数およびタイプを同定する。
【０００６】
本発明の一実施形態において、マルチリンクＰＰＰは、「非共有ＱｏＳネゴシエーション“ｎｏｎ−Ｓｈａｒｉｎｇ  ＱｏＳ  Ｎｅｇｏｔｉａｔｉｏｎ”」オプションメッセージ、およびＩＰ制御プロトコル（ＩＰＣＰ）フェーズにおける「ＱｏＳ強化マルチリンクヘッダフォーマット“ＱｏＳ−Ｅｎｈａｎｃｅｄ  Ｍｕｌｔｉｌｉｎｋ  Ｈｅａｄｅｒ  Ｆｏｒｍａｔ”」オプションメッセージをサポートするように修正される。
【０００７】
【発明の実施の形態】
本発明のコンセプトを説明する前に、ＩＰベースドワイヤレスデータサービスの概略を説明する。以下の説明は、ネットワークエンティティに対して第３世代（３Ｇ）ワイヤレス技術を使用する。例えば、Ｔｏｍ  Ｈｉｌｌｅｒ等による“３Ｇ  Ｗｉｒｅｌｅｓｓ  Ｄａｔａ  Ｐｒｏｖｉｄｅｒ  Ａｒｃｈｉｔｅｃｔｕｒｅ  Ｕｓｉｎｇ  Ｍｏｂｉｌｅ  ＩＰ  ａｎｄ  ＡＡＡ”を参照のこと。
【０００８】
図１は、ジェネリックワイドエリアワイヤレスデータネットワークレファレンスモデル（ｇｅｎｅｒｉｃ  ｗｉｄｅ  ａｒｅａ  ｗｉｒｅｌｅｓｓ  ｄａｔａ  ｎｅｔｗｏｒｋ  ｒｅｆｅｒｅｎｃｅ  ｍｏｄｅｌ）を示す。構成要素は周知であり、詳細に説明することはしない。例えば、移動体エンドポイントまたは端末装置は、移動体ノード（ＭＮ）１０５により表される。後者は、リンクレイヤメッセージにより、最も近い基地局、例えばＢＳ１１０に登録される。この例のために、ＢＳ１１０は、インタワーキングファンクションユニット（ＩＷＦ）１１５によりサービスされる「フォーリンエリア“ｆｏｒｅｉｇｎ  ａｒｅａ”」の一部であると仮定する。ＩＷＦ１１５は、この技術分野において知られているインターミディエットフォーリンエージェント（ＩＦＡ）と基本的に等価である。
【０００９】
ＩＷＡ１１５は、ビジティングパケットデータサービングノード（Ｖ−ＰＤＳＮ）１２０に結合されている。Ｖ−ＰＤＳＮ１２０は、この技術分野において知られているゲートウェイフォーリンエージェント／ダイナミックホームエージェント（ＧＦＡ／ＤＨＡ）と基本的に等価である。図１には示されていないが、フォーリンエリアは、互いに通信可能な他のＩＷＦを含む。同様に、ＭＮ１０５の図示しないユーザは、「ホームエリア“ｈｏｍｅ  ｅｒｅａ”」と関連づけられている。
【００１０】
後者は、ホームパケットデータサービングノード（Ｈ−ＤＳＮ）１３０およびホームエージェント（ＨＡ）１３５により表される。Ｈ−ＤＳＮ１３０は、ゲートウェイホームエージェントと基本的に等価である。周知のユーザ認証方法が、例えば認証・検定・課金（ＡＡＡ）サーバ１２５および１４０により使用されることと仮定されている。このコンテキストにおいて、ＢＳ１１０、ＩＷＦ１１５、Ｖ−ＰＤＳＮ１２０、Ｈ−ＰＤＳＮ１３０およびＨＡ１３５は、全て異なる形式のパケットサーバである。例えば、Ｖ−ＰＤＳＮ１２０とＨ−ＰＤＳＮ１３０との間の通信は、インタネットプロトコル（ＩＰ）ベースドネットワーク１４０による。
【００１１】
上述したように、ワイヤレスデータサービスは、図１のＩＰベースドネットワークによりＭＮ１０５に関連づけられたユーザに提供される。ＭＮ１０５は、フォーリンエリアを訪問しているので、そのような移動体ＩＰサービスのサポートは、典型的には、アドレッシングおよびルーティング目的のためにホームＩＰネットワークからフォーリンＩＰネットワークへメッセージがトンネル化（“ｔｕｎｎｅｌｅｄ”）されることを必要とする。このコンテキストにおいて、ＢＳ１１０とＩＷＦ１１５との間の通信は、リンクレイヤにおいて行われると仮定される。
【００１２】
そのようなＩＰサービスを提供するための提案されているＴＲ４５．６アーキテクチャを使用する例示的なプロトコルスタックが、図２に示されている。例えば、Ｔｏｍ  Ｈｉｌｌｅｒによる“Ｗｉｒｅｌｅｓｓ  ＩＰ  Ｎｅｔｗｏｒｋ  Ａｒｃｈｉｔｅｃｔｕｒｅ  ｂａｓｅｄ  ｏｎ  ＩＥＴＦ  Ｐｒｏｔｏｃｏｌｓ”，  ＴＲ４５．６Ｇ／９９．０５．１７．０６  を参照こと。図２において、ＩＰは、インタネットプロトコルレイヤを示し、ＰＰＰは、ポイントツーポイントプロトコルレイヤを示し、Ｌ／Ｍは、論理リンク制御／媒体アクセス制御レイヤを示し、ＷＬは、ワイヤレスリンクレイヤ１を示し、Ｌ１はいずれかのリンクレイヤ１トランスポート（物理レイヤ）を示し、ＢＨＩＰＬ２は、リンクレイヤ２におけるバックホール（ｂａｃｋ  ｈａｕｌ）ＩＰトンネルを示し、ＴＩＰＬ２は、リンクレイヤ２におけるコアＩＰトンネルを示す。
【００１３】
図２から分かるように、ＰＰＰは、ＭＮとＶ−ＰＤＳＮとの間のリンクレイヤとして使用される。ＭＮは、リンクレイヤメッセージにより最も近いＢＳに登録される。そして、ＰＰＰセッションは、ＭＮとＶ−ＰＤＳＮとの間でアクティブ化される。ＰＰＰセッションセットアップ手順により、Ｖ−ＰＤＳＮは、ＩＰアドレスをＭＮにダイナミックに割り当てることができる。また、いくつかのレイヤ３トンネルセットアップメッセージが、コアＩＰトンネル（ＴＩＰ）がＨ−ＰＤＳＮからＶ−ＰＤＳＮへ存在するように、Ｖ−ＰＤＳＮとＨ−ＰＤＳＮとの間で交換される。
【００１４】
このコアＩＰトンネルは、ＭＮ行きであるパケットを渡すために使用される。ＭＮ行きであるパケットは、Ｈ−ＰＤＳＮにより横取りされて、コアＩＰトンネルによりＶ−ＰＤＳＮに渡される。Ｖ−ＰＤＳＮは、それらを、バックホールＩＰトンネルにより適切なＩＷＦに渡す。これは、Ｖ−ＰＤＳＮとＩＷＦとの間のネットワークがＩＰネットワークであると仮定している。
【００１５】
このバックホールＩＰトンネルは、ＰＰＰフレームを運ぶ。トンネル確立プロトコルは、この技術分野において知られている。例えば、Ｐ．  Ｃａｌｈｏｕｎ，  Ｇ．  Ｍｏｎｔｅｎｅｇｒｏ，  Ｃ．  Ｐｅｒｋｉｎｓ  による“Ｔｕｎｎｅｌ  Ｅｓｔａｂｌｉｓｈｍｅｎｔ  Ｐｒｏｔｏｃｏｌ，”ｄｒａｆｔ−ｉｅｔｆ−ｍｏｂｉｌｅｉｐ−ｃａｌｈｏｕｎ−ｔｅｐ−０１．ｔｘｔ，  Ｍａｒｃｈ  １９９８を参照こと。そして、ＩＷＦは、パケットを適切な基地局に渡し、基地局は、それらをＭＮに渡す。ＭＮからのパケットは、同様に、基地局からＩＷＦへ渡され、ＩＷＦは、それらをＶ−ＰＤＳＮに渡す。必要である場合、リバースコアＩＰトンネルが、ホームネットワーク内のいずれかのホストへＭＮからトラヒックを渡すことに使用するために、Ｖ−ＰＤＳＮからＨ−ＰＤＳＮへセットアップされる。
【００１６】
逆方向トンネルが存在しない場合、正規のＩＰルーティングによりパケットがＨ−ＰＤＳＮに渡される。これは、パケットがＨ−ＰＤＳＮ内のホスト行きである場合のみである。対応するホストがＨ−ＰＤＳＮ内にない場合、Ｖ−ＰＤＳＮをダイナミックホームエージェントとして単に使用することができる。このモードにおいて、いずれかのワイヤードホストからＭＮへのパケットは、Ｖ−ＰＤＳＮにより横取りされて、ＭＮに経路選択される。同様に、ＭＮからいずれかのワイヤードホストへのいずれのパケットも、Ｖ−ＰＤＳＮにより経路選択される。
【００１７】
本発明のコンセプトは、マルチリンクＰＰＰ（例えば、Ｋ．  Ｓｌｏｗｅｒ  等による“Ｔｈｅ  ＰＰＰ  Ｍｕｌｔｉｌｉｎｋ  Ｐｒｏｔｏｃｏｌ  （ＭＰ）”，  ＲＦＣ１９９０，  Ａｕｇｕｓｔ，  １９９６を参照のこと）を修正する。本発明のコンセプトに関連するマルチリンクＰＰＰの部分のみ、即ちＩＰ制御プロトコル（ＩＰＣＰ）フェーズの関連部分のみがここに開示される。現行のＩＰプロトコルに精通していることが仮定されている。また、パケットエンドポイントは、通常のプログラミング技法を使用して以下に説明する方法を実行するように適切にプログラムされていることが想定され、ここでは説明しない。
【００１８】
新しい「非共有ＱｏＳ“Ｎｏｎ−Ｓｈａｒｉｎｇ  ＱｏＳ”」オプションメッセージに対する例示的なフォーマットが図３に示されている。フィールドは、左から右に送信される。図３に示されているように、本発明によれば、ＩＰＣＰのタイプフィールド値は、２８に設定される。これは、非共有ＱｏＳオプションメッセージを表す。長さフィールドは、５（非共有ＱｏＳオプションメッセージの長さ）に設定される。ＩＰＣＰにおいて、以下のコード値が使用され得る。
コード＝２：複数のクラスを有する長いシーケンス番号パケットフォーマット、および
コード＝６：複数のクラスを有する短いシーケンス番号パケットフォーマット。
【００１９】
ＮｏＣｌｓフィールドは、この特定のリンク上のクラスの数を表す。例えば、８個のクラスが許容されている。ＱｏＳビットマップフィールドは、特定のクラス番号の存在／不存在を示すために使用される１バイトのビットマップ（ＱｏＳビットマップ）である。ＱｏＳビットマップフィールドは、８ビットの幅であるので、８個のＰＰＰＱｏＳクラスは十分であると仮定されていることに留意すべきである。ここで、最高の優先度クラスのゼロを有するクラス０−７である。代替的に、ＱｏＳビットマップフィールドは、８個よりも多いクラスをサポートするように拡張することができる。
【００２０】
例えば、１つのＰＰＰピアが、このリンク上の３個のクラス、即ちクラス３、クラス４およびクラス５がある別のＰＰＰピアに対して通信するために、ＮｏＣｌｓフィールドは、３の値に設定され、ＱｏＳビットマップフィールドは、“０００１１１００”に設定される。ここで、ビットゼロ、即ちｂ０  が最も左のビットである。最終的に、Ｒｓｖフィールドが、将来の使用のためにリザーブされる。
【００２１】
以上の結果として、図示しないＩＰＣＰネゴシエーションフェーズにおいて、ＰＰＰピアは、ＭＲＲＵおよびエンドポイントディスクリミネーターオプションと共に新たに定義された非共有ＱｏＳオプションメッセージを含むことができる。図４は、標準マルチリンクＰＰＰと共に非共有ＱｏＳオプションを使用することを示す。便宜的に、図４において、送信ピアがピアＡであり、受信ピアがピアＢであることが仮定されている。ネゴシエーションの観点からの送信および受信であり、例えば、ピアＡが非共有ＱｏＳオプションを要求する。
【００２２】
上記したように、非共有ＱｏＳオプションメッセージは、ＰＰＰピアが、特定のリンク上で実行されるべきクラスの数を特定することを可能にする。例えば、ＰＰＰピアは、非共有ＱｏＳオプションメッセージを使用して、まず１つのリンク（リンク１）をアクティブ化し、リンク１上に２つのクラス、即ちクラス３および４があることを特定すると仮定される。即ち、ＮｏＣｌｓフィールドは、２に設定され、ＱｏＳビットマップフィールドは、“０００１１０００”に設定される。
【００２３】
そして、その後、ＰＰＰピアは、非共有ＱｏＳオプションをイネーブルすることなしに、さらに２つのリンクをアクティブ化する。即ち、これらの追加的なリンクに対するネゴシエーションフェーズに、非共有ＱｏＳオプションメッセージは含まれない。これは、クラス番号３および４を有する全てのＰＰＰフレームが、リンク１上を運ばれ、残りのＰＰＰフレームが、セグメント化され、またはマルチリンクＰＰＰにおいて行われるように断片化され、非共有ＱｏＳオプションとネゴシエートされなかった２つの残りのリンク（リンク２および３）上を運ばれる。ベアラデータ（ＰＰＰフレーム）は、複数のクラスを有する短いまたは長いシーケンス番号断片フォーマットのいずれかを使用することができる。
【００２４】
非共有ＱｏＳオプションがネゴシエートされる場合、オプションは、ＰＰＰピア間で両方向のトラヒックに対して適応されることが仮定されている。上記の例を使用して、クラス番号３および４を有するＰＰＰフレームは、いずれの方向にもリンク１上を運ばれることになる。これは、リンク１に対する両方向の矢印により図４に示されている。
【００２５】
図５および６において、本発明により、新しい「ＱｏＳエンハンスドマルチリンクヘッダフォーマット（ＱｏＳ−ＥＭＨＦ）」オプションメッセージに対する例示的なフォーマットが示されている。フィールドが左から右に送信される。ＱｏＳ−ＥＭＨＦオプションメッセージは、区別されたサービス（レイヤ３）をＰＰＰＱｏＳクラスにマップすることをサポートする。
【００２６】
図５および６から分かるように、ＩＰＣＰのタイプフィールド値は、２９に設定され、これは、ＱｏＳ−ＥＭＨＦオプションメッセージを表す。長さフィールド値は、この特定のＱｏＳ−ＥＭＨＦオプションメッセージの長さに設定される。Ｔｙｐフィールド値は、２つのタイプのＱｏＳ−ＥＭＨＦオプションメッセージを区別する。Ｔｙｐフィールドは、４個の異なるタイプのＱｏＳ−ＥＭＨＦオプションメッセージをサポートするが、ここでは、２つのみが定義されている。
【００２７】
一方のＴｙｐフィールド値が、図５に示されている。このタイプのＱｏＳ−ＥＭＨＦオプションメッセージは、以下のフィールドを含む。ＮｏＣＰ，ＣｌｓＮｏ，および可変ナンバーディファレンシャルサービス（ＤＳ）コードポイントフィールド（ＤＳＣＰ）である。ＮｏＣＰフィールドの値は、ＣｌｓＮｏフィールドの値により特定されるクラス番号にマップされることになるＤＳＣＰコードポイントの数を表す。ＤＳＣＰの定義のために、Ｄｅｆｉｎｉｔｉｏｎ  ｏｆ  ｔｈｅ  ｄｉｆｆｅｒｅｎｔｉａｔｅｄ  Ｓｅｒｖｉｃｅｓ  Ｆｉｅｌｄ  （ＤＳ  Ｆｉｅｌｄ）  ｉｎ  ｔｈｅ  ＩＰｖ４  ａｎｄ  ＩＰｖ６  Ｈｅａｄｅｒｓ  （ＲＦＣ２４７４），  Ｄｅｃ．，  １９９８  を参照のこと。
【００２８】
タイプ１ＱｏＳ−ＥＭＨＦオプションメッセージは、ＰＰＰピアが、ディファレンシャルサービスコードポイントをＰＰＰＱｏＳクラスにマップすることを可能にする。これは、ＰＰＰピアが、各ＰＰＰフレームを適切にマークすることを可能にする。例えば、２つのＰＰＰピアは、マークされた複数のＤＳＣＰ、即ち、ＤＳＣＰコード１、ＤＳＣＰコード２、ＤＳＣＰコード３およびＤＳＣＰコード４を有するＩＰパケットを運ぶものと仮定する。ＤＳＣＰコード１およびＤＳＣＰコード２をＰＰＰＱｏＳクラス１にマップし、かつＤＳＣＰコード３およびＤＳＣＰコード４をＰＰＰＱｏＳクラス２にマップすることが望まれていると仮定する。
【００２９】
図５の例示されたＱｏＳ−ＥＭＨＦオプションメッセージにおいて、ＰＰＰピアは、ＤＳＣＰコード１およびＤＳＣＰコード２に関して、このマッピングを互いに通知する。ここで、ＣｌｓＮｏはクラス１を表す値に等しい。図示されていない同様のメッセージも、別のリンクに対してＤＳＣＰコード３およびＤＳＣＰコード４をクラス２に割り当てることに関して送信される。このオプションなしに、両方のＰＰＰピアが異なるマッピングを実行することができる。異なるベンダーからの装置は、同じマッピングを実行することができず、したがって、ＰＰＰ／ＭＰリンクにおけるＱｏＳ保証を提供することがより困難である。
【００３０】
このオプションがピア間でネゴシエートされる場合、アクセプティングピアは、ＱｏＳ−ＥＭＨＦオプションメッセージ中のＣｌｓＮｏフィールドの値により特定されたクラス番号を有するＰＰＰフレームとして、各ＤＳＣＰ値でマークされた全てのＩＰパケットを送信しなければならない。（例えば、図５において、アクセプティングピアは、クラス番号１を有するＤＳＣＰコード１およびＤＳＣＰコード２でマークされた全てのＩＰパケットを送信しなければならない。受信ＰＰＰピアがこのマッピングを受け入れることができない場合、受信ＰＰＰピアは、オプションをＣｏｎｆｉｇｕｒｅ−ＮａｋまたはＣｏｎｆｉｇｕｒｅ−Ｒｅｊｅｃｔして送信ＰＰＰピアに戻す。
【００３１】
２のＴｙｐフィールド値が図６に示されている。このタイプ２ＱｏＳ−ＥＭＨＦオプションメッセージは、以下のフィールドを含む。即ち、ＮＳｅＳ、ＣｌｓＮｏ、セッションＬｅｎ、および可変ナンバーセッション記述フィールドである。ＮＳｅＳフィールドの値は、このＰＰＰクラス番号を使用するセッションの数を表し、これは、ＣｌｓＮｏフィールドの値により特定される。セッションＬｅｎフィールドの値は、セッション記述の長さを定義する。ＩＰあて先である場合、４バイトであり、ＩＰあて先＋プロトコルに対して５バイト、ＩＰあて先＋プロトコル＋ポート番号に対して６バイト、ＩＰあて先＋プロトコル＋ポート番号＋ＤＳＣＰコードポイントに対して７バイトである。
【００３２】
プロトコルおよびポート番号のコンテキストにおいて、これらの用語はこの技術分野において知られている。例えば、図示しないプロトコルタイプは、ＴＣＰ（トランザクション制御プロトコル）またはＵＤＰ（ユーザデータグラムプロトコル）のいずれかを表す所定値であり、ポート番号に対しても同様である。図６の例示的なＱｏＳ−ＥＭＨＦオプションメッセージは、２のＮＳｅＳ値および４のセッションＬｅｎ値を表し、結果として、２つのセッション記述、およびそれぞれ長さ４を表す。
【００３３】
タイプ２ＱｏＳ−ＥＭＨＦオプションメッセージに対して、全てのセッションの記述長さは、同じでなければならない。ＱｏＳ−ＥＭＨＦタイプ２オプションがネゴシエートされる場合、アクセプティング即ち受信ピアは、特定のセッション記述を有する全てのＩＰパケットを、ＣｌｓＮｏフィールドにおいて特定されたクラス番号を有するＰＰＰフレームとして運ばなければならない。受信ＰＰＰピアがこのマッピングを受け入れることができない場合、ＩＰＣＰにおいて、このオプションをＣｏｎｆｉｇｕｒｅ−Ｎａｋ  または  Ｃｏｎｆｉｇｕｒｅ−Ｒｅｊｅｃｔ  することになる。特定のパケットエンドポイント構成は、それらが各マルチリンクＰＰＰユーザに提供する異なるクラスのサービスを適応させるための十分なバッファ空間を提供する。
【００３４】
代替的に、ＱｏＳ−ＥＭＨＦオプションメッセージは、図７に示されるようにフォーマットされる。このバージョンのＱｏＳ−ＥＭＨＦオプションメッセージは、ＱｏＳ−ＥＭＨＦタイプ１およびＱｏＳ−ＥＭＨＦタイプ２情報を結合させる。フィールドＣｌｓｎｏは、ＰＰＰクラス番号に対応し、フィールドＮｏＳＤは、このＰＰＰＱｏＳクラスに関連づけられたセッション記述子の数に対応する。オプションＴｙｐフィールドは、以下の値を有する。
【００３５】
オプションＴｙｐ＝１：セッション記述子は、ＤＳＣＰコードポイント（１バイト）、
オプションＴｙｐ＝２：セッション記述子は、ＩＰあて先アドレス（４バイト）、
オプションＴｙｐ＝３：ＩＰあて先アドレス＋ポート（５バイト）、
オプションＴｙｐ＝４：ＩＰあて先アドレス＋ポート＋プロトコルＩＤ（６バイト）、および
オプションＴｙｐ＝５：ＩＰあて先アドレス＋ポート＋プロトコルＩＤ＋ＤＳＣＰコードポイント（７バイト）。
【００３６】
他のオプションタイプ情報も追加することができる。図７において、ＰＰＰクラス１（ＣｌｓＮｏ＝１）は、ＤＳＣＰコードポイント（オプションタイプ＝１）であるセッション記述子を有し、３個のＤＳＣＰコードポイント（ＤＳＣＰ＃１，ＤＳＣＰ＃２，およびＤＳＣＰ＃３）をこのＰＰＰクラス番号にマップする。また、これは、ＩＰあて先アドレスであるセッション記述子を有するＰＰＰクラス２（ＣｌｓＮｏ＝２）でもあり、２個のＩＰあて先アドレスのためのパケットをこのＰＰＰクラス番号にマップする。
【００３７】
上記の結果として、本発明のコンセプトは、いくつかの所定のセッションからのパケットが１つの物理リンクに送られることおよび他のセッションからのパケットが別の物理リンクに送られることを可能にする現行のＰＰＰ内のＱｏＳメカニズムを提供する。また、これは、アドミッション制御、無線資源マネージメントおよびトラヒックエンジニアリング目的のために、いずれかの特定の時点においてアクティブ化される正確なクラス番号を提供する。最終的に、これは、１つまたは複数のＩＰセッションからのパケットを、リンクバンドル中のワイヤレスリンクの１つにマップする能力を提供する。換言すれば、パケットエンドポイントは、いずれか特定のリンクにおいてアクティブ化されることになる異なるクラスの正確なタイプを知っている。
【００３８】
図８において、本発明の原理によりマルチリンクＰＰＰネゴシエーションを実行することに使用するための代表的なパケットエンドポイントの概略ブロック図が示されている。パケットエンドポイント６０５は、ストアードプログラム制御ベースドプロセッサアーキテクチャであり、プロセッサ６５０、例えば上述した修正されたマルチリンクＰＰＰネゴシエーションにしたがって通信するためのプログラム命令およびデータを記憶するためのメモリ６６０、およびパス６６６で表されているような１つまたは２つ以上のパケット通信設備に結合するための通信インタフェースを含む。
【００３９】
【発明の効果】
以上述べたように、本発明によれば、マルチリンクＰＰＰを、ワイヤレス環境においてより柔軟なサービス品質（ＱｏＳ）サポートを提供するように強化することができる。
【図面の簡単な説明】
【図１】ワイドエリアワイヤレスデータネットワークの構成を示す図。
【図２】ＩＰサービスを移動体ユーザに提供するために図１のネットワークにおいて使用するための例示的なプロトコルスタックを示す図。
【図３】本発明の原理による新しい「非共有ＱｏＳ」オプションのための例示的なフォーマットを示す図。
【図４】本発明の原理による非共有ＱｏＳオプションを１つのＰＰＰリンクが使用する例示的なマルチリンクＰＰＰネゴシエーションを示す図。
【図５】本発明の原理による新しい「ＱｏＳエンハンスドマルチリンクヘッダフォーマット」オプションのための例示的なフォーマットを示す図。
【図６】本発明の原理による新しい「ＱｏＳエンハンスドマルチリンクヘッダフォーマット」オプションのための例示的なフォーマットを示す図。
【図７】本発明の原理による新しい「ＱｏＳエンハンスドマルチリンクヘッダフォーマット」オプションのための例示的なフォーマットを示す図。
【図８】本発明の原理によるマルチリンクＰＰＰネゴシエーションを実行することに使用するためのパケットエンドポイントを示す概略ブロック図。
【符号の説明】
１２５  フォーリンＡＡＡ
１４０  ＩＰ−ベースドネットワーク
６５０  プロセッサ
６６０  メモリ
６６５  通信インタフェース
【図１】
0003556885.tif 000002
【図２】
0003556885.tif 000003
【図３】
0003556885.tif 000004
【図４】
0003556885.tif 000005
【図５】
0003556885.tif 000006
【図６】
0003556885.tif 000007
【図７】
0003556885.tif 000008
【図８】
0003556885.tif 000009