JP4509112B2 - 移動局とｉｐネットワーク間におけるインタフェースでのサービス品質サポート - Google Patents

Description

本発明は一般に、ＤｉｆｆＳｅｒｖアーキテクチャを用いるネットワークノード間でのデータの優先順位に関する。特に、複合型ＣＤＭＡ２０００／３ＧＰＰ２ネットワークにおいて無線ノードとパケットデータ交換ノードでの、異なるデータパケットのサービス品質を保証する方法およびシステムについて以下説明する。但し、別の複合型ネットワークに対して本発明を適用することも可能である。

データの型に従ってデータの優先順位を判定するネットワークアーキテクチャと関連して、本発明の範囲を限定することなく本発明の背景について説明する。（ＩＰを介する音声通話すなわちＶｏＩＰ、ストリーミングビデオ、ｅ−コマースなどの）異なる型のデータに対してインターネットプロトコル（ＩＰ）が（移動電話、固定電話、仮想私設電話などの）異なるサブネットワークの両端にわたって至る所で利用されるようになるのに伴い、ネットワーク全体の異なる部分やノード間をデータが移動する際、異なる型のデータ処理を行って最小限のサービス品質の達成を図る必要性が生じてくる。従来のＩＰがパケット配信用としてベストエフォートによるアプローチを行うものであったのに対して、移動通信ネットワークは最小ビットエラー率に依拠するものとなる。異なるサブネットワーク間での信頼性を保証するために２つの処方すなわちＩｎｔＳｅｒｖとＤｉｆｆＳｅｒｖとが利用されている：ＩｎｔＳｅｒｖでは、ネットワーク経路のエンドノードが、その特定のＱｏＳの必要性を示すシグナリングをネットワークに対して行う組込み型サービスが行われ、ＤｉｆｆＳｅｒｖでは、データパケットがクラス情報を運び、このクラス情報をネットワークノードが利用して、適用可能なＱｏＳの判定を行うようにする差別化サービスが行われる。効率のよいネットワークでは異なるＱｏＳが必要となる。というのは、（異なる型のデータパケットなどの）様々なアプリケーションが、遅延時間、ジッタ、パケットロス、変動および別のＱｏＳメトリックに対する変動するニーズを有しているからである。例えば、ＶｏＩＰが非常に低いジッタ（約１００ミリ秒の一方向ジッタ）と、約８〜６４Ｋｂｐｓの間の帯域とを必要とするのに対して、ファイル転送用アプリケーションは、一般にジッタを被ることはないが、パケットロスによる破損を非常に受けやすい。サービス品質を保証することによって、ネットワーク通信事業者は、従来のインターネットプロトコル（ＩＰ）ネットワーク経路でのベストエフォートによるパケットリレーだけでなく、高い信頼性を要求する顧客に対して差別化された値付けを行うことがさらに可能となる。

本発明はＤｉｆｆＳｅｒｖに関する発明であるが、ＤｉｆｆＳｅｒｖの一般的アーキテクチャは、ネットワークの中に入って来る（データパケットなどの）トラフィックを類別し、おそらくネットワークを経由するデータパスウェイのバウンダリすなわちエッジルータ'において（マーキング、メトリック、ポリシ、シェイピングなどによる）条件付けを行い、異なるビヘイビアのアグリゲートに割り当てを行うという一般的コンセプトに基づくものである。個々のビヘイビアのアグリゲートは単一の差別化サービスコードポイント（ＤＳＣＰ）によって特定されるが、この差別化サービスコードポイントは個々のパケットのヘッダ内に在るビットストリーム（一般に６ビット）である。ネットワークのコア（データパスウェイのエッジ'に存在しない内部ノード）内では、ＤＳＣＰに関連する“ｐｅｒ−ｈｏｐ”ビヘイビア（ＰＨＢ）に従ってパケットの転送が行われる。ｐｅｒ−ｈｏｐビヘイビアはしきい値を表し、パケットはこのしきい値の範囲内でネットワークノード間を移動するが、上記しきい値は、例えば遅延時間、ジッタ、帯域などの制限を表わす値であり、競合するトラフィックストリーム間の個々のノードでバッファ資源と帯域資源とを割り当てるために利用する値である。パケットマーキングを用いて明確に規定されたＰＨＢを利用して、所定の任意のパケットに対するスケーラブルなＱｏＳソリューションを達成することができる。次いで、ＤｉｆｆＳｅｒｖでは、ＱｏＳに対するシグナリングは少なくともネットワークコア内では不要となる。そのため、個々のネットワークノードで保持する必要があるパケット状態の数は著しく減少することになる。例えば、内部ルータやノードは、一時パケットに対してアプリケーション毎のフロー状態や顧客毎の転送状態を追跡する必要はなくなる。この結果、最終的に、ＤｉｆｆＳｅｒｖでは、複雑さがネットワークのエッジまで押しやられて、（典型的にはさらに多数の）コアルータやノードがシンプルかつ高速に保持されることになる。

ＤｉｆｆＳｅｒｖドメイン内のエッジルータはトラフィック方向に応じてイングレスノードまたはエグレスノードとも命名される。図１はＣＤＭＡ２０００／３ＧＰＰ２との複合型ネットワーク２０の従来技術による概観を描く図であり、この複合型ネットワーク２０ではＤｉｆｆＳｅｒｖアーキテクチャの利用が可能である。３ＧＰＰ２プロトコルが採用されているような移動通信ネットワーク２２は、ＲＮ２４の制御下にある移動局ＭＳ２６からのアップリンクトラフィック用イングレスノードとして機能する無線ノードＲＮ２４（基地局ＢＳなど）を備えている。ＭＳからの第１のメッセージ２８はＲＮ２４を通過してパケットデータ交換ノード（ＰＤＳＮ）３０へ達する。ＰＤＳＮ３０を出るとすぐに、パケットは、ＣＤＭＡ２０００のネットワーク３２内のルータおよび別のノードが、個々にパケットを開く'ことなく、このパケットの送信を或る一定の品質で実施可能にする属性を担持し、この所望の品質を満たすのに必要な適切な経路の判定を行う必要がある。ＩＰベースのネットワーク３２からＭＳ２６への第２のメッセージ３４の場合、ＰＤＳＮ３０はエグレスノードとして機能する。ＩＰベースのネットワーク３２によって利用され、それによって品質判定基準を満たすようにする（ホップビヘイビア毎などの）手段は、一般に移動通信ネットワーク２２に対して直接適合性のあるものではない。ＲＮ２４とＰＤＳＮ３０間でのインタフェースは一般にＲ−ＰネットワークあるいはＲ−Ｐインタフェースと命名されている。Ｒ−Ｐインタフェースが作動して、さらに広域のネットワーク３２と移動ネットワーク２２との間でＤｉｆｆＳｅｒｖの容易化を図るという広いコンセプトが現在存在するが、サービスインスタンスのダウンリンクトラフィックが以下説明する１つのフローを運ぶこと以外には、このような機能性の実現方法に関する具体的な詳細を本願発明者らは知らない。

現在の３ＧＰＰ２標準化［３ＧＰＰ２Ｐ．Ｓ０００１Ｃ．４］では、マッピング処理と、フロー処理とが導入され、特定のダウンリンクフローをサービスインスタンスにマップするようになっている。メインのサービスインスタンスは１つのＲ−Ｐ接続を表し、このサービスインスタンスは、Ｒ−Ｐ接続の初期化時に一意の識別子（ＳＲ＿ＩＤ）によって特定される。３ＧＰＰ２仕様［３ＧＰＰ２Ｘ．Ｓ００１１−００４−Ｃ、ｖｅｒ．１．０、２００３年８月；セクション３および３．２以下参照］に記載のように、メインのサービスインスタンスに加えて、ＭＮ２６はメインのサービスインスタンスと同じＲ−Ｐ接続または異なるＲ−Ｐ接続時に１以上の補助サービスインスタンスを開いて、メインのサービスインスタンスに適していないトラフィックを運ぶようにすることが可能である。典型的には、メインのサービスインスタンスを利用して、ＭＳ２６とＰＤＳＮ３０間で接続の初期化と更新とを行うシグナリングを運び、メインのサービスインスタンスと関連する異なる補助サービスインスタンスを利用して（ストリーミングビデオ、電子メールなどの）異なる型のデータを運ぶことになる。（好適には補助）サービスインスタンスは複数のフローを運ぶものであってもよく、フローがプロトコル層の或る特定手続き（specific instantiation）のシーケンスであって、上記フロー上のパケットはこの特定手続きのシーケンスを介してトランスポートされる。補助サービスインスタンスを効果的に利用するために、ＰＤＳＮ３０はパケットフィルタに関する情報を受ける必要がある。パケットフィルタとは、どのパケットをどのサービスインスタンスで送るべきかについてのマッピングを行うためにＰＤＳＮ３０が利用する情報である。トラフィックフローテンプレート（ＴＦＴ）は、１つのサービスインスタンスをサポートするためにＭＳが送るテンプレートであるが、このＴＦＴは、（ＭＳ２６がホームネットワークと外部ネットワークとの間を移動するにつれて、上記ＩＰアドレスの変更も可能である）ＭＳ ＩＰアドレス、並びに、パケット宛先ＩＰアドレスとポート番号およびプロトコルタイプとサービスタイプのような（但しこれらのみに限定されるものではない）パケットフィルタコンポーネントを運ぶものである。１つのＴＦＴは（ＳＲ ＩＤによって特定される）１つのサービスインスタンスに対応し、このＴＦＴによって、ＰＤＳＮ３０は異なるタイプのパケットを異なる補助サービスインスタンスに置くことが可能となる。

上述のフローマッピング機構は、ダウンリンクパケットのみを特定の補助サービスインスタンスにマップする能力を持っているように思われる。さらに、上記フローマッピング機構では、上記サービスインスタンスにおいて特別のフローをどのようにすれば識別できるかについての説明がなく、ダウンリンクパケットのみがサービスインスタンスにマップされるため、上記サービスインスタンスでのすべてのフロー（２以上のフローの場合）によってパケット品質が保証されている場合にのみ、上記フローマッピング機構は作動可能となるように思われる。１つの文書ドキュメント［ＴＲ４５：ＣＤＭＡ２００アクセスネットワークインタフェース−第２部”（ＰＮ−４５４５．２−ＲＶ３、Ｂａｌｌｏｔバージョン２００２年１０月）用の相互運用仕様書（ＩＯＳ）には、サービスプロバイダによって規定された無線アクセスネットワークポリシまたはローカルなポリシをＲＮとＰＤＳＮとによって利用して、アップリンクトラフィックとダウンリンクトラフィックのマーキングと条件付けを行うようすることができる旨が概括的に述べられているが、この相互運用仕様書（ＩＯＳ）には、上記を行う機構は規定されていない。従来技術では、移動通信ネットワークにおけるサービス品質を保証するために、サービスインスタンスに対するダウンリンクパケットのみのマッピングが特に記載されているにすぎず、同じサービスインスタンスで異なるパケット品質のフローを作動できるようには思われない。当業において必要とするものは、Ｒ−Ｐインタフェース側でＤｉｆｆＳｅｒｖアーキテクチャにおけるサービス品質を実現して、アップリンクトラフィックとダウンリンクトラフィックの双方のトラフィックで品質を保証する方法であり、この品質は、好適には、同じサービスインスタンスのフロー間で異なるものであってもよいことが望ましい。

本発明は１つの態様では、接続部内におけるフローの確立方法である。本方法は、無線ネットワークノードにおいて第１の要求メッセージを受け取るステップを含むものである。上記第１の要求メッセージは、上記フロー用の少なくとも１つの品質パラメータを含む。さらに、本方法には複数のサービス品質パラメータを許可するステップが含まれる。本方法は、１以上の許可されたサービス品質パラメータを含む第２の要求メッセージを上記無線ネットワークノードから送るという点で引き継がれる。上記第２の要求メッセージは、上記第１の要求メッセージで用いられる上記少なくとも１つのサービス品質パラメータと同じものであってもよい。好適には、上記無線ネットワークノードが無線ノードであり、接続部が上記無線ネットワークノードとＰＤＳＮのような別のノードとの間に在ることが望ましい。

別の態様では、本発明は、１つのフローにおいて、無線ノードとパケット交換データノードとの間で保証された品質を可能にするために利用できるシグナリングプロトコルである。上記無線ノードは上記フロー用の少なくとも１つのサービス品質パラメータを含む要求を移動局から受け取る。続いて、上記無線ノードは上記フロー用の１組のサービス品質パラメータの許可を上記移動局へ送る。上記無線ノードは上記フロー用の許可された１組のサービス品質パラメータを含む登録要求をパケットデータ交換ノードへさらに送る。次いで、上記無線ノードは上記フローを認可する旨の登録返信を上記パケットデータ交換ノードから受け取る。

さらに別の態様によれば、本発明は、受信機、コントローラおよび送信機を有する、無線基地局のような無線ネットワークノードである。上記受信機はフロー用の少なくとも１つのサービス品質パラメータを接続部内に含むＱｏＳパラメータ要求メッセージを受信する受信機である。上記コントローラは上記受信機と結合され、少なくとも上記基地局と上記移動局との間で上記１組の少なくとも１つの品質パラメータを満たすフローを運ぶサブジェクト接続が、前から存在する接続であるか、新規の接続であるかを判定するコントローラである。上記送信機は、上記のように判定を行うコントローラの判定に応答して、サービス接続許可メッセージを上記移動局へ送信するコントローラと結合される。

添付図面と共に以下の説明を参照することによって、本発明の実施形態の上記およびその他の特徴、態様並びに利点が明らかになる。しかし、図面は単に例示を目的として設計されたものであり、本発明を限定するものとして設計されたものではないことを理解されたい。

以下の図面を参照しながら本発明について以下さらに詳細に説明する。明記した場合を除いて、これらの図面はスケーリングを施したものではない。

上記背景説明に加えて、従来技術には、２以上のフローがサービスインスタンスに存在する場合、パケットがどのフローによってトランスポートされるかを判断する能力がなく、補助サービスインスタンスの内部で異なるフローのＱｏＳ要件を取得するためのＰＤＳＮ３０向けの機構が設けられていないように思われる。単に個々のフロー用のサービスインスタンスを追加するのではなく、本発明は、個々の（好適には補助）サービスインスタンス内で複数のフローを作動可能にし、より少数のＲ−Ｐ接続と、（過剰Ｒ−Ｐ接続の確立と維持を行うためのより少数のシグナリングに起因して生じる）利用可能な帯域のさらに好適な利用とを移動通信ネットワーク２２において結果として得ることを意図するものである。Ｒ−ＰインタフェースにおいてＤｉｆｆＳｅｒｖベースのＱｏＳを提供するために、エッジルータ（パケット類別、マーキング、メトリック、ポリシおよびシェイピングなど）向けのＤｉｆｆＳｅｒｖの機能性をＲＮ２４とＰＤＳＮ３０とにおいて実現することが望ましい。これらの機能を実現するために、本発明は、ＲＮ２４とＰＤＳＮ３０とにおいてすべてのサービス品質（ＱｏＳ）関連情報をリレーするおよび／または構成するためのシグナリング機構を提供するものである。

本発明は、アップリンクトラフィックとダウンリンクトラフィックとのためのいくつかの分散によって、ＤｉｆｆＳｅｒｖネットワークのイングレスノードとエグレスノード間でのトラフィックフロー管理を可能にするための改善された方法およびシステムを提示するものである。個々のアプローチには、ＲＮ２４とＰＤＳＮ３０とにＱｏＳ要件を提供して、フロー内におけるパケット品質を保証する移動ノードすなわち移動局ＭＳ２６が含まれる。好適には、記載の別個の各実施形態において、（ＴＩＡ／ＩＳ−７０７−Ａ−３に規定されているような）“ＱｏＳ＿ＢＬＯＢ”のような周知のフォーマットを使用するリンクレベルで、あるいは、拡張ダイナミックフローマッピング機構を介してＩＰレベルでＱｏＳ要件のシグナリングを行うことが望ましい。また、ＲＮ２４とＰＤＳＮ３０とにおいて上記のようなＱｏＳ情報を利用して、Ｒ−Ｐインタフェースと外部ネットワーク３２とへＱｏＳサポートを提供する方法に関する具体的な詳細についても説明する。

本発明の特定の実施形態の利用および実施構成を以下詳細に提示するが、多種多様の状況で具現化できる多くの発明概念が発明によって提供されることを理解されたい。本願明細書で解説される具体的な実施形態は、本発明を実施し、利用するための実施形態であって、本発明を限定するものではない実施形態として役立つものであり、本発明の範囲や以下の請求項の限定を意図するものではない。

図２はＭＳ２６と、ＲＮ２４と、ＰＤＳＮ３０との間でシグナリングを行う方法を示す図であり、この方法によっていくつかの周辺機器によってＰＤＳＮ３０と、認証／認可／課金ノード（ＡＡＡ）３６との間でシグナリングが行われる。ＡＡＡ３６は一般に、特定の補助サービスインスタンスが外部ネットワーク等を経由する経路選定を行う必要がある場合に、ＭＳがそのホームネットワーク領域から外へ移動する場合のような、ＭＳ２６がそのホームネットワークや協働する外部ネットワーク内で作動するための別々のサーバである。ＡＡＡ３６は特定のＭＳ２６を認証するように機能し、このＭＳ２６を認可してホームネットワークまたはホームネットワークがサービスレベルの合意ＳＬＡを結んでいる外部ネットワークのいくつかのサービスあるいはすべてのサービスを利用し、アクセスされたサービスを追跡し、別のメトリックを用いてＳＬＡやユーザ契約に基づいて支払い計算を行うものである。図２（図２Ａおよび２Ｂからなる）は本発明の好適な実施形態を表わす図である。

最初に、当業で周知のようにＭＳ２６とＰＤＳＮ３０とはメインのサービスインスタンスの設定３８を行う。この設定は、アップリンクトラフィック２８を開始する場合には、ＭＳ２６が開始するか、ダウンリンクトラフィック３４を開始する場合には、ＰＤＳＮ３０が基地局ＢＳ２４を介して開始することができる。ＰＤＳＮ３０は特定のＭＳ２６に関するアクセス要求４０をＡＡＡ３６へ発信する。ＡＡＡ３６は特定のＭＳ２６を認証し、さらに、ＭＳ２６が認可された場合、ＭＳ２６の加入者プロフィールを含む受入れメッセージ４２をＰＤＳＮ３０へ出力する。この加入者プロフィールはＭＳユーザに関連するサービス品質パラメータを含むものであってもよい。例えば、ＭＳユーザは、プレミアムユーザまたはゴールドユーザとなることができ、このようなユーザは、ネットワークサービス契約によって、ファイル転送用として最小限の信頼性が保証され、異なる型のデータに対して、デジタルビデオ放送（ＤＶＢ−Ｈ）の保証された品質での受信等の認可を受けることになる。これら異なる型のデータ間の品質は一般に、帯域（毎秒ビット）、最大パケット遅延時間（ミリ秒）および容認可能なパケットロス率（％）（但しこれらのみに限定されるわけではない）のようなＱｏＳパラメータとして反映される。ＱｏＳユーザ／加入者プロフィール内のＱｏＳパラメータは、ＤｉｆｆＳｅｒｖに対する微調整およびパケットトランスポート品質の上昇と共に変化と進化とを受ける対象となり、さらに、このＱｏＳパラメータは、移動通信ネットワーク２２における活動、（例えば、ユーザプロファイルによって、午前７時と午後７時との間で有効となる１つのＱｏＳおよび別の時点において有効となるさらに高いＱｏＳを提供するような）１日の時刻などに対応する変数であってもよいが、これらはすべて本発明から逸脱することのないものである。

メインのサービスインスタンスの確立３８後しばらくしてから、ＭＳ２６は特定のＱｏＳパラメータが関連したり、所望したりするデータフローを認知するようになる。例えば、ＭＳ２６は、電子メールテキストに添付するデジタル写真の送信準備を行ったり、デジタルビデオ放送の受信準備を行ったりすることができる。或いは、ＭＳ２６は無線アクセスネットワーク間を移動することができる。いずれの場合にせよ、ＭＳ２６は、確立したいフロー並びに個々のフロー用識別子を作成して、（例えば、デジタル写真のパケット用の１つのフローや、電子メールテキストのパケット用の別のフローなどの）関連データの送信を意図することになる。上記フロー用識別子をＭＳ＿ＦＬＯＷ＿ＩＤと命名する。ＭＳ＿ＦＬＯＷ＿ＩＤはフローが（ＩＥＴＦ）プロトコル層のある特定手続きを共有する一連のパケットであることを認識するものである。ＭＳ２６は、ＱｏＳパラメータ要求メッセージ４４をＲＮ２４へ送信するが、このＱｏＳパラメータ要求メッセージ４４にはＭＳが作成したデータフローと、新規フロー用識別子（ＭＳ＿ＦＬＯＷ＿ＩＤ）とに関連する少なくともＱｏＳパラメータが含まれる。好適には、これらのパラメータは従来技術で規定されているＱｏＳ＿ＢＬＯＢフォーマットのパラメータであることが望ましい。図２の例では、ＱｏＳパラメータメッセージ４４には、ＭＳ２６が作成したフローを運ぶ確立対象の新たなＲ−Ｐ接続を一意に特定するサービスインスタンス識別子（ＳＲ＿ＩＤ ｘ）が含まれている。例えば、要求されたパラメータがフローＭＳ＿ＦＬＯＷ＿ＩＤに対して毎秒ｍビットの最小限の帯域であると仮定する。メッセージ４４のＱｏＳパラメータが要求されていること、並びに、このパラメータが、ある特定のサービスインスタンス識別子（ＳＲ＿ＩＤ ｘ）およびＭＳ２６が作成した特定のフロー識別子（ＭＳ＿ＦＬＯＷ＿ＩＤ）と単一のメッセージ内で関連付けられていることは注目すべきことである。

要求したＱｏＳパラメータの受信に続いて、ＲＮ２４は受付制御４６を実行する。受付制御４６時に、移動通信ネットワーク２２が、例えばホームネットワークや外部ネットワークを介してＱｏＳ要求メッセージ４４に示されている品質を満たすことができるかどうかの判定がＲＮ２４によって行われる。２つのオプションを示す：メッセージ４８〜５０で新規サービスインスタンス（ＳＲ＿ＩＤ ｘ）を設定し、次いでメッセージ４８’−５０’で既存のサービスインスタンス（ＳＲ＿ＩＤ ｙ）を再構成する。

第１のオプションでは、ＲＮ２４側での受付制御４６によって、ネットワークファシリティが（ｍｂｐｓ最小帯域の場合などで）要求されるＱｏＳパラメータを満たすのに利用可能であることが判定され、ＳＲ＿ＩＤ ｘとして特定される新規サービスインスタンスが以下のように設定される。参照番号３８で確立されたメインのサービスインスタンスまたはＭＳ２６用の他の任意の既存のサービスインスタンスを、ＭＳが作成した新規フローのＱｏＳパラメータに適合させることができない場合、このオプションを実行してもよい。ＲＮ２４は、既存のサービスインスタンス（ＳＲ＿ＩＤ ｘ）用識別子と、ＱｏＳパラメータの許可（最小ｘｂｐｓ帯域など）と、ＭＳ２６と基地局２４間のトラフィック用無線リンク接続パラメータとを含むサービス接続メッセージ４８をＭＳ２６へ送信する。このメッセージ４８は、ＱｏＳ許可の適用先であるＭＳ２６が作成したフロー識別子も含むことが望ましい。このフロー識別子は図２ではＱｏＳ＿ＢＬＯＢフォーマットの形で固有のものである。

（Ａ１０接続などの）新たな接続の確立が必要となった場合、ＲＮ２４は登録要求メッセ−ジ５２の形でＰＤＳＮ３０と調整を行うが、この調整はサービス接続メッセージ４８およびサービス接続終了メッセージ５０と同時に行ってもよいし、あるいは、後続して行ってもよい。既存のインフラストラクチャ内でのレディアドプション（ready adoption）の場合、好適には登録要求メッセ−ジ５２がＡ１１メッセージのフォーマットであることが望ましい。本発明では、サービスインスタンス識別子（ＳＲ＿ＩＤ ｘなど）と、メッセージ４４と４８においてＭＳ２６とＲＮ２４間で事前に交換された要求されたＱｏＳパラメータと許可されたＱｏＳパラメータとのうちの少なくとも一方のパラメータ（好適には双方のパラメータ）の双方並びにＱｏＳパラメータが関係するフロー識別子が含まれている。ＰＤＳＮ３０は新規サービスインスタンス（ＳＲ＿ＩＤ ｘ）を認可し５４、登録要求５２のＱｏＳパラメータを満たすものとなる。この許可によってＱｏＳパラメータ要求は許可されることになる。というのは、ＭＳ２６が作成したフロー（ＭＳ＿ＦＬＯＷ＿ＩＤとして特定される）が上記新規サービスインスタンス内に存在するからである。認可される５４とすぐに、ＰＤＳＮ３０は登録返信メッセージをＲＮ２４へ送信し５６、要求したＱｏＳパラメータを満たす新規サービスインスタンス（ＳＲ＿ＩＤ ｘ）が確立された旨をＲＮ２４に通知する。

第２のオプションでは、ＲＮ２４は、既存のサービスインスタンス（ＳＲ＿ＩＤ ｙ）でフローを運ぶ旨の判定を受付制御４６側で行う。本例の場合、既存のサービスインスタンスは、ｙミリ秒の最大パケット遅延時間を可能にする補助サービスインスタンスであると仮定する。その場合要求されたＱｏＳパラメータはｘｂｐｓの最小帯域となる。ＲＮ２４は既存のサービスインスタンス（ＳＲ＿ＩＤ ｙ）のパラメータを要求のパラメータ（ｘｂｐｓ帯域など）へ再構成し、適用可能なサービスインスタンス識別子（ＳＲ＿ＩＤ ｙなど）と、ｘｂｐｓ帯域の許可と、ＭＳ２６と基地局２４間でのトラフィック用無線リンク接続パラメータとを含むサービス接続メッセージ４８’をＭＳ２６へ送信する。上記のように、ＭＳ２６が作成したフロー識別子もこのメッセージ４８’内に存在する。メッセージ４８〜５０と４８’'〜５０’および上記に記載のいずれかのオプションでは、ＭＳ２６はサービス接続終了メッセージ５０、５０'を用いて応答を行い、トラフィックチャネル無線リンクの確立を行う。

新たな接続が要求されず、既存の接続が再構成された場合、シグナリングは上記記載の場合と同様になるが、新たな接続を行う場合には以下の例外がある。ＲＮ２４からＰＤＳＮ３０への登録要求５２には、サービスインスタンス識別子（ＳＲ＿ＩＤ ｙなど）およびメッセージ４８’で事前にＭＳ２６へ送信された修正済みの許可されたＱｏＳパラメータ、並びに、ＱｏＳパラメータが関係するフロー識別子が含まれる。ＰＤＳＮ３０は、既存のサービスインスタンス（ＳＲ＿ＩＤ ｙ）を認可して５４、登録要求５２のＱｏＳパラメータを満たすようにする。認可される５４とすぐに、ＰＤＳＮ３０は登録返信メッセージ５６をＲＮ２４へ送信し、要求された（そして現在許可されている）ＱｏＳパラメータを満たすために既存のサービスインスタンス（ＳＲ＿ＩＤ ｙ）が修正された旨をＲＮ２４に通知する。

アップリンク２８またはダウンリンク３４でパケットが新規フローに沿って送信される前にシグナリングを終了するために、ＭＳ２６は、フロー識別子（ＭＳ＿ＦＬＯＷ＿ＩＤ）と、フロー方向（アップリンク２８またはダウンリンク３４）と、補助サービスインスタンス用フィルタパラメータとを運ぶ予約ＲＥＳＶメッセージ５８を送信する。ＲＥＳＶメッセージ５８はフィルタリングパケットに関する情報を運ぶため一般にフィルタメッセージと命名することができる。従来技術では、パケットフィルタパラメータは一般にトランスポートフローテンプレートＴＦＴフォーマットの形をとり、影響を受けたネットワークによるレディアドプション（ready adoption）用として本発明を継続することができる実施形態である。とはいえこのフォーマットは単独で本発明を限定するものではない。このＲＥＳＶメッセージ５８は、メインのサービスインスタンスの設定３８時に確立されたメインのサービスインスタンス上にあってもよいし、あるいは、新規フローの補助サービスインスタンス上にあってもよいが、ＲＥＳＶメッセージ５８は、どのパケットがどのフローの中へ入るか、その結果上記パケットが（ＩＰベースの）外部ネットワーク３２の内部ノードを経由してどのように移動するかをＰＤＳＮ３０に通知するメッセージである。例えば、（１つのサービスインスタンスまたは２つのサービスインスタンス内のいずれか）に２つのフロー（静止写真用として１つのフローおよびＩＰを介する音声通話用として１つのフロー）が設定された場合、ＲＥＳＶメッセージ５８は、パケットヘッダの中にあるどの差別化サービスコードポイント（ＤＳＣＰ）がどのフローの中へ入るかを特定することになる。単一のＴＦＴはマルチフローおよびマルチフィルタに関する情報を与えることができるが、その場合、２以上のフローが本ＭＳ２６に対してアクティブとなる。ＰＤＳＮ３０はＲＥＳＶ確認メッセージ６０を用いて応答を行う。この結果、最終的にＰＤＳＮ３０は、パケットヘッダのビットのみを用いて個々のパケットをある特定のフローにマップする情報を得ることになる。

例えば、上記のように、２つのフローが、１つのフローは静止写真用として、１つのフローはＶｏＩＰ用として設定されると想定する。ＤＳＣＰは６ビットであるため、ＤＳＣＰヘッダ内に値０１１１０１を持つパケットは第１のフローの中へ入るべきである旨が、ＭＳ２６によってＲＥＳＶメッセージ５８内でＰＤＳＮ３０へ通知される。第１のフローが１つのサービスインスタンスとのみ関連付けられることはサービスインスタンス／フロー構成内では固有のことである。ＰＤＳＮ３０が静止写真に関する特定のＤＳＣＰを有するパケットを認知する必要はない。ＰＤＳＮ３０においてはマップのみが必要であり、ＭＳ２６は、フロー作成時に、基底に在るデータの型に対して適正なＱｏＳパラメータを決定する。その同じＲＥＳＶメッセージ５８は、０１１１１０のＤＳＣＰヘッダ値を持つ上記パケットが第２のフローの中へ入る旨を通知する。この第２のフローへの入来は、最初のサービスインスタンスを介して行ってもよいし、最初のサービスインスタンスを介さずに行ってもよい。これらフローの各々は、基底に在るデータの異なる性質に起因して異なるＱｏＳを有することになる；写真からのパケットは遅延に対してやや鈍感であるが、結果として得られる写真はパケットロスによって顕著な破損を受ける可能性があるのに対して、ＶｏＩＰパケットは遅延に対して敏感に反応するが、パケットロスに対しては比較的鈍感である。データフローの設定に用いる異なるＱｏＳパラメータは、基底に在るデータの型を反映するものであるが、データフローはＭＳ２６で作成されるものであり、ＲＮ２４やＰＤＳＮ３０で作成されるものではない。ＲＥＳＶメッセージ５８はどのパケットがどのデータフローの中へ入るかをＰＤＳＮ３０に通知し、ＰＤＳＮ３０はデータフローに対するＤＳＣＰのマップを構成する。ＭＳが２つのＶｏＩＰパケット間に連続して配置された写真パケットを送信できるのに対して、ＰＤＳＮ３０はヘッダ内のＤＳＣＰに関する情報のみを用いてこれらの写真パケットを分離するものである。さらにパケットを送信するＣＤＭＡ２０００のネットワーク３２の内部ノードは、ヘッダを開く必要や、マップを意識する必要さえない。というのは、これらのノードは組み込まれたサービスＩｎｔＳｅｒｖモデルで作動しているからである。この場合ネットワークを経由するフローは、上記ネットワークのエッジ内へパケットが入る際に事前に定められる。内部ノードは、ＱｏＳについて知ることなく、潜在的代替フロー、基底に在るデータ型、等を単にリレーするだけである。ＣＤＭＡ２０００のネットワーク３２の内部リレーが、ＭＳ２６によって要求される（およびＰＤＳＮ３０とＲＮ２４によって許可される）サービス品質を満たすものであり、単にパケットをずっと移動させるベストエフォートによる試みを反映するだけのものではないことがＤｉｆｆＳｅｒｖでの本発明の効率のよいシグナリングによって達成される。

図３は図２の信号図と類似の信号図であるが、ＲＮ２４によって更新されるＱｏＳパラメータの更新先である事前に確立済みのサービスインスタンスのコンテキストにおける信号図である。このコンテキストは、ＭＳ２６とＰＤＳＮ３０との間で、かつ、ＲＮ２４や基地局ＢＳを介して（任意のサービスインスタンスを介する）現在進行中のフロー６２として反映され、さらに、このコンテキストは、ＲＮ／ＢＳ２４がトラフィック条件や無線条件の変動に起因する現在進行中のフロー６２の変更を望むときに生じる可能性がある。ＲＮ２４は、特別のフロー用としてどのＱｏＳパラメータを更新６４すべきかの選択を行い、登録要求メッセ−ジ５２'をＰＤＳＮ３０へ送信して、関連するサービスインスタンス（ＳＲ＿ＩＤ）、フロー（ＭＳフローＩ）、および接続用およびフロー用の更新済みＱｏＳパラメータを運ぶものである。ＰＤＳＮ３０は、更新済みＱｏＳパラメータ５４'を認可し、認可の成功時に、ＲＮ２４へ登録応答５６'を返信して、更新済みＱｏＳパラメータを許可し、ＲＮ２４はサービス接続メッセージ４８”をＭＳ２６へ送る。図３のコンテキストで、無線リンク自体が変更された場合、サービス接続メッセージ４８”には、サービスインスタンス識別子（ＳＲ＿ＩＤ）と、フロー識別子（ＭＳフローＩ）と、更新され、許可されたＱｏＳパラメータおよび任意の関連する無線リンクパラメータとが含まれることになる。ＭＳ２６はサービス接続終了メッセージ５０”を用いて応答する。（ｘｂｐｓから２ｘｂｐｓへ変更された最小帯域などの）ある特定のフローのＱｏＳパラメータのグレードアップが行われた場合、メッセージ４８”と５０”とは以下のメッセージ５２'と５６'とに従う必要がある。そうしないと、これらのメッセージは同時に生じる可能性がある。

もはやフローを必要としなくなった場合、ＭＳ２６は自身で決定を行い、ＲＮ２４に対するシグナリングを行って、除去すべきフローと、このフローが存在するサービスインスタンスと、該フローの関連付けられたＱｏＳパラメータとを特定する。ＲＮ２４は、ＭＳ２６から受信したＱｏＳパラメータと、フロー識別子と、サービスインスタンスとを含む登録要求をＰＤＳＮ３０へ送信する。関連するサービスインスタンスで別のフローが運ばれなかった場合、ＲＮ２４は登録要求メッセ−ジで上記サービスインスタンスの切断を要求することも可能である。ＰＤＳＮ３０は上記フロー用のパケットフィルタを削除し、登録返信メッセージをＲＮ２４へ送信する。次いで、ＲＮ２４はサービス接続メッセージをＭＳ２６へ送信して、フローが除去される旨を示し、別のフローがサービス時刻に運ばれず、サービスインスタント全体が切断された場合、ＲＮ２４もサービス接続メッセージ内のサービスインスタンスを切断することになる。ＭＳ２６はサービス接続終了メッセージを用いてＲＮ２４に対する応答を行う。

図２の本質として、ＲＮ２４が、ＭＳ２６からＱｏＳ要件を取得したり、ＱｏＳ要件を導き出したりし、次いで、ＰＤＳＮ３０へＱｏＳ要件を送信するということが挙げられる。第１の代替実施形態に従う上記情報を利用するダウンリンクトラフィックとアップリンクトラフィックとの別々の処理が図４Ａ（ダウンリンク）と図４Ｂ（アップリンク）とに示されている。アップリンクトラフィックとダウンリンクトラフィックの別々の処理用の第２の代替実施形態は、図５Ａ（ダウンリンク）と図５Ｂ（アップリンク）とに示されている。アップリンクトラフィック用の第３の代替実施形態は図６に示されている。これらの各々は図２のシグナリングに対する補助であり、ＰＤＳＮ３０またはＲＮ２４において決定されたポリシのアップリンクとダウンリンクとの実施を示すものである。図２に記載のメッセージが上記代替実施形態にも示されている場合、これらメッセージは上記代替実施形態で修正され、メッセージタイトル、メッセージ内容および／または付随する説明テキストによって明白にされる。

図４Ａのダウンリンク時にＲＮ２４は登録要求６６をＰＤＳＮ３０へ送信するが、この第１の代替実施形態ではメッセージ６６にはサービスインスタンス識別子と（ＱｏＳパラメータを含む）ＱｏＳ＿ＢＬＯＢメッセージとが含まれる。ＰＤＳＮ３０は、要求メッセージ６６に基づいて、ダウンリンクトラフィック３４用のＤｉｆｆＳｅｒｖポリシ（以下の例）を判定し６８、それによってダウンリンクパケット３４を適切なサービスインスタンスとフローとにマップするために利用されるサービスインスタンスとＤｉｆｆＳｅｒｖポリシとの間にマップが構成されることになる。次いで、ＰＤＳＮ３０は認可後に登録返信メッセージ５６を送信し、ＲＮ２４は前述したようにサービス接続メッセージ５０、５０'を送信する。次いで、ＭＳ２６は、フィルタ、あるいは、前述したＲＥＳＶメッセージ５８の場合と類似のＲＥＳＶメッセージ７０を送信するが、本例では、登録要求メッセ−ジ６６のＱｏＳ＿ＢＬＯＢ部分内のＰＤＳＮ３０に対して事前に与えられているようなフロー識別子を設ける必要はない。その代わりに、このフィルタメッセージ７０には（フロー用のフィルタパラメータと共に）ダウンリンクトラフィック用のサービスインスタンス識別子とＴＦＴとが含まれる。ＰＤＳＮ３０は、フィルタに関するこの付加情報を利用して、サービスインスタンス識別子を介して（パケットフィルタを用いる）フローにＤｉｆｆＳｅｒｖポリシをマップする。

ＤｉｆｆＳｅｒｖポリシは、前述したようなＤＳＣＰマーキングおよび／またはトラフィックポリシ／シェイピングポリシを設けることも可能であり（但しこれらのみに限定されるわけではない）、図２に記載のプロファイル４２を考慮に入れることも可能である。２つの異なる例は所定のものではあるが、これらのポリシの規定は異なる移動通信ネットワーク２２の通信事業者の間で変動するものであってもよい。ＤｉｆｆＳｅｒｖマーキングポリシの一例として、ａ）ｘｂｐｓの要求帯域と、ｂ）ｙミリ秒の要求される最大遅延時間と、ｃ）ｚ％の容認可能な損失率とを含むＱｏＳパラメータを有するダウンリンクパケットが０１１００１のＤＳＣＰ値を用いてマークされるものと想定する。別のＱｏＳパラメータの組み合わせとしきい値とは異なるＤＳＣＰ値と同じである。ＤｉｆｆＳｅｒｖトラフィック規制／シェイピングポリシの一例として、移動通信ネットワーク２２によって従来通り混雑したトラフィックが運ばれる時間のような或る一定時間の間、（拡張機能を備えたサービスに対してプレミアム料金を払うユーザなどの）高い優先順位のユーザが利用する（トラフィッククラスやアプリケーションＩＤによって指定されるものであってもよい）ストリーミング用アプリケーションがＸｂｐｓを上回らないものであることが想定される。特定のユーザＱｏＳプロファイルの中でこのようなＤｉｆｆＳｅｒｖトラフィック規制／シェイピングポリシを指定することも可能であるし、あるいは、ローカルな移動通信ネットワーク２２固有の制限用としてこの移動通信ネットワーク２２によってこのようなＤｉｆｆＳｅｒｖトラフィック規制／シェイピングポリシを規定してもよい。（従来最も帯域制限を受けている）ジャンクチャにおいてポリシを実施することによってＲＮ２４−ＭＳ２６インタフェースに過負荷をかける代わりに、ＲＮ２４が上記ポリシを認知するようにしてもよいが、プロファイル外のパケットがＲＮ２４に達する前に、このようなポリシに基づいて上記プロファイル外のパケットを落したり、シェイピングを行ったりすることによってＰＤＳＮ３０はダウンリンクトラフィック３４用のポリシを実施することができる。ダウンリンクトラフィックがＰＤＳＮ３０を通過するにつれて、ＰＤＳＮ３０はＴＦＴに基づいて正しいサービスインスタンスの中へパケットのマッピングを行い、ＳＲ＿ＩＤと関連付けられた正しいＤＳＣＰを用いてこのパケットのマーキングを行う。別の可能なＤｉｆｆＳｅｒｖ機能（ポリシイング、シェイピングなど）を上述したものと同様に実行することができる。

この第１の代替実施形態用の図４Ｂに図示のようなアップリンク時に、ＱｏＳパラメータとフロー識別子とはＤＳＣＰと別のＤｉｆｆＳｅｒｖポリシとに直接マッピングされる。ＭＳ２６から当該情報を取得した後、ＲＮ２４は、例えば、どのＤｉｆｆＳｅｒｖポリシ（ＤＳＣＰマーキングなど）をサービスインスタンスに適用するかの判定を行い７４、次いで、ＳＲ＿ＩＤとＤｉｆｆＳｅｒｖポリシとの間でマッピングを確立する。このアップリンク２８フロー用のマッピングがＲＮ２４に存在するため、登録要求７６はサービスインスタンス識別子を含むだけで十分となる。

図５Ａ（ダウンリンク）と図５Ｂ（アップリンク）とに第２の代替実施形態が描かれている。図５Ａでは、ＭＳ２６は、ダウンリンクのフローフィルタを運ぶＴＦＴと共にダウンリンクのＱｏＳ要件をＲＥＳＶメッセージ７８の形でＰＤＳＮ３０へ送る。ＲＥＳＶメッセージの形で運ばれるＱｏＳ要件は、上述した情報と同じ情報を含むか、新たな情報要素やＤｉｆｆＳｅｒｖ用として規定されたフローフォーマットを含むものであってもよい。ＲＥＳＶメッセージ７８を受け取った後、ＰＤＳＮ３０はダウンリンクトラフィック用ＱｏＳ要件に基づいて適用すべきＤｉｆｆＳｅｒｖポリシを判定し８０、上記に例示したようなフロー（ＴＦＴのフィルタを介して）と、フロー（ＳＲ＿ＩＤ）を運ぶサービスインスタンスと、任意の関連するＤｉｆｆＳｅｒｖポリシとの間でマッピングを作成する。登録要求７６は、サービスインスタンス識別子を含むだけで十分であり、登録応答５６と、ＲＥＳＶメッセージまたはフィルタ確認６０メッセージとは前述のものと同様である。

図５Ｂに図示のようなこの第２の代替実施形態におけるアップリンクの場合、ＭＳ２６はＲＥＳＶメッセージ８２をＰＤＳＮ３０へ送信し、上記ＲＥＳＶメッセージ８２には、サービスインスタンス識別子と、アップリンクおよびダウンリンクのＱｏＳパラメータと、ダウンリンク（ＴＦＴ）用のフィルタパラメータとが含まれる。ＰＤＳＮ３０は、アップリンクトラフィック用のＤｉｆｆＳｅｒｖポリシを判定する８４情報を利用して、サービスインスタンスとＤｉｆｆＳｅｒｖポリシ間にマップを構成する。次いで、ＰＤＳＮ３０はＲＮ２４に対するシグナリング８６を行って、ＰＤＳＮ３０が判定するアップリンクトラフィック処理ポリシを実行する。好適には、このメッセージ８６委譲（ｄｅｖｏｌｖｉｎｇ）ポリシの実施は周知のＣＯＰＳフォーマットで表わされ、このポリシの実施によって、サービスインスタンス識別子と、上記サービスインスタンスでアップリンクトラフィックに適用される上記判定済みポリシとが運ばれることが望ましい。或いは、メッセージ８６は修正済みのＡ１１メッセージであってもよい。ＲＮ２４が、ＭＳ２６によって事前に作成されたフローを（図２のメッセージ４４から）認知しているため、メッセージ８６で特定されたサービスインスタンスを利用して、ＤｉｆｆＳｅｒｖポリシを実施する相手先サービスインスタンスの関連フローがＲＮ２４に対して一意に特定される。何らかの形の確認応答メッセージ８８がＰＤＳＮ３０へ送信され、次いで、ＰＤＳＮ３０は確認メッセージ６０をＭＳ２６へ送信する。

図６はアップリンク２８トラフィックの具体的な処理を行うための第３の代替実施形態を示す。ＭＳ２６は、ＲＥＳＶを送信するか、あるいは、サービスインスタンス識別子と、アップリンクＱｏＳパラメータと、ダウンリンクフィルタパラメータ（ＴＦＴ）とを運ぶフィルタメッセージ９０を送信する。ＲＮ２４は上記ＲＥＳＶメッセージ９０を受け取る。本実施形態では、ＲＮ２４は上記メッセージ９０をＰＤＳＮ３０へ転送する９０'以外に、このＲＥＳＶメッセージ９０をインターセプトし９２、アップリンクトラフィック用のＤｉｆｆＳｅｒｖポリシを判定し、サービスインスタンス識別子をＤｉｆｆＳｅｒｖポリシにマップする。ＰＤＳＮ３０はアップリンクＱｏＳパラメータを無視する９４。というのは、本実施形態では、ＲＮ２４がアップリンクトラフィック用ＤｉｆｆＳｅｒｖポリシを実施するからである。前述したようにＰＤＳＮ３０は確認メッセージ６０をＭＳ２６へ送信する。

アップリンク用トラフィックおよびダウンリンクトラフィック用ソリューションは別々に図解されているが、対応するソリューションは一括してマージされ、異なる好適な代替実施形態のためのミックス用アップリンクおよびダウンリンクソリューションを設けることができる。

図７Ａと図７Ｂとを参照しながら上記シグナリング交換で説明した移動局２６について次に説明する。図７Ｂのブロック図に記載されている電子装置のうちの或る電子装置が上述の基地局２４とＰＤＳＮ３０内に設けられている。移動局２６は携帯電話や個人用コミュニケータであってもよい（但しこれらのみに限定されるわけではない）。移動局２６は、移動ノードや基地局２４へ信号を送信するための、および、移動ノードや基地局２４から信号を受信するための１以上のアンテナ１０２を備えている。基地局２４は、ＰＤＳＮ３０と移動体交換センタ（ＭＳＣ、図示せず）とを備えたネットワークの一部であってもよい。ＭＳＣは、移動局２６が発呼時に関与する場合、陸線基幹回線との接続を行うものである。移動局２６は、変調器（ＭＯＤ）１０４Ａ、送信機１０４、受信機１０６、復調装置（ＤＥＭＯＤ）１０６Ａ、および、それぞれ、送信機１０４と受信機１０６とへ信号を出力し、並びに、送信機１０４と受信機１０６とから信号を受け取るコントローラ１０８を備えるものである。これらの信号には適用可能なセルラシステムのエアインタフェース規格、ユーザの音声データおよび／またはユーザ作成データ、並びに、詳細に上述した信号に準拠するシグナリング情報が含まれる。本発明の教示はＧＳＭタイプのＴＤＭＡ移動局に容易に適用可能であるが、これらの教示は、符号分割／多元接続（ＣＤＭＡ）システムおよび別のタイプのシステムに対しても同様に適用可能である。

コントローラ１０８は移動局のオーディオ（音声経路）機能および論理機能の実現に必要な回路も備えるものと理解されたい。例えば、コントローラ１０８は、デジタル信号プロセッサ装置、マイクロプロセッサ装置、種々のアナログからデジタルへの変換器、デジタルからアナログへの変換器、並びに、別のサポート回路から構成することが可能である。移動局２６の制御機能および信号処理機能はこれら装置のそれぞれの能力に従ってこれら装置間で割り当てられる。

ユーザインタフェースは、従来方式のイヤホンやスピーカ１１０、従来方式のマイク１１２、ディスプレイ１１４並びにユーザ入力装置（典型的にはキーパッド１１６）を備える。これらのすべてはコントローラ１０８と結合される。ユーザ入力装置はデジタル静止カメラまたはデジタルビデオカメラを備えるものであってもよい。キーパッド１１６は、従来方式の数字キー（０〜９）および関連キー（＃、＊）１１６ａおよび移動局２６の操作に使用する別のキー１１６ｂを備える。これら別のキー１１６ｂは例えば、ＳＥＮＤキー、種々のメニュースクロールキー、および、ソフトキー並びにパワーオン／オフキーを備えるものであってもよい。タッチパネル式スクリーンとしてのディスプレイ１１４と共にこれらのキーを共置（co-located）してもよい。これらキー機能は、スピーカ１１２を介する音声認識によって作動するものであってもよいし、従来の１１６ａと別の１１６ｂキー用として周知のような同じ機能性または拡張された機能性を実行するために別様に具現化してもよい。移動局２６は、移動局２６の作動に必要な種々の回路に電力を供給する取り外し可能なバッテリ１１８も備えている。

移動局２６は、メモリ１２０として集合的に示されている種々のメモリも備え、このメモリには、移動局の作動中にコントローラ１０８によって複数の定数および変数が格納される。例えば、メモリ１２０には、無線システムパラメータの値と、移動局２６用の一意の識別子と、コントローラ１０８の動作を制御するオペレーティングプログラムとが（典型的には各々ＲＯＭ装置の中に）格納され、さらに、オペレーティングプログラムのコンテキスト内で特定のアプリケーションを実行するための種々のソフトウェアアプリケーションプログラム（アプリケーションプログラムは典型的には読出し／書込みＲＡＭ装置の中に在る）が格納される。メモリ１２０内のオペレーティングプログラムには、典型的には種々のメニュー項目として、メッセージ機能とメッセージ関連機能とをユーザに対してディスプレイ１１４に表示するルーチンが含まれる。

本発明によれば、アプリケーションソフトウェアプログラム１２２は、スタンドアローン型プログラムであってもよいし、あるいは前から存在する別のプログラムをさらに修正した（別様には存在しない或る種のデータと共にメッセージ４４を構成するような）プログラムであってもよいが、このアプリケーションソフトウェアプログラム１２２は、少なくとも１つの品質パラメータにデータ型をマップするメモリ１２０の中に格納される。移動局２６は、アップリンクパケットまたはダウンリンクパケット用として基底に在るデータ型を判定したり、アプリケーションプログラム１２２を利用して、どの品質パラメータに対して上記データ型を適用するかを判定したりして、上述のようなＱｏＳパラメータ要求メッセージ４４の送信を行う。このＱｏＳパラメータ要求メッセージ４４は、ソフトウェアアプリケーションマップから得られるＱｏＳパラメータとサービスインスタンス識別子との双方を含み、さらに、好適には、ＱｏＳパラメータを適用する（ＭＳで作成された）相手先フローも含むという点で新規のものである。さらに、このアプリケーションプログラムは、サービス接続メッセージ４８、４８'の受信に応答して（すなわち自動的に）、ＱｏＳパラメータを運ぶＲＥＳＶメッセージまたはフィルタメッセージ５８、７０、７８、８２、９０およびサービスインスタンス識別子、並びに、好適にはフロー方向、および、ＭＳ２６でフロー用として作成されたフロー識別子もＭＳ２６へ送信させるものである。

典型的にはマイク１１２、バッテリ１１８、スピーカ１１０、ディスプレイ１１４およびキーパッド１１６を除いて、図７Ｂの上記回路のほとんどもＲＮ２４とＰＤＳＮ３０の中に存在している。ＲＮ２４とＰＤＳＮ３０は個々に、それぞれのノードから送信される上記詳述したメッセージを構成するためのアプリケーションソフトウェアプログラムを有し、これらのメッセージのうちの或る種のメッセージは、上記好ましい代替実施形態で特に詳述したように、ＭＳ２６、ＭＮ２４、ＰＤＳＮ３０のいずれかからの別のメッセージの受信に応答するメッセージである。

クレームされた発明の好適な代替実施形態であると現在考えられる形態を以上例示し、これについて説明したが、多数の変更と修正とが当業者の心に浮かぶであろうことは理解できる。これらの変更をすべてカバーすることが、添付の請求項において意図されていることである。

移動局と外部ネットワーク間の、および、無線ノードＲＮとパケットデータ交換ノードＰＤＳＮとを介する移動パケットの従来技術の概観である。 サービスインスタンスの初期設定時にアップリンク方向とダウンリンク方向の双方の方向でＱｏＳ ＤｉｆｆＳｅｒｖを作動可能にする図１のネットワークのノード間での信号図（その１）である。 サービスインスタンスの初期設定時にアップリンク方向とダウンリンク方向の双方の方向でＱｏＳ ＤｉｆｆＳｅｒｖを作動可能にする図１のネットワークのノード間での信号図（その２）である。 図２の場合と同様の図であるが、既存のサービスインスタンス内のＱｏＳを修正するためのシグナリングを示す図である。 第１の代替実施形態におけるダウンリンクトラフィックの特定の処理を示す信号図である。 第１の代替実施形態におけるアップリンクトラフィックの特定の処理を示す信号図である。 第２の代替実施形態におけるダウンリンクトラフィックの特定の処理を示す信号図である。 第２の代替実施形態におけるアップリンクトラフィックの特定の処理を示す信号図である。 第３の代替実施形態におけるアップリンクトラフィックの特定の処理を示す信号図である。 本発明に基づいて構成される移動局の透視図である。 本発明に基づいて構成される移動局の概略ブロック図である。

Claims (16)

1. フローを確立する方法であって、
   無線ネットワークノードにおいて移動局から第１の要求メッセージを受け取るステップであって、前記第１の要求メッセージが前記フロー用の少なくとも１つのサービス品質パラメータを含むステップと、
   前記無線ネットワークノードが前記少なくとも１つのサービス品質パラメータを含む複数のサービス品質パラメータを許可するステップと、
   前記無線ネットワークノードからパケットデータ交換ノードへ第２の要求メッセージを送るステップであって、前記第２の要求メッセージが１以上の前記許可されたサービス品質パラメータを含むステップと、を具備することを特徴とする方法。
2. 前記無線ネットワークノードが基地局であることを特徴とする請求項１に記載の方法。
3. 請求項１に記載の方法であって、
   前記無線ネットワークノードから前記移動局へ返信メッセージを送るステップであって、前記返信メッセージが、前記許可された複数のサービス品質パラメータと、前記フロー用の無線リンクパラメータとを含むステップをさらに具備することを特徴とする方法。
4. 前記返信メッセージがフロー識別子をさらに含むことを特徴とする請求項３に記載の方法。
5. 前記無線ネットワークノード以外のノードから、および、前記第１の要求メッセージを発信する前記移動局から、前記第１の要求メッセージの前記送信よりも先に、前記移動局と関連付けられた一連の品質パラメータを含む加入者プロフィールを受け取るステップをさらに具備することを特徴とする請求項２に記載の方法。
6. 請求項２に記載の方法であって、
   前記第１の要求メッセージを発信する前記移動局から別のノードへフィルタメッセージを送るステップであって、前記フィルタメッセージが少なくとも１つのパケットフィルタを含むステップをさらに具備することを特徴とする方法。
7. 前記少なくとも１つのパケットフィルタが複数のパケットフィルタコンテンツオプションを具備し、前記少なくとも１つのパケットフィルタがフロー識別子によって特定されることを特徴とする請求項６に記載の方法。
8. 請求項２に記載の方法であって、
   許可された前記複数のサービス品質パラメータを満たすために前記フローをさらにサポートすることができない旨を前記無線ネットワークノードにおいて判定するステップと、
   少なくとも１つの更新済みサービス品質パラメータを含む修正済みの第２の要求メッセージを送るステップと、
   前記少なくとも１つの更新済みサービス品質パラメータを満たすために認可を受け取るステップと、をさらに具備することを特徴とする方法。
9. 前記修正済みの第２の要求メッセージが前記フロー用の識別子を含むことを特徴とする請求項８に記載の方法。
10. 請求項１に記載の方法であって、
    前記フローでトランスポートするパケットに適用するポリシを判定し、前記フローと関連づけられた識別子を前記ポリシにマップするステップをさらに具備することを特徴とする方法。
11. 前記ポリシを判定するステップが別のノードに在る方法であって、アップリンク方向とダウンリンク方向とのうちの少なくとも一方の方向で送られる前記パケットに関する前記ポリシを前記別のノードにおいて実施するステップをさらに具備することを特徴とする請求項１０に記載の方法。
12. 前記ポリシを判定するステップが前記無線ネットワークノードに在る方法であって、前記無線ネットワークノードから前記別のノードへ少なくともアップリンク方向で送られる前記パケットに関する前記ポリシを前記無線ネットワークノードにおいて実施するステップをさらに具備することを特徴とする請求項１０に記載の方法。
13. 前記ポリシを判定するステップが前記パケットデータ交換ノードに在る方法であって、前記無線ネットワークノードから前記パケットデータ交換ノードへアップリンク方向で送られた少なくとも前記パケット用の前記ポリシを前記無線ネットワークノードにおいて実施することを特徴とする請求項１０に記載の方法。
14. 無線ネットワークノードであって、
    フロー用の少なくとも１つのサービス品質パラメータを含むＱｏＳパラメータ要求メッセージを受信する受信機と、
    前記少なくとも１つのサービス品質パラメータの判定と許可とを行うための、前記受信機と結合されたコントローラと、
    判定と許可とを行う前記コントローラの判定に応答して、返信メッセージを前記移動局へ、登録要求メッセージをパケットデータ交換ノードへ送信するための、前記コントローラと結合された送信機と、
    を具備することを特徴とする無線ネットワークノード。
15. 前記登録要求メッセージが前記フロー用の識別子を含むことを特徴とする請求項１４に記載の無線ネットワークノード。
16. 前記登録要求メッセ−ジが前記少なくとも１つのサービス品質パラメータをさらに含むことを特徴とする請求項１５に記載の無線ネットワークノード。

Images