JP2018061268A

JP2018061268A - 通信システム、基地局および基地局制御装置

Info

Publication number: JP2018061268A
Application number: JP2017218031A
Authority: JP
Inventors: 前田　美保; Miho Maeda; 美保前田; 望月　満; Mitsuru Mochizuki; 満望月; 靖岩根; Yasushi Iwane; 隆之野並; Takayuki Nonami; 大成末満; Taisei Suemitsu; 祐一中井; Yuichi Nakai
Original assignee: Mitsubishi Electric Corp
Current assignee: Mitsubishi Electric Corp
Priority date: 2010-10-01
Filing date: 2017-11-13
Publication date: 2018-04-12
Anticipated expiration: 2031-09-27
Also published as: EP4274275A2; JP6633712B2; JPWO2012043523A1; WO2012043523A1; JP2022028872A; JP5955439B2; US20160198434A1; EP2624627A4; EP4274275A3; JP2016165156A; EP3654691A1; JP5784029B2; US20130182632A1; JP2023100781A; US20240064779A1; US12262396B2; JP7766764B2; JP2019017105A; EP2624627A1; JP2020039183A

Abstract

【課題】基地局の傘下に多数の端末群が存在する場合でも、多数の端末から、あるいは多数の端末へ同時にデータを通信する状況が生じたときのコアネットワークの混雑を緩和することができる通信システム等を提供する。【解決手段】通信システムは、端末がＭＴＣ装置であることを示すＭＴＣ情報を端末から受信する基地局、および、基地局とＳＧＳＮ／ＭＭＥとの間にその基地局を制御する基地局制御装置を有する。基地局は、ＭＴＣ装置を識別するＭＴＣ識別情報を基地局制御装置に通知する。基地局制御装置は、ＭＴＣ識別情報と共にページングメッセージを基地局に通知する。【選択図】図１３

Description

本発明は、複数の端末と基地局との間で無線通信を実施する通信システム、ならびに前記通信システムに含まれる基地局および基地局制御装置に関する。

第３世代と呼ばれる通信方式のうち、Ｗ−ＣＤＭＡ（Wideband Code division Multiple Access）方式が２００１年から日本で商用サービスが開始されている。また、下りリンク（個別データチャネル、個別制御チャネル）にパケット伝送用のチャネル（High Speed-Downlink Shared Channel：ＨＳ−ＤＳＣＨ）を追加することにより、下りリンクを用いたデータ送信の更なる高速化を実現するＨＳＤＰＡ（High Speed Downlink Packet Access）のサービスが開始されている。さらに、上り方向のデータ送信をより高速化するため、ＨＳＵＰＡ（High Speed Uplink Packet Access）方式についてもサービスが開始されている。Ｗ−ＣＤＭＡは、移動体通信システムの規格化団体である３ＧＰＰ（3rd Generation Partnership Project）により定められた通信方式であり、リリース８版の規格書がとりまとめられている。

また、３ＧＰＰにおいて、Ｗ−ＣＤＭＡとは別の通信方式として、無線区間についてはロングタームエボリューション（Long Term Evolution：ＬＴＥ）、コアネットワーク（単にネットワークとも称する）を含めたシステム全体構成については、システムアーキテクチャエボリューション（System Architecture Evolution：ＳＡＥ）と称される新たな通信方式が検討されている。この通信方式は３．９Ｇ（3.9 Generation）システムとも呼ばれる。

ＬＴＥでは、アクセス方式、無線のチャネル構成やプロトコルが、現在のＷ−ＣＤＭＡ（ＨＳＤＰＡ／ＨＳＵＰＡ）とは全く異なるものになる。例えば、アクセス方式は、Ｗ−ＣＤＭＡが符号分割多元接続（Code Division Multiple Access）を用いているのに対して、ＬＴＥは下り方向はＯＦＤＭ（Orthogonal Frequency Division Multiplexing）、上り方向はＳＣ−ＦＤＭＡ（Single Career Frequency Division Multiple Access）を用いる。また、帯域幅は、Ｗ−ＣＤＭＡが５ＭＨｚであるのに対し、ＬＴＥでは１．４ＭＨｚ，３ＭＨｚ，５ＭＨｚ，１０ＭＨｚ，１５ＭＨｚ，２０ＭＨｚの中で基地局毎に選択可能となっている。また、ＬＴＥでは、Ｗ−ＣＤＭＡのように回線交換を含まず、パケット通信方式のみになる。

ＬＴＥは、Ｗ−ＣＤＭＡのコアネットワーク（General Packet Radio Service：ＧＰＲＳ）とは異なる新たなコアネットワークを用いて通信システムが構成されるため、Ｗ−ＣＤＭＡ網とは別の独立した無線アクセス網として定義される。したがって、Ｗ−ＣＤＭＡの通信システムと区別するため、ＬＴＥの通信システムでは、移動端末（User Equipment：ＵＥ）と通信を行う基地局（Base station）はｅＮＢ（E-UTRAN NodeB）と称され、複数の基地局と制御データやユーザデータのやり取りを行う基地局制御装置（Radio Network Controller）は、ＥＰＣ（Evolved Packet Core）またはａＧＷ（Access Gateway）と称される。このＬＴＥの通信システムでは、ユニキャスト（Unicast）サービスとＥ-ＭＢＭＳサービス（Evolved Multimedia Broadcast Multicast Service）とが提供される。Ｅ−ＭＢＭＳサービスとは、放送型マルチメディアサービスであり、単にＭＢＭＳと称される場合もある。複数の移動端末に対してニュースや天気予報、モバイル放送などの大容量放送コンテンツが送信される。これを１対多（Point to Multipoint）サービスともいう。

３ＧＰＰでの、ＬＴＥシステムにおける全体的なアーキテクチャ（Architecture）に関する現在の決定事項が、非特許文献１（４．６．１章）に記載されている。全体的なアーキテクチャについて図１を用いて説明する。図１は、ＬＴＥ方式の通信システムの構成を示す説明図である。図１において、移動端末１０１に対する制御プロトコル、例えばＲＲＣ（Radio Resource Control）と、ユーザプレイン、例えばＰＤＣＰ（Packet Data Convergence Protocol）、ＲＬＣ（Radio Link Control）、ＭＡＣ（Medium Access Control）、ＰＨＹ（Physical layer）とが基地局１０２で終端するならば、Ｅ−ＵＴＲＡＮ（Evolved Universal Terrestrial Radio Access）は１つあるいは複数の基地局１０２によって構成される。

基地局１０２は、ＭＭＥ（Mobility Management Entity）１０３から通知されるページング信号（Paging Signaling、ページングメッセージ（paging messages）とも称される）のスケジューリング（Scheduling）および送信を行う。基地局１０２は、Ｘ２インタフェースにより、互いに接続される。また基地局１０２は、Ｓ１インタフェースによりＥＰＣ（Evolved Packet Core）に接続される。より明確には、基地局１０２は、Ｓ１＿ＭＭＥインタフェースによりＭＭＥ（Mobility Management Entity）１０３に接続され、Ｓ１＿ＵインタフェースによりＳ−ＧＷ（Serving Gateway）１０４に接続される。

ＭＭＥ１０３は、複数あるいは単数の基地局１０２へのページング信号の分配を行う。また、ＭＭＥ１０３は、待受け状態（Idle State）のモビリティ制御（Mobility control）を行う。ＭＭＥ１０３は、移動端末が待ち受け状態およびアクティブ状態（Active State）の際に、トラッキングエリア（Tracking Area）リストの管理を行う。

Ｓ−ＧＷ１０４は、ひとつまたは複数の基地局１０２とユーザデータの送受信を行う。Ｓ−ＧＷ１０４は、基地局間のハンドオーバの際、ローカルな移動性のアンカーポイント（Mobility Anchor Point）となる。ＥＰＣには、さらにＰ−ＧＷ（PDN Gateway）が存在し、ユーザ毎のパケットフィルタリングやＵＥ−ＩＤアドレスの割当などを行う。

移動端末１０１と基地局１０２との間の制御プロトコルＲＲＣは、報知（Broadcast）、ページング（paging）、ＲＲＣ接続マネージメント（RRC connection management）などを行う。ＲＲＣにおける基地局と移動端末の状態として、ＲＲＣ＿ＩＤＬＥ、ＲＲＣ＿ＣＯＮＮＥＣＴＥＤがある。ＲＲＣ＿ＩＤＬＥでは、ＰＬＭＮ（Public Land Mobile Network）選択、システム情報（System Information：ＳＩ）の報知、ページング（paging）、セル再選択（cell reselection）、モビリティ等が行われる。ＲＲＣ＿ＣＯＮＮＥＣＴＥＤでは、移動端末はＲＲＣ接続（connection）を有し、ネットワークとのデータの送受信を行うことができ、また、ハンドオーバ（Handover：ＨＯ）、隣接セル（Neighbour cell）のメジャメント等が行われる。

非特許文献１（５章）に記載される３ＧＰＰでの、ＬＴＥシステムにおけるフレーム構成に関する現在の決定事項について、図２を用いて説明する。図２は、ＬＴＥ方式の通信システムで使用される無線フレームの構成を示す説明図である。図２において、１つの無線フレーム（Radio frame）は１０ｍｓである。無線フレームは１０個の等しい大きさのサブフレーム（Sub-frame）に分割される。サブフレームは、２個の等しい大きさのスロット（slot）に分割される。無線フレーム毎に１番目と６番目のサブフレームに下り同期信号（Downlink Synchronization Signal：ＳＳ）が含まれる。同期信号には、第一同期信号（Primary Synchronization Signal：Ｐ−ＳＳ）と、第二同期信号（Secondary Synchronization Signal：Ｓ−ＳＳ）とがある。

サブフレーム単位にてＭＢＳＦＮ（Multimedia Broadcast multicast service Single Frequency Network）用とＭＢＳＦＮ以外のチャネルの多重が行われる。ＭＢＳＦＮ送信(MBSFN Transmission)とは、同時に複数のセルから同じ波形の送信により実現される同時放送送信技術(simulcast transmission technique)である。ＭＢＳＦＮ領域（MBSFN Area）の複数のセルからのＭＢＳＦＮ送信は、移動端末によって１つの送信であると見える。ＭＢＳＦＮとは、このようなＭＢＳＦＮ送信をサポートするネットワークである。以降、ＭＢＳＦＮ送信用のサブフレームをＭＢＳＦＮサブフレーム（MBSFN sub-frame）と称する。

非特許文献２に、ＭＢＳＦＮサブフレームの割り当て時のシグナリング例が記載されている。図３は、ＭＢＳＦＮフレームの構成を示す説明図である。図３において、ＭＢＳＦＮフレーム（MBSFN frame）毎にＭＢＳＦＮサブフレームが割り当てられる。ＭＢＳＦＮフレームは、割当周期（radio Frame Allocation Period）にて繰り返される。ＭＢＳＦＮサブフレームは、割当周期と割当オフセット（radio Frame Allocation Offset）によって定義された無線フレームにてＭＢＳＦＮのために割り当てられるサブフレームであり、マルチメディアデータを伝送するためのサブフレームである。以下の式（１）を満たす無線フレームが、ＭＢＳＦＮサブフレームを含む無線フレームである。

ＳＦＮｍｏｄ radioFrameAllocationPeriod＝radioFrameAllocationOffset …（１）
ＭＢＳＦＮサブフレームの割当は６ビットにて行われる。１番左のビットは、サブフレーム２番目（＃１）のＭＢＳＦＮ割当を定義する。２番目のビットはサブフレーム３番目（＃２）、３番目のビットはサブフレーム４番目（＃３）、４番目のビットはサブフレーム７番目（＃６）、５番目のビットはサブフレーム８番目（＃７）、６番目のビットはサブフレーム９番目（＃８）のＭＢＳＦＮ割当を定義する。該ビットが「１」を示す場合、対応するサブフレームがＭＢＳＦＮのために割当てられることを示す。

３ＧＰＰでの、ＬＴＥシステムにおけるチャネル構成に関する現在の決定事項が、非特許文献１（５章）に記載されている。ＣＳＧセル（Closed Subscriber Group cell）においてもｎｏｎ−ＣＳＧセルと同じチャネル構成が用いられると想定されている。物理チャネル（Physical channel）について、図４を用いて説明する。図４は、ＬＴＥ方式の通信システムで使用される物理チャネルを説明する説明図である。図４において、物理報知チャネル（Physical Broadcast channel：ＰＢＣＨ）４０１は、基地局１０２から移動端末１０１へ送信される下りチャネルである。ＢＣＨトランスポートブロック（transport block）は、４０ｍｓ間隔中の４個のサブフレームにマッピングされる。４０ｍｓタイミングの明白なシグナリングはない。物理制御チャネルフォーマットインジケータチャネル（Physical Control Format Indicator Channel：ＰＣＦＩＣＨ）４０２は、基地局１０２から移動端末１０１へ送信される。ＰＣＦＩＣＨは、ＰＤＣＣＨｓのために用いるＯＦＤＭシンボルの数について基地局１０２から移動端末１０１へ通知する。ＰＣＦＩＣＨは、サブフレーム毎に送信される。

物理下り制御チャネル（Physical Downlink Control Channel：ＰＤＣＣＨ）４０３は、基地局１０２から移動端末１０１へ送信される下りチャネルである。ＰＤＣＣＨは、リソース割り当て（allocation）、ＤＬ−ＳＣＨ（後述の図５に示されるトランスポートチャネルの１つである下り共有チャネル）に関するＨＡＲＱ（Hybrid Automatic Repeat reQuest）情報、ＰＣＨ（図５に示されるトランスポートチャネルの１つであるページングチャネル）を通知する。ＰＤＣＣＨは、上りスケジューリンググラント（Uplink Scheduling Grant）を運ぶ。ＰＤＣＣＨは、上り送信に対する応答信号であるＡｃｋ（Acknowledgement）／Ｎａｃｋ（Negative Acknowledgement）を運ぶ。ＰＤＣＣＨは、Ｌ１／Ｌ２制御信号とも呼ばれる。

物理下り共有チャネル（Physical Downlink Shared Channel：ＰＤＳＣＨ）４０４は、基地局１０２から移動端末１０１へ送信される下りチャネルである。ＰＤＳＣＨは、トランスポートチャネルであるＤＬ−ＳＣＨ（下り共有チャネル）やトランスポートチャネルであるＰＣＨがマッピングされている。物理マルチキャストチャネル（Physical Multicast Channel：ＰＭＣＨ）４０５は、基地局１０２から移動端末１０１へ送信される下りチャネルである。ＰＭＣＨは、トランスポートチャネルであるＭＣＨ（マルチキャストチャネル）がマッピングされている。

物理上り制御チャネル（Physical Uplink Control Channel：ＰＵＣＣＨ）４０６は、移動端末１０１から基地局１０２へ送信される上りチャネルである。ＰＵＣＣＨは、下り送信に対する応答信号（response）であるＡｃｋ／Ｎａｃｋを運ぶ。ＰＵＣＣＨは、ＣＱＩ（Channel Quality Indicator）レポートを運ぶ。ＣＱＩとは、受信したデータの品質、もしくは通信路品質を示す品質情報である。またＰＵＣＣＨは、スケジューリングリクエスト（Scheduling Request：ＳＲ）を運ぶ。物理上り共有チャネル（Physical Uplink Shared Channel：ＰＵＳＣＨ）４０７は、移動端末１０１から基地局１０２へ送信される上りチャネルである。ＰＵＳＣＨは、ＵＬ−ＳＣＨ（図５に示されるトランスポートチャネルの１つである上り共有チャネル）がマッピングされている。

物理ＨＡＲＱインジケータチャネル（Physical Hybrid ARQ Indicator Channel：ＰＨＩＣＨ）４０８は、基地局１０２から移動端末１０１へ送信される下りチャネルである。ＰＨＩＣＨは、上り送信に対する応答であるＡｃｋ／Ｎａｃｋを運ぶ。物理ランダムアクセスチャネル（Physical Random Access Channel：ＰＲＡＣＨ）４０９は、移動端末１０１から基地局１０２へ送信される上りチャネルである。ＰＲＡＣＨは、ランダムアクセスプリアンブル（random access preamble）を運ぶ。

下りリファレンスシグナル（Reference signal）は、移動体通信システムとして既知のシンボルである。移動端末の物理レイヤの測定として、リファレンスシンボルの受信電力（Reference Symbol Received Power：ＲＳＲＰ）がある。

非特許文献１（５章）に記載されるトランスポートチャネル（Transport channel）について、図５を用いて説明する。図５は、ＬＴＥ方式の通信システムで使用されるトランスポートチャネルを説明する説明図である。図５（Ａ）には、下りトランスポートチャネルと下り物理チャネルとの間のマッピングを示す。図５（Ｂ）には、上りトランスポートチャネルと上り物理チャネルとの間のマッピングを示す。

下りトランスポートチャネルについて報知チャネル（Broadcast Channel：ＢＣＨ）は、その基地局（セル）のカバレッジ全体に報知される。ＢＣＨは、物理報知チャネル（ＰＢＣＨ）にマッピングされる。

下り共有チャネル（Downlink Shared Channel：ＤＬ−ＳＣＨ）には、ＨＡＲＱ（Hybrid ARQ）による再送制御が適用される。ＤＬ−ＳＣＨは、基地局（セル）のカバレッジ全体への報知が可能である。ＤＬ−ＳＣＨは、ダイナミックあるいは準静的（Semi-static）なリソース割り当てをサポートする。準静的なリソース割り当ては、パーシステントスケジューリング（Persistent Scheduling）とも言われる。ＤＬ−ＳＣＨは、移動端末の低消費電力化のために移動端末のＤＲＸ（Discontinuous reception）をサポートする。ＤＬ−ＳＣＨは、物理下り共有チャネル（ＰＤＳＣＨ）へマッピングされる。

ページングチャネル（Paging Channel：ＰＣＨ）は、移動端末の低消費電力を可能とするために移動端末のＤＲＸをサポートする。ＰＣＨは、基地局（セル）のカバレッジ全体への報知が要求される。ＰＣＨは、動的にトラフィックに利用できる物理下り共有チャネル（ＰＤＳＣＨ）のような物理リソース、あるいは他の制御チャネルの物理下り制御チャネル（ＰＤＣＣＨ）のような物理リソースへマッピングされる。

マルチキャストチャネル（Multicast Channel：ＭＣＨ）は、基地局（セル）のカバレッジ全体への報知に使用される。ＭＣＨは、マルチセル送信におけるＭＢＭＳサービス（ＭＴＣＨとＭＣＣＨ）のＳＦＮ合成をサポートする。ＭＣＨは、準静的なリソース割り当てをサポートする。ＭＣＨは、ＰＭＣＨへマッピングされる。

上り共有チャネル（Uplink Shared Channel：ＵＬ−ＳＣＨ）には、ＨＡＲＱ（Hybrid ARQ）による再送制御が適用される。ＵＬ−ＳＣＨは、ダイナミックあるいは準静的（Semi-static）なリソース割り当てをサポートする。ＵＬ−ＳＣＨは、物理上り共有チャネル（ＰＵＳＣＨ）へマッピングされる。

図５（Ｂ）に示されるランダムアクセスチャネル（Random Access Channel：ＲＡＣＨ）は、制御情報に限られている。ＲＡＣＨは、衝突のリスクがある。ＲＡＣＨは、物理ランダムアクセスチャネル（ＰＲＡＣＨ）へマッピングされる。

ＨＡＲＱについて説明する。ＨＡＲＱとは、自動再送（Automatic Repeat reQuest：ＡＲＱ）と誤り訂正（Forward Error Correction）との組み合わせにより、伝送路の通信品質を向上させる技術である。通信品質が変化する伝送路に対しても、再送により誤り訂正が有効に機能するという利点がある。特に、再送にあたって初送の受信結果と再送の受信結果との合成をすることで、更なる品質向上を得ることも可能である。

再送の方法の一例を説明する。受信側にて、受信データが正しくデコードできなかった場合、換言すればＣＲＣ（Cyclic Redundancy Check）エラーが発生した場合（ＣＲＣ＝ＮＧ）、受信側から送信側へ「Ｎａｃｋ」を送信する。「Ｎａｃｋ」を受信した送信側は、データを再送する。受信側にて、受信データが正しくデコードできた場合、換言すればＣＲＣエラーが発生しない場合（ＣＲＣ＝ＯＫ）、受信側から送信側へ「Ａｃｋ」を送信する。「Ａｃｋ」を受信した送信側は次のデータを送信する。

ＨＡＲＱ方式の一例として、チェースコンバイニング（Chase Combining）がある。チェースコンバイニングとは、初送と再送に同じデータ系列を送信するもので、再送において初送のデータ系列と再送のデータ系列との合成を行うことで、利得を向上させる方式である。これは、初送データに誤りがあったとしても、部分的に正確なものも含まれており、正確な部分の初送データと再送データとを合成することで、より高精度にデータを送信できるという考え方に基づいている。また、ＨＡＲＱ方式の別の例として、ＩＲ（Incremental Redundancy）がある。ＩＲとは、冗長度を増加させるものであり、再送においてパリティビットを送信することで、初送と組み合わせて冗長度を増加させ、誤り訂正機能により品質を向上させるものである。

非特許文献１（６章）に記載される論理チャネル（ロジカルチャネル：Logical channel）について、図６を用いて説明する。図６は、ＬＴＥ方式の通信システムで使用される論理チャネルを説明する説明図である。図６（Ａ）には、下りロジカルチャネルと下りトランスポートチャネルとの間のマッピングを示す。図６（Ｂ）には、上りロジカルチャネルと上りトランスポートチャネルとの間のマッピングを示す。

報知制御チャネル（Broadcast Control Channel：ＢＣＣＨ）は、報知システム制御情報のための下りチャネルである。論理チャネルであるＢＣＣＨは、トランスポートチャネルである報知チャネル（ＢＣＨ）、あるいは下り共有チャネル（ＤＬ−ＳＣＨ）へマッピングされる。

ページング制御チャネル（Paging Control Channel：ＰＣＣＨ）は、ページング信号を送信するための下りチャネルである。ＰＣＣＨは、移動端末のセルロケーションをネットワークが知らない場合に用いられる。論理チャネルであるＰＣＣＨは、トランスポートチャネルであるページングチャネル（ＰＣＨ）へマッピングされる。

共有制御チャネル（Common Control Channel：ＣＣＣＨ）は、移動端末と基地局との間の送信制御情報のためのチャネルである。ＣＣＣＨは、移動端末がネットワークとの間でＲＲＣ接続（connection）を持っていない場合に用いられる。下り方向では、ＣＣＣＨは、トランスポートチャネルである下り共有チャネル（ＤＬ−ＳＣＨ）へマッピングされる。上り方向では、ＣＣＣＨは、トランスポートチャネルである上り共有チャネル（ＵＬ−ＳＣＨ）へマッピングされる。

マルチキャスト制御チャネル（Multicast Control Channel：ＭＣＣＨ）は、１対多の送信のための下りチャネルである。ネットワークから移動端末への１つあるいはいくつかのＭＴＣＨ用のＭＢＭＳ制御情報の送信のために用いられるチャネルである。ＭＣＣＨは、ＭＢＭＳ受信中の移動端末のみに用いられるチャネルである。ＭＣＣＨは、トランスポートチャネルである下り共有チャネル（ＤＬ−ＳＣＨ）あるいはマルチキャストチャネル（ＭＣＨ）へマッピングされる。

個別制御チャネル（Dedicated Control Channel：ＤＣＣＨ）は、移動端末とネットワークとの間の個別制御情報を送信するチャネルである。ＤＣＣＨは、上りでは上り共有チャネル（ＵＬ−ＳＣＨ）へマッピングされ、下りでは下り共有チャネル（ＤＬ−ＳＣＨ）にマッピングされる。

個別トラフィックチャネル（Dedicated Traffic Channel：ＤＴＣＨ）は、ユーザ情報の送信のための個別移動端末への１対１通信のチャネルである。ＤＴＣＨは、上りおよび下りともに存在する。ＤＴＣＨは、上りでは上り共有チャネル（ＵＬ−ＳＣＨ）へマッピングされ、下りでは下り共有チャネル（ＤＬ−ＳＣＨ）へマッピングされる。

マルチキャストトラフィックチャネル（Multicast Traffic channel：ＭＴＣＨ）は、ネットワークから移動端末へのトラフィックデータ送信のための下りチャネルである。ＭＴＣＨは、ＭＢＭＳ受信中の移動端末のみに用いられるチャネルである。ＭＴＣＨは、下り共有チャネル（ＤＬ−ＳＣＨ）あるいはマルチキャストチャネル（ＭＣＨ）へマッピングされる。

ＧＣＩとは、グローバルセル識別子（Global Cell Identity）のことである。ＬＴＥおよびＵＭＴＳ（Universal Mobile Telecommunication System）において、ＣＳＧセル（Closed Subscriber Group cell）が導入される。ＣＳＧについて以下に説明する（非特許文献３３．１章参照）。ＣＳＧ（Closed Subscriber Group）とは、利用可能な加入者をオペレータが特定しているセルである（特定加入者用セル）。

特定された加入者は、ＰＬＭＮ（Public Land Mobile Network）の１つ以上のＥ-ＵＴＲＡＮセルにアクセスすることが許可される。特定された加入者がアクセスを許可されている１つ以上のＥ−ＵＴＲＡＮセルを「ＣＳＧｃｅｌｌ（ｓ）」と呼ぶ。ただし、ＰＬＭＮにはアクセス制限がある。ＣＳＧセルとは、固有のＣＳＧアイデンティティ（CSG identity：ＣＳＧＩＤ；ＣＳＧ−ＩＤ）を報知するＰＬＭＮの一部である。予め利用登録し、許可された加入者グループのメンバーは、アクセス許可情報であるところのＣＳＧ−ＩＤを用いてＣＳＧセルにアクセスする。

ＣＳＧ−ＩＤは、ＣＳＧセルまたはセルによって報知される。移動体通信システムにＣＳＧ−ＩＤは複数存在する。そして、ＣＳＧ−ＩＤは、ＣＳＧ関連のメンバーのアクセスを容易にするために、移動端末（ＵＥ）によって使用される。

移動端末の位置追跡は、１つ以上のセルからなる区域を単位に行われる。位置追跡は、待受け状態であっても移動端末の位置を追跡し、呼び出す（移動端末が着呼する）ことを可能にするためである。この移動端末の位置追跡のための区域をトラッキングエリアと呼ぶ。

ＣＳＧホワイトリスト（CSG White List）とは、加入者が属するＣＳＧセルのすべてのＣＳＧＩＤが記録されている、ＵＳＩＭ（Universal Subscriber Identity Module）に格納されたリストである。ＣＳＧホワイトリストは、許可ＣＳＧリスト（Allowed CSG ID List）と呼ばれることもある。

「適切なセル」（Suitable cell）について以下に説明する（非特許文献３４．３章参照）。「適切なセル」（Suitable cell）とは、ＵＥが通常（normal）サービスを受けるためにキャンプオン（Camp ON）するセルである。そのようなセルは、以下の（１），（２）の条件を満たすものとする。

（１）セルは、選択されたＰＬＭＮもしくは登録されたＰＬＭＮ、または「ＥｑｕｉｖａｌｅｎｔＰＬＭＮリスト」のＰＬＭＮの一部であること。

（２）ＮＡＳ（Non-Access Stratum）によって提供された最新情報にて、さらに以下の（ａ）〜（ｄ）の条件を満たすこと
（ａ）そのセルが禁じられた（barred）セルでないこと
（ｂ）そのセルが「ローミングのための禁止されたＬＡｓ」リストの一部ではなく、少なくとも１つのトラッキングエリア（Tracking Area：ＴＡ）の一部であること。その場合、そのセルは前記（１）を満たす必要がある
（ｃ）そのセルが、セル選択評価基準を満たしていること
（ｄ）そのセルが、ＣＳＧセルとしてシステム情報（System Information：ＳＩ）によって特定されたセルに関しては、ＣＳＧ−ＩＤはＵＥの「ＣＳＧホワイトリスト」（CSG WhiteList）の一部であること（ＵＥのCSG WhiteList中に含まれること）。

「アクセプタブルセル」（Acceptable cell）について以下に説明する（非特許文献３４．３章参照）。これは、ＵＥが限られたサービス（緊急通報）を受けるためにキャンプオンするセルである。そのようなセルは、以下のすべての要件を充足するものとする。つまり、Ｅ−ＵＴＲＡＮネットワークで緊急通報を開始するための最小のセットの要件を以下に示す。（１）そのセルが禁じられた（barred）セルでないこと。（２）そのセルが、セル選択評価基準を満たしていること。

セルにキャンプオン（camp on）するとは、ＵＥがセル選択／再選択（cell selection/reselection）処理を完了し、ＵＥがシステム情報とページング情報をモニタするセルを選択した状態である。

３ＧＰＰにおいて、Ｈｏｍｅ−ＮｏｄｅＢ（Ｈｏｍｅ−ＮＢ；ＨＮＢ）、Ｈｏｍｅ−ｅＮｏｄｅＢ（Ｈｏｍｅ−ｅＮＢ；ＨｅＮＢ）と称される基地局が検討されている。ＵＴＲＡＮにおけるＨＮＢ、またはＥ-ＵＴＲＡＮにおけるＨｅＮＢは、例えば家庭、法人、商業用のアクセスサービス向けの基地局である。非特許文献４には、ＨｅＮＢおよびＨＮＢへのアクセスの３つの異なるモードが開示されている。具体的には、オープンアクセスモード（Open access mode）と、クローズドアクセスモード（Closed access mode）と、ハイブリッドアクセスモード（Hybrid access mode）である。

各々のモードは、以下のような特徴を有する。オープンアクセスモードでは、ＨｅＮＢやＨＮＢは通常のオペレータのノーマルセルとして操作される。クローズドアクセスモードでは、ＨｅＮＢやＨＮＢがＣＳＧセルとして操作される。これはＣＳＧメンバーのみアクセス可能なＣＳＧセルである。ハイブリッドアクセスモードでは、非ＣＳＧメンバーも同時にアクセス許可されているＣＳＧセルである。ハイブリッドアクセスモードのセル（ハイブリッドセルとも称する）は、言い換えれば、オープンアクセスモードとクローズドアクセスモードの両方をサポートするセルである。

３ＧＰＰでは、全ＰＣＩ（Physical Cell Identity）を、ＣＳＧセル用とｎｏｎ−ＣＳＧセル用とに分割（ＰＣＩスプリットと称する）することが議論されている（非特許文献５参照）。またＰＣＩスプリット情報は、システム情報にて基地局から傘下の移動端末に対して報知されることが議論されている。ＰＣＩスプリットを用いた移動端末の基本動作を開示する。ＰＣＩスプリット情報を有していない移動端末は、全ＰＣＩを用いて（例えば５０４コード全てを用いて）セルサーチを行う必要がある。これに対して、ＰＣＩスプリット情報を有する移動端末は、当該ＰＣＩスプリット情報を用いてセルサーチを行うことが可能である。

また３ＧＰＰでは、リリース１０として、ロングタームエボリューションアドヴァンスド（Long Term Evolution Advanced：ＬＴＥ−Ａ）の規格策定が進められている（非特許文献６、非特許文献７参照）。

ＬＴＥ−Ａシステムでは、高い通信速度、セルエッジでの高いスループット、新たなカバレッジエリアなどを得るために、リレー（Relay：リレーノード（ＲＮ））をサポートすることが検討されている。リレーノードは、ドナーセル（Donor cell；Donor eNB；ＤｅＮＢ）を介して無線アクセスネットワークに無線で接続される。ドナーセルの範囲内で、ネットワーク（Network：ＮＷ）からリレーへのリンクは、ネットワークからＵＥへのリンクと同じ周波数バンドを共用する。この場合、リリース８のＵＥも該ドナーセルに接続することを可能とする。ドナーセルとリレーノードとの間のリンクをバックホールリンク（backhaul link）と称し、リレーノードとＵＥとの間のリンクをアクセスリンク（access link）と称す。

ＦＤＤ（Frequency Division Duplex）におけるバックホールリンクの多重方法として、ＤｅＮＢからＲＮへの送信は下り（ＤＬ）周波数バンドで行われ、ＲＮからＤｅＮＢへの送信は上り（ＵＬ）周波数バンドで行われる。リレーにおけるリソースの分割方法として、ＤｅＮＢからＲＮへのリンクおよびＲＮからＵＥへのリンクが一つの周波数バンドで時分割多重され、ＲＮからＤｅＮＢへのリンクおよびＵＥからＲＮへのリンクも一つの周波数バンドで時分割多重される。こうすることで、リレーにおいて、リレーの送信が自リレーの受信へ干渉することを防ぐことができる。

３ＧＰＰでは、通常のｅＮＢ（マクロセル）だけでなく、ピコｅＮＢ（ピコセル（pico cell））、ＨｅＮＢ／ＨＮＢ／ＣＳＧセル、ホットゾーンセル用のノード、リレーノード、リモートラジオヘッド（Remote Radio Head：ＲＲＨ）などのいわゆるローカルノードが検討されている。

これらローカルノードは、高速、大容量の通信などのさまざまなサービスの要求に応じて、マクロセルを補完するために配置される。例えば、ＨｅＮＢは、商店街やマンション、学校、会社などへ数多く設置されることが要求される。このため、ＨｅＮＢがマクロセルのカバレッジ内に設置される場合も生じる。ＨｅＮＢがマクロセルのカバレッジ内に設置されるような場合、マクロセル、ＨｅＮＢ、移動端末（ＵＥ）らの間で干渉が生じることとなる。これらの干渉により、移動端末（ＵＥ）は、マクロセルあるいはＨｅＮＢとの通信が妨げられ、通信速度の低下が生じる。さらに干渉電力が大きくなると、通信ができなくなってしまうことになる。したがって、これらのマクロセルとローカルノードとが混在して配置される状況において生じる干渉を回避し、通信品質を最適にするための方法が要求される。

３ＧＰＰにおいて、マシンタイプコミュニケーション（Machine Type Communication：ＭＴＣ）技術の検討が進められている（非特許文献８参照）。ＭＴＣ用のデバイス（MTC Device：ＭＴＣＤ）の数は、膨大であることが予想されている。ＭＴＣサービスでは、多数のＭＴＣＤから、あるいは多数のＭＴＣＤへ同時にデータを通信する状況が生じる。これによって、コアネットワーク（Core Network）において混雑状態が生じるという問題が発生する。

このような問題を解決するために、非特許文献９には、ｅＮＢが、同じＭＴＣＤグループのＭＴＣＤに共通のシグナリングメッセージを引き止め（hold back）、寄せ集める（aggregation）ことで、シグナリングメッセージをコンパクトにすることが開示されている。

３ＧＰＰＴＳ３６．３００Ｖ１０．０．０４．６．１章、４．６．２章、５章、６章、１０．１．２章、１０．７章３ＧＰＰＴＳ３６．３３１Ｖ９．３．０３ＧＰＰＴＳ３６．３０４Ｖ９．３．０３．１章、４．３章、５．２．４章３ＧＰＰＳ１−０８３４６１３ＧＰＰＲ２−０８２８９９３ＧＰＰＴＲ３６．８１４Ｖ９．０．０３ＧＰＰＴＲ３６．９１２Ｖ９.０.０３ＧＰＰＴＳ２２．３６８Ｖ２．０．０３ＧＰＰＳ２−１０３１８６

前述のように、非特許文献９には、ｅＮＢが、同じＭＴＣＤグループのＭＴＣＤに共通のシグナリングメッセージを引き止め（hold back）、寄せ集める（aggregation）ことで、シグナリングメッセージをコンパクトにすることが開示されている。

しかし、ｅＮＢの傘下に多くのＭＴＣＤグループが存在する場合には、非特許文献９に開示されている方法を用いたとしても、前述のコアネットワークにおいて混雑状態が生じるという問題が再発する。

本発明の目的は、ｅＮＢの傘下に多くのＭＴＣＤグループが存在する場合でも、多数のＭＴＣＤから、あるいは多数のＭＴＣＤへ同時にデータを通信する状況が生じたときのコアネットワークの混雑状態を緩和することができる通信システム等を提供することである。

本発明の通信システムは、端末がＭＴＣ装置であることを示すＭＴＣ情報を前記端末から受信する基地局およびその基地局を制御する基地局制御装置を有する通信システムであって、前記基地局は、前記ＭＴＣ装置を識別するＭＴＣ識別情報を前記基地局制御装置に通知し、前記基地局制御装置は、前記ＭＴＣ識別情報と共にページングメッセージを前記基地局に通知することを特徴とする。

本発明の基地局は、端末がＭＴＣ装置であることを示すＭＴＣ情報を前記端末から受信する基地局であって、前記ＭＴＣ装置を識別するＭＴＣ識別情報を前記基地局制御装置に通知し、前記ＭＴＣ識別情報と共にページングメッセージを前記基地局制御装置から受信することを特徴とする。

本発明の基地局制御装置は、端末がＭＴＣ装置であることを示すＭＴＣ情報を前記端末から受信する基地局を制御する基地局制御装置であって、前記ＭＴＣ装置を識別するＭＴＣ識別情報を前記基地局から受信し、前記ＭＴＣ識別情報と共にページングメッセージを前記基地局に通知することを特徴とする。

本発明の通信システムによれば、基地局の傘下に多数の端末群が存在する場合でも、これらに含まれる多数の端末との間でデータを通信する状況が生じたときのコアネットワークの混雑を緩和することができる。

本発明の基地局によれば、基地局の傘下に多数の端末群が存在する場合でも、これらに含まれる多数の端末との間でデータを通信する状況が生じたときのコアネットワークの混雑を緩和することができる。

本発明の基地局制御装置によれば、基地局の傘下に多数の端末群が存在する場合でも、これらに含まれる多数の端末との間でデータを通信する状況が生じたときのコアネットワークの混雑を緩和することができる。

この発明の目的、特徴、局面、および利点は、以下の詳細な説明と添付図面とによって、より明白となる。

ＬＴＥ方式の通信システムの構成を示す説明図である。ＬＴＥ方式の通信システムで使用される無線フレームの構成を示す説明図である。ＭＢＳＦＮフレームの構成を示す説明図である。ＬＴＥ方式の通信システムで使用される物理チャネルを説明する説明図である。ＬＴＥ方式の通信システムで使用されるトランスポートチャネルを説明する説明図である。ＬＴＥ方式の通信システムで使用される論理チャネルを説明する説明図である。現在３ＧＰＰにおいて議論されているＬＴＥ方式の移動体通信システムの全体的な構成を示すブロック図である。本発明に係る移動端末（図７の移動端末７１）の構成を示すブロック図である。本発明に係る基地局（図７の基地局７２）の構成を示すブロック図である。本発明に係るＭＭＥ（図７のＭＭＥ部７３）の構成を示すブロック図である。本発明に係るＨｅＮＢＧＷである図７に示すＨｅＮＢＧＷ７４の構成を示すブロック図である。ＬＴＥ方式の通信システムにおいて移動端末（ＵＥ）が行うセルサーチから待ち受け動作までの概略を示すフローチャートである。３ＧＰＰで検討されているＭＴＣのアーキテクチャの一例を示す説明図である。従来の技術におけるＵＥ−ＭＭＥ間の制御データのプロトコルスタックを示す図である。実施の形態１におけるＭＴＣＤ−ＭＭＥ間の制御データのプロトコルスタックを示す図である。実施の形態１における集線処理に関するＨｅＮＢの処理手順を示すフローチャート図である。実施の形態１における移動体通信システムのシーケンスを示す図である。実施の形態１の変形例１における集線処理に関するＨｅＮＢの処理手順を示すフローチャート移動体通信システムのシーケンスである。実施の形態１の変形例２における移動体通信システムのシーケンスを示す図である。実施の形態１の変形例３における移動体通信システムのシーケンスを示す図である。実施の形態１の変形例４における移動体通信システムのシーケンスを示す図である。実施の形態２における移動体通信システムのシーケンスを示す図である。実施の形態２における移動体通信システムのシーケンスを示す図である。実施の形態２の変形例１における移動体通信システムのシーケンスを示す図である。実施の形態２の変形例３における移動体通信システムのシーケンスを示す図である。実施の形態３における移動体通信システムのシーケンスを示す図である。実施の形態４における移動体通信システムのシーケンスを示す図である。実施の形態５における移動体通信システムのシーケンスを示す図である。実施の形態５における移動体通信システムのシーケンスを示す図である。現行のページング方法を説明するためのロケーションを示す図における移動体通信システムのシーケンスである。実施の形態３を実行した場合の無線リソースの無駄を説明するための移動体通信システムのシーケンスを示す図である。実施の形態３を実行した場合の無線リソースの無駄を説明するための移動体通信システムのシーケンスを示す図である。実施の形態４を実行した場合の無線リソースの無駄を説明するための移動体通信システムのシーケンスを示す図である。実施の形態４を実行した場合の無線リソースの無駄を説明するための移動体通信システムのシーケンスを示す図である。実施の形態７における移動体通信システムのシーケンスを示す図である。実施の形態７における移動体通信システムのシーケンスを示す図である。実施の形態７における移動体通信システムの他のシーケンスを示す図である。実施の形態７における移動体通信システムの他のシーケンスを示す図である。実施の形態７における移動体通信システムの他のシーケンスを示す図である。実施の形態７における移動体通信システムの他のシーケンスを示す図である。実施の形態７における移動体通信システムの他のシーケンスを示す図である。実施の形態７における移動体通信システムの他のシーケンスを示す図である。実施の形態７の変形例１における移動体通信システムのシーケンスを示す図である。実施の形態７の変形例１における移動体通信システムのシーケンスを示す図である。

実施の形態１．
図７は、現在３ＧＰＰにおいて議論されているＬＴＥ方式の移動体通信システムの全体的な構成を示すブロック図である。現在３ＧＰＰにおいては、ＣＳＧ（Closed Subscriber Group）セル（Ｅ−ＵＴＲＡＮのＨｏｍｅ−ｅＮｏｄｅＢ（Ｈｏｍｅ−ｅＮＢ；ＨｅＮＢ）、ＵＴＲＡＮのＨｏｍｅ−ＮＢ（ＨＮＢ））と、ｎｏｎ−ＣＳＧセル（Ｅ−ＵＴＲＡＮのｅＮｏｄｅＢ（ｅＮＢ）、ＵＴＲＡＮのＮｏｄｅＢ（ＮＢ）、ＧＥＲＡＮのＢＳＳ）とを含めたシステムの全体的な構成が検討されており、Ｅ−ＵＴＲＡＮについては、図７のような構成が提案されている（非特許文献１４．６．１.章参照）。

図７について説明する。移動端末装置（以下「移動端末」または「User Equipment（ＵＥ）」という）７１は、基地局装置（以下「基地局」という）７２と無線通信可能であり、無線通信で信号の送受信を行う。移動端末装置は、通信端末装置に相当する。以下、移動端末装置を「通信端末」という場合がある。基地局７２は、マクロセルであるｅＮＢ７２−１と、ローカルノードであるＨｏｍｅ−ｅＮＢ７２−２とに分類される。ｅＮＢ７２−１は、大規模基地局装置に相当し、移動端末ＵＥ７１と通信可能な範囲であるカバレッジとして、比較的大きい大規模カバレッジを有する。Ｈｏｍｅ−ｅＮＢ７２−２は、小規模基地局装置に相当し、カバレッジとして、比較的小さい小規模カバレッジを有する。

ｅＮＢ７２−１は、ＭＭＥ、あるいはＳ−ＧＷ、あるいはＭＭＥおよびＳ−ＧＷを含むＭＭＥ／Ｓ−ＧＷ部（以下「ＭＭＥ部」という場合がある）７３とＳ１インタフェースにより接続され、ｅＮＢ７２−１とＭＭＥ部７３との間で制御情報が通信される。ひとつのｅＮＢ７２−１に対して、複数のＭＭＥ部７３が接続されてもよい。ｅＮＢ７２−１間は、Ｘ２インタフェースにより接続され、ｅＮＢ７２−１間で制御情報が通信される。

Ｈｏｍｅ−ｅＮＢ７２−２は、ＭＭＥ部７３とＳ１インタフェースにより接続され、Ｈｏｍｅ−ｅＮＢ７２−２とＭＭＥ部７３との間で制御情報が通信される。ひとつのＭＭＥ部７３に対して、複数のＨｏｍｅ−ｅＮＢ７２−２が接続される。あるいは、Ｈｏｍｅ−ｅＮＢ７２−２は、ＨｅＮＢＧＷ（Home-eNB GateWay）７４を介してＭＭＥ部７３と接続される。Ｈｏｍｅ−ｅＮＢ７２−２とＨｅＮＢＧＷ７４とは、Ｓ１インタフェースにより接続され、ＨｅＮＢＧＷ７４とＭＭＥ部７３とはＳ１インタフェースを介して接続される。ひとつまたは複数のＨｏｍｅ−ｅＮＢ７２−２がひとつのＨｅＮＢＧＷ７４と接続され、Ｓ１インタフェースを通して情報が通信される。ＨｅＮＢＧＷ７４は、ひとつまたは複数のＭＭＥ部７３と接続され、Ｓ１インタフェースを通して情報が通信される。

さらに現在３ＧＰＰでは、以下のような構成が検討されている。Ｈｏｍｅ−ｅＮＢ７２−２間のＸ２インタフェースはサポートされない。ＭＭＥ部７３からは、ＨｅＮＢＧＷ７４はｅＮＢ７２−１として見える。Ｈｏｍｅ−ｅＮＢ７２−２からは、ＨｅＮＢＧＷ７４はＭＭＥ部７３として見える。Ｈｏｍｅ−ｅＮＢ７２−２が、ＨｅＮＢＧＷ７４を介してＭＭＥ部７３に接続されるか否かに関係なく、Ｈｏｍｅ−ｅＮＢ７２−２とＭＭＥ部７３との間のインタフェースは、Ｓ１インタフェースで同じである。複数のＭＭＥ部７３にまたがるような、Ｈｏｍｅ−ｅＮＢ７２−２へのモビリティ、あるいはＨｏｍｅ−ｅＮＢ７２−２からのモビリティはサポートされない。Ｈｏｍｅ−ｅＮＢ７２−２は、唯一のセルをサポートする。

図８は、本発明に係る移動端末（図７の移動端末７１）の構成を示すブロック図である。図８に示す移動端末７１の送信処理を説明する。まず、プロトコル処理部８０１からの制御データ、およびアプリケーション部８０２からのユーザデータが、送信データバッファ部８０３へ保存される。送信データバッファ部８０３に保存されたデータは、エンコーダー部８０４へ渡され、誤り訂正などのエンコード処理が施される。エンコード処理を施さずに、送信データバッファ部８０３から変調部８０５へ直接出力されるデータが存在してもよい。エンコーダー部８０４でエンコード処理されたデータは、変調部８０５にて変調処理が行われる。変調されたデータは、ベースバンド信号に変換された後、周波数変換部８０６へ出力され、無線送信周波数に変換される。その後、アンテナ８０７から基地局７２に送信信号が送信される。

また、移動端末７１の受信処理は、以下のとおりに実行される。基地局７２からの無線信号がアンテナ８０７により受信される。受信信号は、周波数変換部８０６にて無線受信周波数からベースバンド信号に変換され、復調部８０８において復調処理が行われる。復調後のデータは、デコーダー部８０９へ渡され、誤り訂正などのデコード処理が行われる。デコードされたデータのうち、制御データはプロトコル処理部８０１へ渡され、ユーザデータはアプリケーション部８０２へ渡される。移動端末７１の一連の処理は、制御部８１０によって制御される。よって制御部８１０は、図８では省略しているが、各部８０１〜８０９と接続している。

図９は、本発明に係る基地局（図７の基地局７２）の構成を示すブロック図である。図９に示す基地局７２の送信処理を説明する。ＥＰＣ通信部９０１は、基地局７２とＥＰＣ（ＭＭＥ部７３、ＨｅＮＢＧＷ７４など）との間のデータの送受信を行う。他基地局通信部９０２は、他の基地局との間のデータの送受信を行う。Ｈｏｍｅ−ｅＮＢ７２−２間のＸ２インタフェースはサポートされない方向であるため、Ｈｏｍｅ−ｅＮＢ７２−２では、他基地局通信部９０２が存在しないことも考えられる。ＥＰＣ通信部９０１および他基地局通信部９０２は、それぞれプロトコル処理部９０３と情報の受け渡しを行う。プロトコル処理部９０３からの制御データ、ならびにＥＰＣ通信部９０１および他基地局通信部９０２からのユーザデータおよび制御データは、送信データバッファ部９０４へ保存される。

送信データバッファ部９０４に保存されたデータは、エンコーダー部９０５へ渡され、誤り訂正などのエンコード処理が施される。エンコード処理を施さずに、送信データバッファ部９０４から変調部９０６へ直接出力されるデータが存在してもよい。エンコードされたデータは、変調部９０６にて変調処理が行われる。変調されたデータは、ベースバンド信号に変換された後、周波数変換部９０７へ出力され、無線送信周波数に変換される。その後、アンテナ９０８より一つもしくは複数の移動端末７１に対して送信信号が送信される。

また、基地局７２の受信処理は以下のとおりに実行される。ひとつもしくは複数の移動端末７１からの無線信号が、アンテナ９０８により受信される。受信信号は、周波数変換部９０７にて無線受信周波数からベースバンド信号に変換され、復調部９０９で復調処理が行われる。復調されたデータは、デコーダー部９１０へ渡され、誤り訂正などのデコード処理が行われる。デコードされたデータのうち、制御データはプロトコル処理部９０３あるいはＥＰＣ通信部９０１、他基地局通信部９０２へ渡され、ユーザデータはＥＰＣ通信部９０１および他基地局通信部９０２へ渡される。基地局７２の一連の処理は、制御部９１１によって制御される。よって制御部９１１は、図９では省略しているが、各部９０１〜９１０と接続している。

現在３ＧＰＰにおいて議論されているＨｏｍｅ−ｅＮＢ７２−２の機能を以下に示す（非特許文献１４．６．２章参照）。Ｈｏｍｅ−ｅＮＢ７２−２は、ｅＮＢ７２−１と同じ機能を有する。加えて、ＨｅＮＢＧＷ７４と接続する場合、Ｈｏｍｅ−ｅＮＢ７２−２は、適当なサービングＨｅＮＢＧＷ７４を発見する機能を有する。Ｈｏｍｅ−ｅＮＢ７２−２は、１つのＨｅＮＢＧＷ７４に唯一接続する。つまり、ＨｅＮＢＧＷ７４との接続の場合は、Ｈｏｍｅ−ｅＮＢ７２−２は、Ｓ１インタフェースにおけるＦｌｅｘ機能を使用しない。Ｈｏｍｅ−ｅＮＢ７２−２は、１つのＨｅＮＢＧＷ７４に接続されると、同時に別のＨｅＮＢＧＷ７４や別のＭＭＥ部７３に接続しない。

Ｈｏｍｅ−ｅＮＢ７２−２のＴＡＣとＰＬＭＮＩＤは、ＨｅＮＢＧＷ７４によってサポートされる。Ｈｏｍｅ−ｅＮＢ７２−２をＨｅＮＢＧＷ７４に接続すると、「ＵＥａｔｔａｃｈｍｅｎｔ」でのＭＭＥ部７３の選択は、Ｈｏｍｅ−ｅＮＢ７２−２の代わりに、ＨｅＮＢＧＷ７４によって行われる。Ｈｏｍｅ−ｅＮＢ７２−２は、ネットワーク計画なしで配備される可能性がある。この場合、Ｈｏｍｅ−ｅＮＢ７２−２は、１つの地理的な領域から別の地理的な領域へ移される。したがって、この場合のＨｏｍｅ−ｅＮＢ７２−２は、位置によって、異なったＨｅＮＢＧＷ７４に接続する必要がある。

図１０は、本発明に係るＭＭＥの構成を示すブロック図である。図１０では、前述の図７に示すＭＭＥ部７３に含まれるＭＭＥ７３ａの構成を示す。ＰＤＮＧＷ通信部１００１は、ＭＭＥ７３ａとＰＤＮＧＷとの間のデータの送受信を行う。基地局通信部１００２は、ＭＭＥ７３ａと基地局７２との間のＳ１インタフェースによるデータの送受信を行う。ＰＤＮＧＷから受信したデータがユーザデータであった場合、ユーザデータは、ＰＤＮＧＷ通信部１００１から、ユーザプレイン通信部１００３経由で基地局通信部１００２に渡され、１つあるいは複数の基地局７２へ送信される。基地局７２から受信したデータがユーザデータであった場合、ユーザデータは、基地局通信部１００２から、ユーザプレイン通信部１００３経由でＰＤＮＧＷ通信部１００１に渡され、ＰＤＮＧＷへ送信される。

ＰＤＮＧＷから受信したデータが制御データであった場合、制御データは、ＰＤＮＧＷ通信部１００１から制御プレイン制御部１００５へ渡される。基地局７２から受信したデータが制御データであった場合、制御データは、基地局通信部１００２から制御プレイン制御部１００５へ渡される。

ＨｅＮＢＧＷ通信部１００４は、ＨｅＮＢＧＷ７４が存在する場合に設けられ、情報種別によって、ＭＭＥ７３ａとＨｅＮＢＧＷ７４との間のインタフェース（ＩＦ）によるデータの送受信を行う。ＨｅＮＢＧＷ通信部１００４から受信した制御データは、ＨｅＮＢＧＷ通信部１００４から制御プレイン制御部１００５へ渡される。制御プレイン制御部１００５での処理の結果は、ＰＤＮＧＷ通信部１００１経由でＰＤＮＧＷへ送信される。また、制御プレイン制御部１００５で処理された結果は、基地局通信部１００２経由でＳ１インタフェースにより１つあるいは複数の基地局７２へ送信され、またＨｅＮＢＧＷ通信部１００４経由で１つあるいは複数のＨｅＮＢＧＷ７４へ送信される。

制御プレイン制御部１００５には、ＮＡＳセキュリティ部１００５−１、ＳＡＥベアラコントロール部１００５−２、アイドルステート（Idle State）モビリティ管理部１００５―３などが含まれ、制御プレインに対する処理全般を行う。ＮＡＳセキュリティ部１００５―１は、ＮＡＳ（Non-Access Stratum）メッセージのセキュリティなどを行う。ＳＡＥベアラコントロール部１００５―２は、ＳＡＥ（System Architecture Evolution）のベアラの管理などを行う。アイドルステートモビリティ管理部１００５―３は、待受け状態（ＬＴＥ−ＩＤＬＥ状態、単にアイドルとも称される）のモビリティ管理、待受け状態時のページング信号の生成および制御、傘下の１つあるいは複数の移動端末７１のトラッキングエリア（ＴＡ）の追加、削除、更新、検索、トラッキングエリアリスト（TA List）管理などを行う。

ＭＭＥ７３ａは、ＵＥが登録されている（registered）追跡領域（トラッキングエリア：Tracking Area：ＴＡ）に属するセルへ、ページングメッセージを送信することで、ページングプロトコルに着手する。ＭＭＥ７３ａに接続されるＨｏｍｅ−ｅＮＢ７２−２のＣＳＧの管理やＣＳＧ−ＩＤの管理、そしてホワイトリスト管理は、アイドルステートモビリティ管理部１００５―３で行ってもよい。

ＣＳＧ−ＩＤの管理では、ＣＳＧ−ＩＤに対応する移動端末とＣＳＧセルとの関係が管理（追加、削除、更新、検索）される。例えば、あるＣＳＧ−ＩＤにユーザアクセス登録された一つまたは複数の移動端末と該ＣＳＧ−ＩＤに属するＣＳＧセルとの関係であってもよい。ホワイトリスト管理では、移動端末とＣＳＧ−ＩＤとの関係が管理（追加、削除、更新、検索）される。例えば、ホワイトリストには、ある移動端末がユーザ登録した一つまたは複数のＣＳＧ−ＩＤが記憶されてもよい。これらのＣＳＧに関する管理は、ＭＭＥ７３ａの中の他の部分で行われてもよい。ＭＭＥ７３ａの一連の処理は、制御部１００６によって制御される。よって制御部１００６は、図１０では省略しているが、各部１００１〜１００５と接続している。

現在３ＧＰＰにおいて議論されているＭＭＥ７３ａの機能を以下に示す（非特許文献１４．６．２章参照）。ＭＭＥ７３ａは、ＣＳＧ（Closed Subscriber Groups）のメンバーの１つ、あるいは複数の移動端末のアクセスコントロールを行う。ＭＭＥ７３ａは、ページングの最適化（Paging optimization）の実行をオプションとして認める。

図１１は、本発明に係るＨｅＮＢＧＷである図７に示すＨｅＮＢＧＷ７４の構成を示すブロック図である。ＥＰＣ通信部１１０１は、ＨｅＮＢＧＷ７４とＭＭＥ７３ａとの間のＳ１インタフェースによるデータの送受信を行う。基地局通信部１１０２は、ＨｅＮＢＧＷ７４とＨｏｍｅ−ｅＮＢ７２−２との間のＳ１インタフェースによるデータの送受信を行う。ロケーション処理部１１０３は、ＥＰＣ通信部１１０１経由で渡されたＭＭＥ７３ａからのデータのうちレジストレーション情報などを、複数のＨｏｍｅ−ｅＮＢ７２−２に送信する処理を行う。ロケーション処理部１１０３で処理されたデータは、基地局通信部１１０２に渡され、ひとつまたは複数のＨｏｍｅ−ｅＮＢ７２−２にＳ１インタフェースを介して送信される。

ロケーション処理部１１０３での処理を必要とせず通過（透過）させるだけのデータは、ＥＰＣ通信部１１０１から基地局通信部１１０２に渡され、ひとつまたは複数のＨｏｍｅ−ｅＮＢ７２−２にＳ１インタフェースを介して送信される。ＨｅＮＢＧＷ７４の一連の処理は、制御部１１０４によって制御される。よって制御部１１０４は、図１１では省略しているが、各部１１０１〜１１０３と接続している。

現在３ＧＰＰにおいて議論されているＨｅＮＢＧＷ７４の機能を以下に示す（非特許文献１４．６．２章参照）。ＨｅＮＢＧＷ７４は、Ｓ１アプリケーションについてリレーする。Ｈｏｍｅ−ｅＮＢ７２−２へのＭＭＥ７３ａの手順の一部分であるが、ＨｅＮＢＧＷ７４は、移動端末７１に関係しないＳ１アプリケーションについて終端する。ＨｅＮＢＧＷ７４が配置されるとき、移動端末７１に無関係な手順がＨｏｍｅ−ｅＮＢ７２−２とＨｅＮＢＧＷ７４との間、そしてＨｅＮＢＧＷ７４とＭＭＥ７３ａとの間を通信される。ＨｅＮＢＧＷ７４と他のノードとの間でＸ２インタフェースは設定されない。ＨｅＮＢＧＷ７４は、ページングの最適化（Paging optimization）の実行をオプションとして認める。

次に移動体通信システムにおける一般的なセルサーチ方法の一例を示す。図１２は、ＬＴＥ方式の通信システムにおいて移動端末（ＵＥ）が行うセルサーチから待ち受け動作までの概略を示すフローチャートである。移動端末は、セルサーチを開始すると、ステップＳＴ１２０１で、周辺の基地局から送信される第一同期信号（Ｐ−ＳＳ）、および第二同期信号（Ｓ−ＳＳ）を用いて、スロットタイミング、フレームタイミングの同期をとる。Ｐ−ＳＳとＳ−ＳＳとを合わせて、同期信号（ＳＳ）には、セル毎に割り当てられたＰＣＩ（Physical Cell Identity）に１対１に対応するシンクロナイゼーションコードが割り当てられている。ＰＣＩの数は現在５０４通りが検討されており、この５０４通りのＰＣＩを用いて同期をとるとともに、同期がとれたセルのＰＣＩを検出（特定）する。

次に同期がとれたセルに対して、ステップＳＴ１２０２で、基地局からセル毎に送信される参照信号ＲＳ（cell-specific Reference Signal：ＣＲＳ）を検出し受信電力（RSRPとも称される。）の測定を行う。参照信号ＲＳには、ＰＣＩと１対１に対応したコードが用いられており、そのコードで相関をとることによって他セルと分離できる。ステップＳＴ１２０１で特定したＰＣＩから、該セルのＲＳ用のコードを導出することによって、ＲＳを検出し、ＲＳ受信電力を測定することが可能となる。

次にステップＳＴ１２０３で、ステップＳＴ１２０２までで検出されたひとつ以上のセルの中から、ＲＳの受信品質が最もよいセル（例えば、ＲＳの受信電力が最も高いセル、つまりベストセル）を選択する。

次にステップＳＴ１２０４で、ベストセルのＰＢＣＨを受信して、報知情報であるＢＣＣＨを得る。ＰＢＣＨ上のＢＣＣＨには、セル構成情報が含まれるＭＩＢ（Master Information Block）がのる。したがってＰＢＣＨを受信してＢＣＣＨを得ることで、ＭＩＢが得られる。ＭＩＢの情報としては、例えば、ＤＬ（ダウンリンク）システム帯域幅（送信帯域幅設定（transmission bandwidth configuration：dl-bandwidth）とも呼ばれる）、送信アンテナ数、ＳＦＮ（System Frame Number）などがある。

次にステップＳＴ１２０５で、ＭＩＢのセル構成情報をもとに該セルのＤＬ−ＳＣＨを受信して、報知情報ＢＣＣＨの中のＳＩＢ（System Information Block）１を得る。ＳＩＢ１には、該セルへのアクセスに関する情報や、セルセレクションに関する情報、他のＳＩＢ（ＳＩＢｋ；ｋ≧２の整数）のスケジューリング情報が含まれる。また、ＳＩＢ１には、ＴＡＣ（Tracking Area Code）が含まれる。

次にステップＳＴ１２０６で、移動端末は、ステップＳＴ１２０５で受信したＳＩＢ１のＴＡＣと、移動端末が既に保有しているＴＡ（Tracking Area）リスト内のＴＡＣとを比較する。比較した結果、ステップＳＴ１２０５で受信したＴＡＣがＴＡリスト内に含まれるＴＡＣと同じならば、該セルで待ち受け動作に入る。比較して、ステップＳＴ１２０５で受信したＴＡＣがＴＡリスト内に含まれなければ、移動端末は該セルを通してコアネットワーク（Core Network，ＥＰＣ）（ＭＭＥなどが含まれる）へ、ＴＡＵ（Tracking Area Update）を行うためにＴＡの変更を要求する。コアネットワークは、ＴＡＵ要求信号とともに移動端末から送られてくる該移動端末の識別番号（ＵＥ−ＩＤなど）をもとに、ＴＡリストの更新を行う。コアネットワークは、移動端末に更新後のＴＡリストを送信する。移動端末は、受信したＴＡリストにて移動端末が保有するＴＡＣリストを書き換える（更新する）。その後、移動端末は、該セルで待ち受け動作に入る。

ＬＴＥやＵＭＴＳ（Universal Mobile Telecommunication System）においては、ＣＳＧ（Closed Subscriber Group）セルの導入が検討されている。前述したように、ＣＳＧセルに登録したひとつまたは複数の移動端末のみにアクセスが許される。ＣＳＧセルと登録されたひとつまたは複数の移動端末とがひとつのＣＳＧを構成する。このように構成されたＣＳＧには、ＣＳＧ−ＩＤと呼ばれる固有の識別番号が付される。なお、ひとつのＣＳＧには、複数のＣＳＧセルがあってもよい。移動端末は、どれかひとつのＣＳＧセルに登録すれば、そのＣＳＧセルが属するＣＳＧの他のＣＳＧセルにはアクセス可能となる。

また、ＬＴＥでのＨｏｍｅ−ｅＮＢやＵＭＴＳでのＨｏｍｅ−ＮＢが、ＣＳＧセルとして使われることがある。ＣＳＧセルに登録した移動端末は、ホワイトリストを有する。具体的には、ホワイトリストはＳＩＭ（Subscriber Identity Module）／ＵＳＩＭに記憶される。ホワイトリストには、移動端末が登録したＣＳＧセルのＣＳＧ情報が格納される。ＣＳＧ情報として具体的には、ＣＳＧ−ＩＤ、ＴＡＩ（Tracking Area Identity）、ＴＡＣなどが考えられる。ＣＳＧ−ＩＤとＴＡＣとが対応付けられていれば、どちらか一方でよい。また、ＣＳＧ−ＩＤおよびＴＡＣと、ＧＣＩ（Global Cell Identity）とが対応付けられていればＧＣＩでもよい。

以上から、ホワイトリストを有しない（本発明においては、ホワイトリストが空（empty）の場合も含める）移動端末は、ＣＳＧセルにアクセスすることは不可能であり、ｎｏｎ−ＣＳＧセルのみにしかアクセスできない。一方、ホワイトリストを有する移動端末は、登録したＣＳＧ−ＩＤのＣＳＧセルにも、ｎｏｎ−ＣＳＧセルにもアクセスすることが可能となる。

３ＧＰＰでは、全ＰＣＩ（Physical Cell Identity）を、ＣＳＧセル用とｎｏｎ−ＣＳＧセル用とに分割（ＰＣＩスプリットと称する）することが議論されている（非特許文献５参照）。またＰＣＩスプリット情報は、システム情報にて基地局から傘下の移動端末に対して報知されることが議論されている。非特許文献５は、ＰＣＩスプリットを用いた移動端末の基本動作を開示する。ＰＣＩスプリット情報を有していない移動端末は、全ＰＣＩを用いて（例えば５０４コード全てを用いて）セルサーチを行う必要がある。これに対して、ＰＣＩスプリット情報を有する移動端末は、当該ＰＣＩスプリット情報を用いてセルサーチを行うことが可能である。

また３ＧＰＰでは、ハイブリッドセルのためのＰＣＩは、ＣＳＧセル用のＰＣＩ範囲の中には含まれないことが決定されている（非特許文献１１０．７章参照）。

３ＧＰＰでは、移動端末がＣＳＧセルをセレクション、あるいはリセレクションする方法について２つのモードが存在する。１つ目は、自動（Automatic）モードである。自動モードの特徴を以下に示す。移動端末内の許可ＣＳＧリスト（Allowed CSG ID List）を利用して、セレクション、あるいはリセレクションを行う。ＰＬＭＮの選択が完了した後、ｎｏｎ−ＣＳＧセル、あるいは許可ＣＳＧリストに存在するＣＳＧＩＤを伴うＣＳＧセルである場合にのみ、選択している該ＰＬＭＮ中の１つのセルにキャンプオンする。移動端末の許可ＣＳＧリストが空であるならば、移動端末は、ＣＳＧセルの自立（autonomous）サーチ機能を停止する（非特許文献３５．２．４．８．１章参照）。

２つ目は、手動（Manual）モードである。手動モードの特徴を以下に示す。移動端末は、現在選択されているＰＬＭＮで利用可能なＣＳＧのリストを、ユーザに示す。移動端末がユーザに提供するＣＳＧのリストは、移動端末に保存されている許可ＣＳＧリストに含まれるＣＳＧに限られない。ユーザが該ＣＳＧのリストに基づいてＣＳＧを選定した後、移動端末は、選択されたＣＳＧＩＤを伴うセルへキャンプオンし、登録（register）を試みる（非特許文献３５．２．４．８．１章参照）。

ＨｅＮＢおよびＨＮＢに対しては、様々なサービスへの対応が求められている。例えば、オペレータは、ある決められたＨｅＮＢおよびＨＮＢに移動端末を登録させ、登録した移動端末のみにＨｅＮＢおよびＨＮＢのセルへのアクセスを許可することで、該移動端末が使用できる無線リソースを増大させて、高速に通信を行えるようにする。その分、オペレータは、課金料を通常よりも高く設定する、といったサービスである。

このようなサービスを実現するため、登録した（加入した、メンバーとなった）移動端末のみがアクセスできるＣＳＧセル（Closed Subscriber Group cell）が導入されている。ＣＳＧセル（Closed Subscriber Group cell）は、商店街やマンション、学校、会社などへ数多く設置されることが要求される。例えば、商店街では店舗毎、マンションでは部屋毎、学校では教室毎、会社ではセクション毎にＣＳＧセルを設置し、各ＣＳＧセルに登録したユーザのみが該ＣＳＧセルを使用可能とするような使用方法が要求されている。ＨｅＮＢ／ＨＮＢは、マクロセルのカバレッジ外での通信を補完するためだけでなく、上述したような様々なサービスへの対応が求められている。このため、ＨｅＮＢ／ＨＮＢがマクロセルのカバレッジ内に設置される場合も生じる。

３ＧＰＰにおいて、ＭＴＣ技術の検討が進められている（非特許文献８参照）。ＭＴＣは、従来の人対人（Human to Human：Ｈ２Ｈ）の通信と異なり、機械対機械（Machine to Machine：Ｍ２Ｍ）の通信である。すなわち、ヒューマンインタラクション（Human Interaction）、つまり人と人とのやり取りを必要としない。ＭＴＣ技術を用いたサービス（以下「ＭＴＣサービス」という）の応用例として、ガス、電力、水道などのメータリング（Metering）、すなわち計測や、輸送管理および発注管理（Tracking&Tracing）などがある。ＭＴＣサービスの特徴として、ＭＴＣ用のデバイス（MTC Device：ＭＴＣＤ）の数が膨大であることがある。一例として、１つのセルの傘下に３万台以上のＭＴＣＤが存在することが想定されている。

３ＧＰＰでは、ＭＴＣのアーキテクチャが検討されている（３ＧＰＰＲ３−１００３１５（以下「非特許文献１０」という）参照）。図１３は、３ＧＰＰで検討されているＭＴＣのアーキテクチャの一例を示す図である。ＬＴＥの通信システムだけでなく、ＷＣＤＭＡ（登録商標）の通信システムでもＭＴＣサービスのサポートが検討されている。

図１３において、ＭＴＣＤ１３０１〜１３０４と、ＮＢ／ｅＮＢ１３０５との間は、インタフェースＵｕ１３１１〜１３１４で接続されている。ＳＧＳＮ／ＭＭＥ（Serving GPRS Support Node/ Mobility Management Entity）１３０６は、ＮＢ／ｅＮＢ１３０５とＩｕＰＳ／Ｓ１インタフェース１３１５で接続されている。図示していないが、ＮＢとＳＧＳＮとの間には、無線ネットワーク制御装置（Radio Network Controller：ＲＮＣ）が存在している。ＮＢとＲＮＣとの間は、Ｉｕｂインタフェースで接続され、ＲＮＣはＩｕＰＳインタフェースを介してＳＧＳＮに接続される。

ＨＬＲ／ＨＳＳ（Home Location Register/Home Subscriber Server）１３０７は、Ｇｒ／Ｓ６ａインタフェース１３１６を介して、ＳＧＳＮ／ＭＭＥ１３０６と接続される。通信オペレータ領域１３１７には、ＮＢ／ｅＮＢ１３０５、ＳＧＳＮ／ＭＭＥ１３０６、およびＨＬＲ／ＨＳＳ１３０７などが含まれる。

ＭＴＣサーバ１３０８は、通信オペレータ領域１３１７に含まれる。ＭＴＣサービスを行うＭＴＣユーザ１３０９は、アプリケーションプログラムインタフェース（Application Program Interface：ＡＰＩ）１３１０を介して、ＭＴＣサーバ１３０８と接続される。ＭＴＣサーバ１３０８が通信オペレータ領域１３１７のいずれのノードに接続されるかについては、３ＧＰＰにおいて現在検討中である。

ＭＴＣサービス用の情報は、ＭＴＣユーザ１３０９によって、ＭＴＣサーバ１３０８から、通信オペレータ領域１３１７のノードであるＮＢ／ｅＮＢ１３０５、ＳＧＳＮ／ＭＭＥ１３０６、ＨＬＲ／ＨＳＳ１３０７を用いて、ＭＴＣＤ１３０１〜１３０４へ通知される。逆にＭＴＣＤ１３０１〜１３０４からの情報は、通信オペレータ領域１３１７のノードであるＮＢ／ｅＮＢ１３０５、ＳＧＳＮ／ＭＭＥ１３０６、ＨＬＲ／ＨＳＳ１３０７を用いて、ＭＴＣサーバ１３０８へ通知され、ＭＴＣユーザ１３０９によって該情報が利用される。

ＭＴＣサービスでは、多数のＭＴＣＤから、あるいは多数のＭＴＣＤへ同時にデータを通信する状況が生じる。このような状況は、例えば、１日１回午前１時に検針データをＭＴＣＤからＭＴＣサーバに送信する場合、あるいは検針データを送信することをＭＴＣサーバからＭＴＣＤに要求する場合などに生じる。他の例としては、全てのＭＴＣＤに対して、一斉にソフトウェアのバージョンアップのためのデータを送信する場合などがある。

従来の通信方式では、Ｈ２Ｈ通信に最適化されているので、多数のＭＴＣＤが同時にデータを通信する状況に対する対策は、為されていない。多数のＭＴＣＤから、あるいは多数のＭＴＣＤへ同時にデータを通信する状況では、無線ネットワーク（Radio Network）、コアネットワーク（Core Network）において混雑状態が生じてしまうという問題が発生する。すなわち、これらのネットワークが過負荷状態となってしまうという問題が発生する。

例えば、ＭＴＣサーバから一斉に多数のＭＴＣＤに検針データを送信することを要求するような場合、ＭＴＣＤ１３０１〜１３０４から、通信オペレータ領域１３１７のノードであるＮＢ／ｅＮＢ１３０５、ＳＧＳＮ／ＭＭＥ１３０６、ＨＬＲ／ＨＳＳ１３０７を用いて、ＭＴＣサーバ１３０８へ多数のデータが送信される。このような状況では、ＮＢ／ｅＮＢ１３０５とＳＧＳＮ／ＭＭＥ１３０６との間の通信に、過負荷状態が発生する。これによって、通信リソース不足、あるいはＮＢ／ｅＮＢ１３０５およびＳＧＳＮ／ＭＭＥ１３０６の処理の過負荷状態が発生するという問題が生じる。

前記コアネットワークにおける混雑状態の発生という課題に対して、前述の非特許文献９では、以下の解決策が開示されている。ｅＮＢが、同じグループのＭＴＣＤに共通のシグナリングメッセージを引き止め（hold back）、寄せ集める（aggregation）ことで、シグナリングメッセージをコンパクトにすることが記載されている。具体的には、ｅＮＢが、事前に決められた時間、あるいは多くの非アクセスストラタム（Non-Access Stratum：ＮＡＳ）シグナリングメッセージ（NAS Signaling messages）が到着するまで、ＭＴＣＤからのＮＡＳシグナリングメッセージを引き止める方法が記載されている。しかし、非特許文献９には、ｅＮＢの傘下に多くのＭＴＣＤグループが存在する場合の課題については示唆されておらず、解決策も開示されていない。また、ｅＮＢでＭＴＣＤからのシグナリングメッセージを引き止め、寄せ集めた後、コアネットワーク側へ送信する方法についても開示されていない。

前記コアネットワークにおける混雑状態の発生という課題に対して、３ＧＰＰＳ２−１０１００８（以下「非特許文献１１」という）では、以下の解決策が開示されている。同じＭＴＣＤグループ内のＭＴＣＤが、ＭＴＣＤではないＵＥに対する１つのネットワーク資源を共有することが記載されている。しかし、非特許文献１１には、ｅＮＢの傘下に多くのＭＴＣＤグループが存在する場合の課題については示唆されておらず、解決策も開示されていない。また非特許文献１１には、ＭＴＣＤからＭＴＣサーバへのメッセージに、ソースアドレスとしての移動加入者識別番号（International Mobile Subscriber Identity：ＩＭＳＩ）とＭＴＣＤの番号、セル番号をマッピングすることが開示されている。しかし、同じＭＴＣＤグループ内のＭＴＣＤが、１つのネットワーク資源を共有する方法については開示されていない。

３ＧＰＰＲ２−１０３２６９（以下「非特許文献１２」という）には、ＭＴＣＤが地下に設置されている場合などは、個々のＭＴＣＤとｅＮＢとの間のチャネル品質が悪く、直接の通信は不適切であるという問題が記載されている。このような問題に対して、非特許文献１２では、ｅＮＢとは別に、ｅＮＢとＭＴＣＤとの間に集中装置（concentrator）を設置することが開示されている。しかし、非特許文献１２には、集中装置からｅＮＢへ送信する方法については開示されていない。

実施の形態１で解決する課題について、以下に説明する。ｅＮＢの傘下に多くのＭＴＣＤグループが存在する場合においては、前述の非特許文献９に開示された方法、すなわちｅＮＢが、同じＭＴＣＤグループのＭＴＣＤに共通のシグナリングメッセージを引き止め、寄せ集める方法では、シグナリングメッセージを削減することができない。実施の形態１では、ｅＮＢの傘下に多くのＭＴＣＤグループが存在する場合でも、多数のＭＴＣＤからのデータを通信する状況が生じたときに、コアネットワークの混雑の緩和が可能な通信システムについて開示する。本実施の形態の通信システムは、移動体通信システムである。ＭＴＣＤグループは、端末装置群に相当する。

実施の形態１での解決策を以下に示す。ＨｅＮＢが、傘下のＭＴＣＤからコアネットワークであるＭＭＥ、あるいはＳＧＳＮ、あるいはＭＴＣサーバなどへのデータを集線（concentrate）する集線処理を行う。ＨｅＮＢは、傘下のＭＴＣＤからコアネットワークであるＭＭＥ、あるいはＳＧＳＮ、あるいはＭＴＣサーバなどへのデータをそのまま送信するのではなく、また中継するのではなく、また経由させるのではなく、集線する。これによって、ＨｅＮＢの傘下に、属するＭＴＣＤグループが異なるＭＴＣＤが多く存在する場合であっても、集線処理を行うことが可能となる。したがって、ＨｅＮＢの傘下に、属するＭＴＣＤグループが異なるＭＴＣＤが多く存在する状況下であっても、コアネットワークにおける混雑を緩和することができる。

また、ＨｅＮＢがクローズドアクセスモード（Closed access mode）、あるいはハイブリッドアクセスモード（Hybrid access mode）で動作する場合、同じＣＳＧに属するＭＴＣＤからコアネットワークへのデータを集線するようにしてもよい。これによって、ＨｅＮＢは、傘下のＭＴＣＤのうち、自ＨｅＮＢと同じＣＳＧへ登録しているＭＴＣＤからのデータのみを処理することができ、ＣＳＧメンバーのみアクセス可能なセルとして動作するというクローズドアクセスモードの趣旨に沿った処理となる。

また、ＨｅＮＢがハイブリッドアクセスモードで動作する場合、オープンアクセスモード（Open access mode）はＭＴＣＤ以外の移動端末が用い、クローズドアクセスモードはＭＴＣＤが用いるようにしてもよい。ＭＴＣＤは、同じＣＳＧのＨｅＮＢへのみアクセスが許されるようにしてもよい。この場合、ＨｅＮＢは、クローズドアクセスモードでアクセスする通信端末からコアネットワークへのデータを集線するようにしてもよい。

ＨｅＮＢで行う処理は、ｅＮＢが行っても同じ効果を得ることができる。以下では、便宜上、ＨｅＮＢを中心に説明する。

ＨｅＮＢとＭＴＣＤとの間の通信方法の具体例として、以下の（１），（２）の２つを開示する。（１）３ＧＰＰによって標準規格化された移動体通信システムの通信方法。（２）３ＧＰＰによって標準規格化された移動体通信システム以外の通信方法。

３ＧＰＰによって標準規格化された移動体通信システム以外の通信方法の具体例として、以下の（１）〜（５）の５つを開示する。（１）赤外線通信。（２）同軸ケーブルによる通信。（３）光ファイバーによる通信。（４）ブルートゥース（Bluetooth（登録商標））による通信。（５）ジグビー（ZigBee（登録商標））による通信。

ＨｅＮＢにおける集線処理の対象である、ＭＴＣＤからコアネットワークへのデータの具体例について、以下に開示する。まず、集線処理の対象となるデータの内容の具体例として、以下の（１），（２）の２つを開示する。（１）制御データ。（２）ユーザデータ。次に、集線処理の対象となるシグナリングの具体例として、以下の（１），（２）の２つを開示する。（１）ＮＡＳシグナリング、あるいはＮＡＳメッセージ。（２）ＲＲＣシグナリング、あるいはＲＲＣメッセージ。

ＨｅＮＢが、傘下の移動端末（ＵＥ）がＭＴＣＤであるか、ＭＴＣＤ以外であるかを区別する方法の具体例として、以下の（１）〜（３）の３つを開示する。以下の説明では、ＭＴＣＤ以外の移動端末（ＵＥ）を「ノーマルＵＥ」と称することもある。

（１）ＭＴＣＤとノーマルＵＥとで用いる識別子を別体系とする。例えば、現行のＵＥ−ＩＤとは別にＭＴＣＤ−ＩＤを新設する。現行のＵＥ−ＩＤをノーマルＵＥ用の識別子とし、ＭＴＣＤ−ＩＤをＭＴＣＤ用の識別子としてもよい。

（２）ＭＴＣＤか否かを区別するためのインジケータ（以下「ＭＴＣＤインジケータ」とも称する）を新設する。ＭＴＣＤインジケータの具体例として、以下の（ａ）〜（ｇ）の７つを開示する。（ａ）ＭＴＣＤであるか、ノーマルＵＥであるかを示すインジケータ。（ｂ）ＭＴＣＤであるか否かを示すインジケータ。ＭＴＣＤでない旨を示すインジケータが含まれていれば、ＨｅＮＢは該ＵＥをノーマルＵＥと判断する。（ｃ）ノーマルＵＥであるか否かを示すインジケータ。ノーマルＵＥでない旨を示すインジケータが含まれていれば、ＨｅＮＢは該ＵＥをＭＴＣＤと判断する。（ｄ）ＭＴＣＤである旨を示すインジケータ。ＭＴＣＤである旨を示すインジケータが含まれていなければ、ＨｅＮＢは該ＵＥをノーマルＵＥと判断する。（ｅ）ＭＴＣＤでない旨を示すインジケータ。ＭＴＣＤでない旨を示すインジケータが含まれていなければ、ＨｅＮＢは該ＵＥをＭＴＣＤと判断する。（ｆ）ノーマルＵＥである旨を示すインジケータ。ノーマルＵＥである旨を示すインジケータが含まれていなければ、ＨｅＮＢは該ＵＥをＭＴＣＤと判断する。（ｇ）ノーマルＵＥでない旨を示すインジケータ。ノーマルＵＥでない旨を示すインジケータが含まれていなければ、ＨｅＮＢは該ＵＥをノーマルＵＥと判断する。

（３）３ＧＰＰによって標準規格化された移動体通信システム以外の通信方法でアクセスしてきたか否かで判断する。３ＧＰＰによって標準規格化された移動体通信システム以外の通信方法でアクセスしてきた移動端末は、ＭＴＣＤと判断する。

以上に述べたＨｅＮＢが、傘下の移動端末（ＵＥ）がＭＴＣＤであるか、ＭＴＣＤ以外であるかを区別する方法の具体例のうち、具体例（１）、具体例（２）−（ｄ）、具体例（２）−（ｇ）、および具体例（３）は、現行のＵＥがノーマルＵＥであれば、新規に追加するパラメータや処理が不要となる。したがって、具体例（１）、具体例（２）−（ｄ）、具体例（２）−（ｇ）、または具体例（３）を用いることによって、現行のＵＥの仕様変更を伴わずに課題を解決することができる。

ＵＥがＭＴＣＤであるか、ＭＴＣＤ以外であるかの区別をＨｅＮＢへ通知する方法の具体例として、以下の（１），（２）の２つを開示する。（１）ＲＲＣメッセージ、あるいはＲＲＣシグナリングを用いて、該ＵＥがＭＴＣＤであるかＭＴＣＤ以外であるかの区別をＨｅＮＢへ通知する。ＲＲＣメッセージ、あるいはＲＲＣシグナリングに前記別体系とした識別子を用いる。またＲＲＣメッセージ、あるいはＲＲＣシグナリングにＭＴＣＤインジケータをマッピングする。ＲＲＣシグナリングの具体例としては、「RRC Connection Request」（非特許文献２参照）などがある。後述する具体例（２）と比較して、本具体例（１）は、ＨｅＮＢが集線処理の対象であるコアネットワークへのデータを受信する前に、ＭＴＣＤであるか否かの判断が可能となる。したがって、ＨｅＮＢでの集線処理における制御遅延を防止することができる。

（２）集線処理を行うコアネットワークへのデータを用いて、該ＵＥがＭＴＣＤであるか、ＭＴＣＤ以外であるかの区別をＨｅＮＢへ通知する。コアネットワークへのデータに、前記別体系とした識別子を用いる。またコアネットワークへのデータに、ＭＴＣＤインジケータをマッピングする。ここで、コアネットワークデータへのヘッダー／フッダーに、前記別体系とした識別子を用いるようにしてもよい。また、コアネットワークデータへのヘッダー／フッダーに、ＭＴＣＤインジケータをマッピングするようにしてもよい。コアネットワークデータのヘッダー／フッダーを用いて、該ＵＥがＭＴＣＤであるかＭＴＣＤ以外であるかの区別が可能となれば、ＨｅＮＢがＭＴＣＤからコアネットワークへのメッセージの中身を常に解釈しなくてよくなる。したがって、ＨｅＮＢの処理の負荷を軽減することができる。

集線処理の具体例として、以下の（１）〜（４）の４つを開示する。（１）ＮＡＳシグナリング、あるいはＮＡＳメッセージを終端し、別途ＭＭＥへ通知する。この際、不要なデータを削減してＭＭＥへ通知してもよい。これによって、ＨｅＮＢからコアネットワークへの通信量が削減でき、コアネットワークの混雑を緩和することができる。（２）ＮＡＳシグナリング、あるいはＮＡＳメッセージを解釈し、別途ＭＭＥへ通知する。この際、不要なデータを削減してＭＭＥへ通知してもよい。これによって、ＨｅＮＢからコアネットワークへの通信量が削減でき、コアネットワークの混雑を緩和することができる。（３）１つ、あるいは複数のＭＴＣＤからのコアネットワークへのデータを、まとめてＭＭＥへ通知する。これによって、ＨｅＮＢからコアネットワークへの通信回数が削減でき、コアネットワークの混雑を緩和することができる。（４）前記（１）〜（３）の組み合わせ。

ＨｅＮＢがＮＡＳシグナリングを終端する概念について、図１４および図１５を用いて説明する。まず、図１４を用いて、従来の技術におけるＵＥ−ＭＭＥ間の制御データのプロトコルスタックについて説明する。図１４は、従来の技術におけるＵＥ−ＭＭＥ間の制御データのプロトコルスタックを示す図である。ＵＥとＨｅＮＢとの間のインタフェースは、ＬＴＥ−Ｕｕ１４０１として定義されている（非特許文献１、３ＧＰＰＴＳ２３．４０１Ｖ１０．０．０（以下「非特許文献１３」という）参照）。ＨｅＮＢとＭＭＥとの間のインタフェースは、Ｓ１−ＭＭＥ１４０２として定義されている（非特許文献１３参照）。

ＵＥ、ＨｅＮＢ、ＭＭＥに、レイヤ１（Ｌ１）プロトコル１４０３−１，１４０３−２，１４０３−３，１４０３−４が存在する。ＵＥ、ＨｅＮＢに、ＭＡＣ（Medium Access Control）プロトコル１４０４−１，１４０４−２が存在する。ＨｅＮＢ、ＭＭＥに、レイヤ２（Ｌ２）プロトコル１４０５−１，１４０５−２が存在する。ＵＥ、ＨｅＮＢに、ＲＬＣ（Radio Link Control）プロトコル１４０６−１，１４０６−２が存在する。ＨｅＮＢ、ＭＭＥに、ＩＰ（Internet Protocol）１４０７−１，１４０７−２が存在する。ＵＥ、ＨｅＮＢに、ＰＤＣＰ（Packet Data Convergence Protocol）１４０８−１，１４０８−２が存在する。ＨｅＮＢ、ＭＭＥに、ＳＣＴＰ（Stream Control Transport Protocol for the control plane）１４０９−１，１４０９−２が存在する。ＵＥ、ＨｅＮＢに、ＲＲＣ（Radio Resource Control）プロトコル１４１０−１，１４１０−２が存在する。ＨｅＮＢ、ＭＭＥに、Ｓ１−ＡＰ（S1 Application Protocol）１４１１−１，１４１１−２が存在する。

ＨｅＮＢ内の各プロトコル層において、中継（Relay）１４１２が行われる。ＵＥ、ＭＭＥに、ＮＡＳ（Non-Access Stratum）プロトコル１４１３−１，１４１３−２が存在する。ＮＡＳプロトコルは、移動性管理の機能と、ユーザプレーンベアラの起動、変更、非活性化をサポートする。

次に図１５を用いて、実施の形態１におけるＭＴＣＤ−ＭＭＥ間の制御データのプロトコルスタックについて説明する。図１５は、実施の形態１におけるＭＴＣＤ−ＭＭＥ間の制御データのプロトコルスタックを示す図である。図１５において、図１４に示すプロトコル層に対応する部分については、同一の参照符を付して、共通する説明を省略する。

ＭＴＣＤとＨｅＮＢとの間のインタフェースは、ＬＴＥ−Ｕｕ１４０１として定義されている。ＭＴＣＤに、レイヤ１（Ｌ１）プロトコル１４０３−１、ＭＡＣプロトコル１４０４−１、ＲＬＣプロトコル１４０６−１、ＰＤＣＰ１４０８−１、ＲＲＣプロトコル１４１０−１、ＭＴＣ用ＮＡＳプロトコル１５０１−１が存在する。ここで、ＭＴＣ用ＮＡＳプロトコルは、ＭＭＥまで至っていないが、便宜上「ＮＡＳ」という文言を用いることとする。

ＨｅＮＢ内に、レイヤ１（Ｌ１）プロトコル１４０３−２、ＭＡＣプロトコル１４０４−２、ＲＬＣプロトコル１４０６−２、ＰＤＣＰ１４０８−２、ＲＲＣプロトコル１４１０−２、ＭＴＣ用ＮＡＳプロトコル１５０１−２が存在する。ＨｅＮＢ内にＭＴＣ用ＮＡＳプロトコル１５０１−２が存在することによって、ＨｅＮＢが前述の集線１５０４を行うことができる。ＨｅＮＢ内の各プロトコル層において、中継１４１２が行われる。ＨｅＮＢ、ＭＭＥに、Ｓ１−ＡＰ１５０２−１，１５０２−２，１５０２−３が存在する。図１５では、ＨｅＮＢ内のＳ１−ＡＰを、Ｓ１−ＡＰ１５０２−１とＳ１−ＡＰ１５０２−３とに分離して記載しているが、ＨｅＮＢ内のＳ１−ＡＰは、１つであってもよい。ＭＭＥには、ノーマルＵＥ用ＮＡＳプロトコル１５０３が存在する。

実施の形態１におけるノーマルＵＥ−ＭＭＥ間の制御データのプロトコルスタックについては、従来の技術と同様であるので、説明を省略する（図１４参照）。但し、ＭＭＥにノーマルＵＥ用ＮＡＳプロトコル１５０３が存在する（図１５参照）。

次に、実施の形態１を用いた具体的な動作例を、図１６および図１７を用いて説明する。本動作例では、ＨｅＮＢにおける集線処理の対象である、ＭＴＣＤからコアネットワークへのデータの具体例として、ＮＡＳシグナリングの場合について開示する。また、ＨｅＮＢが、傘下の移動端末（ＵＥ）がＭＴＣＤであるか、ＭＴＣＤ以外であるかを区別する方法の具体例として、ＲＲＣメッセージ「RRC Connection Request」にＭＴＣＤインジケータをマッピングする場合について開示する。また、集線処理の具体例として、１つ、あるいは複数のＭＴＣＤからのコアネットワークへのデータを、まとめてＭＭＥへ通知する場合について開示する。

まず図１６を用いて、実施の形態１におけるＨｅＮＢの集線処理の具体例について説明する。図１６は、実施の形態１における集線処理に関するＨｅＮＢの処理手順を示すフローチャートである。

ステップＳＴ１６０１において、ＨｅＮＢは、ＵＥからＲＲＣメッセージ「RRC Connection Request」を受信したか否かを判断する。ＨｅＮＢは、ＵＥからＲＲＣメッセージを受信したと判断した場合は、ステップＳＴ１６０２へ移行する。ＨｅＮＢは、ＵＥからＲＲＣメッセージを受信していないと判断した場合は、ステップＳＴ１６０１の判断処理を繰り返す。

ステップＳＴ１６０２において、ＨｅＮＢは、ステップＳＴ１６０１で受信したＲＲＣメッセージにマッピングされるＭＴＣＤインジケータを確認し、ステップＳＴ１６０３に移行する。

ステップＳＴ１６０３において、ＨｅＮＢは、ステップＳＴ１６０２で確認したＭＴＣＤインジケータに基づいて、ＲＲＣメッセージをＭＴＣＤから受信したか否か、すなわち、ステップＳＴ１６０１で受信したＲＲＣメッセージを送信したＵＥがＭＴＣＤであるか否かを判断する。ＨｅＮＢは、ＲＲＣメッセージをＭＴＣＤから受信した、すなわちＲＲＣメッセージを送信したＵＥがＭＴＣＤであると判断した場合は、ステップＳＴ１６０４へ移行する。ＨｅＮＢは、ＲＲＣメッセージをＭＴＣＤから受信していない、すなわちＲＲＣメッセージを送信したＵＥがＭＴＣＤではないと判断した場合は、ステップＳＴ１６０５へ移行する。

ステップＳＴ１６０４において、ＨｅＮＢは、ＭＴＣＤからコアネットワークへのデータを集線処理する。ステップＳＴ１６０４の処理を終了した後は、ＨｅＮＢは、全ての処理手順を終了する。ステップＳＴ１６０５において、ＨｅＮＢは、ＵＥからコアネットワークへのデータを集線処理しない。すなわちデータは、ＨｅＮＢ経由で、ＵＥからコアネットワークへ送信される。ステップＳＴ１６０５の処理を終了した後は、ＨｅＮＢは、全ての処理手順を終了する。

次に図１７を用いて、実施の形態１における移動体通信システムのシーケンスの具体例について説明する。図１７は、実施の形態１における移動体通信システムのシーケンスを示す図である。ＨｅＮＢの傘下に、ｍ個のノーマルＵＥとｎ個のＭＴＣＤとが存在するとする。ここで、ｍおよびｎは、それぞれ自然数を示す。ｍ個のノーマルＵＥを、ノーマルＵＥ＿１〜ノーマルＵＥ＿ｍで表し、ｎ個のＭＴＣＤを、ＭＴＣＤ＿１〜ＭＴＣＤ＿ｎで表す。

ステップＳＴ１７０１において、ノーマルＵＥ＿１は、ＨｅＮＢに、ＭＴＣＤインジケータを含むＲＲＣメッセージである「RRC Connection Request」を送信する。ステップＳＴ１７０２において、ノーマルＵＥ＿ｍは、ＨｅＮＢに、ＭＴＣＤインジケータを含むＲＲＣメッセージである「RRC Connection Request」を送信する。このように本実施の形態では、ノーマルＵＥ＿１〜ノーマルＵＥ＿ｍのうち、ノーマルＵＥ＿１およびノーマルＵＥ＿ｍが、コアネットワークへの送信データが発生したとして、ＭＴＣＤインジケータを含むＲＲＣメッセージである「RRC Connection Request」をＨｅＮＢに送信するものとする。

ステップＳＴ１７０３において、ＭＴＣＤ＿１は、ＨｅＮＢに、ＭＴＣＤインジケータを含むＲＲＣメッセージである「RRC Connection Request」を送信する。ステップＳＴ１７０４において、ＭＴＣＤ＿ｎは、ＨｅＮＢに、ＭＴＣＤインジケータを含むＲＲＣメッセージである「RRC Connection Request」を送信する。このように本実施の形態では、ＭＴＣＤ＿１〜ＭＴＣＤ＿ｎのうち、ＭＴＣＤ＿１およびＭＴＣＤ＿ｎが、コアネットワークへの送信データが発生したとして、ＭＴＣＤインジケータを含むＲＲＣメッセージである「RRC Connection Request」をＨｅＮＢに送信するものとする。

ステップＳＴ１７０５において、ＨｅＮＢは、受信した「RRC Connection Request」に含まれるＭＴＣＤインジケータを確認し、ＲＲＣメッセージがＭＴＣＤからのデータであるか否かを判断する。ＨｅＮＢは、ＭＴＣＤからのデータであると判断した場合は、ステップＳＴ１７０７へ移行する。ＨｅＮＢは、ＭＴＣＤからのデータではないと判断した場合は、ステップＳＴ１７０６へ移行する。

本動作例においては、ステップＳＴ１７０１はノーマルＵＥ＿１からのＲＲＣメッセージの送信処理であるので、ステップＳＴ１７０５では、ＭＴＣＤからのデータではないと判断され、ステップＳＴ１７０６へ移行する。また、ステップＳＴ１７０２はノーマルＵＥ＿ｍからのＲＲＣメッセージの送信処理であるので、ステップＳＴ１７０５では、ＭＴＣＤからのデータではないと判断され、ステップＳＴ１７０６へ移行する。また、ステップＳＴ１７０３はＭＴＣＤ＿１からのＲＲＣメッセージの送信処理であるので、ステップＳＴ１７０５では、ＭＴＣＤからのデータであると判断され、ステップＳＴ１７０７へ移行する。また、ステップＳＴ１７０４はＭＴＣＤ＿ｎからのＲＲＣメッセージの送信処理であるので、ステップＳＴ１７０５では、ＭＴＣＤからのデータであると判断され、ステップＳＴ１７０７へ移行する。

ステップＳＴ１７０６において、ＨｅＮＢは、傘下のＭＴＣＤ以外の移動端末（ＵＥ）であるノーマルＵＥからコアネットワークへのデータを集線処理しない設定とする。本動作例では、ＨｅＮＢは、傘下のＭＴＣＤ以外のＵＥについて、ＵＥからのＮＡＳシグナリングを集線処理しない設定、具体的には、ノーマルＵＥからコアネットワークへのＮＡＳシグナリングを集線処理しない設定とする。

ステップＳＴ１７０７において、ＨｅＮＢは、傘下のＭＴＣＤからコアネットワークへのデータを集線処理する設定とする。本動作例では、ＨｅＮＢは、傘下のＵＥのうちのＭＴＣＤについて、ＵＥからのＮＡＳシグナリングを集線処理する設定、具体的には、ＭＴＣＤからコアネットワークへのＮＡＳシグナリングを集線処理する設定とする。

ステップＳＴ１７０８において、ノーマルＵＥ＿１は、ＨｅＮＢ経由でＭＭＥへ、コアネットワークへのデータであるＮＡＳシグナリングを送信する。ＨｅＮＢは、ステップＳＴ１７０６において、ノーマルＵＥ＿１からのＮＡＳシグナリングの集線処理を行わない設定になっているので、ノーマルＵＥ＿１から送信されたＮＡＳシグナリングは、そのままＨｅＮＢ経由でＭＭＥへ通知される。

ステップＳＴ１７０９において、ノーマルＵＥ＿ｍは、ＨｅＮＢ経由でＭＭＥへ、コアネットワークへのデータであるＮＡＳシグナリングを送信する。ＨｅＮＢは、ステップＳＴ１７０６において、ノーマルＵＥ＿ｍからのＮＡＳシグナリングの集線処理を行わない設定になっているので、ノーマルＵＥ＿ｍから送信されたＮＡＳシグナリングは、そのままＨｅＮＢ経由でＭＭＥへ通知される。同様に、他のノーマルＵＥからＨｅＮＢ経由でＭＭＥへＮＡＳシグナリングが送信された場合、他のノーマルＵＥから送信されたＮＡＳシグナリングは、そのままＨｅＮＢ経由でＭＭＥへ通知される。

ステップＳＴ１７１０において、ＭＴＣＤ＿１は、ＭＭＥへ、コアネットワークへのデータであるＮＡＳシグナリングを送信する。ＨｅＮＢは、ステップＳＴ１７０７において、ＭＴＣＤ＿１からのＮＡＳシグナリングの集線処理を行う設定になっているので、ＭＴＣＤ＿１から送信されたＮＡＳシグナリングは、ステップＳＴ１７１２において集線処理が行われる。また、ステップＳＴ１７１２、あるいはステップＳＴ１７０７において、ＨｅＮＢが通常の「RRC Connection Request」を受信した場合の処理（非特許文献２参照）を省略してもよい。また、ステップＳＴ１７１２において、ＨｅＮＢは、「RRC Connection Request」を送信したＭＴＣＤに対して、「RRC Connection reject」を通知してもよい。また、「RRC Connection reject」に、ＭＴＣＤからコアネットワークへのデータを受信した旨を示す情報をマッピングしてもよい。また「RRC Connection reject」に、ＭＴＣＤからコアネットワークへのデータの再送を要求する情報をマッピングしてもよい。

ステップＳＴ１７１１において、ＭＴＣＤ＿ｎは、ＭＭＥへ、コアネットワークへのデータであるＮＡＳシグナリングを送信する。ＨｅＮＢは、ステップＳＴ１７０７において、ＭＴＣＤ＿ｎからのＮＡＳシグナリングの集線処理を行う設定になっているので、ＭＴＣＤ＿ｎから送信されたＮＡＳシグナリングは、ステップＳＴ１７１２において集線処理が行われる。同様に、他のＭＴＣＤからＭＭＥへＮＡＳシグナリングが送信された場合、他のＭＴＣＤから送信されたＮＡＳシグナリングは、ステップＳＴ１７１２において集線処理が行われる。

ステップＳＴ１７１２において、ＨｅＮＢは、傘下のＭＴＣＤからのコアネットワークへのデータであるＮＡＳシグナリングの集線処理を行う。ステップＳＴ１７１３において、ＨｅＮＢは、ＭＴＣＤ＿１、ＭＴＣＤ＿ｎからコアネットワークへのデータであるＭＭＥへのデータをまとめて、ＭＭＥに通知する。

実施の形態１により、以下の効果を得ることができる。実施の形態１によれば、ＨｅＮＢが、傘下のＭＴＣＤからコアネットワークへのデータを集線する集線処理を行う。このとき、ＭＴＣＤグループにわたって集線処理を行う。つまり、ＭＴＣＤグループとは無関係に集線処理を行うので、ＨｅＮＢの傘下に多くのＭＴＣＤグループが存在する場合であっても、ＨｅＮＢからコアネットワークへの通信回数、あるいはデータ量を削減することができる。これによって、ＨｅＮＢの傘下に多くのＭＴＣＤグループが存在し、多数のＭＴＣＤからデータを通信する状況が生じた場合であっても、コアネットワークの混雑を緩和することが可能な移動体通信システムを得ることができる。

また、ＭＴＣＤが３ＧＰＰによって標準規格化された移動体通信システムとしての無線環境の悪い場所に設定されている場合であっても、非特許文献１２に示す集中装置のように別途エンティティを設ける必要がなく、ＨｅＮＢが起点となって３ＧＰＰ網を用いてＭＴＣユーザ、ＭＴＣサーバと通信することが可能となる。別途エンティティを設ける必要がない点において、移動体通信システムが複雑化することを回避することができるという利点がある。

実施の形態１変形例１．
前述の実施の形態１を用いた場合、以下の課題が発生する。集線処理を行うことで、集線処理を行わない場合と比較して、ＭＴＣＤからコアネットワークへのデータの伝達に遅延が発生する。遅延が発生する具体例を、前述の図１７を用いて説明する。

集線処理を行わないノーマルＵＥ＿１からコアネットワークへのＮＡＳシグナリングは、ステップＳＴ１７０８において、そのままＨｅＮＢ経由でＭＭＥへ通知される。これに対して、集線処理を行うＭＴＣＤ＿１からコアネットワークへのＮＡＳシグナリングは、ステップＳＴ１７１２において、ＨｅＮＢ内で集線処理が行われてから、ステップＳＴ１７１３において、別途ＨｅＮＢからＭＭＥへ通知される。このように、集線処理を行うと、ＨｅＮＢ内で制御遅延が発生する。

一般的にＭＴＣＤは、遅延に寛容なものが多いと考えられているが、遅延発生に敏感なＭＴＣＤも考えられる。具体例としては、地震発生を感知する機能を搭載したＭＴＣＤなどである。そのような遅延発生に敏感なＭＴＣＤに、前述の実施の形態１を用いることによって遅延が発生することは、ＭＴＣＤサービス上問題がある。

実施の形態１の変形例１での解決策を以下に示す。実施の形態１での解決策と異なる部分を中心に説明する。説明していない部分については、実施の形態１と同様とする。

ＨｅＮＢは、傘下のＭＴＣＤのうち、遅延が許されるＭＴＣＤから、コアネットワークであるＭＭＥ、あるいはＳＧＳＮ、あるいはＭＴＣサーバなどへのデータを集線（concentrate）する。ＨｅＮＢは、傘下のＭＴＣＤのうち、遅延が許されないＭＴＣＤから、コアネットワークであるＭＭＥ、あるいはＳＧＳＮ、あるいはＭＴＣサーバなどへのデータは集線しない。

ＨｅＮＢは、傘下のＭＴＣＤのうち、優先順位が低いＭＴＣＤ（Low priority ＭＴＣＤ）から、コアネットワークであるＭＭＥ、あるいはＳＧＳＮ、あるいはＭＴＣサーバなどへのデータを集線（concentrate）する。ＨｅＮＢは、傘下のＭＴＣＤのうち優先順位が高いＭＴＣＤ（High priority ＭＴＣＤ）から、コアネットワークであるＭＭＥ、あるいはＳＧＳＮ、あるいはＭＴＣサーバなどへのデータは集線しない。

ＨｅＮＢが、傘下の移動端末（ＵＥ）が優先順位の低いＭＴＣＤであるか否かを区別する方法の具体例を、以下に開示する。優先順位を表すインジケータ（以下「優先順位インジケータ」とも称する）を新設する。

優先順位インジケータの具体例として、以下の（ａ）〜（ｇ）の７つを開示する。

（ａ）優先順位が高いか、低いかを示すインジケータ。

（ｂ）優先順位が低いか否かを示すインジケータ。優先順位が低くないことを示すインジケータが含まれていれば、ＨｅＮＢは、ＭＴＣＤを優先順位が高いと判断する。

（ｃ）優先順位が高いか否かを示すインジケータ。優先順位が高くないことを示すインジケータが含まれていれば、ＨｅＮＢは、ＭＴＣＤを優先順位が低いと判断する。

（ｄ）優先順位が低いＭＴＣＤである旨を示すインジケータ。優先順位が低いＭＴＣＤである旨を示すインジケータが含まれていなければ、ＨｅＮＢは、ＭＴＣＤを優先順位が高いＭＴＣＤであると判断する。

（ｅ）優先順位が低いＭＴＣＤでない旨を示すインジケータ。優先順位が低いＭＴＣＤでない旨を示すインジケータが含まれていなければ、ＨｅＮＢは、ＭＴＣＤを優先順位が低いＭＴＣＤであると判断する。

（ｆ）優先順位が高いＭＴＣＤである旨を示すインジケータ。優先順位が高いＭＴＣＤである旨を示すインジケータが含まれていなければ、ＨｅＮＢは、ＭＴＣＤを優先順位が低いＭＴＣＤであると判断する。

（ｇ）優先順位が高いＭＴＣＤでない旨を示すインジケータ。優先順位が高いＭＴＣＤでない旨を示すインジケータが含まれていなければ、ＨｅＮＢは、ＭＴＣＤを優先順位が高いＭＴＣＤであると判断する。

ここで優先順位について「低い」、あるいは「高い」と記載したが、優先順位インジケータが２値である必要はない。優先順位が複数あってもよい。優先順位インジケータは、例えば整数で示されてもよい。具体例として、優先順位インジケータが、「０」、「１」、「２」、「３」と示され、数字が大きいほど優先順位が高いとする。この具体例の場合、優先順位インジケータが「０」または「１」のＭＴＣＤは、集線処理による制御遅延に寛容であるとして、ＨｅＮＢは、該ＭＴＣＤからコアネットワークへのデータを集線（concentrate）する。これに対し、優先順位インジケータが「２」または「３」のＭＴＣＤは、集線処理による制御遅延に敏感であるとして、ＨｅＮＢは、該ＭＴＣＤからコアネットワークへのデータは集線しない。

ＭＴＣＤが優先順位の低いＭＴＣＤであるか否かの区別を、ＨｅＮＢへ通知する方法の具体例として、以下の（１），（２）の２つを開示する。

（１）ＲＲＣメッセージ、あるいはＲＲＣシグナリングを用いて、ＭＴＣＤが優先順位の低いＭＴＣＤであるか、優先順位の高いＭＴＣＤであるかの区別をＨｅＮＢへ通知する。またＲＲＣメッセージ、あるいはＲＲＣシグナリングに、優先順位インジケータをマッピングする。ＲＲＣシグナリングの具体例としては、「RRC Connection Request」（非特許文献２参照）などがある。後述する具体例（２）と比較して、本具体例（１）は、ＨｅＮＢが、集線処理の対象であるコアネットワークへのデータを受信する前に、ＭＴＣＤであるか否かの判断が可能となる。したがって、ＨｅＮＢでの集線処理における制御遅延を防止することができる。

（２）集線処理を行うコアネットワークへのデータを用いて、ＭＴＣＤが優先順位の低いＭＴＣＤであるか、優先順位の高いＭＴＣＤであるかの区別をＨｅＮＢへ通知する。またコアネットワークへのデータ（以下「コアネットワークデータ」という場合がある）に、優先順位インジケータをマッピングする。また、コアネットワークデータのヘッダーまたはフッターに、優先順位インジケータをマッピングするようにしてもよい。コアネットワークデータのヘッダーまたはフッターを用いて、ＵＥがＭＴＣＤであるか、ＭＴＣＤ以外であるかの区別が可能となれば、ＨｅＮＢがＭＴＣＤからコアネットワークへのメッセージの中身を常に解釈しなくてよくなる。これによって、ＨｅＮＢの処理の負荷を軽減することができる。

次に、実施の形態１の変形例１を用いた具体的な動作例を、図１８を用いて説明する。図１８は、実施の形態１の変形例１における集線処理に関するＨｅＮＢの処理手順を示すフローチャートである。図１８において、図１６に示すステップに対応するステップについては、同一の参照符を付して、共通する説明を省略する。

本動作例では、ＨｅＮＢにおける集線処理の対象である、ＭＴＣＤからコアネットワークへのデータの具体例として、ＮＡＳシグナリングの場合について開示する。また、ＨｅＮＢが、傘下の移動端末（ＵＥ）がＭＴＣＤであるか、ＭＴＣＤ以外であるかを区別する方法の具体例として、ＲＲＣメッセージ「RRC Connection Request」にＭＴＣＤインジケータをマッピングする場合について開示する。また、ＨｅＮＢが、傘下のＭＴＣＤが優先順の低いＭＴＣＤであるか、優先順位の高いＭＴＣＤであるかを区別する方法の具体例として、ＲＲＣメッセージ「RRC Connection Request」に優先順位インジケータをマッピングする場合について開示する。

ＨｅＮＢは、前述のステップＳＴ１６０１〜ステップＳＴ１６０３の処理を順次行う。本変形例では、ＨｅＮＢは、ステップＳＴ１６０３において、ＵＥがＭＴＣＤであると判断した場合は、ステップＳＴ１８０１へ移行し、ＵＥがＭＴＣＤではないと判断した場合は、ステップＳＴ１６０５へ移行する。

ステップＳＴ１８０１において、ＨｅＮＢは、ＲＲＣメッセージにマッピングされる優先順位インジケータを確認し、ステップＳＴ１８０２へ移行する。

ステップＳＴ１８０２において、ＨｅＮＢは、ステップＳＴ１８０１で確認した優先順位インジケータに基づいて、ＲＲＣメッセージを優先順位が低いＭＴＣＤから受信したか否か、すなわち、ステップＳＴ１６０１で受信したＲＲＣメッセージを送信したＭＴＣＤが優先順位の低いＭＴＣＤであるか否かを判断する。ＨｅＮＢは、ＲＲＣメッセージを優先順位が低いＭＴＣＤから受信した、すなわちＭＴＣＤが優先順位の低いＭＴＣＤであると判断した場合は、ステップＳＴ１６０４へ移行し、前述の処理を行う。ＨｅＮＢは、ＲＲＣメッセージを優先順位が低いＭＴＣＤから受信していない、すなわちＭＴＣＤが優先順位の低いＭＴＣＤではないと判断した場合は、ステップＳＴ１６０５へ移行し、前述の処理を行う。

実施の形態１の変形例１における移動体通信システムのシーケンスの具体例については、図１７に示すステップＳＴ１７０５とステップＳＴ１７０６との間に、図１８に示すステップＳＴ１８０１およびステップＳＴ１８０２が設けられること以外は、図１７に示す実施の形態１における移動体通信システムのシーケンスと同様であるので、図示および説明を省略する。

実施の形態１の変形例１によって、実施の形態１の効果に加えて、以下の効果を得ることができる。遅延に寛容なＭＴＣＤについては、実施の形態１と同様の処理を実行することによって、実施の形態１と同様に、コアネットワークの混雑を緩和することができる。さらに、遅延発生に敏感なＭＴＣＤについては、ＨｅＮＢによる集線処理を行わないようにすることができるので、集線処理による制御遅延の影響を受けないようにすることができる。

実施の形態１変形例２．
実施の形態１の変形例２では、前述の実施の形態１の開始時期および終了時期について開示する。

実施の形態１の変形例２での解決策を以下に示す。実施の形態１での解決策と異なる部分を中心に説明する。説明していない部分については、実施の形態１と同様とする。

コアネットワークであるＭＭＥ、ＳＧＳＮなどの指示によって、実施の形態１の処理の実行を開始する。コアネットワークであるＭＭＥ、ＳＧＳＮなどの指示によって、実施の形態１の処理の実行を停止する。

コアネットワークであるＭＭＥ、ＳＧＳＮなどが、ＨｅＮＢへ実施の形態１の処理（以下「集線処理」とも称する）の開始（以下「集線ＯＮ」とも称する）を指示するきっかけ（トリガ）の具体例として、以下の（１）〜（３）の３つを開示する。（１）コアネットワークであるＭＭＥ、ＳＧＳＮなどのエンティティ、すなわち構成要素が過負荷（Overload）となった場合。（２）コアネットワークであるＭＭＥ、ＳＧＳＮなどの処理負荷が閾値以上となった場合。コアネットワークであるＭＭＥ、ＳＧＳＮなどのＭＴＣＤ関連の処理負荷が閾値以上となった場合としてもよい。（３）通信量が閾値以上となった場合。ＭＴＣＤ関連の通信量が閾値以上となった場合としてもよい。通信量は、ＭＭＥとＨｅＮＢとの間の通信量としてもよい。またＳＧＳＮとＨｅＮＢとの間の通信量としてもよい。

コアネットワークが、集線処理の停止（以下「集線ＯＦＦ」とも称する）を指示するきっかけの具体例として、以下の（１）〜（３）の３つを開示する。（１）コアネットワークであるＭＭＥ、ＳＧＳＮなどのエンティティが過負荷（Overload）でなくなった場合。（２）コアネットワークであるＭＭＥ、ＳＧＳＮなどの処理負荷が閾値未満となった場合。コアネットワークであるＭＭＥ、ＳＧＳＮなどのＭＴＣＤ関連の処理負荷が閾値未満となった場合としてもよい。（３）通信量が閾値未満となった場合。ＭＴＣＤ関連の通信量が閾値未満となった場合としてもよい。通信量は、ＭＭＥとＨｅＮＢとの間の通信量としてもよい。またＳＧＳＮとＨｅＮＢとの間の通信量としてもよい。

コアネットワークであるＭＭＥ、ＳＧＳＮなどが、ＨｅＮＢへの集線ＯＮ、あるいは集線ＯＦＦの指示に用いるプロトコルの具体例としては、Ｓ１−ＡＰなどがある。

コアネットワークであるＭＭＥ、ＳＧＳＮなどが、ＨｅＮＢへ集線ＯＮを指示するシグナリングの具体例として、以下の（１）〜（４）の４つを開示する。（１）集線ＯＮ、あるいは開始、あるいはスタートを示すシグナリングを新設する。（２）ＮＡＳメッセージの終端ＯＮ、あるいは開始、あるいはスタートを示すシグナリングを新設する。（３）ＮＡＳメッセージの解釈ＯＮ、あるいは開始、あるいはスタートを示すシグナリング新設する。（４）既存のＳ１−ＡＰシグナリングである「Overload Start」を用いる（３ＧＰＰＴＳ３６．４１３Ｖ９．３．０（以下「非特許文献１４」という）参照）。

現在の規格では、ＭＭＥから「Overload Start」を受信したｅＮＢは、傘下の移動端末からのＲＲＣ接続（RRC Connection）などを拒絶する処理などを行う。これに対し、本実施の形態１の変形例２では、ＭＭＥから「Overload Start」を受信したｅＮＢは、傘下のＭＴＣＤに対して集線処理を行う。

具体例（４）は、具体例（１）〜（３）と比較して、新たなシグナリングを設ける必要がない点において、移動体通信システムが複雑化することを回避することができるという利点がある。また、現在の「Overload Start」の規格は、ｅＮＢ傘下の移動端末からのアクセス自体を拒絶する。これに対し、具体例（４）は、ノーマルＵＥ以外のＵＥであるＭＴＣＤからのデータを集線処理することによって、通信回数の削減、あるいは通信量の削減を行い、コアネットワーク側の過負荷状態を緩和させる。ノーマルＵＥからのデータは、通常通りコアネットワーク側へ送信するようにしてもよい。これによって、ｅＮＢの傘下の移動端末からのアクセス自体は拒絶されないようにすることができる。したがって、ユーザフレンドリーな移動体通信システムを構築することができる。

コアネットワークであるＭＭＥ、ＳＧＳＮなどが、ＨｅＮＢへ集線ＯＦＦを指示するシグナリングの具体例として、以下の（１）〜（４）の４つを開示する。（１）集線ＯＦＦ、あるいは停止、あるいはストップを示すシグナリングを新設する。（２）ＮＡＳメッセージの終端ＯＦＦ、あるいは停止、あるいはストップを示すシグナリングを新設する。（３）ＮＡＳメッセージの解釈ＯＦＦ、あるいは停止、あるいはストップを示すシグナリングを新設する。（４）既存のＳ１−ＡＰシグナリングである「Overload stop」を用いる（非特許文献１４参照）。

現在の規格では、ＭＭＥから「Overload stop」を受信したｅＮＢは、ＭＭＥに対して通常の操作を開始する。これに対し、本実施の形態１の変形例２では、ＭＭＥから「Overload stop」を受信したｅＮＢは、傘下のＭＴＣＤに対して集線処理を停止する。

具体例（４）は、具体例（１）〜（３）と比較して、新たなシグナリングを設ける必要がない点において、移動体通信システムが複雑化することを回避することができるという利点がある。また、ＭＭＥの過負荷状態が解消した場合には、ノーマルＵＥ以外のＵＥであるＭＴＣＤからのデータについても、遅延が発生し得る集線処理を停止することができる。したがって、ユーザフレンドリーな移動体通信システムを構築することができる。

次に、実施の形態１の変形例２を用いた具体的な動作例を、図１９を用いて説明する。図１９は、実施の形態１の変形例２における移動体通信システムのシーケンスを示す図である。ＨｅＮＢの傘下に、ＭＴＣＤ＿１〜ＭＴＣＤ＿ｎが存在するとする。

本動作例では、コアネットワークであるＭＭＥ、ＳＧＳＮなどが、ＨｅＮＢへ集線処理の開始を指示するきっかけの具体例として、通信量が閾値以上となった場合について開示する。また、コアネットワークであるＭＭＥ、ＳＧＳＮなどが、ＨｅＮＢへ集線処理の停止を指示するきっかけの具体例として、通信量が閾値未満となった場合について開示する。コアネットワークであるＭＭＥ、ＳＧＳＮなどが、ＨｅＮＢへ集線ＯＮを指示するシグナリングの具体例として、集線ＯＮを示すシグナリングを新設する場合について開示する。また、コアネットワークであるＭＭＥ、ＳＧＳＮなどが、ＨｅＮＢへ集線ＯＦＦを指示するシグナリングの具体例として、集線ＯＦＦを示すシグナリングを新設する場合について開示する。

ステップＳＴ１９０１において、ＭＭＥは、ＭＭＥとＨｅＮＢとの間の通信量が閾値以上となったか否かを判断する。ＭＭＥは、前記通信量が閾値以上となったと判断した場合は、ステップＳＴ１９０２へ移行する。ＭＭＥは、前記通信量が閾値以上となっていない、すなわち閾値未満であると判断した場合は、ステップＳＴ１９０４へ移行する。

ステップＳＴ１９０２において、ＭＭＥは、ＨｅＮＢへ集線ＯＮを示すシグナリングを通知する。

ステップＳＴ１９０４において、ＭＭＥは、ＨｅＮＢへ集線ＯＦＦを示すシグナリングを通知する。

ステップＳＴ１９０６において、ＨｅＮＢは、集線ＯＮを示すシグナリングを受信したか否かを判断する。集線ＯＮを示すシグナリングを受信したと判断した場合は、ステップＳＴ１９０３へ移行する。集線ＯＮを示すシグナリングを受信していないと判断した場合は、ステップＳＴ１９０５へ移行する。また、図示はしていないが、ステップＳＴ１９０６において集線ＯＮを示すシグナリングを受信していないと判断した後に、ＨｅＮＢは、集線ＯＦＦを示すシグナリングを受信したか否かを判断してもよい。集線ＯＦＦを示すシグナリングを受信したと判断した場合に、ステップＳＴ１９０５へ移行するようにしてもよい。集線ＯＦＦを示すシグナリングを受信していないと判断した場合は、通常の処理を行うようにしてもよい。

ステップＳＴ１９０３において、ＨｅＮＢは、傘下のＭＴＣＤからコアネットワークへのデータに対する集線処理を実行する。また、ステップＳＴ１９０３において、ＨｅＮＢが通常の「RRC Connection Request」を受信した場合の処理（非特許文献２参照）を省略してもよい。また、ステップＳＴ１９０３において、ＨｅＮＢは、「RRC Connection Request」を送信したＭＴＣＤに対して、「RRC Connection reject」を通知してもよい。また、「RRC Connection reject」に、ＭＴＣＤからコアネットワークへのデータを受信した旨を示す情報をマッピングしてもよい。また「RRC Connection reject」に、ＭＴＣＤからコアネットワークへのデータの再送を要求する情報をマッピングしてもよい。

ステップＳＴ１９０５において、ＨｅＮＢは、傘下のＭＴＣＤからコアネットワークへのデータに対する集線処理を実行しない。

本変形例では、実施の形態１と組み合わせた例について主に記載したが、実施の形態１の変形例１とも組み合わせて用いることができる。

実施の形態１の変形例２によって、実施の形態１の効果に加えて、以下の効果を得ることができる。本実施の形態１の変形例２を用いることによって、コアネットワークの混雑、あるいはコアネットワークのエンティティに過負荷が発生した場合に、コアネットワークの意思によって、ＨｅＮＢの集線処理を開始することができる。集線処理の開始によって、移動端末へのサービスは継続したまま、コアネットワークの混雑を緩和することができる。

また、コアネットワークの混雑が緩和、あるいはコアネットワークのエンティティの過負荷が解消された場合には、コアネットワークの意思によって、ＨｅＮＢの集線処理を停止することができる。常に、傘下のＭＴＣＤからコアネットワークへのデータを集線する方法である実施の形態１と比較して、集線処理の停止によって、集線処理で発生するＭＴＣＤサービスへの制御遅延が解消され、ユーザフレンドリーな移動体通信システムを構築することができる。

実施の形態１変形例３．
前述の実施の形態１の変形例２を用いた場合、以下の課題が発生する。集線処理を行う能力を有するＨｅＮＢと、集線処理を行う能力を有していないＨｅＮＢとが存在する場合を考える。集線処理を行う能力を有していないＨｅＮＢに対して、コアネットワークであるＭＭＥ、ＳＧＳＮなどが、実施の形態１の変形例２の処理を実行して、集線処理の開始や停止の指示を通知することは無駄となる。具体的には、コアネットワークからＨｅＮＢまでの通信リソースの無駄、およびコアネットワークの処理の無駄が発生する。

実施の形態１の変形例３での解決策を以下に示す。実施の形態１および実施の形態１の変形例２での解決策と異なる部分を中心に説明する。説明していない部分については、実施の形態１および実施の形態１の変形例２と同様とする。

ＨｅＮＢが、ＭＴＣＤからのデータの集線処理に関する能力情報をコアネットワークであるＭＭＥ、ＳＧＳＮなどへ通知する。コアネットワークは、ＭＴＣＤからのデータの集線処理を行う能力があるＨｅＮＢに対して、前述の実施の形態１の変形例２の処理を実行する。

ＨｅＮＢがコアネットワークへ通知する集線処理に関する能力情報の具体例として、以下の（１）〜（３）の３つを開示する。（１）ＭＴＣＤからのデータを集線することができるか否かの情報。あるいは、ＭＴＣＤからのデータを集線することができる旨の情報。あるいは、ＭＴＣＤからのデータを集線することができない旨の情報。（２）ＮＡＳシグナリングを解釈することができるか否かの情報。あるいは、ＮＡＳシグナリングを解釈することができる旨の情報。あるいは、ＮＡＳシグナリングを解釈することができない旨の情報。（３）ＮＡＳシグナリングを終端することができるか否かの情報。あるいは、ＮＡＳシグナリングを終端することができる旨の情報。あるいは、ＮＡＳシグナリングを終端することができない旨の情報。

前記集線処理に関する能力情報の具体例のうち、（１）のＭＴＣＤからのデータを集線することができる旨の情報、（２）のＮＡＳシグナリングを解釈することができる旨の情報、および（３）のＮＡＳシグナリングを終端することができる旨の情報を用いることは、集線処理を行う能力を有していないＨｅＮＢが、前記集線処理に関する能力情報をコアネットワークへ通知する必要がない点において有効である。

ＨｅＮＢが、集線処理に関する能力情報をコアネットワークへ通知するタイミングの具体例として、以下の（１）〜（３）の３つを開示する。（１）ＨｅＮＢ設置時。ＨｅＮＢの集線処理を行う能力に変更が生じることがない場合、通信リソースの無駄が発生しないという効果を得ることができる。（２）周期的。ＨｅＮＢの集線処理を行う能力に変更が生じる場合に有効である。また、周期的に能力情報が通知されるので、通信エラーに強いという効果を得ることができる。（３）ＨｅＮＢの能力変更時。ＨｅＮＢの集線処理を行う能力に変更が生じる場合に有効である。具体例（２）と比較して、能力変更時のみの通知であるので、通信リソースの無駄が発生しないという効果を得ることができる。

ＨｅＮＢが、集線処理に関する能力情報をコアネットワークへ通知する際のシグナリングの具体例として、以下の（１）〜（３）の３つを開示する。

（１）新たにＳ１シグナリング、あるいはＳ１メッセージを設ける。制御用のＳ１シグナリングを設けるようにしてもよい。また、受信側であるＭＭＥ、ＳＧＳＮなどからの応答メッセージ不要のＳ１シグナリングを設けるようにしてもよい。応答メッセージ不要のＳ１シグナリングは、「クラス２（Class2）」とも称される（非特許文献１４参照）。また移動端末とは無関係のＳ１シグナリングを設けるようにしてもよい。移動端末とは無関係のＳ１シグナリングは、「non UE associated Signalling」とも称される（非特許文献１４参照）。新たに設けるＳ１シグナリングにマッピングするパラメータとしては、前記「ＨｅＮＢがコアネットワークへ通知する集線処理に関する能力情報」がある。

（２）新たにＳ１シグナリング、あるいはＳ１メッセージを設ける。制御用のＳ１シグナリングを設けるようにしてもよい。また、受信側であるＭＭＥ、ＳＧＳＮなどからの応答メッセージが必要なＳ１シグナリングを設けるようにしてもよい。応答メッセージ必要なＳ１シグナリングは、「クラス１（Class1）」とも称される（非特許文献１４参照）。また移動端末とは無関係のＳ１シグナリングを設けるようにしてもよい。新たに設けるＳ１シグナリングにマッピングするパラメータとしては、前記「ＨｅＮＢがコアネットワークへ通知する集線処理に関する能力情報」がある。

（３）既存のＳ１シグナリングを用いる。既存の制御用のＳ１シグナリングを用いるようにしてもよい。また、既存の移動端末とは無関係のＳ１シグナリングを用いるようにしてもよい。既存のＳ１シグナリングに追加が必要なパラメータとしては、前記「ＨｅＮＢがコアネットワークへ通知する集線処理に関する能力情報」がある。具体例（１），（２）と比較して、新たなシグナリングを設ける必要がない点において、移動体通信システムが複雑化することを回避することができるという利点がある。

次に、既存のＳ１シグナリングの具体例として、以下の（ａ），（ｂ）の２つを開示する。

（ａ）「S1 SETUP REQUEST」（非特許文献１４参照）。「S1 SETUP REQUEST」の目的は、ｅＮＢとＭＭＥとが、Ｓ１インタフェースを正しく共同利用するのに必要なアプリケーションレベルのデータを交換することである。既に含まれているパラメータは、ｅＮＢのＣＳＧ−ＩＤ、グローバルセル識別子およびＴＡＣなどのように、ｅＮＢ固有の情報である。ＨｅＮＢの集線処理に関する能力情報も、ＨｅＮＢ固有の情報である。したがって、ＨｅＮＢが集線処理に関する能力情報をコアネットワークへ通知するために「S1 SETUP REQUEST」を用いることによって、受信するＭＭＥがＨｅＮＢ固有の情報を一度に得ることができる。これによって、ＭＭＥの処理負荷の軽減、また移動体通信システムとしての制御遅延防止という効果を得ることができる。

（ｂ）「eNB Configuration Update」（非特許文献１４参照）。「eNB Configuration Update」の目的は、ｅＮＢとＭＭＥとが、Ｓ１インタフェースを正しく共同利用するのに必要なアプリケーションレベルのデータを更新することである。既に含まれているパラメータは、ｅＮＢのＣＳＧ−ＩＤおよびＴＡＣなどのように、ｅＮＢ固有の情報である。ＨｅＮＢの集線処理に関する能力情報も、ＨｅＮＢ固有の情報である。したがって、ＨｅＮＢが集線処理に関する能力情報をコアネットワークへ通知するために「eNB Configuration Update」を用いることによって、受信するＭＭＥがＨｅＮＢ固有の情報を一度に得ることができる。これによって、ＭＭＥの処理負荷の軽減、また移動体通信システムとしての制御遅延防止という効果を得ることができる。

次に、実施の形態１の変形例３を用いた具体的な動作例を、図２０を用いて説明する。図２０は、実施の形態１の変形例３における移動体通信システムのシーケンスを示す図である。図２０において、図１９に示すステップに対応するステップについては、同一の参照符を付して、共通する説明を省略する。

本動作例では、ＨｅＮＢが集線処理に関する能力情報をコアネットワークへ通知するタイミングの具体例として、ＨｅＮＢ設置時について開示する。

ステップＳＴ２００１において、ＨｅＮＢが設置される。ステップＳＴ２００２において、ＨｅＮＢは、ＭＭＥへＨｅＮＢの集線処理に関する能力情報を通知する。集線処理に関する能力情報を受信したＭＭＥは、該情報を記憶および管理する。

ステップＳＴ２００３において、ＭＭＥは、ステップＳＴ２００２で受信した集線処理に関する能力情報に基づいて、ＨｅＮＢが集線処理を行う能力があるか否かを判断する。ＭＭＥは、ＨｅＮＢが集線処理を行う能力があると判断した場合は、ステップＳＴ１９０１へ移行する。ＭＭＥは、ＨｅＮＢが集線処理を行う能力がないと判断した場合は、本実施の形態の本質的な部分ではないので、説明を省略することとして、処理を終了する。

ステップＳＴ２００３でＨｅＮＢが集線処理を行う能力があると判断された後は、前述の図１９と同様に、ＭＭＥおよびＨｅＮＢによって、ステップＳＴ１９０１〜ステップＳＴ１９０６の各処理が行われる。本変形例では、図２０に示すように、ステップＳＴ２００３の処理後にステップＳＴ１９０１の処理を行うようにしているが、ステップＳＴ２００３の処理とステップＳＴ１９０１の処理とは任意の順番で行ってもよく、ステップＳＴ１９０１の処理後にステップＳＴ２００３の処理を行うようにしてもよい。

本変形例では、実施の形態１および実施の形態１の変形例２と組み合わせた例について主に記載したが、実施の形態１の変形例１とも組み合わせて用いることができる。

実施の形態１の変形例３によって、実施の形態１および実施の形態１の変形例２の効果に加えて、以下の効果を得ることができる。集線処理を行う能力を有していないＨｅＮＢに対して、コアネットワークが集線処理の開始や停止の指示を通知することを防止することができる。これによって、コアネットワークからＨｅＮＢまでの通信リソースを有効に活用することができるとともに、コアネットワークの処理の負荷を軽減することができる。

実施の形態１変形例４．
本実施の形態１の変形例４では、実施の形態１の変形例３と同じ課題について別の解決策を開示する。実施の形態１の変形例４での解決策を以下に示す。実施の形態１および実施の形態１の変形例２での解決策と異なる部分を中心に説明する。説明していない部分については、実施の形態１および実施の形態１の変形例２と同様とする。

実施の形態１の変形例４では、集線処理を行う能力を有するＨｅＮＢに対しても、集線処理を行う能力を有していないＨｅＮＢに対しても、コアネットワークであるＭＭＥ、ＳＧＳＮなどは、前述の実施の形態１の変形例２の処理を実行する。集線処理の開始や停止の指示を受信したＨｅＮＢにおいて、集線処理を行う能力を有するか否かで動作を異ならせる。

集線処理を行う能力を有するＨｅＮＢの動作の具体例としては、実施の形態１、実施の形態１の変形例１、および実施の形態１の変形例２がある。

集線処理を行う能力を有していないＨｅＮＢの動作の具体例を、以下に開示する。まず、コアネットワークであるＭＭＥ、ＳＧＳＮなどから集線処理の開始指示を受信したＨｅＮＢの動作の具体例として、以下の（１）〜（４）の４つを開示する。

（１）傘下の移動端末からコアネットワークであるＭＭＥ、ＳＧＳＮなどへのデータの送受信を停止、あるいは拒否する。ＭＭＥへのデータの具体例として、ＮＡＳメッセージ、ＮＡＳシグナリングがある。

（２）傘下の移動端末からのＲＲＣ接続関連のシグナリングを拒否する。ＲＲＣ接続関連のシグナリングの具体例として、「RRC CONNECTION REQUEST」、「RRC CONNECTION Reestablishment Request」（非特許文献２参照）などがある。

（３）現行のＭＭＥから「Overload Start」を受信したときの動作を行う（非特許文献１４参照）。具体的には、緊急（emergency）呼以外のＲＲＣ接続設立を拒絶する。

（４）前記（１）〜（３）の組み合わせ。

コアネットワークであるＭＭＥ、ＳＧＳＮなどから集線処理の停止指示を受信したＨｅＮＢの動作の具体例としては、通常の動作を行うことが挙げられる。

次に、実施の形態１の変形例４を用いた具体的な動作例を、図２１を用いて説明する。図２１は、実施の形態１の変形例４における移動体通信システムのシーケンスを示す図である。図２１において、図１９に示すステップに対応するステップについては、同一の参照符を付して、共通する説明を省略する。

本動作例では、コアネットワークがＨｅＮＢへ集線ＯＮを指示するシグナリングの具体例として、既存のＳ１−ＡＰシグナリングである「Overload Start」を用いる場合について開示する。また、コアネットワークがＨｅＮＢへ集線ＯＦＦを指示するシグナリングの具体例として、既存のＳ１−ＡＰシグナリングである「Overload stop」を用いる場合について開示する。また、集線処理を行う能力を有していないＨｅＮＢが、コアネットワークから集線処理の開始指示を受信した場合の動作例として、現行の「Overload Start」を受信したときの動作を行う場合について開示する。

ステップＳＴ１９０１において、ＭＭＥは、ＭＭＥとＨｅＮＢとの間の通信量が閾値以上となったか否かを判断する。ＭＭＥは、前記通信量が閾値以上となったと判断した場合は、ステップＳＴ２１０１へ移行する。ＭＭＥは、前記通信量が閾値以上となっていない、すなわち閾値未満であると判断した場合は、ステップＳＴ２１０４へ移行する。

ステップＳＴ２１０１において、ＭＭＥは、ＨｅＮＢへ「Overload Start」を通知する。ステップＳＴ２１０４において、ＭＭＥは、ＨｅＮＢへ「Overload Stop」を通知する。

ステップＳＴ２１０７において、ＨｅＮＢは、「Overload Start」を受信したか否かを判断する。「Overload Start」を受信したと判断した場合は、ステップＳＴ２１０２へ移行する。「Overload Start」を受信していないと判断した場合は、ステップＳＴ２１０５へ移行する。図示はしていないが、ステップＳＴ２１０７において、「Overload Start」を受信していないと判断した後に、ＨｅＮＢは、「Overload Stop」を受信したか否かを判断してもよい。そして、「Overload Stop」を受信したと判断した場合に、ステップＳＴ２１０５へ移行し、「Overload Stop」を受信していないと判断した場合は、ステップＳＴ２１０６へ移行するようにしてもよい。

ステップＳＴ２１０２において、ＨｅＮＢは、自セルが集線処理を行う能力を有するか否かを判断する。ＨｅＮＢは、集線処理を行う能力を有すると判断した場合は、ステップＳＴ１９０３へ移行する。ＨｅＮＢは、集線処理を行う能力を有していないと判断した場合は、ステップＳＴ２１０３へ移行する。

ステップＳＴ１９０３において、ＨｅＮＢは、傘下のＭＴＣＤからコアネットワークへのデータに対する集線処理を実行して、処理を終了する。ステップＳＴ２１０３において、ＨｅＮＢは、傘下の移動端末からの緊急（emergency）呼以外のＲＲＣ接続設立を拒絶して、処理を終了する。

ステップＳＴ２１０５において、ＨｅＮＢは、自セルが集線処理を行う能力を有するか否かを判断する。ＨｅＮＢは、集線処理を行う能力を有すると判断した場合は、ステップＳＴ１９０５へ移行する。ＨｅＮＢは、集線処理を行う能力を有していないと判断した場合は、ステップＳＴ２１０６へ移行する。

ステップＳＴ１９０５において、ＨｅＮＢは、傘下のＭＴＣＤからコアネットワークへのデータに対する集線処理を実行しない。ステップＳＴ２１０６において、ＨｅＮＢは、通常動作を行う。

ステップＳＴ２１０５の判断処理を省略して、集線処理を行う能力の有無とは無関係に、ステップＳＴ２１０４においてＭＭＥから「Overload Stop」を受信したＨｅＮＢが、ステップＳＴ２１０６へ移行して通常動作を行うようにしてもよい。

実施の形態１の変形例４によって、実施の形態１および実施の形態１の変形例２の効果に加えて、以下の効果を得ることができる。実施の形態１の変形例３と比較して、ＨｅＮＢが自セルの集線処理に関する能力情報をコアネットワークへ通知する必要がなくなり、ＨｅＮＢとコアネットワークとの間の通信リソースを有効に活用することができる。

またコアネットワークが、傘下のＨｅＮＢの集線処理に行う能力の有無を記憶し、集線処理に関する能力の有無によって動作を分ける必要がなくなり（図２０のステップＳＴ２００３参照）、コアネットワークの処理の負荷を軽減することができる。

また、コアネットワークの混雑が発生し、コアネットワークがＨｅＮＢへ集線ＯＮを指示するシグナリングを通知した場合、ＨｅＮＢが集線処理を行う能力を有するか否かに関わらず、ＨｅＮＢとコアネットワークとの間の通信、あるいはコアネットワークの処理負荷の軽減につながる動作が開始される（図２１のステップＳＴ２１０３、ステップＳＴ１９０３参照）。したがって、ＨｅＮＢが集線処理を行う能力を有するか否かに関わらず、コアネットワークの混雑を回避することが可能となる。

実施の形態２．
本実施の形態２では、実施の形態１を用いてＨｅＮＢによって集線処理を行った後、ＨｅＮＢからコアネットワークであるＭＭＥ、ＳＧＳＮなどへデータを送信する具体的な方法について開示する。

実施の形態２での解決策を以下に示す。ＨｅＮＢがきっかけ（trigger）あるいは起点となって、傘下のＭＴＣＤからコアネットワークであるＭＭＥ、ＳＧＳＮ、ＭＴＣサーバなどへのデータを送信する。

ＨｅＮＢが、傘下のＭＴＣＤからコアネットワークであるＭＭＥ、ＳＧＳＮ、ＭＴＣサーバなどへのデータの送信のトリガとなる条件の具体例として、以下の（１），（２）の２つを開示する。

（１）ＨｅＮＢが、傘下のＭＴＣＤからの上りデータの受信とは無関係に、傘下のＭＴＣＤからのデータをコアネットワークへ送信する。該送信は、ＭＴＣＤ用リソースで行うようにしてもよい。ＭＴＣＤ用リソースの具体例としては、ＭＴＣＤ用の通信が許可された時間、あるいは許可された期間、あるいは許可されたリソースなどがある。ＭＴＣＤ用の通信が許可された時間または期間は、許可期間に相当する。ＭＴＣＤ用の通信が許可されたリソースは、許可リソースに相当する。ＭＴＣＤ用リソースの設定は、コアネットワークであるＭＭＥ、ＳＧＳＮ、ＭＴＣサーバなどがＨｅＮＢへ設定、あるいは更新してもよいし、静的に決定、すなわち予め決定されていてもよい。

前述の非特許文献９では、ｅＮＢがＭＴＣＤからのメッセージを受信した時点から、決められた時間だけメッセージを保留する。これに対し、本具体例では、ＨｅＮＢがＭＴＣＤからのメッセージを受信した時点と無関係に、ＭＴＣＤ用の通信が許可された時間などに、コアネットワークへ送信を行う。したがって本具体例では、コアネットワーク側が、ＨｅＮＢからＭＴＣＤ用の送信が行われる可能性のある時間を把握することが可能となる。非特許文献９では、コアネットワーク側で、ｅＮＢがＭＴＣＤからメッセージを受信する時点を把握することが不可能であるので、ＭＴＣＤからメッセージを受信した時点を基準として、ｅＮＢからＭＴＣＤ用の送信が行われる可能性のある時間を把握することは不可能である。したがって、非特許文献９と比較して、本具体例では、コアネットワークがＭＴＣＤによる負荷の調整を容易に行うことができる。

また、３ＧＰＰＴＲ２３．８８８Ｖ０．５．１（以下「非特許文献１５」という）では、ネットワークオペレータがＭＴＣＤに対して、予め定義された期間（period）のみネットワークにアクセスすることを許可することが開示されている。これに対し、本具体例では、ＭＴＣＤに対してネットワークへアクセスすることを許可する期間の設定を必要としない。したがって、コアネットワークから、多数存在するＭＴＣＤへの許可期間の通知、あるいは設定が不要となるので、無線リソースを有効に活用することができる。さらに、本具体例では、コアネットワークの各ＭＴＣＤの時間管理、あるいはコアネットワークとＭＴＣＤとの同期確立が不要となるので、通信システムが複雑化することを回避することができる。

（２）ＨｅＮＢが、傘下のＭＴＣＤからの上りデータの受信をきっかけに、傘下のＭＴＣＤからのデータをコアネットワークであるＭＭＥ、ＳＧＳＮ、ＭＴＣサーバなどへ送信する。

ＭＴＣＤからの上りデータの具体例として、以下の（ａ），（ｂ）の２つを開示する。

（ａ）ＲＲＣメッセージ、ＲＲＣシグナリングの受信。非特許文献９では、ｅＮＢがＮＡＳシグナリングの受信をきっかけに、ＭＴＣＤからのデータをコアネットワークへ送信することが開示されている。本具体例では、ＲＲＣシグナリングの受信をきっかけにして、ＭＴＣＤからのデータをコアネットワークへ送信する。これによって、非特許文献９と比較して、早い段階で集線処理の準備を行うことが可能となる。ＲＲＣメッセージを受信した時点から、予め決められた時間の経過後、あるいはコアネットワークから設定された時間の経過後に、傘下のＭＴＣＤからのデータをコアネットワークへ送信するようにしてもよい。あるいは、予め決められた回数、傘下のＭＴＣＤからのＲＲＣメッセージを受信した場合に、傘下のＭＴＣＤからのデータをコアネットワークへ送信するようにしてもよい。

（ｂ）３ＧＰＰによって標準規格化された移動体通信システム以外の通信方式で送信された上りデータの受信。本具体例によって、ＭＴＣＤが、３ＧＰＰで標準規格化された移動体通信システムとしての無線環境の悪い場所に設定されている場合であっても、前記の具体例（２）のように、ＨｅＮＢが傘下のＭＴＣＤからの上りデータの受信をきっかけとして、傘下のＭＴＣＤからのデータをコアネットワークへ送信することが可能となる。

３ＧＰＰによって標準規格化された移動体通信システム以外の通信方式で送信された上りデータを受信した時点から、予め決められた時間の経過後に、あるいはコアネットワークから設定された時間の経過後に、傘下のＭＴＣＤからのデータをコアネットワークへ送信するようにしてもよい。あるいは、予め決められた回数、傘下のＭＴＣＤから３ＧＰＰによって標準規格化された移動体通信システム以外の通信方式で送信された上りデータを受信した場合に、傘下のＭＴＣＤからのデータをコアネットワークへ送信するようにしてもよい。

ＨｅＮＢが、傘下のＭＴＣＤからコアネットワークであるＭＭＥ、ＳＧＳＮ、ＭＴＣサーバなどへのデータをＳ−ＧＷ経由で送信する際のシグナリングの具体例を、以下に開示する。ユーザデータグラムプロトコル（User Datagram Protocol：ＵＤＰ）を用いて送信する（非特許文献１３参照）。該データはユーザデータであってもよい。

ＨｅＮＢが、傘下のＭＴＣＤからコアネットワークであるＭＭＥ、ＳＧＳＮ、ＭＴＣサーバなどへのデータをＭＭＥ経由で送信する際のシグナリングの具体例を、以下に開示する。Ｓ１インタフェース（「Ｓ１−ＭＭＥ」あるいは「Ｓ１−Ｕ」とも称される）を用いる。該データは制御データであってもよい。

Ｓ１インタフェースを用いて、傘下のＭＴＣＤからコアネットワークへのデータを送信する際の更なる具体例を、以下に開示する。新たにＳ１シグナリング、あるいはＳ１メッセージを設ける。制御用のＳ１シグナリングを設けるようにしてもよい。また、受信側であるＭＭＥ、ＳＧＳＮなどからの応答メッセージ不要のＳ１シグナリングを設けるようにしても良い。応答メッセージ不要のＳ１シグナリングは、「クラス２（Class2）」とも称される（非特許文献１４参照）。また移動端末とは無関係のＳ１シグナリングを設けるようにしてもよい。移動端末とは無関係のＳ１シグナリングは、「non UE associated Signaling」とも称される（非特許文献１４参照）。

新たに設けるＳ１シグナリングにマッピングするパラメータの具体例として、以下の（１）〜（８）の８つを開示する。（１）ＨｅＮＢの識別子。受信側で、どのＨｅＮＢ経由のデータであるかを識別可能となるので、ＰＣＩ（Physical Cell Identity）、ＣＧＩ（Cell Global Identity）などであってもよい。（２）ＭＴＣＤの識別子。受信側で、どのＭＴＣＤからのデータであるかを識別可能となるので、ＩＭＳＩ、ＭＴＣＤの製造番号などであってもよい。本パラメータは、集線処理を行うＭＴＣＤの数だけ、すなわち集線処理を行うＭＴＣＤの数と同数あってもよい。（３）ＭＴＣ用のＰＤＵ（Protocol Data Unit）。ＰＤＵとは、同位レイヤ間で意味を持つデータの固まりである。これによって、新たに設けるＳ１シグナリングに、ＭＴＣＤからコアネットワークへのデータをマッピングすることが可能となる。本パラメータは、集線処理を行うＭＴＣＤの数だけ、すなわち集線処理を行うＭＴＣＤの数と同数あってもよい。（４）ＭＴＣ用のＳＤＵ（Service Data Unit）。ＳＤＵとは、上位レイヤから転送依頼されたデータの固まりである。これによって、新たに設けるＳ１シグナリングに、ＭＴＣＤからコアネットワークへのデータをマッピングすることが可能となる。本パラメータは、集線処理を行うＭＴＣＤの数だけ、すなわち集線処理を行うＭＴＣＤの数と同数あってもよい。（５）サービスの種類、あるいはサービスの識別子。これによってサービス別にデータの送信先が異なる場合などに対応することができる。また、１つのＭＴＣＤで複数のサービスに対応する場合であっても、サービス別にデータの送信先が異なる場合などに対応することができる。（６）どのＭＴＣサーバ向けのデータであるか、あるいはどのＭＴＣユーザ向けのデータであるかを示す情報。具体例としては、ＭＴＣサーバの識別子、あるいはＭＴＣユーザの識別子。これによって、送信先を適切に変更することができる。（７）前記（５）と前記（６）との組み合わせを示す識別子、あるいはインデックス。（８）前記（１）〜（７）の組み合わせ。

次に、実施の形態２を用いた具体的な動作例を、図２２を用いて説明する。図２２は、実施の形態２における移動体通信システムのシーケンスを示す図である。図２２において、図１７および図１９に示すステップに対応するステップについては、同一の参照符を付して、共通する説明を省略する。

本動作例では、ＨｅＮＢが、傘下のＭＴＣＤからコアネットワークへのデータの送信のトリガとなる条件の具体例として、ＨｅＮＢが、傘下のＭＴＣＤからの上りデータの受信とは無関係に、傘下のＭＴＣＤからのデータをコアネットワークへ送信する場合について開示する。またコアネットワークへの送信は、ＭＴＣＤ用の通信が許可された期間において行われる場合について開示する。

ステップＳＴ２２０１において、ＭＭＥは、ＨｅＮＢが傘下のＭＴＣＤからのデータをコアネットワークへ送信することが許可された期間を表す期間情報をＨｅＮＢへ通知する。換言すれば、ＭＭＥは、ＭＴＣＤ用の通信を許可する期間を表す期間情報をＨｅＮＢへ通知する。

次に、ＭＴＣＤ＿１が前述のステップＳＴ１７０３の処理を行い、ＭＴＣＤ＿ｎが前述のステップＳＴ１７０４の処理を行う。ＭＴＣＤ＿１およびＭＴＣＤ＿ｎから送信された「RRC Connection Request」を受信したＨｅＮＢは、前述のステップＳＴ１７０５およびステップＳＴ１９０３の処理を行う。ステップＳＴ１９０３の処理を終了した後は、ステップＳＴ２２０２へ移行する。

ステップＳＴ２２０２において、ＨｅＮＢは、ステップＳＴ２２０１で受信した期間情報に基づいて、ＭＴＣＤ用の通信が許可された期間であるか否かを判断する。ＨｅＮＢは、ＭＴＣＤ用の通信が許可された期間であると判断した場合は、ステップＳＴ２２０３へ移行する。ＨｅＮＢは、ＭＴＣＤ用の通信が許可された期間でないと判断した場合は、ステップＳＴ２２０２の判断処理を繰り返す。

ステップＳＴ２２０３において、ＨｅＮＢは、傘下のＭＴＣＤからコアネットワークへのデータを、Ｓ１インタフェースを用いてＭＭＥへ送信する。本動作例では、実際には、ステップＳＴ１７０３の処理の後に、ステップＳＴ１７０５、ステップＳＴ１９０３およびステップＳＴ２２０２に相当する処理が行われるが、理解を容易にするために、図示および説明を省略している。

また、ステップＳＴ１７０５において、ＭＴＣＤからのデータではないと判断された場合は、本実施の形態の本質的な部分ではないので、説明を省略することとして、処理を終了する。あるいは、ステップＳＴ１７０５において、ＭＴＣＤからのデータではないと判断された場合は、ステップＳＴ２２０２と同様の処理を行い、ＭＴＣＤ用の通信が許可された期間に、ＭＴＣＤからのデータは無いことを示してもよい。例えば、「empty」を通知してもよい。これによって、ＭＭＥが、ＭＴＣＤ用の通信が許可された期間に何らかのデータを受信することになり、ＨｅＮＢとＭＭＥとの間の通信エラーを低減することができる。

また、ステップＳＴ２２０２の判断処理を繰り返している間、ＨｅＮＢが別途、傘下のＭＴＣＤからＲＲＣメッセージを受信し、ステップＳＴ１７０５、ステップＳＴ１９０３およびステップＳＴ２２０２に相当する処理が行われることも考えられるが、理解を容易にするために、説明を省略している。

次に、実施の形態２を用いた具体的な動作例を、図２３を用いて説明する。図２３は、実施の形態２における移動体通信システムのシーケンスを示す図である。図２３において、図１７および図２２に示すステップに対応するステップについては、同一の参照符を付して、共通する説明を省略する。

本動作例では、ＨｅＮＢが、傘下のＭＴＣＤからコアネットワークへのデータの送信のトリガとなる条件の具体例として、ＨｅＮＢが、傘下のＭＴＣＤからの上りデータの受信をきっかけに、傘下のＭＴＣＤからのデータをコアネットワークへ送信する場合について開示する。また上りデータの具体例としては、ＲＲＣシグナリングである場合について開示する。

ステップＳＴ２３０１において、ＭＭＥは、ＲＲＣメッセージを受信したときから、ＭＴＣＤからのデータをコアネットワークへ送信するまでの時間をＨｅＮＢに設定する。換言すれば、ＭＭＥは、ＲＲＣメッセージを受信してから集線処理するまでの時間である集線処理時間をＨｅＮＢに設定する。

次に、ステップＳＴ１７０３において、ＭＴＣＤ＿１が「RRC Connection Request」をＨｅＮＢに送信する処理を行い、ステップＳＴ１７０４において、ＭＴＣＤ＿ｎが「RRC Connection Request」をＨｅＮＢに送信する処理を行う。ＭＴＣＤ＿１およびＭＴＣＤ＿ｎから送信された「RRC Connection Request」を受信したＨｅＮＢは、前述のステップＳＴ１７０５およびステップＳＴ１９０３の処理を行う。ステップＳＴ１９０３の処理を終了した後は、ＨｅＮＢは、ステップＳＴ２３０２へ移行する。

ステップＳＴ２３０２において、ＨｅＮＢは、ＲＲＣメッセージの受信から、ステップＳＴ２３０１で設定された集線処理時間が経過したか否かを判断する。ＨｅＮＢは、集線処理時間が経過したと判断した場合は、ステップＳＴ２２０３へ移行する。ＨｅＮＢは、集線処理時間が経過していないと判断した場合、ステップＳＴ２３０２の判断処理を繰り返す。本動作例では、ＨｅＮＢは、ステップＳＴ２３０２において、集線処理時間が経過したか否かを判断する処理を行うが、前回、傘下のＭＴＣＤからコアネットワークへのデータを送信してから最初に受信したＲＲＣメッセージの受信から、集線処理時間が経過したか否かを判断する処理を行うようにしてもよい。

本動作例では、実際には、ステップＳＴ１７０３の処理の後に、ステップＳＴ１７０５、ステップＳＴ１９０３およびステップＳＴ２３０２に相当する処理が行われるが、理解を容易にするために、説明を省略している。

また、ステップＳＴ２３０２の判断処理を繰り返している間、ＨｅＮＢが別途、傘下のＭＴＣＤからＲＲＣメッセージを受信し、ステップＳＴ１７０５、ステップＳＴ１９０３およびステップＳＴ２３０２に相当する処理が行われることも考えられるが、理解を容易にするために、説明を省略している。

本実施の形態では、実施の形態１と組み合わせた例について主に記載したが、本実施の形態は、実施の形態１の変形例１、実施の形態１の変形例２、実施の形態１の変形例３および実施の形態１の変形例４とも組み合わせて用いることができる。

また、本実施の形態は、非特許文献９に開示されているｅＮＢがＭＴＣＤグループに共通のシグナリングメッセージを引き止め（hold back）、寄せ集める（aggregation）際にも用いることができる。

実施の形態２によって、以下の効果を得ることができる。ＨｅＮＢが、傘下のＭＴＣＤからコアネットワークへのデータを集線処理した後、ＨｅＮＢからコアネットワークへデータを送信する方法を確立することができる。

実施の形態２変形例１．
実施の形態２の変形例１では、実施の形態２におけるＨｅＮＢが、傘下のＭＴＣＤからコアネットワークであるＭＭＥ、ＳＧＳＮ、ＭＴＣサーバなどへのデータをＭＭＥ経由でＳ１インタフェースを用いて送信する際の他の具体例を開示する。

新たにＳ１シグナリング、あるいはＳ１メッセージを設ける。制御用のＳ１シグナリングを設けるようにしてもよい。また、受信側であるＭＭＥ、ＳＧＳＮなどからの応答メッセージが必要なＳ１シグナリングを設けるようにしてもよい。応答メッセージが必要なＳ１シグナリングは、「クラス１（Class1）」とも称される（非特許文献１４参照）。

ＨｅＮＢが、ＭＭＥからの応答メッセージにおいて、成功を示すメッセージ、たとえば「Successfulメッセージ」あるいは「Ackメッセージ」を受信した場合、次のデータの送信を行うようにしてもよい。ＨｅＮＢが、ＭＭＥからの応答メッセージにおいて、失敗を示すメッセージ、たとえば「Unsuccessfulメッセージ」、「failureメッセージ」あるいは「Nackメッセージ」を受信した場合、再送を行うようにしてもよい。また、移動端末とは無関係のＳ１シグナリングを設けるようにしてもよい。移動端末とは無関係のＳ１シグナリングは、「non UE associated Signaling」とも称される（非特許文献１４参照）。

新たに設けるＳ１シグナリングにマッピングするパラメータの具体例は、前述の実施の形態２と同様であるので、説明を省略する。

次に、実施の形態２の変形例１を用いた具体的な動作例を、図２４を用いて説明する。図２４は、実施の形態２の変形例１における移動体通信システムのシーケンスを示す図である。図２４において、図１７および図２２に示すステップに対応するステップについては、同一の参照符を付して、共通する説明を省略する。

本動作例では、ＨｅＮＢが、傘下のＭＴＣＤからコアネットワークへの送信のトリガとなる条件の具体例として、ＨｅＮＢが、傘下のＭＴＣＤからの上りデータの受信とは無関係に、傘下のＭＴＣＤからのデータをコアネットワークへ送信する場合について開示する。またコアネットワークへの送信は、ＭＴＣＤ用の通信が許可された期間において行われる場合について開示する。

ＭＭＥが前述のステップＳＴ２２０１の処理を行う。次に、ステップＳＴ１７０３において、ＭＴＣＤ＿１が「RRC Connection Request」をＨｅＮＢに送信する処理を行い、ステップＳＴ１７０４において、ＭＴＣＤ＿ｎが「RRC Connection Request」をＨｅＮＢに送信する処理を行う。ＭＴＣＤ＿１およびＭＴＣＤ＿ｎから送信された「RRC Connection Request」を受信したＨｅＮＢは、前述のステップＳＴ１７０５およびステップＳＴ１９０３の処理を行う。ステップＳＴ１９０３の処理を終了した後は、ＨｅＮＢは、前述のステップＳＴ２２０２およびステップＳＴ２２０３の処理を行う。

次に、ステップＳＴ２４０１において、ステップＳＴ２２０３でＨｅＮＢからクラス１のＳ１インタフェースを用いたシグナリングによって傘下のＭＴＣＤからコアネットワークへのデータを受信したＭＭＥは、受信したデータのメッセージに対する応答メッセージをＨｅＮＢへ送信する。

次に、ステップＳＴ２４０２において、ＨｅＮＢは、成功を示すメッセージ、たとえばＡｃｋメッセージを受信したか否かを判断する。具体的には、ＨｅＮＢは、ステップＳＴ２４０１で受信した応答メッセージが成功を示すメッセージであるか否か、たとえばＡｃｋメッセージであるか否かを判断する。ＨｅＮＢは、応答メッセージが成功を示すメッセージであると判断した場合、たとえばＡｃｋメッセージであると判断した場合は、ステップＳＴ２４０４へ移行する。ＨｅＮＢは、応答メッセージが成功を示すメッセージでないと判断した場合、すなわち、失敗を示すメッセージ、たとえばＮａｃｋメッセージであると判断した場合は、ステップＳＴ２４０３へ移行する。

ステップＳＴ２４０３において、ＨｅＮＢは、ステップＳＴ２２０３で送信した傘下のＭＴＣＤからコアネットワークへのデータをＭＭＥへ再送し、ステップＳＴ２４０２へ戻って判断処理を繰り返す。

ステップＳＴ２４０４において、ＨｅＮＢは、傘下のＭＴＣＤからコアネットワークへの次のデータを、Ｓ１インタフェースを用いてＭＭＥへ送信する。

本変形例では、実施の形態１と組み合わせた例について主に記載したが、本変形例は、実施の形態１の変形例１、実施の形態１の変形例２、実施の形態１の変形例３および実施の形態１の変形例４とも組み合わせて用いることができる。

また、本変形例は、非特許文献９に開示されているｅＮＢがＭＴＣＤグループに共通のシグナリングメッセージを引き止め（hold back）、寄せ集める（aggregation）際にも用いることができる。

実施の形態２の変形例１によって、以下の効果を得ることができる。ＨｅＮＢが、傘下のＭＴＣＤからコアネットワークへのデータを集線処理した後、ＨｅＮＢからコアネットワークへデータを送信する方法を確立することができる。

実施の形態２変形例２．
実施の形態２の変形例２では、実施の形態２におけるＨｅＮＢが、傘下のＭＴＣＤからコアネットワークであるＭＭＥ、ＳＧＳＮ、ＭＴＣサーバなどへのデータをＭＭＥ経由でＳ１インタフェースを用いて送信する際の他の具体例を開示する。既存のＳ１シグナリング、あるいはＳ１メッセージを用いる。既存の制御用のＳ１シグナリングを用いるようにしてもよい。また、既存の移動端末とは無関係のＳ１シグナリングを用いるようにしてもよい。

ＨｅＮＢが、傘下のＭＴＣＤからコアネットワークであるＭＭＥ、ＳＧＳＮ、ＭＴＣサーバなどへのデータをＭＭＥ経由でＳ１インタフェースを用いて送信する際に、既存のＳ１シグナリングに必要なパラメータの具体例として、以下の（１）〜（５）の５つを開示する。（１）ＨｅＮＢの識別子。（２）ＭＴＣＤの識別子。集線処理を行うＭＴＣＤの数だけ、すなわち集線処理を行うＭＴＣＤの数と同数あってもよい。（３）ＭＴＣ用のＰＤＵ、あるいはＳＤＵ。集線処理を行うＭＴＣＤの数だけ、すなわち集線処理を行うＭＴＣＤの数と同数あってもよい。（４）サービスの種類、あるいはサービスの識別子。（５）どのＭＴＣサーバ向けのデータであるか、あるいはどのＭＴＣユーザ向けのデータであるかを示す情報。

（ａ）「S1 SETUP REQUEST」（非特許文献１４参照）。「S1 SETUP REQUEST」にマッピングされるパラメータには、前述の既存のＳ１シグナリングに必要なパラメータの具体例（１）のＨｅＮＢの識別子である「Global eNB ID」が既に含まれる。したがって、「S1 SETUP REQUEST」に新たに追加が必要なパラメータは、前述の具体例（２）のＭＴＣＤの識別子、前述の具体例（３）のＭＴＣ用のＰＤＵあるいはＳＤＵ、前述の具体例（４）のサービスの種類、あるいはサービスの識別子、および前述の具体例（５）のどのＭＴＣサーバ向けのデータであるか、あるいはどのＭＴＣユーザ向けのデータであるかを示す情報である。ＭＴＣＤの識別子は、集線処理を行うＭＴＣＤの数だけ、すなわち集線処理を行うＭＴＣＤの数と同数あってもよい。ＭＴＣ用のＰＤＵあるいはＳＤＵは、集線処理を行うＭＴＣＤの数だけ、すなわち集線処理を行うＭＴＣＤの数と同数あってもよい。

「S1 SETUP REQUEST」に対するＭＭＥからの成功を示す応答メッセージである「S1 SETUP RESPONSE」中に、ＭＴＣＤからのデータを正常に受信した旨を示すパラメータを追加してもよい。正常に受信した旨を示すパラメータを含む「S1 SETUP RESPONSE」を受信したＨｅＮＢは、次のＭＴＣＤからのデータを送信するようにしてもよい。あるいは、正常に受信した旨を示すパラメータを新設せず、「S1 SETUP RESPONSE」を受信したＨｅＮＢは、次のＭＴＣＤからのデータを送信するようにしてもよい。「S1 SETUP REQUEST」に対するＭＭＥからの失敗を示す応答メッセージである「S1 SETUP FAILURE」中に、ＭＴＣＤからのデータを正常に受信できなかった旨を示すパラメータを追加してもよい。正常に受信できなかった旨を示すパラメータを含む「S1 SETPUP FAILURE」を受信したＨｅＮＢは、同じＭＴＣＤからのデータを再送するようにしてもよい。あるいは、正常に受信できなかった旨を示すパラメータを新設せず、「S1 SETUP FAILURE」を受信したＨｅＮＢは、同じＭＴＣＤからのデータを再送するようにしてもよい。

（ｂ）「eNB Configuration Update」（非特許文献１４参照）。「eNB Configuration Update」にマッピングされるパラメータには、前述の既存のＳ１シグナリングに必要なパラメータの具体例（１）のＨｅＮＢの識別子である「eNB Name」が既に含まれる。したがって、「S1 SETUP REQUEST」に新たに追加が必要なパラメータは、前述の具体例（２）のＭＴＣＤの識別子、前述の具体例（３）のＭＴＣ用のＰＤＵあるいはＳＤＵ、前述の具体例（４）のサービスの種類、あるいはサービスの識別子、および前述の具体例（５）のどのＭＴＣサーバ向けのデータであるか、あるいはどのＭＴＣユーザ向けのデータであるかを示す情報である。ＭＴＣＤの識別子は、集線処理を行うＭＴＣＤの数だけ、すなわち集線処理を行うＭＴＣＤの数と同数あってもよい。ＭＴＣ用のＰＤＵあるいはＳＤＵは、集線処理を行うＭＴＣＤの数だけ、すなわち集線処理を行うＭＴＣＤの数と同数あってもよい。

「eNB Configuration Update」に対するＭＭＥからの成功を示す応答メッセージである「eNB Configuration Update Acknowledge」中に、ＭＴＣＤからのデータを正常に受信した旨を示すパラメータを追加してもよい。正常に受信した旨を示すパラメータを含む「eNB Configuration Update Acknowledge」を受信したＨｅＮＢは、次のＭＴＣＤからのデータを送信するようにしてもよい。あるいは、正常に受信した旨を示すパラメータを新設せず、「eNB Configuration Update Acknowledge」を受信したＨｅＮＢは、次のＭＴＣＤからのデータを送信するようにしてもよい。「eNB Configuration Update」に対するＭＭＥからの失敗を示す応答メッセージである「eNB Configuration Update FAILURE」中に、ＭＴＣＤからのデータを正常に受信できなかった旨を示すパラメータを追加してもよい。正常に受信できなかった旨を示すパラメータを含む「eNB Configuration Update FAILURE」を受信したＨｅＮＢは、同じＭＴＣＤからのデータを再送するようにしてもよい。あるいは、正常に受信できなかった旨を示すパラメータを新設せず、「eNB Configuration Update FAILURE」を受信したＨｅＮＢは、同じＭＴＣＤからのデータを再送するようにしてもよい。

実施の形態２の変形例２によって、実施の形態２の効果に加えて、以下の効果を得ることができる。実施の形態２および実施の形態２の変形例１と比較して、新たなシグナリングを設ける必要がない点において、移動体通信システムが複雑化することを回避することができるという利点がある。

実施の形態２変形例３．
実施の形態２の変形例３では、実施の形態２におけるＨｅＮＢが、傘下のＭＴＣＤからコアネットワークであるＭＭＥ、ＳＧＳＮ、ＭＴＣサーバなどへのデータをＭＭＥ経由でＳ１インタフェースを用いて送信する際の他の具体例を開示する。既存のＳ１シグナリング、あるいはＳ１メッセージを用いる。既存の制御用のＳ１シグナリングを用いるようにしてもよい。また、既存の移動端末と関係があるＳ１シグナリングを用いるようにしてもよい。既存の移動端末と関係があるＳ１シグナリングは、「UE associated Signalling」とも称される（非特許文献１４参照）。

ＨｅＮＢが、傘下のＭＴＣＤからコアネットワークであるＭＭＥ、ＳＧＳＮ、ＭＴＣサーバなどへのデータをＭＭＥ経由でＳ１インタフェースを用いて送信する際に、既存のＳ１シグナリングに必要なパラメータの具体例として、以下の（１）〜（９）の９つを開示する。

（１）ＨｅＮＢの識別子。受信側で、どのＨｅＮＢ経由のデータであるかを識別可能となるので、ＰＣＩ（Physical Cell Identity）、ＣＧＩ（Cell Global Identity）などであってもよい。

（２）ＭＴＣＤの識別子。受信側で、どのＭＴＣＤからのデータであるかを識別可能となるので、ＩＭＳＩ、ＭＴＣＤの製造番号などであってもよい。本パラメータは、集線処理を行うＭＴＣＤの数だけ、すなわち集線処理を行うＭＴＣＤの数と同数あってもよい。

（３）ＭＴＣ用のＰＤＵ。ＰＤＵとは、同位レイヤ間で意味を持つデータの固まりである。ＰＤＵを用いることによって、新たに設けるＳ１シグナリングに、ＭＴＣＤからコアネットワークへのデータをマッピングすることが可能となる。本パラメータは、集線処理を行うＭＴＣＤの数だけ、すなわち集線処理を行うＭＴＣＤの数と同数あってもよい。

（４）ＭＴＣ用のＳＤＵ。ＳＤＵとは、上位レイヤから転送依頼されたデータの固まりである。ＳＤＵを用いることによって、新たに設けるＳ１シグナリングに、ＭＴＣＤからコアネットワークへのデータをマッピングすることが可能となる。本パラメータは、集線処理を行うＭＴＣＤの数だけ、すなわち集線処理を行うＭＴＣＤの数と同数あってもよい。

（５）Ｓ１シグナリングが、ＭＴＣ用であることを示すインジケータ。あるいは、Ｓ１シグナリングが、ノーマルＵＥとは無関係であることを示すインジケータ。本パラメータが存在することで、ＨｅＮＢが、傘下のＭＴＣＤからコアネットワークへのデータ送信用に、Ｓ１シグナリングを用いているか否かを判断することが可能となる。これによって、ＭＴＣＤからコアネットワークへのデータ送信時には、Ｓ１シグナリング中のノーマルＵＥに関するパラメータを含めなくてもよい、あるいはノーマルＵＥに関するパラメータは無意味な情報であることを示すなどの動作が可能となる。

（６）サービスの種類、あるいはサービスの識別子。これによって、サービス別にデータの送信先が異なる場合などに対応することができる。また、１つのＭＴＣＤで複数のサービスに対応する場合であっても、サービス別にデータの送信先が異なる場合などに対応することができる。

（７）どのＭＴＣサーバ向けのデータであるか、あるいはどのＭＴＣユーザ向けのデータであるかを示す情報。具体例としては、ＭＴＣサーバの識別子、あるいはＭＴＣユーザの識別子。これによって、送信先を適切に変更することができる。

（８）前記（６）と前記（７）との組み合わせを示す識別子、あるいはインデックス。

（９）前記（１）〜（８）の組み合わせ。

（ａ）「Initial UE Message」（非特許文献１４参照）。現行の規格では、ｅＮＢは、上りＮＡＳメッセージを受信したとき、ＮＡＳのＰＤＵを含む「Initial UE Message」を用いて、ＭＭＥへ該メッセージを送信する。したがってＨｅＮＢが、傘下のＭＴＣＤからコアネットワークへのデータをＭＭＥへ「Initial UE Message」を用いて送信することは、同様の目的で現行の規格と同様のＳ１シグナリングを用いることができることになる。これによって、移動体通信システムが複雑化することを回避することができる。但し、ＨｅＮＢが上りＮＡＳメッセージを受信しない場合においても、本変形例を用いることができる。

次に、「Initial UE Message」に追加および変更が必要なパラメータについて説明する。「Initial UE Message」にマッピングされるパラメータには、（１）ＨｅＮＢの識別子である「ＣＧＩ」が既に含まれる。したがって「Initial UE Message」に新たに追加が必要なパラメータの具体例としては、以下の（２）〜（８）がある。（２）ＭＴＣＤの識別子。（３）ＭＴＣ用のＰＤＵ。（４）ＭＴＣ用のＳＤＵ。「Initial UE Message」には、ＮＡＳ−ＰＤＵが既に含まれる。例えば、Ｓ１シグナリングがＭＴＣ用であれば、ＮＡＳ−ＰＤＵをＭＴＣ用のＰＤＵとしてもよい。（５）Ｓ１シグナリングが、ＭＴＣ用であることを示すインジケータ。（６）どのＭＴＣサーバ向けのデータであるか、あるいはどのＭＴＣユーザ向けのデータであるかを示す情報。（７）どのＭＴＣサーバ向けのデータであるか、あるいはどのＭＴＣユーザ向けのデータであるかを示す情報。（８）前記（６）と前記（７）との組み合わせを示す識別子、あるいはインデックス。

「Initial UE Message」に含まれるパラメータにおいて変更が必要なパラメータは、「eNB UE S1AP ID」である。現行の規格では、ｅＮＢは移動端末に使用されるために固有の「eNB UE S1AP ID」を割り当て、「Initial UE Message」中にマッピングする。「eNB UE S1AP ID」とは、Ｓ１インタフェース上で移動端末に関連する固有の識別子である。ＨｅＮＢにおいて集線処理をした後に、ＨｅＮＢからコアネットワークへデータを送信する場合、送信されるデータには、複数のＭＴＣＤからのデータが含まれる場合がある。つまり、移動端末固有にはＳ１インタフェースを用いない。したがって、「eNB UE S1AP ID」をＨｅＮＢが割り当て不可能な状況が発生する。また、現行の規格では「Initial UE Message」には「eNB UE S1AP ID」を必ずマッピングする必要がある。つまり、集線処理によって複数のＭＴＣＤからのデータを１つの「initial UE Message」で送信するような場合、「eNB UE S1AP ID」の取扱いにおいて、移動体通信システムとして統一がなくなるという問題が発生する。移動体通信システムとして統一が図られなければ、安定した通信網が供給できないなどの問題が発生する。そこで、例えばＳ１シグナリングがＭＴＣ用であれば、「eNB UE S1AP ID」はマッピングされていても、受信側で無効なパラメータ、あるいは送信側でのマッピングを必須とせずにオプションとする。これによって、ＨｅＮＢの処理が明確となり、統一した移動体通信網の構築が可能となり、安定した通信網の供給が可能となる。

（ｂ）「Uplink NAS Transport」（非特許文献１４参照）。現行の規格では、ｅＮＢは、移動端末に関連するＳ１インタフェースによる接続が存在するＭＭＥに送信すべきＮＡＳメッセージを受信したとき、ＮＡＳのＰＤＵを含む「Uplink NAS Transport」を用いてＭＭＥへ該メッセージを送信する。したがって、ＨｅＮＢが、傘下のＭＴＣＤからコアネットワークへのデータをＭＭＥへ「Uplink NAS Transport」を用いて送信することは、同様の目的で現行の規格と同様のＳ１シグナリングを用いることができることになる。これによって、移動体通信システムが複雑化することを回避することができる。但し、ＨｅＮＢが上りＮＡＳメッセージを受信しない場合においても、本変形例を用いることができる。また、Ｓ１インタフェースによる接続が存在しない場合においても、本変形例を用いることができる。

次に、「Uplink NAS Transport」に追加および変更が必要なパラメータについて説明する。「Uplink NAS Transport」にマッピングされるパラメータには、（１）ＨｅＮＢの識別子である「ＣＧＩ」が既に含まれる。したがって「Initial UE Message」に新たに追加が必要なパラメータの具体例としては、以下の（２）〜（８）がある。（２）ＭＴＣＤの識別子。（３）ＭＴＣ用のＰＤＵ。（４）ＭＴＣ用のＳＤＵ。「Uplink NAS Transport」には、ＮＡＳ−ＰＤＵが既に含まれる。例えば、Ｓ１シグナリングがＭＴＣ用であれば、ＮＡＳ−ＰＤＵをＭＴＣ用のＰＤＵとしてもよい。（５）Ｓ１シグナリングが、ＭＴＣ用であることを示すインジケータ。（６）どのＭＴＣサーバ向けのデータであるか、あるいはどのＭＴＣユーザ向けのデータであるかを示す情報。（７）どのＭＴＣサーバ向けのデータであるか、あるいはどのＭＴＣユーザ向けのデータであるかを示す情報。（８）前記（６）と前記（７）との組み合わせを示す識別子、あるいはインデックス。

「Uplink NAS Transport」に含まれるパラメータにおいて変更が必要なパラメータとして、以下の（ｂ１），（ｂ２）の２つを開示する。

（ｂ１）「eNB UE S1AP ID」。現行の規格では、ｅＮＢは移動端末に使用されるために固有の「eNB UE S1AP ID」を割り当て、「Uplink NAS Transport」中にマッピングする。「eNB UE S1AP ID」とは、Ｓ１インタフェース上で該移動端末に関連する固有の識別子である。ＨｅＮＢにおいて集線処理をした後に、ＨｅＮＢからコアネットワークへデータを送信する場合、送信されるデータには、複数のＭＴＣＤからのデータが含まれる場合がある。つまり、移動端末固有にはＳ１インタフェースを用いない。これによって、「eNB UE S1AP ID」をＨｅＮＢが割り当て不可能な状況が発生する。

また、現行の規格では、「Uplink NAS Transport」には「eNB UE S1AP ID」を必ずマッピングする必要がある。つまり、集線処理によって複数のＭＴＣＤからのデータを１つの「Uplink NAS Transport」で送信するような場合、「eNB UE S1AP ID」の取扱いにおいて、移動体通信システムとして統一がなくなるという問題が発生する。移動体通信システムとして統一が図られなければ、安定した通信網が供給できないなどの問題が発生する。そこで、例えばＳ１シグナリングがＭＴＣ用であれば、「eNB UE S1AP ID」はマッピングされていても、受信側で無効なパラメータ、あるいは送信側でのマッピングを必須とせずにオプションとする。これによって、ＨｅＮＢの処理が明確となり、統一した移動体通信網の構築が可能となり、安定した通信網の供給が可能となる。

（ｂ２）「MME UE S1AP ID」。「MME UE S1AP ID」とは、Ｓ１インタフェース上で移動端末に関連する固有の識別子である。ＨｅＮＢにおいて集線処理をした後に、ＨｅＮＢからコアネットワークへデータを送信する場合、送信されるデータには、複数のＭＴＣＤからのデータが含まれる場合がある。つまり、移動端末固有にはＳ１インタフェースを用いない。これによって、「MME UE S1AP ID」をＨｅＮＢが割り当て不可能な状況が発生する。

また、現行の規格では、「Uplink NAS Transport」には「MME UE S1AP ID」を必ずマッピングする必要がある。つまり、集線処理によって、複数のＭＴＣＤからのデータを１つの「Uplink NAS Transport」で送信するような場合、「MME UE S1AP ID」の取扱いにおいて、移動体通信システムとして統一がなくなるという問題が発生する。移動体通信システムとして統一が図られなければ、安定した通信網が供給できないなどの問題が発生する。そこで、例えばＳ１シグナリングがＭＴＣ用であれば、「MME UE S1AP ID」はマッピングされていても、受信側で無効なパラメータ、あるいは送信側でのマッピングを必須とせずにオプションとする。これによって、ＨｅＮＢの処理が明確となり、統一した移動体通信網の構築が可能となり、安定した通信網の供給が可能となる。

実施の形態２の変形例３によって、実施の形態２の効果に加えて、以下の効果を得ることができる。実施の形態２および実施の形態２の変形例１と比較して、新たなシグナリングを設ける必要がない点において、移動体通信システムが複雑化することを回避することができるという利点がある。

実施の形態２変形例４．
前述の実施の形態２を用いた場合、以下の課題が発生する。集線処理を行う能力を有するＨｅＮＢと、集線処理を行う能力を有していないＨｅＮＢとが存在する場合を考える。集線処理を行う能力を有していないＨｅＮＢへコアネットワークであるＭＭＥ、ＳＧＳＮなどが実施の形態２の処理を実行して、Ｓ１インタフェースを介してＭＴＣＤ用の通信として許可された時間、あるいは許可された期間、あるいは許可されたリソースを通知することは無駄となる。具体的には、コアネットワークからＨｅＮＢまでの通信リソースの無駄、およびコアネットワークの処理の無駄が発生する。

実施の形態２の変形例４での解決策を以下に示す。実施の形態１および実施の形態２での解決策と異なる部分を中心に説明する。説明していない部分については、実施の形態１および実施の形態２と同様とする。

ＨｅＮＢは、ＭＴＣＤからのデータの集線処理に関する能力情報をコアネットワークであるＭＭＥ、ＳＧＳＮなどへ通知する。コアネットワークは、ＭＴＣＤからのデータの集線処理を行う能力があるＨｅＮＢに対して、実施の形態２を実行して、ＭＴＣＤ用リソースの通知を実行する。

また、コアネットワークは、集線処理を行うＨｅＮＢのみに対して、実施の形態２を実行して、ＭＴＣＤ用リソースの通知を実行するようにしてもよい。

また、実施の形態１の変形例２を実行する場合、コアネットワークがＨｅＮＢへ集線処理の開始を指示する際に、ＭＴＣＤ用リソースの通知を実行するようにしてもよい。その場合、集線ＯＮの指示とともに、ＭＴＣＤ用リソースを通知してもよい。実施の形態１の変形例２で開示した、コアネットワークがＨｅＮＢへ集線ＯＮを指示するシグナリングの具体例として、パラメータにＭＴＣＤ用リソースを追加してもよい。

ＨｅＮＢがコアネットワークへ通知する集線処理に関する能力情報の具体例は、実施の形態１の変形例３と同様であるので説明を省略する。

ＨｅＮＢが集線処理に関する能力情報をコアネットワークへ通知するタイミングの具体例として、以下の（１）〜（５）の５つを開示する。

（１）ＨｅＮＢ設置時。ＨｅＮＢの集線処理を行う能力に変更が生じることがない場合、通信リソースの無駄が発生しないという効果を得ることができる。

（２）周期的。ＨｅＮＢの集線処理を行う能力に変更が生じる場合に有効である。また、周期的に能力情報が通知されるので、通信エラーに強いという効果を得ることができる。

（３）ＨｅＮＢの能力変更時。ＨｅＮＢの集線処理を行う能力に変更が生じる場合に有効である。具体例（３）は、具体例（２）と比較して、能力変更時のみの通知であるので、通信リソースの無駄が発生しないという効果を得ることができる。

（４）ＨｅＮＢが集線処理を開始するとき。あるいは集線処理の開始前。集線処理に関する能力情報として、集線処理を開始する旨を通知してもよい。集線処理を行う能力を有するＨｅＮＢであっても、傘下にＭＴＣＤが存在しなければ、コアネットワークからのＭＴＣＤ用リソースの通知は無駄となる。具体例（４）は、具体例（１）〜（３）と比較して、実際にＭＴＣＤ用リソースが必要なＨｅＮＢにのみ、コアネットワークがＭＴＣＤ用リソースを通知することが可能となる。したがって、本具体例（４）は、よりコアネットワークからＨｅＮＢまでの通信リソースを有効に活用することができるとともに、コアネットワークの処理の負荷を軽減することができる。

（５）集線処理を終了の際。集線処理に関する能力情報として、集線処理を終了する旨を通知してもよい。具体例（４）と具体例（５）とは、組み合わせて用いることができる。

ＨｅＮＢが集線処理に関する能力情報をコアネットワークへ通知する際のシグナリングの具体例は、実施の形態１の変形例３と同様であるので説明を省略する。その際、具体例（２）を用い、応答メッセージが必要なＳ１シグナリングを設けた場合、応答メッセージにＭＴＣＤ用リソースをマッピングするようにしてもよい。これによって、通信手順を省略することができ、ＨｅＮＢやコアネットワークの処理の負荷を軽減することができるとともに、通信リソースを有効に活用することができる。

また、具体例（３）を用い、既存の応答メッセージが必要な既存のＳ１シグナリングを設けた場合、応答メッセージにＭＴＣＤ用リソースをマッピングするようにしてもよい。これによって、通信手順を省略することができ、ＨｅＮＢやコアネットワークの処理の負荷を軽減することができるとともに、通信リソースを有効に活用することができる。応答メッセージの具体例としては、「S1 SETUP RESPONSE」、「S1 SETUP FAILURE」「ENB CONFIGURATION UPDATE ACKNOWLEDGE」「eNB Configuration Update FAILURE」などがある。

ＭＴＣＤ用リソースの解放の方法についての具体例として、以下の（１）〜（３）の３つを開示する。（１）ＭＴＣＤ用リソースについて有効期間を、予め決定しておく。有効期間を経過した場合、コアネットワークは、ＭＴＣＤ用リソースを解放する。（２）コアネットワークが、ＨｅＮＢへ、ＭＴＣＤ用リソースの通知を行う場合、あわせて該リソースの有効期間を通知する。有効期間を経過した場合、コアネットワークは、ＭＴＣＤ用リソースを解放する。（３）ＨｅＮＢが集線処理に関する能力情報をコアネットワークへ通知するタイミングの前述の具体例（５）を用いた場合、該通知を受信したコアネットワークは、ＭＴＣＤ用リソースを解放する。

前記具体例（１）〜（３）を用いて、ＭＴＣＤ用リソースを解放することで、無駄なリソースを確保する必要が無くなる。また、解放した通信リソースは、他の通信、例えばノーマルＵＥ用の通信に用いることができる。これによって、通信リソースを有効に活用することができる。

前記具体例（１）および（２）については、ＨｅＮＢが集線処理を行っている場合においても有効期間が経過し、コアネットワークにおいてＭＴＣＤ用リソースが解放される場合が考えられる。したがって、ＨｅＮＢがＭＴＣＤ用リソースを要求することができるようにしてもよい。ＭＴＣＤ用リソースの要求情報をコアネットワークへ通知する際のシグナリングの具体例は、実施の形態１の変形例３で開示したＨｅＮＢが、集線処理に関する能力情報をコアネットワークへ通知する際のシグナリングの具体例を用いることができるので、説明を省略する。

実施の形態２の変形例３を用いた具体的な動作例を、図２５を用いて説明する。図２５は、実施の形態２の変形例３における移動体通信システムのシーケンスを示す図である。図２５において、図１７、図２０および図２２に示すステップに対応するステップについては、同一の参照符を付して、共通する説明を省略する。

本動作例では、ＨｅＮＢが集線処理に関する能力情報をコアネットワークへ通知するタイミングの具体例として、ＨｅＮＢ設置時について開示する。また、ＨｅＮＢは、集線処理能力を有することとする。ＨｅＮＢが集線処理に関する能力情報をコアネットワークへ通知する際のシグナリングの具体例として、既存のＳ１シグナリングである「S1 SETUP REQUEST」を用いる場合について開示する。また、「S1 SETUP」手順は成功したとして、ＭＴＣＤ用リソースを「S1 SETUP REQUEST」の応答メッセージである「S1 SETUP RESPONSE」を用いて通知する場合について開示する。

ステップＳＴ２００１において、ＨｅＮＢが設置される。ステップＳＴ２５０１において、ＨｅＮＢは、ＭＭＥへＨｅＮＢの集線処理に関する能力情報を通知する。この通知には「S1 SETUP REQUEST」を用いる。「S1 SETUP REQUEST」のパラメータとして、集線処理に関する能力情報をマッピングする。

ステップＳＴ２００３において、ＭＭＥは、ステップＳＴ２５０１で受信した集線処理に関する能力情報に基づいて、ＨｅＮＢが集線処理を行う能力があるか否かを判断する。ＭＭＥは、集線処理を行う能力があると判断した場合は、ステップＳＴ２５０２へ移行する。ＭＭＥは、集線処理を行う能力がないと判断した場合は、ステップＳＴ２５０３へ移行する。本動作例では、ＨｅＮＢは集線処理能力を有するので、集線処理を行う能力があると判断され、ステップＳＴ２５０２へ移行する。

ステップＳＴ２５０２において、ＭＭＥは、ＨｅＮＢへＭＴＣＤ用リソースを通知する。この通知には「S1 SETUP RESPONSE」を用いる。「S1 SETUP RESPONSE」のパラメータとして、ＭＴＣＤ用リソースをマッピングする。

ステップＳＴ２５０３において、ＭＭＥは、ＨｅＮＢへ「S1 SETUP RESPONSE」を通知する。「S1 SETUP RESPONSE」のパラメータとして、ＭＴＣＤ用リソースはマッピングしない。つまり、ステップＳＴ２５０３でＨｅＮＢへ通知される「S1 SETUP RESPONSE」には、ＭＴＣＤ用リソースを含まない。

次に、ステップＳＴ１７０３において、ＭＴＣＤ＿１が「RRC Connection Request」をＨｅＮＢに送信する処理を行い、ステップＳＴ１７０４において、ＭＴＣＤ＿ｎが「RRC Connection Request」をＨｅＮＢに送信する処理を行う。ＭＴＣＤ＿１およびＭＴＣＤ＿ｎから送信された「RRC Connection Request」を受信したＨｅＮＢは、前述のステップＳＴ１７０５およびステップＳＴ１９０３の処理を行う。ステップＳＴ１９０３の処理を終了した後は、ＨｅＮＢは、ステップＳＴ２５０４へ移行する。

ステップＳＴ２５０４において、ＨｅＮＢは、ステップＳＴ２５０２で受信した、ＭＴＣＤ用リソースであるか否かを判断する。ＨｅＮＢは、ＭＴＣＤ用リソースであると判断した場合は、ステップＳＴ２２０３へ移行し、ＨｅＮＢが、傘下のＭＴＣＤからコアネットワークへのデータをＭＭＥへＳ１インタフェースを用いて送信する。ＨｅＮＢは、ＭＴＣＤ用リソースでないと判断した場合は、ステップＳＴ２５０４の判断処理を繰り返す。

本変形例では実施の形態１および実施の形態２と組み合わせた例について主に記載したが、本変形例は、実施の形態１の変形例１、実施の形態１の変形例２、実施の形態１の変形例３、実施の形態１の変形例４、実施の形態２の変形例１、実施の形態２の変形例２および実施の形態２の変形例３とも組み合わせて用いることができる。

また、本変形例は、非特許文献１０に開示されているｅＮＢがＭＴＣＤグループに共通のシグナリングメッセージを引き止め（hold back）、寄せ集める（aggregation）際にも用いることができる。

実施の形態２の変形例４によって、実施の形態２の効果に加えて、以下の効果を得ることができる。集線処理を行う能力を有していないＨｅＮＢに対して、コアネットワークがＭＴＣＤ用リソースを通知することを防止することができる。これによって、コアネットワークからＨｅＮＢまでの通信リソースを有効に活用することができるとともに、コアネットワークの処理の負荷を軽減することができる。

実施の形態３．
本実施の形態３では、実施の形態１を実行した際のページング（Paging）方法について開示する。本実施の形態３では、ＨｅＮＢとＭＴＣＤとの間の通信方法として、３ＧＰＰによって標準規格化された移動体通信システムを用いた場合について開示する。

実施の形態３を用いた具体的な動作例を、図２６を用いて説明する。図２６は、実施の形態３における移動体通信システムのシーケンスを示す図である。図２６において、図１７に示すステップに対応するステップについては、同一の参照符を付して、共通する説明を省略する。

本動作例では、ＨｅＮＢで集線処理を行うＭＴＣＤからコアネットワークへのデータの具体例として、ＮＡＳシグナリングの場合について開示する。また、ＨｅＮＢが、傘下の移動端末（ＵＥ）がＭＴＣＤであるか、ＭＴＣＤ以外であるかを区別する方法の具体例として、ＲＲＣメッセージ「RRC Connection Request」にＭＴＣＤインジケータをマッピングする場合について開示する。

まず、ステップＳＴ１７０３において、ＭＴＣＤ＿１が「RRC Connection Request」をＨｅＮＢに送信する処理を行い、ステップＳＴ１７０４において、ＭＴＣＤ＿ｎが「RRC Connection Request」をＨｅＮＢに送信する処理を行う。ＭＴＣＤ＿１およびＭＴＣＤ＿ｎから送信された「RRC Connection Request」を受信したＨｅＮＢは、前述のステップＳＴ１７０５およびステップＳＴ１７０７の処理を行う。ステップＳＴ１７０７の処理を終了した後は、ステップＳＴ２６０１へ移行する。

本動作例では、ステップＳＴ１７０３の処理の後に、ステップＳＴ１７０５、ステップＳＴ１７０７およびステップＳＴ２２０２に相当する処理が行われるが、理解を容易にするために、説明を省略している。

また、ステップＳＴ１７０５において、ＭＴＣＤからのデータではないと判断された場合は、本実施の形態の本質的な部分ではないので、説明を省略することとして、処理を終了する。

ステップＳＴ２６０１において、ＭＴＣＤ＿１は、ＨｅＮＢへ、ＭＴＣＤ＿１の識別子を含むアタッチメッセージを送信する。アタッチの詳細な方法については、非特許文献１３に開示されている。ステップＳＴ２６０２において、ＭＴＣＤ＿ｎは、ＨｅＮＢへ、ＭＴＣＤ＿ｎの識別子を含むアタッチメッセージを送信する。

ステップＳＴ２６０３において、ＨｅＮＢは、ステップＳＴ２６０１で受信したＭＴＣＤ＿１からのアタッチメッセージと、ステップＳＴ２６０２で受信したＭＴＣＤ＿ｎからのアタッチメッセージとを集線処理する。本動作例では、集線処理として、複数のＭＴＣＤからコアネットワークへのデータであるアタッチメッセージを、まとめてＭＭＥへ通知することとする。

ステップＳＴ２６０４において、ＨｅＮＢは、ステップＳＴ２６０３で集線処理を行うことによって集線されたアタッチメッセージをＭＭＥへ通知する。アタッチメッセージには、集線処理の対象となったＭＴＣＤの識別子であるＭＴＣＤ＿１の識別子およびＭＴＣＤ＿ｎの識別子と、ＨｅＮＢの識別子と、ＴＡＩとが含まれる。アタッチメッセージの通知方法としては、実施の形態２、実施の形態２の変形例１、実施の形態２の変形例２および実施の形態２の変形例３を用いることができる。

ステップＳＴ２６０５において、ＭＭＥは、ＨＳＳ（Home Subscriber Server）へ、アタッチメッセージとして受信したＭＴＣＤの識別子であるＭＴＣＤ＿１の識別子およびＭＴＣＤ＿ｎの識別子を通知する。ＨＳＳとは、３ＧＰＰ移動体通信網における加入者情報データベースであり、認証情報および在圏情報の管理を行うエンティティである。

ステップＳＴ２６０６において、ＨＳＳは、アタッチ処理されたＭＴＣＤの識別子であるＭＴＣＤ＿１の識別子とＭＴＣＤ＿ｎの識別子とを登録し、管理する。

ステップＳＴ２６０７において、ＭＭＥは、ＭＴＣＤ＿１宛の着信を受信したとする。着信の詳細な方法については、非特許文献１３および非特許文献１４に開示されている。着信には、ＭＴＣＤ＿１の識別子が含まれる。これによって、ＭＴＣＤ＿１単体に着信させることができる。

ステップＳＴ２６０８において、ＭＭＥは、ＭＴＣＤ＿１のトラッキングエリアリスト（TAI Listとも称される）を検索する。

ステップＳＴ２６０９において、ＭＭＥは、ＨｅＮＢへ、ＭＴＣＤ＿１宛のページングを通知する。ページングには、ＭＴＣＤ＿１のトラッキングエリアリストと、ＭＴＣＤ＿１の識別子とが含まれる。ＭＴＣＤ＿１の識別子が含まれることによって、ＭＴＣＤ＿１単体に着信させることができる。

ステップＳＴ２６１０において、ＨｅＮＢは、ステップＳＴ２６０９で受信したページングに含まれるＭＴＣＤ＿１のトラッキングエリアリスト（TAI List）に含まれるトラッキングエリアに、自ＨｅＮＢが含まれるか否かを判断する。ＨｅＮＢは、自ＨｅＮＢが含まれると判断した場合は、ステップＳＴ２６１１へ移行する。ＨｅＮＢは、自ＨｅＮＢが含まれないと判断した場合は、ステップＳＴ２６１１の処理を行わない。

ステップＳＴ２６１１において、ＨｅＮＢは、ＭＴＣＤ＿１宛のページングを通知する。ページングは、３ＧＰＰによって標準規格化された移動体通信システムにおいて通知する。具体的には、ページングメッセージは、論理チャネルであるＰＣＣＨにマッピングされ、ＰＣＣＨは、トランスポートチャネルであるＰＣＨへマッピングされ、ＰＣＨは、物理チャネルであるＰＤＳＣＨへマッピングされる。ＰＤＣＣＨで全移動端末共通のページングインジケータを送信する。ページングインジケータが送信されたＰＤＣＣＨによって、前記ページングメッセージがマッピングされたＰＤＳＣＨのリソースが割り当てられる。ページングの通知の詳細な方法については、非特許文献１、非特許文献２および非特許文献１６に開示されている。

本実施の形態では、実施の形態１、実施の形態２、実施の形態２の変形例１、実施の形態２の変形例２および実施の形態２の変形例３と組み合わせた例について主に記載したが、実施の形態１の変形例１、実施の形態１の変形例２、実施の形態１の変形例３および実施の形態２の変形例４とも組み合わせて用いることができる。

以上に述べた実施の形態３では、実施の形態１を実行し、ＨｅＮＢとＭＴＣＤとの間の通信方法として、３ＧＰＰによって標準規格化された移動体通信システムを用いた場合のページング（Paging）方法について開示している。実施の形態３を実行することによって、３ＧＰＰによって標準規格化された移動体通信システムを用いた場合に、ページング（Paging）を実現することができる。

実施の形態４．
本実施の形態４では、実施の形態１を実行した際のページング（Paging）方法について開示する。本実施の形態４では、ＨｅＮＢとＭＴＣＤとの間の通信方法として、３ＧＰＰによって標準規格化された移動体通信システム以外の通信システムを用いた場合について開示する。

実施の形態４での解決策を以下に示す。実施の形態１での解決策と異なる部分を中心に説明する。説明していない部分については、実施の形態１と同様とする。

ＨｅＮＢは、３ＧＰＰによって標準規格化された移動体通信システム以外の通信システムを用いてアクセスしてきたＭＴＣＤからのデータを集線処理し、３ＧＰＰによって標準規格化された移動体通信システムのプロトコルを用いて、コアネットワークであるＭＭＥ、あるいはＳＧＳＮ、あるいはＭＴＣサーバなどへ通知する。ＨｅＮＢは、集線処理を行ったＭＴＣＤの識別子を記憶し、ＭＭＥから集線処理を行ったＭＴＣＤの識別子を含んだページングメッセージを受信したときには、傘下のＭＴＣＤへ着信を通知する。

集線処理の具体例として、以下の（１）〜（３）の３つを開示する。（１）３ＧＰＰによって標準規格化された移動体通信システム以外の通信システムによるアクセスを、３ＧＰＰによって標準規格化された移動体通信システムのプロトコルに乗せ変える。３ＧＰＰによって標準規格化された移動体通信システム以外の通信システムによるアクセスがあった場合、アクセス内容を解釈し、アクセス内容に即した３ＧＰＰによって標準規格化された移動体通信システムのプロトコルを選定し、プロトコルに必要なパラメータをコアネットワークであるＭＭＥ、あるいはＳＧＳＮ、あるいはＭＴＣサーバなどへ通知する。（２）１つ、あるいは複数のＭＴＣＤからのコアネットワークへのデータを、まとめてＭＭＥへ通知する。これによって、ＨｅＮＢからコアネットワークへの通信回数を削減することができ、コアネットワークの混雑を緩和することができる。（３）（１）と（２）との組み合わせ。

集線処理の具体例について、前記の具体例（１）を選択した場合における、３ＧＰＰによって標準規格化された移動体通信システム以外の通信システムによるアクセス内容と、アクセス内容に即した３ＧＰＰによって標準規格化された移動体通信システムのプロトコルとの組み合わせの具体例として、以下の（ａ）〜（ｈ）の８つを開示する。以下の説明では、３ＧＰＰによって標準規格化された移動体通信システム以外の通信システムを「３ＧＰＰ以外」と称し、３ＧＰＰによって標準規格化された移動体通信システムを「３ＧＰＰ内」と称することもある。

（ａ）３ＧＰＰ以外でＭＴＣＤの電源ＯＮを通知してきた場合、３ＧＰＰ内で「Attach procedure」を選定。「Attach procedure」の詳細は、非特許文献１３に開示されている。（ｂ）３ＧＰＰ以外でＭＴＣＤの設置を通知してきた場合、３ＧＰＰ内で「Attach procedure」を選定。（ｃ）３ＧＰＰ以外でＭＴＣＤの位置の登録を通知してきた場合、３ＧＰＰ内で「Attach procedure」を選定。（ｄ）３ＧＰＰ以外でＭＴＣＤの移動を通知してきた場合、３ＧＰＰ内で「Tracking Area Update procedure」を選定。「Tracking Area Update procedure」の詳細は、非特許文献１３に開示されている。（ｅ）３ＧＰＰ以外でＭＴＣＤの通信要求、あるいは発呼要求、あるいは着呼応答を通知してきた場合、３ＧＰＰ内で「Service Request procedures」を選定。「Service Request procedures」の詳細は、非特許文献１３に開示されている。（ｆ）３ＧＰＰ以外でＭＴＣＤの電源ＯＦＦを通知してきた場合、３ＧＰＰ内で「Detach procedure」を選定。「Detach procedure」の詳細は、非特許文献１３に開示されている。（ｇ）３ＧＰＰ以外でＭＴＣＤの設置解除を通知してきた場合、３ＧＰＰ内で「Detach procedure」を選定。（ｈ）３ＧＰＰ以外でＭＴＣＤの故障を通知してきた場合、３ＧＰＰ内で「Detach procedure」を選定。

集線処理の具体例について、前記の具体例（１）を選択した場合における、プロトコルに必要なパラメータの具体例として、以下の（ａ）〜（ｄ）の４つを開示する。

（ａ）３ＧＰＰ内において「Attach procedure」を選定した場合、以下の（ａ１）〜（ａ４）。（ａ１）ＭＴＣＤの識別子。（ａ２）ＨｅＮＢの識別子。（ａ３）ＨｅＮＢのトラッキングエリア。（ａ４）前記（ａ１）〜（ａ３）の組み合わせ。

（ｂ）３ＧＰＰ内において「Tracking Area Update procedure」を選定した場合、以下の（ｂ１）〜（ｂ４）。（ｂ１）ＭＴＣＤの識別子。（ｂ２）ＨｅＮＢの識別子。（ｂ３）ＨｅＮＢのトラッキングエリア。（ｂ４）前記（ｂ１）〜（ｂ３）の組み合わせ。

（ｃ）「Service Request procedures」を選定した場合、以下の（ｃ１）〜（ｃ４）。（ｃ１）ＭＴＣＤの識別子。（ｃ２）ＨｅＮＢの識別子。（ｃ３）ＨｅＮＢのトラッキングエリア。（ｃ４）前記（ｃ１）〜（ｃ３）の組み合わせ。

（ｄ）「Detach procedure」を選定した場合、（ｄ１）ＭＴＣＤの識別子。

実施の形態４を用いた具体的な動作例を、図２７を用いて説明する。図２７は、実施の形態４における移動体通信システムのシーケンスを示す図である。図２７において、図１７および図２６に示すステップに対応するステップについては、同一の参照符を付して、共通する説明を省略する。

本動作例では、集線処理の具体例としては、前記の具体例（３）である具体例（１）と具体例（２）との組み合わせを用いた場合について開示する。また、３ＧＰＰ以外によるアクセス内容と、アクセス内容に即した３ＧＰＰ内のプロトコルとの組み合わせの具体例としては、３ＧＰＰ以外でＭＴＣＤの設置を通知してきた場合、および３ＧＰＰ内で「Attach procedure」を選定した場合について開示する。また、３ＧＰＰ以外によるアクセスを３ＧＰＰ内のプロトコルに乗せ変える場合における、「Attach procedure」に必要なパラメータの具体例として、前記の具体例（ａ）の（ａ１）ＭＴＣＤの識別子、（ａ２）ＨｅＮＢの識別子、（ａ３）ＨｅＮＢのトラッキングエリアとした場合について開示する。

ステップＳＴ２７０１において、ＭＴＣＤ＿１は、ＨｅＮＢへ、ＭＴＣＤ＿１の識別子を含むＭＴＣＤの設置通知を送信する。

ステップＳＴ２７０２において、ＭＴＣＤ＿ｎは、ＨｅＮＢへ、ＭＴＣＤ＿ｎの識別子を含むＭＴＣＤの設置通知を送信する。

ステップＳＴ２７０３において、ＨｅＮＢは、ステップＳＴ２７０２におけるＭＴＣＤ＿ｎの識別子を含むＭＴＣＤの設置通知を３ＧＰＰ以外で受信したか否かを確認し、前記ＭＴＣＤの設置通知が、ＭＴＣＤからのデータであるか否かを判断する。ＨｅＮＢは、ＭＴＣＤの識別子を含むＭＴＣＤの設置通知を３ＧＰＰ以外で受信したと判断した場合は、ＭＴＣＤからのデータであると判断し、ステップＳＴ２７０４へ移行する。ＨｅＮＢは、ＭＴＣＤの識別子を含むＭＴＣＤの設置通知を３ＧＰＰ以外で受信しなかったと判断した場合は、ＭＴＣＤからのデータではないと判断し、本実施の形態の本質的な部分ではないので、説明を省略することとして、処理を終了する。

また、ＭＴＣＤの識別子が含まれているか否かを確認せずに、３ＧＰＰ以外で受信した場合は、ＭＴＣＤからのデータであると判断し、ステップＳＴ２７０４へ移行するようにしてもよい。３ＧＰＰ内で受信した場合は、ノーマルＵＥからのデータであると判断し、本実施の形態の本質的な部分ではないので、説明を省略することとして、処理を終了するようにしてもよい。

ステップＳＴ２７０４において、ＨｅＮＢは、集線処理を行うＭＴＣＤの識別子を記憶する。本動作例においては、ＭＴＣＤ＿１の識別子とＭＴＣＤ＿ｎの識別子とを記憶する。

ステップＳＴ２７０５において、ＨｅＮＢは、集線処理を行う。本動作例においては、ＨｅＮＢは、ＭＴＣＤ＿１およびＭＴＣＤ＿ｎからのコアネットワークへのデータをまとめてＭＭＥへ通知する。また、３ＧＰＰ以外によるアクセスであるステップＳＴ２７０１とステップＳＴ２７０２との内容を解釈し、「設置」に関するアクセスであると理解する。次に、「設置」に関するアクセスに即した３ＧＰＰ内のプロトコルとして「Attach procedure」を選定する。また「Attach procedure」にパラメータとして、ステップＳＴ２７０１で受信したＭＴＣＤ＿１の識別子と、ステップＳＴ２７０２で受信したＭＴＣＤ＿ｎの識別子と、自ＨｅＮＢの識別子と、ＨｅＮＢのトラッキングエリアとをマッピングする。

本動作例では、ステップＳＴ２７０１の処理の後に、ステップＳＴ２７０３、ステップＳＴ２７０４およびステップＳＴ２７０５に相当する処理が行われるが、理解を容易にするために、説明を省略している。

ステップＳＴ２７０６において、ＨｅＮＢは、ステップＳＴ２７０５で集線処理を行うことによって集線されたアタッチメッセージをＭＭＥへ通知する。アタッチメッセージには、集線処理の対象となったＭＴＣＤの識別子であるＭＴＣＤ＿１の識別子およびＭＴＣＤ＿ｎの識別子と、ＨｅＮＢの識別子と、ＴＡＩとが含まれる。該通知には、実施の形態２、実施の形態２の変形例１、実施の形態２の変形例２および実施の形態２の変形例３を用いることができる。

ステップＳＴ２７０６の処理の後は、ＭＭＥがステップＳＴ２６０５の処理を行い、ＨＳＳがステップＳＴ２６０６の処理を行う。次にＭＭＥが、ステップＳＴ２６０７においてＭＴＣＤ＿１宛の着信を受信し、ＭＭＥがステップＳＴ２６０８およびステップＳＴ２６０９の処理を行う。

次に、ステップＳＴ２７０７において、ＨｅＮＢは、ステップＳＴ２６０９で受信したページングに含まれるＭＴＣＤ＿１についての集線処理を行ったか否かを判断する。ステップＳＴ２７０７の処理の判断には、ステップＳＴ２７０４で記憶した情報を用いるとよい。集線処理を行ったと判断した場合は、ステップＳＴ２７０８へ移行する。集線処理を行っていないと判断した場合は、ステップＳＴ２７０９へ移行する。本動作例においては、ＨｅＮＢは、ＭＴＣＤ＿１についての集線処理を行っているので、ステップＳＴ２７０８へ移行する。

ステップＳＴ２７０８において、ＨｅＮＢは、ＭＴＣＤ＿１宛の着信をＭＴＣＤ＿１へ通知する。ステップＳＴ２７０８の着信の通知は、ステップＳＴ２７０１で用いられた３ＧＰＰ以外の通信システムを用いて行う。ステップＳＴ２７０９において、ＨｅＮＢは、ステップＳＴ２６０９で受信したページングに含まれるＭＴＣＤ＿１のトラッキングエリアリストに含まれるトラッキングエリアに、自ＨｅＮＢが含まれるか否かを判断する。自ＨｅＮＢが含まれると判断した場合は、ステップＳＴ２７１０へ移行する。自ＨｅＮＢが含まれないと判断した場合は、ステップＳＴ２７１０の処理を行わない。ステップＳＴ２７１０において、ＨｅＮＢは、３ＧＰＰ内の通信システムを用いて着信の通知を行う。

また本実施の形態では、ＨｅＮＢとＭＴＣＤとの間の通信方法が３ＧＰＰ以外である場合について説明したが、ＨｅＮＢとＭＴＣＤとの間の通信方法が３ＧＰＰ内である場合でも本実施の形態を用いることができる。

以上に述べた実施の形態４では、実施の形態１を実行し、ＨｅＮＢとＭＴＣＤとの間の通信方法として、３ＧＰＰによって標準規格化された移動体通信システム以外の通信システムを用いた場合のページング（Paging）方法について開示している。実施の形態４を実行することによって、３ＧＰＰによって標準規格化された移動体通信システム以外の通信システムを用いた場合に、ページング（Paging）を実行することができる。

実施の形態４変形例１．
前述の実施の形態４を用いた場合、以下の課題が発生する。ＭＴＣＤが移動し、ＨｅＮＢ経由でのＭＴＣサーバとの通信が不可能となった場合であっても、ＨｅＮＢ内で集線処理を行ったＭＴＣＤとして、ＭＴＣＤの識別子が記憶され続ける。これによって、ＨｅＮＢの記憶領域が不要なデータに用いられるという課題が発生する。

実施の形態４の変形例１での解決策として、以下の（１），（２）の２つを開示する。（１）ＭＴＣＤは、移動して、ＨｅＮＢ経由でのＭＴＣサーバとの通信が不可能となった場合、その旨をＨｅＮＢへ通知する。ＭＴＣＤは、移動する場合、その旨をソースＨｅＮＢへ通知する。該通知を受信したＨｅＮＢは、集線処理を行ったＭＴＣＤの記憶から、該ＭＴＣＤを削除する。

（２）ＭＴＣＤは、移動して、ＨｅＮＢ経由でのＭＴＣサーバとの通信が不可能となった場合、その旨をＨｅＮＢ経由でコアネットワークへ通知する。ＭＴＣＤは、移動する場合、その旨をソースＨｅＮＢ経由でコアネットワークへ通知する。該通知を受信したコアネットワークは、ＭＴＣＤのソースセルを変更するか否かを判断する。コアネットワークは、ソースセルを変更する旨の決定をした場合は、ソースセルを変更する旨をＨｅＮＢへ通知する。該通知を受信したＨｅＮＢは、集線処理を行ったＭＴＣＤの記憶から、ＭＴＣＤを削除する。コアネットワークからＨｅＮＢへのソースセルを変更する旨の通知には、ＭＴＣＤの識別子が含まれる。

ＭＴＣＤからＨｅＮＢへ通知する内容の具体例として、以下の（１）〜（３）の３つを開示する。（１）移動する旨。（２）サービングセルを変更する旨。（３）ハンドオーバする旨。

実施の形態４の変形例１により、実施の形態４の効果に加えて、以下の効果を得ることができる。ＭＴＣＤが移動し、ＨｅＮＢ経由でのＭＴＣサーバとの通信が不可能となった場合、つまりＨｅＮＢがＭＴＣＤの集線処理を行うことができなくなった場合、ＨｅＮＢの記憶領域から、ＭＴＣＤのデータを削除することが可能となる。これによって、無駄なデータでＨｅＮＢの記憶領域を使用することを防ぐことができる。

実施の形態５．
本実施の形態５では、実施の形態１を実行した際のページング（Paging）方法について開示する。本実施の形態５では、ＭＴＣＤ毎へのページングではなく、ＨｅＮＢ毎でのページング方法について開示する。集線処理を行ったＨｅＮＢ毎であってもよい。

実施の形態５での解決策を以下に示す。実施の形態１での解決策と異なる部分を中心に説明する。説明していない部分については、実施の形態１と同様とする。

オペレータ、あるいはＭＴＣユーザへの登録などは、ＭＴＣＤ個別で行わず、集線処理を行うＨｅＮＢ単位で行う。サービス形態の一例を挙げる。家屋に設置されるＨｅＮＢ毎に１つのＭＴＣＤとしての契約を行う。ＨｅＮＢの傘下に複数のＭＴＣＤが存在した場合であっても、ＨｅＮＢとして１つの契約となる。集線処理を行ったＨｅＮＢ単位でコアネットワークへ登録し、ページングはＨｅＮＢ宛へ行う。ページングを受信したＨｅＮＢは、傘下の全てのＭＴＣＤへ着信通知を行う。

集線処理の具体例について、以下に開示する。実施の形態１で開示した具体例（１）〜（４）と合わせて、以下の具体例（５）の動作を行う。（５）傘下のＭＴＣＤからコアネットワークへのデータ中に含まれるＭＴＣＤの識別子を削除し、代わりに自ＨｅＮＢの識別子をマッピングする。既にＨｅＮＢの識別子を付加してコアネットワークへ通知するようなメッセージの場合は、ＭＴＣＤの識別子を削除するのみでよい。

コアネットワークへの登録方法の具体例について、以下に開示する。ＭＭＥは、ＨＳＳにＭＴＣＤの識別子ではなく、ＭＴＣＤのコアネットワークへのデータを集線処理したＨｅＮＢの識別子を通知する。ＨＳＳは、ＭＴＣＤの識別子ではなく、集線処理したＨｅＮＢの識別子を登録する。

ＨｅＮＢが傘下の全てのＭＴＣＤへ着信を通知する具体例として、以下の（１），（２）の２つを開示する。（１）報知情報を用いる。（２）グループ呼出しを用いる。

実施の形態５を用いた具体的な動作例を、図２８を用いて説明する。図２８は、実施の形態５における移動体通信システムのシーケンスを示す図である。図２８において、図１７および図２６に示すステップに対応するステップについては、同一の参照符を付して、共通する説明を省略する。

本動作例では、ＨｅＮＢで集線処理を行うＭＴＣＤからコアネットワークへのデータの具体例として、ＮＡＳシグナリングの場合について開示する。また、ＨｅＮＢが、傘下の移動端末（ＵＥ）がＭＴＣＤであるか、ＭＴＣＤ以外であるかを区別する方法の具体例として、ＲＲＣメッセージ「RRC Connection Request」にＭＴＣＤインジケータをマッピングする場合について開示する。またＨｅＮＢが、傘下の全てのＭＴＣＤへ着信を通知する具体例については、報知情報を用いる場合について開示する。

まず、ＭＴＣＤ＿１がステップＳＴ１７０３の処理を行い、ＭＴＣＤ＿ｎがステップＳＴ１７０４の処理を行う。次に、ＭＴＣＤ＿１およびＭＴＣＤ＿ｎから送信された「RRC Connection Request」を受信したＨｅＮＢは、ステップＳＴ１７０５およびステップＳＴ１７０７の処理を行う。次に、ＭＴＣＤ＿１がステップＳＴ２６０１の処理を行い、ＭＴＣＤ＿ｎがステップＳＴ２６０２の処理を行う。

次に、ステップＳＴ２８０１において、ＨｅＮＢは、ステップＳＴ２６０１で受信したＭＴＣＤ＿１からのアタッチメッセージと、ステップＳＴ２６０２で受信したＭＴＣＤ＿ｎからのアタッチメッセージとを集線処理する。本動作例では、集線処理として、複数のＭＴＣＤからコアネットワークへのデータであるアタッチメッセージを、まとめてＭＭＥへ通知することとする。その際、傘下のＭＴＣＤからコアネットワークへのデータ中に含まれるＭＴＣＤの識別子であるＭＴＣＤ＿１の識別子と、ＭＴＣＤ＿ｎの識別子とを、ＭＭＥへ通知しない。ＭＴＣＤの識別子を通知しない代わりに、自ＨｅＮＢの識別子を通知する。但し、自ＨｅＮＢの識別子は、現行の規格のｅＮＢからＭＭＥへの「Attach procedure」で通知されるパラメータである（非特許文献１３参照）。本動作例のステップＳＴ２８０１では、傘下のＭＴＣＤから受信したアタッチメッセージから、ＭＴＣＤの識別子を削除するのみでもよい。

ステップＳＴ２８０２において、ＨｅＮＢは、ステップＳＴ２８０１で集線処理を行うことによって集線されたアタッチメッセージをＭＭＥへ通知する。アタッチメッセージには、集線処理の対象となったＭＴＣＤの識別子であるＭＴＣＤ＿１の識別子およびＭＴＣＤ＿ｎの識別子は含まれず、ＨｅＮＢの識別子と、ＴＡＩとが含まれる。またＴＡＩの通知は任意である。ステップＳＴ２８０２の通知には、実施の形態２、実施の形態２の変形例１、実施の形態２の変形例２および実施の形態２の変形例３を用いることができる。

ステップＳＴ２８０３において、ＭＭＥは、ＨＳＳへアタッチメッセージで受信したＨｅＮＢの識別子を通知する。ステップＳＴ２８０４において、ＨＳＳは、アタッチ処理されたＨｅＮＢを登録し、管理する。

ステップＳＴ２８０５において、ＭＭＥは、ＨｅＮＢ宛の着信を受信したとする。着信の詳細な方法については、非特許文献１３および非特許文献１４に開示されている。着信には、ＨｅＮＢの識別子が含まれる。これによって、ＨｅＮＢ単位の着信をすることができる。

ステップＳＴ２８０６において、ＭＭＥは、自ＭＭＥの傘下にＨｅＮＢが存在するか否かを判断する。存在すると判断した場合は、ステップＳＴ２８０７へ移行し、存在しないと判断した場合は、処理を終了する。本動作例では、自ＭＭＥの傘下にＨｅＮＢが存在するので、ステップＳＴ２８０７へ移行する。ステップＳＴ２８０６の処理を行わずに、ＭＭＥは、ステップＳＴ２８０７において、傘下の基地局であるｅＮＢ、ＨｅＮＢなどへ、ページングを通知してもよい。

ステップＳＴ２８０７において、ＭＭＥは、ＨｅＮＢへＨｅＮＢ宛のページングを通知する。該ページングには、ＭＴＣＤ＿１のトラッキングエリアリスト、ＭＴＣＤ＿１の識別子および「UE Identity Index value」は含まれない。「UE Identity Index value」の説明は、後述の実施の形態６に示す。ＭＴＣＤ＿１のトラッキングエリアリストおよびＭＴＣＤ＿１の識別子が含まれない代わりに、ＨｅＮＢの識別子が含まれる。ＨｅＮＢの識別子が含まれることによって、ＨｅＮＢ単位に着信させることができる。

ステップＳＴ２８０８において、ＨｅＮＢは、ステップＳＴ２８０７で受信したページングに含まれる識別子が、ＨｅＮＢの識別子であるか否かを判断する。ＨｅＮＢは、ＨｅＮＢの識別子であると判断した場合は、ステップＳＴ２８０９へ移行する。ＨｅＮＢは、ＨｅＮＢの識別子でないと判断した場合は、移動端末の識別子であると判断して、ステップＳＴ２６１０へ移行する。本動作例では、ステップＳＴ２８０７において受信したページングに含まれる識別子は、ＨｅＮＢの識別子であるので、ステップＳＴ２８０９へ移行する。

ステップＳＴ２８０９において、ＨｅＮＢは、ステップＳＴ２８０７で受信したページングに含まれるＨｅＮＢの識別子が、自ＨｅＮＢの識別子であるか否かを判断する。自ＨｅＮＢであると判断した場合は、ステップＳＴ２８１０へ移行する。自ＨｅＮＢでないと判断した場合は、処理を終了する。本動作例では、ステップＳＴ２８０７で受信したページングに含まれるＨｅＮＢの識別子は、自ＨｅＮＢの識別子であるので、ステップＳＴ２８１０へ移行する。

ステップＳＴ２８１０において、ＨｅＮＢは、傘下の全てのＭＴＣＤへ報知情報を用いて着信を通知する。

ステップＳＴ２８１１において、ＨｅＮＢは、通常通りに移動端末識別子を含むページングを通知する。該ページングは、３ＧＰＰによって標準規格化された移動体通信システムで通知する。具体的には、ページングメッセージは、論理チャネルであるＰＣＣＨにマッピングされ、ＰＣＣＨは、トランスポートチャネルであるＰＣＨへマッピングされ、ＰＣＨは、物理チャネルであるＰＤＳＣＨへマッピングされる。ＰＤＣＣＨで全移動端末共通のページングインジケータを送信する。ページングインジケータが送信されたＰＤＣＣＨによって、前記ページングメッセージがマッピングされたＰＤＳＣＨのリソースが割り当てられる。ページングの通知の詳細な方法については、非特許文献１、非特許文献２および非特許文献１６に開示されている。

また実施の形態では、ＨｅＮＢとＭＴＣＤとの間の通信方法が３ＧＰＰ内である場合について説明したが、ＨｅＮＢとＭＴＣＤとの間の通信方法が３ＧＰＰ以外である場合でも本実施の形態を用いることができる。

以上に述べた実施の形態５では、実施の形態１を実行し、ＭＴＣＤ毎へのページングではなく、ＨｅＮＢ毎でのページング方法について開示している。実施の形態５を実行することによって、ＨｅＮＢ毎でのページングを実現することができる。

実施の形態５変形例１．
本実施の形態５の変形例１では、実施の形態５を実行して、オペレータ、あるいはＭＴＣユーザへの登録などは、ＭＴＣＤ個別で行わず、集線処理を行うＨｅＮＢ単位で行った場合であっても、ＭＴＣＤ毎へのページングを行う方法について開示する。

実施の形態５の変形例１での解決策を以下に示す。実施の形態１および実施の形態５の解決策と異なる部分を中心に説明する。説明していない部分については、実施の形態１および実施の形態５と同様とする。

ＨｅＮＢは、集線処理を行ったＭＴＣＤの識別子を記憶し、ＭＭＥから該ＨｅＮＢの識別子とは別にＭＴＣＤの識別子を含むページングメッセージを受信したときには、傘下のＭＴＣＤへ着信を通知する。

実施の形態５の変形例１を用いた具体的な動作例を、図２９を用いて説明する。図２９は、実施の形態５の変形例１における移動体通信システムのシーケンスを示す図である。図２９において、図１７、図２６および図２８に示すステップに対応するステップについては、同一の参照符を付して、共通する説明を省略する。

まず、ＭＴＣＤ＿１がステップＳＴ１７０３の処理を行い、ＭＴＣＤ＿ｎがステップＳＴ１７０４の処理を行う。次に、ＭＴＣＤ＿１およびＭＴＣＤ＿ｎから送信された「RRC Connection Request」を受信したＨｅＮＢは、ステップＳＴ１７０５およびステップＳＴ１７０７の処理を行う。次に、ＭＴＣＤ＿１がステップＳＴ２６０１の処理を行い、ＭＴＣＤ＿ｎがステップＳＴ２６０２の処理を行う。次に、ＭＴＣＤ＿１およびＭＴＣＤ＿ｎから送信されたアタッチメッセージを受信したＨｅＮＢは、ステップＳＴ２７０４、ステップＳＴ２８０１およびステップＳＴ２８０２の処理を行う。次に、ＭＭＥがステップＳＴ２８０３の処理を行い、ＨＳＳがステップＳＴ２８０４の処理を行う。

ステップＳＴ２９０１において、ＭＭＥは、ＨｅＮＢ宛の着信を受信したとする。着信の詳細な方法については、非特許文献１３および非特許文献１４に開示されている。着信には、ＨｅＮＢの識別子とは別に、個別に呼び出したいＭＴＣＤ＿１の識別子が含まれる。これによって、オペレータなどへの登録をＭＴＣＤ個別で行わず、集線処理を行うＨｅＮＢ単位で行った場合であっても、ＭＴＣＤ毎へのページングを行うことができる。ＭＭＥは、ステップＳＴ２９０１の処理の後に、ステップＳＴ２８０６の処理を行う。ステップＳＴ２８０６において、ＭＭＥが、自ＭＭＥの傘下にＨｅＮＢが存在すると判断した場合は、ステップＳＴ２９０２へ移行する。

ステップＳＴ２９０２において、ＭＭＥは、ＨｅＮＢへＨｅＮＢ宛のページングを通知する。該ページングには、ＭＴＣＤ＿１の識別子は含まれるが、ＭＴＣＤ＿１のトラッキングエリアリストは含まれない。ＨｅＮＢは、ステップＳＴ２８０８およびステップＳＴ２８０９の処理を行う。ステップＳＴ２８０９において、ＨｅＮＢが、ステップＳＴ２９０２で受信したページングに含まれるＨｅＮＢの識別子が、自ＨｅＮＢの識別子であると判断した場合は、ステップＳＴ２９０３へ移行する。

ステップＳＴ２９０３において、ＨｅＮＢは、ステップＳＴ２９０２で受信したページングに含まれるＭＴＣＤ＿１識別子のＭＴＣＤ＿１についての集線処理を行ったか否かを判断する。ステップＳＴ２９０３の判断には、ステップＳＴ２７０４で記憶した情報を用いるとよい。集線処理を行ったと判断した場合は、ステップＳＴ２６１１へ移行する。集線処理を行っていないと判断した場合は、処理を終了する。

本変形例では、実施の形態１、実施の形態２、実施の形態２の変形例１、実施の形態２の変形例２および実施の形態２の変形例３と組み合わせた例について主に記載したが、実施の形態１の変形例１、実施の形態１の変形例２、実施の形態１の変形例３および実施の形態２の変形例４とも組み合わせて用いることができる。

また本変形例では、ＨｅＮＢとＭＴＣＤとの間の通信方法が３ＧＰＰ内である場合について説明したが、ＨｅＮＢとＭＴＣＤとの間の通信方法が３ＧＰＰ以外である場合でも、本変形例を用いることができる。

以上に述べた実施の形態５の変形例１では、実施の形態１に加えて、実施の形態５を実行し、オペレータ、あるいはＭＴＣユーザへの登録などは、ＭＴＣＤ個別で行わず、集線処理を行うＨｅＮＢ単位で行った場合であっても、ＭＴＣＤ毎のページングを行う方法について開示している。実施の形態５の変形例１を実行することによって、オペレータ、あるいはＭＴＣユーザへの登録などを、集線処理を行うＨｅＮＢ単位で行った場合に、ＭＴＣＤ毎のページングを実現することができる。

実施の形態６．
実施の形態６で解決する課題について、以下に説明する。実施の形態５において、ＨｅＮＢが、傘下の全てのＭＴＣＤへ着信を通知する場合に報知情報を用いる場合、無線区間、つまりＨｅＮＢとＭＴＣＤとの間が通常のページング送信とは異なる。ＭＭＥからＨｅＮＢへのページング中には、無線区間の設定に用いるパラメータが存在する。したがって、無駄なパラメータが存在することとなり、リソースの無駄が発生する。

実施の形態６での解決策を以下に示す。実施の形態１、あるいは実施の形態５の解決策と異なる部分を中心に説明する。説明していない部分については、実施の形態１、あるいは実施の形態５と同様とする。

ＭＴＣＤ毎へのページングではなく、ＨｅＮＢ毎でのページングを実行する場合、ＭＭＥからＨｅＮＢへのページングメッセージは、現行の規格（非特許文献１４参照）と異ならせる。ＭＭＥは、受信した着呼に、ＭＴＣＤ識別子ではなく、ＨｅＮＢ識別子が含まれていた場合、ＭＭＥからＨｅＮＢへのページングメッセージは、現行の規格と異ならせる。

現行の規格とは異ならせるページングメッセージの具体例として、以下の（１），（２）のに２つ開示する。

（１）新たなＨｅＮＢ単位のページングメッセージを設ける。または新たな集線処理を行った場合のページングメッセージを設ける。新たなメッセージに含まれるパラメータの具体例としては、ＨｅＮＢの識別子がある。

（２）既存のＳ１シグナリングである「Paging」を、ＨｅＮＢ単位のページングに用いる。既存のＳ１シグナリングである「Paging」を、集線処理を行った場合のページングに用いる。

次に「Paging」に追加および変更が必要なパラメータについて説明する。追加が必要なパラメータの具体例としては、ＨｅＮＢの識別子がある。変更が必要なパラメータの具体例として、以下の（ａ）〜（ｃ）の３つを開示する。

（ａ）「UE Identity Index value」。現行の規格では、「UE Identity Index value」は、ｅＮＢがページングを送信する無線フレームである「Paging Frame：ＰＦ」を計算するために用いられる。ＨｅＮＢが、傘下のＭＴＣＤへ報知情報を用いて着信を通知する場合、ＨｅＮＢにおいてページングを送信する無線フレームの計算は不要である。したがって、「UE Identity Index value」の指定が移動体通信システム上不可能な状況が発生する。また、現行の規格では、「Paging」には「UE Identity Index value」を必ずマッピングする必要がある。つまり、ＭＴＣＤ毎へのページングではなく、ＨｅＮＢ毎でのページングを現行の「Paging」で送信するような場合、「UE Identity Index value」の取扱いにおいて、移動体通信システムとして統一がなくなるという問題が発生する。移動体通信システムとして統一が図られなければ、安定した通信網が供給できないなどの問題が発生する。そこで、例えば「Paging」にＨｅＮＢの識別子がマッピングされていれば、ＨｅＮＢ毎でのページングであると判断し、「UE Identity Index value」はマッピングされていても、受信側で無効なパラメータとするか、あるいは送信側でのマッピングを必須とせずにオプションとする。これによって、ＭＭＥおよびＨｅＮＢの処理が明確となり、統一した移動体通信網の構築が可能となり、安定した通信網の供給が可能となる。

（ｂ）「UE Paging Identity」。現行の規格では、「UE Paging Identity」は呼び出される移動端末の識別子である。ＨｅＮＢが、傘下の全てのＭＴＣＤへ報知情報を用いて着信を通知する場合、ＨｅＮＢにおいて、移動端末の一種であるＭＴＣＤの個別の識別子は不要である。また、発呼側からもＭＴＣＤの個別の識別子は通知されないことが想定される。したがって、「UE Paging Identity」の指定が移動体通信システム上不可能な状況が発生する。また、現行の規格では、「Paging」には「UE Paging Identity」を必ずマッピングする必要がある。つまり、ＭＴＣＤ毎へのページングではなく、ＨｅＮＢ毎でのページングを現行の「Paging」で送信するような場合、「UE Paging Identity」の取扱いにおいて、移動体通信システムとして統一がなくなるという問題が発生する。移動体通信システムとして統一が図られなければ、安定した通信網が供給できないなどの問題が発生する。そこで、例えば「Paging」にＨｅＮＢの識別子がマッピングされていれば、ＨｅＮＢ毎でのページングであると判断し、「UE Paging Identity」はマッピングされていても、受信側で無効なパラメータとするか、あるいは送信側でのマッピングを必須とせずにオプションとする。これによって、ＭＭＥおよびＨｅＮＢの処理が明確となり、統一した移動体通信網の構築が可能となり、安定した通信網の供給が可能となる。

（ｃ）「TA情報」。現行の規格では、「TA情報」は、ＴＡ情報に属するｅＮＢがページングを送信する。ＨｅＮＢが、傘下のＭＴＣＤへ報知情報を用いて着信を通知する場合、ページング中にＨｅＮＢの識別子が含まれる。これによって、ページングに含まれるＨｅＮＢの識別子と一致するＨｅＮＢが、傘下のＭＴＣＤへ着信を通知するようにしてもよい。したがって「TA情報」は、特に必要ではないパラメータとなる。一方、現行の規格では、「Paging」には「TA情報」を必ずマッピングする必要がある。つまり、ＭＴＣＤ毎へのページングではなく、ＨｅＮＢ毎でのページングを現行の「Paging」で送信するような場合、不要なパラメータである「TA情報」が通知される。そこで、例えば「Paging」にＨｅＮＢの識別子がマッピングされていれば、ＨｅＮＢ毎でのページングであると判断し、送信側での「TA情報」のマッピングを必須とせずにオプションとする。これによって、無駄なパラメータの送信を防止することが可能となる。

実施の形態６により、実施の形態５の効果に加えて、以下の効果を得ることができる。ＭＭＥからＨｅＮＢへのページング中の無駄なパラメータを削減することができ、リソースを有効に活用することができる。

実施の形態７．
実施の形態７で解決する課題について、以下に説明する。まず、現行のページング方法について説明する。非特許文献１４には、以下のことが開示されている。ＭＭＥからｅＮＢへ通知されるページングメッセージ中に含まれるＴＡＩＬｉｓｔで示されたトラッキングエリアに属する各セルでは、無線インタフェース上でページングを発生させる。

図３０を用いて、現行のページング方法について再度説明する。図３０は、現行のページング方法を説明するためのロケーションを示す図である。まず、図３０のロケーションについて説明する。ｅＮＢ３００１、ＨｅＮＢ３００３、ＨｅＮＢ３００５、ＨｅＮＢ３００７が設置されている。ｅＮＢ３００１は、カバレッジ３００２を持つ。ＨｅＮＢ３００３は、カバレッジ３００４を持つ。ＨｅＮＢ３００５は、カバレッジ３００６を持つ。ＨｅＮＢ３００７は、カバレッジ３００８を持つ。ＨｅＮＢ３００７のカバレッジ３００８内に、移動端末３００９が存在する。ｅＮＢ３００１のカバレッジ３００２内に、ｅＮＢ３００１、ＨｅＮＢ３００３、ＨｅＮＢ３００５およびＨｅＮＢ３００７が存在する。トラッキングエリア＃１（ＴＡ＃１）３０１６に、ｅＮＢ３００１、ＨｅＮＢ３００３、ＨｅＮＢ３００５およびＨｅＮＢ３００７が含まれる。

また、ｅＮＢ３０１０、ＨｅＮＢ３０１２およびＨｅＮＢ３０１４が設置されている。ｅＮＢ３０１０は、カバレッジ３０１１を持つ。ＨｅＮＢ３０１２は、カバレッジ３０１３を持つ。ＨｅＮＢ３０１４は、カバレッジ３０１５を持つ。ｅＮＢ３０１０のカバレッジ３０１１内に、ｅＮＢ３０１０、ＨｅＮＢ３０１２およびＨｅＮＢ３０１４が存在する。トラッキングエリア＃２（ＴＡ＃２）３０１７に、ｅＮＢ３０１０、ＨｅＮＢ３０１２およびＨｅＮＢ３０１４が含まれる。

移動端末３００９のトラッキングエリアリストとして、トラッキングエリア＃１（ＴＡ＃１）３０１６と、トラッキングエリア＃２（ＴＡ＃２）３０１７とが登録されている場合を考える。前記ロケーションにおいて、移動端末３００９に着信が発生した場合の、現行のページング方法について説明する。

現行の規格では、ＭＭＥからｅＮＢへ通知されるページングメッセージ中に含まれるＴＡＩＬｉｓｔで示されたトラッキングエリアに属する各セルでは、無線インタフェース上でページングを発生させる。したがって、トラッキングエリア＃１（ＴＡ＃１）３０１６に属するｅＮＢ３００１、ＨｅＮＢ３００３、ＨｅＮＢ３００５およびＨｅＮＢ３００７と、トラッキングエリア＃２（ＴＡ＃２）３０１７に属するｅＮＢ３０１０、ＨｅＮＢ３０１２およびＨｅＮＢ３０１４とから、無線インタフェースを用いてページングが発生する。無意味なページング送信は、無線リソースを有効に活用することができず、また干渉が発生するという従来からの課題がある。

次に、実施の形態７で解決する課題について、以下に説明する。集線処理を行う能力を有するＨｅＮＢと、集線処理を行う能力を有していないＨｅＮＢとが存在する場合を考える。前述の実施の形態３および実施の形態４を実行した場合、集線処理能力を有していないＨｅＮＢからＭＴＣＤへのページング通知、あるいは着信通知が無駄となる。これによって、無線リソースを有効に活用することができないという課題が生じる。

前述の実施の形態３を実行した場合の無線リソースの無駄を、図３１および図３２を用いて説明する。図３１および図３２は、実施の形態３を実行した場合の無線リソースの無駄を説明するための移動体通信システムのシーケンスを示す図である。図３１と図３２とは、境界線Ｌ１の位置で、つながっている。図３１および図３２において、図１７および図２６に示すステップに対応するステップについては、同一の参照符を付して、共通する説明を省略する。

本動作例では、図３０に示すロケーション図を用いて説明する。ＨｅＮＢ３００３とＨｅＮＢ３００７とが、集線処理を行う能力を有するＨｅＮＢとし、ＨｅＮＢ３００５が、集線処理を行う能力を有していないＨｅＮＢとする。移動端末３００９は、ＭＴＣＤとし、ＭＴＣＤの識別子をＭＴＣＤ＿１とする。

まず、ＭＴＣＤ＿１がステップＳＴ１７０３の処理を行い、ＭＴＣＤ＿ｎがステップＳＴ１７０４の処理を行う。次に、ＭＴＣＤ＿１およびＭＴＣＤ＿ｎから送信された「RRC Connection Request」を受信したＨｅＮＢ３００７は、ステップＳＴ１７０５およびステップＳＴ１７０７の処理を行う。次に、ＭＴＣＤ＿１がステップＳＴ２６０１の処理を行い、ＭＴＣＤ＿ｎがステップＳＴ２６０２の処理を行う。次に、ＭＴＣＤ＿１およびＭＴＣＤ＿ｎから送信されたアタッチメッセージを受信したＨｅＮＢ３００７は、ステップＳＴ２６０３およびステップＳＴ２６０４の処理を行う。次に、ＭＭＥがステップＳＴ２６０５の処理を行う。次に、ＨＳＳがステップＳＴ２６０６の処理を行う。

ステップＳＴ２６０７において、ＭＭＥが、ＭＴＣＤ＿１宛の着信を受信した後、ステップＳＴ２６０８において、ＭＭＥは、ＭＴＣＤ＿１のトラッキングエリアリスト（TAI Listとも称される）を検索する。本動作例では、ＭＭＥは、ＭＴＣＤ＿１のトラッキングエリアリストが、トラッキングエリア＃１（ＴＡ＃１）３０１６とトラッキングエリア＃２（ＴＡ＃２）３０１７とを含むことが判明する。

ステップＳＴ３１０１において、ＭＭＥは、ＨｅＮＢ３００７へＭＴＣＤ＿１宛のページングを通知する。該ページングには、ＭＴＣＤ＿１のトラッキングエリアリストおよびＭＴＣＤ＿１の識別子が含まれる。

ステップＳＴ３１０２において、ＭＭＥは、ＨｅＮＢ３００５へＭＴＣＤ＿１宛のページングを通知する。該ページングには、ＭＴＣＤ＿１のトラッキングエリアリストおよびＭＴＣＤ＿１の識別子が含まれる。

ステップＳＴ３１０３において、ＭＭＥは、ＨｅＮＢ３００３へＭＴＣＤ＿１宛のページングを通知する。該ページングには、ＭＴＣＤ＿１のトラッキングエリアリストおよびＭＴＣＤ＿１の識別子が含まれる。

ステップＳＴ３１０４において、ＨｅＮＢ３００７は、ステップＳＴ３１０１で受信したページングに含まれるＭＴＣＤ＿１のトラッキングエリアリストに含まれるトラッキングエリアに、自ＨｅＮＢが含まれるか否かを判断する。自ＨｅＮＢが含まれると判断した場合は、ステップＳＴ３１０５へ移行する。自ＨｅＮＢが含まれないと判断した場合は、ステップＳＴ３１０５の処理を行わない。本動作例では、図３０に示すように、トラッキングエリアリストに含まれるトラッキングエリア＃１（ＴＡ＃１）３０１６に、自ＨｅＮＢ３００７が含まれている。したがってステップＳＴ３１０４の処理の後は、ステップＳＴ３１０５へ移行する。

ステップＳＴ３１０５において、ＨｅＮＢ３００７は、ＭＴＣＤ＿１宛のページングをＭＴＣＤ＿１へ通知する。該ページングは、３ＧＰＰによって標準規格化された移動体通信システムで通知する。該ページングの通知の詳細な方法については、非特許文献１、非特許文献２および非特許文献１６に開示されている。

ステップＳＴ３１０６において、ＨｅＮＢ３００５は、ステップＳＴ３１０２で受信したページングに含まれるＭＴＣＤ＿１のトラッキングエリアリストに含まれるトラッキングエリアに、自ＨｅＮＢが含まれるか否かを判断する。自ＨｅＮＢが含まれると判断した場合は、ステップＳＴ３１０７へ移行する。自ＨｅＮＢが含まれないと判断した場合は、ステップＳＴ３１０７の処理を行わない。本動作例では、図３０に示すように、トラッキングエリアリストに含まれるトラッキングエリア＃１（ＴＡ＃１）３０１６に、自ＨｅＮＢ３００５が含まれている。したがってステップＳＴ３１０６の処理の後は、ステップＳＴ３１０７へ移行する。

ステップＳＴ３１０７において、ＨｅＮＢ３００５は、ＭＴＣＤ＿１宛のページングを通知する。該ページングは、３ＧＰＰによって標準規格化された移動体通信システムで通知する。該ページングの通知の詳細な方法については、非特許文献１、非特許文献２および非特許文献１６に開示されている。

ステップＳＴ３１０８において、ＨｅＮＢ３００３は、ステップＳＴ３１０３で受信したページングに含まれるＭＴＣＤ＿１のトラッキングエリアリストに含まれるトラッキングエリアに、自ＨｅＮＢが含まれるか否かを判断する。自ＨｅＮＢが含まれると判断した場合は、ステップＳＴ３１０９へ移行する。自ＨｅＮＢが含まれないと判断した場合は、ステップＳＴ３１０９の処理を行わない。本動作例では、図３０に示すように、トラッキングエリアリストに含まれるトラッキングエリア＃１（ＴＡ＃１）３０１６に、自ＨｅＮＢ３００３が含まれている。したがってステップＳＴ３１０８の処理の後は、ステップＳＴ３１０９へ移行する。

ステップＳＴ３１０９において、ＨｅＮＢ３００３は、ＭＴＣＤ＿１宛のページングを通知する。該ページングは、３ＧＰＰによって標準規格化された移動体通信システムで通知する。該ページングの通知の詳細な方法については、非特許文献１、非特許文献２および非特許文献１６に開示されている。

前述のように、ＭＴＣＤの識別子がＭＴＣＤ＿１である移動端末３００９は、ＨｅＮＢ３００７のカバレッジ３００８内に位置するので、ステップＳＴ３１０５におけるＨｅＮＢ３００７からのページングを受信することになる。したがって、ステップＳＴ３１０７におけるＨｅＮＢ３００５からのページング、およびステップＳＴ３１０９におけるＨｅＮＢ３００３からのページングは無駄となる。

次に、実施の形態４を実行した場合の無線リソースの無駄を、図３３および図３４を用いて説明する。図３３および図３４は、実施の形態４を実行した場合の無線リソースの無駄を説明するための移動体通信システムのシーケンスを示す図である。図３３と図３４とは、境界線Ｌ２の位置で、つながっている。図３３および図３４において、図２６、図２７、図３１および図３２に示すステップに対応するステップについては、同一の参照符を付して、共通する説明を省略する。

本動作例では、図３０に示すロケーション図を用いて説明する。ＨｅＮＢ３００３とＨｅＮＢ３００７とが、集線処理を行う能力を有するＨｅＮＢとし、ＨｅＮＢ３００５が、集線処理を行う能力を有していないＨｅＮＢとする。移動端末３００９は、ＭＴＣＤとし、ＭＴＣＤの識別子をＭＴＣＤ＿１とする。移動端末３００９からのデータを、ＨｅＮＢ３００７が集線処理したとする。

まず、ＭＴＣＤ＿１がステップＳＴ２７０１の処理を行い、ＭＴＣＤ＿ｎがステップＳＴ２７０２の処理を行う。次に、ＨｅＮＢ３００７が、ステップＳＴ２７０３〜ステップＳＴ２７０６の処理を行う。次に、ＭＭＥがステップＳＴ２６０５の処理を行い、ＨＳＳがステップＳＴ２６０６の処理を行う。

ＨｅＮＢ３００７は、集線処理を行う能力を有する。したがって、ステップＳＴ２７０７において、ＨｅＮＢは、ステップＳＴ３１０１で受信したページングに含まれるＭＴＣＤ＿１についての集線処理を行ったか否かを判断する。ステップＳＴ２７０７の処理の判断には、ステップＳＴ２７０４で記憶した情報を用いるとよい。集線処理を行ったと判断した場合は、ステップＳＴ２７０８へ移行する。集線処理を行っていないと判断した場合は、ステップＳＴ２７０９へ移行する。本動作例においては、ＨｅＮＢ３００７は、ＭＴＣＤ＿１についての集線処理を行っているので、集線処理を行ったと判断され、ステップＳＴ２７０８へ移行する。

また、ＨｅＮＢ３００５は、集線処理を行う能力を有していない。したがって、現行のページング方法の通り、ステップＳＴ３１０６において、ＨｅＮＢ３００５は、ステップＳＴ３１０２で受信したページングに含まれるＭＴＣＤ＿１のトラッキングエリアリストに含まれるトラッキングエリアに、自ＨｅＮＢが含まれるか否かを判断する。自ＨｅＮＢが含まれると判断した場合は、ステップＳＴ３１０７へ移行する。自ＨｅＮＢが含まれないと判断した場合は、ステップＳＴ３１０７の処理を行わない。本動作例では、図３０に示すように、トラッキングエリアリストに含まれるトラッキングエリア＃１（ＴＡ＃１）３０１６に、自ＨｅＮＢ３００５が含まれている。したがってステップＳＴ３１０６の処理の後は、ステップＳＴ３１０７へ移行する。

また、ＨｅＮＢ３００３は、集線処理を行う能力を有する。したがってステップＳＴ３２０１において、ＨｅＮＢは、ステップＳＴ３１０３で受信したページングに含まれるＭＴＣＤ＿１についての集線処理を行ったか否かを判断する。集線処理を行ったと判断した場合は、ステップＳＴ３１０９へ移行する。集線処理を行っていないと判断した場合は、ステップＳＴ３２０２へ移行する。本動作例においては、ＨｅＮＢ３００３は、ＭＴＣＤ＿１についての集線処理を行ってないので、集線処理を行っていないと判断され、ステップＳＴ３２０２へ移行する。

ステップＳＴ３２０２において、ＨｅＮＢは、ステップＳＴ３１０３で受信したページングに含まれるＭＴＣＤ＿１のトラッキングエリアリストに含まれるトラッキングエリアに、自ＨｅＮＢが含まれるか否かを判断する。自ＨｅＮＢが含まれると判断した場合は、ステップＳＴ３２０３へ移行する。自ＨｅＮＢが含まれないと判断した場合は、ステップＳＴ３２０３の処理を行わない。ステップＳＴ３２０３において、ＨｅＮＢは、３ＧＰＰ内の通信システムを用いて着信の通知を行う。本動作例においては、ＨｅＮＢ３００３は、ＭＴＣＤ＿１のトラッキングエリアに含まれるので、ステップＳＴ３２０３の処理を実行する。

前述のように、ＭＴＣＤの識別子がＭＴＣＤ＿１である移動端末３００９は、ＨｅＮＢ３００７のカバレッジ３００８内に位置するので、ステップＳＴ３１０５におけるＨｅＮＢ３００７からのページングを受信することになる。したがって、ステップＳＴ３１０７におけるＨｅＮＢ３００５からのページング、およびステップＳＴ３２０３におけるＨｅＮＢ３００３からのページングは無駄となる。

実施の形態７での解決策を以下に示す。ＨｅＮＢで集線処理を行う旨を、ＭＴＣＤの識別子とともにコアネットワーク側であるＭＭＥ、ＨＳＳなどへ登録する。集線処理を行うか否かの情報を、以下「集線処理状況」とも称する。ＭＴＣＤ宛のページングが発生した場合は、ページングメッセージ中に集線処理状況を含ませる。ＨｅＮＢが、集線処理を行う旨を示す情報が含まれるページングメッセージを受信した場合、自ＨｅＮＢが集線処理を行う能力を有する場合にページングメッセージを送信する。

ＨｅＮＢで集線処理を行う旨を、コアネットワークへ登録するタイミングの具体例として、以下の（１）〜（４）の４つを開示する。（１）ＨｅＮＢが、傘下のＭＴＣＤからコアネットワークへのデータを集線する毎。（２）ＭＴＣＤのアタッチメッセージを集線処理する際、あるいは集線処理の際に「Attach procedure」を選定する際。本具体例（２）は、具体例（１）と比較して、ＨｅＮＢが集線処理を行う旨をコアネットワークへ登録する回数が少なくなる。したがって、通信リソースを有効に活用することができ、ＨｅＮＢの処理の負荷を軽減することができる。（３）ＭＴＣＤのＴＡＵメッセージを集線処理する際、あるいは集線処理の際に「Tracking Area Update procedure」を選定する際。本具体例（３）は、具体例（１）と比較して、ＨｅＮＢが集線処理を行う旨をコアネットワークへ登録する回数が少なくなる。したがって、通信リソースを有効に活用することができ、ＨｅＮＢの処理の負荷を軽減することができる。（４）前記（２）と前記（３）との組み合わせ。

コアネットワークが、集線処理を行う旨の登録を削除するタイミングの具体例としては、ＭＴＣＤからの「Detach procedure」を受信した際である。登録方法の具体例を以下に開示する。ＭＴＣＤの識別子と関連付けて集線処理状況を記憶する。

登録するエンティティの具体例として、以下の（１），（２）の２つを開示する。（１）ＭＭＥ。着信処理の際に、他のエンティティに問い合わせを行う必要がなくなる。したがって制御遅延を防止することができ、通信システムの処理の負荷を軽減することができるという点で有効である。（２）ＨＳＳ。他の登録情報とともに記憶することができるので、データの一元管理が可能となるという点において有効である。具体例（１）と比較して、移動端末の移動によってＭＭＥが変更になった場合であっても、登録情報を有効に活用することができるという点で有効である。つまり、ＨｅＮＢからＨＳＳへの集線処理を行う旨の登録回数を削減することができる。これによって、通信リソースを有効に活用することができ、ＨｅＮＢの処理の負荷を軽減することができる。

ページングが発生した場合に、ページングメッセージ中に集線処理を行った旨を示す情報を含ませる方法の具体例として、以下の（１），（２）の２つを開示する。（１）登録場所がＨＳＳであった場合、発信元、あるいは着信元のＭＭＥが、ＨＳＳに集線処理状況を問い合わせる。ＭＭＥは、その問い合わせ結果をページングメッセージ中にマッピングする。（２）登録場所がＭＥＥであった場合、着信元のＭＭＥが着信のあったＭＴＣＤの集線処理状況を検索する。ＭＭＥは、その検索結果をページングメッセージ中にマッピングする。

実施の形態７を用いた具体的な動作例を、図３５および図３６を用いて説明する。図３５および図３６は、実施の形態７における移動体通信システムのシーケンスを示す図である。図３５と図３６とは、境界線Ｌ３の位置で、つながっている。図３５および図３６において、図１７、図２６、図３１および図３２に示すステップに対応するステップについては、同一の参照符を付して、共通する説明を省略する。

本動作例では、図３０に示すロケーション図を用いて説明する。ＨｅＮＢ３００３とＨｅＮＢ３００７とが、集線処理を行う能力を有するＨｅＮＢとし、ＨｅＮＢ３００５が、集線処理を行う能力を有していないＨｅＮＢとする。移動端末３００９は、ＭＴＣＤとし、ＭＴＣＤの識別子をＭＴＣＤ＿１とする。また、ＨｅＮＢで集線処理を行う旨をコアネットワークへ登録するタイミングの具体例として、ＭＴＣＤのアタッチメッセージを集線する際について開示する。また、登録するエンティティの具体例がＨＳＳである場合について開示する。また、実施の形態３を実行した場合について開示する。

まず、ＭＴＣＤ＿１がステップＳＴ１７０３の処理を行い、ＭＴＣＤ＿ｎがステップＳＴ１７０４の処理を行う。次に、ＭＴＣＤ＿１およびＭＴＣＤ＿ｎから送信された「RRC Connection Request」を受信したＨｅＮＢ３００７は、ステップＳＴ１７０５およびステップＳＴ１７０７の処理を行う。次に、ＭＴＣＤ＿１がステップＳＴ２６０１の処理を行い、ＭＴＣＤ＿ｎがステップＳＴ２６０２の処理を行う。次に、ＭＴＣＤ＿１およびＭＴＣＤ＿ｎから送信されたアタッチメッセージを受信したＨｅＮＢ３００７は、ステップＳＴ２６０３において、ステップＳＴ２６０１で受信したＭＴＣＤ＿１からのアタッチメッセージと、ステップＳＴ２６０２で受信したＭＴＣＤ＿ｎからのアタッチメッセージとを集線処理する。つまり、アタッチメッセージの集線処理を行っている。これによって、本動作例では、集線処理を行う旨をコアネットワークへ登録する。

次に、ステップＳＴ３３０１において、ＨｅＮＢ３００７は、ステップＳＴ２６０３で集線処理を行うことによって集線されたアタッチメッセージと、集線処理を行う旨とをＭＭＥへ通知する。アタッチメッセージには、集線処理の対象となったＭＴＣＤの識別子であるＭＴＣＤ＿１の識別子およびＭＴＣＤ＿ｎの識別子と、ＨｅＮＢの識別子と、ＴＡＩとが含まれる。アタッチメッセージ中に集線処理を行う旨を含ませてもよい。該通知には、実施の形態２、実施の形態２の変形例１、実施の形態２の変形例２および実施の形態２の変形例３を用いることができる。

ステップＳＴ３３０２において、ＭＭＥは、ＨＳＳ（Home Subscriber Server）へアタッチメッセージとして受信したＭＴＣＤの識別子であるＭＴＣＤ＿１の識別子およびＭＴＣＤ＿ｎの識別子と、集線処理を行う旨とを通知する。

ステップＳＴ３３０３において、ＨＳＳは、アタッチ処理されたＭＴＣＤ＿１の識別子およびＭＴＣＤ＿ｎの識別子と、集線処理を行う旨とを登録し、管理する。登録および管理の際は、集線処理状況をＭＴＣＤの識別子と関連付けて行う。ステップＳＴ２６０７において、ＭＭＥが、ＭＴＣＤ＿１宛の着信を受信した後、ＭＭＥは、ステップＳＴ２６０８の処理を行う。

次に、ステップＳＴ３３０４において、ＭＭＥは、ＭＴＣＤ＿１の集線状況をＨＳＳへ問い合わせる。ステップＳＴ３３０５において、ＨＳＳは、ＭＴＣＤ＿１の集線状況をＭＭＥへ報告する。本動作例では、ＭＴＣＤ＿１は、集線処理されているので、集線処理を行う旨が報告される。

ステップＳＴ３３０６において、ＭＭＥは、ステップＳＴ３３０５で受信した集線状況報告に基づいて、ＭＴＣＤ＿１が集線処理されたか否かを判断する。ＭＴＣＤ＿１が集線処理されたと判断した場合は、ステップＳＴ３３０７へ移行する。ＭＴＣＤ＿１が集線処理されていないと判断した場合は、ステップＳＴ３１０１へ移行する。本動作例では、ＭＴＣＤ＿１は集線処理されており、ステップＳＴ３３０５において集線処理を行う旨が報告されている。したがって、ＭＴＣＤ＿１が集線処理されたと判断され、ステップＳＴ３３０７へ移行する。

ステップＳＴ３３０７において、ＭＭＥは、ＭＴＣＤ＿１宛のページングメッセージに集線処理した旨を追加する。したがって、ステップＳＴ３３０７の処理を実行する本動作例においては、ステップＳＴ３１０１において、ＭＭＥからＨｅＮＢ３００７へ通知されるＭＴＣＤ＿１宛のページングメッセージ中には、ＭＴＣＤ＿１のトラッキングエリアリストおよびＭＴＣＤ＿１の識別子の他に、集線処理した旨が含まれる。同様に、ステップＳＴ３１０２において、ＭＭＥからＨｅＮＢ３００５へ通知されるＭＴＣＤ＿１宛のページングメッセージ中には、ＭＴＣＤ＿１のトラッキングエリアリストおよびＭＴＣＤ＿１の識別子の他に、集線処理した旨が含まれる。同様に、ステップＳＴ３１０３において、ＭＭＥからＨｅＮＢ３００３へ通知されるＭＴＣＤ＿１宛のページングメッセージ中には、ＭＴＣＤ＿１のトラッキングエリアリストおよびＭＴＣＤ＿１の識別子の他に、集線処理した旨が含まれる。

ステップＳＴ３３０８において、ＨｅＮＢ３００７は、ステップＳＴ３１０１で受信したページングに、集線処理した旨が含まれているか否かを判断する。集線処理した旨が含まれていると判断した場合は、ステップＳＴ３３０９へ移行する。集線処理した旨が含まれていないと判断した場合は、ステップＳＴ３１０４へ移行する。本動作例では、ステップＳＴ３１０１で受信したページングに、集線処理した旨が含まれている。したがってステップＳＴ３３０８の処理の後は、ステップＳＴ３３０９へ移行する。

ステップＳＴ３３０９において、ＨｅＮＢ３００７は、自ＨｅＮＢが集線処理能力を有するか否かを判断する。自ＨｅＮＢが集線処理能力を有すると判断した場合は、ステップＳＴ３１０４へ移行する。自ＨｅＮＢが集線処理能力を有していないと判断した場合は、ステップＳＴ３１０４およびステップＳＴ３１０５の処理を行わない。本動作例では、ＨｅＮＢ３００７は集線処理能力を有するので、ステップＳＴ３１０４へ移行する。次にＨｅＮＢ３００７は、ステップＳＴ３１０４およびステップＳＴ３１０５の処理を行う。

ステップＳＴ３３１０において、ＨｅＮＢ３００５は、ステップＳＴ３１０２で受信したページングに、集線処理した旨が含まれているか否かを判断する。集線処理した旨が含まれていると判断した場合は、ステップＳＴ３３１１へ移行する。集線処理した旨が含まれていないと判断した場合は、ステップＳＴ３１０６へ移行する。本動作例では、ステップＳＴ３１０２で受信したページングに集線処理した旨が含まれている。したがってステップＳＴ３３１０の処理の後は、ステップＳＴ３３１１へ移行する。

ステップＳＴ３３１１において、ＨｅＮＢ３００５は、自ＨｅＮＢが集線処理能力を有するか否かを判断する。自ＨｅＮＢが集線処理能力を有すると判断した場合は、ステップＳＴ３１０６へ移行する。自ＨｅＮＢが集線処理能力を有していないと判断した場合は、ステップＳＴ３１０６およびステップＳＴ３１０７の処理を行わない。本動作例では、ＨｅＮＢ３００５は集線処理能力を有していないので、ステップＳＴ３１０６およびステップＳＴ３１０７の処理を行わない。実施の形態３を実行した場合の無線リソースの無駄を説明する図３１および図３２では、図３２のステップＳＴ３１０７に示すように、ＨｅＮＢ３００５は、ＭＴＣＤ＿１を受信することがない、無駄なＭＴＣＤ＿１宛のページングを通知する。本実施の形態では、図３２のステップＳＴ３１０７に示すような無駄なページングを削減することができる。

ステップＳＴ３３１２において、ＨｅＮＢ３００３は、ステップＳＴ３１０３で受信したページングに、集線処理した旨が含まれているか否かを判断する。集線処理した旨が含まれていると判断した場合は、ステップＳＴ３３１３へ移行する。集線処理した旨が含まれていないと判断した場合は、ステップＳＴ３１０８へ移行する。本動作例では、ステップＳＴ３１０３で受信したページングに集線処理した旨が含まれている。したがってステップＳＴ３３１２の処理の後は、ステップＳＴ３３１３へ移行する。

ステップＳＴ３３１３において、ＨｅＮＢ３００３は、自ＨｅＮＢが集線処理能力を有するか否かを判断する。自ＨｅＮＢが集線処理能力を有すると判断した場合は、ステップＳＴ３１０８へ移行する。集線処理能力を有していないと判断した場合は、ステップＳＴ３１０８およびステップＳＴ３１０９の処理を行わない。本動作例では、ＨｅＮＢ３００３は集線処理能力を有するので、ステップＳＴ３１０８へ移行する。次にＨｅＮＢ３００３は、ステップＳＴ３１０８およびステップＳＴ３１０９の処理を行う。

実施の形態７を用いた具体的な動作例を、図３７および図３８を用いて説明する。図３７および図３８は、実施の形態７における移動体通信システムの他のシーケンスを示す図である。図３７と図３８とは、境界線Ｌ４の位置で、つながっている。図３７および図３８において、図１７、図２６、図３１〜図３６に示すステップに対応するステップについては、同一の参照符を付して、共通する説明を省略する。

本動作例では、図３０に示すロケーション図を用いて説明する。ＨｅＮＢ３００３とＨｅＮＢ３００７とが、集線処理を行う能力を有するＨｅＮＢとし、ＨｅＮＢ３００５が、集線処理を行う能力を有していないＨｅＮＢとする。移動端末３００９は、ＭＴＣＤとし、ＭＴＣＤの識別子をＭＴＣＤ＿１とする。また、ＨｅＮＢで集線処理を行う旨をコアネットワークへ登録するタイミングの具体例として、ＭＴＣＤのアタッチメッセージを集線する際について開示する。また、登録するエンティティの具体例がＭＭＥである場合について開示する。また、実施の形態３を実行した場合について開示する。

まず、ＭＴＣＤ＿１がステップＳＴ１７０３の処理を行い、ＭＴＣＤ＿ｎがステップＳＴ１７０４の処理を行う。次に、ＭＴＣＤ＿１およびＭＴＣＤ＿ｎから送信された「RRC Connection Request」を受信したＨｅＮＢ３００７は、ステップＳＴ１７０５およびステップＳＴ１７０７の処理を行う。次に、ＭＴＣＤ＿１がステップＳＴ２６０１の処理を行い、ＭＴＣＤ＿ｎがステップＳＴ２６０２の処理を行う。次に、ＭＴＣＤ＿１およびＭＴＣＤ＿ｎから送信されたアタッチメッセージを受信したＨｅＮＢ３００７は、ステップＳＴ２６０３およびステップＳＴ３３０１の処理を行う。

次に、ステップＳＴ３４０１において、ＭＭＥは、ステップＳＴ３３０１のアタッチメッセージで受信したＭＴＣＤの識別子であるＭＴＣＤ＿１の識別子およびＭＴＣＤ＿ｎの識別子と、集線処理を行う旨とを登録し、管理する。登録および管理の際は、集線処理状況をＭＴＣＤの識別子と関連付けて行う。次に、ＭＭＥがステップＳＴ２６０５の処理を行い、ＨＳＳがステップＳＴ２６０６の処理を行う。ステップＳＴ２６０７において、ＭＭＥが、ＭＴＣＤ＿１宛の着信を受信した後、ＭＭＥは、ステップＳＴ２６０８の処理を行う。

次に、ステップＳＴ３４０２において、ＭＭＥは、ＭＴＣＤ＿１の集線状況を検索する。ステップＳＴ３４０２の処理の後は、図３６と同様に、ＭＭＥは、ステップＳＴ３３０６、ステップＳＴ３３０７、ステップＳＴ３１０１〜ステップＳＴ３１０３の処理を行う。また、ＨｅＮＢ３００７は、ステップＳＴ３３０８、ステップＳＴ３３０９、ステップＳＴ３１０４およびステップＳＴ３１０５の処理を行う。またＨｅＮＢ３００５は、ステップＳＴ３３１０、ステップＳＴ３３１１、ステップＳＴ３１０６およびステップＳＴ３１０７の処理を行う。またＨｅＮＢ３００３は、ステップＳＴ３３１２、ステップＳＴ３３１３、ステップＳＴ３１０８およびステップＳＴ３１０９の処理を行う。

本動作例では、図３６に示すシーケンスと同様に、ステップＳＴ３３１１において、ＨｅＮＢ３００５は、自ＨｅＮＢが集線処理能力を有するか否かを判断する。自ＨｅＮＢが集線処理能力を有すると判断した場合は、ステップＳＴ３１０６へ移行する。自ＨｅＮＢが集線処理能力を有していないと判断した場合は、ステップＳＴ３１０６およびステップＳＴ３１０７の処理を行わない。本動作例では、ＨｅＮＢ３００５は集線処理能力を有していないので、ステップＳＴ３１０６およびステップＳＴ３１０７の処理を行わない。実施の形態３を実行した場合の無線リソースの無駄を説明する図３１および図３２では、図３２のステップＳＴ３１０７に示すように、ＨｅＮＢ３００５は、ＭＴＣＤ＿１を受信することがない、無駄なＭＴＣＤ＿１宛のページングを通知する。本実施の形態では、図３２のステップＳＴ３１０７に示すような無駄なページングを削減することができる。

実施の形態７を用いた具体的な動作例を、図３９および図４０を用いて説明する。図３９および図４０は、実施の形態７における移動体通信システムの他のシーケンスを示す図である。図３９と図４０とは、境界線Ｌ５の位置で、つながっている。図３９および図４０において、図２６、図２７および図３１〜図３６に示すステップに対応するステップについては、同一の参照符を付して、共通する説明を省略する。

本動作例では、図３０に示すロケーション図を用いて説明する。ＨｅＮＢ３００３とＨｅＮＢ３００７とが、集線処理を行う能力を有するＨｅＮＢとし、ＨｅＮＢ３００５が、集線処理を行う能力を有していないＨｅＮＢとする。移動端末３００９は、ＭＴＣＤとし、ＭＴＣＤの識別子をＭＴＣＤ＿１とする。また、ＨｅＮＢで集線処理を行う旨をコアネットワークへ登録するタイミングの具体例として、集線処理の際に「Attach procedure」を選定した場合について開示する。また、登録するエンティティの具体例がＨＳＳである場合について開示する。また、実施の形態４を実行した場合について開示する。

まず、ＭＴＣＤ＿１がステップＳＴ２７０１の処理を行い、ＭＴＣＤ＿ｎがステップＳＴ２７０２の処理を行う。次に、ＨｅＮＢ３００７が、ステップＳＴ２７０３およびステップＳＴ２７０４の処理を行う。

次に、ステップＳＴ２７０５において、ＨｅＮＢ３００７は、集線処理を行う。本動作例においては、ＭＴＣＤ＿１およびＭＴＣＤ＿ｎからのコアネットワークへのデータをまとめてＭＭＥへ通知する。また３ＧＰＰ以外によるアクセスであるステップＳＴ２７０１およびステップＳＴ２７０２の内容を解釈し、「設置」に関するアクセスであると理解する。次に「設置」に関するアクセスに即した３ＧＰＰ内のプロトコルとして「Attach procedure」を選定する。集線処理の際に「Attach procedure」を選定している。したがって、本動作例では集線処理を行う旨をコアネットワークへ登録する。

ステップＳＴ３５０１において、ＨｅＮＢ３００７は、ステップＳＴ２７０５で集線処理を行うことによって集線されたアタッチメッセージと、集線処理を行う旨とをＭＭＥへ通知する。アタッチメッセージには、集線処理の対象となったＭＴＣＤの識別子であるＭＴＣＤ＿１の識別子およびＭＴＣＤ＿ｎの識別子と、ＨｅＮＢの識別子と、ＴＡＩとが含まれる。アタッチメッセージ中に集線処理を行う旨を含ませてもよい。該通知には、実施の形態２、実施の形態２の変形例１、実施の形態２の変形例２および実施の形態２の変形例３を用いることができる。

ステップＳＴ３５０１の処理の後は、ＭＭＥは、ステップＳＴ３３０２、ステップＳＴ２６０８、ステップＳＴ３３０４、ステップＳＴ３３０６、ステップＳＴ３３０７およびステップＳＴ３１０１〜ステップＳＴ３１０３の処理を行う。またＨＳＳは、ステップＳＴ３３０３、ステップＳＴ２６０７およびステップＳＴ３３０５の処理を行う。また、ＨｅＮＢ３００７は、ステップＳＴ３３０８、ステップＳＴ３３０９、ステップＳＴ２７０７、ステップＳＴ２７０８、ステップＳＴ２７０９およびステップＳＴ２７１０の処理を行う。またＨｅＮＢ３００５は、ステップＳＴ３３１０、ステップＳＴ３３１１、ステップＳＴ３１０６およびステップＳＴ３１０７の処理を行う。またＨｅＮＢ３００３は、ステップＳＴ３３１２、ステップＳＴ３３１３、ステップＳＴ３２０１、ステップＳＴ３１０９、ステップＳＴ３２０２およびステップＳＴ３２０３の処理を行う。

ステップＳＴ３３１０において、ＨｅＮＢ３００５は、ステップＳＴ３１０２で受信したページングに集線処理した旨が含まれているか否かを判断する。集線処理した旨が含まれていると判断した場合は、ステップＳＴ３３１１へ移行する。集線処理した旨が含まれていないと判断した場合は、ステップＳＴ３１０６へ移行する。本動作例では、ステップＳＴ３１０２で受信したページングに集線処理した旨が含まれている。したがってステップＳＴ３３１０の処理の後は、ステップＳＴ３３１１へ移行する。

ステップＳＴ３３１１において、ＨｅＮＢ３００５は、自ＨｅＮＢが集線処理能力を有するか否かを判断する。自ＨｅＮＢが集線処理能力を有すると判断した場合は、ステップＳＴ３１０６へ移行する。自ＨｅＮＢが集線処理能力を有していないと判断した場合は、ステップＳＴ３１０６およびステップＳＴ３１０７の処理を行わない。本動作例では、ＨｅＮＢ３００５は集線処理能力を有していないので、ステップＳＴ３１０６およびステップＳＴ３１０７の処理を行わない。実施の形態４を実行した場合の無線リソースの無駄を説明する図３３および図３４では、図３４のステップＳＴ３１０７に示すように、ＨｅＮＢ３００５は、ＭＴＣＤ＿１を受信することがない、無駄なＭＴＣＤ＿１宛のページングを通知する。本実施の形態では、図３４のステップＳＴ３１０７に示すような無駄なページングを削減することができる。

実施の形態７を用いた具体的な動作例を、図４１および図４２を用いて説明する。図４１および図４２は、実施の形態７における移動体通信システムの他のシーケンスを示す図である。図４１と図４２とは、境界線Ｌ６の位置で、つながっている。図４１および図４２において、図２６、図２７、図３１〜図３６、図３９および図４０に示すステップに対応するステップについては、同一の参照符を付して、共通する説明を省略する。

本動作例では、前述の図３０に示すロケーション図を用いて説明する。ＨｅＮＢ３００３とＨｅＮＢ３００７とが、集線処理を行う能力を有するＨｅＮＢとし、ＨｅＮＢ３００５が、集線処理を行う能力を有していないＨｅＮＢとする。移動端末３００９は、ＭＴＣＤとし、ＭＴＣＤの識別子をＭＴＣＤ＿１とする。また、ＨｅＮＢで集線処理を行う旨をコアネットワークへ登録するタイミングの具体例として、ＭＴＣＤのアタッチメッセージを集線する際について開示する。また、登録するエンティティの具体例がＭＭＥである場合について開示する。また、実施の形態４を実行した場合について開示する。

本動作例では、図３９および図４０に示すシーケンスと同様に、ステップＳＴ３３１１において、ＨｅＮＢ３００５は、自ＨｅＮＢが集線処理能力を有するか否かを判断する。自ＨｅＮＢが集線処理能力を有すると判断した場合は、ステップＳＴ３１０６へ移行する。自ＨｅＮＢが集線処理能力を有していないと判断した場合は、ステップＳＴ３１０６およびステップＳＴ３１０７の処理を行わない。本動作例では、ＨｅＮＢ３００５は集線処理能力を有していないので、ステップＳＴ３１０６およびステップＳＴ３１０７の処理を行わない。実施の形態４を実行した場合の無線リソースの無駄を説明する図３３および図３４では、図３４のステップＳＴ３１０７に示すように、ＨｅＮＢ３００５は、ＭＴＣＤ＿１を受信することがない、無駄なＭＴＣＤ＿１宛のページングを通知する。本実施の形態では、図３４のステップＳＴ３１０７に示すような無駄なページングを削減することができる。

実施の形態７により、実施の形態３および実施の形態４の効果に加えて、以下の効果を得ることができる。ＨｅＮＢが、集線処理を行う旨を示す情報が含まれるページングメッセージを受信した場合、自ＨｅＮＢが集線処理を行う能力を有する場合にページングメッセージを送信する。これによって、集線処理を行うＭＴＣＤ宛のページングは、集線処理を行う能力を有していないＨｅＮＢからの通知を削減することができる。集線処理を行うＭＴＣＤが集線処理能力を有していないＨｅＮＢの傘下に存在することはない。したがって、無駄なＨｅＮＢからのページング送信のみを削減し、着信漏れを防ぎつつ、無線リソースを有効に活用することができ、干渉を削減することができる。

実施の形態７変形例１．
実施の形態７の変形例１で解決する課題について、以下に説明する。実施の形態７を用いた場合、以下の課題が発生する。図３６を用いて課題を説明する。実施の形態７を用いることによって、集線処理を行うＭＴＣＤ宛のページングは、集線処理を行う能力を有していないＨｅＮＢからの通知を削減することができる。一方で、図３６のステップＳＴ３１０２などにおいて、集線処理を行う能力を有していないＨｅＮＢへ通知されないページングメッセージが通知される。したがって、通信リソースの無駄が発生し、図３６のステップＳＴ３３１０およびステップＳＴ３３１１などにおいて、ＭＭＥ、あるいは集線処理を行う能力を有していないＨｅＮＢの無駄な処理の負荷が発生するという課題がある。

実施の形態７の変形例１での解決策を以下に示す。実施の形態７の解決策と異なる部分を中心に説明する。説明していない部分については、実施の形態７と同様とする。

ＨｅＮＢにおいて集線処理を行う旨をＭＴＣＤの識別子とともに、コアネットワーク側であるＭＭＥ、ＨＳＳなどへ登録する。集線処理を行うか否かの情報を、以下「集線処理状況」とも称する。集線処理を行うＭＴＣＤ宛のページングが発生した場合、ＭＭＥは、集線処理を行う能力を有するＨｅＮＢに、ページングメッセージを送信する。集線処理を行うＭＴＣＤ宛のページングが発生した場合、ＭＭＥは、集線処理を行う能力を有していないＨｅＮＢに、ページングメッセージを送信しない。

ＭＭＥが、傘下のＨｅＮＢの集線処理を行う能力を把握する具体例を、以下に開示する。前述の実施の形態１の変形例３を用いて、ＨｅＮＢがＭＴＣＤからのデータの集線処理に関する能力情報をコアネットワークであるＭＭＥ、ＳＧＳＮなどへ通知する。

実施の形態７の変形例１を用いた具体的な動作例を、図４３および図４４を用いて説明する。図４３および図４４は、実施の形態７の変形例１における移動体通信システムのシーケンスを示す図である。図４３と図４４とは、境界線Ｌ７の位置で、つながっている。図４３および図４４において、図１７、図２６、図３１、図３２、図３５および図３６に示すステップに対応するステップについては、同一の参照符を付して、共通する説明を省略する。

本動作例では、前述の図３０に示すロケーション図を用いて説明する。ＨｅＮＢ３００３とＨｅＮＢ３００７とが、集線処理を行う能力を有するＨｅＮＢとし、ＨｅＮＢ３００５が、集線処理を行う能力を有していないＨｅＮＢとする。移動端末３００９は、ＭＴＣＤとし、ＭＴＣＤの識別子をＭＴＣＤ＿１とする。また、ＨｅＮＢが集線処理に関する能力情報をコアネットワークへ通知するタイミングの具体例として、ＨｅＮＢ設置時について開示する。また、ＨｅＮＢで集線処理を行う旨をコアネットワークへ登録するタイミングの具体例として、ＭＴＣＤのアタッチメッセージを集線する際について開示する。また、登録するエンティティの具体例がＨＳＳである場合について開示する。また、実施の形態３を実行した場合について開示する。

ステップＳＴ３７０１において、ＨｅＮＢ３００７が設置される。ステップＳＴ３７０２において、ＨｅＮＢ３００７は、ＭＭＥへＨｅＮＢ３００７の集線処理に関する能力情報を通知する。

ステップＳＴ３７０３において、ＨｅＮＢ３００５が設置される。ステップＳＴ３７０４において、ＨｅＮＢ３００５は、ＭＭＥへＨｅＮＢ３００５の集線処理に関する能力情報を通知する。

ステップＳＴ３７０５において、ＨｅＮＢ３００３が設置される。ステップＳＴ３７０６において、ＨｅＮＢ３００３は、ＭＭＥへＨｅＮＢ３００３の集線処理に関する能力情報を通知する。

ステップＳＴ３７０７において、ＭＭＥは、傘下のＨｅＮＢの能力情報を登録し、管理する。登録および管理の際は、能力情報をＨｅＮＢの識別子と関連付けて行う。

ステップＳＴ３３０６において、ＭＭＥは、ステップＳＴ３３０５で受信した集線状況報告に基づいて、ＭＴＣＤ＿１が集線処理されたか否かを判断する。ＭＴＣＤ＿１が集線処理されたと判断した場合は、ステップＳＴ３７０８へ移行する。ＭＴＣＤ＿１が集線処理されていないと判断した場合は、ステップＳＴ３１０１へ移行する。本動作例では、ＭＴＣＤ＿１は集線処理されており、ステップＳＴ３３０５で集線処理を行う旨が報告されている。したがって、ＭＴＣＤ＿１が集線処理されたと判断され、ステップＳＴ３７０８へ移行する。

ステップＳＴ３７０８において、ＭＭＥは、傘下のＨｅＮＢのうち集線処理を行う能力を有するＨｅＮＢを選定する。選定には、ステップＳＴ３７０７で登録した情報を用いるとよい。本動作例では、ＨｅＮＢ３００３とＨｅＮＢ３００７とが集線処理を行う能力を有するＨｅＮＢであると選定される。一方、ＨｅＮＢ３００５は、集線処理を行う能力を有するＨｅＮＢであると選定されない。ＭＭＥは、集線処理を行う能力を有するＨｅＮＢにページングメッセージを送信し、集線処理を行う能力を有していないＨｅＮＢにページングメッセージを送信しない。

したがって、ステップＳＴ３１０１において、ＭＭＥは、ＨｅＮＢ３００７へＭＴＣＤ＿１宛のページングを通知する。該ページングには、ＭＴＣＤ＿１のトラッキングエリアリストおよびＭＴＣＤ＿１の識別子が含まれる。ステップＳＴ３１０３において、ＭＭＥは、ＨｅＮＢ３００３へＭＴＣＤ＿１宛のページングを通知する。該ページングには、ＭＴＣＤ＿１のトラッキングエリアリストおよびＭＴＣＤ＿１の識別子が含まれる。ＭＭＥは、ＨｅＮＢ３００５へＭＴＣＤ＿１宛のページングを通知しない。図３６では、ステップＳＴ３１０２に示すように、通知されないページングメッセージが、ＭＭＥからＨｅＮＢ３００５へ通知される。本実施の形態では、図３６のステップＳＴ３１０２に示すような無駄な通信を削減することができる。

一方、ステップＳＴ３３０６において、ＭＭＥが着信のあった移動端末を集線処理されていないと判断した場合、ステップＳＴ３１０１において、ＭＭＥは、ＨｅＮＢ３００７へＭＴＣＤ＿１宛のページングを通知する。該ページングには、ＭＴＣＤ＿１のトラッキングエリアリストおよびＭＴＣＤ＿１の識別子が含まれる。ステップＳＴ３１０２において、ＭＭＥは、ＨｅＮＢ３００５へＭＴＣＤ＿１宛のページングを通知する。該ページングには、ＭＴＣＤ＿１のトラッキングエリアリストおよびＭＴＣＤ＿１の識別子が含まれる。ステップＳＴ３１０３において、ＭＭＥは、ＨｅＮＢ３００３へＭＴＣＤ＿１宛のページングを通知する。該ページングには、ＭＴＣＤ＿１のトラッキングエリアリストおよびＭＴＣＤ＿１の識別子が含まれる。

本変形例では、実施の形態３と組み合わせた例について主に記載したが、実施の形態４とも組み合わせて用いることができる。

実施の形態７の変形例１により、実施の形態７の効果に加えて、以下の効果を得ることができる。ＭＭＥが、集線処理を行うＭＴＣＤ宛のページングメッセージを受信した場合、集線処理を行う能力を有するＨｅＮＢにページングメッセージを送信する。これによって、集線処理を行うＭＴＣＤ宛のページングの、集線処理を行う能力を有していないＨｅＮＢへの通知を削減することができる。集線処理を行うＭＴＣＤが集線処理能力を有していないＨｅＮＢの傘下に存在することはない。したがって、無駄なＨｅＮＢへのページング通知のみを削減し、着信漏れを防ぎつつ、通信リソースを有効に活用することができ、ＭＭＥあるいは集線処理を行う能力を有していないＨｅＮＢの処理の負荷を軽減することができる。

実施の形態７変形例２．
実施の形態７の変形例２で解決する課題について、以下に説明する。実施の形態７を用いた場合、以下の課題が発生する。図３５および図３６を用いて課題を説明する。実施の形態７を用いることによって、集線処理を行うＭＴＣＤ宛のページングは、集線処理を行う能力を有していないＨｅＮＢからの通知を削減することができる。一方で、ＭＴＣＤの集線処理を行っていないＨｅＮＢからＭＴＣＤ宛のページングは、図３６のステップＳＴ３１０３およびステップＳＴ３１０９に示すように、以前通知される。無意味なページング送信は、無線リソースを有効に活用することができず、干渉が発生するという課題がある。

実施の形態７の変形例２での解決策を以下に示す。ＨｅＮＢは、ＨｅＮＢで集線処理を行ったＨｅＮＢの識別子をＭＴＣＤの識別子とともに、コアネットワーク側であるＭＭＥ、ＨＳＳなどへ登録する。

実施の形態７と同様に、ＭＴＣＤ宛のページングが発生した場合は、ページングメッセージ中に集線処理を行ったＨｅＮＢの識別子を含ませる。ＨｅＮＢが、集線処理を行ったＨｅＮＢの識別子が含まれるページングメッセージを受信した場合、ＨｅＮＢの識別子が自ＨｅＮＢのものであった場合に、ページングメッセージを送信する。

ＨｅＮＢが集線処理を行ったＨｅＮＢの識別子をコアネットワークへ登録するタイミングの具体例については、実施の形態７の「ＨｅＮＢで集線処理を行う旨をコアネットワークへ登録するタイミング」の具体例と同様であるので、説明を省略する。

コアネットワークが、集線処理を行ったＨｅＮＢの識別子の登録を削除するタイミングの具体例としては、ＭＴＣＤからの「Detach procedure」を受信したときが挙げられる。

登録方法の具体例を以下に開示する。ＭＴＣＤの識別子と関連付けて集線処理を行ったＨｅＮＢの識別子を記憶する。

登録するエンティティの具体例は、実施の形態７と同様であるので、説明を省略する。ページングが発生した場合に、ページングメッセージ中に集線処理を行ったＨｅＮＢの識別子を含ませる方法の具体例は、実施の形態７のページングが発生した場合にページングメッセージ中に集線処理を行った旨を示す情報を含ませる方法の具体例と同様であるので、説明を省略する。

あるいは、実施の形態７の変形例１と同様に、集線処理を行うＭＴＣＤ宛のページングが発生した場合、ＭＭＥは、集線処理を行ったＨｅＮＢにページングメッセージを送信する。集線処理を行うＭＴＣＤ宛のページングが発生した場合、ＭＭＥは、集線処理を行ったＨｅＮＢ以外のＨｅＮＢに、ページングメッセージを送信しない。

実施の形態７の変形例２により、実施の形態７および実施の形態７の変形例１の効果に加えて、以下の効果を得ることができる。

集線処理を行ったＨｅＮＢ以外のＨｅＮＢからのＭＴＣＤ宛のページングを削減することができる。あるいは、集線処理を行ったＨｅＮＢ以外へのページング通知を削減することができる。集線処理を行うＭＴＣＤが、集線処理を行ったＨｅＮＢ以外のＨｅＮＢの傘下に存在することはない。したがって、無駄なＨｅＮＢからのページング、あるいは無駄なＨｅＮＢへのページング通知のみを削減し、着信漏れを防ぎつつ、無線リソースを有効に活用することができ、通信リソースを有効に活用することができる。また、ＭＭＥあるいは集線処理を行う能力を有していないＨｅＮＢの処理の負荷を軽減することができる。

本発明で開示した方法は、ｅＮＢ／ＮＢに限らず、ＨｅＮＢ、ＨＮＢ、ピコｅＮＢ（ＬＴＥピコセル（EUTRAN pico cell））、ピコＮＢ（ＷＣＤＭＡピコセル（UTRAN pico cell）、ホットゾーンセル用のノードなどの、いわゆるローカルノードにも適用できる。ＭＴＣサービスをサポートするローカルノードに、本発明で開示した方法を行うことで、コアネットワークにおける混雑を回避することが可能となる。

以上の各実施の形態では、ＬＴＥシステム（Ｅ−ＵＴＲＡＮ）を中心に説明したが、本発明の通信システムは、Ｗ−ＣＤＭＡシステム（ＵＴＲＡＮ、ＵＭＴＳ）およびＬＴＥアドヴァンスド（LTE-Advanced）にも適用することが可能である。

この発明は詳細に説明されたが、上記した説明は、すべての局面において、例示であって、この発明がそれに限定されるものではない。例示されていない無数の変形例が、この発明の範囲から外れることなく想定され得るものと解される。

１３０１〜１３０４ＭＴＣＤ、１３０５ＮＢ／ｅＮＢ、１３０６ＳＧＳＮ／ＭＭＥ、１３０７ＨＬＲ／ＨＳＳ、１３０８ＭＴＣサーバ、１３０９ＭＴＣユーザ、１３１０ＡＰＩ、１３１１〜１３１４Ｕｕインタフェース、１３１５ＩｕＰＳ／Ｓ１インタフェース、１３１６Ｇｒ／Ｓ６ａインタフェース、１３１７通信オペレータ領域、３００１，３０１０ｅＮＢ、３００３，３００５，３００７，３０１２，３０１４ＨｅＮＢ、３００２，３００４，３００６，３００８，３０１１，３０１３，３０１５カバレッジ、３００９移動端末、３０１６トラッキングエリア＃１（ＴＡ＃１）、３０１７トラッキングエリア＃２（ＴＡ＃２）。

Claims

端末がＭＴＣ装置であることを示すＭＴＣ情報を前記端末から受信する基地局およびその基地局を制御する基地局制御装置を有する通信システムであって、
前記基地局は、前記ＭＴＣ装置を識別するＭＴＣ識別情報を前記基地局制御装置に通知し、
前記基地局制御装置は、前記ＭＴＣ識別情報と共にページングメッセージを前記基地局に通知することを特徴とする通信システム。
端末がＭＴＣ装置であることを示すＭＴＣ情報を前記端末から受信する基地局であって、
前記ＭＴＣ装置を識別するＭＴＣ識別情報を基地局制御装置に通知し、
前記ＭＴＣ識別情報と共にページングメッセージを前記基地局制御装置から受信することを特徴とする基地局。
端末がＭＴＣ装置であることを示すＭＴＣ情報を前記端末から受信する基地局を制御する基地局制御装置であって、
前記ＭＴＣ装置を識別するＭＴＣ識別情報を前記基地局から受信し、
前記ＭＴＣ識別情報と共にページングメッセージを前記基地局に通知することを特徴とする基地局制御装置。