(57)【要約】【課題】上位ネットワークにおける処理の輻輳を抑制できるようにする。【解決手段】無線デバイスは、特定の信号系列を含む接続要求を無線基地局へ送信する。無線基地局は、前記信号系列の検出に応じて、無線デバイスとの間の前記接続要求に応じた接続処理が完了する前に、無線デバイスのためのアタッチ要求を上位ネットワークノードへ無線デバイスの代理で送信する。【選択図】図１３
2016122887.tif 000002
【特許請求の範囲】
【請求項１】
無線アクセスネットワークにおける無線エリアを形成する無線基地局であって、
前記無線アクセスネットワークへの無線デバイスの登録を要求するアタッチ要求を記憶する記憶部と、
前記無線エリアに位置する無線デバイスから特定の信号系列を含む接続要求を受信する受信部と、
前記信号系列の検出に応じて、前記信号系列の検出後に予定されている前記無線デバイスからのアタッチ要求を受信する前に、前記記憶部に記憶されたアタッチ要求を上位ネットワークノードへ送信する処理部と、を備えた、
無線基地局。
【請求項２】
前記記憶部は、
前記信号系列を割り当てられた前記無線デバイスから過去に受信した前記上位ネットワークノード宛のアタッチ要求を記憶し、
前記処理部は、
前記信号系列の受信検出に応じて、前記記憶部に記憶されたアタッチ要求を読み出して前記上位ネットワークノードへ送信する、請求項１に記載の無線基地局。
【請求項３】
前記信号系列は、前記無線デバイスが前記無線基地局との間のランダムアクセス手順で用いるランダムアクセスプリアンブルであり、
前記ランダムアクセスプリアンブルには、前記無線デバイスがＭＴＣ（Machine-Type Communication）を行なうＭＴＣデバイスであることを示すパターンが割り当てられ、
前記処理部による前記アタッチ要求の読み出し及び送信は、前記パターンのランダムアクセスプリアンブルの検出に応じて実施される、請求項２に記載の無線基地局。
【請求項４】
前記処理部は、
前記ＭＴＣデバイスに割り当てる、前記ランダムアクセスプリアンブルのパターンを示す情報を、前記無線エリアに報知する、請求項３に記載の無線基地局。
【請求項５】
前記無線エリアに、複数の前記ＭＴＣデバイスが位置しており、
前記処理部は、
前記複数のＭＴＣデバイスから受信したアタッチ要求の宛先が同一の上位ネットワークノードであることを検出すると、前記複数のＭＴＣデバイスに同じランダムアクセスプリアンブルを割り当ててグループ管理する、請求項３又は４に記載の無線基地局。
【請求項６】
無線アクセスネットワークにおける無線基地局が形成する無線エリアにおいて前記無線基地局に接続する無線デバイスであって、
前記無線基地局へ接続要求を送信する送信部と、
前記接続要求に、特定の信号系列を設定する処理部と、を備え、
前記信号系列は、前記無線アクセスネットワークへの前記無線デバイスの登録を要求するアタッチ要求を記憶部に記憶した前記無線基地局が、前記信号系列の検出に応じて、前記信号系列の検出後に予定されている前記無線デバイスからのアタッチ要求を受信する前に、前記記憶部に記憶されたアタッチ要求を上位ネットワークノードへ送信することを可能にする
を備えた、無線デバイス。
【請求項７】
前記無線デバイスは、ＭＴＣ（Machine-Type Communication）を行なうＭＴＣデバイスであり、
前記信号系列は、前記無線デバイスが前記無線基地局との間のランダムアクセス手順で用いるランダムアクセスプリアンブルであり、
前記処理部は、
前記無線デバイスが前記ＭＴＣデバイスであることを示すパターンのランダムアクセスプリアンブルを前記特定の信号系列として設定する、請求項６に記載の無線デバイス。
【請求項８】
前記処理部は、
前記無線基地局から報知される、前記無線デバイスが前記ＭＴＣデバイスであることを示す前記ランダムアクセスプリアンブルのパターン情報を受信する、請求項７に記載の無線デバイス。
【請求項９】
請求項１〜５のいずれか１項に記載の無線基地局と、
請求項６〜８のいずれか１項に記載の無線デバイスと、
を備えた、無線通信システム。
【請求項１０】
無線アクセスネットワークにおける無線基地局が形成する無線エリアに位置する無線デバイスが、特定の信号系列を含む接続要求を前記無線基地局へ送信し、
前記無線基地局は、
前記無線アクセスネットワークへの前記無線デバイスの登録を要求するアタッチ要求を記憶部に記憶し、
前記信号系列の検出に応じて、前記信号系列の検出後に予定されている前記無線デバイスからのアタッチ要求を受信する前に、前記記憶部に記憶されたアタッチ要求を上位ネットワークノードへ送信する、
無線通信制御方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、無線基地局、無線デバイス、無線通信システム、及び、無線通信制御方法に関する。
【背景技術】
【０００２】
無線通信技術の１つとして、Ｍ２Ｍ（Machine to Machine）と呼ばれる技術がある。Ｍ２Ｍ技術とは、ＰＣ（Personal Computer）等の情報機器に限らず、自動車や家電、センサ等の「物」（又は「機械」）が自律的にネットワークに接続して通信する機能を有し、互いに人を介さずに情報交換を行ない、自動的にお互いの制御が可能な技術である。
【０００３】
通信機器の小型化により、様々な「物」や「機械」（「デバイス」と総称してよい。）に通信機器を搭載できるようになったことや、ネットワークインフラの発達により無線通信エリアが拡大されたこと等により、Ｍ２Ｍ技術が普及しつつある。Ｍ２Ｍ技術による通信サービスは、「ＭＴＣ（Machine-Type Communication）サービス」と称されることがある。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】特表２００９−５２６４９１号公報
【特許文献２】特開２００５−１２３３５号公報
【特許文献３】特表２００２−５３８７４４号公報
【特許文献４】特表２０１０−５４１４０７号公報
【特許文献５】特表２０１３−５３２９３０号公報
【特許文献６】特開２００９−７７３６８号公報
【特許文献７】国際公開第２０１３／０４６６２０号
【非特許文献】
【０００５】
【非特許文献１】「ＬＴＥリリース１２−ネットワーク化社会に向かって次のステップを踏み出す」、エリクソンホワイトペーパー２８４  ２３−３１８９  Ｕｊｐ、２０１３年１月、エリクソンジャパン
【非特許文献２】「Ｍ２Ｍ通信コアネットワーク基盤と輻輳対策技術」、ＮＴＴ  ＤＯＣＯＭＯテクニカル・ジャーナル  Ｖｏｌ．２１  Ｎｏ．２、２０１３年７月、ＮＴＴ  ＤＯＣＯＭＯ
【非特許文献３】３ＧＰＰ  ＴＳ  ３６．２１１  Ｔｅｃｈｎｉｃａｌ  Ｓｐｅｃｉｆｉｃａｔｉｏｎ  Ｇｒｏｕｐ  Ｒａｄｉｏ  Ａｃｃｅｓｓ  Ｎｅｔｗｏｒｋ；Ｅｖｏｌｖｅｄ  Ｕｎｉｖｅｒｓａｌ  Ｔｅｒｒｅｓｔｒｉａｌ  Ｒａｄｉｏ  Ａｃｃｅｓｓ（Ｅ−ＵＴＲＡ）；Ｐｈｙｓｉｃａｌ  ｃｈａｎｎｅｌｓ  ａｎｄ  ｍｏｄｕｌａｔｉｏｎ
【発明の概要】
【発明が解決しようとする課題】
【０００６】
ＭＴＣサービスをサポートする無線デバイス（「ＭＴＣデバイス」と称してよい。）が、或る無線基地局の無線エリアに多数設置されることがある。
【０００７】
多数のＭＴＣデバイスが無線基地局を介して上位ネットワークとの通信を一斉に開始しようとすると、上位ネットワークにおいて通信（あるいは処理）の輻輳が生じるおそれがある。
【０００８】
１つの側面では、本発明の目的の１つは、上位ネットワークにおける処理の輻輳を抑制できるようにすることにある。
【課題を解決するための手段】
【０００９】
１つの側面において、無線アクセスネットワークにおける無線エリアを形成する無線基地局は、記憶部と、受信部と、処理部と、を備えてよい。記憶部は、前記無線アクセスネットワークへの無線デバイスの登録を要求するアタッチ要求を記憶してよい。受信部は、前記無線エリアに位置する無線デバイスから特定の信号系列を含む接続要求を受信してよい。処理部は、前記信号系列の検出に応じて、前記信号系列の検出後に予定されている前記無線デバイスからの前記アタッチ要求を受信する前に、前記記憶部に記憶されたアタッチ要求を上位ネットワークノードへ送信してよい。
【００１０】
また、１つの側面において、無線デバイスは、無線アクセスネットワークにおける無線基地局が形成する無線エリアにおいて前記無線基地局に接続する。無線デバイスは、送信部と、処理部と、を備えてよい。送信部は、前記無線基地局へ接続要求を送信してよい。処理部は、前記接続要求に、特定の信号系列を設定してよい。前記信号系列は、前記無線アクセスネットワークへの前記無線デバイスの登録を要求するアタッチ要求を記憶部に記憶した前記無線基地局が、前記信号系列の検出に応じて、前記信号系列の検出後に予定されている前記無線デバイスからのアタッチ要求を受信する前に、前記記憶部に記憶されたアタッチ要求を上位ネットワークノードへ送信することを可能にする信号系列であってよい。
【００１１】
更に、１つの側面において、無線通信システムは、上述した無線基地局と無線デバイスとを備えてよい。
【００１２】
また、１つの側面において、無線通信制御方法は、無線アクセスネットワークにおける無線基地局が形成する無線エリアに位置する無線デバイスが、特定の信号系列を含む接続要求を前記無線基地局へ送信してよい。前記無線基地局は、前記無線アクセスネットワークへの前記無線デバイスの登録を要求するアタッチ要求を記憶部に記憶し、前記信号系列の検出に応じて、前記信号系列の検出後に予定されている前記無線デバイスからのアタッチ要求を受信する前に、前記記憶部に記憶されたアタッチ要求を上位ネットワークノードへ送信してよい。
【発明の効果】
【００１３】
１つの側面として、上位ネットワークにおける処理の輻輳を抑制できる。
【図面の簡単な説明】
【００１４】
【図１】３ＧＰＰ（3rd Generation Partnership Project）にて規定されるＬＴＥ（Long Term Evolution）アーキテクチャの一例を示すブロック図である。
【図２】ＭＴＣサービスを適用したＬＴＥアーキテクチャの一例を示すブロック図である。
【図３】ＭＴＣサービスを適用した無線通信システムの構成例を模式的に示す図である。
【図４】ＬＴＥアーキテクチャにおける通常のＵＥのＲＡＮへのアタッチ処理の一例を示すシーケンス図である。
【図５】ＭＴＣサービスを適用したＬＴＥアーキテクチャでのアタッチ処理の一例を示すシーケンス図である。
【図６】アタッチ処理の詳細例を示すシーケンス図である。
【図７】一実施形態のＭＴＣデバイス識別処理例を示すシーケンス図である。
【図８】物理ランダムアクセスチャネルの構成例を示す図である。
【図９】一実施形態の管理テーブル生成例を示すシーケンス図である。
【図１０】一実施形態の管理テーブル生成例を示すシーケンス図である。
【図１１】一実施形態の管理テーブルの一例を示す図である。
【図１２】図１１に例示する管理テーブルの更新例を示す図である。
【図１３】一実施形態のアタッチ処理例を示すシーケンス図である。
【図１４】一実施形態のアタッチ処理例を示すシーケンス図である。
【図１５】一実施形態の変形例を示すシーケンス図である。
【図１６】一実施形態の変形例を示すシーケンス図である。
【図１７】一実施形態の無線基地局（ｅＮＢ）の構成例を示すブロック図である。
【図１８】一実施形態のＭＴＣデバイスの構成例を示すブロック図である。
【発明を実施するための形態】
【００１５】
以下、図面を参照して本発明の実施の形態を説明する。ただし、以下に説明する実施形態は、あくまでも例示であり、以下に明示しない種々の変形や技術の適用を排除する意図はない。また、以下に説明する各種の例示的態様は、適宜に組み合わせて実施しても構わない。なお、以下の実施形態で用いる図面において、同一符号を付した部分は、特に断らない限り、同一若しくは同様の部分を表す。
【００１６】
図１は、３ＧＰＰにて規定されるＬＴＥアーキテクチャの一例を示すブロック図である。「ＬＴＥアーキテクチャ」は、「無線通信システム」の一例である。
【００１７】
図１に示すＬＴＥアーキテクチャは、例示的に、ＵＥ１０、ｅＮＢ２０（ＲＥ２１及びＢＳ２２）、Ｓ−ＧＷ３０、Ｐ−ＧＷ４０、ＭＭＥ５０、及び、ＨＳＳ６０を備える。
【００１８】
ＵＥ１０は、「User Equipment」の略称であり、例示的に、無線端末である。無線端末は、例えばｅＮＢが提供する無線エリアにおいて当該ｅＮＢと無線通信が可能な通信機器の一例である。
【００１９】
「無線端末」は、「無線デバイス」、「無線装置」、あるいは「端末装置」等と称されてもよい。無線端末１０は、その位置が変化しない固定端末であってもよいし、その位置が変化する移動端末（「移動機」と称してもよい。）であってもよい。非限定的な一例として、無線端末１０は、携帯電話やスマートフォン、タブレット端末等の移動可能なＵＥであってよい。
【００２０】
ｅＮＢ２０は、「enhanced Node B」の略称であり、無線基地局の一例である。ｅＮＢ２０は、無線機能部と、その他の基本機能部と、が一体的に備えられていてもよいし、図１に例示するように互いに分離されていてもよい。
【００２１】
無線機能部は、ＲＥ（Radio Equipment）２１と称してよく、基本機能部は、ＢＳ（Base Station）２２と称してよい。ＲＥ２１は、例示的に、有線インタフェースによってＢＳ２２と通信可能に接続されてよい。有線インタフェースには、光インタフェースの一例であるＣＰＲＩ（Common Public Radio Interface）を適用してよい。
【００２２】
ＲＥ２１は、ＵＥ１０との間の無線インタフェース（「Ｕｂ」と表記されることがある。）を提供する。別言すると、ＲＥ２１は、ＵＥ１０が無線によりＲＥ２１に接続して当該ＲＥ２１との間で無線通信が可能な無線エリアを提供する。無線エリアは、ＢＳ２２によっても提供されてよい。無線エリアがｅＮＢ２０によって形成されることに変わりない。
【００２３】
「無線エリア」は、「セル」、「カバレッジエリア」あるいは「通信エリア」と称してもよい。「セル」は「セクタセル」に分割されてもよい。「セル」には、マクロセルやスモールセルが含まれてよい。
【００２４】
スモールセルは、マクロセルよりも電波到達範囲（カバレッジ）の小さいセルの一例である。スモールセルは、カバレッジエリアに応じて呼称が異なってよい。例えば、スモールセルは、「フェムトセル」、「ピコセル」、「マイクロセル」、「ナノセル」、「メトロセル」、「ホームセル」等と称されてもよい。
【００２５】
ｅＮＢ２０とＵＥ１０との間の無線通信は、「セルラー通信」と称してもよい。セルラー通信には、例示的に、ＬＴＥ（Long Term Evolution）やＬＴＥ−Ａｄｖａｎｃｅｄに準拠した無線通信方式を適用してよい。代替的あるいは複合的に、ＲＥ（又はＢＳ）とＵＥとの間の無線通信には、「Worldwide Interoperability for Microwave Access, (WiMAX)」（登録商標）等の他の方式に準拠した無線通信方式を適用してもよい。
【００２６】
ｅＮＢ２０（例えば、ＢＳ２２）は、例示的に、Ｓ−ＧＷ３０及びＭＭＥ５０と通信可能に接続されてよい。「Ｓ−ＧＷ」は、「Serving Gateway」の略称であり、ＭＭＥは、「Mobility Management Entity」の略称である。ｅＮＢ２０（ＢＳ２２）と、Ｓ−ＧＷ３０及びＭＭＥ５０と、の間は、それぞれ例えば、Ｓ１インタフェースと称されるインタフェースによって通信可能に接続されてよい。
【００２７】
Ｓ−ＧＷ３０は、Ｓ５インタフェースと称されるインタフェースによってＰ−ＧＷ４０と通信可能に接続されてよい。「Ｐ−ＧＷ」は、「Packet Data Network Gateway」の略称である。Ｐ−ＧＷ４０は、インターネットやイントラネット等のパケットデータネットワーク（ＰＤＮ）と通信可能に接続されてよい。
【００２８】
Ｓ−ＧＷ３０及びＰ−ＧＷ４０を介して、ＵＥ１０とＰＤＮとの間でユーザパケットの送受信が可能である。ユーザパケットは、ユーザデータの一例であり、ユーザプレーン信号と称してもよい。
【００２９】
例示的に、Ｓ−ＧＷ３０は、ユーザプレーン信号を処理してよい。制御プレーン信号は、ＭＭＥ５０が処理してよい。Ｓ−ＧＷ３０は、Ｓ１１インタフェースと称されるインタフェースによってＭＭＥ５０と通信可能に接続されてよい。
【００３０】
ＭＭＥ５０は、例示的に、ＵＥ１０の位置情報を管理する。Ｓ−ＧＷ３０は、ＭＭＥ５０で管理されている位置情報を基に、例えば、ＵＥ１０の移動に伴うユーザプレーン信号のパス切り替え等の移動制御を実施してよい。移動制御には、ＵＥ１０のハンドオーバに伴う制御が含まれてよい。
【００３１】
ＨＳＳ６０は、「Home Subscriber Server」の略称であり、例示的に、Ｓ６インタフェースと称されるインタフェースによってＭＭＥ５０と通信可能に接続されてよい。ＨＳＳ６０は、ＵＥ１０（「加入者」と称してもよい。）向けに提供する通信サービスに応じた制御や、加入者データを処理するサーバの一例である。
【００３２】
Ｓ−ＧＷ３０、Ｐ−ＧＷ４０、ＭＭＥ５０、及び、ＨＳＳ６０を含むネットワークは、「コアネットアーク」と称してよい。「コアネットワーク」は、ｅＮＢ２０に対する「上位ネットワーク」に相当すると捉えてよい。したがって、Ｓ−ＧＷ３０、Ｐ−ＧＷ４０、ＭＭＥ５０、及び、ＨＳＳ６０は、「コアネットワーク」のエレメント（ＮＥ）あるいはエンティティに相当すると捉えてよい。
【００３３】
ｅＮＢ２０は、「コアネットワーク」に、有線インタフェースの一例である「Ｓ１インタフェース」によって接続されていると捉えてよい。ｅＮＢ２０は、無線インタフェースによって「コアネットワーク」と通信可能に接続されても構わない。
【００３４】
ｅＮＢ２０とコアネットワークとを含むネットワークは、無線アクセスネットワーク（ＲＡＮ）と称されてもよい。ＲＡＮの一例は、「Evolved Universal Terrestrial Radio Access Network, E-UTRAN」である。
【００３５】
ＲＡＮは、３ＧＰＰが規定するＬＴＥアーキテクチャによれば、大容量かつ小遅延のパケット通信に最適化される。一方、更なるＬＴＥのＲＡＮ技術の展開として、３ＧＰＰでは、ＬＴＥアーキテクチャのＭＴＣ（Machine-Type Communication）サービスに対する機能強化や機能拡張が検討、議論されている。
【００３６】
ＭＴＣサービスは、Ｍ２Ｍ技術に基づく通信サービスの一例である。Ｍ２Ｍ技術を用いたＭＴＣサービスの一例としては、各地に散在する自動販売機やエレベータの遠隔監視サービスや、車両等の移動体に通信機器を搭載して、渋滞情報や駐車場の空き状況等の情報提供をリアルタイムに行なうサービス等が挙げられる。
【００３７】
図２は、ＭＴＣサービスを適用したＬＴＥアーキテクチャの一例を示すブロック図である。なお、図２のアーキテクチャは、例えば３ＧＰＰリリース１２において規定されている。
【００３８】
図２と図１とを比較すると、図２に示すＬＴＥアーキテクチャは、ＵＥ１０に代替あるいは追加してＭＴＣデバイス１１を備え、かつ、コアネットワークにＭＴＣ−ＩＷＦ７０及びＳＣＳ８０が追加されている点が図１のアーキテクチャと異なる。なお、「ＭＴＣデバイス」は、「Ｍ２Ｍデバイス」と称されてもよい。
【００３９】
ＭＴＣデバイス１１は、例示的に、ＲＡＮとの間の無線通信をサポートする無線通信機能を具備し、ＵＥ１０と同様に、ｅＮＢ２０が提供する無線エリアにおいて当該ｅＮＢ２０と無線通信が可能な無線デバイスの一例である。
【００４０】
ただし、ＵＥ１０とは異なって、ＭＴＣデバイス１１による無線通信は、人（ユーザ）による操作が介在しない通信であってよい。例えば、ＭＴＣデバイス１１による無線通信は、ＭＴＣデバイス１１に備えられた、ユーザ操作がなくても自律的な動作が可能なアプリケーション（「プログラム」あるいは「ソフトウェア」と称してもよい。）による通信であってよい。
【００４１】
例えば、ＭＴＣデバイス１１は、無線通信機能を具備したセンサデバイスやメータ（測定器）等であってよい。また、ＭＴＣデバイス１１は、車両や航空機、船舶等の移動体（「乗り物」と称してもよい。）に取り付けられた無線機器であってよい。
【００４２】
車両等の「乗り物」に取り付けられて位置が可変のＭＴＣデバイスは、「移動機」に相当すると捉えてよい。この場合、ＵＥとＭＴＣデバイスとは、「移動機」と総称してよい。
【００４３】
ＭＴＣデバイス１１は、図２中に例示するように、実現するＭＴＣサービスに応じたＭＴＣアプリケーション（「プログラム」あるいは「ソフトウェア」と称してもよい。）１１０を具備してよい。
【００４４】
ＭＴＣアプリケーション１１０の実行に応じて、ＭＴＣデバイス１１は、例えばＭＴＣサービスに応じた情報提供等を無線通信によって実施してよい。ＭＴＣサービスにおける情報提供には、例示的に、ＭＴＣデバイス１１がセンシングあるいは測定した情報等を、ＲＡＮに設置されたＳＣＳ８０宛に送信することが含まれてよい。ＭＴＣサービスに応じた通信は、定期あるいは不定期に実施されてよい。
【００４５】
「ＳＣＳ」は、「Service Capability Server」の略称であり、例えばＭＴＣサービスを提供するサーバである。そのため、ＳＣＳ８０は、ＭＴＣサーバ８０と称してもよい。
【００４６】
ＳＣＳ８０には、例示的に、ＭＴＣデバイス１１のＭＴＣアプリケーション１１０と通信可能なＭＴＣアプリケーションが実装されてよい。当該ＭＴＣアプリケーションによって、ＳＣＳ８０は、ＭＴＣデバイス１１との間のＭＴＣサービスに応じた通信を終端可能である。ＳＣＳ８０は、例示的に、Ｐ−ＧＷ４０及びＭＴＣ−ＩＷＦ７０とそれぞれ通信可能に接続されてよい。
【００４７】
「ＭＴＣ−ＩＷＦ」は、「Machine Type Communication-Inter Working Function」の略称である。ＭＴＣ−ＩＷＦ７０は、例示的に、ＳＣＳ８０とＭＭＥ５０との間の制御プレーン信号の送受信処理が可能である。
【００４８】
ところで、ＭＴＣデバイス１１は、ＵＥ１０とは異なり、大容量で高速なデータ通信は必要なく、比較的、低頻度で少ないデータ量の通信を行なうことが想定される。また、ＭＴＣデバイス１１には、自動販売機やスマートメータのように外部からの給電により長時間の連続的な動作が可能なデバイスに限らず、小型化やコストの観点から、ＵＥ１０と同様に限りある容量のバッテリで動作するデバイスも多く存在すると想定される。
【００４９】
なお、図３に、或るｅＮＢ２０が形成する無線エリア２００に、自動販売機やスマートメータ等のＭＴＣデバイス１１が設置された様子を模式的に示す。各ＭＴＣデバイス１１は、無線エリア２００においてｅＮＢ２０と無線通信することが可能である。
【００５０】
バッテリ駆動によるＭＴＣデバイスの動作時間を延ばす（別言すると、省電力化）という観点から、３ＧＰＰでは、ＭＴＣサービスにおけるデータ送受信間隔の延長（別言すると、データ送受信頻度の低減）等が議論されている。
【００５１】
例えば、ＭＴＣデバイス１１は、通信が必要な時に限って起動（「ウェイクアップ」と称してよい。）して、通信が終了すれば停止あるいはスリープ状態に移行するデバイスであってよい。
【００５２】
また、ＭＴＣデバイス１１の普及に応じて、１台のｅＮＢ２０あたりにアクセスし得るＭＴＣデバイス１１が著しく増加することが想定されるため、ＭＴＣデバイス１１のＲＡＮへの接続手順の見直し等についても３ＧＰＰで議論されている。
【００５３】
現在では人対人（別言すると、ＵＥ同士）の通信が主流であるが、今後は、ＭＴＣデバイス１１に搭載されたＭＴＣアプリケーション１１０が自律的に実行する通信が増えると想定される。
【００５４】
ここで、ＵＥ１０を利用するユーザ（人）であれば、例えば、音声呼の発信に数回失敗すると、発信（別言するとＲＡＮへの接続）を断念すると想定される。しかし、ＭＴＣアプリケーション１１０の場合は、通信を規制する何らかの手段や方法が実施されない限り、ＲＡＮへの接続を試行し続けてしまう。
【００５５】
また、ＭＴＣデバイス１１の数が増えると、例えば、ＭＴＣデバイス１１からＳＣＳ８０宛のステータス報告や、ＭＴＣデバイス１１の移動に伴う移動制御の頻度が大幅に増加するおそれがある。そのため、或る無線エリア２００に多数存在するＭＴＣデバイス１１が、ＲＡＮの共有リソースに対して同時に使用を要求する可能性がある。
【００５６】
例えば、同一無線エリア２００において膨大な数の無線デバイス（ＭＴＣデバイス１１及びＵＥ１０の双方を含んでよい）が一斉に接続処理を開始するケースが生じ得る。また、無線デバイスとｅＮＢ２０との間のランダムアクセス手順において、複数の無線デバイスが輻輳状態となり、再送処理が頻発するケースも生じ得る。なお、「手順」は、「処理」、「シーケンス」、あるいは、「プロシージャ」等と称されてもよい。
【００５７】
更には、無線デバイスの処理負荷の増大に限らず、ＲＡＮやコアネットワーク（以下「上位ネットワーク」と総称することがある。）のエレメント（「ノード」あるいは「エンティティ」と称してもよい。）における処理負荷が増大し輻輳が生じる可能性もある。
【００５８】
そこで、本実施形態では、ＬＴＥアーキテクチャのような無線通信システムへのＭＴＣサービスの適用において、上位ネットワークにおける処理負荷の増大や輻輳の発生を抑制できるようにする。
【００５９】
例えば、同一無線エリア２００において膨大な数のＭＴＣデバイス１１が一斉に接続処理を開始するようなイベントが発生する前に、複数のＭＴＣデバイス１１から上位ネットワークへのアタッチ要求を、ｅＮＢ２０が代理で上位ネットワークへ送信してよい。これにより、上位ネットワークにおける処理負荷の増大や輻輳状態の発生を回避あるいは抑制することができる。
【００６０】
ここで、上述した懸念事項をより具体的に説明するために、図４に、図１に例示したようなＬＴＥアーキテクチャにおける通常のＵＥ１０のＲＡＮへのアタッチ処理（シーケンス）の一例を示す。また、図５に、図２に例示したようなＭＴＣサービスを適用したＬＴＥアーキテクチャでのアタッチ処理の一例を示す。
【００６１】
図４に例示するように、ＵＥ１０は、電源投入時等のウェイクアップ時に、ｅＮＢ２０から送信される同期信号（ＳＳ）に基づいて、セルサーチ（「セル測定」と称してもよい。）を行ない、接続に適したセルを選択する（処理Ｐ１１〜Ｐ１３）。セル選択は、例示的に、同期信号のＵＥ１０での受信強度に基づいて行なわれてよく、受信強度が最大のセルを選択することであってよい。
【００６２】
その後、ＵＥ１０は、選択したセルにおいて、ｅＮＢ２０が送信する報知情報を受信し、受信した報知情報に設定されている情報を抽出する（処理Ｐ１４及びＰ１５）。報知情報は、報知チャネル（Broadcast Channel）にて送信されてよい。
【００６３】
報知情報には、ダウンリンク（ＤＬ）のシステム帯域幅や、システムフレーム番号（ＳＮＢ）、送信アンテナ数等を識別可能な情報が設定されてよい。当該報知情報は、ＭＩＢ（Master Information Block）と称されてよい。
【００６４】
ＵＥ１０は、抽出したＭＩＢに基づいて、選択したセルを形成するｅＮＢ２０との間で、例えば、ランダムアクセス（ＲＡ）手順及びＲＲＣ（Radio Resource Control）接続手順を実施して無線リンク（例えば、ＲＲＣコネクション）を確立する。なお、図４には、ＲＡ手順及びＲＲＣ接続手順の詳細については図示を省略している。
【００６５】
ｅＮＢ２０との間の無線リンクが確立すると、ＵＥ１０は、アタッチ要求（リクエスト）を当該ｅＮＢ２０へ送信する（処理Ｐ１６）。アタッチ要求は、ＵＥ１０のＲＡＮへの登録（あるいは接続）を要求する信号の一例であり、ＵＥ１０の加入者情報や端末情報等が含まれてよい。
【００６６】
アタッチ要求に含まれる情報を基に、以下に説明するように、ＵＥ１０についてのセキュリティ処理や位置登録処理、セッション設定処理、ＲＲＣ接続処理等が、ｅＮＢ２０に対する上位ネットワークノードにおいて遂行される。
【００６７】
ここでいう「上位ネットワークノード」は、既述のＭＭＥ５０や、Ｓ−ＧＷ３０、Ｐ−ＧＷ４０、及び、ＨＳＳ６０等である。なお、「セッション」は、「コネクション」あるいは「ベアラ」と称してもよい。
【００６８】
ｅＮＢ２０は、アタッチ要求を受信すると、受信したアタッチ要求を、当該アタッチ要求において指定されている宛先ＭＭＥ５０へ送信する（処理Ｐ１７）。ＭＭＥ５０は、アタッチ要求を受信すると、認証情報に基づいて、アタッチ要求の送信元ＵＥ１０に対する認証、秘匿処理、インテグリティ等のセキュリティ処理を実施する（処理Ｐ１８）。なお、認証情報は、例示的に、加入者情報を管理するＨＳＳ６０から取得してよい。
【００６９】
ＵＥ１０に対するセキュリティ処理が正常に終了すれば、ＭＭＥ５０は、ＨＳＳ６０に対して認証済みのＵＥ１０の位置登録（更新）要求（Update Location Request）を送信してよい（処理Ｐ１９）。
【００７０】
ＨＳＳ６０は、ＭＭＥ５０からＵＥ１０の位置登録要求を受信すると、例えば、当該要求に含まれている、ＵＥ１０の位置情報によって当該ＵＥ１０の位置情報を更新、登録して、位置登録応答（Update Location ACK）をＭＭＥ５０に返す（処理Ｐ２０）。
【００７１】
ＭＭＥ５０は、ＨＳＳ６０から位置登録応答を受信すると、Ｓ−ＧＷ３０へセッション作成要求（Create Session Request）を送信する（処理Ｐ２１）。
【００７２】
セッション作成要求を受信したＳ−ＧＷ３０は、Ｐ−ＧＷ４０と連携して、受信したセッション作成要求に応じたベアラのセッションをＰ−ＧＷ４０との間に作成し、セッション作成応答（Create Session Response）をＭＭＥ５０に返信する（処理Ｐ２２）。
【００７３】
当該セッション作成応答には、Ｓ−ＧＷ３０及びＰ−ＧＷ４０間に作成、設定されたベアラと接続する無線ベアラ（別言すると、ＲＲＣ接続）を、ｅＮＢ２０がＵＥ１０との間で設定するための情報（「伝達情報」と称してよい。）が含まれてよい。
【００７４】
ＭＭＥ５０は、セッション作成応答を受信すると、ＲＲＣ接続設定のための伝達情報を、例えば初期コンテキストセットアップ要求（Initial Context Setup Request）にて、アタッチ要求の送信元ｅＮＢ２０へ送信する（処理Ｐ２３）。当該初期コンテキストセットアップ要求と共に、アタッチ要求を正常に受け付けたことを示す信号（Attach Accept）がｅＮＢ２０に送信されてよい。
【００７５】
ｅＮＢ２０は、ＭＭＥ５０から初期コンテキストセットアップ要求を受信すると、当該要求に含まれる伝達情報に基づいて、アタッチ要求の送信元ＵＥ１０との間にＲＲＣ接続を設定するためのＲＲＣメッセージをＵＥ１０へ送信する（処理Ｐ２４）。当該ＲＲＣメッセージは、ＲＲＣ接続再設定（RRC Connection Reconfiguration）メッセージと称してよい。
【００７６】
ＵＥ１０は、ｅＮＢ２０からＲＲＣ接続再設定メッセージを受信すると、当該メッセージに含まれるＲＲＣ接続の設定情報に基づいて、ｅＮＢ２０との間にＲＲＣ接続を設定して設定完了通知をＲＲＣメッセージにてｅＮＢ２０に送信する（処理Ｐ２５）。当該設定完了通知を示すＲＲＣメッセージは、「RRC Connection Reconfiguration Complete」メッセージと称してよい。
【００７７】
ｅＮＢ２０は、ＵＥ１０からＲＲＣ接続の設定完了通知を受信すると、ＭＭＥ５０へ初期コンテキストセットアップ応答（Initial Context Setup Response）を送信する（処理Ｐ２６）。
【００７８】
一方、ＵＥ１０は、ＲＲＣ接続設定が完了すると、ｅＮＢ２０に対して初期直送（Direct Transfer）メッセージを送信して、初期直送手順を開始する（処理Ｐ２７）。
【００７９】
「初期直送手順」は、例示的に、ＲＲＣ接続のアップリンク（ＵＬ）でシグナリング接続（「制御プレーン接続」と称してもよい。）を確立するために実施され、ＵＥ１０の上位レイヤによるＵＬのユーザデータ送信要求に応じて実施されてよい。
【００８０】
初期直送メッセージを受信したｅＮＢ２０は、ＵＥ１０のＲＡＮへのアタッチ処理が完了したことを示すメッセージ（Attach Complete）をＭＭＥ５０に送信する（処理Ｐ２８）。
【００８１】
その後、ＵＥ１０は、確立したＲＲＣ接続にてＵＬのユーザデータをｅＮＢ２０へ送信する。当該ユーザデータは、作成済みのベアラのセッションを通じてＰ−ＧＷ４０へ送信される（処理Ｐ２９）。
【００８２】
また、ＰＤＮからＵＥ１０宛のユーザデータがあれば、当該ベアラのセッションを通じて、Ｐ−ＧＷ４０からｅＮＢ２０経由でダウンリンク（ＤＬ）のユーザデータがＵＥ１０へ送信される（処理Ｐ３２）。
【００８３】
なお、例えばＵＥ１０の移動（例えばハンドオーバ等）に伴って、Ｓ−ＧＷ３０とＰ−ＧＷ４０との間のベアラに変更が生じることがある。その場合、ＭＭＥ５０は、Ｓ−ＧＷ３０及びＰ−ＧＷ４０へ修正ベアラ要求（Modify Bearer Request）メッセージを送信してよい（処理Ｐ３０）。
【００８４】
ＭＭＥ５０から修正ベアラ要求メッセージを受信したＳ−ＧＷ３０は、Ｐ−ＧＷ４０と連携して、ベアラの修正を行ない、修正ベアラ応答メッセージをＭＭＥ５０に返信してよい（処理Ｐ３１）。ベアラの修正によって、ＵＥ２０は、移動中でもＰＤＮとの通信を正常に継続できる。
【００８５】
次に、図５に、図２に例示したようなＭＴＣサービスを適用したＬＴＥアーキテクチャでのアタッチ処理の一例を示す。図５には、非限定的な一例として、２つのＭＴＣデバイス１１（＃１及び＃２）が、１つのｅＮＢ２０に対してアタッチ要求を送信するケースを例示している。
【００８６】
ＭＴＣデバイス＃１及び＃２は、それぞれ、電源ＯＮ等によってウェイクアップされると、図４に例示したＵＥ１０のアタッチ処理と同様にして、セルサーチやセル選択、報知情報の抽出等の処理を実施した後、アタッチ要求をｅＮＢへ送信する。
【００８７】
各アタッチ要求は、ＭＭＥ５０へ送信される。ＭＭＥ５０は、受信したアタッチ要求のそれぞれについて、ＨＳＳ６０やＳ−ＧＷ３０、Ｐ−ＧＷ４０、ＳＣＳ８０等の上位ノードに対する要求の送信や応答の受信を行なう。
【００８８】
例えば、ＭＭＥ５０は、受信したアタッチ要求毎に、ＨＳＳ６０との間で位置登録要求の送信及び位置登録応答の受信を行ない、また、Ｓ−ＧＷ３０、Ｐ−ＧＷ４０及びＳＣＳ８０との間でセッション作成要求の送信及びセッション作成応答の受信を行なう。
【００８９】
なお、図５において、処理Ｐ２１ａ及び処理Ｐ２２ａは、Ｐ−ＧＷ４０とＳＣＳ８０との間でＭＴＣデバイス１１のＭＴＣアプリケーション１１０に応じたセッションの作成要求及び作成応答が送受信されることを例示している。
【００９０】
ここで、例えば、定期的にＳＣＳ８０と通信を行なうようなＭＴＣデバイス１１がｅＮＢ２０の無線エリア２００に多数存在することを想定する。この場合、多数のＭＴＣデバイス１１が一斉にウェイクアップすると、上位ネットワークノードに対して多数のアタッチ要求がｅＮＢ２０経由で上位ノードへ送信されることになる。そのため、上位ネットワークノードに対する要求の輻輳や上位ネットワークノードにおける処理負荷の増大が生じるおそれがある。
【００９１】
例えば、（１）ＭＭＥ５０に対するアタッチ要求の輻輳や、（２）ＨＳＳ６０に対する位置登録要求の輻輳、（３）ＭＴＣアプリケーションを有する特定のＳＣＳ８０に対する接続（セッション作成）要求の輻輳等が生じ易くなる。また、ＭＭＥ５０やＨＳＳ６０、ＳＣＳ８０の処理負荷が増大し易くなる。
【００９２】
上記（１）のＭＭＥ５０に対するアタッチ要求の輻輳は、ＨＳＳ６０やＳＣＳ８０に対する要求にも連鎖的に影響し得る。別言すると、上記（２）及び（３）の輻輳は、上記（１）の輻輳が原因で生じ易くなるともいえる。
【００９３】
そこで、本実施形態では、１つのｅＮＢ２０に多数のＭＴＣデバイス１１が接続し得る状況において、ＭＭＥ５０に対するアタッチ要求の輻輳対処方法について検討する。
【００９４】
まず、当該輻輳対処方法の説明に先立って、図６を参照して、ＭＴＣデバイス１１についてのＲＡ手順、ＲＲＣ接続手順、及び、アタッチ処理の一例について説明する。なお、図６に例示するＲＡ手順は、「競合（contention）ベース」と呼ばれるＲＡ手順の一例である。ただし、「非競合（non-contention）ベース」のＲＡ手順の適用が排除されるわけではない。
【００９５】
図６に例示するように、ＭＴＣデバイス１１は、ウェイクアップ後、既述のＵＥ１０の場合と同様にセルサーチ、セル選択及び報知情報抽出の各処理を実施した後、アタッチ要求を送信する前に、ＲＡ手順及びＲＲＣ接続手順を実施する。
【００９６】
例えば、ＭＴＣデバイス１１は、ＲＡ手順に処理を移行すると、予め用意されている複数のＲＡプリアンブルのいずれか１つをランダムに選択し、選択したＲＡプリアンブルをｅＮＢ２０へ送信する（処理Ｐ５１及びＰ５２）。
【００９７】
ｅＮＢ２０は、ＭＴＣデバイス１１が送信したＲＡプリアンブルを検出すると（別言すると、ＲＡプリアンブルの受信に成功すると）、ＲＡ手順に処理を移行して、ＲＡレスポンスをＭＴＣデバイス１１に返信する（処理Ｐ５３及びＰ５４）。
【００９８】
ＲＡレスポンスをｅＮＢ２０から受信したＭＴＣデバイス１１は、スケジュール送信（Schedule Transmission）メッセージをｅＮＢ２０へ送信する（処理Ｐ５５）。スケジュール送信メッセージには、送信元ＭＴＣデバイス１１を識別可能な情報（例えば、識別子（ＩＤ））が含まれてよい。
【００９９】
ｅＮＢ２０は、スケジュール送信メッセージを受信してＭＴＣデバイス１１のＩＤの検出に成功したＭＴＣデバイス１１に対して、ＲＡに成功したことを示す競合解決（Contention Resolution）メッセージを送信する（処理Ｐ５６）。
【０１００】
競合解決メッセージを受信したＭＴＣデバイス１１は、ＲＲＣ接続処理に処理を移行し、ＲＲＣ接続要求（RRC Connection Request）メッセージをｅＮＢ２０へ送信する（処理Ｐ５７及びＰ５８）。
【０１０１】
ｅＮＢ２０は、ＭＴＣデバイス１１からＲＲＣ接続要求メッセージを受信すると、ＲＲＣ接続設定のためのセル設定情報等を含むＲＲＣ接続セットアップ（RRC Connection Setup）メッセージをＭＴＣデバイス１１に送信する（処理Ｐ５９）。
【０１０２】
ＭＴＣデバイス１１は、ＲＲＣ接続セットアップメッセージをｅＮＢ２０から受信すると、セル設定情報等に基づいて、ｅＮＢ２０との間のＲＲＣ接続の設定を行なう。設定が完了すれば、ＭＴＣデバイス１１は、ＲＲＣ接続設定完了（RRC Connection Setup Complete）メッセージをｅＮＢ２０へ送信する（処理Ｐ６０）。当該ＲＲＣ接続設定完了メッセージは、例示的に、ＵＬの個別制御チャネル（ＤＣＣＨ）にて送信されてよい。
【０１０３】
ｅＮＢ２０は、ＭＴＣデバイス１１から例えばＵＬのＤＣＣＨにてＲＲＣ接続設定完了メッセージを受信すると、ＤＬのＤＣＣＨにて、確認応答（DCCH Data ACK）メッセージをＭＴＣデバイス１１へ送信してよい（処理Ｐ６１）。
【０１０４】
ＭＴＣデバイス１１は、ＤＬのＤＣＣＨの確認応答メッセージを受信すると、アタッチ処理に処理を移行し、ＭＭＥ５０宛にＵＬの情報を転送するＵＬ情報転送（UL Information Transfer）メッセージをｅＮＢへ送信してよい（処理Ｐ６２及びＰ６３）。当該ＵＬ情報転送メッセージが、既述のアタッチ要求に相当する。アタッチ要求は、ＮＡＳ（None Access Stratum）メッセージと称されてもよい。
【０１０５】
ｅＮＢ２０は、ＭＴＣデバイス１１からアタッチ要求を受信すると、当該アタッチ要求において指定されている宛先ＭＭＥ５０へ、受信したアタッチ要求（ＮＡＳメッセージ）を送信（「転送」と称してもよい。）する（処理Ｐ６４及びＰ６５）。
【０１０６】
以上の処理Ｐ６２〜Ｐ６５が、図４及び図５に例示したアタッチ処理Ｐ１６及びＰ１７に相当すると捉えてよい。
【０１０７】
図６において、１つのｅＮＢ２０の無線エリア２００に存在する複数のＭＴＣデバイス１１が同じ時刻にウェイクアップすると、各ＭＴＣデバイス１１がＲＲＣ接続要求及びＭＭＥ５０宛のアタッチ要求を当該ｅＮＢ２０へ同じタイミングで一斉に送信する。
【０１０８】
ここで、ウェイクアップした各ＭＴＣデバイス１１は、それぞれ同じＳＣＳ８０（図２参照）と通信して同じＭＴＣサービスを提供するデバイスであることがある。その場合、各ＭＴＣデバイス１１が、アタッチ要求において指定する宛先ＭＭＥ５０は、同じＭＭＥ５０であると想定される。
【０１０９】
例えば図２において、ＳＣＳ８０にＭＴＣ−ＩＷＦ７０を介して接続されたＭＭＥ５０が、同じＭＴＣサービスを提供する複数のＭＴＣデバイス１１にとっての共通の宛先ＭＭＥ５０に相当すると考えられる。
【０１１０】
そこで、本実施形態では、ｅＮＢ２０においてＭＴＣデバイス１１から受信したアタッチ要求のメッセージ内容を記憶（「保持」と称してもよい。）、管理しておく。そして、過去にアタッチ要求を送信したＭＴＣデバイス１１と同じＭＴＣサービスを提供するＭＴＣデバイス１１からｅＮＢ２０に接続の試行があると、ｅＮＢ２０が、ＭＴＣデバイス１１の代理でＭＭＥ５０に送信する。別言すると、ｅＮＢ２０は、ＭＴＣデバイス１１からのアタッチ要求の受信（検出）を待たずに、保持しているアタッチ要求をＭＭＥ５０へ送信する。
【０１１１】
ｅＮＢ２０による当該アタッチ要求の送信（「代理送信」と称してもよい。）は、ＲＲＣ接続処理が完了する前、例えば、ＲＡ手順の過程において実施されてよい。これにより、ＭＭＥ５０へのアタッチ要求の送信タイミングの分散化を図ることができ、アタッチ要求の輻輳を回避あるいは抑制することができる。
【０１１２】
上述したアタッチ要求の代理送信を実現するために、ｅＮＢは、接続を試行してきた無線デバイスがＭＴＣデバイス１１であるか否かを識別する機能を具備してよい。また、ｅＮＢ２０は、識別したＭＴＣデバイス１１の通信先が同じＭＭＥ５０である複数のＭＴＣデバイス１１をＭＴＣデバイスグループとして管理する機能を具備してよい。
【０１１３】
更に、ｅＮＢ２０は、ＭＴＣデバイス１１から過去に受信したアタッチ要求のメッセージ内容を保持しておく機能を具備してよい。また、ｅＮＢ２０は、保持したメッセージ内容のアタッチ要求をＭＭＥ２０に送信する機能を具備してよい。
【０１１４】
以下、上述したアタッチ要求の代理送信を実現する処理の一例について、図７〜図１６を参照して説明する。なお、以下において、ＲＡ手順及びＲＲＣ接続手順は、いずれも、ｅＮＢに対する「接続要求手順（あるいは処理）」の１つに相当すると捉えてもよい。別言すると、ＲＡ手順とＲＲＣ接続手順とは、「接続要求手順」と総称してもよい。
【０１１５】
（ＭＴＣデバイス識別処理）
まず、図７〜図９を参照して、ｅＮＢ２０によるＭＴＣデバイス１１の識別処理の一例について説明する。
【０１１６】
図７に例示するように、ｅＮＢ２０は、自ノード２０がＭＴＣデバイス１１の通信をサポートしておりＭＴＣ機能が有効である否かを判定する（処理Ｐ１０１）。
【０１１７】
ＭＴＣ機能が有効であれば（処理Ｐ１０１でＹＥＳの場合）、ｅＮＢ２０は、ＭＴＣサービスをサポートしていることを示す情報を無線エリア２００に報知してよい（処理Ｐ１０２）。なお、ＭＴＣ機能が有効でなければ（処理Ｐ１０１でＹＥＳの場合）、ｅＮＢ２０は、処理Ｐ１０２及びＰ１０３をスキップして、通常通り、同期信号及び報知情報の送信を行なってよい（処理Ｐ１０４及びＰ１０５）。
【０１１８】
ＭＴＣサービスをサポートしていることを示す情報は、「ＭＴＣサポート情報」と称してよい。ＭＴＣサポート情報の無線エリア２００への報知には、ＳＩＢ（System Information Block）を用いてよい。
【０１１９】
ＳＩＢには、複数の種別（type）が規定されており、例示的に、「type 1」のＳＩＢ（「ＳＩＢ１」と表記してよい。）をＭＴＣサポート情報の報知に用いてよい。例えば、ｅＮＢは、ＳＩＢ１に含まれる、ＰＬＭＮ（Public Land Mobile Network）の識別子（ＰＬＭＮ−ＩＤ）を用いて、ＭＴＣサポート情報をセルへ報知してよい。
【０１２０】
なお、ＳＩＢは、既述のＭＩＢと同様に報知情報の一例であるが、ＭＩＢとは異なる物理チャネルにて送信されてよい。例えば、ＭＩＢは、ＰＢＣＨ（Physical Broadcast Channel）にて送信されてよく、ＳＩＢは、ＰＤＳＣＨ（Physical Downlink Shard Channel）にて送信されてよい。
【０１２１】
また、ｅＮＢ２０は、当該ｅＮＢ２０に接続を試行してくる無線デバイスがＭＴＣデバイス１１であるかＵＥ１０であるかを示す端末種別情報と、ＲＡプリアンブル（「ＲＡパターン」と称してもよい。）と、をリンク付けしてよい。ｅＮＢ２０は、当該リンク付けを例えばＳＩＢ１に反映してよい（処理Ｐ１０３）。
【０１２２】
リンク付けは、端末種別情報に加えて、無線デバイスによる送信が「初回送信」か「継続送信」かを示す情報の別に実施してよい。例えば図８に示すように、ＲＡプリアンブルとして、１セルあたりに０番〜６３番の合計６４種類のパターンが確保されていると仮定する。
【０１２３】
なお、ＲＡプリアンブルは、物理ランダムアクセスチャネル（ＰＲＡＣＨ）に対して「ＲＡＣＨルートシーケンス」によってシーケンス符号（例えば、Zadoff-Chu系列）を割り当てることで生成できる。
【０１２４】
したがって、ＲＡプリアンブルの上記パターン番号は、当該シーケンス符号のパターン番号に相当すると捉えてよい。「シーケンス符号のパターン番号」は、「シーケンス番号」と称してもよい。ＲＡプリアンブルは、特定の信号系列を含む接続要求の一例である、と捉えてよい。
【０１２５】
この場合、ｅＮＢ２０は、３８〜６３番のＲＡプリアンブルをＭＴＣデバイス１１が選択可能なＲＡプリアンブルにリンク付けしてよい。その他の０〜３７番のパターンのＲＡプリアンブルについては、ＭＴＣデバイス１１でない無線デバイスが選択可能なＲＡプリアンブルとしてリンク付けされてよい。なお、ＭＴＣデバイス１１でない無線デバイスは、「非ＭＴＣデバイス」と称してよく、例えばＵＥ１０であってよい。
【０１２６】
更に、ｅＮＢ２０は、ＭＴＣデバイス１１が選択可能な３８〜６３番のＲＡプリアンブルのうち、３８〜４５番のＲＡプリアンブルを「初回送信」にリンク付けし、その他の４６〜６３番のＲＡプリアンブルを「継続送信」にリンク付けしてよい。
【０１２７】
「継続送信」用のＲＡプリアンブルは、無線エリア２００の一例であるセルの識別子（セルＩＤ）に関連付けて管理されてよい。別言すると、ＭＴＣデバイスは、「継続送信」の場合、セルＩＤは変わらないはずなので、セルＩＤに関連付けられたＲＡプリアンブルを固定的に選択してよい。
【０１２８】
なお、上記のリンク付け（「割り当て」と称してもよい。）は、あくまでも一例であり、リンク付けするＲＡプリアンブルのシーケンス番号は必ずしも連番でなくてよい。ｅＮＢにアクセスしてきた端末が「初回送信」あるいは「継続送信」のＭＴＣデバイスであることをｅＮＢにおいて識別可能であれば、ＲＡプリアンブルのリンク付けのルールは自由である。
【０１２９】
例えば、ＭＴＣデバイス１１が「初回送信」及び「継続送信」のそれぞれで選択可能なＲＡプリアンブルのシーケンス番号候補を、ＭＴＣデバイス１１に予め設定しておいてもよい。ｅＮＢ２０は、非ＭＴＣデバイスに対して、ＭＴＣデバイスに割り当て済みのパターン番号以外のＲＡプリアンブルを優先して選択するように当該ＵＥ１０に指示してよい。当該指示は、例えばＳＩＢにて無線エリア２００に報知されてよい。
【０１３０】
ＲＡプリアンブルのリンク付けが完了すると、ｅＮＢ２０は、無線エリア２００への同期信号及び報知情報（ＭＩＢ及びＳＩＢ）の送信を実施してよい（処理Ｐ１０４及びＰ１０５）。
【０１３１】
ＭＴＣデバイス１１は、ｅＮＢ２０の無線エリア２００においてウェイクアップすると（処理Ｐ１００）、ｅＮＢ２０が送信した同期信号及び報知情報を受信する（処理Ｐ１０６）。ＭＴＣデバイス１１は、受信した報知情報から、ＭＩＢ及びＳＩＢ（ＳＩＢ１）を抽出する（処理Ｐ１０７及びＰ１０８）。
【０１３２】
そして、ＭＴＣデバイス１１は、抽出したＳＩＢ１からトラッキングエリアコード（ＴＡＣ）及びＰＬＭＮ−ＩＤを抽出し、ＰＬＭＮ−ＩＤがＭＴＣサポート情報を示しているかを判定する（処理Ｐ１０９〜Ｐ１１１）。
【０１３３】
判定の結果、ＰＬＭＮ−ＩＤがＭＴＣサポート情報を示していなければ（処理Ｐ１１１でＮＯの場合）、ＭＴＣデバイス１１は、例えば、処理Ｐ１０５以降の処理に戻る。一方、ＰＬＭＮ−ＩＤがＭＴＣサポート情報を示していれば（処理Ｐ１１１でＹＥＳの場合）、ＭＴＣデバイス１１は、ＳＩＢ１から抽出したＴＡＣと、当該ＭＴＣデバイス１１で保持しているＴＡＣと、を比較して一致するか否かを判定する（処理Ｐ１１２）。
【０１３４】
判定の結果、ＴＡＣが一致しなければ（処理Ｐ１１２でＮＯの場合）、ＭＴＣデバイス１１は、過去に当該ｅＮＢ２０との間でＲＲＣ接続を確立しておらず、新規に当該ｅＮＢ２０に接続を試行する（別言すると、「初回送信」である）と判定する。
【０１３５】
当該判定に応じて、ＭＴＣデバイス１１は、ＭＴＣデバイス１１の「初回送信」用に割り当てられたシーケンス符号の中からランダムに１つを選択する（処理Ｐ１１３）。
【０１３６】
一方、ＴＡＣが一致すれば（処理Ｐ１１２でＹＥＳの場合）、ＭＴＣデバイス１１は、過去に当該ｅＮＢ２０との間でＲＲＣ接続を確立しており、ｅＮＢ２０への接続試行は「継続送信」であると判定する。
【０１３７】
当該判定に応じて、ＭＴＣデバイス１１は、ＳＩＢからセルＩＤを抽出し、「継続送信」用に割り当てられているシーケンス番号の中で、セルＩＤに関連付けられたシーケンス番号のシーケンス符号を選択する（処理Ｐ１１４及びＰ１１５）。既述の例であれば、ＭＴＣデバイス１１は、４６〜６３番のシーケンス番号のうちのいずれかのシーケンス符号を選択する。
【０１３８】
処理Ｐ１１３又は処理Ｐ１１５にてシーケンス符号が選択されると、ＭＴＣデバイスは、選択したシーケンス符号にてＲＡプリアンブルを生成し（処理Ｐ１１６）、生成したＲＡプリアンブルをｅＮＢ２０へ送信する（処理Ｐ１１７）。
【０１３９】
図９に例示するように、ｅＮＢ２０は、ＲＡプリアンブルを受信すると（処理Ｐ１２１）、受信したＲＡプリアンブルの生成に用いられたシーケンス符号のパターンを検出する（処理Ｐ１２２）。
【０１４０】
そして、ｅＮＢ２０は、検出したパターンが、ＭＴＣデバイス１１の「初回送信」用に割り当てられているパターン（例えば既述の例で、３８〜４５番）のいずれかに該当するか否かを判定する（処理Ｐ１２３）。
【０１４１】
判定の結果、シーケンス符号のパターンが「初回送信」用のパターンであれば（処理Ｐ１２３でＹＥＳの場合）、ｅＮＢ２０は、処理Ｐ１２４〜Ｐ１２６を実施する。処理Ｐ１２４〜Ｐ１２６は、セルＩＤとシーケンス符号のパターン番号とのリンク付けと、ＭＴＣデバイスへの通知メッセージの生成と、を行なう処理に相当する。
【０１４２】
例えば、ｅＮＢ２０は、処理Ｐ１２４において、ＭＴＣサービス用のセルＩＤを払い出す。「ＭＴＣ用のセルＩＤの払い出し」とは、例えば、ｅＮＢ２０においてセルＩＤとして選択可能なＩＤ群の中から、用途がデフォルトとして既に定められているＩＤを除いた未使用のＩＤを、ＭＴＣサービスに割り当てることであってよい。
【０１４３】
また、処理Ｐ１２５において、ｅＮＢ２０は、ＭＴＣデバイス宛の通知メッセージに含める移動制御情報（Mobility Control Information, MCI）を生成する。
【０１４４】
更に、処理Ｐ１２６において、ｅＮＢ２０は、「継続送信」用のシーケンス符号のパターン番号候補の中から未割当のパターン番号を選択し、選択したパターン番号を処理Ｐ１２４で払い出したセルＩＤにリンク付けする。処理Ｐ１２５及びＰ１２６の順序は、交換可能である。
【０１４５】
そして、ｅＮＢ２０は、ＭＣＩと、「継続送信」用のシーケンス符号のパターン番号と「継続送信」用に払い出したセルＩＤとのリンク付けを示す情報と、をＭＴＣデバイス１１宛に送信するメッセージに設定する（処理Ｐ１２７）。
【０１４６】
当該メッセージには、ＲＲＣメッセージを用いてよく、例示的に、ＲＲＣメッセージの一例であるＲＲＣ接続セットアップ（RRC Connection Setup）メッセージを用いてよい。
【０１４７】
一方、受信ＲＡプリアンブルから検出したシーケンス符号のパターンが「初回送信」用のパターンでなければ（処理Ｐ１２３でＮＯの場合）、ｅＮＢ２０は、ＭＴＣデバイス１１に対して、ＵＥ１０に対するのと同様のＲＡ手順を実施してよい。
【０１４８】
例えば、ｅＮＢ２０は、受信したＲＡプリアンブルに対するＲＡレスポンスをＭＴＣデバイス１１に返信する（処理Ｐ１２８）。
【０１４９】
ＲＡ応答をｅＮＢ２０から受信したＭＴＣデバイス１１は、スケジュール送信メッセージをｅＮＢ２０へ送信してよい（処理Ｐ１２９）。スケジュール送信メッセージには、送信元ＭＴＣデバイスの識別子（ＩＤ）が含まれてよい。
【０１５０】
ｅＮＢ２０は、スケジュール送信メッセージを受信してＭＴＣデバイス１１のＩＤ検出に成功したＭＴＣデバイス１１に対して、ＲＡに成功したことを示す競合解決メッセージを送信してよい（処理Ｐ１３０）。
【０１５１】
競合解決メッセージを受信したＭＴＣデバイス１１は、ＲＲＣ接続処理に処理を移行し、ＲＲＣ接続要求メッセージをｅＮＢ２０へ送信してよい（処理Ｐ１３１及びＰ１３２）。
【０１５２】
ｅＮＢ２０は、ＭＴＣデバイス１１からＲＲＣ接続要求メッセージを受信すると、ＲＲＣ接続設定のためのセル設定情報等を含むＲＲＣ接続セットアップメッセージをＭＴＣデバイス１１に送信してよい（処理Ｐ１３３）。
【０１５３】
ＭＴＣデバイス１１のＲＡプリアンブルの送信が「初回送信」であった場合は、当該ＲＲＣ接続セットアップメッセージに、処理Ｐ１２７で設定された情報が含まれることになる。
【０１５４】
ｅＮＢ２０は、ＲＲＣ接続セットアップメッセージの送信後、受信したＲＡプリアンブルの送信元ＭＴＣデバイス１１の登録処理に処理を移行してよい。例えば、ｅＮＢ２０は、セルＩＤとシーケンス番号とのリンク付け（対応付け）情報を、メモリ等の記憶装置や記憶部、記憶媒体等に記憶してよい（処理Ｐ１３４）。
【０１５５】
リンク付け情報の記憶の形態は、特に限定されないが、例示的に、テーブル形式（あるいはリスト形式）の管理テーブルＭＴであってよい。管理テーブルＭＴにおいて、シーケンス番号毎にセルＩＤが登録されてよい。
【０１５６】
なお、ＭＴＣデバイス１１の「初回送信」では、ＭＴＣデバイス１１で設定される情報（例えば、ＲＡＮにおいてＭＴＣデバイス１１を一意に識別可能な識別子等）をｅＮＢ２０は入手できない。そのため、処理Ｐ１３４の段階では、管理テーブルＭＴによって管理される情報は、セルＩＤとシーケンス番号とのリンク付け情報に限られてよい。
【０１５７】
ＲＡＮにおいてＭＴＣデバイス１１を一意に識別可能な識別子の一例は、ＬＴＥで規定されるＧＵＴＩ（Global Unique Temporary Identity）であってよい。ＧＵＴＩは、ＩＭＳＩ（International Mobile Subscriber Identity）やＴＭＳＩ（Temporary Mobile Subscriber Identity）に相当する識別子であると捉えてもよい。
【０１５８】
一方、ＭＴＣデバイス１１は、ＲＲＣ接続セットアップメッセージをｅＮＢ２０から受信すると、セルＩＤ等のセル設定情報等に基づいて、ｅＮＢ２０との間のＲＲＣ接続の設定を行なう（処理Ｐ１３５）。
【０１５９】
また、ＭＴＣデバイス１１は、受信したＲＲＣ接続セットアップメッセージに、リンク付け情報が設定されていれば、当該リンク付け情報を基に、「継続送信」用のシーケンス符号の設定を行なってよい（処理Ｐ１３６）。既述の例であれば、３８〜４５番のパターン番号のうちのいずれか１つのパターン番号のシーケンス符号が、「継続送信」用に設定されてよい。
【０１６０】
その後、ＭＴＣデバイス１１は、ＲＲＣ接続設定完了（RRC Connection Setup Complete）メッセージを、ｅＮＢ２０へ送信する（処理Ｐ１３７）。当該ＲＲＣ接続設定完了メッセージは、例示的に、ＵＬのＤＣＣＨにて送信されてよい。
【０１６１】
ｅＮＢ２０は、ＭＴＣデバイス１１から例えばＵＬのＤＣＣＨにてＲＲＣ接続設定完了メッセージを受信すると、ＤＬのＤＣＣＨにて、確認応答（DCCH Data ACK）メッセージを、ＭＴＣデバイス１１へ送信してよい（処理Ｐ１３８）。
【０１６２】
以上のようにして、ｅＮＢ２０は、ＲＡプリアンブルのパターンを基に、当該ｅＮＢ２０に接続を試行（又は接続要求）してくる無線デバイスが、ＭＴＣデバイスであるか否かを識別することができる。
【０１６３】
（管理テーブルＭＴ生成／更新／メッセージ保持処理）
次に、図１０〜図１２を参照して、ｅＮＢ２０における、上述した管理テーブルＭＴの生成及び更新処理と、ＭＴＣデバイス１１から受信したアタッチ要求の内容（メッセージ）を保持する処理と、について説明する。
【０１６４】
まず、図１０に例示するように、ｅＮＢ２０は、ＲＲＣ接続処理（処理Ｐ１４１〜Ｐ１４５）を経てアタッチ処理に移行したＭＴＣデバイス１１からアタッチ要求を受信する（処理Ｐ１４６及びＰ１４７）。
【０１６５】
アタッチ要求の受信に応じて、ｅＮＢ２０は、当該アタッチ要求のメッセージ内容を確認して、指定されている宛先ＭＭＥ５０へ、受信したアタッチ要求（ＮＡＳメッセージ）を送信する（処理Ｐ１４８及びＰ１４９）。
【０１６６】
処理Ｐ１４８において、ｅＮＢ２０は、ＧＵＴＩや宛先ＭＭＥ情報等の、ＭＴＣデバイス１１にて設定される情報を入手できる。ｅＮＢ２０は、入手したＧＵＴＩを基に管理テーブルＭＴを参照して、同一ＧＵＴＩのエントリが管理テーブルＭＴに登録されているか否かを判定する（処理Ｐ１５０）。
【０１６７】
判定の結果、ＧＵＴＩのエントリが管理テーブルＭＴに無ければ（処理Ｐ１５０でＮＯの場合）、ｅＮＢ２０は、例えば図１１に示すように、該当するリンク付け情報に、ＧＵＴＩと宛先ＭＭＥ情報とを対応付けて管理テーブルＭＴに登録する（処理Ｐ１５１）。その際、管理テーブルＭＴには、ＧＵＴＩを入手したアタッチ要求のｅＮＢ２０での受信時刻を示す時刻情報が併せて管理テーブルＭＴに登録されてよい。
【０１６８】
時刻情報は、例えば、セルＩＤによって識別されるＭＴＣデバイス１１（又はＭＴＣデバイスグループ）が、アタッチ要求をどのようなタイミングや周期でｅＮＢ２０に送信してくるかを学習、管理、あるいは予測するために用いられてよい。
【０１６９】
また、時刻情報は、ＭＴＣデバイス１１のＲＡＮからの離脱を検出、管理するために用いられてもよい。例えば、時刻情報を基に長時間にわたってアタッチ要求を受信していないＭＴＣデバイス１１は、ＲＡＮから離脱している、と判定してよい。
【０１７０】
一方、処理１５０において、管理テーブルＭＴにＧＵＴＩのエントリが既に管理テーブルＭＴに登録されていれば（処理Ｐ１５０でＹＥＳの場合）、ｅＮＢ２０は、該当ＧＵＴＩのエントリを、受信したアタッチ要求から入手した情報によって更新する（処理Ｐ１５２）。
【０１７１】
図１２に管理テーブルＭＴの更新例を示す。図１２には、非限定的な一例として、３つのＧＵＴＩ（０００１，００１２及び００３２）のエントリが登録済みで、セルＩＤ＝４を払い出したＭＴＣデバイスからアタッチ要求を受信した状況を例示している。
【０１７２】
ここで、当該アタッチ要求に設定されたＧＵＴＩ及び宛先ＭＭＥ情報が他のセルＩＤのエントリと重複することがある。図１２の（１）の例では、ＧＵＴＩ及び宛先ＭＭＥ５０に関して、登録済みのセルＩＤ＝１のエントリと、新規登録したセルＩＤのエントリとが重複している。
【０１７３】
この場合、図１２の（２）に例示するように、ｅＮＢ２０は、セルＩＤ＝４のエントリをセルＩＤ＝１のエントリに集約（マージ）してよい。このとき、セルＩＤ＝１のエントリに集約された、アタッチ要求の送信元ＭＴＣデバイス１１は、集約先のセルＩＤ＝１に対応するＭＴＣデバイス１１と共にＭＴＣデバイスグループを形成する、と捉えてよい。
【０１７４】
別言すると、管理テーブルＭＴにおいて、ＧＵＴＩ及び宛先ＭＭＥ情報が同じであるアタッチ要求を送信した送信元ＭＴＣデバイス１１が、１つのグループとして管理される、と捉えてよい。
【０１７５】
ＧＵＴＩ及び宛先ＭＭＥ情報が同じなら、ｅＮＢ２０は、宛先ＭＭＥ５０に対して、過去に受信、保持したアタッチ要求を先出し的に代理送信してよい。そのため、管理テーブルＭＴにおいて、１つのＭＴＣデバイスグループに、どのＭＴＣデバイス１１が属しているか、ということまでは識別可能でなくてよい。
【０１７６】
管理テーブルＭＴの登録又は更新に応じて、ｅＮＢ２０は、管理テーブルＭＴのセルＩＤ及びＧＵＴＩとリンク付けて、ＭＴＣデバイス１１から受信したアタッチ要求のメッセージ内容をメモリ等に保持しておく（処理Ｐ１５３）。
【０１７７】
以上のようにして、ｅＮＢ２０は、ｅＮＢ２０にアタッチ要求を送信してくるＭＴＣデバイス１１を管理テーブルＭＴにて管理し、アタッチ要求の代理送信に備えて、代理送信の対象となり得るアタッチ要求のメッセージ内容を記憶しておく。
【０１７８】
（登録完了後のアタッチ処理）
次に、図１３及び図１４を参照して、既述のように管理テーブルＭＴへの情報登録が済んでいるＭＴＣデバイス１１、別言すると、過去にアタッチ要求をｅＮＢ２０に送信してきたＭＴＣデバイス１１の新規のアタッチ処理について説明する。
【０１７９】
概要的な説明を行なえば、ｅＮＢ２０は、管理テーブルＭＴに基づいて、アタッチ要求の先出し対象（別言すると、代理送信対象）となるＭＴＣデバイス１１をグループとして管理しておく。
【０１８０】
そして、ｅＮＢ２０は、代理送信対象のグループに対するＲＡプリアンブルのシーケンス符号のパターン番号を基に識別される、過去に受信して保持しているアタッチ要求のメッセージ内容を、対象となるＭＭＥ５０宛にＭＴＣデバイス１１の代理で送信する。
【０１８１】
図１３に例示するように、ＭＴＣデバイス１１のウェイクアップ（処理Ｐ１６１）に応じて、当該ＭＴＣデバイス１１は、ｅＮＢ２０との間でＲＡ手順を開始して、ＲＡプリアンブルをｅＮＢ２０へ送信する（処理Ｐ１６２〜Ｐ１６４）。
【０１８２】
ｅＮＢ２０は、ＲＡプリアンブルを受信すると、受信したＲＡプリアンブルの生成に用いられたシーケンス符号のパターンを検出し、検出したパターンが「初回送信」用に割り当てられているパターンのいずれかに該当するか否かを判定する（処理Ｐ１６５）。
【０１８３】
判定の結果、シーケンス符号のパターンが「初回送信」用のパターンであれば（処理Ｐ１６５でＹＥＳの場合）、ｅＮＢ２０は、例えば図１０及び図１１に例示した管理テーブルＭＴに対する登録処理を実施してよい。
【０１８４】
一方、シーケンス符号のパターンが「継続送信」用のパターンであれば（処理Ｐ１６５でＮＯの場合）、ｅＮＢ２０は、管理テーブルＭＴを参照して当該シーケンス符号のパターン番号に対応するセルＩＤが登録されているか否かを判定する（処理Ｐ１６６及びＰ１６７）。
【０１８５】
セルＩＤが登録されていれば（処理Ｐ１６７でＹＥＳの場合）、ｅＮＢ２０は、管理テーブルＭＴから当該セルＩＤに対応するＧＵＴＩ及び宛先ＭＭＥ情報を読み出す（処理Ｐ１６８）。そして、ｅＮＢ２０は、読み出したＧＵＴＩに対応するアタッチ要求のメッセージ内容をメモリ等から読み出す（処理Ｐ１６９）。
【０１８６】
ｅＮＢ２０は、読み出したメッセージ内容を、管理テーブルＭＴから読み出した宛先ＭＭＥ５０へのアタッチ要求に設定し、当該アタッチ要求をＭＴＣデバイス１１の代理で宛先ＭＭＥ５０へ送信する（処理Ｐ１７０）。
【０１８７】
別言すると、ｅＮＢ２０は、「継続送信」を示す特定のシーケンス符号パターンのＲＡプリアンブルの受信検出に応じて、その後に予定されているＭＴＣデバイス１１からのアタッチ要求の受信を待たずに、記憶しているアタッチ要求を宛先ＭＭＥ５０へ送信する。
【０１８８】
ＭＭＥ５０は、ｅＮＢ２０によって代理送信されたアタッチ要求を通常通りに正常に受け付けることで、図５に例示したように、Ｓ−ＧＷ３０に対してセッション接続要求を送信できる。したがって、Ｐ−ＧＷ４０やＳＣＳ８０を含むコアネットワークと、ＭＴＣデバイス１１との間のベアラを確立することができる。
【０１８９】
また、ｅＮＢ２０によって代理送信されるアタッチ要求は、宛先ＭＭＥ５０に変更が無く、かつ、ＧＵＴＩが同一であるため、ＭＭＥ５０によるＨＳＳ６０に対する位置登録要求は生じない。したがって、ＨＳＳ６０に対する位置登録要求の輻輳を抑制あるいは回避できる。
【０１９０】
なお、管理テーブルＭＴに該当セルＩＤが登録されていなかった場合（処理Ｐ１６７でＮＯの場合）、ｅＮＢ２０は、処理Ｐ１６８〜Ｐ１７０をスキップしてよい。
【０１９１】
その後、ｅＮＢ２０は、ＲＡ手順に処理を移行し（処理Ｐ１７１）、図１４に例示するように、ＭＴＣデバイス１１との間で、ＲＡレスポンスの送信、スケジュール送信メッセージの受信、及び、競合解決メッセージの送信を行なう（処理Ｐ１８１〜Ｐ１８３）。
【０１９２】
競合解決メッセージを受信したＭＴＣデバイス１１は、ＲＲＣ接続処理に処理を移行する（処理Ｐ１８４）。例えば、ＭＴＣデバイス１１は、ｅＮＢ２０との間で、ＲＲＣ接続要求メッセージの送信、ＲＲＣ接続セットアップメッセージの受信、ＲＲＣ接続設定完了メッセージの送信、及び、ＤＣＣＨの確認応答メッセージの受信を行なう（処理Ｐ１８５〜Ｐ１８８）。
【０１９３】
ｅＮＢ２０からのＤＣＣＨの確認応答メッセージの受信に応じて、ＭＴＣデバイス１１は、アタッチ処理に処理を移行して、アタッチ要求をｅＮＢ２０へ送信する（処理Ｐ１８９及びＰ１９０）。
【０１９４】
ｅＮＢ２０は、アタッチ要求を受信すると、そのメッセージ内容を基に、図１３の処理Ｐ１７０で代理送信済みのメッセージ内容及び宛先ＭＭＥ５０と差異が無いか否かを、管理テーブルＭＴを参照して確認（照合）してよい。
【０１９５】
差異が無ければ、当該アタッチ要求は宛先ＭＭＥ５０へ送信せずに破棄してよい（処理Ｐ１９１）。これにより、ＭＭＥ５０に対するアタッチ要求の輻輳を抑制あるいは回避できる。
【０１９６】
一方、差異が有れば、ｅＮＢ２０は、通常通り、受信したアタッチ要求のメッセージ内容を宛先ＭＭＥ５０へ送信してよい（処理Ｐ１９２）。また、図１３及び図１４中に点線矢印で例示するように、図１３の処理Ｐ１６７でセルＩＤが管理テーブルＭＴに登録されていなかった場合（ＮＯの場合）も、ｅＮＢ２０は、処理Ｐ１９０で受信したアタッチ要求のメッセージ内容を宛先ＭＭＥ５０へ送信してよい（処理Ｐ１９２）。
【０１９７】
以上のように、上述した実施形態によれば、過去に同じＭＭＥ５０宛のアタッチ要求を受信したＭＴＣデバイス１１をｅＮＢ２０において識別、管理しておく。そして、管理しているＭＴＣデバイス１１から、再度、ｅＮＢ２０への接続試行（例えば、ＲＡ）があると、ｅＮＢ２０が、ＭＭＥ５０へアタッチ要求を先出し的に代理送信する。
【０１９８】
これにより、１つのｅＮＢ２０に接続し得るＭＴＣデバイス１１の数が増えても、ＭＭＥ５０に対するアタッチ要求の送信頻度を削減することができ、アタッチ要求の輻輳を抑制あるいは回避することが可能になる。その結果、ＲＡＮの処理負荷を軽減することができる。
【０１９９】
また、ｅＮＢ２０は、ＭＭＥ５０へのアタッチ要求の代理送信を、ＭＴＣデバイス１１との間のＲＡ手順の終了前、別言すると、ＭＴＣデバイス１１との間のＲＲＣ接続処理の開始又は完了前に実施してよい。
【０２００】
したがって、ＭＭＥ５０は、ＭＴＣデバイス１１と、Ｓ−ＧＷ３０やＰ−ＧＷ４０を経由したＳＣＳ８０と、の間のセッション（コネクション）設定を、ＭＴＣデバイス１１とｅＮＢ２０との間のＲＲＣ接続処理を待たずに、早期に開始できる。よって、例えば、ＭＴＣデバイス１１は、ＳＣＳ８０との間でＭＴＣサービス（別言すると、ＭＴＣアプリケーション）に応じた通信を早期に開始できる。
【０２０１】
以上のように、上述した実施形態によれば、ＭＴＣサービスを提供する複数のＭＴＣデバイス１１が、ｅＮＢ２０経由で上位ネットワークノードと通信するために、アタッチ要求を一斉に送信することによる輻輳状態を抑制あるいは回避できる。したがって、ＲＡＮの負荷を軽減することができる。
【０２０２】
（変形例）
次に、図１５及び図１６を参照して、上述した実施形態の変形例について説明する。本変形例では、アタッチ要求をＭＭＥ５０へ代理送信したｅＮＢ２０が、その旨を無線エリア２００に報知することで、ＭＴＣデバイス１１がアタッチ処理をスキップして次処理を開始してよい例について説明する。
【０２０３】
なお、図１５及び図１６では、複数（例示的に、２台）のＭＴＣデバイス（＃１及び＃２）が、１つのｅＮＢ２０に接続可能であり、ｅＮＢ２０において、各ＭＴＣデバイス１１が同じセルＩＤによってグループ管理されている状況を想定する。
【０２０４】
まず、図１５に例示するように、ＭＴＣデバイス＃１のウェイクアップ（処理Ｐ２０１）に応じて、当該ＭＴＣデバイス＃１は、ｅＮＢとの間でＲＡ手順を開始して、ＲＡプリアンブルをｅＮＢ２０へ送信する（処理Ｐ２０２〜Ｐ２０４）。
【０２０５】
ｅＮＢ２０は、ＲＡプリアンブルを受信すると（処理Ｐ２０５）、受信したＲＡプリアンブルの生成に用いられたシーケンス符号のパターンを検出する（処理Ｐ２０６）。
【０２０６】
そして、ｅＮＢ２０は、管理テーブルＭＴを参照して、検出したシーケンス符号のパターン番号に対応するセルＩＤが登録されているか否かを判定する（処理Ｐ２０７及びＰ２０８）。
【０２０７】
セルＩＤが登録されていれば（処理Ｐ２０８でＹＥＳの場合）、ｅＮＢ２０は、管理テーブルＭＴから当該セルＩＤに対応するＧＵＴＩ及び宛先ＭＭＥ情報を読み出す（処理Ｐ２０９）。そして、ｅＮＢ２０は、読み出したＧＵＴＩに対応するアタッチ要求のメッセージ内容をメモリ等から読み出す（処理Ｐ２１０）。
【０２０８】
ｅＮＢは、読み出したメッセージ内容を、管理テーブルＭＴから読み出した宛先ＭＭＥ情報が示す宛先ＭＭＥ５０へのアタッチ要求に設定し、当該アタッチ要求をＭＴＣデバイス１１の代理で宛先ＭＭＥ５０へ送信する（処理Ｐ２１１）。
【０２０９】
ＭＭＥ５０は、ｅＮＢ２０によって代理送信されたアタッチ要求を通常通りに正常に受け付けることで、図５に例示したように、Ｓ−ＧＷ３０に対してセッション接続要求を送信してよい。したがって、Ｐ−ＧＷ４０やＳＣＳ８０を含むコアネットワークと、ＭＴＣデバイス１１との間のベアラを確立することができる。
【０２１０】
一方、ｅＮＢ２０は、ＭＭＥ５０へのアタッチ要求の代理送信後に、ＲＡ手順に処理を移行してよい（処理Ｐ２１２）。また、ｅＮＢ２０は、処理Ｐ２０８において管理テーブルＭＴにセルＩＤが未登録の場合（ＮＯの場合）も、処理Ｐ２０９〜Ｐ２１１をスキップして、ＲＡ手順に処理を移行してよい（処理Ｐ２１２）。
【０２１１】
例えば図１６に示すように、ｅＮＢ２０は、ＭＴＣデバイス＃１との間で、ＲＡレスポンスの送信、スケジュール送信メッセージの受信、及び、競合解決メッセージの送信を行なってよい（処理Ｐ２１３〜Ｐ２１５）。
【０２１２】
競合解決メッセージを受信したＭＴＣデバイス＃１は、ＲＲＣ接続処理に処理を移行してよい（処理Ｐ２１６）。例えば、ＭＴＣデバイス＃１は、ｅＮＢ２０との間で、ＲＲＣ接続要求メッセージの送信、ＲＲＣ接続セットアップメッセージの受信、ＲＲＣ接続設定完了メッセージの送信、及び、ＤＣＣＨの確認応答メッセージの受信を行なってよい（処理Ｐ２１７〜Ｐ２２０）。
【０２１３】
ここで、ｅＮＢ２０は、例えば、報知チャネルにて、ｅＮＢ２０がＭＭＥ５０へのアタッチ要求の代理送信を実施したことを示す情報を無線エリア２００へ報知してよい（処理Ｐ２２１及びＰ２２２）。報知情報には、ＳＩＢを用いてよい。
【０２１４】
ＭＴＣデバイス＃１と同じＭＴＣデバイスグループに属する他のＭＴＣデバイス＃２がウェイクアップすると、ｅＮＢ２０から報知チャネルの信号を受信して報知情報を抽出する（処理Ｐ２２３）。
【０２１５】
ＭＴＣデバイス＃２は、抽出した報知情報から、ｅＮＢ２０がアタッチ要求の代理送信を既に実施したことを認識できる。したがって、ＭＴＣデバイス＃２はアタッチ処理をスキップして次処理に移行してよい（処理Ｐ２２４）。
【０２１６】
このように、ＭＴＣデバイス＃２は、アタッチ処理をスキップしてよいので、ＭＴＣデバイス＃２の処理負荷の軽減を図ることができる。
【０２１７】
一方、ＭＴＣデバイス＃１は、処理Ｐ２２０においてＤＣＣＨの確認応答メッセージを受信してＲＲＣ接続処理が完了しているので、アタッチ処理に処理を移行して、アタッチ要求をｅＮＢ２０へ送信してよい（処理Ｐ２２５及びＰ２２６）。
【０２１８】
ｅＮＢ２０は、ＭＴＣデバイス＃１からアタッチ要求を受信すると、図１４の処理Ｐ１９１及びＰ１９２と同様の処理を実施してよい。例えば、ｅＮＢ２０は、管理テーブルＭＴを参照して、受信したアタッチ要求の内容及び宛先ＭＭＥ情報に差異が無いかを確認（照合）して、差異が無ければ、当該アタッチ要求は破棄してよい（処理Ｐ２２７）。これにより、ＭＭＥ５０に対するアタッチ要求の輻輳を抑制あるいは回避できる。
【０２１９】
（ｅＮＢ及びＭＴＣデバイスの構成例）
次に、図１７及び図１８を参照して、上述したｅＮＢ２０及びＭＴＣデバイス１１の構成例について説明する。なお、図１７が、ｅＮＢ２０の構成例を示すブロック図であり、図１８が、ＭＴＣデバイス１１の構成例を示すブロック図である。
【０２２０】
（ｅＮＢの構成例）
図１７に示すｅＮＢ２０は、例示的に、図１に示したようにＲＥ２１とＢＳ２２とが分離された構成を有してよい。ただし、ｅＮＢ２０は、ＲＥ２１とＢＳ２２とを一体的に備えた構成であってもよい。
【０２２１】
ＲＥ２１は、例示的に、アンテナ２１１、デュプレクサ２１２、ローノイズアンプ（ＬＮＡ）２１３、ダウンコンバータ２１４、アップコンバータ２１５、及び、パワーアンプ（ＰＡ）２１６を備えてよい。更に、ＲＥ２１は、変復調処理部２１７、制御部２１８、及び、ＥＯ／ＯＥモジュール２１９を備えてよい。
【０２２２】
一方、ＢＳ２２は、例示的に、伝送路インタフェース（ＩＦ）２２１、タイミング制御部２２２、制御部２２３、ベースバンド処理部２２４、記憶部２２５、及び、ＥＯ／ＯＥモジュール２２６を備えてよい。
【０２２３】
ＲＥ２１において、アンテナ２１１は、無線エリア２００を形成する無線信号の送受信を行なう。
【０２２４】
デュプレクサ２１２は、ＰＡ２１６からアンテナ２１１への無線送信信号と、アンテナ２１１からＬＮＡ２１３への無線受信信号と、を分離する。
【０２２５】
ＬＮＡ２１３は、デュプレクサ２１２から入力される無線受信信号を低雑音増幅してダウンコンバータ２１４へ出力する。
【０２２６】
ダウンコンバータ２１４は、ＬＮＡ２１３で増幅された無線受信信号をベースバンド信号に変換（ダウンコンバート）して変復調処理部２１７に出力する。
【０２２７】
アップコンバータ２１５は、変復調処理部２１７で変調された送信ベースバンド信号を無線送信信号に変換（アップコンバート）してＰＡ２１６に出力する。
【０２２８】
ＰＡ２１６は、アップコンバータ２１５からの無線送信信号を所定の送信電力に増幅する。ＰＡ２１６で増幅された無線送信信号は、デュプレクサ２１２を介してアンテナ２１１から空間へ送信される。
【０２２９】
変復調処理部２１７は、ＥＯ／ＯＥ変換モジュール２１９から入力される送信データを変調して送信ベースバンド信号を生成してアップコンバータ２１５へ出力する。また、変復調処理部２１７は、ダウンコンバータ２１４から入力される受信ベースバンド信号を復調して受信データをＥＯ／ＯＥ変換モジュール２１９へ出力する。
【０２３０】
変復調処理部２１７による変調及び復調には、ＵＥ１０やＭＴＣデバイス１１との間の無線通信方式に応じた変調方式及び復調方式を適用してよい。例えば、ＬＴＥやＬＴＥ−Ａｄｖａｎｃｅｄに準拠した通信方式であれば、ＯＦＤＭ（Orthogonal Frequency-Division Multiplexing）等の直交変調及び直交復調方式を、変復調処理部２１７に適用してよい。
【０２３１】
変復調処理部２１７には、ＢＳ２２との間の光インタフェースの一例であるＣＰＲＩを通じて送受信される信号を処理（終端等）する機能が含まれてもよい。変復調処理部２１７は、例示的に、ＦＰＧＡ（Field Programmable Gate Array）を用いて実現されてよい。
【０２３２】
制御部２１８は、ＲＥ２１の動作を統括的に制御する。当該制御には、変復調処理部２１７による変復調処理の制御やＰＡ２１６の増幅率の制御等が含まれてよい。制御部２１８は、例示的に、演算能力を備えたプロセッサと、メモリ等の記憶部と、を用いて実現されてよい。
【０２３３】
プロセッサの一例は、ＣＰＵ（Central Processing Unit）であり、メモリの一例は、ＤＲＡＭ（Dynamic Random Access Memory）である。ただし、適用可能なプロセッサ及びメモリの一例は、これらに限られない。
【０２３４】
ＥＯ／ＯＥ変換モジュール２１９は、ＢＳ２２のＥＯ／ＯＥ変換モジュール２２６と例えば光ファイバにて接続されて、ＢＳ２２のＥＯ／ＯＥ変換モジュール２２６との間で光ファイバを通じて光信号の送受信を行なう。
【０２３５】
例えば、ＥＯ／ＯＥ変換モジュール２１９は、ＢＳ２２から受信した光信号を電気信号に光電（ＯＥ）変換し、また、ＢＳ２２へ送信する電気信号を光信号に電光（ＥＯ）変換する。
【０２３６】
ＢＳ２２から受信して電気信号に変換された信号は、送信データを含んでよく、変復調処理部２１７に入力されてよい。ＢＳ２２へ光信号に変換して送信する電気信号は、変復調処理部２１７から入力され、変復調処理部２１７で復調された受信データが含まれてよい。
【０２３７】
一方、ＢＳ２２において、伝送路インタフェース２２１は、例示的に、コアネットワークとの間で送受信される信号を処理する。伝送路インタフェース２２１には、例示的に、レイヤ２スイッチ（Ｌ２ＳＷ）やイーサネット（登録商標）の物理レイヤを処理するインタフェース等が含まれてよい。
【０２３８】
タイミング制御部２２２は、例示的に、ＢＳ２２全体の動作タイミングを制御する。例えば、タイミング制御部２２２は、ベースバンド処理部２２４及び制御部２２３の動作タイミングを制御してよい。
【０２３９】
動作タイミングの制御は、例示的に、電圧制御発振器（ＶＣＸＯ）によって生成される基準クロック信号に基づいて実施されてよい。基準クロック信号は、ＢＳ２２の位置情報に基づいて補正されても構わない。ＢＳ２２の位置情報は、例示的に、ＧＰＳ（Global Positioning System）モジュールによって取得されてよい。
【０２４０】
ベースバンド処理部２２４は、例示的に、伝送路インタフェース２２１とＲＥ２１との間で送受信される信号のベースバンド処理を行なう。ベースバンド処理には、例示的に、デジタル変復調処理や、誤り訂正符号を用いた符号化及び復号化等が含まれてよい。
【０２４１】
ベースバンド処理部２２４には、例示的に、ＭＴＣデバイス識別／メッセージ生成部２２４１が含まれてよい。ＭＴＣデバイス識別／メッセージ生成部２２４１は、記憶部２２５に記憶されたデータに基づいて、既述のＭＴＣデバイス１１の識別処理、並びに、既述のＲＡ手順、ＲＲＣ接続処理、及び、アタッチ処理等に用いられるメッセージの生成を行なうことが可能である。
【０２４２】
そのため、記憶部２２５に記憶されるデータには、既述の管理テーブルＭＴや、ＭＴＣデバイス識別／メッセージ生成部２２４１が既述の処理を実施するために用いるデータやプログラム等が含まれてよい。記憶部２２５は、メモリであってよく、メモリの一例は、ＤＲＡＭである。
【０２４３】
なお、ＭＴＣデバイス識別／メッセージ生成部２２４１を含むベースバンド処理部２２４は、例示的に、ＦＰＧＡやＤＳＰ（Digital Signal Processor）、ＤＲＡＭ等を用いて実現されてよい。
【０２４４】
制御部２２３は、例示的に、ＢＳ２２の全体的な動作を統括制御してよい。例えば、制御部２２３は、伝送路インタフェース２２１とベースバンド処理部２２４との間のデジタル信号の授受を制御してよい。
【０２４５】
ＢＳ２２のＥＯ／ＯＥ変換モジュール２２６は、既述のとおりＲＥ２１のＥＯ／ＯＥ変換モジュール２１９と例えば光ファイバにて接続されて、ＲＥ２１のＥＯ／ＯＥ変換モジュール２１９との間で光ファイバを通じて光信号の送受信を行なう。
【０２４６】
例えば、ＥＯ／ＯＥ変換モジュール２２６は、ＲＥ２１から受信した光信号を電気信号に光電（ＯＥ）変換し、また、ＲＥ２１へ送信する電気信号を光信号に電光（ＥＯ）変換する。
【０２４７】
ＲＥ２１から受信して電気信号に変換された信号は、ＲＥ２１の変復調処理部２１７で復調された受信データを含んでよく、例えばベースバンド処理部２２４に入力される。ＲＥ２１へ光信号に変換して送信する電気信号は、ベースバンド処理部２２４から入力され、ＲＥ２１の変復調処理部２１７で変調される送信データが含まれてよい。
【０２４８】
（ＭＴＣデバイスの構成例）
図１８に示すように、ＭＴＣデバイス１１は、例示的に、アンテナ１１１、デュプレクサ１１２、ＬＮＡ１１３、ＰＡ１１４、変復調処理部１１５、信号処理部１１６、制御部１１７、及び、ＭＴＣサービス処理部１１８を備えてよい。
【０２４９】
アンテナ１１１は、例えば、ｅＮＢ２０との間で無線信号の送受信を行なう。
【０２５０】
デュプレクサ１１２は、ＰＡ１１４からアンテナ１１１への無線送信信号と、アンテナ１１１からＬＮＡ１１３への無線受信信号と、を分離する。
【０２５１】
ＬＮＡ１１３は、デュプレクサ１１２から入力される無線受信信号を低雑音増幅して変復調処理部１１５へ出力する。
【０２５２】
ＰＡ１１４は、変復調処理部１１５からの無線送信信号を所定の送信電力に増幅する。ＰＡ１１４で増幅された無線送信信号は、デュプレクサ１１２を介してアンテナ１１１から空間へ送信される。
【０２５３】
変復調処理部１１５には、ＬＮＡ１１３からの無線受信信号をベースバンド信号に変換するダウンコンバータ、及び、ＰＡ１１４への送信ベースバンド信号を無線送信信号に変換するアップコンバータが含まれてよい。
【０２５４】
変復調処理部１１５は、信号処理部１１６から入力される送信データを変調し、変調信号を無線送信信号にアップコンバートしてＰＡ１１４へ出力する。また、変復調処理部１１５は、ＬＮＡ１１３から入力されてベースバンド信号にダウンコンバートした受信信号を復調して受信データを信号処理部１１６へ出力する。
【０２５５】
変復調処理部１１５による変調及び復調には、ｅＮＢ２０との間の無線通信方式に応じた変調方式及び復調方式を適用してよい。例えば、ＬＴＥやＬＴＥ−Ａｄｖａｎｃｅｄに準拠した通信方式であれば、ＯＦＤＭ等の直交変調及び直交復調方式を変復調処理部１１５に適用してよい。変復調処理部１１５は、例示的に、ＦＰＧＡを用いて実現されてよい。
【０２５６】
信号処理部１１６は、例示的に、変復調処理部１１５への送信データ、及び、変復調処理部１１５からの受信データをデジタル信号処理する。信号処理部１１６に、ランダムアクセス（ＲＡ）処理部１１６１が含まれてよい。ＲＡ処理部１１６１によってｅＮＢ２０との間で既述のＲＡ手順を実行可能である。
【０２５７】
ＲＡ処理部１１６１を含む信号処理部１１６は、例示的に、ＤＳＰやＤＲＡＭを用いて実現されてよい。
【０２５８】
制御部１１７は、例示的に、ＭＴＣデバイス１１の全体的な動作を統括制御してよい。当該制御には、信号処理部１１６によるデジタル信号処理の制御が含まれてよい。制御部１１７に、ＲＲＣ／アタッチ処理部１１７１が含まれてよい。ＲＲＣ／アタッチ処理部１１７１によって、ｅＮＢ２０との間で既述のＲＲＣ接続処理とアタッチ処理とを実行可能である。
【０２５９】
ＭＴＣサービス処理部１１８は、ＭＴＣサービスに応じた処理を実施する。当該処理には、例示的に、ＭＴＣデバイス１１のウェイクアップやスリープ動作、ＲＡＮへのアタッチ処理後のＳＣＳ８０との間のＭＴＣサービスに応じた通信処理等が含まれてよい。
【０２６０】
ＭＴＣサービスに応じた通信処理には、センサやメータ等によってセンシングあるいは計測された情報をＳＣＳ８０へ送信することが含まれてよい。そのため、ＭＴＣサービス処理部１１８には、図示を省略したセンサやメータ等が含まれてよい。
【符号の説明】
【０２６１】
１０  無線デバイス（ＵＥ）
１１  無線デバイス（ＭＴＣデバイス）
１１０  ＭＴＣアプリケーション
１１１  アンテナ
１１２  デュプレクサ
１１３  低雑音増幅器（ＬＮＡ）
１１４  パワーアンプ（ＰＡ）
１１５  変復調処理部
１１６  信号処理部
１１７  制御部
１１８  ＭＴＣサービス処理部
２０  無線基地局（ｅＮＢ）
２１  ＲＥ
２１１  アンテナ
２１２  デュプレクサ
２１３  ローノイズアンプ（ＬＮＡ）
２１４  ダウンコンバータ
２１５  アップコンバータ
２１６  パワーアンプ（ＰＡ）
２１７  変復調処理部
２１８  制御部
２１９  ＥＯ／ＯＥモジュール
２２  ＢＳ
２２１  伝送路インタフェース
２２２  タイミング制御部
２２３  制御部
２２４  ベースバンド処理部
２２５  記憶部
２２６  ＥＯ／ＯＥモジュール
３０  Ｓ−ＧＷ
４０  Ｐ−ＧＷ
５０  ＭＭＥ
６０  ＨＳＳ
７０  ＭＴＣ−ＩＷＦ
８０  ＳＣＳ（ＭＴＣサーバ）
ＭＴ  管理テーブル
【図１】
2016122887.tif 000003
【図２】
2016122887.tif 000004
【図３】
2016122887.tif 000005
【図４】
2016122887.tif 000006
【図５】
2016122887.tif 000007
【図６】
2016122887.tif 000008
【図７】
2016122887.tif 000009
【図８】
2016122887.tif 000010
【図９】
2016122887.tif 000011
【図１０】
2016122887.tif 000012
【図１１】
2016122887.tif 000013
【図１２】
2016122887.tif 000014
【図１３】
2016122887.tif 000015
【図１４】
2016122887.tif 000016
【図１５】
2016122887.tif 000017
【図１６】
2016122887.tif 000018
【図１７】
2016122887.tif 000019
【図１８】
2016122887.tif 000020