複数の通信装置が特定の通信サーバとネットワークを介して通信を行っているシステムであり、前記複数の通信装置のそれぞれに割り当てられている通信のビットレートの総和が、所定の上限値を超えることができないように設定されている前記システムにおける通信装置であって、高優先度及び高ビットレートのトラフィックの送信を行うかどうか決定する送信決定部と、前記高優先度及び高ビットレートのトラフィックの送信を行うことを決定した場合、前記高優先度及び高ビットレートのトラフィックの送信を行うためのサービス要求を前記ネットワークへ送信するサービス要求送信部と、前記サービス要求に対する応答であって、前記高優先度及び高ビットレートのトラフィックを送信することができないベアラのベアラ識別子を含むサービス要求応答を受信するサービス要求応答受信部と、前記ベアラ識別子によって特定されるベアラを経由して、前記高優先度及び高ビットレートのトラフィックの送信要求を前記特定の通信サーバへ送信するトラフィック送信要求部と、前記トラフィックの送信要求に対する応答であって、前記高優先度及び高ビットレートのトラフィックの送信が可能かどうかを示す情報を含む送信要求応答を受信するトラフィック送信要求応答受信部と、前記送信要求応答から、前記高優先度及び高ビットレートのトラフィックの送信が可能であると判断された場合には、前記高優先度及び高ビットレートのトラフィックを前記特定の通信サーバへ送信するトラフィック送信部とを、有する通信装置。前記サービス要求応答に含まれる前記ベアラ識別子が、最小限の帯域幅を有するベアラを示すものであり、前記トラフィック送信要求部は、前記ベアラ識別子によって識別される前記最小限の帯域幅を有するベアラを経由して、前記トラフィックの送信要求を前記特定の通信サーバへ送信するよう構成されている請求項1に記載の通信装置。前記サービス要求応答に含まれる前記ベアラ識別子が、デフォルトベアラを示すものであり、前記トラフィック送信要求部は、前記ベアラ識別子によって識別される前記デフォルトベアラを経由して、前記トラフィックの送信要求を前記特定の通信サーバへ送信するよう構成されている請求項1に記載の通信装置。前記送信要求応答から、前記高優先度及び高ビットレートのトラフィックの送信が可能であると判断された場合には、前記ベアラ識別子によって特定されるベアラを経由して前記高優先度及び高ビットレートのトラフィックを前記特定の通信サーバへ送信することが可能となるように、前記ベアラ識別子によって特定されるベアラの帯域幅を変更する処理を行うベアラ変更部を有し、前記トラフィック送信部が、前記ベアラ変更部によって帯域幅が変更された前記ベアラ識別子によって特定されるベアラを経由して前記高優先度及び高ビットレートのトラフィックを前記特定の通信サーバへ送信するよう構成されている請求項1に記載の通信装置。前記トラフィック送信要求部が、前記高優先度及び高ビットレートのトラフィックの送信要求を、ユーザプレーン又は制御プレーンのどちらかのメッセージを利用して前記特定の通信サーバへ送信するよう構成されている請求項1に記載の通信装置。複数の通信装置が特定の通信サーバとネットワークを介して通信を行っているシステムであり、前記複数の通信装置が前記特定の通信サーバと行っている前記通信のそれぞれのビットレートの総和が、所定の上限値を超えることができないように設定されている前記システムにおける前記ネットワークを構成するネットワークノードであって、前記高優先度及び高ビットレートのトラフィックの送信を行うことを決定した前記通信装置から、前記高優先度及び高ビットレートのトラフィックの送信を行うためのサービス要求を受信するサービス要求受信部と、前記サービス要求に対する応答として、前記高優先度及び高ビットレートのトラフィックを送信することができないベアラのベアラ識別子を含むサービス要求応答を送信するサービス要求応答送信部とを、有するネットワークノード。前記高優先度及び高ビットレートのトラフィックの送信を仮に許可した場合に前記システム内のビットレートの総和が前記所定の上限値を超えてしまわないかどうかをチェックする上限値超過チェック部と、前記上限値超過チェック部で前記総和が前記所定の上限値を超えないと判断された場合には、前記高優先度及び高ビットレートのトラフィックを送信することができるベアラのベアラ識別子を含むサービス要求応答を送信する送信するサービス要求許可応答送信部とを、有し、前記上限値超過チェック部で前記総和が前記所定の上限値を超えてしまうと判断された場合にのみ、前記サービス要求応答送信部が、前記サービス要求に対する応答として、前記高優先度及び高ビットレートのトラフィックを送信することができないベアラのベアラ識別子を含むサービス要求応答を送信するよう構成されている請求項6に記載のネットワークノード。前記上限値超過チェック部で前記総和が前記所定の上限値を超えてしまうと判断された場合に、前記通信装置が前記高優先度及び高ビットレートのトラフィックの送信要求を前記特定の通信サーバへ送信するためのベアラを設定するための処理を、前記ネットワークを構成する他のネットワークノードとの間で実行するベアラ設定処理部を有し、前記サービス要求応答送信部が、前記サービス要求に対する応答として、前記ベアラ設定処理部で設定を行ったベアラのベアラ識別子を含むサービス要求応答を送信するよう構成されている請求項7に記載のネットワークノード。前記サービス要求応答に含まれる前記ベアラ識別子が、最小限の帯域幅を有するベアラを示すものである請求項6に記載のネットワークノード。前記サービス要求応答に含まれる前記ベアラ識別子が、デフォルトベアラを示すものである請求項6に記載のネットワークノード。複数の通信装置が特定の通信サーバとネットワークを介して通信を行っているシステムであり、前記複数の通信装置のそれぞれに割り当てられている通信のビットレートの総和が、所定の上限値を超えることができないように設定されている前記システムにおける通信サーバであって、高優先度及び高ビットレートのトラフィックの送信を行うことを決定した前記通信装置から、所定のベアラを経由して前記高優先度及び高ビットレートのトラフィックの送信要求を受信するトラフィック送信要求受信部と、前記高優先度及び高ビットレートのトラフィックの送信を行うことを決定した前記通信装置以外の通信装置のうち、トラフィックの送信を中止させることができる特定の通信装置に対して、トラフィックの中止指示を送信するトラフィック中止指示部と、前記トラフィック中止指示部によってトラフィックの送信が中止された特定の通信装置に割り当てられていた帯域幅を、前記高優先度及び高ビットレートのトラフィックの送信を行うことを決定した前記通信装置によるトラフィック用に予約し、前記トラフィックの送信要求に対する応答であって、前記高優先度及び高ビットレートのトラフィックの送信が可能であることを示す情報を含む送信要求応答を送信するトラフィック送信要求応答送信部とを、有する通信サーバ。前記トラフィックの送信を中止させることができる前記特定の通信装置を特定するために、前記複数の通信装置のそれぞれによって送信されているトラフィックの優先度を判断する優先度判断部を有する請求項11に記載の通信サーバ。<発明の基本原理>本発明は、モバイルデバイスのグループ例えば、MTCデバイスのグループが、単一又は複数のサーバ例えば、MTCサーバとの間でグループ通信を行っており、そのグループの所定デバイスの高優先度、広帯域幅、リアルタイムのUプレーントラフィックに利用可能なグループビットレート又はグループ帯域幅を有していない場合に適用される。本発明の基本原理は、このような高優先度のUプレーントラフィックを有するデバイスが、ネットワークへのシグナリング処理を利用してそのトラフィック状態を通知し、利用可能なグループ帯域幅がネットワークに存在しない場合には最小限の帯域幅のベアラを取得することである。このような最小限の帯域幅のベアラを取得した後、このデバイスは、危機的状態であることすなわち、高優先度のUプレーントラフィックを送信できないことをサーバへ通知し、その結果、サーバは、高優先度のUプレーントラフィックを有するデバイスが利用可能なグループ帯域幅を取得するために、重要なUプレーントラフィックを送信していないグループ内の他のデバイスの伝送を中止する。すなわち、本発明の主要な原理に関連するステップ又は処理は以下の通りである。あるグループのデバイスは、アプリケーションレイヤのトラフィックに関連した自身の優先状態を判断し、ネットワークへの高優先度Uプレーントラフィックの伝送を通知する。さらに、ネットワーク3GPPネットワークから与えられた最小限の帯域幅のベアラを利用し、Uプレーントラフィック状態及び利用可能なグループ帯域幅がない状態をサーバへ通知する。低優先度Uプレーントラフィックを有するデバイスの伝送を中止して、高優先度Uプレーントラフィックを有しており帯域幅を要求しているデバイス用に帯域幅を確保するために、サーバは、アプリケーションレイヤのインテリジェンスを利用して、グループ内の他のデバイスのUプレーントラフィック状態を特定し、低優先度のUプレーントラフィックに使用されている帯域を解放する。最後に、重大な遅延無く高優先度Uプレーントラフィックを転送できるようにするため、高優先度Uプレーントラフィックに必要なグループ帯域幅が利用可能な状態となったことが、高優先Uプレーントラフィックを有するデバイスに通知される。<本発明の動作シナリオ>以下、本発明の好適な実施の形態に係る本発明の動作シナリオについて詳細に説明する。ここでは、図2Aを参照しながら、特に3GPP構成に関連した動作シナリオについて説明する。なお、当業者であれば、本発明は3GPP固有のシナリオに限定されるものではなく、他の動作シナリオに対しても同様に適用可能であることは明白である。例えば、デバイスは、広帯域アクセスメディアや、その他のタイプのアクセスメディア又はネットワークアーキテクチャを通じて、サーバとの間でグループ通信を行うことが可能である。さらに、本発明は、グループ内のデバイスの1つが、グループベースの通信モデルにおけるサーバとして機能する場合にも適用可能である。また、図2Aに示されているシナリオは、MTCサーバと通信を行っているMTCデバイスに関するものであるが、本発明が適用されるデバイスのタイプに関する制約はなく、例えばデバイスは、サービスを受けるためにネットワークに接続する機能を有する通常のモバイル端末であってもよい。図2Aにおいて、MTCデバイス200a、201a、202a、203aが、MTCサーバ214aなどのサーバとの間でグループベースの通信を利用しているとする。さらに、MTCデバイス200a、201a、202a、203aが、関連するエンドポイントへのユーザプレーン及び制御プレーンのトラフィック伝送に、3GPPコアネットワーク212aを利用しているとする。また、図2Aに示されているMTCデバイス200a、201a、202a、203aのユーザプレーントラフィックは、eNBからサービングゲートウェイS-GWへのトンネリング機構、及び、S-GWからP-GWへの別の独立したトンネリング機構によって、MTCサーバ214aに到達しているとする。図2Aに図示されている3GPPコアネットワーク212aは、非特許文献2に記載されている3GPP拡張パケットコアevolvedpacketcoreEPCであってもよい。また、コアネットワーク212aは、GeneralPacketRadioServiceGPRSコアネットワークやUniversalMobileTelecommunicationSystemUMTSコアネットワークであってもよく、同様に本発明が適用可能である。なお、図2Aは、アクセスシステムとしてLTEを用いた場合の構成を示しているが、UMTSを用いた場合は、eNBはRNC/BSC、MMEはSGSN、PGWはGGSNに置き換えられる。図2Aに示されているMTCデバイス200a、201a、202a、203aは単一の加入者によって配置されており、相互にオーバラップしない独立した領域あるいは、オーバラップしている領域が一部のみであるに配置されているとする。独立した領域にMTCデバイスを配置することは、MTCデバイスがそれぞれ独立したeNBサービスエリア又はセルに配置されていることを表している。このような配置は、最も現実的な配置である。これは、すべてのMTCデバイスが同一の領域に配置されるのではなく、ほとんどの場合において、MTCデバイスがそれぞれ異なる領域から情報を送信するために使用されるからである。しかしながら、領域内に検出すべき多数のマシンタイプのデータが存在しているような稀な場合には、MTCデバイス間の負荷バランスを目的として、所定の位置に複数のMTCデバイスを配置することも可能である。通常、MTCデバイスは送信すべきデータがあまり多くないことを考えると、データの収集、処理、MTCサーバへの伝送のために、MTCデバイスが独立したオーバラップしない領域内に配置されることが非常に現実的な配置である。MTCデバイスがオーバラップしない配置モデルに基づき、さらに、図2Aに示されているように、MTCデバイス200a、201a、202a、203aが、eNB204a、205a、206a、207aにそれぞれ接続されているとする。さらに、MTCデバイス200a、201aがNASメッセージトラッキングエリアアップデート、サービス要求をMME208aへ送信しようとするとき、eNB204a及びeNB205aが、MTCデバイス200a及びMTCデバイス201aのそれぞれのために、MME208aとの間にS1制御プレーンコネクションS1-MME、S1-APのセットアップを行う。同様に、MTCデバイス200a、201aがアイドルモードから接続モードへ変更してサービス要求メカニズムを実行するとき、S-GW209aは、MME208aから指示を受けると、MTCデバイス200a、201aのそれぞれのために、eNB204a及びeNB205aとの間にS1ユーザプレーンコネクションS1-u、GPRSトンネリングプロトコルGTPベアラのセットアップを行う。なお、サービス要求及び一般的なNASシグナリングに関連する動作メカニズムの詳細は、非特許文献2に記載されている。同様の方法で、MTCデバイス202a、203aにおいても、MME211a及びS-GW210aに向かう適切なベアラがセットアップされる。また、MTCデバイス200a、201aのために、S-GW209aからP-GW213aへのGTPベアラ又はPMIPトンネルがセットアップされ、同様に、MTCデバイス202a、203aのためにS-GW210aからP-GW213aへのGTPベアラ又はPMIPトンネルがセットアップされる。図2Aに示されるように、3GPPネットワーク内でMTCデバイスがオーバラップしない配置とすることで、あるグループのMTCデバイスが異なるeNB、MME、S-GWに接続管理されているかもしれない。しかしながら、すべてのMTCデバイスが単一のMTCサーバ214aと通信を行っているので、HSSに格納されている静的なコンフィギュレーションによって、同一のP-GW213aを割り当てることが可能となる。また、P-GW213aは、G-AMBR上限に対する通信状況を確認するエンティティG-AMBRの実施ポイント、AvGrBWを計算するポイント、AvGrBW情報を通知するエンティティ又は配付するエンティティであるとする。図2Aで説明される動作シナリオは、グループ内のすべてのMTCデバイスが異なるeNBに接続しており、その結果、異なるMME及びS-GWに接続管理されるかもしれない場合である。しかしながら、本発明は、MTCサーバと通信を行うグループベースの通信モデルのすべてのMTCデバイスが、同一のeNB、同一のMME、又は、同一のS-GWに接続可能であるというシナリオに対しても同様に適用可能である。このようなシナリオでは、G-AMBRの実施ポイントがP-GWではなくS-GWであってもよい。しかしながら、もしS-GWがG-AMBRの保持を行うとすれば、MTCデバイスへAvGrBWを通知できるようにするベアラ変更bearermodification処理をトリガするための新たな処理が、S-GWに導入される必要がある。<本発明の適用が可能なシナリオ例>本発明の好適な実施の形態に従って、本発明の適切なシナリオ例について説明する。本発明は、このようなグループベースの帯域幅制限を課されているデバイスが、高優先度、広帯域幅、リアルタイムUプレーンのトラフィックをサーバへ伝送する必要がある実用的な現実のシナリオに適用可能である。特に、本発明は、あるグループに属するデバイスがグループ帯域幅が制約された状態において、サーバへ送信すべき高優先度Uプレーントラフィックを有している一方、グループ内の他のデバイスのいくつかが高優先度Uプレーントラフィックをサーバへ送信していない場合に適用可能である。なお、この本発明の実施の形態は、M2Mグループベースの通信シナリオに関係するものであるが、本発明の範囲を逸脱することなく、他の多くの非M2Mシナリオに対しても本発明は適用可能である。本発明が適用可能なM2Mグループベースの通信シナリオの一例としては、例えば、MTC加入者が、監視カメラを用いて家や事務所における盗難や破壊行為の画像を取得するための複数のMTCデバイスを配備する例が挙げられる。このような配備シナリオでは、盗難防止及び盗難検出のために、監視カメラが、共通のMTCサーバに対してモニタリングしたイベントをアップデートすると考えられる。MTC機能を有する監視カメラは電力に制限があり、バッテリ駆動式かもしれない。また、グループ内のすべての監視カメラは、同じタイプのUプレーントラフィックをMTCサーバへ同時に送信しているわけではないとする。例えば、監視カメラは、侵入者を検出すると、侵入者の顔、挙動や動作を高解像度でキャプチャした高優先度Uプレーントラフィックをサーバへ送信しようとするため、広帯域幅が必要となる。所定の監視カメラが高優先度UプレーントラフィックをMTCサーバへ送ろうとしている一方、グループ内の別の監視カメラは、家庭や事務所の通常の活動をキャプチャした通常のトラフィックをMTCサーバへ送信しているかもしれない。このように、高優先度Uプレーントラフィックを送ろうとしているが現在十分な帯域幅を有していない監視カメラのための最小限の帯域幅ベアラを取得するために、本発明が適用可能である。監視カメラは、利用可能なグループ帯域幅が不足している状態をMTCサーバへ通知するために最小限の帯域幅ベアラを取得すると、最小限の帯域幅ベアラを経由して警告メッセージを伝送することによって、この状態をMTCサーバへ通知する。MTCサーバは、監視カメラから帯域幅が不足しているという情報を受信すると、他の低優先度のカメラのセッションを解消し、さらに、高優先度の監視カメラに対して帯域を割り当てた後、サービスを開始するよう通知する。本発明が適用可能なM2Mグループベース通信の別のシナリオとしては、例えば、エンターテインメントとして、カメラ機能を有するMTCデバイスがリアルタイムのイベントをキャプチャしてMTCサーバへ報告するよう配置されている例が挙げられる。例えば、これらのMTCデバイスは、人間が介在することなく動作してリアルタイムでイベントをキャプチャし、マルチメディアトラフィックを使用してテレビ放送局に配置されているMTCサーバへイベントを送信する。さらに、本発明が適用可能なM2Mグループベースの別の通信シナリオとしては、例えば、あるグループのMTCデバイスが、人間の健康状態に関するトラフィックをMTCサーバへアップデートしている場合が挙げられる。MTCデバイスからのトラフィックのストリームには、例えば、人間の鼓動、体温、血糖レベルが含まれ得る。このような場合、あるグループに属する健康監視のためのMTCデバイスに対してグループ帯域幅の上限が課されているならば、本発明の主要な方法を利用して、健康監視のためのMTCデバイスからの高優先度Uプレーントラフィックに対してアクセス許可を与えることが望ましい。本発明の方法を適用することによって、著しく遅延させることなく、健康監視デバイスからの高優先度Uプレーントラフィックを伝送できるようにすることを目的とする。<G-AMBR実施ポイントによるベアラの処理>MTCデバイスがMTCサーバとの間でグループベース通信を行っており、各MTCデバイスに単一又は複数のベアラが割り当てられている場合において、コアネットワークにG-AMBRが実施及び実装されているときのベアラ管理実行方法について、本発明の好適な実施の形態に従って説明する。通常のUEのための一般的なベアラ管理は、例えば、非特許文献2に開示されている。しかしながら、本明細書では、G-AMBRの上限が設定されている場合のベアラ管理処理について説明する。なお、M2M通信シナリオにおけるG-AMBRが存在する場合のベアラ管理について説明するが、当業者であれば、あるデバイスのために単一又は複数のベアラが生成され、かつ、G-AMBRがシステムに設定及び実装されているような任意のグループベースの通信シナリオにおいて、本発明が適用可能であることが分かるであろう。例えば、グループの所定のMTCデバイスに対して、デフォルトベアラのみが確立されているのであれば、利用可能なグループ帯域幅すなわち、アップリンクAvGrBWが0であると通知されると、このMTCデバイスは、Uプレーンアップリンクトラフィックを送信することができないとする。デフォルトベアラは非GBRベアラなので、通知される利用可能なグループ帯域幅が0より大きい場合には、このMTCデバイスは、Uプレーンアップリンクトラフィックを送信することができるとする。さらに、AvGrBWの値が変更された場合には常に、ベアラQoSアップデートを行わないベアラ変更処理を使用することによって、利用可能なグループ帯域幅の状態がこのMTCデバイスに通知されるとする。なお、単一のデフォルトベアラに関して説明されている同一の処理は、MTCデバイスに関して複数のPDNコネクションが存在しており、MTCデバイスが複数のデフォルトベアラを持っている場合にも適用される。たとえ複数のデフォルトベアラが存在している場合であっても、AvGrBWは、ベアラQoSアップデートシグナリングではなく、単一のベアラ変更処理を利用して通知される。これは、AvGrBWが所定のデフォルトベアラに関連したパラメータではなく、MTCデバイスに関連したパラメータだからである。また、例えば、グループ内の所定のMTCデバイスが専用ベアラ及びデフォルトベアラを有しており、すべての専用ベアラが非GBRベアラである場合には、このMTCデバイスは、所定のベアラ又はベアラIDとは無関係に、AvGrBWの通知を受けるかもしれない。すなわち、AvGrBWは、ベアラQoSアップデートを行わない単一のベアラ変更処理を使用して通知される。たとえ複数の非GBRベアラが存在していたとしても、MTCデバイスへAvGrBWの値を提供するために単一のベアラ変更シグナリングが使用される。これは、すべてのベアラが非GBRベアラであり、それに関連する帯域幅が存在せず、それ故、ネットワークは単にベアラ識別子に関連付けられていないAvGrBWを通知するだけだからである。このような場合、MTCデバイスは、AvGrBWが0より大きいときにはアップリンクUプレーントラフィックを送信し、AvGrBWが0のときにはアップリンクUプレーントラフィックを送信しない。グループ内のMTCデバイスは、AvGrBWが0より高いと通知された場合に、非GBR専用ベアラ又はデフォルトベアラのどちらかを使用してUプレーントラフィック送信を行うことが可能である。また、別のシナリオにおいて、例えば、グループ内の所定のMTCデバイスがデフォルトベアラ及びGBRベアラを有している場合、AvGrBWの通知は、P-GWが、各専用GBRベアラに関してベアラ変更シグナリングを独立して送信し、各GBRベアラのための変更された帯域幅を通知する。これは、帯域幅がGBRベアラに関係していることから、ネットワークがAvGrBWをGBRベアラ間で分割し、その結果、各ベアラに関するベアラ変更シグナリングを送信するからである。例えばAvGrBWがxの場合、P-GWは、利用可能な帯域幅のほとんどをGBRベアラへ対照的に又は非対称的に配分するため、GBRベアラのそれぞれに関して複数のベアラ変更処理を実行する。したがって、GBRベアラが存在するとき、GBRベアラ間におけるAvGrBWの個々の分配又は割り当てが必要となるので、ベアラ変更シグナリングが大きくなる。一方、複数の非GBRベアラの場合では、AvGrBWを通知する単一のベアラ変更シグナリングで十分である。さらに、GBRベアラに関連してベアラ変更シグナリングが送信されるとき、その処理は、ベアラQoSアップデートを行わないベアラ変更処理とは異なる。GBRベアラに関しては、ベアラ変更シグナリングがそのベアラのための帯域幅GBR値を伝送するので、非特許文献2に開示されているように、その処理は、QoSアップデートを有するベアラ変更処理となる。また、デフォルトベアラに関係するGBRは存在しないので、最低限の帯域幅のみがデフォルトベアラに残される。新しいGBR値がMTCデバイスへ通知されると、MTCデバイスは、このGBR値がトラフィックの伝送に十分かどうかを判断して、関連するGBRベアラ又はデフォルトベアラを選択することが可能となる。所定のMTCデバイスに割り当てられるベアラがデフォルトベアラ、GBR専用ベアラ、非GBR専用ベアラなどの場合には、P-GWは利用可能なグループ帯域幅、すなわち、AvGrBWのほとんどをGBRベアラに割り当ててMTCデバイスへ通知し、AvGrBWのうちの最小限の帯域幅をデフォルトベアラ及び非GBRベアラへ割り当てる。P-GWは、GBRベアラのために複数のベアラQoS変更処理を実行し、各GBRベアラに対して割り当てた帯域幅をそれぞれ通知する。デフォルトベアラ及び非GBRベアラに関しては、P-GWは、ベアラQoSアップデートを行わない単一のベアラ変更処理を実行し、デフォルトベアラ及び非GBRベアラのための利用可能な帯域を一括して通知する。そして、MTCデバイスは、ベアラQoSアップデートを行わないベアラ変更処理で送信された利用可能な帯域幅値を使用して、1つ以上の非GBRベアラ経由でトラフィックを送信することができる。同様に、MTCデバイスは、アップリンクトラフィック送信のために関連するGBRベアラを選択する際に、受信した個々のGBRベアラに関するベアラQoSアップデートを使用する。また、MTCデバイスがUプレーントラフィック伝送の際に帯域幅が保証されているGBRベアラを持っていたとしても、Uプレーントラフィックに利用されていないGBRベアラの帯域幅は、AvGrBW計算処理における帯域幅として使用されないとする。例えば、利用可能なグループ帯域幅又はAvGrBWを計算する際、最初のステップにおいて、MTCデバイスのグループにおいて利用されている全体の帯域幅を特定する。この帯域幅は、MTCデバイスのUプレーントラフィックに関係する帯域幅である。そのグループで利用されている帯域幅を特定した後、利用可能なグループ帯域幅が特定可能となる。利用されている帯域幅を計算するとき、実際のUプレーントラフィックに関係する帯域幅のみが利用されている帯域幅として考慮され、利用されていないGBRベアラに関係する帯域幅は考慮されない。利用されていないGBRベアラは、現在Uプレーントラフィックを伝送していないGBRベアラである。しかしながら、別の通信モデルでは、GBRベアラは高優先度ベアラであると考えられ、これらのベアラは、たとえUプレーントラフィックが現在GBRベアラ経由で伝送されていない場合でも、そのグループで利用されている帯域幅を計算するために利用することが可能である。このような処理を利用することによって、GBRベアラに関係する帯域幅は、UプレーントラフィックがGBRベアラ経由で送信されているが否かによらず、GBRベアラが許可されているMTCデバイスにとって常に利用可能な状態となる。しかしながら、GBRベアラのために固定した帯域幅を常に予約しておくことは、効率的なリソース管理モデルではない。それにもかかわらず、あるシナリオでは、MTCデバイスは、利用可能なグループ帯域幅の計算処理で、利用可能であることが常に示されている帯域幅を有する特別な専用GBRベアラを確立するようネットワークへ要求することが可能である。このようなベアラを持つことによって、MTCデバイスは、高優先度トラフィックの伝送のためにこの特別な専用GBRベアラをすぐに利用することが可能であり、AvGrBWを考慮する必要はない。上述のQoSベアラ管理処理は、特に、3GPPEPSにおけるベアラ管理処理を説明しているが、当業者であれば、G-AMBRを実行する際に説明されているベアラ管理処理が、MTCデバイスのUプレーントラフィックがGPRSコア又はUMTSコア又はベアラ管理を利用するその他のシステムを伝送する場合においても適用可能であることが分かるであろう。<AvGrBWがMMEに格納されている際の動作>ベアラ変更シグナリングを送信して、Uプレーントラフィックの送信を現在予定していないグループ内のすべてのMTCデバイスに対して、ベアラ間におけるAvGrBW配分を通知することは、上述のように不要なシグナリングであり、ネットワークリソースの浪費である。さらに、MTCデバイスがアップリンクUプレーントラフィックを送信する予定がない場合、そのMTCデバイスをアイドルモードから立ち上げてベアラ全体のAvGrBW配分を通知することは、MTCデバイスの電力の浪費である。したがって、AvGrBW値に変更があった場合には常に、MTCデバイスの関連ベアラの帯域幅値をMMEへ通知し、MTCデバイスがUプレーントラフィックを送信したいと思うまでMMEがそれを格納することが、より良い実施例である。P-GWは、新しいAvGrBWに関連して変更されたMTCデバイスのベアラ帯域幅を、ベアラ変更処理を利用して通知し、MMEは、必要となるまではその値をMTCデバイスへ通知しない。以下、本発明の好適な実施の形態に従って、このようなベアラ管理処理について説明する。以下、図2Bを参照しながら、本発明の実施の形態において、このようなより良いベアラ管理処理について説明する。図2Bにおいて、MTCデバイス200b、201bは、MTCサーバ204bとの間でグループベースの通信を行っているMTCデバイスのグループに属しているMTCデバイスである。さらに、MTCデバイス200b、201bのために各eNBによって選定されたMMEが、MME202bであるとする。さらに、G-AMBR実施ポイント及びAvGrBW計算ポイントがP-GW203bであるとする。さらに、MTCデバイス200bはアイドルモードである一方、MTCデバイス201bは接続モードであり、MTCサーバ204bへUプレーントラフィックを送信しているとする。上述のように、ある配置構成において、AvGrBW、及び、MTCデバイス200bのベアラ間におけるAvGrBWの分配は、関連するベアラ変更処理を利用してMME202bへ通知される。しかしながら、MME202bは、MTCデバイス200bがアイドルモードであることを知っているので、これらのベアラコンテキストをMTCデバイス200bへ送信せずに、その代わり、MME202bの格納手段に格納する。このような動作シナリオでは、P-GW203bは、シグナリングメッセージ205bを用いて、AvGrBWに関係しているベアラであって、MTCデバイス200bに関連したベアラのベアラ変更メッセージを送信すると考えられる。このメッセージ205bの内容は、MME202bに格納され、MTCデバイス200bへは転送されない。シグナリングメッセージ205bの送信後、MTCデバイス200bは、アイドルモードから接続モードへ移行し、サービス要求メッセージ206bをMME202bへ送信したとする。MME202bは、MTCデバイス200bのために格納されているAvGrBWをチェックし、AvGrBWがMTCデバイス200bにとって十分なのものかどうかを確認することが可能である。MTCデバイス200bのAvGrBWは、ベアラ変更メッセージ205bに埋め込まれた帯域幅情報によってMME202bへ通知される。状態207bに示されているようにAvGrBWが0であれば、MME202bは、サービス要求応答メッセージ208bを送信し、適切な項目値clauseを用いてサービス要求を拒絶することが可能である。なお、項目値は、例えば、AvGrBWの不足による拒絶とすることが可能である。AvGrBWが0より大きい場合には、MME202bは、サービス応答処理208bにおいて、デフォルトベアラや専用GBRベアラに関係する帯域幅を単に通知し、Uプレーントラフィック伝送に関して帯域幅が十分かどうかをMTCデバイス200bに決定させればよい。このような場合、MME202bは、サービス応答NASメッセージ208bの新たな情報要素によって、ベアラに関連した帯域幅値を通知し、拒絶の項目値によるサービス要求の拒絶は行わない。また、MTCデバイス200bがUプレーントラフィック伝送に必要なビットレートをサービス要求206bにおいて送信した場合には、MME202bは、AvGrBWの値及びMTCデバイス200bのベアラにおけるAvGrBWの分配に基づいて、サービス受け入れメッセージ又はサービス拒絶メッセージを送信する。要求されたビットレートをサポートする単一のGBRベアラが存在する場合には、GBRベアラが許可されて、サービス要求応答メッセージ208bによってベアラ識別子が通知される。AvGrBWが0より大きいが、要求されたビットレートをサポートするには十分ではない場合には、メッセージ208bでサービス拒絶が送信される。また、MTCデバイス200bによって要求されたビットレートが、単一の既存GBRベアラではなく、複数のGBRベアラの結合によってサポート可能である場合、MME202bは、サービス要求206bを拒絶し、さらに新たなベアラ値を通知すること、ベアラ情報を待機すること、ページングを受信するまでサービス要求の再試行をしないことを通知する。こうしたページング情報の待機は、メッセージ208bによって送信可能である。MME202bは、MTCデバイス200bのためのベアラを確立するようP-GW203bへ要求してもよい。この新しいベアラを実現するため、既存のGBRベアラが破棄され、新たなGBRが作成される必要がある。ある古いGBRベアラが無効化され、MTCデバイス200bに必要なGBRベアラが作成されると、MME202bは、MTCデバイス200bにページングを送信することができる。MTCデバイス200bはページングを受信し、MME202bへのサービス要求を実行する。サービス応答において、アップリンクUプレーントラフィック送信を可能にする新しいGBRベアラの属性がMTCデバイス200bへ送信される。NASメッセージ208bがサービス拒絶メッセージである場合、MTCデバイス200bはランダムな時間だけ待機した後、接続モードに移行するためにサービス要求を再試行する。このような再試行のサービス要求は、図2Bのシグナリングメッセージ209bとして示されている。また、ここでも、グループ内のどのデバイスもアップリンクUプレーントラフィックの送信を中止せず、MME202bにおけるAvGrBWの状態に変更はないとする。この再試行サービス要求の間に状態変更がなかったことは、状態210bとして示されている。この場合、MME202bは、別のサービス要求拒絶メッセージ211bをMTCデバイス200bへ送信する。このシナリオにおいて、MTCデバイス201bがUプレーントラフィック送信を停止し、その結果、送信中止メッセージ212bをMME202bへ送信したとする。なお、このメッセージ212bはオプションのメッセージであり、必ずしも送信される必要はない。MTCデバイス201bは、ネットワークからのデタッチを実行する場合に、デタッチNASメッセージ212bをMME202bへ送信することが可能である。このデタッチメッセージ212bは、デタッチ通知のためにさらにP-GW203bへ送信される。P-GW203bは、デタッチメッセージ213bを受信すると、AvGrBWを再計算する。新たなAvGrBWは、シグナリングメッセージ214bを使用してMME202bへ通知される。なお、シグナリングメッセージ214bによって通知されるAvGrBWは、MTCデバイス200bのアップリンクUプレーントラフィックを送信するのに十分であるとする。サービス要求を再試行するメッセージ215bを再度受信したMME202bは、空いているグループ帯域幅が利用可能な状態状態216bとなっているので、サービス要求受け入れメッセージ217bをMTCデバイス200bへ送信する。サービス要求が受け入れられたことメッセージ217bを考慮し、MTCデバイス200bは、MTCサーバ204へのUプレーントラフィックの送信に成功する。このUプレーントラフィックがメッセージ218bによって示されている。この方法の利点は、必ずしもベアラ情報を送信する必要がないという点、MTCデバイスがデータを送信しようとしており、サービス要求を送信する場合にのみ通知が行われるという点にある。これにより、コアネットワークの不要なシグナリング、ページングのシグナリングが送信されるという問題が解決され、また、MTCデバイスの電力が節約される。しかしながら、図2Bに図示されている方法は、送信すべき高優先度トラフィックを有するMTCデバイス200bが、依然として、必要な帯域幅を取得するためにある程度の時間だけ待機しなければならず、また、MTCデバイス200bが複数回のサービス要求シグナリングを実行して、接続モードに移行しなければならないという課題も有している。MTCデバイス200bがデタッチモードからアタッチモードへ変わる場合には、MTCデバイス200bは、通常のベアラ作成処理を利用して、ベアラ関連情報を受信する。アタッチモードでは、MTCデバイス200bがMME202bへ問い合わせを行って関連するベアラパラメータを取得するか、又は、MME202bがベアラ情報を格納せずに渡すことが可能である。なお、3GPP構成に関連して説明を行ったが、当業者であれば、同様の動作を行う他の構成に上述の方法を適用することが可能である。<本発明の主要な動作>次に、本発明の好適な実施の形態における動作について説明する。本発明の主要な基本原理は上述した通りであるが、ここでは、任意のネットワークアーキテクチャにおける動作について説明する。この任意のネットワークアーキテクチャは、主に3つの構成要素例えば、MTCデバイス、MTCサーバ、MTCデバイスがMTCサーバへ到達するためのネットワークコンポーネントから構成される一般的なアーキテクチャである。このネットワークコンポーネントは、MTCデバイスからのユーザプレーントラフィック及び制御プレーントラフィックの伝送を可能にするルータ及びゲートウェイによって構成されると考えることができる。また、このネットワークコンポーネントは、アクセスネットワーク、伝送ネットワーク、さらには一般的なインターネットをも構成すると考えることができる。さらに、このネットワークコンポーネントは、接続されている各MTCデバイスに関して、単一又は複数のベアラを作成、維持することが可能である。上述のように、MTCデバイスがUプレーン伝送のためにベアラを使用する場合、ベアラは、Uプレーントラフィックに提供されるQoSサポートのレベルという特徴を有している。なお、本発明の主要な動作は、特に、本発明の実施の形態におけるM2M通信に関連した通信環境において説明されるが、当業者であれば、本発明は、このMTCデバイスが任意のモバイルデバイスであって、このMTCサーバが任意のタイプのサーバであるような一般的な設定においても適用可能であることが分かるであろう。さらに本発明の動作を理解するため、図3Aに図示されているシグナリング交換について説明する。このようなシグナリング交換の詳細を説明する前に、まず、図3Aを参照しながら、本発明の高次の動作について説明する。図3Aにおいて、MTCデバイス300aが、ネットワーク301aを通じてMTCサーバ302aと通信しているとする。ネットワーク301aは、MTCデバイス300aとMTCサーバ302aとの間のパスにおける任意のネットワークエンティティである。図3Aに図示されている本発明に係る動作は、MTCデバイス300aが、高優先度、広帯域幅、リアルタイムUプレーントラフィックを送信する必要性をネットワーク301aこれは、ネットワークエンティティを意味しているへ送信し、AvGrBWが無い場合にはネットワーク301aは、たとえMTCデバイス300aが、接続されている複数のベアラを既に有していたとしても、最小限の帯域幅のベアラをMTCデバイス300aが使用することのみを許可する。MTCデバイスのグループのための利用可能な帯域幅が無い場合例えば、AvGrBW=0には、ネットワーク301aは、そのグループのMTCデバイス300aに対して、高いQoSを有するベアラの使用の許可を与えることを望まず、その結果、MTCデバイス300aに対して最小限の帯域幅ベアラの割り当てのみを行う。最小限の帯域幅ベアラは、そのベアラに最小限の帯域幅及び低QoSが関連付けられていることを意味する。最小限の帯域幅ベアラに低QoSを与えることは、Uプレーントラフィックがこのベアラを通じて送信される場合にネットワーク301aが優先的な取り扱いを行う必要がなく、その結果、最低限の帯域幅ベアラを経由して送信されるUプレーントラフィックが、他のデバイスのUプレーントラフィックフローに影響を与えないようにすることを意味する。なお、他のデバイスは、そのグループのデバイスではなくてもよい。また、最小限の帯域幅を最小限の帯域幅ベアラに割り当てることによって、ネットワーク301aは、そのグループに属さない他のデバイスからの重要なリソースが、最小限の帯域幅ベアラ経由で送信されるUプレーントラフィックに使用される必要がないようにすることを意味する。ネットワーク301aがこのような最小限の帯域幅のベアラを決定すると、ネットワーク301aは、この最小限の帯域幅のベアラのベアラ識別子を、MTCデバイス300aへ通知する。MTCデバイス300aは、ネットワーク301aによって返信されるベアラが最小限の帯域幅のベアラであると判断すると、静的構成に基づいてそれに関連付けられているQCIを把握し、Uプレーントラフィック送信に関連するベアラを使用する際に、内部でQoSパラメータすなわち、帯域幅、リンクバッファの特性の調整を行う。なお、各QCIスカラは、任意のQoSパラメータにマッピングされていると考えられる。MTCデバイス300aが、最小限の帯域幅ベアラのためのQCI値や、静的に格納された関連QoSパラメータを持っていないような場合には、ネットワーク301aは、最小限の帯域幅のベアラのベアラIDに加えて、最小限の帯域幅のベアラのためのQCIスカラ値や、このQCIスカラに対応するQoSパラメータを、MTCデバイス300aへ明示的に与えてもよい。MTCデバイス300aは、この最小限の帯域幅のベアラについて通知されると、そのベアラを、高優先度、広帯域、リアルタイムUプレーントラフィックを転送することが可能な何らかの帯域幅を得るための警告メッセージをMTCサーバ302aへ送信するために使用可能なベアラと正しく判断する。最小限の帯域幅のベアラの特性を判断した後、MTCデバイス300aは、この最小限の帯域幅のベアラを使用するためにQoSパラメータを内部で調整する。MTCデバイス300aは、Uプレーントラフィック送信レートを、最小限の帯域幅のベアラのQCIに関連する最小限の値に調整し、最小限の帯域幅のベアラに対応するQCIを内部のアップリンクバッファへ入力する。MTCデバイス300aは、ネットワーク301aにおいて帯域幅が不足している状態にあることをMTCサーバ302aへ通知するために、この最小限の帯域幅のベアラを使用する。このとき、AvGrBWが0以上であるが、MTCデバイス300aに必要なUプレーントラフィックレートがAvGrBWより大きい場合であっても、ネットワーク301aが、最小限の帯域幅のベアラをMTCデバイス300aへ割り当てることが重要である。MTCサーバ302aへ警告が送信されて使用されていた帯域が解放され、AvGrBWを上回る帯域が存在する状態になると、MTCサーバ302aは、帯域幅が解放された状態がMTCデバイス300aへ通知される。帯域幅が利用可能な状態がMTCデバイス300aによって認識されると、MTCデバイス300aは、最小限の帯域幅のベアラのためのQCIを復元するようネットワーク301aへ要求し、それを利用して高優先度、広帯域幅、リアルタイムUプレーントラフィックをMTCサーバ302aへ送信する。以下、本発明の詳細な動作について説明する。MTCデバイス300aが、サービス要求シグナリング303aを送信し、高優先度、広帯域幅、リアルタイムトラフィックを送信する予定であることを通知する。MTCデバイス300aが高優先度、広帯域幅、リアルタイムトラフィックを送ろうとしていることを示すトリガは任意の形式が可能であり、例えば、このような必要性を特徴付けるUプレーントラフィックのビットレート、帯域幅、又は、何らかの識別子であってもよい。ネットワークエンティティ301aは、そのグループに関するAvGrBWをチェックする。そのグループに関するAvGrBWが0の場合、ネットワークエンティティ301aは、最小限の帯域幅のベアラのみが使用可能であることをMTCデバイス300aへ通知する。このような最小限の帯域幅のベアラに関する情報は、応答メッセージ304aで提供される。MTCデバイス300aは、応答メッセージ304aを受信すると、最小限の帯域幅のベアラをセットアップするために必要な動作を実行する。なお、最小限の帯域幅のベアラのセットアップは、明示的なシグナリングの有無によらず実行可能である。なお、応答メッセージ304aは、最小限のデータしか送ることができない時間間隔バックオフタイマを示す値を含むサービス要求応答メッセージServiceAcceptであってもよい。MTCデバイス300aは、受信した応答メッセージ304aの中にバックオフタイマが含まれた場合には、受信したタイマが経過するまでは、高優先度や広帯域なトラフィックを送信することができないと判断する。つまり、バックオフタイマは、MTCデバイス300aが送信したサービス要求に対応するベアラの確立が一定時間バックオフタイマ経過後に行われることを示している。この場合、バックオフタイマを通知するネットワーク301a内のエンティティはMMEである。MTCデバイス300aは、このような最小限の帯域幅のベアラの存在及び構成を把握した後、最小限の帯域幅のベアラを使用して、メッセージ305aに示されているようにMTCサーバ302aへ警告メッセージを送信する。また、上述したように、ネットワーク301aから受信した応答メッセージ304aの中にバックオフタイマが含まれていた場合には、ネットワーク301aから受信したバックオフタイマが有効である間は、最小限の帯域幅のベアラを使用して、メッセージ305aに示されているようにMTCサーバ202aへ警告メッセージを送信する。この警告メッセージ305aは、ユーザプレーンメッセージであると考えられ、具体的には、何らかの帯域幅を要求するために送信されるものである。MTCサーバ302aは、ネットワーク301aと通信を行って、そのグループに関する帯域幅を取得するか、あるいは、何らかの手段を利用して、MTCデバイス300aのために帯域幅を解放する。なお、上記何らかの手段は、他のMTCデバイスがあまり重要なUプレーントラフィックをMTCサーバ302aへ送信していない場合に、その送信を停止するよう通知することであってもよい。MTCサーバ302aとネットワーク301aとの間のやり取りは図3Aには明示されていない。MTCサーバ302aは、MTCデバイス300aに必要な帯域幅が利用可能であることを確認した後、送信可CleartoSend:CTSアプリケーションレイヤメッセージ306aをMTCデバイス300aへ送信する。このアプリケーションレイヤメッセージ306aを受信すると、MTCデバイス300aは、ネットワークエンティティ301aに対してベアラ変更シグナリング307aを実行する。メッセージ307aの目的は、最小限の帯域幅のベアラに対してより高いQoS特性を回復するよう要求するものであり、その結果、MTCデバイス300aは、高優先度、広帯域幅、リアルタイムUプレーントラフィックをMTCサーバ302aへ送信することが可能となる。また、MTCデバイス300aに割り当てられるこの最小限の帯域幅のベアラ以外の別の所定のベアラが、MTCサーバ302aへのUプレーントラフィックを伝送するために十分であることをMTCデバイス300aが把握している場合には、MTCデバイス300aは、最小限の帯域幅のベアラではないこのようなベアラに関してベアラ変更を実行することが可能である。ネットワークエンティティ301aは、メッセージ307aによるベアラ変更要求を受け入れる前に、現在のAvGrBWが十分かどうかのチェックを行う。ネットワークエンティティ301aが、メッセージ307aに埋め込まれている要件を満たす十分な帯域幅が存在していることを把握すると、メッセージ308aに示されているように、アクノレッジメントを送信する。アクノレッジメントメッセージ308aでは、ネットワークエンティティ301aは、最小限の帯域幅のべアラの識別子を割り当てるか、あるいは、MTCデバイス300aの高優先度、広帯域、リアルタイムUプレーントラフィックを伝送することが可能な別の既存のベアラの識別子を割り当てる。メッセージ308aを受信した場合は、MTCデバイス300aは、メッセージ308aにベアラIDを付加したUプレーンメッセージをMTCサーバ302aへ送信する。MTCサーバ302aへのUプレーンデータメッセージは、メッセージ309aによって図示されている。本発明の動作に係る上述の説明から、AvGrBWが0、又は、MTCデバイス300aが高優先度UプレーントラフィックをMTCサーバ302aへ送信できない程度の低い値の場合に、本発明の方法を適用することで、従来技術に係る非効率性を伴わずに、必要な帯域幅が取得できることは明らかである。本発明の方法を利用して、MTCサーバ302aと通信を行うために、低減されたQoSを有する最小限の帯域幅のベアラがセットアップされ、その結果、MTCサーバ302aは、低優先度トラフィックを送信するその他のMTCデバイスを外して、AvGrBWの状態をより高い値に戻すことが可能となる。この最小限の帯域幅のベアラの特別な性質は、最小限の帯域幅のベアラが既存のベアラのQoSが変更されたものである場合には、変更されたQoSをMTCデバイス300a又はルータへ通知するためにネットワークにおいて明示的なベアラ変更シグナリングの付加が行われることなく、最小限の帯域幅のベアラがMTCデバイス300aへ割り当てられることである。最小限の帯域幅のベアラを使用してUプレーントラフィックをMTCサーバ302aへ送信する際には、最小限の帯域幅のベアラのIDが付加され、パス上のルータは、このIDが最小限の帯域幅のベアラに関連していることを把握し、Uプレーントラフィックに関して必要最小限のQoS処理を行う。なお、最小限の帯域幅のベアラのIDは固有であり、最小限の帯域幅ベアラのみに関連しているとする。その結果、Uプレーントラフィックのパス上のルータは、たとえ明示的なベアラ変更シグナリングをネットワークから受信しなかったとしても、最小限の帯域幅のベアラのIDを確認したときは、行うべきQoS処理を把握する。また、既存のベアラが最小減の帯域幅のベアラである場合に、そのベアラのIDが最小限の帯域幅のベアラのIDに変更される。このような最小限の帯域幅のベアラの判断では、最小限の帯域幅のベアラのIDが特定のQoSへマッピングされており、このようなマッピングがルータ及びMTCデバイス300aにも事前に格納されていると考えられる。<3GPPシナリオにおける本発明の詳細な動作-最小限の帯域幅のベアラが変更されたQCIを有するデフォルトベアラである場合>上述では、図3Aに示されるシグナリング交換を実行する動作を参照しながら、以下では、デフォルトベアラが使用される場合について説明する。以下、最小限の帯域幅ベアラとしてデフォルトベアラが使用される場合について説明する。MTCデバイスとMTCサーバとの間のネットワークが、非特許文献2に開示されているネットワークアーキテクチャを有し得る3GPPネットワークセグメントの場合における本発明の詳細な動作について説明する。最小限の帯域幅のベアラとして使用されるデフォルトベアラに関して、2つの場合が存在する。第1の場合は、MTCデバイスがデフォルトベアラのみを有しており、QoSが低減されたデフォルトベアラが最小限の帯域幅のベアラとみなされる場合である。第2の場合は、MTCデバイスがデフォルトベアラ及び専用ベアラを有しており、デフォルトベアラのQoSを低減させずに、デフォルトベアラのみが最小限の帯域幅のベアラとして割り当てられる場合である。第2の場合において、デフォルトベアラが最小限の帯域幅のベアラとして使用されるとき、デフォルトベアラに関連するQoSが低く、かつ、デフォルトベアラのためのQoSパラメータを低減させる必要がないと仮定する。したがって、第2の場合には、第1の場合のようにQCI値を変更させる必要はない。さらに、図3Bを参照しながら、3GPPの設定において、デフォルトベアラが最小限の帯域幅ベアラとして使用される場合の詳細な動作について説明する。ここでは、まず、MTCデバイスに関連して単一のデフォルトベアラのみが存在する場合について説明し、続いて、MTCデバイスに割り当てられている専用ベアラが存在する場合について説明する。図3Bでは、MTCデバイス300b、301bは、通常、MTCサーバ304bと通信を行うものであり、G-AMBRが課されているとする。また、MTCデバイス300b、301bには、例えば、P-GWなどのネットワークエンティティ303bからIPアドレスが割り当てられるとする。以降、ネットワークエンティティ303bはP-GWであるとする。また、MTCデバイス300b、301bはMME302bに接続されているとする。このような3GPP指向の設定では、MTCデバイス301bは、MTCサーバ304bとUプレーン通信セッションを有しているとする。さらに、MTCデバイス300bは、MTCサーバ304bへ送信すべき高優先度、広帯域幅、リアルタイムUプレーントラフィックを有しており、MTCデバイス300bは現在アイドルモードであるとする。さらに、MTCデバイス300bは、デフォルトベアラのみがセットアップされており、このようなデフォルトベアラの状態は、例えばMME302b、P-GW303b、さらにはMTCデバイス300bなどのネットワークエンティティに保持されているとする。なお、デフォルトベアラの状態は、ベアラID、APN、QCI、IPプレフィックス値などを指すものである。MTCデバイス300bが、そのフローに関してあまり高いQoS処理を必要としておらず、デフォルトベアラのみを使用してMTCサーバ304bと通信を行うことができる場合には、MTCデバイス300bがデフォルトベアラしか持っていないというシナリオが十分に考えられる。この高優先度UプレーントラフィックをMTCサーバ304bへ送信するために、MTCデバイス300bは、メッセージ305bに示されるようにサービス要求メッセージを送信する。MTCデバイス300bは、高優先度、広帯域幅、リアルタイムのUプレーントラフィックを送信する必要があることを示すためのフラグを、このサービス要求メッセージ305bに埋め込むことができる。なお、このフラグは、サービス要求メッセージ305bに付加される新たな情報要素であってもよい。また、MTCデバイス300bは、このメッセージ305bに、明示的なビットレート及び帯域幅のプロファイルを埋め込むことも可能である。また、別の派生例として、MTCデバイス300bが、メッセージ305bのフラグを送信し、そのフラグを確認したMME302bが、MTCデバイス300bに関するトラフィックのプロファイルを、格納されたキャッシュやデータベースから取得することが可能である。なお、この例では、MTCデバイス300bのトラフィックのプロファイルがMME302bにおいて静的に構成されている。メッセージ305bの受信後、状態306bに示すようにAvGrBWが0であることをMME302bが把握した場合、MME302bは、メッセージ307bに示すようにサービス要求応答メッセージをMTCデバイス300bへ送信することが可能である。この応答メッセージ307bは、最小限の帯域幅のベアラのベアラIDをMTCデバイス300bへ通知することが望ましい。上述の実施の形態のように、MTCデバイスがアイドルモードの場合には、ベアラ変更メッセージはMTCデバイスへ送信されず、MME302bでベアラ情報を維持することが可能である。このような最適化された動作によれば、MME302bは、MTCデバイス300bのベアラに関するすべての情報を有しており、直ちに適切なメッセージ307bで応答することが可能である。このベアラ情報には、AvGrBWの情報が含まれていてもよい。MTCデバイス300bはメッセージ307bを受信し、最小限の帯域幅のベアラのベアラIDを確認すると、このベアラIDが一時的にデフォルトベアラに割り当てられていることを把握し、さらに、ネットワークがMTCデバイス300bへ最小限の帯域幅のベアラを割り当てるつもりであることを理解する。なお、別の実施例では、応答メッセージ307bに新たな情報要素CauseValueを割り当てることが可能であり、MTCデバイス300bは、それを最小限の帯域幅のベアラの許可と解釈することも可能である。メッセージ307bに新たな情報要素が存在する場合には、MTCデバイス300bは、MTCデバイス300bに格納されている、事前に構成された最小限の帯域幅のベアラのIDを特定することが可能である。MTCデバイス300bは、事前構成によって、最小限の帯域幅ベアラに関連するベアラIDを既に把握しており、応答メッセージ307b内の情報をすぐに特定できると考えられる。なお、事前構成がない場合であっても、MTCデバイス300bは、新たなベアラIDが応答メッセージ307bに存在する場合に、それを最小限の帯域幅のベアラのベアラIDと判断してもよい。また、応答メッセージ307bにバックオフタイマが含まれている場合は、そのタイマが有効である間は、最小限の帯域幅のベアラだけが許可されていると解釈する。つまり、そのタイマの有効期限が切れた場合は、通常通りのベアラを生成することが可能であると判断し、高優先度広帯域向けのサービス要求を送信する。最小限の帯域幅のベアラを使用してUプレーントラフィックを送るとき、MTCデバイス300bは、上述のように、最小限の帯域幅のベアラが割り当てられていることを把握し、続いて、内部でQoSを変更する。最小限の帯域幅のベアラはデフォルトベアラであり、MTCデバイス300bは新しいQCIをデフォルトベアラに関連付ける。このような内部での関連付けは、処理308bによって示されている。最小限の帯域幅のベアラの変更及び構成が内部で行われた後、MTCデバイス300bは、最小限の帯域幅ベアラIDをユーザプレーンパケットに関連付けることによって、Uプレーン警告メッセージ309bをMTCサーバ304bへ送信する。なお、当業者であれば、デフォルトベアラのIDが静的な最小限の帯域幅のベアラのIDへ変更され、その結果、すべてのルータがメッセージ309bに対して最小限のQoS処理を実行することが分かるであろう。さらに、MTCデバイス300bは、MTCサーバ304bへその状態を通知するため、非常に低い帯域幅のUプレーントラフィックをMTCサーバ304bへ送信する。MTCサーバ304bは、メッセージ309bを受信すると、MTCデバイス300bに必要な帯域幅を取得する方法を決定する。ある方法においては、メッセージ309bに、MTCデバイス300bが送信しようとしている高優先度Uプレーントラフィックのビットレート情報が含まれていてもよい。このようなビットレート情報を把握することによって、MTCサーバ304bは、MTCデバイス300bを収容するために解放すべき帯域幅の量を容易に把握することが可能である。MTCサーバ304bがビットレート監視特性を有する場合には、MTCサーバ304bは、MTCデバイス300bのための帯域幅を取得するために送信を停止する必要があるグループ内の他のすべてのデバイスを特定することが可能である。MTCサーバ304bは、他のMTCデバイスのフローがさほど重要ではないことを予測できるのであれば、他のMTCデバイスの送信をストップさせるだけでよいと考えられる。MTCサーバ304bがこのようなビットレート監視特性を持っていない場合は、シャットダウンが必要なMTCデバイスを特定する際の援助をしてもらうようP-GW303bと通信を行うことが可能である。しかしながら、MTCサーバ304bが、アプリケーションレイヤを有しており、高優先度トラフィックを送信していないグループ内のMTCデバイスを特定する機能を有しているので、送信の中止が可能なMTCデバイスは、MTCサーバ304bによってのみ特定される。MTCサーバ304bは、MTCデバイス301bのUプレーントラフィックが停止可能であることを特定した場合、メッセージ310bを使用して送信停止メッセージをMTCデバイス301bへ送信する。MTCデバイス300bに帯域幅を確実に提供できるようにし、別のMTCデバイスによって使われないようにするため、MTCサーバ304bは、P-GW303bに対して、MTCデバイス300bにおいて必要な帯域幅を明示的に予約するよう要求してもよい。この動作によれば、予約によって、MTCデバイス300bに関するAvGrBWの値は高くなり、他のデバイスに関するAvGrBW値は低くなる。MTCサーバ304bは、MTCデバイス300bのために十分な帯域幅が利用可能であると把握すると、CTSメッセージをMTCデバイス300bへ送信する。このCTSメッセージは、メッセージ311bによって示される。メッセージ311bがMTCデバイス300bによって受信されると、MTCデバイス300bは、デフォルトベアラに対してベアラ変更を実行するよう決定する。ベアラ変更は、デフォルトベアラのQoS特性をより高い値に回復するために行われる。その結果、MTCデバイス300bは、高優先度、広帯域幅、リアルタイムUプレーントラフィックを送信することができる。MME302bは、デフォルトベアラ変更要求メッセージ312bを受信し、それが関係する帯域幅より大きいAvGrBWであるという情報を有している場合状態313bには、ベアラ変更処理を実行してデフォルトベアラのためのQCIを回復させる。デフォルトベアラID最小限の帯域幅のベアラのIDとは異なるは、ベアラ変更要求応答メッセージ314bによって、MTCデバイス300bへ返される。メッセージ314bによってデフォルトベアラのIDを受けると、MTCデバイス300bは、MTCサーバ304bへのアップリンクトラフィック315bの送信を開始する。なお、派生例として、ベアラ変更要求メッセージ312bにおいて、MTCデバイス300bは新たな専用ベアラを要求して、高優先度トラフィックを伝送することが可能である。さらに別の派生例として、ネットワークは、デフォルトベアラを変更する代わりに、専用ベアラを生成することが可能である。新たに生成された専用ベアラのIDはメッセージ314bによって通知可能である。次に、既存のデフォルトベアラが最小限の帯域幅のベアラとして、応答メッセージ307bによってMTCデバイス300bへ単純に通知される第2の場合について説明する。既存のデフォルトベアラが最小限の帯域幅のベアラとして返されると、MTCデバイス300bは、複数のベアラをそれに関連付けてもよい。この第2の場合では、応答メッセージ307bは単にデフォルトベアラのIDを伝送する。MTCデバイス300bは、既存のデフォルトベアラのIDがメッセージ307bによって返されると、デフォルトベアラのみがMTCサーバ304bへ警告メッセージ309bを送信するために使用可能であり、変更を行わないデフォルトベアラが最小限の帯域幅のベアラであると判断することが可能である。また、MTCデバイス300bは、応答メッセージ307bを確認すると、警告メッセージ309bが最小限の帯域幅で送信される必要があるという判断も行う。この実施例では、デフォルトベアラのQoSは非常に低く、MTCデバイス300bによるQoSの更なる内部変更が不要であると考えられる。したがって、ステップ308bは実行される必要はない。また、この第2の場合においても、応答メッセージ307bにバックオフタイマが含まれている場合は、そのタイマが有効である間は、デフォルトベアラが最小限の帯域幅のベアラであると判断してもよい。そして、このバックオフタイマが有効である間は、警告メッセージ309bがデフォルトベアラ上で送信される必要があるという判断も行う。デフォルトベアラが最小限の帯域幅のベアラとして単に使用され、複数のベアラがMTCデバイス300bに関連付けられる実施例では、MTCデバイス300bは、ベアラ変更要求312bにおいて、デフォルトベアラに関連するQoSよりも高いQoSを持つようデフォルトベアラを変更する要求を行うことが可能であるか、あるいは、既存の専用ベアラに対してベアラ変更を要求することが可能である。なお、MTCデバイス300bは、メッセージ312bの代わりに、単純に新たな専用ベアラを要求することも可能である。MME302bは、要求312bを処理する方法を判断する。MME302bが要求312bを処理することができる方法は複数存在し、どの方法で判断を行ったとしても、本発明の主要なポイントに影響を与えるものではない。<本発明の別の動作-最小限の帯域幅のベアラが明示的に生成される>AvGrBWが存在しない場合に、最小限の帯域幅のベアラが明示的に生成されることが望ましい構成も存在する。以下、このような実施例について説明する。デフォルトベアラのQoS特性が非常に低いQoS値への変更を禁止されている場合には、図3Cに図示されているように、最小限の帯域幅の専用ベアラを生成し、その最小限の帯域幅の専用ベアラのQoS特性を改善することが適切である。このように、最小限の帯域幅の専用ベアラを生成することが有用な場合がある。さらに、デフォルトベアラと共に、最小限の帯域幅の専用ベアラを使用する場合もある。この場合、最小限の帯域幅の専用ベアラが最小限のQoSを必要とするトラフィックのために使用される場合もある。以下、図3Cを参照しながら、この本発明の別の実施例の主要なステップについて説明する。本発明の主要な動作環境において、MMEが、MTCデバイスの1つ又は複数のベアラに関係するAvGrBWに関連したベアラコンテキストを維持し、MTCデバイスがサービス要求処理を実行するまで、ベアラコンテキストをMTCデバイスへ提供しないようにすることが可能である。このベアラコンテキストは、P-GW始動のベアラ変更処理を利用して、P-GWから提供されると考えられる。以下、このような動作について詳述する。MTCデバイス300c、301cは、通常MTCサーバと通信を行い、グループベースの通信シナリオであるとする。また、MTCサーバ304cと通信を行っているMTCデバイスは、G-AMBRが課せられているとする。また、MTCデバイス301cが現在アップリンクトラフィックをMTCサーバ304cへ送信している一方、MTCデバイス300cはアイドルモードであるとする。なお、MTCデバイス300cは、関連する複数のベアラを有していてもよい。さらに、ある経過時間後に、MTCデバイス300cは、MTCサーバ304cへ送信すべきUプレーントラフィックを有するものとする。さらに、MTCデバイス300cが送信しようとしているUプレーントラフィックが、高優先度、広帯域、リアルタイムのタイプのトラフィックであるとする。さらに、MTCデバイス300cが、高優先度及び広帯域トラフィックのようなUプレーントラフィックを分類することが可能な適切なアプリケーションレイヤインテリジェンスを有しているとする。さらに、MTCデバイス300cのアプリケーションレイヤが、さらにこうしたトラフィック分類すなわち、高優先度及び広帯域をNASレイヤへ渡し、その結果、NASレイヤで開始されるサービス要求が、サービス要求メッセージ内に高優先度トラフィック通知を埋め込むとする。MTCデバイス300cのNASレイヤは、こうした高優先度トリガを受信すると、MTCデバイス300cがサービス要求メッセージ305cをMME302cへ送信する。このサービス要求メッセージ305cには、MTCデバイス300cが、高優先度及び広帯域トラフィック伝送に関するサービス要求を実行していることを示す情報要素が存在する。MME302cは、サービス要求シグナリングメッセージ305cを受信すると、まず、AVGrBWがMTCデバイス300cのトラフィックのプロファイルを伝送するのに十分かどうかをチェックする。このようなトラフィックのプロファイル又はトラフィック特性は、サービス要求メッセージ305cに埋め込まれてもよく、また、このようなトラフィックのプロフィールのパラメータは、ビットレートであってもよい。状態306cによって示されているように、AvGrBWが十分ではなく、その結果、シグナリングメッセージ305cに関する要求をサポートできない場合には、MME302cは、最小限の帯域幅の専用ベアラ生成処理を始動する。このような最小限の帯域幅のベアラ作成シグナリング処理は、メッセージ307cによって示されている。最小限の帯域幅の専用ベアラは、デフォルトベアラが通常関連付けられているものよりも小さいQCIQoSを有している。通常、デフォルトベアラはUプレーントラフィックに使用され、相対的に高いQoS取り扱いを有すると考えられる。しかしながら、最小限の帯域幅の専用ベアラは、主に警告又はヘルプトリガをMTCサーバ304cへ送信するために使用されるため、最小限の帯域幅の専用ベアラに関しては高いQoSで処理される必要はない。最小限の帯域幅の専用ベアラは、非常に小さい帯域幅が関連付けられている。MME302cが十分な量のAvGrBWを有しており、MTCデバイスのトラフィックを伝送するために必要な帯域幅がAvGrBWより小さい場合には、MME302cは、MTCデバイス300cに関連したトラフィックのために、どのベアラを割り当てるべきかすなわち、ベアラ識別子をチェックする。サービス要求305cがGBRベアラを所望し、MTCデバイス300cのGBRベアラのための帯域幅がトラフィックの伝送に十分な場合には、GBRベアラが提供される。また、このようなGBRベアラ要求がメッセージ305cによって提供されず、非GBRベアラプールに対して利用可能な帯域幅がトラフィックの伝送に十分な場合には、非GBRベアラが提供される。また、必要なベアラが、任意の量の帯域幅を有するGBRベアラであるが、必要な帯域幅値を有するGBRベアラがMTCデバイス300cのために存在しない場合には、MME302cは、既存のGBRベアラを無効化し、MTCデバイス300cのための広帯域GBRベアラを1つ生成する。また、要求がどんなベアラであってもよく、非GBRプールに関連する帯域幅が十分ではない場合には、GBRベアラが無効化され、非GBRベアラが提供されてもよい。また、上述の説明から、AvGrBWがMTCデバイス300cのトラフィックを伝送するために十分ではない場合には、最小限の帯域幅の専用ベアラが生成されることは明らかである。その他の場合においては、適当なベアラが特定され、サービス要求応答メッセージ308cによって提供される。すべての非GBRベアラが利用可能な帯域幅、及び、所定のMTCデバイスの全ての単一GBRベアラに関連する帯域幅の総和は、AvGrBW値に等しいことが重要である。例えば、4つの非GBRベアラと2つのGBRベアラとが存在し、各GBRベアラに関連する帯域幅が10ユニットであり、AvGrBWが60ユニットの場合には、すべての非GBRベアラが利用可能な帯域幅は、60-1010=40ユニットとなる。また、非GBRベアラプールに関連する帯域幅は、AvGrBW-GBRベアラ全ての関連する帯域幅となる。最小限の帯域幅の専用ベアラは、様々な方法で作成することが可能である。非特許文献2で説明されている既存のベアラ新規作成処理によれば、MME始動のベアラ生成処理は存在しないが、本発明に係る最小限の帯域幅の専用ベアラの作成に関しては、MME302cが、新しいシグナリング処理を用いることでP-GW303cに対してベアラ生成要求をトリガできるようにしてもよい。MME302cは、何らかの特別なトリガをP-GW303cへ送信することが可能であり、P-GW303cは、P-GW始動の専用ベアラ生成処理を開始することができる。この最小限の帯域幅の専用ベアラは、最小限のQoSパラメータを提供する専用ベアラ及び非GBRベアラである。もし、AvGrBWが存在せずにすなわち、AvGrBWが0、最小限の帯域幅専用ベアラが生成されると、P-GW303cは、この最小限の帯域幅の専用ベアラに関してトラフィックのシェーピングを実行せず、PCRFに対してG-AMBR違反を通知する必要がある。最小限の帯域幅の専用ベアラが作成されると、サービス要求成功NASメッセージ308cが、MTCデバイス300cへ送信されることが望ましい。MTCデバイス300cは、最小限の帯域幅の専用ベアラが確立されたことを示すサービス応答メッセージ308cを確認すると、最小限の帯域幅の専用ベアラを使用して、本質的には制御トラフィックと同様のアプリケーションのトラフィックを送信する。なお、応答メッセージ308cにバックオフタイマが含まれている場合は、そのタイマが有効である間は、警告メッセージを送信するための最小限の帯域幅の専用ベアラだけが許可されていると解釈する。つまり、そのタイマの有効期限が切れた場合は、通常通りのベアラを生成することが可能であると判断し、高優先度広帯域向けのサービス要求を送信する。さらに、この最小限の帯域幅の専用ベアラに関するEPSベアラ識別子は、メッセージ308cによって送信されるとする。このようなMTCサーバ304cに送信されるUプレーン警告メッセージは、メッセージ309cとして示される。このUプレーン警告メッセージ309cを受信すると、MTCサーバ304cは、グループ内の高優先度又は重要なトラフィックに関わっていないと考えられる他のMTCデバイスのトラフィックを特定する処理を開始する。ここで、MTCサーバ304cは、重要ではないトラフィックを送信しているデバイスとして、MTCデバイス301cを特定したとする。また、MTCサーバ304cは、重要ではないトラフィックを識別するために十分なインテリジェンスを持っており、その結果、MTCサーバ304cが、送信を停止させるためにMTCデバイス301cへのアプリケーションレイヤメッセージの送信を行うとする。このような送信停止メッセージは、メッセージ310cとして示される。MTCサーバ304cは、MTCデバイス301cが送信を中止したことを特定すると、さらに、最小限の帯域幅の専用ベアラを使用してMTCデバイス300cへ送信可CTSアプリケーションメッセージを送信する。あるMTCデバイス301cがグループ帯域幅を共有しないように外すことによって、他のMTCデバイス300cのための十分な帯域幅を確保することが可能となる。また、送信停止の依頼が可能な他のMTCデバイスが存在しないかすなわち、グループ内の他のMTCデバイスも高優先度トラフィックを送信している、又は、グループに属する任意の他のMTCデバイスをグループから外しても必要な帯域幅を得ることができない場合には、MTCデバイス300cは、帯域幅が解放されるのを待機する必要がある。しかしながら、一般的に、MTCデバイス300cが高優先度トラフィックを送信しようとしているときに、グループ内の他のMTCデバイスも高優先度トラフィックを送信している場合は非常に稀であり、その結果、上述の待機時間は許容可能な限界内となることが多いと考えられる。また、MTCデバイス301cを外した後に帯域幅が十分であるかどうかを決定する方法や、送信可メッセージ311cを送信するよう決定する方法においても、多くの様々な実施例が存在する。ある実施例では、MTCサーバ304cがビットレート監視機能を有し、この機能を用いてMTCデバイス300cへのCTSの送信を決定することが可能である。MTCデバイス300cは、送信可メッセージ311cを受信すると、新たなGBRベアラに関して全く新しい要求を生成するのではなく、最小限の帯域幅の専用ベアラのベアラ変更を行うよう要求する付加的な決定処理をトリガする。このようなベアラ変更処理は、GBRベアラに必要な帯域幅を取得するために実行される。非特許文献2で説明されているベアラ作成及び変更に関連する標準的な処理によれば、専用ベアラの生成はP-GW303cによってのみ実行可能である。従って、MTCデバイス300cが、最小限の帯域幅専用ベアラに関してベアラ変更処理を始動することが最も適切である。最小限の帯域幅の専用ベアラを要求するベアラ変更要求は、MME302cへ送信されるシグナリングメッセージ312cによって示されている。通常、ベアラ変更要求はNASメッセージである。MME302cは、ベアラ変更要求をMTCデバイス300cから受信すると、現在の利用可能なグループ帯域幅の状態313cに基づいて適切にベアラ変更要求に対して応答を行う。MTCデバイス301cからの送信停止によって、状態313cは、適切なAvGrBWを反映して、MTCデバイス300cの高優先度トラフィックを伝送できるようにするものである。MTCデバイス301cが送信を停止すると、P-GW303cが、MME302cに対してAvGrBW情報の通知を行うとする。その結果、MME302cは、ベアラ変更要求312cに対して肯定的なアクノレッジメントメッセージを送信する。このようなアクノレッジメントメッセージはシグナリングメッセージ314cによって示される。最小限の帯域幅の専用ベアラに関するベアラ変更は、P-GW303cで実行されてMME302cへ通知されてもよく、あるいは、MME302cで実行されてP-GW303cへ通知されてもよい。MTCデバイス300cは、最小限の帯域幅の専用ベアラに関する適切なベアラ変更をMME302cから受信すると、MTCサーバ304cへのUプレーントラフィックの送信を開始する。このMTCサーバ304cへのトラフィックはメッセージ315cによって示される。上記解決方法の説明から、MTCデバイス300cは、再試行シグナリングを追加することなく、高優先度及び広帯域幅トラフィックをMTCサーバ304cへ送信するために必要な帯域幅を取得し、これにより、本発明の目的を実現することが可能である。必要な帯域幅は、このような最小限の帯域幅の専用ベアラをセットアップすることによって取得される。なお、上述の解決方法の派生例は3GPP特有のシナリオで説明されているが、これらの派生例に関してもは、本発明を逸脱しない範囲で、同様の動作方法を有するシステムに適用可能である。<本発明の別の動作-MTCサーバがネットワークエンティティへ管理を委譲する>また、本発明の別の実施例では、MTCサーバからのCTSメッセージがMTCデバイスへ送信される必要はない。寧ろ、P-GWは、AvGrBWへの状態変更を検出すると、ベアラ変更要求をMMEへ送信し、MTCデバイスに必要な帯域がMTCサーバによって解放されたかどうかをMMEが判断することが可能である。MMEは、帯域が解放されることを決定すると、P-GWから送信されたベアラ変更メッセージをMTCデバイスへ渡す。以下、この本発明の好適な実施の形態の派生例について説明する。なお、本発明に係るこの派生例の動作を3GPP特有の構成を用いて説明するが、当業者であれば、MTCデバイスとMTCサーバとの間のパスが任意の一般的なネットワークセグメントであっても、同様の動作が有効であることが分かるであろう。図4において、MTCデバイス400は、通常、MTCサーバ404に対してP-GW403経由でUプレーントラフィックを送信する。MTCデバイス401がUプレーントラフィックをMTCサーバ404へ送信しており、MTCデバイス400がアイドルモードであるとする。また、MTCデバイス400、401は、グループベースの通信をMTCサーバ404との間で行い、グループ帯域幅の上限が課せられているとする。また、本発明の説明における動作の全ての仮定が適用され、動作の詳細及び仮定は上述の通りであるため、ここでは説明を省略する。上述の本発明の動作と同様に、MTCデバイス400は、メッセージ406に示されているように、高優先度トラフィック伝送トリガが付加されたサービス要求メッセージを送信することが可能である。次に、MME402は、状態407を使用し、MTCデバイス400のトラフィック要件を満たす利用可能なグループ帯域幅が利用可能ではないことを決定する。MME402は、最小限の帯域幅のベアラを決定し、望ましくはサービス要求応答メッセージ408によって、最小限の帯域幅のベアラのベアラ識別子を通知する。次に、MTCデバイス400は緊急のトラフィックの警告をMTCサーバ404へ送信する。このメッセージPAM:PriorityAlarmMessageはメッセージ409によって示される。そして、MTCサーバ404は、MTCデバイス400がグループ帯域幅の共有から除外可能かどうかをチェックする。MTCサーバ404は、MTCデバイス400に関連するビットレートを取得するためにP-GW403と通信を行って、どのデバイスがグループ帯域幅の共有から除外する必要があるかをチェックする。なお、MTCサーバ404とP-GW403との間のやり取りは、インタフェース412を使用して行うことが可能である。MTCサーバ404がP-GW403と通信を行うため、P-GW403とMTCサーバ404との間にアプリケーションプロトコルインタフェースApplicationProtocolInterface:APIが必要となる。通信が中止される必要があるMTCデバイスを特定することをMTCサーバ404が決定する際のチェック処理は、状態410によって示される。MTCサーバ404は、このようなMTCデバイス400を特定すると、送信停止メッセージ411をMTCデバイス401へ送信する。ここで図3Aとは異なり、MTCサーバ404は、CTSメッセージをMTCデバイス400へ送信しない。MME402は、MTCデバイス400に対して高優先度及び広帯域幅トラフィックの送信を開始するための通知処理を援助する。MTCデバイス401が送信を中止すると、P-GW403におけるAvGrBWの状態が変更され、AnGrBWの値がP-GW403において増大する。その結果、P-GW403は、上述のようにベアラ変更処理を利用して、ベアラ変更シグナリング413をMTCデバイス400へ送信する。MME402は、これらのベアラ変更シグナリング413を調べ、AvGrBWがMTCデバイス400に高優先度及び広帯域トラフィックを転送させるのに十分かどうかを決定する。このような決定処理は、上述のものと同様であり、ここでは説明を省略する。MME402は、MTCデバイス400がサービスを開始することができると判断すると、MTCデバイス400が使用すると思われるベアラに関して、関連ベアラ変更メッセージをMTCデバイス400へ渡す。あるいは、最小限の帯域幅専用ベアラが存在するだけならば、MME402は、この最小限の帯域幅の専用ベアラに関連するベアラ変更メッセージをMTCデバイス400へ渡す。MME402からMTCデバイス400へ送信されたベアラ変更シグナリングメッセージは、シグナリング414によって示されている。ベアラ変更メッセージ414を受信すると、MTCデバイス400は、そのアップリンク高優先度トラフィック伝送に対して、通知された専用ベアラを使用することが可能である。また、専用ベアラが存在しない場合には、MME402は、デフォルトベアラのみをMTCデバイス400へ通知する。このようなUプレーントラフィック伝送は、メッセージ415によって示される。この方法の主な利点は、図4に説明されているように、MTCデバイス400がベアラ変更処理を始動する必要がないことである。その結果、電力制約のあるMTCデバイスのバッテリ電力を節約できるという利点がある。また、別の利点として、MTCデバイス400がCTSメッセージを待機する必要がなく、必要なベアラを取得するまでの待ち時間が小さいという利点もある。明示的な最小限の帯域幅のベアラが生成される本発明の別の動作として、最小限の帯域幅の専用ベアラが、初期アタッチ処理の間に生成されてネットワークによって維持されるようにすることも可能である。最小限の帯域幅の専用ベアラは非常に小さいネットワークリソースしか使用しないので、このベアラは、ネットワークに負荷をかけることなく、事前に生成可能でありネットワークで維持可能であると考えられる。また、最小限の帯域幅の専用ベアラを事前に作成する利点として、最小限の帯域幅のベアラが作成されるのを待つことなく、メッセージ408のようなサービス要求応答メッセージが送信可能となる点も挙げられる。<MTCデバイスの機能図>次に、本発明の好適な実施の形態におけるモバイルデバイス例えば、MTCデバイスの機能アーキテクチャについて説明する。以下、図5を参照しながら、各機能コンポーネントについて説明する。図5に示される機能コンポーネントは、本発明を実行するモバイルデバイスの好適な実現手段である。しかしながら、当業者であれば、図5に図示されている主要な機能コンポーネントは、本発明の範囲から逸脱しない別の方法で実現可能であることが分かるであろう。図5に図示されている機能アーキテクチャは、上述されている本発明を実行するためにMTCデバイスで必要となるすべてのハードウェア、ソフトウェア、フォームウェアを有している。MTCデバイスの機能アーキテクチャ500は、例えば、アプリケーションレイヤ505、IPレイヤIPルーティングレイヤ504、NASレイヤ503、ASレイヤ502、無線通信レイヤ501などの機能ブロックを有している。このような標準的なレイヤ又は機能ブロックに加えて、機能アーキテクチャ500は、さらに、本発明に係る動作を実現するためのモジュール最小限ベアラ必要性推定モジュール506、高品質高優先度広帯域幅サービス要求トリガモジュール507、最小限広帯域幅ベアラ変更決定モジュール508、最小限広帯域幅ベアラ変更トリガモジュール509を有している。さらに、これらの機能エンティティ間には、モジュール間で情報の受け渡しを行うための適切なシグナリングインタフェースが設けられている。NASレイヤ503は、主に、MTCデバイスとそのMMEとの間のNASシグナリングのやり取りに使用される。このようなNASシグナリングは、トラッキングエリア更新、アイドル状態からアクティブ状態への変更時のサービス要求、PDNコネクション確立、PDNコネクション削除、ベアラ変更処理、アタッチ処理、デタッチ処理において使用可能である。また、ASレイヤ502は、MTCデバイスとeNB間の全てのシグナリングのために使用される。ASレイヤ502のシグナリングは、MTCデバイスとeNBとの間の無線ベアラを確立するために使用される。また、ASレイヤ502は、セル選択とセル監視機能のために用いられる。アプリケーションレイヤ505からのユーザプレーントラフィックは、IPレイヤ504を経由して送信されてASレイヤ502に届き、最終的に無線通信レイヤ501経由で送信される。ユーザプレーンパケットのデータユニット伝送を実現するため、インタフェース512、511、510が使用される。同様に、NASメッセージを伝送するために、適切なインタフェースがNASレイヤ503において使用される。このようなインタフェースは、図5で示されるインタフェース514、510である。また、無線通信レイヤ501は、MTCデバイスの物理レイヤのプロトコルを有している。MTCデバイスは、送信すべき高優先度及び広帯域幅トラフィックを有していると判断すると、高優先度及び広帯域幅トリガが埋め込まれたサービス要求をトリガする。高優先度トラフィックのためのサービス要求をトリガするという判断は、モジュール506で実行される。高優先度トラフィックのためのサービス要求をトリガするという判断は、NASレイヤ503からのトリガに基づいて、又は、アプリーケーションレイヤ505へのダイレクトインタフェースを使用することによって行われ得る。例えば、アプリケーションレイヤ505は、MTCデバイスが高優先度トラフィックを有しているをモジュール506へ通知すると、広帯域幅ベアラが必要とされ、高優先度トリガがサービス要求に含まれる必要があると判断することができる。このような決定がモジュール506で行われると、制御はインタフェース515を通じてモジュール507へ渡される。モジュール507は、NASレイヤ503へ渡されるべき関連データを形成又は収集する。この関連データは、ビットレートや、高優先度、広帯域幅トラフィックなどを表すための何らかのデータであってもよい。モジュール507は、インタフェース516を使用してNASレイヤ503へ制御データを渡す。また、モジュール507は、最小限の帯域幅のベアラに関するネットワークからの応答情報を処理する機能を有している。最小限の帯域幅のベアラがデフォルトベアラであり、最小限の帯域幅のベアラのIDが固有である場合には、MTCデバイスは、この情報を処理し、QoSを内部で変更する。このような機能もモジュール507に関連付けられている。NASレイヤ503は、新たな情報要素に高優先度トラフィックであることが挿入されたサービス要求メッセージを生成し、ASレイヤ502及び無線通信レイヤ501を通じて高優先度トラフィックのためのサービス要求を送信する。このサービス要求を送信した後、MTCデバイスはMTCサーバからCTSを受信する。このような場合に、アプリケーションレイヤ505は、モジュール508へトリガを送信し、最小限の帯域幅のベアラのためのベアラ変更処理をトリガできることを通知する。アプリケーションレイヤからのCTS受信トリガの処理はモジュール508で実行される。最小限の帯域幅のベアラのためのベアラ変更をトリガする決定がモジュール508で決定されると、制御はシグナリングインタフェース518を通じてモジュール509へ渡される。モジュール509では、トリガの決定が行われ、NASレイヤ503は、最小限の帯域幅の専用レイヤのためのベアラ変更を送信するよう要求される。モジュール509からNASレイヤ503へのトリガは、シグナリングインタフェース517経由で実行される。<デバイスの動作のフローチャート>次に図6を参照しながら、本発明の好適な実施の形態におけるモバイルデバイスの動作について説明する。第1ステップとして、チェックプロセス600がトリガされ、モバイルデバイスMTCデバイスであってもよいは、高優先度及び広帯域幅トラフィックを転送するための広帯域幅ベアラが必要か否かをチェックする。こうしたチェックは、ステップ600で実行される。このステップ600によって、高優先度及び広帯域トラフィックが送信される必要があるかどうかが特定される。このステップ600がいいえの場合には、ステップ601が実行される。ステップ601は、高優先度トラフィック及び広帯域幅トラフィックを通知するための新たな情報要素が付加されることのなく、通常のサービス要求をトリガする通常の処理を有している。また、ステップ600がはいの場合には、ステップ602が実行される。ステップ602では、高優先度トラフィックに関する新しい情報が付加されたサービス要求が作成されて送信される。ステップ602を実行した後、決定処理がトリガされる。この決定処理はステップ603によって示される。ステップ603では、高優先度トリガが付加されたサービス要求が受け入れられたかどうかがチェックされる。非常に稀にしか起こらないが、高優先度トラフィックに関する帯域幅を取得するために最小限の帯域幅のベアラのためのサービス要求が受け入れられなかった場合には、制御はステップ604に渡され、MTCデバイスは、後でサービス要求をリトライすることを決定する。ステップ603がはいであり、MMEがサービス要求応答によって最小限の帯域幅のベアラを提供する場合には、制御はステップ605に渡される。ステップ605では、MTCデバイスは、デフォルトベアラが与えられた場合にはベアラに関するQCIを低減させ、最小限の帯域幅のベアラを使用して警告メッセージをMTCサーバへ送信する。警告メッセージをMTCサーバへ送信した後、MTCデバイスはMTCサーバからのCTSを待機し、ステップ606に示すようにCTS受信状態のチェック処理を実行する。CTSを受信すると、ステップ608が実行され、MTCデバイスは、デバイス始動ベアラ変更処理を使用して、最小限の帯域幅に係るQCIを増加させるよう要求する。また、ステップ606がいいえの場合には、ステップ607が実行され、MTCデバイスは単にCTSを待機し続けるか、あるいは、利用可能な帯域幅を用いて緊急トラフィックに関連する情報をMTCサーバへ送信する。<本発明が応用された派生例>次に、本発明の好適な実施の形態に従った派生的な応用例について説明する。本発明の派生例は、コアネットワークが時間制御機能TimeControlledを実装しており、MTCデバイスが時間許容アプリケーションを有する構成において性能を拡張するために使用される。時間制御機能は、トラフィック伝送のためにネットワークを使用するMTCデバイスのアクセス時間に係るネットワーク制御を表す。時間制御機能がネットワークに存在している場合、MTCデバイスが時間許容TimeTolerantアプリケーションを有するときには、この時間制御機能の影響をほとんど受けない。なお、時間許容及び時間制御の詳細は、非特許文献1に説明されている。ネットワークが時間制御メカニズムを動作しているとき、ネットワークは、MTCデバイスに対してこの状態を通知し、その結果、MTCデバイスは、時間制御期間の間はネットワークを通じてトラフィックを送信しない。なお、ほとんどの場合において、MTCサーバではなくMTCデバイスのみが、この時間制御期間を把握している。時間制御期間が伝送される瞬間に、ネットワークが、MTCデバイス上の時間制御をMTCデバイスへ課すことを決定した場合には、MTCデバイスは帯域幅を有さず、時間制御状態に関してMTCサーバへ通知するためのアクセスさえ行わない。図7Aを参照しながら、このような時間制御トラフィック伝送環境に本発明を適用した場合について説明する。本発明の派生的な応用例では、最小限の帯域幅のベアラを生成することによって、MTCデバイスは、輻輳状態又はコアネットワークにおける時間制御状態をMTCサーバへ通知することが可能である。輻輳状態又は時間制御状態をMTCサーバへ通知することによって、MTCサーバが、ネットワークによって時間制御されたMTCデバイスへ、Uプレーントラフィックを送信しないようにすることが可能となる。MTCサーバは、このような時間制御状態においてMTCデバイスへトラフィックを送信し続けるならば、ネットワークに複数の問題をもたらすことになる。第1の問題は、時間制御状態が取り除かれるまでダウンリンクトラフィックに必要となる格納リソースである。第2の問題は、バッファオーバフローによってデータが失われてしまうかもしれないという問題である。以下、図7Aを参照しながら、応用例について説明する。図7Aでは、MTCデバイス709、708、707、706がP-GW701を通じてMTCサーバ702と通信を行っている。また、これらのMTCデバイスは、eNB710、S-GW704、MME705に接続されており、MTCサーバ702とグループ通信を行っているとする。上述のように、コアネットワーク700及び/又はアクセスネットワーク703が輻輳状態である場合には、ネットワークは、Uプレーントラフィック送信のためにMTCデバイスが3GPPネットワークへアクセスすることが禁止されていることをMTCデバイスへ通知する。さらに、これらのMTCデバイスは時間許容トラフィックを有しているとする。このような場合、MTCサーバ702は、時間制御条件を把握していないかもしれず、何らかの制御又はポーリングメッセージをこれらのMTCデバイスへ送信してしまい、ネットワークリソースを浪費してしまうことになる。このような問題を解決するために、例えば、MTCデバイス709は、こうしたネットワークの時間制御状態の通知を受けた場合には、デフォルトベアラ712に加えて、最小限の帯域幅のベアラ711を生成するようネットワークへ要求することが可能である。このような最小限の帯域幅のベアラ711は、時間制御又は輻輳状態であることをMTCサーバへ通知するためだけのものである。最小限の帯域幅のベアラ711を使用することで、MTCデバイス709は、メッセージをMTCサーバ702へ送信し、時間制御状態であることを通知する。MTCサーバ702がこのような情報を処理するとき、MTCサーバ702は、時間制御期間が満了するまで、MTCデバイス709へのメッセージの送信を中止する。なお、時間制御ウィンドウが静的であるならば、ウィンドウ期間をMTCサーバ702に通知することが可能である。一方、動的な時間制御ウィンドウ期間の場合には、ネットワークは、時間制御の満了の瞬間をランダムに通知し、MTCデバイス709は、最小限の帯域幅のベアラを使用して、時間制御の終了をMTCサーバ702へ通知する。MTCデバイス709は、MTCサーバ702へのトラフィックの送信を再開すると、最小限の帯域幅のベアラに関してモバイルデバイス始動のベアラ変更処理を実行するか、新たな専用ベアラを要求し、この後使用するために休止モードdormantmodeにおいて最小限の帯域幅のベアラを保持する。<本発明の派生的な応用例の詳細な説明>以下、図7Bを参照しながら、本発明のさらに別の派生的な応用例について説明する。MTCデバイス700aは、任意のネットワークセグメント701aを使用してMTCサーバ702aと通信を行っている。この任意のネットワークセグメント701aは、3GPPネットワークセグメントであってもよい。また、ネットワーク701aは、加入しているMTCデバイス上で何らかの時間制御を課しているとする。ここでは、時間制御は、MTCデバイスがある明確な期間の間はネットワーク701aの使用を禁じられることを意味する。また、ネットワークに輻輳が発生している場合に、ネットワークが時間制御を課してもよい。ネットワーク701aからMTCデバイス700aへ送信される時間制御情報は、メッセージ703aによって示されている。このメッセージ703aは任意のタイプのメッセージを用いて送信されてもよい。3GPP構成では、時間制御メッセージ703aは、ページングトリガ、サービス要求受け入れ、あるいは、任意のNASメッセージによって送信可能であり、特定のメッセージに限定されるものではない。MTCデバイス700aは、このメッセージ703aを確認すると、そのサーバMTCサーバ702aと通信を行うための最小限の帯域幅のベアラを取得するため、サービス要求メッセージ704aをネットワーク701aへ送信する。最小限の帯域幅のベアラの要求704aは、主に、MTCデバイス700aの時間制御状態をMTCサーバ702aへ通知するために実行される。ネットワーク701aは、上述のように最小限の帯域幅のベアラを作成し、最小限の帯域幅のベアラのIDを有する応答メッセージ705aをMTCデバイス700aへ送信する。このようなMTCデバイス700aへの応答メッセージと最小限の帯域幅のベアラの確立は、メッセージ705a、706aによってそれぞれ示されている。ここで、時間制御が課される期間が、MTCサーバ702aには知らされていないとする。このとき、MTCサーバ702aからMTCデバイス700aへ不要なトラフィックが送信されないようにするため、MTCデバイス700aは、最小限の帯域幅のベアラを使用して、Uプレーン警告メッセージをMTCサーバ702aへ送信する。このような警告メッセージは、メッセージ707aによって示される。MTCサーバ702aは、この警告メッセージを確認すると、適切な設定を行って、MTCデバイス700aへのUプレーントラフィックを妨げるか又は中断する。これは、状態708aに示される。また、ある時間経過した後、ネットワーク701aは、MTCデバイス700aの時間制御を緩和する決定を行う。時間制御の緩和は、明示的なメッセージ709aによって送信可能である。ネットワーク701aは、時間制御期間を事前に把握している場合には、その期間情報をメッセージ703aによって送信する。しかしながら、ほとんどの場合、ネットワーク701aは、この時間制御の正確な期間を知らず、明示的なトリガ709aによってMTCデバイス700aに通知しようとする。MTCデバイス700aは、メッセージ709aを受信すると、UプレーントラフィックをMTCサーバ702aへ送信するための最小限の帯域幅のベアラを拡張するよう、ネットワーク701aへ要求する。このようなベアラ変更シグナリングは、メッセージ710a、711aによって示されている。アップリンクのデータ送信はメッセージ712aによって示され、ダウンリンクのデータメッセージはメッセージ714aによって示される。<制御プレーンシグナリングを使用して、帯域幅が不足している状態をMTCサーバへ通知する本発明の派生例>上述の説明では、最小限の帯域幅のベアラが構成されると、MTCデバイスが最小限の帯域幅のベアラを使用して、Uプレーン警告メッセージをMTCサーバへ送信する本発明の動作について説明した。このUプレーン警告メッセージは、AvGrBWが0であることを通知するため、又は、MTCデバイスが時間制御状態であることを通知するために使用可能である。このような時間制御又はAvGrBWが無い状態において最小限の帯域幅のベアラを割り当て、このベアラを使用してMTCサーバへUプレーン警告メッセージを送信することにはいくつかの利点がある。第1の利点は、このような最小限の帯域幅のベアラの割り当てによって、MTCデバイスが接続モードに切り換えられ、その結果、MTCサーバが送信可情報を通知しようとした場合に、より簡単にMTCサーバがデバイスと通信を行えるようになるという点である。MTCデバイスが接続モードの場合、接続モードでページングを受信する際の遅延がなく、その結果、接続モードへの移行に関連した遅延が発生しないことから、MTCサーバからのメッセージの受信にほとんど時間を要さない。第2の利点は、MTCデバイスは接続モード時にはMTCサーバから到達可能なので、ネットワークからのページングシグナリングや、MTCデバイスからのサービス要求シグナリングを回避できるようになる点である。第3の利点は、MTCデバイスはUプレーン警告メッセージを使用してMTCサーバへ通知を行うので、このメッセージは、別の手段帯域メッセージ以外又はMTCサーバへのホップバイホップ転送を用いた場合よりも短い時間でMTCサーバへ送信可能であるという点である。しかしながら、MTCサーバへ通信を行うことが可能であり、MTCデバイスのAvGrBW=0の状態を通知することが可能な帯域幅がないときには、MTCデバイスがその現在の緊急状態を制御プレーンシグナリングを用いてMTCサーバへ通知し、依然としてアイドル状態のままでいることが有益となる場合もある。一般に、MTCデバイスがアイドルモードにあるときは、位置更新の頻度が小さく、MTCデバイスがハンドオフ管理のためのセルモニタリングを実行する必要がないので、電力消費が低いと考えられる。本発明の好適な実施の形態によれば、帯域幅が不足している状態にあること又は時間制御状態にあることに関する警告メッセージは、制御プレーンメッセージによってMTCサーバへ通知される。本発明の別の実施例として、MTCデバイスが制御プレーンメッセージをネットワークへ送信し、帯域幅が不足している状態であること又は時間制御状態であることについて、ネットワークからMTCサーバへ通知することが可能である。MTCサーバへ通知するためにCプレーンメッセージを使用すると、MTCデバイスが接続モードとなる必要が無いという利点に加えて、ネットワークが何らかの別の手段を使用することで、コアネットワークを伝送させずにMTCサーバと通信できるという別の利点がある。これは、特に、ネットワークが輻輳しているか、割り当てられるべき帯域がない場合に有用である。また、帯域幅が不足している状態すなわち、AvGrBW=0、又は、輻輳による時間制御状態を通知するために制御プレーンを使用する更なる利点として、MTCデバイスとネットワークとの間のインタフェースでは、Uプレーンメッセージと比較して制御プレーンメッセージのパケットサイズが小さいという点も挙げられる。通常、レイヤ化されたプロトコルアーキテクチャによれば、Uプレーンメッセージのサイズは大きくなる。したがって、帯域幅制約環境の下で、制御プレーンシグナリングを使用してMTCデバイスの警告状態をネットワークへ通知することは有用である。さらに、図8を参照しながら、本発明のシグナリング交換について説明する。図8において、MTCデバイス800は、ネットワークセグメント801を経由してMTCサーバ802と通信を行っている。このネットワークセグメント801は、3GPPネットワークであってもよいが、3GPPネットワークに限定されるものではない。このような構成において、MTCデバイス800は高優先度、広帯域幅、リアルタイムUプレーントラフィックをMTCサーバ802へ送信しようとしているかもしれない。MTCデバイス800は現在アイドルモードであり、この高優先度トラフィックを送信するために、ネットワーク801へのサービス要求メッセージ803の送信を行うとする。さらに、メッセージ803がネットワーク801で受信された場合にAvGrBWの値が0であるとする。なお、ネットワーク801が、メッセージ803を受信したときに、MTCデバイス800に時間制御を課すよう決定したとしてもよい。上述のネットワーク状態において、ネットワーク801は、適切な項目を有するサービス要求拒絶メッセージ804を送信することが可能である。この拒絶項目は、例えば、ネットワークが、拒絶の理由がAvGrBWが十分ではないか、ネットワーク801において時間制御アクティブであるかのどちらであることを通知するものである。MTCデバイス800は、メッセージ804を受信すると、Uプレーンメッセージを使用してMTCサーバ802へ届くベアラがないことを把握し、アイドルモードのままとなる。また、メッセージ804の拒絶項目を受信した後、MTCデバイス800は、決定処理を行って、ネットワーク801へCプレーンメッセージを送信することを決定する。このCプレーンメッセージは、MTCデバイス800の状態をMTCサーバ802へ通知するよう要求するものである。このCプレーンメッセージは、ネットワーク801が3GPPネットワークである場合には、TAUであってもよく、また、任意のNASメッセージであってもよい。Cプレーンメッセージ805には、AvGrBW=0の状態に関する情報、又は時間制御状態に関する情報が埋め込まれている。また、メッセージ805には、このような状態情報がMTCサーバ802へ渡される必要性に関する情報も含まれている。ネットワークエンティティ801は、制御メッセージ805を受信し、別の新たな制御メッセージ806をMTCサーバ802へ送信する。制御メッセージ806には、MTCデバイス800の状態情報が含まれている。なお、メッセージ806は、ネットワーク801及びMTCサーバ802を接続しているコアネットワークを経由して送信される必要はなく、別のネットワークを通じてメッセージ806を送信することが可能である。AvGrBWが0であることを通知するためのメッセージ806がMTCサーバ802へ送信された場合、MTCサーバ802は、上述のように、MTCデバイス800のために何らかの利用可能な帯域幅を取得しようと試みる。MTCサーバ802は、MTCデバイス800のための帯域幅を取得すると、CTSメッセージ807をMTCデバイス800へ送信することが可能となる。MCTデバイス800は、前回サービス要求を行ったときにネットワーク801によって無線ベアラが割り当てられておらず、アイドルモードなので、ネットワーク801は、ページングメッセージ808をMTCデバイス800へ送信する。ページングメッセージ808を受信すると、MTCデバイス800は、サービス要求メッセージ809を送信し、接続モードへ移行する。サービス要求809が受け入れられ、MTCデバイス800が接続モードへ移行し、すべての無線ベアラがセットアップされると、MTCデバイス800は、ネットワーク801にバッファされているCTSメッセージ807を受信することが可能となる。さらに、MTCサーバ802がAvGrBWに付加されている何らかの帯域幅を取得したことにより、AvGrBWが0より大きいので、ネットワーク801は、サービス要求受け入れメッセージ810をMTCデバイス800へ送信する。このサービス要求受け入れメッセージ810は、高優先度、広帯域幅、リアルタイムトラフィックを転送するための適切な帯域幅が利用可能であることに関する通知を有していてもよい。サービス要求が受け入れられることは、無線ベアラがMTCデバイス800のためにセットアップされることを意味する。さらに、CTSメッセージ807が無線ベアラを通じてMTCデバイス800へ送信されるとする。CTSメッセージ807を受信すると、MTCデバイス800は、適切なベアラを使用して、UプレーントラフィックをMTCサーバ802へ送信できるようになる。なお、MTCサーバ802へのUプレーントラフィック送信は、メッセージ811によって示される。また、AvGrBWが0より大きい場合、ネットワーク801は、CTSメッセージ807を待機せずにページングメッセージを送信することも可能である。また、別の派生的な応用例では、MTCデバイス800は、このようなトリガをサービス要求メッセージ803に挿入することにより、緊急トラフィックに関する警告メッセージを送信することが可能である。また、AvGrBWが0ならば、サービス要求803が挿入された警告メッセージの処理が行われた後、制御プレーンメッセージがMTCサーバ802へ送信される。なお、本発明は、最も実用的かつ好適な実施の形態であると考えられるものを示し、説明を行っているが、当業者であれば、本発明の範囲から逸脱しない程度にデザイン及びパラメータの詳細について様々な派生例が存在することが分かるであろう。また、上記の本発明の実施の形態の説明で用いた各機能ブロックは、典型的には集積回路であるLSILargeScaleIntegrationとして実現される。これらは個別に1チップ化されてもよいし、一部又はすべてを含むように1チップ化されてもよい。なお、ここでは、LSIとしたが、集積度の違いにより、ICIntegratedCircuit、システムLSI、スーパーLSI、ウルトラLSIと呼称されることもある。また、集積回路化の手法はLSIに限るものではなく、専用回路又は汎用プロセッサで実現してもよい。LSI製造後に、プログラムすることが可能なFPGAFieldProgrammableGateArrayや、LSI内部の回路セルの接続や設定を再構成可能なリコンフィギュラブルプロセッサを利用してもよい。さらには、半導体技術の進歩又は派生する別技術によりLSIに置き換わる集積回路化の技術が登場すれば、当然、その技術を用いて機能ブロックの集積化を行ってもよい。例えば、バイオ技術の適応などが可能性としてあり得る。