JP2005529554A - 通信システムにおけるパケットフロープロセシング - Google Patents

Abstract

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

Description

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

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

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

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

用語“イグゼンプラリ”は、 “例、事例、若しくは実例として取り扱われること”を意味するためにここで使用される。“イグゼンプラリ“としてここで説明されたいずれかの実施形態が、他の実施形態に対して好ましい若しくは優位であるとして解釈される必要性はない。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ＲＳＶＰ ＱｏＳ要求を満足させるための詳細なルールは、各インターフェースにおいて使用されている固有のリンクレイヤ技術に依存する。単純なリースされたラインに関して、所望のＱｏＳは、例えば、リンクレイヤドライバ中のパケットスケジューラから取得される。リンクレイヤ技術が、自分自身のＱｏＳ管理可能出力（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を有するインターネットエンジニアリングタスクフォースにより発行された、Ｒ．ローゼンベルグら著の“ＳＩＰ：セッションイニシエーションプロトコル”；及び１９９９年３月付け、文書番号第ＲＦＣ２５４３を有するネットワークワーキンググループによって発行された、Ｍ．ハンドレイら著の“ＳＩＰ：セッションイニシエーションプロトコル”にも詳細に説明されていることに、注意する。

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

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

ステップ３において、ＰＤＳＮは、ＭＳネットワークアクセスアイデンティファイア（Network Access Identifier）（ＮＡＩ）及び信任状を含んでいるＡＡＡへアクセス要求（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））によってなされる。マッピングがＰＣＦによって実施されるならば、既存のＡ９−ＢＳサービス要求メッセージに変化がない。マッピングがＢＳにおいて実施されるならば、ＰＣＦは、Ａ９−ＢＳサービス要求メッセージにおいてＢＳに対して適用されたヘッダ圧縮アルゴリズムを指示する。例えば、マッピングテーブルは、下記のように明記される可能性がある：

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

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

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

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

ステップｇにおいて、ＢＳは、無線インターフェースのトラフィックチャネルを介して通話指定メッセージを送る可能性があり、ＣＣステートマシーン（通話制御ステートマシーン）の確立を開始する。

ステップｈにおいて、ＢＳは、追加のサービスオプション接続を呼び出すために、ＭＳへ下記の１つを送る：ｉ）サービス接続メッセージ；ｉｉ）通常ハンドオフ管理メッセージ；若しくはｉｉｉ）普遍的なハンドオフ管理メッセージである。

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

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

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

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

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

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

ＰＤＳＮは、システムによりサポートされているとしてメッセージを使用することによって新たなＡ１０接続の追加に関する要求を開始する可能性がある。ＰＤＳＮは、ＰＣＦへＡ１１−登録更新メッセージを送って、新たなＡ１０接続の追加を要求する。ＰＤＳＮは、‘新たな接続を追加（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）（ＮＡＩ）及び信用証明書を含んでいるＡＡＡへアクセス要求を送る。信用証明書は、（単純ＩＰが使用されるのであれば）ＣＨＡＰ若しくは（モービルＩＰが使用されるのであれば）ＦＡチャレンジに応答して移動体によって算出された暗号認承メッセージである。

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

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

表４．ユーザ申込みプロファイル情報

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

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

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

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

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

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

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

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

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

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

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

１２．ＲＮは、通話指定メッセージを介してＭＳへＡ１１シグナリングメッセージ中に明記されたＳＯを接続しようと試みる。

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

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

表５．ＲＮ確立情報

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

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

表６．パケットフィルタに関する指定

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

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

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

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

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

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

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

１２．ＲＮは、通話指定メッセージを介してＭＳへＳＯ３３を接続しようと試みる。

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

表７．ＲＮ確立

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

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

表６．パケットフィルタ情報

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

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

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

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

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

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

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

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

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

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

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

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

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

符号の説明

１００…通信システム，４００…通信システム，４２０…通信バス，４８０…通信バス，５００…ＭＳ，５１０…アンテナ，５６０…通信バス。

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