(57)【要約】【課題】マシン型通信用に強化されたランダムアクセスチャネル（ＲＡＣＨ）の設計を提供する。【解決手段】  無線通信ネットワークのマシーンツーマシン（Ｍ２Ｍ）によって無線アクセスネットワーク（ＲＡＮ）レベルのアクセス排除を行い、前記Ｍ２Ｍデバイスが前記Ｍ２Ｍデバイスのアクセスクラス（ＡＣ）に基づいて異なる排除パラメータを用いることでアクセス確率を適応して調整するステップ、およびアクセスを取得後、基地局とのランダムアクセスチャネル（ＲＡＣＨ）手順を行うステップを含む方法。【選択図】図５
2013532929.tif 000002
【特許請求の範囲】
【請求項１】
無線通信ネットワークのマシーンツーマシン（以下、Ｍ２Ｍと称す）によって無線アクセスネットワーク（ＲＡＮ）レベルのアクセス排除を行い、前記Ｍ２Ｍデバイスが前記Ｍ２Ｍデバイスのアクセスクラス（ＡＣ）に基づいて異なる排除パラメータを用いることでアクセス確率を適応して調整するステップ、および
アクセスを取得後、基地局とのランダムアクセスチャネル（ＲＡＣＨ）手順を行うステップを含む方法。
【請求項２】
ネットワークの他のマシン型通信（以下、ＭＴＣと称す）デバイスの間で、サービスタイプ、ＭＴＣサーバー、および前記Ｍ２ＭデバイスのデバイスＩＤに基づく非アクセス層（ＮＡＳ）レベルのアクセス分散を行うステップを更に含む請求項１に記載の方法。
【請求項３】
マシン型通信（以下、ＭＴＣと称す）デバイス上で動作するＭＴＣアプリケーションの優先に基づいて、前記ＭＴＣアプリケーションレベルのアクセス分散を行うステップを更に含む請求項１に記載の方法。
【請求項４】
第１のアクセス排除要因は、前記Ｍ２Ｍデバイスに用いられ、
第２のアクセス排除要因は、人間同士（Ｈ２Ｈ）の通信に用いられる請求項１に記載の方法。
【請求項５】
第１の再試行タイマーは、Ｍ２Ｍデバイスに用いられ、
第２の再試行タイマーは、人間同士（Ｈ２Ｈ）の通信に用いられる請求項１に記載の方法。
【請求項６】
無線通信ネットワークのマシーンツーマシン（以下、Ｍ２Ｍと称す）によって第１のバックオフ時間を用いるステップ、
前記第１のバックオフ時間を用いた後、ランダムアクセスチャネル（以下、ＲＡＣＨと称す）プリアンブルを基地局に伝送するステップ、
コンテキスト情報に基づいて前記第１のＲＡＣＨプリアンブル検出が失敗した時、第２のバックオフ時間を用いるステップ、および
前記第２のバックオフ時間を用いた後、前記ＲＡＣＨプリアンブルを前記基地局に再送するステップを含む方法。
【請求項７】
前記Ｍ２Ｍデバイスは、前記第１のバックオフ時間用に内部分散を有する請求項６に記載の方法。
【請求項８】
前記第１のバックオフ時間は、マシン型通信（ＭＴＣ）のアプリケーションレベルまたはコアネットワークレベルで割り当てられる請求項６に記載の方法。
【請求項９】
前記第１のバックオフ時間は、ＲＡＣＨアクセスレベルで割り当てられ、前記第１のバックオフ時間は、異なる無線ネットワーク一時識別子（ＲＮＴＩ）によってブロードキャストすることによって、または保留ビットまたは無線リソース制御（ＲＲＣ）メッセージのいずれかによって示される請求項６に記載の方法。
【請求項１０】
前記ＲＡＣＨプリアンブルは、マシン型通信専用である請求項６に記載の方法。
【請求項１１】
前記ＲＡＣＨプリアンブルは、マシン型通信専用のサブフレーム及びリソースブロックに伝送される請求項６に記載の方法。
【請求項１２】
前記第２のバックオフ時間は、ランダムアクセス応答（ＲＡＲ）メッセージによって前記基地局から伝送されるバックオフインジケータに含まれる請求項６に記載の方法。
【請求項１３】
前記第２のバックオフ時間は、デバイスタイプおよびアプリケーション／サービスタイプを含むデバイス関連のコンテキスト情報の少なくとも一部に基づいた前記基地局によって決められる請求項１２に記載の方法。
【請求項１４】
前記第２のバックオフ時間は、負荷情報および歴史的統計情報を含むネットワーク関連のコンテキスト情報に基づいたＭ２Ｍによって競合される請求項６に記載の方法。
【請求項１５】
前記Ｍ２Ｍデバイスは、前記ＲＡＣＨプリアンブルを再送する前に１つ以上のサブフレームを待つ請求項６に記載の方法。
【請求項１６】
前記Ｍ２Ｍデバイスは、前記ＲＡＣＨプリアンブルを再送する前に、節電モードに戻り、前記次の不連続受信（ＤＲＸ）サイクルまで待機する請求項６に記載の方法。
【請求項１７】
無線通信ネットワークの複数のマシン型通信（ＭＴＣ）デバイスによって用いられる基地局により第１のランダムアクセスチャネル（以下、ＲＡＣＨと称す）リソースを分割するステップ、
複数の人間同士（以下、Ｈ２Ｈと称す）デバイスによって用いられる第２のＲＡＣＨリソースを分割するステップ、および
複数のマシーンツーマシン（以下、Ｍ２Ｍと称す）デバイスおよび複数のＨ２Ｈデバイスによってシェアされる第３のＲＡＣＨリソースを分割するステップを含む方法。
【請求項１８】
前記第１、前記第２、および前記第３のＲＡＣＨリソースは、互いに共有しない請求項１７に記載の方法。
【請求項１９】
前記第１のＲＡＣＨリソースは、前記第２のＲＡＣＨリソースのサブセットである請求項１７に記載の方法。
【請求項２０】
ＲＡＣＨリソースは、ＲＡＣＨ伝送時間、ＲＡＣＨ伝送周波数、およびＲＡＣＨプリアンブルを含む請求項１７に記載の方法。
【請求項２１】
前記第１、前記第２、および前記第３のＲＡＣＨリソースは、負荷情報に基づいて適応して割り当てられる請求項１７に記載の方法。
【請求項２２】
前記第１、前記第２、および前記第３のＲＡＣＨリソースは、衝突確率または伝送係数に基づいて適応して割り当てられる請求項１７に記載の方法。
【請求項２３】
無線通信システムのマシン型通信（ＭＴＣ）デバイスによって基地局から伝送されたマシン型通信（以下、ＭＴＣと称す）形態の信号を受信するステップ、
前記基地局から伝送されたＭＴＣアップリンクグラントを受信するステップ、および
無線ソース制御（ＲＲＣ）接続の確立なしに、前記ＭＴＣアップリンクグラントソース領域でＭＴＣデータを送信するステップを含む方法。
【請求項２４】
セル内の複数のＭＴＣデバイスは共通の無線ベアラ設定をシェアする請求項２３に記載の方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本出願は、３５ U.S.C. §１１９の下、２０１０年８月４日に出願された米国特許仮出願番号第６１／３７０，５５５号「Protocol Design to Reduce RACH Collision in Machine-Type Communications,」からの優先権を主張するものであり、これらの全ては引用によって本願に援用される。
【０００２】
本発明は、マシン型通信に関し、特に、マシン型通信用に強化されたランダムアクセスチャネル（ＲＡＣＨ）の設計に関するものである。
【背景技術】
【０００３】
マシン型通信は、必ずしもヒューマンインタラクションを要しない１つ以上の要素（ｅｎｔｉｔｙ）を含むデータ通信の一種である。 マシン型通信用に最適化されたサービスは、人間同士（Ｈ２Ｈ）の通信用に最適化されたサービスと異なる。一般的に、マシン型通信サービスは、異なる市場シナリオ、純粋なデータ通信、低コストと製造努力、および端末ごとに低トラフィックを有する潜在的に非常に大量の通信端末を含むため、現存の移動通信ネットワークと異なる。
【０００４】
マシーンツーマシン（Ｍ２Ｍ）およびマシン型通信（ＭＴＣ）は、使用ケースを説明し、マシン型通信サービスのさまざまな特徴を説明するのに用いられる。Ｍ２ＭおよびＭＴＣデバイスは、 “モノのインターネット（ｉｎｔｅｒｎｅｔ ｏｆ ｔｈｉｎｇｓ）”を有効にする、次世代の無線ネットワークの一部となる。潜在的なＭ２ＭおよびＭＴＣアプリケーションは、セキュリティ、追跡（ｔｒａｃｋｉｎｇ ａｎｄ ｔｒａｃｉｎｇ）、支払い、健康、遠隔保守／制御、計量、および消費者向けデバイスを含む。マシン型通信サービスの主な特徴は、低移動性、時間制御性、遅延許容性、パケット交換オンリー、少量のデータ伝送、モバイル発信オンリー、低頻度モバイル終了（ｉｎｆｒｅｑｕｅｎｔ ｍｏｂｉｌｅ  ｔｅｒｍｉｎａｔｅｄ）、ＭＴＣモニタリング、プライオリティアラーム、安全接続、位置特定トリガ（ｌｏｃａｔｉｏｎ ｓｐｅｃｉｆｉｃ ｔｒｉｇｇｅｒ）、アップリンクデータのためのネットワーク提供の目的地（ｎｅｔｗｏｒｋ ｐｒｏｖｉｄｅｄ ｄｅｓｔｉｎａｔｉｏｎ ｆｏｒ ｕｐｌｉｎｋ ｄａｔａ、）低頻度の伝送、およびグループベースのＭＴＣなどの特徴を含む。
【０００５】
ＭＴＣデバイスまたはＭＴＣサーバー間、または２つのＭＴＣデバイス間のエンドツーエンドアプリケーションが、３ＧＰＰシステムで提供される。３ＧＰＰシステムは、ＭＴＣ用に最適化されたトランスポートおよび通信サービスを提供する。しかしながら、ＭＴＣトラフィックは、ネットワーク／コアネットワークによって制御されない可能性がある。例えば、ＭＴＣアプリケーションは、多くのＭＴＣデバイスに同時に“何か”をするように要求する可能性があり、その結果、非常に短い時間内に大量のＭ２Ｍデバイスが無線サービスにアクセスしようとすることになる。よって、多くのＭＴＣデバイスは、大量のランダムアクセスチャネル（ＲＡＣＨ）のプリアンブルを送信するため、高いＲＡＣＨの衝突確率を招く。また、コアネットワークエンティティがダウンした時、連続的なアクセスの試行からＭＴＣデバイスを延期する機構がない。よって、ＭＴＣデバイス自身のサービングネットワークが失敗（ｆａｉｌ）した時、多くのＭＴＣデバイスは、ローミング状態にあり、全てローカル競合ネットワークに移動する可能性があり、（まだ）失敗していないネットワークで潜在的に過負荷を発生させる可能性がある。
【０００６】
図１（従来技術）は、３ＧＰＰネットワーク１００の無線ネットワークの混雑のユースケース（ｕｓｅ ｃａｓｅ）を表している。３ＧＰＰネットワーク１００は、ＭＴＣサーバー１１０、パケットデータネットワークゲートウェイ（ＰＤＮ ＧＷ）１２０、サービングＧＷ１３０、２つの基地局ｅＮＢ１４１およびｅＮＢ１４２、および複数のＭ２Ｍデバイスを含む。図１に表されるように、無線ネットワークの混雑は、大量の同時データの伝送がいくつかのＭＴＣアプリケーションで行われた時に発生する。典型的なアプリケーションの一つは、大量のセンサを有するブリッジモニタリングである。列車が橋を通過した時、全てのＭＴＣセンサは、ほぼ同時にモニタリングデータを伝送する。同様の事が大雨の時にハイドロロジーモニタリング、および侵入者が侵入した時にビルディングモニタリングで生じる。よって、ネットワークが最適化されて、特定領域の大量のＭＴＣデバイスがデータをほぼ同時に伝送できるようにすることが望ましい。
【０００７】
図２（従来技術）は、３ＧＰＰネットワーク２００のコアネットワークの混雑のユースケースを表している。３ＧＰＰネットワーク２００は、ＭＴＣサーバー２１０、パケットデータネットワークゲートウェイ（ＰＤＮ ＧＷ）２２０、サービングＧＷ２３０、２つの基地局ｅＮＢ２４１およびｅＮＢ２４２、および複数のＭ２Ｍデバイスを含む。多くのＭＴＣアプリケーションでは、大量のＭＴＣデバイスは、単一のＭＴＣユーザー（例えば、ＭＴＣユーザー２５０）に属されている。これらのＭＴＣデバイスは共同にＭＴＣグループの一部である（例えば、ＭＴＣグループ２６０）。例えば、ＭＴＣユーザー２５０は、ＭＴＣグループ２６０と関連しており、ＭＴＣユーザー２５０は、ＭＴＣサーバー２１０を所有する。ＭＴＣグループ２６０のＭＴＣデバイスは、ＭＴＣサーバー２１０と通信する。一般的に、
任意の特定のセルでＭＴＣデバイスにより同時に送信されるデータが制限することで、無線ネットワークへの過剰な負荷を防ぐ方法によって、同じＭＴＣグループのＭＴＣデバイスは、ネットワーク上に散乱している。しかしながら、図２に示されるように、大量のＭＴＣデバイスが同時にデータを送信／受信した時、データの混雑が、モバイルコアネットワーク、またはモバイルコアネットワークとＭＴＣグループに関連するデータトラフィックが集合されるＭＴＣサーバーとの間のリンクで生じる可能性がある。よって、ネットワークオペレータとＭＴＣユーザーは、同じＭＴＣグループで送信／受信されたデータ用に最大レートを実行する手段を有することが望ましい。
【０００８】
３ＧＰＰシステムの現在のＲＡＣＨ手順に基づいて、最大のＲＡＣＨ容量は、一秒当たり６４，０００のランダムアクセスアテンプトである（例えば、１サブフレーム当たり１ＰＲＡＣＨおよび６４のＲＡ用のプリアンブル）。よって、１％のＲＡＣＨの衝突確率の要求に適用するためには、最大のＲＡＣＨアクセスは、約一秒当たり６４３となる。このような最大ＲＡＣＨアクセス速度は、高速と見なされ、いくつかのＭＴＣアプリケーションにおいて大量の同時データ伝送をサポートするのに十分でない可能性がある。また、余分なＲＡＣＨリソースの割り当ては、無線リソースの非効率的利用を招く可能性がある。強化されたＲＡＣＨの解決法は、最適化されたＭＴＣサービスに求められる。
【発明の概要】
【発明が解決しようとする課題】
【０００９】
マシン型通信用に強化されたランダムアクセスチャネル（ＲＡＣＨ）の設計を提供する。
【課題を解決するための手段】
【００１０】
適応ＲＡＣＨの操作が３ＧＰＰ無線通信のマシン型通信（ＭＴＣ）に提供される。適応ＲＡＣＨの操作は、コンテキスト情報に基づいてＲＡＣＨ衝突確率を減少し、ネットワークの過負荷を制御し、システムパフォーマンスを向上させる。コンテキスト情報は、デバイス関連の情報およびネットワーク関連の情報を含む。デバイス関連の情報は、デバイスタイプおよびサービスまたはアプリケーションタイプを含む。ネットワーク関連の情報は、ネットワーク負荷情報および歴史的統計情報を含む。コンテキスト情報に基づき、ＭＴＣデバイスは、異なるレベルで適応ＲＡＣＨの操作を用いることによって、さまざまなネットワークアクセスおよびＲＡＣＨパラメータを調整する。例えば、アプリケーションレベルおよびネットワークレベルでは、ＭＴＣデバイスは、ＲＡＣＨアクセス用にそのアクセス確率および／またはＲＡＣＨのバックオフ時間を調整する。無線アクセスネットワーク（ＲＡＮ）レベルでは、ＭＴＣデバイスは、そのアクセス確率および／またはＲＡＣＨのバックオフ時間を調整するか、または調整されたＲＡＣＨ無線リソースおよびプリアンブルを用いてＲＡＣＨのプリアンブルを送信する。
【００１１】
第１の実施形態では、ＭＴＣデバイスは、ＡＰＰ、ＮＡＳ、および／またはＲＡＮレベルを含む異なるレベルでＲＡＣＨの操作前のアクセス確率を調整する。Ｈ２Ｈアクセスクラス（ＡＣ）に比べ、Ｍ２Ｍアクセスクラス（ＡＣ）は、異なるアクセス確率、排除パラメータ、および再試行タイマーパラメータを用いることができる。アプリケーションレベルのアクセス分散では、排除は、サービスタイプに基づいてアクセスを優先することで行われる（異なるアプリケーションのＱｏＳ要求および／または遅延許容レベルに基づく）。ＮＡＳレベルのアクセス分散では、排除は、アクセス制限によって行われる（例えばサービスタイプ、ＭＴＣサーバー、およびデバイスＩＤに基づいてアクセスを優先する）。ＲＡＮレベルのアクセス分散では、排除は、異なるＡＣクラス用に異なる排除要因を用いることで行われる。
【００１２】
第２の実施形態では、ＭＴＣデバイスは、ＡＰＰ、ＮＡＳ、および／またはＲＡＮレベルを含む異なるレベルでＲＡＣＨの操作中にそのバックオフ時間を調整する。ＲＡＣＨバックオフ遅延は、第１のＲＡＣＨプリアンブルの送信前でもＲＡＣＨプリアンブル衝突の後でも用いられることができる。第１のＲＡＣＨの前の初期のＲＡＣＨアクセス分散は、高いレベルのＲＡＣＨコンテンションを防ぎ、よって、アプリケーションまたはネットワークレベルで適用される。一旦、ＲＡＣＨ衝突が認められると、特定のバックオフタイマーがＲＡＣＨ手順中、各ＭＴＣデバイスに用いられることができる。異なるバックオフ時間は、異なる遅延許容性Ｍ２Ｍシナリオに用いられることができる。
【００１３】
第３の実施形態では、ＭＴＣデバイスは、ＲＡＮレベルで調整されたＲＡＣＨリソースを有するＲＡＣＨプリアンブルを送信する。ネットワークは、Ｍ２Ｍ−ｏｎｌｙデバイス、Ｈ２Ｈ−ｏｎｌｙデバイス、およびＭ２ＭとＨ２Ｈデバイスの両方によって用いられるリソース用にＲＡＣＨリソースの割り当てを適応して調整する。アプリケーション要求および優先アクセスクラスに基づいてデバイスは、専用のＲＡＣＨリソースまたはシェアのＲＡＣＨリソースのいずれかの使用を選択する。また、ＲＡＣＨリソースの割り当ては、負荷情報（例えば、Ｍ２Ｍトラフィック負荷および／またはＨ２Ｈトラフィック負荷）、ＲＡＣＨ衝突確率、および他のコンテキスト情報に基づいて更に調整される。
【００１４】
第４の実施形態では、ＲＡＣＨを用いない解決が用いられ、低移動性または移動性のないＭＴＣデバイス用にＭＴＣデータを送信する。ＭＴＣの要求が経時的に、かつ異なるＭＴＣデバイス全体で通常、固定されるため、再構成されたＵＬリソースが用いられて、ＭＴＣデータを送信する。ＭＴＣデータは、ＲＲＣの確立なしに、ＵＬリソースに伝送され、ＲＲＣシグナリングオーバーヘッドを減少する。１つの実施形態では、ｅＮＢは、ブロードキャスティングまたは専用の伝送を通して、ＭＴＣデバイスにＭＴＣ構成を伝送し、次いで１つまたは複数のＭＴＣグラントを伝送する。ＭＴＣデバイスは、グラントされたリソースを用いてＭＴＣデータを送信する。ＲＡＣＨを用いない解決は、どのコンテンションベースのアクセス機構も必要とせず、多くのＭＴＣサービス／アプリケーションに適合する。
他の実施形態及びそれらの利点が以下に詳細に説明される。この概要は、説明を限定するものではない。
【図面の簡単な説明】
【００１５】
【図１】図１は、３ＧＰＰネットワーク１００の無線ネットワークの混雑のユースケースを表している。
【図２】図２は、３ＧＰＰネットワーク２００のコアネットワークの混雑のユースケースを表している。
【図３】本実施態様に基づくマシン型通信（ＭＴＣ）をサポートする３ＧＰＰネットワークを表している。
【図４】本実施態様に基づく適応ランダムアクセスチャネル（ＲＡＣＨ）の操作を表している。
【図５】アクセス確率を調整することで適応ＲＡＣＨの操作の第１の選択を表している。
【図６】ＲＡＣＨのバックオフ時間を調整することで適応ＲＡＣＨの操作の第２の選択を表している。
【図７】ＲＡＣＨリソースの割り当てを調整することで適応ＲＡＣＨの操作の第３の選択を表している。
【図８】マシン型通信を最適化するＲＡＣＨ（ＲＡＣＨ−ｌｅｓｓ）を用いない解決方法を表している。
【図９】本実施態様に基づく最適化されたマシン型通信（ＭＴＣ）用の適応ＲＡＣＨの操作の方法のフローチャートである。
【発明を実施するための形態】
【００１６】
発明の実施の形態を説明する。その例が添付の図面に示されている。
【００１７】
図３は、本発明の実施形態に基づくマシン型通信（ＭＴＣ）をサポートする３ＧＰＰネットワーク３００を表している。３ＧＰＰネットワーク３００は、複数のＭＴＣデバイス（例えば、図３に示されたＭＴＣデバイス３１４）と通信することで各種のＭＴＣサービスをＭＴＣユーザー３１２に提供するＭＴＣサーバー３１１を含む。図３の例では、ＭＴＣサーバー３１１、ＭＴＣユーザー３１２、およびパケットデータネットワークゲートウェイ（ＰＤＮ ＧＷ）３１３は、コアネットワーク３１０の一部に属する。ＭＴＣデバイス３１４およびそのサービング基地局（ｅＮＢ）３１５は、無線アクセスネットワーク（ＲＡＮ）３２０の一部に属する。ＭＴＣサーバー３１１は、ＰＤＮ ＧＷ３１３、サービングＧＷ３１６、およびｅＮＢ３１５によってＭＴＣデバイス３１４と通信する。また、移動管理ノード（ＭＭＥ）３１７は、ｅＮＢ３１５、サービングＧＷ３１６、およびＰＤＮ ＧＷ３１３と通信し、３ＧＰＰネットワーク３００の無線アクセスデバイスの移動管理をする。注意するのは、タームＭＴＣは、人間同士（Ｈ２Ｈ）の通信と比べて、機械間（Ｍ２Ｍ）の通信とも呼ばれ、ＭＴＣデバイスは、Ｈ２Ｈと比べてＭ２Ｍデバイスとも呼ばれている。
【００１８】
図３の例では、ＭＴＣサーバー３１１は、確立されたアプリケーションプログラミングインタフェース（ＡＰＩ）３４０によってアプリケーション（ＡＰＰ）プロトコル層で各種のＭＴＣサービス／アプリケーションをＭＴＣユーザー３１２に提供する。典型的なＭＴＣアプリケーションは、セキュリティ（例えば、監視システム）、追跡（例えば、走行距離連動型料金収受）、支払い（例えば、自動販売機およびゲーム機）、健康（例えば、健康推進システム）、遠隔保守／制御、計量（例えば、スマートグリッド）、および消費者向けデバイス（例えば、電子書籍）を含む。エンドツーエンドのＭＴＣサービスの提供のために、ＭＴＣサーバー３１１は、３ＧＰＰネットワークの複数のＭＴＣデバイスと通信する。各ＭＴＣデバイス（例えば、ＭＴＣデバイス３１４）は、各種のプロトコル層モジュールを含んで、エンドツーエンドのＭＴＣアプリケーションおよびデータ接続をサポートする。アプリケーションレベルでは、ＡＰＰモジュール３３１は、ＡＰＰプロトコル層（例えば、点線３４１によって表されている）でＭＴＣサーバー３１１と通信し、エンドツーエンドの制御／データを提供する。ネットワークレベルでは、ＮＡＳモジュール３３２は、非アクセス層（ｎｏｎ−ａｃｃｅｓｓ  ｓｔｒａｔｕｍ； ＮＡＳ）プロトコル層（例えば、点線３４２によって表されている）でＭＭＥ３１７と通信し、移動管理および他の発信（ｓｉｇｎａｌｉｎｇ）機能をサポートする。無線アクセスネットワーク（ＲＡＮ）レベルでは、ＲＲＣモジュール３３３は、システム情報のブロードキャスト、ＲＲＣ接続制御、ページング、無線構成制御、ＱｏＳ制御などを管理する無線リソース制御（ＲＲＣ）プロトコル層でｅＮＢ３１５と通信する（例えば、点線３４３によって表されている）。
【００１９】
３ＧＰＰシステムでは、ランダムアクセスチャネル（ＲＡＣＨ）が携帯電話または他の無線アクセス端末、例えばコンテンションベースのアップリンク伝送のＭＴＣまたはＭ２Ｍデバイスに用いられる。ＲＡＣＨは、無線アクセス端末で用いられる共有アップリンクチャンネルであり、アクセスをリクエストして、アップリンクチャネルの所有権（ｏｗｎｅｒｓｈｉｐ）を取得し、ＲＡＣＨ手順によってそれらのサービング基地局との伝送を初期化する。ＭＴＣサーバーがネットワークオペレータドメイン内に必ずしもあるわけではなく、且つエンドツーエンドのＭＴＣサービスがＭＴＣサーバーと関連するわけではないため、ＭＴＣトラフィックは、ネットワーク／コアネットワークによって制御されない可能性がある。よって、非常に短い時間内に大量のＭ２Ｍデバイス（例えば、セルのＵＥ、またはｅＮＢ、またはＭＭＥの数において設計寸法よりかなり大きい）が無線サービスにアクセスしたい場合、ＭＴＣデバイスからそれらのサービング基地局に伝送された大量のＲＡＣＨのプリアンブルは、高いＲＡＣＨの衝突確率を招く可能性がある。また、コアネットワークがダウンした時、ＭＴＣデバイス自身のサービングネットワークが失敗した時、多くのＭＴＣデバイスは、ローミング状態にあり、全てローカル競合ネットワークに移動し、（まだ）失敗していないネットワークで潜在的に過負荷を発生させる可能性がある。
【００２０】
１つの実施態様として、従来のＲＡＣＨ手順は、コンテキスト情報に基づいて用いられ、ＲＡＣＨの衝突確率を減少し、ネットワークの過負荷を制御し、システムパフォーマンスを向上させる。コンテキスト情報は、デバイス関連の情報およびネットワーク関連の情報を含む。デバイス関連の情報は、デバイスタイプ（例えばＭ２ＭデバイスまたはＨ２Ｈデバイス）およびサービスまたはアプリケーションタイプ（例えば、セキュリティ、追跡、支払い、健康、遠隔保守／制御、計量、および消費者向けデバイス）を含む。ネットワーク関連の情報は、負荷情報および歴史的統計情報を含む。得られたコンテキスト情報（例えば、太い点線３５０で表されたＭＴＣサーバー３１１からＭＴＣサーバー３１４、または細い点線３５１で表されたＭＭＥデバイス３１７からＭＴＣデバイス３１４に転送されたコンテキスト情報）に基づき、ＭＴＣデバイス３１４は、異なる層で適応ＲＡＣＨの操作を用いることによって、さまざまなネットワークアクセスおよびＲＡＣＨパラメータを調整することができる。例えば、ＡＰＰ層およびＮＡＳ層では、ＭＴＣデバイス３１４は、適応ＲＡＣＨの操作用にそのアクセス確率またはＲＡＣＨのバックオフ時間を調整する。一方、ＲＲＣ層では、ＭＴＣデバイス３１４は、そのアクセス確率またはＲＡＣＨのバックオフ時間を調整するか、または適応ＲＡＣＨの操作用に調整されたＲＡＣＨリソースを用いたＲＡＣＨのプリアンブルを送信する。過負荷表示などのコンテキスト情報（混雑したネットワークエンティティ、例えばＡＰＮ、またはＭＴＣサーバーなど）は、ＭＭＥ３１７からｅＮＢ３１５に伝送されることができる。情報に基づいて、ｅＮＢ３１５は、ＭＴＣデバイス３１４からの特定の接続リクエストに応じるかどうかを決める。
【００２１】
図４は、１つの新しい実施態様に基づく適応ランダムアクセスチャネル（ＲＡＣＨ）の操作を表している。図４の例では、ＭＴＣデバイス４１０は、ｅＮＢ４２０によってＭＴＣサーバー４３０と通信する。ＲＡＣＨを開始する前に、ＭＴＣデバイス４１０は、まず適応ＲＡＣＨの操作用にコンテキスト情報を得る。コンテキスト情報は、ＭＴＣデバイス自体によって得られるか、またはネットワークを介してＭＴＣサーバーから転送されることができる。デバイス関連のコンテキスト情報では、ＭＴＣデバイスは、通常それ自体のデバイス情報から得る。ネットワーク関連のコンテキスト情報では、ＭＴＣデバイスにそれらの情報を得るいくつかのいくつかの方式（ｓｃｈｅｍｅ）がある。第１の方式では、ＭＴＣデバイスは、収集または推定によってネットワーク関連の情報の一部を得ることができる。例えば、ＭＴＣデバイス４１０は、ＲＡＣＨの衝突確率およびアプリケーションのトラフィック特性などの以前の統計に基づいて歴史的統計を収集し、ネットワーク負荷情報を推定する。第２の方式では、ネットワークまたはアプリケーションは、ＮＡＳ、Ｓｌ−ＡＰ、またはＡＰＰレベルの信号（ｓｉｇｎａｌｉｎｇ）によってコンテキスト情報を転送する。例えば、ネットワークは、システム情報ブロック（ＳＩＢ）によってコンテキスト情報を通知する（例えば、ステップ４４１によって表されたように、コンテキスト情報は、ｅＮＢ４２０からＭＴＣデバイス４１０に転送される）。第３の方式では、コンテキスト情報は、ページングチャネル（ＰＣＨ）上のページングメッセージ（例えば、ステップ４４２によって表されたように、ＭＴＣサーバー４３０からＭＴＣデバイス４１０へのページングメッセージ）によって転送される。例えばページングメッセージは、状態パラメータを含み（または特定のタイプのページングコードまたはページングＩＤを用いる）、現在の負荷状態（例えば高／中／低の負荷レベル）を示す。ページングチャネルは、ページングされたＩＤまたはページングされたノードのグループも通知し、ＲＡＣＨを伝送するための規則を明確にすることができる（例えば、ページングメッセージへの付加排除確率（ａｐｐｅｎｄ  ｂａｒｒｉｎｇ  ｐｒｏｂａｂｉｌｉｔｙ）、遅延時間値、または他の関連のパラメータ）。デバイス始動のＲＡＣＨ伝送（例えばプッシュ方法）では、ＭＴＣデバイス４１０は、ＲＡＣＨを開始する前に、ＰＣＨをチェックし、コンテキスト情報を得る。ネットワーク始動のＲＡＣＨ伝送（例えばプル方法）では、ＭＴＣデバイス４１０は、ＰＣＨを受けて、ページングＩＤ、ＲＡＣＨアクセスポリシー、またはコンテキスト情報を識別するページングメッセージを得る。
【００２２】
コンテキスト情報を得た後、ＭＴＣデバイス４１０は、適応ＲＡＣＨの操作を用いてネットワークへのアクセスを取得し、ＭＴＣサーバー４３０と通信する。３つの選択が可能である。第１の選択では、ＭＴＣデバイス４１０は、ＡＰＰ、ＮＡＳ、および／またはＲＡＮレベルを含む異なるレベルでＲＡＣＨの操作の前にそのアクセスの確率を調整する（ステップ４５０）。第２の選択では、ＭＴＣデバイス４１０は、ＡＰＰ、ＮＡＳ、および／またはＲＡＮレベルを含む異なるレベルでＲＡＣＨの操作中にそのバックオフ時間を調整する（ステップ４６０）。第３の選択では、ＭＴＣデバイス４１０は、ＲＡＮレベルで調整されたＲＡＣＨリソースを有するＲＡＣＨプリアンブルを送信する（ステップ４７０）。これらの選択では、ＲＡＣＨの操作は、デバイスタイプ、サービス／アプリケーションタイプ、負荷のレベル、および／または歴史的統計を含むコンテキスト情報に基づいて適応される。３つの適応ＲＡＣＨの選択のそれぞれが付加の詳細とともに以下に述べられる。
【００２３】
図５は、無線ネットワーク５００のアクセス確率を調整する、適応ＲＡＣＨの操作の第１の選択を表している。無線ネットワーク５００は、ＭＴＣデバイス５１０およびｅＮＢ５２０を含む。ＭＴＣデバイス５１０がそのサービングｅＮＢ５２０とＲＡＣＨ手順を開始した後、ＭＴＣデバイス５１０は、アクセス排除を行うことでそのアクセス確率を調整する。Ｈ２Ｈアクセスクラス（ＡＣ）に比べ、Ｍ２Ｍアクセスクラス（ＡＣ）は、異なるアクセス確率、排除パラメータ、および再試行タイマーパラメータを用いることができる。これらの手順は、アプリケーションレベル、ＮＡＳレベル、またはＲＡＮレベル（例えば、ＲＡＣＨアクセスレベル）のアクセス分散で実施されることができる。アプリケーションレベルのアクセス分散では、排除は、サービスタイプに基づいてアクセスを優先することで行われる。例えば、異なるアクセス確率は、異なるアプリケーションのＱｏＳ要求および／または遅延許容レベルに基づく。ＮＡＳレベルのアクセス分散では、排除は、アクセス制限、例えばサービスタイプ、ＭＴＣサーバー、およびデバイスＩＤ（例えば、新しいＭＴＣ ＩＤ、国際移動体装置識別番号（ＩＭＥＩ）、国際移動体加入者識別番号（ＩＭＳＩ）など）に基づいてアクセスを優先することで行われる。ＲＡＮレベルのアクセス分散では、排除は、アクセスクラス排除機構の異なるａｃ−ＢａｒｒｉｎｇＦａｃｔｏｒを用いることで行われる。例えば、異なる排除要因および再試行タイマーがＭＴＣデバイスに用いられる。また、新しいＡＣクラスがＭ２Ｍに定義されることができ、Ｍ２Ｍ ＡＣクラス排除は、ＲＡＣＨレベル、コアネットワーク／アプリケーションレベル、または両方で実施されることができる。
【００２４】
ステップ５３１のアクセス排除の完了後、次いでＭＴＣデバイス５１０がｅＮＢ５２０とＲＡＣＨ手順を開始する。ステップ５４１では、ＭＴＣデバイス５１０は、ＲＡプリアンブルをｅＮＢ５２０に伝送する。ステップ５４２では、ｅＮＢは、ＲＡ応答（ＲＡＲ）をＭＴＣデバイス５１０に送信し返す。ＲＡプリアンブルがうまくデコードされた時、ＲＡＲは、ＭＴＣデバイス５１０に用いる後続のアップリンク伝送のアップリンクグラントを含む。ステップ５４３では、ＭＴＣデバイス５１０は、承認された（ｇｒａｎｔｅｄ）アップリンクリソースによって、ＲＲＣ接続リクエスト（例えばＭＳＧ３）をｅＮＢ５２０に伝送する。最後に、ステップ５４４では、ｅＮＢ５２０は、ＲＲＣＲＡＣＨコンテンション解決（例えばＭＳＧ４）をＭＴＣデバイス５１０に送信し返し、ＭＴＣデバイス５１０とＲＲＣ接続を確立し、ＲＡＣＨ手順を完了する。異なるプロトコル層で実施される各種のアクセス分散技術を用いてアクセス確率を調整することで、大量のＭＴＣデバイスのアクセス確率は、好ましく優先されて分散され、ＲＡＣＨの衝突確率を減少する。
【００２５】
図６は、無線ネットワーク６００のバックオフ時間を調整する、適応ＲＡＣＨの操作の第２の選択を表している。無線ネットワークは、ＭＴＣデバイス６１０およびｅＮＢ６２０を含む。適応ＲＡＣＨの操作の第２の選択では、ＲＡＣＨのバックオフ時間は、コンテキスト情報に基づいて適応して調整される。ＲＡＣＨバックオフ遅延は、アプリケーションレベル、コアネットワークレベル（例えばＮＡＳ層）、またはＲＡＮレベル（例えばＲＡＣＨアクセスレベル）に実施されることができる。また、ＲＡＣＨバックオフ遅延は、第１のＲＡＣＨプリアンブルの送信前でもＲＡＣＨプリアンブル衝突の後でも用いられることができる。第１のＲＡＣＨの前の初期のＲＡＣＨアクセス分散は、高いレベルのＲＡＣＨコンテンションを防ぐことができるので、アプリケーションまたはネットワークレベルに適している。一旦、ＲＡＣＨ衝突が認められると、特定のバックオフタイマーがＲＡＣＨ手順中、各ＭＴＣデバイスに用いられることができる。
【００２６】
図６に示されるように、ＭＴＣデバイス６１０は、第１のＲＡＣＨプリアンブルの送信前にステップ６３１の初期のアクセス分散を実行する。更に具体的に言えば、ＭＴＣデバイス６１０は、ＲＡＣＨプリアンブルをｅＮＢ６２０に送信する前に、第１のバックオフ時間＃１を用いる。第１のバックオフ時間は、各種の方式によって決められることができる。１つの実施形態では、ＭＴＣデバイス６１０は、第１のバックオフ時間の値用に内部（ｂｕｉｌｔ−ｉｎ）分散を有する。例えば、各ＭＴＣデバイスは、所定の範囲からバックオフ時間＃１用の値をランダムに選択する。第２の実施形態では、第１のバックオフ時間は、デバイス関連のコンテキスト情報に基づいてアプリケーションレベルまたはネットワークレベルで割り当てられる。例えば、より短いバックオフ時間は、比較的緊急の高いアプリケーション、またはより低い遅延許容性を有するアプリケーションに割り当てられる。一方、より長いバックオフ時間は、より長い遅延許容性を有するアプリケーションに割り当てられる。異なるバックオフ時間は、サービス／アプリケーションタイプ、ＭＴＣサーバー、ＭＴＣデバイスのデバイスＩＤに基づいて割り当てられることもできる。第３の実施形態では、ＭＴＣデバイス６１０は、第１のＲＡＣＨが新しい手順を用いる前にバックオフを行い、ｅＮＢは、異なるランダムアクセス無線ネットワーク一時識別子（ＲＡ−ＲＮＴＩ）を通じたブロードキャスト、リザーブビット、またはＲＲＣメッセージによって、第１のバックオフ時間を示す。
【００２７】
バックオフ時間＃１が過ぎた後、ステップ６３２では、ＭＴＣ６１０は、ＲＡＣＨプリアンブルをｅＮＢ６２０に送信する。多くのＭＴＣデバイスが同じＲＡＣＨリソース（例えば、ＲＡＣＨリソースブロックおよびＲＡＣＨプリアンブル）をシェアするため、ｅＮＢ６２０は、ＲＡＣＨ衝突により、ＲＡＣＨプリアンブルをデコードすることができない可能性がある。ＲＡＣＨ衝突が発生した時、第２のバックオフ時間は、ＲＡＣＨプリアンブルを再送する前、ＭＴＣ６１０によって用いられる。第１のバックオフ時間と同様に、第２のバックオフ時間は、コンテキスト情報に基づいてアプリケーションレベル、ネットワークレベル、またはＲＡＮレベルで割り当てられる。
【００２８】
図６の例では、ｅＮＢ６２０は、ＲＡＣＨ衝突を検出した後、ステップ６３３で第２のバックオフ時間を決める。しかしながら、ｅＮＢ６２０では、ＭＴＣデバイス６１０のコンテキスト情報を知らない可能性がある。１つの例では、ＭＴＣデバイス６１０は、ＭＴＣデバイスタイプ専用であるＲＡＣＨプリアンブルを用いる。もう１つの例では、ＭＴＣデバイス６１０は、ＭＴＣデバイスタイプ専用であるＲＡＣＨリソース（例えば、プリアンブル、リソースブロック、およびサブフレーム）を用いる。専用のＲＡＣＨプリアンブルまたはＲＡＣＨリソースに基づいて、ｅＮＢ６２０は、ＭＴＣデバイス６１０のデバイスタイプを識別することができる。一旦、ｅＮＢ６２０が異なるデバイスタイプを判別すると、ｅＮＢ６２０は、異なるＲＡ−ＲＮＴＩのＲＡＲによって異なるバックオフ時間を割り当てる。１つの実施形態では、図６のブロック６５１に表されるように、第２のバックオフ時間＃２は、Ｅ／Ｔ／Ｒ／Ｒ／ＢＩメディアアクセス制御（ＭＡＣ）サブヘッダの第１のオクテットに含まれるバックオフインジケータ（ＢＩ）を用いて割り当てられる。
【００２９】
ステップ６３３では、第２のバックオフ時間を決めた後、ｅＮＢ６２０は、ステップ６３４で、バックオフインジケータを有するＲＡＲをＭＴＣデバイス６１０に伝送する。ＭＴＣデバイスは、ステップ６４１でＲＡプリアンブルを再送する前に第２のバックオフ時間を用いる。ＲＡプリアンブルをうまくデコーディングした後、ｅＮＢ６２０は、ステップ６４２でアップリンクグラントを有するＲＡＲをＭＴＣデバイス６１０に送信し返す。ステップ６４３では、ＭＴＣデバイス６１０は、承認されたアップリンクリソースによって、ＲＲＣ接続リクエスト（例えばＭＳＧ３）をｅＮＢ６２０に伝送する。最後に、ステップ６４４では、ｅＮＢ６２０は、ＲＲＣ接続リクエスト（例えばＭＳＧ４）をＭＴＣデバイス６１０に送信し返し、ＲＲＣ接続を確立し、ＲＡＣＨ手順を完了する。
【００３０】
異なるバックオフ時間は、異なる遅延許容性Ｍ２Ｍシナリオに用いられることができる。例えば、アプリケーションが高い遅延許容性を有する場合、デバイスは、ＲＡＣＨアクセスのために次の不連続受信（ＤＲＸ）のアクティブ期間まで延期することができる。一方、アプリケーションがＫタイムスロットのスケールで遅延を許容できる場合、デバイスは、次のＫタイムスロットにＲＡＣＨアクセスを延期する可能性がある。また、異なるバックオフ時間が、ネットワーク関連のコンテキスト情報およびアクセスクラスのタイプに基づいて用いられてもよい。例えば、負荷が高い時、クラス１のデバイス（例えば、高い優先度）は、［５、１０］サブフレーム内にＲＡＣＨアクセスを延期し、クラス２のデバイス（例えば、低い優先度）は、［２０、３０］サブフレーム内にＲＡＣＨアクセスを延期する。一方、負荷が低い時、クラス１のデバイスは、そのＲＡＣＨアクセスを延期せず、クラス２のデバイスは、［０、１０］サブフレーム内にＲＡＣＨアクセスを延期する。
【００３１】
図７は、無線ネットワーク７００のＲＡＣＨリソースの割り当てを調整する、適応ＲＡＣＨの操作の第３の選択を表している。無線ネットワーク７００は、Ｈ２Ｈデバイス７１０、Ｍ２Ｍデバイス７２０、およびＨ２Ｈデバイス７１０とＭ２Ｍデバイス７２０の両方をサービングするｅＮＢ７３０を含む。ステップ７３１では、ｅＮＢ７３０は、Ｈ２Ｈデバイス７１０およびＭ２Ｍデバイス７２０にＲＡＣＨリソースの割り当てをブロードキャストする。ＲＡＣＨリソースの用語は、ＲＡＣＨ無線リソースおよびＲＡＣＨプリアンブルの両方を指している。第１の実施形態では、専用のＲＡＣＨ無線リソース（例えば無線リソースブロックおよびサブフレーム）は、ＭＴＣ−ｏｎｌｙデバイスに割り当てられる。例えば、新しいＭＴＣ−ＲＡＣＨパラメータは、ＳＩＢ２に定義される。もう１つの実施形態では、後方交換性をサポートするために、新しいＭＴＣ−ＲＡＣＨパラメータは、新しいＳＩＢ（例えばＳＩＢ Ｘ）に定義されることができる。第２の実施形態では、専用のＲＡＣＨプリアンブルは、ＭＴＣ−ｏｎｌｙデバイスに割り当てられる。
【００３２】
ネットワークは、Ｍ２Ｍ−ｏｎｌｙデバイス、Ｈ２Ｈ−ｏｎｌｙデバイス、およびＭ２ＭとＨ２Ｈデバイスの両方によって用いられるリソース用にＲＡＣＨリソースの割り当てを適応して調整する。図７のブロック７５０によって示されるように、例えば、全てのＲＡＣＨリソースは、３つの部分に分けられる。具体的には、ＲＡＣＨ伝送のタイムスロット、周波数トーン（ｆｒｅｑｕｅｎｃｙ ｔｏｎｅ）、およびプリアンブルは、３つの部分に分けられる。第１のＲＡＣＨリソース部分＃１は、Ｍ２Ｍ−ｏｎｌｙ ＲＡＣＨアクセス用に割り当てられ、第２のＲＡＣＨリソース部分＃２は、Ｈ２Ｈ−ｏｎｌｙ ＲＡＣＨアクセス用に割り当てられ、第３のＲＡＣＨリソース部分＃３は、Ｍ２ＭとＨ２Ｈ ＲＡＣＨアクセスによってシェアされる。アプリケーション要求および優先アクセスクラスに基づいてデバイスは、専用のＲＡＣＨリソースまたはシェアのＲＡＣＨリソースのいずれかの使用を選択する。また、ＲＡＣＨリソースの割り当ては、負荷情報、衝突確率、および他のコンテキスト情報に基づいて更に調整される。例えば、ネットワークは、Ｈ２Ｈアクセス用に、全てのＲＡＣＨ伝送の機会を割り当て、Ｍ２Ｍ−ｏｎｌｙアクセス用に、全てのＲＡＣＨ伝送の機会のサブセットを割り当てることができる。割り当ては、Ｍ２Ｍトラフィック負荷および／またはＨ２Ｈトラフィック負荷に基づいて適応して構成されることができる。割り当ては、衝突および伝送係数に基づいて適応して構成されることもできる。
【００３３】
適応リソース割り当ての１つの実施形態では、ｅＮＢは、第１の期間にＭ２ＭおよびＨ２ＨでシェアされたＲＡＣＨリソースを割り当てる。デバイスの数が小さいほど、深刻な衝突が観測されず、更なる最適化を必要としなくなる。しかしながら、第２の期間では、ｅＮＢは、高いＲＡＣＨ衝突頻度を観測する。よって、ｅＮＢは、正常な着信コール（ｐｈｏｎｅ ｃａｌｌ）のユーザエクスペリエンスを補償するために、Ｈ２Ｈトラフィック専用のＲＡＣＨリソースの一部を割り当てる。ほとんどのＭ２Ｍトラフィックが、通常、より遅延許容性をもっているため、ｅＮＢは、ＲＡＣＨリソースの残りをＭ２Ｍトラフィックに割り当てる。Ｍ２Ｍデバイスの数が割り当てられたＲＡＣＨリソースのサポート可能な数より高い場合、ＲＡＮ／ＮＡＳレベルトラフィック分散などによって、Ｍ２Ｍトラフィックを分散させる一層の改善が必要となる。ｅＮＢは、ＲＡＣＨリソースを動的に調整することができる。例えば、着信コールがより少ない時、ｅＮＢは、より多くのＲＡＣＨリソースをＭ２Ｍトラフィックに割り当てることができる。
【００３４】
図８は、無線ネットワーク８００のマシン型通信を最適化するＲＡＣＨ（ＲＡＣＨ−ｌｅｓｓ）を用いない解決方法を表している。無線通信８００は、ＭＴＣデバイス８１０およびｅＮＢ８２０を含む。タイミングアドバンス（ＴＡ）および第１のＵＬグラントを得るためにＲＡＣＨがコンテンションベースのアップリンク伝送に正常に用いられる時、ｅＮＢ用のＲＡＣＨアクセスのコストが高くなる。これは、特に、Ｍ２Ｍデバイスの数が非常に大きい時に該当し、多くのＭＴＣアプリケーションの典型的な特徴である。しかしながら、低移動性または移動性のないＭＴＣデバイスでは、ＭＴＣデバイスが同じセルに依頼してＭＴＣデータを送信することができるため、ＴＡは、常に固定される。よって、ＭＴＣの要求が経時的に、かつ異なるＭＴＣデバイス全体で通常、固定されるため、これらのＭＴＣデバイスが再構成されたＵＬリソースを用いてデータを送信することは可能である。ＵＬリソースは、シェアまたは専用とすることができる。ＲＲＣシグナリングオーバーヘッドを減少するために、ＲＲＣの確立なしに、ＭＴＣデータをＵＬリソースに伝送することが可能である。セル内のＭＴＣデバイスが共通の無線ベアラ設定（ｃｏｎｆｉｇｕｒａｔｉｏｎ）をシェアすることも可能である。ＲＡＣＨが６つのＲＢを有する時、小さいＭＴＣデータ伝送は１つまたは２つのＲＢのみ必要である。図８の例では、ステップ８３０にて、ｅＮＢ８２０は、ブロードキャスティングまたは専用の伝送を通して、ＭＴＣ構成をＭＴＣデバイス８１０に伝送する。ステップ８４０およびステップ８５０では、ｅＮＢ８２０は、１つまたは複数のＭＴＣグラントを伝送する。最後に、ステップ８６０では、ＭＴＣデバイス８１０は、グラントされたリソースを用いてＭＴＣデータを送信する。このようなＲＡＣＨを用いない解決は、どのコンテンションベースのアクセス機構も必要とせず、多くのＭＴＣサービス／アプリケーションに適合する。
【００３５】
図９は、１つの新しい態様に基づく最適化されたマシン型通信（ＭＴＣ）用の適応ＲＡＣＨの操作の方法のフローチャートである。ステップ９０１では、ＭＴＣデバイスは、ＭＴＣサーバーからコンテキスト情報を受信する。コンテキスト情報は、デバイス関連の情報およびネットワーク関連の情報を含む。デバイス関連の情報は、デバイスタイプおよびサービスまたはアプリケーションタイプを含む。ネットワーク関連の情報は、ネットワーク負荷情報および歴史的統計情報を含む。コンテキスト情報に基づき、ＭＴＣデバイスは、適応ＲＡＣＨの操作を用いることによって、さまざまなネットワークアクセスおよびＲＡＣＨパラメータを調整する。第１の適応ＲＡＣＨの操作では、ＭＴＣデバイスは、ＡＰＰ、ＮＡＳ、および／またはＲＡＮレベルを含む異なるレベルのＲＡＣＨの前のアクセス確率を調整する（ステップ９０２）。第２の適応ＲＡＣＨの操作では、ＭＴＣデバイスは、ＡＰＰ、ＮＡＳ、および／またはＲＡＮレベルを含む異なるレベルのＲＡＣＨの操作中のＲＡＣＨバックオフ時間を調整する（ステップ９０３）。第３の適応ＲＡＣＨの操作では、ＭＴＣデバイスは、ＲＡＮレベルで調整されたＲＡＣＨリソースを用いたＲＡプリアンブルを伝送する（ステップ９０４）。３つの選択は、３つの選択は共存して組み合わさって用いられることができる（ステップ９０５）。最後に、ステップ９０６では、ＲＡＣＨを用いない解決は、最適化されたマシン型通信に用いられる。
【００３６】
本発明は、説明のためにある特定の実施の形態に関連して述べられているが本発明はこれを制限するものではない。よって、種々の変更、改変、及び上述の実施の形態の種々の特徴の組み合わせがこの請求項に記載したような本発明の範囲内で、行い得る。
【符号の説明】
【００３７】
１００、２００、３００…３ＧＰＰネットワーク
１１０、２１０、３１１、４３０…ＭＴＣサーバー
１２０、２２０、３１３…ＰＤＮ ＧＷ
１３０、２３０、３１６…Ｓ−ＧＷ
１４１、１４２、２４１、２４２、３１５…ｅＮＢ
４２０、５２０、６２０、７３０、８２０…ｅＮＢ
２５０、３１２…ＭＴＣユーザー
２６０…ＭＴＣグループ
３１０…コアネットワーク
３１４、４１０、５１０、６１０、８１０…ＭＴＣデバイス
３１７…移動管理ノード（ＭＭＥ）
３２０…ＲＡＮ
３３１…ＡＰＰモジュール
３３２…ＮＡＳモジュール
３３３…ＲＲＣモジュール
３４０…ＡＰＩ
３４１、３４２、３４３…点線
３５０、３５１…細い点線
５００、６００、７００、８００…無線ネットワーク
６５１、７５０…ブロック
７１０…Ｈ２Ｈデバイス
７２０…Ｍ２Ｍデバイス
【図１】
2013532929.tif 000003
【図２】
2013532929.tif 000004
【図３】
2013532929.tif 000005
【図４】
2013532929.tif 000006
【図５】
2013532929.tif 000007
【図６】
2013532929.tif 000008
【図７】
2013532929.tif 000009
【図８】
2013532929.tif 000010
【図９】
2013532929.tif 000011
【国際調査報告】
2013532929.tif 000012
2013532929.tif 000013
2013532929.tif 000014
2013532929.tif 000015