以下、図面を参照しながら、本発明の第1〜第3の実施の形態について説明する。
<システム構成>
まず、図1を参照しながら、本発明の第1〜第3の実施の形態に共通するシステム構成について説明する。図1は、本発明の第1〜第3の実施の形態に共通するシステム構成の一例を示す図である。
上述のように、図1に図示されている通信システムは、少なくともMTCデバイス100、UE105、MTCデバイス100やUE105と無線接続する基地局(eNB又はNB)110、E−UTRAN115上のMTCデバイス100やUE105の移動管理を担当するMME120、MTCデバイス100やUE105のE−UTRAN115に対するユーザデータ配信制御を行うSGW130、MTCデバイス100やUE105に対するアドレス割り当てやPDN155とSGW130間のユーザデータ転送並びに経路制御を行うPGW140、MTCデバイス100やUE105のサブスクリプションデータ並びに通信コンテキストなどを管理保持しているHSS125、MTCデバイス100による通信の制御や状態管理、アプリケーションサービスの提供などを行うサーバであるMTCサーバ150、MTCデバイス100やMTCサーバ150に対してアプリケーションの管理・制御やアプリケーションデータの管理を実施するMTCユーザ160を有している。なお、MTCユーザ160は、また、HSS125の代わりに、AAA(Authentication, authorization and Accounting)サーバを用いてもよい。また、AAAサーバとHSS125は、物理的又は論理的に同一の装置に実装されるものであってもよい。
なお、図1において、MTCサーバ150はPDN155内に位置しているが、通信システムのオペレータドメイン内に位置していてもよく、例えば、PGW140がMTCサーバ150の機能を担ってもよい。
ここで、MTCデバイス100は少なくとも1つ以上の通信インタフェースを持ち、通信システム(例えば、E−UTRAN115)に接続することが可能である。なお、MTCデバイス100は、図示されている通信システム以外のネットワーク(例えば、UTRAN、WLAN(Wireless LAN)ネットワークやWiMAXネットワーク)に、同時に、あるいは排他的に接続するものであってもよい。MTCデバイス100は、接続した通信システムを通じて、MTCサーバ150と通信可能であり、MTCサーバ150はMTCユーザ160と通信可能である。
また、MTCデバイス100は、通信システム内で従来のUE105と共存しながら通信を行う。なお、図1では、MTCデバイス100とUE105とがそれぞれ異なるeNB110に接続しているが、MTCデバイス用のeNB110が区別されているわけではなく、どのeNB110と接続してもよいものとする。しかし、今後、MTCデバイス100が、MTCデバイス100用にカスタマイズされたeNB110のみに接続が許されるという環境に変化した場合、MTCデバイス100はMTCデバイス100用のeNB110に接続されてもよい。
また、各MTCデバイス100は、UE105と同様にMTCデバイス100を識別するためのID(以降、デバイスIDと呼ぶ)が割り当てられていることとする。同様に、MTCデバイス100がMTCグループを形成する場合、MTCグループを識別するためのID(以降、グループIDと呼ぶ)が割り当てられていることとする。同様に、MTCデバイス100は、デバイスの種類(例えば、煙センサ)を識別するためのID(以降、デバイス種IDと呼ぶ)が割り当てられていることとする。なお、MTCデバイス100の種類は、そのMTCデバイス100が搭載又は接続されている装置の種類によって決まる。また、MTCデバイス100の種類は、MTCサーバ、MTCユーザ、又は、通信システムのオペレータによって設定されてもよい。
なお、MTCデバイス100、通信システムのエンティティ(例えば、MME120、PGW140など)、MTCサーバ150が、デバイス種IDを用いずに、MTCデバイス100の種類を識別することができるのであれば(例えば、デバイスIDのうちデバイス種別を示す一部のビット列(例えば、上位あるいは下位数ビット)からMTCデバイス100の種類を導出)、必ずしも本デバイス種IDを用いる必要はない。また、デバイスIDも同様に、例えばIMEI(International Mobile Equipment Identity)やIMSI(International Mobile Subscriber Identity)を用いることで、MTCデバイス100を一意に識別できるのであれば、新たに割り当てる必要はない。また、グループIDも同様に、例えばデータを転送するPDNコネクション、EPSベアラを共有する場合(例えば、MTCグループの中で代表するMTCデバイス100が、通信システムとPDNコネクション、EPSベアラを確立していて、代表するMTCデバイス100が同MTCグループに属する他のMTCデバイス100が取得したデータを転送する場合)には、PDNコネクションIDやEPSベアラID、APN(Access Point Name)を用いることでMTCグループを識別できるのであれば、新たに割り当てる必要はない。
また、各MTCデバイス100には、例えばMTCユーザ160などによって事前にMTCの機能(MTC Features)が組み込まれていてもよく(例えば、SIMカードに書き込む、MTCデバイス100の記憶メモリに書き込む)、ネットワーク装置(例えば、MME120やMTCサーバ150など)やMTCデバイス100自身が、所望のMTCの機能を有効化/無効化するものであってもよい。上記のようなMTCデバイス100のデバイスID、グループID、デバイス種ID、搭載しているMTCの機能、MTCの機能の有効化/無効化など、MTCに関連する様々な情報は、HSS125が保持するサブスクリプションデータや通信コンテキストなどに登録されているものとする。また、E−UTRAN115におけるMTCデバイス100のモビリティ制御は、UE105に対する制御と同様にMME120が実施する。
また、MTCサーバ150は、通信システムを運用するオペレータが管理する場合と、オペレータ以外の運用者が管理する場合がある。いずれの場合も、オペレータが管理するPGW140とのインタフェースを有し、通信システムに接続するMTCデバイスから/へのユーザデータ転送、通信システムにおけるMTCデバイスの制御に関するサービスを享受する。なお、オペレータがMTCサーバを管理する場合、MTCサーバとPGW140を同一装置内に実施するものであってもよく、これによって外部インタフェースの実装を装置内に隠蔽して装置コストの削減を図ることができる。
また、MTCユーザ160は、各MTCデバイス100が取得したデータを管理・利用する主体であり、事業運営者や企業、またデータ管理を実施する制御主体(PC、サーバなど)に相当する。例えば、MTCデバイス100が自動販売機に組み込まれていることを想定すると、MTCユーザ160は自動販売機の売り上げ集計やメンテナンスを実施する会社などである。また、MTCデバイス100を煙センサに組み込まれていることを想定すると、MTCユーザ160は消防署や警備会社、保険会社、又は住宅の火災による被害の軽減を担当する会社などであると考えられる。なお、MTCユーザ160は、上記のようにMTCの管理を行うユーザが使用するMTCユーザ端末と考えてもよく、あるいは、MTCの管理を行うユーザが操作するMTCサーバ150と同一の装置であると考えてもよい。
また、一般的に、MTCデバイス100とMTCサーバ150との間で交換されるデータは、アプリケーションレベルのデータであるため、MTCデバイス100とPGW140との間のデータ転送は、Uプレーン(User plane:ユーザプレーン)の利用が想定される。しかし、アプリケーションやサービスの内容や性質(例えば、生存者確認など緊急性を伴うデータ転送向けサービス)、通信システムのネットワークオペレータの要求(例えば、ネットワーク装置(例えば、MME120)による制御が必要となる場合(例えば、MTCデバイス100の位置情報の変更や、MTCグループ/同一デバイス種などの制御))、MTCデバイス100/MTCサーバ150の要求(例えば、迅速に、又は、高い信頼度でデータを送信/取得したい場合)によっては、即時性や信頼性を有するCプレーン(Control plane:制御プレーン)を利用する(シグナリングメッセージにアプリケーションデータを重畳、あるいはピギーバックする)ことによる効果が大きい場合がある。
また、イベント検知時に優先度の高いイベント通知メッセージを送信するMTCデバイス100は、取得したデータ(センシングデータとも呼ぶ)からイベントを検出すると、優先度の高いイベント通知メッセージをMTCサーバに送信し、同時に、あるいは続けて、取得したデータ(センシングデータ)をMTCサーバに送信するものとする。
また、上記の構成を有する通信システムにおいて、MTCデバイス100は、通信システム(E−UTRAN115)に接続されており、通信システムを通じてMTCサーバ150と通信可能であるとする。
<第1の実施の形態>
以下、本発明の第1の実施の形態におけるシステム動作の一例について、図3を用いて詳しく説明する。図3は、本発明の第1の実施の形態におけるシステム動作の一例(複数のMTCデバイス100から送信される同一イベント、又は、そのイベントを引き起こした出来事によって引き起こされたイベントによる優先度の高いイベント通知メッセージの送信抑制方法)を説明するためのシーケンス図である。なお、図3には、図1に図示されているシステム構成における処理シーケンスの一例が図示されている。
ここで、本実施の形態の説明を容易化するために、MTCデバイス100は以下のような特徴を持っていることを前提とする。
MTCデバイス100は、非特許文献1で定義されている“Time Controlled”と、“PAM”と、“Group based”と、“Low mobility”とを有しているとする。MTCデバイス100は、他の複数のMTCデバイス100と共に1つのMTCグループとして管理されていることとする。また、MTCグループ内のMTCデバイス100は、“煙センサ”、“炎センサ”、“人感センサ”で構成されているものとする(実際には、各センサにMTCデバイス100である通信モジュールが実装される)。“煙センサ”は、一定値以上(あるいは所定時間連続して一定値以上)の煙濃度を検出した場合、すなわちイベント(煙)を検知した際に、火災が発生している可能性が高いと判断し、高い優先度(高優先度モードとも呼ぶ)でメッセージを送信する。“炎センサ”はイベント(炎)を検知した際、火災が発生している可能性が高いと判断し、“煙センサ”と同様に、高い優先度(高優先度モード)でメッセージを送信する。一方、“人感センサ”はイベント(人の有無)を検知した際、一般的な優先度(ノーマルモードとも呼ぶ)でセンシングデータを送信する。ここで、高優先度モードとは、イベントを検知した際に優先度の高いイベント通知メッセージを送信する状態である。またノーマルモードとは、イベントを検知した際に優先度の高いイベント通知メッセージは送信せずに、取得したデータを一般的な優先度で送信する状態、又は、一般的な優先度でイベント通知メッセージを送信し、取得したデータも同様に一般的な優先度で送信する状態である。なお、メッセージの優先度は、EPSベアラのQCIや、EPSベアラの帯域幅(例えば、MBR(Maximum Bit Rate)やAMBR(Aggregate Maximum Bit Rate))、MTCデバイス100が持つIMSIやIMEIの値、PCC(Policy and Charging Control)、MTC Feature/MTCデバイス100の種類/MTCサービス毎に定義される優先度や値などで定義されてもよい。
図3では、MTCグループ内のMTCデバイス100を識別するために、MTCデバイスA100AとMTCデバイスB100Bとが図示されている。なお、ここでは、MTCデバイスA100Aを、最初にイベントを検知するMTCデバイス(“煙センサ”)と仮定し、MTCデバイス100Bを、MTCデバイスA100Aと同一のMTCグループに属する他のMTCデバイス(“煙センサ”、“炎センサ”、“人感センサ”)と仮定する。なお、図3では2つのMTCデバイス100(MTCデバイスA100A、MTCデバイスB100B)しか存在していないが、3つ以上のMTCデバイス100が同じMTCグループ内に存在する場合でも、同様に動作する。
以下、図3に図示されているシーケンスについて説明する。MTCデバイスA100A(煙センサ)は、MTCサーバ150と通信を行うためのPDNコネクションを、従来手法(例えば、非特許文献3で示されるAttach procedure)に基づいてPGW140と確立する(図3のステップS201:PDNコネクション確立済み)。また、MTCデバイスB100Bも、従来手法(例えば、非特許文献3で示されるAttach procedure)に基づいてPGW140とPDNコネクションを確立する(図3のステップS206:PDNコネクション確立済み)。
ここで、MTCデバイスA100Aが、例えば、火災発生などにより、イベント(煙)を検知したとする(図3のステップS202:イベント検知)。イベントを検知したMTCデバイスA100Aは、イベントを検知したことをMTCサーバ150に通知するためのメッセージ(ここでは、イベント通知メッセージ@デバイスAと表記)を送信する。なお、MTCデバイスA100A(煙センサ)が煙を検知した場合は、火災が発生している可能性が高いと予測され、MTCデバイスA100Aは優先度の高いメッセージ(例えば、PAM)を用いて、MTCサーバ150に通知する(図3のステップS203:イベント通知メッセージ@デバイスA)。また、これ以降、優先度の高いメッセージとは、PAMや、他のNASメッセージより優先度が高いNAS/ASメッセージなどを指す。また、この優先度の高いメッセージは、(Priority) Event Notification、Alarm Signaling、Event Alert、Emergency signaling、Event Detection Messageなどと呼ばれてもよい。
なお、このMTCデバイスA100Aから送信される優先度の高いメッセージであるイベント通知メッセージ@デバイスAは、例えば、非特許文献1が定義するPAMや、非特許文献3で記述されているTAU(Tracking Area Update) Requestなどの位置登録メッセージにピギーバック(重畳)した場合、又は、PDNコネクションやEPSベアラが確立されていない状態でイベントを検知した場合は、PDNコネクションやEPSベアラを確立する際に用いられる、例えば、Attach RequestやService Request、非特許文献4にて定義されるDS-MIPv6 bootstrapping based on IKEv2で使用されるIKE_SA_INITメッセージやIKE_AUTH Requestメッセージを用いてもよい。また、Bearer Modification Requestメッセージを用いるものであってもよい。これによって、新規メッセージを導入することなく、少ない修正でMTCデバイス100からのイベント通知を実施することができる。
通信システムのエンティティ(例えば、MME120)は、MTCグループに属しているMTCデバイスA100Aから、イベントを検知したことを知らせる優先度の高いイベント通知メッセージを受信すると、SGW130/PGW140を通じて、MTCサーバ150にイベント通知メッセージ@デバイスAを転送する。また、通信システムのエンティティ(例えば、MME120)は、後続する優先度の高いイベント通知メッセージ(同一イベント(例えば、煙の発生)、若しくは、そのイベント(例えば、煙発生)を引き起こした出来事(例えば、火災発生)によって引き起こされたイベント(例えば、炎の発生)によるイベント通知メッセージ(例えば、PAM))の送信を抑制するためのメッセージ(ここでは、逆イベント通知メッセージと表記する。また、逆PAM、混雑回避メッセージ、Time Tolerant Indication、congestion indication、congestion prior indication、PAM reduction indicationなどと呼ばれてもよい)を、同グループの全てのMTCデバイス100にブロードキャストする(図3のステップS204:逆イベント通知メッセージ)。なお、通信システムのEntity(例えば、MME120)は、この逆通知メッセージに同種の優先度の高い通知メッセージの送信停止を示すパラメータを格納してもよい。
また、この逆イベント通知メッセージは、逆イベント通知メッセージの送信元(例えば、MME120)の判断(例えば、通信システムのオペレータによる事前設定)によって、他のメッセージより高い優先度、若しくは一般的な優先度で送信してもよい。他のメッセージより高い優先度で逆イベント通知メッセージが送信される場合は、メッセージの送信元が過負荷状態であり、一般的な優先度のメッセージの処理が放棄される場合でも、優先度の高い逆イベント通知メッセージは送信することができる。また、優先度の高い逆イベント通知メッセージではなく、一般的な優先度で逆イベント通知メッセージを送るものであってもよい。この場合は、特にメッセージの優先度を設定する必要がなくなる。
また、MME120は、一定期間内に所定数のイベント通知メッセージを受信した、あるいは単に一定数のイベント通知メッセージを受信した場合に、逆イベント通知メッセージを送信するものであってもよい。これにより、同一のイベント通知メッセージが今後も増加するであろうことを予見した上で、それらの発生を抑えるための逆イベント通知メッセージを送信することにより、単発のイベント通知メッセージから判断する場合に比べて、抑止メッセージ(逆イベント通知メッセージ)を効果的に発行することができ、通信リソースや帯域の有効利用を図ることができる(単発のイベント通知メッセージにより判断する場合、イベント通知メッセージを受信するたびに逆イベント通知メッセージを送信することになり、通信リソースや帯域を浪費することになる)。
このとき、MME120は、MTCデバイスA100AがMTCグループに属しているか、また、MTCグループに属しているのであれば、どのMTCグループに属しているかを、MTCデバイスA100Aに対応するサブスクリプションデータをHSS125から取得してグループIDが登録されているかどうかで判断してもよい。若しくは、MTCデバイスA100Aがメッセージに格納したグループIDから、MTCデバイスA100Aがグループに属しているかどうか(あるいは、どのグループに属しているか)を判断してもよい。また、MME120が既にサブスクリプションデータを保持、又は、HSS125からサブスクリプションデータを取得する以外の方法(例えば、外部サーバへの問合せなど)により、MTCデバイスA100AがMTCグループに属しているかどうかを確認してもよい。
また、ここでは逆イベント通知メッセージを送信する対象を、イベントを検知したMTCデバイスA100Aが属しているMTCグループ配下の全てのMTCデバイス(MTCデバイスA100A及びMTCデバイスB100B)としているが、“Group based”Featureが適用されないケースにおいては、例えば、MTCデバイスA100Aが接続しているeNB110やMME120(あるいは特定のTracking Area)配下の全てのMTCデバイス100を逆イベント通知メッセージの送信対象としてもよい。この場合は、特定のエリアに位置するMTCデバイス100からの同じイベントによる優先度の高いイベント通知メッセージも回避することができる。また、MTCグループという概念を考慮せずに、優先度の高いイベント通知メッセージを回避できることにより、グループIDなどを用いなくてもよいという利点がある。ここでは、グループIDの代わりに、eNB110のID、若しくは、eNB110のアドレス(並びにデバイスのベアラに対応するS1-U TEID)を使用してもよい。また、MME120があらかじめ送信相手を確認できているのであれば、ブロードキャストではなく、マルチキャストやユニキャストで逆イベント通知メッセージを送信してもよい。これにより、制御範囲(通知範囲)を限定することにより、システム全体へのインパクトを低減させることができる。なお、この逆イベント通知メッセージは、上記MME120以外の他の通信システムにおけるエンティティ(例えば、eNB110、PGW140など)や、MTCサーバ150が送信してもよい。
逆イベント通知メッセージは、上述のように、後続する同種の優先度の高いイベント通知メッセージ(同一イベント、若しくは、そのイベントを引き起こした出来事によって引き起こされたイベントによるイベント通知メッセージ(例えば、PAM))を抑制するためのメッセージである。具体的には、逆イベント通知メッセージは、MTCデバイス100に対してノーマルモードの動作を要請するメッセージであり、逆イベント通知メッセージを受信したMTCデバイス100は、高優先度モードで動作している場合はノーマルモードへモード遷移し、ノーマルモードで動作している場合は、そのままノーマルモードを維持する。
また、優先度の高いイベント通知メッセージ(例えば、PAMなど)を回避する以外での逆イベント通知メッセージの使い方がある。例えば、通信システムのエンティティとMTCデバイス100が、複数の優先度レベルを認識することができ、MTCデバイス100が優先度の異なる複数のセンシングデータを送信したい場合、逆イベント通知メッセージを受信したMTCデバイス100は、例えば、逆イベント通知メッセージに格納されているネットワーク側が示す許容優先度レベルや、MTCデバイス100にあらかじめ組み込まれているコンテキスト(例えば、混雑度レベル3のときは優先度レベル3以上のメッセージのみ送信許容)やアプリケーションデータを用いて、送信可能なセンシングデータを選択/決定してもよい。このとき、例えば逆イベント通知メッセージを受信することで、MTCデバイス100は送信するセンシングデータの優先度の判別を行わないモード(例えば、ノーマルモード)から、優先度を考慮して送信するセンシングデータを選択/決定できるモード(例えば、高優先度モード)に切り替えてもよい。
また、少なくともMTCデバイス100が複数の優先度レベルを認識することができる場合、ネットワーク側の装置(例えば、MTCサーバ150やMME120)によって送信された優先度レベルの変更を示しているメッセージなどによって、MTCデバイス100は例えば、送信するメッセージの優先度レベルを変更するなどの処理をしてもよい。これにより、ネットワークが混雑していてパケットロスが発生しているような状況において、MTCデバイス100自身が送信するメッセージの優先度レベルを考慮し、送信するメッセージを選択することで、更なる混雑状態を作ることを回避できる。
逆イベント通知メッセージを受信したMTCデバイスA100Aは、逆イベント通知メッセージに従って、図7のように高優先度モードからノーマルモードにモード遷移を行う(ステップS205:モード切替)。そして、その後は、MTCデバイスA100Aは、ノーマルモードでセンシングデータの送信を行う(図3のステップS210:取得データ送信)。なお、図3のステップS210の取得データ送信は、ステップS205のモード切替後の任意のタイミングに行われる。また、ここでは、最初にイベント通知メッセージを送信したMTCデバイスA100Aが、逆イベント通知メッセージの受信によって、高優先度モードからノーマルモードへモード遷移を行っているが、高優先度モードによるイベント通知メッセージの送信を行った直後に自らノーマルモードへモード遷移してもよく、あるいは、イベント通知メッセージを送信したMTCデバイスA100Aに関しては、そのまま高優先度モードによる通知を継続して行えるようにしてもよい。
また、逆イベント通知メッセージを受信したMTCデバイスB100Bは、自らイベントを検知した際に高い優先度のイベント通知メッセージ(例えば、PAMなど)を用いてMTCサーバ150にイベントを検知したことを通知するMTCデバイス(例えば、他の煙センサや炎センサなど)であっても、逆イベント通知メッセージの受信に応じて図7のように高優先度モードからノーマルモードにモード遷移する(図3のステップS207:モード切替)。そして、その後、イベントを検知したとしても(図3のステップS208:イベント検知)、高い優先度のイベント通知メッセージ(例えば、PAMなど)の送信を行わず(図3のステップS207:モード切替)、ノーマルモードでセンシングデータの送信を行う(図3のステップS209:取得データ送信)。なお、MTCデバイスB100Bが、通常時からノーマルモードでセンシングデータをMTCサーバ150に送信している人感センサのようなMTCデバイスの場合には、送信モードをノーマルモードのままに維持する。また、ステップS207の高優先度モードからノーマルモードにモード遷移後にイベントを検知した際、高優先度ではなく一般的な優先度でイベント通知メッセージを通知し、その後にセンシングデータを送信してもよい。
なお、上述のように、イベントを検知した際に高い優先度のイベント通知メッセージを用いてイベントを検知したことをMTCサーバ150に通知していたMTCデバイス100(例えば、煙センサや炎センサ)は、逆イベント通知メッセージの受信によってノーマルモードへモード遷移するが、例えば、一定時間後(例えば、逆イベント通知メッセージでライフタイム値を通知など)、又は、MME120やMTCサーバ150から送信されるメッセージ(例えば、NASメッセージなど)を受信することで、ノーマルモードから高優先度モードに戻すようにしてもよい。これにより、1つのイベントが終了した後は、従来と変わらない動作に戻すことができる(図3には不図示)。
<第2の実施の形態>
第1の実施の形態の解決手法によれば、本発明が目的としている冗長なイベント通知メッセージの送信を抑制することは実現できているが、優先度の高い必要なイベント通知メッセージの送信さえも抑制してしまう場合がある。例えば、煙センサが煙の発生を検出した場合、逆イベント通知メッセージによってすべてのMTCデバイス100(例えば、炎センサなど)がノーマルモードへ遷移してしまう。その結果、煙の発生後、さらに炎センサが炎を検知した場合であっても、炎センサは、高い優先度のイベント通知メッセージ(例えば、PAMなど)を送信することはできない。
また、例えば、上記した複数のマンション群のセキュリティを監視している環境において、通常(災害が発生していないとき)人感センサは緊急性が要求されていないため、検知したイベント/取得したデータをノーマルモードでMTCサーバ150に定期的あるいは所定のタイミングで送信する。しかしながら、煙センサが煙を検知した環境においては、火災が発生している可能性が高いため、人の有無に関する情報は重要度が高くなる。そのため、人感センサが検知した人の有無に関する情報は、一般的な優先度(ノーマルモード)ではなく、高い優先度でイベント通知メッセージ(例えば、PAMなど)を用いて通知しないといけない。このように、通常はノーマルモードで人の有無に関する情報を送信していたMTCデバイス100(人感センサ)が、同じMTCグループに属しているMTCデバイス100、若しくは周辺のMTCデバイス100が検知したイベントにより、高い優先度のイベント通知メッセージ(例えば、PAMなど)でイベントの検知(人の有無に関する情報)を通知できるようにしたいという要望がある。
また、煙センサが煙を検知し、火災が発生している可能性が高い環境では、人は一斉に走って逃げることが想定される。このとき、人感センサが、例えば一定の人の歩行速度と密度を超えたとき、優先度の高いイベント通知メッセージを通知するように設定されている場合も考えられる。また、通信システムのオペレータ、MTCサーバ150やMTCユーザ160などの要求によって、MTCデバイス100間で通信が可能である環境において、周辺のMTCデバイス100から一定の値以上のメッセージを受信した場合(例えば、アドホックネットワークのような環境において、一定時間内に一定値以上のパケットを転送した場合など)、優先度の高いイベント通知メッセージを通知するように設定されている場合も考えられる。
なお、MTCデバイス100が、イベントを検知した際に、イベント通知メッセージのみを通知する、又は、取得したデータのみ送信する、若しくは、イベント通知メッセージと取得したデータを送信するメッセージの両方のメッセージを送信するかは、例えばMTCデバイス100自身、通信システムのオペレータ、MTCサーバ150やMTCユーザ160などによって決まるものとする。
第1の実施の形態における解決法(通信システムのエンティティ、若しくは、MTCサーバ150が、イベントを検知したMTCデバイス100から送信される優先度の高いイベント通知メッセージ受信後、対象となるMTCグループに属する複数のMTCデバイス100が送信する可能性のある優先度の高いイベント通知メッセージを抑制することを目的としたメッセージを送信する方法)では、全てのデバイスに一律に送信停止を指示していたため、上述のようなケースにおいて、必要なイベント通知メッセージ(例えば、煙センサがPAMを送信した後の、炎センサ又は人感センサからのPAMなど)を受信することができなくなってしまう。したがって、第1の実施の形態の改良系を第2の実施の形態で示す。
以下、本発明の第2の実施の形態におけるシステム動作の一例について、図4を用いて詳しく説明する。図4は、本発明の第2の実施の形態におけるシステム動作の一例(複数のMTCデバイス100から送信される同一イベント、又は、そのイベントを引き起こした出来事によって引き起こされたイベントによる優先度の高いイベント通知メッセージの送信抑制方法)を説明するためのシーケンス図である。なお、図4には、図1に図示したシステム構成における処理シーケンスの一例を図示する。
ここで、本実施の形態の説明を容易化するために、MTCデバイス100は以下のような特徴を持っていることを前提とする。
MTCデバイス100は、非特許文献1で定義されている“Time Controlled”と、“PAM”と、“Group based”と、“Low mobility”とを有しているとする。MTCデバイス100は、他の複数のMTCデバイス100と共に1つのMTCグループとして管理されていることとする。また、MTCグループ内のMTCデバイス100は、“煙センサ”、“炎センサ”、“人感センサ”で構成されているものとする。“煙センサ”はイベント(煙)を検知すると、火災が発生している可能性が高いと判断し、高い優先度(高優先度モード)でメッセージを送信する。“炎センサ”はイベント(炎)を検知すると、火災が発生している可能性が高いと判断し、“煙センサ”と同様に、高い優先度(高優先度モード)でメッセージを送信する。一方、“人感センサ”がイベント(人の有無)を検知すると、ノーマルモードでセンシングデータを送信する。
図4では、MTCグループ内のMTCデバイス100を識別するために、MTCデバイスA100AとMTCデバイスB100Bとが図示されている。なお、ここでは、MTCデバイスA100Aを、最初にイベントを検知するMTCデバイス(“煙センサ”)と仮定し、MTCデバイスB100Bを、MTCデバイスA100Aと同一のMTCグループに属する他のMTCデバイス(“煙センサ”、“炎センサ”、“人感センサ”)と仮定する。
以下、図4に図示されているシーケンスについて説明する。MTCデバイスA100A(煙センサ)は、MTCサーバ150と通信を行うためのPDNコネクションを、従来手法(例えば、非特許文献3で示されるAttach procedure)に基づいてPGW140と確立する(図4のステップS301:PDNコネクション確立済み)。また、MTCデバイスB100Bも同様に、従来手法(例えば、非特許文献3で示されるAttach procedure)に基づいて、PGW140とPDNコネクションを確立する(図4のステップS308:PDNコネクション確立済み)。
ここで、MTCデバイスA100Aが、例えば、火災発生などにより、イベント(煙)を検知したとする(図4のステップS302:イベント検知)。イベントを検知したMTCデバイスA100Aは、イベントを検知したことをMTCサーバ150に通知するために、検知したイベント情報など(例えば、煙発生フラグ、デバイス種IDなど)を格納したイベント通知メッセージを作成し、MTCサーバ150にイベント通知メッセージ(ここでは、イベント通知メッセージ(イベント情報)@デバイスAと表記)を送信する(図4のステップS303:イベント通知メッセージ(イベント情報)@デバイスA)。なお、MTCデバイスA100A(煙センサ)が煙を検知した場合は、火災が発生している可能性が高いと予測され、MTCデバイスA100Aは優先度の高いメッセージを用いて、MTCサーバ150に通知する。また、このとき、MTCデバイスA100Aは、イベント通知メッセージにセンシングデータ(煙濃度)を格納してもよい。
図5Aは、図4のステップS303において、MTCデバイスA100Aが通信システムを通じて、MTCサーバ150に送信するメッセージの一例として、イベント通知メッセージ(イベント情報)@デバイスAのフォーマット例を示す図である。
MTCデバイスA100Aは、例えば、従来のNASメッセージフィールドに、少なくともイベントフラグフィールドを追加する。イベントフラグフィールドは、MTCデバイスA100Aがイベントを検知したこと(例えば、MTCデバイスA100Aが煙センサの場合は、煙発生フラグ)を示すためのフィールドである。なお、検出したイベントの種別を併記してもよい。さらには、センシングデータフィールド、デバイス種IDフィールドを追加してもよい。また、センシングデータフィールドは、例えばイベントを検知した際に、MTCサーバ150に早期に(すなわちイベント通知とともに)送信しておきたいデータ(例えば、MTCデバイスA100Aが煙センサの場合、煙濃度など)を格納するためのフィールドである。また、デバイス種IDフィールドは、イベントを検知したMTCデバイスA100Aの種類を識別するための情報を格納するためのフィールドである。例えば、MTCデバイスA100Aが煙センサの場合は、“煙センサ”であることが識別可能な情報が格納される(例えば、IMEIのデバイス種別を示すビット列から判断する、など)。なお、これら従来のNASメッセージに加えたイベントフラグフィールド、センシングデータフィールド、デバイス種IDフィールドは、NASメッセージフィールドに埋め込まれるものであってもよい。また、従来のNASメッセージ以外のメッセージ(例えば、MTC用の)を用いてもよい。
なお、本実施の形態は、Cプレーンでイベント通知メッセージ(イベント情報)@デバイスAが送信されると仮定しているが、Uプレーンで送信される場合には、従来のUプレーンで送信されるメッセージの任意のフィールドでもよい。また、MTCデバイスA100A、若しくはMTCサーバ150/MTCユーザ160が、イベントフラグフィールドの情報を用いなくても、MTCデバイス100がイベントを検知したことを確認できる、例えば、“Time controlled”が適用されたMTCデバイス100が、割り当てられた時間外にアクセスしてきた場合に、MTCデバイス100が高優先度モードで通知すべきイベントを検出したものとMME120が判断できる場合は、イベントフラグフィールドを省略してもよい。また、MTCデバイスA100AがMTCサーバ150に早期に(すなわちイベント通知とともに)送信しておきたいセンシングデータがない場合は、センシングデータフィールドを省略してもよい。また、デバイス種IDフィールドも同様に、従来のNASメッセージフィールドに格納されているデバイスIDから、そのデバイスの種類を導出することができるのであれば、省略してもよい。また、デバイス種IDフィールドに情報が格納されていることで、MTCデバイスA100Aがイベントを検知したということを確認できる(例えば、煙センサを示すデバイス種IDが格納される場合、同時に煙検知イベントが通知されたものとする)のであれば、イベントフラグフィールドも同様に省略してもよい。
なお、このMTCデバイスA100Aから送信される優先度の高いメッセージであるイベント通知メッセージ(イベント情報)@デバイスAは、例えば、非特許文献1が定義するPAMや、非特許文献3で記述されているTAU(Tracking Area Update)リクエストなどの位置登録メッセージにピギーバック(重畳)した場合、又は、PDNコネクションやEPSベアラが確立されていない状態でイベントを検知した場合は、PDNコネクションやEPSベアラを確立する際に用いられる、例えば、Attach RequestやService Request、非特許文献4にて定義されるDS-MIPv6 bootstrapping based on IKEv2で使用されるIKE_SA_INITメッセージやIKE_AUTH Requestメッセージを改良して用いてもよい。また、Bearer Modification Requestメッセージを用いるものであってもよい。これによって、新規メッセージを導入することなく、少ない修正でMTCデバイス100からのイベント通知を実施することができる。
通信システムのエンティティ(例えば、MME120)は、イベント通知メッセージ(イベント情報)@デバイスAを受信すると、受信したメッセージから、必要な情報(例えば、イベントフラグ、センシングデータ、デバイス種ID)を抽出し、例えば、従来のUpdate Bearer Requestメッセージなどに格納し、SGW130/PGW140を通じて、MTCサーバ150にイベント通知メッセージ(イベント情報)@デバイスAを転送する。このとき、MME120は、イベント通知メッセージ(イベント情報)@デバイスAからイベント情報(イベントフラグ/デバイス種ID)を抽出して、逆イベント通知メッセージ(イベント情報)(逆PAM、混雑回避メッセージ、Time Tolerant Indication、congestion indication、congestion prior indication、PAM reduction indicationなどと呼ばれてもよい)に格納し、MTCデバイスA100Aが属しているMTCグループ内の全てのMTCデバイス100に送信する(図4のステップS304:逆イベント通知メッセージ(イベント情報))。
また、この逆イベント通知メッセージは、逆イベント通知メッセージの送信元(例えば、MME120)の判断(例えば、通信システムのオペレータによる事前設定)によって、他のメッセージより高い優先度、若しくは一般的な優先度で送信してもよい。他のメッセージより高い優先度で逆イベント通知メッセージが送信される場合は、メッセージの送信元が過負荷状態であり、一般的な優先度のメッセージの処理が放棄される場合でも、優先度の高い逆イベント通知メッセージは送信することができる。また、優先度の高い逆イベント通知メッセージではなく、一般的な優先度で逆イベント通知メッセージを送るものであってもよい。この場合は、特にメッセージの優先度を設定する必要がなくなる。
また、MME120は、一定期間内に所定数のイベント通知メッセージを受信した、あるいは単に一定数のイベント通知メッセージを受信した場合に、逆イベント通知メッセージを送信するものであってもよい。これにより、同一のイベント通知メッセージが今後も増加するであろうことを予見した上で、それらの発生を抑えるための逆イベント通知メッセージを送信することにより、単発のイベント通知メッセージから判断する場合に比べて、抑止メッセージ(逆イベント通知メッセージ)を効果的に発行することができ、通信リソースや帯域の有効利用を図ることができる(単発のイベント通知メッセージにより判断する場合、イベント通知メッセージを受信するたびに逆イベント通知メッセージを送信することになり、通信リソースや帯域を浪費することになる)。
このとき、MME120は、MTCデバイスA100AがMTCグループに属しているか、また、MTCグループに属しているのであれば、どのMTCグループに属しているかを確認するために、MTCデバイスA100Aに対応するサブスクリプションデータをHSS125から取得してグループIDが登録されているかどうかで判断してもよい。若しくは、ステップS303のイベント通知メッセージ(イベント情報)@デバイスAに格納されているグループIDなどから判断してもよい(図5A不図示)。また、MME120が既にサブスクリプションデータを保持、又は、HSS125からサブスクリプションデータを取得する以外の方法(例えば、外部サーバなど)を用いて、MTCデバイスA100AがMTCグループに属しているかどうかを確認できるのであれば、HSS125に問い合わせる必要はない。
また、ここでは逆イベント通知メッセージを送信する対象を、イベントを検知したMTCデバイスA100Aが属しているMTCグループ配下の全てのMTCデバイス(MTCデバイスA100A及びMTCデバイスB100B)としているが、“Group based”を搭載していないケースにおいては、MTCデバイスA100Aが接続しているeNB110配下の全てのMTCデバイス100を逆イベント通知メッセージの送信対象としてもよい。この場合、特定のエリアに位置するMTCデバイス100からの同じイベントによる優先度の高いイベント通知メッセージを抑制することができる。また、MTCグループという概念を考慮せずに、優先度の高いイベント通知メッセージを抑制できることにより、グループIDなどを用いなくてもよいという利点がある。ここでは、グループIDの代わりに、eNB IDやeNBアドレス(並びにMTCデバイス100のEPSベアラに対応するS1-U TEID)を使用してもよい。また、MME120があらかじめ送信相手を確認できているのであれば、ブロードキャストではなく、マルチキャストやユニキャストで逆イベント通知メッセージを送信してもよい。これにより、制御範囲(通知範囲)を限定することにより、システム全体へのインパクトを低減させることができる。
また、MME120は、逆イベント通知メッセージ(イベント情報)をMTCグループの全てのMTCデバイス100に送信する際、例えば、逆イベント通知メッセージ(イベント情報)の送信先であるMTCグループのグループID、デバイス種IDと一緒に逆イベント通知メッセージ(イベント情報)を送信したことを、逆イベント通知メッセージ(イベント情報)送信済み情報として記憶する。この記憶した逆イベント通知メッセージ(イベント情報)送信済み情報は、同じMTCグループ内の同じデバイス種のMTCデバイス100から同一イベント、又は、そのイベントを引き起こした出来事によって引き起こされたイベントによるイベント通知メッセージ(イベント情報)を受信した際に、再度同じ逆イベント通知メッセージ(イベント情報)を送信しないように、MTCデバイス100が判断するパラメータとして使用される。なお、イベント通知メッセージ(イベント情報)を受信した際、同じMTCグループの同じMTCデバイス種からのイベント通知メッセージ(イベント情報)であると判断できる場合は、再度、逆イベント通知メッセージ(イベント情報)を送信することが望ましいが、この場合は、必ずしも逆イベント通知メッセージ(イベント情報)送信済み情報を記憶する必要はない。また、MME120は、上記したようにMTCデバイス100の種類を確認できるものとする(例えば、MTCデバイスのデバイスIDからMTCデバイス100の種類を確認することができる(例えば、デバイスIDのうちデバイス種別を示す一部のビット列(例えば、上位あるいは下位数ビット)、又は、外部サーバにデバイスIDを通知するとデバイス種IDを取得できるなど)、又は、図5Aに図示されているようにイベント通知メッセージ(イベント情報)@デバイスAにデバイス種IDも格納されていることとする)。
また、MTCデバイス100が複数のイベントグループ情報を保持している場合、MME120は、イベントグループ情報ラベル(複数のイベントグループ情報のうちのどのイベントグループ情報を使用するかを示すためにイベントグループ情報と関連付けられている情報)を逆イベント通知メッセージ(イベント情報)に格納して送信を行う。MME120が、どのイベントグループ情報を使用するかを判断する方法は、例えば、サブスクリプションデータに登録されている情報(例えば、イベント情報とイベントグループ情報が対になっている情報など)を用いてもよいし、MTCサーバ150/MTCユーザ160が、あらかじめ設定しているMTCサービスの仕様や登録情報、また設定情報などに基づいて決定してもよい。また、MME120による上記の判断(どのイベントグループ情報を使用するか)は、MTCデバイス100が送信するイベント通知メッセージ(イベント情報)で、複数のイベントグループ情報を保持していることを通知したうえで、実施されてもよい。
ここで、図5Bを参照しながら、逆イベント通知メッセージ(イベント情報)について説明する。図5Bは、図4のステップS304において、MME120が、MTCデバイスA100Aが属するMTCグループの全てのMTCデバイス100(MTCデバイスB100Bを含む)にブロードキャストするメッセージの一例として、逆イベント通知メッセージ(イベント情報)のフォーマット例を示す図である。
MME120は、従来のNAS返信メッセージフィールドに、イベントフラグフィールド、デバイス種IDフィールド、イベントグループ情報ラベルフィールドを追加したメッセージを送信する。イベントフラグフィールドは、MTCデバイス100がイベントを検知したことを示すためのフィールドである。なお、イベントフラグフィールドは、このメッセージが逆イベント通知メッセージであることを識別するためのフィールドとしても用いられる。また、デバイス種IDフィールドは、イベントを検知したMTCデバイス100の種類の情報(例えば、煙センサ)を格納するためのフィールドである。デバイス種IDフィールドには、例えば、この逆イベント通知メッセージを送信するきっかけとなったイベント通知メッセージの送信元のMTCデバイス100の種類を識別するための情報が格納される。なお、このデバイス種IDフィールドに格納される情報は、後述するイベントグループ情報(図6参照)内に登録されている情報と対応付けられている必要があり、また、イベントグループ情報内に登録されている情報との対応が明確に判別できるのであれば、デバイス種ID以外の情報(例えば、イベントのIDなど)を用いてもよい。また、イベントグループ情報ラベルフィールドは、例えば、MTCデバイス100が複数のイベントグループ情報を保持している際に使用されるフィールドである。このイベントグループ情報ラベルフィールドには、MTCデバイス100がどのイベントグループ情報を使用するかを決定するために、MME120によってイベントグループ情報ラベル(例えば、火災、地震、強盗、建物崩壊、土砂崩れなど)が格納される。
なお、本実施の形態は、Cプレーンで逆イベント通知メッセージ(イベント情報)が送信されると仮定しているが、Uプレーンで送信される場合には、従来のUプレーンで送信されるメッセージの任意のフィールドでもよい。また、MTCデバイス100が、MME120からの逆イベント通知メッセージ(イベント情報)に格納されるイベントフラグフィールドの情報を用いなくても、同じMTCグループ、若しくは、周辺のMTCデバイス100が、イベントを検知したことを確認できるのであれば(例えば、“Time controlled”で割り当てられた時間外のメッセージ受信から確認可能)、イベントフラグフィールドを省略してもよい。また、MME120が、MTCデバイス100が1つのイベントグループ情報しか保持していないことを確認済みの場合や、イベントグループ情報を用いたモード遷移の詳細な管理を行わないような場合には、イベントグループ情報を識別する必要がないので、イベントグループ情報ラベルフィールドを省略してもよい。例えば、ネットワーク装置(例えば、MME120)から送信される逆イベント通知メッセージに、イベントグループ情報ラベルを格納せずにデバイス種IDのみを格納することで、最初にイベント通知メッセージを送信したMTCデバイス100と同種のMTCデバイス100からのイベント通知メッセージのみを抑制することができる。
なお、これら従来のNASメッセージに加えたイベントフラグフィールド、デバイス種IDフィールド、イベントグループ情報ラベルフィールドは、NAS返信メッセージフィールドに埋め込まれるものであってもよい。
なお、このMME120から送信される逆イベント通知メッセージ(イベント情報)は、例えば、非特許文献3や非特許文献5で記述されているPagingメッセージやBearer Modification Requestメッセージ、非特許文献1が定義するPAM、非特許文献3で記述されているTAU Acceptメッセージ、又は、非特許文献4が定義するDS-MIPv6 bootstrapping based on IKEv2で使用されるIKE_SA_INITメッセージやIKE_AUTH Responseメッセージを拡張して用いてもよい。
なお、イベント通知メッセージ(イベント情報)@デバイスAに格納されているイベント情報を参照し、その参照したイベント情報を逆イベント通知メッセージ(イベント情報)に格納してブロードキャストするエンティティは、MME120ではなく、PGW140やMTCサーバ150であってもよい。また、イベント通知メッセージ(イベント情報)@デバイスAに格納されているデバイス種IDと、逆イベント通知メッセージ(イベント情報)に格納されているデバイス種IDは、関連性が保証されているのであれば、必ずしも一致しなくてもよい。しかし、この場合も、逆イベント通知メッセージ(イベント情報)に格納されている情報と、イベントグループ情報に登録されている情報(例えば、デバイス種ID)とは、関連性が保証されている必要がある。なお、デバイス種IDではなく、イベント情報や従来のNASメッセージに含まれているMTCデバイス100を識別する、例えば、IPアドレスや、デバイスIDを基に、逆イベント通知メッセージ(イベント情報)に格納するデバイス種IDを確認できるのであれば、イベント通知メッセージ(イベント情報)@デバイスAに格納されているデバイス種IDを使用する必要はない。
逆イベント通知メッセージ(イベント情報)を受信したMTCグループ内のMTCデバイス100(図4中のMTCデバイスB100Bに相当)は、逆イベント通知メッセージ(イベント情報)に格納されているデバイス種IDを抽出し、MTCデバイスB100B自身のデバイスID/デバイス種IDと一致しているかどうかを確認する(図4のステップS309:自種IDと一致しているかを確認)。この確認によって、逆イベント通知メッセージ(イベント情報)から抽出されたデバイス種IDと、自身のデバイスID/デバイス種IDとが一致している場合には、MTCデバイス100は、ノーマルモードに遷移する(元々ノーマルモードだった場合はそのまま維持)。なお、逆イベント通知メッセージ(イベント情報)から抽出されたデバイス種IDは、その逆イベント通知メッセージを送信するきっかけとなったイベント通知メッセージ(イベント)の送信元のMTCデバイス100(ここでは、MTCデバイスA100A)の種類を表している。すなわち、MTCデバイスB100Bは、自デバイスと同種類のMTCデバイス100からイベント通知メッセージが送信されたかどうかを判断し、自デバイスと同種類のMTCデバイス100からイベント通知メッセージが既に送信されたことが確認できた場合には、高優先度モードによるイベント通知メッセージの送信を行わないよう、ノーマルモードで動作を行う。
また、MTCデバイスB100Bは、受信した逆イベント通知メッセージ(イベント情報)に含まれているデバイス種IDに基づいて、高優先度モードへのモード切替を行うべきかどうかを判断し、高優先度モードへのモード切替を行う必要が確認された場合には、高優先度モードへモード切替(あるいは、元々高優先度モードで動作しているのであればそのまま高優先度モードを維持)を行う(図4のステップS310:高優先度モードへの切替を行うかどうかを判断(モード切り換え))。ここで、高優先度モードへモード切替を行うべきかどうかの判断は、例えば、逆イベント通知メッセージ(イベント情報)から抽出したデバイス種IDが、そのMTCデバイスB100Bが保持しているイベントグループ情報(図6)に記載されているかどうかで判断する。なお、MTCデバイスB100Bが複数のイベントグループ情報を保持している場合は、逆イベント通知メッセージ(イベント情報)に格納されているイベントグループ情報ラベルを抽出し、抽出されたイベントグループラベル情報に対応するイベントグループ情報を使用して判断する。
図6は、MTCデバイス100が、受信した逆イベント通知メッセージ(イベント情報)に含まれているデバイス種ID/イベントグループ情報ラベルに基づいて、モード切替を行うべきかどうかを判断するために用いられるイベントグループ情報の一例を示す図である。このイベントグループ情報には、複数のデバイス種ID(対応関係が分かるのであれば、デバイス種IDと一致する必要はない)が登録されており、このデバイス種IDは静的/動的に設定される。逆イベント通知メッセージ(イベント情報)を受信したMTCデバイスB100Bは、逆イベント通知メッセージ(イベント情報)から抽出されたデバイス種IDが、イベントグループ情報に登録されているかどうかを確認する。
図6には、MTCデバイスB100B(人感センサ)が保持しているイベントグループ情報の一例が図示されている。図6では、イベントグループ情報に煙センサIDと炎センサIDとが記載されており、このイベントグループ情報を保持しているMTCデバイスB100B(人感センサ)は、煙センサID又は炎センサIDが含まれている逆イベント通知メッセージ(イベント情報)を受信すると、高優先度モードへモード切替を行って(あるいは、そのまま高優先度モードを維持して)動作を行う。すなわち、イベントグループ情報には、特定の逆イベント通知メッセージ(イベント情報)を受信した場合、高優先度モードに遷移あるいは維持するよう規定する情報が登録されている。
イベントグループ情報にどの種類のデバイス種IDを登録するかは、例えば、イベント発生時の好適な動作に基づいて考慮されることが好ましい。一例として、例えば、火災が発生したときには、煙センサからネットワーク側へ優先度の高いイベント通知メッセージ(イベント情報)が送信され、その逆イベント通知メッセージ(イベント情報)がMTCグループ内にブロードキャストされた場合であっても、炎を検知するために炎センサは高優先度モードのまま動作させておき、また、人が残っていないかどうかを迅速に把握するために人感センサを高優先度モードにモード遷移させることが最適な動作であるとする。この場合には、例えば、炎センサが保持するイベントグループ情報に煙センサIDと人感センサID、煙センサが保持するイベントグループ情報に炎センサIDと人感センサID、人感センサが保持するイベントグループ情報に煙センサIDと炎センサIDをそれぞれ登録しておくことで、最適な動作を実現することが可能となる。なお、イベントグループ情報に登録するデバイス種ID及び各MTCデバイス100の動作については、後で詳細に説明する。
なお、ステップS309及びステップS310の確認処理は、各MTCデバイス100にイベントグループ情報をどのように持たせるか(各MTCデバイス100個別にイベントグループ情報を持たせるのか、あるいは、複数のMTCデバイス100に同じイベントグループ情報を持たせるのか)や、イベントグループ情報内に含まれる情報をどのように構成しておくか(イベントグループ情報を持つMTCデバイス100の自種IDをイベントグループ情報に含ませておくかどうか)などによって、様々な方法を採用することが可能である。しかしながら、本発明の基本的な考え方は、ステップS309及びステップS310の確認処理の方法を限定するものではない。本発明では、逆イベント通知メッセージを受信したMTCデバイス100が、自デバイスと同種類のデバイスから既にイベント通知メッセージの送信が行われたかどうかを確認でき、さらに、自デバイスと異なる種類のデバイスからイベント通知メッセージの送信が行われている場合には高優先度モードへ遷移(あるいは、現在のモードをそのまま維持)すべきかどうかを判断できるようにすることが重要である。
また、図6には、上述のように、MTCデバイスB100B(人感センサ)が保持するイベントグループ情報が図示されているが、このイベントグループ情報に、人感センサ自体のID(人感センサID)が含まれていてもよい。ここで一例として挙げているステップS309及びステップS310の確認処理によれば、MTCデバイスB100B(人感センサ)は、自身が保持しているイベントグループ情報に自デバイス種ID(人感センサID)が含まれているかどうかを確認することはないが、逆イベント通知メッセージ(イベント情報)を受信した場合でも例外的に高優先度モードで動作を行うMTCデバイス100のデバイス種IDの一覧を、イベントグループ情報として登録することで、共通のイベントグループ情報を作成することも可能である。具体的には、火災発生時に、煙センサ、炎センサ、人感センサを高優先度モードで動作させたいと考えた場合には、イベントグループラベルの情報「火災」が付けられており、煙センサ、炎センサ、人感センサが登録されたイベントグループ情報を、煙センサ、炎センサ、人感センサに共通して持たせておくことも可能である。さらに、ステップS309及びステップS310の確認処理を上述したものとは異なる動作とすることで、すべてのMTCデバイス100が共通のイベントグループ情報を持たせた場合であっても、本発明に係る詳細なモード遷移の管理を実現できる方法も存在する。
また、MTCグループのMTCデバイス100は、逆イベント通知メッセージ(イベント情報)を受信した際、逆イベント通知メッセージ(イベント情報)に格納されているデバイス種ID(例えば、煙センサ)を記憶する(図4のステップS311:イベント情報の記憶)。この記憶したイベント情報は、MTCデバイス100が再度MME120から別の逆イベント通知メッセージ(イベント情報(例えば、人感センサID))を受信した際に、優先度の高いイベント通知メッセージを送信しない(高優先度モードに切り替わらない)と判断するパラメータとして使用される。例えば、MTCデバイスA100A(煙センサ)が、イベントを検知して、優先度の高いイベント通知メッセージ(イベント情報)を送信した後、MTCデバイスA100Aと同じMTCグループに属しているMTCデバイス100は、デバイス種IDが“煙センサ”の逆イベント通知メッセージ(イベント情報)を受信する。このとき、MTCデバイスA100Aと同じデバイス種のMTCデバイスB100B(煙センサ)は、高優先度モードからノーマルモードにモード遷移するとともに、デバイス種IDが“煙センサ”の逆イベント通知メッセージ(イベント情報)を受信したことを記憶する。その後、同じMTCグループのMTCデバイスB100B(人感センサ)がイベントを検知して、優先度の高いメッセージ(イベント情報)を送信した場合には、MTCグループ内のMTCデバイス100は、デバイス種IDが“人感センサ”の逆イベント通知メッセージ(イベント情報)を、デバイス種IDが“煙センサ”の逆イベント通知メッセージ(イベント情報)に続いて受信する。このとき、MTCデバイスA100Aは、先に受信しているデバイス種IDが“煙センサ”の逆イベント通知メッセージ(イベント情報)を記憶しており、この記憶された情報(受信履歴)をパラメータとして、ノーマルモードから高優先度モードにモード遷移せずに、再度優先度の高いイベント通知メッセージ(イベント情報)を送信しないよう動作する。これにより、同一イベント(例えば、火災発生)の際にいったん高優先度モードからノーマルモードに遷移したMTCデバイス100は、再度、高優先度モードに戻らないように制御することが可能となる。なお、このモード切替するための判断要素となるパラメータは、MTCデバイス100の種類を示すデバイス種ID以外の情報でもよい。
なお、ステップS309の自デバイス種IDの確認ステップからステップS311のイベント情報の記憶ステップは、順不同で実施してもよい。
その後、MTCデバイスB100B(例えば、人感センサ)が、イベント(例えば、人の存在)を検知したとする(図4のステップS313:イベント検知)。イベント検知したMTCデバイスB100Bは、イベント検知時にデータ送信するモードを確認し、その送信モードに従って、MTCサーバ150に通知を行う。このとき、MTCデバイスB100Bが高優先度モードであり、優先度の高いメッセージを通知する場合は、MTCデバイスB100Bは、検知したイベント情報などを格納したイベント通知メッセージをMTCサーバ150に通知する(図4のステップS314:イベント通知メッセージ(イベント情報)@デバイスB)。一方、MTCデバイスB100Bが高優先度モードではなくノーマルモードで送信する場合は、ステップS314のイベント通知メッセージ(イベント送信)(点線部分)はノーマルモードで通知するか、若しくは行わず、MTCサーバ150にセンシングデータを送信する(図4のステップS315:取得データ送信)。なお、ステップS314のイベント通知メッセージとステップS315の取得データ送信は、逐次的、若しくは、同時に行ってもよい。
また、最初にイベント通知メッセージ(イベント情報)を送信したMTCデバイスA100Aも、逆イベント通知メッセージ(イベント情報)を受信し、逆イベント通知メッセージ(イベント情報)に従って、図7のように高優先度モードからノーマルモードにモード遷移を行い(図4のステップS306:モード切替)、逆イベント通知メッセージ(イベント情報)を受信したことを記憶する(図4のステップS307:イベント情報の記憶)。そして、その後は、MTCデバイスA100Aは、ノーマルモードでセンシングデータの送信を行う(図4のステップS316:取得データ送信)。なお、図4のステップS316の取得データ送信は、ステップS303のイベント通知メッセージ(イベント情報)@デバイスA送信後の任意のタイミングに行うことが可能である。また、ここでは、最初にイベント通知メッセージ(イベント情報)を送信したMTCデバイスA100Aが、逆イベント通知メッセージ(イベント情報)の受信によって、高優先度モードからノーマルモードへモード遷移を行っているが、高優先度モードによるイベント通知メッセージ(イベント情報)の送信を行った直後に自らノーマルモードへモード遷移してもよく、あるいは、イベント通知メッセージ(イベント情報)を送信したMTCデバイスA100Aに関しては、そのまま高優先度モードによる通知を継続して行えるようにしてもよい。
また、通常、イベントを検知した際に高い優先度のイベント通知メッセージでMTCサーバ150に通知していたMTCデバイス100(例えば、炎センサ)は、例えば、一定時間後(例えば、逆イベント通知メッセージでライフタイム値を通知など)、又は、MME120、MTCサーバ150から送信されるメッセージ(例えば、NASメッセージなど)をMTCデバイス100が受信することで、ノーマルモードから高優先度モードに戻すことができる。また、通常、いったん高優先度モードに遷移した後にノーマルモードに戻って動作を行っているMTCデバイス100(例えば、人感センサ)に関しても、同様の方法で、元の状態(逆イベント通知メッセージを受信した場合に、ノーマルモードから高優先度モードへ遷移できる状態)に戻すことができる。これにより、1つのイベントが終了後も、通常と同様の動作に戻すことができる(図4には不図示)。
次に、図8を参照しながら、本発明の第2の実施の形態におけるMTCデバイス100の構成について説明する。図8は、本発明の第2の実施の形態におけるMTCデバイス100の構成の一例を示す図である。
図8において、MTCデバイス100は、通信システム(例えば、E−UTRANやUTRAN)と接続して下位レイヤにおける通信処理と上位レイヤでIPなどのパケット通信処理を実施する通信処理部501、受信したメッセージが逆イベント通知メッセージであるか判断し、受信した逆イベント通知メッセージに格納されているイベント情報を記憶し、逆イベント通知メッセージに格納されているデバイス種IDが、MTCデバイス100自身のデバイス種IDと一致しているか確認し、さらに、保持しているイベントグループ情報に逆イベント通知メッセージに格納されているデバイス種IDが登録されているか確認する逆イベント通知メッセージ処理部502、逆イベント通知メッセージを受信した際にMTCデバイス100の現在の送信モードを確認し、その送信モードを確認するために使用する情報を保持し、MTCデバイス100の送信モードを切り替える送信モード制御部504、特定のイベント(そのMTCデバイス100が監視しているイベント)を検知するイベント検知部505、イベント検知時に高い優先度のメッセージで送るか判断するイベント通知メッセージ処理部503を少なくとも有する。なお、例えば、イベント通知メッセージ処理部503が、送信モード制御部504の機能を保持している場合は、送信モード制御部504を省略できる。他の機能部も同様に、1つの機能部で上記の機能部を含む場合は、省略してもよい。逆に、例えば、イベント通知メッセージ処理部503で実施している、受信した逆イベント通知メッセージに格納されているイベント情報を記憶する機能と、イベント検知時に高い優先度のメッセージで送るかどうかを判断する機能とを分けてもよい。
なお、MTCデバイス100において上述の各構成要素が動作を行うことで、特定のイベントの発生を検知するためのセンサによって検知されたセンシングデータを通常の優先度で送信するノーマルモード、又は、センサによって特定のイベントの発生を検知したことを通知するイベント通知メッセージをノーマルモード、若しくは、ノーマルモードの優先度よりも高い優先度で送信する高優先度モードのいずれかの送信モードで動作を行うよう制御する動作モード制御部としての機能、ネットワークノードへ高優先度モードによるイベント通知メッセージの送信又はノーマルモードによるセンシングデータの送信を行う送信部としての機能、特定のイベントの発生を検知したことを通知するイベント通知メッセージを任意の通信ノードから受信したネットワークノードから、任意の通信ノードが通知するイベント通知メッセージに対する応答として送信されるメッセージであって、送信モードをノーマルモードへ遷移するか又はノーマルモードのまま維持するよう指示するメッセージを受信するメッセージ受信部としての機能、メッセージを受信した場合に、送信モードをノーマルモードへ遷移するか又はノーマルモードのまま維持するかどうかを判断するモード遷移判断部としての機能などが実現される。
次に、図8に図示されている構成を有するMTCデバイス100について、本発明における特徴的な処理を中心に、図9Aと図9Bを用いて詳しく説明する。図9Aは、本発明の第2の実施の形態において、イベント検知時に、ノーマルモード又は高優先度モードでMTCサーバ150への送信処理を行うMTCデバイス100の処理フローの一例を示すフロー図であり、図9Bは、本発明の第2の実施の形態において、ネットワーク側(例えば、MME120)から逆イベント通知メッセージを受信したMTCデバイス100の処理フローの一例を示すフロー図である。
最初に、図9Aを参照しながら、MTCデバイス100がイベントを検知した際に、ノーマルモード又は高優先度モードでMTCサーバ150への送信する場合の処理フローについて説明する。
MTCデバイス100は、MTCサーバ150と通信を行うために、PGW140との間にPDNコネクション及びEPSベアラを確立する(図9AのステップS601)。
ここで、MTCデバイス100は、イベント検知部505でイベントを検知したとする(図9AのステップS602)。なお、イベントの検知は、例えば、煙センサであれば煙の検知、炎センサであれば炎の検知、人感センサであれば人物の検知などである。イベント検知後、MTCデバイス100は、送信モードに関する情報を取得し(図9AのステップS603)、高い優先度のメッセージでMTCサーバ150に送信するかどうかを、イベント通知メッセージ判断部503で判断する(図9AのステップS604)。
送信モードが高優先モードであり、高い優先度のイベント通知メッセージでMTCサーバ150に通知すると判断した場合、MTCデバイス100は通信処理部501で例えば、イベントフラグ(例えば、煙発生)、センシングデータ、デバイス種IDを生成し(図9AのステップS605)、このイベント情報を格納したイベント通知メッセージ(イベント情報)@デバイスAを、通信システムを通じてMTCサーバ150に送信する(図9AのステップS606)。
なお、上述のように、例えば、“Time Controlled” が適用されたMTCデバイス100が、割り当てられた時間外にアクセスしてきた場合に、MTCデバイス100が高優先度モードで通知すべきイベントを検出したものとネットワーク側(例えば、MME120)が判断できる場合、MTCデバイス100は、イベントフラグをイベント通知メッセージ(イベント情報)@デバイスAに格納する必要はない。また、上記以外の手段を用いて、MTCデバイス100がイベントを検知したことをネットワーク側が確認できるのであれば、同様にイベントフラグを省略してもよい。また、デバイス種IDも同様に、例えば、デバイスIDのうちデバイス種別を示す一部のビット列(例えば、上位あるいは下位数ビット)からMTCデバイス100の種類を導出し、MTCデバイス100の種類をネットワーク側で識別できるのであれば、デバイス種IDを格納する必要はない。
一方、送信モードがノーマルモードであり、一般的な優先度で検知したイベント(例えば、煙発生)とセンシングデータをMTCサーバ150に送信すると判断した場合、MTCデバイス100は、通常通り、イベント通知メッセージ(イベント情報)@デバイスAと取得したセンシングデータを、通信処理部501から送信する(図9AのステップS607)。
なお、上述のように、MTCデバイス100は、一定時間後(例えば、逆イベント通知メッセージで通知されたライフタイム値など)、又は、MME120、MTCサーバ150から送信されるメッセージ(例えば、NASメッセージなど)を受信したときに、高優先度モードからノーマルモード、若しくは、ノーマルモードから高優先度モードに戻す処理を行ってもよい(図9Aには不図示)。
次に、図9Bを参照しながら、MTCデバイス100がネットワーク側(例えば、MME120)から逆イベント通知メッセージを受信した場合の処理フローについて説明する。
MTCデバイス100は、MTCサーバ150と通信を行うために、PGW140との間にPDNコネクション及びEPSベアラを確立する(図9BのステップS701)。
ここで、MTCデバイス100は、通信システムから何らかのメッセージを受信すると、受信したメッセージが逆イベント通知メッセージ(イベント情報)であるかどうかを逆イベント通知メッセージ処理部502にて判断する(図9BのステップS702)。逆イベント通知メッセージ(イベント情報)ではないと判断した場合には、そのメッセージに適した別の処理が行われる(図9Bには不図示)。
一方、逆イベント通知メッセージ(イベント情報)だと判断した場合、MTCデバイス100は、逆イベント通知メッセージ(イベント情報)からデバイス種IDを抽出し、同一のデバイス種IDが格納された逆イベント通知メッセージ(イベント情報)を再度受信した場合を特定するために、抽出されたデバイス種IDを逆イベント通知メッセージ処理部502にて記憶する(図9BのステップS703)。
続いて、逆イベント通知メッセージ処理部502において、MTCデバイス100自身のデバイスID/デバイス種IDと逆イベント通知メッセージ(イベント情報)に格納されているデバイス種IDとが一致しているかどうかを確認する(図9BのステップS705)。MTCデバイス100自身のデバイスID/デバイス種IDと逆イベント通知メッセージ(イベント情報)に格納されているデバイス種IDとが一致する場合は、自デバイスと同じ種類のMTCデバイス100からイベント通知メッセージが既に送信されていると判断でき、MTCデバイス100は、ノーマルモードで動作を行う(図9BのステップS706)。なお、ステップS706では、MTCデバイスが高優先度モードだった場合は、送信モード制御部504においてノーマルモードに遷移し、MTCデバイスがノーマルモードだった場合は、そのままノーマルモードを維持する。
一方、MTCデバイス100自身のデバイスID/デバイス種IDと逆イベント通知メッセージ(イベント情報)に格納されているデバイス種IDとが一致しない場合は、逆イベント通知メッセージ処理部502において、逆イベント通知メッセージ(イベント情報)に含まれるイベントグループ情報ラベルに対応するイベントグループ情報を読み出し(図9BのステップS707)、逆イベント通知メッセージ(イベント情報)から抽出したデバイス種IDが、イベントグループ情報に登録されているかどうかを確認する(図9BのステップS708)。逆イベント通知メッセージ(イベント情報)から抽出したデバイス種IDがイベントグループ情報に登録されていない場合は、受信した逆イベント通知メッセージはMTCデバイス100が関与していないイベントに係る逆イベント通知メッセージ(イベント情報)であると判断でき、MTCデバイス100は、処理を終了する。なお、デバイス種IDのリストが登録されたイベントグループ情報をMTCデバイス100に保持させるのではなく、自デバイス種とそのラベルとが関連付けられているかどうかを示す情報を保持させることも可能であり、この場合には、MTCデバイス100は、ステップS708において、「自デバイス種とラベル名(例えば「火災」)とが関連付けられているかどうかを確認するだけでよい。
一方、逆イベント通知メッセージ(イベント情報)から抽出したデバイス種IDが、イベントグループ情報に登録いる場合は、受信した逆イベント通知メッセージ(イベント情報)はMTCデバイス100が関与しているイベントに係る逆イベント通知メッセージ(イベント情報)であると判断できる。この場合、MTCデバイス100は、逆イベント通知メッセージ処理部502に記憶されているデバイス種IDを確認し、同じ種類のMTCデバイス100から送信されたイベント通知メッセージ(イベント情報)に対する逆イベント通知メッセージ(イベント情報)を既に受信しているかどうかを判断する(図9BのステップS709)。そして、MTCデバイス100は、同じ種類のMTCデバイス100から送信されたイベント通知メッセージ(イベント情報)に対する逆イベント通知メッセージ(イベント情報)を既に受信している場合は処理を終了し、一方、同じ種類のMTCデバイス100から送信されたイベント通知メッセージ(イベント情報)に対する逆イベント通知メッセージ(イベント情報)を初めて受信した場合は、高優先度モードで動作を行う(図9BのステップS710)。なお、ステップS710では、MTCデバイス100が高優先度モードだった場合は、送信モード制御部504においてそのまま高優先度モードを維持し、MTCデバイスがノーマルモードだった場合は、高優先度モードに遷移する。このようにして決定された送信モードは、図9Aに図示されている送信モードの確認処理(図9AのステップS603)で参照される。
なお、ステップS705の自デバイス種IDとの一致を確認するタイミング、ステップS708の逆イベント通知メッセージ(イベント情報)から抽出されたデバイス種IDがイベントグループ情報に登録されているかどうかを確認するタイミング、ステップS709の逆イベント通知メッセージ(イベント情報)の受信を既に行っているデバイス種かどうかを確認するタイミングは、順序が異なっていてもよい。
次に、図10を参照しながら、本発明の第2の実施の形態におけるMMEの構成について説明する。図10は、本発明の第2の実施の形態におけるMME120の構成の一例を示す図である。
図10において、MME120は、通信システム(例えば、E−UTRANやUTRAN)上で通信処理を行い、IPなどのパケット通信処理を実施する通信処理部801、受信メッセージが高い優先度で送られてきたイベント通知メッセージであるか判断した後、イベント情報を取得し、取得したイベント情報を記憶するイベント通知メッセージ処理部803、同一イベント、又は、そのイベントによって引き起こされたイベントによる冗長なイベント通知メッセージの受信を抑制するためにイベント通知メッセージから取得したイベント情報を格納した逆イベント通知メッセージをブロードキャスト送信するか判断する逆イベント通知メッセージ処理部802を少なくとも有する。なお、例えば、逆イベント通知メッセージ処理部802が、イベント通知メッセージ処理部803の機能を保持している場合、イベント通知メッセージ処理部803を省略できる。他の機能部も同様に、1つの機能部で上記の機能部を含む場合は、省略してもよい。
なお、MME120において上述の各構成要素が動作を行うことで、MTCデバイス100から、特定のイベントの発生を検知したことを通知するイベント通知メッセージを受信する受信部としての機能、イベント通知メッセージに対する応答として、送信モードをノーマルモードへ遷移するか又はノーマルモードのまま維持するよう指示するメッセージを作成するメッセージ作成部としての機能、メッセージをMTCデバイス100へ送信するメッセージ送信部としての機能を有している。
次に、図10に図示されている構成を有するMME120について、本発明における特徴的な処理を中心に、図11を用いて詳しく説明する。図11は、本発明の第2の実施の形態におけるMME120の処理フローの一例を示すフロー図である。
MME120は、MTCデバイスA100Aから送信されたメッセージを受信し、イベント通知メッセージ処理部803にて、このメッセージが優先度の高いイベント通知メッセージ(イベント情報)@デバイスAであると判断したとする(図11のステップS901)。なお、MME120は、イベント通知メッセージ(イベント情報)@デバイスAだと判断する際に、イベント通知メッセージ(イベント情報)@デバイスAのイベントフラグフィールドを参照してもよい。
続いて、MME120は、イベント通知メッセージ処理部803にて、受信したイベント通知メッセージ(イベント情報)@デバイスAからイベント情報を取得する(図11のステップS902)。そして、MME120は、同一イベント、又は、そのイベントを引き起こした出来事によって引き起こされたイベントによる冗長なイベント通知メッセージの送信を抑制するために逆イベント通知メッセージ(イベント情報)をMTCグループのMTCデバイス100に送信するかどうかを逆イベント通知メッセージ処理部802にて判断する(図11のステップS903)。なお、逆イベント通知メッセージ(イベント情報)を送信するかどうか(あるいは、高優先度モードによる動作を要求するために、どのラベルを逆イベント通知メッセージに付加するか)を判断する際、逆イベント通知メッセージ処理部802に保持されているイベントグループ情報を用いて判断してもよい。また、HLR/HSS125にMTCデバイス100の情報(例えば、サブスクリプションデータ)を問い合わせて判断してもよい。
逆イベント通知メッセージ(イベント情報)を送信すると判断した場合、MME120は、例えば、イベント通知メッセージ(イベント情報)@デバイスAから取得されたデバイス種IDを格納した逆イベント通知メッセージ(イベント情報)をMTCデバイスA100Aが属するMTCグループの全てのMTCデバイス(MTCデバイスB100Bを含む)にブロードキャストで送信する(図11のステップS904)。なお、MME120は、MTCデバイスA100AがMTCグループに属しているかどうかを判断する手段として、イベント通知メッセージ(イベント情報)@デバイスAに格納されているグループID(図5Aには不図示)や、HSS125が保持するサブスクリプションデータを用いてもよい。また、MME120が逆イベント通知メッセージ(イベント情報)を送信する際、MME120はイベント通知メッセージ(イベント情報)@デバイスAから抽出したデバイス種IDを、再度イベント通知メッセージ(イベント情報)@デバイスAを受信した際に逆イベント通知メッセージ(イベント情報)を送信するかどうかを判断する際に用いるパラメータとして使用するため、例えば、逆イベント通知メッセージ処理部802にて記憶することが望ましい。なお、イベント通知メッセージ(イベント情報)@デバイスAから抽出するデバイス種IDは、MTCデバイス100の種類を識別するためのID以外を使用してもよいが、上述のように、各MTCデバイス100が保持するイベントグループ情報に登録されている情報と関連している必要がある。
また、MME120は、逆イベント通知メッセージ(イベント情報)にイベントグループ情報ラベルを付加する場合、特定のデバイスからのイベント通知メッセージ(例えば、煙センサや炎センサ)に対して、事前に定められた特定のラベル名(例えば「火災」)を付加するように構成されていてもよく、また、イベント通知メッセージに含まれているイベント情報やセンシングデータ)、その他の情報などから、付加すべきイベントグループ情報ラベル名を決定してもよい。また、あるMTCデバイス100(例えば、煙センサ)から受信したイベント通知メッセージ(イベント情報)に応じてあるイベントグループ情報ラベル(例えば「火災」)を付加して逆イベント通知メッセージを送信した場合、イベントグループ情報などによって関連付けられている別のデバイス種のMTCデバイス100(例えば、炎センサ)からイベント通知メッセージを所定時間内に受信したときには、その逆イベント通知メッセージ(イベント情報)に同一のラベル名(例えば「火災))を付加するようにしてもよい。
また、MME120は、一定時間後、又は、MTCサーバ150/MTCユーザ160があらかじめ設定した仕様や登録情報、また設定情報などに基づいて、MTCデバイス100又はMME120が保持している情報を解放するためのメッセージ(例えば、NASメッセージで、MTCデバイス100が持つ送信モードの定常化(高優先度モードからノーマルモード、若しくは、ノーマルモードから高優先度モード))を送信してもよい(図11には不図示)。
また、上述の説明では、MME120が逆イベント通知メッセージ(イベント情報)を送信しているが、MTCサーバ150が逆イベント通知メッセージ(イベント情報)を送信することも可能である。なお、本発明の第2の実施の形態において、MTCサーバ150が逆イベント通知メッセージ(イベント情報)を送信する場合のMTCサーバ150の構成は、図10に図示されているMME120の構成と同様であり、ここでは説明を省略する。
同様に、本発明の第2の実施の形態において、MTCサーバ150の処理フローは、図10に図示されているMME120の処理フロー(ずなわち、図11に図示されている処理フロー)と同様であり、ここでは説明を省略する。
次に、図12〜図14を参照しながら、上述した本発明の第1及び第2の実施の形態における各MTCデバイス100の動作とイベントグループ情報について、具体的な例を挙げながら説明する。
図12は、本発明の第1及び第2の実施の形態に係る具体的な例を説明するために、各MTCデバイス100の配置の一例を示す図である。図12には、MTCグループ内に様々なMTCデバイス100(煙センサ、炎センサ、人感センサ、ガスセンサ、水道センサ、水道メータセンサ、地震センサ、ドアロックセンサなど)が多数配置されている状態が模式的に図示されている。図12に図示されているように、例えば、多数のMTCデバイス100が1つの施設内に配置されることで、例えば、施設内で発生し得るイベント(事故や災害など)を監視している。以下では、同一MTCグループ内の多数のMTCデバイス100のうち、2つの煙センサ、2つの炎センサ、2つの人感センサ、1つのドアロックセンサ、1つの水道センサに焦点を当てて、本発明に係る動作について具体的に説明する。
なお、煙センサは、通常は高優先度モードで動作し、煙の発生を検知すると高優先度のイベント通知メッセージを送信するよう構成されているとする。また、炎センサは、通常は高優先度モードで動作し、炎の発生を検知(熱の検知)すると高優先度のイベント通知メッセージを送信するよう構成されているとする。また、人感センサは、通常はノーマルモードで動作し、人の存在の有無の情報をセンシングデータとしてノーマルモードで送信するよう構成されているとする。また、ドアロックセンサは、通常は高優先度モードで動作し、施錠されたドアの開錠を検知すると高優先度のイベント通知メッセージを送信するよう構成されているとする。また、水道メータセンサは、通常はノーマルモードで動作し、水道メータの値(検針値)をセンシングデータとしてノーマルモードで送信するよう構成されているとする。
<図13の(1)>
本発明の第1の実施の形態によれば、例えば、ある煙センサが煙の発生を検知し、MTCサーバ150へイベント通知メッセージを送信すると、MME120からMTCグループ内のすべてのMTCデバイス100へ逆イベント通知メッセージが送信される。
この場合、逆イベント通知メッセージを受信するMTCデバイス100(すなわち、MTCグループ内のすべてのMTCデバイス100)は、ノーマルモードへ遷移する(元々ノーマルモードの場合はそのまま維持)。具体的には、図13の(1)に図示されているように、煙センサ、炎センサ、ドアロックセンサは高優先度モードからノーマルモードへ遷移し、人感センサはノーマルモードを維持し続ける。また、その他のMTCデバイス100(例えば、地震センサや水道センサなど)も、すべてノーマルモードによる動作を行うよう制御される。
<図13の(2)、図14の(A)、(B)>
また、本発明の第2の実施の形態によれば、例えば、ある煙センサが煙の発生を検知し、MTCサーバ150へイベント通知メッセージ(イベント情報)を送信すると、MME120からMTCグループ内のすべてのMTCデバイス100へ逆イベント通知メッセージ(イベント情報)が送信される。この場合、MTCグループ内のすべてのMTCデバイス100は、デバイス種ID「煙センサ」及びイベントグループ情報ラベル名「火災」を含む逆イベント通知メッセージ[煙|火災]を受信する。
逆イベント通知メッセージ[煙|火災]の受信によって、煙センサは、同じデバイス種からイベント通知メッセージ(イベント情報)が送信されたことを把握し、ノーマルモードに遷移する。一方、炎センサは、異なるデバイス種からイベント通知メッセージ(イベント情報)が送信されたことを把握し、そのまま高優先度モードを維持する。また、人感センサは、ラベル名「火災」を含む逆イベント通知メッセージ(イベント情報)を受信することで、ノーマルモードから高優先度モードへ遷移する。また、ドアロックセンサは、自デバイスとは関連性のない逆イベント通知メッセージ(イベント情報)であることを把握し、そのまま高優先度モードを維持する。
さらに、ある炎センサが炎の発生を検知し、MTCサーバ150へイベント通知メッセージ(イベント情報)を送信したとすると、MME120からMTCグループ内のすべてのMTCデバイス100へ逆イベント通知メッセージ(イベント情報)が送信される。この場合、MTCグループ内のすべてのMTCデバイス100は、デバイス種ID「炎センサ」及びラベル名「火災」を含む逆イベント通知メッセージ[炎|火災]を受信する。
逆イベント通知メッセージ[炎|火災]の受信によって、炎センサは、同じデバイス種からイベント通知メッセージが送信されたことを把握し、ノーマルモードに遷移する。一方、煙センサは、同一の出来事(火災の発生)によって引き起こされたイベントの逆イベント通知メッセージ(すなわち、逆イベント通知メッセージ[煙|火災])の受信によってノーマルモードへの遷移を行っているので、そのままノーマルモードを維持し続ける。また、人感センサは、同一の出来事(火災の発生)によって引き起こされたイベントの逆イベント通知メッセージ(すなわち、逆イベント通知メッセージ[煙|火災])の受信によって高優先度モードへの遷移を既に行っているので、そのまま高優先度モードを維持し続ける。また、ドアロックセンサは、自デバイスとは関連性のない逆イベント通知メッセージであることを把握し、そのまま高優先度モードを維持する。
さらに、ある人感センサが人物の存在を検知し、MTCサーバ150へイベント通知メッセージを送信したとすると、MME120からMTCグループ内のすべてのMTCデバイス100へ逆イベント通知メッセージ(イベント情報)が送信される。この場合、MTCグループ内のすべてのMTCデバイス100は、デバイス種ID「人感センサ」及びラベル名「火災」を含む逆イベント通知メッセージ[人感|火災]を受信する。
逆イベント通知メッセージ[人感|火災]の受信によって、人感センサは、同じデバイス種からイベント通知メッセージが送信されたことを把握し、ノーマルモードに遷移する。一方、煙センサ及び炎センサは、同一の出来事(火災の発生)によって引き起こされたイベントの逆イベント通知メッセージ(すなわち、逆イベント通知メッセージ[煙|火災]及び逆イベント通知メッセージ[炎|火災])の受信によってノーマルモードへの遷移を行っているので、そのままノーマルモードを維持し続ける。また、ドアロックセンサは、自デバイスとは関連性のない逆イベント通知メッセージであることを把握し、そのまま高優先度モードを維持する。
図13の(2)のような動作を実現するためには、例えば、図14の(A)に図示されているように、例えば、煙センサにラベル名「火災」のイベントグループ情報(炎センサ及び人感センサのデバイス種IDが登録されている)を持たせ、炎センサにラベル名「火災」のイベントグループ情報(煙センサ及び人感センサのデバイス種IDが登録されている)を持たせ、人感センサにラベル名「火災」のイベントグループ情報(炎センサ及び煙センサのデバイス種IDが登録されている)を持たせればよい。なお、ドアロックセンサなどのような関連性のないMTCデバイス100においては、ラベル名「火災」のイベントグループ情報を持たせないようにしておくか、あるいは、デバイス種IDが登録されていないラベル名「火災」のイベントグループ情報を持たせるようにしておく。
上述の図14の(A)のようなイベントグループ情報の持たせ方によれば、個々のデバイス種によって異なるイベントグループ情報を持たせることになるが、別の方法として、全MTCデバイス100に共通(同一)のイベントグループ情報を持たせるようにすることも可能である。この場合、例えば図9BのステップS708の処理において、逆イベント通知メッセージ(イベント情報)に含まれているデバイス種IDがイベントグループ情報に含まれているかどうかを確認することに加えて、さらに、自デバイス種IDがイベントグループ情報に含まれているかどうかを確認することで、本発明に係る動作が実現可能となる。なお、この場合も、ドアロックセンサなどのような関連性のないMTCデバイス100においては、ラベル名「火災」のイベントグループ情報を持たせないようにしておいてもよい。
図14の(A)のように、個々のMTCデバイス100が異なるイベントグループ情報を持つようにする場合には、モード遷移に関してより詳細な管理を行うことができる。例えば、人感センサが持つラベル名「火災」のイベントグループ情報に、煙センサのみが登録された状態に変更することによって、人感センサは、煙センサのデバイス種IDを含む逆イベント通知メッセージ(イベント情報)を受信した場合には高優先度モードへ遷移するが、炎センサのデバイス種IDを含む逆イベント通知メッセージ(イベント情報)を受信した場合にはノーマルモードをそのまま維持するように設定することが可能となる。なお、このような状態を想定しない場合(特定のイベントに対して、どのデバイス種のMTCデバイス100からイベント通知メッセージが送信された場合であっても、関連するラベルを持っているMTCデバイス100は高優先度モードに遷移する場合)は、自デバイス種がそのラベル名に関連付けられているかどうかを確認するだけでよい。すなわち、各MTCデバイス100のデバイス種IDが登録されているイベントグループ情報を持つ必要はなく、単に、自デバイス種とラベル名(例えば「火災」)とが関連付けられているかどうかを示す情報を持っているだけでよい。一方、図14の(B)のように、MTCデバイス100が共通のイベントグループ情報を持つようにする場合には、どのMTCデバイス100にどのイベントグループ情報を持たせる必要があるかを考慮せずに、全MTCデバイスに対してイベントグループ情報を一括配信して保持させることが可能となる。
<図13の(3)、図14の(C)、(D)>
また、本発明の第2の実施の形態では、複数のイベントグループ情報を設定することで、イベントごと(ラベル名ごと)に、MTCデバイス100のモード遷移を変えることが可能である。例えば、あるドアロックセンサがドアの開錠(不審者侵入の可能性)を検知し、MTCサーバ150へイベント通知メッセージ(イベント情報)を送信すると、MME120からMTCグループ内のすべてのMTCデバイス100へ逆イベント通知メッセージ(イベント情報)が送信される。この場合、MTCグループ内のすべてのMTCデバイス100は、デバイス種ID「ドアロックセンサ」(ここでは、開錠と表記)及びラベル名「侵入」を含む逆イベント通知メッセージ[開錠|侵入]を受信する。
このとき、図13の(3)のように、例えば、逆イベント通知メッセージ[開錠|侵入]の受信によって、人感センサのみモード遷移(ノーマルモードから高優先度モード)させ、その後、人感センサが人物の存在を検知し、MTCサーバ150へイベント通知メッセージ(イベント情報)を送信した場合に、他の人感センサのモードを高優先度モードからノーマルモードに戻す動作を行わせるとする。
このような場合には、MTCデバイス個別にイベントグループ情報を設定する方法において、図14の(C)のように、人感センサにラベル名「侵入」のイベントグループ情報(ドアロックセンサのデバイス種IDが登録されている)を持たせるか、あるいは、MTCデバイス100に共通のイベントグループ情報を設定する方法において、図14の(D)のように、全MTCデバイス100にラベル名「侵入」のイベントグループ情報(人感センサ及びドアロックセンサのデバイス種IDが登録されている)を持たせればよい。この場合、少なくとも人感センサは、ラベル名の異なる複数のイベントグループ情報を保持することになる。
<図13の(4)>
また、上述の本発明の第2の実施の形態では、例えば、デバイス種ID及びイベントグループ情報ラベル(ラベル名)の両方がイベント情報として含まれた逆イベント通知メッセージ(イベント情報)の送信が行われている。しかしながら、イベントグループ情報ラベル(ラベル名)を用いず、イベントグループ情報による詳細な設定が行われないような構成として、デバイス種IDのみを含む逆イベント通知メッセージの送信が行われるようにしてもよい。この方法は、第1の実施の形態における逆イベント通知メッセージによって行われるノーマルモードへのモード遷移の指示を、イベント通知メッセージを送信したMTCデバイス100と同じ種類のMTCデバイスに対してのみ行うものであると言える。また、図9Bの動作(本発明の第2の実施の形態における動作)において、ステップS707〜S709の処理を行わないものであるとも言える。
例えば、ある煙センサが煙の発生を検知し、MTCサーバ150へイベント通知メッセージを送信すると、MME120からMTCグループ内のすべてのMTCデバイス100へ、デバイス種ID「煙センサ」を含む逆イベント通知メッセージ(イベント情報)が送信される。
この場合、MTCグループ内のすべてのMTCデバイス100が、デバイス種ID「煙センサ」を含む逆イベント通知メッセージを受信するが、図13の(4)に図示されているように、この逆イベント通知メッセージに含まれているデバイス種IDと同じ種類のMTCデバイス(すなわち、すべての煙センサ)のみ、モード遷移(ノーマルモードへの遷移)を行う。
<図13の(5)、図14の(E)>
また、上述の本発明の第2の実施の形態では、例えば、デバイス種ID及びイベントグループ情報ラベル(ラベル名)の両方がイベント情報として含まれた逆イベント通知メッセージ(イベント情報)の送信が行われているが、逆イベント通知メッセージ(イベント情報)に、デバイス種IDを挿入せず、イベントグループ情報ラベル(ラベル名)のみを付加することも可能である。この方法は、図9Bの動作(本発明の第2の実施の形態における動作)において、ステップS705の処理を行わないものであると言える。
例えば、ある煙センサが煙の発生を検知し、MTCサーバ150へイベント通知メッセージを送信すると、MME120からMTCグループ内のすべてのMTCデバイス100へ、ラベル名「火災」を含む逆イベント通知メッセージが送信される。
ここで、図14の(E)に図示されているように、人感センサのみが、自デバイス種とラベル名「火災」とが関連付けられていることを示す情報を持っているとする。なお、図14の(E)では、人感センサは、ラベル名「火災」のイベントグループ情報を保持しているのが図示されているように、ラベル名「火災」を含む逆イベント通知メッセージの受信時にモード遷移を行うことが特定できるような情報であれば、情報の持ち方は限定されるものではない。
MTCグループ内のすべてのMTCデバイス100が逆イベント通知メッセージ[火災]を受信するが、例えば、煙センサ、炎センサ、ドアロックセンサなどのMTCデバイス100は、ラベル名「火災」に関連付けられておらず、モード遷移を行わない。一方、人感センサは、ラベル名「火災」に関連付けられており、逆イベント通知メッセージ[火災]の受信によってモード遷移(高優先度モードへの遷移)を行う。
なお、図13の(5)及び図14の(E)の例によれば、人感センサ以外のMTCデバイス100のモードはそのまま維持される一方、人感センサのモードが高優先度モードへ遷移するため、MTCデバイス100からのイベント通知メッセージの送信を抑制できているわけではない。しかしながら、あるMTCデバイス100からイベント通知メッセージが送信されたことを契機として、通常はノーマルモードで動作しているMTCデバイス100(例えば、人感センサ)の送信モードを高優先度モードに変更できるという点において有用である。すなわち、通常はノーマルモードで動作しているMTCデバイス100(人感センサ)を、必要に応じて迅速に高優先度モードに遷移させることが可能となる。
<第3の実施の形態>
上記の実施の形態の解決手法によれば、MTCデバイス100が通知するイベント通知メッセージとMME120が送信する逆イベント通知メッセージは、共にCプレーン上で交換されていたが、MTCデバイス100が通知するイベント通知メッセージはUプレーンで、逆イベント通知メッセージはネットワーク装置(例えば、MME120、MTCサーバ150やPGW140)によってCプレーンが用いられる場合がある。例えば、通信システムのオペレータ、MTCサーバ150やMTCユーザ160によって、静的、若しくは、動的に設定されるMTCサービスの仕様や登録情報、また設定情報などに基づいて、MTCサービスにおけるメッセージは基本的にUプレーン上で交換すると設定されている場合、イベント(例えば、煙発生)を検知したMTCデバイス100は、Uプレーンを用いてイベント通知メッセージをPGW140/MTCサーバ150に通知する。ここで、ネットワーク装置(例えば、PGW140/MTCサーバ150)はMTCサービスの仕様や登録情報、また設定情報などに基づいて、イベント通知メッセージの応答である逆イベント通知メッセージをUプレーンを用いて送信したいが、MME120経由で逆イベント通知メッセージを送信しなければならない場合(例えば、MME120がイベント通知メッセージに格納されているイベント情報(例えば、デバイスID/デバイス種ID)を用いて、MTCデバイス100の管理情報を更新しなければならない場合)がある。このようなケースが、本発明の第3の実施の形態に相当する。
以下、本発明の第3の実施の形態におけるシステム動作の一例について、図15を用いて詳しく説明する。図15は、本発明の第3の実施の形態におけるシステム動作の一例(複数のMTCデバイス100から送信される同一イベント、又は、そのイベントを引き起こした出来事によって引き起こされたイベントによる優先度の高いイベント通知メッセージの送信抑制方法)を説明するためのシーケンス図である。なお、図15には、図1に図示したシステム構成における処理シーケンスの一例を図示する。ここで、MTCデバイス100の特徴は、本発明の第2の実施の形態における特徴と同様であり、ここでは説明を省略する。
以下、図15に図示されているシーケンスについて説明する。ステップS321〜ステップS322は、本発明の第2の実施の形態におけるステップS301〜ステップS302(図4を参照)と同様なので、ここでは説明を省略する。
続いて、MTCデバイスA100Aは、検知したイベント情報(例えば、煙センサID)を格納したイベント通知メッセージ(イベント情報)をUプレーン上で、MTCサーバ150に通知する(ステップS323:イベント通知メッセージ(イベント情報)@デバイスA)。すなわち、MTCデバイスA100Aから通知されるイベント通知メッセージ(イベント情報)@デバイスAは、eNB110、SGW130、PGW140、MTCサーバ150という順に転送される。なお、ここでは、MTCサーバ150が、イベント通知メッセージ(イベント情報)の通知先になっているが、通信システムのオペレータ、MTCサーバ150やMTCユーザ160によって設定される仕様や登録情報、また設定情報などに基づいて、イベント通知メッセージ(イベント情報)の送信先を他のネットワーク装置(例えば、PGW140)にしてもよい。
続いて、MTCサーバ150は、受信したイベント通知メッセージ(イベント情報)からイベント情報を抽出し、逆イベント通知メッセージに格納する。そして、MTCサーバ150は、同一イベント(例えば、煙の発生)、若しくは、そのイベント(例えば、煙発生)を引き起こした出来事(例えば、火災発生)によって引き起こされたイベント(例えば、炎の発生)によるイベント通知メッセージの送信を抑制するために、逆イベント通知メッセージをMME120に送信する。続いて、MME120がCプレーンを用いてMTCグループに属するMTCデバイス100に逆イベント通知メッセージをブロードキャスト(ステップS324:逆イベント通知メッセージ(イベント情報))。なお、ここでは、MME120が逆イベント通知メッセージを生成しているが、他のネットワーク装置(例えば、MTCサーバ150やPGW140が生成してもよい。その場合、MME120でないネットワーク装置(MTCサーバ150やPGW140)がブロードキャストしてもよい。
逆イベント通知メッセージを送信したMME120は、逆イベント通知メッセージに格納されていたイベント情報(例えば、デバイスID)を抽出し、再度逆イベント通知メッセージをブロードキャストするか判断する際に使用するために記憶する(ステップS325:イベント情報の記憶)。なお、ステップS326以降は、本発明の第2の実施の形態のステップS306以降と同様なので、ここでは説明を省略する。
本発明の第3の実施の形態のように、MTCデバイス100が通知するイベント通知メッセージはUプレーンで、ネットワーク装置(例えば、MME120、MTCサーバ150やPGW140)から送信される逆イベント通知メッセージはCプレーンを用いることで、MTCサービスにおけるメッセージが基本的にUプレーンを用いて送信されると設定されている環境において、ネットワーク装置(例えば、PGW140、MTCサーバ150)が、MME120経由(Cプレーン)で逆イベント通知メッセージを送信しなければいけない場合(例えば、MME120がイベント通知メッセージに格納されているイベント情報(例えば、デバイスID/デバイス種ID)を用いて、MTCデバイス100の管理情報を更新しなければならない場合)に対応することができる。
<第4の実施の形態>
本発明の第4の実施の形態では、MTCデバイス100が通知するイベント通知メッセージはCプレーンで、ネットワーク装置(例えば、MTCサーバ150やPGW140)から送信される逆イベント通知メッセージはUプレーンが用いられる場合について説明する。例えば、通信システムのオペレータ、MTCサーバ150やMTCユーザ160によって、静的、若しくは、動的に設定されるMTCサービスの仕様や登録情報、また設定情報などに基づいて、MTCサービスにおけるメッセージが基本的にUプレーンを用いて送信されると設定されている環境において、MTCデバイス100がイベント(例えば、煙発生)を検知したとする。本来であれば、MTCデバイス100はUプレーンを用いて、イベント通知メッセージをPGW140/MTCサーバ150に通知するが、MME120がMTCデバイス100の管理に必要とする情報が伴う場合(例えば、MTCデバイス100が移動可能な煙センサ(例えば、煙発生を検知可能な移動ロボット)であり、イベント情報に加えてMTCデバイス100の位置情報を通知する場合や、MTCサービスがMTCデバイス100の位置情報も付加してイベント情報を通知するMTCサービス(例えば、MTCデバイス100が車などに搭載されていて、イベント検知時、位置情報も付加して送信するサービス)である場合)、あらかじめ通信システムのオペレータ、MTCサーバ150、MTCユーザ160によって設定されている仕様、登録情報や設定情報に基づいて、MTCデバイス100の判断でCプレーンを用いてイベント通知メッセージを通知する場合がある。
以下、本発明の第4の実施の形態におけるシステム動作の一例について、図16を用いて詳しく説明する。図16は、本発明の第4の実施の形態におけるシステム動作の一例(複数のMTCデバイス100から送信される同一イベント、又は、そのイベントを引き起こした出来事によって引き起こされたイベントによる優先度の高いイベント通知メッセージの送信抑制方法)を説明するためのシーケンス図である。なお、図16には、図1に図示したシステム構成における処理シーケンスの一例を図示する。ここで、MTCデバイス100の特徴は、本発明の第2の実施の形態における特徴と同様であり、ここでは説明を省略する。
以下、図16に図示されているシーケンスについて説明する。ステップS341〜ステップS342は、本発明の第2の実施の形態におけるステップS301〜ステップS302(図4を参照)と同様なので、ここでは説明を省略する。
続いて、MTCデバイスA100Aは、検知したイベント情報(例えば、煙センサID)を格納したイベント通知メッセージ(イベント情報)をCプレーン上で、MME120に通知する(ステップS343:イベント通知メッセージ(イベント情報)@デバイスA)。
MME120は、MTCデバイスA100Aからイベント通知メッセージ(イベント情報)@デバイスAを受信し、必要な情報(例えば、MTCデバイスA100Aの位置情報やデバイスIDなど)を抽出し、例えば、MTCデバイスA100Aの管理処理(例えば、MTCデバイスA100Aのコンテキスト情報の更新や、位置情報の更新など)を行う(ステップS344:デバイスA管理処理)。
そして、MME120は、イベント通知メッセージ(イベント情報)@デバイスAに格納されていたイベント情報(例えば、デバイスIDやデバイス種ID)を抽出し、再度逆イベント通知メッセージをブロードキャストするか判断する際に使用するために記憶する(ステップS345:イベント情報の記憶)。
続いて、MME120は、受信したイベント通知メッセージ(イベント情報)をMTCサーバ150に転送する(ステップS346)。このとき、MME120は、通信システムのオペレータ、MTCサーバ150やMTCユーザ160によって設定された仕様、登録情報や設定情報に基づいて、受信したイベント通知メッセージ(イベント情報)@デバイスAをそのまま転送、若しくは、必要な情報(例えば、イベント情報)のみをMTCサーバ150に送信する。なお、ここでは、MTCサーバ150が、イベント通知メッセージ(イベント情報)の通知先になっているが、通信システムのオペレータ、MTCサーバ150やMTCユーザ160によって設定される仕様や登録情報、また設定情報などに基づいて、イベント通知メッセージ(イベント情報)の送信先を他のネットワーク装置(例えば、PGW140)にしてもよい。なお、ステップS344のデバイスA管理処理からステップS346のイベント通知メッセージ(イベント情報)@デバイスAの転送処理は、順不同で実施してもよい。
続いて、MTCサーバ150は、受信したイベント通知メッセージ(イベント情報)からイベント情報を抽出し、逆イベント通知メッセージに格納する。そして、MTCサーバ150は、同一イベント(例えば、煙の発生)、若しくは、そのイベント(例えば、煙発生)を引き起こした出来事(例えば、火災発生)によって引き起こされたイベント(例えば、炎の発生)によるイベント通知メッセージの送信を抑制するために、逆イベント通知メッセージ(イベント情報)をUプレーンを用いてMTCグループに属するMTCデバイス100にブロードキャストする(ステップS347:逆イベント通知メッセージ(イベント情報))。ステップS348以降は、本発明の第2の実施の形態のステップS306以降と同様なので、ここでは説明を省略する。
本発明の第4の実施の形態のように、MTCデバイス100が通知するイベント通知メッセージはCプレーンで、ネットワーク装置(例えば、MTCサーバ150やPGW140)から送信される逆イベント通知メッセージはUプレーンを用いることで、MTCサービスにおけるメッセージが基本的にUプレーンを用いて送信されると設定されている環境において、MTCデバイス100が、MME120経由(Cプレーン)でイベント通知メッセージを送信しなければいけない場合(例えば、MME120がイベント通知メッセージに格納されているイベント情報(例えば、デバイスID/デバイス種ID)やMTCデバイス100の位置情報を用いて、MTCデバイス100の管理情報を更新しなければならない場合)に対応することができる。
<第5の実施の形態>
本発明の第5の実施の形態では、MTCデバイス100が通知するイベント通知メッセージはUプレーンで、ネットワーク装置(例えば、MTCサーバ150やPGW140)から送信される逆イベント通知メッセージも同様にUプレーンが用いられる場合について説明する。すなわち、MTCデバイス100から通知されるイベント通知メッセージ(イベント情報)とネットワーク装置(例えば、MTCサーバ150やPGW140)から送信される逆イベント通知メッセージ(イベント情報)が、共にUプレーン上で交換される場合について説明する。例えば、通信システムのオペレータ、MTCサーバ150やMTCユーザ160によって、静的、若しくは、動的に設定されるMTCサービスの仕様や登録情報、また設定情報などに基づいて、MTCサービスにおける全てのメッセージがUプレーンを用いて送信されると設定されている環境である。すなわち、MTCデバイスA100Aから通知されるイベント通知メッセージ(イベント情報)@デバイスAは、eNB110、SGW130、PGW140、MTCサーバ150という順で転送され、MTCサーバ150から送信される逆イベント通知メッセージ(イベント情報)は、PGW140、SGW130、eNB110、MTCデバイス100という順で転送される。つまり、MME120は介さず、MTCサービスのメッセージが交換される。例えば、MTCサービスにおけるメッセージ(例えば、イベントを検知した情報や、センシングデータなど)は、MTCデバイス100の位置情報などを更新するメッセージ(例えば、TAU、RAU、ページングなど)を除いて、全てアプリケーション情報と解釈し、MTCデバイス100やUE105のモビリティ制御やPDNコネクション・EPSベアラを管理、QoSなどを管理するためのCプレーンではなく、ユーザデータ(アプリケーション情報)を転送するUプレーンでのみ交換しなくてはならないという環境が、本発明の第5の実施の形態に相当する。
以下、本発明の第5の実施の形態におけるシステム動作の一例について、図17を用いて詳しく説明する。図17は、本発明の第5の実施の形態におけるシステム動作の一例(複数のMTCデバイス100から送信される同一イベント、又は、そのイベントを引き起こした出来事によって引き起こされたイベントによる優先度の高いイベント通知メッセージの送信抑制方法)を説明するためのシーケンス図である。なお、図17には、図1に図示したシステム構成における処理シーケンスの一例を図示する。ここで、MTCデバイス100の特徴は、本発明の第2の実施の形態における特徴と同様であり、ここでは説明を省略する。
以下、図17に図示されているシーケンスについて説明する。ステップS361〜ステップS362は、本発明の第2の実施の形態におけるステップS301〜ステップS302と同様なので、ここでは説明を省略する。
続いて、MTCデバイスA100Aは、検知したイベント情報(例えば、煙センサID)を格納したイベント通知メッセージ(イベント情報)をUプレーン上で、MTCサーバ150に通知する(ステップS363:イベント通知メッセージ(イベント情報)@デバイスA)。すなわち、MTCデバイスA100Aから通知されるイベント通知メッセージ(イベント情報)@デバイスAは、eNB110、SGW130、PGW140、MTCサーバ150という順で転送される。なお、ここでは、MTCサーバ150が、イベント通知メッセージ(イベント情報)の通知先になっているが、通信システムのオペレータ、MTCサーバ150やMTCユーザ160によって設定される仕様や登録情報、また設定情報などに基づいて、イベント通知メッセージ(イベント情報)の送信先を他のネットワーク装置(例えば、PGW140)にしてもよい。
続いて、MTCサーバ150は、受信したイベント通知メッセージ(イベント情報)のイベント情報(例えば、デバイスIDやデバイス種ID)を逆イベント通知メッセージに格納し、Uプレーンを用いてMTCグループに属するMTCデバイス100にブロードキャストする(ステップS364:逆イベント通知メッセージ(イベント情報))。
続いて、MTCサーバ150は、同一イベント(例えば、煙の発生)、若しくは、そのイベント(例えば、煙発生)を引き起こした出来事(例えば、火災発生)によって引き起こされたイベント(例えば、炎の発生)によるイベント通知メッセージの送信を抑制するために、イベント通知メッセージ(イベント情報)@デバイスAに格納されているイベント情報(例えば、デバイスIDやデバイス種ID)を記憶する(ステップS365:イベント情報の記憶)。ステップS366以降は、本発明の第2の実施の形態のステップS306以降と同様なので、ここでは説明を省略する。
本発明の第5の実施の形態のように、MTCデバイス100が通知するイベント通知メッセージとネットワーク装置(例えば、MTCサーバ150やPGW140)が送信する逆イベント通知メッセージが共にUプレーンを用いることで、例えばMTCサービスにおけるメッセージ(例えば、イベントを検知した情報や、センシングデータなど)は、MTCデバイス100の位置情報などを更新するメッセージ(例えば、TAU、RAU、ページングなど)を除いて、全てアプリケーション情報と解釈し、MTCデバイス100やUE105のモビリティ制御やPDNコネクション・EPSベアラを管理、QoSなどを管理するためのCプレーンではなく、ユーザデータ(アプリケーション情報)を転送するUプレーン上で交換しなくてはならないという環境に対応することができる。
<第6の実施の形態>
また、上記の各実施の形態では、PGW140をデータゲートウェイとするEPS(Evolved Packet System)アーキテクチャを用いた例について説明したが、それ以外にも、例えばGPRS(General Packet Radio Service)アーキテクチャや、UMTS(Universal Mobile Telecommunications System)アーキテクチャ、またそれらアーキテクチャが混在するような構成においても、同様に実施可能であることは当業者にとって明らかである。
例えば、GPRSアーキテクチャやUMTSアーキテクチャに基づく構成の場合、上述したようなMME120とSGW130の役割をSGSN(Serving GPRS Support Node)が担い、相当する処理を実施する。また、同様にPGW140の役割をGGSN(Gateway GPRS Support Node)が担い、相当する処理を実施する。さらには、PDNコネクションと同等の論理通信路として、PDPコンテキストが用いられる。いくつかのメッセージについては、その表記やシグナリングの手順、またメッセージの順序などが若干異なる場合があるが、本発明による実施においては問題ではない。なお、その他の通信システム(例えば、WLANなどのローカル通信システムやWiMAXなどの広域通信システム、3GPP2などのセルラシステム、その他自営通信システムなど)においても同様に実施可能である。
<第7の実施の形態>
上記の実施の形態では、図1のMTC通信ネットワークの構成において、複数のMTCデバイス100が1つのMTCグループとしてまとめられ、各MTCデバイスが3Gアクセス(例えば、E−UTRAN115)への通信インタフェースを保持し、3Gアクセスを介して、MTCデバイス100が検知したイベントや、センシングデータをMTCサーバ150に送信するアーキテクチャを用いた例について説明した。しかし、それ以外にも、例えば、MTCデバイス100と3Gアクセスとの間にMTCデバイスゲートウェイを設け、MTCデバイスゲートウェイがMTCデバイスから送信されたメッセージを転送するアーキテクチャにおいても実施可能であることが明らかである。本発明の第7の実施の形態におけるMTC通信ネットワークの構成の一例を図18に示す。
図18において、図1と異なる点は、MTCデバイス100とeNB110(3Gアクセス)との間にMTCデバイスゲートウェイ102が存在することである。
図18において、MTCデバイスゲートウェイ102は、3Gアクセス115と通信するための通信インタフェースを1つ以上持つ。さらに、MTCデバイスゲートウェイ102は、複数のMTCデバイス100と通信するための通信インタフェース(例えば、通信バスを設け、そのバスへの通信インタフェースや、有線LANのような通信インタフェースや、Zigbee(ジグビー)(登録商標)や無線LANなどの無線通信プロトコル)を持つ。
一方、MTCデバイス100は、上記の各実施の形態のMTCデバイス100とは異なり、3Gアクセスへの通信インタフェースを持っていなくてもよい。すなわち、MTCデバイス100は、検知したイベント情報やセンシングデータを直接3Gアクセス経由でMTCサーバ150に送信することができなくてもよい。その代わり、MTCデバイス100が検知したイベント情報やセンシングデータは、MTCデバイスゲートウェイ102に送信することで、MTCデバイスゲートウェイ102が3Gアクセスを経由して、ネットワーク装置(例えば、MME120、PGW140やMTCサーバ150)に転送する。このように、MTCデバイスゲートウェイ102が、MTCデバイス100が取得したデータをまとめて送信することで、通信システムのオペレータ、MTCサーバ150やMTCユーザ160は、個別にMTCデバイス100を管理する必要がなくなり、処理負荷とリソースが軽減される。また、3Gアクセスに通信する装置をMTCデバイスゲートウェイ102にまとめることで、例えば、全MTCデバイス100に高価な3Gアクセスへの通信インタフェースを搭載する必要がなくなり、コスト削減を図ることもできる。なお、本発明の第7の実施の形態は、マンションやビル、集合住宅などを監視するシステムを管理する業者において、現実的な実施の形態と言える。
また、第1の実施の形態で説明したように、少なくともMTCデバイスゲートウェイ102が複数のMTCデバイス100から送信されたデータの優先度レベルを確認することができ、ネットワーク側で混雑状態が起こっているとき(例えば、eNB110、MME120やPGW140がオーバーフロー)や、MTCユーザ160が通信システムオペレータと特別な契約(例えば、高額な利用料金の課金ルールを結ぶことで、優先的なデータ転送がされる契約)を保持するとき、又は、オペレータ方針によって一定の優先度レベルを用いたデータ転送の指示が配布されたとき(例えば、優先度レベル3以上はデータ転送可のとき)には、MTCデバイスゲートウェイ102が優先度レベルを確認しながら(例えば、ネットワーク側が示す許容優先度レベルとMTCデバイス100から転送されるデータに格納された優先度レベルを比較する。または、MTCデバイス100やMTCデバイスゲートウェイ102にあらかじめ組み込まれているコンテキスト(例えば、混雑度レベル3のときは優先度レベル3以上のメッセージのみ送信許容などのルールが登録されているコンテキスト)やアプリケーションデータに含まれている優先度レベルを確認する)、転送データの選択をすることで、優先度レベルが高いデータのみネットワーク側へ転送することができる(優先度の低いデータの転送は後回し(例えば、混雑状態の解消後)にすることができる)。これにより、ネットワーク側の混雑状態が起こっている場合でも、MTCユーザ160やMTCサーバ150は、優先的に収集しているデータを受信することができる。
また、MTCデバイス100がMTCデバイスゲートウェイ102の役割を担うことも可能である。この場合、MTCデバイスゲートウェイ102となるMTCデバイス100の負荷が増えることが予想され、負荷を分散する手段が必要となり得る。例えば、MTCデバイスゲートウェイ102の役割を、MTCグループの各MTCデバイス100で順番に(例えば、時間で区切って)担当していくなどして負荷分散することが可能である。
<第8の実施の形態>
上記の実施の形態では、ネットワーク側で混雑状態になる前にネットワーク側の装置(例えば、eNB110、MME120や、SGW130、PGW140、MTCサーバ150)から逆イベント通知メッセージが通知され、MTCデバイス100から送信される冗長なイベント通知メッセージの送信を抑制し、ネットワーク側の混雑状態を回避していた。しかし、既にネットワーク側で混雑状態が起こっているとき、若しくは、あるメッセージ(例えば、PDNコネクション確立リクエストや、転送データ)を受信した時点で混雑状態が起こり始めたときに、UE105などから優先度の高い緊急メッセージ(Emergency requestや、Emergency messageとも呼ばれる)やデータ(アプリケーションメッセージ)、PDNコネクション確立リクエストが送られてきた場合、更なるリソース(U−plane(Uプレーン)、C−plane(Cプレーン)共)が必要となる。例えば、通信システムのエンティティ(例えば、eNB110やMME120、SGW130、PGW140)における処理能力のリソース(例えば、データ転送における処理)や、MTCデバイス100やUE105に割り当てる通信リソースや帯域リソースなどがある。このような課題も解決するために、既に確立済みであるPDNコネクションをUE105やMTCデバイス100、ネットワーク側のエンティティ(例えば、eNB110やMME120、SGW130、PGW140、MTCサーバ150)が保持する優先度レベル(例えば、UE105やMTCデバイス100に割り当てられる優先度レベルや、送信するデータの優先度レベルや、QCIやARP)を用いて選択的に切断すること、あるいは、新規PDNコネクションの確立を制御することで優先度レベルの高いリクエストやメッセージ、アプリケーションのためのリソースを確保する。なお、この本発明の第8の実施の形態は、MTCデバイス100やUE105が多く存在するエリアで起こり得る現実的な実施の形態である。
以下、本発明の第8の実施の形態について、図19〜24を用いて説明する。
ここで、本発明の第8の実施の形態の説明を容易化するために、図19と図20におけるMTCデバイスBとMTCデバイスDとMTCデバイスEとMTCデバイスFは、非特許文献1で定義されている“Time tolerant(タイムトレラント)”(耐時間性)を有していることを前提とする。
この“Time tolerant”の機能を保持しているMTCデバイス100は、ネットワークが混雑状態の場合やオペレータ方針などによって、メッセージ(例えば、PDNコネクション確立リクエストやデータ転送)の送信タイミングを遅らせることができる。この“Time tolerant”の動作について、図19を用いて説明する。図19は、MTCデバイスAとMTCデバイスBとMTCデバイスCが既にPDNコネクションを確立済みで各MTCデバイス100から3Gアクセス側にデータ転送をしており(図19の(A)データ転送)、MTCデバイスDとMTCデバイスEとMTCデバイスFが順次的に、これからPDNコネクションを確立し、3Gアクセス側にデータ転送を行おうとしている状態である(MTCデバイスA〜CはConnected modeであり、MTCデバイスD〜Fは順次的にIDLE modeからConnected modeになろうとしている状態)。このとき、MTCデバイスDがPDNコネクションを確立しようとした際に、3Gアクセス側で混雑状態が発生してしまうとする(例えば、3Gアクセス側で許容できるトラフィック量を超えてしまう)(図19の(F)混雑発生)。この場合、3Gアクセス側は、MTCデバイスDのPDNコネクションの確立を拒絶することを示すPDNコネクション確立拒絶メッセージをMTCデバイスDに返信した後に、3Gアクセス側で混雑状態になっていることを通知するメッセージ(図19の(B)送信制御メッセージ)を対象となるMTCデバイス100(本発明の第8の実施の形態では、MTCデバイスA〜Fである。実環境では、例えば、特定のAPNに接続しているMTCデバイス100、特定のMTCグループに属しているMTCデバイス100、特定のオペレータに属しているMTCデバイス100、特定のエリア(例えば、特定のeNB110やMME120に接続しているMTCデバイス)など)にブロードキャスト送信する。なお、ネットワークが混雑状態を認識するタイミングは、上記のようにMTCデバイスDのPDNコネクション確立要求を受けた際に限定されず、既にPDNコネクションを確立しているMTCデバイスによって送信されたデータによって輻輳が発生した、あるいは発生しそうである場合に、送信制御メッセージを対象となるMTCデバイスが属するエリアへブロードキャスト送信する。なお、(B)送信制御メッセージには、例えば、MTCデバイス100から送信されるメッセージ(例えば、PDNコネクション確立リクエスト)をどのくらい遅らせるかを示す値(例えば、待機時間)が格納されていることとする(図19の(C)待機時間)。待機時間が格納された(B)送信制御メッセージを受信したMTCデバイス100は、“Time tolerant”の機能を保持しているか確認する。
“Time tolerant”の機能を保持しているMTCデバイス100は、(B)送信制御メッセージを受信した後、3Gアクセスから示された値(例えば、待機時間)に基づいて、送信メッセージのタイミングを遅らせることができる(例えば、図19の(D)から(E))。なお、ここでは3Gアクセスから示された値(待機時間)に基づいて送信メッセージのタイミングを遅らせているが、例えばMTCデバイスが値(待機時間)を計算してもよく、また、MTCサーバ150などの外部サーバに値(待機時間)を問い合わせてもよい。
“Time tolerant”の機能を保持していないMTCデバイス100やUE105が(B)送信制御メッセージを受信した場合は、送信メッセージのタイミングを遅らせることができないため、(C)待機時間の間にメッセージ(例えば、PDNコネクション確立リクエストやアプリケーションデータ、Emergency requestや、Emergency message)を送信する。“Time tolerant”を保持していないMTCデバイス100やUE105が送信するメッセージは、(C)待機時間の後に再送信することができない(送信メッセージのタイミングを遅らせることができない)ため、優先度レベルが高いMTCデバイス100やUE105から送信されるメッセージとして送信できるようにする。この優先度レベルが高いMTCデバイス100やUE105から送信されるメッセージをネットワーク側が受け入れられるようにするために、送信メッセージのタイミングを遅らせることができる(優先度レベルが低い)MTCデバイス100(“Time tolerant”の機能を保持するMTCデバイス100)によって確立されたPDNコネクションを切断する((C)待機時間の後にメッセージを送信させる)ことで、リソース(C−plane、U−plane共)を確保する。
“Time tolerant”の機能を保持していないMTCデバイス100とUE105が(B)送信制御メッセージを受信した際、一定の期間(例えば、(B)送信制御メッセージに格納されている値(待機時間)ではなく、MTCデバイス100やUE105にあらかじめ組み込まれている待機時間(固定値))を待機することができる場合、“Time tolerant”の機能を保持しているMTCデバイス100は、“Time tolerant”の機能を保持していないMTCデバイス100より長い時間、メッセージの送信を遅らせることができるものとする。
以下、本発明の第8の実施の形態におけるシステム動作の一例について、図20を用いて詳しく説明する。図20は、本発明の第8の実施の形態におけるシステム動作の一例(既に確立済みであるPDNコネクションをUE105やMTCデバイス100、ネットワーク側のエンティティ(例えば、eNB110やMME120、SGW130、PGW140、MTCサーバ150)が保持する優先度レベル(例えば、UE105やMTCデバイス100に割り当てられる優先度レベルや、送信するデータの優先度レベルや、QCIやARP)を用いて切断することで優先度レベルの高いリクエストやアプリケーションのためのリソース確保方法)を説明するためのシーケンスチャートである。なお、図20には、図1に図示したシステム構成における処理シーケンスの一例を図示する。
MTCデバイスA100AとMTCデバイスB100BとMTCデバイスC100Cは、既にPDNコネクションを確立済みであり、データ転送を行っていることとする(図20のステップS1001A、S1001B、S1001C:PDNコネクション確立済み)。続いて、MTCデバイスD100Dがデータ転送をするためにPDNコネクション確立リクエストをMME120に送信する(図20のステップS1002:PDNコネクション確立リクエスト)。
PDNコネクション確立リクエストを受け、ネットワーク側のエンティティ(例えば、eNB110やMME120など)が、例えば処理能力の許容レベル(閾値)を上回ったかどうか確認することによって、混雑状態を検出する(リソースの確保が必要であることを検出する)(図20のステップS1003:混雑検出)。ここでは、MTCデバイスD100Dから送信されたPDNコネクション確立リクエストを受信することでネットワーク側のエンティティ(例えば、eNB110やMME120など)が混雑状態を検出しているが、データ転送をしているMTCデバイス100(本発明の第8の実施の形態では、MTCデバイスA〜C)によって送信されるデータサイズ(送信されているデータの総量)の増加などによって、ネットワーク側のエンティティが混雑状態を検出してもよい。
また、本実施の形態の説明を容易化するために、MME120が混雑状態を検出しているが、他のエンティティ(例えば、eNB110やSGW130、PGW140、MTCサーバ150)が混雑状態を検出してもよい。その場合、各エンティティがMTCデバイスD100Dに混雑状態が起こっていることを直接通知してもよいし、MME120やeNB110などに通知することで、間接的に通知してもよい(例えば、PGW140が混雑状態を検出し次第、MME120に混雑状態を通知し、MME120はMTCデバイスD100DからPDNコネクション確立リクエストが送信されてきた際に、混雑状態をMTCデバイス100に通知してもよい)。
混雑状態を検出したMME120は、PDNコネクションを確立できないことを通知するためにPDNコネクション確立リクエスト拒絶メッセージをMTCデバイスD100Dに送信する(図20のステップS1004:PDNコネクション確立リクエスト拒絶)。続いて、eNB110は、対象となるMTCデバイス100(例えば、特定のAPNに接続しているMTCデバイス、特定のMTCグループに属しているMTCデバイス、特定のオペレータに属しているMTCデバイス、特定のエリア(例えば、特定のeNB110やMME120に接続しているMTCデバイス)など)に送信制御メッセージをブロードキャストする(図20のステップS1005、S1006:送信制御メッセージ)。対象となるMTCデバイス100の決定は、例えば、ステップS1005のブロードキャストメッセージ指示でMME120がeNB110に指示してもよい。このとき、MME120はeNB110やSGW130、PGW140、MTCサーバ150に指示を問い合わせてもよい。
なお、eNB110が対象となるMTCデバイス100にブロードキャスト送信する際、従来技術であるページングメッセージ(Paging)やMBMS(Multimedia Broadcast And Multicast Service)を用いてよい。また、ここでは、本実施の形態の説明を容易化するために、MME120がeNB110にブロードキャストメッセージを指示し、eNB110が対象デバイスにブロードキャストしているが、他のエンティティがブロードキャストメッセージを指示し、ブロードキャスト送信してもよい(例えば、PGW140がeNB110にブロードキャストメッセージ指示し、eNB110がブロードキャスト送信)。
また、MME120によるメッセージの送信処理(ステップS1004とステップS1005)の順序は、入れ替わってもよい。さらに、ステップS1005において送信制御メッセージをブロードキャストすることで、MTCデバイスD100DのPDNコネクション確立リクエストの拒絶を通知することができるのであれば、ステップS1004を省略してもよい。
送信制御メッセージを受信したMTCデバイス100は、“Time tolerant”の機能を保持しているか確認する。MTCデバイス100が、“Time tolerant”の機能を保持している場合、PDNコネクション確立リクエストを送信するタイミングを送信制御メッセージに格納されている待機時間に基づいて遅らせる。“Time tolerant”の機能を保持していないMTCデバイス100は、送信メッセージのタイミングを遅らせることができないので、ネットワーク側で混雑状態が起こっている場合でもPDNコネクション確立リクエストを送信する。
このように、MTCデバイス100からのPDNコネクション確立リクエストの送信を回避することで、通信システムの処理負荷が軽減され、C−planeのリソースは確保できる。しかしながら、既にPDNコネクションを確立しているMTCデバイス(MTCデバイスA100A〜MTCデバイスC100C)のデータ転送が完了するまで、U−planeのリソースに空きは生じない。さらに、上記したようにUE105などから優先度の高い緊急メッセージ(Emergency requestや、Emergency messageとも呼ばれる)やアプリケーションメッセージが送られてくることで、優先度レベルの高いUE105やMTCデバイス100用の更なるリソース(U−plane、C−plane共)が必要となることがある。
そこで、MTCデバイス100の優先度レベルを用いて、既に確立済みであるPDNコネクションを選択的に切断することで優先度レベルの高いPDNコネクション確立リクエストやアプリケーションデータの転送のためのU−planeのリソースを確保する。この優先度レベルを判別するためにも、例えば、“Time tolerant”の機能を保持しているMTCデバイス100であるかどうかをMTCデバイス100に確認させる。
そこで、eNB110がブロードキャスト送信する送信制御メッセージに「“Time tolerant”の機能を保持するMTCデバイス100は確立済みPDNコネクションを切断する」よう指示するパラメータを格納する。“Time tolerant”の機能を保持するMTCデバイス100は、例えば、eNB110からブロードキャスト送信される送信制御メッセージの受信後、確立済みのPDNコネクションを切断する。また、MTCデバイス100は、送信制御メッセージから一定時間(例えば、3Gアクセスから示された値(例えば、待機時間))経過後、再度PDNコネクションを確立し、データ転送を行ってもよい。
図21は、図20のステップS1006において、eNB110が対象となるMTCデバイス100にブロードキャスト送信する送信制御メッセージであり、「“Time tolerant”の機能を保持するMTCデバイス100は確立済みPDNコネクションを切断する」よう指示するパラメータと、「更に付加される詳細な条件」を示したパラメータが格納されるメッセージ構成の一例として、送信制御メッセージのフォーマット例を示す図である。
図21は、ブロードキャスト送信するために必要となるヘッダフィールドと「“Time tolerant”の機能を保持するMTCデバイス100は確立済みPDNコネクションを切断する」ことを示したTime tolerantフィールドとさらに詳細な情報を用いてPDNコネクションの維持/切断を判断する際に用いる詳細な条件(詳細データ)が格納される詳細データフィールドで構成される。詳細データフィールドには、従来技術のAPNや位置情報(例えば、eNB IDやeNBアドレス)、MTCグループを識別するグループID、接続しているネットワークオペレータを識別するPLMN IDに加えて、確立済みのPDNコネクションを用いて転送するデータのデータ残量(データ残量値)や予想完了時間(予想完了時刻)、残時間、PDNコネクション(EPSベアラ)のQCI(QoS Class Indicator)やARP(Allocation and Retention Priority)、データ転送を開始した時刻(以降、“Before time”とも呼ぶ)、MTC feature(例えば、非特許文献1で定義されている着信しかできない“Mobile originated only”の機能を保持しているMTCデバイス100)などを格納することができる。MTCデバイス100は、確立済みのPDNコネクションを維持/切断する判断条件として、MTCデバイス100が“Time tolerant”の機能を保持しているかに加えて、詳細データフィールドに格納されている詳細な判断条件を用いることができる。つまり、この詳細データフィールドを用いることで、論理演算を用いて説明すると「“Time tolerant”の機能を保持しているMTCデバイス100」AND「詳細データ」や、「“Time tolerant”の機能を保持しているMTCデバイス100」OR「詳細データ」や、「“Time tolerant”の機能を保持しているMTCデバイス100」EXOR「詳細データ」の結果で、確立済みのPDNコネクションの維持/切断を決定することができる。なお、MTCデバイス100やUE105、通信システムのエンティティが、優先度レベルの低いMTCデバイス100、又は、アプリケーションであることを示すパラメータ(例えば、“Low priority indicator”)を認識できる場合は、「“Low priority”の機能を保持するMTCデバイス100は確立済みPDNコネクションを切断する」ことを示したパラメータと置き換えてもよい(代わりに使用してもよい)。
例えば、「“Time tolerant”の機能を保持しているMTCデバイス100」であり、「“Mobile originated only”の機能を保持しているMTCデバイス100」によって確立されたPDNコネクションのみ切断する。または、「“Time tolerant”の機能を保持しているMTCデバイス100」、もしくは、「“Mobile originated only”の機能を保持しているMTCデバイス100」によって確立されたPDNコネクションは切断する。または、「“Time tolerant”の機能を保持しているMTCデバイス100」であり、「“Mobile originated only”の機能を保持しているMTCデバイス100」によって確立されたPDNコネクションと、「“Time tolerant”の機能を保持しているMTCデバイス100」と「“Mobile originated only”の機能を保持しているMTCデバイス100」でもないMTCデバイス100によって確立されたPDNコネクションは切断するというように定義してもよい。
また、例えば詳細データフィールドにBefore timeを格納することで、“Time tolerant”の機能を保持しているMTCデバイス100であり、Before timeで示された値(時刻)以降にPDNコネクションを確立、若しくは、データ送信を開始したMTCデバイス100である場合、確立済みのPDNコネクションを切断すると定義してもよい。このとき、Before timeは、例えば「AM11:00」のように値(時刻)を示してもよい。また、Before timeは、「Before timeで示された値(時刻)以内にPDNコネクションを確立したMTCデバイス、若しくは、データ転送を開始してから経過した時間」のように指示することもでき、その場合は、例えば「1分」のように値(時刻)を示してもよい。
また、例えば詳細データフィールドに転送するデータのデータ残量(データ残量値)を格納することで、“Time tolerant”の機能を保持しているMTCデバイス100であり、MTCデバイス100によって送信されるデータの残量がネットワーク側から指示されたデータ残量値を超えてしまっている場合は、確立済みのPDNコネクションを切断すると定義してもよい。このとき、データ残量値は、例えば「1M Bytes」のように値を示してもよい。
また、例えば詳細データフィールドに予想完了時間(残時間)を格納することで、“Time tolerant”の機能を保持しているMTCデバイス100であり、MTCデバイス100が予想するデータ送信の予想完了時間(残時間)がeNB110からブロードキャスト送信された送信制御メッセージに格納されている予想完了時間(残時間)を超えてしまっている場合は、確立済みのPDNコネクションを切断すると定義してもよい。このとき、予想完了時間は、例えば「AM11:15」、残時間は「1分」のように値を示してもよい。また、この予想完了時間や残時間は、例えば、データダウンロード完了までの時間を表わすアプリケーションなどから取得できる情報を利用してもよい。
また、例えば詳細データフィールドにQCIやARPを格納することで、“Time tolerant”の機能を保持しているMTCデバイス100であり、現在送信しているデータで用いているPDNコネクションやEPSベアラのQCIやARPが、詳細データフィールドで示された値以下である場合、該当するPDNコネクションを切断するというように定義してもよい。通信システムのエンティティ(例えば、eNB110やMME120、SGW130、PGW140)やMTCサーバ150が詳細データフィールドに格納するQCIやARPは、例えばSubscription dataやMTCデバイス100の情報が登録されているコンテキスト、課金ルールなどを管理しているPCRF(Policy and Charging Rules Function、図1には不図示)から取得したデータなどを用いて決定してもよい。例えば、MME120がHSS125から送信制御メッセージの送信対象先であるMTCデバイス100のSubscription dataを取得し、確立されているPDNコネクションの平均QCIやARPを導き出し、現在の混雑状態と照らし合わせて、詳細データフィールドに格納するQCIやARPを決定してもよい。
MTCデバイス100は、上記したような詳細データフィールドに格納されているPDNコネクションを切断するための詳細な判断条件を用いるために、例えば、Before timeが格納される場合は、Before timeを用いるためにMTCデバイス100はデータ転送を開始した時刻や、PDNコネクションを確立した時刻を記憶、若しくは、その時点からタイマーを起動し、eNB110からブロードキャスト送信された送信制御メッセージを受信するまでの時間を計測してもよい。
また、詳細データフィールドにデータ残量(データ残量値)が格納される場合は、MTCデバイス100は、現在送信しているデータの残りを把握しておく必要がある。例えば、MTCデバイス100は送信予定のデータ総量(例えば、50M Bytes)と送信済みデータ量を記憶しておくことで、データ残量を計算してもよい。
また、詳細データフィールドに予想完了時間(あるいは、予想完了時刻)や残時間が格納される場合は、MTCデバイス100は、現在送信しているデータの予想完了時間や、送信完了するまでに要する時間を把握しておく必要がある。例えば、MTCデバイス100は送信予定のデータ量(例えば、50M Bytes)と送信レート(例えば、1Mbps)と送信済みデータ量(例えば、40M Bytes)を把握しておき、データ転送の予想完了時間(現時刻がAM11:00とすると、データ転送の予想完了時刻(50M Bytes―40M Bytes)×8bits÷1Mbps=80秒なので、AM11:01 20秒)や残時間(80秒)を見積もってもよい。上記式は、単純に計算した式の例であり、実環境におけるパケットロス率などを考慮した式を用いてもよい。また、このような予想完了時間や残時間は、起動しているアプリケーションから取得してもよい。
また、詳細データフィールドにQCIやARPが格納される場合は、MTCデバイス100は、現在使用しているPDNコネクションのQCIやARPを把握しておく必要がある。例えば、MTCデバイス100は、PDNコネクション(EPSベアラ)を確立した際(例えば、Attach procedure中や、Bearer modification procedure中)にネットワーク側のエンティティ(例えば、eNB110、MME120、SGW130、PGW140、HSS125)からQCIやARPを取得し、ネットワーク側からブロードキャスト送信される送信制御メッセージに格納されるQCIやARPと比較してもよい。
また、詳細データフィールドにMTC featureが格納される場合は、MTCデバイス100は、搭載しているMTC featureを把握しておく必要がある。例えば、MTCデバイス100は、MTCデバイス100コンテキストを持ち、そのコンテキストの中に各MTCデバイス100が搭載する全てのMTC featureを登録してもよい。または、MTCデバイス100が3GアクセスとPDNコネクションを確立する際(例えば、Attach procedure中)、ネットワーク側からMTCデバイス100が保持できるMTC feature、もしくは、MTCサーバ/ユーザから指示されているMTC featureをMTCデバイス100に通知することで、MTCデバイス100が搭載しているMTC featureを把握してもよい。
なお、詳細データフィールドを用いずに、Time tolerantフィールドのみでPDNコネクションの維持/切断を判断する場合は、例えば図21に図示されているフォーマットから詳細データフィールドを省略してもよい。
また、「“Time tolerant”の機能を保持するMTCデバイス100は確立済みPDNコネクションを切断する」ことを通知するために、従来技術のページングとSIB(System Information Block)を用いてもよい。例えば、MTC用のSIBを新たに設ける、若しくは、既存のSIBを改良して、MTCデバイス100にそのSIBを読み出すように指示することで、「“Time tolerant”の機能を保持するMTCデバイス100は確立済みPDNコネクションを切断する」ことを通知してもよい。また、従来技術のMBMS(Multimedia Broadcast And Multicast Service)を用いて、各MTCデバイス100に通知してもよい。
「“Time tolerant”の機能を保持するMTCデバイス100は確立済みPDNコネクションを切断する」ことを通知されたMTCデバイス100は、自分自身が“Time tolerant”の機能を保持しているかどうかを確認する。
MTCデバイス100が、“Time tolerant”の機能を保持しており、かつ、既にPDNコネクションを確立済みである場合には、PDNコネクションを切断する(図20のステップS1007:PDNコネクションリリース)。なお、ここではMTCデバイス100が、“Time tolerant”の機能を保持していて、既にPDNコネクションを確立済みである場合、即座にPDNコネクションを切断しているが、例えばMTCデバイスと通信システムのポリシや、アプリケーションの仕様などに基づいて、切断のタイミングを見計らってもよい。また、MTCデバイス100と通信システムのエンティティ(例えば、eNB110やMME120、SGW130、PGW140)は、PDNコネクションを切断する際、完全に切断するのではなく、再度PDNコネクションを確立する際の時間短縮や処理負荷軽減のために以前の状態(例えば、MTCデバイス100のIPアドレス、IMSI、IMEI、鍵情報)を一定期間、各装置で保持して再利用してもよい。
また、図20の例では、MTCデバイスB100Bが、“Time tolerant”の機能を保持しており、かつ、既にPDNコネクションを確立済みのMTCデバイス100に該当する。すなわち、MTCデバイスB100Bは、ステップS1006の送信制御メッセージを受信すると、確立済みのPDNコネクションを切断する。なお、このとき、MTCデバイスB100Bは、確立したPDNコネクションを切断するために、非特許文献3で定義されているUE−initiated Detach ProcedureやUE requested bearer resource modification procedureなどの従来技術に係る処理を用いてもよい。
また、“Time tolerant”を保持しておらず、PDNコネクションが確立済みのMTCデバイス100(図20の例では、MTCデバイスA100AとMTCデバイスC100Cに相当)は、PDNコネクションをそのまま維持する。また、“Time tolerant”を保持していて、PDNコネクションを保持しておらず、これからメッセージ(例えば、PDNコネクション確立リクエスト)を送信しようとしていたMTCデバイス100(MTCデバイスE100EやMTCデバイスF100Fに相当)は、上記で説明したように(例えば、図19の(D)から(E))、メッセージの送信タイミングを遅らせる。
また、その後、UE105などから優先度の高い緊急メッセージ(Emergency requestや、Emergency messageとも呼ばれる)やアプリケーションメッセージが送られてくる場合、若しくは、メッセージを送るためのPDNコネクション確立リクエストが送られてくる場合(図20のステップS1008:データ送信/PDNコネクション確立リクエスト)がある。この場合、UE105は、メッセージを送信することが可能である。ステップS1007で、MTCデバイスBが確立済みのPDNコネクションを切断したことによってリソース(C−plane、U−plane共)が確保されたため、ネットワーク側はステップS1008のUEによるデータ送信、若しくは、PDNコネクション確立リクエストを受け入れることができる。
なお、本発明の第8の実施の形態では、“Time tolerant”の機能を保持するMTCデバイス100のみを対象とするのではなく、APNやMTCグループのグループID、ネットワークオペレータを識別するPLMN ID(Public Land Mobile Network ID)、デバイス種ID、デバイスIDなどと組み合わせて使用してもよい。
また、本発明の第8の実施の形態は、MTCデバイス100が送信制御メッセージ受信後に確立したPDNコネクションを切断しているが、通信システムのエンティティ(例えば、eNB110やMME120、SGW130、PGW140)やMTCサーバ150が、Subscription dataやMTCデバイス100特有のコンテキスト、メッセージ交換(例えば、Attach procedure)時などの情報から、切断すべきPDNコネクション(“特定のPDNコネクション”)を確認することができるのであれば、通信システムのエンティティ(例えば、eNB110やMME120、SGW130、PGW140)やMTCサーバ150主導でPDNコネクションを切断してもよい。このとき、非特許文献3で定義されているPDN GW initiated bearer deactivationやMME−initiated Detach procedureなどの従来技術に係る処理を用いてもよい。例えば、通信システムのエンティティ(例えば、eNB110やMME120、SGW130、PGW140)やMTCサーバ150が、優先度の高いUE105やMTCデバイス100のためのリソースを確保するために算出、若しくは、取得したPDNコネクションを切断するための条件(例えば、“Time tolerant”の機能を保持するMTCデバイス100で、Before timeで示される値に該当するMTCデバイス100)と、記憶していたMTCデバイス100によってPDNコネクションが確立された時刻を比較し、切断すべきPDNコネクションを確認することができる場合がある。
次に、図22を参照しながら、本発明の第8の実施の形態におけるMTCデバイス100の構成について説明する。図22は、本発明の第8の実施の形態におけるMTCデバイス100の構成の一例を示す図である。
図22において、MTCデバイス100は、通信システム(例えば、E−UTRANやUTRAN)と接続して下位レイヤにおける通信処理と上位レイヤでIPなどのパケット通信処理を実施する通信処理部1110、ネットワーク側からブロードキャスト送信された送信制御メッセージのTime tolerantフィールドと詳細データフィールドを処理するブロードキャストメッセージ処理部1120、ブロードキャストメッセージ処理部1120の結果に基づいて、既に確立済みのPDNコネクションを維持/切断するPDNコネクション処理部1130を少なくとも有する。
また、送信制御メッセージの詳細データフィールドに情報が格納される場合は、詳細データ処理部1140を設けてもよい。詳細データ処理部1140は、例えば、Before timeを用いてデータ送信開始時間でPDNコネクションの切断をする場合、MTCデバイス100内でデータ送信を開始した時間を記憶する機能やタイマー機能を有する。詳細データ処理部1140は、既存の処理部(例えば、ブロードキャストメッセージ処理部1120)に組み込んでもよい。
次に、図22に図示されている構成を有するMTCデバイス100について、本発明における特徴的な処理を中心に、図23を用いて詳しく説明する。
図23において、MTCデバイス100は、eNB110からブロードキャスト送信されたメッセージ(送信制御メッセージ)を受信する(図23のステップS1210)。MTCデバイス100は、MTCデバイス100自身がPDNコネクションを切断するMTCデバイス100であるかを確認するために、ブロードキャストメッセージ(送信制御メッセージ)のTime tolerantフィールドと詳細データフィールドに格納されている情報をブロードキャストメッセージ処理部1120で取得する(図23のステップS1220)。
MTCデバイス100は、受信したブロードキャストメッセージの送信対象に自分が含まれていないと判断した場合には、特別な処理は行わずに終了する。
一方、MTCデバイス100が、受信したブロードキャストメッセージの送信対象に自分が含まれていると判断した場合には、MTCデバイス100と通信システムの間にPDNコネクションを確立済みであるかどうかを更に確認する(図23のステップS1230)。なお、MTCデバイス100が、ブロードキャストメッセージの送信対象に自分が含まれているかどうかを判断する処理フロー(図23のステップS1220の処理)の詳細については後述する(図24を参照)。
MTCデバイス100と通信システム間にPDNコネクションが確立されていない場合、MTCデバイス100はPDNコネクション未確立時の動作(例えば、“Time tolerant”の機能を保持しているMTCデバイス100は、PDNコネクション確立リクエストの送信タイミングを遅らせる)を実施して(図23のステップS1240)、終了する。
一方、MTCデバイス100と通信システム間に、既にPDNコネクションを確立されている場合、MTCデバイス100は、PDNコネクション処理部1130で、例えば非特許文献3で定義されているUE−initiated Detach ProcedureやUE requested bearer resource modification procedureなどを用いて、確立済みのPDNコネクションを切断する(図23のステップS1250)。
次に、詳細データフィールドに格納された値を用いてPDNコネクションを維持/切断する際の詳細な流れについて説明する。例えば、詳細データフィールドにデータ転送を開始してから経過した時間を示す“Before time”が格納されている場合について、図24を用いて詳しく説明する。なお、図24は、図23のステップS1220の処理の詳細について説明するためのものである。
図24において、MTCデバイス100は、eNB110からブロードキャスト送信されたメッセージ(送信制御メッセージ)を受信する(図24のステップS1210)。続いて、MTCデバイス100は、MTCデバイス100自身がPDNコネクションを切断するMTCデバイス100であるかを確認するために、ブロードキャストメッセージ(送信制御メッセージ)のTime tolerantフィールドを確認する(図24のステップS1221)。このとき、MTCデバイス100は、例えば、製造時に設定された情報(例えば、MTC featureの一覧が登録されているMTCデバイス100コンテキスト)やAttach procedure中にネットワーク側から通知される情報(例えば、通信システムのオペレータから設定されるMTC featureや、MTC Userから設定されるMTC feature)などから、自分自身が“Time tolerant”の機能を保持しているか確認してもよい。
MTCデバイス100は、自分自身が“Time tolerant”の機能を保持していないと判断した場合には、特別な処理は行わずに終了する。
一方、MTCデバイス100が、自分自身が“Time tolerant”の機能を保持していると判断した場合には、続いて、送信制御メッセージの詳細データフィールドで示されたBefore timeの値(時刻)を取得する。ここでは、MTCデバイス100が既にPDNコネクションを確立済みであると仮定し、MTCデバイス100はPDNコネクションを確立した時刻や、確立したPDNコネクションで行うデータ転送の開始時刻を記憶、若しくは、タイマーを起動し、送信制御メッセージを受信するまでの時間を計測しているとする。
MTCデバイス100は、送信制御メッセージの詳細データフィールドで示されたBefore timeの値(時刻)と記憶(若しくは、計測)した値(時刻)の比較を行い、PDNコネクションの切断を判断する(図24のステップS1222)。例えば、送信制御メッセージの詳細データフィールドで示されたBefore timeの値(時刻)が「AM11:00」であり、MTCデバイス100が記憶(若しくは、計測)した値(時刻)が「AM10:55」であった場合(送信制御メッセージで示された時刻>MTCデバイス100内で記憶(計測)した時刻という条件に当てはまらない場合)、ネットワーク側が判断した値(時刻)より前から通信を開始し始めていたということで、送信制御メッセージの送信対象に自分が含まれていないと判断し、その結果、特別な処理は行わずにPDNコネクションを維持する。なお、この「AM11:00」のような形式ではなく、「1分前」のような形式でもよい。
一方、送信制御メッセージで示された時刻>MTCデバイス100内で記憶した時刻の条件に当てはまる場合には、ネットワーク側が判断した値(時刻)より後に通信を開始し始めたということで、送信制御メッセージの送信対象に自分が含まれていると判断し、その結果、確立済みのPDNコネクションを切断する(図24のステップS1230、ステップS1240)。
また、この詳細データフィールドを用いたPDNコネクションの切断について、Before timeを例に挙げて説明したが、他のデータ残量や残時間などについても同様な処理(例えば、図24のステップS1222はBefore timeを用いて説明しているが、送信制御メッセージで示されたデータ残量値>MTCデバイス内で計算したデータ残量値など)が行われる。また、Before timeとデータ残量を組み合わせることによって、さらにPDNコネクションの維持/切断に用いる詳細な判断条件にできる。例えば、Before timeを用いて、PDNコネクションを切断するか絞り込みをした後に、その中でデータ残量がどれくらいかによってPDNコネクションを切断するかを判断してもよい。
また、本発明の第8の実施の形態を非特許文献6で定義されているLow priority indicatorと組み合わせることで、ネットワーク側で混雑状態が起こっている際、最初にLow pirority indicatorを持つMTCデバイス100によって確立されたPDNコネクションを切断し、続いて“Time tolerant”の機能を持つMTCデバイス100によって確立されたPDNコネクションを切断するというように、段階的にPDNコネクションを切断することができる。これにより、リソースを段階的に確保することができ、過剰なPDNコネクションの切断を回避することができる。例えば、通信システムのエンティティ(例えば、eNB110やMME120、SGW130、PGW140、HSS)が、Low priority indicatorが格納されたPDNコネクション確立リクエストを送信してきたMTCデバイス100を、例えば、MTCデバイスコンテキストに登録、または、Subscription dataに登録するなどによって把握しておき、上記処理を実現させてもよい。また、通信システムのエンティティが、Low priority indicatorを持つMTCデバイス100を把握することによって、ブロードキャスト送信する送信制御メッセージの送信先をLow priority indicatorを持つMTCデバイス100のみと指定してもよい。
また、Low priority indicatorとの組み合わせではなく、Time tolerantフィールドの代わりにLow priority indicatorフィールドを用いて、切断すべきPDNコネクションを決定してもよい。このとき、Low priority indicatorフィールドは、詳細データフィールドと組み合わせて使用してもよい。
例えば、MME120が混雑状態を検知した場合、最初にLow priority indicatorを持つMTCデバイス100によって確立されたPDNコネクションを切断する指示をeNB110に送信し、eNB110が対象となるMTCデバイス100に送信制御メッセージをブロードキャストする。送信制御メッセージを受信し、かつ、Low priority indicatorを持つMTCデバイス100は、確立済みのPDNコネクションを切断する。
ここで、リソースの確保が十分でないと判断された場合(例えば、混雑状態を示す閾値を超えている場合など)、MME120がTime tolerantフィールド(例えば、「“Time tolerant”の機能を保持している」)と詳細データフィールド(例えば、「“Mobile Originated only”」)を用いて、確立済みのPDNコネクションを切断するとeNB110に通知し、eNB110が対象となるMTCデバイス100にブロードキャスト送信する。送信制御メッセージを受信し、かつ、“Time tolerant”と“Mobile Originated only”の機能を持つMTCデバイス100は、確立済みのPDNコネクションを切断する。これにより、リソースを段階的に確保することができ、過剰なPDNコネクションの切断を回避することができる。
本発明の第8の実施の形態では、一部のMTCデバイス100(MTCデバイスB100B、MTCデバイスD100D、MTCデバイスE100E、MTCデバイスF100F)が“Time tolerant”の機能を保持していることを前提としているが、全てのMTCデバイス100が“Time tolerant”の機能を保持している場合にも適用できる。
全てのMTCデバイス100が、“Time tolerant”の機能を保持している場合、“Time tolerant”の機能を保持しているか否かでPDNコネクションの切断を判断することができなくなるので、図21の詳細データフィールドに格納される判断条件を用いて、PDNコネクションの切断を判断する。例えば、全てのMTCデバイス100が“Time tolerant”の機能を保持している環境において、“Time tolerant”の機能を保持し、“Mobile Originated only”の機能も保持しているMTCデバイス100によって確立されたPDNコネクションを切断するというブロードキャストメッセージは、“Mobile Originated only”の機能を保持しているMTCデバイス100によって確立されたPDNコネクションは切断するという送信制御メッセージになる。同様に、全てのMTCデバイス100が、“Time tolerant”の機能を保持している環境において、Time tolerant”の機能を保持し、「送信制御メッセージで示された時刻>MTCデバイス100内で記憶した時刻」の条件に当てはまる場合には、確立済みのPDNコネクションを切断するという送信制御メッセージは、「送信制御メッセージで示された時刻>MTCデバイス100内で記憶した時刻」の条件に当てはまるMTCデバイス100によって確立されたPDNコネクションは切断するという送信制御メッセージになる。そのため、eNB110がブロードキャスト送信する送信制御メッセージにおいて、“Time tolerant”の機能を保持するMTCデバイス100であるか否かを識別するための図21のTime tolerantフィールドは省略できる。
以上、本発明の第8の実施の形態によれば、既にネットワーク側で混雑状態が起こっているとき、若しくは、あるメッセージ(例えば、PDNコネクション確立リクエストや、転送データ)を受信した時点で混雑状態が起こり始めたときに、UE105などから優先度の高い緊急メッセージ(Emergency requestや、Emergency messageとも呼ばれる)やアプリケーションメッセージが送られてくることで更なるリソース(U−plane、C−plane共)が必要となる課題に対して、ネットワーク側からブロードキャスト送信されるメッセージで、MTCデバイス100が“Time tolerant”の機能を保持しており、そして、詳細データフィールドで示される値(例えば、“Before time”で示されるデータ転送を開始してから経過した時間)を用いて、既に確立済みであるPDNコネクションの維持/切断をする。これにより、優先度レベルの高いリクエストやアプリケーションのためのリソースを確保することができる。
また、ネットワーク側(例えば、eNB110やMME120、SGW130、PGW140、MTCサーバ150)から対象となるMTCデバイス100(例えば、特定のAPNに接続しているMTCデバイス100、特定のMTCグループに属しているMTCデバイス100、特定のオペレータに属しているMTCデバイス100、特定のエリア(例えば、特定のeNB110やMME120に接続しているMTCデバイス100)など)にメッセージがブロードキャストされることによって、メッセージ(例えば、PDNコネクション確立リクエスト)を送信しようとしていたMTCデバイス100からのメッセージを回避することができる。それにより、ネットワーク側のエンティティ(例えば、eNB110やMME120、SGW130、PGW140、MTCサーバ150)の処理負荷やトラフィックが軽減される。
また、上記の実施の形態でネットワーク側のエンティティ(例えば、eNB110やMME120、SGW、PGW、MTCサーバ150)からメッセージ(例えば、本発明の第1〜第7の実施の形態では逆イベント通知メッセージ、本発明の第8の実施の形態では送信制御メッセージ)がブロードキャストされる。ネットワーク側のエンティティ(例えば、eNB110、MME120、SGW130、PGW140、MTCサーバ150)は、非特許文献6で定義されるように、このブロードキャストされるメッセージにMTCデバイス100が送信するメッセージを遅らすための待機時間(Stop time、Barring time、Backoff time、Wait timeなどとも呼ばれる)を格納する場合もある。MTCデバイス100は、この待機時間の間はデータ送信やPDNコネクション確立リクエストなどのメッセージ送信を行えないものとする(例えば、MTCデバイス100が通常モードからデータ送信抑制モードや、規制モード、制限モードなどにモード遷移する)。しかし、優先度レベルの高いイベントを検知した場合や、緊急事態が生じた場合には、ネットワーク側からメッセージ送信の抑制をされているが、MTCデバイス100はデータ送信やPDNコネクション確立リクエストの送信が可能なモード(例えば、通常モード)にモード遷移できるものとする。また、この待機時間は、詳細データフィールドに格納されるPDNコネクションを維持/切断するための条件(例えば、Before time)と共用してもよい。例えば、待機時間を「3分」と設定し、優先度レベルの低いMTCデバイスからのメッセージ(例えば、PDNコネクション確立リクエスト)を3分間抑制すると同時に、3分以内に確立されたPDNコネクションを切断するように指示してもよい。なお、このとき、詳細データフィールドは省略でき、通信システムのエンティティやMTCデバイス100の処理負荷、ネットワークのトラフィックが軽減される。
また、上記の実施の形態(特に第8の実施の形態)で、MTCデバイス100とネットワーク側のエンティティが、異なる優先度レベルを認識できる場合(例えば、アプリケーションAのデータは優先度レベルAであり、UE105からのメッセージは優先度レベルBなど)、ネットワーク側のエンティティ(例えば、eNB110、MME120、SGW130、PGW140、MTCサーバ150)は優先度レベル毎にメッセージ送信を抑制してもよい。例えば、eNB110がブロードキャスト送信する送信制御メッセージに「優先度レベルBのみ抑制」ということを示すパラメータを格納する。この送信制御メッセージを受信したMTCデバイス100は、優先度レベルBのメッセージのみ送信を遅らせる/停止させる、若しくは、優先度レベルを変化させてメッセージを送信する。例えば、「優先度レベルBのみ抑制」であるが、「MTCグループAに属しているMTCデバイス100は免除」ということを示すパラメータと組み合わせて使用してもよい。また、優先度レベルだけではなく、従来技術の、例えば、Access classを用いてMTCデバイス100から送信されるメッセージを抑制してもよい。
また、上記の実施の形態(特に第1〜第8の実施の形態)におけるMTCデバイス100は、1つのMTCグループや1つのAPN、1つのPLMNオペレータに属していたが、複数のMTCグループや複数のAPN、複数のPLMNオペレータに属してもよい。例えば、MTCデバイス100が2つのAPN(APN−1とAPN−2)に接続している場合、通信システムは段階的にMTCデバイス100から送信されるメッセージを抑制することができる。例えば、ネットワーク側のエンティティ(例えば、eNB110、MME120、SGW130、PGW140、MTCサーバ150)がブロードキャスト送信する送信制御メッセージ、若しくは、逆イベント通知メッセージに「APN−1を用いた送信メッセージを抑制」ということを示すパラメータを格納する。これにより、MTCデバイス100はAPN−1を用いたメッセージ送信は抑制されるが、APN−2を用いたメッセージ送信は可能となる。
また、本発明の第8の実施の形態では、説明の容易化のために、“Time tolerant”フィールドと詳細データフィールドを用いた結果、確立済みのPDNコネクションを切断すると多く記述したが、通信システムのオペレータのポリシやMTCサーバ、MTCユーザのポリシ、アプリケーションのポリシ、MTCデバイスのポリシによっては、確立済みのPDNコネクションを切断ではなく、「維持」すると決定してもよい。
なお、本発明の第8の実施の形態では、“Time tolerant”の機能を保持し、詳細データフィールドで指定された条件に該当するMTCデバイス100が、既にPDNコネクションを確立済みである場合、MTCデバイス100はPDNコネクションを切断していたが(図24のステップS1221、S1222、S1230、S1250)、PDNコネクションは切断せずに(維持したまま)、データ送信のみ制御(例えば、停止、データレートの変更、データサイズの変更)を行ってもよい。これにより、U−planeのリソースを段階的に確保することができる。また、PDNコネクションを切断しないため、再度PDNコネクションを確立する必要がなくなり、通信システムのエンティティ(例えば、eNB110、MME120、SGW130、PGW140)の処理負荷が軽減される(例えば、アドレスの割り当て、バインディングアップデート)。
なお、本発明の第8の実施の形態は、通信システムのエンティティが対象となるMTCデバイス100にブロードキャストして、優先度レベルの高いUE105やMTCデバイス100のためのリソースを確保するためにPDNコネクションを切断しているが、ブロードキャストではなく、ユニキャストやマルチキャストで送信してもよい。
なお、本発明の第8の実施の形態は、図19、20を用いて説明したように、MTCデバイスD100DがPDNコネクション確立リクエストをネットワーク側に送信した結果(図20のステップS1002)、ネットワーク側が混雑状態になり(図20のステップS1003)、送信制御メッセージがMTCデバイスに送信されていた(図20のステップS1006)。つまり、送信制御メッセージは、ネットワーク側が混在状態にある場合に、優先度レベルが低いMTCデバイス100からのメッセージ(例えば、PDNコネクション確立リクエスト)の回避と、既に確立済みのPDNコネクションを切断することを要求するために使用された。さらに、送信制御メッセージは、既にPDNコネクションを確立済みであるMTCデバイス100が、新たに送信する可能性がある別のPDNコネクション確立リクエストを拒絶する、あるいは遅延させるためにも用いることができる。送信制御メッセージを新たなPDNコネクション確立リクエストの遅延のために用いる場合、混雑状態を検出した際に通信システムのエンティティは、待機時間を含む送信制御メッセージを対象となるMTCデバイスへブロードキャストする。このとき、ネットワーク側がブロードキャスト送信する送信制御メッセージにパラメータ情報として格納される待機時間は、既にPDNコネクションを確立済みであるMTCデバイス100(MTCデバイスA100A、MTCデバイスB100B、MTCデバイスC100C、MTCデバイスD100D)が送信する追加のPDNコネクション確立メッセージの送信タイミングを遅らせることを指示する情報として用いられる。この送信制御メッセージを受信したMTCデバイス100は、MTCデバイス100自身が既に確立済みのPDNコネクションを保持済みであり、新たに別のPDNコネクションを確立したい場合は、待機時間が経過するまでそのPDNコネクション確立リクエストの送信を遅らせると判断する。例えば、既に1つのPDNコネクションを確立しているMTCデバイス100が、さらに1つのPDNコネクションを新たに追加で確立しようとしていた場合、送信制御メッセージを受けることで、2つ目のPDNコネクションの確立要求の送信を、待機時間後へと遅らせる。
また、既にPDNコネクションを確立済みであるMTCデバイス100が、待機時間が格納されていない送信制御メッセージを受信した場合、追加のPDNコネクション確立リクエストを送信しないようにすることもできる。例えば、送信制御メッセージに「追加確立禁止」を示すパラメータを格納することで、MTCデバイス100による追加のPDNコネクション確立リクエスト送信を回避する。
また、既にPDNコネクションを確立済みであるMTCデバイス100が、待機時間が格納されていない送信制御メッセージであり、さらにMTCデバイス100による追加予定のPDNコネクションに対するパラメータ(例えば、各MTCデバイス100が確立可能なPDNコネクションの最大数、又は、追加PDNコネクションに割り当て可能なQoSなど)が格納された送信制御メッセージを受信した場合、追加のPDNコネクションを確立する際にこの情報に従って、PDNコネクション確立リクエストを送信する。
例えば、パラメータ情報に、同時に確立可能なPDNコネクションの最大数が含まれている場合、MTCデバイス100自身が確立したいPDNコネクション数と送信制御メッセージに格納されている、同時に確立可能なPDNコネクションの最大数を比較し、確立したいPDNコネクションの数が、同時に確立可能なPDNコネクションの数を上回る場合は、確立済みのPDNコネクションが終了した後に、新たなPDNコネクションの確立を行う。つまり、2つ目のPDNコネクションを確立したいMTCデバイス100が、同時確立可能なPDNコネクションの数が1つであるパラメータ情報を受信した場合は、確立した1つ目のPDNコネクションを用いた通信が終了し、そのPDNコネクションを切断した後に、2つ目の新たな別のPDNコネクションを確立する。さらに、3つ目のPDNコネクションを確立する場合には、2つ目のPDNコネクションを用いた通信が終了した後に、そのPDNコネクションを切断し、3つ目の新たなPDNコネクションを確立する。なお、新たなPDNコネクションを確立する必要が生じた際に、既に確立されているPDNコネクションを直ぐに切断すると判断してもよい。また、パラメータ情報として、同時に確立可能なPDNコネクションの数を通知する代わりに、追加のPDNコネクションの確立が制限されていることを示す情報を送信制御メッセージに含めてもよい。この情報を受けたMTCデバイス100は、新たなPDNコネクションを確立する場合は、既に確立しているPDNコネクションを切断した後に、新たなPDNコネクションの確立要求を送信する。
これにより、MTCデバイス100が複数のPDNコネクションを確立しなければならない場合(例えば、MTCデバイス100が複数のMTCサーバ150または複数のAPN、若しくは、複数のMTCユーザ160と接続されていて、MTCユーザの情報セキュリティや契約関係上、PDNコネクションを分けて使用しなければならない場合)に、同時に確立できるPDNコネクションの数を制限することで、同時に複数のPDNコネクションを確立することによって帯域が占有されてしまうことを防ぐ効果がある。
また、上記したMTCデバイス100による追加予定のPDNコネクションに対するパラメータ(例えば、各MTCデバイス100が確立可能なPDNコネクションの最大数、又は、追加PDNコネクションに割り当て可能なQoSなど)に加えて、待機時間が格納される場合、MTCデバイス100による追加予定のPDNコネクションに対するパラメータ(例えば、各MTCデバイス100が確立可能なPDNコネクションの最大数、又は、追加PDNコネクションに割り当て可能なQoSなど)の適用時間(有効期間)として使用することで、リアルタイムに変化するネットワーク側の混雑状態に沿ったリソース管理になる。例えば、ネットワーク側からブロードキャスト送信される送信制御メッセージに、待機時間(例えば、「1分」)が格納されており、かつ、「各MTCデバイス100が確立可能なPDNコネクションは1つ」と示されている場合、送信制御メッセージを受信したMTCデバイス100は、送信制御メッセージを受信した後から1分以内に新たなPDNコネクション確立リクエストを送信する場合は、既に確立済みのPDNコネクションを切断した後、追加のPDNコネクションを確立する。待機時間の経過後は、「各MTCデバイス100が確立可能なPDNコネクションは1つ」と示されている情報は、適用時間を過ぎているので、追加のPDNコネクションを確立する際には用いなくてよい。なお、追加予定のPDNコネクションに対するパラメータが格納された送信制御メッセージを受信したMTCデバイス100は、追加のPDNコネクションを確立する際、追加のPDNコネクションの確立を諦めて既に確立済みのPDNコネクションを維持するか、若しくは、既に確立済みのPDNコネクションを切断して追加のPDNコネクションを確立するかを、例えば、MTCデバイス100が保持するコンテキスト(例えば、MTCサーバ150やMTCユーザ160からの要求やスタティックな情報)や、アプリケーションに仕様に基づいて判断してもよい。
この「各MTCデバイス100が確立可能なPDNコネクションは1つ」と示されている情報は、送信制御メッセージの詳細データフィールドに格納してもよい。
なお、既にPDNコネクションを確立しているMTCデバイス100に対して、追加のPDNコネクションに対するパラメータを通知するメッセージは、ブロードキャストではなくユニキャストで送信されてもよい。この場合、MTCデバイス100は、最初のPDNコネクションを確立する際に(例えば、Attach procedure中)、通信システムのエンティティから追加のPDNコネクションに対するパラメータ(例えば、各MTCデバイス100が確立可能なPDNコネクションの最大数、又は、追加PDNコネクションに割り当て可能なQoSなど)を含む送信制御メッセージを受信する。パラメータ情報を取得したMTCデバイス100は、上記のように、取得したパラメータ情報に従って追加のPDNコネクションを確立するためのPDNコネクション確立リクエストを送信する。
なお、追加のPDNコネクションに対するパラメータ情報がMTCデバイス100に通知されるタイミングは、MTCデバイス100から最初のPDNコネクション確立リクエストを受けた際に限定されず、既にPDNコネクションの確立が終了した後の任意のタイミングでもよい。つまり、ネットワーク側が混雑状態を検出した際に、既にPDNコネクションを確立しているMTCデバイス100に対してパラメータ情報が通知される。また、MTCデバイス100が送信する追加のPDNコネクションの確立リクエストを受信した際に、その確立リクエストが拒絶されたことを通知する送信制御メッセージ、さらには追加のPDNコネクションに対するパラメータ情報を含む送信制御メッセージをMTCデバイス100に通知してもよい。
<第9の実施の形態>
本発明の第9の実施の形態では、既にPDNコネクションを確立済みの状態で、さらに追加のPDNコネクション確立を望むMTCデバイス100が、ネットワークから通知される混雑状態に関する情報に基づいて、既に確立済みのPDNコネクションをリリースし、追加のPDNコネクションを確立する。
MTCデバイス100は、ネットワークが混雑している場合でも、新たにPDNコネクションを確立し、データを送信したい場合がある。例えば、MTCデバイス100が人感センサであり、センサが不良動作を起こしていないかなどを確認するためのメンテナンスデータと、実際にセンサが取得したセンシングデータの送信先のMTCサーバ150が異なり、メンテナンス用のPDNコネクションは確立済みで、センシングしたデータを送信するためのPDNコネクションを任意の期間のみ確立するケースや、又は、MTCデバイス100が自動販売機であり、MTCサーバ150に接続するためのPDNコネクションと、IMS(IP Multimedia Subsystem)に接続するためのPDNコネクションがあり、MTCサーバ150に接続するためのPDNコネクションは確立済みで、IMSに接続するためのPDNコネクションを任意のタイミングで確立するケースなどがある。しかし、最初のPDNコネクションを確立してから、追加のPDNコネクションを確立するまでの間に、ネットワークは混雑状態を検出する場合があり、このとき、MTCデバイス100が送信する追加のPDNコネクション確立リクエストは拒絶されてしまう。また、MTCデバイス100において、既に確立済みのPDNコネクションで送信しているデータより、追加で確立するPDNコネクションで送信するデータのほうが優先度レベルの高い場合がある。このとき、MTCデバイス100が追加のPDNコネクションを確立できない場合、MTCデバイス100やMTCサーバ150、MTCユーザ160などに優先度レベルが高いデータを送受信できないなどの不利益が生じる。このような課題を解決するために、既にPDNコネクションを確立済みであるMTCデバイス100は、ネットワークから通知される混雑状態に関する情報に基づいて、既に確立済みのPDNコネクションをリリースし、追加のPDNコネクションを確立する。
以下、本発明の第9の実施の形態について、図25、図26、図27A〜図27E、図28〜図30、図35、図36を用いて説明する。
ここで、本発明の第9の実施の形態の説明を容易化するために、本発明の第9の実施の形態におけるMTCデバイス100は、ネットワークと既にPDNコネクションを1つ確立済みであり、確立済みのPDNコネクション内のEPSベアラに対して、ネットワークが保証するビットレート(GBR:Guaranteed Bit Rate)は5Mbpsとする。また、MTCデバイス100は、追加のPDNコネクションを確立するために、PDNコネクション確立リクエストを送信する。
この“GBR=5Mbps”とは、ネットワークがMTCデバイス100に対して、5Mbpsのビットレートを保証することを示している。例えば、MTCデバイス100に5MbpsのGBRが割り当てられている間、ネットワークは5Mbpsを下回るビットレート(例えば、4Mbps)をMTCデバイス100に提供しないことを示している。
“GBR=5Mbps”が割り当てられたEPSベアラを含むPDNコネクションを確立済みであるMTCデバイス100の動作について、図25を用いて説明する。
図25において、“GBR=5Mbps”が割り当てられたEPSベアラを含むPDNコネクションを確立済みであるMTCデバイス100が、追加のPDNコネクションを確立しようとする状態を前提とする(ステップS2500)。MTCデバイス100は、追加のPDNコネクションを確立するためにPDNコネクション確立リクエストを送信する(ステップS2501:PDNコネクション確立リクエスト)。なお、MTCデバイス100がPDNコネクションを確立する際、非特許文献3で定義されているPDN connectivity requestメッセージや、Service requestや、Create Bearer requestメッセージなどを使用してもよい。
このとき、PDNコネクション確立リクエストを受信したネットワークでは、ネットワーク側で混雑状態が発生してしまうとする(図25の(A)混雑発生)。そのため、ネットワークは、ステップS2501でMTCデバイス100から送信されたPDNコネクション確立リクエストを拒絶するPDNコネクション確立拒絶レスポンスを送信する(ステップS2502:PDNコネクション確立拒絶レスポンス)。
追加のPDNコネクション確立を拒絶されたMTCデバイス100は、追加のPDNコネクションの優先度レベルと確立済みのPDNコネクションの優先度レベルを比較する(ステップS2503:優先度レベルの比較)。なお、PDNコネクションの優先度レベルは、アプリケーションレイヤから取得できるアプリケーション毎に割り当てられる優先度レベルや、MTCデバイス100が保持するポリシ、MTCデバイス100がMTCのためにスタティック(静的)に格納されている情報(例えば、最初に起動したアプリケーションを優先的に処理するなど)などを用いて取得してもよい。
追加のPDNコネクションの優先度レベルのほうが高いと判断したMTCデバイス100は、確立済みのPDNコネクションの代わりとして追加のPDNコネクションを確立できるか確認するために、既に確立済みのPDNコネクションのEPSベアラに割り当てられているQoS情報(GBR情報など)と、追加のPDNコネクションのEPSベアラに必要なQoS情報(GBR情報など)を比較する(ステップS2504:QoS比較)。
例えば、GBRで比較する場合には、図27Aで示すように、確立済みのPDNコネクションのEPSベアラに割り当てられているGBRが1Mbpsの場合、MTCデバイス100は、追加のPDNコネクションのEPSベアラに必要なGBRが1Mbps以下であれば、確立済みのPDNコネクションを切断することで、追加のPDNコネクションを確立できる。なお、このとき、MTCデバイス100は従来であれば、追加のPDNコネクションを確立することができないが、確立済みのPDNコネクションより追加のPDNコネクションの優先度レベルのほうが高いことを知得した場合、MTCデバイス100は確立済みのPDNコネクションをリリースした後、MTCデバイス100は追加のPDNコネクションを確立する。
また、QCIで比較する場合には、図27Bで示すように、MTCデバイス100が、追加で確立するPDNコネクションのQCIが、既に確立済みのPDNコネクションに割り当てられているQCIと一致している場合、MTCデバイス100は確立済みのPDNコネクションを切断することで、追加のPDNコネクションを確立できる。また、QCIが一致しており、かつ確立済みのPDNコネクションのGBRが、追加で確立するPDNコネクションのGBRよりも大きい場合に、MTCデバイス100は確立済みのPDNコネクションを切断することで、追加のPDNコネクションを確立できると判断してもよい。このように、上記のGBRを用いた説明と同様に、MTCデバイス100は従来であれば、追加のPDNコネクションを確立することができないが、確立済みのPDNコネクションより追加のPDNコネクションの優先度レベルのほうが高いため、MTCデバイス100は確立済みのPDNコネクションをリリースした後、MTCデバイス100は追加のPDNコネクションを確立する。
また、QoS情報を複数用いて、MTCデバイス100が確立済みのPDNコネクションをリリースして、追加のPDNコネクションを確立するか判断してもよい。例えば、MTCデバイス100が、QoS情報として、GBRとMBRを用いてもよい。この場合、MTCデバイス100は、最初のステップとして、追加で確立するPDNコネクションのベアラで用いられるGBRが、「既に確立済みのPDNコネクションのベアラで用いられるGBR」以下であるか確認する。「既に確立済みのPDNコネクションのベアラで用いられるGBR」以下の場合、MTCデバイス100は、GBRに続いてMBRも同様に確認する。MBRも同様に「既に確立済みのPDNコネクションのベアラで用いられるMBR」以下の場合、MTCデバイス100は、既に確立済みのPDNコネクションをリリーすることによって確保されるリソースを用いて追加のPDNコネクションを確立することができると判断し、既に確立済みのPDNコネクションをリリースする。そして、MTCデバイス100は、新しいPDNコネクションを確立する。
なお、上記の説明例では、QoS情報の比較処理を実施する際、GBR、QCI、MBRを挙げているが、他のQoS情報に関する例も含めて、図26にアクション、図27A〜図27Eにアクション結果が図示されている。
また、上記のQoS比較処理の説明では、MTCデバイス100が1つのPDNコネクションを確立済みの状態を前提としていたが、MTCデバイス100が複数のPDNコネクションを確立済みの状態では、各PDNコネクション、若しくは、各PDNコネクションのEPSベアラに割り当てられているQoS情報の合計(GBRの合計など)や、もしくは、両方(QCIが一致するベアラケースなど)が、追加で確立するPDNコネクションで必要なQoS情報を満たすことができる場合、MTCデバイス100は追加のPDNコネクションを確立することができる。このとき、MTCデバイス100は、確立済みのPDNコネクションを全てリリースしてもよいし、追加のPDNコネクションに必要なQoS情報を確保するためにリリースする必要があるPDNコネクションを複数選択した後、それらをリリースしてもよい。
なお、追加のPDNコネクションや、EPSベアラに必要なQoS情報は、例えば、MTCサービスのアプリケーションや、MTCデバイス100が保持するポリシ、MTCデバイス100にMTCのためにスタティックに格納されている情報、MTCサーバ150やMTCユーザ160から直接通知される情報などから取得してもよい。
ステップS2504において比較した結果、追加で確立するPDNコネクションのEPSベアラのQoS情報(GBR情報)が、既に確立済みのPDNコネクションのEPSベアラに割り当てられているQoS情報(GBR情報)以下であれば(例えば、既に確立済みのPDNコネクションのEPSベアラに割り当てられているGBR情報が5Mbpsで、追加で確立するPDNコネクションのEPSベアラで必要なGBR情報が4Mbpsの場合など)、確立済みのPDNコネクションをリリースする(ステップS2505:PDNコネクションRelease procedure)。なお、確立済みのPDNコネクションをリリースする際に、非特許文献3で定義されるUE requested PDN disconnection procedureや、UE−initiated Detach procedure、UE requested bearer resource modification procedureなどを使用してもよい。
また、MTCデバイス100が、PDNコネクションをリリースすることによって確保されたリソースが、MTCデバイス100ではなく、他のMTCデバイスやUEに割り当てられてしまう場合が考えられる。この場合、MTCデバイス100は、確立済みのPDNコネクションをリリースする際、リリースしたPDNコネクションのEPSベアラに割り当てられているQoS情報(GBR情報)を新たに確立するPDNコネクションで再使用することをネットワークへ通知する。
図28は、MTCデバイス100がUE requested PDN disconnection procedureを用いて、ネットワーク側にリリースしたPDNコネクションのEPSベアラに割り当てられていたリソース(QoS情報)を新たに確立するPDNコネクションで再使用することをネットワークへ通知するメッセージのフォーマット例である。
図28に図示されているメッセージは、従来のPDN Disconnection Requestメッセージフィールドに加えて、他のMTCデバイス100やUE105にQoS情報(GBR情報)を割り当てないように通知するためのQoS保持フィールド、MTCデバイス100が要求するネットワーク側でQoS情報を保持する期間を示す保持期間フィールドで構成される。
続いて、図25において、確立済みのPDNコネクションをリリース後、MTCデバイス100は、PDNコネクション確立リクエストを送信する(ステップS2506:PDNコネクション確立リクエスト)。このとき、ネットワーク側が、PDNコネクションをリリースすることによって確保されたリソースを使用して新たにPDNコネクションを確立しようとしているMTCデバイス100であることを識別できることとする。例えば、PDNコネクション確立リクエストに格納されているMTCデバイス100のIMSIやIMEI、又は、PDNコネクションRelease procedure中に交換した新規の識別子などを用いてMTCデバイス100を識別してもよい。
ステップS2506のPDNコネクション確立リクエストを受信したネットワークは、PDNコネクションをリリースすることによって確保されたリソースを使用して新たにPDNコネクションを確立しようとしているMTCデバイス100であることを確認し、PDNコネクション確立許可レスポンスを送信する(ステップS2507:PDNコネクション確立許可レスポンス)。
PDNコネクション確立後、MTCデバイス100はステップS2507で確立したPDNコネクションのEPSベアラで使用するQoS情報(GBR情報)に変更するため、PDNコネクションModification procedureを実施する(ステップS2508)。このときも、ステップS2506のときと同様に、ネットワークは、確保しているリソースの対象MTCデバイス100であることを識別できることとする。なお、ステップS2504のQoS情報の比較後、MTCデバイス100が確立済みのPDNコネクションをリリースし、PDNコネクションの確立処理をするのではなく、PDNコネクションModification procedureをするだけで、新たに確立しようとしているPDNコネクションと同等のPDNコネクションが確保できる場合は、ステップS2505からステップS2507を省略してもよい。
確立したPDNコネクションのQoS情報を更新後、MTCデバイス100はPDNコネクションの確立を完了する(ステップS2509:PDNコネクション確立完了)。
なお、第9の実施の形態では、MTCデバイス100が追加のPDNコネクションを送信した際にネットワークが混雑状態を検出して、PDNコネクションの確立を拒絶しているが、例えば、他のMTCデバイス100やUE105によるデータ送信などによる混雑発生を機に、例えば、同じMTCグループや同じeNB110に接続しているMTCデバイス100など、複数のMTCデバイス100やUE105に対して、ブロードキャストメッセージで、追加のPDNコネクションの確立拒絶を通知してもよい。
次に、図29を参照しながら、本発明の第9の実施の形態におけるMTCデバイス100の構成について説明する。図29は、本発明の第9の実施の形態におけるMTCデバイス100の構成の一例を示す図である。
図29において、MTCデバイス100は、通信システム(例えば、E−UTRANやUTRAN)と接続して下位レイヤにおける通信処理と上位レイヤでIPなどのパケット通信処理を実施する通信処理部2701、PDNコネクション確立リクエストの送信や確立したPDNコネクションのEPSベアラに割り当てられるQoS情報の更新、PDNコネクションのリリースなどを処理するPDNコネクション処理部2702、確立済みPDNコネクションのQoS情報と追加で確立するPDNコネクションのQoS情報を比較するQoS情報比較部2703を少なくとも有する。なお、図29には不図示だが、MTCデバイス100は、追加のPDNコネクションの優先度レベルと確立済みのPDNコネクションの優先度レベルを比較する優先度レベル比較部を有していてもよい。
次に、図29に図示されている構成を有するMTCデバイス100について、本発明における特徴的な処理を中心に、図30を用いて詳しく説明する。
図30において、MTCデバイス100は、既にPDNコネクションを1つ確立済みの状態であり、追加のPDNコネクションの確立リクエストをPDNコネクション処理部2702から通信処理部2701を介して、ネットワークに送信する(ステップS2801:PDNコネクション確立リクエスト送信)。
PDNコネクション確立リクエストを受信したネットワークでは、混雑状態を検出しているため、MTCデバイス100は、3Gアクセスから送信されるPDNコネクション確立拒絶レスポンスを受信する(ステップS2802:PDNコネクション確立拒絶レスポンス受信)。
追加PDNコネクションの確立を拒絶されたMTCデバイス100は、QoS情報比較部2703にて、確立済みのPDNコネクションのEPSベアラに割り当てられているQoS情報と、追加で確立するPDNコネクションのEPSベアラに必要なQoS情報を比較する(ステップS2803:QoS情報の比較)。なお、MTCデバイス100は、優先度レベル比較部において、追加のPDNコネクションの優先度レベルと確立済みのPDNコネクションの優先度レベルを比較し、追加のPDNコネクションの優先度レベルのほうが高いと判断した場合に、確立済みのPDNコネクションの代わりとして追加のPDNコネクションを確立できるか確認するために、QoS情報の比較を行うようにしてもよい。
ステップS2803において比較した結果、追加で確立するPDNコネクションのQoS情報が、確立済みのPDNコネクションのQoS情報以下であれば(例えば、追加で確立するPDNコネクションのEPSベアラで必要なGBRが4Mbpsで、既に確立済みのPDNコネクションのEPSベアラのGBRが5Mbpsである場合など)、QoS情報比較部2703からPDNコネクション処理部2702に確立済みのPDNコネクションをリリースするように指示し、通信処理部2701を介して、PDNコネクションをリリースするためのメッセージを送信する(ステップS2804:確立済みPDNコネクションリリース)。このとき、MTCデバイス100は、リリースするPDNコネクションに割り当てられているリソース(例えば、通信リソースや帯域リソースなど)を他のMTCデバイス100やUE105に割り当てないように指示するための識別子を送信するメッセージに格納する。
一方、ステップS2803において比較した結果、追加で確立するPDNコネクションのQoS情報が、確立済みのPDNコネクションのQoS情報より大きければ(例えば、追加で確立するPDNコネクションのEPSベアラで必要なGBRが6Mbpsで、既に確立済みのPDNコネクションのEPSベアラのGBRが5Mbpsである場合など)、確立済みのPDNコネクションはリリースされることなく、維持される。
確立済みのPDNコネクションをリリースしたMTCデバイス100は、PDNコネクション処理部2702から通信処理部2701を介して、追加のPDNコネクションを確立する(ステップS2805:追加のPDNコネクション確立)。この場合もステップS2804と同様に、MTCデバイス100は、ネットワークが、PDNコネクションをリリースしたMTCデバイス100であることを識別できるような識別子を、追加のPDNコネクション確立リクエストに格納する。
PDNコネクションを確立後、MTCデバイス100は、デフォルトのPDNコネクションのQoS情報から追加のPDNコネクションが必要とするQoS情報に更新するため、非特許文献3で定義されるUE requested bearer resource modification procedureなどを用いて、更新する(ステップS2806:追加PDNコネクションのQoS情報を更新)。この場合もステップS2804と同様に、MTCデバイス100は、ネットワークが、PDNコネクションをリリースしたMTCデバイス100であることを識別できるような識別子を、確立したPDNコネクションのQoS情報の更新メッセージに格納する。
なお、ステップS2803のQoS情報の比較後、MTCデバイス100が確立済みのPDNコネクションをリリースし、PDNコネクションの確立処理をするのではなく、PDNコネクションModification procedureを実施し、MTCデバイス100が要求するPDNコネクションを実現できる場合は、ステップS2804及びステップS2805を省略してもよい。
なお、上記の第9の実施の形態では、ネットワークからMTCデバイス100に混雑状態に関する情報が通知され、MTCデバイス100は確立済みのPDNコネクション、若しくは、PDNコネクションのEPSベアラに割り当てられているQoS情報と、追加のPDNコネクションで必要なQoS情報を比較して、確立済みのPDNコネクションをリリースすることで確保されるリソースを、新たなPDNコネクションの確立に用いることができるか否かを判断している。このQoS情報に加えて、MTCデバイス100は、MTCデバイス100の確立可能なPDNコネクション数を確立済みのPDNコネクションをリリースする際の判断材料として用いてもよい。
この確立可能なPDNコネクション数の情報を、例えば、MTCデバイス100が、MTCのためにスタティックに格納している情報から取得してもよい、又は、ネットワークが任意のタイミング(例えば、混雑状態を検出したとき)でMTCデバイス100に確立可能なPDNコネクション数をあらかじめ通知してもよい、又は、MTCデバイス100は、確立済みのPDNコネクションを確立した際にネットワークから「MTCデバイス100が確立可能なPDNコネクション数は1つ」という情報を取得してもよい、又は、ネットワークは、PDNコネクション確立拒絶レスポンスで、QoS情報は通知することはできないが、「MTCデバイス100が確立可能なPDNコネクション数」の情報のみを通知できる場合は、MTCデバイス100が追加のPDNコネクションを確立する際に送信するPDNコネクション確立リクエストの返信(PDNコネクション確立拒絶レスポンス)で、「MTCデバイス100が確立可能なPDNコネクション数は1つ」という情報を通知してもよい。
このように、QoS情報と確立可能なPDNコネクション数を組み合わせることにより、ネットワークは割り当て可能なリソースを精度高く制御することができる。例えば、ネットワークが、PDNコネクションを1つ確立済みのMTCデバイス100から、追加のPDNコネクションの確立リクエストを受信した場合、ネットワークがMTCデバイス100に対して、PDNコネクション確立拒絶レスポンスを送信する。このとき、MTCデバイス100は保持している確立可能なPDNコネクション数の情報を用いて、現在確立しているPDNコネクション数を確認し、さらに確立済みのPDNコネクションが存在する場合、その確立済みのPDNコネクション、若しくは、確立済みのPDNコネクションのEPSベアラに割り当てられているQoS情報(例えば、GBR=1Mbps)と追加で確立するPDNコネクションで必要なQoS情報(500kbps)を比較し、追加のPDNコネクションで必要とされるQoS情報を満たすことができる場合、MTCデバイス100は確立済みのPDNコネクションをリリースし、追加のPDNコネクションを確立することができる。
なお、MTCデバイス100の保持する確立可能なPDNコネクション数の情報とPDNコネクション数を管理するPDNコネクション処理部で情報共有(同期)がとれていない場合や、PDNコネクション確立拒絶レスポンスで取得できる情報(例えば、混雑レベルや現在の確立可能なPDNコネクション数)を得る場合や、確立済みのPDNコネクションより優先度レベルの高いPDNコネクションの確立リクエストの場合があるため、MTCデバイス100が保持する確立可能なPDNコネクション数に既に確立済みのPDNコネクションの数が達している状態にもかかわらず、MTCデバイス100は追加のPDNコネクション確立するためのPDNコネクション確立リクエストを送信する可能性がある。
以上、本発明の第9の実施の形態によれば、既にPDNコネクションを確立済みのMTCデバイス100が追加のPDNコネクションを確立する際、ネットワークで混雑状態を検出している場合でも、確立済みのPDNコネクションに割り当てられているQoS情報と追加で確立するPDNコネクションに必要なQoS情報を比較し、追加で確立するPDNコネクションに必要なQoS情報が、確立済みのPDNコネクションに割り当てられているQoS情報を満たすことができる場合、MTCデバイス100は確立済みPDNコネクションをリリース又は変更し、追加のPDNコネクションを確立することができる。これにより、MTCデバイス100は優先度レベルが高いデータを送信することができ、MTCデバイス100やMTCサーバ150、MTCユーザ160などに優先度レベルが高いデータを送信できないなどの問題は解決される。
<第10の実施の形態>
本発明の第10の実施の形態では、既にPDNコネクションを確立済みの状態で、さらに追加のPDNコネクション確立を望むMTCデバイス100が、ネットワークから通知されるMTCデバイス100やUE105に割り当て可能な通信リソースや帯域リソースの情報に基づいて、既に確立済みのPDNコネクションをリリースし、追加のPDNコネクションを確立する。
第10の実施の形態で想定しているシナリオは、第9の実施の形態と同じである。第9の実施の形態との違いは、MTCデバイス100が追加のPDNコネクションを確立する際、確立済みのPDNコネクション、又は、そのPDNコネクションのEPSベアラに割り当てられているQoS情報と、ネットワークから通知されるMTCデバイス100に割り当て可能なQoS情報(例えば、通信リソースや帯域リソース)を足し合わせたリソースが、新たに確立するPDNコネクションに必要なリソースよりも大きい場合に、確立済みのPDNコネクションをリリースすると判断する点である。以下、第9の実施の形態との違いを中心に詳しく説明する。
以下、本発明の第10の実施の形態について、図31、図32、図33A〜図33E、図34〜図36を用いて説明する。
ここで、本発明の第10の実施の形態の説明を容易化するために、本発明の第10の実施の形態におけるMTCデバイス100は、第9の実施の形態における前提と同様に、ネットワークと既にPDNコネクションを1つ確立済みであり、確立済みのPDNコネクション内のEPSベアラに対して、ネットワークが保証するビットレート(GBR:Guaranteed Bit Rate)は5Mbpsとする。また、MTCデバイス100は、追加のPDNコネクションを確立するために、PDNコネクション確立リクエストを送信する。このとき、MTCデバイス100は、既に確立済みのPDNコネクションで送信されるデータの優先度より、追加で確立するPDNコネクションで送信するデータの優先度レベルのほうが高いことを認識していることを前提としている。
“GBR=5Mbps”が割り当てられたEPSベアラを含むPDNコネクションを確立済みであるMTCデバイス100が、追加のPDNコネクションを確立する際、ネットワークから通知されるQoS情報に基づいて、確立済みのPDNコネクションをリリースし、追加のPDNコネクションを確立するMTCデバイス100の動作について、図31を用いて説明する。
図31において、“GBR=5Mbps”が割り当てられたEPSベアラを含むPDNコネクションを確立済みであるMTCデバイス100が、追加のPDNコネクションを確立しようとする状態を前提とする(ステップS2900)。MTCデバイス100は、追加のPDNコネクションを確立するためにPDNコネクション確立リクエストを送信する(ステップS2901:PDNコネクション確立リクエスト)。なお、図31におけるステップS2900及びS2901は、図25におけるステップS2500及びS2501と同じなので、ここでは詳細な説明を省略する。
続いて、混雑状態を検出したネットワークは、PDNコネクションの確立リクエストの送信元であるMTCデバイス100に割り当て可能なQoS情報(例えば、GBR<=2Mbpsなら許可など)を格納したPDNコネクション確立拒絶レスポンスを送信する(ステップS2902:PDNコネクション確立拒絶レスポンス)。なお、GBR以外のQoS情報として、図32及び図33A〜図33Eで示すように、QCI(QoS Class Indicator)、ARP(Allocation and Retention Priority)、MBR(Maximum Bit Rate)、Group−AMBR(Group−Aggregated Maximum Bit Rate)、APN−AMBR(Access Point Name−AMBR)、Transfer Delay、Packet Delay Budget、Packet Error Loss Rate、Application priorityなどがある。
図34は、3Gアクセスが、追加のPDNコネクションに割り当て可能なQoS情報をMTCデバイス100に通知する際のメッセージのフォーマット例である。
図34に図示されているメッセージは、従来のPDNコネクション確立拒絶メッセージフィールドに加えて、MTCデバイス100に割り当て可能なQoS情報を格納するQoS情報フィールド、QoS情報フィールドに格納されている情報の有効時間(割り当て可能な時間)を示す有効期間フィールドで構成される。なお、有効期間フィールドは、本発明の第8の実施の形態で説明した待機時間と併用してもよい。
ネットワークからMTCデバイス100に割り当て可能なQoS情報を通知されたMTCデバイス100は、図31で示すように、追加で確立するPDNコネクションに必要なQoS情報が、既に確立済みのPDNコネクションに割り当てられているQoS情報と、ステップS2902で通知されたMTCデバイス100に割り当て可能なQoS情報の合計以下であるか比較する(ステップS2903:QoS比較)。
例えば、GBRで比較する場合には、図33Aで示すように、確立済みのPDNコネクションのEPSベアラに割り当てられているGBRが1Mbpsで、ネットワークからPDNコネクション確立拒絶レスポンスで通知される追加PDNコネクションに割り当て可能なGBRが0.5Mbpsである場合は、MTCデバイス100はGBRが1.5Mbps以下であれば、PDNコネクションを確立できる。すなわち、追加で確立するPDNコネクションのEPSベアラで必要とするGBRが1.5Mbps以下であれば、確立可能である。なお、このとき、確立済みのPDNコネクションをリリースする必要があるときは、MTCデバイスが追加で確立するPDNコネクションのGBRが、「ネットワークから通知されるGBR<追加で確立するPDNコネクションのGBR<ネットワークから通知されるGBRと確立済みのPDNコネクションのEPSベアラに割り当てられているGBRの合計」のときである。また、この具体例では、ネットワークからMTCデバイス100に通知される追加のPDNコネクションに割り当て可能なQoS情報は、現在のMTCデバイス100に対して割り当て可能なQoS情報であるが、MTCデバイス100が確立可能な絶対値を示すQoS情報を使用してもよい。例えば、GBRの場合、3Gアクセスから通知されるMTCデバイス100に割り当てられるQoS情報は、1.5Mbps(確立済みPDNコネクションのEPSベアラに割り当てられているGBR(1Mbps)+追加のPDNコネクションに割り当て可能なGBR(0.5Mbps))として通知してもよい。
また、QCIで比較する場合には、図33Bで示すように、MTCデバイス100が追加で確立するPDNコネクションのQCIが、3Gアクセスから通知されるMTCデバイス100に割り当て可能なQCIと一致している場合、MTCデバイス100は追加のPDNコネクションを確立できる。
また、詳しい説明は後述するが、QoS情報に加えて、MTCデバイス100が確立可能なPDNコネクション数もMTCデバイス100に通知される場合(例えば、MTCデバイス100は、一定時間(例えば、混雑時に通知される待機時間(Backoff time))、合計1つのPDNコネクションを確立可能)、MTCデバイス100は確立済みのPDNコネクションのQCIを確認し、追加で確立するPDNコネクションのQCIと比較する。QCIが同じで、かつ、確立可能なPDNコネクション数が1つである場合、MTCデバイス100は、確立済みのPDNコネクションをリリースすることで、追加のPDNコネクションを確立できる。
なお、上記の説明例では、QoS情報の比較処理を実施する際、GBR、QCIを挙げているが、他のQoS情報に関する例も含めて、図32にアクション、図33A〜図33Eにアクション結果が図示されている。
また、ステップS2903のQoS比較を行う前に、本発明の第9の実施の形態で説明したように、追加のPDNコネクション確立を拒絶されたMTCデバイス100は、追加のPDNコネクションの優先度レベルと確立済みのPDNコネクションの優先度レベルを比較した後に、QoS比較を起こってもよい。なお、PDNコネクションの優先度レベルは、アプリケーションレイヤから取得できるアプリケーション毎に割り当てられる優先度レベルや、MTCデバイス100が保持するポリシ、MTCデバイス100がMTCのためにスタティック(静的)に格納されている情報(例えば、最初に起動したアプリケーションを優先的に処理するなど)などを用いて取得してもよい。
続く、ステップS2903のQoS比較後、図31のステップS2904からステップS2908は、図25のステップS2505からステップS2509と同じなので、ここでは詳細な説明を省略する。
なお、上記の第10の実施の形態では、MTCデバイス100が追加のPDNコネクションの確立リクエストに対するPDNコネクション確立拒絶レスポンスで、MTCデバイス100に割り当て可能なQoS情報を通知していたが、ネットワークはMTCデバイス100に割り当て可能なリソースが存在することから、PDNコネクション確立許可レスポンスで通知してもよい。その場合、ステップS2902のPDNコネクション確立拒絶レスポンスは、PDNコネクション確立許可レスポンスに変わる。加えて、ステップS2903からステップS2906は省略でき、ステップS2907のPDNコネクションModification procedureから実施可能となる。
なお、上記の第10の実施の形態では、ネットワークからMTCデバイス100にQoS情報が通知されているが、QoS情報に加えて、MTCデバイス100の確立可能なPDNコネクション数を通知してもよい。QoS情報と確立可能なPDNコネクション数を組み合わせることにより、ネットワークは割り当て可能なリソースを精度高く制御することができる。例えば、ネットワークが、PDNコネクションを1つ確立済みのMTCデバイス100から、追加のPDNコネクションの確立リクエストを受信した場合、ネットワークがMTCデバイス100に対して、「MTCデバイス100の確立可能なPDNコネクション数は1つ」、かつ、「追加のPDNコネクションに割り当て可能なQoS情報(GBR)は、1Mbps」のQoS情報をPDNコネクション確立拒絶レスポンスに格納して送信する。このとき、MTCデバイス100は「MTCデバイス100の確立可能なPDNコネクション数は1つ」という情報から、追加のPDNコネクションを確立するためには、確立済みのPDNコネクションをリリースする必要があることを確認できる。さらに、「追加のPDNコネクションに割り当て可能なQoS情報(GBR)は、1Mbps」というQoS情報から、追加のPDNコネクションで必要とされるQoS情報を満たせるか確認することができ、追加のPDNコネクションで必要とされるQoS情報が、確立済みのPDNコネクションに割り当てられているQoS情報以下である場合は、MTCデバイス100は、確立済みのPDNコネクションをリリースし、追加のPDNコネクションを確立することができる。
以上、本発明の第10の実施の形態によれば、既にPDNコネクションを確立済みのMTCデバイス100が追加のPDNコネクションを確立する際、ネットワークで混雑状態を検出している場合でも、ネットワークから通知されるMTCデバイスに割り当て可能なQoS情報と、確立済みのPDNコネクションに割り当てられているQoS情報と、追加で確立するPDNコネクションに必要なQoS情報を比較し、追加で確立するPDNコネクションに必要なQoS情報が、確立済みのPDNコネクションに割り当てられているQoS情報を満たすことができる場合、MTCデバイス100は確立済みPDNコネクションをリリースし、追加のPDNコネクションを確立することができる。これにより、MTCデバイスは優先度レベルが高いデータを送信することができ、MTCデバイス100やMTCサーバ150、MTCユーザ160などに優先度レベルが高いデータを送信できないなどの問題は解決される。
上記の本発明の第9の実施の形態と第10の実施の形態では、MTCデバイス100による確立済みのPDNコネクションの接続先と、追加で確立するPDNコネクションの接続先が同じであることを前提としている。
ここで、図35ではMTCデバイス100が複数の接続先とPDNコネクションを確立できる状態を示している。図35におけるMTCデバイスA100Aは、例えば、複数のMTCサーバ150に接続することができ、1つ目のPDNコネクション(確立済みのPDNコネクション)の接続先はMTCサーバA150Aで、2つ目のPDNコネクション(追加で確立するPDNコネクション)の接続先はMTCサーバB150Bになる場合がある。
MTCデバイスA100Aの接続先が異なる場合、本発明の第9の実施の形態と第10の実施の形態におけるPDNコネクションの確立拒絶レスポンスを受信した後の処理ステップとして、接続先を確認する処理が必要となる。
図36は、図25のステップS2502とステップS2503の間に接続先を確認する処理ステップを追加したものである。また、図35におけるMTCデバイスA100Aと図36におけるMTCデバイスA100Aは同一であるとする。
MTCサーバA150Aにデータを送信するためのPDNコネクションを確立済みのMTCデバイスA100Aが、MTCサーバB150Bにデータを送信するためのPDNコネクションを確立するためのPDNコネクション確立リクエストをネットワーク送信する(ステップS2501)。MTCサーバBにデータを送信するためのPDNコネクション確立リクエストを受信したネットワークは、(A)混雑発生によって、PDNコネクション確立拒絶レスポンスを送信する(ステップS2502)。
ここで、MTCデバイスA100Aは、確立済みのPDNコネクションをリリースして、追加のPDNコネクションを確立することができるかを判断するための処理として、確立済みのPDNコネクションの接続先と、追加のPDNコネクションの接続先が同じであるか否かを確認する(ステップS2520)。接続先を表す情報としては、APNを用いることができる。つまり、APNが同じであれば接続先が同じであると判断し、APNが異なれば接続先が異なると判断する。
確立済みのPDNコネクションの接続先と追加のPDNコネクションの接続先が同じである場合は、引き続き、第9の実施の形態と同様の処理(図25のステップS2503以降の処理)や第10の実施の形態と同様の処理(図31のステップS2903以降の処理)を行う。
しかしながら、確立済みのPDNコネクションの接続先と追加のPDNコネクションの接続先が異なる場合、例えば、追加のPDNコネクション確立リクエストを受信したMTCサーバB150Bでは混雑検出されているが、MTCデバイスA100Aによって既に確立済みのPDNコネクションを通してデータを転送されているMTCサーバA150Aでは混雑検出されていない(混雑が起こっていない)場合には、確立済みのPDNコネクションをリリースすることで確保されるリソースを、追加のPDNコネクションの確立に再使用することができないと判断する。なお、追加のPDNコネクション確立リクエストが拒絶されている理由は、MTCサーバB150Bにおける混雑検出以外に、ネットワーク(通信システム)のエンティティであるSGW−B130BやPGW−B140Bなどで起きている輻輳であってもよい。
ここで、MTCサーバA150Aにおいて混雑状態が起きていない状態で、MTCデバイスA100Aによって送信された追加のPDNコネクション確立リクエストが、MTCサーバB150Bの混雑状態により拒絶された場合、MTCデバイスA100Aは、MTCサーバA150Aにデータを送信するためのPDNコネクションをリリースしても、MTCサーバB150Bに送信するためのPDNコネクションを確立できない。そのため、MTCデバイスA100Aは、確立済みのPDNコネクションを維持し、追加のPDNコネクションの確立をキャンセルする。
また、確立済みのPDNコネクションの接続先と追加のPDNコネクションの接続先が異なる状態でも、MTCデバイスA100Aが拒絶された追加のPDNコネクションの接続先を変更できる場合(例えば、MTCサーバA150AとMTCサーバ150Bが同じオペレータによる管轄、若しくは、MTCユーザ160に接続されている場合や、MTCサーバ150AとMTCサーバB150B間でPDNコネクション移行の契約が交わされており、交渉を自動的に実施するなど)、MTCデバイスA100Aは、追加で確立するPDNコネクションの接続先を変更する。続いて、MTCデバイスA100Aは、確立済みのPDNコネクションの接続先であるMTCサーバA150AとのPDNコネクションをリリースし、MTCサーバA150Aにデータを転送するための追加のPDNコネクションを確立する。なお、追加のPDNコネクションの接続先を変更する処理と確立済みのPDNコネクションの接続先であるMTCサーバA150AとのPDNコネクションをリリースする処理は順不同である。
なお、この接続先はMTCサーバ150やMTCユーザ160のアドレスやIdentity(例えば、MTCサーバ TEID)、ネットワーク(通信システム)の装置であるPGWのアドレスやIdentity(例えば、PGW TEID)、APNなど接続先を識別できるものでもよい。
また、上記の実施の形態(特に第2〜第8の実施の形態)における逆イベント通知メッセージ(イベント情報)や送信制御メッセージには、イベント情報(例えば、デバイスIDやデバイス種ID)が格納されていたが、eNB IDやeNBアドレス(並びに、MTCデバイス100のEPSベアラに対応するS1-U TEID)、イベント通知メッセージ(イベント情報)@デバイスAの送信元であるMTCデバイスA100Aのアドレスや、MTCサービスで管理されている情報(例えば、MTCデバイスA100Aが位置する情報(例えば、3階、301号室、3丁目など))を追加することで、逆イベント通知メッセージ(イベント情報)を受信したMTCデバイス100がモード遷移する必要があるかどうかを判断させてもよい。
なお、本発明を説明する一例として、煙センサに通信モジュールを実装したMTCデバイスA100Aが、煙を検知した後に起こりうる冗長のイベント通知メッセージに対する抑制方法について説明したが、以下のケースにも適用可能である。
例えば、ガス管の状態(例えば、破損していないか)を確認するガス管センサに通信モジュールを実装した複数のMTCデバイスA100Aと主に居住スペースに配置されるガス漏れを検知するガスセンサに通信モジュールを実装した複数のMTCデバイスB100Bが、同じMTCグループで構成されている環境において、ガス管が破損することにより、MTCデバイスA100Aによって通知されるイベント通知メッセージ(イベント情報)@デバイスAを利用して、MTCデバイスB100Bのイベント通知メッセージを抑制してもよい。すなわち、MTCデバイスA100Aからイベント情報(例えば、ガス管センサID)が格納されたイベント通知メッセージ(イベント情報)@デバイスAを受け、ネットワーク装置(例えば、MME120やMTCサーバ150)が、イベント情報(例えば、ガス管センサID)を格納した逆イベント通知メッセージをMTCグループに属するMTCデバイス100に送信し、MTCデバイス100がモード遷移する必要があるか(優先度の高いイベント通知メッセージを送信するか)判断させてもよい。このようなMTCサービスに本発明を適用した場合、ガス管が破損することによって生じると予想されるガス管破損の誘発やガス漏れに対して、イベント(例えば、ガス管破損やガス漏れ)を検知した複数のMTCデバイス100による冗長な優先度の高いイベント通知メッセージを抑制することができ、MTCデバイス100とネットワーク装置(例えば、MME120やMTCサーバ150)の処理負荷を軽減、トラフィックを低減することができる。
また、例えば、エアバックと連動している衝撃センサを搭載済の乗用車に通信モジュールを実装したMTCデバイス100が、複数台の衝突事故(例えば、複数台による玉突き事故)を起こした場合、最初にネットワーク装置(例えば、MME120やMTCサーバ150)に通知された優先度の高いイベント通知メッセージを利用して、後続する優先度の高いイベント通知メッセージを抑制してもよい。すなわち、ネットワーク装置(例えば、MME120やMTCサーバ150)が、最初に受信したイベント通知メッセージのイベント情報(例えば、衝撃センサID)を格納した逆イベント通知メッセージを衝突事故が起きたエリア(例えば、イベント通知メッセージが送信されたeNB110配下)のMTCデバイス100にブロードキャストすることで、同一イベント、若しくは、そのイベントを引き起こした出来事によって引き起こされたイベントによる優先度の高いイベント通知メッセージを抑制することができる。このようなMTCサービスに本発明を適用した場合、衝撃センサを搭載した複数台の乗用車の衝突事故が発生した際に高い確率で生じる冗長な優先度の高いイベント通知メッセージを抑制することができ、MTCデバイス100とネットワーク装置(例えば、MME120やMTCサーバ150)の処理負荷を軽減、トラフィックを低減することができる。
また、例えば、土砂崩れを監視する加速度センサや傾斜センサに通信モジュールを実装したMTCデバイス100が、土砂崩れが起こりそうなエリア(例えば、山や崖)に複数設置されている環境において、土砂崩れが起こることにより、MTCデバイス100によって通知されるイベント通知メッセージを利用して、後続する優先度の高いイベント通知メッセージを抑制してもよい。すなわち、MTCデバイス100からイベント情報(例えば、加速度センサID)が格納されたイベント通知メッセージ(イベント情報)を受け、ネットワーク装置(例えば、MME120やMTCサーバ150)が、イベント情報(例えば、加速度センサID)を格納した逆イベント通知メッセージをMTCグループに属するMTCデバイス100に送信し、MTCデバイス100がモード遷移する必要があるか(優先度の高いイベント通知メッセージを送信するか)判断させてもよい。また、このような、あらかじめ単一の事象のみ監視するMTCサービスであることが定義されている環境においては、イベント情報(例えば、加速度センサID)を含めなくても、何のイベントが発生したか明らかであるため、省略してもよい。
また、例えば、振動センサに通信モジュールを実装したMTCデバイスによる陸橋の揺れ具合の監視から陸橋に異常がないか確認するMTCサービスなども同様に、本発明は適用可能である。
なお、上記の本発明の各実施の形態では、MTCデバイス100から通知されるイベント通知メッセージをトリガとして、ネットワーク装置(例えば、MME120やSGW130、PGW140、MTCサーバ150)が冗長なイベント通知メッセージを抑制するための逆イベント通知メッセージをブロードキャストしていたが、イベント通知メッセージではなく、例えば、MTCデバイス100とMTCデバイス100に組み込まれているUICC(Universal Integrated Circuit Card)の関連性の不一致を検知した場合や、MTCデバイス100上で機能しているMTC featureとHSSが保持するMTCデバイス100のサブスクリプションデータに登録されているMTC featureの整合が取れない場合や、設置場所が限定、若しくは、固定されているMTCデバイス100(例えば、自動販売機、煙センサ、炎センサ)、つまり、MTCデバイス100の位置情報の変化が起こりにくい環境(通信環境の変化や、基地局の負荷バランスによってMTCデバイス100の接続する基地局切り替えは除く)で、MTCデバイス100の位置情報の変化を検知した場合や、MTCデバイス100とネットワークの間のPDNコネクション、又は、EPSベアラが切断された場合などをトリガとして、逆イベント通知メッセージをブロードキャストしてもよい。
また、上記の本発明の各実施の形態では、MTCデバイス100から送信されたイベント通知メッセージを受信したネットワーク装置(例えば、MME120、SGW130、PGW140、MTCサーバ150)は、イベント通知メッセージの内容を他のネットワーク装置に転送していたが(例えば、本発明の第2の実施の形態では、イベント通知メッセージを受信したMME120が、SGW130、PGW140を経由してMTCサーバ150にイベント通知メッセージを転送、若しくは、必要な情報のみを転送している)、オペレータの方針やMTCアプリケーションの仕様などに基づいて、転送しなくてもよい。
また、上記の本発明の各実施の形態では、MTCデバイス100がネットワークとの間にPDNコネクションとEPSベアラを確立した後にイベントを検知していたが、イベントを検知した後にPDNコネクションとEPSベアラを確立し、イベント情報やセンシング情報を送信してもよい。
また、上記の本発明の各実施の形態では、逆イベント通知メッセージを送信するネットワーク装置は、MME120やPGW140、MTCサーバ150を例として挙げて説明していたが、これらに限定されるわけではなく、SGW130や外部のネットワークに位置する装置(例えば、ローミング先のネットワーク装置やAAAサーバ、SIPサーバ)が送信してもよい。
また、上記の本発明の各実施の形態では、イベント通知メッセージを受信したネットワーク装置(例えば、MME120、SGW130、PGW140、MTCサーバ150)が逆イベント通知メッセージをブロードキャストしていたが、例えば、ネットワーク装置(例えば、MME120、SGW130、PGW140、MTCサーバ150)がMTCデバイス100の接続先である基地局(eNB110)に逆イベント通知メッセージをブロードキャストするように指示し、eNB110が逆イベント通知メッセージをブロードキャストしてもよい。例えば、現在規定されているようにeNBがページングをブロードキャストし、UE105にETWSの情報を取得させる手段を利用、拡張することで、既存システムに大きな影響を与えることなく、本発明を実施することができる。
また、上記の本発明の各実施の形態では、イベント通知メッセージを受信したネットワーク装置(例えば、MME120、SGW130、PGW140、MTCサーバ150)は、逆イベント通知メッセージをブロードキャストして、冗長なイベント通知メッセージを抑制していたが、他の役割を持たせたメッセージをブロードキャストしてもよい。例えば、特定のエリアに複数の自動販売機(MTCデバイス100)が設置されている環境で、例えば、窃盗によって1つの自動販売機の位置情報が変化したことをネットワーク側が検知した場合、ネットワーク装置は自動販売機の位置情報変化をトリガとして、上記特定のエリアの複数の自動販売機に対して、各自動販売機の位置情報を送信すること(Tracking Area Update)を指示したメッセージをブロードキャストしてもよい。これにより、他の自動販売機の状況を定期的に実施される位置情報の更新時より迅速、かつ、確実に確認することができる。
また、上記の本発明の各実施の形態では、イベント通知メッセージを受信したネットワーク装置(例えば、MME120、SGW130、PGW140、MTCサーバ150)は、逆イベント通知メッセージをブロードキャストしていたが、逆イベント通知メッセージを送信するMTCデバイス100を把握している場合には、マルチキャストやユニキャストで実施してもよい。
なお、上記の本発明の各実施の形態の説明で用いた各機能ブロックは、典型的には集積回路であるLSI(Large Scale Integration)として実現される。これらは個別に1チップ化されてもよいし、一部又はすべてを含むように1チップ化されてもよい。なお、ここでは、LSIとしたが、集積度の違いにより、IC(Integrated Circuit)、システムLSI、スーパーLSI、ウルトラLSIと呼称されることもある。
また、集積回路化の手法はLSIに限るものではなく、専用回路又は汎用プロセッサで実現してもよい。LSI製造後に、プログラムすることが可能なFPGA(Field Programmable Gate Array)や、LSI内部の回路セルの接続や設定を再構成可能なリコンフィギュラブル・プロセッサを利用してもよい。
さらには、半導体技術の進歩又は派生する別技術によりLSIに置き換わる集積回路化の技術が登場すれば、当然、その技術を用いて機能ブロックの集積化を行ってもよい。例えば、バイオ技術の適応などが可能性としてあり得る。