無線通信ネットワークのマシーンツーマシン以下、M2Mと称すによって無線アクセスネットワークRANレベルのアクセス排除を行い、前記M2Mデバイスが前記M2MデバイスのアクセスクラスACに基づいて異なる排除パラメータを用いることでアクセス確率を適応して調整するステップ、およびアクセスを取得後、基地局とのランダムアクセスチャネルRACH手順を行うステップを含む方法。ネットワークの他のマシン型通信以下、MTCと称すデバイスの間で、サービスタイプ、MTCサーバー、および前記M2MデバイスのデバイスIDに基づく非アクセス層NASレベルのアクセス分散を行うステップを更に含む請求項1に記載の方法。マシン型通信以下、MTCと称すデバイス上で動作するMTCアプリケーションの優先に基づいて、前記MTCアプリケーションレベルのアクセス分散を行うステップを更に含む請求項1に記載の方法。第1のアクセス排除要因は、前記M2Mデバイスに用いられ、第2のアクセス排除要因は、人間同士H2Hの通信に用いられる請求項1に記載の方法。第1の再試行タイマーは、M2Mデバイスに用いられ、第2の再試行タイマーは、人間同士H2Hの通信に用いられる請求項1に記載の方法。無線通信ネットワークのマシーンツーマシン以下、M2Mと称すによって第1のバックオフ時間を用いるステップ、前記第1のバックオフ時間を用いた後、ランダムアクセスチャネル以下、RACHと称すプリアンブルを基地局に伝送するステップ、コンテキスト情報に基づいて前記第1のRACHプリアンブル検出が失敗した時、第2のバックオフ時間を用いるステップ、および前記第2のバックオフ時間を用いた後、前記RACHプリアンブルを前記基地局に再送するステップを含む方法。前記M2Mデバイスは、前記第1のバックオフ時間用に内部分散を有する請求項6に記載の方法。前記第1のバックオフ時間は、マシン型通信MTCのアプリケーションレベルまたはコアネットワークレベルで割り当てられる請求項6に記載の方法。前記第1のバックオフ時間は、RACHアクセスレベルで割り当てられ、前記第1のバックオフ時間は、異なる無線ネットワーク一時識別子RNTIによってブロードキャストすることによって、または保留ビットまたは無線リソース制御RRCメッセージのいずれかによって示される請求項6に記載の方法。前記RACHプリアンブルは、マシン型通信専用である請求項6に記載の方法。前記RACHプリアンブルは、マシン型通信専用のサブフレーム及びリソースブロックに伝送される請求項6に記載の方法。前記第2のバックオフ時間は、ランダムアクセス応答RARメッセージによって前記基地局から伝送されるバックオフインジケータに含まれる請求項6に記載の方法。前記第2のバックオフ時間は、デバイスタイプおよびアプリケーション/サービスタイプを含むデバイス関連のコンテキスト情報の少なくとも一部に基づいた前記基地局によって決められる請求項12に記載の方法。前記第2のバックオフ時間は、負荷情報および歴史的統計情報を含むネットワーク関連のコンテキスト情報に基づいたM2Mによって競合される請求項6に記載の方法。前記M2Mデバイスは、前記RACHプリアンブルを再送する前に1つ以上のサブフレームを待つ請求項6に記載の方法。前記M2Mデバイスは、前記RACHプリアンブルを再送する前に、節電モードに戻り、前記次の不連続受信DRXサイクルまで待機する請求項6に記載の方法。無線通信ネットワークの複数のマシン型通信MTCデバイスによって用いられる基地局により第1のランダムアクセスチャネル以下、RACHと称すリソースを分割するステップ、複数の人間同士以下、H2Hと称すデバイスによって用いられる第2のRACHリソースを分割するステップ、および複数のマシーンツーマシン以下、M2Mと称すデバイスおよび複数のH2Hデバイスによってシェアされる第3のRACHリソースを分割するステップを含む方法。前記第1、前記第2、および前記第3のRACHリソースは、互いに共有しない請求項17に記載の方法。前記第1のRACHリソースは、前記第2のRACHリソースのサブセットである請求項17に記載の方法。RACHリソースは、RACH伝送時間、RACH伝送周波数、およびRACHプリアンブルを含む請求項17に記載の方法。前記第1、前記第2、および前記第3のRACHリソースは、負荷情報に基づいて適応して割り当てられる請求項17に記載の方法。前記第1、前記第2、および前記第3のRACHリソースは、衝突確率または伝送係数に基づいて適応して割り当てられる請求項17に記載の方法。無線通信システムのマシン型通信MTCデバイスによって基地局から伝送されたマシン型通信以下、MTCと称す形態の信号を受信するステップ、前記基地局から伝送されたMTCアップリンクグラントを受信するステップ、および無線ソース制御RRC接続の確立なしに、前記MTCアップリンクグラントソース領域でMTCデータを送信するステップを含む方法。セル内の複数のMTCデバイスは共通の無線ベアラ設定をシェアする請求項23に記載の方法。マシン型通信用に強化されたランダムアクセスチャネルRACHの設計を提供する。適応RACHの操作が3GPP無線通信のマシン型通信MTCに提供される。適応RACHの操作は、コンテキスト情報に基づいてRACH衝突確率を減少し、ネットワークの過負荷を制御し、システムパフォーマンスを向上させる。コンテキスト情報は、デバイス関連の情報およびネットワーク関連の情報を含む。デバイス関連の情報は、デバイスタイプおよびサービスまたはアプリケーションタイプを含む。ネットワーク関連の情報は、ネットワーク負荷情報および歴史的統計情報を含む。コンテキスト情報に基づき、MTCデバイスは、異なるレベルで適応RACHの操作を用いることによって、さまざまなネットワークアクセスおよびRACHパラメータを調整する。例えば、アプリケーションレベルおよびネットワークレベルでは、MTCデバイスは、RACHアクセス用にそのアクセス確率および/またはRACHのバックオフ時間を調整する。無線アクセスネットワークRANレベルでは、MTCデバイスは、そのアクセス確率および/またはRACHのバックオフ時間を調整するか、または調整されたRACH無線リソースおよびプリアンブルを用いてRACHのプリアンブルを送信する。第1の実施形態では、MTCデバイスは、APP、NAS、および/またはRANレベルを含む異なるレベルでRACHの操作前のアクセス確率を調整する。H2HアクセスクラスACに比べ、M2MアクセスクラスACは、異なるアクセス確率、排除パラメータ、および再試行タイマーパラメータを用いることができる。アプリケーションレベルのアクセス分散では、排除は、サービスタイプに基づいてアクセスを優先することで行われる異なるアプリケーションのQoS要求および/または遅延許容レベルに基づく。NASレベルのアクセス分散では、排除は、アクセス制限によって行われる例えばサービスタイプ、MTCサーバー、およびデバイスIDに基づいてアクセスを優先する。RANレベルのアクセス分散では、排除は、異なるACクラス用に異なる排除要因を用いることで行われる。第2の実施形態では、MTCデバイスは、APP、NAS、および/またはRANレベルを含む異なるレベルでRACHの操作中にそのバックオフ時間を調整する。RACHバックオフ遅延は、第1のRACHプリアンブルの送信前でもRACHプリアンブル衝突の後でも用いられることができる。第1のRACHの前の初期のRACHアクセス分散は、高いレベルのRACHコンテンションを防ぎ、よって、アプリケーションまたはネットワークレベルで適用される。一旦、RACH衝突が認められると、特定のバックオフタイマーがRACH手順中、各MTCデバイスに用いられることができる。異なるバックオフ時間は、異なる遅延許容性M2Mシナリオに用いられることができる。第3の実施形態では、MTCデバイスは、RANレベルで調整されたRACHリソースを有するRACHプリアンブルを送信する。ネットワークは、M2M-onlyデバイス、H2H-onlyデバイス、およびM2MとH2Hデバイスの両方によって用いられるリソース用にRACHリソースの割り当てを適応して調整する。アプリケーション要求および優先アクセスクラスに基づいてデバイスは、専用のRACHリソースまたはシェアのRACHリソースのいずれかの使用を選択する。また、RACHリソースの割り当ては、負荷情報例えば、M2Mトラフィック負荷および/またはH2Hトラフィック負荷、RACH衝突確率、および他のコンテキスト情報に基づいて更に調整される。第4の実施形態では、RACHを用いない解決が用いられ、低移動性または移動性のないMTCデバイス用にMTCデータを送信する。MTCの要求が経時的に、かつ異なるMTCデバイス全体で通常、固定されるため、再構成されたULリソースが用いられて、MTCデータを送信する。MTCデータは、RRCの確立なしに、ULリソースに伝送され、RRCシグナリングオーバーヘッドを減少する。1つの実施形態では、eNBは、ブロードキャスティングまたは専用の伝送を通して、MTCデバイスにMTC構成を伝送し、次いで1つまたは複数のMTCグラントを伝送する。MTCデバイスは、グラントされたリソースを用いてMTCデータを送信する。RACHを用いない解決は、どのコンテンションベースのアクセス機構も必要とせず、多くのMTCサービス/アプリケーションに適合する。他の実施形態及びそれらの利点が以下に詳細に説明される。この概要は、説明を限定するものではない。発明の実施の形態を説明する。その例が添付の図面に示されている。図3は、本発明の実施形態に基づくマシン型通信MTCをサポートする3GPPネットワーク300を表している。3GPPネットワーク300は、複数のMTCデバイス例えば、図3に示されたMTCデバイス314と通信することで各種のMTCサービスをMTCユーザー312に提供するMTCサーバー311を含む。図3の例では、MTCサーバー311、MTCユーザー312、およびパケットデータネットワークゲートウェイPDNGW313は、コアネットワーク310の一部に属する。MTCデバイス314およびそのサービング基地局eNB315は、無線アクセスネットワークRAN320の一部に属する。MTCサーバー311は、PDNGW313、サービングGW316、およびeNB315によってMTCデバイス314と通信する。また、移動管理ノードMME317は、eNB315、サービングGW316、およびPDNGW313と通信し、3GPPネットワーク300の無線アクセスデバイスの移動管理をする。注意するのは、タームMTCは、人間同士H2Hの通信と比べて、機械間M2Mの通信とも呼ばれ、MTCデバイスは、H2Hと比べてM2Mデバイスとも呼ばれている。図3の例では、MTCサーバー311は、確立されたアプリケーションプログラミングインタフェースAPI340によってアプリケーションAPPプロトコル層で各種のMTCサービス/アプリケーションをMTCユーザー312に提供する。典型的なMTCアプリケーションは、セキュリティ例えば、監視システム、追跡例えば、走行距離連動型料金収受、支払い例えば、自動販売機およびゲーム機、健康例えば、健康推進システム、遠隔保守/制御、計量例えば、スマートグリッド、および消費者向けデバイス例えば、電子書籍を含む。エンドツーエンドのMTCサービスの提供のために、MTCサーバー311は、3GPPネットワークの複数のMTCデバイスと通信する。各MTCデバイス例えば、MTCデバイス314は、各種のプロトコル層モジュールを含んで、エンドツーエンドのMTCアプリケーションおよびデータ接続をサポートする。アプリケーションレベルでは、APPモジュール331は、APPプロトコル層例えば、点線341によって表されているでMTCサーバー311と通信し、エンドツーエンドの制御/データを提供する。ネットワークレベルでは、NASモジュール332は、非アクセス層non-accessstratum;NASプロトコル層例えば、点線342によって表されているでMME317と通信し、移動管理および他の発信signaling機能をサポートする。無線アクセスネットワークRANレベルでは、RRCモジュール333は、システム情報のブロードキャスト、RRC接続制御、ページング、無線構成制御、QoS制御などを管理する無線リソース制御RRCプロトコル層でeNB315と通信する例えば、点線343によって表されている。3GPPシステムでは、ランダムアクセスチャネルRACHが携帯電話または他の無線アクセス端末、例えばコンテンションベースのアップリンク伝送のMTCまたはM2Mデバイスに用いられる。RACHは、無線アクセス端末で用いられる共有アップリンクチャンネルであり、アクセスをリクエストして、アップリンクチャネルの所有権ownershipを取得し、RACH手順によってそれらのサービング基地局との伝送を初期化する。MTCサーバーがネットワークオペレータドメイン内に必ずしもあるわけではなく、且つエンドツーエンドのMTCサービスがMTCサーバーと関連するわけではないため、MTCトラフィックは、ネットワーク/コアネットワークによって制御されない可能性がある。よって、非常に短い時間内に大量のM2Mデバイス例えば、セルのUE、またはeNB、またはMMEの数において設計寸法よりかなり大きいが無線サービスにアクセスしたい場合、MTCデバイスからそれらのサービング基地局に伝送された大量のRACHのプリアンブルは、高いRACHの衝突確率を招く可能性がある。また、コアネットワークがダウンした時、MTCデバイス自身のサービングネットワークが失敗した時、多くのMTCデバイスは、ローミング状態にあり、全てローカル競合ネットワークに移動し、まだ失敗していないネットワークで潜在的に過負荷を発生させる可能性がある。1つの実施態様として、従来のRACH手順は、コンテキスト情報に基づいて用いられ、RACHの衝突確率を減少し、ネットワークの過負荷を制御し、システムパフォーマンスを向上させる。コンテキスト情報は、デバイス関連の情報およびネットワーク関連の情報を含む。デバイス関連の情報は、デバイスタイプ例えばM2MデバイスまたはH2Hデバイスおよびサービスまたはアプリケーションタイプ例えば、セキュリティ、追跡、支払い、健康、遠隔保守/制御、計量、および消費者向けデバイスを含む。ネットワーク関連の情報は、負荷情報および歴史的統計情報を含む。得られたコンテキスト情報例えば、太い点線350で表されたMTCサーバー311からMTCサーバー314、または細い点線351で表されたMMEデバイス317からMTCデバイス314に転送されたコンテキスト情報に基づき、MTCデバイス314は、異なる層で適応RACHの操作を用いることによって、さまざまなネットワークアクセスおよびRACHパラメータを調整することができる。例えば、APP層およびNAS層では、MTCデバイス314は、適応RACHの操作用にそのアクセス確率またはRACHのバックオフ時間を調整する。一方、RRC層では、MTCデバイス314は、そのアクセス確率またはRACHのバックオフ時間を調整するか、または適応RACHの操作用に調整されたRACHリソースを用いたRACHのプリアンブルを送信する。過負荷表示などのコンテキスト情報混雑したネットワークエンティティ、例えばAPN、またはMTCサーバーなどは、MME317からeNB315に伝送されることができる。情報に基づいて、eNB315は、MTCデバイス314からの特定の接続リクエストに応じるかどうかを決める。図4は、1つの新しい実施態様に基づく適応ランダムアクセスチャネルRACHの操作を表している。図4の例では、MTCデバイス410は、eNB420によってMTCサーバー430と通信する。RACHを開始する前に、MTCデバイス410は、まず適応RACHの操作用にコンテキスト情報を得る。コンテキスト情報は、MTCデバイス自体によって得られるか、またはネットワークを介してMTCサーバーから転送されることができる。デバイス関連のコンテキスト情報では、MTCデバイスは、通常それ自体のデバイス情報から得る。ネットワーク関連のコンテキスト情報では、MTCデバイスにそれらの情報を得るいくつかのいくつかの方式schemeがある。第1の方式では、MTCデバイスは、収集または推定によってネットワーク関連の情報の一部を得ることができる。例えば、MTCデバイス410は、RACHの衝突確率およびアプリケーションのトラフィック特性などの以前の統計に基づいて歴史的統計を収集し、ネットワーク負荷情報を推定する。第2の方式では、ネットワークまたはアプリケーションは、NAS、Sl-AP、またはAPPレベルの信号signalingによってコンテキスト情報を転送する。例えば、ネットワークは、システム情報ブロックSIBによってコンテキスト情報を通知する例えば、ステップ441によって表されたように、コンテキスト情報は、eNB420からMTCデバイス410に転送される。第3の方式では、コンテキスト情報は、ページングチャネルPCH上のページングメッセージ例えば、ステップ442によって表されたように、MTCサーバー430からMTCデバイス410へのページングメッセージによって転送される。例えばページングメッセージは、状態パラメータを含みまたは特定のタイプのページングコードまたはページングIDを用いる、現在の負荷状態例えば高/中/低の負荷レベルを示す。ページングチャネルは、ページングされたIDまたはページングされたノードのグループも通知し、RACHを伝送するための規則を明確にすることができる例えば、ページングメッセージへの付加排除確率appendbarringprobability、遅延時間値、または他の関連のパラメータ。デバイス始動のRACH伝送例えばプッシュ方法では、MTCデバイス410は、RACHを開始する前に、PCHをチェックし、コンテキスト情報を得る。ネットワーク始動のRACH伝送例えばプル方法では、MTCデバイス410は、PCHを受けて、ページングID、RACHアクセスポリシー、またはコンテキスト情報を識別するページングメッセージを得る。コンテキスト情報を得た後、MTCデバイス410は、適応RACHの操作を用いてネットワークへのアクセスを取得し、MTCサーバー430と通信する。3つの選択が可能である。第1の選択では、MTCデバイス410は、APP、NAS、および/またはRANレベルを含む異なるレベルでRACHの操作の前にそのアクセスの確率を調整するステップ450。第2の選択では、MTCデバイス410は、APP、NAS、および/またはRANレベルを含む異なるレベルでRACHの操作中にそのバックオフ時間を調整するステップ460。第3の選択では、MTCデバイス410は、RANレベルで調整されたRACHリソースを有するRACHプリアンブルを送信するステップ470。これらの選択では、RACHの操作は、デバイスタイプ、サービス/アプリケーションタイプ、負荷のレベル、および/または歴史的統計を含むコンテキスト情報に基づいて適応される。3つの適応RACHの選択のそれぞれが付加の詳細とともに以下に述べられる。図5は、無線ネットワーク500のアクセス確率を調整する、適応RACHの操作の第1の選択を表している。無線ネットワーク500は、MTCデバイス510およびeNB520を含む。MTCデバイス510がそのサービングeNB520とRACH手順を開始した後、MTCデバイス510は、アクセス排除を行うことでそのアクセス確率を調整する。H2HアクセスクラスACに比べ、M2MアクセスクラスACは、異なるアクセス確率、排除パラメータ、および再試行タイマーパラメータを用いることができる。これらの手順は、アプリケーションレベル、NASレベル、またはRANレベル例えば、RACHアクセスレベルのアクセス分散で実施されることができる。アプリケーションレベルのアクセス分散では、排除は、サービスタイプに基づいてアクセスを優先することで行われる。例えば、異なるアクセス確率は、異なるアプリケーションのQoS要求および/または遅延許容レベルに基づく。NASレベルのアクセス分散では、排除は、アクセス制限、例えばサービスタイプ、MTCサーバー、およびデバイスID例えば、新しいMTCID、国際移動体装置識別番号IMEI、国際移動体加入者識別番号IMSIなどに基づいてアクセスを優先することで行われる。RANレベルのアクセス分散では、排除は、アクセスクラス排除機構の異なるac-BarringFactorを用いることで行われる。例えば、異なる排除要因および再試行タイマーがMTCデバイスに用いられる。また、新しいACクラスがM2Mに定義されることができ、M2MACクラス排除は、RACHレベル、コアネットワーク/アプリケーションレベル、または両方で実施されることができる。ステップ531のアクセス排除の完了後、次いでMTCデバイス510がeNB520とRACH手順を開始する。ステップ541では、MTCデバイス510は、RAプリアンブルをeNB520に伝送する。ステップ542では、eNBは、RA応答RARをMTCデバイス510に送信し返す。RAプリアンブルがうまくデコードされた時、RARは、MTCデバイス510に用いる後続のアップリンク伝送のアップリンクグラントを含む。ステップ543では、MTCデバイス510は、承認されたgrantedアップリンクリソースによって、RRC接続リクエスト例えばMSG3をeNB520に伝送する。最後に、ステップ544では、eNB520は、RRCRACHコンテンション解決例えばMSG4をMTCデバイス510に送信し返し、MTCデバイス510とRRC接続を確立し、RACH手順を完了する。異なるプロトコル層で実施される各種のアクセス分散技術を用いてアクセス確率を調整することで、大量のMTCデバイスのアクセス確率は、好ましく優先されて分散され、RACHの衝突確率を減少する。図6は、無線ネットワーク600のバックオフ時間を調整する、適応RACHの操作の第2の選択を表している。無線ネットワークは、MTCデバイス610およびeNB620を含む。適応RACHの操作の第2の選択では、RACHのバックオフ時間は、コンテキスト情報に基づいて適応して調整される。RACHバックオフ遅延は、アプリケーションレベル、コアネットワークレベル例えばNAS層、またはRANレベル例えばRACHアクセスレベルに実施されることができる。また、RACHバックオフ遅延は、第1のRACHプリアンブルの送信前でもRACHプリアンブル衝突の後でも用いられることができる。第1のRACHの前の初期のRACHアクセス分散は、高いレベルのRACHコンテンションを防ぐことができるので、アプリケーションまたはネットワークレベルに適している。一旦、RACH衝突が認められると、特定のバックオフタイマーがRACH手順中、各MTCデバイスに用いられることができる。図6に示されるように、MTCデバイス610は、第1のRACHプリアンブルの送信前にステップ631の初期のアクセス分散を実行する。更に具体的に言えば、MTCデバイス610は、RACHプリアンブルをeNB620に送信する前に、第1のバックオフ時間1を用いる。第1のバックオフ時間は、各種の方式によって決められることができる。1つの実施形態では、MTCデバイス610は、第1のバックオフ時間の値用に内部built-in分散を有する。例えば、各MTCデバイスは、所定の範囲からバックオフ時間1用の値をランダムに選択する。第2の実施形態では、第1のバックオフ時間は、デバイス関連のコンテキスト情報に基づいてアプリケーションレベルまたはネットワークレベルで割り当てられる。例えば、より短いバックオフ時間は、比較的緊急の高いアプリケーション、またはより低い遅延許容性を有するアプリケーションに割り当てられる。一方、より長いバックオフ時間は、より長い遅延許容性を有するアプリケーションに割り当てられる。異なるバックオフ時間は、サービス/アプリケーションタイプ、MTCサーバー、MTCデバイスのデバイスIDに基づいて割り当てられることもできる。第3の実施形態では、MTCデバイス610は、第1のRACHが新しい手順を用いる前にバックオフを行い、eNBは、異なるランダムアクセス無線ネットワーク一時識別子RA-RNTIを通じたブロードキャスト、リザーブビット、またはRRCメッセージによって、第1のバックオフ時間を示す。バックオフ時間1が過ぎた後、ステップ632では、MTC610は、RACHプリアンブルをeNB620に送信する。多くのMTCデバイスが同じRACHリソース例えば、RACHリソースブロックおよびRACHプリアンブルをシェアするため、eNB620は、RACH衝突により、RACHプリアンブルをデコードすることができない可能性がある。RACH衝突が発生した時、第2のバックオフ時間は、RACHプリアンブルを再送する前、MTC610によって用いられる。第1のバックオフ時間と同様に、第2のバックオフ時間は、コンテキスト情報に基づいてアプリケーションレベル、ネットワークレベル、またはRANレベルで割り当てられる。図6の例では、eNB620は、RACH衝突を検出した後、ステップ633で第2のバックオフ時間を決める。しかしながら、eNB620では、MTCデバイス610のコンテキスト情報を知らない可能性がある。1つの例では、MTCデバイス610は、MTCデバイスタイプ専用であるRACHプリアンブルを用いる。もう1つの例では、MTCデバイス610は、MTCデバイスタイプ専用であるRACHリソース例えば、プリアンブル、リソースブロック、およびサブフレームを用いる。専用のRACHプリアンブルまたはRACHリソースに基づいて、eNB620は、MTCデバイス610のデバイスタイプを識別することができる。一旦、eNB620が異なるデバイスタイプを判別すると、eNB620は、異なるRA-RNTIのRARによって異なるバックオフ時間を割り当てる。1つの実施形態では、図6のブロック651に表されるように、第2のバックオフ時間2は、E/T/R/R/BIメディアアクセス制御MACサブヘッダの第1のオクテットに含まれるバックオフインジケータBIを用いて割り当てられる。ステップ633では、第2のバックオフ時間を決めた後、eNB620は、ステップ634で、バックオフインジケータを有するRARをMTCデバイス610に伝送する。MTCデバイスは、ステップ641でRAプリアンブルを再送する前に第2のバックオフ時間を用いる。RAプリアンブルをうまくデコーディングした後、eNB620は、ステップ642でアップリンクグラントを有するRARをMTCデバイス610に送信し返す。ステップ643では、MTCデバイス610は、承認されたアップリンクリソースによって、RRC接続リクエスト例えばMSG3をeNB620に伝送する。最後に、ステップ644では、eNB620は、RRC接続リクエスト例えばMSG4をMTCデバイス610に送信し返し、RRC接続を確立し、RACH手順を完了する。異なるバックオフ時間は、異なる遅延許容性M2Mシナリオに用いられることができる。例えば、アプリケーションが高い遅延許容性を有する場合、デバイスは、RACHアクセスのために次の不連続受信DRXのアクティブ期間まで延期することができる。一方、アプリケーションがKタイムスロットのスケールで遅延を許容できる場合、デバイスは、次のKタイムスロットにRACHアクセスを延期する可能性がある。また、異なるバックオフ時間が、ネットワーク関連のコンテキスト情報およびアクセスクラスのタイプに基づいて用いられてもよい。例えば、負荷が高い時、クラス1のデバイス例えば、高い優先度は、[5、10]サブフレーム内にRACHアクセスを延期し、クラス2のデバイス例えば、低い優先度は、[20、30]サブフレーム内にRACHアクセスを延期する。一方、負荷が低い時、クラス1のデバイスは、そのRACHアクセスを延期せず、クラス2のデバイスは、[0、10]サブフレーム内にRACHアクセスを延期する。図7は、無線ネットワーク700のRACHリソースの割り当てを調整する、適応RACHの操作の第3の選択を表している。無線ネットワーク700は、H2Hデバイス710、M2Mデバイス720、およびH2Hデバイス710とM2Mデバイス720の両方をサービングするeNB730を含む。ステップ731では、eNB730は、H2Hデバイス710およびM2Mデバイス720にRACHリソースの割り当てをブロードキャストする。RACHリソースの用語は、RACH無線リソースおよびRACHプリアンブルの両方を指している。第1の実施形態では、専用のRACH無線リソース例えば無線リソースブロックおよびサブフレームは、MTC-onlyデバイスに割り当てられる。例えば、新しいMTC-RACHパラメータは、SIB2に定義される。もう1つの実施形態では、後方交換性をサポートするために、新しいMTC-RACHパラメータは、新しいSIB例えばSIBXに定義されることができる。第2の実施形態では、専用のRACHプリアンブルは、MTC-onlyデバイスに割り当てられる。ネットワークは、M2M-onlyデバイス、H2H-onlyデバイス、およびM2MとH2Hデバイスの両方によって用いられるリソース用にRACHリソースの割り当てを適応して調整する。図7のブロック750によって示されるように、例えば、全てのRACHリソースは、3つの部分に分けられる。具体的には、RACH伝送のタイムスロット、周波数トーンfrequencytone、およびプリアンブルは、3つの部分に分けられる。第1のRACHリソース部分1は、M2M-onlyRACHアクセス用に割り当てられ、第2のRACHリソース部分2は、H2H-onlyRACHアクセス用に割り当てられ、第3のRACHリソース部分3は、M2MとH2HRACHアクセスによってシェアされる。アプリケーション要求および優先アクセスクラスに基づいてデバイスは、専用のRACHリソースまたはシェアのRACHリソースのいずれかの使用を選択する。また、RACHリソースの割り当ては、負荷情報、衝突確率、および他のコンテキスト情報に基づいて更に調整される。例えば、ネットワークは、H2Hアクセス用に、全てのRACH伝送の機会を割り当て、M2M-onlyアクセス用に、全てのRACH伝送の機会のサブセットを割り当てることができる。割り当ては、M2Mトラフィック負荷および/またはH2Hトラフィック負荷に基づいて適応して構成されることができる。割り当ては、衝突および伝送係数に基づいて適応して構成されることもできる。適応リソース割り当ての1つの実施形態では、eNBは、第1の期間にM2MおよびH2HでシェアされたRACHリソースを割り当てる。デバイスの数が小さいほど、深刻な衝突が観測されず、更なる最適化を必要としなくなる。しかしながら、第2の期間では、eNBは、高いRACH衝突頻度を観測する。よって、eNBは、正常な着信コールphonecallのユーザエクスペリエンスを補償するために、H2Hトラフィック専用のRACHリソースの一部を割り当てる。ほとんどのM2Mトラフィックが、通常、より遅延許容性をもっているため、eNBは、RACHリソースの残りをM2Mトラフィックに割り当てる。M2Mデバイスの数が割り当てられたRACHリソースのサポート可能な数より高い場合、RAN/NASレベルトラフィック分散などによって、M2Mトラフィックを分散させる一層の改善が必要となる。eNBは、RACHリソースを動的に調整することができる。例えば、着信コールがより少ない時、eNBは、より多くのRACHリソースをM2Mトラフィックに割り当てることができる。図8は、無線ネットワーク800のマシン型通信を最適化するRACHRACH-lessを用いない解決方法を表している。無線通信800は、MTCデバイス810およびeNB820を含む。タイミングアドバンスTAおよび第1のULグラントを得るためにRACHがコンテンションベースのアップリンク伝送に正常に用いられる時、eNB用のRACHアクセスのコストが高くなる。これは、特に、M2Mデバイスの数が非常に大きい時に該当し、多くのMTCアプリケーションの典型的な特徴である。しかしながら、低移動性または移動性のないMTCデバイスでは、MTCデバイスが同じセルに依頼してMTCデータを送信することができるため、TAは、常に固定される。よって、MTCの要求が経時的に、かつ異なるMTCデバイス全体で通常、固定されるため、これらのMTCデバイスが再構成されたULリソースを用いてデータを送信することは可能である。ULリソースは、シェアまたは専用とすることができる。RRCシグナリングオーバーヘッドを減少するために、RRCの確立なしに、MTCデータをULリソースに伝送することが可能である。セル内のMTCデバイスが共通の無線ベアラ設定configurationをシェアすることも可能である。RACHが6つのRBを有する時、小さいMTCデータ伝送は1つまたは2つのRBのみ必要である。図8の例では、ステップ830にて、eNB820は、ブロードキャスティングまたは専用の伝送を通して、MTC構成をMTCデバイス810に伝送する。ステップ840およびステップ850では、eNB820は、1つまたは複数のMTCグラントを伝送する。最後に、ステップ860では、MTCデバイス810は、グラントされたリソースを用いてMTCデータを送信する。このようなRACHを用いない解決は、どのコンテンションベースのアクセス機構も必要とせず、多くのMTCサービス/アプリケーションに適合する。図9は、1つの新しい態様に基づく最適化されたマシン型通信MTC用の適応RACHの操作の方法のフローチャートである。ステップ901では、MTCデバイスは、MTCサーバーからコンテキスト情報を受信する。コンテキスト情報は、デバイス関連の情報およびネットワーク関連の情報を含む。デバイス関連の情報は、デバイスタイプおよびサービスまたはアプリケーションタイプを含む。ネットワーク関連の情報は、ネットワーク負荷情報および歴史的統計情報を含む。コンテキスト情報に基づき、MTCデバイスは、適応RACHの操作を用いることによって、さまざまなネットワークアクセスおよびRACHパラメータを調整する。第1の適応RACHの操作では、MTCデバイスは、APP、NAS、および/またはRANレベルを含む異なるレベルのRACHの前のアクセス確率を調整するステップ902。第2の適応RACHの操作では、MTCデバイスは、APP、NAS、および/またはRANレベルを含む異なるレベルのRACHの操作中のRACHバックオフ時間を調整するステップ903。第3の適応RACHの操作では、MTCデバイスは、RANレベルで調整されたRACHリソースを用いたRAプリアンブルを伝送するステップ904。3つの選択は、3つの選択は共存して組み合わさって用いられることができるステップ905。最後に、ステップ906では、RACHを用いない解決は、最適化されたマシン型通信に用いられる。本発明は、説明のためにある特定の実施の形態に関連して述べられているが本発明はこれを制限するものではない。よって、種々の変更、改変、及び上述の実施の形態の種々の特徴の組み合わせがこの請求項に記載したような本発明の範囲内で、行い得る。