JP2010104001A - 通信システムにおけるパケット・フロー処理 - Google Patents

Abstract

【課題】ＩＰコンポーネントを有する通信システムにおいて複数のサービスインスタンスをサポートするパケットフローマッピング処理方法及び装置を提供する。
【解決手段】リソース予約メッセージは、関連付けられたパケット・フローのフロー処理法を決定するために使用されるパケット・フロー・パラメータ情報を含む。パケット・フロー・マッピングは、関連付けられたパケット・フローのサービスの品質に基づく。他の実施形態では、ベアラ接続が確立され、フロー処理法に関係する情報に対してモニタされる。
【選択図】図５

Description

本発明は、通信システムにおけるパケット・フロー処理に係り、より具体的には、インターネット・プロトコル（Internet Protocol）（ＩＰ）コンポーネントを有する通信システムにおいて複数のサービス・インスタンスをサポートするパケット・フロー・マッピング及び処理法に関する。

［関連文献］
発明に関する本出願は、米国特許出願番号第１０／１７０，０５９、名称“通信システムにおけるパケット・フロー処理（PACKET FLOW PROCESSING IN A COMMUNICATION SYSTEM）”、２００２年６月１０日提出、に基づいて優先権を主張するものであり、この譲受人に譲渡され、これによりここに引用文献として特別に取り込まれている。

データ通信をサポートする通信システムは、インターネット・プロトコル（ＩＰ）コンポーネント又は構成部分（portion）を多くの場合に含み、そこでは、データは、ＩＰフォーマットで通信される。同様に、通信システムは、ＩＰシステムと通信することができる、又はＩＰノードとの通信に参加することができる。そのような通信に関して、データは、パケットで搬送される；パケットのシーケンス（sequence）は、“パケット・フロー”と呼ばれる。パケット・フローを処理するために、通信システムの（複数の）インフラストラクチャ・エレメントは、ある種の情報を必要とする。例えば、（複数の）インフラストラクチャ・エレメントは、ヘッダ圧縮及び／又はマッピング情報を必要とすることがあり、その結果、（複数の）インフラストラクチャ・エレメントは、複数のパケット・フローを適切なリンク−レイヤ接続に向けることができる。

それゆえ、この分野において、そのような情報を要求しているインフラストラクチャ・エレメントにパケット・フロー情報を提供するためのニーズがある。同様に、通信システムにおいてパケット・フローのマッピング及び処理法に関する効率的な方法に対するニーズがある。

図１は、通信システムである。 図２は、処理に関するコール・フロー（call flow）であり、そこではＰＤＳＮは、（複数の）ＲＳＶＰメッセージからのパケット・フローに対するフロー処理法及びマッピングを決定する。 図３は、処理に関するコール・フローであり、そこではＰＤＳＮは、セッション・イニシエーション・プロトコル（Session Initiation Protocol）（ＳＩＰ）メッセージを “スニフィング（sniffing）（感付くこと）”することからフロー処理法及びマッピングを決定する。 図４は、リソース予約プロトコルをサポートする通信システムを図示する。 図５は、パケット・フローを処理することに適応した移動局である。 図６は、種々の実施形態にしたがったパケット・フロー処理を図示する。 図７は、種々の実施形態にしたがったパケット・フロー処理を図示する。 図８は、種々の実施形態にしたがったパケット・フロー処理を図示する。 図９は、マルチ−チャネル・フロー処理プロトコル（Multi-Channel Flow Treatment Protocol）（ＭＣＦＴＰ）パケット・フォーマットである。

詳細な説明

用語“具体例の（exemplary）”は、“例、事例、又は実例として取り扱われること”を意味するようにここでは使用される。“具体例の”としてここで説明されたいずれかの実施形態が、他の実施形態に対して好ましい又は優位であるとして必ずしも解釈される必要はない。

図１は、データ通信に適応した通信システム１００である。通信システム１００は、基地局（Base Station）（ＢＳ）１０４と通信している移動局（Mobile Station）（ＭＳ）１０２を含む。ＢＳ１０４は、パケット・データ・サービス・ノード（Packet Data Service Node）（ＰＤＳＮ）１０６と、同様に、音声通信、等を処理するための他のコンポーネント（図示せず）とさらに通信している。ＰＤＳＮ１０６は、ＩＰ通信をサポートしているネットワークのような、データ・ネットワークと、ＭＳ１０２及びＢＳ１０４とに対するインターフェースとして働く。

ＭＳ１０２は、データ通信をサポートする、そこでは、複数のＡ１０接続及びサービス・オプション（Service Option）（ＳＯ）接続が図示される。ＳＯ接続は、パケット・データ・サービスのような、選択されたサービス・オプションの通信のために使用される。Ａ１０接続は、次に、ＰＤＳＮ１０６とＢＳ１０４との間でインターネット・プロトコル（ＩＰ）パケットを送るためのリンクを提供する。ＳＯ接続は、ＭＳ１０２とＢＳ１０４との間でＩＰパケットを送るためのリンクを提供する。ＳＯ接続（ＭＳ−ＢＳ）とＡ１０接続（ＢＳ−ＰＤＳＮ）との間に１対１マッピングがある。ＭＳ１０２が複数の同時接続をサポートするので、複数のＡ１０／ＳＯ接続の対が、図１に図示される。言い換えると、ＭＳ１０２は、並行して複数のパケット・フローを処理できる。各パケット・フローは、１つのＡ１０接続又はリンクに割り当てられる。Ａ１０リンクへのパケット・フローの割当ては、パケット・フロー“マッピング”と呼ばれ、そしてＰＤＳＮによって決定される。図１のシステム１００に適用可能である、そのようなマッピングに関する数多くの規準及びアルゴリズムがある。

上に論じたように、ＭＳ１０２とＢＳ１０４との間の各ＳＯ接続又はリンクは、ＢＳ１０４とＰＤＳＮ１０６との間の対応するＡ１０接続又はリンクを有する。対応は、ＢＳ１０４を通る破線によって図示される。ＳＯ／Ａ１０接続は、ＩＰを介した音声（Voice over IP）（ＶｏＩＰ）通信のような、双方向通信又は対話型通信に対して使用されることができる、又は、インターネットソースからの情報のストリーミングに関するような又はデータをダウンロードするための、一方向通信に対して使用されることができる。データ通信のタイプの数が増加するにつれ、ＳＯ／Ａ１０接続は、ますます多くのこれらの通信のために実装されることがある。複数のＳＯ接続（サービス・インスタンスとしても知られる）が、パケット・フローの異なるＱｏＳ要求をサポートするために必要であることに、注意する。例えば、ＭＳ１０２は、２つのアクティブなＳＯ接続を有することができる。第１のＳＯ接続は、送信待ち時間の犠牲を払って無線を介した信頼できる搬送を提供するための再送信メカニズムを有する、そしてそれゆえ、信頼できる送信を必要とするデータ搬送に使用される。第２のＳＯ接続は、再送信メカニズムを持たないことがあり、迅速な送信を必要とするデータ搬送のために使用される。

ＰＤＳＮ１０６は、認証、アカウンティング及び認可（Authentication Accounting and Authorization）（ＡＡＡ）１１２をさらに含む。ＡＡＡ１１２は、接続を認証すること及びキャリア又はサービス・プロバイダによる請求書、等に関するアカウンティングの経過を追うことを取り扱う。ＰＤＳＮ１０６は、対応するノード（Corresponding Node）（ＣＮ）１０８、同様に他のソース１１０からのパケット・フローを受信する。ＣＮ１０８は、インターネットにおけるノード、サービス・プロバイダ、端末、等であり得る。言い換えると、ＣＮ１０８は、情報のソース又は通信への参加者である。ＰＤＳＮ１０６は、複数のソースからの複数ｆのパケット・フローを受信することができ、そこでは、上記のパケット・フローは、ＭＳ１０２のような、複数の参加者に対して宛てられることに、注意する。各パケット・フローは、対応するＳＯ／Ａ１０接続にマッピングされ、そして参加者によって取り決められた複数のパラメータにしたがって処理される。

各パケット・フローのフロー・マッピング及び処理法は、複数のサービス・インスタンスが、ＭＳ１０２のような、所定のユーザに対して設定される場合に、特に重要である。ＭＳ１０２が複数のアクティブなサービス・インスタンスを有し、そしてＭＳ１０２が複数のヘッダ圧縮アルゴリズムを使用するのであれば、ＰＤＳＮ１０６は、各サービス・インスタンスに関係するパケット・フローを処理するための情報を望むであろう。情報は、各パケット・フローに対して使用された具体的なヘッダ圧縮アルゴリズム、及び各Ａ１０接続への各パケット・フローのマッピングを含むが、これらに限定されることはない。

以下に説明される実施形態は、ＲＳＶＰメッセージを介してフロー処理情報を提供する１つの方法であり、そのＲＳＶＰメッセージは、フロー処理法と呼ばれる新たなオブジェクトを含む。ＲＳＶＰメッセージは、インターネットにおける統合サービスのために設計されたリソース予約設定プロトコルであり、そして、Ｒ．ブランデン（Branden）らによるＲＦＣ２２０５、名称“リソース予約プロトコル（Resource ReSerVation Protocol）（ＲＳＶＰ）”に説明されている。ＲＳＶＰプロトコルは、ホストによって使用されて、特定のアプリケーション・データ・ストリーム又はフローに関するネットワークからのサービスの具体的な品質を要求する。ＲＳＶＰは、しかも、ルータにより使用されて、フローの（複数の）経路に沿った全てのノードへサービスの品質（Quality-of-Service）（ＱｏＳ）要求を配信し、そして要求されたサービスを提供するように状態を確立しそして維持する。ＲＳＶＰ要求は、一般に、データ経路に沿った各ノードにおいて予約されるリソースを結果としてもたらすであろう。ＲＳＶＰメッセージは、双方向パケット・フロー（例えば、対話型ＶｏＩＰセッション）又は一方向パケット・フロー（例えば、ストリーミング・セッション）に関するパケット・フィルタを提供する。パケット・フィルタは、ノードによって使用されて、特定のパケット・フローを認識する。

ＲＳＶＰは、特定の宛て先及び搬送−レイヤ・プロトコルとのデータ・フローである“セッション”を規定する。ＲＳＶＰは、各セッションを別々に処理する。ＲＳＶＰセッションは、３成分：（ＤｅｓｔＡｄｄｒｅｓｓ、ＰｒｏｔｏｃｏｌＩｄ ［ＤｓｔＰｏｒｔ］）により規定される。ここで、ＤｅｓｔＡｄｄｒｅｓｓ、データ・パケットのＩＰ宛て先アドレス、は、ユニキャスト・アドレス又はマルチキャスト・アドレスであり得る。ＰｒｏｔｏｃｏｌＩｄは、ＩＰプロトコルＩＤである。オプションのＤｓｔＰｏｒｔパラメータは、“一般化された宛て先ポート”、すなわち、トランスポート又はアプリケーション・プロトコル・レイヤ中のあるさらなる逆多重化点、である。ＤｓｔＰｏｒｔは、ユーザ・データグラム・プロトコル（User Datagram Protocol）／送信制御プロトコル（Transmission Control Protocol）（ＵＤＰ／ＴＣＰ）宛て先ポート・フィールドにより、別の１つのトランスポート・プロトコルにおける等価なフィールドにより、又はあるアプリケーションに固有の情報により、規定されることがある。

主サービス・インスタンスの確立とともに、ＭＳ１０２が補助のサービス・インスタンスを設定することを決定する場合に、ＭＳ１０２は、ＲＳＶＰ ＰＡＴＨ及びＲＥＳＶメッセージを送って、サービスの品質（ＱｏＳ）リソースを要求する。ＲＳＶＰ ＲＥＳＶメッセージにおいて、ＭＳ１０２は、ＩＰアドレス及びポート番号を介してパケット・フローを特徴づけ、そしてコーデック・タイプ及びヘッダ圧縮タイプを伝達する。ＲＳＶＰ ＲＥＳＶメッセージを受信するとともに、ＰＤＳＮは、情報を検査し、そしてＢＳへの新たなＡ１０接続を要求し、そして新たに確立したＡ１０接続をフィルタ・スペック（Filter Spec）及びオプションとしてセッション・クラス（Session Class）（以降、ＲＳＶＰタイプ・プロトコルに関連して規定される）により特徴付けられるパケット・フローと関連付ける。図４は、ＲＦＣ２２０５と整合するＲＳＶＰメッセージのフォーマットを詳細に説明する。ＲＳＶＰメッセージは、パケット・フロー処理法及び／又はマッピングのためにＰＤＳＮによって必要とされる情報の送信のために使用されることができるメッセージの一例として例示される。代わりの実施形態は、同一の情報又は同様の情報を提供するために他のメッセージを与えることができる。

ＲＳＶＰタイプ・プロトコルの議論全体を通して、方向を示す用語は、データのフローの方向にしたがって規定されることに、注意する。予約要求を搬送するＲＳＶＰメッセージは、受信者において始められ、（複数の）送信者に向かってアップストリームに渡される。具体的に、方向を示す用語“アップストリーム”対“ダウンストリーム”、“前のホップ”対“次のホップ”、及び“着信インターフェース”対“発信インターフェース”は、データ・フローの方向に関連して規定される。

図４は、ＲＳＶＰプロトコルを実行するホスト４０１及びルータ４５０を有する通信システムを図示する。図示されたように、ホスト４０１は、ＲＳＶＰプロセス・ユニット４０４に双方向に接続されたアプリケーション・ユニット４０４を含む。ＲＳＶＰプロセス・ユニットは、適切なＲＳＶＰメッセージ及び送信のためのコンテントを決定し、そしてしかもルータ４５０から受信されるこれらのＲＳＶＰメッセージ及びコンテントを考慮する。ＲＳＶＰプロセス・ユニット４０４は、ポリシ制御ユニット５０６に接続される。ホスト４０１内部の通信は、通信バス４２０を介してである。ホスト４０１は、承認制御ユニット４０８，パケット・スケジューラ４１０、及びクラシファイア４１２をさらに含む。

図４を続けて、ルータ４５０は、ホスト４０１におけるような同様のユニットを含む、しかしながら、その構成は、わずかに異なる方式で実装されることができる。ルータ４５０は、ルーティング・ユニット４５２、ＲＳＶＰプロセス・ユニット４５４、ポリシ制御ユニット４５６、承認制御ユニット４５８、パケット・スケジューラ４６０、クラシファイア４６２を含み、全てが通信バス４８０を介して通信する。ＲＳＶＰプロセス・ユニット４０４は、ＲＳＶＰプロセス・ユニット４５４への及びそれからのＲＳＶＰメッセージを通信することに、注意する。

システム４００の内部で、サービスの品質は、“トラフィック制御”と包括的に呼ばれるメカニズムによって特定のデータ・フローに対して与えられる。これらのメカニズムは、（１）パケット・クラシファイア（クラシファイア４１２，４６２）、（２）承認制御手段（承認制御手段４０８、４５８）、及び（３）“パケット・スケジューラ”（パケット・スケジューラ４１０、４６０）又は特定のパケットがいつ転送されるかを決定するためのある別のリンク−レイヤ−依存メカニズム、を含む。“パケット・クラシファイア”メカニズム、すなわちクラシファイア４１２、４６２は、各パケットに関するＱｏＳクラス（及びおそらくルート）を決定する。各発信インターフェースに関して、“パケット・クラシファイア”又は他のリンク−レイヤ−依存メカニズムは、約束されたＱｏＳを達成する。トラフィック制御は、統合によって規定されるＱｏＳサービス・モデルを与える。

予約設定の期間に、ＲＳＶＰ ＱｏＳ要求は、２つのローカル判断モジュール、“承認制御手段”（承認制御手段４０８，４５８）及び“ポリシ制御手段”（４０６，４５６）に渡される。承認制御手段４０８，４５８は、ノードが要求されたＱｏＳを供給するために十分な利用可能なリソースを有するかどうかを判断する。ポリシ制御手段（４０６，４５６）は、ユーザが予約するために管理上の許可を有するかどうかを判断する。両方の検査が上手くいくならば、パラメータは、パケット・クラシファイア中に及びリンク・レイヤ・インターフェース中に（例えば、パケット・スケジューラ中に）設定され、所望のＱｏＳを取得する。もし、いずれか一方の検査が失敗するのであれば、ＲＳＶＰプログラムは、要求を始めた申請プロセスにエラー通知を返す。

ＲＳＶＰプロトコル・メカニズムは、マルチキャスト又はユニキャスト配信経路の網目にわたり配布された予約状態を生成しそして維持するための一般的な手段を与える。ＲＳＶＰ自身は、不透明なデータとしてＱｏＳパラメータ及びポリシ制御パラメータを転送しそして操作して、解釈のために適切なトラフィック制御モジュール及びポリシ制御モジュールへそれらを渡す。大きなマルチキャスト・グループのメンバーシップ及び結果としてのマルチキャスト・ツリー・トポロジーが時間とともに変化することがあるので、ＲＳＶＰ設計は、ＲＳＶＰに関する状態を仮定し、そしてトラフィック制御状態がルータ及びホスト中で漸増的に構築され、破壊されるようにする。この目的で、ＲＳＶＰは、“ソフト”状態を確立する；すなわち、ＲＳＶＰは、周期的なリフレッシュ・メッセージを送って、（複数の）予約された経路に沿った状態を維持する。リフレッシュ・メッセージがなければ、状態は、自動的に時間切れになり、削除される。まとめると、ＲＳＶＰは、以下の属性を有する：
１．ＲＳＶＰは、ユニキャスト及び複数−対−複数マルチキャスト・アプリケーションの両者に関するリソース予約を行い、変化しているグループ・メンバーシップ、同様に変化しているルートにダイナミックに適応する。

２．ＲＳＶＰは、単信方式である、すなわち、ユニキャスト・データ・フローに関する予約をサポートする。

３．ＲＳＶＰは、受信者優先である、すなわち、データ・フローの受信者は、そのフローのために使用されるリソース予約を開始し、そして維持する。

４．ＲＳＶＰは、ルータ及びホスト中の“ソフト”状態を維持し、ダイナミックなメンバーシップの変化及びルーティングの変化に対する自動適応に対して洗練されたサポートを提供する。

５．ＲＳＶＰは、ルーティング・プロトコルではなく、現在及び未来のルーティング・プロトコルをサポートする。

６．ＲＳＶＰは、ＲＳＶＰに対して不透明であるトラフィック制御パラメータ及びポリシ制御パラメータを搬送し、維持する。

７．ＲＳＶＰは、様々なアプリケーションに適応させるために複数の予約モデルを提供する。

８．ＲＳＶＰは、ＲＳＶＰをサポートしないルータを経由してトランスペアレントなオペレーションを提供する。

９．ＲＳＶＰは、ＩＰｖ４及びＩＰｖ６の両者をサポートする。

基本的なＲＳＶＰ予約要求は、“フィルタ・スペック（filter spec）”とともに“フロースペック（flowspec）”からなる；この対は、“フロー・デスクリプタ（flow descriptor）”と呼ばれる。フロースペックは、所望のＱｏＳを特定する。セッション仕様とともに、フィルタ・スペックは、データ・パケットのセット−”フロー“−を規定して、フロースペックによって規定されるＱｏＳを受信する。フロースペックは、ノードのパケット・スケジューラ又は他のリンク・レイヤ・メカニズム中にパラメータを設定するために使用される、一方で、フィルタ・スペックは、パケット・クラシファイア中にパラメータを設定するために使用される。特定のセッションに宛てられるが、そのセッションに関するフィルタ・スペックのいずれにも符合しないデータ・パケットは、最善の努力をした結果の（best effort）トラフィックとして扱われる。

予約要求中のフロースペックは、一般にサービス・クラス及び２セットの数値パラメータ：（１）所望のＱｏＳを規定する“Ｒｓｐｅｃ”（Ｒは‘予約’）、及び（２）データ・フローを記述する“Ｔｓｐｅｃ”（Ｔは‘トラフィック’）、を含む。Ｔｓｐｅｃ及びＲｓｐｅｃのフォーマット及びコンテントは、システムによって決定され、一般にＲＳＶＰに対して不透明である。

フィルタ・スペックの正確なフォーマットは、どのＩＰバージョンが使用されるかに依存する。現在のバージョンは、ＩＰｖ４又はＩＰｖ６を考慮する。１つのアプローチにしたがって、フィルタ・スペックは、所定のセッションにおいて複数のパケットの任意のサブセットを選択することができる。そのようなサブセットは、送信者に関して（すなわち、送信者ＩＰアドレス及び一般化されたソース・ポート）、上位レベル・プロトコルに関して、又は一般にパケット中のいずれかのプロトコルヘッダ中の任意のフィールドに関して規定され得る。例えば、フィルタ・スペックは、アプリケーション・レイヤ・ヘッダ中のフィールドにおいて選択することにより、体系的にエンコードされたビデオ・ストリームの異なるサブフローを選択するために使用されるはずである。単純化のために（及びレイヤ違反を最小にするために）、現在のＲＳＶＰ仕様において規定された基本フィルタ・スペック・フォーマットは、非常に制限された形式：送信者ＩＰアドレス及びオプションとしてＵＤＰ／ＴＣＰポート番号ＳｒｃＰｏｒｔ、を有する。

各中間ノードにおいて、予約要求は、下記のように、２つの一般的なアクションをトリガする。

１．リンク上で予約をする
ＲＳＶＰプロセスは、要求を承認制御手段及びポリシ制御手段に渡す。どちらか一方のテストが不合格であるならば、予約は拒絶され、ＲＳＶＰプロセスは、適切な（複数の）受信者にエラー・メッセージを送り返す。両者が上手くいったならば、ノードは、パケット・クラシファイアを設定して、フィルタ・スペックによって規定されるデータ・パケットを選択する、そして適切なリンク・レイヤと情報を交換して、フロースペックによって規定される所望のＱｏＳを取得する。

ＲＳＶＰ ＱｏＳ要求を満足させるための詳細なルールは、各インターフェースにおいて使用されている固有のリンク・レイヤ技術に依存する。単純なリースされたラインに関して、所望のＱｏＳは、例えば、リンク・レイヤ・ドライバ中のパケット・スケジューラから取得される。リンク・レイヤ技術が、自分自身のＱｏＳ管理可能能力（management capability）を与えるのであれば、ＲＳＶＰは、リンク・レイヤと取り決めをして、要求したＱｏＳを取得する。ＱｏＳを制御するためのアクションは、ＲＳＶＰ予約要求が（複数の）受信者ダウンストリームから開始するのであるが、データがリンク・レイヤ媒体に入る場所において、すなわち、論理リンク又は物理リンクのアップストリーム・エンドにおいて、発生することに、注意する。

２．要求アップストリームを転送する
予約要求は、適切な送信者に向かってアップストリームを伝播される。所定の予約要求がそこに向かって伝播される送信者ホストのセットは、その要求の“スコープ（scope）”と呼ばれる。

ノードがアップストリームを転送する予約要求は、２つの理由のために、ダウンストリームから受信した要求と異なることがある。トラフィック制御メカニズムは、ホップする毎にフロースペックを変更することができる。より重要なことは、同一の送信者（又は送信者のセット）からの（複数の）マルチキャスト・ツリーの異なるダウンストリーム・ブランチからの予約は、アップストリームを移動する予約として“マージ（merge）される”必要がある。

受信者が予約要求を開始する場合に、受信者は、自身の要求がネットワークに（おそらく）インストールされたことを示す確認メッセージを同様に要求することができる。成功した予約要求は、既存の予約が要求されようとしているものと等しくなる又は大きくなる点に自身が到達するまで、マルチキャスト・ツリーに沿ってアップストリームを伝播する。その点において、到着要求は、その場で予約とマージされ、さらに転送される必要がない；ノードは、その後、受信者に対して予約確認メッセージを送り返すことができる。

２つの基本的なＲＳＶＰメッセージ・タイプ：ＲＥＳＶ及びＰＡＴＨ、がある。各受信者ホストは、送信者に向かってアップストリームでＲＳＶＰ予約要求（ＲＥＳＶ）メッセージを送る。これらのメッセージは、データ・パケットが使用するはずの（複数の）経路の精確に逆を、送信者選択において含まれた全ての送信者ホストへのアップストリームで、たどらなければならない。ＲＥＳＶメッセージは、（複数の）経路に沿った各ノードにおける“予約状態”の生成及び維持を結果としてもたらす。ＲＥＳＶメッセージは、送信者ホストそれ自身に最終的に配信され、その結果、ホストは、経路に沿った最初のホップに対して適切なトラフィック制御パラメータを設定できる。

各ＲＳＶＰ送信者ホストは、（複数の）ルーティング・プロトコルにより与えられるユニキャスト／マルチキャスト・ルートに沿ったダウンストリームにＲＳＶＰ“ＰＡＴＨ”メッセージを送信し、データの経路を追跡する。これらのＲＳＶＰ ＰＡＴＨメッセージは、“経路状態（path state）”をその道筋に沿った各ノードに記憶する。この経路状態は、前のホップ・ノードの少なくともユニキャストＩＰアドレスを含み、それは、逆方向にＲＥＳＶメッセージをホップ毎に配達するために使用される。将来の設計が、ルーティング・プロトコルを与えることができることを注意する、そのルーティング・プロトコルは、逆経路転送情報を直接に供給し、経路状態の逆ルーティング機能を置き換える。

ＰＡＴＨメッセージは、前のホップ・アドレスに加えて下記の情報を含む：
１．送信者テンプレート（Sender Template）
ＰＡＴＨメッセージは、送信者テンプレートを搬送するために必要であり、送信者テンプレートは、送信者が始めようとしているデータ・パケットのフォーマットを記述する。このテンプレートは、同一のリンクにおいて同一のセッション中の他のものからこの送信者のパケットを選択するために使用されることができるフィルタ・スペックの形式である。送信者テンプレートは、Ｒｅｓｖメッセージ中に現れるフィルタ・スペックと正確に同一の表現力及びフォーマットを有する。それゆえ、送信者テンプレートは、送信者ＩＰアドレス及びオプションとしてＵＤＰ／ＴＣＰ送信者ポートのみを特定することができ、そしてそのセッションに対して特定されるプロトコルＩｄを仮定する。

２．送信者Ｔｓｐｅｃ（Sender Tspec）
ＰＡＴＨメッセージは、送信者Ｔｓｐｅｃを搬送するために必要とされ、送信者Ｔｓｐｅｃは、送信者が発生させようとしているデータ・フローのトラフィック特性を規定する。このＴｓｐｅｃは、トラフィック制御によって使用されて、過剰予約、及びおそらく不必要な承認制御失敗を防止する。

３．Ａｄｓｐｅｃ
Ｐａｔｈメッセージは、“Ａｄｓｐｅｃ”として知られる、ＯＰＷＡ宣伝情報のパッケージを搬送することができる。ＰＡＴＨメッセージ中で受信されたＡｄｓｐｅｃは、ローカル・トラフィック制御に渡される、これは更新されたＡｄｓｐｅｃを送り返す；更新されたバージョンは、その後、ダウンストリームに送られるＰＡＴＨメッセージにおいて転送される。ＰＡＴＨメッセージは、データと同一のソース及び宛て先で送られる、その結果、非−ＲＳＶＰクラウド（cloud）を経由して正確に配送される。一方で、ＲＥＳＶメッセージは、ホップ毎に送られる；各ＲＳＶＰ会話ノードは、前のＲＳＶＰホップのユニキャスト・アドレスにＲＥＳＶメッセージを転送する。

図２は、ＭＳ１０２、ＢＳ１０４（パケット制御機能（Packet Control Function）（ＰＣＦ）オペレーションを含む）、ＰＤＳＮ１０６、ＡＡＡ１１２、及びＣＮ１０８間の双方向、対話型コール処理を図示する。フローは、（図２中に）１から１６まで番号を付けられたステップで経時的に説明される。

ステップ１において、移動体がアプリケーションによってトリガされたセッション・イニシエーション・プロトコル（Session Initiation Protocol）（ＳＩＰ）シグナリングを送ることができる前に、ＭＳは、パケット・データ・サービスＳＯ３３に関するような、サービス・オプション（Service Option）（ＳＯ）を確立する。図示された例では、無線リンク・プロトコル（Radio Link Protocol）（ＲＬＰ）再送信がイネーブルにされる。これは、無線を介して搬送されるべきＳＩＰメッセージのためのメカニズムを提供する。ＳＩＰは、２００２年２月２１日付、文書番号第draft-ietf-sip-rfc２５４３bis-０８．psを有するインターネット・エンジニアリング・タスク・フォースにより発行された、Ｊ．ローゼンベルグ（Rosenberg）ら著の“ＳＩＰ：セッション・イニシエーション・プロトコル（SIP: Session Initiation Protocol）”；及び１９９９年３月付け、文書番号第ＲＦＣ２５４３を有するネットワーク・ワーキング・グループによって発行された、Ｍ．ハンドレイ（Handley）ら著の“ＳＩＰ：セッション・イニシエーション・プロトコル（SIP: Session Initiation Protocol）”にも詳細に説明されていることに、注意する。

セッション・イニシエーション・プロトコル（ＳＩＰ）は、１又はそれより多くの参加者とセッションを生成するため、変更するため、そして終了するためのアプリケーション・レイヤ制御（シグナリング）プロトコルである。これらのセッションは、インターネット電話通話、マルチメディア配信、及びマルチメディア会議を含む。セッションを生成するために使用されたＳＩＰ要請は、参加者が互換性のある媒体タイプのセットについて合意することを可能にする、セッション説明を搬送する。ＳＩＰは、プロキシ・サーバと呼ばれるエレメントを使用させて、ユーザの現在の場所への配送要求を手助けし、サービスのためにユーザを認証しそして認可し、プロバイダ・コール−ルーティング・ポリシを実装し、及びユーザに対してフィーチャ（feature）を提供する。ＳＩＰは、しかも、ユーザがプロキシ・サーバによる使用のために自身の現在の場所をアップロードすることを可能にする登録機能も提供する。ＳＩＰは、いくつかの異なるトランスポート・プロトコルの先頭で動作する。

ステップ２において、ＭＳは、ＰＤＳＮとのポイント−ツー−ポイント（ＰＰＰ）セッションを確立する。これは、リンク・レイヤに関するベアラ接続を提供し、パケット・フローに関する接続の確立を可能にする。ＰＰＰは、１９９４年７月付けのＲＦＣ１６６１としてネットワーク・ワーキング・グループによって発行された、Ｗ．シンプソン（Simpson）著の“ポイント−ツー−ポイント・プロトコル（ＰＰＰ）”に詳細に説明されていることに、注意する。

ステップ３において、ＰＤＳＮは、ＭＳネットワーク・アクセス・アイデンティファイア（Network Access Identifier）（ＮＡＩ）及び信任状（credential）を含んでいるＡＡＡへアクセス要求（Access Request）送る。ＮＡＩは、ＭＳに関する固有のアイデンティファイアである。信任状は、（シンプルＩＰ（Simple IP）が使用されるのであれば）チャレンジ・ハンドシェイク認証プロトコル（Challenge Handshake Authentication Protocol）（ＣＨＡＰ）に又は（モービルＩＰ（Mobile IP）が使用されるのであれば）フォリン・エージェント・チャレンジ（Foreign Agent Challenge）に応じてＭＳによって算出された認証手段（Authenticator）である。

ステップ４において、移動体が良好に認証されるのであれば、ＡＡＡは、ユーザ申込みプロファイルを含んでいるアクセス承諾（Access Accept）を送る。このプロファイルは、２つの部分からなる：オーバー・ジ・エアー（Over The Air、無線）（ＯＴＡ）コンポーネント；及びＩＰコンポーネントである。

ステップ５において、ＰＤＳＮは、ユーザＩＰ申込みプロファイルを受信し、キャッシュし、そしてＢＳへユーザＯＴＡ申込みプロファイルを転送する。

ステップ６において、移動体は、ＰＰＰ／ＳＯ３３を介してＳＩＰシグナリングを送る。ＳＩＰシグナリングは、ＣＮと仮想ベアラ接続を設定するように働く。これは、そこを通してパケット・フローが搬送されるはずのＩＰベアラ接続である。

ステップ７において、ＳＩＰシグナリング（例えば、１８３セッション・プログレス（Session Progress））によってトリガされる、ＣＮは、ＭＳに向かってＲＳＶＰ ＰＡＴＨメッセージを送る。ＲＳＶＰ Ｐａｔｈメッセージにおいて、ＣＮは、標準ＲＳＶＰオブジェクト送信者テンプレート及び送信者トラフィックＳｐｅｃ（Sender Traffic Spec）（Ｔｓｐｅｃ）を含み、その送信者Ｔｓｐｅｃは、ＣＮによって発生されるはずのパケット・フローを特徴付ける。ステップ８において、ＰＤＳＮは、ＭＳへＲＳＶＰ ＰＡＴＨメッセージを転送する。ステップ９において、ＲＳＶＰ ＰＡＴＨメッセージを受信するとともに、ＭＳは、メッセージ中に含まれた情報を使用して、パケット・フローを受信するために所望のＱｏＳパラメータ（すなわち、帯域幅及び遅延）を計算する。移動体は、その後、ＲＳＶＰ ＲＥＳＶメッセージを送って、ＣＮへ経路に沿ったリソースを予約する。ＲＳＶＰ ＲＥＳＶメッセージは、フロースペック、フィルタ・スペック、及び処理スペックを含み、その処理スペックは、“第３世代パートナーシップ・プロジェクト２”、ここでは３ＧＰＰ２と呼ぶ、と名付けられたコンソーシアムによって提案された標準、及びＴＲ−４５．５、ここではｃｄｍａ２０００標準として呼ばれる、をサポートしているシステムに固有の新たなＲＳＶＰオブジェクトである。

フロースペックは、所望のＱｏＳを特定する。フロースペックは、ノードのパケット・スケジューラ又は他のリンク・レイヤ・メカニズム中のパラメータを設定するために使用される。予約要求中のフロースペックは、サービス・クラス及び２組の数値パラメータ：（１）所望のＱｏＳを規定する“Ｒｓｐｅｃ”（Ｒは‘予約する（reserve）’）、及び（２）データ・フローを記述する“Ｔｓｐｅｃ”（Ｔは‘トラフィック’）、を一般に含む。Ｔｓｐｅｃ及びＲｓｐｅｃのフォーマット及びコンテントは、統合サービス・モデルによって決定され、一般にＲＳＶＰに対して不透明（opaque）である。

フィルタ・スペックは、パケット・フローに関するパケット・フィルタを規定し、そのＱｏＳは、フロースペックによって規定される。フィルタ・スペックは、パケット・クラシファイア中のパラメータを設定するために使用される。特定のセッションに宛てられるがそのセッションに関するいずれのフィルタ・スペックにも符合しないデータ・パケットは、最善の努力をしたトラフィックとして取り扱われる。

処理スペック、これは新たなＲＳＶＰオブジェクトである、は、パケット・フローにおいて使用されるべきヘッダ圧縮タイプを伝える。

ＲＳＶＰ ＲＥＳＶメッセージを受信するとともに、ＰＤＳＮは、ＰＤＳＮローディング及びローカル・ポリシ、移動体到達可能性、とユーザのＩＰ申込みプロファイル、に基づいて認可を実行する。ＰＤＳＮがＲＳＶＰ ＲＥＳＶメッセージを拒絶するのであれば、ＰＤＳＮは、ＣＮに向かってＲＳＶＰＴｅａｒメッセージを、ＭＳに向かってＰＡＴＨＴｅａｒを送る。それ以外は、ＲＳＶＰ ＲＥＳＶが認可されるのであれば、ＰＤＳＮは、ＲＳＶＰ ＲＥＳＶメッセージの処理スペックを検査する。処理スペックは、ＭＳがパケット・フローにおいて使用することを望むヘッダ圧縮タイプを含む。ＰＤＳＮは、新たなＡ１０接続が必要であるか否かを決定する。必要であれば、ＰＤＳＮは、ＢＳへＡ１１登録更新（ＲＵＰ）メッセージを送って、ステップ１０において新たなＡ１０接続を要求する。

例えば、ヘッダ圧縮タイプがＬＬＡＲＯＨＣであるならば、ＰＤＳＮは、ＢＳへ、Ａ１１を介して、通知を与えて、新たなＡ１０接続を確立し、そしてＭＳとの、ＳＯ６１のような、選択されたサービス・オプション・インスタンスの確立を開始する。

ヘッダ圧縮タイプがＲＯＨＣであるならば、ＰＤＳＮは、ＢＳへ、Ａ１１を介して通知を送って新たなＡ１０接続を確立し、そして（ＲＬＰ再送信なしで）ＭＳとの、ＳＯ３３のような、補助のサービス・オプション・インスタンスの確立を開始する。

ヘッダ圧縮タイプとＳＯとの間の提携は、ＰＤＳＮにおいて又はＢＳにおいて行われることができる。提携がＰＤＳＮにおいて行われるのであれば、Ａ１１ＲＵＰメッセージは、ＳＯ番号を含み、そしてＢＳは、ＭＳとサービス取り決めを開始するためにそれを使用する。提携がＢＳにおいて行われるならば、Ａ１１ＲＵＰメッセージは、ヘッダ圧縮タイプを含み、そしてＢＳは、それをＳＯ番号と関連付け、そしてＭＳとのサービス取り決めを開始するためにそれを使用する。

ステップ１１において、ＢＳは、Ａ１１登録受領通知（Registration Acknowledgement）（ＲＡＣＫ）メッセージを用いて応答する。ステップ１２において、ＢＳは、コール割当メッセージ（Call Assignment Message）（ＣＬＡＭ）を介してＭＳへ、Ａ１１シグナリング・メッセージにおいて特定されたＳＯを接続しようと試みる。ステップ１３において、ＢＳは、選択されたＳＯを接続する。ステップ１４において、ＢＳは、Ａ１１ＲＲＱ（登録要求（Registration Request））を送って、Ａ１０接続を確立する。ステップ１５において、ＰＤＳＮは、Ａ１１ＲＲＰ（登録返信（Registration Reply））を用いて応答する。

ステップ１６において、新たなＡ１０接続の良好な確立とともに、ＰＤＳＮは、ステップ９においてＲＳＶＰ ＲＥＳＶメッセージのフィルタ・スペックから取得されたパケット・フィルタと新たに確立されたＡ１０接続を関連付ける。これは、ＰＤＳＮがパケット・フィルタの記述に適応したパケット・フローにフロー・マッピングを実行することを可能にする。ＰＤＳＮは、ＲＳＶＰ ＲＥＳＶメッセージから処理スペックを削除し、そしてそれをＣＮに向けて送る。ある（複数の）理由のために、新たなＡ１０接続がタイムアウトの後で確立されないのであれば、ＰＤＳＮは、ＭＳに向けてＰＡＴＨＴｅａｒメッセージを送る。

この時点から、パケット・フローは、ＰＤＳＮを介してＣＮからＭＳへ処理される。ＰＤＳＮは、パケット・フローに適切なヘッダ圧縮を実行し、そして適切なＡ１０接続へパケット・フローを転送する。

図２は、ＣＮからＭＳへの一方向通信を説明することに、注意する。ＣＮとＭＳとの間の対話型双方向通信に関して、ＭＳ及びＣＮの両者は、ソースであり宛て先である。それゆえ、図２に示されそして上記に詳細に説明されたステップに加えて、対称的なステップが、ＭＳから開始される。例えば、ＭＳは、しかも、ＲＳＶＰ Ｐａｔｈメッセージを送る。同様に、ＰＤＳＮは、ＣＮへＲＳＶＰ Ｐａｔｈメッセージを転送する。ＣＮは、ＲＳＶＰ ＲＥＳＶメッセージを提供する；そしてＰＤＳＮは、ＭＳへＲＳＶＰ ＲＥＳＶメッセージを転送する。ＣＮからのＲＳＶＰ ＲＥＳＶメッセージは、ステップ１０におけるようにＡ１０接続の確立を要求するためにＰＤＳＮをトリガする必要性がない。

イネーブルにされたＲＬＰ再送信のない補助ＳＯ３３に対する既存のＡ１０接続の状況に関して、１つの実施形態は、既存の接続を利用する。代わりの実施形態にしたがって、ＢＳは、ＭＳとの他の１の補助ＳＯ３３を確立する。この場合には、ＭＳが拒絶するのであれば、既存の補助ＳＯ３３は、新たなコーデックを搬送するためにも使用される。

図２は、ＩＰ通信に対して適応し、パケット・フローを処理することが可能な、スペクトル拡散通信システムにおけるコール・フローを図示する。代わりの通信システムは、パケット・フローを処理するために必要な情報を提供するために採用されることができる。そのような情報は、例において詳細に説明された特定の情報に制限されることなく、システム・コンポーネントにより必要な又は要求される任意の情報を含むことができる。同様に、ステップの順序は、所定のシステムの設計及びニーズにしたがって変えられることができる。図２のコール・フローは、パケット・フロー処理の一例として与えられる。

以下に説明される実施形態は、ＲＳＶＰメッセージを介してフロー処理法及びフロー・マッピング情報を提供する他の１方法である。フロー処理法及びマッピング情報は、ＲＳＶＰ ＲＥＳＶメッセージにおいて伝達された標準ＲＳＶＰオブジェクトから導出されることができ、そして新たなＲＳＶＰオブジェクトは、前の方法におけるように規定される必要がない。

コール・フローは、図２と同じである。１つの違いは、ステップ９において、ＲＳＶＰ ＲＥＳＶメッセージは、フロースペック及びフィルタ・スペックを含むだけである。そこには、どのヘッダ圧縮タイプがパケット・フローにおいて使用されるべきかをＰＤＳＮに明確に知らせる処理スペックがない。その代わりに、ＰＤＳＮは、暗黙のうちヘッダ圧縮タイプを決定するためにフロースペックを使用する。

フロースペックは、予約スペック（Reservation Spec）（Ｒｓｐｅｃ）及びトラフィック・スペック（Traffic Spec）（Ｔｓｐｅｃ）を含む。Ｒｓｐｅｃは、サービス・レートを記述し、そしてＴｓｐｅｃは、トークン・バケット・パラメータ（token bucket parameter）（バケット・レート、ピーク・レート、バケット深さ、最大バケット・サイズ）を記述して、ＣＮが発生させようとするトラフィックを特徴付ける。Ｒｓｐｅｃ及びＴｓｐｅｃは、ともに、ＣＤＭＡ音声コーデック（例えば、１３−ｋｂｐｓピュアボイス（純音声：Pure Voice）、８−ｋｂｐｓ ＥＶＲＣ、８−Ｋｂｐｓ ＳＭＶ、又は４−ｋｂｐｓ ＳＭＶ）を特徴付け、そのＣＤＭＡ音声コーデックは、２０ｍｓ毎に音声フレームを出力する。ＰＤＳＮは、フロースペック中のパラメータ値に基づいて、ＣＤＭＡ音声コーデックを認識するように構成される。符合しているのであれば、そしてＭＳがＬＬＡＲＯＨＣの能力があるならば、ＰＤＳＮは、ＢＳが新たなＡ１０接続を確立することを要求し、そしてＢＳは、ＭＳとのＳＯ６１を確立する。符合しないのであれば、ＰＤＳＮは、パケット・フローがＣＤＭＡ音声コーデック以外のリアル・タイム・コーデックを搬送すると結論付ける；この場合には、ＭＳがＲＯＨＣの能力があり、現在、補助ＳＯ３３を何も持たないのであれば、ＰＤＳＮは、ＢＳが新たなＡ１０接続を確立することを要求し、ＢＳは、ＭＳとの（ＲＬＰ再送信がディスエーブルにされている）補助ＳＯ３３を確立する。

異なるコーデックが、ＣＤＭＡコーデックと同じＲｓｐｅｃ及びＴｓｐｅｃの記述を有することが、可能である。例えば、コーデックＸは、サービス・レート８ｋｂｐｓ、２０−ｍｓの一定のパケット間インターバル、及び１７１ビット足すヘッダ・オーバーヘッドの最大パケット・サイズとして特徴付けられ、これは、ＥＶＲＣ特性と同一である。この寄与は、あたかもＥＶＲＣであるかのように、０−バイト・ヘッダ圧縮が、コーデックＸを搬送するパケット・フローに適用されることを、推奨する。低レート・フレーム・サイズのコーデックＸは、ＥＶＲＣのフレーム・サイズと異なるはずであるけれども、各低レート・フレームは、ＣＤＭＡ物理レイヤ・フレーム（全体、１／２、１／４、又は１／８）中に詰め込まれ、そして適合させられることが可能である。

図３は、コール・フロー処理を図示し、そこでは、ＰＤＳＮは、ＳＩＰメッセージを“スニフィング（sniffing）（感付くこと）”することからフロー処理法及び／又はマッピングを決定する。スニフィングは、特定の情報を待機しているメッセージを検査するプロセスを呼ぶ。一般的に、ノードは、特定の情報をスニフする一方で、全ての他の情報を無視する。図３に図示された実施形態では、ＰＤＳＮは、所定のパケット・フローの処理法を決定するために及び／又は所定のパケット・フローのマッピングのために要求される特定の情報をスニフする。ＰＤＳＮは、ＳＩＰシグナリング・メッセージをスニフする。ＰＤＳＮは、ＳＩＰメッセージの他のコンテントを無視する。代わりの実施形態は、ＰＤＳＮのそのような処理のために又は他のオペレーションのためにＳＩＰメッセージ中の他のコンテントを適用することができる。

図３に図示された実施形態は、フロー処理法及びフロー・マッピング情報を決定するための代わりの方法を提供し、そこでは、そのような決定は、ＰＤＳＮがスニフしているセッション・イニシエーション・プロトコル（ＳＩＰ）メッセージに基づく。この方法は、ＰＤＳＮがＳＩＰメッセージをスニフすることを信頼して、ＣＮによって発生されるはずの新たなパケット・フローのコーデック、ＩＰアドレス、及びポート番号を決定する。これは、ＰＤＳＮがフロー処理法及びフロー・マッピングを決定するために十分な情報を提供する。ＰＤＳＮは、パケット・フローを搬送するために新たなＡ１０接続が必要であるか否かも決定する。もし必要であれば、ＰＤＳＮは、ＢＳがＡ１０接続を確立することを要求し、ＢＳは、ＭＳとの新たなサービス・インスタンスの確立を開始する。

スニフしているＳＩＰメッセージは、ＩＰパケットがＳＩＰメッセージを搬送していること、そしてＳＩＰメッセージから本質的な情報を取り出すことを、ＰＤＳＮが認識することを必要とする。ＰＤＳＮは、パケットの宛て先ポート番号を検査する。もし、５０６０に等しければ、搬送ペイロードは、ＳＩＰメッセージを搬送している。そこには多くのＳＩＰメッセージ及びフィールドがあることに、注意する。ＰＤＳＮは、ＳＩＰ ＩＮＶＩＴＥ（要請）メッセージ及びＳＩＰ２００ＯＫメッセージに注意を払い、そして他のＳＩＰメッセージを無視することを選択することができる。ＳＩＰは、様々なメッセージを規定することに、注意する。ＳＩＰ ＩＮＶＩＴＥメッセージは、ユーザ又はサービスがセッションに関与するようにこれから要請されることを指示する。ＳＩＰ ２００ ＯＫメッセージは、要求が良好に行われたことを指示する。ＳＩＰ ＩＮＶＩＴＥメッセージ及びＳＩＰ ２００ ＯＫメッセージ内では、ＰＤＳＮは、ＩＰアドレス情報を伝える接続フィールド、ポート番号情報を伝える媒体フィールド、及びコーデック・タイプを伝える属性フィールド、に注意を払う。コーデック・タイプに基づいて、ＰＤＳＮは、どのヘッダ圧縮タイプがパケット・フローにおいて使用されるべきかを決定する。例えば、コーデック・タイプがＣＤＭＡコーデック（例えば、ピュアボイス、ＥＶＲＣ、又はＳＭＶ）を指示するのであれば、リンク−レイヤ−アシスティッド・ロバスト・ヘッダ圧縮（Link-Layer-Assisted Robust Header Compression）（ＬＬＡＲＯＨＣ）が使用される；コーデック・タイプがＣＤＭＡコーデック以外のコーデックを指示するのであれば、ロバスト・ヘッダ圧縮（Robust Header Compression）（ＲＯＨＣ）が使用される。代わりのシステムは、複数のコーデック・タイプのいずれかをサポートすることができ、ここに与えられた具体的な詳細説明は、例として機能する。

ＰＤＳＮがヘッダ圧縮タイプを決定した後で、ＰＤＳＮは、新たなＡ１０接続が新たなパケット・フローに対して必要であるか否かを決定する。もし必要であるならば、ＰＤＳＮは、ＢＳがＡ１０接続を確立することを要求し、そしてＢＳは、ＭＳとの新たなサービス・インスタンスの確立を開始する。Ａ１０接続の良好な確立とともに、ＰＤＳＮは、Ａ１０接続をスニフしているＳＩＰメッセージから取得されたパケット・フィルタと、すなわち、ＳＩＰ ＩＮＶＩＴＥメッセージ及びＳＩＰ ２００ ＯＫメッセージの接続フィールド及び媒体フィールドと、関係付ける。

図５は、パケット・フローを処理するために適応するＭＳ５００を図示する。ＭＳ５００は、アンテナ５１０、受信機５２０、及び送信機５３０を含む。受信機５２０及び送信機５３０は、中央処理ユニット（ＣＰＵ）５４０にそれぞれ接続される。ＣＰＵ５４０及びメモリ５５０は、通信バス５６０にそれぞれ接続される。さらに、パケット・フロー設定ユニット５７０、パケット・フロー処理ユニット５８０、及びパケット・フロー決定ユニット５９０は、通信バス５６０にそれぞれ接続される。パケット・フロー決定ユニット５９０は、通信が双方向であるか又は一方向であるかどうかを決定する。パケット・フロー設定ユニット５７０は、コーデック・タイプ、ヘッダ圧縮のような、パケット・フローの詳細を決定する。パケット・フロー設定ユニット５７０及びパケット・フロー決定ユニット５９０は、図２及び図３に説明されたような、パケット・フローの送信のための初期アクセス及び設定に携わる。一旦、通信が確立されると、パケット・フロー処理ユニット５８０は、確立された特定のパラメータにしたがってパケット・フローを処理する。

本発明は、差別化されたサービス・コード・ポイント（Differentiated Service Code Point）（ＤＳＣＰ）に依存せずにＲＳＶＰメッセージ中のパケット・フロー・パラメータを通信するためのフレキシブルな方法を提供し、ＤＳＣＰは、ＩＰヘッダ、プロトコル・タイプ、及び周知のポート番号のフィールドにおいて伝えられる。ＲＳＶＰメッセージのようなメッセージの使用は、双方向及び一方向パケット・フローの両者に対して使用されることができる。

パケット・フロー情報を提供するために既存のメッセージの使用は、効率的な無線リソース割り当て及び使用基準を実現する。１つの実施形態では、通信のための新たなベアラ接続、すなわち、新たなＡ１０接続、は、ＲＳＶＰ予約が認可されるまで確立されない。これは、拒絶されたときにベアラ接続（すなわち、補助ＳＯ、Ａ８／Ａ１０接続）の終了を必要とすることを回避する。

代わりの実施形態では、追加のサービス・インスタンス設定が、図６に図示されたように始められることができる。図６のコール・フロー図は、ＭＳが、主サービス・インスタンスが確立されると既にアクティブである場合に、追加のサービス・インスタンス設定手順を図示する。この手順は、以下の通りである：
点ａにおいて、ＰＤＳＮは、追加のサービス・インスタンスを確立することをように決定する；ＰＤＳＮは、ＰＣＦへＡ１１登録更新を送る。Ａ１１登録更新メッセージは、ＰＤＳＮが適用されたヘッダ圧縮アルゴリズムを指示することを可能にする。ＰＤＳＮは、登録更新メッセージに関連付けられたタイマー、タイマー“Ｔ‘ｒｅｇｕｐｄ”と呼ばれる、をスタートする。

点ｂにおいて、ＰＣＦは、追加のサービス・インスタンスを要求するためにＢＳへＡ９−ＢＳサービス要求メッセージを送り、そしてタイマー“Ｔ_{ｂｓｒｅｑ９}”と呼ばれるタイマーをスタートする。ヘッダ圧縮アルゴリズムとサービス・オプションとの間のマッピングは、ＰＣＦ又はＢＳにおいて実行されることができる。１つの実施形態にしたがえば、決定は、ＴＳＧ−Ａ（テクニカル・スペシフィケーション・グループ（Technical Specification Group））によってなされる。マッピングがＰＣＦによって実行されるならば、既存のＡ９−ＢＳサービス要求メッセージに変更が行われない。マッピングがＢＳにおいて実行されるならば、ＰＣＦは、Ａ９−ＢＳサービス要求メッセージにおいてＢＳに対して適用されたヘッダ圧縮アルゴリズムを指示する。例えば、マッピング・テーブルは、下記のように指定されることができる：

ステップｃにおいて、ＢＳは、ＭＳＣへ追加のサービス要求メッセージを送り、そして追加のサービス・インスタンスを再接続するためにタイマー“Ｔ_３０３”と呼ばれるタイマーをスタートする。

ステップｄにおいて、ＭＳＣは、ＢＳへ割当要求（Assignment Request）メッセージを送って、無線リソースの割当及びＢＳとＰＣＦとの間のＡ８（例えば、ユーザ・トラフィック（User Traffic））接続を要求する。ＭＳＣは、その後、タイマー“Ｔ_１０”と呼ばれるタイマーをスタートさせる。ＭＳＣから割当要求メッセージを受信するとともに、ＢＳは、タイマーＴ_３０３を停止する。

ステップｅにおいて、ＢＳは、Ａ９−ＢＳサービス応答を用いて応答する。ＰＣＦは、Ａ９−ＢＳサービス応答メッセージを受信するとともにタイマーＴ_{ｂｓｒｅｑ９}を停止する。

ステップｆにおいて、ＢＳから良好なＡ９−ＢＳサービス応答メッセージを受信するとともに、ＰＣＦは、Ａ１１登録受領通知を用いて応答する。ＰＤＳＮは、タイマーＴ‘ｒｅｇｕｐｄを停止する。

ステップｇにおいて、ＢＳは、無線インターフェースのトラフィック・チャネルを介してコール割当メッセージを送ることができて、ＣＣステート・マシーン（コール制御ステート・マシーン）の確立を開始する。

ステップｈにおいて、ＢＳは、ＭＳへ：ｉ）サービス接続メッセージ；ｉｉ）通常ハンドオフ管理メッセージ；又はｉｉｉ）普遍的なハンドオフ管理メッセージ、のうちの１つを送って、追加のサービス・オプション接続を呼び出す。

ステップｉにおいて、サービス取り決めは、ＭＳとＢＳとの間で実行されることができる。ステップｊにおいて、サービス取り決め手順の完了とともに、サービス接続完了メッセージを用いて応答する。

ステップｋにおいて、ＢＳは、ＰＣＦへＡ９−設定−Ａ８メッセージを送って、Ａ９（例えば、シグナリング）接続を介して、追加のサービス・インスタンスのためにＢＳとＰＣＦとの間のＡ８（すなわち、ユーザ・トラフィック）接続を確立する。ＢＳは、その後、タイマー“Ｔ_{Ａ８−Ｓｅｔｕｐ}”と呼ばれるタイマーをスタートさせる。

ステップｌにおいて、ＰＣＦは、この移動体に関連付けられたＡ１０接続があり、そして追加のＡ１０接続がこれから設定される必要があることを認識する。ＰＣＦは、対応するＰＤＳＮへＡ１１−登録要求メッセージを送る。ＰＣＦは、タイマー“Ｔ‘ｒｅｇｒｅｑ”と呼ばれるタイマーをスタートさせる。

ステップｍにおいて、ＰＤＳＮは、承諾指示を有するＡ１１−登録回答メッセージを送り返すことによって接続を承諾する。

ステップｎにおいて、ＰＣＦは、Ａ９−接続−Ａ８メッセージを用いて応答して、このパケット・サービス要求に関するＡ８（例えば、ユーザ・トラフィック）接続の設定を完了する。ＰＣＦからのＡ９−接続−Ａ８メッセージの受信とともに、ＢＳは、タイマーＴ_{Ａ８−Ｓｅｔｕｐ}を停止する。

ステップｏにおいて、無線サービス接続及びＡ１０接続が確立された後で、ＢＳは、ＭＳＣへ割当完了メッセージを送る。ＭＳＣが割当要求メッセージを送る場合に、ＭＳＣは、その後、タイマーＴ_１０を停止する（ステップｄ参照）。

ＰＤＳＮが、システムによりサポートされているようなメッセージを使用することによって新たなＡ１０接続の追加に関する要求を開始することができることに、注意する。ＰＤＳＮは、ＰＣＦへＡ１１−登録更新メッセージを送って、新たなＡ１０接続の追加を要求する。ＰＤＳＮは、‘新たな接続を追加（Add New Connection）’に設定されたメッセージ中のコード・フィールドを有するＡ１１登録更新メッセージを送って、新たなＡ１０接続をＰＣＦが確立することを要求する。ＰＤＳＮは、その後、Ａ１１−登録更新メッセージを送った後で、“Ｔ’ｒｅｇｕｐｄ”と呼ばれる登録更新に関連付けられたタイマーをスタートさせる、そして、ＰＣＦからのＡ１１−登録Ａｃｋメッセージを待つ。

タイマーＴ’ｒｅｇｕｐｄが時間切れになるのであれば、ＰＤＳＮは、設定可能な回数ＰＣＦへＡ１１−登録更新メッセージを再送信することができる。ＰＣＦからの応答なしで設定可能な回数の再送信の後で、セッション確立手順は、失敗したとして考えられることができる、しかしながら、既存の（複数の）Ａ１０接続は、接続されたまま残る。

要求されたオペレーションが、ＢＳ、ＰＣＦ、及びＭＳＣによって良好にサポートされることができるのであれば、ＰＣＦは、ＰＤＳＮへＡ１１−登録受領通知メッセージを送って、要求されたＡ１０接続が承諾されたことを通知する。

‘新たな接続を追加’に設定されたメッセージのコード・フィールドを有するＡ１１−登録更新メッセージを受信するとともに、要求されたＡ１０接続をＰＣＦがサポートするのであれば、ＰＣＦは、ＢＳへＡ９−ＢＳサービス要求メッセージを送る。ＭＳＣ及びＢＳが新たな接続をサポートするならば、ＰＣＦは、メッセージ中の状態フィールドを‘新たな接続が受諾された’に設定することによって指示する。メッセージの受信とともに、ＰＤＳＮは、Ａ１１−登録更新メッセージが送られた時に、タイマーＴ‘ｒｅｇｕｐｄを停止するはずであり、Ａ１１−Ａｃｋが受信された時に停止する。

‘新たな接続を追加’に設定されたメッセージのコード・フィールドを有するＡ１１−登録更新メッセージの受信とともに、ＰＣＦが要求されたＡ１０接続をサポートしないのであれば、又は要求された接続がＢＳから受信されたＡ９−ＢＳサービス応答メッセージによって否定されるのであれば、ＰＣＦは、メッセージ中の状態フィールドを‘新たな接続が否定された’に設定することによって指示する。メッセージの受信とともに、ＰＤＳＮは、タイマーＴ‘ｒｅｇｕｐｄを停止する。

ＰＤＳＮがＰＣＦからＡ１１−登録受領通知メッセージを受信することに失敗するならば、新たな確立が失敗したと考える前に、ＰＤＳＮは、設定可能な回数Ａ１１−登録更新メッセージを再送信することができる。

上に説明されたメッセージのそれぞれは、システムによって規定されたように任意の数のフィールド及びコードを含むことができる。例えば、３ＧＰＰ２における設計のために提案されたように、Ａ１１−登録更新メッセージは、コードを含む。メッセージが、追加の接続を要求する又は既存の接続への更新を要求する場合に、コード情報エレメントが含まれる。コード・エレメントは、Ａ１１−登録要求メッセージの処理の結果を識別する。例えば、コード（十進法の）３３は、“新たな接続追加”を指示する。

同様に、Ａ１１−登録更新メッセージは、Ａ１１−登録更新メッセージの処理の結果を識別する関連付けられた状態エレメントを有する。例えば、状態（十進法の）１４９は、“新たな接続承諾”を指示し；状態（十進法の）１５０は、“新たな接続拒絶”を指示する。

さらに、（十六進法の）０ＡＨの通常ベンダ／オーガニゼーション特定拡張（Normal Vendor/Organization Specific Extension）（ＮＶＳＥ）−アプリケーション・タイプは、ヘッダ圧縮アルゴリズムを指示する。アプリケーション・サブタイプは、その後、特定のアルゴリズムを識別するために使用される。例えば、（十六進法の）０１Ｈは、ロバスト・ヘッダ圧縮（ＲＯＨＣ）を識別し、一方で、（十六進法の）０２Ｈは、リンク・レイヤが補助する（Link-Layer Assisted）ＲＯＨＣ（ＬＬＡＲＯＨＣ）を識別する。ＭＮセッション・リファレンスＩＤフィールド（MN Session Reference ID field）は、移動体においてパケット・データ・サービス・インスタンスを一義的に識別するために使用される。ＭＮセッション・リファレンスＩＤは、移動体からＰＣＦへ渡される。アプリケーション・タイプ０ＡＨ（ヘッダ圧縮アルゴリズム）に関して、ＭＮセッション・リファレンスＩＤフィールドは、オクテット１１中のヘッダ圧縮アルゴリズムを含む。

マルチ−チャネル・フロー処理プロトコル（Multi-Channel Flow Treatment Protocol）（ＭＣＦＴＰ）は、新たなＰＰＰプロトコル・タイプとして規定される。ＭＣＦＴＰは、パケット・フローと０バイト・ヘッダ圧縮に対するＳＲ＿ＩＤ、例えば、フローが基礎になるサービス・インスタンス接続にどのようにしてマッピングされるか、との間、ＭＳとＰＤＳＮとの間、の結合に関する情報を搬送する。ＭＣＦＴＰは、ヘッダ削除モードがＭＳとＰＤＳＮとの間で使用されるならば、ＭＳからＰＤＳＮへＩＲ−スタティック情報を同様に搬送する。ＭＣＦＴＰの情報エレメントは、必要に応じてプロトコルの容易な拡張を可能にするタイプ、長さ、数値（ＴＬＶ）原理に沿って設計される。

何らかのＭＣＦＴＰパケットが通信されることがあり得る前に、ＰＰＰは、ネットワーク−レイヤ・プロトコル・フェーズ（Network-Layer Protocol Phase）に到達する。ＭＣＦＴＰパケットは、図９に図示される。１より多くのＭＣＦＴＰパケットが、ＰＰＰ情報フィールド中にカプセル化されることができ、そこでは、プロトコル番号は、プロトコルｘ０２８９（ＭＣＦＴＰ）を指示する。ＭＣＦＴＰは、３つの基本的なメッセージ・フォーマットを使用する：
・ＭＣＦＴＰ−要求（オペレーション・コード＝１）
・ＭＣＦＴＰ−応答（オペレーション・コード＝２）
・ＭＣＦＴＰ−拒絶（オペレーション・コード＝７）。
ＭＣＦＴＰ−要求メッセージ・フォーマットは、１に等しいコードを用いて送られ、そして表１に示されたフィールドを含む。

ＭＣＦＴＰ−応答メッセージは、ＭＣＦＴＰ−要求メッセージが良好に受信され処理されたことに応答して送られる。これは、単純に中身が空である又は含まれたＩＲ−スタティック情報のどちらか一方を有するＭＣＦＴＰパケットである。ＭＣＦＴＰ−応答メッセージ・フォーマットは、２に等しいコードを用いて送られ、そして表２に示されたフィールドを含む。

ＭＣＦＴＰ−拒絶メッセージは、例えば、受信者が受信したオプション又はサブオプションを識別できなかった場合のような、処理できなかったＭＣＦＴＰ−要求メッセージに応答して送られる。ＭＣＦＴＰ−拒絶パケット・フォーマットは、７に等しいコードを用いて送られ、そして表３に示されたフィールドを含む。

１つの実施形態にしたがえば、フロー・マッピングのための方法、単純化されたＭＣＦＴＰ方法は、局在化されたＲＳＶＰ方法と統合される。具体的には、単純化されたＭＣＦＴＰは、０バイト・ヘッダ圧縮ＮＨＰパケット中にコンテクトＩＤ（ＣＩＤ）がないために、ＳＲ＿ＩＤ（サービス・リファレンス・アイデンティフィケーション（Service Reference Identification））とＩＰフローとの間の結合を確立するための０バイト・ヘッダ圧縮に対して使用されるだけである。単純化されたＭＣＦＴＰは、ＳＲ＿ＩＤ結合及び０バイト・ヘッダ圧縮削除モードに関するＩＲ−スタティックのような、リンク・レイヤ・パラメータをＭＣＦＴＰが含むので、ＵＤＰの代わりにＰＰＰを介してランする。局在化されたＲＳＶＰは、移動体ノードへＭＣＦＴＰ要求を送るＰＤＳＮをトリガするために使用される。この方法は、標準の局在化されたＲＳＶＰメッセージ及びオブジェクトを使用する。既存のＲＳＶＰオブジェクトは、ＰＤＳＮに関する十分な情報を伝えて、コーデック特性、それゆえ、どのヘッダ圧縮方法がパケット・フローにおいて使用されるべきか、を決定する。３ＧＰＰ２−固有のＲＳＶＰオブジェクトは、要求されない。ＰＤＳＮは、しかも、新たなＡ１０接続がＩＰフローを搬送するために必要であるか否かを決定する。必要であれば、ＰＤＳＮは、ＲＮがＡ１０接続を確立することを要求し、そして、ＲＮは、ＭＳと新たなサービス・インスタンスの確立を開始し、そしてサービス取り決めが、ＭＳとＲＮとの間で実行されることができる。新たなサービス・インスタンスが確立された後で、ＰＤＳＮは、ＰＰＰを介してＭＣＦＴＰを送って、ＩＰフローとＳＲ＿ＩＤとの間を結合することを指示する。ヘッダ削除モードが使用されるならば、ＭＳは、ＰＰＰを介してＭＣＦＴＰを使用することによって、ＰＤＳＮへＩＲ−スタティック・パラメータを送る。

図７は、ＰＤＳＮ及びＭＳが、対応するノード（ＣＮ）によってこれから発生されるパケット・フローに関するフロー処理法及びマッピングを、どのように決定するかを図示する。

１．移動体は、主サービス・インスタンス（すなわち、イネーブルにされたＲＬＰ再送信を有するＳＯ３３）を確立する。移動体は、無線を介して信頼性のある搬送を提供する主サービス・インスタンスを介してＳＩＰメッセージ及びＲＳＶＰメッセージを後で送る。移動体は、ＰＤＳＮとのＰＰＰセッションを確立する。移動体は、ＰＰＰ ＩＰＣＰフェーズの間にＰＤＳＮへ自身のヘッダ圧縮可能出力（例えば、ＲＯＨＣ、ＬＬＡＲＯＨＣ、ＶＪＨＣ）を指示する。

２．ＰＤＳＮは、移動体のネットワーク・アクセス・アイデンティファイア（Network Access Identifier）（ＮＡＩ）及び信用証明書（credential）を含んでいるＡＡＡへアクセス要求を送る。信用証明書は、（単純ＩＰが使用されるのであれば）ＣＨＡＰ、又は（モービルＩＰが使用されるのであれば）ＦＡチャレンジに応答して移動体によって算出される認証手段（authenticator）である。

３．移動体が良好に認証されるならば、ＡＡＡは、ユーザ申込みプロファイルを含んでいるアクセス承諾（Access Accept）を送る。

４．ＰＤＳＮは、ＲＮへユーザ申込みプロファイルを転送することができる。この時に、ＰＤＳＮは、以下のように主サービス・インスタンスに関するパケット・フィルタを確立できる。全ての着信ＩＰパケットは、宛て先ＩＰアドレスが符合するのであれば、ＧＲＥトンネル（Ａ１０接続）ｘに符合する。

記号^“＊”は、ワイルド・マッチ（wild match）を示すことに、注意する。

５．後のいずれかの時点で、移動体とＣＮは、ＳＩＰシグナリングを交換する。

６．ＳＩＰシグナリング（例えば、１８３セッション・プログレス（Session Progress））によりトリガされると、移動体は、ＰＤＳＮへＰＡＴＨ要求メッセージを送って、送信者（すなわち、ＣＮ）の代わりにＲＳＶＰ予約設定を開始するためにローカルＲＳＶＰプロクシを合図する。ＰＡＴＨ要求メッセージは、ＰＤＳＮへ宛てられる。移動体は、ＩＰＣＰの間にＰＤＳＮのＩＰアドレスを見つける。設定されたＬＩ（局在化されたアイデンティフィケーション（Localized Identification））フラッグを有するＰａｔｈ要求メッセージは、メッセージ・タイプ・フィールドを除いて標準のＰａｔｈメッセージと同じである。Ｐａｔｈ要求メッセージは、セッション・オブジェクト、予期される送信者を規定する送信者テンプレート、及び移動体ユーザの希望又は着信トラフィック特性の最善の推定値に基づいた又は搬送に先立つアプリケーション・レベル・セッション・シグナリング（例えば、ＳＩＰ）に基づいたトラフィック仕様（ＴＳｐｅｃ）、を含む。

７．ＰＤＳＮ，又はローカルＲＳＶＰプロクシ、がＰａｔｈ要求メッセージを受信する場合に、ＰＤＳＮは、メッセージがアクセス・ネットワーク内に留まることを意味することを検出する。メッセージ・タイプは、プロクシがダウンストリーム・フローに関するＲＳＶＰ予約を開始するはずであり、そしてＰａｔｈメッセージ中のフィールドを埋めるためにメッセージ中の情報を使用すべきであることを、指示する。それゆえ、ＰＤＳＮは、設定されたＬＩフラッグを有する移動体ノードへＰａｔｈメッセージを送る。セッション・オブジェクト及び送信者テンプレートが当初は“後方”に設定されたので、プロクシは、これらのエントリーを直接そのままＰａｔｈメッセージにコピーできる。

８．移動体ノードは、設定されたＬＩフラッグを有するＲＥＳＶメッセージを用いて応答する。

９．ＲＳＶＰ ＲＥＳＶメッセージを受信するとともに、ＰＤＳＮは、ＰＤＳＮローディングとローカル・ポリシ、移動体到着可能性、及びユーザのＩＰ申込みプロファイルに基づいて認可を実行する。認可されたならば、ＰＤＳＮは、フロースペック及びフィルタ・スペックに基づいてフロー処理法及びマッピングを決定する。

ＰＤＳＮは、フロースペックを使用して、どのヘッダ圧縮方法がパケット・フローに使用されるべきかを決定する。フロースペックは、予約スペック（Ｒｓｐｅｃ）及びトラフィックスペック（Ｔｓｐｅｃ）を含む。Ｒｓｐｅｃは、サービス・レートを記述する、そしてＴｓｐｅｃは、トークン・バケット・パラメータ（バケット・レート、ピーク・レート、バケット深さ、最大パケット・サイズ）を記述して、ＣＮが発生しようとするトラフィックを特徴付ける。Ｒｓｐｅｃ及びＴｓｐｅｃは一緒に、音声フレームを２０ｍｓ毎に出力するＣＤＭＡ音声コーデック（１３−ｋｂｐｓ ピュアボイス、８−ｋｂｐｓ ＥＶＲＣ、８−ｋｂｐｓ ＳＭＶ、又は４−ｋｂｐｓ ＳＭＶ）を特徴付けることができる。代わりのコーデックが同じＲｓｐｅｃ及びＴｓｐｅｃ記述を有することができることに、注意する。例えば、コーデックＸは、サービス・レート８ｋｂｐｓ、２０−ｍｓ一定パケット間インターバル、及び１７１ビット足すヘッダ・オーバーヘッドの最大パケット・サイズとして、特徴付けられ、これは、ＥＶＲＣ特性と同じである。０−バイト・ヘッダ圧縮は、それがあたかもＥＶＲＣであったかのように、コーデックＸを搬送するパケット・フローに適用されることができる。コーデックＸの低レート・フレーム・サイズがＥＶＲＣのものと異なることがあるとはいえ、各低レート・フレームは、詰め込まれ、そしてＣＤＭＡ物理レイヤ・フレーム（全体、１／２，１／４，又は１／８）に適合させられることが可能である。

ＰＤＳＮは、フロースペック中のパラメータ値に基づいてＣＤＭＡ音声コーデックを認識するように構成される。符合するのであれば、そしてＭＳがＬＬＡＲＯＨＣの能力があるならば、ＰＤＳＮは、ＲＮが新たなＡ１０接続を確立することを要求し、そしてＲＮは、ＭＳとのＳＯ６１を確立する。符合しないのであれば、ＰＤＳＮは、ＩＰフローがＣＤＭＡ音声コーデック以外のリアル・タイム・コーデックを搬送すると、結論を下す；この場合には、ＭＳがＲＯＨＣの能力があり、現在、補助のデータ・サービス・オプションＳＯ３３を有するのであれば、ＰＤＳＮは、ＲＮが新たなＡ１０接続を確立することを要求し、ＲＮは、ＭＳとの補助ＳＯ３３（ディスエーブルにされたＲＬＰ再送信）を確立する。

ＰＤＳＮは、フロー・マッピングのためにフィルタ・スペックを使用する。フィルタ・スペックは、ＣＮよって生成されるはずのパケット・フローのソース・アドレス及びポート番号を伝える。ＰＤＳＮが新たなＡ１０接続を要求するならば、ＰＤＳＮは、新たな接続をフィルタ・スペックに記述されたパケット・フローと関連付ける。

１０．新たなＡ１０接続がパケット・フローに対して望まれるとＰＤＳＮが決定するのであれば、ＰＤＳＮは、ＲＮへＡ１１登録更新（ＲＵＰ）メッセージを送って、新たなＡ１０接続を要求する。メッセージは、ＭＳとの適切なＳＯを確立するようにＲＮをトリガする指示を伝える。メッセージは、しかも、ＳＯ確立の際に必要とされるはずのＱｏＳパラメータも伝えることができる。

１１．ＲＮがＰＤＳＮによって要求された新たなＡ１０接続をサポートできるのであれば、ＲＮは、Ａ１１登録受領通知（ＲＡＣＫ）メッセージを用いて応答する。

１２．ＲＮは、コール割当メッセージを介してＭＳへＡ１１シグナリング・メッセージにおいて指定されたＳＯを接続しようと試みる。

１３．ＲＮと移動体は、サービス取り決めを実行して、ＳＯについて合意する。この例では、ＭＳは、ヘッダ削除モードを指定しているＳＯ６２を要求する。

１４．ＲＮは、ＳＲ＿ＩＤを割り当てて、ＳＯ６２を接続する。表５は、ＲＮ確立を示す。

１５．ＲＮは、Ａ１１ＲＲＱを送って、新たなＡ１０接続を確立する。Ａ１１ＲＲＱメッセージにおいて、ＲＮは、しかも、ＳＲ＿ＩＤ及び無線を介して接続されるサービス・オプションも指示する。

１６．ＰＤＳＮは、Ａ１１ ＲＲＰを用いて応答する。新たなＡ１０接続の良好な確立とともに、ＰＤＳＮは、新たに確立されたＡ１０接続をＲＳＶＰメッセージのフィルタ・スペックから取得された順方向パケット・フィルタと関連付ける。この時点で、ＰＤＳＮは、主サービス・インスタンス及び補助サービス・インスタンスの両者に対してパケット・フィルタを確立することができる。この場合には、ＰＤＳＮは、最初に補助サービス・インスタンスにパケット・フィルタを適用するはずである。

１７．ＰＤＳＮは、ＳＲ＿ＩＤとＩＰフローの結合を指示しているＭＳへＰＰＰ（主サービス・インスタンス）を介してＭＣＦＴＰ要求を送る。

１８．ＳＯ６２（ＬＬＡＲＯＨＣヘッダ削除モード）がこの例では使用されているので、ＭＳは、ＳＲ−スタティック情報を指示しているＰＤＳＮへＭＣＦＴＰ応答を送る。

１９．ＩＰパケットは、アプリケーションとＣＮとの間で流れ始めることができる。

ＲＯＨＣに関するフロー・マッピング及び処理法のコール・フローは、ＬＬＡＲＯＨＣと同様である。違いは、コンテクストＩＤ（ＣＩＤ）が各ＲＯＨＣパケットに含まれており、その結果、受信側がＣＩＤを介してＩＰフローを区別できるので、ＭＣＦＴＰが必要ないことである。

図８は、ＲＯＨＣに関する対応するノード（ＣＮ）によって生成されようとしているパケット・フローに関するフロー処理法及びマッピングを、ＰＤＳＮ及びＭＳが、どのようにして決定するかを説明する。始めのステップ１からステップ９は、図７に示されたものと同様であることに、注意する。以下の説明は、図８のステップ１０から始まる。

１０．新たなＡ１０接続がパケット・フローに対して必要であることをＰＤＳＮが決定するのであれば、ＰＤＳＮは、ＲＮへＡ１１登録更新（ＲＵＰ）メッセージ送って、新たなＡ１０接続を要求する。このメッセージは、ＭＳと適切なＳＯを確立するためにＲＮをトリガする指示を伝える。メッセージは、しかも、ＳＯ確立の際に必要であり得る、サービスの品質（ＱｏＳ）パラメータも伝えることができる。

１１．ＲＮがＰＤＳＮによって要求された新たなＡ１０接続をサポートできるのであれば、ＲＮは、Ａ１１登録受領通知（ＲＡＣＫ）メッセージを用いて応答する。

１２．ＲＮは、コール割当メッセージを介してＭＳへＳＯ３３を接続しようと試みる。

１３．ＲＮは、ＳＲ＿ＩＤを割り当てて、移動体へＳＯ３３を接続する。

１４．ＲＮは、Ａ１１ＲＲＱを送って、新たなＡ１０接続を確立する。このメッセージにおいて、ＲＮは、同様に、ＳＲ＿ＩＤ及び無線を介して接続されるサービス・オプションも指示する。

１５．ＰＤＳＮは、Ａ１１ ＲＲＰを用いて応答する。新たなＡ１０接続の良好な確立とともに、ＰＤＳＮは、新たに確立されたＡ１０接続をＲＳＶＰメッセージのフィルタ・スペックから取得された順方向パケット・フィルタと関連付ける。この時点で、ＰＤＳＮは、主サービス・インスタンス及び補助サービス・インスタンスの両者に対してパケット・フィルタを確立することができる。この場合には、ＰＤＳＮは、最初に補助サービス・インスタンスにパケット・フィルタを適用するはずである。

１６．ＭＳ及びＰＤＳＮの両者は、副ＳＯ３を介してＩＲ（開始及びリフレッシュ）パケットを送る。

１７．ＩＰパケットは、アプリケーションとＣＮとの間を流れることができる。

ＬＬＡ−ＲＯＨＣに関して、ＭＣＦＴＰは、いくつかの利点を与える。ＰＤＳＮは、パケット・フィルタ及びＳＲ＿ＩＤの結合をＭＳへ伝えるためにＭＣＦＴＰを使用する。ＭＣＦＴＰに対するニーズは、下記のＴＥ−ＭＴ（端末装置−移動体端末）の例に説明される。何らかの理由で、ＴＥ（例えば、ラップトップ）は、それぞれがＥＶＲＣを使用している、２つのＩＰを介した音声（ＶｏＩＰ）セッションを同時に確立することを望むことがある。ＭＴ（例えば、ネットワーク−モデル・ハンドセット）は、両方のＶｏＩＰフローに関するパケット・フィルタ情報を含むＲＳＶＰメッセージをスニフできるけれども、ＰＤＳＮが結合についてＭＴに通知するためにＭＣＦＴＰを使用しない限りは、ＭＴは、パケット・フィルタとＳＲ＿ＩＤとの間の結合を知らない。注：この例では、ＥＶＲＣを使用する両方のＶｏＩＰセッションに関するＲＳＶＰパラメータは、ＭＴには全く同じに見えるはずである。

ヘッダ削除モードの場合には、ＭＳは、ＰＤＳＮへ“全ヘッダ”情報を伝えるためにＭＣＦＴＰを使用する必要がある。ＬＬＡ−ＲＯＨＣは、リンク・レイヤが補助するヘッダ圧縮であることに、注意する。付け加えると、ヘッダ削除モードは、３ＧＰＰ２に固有のモードである；それゆえ、オペレーションを補助するために３ＧＰＰ２に固有なリンク・プロトコル（単純化されたＭＣＦＴＰ）を生成することは問題ではない。

ＲＯＨＣに関して、ＴＥが２つのリアル・タイム・セッションを同時に確立することを望む場合でさえ、ＭＣＦＴＰは必要ない。例えば、０−バイト・ヘッダ圧縮の利点を利用することができない非−ＣＤＭＡコーデックを使用することである。ＲＳＶＰパラメータに基づいて、ＲＳＶＰメッセージをスニフするＭＴは、２つのリアル・タイム・セッションが同様の無線ＱｏＳを必要とするか否かを知るはずである。この例は、下記の２つの場合をさらに考慮する：
１．セッションが同様な無線ＱｏＳを必要とするのであれば、１つの副ＳＯ３３だけが、両方のフローに対して必要であり、そしてＭＴは、副ＳＯ３３に対応する同じＳＲ＿ＩＤにフローのパケット・フィルタをマッピングすることが可能である。ＲＳＶＰパラメータに基づいて、ネットワーク側は、ＰＤＳＮがトリガする際にＲＡＮが両方のフローに対して１つの副ＳＯ３３を確立することに帰結する同じ結論を下すはずである。ＲＯＨＣの初期化の間に、ＭＴは、ＰＤＳＮへ（副ＳＯ３３を介して）ＲＯＨＣ ＩＲパケットを送り、そして各フローに関するヘッダ圧縮状態は、ＣＩＤによって識別される。

２．セッションが異なる無線ＱｏＳを必要とする（例えば、一方はＲＬＰ再送信を必要とせず、一方が１に等しい最大再送信を用いるＲＬＰ再送信を必要とする）のであれば、２つの副ＳＯ３３が必要である。ＭＴは、ＲＳＶＰパラメータに基づいて、どのＩＰフローがどの副ＳＯ３３に送られるべきであるかを知る；そのようにして、ＭＴは、パケット・フィルタとＳＲ＿ＩＤとの間の結合を知る。ＲＯＨＣ初期化の間に、ＭＴは、適切な副ＳＯ３３において各リアル・タイム・セッションに関するＲＯＨＣ ＩＲパケットを送り、そして、ＩＲパケットは、対応するＡ１０接続においてＰＤＳＮによって受信される。ＩＲパケットは、パケット・フィルタ情報を適切なＡ１０接続と結合するためにＰＤＳＮにとって十分なパケット・フィルタ情報を有する。

（ＵＤＰデータグラムの代わりに）ＰＰＰフレームは、ＭＣＦＴＰに対して推奨され、レイヤリング原理に基づく。ＭＣＦＴＰの使用は、下記を伝える：ｉ）パケット・フィルタとＳＲ＿ＩＤとの間の結合；及びｉｉ）ＬＬＡ−ＲＯＨＣヘッダ削除モードが使用される場合に、“全ヘッダ”情報。ＭＣＦＴＰがリンク・レイヤに関係する情報を伝えるために使用されるので、ＭＣＦＴＰは、リンク・レイヤ（例えば、ＰＰＰ）において搬送されるはずである。ＭＣＦＴＰを搬送するためにＵＤＰを使用することは、率直に言って、“レイヤ違反”であり、厳密に言って推奨されない。ここに説明される方法は、既存のＲＳＶＰパラメータ（フロースペック及びフィルタ・スペック）を頼りにして、ＰＤＳＮにおいてパケット・フィルタを確立する。ＥＶＲＣコーデックに関するトークン・バケット・パラメータを設定する一例が、下記に列記される：
・ バケット深さ＝１（ソースは一定のビット・レートである）
・ ピーク・レート＝（１７６ビット／全レート・フレーム）＊（５０全レート・フレーム／秒）＋（３２０ＩＰオーバーヘッド・ビット／フレーム）＊（５０フレーム／秒）＝２４．８ｋｂｐｓ
・ 最大パケット・サイズ＝１７６ビット＋３２０オーバーヘッド・ビット＝４９６ビット
既存のＲＳＶＰパラメータは、ＰＤＳＮにおいてパケット・フィルタを確立するために十分である。ここに説明された方法は、レイヤリング違反がなく非常にクリーンである。さらに標準ＲＳＶＰオブジェクト及び動作様式が、いずれかの３ＧＰＰ２−固有のＲＳＶＰオブジェクトを必要とせずに、使用される。単純化されたＭＣＦＴＰは、リンク・レイヤが補助する０バイト・ヘッダ圧縮に限定されるだけである。この単純化されたＭＣＦＴＰは、ＭＳ及びＰＤＳＮの両者にとって実行することが容易である。本方法がＳＯの確立を開始するため及び移動体とネットワークとの間のサービス構成を取り決めるためにネットワークを信頼するので、本方法は、ラップトップと移動体端末との間に特別なアプリケーション・プログラミング・インターフェース（ＡＰＩ）を必要としない。ＭＣＦＴＰモジュールとＬＬＡＲＯＨＣモジュールとの間のインターフェースが、ＴＦＴ（トラフィック・フロー・テンプレート）及びＳＲ＿ＩＤの情報を伝える必要があるとはいえ、移動体端末によって全体として制御されることができる。

この分野に知識のある者は、情報及び信号が、各種の異なる技術及び技法いずれかを使用して表されることを、理解するはずである。例えば、上記の説明全体を通して参照されることができる、データ、指示、命令、情報、信号、ビット、シンボル、及びチップは、電圧、電流、電磁波、磁場又は磁力粒子、光場又は光粒子、又はこれらの任意の組み合わせによって表わされることができる。

この分野に知識のある者は、ここに開示された実施形態に関連して説明された各種の例示的な論理ブロック、モジュール、回路、及びアルゴリズムのステップが、電子ハードウェア、コンピュータ・ソフトウェア、又は両者の組み合わせとして実装され得ることを、さらに認識するはずである。ハードウェア及びソフトウェアのこの互換性をはっきりと説明するために、各種の例示的なコンポーネント、ブロック、モジュール、及びステップが、それらの機能性の面から一般的にこれまでに説明されてきた。そのような機能性が、ハードウェア又はソフトウェアとして実装されるか否かは、固有のアプリケーション及びシステム全体に課せられた設計の制約に依存する。熟練した職人は、各々の固有のアプリケーションに対して違ったやり方で説明された機能性を実行することができるが、そのような実行の決定は、本発明の範囲から逸脱すること生ずるとして説明されるべきでない。

ここに開示された実施形態に関連して述べられた、各種の解説的な論理ブロック、モジュール、及び回路は、汎用プロセッサ、ディジタル・シグナル・プロセッサ（ＤＳＰ）、アプリケーション・スペシフィック集積回路（ＡＳＩＣ）、フィールド・プログラマブル・ゲートアレイ（ＦＰＧＡ）又は他のプログラマブル・ロジック・デバイス、ディスクリート・ゲート又はトランジスタ・ロジック、ディスクリート・ハードウェア・コンポーネント、又はここに説明した機能を実行するために設計されたこれらの任意の組み合わせで、実装又は実行されることができる。汎用プロセッサは、マイクロプロセッサであり得るが、代案では、プロセッサは、いずれかの従来のプロセッサ、コントローラ、マイクロコントローラ、又はステート・マシン(state machine)であり得る。プロセッサは、演算デバイスの組み合わせとして実装されることができる。例えば、ＤＳＰとマイクロプロセッサとの組み合わせ、複数のマイクロプロセッサの組み合わせ、ＤＳＰコアと結合した１又はそれより多くのマイクロプロセッサ、又はいずれかの他のそのような構成であり得る。

ここに開示された実施形態に関連して説明された方法又はアルゴリズムのステップは、ハードウェアにおいて直接に、プロセッサにより実行されるソフトウェア・モジュールにおいて、又は、両者の組み合わせにおいて実現されることができる。ソフトウェア・モジュールは、ＲＡＭメモリ、フラッシュメモリ、ＲＯＭメモリ、ＥＰＲＯＭメモリ、ＥＥＰＲＯＭメモリ、レジスタ、ハード・ディスク、脱着可能なディスク、ＣＤ−ＲＯＭ、又は、この分野で知られている他のいずれかの記憶媒体の中に存在することができる。ある具体例の記憶媒体は、プロセッサに接続され、プロセッサは、記憶媒体から情報を読み出し、そこに情報を書き込めるようにする。代案では、記憶媒体は、プロセッサに集積されることができる。プロセッサ及び記憶媒体は、ＡＳＩＣ中に存在することができる。ＡＳＩＣは、ユーザ端末中に存在することができる。代案では、プロセッサ及び記憶媒体は、ユーザ端末中の個別コンポーネントとして存在することができる。

開示された実施形態のこれまでの説明は、本技術分野に知識のあるいかなる者でも、本発明を作成し、使用することを可能にすることを提供する。これらの実施形態に対する各種の変形は、本技術分野に知識のある者に、容易に実現されるであろう。そして、ここで規定された一般的な原理は、本発明の精神又は範囲から逸脱しないで他の実施形態にも適用されることができる。それゆえ、本発明は、ここに示された実施形態に制限されることを意図したものではなく、ここに開示した原理及び新規な特性と整合する広い範囲に適用されるものである。

Claims (25)

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. 無線通信デバイスにおいて追加のサービス・インスタンスを受信するための方法、前記方法は：
    第１のサービス・オプションを確立すること；
    前記第１のサービス・オプションと同時に第２のサービス・オプションを要求すること；
    第２のサービス・オプション接続を識別するメッセージを受信すること；
    前記第２のサービス・オプション接続を確立すること；及び
    前記第１及び第２のサービス・オプション接続を介して通信すること、
    を具備する方法。

Images