JPWO2011135800A1 - 通信装置、ネットワークノード並びに通信サーバ - Google Patents

Abstract

グループベースの通信においてグループ帯域幅に上限がある場合であっても、高優先度及び高帯域幅のユーザプレーントラフィックを送信する必要があるデバイスからそのユーザプレーントラフィックを送信できるようにする技術が開示され、その技術によれば高優先度及び高帯域幅のユーザプレーントラフィックを送信しようとするＭＴＣデバイスがネットワークノード（Ｐ−ＧＷ２１３ａ）にサービス要求を行ったとき、グループ帯域幅の上限値を超えてしまう場合には最小限の帯域幅のベアラの使用を許可する。ＭＴＣデバイスは、このベアラを経由してＭＴＣサーバ２１４ａへトラフィックの送信要求を行う。ＭＴＣサーバは、適切な他のＭＴＣデバイスのトラフィックを停止させて、高優先度及び高帯域幅のユーザプレーントラフィックを有するＭＴＣデバイスのために、帯域幅を確保する。

Description

本発明は、パケット交換型データ通信ネットワークにおける通信技術に関する。具体的には、本発明は、あるグループに属し、グループ帯域幅上限値に関連する帯域幅制約を有する通信装置と、ネットワークを構成するネットワークノード及び通信サーバに関する。

セルラ通信は、Global System for Mobile Communications（ＧＳＭ）ネットワークの黎明期から、General Packet Radio Service（ＧＰＲＳ）、そして現在世界中で利用されているUniversal Mobile Telecommunications System（ＵＭＴＳ）へと継続して発展している。近い将来、次世代Long Term Evolution（ＬＴＥ）ネットワークが利用可能となるであろう。また、アクセス技術と共に、セルラ通信ネットワークによって提供されるサービスも発展してきている。現在のセルラネットワークは、初歩的な音声通話サービスだけを提供するものではなく、短いテキストメッセージの伝送やグローバルインターネットへのアクセスも提供している。また最近、例えばマシントゥーマシン（Ｍ２Ｍ：machine-to-machine）通信などのノンヒューマン（non-human）コミュニケーションをカバーするための新たなサービスへと拡張してきている。また、第３世代パートナーシッププロジェクト（３ＧＰＰ：the Third Generation Partnership Project）は、セルラネットワークがマシンタイプ通信をサポートするための要件定義を開始している（下記の非特許文献１を参照）。これにより、セルラネットワークは、マシンタイプ通信をより適切にサポートするものとなる。

Ｍ２Ｍ通信は、ヒューマントゥーヒューマン（Ｈ２Ｈ：human-to-human）コミュニケーションとは異なる通信パラダイムである。Ｍ２Ｍ通信は、通信シナリオ及び通信モデルにおいて異なっている。マシンタイプ通信シナリオのほとんどは、単一又は複数のマシンタイプ通信（ＭＴＣ：Machine Type Communication）デバイスと、単一のＭＴＣサーバとの間の通信に関係する。以下のａ）からｇ）は、ＭＴＣデバイスがＭＴＣサーバへ通信を行うシナリオの一例である。ａ）ＭＴＣデバイスがＭＴＣサーバに対して、人間の健康に関するデータをアップデートする健康管理産業、ｂ）ある会社に属する船舶が、ＭＴＣデバイスを実装する移動中の船舶から送信されるアップデートデータを用いてサーバにより追跡される航路追跡、ｃ）所有物を監視する産業、ｄ）天候に関する情報をサーバにアップデートする天候センサ、ｅ）食料の状態に関する情報をサーバにアップデートする食料センサ、ｆ）停電や電力消費に関する情報をＭＴＣサーバにアップデートする家庭内のスマートメータ、ｇ）侵入者の検知情報をＭＴＣサーバへアップデートする監視カメラ。

また、ＭＴＣサーバがＭＴＣサーバへ通信を行うシナリオに加えて、ＭＴＣデバイス間通信のような別のＭＴＣ通信シナリオも存在する。このような通信シナリオの一例としては、ＭＴＣデバイスを制御し、より良い動作をさせるために、家庭内に配置されているスマートメータ間で通信を行う場合が挙げられる。ヒューマントゥーヒューマンとは異なるＭ２Ｍ通信の特徴は、以下の通りである。ａ）人間の介入や決定処理なく動作する、ｂ）遅延許容性や非常に低いデータアプリケーションなどのような異なる通信トラフィックのタイプを有する、ｃ）モバイルのみが存在するタイプ、データ取得のためのサーバからのポーリングが行われるモデル、一般的なモバイルのタイプなどのような異なる通信モデルを有する、ｄ）モビリティが低いパターンやモビリティの無いパターンなどのように、ＭＴＣデバイスに対して異なる位置管理動作を行うような異なるモビリティパターンを有する、ｅ）単一のメッセージを使用して複数のＭＴＣデバイスに到達可能とするグループベースのアドレッシングなど、異なるアドレッシング機構を有する、ｆ）人間によって制御されないＭＴＣデバイスによって窃盗や破壊行為を防ぐ必要性を有する、ｇ）あるサービス加入の下で配置されている複数のＭＴＣデバイスによって、グループベースの課金やサービス提供モデルを有する、ｈ）より廉価な動作のために電力ラインが供給がされておらず、ほとんどのＭＴＣデバイスをバッテリ駆動式とすることによって極力電力消費を抑えた動作を有する。このようなＭ２Ｍに具体的に関連するユニークな特性は、サービス要件を特定してネットワークの最適化を実現するために使用される。３ＧＰＰコアに接続しているＭＴＣデバイスの数は、３ＧＰＰに接続している従来のユーザ端末（ＵＥ）よりもずっと多く、マシンタイプ通信のユニークな特性をターゲットとするネットワーク最適化を有することが不可欠である。その結果、ネットワークオペレータは、動作コストを大きく低減させ、ＭＴＣデバイスに関連する魅力的な課金モデルを提供することが可能となる。

ＭＴＣデバイスのユニークな特性に関して具体的に実装されるネットワーク最適化を提供するためのサービス及びアーキテクチャ要件を画策するため、３ＧＰＰのＳＡ１（Service Aspects 1）及びＳＡ２（Service Aspects 2）ワーキンググループにおいて標準化が行われている。ＭＴＣデバイスに関連するサービス要件及びネットワーク最適化は、例えば、下記の非特許文献１に開示されている。非特許文献１に開示されているＭＴＣ関連のサービス要件の多くは、ＭＴＣ通信のためのネットワークを最適化すること、又はネットワークを改善することをターゲットとしている。非特許文献１には、単一の加入者に属し、ＭＴＣサーバと通信を行っているＭＴＣデバイスのグループに対して、帯域幅の上限が課されるというサービス要件が開示されている。ここでは、このようなグループ向けの帯域幅の上限を、グループ全体最大ビットレート（group bandwidth maximum bit rate：Ｇ−ＡＭＢＲ）と呼ぶことにする。この非特許文献１では、帯域幅に関連するすべてのパラメータは、ビット／秒の単位で表されている。Ｇ−ＡＭＢＲは、アップリンク、及び／又は、ダウンリンクに関して独立して割り当て可能である。なお、アップリンクＧ−ＡＭＢＲは、ＵＬ−Ｇ−ＡＭＢＲと記載し、ダウンリンクＧ−ＡＭＢＲは、ＤＬ−Ｇ−ＡＭＢＲと記載する。ユーザプレーン（Ｕプレーン）トラフィックが主にアップリンクであるＭ２Ｍグループ通信モデルでは、ＵＬ−Ｇ−ＡＭＢＲのみが適用されてもよい。また、ダウンリンクが支配的な場合も同様に、ＤＬ−Ｇ−ＡＭＢＲのみが適用されてもよい。Ｇ−ＡＭＢＲが適用されている場合、グループに属する多数のＭＴＣデバイスが行っているユーザプレーントラフィックに関するトータルの帯域幅が、いかなるときでもＧ−ＡＭＢＲを超えることはできない。このようなグループの上限を超えると、実施ポイント（帯域幅の使用状況をチェックするポイント）においてトラフィックのシェーピングが行われる。上述のグループベースの通信モデルでは、すべてのＭＴＣデバイスが同一のサーバと通信を行っているので、すべてのＭＴＣデバイスは、同一のパケットデータネットワークゲートウェイ（packet data network gateway：Ｐ−ＧＷ）を利用し、その結果、トラフィック実施ポイントはＰ−ＧＷとなる。このＧ−ＡＭＢＲを割り当てるための主要な動機は、グループ内のすべてのＭＴＣデバイスが同時にコアネットワークを使用する際に必要とされるトータルの帯域幅より小さい値のＧ−ＡＭＢＲを設定することである。

ネットワークによってＧ−ＡＭＢＲの上限値が割り当てられることは、グループベースの通信において合理的である。切り詰められえたグループ帯域幅の上限値を用いることによって、加入者は、オペレータに支払うサービス料が少なくなる。さらに、オペレータは、多くのＭＴＣデバイスをネットワークに収容することができ、魅力的な価格を提供することでより多くの収入を得ることができる。また、Ｇ−ＡＭＢＲは、通常は、home subscription server（ＨＳＳ）によって割り当てられる静的な値であるか、又は、Ｐ−ＧＷに静的に格納されているか、又は、policy control and charging related function（ＰＣＲＦ）からＰ−ＧＷへ静的な方法で提供されるものである。しかしながら、Ｇ−ＡＭＢＲは、ＰＣＲＦによって動的に管理可能な動的な値であってもよい。また、下記の非特許文献２には、上述した機能エンティティの機能上の役割が詳細に説明されている。

Ｇ−ＡＭＢＲの概念を用いることによって、上述のような利益が多数提供されるが、トレードオフ、すなわち、不利益も存在している。例えば、Ｇ−ＡＭＢＲの上限によって、グループの複数のＭＴＣデバイスの間で現在使用されている帯域幅がＧ−ＡＭＢＲに達しており、かつ、そのグループの別のＭＴＣデバイスがユーザプレーントラフィックを送信しようとした場合に問題が生じる。この場合、このＧ−ＡＭＢＲの上限によれば、複数のＭＴＣデバイスが同時に、限定的に利用可能な帯域幅や自由に使用可能な帯域幅を求める場合も問題が生じる。グループにおいて利用可能な自由な帯域（ここではＡｖＧｒＢＷと記載する）は、（Ｇ−ＡＭＢＲ）−（Ｕプレーントラフィックを送信しているグループ内のＭＴＣデバイスに関する帯域幅又はビットレートの現在の総量）に等しい。なお、ＡｖＧｒＢＷは、ビット／秒で表すことが可能である。

非特許文献２に概説されているように、通常のＵＥにおける動作によれば、最初のアタッチ処理の間、デフォルトベアラに関連付けられるサービス品質（quality of service）パラメータは、ノンアクセスストラタム（Non Access Stratum：ＮＡＳ）メッセージ（Attach Accept message）によって、mobility management entity（ＭＭＥ）からＵＥへ通知される。最初のアタッチ処理の間に、通常のＵＥへのベアラコンテキストの通知処理に加え、ＵＥが接続モード（Connected Mode）又はアイドルモード（Idle Mode）のとき、ベアラ変更処理（Bearer Modification procedure）を利用してベアラコンテキストの変更がＵＥへ通知される。非特許文献２には、接続モード及びアイドルモードの定義が記載されている。ベアラ変更処理は、ほとんどの場合はＰ−ＧＷによってトリガ可能であり、また、ＭＭＥによってトリガされる場合もある。上述した通常のＵＥの処理の説明から、ＵＥは、ベアラコンテキストを事前に把握する必要があり、これによって、適切な特性を有するアップリンクＵプレーントラフィックを送信することができ、ダウンリンクＵプレーントラフィックを受信することができるようになることは明らかである。また、リソース管理や３ＧＰＰ evolved packet system（ＥＰＳ）のＱｏＳモデルに違反するものでもない。例えば、ネットワークがある帯域幅に関連したパラメーターをベアラ（例えば、専用ベアラ（dedicated bearer：個別ベアラ））へ割り当てた場合、ＵＥは、それに応じて、Ｕプレーントラフィックの伝送速度を調整しなければならない。また、ネットワークが、ＵＥに関連するすべての非ＧＢＲ（Guaranteed Bit Rate）フローのための最大帯域幅（ＵＥ−ＡＭＢＲ）、あるいは、ＵＥのアクセスポイントネーム（access point name：ＡＰＮ）に関係するすべての非ＧＢＲフローのために最大帯域幅（ＡＰＮ−ＡＭＢＲ）を割り当てている場合には、ＵＥは、そのフローに関係する帯域幅がネットワークによって課せられた上限の総計を超えないようにしなければならない。事前にベアラ特性を把握する重要な利点として、ＵＥがアイドルモードから接続モードへ状態を変更したときに、Ｕプレーントラフィック伝送が迅速に開始できるという点がさらに挙げられる。これにより、ＵＥは、Ｕプレーントラフィックを送信する前に、ベアラコンテキストを把握するための時間を待機する必要がなくなる。

ベアラに関係するＱｏＳパラメータは、例えば、ＱＣＩ（quality class indication）、ＡＲＰ（allocation and retention priority）、ＭＢＲ（maximum bit rate）、ＧＢＲ（guaranteed bit rate）などである。また、このようなＱｏＳパラメータに加えて、例えば、ＵＥ−ＡＭＢＲやＡＰＮ−ＡＭＢＲなどの非ＧＢＲベアラのためのグループＱＯＳパラメータも割り当てられる。これらのＱｏＳパラメータの詳細な説明及び定義は、非特許文献２に明確に開示されている。すべてのパケットデータネットワーク（packet data network：ＰＤＮ）コネクションに関して、必要最小限のデフォルトベアラが作成される。このデフォルトベアラには、最小限のＱｏＳパラメータ（最低限のＱｏＳ処理を必要とするＱＣＩ値）が割り当てられる。このベアラは、通常は非ＧＢＲベアラである。ＱｏＳパラメータであるＭＢＲ及びＧＢＲはＧＢＲベアラにのみ関係するので、デフォルトベアラに対しては、ＱｏＳパラメータであるＭＢＲ及びＧＢＲは割り当てられない。また、非特許文献２に開示されているように、専用ベアラは、通常、Ｐ−ＧＷが開始するベアラ生成要求処理（P-GW initiated create bearer request procedure）によって生成される。専用ベアラは、ＧＢＲベアラであってもよく、非ＧＢＲベアラであってもよい。ＧＢＲベアラである専用ベアラがネットワークによって割り当てられると、ネットワークは、無線アクセスネットワーク（radio access network：ＲＡＮ）及びコアネットワークにおいて適切なリソース予約処理を用いることで、ＧＢＲベアラのビットレートが確実に保証されるようにする。

ネットワークは専用ベアラのための帯域幅を保証するが、リソースが利用不可能な場合などには、いつでも専用ベアラのＧＢＲを変更することができる。なお、現在のＵＥの処理において、この専用ベアラの変更はほとんど起こらず、専用ベアラ変更をＵＥへ事前に通知する。同様に、ＵＥのＵＥ−ＡＭＢＲ及びＡＰＮ−ＡＭＢＲも、ほとんど変更されず、これらの情報は、非特許文献２に概説されているＱｏＳ変更なしのベアラ変更処理を利用してＵＥへ通知可能であると仮定されている。例えば、ＵＥがアイドルモードの場合には、ベアラコンテキストの変更は最初のページングによって通知され、これにより、ＵＥは、サービス要求（Service Request）処理を実行する。ＵＥがサービス要求の実行に成功すると、変更されたベアラコンテキストがＵＥへ渡される。しかしながら、現在のＵＥは、ＭＴＣデバイスのような低電力要件を有していないため、ページングされてベアラ変更を受信するために起動されたとしても、電量を消耗していまうという重大な問題が生じるわけではない。さらに、通常のＵＥに関しては、ネットワークは、リソース管理を懸念する必要はほとんどなく、ベアラ変更はほとんど生じないので、ページング、及び、ページングに伴うシグナリングのコストはあまり高くはならない。例えば、専用ベアラのためのＵＥ−ＡＭＢＲ、ＡＰＮ−ＡＭＢＲ、ＧＢＲが変更される可能性が低い。しかしながら、ＭＴＣデバイスに関しては膨大な台数が存在することを考慮すると、グループ帯域幅上限や効率的なリソース管理に係る特別な技術（非常に大多数のＭＴＣデバイスの接続が必要となるＭ２Ｍ通信を収容するためにネットワークで動作する技術）が存在するとき、ネットワークはより多くのベアラ変更メッセージを送信する。

また、下記の特許文献１には、第１のデバイスで帯域幅が使用されない場合、第１のデバイスから第２のデバイスへ帯域幅の再割り当てを行う方法が開示されている。ここでは、デバイスはグループ通信を行っていると考えられる。また、特許文献１には、あるデバイスで使用されていない帯域幅を別のデバイスへ移すことによって、効率的な帯域幅の使用を実現する方法が開示されている。

また、下記の特許文献２には、グループ内の単一のデバイスのみが通信を行えるようにするグループ通信モデルの通信メカニズムを実現する方法が開示されている。この方法では、最初のアクセス制御において優先度が使用される方法によって、優先度のメカニズムがカバーされている。また、サービスを受けるより優先度の高いデバイスを取得するための割り込み優先度もカバーされている。

また、下記の特許文献３には、アタッチメントの際に認証サーバによって、端末へ通信優先度が割り当てられる方法が開示されている。さらに、割り当てられた通信優先度が認証サーバからルータへ通知されると考えられる。また、端末から送信されるパケットに通信優先度が付加されると考えられる。ルータは、この通信優先度が付加されたパケットを見つけると、特別な方法で処理を行う。さらに、ルータは、通信優先度に基づいて優先度の高い端末のアクセス制御を行う。

また、下記の特許文献４には、グループデバイスのアドレッシングを適切に行う方法が開示されている。伝送ネットワークには、内部で転送要素を定義するためのフレキシブルなトポロジーが含まれている。各転送要素には、伝送ネットワークに属し、複数の地理的に分配されたポートを有するポートグループが含まれている。ポートグループのポート間では、ポイントトゥーマルチポイントの接続性が定められている。識別子は、プロトコル交換用に、内部及び／又は外部要素に対応する単一の要素として、ポートグループを表している。

米国特許７６０９６３４ 米国特許７４０８９４８ 米国特許公開２００７／０２５８４４０ 国際公開公報ＷＯ２００１／０８６８６３

3GPP TS 22.368 V2.0.0, "Service Requirements for Machine Type Communications", 2010年3月 3GPP TS 23.401 V9.3.0, "3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; General Packet Radio Service (GPRS) enhancements for Evolved Universal Terrestrial Radio Access Network (E-UTRAN) access", 2009年12月

しかしながら、グループ帯域幅上限（すなわち、Ｇ−ＡＭＢＲ）が課されており、そのグループのＭＴＣデバイスが、送信すべきデータとして、リアルタイムトラフィック、広帯域幅を要するトラフィック、高優先度なＵプレーントラフィックを有している場合に問題が生じる。ここで説明する主な問題は、ＡｖＧｒＢＷが、ＭＴＣデバイスの広帯域、かつ、遅延耐性の無いトラフィック（例えば、高優先度のリアルタイムビデオキャプチャ情報）を伝送するためには十分ではない場合に基づいている。グループモデルの下で、Ｇ−ＡＭＢＲがＭＴＣデバイスのためのグループＱｏＳパラメータとして使用され場合、ＭＴＣデバイスは、そのグループに関するＡｖＧｒＢＷを把握する必要があるとする。ＭＴＣデバイスがこの値を把握していない場合には、そのアップリンクＵプレーントラフィック伝送を正しく行うことはできない。デバイスは、送信すべきリアルタイムＵプレーントラフィック（例えば、リアルタイムビデオ）を有している場合には、そのＵプレーントラフィック伝送レートをＡｖＧｒＢＷより確実に小さくする必要がある。ＭＴＣデバイスがレート制御を受けてもよい遅延耐性を有するトラフィック（例えば、任意の伝送レートで送信可能なデータトラフィック）を有している場合には、ＭＴＣデバイスは、ＡｖＧｒＢＷを把握して、そのアプリケーショントラフィックレートをＡｖＧｒＢＷに応じて変更できるようにする必要がある。

さらに、上述の問題について、図１を参照しながら説明する。ＭＴＣデバイス１０３、１０４、１０５、１０６はグループに加入しており、ほとんどの場合、コアネットワーク（３ＧＰＰ ＥＰＣ）１００を通じてＭＴＣサーバ１０２と通信を行う。ＭＴＣデバイスの１つ（例えば、ＭＴＣデバイス１０６）がＭＴＣサーバ１０２と通信を行う場合、Ｐ−ＧＷ１０１は、Ｕプレーンのアップリンクトラフィックのレートを監視して、ＭＴＣデバイス１０６に関連する帯域幅を把握する。図１で、ＭＴＣデバイス１０６からのアップリンクＵプレーントラフィックはメッセージ１１０として示される。Ｐ−ＧＷ１０１は、（ＵＬ−Ｇ−ＡＭＢＲ）−（ＭＴＣデバイス１０６からのアップリンクのユープレーントラフィックレート）であるＡｖＧｒＢＷを算出すると、ＱｏＳアップデートを行わないベアラ変更処理（bearer modification procedure without bearer QoS update）を利用して、ＭＴＣデバイス１０３、１０４、１０５、１０６に、ＡｖＧｒＢＷを通知する。一般に、ベアラのＱｏＳをアップデートしないベアラ変更処理は、一般的には、非特許文献２に開示されているように、トラフィックフローテンプレート（ＴＦＴ：traffic flow template）、及び／又は、ＡＰＮ−ＡＭＢＲを変更する際に用いられる。ＭＴＣデバイス１０３、１０４、１０５に向けて送信されるベアラ変更処理に関連するシグナリングは、シグナリングメッセージ１０７、１０８、１０９のそれぞれによって示される。ＭＴＣデバイス１０３のみが、アップリンクＵプレーントラフィックをＭＴＣサーバ１０２に送信予定であるならば、ＭＴＣデバイス１０４、１０５へのベアラ変更シグナリングは、無駄なシグナリングである。Ｍ２Ｍの構成及び動作においては、シグナリングオーバヘッドが発生してしまうので、シグナリングメッセージ１０８、１０９によって示されているベアラ変更シグナリングの追加は望ましくない。ＡｖＧｒＢＷを伝送するベアラ変更シグナリングで伝送される情報を必要としないＭＴＣデバイスがグループ内に多数存在する場合には、ベアラ変更シグナリングは、コアネットワークのリソースを浪費してしまうことになる。

さらに、図１に示されているＭＴＣデバイスは低電力であり、ＡｖＧｒＢＷをアップデートするためにＭＴＣ１０４、１０５を不要に起動させることは、電力供給に制限のあるＭＴＣデバイスの電力を浪費してしまうことになる。また、図１に示されているシナリオにおいて、ある時間が経過した後、ＭＴＣデバイス１０３が、送信すべきアップリンクＵプレーントラフィックを有するとする。ＭＴＣデバイス１０３のトラフィックは、リアルタイム、高優先度、広帯域幅であり、遅延させることはできず、また、レートのコントロールもできない。ＭＴＣデバイス１０３に通知されるＡｖＧｒＢＷは、ＭＴＣデバイス１０３が必要とするビットレートをサポートできないものであるとする。ＡｖＧｒＢＷが十分ではないので、高優先度、リアルタイム、広帯域幅トラフィックは、ＭＴＣサーバ１０２に届かない。例えば、ＭＴＣデバイス１０３、１０４、１０５、１０６は、異なるｅＮＤのサービスエリアを渡って様々な地域に配置される監視カメラであるかもしれない。この場合、ＭＴＣデバイス１０３は、侵入者の侵入に関係する重要な情報を送っているかもしれない。こうした重要なメッセージは、リアルタイムで送信される必要があり、侵入者の姿や動作をはっきりとキャプチャするため、広帯域幅が必要である。このように、グループ帯域幅に上限が設定されているモデルにおいて、ＭＴＣデバイス１０３からのＵ−プレーントラフィックが、遅延無くＭＴＣサーバ１０２に到達できるようにすることが必要不可欠である。なお、ここではＭＴＣデバイスによって構成されるグループベースの通信シナリオの問題について説明しているが、当業者であれば、任意のタイプのグループベースの通信に起こる問題であると判断できるであろう。

また、特許文献１に開示されている技術は、空いている帯域幅（Spare Bandwidth）が存在しない場合に、広帯域幅トラフィックの伝送のために利用可能な帯域幅を取得するものではない。したがって、例えばＡｖＧｒＢＷの状態が必要最小限に設定される場合などにおいて、未使用の帯域幅を再割り当てする方法は、図１で説明した高優先度トラフィックの伝送に係る問題を解決するために利用することができない。

また、特許文献２に開示されている技術は、グループ内のデバイスに静的な優先度の割り当てが行われていない場合には、高優先度のデバイスのための帯域幅をどのように取得するかが提示されていない。したがって、特許文献２に開示されている技術は、グループ内のデバイスに対して優先度が事前に割り当てられていない場合には、サービスを受けさせる高優先度デバイスを適切に特定することができず、図１で説明した問題を適切に解決することはできない。

また、特許文献３に開示されている技術によれば、端末から送信されるトラフィックのタイムに基づいて端末の優先度が設定された場合のアクセス制御メカニズムが開示されていない。特許文献３に開示されているように、ネットワークエンティティがデバイスに対して静的な優先度を事前に割り当てた場合には、図１で説明したシナリオのようにネットワークによって優先度の状態が明示的に割り当てられない場合の問題を解決することはできない。さらに、特許文献３には、帯域幅に上限があるケース（図１に図示されているケース）において、どのように高優先度トラフィックが収容されるのかについてカバーされていない。

また、特許文献４に開示されている技術は、このようなグループ識別子は、通信トラフィックが複数のデバイスへ送信される場合にグループ最適化を実現する適切なメカニズムであるが、図１で説明されている問題を解決するために、ネットワークを通じて高優先度トラフィックを取得する方法を実現することはできない。

本発明は、上記の問題を解決するため、高優先度、リアルタイム、広帯域幅のユーザプレーントラフィックを有するグループデバイスが存在する場合、利用可能なグループ帯域幅が上記ユーザプレーントラフィックの伝送に十分ではない場合であっても、グループ帯域幅上限の中から必要な帯域幅を取得できるようにすることを目的とする。また、本発明は、デバイスからネットワークへの過度なシグナリングが発生しないよう考慮しながら、デバイスが、電力消費量を抑えつつ、必要な帯域幅を取得できるようにすることを目的とする。

上記の目的を達成するため、本発明の通信装置は、複数の通信装置が特定の通信サーバとネットワークを介して通信を行っているシステムであり、前記複数の通信装置のそれぞれに割り当てられている通信のビットレートの総和が、所定の上限値を超えることができないように設定されている前記システムにおける通信装置であって、
高優先度及び高ビットレートのトラフィックの送信を行うかどうか決定する送信決定部と、
前記高優先度及び高ビットレートのトラフィックの送信を行うことを決定した場合、前記高優先度及び高ビットレートのトラフィックの送信を行うためのサービス要求を前記ネットワークへ送信するサービス要求送信部と、
前記サービス要求に対する応答であって、前記高優先度及び高ビットレートのトラフィックを送信することができないベアラのベアラ識別子を含むサービス要求応答を受信するサービス要求応答受信部と、
前記ベアラ識別子によって特定されるベアラを経由して、前記高優先度及び高ビットレートのトラフィックの送信要求を前記特定の通信サーバへ送信するトラフィック送信要求部と、
前記トラフィックの送信要求に対する応答であって、前記高優先度及び高ビットレートのトラフィックの送信が可能かどうかを示す情報を含む送信要求応答を受信するトラフィック送信要求応答受信部と、
前記送信要求応答から、前記高優先度及び高ビットレートのトラフィックの送信が可能であると判断された場合には、前記高優先度及び高ビットレートのトラフィックを前記特定の通信サーバへ送信するトラフィック送信部とを、
有する。
この構成により、高優先度、リアルタイム、高帯域幅のユーザプレーントラフィックを有するグループデバイスが存在する場合、利用可能なグループ帯域幅が上記ユーザプレーントラフィックの伝送に十分ではない場合であっても、グループ帯域幅上限の中から必要な帯域幅を取得できるようになる。また、この構成により、デバイスからネットワークへの過度なシグナリングが発生しないよう考慮しながら、デバイスが、電力消費量を抑えつつ、必要な帯域幅を取得できるようになる。

また、上記の目的を達成するため、本発明のネットワークノードは、複数の通信装置が特定の通信サーバとネットワークを介して通信を行っているシステムであり、前記複数の通信装置のそれぞれに割り当てられている通信のビットレートの総和が、所定の上限値を超えることができないように設定されている前記システムにおける前記ネットワークを構成するネットワークノードであって、
前記高優先度及び高ビットレートのトラフィックの送信を行うことを決定した前記通信装置から、前記高優先度及び高ビットレートのトラフィックの送信を行うためのサービス要求を受信するサービス要求受信部と、
前記サービス要求に対する応答として、前記高優先度及び高ビットレートのトラフィックを送信することができないベアラのベアラ識別子を含むサービス要求応答を送信するサービス要求応答送信部とを、
有する。
この構成により、高優先度、リアルタイム、高帯域幅のユーザプレーントラフィックを有するグループデバイスが存在する場合、利用可能なグループ帯域幅が上記ユーザプレーントラフィックの伝送に十分ではない場合であっても、グループ帯域幅上限の中から必要な帯域幅を取得できるようになる。また、この構成により、デバイスからネットワークへの過度なシグナリングが発生しないよう考慮しながら、デバイスが、電力消費量を抑えつつ、必要な帯域幅を取得できるようになる。

また、上記の目的を達成するため、本発明の通信サーバは、複数の通信装置が特定の通信サーバとネットワークを介して通信を行っているシステムであり、前記複数の通信装置のそれぞれに割り当てられている通信のビットレートの総和が、所定の上限値を超えることができないように設定されている前記システムにおける通信サーバであって、
高優先度及び高ビットレートのトラフィックの送信を行うことを決定した前記通信装置から、所定のベアラを経由して前記高優先度及び高ビットレートのトラフィックの送信要求を受信するトラフィック送信要求受信部と、
前記高優先度及び高ビットレートのトラフィックの送信を行うことを決定した前記通信装置以外の通信装置のうち、トラフィックの送信を中止させることができる特定の通信装置に対して、トラフィックの中止指示を送信するトラフィック中止指示部と、
前記トラフィック中止指示部によってトラフィックの送信が中止された特定の通信装置に割り当てられていた帯域幅を、前記高優先度及び高ビットレートのトラフィックの送信を行うことを決定した前記通信装置によるトラフィック用に予約し、前記トラフィックの送信要求に対する応答であって、前記高優先度及び高ビットレートのトラフィックの送信が可能であることを示す情報を含む送信要求応答を送信するトラフィック送信要求応答送信部とを、
有する。
この構成により、高優先度、リアルタイム、高帯域幅のユーザプレーントラフィックを有するグループデバイスが存在する場合、利用可能なグループ帯域幅が上記ユーザプレーントラフィックの伝送に十分ではない場合であっても、グループ帯域幅上限の中から必要な帯域幅を取得できるようになる。また、この構成により、デバイスからネットワークへの過度なシグナリングが発生しないよう考慮しながら、デバイスが、電力消費量を抑えつつ、必要な帯域幅を取得できるようになる。

本発明は、上記の構成を有しており、高優先度、リアルタイム、高帯域幅のユーザプレーントラフィックを有するグループデバイスが存在する場合、利用可能なグループ帯域幅が上記ユーザプレーントラフィックの伝送に十分ではない場合であっても、グループ帯域幅上限の中から必要な帯域幅を取得できるようにするという効果を有している。また、本発明は、上記の構成を有しており、デバイスからネットワークへの過度なシグナリングが発生しないよう考慮しながら、デバイスが、電力消費量を抑えつつ、必要な帯域幅を取得できるようにするという効果を有している。

従来の技術におけるグループベースの通信モデルを示す図 本発明の実施の形態におけるグループベースの通信モデルの構成の一例を示す図 本発明の実施の形態における動作の第１の例を示すシーケンスチャート 本発明の実施の形態における動作の第２の例を示すシーケンスチャート 本発明の実施の形態における動作の第３の例を示すシーケンスチャート 本発明の実施の形態における動作の第４の例を示すシーケンスチャート 本発明の実施の形態における動作の第５の例を示すシーケンスチャート 本発明の実施の形態におけるＭＴＣデバイスの構成の一例を示す図 本発明の実施の形態におけるＭＴＣデバイスの処理の一例を示すフローチャート 本発明の実施の形態におけるグループベースの通信モデルの構成の別の一例を示す図 本発明の実施の形態における動作の第６の例を示すシーケンスチャート 本発明の実施の形態における動作の第７の例を示すシーケンスチャート

＜発明の基本原理＞
本発明は、モバイルデバイスのグループ（例えば、ＭＴＣデバイスのグループ）が、単一又は複数のサーバ（例えば、ＭＴＣサーバ）との間でグループ通信を行っており、そのグループの所定デバイスの高優先度、広帯域幅、リアルタイムのＵプレーントラフィックに利用可能なグループビットレート又はグループ帯域幅を有していない場合に適用される。本発明の基本原理は、このような高優先度のＵプレーントラフィックを有するデバイスが、ネットワークへのシグナリング処理を利用してそのトラフィック状態を通知し、利用可能なグループ帯域幅がネットワークに存在しない場合には最小限の帯域幅のベアラを取得することである。このような最小限の帯域幅のベアラを取得した後、このデバイスは、危機的状態であること（すなわち、高優先度のＵプレーントラフィックを送信できないこと）をサーバへ通知し、その結果、サーバは、高優先度のＵプレーントラフィックを有するデバイスが利用可能なグループ帯域幅を取得するために、重要なＵプレーントラフィックを送信していないグループ内の他のデバイスの伝送を中止する。

すなわち、本発明の主要な原理に関連するステップ又は処理は以下の通りである。
あるグループのデバイスは、アプリケーションレイヤのトラフィックに関連した自身の優先状態を判断し、ネットワークへの高優先度Ｕプレーントラフィックの伝送を通知する。
さらに、ネットワーク（３ＧＰＰネットワーク）から与えられた最小限の帯域幅のベアラを利用し、Ｕプレーントラフィック状態及び利用可能なグループ帯域幅がない状態をサーバへ通知する。
低優先度Ｕプレーントラフィックを有するデバイスの伝送を中止して、高優先度Ｕプレーントラフィックを有しており帯域幅を要求しているデバイス用に帯域幅を確保するために、サーバは、アプリケーションレイヤのインテリジェンスを利用して、グループ内の他のデバイスのＵプレーントラフィック状態を特定し、低優先度のＵプレーントラフィックに使用されている帯域を解放する。
最後に、重大な遅延無く高優先度Ｕプレーントラフィックを転送できるようにするため、高優先度Ｕプレーントラフィックに必要なグループ帯域幅が利用可能な状態となったことが、高優先Ｕプレーントラフィックを有するデバイスに通知される。

＜本発明の動作シナリオ＞
以下、本発明の好適な実施の形態に係る本発明の動作シナリオについて詳細に説明する。ここでは、図２Ａを参照しながら、特に３ＧＰＰ構成に関連した動作シナリオについて説明する。なお、当業者であれば、本発明は３ＧＰＰ固有のシナリオに限定されるものではなく、他の動作シナリオに対しても同様に適用可能であることは明白である。例えば、デバイスは、広帯域アクセスメディアや、その他のタイプのアクセスメディア又はネットワークアーキテクチャを通じて、サーバとの間でグループ通信を行うことが可能である。さらに、本発明は、グループ内のデバイスの１つが、グループベースの通信モデルにおけるサーバとして機能する場合にも適用可能である。また、図２Ａに示されているシナリオは、ＭＴＣサーバと通信を行っているＭＴＣデバイスに関するものであるが、本発明が適用されるデバイスのタイプに関する制約はなく、例えばデバイスは、サービスを受けるためにネットワークに接続する機能を有する通常のモバイル端末であってもよい。

図２Ａにおいて、ＭＴＣデバイス２００ａ、２０１ａ、２０２ａ、２０３ａが、ＭＴＣサーバ２１４ａなどのサーバとの間でグループベースの通信を利用しているとする。さらに、ＭＴＣデバイス２００ａ、２０１ａ、２０２ａ、２０３ａが、関連するエンドポイントへのユーザプレーン及び制御プレーンのトラフィック伝送に、３ＧＰＰコアネットワーク２１２ａを利用しているとする。また、図２Ａに示されているＭＴＣデバイス２００ａ、２０１ａ、２０２ａ、２０３ａのユーザプレーントラフィックは、ｅＮＢからサービングゲートウェイ（Ｓ−ＧＷ）へのトンネリング機構、及び、Ｓ−ＧＷからＰ−ＧＷへの別の独立したトンネリング機構によって、ＭＴＣサーバ２１４ａに到達しているとする。図２Ａに図示されている３ＧＰＰコアネットワーク２１２ａは、非特許文献２に記載されている３ＧＰＰ拡張パケットコア（evolved packet core（ＥＰＣ））であってもよい。また、コアネットワーク２１２ａは、General Packet Radio Service（ＧＰＲＳ）コアネットワークやUniversal Mobile Telecommunication System（ＵＭＴＳ）コアネットワークであってもよく、同様に本発明が適用可能である。なお、図２Ａは、アクセスシステムとしてＬＴＥを用いた場合の構成を示しているが、ＵＭＴＳを用いた場合は、ｅＮＢはＲＮＣ／ＢＳＣ、ＭＭＥはＳＧＳＮ、ＰＧＷはＧＧＳＮに置き換えられる。

図２Ａに示されているＭＴＣデバイス２００ａ、２０１ａ、２０２ａ、２０３ａは単一の加入者によって配置されており、相互にオーバラップしない独立した領域（あるいは、オーバラップしている領域が一部のみである）に配置されているとする。独立した領域にＭＴＣデバイスを配置することは、ＭＴＣデバイスがそれぞれ独立したｅＮＢサービスエリア又はセルに配置されていることを表している。このような配置は、最も現実的な配置である。これは、すべてのＭＴＣデバイスが同一の領域に配置されるのではなく、ほとんどの場合において、ＭＴＣデバイスがそれぞれ異なる領域から情報を送信するために使用されるからである。しかしながら、領域内に検出すべき多数のマシンタイプのデータが存在しているような稀な場合には、ＭＴＣデバイス間の負荷バランスを目的として、所定の位置に複数のＭＴＣデバイスを配置することも可能である。通常、ＭＴＣデバイスは送信すべきデータがあまり多くないことを考えると、データの収集、処理、ＭＴＣサーバへの伝送のために、ＭＴＣデバイスが独立したオーバラップしない領域内に配置されることが非常に現実的な配置である。

ＭＴＣデバイスがオーバラップしない配置モデルに基づき、さらに、図２Ａに示されているように、ＭＴＣデバイス２００ａ、２０１ａ、２０２ａ、２０３ａが、ｅＮＢ２０４ａ、２０５ａ、２０６ａ、２０７ａにそれぞれ接続されているとする。さらに、ＭＴＣデバイス２００ａ、２０１ａがＮＡＳメッセージ（トラッキングエリアアップデート、サービス要求）をＭＭＥ２０８ａへ送信しようとするとき、ｅＮＢ２０４ａ及びｅＮＢ２０５ａが、ＭＴＣデバイス２００ａ及びＭＴＣデバイス２０１ａのそれぞれのために、ＭＭＥ２０８ａとの間にＳ１制御プレーンコネクション（Ｓ１−ＭＭＥ、Ｓ１−ＡＰ(Application Protocol)）のセットアップを行う。同様に、ＭＴＣデバイス２００ａ、２０１ａがアイドルモードから接続モードへ変更してサービス要求メカニズムを実行するとき、Ｓ−ＧＷ２０９ａは、ＭＭＥ２０８ａから指示を受けると、ＭＴＣデバイス２００ａ、２０１ａのそれぞれのために、ｅＮＢ２０４ａ及びｅＮＢ２０５ａとの間にＳ１ユーザプレーンコネクション（Ｓ１−ｕ、ＧＰＲＳトンネリングプロトコル（ＧＴＰ）ベアラ）のセットアップを行う。なお、サービス要求及び一般的なＮＡＳシグナリングに関連する動作メカニズムの詳細は、非特許文献２に記載されている。同様の方法で、ＭＴＣデバイス２０２ａ、２０３ａにおいても、ＭＭＥ２１１ａ及びＳ−ＧＷ２１０ａに向かう適切なベアラがセットアップされる。また、ＭＴＣデバイス２００ａ、２０１ａのために、Ｓ−ＧＷ２０９ａからＰ−ＧＷ２１３ａへのＧＴＰベアラ又はＰＭＩＰトンネルがセットアップされ、同様に、ＭＴＣデバイス２０２ａ、２０３ａのためにＳ−ＧＷ２１０ａからＰ−ＧＷ２１３ａへのＧＴＰベアラ又はＰＭＩＰトンネルがセットアップされる。

図２Ａに示されるように、３ＧＰＰネットワーク内でＭＴＣデバイスがオーバラップしない配置とすることで、あるグループのＭＴＣデバイスが異なるｅＮＢ、ＭＭＥ、Ｓ−ＧＷに接続・管理されているかもしれない。しかしながら、すべてのＭＴＣデバイスが単一のＭＴＣサーバ２１４ａと通信を行っているので、ＨＳＳに格納されている静的なコンフィギュレーションによって、同一のＰ−ＧＷ２１３ａを割り当てることが可能となる。また、Ｐ−ＧＷ２１３ａは、Ｇ−ＡＭＢＲ上限に対する通信状況を確認するエンティティ（Ｇ−ＡＭＢＲの実施ポイント）、ＡｖＧｒＢＷを計算するポイント、ＡｖＧｒＢＷ情報を通知するエンティティ又は配付するエンティティであるとする。

図２Ａで説明される動作シナリオは、グループ内のすべてのＭＴＣデバイスが異なるｅＮＢに接続しており、その結果、異なるＭＭＥ及びＳ−ＧＷに接続・管理されるかもしれない場合である。しかしながら、本発明は、ＭＴＣサーバと通信を行うグループベースの通信モデルのすべてのＭＴＣデバイスが、同一のｅＮＢ、同一のＭＭＥ、又は、同一のＳ−ＧＷに接続可能であるというシナリオに対しても同様に適用可能である。このようなシナリオでは、Ｇ−ＡＭＢＲの実施ポイントがＰ−ＧＷではなくＳ−ＧＷであってもよい。しかしながら、もしＳ−ＧＷがＧ−ＡＭＢＲの保持を行うとすれば、ＭＴＣデバイスへＡｖＧｒＢＷを通知できるようにするベアラ変更（bearer modification）処理をトリガするための新たな処理が、Ｓ−ＧＷに導入される必要がある。

＜本発明の適用が可能なシナリオ例＞
本発明の好適な実施の形態に従って、本発明の適切なシナリオ例について説明する。本発明は、このようなグループベースの帯域幅制限を課されているデバイスが、高優先度、広帯域幅、リアルタイムＵプレーンのトラフィックをサーバへ伝送する必要がある実用的な現実のシナリオに適用可能である。特に、本発明は、あるグループに属するデバイスがグループ帯域幅が制約された状態において、サーバへ送信すべき高優先度Ｕプレーントラフィックを有している一方、グループ内の他のデバイスのいくつかが高優先度Ｕプレーントラフィックをサーバへ送信していない場合に適用可能である。なお、この本発明の実施の形態は、Ｍ２Ｍグループベースの通信シナリオに関係するものであるが、本発明の範囲を逸脱することなく、他の多くの非Ｍ２Ｍシナリオに対しても本発明は適用可能である。

本発明が適用可能なＭ２Ｍグループベースの通信シナリオの一例としては、例えば、ＭＴＣ加入者が、監視カメラを用いて家や事務所における盗難や破壊行為の画像を取得するための複数のＭＴＣデバイスを配備する例が挙げられる。このような配備シナリオでは、盗難防止及び盗難検出のために、監視カメラが、共通のＭＴＣサーバに対してモニタリングしたイベントをアップデートすると考えられる。ＭＴＣ機能を有する監視カメラは電力に制限があり、バッテリ駆動式かもしれない。また、グループ内のすべての監視カメラは、同じタイプのＵプレーントラフィックをＭＴＣサーバへ同時に送信しているわけではないとする。例えば、監視カメラは、侵入者を検出すると、侵入者の顔、挙動や動作を高解像度でキャプチャした高優先度Ｕプレーントラフィックをサーバへ送信しようとするため、広帯域幅が必要となる。所定の監視カメラが高優先度ＵプレーントラフィックをＭＴＣサーバへ送ろうとしている一方、グループ内の別の監視カメラは、家庭や事務所の通常の活動をキャプチャした通常のトラフィックをＭＴＣサーバへ送信しているかもしれない。このように、高優先度Ｕプレーントラフィックを送ろうとしているが現在十分な帯域幅を有していない監視カメラのための最小限の帯域幅ベアラを取得するために、本発明が適用可能である。監視カメラは、利用可能なグループ帯域幅が不足している状態をＭＴＣサーバへ通知するために最小限の帯域幅ベアラを取得すると、最小限の帯域幅ベアラを経由して警告メッセージを伝送することによって、この状態をＭＴＣサーバへ通知する。ＭＴＣサーバは、監視カメラから帯域幅が不足しているという情報を受信すると、他の低優先度のカメラのセッションを解消し、さらに、高優先度の監視カメラに対して帯域を割り当てた後、サービスを開始するよう通知する。

本発明が適用可能なＭ２Ｍグループベース通信の別のシナリオとしては、例えば、エンターテインメントとして、カメラ機能を有するＭＴＣデバイスがリアルタイムのイベントをキャプチャしてＭＴＣサーバへ報告するよう配置されている例が挙げられる。例えば、これらのＭＴＣデバイスは、人間が介在することなく動作してリアルタイムでイベントをキャプチャし、マルチメディアトラフィックを使用してテレビ放送局に配置されているＭＴＣサーバへイベントを送信する。

さらに、本発明が適用可能なＭ２Ｍグループベースの別の通信シナリオとしては、例えば、あるグループのＭＴＣデバイスが、人間の健康状態に関するトラフィックをＭＴＣサーバへアップデートしている場合が挙げられる。ＭＴＣデバイスからのトラフィックのストリームには、例えば、人間の鼓動、体温、血糖レベルが含まれ得る。このような場合、あるグループに属する健康監視のためのＭＴＣデバイスに対してグループ帯域幅の上限が課されているならば、本発明の主要な方法を利用して、健康監視のためのＭＴＣデバイスからの高優先度Ｕプレーントラフィックに対してアクセス許可を与えることが望ましい。本発明の方法を適用することによって、著しく遅延させることなく、健康監視デバイスからの高優先度Ｕプレーントラフィックを伝送できるようにすることを目的とする。

＜Ｇ−ＡＭＢＲ実施ポイントによるベアラの処理＞
ＭＴＣデバイスがＭＴＣサーバとの間でグループベース通信を行っており、各ＭＴＣデバイスに単一又は複数のベアラが割り当てられている場合において、コアネットワークにＧ−ＡＭＢＲが実施及び実装されているときのベアラ管理実行方法について、本発明の好適な実施の形態に従って説明する。通常のＵＥのための一般的なベアラ管理は、例えば、非特許文献２に開示されている。しかしながら、本明細書では、Ｇ−ＡＭＢＲの上限が設定されている場合のベアラ管理処理について説明する。なお、Ｍ２Ｍ通信シナリオにおけるＧ−ＡＭＢＲが存在する場合のベアラ管理について説明するが、当業者であれば、あるデバイスのために単一又は複数のベアラが生成され、かつ、Ｇ−ＡＭＢＲがシステムに設定及び実装されているような任意のグループベースの通信シナリオにおいて、本発明が適用可能であることが分かるであろう。

例えば、グループの所定のＭＴＣデバイスに対して、デフォルトベアラのみが確立されているのであれば、利用可能なグループ帯域幅（すなわち、アップリンクＡｖＧｒＢＷ）が０であると通知されると、このＭＴＣデバイスは、Ｕプレーンアップリンクトラフィックを送信することができないとする。デフォルトベアラは非ＧＢＲベアラなので、通知される利用可能なグループ帯域幅が０より大きい場合には、このＭＴＣデバイスは、Ｕプレーンアップリンクトラフィックを送信することができるとする。さらに、ＡｖＧｒＢＷの値が変更された場合には常に、ベアラＱｏＳアップデートを行わないベアラ変更処理を使用することによって、利用可能なグループ帯域幅の状態がこのＭＴＣデバイスに通知されるとする。なお、単一のデフォルトベアラに関して説明されている同一の処理は、ＭＴＣデバイスに関して複数のＰＤＮコネクションが存在しており、ＭＴＣデバイスが複数のデフォルトベアラを持っている場合にも適用される。たとえ複数のデフォルトベアラが存在している場合であっても、ＡｖＧｒＢＷは、ベアラＱｏＳアップデートシグナリングではなく、単一のベアラ変更処理を利用して通知される。これは、ＡｖＧｒＢＷが所定のデフォルトベアラに関連したパラメータではなく、ＭＴＣデバイスに関連したパラメータだからである。

また、例えば、グループ内の所定のＭＴＣデバイスが専用ベアラ及びデフォルトベアラを有しており、すべての専用ベアラが非ＧＢＲベアラである場合には、このＭＴＣデバイスは、所定のベアラ又はベアラＩＤとは無関係に、ＡｖＧｒＢＷの通知を受けるかもしれない。すなわち、ＡｖＧｒＢＷは、ベアラＱｏＳアップデートを行わない単一のベアラ変更処理を使用して通知される。たとえ複数の非ＧＢＲベアラが存在していたとしても、ＭＴＣデバイスへＡｖＧｒＢＷの値を提供するために単一のベアラ変更シグナリングが使用される。これは、すべてのベアラが非ＧＢＲベアラであり、それに関連する帯域幅が存在せず、それ故、ネットワークは単にベアラ識別子に関連付けられていないＡｖＧｒＢＷを通知するだけだからである。このような場合、ＭＴＣデバイスは、ＡｖＧｒＢＷが０より大きいときにはアップリンクＵプレーントラフィックを送信し、ＡｖＧｒＢＷが０のときにはアップリンクＵプレーントラフィックを送信しない。グループ内のＭＴＣデバイスは、ＡｖＧｒＢＷが０より高いと通知された場合に、非ＧＢＲ専用ベアラ又はデフォルトベアラのどちらかを使用してＵプレーントラフィック送信を行うことが可能である。

また、別のシナリオにおいて、例えば、グループ内の所定のＭＴＣデバイスがデフォルトベアラ及びＧＢＲベアラを有している場合、ＡｖＧｒＢＷの通知は、Ｐ−ＧＷが、各専用（ＧＢＲ）ベアラに関してベアラ変更シグナリングを独立して送信し、各ＧＢＲベアラのための変更された帯域幅を通知する。これは、帯域幅がＧＢＲベアラに関係していることから、ネットワークがＡｖＧｒＢＷをＧＢＲベアラ間で分割し、その結果、各ベアラに関するベアラ変更シグナリングを送信するからである。例えばＡｖＧｒＢＷがｘの場合、Ｐ−ＧＷは、利用可能な帯域幅のほとんどをＧＢＲベアラへ対照的に又は非対称的に配分するため、ＧＢＲベアラのそれぞれに関して複数のベアラ変更処理を実行する。したがって、ＧＢＲベアラが存在するとき、ＧＢＲベアラ間におけるＡｖＧｒＢＷの個々の分配又は割り当てが必要となるので、ベアラ変更シグナリングが大きくなる。一方、複数の非ＧＢＲベアラの場合では、ＡｖＧｒＢＷを通知する単一のベアラ変更シグナリングで十分である。さらに、ＧＢＲベアラに関連してベアラ変更シグナリングが送信されるとき、その処理は、ベアラＱｏＳアップデートを行わないベアラ変更処理とは異なる。ＧＢＲベアラに関しては、ベアラ変更シグナリングがそのベアラのための帯域幅（ＧＢＲ値）を伝送するので、非特許文献２に開示されているように、その処理は、ＱｏＳアップデートを有するベアラ変更処理となる。また、デフォルトベアラに関係するＧＢＲは存在しないので、最低限の帯域幅のみがデフォルトベアラに残される。新しいＧＢＲ値がＭＴＣデバイスへ通知されると、ＭＴＣデバイスは、このＧＢＲ値がトラフィックの伝送に十分かどうかを判断して、関連するＧＢＲベアラ又はデフォルトベアラを選択することが可能となる。

所定のＭＴＣデバイスに割り当てられるベアラがデフォルトベアラ、ＧＢＲ専用ベアラ、非ＧＢＲ専用ベアラなどの場合には、Ｐ−ＧＷは利用可能なグループ帯域幅、すなわち、ＡｖＧｒＢＷのほとんどをＧＢＲベアラに割り当ててＭＴＣデバイスへ通知し、ＡｖＧｒＢＷのうちの最小限の帯域幅をデフォルトベアラ及び非ＧＢＲベアラへ割り当てる。Ｐ−ＧＷは、ＧＢＲベアラのために複数のベアラＱｏＳ変更処理を実行し、各ＧＢＲベアラに対して割り当てた帯域幅をそれぞれ通知する。デフォルトベアラ及び非ＧＢＲベアラに関しては、Ｐ−ＧＷは、ベアラＱｏＳアップデートを行わない単一のベアラ変更処理を実行し、デフォルトベアラ及び非ＧＢＲベアラのための利用可能な帯域を一括して通知する。そして、ＭＴＣデバイスは、ベアラＱｏＳアップデートを行わないベアラ変更処理で送信された利用可能な帯域幅値を使用して、１つ以上の非ＧＢＲベアラ経由でトラフィックを送信することができる。同様に、ＭＴＣデバイスは、アップリンクトラフィック送信のために関連するＧＢＲベアラを選択する際に、受信した個々のＧＢＲベアラに関するベアラＱｏＳアップデートを使用する。

また、ＭＴＣデバイスがＵプレーントラフィック伝送の際に帯域幅が保証されているＧＢＲベアラを持っていたとしても、Ｕプレーントラフィックに利用されていないＧＢＲベアラの帯域幅は、ＡｖＧｒＢＷ計算処理における帯域幅として使用されないとする。例えば、利用可能なグループ帯域幅又はＡｖＧｒＢＷを計算する際、最初のステップにおいて、ＭＴＣデバイスのグループにおいて利用されている全体の帯域幅を特定する。この帯域幅は、ＭＴＣデバイスのＵプレーントラフィックに関係する帯域幅である。そのグループで利用されている帯域幅を特定した後、利用可能なグループ帯域幅が特定可能となる。利用されている帯域幅を計算するとき、実際のＵプレーントラフィックに関係する帯域幅のみが利用されている帯域幅として考慮され、利用されていないＧＢＲベアラに関係する帯域幅は考慮されない。利用されていないＧＢＲベアラは、現在Ｕプレーントラフィックを伝送していないＧＢＲベアラである。

しかしながら、別の通信モデルでは、ＧＢＲベアラは高優先度ベアラであると考えられ、これらのベアラは、たとえＵプレーントラフィックが現在ＧＢＲベアラ経由で伝送されていない場合でも、そのグループで利用されている帯域幅を計算するために利用することが可能である。このような処理を利用することによって、ＧＢＲベアラに関係する帯域幅は、ＵプレーントラフィックがＧＢＲベアラ経由で送信されているが否かによらず、ＧＢＲベアラが許可されているＭＴＣデバイスにとって常に利用可能な状態となる。しかしながら、ＧＢＲベアラのために固定した帯域幅を常に予約しておくことは、効率的なリソース管理モデルではない。それにもかかわらず、あるシナリオでは、ＭＴＣデバイスは、利用可能なグループ帯域幅の計算処理で、利用可能であることが常に示されている帯域幅を有する特別な専用ＧＢＲベアラを確立するようネットワークへ要求することが可能である。このようなベアラを持つことによって、ＭＴＣデバイスは、高優先度トラフィックの伝送のためにこの特別な専用ＧＢＲベアラをすぐに利用することが可能であり、ＡｖＧｒＢＷを考慮する必要はない。

上述のＱｏＳベアラ管理処理は、特に、３ＧＰＰ ＥＰＳにおけるベアラ管理処理を説明しているが、当業者であれば、Ｇ−ＡＭＢＲを実行する際に説明されているベアラ管理処理が、ＭＴＣデバイスのＵプレーントラフィックがＧＰＲＳコア又はＵＭＴＳコア又はベアラ管理を利用するその他のシステムを伝送する場合においても適用可能であることが分かるであろう。

＜ＡｖＧｒＢＷがＭＭＥに格納されている際の動作＞
ベアラ変更シグナリングを送信して、Ｕプレーントラフィックの送信を現在予定していないグループ内のすべてのＭＴＣデバイスに対して、ベアラ間におけるＡｖＧｒＢＷ配分を通知することは、上述のように不要なシグナリングであり、ネットワークリソースの浪費である。さらに、ＭＴＣデバイスがアップリンクＵプレーントラフィックを送信する予定がない場合、そのＭＴＣデバイスをアイドルモードから立ち上げてベアラ全体のＡｖＧｒＢＷ配分を通知することは、ＭＴＣデバイスの電力の浪費である。したがって、ＡｖＧｒＢＷ値に変更があった場合には常に、ＭＴＣデバイスの関連ベアラの帯域幅値をＭＭＥへ通知し、ＭＴＣデバイスがＵプレーントラフィックを送信したいと思うまでＭＭＥがそれを格納することが、より良い実施例である。Ｐ−ＧＷは、新しいＡｖＧｒＢＷに関連して変更されたＭＴＣデバイスのベアラ帯域幅を、ベアラ変更処理を利用して通知し、ＭＭＥは、必要となるまではその値をＭＴＣデバイスへ通知しない。以下、本発明の好適な実施の形態に従って、このようなベアラ管理処理について説明する。以下、図２Ｂを参照しながら、本発明の実施の形態において、このようなより良いベアラ管理処理について説明する。

図２Ｂにおいて、ＭＴＣデバイス２００ｂ、２０１ｂは、ＭＴＣサーバ２０４ｂとの間でグループベースの通信を行っているＭＴＣデバイスのグループに属しているＭＴＣデバイスである。さらに、ＭＴＣデバイス２００ｂ、２０１ｂのために各ｅＮＢによって選定されたＭＭＥが、ＭＭＥ２０２ｂであるとする。さらに、Ｇ−ＡＭＢＲ実施ポイント及びＡｖＧｒＢＷ計算ポイントがＰ−ＧＷ２０３ｂであるとする。さらに、ＭＴＣデバイス２００ｂはアイドルモードである一方、ＭＴＣデバイス２０１ｂは接続モードであり、ＭＴＣサーバ２０４ｂへＵプレーントラフィックを送信しているとする。

上述のように、ある配置構成において、ＡｖＧｒＢＷ、及び、ＭＴＣデバイス２００ｂのベアラ間におけるＡｖＧｒＢＷの分配は、関連するベアラ変更処理を利用してＭＭＥ２０２ｂへ通知される。しかしながら、ＭＭＥ２０２ｂは、ＭＴＣデバイス２００ｂがアイドルモードであることを知っているので、これらのベアラコンテキストをＭＴＣデバイス２００ｂへ送信せずに、その代わり、ＭＭＥ２０２ｂの格納手段に格納する。

このような動作シナリオでは、Ｐ−ＧＷ２０３ｂは、シグナリングメッセージ２０５ｂを用いて、ＡｖＧｒＢＷに関係しているベアラであって、ＭＴＣデバイス２００ｂに関連したベアラのベアラ変更メッセージを送信すると考えられる。このメッセージ２０５ｂの内容は、ＭＭＥ２０２ｂに格納され、ＭＴＣデバイス２００ｂへは転送されない。シグナリングメッセージ２０５ｂの送信後、ＭＴＣデバイス２００ｂは、アイドルモードから接続モードへ移行し、サービス要求メッセージ２０６ｂをＭＭＥ２０２ｂへ送信したとする。ＭＭＥ２０２ｂは、ＭＴＣデバイス２００ｂのために格納されているＡｖＧｒＢＷをチェックし、ＡｖＧｒＢＷがＭＴＣデバイス２００ｂにとって十分なのものかどうかを確認することが可能である。ＭＴＣデバイス２００ｂのＡｖＧｒＢＷは、ベアラ変更メッセージ２０５ｂに埋め込まれた帯域幅情報によってＭＭＥ２０２ｂへ通知される。状態２０７ｂに示されているようにＡｖＧｒＢＷが０であれば、ＭＭＥ２０２ｂは、サービス要求応答メッセージ２０８ｂを送信し、適切な項目値（clause）を用いてサービス要求を拒絶することが可能である。なお、項目値は、例えば、ＡｖＧｒＢＷの不足による拒絶とすることが可能である。

ＡｖＧｒＢＷが０より大きい場合には、ＭＭＥ２０２ｂは、サービス応答処理２０８ｂにおいて、デフォルトベアラや専用ＧＢＲベアラに関係する帯域幅を単に通知し、Ｕプレーントラフィック伝送に関して帯域幅が十分かどうかをＭＴＣデバイス２００ｂに決定させればよい。このような場合、ＭＭＥ２０２ｂは、サービス応答ＮＡＳメッセージ２０８ｂの新たな情報要素によって、ベアラに関連した帯域幅値を通知し、拒絶の項目値によるサービス要求の拒絶は行わない。

また、ＭＴＣデバイス２００ｂがＵプレーントラフィック伝送に必要なビットレートをサービス要求２０６ｂにおいて送信した場合には、ＭＭＥ２０２ｂは、ＡｖＧｒＢＷの値及びＭＴＣデバイス２００ｂのベアラにおけるＡｖＧｒＢＷの分配に基づいて、サービス受け入れメッセージ又はサービス拒絶メッセージを送信する。要求されたビットレートをサポートする単一のＧＢＲベアラが存在する場合には、ＧＢＲベアラが許可されて、サービス要求応答メッセージ２０８ｂによってベアラ識別子が通知される。ＡｖＧｒＢＷが０より大きいが、要求されたビットレートをサポートするには十分ではない場合には、メッセージ２０８ｂでサービス拒絶が送信される。また、ＭＴＣデバイス２００ｂによって要求されたビットレートが、単一の既存ＧＢＲベアラではなく、複数のＧＢＲベアラの結合によってサポート可能である場合、ＭＭＥ２０２ｂは、サービス要求２０６ｂを拒絶し、さらに新たなベアラ値を通知すること、ベアラ情報を待機すること、ページングを受信するまでサービス要求の再試行をしないことを通知する。こうしたページング情報の待機は、メッセージ２０８ｂによって送信可能である。ＭＭＥ２０２ｂは、ＭＴＣデバイス２００ｂのためのベアラを確立するようＰ−ＧＷ２０３ｂへ要求してもよい。この新しいベアラを実現するため、既存のＧＢＲベアラが破棄され、新たなＧＢＲが作成される必要がある。ある古いＧＢＲベアラが無効化され、ＭＴＣデバイス２００ｂに必要なＧＢＲベアラが作成されると、ＭＭＥ２０２ｂは、ＭＴＣデバイス２００ｂにページングを送信することができる。ＭＴＣデバイス２００ｂはページングを受信し、ＭＭＥ２０２ｂへのサービス要求を実行する。サービス応答において、アップリンクＵプレーントラフィック送信を可能にする新しいＧＢＲベアラの属性がＭＴＣデバイス２００ｂへ送信される。

ＮＡＳメッセージ２０８ｂがサービス拒絶メッセージである場合、ＭＴＣデバイス２００ｂはランダムな時間だけ待機した後、接続モードに移行するためにサービス要求を再試行する。このような再試行のサービス要求は、図２Ｂのシグナリングメッセージ２０９ｂとして示されている。また、ここでも、グループ内のどのデバイスもアップリンクＵプレーントラフィックの送信を中止せず、ＭＭＥ２０２ｂにおけるＡｖＧｒＢＷの状態に変更はないとする。この再試行サービス要求の間に状態変更がなかったことは、状態２１０ｂとして示されている。この場合、ＭＭＥ２０２ｂは、別のサービス要求拒絶メッセージ２１１ｂをＭＴＣデバイス２００ｂへ送信する。

このシナリオにおいて、ＭＴＣデバイス２０１ｂがＵプレーントラフィック送信を停止し、その結果、送信中止メッセージ２１２ｂをＭＭＥ２０２ｂへ送信したとする。なお、このメッセージ２１２ｂはオプションのメッセージであり、必ずしも送信される必要はない。ＭＴＣデバイス２０１ｂは、ネットワークからのデタッチを実行する場合に、デタッチＮＡＳメッセージ２１２ｂをＭＭＥ２０２ｂへ送信することが可能である。このデタッチメッセージ２１２ｂは、デタッチ通知のためにさらにＰ−ＧＷ２０３ｂへ送信される。Ｐ−ＧＷ２０３ｂは、デタッチメッセージ２１３ｂを受信すると、ＡｖＧｒＢＷを再計算する。新たなＡｖＧｒＢＷは、シグナリングメッセージ２１４ｂを使用してＭＭＥ２０２ｂへ通知される。なお、シグナリングメッセージ２１４ｂによって通知されるＡｖＧｒＢＷは、ＭＴＣデバイス２００ｂのアップリンクＵプレーントラフィックを送信するのに十分であるとする。

サービス要求を再試行するメッセージ２１５ｂを再度受信したＭＭＥ２０２ｂは、空いているグループ帯域幅が利用可能な状態（状態２１６ｂ）となっているので、サービス要求受け入れメッセージ２１７ｂをＭＴＣデバイス２００ｂへ送信する。サービス要求が受け入れられたこと（メッセージ２１７ｂ）を考慮し、ＭＴＣデバイス２００ｂは、ＭＴＣサーバ２０４へのＵプレーントラフィックの送信に成功する。このＵプレーントラフィックがメッセージ２１８ｂによって示されている。この方法の利点は、必ずしもベアラ情報を送信する必要がないという点、ＭＴＣデバイスがデータを送信しようとしており、サービス要求を送信する場合にのみ通知が行われるという点にある。これにより、コアネットワークの不要なシグナリング、ページングのシグナリングが送信されるという問題が解決され、また、ＭＴＣデバイスの電力が節約される。しかしながら、図２Ｂに図示されている方法は、送信すべき高優先度トラフィックを有するＭＴＣデバイス２００ｂが、依然として、必要な帯域幅を取得するためにある程度の時間だけ待機しなければならず、また、ＭＴＣデバイス２００ｂが複数回のサービス要求シグナリングを実行して、接続モードに移行しなければならないという課題も有している。

ＭＴＣデバイス２００ｂがデタッチモードからアタッチモードへ変わる場合には、ＭＴＣデバイス２００ｂは、通常のベアラ作成処理を利用して、ベアラ関連情報を受信する。アタッチモードでは、ＭＴＣデバイス２００ｂがＭＭＥ２０２ｂへ問い合わせを行って関連するベアラパラメータを取得するか、又は、ＭＭＥ２０２ｂがベアラ情報を格納せずに渡すことが可能である。なお、３ＧＰＰ構成に関連して説明を行ったが、当業者であれば、同様の動作を行う他の構成に上述の方法を適用することが可能である。

＜本発明の主要な動作＞
次に、本発明の好適な実施の形態における動作について説明する。本発明の主要な基本原理は上述した通りであるが、ここでは、任意のネットワークアーキテクチャにおける動作について説明する。この任意のネットワークアーキテクチャは、主に３つの構成要素（例えば、ＭＴＣデバイス、ＭＴＣサーバ、ＭＴＣデバイスがＭＴＣサーバへ到達するためのネットワークコンポーネント）から構成される一般的なアーキテクチャである。このネットワークコンポーネントは、ＭＴＣデバイスからのユーザプレーントラフィック及び制御プレーントラフィックの伝送を可能にするルータ及びゲートウェイによって構成されると考えることができる。また、このネットワークコンポーネントは、アクセスネットワーク、伝送ネットワーク、さらには一般的なインターネットをも構成すると考えることができる。さらに、このネットワークコンポーネントは、接続されている各ＭＴＣデバイスに関して、単一又は複数のベアラを作成、維持することが可能である。上述のように、ＭＴＣデバイスがＵプレーン伝送のためにベアラを使用する場合、ベアラは、Ｕプレーントラフィックに提供されるＱｏＳサポートのレベルという特徴を有している。なお、本発明の主要な動作は、特に、本発明の実施の形態におけるＭ２Ｍ通信に関連した通信環境において説明されるが、当業者であれば、本発明は、このＭＴＣデバイスが任意のモバイルデバイスであって、このＭＴＣサーバが任意のタイプのサーバであるような一般的な設定においても適用可能であることが分かるであろう。

さらに本発明の動作を理解するため、図３Ａに図示されているシグナリング交換について説明する。このようなシグナリング交換の詳細を説明する前に、まず、図３Ａを参照しながら、本発明の高次の動作について説明する。図３Ａにおいて、ＭＴＣデバイス３００ａが、ネットワーク３０１ａを通じてＭＴＣサーバ３０２ａと通信しているとする。ネットワーク３０１ａは、ＭＴＣデバイス３００ａとＭＴＣサーバ３０２ａとの間のパスにおける任意のネットワークエンティティである。図３Ａに図示されている本発明に係る動作は、ＭＴＣデバイス３００ａが、高優先度、広帯域幅、リアルタイムＵプレーントラフィックを送信する必要性をネットワーク３０１ａ（これは、ネットワークエンティティを意味している）へ送信し、ＡｖＧｒＢＷが無い場合にはネットワーク３０１ａは、たとえＭＴＣデバイス３００ａが、接続されている複数のベアラを既に有していたとしても、最小限の帯域幅のベアラをＭＴＣデバイス３００ａが使用することのみを許可する。ＭＴＣデバイスのグループのための利用可能な帯域幅が無い場合（例えば、ＡｖＧｒＢＷ＝０）には、ネットワーク３０１ａは、そのグループのＭＴＣデバイス３００ａに対して、高いＱｏＳを有するベアラの使用の許可を与えることを望まず、その結果、ＭＴＣデバイス３００ａに対して最小限の帯域幅ベアラの割り当てのみを行う。最小限の帯域幅ベアラは、そのベアラに最小限の帯域幅及び低ＱｏＳが関連付けられていることを意味する。最小限の帯域幅ベアラに低ＱｏＳを与えることは、Ｕプレーントラフィックがこのベアラを通じて送信される場合にネットワーク３０１ａが優先的な取り扱いを行う必要がなく、その結果、最低限の帯域幅ベアラを経由して送信されるＵプレーントラフィックが、他のデバイスのＵプレーントラフィックフローに影響を与えないようにすることを意味する。なお、他のデバイスは、そのグループのデバイスではなくてもよい。また、最小限の帯域幅を最小限の帯域幅ベアラに割り当てることによって、ネットワーク３０１ａは、そのグループに属さない他のデバイスからの重要なリソースが、最小限の帯域幅ベアラ経由で送信されるＵプレーントラフィックに使用される必要がないようにすることを意味する。

ネットワーク３０１ａがこのような最小限の帯域幅のベアラを決定すると、ネットワーク３０１ａは、この最小限の帯域幅のベアラのベアラ識別子を、ＭＴＣデバイス３００ａへ通知する。ＭＴＣデバイス３００ａは、ネットワーク３０１ａによって返信されるベアラが最小限の帯域幅のベアラであると判断すると、静的構成に基づいてそれに関連付けられているＱＣＩを把握し、Ｕプレーントラフィック送信に関連するベアラを使用する際に、内部でＱｏＳパラメータ（すなわち、帯域幅、リンクバッファの特性）の調整を行う。なお、各ＱＣＩスカラは、任意のＱｏＳパラメータにマッピングされていると考えられる。ＭＴＣデバイス３００ａが、最小限の帯域幅ベアラのためのＱＣＩ値や、静的に格納された関連ＱｏＳパラメータを持っていないような場合には、ネットワーク３０１ａは、最小限の帯域幅のベアラのベアラＩＤに加えて、最小限の帯域幅のベアラのためのＱＣＩスカラ値や、このＱＣＩスカラに対応するＱｏＳパラメータを、ＭＴＣデバイス３００ａへ明示的に与えてもよい。

ＭＴＣデバイス３００ａは、この最小限の帯域幅のベアラについて通知されると、そのベアラを、高優先度、広帯域、リアルタイムＵプレーントラフィックを転送することが可能な何らかの帯域幅を得るための警告メッセージをＭＴＣサーバ３０２ａへ送信するために使用可能なベアラと正しく判断する。最小限の帯域幅のベアラの特性を判断した後、ＭＴＣデバイス３００ａは、この最小限の帯域幅のベアラを使用するためにＱｏＳパラメータを内部で調整する。ＭＴＣデバイス３００ａは、Ｕプレーントラフィック送信レートを、最小限の帯域幅のベアラのＱＣＩに関連する最小限の値に調整し、最小限の帯域幅のベアラに対応するＱＣＩを内部のアップリンクバッファへ入力する。ＭＴＣデバイス３００ａは、ネットワーク３０１ａにおいて帯域幅が不足している状態にあることをＭＴＣサーバ３０２ａへ通知するために、この最小限の帯域幅のベアラを使用する。このとき、ＡｖＧｒＢＷが０以上であるが、ＭＴＣデバイス３００ａに必要なＵプレーントラフィックレートがＡｖＧｒＢＷより大きい場合であっても、ネットワーク３０１ａが、最小限の帯域幅のベアラをＭＴＣデバイス３００ａへ割り当てることが重要である。

ＭＴＣサーバ３０２ａへ警告が送信されて使用されていた帯域が解放され、ＡｖＧｒＢＷを上回る帯域が存在する状態になると、ＭＴＣサーバ３０２ａは、帯域幅が解放された状態がＭＴＣデバイス３００ａへ通知される。帯域幅が利用可能な状態がＭＴＣデバイス３００ａによって認識されると、ＭＴＣデバイス３００ａは、最小限の帯域幅のベアラのためのＱＣＩを復元するようネットワーク３０１ａへ要求し、それを利用して高優先度、広帯域幅、リアルタイムＵプレーントラフィックをＭＴＣサーバ３０２aへ送信する。

以下、本発明の詳細な動作について説明する。ＭＴＣデバイス３００ａが、サービス要求シグナリング３０３ａを送信し、高優先度、広帯域幅、リアルタイムトラフィックを送信する予定であることを通知する。ＭＴＣデバイス３００ａが高優先度、広帯域幅、リアルタイムトラフィックを送ろうとしていることを示すトリガは任意の形式が可能であり、例えば、このような必要性を特徴付けるＵプレーントラフィックのビットレート、帯域幅、又は、何らかの識別子であってもよい。ネットワークエンティティ３０１ａは、そのグループに関するＡｖＧｒＢＷをチェックする。そのグループに関するＡｖＧｒＢＷが０の場合、ネットワークエンティティ３０１ａは、最小限の帯域幅のベアラのみが使用可能であることをＭＴＣデバイス３００ａへ通知する。このような最小限の帯域幅のベアラに関する情報は、応答メッセージ３０４ａで提供される。ＭＴＣデバイス３００ａは、応答メッセージ３０４ａを受信すると、最小限の帯域幅のベアラをセットアップするために必要な動作を実行する。なお、最小限の帯域幅のベアラのセットアップは、明示的なシグナリングの有無によらず実行可能である。なお、応答メッセージ３０４ａは、最小限のデータしか送ることができない時間間隔（バックオフタイマ）を示す値を含むサービス要求応答メッセージ（Service Accept）であってもよい。ＭＴＣデバイス３００ａは、受信した応答メッセージ３０４ａの中にバックオフタイマが含まれた場合には、受信したタイマが経過するまでは、高優先度や広帯域なトラフィックを送信することができないと判断する。つまり、バックオフタイマは、ＭＴＣデバイス３００ａが送信したサービス要求に対応するベアラの確立が一定時間（バックオフタイマ経過）後に行われることを示している。この場合、バックオフタイマを通知するネットワーク３０１ａ内のエンティティはＭＭＥである。

ＭＴＣデバイス３００ａは、このような最小限の帯域幅のベアラの存在及び構成を把握した後、最小限の帯域幅のベアラを使用して、メッセージ３０５ａに示されているようにＭＴＣサーバ３０２ａへ警告メッセージを送信する。また、上述したように、ネットワーク３０１ａから受信した応答メッセージ３０４ａの中にバックオフタイマが含まれていた場合には、ネットワーク３０１ａから受信したバックオフタイマが有効である間は、最小限の帯域幅のベアラを使用して、メッセージ３０５ａに示されているようにＭＴＣサーバ２０２ａへ警告メッセージを送信する。この警告メッセージ３０５ａは、ユーザプレーンメッセージであると考えられ、具体的には、何らかの帯域幅を要求するために送信されるものである。ＭＴＣサーバ３０２ａは、ネットワーク３０１ａと通信を行って、そのグループに関する帯域幅を取得するか、あるいは、何らかの手段を利用して、ＭＴＣデバイス３００ａのために帯域幅を解放する。なお、上記何らかの手段は、他のＭＴＣデバイスがあまり重要なＵプレーントラフィックをＭＴＣサーバ３０２ａへ送信していない場合に、その送信を停止するよう通知することであってもよい。ＭＴＣサーバ３０２ａとネットワーク３０１ａとの間のやり取りは図３Ａには明示されていない。ＭＴＣサーバ３０２ａは、ＭＴＣデバイス３００ａに必要な帯域幅が利用可能であることを確認した後、送信可（Clear-to-Send：ＣＴＳ）アプリケーションレイヤメッセージ３０６ａをＭＴＣデバイス３００ａへ送信する。このアプリケーションレイヤメッセージ３０６ａを受信すると、ＭＴＣデバイス３００ａは、ネットワークエンティティ３０１ａに対してベアラ変更シグナリング３０７ａを実行する。メッセージ３０７ａの目的は、最小限の帯域幅のベアラに対してより高いＱｏＳ特性を回復するよう要求するものであり、その結果、ＭＴＣデバイス３００ａは、高優先度、広帯域幅、リアルタイムＵプレーントラフィックをＭＴＣサーバ３０２ａへ送信することが可能となる。また、ＭＴＣデバイス３００ａに割り当てられるこの最小限の帯域幅のベアラ以外の別の所定のベアラが、ＭＴＣサーバ３０２ａへのＵプレーントラフィックを伝送するために十分であることをＭＴＣデバイス３００ａが把握している場合には、ＭＴＣデバイス３００ａは、最小限の帯域幅のベアラではないこのようなベアラに関してベアラ変更を実行することが可能である。

ネットワークエンティティ３０１ａは、メッセージ３０７ａによるベアラ変更要求を受け入れる前に、現在のＡｖＧｒＢＷが十分かどうかのチェックを行う。ネットワークエンティティ３０１ａが、メッセージ３０７ａに埋め込まれている要件を満たす十分な帯域幅が存在していることを把握すると、メッセージ３０８ａに示されているように、アクノレッジメントを送信する。アクノレッジメントメッセージ３０８ａでは、ネットワークエンティティ３０１ａは、最小限の帯域幅のべアラの識別子を割り当てるか、あるいは、ＭＴＣデバイス３００ａの高優先度、広帯域、リアルタイムＵプレーントラフィックを伝送することが可能な別の既存のベアラの識別子を割り当てる。メッセージ３０８ａを受信した場合は、ＭＴＣデバイス３００ａは、メッセージ３０８ａにベアラＩＤを付加したＵプレーンメッセージをＭＴＣサーバ３０２ａへ送信する。ＭＴＣサーバ３０２ａへのＵプレーンデータメッセージは、メッセージ３０９ａによって図示されている。

本発明の動作に係る上述の説明から、ＡｖＧｒＢＷが０、又は、ＭＴＣデバイス３００ａが高優先度ＵプレーントラフィックをＭＴＣサーバ３０２ａへ送信できない程度の低い値の場合に、本発明の方法を適用することで、従来技術に係る非効率性を伴わずに、必要な帯域幅が取得できることは明らかである。本発明の方法を利用して、ＭＴＣサーバ３０２ａと通信を行うために、低減されたＱｏＳを有する最小限の帯域幅のベアラがセットアップされ、その結果、ＭＴＣサーバ３０２ａは、低優先度トラフィックを送信するその他のＭＴＣデバイスを外して、ＡｖＧｒＢＷの状態をより高い値に戻すことが可能となる。この最小限の帯域幅のベアラの特別な性質は、最小限の帯域幅のベアラが既存のベアラのＱｏＳが変更されたものである場合には、変更されたＱｏＳをＭＴＣデバイス３００ａ又はルータへ通知するためにネットワークにおいて明示的なベアラ変更シグナリングの付加が行われることなく、最小限の帯域幅のベアラがＭＴＣデバイス３００ａへ割り当てられることである。最小限の帯域幅のベアラを使用してＵプレーントラフィックをＭＴＣサーバ３０２ａへ送信する際には、最小限の帯域幅のベアラのＩＤが付加され、パス上のルータは、このＩＤが最小限の帯域幅のベアラに関連していることを把握し、Ｕプレーントラフィックに関して必要最小限のＱｏＳ処理を行う。なお、最小限の帯域幅のベアラのＩＤは固有であり、最小限の帯域幅ベアラのみに関連しているとする。その結果、Ｕプレーントラフィックのパス上のルータは、たとえ明示的なベアラ変更シグナリングをネットワークから受信しなかったとしても、最小限の帯域幅のベアラのＩＤを確認したときは、行うべきＱｏＳ処理を把握する。また、既存のベアラが最小減の帯域幅のベアラである場合に、そのベアラのＩＤが最小限の帯域幅のベアラのＩＤに変更される。このような最小限の帯域幅のベアラの判断では、最小限の帯域幅のベアラのＩＤが特定のＱｏＳへマッピングされており、このようなマッピングがルータ及びＭＴＣデバイス３００ａにも事前に格納されていると考えられる。

＜３ＧＰＰシナリオにおける本発明の詳細な動作−最小限の帯域幅のベアラが変更されたＱＣＩを有するデフォルトベアラである場合＞
上述では、図３Ａに示されるシグナリング交換を実行する動作を参照しながら、以下では、デフォルトベアラが使用される場合について説明する。以下、最小限の帯域幅ベアラとしてデフォルトベアラが使用される場合について説明する。ＭＴＣデバイスとＭＴＣサーバとの間のネットワークが、非特許文献２に開示されているネットワークアーキテクチャを有し得る３ＧＰＰネットワークセグメントの場合における本発明の詳細な動作について説明する。最小限の帯域幅のベアラとして使用されるデフォルトベアラに関して、２つの場合が存在する。第１の場合は、ＭＴＣデバイスがデフォルトベアラのみを有しており、ＱｏＳが低減されたデフォルトベアラが最小限の帯域幅のベアラとみなされる場合である。第２の場合は、ＭＴＣデバイスがデフォルトベアラ及び専用ベアラを有しており、デフォルトベアラのＱｏＳを低減させずに、デフォルトベアラのみが最小限の帯域幅のベアラとして割り当てられる場合である。第２の場合において、デフォルトベアラが最小限の帯域幅のベアラとして使用されるとき、デフォルトベアラに関連するＱｏＳが低く、かつ、デフォルトベアラのためのＱｏＳパラメータを低減させる必要がないと仮定する。したがって、第２の場合には、第１の場合のようにＱＣＩ値を変更させる必要はない。

さらに、図３Ｂを参照しながら、３ＧＰＰの設定において、デフォルトベアラが最小限の帯域幅ベアラとして使用される場合の詳細な動作について説明する。ここでは、まず、ＭＴＣデバイスに関連して単一のデフォルトベアラのみが存在する場合について説明し、続いて、ＭＴＣデバイスに割り当てられている専用ベアラが存在する場合について説明する。

図３Ｂでは、ＭＴＣデバイス３００ｂ、３０１ｂは、通常、ＭＴＣサーバ３０４ｂと通信を行うものであり、Ｇ−ＡＭＢＲが課されているとする。また、ＭＴＣデバイス３００ｂ、３０１ｂには、例えば、Ｐ−ＧＷなどのネットワークエンティティ３０３ｂからＩＰアドレスが割り当てられるとする。以降、ネットワークエンティティ３０３ｂはＰ−ＧＷであるとする。また、ＭＴＣデバイス３００ｂ、３０１ｂはＭＭＥ３０２ｂに接続されているとする。このような３ＧＰＰ指向の設定では、ＭＴＣデバイス３０１ｂは、ＭＴＣサーバ３０４ｂとＵプレーン通信セッションを有しているとする。さらに、ＭＴＣデバイス３００ｂは、ＭＴＣサーバ３０４ｂへ送信すべき高優先度、広帯域幅、リアルタイムＵプレーントラフィックを有しており、ＭＴＣデバイス３００ｂは現在アイドルモードであるとする。

さらに、ＭＴＣデバイス３００ｂは、デフォルトベアラのみがセットアップされており、このようなデフォルトベアラの状態は、例えばＭＭＥ３０２ｂ、Ｐ−ＧＷ３０３ｂ、さらにはＭＴＣデバイス３００ｂなどのネットワークエンティティに保持されているとする。なお、デフォルトベアラの状態は、ベアラＩＤ、ＡＰＮ、ＱＣＩ、ＩＰプレフィックス値などを指すものである。ＭＴＣデバイス３００ｂが、そのフローに関してあまり高いＱｏＳ処理を必要としておらず、デフォルトベアラのみを使用してＭＴＣサーバ３０４ｂと通信を行うことができる場合には、ＭＴＣデバイス３００ｂがデフォルトベアラしか持っていないというシナリオが十分に考えられる。この高優先度ＵプレーントラフィックをＭＴＣサーバ３０４ｂへ送信するために、ＭＴＣデバイス３００ｂは、メッセージ３０５ｂに示されるようにサービス要求メッセージを送信する。ＭＴＣデバイス３００ｂは、高優先度、広帯域幅、リアルタイムのＵプレーントラフィックを送信する必要があることを示すためのフラグを、このサービス要求メッセージ３０５ｂに埋め込むことができる。なお、このフラグは、サービス要求メッセージ３０５ｂに付加される新たな情報要素であってもよい。また、ＭＴＣデバイス３００ｂは、このメッセージ３０５ｂに、明示的なビットレート及び帯域幅のプロファイルを埋め込むことも可能である。また、別の派生例として、ＭＴＣデバイス３００ｂが、メッセージ３０５ｂのフラグを送信し、そのフラグを確認したＭＭＥ３０２ｂが、ＭＴＣデバイス３００ｂに関するトラフィックのプロファイルを、格納されたキャッシュやデータベースから取得することが可能である。なお、この例では、ＭＴＣデバイス３００ｂのトラフィックのプロファイルがＭＭＥ３０２ｂにおいて静的に構成されている。メッセージ３０５ｂの受信後、状態３０６ｂに示すようにＡｖＧｒＢＷが０であることをＭＭＥ３０２ｂが把握した場合、ＭＭＥ３０２ｂは、メッセージ３０７ｂに示すようにサービス要求応答メッセージをＭＴＣデバイス３００ｂへ送信することが可能である。この応答メッセージ３０７ｂは、最小限の帯域幅のベアラのベアラＩＤをＭＴＣデバイス３００ｂへ通知することが望ましい。上述の実施の形態のように、ＭＴＣデバイスがアイドルモードの場合には、ベアラ変更メッセージはＭＴＣデバイスへ送信されず、ＭＭＥ３０２ｂでベアラ情報を維持することが可能である。このような最適化された動作によれば、ＭＭＥ３０２ｂは、ＭＴＣデバイス３００ｂのベアラに関するすべての情報を有しており、直ちに適切なメッセージ３０７ｂで応答することが可能である。このベアラ情報には、ＡｖＧｒＢＷの情報が含まれていてもよい。ＭＴＣデバイス３００ｂはメッセージ３０７ｂを受信し、最小限の帯域幅のベアラのベアラＩＤを確認すると、このベアラＩＤが一時的にデフォルトベアラに割り当てられていることを把握し、さらに、ネットワークがＭＴＣデバイス３００ｂへ最小限の帯域幅のベアラを割り当てるつもりであることを理解する。なお、別の実施例では、応答メッセージ３０７ｂに新たな情報要素（Cause Value）を割り当てることが可能であり、ＭＴＣデバイス３００ｂは、それを最小限の帯域幅のベアラの許可と解釈することも可能である。メッセージ３０７ｂに新たな情報要素が存在する場合には、ＭＴＣデバイス３００ｂは、ＭＴＣデバイス３００ｂに格納されている、事前に構成された最小限の帯域幅のベアラのＩＤを特定することが可能である。ＭＴＣデバイス３００ｂは、事前構成によって、最小限の帯域幅ベアラに関連するベアラＩＤを既に把握しており、応答メッセージ３０７ｂ内の情報をすぐに特定できると考えられる。なお、事前構成がない場合であっても、ＭＴＣデバイス３００ｂは、新たなベアラＩＤが応答メッセージ３０７ｂに存在する場合に、それを最小限の帯域幅のベアラのベアラＩＤと判断してもよい。また、応答メッセージ３０７ｂにバックオフタイマが含まれている場合は、そのタイマが有効である間は、最小限の帯域幅のベアラだけが許可されていると解釈する。つまり、そのタイマの有効期限が切れた場合は、通常通りのベアラを生成することが可能であると判断し、高優先度・広帯域向けのサービス要求を送信する。

最小限の帯域幅のベアラを使用してＵプレーントラフィックを送るとき、ＭＴＣデバイス３００ｂは、上述のように、最小限の帯域幅のベアラが割り当てられていることを把握し、続いて、内部でＱｏＳを変更する。最小限の帯域幅のベアラはデフォルトベアラであり、ＭＴＣデバイス３００ｂは新しいＱＣＩをデフォルトベアラに関連付ける。このような内部での関連付けは、処理３０８ｂによって示されている。最小限の帯域幅のベアラの変更及び構成が内部で行われた後、ＭＴＣデバイス３００ｂは、最小限の帯域幅ベアラＩＤをユーザプレーンパケットに関連付けることによって、Ｕプレーン警告メッセージ３０９ｂをＭＴＣサーバ３０４ｂへ送信する。なお、当業者であれば、デフォルトベアラのＩＤが静的な最小限の帯域幅のベアラのＩＤへ変更され、その結果、すべてのルータがメッセージ３０９ｂに対して最小限のＱｏＳ処理を実行することが分かるであろう。さらに、ＭＴＣデバイス３００ｂは、ＭＴＣサーバ３０４ｂへその状態を通知するため、非常に低い帯域幅のＵプレーントラフィックをＭＴＣサーバ３０４ｂへ送信する。

ＭＴＣサーバ３０４ｂは、メッセージ３０９ｂを受信すると、ＭＴＣデバイス３００ｂに必要な帯域幅を取得する方法を決定する。ある方法においては、メッセージ３０９ｂに、ＭＴＣデバイス３００ｂが送信しようとしている高優先度Ｕプレーントラフィックのビットレート情報が含まれていてもよい。このようなビットレート情報を把握することによって、ＭＴＣサーバ３０４ｂは、ＭＴＣデバイス３００ｂを収容するために解放すべき帯域幅の量を容易に把握することが可能である。ＭＴＣサーバ３０４ｂがビットレート監視特性を有する場合には、ＭＴＣサーバ３０４ｂは、ＭＴＣデバイス３００ｂのための帯域幅を取得するために送信を停止する必要があるグループ内の他のすべてのデバイスを特定することが可能である。ＭＴＣサーバ３０４ｂは、他のＭＴＣデバイスのフローがさほど重要ではないことを予測できるのであれば、他のＭＴＣデバイスの送信をストップさせるだけでよいと考えられる。ＭＴＣサーバ３０４ｂがこのようなビットレート監視特性を持っていない場合は、シャットダウンが必要なＭＴＣデバイスを特定する際の援助をしてもらうようＰ−ＧＷ３０３ｂと通信を行うことが可能である。しかしながら、ＭＴＣサーバ３０４ｂが、アプリケーションレイヤを有しており、高優先度トラフィックを送信していないグループ内のＭＴＣデバイスを特定する機能を有しているので、送信の中止が可能なＭＴＣデバイスは、ＭＴＣサーバ３０４ｂによってのみ特定される。

ＭＴＣサーバ３０４ｂは、ＭＴＣデバイス３０１ｂのＵプレーントラフィックが停止可能であることを特定した場合、メッセージ３１０ｂを使用して送信停止メッセージをＭＴＣデバイス３０１ｂへ送信する。ＭＴＣデバイス３００ｂに帯域幅を確実に提供できるようにし、別のＭＴＣデバイスによって使われないようにするため、ＭＴＣサーバ３０４ｂは、Ｐ−ＧＷ３０３ｂに対して、ＭＴＣデバイス３００ｂにおいて必要な帯域幅を明示的に予約するよう要求してもよい。この動作によれば、予約によって、ＭＴＣデバイス３００ｂに関するＡｖＧｒＢＷの値は高くなり、他のデバイスに関するＡｖＧｒＢＷ値は低くなる。ＭＴＣサーバ３０４ｂは、ＭＴＣデバイス３００ｂのために十分な帯域幅が利用可能であると把握すると、ＣＴＳメッセージをＭＴＣデバイス３００ｂへ送信する。このＣＴＳメッセージは、メッセージ３１１ｂによって示される。メッセージ３１１ｂがＭＴＣデバイス３００ｂによって受信されると、ＭＴＣデバイス３００ｂは、デフォルトベアラに対してベアラ変更を実行するよう決定する。ベアラ変更は、デフォルトベアラのＱｏＳ特性をより高い値に回復するために行われる。その結果、ＭＴＣデバイス３００ｂは、高優先度、広帯域幅、リアルタイムＵプレーントラフィックを送信することができる。ＭＭＥ３０２ｂは、デフォルトベアラ変更要求メッセージ３１２ｂを受信し、それが関係する帯域幅より大きいＡｖＧｒＢＷであるという情報を有している場合（状態３１３ｂ）には、ベアラ変更処理を実行してデフォルトベアラのためのＱＣＩを回復させる。デフォルトベアラＩＤ（最小限の帯域幅のベアラのＩＤとは異なる）は、ベアラ変更要求応答メッセージ３１４ｂによって、ＭＴＣデバイス３００ｂへ返される。

メッセージ３１４ｂによってデフォルトベアラのＩＤを受けると、ＭＴＣデバイス３００ｂは、ＭＴＣサーバ３０４ｂへのアップリンクトラフィック３１５ｂの送信を開始する。なお、派生例として、ベアラ変更要求メッセージ３１２ｂにおいて、ＭＴＣデバイス３００ｂは新たな専用ベアラを要求して、高優先度トラフィックを伝送することが可能である。さらに別の派生例として、ネットワークは、デフォルトベアラを変更する代わりに、専用ベアラを生成することが可能である。新たに生成された専用ベアラのＩＤはメッセージ３１４ｂによって通知可能である。

次に、既存のデフォルトベアラが最小限の帯域幅のベアラとして、応答メッセージ３０７ｂによってＭＴＣデバイス３００ｂへ単純に通知される第２の場合について説明する。既存のデフォルトベアラが最小限の帯域幅のベアラとして返されると、ＭＴＣデバイス３００ｂは、複数のベアラをそれに関連付けてもよい。この第２の場合では、応答メッセージ３０７ｂは単にデフォルトベアラのＩＤを伝送する。ＭＴＣデバイス３００ｂは、既存のデフォルトベアラのＩＤがメッセージ３０７ｂによって返されると、デフォルトベアラのみがＭＴＣサーバ３０４ｂへ警告メッセージ３０９ｂを送信するために使用可能であり、変更を行わないデフォルトベアラが最小限の帯域幅のベアラであると判断することが可能である。また、ＭＴＣデバイス３００ｂは、応答メッセージ３０７ｂを確認すると、警告メッセージ３０９ｂが最小限の帯域幅で送信される必要があるという判断も行う。この実施例では、デフォルトベアラのＱｏＳは非常に低く、ＭＴＣデバイス３００ｂによるＱｏＳの更なる内部変更が不要であると考えられる。したがって、ステップ３０８ｂは実行される必要はない。また、この第２の場合においても、応答メッセージ３０７ｂにバックオフタイマが含まれている場合は、そのタイマが有効である間は、デフォルトベアラが最小限の帯域幅のベアラであると判断してもよい。そして、このバックオフタイマが有効である間は、警告メッセージ３０９ｂがデフォルトベアラ上で送信される必要があるという判断も行う。

デフォルトベアラが最小限の帯域幅のベアラとして単に使用され、複数のベアラがＭＴＣデバイス３００ｂに関連付けられる実施例では、ＭＴＣデバイス３００ｂは、ベアラ変更要求３１２ｂにおいて、デフォルトベアラに関連するＱｏＳよりも高いＱｏＳを持つようデフォルトベアラを変更する要求を行うことが可能であるか、あるいは、既存の専用ベアラに対してベアラ変更を要求することが可能である。なお、ＭＴＣデバイス３００ｂは、メッセージ３１２ｂの代わりに、単純に新たな専用ベアラを要求することも可能である。ＭＭＥ３０２ｂは、要求３１２ｂを処理する方法を判断する。ＭＭＥ３０２ｂが要求３１２ｂを処理することができる方法は複数存在し、どの方法で判断を行ったとしても、本発明の主要なポイントに影響を与えるものではない。

＜本発明の別の動作−最小限の帯域幅のベアラが明示的に生成される＞
ＡｖＧｒＢＷが存在しない場合に、最小限の帯域幅のベアラが明示的に生成されることが望ましい構成も存在する。以下、このような実施例について説明する。デフォルトベアラのＱｏＳ特性が非常に低いＱｏＳ値への変更を禁止されている場合には、図３Ｃに図示されているように、最小限の帯域幅の専用ベアラを生成し、その最小限の帯域幅の専用ベアラのＱｏＳ特性を改善することが適切である。このように、最小限の帯域幅の専用ベアラを生成することが有用な場合がある。さらに、デフォルトベアラと共に、最小限の帯域幅の専用ベアラを使用する場合もある。この場合、最小限の帯域幅の専用ベアラが最小限のＱｏＳを必要とするトラフィックのために使用される場合もある。

以下、図３Ｃを参照しながら、この本発明の別の実施例の主要なステップについて説明する。本発明の主要な動作環境において、ＭＭＥが、ＭＴＣデバイスの１つ又は複数のベアラに関係するＡｖＧｒＢＷに関連したベアラコンテキストを維持し、ＭＴＣデバイスがサービス要求処理を実行するまで、ベアラコンテキストをＭＴＣデバイスへ提供しないようにすることが可能である。このベアラコンテキストは、Ｐ−ＧＷ始動のベアラ変更処理を利用して、Ｐ−ＧＷから提供されると考えられる。以下、このような動作について詳述する。

ＭＴＣデバイス３００ｃ、３０１ｃは、通常ＭＴＣサーバと通信を行い、グループベースの通信シナリオであるとする。また、ＭＴＣサーバ３０４ｃと通信を行っているＭＴＣデバイスは、Ｇ−ＡＭＢＲが課せられているとする。また、ＭＴＣデバイス３０１ｃが現在アップリンクトラフィックをＭＴＣサーバ３０４ｃへ送信している一方、ＭＴＣデバイス３００ｃはアイドルモードであるとする。なお、ＭＴＣデバイス３００ｃは、関連する複数のベアラを有していてもよい。さらに、ある経過時間後に、ＭＴＣデバイス３００ｃは、ＭＴＣサーバ３０４ｃへ送信すべきＵプレーントラフィックを有するものとする。さらに、ＭＴＣデバイス３００ｃが送信しようとしているＵプレーントラフィックが、高優先度、広帯域、リアルタイムのタイプのトラフィックであるとする。さらに、ＭＴＣデバイス３００ｃが、高優先度及び広帯域トラフィックのようなＵプレーントラフィックを分類することが可能な適切なアプリケーションレイヤインテリジェンスを有しているとする。さらに、ＭＴＣデバイス３００ｃのアプリケーションレイヤが、さらにこうしたトラフィック分類（すなわち、高優先度及び広帯域）をＮＡＳレイヤへ渡し、その結果、ＮＡＳレイヤで開始されるサービス要求が、サービス要求メッセージ内に高優先度トラフィック通知を埋め込むとする。ＭＴＣデバイス３００ｃのＮＡＳレイヤは、こうした高優先度トリガを受信すると、ＭＴＣデバイス３００ｃがサービス要求メッセージ３０５ｃをＭＭＥ３０２ｃへ送信する。このサービス要求メッセージ３０５ｃには、ＭＴＣデバイス３００ｃが、高優先度及び広帯域トラフィック伝送に関するサービス要求を実行していることを示す情報要素が存在する。

ＭＭＥ３０２ｃは、サービス要求シグナリングメッセージ３０５ｃを受信すると、まず、ＡＶＧｒＢＷがＭＴＣデバイス３００ｃのトラフィックのプロファイルを伝送するのに十分かどうかをチェックする。このようなトラフィックのプロファイル又はトラフィック特性は、サービス要求メッセージ３０５ｃに埋め込まれてもよく、また、このようなトラフィックのプロフィールのパラメータは、ビットレートであってもよい。状態３０６ｃによって示されているように、ＡｖＧｒＢＷが十分ではなく、その結果、シグナリングメッセージ３０５ｃに関する要求をサポートできない場合には、ＭＭＥ３０２ｃは、最小限の帯域幅の専用ベアラ生成処理を始動する。このような最小限の帯域幅のベアラ作成シグナリング処理は、メッセージ３０７ｃによって示されている。最小限の帯域幅の専用ベアラは、デフォルトベアラが通常関連付けられているものよりも小さいＱＣＩ（ＱｏＳ）を有している。通常、デフォルトベアラはＵプレーントラフィックに使用され、相対的に高いＱｏＳ取り扱いを有すると考えられる。しかしながら、最小限の帯域幅の専用ベアラは、主に警告又はヘルプトリガをＭＴＣサーバ３０４ｃへ送信するために使用されるため、最小限の帯域幅の専用ベアラに関しては高いＱｏＳで処理される必要はない。最小限の帯域幅の専用ベアラは、非常に小さい帯域幅が関連付けられている。

ＭＭＥ３０２ｃが十分な量のＡｖＧｒＢＷを有しており、ＭＴＣデバイスのトラフィックを伝送するために必要な帯域幅がＡｖＧｒＢＷより小さい場合には、ＭＭＥ３０２ｃは、ＭＴＣデバイス３００ｃに関連したトラフィックのために、どのベアラを割り当てるべきか（すなわち、ベアラ識別子）をチェックする。サービス要求３０５ｃがＧＢＲベアラを所望し、ＭＴＣデバイス３００ｃのＧＢＲベアラのための帯域幅がトラフィックの伝送に十分な場合には、ＧＢＲベアラが提供される。また、このようなＧＢＲベアラ要求がメッセージ３０５ｃによって提供されず、非ＧＢＲベアラプールに対して利用可能な帯域幅がトラフィックの伝送に十分な場合には、非ＧＢＲベアラが提供される。また、必要なベアラが、任意の量の帯域幅を有するＧＢＲベアラであるが、必要な帯域幅値を有するＧＢＲベアラがＭＴＣデバイス３００ｃのために存在しない場合には、ＭＭＥ３０２ｃは、既存のＧＢＲベアラを無効化し、ＭＴＣデバイス３００ｃのための広帯域ＧＢＲベアラを１つ生成する。また、要求がどんなベアラであってもよく、非ＧＢＲプールに関連する帯域幅が十分ではない場合には、ＧＢＲベアラが無効化され、非ＧＢＲベアラが提供されてもよい。また、上述の説明から、ＡｖＧｒＢＷがＭＴＣデバイス３００ｃのトラフィックを伝送するために十分ではない場合には、最小限の帯域幅の専用ベアラが生成されることは明らかである。その他の場合においては、適当なベアラが特定され、サービス要求応答メッセージ３０８ｃによって提供される。

すべての非ＧＢＲベアラが利用可能な帯域幅、及び、所定のＭＴＣデバイスの全ての単一ＧＢＲベアラに関連する帯域幅の総和は、ＡｖＧｒＢＷ値に等しいことが重要である。例えば、４つの非ＧＢＲベアラと２つのＧＢＲベアラとが存在し、各ＧＢＲベアラに関連する帯域幅が１０ユニットであり、ＡｖＧｒＢＷが６０ユニットの場合には、すべての非ＧＢＲベアラが利用可能な帯域幅は、（６０−（１０＋１０））＝４０ユニットとなる。また、非ＧＢＲベアラプールに関連する帯域幅は、ＡｖＧｒＢＷ−（ＧＢＲベアラ全ての関連する帯域幅）となる。

最小限の帯域幅の専用ベアラは、様々な方法で作成することが可能である。非特許文献２で説明されている既存のベアラ新規作成処理によれば、ＭＭＥ始動のベアラ生成処理は存在しないが、本発明に係る最小限の帯域幅の専用ベアラの作成に関しては、ＭＭＥ３０２ｃが、新しいシグナリング処理を用いることでＰ−ＧＷ３０３ｃに対してベアラ生成要求をトリガできるようにしてもよい。ＭＭＥ３０２ｃは、何らかの特別なトリガをＰ−ＧＷ３０３ｃへ送信することが可能であり、Ｐ−ＧＷ３０３ｃは、Ｐ−ＧＷ始動の専用ベアラ生成処理を開始することができる。この最小限の帯域幅の専用ベアラは、最小限のＱｏＳパラメータを提供する専用ベアラ及び非ＧＢＲベアラである。もし、ＡｖＧｒＢＷが存在せずに（すなわち、ＡｖＧｒＢＷが０）、最小限の帯域幅専用ベアラが生成されると、Ｐ−ＧＷ３０３ｃは、この最小限の帯域幅の専用ベアラに関してトラフィックのシェーピングを実行せず、ＰＣＲＦに対してＧ−ＡＭＢＲ違反を通知する必要がある。

最小限の帯域幅の専用ベアラが作成されると、サービス要求成功ＮＡＳメッセージ３０８ｃが、ＭＴＣデバイス３００ｃへ送信されることが望ましい。ＭＴＣデバイス３００ｃは、最小限の帯域幅の専用ベアラが確立されたことを示すサービス応答メッセージ３０８ｃを確認すると、最小限の帯域幅の専用ベアラを使用して、本質的には制御トラフィックと同様のアプリケーションのトラフィックを送信する。なお、応答メッセージ３０８ｃにバックオフタイマが含まれている場合は、そのタイマが有効である間は、警告メッセージを送信するための最小限の帯域幅の専用ベアラだけが許可されていると解釈する。つまり、そのタイマの有効期限が切れた場合は、通常通りのベアラを生成することが可能であると判断し、高優先度・広帯域向けのサービス要求を送信する。さらに、この最小限の帯域幅の専用ベアラに関するＥＰＳベアラ識別子は、メッセージ３０８ｃによって送信されるとする。このようなＭＴＣサーバ３０４ｃに送信されるＵプレーン警告メッセージは、メッセージ３０９ｃとして示される。このＵプレーン警告メッセージ３０９ｃを受信すると、ＭＴＣサーバ３０４ｃは、グループ内の高優先度又は重要なトラフィックに関わっていないと考えられる他のＭＴＣデバイスのトラフィックを特定する処理を開始する。ここで、ＭＴＣサーバ３０４ｃは、重要ではないトラフィックを送信しているデバイスとして、ＭＴＣデバイス３０１ｃを特定したとする。また、ＭＴＣサーバ３０４ｃは、重要ではないトラフィックを識別するために十分なインテリジェンスを持っており、その結果、ＭＴＣサーバ３０４ｃが、送信を停止させるためにＭＴＣデバイス３０１ｃへのアプリケーションレイヤメッセージの送信を行うとする。このような送信停止メッセージは、メッセージ３１０ｃとして示される。ＭＴＣサーバ３０４ｃは、ＭＴＣデバイス３０１ｃが送信を中止したことを特定すると、さらに、最小限の帯域幅の専用ベアラを使用してＭＴＣデバイス３００ｃへ送信可（ＣＴＳ）アプリケーションメッセージを送信する。あるＭＴＣデバイス３０１ｃがグループ帯域幅を共有しないように外すことによって、他のＭＴＣデバイス３００ｃのための十分な帯域幅を確保することが可能となる。また、送信停止の依頼が可能な他のＭＴＣデバイスが存在しないか（すなわち、グループ内の他のＭＴＣデバイスも高優先度トラフィックを送信している）、又は、グループに属する任意の他のＭＴＣデバイスをグループから外しても必要な帯域幅を得ることができない場合には、ＭＴＣデバイス３００ｃは、帯域幅が解放されるのを待機する必要がある。しかしながら、一般的に、ＭＴＣデバイス３００ｃが高優先度トラフィックを送信しようとしているときに、グループ内の他のＭＴＣデバイスも高優先度トラフィックを送信している場合は非常に稀であり、その結果、上述の待機時間は許容可能な限界内となることが多いと考えられる。また、ＭＴＣデバイス３０１ｃを外した後に帯域幅が十分であるかどうかを決定する方法や、送信可メッセージ３１１ｃを送信するよう決定する方法においても、多くの様々な実施例が存在する。ある実施例では、ＭＴＣサーバ３０４ｃがビットレート監視機能を有し、この機能を用いてＭＴＣデバイス３００ｃへのＣＴＳの送信を決定することが可能である。

ＭＴＣデバイス３００ｃは、送信可メッセージ３１１ｃを受信すると、新たなＧＢＲベアラに関して全く新しい要求を生成するのではなく、最小限の帯域幅の専用ベアラのベアラ変更を行うよう要求する付加的な決定処理をトリガする。このようなベアラ変更処理は、ＧＢＲベアラに必要な帯域幅を取得するために実行される。非特許文献２で説明されているベアラ作成及び変更に関連する標準的な処理によれば、専用ベアラの生成はＰ−ＧＷ３０３ｃによってのみ実行可能である。従って、ＭＴＣデバイス３００ｃが、最小限の帯域幅専用ベアラに関してベアラ変更処理を始動することが最も適切である。最小限の帯域幅の専用ベアラを要求するベアラ変更要求は、ＭＭＥ３０２ｃへ送信されるシグナリングメッセージ３１２ｃによって示されている。通常、ベアラ変更要求はＮＡＳメッセージである。ＭＭＥ３０２ｃは、ベアラ変更要求をＭＴＣデバイス３００ｃから受信すると、現在の利用可能なグループ帯域幅の状態３１３ｃに基づいて適切にベアラ変更要求に対して応答を行う。

ＭＴＣデバイス３０１ｃからの送信停止によって、状態３１３ｃは、適切なＡｖＧｒＢＷを反映して、ＭＴＣデバイス３００ｃの高優先度トラフィックを伝送できるようにするものである。ＭＴＣデバイス３０１ｃが送信を停止すると、Ｐ−ＧＷ３０３ｃが、ＭＭＥ３０２ｃに対してＡｖＧｒＢＷ情報の通知を行うとする。その結果、ＭＭＥ３０２ｃは、ベアラ変更要求３１２ｃに対して肯定的なアクノレッジメントメッセージを送信する。このようなアクノレッジメントメッセージはシグナリングメッセージ３１４ｃによって示される。最小限の帯域幅の専用ベアラに関するベアラ変更は、Ｐ−ＧＷ３０３ｃで実行されてＭＭＥ３０２ｃへ通知されてもよく、あるいは、ＭＭＥ３０２ｃで実行されてＰ−ＧＷ３０３ｃへ通知されてもよい。ＭＴＣデバイス３００ｃは、最小限の帯域幅の専用ベアラに関する適切なベアラ変更をＭＭＥ３０２ｃから受信すると、ＭＴＣサーバ３０４ｃへのＵプレーントラフィックの送信を開始する。このＭＴＣサーバ３０４ｃへのトラフィックはメッセージ３１５ｃによって示される。

上記解決方法の説明から、ＭＴＣデバイス３００ｃは、再試行シグナリングを追加することなく、高優先度及び広帯域幅トラフィックをＭＴＣサーバ３０４ｃへ送信するために必要な帯域幅を取得し、これにより、本発明の目的を実現することが可能である。必要な帯域幅は、このような最小限の帯域幅の専用ベアラをセットアップすることによって取得される。なお、上述の解決方法の派生例は３ＧＰＰ特有のシナリオで説明されているが、これらの派生例に関してもは、本発明を逸脱しない範囲で、同様の動作方法を有するシステムに適用可能である。

＜本発明の別の動作−ＭＴＣサーバがネットワークエンティティへ管理を委譲する＞
また、本発明の別の実施例では、ＭＴＣサーバからのＣＴＳメッセージがＭＴＣデバイスへ送信される必要はない。寧ろ、Ｐ−ＧＷは、ＡｖＧｒＢＷへの状態変更を検出すると、ベアラ変更要求をＭＭＥへ送信し、ＭＴＣデバイスに必要な帯域がＭＴＣサーバによって解放されたかどうかをＭＭＥが判断することが可能である。ＭＭＥは、帯域が解放されることを決定すると、Ｐ−ＧＷから送信されたベアラ変更メッセージをＭＴＣデバイスへ渡す。以下、この本発明の好適な実施の形態の派生例について説明する。なお、本発明に係るこの派生例の動作を３ＧＰＰ特有の構成を用いて説明するが、当業者であれば、ＭＴＣデバイスとＭＴＣサーバとの間のパスが任意の一般的なネットワークセグメントであっても、同様の動作が有効であることが分かるであろう。

図４において、ＭＴＣデバイス４００は、通常、ＭＴＣサーバ４０４に対してＰ−ＧＷ４０３経由でＵプレーントラフィックを送信する。ＭＴＣデバイス４０１がＵプレーントラフィックをＭＴＣサーバ４０４へ送信しており、ＭＴＣデバイス４００がアイドルモードであるとする。また、ＭＴＣデバイス４００、４０１は、グループベースの通信をＭＴＣサーバ４０４との間で行い、グループ帯域幅の上限が課せられているとする。また、本発明の説明における動作の全ての仮定が適用され、動作の詳細及び仮定は上述の通りであるため、ここでは説明を省略する。

上述の本発明の動作と同様に、ＭＴＣデバイス４００は、メッセージ４０６に示されているように、高優先度トラフィック伝送トリガが付加されたサービス要求メッセージを送信することが可能である。次に、ＭＭＥ４０２は、状態４０７を使用し、ＭＴＣデバイス４００のトラフィック要件を満たす利用可能なグループ帯域幅が利用可能ではないことを決定する。ＭＭＥ４０２は、最小限の帯域幅のベアラを決定し、望ましくはサービス要求応答メッセージ４０８によって、最小限の帯域幅のベアラのベアラ識別子を通知する。次に、ＭＴＣデバイス４００は緊急のトラフィックの警告をＭＴＣサーバ４０４へ送信する。このメッセージ（ＰＡＭ：Priority Alarm Message）はメッセージ４０９によって示される。そして、ＭＴＣサーバ４０４は、ＭＴＣデバイス４００がグループ帯域幅の共有から除外可能かどうかをチェックする。ＭＴＣサーバ４０４は、ＭＴＣデバイス４００に関連するビットレートを取得するためにＰ−ＧＷ４０３と通信を行って、どのデバイスがグループ帯域幅の共有から除外する必要があるかをチェックする。なお、ＭＴＣサーバ４０４とＰ−ＧＷ４０３との間のやり取りは、インタフェース４１２を使用して行うことが可能である。ＭＴＣサーバ４０４がＰ−ＧＷ４０３と通信を行うため、Ｐ−ＧＷ４０３とＭＴＣサーバ４０４との間にアプリケーションプロトコルインタフェース（Application Protocol Interface：ＡＰＩ）が必要となる。通信が中止される必要があるＭＴＣデバイスを特定することをＭＴＣサーバ４０４が決定する際のチェック処理は、状態４１０によって示される。ＭＴＣサーバ４０４は、このようなＭＴＣデバイス４００を特定すると、送信停止メッセージ４１１をＭＴＣデバイス４０１へ送信する。

ここで図３Ａとは異なり、ＭＴＣサーバ４０４は、ＣＴＳメッセージをＭＴＣデバイス４００へ送信しない。ＭＭＥ４０２は、ＭＴＣデバイス４００に対して高優先度及び広帯域幅トラフィックの送信を開始するための通知処理を援助する。ＭＴＣデバイス４０１が送信を中止すると、Ｐ−ＧＷ４０３におけるＡｖＧｒＢＷの状態が変更され、ＡｎＧｒＢＷの値がＰ−ＧＷ４０３において増大する。その結果、Ｐ−ＧＷ４０３は、上述のようにベアラ変更処理を利用して、ベアラ変更シグナリング４１３をＭＴＣデバイス４００へ送信する。ＭＭＥ４０２は、これらのベアラ変更シグナリング４１３を調べ、ＡｖＧｒＢＷがＭＴＣデバイス４００に高優先度及び広帯域トラフィックを転送させるのに十分かどうかを決定する。このような決定処理は、上述のものと同様であり、ここでは説明を省略する。

ＭＭＥ４０２は、ＭＴＣデバイス４００がサービスを開始することができると判断すると、ＭＴＣデバイス４００が使用すると思われるベアラに関して、関連ベアラ変更メッセージをＭＴＣデバイス４００へ渡す。あるいは、最小限の帯域幅専用ベアラが存在するだけならば、ＭＭＥ４０２は、この最小限の帯域幅の専用ベアラに関連するベアラ変更メッセージをＭＴＣデバイス４００へ渡す。ＭＭＥ４０２からＭＴＣデバイス４００へ送信されたベアラ変更シグナリングメッセージは、シグナリング４１４によって示されている。ベアラ変更メッセージ４１４を受信すると、ＭＴＣデバイス４００は、そのアップリンク高優先度トラフィック伝送に対して、通知された専用ベアラを使用することが可能である。また、専用ベアラが存在しない場合には、ＭＭＥ４０２は、デフォルトベアラのみをＭＴＣデバイス４００へ通知する。このようなＵプレーントラフィック伝送は、メッセージ４１５によって示される。

この方法の主な利点は、図４に説明されているように、ＭＴＣデバイス４００がベアラ変更処理を始動する必要がないことである。その結果、電力制約のあるＭＴＣデバイスのバッテリ電力を節約できるという利点がある。また、別の利点として、ＭＴＣデバイス４００がＣＴＳメッセージを待機する必要がなく、必要なベアラを取得するまでの待ち時間が小さいという利点もある。明示的な最小限の帯域幅のベアラが生成される本発明の別の動作として、最小限の帯域幅の専用ベアラが、初期アタッチ処理の間に生成されてネットワークによって維持されるようにすることも可能である。最小限の帯域幅の専用ベアラは非常に小さいネットワークリソースしか使用しないので、このベアラは、ネットワークに負荷をかけることなく、事前に生成可能でありネットワークで維持可能であると考えられる。また、最小限の帯域幅の専用ベアラを事前に作成する利点として、最小限の帯域幅のベアラが作成されるのを待つことなく、メッセージ４０８のようなサービス要求応答メッセージが送信可能となる点も挙げられる。

＜ＭＴＣデバイスの機能図＞
次に、本発明の好適な実施の形態におけるモバイルデバイス（例えば、ＭＴＣデバイス）の機能アーキテクチャについて説明する。以下、図５を参照しながら、各機能コンポーネントについて説明する。図５に示される機能コンポーネントは、本発明を実行するモバイルデバイスの好適な実現手段である。しかしながら、当業者であれば、図５に図示されている主要な機能コンポーネントは、本発明の範囲から逸脱しない別の方法で実現可能であることが分かるであろう。

図５に図示されている機能アーキテクチャは、上述されている本発明を実行するためにＭＴＣデバイスで必要となるすべてのハードウェア、ソフトウェア、フォームウェアを有している。ＭＴＣデバイスの機能アーキテクチャ５００は、例えば、アプリケーションレイヤ５０５、ＩＰレイヤ（ＩＰルーティングレイヤ）５０４、ＮＡＳレイヤ５０３、ＡＳレイヤ５０２、無線通信レイヤ５０１などの機能ブロックを有している。このような標準的なレイヤ又は機能ブロックに加えて、機能アーキテクチャ５００は、さらに、本発明に係る動作を実現するためのモジュール（最小限ベアラ必要性推定モジュール５０６、高品質（高優先度＋広帯域幅）サービス要求トリガモジュール５０７、最小限広帯域幅ベアラ変更決定モジュール５０８、最小限広帯域幅ベアラ変更トリガモジュール５０９）を有している。さらに、これらの機能エンティティ間には、モジュール間で情報の受け渡しを行うための適切なシグナリングインタフェースが設けられている。

ＮＡＳレイヤ５０３は、主に、ＭＴＣデバイスとそのＭＭＥとの間のＮＡＳシグナリングのやり取りに使用される。このようなＮＡＳシグナリングは、トラッキングエリア更新、アイドル状態からアクティブ状態への変更時のサービス要求、ＰＤＮコネクション確立、ＰＤＮコネクション削除、ベアラ変更処理、アタッチ処理、デタッチ処理において使用可能である。また、ＡＳレイヤ５０２は、ＭＴＣデバイスとｅＮＢ間の全てのシグナリングのために使用される。ＡＳレイヤ５０２のシグナリングは、ＭＴＣデバイスとｅＮＢとの間の無線ベアラを確立するために使用される。また、ＡＳレイヤ５０２は、セル選択とセル監視機能のために用いられる。アプリケーションレイヤ５０５からのユーザプレーントラフィックは、ＩＰレイヤ５０４を経由して送信されてＡＳレイヤ５０２に届き、最終的に無線通信レイヤ５０１経由で送信される。ユーザプレーンパケットのデータユニット伝送を実現するため、インタフェース５１２、５１１、５１０が使用される。同様に、ＮＡＳメッセージを伝送するために、適切なインタフェースがＮＡＳレイヤ５０３において使用される。このようなインタフェースは、図５で示されるインタフェース５１４、５１０である。また、無線通信レイヤ５０１は、ＭＴＣデバイスの物理レイヤのプロトコルを有している。

ＭＴＣデバイスは、送信すべき高優先度及び広帯域幅トラフィックを有していると判断すると、高優先度及び広帯域幅トリガが埋め込まれたサービス要求をトリガする。高優先度トラフィックのためのサービス要求をトリガするという判断は、モジュール５０６で実行される。高優先度トラフィックのためのサービス要求をトリガするという判断は、ＮＡＳレイヤ５０３からのトリガに基づいて、又は、アプリーケーションレイヤ５０５へのダイレクトインタフェースを使用することによって行われ得る。例えば、アプリケーションレイヤ５０５は、ＭＴＣデバイスが高優先度トラフィックを有しているをモジュール５０６へ通知すると、広帯域幅ベアラが必要とされ、高優先度トリガがサービス要求に含まれる必要があると判断することができる。このような決定がモジュール５０６で行われると、制御はインタフェース５１５を通じてモジュール５０７へ渡される。

モジュール５０７は、ＮＡＳレイヤ５０３へ渡されるべき関連データを形成又は収集する。この関連データは、ビットレートや、高優先度、広帯域幅トラフィックなどを表すための何らかのデータであってもよい。モジュール５０７は、インタフェース５１６を使用してＮＡＳレイヤ５０３へ制御データを渡す。また、モジュール５０７は、最小限の帯域幅のベアラに関するネットワークからの応答情報を処理する機能を有している。最小限の帯域幅のベアラがデフォルトベアラであり、最小限の帯域幅のベアラのＩＤが固有である場合には、ＭＴＣデバイスは、この情報を処理し、ＱｏＳを内部で変更する。このような機能もモジュール５０７に関連付けられている。

ＮＡＳレイヤ５０３は、新たな情報要素に高優先度トラフィックであることが挿入されたサービス要求メッセージを生成し、ＡＳレイヤ５０２及び無線通信レイヤ５０１を通じて高優先度トラフィックのためのサービス要求を送信する。このサービス要求を送信した後、ＭＴＣデバイスはＭＴＣサーバからＣＴＳを受信する。このような場合に、アプリケーションレイヤ５０５は、モジュール５０８へトリガを送信し、最小限の帯域幅のベアラのためのベアラ変更処理をトリガできることを通知する。アプリケーションレイヤからのＣＴＳ受信トリガの処理はモジュール５０８で実行される。最小限の帯域幅のベアラのためのベアラ変更をトリガする決定がモジュール５０８で決定されると、制御はシグナリングインタフェース５１８を通じてモジュール５０９へ渡される。モジュール５０９では、トリガの決定が行われ、ＮＡＳレイヤ５０３は、最小限の帯域幅の専用レイヤのためのベアラ変更を送信するよう要求される。モジュール５０９からＮＡＳレイヤ５０３へのトリガは、シグナリングインタフェース５１７経由で実行される。

＜デバイスの動作のフローチャート＞
次に図６を参照しながら、本発明の好適な実施の形態におけるモバイルデバイスの動作について説明する。第１ステップとして、チェックプロセス６００がトリガされ、モバイルデバイス（ＭＴＣデバイスであってもよい）は、高優先度及び広帯域幅トラフィックを転送するための広帯域幅ベアラが必要か否かをチェックする。こうしたチェックは、ステップ６００で実行される。このステップ６００によって、高優先度及び広帯域トラフィックが送信される必要があるかどうかが特定される。このステップ６００が『いいえ』の場合には、ステップ６０１が実行される。ステップ６０１は、高優先度トラフィック及び広帯域幅トラフィックを通知するための新たな情報要素が付加されることのなく、通常のサービス要求をトリガする通常の処理を有している。また、ステップ６００が『はい』の場合には、ステップ６０２が実行される。ステップ６０２では、高優先度トラフィックに関する新しい情報が付加されたサービス要求が作成されて送信される。ステップ６０２を実行した後、決定処理がトリガされる。この決定処理はステップ６０３によって示される。ステップ６０３では、高優先度トリガが付加されたサービス要求が受け入れられたかどうかがチェックされる。非常に稀にしか起こらないが、高優先度トラフィックに関する帯域幅を取得するために最小限の帯域幅のベアラのためのサービス要求が受け入れられなかった場合には、制御はステップ６０４に渡され、ＭＴＣデバイスは、後でサービス要求をリトライすることを決定する。

ステップ６０３が『はい』であり、ＭＭＥがサービス要求応答によって最小限の帯域幅のベアラを提供する場合には、制御はステップ６０５に渡される。ステップ６０５では、ＭＴＣデバイスは、デフォルトベアラが与えられた場合にはベアラに関するＱＣＩを低減させ、最小限の帯域幅のベアラを使用して警告メッセージをＭＴＣサーバへ送信する。警告メッセージをＭＴＣサーバへ送信した後、ＭＴＣデバイスはＭＴＣサーバからのＣＴＳを待機し、ステップ６０６に示すようにＣＴＳ受信状態のチェック処理を実行する。ＣＴＳを受信すると、ステップ６０８が実行され、ＭＴＣデバイスは、デバイス始動ベアラ変更処理を使用して、最小限の帯域幅に係るＱＣＩを増加させるよう要求する。また、ステップ６０６が『いいえ』の場合には、ステップ６０７が実行され、ＭＴＣデバイスは単にＣＴＳを待機し続けるか、あるいは、利用可能な帯域幅を用いて緊急トラフィックに関連する情報をＭＴＣサーバへ送信する。

＜本発明が応用された派生例＞
次に、本発明の好適な実施の形態に従った派生的な応用例について説明する。本発明の派生例は、コアネットワークが時間制御機能（Time Controlled）を実装しており、ＭＴＣデバイスが時間許容アプリケーションを有する構成において性能を拡張するために使用される。時間制御機能は、トラフィック伝送のためにネットワークを使用するＭＴＣデバイスのアクセス時間に係るネットワーク制御を表す。時間制御機能がネットワークに存在している場合、ＭＴＣデバイスが時間許容（Time Tolerant）アプリケーションを有するときには、この時間制御機能の影響をほとんど受けない。なお、時間許容及び時間制御の詳細は、非特許文献１に説明されている。ネットワークが時間制御メカニズムを動作しているとき、ネットワークは、ＭＴＣデバイスに対してこの状態を通知し、その結果、ＭＴＣデバイスは、時間制御期間の間はネットワークを通じてトラフィックを送信しない。なお、ほとんどの場合において、ＭＴＣサーバではなくＭＴＣデバイスのみが、この時間制御期間を把握している。時間制御期間が伝送される瞬間に、ネットワークが、ＭＴＣデバイス上の時間制御をＭＴＣデバイスへ課すことを決定した場合には、ＭＴＣデバイスは帯域幅を有さず、時間制御状態に関してＭＴＣサーバへ通知するためのアクセスさえ行わない。図７Ａを参照しながら、このような時間制御トラフィック伝送環境に本発明を適用した場合について説明する。

本発明の派生的な応用例では、最小限の帯域幅のベアラを生成することによって、ＭＴＣデバイスは、輻輳状態又はコアネットワークにおける時間制御状態をＭＴＣサーバへ通知することが可能である。輻輳状態又は時間制御状態をＭＴＣサーバへ通知することによって、ＭＴＣサーバが、ネットワークによって時間制御されたＭＴＣデバイスへ、Ｕプレーントラフィックを送信しないようにすることが可能となる。ＭＴＣサーバは、このような時間制御状態においてＭＴＣデバイスへトラフィックを送信し続けるならば、ネットワークに複数の問題をもたらすことになる。第１の問題は、時間制御状態が取り除かれるまでダウンリンクトラフィックに必要となる格納リソースである。第２の問題は、バッファオーバフローによってデータが失われてしまうかもしれないという問題である。

以下、図７Ａを参照しながら、応用例について説明する。図７Ａでは、ＭＴＣデバイス７０９、７０８、７０７、７０６がＰ−ＧＷ７０１を通じてＭＴＣサーバ７０２と通信を行っている。また、これらのＭＴＣデバイスは、ｅＮＢ７１０、Ｓ−ＧＷ７０４、ＭＭＥ７０５に接続されており、ＭＴＣサーバ７０２とグループ通信を行っているとする。上述のように、コアネットワーク７００及び／又はアクセスネットワーク７０３が輻輳状態である場合には、ネットワークは、Ｕプレーントラフィック送信のためにＭＴＣデバイスが３ＧＰＰネットワークへアクセスすることが禁止されていることをＭＴＣデバイスへ通知する。さらに、これらのＭＴＣデバイスは時間許容トラフィックを有しているとする。

このような場合、ＭＴＣサーバ７０２は、時間制御条件を把握していないかもしれず、何らかの制御又はポーリングメッセージをこれらのＭＴＣデバイスへ送信してしまい、ネットワークリソースを浪費してしまうことになる。このような問題を解決するために、例えば、ＭＴＣデバイス７０９は、こうしたネットワークの時間制御状態の通知を受けた場合には、デフォルトベアラ７１２に加えて、最小限の帯域幅のベアラ７１１を生成するようネットワークへ要求することが可能である。このような最小限の帯域幅のベアラ７１１は、時間制御又は輻輳状態であることをＭＴＣサーバへ通知するためだけのものである。最小限の帯域幅のベアラ７１１を使用することで、ＭＴＣデバイス７０９は、メッセージをＭＴＣサーバ７０２へ送信し、時間制御状態であることを通知する。ＭＴＣサーバ７０２がこのような情報を処理するとき、ＭＴＣサーバ７０２は、時間制御期間が満了するまで、ＭＴＣデバイス７０９へのメッセージの送信を中止する。なお、時間制御ウィンドウが静的であるならば、ウィンドウ期間をＭＴＣサーバ７０２に通知することが可能である。一方、動的な時間制御ウィンドウ期間の場合には、ネットワークは、時間制御の満了の瞬間をランダムに通知し、ＭＴＣデバイス７０９は、最小限の帯域幅のベアラを使用して、時間制御の終了をＭＴＣサーバ７０２へ通知する。

ＭＴＣデバイス７０９は、ＭＴＣサーバ７０２へのトラフィックの送信を再開すると、最小限の帯域幅のベアラに関してモバイルデバイス始動のベアラ変更処理を実行するか、新たな専用ベアラを要求し、この後使用するために休止モード（dormant mode）において最小限の帯域幅のベアラを保持する。

＜本発明の派生的な応用例の詳細な説明＞
以下、図７Ｂを参照しながら、本発明のさらに別の派生的な応用例について説明する。ＭＴＣデバイス７００ａは、任意のネットワークセグメント７０１ａを使用してＭＴＣサーバ７０２ａと通信を行っている。この任意のネットワークセグメント７０１ａは、３ＧＰＰネットワークセグメントであってもよい。また、ネットワーク７０１ａは、加入しているＭＴＣデバイス上で何らかの時間制御を課しているとする。ここでは、時間制御は、ＭＴＣデバイスがある明確な期間の間はネットワーク７０１ａの使用を禁じられることを意味する。また、ネットワークに輻輳が発生している場合に、ネットワークが時間制御を課してもよい。ネットワーク７０１ａからＭＴＣデバイス７００ａへ送信される時間制御情報は、メッセージ７０３ａによって示されている。このメッセージ７０３ａは任意のタイプのメッセージを用いて送信されてもよい。３ＧＰＰ構成では、時間制御メッセージ７０３ａは、ページングトリガ、サービス要求受け入れ、あるいは、任意のＮＡＳメッセージによって送信可能であり、特定のメッセージに限定されるものではない。

ＭＴＣデバイス７００ａは、このメッセージ７０３ａを確認すると、そのサーバ（ＭＴＣサーバ７０２ａ）と通信を行うための最小限の帯域幅のベアラを取得するため、サービス要求メッセージ７０４ａをネットワーク７０１ａへ送信する。最小限の帯域幅のベアラの要求７０４ａは、主に、ＭＴＣデバイス７００ａの時間制御状態をＭＴＣサーバ７０２ａへ通知するために実行される。ネットワーク７０１ａは、上述のように最小限の帯域幅のベアラを作成し、最小限の帯域幅のベアラのＩＤを有する応答メッセージ７０５ａをＭＴＣデバイス７００ａへ送信する。このようなＭＴＣデバイス７００ａへの応答メッセージと最小限の帯域幅のベアラの確立は、メッセージ７０５ａ、７０６ａによってそれぞれ示されている。

ここで、時間制御が課される期間が、ＭＴＣサーバ７０２ａには知らされていないとする。このとき、ＭＴＣサーバ７０２ａからＭＴＣデバイス７００ａへ不要なトラフィックが送信されないようにするため、ＭＴＣデバイス７００ａは、最小限の帯域幅のベアラを使用して、Ｕプレーン警告メッセージをＭＴＣサーバ７０２ａへ送信する。このような警告メッセージは、メッセージ７０７ａによって示される。ＭＴＣサーバ７０２ａは、この警告メッセージを確認すると、適切な設定を行って、ＭＴＣデバイス７００ａへのＵプレーントラフィックを妨げるか又は中断する。これは、状態７０８ａに示される。また、ある時間経過した後、ネットワーク７０１ａは、ＭＴＣデバイス７００ａの時間制御を緩和する決定を行う。時間制御の緩和は、明示的なメッセージ７０９ａによって送信可能である。ネットワーク７０１ａは、時間制御期間を事前に把握している場合には、その期間情報をメッセージ７０３ａによって送信する。しかしながら、ほとんどの場合、ネットワーク７０１ａは、この時間制御の正確な期間を知らず、明示的なトリガ７０９ａによってＭＴＣデバイス７００ａに通知しようとする。ＭＴＣデバイス７００ａは、メッセージ７０９ａを受信すると、ＵプレーントラフィックをＭＴＣサーバ７０２ａへ送信するための最小限の帯域幅のベアラを拡張するよう、ネットワーク７０１ａへ要求する。このようなベアラ変更シグナリングは、メッセージ７１０ａ、７１１ａによって示されている。アップリンクのデータ送信はメッセージ７１２ａによって示され、ダウンリンクのデータメッセージはメッセージ７１４ａによって示される。

＜制御プレーンシグナリングを使用して、帯域幅が不足している状態をＭＴＣサーバへ通知する本発明の派生例＞
上述の説明では、最小限の帯域幅のベアラが構成されると、ＭＴＣデバイスが最小限の帯域幅のベアラを使用して、Ｕプレーン警告メッセージをＭＴＣサーバへ送信する本発明の動作について説明した。このＵプレーン警告メッセージは、ＡｖＧｒＢＷが０であることを通知するため、又は、ＭＴＣデバイスが時間制御状態であることを通知するために使用可能である。このような時間制御又はＡｖＧｒＢＷが無い状態において最小限の帯域幅のベアラを割り当て、このベアラを使用してＭＴＣサーバへＵプレーン警告メッセージを送信することにはいくつかの利点がある。第１の利点は、このような最小限の帯域幅のベアラの割り当てによって、ＭＴＣデバイスが接続モードに切り換えられ、その結果、ＭＴＣサーバが送信可情報を通知しようとした場合に、より簡単にＭＴＣサーバがデバイスと通信を行えるようになるという点である。ＭＴＣデバイスが接続モードの場合、接続モードでページングを受信する際の遅延がなく、その結果、接続モードへの移行に関連した遅延が発生しないことから、ＭＴＣサーバからのメッセージの受信にほとんど時間を要さない。第２の利点は、ＭＴＣデバイスは接続モード時にはＭＴＣサーバから到達可能なので、ネットワークからのページングシグナリングや、ＭＴＣデバイスからのサービス要求シグナリングを回避できるようになる点である。第３の利点は、ＭＴＣデバイスはＵプレーン警告メッセージを使用してＭＴＣサーバへ通知を行うので、このメッセージは、別の手段（帯域メッセージ以外）又はＭＴＣサーバへのホップバイホップ転送を用いた場合よりも短い時間でＭＴＣサーバへ送信可能であるという点である。

しかしながら、ＭＴＣサーバへ通信を行うことが可能であり、ＭＴＣデバイスのＡｖＧｒＢＷ＝０の状態を通知することが可能な帯域幅がないときには、ＭＴＣデバイスがその現在の緊急状態を制御プレーンシグナリングを用いてＭＴＣサーバへ通知し、依然としてアイドル状態のままでいることが有益となる場合もある。一般に、ＭＴＣデバイスがアイドルモードにあるときは、位置更新の頻度が小さく、ＭＴＣデバイスがハンドオフ管理のためのセルモニタリングを実行する必要がないので、電力消費が低いと考えられる。本発明の好適な実施の形態によれば、帯域幅が不足している状態にあること又は時間制御状態にあることに関する警告メッセージは、制御プレーンメッセージによってＭＴＣサーバへ通知される。

本発明の別の実施例として、ＭＴＣデバイスが制御プレーンメッセージをネットワークへ送信し、帯域幅が不足している状態であること又は時間制御状態であることについて、ネットワークからＭＴＣサーバへ通知することが可能である。ＭＴＣサーバへ通知するためにＣプレーンメッセージを使用すると、ＭＴＣデバイスが接続モードとなる必要が無いという利点に加えて、ネットワークが何らかの別の手段を使用することで、コアネットワークを伝送させずにＭＴＣサーバと通信できるという別の利点がある。これは、特に、ネットワークが輻輳しているか、割り当てられるべき帯域がない場合に有用である。また、帯域幅が不足している状態（すなわち、ＡｖＧｒＢＷ＝０）、又は、輻輳による時間制御状態を通知するために制御プレーンを使用する更なる利点として、ＭＴＣデバイスとネットワークとの間のインタフェースでは、Ｕプレーンメッセージと比較して制御プレーンメッセージのパケットサイズが小さいという点も挙げられる。通常、レイヤ化されたプロトコルアーキテクチャによれば、Ｕプレーンメッセージのサイズは大きくなる。したがって、帯域幅制約環境の下で、制御プレーンシグナリングを使用してＭＴＣデバイスの警告状態をネットワークへ通知することは有用である。さらに、図８を参照しながら、本発明のシグナリング交換について説明する。

図８において、ＭＴＣデバイス８００は、ネットワークセグメント８０１を経由してＭＴＣサーバ８０２と通信を行っている。このネットワークセグメント８０１は、３ＧＰＰネットワークであってもよいが、３ＧＰＰネットワークに限定されるものではない。このような構成において、ＭＴＣデバイス８００は高優先度、広帯域幅、リアルタイムＵプレーントラフィックをＭＴＣサーバ８０２へ送信しようとしているかもしれない。ＭＴＣデバイス８００は現在アイドルモードであり、この高優先度トラフィックを送信するために、ネットワーク８０１へのサービス要求メッセージ８０３の送信を行うとする。さらに、メッセージ８０３がネットワーク８０１で受信された場合にＡｖＧｒＢＷの値が０であるとする。なお、ネットワーク８０１が、メッセージ８０３を受信したときに、ＭＴＣデバイス８００に時間制御を課すよう決定したとしてもよい。上述のネットワーク状態において、ネットワーク８０１は、適切な項目を有するサービス要求拒絶メッセージ８０４を送信することが可能である。この拒絶項目は、例えば、ネットワークが、拒絶の理由がＡｖＧｒＢＷが十分ではないか、ネットワーク８０１において時間制御アクティブであるかのどちらであることを通知するものである。

ＭＴＣデバイス８００は、メッセージ８０４を受信すると、Ｕプレーンメッセージを使用してＭＴＣサーバ８０２へ届くベアラがないことを把握し、アイドルモードのままとなる。また、メッセージ８０４の拒絶項目を受信した後、ＭＴＣデバイス８００は、決定処理を行って、ネットワーク８０１へＣプレーンメッセージを送信することを決定する。このＣプレーンメッセージは、ＭＴＣデバイス８００の状態をＭＴＣサーバ８０２へ通知するよう要求するものである。このＣプレーンメッセージは、ネットワーク８０１が３ＧＰＰネットワークである場合には、ＴＡＵであってもよく、また、任意のＮＡＳメッセージであってもよい。Ｃプレーンメッセージ８０５には、ＡｖＧｒＢＷ＝０の状態に関する情報、又は時間制御状態に関する情報が埋め込まれている。また、メッセージ８０５には、このような状態情報がＭＴＣサーバ８０２へ渡される必要性に関する情報も含まれている。ネットワークエンティティ８０１は、制御メッセージ８０５を受信し、別の新たな制御メッセージ８０６をＭＴＣサーバ８０２へ送信する。制御メッセージ８０６には、ＭＴＣデバイス８００の状態情報が含まれている。なお、メッセージ８０６は、ネットワーク８０１及びＭＴＣサーバ８０２を接続しているコアネットワークを経由して送信される必要はなく、別のネットワークを通じてメッセージ８０６を送信することが可能である。

ＡｖＧｒＢＷが０であることを通知するためのメッセージ８０６がＭＴＣサーバ８０２へ送信された場合、ＭＴＣサーバ８０２は、上述のように、ＭＴＣデバイス８００のために何らかの利用可能な帯域幅を取得しようと試みる。ＭＴＣサーバ８０２は、ＭＴＣデバイス８００のための帯域幅を取得すると、ＣＴＳメッセージ８０７をＭＴＣデバイス８００へ送信することが可能となる。ＭＣＴデバイス８００は、前回サービス要求を行ったときにネットワーク８０１によって無線ベアラが割り当てられておらず、アイドルモードなので、ネットワーク８０１は、ページングメッセージ８０８をＭＴＣデバイス８００へ送信する。ページングメッセージ８０８を受信すると、ＭＴＣデバイス８００は、サービス要求メッセージ８０９を送信し、接続モードへ移行する。サービス要求８０９が受け入れられ、ＭＴＣデバイス８００が接続モードへ移行し、すべての無線ベアラがセットアップされると、ＭＴＣデバイス８００は、ネットワーク８０１にバッファされているＣＴＳメッセージ８０７を受信することが可能となる。

さらに、ＭＴＣサーバ８０２がＡｖＧｒＢＷに付加されている何らかの帯域幅を取得したことにより、ＡｖＧｒＢＷが０より大きいので、ネットワーク８０１は、サービス要求受け入れメッセージ８１０をＭＴＣデバイス８００へ送信する。このサービス要求受け入れメッセージ８１０は、高優先度、広帯域幅、リアルタイムトラフィックを転送するための適切な帯域幅が利用可能であることに関する通知を有していてもよい。サービス要求が受け入れられることは、無線ベアラがＭＴＣデバイス８００のためにセットアップされることを意味する。さらに、ＣＴＳメッセージ８０７が無線ベアラを通じてＭＴＣデバイス８００へ送信されるとする。ＣＴＳメッセージ８０７を受信すると、ＭＴＣデバイス８００は、適切なベアラを使用して、ＵプレーントラフィックをＭＴＣサーバ８０２へ送信できるようになる。なお、ＭＴＣサーバ８０２へのＵプレーントラフィック送信は、メッセージ８１１によって示される。

また、ＡｖＧｒＢＷが０より大きい場合、ネットワーク８０１は、ＣＴＳメッセージ８０７を待機せずにページングメッセージを送信することも可能である。また、別の派生的な応用例では、ＭＴＣデバイス８００は、このようなトリガをサービス要求メッセージ８０３に挿入することにより、緊急トラフィックに関する警告メッセージを送信することが可能である。また、ＡｖＧｒＢＷが０ならば、サービス要求８０３が挿入された警告メッセージの処理が行われた後、制御プレーンメッセージがＭＴＣサーバ８０２へ送信される。

なお、本発明は、最も実用的かつ好適な実施の形態であると考えられるものを示し、説明を行っているが、当業者であれば、本発明の範囲から逸脱しない程度にデザイン及びパラメータの詳細について様々な派生例が存在することが分かるであろう。

また、上記の本発明の実施の形態の説明で用いた各機能ブロックは、典型的には集積回路であるＬＳＩ（Large Scale Integration）として実現される。これらは個別に１チップ化されてもよいし、一部又はすべてを含むように１チップ化されてもよい。なお、ここでは、ＬＳＩとしたが、集積度の違いにより、ＩＣ（Integrated Circuit）、システムＬＳＩ、スーパーＬＳＩ、ウルトラＬＳＩと呼称されることもある。

また、集積回路化の手法はＬＳＩに限るものではなく、専用回路又は汎用プロセッサで実現してもよい。ＬＳＩ製造後に、プログラムすることが可能なＦＰＧＡ（Field Programmable Gate Array）や、ＬＳＩ内部の回路セルの接続や設定を再構成可能なリコンフィギュラブル・プロセッサを利用してもよい。

さらには、半導体技術の進歩又は派生する別技術によりＬＳＩに置き換わる集積回路化の技術が登場すれば、当然、その技術を用いて機能ブロックの集積化を行ってもよい。例えば、バイオ技術の適応などが可能性としてあり得る。

本発明は、パケット交換型データ通信ネットワークにおける通信技術に関する。本発明は、特に、グループベースの通信において、グループに帯域幅の上限（グループ帯域幅上限値）が設定されている場合の技術に適用可能である。また、本発明は、特に、マシントゥーマシン通信及びマシンタイプ通信の技術に適用可能である。

ＭＴＣデバイスのユニークな特性に関して具体的に実装されるネットワーク最適化を提供するためのサービス及びアーキテクチャ要件を画策するため、３ＧＰＰのＳＡ１（Service & System Aspects 1）及びＳＡ２（Service & System Aspects 2）ワーキンググループにおいて標準化が行われている。ＭＴＣデバイスに関連するサービス要件及びネットワーク最適化は、例えば、下記の非特許文献１に開示されている。非特許文献１に開示されているＭＴＣ関連のサービス要件の多くは、ＭＴＣ通信のためのネットワークを最適化すること、又はネットワークを改善することをターゲットとしている。非特許文献１には、単一の加入者に属し、ＭＴＣサーバと通信を行っているＭＴＣデバイスのグループに対して、帯域幅の上限が課されるというサービス要件が開示されている。ここでは、このようなグループ向けの帯域幅の上限を、グループ全体最大ビットレート（group bandwidth maximum bit rate：Ｇ−ＡＭＢＲ）と呼ぶことにする。この非特許文献１では、帯域幅に関連するすべてのパラメータは、ビット／秒の単位で表されている。Ｇ−ＡＭＢＲは、アップリンク、及び／又は、ダウンリンクに関して独立して割り当て可能である。なお、アップリンクＧ−ＡＭＢＲは、ＵＬ−Ｇ−ＡＭＢＲと記載し、ダウンリンクＧ−ＡＭＢＲは、ＤＬ−Ｇ−ＡＭＢＲと記載する。ユーザプレーン（Ｕプレーン）トラフィックが主にアップリンクであるＭ２Ｍグループ通信モデルでは、ＵＬ−Ｇ−ＡＭＢＲのみが適用されてもよい。また、ダウンリンクが支配的な場合も同様に、ＤＬ−Ｇ−ＡＭＢＲのみが適用されてもよい。Ｇ−ＡＭＢＲが適用されている場合、グループに属する多数のＭＴＣデバイスが行っているユーザプレーントラフィックに関するトータルの帯域幅が、いかなるときでもＧ−ＡＭＢＲを超えることはできない。このようなグループの上限を超えると、実施ポイント（帯域幅の使用状況をチェックするポイント）においてトラフィックのシェーピングが行われる。上述のグループベースの通信モデルでは、すべてのＭＴＣデバイスが同一のサーバと通信を行っているので、すべてのＭＴＣデバイスは、同一のパケットデータネットワークゲートウェイ（packet data network gateway：Ｐ−ＧＷ）を利用し、その結果、トラフィック実施ポイントはＰ−ＧＷとなる。このＧ−ＡＭＢＲを割り当てるための主要な動機は、グループ内のすべてのＭＴＣデバイスが同時にコアネットワークを使用する際に必要とされるトータルの帯域幅より小さい値のＧ−ＡＭＢＲを設定することである。

さらに、図１に示されているＭＴＣデバイスは低電力であり、ＡｖＧｒＢＷをアップデートするためにＭＴＣ１０４、１０５を不要に起動させることは、電力供給に制限のあるＭＴＣデバイスの電力を浪費してしまうことになる。また、図１に示されているシナリオにおいて、ある時間が経過した後、ＭＴＣデバイス１０３が、送信すべきアップリンクＵプレーントラフィックを有するとする。ＭＴＣデバイス１０３のトラフィックは、リアルタイム、高優先度、広帯域幅であり、遅延させることはできず、また、レートのコントロールもできない。ＭＴＣデバイス１０３に通知されるＡｖＧｒＢＷは、ＭＴＣデバイス１０３が必要とするビットレートをサポートできないものであるとする。ＡｖＧｒＢＷが十分ではないので、高優先度、リアルタイム、広帯域幅トラフィックは、ＭＴＣサーバ１０２に届かない。例えば、ＭＴＣデバイス１０３、１０４、１０５、１０６は、異なるｅＮＢのサービスエリアを渡って様々な地域に配置される監視カメラであるかもしれない。この場合、ＭＴＣデバイス１０３は、侵入者の侵入に関係する重要な情報を送っているかもしれない。こうした重要なメッセージは、リアルタイムで送信される必要があり、侵入者の姿や動作をはっきりとキャプチャするため、広帯域幅が必要である。このように、グループ帯域幅に上限が設定されているモデルにおいて、ＭＴＣデバイス１０３からのＵ−プレーントラフィックが、遅延無くＭＴＣサーバ１０２に到達できるようにすることが必要不可欠である。なお、ここではＭＴＣデバイスによって構成されるグループベースの通信シナリオの問題について説明しているが、当業者であれば、任意のタイプのグループベースの通信に起こる問題であると判断できるであろう。

サービス要求を再試行するメッセージ２１５ｂを再度受信したＭＭＥ２０２ｂは、空いているグループ帯域幅が利用可能な状態（状態２１６ｂ）となっているので、サービス要求受け入れメッセージ２１７ｂをＭＴＣデバイス２００ｂへ送信する。サービス要求が受け入れられたこと（メッセージ２１７ｂ）を考慮し、ＭＴＣデバイス２００ｂは、ＭＴＣサーバ２０４ｂへのＵプレーントラフィックの送信に成功する。このＵプレーントラフィックがメッセージ２１８ｂによって示されている。この方法の利点は、必ずしもベアラ情報を送信する必要がないという点、ＭＴＣデバイスがデータを送信しようとしており、サービス要求を送信する場合にのみ通知が行われるという点にある。これにより、コアネットワークの不要なシグナリング、ページングのシグナリングが送信されるという問題が解決され、また、ＭＴＣデバイスの電力が節約される。しかしながら、図２Ｂに図示されている方法は、送信すべき高優先度トラフィックを有するＭＴＣデバイス２００ｂが、依然として、必要な帯域幅を取得するためにある程度の時間だけ待機しなければならず、また、ＭＴＣデバイス２００ｂが複数回のサービス要求シグナリングを実行して、接続モードに移行しなければならないという課題も有している。

ＭＴＣデバイス３００ａは、このような最小限の帯域幅のベアラの存在及び構成を把握した後、最小限の帯域幅のベアラを使用して、メッセージ３０５ａに示されているようにＭＴＣサーバ３０２ａへ警告メッセージを送信する。また、上述したように、ネットワーク３０１ａから受信した応答メッセージ３０４ａの中にバックオフタイマが含まれていた場合には、ネットワーク３０１ａから受信したバックオフタイマが有効である間は、最小限の帯域幅のベアラを使用して、メッセージ３０５ａに示されているようにＭＴＣサーバ３０２ａへ警告メッセージを送信する。この警告メッセージ３０５ａは、ユーザプレーンメッセージであると考えられ、具体的には、何らかの帯域幅を要求するために送信されるものである。ＭＴＣサーバ３０２ａは、ネットワーク３０１ａと通信を行って、そのグループに関する帯域幅を取得するか、あるいは、何らかの手段を利用して、ＭＴＣデバイス３００ａのために帯域幅を解放する。なお、上記何らかの手段は、他のＭＴＣデバイスがあまり重要なＵプレーントラフィックをＭＴＣサーバ３０２ａへ送信していない場合に、その送信を停止するよう通知することであってもよい。ＭＴＣサーバ３０２ａとネットワーク３０１ａとの間のやり取りは図３Ａには明示されていない。ＭＴＣサーバ３０２ａは、ＭＴＣデバイス３００ａに必要な帯域幅が利用可能であることを確認した後、送信可（Clear-to-Send：ＣＴＳ）アプリケーションレイヤメッセージ３０６ａをＭＴＣデバイス３００ａへ送信する。このアプリケーションレイヤメッセージ３０６ａを受信すると、ＭＴＣデバイス３００ａは、ネットワークエンティティ３０１ａに対してベアラ変更シグナリング３０７ａを実行する。メッセージ３０７ａの目的は、最小限の帯域幅のベアラに対してより高いＱｏＳ特性を回復するよう要求するものであり、その結果、ＭＴＣデバイス３００ａは、高優先度、広帯域幅、リアルタイムＵプレーントラフィックをＭＴＣサーバ３０２ａへ送信することが可能となる。また、ＭＴＣデバイス３００ａに割り当てられるこの最小限の帯域幅のベアラ以外の別の所定のベアラが、ＭＴＣサーバ３０２ａへのＵプレーントラフィックを伝送するために十分であることをＭＴＣデバイス３００ａが把握している場合には、ＭＴＣデバイス３００ａは、最小限の帯域幅のベアラではないこのようなベアラに関してベアラ変更を実行することが可能である。

上述の本発明の動作と同様に、ＭＴＣデバイス４００は、メッセージ４０６に示されているように、高優先度トラフィック伝送トリガが付加されたサービス要求メッセージを送信することが可能である。次に、ＭＭＥ４０２は、状態４０７を使用し、ＭＴＣデバイス４００のトラフィック要件を満たす利用可能なグループ帯域幅が利用可能ではないことを決定する。ＭＭＥ４０２は、最小限の帯域幅のベアラを決定し、望ましくはサービス要求応答メッセージ４０８によって、最小限の帯域幅のベアラのベアラ識別子を通知する。次に、ＭＴＣデバイス４００は緊急のトラフィックの警告をＭＴＣサーバ４０４へ送信する。このメッセージ（ＰＡＭ：Priority Alarm Message）はメッセージ４０９によって示される。そして、ＭＴＣサーバ４０４は、ＭＴＣデバイスがグループ帯域幅の共有から除外可能かどうかをチェックする。ＭＴＣサーバ４０４は、ＭＴＣデバイス４００に関連するビットレートを取得するためにＰ−ＧＷ４０３と通信を行って、どのデバイスがグループ帯域幅の共有から除外する必要があるかをチェックする。なお、ＭＴＣサーバ４０４とＰ−ＧＷ４０３との間のやり取りは、インタフェース４１２を使用して行うことが可能である。ＭＴＣサーバ４０４がＰ−ＧＷ４０３と通信を行うため、Ｐ−ＧＷ４０３とＭＴＣサーバ４０４との間にアプリケーションプロトコルインタフェース（Application Protocol Interface：ＡＰＩ）が必要となる。通信が中止される必要があるＭＴＣデバイスを特定することをＭＴＣサーバ４０４が決定する際のチェック処理は、状態４１０によって示される。ＭＴＣサーバ４０４は、このようなＭＴＣデバイス４０１を特定すると、送信停止メッセージ４１１をＭＴＣデバイス４０１へ送信する。

Claims (12)

1. 複数の通信装置が特定の通信サーバとネットワークを介して通信を行っているシステムであり、前記複数の通信装置のそれぞれに割り当てられている通信のビットレートの総和が、所定の上限値を超えることができないように設定されている前記システムにおける通信装置であって、
   高優先度及び高ビットレートのトラフィックの送信を行うかどうか決定する送信決定部と、
   前記高優先度及び高ビットレートのトラフィックの送信を行うことを決定した場合、前記高優先度及び高ビットレートのトラフィックの送信を行うためのサービス要求を前記ネットワークへ送信するサービス要求送信部と、
   前記サービス要求に対する応答であって、前記高優先度及び高ビットレートのトラフィックを送信することができないベアラのベアラ識別子を含むサービス要求応答を受信するサービス要求応答受信部と、
   前記ベアラ識別子によって特定されるベアラを経由して、前記高優先度及び高ビットレートのトラフィックの送信要求を前記特定の通信サーバへ送信するトラフィック送信要求部と、
   前記トラフィックの送信要求に対する応答であって、前記高優先度及び高ビットレートのトラフィックの送信が可能かどうかを示す情報を含む送信要求応答を受信するトラフィック送信要求応答受信部と、
   前記送信要求応答から、前記高優先度及び高ビットレートのトラフィックの送信が可能であると判断された場合には、前記高優先度及び高ビットレートのトラフィックを前記特定の通信サーバへ送信するトラフィック送信部とを、
   有する通信装置。
2. 前記サービス要求応答に含まれる前記ベアラ識別子が、最小限の帯域幅を有するベアラを示すものであり、前記トラフィック送信要求部は、前記ベアラ識別子によって識別される前記最小限の帯域幅を有するベアラを経由して、前記トラフィックの送信要求を前記特定の通信サーバへ送信するよう構成されている請求項１に記載の通信装置。
3. 前記サービス要求応答に含まれる前記ベアラ識別子が、デフォルトベアラを示すものであり、前記トラフィック送信要求部は、前記ベアラ識別子によって識別される前記デフォルトベアラを経由して、前記トラフィックの送信要求を前記特定の通信サーバへ送信するよう構成されている請求項１に記載の通信装置。
4. 前記送信要求応答から、前記高優先度及び高ビットレートのトラフィックの送信が可能であると判断された場合には、前記ベアラ識別子によって特定されるベアラを経由して前記高優先度及び高ビットレートのトラフィックを前記特定の通信サーバへ送信することが可能となるように、前記ベアラ識別子によって特定されるベアラの帯域幅を変更する処理を行うベアラ変更部を有し、
   前記トラフィック送信部が、前記ベアラ変更部によって帯域幅が変更された前記ベアラ識別子によって特定されるベアラを経由して前記高優先度及び高ビットレートのトラフィックを前記特定の通信サーバへ送信するよう構成されている請求項１に記載の通信装置。
5. 前記トラフィック送信要求部が、前記高優先度及び高ビットレートのトラフィックの送信要求を、ユーザプレーン又は制御プレーンのどちらかのメッセージを利用して前記特定の通信サーバへ送信するよう構成されている請求項１に記載の通信装置。
6. 複数の通信装置が特定の通信サーバとネットワークを介して通信を行っているシステムであり、前記複数の通信装置が前記特定の通信サーバと行っている前記通信のそれぞれのビットレートの総和が、所定の上限値を超えることができないように設定されている前記システムにおける前記ネットワークを構成するネットワークノードであって、
   前記高優先度及び高ビットレートのトラフィックの送信を行うことを決定した前記通信装置から、前記高優先度及び高ビットレートのトラフィックの送信を行うためのサービス要求を受信するサービス要求受信部と、
   前記サービス要求に対する応答として、前記高優先度及び高ビットレートのトラフィックを送信することができないベアラのベアラ識別子を含むサービス要求応答を送信するサービス要求応答送信部とを、
   有するネットワークノード。
7. 前記高優先度及び高ビットレートのトラフィックの送信を仮に許可した場合に前記システム内のビットレートの総和が前記所定の上限値を超えてしまわないかどうかをチェックする上限値超過チェック部と、
   前記上限値超過チェック部で前記総和が前記所定の上限値を超えないと判断された場合には、前記高優先度及び高ビットレートのトラフィックを送信することができるベアラのベアラ識別子を含むサービス要求応答を送信する送信するサービス要求許可応答送信部とを、
   有し、
   前記上限値超過チェック部で前記総和が前記所定の上限値を超えてしまうと判断された場合にのみ、前記サービス要求応答送信部が、前記サービス要求に対する応答として、前記高優先度及び高ビットレートのトラフィックを送信することができないベアラのベアラ識別子を含むサービス要求応答を送信するよう構成されている請求項６に記載のネットワークノード。
8. 前記上限値超過チェック部で前記総和が前記所定の上限値を超えてしまうと判断された場合に、前記通信装置が前記高優先度及び高ビットレートのトラフィックの送信要求を前記特定の通信サーバへ送信するためのベアラを設定するための処理を、前記ネットワークを構成する他のネットワークノードとの間で実行するベアラ設定処理部を有し、
   前記サービス要求応答送信部が、前記サービス要求に対する応答として、前記ベアラ設定処理部で設定を行ったベアラのベアラ識別子を含むサービス要求応答を送信するよう構成されている請求項７に記載のネットワークノード。
9. 前記サービス要求応答に含まれる前記ベアラ識別子が、最小限の帯域幅を有するベアラを示すものである請求項６に記載のネットワークノード。
10. 前記サービス要求応答に含まれる前記ベアラ識別子が、デフォルトベアラを示すものである請求項６に記載のネットワークノード。
11. 複数の通信装置が特定の通信サーバとネットワークを介して通信を行っているシステムであり、前記複数の通信装置のそれぞれに割り当てられている通信のビットレートの総和が、所定の上限値を超えることができないように設定されている前記システムにおける通信サーバであって、
    高優先度及び高ビットレートのトラフィックの送信を行うことを決定した前記通信装置から、所定のベアラを経由して前記高優先度及び高ビットレートのトラフィックの送信要求を受信するトラフィック送信要求受信部と、
    前記高優先度及び高ビットレートのトラフィックの送信を行うことを決定した前記通信装置以外の通信装置のうち、トラフィックの送信を中止させることができる特定の通信装置に対して、トラフィックの中止指示を送信するトラフィック中止指示部と、
    前記トラフィック中止指示部によってトラフィックの送信が中止された特定の通信装置に割り当てられていた帯域幅を、前記高優先度及び高ビットレートのトラフィックの送信を行うことを決定した前記通信装置によるトラフィック用に予約し、前記トラフィックの送信要求に対する応答であって、前記高優先度及び高ビットレートのトラフィックの送信が可能であることを示す情報を含む送信要求応答を送信するトラフィック送信要求応答送信部とを、
    有する通信サーバ。
12. 前記トラフィックの送信を中止させることができる前記特定の通信装置を特定するために、前記複数の通信装置のそれぞれによって送信されているトラフィックの優先度を判断する優先度判断部を有する請求項１１に記載の通信サーバ。

Images