JPWO2011129098A1 - 接続確立方法及び通信ノード - Google Patents
接続確立方法及び通信ノード Download PDFInfo
- Publication number
- JPWO2011129098A1 JPWO2011129098A1 JP2012510567A JP2012510567A JPWO2011129098A1 JP WO2011129098 A1 JPWO2011129098 A1 JP WO2011129098A1 JP 2012510567 A JP2012510567 A JP 2012510567A JP 2012510567 A JP2012510567 A JP 2012510567A JP WO2011129098 A1 JPWO2011129098 A1 JP WO2011129098A1
- Authority
- JP
- Japan
- Prior art keywords
- message
- mtc
- event
- mtc device
- information
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Granted
Links
- 238000004891 communication Methods 0.000 title claims abstract description 465
- 238000000034 method Methods 0.000 title claims abstract description 159
- 230000005540 biological transmission Effects 0.000 claims abstract description 430
- 230000007704 transition Effects 0.000 claims description 76
- 230000004044 response Effects 0.000 claims description 71
- 230000008859 change Effects 0.000 claims description 54
- 230000002441 reversible effect Effects 0.000 abstract description 468
- 239000000779 smoke Substances 0.000 abstract description 278
- 238000001514 detection method Methods 0.000 abstract description 52
- 208000037196 Medullary thyroid carcinoma Diseases 0.000 description 2801
- 208000023356 medullary thyroid gland carcinoma Diseases 0.000 description 2801
- 238000012545 processing Methods 0.000 description 247
- 230000006870 function Effects 0.000 description 191
- 238000012546 transfer Methods 0.000 description 72
- 238000007726 management method Methods 0.000 description 48
- 230000008569 process Effects 0.000 description 42
- 230000009471 action Effects 0.000 description 30
- 230000003111 delayed effect Effects 0.000 description 26
- 230000004048 modification Effects 0.000 description 26
- 238000012986 modification Methods 0.000 description 26
- 238000010586 diagram Methods 0.000 description 25
- 238000005516 engineering process Methods 0.000 description 20
- 230000002829 reductive effect Effects 0.000 description 20
- 238000012790 confirmation Methods 0.000 description 18
- 239000000284 extract Substances 0.000 description 18
- 230000001629 suppression Effects 0.000 description 18
- 230000000694 effects Effects 0.000 description 16
- 238000007796 conventional method Methods 0.000 description 12
- XLYOFNOQVPJJNP-UHFFFAOYSA-N water Substances O XLYOFNOQVPJJNP-UHFFFAOYSA-N 0.000 description 12
- 230000003068 static effect Effects 0.000 description 10
- 238000003860 storage Methods 0.000 description 10
- 230000001133 acceleration Effects 0.000 description 8
- 230000010354 integration Effects 0.000 description 8
- 230000011664 signaling Effects 0.000 description 8
- 101100435066 Caenorhabditis elegans apn-1 gene Proteins 0.000 description 6
- 238000013523 data management Methods 0.000 description 6
- 230000014759 maintenance of location Effects 0.000 description 6
- 238000012544 monitoring process Methods 0.000 description 6
- 230000001960 triggered effect Effects 0.000 description 6
- 230000008901 benefit Effects 0.000 description 4
- 230000001934 delay Effects 0.000 description 4
- 238000009826 distribution Methods 0.000 description 4
- 230000000670 limiting effect Effects 0.000 description 4
- 238000012423 maintenance Methods 0.000 description 4
- 238000004519 manufacturing process Methods 0.000 description 4
- 238000004705 quadratic configuration interaction calculation Methods 0.000 description 4
- 230000009467 reduction Effects 0.000 description 4
- 239000002699 waste material Substances 0.000 description 4
- 102100035409 Dehydrodolichyl diphosphate synthase complex subunit NUS1 Human genes 0.000 description 2
- 241000760358 Enodes Species 0.000 description 2
- 101100240466 Homo sapiens NUS1 gene Proteins 0.000 description 2
- 230000005856 abnormality Effects 0.000 description 2
- 230000002776 aggregation Effects 0.000 description 2
- 238000004220 aggregation Methods 0.000 description 2
- 238000013475 authorization Methods 0.000 description 2
- 238000004364 calculation method Methods 0.000 description 2
- 230000001413 cellular effect Effects 0.000 description 2
- 238000005520 cutting process Methods 0.000 description 2
- 230000009849 deactivation Effects 0.000 description 2
- 238000009434 installation Methods 0.000 description 2
- 239000000463 material Substances 0.000 description 2
- 230000005012 migration Effects 0.000 description 2
- 238000013508 migration Methods 0.000 description 2
- 230000006855 networking Effects 0.000 description 2
- 238000010606 normalization Methods 0.000 description 2
- 230000008520 organization Effects 0.000 description 2
- 230000002093 peripheral effect Effects 0.000 description 2
- 229920002401 polyacrylamide Polymers 0.000 description 2
- 238000003672 processing method Methods 0.000 description 2
- 230000000717 retained effect Effects 0.000 description 2
- 239000004065 semiconductor Substances 0.000 description 2
- 241000894007 species Species 0.000 description 2
- 230000001360 synchronised effect Effects 0.000 description 2
- 238000010200 validation analysis Methods 0.000 description 2
- 229960001716 benzalkonium Drugs 0.000 description 1
- CYDRXTMLKJDRQH-UHFFFAOYSA-N benzododecinium Chemical compound CCCCCCCCCCCC[N+](C)(C)CC1=CC=CC=C1 CYDRXTMLKJDRQH-UHFFFAOYSA-N 0.000 description 1
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04Q—SELECTING
- H04Q3/00—Selecting arrangements
- H04Q3/0016—Arrangements providing connection between exchanges
- H04Q3/0029—Provisions for intelligent networking
- H04Q3/0045—Provisions for intelligent networking involving hybrid, i.e. a mixture of public and private, or multi-vendor systems
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W28/00—Network traffic management; Network resource management
- H04W28/02—Traffic management, e.g. flow control or congestion control
- H04W28/0215—Traffic management, e.g. flow control or congestion control based on user or device properties, e.g. MTC-capable devices
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W28/00—Network traffic management; Network resource management
- H04W28/02—Traffic management, e.g. flow control or congestion control
- H04W28/0289—Congestion control
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
- H04W4/70—Services for machine-to-machine communication [M2M] or machine type communication [MTC]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W76/00—Connection management
- H04W76/10—Connection setup
- H04W76/18—Management of setup rejection or failure
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04M—TELEPHONIC COMMUNICATION
- H04M2203/00—Aspects of automatic or semi-automatic exchanges
- H04M2203/20—Aspects of automatic or semi-automatic exchanges related to features of supplementary services
- H04M2203/205—Broadcasting
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04M—TELEPHONIC COMMUNICATION
- H04M2242/00—Special services or facilities
- H04M2242/04—Special services or facilities for emergency applications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
- H04W4/12—Messaging; Mailboxes; Announcements
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W76/00—Connection management
- H04W76/10—Connection setup
- H04W76/12—Setup of transport tunnels
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W76/00—Connection management
- H04W76/20—Manipulation of established connections
- H04W76/22—Manipulation of transport tunnels
Abstract
多数の通信ノード（ＭＴＣデバイス）から送信されるイベント通知メッセージ数を低減させる技術が開示され、その技術によればＭＴＣデバイスＡ１００Ａがイベント（煙センサによる煙の検知）を検知した際、ＭＴＣサーバ１５０にイベント通知メッセージを送信すると、ネットワーク側は、イベント通知メッセージの受信によって、ＭＴＣデバイスによるイベントの検知を確認し、複数のＭＴＣデバイスに対して、例えばブロードキャストによって逆イベント通知メッセージを送信する。この逆イベント通知メッセージは、同一イベント（煙の検知）、若しくは、そのイベント（煙の検知）を引き起こした出来事（火災発生）によって引き起こされた別のイベント（炎の発生など）を検知した場合であっても、高優先度モードで通知メッセージを送信しないよう指示するものであり、これによって、後続の冗長なイベント通知メッセージの送信を抑制することが可能となる。
Description
本発明は、ネットワークにメッセージを送信する際に、メッセージの送信の判断を行う通信ノード及びネットワークノードに関し、特にＭＴＣ（Machine Type Communications、Ｍ２Ｍ（Machine to Machine）通信とも呼ばれる）における通信ノード（以降、ＭＴＣデバイスと呼ぶ）がイベントを検知して、ネットワークにメッセージを送信する際にメッセージの送信の判断を行う通信ノード及びネットワークノードに関する。
現在、携帯電話（User Equipment：ＵＥ）に用いる技術の標準化団体である３ＧＰＰ（The third Generation Partnership Project）では、ＭＴＣで用いられる技術の標準化が行われている（下記の非特許文献１、２を参照）。ＭＴＣは、ＭＴＣデバイス（例えば、自動販売機や街頭広告ディスプレイ、煙センサ、セキュリティカメラ、人感センサなどの装置や機械に組み込まれた通信モジュール、又は、その総称）と、ＭＴＣデバイスによる通信の制御や、状態管理、またアプリケーションサービス（ＭＴＣサービスとも呼ぶ）を提供するサーバであるＭＴＣサーバ、さらにＭＴＣデバイスやＭＴＣサーバに対して、アプリケーションの制御や管理を実施するＭＴＣユーザから構成される。ＭＴＣでは、従来のＵＥのためのモビリティ制御（移動制御や移動管理、位置管理とも呼ぶ）などの既存機能を活用することを目的として、ＧＥＲＡＮ（GSM EDGE Radio Access Network）やＵＴＲＡＮ（Universal Terrestrial Radio Access Network）、Ｅ−ＵＴＲＡＮ（Evolved UTRAN）などの３ＧＰＰの規格に基づくアクセスネットワーク（以降、通信システムと呼ぶ）の使用を前提とする。つまり、ＭＴＣデバイスは、通信システム内で従来のＵＥと共存しながら通信を行う。ここで、ＵＥは人がユーザインタフェースを通じて操作する移動端末であり、ＭＴＣデバイスは人が直接操作するものではなく、端末又は装置に埋め込まれており、通信システムを介して操作するものとする。ＭＴＣ通信ネットワークの構成の一例を図１に示す。
図１には、ＭＴＣデバイス１００、ＵＥ１０５、ＭＴＣデバイス１００やＵＥ１０５と無線接続する基地局（Ｅ−ＵＴＲＡＮではｅＮＢ（eNode B）、ＵＴＲＡＮではＮＢ（Node B）と呼ばれる）１１０、Ｅ−ＵＴＲＡＮ１１５上のＭＴＣデバイス１００やＵＥ１０５の移動管理を担当するＭＭＥ（Mobility Management Entity）１２０、ＭＴＣデバイス１００やＵＥ１０５のＥ−ＵＴＲＡＮ１１５に対するユーザデータ配信制御を行うＳＧＷ（Serving Gateway、ＭＡＧ（Mobility Anchor Gateway：モビリティアンカポイント）などとも呼ばれる）１３０、ＭＴＣデバイス１００やＵＥ１０５に対するアドレス割り当てやＰＤＮ（Packet Data Network）１５５とＳＧＷ１３０間のユーザデータ転送並びに経路制御を行うＰＧＷ（Packet Gateway、ＨＡ（Home Agent：ホームエージェント）やＬＭＡ（Local Mobility Anchor：ローカルモビリティアンカ）などとも呼ばれる）１４０、ＭＴＣデバイス１００やＵＥ１０５のサブスクリプションデータ（Subscription data）並びに通信コンテキストなどを管理保持しているＨＳＳ（Home Subscriber Server）１２５、ＭＴＣデバイス１００による通信の制御や状態管理、アプリケーションサービスを提供するサーバであるＭＴＣサーバ１５０、ＭＴＣデバイス１００やＭＴＣサーバ１５０に対してアプリケーションの管理・制御やアプリケーションデータの管理を実施するＭＴＣユーザ１６０から構成されるネットワーク構成の一例が図示されている。
図１において、ＭＴＣデバイス１００が通信システムを介してＭＴＣサーバ１５０（サービスを提供するサーバ）と通信を行う際、ＭＴＣデバイス１００は、ＰＧＷ１４０とＰＤＮコネクション及びＥＰＳベアラを確立する（下記の非特許文献３を参照）。ＭＴＣデバイス１００が取得したデータ（例えば、煙センサにおける煙検知情報などのセンシングデータ）は、確立したＰＤＮコネクション及びＥＰＳベアラを通じてＰＧＷ１４０に送信され、ＰＧＷ１４０からＭＴＣサーバ１５０に転送される。ＭＴＣサーバ１５０は、ＭＴＣデバイス１００から送られてきたデータを、定義されたタイミング（例えば、ＭＴＣデバイス１００からデータ受信後、又は、ＭＴＣユーザ１６０からのリクエストメッセージ受信後など）で、ＭＴＣユーザ１６０に提供する。
ＭＴＣデバイス１００が取得したデータをＭＴＣサーバ１５０に送信するタイミングは、ＭＴＣデバイス１００が搭載する特徴（ＭＴＣ Ｆｅａｔｕｒｅ、以下、ＭＴＣの機能と記載することもある）や通信システムオペレータの指示、ＭＴＣサービスの内容によって決まる。例えば、ＭＴＣデバイス１００が非特許文献１で定義されているＭＴＣの機能の１つである“Ｔｉｍｅ Ｃｏｎｔｒｏｌｌｅｄ”（時間制御）を搭載する場合、すなわち、ＭＴＣデバイス１００が通信動作を実施する時間が制限されている場合、ＭＴＣデバイス１００は、所定の時間（例えば通信システムオペレータから割り当てられたり、ＭＴＣユーザ１６０が設定したりする）に限り、ＭＴＣサーバ１５０へのアクセスが許可され、取得したデータを送信する。また、ＭＴＣデバイス１００が非特許文献１で定義されている“ＰＡＭ（Priority Alarm Message）”を搭載する場合、すなわち、ＭＴＣデバイス１００が優先度の高いメッセージをＭＴＣサーバ１５０／ＭＴＣユーザ１６０に送信できる場合、ＭＴＣデバイス１００がイベント（例えば、煙検知、炎検知、盗難など）を検知時に、他のメッセージより優先的にメッセージを送信し、ＭＴＣサーバ１５０に転送される。なお、ＰＡＭは緊急情報通知にも相当するため、アプリケーション設定や通信オペレータのポリシにより、上記“Ｔｉｍｅ Ｃｏｎｔｒｏｌｌｅｄ”による制約を受けることなく、任意のタイミングでも送信を許可される場合がある。
また、その他の非特許文献１で定義されるＭＴＣの機能として、“Ｇｒｏｕｐ ｂａｓｅｄ”をＭＴＣデバイス１００が搭載する場合、すなわち、ＭＴＣサーバ１５０／ＭＴＣユーザ１６０、又は、通信システムのオペレータの要望（例えば、ＭＴＣデバイス１００の管理を容易化、又は、ＩＭＳＩ（International Mobile Subscriber Identity）の共有化など）の下、複数のＭＴＣデバイス１００を管理する場合、複数のＭＴＣデバイス１００を１つのグループ（以降、ＭＴＣグループと呼ぶ）として扱うことで、例えばＨＳＳ１２５は、通常ＭＴＣデバイス１００毎に管理保持するサブスクリプションデータの全体あるいは一部を、ＭＴＣグループ単位に集約して管理保持することができる。
ＭＴＣデバイス１００が“Ｌｏｗ ｍｏｂｉｌｉｔｙ”を搭載している場合、すなわちＭＴＣデバイス１００が限られた範囲でしか移動しない（例えば、所定のＴＡ（Tracking Area）やセル範囲に限定して移動する）、あるいは自動販売機のように装置として固定される場合、位置情報を更新するための、例えば、ＴＡＵ（Tracking Area Update）やＲＡＵ（Routing Area Update）の実施頻度をＵＥ１０５と比較して抑えることができ、ＭＴＣデバイス１００と移動管理を行う通信ノード（例えば、ＭＭＥ１２０やＰＧＷ１４０など）におけるモビリティ制御による負荷を軽減できる。
このように、ＭＴＣデバイスは、ＭＴＣユーザ１６０の要求に基づいて、ＭＴＣの機能（Ｆｅａｔｕｒｅ）を複数搭載することができる。また、ＭＴＣデバイス１００とＭＴＣサーバ１５０／ＭＴＣユーザ１６０との間の需要に応じて、ＭＴＣデバイス１００が有するＭＴＣの機能を有効化（Ａｃｔｉｖａｔｅ）／無効化（Ｄｅａｃｔｉｖａｔｅ）することができる（機能や動作の有効化／無効化）。
従来のＵＥ１０５と比較した場合、膨大な数のＭＴＣデバイス１００が通信システムを介して同時に通信を行うことが想定されるため、ＵＥ１０５による通信を妨害しないためにも、ＭＴＣデバイス１００による通信に対応し得るネットワークの改良が必要である。
3GPP TS 22.368 V1.1.1，November 2009
3GPP TR 23.888 V0.1.1，December 2009
3GPP TS 23.401 V9.3.0，December 2009
3GPP TS 33.402 V9.2.0，December 2009
3GPP TS 36.300 V9.2.0，December 2009
3GPP TR 23.888 V0.4.1，June 2010
しかしながら、従来の通信システムでは、複数のＭＴＣデバイスがイベントを検知し、優先度の高いイベント通知メッセージを送信する場合に課題が生じる。以下、図２を参照しながら説明する。
なお、ここでは、シナリオとして、非特許文献１で定義される、ＭＴＣの機能のうち、“Ｔｉｍｅ ｃｏｎｔｒｏｌｌｅｄ”と“ＰＡＭ”、“Ｇｒｏｕｐ ｂａｓｅｄ”、“Ｌｏｗ ｍｏｂｉｌｉｔｙ”を搭載する複数のＭＴＣデバイス１００（例えば、煙センサ、炎センサ、人感センサ）が１つのＭＴＣグループを形成し、マンション群のセキュリティを監視している環境において、マンション火災が発生する場合を考える。このとき、あるＭＴＣデバイス１００（例えば、煙センサ）が火災発生を認識する発端となるイベント（煙）を検知し（煙発生）、その後、他のＭＴＣデバイス（例えば、人感センサ）がイベント（人の有無）を検知する。
まず、煙センサに搭載されたＭＴＣデバイス（ＭＴＣデバイスＡ１００Ａ）はＭＴＣサーバ１５０と通信するためのＰＤＮコネクションを確立する（図２のステップＳ２００１：ＰＤＮコネクション確立済み）。なお、ＭＴＣデバイスＢ１００Ｂも、同様にＰＧＷ１４０とＰＤＮコネクションを確立する（図２のステップＳ２００４：ＰＤＮコネクション確立済み）。
ＭＴＣデバイスＡ１００Ａ（煙センサ）がイベント（煙）を検知したとする（図２のステップＳ２００２：イベント検知）。イベントを検知したＭＴＣデバイスＡ１００Ａは、ＰＡＭを用いて、煙を検知したことをＭＴＣサーバ１５０に通知する（図２のステップＳ２００３：イベント通知メッセージ＠デバイスＡ）。
一方、他の箇所に設置された複数のＭＴＣデバイスＢ１００Ｂ（他の煙センサや、炎センサなど）も火災発生を検知し（図２のステップＳ２００５）、火災発生を検知したことを、優先度の高いイベント通知メッセージ（例えば、ＰＡＭ）を用いて報告する（図２のステップＳ２００６）。例えば、他の煙センサも同様に煙を検出し、他の煙センサに搭載されたＭＴＣデバイスＢ１００Ｂも、煙の検出を優先度の高いイベント通知メッセージ（例えば、ＰＡＭ）を用いて報告する。また、例えば炎センサが、炎から発せられる紫外線を検出し、炎センサに搭載されたＭＴＣデバイスＢ１００Ｂが、ＭＴＣサーバ１５０に対して、炎から発せられる紫外線を検出したことを優先度の高いメッセージで通知することも考えられる。なお、他の煙センサや炎センサの設置数は膨大な数になることもある。
その結果、既存の通信システムでは、ＭＴＣサーバ１５０が最初のＭＴＣデバイスＡ１００ＡからのＰＡＭによって既に火災発生を検知できているにもかかわらず、同様に火災発生を検知した多数のＭＴＣデバイスＢ１００ＢからもＰＡＭを受信して、受信した全てのＰＡＭを処理しなければならなくなる。その結果、ＭＴＣサーバ１５０における処理負荷やネットワークのトラフィック負荷が増加してしまうことになる。また、火災発生を検出した後に必要とされるイベント検知（例えば、上記では人の有無）の送受信が遅延したり欠損したりすることにより、災害に迅速に対応できないといった問題も考えられる。
同様の問題は、例えば、工場に設置された複数のガスセンサが、ガス漏れを検知したことを、ＰＡＭを用いてＭＴＣサーバ１５０に送信するようなシナリオでも起こり得る。すなわち、この場合も、冗長な処理負荷やネットワークのトラフィック負荷が増加してしまう。
すなわち、多数のＭＴＣデバイス１００が設置されている環境においては、あるＭＴＣデバイス１００が、イベント（煙の発生）を検知したことを優先的にネットワーク側へ通知することで、そのイベントの通知からある出来事（例えば、火災発生）が起こっていることをネットワーク側で把握できるにもかかわらず、多数のＭＴＣデバイス１００から同様に高優先度モードにて通知されてくるイベント通知メッセージ（冗長なイベント通知メッセージ）を処理しなければならず、処理負荷が増加するという問題がある。また、多数のイベント通知メッセージが流れることでネットワークのトラフィックが増加してしまい、ネットワーク側に対して、例えば、別のイベントの発生を示す情報が遅延してしまったり、あるいは、届かなかったりする可能性もある。
上記の問題を解決するため、本発明は、ネットワーク側にかかる負荷（ＭＴＣサーバ及び通信システムのエンティティ（ｅＮＢ、ＭＭＥ、ＳＧＷ、ＰＧＷなど）の処理負荷やネットワークにおけるトラフィック量など）を低減させるための通信ノード及びネットワークノードを提供することを目的とする。また、本発明は、多数のＭＴＣデバイスが設置されている環境において、通信システムを通じてＭＴＣサーバと通信を行うＭＴＣデバイスがイベントを検知する状況となった場合に、ＭＴＣサーバ及び通信システムのエンティティ（ｅＮＢ、ＭＭＥ、ＳＧＷ、ＰＧＷなど）の処理負荷やネットワークにおけるトラフィック量を低減させるための通信ノード及びネットワークノードを提供することを目的とする。また、本発明は、ネットワーク側で混雑状況が検知された場合に、ＭＴＣサーバ及び通信システムのエンティティ（ｅＮＢ、ＭＭＥ、ＳＧＷ、ＰＧＷなど）の処理負荷やネットワークにおけるトラフィック量を低減させるための通信ノード及びネットワークノードを提供することを目的とする。
上記の目的を達成するため、本発明の通信ノードは、ネットワーク側のエンティティが他の通信ノードからの通知に応じて送信する制御メッセージ、又は、前記他の通信ノードとの間の通信状況に応じて送信する制御メッセージであって、特定の条件に当てはまる通信ノードの通信モードを変更するよう指示する前記制御メッセージをネットワーク側から受信し、受信した前記制御メッセージに含まれている前記特定の条件を参照して、前記特定の条件に当てはまる場合には、前記通信モードを変更するよう制御する通信制御部を有する。
この構成により、ネットワーク側にかかる負荷（ＭＴＣサーバ及び通信システムのエンティティ（ｅＮＢ、ＭＭＥ、ＳＧＷ、ＰＧＷなど）の処理負荷やネットワークにおけるトラフィック量など）を低減させることが可能となる。
この構成により、ネットワーク側にかかる負荷（ＭＴＣサーバ及び通信システムのエンティティ（ｅＮＢ、ＭＭＥ、ＳＧＷ、ＰＧＷなど）の処理負荷やネットワークにおけるトラフィック量など）を低減させることが可能となる。
上記の目的を達成するため、本発明の通信ノードは、前記通信制御部が、特定のイベントの発生を検知するためのセンサによって検知されたセンシングデータを通常の優先度で送信するノーマルモード、又は、前記センサによって前記特定のイベントの発生を検知したことを通知するイベント通知メッセージを前記ノーマルモードの優先度よりも高い優先度で送信する高優先度モードのいずれかの送信モードで動作を行うよう制御する動作モード制御部と、
ネットワークノードへ、前記高優先度モードによる前記イベント通知メッセージの送信又は前記ノーマルモードによる前記センシングデータの送信を行う送信部と、
特定のイベントの発生を検知したことを通知するイベント通知メッセージを任意の通信ノードから受信した前記ネットワークノードから、前記任意の通信ノードからのイベント通知メッセージに対する応答として送信されるメッセージであって、送信モードを前記ノーマルモードへ遷移するか又は前記ノーマルモードのまま維持するよう指示する前記メッセージを受信するメッセージ受信部と、
前記メッセージを受信した場合に、前記送信モードを前記ノーマルモードへ遷移するか又は前記ノーマルモードのまま維持するかどうかを判断するモード遷移判断部とを、
有し、
前記送信モードを前記ノーマルモードへ遷移するか又は前記ノーマルモードのまま維持すると前記モード遷移判断部が判断した場合には、前記動作モード制御部が、前記送信モードを前記ノーマルモードへ遷移するか又は前記ノーマルモードのまま維持するよう構成されている。
この構成により、多数の通信ノード（ＭＴＣデバイス）が設置されている環境において、通信システムを通じてサーバ（ＭＴＣサーバ）と通信を行う通信ノードがイベントを検知及び通知する状況となった場合に、ＭＴＣサーバ及び通信システムのエンティティ（ｅＮＢ、ＭＭＥ、ＳＧＷ、ＰＧＷなど）の処理負荷やネットワークにおけるトラフィック量を低減させることが可能となる。
ネットワークノードへ、前記高優先度モードによる前記イベント通知メッセージの送信又は前記ノーマルモードによる前記センシングデータの送信を行う送信部と、
特定のイベントの発生を検知したことを通知するイベント通知メッセージを任意の通信ノードから受信した前記ネットワークノードから、前記任意の通信ノードからのイベント通知メッセージに対する応答として送信されるメッセージであって、送信モードを前記ノーマルモードへ遷移するか又は前記ノーマルモードのまま維持するよう指示する前記メッセージを受信するメッセージ受信部と、
前記メッセージを受信した場合に、前記送信モードを前記ノーマルモードへ遷移するか又は前記ノーマルモードのまま維持するかどうかを判断するモード遷移判断部とを、
有し、
前記送信モードを前記ノーマルモードへ遷移するか又は前記ノーマルモードのまま維持すると前記モード遷移判断部が判断した場合には、前記動作モード制御部が、前記送信モードを前記ノーマルモードへ遷移するか又は前記ノーマルモードのまま維持するよう構成されている。
この構成により、多数の通信ノード（ＭＴＣデバイス）が設置されている環境において、通信システムを通じてサーバ（ＭＴＣサーバ）と通信を行う通信ノードがイベントを検知及び通知する状況となった場合に、ＭＴＣサーバ及び通信システムのエンティティ（ｅＮＢ、ＭＭＥ、ＳＧＷ、ＰＧＷなど）の処理負荷やネットワークにおけるトラフィック量を低減させることが可能となる。
また、上記の目的を達成するため、本発明の通信ノードは、前記通信制御部が、
ネットワークにおいて混雑状態が検知された場合にネットワークノードから送信されるメッセージであって、マシンタイプ通信において規定されている耐時間性機能を有している通信ノードは前記ネットワークへの接続を抑制するよう指示する情報を含む前記メッセージを受信するメッセージ受信部と、
前記メッセージを受信した場合、自通信ノードが前記耐時間性機能を有しているか否かを判断する機能判断部と、
前記耐時間性機能を有していると判断された場合、前記ネットワークとの間で確立されている接続を切断する、若しくは、前記ネットワークとの間で確立されている接続は維持したままデータ送信を制御するか、又は、前記ネットワークとの間で接続が確立されていない場合には前記ネットワークへの接続要求を行わないように制御する接続制御部とを、
有する。
この構成により、ネットワーク側で混雑状況が検知された場合に、ＭＴＣサーバ及び通信システムのエンティティ（ｅＮＢ、ＭＭＥ、ＳＧＷ、ＰＧＷなど）の処理負荷やネットワークにおけるトラフィック量を低減させることが可能となる。
ネットワークにおいて混雑状態が検知された場合にネットワークノードから送信されるメッセージであって、マシンタイプ通信において規定されている耐時間性機能を有している通信ノードは前記ネットワークへの接続を抑制するよう指示する情報を含む前記メッセージを受信するメッセージ受信部と、
前記メッセージを受信した場合、自通信ノードが前記耐時間性機能を有しているか否かを判断する機能判断部と、
前記耐時間性機能を有していると判断された場合、前記ネットワークとの間で確立されている接続を切断する、若しくは、前記ネットワークとの間で確立されている接続は維持したままデータ送信を制御するか、又は、前記ネットワークとの間で接続が確立されていない場合には前記ネットワークへの接続要求を行わないように制御する接続制御部とを、
有する。
この構成により、ネットワーク側で混雑状況が検知された場合に、ＭＴＣサーバ及び通信システムのエンティティ（ｅＮＢ、ＭＭＥ、ＳＧＷ、ＰＧＷなど）の処理負荷やネットワークにおけるトラフィック量を低減させることが可能となる。
また、上記の目的を達成するため、本発明のネットワークノードは、ネットワーク側のエンティティが他の通信ノードからの通知に応じて送信する制御メッセージ、又は、前記他の通信ノードとの間の通信状況に応じて送信する制御メッセージに、特定の条件に当てはまる通信ノードの通信モードを変更するよう指示する情報を含ませ、前記特定の条件に当てはまる通信ノードの通信モードを変更させるよう制御する通信制御部を有する。
この構成により、ネットワーク側にかかる負荷（ＭＴＣサーバの処理負荷やネットワークにおけるトラフィック量など）を低減させることが可能となる。
この構成により、ネットワーク側にかかる負荷（ＭＴＣサーバの処理負荷やネットワークにおけるトラフィック量など）を低減させることが可能となる。
また、上記の目的を達成するため、本発明のネットワークノードは、通信制御部が、特定のイベントの発生を検知するためのセンサによって検知されたセンシングデータを通常の優先度で送信するノーマルモード、又は、前記センサによって前記特定のイベントの発生を検知したことを通知するイベント通知メッセージを前記ノーマルモードの優先度よりも高い優先度で送信する高優先度モードのいずれかの送信モードで動作を行う前記複数の通信ノードと接続されているネットワークノードであって、
前記複数の通信ノードのいずれか１つから、特定のイベントの発生を検知したことを通知する前記イベント通知メッセージを受信する受信部と、
前記イベント通知メッセージに対する応答として、送信モードを前記ノーマルモードへ遷移するか又は前記ノーマルモードのまま維持するよう指示するメッセージを作成するメッセージ作成部と、
前記メッセージを前記複数の通信ノードへ送信するメッセージ送信部とを、
有する。
この構成により、多数の通信ノード（ＭＴＣデバイス）が設置されている環境において、通信システムを通じてサーバ（ＭＴＣサーバ）と通信を行う通信ノードがイベントを検知及び通知する状況となった場合に、ＭＴＣサーバ及び通信システムのエンティティ（ｅＮＢ、ＭＭＥ、ＳＧＷ、ＰＧＷなど）の処理負荷やネットワークにおけるトラフィック量を低減させることが可能となる。
前記複数の通信ノードのいずれか１つから、特定のイベントの発生を検知したことを通知する前記イベント通知メッセージを受信する受信部と、
前記イベント通知メッセージに対する応答として、送信モードを前記ノーマルモードへ遷移するか又は前記ノーマルモードのまま維持するよう指示するメッセージを作成するメッセージ作成部と、
前記メッセージを前記複数の通信ノードへ送信するメッセージ送信部とを、
有する。
この構成により、多数の通信ノード（ＭＴＣデバイス）が設置されている環境において、通信システムを通じてサーバ（ＭＴＣサーバ）と通信を行う通信ノードがイベントを検知及び通知する状況となった場合に、ＭＴＣサーバ及び通信システムのエンティティ（ｅＮＢ、ＭＭＥ、ＳＧＷ、ＰＧＷなど）の処理負荷やネットワークにおけるトラフィック量を低減させることが可能となる。
また、上記の目的を達成するため、本発明のネットワークノードは、前記通信制御部が、
混雑状態が検知された場合に、マシンタイプ通信において規定されている時間制御機能を有している通信ノードは前記ネットワークへの接続を抑制するよう指示する情報を前記メッセージに含ませるメッセージ作成部を有する。
この構成により、ネットワーク側で混雑状況が検知された場合に、ＭＴＣサーバ及び通信システムのエンティティ（ｅＮＢ、ＭＭＥ、ＳＧＷ、ＰＧＷなど）の処理負荷やネットワークにおけるトラフィック量を低減させるための通信ノード及びネットワークノードを提供することを目的とする。
混雑状態が検知された場合に、マシンタイプ通信において規定されている時間制御機能を有している通信ノードは前記ネットワークへの接続を抑制するよう指示する情報を前記メッセージに含ませるメッセージ作成部を有する。
この構成により、ネットワーク側で混雑状況が検知された場合に、ＭＴＣサーバ及び通信システムのエンティティ（ｅＮＢ、ＭＭＥ、ＳＧＷ、ＰＧＷなど）の処理負荷やネットワークにおけるトラフィック量を低減させるための通信ノード及びネットワークノードを提供することを目的とする。
本発明は、上記の構成を有しており、ネットワーク側にかかる負荷（ＭＴＣサーバ及び通信システムのエンティティ（ｅＮＢ、ＭＭＥ、ＳＧＷ、ＰＧＷなど）の処理負荷やネットワークにおけるトラフィック量など）を低減させるという効果を有する。また、多数の通信ノード（ＭＴＣデバイス）が設置されている環境において、通信システムを通じてサーバ（ＭＴＣサーバ）と通信を行う通信ノードがイベントを検知及び通知する状況となった場合に、サーバの処理負荷やネットワークにおけるトラフィック量を低減させるという効果を有する。また、ネットワーク側で混雑状況が検知された場合に、ＭＴＣサーバ及び通信システムのエンティティ（ｅＮＢ、ＭＭＥ、ＳＧＷ、ＰＧＷなど）の処理負荷やネットワークにおけるトラフィック量を低減させるという効果を有する。
また、本発明は、通常時には検知した情報をノーマルモードでＭＴＣサーバ１５０に送信していたＭＴＣデバイスの送信モードを、緊急時（ある出来事が起こった場合）に、高優先度モードへ切り替えさせることができるという効果を有している。
以下、図面を参照しながら、本発明の第１〜第３の実施の形態について説明する。
＜システム構成＞
まず、図１を参照しながら、本発明の第１〜第３の実施の形態に共通するシステム構成について説明する。図１は、本発明の第１〜第３の実施の形態に共通するシステム構成の一例を示す図である。
まず、図１を参照しながら、本発明の第１〜第３の実施の形態に共通するシステム構成について説明する。図１は、本発明の第１〜第３の実施の形態に共通するシステム構成の一例を示す図である。
上述のように、図１に図示されている通信システムは、少なくともＭＴＣデバイス１００、ＵＥ１０５、ＭＴＣデバイス１００やＵＥ１０５と無線接続する基地局（ｅＮＢ又はＮＢ）１１０、Ｅ−ＵＴＲＡＮ１１５上のＭＴＣデバイス１００やＵＥ１０５の移動管理を担当するＭＭＥ１２０、ＭＴＣデバイス１００やＵＥ１０５のＥ−ＵＴＲＡＮ１１５に対するユーザデータ配信制御を行うＳＧＷ１３０、ＭＴＣデバイス１００やＵＥ１０５に対するアドレス割り当てやＰＤＮ１５５とＳＧＷ１３０間のユーザデータ転送並びに経路制御を行うＰＧＷ１４０、ＭＴＣデバイス１００やＵＥ１０５のサブスクリプションデータ並びに通信コンテキストなどを管理保持しているＨＳＳ１２５、ＭＴＣデバイス１００による通信の制御や状態管理、アプリケーションサービスの提供などを行うサーバであるＭＴＣサーバ１５０、ＭＴＣデバイス１００やＭＴＣサーバ１５０に対してアプリケーションの管理・制御やアプリケーションデータの管理を実施するＭＴＣユーザ１６０を有している。なお、ＭＴＣユーザ１６０は、また、ＨＳＳ１２５の代わりに、ＡＡＡ（Authentication, authorization and Accounting）サーバを用いてもよい。また、ＡＡＡサーバとＨＳＳ１２５は、物理的又は論理的に同一の装置に実装されるものであってもよい。
なお、図１において、ＭＴＣサーバ１５０はＰＤＮ１５５内に位置しているが、通信システムのオペレータドメイン内に位置していてもよく、例えば、ＰＧＷ１４０がＭＴＣサーバ１５０の機能を担ってもよい。
ここで、ＭＴＣデバイス１００は少なくとも１つ以上の通信インタフェースを持ち、通信システム（例えば、Ｅ−ＵＴＲＡＮ１１５）に接続することが可能である。なお、ＭＴＣデバイス１００は、図示されている通信システム以外のネットワーク（例えば、ＵＴＲＡＮ、ＷＬＡＮ（Wireless LAN）ネットワークやＷｉＭＡＸネットワーク）に、同時に、あるいは排他的に接続するものであってもよい。ＭＴＣデバイス１００は、接続した通信システムを通じて、ＭＴＣサーバ１５０と通信可能であり、ＭＴＣサーバ１５０はＭＴＣユーザ１６０と通信可能である。
また、ＭＴＣデバイス１００は、通信システム内で従来のＵＥ１０５と共存しながら通信を行う。なお、図１では、ＭＴＣデバイス１００とＵＥ１０５とがそれぞれ異なるｅＮＢ１１０に接続しているが、ＭＴＣデバイス用のｅＮＢ１１０が区別されているわけではなく、どのｅＮＢ１１０と接続してもよいものとする。しかし、今後、ＭＴＣデバイス１００が、ＭＴＣデバイス１００用にカスタマイズされたｅＮＢ１１０のみに接続が許されるという環境に変化した場合、ＭＴＣデバイス１００はＭＴＣデバイス１００用のｅＮＢ１１０に接続されてもよい。
また、各ＭＴＣデバイス１００は、ＵＥ１０５と同様にＭＴＣデバイス１００を識別するためのＩＤ（以降、デバイスＩＤと呼ぶ）が割り当てられていることとする。同様に、ＭＴＣデバイス１００がＭＴＣグループを形成する場合、ＭＴＣグループを識別するためのＩＤ（以降、グループＩＤと呼ぶ）が割り当てられていることとする。同様に、ＭＴＣデバイス１００は、デバイスの種類（例えば、煙センサ）を識別するためのＩＤ（以降、デバイス種ＩＤと呼ぶ）が割り当てられていることとする。なお、ＭＴＣデバイス１００の種類は、そのＭＴＣデバイス１００が搭載又は接続されている装置の種類によって決まる。また、ＭＴＣデバイス１００の種類は、ＭＴＣサーバ、ＭＴＣユーザ、又は、通信システムのオペレータによって設定されてもよい。
なお、ＭＴＣデバイス１００、通信システムのエンティティ（例えば、ＭＭＥ１２０、ＰＧＷ１４０など）、ＭＴＣサーバ１５０が、デバイス種ＩＤを用いずに、ＭＴＣデバイス１００の種類を識別することができるのであれば（例えば、デバイスＩＤのうちデバイス種別を示す一部のビット列（例えば、上位あるいは下位数ビット）からＭＴＣデバイス１００の種類を導出）、必ずしも本デバイス種ＩＤを用いる必要はない。また、デバイスＩＤも同様に、例えばＩＭＥＩ（International Mobile Equipment Identity）やＩＭＳＩ（International Mobile Subscriber Identity）を用いることで、ＭＴＣデバイス１００を一意に識別できるのであれば、新たに割り当てる必要はない。また、グループＩＤも同様に、例えばデータを転送するＰＤＮコネクション、ＥＰＳベアラを共有する場合（例えば、ＭＴＣグループの中で代表するＭＴＣデバイス１００が、通信システムとＰＤＮコネクション、ＥＰＳベアラを確立していて、代表するＭＴＣデバイス１００が同ＭＴＣグループに属する他のＭＴＣデバイス１００が取得したデータを転送する場合）には、ＰＤＮコネクションＩＤやＥＰＳベアラＩＤ、ＡＰＮ（Access Point Name）を用いることでＭＴＣグループを識別できるのであれば、新たに割り当てる必要はない。
また、各ＭＴＣデバイス１００には、例えばＭＴＣユーザ１６０などによって事前にＭＴＣの機能（ＭＴＣ Ｆｅａｔｕｒｅｓ）が組み込まれていてもよく（例えば、ＳＩＭカードに書き込む、ＭＴＣデバイス１００の記憶メモリに書き込む）、ネットワーク装置（例えば、ＭＭＥ１２０やＭＴＣサーバ１５０など）やＭＴＣデバイス１００自身が、所望のＭＴＣの機能を有効化／無効化するものであってもよい。上記のようなＭＴＣデバイス１００のデバイスＩＤ、グループＩＤ、デバイス種ＩＤ、搭載しているＭＴＣの機能、ＭＴＣの機能の有効化／無効化など、ＭＴＣに関連する様々な情報は、ＨＳＳ１２５が保持するサブスクリプションデータや通信コンテキストなどに登録されているものとする。また、Ｅ−ＵＴＲＡＮ１１５におけるＭＴＣデバイス１００のモビリティ制御は、ＵＥ１０５に対する制御と同様にＭＭＥ１２０が実施する。
また、ＭＴＣサーバ１５０は、通信システムを運用するオペレータが管理する場合と、オペレータ以外の運用者が管理する場合がある。いずれの場合も、オペレータが管理するＰＧＷ１４０とのインタフェースを有し、通信システムに接続するＭＴＣデバイスから／へのユーザデータ転送、通信システムにおけるＭＴＣデバイスの制御に関するサービスを享受する。なお、オペレータがＭＴＣサーバを管理する場合、ＭＴＣサーバとＰＧＷ１４０を同一装置内に実施するものであってもよく、これによって外部インタフェースの実装を装置内に隠蔽して装置コストの削減を図ることができる。
また、ＭＴＣユーザ１６０は、各ＭＴＣデバイス１００が取得したデータを管理・利用する主体であり、事業運営者や企業、またデータ管理を実施する制御主体（ＰＣ、サーバなど）に相当する。例えば、ＭＴＣデバイス１００が自動販売機に組み込まれていることを想定すると、ＭＴＣユーザ１６０は自動販売機の売り上げ集計やメンテナンスを実施する会社などである。また、ＭＴＣデバイス１００を煙センサに組み込まれていることを想定すると、ＭＴＣユーザ１６０は消防署や警備会社、保険会社、又は住宅の火災による被害の軽減を担当する会社などであると考えられる。なお、ＭＴＣユーザ１６０は、上記のようにＭＴＣの管理を行うユーザが使用するＭＴＣユーザ端末と考えてもよく、あるいは、ＭＴＣの管理を行うユーザが操作するＭＴＣサーバ１５０と同一の装置であると考えてもよい。
また、一般的に、ＭＴＣデバイス１００とＭＴＣサーバ１５０との間で交換されるデータは、アプリケーションレベルのデータであるため、ＭＴＣデバイス１００とＰＧＷ１４０との間のデータ転送は、Ｕプレーン（User plane：ユーザプレーン）の利用が想定される。しかし、アプリケーションやサービスの内容や性質（例えば、生存者確認など緊急性を伴うデータ転送向けサービス）、通信システムのネットワークオペレータの要求（例えば、ネットワーク装置（例えば、ＭＭＥ１２０）による制御が必要となる場合（例えば、ＭＴＣデバイス１００の位置情報の変更や、ＭＴＣグループ／同一デバイス種などの制御））、ＭＴＣデバイス１００／ＭＴＣサーバ１５０の要求（例えば、迅速に、又は、高い信頼度でデータを送信／取得したい場合）によっては、即時性や信頼性を有するＣプレーン（Control plane：制御プレーン）を利用する（シグナリングメッセージにアプリケーションデータを重畳、あるいはピギーバックする）ことによる効果が大きい場合がある。
また、イベント検知時に優先度の高いイベント通知メッセージを送信するＭＴＣデバイス１００は、取得したデータ（センシングデータとも呼ぶ）からイベントを検出すると、優先度の高いイベント通知メッセージをＭＴＣサーバに送信し、同時に、あるいは続けて、取得したデータ（センシングデータ）をＭＴＣサーバに送信するものとする。
また、上記の構成を有する通信システムにおいて、ＭＴＣデバイス１００は、通信システム（Ｅ−ＵＴＲＡＮ１１５）に接続されており、通信システムを通じてＭＴＣサーバ１５０と通信可能であるとする。
＜第１の実施の形態＞
以下、本発明の第１の実施の形態におけるシステム動作の一例について、図３を用いて詳しく説明する。図３は、本発明の第１の実施の形態におけるシステム動作の一例（複数のＭＴＣデバイス１００から送信される同一イベント、又は、そのイベントを引き起こした出来事によって引き起こされたイベントによる優先度の高いイベント通知メッセージの送信抑制方法）を説明するためのシーケンス図である。なお、図３には、図１に図示されているシステム構成における処理シーケンスの一例が図示されている。
以下、本発明の第１の実施の形態におけるシステム動作の一例について、図３を用いて詳しく説明する。図３は、本発明の第１の実施の形態におけるシステム動作の一例（複数のＭＴＣデバイス１００から送信される同一イベント、又は、そのイベントを引き起こした出来事によって引き起こされたイベントによる優先度の高いイベント通知メッセージの送信抑制方法）を説明するためのシーケンス図である。なお、図３には、図１に図示されているシステム構成における処理シーケンスの一例が図示されている。
ここで、本実施の形態の説明を容易化するために、ＭＴＣデバイス１００は以下のような特徴を持っていることを前提とする。
ＭＴＣデバイス１００は、非特許文献１で定義されている“Ｔｉｍｅ Ｃｏｎｔｒｏｌｌｅｄ”と、“ＰＡＭ”と、“Ｇｒｏｕｐ ｂａｓｅｄ”と、“Ｌｏｗ ｍｏｂｉｌｉｔｙ”とを有しているとする。ＭＴＣデバイス１００は、他の複数のＭＴＣデバイス１００と共に１つのＭＴＣグループとして管理されていることとする。また、ＭＴＣグループ内のＭＴＣデバイス１００は、“煙センサ”、“炎センサ”、“人感センサ”で構成されているものとする（実際には、各センサにＭＴＣデバイス１００である通信モジュールが実装される）。“煙センサ”は、一定値以上（あるいは所定時間連続して一定値以上）の煙濃度を検出した場合、すなわちイベント（煙）を検知した際に、火災が発生している可能性が高いと判断し、高い優先度（高優先度モードとも呼ぶ）でメッセージを送信する。“炎センサ”はイベント（炎）を検知した際、火災が発生している可能性が高いと判断し、“煙センサ”と同様に、高い優先度（高優先度モード）でメッセージを送信する。一方、“人感センサ”はイベント（人の有無）を検知した際、一般的な優先度（ノーマルモードとも呼ぶ）でセンシングデータを送信する。ここで、高優先度モードとは、イベントを検知した際に優先度の高いイベント通知メッセージを送信する状態である。またノーマルモードとは、イベントを検知した際に優先度の高いイベント通知メッセージは送信せずに、取得したデータを一般的な優先度で送信する状態、又は、一般的な優先度でイベント通知メッセージを送信し、取得したデータも同様に一般的な優先度で送信する状態である。なお、メッセージの優先度は、ＥＰＳベアラのＱＣＩや、ＥＰＳベアラの帯域幅（例えば、ＭＢＲ（Maximum Bit Rate）やＡＭＢＲ（Aggregate Maximum Bit Rate））、ＭＴＣデバイス１００が持つＩＭＳＩやＩＭＥＩの値、ＰＣＣ（Policy and Charging Control）、ＭＴＣ Ｆｅａｔｕｒｅ／ＭＴＣデバイス１００の種類／ＭＴＣサービス毎に定義される優先度や値などで定義されてもよい。
図３では、ＭＴＣグループ内のＭＴＣデバイス１００を識別するために、ＭＴＣデバイスＡ１００ＡとＭＴＣデバイスＢ１００Ｂとが図示されている。なお、ここでは、ＭＴＣデバイスＡ１００Ａを、最初にイベントを検知するＭＴＣデバイス（“煙センサ”）と仮定し、ＭＴＣデバイス１００Ｂを、ＭＴＣデバイスＡ１００Ａと同一のＭＴＣグループに属する他のＭＴＣデバイス（“煙センサ”、“炎センサ”、“人感センサ”）と仮定する。なお、図３では２つのＭＴＣデバイス１００（ＭＴＣデバイスＡ１００Ａ、ＭＴＣデバイスＢ１００Ｂ）しか存在していないが、３つ以上のＭＴＣデバイス１００が同じＭＴＣグループ内に存在する場合でも、同様に動作する。
以下、図３に図示されているシーケンスについて説明する。ＭＴＣデバイスＡ１００Ａ（煙センサ）は、ＭＴＣサーバ１５０と通信を行うためのＰＤＮコネクションを、従来手法（例えば、非特許文献３で示されるAttach procedure）に基づいてＰＧＷ１４０と確立する（図３のステップＳ２０１：ＰＤＮコネクション確立済み）。また、ＭＴＣデバイスＢ１００Ｂも、従来手法（例えば、非特許文献３で示されるAttach procedure）に基づいてＰＧＷ１４０とＰＤＮコネクションを確立する（図３のステップＳ２０６：ＰＤＮコネクション確立済み）。
ここで、ＭＴＣデバイスＡ１００Ａが、例えば、火災発生などにより、イベント（煙）を検知したとする（図３のステップＳ２０２：イベント検知）。イベントを検知したＭＴＣデバイスＡ１００Ａは、イベントを検知したことをＭＴＣサーバ１５０に通知するためのメッセージ（ここでは、イベント通知メッセージ＠デバイスＡと表記）を送信する。なお、ＭＴＣデバイスＡ１００Ａ（煙センサ）が煙を検知した場合は、火災が発生している可能性が高いと予測され、ＭＴＣデバイスＡ１００Ａは優先度の高いメッセージ（例えば、ＰＡＭ）を用いて、ＭＴＣサーバ１５０に通知する（図３のステップＳ２０３：イベント通知メッセージ＠デバイスＡ）。また、これ以降、優先度の高いメッセージとは、ＰＡＭや、他のＮＡＳメッセージより優先度が高いＮＡＳ／ＡＳメッセージなどを指す。また、この優先度の高いメッセージは、(Priority) Event Notification、Alarm Signaling、Event Alert、Emergency signaling、Event Detection Messageなどと呼ばれてもよい。
なお、このＭＴＣデバイスＡ１００Ａから送信される優先度の高いメッセージであるイベント通知メッセージ＠デバイスＡは、例えば、非特許文献１が定義するＰＡＭや、非特許文献３で記述されているＴＡＵ（Tracking Area Update） Ｒｅｑｕｅｓｔなどの位置登録メッセージにピギーバック（重畳）した場合、又は、ＰＤＮコネクションやＥＰＳベアラが確立されていない状態でイベントを検知した場合は、ＰＤＮコネクションやＥＰＳベアラを確立する際に用いられる、例えば、Attach RequestやService Request、非特許文献４にて定義されるDS-MIPv6 bootstrapping based on IKEv2で使用されるＩＫＥ＿ＳＡ＿ＩＮＩＴメッセージやＩＫＥ＿ＡＵＴＨ Ｒｅｑｕｅｓｔメッセージを用いてもよい。また、Bearer Modification Requestメッセージを用いるものであってもよい。これによって、新規メッセージを導入することなく、少ない修正でＭＴＣデバイス１００からのイベント通知を実施することができる。
通信システムのエンティティ（例えば、ＭＭＥ１２０）は、ＭＴＣグループに属しているＭＴＣデバイスＡ１００Ａから、イベントを検知したことを知らせる優先度の高いイベント通知メッセージを受信すると、ＳＧＷ１３０／ＰＧＷ１４０を通じて、ＭＴＣサーバ１５０にイベント通知メッセージ＠デバイスＡを転送する。また、通信システムのエンティティ（例えば、ＭＭＥ１２０）は、後続する優先度の高いイベント通知メッセージ（同一イベント（例えば、煙の発生）、若しくは、そのイベント（例えば、煙発生）を引き起こした出来事（例えば、火災発生）によって引き起こされたイベント（例えば、炎の発生）によるイベント通知メッセージ（例えば、ＰＡＭ））の送信を抑制するためのメッセージ（ここでは、逆イベント通知メッセージと表記する。また、逆ＰＡＭ、混雑回避メッセージ、Time Tolerant Indication、congestion indication、congestion prior indication、PAM reduction indicationなどと呼ばれてもよい）を、同グループの全てのＭＴＣデバイス１００にブロードキャストする（図３のステップＳ２０４：逆イベント通知メッセージ）。なお、通信システムのＥｎｔｉｔｙ（例えば、ＭＭＥ１２０）は、この逆通知メッセージに同種の優先度の高い通知メッセージの送信停止を示すパラメータを格納してもよい。
また、この逆イベント通知メッセージは、逆イベント通知メッセージの送信元（例えば、ＭＭＥ１２０）の判断（例えば、通信システムのオペレータによる事前設定）によって、他のメッセージより高い優先度、若しくは一般的な優先度で送信してもよい。他のメッセージより高い優先度で逆イベント通知メッセージが送信される場合は、メッセージの送信元が過負荷状態であり、一般的な優先度のメッセージの処理が放棄される場合でも、優先度の高い逆イベント通知メッセージは送信することができる。また、優先度の高い逆イベント通知メッセージではなく、一般的な優先度で逆イベント通知メッセージを送るものであってもよい。この場合は、特にメッセージの優先度を設定する必要がなくなる。
また、ＭＭＥ１２０は、一定期間内に所定数のイベント通知メッセージを受信した、あるいは単に一定数のイベント通知メッセージを受信した場合に、逆イベント通知メッセージを送信するものであってもよい。これにより、同一のイベント通知メッセージが今後も増加するであろうことを予見した上で、それらの発生を抑えるための逆イベント通知メッセージを送信することにより、単発のイベント通知メッセージから判断する場合に比べて、抑止メッセージ（逆イベント通知メッセージ）を効果的に発行することができ、通信リソースや帯域の有効利用を図ることができる（単発のイベント通知メッセージにより判断する場合、イベント通知メッセージを受信するたびに逆イベント通知メッセージを送信することになり、通信リソースや帯域を浪費することになる）。
このとき、ＭＭＥ１２０は、ＭＴＣデバイスＡ１００ＡがＭＴＣグループに属しているか、また、ＭＴＣグループに属しているのであれば、どのＭＴＣグループに属しているかを、ＭＴＣデバイスＡ１００Ａに対応するサブスクリプションデータをＨＳＳ１２５から取得してグループＩＤが登録されているかどうかで判断してもよい。若しくは、ＭＴＣデバイスＡ１００Ａがメッセージに格納したグループＩＤから、ＭＴＣデバイスＡ１００Ａがグループに属しているかどうか（あるいは、どのグループに属しているか）を判断してもよい。また、ＭＭＥ１２０が既にサブスクリプションデータを保持、又は、ＨＳＳ１２５からサブスクリプションデータを取得する以外の方法（例えば、外部サーバへの問合せなど）により、ＭＴＣデバイスＡ１００ＡがＭＴＣグループに属しているかどうかを確認してもよい。
また、ここでは逆イベント通知メッセージを送信する対象を、イベントを検知したＭＴＣデバイスＡ１００Ａが属しているＭＴＣグループ配下の全てのＭＴＣデバイス（ＭＴＣデバイスＡ１００Ａ及びＭＴＣデバイスＢ１００Ｂ）としているが、“Ｇｒｏｕｐ ｂａｓｅｄ”Ｆｅａｔｕｒｅが適用されないケースにおいては、例えば、ＭＴＣデバイスＡ１００Ａが接続しているｅＮＢ１１０やＭＭＥ１２０（あるいは特定のTracking Area）配下の全てのＭＴＣデバイス１００を逆イベント通知メッセージの送信対象としてもよい。この場合は、特定のエリアに位置するＭＴＣデバイス１００からの同じイベントによる優先度の高いイベント通知メッセージも回避することができる。また、ＭＴＣグループという概念を考慮せずに、優先度の高いイベント通知メッセージを回避できることにより、グループＩＤなどを用いなくてもよいという利点がある。ここでは、グループＩＤの代わりに、ｅＮＢ１１０のＩＤ、若しくは、ｅＮＢ１１０のアドレス（並びにデバイスのベアラに対応するS1-U TEID）を使用してもよい。また、ＭＭＥ１２０があらかじめ送信相手を確認できているのであれば、ブロードキャストではなく、マルチキャストやユニキャストで逆イベント通知メッセージを送信してもよい。これにより、制御範囲（通知範囲）を限定することにより、システム全体へのインパクトを低減させることができる。なお、この逆イベント通知メッセージは、上記ＭＭＥ１２０以外の他の通信システムにおけるエンティティ（例えば、ｅＮＢ１１０、ＰＧＷ１４０など）や、ＭＴＣサーバ１５０が送信してもよい。
逆イベント通知メッセージは、上述のように、後続する同種の優先度の高いイベント通知メッセージ（同一イベント、若しくは、そのイベントを引き起こした出来事によって引き起こされたイベントによるイベント通知メッセージ（例えば、ＰＡＭ））を抑制するためのメッセージである。具体的には、逆イベント通知メッセージは、ＭＴＣデバイス１００に対してノーマルモードの動作を要請するメッセージであり、逆イベント通知メッセージを受信したＭＴＣデバイス１００は、高優先度モードで動作している場合はノーマルモードへモード遷移し、ノーマルモードで動作している場合は、そのままノーマルモードを維持する。
また、優先度の高いイベント通知メッセージ（例えば、ＰＡＭなど）を回避する以外での逆イベント通知メッセージの使い方がある。例えば、通信システムのエンティティとＭＴＣデバイス１００が、複数の優先度レベルを認識することができ、ＭＴＣデバイス１００が優先度の異なる複数のセンシングデータを送信したい場合、逆イベント通知メッセージを受信したＭＴＣデバイス１００は、例えば、逆イベント通知メッセージに格納されているネットワーク側が示す許容優先度レベルや、ＭＴＣデバイス１００にあらかじめ組み込まれているコンテキスト（例えば、混雑度レベル３のときは優先度レベル３以上のメッセージのみ送信許容）やアプリケーションデータを用いて、送信可能なセンシングデータを選択／決定してもよい。このとき、例えば逆イベント通知メッセージを受信することで、ＭＴＣデバイス１００は送信するセンシングデータの優先度の判別を行わないモード（例えば、ノーマルモード）から、優先度を考慮して送信するセンシングデータを選択／決定できるモード（例えば、高優先度モード）に切り替えてもよい。
また、少なくともＭＴＣデバイス１００が複数の優先度レベルを認識することができる場合、ネットワーク側の装置（例えば、ＭＴＣサーバ１５０やＭＭＥ１２０）によって送信された優先度レベルの変更を示しているメッセージなどによって、ＭＴＣデバイス１００は例えば、送信するメッセージの優先度レベルを変更するなどの処理をしてもよい。これにより、ネットワークが混雑していてパケットロスが発生しているような状況において、ＭＴＣデバイス１００自身が送信するメッセージの優先度レベルを考慮し、送信するメッセージを選択することで、更なる混雑状態を作ることを回避できる。
逆イベント通知メッセージを受信したＭＴＣデバイスＡ１００Ａは、逆イベント通知メッセージに従って、図７のように高優先度モードからノーマルモードにモード遷移を行う（ステップＳ２０５：モード切替）。そして、その後は、ＭＴＣデバイスＡ１００Ａは、ノーマルモードでセンシングデータの送信を行う（図３のステップＳ２１０：取得データ送信）。なお、図３のステップＳ２１０の取得データ送信は、ステップＳ２０５のモード切替後の任意のタイミングに行われる。また、ここでは、最初にイベント通知メッセージを送信したＭＴＣデバイスＡ１００Ａが、逆イベント通知メッセージの受信によって、高優先度モードからノーマルモードへモード遷移を行っているが、高優先度モードによるイベント通知メッセージの送信を行った直後に自らノーマルモードへモード遷移してもよく、あるいは、イベント通知メッセージを送信したＭＴＣデバイスＡ１００Ａに関しては、そのまま高優先度モードによる通知を継続して行えるようにしてもよい。
また、逆イベント通知メッセージを受信したＭＴＣデバイスＢ１００Ｂは、自らイベントを検知した際に高い優先度のイベント通知メッセージ（例えば、ＰＡＭなど）を用いてＭＴＣサーバ１５０にイベントを検知したことを通知するＭＴＣデバイス（例えば、他の煙センサや炎センサなど）であっても、逆イベント通知メッセージの受信に応じて図７のように高優先度モードからノーマルモードにモード遷移する（図３のステップＳ２０７：モード切替）。そして、その後、イベントを検知したとしても（図３のステップＳ２０８：イベント検知）、高い優先度のイベント通知メッセージ（例えば、ＰＡＭなど）の送信を行わず（図３のステップＳ２０７：モード切替）、ノーマルモードでセンシングデータの送信を行う（図３のステップＳ２０９：取得データ送信）。なお、ＭＴＣデバイスＢ１００Ｂが、通常時からノーマルモードでセンシングデータをＭＴＣサーバ１５０に送信している人感センサのようなＭＴＣデバイスの場合には、送信モードをノーマルモードのままに維持する。また、ステップＳ２０７の高優先度モードからノーマルモードにモード遷移後にイベントを検知した際、高優先度ではなく一般的な優先度でイベント通知メッセージを通知し、その後にセンシングデータを送信してもよい。
なお、上述のように、イベントを検知した際に高い優先度のイベント通知メッセージを用いてイベントを検知したことをＭＴＣサーバ１５０に通知していたＭＴＣデバイス１００（例えば、煙センサや炎センサ）は、逆イベント通知メッセージの受信によってノーマルモードへモード遷移するが、例えば、一定時間後（例えば、逆イベント通知メッセージでライフタイム値を通知など）、又は、ＭＭＥ１２０やＭＴＣサーバ１５０から送信されるメッセージ（例えば、ＮＡＳメッセージなど）を受信することで、ノーマルモードから高優先度モードに戻すようにしてもよい。これにより、１つのイベントが終了した後は、従来と変わらない動作に戻すことができる（図３には不図示）。
＜第２の実施の形態＞
第１の実施の形態の解決手法によれば、本発明が目的としている冗長なイベント通知メッセージの送信を抑制することは実現できているが、優先度の高い必要なイベント通知メッセージの送信さえも抑制してしまう場合がある。例えば、煙センサが煙の発生を検出した場合、逆イベント通知メッセージによってすべてのＭＴＣデバイス１００（例えば、炎センサなど）がノーマルモードへ遷移してしまう。その結果、煙の発生後、さらに炎センサが炎を検知した場合であっても、炎センサは、高い優先度のイベント通知メッセージ（例えば、ＰＡＭなど）を送信することはできない。
第１の実施の形態の解決手法によれば、本発明が目的としている冗長なイベント通知メッセージの送信を抑制することは実現できているが、優先度の高い必要なイベント通知メッセージの送信さえも抑制してしまう場合がある。例えば、煙センサが煙の発生を検出した場合、逆イベント通知メッセージによってすべてのＭＴＣデバイス１００（例えば、炎センサなど）がノーマルモードへ遷移してしまう。その結果、煙の発生後、さらに炎センサが炎を検知した場合であっても、炎センサは、高い優先度のイベント通知メッセージ（例えば、ＰＡＭなど）を送信することはできない。
また、例えば、上記した複数のマンション群のセキュリティを監視している環境において、通常（災害が発生していないとき）人感センサは緊急性が要求されていないため、検知したイベント／取得したデータをノーマルモードでＭＴＣサーバ１５０に定期的あるいは所定のタイミングで送信する。しかしながら、煙センサが煙を検知した環境においては、火災が発生している可能性が高いため、人の有無に関する情報は重要度が高くなる。そのため、人感センサが検知した人の有無に関する情報は、一般的な優先度（ノーマルモード）ではなく、高い優先度でイベント通知メッセージ（例えば、ＰＡＭなど）を用いて通知しないといけない。このように、通常はノーマルモードで人の有無に関する情報を送信していたＭＴＣデバイス１００（人感センサ）が、同じＭＴＣグループに属しているＭＴＣデバイス１００、若しくは周辺のＭＴＣデバイス１００が検知したイベントにより、高い優先度のイベント通知メッセージ（例えば、ＰＡＭなど）でイベントの検知（人の有無に関する情報）を通知できるようにしたいという要望がある。
また、煙センサが煙を検知し、火災が発生している可能性が高い環境では、人は一斉に走って逃げることが想定される。このとき、人感センサが、例えば一定の人の歩行速度と密度を超えたとき、優先度の高いイベント通知メッセージを通知するように設定されている場合も考えられる。また、通信システムのオペレータ、ＭＴＣサーバ１５０やＭＴＣユーザ１６０などの要求によって、ＭＴＣデバイス１００間で通信が可能である環境において、周辺のＭＴＣデバイス１００から一定の値以上のメッセージを受信した場合（例えば、アドホックネットワークのような環境において、一定時間内に一定値以上のパケットを転送した場合など）、優先度の高いイベント通知メッセージを通知するように設定されている場合も考えられる。
なお、ＭＴＣデバイス１００が、イベントを検知した際に、イベント通知メッセージのみを通知する、又は、取得したデータのみ送信する、若しくは、イベント通知メッセージと取得したデータを送信するメッセージの両方のメッセージを送信するかは、例えばＭＴＣデバイス１００自身、通信システムのオペレータ、ＭＴＣサーバ１５０やＭＴＣユーザ１６０などによって決まるものとする。
第１の実施の形態における解決法（通信システムのエンティティ、若しくは、ＭＴＣサーバ１５０が、イベントを検知したＭＴＣデバイス１００から送信される優先度の高いイベント通知メッセージ受信後、対象となるＭＴＣグループに属する複数のＭＴＣデバイス１００が送信する可能性のある優先度の高いイベント通知メッセージを抑制することを目的としたメッセージを送信する方法）では、全てのデバイスに一律に送信停止を指示していたため、上述のようなケースにおいて、必要なイベント通知メッセージ（例えば、煙センサがＰＡＭを送信した後の、炎センサ又は人感センサからのＰＡＭなど）を受信することができなくなってしまう。したがって、第１の実施の形態の改良系を第２の実施の形態で示す。
以下、本発明の第２の実施の形態におけるシステム動作の一例について、図４を用いて詳しく説明する。図４は、本発明の第２の実施の形態におけるシステム動作の一例（複数のＭＴＣデバイス１００から送信される同一イベント、又は、そのイベントを引き起こした出来事によって引き起こされたイベントによる優先度の高いイベント通知メッセージの送信抑制方法）を説明するためのシーケンス図である。なお、図４には、図１に図示したシステム構成における処理シーケンスの一例を図示する。
ここで、本実施の形態の説明を容易化するために、ＭＴＣデバイス１００は以下のような特徴を持っていることを前提とする。
ＭＴＣデバイス１００は、非特許文献１で定義されている“Ｔｉｍｅ Ｃｏｎｔｒｏｌｌｅｄ”と、“ＰＡＭ”と、“Ｇｒｏｕｐ ｂａｓｅｄ”と、“Ｌｏｗ ｍｏｂｉｌｉｔｙ”とを有しているとする。ＭＴＣデバイス１００は、他の複数のＭＴＣデバイス１００と共に１つのＭＴＣグループとして管理されていることとする。また、ＭＴＣグループ内のＭＴＣデバイス１００は、“煙センサ”、“炎センサ”、“人感センサ”で構成されているものとする。“煙センサ”はイベント（煙）を検知すると、火災が発生している可能性が高いと判断し、高い優先度（高優先度モード）でメッセージを送信する。“炎センサ”はイベント（炎）を検知すると、火災が発生している可能性が高いと判断し、“煙センサ”と同様に、高い優先度（高優先度モード）でメッセージを送信する。一方、“人感センサ”がイベント（人の有無）を検知すると、ノーマルモードでセンシングデータを送信する。
図４では、ＭＴＣグループ内のＭＴＣデバイス１００を識別するために、ＭＴＣデバイスＡ１００ＡとＭＴＣデバイスＢ１００Ｂとが図示されている。なお、ここでは、ＭＴＣデバイスＡ１００Ａを、最初にイベントを検知するＭＴＣデバイス（“煙センサ”）と仮定し、ＭＴＣデバイスＢ１００Ｂを、ＭＴＣデバイスＡ１００Ａと同一のＭＴＣグループに属する他のＭＴＣデバイス（“煙センサ”、“炎センサ”、“人感センサ”）と仮定する。
以下、図４に図示されているシーケンスについて説明する。ＭＴＣデバイスＡ１００Ａ（煙センサ）は、ＭＴＣサーバ１５０と通信を行うためのＰＤＮコネクションを、従来手法（例えば、非特許文献３で示されるAttach procedure）に基づいてＰＧＷ１４０と確立する（図４のステップＳ３０１：ＰＤＮコネクション確立済み）。また、ＭＴＣデバイスＢ１００Ｂも同様に、従来手法（例えば、非特許文献３で示されるAttach procedure）に基づいて、ＰＧＷ１４０とＰＤＮコネクションを確立する（図４のステップＳ３０８：ＰＤＮコネクション確立済み）。
ここで、ＭＴＣデバイスＡ１００Ａが、例えば、火災発生などにより、イベント（煙）を検知したとする（図４のステップＳ３０２：イベント検知）。イベントを検知したＭＴＣデバイスＡ１００Ａは、イベントを検知したことをＭＴＣサーバ１５０に通知するために、検知したイベント情報など（例えば、煙発生フラグ、デバイス種ＩＤなど）を格納したイベント通知メッセージを作成し、ＭＴＣサーバ１５０にイベント通知メッセージ（ここでは、イベント通知メッセージ（イベント情報）＠デバイスＡと表記）を送信する（図４のステップＳ３０３：イベント通知メッセージ（イベント情報）＠デバイスＡ）。なお、ＭＴＣデバイスＡ１００Ａ（煙センサ）が煙を検知した場合は、火災が発生している可能性が高いと予測され、ＭＴＣデバイスＡ１００Ａは優先度の高いメッセージを用いて、ＭＴＣサーバ１５０に通知する。また、このとき、ＭＴＣデバイスＡ１００Ａは、イベント通知メッセージにセンシングデータ（煙濃度）を格納してもよい。
図５Ａは、図４のステップＳ３０３において、ＭＴＣデバイスＡ１００Ａが通信システムを通じて、ＭＴＣサーバ１５０に送信するメッセージの一例として、イベント通知メッセージ（イベント情報）＠デバイスＡのフォーマット例を示す図である。
ＭＴＣデバイスＡ１００Ａは、例えば、従来のＮＡＳメッセージフィールドに、少なくともイベントフラグフィールドを追加する。イベントフラグフィールドは、ＭＴＣデバイスＡ１００Ａがイベントを検知したこと（例えば、ＭＴＣデバイスＡ１００Ａが煙センサの場合は、煙発生フラグ）を示すためのフィールドである。なお、検出したイベントの種別を併記してもよい。さらには、センシングデータフィールド、デバイス種ＩＤフィールドを追加してもよい。また、センシングデータフィールドは、例えばイベントを検知した際に、ＭＴＣサーバ１５０に早期に（すなわちイベント通知とともに）送信しておきたいデータ（例えば、ＭＴＣデバイスＡ１００Ａが煙センサの場合、煙濃度など）を格納するためのフィールドである。また、デバイス種ＩＤフィールドは、イベントを検知したＭＴＣデバイスＡ１００Ａの種類を識別するための情報を格納するためのフィールドである。例えば、ＭＴＣデバイスＡ１００Ａが煙センサの場合は、“煙センサ”であることが識別可能な情報が格納される（例えば、IMEIのデバイス種別を示すビット列から判断する、など）。なお、これら従来のＮＡＳメッセージに加えたイベントフラグフィールド、センシングデータフィールド、デバイス種ＩＤフィールドは、ＮＡＳメッセージフィールドに埋め込まれるものであってもよい。また、従来のＮＡＳメッセージ以外のメッセージ（例えば、ＭＴＣ用の）を用いてもよい。
なお、本実施の形態は、Ｃプレーンでイベント通知メッセージ（イベント情報）＠デバイスＡが送信されると仮定しているが、Ｕプレーンで送信される場合には、従来のＵプレーンで送信されるメッセージの任意のフィールドでもよい。また、ＭＴＣデバイスＡ１００Ａ、若しくはＭＴＣサーバ１５０／ＭＴＣユーザ１６０が、イベントフラグフィールドの情報を用いなくても、ＭＴＣデバイス１００がイベントを検知したことを確認できる、例えば、“Ｔｉｍｅ ｃｏｎｔｒｏｌｌｅｄ”が適用されたＭＴＣデバイス１００が、割り当てられた時間外にアクセスしてきた場合に、ＭＴＣデバイス１００が高優先度モードで通知すべきイベントを検出したものとＭＭＥ１２０が判断できる場合は、イベントフラグフィールドを省略してもよい。また、ＭＴＣデバイスＡ１００ＡがＭＴＣサーバ１５０に早期に（すなわちイベント通知とともに）送信しておきたいセンシングデータがない場合は、センシングデータフィールドを省略してもよい。また、デバイス種ＩＤフィールドも同様に、従来のＮＡＳメッセージフィールドに格納されているデバイスＩＤから、そのデバイスの種類を導出することができるのであれば、省略してもよい。また、デバイス種ＩＤフィールドに情報が格納されていることで、ＭＴＣデバイスＡ１００Ａがイベントを検知したということを確認できる（例えば、煙センサを示すデバイス種ＩＤが格納される場合、同時に煙検知イベントが通知されたものとする）のであれば、イベントフラグフィールドも同様に省略してもよい。
なお、このＭＴＣデバイスＡ１００Ａから送信される優先度の高いメッセージであるイベント通知メッセージ（イベント情報）＠デバイスＡは、例えば、非特許文献１が定義するＰＡＭや、非特許文献３で記述されているＴＡＵ（Tracking Area Update）リクエストなどの位置登録メッセージにピギーバック（重畳）した場合、又は、ＰＤＮコネクションやＥＰＳベアラが確立されていない状態でイベントを検知した場合は、ＰＤＮコネクションやＥＰＳベアラを確立する際に用いられる、例えば、Attach RequestやService Request、非特許文献４にて定義されるDS-MIPv6 bootstrapping based on IKEv2で使用されるＩＫＥ＿ＳＡ＿ＩＮＩＴメッセージやＩＫＥ＿ＡＵＴＨ Ｒｅｑｕｅｓｔメッセージを改良して用いてもよい。また、Bearer Modification Requestメッセージを用いるものであってもよい。これによって、新規メッセージを導入することなく、少ない修正でＭＴＣデバイス１００からのイベント通知を実施することができる。
通信システムのエンティティ（例えば、ＭＭＥ１２０）は、イベント通知メッセージ（イベント情報）＠デバイスＡを受信すると、受信したメッセージから、必要な情報（例えば、イベントフラグ、センシングデータ、デバイス種ＩＤ）を抽出し、例えば、従来のUpdate Bearer Requestメッセージなどに格納し、ＳＧＷ１３０／ＰＧＷ１４０を通じて、ＭＴＣサーバ１５０にイベント通知メッセージ（イベント情報）＠デバイスＡを転送する。このとき、ＭＭＥ１２０は、イベント通知メッセージ（イベント情報）＠デバイスＡからイベント情報（イベントフラグ／デバイス種ＩＤ）を抽出して、逆イベント通知メッセージ（イベント情報）（逆ＰＡＭ、混雑回避メッセージ、Time Tolerant Indication、congestion indication、congestion prior indication、PAM reduction indicationなどと呼ばれてもよい）に格納し、ＭＴＣデバイスＡ１００Ａが属しているＭＴＣグループ内の全てのＭＴＣデバイス１００に送信する（図４のステップＳ３０４：逆イベント通知メッセージ（イベント情報））。
また、この逆イベント通知メッセージは、逆イベント通知メッセージの送信元（例えば、ＭＭＥ１２０）の判断（例えば、通信システムのオペレータによる事前設定）によって、他のメッセージより高い優先度、若しくは一般的な優先度で送信してもよい。他のメッセージより高い優先度で逆イベント通知メッセージが送信される場合は、メッセージの送信元が過負荷状態であり、一般的な優先度のメッセージの処理が放棄される場合でも、優先度の高い逆イベント通知メッセージは送信することができる。また、優先度の高い逆イベント通知メッセージではなく、一般的な優先度で逆イベント通知メッセージを送るものであってもよい。この場合は、特にメッセージの優先度を設定する必要がなくなる。
また、ＭＭＥ１２０は、一定期間内に所定数のイベント通知メッセージを受信した、あるいは単に一定数のイベント通知メッセージを受信した場合に、逆イベント通知メッセージを送信するものであってもよい。これにより、同一のイベント通知メッセージが今後も増加するであろうことを予見した上で、それらの発生を抑えるための逆イベント通知メッセージを送信することにより、単発のイベント通知メッセージから判断する場合に比べて、抑止メッセージ（逆イベント通知メッセージ）を効果的に発行することができ、通信リソースや帯域の有効利用を図ることができる（単発のイベント通知メッセージにより判断する場合、イベント通知メッセージを受信するたびに逆イベント通知メッセージを送信することになり、通信リソースや帯域を浪費することになる）。
このとき、ＭＭＥ１２０は、ＭＴＣデバイスＡ１００ＡがＭＴＣグループに属しているか、また、ＭＴＣグループに属しているのであれば、どのＭＴＣグループに属しているかを確認するために、ＭＴＣデバイスＡ１００Ａに対応するサブスクリプションデータをＨＳＳ１２５から取得してグループＩＤが登録されているかどうかで判断してもよい。若しくは、ステップＳ３０３のイベント通知メッセージ（イベント情報）＠デバイスＡに格納されているグループＩＤなどから判断してもよい（図５Ａ不図示）。また、ＭＭＥ１２０が既にサブスクリプションデータを保持、又は、ＨＳＳ１２５からサブスクリプションデータを取得する以外の方法（例えば、外部サーバなど）を用いて、ＭＴＣデバイスＡ１００ＡがＭＴＣグループに属しているかどうかを確認できるのであれば、ＨＳＳ１２５に問い合わせる必要はない。
また、ここでは逆イベント通知メッセージを送信する対象を、イベントを検知したＭＴＣデバイスＡ１００Ａが属しているＭＴＣグループ配下の全てのＭＴＣデバイス（ＭＴＣデバイスＡ１００Ａ及びＭＴＣデバイスＢ１００Ｂ）としているが、“Ｇｒｏｕｐ ｂａｓｅｄ”を搭載していないケースにおいては、ＭＴＣデバイスＡ１００Ａが接続しているｅＮＢ１１０配下の全てのＭＴＣデバイス１００を逆イベント通知メッセージの送信対象としてもよい。この場合、特定のエリアに位置するＭＴＣデバイス１００からの同じイベントによる優先度の高いイベント通知メッセージを抑制することができる。また、ＭＴＣグループという概念を考慮せずに、優先度の高いイベント通知メッセージを抑制できることにより、グループＩＤなどを用いなくてもよいという利点がある。ここでは、グループＩＤの代わりに、ｅＮＢ ＩＤやｅＮＢアドレス（並びにＭＴＣデバイス１００のＥＰＳベアラに対応するS1-U TEID）を使用してもよい。また、ＭＭＥ１２０があらかじめ送信相手を確認できているのであれば、ブロードキャストではなく、マルチキャストやユニキャストで逆イベント通知メッセージを送信してもよい。これにより、制御範囲（通知範囲）を限定することにより、システム全体へのインパクトを低減させることができる。
また、ＭＭＥ１２０は、逆イベント通知メッセージ（イベント情報）をＭＴＣグループの全てのＭＴＣデバイス１００に送信する際、例えば、逆イベント通知メッセージ（イベント情報）の送信先であるＭＴＣグループのグループＩＤ、デバイス種ＩＤと一緒に逆イベント通知メッセージ（イベント情報）を送信したことを、逆イベント通知メッセージ（イベント情報）送信済み情報として記憶する。この記憶した逆イベント通知メッセージ（イベント情報）送信済み情報は、同じＭＴＣグループ内の同じデバイス種のＭＴＣデバイス１００から同一イベント、又は、そのイベントを引き起こした出来事によって引き起こされたイベントによるイベント通知メッセージ（イベント情報）を受信した際に、再度同じ逆イベント通知メッセージ（イベント情報）を送信しないように、ＭＴＣデバイス１００が判断するパラメータとして使用される。なお、イベント通知メッセージ（イベント情報）を受信した際、同じＭＴＣグループの同じＭＴＣデバイス種からのイベント通知メッセージ（イベント情報）であると判断できる場合は、再度、逆イベント通知メッセージ（イベント情報）を送信することが望ましいが、この場合は、必ずしも逆イベント通知メッセージ（イベント情報）送信済み情報を記憶する必要はない。また、ＭＭＥ１２０は、上記したようにＭＴＣデバイス１００の種類を確認できるものとする（例えば、ＭＴＣデバイスのデバイスＩＤからＭＴＣデバイス１００の種類を確認することができる（例えば、デバイスＩＤのうちデバイス種別を示す一部のビット列（例えば、上位あるいは下位数ビット）、又は、外部サーバにデバイスＩＤを通知するとデバイス種ＩＤを取得できるなど）、又は、図５Ａに図示されているようにイベント通知メッセージ（イベント情報）＠デバイスＡにデバイス種ＩＤも格納されていることとする）。
また、ＭＴＣデバイス１００が複数のイベントグループ情報を保持している場合、ＭＭＥ１２０は、イベントグループ情報ラベル（複数のイベントグループ情報のうちのどのイベントグループ情報を使用するかを示すためにイベントグループ情報と関連付けられている情報）を逆イベント通知メッセージ（イベント情報）に格納して送信を行う。ＭＭＥ１２０が、どのイベントグループ情報を使用するかを判断する方法は、例えば、サブスクリプションデータに登録されている情報（例えば、イベント情報とイベントグループ情報が対になっている情報など）を用いてもよいし、ＭＴＣサーバ１５０／ＭＴＣユーザ１６０が、あらかじめ設定しているＭＴＣサービスの仕様や登録情報、また設定情報などに基づいて決定してもよい。また、ＭＭＥ１２０による上記の判断（どのイベントグループ情報を使用するか）は、ＭＴＣデバイス１００が送信するイベント通知メッセージ（イベント情報）で、複数のイベントグループ情報を保持していることを通知したうえで、実施されてもよい。
ここで、図５Ｂを参照しながら、逆イベント通知メッセージ（イベント情報）について説明する。図５Ｂは、図４のステップＳ３０４において、ＭＭＥ１２０が、ＭＴＣデバイスＡ１００Ａが属するＭＴＣグループの全てのＭＴＣデバイス１００（ＭＴＣデバイスＢ１００Ｂを含む）にブロードキャストするメッセージの一例として、逆イベント通知メッセージ（イベント情報）のフォーマット例を示す図である。
ＭＭＥ１２０は、従来のＮＡＳ返信メッセージフィールドに、イベントフラグフィールド、デバイス種ＩＤフィールド、イベントグループ情報ラベルフィールドを追加したメッセージを送信する。イベントフラグフィールドは、ＭＴＣデバイス１００がイベントを検知したことを示すためのフィールドである。なお、イベントフラグフィールドは、このメッセージが逆イベント通知メッセージであることを識別するためのフィールドとしても用いられる。また、デバイス種ＩＤフィールドは、イベントを検知したＭＴＣデバイス１００の種類の情報（例えば、煙センサ）を格納するためのフィールドである。デバイス種ＩＤフィールドには、例えば、この逆イベント通知メッセージを送信するきっかけとなったイベント通知メッセージの送信元のＭＴＣデバイス１００の種類を識別するための情報が格納される。なお、このデバイス種ＩＤフィールドに格納される情報は、後述するイベントグループ情報（図６参照）内に登録されている情報と対応付けられている必要があり、また、イベントグループ情報内に登録されている情報との対応が明確に判別できるのであれば、デバイス種ＩＤ以外の情報（例えば、イベントのＩＤなど）を用いてもよい。また、イベントグループ情報ラベルフィールドは、例えば、ＭＴＣデバイス１００が複数のイベントグループ情報を保持している際に使用されるフィールドである。このイベントグループ情報ラベルフィールドには、ＭＴＣデバイス１００がどのイベントグループ情報を使用するかを決定するために、ＭＭＥ１２０によってイベントグループ情報ラベル（例えば、火災、地震、強盗、建物崩壊、土砂崩れなど）が格納される。
なお、本実施の形態は、Ｃプレーンで逆イベント通知メッセージ（イベント情報）が送信されると仮定しているが、Ｕプレーンで送信される場合には、従来のＵプレーンで送信されるメッセージの任意のフィールドでもよい。また、ＭＴＣデバイス１００が、ＭＭＥ１２０からの逆イベント通知メッセージ（イベント情報）に格納されるイベントフラグフィールドの情報を用いなくても、同じＭＴＣグループ、若しくは、周辺のＭＴＣデバイス１００が、イベントを検知したことを確認できるのであれば（例えば、“Ｔｉｍｅ ｃｏｎｔｒｏｌｌｅｄ”で割り当てられた時間外のメッセージ受信から確認可能）、イベントフラグフィールドを省略してもよい。また、ＭＭＥ１２０が、ＭＴＣデバイス１００が１つのイベントグループ情報しか保持していないことを確認済みの場合や、イベントグループ情報を用いたモード遷移の詳細な管理を行わないような場合には、イベントグループ情報を識別する必要がないので、イベントグループ情報ラベルフィールドを省略してもよい。例えば、ネットワーク装置（例えば、ＭＭＥ１２０）から送信される逆イベント通知メッセージに、イベントグループ情報ラベルを格納せずにデバイス種ＩＤのみを格納することで、最初にイベント通知メッセージを送信したＭＴＣデバイス１００と同種のＭＴＣデバイス１００からのイベント通知メッセージのみを抑制することができる。
なお、これら従来のＮＡＳメッセージに加えたイベントフラグフィールド、デバイス種ＩＤフィールド、イベントグループ情報ラベルフィールドは、ＮＡＳ返信メッセージフィールドに埋め込まれるものであってもよい。
なお、このＭＭＥ１２０から送信される逆イベント通知メッセージ（イベント情報）は、例えば、非特許文献３や非特許文献５で記述されているＰａｇｉｎｇメッセージやBearer Modification Requestメッセージ、非特許文献１が定義するＰＡＭ、非特許文献３で記述されているＴＡＵ Ａｃｃｅｐｔメッセージ、又は、非特許文献４が定義するDS-MIPv6 bootstrapping based on IKEv2で使用されるＩＫＥ＿ＳＡ＿ＩＮＩＴメッセージやＩＫＥ＿ＡＵＴＨ Ｒｅｓｐｏｎｓｅメッセージを拡張して用いてもよい。
なお、イベント通知メッセージ（イベント情報）＠デバイスＡに格納されているイベント情報を参照し、その参照したイベント情報を逆イベント通知メッセージ（イベント情報）に格納してブロードキャストするエンティティは、ＭＭＥ１２０ではなく、ＰＧＷ１４０やＭＴＣサーバ１５０であってもよい。また、イベント通知メッセージ（イベント情報）＠デバイスＡに格納されているデバイス種ＩＤと、逆イベント通知メッセージ（イベント情報）に格納されているデバイス種ＩＤは、関連性が保証されているのであれば、必ずしも一致しなくてもよい。しかし、この場合も、逆イベント通知メッセージ（イベント情報）に格納されている情報と、イベントグループ情報に登録されている情報（例えば、デバイス種ＩＤ）とは、関連性が保証されている必要がある。なお、デバイス種ＩＤではなく、イベント情報や従来のＮＡＳメッセージに含まれているＭＴＣデバイス１００を識別する、例えば、ＩＰアドレスや、デバイスＩＤを基に、逆イベント通知メッセージ（イベント情報）に格納するデバイス種ＩＤを確認できるのであれば、イベント通知メッセージ（イベント情報）＠デバイスＡに格納されているデバイス種ＩＤを使用する必要はない。
逆イベント通知メッセージ（イベント情報）を受信したＭＴＣグループ内のＭＴＣデバイス１００（図４中のＭＴＣデバイスＢ１００Ｂに相当）は、逆イベント通知メッセージ（イベント情報）に格納されているデバイス種ＩＤを抽出し、ＭＴＣデバイスＢ１００Ｂ自身のデバイスＩＤ／デバイス種ＩＤと一致しているかどうかを確認する（図４のステップＳ３０９：自種ＩＤと一致しているかを確認）。この確認によって、逆イベント通知メッセージ（イベント情報）から抽出されたデバイス種ＩＤと、自身のデバイスＩＤ／デバイス種ＩＤとが一致している場合には、ＭＴＣデバイス１００は、ノーマルモードに遷移する（元々ノーマルモードだった場合はそのまま維持）。なお、逆イベント通知メッセージ（イベント情報）から抽出されたデバイス種ＩＤは、その逆イベント通知メッセージを送信するきっかけとなったイベント通知メッセージ（イベント）の送信元のＭＴＣデバイス１００（ここでは、ＭＴＣデバイスＡ１００Ａ）の種類を表している。すなわち、ＭＴＣデバイスＢ１００Ｂは、自デバイスと同種類のＭＴＣデバイス１００からイベント通知メッセージが送信されたかどうかを判断し、自デバイスと同種類のＭＴＣデバイス１００からイベント通知メッセージが既に送信されたことが確認できた場合には、高優先度モードによるイベント通知メッセージの送信を行わないよう、ノーマルモードで動作を行う。
また、ＭＴＣデバイスＢ１００Ｂは、受信した逆イベント通知メッセージ（イベント情報）に含まれているデバイス種ＩＤに基づいて、高優先度モードへのモード切替を行うべきかどうかを判断し、高優先度モードへのモード切替を行う必要が確認された場合には、高優先度モードへモード切替（あるいは、元々高優先度モードで動作しているのであればそのまま高優先度モードを維持）を行う（図４のステップＳ３１０:高優先度モードへの切替を行うかどうかを判断（モード切り換え））。ここで、高優先度モードへモード切替を行うべきかどうかの判断は、例えば、逆イベント通知メッセージ（イベント情報）から抽出したデバイス種ＩＤが、そのＭＴＣデバイスＢ１００Ｂが保持しているイベントグループ情報（図６）に記載されているかどうかで判断する。なお、ＭＴＣデバイスＢ１００Ｂが複数のイベントグループ情報を保持している場合は、逆イベント通知メッセージ（イベント情報）に格納されているイベントグループ情報ラベルを抽出し、抽出されたイベントグループラベル情報に対応するイベントグループ情報を使用して判断する。
図６は、ＭＴＣデバイス１００が、受信した逆イベント通知メッセージ（イベント情報）に含まれているデバイス種ＩＤ／イベントグループ情報ラベルに基づいて、モード切替を行うべきかどうかを判断するために用いられるイベントグループ情報の一例を示す図である。このイベントグループ情報には、複数のデバイス種ＩＤ（対応関係が分かるのであれば、デバイス種ＩＤと一致する必要はない）が登録されており、このデバイス種ＩＤは静的／動的に設定される。逆イベント通知メッセージ（イベント情報）を受信したＭＴＣデバイスＢ１００Ｂは、逆イベント通知メッセージ（イベント情報）から抽出されたデバイス種ＩＤが、イベントグループ情報に登録されているかどうかを確認する。
図６には、ＭＴＣデバイスＢ１００Ｂ（人感センサ）が保持しているイベントグループ情報の一例が図示されている。図６では、イベントグループ情報に煙センサＩＤと炎センサＩＤとが記載されており、このイベントグループ情報を保持しているＭＴＣデバイスＢ１００Ｂ（人感センサ）は、煙センサＩＤ又は炎センサＩＤが含まれている逆イベント通知メッセージ（イベント情報）を受信すると、高優先度モードへモード切替を行って（あるいは、そのまま高優先度モードを維持して）動作を行う。すなわち、イベントグループ情報には、特定の逆イベント通知メッセージ（イベント情報）を受信した場合、高優先度モードに遷移あるいは維持するよう規定する情報が登録されている。
イベントグループ情報にどの種類のデバイス種ＩＤを登録するかは、例えば、イベント発生時の好適な動作に基づいて考慮されることが好ましい。一例として、例えば、火災が発生したときには、煙センサからネットワーク側へ優先度の高いイベント通知メッセージ（イベント情報）が送信され、その逆イベント通知メッセージ（イベント情報）がＭＴＣグループ内にブロードキャストされた場合であっても、炎を検知するために炎センサは高優先度モードのまま動作させておき、また、人が残っていないかどうかを迅速に把握するために人感センサを高優先度モードにモード遷移させることが最適な動作であるとする。この場合には、例えば、炎センサが保持するイベントグループ情報に煙センサＩＤと人感センサＩＤ、煙センサが保持するイベントグループ情報に炎センサＩＤと人感センサＩＤ、人感センサが保持するイベントグループ情報に煙センサＩＤと炎センサＩＤをそれぞれ登録しておくことで、最適な動作を実現することが可能となる。なお、イベントグループ情報に登録するデバイス種ＩＤ及び各ＭＴＣデバイス１００の動作については、後で詳細に説明する。
なお、ステップＳ３０９及びステップＳ３１０の確認処理は、各ＭＴＣデバイス１００にイベントグループ情報をどのように持たせるか（各ＭＴＣデバイス１００個別にイベントグループ情報を持たせるのか、あるいは、複数のＭＴＣデバイス１００に同じイベントグループ情報を持たせるのか）や、イベントグループ情報内に含まれる情報をどのように構成しておくか（イベントグループ情報を持つＭＴＣデバイス１００の自種ＩＤをイベントグループ情報に含ませておくかどうか）などによって、様々な方法を採用することが可能である。しかしながら、本発明の基本的な考え方は、ステップＳ３０９及びステップＳ３１０の確認処理の方法を限定するものではない。本発明では、逆イベント通知メッセージを受信したＭＴＣデバイス１００が、自デバイスと同種類のデバイスから既にイベント通知メッセージの送信が行われたかどうかを確認でき、さらに、自デバイスと異なる種類のデバイスからイベント通知メッセージの送信が行われている場合には高優先度モードへ遷移（あるいは、現在のモードをそのまま維持）すべきかどうかを判断できるようにすることが重要である。
また、図６には、上述のように、ＭＴＣデバイスＢ１００Ｂ（人感センサ）が保持するイベントグループ情報が図示されているが、このイベントグループ情報に、人感センサ自体のＩＤ（人感センサＩＤ）が含まれていてもよい。ここで一例として挙げているステップＳ３０９及びステップＳ３１０の確認処理によれば、ＭＴＣデバイスＢ１００Ｂ（人感センサ）は、自身が保持しているイベントグループ情報に自デバイス種ＩＤ（人感センサＩＤ）が含まれているかどうかを確認することはないが、逆イベント通知メッセージ（イベント情報）を受信した場合でも例外的に高優先度モードで動作を行うＭＴＣデバイス１００のデバイス種ＩＤの一覧を、イベントグループ情報として登録することで、共通のイベントグループ情報を作成することも可能である。具体的には、火災発生時に、煙センサ、炎センサ、人感センサを高優先度モードで動作させたいと考えた場合には、イベントグループラベルの情報「火災」が付けられており、煙センサ、炎センサ、人感センサが登録されたイベントグループ情報を、煙センサ、炎センサ、人感センサに共通して持たせておくことも可能である。さらに、ステップＳ３０９及びステップＳ３１０の確認処理を上述したものとは異なる動作とすることで、すべてのＭＴＣデバイス１００が共通のイベントグループ情報を持たせた場合であっても、本発明に係る詳細なモード遷移の管理を実現できる方法も存在する。
また、ＭＴＣグループのＭＴＣデバイス１００は、逆イベント通知メッセージ（イベント情報）を受信した際、逆イベント通知メッセージ（イベント情報）に格納されているデバイス種ＩＤ（例えば、煙センサ）を記憶する（図４のステップＳ３１１：イベント情報の記憶）。この記憶したイベント情報は、ＭＴＣデバイス１００が再度ＭＭＥ１２０から別の逆イベント通知メッセージ（イベント情報（例えば、人感センサＩＤ））を受信した際に、優先度の高いイベント通知メッセージを送信しない（高優先度モードに切り替わらない）と判断するパラメータとして使用される。例えば、ＭＴＣデバイスＡ１００Ａ（煙センサ）が、イベントを検知して、優先度の高いイベント通知メッセージ（イベント情報）を送信した後、ＭＴＣデバイスＡ１００Ａと同じＭＴＣグループに属しているＭＴＣデバイス１００は、デバイス種ＩＤが“煙センサ”の逆イベント通知メッセージ（イベント情報）を受信する。このとき、ＭＴＣデバイスＡ１００Ａと同じデバイス種のＭＴＣデバイスＢ１００Ｂ（煙センサ）は、高優先度モードからノーマルモードにモード遷移するとともに、デバイス種ＩＤが“煙センサ”の逆イベント通知メッセージ（イベント情報）を受信したことを記憶する。その後、同じＭＴＣグループのＭＴＣデバイスＢ１００Ｂ（人感センサ）がイベントを検知して、優先度の高いメッセージ（イベント情報）を送信した場合には、ＭＴＣグループ内のＭＴＣデバイス１００は、デバイス種ＩＤが“人感センサ”の逆イベント通知メッセージ（イベント情報）を、デバイス種ＩＤが“煙センサ”の逆イベント通知メッセージ（イベント情報）に続いて受信する。このとき、ＭＴＣデバイスＡ１００Ａは、先に受信しているデバイス種ＩＤが“煙センサ”の逆イベント通知メッセージ（イベント情報）を記憶しており、この記憶された情報（受信履歴）をパラメータとして、ノーマルモードから高優先度モードにモード遷移せずに、再度優先度の高いイベント通知メッセージ（イベント情報）を送信しないよう動作する。これにより、同一イベント（例えば、火災発生）の際にいったん高優先度モードからノーマルモードに遷移したＭＴＣデバイス１００は、再度、高優先度モードに戻らないように制御することが可能となる。なお、このモード切替するための判断要素となるパラメータは、ＭＴＣデバイス１００の種類を示すデバイス種ＩＤ以外の情報でもよい。
なお、ステップＳ３０９の自デバイス種ＩＤの確認ステップからステップＳ３１１のイベント情報の記憶ステップは、順不同で実施してもよい。
その後、ＭＴＣデバイスＢ１００Ｂ（例えば、人感センサ）が、イベント（例えば、人の存在）を検知したとする（図４のステップＳ３１３：イベント検知）。イベント検知したＭＴＣデバイスＢ１００Ｂは、イベント検知時にデータ送信するモードを確認し、その送信モードに従って、ＭＴＣサーバ１５０に通知を行う。このとき、ＭＴＣデバイスＢ１００Ｂが高優先度モードであり、優先度の高いメッセージを通知する場合は、ＭＴＣデバイスＢ１００Ｂは、検知したイベント情報などを格納したイベント通知メッセージをＭＴＣサーバ１５０に通知する（図４のステップＳ３１４：イベント通知メッセージ（イベント情報）＠デバイスＢ）。一方、ＭＴＣデバイスＢ１００Ｂが高優先度モードではなくノーマルモードで送信する場合は、ステップＳ３１４のイベント通知メッセージ（イベント送信）（点線部分）はノーマルモードで通知するか、若しくは行わず、ＭＴＣサーバ１５０にセンシングデータを送信する（図４のステップＳ３１５：取得データ送信）。なお、ステップＳ３１４のイベント通知メッセージとステップＳ３１５の取得データ送信は、逐次的、若しくは、同時に行ってもよい。
また、最初にイベント通知メッセージ（イベント情報）を送信したＭＴＣデバイスＡ１００Ａも、逆イベント通知メッセージ（イベント情報）を受信し、逆イベント通知メッセージ（イベント情報）に従って、図７のように高優先度モードからノーマルモードにモード遷移を行い（図４のステップＳ３０６：モード切替）、逆イベント通知メッセージ（イベント情報）を受信したことを記憶する（図４のステップＳ３０７：イベント情報の記憶）。そして、その後は、ＭＴＣデバイスＡ１００Ａは、ノーマルモードでセンシングデータの送信を行う（図４のステップＳ３１６：取得データ送信）。なお、図４のステップＳ３１６の取得データ送信は、ステップＳ３０３のイベント通知メッセージ（イベント情報）＠デバイスＡ送信後の任意のタイミングに行うことが可能である。また、ここでは、最初にイベント通知メッセージ（イベント情報）を送信したＭＴＣデバイスＡ１００Ａが、逆イベント通知メッセージ（イベント情報）の受信によって、高優先度モードからノーマルモードへモード遷移を行っているが、高優先度モードによるイベント通知メッセージ（イベント情報）の送信を行った直後に自らノーマルモードへモード遷移してもよく、あるいは、イベント通知メッセージ（イベント情報）を送信したＭＴＣデバイスＡ１００Ａに関しては、そのまま高優先度モードによる通知を継続して行えるようにしてもよい。
また、通常、イベントを検知した際に高い優先度のイベント通知メッセージでＭＴＣサーバ１５０に通知していたＭＴＣデバイス１００（例えば、炎センサ）は、例えば、一定時間後（例えば、逆イベント通知メッセージでライフタイム値を通知など）、又は、ＭＭＥ１２０、ＭＴＣサーバ１５０から送信されるメッセージ（例えば、ＮＡＳメッセージなど）をＭＴＣデバイス１００が受信することで、ノーマルモードから高優先度モードに戻すことができる。また、通常、いったん高優先度モードに遷移した後にノーマルモードに戻って動作を行っているＭＴＣデバイス１００（例えば、人感センサ）に関しても、同様の方法で、元の状態（逆イベント通知メッセージを受信した場合に、ノーマルモードから高優先度モードへ遷移できる状態）に戻すことができる。これにより、１つのイベントが終了後も、通常と同様の動作に戻すことができる（図３には不図示）。
次に、図８を参照しながら、本発明の第２の実施の形態におけるＭＴＣデバイス１００の構成について説明する。図８は、本発明の第２の実施の形態におけるＭＴＣデバイス１００の構成の一例を示す図である。
図８において、ＭＴＣデバイス１００は、通信システム（例えば、Ｅ−ＵＴＲＡＮやＵＴＲＡＮ）と接続して下位レイヤにおける通信処理と上位レイヤでＩＰなどのパケット通信処理を実施する通信処理部５０１、受信したメッセージが逆イベント通知メッセージであるか判断し、受信した逆イベント通知メッセージに格納されているイベント情報を記憶し、逆イベント通知メッセージに格納されているデバイス種ＩＤが、ＭＴＣデバイス１００自身のデバイス種ＩＤと一致しているか確認し、さらに、保持しているイベントグループ情報に逆イベント通知メッセージに格納されているデバイス種ＩＤが登録されているか確認する逆イベント通知メッセージ処理部５０２、逆イベント通知メッセージを受信した際にＭＴＣデバイス１００の現在の送信モードを確認し、その送信モードを確認するために使用する情報を保持し、ＭＴＣデバイス１００の送信モードを切り替える送信モード制御部５０４、特定のイベント（そのＭＴＣデバイス１００が監視しているイベント）を検知するイベント検知部５０５、イベント検知時に高い優先度のメッセージで送るか判断するイベント通知メッセージ処理部５０３を少なくとも有する。なお、例えば、イベント通知メッセージ処理部５０３が、送信モード制御部５０４の機能を保持している場合は、送信モード制御部５０４を省略できる。他の機能部も同様に、１つの機能部で上記の機能部を含む場合は、省略してもよい。逆に、例えば、イベント通知メッセージ処理部５０３で実施している、受信した逆イベント通知メッセージに格納されているイベント情報を記憶する機能と、イベント検知時に高い優先度のメッセージで送るかどうかを判断する機能とを分けてもよい。
なお、ＭＴＣデバイス１００において上述の各構成要素が動作を行うことで、特定のイベントの発生を検知するためのセンサによって検知されたセンシングデータを通常の優先度で送信するノーマルモード、又は、センサによって特定のイベントの発生を検知したことを通知するイベント通知メッセージをノーマルモード、若しくは、ノーマルモードの優先度よりも高い優先度で送信する高優先度モードのいずれかの送信モードで動作を行うよう制御する動作モード制御部としての機能、ネットワークノードへ高優先度モードによるイベント通知メッセージの送信又はノーマルモードによるセンシングデータの送信を行う送信部としての機能、特定のイベントの発生を検知したことを通知するイベント通知メッセージを任意の通信ノードから受信したネットワークノードから、任意の通信ノードが通知するイベント通知メッセージに対する応答として送信されるメッセージであって、送信モードをノーマルモードへ遷移するか又はノーマルモードのまま維持するよう指示するメッセージを受信するメッセージ受信部としての機能、メッセージを受信した場合に、送信モードをノーマルモードへ遷移するか又はノーマルモードのまま維持するかどうかを判断するモード遷移判断部としての機能などが実現される。
次に、図８に図示されている構成を有するＭＴＣデバイス１００について、本発明における特徴的な処理を中心に、図９Ａと図９Ｂを用いて詳しく説明する。図９Ａは、本発明の第２の実施の形態において、イベント検知時に、ノーマルモード又は高優先度モードでＭＴＣサーバ１５０への送信処理を行うＭＴＣデバイス１００の処理フローの一例を示すフロー図であり、図９Ｂは、本発明の第２の実施の形態において、ネットワーク側（例えば、ＭＭＥ１２０）から逆イベント通知メッセージを受信したＭＴＣデバイス１００の処理フローの一例を示すフロー図である。
最初に、図９Ａを参照しながら、ＭＴＣデバイス１００がイベントを検知した際に、ノーマルモード又は高優先度モードでＭＴＣサーバ１５０への送信する場合の処理フローについて説明する。
ＭＴＣデバイス１００は、ＭＴＣサーバ１５０と通信を行うために、ＰＧＷ１４０との間にＰＤＮコネクション及びＥＰＳベアラを確立する（図９ＡのステップＳ６０１）。
ここで、ＭＴＣデバイス１００は、イベント検知部５０５でイベントを検知したとする（図９ＡのステップＳ６０２）。なお、イベントの検知は、例えば、煙センサであれば煙の検知、炎センサであれば炎の検知、人感センサであれば人物の検知などである。イベント検知後、ＭＴＣデバイス１００は、送信モードに関する情報を取得し（図９ＡのステップＳ６０３）、高い優先度のメッセージでＭＴＣサーバ１５０に送信するかどうかを、イベント通知メッセージ判断部５０３で判断する（図９ＡのステップＳ６０４）。
送信モードが高優先モードであり、高い優先度のイベント通知メッセージでＭＴＣサーバ１５０に通知すると判断した場合、ＭＴＣデバイス１００は通信処理部５０１で例えば、イベントフラグ（例えば、煙発生）、センシングデータ、デバイス種ＩＤを生成し（図９ＡのステップＳ６０５）、このイベント情報を格納したイベント通知メッセージ（イベント情報）＠デバイスＡを、通信システムを通じてＭＴＣサーバ１５０に送信する（図９ＡのステップＳ６０６）。
なお、上述のように、例えば、“Ｔｉｍｅ Ｃｏｎｔｒｏｌｌｅｄ” が適用されたＭＴＣデバイス１００が、割り当てられた時間外にアクセスしてきた場合に、ＭＴＣデバイス１００が高優先度モードで通知すべきイベントを検出したものとネットワーク側（例えば、ＭＭＥ１２０）が判断できる場合、ＭＴＣデバイス１００は、イベントフラグをイベント通知メッセージ（イベント情報）＠デバイスＡに格納する必要はない。また、上記以外の手段を用いて、ＭＴＣデバイス１００がイベントを検知したことをネットワーク側が確認できるのであれば、同様にイベントフラグを省略してもよい。また、デバイス種ＩＤも同様に、例えば、デバイスＩＤのうちデバイス種別を示す一部のビット列（例えば、上位あるいは下位数ビット）からＭＴＣデバイス１００の種類を導出し、ＭＴＣデバイス１００の種類をネットワーク側で識別できるのであれば、デバイス種ＩＤを格納する必要はない。
一方、送信モードがノーマルモードであり、一般的な優先度で検知したイベント（例えば、煙発生）とセンシングデータをＭＴＣサーバ１５０に送信すると判断した場合、ＭＴＣデバイス１００は、通常通り、イベント通知メッセージ（イベント情報）＠デバイスＡと取得したセンシングデータを、通信処理部５０１から送信する（図９のステップＳ６０７）。
なお、上述のように、ＭＴＣデバイス１００は、一定時間後（例えば、逆イベント通知メッセージで通知されたライフタイム値など）、又は、ＭＭＥ１２０、ＭＴＣサーバ１５０から送信されるメッセージ（例えば、ＮＡＳメッセージなど）を受信したときに、高優先度モードからノーマルモード、若しくは、ノーマルモードから高優先度モードに戻す処理を行ってもよい（図９Ａには不図示）。
次に、図９Ｂを参照しながら、ＭＴＣデバイス１００がネットワーク側（例えば、ＭＭＥ１２０）から逆イベント通知メッセージを受信した場合の処理フローについて説明する。
ＭＴＣデバイス１００は、ＭＴＣサーバ１５０と通信を行うために、ＰＧＷ１４０との間にＰＤＮコネクション及びＥＰＳベアラを確立する（図９ＢのステップＳ７０１）。
ここで、ＭＴＣデバイス１００は、通信システムから何らかのメッセージを受信すると、受信したメッセージが逆イベント通知メッセージ（イベント情報）であるかどうかを逆イベント通知メッセージ処理部５０２にて判断する（図９ＢのステップＳ７０２）。逆イベント通知メッセージ（イベント情報）ではないと判断した場合には、そのメッセージに適した別の処理が行われる（図９Ｂには不図示）。
一方、逆イベント通知メッセージ（イベント情報）だと判断した場合、ＭＴＣデバイス１００は、逆イベント通知メッセージ（イベント情報）からデバイス種ＩＤを抽出し、同一のデバイス種ＩＤが格納された逆イベント通知メッセージ（イベント情報）を再度受信した場合を特定するために、抽出されたデバイス種ＩＤを逆イベント通知メッセージ処理部５０２にて記憶する（図９ＢのステップＳ７０３）。
続いて、逆イベント通知メッセージ処理部５０２において、ＭＴＣデバイス１００自身のデバイスＩＤ／デバイス種ＩＤと逆イベント通知メッセージ（イベント情報）に格納されているデバイス種ＩＤとが一致しているかどうかを確認する（図９ＢのステップＳ７０５）。ＭＴＣデバイス１００自身のデバイスＩＤ／デバイス種ＩＤと逆イベント通知メッセージ（イベント情報）に格納されているデバイス種ＩＤとが一致する場合は、自デバイスと同じ種類のＭＴＣデバイス１００からイベント通知メッセージが既に送信されていると判断でき、ＭＴＣデバイス１００は、ノーマルモードで動作を行う（図９ＢのステップＳ７０６）。なお、ステップＳ７０６では、ＭＴＣデバイスが高優先度モードだった場合は、送信モード制御部５０４においてノーマルモードに遷移し、ＭＴＣデバイスがノーマルモードだった場合は、そのままノーマルモードを維持する。
一方、ＭＴＣデバイス１００自身のデバイスＩＤ／デバイス種ＩＤと逆イベント通知メッセージ（イベント情報）に格納されているデバイス種ＩＤとが一致しない場合は、逆イベント通知メッセージ処理部５０２において、逆イベント通知メッセージ（イベント情報）に含まれるイベントグループ情報ラベルに対応するイベントグループ情報を読み出し（図９ＢのステップＳ７０７）、逆イベント通知メッセージ（イベント情報）から抽出したデバイス種ＩＤが、イベントグループ情報に登録されているかどうかを確認する（図９ＢのステップＳ７０８）。逆イベント通知メッセージ（イベント情報）から抽出したデバイス種ＩＤがイベントグループ情報に登録されていない場合は、受信した逆イベント通知メッセージはＭＴＣデバイス１００が関与していないイベントに係る逆イベント通知メッセージ（イベント情報）であると判断でき、ＭＴＣデバイス１００は、処理を終了する。なお、デバイス種ＩＤのリストが登録されたイベントグループ情報をＭＴＣデバイス１００に保持させるのではなく、自デバイス種とそのラベルとが関連付けられているかどうかを示す情報を保持させることも可能であり、この場合には、ＭＴＣデバイス１００は、ステップＳ７０８において、「自デバイス種とラベル名（例えば「火災」）とが関連付けられているかどうかを確認するだけでよい。
一方、逆イベント通知メッセージ（イベント情報）から抽出したデバイス種ＩＤが、イベントグループ情報に登録いる場合は、受信した逆イベント通知メッセージ（イベント情報）はＭＴＣデバイス１００が関与しているイベントに係る逆イベント通知メッセージ（イベント情報）であると判断できる。この場合、ＭＴＣデバイス１００は、逆イベント通知メッセージ処理部５０２に記憶されているデバイス種ＩＤを確認し、同じ種類のＭＴＣデバイス１００から送信されたイベント通知メッセージ（イベント情報）に対する逆イベント通知メッセージ（イベント情報）を既に受信しているかどうかを判断する（図９ＢのステップＳ７０９）。そして、ＭＴＣデバイス１００は、同じ種類のＭＴＣデバイス１００から送信されたイベント通知メッセージ（イベント情報）に対する逆イベント通知メッセージ（イベント情報）を既に受信している場合は処理を終了し、一方、同じ種類のＭＴＣデバイス１００から送信されたイベント通知メッセージ（イベント情報）に対する逆イベント通知メッセージ（イベント情報）を初めて受信した場合は、高優先度モードで動作を行う（図９ＢのステップＳ７１０）。なお、ステップＳ７１０では、ＭＴＣデバイス１００が高優先度モードだった場合は、送信モード制御部５０４においてそのまま高優先度モードを維持し、ＭＴＣデバイスがノーマルモードだった場合は、高優先度モードに遷移する。このようにして決定された送信モードは、図９Ａに図示されている送信モードの確認処理（図９ＡのステップＳ６０３）で参照される。
なお、ステップＳ７０５の自デバイス種ＩＤとの一致を確認するタイミング、ステップＳ７０８の逆イベント通知メッセージ（イベント情報）から抽出されたデバイス種ＩＤがイベントグループ情報に登録されているかどうかを確認するタイミング、ステップＳ７０９の逆イベント通知メッセージ（イベント情報）の受信を既に行っているデバイス種かどうかを確認するタイミングは、順序が異なっていてもよい。
次に、図１０を参照しながら、本発明の第２の実施の形態におけるＭＭＥの構成について説明する。図１０は、本発明の第２の実施の形態におけるＭＭＥ１２０の構成の一例を示す図である。
図１０において、ＭＭＥ１２０は、通信システム（例えば、Ｅ−ＵＴＲＡＮやＵＴＲＡＮ）上で通信処理を行い、ＩＰなどのパケット通信処理を実施する通信処理部８０１、受信メッセージが高い優先度で送られてきたイベント通知メッセージであるか判断した後、イベント情報を取得し、取得したイベント情報を記憶するイベント通知メッセージ処理部８０３、同一イベント、又は、そのイベントによって引き起こされたイベントによる冗長なイベント通知メッセージの受信を抑制するためにイベント通知メッセージから取得したイベント情報を格納した逆イベント通知メッセージをブロードキャスト送信するか判断する逆イベント通知メッセージ処理部８０２を少なくとも有する。なお、例えば、逆イベント通知メッセージ処理部８０２が、イベント通知メッセージ処理部８０３の機能を保持している場合、イベント通知メッセージ処理部８０３を省略できる。他の機能部も同様に、１つの機能部で上記の機能部を含む場合は、省略してもよい。
なお、ＭＭＥ１２０において上述の各構成要素が動作を行うことで、ＭＴＣデバイス１００から、特定のイベントの発生を検知したことを通知するイベント通知メッセージを受信する受信部としての機能、イベント通知メッセージに対する応答として、送信モードをノーマルモードへ遷移するか又はノーマルモードのまま維持するよう指示するメッセージを作成するメッセージ作成部としての機能、メッセージをＭＴＣデバイス１００へ送信するメッセージ送信部としての機能を有している。
次に、図１０に図示されている構成を有するＭＭＥ１２０について、本発明における特徴的な処理を中心に、図１１を用いて詳しく説明する。図１１は、本発明の第２の実施の形態におけるＭＭＥ１２０の処理フローの一例を示すフロー図である。
ＭＭＥ１２０は、ＭＴＣデバイスＡ１００Ａから送信されたメッセージを受信し、イベント通知メッセージ処理部８０３にて、このメッセージが優先度の高いイベント通知メッセージ（イベント情報）＠デバイスＡであると判断したとする（図１１のステップＳ９０１）。なお、ＭＭＥ１２０は、イベント通知メッセージ（イベント情報）＠デバイスＡだと判断する際に、イベント通知メッセージ（イベント情報）＠デバイスＡのイベントフラグフィールドを参照してもよい。
続いて、ＭＭＥ１２０は、イベント通知メッセージ処理部８０３にて、受信したイベント通知メッセージ（イベント情報）＠デバイスＡからイベント情報を取得する（図１１のステップＳ９０２）。そして、ＭＭＥ１２０は、同一イベント、又は、そのイベントを引き起こした出来事によって引き起こされたイベントによる冗長なイベント通知メッセージの送信を抑制するために逆イベント通知メッセージ（イベント情報）をＭＴＣグループのＭＴＣデバイス１００に送信するかどうかを逆イベント通知メッセージ処理部８０２にて判断する（図１１のステップＳ９０３）。なお、逆イベント通知メッセージ（イベント情報）を送信するかどうか（あるいは、高優先度モードによる動作を要求するために、どのラベルを逆イベント通知メッセージに付加するか）を判断する際、逆イベント通知メッセージ処理部８０２に保持されているイベントグループ情報を用いて判断してもよい。また、ＨＬＲ／ＨＳＳ１２５にＭＴＣデバイス１００の情報（例えば、サブスクリプションデータ）を問い合わせて判断してもよい。
逆イベント通知メッセージ（イベント情報）を送信すると判断した場合、ＭＭＥ１２０は、例えば、イベント通知メッセージ（イベント情報）＠デバイスＡから取得されたデバイス種ＩＤを格納した逆イベント通知メッセージ（イベント情報）をＭＴＣデバイスＡ１００Ａが属するＭＴＣグループの全てのＭＴＣデバイス（ＭＴＣデバイスＢ１００Ｂを含む）にブロードキャストで送信する（図１１のステップＳ９０４）。なお、ＭＭＥ１２０は、ＭＴＣデバイスＡ１００ＡがＭＴＣグループに属しているかどうかを判断する手段として、イベント通知メッセージ（イベント情報）＠デバイスＡに格納されているグループＩＤ（図５Ａには不図示）や、ＨＳＳ１２５が保持するサブスクリプションデータを用いてもよい。また、ＭＭＥ１２０が逆イベント通知メッセージ（イベント情報）を送信する際、ＭＭＥ１２０はイベント通知メッセージ（イベント情報）＠デバイスＡから抽出したデバイス種ＩＤを、再度イベント通知メッセージ（イベント情報）＠デバイスＡを受信した際に逆イベント通知メッセージ（イベント情報）を送信するかどうかを判断する際に用いるパラメータとして使用するため、例えば、逆イベント通知メッセージ処理部８０２にて記憶することが望ましい。なお、イベント通知メッセージ（イベント情報）＠デバイスＡから抽出するデバイス種ＩＤは、ＭＴＣデバイス１００の種類を識別するためのＩＤ以外を使用してもよいが、上述のように、各ＭＴＣデバイス１００が保持するイベントグループ情報に登録されている情報と関連している必要がある。
また、ＭＭＥ１２０は、逆イベント通知メッセージ（イベント情報）にイベントグループ情報ラベルを付加する場合、特定のデバイスからのイベント通知メッセージ（例えば、煙センサや炎センサ）に対して、事前に定められた特定のラベル名（例えば「火災」）を付加するように構成されていてもよく、また、イベント通知メッセージに含まれているイベント情報やセンシングデータ）、その他の情報などから、付加すべきイベントグループ情報ラベル名を決定してもよい。また、あるＭＴＣデバイス１００（例えば、煙センサ）から受信したイベント通知メッセージ（イベント情報）に応じてあるイベントグループ情報ラベル（例えば「火災」）を付加して逆イベント通知メッセージを送信した場合、イベントグループ情報などによって関連付けられている別のデバイス種のＭＴＣデバイス１００（例えば、炎センサ）からイベント通知メッセージを所定時間内に受信したときには、その逆イベント通知メッセージ（イベント情報）に同一のラベル名（例えば「火災））を付加するようにしてもよい。
また、ＭＭＥ１２０は、一定時間後、又は、ＭＴＣサーバ１５０／ＭＴＣユーザ１６０があらかじめ設定した仕様や登録情報、また設定情報などに基づいて、ＭＴＣデバイス１００又はＭＭＥ１２０が保持している情報を解放するためのメッセージ（例えば、ＮＡＳメッセージで、ＭＴＣデバイス１００が持つ送信モードの定常化（高優先度モードからノーマルモード、若しくは、ノーマルモードから高優先度モード））を送信してもよい（図１１には不図示）。
また、上述の説明では、ＭＭＥ１２０が逆イベント通知メッセージ（イベント情報）を送信しているが、ＭＴＣサーバ１５０が逆イベント通知メッセージ（イベント情報）を送信することも可能である。なお、本発明の第２の実施の形態において、ＭＴＣサーバ１５０が逆イベント通知メッセージ（イベント情報）を送信する場合のＭＴＣサーバ１５０の構成は、図１０に図示されているＭＭＥ１２０の構成と同様であり、ここでは説明を省略する。
同様に、本発明の第２の実施の形態において、ＭＴＣサーバ１５０の処理フローは、図１０に図示されているＭＭＥ１２０の処理フロー（ずなわち、図１１に図示されている処理フロー）と同様であり、ここでは説明を省略する。
次に、図１２〜図１４を参照しながら、上述した本発明の第１及び第２の実施の形態における各ＭＴＣデバイス１００の動作とイベントグループ情報について、具体的な例を挙げながら説明する。
図１２は、本発明の第１及び第２の実施の形態に係る具体的な例を説明するために、各ＭＴＣデバイス１００の配置の一例を示す図である。図１２には、ＭＴＣグループ内に様々なＭＴＣデバイス１００（煙センサ、炎センサ、人感センサ、ガスセンサ、水道センサ、水道メータセンサ、地震センサ、ドアロックセンサなど）が多数配置されている状態が模式的に図示されている。図１２に図示されているように、例えば、多数のＭＴＣデバイス１００が１つの施設内に配置されることで、例えば、施設内で発生し得るイベント（事故や災害など）を監視している。以下では、同一ＭＴＣグループ内の多数のＭＴＣデバイス１００のうち、２つの煙センサ、２つの炎センサ、２つの人感センサ、１つのドアロックセンサ、１つの水道センサに焦点を当てて、本発明に係る動作について具体的に説明する。
なお、煙センサは、通常は高優先度モードで動作し、煙の発生を検知すると高優先度のイベント通知メッセージを送信するよう構成されているとする。また、炎センサは、通常は高優先度モードで動作し、炎の発生を検知（熱の検知）すると高優先度のイベント通知メッセージを送信するよう構成されているとする。また、人感センサは、通常はノーマルモードで動作し、人の存在の有無の情報をセンシングデータとしてノーマルモードで送信するよう構成されているとする。また、ドアロックセンサは、通常は高優先度モードで動作し、施錠されたドアの開錠を検知すると高優先度のイベント通知メッセージを送信するよう構成されているとする。また、水道メータセンサは、通常はノーマルモードで動作し、水道メータの値（検針値）をセンシングデータとしてノーマルモードで送信するよう構成されているとする。
＜図１３の（１）＞
本発明の第１の実施の形態によれば、例えば、ある煙センサが煙の発生を検知し、ＭＴＣサーバ１５０へイベント通知メッセージを送信すると、ＭＭＥ１２０からＭＴＣグループ内のすべてのＭＴＣデバイス１００へ逆イベント通知メッセージが送信される。
本発明の第１の実施の形態によれば、例えば、ある煙センサが煙の発生を検知し、ＭＴＣサーバ１５０へイベント通知メッセージを送信すると、ＭＭＥ１２０からＭＴＣグループ内のすべてのＭＴＣデバイス１００へ逆イベント通知メッセージが送信される。
この場合、逆イベント通知メッセージを受信するＭＴＣデバイス１００（すなわち、ＭＴＣグループ内のすべてのＭＴＣデバイス１００）は、ノーマルモードへ遷移する（元々ノーマルモードの場合はそのまま維持）。具体的には、図１３の（１）に図示されているように、煙センサ、炎センサ、ドアロックセンサは高優先度モードからノーマルモードへ遷移し、人感センサはノーマルモードを維持し続ける。また、その他のＭＴＣデバイス１００（例えば、地震センサや水道センサなど）も、すべてノーマルモードによる動作を行うよう制御される。
＜図１３の（２）、図１４の（Ａ）、（Ｂ）＞
また、本発明の第２の実施の形態によれば、例えば、ある煙センサが煙の発生を検知し、ＭＴＣサーバ１５０へイベント通知メッセージ（イベント情報）を送信すると、ＭＭＥ１２０からＭＴＣグループ内のすべてのＭＴＣデバイス１００へ逆イベント通知メッセージ（イベント情報）が送信される。この場合、ＭＴＣグループ内のすべてのＭＴＣデバイス１００は、デバイス種ＩＤ「煙センサ」及びイベントグループ情報ラベル名「火災」を含む逆イベント通知メッセージ［煙｜火災］を受信する。
また、本発明の第２の実施の形態によれば、例えば、ある煙センサが煙の発生を検知し、ＭＴＣサーバ１５０へイベント通知メッセージ（イベント情報）を送信すると、ＭＭＥ１２０からＭＴＣグループ内のすべてのＭＴＣデバイス１００へ逆イベント通知メッセージ（イベント情報）が送信される。この場合、ＭＴＣグループ内のすべてのＭＴＣデバイス１００は、デバイス種ＩＤ「煙センサ」及びイベントグループ情報ラベル名「火災」を含む逆イベント通知メッセージ［煙｜火災］を受信する。
逆イベント通知メッセージ［煙｜火災］の受信によって、煙センサは、同じデバイス種からイベント通知メッセージ（イベント情報）が送信されたことを把握し、ノーマルモードに遷移する。一方、炎センサは、異なるデバイス種からイベント通知メッセージ（イベント情報）が送信されたことを把握し、そのまま高優先度モードを維持する。また、人感センサは、ラベル名「火災」を含む逆イベント通知メッセージ（イベント情報）を受信することで、ノーマルモードから高優先度モードへ遷移する。また、ドアロックセンサは、自デバイスとは関連性のない逆イベント通知メッセージ（イベント情報）であることを把握し、そのまま高優先度モードを維持する。
さらに、ある炎センサが炎の発生を検知し、ＭＴＣサーバ１５０へイベント通知メッセージ（イベント情報）を送信したとすると、ＭＭＥ１２０からＭＴＣグループ内のすべてのＭＴＣデバイス１００へ逆イベント通知メッセージ（イベント情報）が送信される。この場合、ＭＴＣグループ内のすべてのＭＴＣデバイス１００は、デバイス種ＩＤ「炎センサ」及びラベル名「火災」を含む逆イベント通知メッセージ［炎｜火災］を受信する。
逆イベント通知メッセージ［炎｜火災］の受信によって、炎センサは、同じデバイス種からイベント通知メッセージが送信されたことを把握し、ノーマルモードに遷移する。一方、煙センサは、同一の出来事（火災の発生）によって引き起こされたイベントの逆イベント通知メッセージ（すなわち、逆イベント通知メッセージ［煙｜火災］）の受信によってノーマルモードへの遷移を行っているので、そのままノーマルモードを維持し続ける。また、人感センサは、同一の出来事（火災の発生）によって引き起こされたイベントの逆イベント通知メッセージ（すなわち、逆イベント通知メッセージ［煙｜火災］）の受信によって高優先度モードへの遷移を既に行っているので、そのまま高優先度モードを維持し続ける。また、ドアロックセンサは、自デバイスとは関連性のない逆イベント通知メッセージであることを把握し、そのまま高優先度モードを維持する。
さらに、ある人感センサが人物の存在を検知し、ＭＴＣサーバ１５０へイベント通知メッセージを送信したとすると、ＭＭＥ１２０からＭＴＣグループ内のすべてのＭＴＣデバイス１００へ逆イベント通知メッセージ（イベント情報）が送信される。この場合、ＭＴＣグループ内のすべてのＭＴＣデバイス１００は、デバイス種ＩＤ「人感センサ」及びラベル名「火災」を含む逆イベント通知メッセージ［人感｜火災］を受信する。
逆イベント通知メッセージ［人感｜火災］の受信によって、人感センサは、同じデバイス種からイベント通知メッセージが送信されたことを把握し、ノーマルモードに遷移する。一方、煙センサ及び炎センサは、同一の出来事（火災の発生）によって引き起こされたイベントの逆イベント通知メッセージ（すなわち、逆イベント通知メッセージ［煙｜火災］及び逆イベント通知メッセージ［炎｜火災］）の受信によってノーマルモードへの遷移を行っているので、そのままノーマルモードを維持し続ける。また、ドアロックセンサは、自デバイスとは関連性のない逆イベント通知メッセージであることを把握し、そのまま高優先度モードを維持する。
図１３の（２）のような動作を実現するためには、例えば、図１４の（Ａ）に図示されているように、例えば、煙センサにラベル名「火災」のイベントグループ情報（炎センサ及び人感センサのデバイス種ＩＤが登録されている）を持たせ、炎センサにラベル名「火災」のイベントグループ情報（煙センサ及び人感センサのデバイス種ＩＤが登録されている）を持たせ、人感センサにラベル名「火災」のイベントグループ情報（炎センサ及び煙センサのデバイス種ＩＤが登録されている）を持たせればよい。なお、ドアロックセンサなどのような関連性のないＭＴＣデバイス１００においては、ラベル名「火災」のイベントグループ情報を持たせないようにしておくか、あるいは、デバイス種ＩＤが登録されていないラベル名「火災」のイベントグループ情報を持たせるようにしておく。
上述の図１４の（Ａ）のようなイベントグループ情報の持たせ方によれば、個々のデバイス種によって異なるイベントグループ情報を持たせることになるが、別の方法として、全ＭＴＣデバイス１００に共通（同一）のイベントグループ情報を持たせるようにすることも可能である。この場合、例えば図９ＢのステップＳ７０８の処理において、逆イベント通知メッセージ（イベント情報）に含まれているデバイス種ＩＤがイベントグループ情報に含まれているかどうかを確認することに加えて、さらに、自デバイス種ＩＤがイベントグループ情報に含まれているかどうかを確認することで、本発明に係る動作が実現可能となる。なお、この場合も、ドアロックセンサなどのような関連性のないＭＴＣデバイス１００においては、ラベル名「火災」のイベントグループ情報を持たせないようにしておいてもよい。
図１４の（Ａ）のように、個々のＭＴＣデバイス１００が異なるイベントグループ情報を持つようにする場合には、モード遷移に関してより詳細な管理を行うことができる。例えば、人感センサが持つラベル名「火災」のイベントグループ情報に、煙センサのみが登録された状態に変更することによって、人感センサは、煙センサのデバイス種ＩＤを含む逆イベント通知メッセージ（イベント情報）を受信した場合には高優先度モードへ遷移するが、炎センサのデバイス種ＩＤを含む逆イベント通知メッセージ（イベント情報）を受信した場合にはノーマルモードをそのまま維持するように設定することが可能となる。なお、このような状態を想定しない場合（特定のイベントに対して、どのデバイス種のＭＴＣデバイス１００からイベント通知メッセージが送信された場合であっても、関連するラベルを持っているＭＴＣデバイス１００は高優先度モードに遷移する場合）は、自デバイス種がそのラベル名に関連付けられているかどうかを確認するだけでよい。すなわち、各ＭＴＣデバイス１００のデバイス種ＩＤが登録されているイベントグループ情報を持つ必要はなく、単に、自デバイス種とラベル名（例えば「火災」）とが関連付けられているかどうかを示す情報を持っているだけでよい。一方、図１４の（Ｂ）のように、ＭＴＣデバイス１００が共通のイベントグループ情報を持つようにする場合には、どのＭＴＣデバイス１００にどのイベントグループ情報を持たせる必要があるかを考慮せずに、全ＭＴＣデバイスに対してイベントグループ情報を一括配信して保持させることが可能となる。
＜図１３の（３）、図１４の（Ｃ）、（Ｄ）＞
また、本発明の第２の実施の形態では、複数のイベントグループ情報を設定することで、イベントごと（ラベル名ごと）に、ＭＴＣデバイス１００のモード遷移を変えることが可能である。例えば、あるドアロックセンサがドアの開錠（不審者侵入の可能性）を検知し、ＭＴＣサーバ１５０へイベント通知メッセージ（イベント情報）を送信すると、ＭＭＥ１２０からＭＴＣグループ内のすべてのＭＴＣデバイス１００へ逆イベント通知メッセージ（イベント情報）が送信される。この場合、ＭＴＣグループ内のすべてのＭＴＣデバイス１００は、デバイス種ＩＤ「ドアロックセンサ」（ここでは、開錠と表記）及びラベル名「侵入」を含む逆イベント通知メッセージ［開錠｜侵入］を受信する。
また、本発明の第２の実施の形態では、複数のイベントグループ情報を設定することで、イベントごと（ラベル名ごと）に、ＭＴＣデバイス１００のモード遷移を変えることが可能である。例えば、あるドアロックセンサがドアの開錠（不審者侵入の可能性）を検知し、ＭＴＣサーバ１５０へイベント通知メッセージ（イベント情報）を送信すると、ＭＭＥ１２０からＭＴＣグループ内のすべてのＭＴＣデバイス１００へ逆イベント通知メッセージ（イベント情報）が送信される。この場合、ＭＴＣグループ内のすべてのＭＴＣデバイス１００は、デバイス種ＩＤ「ドアロックセンサ」（ここでは、開錠と表記）及びラベル名「侵入」を含む逆イベント通知メッセージ［開錠｜侵入］を受信する。
このとき、図１３の（３）のように、例えば、逆イベント通知メッセージ［開錠｜侵入］の受信によって、人感センサのみモード遷移（ノーマルモードから高優先度モード）させ、その後、人感センサが人物の存在を検知し、ＭＴＣサーバ１５０へイベント通知メッセージ（イベント情報）を送信した場合に、他の人感センサのモードを高優先度モードからノーマルモードに戻す動作を行わせるとする。
このような場合には、ＭＴＣデバイス個別にイベントグループ情報を設定する方法において、図１４の（Ｃ）のように、人感センサにラベル名「侵入」のイベントグループ情報（ドアロックセンサのデバイス種ＩＤが登録されている）を持たせるか、あるいは、ＭＴＣデバイス１００に共通のイベントグループ情報を設定する方法において、図１４の（Ｄ）のように、全ＭＴＣデバイス１００に人感センサにラベル名「侵入」のイベントグループ情報（人感センサ及びドアロックセンサのデバイス種ＩＤが登録されている）を持たせればよい。この場合、少なくとも人感センサは、ラベル名の異なる複数のイベントグループ情報を保持することになる。
＜図１３の（４）＞
また、上述の本発明の第２の実施の形態では、例えば、デバイス種ＩＤ及びイベントグループ情報ラベル（ラベル名）の両方がイベント情報として含まれた逆イベント通知メッセージ（イベント情報）の送信が行われている。しかしながら、イベントグループ情報ラベル（ラベル名）を用いず、イベントグループ情報による詳細な設定が行われないような構成として、デバイス種ＩＤのみを含む逆イベント通知メッセージの送信が行われるようにしてもよい。この方法は、第１の実施の形態における逆イベント通知メッセージによって行われるノーマルモードへのモード遷移の指示を、イベント通知メッセージを送信したＭＴＣデバイス１００と同じ種類のＭＴＣデバイスに対してのみ行うものであると言える。また、図９Ｂの動作（本発明の第２の実施の形態における動作）において、ステップＳ７０７〜Ｓ７０９の処理を行わないものであるとも言える。
また、上述の本発明の第２の実施の形態では、例えば、デバイス種ＩＤ及びイベントグループ情報ラベル（ラベル名）の両方がイベント情報として含まれた逆イベント通知メッセージ（イベント情報）の送信が行われている。しかしながら、イベントグループ情報ラベル（ラベル名）を用いず、イベントグループ情報による詳細な設定が行われないような構成として、デバイス種ＩＤのみを含む逆イベント通知メッセージの送信が行われるようにしてもよい。この方法は、第１の実施の形態における逆イベント通知メッセージによって行われるノーマルモードへのモード遷移の指示を、イベント通知メッセージを送信したＭＴＣデバイス１００と同じ種類のＭＴＣデバイスに対してのみ行うものであると言える。また、図９Ｂの動作（本発明の第２の実施の形態における動作）において、ステップＳ７０７〜Ｓ７０９の処理を行わないものであるとも言える。
例えば、ある煙センサが煙の発生を検知し、ＭＴＣサーバ１５０へイベント通知メッセージを送信すると、ＭＭＥ１２０からＭＴＣグループ内のすべてのＭＴＣデバイス１００へ、デバイス種ＩＤ「煙センサ」を含む逆イベント通知メッセージ（イベント情報）が送信される。
この場合、ＭＴＣグループ内のすべてのＭＴＣデバイス１００が、デバイス種ＩＤ「煙センサ」を含む逆イベント通知メッセージを受信するが、図１３の（４）に図示されているように、この逆イベント通知メッセージに含まれているデバイス種ＩＤと同じ種類のＭＴＣデバイス（すなわち、すべての煙センサ）のみ、モード遷移（ノーマルモードへの遷移）を行う。
＜図１３の（５）、図１４の（Ｅ）＞
また、上述の本発明の第２の実施の形態では、例えば、デバイス種ＩＤ及びイベントグループ情報ラベル（ラベル名）の両方がイベント情報として含まれた逆イベント通知メッセージ（イベント情報）の送信が行われているが、逆イベント通知メッセージ（イベント情報）に、デバイス種ＩＤを挿入せず、イベントグループ情報ラベル（ラベル名）のみを付加することも可能である。この方法は、図９Ｂの動作（本発明の第２の実施の形態における動作）において、ステップＳ７０５の処理を行わないものであると言える。
また、上述の本発明の第２の実施の形態では、例えば、デバイス種ＩＤ及びイベントグループ情報ラベル（ラベル名）の両方がイベント情報として含まれた逆イベント通知メッセージ（イベント情報）の送信が行われているが、逆イベント通知メッセージ（イベント情報）に、デバイス種ＩＤを挿入せず、イベントグループ情報ラベル（ラベル名）のみを付加することも可能である。この方法は、図９Ｂの動作（本発明の第２の実施の形態における動作）において、ステップＳ７０５の処理を行わないものであると言える。
例えば、ある煙センサが煙の発生を検知し、ＭＴＣサーバ１５０へイベント通知メッセージを送信すると、ＭＭＥ１２０からＭＴＣグループ内のすべてのＭＴＣデバイス１００へ、ラベル名「火災」を含む逆イベント通知メッセージが送信される。
ここで、図１４の（Ｅ）に図示されているように、人感センサのみが、自デバイス種とラベル名「火災」とが関連付けられていることを示す情報を持っているとする。なお、図１４の（Ｅ）では、人感センサは、ラベル名「火災」のイベントグループ情報を保持しているのが図示されているように、ラベル名「火災」を含む逆イベント通知メッセージの受信時にモード遷移を行うことが特定できるような情報であれば、情報の持ち方は限定されるものではない。
ＭＴＣグループ内のすべてのＭＴＣデバイス１００が逆イベント通知メッセージ［火災］を受信するが、例えば、煙センサ、炎センサ、ドアロックセンサなどのＭＴＣデバイス１００は、ラベル名「火災」に関連付けられておらず、モード遷移を行わない。一方、人感センサは、ラベル名「火災」に関連付けられており、逆イベント通知メッセージ［火災］の受信によってモード遷移（高優先度モードへの遷移）を行う。
なお、図１３の（５）及び図１４の（Ｅ）の例によれば、人感センサ以外のＭＴＣデバイス１００のモードはそのまま維持される一方、人感センサのモードが高優先度モードへ遷移するため、ＭＴＣデバイス１００からのイベント通知メッセージの送信を抑制できているわけではない。しかしながら、あるＭＴＣデバイス１００からイベント通知メッセージが送信されたことを契機として、通常はノーマルモードで動作しているＭＴＣデバイス１００（例えば、人感センサ）の送信モードを高優先度モードに変更できるという点において有用である。すなわち、通常はノーマルモードで動作しているＭＴＣデバイス１００（人感センサ）を、必要に応じて迅速に高優先度モードに遷移させることが可能となる。
＜第３の実施の形態＞
上記の実施の形態の解決手法によれば、ＭＴＣデバイス１００が通知するイベント通知メッセージとＭＭＥ１２０が送信する逆イベント通知メッセージは、共にＣプレーン上で交換されていたが、ＭＴＣデバイス１００が通知するイベント通知メッセージはＵプレーンで、逆イベント通知メッセージはネットワーク装置（例えば、ＭＭＥ１２０、ＭＴＣサーバ１５０やＰＧＷ１４０）によってＣプレーンが用いられる場合がある。例えば、通信システムのオペレータ、ＭＴＣサーバ１５０やＭＴＣユーザ１６０によって、静的、若しくは、動的に設定されるＭＴＣサービスの仕様や登録情報、また設定情報などに基づいて、ＭＴＣサービスにおけるメッセージは基本的にＵプレーン上で交換すると設定されている場合、イベント（例えば、煙発生）を検知したＭＴＣデバイス１００は、Ｕプレーンを用いてイベント通知メッセージをＰＧＷ１４０／ＭＴＣサーバ１５０に通知する。ここで、ネットワーク装置（例えば、ＰＧＷ１４０／ＭＴＣサーバ１５０）はＭＴＣサービスの仕様や登録情報、また設定情報などに基づいて、イベント通知メッセージの応答である逆イベント通知メッセージをＵプレーンを用いて送信したいが、ＭＭＥ１２０経由で逆イベント通知メッセージを送信しなければならない場合（例えば、ＭＭＥ１２０がイベント通知メッセージに格納されているイベント情報（例えば、デバイスＩＤ／デバイス種ＩＤ）を用いて、ＭＴＣデバイス１００の管理情報を更新しなければならない場合）がある。このようなケースが、本発明の第４の実施の形態に相当する。
上記の実施の形態の解決手法によれば、ＭＴＣデバイス１００が通知するイベント通知メッセージとＭＭＥ１２０が送信する逆イベント通知メッセージは、共にＣプレーン上で交換されていたが、ＭＴＣデバイス１００が通知するイベント通知メッセージはＵプレーンで、逆イベント通知メッセージはネットワーク装置（例えば、ＭＭＥ１２０、ＭＴＣサーバ１５０やＰＧＷ１４０）によってＣプレーンが用いられる場合がある。例えば、通信システムのオペレータ、ＭＴＣサーバ１５０やＭＴＣユーザ１６０によって、静的、若しくは、動的に設定されるＭＴＣサービスの仕様や登録情報、また設定情報などに基づいて、ＭＴＣサービスにおけるメッセージは基本的にＵプレーン上で交換すると設定されている場合、イベント（例えば、煙発生）を検知したＭＴＣデバイス１００は、Ｕプレーンを用いてイベント通知メッセージをＰＧＷ１４０／ＭＴＣサーバ１５０に通知する。ここで、ネットワーク装置（例えば、ＰＧＷ１４０／ＭＴＣサーバ１５０）はＭＴＣサービスの仕様や登録情報、また設定情報などに基づいて、イベント通知メッセージの応答である逆イベント通知メッセージをＵプレーンを用いて送信したいが、ＭＭＥ１２０経由で逆イベント通知メッセージを送信しなければならない場合（例えば、ＭＭＥ１２０がイベント通知メッセージに格納されているイベント情報（例えば、デバイスＩＤ／デバイス種ＩＤ）を用いて、ＭＴＣデバイス１００の管理情報を更新しなければならない場合）がある。このようなケースが、本発明の第４の実施の形態に相当する。
以下、本発明の第３の実施の形態におけるシステム動作の一例について、図１５を用いて詳しく説明する。図１５は、本発明の第３の実施の形態におけるシステム動作の一例（複数のＭＴＣデバイス１００から送信される同一イベント、又は、そのイベントを引き起こした出来事によって引き起こされたイベントによる優先度の高いイベント通知メッセージの送信抑制方法）を説明するためのシーケンス図である。なお、図１５には、図１に図示したシステム構成における処理シーケンスの一例を図示する。ここで、ＭＴＣデバイス１００の特徴は、本発明の第２の実施の形態における特徴と同様であり、ここでは説明を省略する。
以下、図１５に図示されているシーケンスについて説明する。ステップＳ３２１〜ステップＳ３２２は、本発明の第２の実施の形態におけるステップＳ３０１〜ステップＳ３０２（図４を参照）と同様なので、ここでは説明を省略する。
続いて、ＭＴＣデバイスＡ１００Ａは、検知したイベント情報（例えば、煙センサＩＤ）を格納したイベント通知メッセージ（イベント情報）をＵプレーン上で、ＭＴＣサーバ１５０に通知する（ステップＳ３２３：イベント通知メッセージ（イベント情報）＠デバイスＡ）。すなわち、ＭＴＣデバイスＡ１００Ａから通知されるイベント通知メッセージ（イベント情報）＠デバイスＡは、ｅＮＢ１１０、ＳＧＷ１３０、ＰＧＷ１４０、ＭＴＣサーバ１５０という順に転送される。なお、ここでは、ＭＴＣサーバ１５０が、イベント通知メッセージ（イベント情報）の通知先になっているが、通信システムのオペレータ、ＭＴＣサーバ１５０やＭＴＣユーザ１６０によって設定される仕様や登録情報、また設定情報などに基づいて、イベント通知メッセージ（イベント情報）の送信先を他のネットワーク装置（例えば、ＰＧＷ１４０）にしてもよい。
続いて、ＭＴＣサーバ１５０は、受信したイベント通知メッセージ（イベント情報）からイベント情報を抽出し、逆イベント通知メッセージに格納する。そして、ＭＴＣサーバ１５０は、同一イベント（例えば、煙の発生）、若しくは、そのイベント（例えば、煙発生）を引き起こした出来事（例えば、火災発生）によって引き起こされたイベント（例えば、炎の発生）によるイベント通知メッセージの送信を抑制するために、逆イベント通知メッセージをＭＭＥ１２０に送信する。続いて、ＭＭＥ１２０がＣプレーンを用いてＭＴＣグループに属するＭＴＣデバイス１００に逆イベント通知メッセージをブロードキャスト（ステップＳ３２４：逆イベント通知メッセージ（イベント情報））。なお、ここでは、ＭＭＥ１２０が逆イベント通知メッセージを生成しているが、他のネットワーク装置（例えば、ＭＴＣサーバ１５０やＰＧＷ１４０が生成してもよい。その場合、ＭＭＥ１２０でないネットワーク装置（ＭＴＣサーバ１５０やＰＧＷ１４０）がブロードキャストしてもよい。
逆イベント通知メッセージを送信したＭＭＥ１２０は、逆イベント通知メッセージに格納されていたイベント情報（例えば、デバイスＩＤ）を抽出し、再度逆イベント通知メッセージをブロードキャストするか判断する際に使用するために記憶する（ステップＳ３２５：イベント情報の記憶）。なお、ステップＳ３２６以降は、本発明の第２の実施の形態のステップＳ３０６以降と同様なので、ここでは説明を省略する。
本発明の第３の実施の形態のように、ＭＴＣデバイス１００が通知するイベント通知メッセージはＵプレーンで、ネットワーク装置（例えば、ＭＭＥ１２０、ＭＴＣサーバ１５０やＰＧＷ１４０）から送信される逆イベント通知メッセージはＣプレーンを用いることで、ＭＴＣサービスにおけるメッセージが基本的にＵプレーンを用いて送信されると設定されている環境において、ネットワーク装置（例えば、ＰＧＷ１４０、ＭＴＣサーバ１５０）が、ＭＭＥ１２０経由（Ｃプレーン）で逆イベント通知メッセージを送信しなければいけない場合（例えば、ＭＭＥ１２０がイベント通知メッセージに格納されているイベント情報（例えば、デバイスＩＤ／デバイス種ＩＤ）を用いて、ＭＴＣデバイス１００の管理情報を更新しなければならない場合）に対応することができる。
＜第４の実施の形態＞
本発明の第４の実施の形態では、ＭＴＣデバイス１００が通知するイベント通知メッセージはＣプレーンで、ネットワーク装置（例えば、ＭＴＣサーバ１５０やＰＧＷ１４０）から送信される逆イベント通知メッセージはＵプレーンが用いられる場合について説明する。例えば、通信システムのオペレータ、ＭＴＣサーバ１５０やＭＴＣユーザ１６０によって、静的、若しくは、動的に設定されるＭＴＣサービスの仕様や登録情報、また設定情報などに基づいて、ＭＴＣサービスにおけるメッセージが基本的にＵプレーンを用いて送信されると設定されている環境において、ＭＴＣデバイス１００がイベント（例えば、煙発生）を検知したとする。本来であれば、ＭＴＣデバイス１００はＵプレーンを用いて、イベント通知メッセージをＰＧＷ１４０／ＭＴＣサーバ１５０に通知するが、ＭＭＥ１２０がＭＴＣデバイス１００の管理に必要とする情報が伴う場合（例えば、ＭＴＣデバイス１００が移動可能な煙センサ（例えば、煙発生を検知可能な移動ロボット）であり、イベント情報に加えてＭＴＣデバイス１００の位置情報を通知する場合や、ＭＴＣサービスがＭＴＣデバイス１００の位置情報も付加してイベント情報を通知するＭＴＣサービス（例えば、ＭＴＣデバイス１００が車などに搭載されていて、イベント検知時、位置情報も付加して送信するサービス）である場合）、あらかじめ通信システムのオペレータ、ＭＴＣサーバ１５０、ＭＴＣユーザ１６０によって設定されている仕様、登録情報や設定情報に基づいて、ＭＴＣデバイス１００の判断でＣプレーンを用いてイベント通知メッセージを通知する場合がある。
本発明の第４の実施の形態では、ＭＴＣデバイス１００が通知するイベント通知メッセージはＣプレーンで、ネットワーク装置（例えば、ＭＴＣサーバ１５０やＰＧＷ１４０）から送信される逆イベント通知メッセージはＵプレーンが用いられる場合について説明する。例えば、通信システムのオペレータ、ＭＴＣサーバ１５０やＭＴＣユーザ１６０によって、静的、若しくは、動的に設定されるＭＴＣサービスの仕様や登録情報、また設定情報などに基づいて、ＭＴＣサービスにおけるメッセージが基本的にＵプレーンを用いて送信されると設定されている環境において、ＭＴＣデバイス１００がイベント（例えば、煙発生）を検知したとする。本来であれば、ＭＴＣデバイス１００はＵプレーンを用いて、イベント通知メッセージをＰＧＷ１４０／ＭＴＣサーバ１５０に通知するが、ＭＭＥ１２０がＭＴＣデバイス１００の管理に必要とする情報が伴う場合（例えば、ＭＴＣデバイス１００が移動可能な煙センサ（例えば、煙発生を検知可能な移動ロボット）であり、イベント情報に加えてＭＴＣデバイス１００の位置情報を通知する場合や、ＭＴＣサービスがＭＴＣデバイス１００の位置情報も付加してイベント情報を通知するＭＴＣサービス（例えば、ＭＴＣデバイス１００が車などに搭載されていて、イベント検知時、位置情報も付加して送信するサービス）である場合）、あらかじめ通信システムのオペレータ、ＭＴＣサーバ１５０、ＭＴＣユーザ１６０によって設定されている仕様、登録情報や設定情報に基づいて、ＭＴＣデバイス１００の判断でＣプレーンを用いてイベント通知メッセージを通知する場合がある。
以下、本発明の第４の実施の形態におけるシステム動作の一例について、図１６を用いて詳しく説明する。図１６は、本発明の第４の実施の形態におけるシステム動作の一例（複数のＭＴＣデバイス１００から送信される同一イベント、又は、そのイベントを引き起こした出来事によって引き起こされたイベントによる優先度の高いイベント通知メッセージの送信抑制方法）を説明するためのシーケンス図である。なお、図１６には、図１に図示したシステム構成における処理シーケンスの一例を図示する。ここで、ＭＴＣデバイス１００の特徴は、本発明の第２の実施の形態における特徴と同様であり、ここでは説明を省略する。
以下、図１６に図示されているシーケンスについて説明する。ステップＳ３４１〜ステップＳ３４２は、本発明の第２の実施の形態におけるステップＳ３０１〜ステップＳ３０２（図４を参照）と同様なので、ここでは説明を省略する。
続いて、ＭＴＣデバイスＡ１００Ａは、検知したイベント情報（例えば、煙センサＩＤ）を格納したイベント通知メッセージ（イベント情報）をＣプレーン上で、ＭＭＥ１２０に通知する（ステップＳ３４３：イベント通知メッセージ（イベント情報）＠デバイスＡ）。
ＭＭＥ１２０は、ＭＴＣデバイスＡ１００Ａからイベント通知メッセージ（イベント情報）＠デバイスＡを受信し、必要な情報（例えば、ＭＴＣデバイスＡ１００Ａの位置情報やデバイスＩＤなど）を抽出し、例えば、ＭＴＣデバイスＡ１００Ａの管理処理（例えば、ＭＴＣデバイスＡ１００Ａのコンテキスト情報の更新や、位置情報の更新など）を行う（ステップＳ３４４：デバイスＡ管理処理）。
そして、ＭＭＥ１２０は、イベント通知メッセージ（イベント情報）＠デバイスＡに格納されていたイベント情報（例えば、デバイスＩＤやデバイス種ＩＤ）を抽出し、再度逆イベント通知メッセージをブロードキャストするか判断する際に使用するために記憶する（ステップＳ３４５：イベント情報の記憶）。
続いて、ＭＭＥ１２０は、受信したイベント通知メッセージ（イベント情報）をＭＴＣサーバ１５０に転送する（ステップＳ３４６）。このとき、ＭＭＥ１２０は、通信システムのオペレータ、ＭＴＣサーバ１５０やＭＴＣユーザ１６０によって設定された仕様、登録情報や設定情報に基づいて、受信したイベント通知メッセージ（イベント情報）＠デバイスＡをそのまま転送、若しくは、必要な情報（例えば、イベント情報）のみをＭＴＣサーバ１５０に送信する。なお、ここでは、ＭＴＣサーバ１５０が、イベント通知メッセージ（イベント情報）の通知先になっているが、通信システムのオペレータ、ＭＴＣサーバ１５０やＭＴＣユーザ１６０によって設定される仕様や登録情報、また設定情報などに基づいて、イベント通知メッセージ（イベント情報）の送信先を他のネットワーク装置（例えば、ＰＧＷ１４０）にしてもよい。なお、ステップＳ３４４のデバイスＡ管理処理からステップＳ３４６のイベント通知メッセージ（イベント情報）＠デバイスＡの転送処理は、順不同で実施してもよい。
続いて、ＭＴＣサーバ１５０は、受信したイベント通知メッセージ（イベント情報）からイベント情報を抽出し、逆イベント通知メッセージに格納する。そして、ＭＴＣサーバ１５０は、同一イベント（例えば、煙の発生）、若しくは、そのイベント（例えば、煙発生）を引き起こした出来事（例えば、火災発生）によって引き起こされたイベント（例えば、炎の発生）によるイベント通知メッセージの送信を抑制するために、逆イベント通知メッセージ（イベント情報）をＵプレーンを用いてＭＴＣグループに属するＭＴＣデバイス１００にブロードキャストする（ステップＳ３４７：逆イベント通知メッセージ（イベント情報））。ステップＳ３４８以降は、本発明の第２の実施の形態のステップＳ３０６以降と同様なので、ここでは説明を省略する。
本発明の第４の実施の形態のように、ＭＴＣデバイス１００が通知するイベント通知メッセージはＣプレーンで、ネットワーク装置（例えば、ＭＴＣサーバ１５０やＰＧＷ１４０）から送信される逆イベント通知メッセージはＵプレーンを用いることで、ＭＴＣサービスにおけるメッセージが基本的にＵプレーンを用いて送信されると設定されている環境において、ＭＴＣデバイス１００が、ＭＭＥ１２０経由（Ｃプレーン）でイベント通知メッセージを送信しなければいけない場合（例えば、ＭＭＥ１２０がイベント通知メッセージに格納されているイベント情報（例えば、デバイスＩＤ／デバイス種ＩＤ）やＭＴＣデバイス１００の位置情報を用いて、ＭＴＣデバイス１００の管理情報を更新しなければならない場合）に対応することができる。
＜第５の実施の形態＞
本発明の第５の実施の形態では、ＭＴＣデバイス１００が通知するイベント通知メッセージはＵプレーンで、ネットワーク装置（例えば、ＭＴＣサーバ１５０やＰＧＷ１４０）から送信される逆イベント通知メッセージも同様にＵプレーンが用いられる場合について説明する。すなわち、ＭＴＣデバイス１００から通知されるイベント通知メッセージ（イベント情報）とネットワーク装置（例えば、ＭＴＣサーバ１５０やＰＧＷ１４０）から送信される逆イベント通知メッセージ（イベント情報）が、共にＵプレーン上で交換される場合について説明する。例えば、通信システムのオペレータ、ＭＴＣサーバ１５０やＭＴＣユーザ１６０によって、静的、若しくは、動的に設定されるＭＴＣサービスの仕様や登録情報、また設定情報などに基づいて、ＭＴＣサービスにおける全てのメッセージがＵプレーンを用いて送信されると設定されている環境である。すなわち、ＭＴＣデバイスＡ１００Ａから通知されるイベント通知メッセージ（イベント情報）＠デバイスＡは、ｅＮＢ１１０、ＳＧＷ１３０、ＰＧＷ１４０、ＭＴＣサーバ１５０という順で転送され、ＭＴＣサーバ１５０から送信される逆イベント通知メッセージ（イベント情報）は、ＰＧＷ１４０、ＳＧＷ１３０、ｅＮＢ１１０、ＭＴＣデバイス１００という順で転送される。つまり、ＭＭＥ１２０は介さず、ＭＴＣサービスのメッセージが交換される。例えば、ＭＴＣサービスにおけるメッセージ（例えば、イベントを検知した情報や、センシングデータなど）は、ＭＴＣデバイス１００の位置情報などを更新するメッセージ（例えば、ＴＡＵ、ＲＡＵ、ページングなど）を除いて、全てアプリケーション情報と解釈し、ＭＴＣデバイス１００やＵＥ１０５のモビリティ制御やＰＤＮコネクション・ＥＰＳベアラを管理、ＱｏＳなどを管理するためのＣプレーンではなく、ユーザデータ（アプリケーション情報）を転送するＵプレーンでのみ交換しなくてはならないという環境が、本発明の第５の実施の形態に相当する。
本発明の第５の実施の形態では、ＭＴＣデバイス１００が通知するイベント通知メッセージはＵプレーンで、ネットワーク装置（例えば、ＭＴＣサーバ１５０やＰＧＷ１４０）から送信される逆イベント通知メッセージも同様にＵプレーンが用いられる場合について説明する。すなわち、ＭＴＣデバイス１００から通知されるイベント通知メッセージ（イベント情報）とネットワーク装置（例えば、ＭＴＣサーバ１５０やＰＧＷ１４０）から送信される逆イベント通知メッセージ（イベント情報）が、共にＵプレーン上で交換される場合について説明する。例えば、通信システムのオペレータ、ＭＴＣサーバ１５０やＭＴＣユーザ１６０によって、静的、若しくは、動的に設定されるＭＴＣサービスの仕様や登録情報、また設定情報などに基づいて、ＭＴＣサービスにおける全てのメッセージがＵプレーンを用いて送信されると設定されている環境である。すなわち、ＭＴＣデバイスＡ１００Ａから通知されるイベント通知メッセージ（イベント情報）＠デバイスＡは、ｅＮＢ１１０、ＳＧＷ１３０、ＰＧＷ１４０、ＭＴＣサーバ１５０という順で転送され、ＭＴＣサーバ１５０から送信される逆イベント通知メッセージ（イベント情報）は、ＰＧＷ１４０、ＳＧＷ１３０、ｅＮＢ１１０、ＭＴＣデバイス１００という順で転送される。つまり、ＭＭＥ１２０は介さず、ＭＴＣサービスのメッセージが交換される。例えば、ＭＴＣサービスにおけるメッセージ（例えば、イベントを検知した情報や、センシングデータなど）は、ＭＴＣデバイス１００の位置情報などを更新するメッセージ（例えば、ＴＡＵ、ＲＡＵ、ページングなど）を除いて、全てアプリケーション情報と解釈し、ＭＴＣデバイス１００やＵＥ１０５のモビリティ制御やＰＤＮコネクション・ＥＰＳベアラを管理、ＱｏＳなどを管理するためのＣプレーンではなく、ユーザデータ（アプリケーション情報）を転送するＵプレーンでのみ交換しなくてはならないという環境が、本発明の第５の実施の形態に相当する。
以下、本発明の第５の実施の形態におけるシステム動作の一例について、図１７を用いて詳しく説明する。図１７は、本発明の第６の実施の形態におけるシステム動作の一例（複数のＭＴＣデバイス１００から送信される同一イベント、又は、そのイベントを引き起こした出来事によって引き起こされたイベントによる優先度の高いイベント通知メッセージの送信抑制方法）を説明するためのシーケンス図である。なお、図１７には、図１に図示したシステム構成における処理シーケンスの一例を図示する。ここで、ＭＴＣデバイス１００の特徴は、本発明の第２の実施の形態における特徴と同様であり、ここでは説明を省略する。
以下、図１７に図示されているシーケンスについて説明する。ステップＳ３６１〜ステップＳ３６２は、本発明の第２の実施の形態におけるステップＳ３０１〜ステップＳ３０２と同様なので、ここでは説明を省略する。
続いて、ＭＴＣデバイスＡ１００Ａは、検知したイベント情報（例えば、煙センサＩＤ）を格納したイベント通知メッセージ（イベント情報）をＵプレーン上で、ＭＴＣサーバ１５０に通知する（ステップＳ３６３：イベント通知メッセージ（イベント情報）＠デバイスＡ）。すなわち、ＭＴＣデバイスＡ１００Ａから通知されるイベント通知メッセージ（イベント情報）＠デバイスＡは、ｅＮＢ１１０、ＳＧＷ１３０、ＰＧＷ１４０、ＭＴＣサーバ１５０という順で転送される。なお、ここでは、ＭＴＣサーバ１５０が、イベント通知メッセージ（イベント情報）の通知先になっているが、通信システムのオペレータ、ＭＴＣサーバ１５０やＭＴＣユーザ１６０によって設定される仕様や登録情報、また設定情報などに基づいて、イベント通知メッセージ（イベント情報）の送信先を他のネットワーク装置（例えば、ＰＧＷ１４０）にしてもよい。
続いて、ＭＴＣサーバ１５０は、受信したイベント通知メッセージ（イベント情報）のイベント情報（例えば、デバイスＩＤやデバイス種ＩＤ）を逆イベント通知メッセージに格納し、Ｕプレーンを用いてＭＴＣグループに属するＭＴＣデバイス１００にブロードキャストする（ステップＳ３６４：逆イベント通知メッセージ（イベント情報））。
続いて、ＭＴＣサーバ１５０は、同一イベント（例えば、煙の発生）、若しくは、そのイベント（例えば、煙発生）を引き起こした出来事（例えば、火災発生）によって引き起こされたイベント（例えば、炎の発生）によるイベント通知メッセージの送信を抑制するために、イベント通知メッセージ（イベント情報）＠デバイスＡに格納されているイベント情報（例えば、デバイスＩＤやデバイス種ＩＤ）を記憶する（ステップＳ３６５：イベント情報の記憶）。ステップＳ３６６以降は、本発明の第２の実施の形態のステップＳ３０６以降と同様なので、ここでは説明を省略する。
本発明の第５の実施の形態のように、ＭＴＣデバイス１００が通知するイベント通知メッセージとネットワーク装置（例えば、ＭＴＣサーバ１５０やＰＧＷ１４０）が送信する逆イベント通知メッセージが共にＵプレーンを用いることで、例えばＭＴＣサービスにおけるメッセージ（例えば、イベントを検知した情報や、センシングデータなど）は、ＭＴＣデバイス１００の位置情報などを更新するメッセージ（例えば、ＴＡＵ、ＲＡＵ、ページングなど）を除いて、全てアプリケーション情報と解釈し、ＭＴＣデバイス１００やＵＥ１０５のモビリティ制御やＰＤＮコネクション・ＥＰＳベアラを管理、ＱｏＳなどを管理するためのＣプレーンではなく、ユーザデータ（アプリケーション情報）を転送するＵプレーン上で交換しなくてはならないという環境に対応することができる。
＜第６の実施の形態＞
また、上記の各実施の形態では、ＰＧＷ１４０をデータゲートウェイとするＥＰＳ（Evolved Packet System）アーキテクチャを用いた例について説明したが、それ以外にも、例えばＧＰＲＳ（General Packet Radio Service）アーキテクチャや、ＵＭＴＳ（Universal Mobile Telecommunications System）アーキテクチャ、またそれらアーキテクチャが混在するような構成においても、同様に実施可能であることは当業者にとって明らかである。
また、上記の各実施の形態では、ＰＧＷ１４０をデータゲートウェイとするＥＰＳ（Evolved Packet System）アーキテクチャを用いた例について説明したが、それ以外にも、例えばＧＰＲＳ（General Packet Radio Service）アーキテクチャや、ＵＭＴＳ（Universal Mobile Telecommunications System）アーキテクチャ、またそれらアーキテクチャが混在するような構成においても、同様に実施可能であることは当業者にとって明らかである。
例えば、ＧＰＲＳアーキテクチャやＵＭＴＳアーキテクチャに基づく構成の場合、上述したようなＭＭＥ１２０とＳＧＷ１３０の役割をＳＧＳＮ（Serving GPRS Support Node）が担い、相当する処理を実施する。また、同様にＰＧＷ１４０の役割をＧＧＳＮ（Gateway GPRS Support Node）が担い、相当する処理を実施する。さらには、ＰＤＮコネクションと同等の論理通信路として、ＰＤＰコンテキストが用いられる。いくつかのメッセージについては、その表記やシグナリングの手順、またメッセージの順序などが若干異なる場合があるが、本発明による実施においては問題ではない。なお、その他の通信システム（例えば、ＷＬＡＮなどのローカル通信システムやＷｉＭＡＸなどの広域通信システム、３ＧＰＰ２などのセルラシステム、その他自営通信システムなど）においても同様に実施可能である。
＜第７の実施の形態＞
上記の実施の形態では、図１のＭＴＣ通信ネットワークの構成において、複数のＭＴＣデバイス１００が１つのＭＴＣグループとしてまとめられ、各ＭＴＣデバイスが３Ｇアクセス（例えば、Ｅ−ＵＴＲＡＮ１１５）への通信インタフェースを保持し、３Ｇアクセスを介して、ＭＴＣデバイス１００が検知したイベントや、センシングデータをＭＴＣサーバ１５０に送信するアーキテクチャを用いた例について説明した。しかし、それ以外にも、例えば、ＭＴＣデバイス１００と３Ｇアクセスとの間にＭＴＣデバイスゲートウェイを設け、ＭＴＣデバイスゲートウェイがＭＴＣデバイスから送信されたメッセージを転送するアーキテクチャにおいても実施可能であることが明らかである。本発明の第７の実施の形態におけるＭＴＣ通信ネットワークの構成の一例を図１８に示す。
上記の実施の形態では、図１のＭＴＣ通信ネットワークの構成において、複数のＭＴＣデバイス１００が１つのＭＴＣグループとしてまとめられ、各ＭＴＣデバイスが３Ｇアクセス（例えば、Ｅ−ＵＴＲＡＮ１１５）への通信インタフェースを保持し、３Ｇアクセスを介して、ＭＴＣデバイス１００が検知したイベントや、センシングデータをＭＴＣサーバ１５０に送信するアーキテクチャを用いた例について説明した。しかし、それ以外にも、例えば、ＭＴＣデバイス１００と３Ｇアクセスとの間にＭＴＣデバイスゲートウェイを設け、ＭＴＣデバイスゲートウェイがＭＴＣデバイスから送信されたメッセージを転送するアーキテクチャにおいても実施可能であることが明らかである。本発明の第７の実施の形態におけるＭＴＣ通信ネットワークの構成の一例を図１８に示す。
図１８において、図１と異なる点は、ＭＴＣデバイス１００とｅＮＢ１１０（３Ｇアクセス）との間にＭＴＣデバイスゲートウェイ１０２が存在することである。
図１８において、ＭＴＣデバイスゲートウェイ１０２は、３Ｇアクセス１１５と通信するための通信インタフェースを１つ以上持つ。さらに、ＭＴＣデバイスゲートウェイ１０２は、複数のＭＴＣデバイス１００と通信するための通信インタフェース（例えば、通信バスを設け、そのバスへの通信インタフェースや、有線ＬＡＮのような通信インタフェースや、Ｚｉｇｂｅｅ（ジグビー）（登録商標）や無線ＬＡＮなどの無線通信プロトコル）を持つ。
一方、ＭＴＣデバイス１００は、上記の各実施の形態のＭＴＣデバイス１００とは異なり、３Ｇアクセスへの通信インタフェースを持っていなくてもよい。すなわち、ＭＴＣデバイス１００は、検知したイベント情報やセンシングデータを直接３Ｇアクセス経由でＭＴＣサーバ１５０に送信することができなくてもよい。その代わり、ＭＴＣデバイス１００が検知したイベント情報やセンシングデータは、ＭＴＣデバイスゲートウェイ１０２に送信することで、ＭＴＣデバイスゲートウェイ１０２が３Ｇアクセスを経由して、ネットワーク装置（例えば、ＭＭＥ１２０、ＰＧＷ１４０やＭＴＣサーバ１５０）に転送する。このように、ＭＴＣデバイスゲートウェイ１０２が、ＭＴＣデバイス１００が取得したデータをまとめて送信することで、通信システムのオペレータ、ＭＴＣサーバ１５０やＭＴＣユーザ１６０は、個別にＭＴＣデバイス１００を管理する必要がなくなり、処理負荷とリソースが軽減される。また、３Ｇアクセスに通信する装置をＭＴＣデバイスゲートウェイ１０２にまとめることで、例えば、全ＭＴＣデバイス１００に高価な３Ｇアクセスへの通信インタフェースを搭載する必要がなくなり、コスト削減を図ることもできる。なお、本発明の第６の実施の形態は、マンションやビル、集合住宅などを監視するシステムを管理する業者において、現実的な実施の形態と言える。
また、第１の実施の形態で説明したように、少なくともＭＴＣデバイスゲートウェイ１０２が複数のＭＴＣデバイス１００から送信されたデータの優先度レベルを確認することができ、ネットワーク側で混雑状態が起こっているとき（例えば、ｅＮＢ１１０、ＭＭＥ１２０やＰＧＷ１４０がオーバーフロー）や、ＭＴＣユーザ１６０が通信システムオペレータと特別な契約（例えば、高額な利用料金の課金ルールを結ぶことで、優先的なデータ転送がされる契約）を保持するとき、又は、オペレータ方針によって一定の優先度レベルを用いたデータ転送の指示が配布されたとき（例えば、優先度レベル３以上はデータ転送可のとき）には、ＭＴＣデバイスゲートウェイ１０２が優先度レベルを確認しながら（例えば、ネットワーク側が示す許容優先度レベルとＭＴＣデバイス１００から転送されるデータに格納された優先度レベルを比較する。または、ＭＴＣデバイス１００やＭＴＣデバイスゲートウェイ１０２にあらかじめ組み込まれているコンテキスト（例えば、混雑度レベル３のときは優先度レベル３以上のメッセージのみ送信許容などのルールが登録されているコンテキスト）やアプリケーションデータに含まれている優先度レベルを確認する）、転送データの選択をすることで、優先度レベルが高いデータのみネットワーク側へ転送することができる（優先度の低いデータの転送は後回し（例えば、混雑状態の解消後）にすることができる）。これにより、ネットワーク側の混雑状態が起こっている場合でも、ＭＴＣユーザ１６０やＭＴＣサーバ１５０は、優先的に収集しているデータを受信することができる。
また、ＭＴＣデバイス１００がＭＴＣデバイスゲートウェイ１０２の役割を担うことも可能である。この場合、ＭＴＣデバイスゲートウェイ１０２となるＭＴＣデバイス１００の負荷が増えることが予想され、負荷を分散する手段が必要となり得る。例えば、ＭＴＣデバイスゲートウェイ１０２の役割を、ＭＴＣグループの各ＭＴＣデバイス１００で順番に（例えば、時間で区切って）担当していくなどして負荷分散することが可能である。
＜第８の実施の形態＞
上記の実施の形態では、ネットワーク側で混雑状態になる前にネットワーク側の装置（例えば、ｅＮＢ１１０、ＭＭＥ１２０や、ＳＧＷ１３０、ＰＧＷ１４０、ＭＴＣサーバ１５０）から逆イベント通知メッセージが通知され、ＭＴＣデバイス１００から送信される冗長なイベント通知メッセージの送信を抑制し、ネットワーク側の混雑状態を回避していた。しかし、既にネットワーク側で混雑状態が起こっているとき、若しくは、あるメッセージ（例えば、ＰＤＮコネクション確立リクエストや、転送データ）を受信した時点で混雑状態が起こり始めたときに、ＵＥ１０５などから優先度の高い緊急メッセージ（Ｅｍｅｒｇｅｎｃｙ ｒｅｑｕｅｓｔや、Ｅｍｅｒｇｅｎｃｙ ｍｅｓｓａｇｅとも呼ばれる）やデータ（アプリケーションメッセージ）、ＰＤＮコネクション確立リクエストが送られてきた場合、更なるリソース（Ｕ−ｐｌａｎｅ（Ｕプレーン）、Ｃ−ｐｌａｎｅ（Ｃプレーン）共）が必要となる。例えば、通信システムのエンティティ（例えば、ｅＮＢ１１０やＭＭＥ１２０、ＳＧＷ１３０、ＰＧＷ１４０）における処理能力のリソース（例えば、データ転送における処理）や、ＭＴＣデバイス１００やＵＥ１０５に割り当てる通信リソースや帯域リソースなどがある。このような課題も解決するために、既に確立済みであるＰＤＮコネクションをＵＥ１０５やＭＴＣデバイス１００、ネットワーク側のエンティティ（例えば、ｅＮＢ１１０やＭＭＥ１２０、ＳＧＷ１３０、ＰＧＷ１４０、ＭＴＣサーバ１５０）が保持する優先度レベル（例えば、ＵＥ１０５やＭＴＣデバイス１００に割り当てられる優先度レベルや、送信するデータの優先度レベルや、ＱＣＩやＡＲＰ）を用いて選択的に切断すること、あるいは、新規ＰＤＮコネクションの確立を制御することで優先度レベルの高いリクエストやメッセージ、アプリケーションのためのリソースを確保する。なお、この本発明の第８の実施の形態は、ＭＴＣデバイス１００やＵＥ１０５が多く存在するエリアで起こり得る現実的な実施の形態である。
上記の実施の形態では、ネットワーク側で混雑状態になる前にネットワーク側の装置（例えば、ｅＮＢ１１０、ＭＭＥ１２０や、ＳＧＷ１３０、ＰＧＷ１４０、ＭＴＣサーバ１５０）から逆イベント通知メッセージが通知され、ＭＴＣデバイス１００から送信される冗長なイベント通知メッセージの送信を抑制し、ネットワーク側の混雑状態を回避していた。しかし、既にネットワーク側で混雑状態が起こっているとき、若しくは、あるメッセージ（例えば、ＰＤＮコネクション確立リクエストや、転送データ）を受信した時点で混雑状態が起こり始めたときに、ＵＥ１０５などから優先度の高い緊急メッセージ（Ｅｍｅｒｇｅｎｃｙ ｒｅｑｕｅｓｔや、Ｅｍｅｒｇｅｎｃｙ ｍｅｓｓａｇｅとも呼ばれる）やデータ（アプリケーションメッセージ）、ＰＤＮコネクション確立リクエストが送られてきた場合、更なるリソース（Ｕ−ｐｌａｎｅ（Ｕプレーン）、Ｃ−ｐｌａｎｅ（Ｃプレーン）共）が必要となる。例えば、通信システムのエンティティ（例えば、ｅＮＢ１１０やＭＭＥ１２０、ＳＧＷ１３０、ＰＧＷ１４０）における処理能力のリソース（例えば、データ転送における処理）や、ＭＴＣデバイス１００やＵＥ１０５に割り当てる通信リソースや帯域リソースなどがある。このような課題も解決するために、既に確立済みであるＰＤＮコネクションをＵＥ１０５やＭＴＣデバイス１００、ネットワーク側のエンティティ（例えば、ｅＮＢ１１０やＭＭＥ１２０、ＳＧＷ１３０、ＰＧＷ１４０、ＭＴＣサーバ１５０）が保持する優先度レベル（例えば、ＵＥ１０５やＭＴＣデバイス１００に割り当てられる優先度レベルや、送信するデータの優先度レベルや、ＱＣＩやＡＲＰ）を用いて選択的に切断すること、あるいは、新規ＰＤＮコネクションの確立を制御することで優先度レベルの高いリクエストやメッセージ、アプリケーションのためのリソースを確保する。なお、この本発明の第８の実施の形態は、ＭＴＣデバイス１００やＵＥ１０５が多く存在するエリアで起こり得る現実的な実施の形態である。
以下、本発明の第８の実施の形態について、図１９〜２４を用いて説明する。
ここで、本発明の第８の実施の形態の説明を容易化するために、図１９と図２０におけるＭＴＣデバイスＢとＭＴＣデバイスＤとＭＴＣデバイスＥとＭＴＣデバイスＦは、非特許文献１で定義されている“Ｔｉｍｅ ｔｏｌｅｒａｎｔ（タイムトレラント）”（耐時間性）を有していることを前提とする。
この“Ｔｉｍｅ ｔｏｌｅｒａｎｔ”の機能を保持しているＭＴＣデバイス１００は、ネットワークが混雑状態の場合やオペレータ方針などによって、メッセージ（例えば、ＰＤＮコネクション確立リクエストやデータ転送）の送信タイミングを遅らせることができる。この“Ｔｉｍｅ ｔｏｌｅｒａｎｔ”の動作について、図１９を用いて説明する。図１９は、ＭＴＣデバイスＡとＭＴＣデバイスＢとＭＴＣデバイスＣが既にＰＤＮコネクションを確立済みで各ＭＴＣデバイス１００から３Ｇアクセス側にデータ転送をしており（図１９の（Ａ）データ転送）、ＭＴＣデバイスＤとＭＴＣデバイスＥとＭＴＣデバイスＦが順次的に、これからＰＤＮコネクションを確立し、３Ｇアクセス側にデータ転送を行おうとしている状態である（ＭＴＣデバイスＡ〜ＣはＣｏｎｎｅｃｔｅｄ ｍｏｄｅであり、ＭＴＣデバイスＤ〜Ｆは順次的にＩＤＬＥ ｍｏｄｅからＣｏｎｎｅｃｔｅｄ ｍｏｄｅになろうとしている状態）。このとき、ＭＴＣデバイスＤがＰＤＮコネクションを確立しようとした際に、３Ｇアクセス側で混雑状態が発生してしまうとする（例えば、３Ｇアクセス側で許容できるトラフィック量を超えてしまう）（図１９の（Ｆ）混雑発生）。この場合、３Ｇアクセス側は、ＭＴＣデバイスＤのＰＤＮコネクションの確立を拒絶することを示すＰＤＮコネクション確立拒絶メッセージをＭＴＣデバイスＤに返信した後に、３Ｇアクセス側で混雑状態になっていることを通知するメッセージ（図１９の（Ｂ）送信制御メッセージ）を対象となるＭＴＣデバイス１００（本発明の第８の実施の形態では、ＭＴＣデバイスＡ〜Ｆである。実環境では、例えば、特定のＡＰＮに接続しているＭＴＣデバイス１００、特定のＭＴＣグループに属しているＭＴＣデバイス１００、特定のオペレータに属しているＭＴＣデバイス１００、特定のエリア（例えば、特定のｅＮＢ１１０やＭＭＥ１２０に接続しているＭＴＣデバイス）など）にブロードキャスト送信する。なお、ネットワークが混雑状態を認識するタイミングは、上記のようにＭＴＣデバイスＤのＰＤＮコネクション確立要求を受けた際に限定されず、既にＰＤＮコネクションを確立しているＭＴＣデバイスによって送信されたデータによって輻輳が発生した、あるいは発生しそうである場合に、送信制御メッセージを対象となるＭＴＣデバイスが属するエリアへブロードキャスト送信する。なお、（Ｂ）送信制御メッセージには、例えば、ＭＴＣデバイス１００から送信されるメッセージ（例えば、ＰＤＮコネクション確立リクエスト）をどのくらい遅らせるかを示す値（例えば、待機時間）が格納されていることとする（図１９の（Ｃ）待機時間）。待機時間が格納された（Ｂ）送信制御メッセージを受信したＭＴＣデバイス１００は、“Ｔｉｍｅ ｔｏｌｅｒａｎｔ”の機能を保持しているか確認する。
“Ｔｉｍｅ ｔｏｌｅｒａｎｔ”の機能を保持しているＭＴＣデバイス１００は、（Ｂ）送信制御メッセージを受信した後、３Ｇアクセスから示された値（例えば、待機時間）に基づいて、送信メッセージのタイミングを遅らせることができる（例えば、図１９の（Ｄ）から（Ｅ））。なお、ここでは３Ｇアクセスから示された値（待機時間）に基づいて送信メッセージのタイミングを遅らせているが、例えばＭＴＣデバイスが値（待機時間）を計算してもよく、また、ＭＴＣサーバ１５０などの外部サーバに値（待機時間）を問い合わせてもよい。
“Ｔｉｍｅ ｔｏｌｅｒａｎｔ”の機能を保持しているＭＴＣデバイス１００は、（Ｂ）送信制御メッセージを受信した後、３Ｇアクセスから示された値（例えば、待機時間）に基づいて、送信メッセージのタイミングを遅らせることができる（例えば、図１９の（Ｄ）から（Ｅ））。なお、ここでは３Ｇアクセスから示された値（待機時間）に基づいて送信メッセージのタイミングを遅らせているが、例えばＭＴＣデバイスが値（待機時間）を計算してもよく、また、ＭＴＣサーバ１５０などの外部サーバに値（待機時間）を問い合わせてもよい。
“Ｔｉｍｅ ｔｏｌｅｒａｎｔ”の機能を保持していないＭＴＣデバイス１００やＵＥ１０５が（Ｂ）送信制御メッセージを受信した場合は、送信メッセージのタイミングを遅らせることができないため、（Ｃ）待機時間の間にメッセージ（例えば、ＰＤＮコネクション確立リクエストやアプリケーションデータ、Ｅｍｅｒｇｅｎｃｙ ｒｅｑｕｅｓｔや、Ｅｍｅｒｇｅｎｃｙ ｍｅｓｓａｇｅ）を送信する。“Ｔｉｍｅ ｔｏｌｅｒａｎｔ”を保持していないＭＴＣデバイス１００やＵＥ１０５が送信するメッセージは、（Ｃ）待機時間の後に再送信することができない（送信メッセージのタイミングを遅らせることができない）ため、優先度レベルが高いＭＴＣデバイス１００やＵＥ１０５から送信されるメッセージとして送信できるようにする。この優先度レベルが高いＭＴＣデバイス１００やＵＥ１０５から送信されるメッセージをネットワーク側が受け入れられるようにするために、送信メッセージのタイミングを遅らせることができる（優先度レベルが低い）ＭＴＣデバイス１００（“Ｔｉｍｅ ｔｏｌｅｒａｎｔ”の機能を保持するＭＴＣデバイス１００）によって確立されたＰＤＮコネクションを切断する（（Ｃ）待機時間の後にメッセージを送信させる）ことで、リソース（Ｃ−ｐｌａｎｅ、Ｕ−ｐｌａｎｅ共）を確保する。
“Ｔｉｍｅ ｔｏｌｅｒａｎｔ”の機能を保持していないＭＴＣデバイス１００とＵＥ１０５が（Ｂ）送信制御メッセージを受信した際、一定の期間（例えば、（Ｂ）送信制御メッセージに格納されている値（待機時間）ではなく、ＭＴＣデバイス１００やＵＥ１０５にあらかじめ組み込まれている待機時間（固定値））を待機することができる場合、“Ｔｉｍｅ ｔｏｌｅｒａｎｔ”の機能を保持しているＭＴＣデバイス１００は、“Ｔｉｍｅ ｔｏｌｅｒａｎｔ”の機能を保持していないＭＴＣデバイス１００より長い時間、メッセージの送信を遅らせることができるものとする。
以下、本発明の第８の実施の形態におけるシステム動作の一例について、図２０を用いて詳しく説明する。図２０は、本発明の第８の実施の形態におけるシステム動作の一例（既に確立済みであるＰＤＮコネクションをＵＥ１０５やＭＴＣデバイス１００、ネットワーク側のエンティティ（例えば、ｅＮＢ１１０やＭＭＥ１２０、ＳＧＷ１３０、ＰＧＷ１４０、ＭＴＣサーバ１５０）が保持する優先度レベル（例えば、ＵＥ１０５やＭＴＣデバイス１００に割り当てられる優先度レベルや、送信するデータの優先度レベルや、ＱＣＩやＡＲＰ）を用いて切断することで優先度レベルの高いリクエストやアプリケーションのためのリソース確保方法）を説明するためのシーケンスチャートである。なお、図２０には、図１に図示したシステム構成における処理シーケンスの一例を図示する。
ＭＴＣデバイスＡ１００ＡとＭＴＣデバイスＢ１００ＢとＭＴＣデバイスＣ１００Ｃは、既にＰＤＮコネクションを確立済みであり、データ転送を行っていることとする（図２０のステップＳ１００１Ａ、Ｓ１００１Ｂ、Ｓ１００１Ｃ：ＰＤＮコネクション確立済み）。続いて、ＭＴＣデバイスＤ１００Ｄがデータ転送をするためにＰＤＮコネクション確立リクエストをＭＭＥ１２０に送信する（図２０のステップＳ１００２：ＰＤＮコネクション確立リクエスト）。
ＰＤＮコネクション確立リクエストを受け、ネットワーク側のエンティティ（例えば、ｅＮＢ１１０やＭＭＥ１２０など）が、例えば処理能力の許容レベル（閾値）を上回ったかどうか確認することによって、混雑状態を検出する（リソースの確保が必要であることを検出する）（図２０のステップＳ１００３：混雑検出）。ここでは、ＭＴＣデバイスＤ１００Ｄから送信されたＰＤＮコネクション確立リクエストを受信することでネットワーク側のエンティティ（例えば、ｅＮＢ１１０やＭＭＥ１２０など）が混雑状態を検出しているが、データ転送をしているＭＴＣデバイス１００（本発明の第８の実施の形態では、ＭＴＣデバイスＡ〜Ｃ）によって送信されるデータサイズ（送信されているデータの総量）の増加などによって、ネットワーク側のエンティティが混雑状態を検出してもよい。
また、本実施の形態の説明を容易化するために、ＭＭＥ１２０が混雑状態を検出しているが、他のエンティティ（例えば、ｅＮＢ１１０やＳＧＷ１３０、ＰＧＷ１４０、ＭＴＣサーバ１５０）が混雑状態を検出してもよい。その場合、各エンティティがＭＴＣデバイスＤ１００Ｄに混雑状態が起こっていることを直接通知してもよいし、ＭＭＥ１２０やｅＮＢ１１０などに通知することで、間接的に通知してもよい（例えば、ＰＧＷ１４０が混雑状態を検出し次第、ＭＭＥ１２０に混雑状態を通知し、ＭＭＥ１２０はＭＴＣデバイスＤ１００ＤからＰＤＮコネクション確立リクエストが送信されてきた際に、混雑状態をＭＴＣデバイス１００に通知してもよい）。
混雑状態を検出したＭＭＥ１２０は、ＰＤＮコネクションを確立できないことを通知するためにＰＤＮコネクション確立リクエスト拒絶メッセージをＭＴＣデバイスＤ１００Ｄに送信する（図２０のステップＳ１００４：ＰＤＮコネクション確立リクエスト拒絶）。続いて、ｅＮＢ１１０は、対象となるＭＴＣデバイス１００（例えば、特定のＡＰＮに接続しているＭＴＣデバイス、特定のＭＴＣグループに属しているＭＴＣデバイス、特定のオペレータに属しているＭＴＣデバイス、特定のエリア（例えば、特定のｅＮＢ１１０やＭＭＥ１２０に接続しているＭＴＣデバイス）など）に送信制御メッセージをブロードキャストする（図２０のステップＳ１００５、Ｓ１００６：送信制御メッセージ）。対象となるＭＴＣデバイス１００の決定は、例えば、ステップＳ１００５のブロードキャストメッセージ指示でＭＭＥ１２０がｅＮＢ１１０に指示してもよい。このとき、ＭＭＥ１２０はｅＮＢ１１０やＳＧＷ１３０、ＰＧＷ１４０、ＭＴＣサーバ１５０に指示を問い合わせてもよい。
なお、ｅＮＢ１１０が対象となるＭＴＣデバイス１００にブロードキャスト送信する際、従来技術であるページングメッセージ（Ｐａｇｉｎｇ）やＭＢＭＳ（Ｍｕｌｔｉｍｅｄｉａ Ｂｒｏａｄｃａｓｔ Ａｎｄ Ｍｕｌｔｉｃａｓｔ Ｓｅｒｖｉｃｅ）を用いてよい。また、ここでは、本実施の形態の説明を容易化するために、ＭＭＥ１２０がｅＮＢ１１０にブロードキャストメッセージを指示し、ｅＮＢ１１０が対象デバイスにブロードキャストしているが、他のエンティティがブロードキャストメッセージを指示し、ブロードキャスト送信してもよい（例えば、ＰＧＷ１４０がｅＮＢ１１０にブロードキャストメッセージ指示し、ｅＮＢ１１０がブロードキャスト送信）。
また、ＭＭＥ１２０によるメッセージの送信処理（ステップＳ１００４とステップＳ１００５）の順序は、入れ替わってもよい。さらに、ステップＳ１００５において送信制御メッセージをブロードキャストすることで、ＭＴＣデバイスＤ１００ＤのＰＤＮコネクション確立リクエストの拒絶を通知することができるのであれば、ステップＳ１００４を省略してもよい。
送信制御メッセージを受信したＭＴＣデバイス１００は、“Ｔｉｍｅ ｔｏｌｅｒａｎｔ”の機能を保持しているか確認する。ＭＴＣデバイス１００が、“Ｔｉｍｅ ｔｏｌｅｒａｎｔ”の機能を保持している場合、ＰＤＮコネクション確立リクエストを送信するタイミングを送信制御メッセージに格納されている待機時間に基づいて遅らせる。“Ｔｉｍｅ ｔｏｌｅｒａｎｔ”の機能を保持していないＭＴＣデバイス１００は、送信メッセージのタイミングを遅らせることができないので、ネットワーク側で混雑状態が起こっている場合でもＰＤＮコネクション確立リクエストを送信する。
このように、ＭＴＣデバイス１００からのＰＤＮコネクション確立リクエストの送信を回避することで、通信システムの処理負荷が軽減され、Ｃ−ｐｌａｎｅのリソースは確保できる。しかしながら、既にＰＤＮコネクションを確立しているＭＴＣデバイス（ＭＴＣデバイスＡ１００Ａ〜ＭＴＣデバイスＣ１００Ｃ）のデータ転送が完了するまで、Ｕ−ｐｌａｎｅのリソースに空きは生じない。さらに、上記したようにＵＥ１０５などから優先度の高い緊急メッセージ（Ｅｍｅｒｇｅｎｃｙ ｒｅｑｕｅｓｔや、Ｅｍｅｒｇｅｎｃｙ ｍｅｓｓａｇｅとも呼ばれる）やアプリケーションメッセージが送られてくることで、優先度レベルの高いＵＥ１０５やＭＴＣデバイス１００用の更なるリソース（Ｕ−ｐｌａｎｅ、Ｃ−ｐｌａｎｅ共）が必要となることがある。
そこで、ＭＴＣデバイス１００の優先度レベルを用いて、既に確立済みであるＰＤＮコネクションを選択的に切断することで優先度レベルの高いＰＤＮコネクション確立リクエストやアプリケーションデータの転送のためのＵ−ｐｌａｎｅのリソースを確保する。この優先度レベルを判別するためにも、例えば、“Ｔｉｍｅ ｔｏｌｅｒａｎｔ”の機能を保持しているＭＴＣデバイス１００であるかどうかをＭＴＣデバイス１００に確認させる。
そこで、ｅＮＢ１１０がブロードキャスト送信する送信制御メッセージに「“Ｔｉｍｅ ｔｏｌｅｒａｎｔ”の機能を保持するＭＴＣデバイス１００は確立済みＰＤＮコネクションを切断する」よう 指示するパラメータを格納する。“Ｔｉｍｅ ｔｏｌｅｒａｎｔ”の機能を保持するＭＴＣデバイス１００は、例えば、ｅＮＢ１１０からブロードキャスト送信される送信制御メッセージの受信後、確立済みのＰＤＮコネクションを切断する。また、ＭＴＣデバイス１００は、送信制御メッセージから一定時間（例えば、３Ｇアクセスから示された値（例えば、待機時間））経過後、再度ＰＤＮコネクションを確立し、データ転送を行ってもよい。
図２１は、図２０のステップＳ１００６において、ｅＮＢ１１０が対象となるＭＴＣデバイス１００にブロードキャスト送信する送信制御メッセージであり、「“Ｔｉｍｅ ｔｏｌｅｒａｎｔ”の機能を保持するＭＴＣデバイス１００は確立済みＰＤＮコネクションを切断する」よう 指示するパラメータと、「更に付加される詳細な条件」を示したパラメータが格納されるメッセージ構成の一例として、送信制御メッセージのフォーマット例を示す図である。
図２１は、ブロードキャスト送信するために必要となるヘッダフィールドと「“Ｔｉｍｅ ｔｏｌｅｒａｎｔ”の機能を保持するＭＴＣデバイス１００は確立済みＰＤＮコネクションを切断する」ことを示したＴｉｍｅ ｔｏｌｅｒａｎｔフィールドとさらに詳細な情報を用いてＰＤＮコネクションの維持／切断を判断する際に用いる詳細な条件（詳細データ）が格納される詳細データフィールドで構成される。詳細データフィールドには、従来技術のＡＰＮや位置情報（例えば、ｅＮＢ ＩＤやｅＮＢアドレス）、ＭＴＣグループを識別するグループＩＤ、接続しているネットワークオペレータを識別するＰＬＭＮ ＩＤに加えて、確立済みのＰＤＮコネクションを用いて転送するデータのデータ残量（データ残量値）や予想完了時間（予想完了時刻）、残時間、ＰＤＮコネクション（ＥＰＳベアラ）のＱＣＩ（QoS Class Indicator）やＡＲＰ（Allocation and Retention Priority）、データ転送を開始した時刻（以降、“Ｂｅｆｏｒｅ ｔｉｍｅ”とも呼ぶ）、ＭＴＣ ｆｅａｔｕｒｅ（例えば、非特許文献１で定義されている着信しかできない“Ｍｏｂｉｌｅ ｏｒｉｇｉｎａｔｅｄ ｏｎｌｙ”の機能を保持しているＭＴＣデバイス１００）などを格納することができる。ＭＴＣデバイス１００は、確立済みのＰＤＮコネクションを維持／切断する判断条件として、ＭＴＣデバイス１００が“Ｔｉｍｅ ｔｏｌｅｒａｎｔ”の機能を保持しているかに加えて、詳細データフィールドに格納されている詳細な判断条件を用いることができる。つまり、この詳細データフィールドを用いることで、論理演算を用いて説明すると「“Ｔｉｍｅ ｔｏｌｅｒａｎｔ”の機能を保持しているＭＴＣデバイス１００」ＡＮＤ「詳細データ」や、「“Ｔｉｍｅ ｔｏｌｅｒａｎｔ”の機能を保持しているＭＴＣデバイス１００」ＯＲ「詳細データ」や、「“Ｔｉｍｅ ｔｏｌｅｒａｎｔ”の機能を保持しているＭＴＣデバイス１００」ＥＸＯＲ「詳細データ」の結果で、確立済みのＰＤＮコネクションの維持／切断を決定することができる。なお、ＭＴＣデバイス１００やＵＥ１０５、通信システムのエンティティが、優先度レベルの低いＭＴＣデバイス１００、又は、アプリケーションであることを示すパラメータ（例えば、“Ｌｏｗ ｐｒｉｏｒｉｔｙ ｉｎｄｉｃａｔｏｒ”）を認識できる場合は、「“Low priority”の機能を保持するＭＴＣデバイス１００は確立済みＰＤＮコネクションを切断する」ことを示したパラメータと置き換えてもよい（代わりに使用してもよい）。
例えば、「“Ｔｉｍｅ ｔｏｌｅｒａｎｔ”の機能を保持しているＭＴＣデバイス１００」であり、「“Ｍｏｂｉｌｅ ｏｒｉｇｉｎａｔｅｄ ｏｎｌｙ”の機能を保持しているＭＴＣデバイス１００」によって確立されたＰＤＮコネクションのみ切断する。または、「“Ｔｉｍｅ ｔｏｌｅｒａｎｔ”の機能を保持しているＭＴＣデバイス１００」、もしくは、「“Ｍｏｂｉｌｅ ｏｒｉｇｉｎａｔｅｄ ｏｎｌｙ”の機能を保持しているＭＴＣデバイス１００」によって確立されたＰＤＮコネクションは切断する。または、「“Ｔｉｍｅ ｔｏｌｅｒａｎｔ”の機能を保持しているＭＴＣデバイス１００」であり、「“Ｍｏｂｉｌｅ ｏｒｉｇｉｎａｔｅｄ ｏｎｌｙ”の機能を保持しているＭＴＣデバイス１００」によって確立されたＰＤＮコネクションと、「“Ｔｉｍｅ ｔｏｌｅｒａｎｔ”の機能を保持しているＭＴＣデバイス１００」と「“Ｍｏｂｉｌｅ ｏｒｉｇｉｎａｔｅｄ ｏｎｌｙ”の機能を保持しているＭＴＣデバイス１００」でもないＭＴＣデバイス１００によって確立されたＰＤＮコネクションは切断するというように定義してもよい。
また、例えば詳細データフィールドにＢｅｆｏｒｅ ｔｉｍｅを格納することで、“Ｔｉｍｅ ｔｏｌｅｒａｎｔ”の機能を保持しているＭＴＣデバイス１００であり、Ｂｅｆｏｒｅ ｔｉｍｅで示された値（時刻）以降にＰＤＮコネクションを確立、若しくは、データ送信を開始したＭＴＣデバイス１００である場合、確立済みのＰＤＮコネクションを切断すると定義してもよい。このとき、Ｂｅｆｏｒｅ ｔｉｍｅは、例えば「ＡＭ１１：００」のように値（時刻）を示してもよい。また、Ｂｅｆｏｒｅ ｔｉｍｅは、「Ｂｅｆｏｒｅ ｔｉｍｅで示された値（時刻）以内にＰＤＮコネクションを確立したＭＴＣデバイス、若しくは、データ転送を開始してから経過した時間」のように指示することもでき、その場合は、例えば「１分」のように値（時刻）を示してもよい。
また、例えば詳細データフィールドに転送するデータのデータ残量（データ残量値）を格納することで、“Ｔｉｍｅ ｔｏｌｅｒａｎｔ”の機能を保持しているＭＴＣデバイス１００であり、ＭＴＣデバイス１００によって送信されるデータの残量がネットワーク側から指示されたデータ残量値を超えてしまっている場合は、確立済みのＰＤＮコネクションを切断すると定義してもよい。このとき、データ残量値は、例えば「１Ｍ Ｂｙｔｅｓ」のように値を示してもよい。
また、例えば詳細データフィールドに予想完了時間（残時間）を格納することで、“Ｔｉｍｅ ｔｏｌｅｒａｎｔ”の機能を保持しているＭＴＣデバイス１００であり、ＭＴＣデバイス１００が予想するデータ送信の予想完了時間（残時間）がｅＮＢ１１０からブロードキャスト送信された送信制御メッセージに格納されている予想完了時間（残時間）を超えてしまっている場合は、確立済みのＰＤＮコネクションを切断すると定義してもよい。このとき、予想完了時間は、例えば「ＡＭ１１：１５」、残時間は「１分」のように値を示してもよい。また、この予想完了時間や残時間は、例えば、データダウンロード完了までの時間を表わすアプリケーションなどから取得できる情報を利用してもよい。
また、例えば詳細データフィールドにＱＣＩやＡＲＰを格納することで、“Ｔｉｍｅ ｔｏｌｅｒａｎｔ”の機能を保持しているＭＴＣデバイス１００であり、現在送信しているデータで用いているＰＤＮコネクションやＥＰＳベアラのＱＣＩやＡＲＰが、詳細データフィールドで示された値以下である場合、該当するＰＤＮコネクションを切断するというように定義してもよい。通信システムのエンティティ（例えば、ｅＮＢ１１０やＭＭＥ１２０、ＳＧＷ１３０、ＰＧＷ１４０）やＭＴＣサーバ１５０が詳細データフィールドに格納するＱＣＩやＡＲＰは、例えばＳｕｂｓｃｒｉｐｔｉｏｎ ｄａｔａやＭＴＣデバイス１００の情報が登録されているコンテキスト、課金ルールなどを管理しているＰＣＲＦ（Policy and Charging Rules Function、図１には不図示）から取得したデータなどを用いて決定してもよい。例えば、ＭＭＥ１２０がＨＳＳ１２５から送信制御メッセージの送信対象先であるＭＴＣデバイス１００のＳｕｂｓｃｒｉｐｔｉｏｎ ｄａｔａを取得し、確立されているＰＤＮコネクションの平均ＱＣＩやＡＲＰを導き出し、現在の混雑状態と照らし合わせて、詳細データフィールドに格納するＱＣＩやＡＲＰを決定してもよい。
ＭＴＣデバイス１００は、上記したような詳細データフィールドに格納されているＰＤＮコネクションを切断するための詳細な判断条件を用いるために、例えば、Ｂｅｆｏｒｅ ｔｉｍｅが格納される場合は、Ｂｅｆｏｒｅ ｔｉｍｅを用いるためにＭＴＣデバイス１００はデータ転送を開始した時刻や、ＰＤＮコネクションを確立した時刻を記憶、若しくは、その時点からタイマーを起動し、ｅＮＢ１１０からブロードキャスト送信された送信制御メッセージを受信するまでの時間を計測してもよい。
また、詳細データフィールドにデータ残量（データ残量値）が格納される場合は、ＭＴＣデバイス１００は、現在送信しているデータの残りを把握しておく必要がある。例えば、ＭＴＣデバイス１００は送信予定のデータ総量（例えば、５０Ｍ Ｂｙｔｅｓ）と送信済みデータ量を記憶しておくことで、データ残量を計算してもよい。
また、詳細データフィールドに予想完了時間（あるいは、予想完了時刻）や残時間が格納される場合は、ＭＴＣデバイス１００は、現在送信しているデータの予想完了時間や、送信完了するまでに要する時間を把握しておく必要がある。例えば、ＭＴＣデバイス１００は送信予定のデータ量（例えば、５０Ｍ Ｂｙｔｅｓ）と送信レート（例えば、１Ｍｂｐｓ）と送信済みデータ量（例えば、４０Ｍ Ｂｙｔｅｓ）を把握しておき、データ転送の予想完了時間（現時刻がＡＭ１１：００とすると、データ転送の予想完了時刻（５０Ｍ Ｂｙｔｅｓ―４０Ｍ Ｂｙｔｅｓ）×８ｂｉｔｓ÷１Ｍｂｐs＝８０秒なので、ＡＭ１１：０１ ２０秒）や残時間（８０秒）を見積もってもよい。上記式は、単純に計算した式の例であり、実環境におけるパケットロス率などを考慮した式を用いてもよい。また、このような予想完了時間や残時間は、起動しているアプリケーションから取得してもよい。
また、詳細データフィールドにＱＣＩやＡＲＰが格納される場合は、ＭＴＣデバイス１００は、現在使用しているＰＤＮコネクションのＱＣＩやＡＲＰを把握しておく必要がある。例えば、ＭＴＣデバイス１００は、ＰＤＮコネクション（ＥＰＳベアラ）を確立した際（例えば、Ａｔｔａｃｈ ｐｒｏｃｅｄｕｒｅ中や、Ｂｅａｒｅｒ ｍｏｄｉｆｉｃａｔｉｏｎ ｐｒｏｃｅｄｕｒｅ中）にネットワーク側のエンティティ（例えば、ｅＮＢ１１０、ＭＭＥ１２０、ＳＧＷ１３０、ＰＧＷ１４０、ＨＳＳ１２５）からＱＣＩやＡＲＰを取得し、ネットワーク側からブロードキャスト送信される送信制御メッセージに格納されるＱＣＩやＡＲＰと比較してもよい。
また、詳細データフィールドにＭＴＣ ｆｅａｔｕｒｅが格納される場合は、ＭＴＣデバイス１００は、搭載しているＭＴＣ ｆｅａｔｕｒｅを把握しておく必要がある。例えば、ＭＴＣデバイス１００は、ＭＴＣデバイス１００コンテキストを持ち、そのコンテキストの中に各ＭＴＣデバイス１００が搭載する全てのＭＴＣ ｆｅａｔｕｒｅを登録してもよい。または、ＭＴＣデバイス１００が３ＧアクセスとＰＤＮコネクションを確立する際（例えば、Ａｔｔａｃｈ ｐｒｏｃｅｄｕｒｅ中）、ネットワーク側からＭＴＣデバイス１００が保持できるＭＴＣ ｆｅａｔｕｒｅ、もしくは、ＭＴＣサーバ／ユーザから指示されているＭＴＣ ｆｅａｔｕｒｅをＭＴＣデバイス１００に通知することで、ＭＴＣデバイス１００が搭載しているＭＴＣ ｆｅａｔｕｒｅを把握してもよい。
なお、詳細データフィールドを用いずに、Ｔｉｍｅ ｔｏｌｅｒａｎｔフィールドのみでＰＤＮコネクションの維持／切断を判断する場合は、例えば図２１に図示されているフォーマットから詳細データフィールドを省略してもよい。
また、「“Ｔｉｍｅ ｔｏｌｅｒａｎｔ”の機能を保持するＭＴＣデバイス１００は確立済みＰＤＮコネクションを切断する」ことを通知するために、従来技術のページングとＳＩＢ（Ｓｙｓｔｅｍ Ｉｎｆｏｒｍａｔｉｏｎ Ｂｌｏｃｋ）を用いてもよい。例えば、ＭＴＣ用のＳＩＢを新たに設ける、若しくは、既存のＳＩＢを改良して、ＭＴＣデバイス１００にそのＳＩＢを読み出すように指示することで、「“Ｔｉｍｅ ｔｏｌｅｒａｎｔ”の機能を保持するＭＴＣデバイス１００は確立済みＰＤＮコネクションを切断する」ことを通知してもよい。また、従来技術のＭＢＭＳ（Ｍｕｌｔｉｍｅｄｉａ Ｂｒｏａｄｃａｓｔ Ａｎｄ Ｍｕｌｔｉｃａｓｔ Ｓｅｒｖｉｃｅ）を用いて、各ＭＴＣデバイス１００に通知してもよい。
「“Ｔｉｍｅ ｔｏｌｅｒａｎｔ”の機能を保持するＭＴＣデバイス１００は確立済みＰＤＮコネクションを切断する」ことを通知されたＭＴＣデバイス１００は、自分自身が“Ｔｉｍｅ ｔｏｌｅｒａｎｔ”の機能を保持しているかどうかを確認する。
ＭＴＣデバイス１００が、“Ｔｉｍｅ ｔｏｌｅｒａｎｔ”の機能を保持しており、かつ、既にＰＤＮコネクションを確立済みである場合には、ＰＤＮコネクションを切断する（図２０のステップＳ１００７：ＰＤＮコネクションリリース）。なお、ここではＭＴＣデバイス１００が、“Ｔｉｍｅ ｔｏｌｅｒａｎｔ”の機能を保持していて、既にＰＤＮコネクションを確立済みである場合、即座にＰＤＮコネクションを切断しているが、例えばＭＴＣデバイスと通信システムのポリシや、アプリケーションの仕様などに基づいて、切断のタイミングを見計らってもよい。また、ＭＴＣデバイス１００と通信システムのエンティティ（例えば、ｅＮＢ１１０やＭＭＥ１２０、ＳＧＷ１３０、ＰＧＷ１４０）は、ＰＤＮコネクションを切断する際、完全に切断するのではなく、再度ＰＤＮコネクションを確立する際の時間短縮や処理負荷軽減のために以前の状態（例えば、ＭＴＣデバイス１００のＩＰアドレス、ＩＭＳI、ＩＭＥＩ、鍵情報）を一定期間、各装置で保持して再利用してもよい。
また、図２０の例では、ＭＴＣデバイスＢ１００Ｂが、“Ｔｉｍｅ ｔｏｌｅｒａｎｔ”の機能を保持しており、かつ、既にＰＤＮコネクションを確立済みのＭＴＣデバイス１００に該当する。すなわち、ＭＴＣデバイスＢ１００Ｂは、ステップＳ１００６の送信制御メッセージを受信すると、確立済みのＰＤＮコネクションを切断する。なお、このとき、ＭＴＣデバイスＢ１００Ｂは、確立したＰＤＮコネクションを切断するために、非特許文献３で定義されているＵＥ−ｉｎｉｔｉａｔｅｄ Ｄｅｔａｃｈ ＰｒｏｃｅｄｕｒｅやＵＥ ｒｅｑｕｅｓｔｅｄ ｂｅａｒｅｒ ｒｅｓｏｕｒｃｅ ｍｏｄｉｆｉｃａｔｉｏｎ ｐｒｏｃｅｄｕｒｅなどの従来技術に係る処理を用いてもよい。
また、“Ｔｉｍｅ ｔｏｌｅｒａｎｔ”を保持しておらず、ＰＤＮコネクションが確立済みのＭＴＣデバイス１００（図２０の例では、ＭＴＣデバイスＡ１００ＡとＭＴＣデバイスＣ１００Ｃに相当）は、ＰＤＮコネクションをそのまま維持する。また、“Ｔｉｍｅ ｔｏｌｅｒａｎｔ”を保持していて、ＰＤＮコネクションを保持しておらず、これからメッセージ（例えば、ＰＤＮコネクション確立リクエスト）を送信しようとしていたＭＴＣデバイス１００（ＭＴＣデバイスＥ１００ＥやＭＴＣデバイスＦ１００Ｆに相当）は、上記で説明したように（例えば、図１９の（Ｄ）から（Ｅ））、メッセージの送信タイミングを遅らせる。
また、その後、ＵＥ１０５などから優先度の高い緊急メッセージ（Ｅｍｅｒｇｅｎｃｙ ｒｅｑｕｅｓｔや、Ｅｍｅｒｇｅｎｃｙ ｍｅｓｓａｇｅとも呼ばれる）やアプリケーションメッセージが送られてくる場合、若しくは、メッセージを送るためのＰＤＮコネクション確立リクエストが送られてくる場合（図２０のステップＳ１００８：データ送信／ＰＤＮコネクション確立リクエスト）がある。この場合、ＵＥ１０５は、メッセージを送信することが可能である。ステップＳ１００７で、ＭＴＣデバイスＢが確立済みのＰＤＮコネクションを切断したことによってリソース（Ｃ−ｐｌａｎｅ、Ｕ−ｐｌａｎｅ共）が確保されたため、ネットワーク側はステップＳ１００８のＵＥによるデータ送信、若しくは、ＰＤＮコネクション確立リクエストを受け入れることができる。
なお、本発明の第８の実施の形態では、“Ｔｉｍｅ ｔｏｌｅｒａｎｔ”の機能を保持するＭＴＣデバイス１００のみを対象とするのではなく、ＡＰＮやＭＴＣグループのグループＩＤ、ネットワークオペレータを識別するＰＬＭＮ ＩＤ（Public Land Mobile Network ID）、デバイス種ＩＤ、デバイスＩＤなどと組み合わせて使用してもよい。
また、本発明の第８の実施の形態は、ＭＴＣデバイス１００が送信制御メッセージ受信後に確立したＰＤＮコネクションを切断しているが、通信システムのエンティティ（例えば、ｅＮＢ１１０やＭＭＥ１２０、ＳＧＷ１３０、ＰＧＷ１４０）やＭＴＣサーバ１５０が、Ｓｕｂｓｃｒｉｐｔｉｏｎ ｄａｔａやＭＴＣデバイス１００特有のコンテキスト、メッセージ交換（例えば、Ａｔｔａｃｈ ｐｒｏｃｅｄｕｒｅ）時などの情報から、切断すべきＰＤＮコネクション（“特定のＰＤＮコネクション”）を確認することができるのであれば、通信システムのエンティティ（例えば、ｅＮＢ１１０やＭＭＥ１２０、ＳＧＷ１３０、ＰＧＷ１４０）やＭＴＣサーバ１５０主導でＰＤＮコネクションを切断してもよい。このとき、非特許文献３で定義されているＰＤＮ ＧＷ ｉｎｉｔｉａｔｅｄ ｂｅａｒｅｒ ｄｅａｃｔｉｖａｔｉｏｎやＭＭＥ−ｉｎｉｔｉａｔｅｄ Ｄｅｔａｃｈ ｐｒｏｃｅｄｕｒｅなどの従来技術に係る処理を用いてもよい。例えば、通信システムのエンティティ（例えば、ｅＮＢ１１０やＭＭＥ１２０、ＳＧＷ１３０、ＰＧＷ１４０）やＭＴＣサーバ１５０が、優先度の高いＵＥ１０５やＭＴＣデバイス１００のためのリソースを確保するために算出、若しくは、取得したＰＤＮコネクションを切断するための条件（例えば、“Ｔｉｍｅ ｔｏｌｅｒａｎｔ”の機能を保持するＭＴＣデバイス１００で、Ｂｅｆｏｒｅ ｔｉｍｅで示される値に該当するＭＴＣデバイス１００）と、記憶していたＭＴＣデバイス１００によってＰＤＮコネクションが確立された時刻を比較し、切断すべきＰＤＮコネクションを確認することができる場合がある。
次に、図２２を参照しながら、本発明の第８の実施の形態におけるＭＴＣデバイス１００の構成について説明する。図２２は、本発明の第８の実施の形態におけるＭＴＣデバイス１００の構成の一例を示す図である。
図２２において、ＭＴＣデバイス１００は、通信システム（例えば、Ｅ−ＵＴＲＡＮやＵＴＲＡＮ）と接続して下位レイヤにおける通信処理と上位レイヤでＩＰなどのパケット通信処理を実施する通信処理部１１１０、ネットワーク側からブロードキャスト送信された送信制御メッセージのＴｉｍｅ ｔｏｌｅｒａｎｔフィールドと詳細データフィールドを処理するブロードキャストメッセージ処理部１１２０、ブロードキャストメッセージ処理部１１２０の結果に基づいて、既に確立済みのＰＤＮコネクションを維持／切断するＰＤＮコネクション処理部１１３０を少なくとも有する。
また、送信制御メッセージの詳細データフィールドに情報が格納される場合は、詳細データ処理部１１４０を設けてもよい。詳細データ処理部１１４０は、例えば、Ｂｅｆｏｒｅ ｔｉｍｅを用いてデータ送信開始時間でＰＤＮコネクションの切断をする場合、ＭＴＣデバイス１００内でデータ送信を開始した時間を記憶する機能やタイマー機能を有する。詳細データ処理部１１４０は、既存の処理部（例えば、ブロードキャストメッセージ処理部１１２０）に組み込んでもよい。
次に、図２２に図示されている構成を有するＭＴＣデバイス１００について、本発明における特徴的な処理を中心に、図２３を用いて詳しく説明する。
図２３において、ＭＴＣデバイス１００は、ｅＮＢ１１０からブロードキャスト送信されたメッセージ（送信制御メッセージ）を受信する（図２３のステップＳ１２１０）。ＭＴＣデバイス１００は、ＭＴＣデバイス１００自身がＰＤＮコネクションを切断するＭＴＣデバイス１００であるかを確認するために、ブロードキャストメッセージ（送信制御メッセージ）のＴｉｍｅ ｔｏｌｅｒａｎｔフィールドと詳細データフィールドに格納されている情報をブロードキャストメッセージ処理部１１２０で取得する（図２３のステップＳ１２２０）。
ＭＴＣデバイス１００は、受信したブロードキャストメッセージの送信対象に自分が含まれていないと判断した場合には、特別な処理は行わずに終了する。
一方、ＭＴＣデバイス１００が、受信したブロードキャストメッセージの送信対象に自分が含まれていると判断した場合には、ＭＴＣデバイス１００と通信システムの間にＰＤＮコネクションを確立済みであるかどうかを更に確認する（図２３のステップＳ１２３０）。なお、ＭＴＣデバイス１００が、ブロードキャストメッセージの送信対象に自分が含まれているかどうかを判断する処理フロー（図２３のステップＳ１２２０の処理）の詳細については後述する（図２４を参照）。
ＭＴＣデバイス１００と通信システム間にＰＤＮコネクションが確立されていない場合、ＭＴＣデバイス１００はＰＤＮコネクション未確立時の動作（例えば、“Ｔｉｍｅ ｔｏｌｅｒａｎｔ”の機能を保持しているＭＴＣデバイス１００は、ＰＤＮコネクション確立リクエストの送信タイミングを遅らせる）を実施して（図２３のステップＳ１２４０）、終了する。
一方、ＭＴＣデバイス１００と通信システム間に、既にＰＤＮコネクションを確立されている場合、ＭＴＣデバイス１００は、ＰＤＮコネクション処理部１１３０で、例えば非特許文献３で定義されているＵＥ−ｉｎｉｔｉａｔｅｄ Ｄｅｔａｃｈ ＰｒｏｃｅｄｕｒｅやＵＥ ｒｅｑｕｅｓｔｅｄ ｂｅａｒｅｒ ｒｅｓｏｕｒｃｅ ｍｏｄｉｆｉｃａｔｉｏｎ ｐｒｏｃｅｄｕｒｅなどを用いて、確立済みのＰＤＮコネクションを切断する（図２３のステップＳ１２５０）。
次に、詳細データフィールドに格納された値を用いてＰＤＮコネクションを維持／切断する際の詳細な流れについて説明する。例えば、詳細データフィールドにデータ転送を開始してから経過した時間を示す“Ｂｅｆｏｒｅ ｔｉｍｅ”が格納されている場合について、図２４を用いて詳しく説明する。なお、図２４は、図２３のステップＳ１２２０の処理の詳細について説明するためのものである。
図２４において、ＭＴＣデバイス１００は、ｅＮＢ１１０からブロードキャスト送信されたメッセージ（送信制御メッセージ）を受信する（図２４のステップＳ１２１０）。続いて、ＭＴＣデバイス１００は、ＭＴＣデバイス１００自身がＰＤＮコネクションを切断するＭＴＣデバイス１００であるかを確認するために、ブロードキャストメッセージ（送信制御メッセージ）のＴｉｍｅ ｔｏｌｅｒａｎｔフィールドを確認する（図２４のステップＳ１２２１）。このとき、ＭＴＣデバイス１００は、例えば、製造時に設定された情報（例えば、ＭＴＣ ｆｅａｔｕｒｅの一覧が登録されているＭＴＣデバイス１００コンテキスト）やＡｔｔａｃｈ ｐｒｏｃｅｄｕｒｅ中にネットワーク側から通知される情報（例えば、通信システムのオペレータから設定されるＭＴＣ ｆｅａｔｕｒｅや、ＭＴＣ Ｕｓｅｒから設定されるＭＴＣ ｆｅａｔｕｒｅ）などから、自分自身が“Ｔｉｍｅ ｔｏｌｅｒａｎｔ”の機能を保持しているか確認してもよい。
ＭＴＣデバイス１００は、自分自身が“Ｔｉｍｅ ｔｏｌｅｒａｎｔ”の機能を保持していないと判断した場合には、特別な処理は行わずに終了する。
一方、ＭＴＣデバイス１００が、自分自身が“Ｔｉｍｅ ｔｏｌｅｒａｎｔ”の機能を保持していると判断した場合には、続いて、送信制御メッセージの詳細データフィールドで示されたＢｅｆｏｒｅ ｔｉｍｅの値（時刻）を取得する。ここでは、ＭＴＣデバイス１００が既にＰＤＮコネクションを確立済みであると仮定し、ＭＴＣデバイス１００はＰＤＮコネクションを確立した時刻や、確立したＰＤＮコネクションで行うデータ転送の開始時刻を記憶、若しくは、タイマーを起動し、送信制御メッセージを受信するまでの時間を計測しているとする。
ＭＴＣデバイス１００は、送信制御メッセージの詳細データフィールドで示されたＢｅｆｏｒｅ ｔｉｍｅの値（時刻）と記憶（若しくは、計測）した値（時刻）の比較を行い、ＰＤＮコネクションの切断を判断する（図２４のステップＳ１２２２）。例えば、送信制御メッセージの詳細データフィールドで示されたＢｅｆｏｒｅ ｔｉｍｅの値（時刻）が「ＡＭ１１：００」であり、ＭＴＣデバイス１００が記憶（若しくは、計測）した値（時刻）が「ＡＭ１０：５５」であった場合（送信制御メッセージで示された時刻＞ＭＴＣデバイス１００内で記憶（計測）した時刻という条件に当てはまらない場合）、ネットワーク側が判断した値（時刻）より前から通信を開始し始めていたということで、送信制御メッセージの送信対象に自分が含まれていないと判断し、その結果、特別な処理は行わずにＰＤＮコネクションを維持する。なお、この「ＡＭ１１：００」のような形式ではなく、「１分前」のような形式でもよい。
一方、送信制御メッセージで示された時刻＞ＭＴＣデバイス１００内で記憶した時刻の条件に当てはまる場合には、ネットワーク側が判断した値（時刻）より後に通信を開始し始めたということで、送信制御メッセージの送信対象に自分が含まれていると判断し、その結果、確立済みのＰＤＮコネクションを切断する（図２４のステップＳ１２３０、ステップＳ１２４０）。
また、この詳細データフィールドを用いたＰＤＮコネクションの切断について、Ｂｅｆｏｒｅ ｔｉｍｅを例に挙げて説明したが、他のデータ残量や残時間などについても同様な処理（例えば、図２４のステップＳ１２２２はＢｅｆｏｒｅ ｔｉｍｅを用いて説明しているが、送信制御メッセージで示されたデータ残量値＞ＭＴＣデバイス内で計算したデータ残量値など）が行われる。また、Ｂｅｆｏｒｅ ｔｉｍｅとデータ残量を組み合わせることによって、さらにＰＤＮコネクションの維持／切断に用いる詳細な判断条件にできる。例えば、Ｂｅｆｏｒｅ ｔｉｍｅを用いて、ＰＤＮコネクションを切断するか絞り込みをした後に、その中でデータ残量がどれくらいかによってＰＤＮコネクションを切断するかを判断してもよい。
また、本発明の第８の実施の形態を非特許文献６で定義されているＬｏｗ ｐｒｉｏｒｉｔｙ ｉｎｄｉｃａｔｏｒと組み合わせることで、ネットワーク側で混雑状態が起こっている際、最初にＬｏｗ ｐｉｒｏｒｉｔｙ ｉｎｄｉｃａｔｏｒを持つＭＴＣデバイス１００によって確立されたＰＤＮコネクションを切断し、続いて“Ｔｉｍｅ ｔｏｌｅｒａｎｔ”の機能を持つＭＴＣデバイス１００によって確立されたＰＤＮコネクションを切断するというように、段階的にＰＤＮコネクションを切断することができる。これにより、リソースを段階的に確保することができ、過剰なＰＤＮコネクションの切断を回避することができる。例えば、通信システムのエンティティ（例えば、ｅＮＢ１１０やＭＭＥ１２０、ＳＧＷ１３０、ＰＧＷ１４０、ＨＳＳ）が、Ｌｏｗ ｐｒｉｏｒｉｔｙ ｉｎｄｉｃａｔｏｒが格納されたＰＤＮコネクション確立リクエストを送信してきたＭＴＣデバイス１００を、例えば、ＭＴＣデバイスコンテキストに登録、または、Ｓｕｂｓｃｒｉｐｔｉｏｎ ｄａｔａに登録するなどによって把握しておき、上記処理を実現させてもよい。また、通信システムのエンティティが、Ｌｏｗ ｐｒｉｏｒｉｔｙ ｉｎｄｉｃａｔｏｒを持つＭＴＣデバイス１００を把握することによって、ブロードキャスト送信する送信制御メッセージの送信先をＬｏｗ ｐｒｉｏｒｉｔｙ ｉｎｄｉｃａｔｏｒを持つＭＴＣデバイス１００のみと指定してもよい。
また、Ｌｏｗ ｐｒｉｏｒｉｔｙ ｉｎｄｉｃａｔｏｒとの組み合わせではなく、Ｔｉｍｅ ｔｏｌｅｒａｎｔフィールドの代わりにＬｏｗ ｐｒｉｏｒｉｔｙ ｉｎｄｉｃａｔｏｒフィールドを用いて、切断すべきＰＤＮコネクションを決定してもよい。このとき、Ｌｏｗ ｐｒｉｏｒｉｔｙ ｉｎｄｉｃａｔｏｒフィールドは、詳細データフィールドと組み合わせて使用してもよい。
例えば、ＭＭＥ１２０が混雑状態を検知した場合、最初にＬｏｗ ｐｒｉｏｒｉｔｙ ｉｎｄｉｃａｔｏｒを持つＭＴＣデバイス１００によって確立されたＰＤＮコネクションを切断する指示をｅＮＢ１１０に送信し、ｅＮＢ１１０が対象となるＭＴＣデバイス１００に送信制御メッセージをブロードキャストする。送信制御メッセージを受信し、かつ、Ｌｏｗ ｐｒｉｏｒｉｔｙ ｉｎｄｉｃａｔｏｒを持つＭＴＣデバイス１００は、確立済みのＰＤＮコネクションを切断する。
ここで、リソースの確保が十分でないと判断された場合（例えば、混雑状態を示す閾値を超えている場合など）、ＭＭＥ１２０がＴｉｍｅ ｔｏｌｅｒａｎｔフィールド（例えば、「“Ｔｉｍｅ ｔｏｌｅｒａｎｔ”の機能を保持している」）と詳細データフィールド（例えば、「“Ｍｏｂｉｌｅ Ｏｒｉｇｉｎａｔｅｄ ｏｎｌｙ”」）を用いて、確立済みのＰＤＮコネクションを切断するとｅＮＢ１１０に通知し、ｅＮＢ１１０が対象となるＭＴＣデバイス１００にブロードキャスト送信する。送信制御メッセージを受信し、かつ、“Ｔｉｍｅ ｔｏｌｅｒａｎｔ”と“Ｍｏｂｉｌｅ Ｏｒｉｇｉｎａｔｅｄ ｏｎｌｙ”の機能を持つＭＴＣデバイス１００は、確立済みのＰＤＮコネクションを切断する。これにより、リソースを段階的に確保することができ、過剰なＰＤＮコネクションの切断を回避することができる。
本発明の第８の実施の形態では、一部のＭＴＣデバイス１００（ＭＴＣデバイスＢ１００Ｂ、ＭＴＣデバイスＤ１００Ｄ、ＭＴＣデバイスＥ１００Ｅ、ＭＴＣデバイスＦ１００Ｆ）が“Ｔｉｍｅ ｔｏｌｅｒａｎｔ”の機能を保持していることを前提としているが、全てのＭＴＣデバイス１００が“Ｔｉｍｅ ｔｏｌｅｒａｎｔ”の機能を保持している場合にも適用できる。
全てのＭＴＣデバイス１００が、“Ｔｉｍｅ ｔｏｌｅｒａｎｔ”の機能を保持している場合、“Ｔｉｍｅ ｔｏｌｅｒａｎｔ”の機能を保持しているか否かでＰＤＮコネクションの切断を判断することができなくなるので、図２１の詳細データフィールドに格納される判断条件を用いて、ＰＤＮコネクションの切断を判断する。例えば、全てのＭＴＣデバイス１００が“Ｔｉｍｅ ｔｏｌｅｒａｎｔ”の機能を保持している環境において、“Ｔｉｍｅ ｔｏｌｅｒａｎｔ”の機能を保持し、“Ｍｏｂｉｌｅ Ｏｒｉｇｉｎａｔｅｄ ｏｎｌｙ”の機能も保持しているＭＴＣデバイス１００によって確立されたＰＤＮコネクションを切断するというブロードキャストメッセージは、“Ｍｏｂｉｌｅ Ｏｒｉｇｉｎａｔｅｄ ｏｎｌｙ”の機能を保持しているＭＴＣデバイス１００によって確立されたＰＤＮコネクションは切断するという送信制御メッセージになる。同様に、全てのＭＴＣデバイス１００が、“Ｔｉｍｅ ｔｏｌｅｒａｎｔ”の機能を保持している環境において、Ｔｉｍｅ ｔｏｌｅｒａｎｔ”の機能を保持し、「送信制御メッセージで示された時刻＞ＭＴＣデバイス１００内で記憶した時刻」の条件に当てはまる場合には、確立済みのＰＤＮコネクションを切断するという送信制御メッセージは、「送信制御メッセージで示された時刻＞ＭＴＣデバイス１００内で記憶した時刻」の条件に当てはまるＭＴＣデバイス１００によって確立されたＰＤＮコネクションは切断するという送信制御メッセージになる。そのため、ｅＮＢ１１０がブロードキャスト送信する送信制御メッセージにおいて、“Ｔｉｍｅ ｔｏｌｅｒａｎｔ”の機能を保持するＭＴＣデバイス１００であるか否かを識別するための図２１のＴｉｍｅ ｔｏｌｅｒａｎｔフィールドは省略できる。
以上、本発明の第８の実施の形態によれば、既にネットワーク側で混雑状態が起こっているとき、若しくは、あるメッセージ（例えば、ＰＤＮコネクション確立リクエストや、転送データ）を受信した時点で混雑状態が起こり始めたときに、ＵＥ１０５などから優先度の高い緊急メッセージ（Ｅｍｅｒｇｅｎｃｙ ｒｅｑｕｅｓｔや、Ｅｍｅｒｇｅｎｃｙ ｍｅｓｓａｇｅとも呼ばれる）やアプリケーションメッセージが送られてくることで更なるリソース（Ｕ−ｐｌａｎｅ、Ｃ−ｐｌａｎｅ共）が必要となる課題に対して、ネットワーク側からブロードキャスト送信されるメッセージで、ＭＴＣデバイス１００が“Ｔｉｍｅ ｔｏｌｅｒａｎｔ”の機能を保持しており、そして、詳細データフィールドで示される値（例えば、“Ｂｅｆｏｒｅ ｔｉｍｅ”で示されるデータ転送を開始してから経過した時間）を用いて、既に確立済みであるＰＤＮコネクションの維持／切断をする。これにより、優先度レベルの高いリクエストやアプリケーションのためのリソースを確保することができる。
また、ネットワーク側（例えば、ｅＮＢ１１０やＭＭＥ１２０、ＳＧＷ１３０、ＰＧＷ１４０、ＭＴＣサーバ１５０）から対象となるＭＴＣデバイス１００（例えば、特定のＡＰＮに接続しているＭＴＣデバイス１００、特定のＭＴＣグループに属しているＭＴＣデバイス１００、特定のオペレータに属しているＭＴＣデバイス１００、特定のエリア（例えば、特定のｅＮＢ１１０やＭＭＥ１２０に接続しているＭＴＣデバイス１００）など）にメッセージがブロードキャストされることによって、メッセージ（例えば、ＰＤＮコネクション確立リクエスト）を送信しようとしていたＭＴＣデバイス１００からのメッセージを回避することができる。それにより、ネットワーク側のエンティティ（例えば、ｅＮＢ１１０やＭＭＥ１２０、ＳＧＷ１３０、ＰＧＷ１４０、ＭＴＣサーバ１５０）の処理負荷やトラフィックが軽減される。
また、上記の実施の形態でネットワーク側のエンティティ（例えば、ｅＮＢ１１０やＭＭＥ１２０、ＳＧＷ、ＰＧＷ、ＭＴＣサーバ１５０）からメッセージ（例えば、本発明の第１〜第７の実施の形態では逆イベント通知メッセージ、本発明の第８の実施の形態では送信制御メッセージ）がブロードキャストされる。ネットワーク側のエンティティ（例えば、ｅＮＢ１１０、ＭＭＥ１２０、ＳＧＷ１３０、ＰＧＷ１４０、ＭＴＣサーバ１５０）は、非特許文献６で定義されるように、このブロードキャストされるメッセージにＭＴＣデバイス１００が送信するメッセージを遅らすための待機時間（Ｓｔｏｐ ｔｉｍｅ、Ｂａｒｒｉｎｇ ｔｉｍｅ、Ｂａｃｋｏｆｆ ｔｉｍｅ、Ｗａｉｔ ｔｉｍｅなどとも呼ばれる）を格納する場合もある。ＭＴＣデバイス１００は、この待機時間の間はデータ送信やＰＤＮコネクション確立リクエストなどのメッセージ送信を行えないものとする（例えば、ＭＴＣデバイス１００が通常モードからデータ送信抑制モードや、規制モード、制限モードなどにモード遷移する）。しかし、優先度レベルの高いイベントを検知した場合や、緊急事態が生じた場合には、ネットワーク側からメッセージ送信の抑制をされているが、ＭＴＣデバイス１００はデータ送信やＰＤＮコネクション確立リクエストの送信が可能なモード（例えば、通常モード）にモード遷移できるものとする。また、この待機時間は、詳細データフィールドに格納されるＰＤＮコネクションを維持／切断するための条件（例えば、Ｂｅｆｏｒｅ ｔｉｍｅ）と共用してもよい。例えば、待機時間を「３分」と設定し、優先度レベルの低いＭＴＣデバイスからのメッセージ（例えば、ＰＤＮコネクション確立リクエスト）を３分間抑制すると同時に、３分以内に確立されたＰＤＮコネクションを切断するように指示してもよい。なお、このとき、詳細データフィールドは省略でき、通信システムのエンティティやＭＴＣデバイス１００の処理負荷、ネットワークのトラフィックが軽減される。
また、上記の実施の形態（特に第８の実施の形態）で、ＭＴＣデバイス１００とネットワーク側のエンティティが、異なる優先度レベルを認識できる場合（例えば、アプリケーションＡのデータは優先度レベルＡであり、ＵＥ１０５からのメッセージは優先度レベルＢなど）、ネットワーク側のエンティティ（例えば、ｅＮＢ１１０、ＭＭＥ１２０、ＳＧＷ１３０、ＰＧＷ１４０、ＭＴＣサーバ１５０）は優先度レベル毎にメッセージ送信を抑制してもよい。例えば、ｅＮＢ１１０がブロードキャスト送信する送信制御メッセージに「優先度レベルＢのみ抑制」ということを示すパラメータを格納する。この送信制御メッセージを受信したＭＴＣデバイス１００は、優先度レベルＢのメッセージのみ送信を遅らせる／停止させる、若しくは、優先度レベルを変化させてメッセージを送信する。例えば、「優先度レベルＢのみ抑制」であるが、「ＭＴＣグループＡに属しているＭＴＣデバイス１００は免除」ということを示すパラメータと組み合わせて使用してもよい。また、優先度レベルだけではなく、従来技術の、例えば、Ａｃｃｅｓｓ ｃｌａｓｓを用いてＭＴＣデバイス１００から送信されるメッセージを抑制してもよい。
また、上記の実施の形態（特に第１〜第８の実施の形態）におけるＭＴＣデバイス１００は、１つのＭＴＣグループや１つのＡＰＮ、１つのＰＬＭＮオペレータに属していたが、複数のＭＴＣグループや複数のＡＰＮ、複数のＰＬＭＮオペレータに属してもよい。例えば、ＭＴＣデバイス１００が２つのＡＰＮ（ＡＰＮ−１とＡＰＮ−２）に接続している場合、通信システムは段階的にＭＴＣデバイス１００から送信されるメッセージを抑制することができる。例えば、ネットワーク側のエンティティ（例えば、ｅＮＢ１１０、ＭＭＥ１２０、ＳＧＷ１３０、ＰＧＷ１４０、ＭＴＣサーバ１５０）がブロードキャスト送信する送信制御メッセージ、若しくは、逆イベント通知メッセージに「ＡＰＮ−１を用いた送信メッセージを抑制」ということを示すパラメータを格納する。これにより、ＭＴＣデバイス１００はＡＰＮ−１を用いたメッセージ送信は抑制されるが、ＡＰＮ−２を用いたメッセージ送信は可能となる。
また、本発明の第８の実施の形態では、説明の容易化のために、“Ｔｉｍｅ ｔｏｌｅｒａｎｔ”フィールドと詳細データフィールドを用いた結果、確立済みのＰＤＮコネクションを切断すると多く記述したが、通信システムのオペレータのポリシやＭＴＣサーバ、ＭＴＣユーザのポリシ、アプリケーションのポリシ、ＭＴＣデバイスのポリシによっては、確立済みのＰＤＮコネクションを切断ではなく、「維持」すると決定してもよい。
なお、本発明の第８の実施の形態では、“Ｔｉｍｅ ｔｏｌｅｒａｎｔ”の機能を保持し、詳細データフィールドで指定された条件に該当するＭＴＣデバイス１００が、既にＰＤＮコネクションを確立済みである場合、ＭＴＣデバイス１００はＰＤＮコネクションを切断していたが（図２４のステップＳ１２２１、Ｓ１２２２、Ｓ１２３０、Ｓ１２５０）、ＰＤＮコネクションは切断せずに（維持したまま）、データ送信のみ制御（例えば、停止、データレートの変更、データサイズの変更）を行ってもよい。これにより、Ｕ−ｐｌａｎｅのリソースを段階的に確保することができる。また、ＰＤＮコネクションを切断しないため、再度ＰＤＮコネクションを確立する必要がなくなり、通信システムのエンティティ（例えば、ｅＮＢ１１０、ＭＭＥ１２０、ＳＧＷ１３０、ＰＧＷ１４０）の処理負荷が軽減される（例えば、アドレスの割り当て、バインディングアップデート）。
なお、本発明の第８の実施の形態は、通信システムのエンティティが対象となるＭＴＣデバイス１００にブロードキャストして、優先度レベルの高いＵＥ１０５やＭＴＣデバイス１００のためのリソースを確保するためにＰＤＮコネクションを切断しているが、ブロードキャストではなく、ユニキャストやマルチキャストで送信してもよい。
なお、本発明の第８の実施の形態は、図１９、２０を用いて説明したように、ＭＴＣデバイスＤ１００ＤがＰＤＮコネクション確立リクエストをネットワーク側に送信した結果（図２０のステップＳ１００２）、ネットワーク側が混雑状態になり（図２０のステップＳ１００３）、送信制御メッセージがＭＴＣデバイスに送信されていた（図２０のステップＳ１００６）。つまり、送信制御メッセージは、ネットワーク側が混在状態にある場合に、優先度レベルが低いＭＴＣデバイス１００からのメッセージ（例えば、ＰＤＮコネクション確立リクエスト）の回避と、既に確立済みのＰＤＮコネクションを切断することを要求するために使用された。さらに、送信制御メッセージは、既にＰＤＮコネクションを確立済みであるＭＴＣデバイス１００が、新たに送信する可能性がある別のＰＤＮコネクション確立リクエストを拒絶する、あるいは遅延させるためにも用いることができる。送信制御メッセージを新たなＰＤＮコネクション確立リクエストの遅延のために用いる場合、混雑状態を検出した際に通信システムのエンティティは、待機時間を含む送信制御メッセージを対象となるＭＴＣデバイスへブロードキャストする。このとき、ネットワーク側がブロードキャスト送信する送信制御メッセージにパラメータ情報として格納される待機時間は、既にＰＤＮコネクションを確立済みであるＭＴＣデバイス１００（ＭＴＣデバイスＡ１００Ａ、ＭＴＣデバイスＢ１００Ｂ、ＭＴＣデバイスＣ１００Ｃ、ＭＴＣデバイスＤ１００Ｄ）が送信する追加のＰＤＮコネクション確立メッセージの送信タイミングを遅らせることを指示する情報として用いられる。この送信制御メッセージを受信したＭＴＣデバイス１００は、ＭＴＣデバイス１００自身が既に確立済みのＰＤＮコネクションを保持済みであり、新たに別のＰＤＮコネクションを確立したい場合は、待機時間が経過するまでそのＰＤＮコネクション確立リクエストの送信を遅らせると判断する。例えば、既に１つのＰＤＮコネクションを確立しているＭＴＣデバイス１００が、さらに１つのＰＤＮコネクションを新たに追加で確立しようとしていた場合、送信制御メッセージを受けることで、２つ目のＰＤＮコネクションの確立要求の送信を、待機時間後へと遅らせる。
また、既にＰＤＮコネクションを確立済みであるＭＴＣデバイス１００が、待機時間が格納されていない送信制御メッセージを受信した場合、追加のＰＤＮコネクション確立リクエストを送信しないようにすることもできる。例えば、送信制御メッセージに「追加確立禁止」を示すパラメータを格納することで、ＭＴＣデバイス１００による追加のＰＤＮコネクション確立リクエスト送信を回避する。
また、既にＰＤＮコネクションを確立済みであるＭＴＣデバイス１００が、待機時間が格納されていない送信制御メッセージであり、さらにＭＴＣデバイス１００による追加予定のＰＤＮコネクションに対するパラメータ（例えば、各ＭＴＣデバイス１００が確立可能なＰＤＮコネクションの最大数、又は、追加ＰＤＮコネクションに割り当て可能なＱｏＳなど）が格納された送信制御メッセージを受信した場合、追加のＰＤＮコネクションを確立する際にこの情報に従って、ＰＤＮコネクション確立リクエストを送信する。
例えば、パラメータ情報に、同時に確立可能なＰＤＮコネクションの最大数が含まれている場合、ＭＴＣデバイス１００自身が確立したいＰＤＮコネクション数と送信制御メッセージに格納されている、同時に確立可能なＰＤＮコネクションの最大数を比較し、確立したいＰＤＮコネクションの数が、同時に確立可能なＰＤＮコネクションの数を上回る場合は、確立済みのＰＤＮコネクションが終了した後に、新たなＰＤＮコネクションの確立を行う。つまり、２つ目のＰＤＮコネクションを確立したいＭＴＣデバイス１００が、同時確立可能なＰＤＮコネクションの数が１つであるパラメータ情報を受信した場合は、確立した１つ目のＰＤＮコネクションを用いた通信が終了し、そのＰＤＮコネクションを切断した後に、２つ目の新たな別のＰＤＮコネクションを確立する。さらに、３つ目のＰＤＮコネクションを確立する場合には、２つ目のＰＤＮコネクションを用いた通信が終了した後に、そのＰＤＮコネクションを切断し、３つ目の新たなＰＤＮコネクションを確立する。なお、新たなＰＤＮコネクションを確立する必要が生じた際に、既に確立されているＰＤＮコネクションを直ぐに切断すると判断してもよい。また、パラメータ情報として、同時に確立可能なＰＤＮコネクションの数を通知する代わりに、追加のＰＤＮコネクションの確立が制限されていることを示す情報を送信制御メッセージに含めてもよい。この情報を受けたＭＴＣデバイス１００は、新たなＰＤＮコネクションを確立する場合は、既に確立しているＰＤＮコネクションを切断した後に、新たなＰＤＮコネクションの確立要求を送信する。
これにより、ＭＴＣデバイス１００が複数のＰＤＮコネクションを確立しなければならない場合（例えば、ＭＴＣデバイス１００が複数のＭＴＣサーバ１５０または複数のＡＰＮ、若しくは、複数のＭＴＣユーザ１６０と接続されていて、ＭＴＣユーザの情報セキュリティや契約関係上、ＰＤＮコネクションを分けて使用しなければならない場合）に、同時に確立できるＰＤＮコネクションの数を制限することで、同時に複数のＰＤＮコネクションを確立することによって帯域が占有されてしまうことを防ぐ効果がある。
また、上記したＭＴＣデバイス１００による追加予定のＰＤＮコネクションに対するパラメータ（例えば、各ＭＴＣデバイス１００が確立可能なＰＤＮコネクションの最大数、又は、追加ＰＤＮコネクションに割り当て可能なＱｏＳなど）に加えて、待機時間が格納される場合、ＭＴＣデバイス１００による追加予定のＰＤＮコネクションに対するパラメータ（例えば、各ＭＴＣデバイス１００が確立可能なＰＤＮコネクションの最大数、又は、追加ＰＤＮコネクションに割り当て可能なＱｏＳなど）の適用時間（有効期間）として使用することで、リアルタイムに変化するネットワーク側の混雑状態に沿ったリソース管理になる。例えば、ネットワーク側からブロードキャスト送信される送信制御メッセージに、待機時間（例えば、「１分」）が格納されており、かつ、「各ＭＴＣデバイス１００が確立可能なＰＤＮコネクションは１つ」と示されている場合、送信制御メッセージを受信したＭＴＣデバイス１００は、送信制御メッセージを受信した後から１分以内に新たなＰＤＮコネクション確立リクエストを送信する場合は、既に確立済みのＰＤＮコネクションを切断した後、追加のＰＤＮコネクションを確立する。待機時間の経過後は、「各ＭＴＣデバイス１００が確立可能なＰＤＮコネクションは１つ」と示されている情報は、適用時間を過ぎているので、追加のＰＤＮコネクションを確立する際には用いなくてよい。なお、追加予定のＰＤＮコネクションに対するパラメータが格納された送信制御メッセージを受信したＭＴＣデバイス１００は、追加のＰＤＮコネクションを確立する際、追加のＰＤＮコネクションの確立を諦めて既に確立済みのＰＤＮコネクションを維持するか、若しくは、既に確立済みのＰＤＮコネクションを切断して追加のＰＤＮコネクションを確立するかを、例えば、ＭＴＣデバイス１００が保持するコンテキスト（例えば、ＭＴＣサーバ１５０やＭＴＣユーザ１６０からの要求やスタティックな情報）や、アプリケーションに仕様に基づいて判断してもよい。
この「各ＭＴＣデバイス１００が確立可能なＰＤＮコネクションは１つ」と示されている情報は、送信制御メッセージの詳細データフィールドに格納してもよい。
なお、既にＰＤＮコネクションを確立しているＭＴＣデバイス１００に対して、追加のＰＤＮコネクションに対するパラメータを通知するメッセージは、ブロードキャストではなくユニキャストで送信されてもよい。この場合、ＭＴＣデバイス１００は、最初のＰＤＮコネクションを確立する際に（例えば、Ａｔｔａｃｈ ｐｒｏｃｅｄｕｒｅ中）、通信システムのエンティティから追加のＰＤＮコネクションに対するパラメータ（例えば、各ＭＴＣデバイス１００が確立可能なＰＤＮコネクションの最大数、又は、追加ＰＤＮコネクションに割り当て可能なＱｏＳなど）を含む送信制御メッセージを受信する。パラメータ情報を取得したＭＴＣデバイス１００は、上記のように、取得したパラメータ情報に従って追加のＰＤＮコネクションを確立するためのＰＤＮコネクション確立リクエストを送信する。
なお、追加のＰＤＮコネクションに対するパラメータ情報がＭＴＣデバイス１００に通知されるタイミングは、ＭＴＣデバイス１００から最初のＰＤＮコネクション確立リクエストを受けた際に限定されず、既にＰＤＮコネクションの確立が終了した後の任意のタイミングでもよい。つまり、ネットワーク側が混雑状態を検出した際に、既にＰＤＮコネクションを確立しているＭＴＣデバイス１００に対してパラメータ情報が通知される。また、ＭＴＣデバイス１００が送信する追加のＰＤＮコネクションの確立リクエストを受信した際に、その確立リクエストが拒絶されたことを通知する送信制御メッセージ、さらには追加のＰＤＮコネクションに対するパラメータ情報を含む送信制御メッセージをＭＴＣデバイス１００に通知してもよい。
＜第９の実施の形態＞
本発明の第９の実施の形態では、既にＰＤＮコネクションを確立済みの状態で、さらに追加のＰＤＮコネクション確立を望むＭＴＣデバイス１００が、ネットワークから通知される混雑状態に関する情報に基づいて、既に確立済みのＰＤＮコネクションをリリースし、追加のＰＤＮコネクションを確立する。
本発明の第９の実施の形態では、既にＰＤＮコネクションを確立済みの状態で、さらに追加のＰＤＮコネクション確立を望むＭＴＣデバイス１００が、ネットワークから通知される混雑状態に関する情報に基づいて、既に確立済みのＰＤＮコネクションをリリースし、追加のＰＤＮコネクションを確立する。
ＭＴＣデバイス１００は、ネットワークが混雑している場合でも、新たにＰＤＮコネクションを確立し、データを送信したい場合がある。例えば、ＭＴＣデバイス１００が人感センサであり、センサが不良動作を起こしていないかなどを確認するためのメンテナンスデータと、実際にセンサが取得したセンシングデータの送信先のＭＴＣサーバ１５０が異なり、メンテナンス用のＰＤＮコネクションは確立済みで、センシングしたデータを送信するためのＰＤＮコネクションを任意の期間のみ確立するケースや、又は、ＭＴＣデバイス１００が自動販売機であり、ＭＴＣサーバ１５０に接続するためのＰＤＮコネクションと、ＩＭＳ（ＩＰ Ｍｕｌｔｉｍｅｄｉａ Ｓｕｂｓｙｓｔｅｍ）に接続するためのＰＤＮコネクションがあり、ＭＴＣサーバ１５０に接続するためのＰＤＮコネクションは確立済みで、ＩＭＳに接続するためのＰＤＮコネクションを任意のタイミングで確立するケースなどがある。しかし、最初のＰＤＮコネクションを確立してから、追加のＰＤＮコネクションを確立するまでの間に、ネットワークは混雑状態を検出する場合があり、このとき、ＭＴＣデバイス１００が送信する追加のＰＤＮコネクション確立リクエストは拒絶されてしまう。また、ＭＴＣデバイス１００において、既に確立済みのＰＤＮコネクションで送信しているデータより、追加で確立するＰＤＮコネクションで送信するデータのほうが優先度レベルの高い場合がある。このとき、ＭＴＣデバイス１００が追加のＰＤＮコネクションを確立できない場合、ＭＴＣデバイス１００やＭＴＣサーバ１５０、ＭＴＣユーザ１６０などに優先度レベルが高いデータを送受信できないなどの不利益が生じる。このような課題を解決するために、既にＰＤＮコネクションを確立済みであるＭＴＣデバイス１００は、ネットワークから通知される混雑状態に関する情報に基づいて、既に確立済みのＰＤＮコネクションをリリースし、追加のＰＤＮコネクションを確立する。
以下、本発明の第９の実施の形態について、図２５、図２６、図２７Ａ〜図２７Ｅ、図２８〜図３０、図３５、図３６を用いて説明する。
ここで、本発明の第９の実施の形態の説明を容易化するために、本発明の第９の実施の形態におけるＭＴＣデバイス１００は、ネットワークと既にＰＤＮコネクションを１つ確立済みであり、確立済みのＰＤＮコネクション内のＥＰＳベアラに対して、ネットワークが保証するビットレート（ＧＢＲ：Guaranteed Bit Rate）は５Ｍｂｐｓとする。また、ＭＴＣデバイス１００は、追加のＰＤＮコネクションを確立するために、ＰＤＮコネクション確立リクエストを送信する。
この“ＧＢＲ＝５Ｍｂｐｓ”とは、ネットワークがＭＴＣデバイス１００に対して、５Ｍｂｐｓのビットレートを保証することを示している。例えば、ＭＴＣデバイス１００に５ＭｂｐｓのＧＢＲが割り当てられている間、ネットワークは５Ｍｂｐｓを下回るビットレート（例えば、４Ｍｂｐｓ）をＭＴＣデバイス１００に提供しないことを示している。
“ＧＢＲ＝５Ｍｂｐｓ”が割り当てられたＥＰＳベアラを含むＰＤＮコネクションを確立済みであるＭＴＣデバイス１００の動作について、図２５を用いて説明する。
図２５において、“ＧＢＲ＝５Ｍｂｐｓ”が割り当てられたＥＰＳベアラを含むＰＤＮコネクションを確立済みであるＭＴＣデバイス１００が、追加のＰＤＮコネクションを確立しようとする状態を前提とする（ステップＳ２５００）。ＭＴＣデバイス１００は、追加のＰＤＮコネクションを確立するためにＰＤＮコネクション確立リクエストを送信する（ステップＳ２５０１：ＰＤＮコネクション確立リクエスト）。なお、ＭＴＣデバイス１００がＰＤＮコネクションを確立する際、非特許文献３で定義されているＰＤＮ ｃｏｎｎｅｃｔｉｖｉｔｙ ｒｅｑｕｅｓｔメッセージや、Ｓｅｒｖｉｃｅ ｒｅｑｕｅｓｔや、Ｃｒｅａｔｅ Ｂｅａｒｅｒ ｒｅｑｕｅｓｔメッセージなどを使用してもよい。
このとき、ＰＤＮコネクション確立リクエストを受信したネットワークでは、ネットワーク側で混雑状態が発生してしまうとする（図２５の（Ａ）混雑発生）。そのため、ネットワークは、ステップＳ２５０１でＭＴＣデバイス１００から送信されたＰＤＮコネクション確立リクエストを拒絶するＰＤＮコネクション確立拒絶レスポンスを送信する（ステップＳ２５０２：ＰＤＮコネクション確立拒絶レスポンス）。
追加のＰＤＮコネクション確立を拒絶されたＭＴＣデバイス１００は、追加のＰＤＮコネクションの優先度レベルと確立済みのＰＤＮコネクションの優先度レベルを比較する（ステップＳ２５０３：優先度レベルの比較）。なお、ＰＤＮコネクションの優先度レベルは、アプリケーションレイヤから取得できるアプリケーション毎に割り当てられる優先度レベルや、ＭＴＣデバイス１００が保持するポリシ、ＭＴＣデバイス１００がＭＴＣのためにスタティック（静的）に格納されている情報（例えば、最初に起動したアプリケーションを優先的に処理するなど）などを用いて取得してもよい。
追加のＰＤＮコネクションの優先度レベルのほうが高いと判断したＭＴＣデバイス１００は、確立済みのＰＤＮコネクションの代わりとして追加のＰＤＮコネクションを確立できるか確認するために、既に確立済みのＰＤＮコネクションのＥＰＳベアラに割り当てられているＱｏＳ情報（ＧＢＲ情報など）と、追加のＰＤＮコネクションのＥＰＳベアラに必要なＱｏＳ情報（ＧＢＲ情報など）を比較する（ステップＳ２５０４：ＱｏＳ比較）。
例えば、ＧＢＲで比較する場合には、図２７Ａで示すように、確立済みのＰＤＮコネクションのＥＰＳベアラに割り当てられているＧＢＲが１Ｍｂｐｓの場合、ＭＴＣデバイス１００は、追加のＰＤＮコネクションのＥＰＳベアラに必要なＧＢＲが１Ｍｂｐｓ以下であれば、確立済みのＰＤＮコネクションを切断することで、追加のＰＤＮコネクションを確立できる。なお、このとき、ＭＴＣデバイス１００は従来であれば、追加のＰＤＮコネクションを確立することができないが、確立済みのＰＤＮコネクションより追加のＰＤＮコネクションの優先度レベルのほうが高いことを知得した場合、ＭＴＣデバイス１００は確立済みのＰＤＮコネクションをリリースした後、ＭＴＣデバイス１００は追加のＰＤＮコネクションを確立する。
また、ＱＣＩで比較する場合には、図２７Ｂで示すように、ＭＴＣデバイス１００が、追加で確立するＰＤＮコネクションのＱＣＩが、既に確立済みのＰＤＮコネクションに割り当てられているＱＣＩと一致している場合、ＭＴＣデバイス１００は確立済みのＰＤＮコネクションを切断することで、追加のＰＤＮコネクションを確立できる。また、ＱＣＩが一致しており、かつ確立済みのＰＤＮコネクションのＧＢＲが、追加で確立するＰＤＮコネクションのＧＢＲよりも大きい場合に、ＭＴＣデバイス１００は確立済みのＰＤＮコネクションを切断することで、追加のＰＤＮコネクションを確立できると判断してもよい。このように、上記のＧＢＲを用いた説明と同様に、ＭＴＣデバイス１００は従来であれば、追加のＰＤＮコネクションを確立することができないが、確立済みのＰＤＮコネクションより追加のＰＤＮコネクションの優先度レベルのほうが高いため、ＭＴＣデバイス１００は確立済みのＰＤＮコネクションをリリースした後、ＭＴＣデバイス１００は追加のＰＤＮコネクションを確立する。
また、ＱｏＳ情報を複数用いて、ＭＴＣデバイス１００が確立済みのＰＤＮコネクションをリリースして、追加のＰＤＮコネクションを確立するか判断してもよい。例えば、ＭＴＣデバイス１００が、ＱｏＳ情報として、ＧＢＲとＭＢＲを用いてもよい。この場合、ＭＴＣデバイス１００は、最初のステップとして、追加で確立するＰＤＮコネクションのベアラで用いられるＧＢＲが、「既に確立済みのＰＤＮコネクションのベアラで用いられるＧＢＲ」以下であるか確認する。「既に確立済みのＰＤＮコネクションのベアラで用いられるＧＢＲ」以下の場合、ＭＴＣデバイス１００は、ＧＢＲに続いてＭＢＲも同様に確認する。ＭＢＲも同様に「既に確立済みのＰＤＮコネクションのベアラで用いられるＭＢＲ」以下の場合、ＭＴＣデバイス１００は、既に確立済みのＰＤＮコネクションをリリーすることによって確保されるリソースを用いて追加のＰＤＮコネクションを確立することができると判断し、既に確立済みのＰＤＮコネクションをリリースする。そして、ＭＴＣデバイス１００は、新しいＰＤＮコネクションを確立する。
なお、上記の説明例では、ＱｏＳ情報の比較処理を実施する際、ＧＢＲ、ＱＣＩ、ＭＢＲを挙げているが、他のＱｏＳ情報に関する例も含めて、図２６にアクション、図２７Ａ〜図２７Ｅにアクション結果が図示されている。
また、上記のＱｏＳ比較処理の説明では、ＭＴＣデバイス１００が１つのＰＤＮコネクションを確立済みの状態を前提としていたが、ＭＴＣデバイス１００が複数のＰＤＮコネクションを確立済みの状態では、各ＰＤＮコネクション、若しくは、各ＰＤＮコネクションのＥＰＳベアラに割り当てられているＱｏＳ情報の合計（ＧＢＲの合計など）や、もしくは、両方（ＱＣＩが一致するベアラケースなど）が、追加で確立するＰＤＮコネクションで必要なＱｏＳ情報を満たすことができる場合、ＭＴＣデバイス１００は追加のＰＤＮコネクションを確立することができる。このとき、ＭＴＣデバイス１００は、確立済みのＰＤＮコネクションを全てリリースしてもよいし、追加のＰＤＮコネクションに必要なＱｏＳ情報を確保するためにリリースする必要があるＰＤＮコネクションを複数選択した後、それらをリリースしてもよい。
なお、追加のＰＤＮコネクションや、ＥＰＳベアラに必要なＱｏＳ情報は、例えば、ＭＴＣサービスのアプリケーションや、ＭＴＣデバイス１００が保持するポリシ、ＭＴＣデバイス１００にＭＴＣのためにスタティックに格納されている情報、ＭＴＣサーバ１５０やＭＴＣユーザ１６０から直接通知される情報などから取得してもよい。
ステップＳ２５０３において比較した結果、追加で確立するＰＤＮコネクションのＥＰＳベアラのＱｏＳ情報（ＧＢＲ情報）が、既に確立済みのＰＤＮコネクションのＥＰＳベアラに割り当てられているＱｏＳ情報（ＧＢＲ情報）以下であれば（例えば、既に確立済みのＰＤＮコネクションのＥＰＳベアラに割り当てられているＧＢＲ情報が５Ｍｂｐｓで、追加で確立するＰＤＮコネクションのＥＰＳベアラで必要なＧＢＲ情報が４Ｍｂｐｓの場合など）、確立済みのＰＤＮコネクションをリリースする（ステップＳ２５０５：ＰＤＮコネクションＲｅｌｅａｓｅ ｐｒｏｃｅｄｕｒｅ）。なお、確立済みのＰＤＮコネクションをリリースする際に、非特許文献３で定義されるＵＥ ｒｅｑｕｅｓｔｅｄ ＰＤＮ ｄｉｓｃｏｎｎｅｃｔｉｏｎ ｐｒｏｃｅｄｕｒｅや、ＵＥ−ｉｎｉｔｉａｔｅｄ Ｄｅｔａｃｈ ｐｒｏｃｅｄｕｒｅ、ＵＥ ｒｅｑｕｅｓｔｅｄ ｂｅａｒｅｒ ｒｅｓｏｕｒｃｅ ｍｏｄｉｆｉｃａｔｉｏｎ ｐｒｏｃｅｄｕｒｅなどを使用してもよい。
また、ＭＴＣデバイス１００が、ＰＤＮコネクションをリリースすることによって確保されたリソースが、ＭＴＣデバイス１００ではなく、他のＭＴＣデバイスやＵＥに割り当てられてしまう場合が考えられる。この場合、ＭＴＣデバイス１００は、確立済みのＰＤＮコネクションをリリースする際、リリースしたＰＤＮコネクションのＥＰＳベアラに割り当てられているＱｏＳ情報（ＧＢＲ情報）を新たに確立するＰＤＮコネクションで再使用することをネットワークへ通知する。
図２８は、ＭＴＣデバイス１００がＵＥ ｒｅｑｕｅｓｔｅｄ ＰＤＮ ｄｉｓｃｏｎｎｅｃｔｉｏｎ ｐｒｏｃｅｄｕｒｅを用いて、ネットワーク側にリリースしたＰＤＮコネクションのＥＰＳベアラに割り当てられていたリソース（ＱｏＳ情報）を新たに確立するＰＤＮコネクションで再使用することをネットワークへ通知するメッセージのフォーマット例である。
図２８に図示されているメッセージは、従来のＰＤＮ Ｄｉｓｃｏｎｎｅｃｔｉｏｎ Ｒｅｑｕｅｓｔメッセージフィールドに加えて、他のＭＴＣデバイス１００やＵＥ１０５にＱｏＳ情報（ＧＢＲ情報）を割り当てないように通知するためのＱｏＳ保持フィールド、ＭＴＣデバイス１００が要求するネットワーク側でＱｏＳ情報を保持する期間を示す保持期間フィールドで構成される。
続いて、図２５において、確立済みのＰＤＮコネクションをリリース後、ＭＴＣデバイス１００は、ＰＤＮコネクション確立リクエストを送信する（ステップＳ２５０６：ＰＤＮコネクション確立リクエスト）。このとき、ネットワーク側が、ＰＤＮコネクションをリリースすることによって確保されたリソースを使用して新たにＰＤＮコネクションを確立しようとしているＭＴＣデバイス１００であることを識別できることとする。例えば、ＰＤＮコネクション確立リクエストに格納されているＭＴＣデバイス１００のＩＭＳＩやＩＭＥＩ、又は、ＰＤＮコネクションＲｅｌｅａｓｅ ｐｒｏｃｅｄｕｒｅ中に交換した新規の識別子などを用いてＭＴＣデバイス１００を識別してもよい。
ステップＳ２５０６のＰＤＮコネクション確立リクエストを受信したネットワークは、ＰＤＮコネクションをリリースすることによって確保されたリソースを使用して新たにＰＤＮコネクションを確立しようとしているＭＴＣデバイス１００であることを確認し、ＰＤＮコネクション確立許可レスポンスを送信する（ステップＳ２５０７：ＰＤＮコネクション確立許可レスポンス）。
ＰＤＮコネクション確立後、ＭＴＣデバイス１００はステップＳ２５０７で確立したＰＤＮコネクションのＥＰＳベアラで使用するＱｏＳ情報（ＧＢＲ情報）に変更するため、ＰＤＮコネクションＭｏｄｉｆｉｃａｔｉｏｎ ｐｒｏｃｅｄｕｒｅを実施する（ステップＳ２５０８）。このときも、ステップＳ２５０６のときと同様に、ネットワークは、確保しているリソースの対象ＭＴＣデバイス１００であることを識別できることとする。なお、ステップＳ２５０４のＱｏＳ情報の比較後、ＭＴＣデバイス１００が確立済みのＰＤＮコネクションをリリースし、ＰＤＮコネクションの確立処理をするのではなく、ＰＤＮコネクションＭｏｄｉｆｉｃａｔｉｏｎ ｐｒｏｃｅｄｕｒｅをするだけで、新たに確立しようとしているＰＤＮコネクションと同等のＰＤＮコネクションが確保できる場合は、ステップＳ２５０５からステップＳ２５０７を省略してもよい。
確立したＰＤＮコネクションのＱｏＳ情報を更新後、ＭＴＣデバイス１００はＰＤＮコネクションの確立を完了する（ステップＳ２５０９：ＰＤＮコネクション確立完了）。
なお、第９の実施の形態では、ＭＴＣデバイス１００が追加のＰＤＮコネクションを送信した際にネットワークが混雑状態を検出して、ＰＤＮコネクションの確立を拒絶しているが、例えば、他のＭＴＣデバイス１００やＵＥ１０５によるデータ送信などによる混雑発生を機に、例えば、同じＭＴＣグループや同じｅＮＢ１１０に接続しているＭＴＣデバイス１００など、複数のＭＴＣデバイス１００やＵＥ１０５に対して、ブロードキャストメッセージで、追加のＰＤＮコネクションの確立拒絶を通知してもよい。
次に、図２９を参照しながら、本発明の第９の実施の形態におけるＭＴＣデバイス１００の構成について説明する。図２９は、本発明の第９の実施の形態におけるＭＴＣデバイス１００の構成の一例を示す図である。
図２９において、ＭＴＣデバイス１００は、通信システム（例えば、Ｅ−ＵＴＲＡＮやＵＴＲＡＮ）と接続して下位レイヤにおける通信処理と上位レイヤでＩＰなどのパケット通信処理を実施する通信処理部２７０１、ＰＤＮコネクション確立リクエストの送信や確立したＰＤＮコネクションのＥＰＳベアラに割り当てられるＱｏＳ情報の更新、ＰＤＮコネクションのリリースなどを処理するＰＤＮコネクション処理部２７０２、確立済みＰＤＮコネクションのＱｏＳ情報と追加で確立するＰＤＮコネクションのＱｏＳ情報を比較するＱｏＳ情報比較部２７０３を少なくとも有する。なお、図２９には不図示だが、ＭＴＣデバイス１００は、追加のＰＤＮコネクションの優先度レベルと確立済みのＰＤＮコネクションの優先度レベルを比較する優先度レベル比較部を有していてもよい。
次に、図２９に図示されている構成を有するＭＴＣデバイス１００について、本発明における特徴的な処理を中心に、図３０を用いて詳しく説明する。
図３０において、ＭＴＣデバイス１００は、既にＰＤＮコネクションを１つ確立済みの状態であり、追加のＰＤＮコネクションの確立リクエストをＰＤＮコネクション処理部２７０２から通信処理部２７０１を介して、ネットワークに送信する（ステップＳ２８０１：ＰＤＮコネクション確立リクエスト送信）。
ＰＤＮコネクション確立リクエストを受信したネットワークでは、混雑状態を検出しているため、ＭＴＣデバイス１００は、３Ｇアクセスから送信されるＰＤＮコネクション確立拒絶レスポンスを受信する（ステップＳ２８０２：ＰＤＮコネクション確立拒絶レスポンス受信）。
追加ＰＤＮコネクションの確立を拒絶されたＭＴＣデバイス１００は、ＱｏＳ情報比較部２７０３にて、確立済みのＰＤＮコネクションのＥＰＳベアラに割り当てられているＱｏＳ情報と、追加で確立するＰＤＮコネクションのＥＰＳベアラに必要なＱｏＳ情報を比較する（ステップＳ２８０３：ＱｏＳ情報の比較）。なお、ＭＴＣデバイス１００は、優先度レベル比較部において、追加のＰＤＮコネクションの優先度レベルと確立済みのＰＤＮコネクションの優先度レベルを比較し、追加のＰＤＮコネクションの優先度レベルのほうが高いと判断した場合に、確立済みのＰＤＮコネクションの代わりとして追加のＰＤＮコネクションを確立できるか確認するために、ＱｏＳ情報の比較を行うようにしてもよい。
ステップＳ２８０３において比較した結果、追加で確立するＰＤＮコネクションのＱｏＳ情報が、確立済みのＰＤＮコネクションのＱｏＳ情報以下であれば（例えば、追加で確立するＰＤＮコネクションのＥＰＳベアラで必要なＧＢＲが４Ｍｂｐｓで、既に確立済みのＰＤＮコネクションのＥＰＳベアラのＧＢＲが５Ｍｂｐｓである場合など）、ＱｏＳ情報比較部２７０３からＰＤＮコネクション処理部２７０２に確立済みのＰＤＮコネクションをリリースするように指示し、通信処理部２７０１を介して、ＰＤＮコネクションをリリースするためのメッセージを送信する（ステップＳ２８０４：確立済みＰＤＮコネクションリリース）。このとき、ＭＴＣデバイス１００は、リリースするＰＤＮコネクションに割り当てられているリソース（例えば、通信リソースや帯域リソースなど）を他のＭＴＣデバイス１００やＵＥ１０５に割り当てないように指示するための識別子を送信するメッセージに格納する。
一方、ステップＳ２８０３において比較した結果、追加で確立するＰＤＮコネクションのＱｏＳ情報が、確立済みのＰＤＮコネクションのＱｏＳ情報より大きければ（例えば、追加で確立するＰＤＮコネクションのＥＰＳベアラで必要なＧＢＲが６Ｍｂｐｓで、既に確立済みのＰＤＮコネクションのＥＰＳベアラのＧＢＲが５Ｍｂｐｓである場合など）、確立済みのＰＤＮコネクションはリリースされることなく、維持される。
確立済みのＰＤＮコネクションをリリースしたＭＴＣデバイス１００は、ＰＤＮコネクション処理部２７０２から通信処理部２７０１を介して、追加のＰＤＮコネクションを確立する（ステップＳ２８０５：追加のＰＤＮコネクション確立）。この場合もステップＳ２８０４と同様に、ＭＴＣデバイス１００は、ネットワークが、ＰＤＮコネクションをリリースしたＭＴＣデバイス１００であることを識別できるような識別子を、追加のＰＤＮコネクション確立リクエストに格納する。
ＰＤＮコネクションを確立後、ＭＴＣデバイス１００は、デフォルトのＰＤＮコネクションのＱｏＳ情報から追加のＰＤＮコネクションが必要とするＱｏＳ情報に更新するため、非特許文献３で定義されるＵＥ ｒｅｑｕｅｓｔｅｄ ｂｅａｒｅｒ ｒｅｓｏｕｒｃｅ ｍｏｄｉｆｉｃａｔｉｏｎ ｐｒｏｃｅｄｕｒｅなどを用いて、更新する（ステップＳ２８０６：追加ＰＤＮコネクションのＱｏＳ情報を更新）。この場合もステップＳ２８０４と同様に、ＭＴＣデバイス１００は、ネットワークが、ＰＤＮコネクションをリリースしたＭＴＣデバイス１００であることを識別できるような識別子を、確立したＰＤＮコネクションのＱｏＳ情報の更新メッセージに格納する。
なお、ステップＳ２８０３のＱｏＳ情報の比較後、ＭＴＣデバイス１００が確立済みのＰＤＮコネクションをリリースし、ＰＤＮコネクションの確立処理をするのではなく、ＰＤＮコネクションＭｏｄｉｆｉｃａｔｉｏｎ ｐｒｏｃｅｄｕｒｅを実施し、ＭＴＣデバイス１００が要求するＰＤＮコネクションを実現できる場合は、ステップＳ２８０４及びステップＳ２８０５を省略してもよい。
なお、上記の第９の実施の形態では、ネットワークからＭＴＣデバイス１００に混雑状態に関する情報が通知され、ＭＴＣデバイス１００は確立済みのＰＤＮコネクション、若しくは、ＰＤＮコネクションのＥＰＳベアラに割り当てられているＱｏＳ情報と、追加のＰＤＮコネクションで必要なＱｏＳ情報を比較して、確立済みのＰＤＮコネクションをリリースすることで確保されるリソースを、新たなＰＤＮコネクションの確立に用いることができるか否かを判断している。このＱｏＳ情報に加えて、ＭＴＣデバイス１００は、ＭＴＣデバイス１００の確立可能なＰＤＮコネクション数を確立済みのＰＤＮコネクションをリリースする際の判断材料として用いてもよい。
この確立可能なＰＤＮコネクション数の情報を、例えば、ＭＴＣデバイス１００が、ＭＴＣのためにスタティックに格納している情報から取得してもよい、又は、ネットワークが任意のタイミング（例えば、混雑状態を検出したとき）でＭＴＣデバイス１００に確立可能なＰＤＮコネクション数をあらかじめ通知してもよい、又は、ＭＴＣデバイス１００は、確立済みのＰＤＮコネクションを確立した際にネットワークから「ＭＴＣデバイス１００が確立可能なＰＤＮコネクション数は１つ」という情報を取得してもよい、又は、ネットワークは、ＰＤＮコネクション確立拒絶レスポンスで、ＱｏＳ情報は通知することはできないが、「ＭＴＣデバイス１００が確立可能なＰＤＮコネクション数」の情報のみを通知できる場合は、ＭＴＣデバイス１００が追加のＰＤＮコネクションを確立する際に送信するＰＤＮコネクション確立リクエストの返信（ＰＤＮコネクション確立拒絶レスポンス）で、「ＭＴＣデバイス１００が確立可能なＰＤＮコネクション数は１つ」という情報を通知してもよい。
このように、ＱｏＳ情報と確立可能なＰＤＮコネクション数を組み合わせることにより、ネットワークは割り当て可能なリソースを精度高く制御することができる。例えば、ネットワークが、ＰＤＮコネクションを１つ確立済みのＭＴＣデバイス１００から、追加のＰＤＮコネクションの確立リクエストを受信した場合、ネットワークがＭＴＣデバイス１００に対して、ＰＤＮコネクション確立拒絶レスポンスを送信する。このとき、ＭＴＣデバイス１００は保持している確立可能なＰＤＮコネクション数の情報を用いて、現在確立しているＰＤＮコネクション数を確認し、さらに確立済みのＰＤＮコネクションが存在する場合、その確立済みのＰＤＮコネクション、若しくは、確立済みのＰＤＮコネクションのＥＰＳベアラに割り当てられているＱｏＳ情報（例えば、ＧＢＲ＝１Ｍｂｐｓ）と追加で確立するＰＤＮコネクションで必要なＱｏＳ情報（５００ｋｂｐｓ）を比較し、追加のＰＤＮコネクションで必要とされるＱｏＳ情報を満たすことができる場合、ＭＴＣデバイス１００は確立済みのＰＤＮコネクションをリリースし、追加のＰＤＮコネクションを確立することができる。
なお、ＭＴＣデバイス１００の保持する確立可能なＰＤＮコネクション数の情報とＰＤＮコネクション数を管理するＰＤＮコネクション処理部で情報共有（同期）がとれていない場合や、ＰＤＮコネクション確立拒絶レスポンスで取得できる情報（例えば、混雑レベルや現在の確立可能なＰＤＮコネクション数）を得る場合や、確立済みのＰＤＮコネクションより優先度レベルの高いＰＤＮコネクションの確立リクエストの場合があるため、ＭＴＣデバイス１００が保持する確立可能なＰＤＮコネクション数に既に確立済みのＰＤＮコネクションの数が達している状態にもかかわらず、ＭＴＣデバイス１００は追加のＰＤＮコネクション確立するためのＰＤＮコネクション確立リクエストを送信する可能性がある。
以上、本発明の第９の実施の形態によれば、既にＰＤＮコネクションを確立済みのＭＴＣデバイス１００が追加のＰＤＮコネクションを確立する際、ネットワークで混雑状態を検出している場合でも、確立済みのＰＤＮコネクションに割り当てられているＱｏＳ情報と追加で確立するＰＤＮコネクションに必要なＱｏＳ情報を比較し、追加で確立するＰＤＮコネクションに必要なＱｏＳ情報が、確立済みのＰＤＮコネクションに割り当てられているＱｏＳ情報を満たすことができる場合、ＭＴＣデバイス１００は確立済みＰＤＮコネクションをリリース又は変更し、追加のＰＤＮコネクションを確立することができる。これにより、ＭＴＣデバイス１００は優先度レベルが高いデータを送信することができ、ＭＴＣデバイス１００やＭＴＣサーバ１５０、ＭＴＣユーザ１６０などに優先度レベルが高いデータを送信できないなどの問題は解決される。
＜第１０の実施の形態＞
本発明の第１０の実施の形態では、既にＰＤＮコネクションを確立済みの状態で、さらに追加のＰＤＮコネクション確立を望むＭＴＣデバイス１００が、ネットワークから通知されるＭＴＣデバイス１００やＵＥ１０５に割り当て可能な通信リソースや帯域リソースの情報に基づいて、既に確立済みのＰＤＮコネクションをリリースし、追加のＰＤＮコネクションを確立する。
本発明の第１０の実施の形態では、既にＰＤＮコネクションを確立済みの状態で、さらに追加のＰＤＮコネクション確立を望むＭＴＣデバイス１００が、ネットワークから通知されるＭＴＣデバイス１００やＵＥ１０５に割り当て可能な通信リソースや帯域リソースの情報に基づいて、既に確立済みのＰＤＮコネクションをリリースし、追加のＰＤＮコネクションを確立する。
第１０の実施の形態で想定しているシナリオは、第９の実施の形態と同じである。第９の実施の形態との違いは、ＭＴＣデバイス１００が追加のＰＤＮコネクションを確立する際、確立済みのＰＤＮコネクション、又は、そのＰＤＮコネクションのＥＰＳベアラに割り当てられているＱｏＳ情報と、ネットワークから通知されるＭＴＣデバイス１００に割り当て可能なＱｏＳ情報（例えば、通信リソースや帯域リソース）を足し合わせたリソースが、新たに確立するＰＤＮコネクションに必要なリソースよりも大きい場合に、確立済みのＰＤＮコネクションをリリースすると判断する点である。以下、第９の実施の形態との違いを中心に詳しく説明する。
以下、本発明の第１０の実施の形態について、図３１、図３２、図３３Ａ〜図３３Ｅ、図３４〜図３６を用いて説明する。
ここで、本発明の第１０の実施の形態の説明を容易化するために、本発明の第１０の実施の形態におけるＭＴＣデバイス１００は、第９の実施の形態における前提と同様に、ネットワークと既にＰＤＮコネクションを１つ確立済みであり、確立済みのＰＤＮコネクション内のＥＰＳベアラに対して、ネットワークが保証するビットレート（ＧＢＲ：Guaranteed Bit Rate）は５Ｍｂｐｓとする。また、ＭＴＣデバイス１００は、追加のＰＤＮコネクションを確立するために、ＰＤＮコネクション確立リクエストを送信する。このとき、ＭＴＣデバイス１００は、既に確立済みのＰＤＮコネクションで送信されるデータの優先度より、追加で確立するＰＤＮコネクションで送信するデータの優先度レベルのほうが高いことを認識していることを前提としている。
“ＧＢＲ＝５Ｍｂｐｓ”が割り当てられたＥＰＳベアラを含むＰＤＮコネクションを確立済みであるＭＴＣデバイス１００が、追加のＰＤＮコネクションを確立する際、ネットワークから通知されるＱｏＳ情報に基づいて、確立済みのＰＤＮコネクションをリリースし、追加のＰＤＮコネクションを確立するＭＴＣデバイス１００の動作について、図３１を用いて説明する。
図３１において、“ＧＢＲ＝５Ｍｂｐｓ”が割り当てられたＥＰＳベアラを含むＰＤＮコネクションを確立済みであるＭＴＣデバイス１００が、追加のＰＤＮコネクションを確立しようとする状態を前提とする（ステップＳ２９００）。ＭＴＣデバイス１００は、追加のＰＤＮコネクションを確立するためにＰＤＮコネクション確立リクエストを送信する（ステップＳ２９０１：ＰＤＮコネクション確立リクエスト）。なお、図３１におけるステップＳ２９００及びＳ２９０１は、図２５におけるステップＳ２５００及びＳ２５０１と同じなので、ここでは詳細な説明を省略する。
続いて、混雑状態を検出したネットワークは、ＰＤＮコネクションの確立リクエストの送信元であるＭＴＣデバイス１００に割り当て可能なＱｏＳ情報（例えば、ＧＢＲ＜＝２Ｍｂｐｓなら許可など）を格納したＰＤＮコネクション確立拒絶レスポンスを送信する（ステップＳ２９０２：ＰＤＮコネクション確立拒絶レスポンス）。なお、ＧＢＲ以外のＱｏＳ情報として、図３２及び図３３Ａ〜図３３Ｅで示すように、ＱＣＩ（ＱｏＳ Ｃｌａｓｓ Ｉｎｄｉｃａｔｏｒ）、ＡＲＰ（Ａｌｌｏｃａｔｉｏｎ ａｎｄ Ｒｅｔｅｎｔｉｏｎ Ｐｒｉｏｒｉｔｙ）、ＭＢＲ（Ｍａｘｉｍｕｍ Ｂｉｔ Ｒａｔｅ）、Ｇｒｏｕｐ−ＡＭＢＲ（Ｇｒｏｕｐ−Ａｇｇｒｅｇａｔｅｄ Ｍａｘｉｍｕｍ Ｂｉｔ Ｒａｔｅ）、ＡＰＮ−ＡＭＢＲ（Ａｃｃｅｓｓ Ｐｏｉｎｔ Ｎａｍｅ−ＡＭＢＲ）、Ｔｒａｎｓｆｅｒ Ｄｅｌａｙ、Ｐａｃｋｅｔ Ｄｅｌａｙ Ｂｕｄｇｅｔ、Ｐａｃｋｅｔ Ｅｒｒｏｒ Ｌｏｓｓ Ｒａｔｅ、Ａｐｐｌｉｃａｔｉｏｎ ｐｒｉｏｒｉｔｙなどがある。
図３４は、３Ｇアクセスが、追加のＰＤＮコネクションに割り当て可能なＱｏＳ情報をＭＴＣデバイス１００に通知する際のメッセージのフォーマット例である。
図３４に図示されているメッセージは、従来のＰＤＮコネクション確立拒絶メッセージフィールドに加えて、ＭＴＣデバイス１００に割り当て可能なＱｏＳ情報を格納するＱｏＳ情報フィールド、ＱｏＳ情報フィールドに格納されている情報の有効時間（割り当て可能な時間）を示す有効期間フィールドで構成される。なお、有効期間フィールドは、本発明の第８の実施の形態で説明した待機時間と併用してもよい。
ネットワークからＭＴＣデバイス１００に割り当て可能なＱｏＳ情報を通知されたＭＴＣデバイス１００は、図３１で示すように、追加で確立するＰＤＮコネクションに必要なＱｏＳ情報が、既に確立済みのＰＤＮコネクションに割り当てられているＱｏＳ情報と、ステップＳ２９０２で通知されたＭＴＣデバイス１００に割り当て可能なＱｏＳ情報の合計以下であるか比較する（ステップＳ２９０３：ＱｏＳ比較）。
例えば、ＧＢＲで比較する場合には、図３３Ａで示すように、確立済みのＰＤＮコネクションのＥＰＳベアラに割り当てられているＧＢＲが１Ｍｂｐｓで、ネットワークからＰＤＮコネクション確立拒絶レスポンスで通知される追加ＰＤＮコネクションに割り当て可能なＧＢＲが０．５Ｍｂｐｓである場合は、ＭＴＣデバイス１００はＧＢＲが１．５Ｍｂｐｓ以下であれば、ＰＤＮコネクションを確立できる。すなわち、追加で確立するＰＤＮコネクションのＥＰＳベアラで必要とするＧＢＲが１．５Ｍｂｐｓ以下であれば、確立可能である。なお、このとき、確立済みのＰＤＮコネクションをリリースする必要があるときは、ＭＴＣデバイスが追加で確立するＰＤＮコネクションのＧＢＲが、「ネットワークから通知されるＧＢＲ＜追加で確立するＰＤＮコネクションのＧＢＲ＜ネットワークから通知されるＧＢＲと確立済みのＰＤＮコネクションのＥＰＳベアラに割り当てられているＧＢＲの合計」のときである。また、この具体例では、ネットワークからＭＴＣデバイス１００に通知される追加のＰＤＮコネクションに割り当て可能なＱｏＳ情報は、現在のＭＴＣデバイス１００に対して割り当て可能なＱｏＳ情報であるが、ＭＴＣデバイス１００が確立可能な絶対値を示すＱｏＳ情報を使用してもよい。例えば、ＧＢＲの場合、３Ｇアクセスから通知されるＭＴＣデバイス１００に割り当てられるＱｏＳ情報は、１．５Ｍｂｐｓ（確立済みＰＤＮコネクションのＥＰＳベアラに割り当てられているＧＢＲ（１Ｍｂｐｓ）＋追加のＰＤＮコネクションに割り当て可能なＧＢＲ（０．５Ｍｂｐｓ））として通知してもよい。
また、ＱＣＩで比較する場合には、図３３Ｂで示すように、ＭＴＣデバイス１００が追加で確立するＰＤＮコネクションのＱＣＩが、３Ｇアクセスから通知されるＭＴＣデバイス１００に割り当て可能なＱＣＩと一致している場合、ＭＴＣデバイス１００は追加のＰＤＮコネクションを確立できる。
また、詳しい説明は後述するが、ＱｏＳ情報に加えて、ＭＴＣデバイス１００が確立可能なＰＤＮコネクション数もＭＴＣデバイス１００に通知される場合（例えば、ＭＴＣデバイス１００は、一定時間（例えば、混雑時に通知される待機時間（Ｂａｃｋｏｆｆ ｔｉｍｅ））、合計１つのＰＤＮコネクションを確立可能）、ＭＴＣデバイス１００は確立済みのＰＤＮコネクションのＱＣＩを確認し、追加で確立するＰＤＮコネクションのＱＣＩと比較する。ＱＣＩが同じで、かつ、確立可能なＰＤＮコネクション数が１つである場合、ＭＴＣデバイス１００は、確立済みのＰＤＮコネクションをリリースすることで、追加のＰＤＮコネクションを確立できる。
なお、上記の説明例では、ＱｏＳ情報の比較処理を実施する際、ＧＢＲ、ＱＣＩを挙げているが、他のＱｏＳ情報に関する例も含めて、図３２にアクション、図３３Ａ〜図３３Ｅにアクション結果が図示されている。
また、ステップＳ２９０３のＱｏＳ比較を行う前に、本発明の第９の実施の形態で説明したように、追加のＰＤＮコネクション確立を拒絶されたＭＴＣデバイス１００は、追加のＰＤＮコネクションの優先度レベルと確立済みのＰＤＮコネクションの優先度レベルを比較した後に、ＱｏＳ比較を起こってもよい。なお、ＰＤＮコネクションの優先度レベルは、アプリケーションレイヤから取得できるアプリケーション毎に割り当てられる優先度レベルや、ＭＴＣデバイス１００が保持するポリシ、ＭＴＣデバイス１００がＭＴＣのためにスタティック（静的）に格納されている情報（例えば、最初に起動したアプリケーションを優先的に処理するなど）などを用いて取得してもよい。
続く、ステップＳ２９０３のＱｏＳ比較後、図３１のステップＳ２９０４からステップＳ２９０８は、図２５のステップＳ２５０５からステップＳ２５０９と同じなので、ここでは詳細な説明を省略する。
なお、上記の第１０の実施の形態では、ＭＴＣデバイス１００が追加のＰＤＮコネクションの確立リクエストに対するＰＤＮコネクション確立拒絶レスポンスで、ＭＴＣデバイス１００に割り当て可能なＱｏＳ情報を通知していたが、ネットワークはＭＴＣデバイス１００に割り当て可能なリソースが存在することから、ＰＤＮコネクション確立許可レスポンスで通知してもよい。その場合、ステップＳ２９０２のＰＤＮコネクション確立拒絶レスポンスは、ＰＤＮコネクション確立許可レスポンスに変わる。加えて、ステップＳ２９０３からステップＳ２９０６は省略でき、ステップＳ２９０７のＰＤＮコネクションＭｏｄｉｆｉｃａｔｉｏｎ ｐｒｏｃｅｄｕｒｅから実施可能となる。
なお、上記の第１０の実施の形態では、ネットワークからＭＴＣデバイス１００にＱｏＳ情報が通知されているが、ＱｏＳ情報に加えて、ＭＴＣデバイス１００の確立可能なＰＤＮコネクション数を通知してもよい。ＱｏＳ情報と確立可能なＰＤＮコネクション数を組み合わせることにより、ネットワークは割り当て可能なリソースを精度高く制御することができる。例えば、ネットワークが、ＰＤＮコネクションを１つ確立済みのＭＴＣデバイス１００から、追加のＰＤＮコネクションの確立リクエストを受信した場合、ネットワークがＭＴＣデバイス１００に対して、「ＭＴＣデバイス１００の確立可能なＰＤＮコネクション数は１つ」、かつ、「追加のＰＤＮコネクションに割り当て可能なＱｏＳ情報（ＧＢＲ）は、１Ｍｂｐｓ」のＱｏＳ情報をＰＤＮコネクション確立拒絶レスポンスに格納して送信する。このとき、ＭＴＣデバイス１００は「ＭＴＣデバイス１００の確立可能なＰＤＮコネクション数は１つ」という情報から、追加のＰＤＮコネクションを確立するためには、確立済みのＰＤＮコネクションをリリースする必要があることを確認できる。さらに、「追加のＰＤＮコネクションに割り当て可能なＱｏＳ情報（ＧＢＲ）は、１Ｍｂｐｓ」というＱｏＳ情報から、追加のＰＤＮコネクションで必要とされるＱｏＳ情報を満たせるか確認することができ、追加のＰＤＮコネクションで必要とされるＱｏＳ情報が、確立済みのＰＤＮコネクションに割り当てられているＱｏＳ情報以下である場合は、ＭＴＣデバイス１００は、確立済みのＰＤＮコネクションをリリースし、追加のＰＤＮコネクションを確立することができる。
以上、本発明の第１０の実施の形態によれば、既にＰＤＮコネクションを確立済みのＭＴＣデバイス１００が追加のＰＤＮコネクションを確立する際、ネットワークで混雑状態を検出している場合でも、ネットワークから通知されるＭＴＣデバイスに割り当て可能なＱｏＳ情報と、確立済みのＰＤＮコネクションに割り当てられているＱｏＳ情報と、追加で確立するＰＤＮコネクションに必要なＱｏＳ情報を比較し、追加で確立するＰＤＮコネクションに必要なＱｏＳ情報が、確立済みのＰＤＮコネクションに割り当てられているＱｏＳ情報を満たすことができる場合、ＭＴＣデバイス１００は確立済みＰＤＮコネクションをリリースし、追加のＰＤＮコネクションを確立することができる。これにより、ＭＴＣデバイスは優先度レベルが高いデータを送信することができ、ＭＴＣデバイス１００やＭＴＣサーバ１５０、ＭＴＣユーザ１６０などに優先度レベルが高いデータを送信できないなどの問題は解決される。
上記の本発明の第９の実施の形態と第１０の実施の形態では、ＭＴＣデバイス１００による確立済みのＰＤＮコネクションの接続先と、追加で確立するＰＤＮコネクションの接続先が同じであることを前提としている。
ここで、図３５ではＭＴＣデバイス１００が複数の接続先とＰＤＮコネクションを確立できる状態を示している。図３５におけるＭＴＣデバイスＡ１００Ａは、例えば、複数のＭＴＣサーバ１５０に接続することができ、１つ目のＰＤＮコネクション（確立済みのＰＤＮコネクション）の接続先はＭＴＣサーバＡ１５０Ａで、２つ目のＰＤＮコネクション（追加で確立するＰＤＮコネクション）の接続先はＭＴＣサーバＢ１５０Ｂになる場合がある。
ＭＴＣデバイスＡ１００Ａの接続先が異なる場合、本発明の第９の実施の形態と第１０の実施の形態におけるＰＤＮコネクションの確立拒絶レスポンスを受信した後の処理ステップとして、接続先を確認する処理が必要となる。
図３６は、図２５のステップＳ２５０２とステップＳ２５０３の間に接続先を確認する処理ステップを追加したものである。また、図３５におけるＭＴＣデバイスＡ１００Ａと図３６におけるＭＴＣデバイスＡ１００Ａは同一であるとする。
ＭＴＣサーバＡ１５０Ａにデータを送信するためのＰＤＮコネクションを確立済みのＭＴＣデバイスＡ１００Ａが、ＭＴＣサーバＢ１５０Ｂにデータを送信するためのＰＤＮコネクションを確立するためのＰＤＮコネクション確立リクエストをネットワーク送信する（ステップＳ２５０１）。ＭＴＣサーバＢにデータを送信するためのＰＤＮコネクション確立リクエストを受信したネットワークは、（Ａ）混雑発生によって、ＰＤＮコネクション確立拒絶レスポンスを送信する（ステップＳ２５０２）。
ここで、ＭＴＣデバイスＡ１００Ａは、確立済みのＰＤＮコネクションをリリースして、追加のＰＤＮコネクションを確立することができるかを判断するための処理として、確立済みのＰＤＮコネクションの接続先と、追加のＰＤＮコネクションの接続先が同じであるか否かを確認する（ステップＳ２５２０）。接続先を表す情報としては、ＡＰＮを用いることができる。つまり、ＡＰＮが同じであれば接続先が同じであると判断し、ＡＰＮが異なれば接続先が異なると判断する。
確立済みのＰＤＮコネクションの接続先と追加のＰＤＮコネクションの接続先が同じである場合は、引き続き、第９の実施の形態と同様の処理（図２５のステップＳ２５０３以降の処理）や第１０の実施の形態と同様の処理（図３１のステップＳ２９０３以降の処理）を行う。
しかしながら、確立済みのＰＤＮコネクションの接続先と追加のＰＤＮコネクションの接続先が異なる場合、例えば、追加のＰＤＮコネクション確立リクエストを受信したＭＴＣサーバＢ１５０Ｂでは混雑検出されているが、ＭＴＣデバイスＡ１００Ａによって既に確立済みのＰＤＮコネクションを通してデータを転送されているＭＴＣサーバＡ１５０Ａでは混雑検出されていない（混雑が起こっていない）場合には、確立済みのＰＤＮコネクションをリリースすることで確保されるリソースを、追加のＰＤＮコネクションの確立に再使用することができないと判断する。なお、追加のＰＤＮコネクション確立リクエストが拒絶されている理由は、ＭＴＣサーバＢ１５０Ｂにおける混雑検出以外に、ネットワーク（通信システム）のエンティティであるＳＧＷ−Ｂ１３０ＢやＰＧＷ−Ｂ１４０Ｂなどで起きている輻輳であってもよい。
ここで、ＭＴＣサーバＡ１５０Ａにおいて混雑状態が起きていない状態で、ＭＴＣデバイスＡ１００Ａによって送信された追加のＰＤＮコネクション確立リクエストが、ＭＴＣサーバＢ１５０Ｂの混雑状態により拒絶された場合、ＭＴＣデバイスＡ１００Ａは、ＭＴＣサーバＡ１５０Ａにデータを送信するためのＰＤＮコネクションをリリースしても、ＭＴＣサーバＢ１５０Ｂに送信するためのＰＤＮコネクションを確立できない。そのため、ＭＴＣデバイスＡ１００Ａは、確立済みのＰＤＮコネクションを維持し、追加のＰＤＮコネクションの確立をキャンセルする。
また、確立済みのＰＤＮコネクションの接続先と追加のＰＤＮコネクションの接続先が異なる状態でも、ＭＴＣデバイスＡ１００Ａが拒絶された追加のＰＤＮコネクションの接続先を変更できる場合（例えば、ＭＴＣサーバＡ１５０ＡとＭＴＣサーバ１５０Ｂが同じオペレータによる管轄、若しくは、ＭＴＣユーザ１６０に接続されている場合や、ＭＴＣサーバ１５０ＡとＭＴＣサーバＢ１５０Ｂ間でＰＤＮコネクション移行の契約が交わされており、交渉を自動的に実施するなど）、ＭＴＣデバイスＡ１００Ａは、追加で確立するＰＤＮコネクションの接続先を変更する。続いて、ＭＴＣデバイスＡ１００Ａは、確立済みのＰＤＮコネクションの接続先であるＭＴＣサーバＡ１５０ＡとのＰＤＮコネクションをリリースし、ＭＴＣサーバＡ１５０Ａにデータを転送するための追加のＰＤＮコネクションを確立する。なお、追加のＰＤＮコネクションの接続先を変更する処理と確立済みのＰＤＮコネクションの接続先であるＭＴＣサーバＡ１５０ＡとのＰＤＮコネクションをリリースする処理は順不同である。
なお、この接続先はＭＴＣサーバ１５０やＭＴＣユーザ１６０のアドレスやＩｄｅｎｔｉｔｙ（例えば、ＭＴＣサーバ ＴＥＩＤ）、ネットワーク（通信システム）の装置であるＰＧＷのアドレスやＩｄｅｎｔｉｔｙ（例えば、ＰＧＷ ＴＥＩＤ）、ＡＰＮなど接続先を識別できるものでもよい。
また、上記の実施の形態（特に第２〜第８の実施の形態）における逆イベント通知メッセージ（イベント情報）や送信制御メッセージには、イベント情報（例えば、デバイスＩＤやデバイス種ＩＤ）が格納されていたが、ｅＮＢ ＩＤやｅＮＢアドレス（並びに、ＭＴＣデバイス１００のＥＰＳベアラに対応するS1-U TEID）、イベント通知メッセージ（イベント情報）＠デバイスＡの送信元であるＭＴＣデバイスＡ１００Ａのアドレスや、ＭＴＣサービスで管理されている情報（例えば、ＭＴＣデバイスＡ１００Ａが位置する情報（例えば、３階、３０１号室、３丁目など））を追加することで、逆イベント通知メッセージ（イベント情報）を受信したＭＴＣデバイス１００がモード遷移する必要があるかどうかを判断させてもよい。
なお、本発明を説明する一例として、煙センサに通信モジュールを実装したＭＴＣデバイスＡ１００Ａが、煙を検知した後に起こりうる冗長のイベント通知メッセージに対する抑制方法について説明したが、以下のケースにも適用可能である。
例えば、ガス管の状態（例えば、破損していないか）を確認するガス管センサに通信モジュールを実装した複数のＭＴＣデバイスＡ１００Ａと主に居住スペースに配置されるガス漏れを検知するガスセンサに通信モジュールを実装した複数のＭＴＣデバイスＢ１００Ｂが、同じＭＴＣグループで構成されている環境において、ガス管が破損することにより、ＭＴＣデバイスＡ１００Ａによって通知されるイベント通知メッセージ（イベント情報）＠デバイスＡを利用して、ＭＴＣデバイスＢ１００Ｂのイベント通知メッセージを抑制してもよい。すなわち、ＭＴＣデバイスＡ１００Ａからイベント情報（例えば、ガス管センサＩＤ）が格納されたイベント通知メッセージ（イベント情報）＠デバイスＡを受け、ネットワーク装置（例えば、ＭＭＥ１２０やＭＴＣサーバ１５０）が、イベント情報（例えば、ガス管センサＩＤ）を格納した逆イベント通知メッセージをＭＴＣグループに属するＭＴＣデバイス１００に送信し、ＭＴＣデバイス１００がモード遷移する必要があるか（優先度の高いイベント通知メッセージを送信するか）判断させてもよい。このようなＭＴＣサービスに本発明を適用した場合、ガス管が破損することによって生じると予想されるガス管破損の誘発やガス漏れに対して、イベント（例えば、ガス管破損やガス漏れ）を検知した複数のＭＴＣデバイス１００による冗長な優先度の高いイベント通知メッセージを抑制することができ、ＭＴＣデバイス１００とネットワーク装置（例えば、ＭＭＥ１２０やＭＴＣサーバ１５０）の処理負荷を軽減、トラフィックを低減することができる。
また、例えば、エアバックと連動している衝撃センサを搭載済の乗用車に通信モジュールを実装したＭＴＣデバイス１００が、複数台の衝突事故（例えば、複数台による玉突き事故）を起こした場合、最初にネットワーク装置（例えば、ＭＭＥ１２０やＭＴＣサーバ１５０）に通知された優先度の高いイベント通知メッセージを利用して、後続する優先度の高いイベント通知メッセージを抑制してもよい。すなわち、ネットワーク装置（例えば、ＭＭＥ１２０やＭＴＣサーバ１５０）が、最初に受信したイベント通知メッセージのイベント情報（例えば、衝撃センサＩＤ）を格納した逆イベント通知メッセージを衝突事故が起きたエリア（例えば、イベント通知メッセージが送信されたｅＮＢ１１０配下）のＭＴＣデバイス１００にブロードキャストすることで、同一イベント、若しくは、そのイベントを引き起こした出来事によって引き起こされたイベントによる優先度の高いイベント通知メッセージを抑制することができる。このようなＭＴＣサービスに本発明を適用した場合、衝撃センサを搭載した複数台の乗用車の衝突事故が発生した際に高い確率で生じる冗長な優先度の高いイベント通知メッセージを抑制することができ、ＭＴＣデバイス１００とネットワーク装置（例えば、ＭＭＥ１２０やＭＴＣサーバ１５０）の処理負荷を軽減、トラフィックを低減することができる。
また、例えば、土砂崩れを監視する加速度センサや傾斜センサに通信モジュールを実装したＭＴＣデバイス１００が、土砂崩れが起こりそうなエリア（例えば、山や崖）に複数設置されている環境において、土砂崩れが起こることにより、ＭＴＣデバイス１００によって通知されるイベント通知メッセージを利用して、後続する優先度の高いイベント通知メッセージを抑制してもよい。すなわち、ＭＴＣデバイス１００からイベント情報（例えば、加速度センサＩＤ）が格納されたイベント通知メッセージ（イベント情報）を受け、ネットワーク装置（例えば、ＭＭＥ１２０やＭＴＣサーバ１５０）が、イベント情報（例えば、加速度センサＩＤ）を格納した逆イベント通知メッセージをＭＴＣグループに属するＭＴＣデバイス１００に送信し、ＭＴＣデバイス１００がモード遷移する必要があるか（優先度の高いイベント通知メッセージを送信するか）判断させてもよい。また、このような、あらかじめ単一の事象のみ監視するＭＴＣサービスであることが定義されている環境においては、イベント情報（例えば、加速度センサＩＤ）を含めなくても、何のイベントが発生したか明らかであるため、省略してもよい。
また、例えば、振動センサに通信モジュールを実装したＭＴＣデバイスによる陸橋の揺れ具合の監視から陸橋に異常がないか確認するＭＴＣサービスなども同様に、本発明は適用可能である。
なお、上記の本発明の各実施の形態では、ＭＴＣデバイス１００から通知されるイベント通知メッセージをトリガとして、ネットワーク装置（例えば、ＭＭＥ１２０やＳＧＷ１３０、ＰＧＷ１４０、ＭＴＣサーバ１５０）が冗長なイベント通知メッセージを抑制するための逆イベント通知メッセージをブロードキャストしていたが、イベント通知メッセージではなく、例えば、ＭＴＣデバイス１００とＭＴＣデバイス１００に組み込まれているＵＩＣＣ（Universal Integrated Circuit Card）の関連性の不一致を検知した場合や、ＭＴＣデバイス１００上で機能しているＭＴＣ ｆｅａｔｕｒｅとＨＳＳが保持するＭＴＣデバイス１００のサブスクリプションデータに登録されているＭＴＣ ｆｅａｔｕｒｅの整合が取れない場合や、設置場所が限定、若しくは、固定されているＭＴＣデバイス１００（例えば、自動販売機、煙センサ、炎センサ）、つまり、ＭＴＣデバイス１００の位置情報の変化が起こりにくい環境（通信環境の変化や、基地局の負荷バランスによってＭＴＣデバイス１００の接続する基地局切り替えは除く）で、ＭＴＣデバイス１００の位置情報の変化を検知した場合や、ＭＴＣデバイス１００とネットワークの間のＰＤＮコネクション、又は、ＥＰＳベアラが切断された場合などをトリガとして、逆イベント通知メッセージをブロードキャストしてもよい。
また、上記の本発明の各実施の形態では、ＭＴＣデバイス１００から送信されたイベント通知メッセージを受信したネットワーク装置（例えば、ＭＭＥ１２０、ＳＧＷ１３０、ＰＧＷ１４０、ＭＴＣサーバ１５０）は、イベント通知メッセージの内容を他のネットワーク装置に転送していたが（例えば、本発明の第２の実施の形態では、イベント通知メッセージを受信したＭＭＥ１２０が、ＳＧＷ１３０、ＰＧＷ１４０を経由してＭＴＣサーバ１５０にイベント通知メッセージを転送、若しくは、必要な情報のみを転送している）、オペレータの方針やＭＴＣアプリケーションの仕様などに基づいて、転送しなくてもよい。
また、上記の本発明の各実施の形態では、ＭＴＣデバイス１００がネットワークとの間にＰＤＮコネクションとＥＰＳベアラを確立した後にイベントを検知していたが、イベントを検知した後にＰＤＮコネクションとＥＰＳベアラを確立し、イベント情報やセンシング情報を送信してもよい。
また、上記の本発明の各実施の形態では、逆イベント通知メッセージを送信するネットワーク装置は、ＭＭＥ１２０やＰＧＷ１４０、ＭＴＣサーバ１５０を例として挙げて説明していたが、これらに限定されるわけではなく、ＳＧＷ１３０や外部のネットワークに位置する装置（例えば、ローミング先のネットワーク装置やＡＡＡサーバ、ＳＩＰサーバ）が送信してもよい。
また、上記の本発明の各実施の形態では、イベント通知メッセージを受信したネットワーク装置（例えば、ＭＭＥ１２０、ＳＧＷ１３０、ＰＧＷ１４０、ＭＴＣサーバ１５０）が逆イベント通知メッセージをブロードキャストしていたが、例えば、ネットワーク装置（例えば、ＭＭＥ１２０、ＳＧＷ１３０、ＰＧＷ１４０、ＭＴＣサーバ１５０）がＭＴＣデバイス１００の接続先である基地局（ｅＮＢ１１０）に逆イベント通知メッセージをブロードキャストするように指示し、ｅＮＢ１１０が逆イベント通知メッセージをブロードキャストしてもよい。例えば、現在規定されているようにｅＮＢがページングをブロードキャストし、ＵＥ１０５にＥＴＷＳの情報を取得させる手段を利用、拡張することで、既存システムに大きな影響を与えることなく、本発明を実施することができる。
また、上記の本発明の各実施の形態では、イベント通知メッセージを受信したネットワーク装置（例えば、ＭＭＥ１２０、ＳＧＷ１３０、ＰＧＷ１４０、ＭＴＣサーバ１５０）は、逆イベント通知メッセージをブロードキャストして、冗長なイベント通知メッセージを抑制していたが、他の役割を持たせたメッセージをブロードキャストしてもよい。例えば、特定のエリアに複数の自動販売機（ＭＴＣデバイス１００）が設置されている環境で、例えば、窃盗によって１つの自動販売機の位置情報が変化したことをネットワーク側が検知した場合、ネットワーク装置は自動販売機の位置情報変化をトリガとして、上記特定のエリアの複数の自動販売機に対して、各自動販売機の位置情報を送信すること（Tracking Area Update）を指示したメッセージをブロードキャストしてもよい。これにより、他の自動販売機の状況を定期的に実施される位置情報の更新時より迅速、かつ、確実に確認することができる。
また、上記の本発明の各実施の形態では、イベント通知メッセージを受信したネットワーク装置（例えば、ＭＭＥ１２０、ＳＧＷ１３０、ＰＧＷ１４０、ＭＴＣサーバ１５０）は、逆イベント通知メッセージをブロードキャストしていたが、逆イベント通知メッセージを送信するＭＴＣデバイス１００を把握している場合には、マルチキャストやユニキャストで実施してもよい。
なお、上記の本発明の各実施の形態の説明で用いた各機能ブロックは、典型的には集積回路であるＬＳＩ（Large Scale Integration）として実現される。これらは個別に１チップ化されてもよいし、一部又はすべてを含むように１チップ化されてもよい。なお、ここでは、ＬＳＩとしたが、集積度の違いにより、ＩＣ（Integrated Circuit）、システムＬＳＩ、スーパーＬＳＩ、ウルトラＬＳＩと呼称されることもある。
また、集積回路化の手法はＬＳＩに限るものではなく、専用回路又は汎用プロセッサで実現してもよい。ＬＳＩ製造後に、プログラムすることが可能なＦＰＧＡ（Field Programmable Gate Array）や、ＬＳＩ内部の回路セルの接続や設定を再構成可能なリコンフィギュラブル・プロセッサを利用してもよい。
さらには、半導体技術の進歩又は派生する別技術によりＬＳＩに置き換わる集積回路化の技術が登場すれば、当然、その技術を用いて機能ブロックの集積化を行ってもよい。例えば、バイオ技術の適応などが可能性としてあり得る。
本発明は、通信ノード（ＭＴＣデバイス１００）がイベント検知の情報を、高い優先度のメッセージを用いてネットワーク側のサーバ（ＭＴＣサーバ１５０）へ送信する環境において、周辺の他の通信ノードが同一の出来事、若しくは、その出来事によって引き起こされたイベントを検知した際に、高優先度モードでイベント通知メッセージを送信しないよう抑制し、ＭＴＣサーバ及び通信システムのエンティティ（ｅＮＢ、ＭＭＥ、ＳＧＷ、ＰＧＷなど）の処理負荷やネットワークにおけるトラフィック量を低減させるという効果を有する。また、ネットワーク側で混雑状況が検知された場合に、ＭＴＣサーバ及び通信システムのエンティティ（ｅＮＢ、ＭＭＥ、ＳＧＷ、ＰＧＷなど）の処理負荷やネットワークにおけるトラフィック量を低減させるという効果を有する。特に、複数の通信ノード（ＭＴＣデバイス１００）がグループ化（ＭＴＣグループ化）されている環境において、有効である。このように、本発明は、緊急性の高いイベント通知メッセージを高優先度モードで送信することが可能な通信技術やネットワークにおける混雑状況を緩和する通信技術に適用可能であり、特に、一機能としてＰＡＭの送信機能や時間制御機能（耐時間性機能）が定義されているＭＴＣの技術に適用可能である。
本発明は、ネットワークにメッセージを送信する際に、メッセージの送信の判断を行う接続確立方法及び通信ノードに関し、特にＭＴＣ（Machine Type Communications、Ｍ２Ｍ（Machine to Machine）通信とも呼ばれる）における通信ノード（以降、ＭＴＣデバイスと呼ぶ）がイベントを検知して、ネットワークにメッセージを送信する際にメッセージの送信の判断を行う接続確立方法及び通信ノードに関する。
現在、携帯電話（User Equipment：ＵＥ）に用いる技術の標準化団体である３ＧＰＰ（The third Generation Partnership Project）では、ＭＴＣで用いられる技術の標準化が行われている（下記の非特許文献１、２を参照）。ＭＴＣは、ＭＴＣデバイス（例えば、自動販売機や街頭広告ディスプレイ、煙センサ、セキュリティカメラ、人感センサなどの装置や機械に組み込まれた通信モジュール、又は、その総称）と、ＭＴＣデバイスによる通信の制御や、状態管理、またアプリケーションサービス（ＭＴＣサービスとも呼ぶ）を提供するサーバであるＭＴＣサーバ、さらにＭＴＣデバイスやＭＴＣサーバに対して、アプリケーションの制御や管理を実施するＭＴＣユーザから構成される。ＭＴＣでは、従来のＵＥのためのモビリティ制御（移動制御や移動管理、位置管理とも呼ぶ）などの既存機能を活用することを目的として、ＧＥＲＡＮ（GSM EDGE Radio Access Network）やＵＴＲＡＮ（Universal Terrestrial Radio Access Network）、Ｅ−ＵＴＲＡＮ（Evolved UTRAN）などの３ＧＰＰの規格に基づくアクセスネットワーク（以降、通信システムと呼ぶ）の使用を前提とする。つまり、ＭＴＣデバイスは、通信システム内で従来のＵＥと共存しながら通信を行う。ここで、ＵＥは人がユーザインタフェースを通じて操作する移動端末であり、ＭＴＣデバイスは人が直接操作するものではなく、端末又は装置に埋め込まれており、通信システムを介して操作するものとする。ＭＴＣ通信ネットワークの構成の一例を図１に示す。
図１には、ＭＴＣデバイス１００、ＵＥ１０５、ＭＴＣデバイス１００やＵＥ１０５と無線接続する基地局（Ｅ−ＵＴＲＡＮではｅＮＢ（eNode B）、ＵＴＲＡＮではＮＢ（Node B）と呼ばれる）１１０、Ｅ−ＵＴＲＡＮ１１５上のＭＴＣデバイス１００やＵＥ１０５の移動管理を担当するＭＭＥ（Mobility Management Entity）１２０、ＭＴＣデバイス１００やＵＥ１０５のＥ−ＵＴＲＡＮ１１５に対するユーザデータ配信制御を行うＳＧＷ（Serving Gateway、ＭＡＧ（Mobility Anchor Gateway：モビリティアンカポイント）などとも呼ばれる）１３０、ＭＴＣデバイス１００やＵＥ１０５に対するアドレス割り当てやＰＤＮ（Packet Data Network）１５５とＳＧＷ１３０間のユーザデータ転送並びに経路制御を行うＰＧＷ（Packet Gateway、ＨＡ（Home Agent：ホームエージェント）やＬＭＡ（Local Mobility Anchor：ローカルモビリティアンカ）などとも呼ばれる）１４０、ＭＴＣデバイス１００やＵＥ１０５のサブスクリプションデータ（Subscription data）並びに通信コンテキストなどを管理保持しているＨＳＳ（Home Subscriber Server）１２５、ＭＴＣデバイス１００による通信の制御や状態管理、アプリケーションサービスを提供するサーバであるＭＴＣサーバ１５０、ＭＴＣデバイス１００やＭＴＣサーバ１５０に対してアプリケーションの管理・制御やアプリケーションデータの管理を実施するＭＴＣユーザ１６０から構成されるネットワーク構成の一例が図示されている。
図１において、ＭＴＣデバイス１００が通信システムを介してＭＴＣサーバ１５０（サービスを提供するサーバ）と通信を行う際、ＭＴＣデバイス１００は、ＰＧＷ１４０とＰＤＮコネクション及びＥＰＳベアラを確立する（下記の非特許文献３を参照）。ＭＴＣデバイス１００が取得したデータ（例えば、煙センサにおける煙検知情報などのセンシングデータ）は、確立したＰＤＮコネクション及びＥＰＳベアラを通じてＰＧＷ１４０に送信され、ＰＧＷ１４０からＭＴＣサーバ１５０に転送される。ＭＴＣサーバ１５０は、ＭＴＣデバイス１００から送られてきたデータを、定義されたタイミング（例えば、ＭＴＣデバイス１００からデータ受信後、又は、ＭＴＣユーザ１６０からのリクエストメッセージ受信後など）で、ＭＴＣユーザ１６０に提供する。
ＭＴＣデバイス１００が取得したデータをＭＴＣサーバ１５０に送信するタイミングは、ＭＴＣデバイス１００が搭載する特徴（ＭＴＣ Ｆｅａｔｕｒｅ、以下、ＭＴＣの機能と記載することもある）や通信システムオペレータの指示、ＭＴＣサービスの内容によって決まる。例えば、ＭＴＣデバイス１００が非特許文献１で定義されているＭＴＣの機能の１つである“Ｔｉｍｅ Ｃｏｎｔｒｏｌｌｅｄ”（時間制御）を搭載する場合、すなわち、ＭＴＣデバイス１００が通信動作を実施する時間が制限されている場合、ＭＴＣデバイス１００は、所定の時間（例えば通信システムオペレータから割り当てられたり、ＭＴＣユーザ１６０が設定したりする）に限り、ＭＴＣサーバ１５０へのアクセスが許可され、取得したデータを送信する。また、ＭＴＣデバイス１００が非特許文献１で定義されている“ＰＡＭ（Priority Alarm Message）”を搭載する場合、すなわち、ＭＴＣデバイス１００が優先度の高いメッセージをＭＴＣサーバ１５０／ＭＴＣユーザ１６０に送信できる場合、ＭＴＣデバイス１００がイベント（例えば、煙検知、炎検知、盗難など）を検知時に、他のメッセージより優先的にメッセージを送信し、ＭＴＣサーバ１５０に転送される。なお、ＰＡＭは緊急情報通知にも相当するため、アプリケーション設定や通信オペレータのポリシにより、上記“Ｔｉｍｅ Ｃｏｎｔｒｏｌｌｅｄ”による制約を受けることなく、任意のタイミングでも送信を許可される場合がある。
また、その他の非特許文献１で定義されるＭＴＣの機能として、“Ｇｒｏｕｐ ｂａｓｅｄ”をＭＴＣデバイス１００が搭載する場合、すなわち、ＭＴＣサーバ１５０／ＭＴＣユーザ１６０、又は、通信システムのオペレータの要望（例えば、ＭＴＣデバイス１００の管理を容易化、又は、ＩＭＳＩ（International Mobile Subscriber Identity）の共有化など）の下、複数のＭＴＣデバイス１００を管理する場合、複数のＭＴＣデバイス１００を１つのグループ（以降、ＭＴＣグループと呼ぶ）として扱うことで、例えばＨＳＳ１２５は、通常ＭＴＣデバイス１００毎に管理保持するサブスクリプションデータの全体あるいは一部を、ＭＴＣグループ単位に集約して管理保持することができる。
ＭＴＣデバイス１００が“Ｌｏｗ ｍｏｂｉｌｉｔｙ”を搭載している場合、すなわちＭＴＣデバイス１００が限られた範囲でしか移動しない（例えば、所定のＴＡ（Tracking Area）やセル範囲に限定して移動する）、あるいは自動販売機のように装置として固定される場合、位置情報を更新するための、例えば、ＴＡＵ（Tracking Area Update）やＲＡＵ（Routing Area Update）の実施頻度をＵＥ１０５と比較して抑えることができ、ＭＴＣデバイス１００と移動管理を行う通信ノード（例えば、ＭＭＥ１２０やＰＧＷ１４０など）におけるモビリティ制御による負荷を軽減できる。
このように、ＭＴＣデバイスは、ＭＴＣユーザ１６０の要求に基づいて、ＭＴＣの機能（Ｆｅａｔｕｒｅ）を複数搭載することができる。また、ＭＴＣデバイス１００とＭＴＣサーバ１５０／ＭＴＣユーザ１６０との間の需要に応じて、ＭＴＣデバイス１００が有するＭＴＣの機能を有効化（Ａｃｔｉｖａｔｅ）／無効化（Ｄｅａｃｔｉｖａｔｅ）することができる（機能や動作の有効化／無効化）。
従来のＵＥ１０５と比較した場合、膨大な数のＭＴＣデバイス１００が通信システムを介して同時に通信を行うことが想定されるため、ＵＥ１０５による通信を妨害しないためにも、ＭＴＣデバイス１００による通信に対応し得るネットワークの改良が必要である。
3GPP TS 22.368 V1.1.1，November 2009
3GPP TR 23.888 V0.1.1，December 2009
3GPP TS 23.401 V9.3.0，December 2009
3GPP TS 33.402 V9.2.0，December 2009
3GPP TS 36.300 V9.2.0，December 2009
3GPP TR 23.888 V0.4.1，June 2010
しかしながら、従来の通信システムでは、複数のＭＴＣデバイスがイベントを検知し、優先度の高いイベント通知メッセージを送信する場合に課題が生じる。以下、図２を参照しながら説明する。
なお、ここでは、シナリオとして、非特許文献１で定義される、ＭＴＣの機能のうち、“Ｔｉｍｅ ｃｏｎｔｒｏｌｌｅｄ”と“ＰＡＭ”、“Ｇｒｏｕｐ ｂａｓｅｄ”、“Ｌｏｗ ｍｏｂｉｌｉｔｙ”を搭載する複数のＭＴＣデバイス１００（例えば、煙センサ、炎センサ、人感センサ）が１つのＭＴＣグループを形成し、マンション群のセキュリティを監視している環境において、マンション火災が発生する場合を考える。このとき、あるＭＴＣデバイス１００（例えば、煙センサ）が火災発生を認識する発端となるイベント（煙）を検知し（煙発生）、その後、他のＭＴＣデバイス（例えば、人感センサ）がイベント（人の有無）を検知する。
まず、煙センサに搭載されたＭＴＣデバイス（ＭＴＣデバイスＡ１００Ａ）はＭＴＣサーバ１５０と通信するためのＰＤＮコネクションを確立する（図２のステップＳ２００１：ＰＤＮコネクション確立済み）。なお、ＭＴＣデバイスＢ１００Ｂも、同様にＰＧＷ１４０とＰＤＮコネクションを確立する（図２のステップＳ２００４：ＰＤＮコネクション確立済み）。
ＭＴＣデバイスＡ１００Ａ（煙センサ）がイベント（煙）を検知したとする（図２のステップＳ２００２：イベント検知）。イベントを検知したＭＴＣデバイスＡ１００Ａは、ＰＡＭを用いて、煙を検知したことをＭＴＣサーバ１５０に通知する（図２のステップＳ２００３：イベント通知メッセージ＠デバイスＡ）。
一方、他の箇所に設置された複数のＭＴＣデバイスＢ１００Ｂ（他の煙センサや、炎センサなど）も火災発生を検知し（図２のステップＳ２００５）、火災発生を検知したことを、優先度の高いイベント通知メッセージ（例えば、ＰＡＭ）を用いて報告する（図２のステップＳ２００６）。例えば、他の煙センサも同様に煙を検出し、他の煙センサに搭載されたＭＴＣデバイスＢ１００Ｂも、煙の検出を優先度の高いイベント通知メッセージ（例えば、ＰＡＭ）を用いて報告する。また、例えば炎センサが、炎から発せられる紫外線を検出し、炎センサに搭載されたＭＴＣデバイスＢ１００Ｂが、ＭＴＣサーバ１５０に対して、炎から発せられる紫外線を検出したことを優先度の高いメッセージで通知することも考えられる。なお、他の煙センサや炎センサの設置数は膨大な数になることもある。
その結果、既存の通信システムでは、ＭＴＣサーバ１５０が最初のＭＴＣデバイスＡ１００ＡからのＰＡＭによって既に火災発生を検知できているにもかかわらず、同様に火災発生を検知した多数のＭＴＣデバイスＢ１００ＢからもＰＡＭを受信して、受信した全てのＰＡＭを処理しなければならなくなる。その結果、ＭＴＣサーバ１５０における処理負荷やネットワークのトラフィック負荷が増加してしまうことになる。また、火災発生を検出した後に必要とされるイベント検知（例えば、上記では人の有無）の送受信が遅延したり欠損したりすることにより、災害に迅速に対応できないといった問題も考えられる。
同様の問題は、例えば、工場に設置された複数のガスセンサが、ガス漏れを検知したことを、ＰＡＭを用いてＭＴＣサーバ１５０に送信するようなシナリオでも起こり得る。すなわち、この場合も、冗長な処理負荷やネットワークのトラフィック負荷が増加してしまう。
すなわち、多数のＭＴＣデバイス１００が設置されている環境においては、あるＭＴＣデバイス１００が、イベント（煙の発生）を検知したことを優先的にネットワーク側へ通知することで、そのイベントの通知からある出来事（例えば、火災発生）が起こっていることをネットワーク側で把握できるにもかかわらず、多数のＭＴＣデバイス１００から同様に高優先度モードにて通知されてくるイベント通知メッセージ（冗長なイベント通知メッセージ）を処理しなければならず、処理負荷が増加するという問題がある。また、多数のイベント通知メッセージが流れることでネットワークのトラフィックが増加してしまい、ネットワーク側に対して、例えば、別のイベントの発生を示す情報が遅延してしまったり、あるいは、届かなかったりする可能性もある。
上記の問題を解決するため、本発明は、ネットワーク側にかかる負荷（ＭＴＣサーバ及び通信システムのエンティティ（ｅＮＢ、ＭＭＥ、ＳＧＷ、ＰＧＷなど）の処理負荷やネットワークにおけるトラフィック量など）を低減させることを目的とする。また、本発明は、多数のＭＴＣデバイスが設置されている環境において、通信システムを通じてＭＴＣサーバと通信を行うＭＴＣデバイスがイベントを検知する状況となった場合に、ＭＴＣサーバ及び通信システムのエンティティ（ｅＮＢ、ＭＭＥ、ＳＧＷ、ＰＧＷなど）の処理負荷やネットワークにおけるトラフィック量を低減させることを目的とする。また、本発明は、ネットワーク側で混雑状況が検知された場合に、ＭＴＣサーバ及び通信システムのエンティティ（ｅＮＢ、ＭＭＥ、ＳＧＷ、ＰＧＷなど）の処理負荷やネットワークにおけるトラフィック量を低減させることを目的とする。
上記の目的を達成するため、本発明の接続確立方法は、ネットワーク内のエンティティとの間に第１の接続を確立している通信ノードが、第２の接続を確立するための接続確立方法であって、
前記第２の接続を確立するための接続確立要求メッセージが拒絶された場合に、前記第１の接続の優先度と、前記第２の接続の優先度を比較するステップと、
前記第２の接続の優先度が前記第１の接続の優先度より高い場合に、前記第１の接続に割り当てられている第１のＱｏＳ情報と、前記第２の接続に必要となる第２のＱｏＳ情報を比較し、前記第１のＱｏＳ情報を前記第２のＱｏＳ情報に再使用できるか判断するステップと、
前記第１のＱｏＳ情報を前記第２のＱｏＳ情報に再使用できると判断する場合に、前記第２の接続を確立するために前記第１の接続を修正するステップと、
を有する。
前記第２の接続を確立するための接続確立要求メッセージが拒絶された場合に、前記第１の接続の優先度と、前記第２の接続の優先度を比較するステップと、
前記第２の接続の優先度が前記第１の接続の優先度より高い場合に、前記第１の接続に割り当てられている第１のＱｏＳ情報と、前記第２の接続に必要となる第２のＱｏＳ情報を比較し、前記第１のＱｏＳ情報を前記第２のＱｏＳ情報に再使用できるか判断するステップと、
前記第１のＱｏＳ情報を前記第２のＱｏＳ情報に再使用できると判断する場合に、前記第２の接続を確立するために前記第１の接続を修正するステップと、
を有する。
上記の目的を達成するため、本発明の通信ノードは、ネットワーク内のエンティティとの間に接続を確立する通信ノードであって、
前記エンティティとの間に前記接続を確立するための接続確立要求メッセージを送信する送信部と、
前記通信ノードが、前記エンティティとの間に確立された第１の接続を保持している際、前記送信部が送信した前記第２の接続を確立するための前記接続確立要求メッセージが拒絶された場合に、前記第１の接続の優先度と、前記第２の接続の優先度を比較する比較部と、
前記第２の接続の優先度が前記第１の接続の優先度より高い場合に、前記第１の接続に割り当てられている第１のＱｏＳ情報と、前記第２の接続に必要となる第２のＱｏＳ情報を比較し、前記第１のＱｏＳ情報を前記第２のＱｏＳ情報に再使用できるか判断する判断部と、
前記第１のＱｏＳ情報を前記第２のＱｏＳ情報に再使用できると判断する場合に、前記第２の接続を確立するために前記第１の接続を修正する修正部とを、
を有する。
前記エンティティとの間に前記接続を確立するための接続確立要求メッセージを送信する送信部と、
前記通信ノードが、前記エンティティとの間に確立された第１の接続を保持している際、前記送信部が送信した前記第２の接続を確立するための前記接続確立要求メッセージが拒絶された場合に、前記第１の接続の優先度と、前記第２の接続の優先度を比較する比較部と、
前記第２の接続の優先度が前記第１の接続の優先度より高い場合に、前記第１の接続に割り当てられている第１のＱｏＳ情報と、前記第２の接続に必要となる第２のＱｏＳ情報を比較し、前記第１のＱｏＳ情報を前記第２のＱｏＳ情報に再使用できるか判断する判断部と、
前記第１のＱｏＳ情報を前記第２のＱｏＳ情報に再使用できると判断する場合に、前記第２の接続を確立するために前記第１の接続を修正する修正部とを、
を有する。
本発明は、上記の構成を有しており、ネットワーク側にかかる負荷（ＭＴＣサーバ及び通信システムのエンティティ（ｅＮＢ、ＭＭＥ、ＳＧＷ、ＰＧＷなど）の処理負荷やネットワークにおけるトラフィック量など）を低減させるという効果を有する。また、多数の通信ノード（ＭＴＣデバイス）が設置されている環境において、通信システムを通じてサーバ（ＭＴＣサーバ）と通信を行う通信ノードがイベントを検知及び通知する状況となった場合に、サーバの処理負荷やネットワークにおけるトラフィック量を低減させるという効果を有する。また、ネットワーク側で混雑状況が検知された場合に、ＭＴＣサーバ及び通信システムのエンティティ（ｅＮＢ、ＭＭＥ、ＳＧＷ、ＰＧＷなど）の処理負荷やネットワークにおけるトラフィック量を低減させるという効果を有する。
また、本発明は、通常時には検知した情報をノーマルモードでＭＴＣサーバ１５０に送信していたＭＴＣデバイスの送信モードを、緊急時（ある出来事が起こった場合）に、高優先度モードへ切り替えさせることができるという効果を有している。
以下、図面を参照しながら、本発明の第１〜第３の実施の形態について説明する。
＜システム構成＞
まず、図１を参照しながら、本発明の第１〜第３の実施の形態に共通するシステム構成について説明する。図１は、本発明の第１〜第３の実施の形態に共通するシステム構成の一例を示す図である。
まず、図１を参照しながら、本発明の第１〜第３の実施の形態に共通するシステム構成について説明する。図１は、本発明の第１〜第３の実施の形態に共通するシステム構成の一例を示す図である。
上述のように、図１に図示されている通信システムは、少なくともＭＴＣデバイス１００、ＵＥ１０５、ＭＴＣデバイス１００やＵＥ１０５と無線接続する基地局（ｅＮＢ又はＮＢ）１１０、Ｅ−ＵＴＲＡＮ１１５上のＭＴＣデバイス１００やＵＥ１０５の移動管理を担当するＭＭＥ１２０、ＭＴＣデバイス１００やＵＥ１０５のＥ−ＵＴＲＡＮ１１５に対するユーザデータ配信制御を行うＳＧＷ１３０、ＭＴＣデバイス１００やＵＥ１０５に対するアドレス割り当てやＰＤＮ１５５とＳＧＷ１３０間のユーザデータ転送並びに経路制御を行うＰＧＷ１４０、ＭＴＣデバイス１００やＵＥ１０５のサブスクリプションデータ並びに通信コンテキストなどを管理保持しているＨＳＳ１２５、ＭＴＣデバイス１００による通信の制御や状態管理、アプリケーションサービスの提供などを行うサーバであるＭＴＣサーバ１５０、ＭＴＣデバイス１００やＭＴＣサーバ１５０に対してアプリケーションの管理・制御やアプリケーションデータの管理を実施するＭＴＣユーザ１６０を有している。なお、ＭＴＣユーザ１６０は、また、ＨＳＳ１２５の代わりに、ＡＡＡ（Authentication, authorization and Accounting）サーバを用いてもよい。また、ＡＡＡサーバとＨＳＳ１２５は、物理的又は論理的に同一の装置に実装されるものであってもよい。
なお、図１において、ＭＴＣサーバ１５０はＰＤＮ１５５内に位置しているが、通信システムのオペレータドメイン内に位置していてもよく、例えば、ＰＧＷ１４０がＭＴＣサーバ１５０の機能を担ってもよい。
ここで、ＭＴＣデバイス１００は少なくとも１つ以上の通信インタフェースを持ち、通信システム（例えば、Ｅ−ＵＴＲＡＮ１１５）に接続することが可能である。なお、ＭＴＣデバイス１００は、図示されている通信システム以外のネットワーク（例えば、ＵＴＲＡＮ、ＷＬＡＮ（Wireless LAN）ネットワークやＷｉＭＡＸネットワーク）に、同時に、あるいは排他的に接続するものであってもよい。ＭＴＣデバイス１００は、接続した通信システムを通じて、ＭＴＣサーバ１５０と通信可能であり、ＭＴＣサーバ１５０はＭＴＣユーザ１６０と通信可能である。
また、ＭＴＣデバイス１００は、通信システム内で従来のＵＥ１０５と共存しながら通信を行う。なお、図１では、ＭＴＣデバイス１００とＵＥ１０５とがそれぞれ異なるｅＮＢ１１０に接続しているが、ＭＴＣデバイス用のｅＮＢ１１０が区別されているわけではなく、どのｅＮＢ１１０と接続してもよいものとする。しかし、今後、ＭＴＣデバイス１００が、ＭＴＣデバイス１００用にカスタマイズされたｅＮＢ１１０のみに接続が許されるという環境に変化した場合、ＭＴＣデバイス１００はＭＴＣデバイス１００用のｅＮＢ１１０に接続されてもよい。
また、各ＭＴＣデバイス１００は、ＵＥ１０５と同様にＭＴＣデバイス１００を識別するためのＩＤ（以降、デバイスＩＤと呼ぶ）が割り当てられていることとする。同様に、ＭＴＣデバイス１００がＭＴＣグループを形成する場合、ＭＴＣグループを識別するためのＩＤ（以降、グループＩＤと呼ぶ）が割り当てられていることとする。同様に、ＭＴＣデバイス１００は、デバイスの種類（例えば、煙センサ）を識別するためのＩＤ（以降、デバイス種ＩＤと呼ぶ）が割り当てられていることとする。なお、ＭＴＣデバイス１００の種類は、そのＭＴＣデバイス１００が搭載又は接続されている装置の種類によって決まる。また、ＭＴＣデバイス１００の種類は、ＭＴＣサーバ、ＭＴＣユーザ、又は、通信システムのオペレータによって設定されてもよい。
なお、ＭＴＣデバイス１００、通信システムのエンティティ（例えば、ＭＭＥ１２０、ＰＧＷ１４０など）、ＭＴＣサーバ１５０が、デバイス種ＩＤを用いずに、ＭＴＣデバイス１００の種類を識別することができるのであれば（例えば、デバイスＩＤのうちデバイス種別を示す一部のビット列（例えば、上位あるいは下位数ビット）からＭＴＣデバイス１００の種類を導出）、必ずしも本デバイス種ＩＤを用いる必要はない。また、デバイスＩＤも同様に、例えばＩＭＥＩ（International Mobile Equipment Identity）やＩＭＳＩ（International Mobile Subscriber Identity）を用いることで、ＭＴＣデバイス１００を一意に識別できるのであれば、新たに割り当てる必要はない。また、グループＩＤも同様に、例えばデータを転送するＰＤＮコネクション、ＥＰＳベアラを共有する場合（例えば、ＭＴＣグループの中で代表するＭＴＣデバイス１００が、通信システムとＰＤＮコネクション、ＥＰＳベアラを確立していて、代表するＭＴＣデバイス１００が同ＭＴＣグループに属する他のＭＴＣデバイス１００が取得したデータを転送する場合）には、ＰＤＮコネクションＩＤやＥＰＳベアラＩＤ、ＡＰＮ（Access Point Name）を用いることでＭＴＣグループを識別できるのであれば、新たに割り当てる必要はない。
また、各ＭＴＣデバイス１００には、例えばＭＴＣユーザ１６０などによって事前にＭＴＣの機能（ＭＴＣ Ｆｅａｔｕｒｅｓ）が組み込まれていてもよく（例えば、ＳＩＭカードに書き込む、ＭＴＣデバイス１００の記憶メモリに書き込む）、ネットワーク装置（例えば、ＭＭＥ１２０やＭＴＣサーバ１５０など）やＭＴＣデバイス１００自身が、所望のＭＴＣの機能を有効化／無効化するものであってもよい。上記のようなＭＴＣデバイス１００のデバイスＩＤ、グループＩＤ、デバイス種ＩＤ、搭載しているＭＴＣの機能、ＭＴＣの機能の有効化／無効化など、ＭＴＣに関連する様々な情報は、ＨＳＳ１２５が保持するサブスクリプションデータや通信コンテキストなどに登録されているものとする。また、Ｅ−ＵＴＲＡＮ１１５におけるＭＴＣデバイス１００のモビリティ制御は、ＵＥ１０５に対する制御と同様にＭＭＥ１２０が実施する。
また、ＭＴＣサーバ１５０は、通信システムを運用するオペレータが管理する場合と、オペレータ以外の運用者が管理する場合がある。いずれの場合も、オペレータが管理するＰＧＷ１４０とのインタフェースを有し、通信システムに接続するＭＴＣデバイスから／へのユーザデータ転送、通信システムにおけるＭＴＣデバイスの制御に関するサービスを享受する。なお、オペレータがＭＴＣサーバを管理する場合、ＭＴＣサーバとＰＧＷ１４０を同一装置内に実施するものであってもよく、これによって外部インタフェースの実装を装置内に隠蔽して装置コストの削減を図ることができる。
また、ＭＴＣユーザ１６０は、各ＭＴＣデバイス１００が取得したデータを管理・利用する主体であり、事業運営者や企業、またデータ管理を実施する制御主体（ＰＣ、サーバなど）に相当する。例えば、ＭＴＣデバイス１００が自動販売機に組み込まれていることを想定すると、ＭＴＣユーザ１６０は自動販売機の売り上げ集計やメンテナンスを実施する会社などである。また、ＭＴＣデバイス１００を煙センサに組み込まれていることを想定すると、ＭＴＣユーザ１６０は消防署や警備会社、保険会社、又は住宅の火災による被害の軽減を担当する会社などであると考えられる。なお、ＭＴＣユーザ１６０は、上記のようにＭＴＣの管理を行うユーザが使用するＭＴＣユーザ端末と考えてもよく、あるいは、ＭＴＣの管理を行うユーザが操作するＭＴＣサーバ１５０と同一の装置であると考えてもよい。
また、一般的に、ＭＴＣデバイス１００とＭＴＣサーバ１５０との間で交換されるデータは、アプリケーションレベルのデータであるため、ＭＴＣデバイス１００とＰＧＷ１４０との間のデータ転送は、Ｕプレーン（User plane：ユーザプレーン）の利用が想定される。しかし、アプリケーションやサービスの内容や性質（例えば、生存者確認など緊急性を伴うデータ転送向けサービス）、通信システムのネットワークオペレータの要求（例えば、ネットワーク装置（例えば、ＭＭＥ１２０）による制御が必要となる場合（例えば、ＭＴＣデバイス１００の位置情報の変更や、ＭＴＣグループ／同一デバイス種などの制御））、ＭＴＣデバイス１００／ＭＴＣサーバ１５０の要求（例えば、迅速に、又は、高い信頼度でデータを送信／取得したい場合）によっては、即時性や信頼性を有するＣプレーン（Control plane：制御プレーン）を利用する（シグナリングメッセージにアプリケーションデータを重畳、あるいはピギーバックする）ことによる効果が大きい場合がある。
また、イベント検知時に優先度の高いイベント通知メッセージを送信するＭＴＣデバイス１００は、取得したデータ（センシングデータとも呼ぶ）からイベントを検出すると、優先度の高いイベント通知メッセージをＭＴＣサーバに送信し、同時に、あるいは続けて、取得したデータ（センシングデータ）をＭＴＣサーバに送信するものとする。
また、上記の構成を有する通信システムにおいて、ＭＴＣデバイス１００は、通信システム（Ｅ−ＵＴＲＡＮ１１５）に接続されており、通信システムを通じてＭＴＣサーバ１５０と通信可能であるとする。
＜第１の実施の形態＞
以下、本発明の第１の実施の形態におけるシステム動作の一例について、図３を用いて詳しく説明する。図３は、本発明の第１の実施の形態におけるシステム動作の一例（複数のＭＴＣデバイス１００から送信される同一イベント、又は、そのイベントを引き起こした出来事によって引き起こされたイベントによる優先度の高いイベント通知メッセージの送信抑制方法）を説明するためのシーケンス図である。なお、図３には、図１に図示されているシステム構成における処理シーケンスの一例が図示されている。
以下、本発明の第１の実施の形態におけるシステム動作の一例について、図３を用いて詳しく説明する。図３は、本発明の第１の実施の形態におけるシステム動作の一例（複数のＭＴＣデバイス１００から送信される同一イベント、又は、そのイベントを引き起こした出来事によって引き起こされたイベントによる優先度の高いイベント通知メッセージの送信抑制方法）を説明するためのシーケンス図である。なお、図３には、図１に図示されているシステム構成における処理シーケンスの一例が図示されている。
ここで、本実施の形態の説明を容易化するために、ＭＴＣデバイス１００は以下のような特徴を持っていることを前提とする。
ＭＴＣデバイス１００は、非特許文献１で定義されている“Ｔｉｍｅ Ｃｏｎｔｒｏｌｌｅｄ”と、“ＰＡＭ”と、“Ｇｒｏｕｐ ｂａｓｅｄ”と、“Ｌｏｗ ｍｏｂｉｌｉｔｙ”とを有しているとする。ＭＴＣデバイス１００は、他の複数のＭＴＣデバイス１００と共に１つのＭＴＣグループとして管理されていることとする。また、ＭＴＣグループ内のＭＴＣデバイス１００は、“煙センサ”、“炎センサ”、“人感センサ”で構成されているものとする（実際には、各センサにＭＴＣデバイス１００である通信モジュールが実装される）。“煙センサ”は、一定値以上（あるいは所定時間連続して一定値以上）の煙濃度を検出した場合、すなわちイベント（煙）を検知した際に、火災が発生している可能性が高いと判断し、高い優先度（高優先度モードとも呼ぶ）でメッセージを送信する。“炎センサ”はイベント（炎）を検知した際、火災が発生している可能性が高いと判断し、“煙センサ”と同様に、高い優先度（高優先度モード）でメッセージを送信する。一方、“人感センサ”はイベント（人の有無）を検知した際、一般的な優先度（ノーマルモードとも呼ぶ）でセンシングデータを送信する。ここで、高優先度モードとは、イベントを検知した際に優先度の高いイベント通知メッセージを送信する状態である。またノーマルモードとは、イベントを検知した際に優先度の高いイベント通知メッセージは送信せずに、取得したデータを一般的な優先度で送信する状態、又は、一般的な優先度でイベント通知メッセージを送信し、取得したデータも同様に一般的な優先度で送信する状態である。なお、メッセージの優先度は、ＥＰＳベアラのＱＣＩや、ＥＰＳベアラの帯域幅（例えば、ＭＢＲ（Maximum Bit Rate）やＡＭＢＲ（Aggregate Maximum Bit Rate））、ＭＴＣデバイス１００が持つＩＭＳＩやＩＭＥＩの値、ＰＣＣ（Policy and Charging Control）、ＭＴＣ Ｆｅａｔｕｒｅ／ＭＴＣデバイス１００の種類／ＭＴＣサービス毎に定義される優先度や値などで定義されてもよい。
図３では、ＭＴＣグループ内のＭＴＣデバイス１００を識別するために、ＭＴＣデバイスＡ１００ＡとＭＴＣデバイスＢ１００Ｂとが図示されている。なお、ここでは、ＭＴＣデバイスＡ１００Ａを、最初にイベントを検知するＭＴＣデバイス（“煙センサ”）と仮定し、ＭＴＣデバイス１００Ｂを、ＭＴＣデバイスＡ１００Ａと同一のＭＴＣグループに属する他のＭＴＣデバイス（“煙センサ”、“炎センサ”、“人感センサ”）と仮定する。なお、図３では２つのＭＴＣデバイス１００（ＭＴＣデバイスＡ１００Ａ、ＭＴＣデバイスＢ１００Ｂ）しか存在していないが、３つ以上のＭＴＣデバイス１００が同じＭＴＣグループ内に存在する場合でも、同様に動作する。
以下、図３に図示されているシーケンスについて説明する。ＭＴＣデバイスＡ１００Ａ（煙センサ）は、ＭＴＣサーバ１５０と通信を行うためのＰＤＮコネクションを、従来手法（例えば、非特許文献３で示されるAttach procedure）に基づいてＰＧＷ１４０と確立する（図３のステップＳ２０１：ＰＤＮコネクション確立済み）。また、ＭＴＣデバイスＢ１００Ｂも、従来手法（例えば、非特許文献３で示されるAttach procedure）に基づいてＰＧＷ１４０とＰＤＮコネクションを確立する（図３のステップＳ２０６：ＰＤＮコネクション確立済み）。
ここで、ＭＴＣデバイスＡ１００Ａが、例えば、火災発生などにより、イベント（煙）を検知したとする（図３のステップＳ２０２：イベント検知）。イベントを検知したＭＴＣデバイスＡ１００Ａは、イベントを検知したことをＭＴＣサーバ１５０に通知するためのメッセージ（ここでは、イベント通知メッセージ＠デバイスＡと表記）を送信する。なお、ＭＴＣデバイスＡ１００Ａ（煙センサ）が煙を検知した場合は、火災が発生している可能性が高いと予測され、ＭＴＣデバイスＡ１００Ａは優先度の高いメッセージ（例えば、ＰＡＭ）を用いて、ＭＴＣサーバ１５０に通知する（図３のステップＳ２０３：イベント通知メッセージ＠デバイスＡ）。また、これ以降、優先度の高いメッセージとは、ＰＡＭや、他のＮＡＳメッセージより優先度が高いＮＡＳ／ＡＳメッセージなどを指す。また、この優先度の高いメッセージは、(Priority) Event Notification、Alarm Signaling、Event Alert、Emergency signaling、Event Detection Messageなどと呼ばれてもよい。
なお、このＭＴＣデバイスＡ１００Ａから送信される優先度の高いメッセージであるイベント通知メッセージ＠デバイスＡは、例えば、非特許文献１が定義するＰＡＭや、非特許文献３で記述されているＴＡＵ（Tracking Area Update） Ｒｅｑｕｅｓｔなどの位置登録メッセージにピギーバック（重畳）した場合、又は、ＰＤＮコネクションやＥＰＳベアラが確立されていない状態でイベントを検知した場合は、ＰＤＮコネクションやＥＰＳベアラを確立する際に用いられる、例えば、Attach RequestやService Request、非特許文献４にて定義されるDS-MIPv6 bootstrapping based on IKEv2で使用されるＩＫＥ＿ＳＡ＿ＩＮＩＴメッセージやＩＫＥ＿ＡＵＴＨ Ｒｅｑｕｅｓｔメッセージを用いてもよい。また、Bearer Modification Requestメッセージを用いるものであってもよい。これによって、新規メッセージを導入することなく、少ない修正でＭＴＣデバイス１００からのイベント通知を実施することができる。
通信システムのエンティティ（例えば、ＭＭＥ１２０）は、ＭＴＣグループに属しているＭＴＣデバイスＡ１００Ａから、イベントを検知したことを知らせる優先度の高いイベント通知メッセージを受信すると、ＳＧＷ１３０／ＰＧＷ１４０を通じて、ＭＴＣサーバ１５０にイベント通知メッセージ＠デバイスＡを転送する。また、通信システムのエンティティ（例えば、ＭＭＥ１２０）は、後続する優先度の高いイベント通知メッセージ（同一イベント（例えば、煙の発生）、若しくは、そのイベント（例えば、煙発生）を引き起こした出来事（例えば、火災発生）によって引き起こされたイベント（例えば、炎の発生）によるイベント通知メッセージ（例えば、ＰＡＭ））の送信を抑制するためのメッセージ（ここでは、逆イベント通知メッセージと表記する。また、逆ＰＡＭ、混雑回避メッセージ、Time Tolerant Indication、congestion indication、congestion prior indication、PAM reduction indicationなどと呼ばれてもよい）を、同グループの全てのＭＴＣデバイス１００にブロードキャストする（図３のステップＳ２０４：逆イベント通知メッセージ）。なお、通信システムのＥｎｔｉｔｙ（例えば、ＭＭＥ１２０）は、この逆通知メッセージに同種の優先度の高い通知メッセージの送信停止を示すパラメータを格納してもよい。
また、この逆イベント通知メッセージは、逆イベント通知メッセージの送信元（例えば、ＭＭＥ１２０）の判断（例えば、通信システムのオペレータによる事前設定）によって、他のメッセージより高い優先度、若しくは一般的な優先度で送信してもよい。他のメッセージより高い優先度で逆イベント通知メッセージが送信される場合は、メッセージの送信元が過負荷状態であり、一般的な優先度のメッセージの処理が放棄される場合でも、優先度の高い逆イベント通知メッセージは送信することができる。また、優先度の高い逆イベント通知メッセージではなく、一般的な優先度で逆イベント通知メッセージを送るものであってもよい。この場合は、特にメッセージの優先度を設定する必要がなくなる。
また、ＭＭＥ１２０は、一定期間内に所定数のイベント通知メッセージを受信した、あるいは単に一定数のイベント通知メッセージを受信した場合に、逆イベント通知メッセージを送信するものであってもよい。これにより、同一のイベント通知メッセージが今後も増加するであろうことを予見した上で、それらの発生を抑えるための逆イベント通知メッセージを送信することにより、単発のイベント通知メッセージから判断する場合に比べて、抑止メッセージ（逆イベント通知メッセージ）を効果的に発行することができ、通信リソースや帯域の有効利用を図ることができる（単発のイベント通知メッセージにより判断する場合、イベント通知メッセージを受信するたびに逆イベント通知メッセージを送信することになり、通信リソースや帯域を浪費することになる）。
このとき、ＭＭＥ１２０は、ＭＴＣデバイスＡ１００ＡがＭＴＣグループに属しているか、また、ＭＴＣグループに属しているのであれば、どのＭＴＣグループに属しているかを、ＭＴＣデバイスＡ１００Ａに対応するサブスクリプションデータをＨＳＳ１２５から取得してグループＩＤが登録されているかどうかで判断してもよい。若しくは、ＭＴＣデバイスＡ１００Ａがメッセージに格納したグループＩＤから、ＭＴＣデバイスＡ１００Ａがグループに属しているかどうか（あるいは、どのグループに属しているか）を判断してもよい。また、ＭＭＥ１２０が既にサブスクリプションデータを保持、又は、ＨＳＳ１２５からサブスクリプションデータを取得する以外の方法（例えば、外部サーバへの問合せなど）により、ＭＴＣデバイスＡ１００ＡがＭＴＣグループに属しているかどうかを確認してもよい。
また、ここでは逆イベント通知メッセージを送信する対象を、イベントを検知したＭＴＣデバイスＡ１００Ａが属しているＭＴＣグループ配下の全てのＭＴＣデバイス（ＭＴＣデバイスＡ１００Ａ及びＭＴＣデバイスＢ１００Ｂ）としているが、“Ｇｒｏｕｐ ｂａｓｅｄ”Ｆｅａｔｕｒｅが適用されないケースにおいては、例えば、ＭＴＣデバイスＡ１００Ａが接続しているｅＮＢ１１０やＭＭＥ１２０（あるいは特定のTracking Area）配下の全てのＭＴＣデバイス１００を逆イベント通知メッセージの送信対象としてもよい。この場合は、特定のエリアに位置するＭＴＣデバイス１００からの同じイベントによる優先度の高いイベント通知メッセージも回避することができる。また、ＭＴＣグループという概念を考慮せずに、優先度の高いイベント通知メッセージを回避できることにより、グループＩＤなどを用いなくてもよいという利点がある。ここでは、グループＩＤの代わりに、ｅＮＢ１１０のＩＤ、若しくは、ｅＮＢ１１０のアドレス（並びにデバイスのベアラに対応するS1-U TEID）を使用してもよい。また、ＭＭＥ１２０があらかじめ送信相手を確認できているのであれば、ブロードキャストではなく、マルチキャストやユニキャストで逆イベント通知メッセージを送信してもよい。これにより、制御範囲（通知範囲）を限定することにより、システム全体へのインパクトを低減させることができる。なお、この逆イベント通知メッセージは、上記ＭＭＥ１２０以外の他の通信システムにおけるエンティティ（例えば、ｅＮＢ１１０、ＰＧＷ１４０など）や、ＭＴＣサーバ１５０が送信してもよい。
逆イベント通知メッセージは、上述のように、後続する同種の優先度の高いイベント通知メッセージ（同一イベント、若しくは、そのイベントを引き起こした出来事によって引き起こされたイベントによるイベント通知メッセージ（例えば、ＰＡＭ））を抑制するためのメッセージである。具体的には、逆イベント通知メッセージは、ＭＴＣデバイス１００に対してノーマルモードの動作を要請するメッセージであり、逆イベント通知メッセージを受信したＭＴＣデバイス１００は、高優先度モードで動作している場合はノーマルモードへモード遷移し、ノーマルモードで動作している場合は、そのままノーマルモードを維持する。
また、優先度の高いイベント通知メッセージ（例えば、ＰＡＭなど）を回避する以外での逆イベント通知メッセージの使い方がある。例えば、通信システムのエンティティとＭＴＣデバイス１００が、複数の優先度レベルを認識することができ、ＭＴＣデバイス１００が優先度の異なる複数のセンシングデータを送信したい場合、逆イベント通知メッセージを受信したＭＴＣデバイス１００は、例えば、逆イベント通知メッセージに格納されているネットワーク側が示す許容優先度レベルや、ＭＴＣデバイス１００にあらかじめ組み込まれているコンテキスト（例えば、混雑度レベル３のときは優先度レベル３以上のメッセージのみ送信許容）やアプリケーションデータを用いて、送信可能なセンシングデータを選択／決定してもよい。このとき、例えば逆イベント通知メッセージを受信することで、ＭＴＣデバイス１００は送信するセンシングデータの優先度の判別を行わないモード（例えば、ノーマルモード）から、優先度を考慮して送信するセンシングデータを選択／決定できるモード（例えば、高優先度モード）に切り替えてもよい。
また、少なくともＭＴＣデバイス１００が複数の優先度レベルを認識することができる場合、ネットワーク側の装置（例えば、ＭＴＣサーバ１５０やＭＭＥ１２０）によって送信された優先度レベルの変更を示しているメッセージなどによって、ＭＴＣデバイス１００は例えば、送信するメッセージの優先度レベルを変更するなどの処理をしてもよい。これにより、ネットワークが混雑していてパケットロスが発生しているような状況において、ＭＴＣデバイス１００自身が送信するメッセージの優先度レベルを考慮し、送信するメッセージを選択することで、更なる混雑状態を作ることを回避できる。
逆イベント通知メッセージを受信したＭＴＣデバイスＡ１００Ａは、逆イベント通知メッセージに従って、図７のように高優先度モードからノーマルモードにモード遷移を行う（ステップＳ２０５：モード切替）。そして、その後は、ＭＴＣデバイスＡ１００Ａは、ノーマルモードでセンシングデータの送信を行う（図３のステップＳ２１０：取得データ送信）。なお、図３のステップＳ２１０の取得データ送信は、ステップＳ２０５のモード切替後の任意のタイミングに行われる。また、ここでは、最初にイベント通知メッセージを送信したＭＴＣデバイスＡ１００Ａが、逆イベント通知メッセージの受信によって、高優先度モードからノーマルモードへモード遷移を行っているが、高優先度モードによるイベント通知メッセージの送信を行った直後に自らノーマルモードへモード遷移してもよく、あるいは、イベント通知メッセージを送信したＭＴＣデバイスＡ１００Ａに関しては、そのまま高優先度モードによる通知を継続して行えるようにしてもよい。
また、逆イベント通知メッセージを受信したＭＴＣデバイスＢ１００Ｂは、自らイベントを検知した際に高い優先度のイベント通知メッセージ（例えば、ＰＡＭなど）を用いてＭＴＣサーバ１５０にイベントを検知したことを通知するＭＴＣデバイス（例えば、他の煙センサや炎センサなど）であっても、逆イベント通知メッセージの受信に応じて図７のように高優先度モードからノーマルモードにモード遷移する（図３のステップＳ２０７：モード切替）。そして、その後、イベントを検知したとしても（図３のステップＳ２０８：イベント検知）、高い優先度のイベント通知メッセージ（例えば、ＰＡＭなど）の送信を行わず（図３のステップＳ２０７：モード切替）、ノーマルモードでセンシングデータの送信を行う（図３のステップＳ２０９：取得データ送信）。なお、ＭＴＣデバイスＢ１００Ｂが、通常時からノーマルモードでセンシングデータをＭＴＣサーバ１５０に送信している人感センサのようなＭＴＣデバイスの場合には、送信モードをノーマルモードのままに維持する。また、ステップＳ２０７の高優先度モードからノーマルモードにモード遷移後にイベントを検知した際、高優先度ではなく一般的な優先度でイベント通知メッセージを通知し、その後にセンシングデータを送信してもよい。
なお、上述のように、イベントを検知した際に高い優先度のイベント通知メッセージを用いてイベントを検知したことをＭＴＣサーバ１５０に通知していたＭＴＣデバイス１００（例えば、煙センサや炎センサ）は、逆イベント通知メッセージの受信によってノーマルモードへモード遷移するが、例えば、一定時間後（例えば、逆イベント通知メッセージでライフタイム値を通知など）、又は、ＭＭＥ１２０やＭＴＣサーバ１５０から送信されるメッセージ（例えば、ＮＡＳメッセージなど）を受信することで、ノーマルモードから高優先度モードに戻すようにしてもよい。これにより、１つのイベントが終了した後は、従来と変わらない動作に戻すことができる（図３には不図示）。
＜第２の実施の形態＞
第１の実施の形態の解決手法によれば、本発明が目的としている冗長なイベント通知メッセージの送信を抑制することは実現できているが、優先度の高い必要なイベント通知メッセージの送信さえも抑制してしまう場合がある。例えば、煙センサが煙の発生を検出した場合、逆イベント通知メッセージによってすべてのＭＴＣデバイス１００（例えば、炎センサなど）がノーマルモードへ遷移してしまう。その結果、煙の発生後、さらに炎センサが炎を検知した場合であっても、炎センサは、高い優先度のイベント通知メッセージ（例えば、ＰＡＭなど）を送信することはできない。
第１の実施の形態の解決手法によれば、本発明が目的としている冗長なイベント通知メッセージの送信を抑制することは実現できているが、優先度の高い必要なイベント通知メッセージの送信さえも抑制してしまう場合がある。例えば、煙センサが煙の発生を検出した場合、逆イベント通知メッセージによってすべてのＭＴＣデバイス１００（例えば、炎センサなど）がノーマルモードへ遷移してしまう。その結果、煙の発生後、さらに炎センサが炎を検知した場合であっても、炎センサは、高い優先度のイベント通知メッセージ（例えば、ＰＡＭなど）を送信することはできない。
また、例えば、上記した複数のマンション群のセキュリティを監視している環境において、通常（災害が発生していないとき）人感センサは緊急性が要求されていないため、検知したイベント／取得したデータをノーマルモードでＭＴＣサーバ１５０に定期的あるいは所定のタイミングで送信する。しかしながら、煙センサが煙を検知した環境においては、火災が発生している可能性が高いため、人の有無に関する情報は重要度が高くなる。そのため、人感センサが検知した人の有無に関する情報は、一般的な優先度（ノーマルモード）ではなく、高い優先度でイベント通知メッセージ（例えば、ＰＡＭなど）を用いて通知しないといけない。このように、通常はノーマルモードで人の有無に関する情報を送信していたＭＴＣデバイス１００（人感センサ）が、同じＭＴＣグループに属しているＭＴＣデバイス１００、若しくは周辺のＭＴＣデバイス１００が検知したイベントにより、高い優先度のイベント通知メッセージ（例えば、ＰＡＭなど）でイベントの検知（人の有無に関する情報）を通知できるようにしたいという要望がある。
また、煙センサが煙を検知し、火災が発生している可能性が高い環境では、人は一斉に走って逃げることが想定される。このとき、人感センサが、例えば一定の人の歩行速度と密度を超えたとき、優先度の高いイベント通知メッセージを通知するように設定されている場合も考えられる。また、通信システムのオペレータ、ＭＴＣサーバ１５０やＭＴＣユーザ１６０などの要求によって、ＭＴＣデバイス１００間で通信が可能である環境において、周辺のＭＴＣデバイス１００から一定の値以上のメッセージを受信した場合（例えば、アドホックネットワークのような環境において、一定時間内に一定値以上のパケットを転送した場合など）、優先度の高いイベント通知メッセージを通知するように設定されている場合も考えられる。
なお、ＭＴＣデバイス１００が、イベントを検知した際に、イベント通知メッセージのみを通知する、又は、取得したデータのみ送信する、若しくは、イベント通知メッセージと取得したデータを送信するメッセージの両方のメッセージを送信するかは、例えばＭＴＣデバイス１００自身、通信システムのオペレータ、ＭＴＣサーバ１５０やＭＴＣユーザ１６０などによって決まるものとする。
第１の実施の形態における解決法（通信システムのエンティティ、若しくは、ＭＴＣサーバ１５０が、イベントを検知したＭＴＣデバイス１００から送信される優先度の高いイベント通知メッセージ受信後、対象となるＭＴＣグループに属する複数のＭＴＣデバイス１００が送信する可能性のある優先度の高いイベント通知メッセージを抑制することを目的としたメッセージを送信する方法）では、全てのデバイスに一律に送信停止を指示していたため、上述のようなケースにおいて、必要なイベント通知メッセージ（例えば、煙センサがＰＡＭを送信した後の、炎センサ又は人感センサからのＰＡＭなど）を受信することができなくなってしまう。したがって、第１の実施の形態の改良系を第２の実施の形態で示す。
以下、本発明の第２の実施の形態におけるシステム動作の一例について、図４を用いて詳しく説明する。図４は、本発明の第２の実施の形態におけるシステム動作の一例（複数のＭＴＣデバイス１００から送信される同一イベント、又は、そのイベントを引き起こした出来事によって引き起こされたイベントによる優先度の高いイベント通知メッセージの送信抑制方法）を説明するためのシーケンス図である。なお、図４には、図１に図示したシステム構成における処理シーケンスの一例を図示する。
ここで、本実施の形態の説明を容易化するために、ＭＴＣデバイス１００は以下のような特徴を持っていることを前提とする。
ＭＴＣデバイス１００は、非特許文献１で定義されている“Ｔｉｍｅ Ｃｏｎｔｒｏｌｌｅｄ”と、“ＰＡＭ”と、“Ｇｒｏｕｐ ｂａｓｅｄ”と、“Ｌｏｗ ｍｏｂｉｌｉｔｙ”とを有しているとする。ＭＴＣデバイス１００は、他の複数のＭＴＣデバイス１００と共に１つのＭＴＣグループとして管理されていることとする。また、ＭＴＣグループ内のＭＴＣデバイス１００は、“煙センサ”、“炎センサ”、“人感センサ”で構成されているものとする。“煙センサ”はイベント（煙）を検知すると、火災が発生している可能性が高いと判断し、高い優先度（高優先度モード）でメッセージを送信する。“炎センサ”はイベント（炎）を検知すると、火災が発生している可能性が高いと判断し、“煙センサ”と同様に、高い優先度（高優先度モード）でメッセージを送信する。一方、“人感センサ”がイベント（人の有無）を検知すると、ノーマルモードでセンシングデータを送信する。
図４では、ＭＴＣグループ内のＭＴＣデバイス１００を識別するために、ＭＴＣデバイスＡ１００ＡとＭＴＣデバイスＢ１００Ｂとが図示されている。なお、ここでは、ＭＴＣデバイスＡ１００Ａを、最初にイベントを検知するＭＴＣデバイス（“煙センサ”）と仮定し、ＭＴＣデバイスＢ１００Ｂを、ＭＴＣデバイスＡ１００Ａと同一のＭＴＣグループに属する他のＭＴＣデバイス（“煙センサ”、“炎センサ”、“人感センサ”）と仮定する。
以下、図４に図示されているシーケンスについて説明する。ＭＴＣデバイスＡ１００Ａ（煙センサ）は、ＭＴＣサーバ１５０と通信を行うためのＰＤＮコネクションを、従来手法（例えば、非特許文献３で示されるAttach procedure）に基づいてＰＧＷ１４０と確立する（図４のステップＳ３０１：ＰＤＮコネクション確立済み）。また、ＭＴＣデバイスＢ１００Ｂも同様に、従来手法（例えば、非特許文献３で示されるAttach procedure）に基づいて、ＰＧＷ１４０とＰＤＮコネクションを確立する（図４のステップＳ３０８：ＰＤＮコネクション確立済み）。
ここで、ＭＴＣデバイスＡ１００Ａが、例えば、火災発生などにより、イベント（煙）を検知したとする（図４のステップＳ３０２：イベント検知）。イベントを検知したＭＴＣデバイスＡ１００Ａは、イベントを検知したことをＭＴＣサーバ１５０に通知するために、検知したイベント情報など（例えば、煙発生フラグ、デバイス種ＩＤなど）を格納したイベント通知メッセージを作成し、ＭＴＣサーバ１５０にイベント通知メッセージ（ここでは、イベント通知メッセージ（イベント情報）＠デバイスＡと表記）を送信する（図４のステップＳ３０３：イベント通知メッセージ（イベント情報）＠デバイスＡ）。なお、ＭＴＣデバイスＡ１００Ａ（煙センサ）が煙を検知した場合は、火災が発生している可能性が高いと予測され、ＭＴＣデバイスＡ１００Ａは優先度の高いメッセージを用いて、ＭＴＣサーバ１５０に通知する。また、このとき、ＭＴＣデバイスＡ１００Ａは、イベント通知メッセージにセンシングデータ（煙濃度）を格納してもよい。
図５Ａは、図４のステップＳ３０３において、ＭＴＣデバイスＡ１００Ａが通信システムを通じて、ＭＴＣサーバ１５０に送信するメッセージの一例として、イベント通知メッセージ（イベント情報）＠デバイスＡのフォーマット例を示す図である。
ＭＴＣデバイスＡ１００Ａは、例えば、従来のＮＡＳメッセージフィールドに、少なくともイベントフラグフィールドを追加する。イベントフラグフィールドは、ＭＴＣデバイスＡ１００Ａがイベントを検知したこと（例えば、ＭＴＣデバイスＡ１００Ａが煙センサの場合は、煙発生フラグ）を示すためのフィールドである。なお、検出したイベントの種別を併記してもよい。さらには、センシングデータフィールド、デバイス種ＩＤフィールドを追加してもよい。また、センシングデータフィールドは、例えばイベントを検知した際に、ＭＴＣサーバ１５０に早期に（すなわちイベント通知とともに）送信しておきたいデータ（例えば、ＭＴＣデバイスＡ１００Ａが煙センサの場合、煙濃度など）を格納するためのフィールドである。また、デバイス種ＩＤフィールドは、イベントを検知したＭＴＣデバイスＡ１００Ａの種類を識別するための情報を格納するためのフィールドである。例えば、ＭＴＣデバイスＡ１００Ａが煙センサの場合は、“煙センサ”であることが識別可能な情報が格納される（例えば、IMEIのデバイス種別を示すビット列から判断する、など）。なお、これら従来のＮＡＳメッセージに加えたイベントフラグフィールド、センシングデータフィールド、デバイス種ＩＤフィールドは、ＮＡＳメッセージフィールドに埋め込まれるものであってもよい。また、従来のＮＡＳメッセージ以外のメッセージ（例えば、ＭＴＣ用の）を用いてもよい。
なお、本実施の形態は、Ｃプレーンでイベント通知メッセージ（イベント情報）＠デバイスＡが送信されると仮定しているが、Ｕプレーンで送信される場合には、従来のＵプレーンで送信されるメッセージの任意のフィールドでもよい。また、ＭＴＣデバイスＡ１００Ａ、若しくはＭＴＣサーバ１５０／ＭＴＣユーザ１６０が、イベントフラグフィールドの情報を用いなくても、ＭＴＣデバイス１００がイベントを検知したことを確認できる、例えば、“Ｔｉｍｅ ｃｏｎｔｒｏｌｌｅｄ”が適用されたＭＴＣデバイス１００が、割り当てられた時間外にアクセスしてきた場合に、ＭＴＣデバイス１００が高優先度モードで通知すべきイベントを検出したものとＭＭＥ１２０が判断できる場合は、イベントフラグフィールドを省略してもよい。また、ＭＴＣデバイスＡ１００ＡがＭＴＣサーバ１５０に早期に（すなわちイベント通知とともに）送信しておきたいセンシングデータがない場合は、センシングデータフィールドを省略してもよい。また、デバイス種ＩＤフィールドも同様に、従来のＮＡＳメッセージフィールドに格納されているデバイスＩＤから、そのデバイスの種類を導出することができるのであれば、省略してもよい。また、デバイス種ＩＤフィールドに情報が格納されていることで、ＭＴＣデバイスＡ１００Ａがイベントを検知したということを確認できる（例えば、煙センサを示すデバイス種ＩＤが格納される場合、同時に煙検知イベントが通知されたものとする）のであれば、イベントフラグフィールドも同様に省略してもよい。
なお、このＭＴＣデバイスＡ１００Ａから送信される優先度の高いメッセージであるイベント通知メッセージ（イベント情報）＠デバイスＡは、例えば、非特許文献１が定義するＰＡＭや、非特許文献３で記述されているＴＡＵ（Tracking Area Update）リクエストなどの位置登録メッセージにピギーバック（重畳）した場合、又は、ＰＤＮコネクションやＥＰＳベアラが確立されていない状態でイベントを検知した場合は、ＰＤＮコネクションやＥＰＳベアラを確立する際に用いられる、例えば、Attach RequestやService Request、非特許文献４にて定義されるDS-MIPv6 bootstrapping based on IKEv2で使用されるＩＫＥ＿ＳＡ＿ＩＮＩＴメッセージやＩＫＥ＿ＡＵＴＨ Ｒｅｑｕｅｓｔメッセージを改良して用いてもよい。また、Bearer Modification Requestメッセージを用いるものであってもよい。これによって、新規メッセージを導入することなく、少ない修正でＭＴＣデバイス１００からのイベント通知を実施することができる。
通信システムのエンティティ（例えば、ＭＭＥ１２０）は、イベント通知メッセージ（イベント情報）＠デバイスＡを受信すると、受信したメッセージから、必要な情報（例えば、イベントフラグ、センシングデータ、デバイス種ＩＤ）を抽出し、例えば、従来のUpdate Bearer Requestメッセージなどに格納し、ＳＧＷ１３０／ＰＧＷ１４０を通じて、ＭＴＣサーバ１５０にイベント通知メッセージ（イベント情報）＠デバイスＡを転送する。このとき、ＭＭＥ１２０は、イベント通知メッセージ（イベント情報）＠デバイスＡからイベント情報（イベントフラグ／デバイス種ＩＤ）を抽出して、逆イベント通知メッセージ（イベント情報）（逆ＰＡＭ、混雑回避メッセージ、Time Tolerant Indication、congestion indication、congestion prior indication、PAM reduction indicationなどと呼ばれてもよい）に格納し、ＭＴＣデバイスＡ１００Ａが属しているＭＴＣグループ内の全てのＭＴＣデバイス１００に送信する（図４のステップＳ３０４：逆イベント通知メッセージ（イベント情報））。
また、この逆イベント通知メッセージは、逆イベント通知メッセージの送信元（例えば、ＭＭＥ１２０）の判断（例えば、通信システムのオペレータによる事前設定）によって、他のメッセージより高い優先度、若しくは一般的な優先度で送信してもよい。他のメッセージより高い優先度で逆イベント通知メッセージが送信される場合は、メッセージの送信元が過負荷状態であり、一般的な優先度のメッセージの処理が放棄される場合でも、優先度の高い逆イベント通知メッセージは送信することができる。また、優先度の高い逆イベント通知メッセージではなく、一般的な優先度で逆イベント通知メッセージを送るものであってもよい。この場合は、特にメッセージの優先度を設定する必要がなくなる。
また、ＭＭＥ１２０は、一定期間内に所定数のイベント通知メッセージを受信した、あるいは単に一定数のイベント通知メッセージを受信した場合に、逆イベント通知メッセージを送信するものであってもよい。これにより、同一のイベント通知メッセージが今後も増加するであろうことを予見した上で、それらの発生を抑えるための逆イベント通知メッセージを送信することにより、単発のイベント通知メッセージから判断する場合に比べて、抑止メッセージ（逆イベント通知メッセージ）を効果的に発行することができ、通信リソースや帯域の有効利用を図ることができる（単発のイベント通知メッセージにより判断する場合、イベント通知メッセージを受信するたびに逆イベント通知メッセージを送信することになり、通信リソースや帯域を浪費することになる）。
このとき、ＭＭＥ１２０は、ＭＴＣデバイスＡ１００ＡがＭＴＣグループに属しているか、また、ＭＴＣグループに属しているのであれば、どのＭＴＣグループに属しているかを確認するために、ＭＴＣデバイスＡ１００Ａに対応するサブスクリプションデータをＨＳＳ１２５から取得してグループＩＤが登録されているかどうかで判断してもよい。若しくは、ステップＳ３０３のイベント通知メッセージ（イベント情報）＠デバイスＡに格納されているグループＩＤなどから判断してもよい（図５Ａ不図示）。また、ＭＭＥ１２０が既にサブスクリプションデータを保持、又は、ＨＳＳ１２５からサブスクリプションデータを取得する以外の方法（例えば、外部サーバなど）を用いて、ＭＴＣデバイスＡ１００ＡがＭＴＣグループに属しているかどうかを確認できるのであれば、ＨＳＳ１２５に問い合わせる必要はない。
また、ここでは逆イベント通知メッセージを送信する対象を、イベントを検知したＭＴＣデバイスＡ１００Ａが属しているＭＴＣグループ配下の全てのＭＴＣデバイス（ＭＴＣデバイスＡ１００Ａ及びＭＴＣデバイスＢ１００Ｂ）としているが、“Ｇｒｏｕｐ ｂａｓｅｄ”を搭載していないケースにおいては、ＭＴＣデバイスＡ１００Ａが接続しているｅＮＢ１１０配下の全てのＭＴＣデバイス１００を逆イベント通知メッセージの送信対象としてもよい。この場合、特定のエリアに位置するＭＴＣデバイス１００からの同じイベントによる優先度の高いイベント通知メッセージを抑制することができる。また、ＭＴＣグループという概念を考慮せずに、優先度の高いイベント通知メッセージを抑制できることにより、グループＩＤなどを用いなくてもよいという利点がある。ここでは、グループＩＤの代わりに、ｅＮＢ ＩＤやｅＮＢアドレス（並びにＭＴＣデバイス１００のＥＰＳベアラに対応するS1-U TEID）を使用してもよい。また、ＭＭＥ１２０があらかじめ送信相手を確認できているのであれば、ブロードキャストではなく、マルチキャストやユニキャストで逆イベント通知メッセージを送信してもよい。これにより、制御範囲（通知範囲）を限定することにより、システム全体へのインパクトを低減させることができる。
また、ＭＭＥ１２０は、逆イベント通知メッセージ（イベント情報）をＭＴＣグループの全てのＭＴＣデバイス１００に送信する際、例えば、逆イベント通知メッセージ（イベント情報）の送信先であるＭＴＣグループのグループＩＤ、デバイス種ＩＤと一緒に逆イベント通知メッセージ（イベント情報）を送信したことを、逆イベント通知メッセージ（イベント情報）送信済み情報として記憶する。この記憶した逆イベント通知メッセージ（イベント情報）送信済み情報は、同じＭＴＣグループ内の同じデバイス種のＭＴＣデバイス１００から同一イベント、又は、そのイベントを引き起こした出来事によって引き起こされたイベントによるイベント通知メッセージ（イベント情報）を受信した際に、再度同じ逆イベント通知メッセージ（イベント情報）を送信しないように、ＭＴＣデバイス１００が判断するパラメータとして使用される。なお、イベント通知メッセージ（イベント情報）を受信した際、同じＭＴＣグループの同じＭＴＣデバイス種からのイベント通知メッセージ（イベント情報）であると判断できる場合は、再度、逆イベント通知メッセージ（イベント情報）を送信することが望ましいが、この場合は、必ずしも逆イベント通知メッセージ（イベント情報）送信済み情報を記憶する必要はない。また、ＭＭＥ１２０は、上記したようにＭＴＣデバイス１００の種類を確認できるものとする（例えば、ＭＴＣデバイスのデバイスＩＤからＭＴＣデバイス１００の種類を確認することができる（例えば、デバイスＩＤのうちデバイス種別を示す一部のビット列（例えば、上位あるいは下位数ビット）、又は、外部サーバにデバイスＩＤを通知するとデバイス種ＩＤを取得できるなど）、又は、図５Ａに図示されているようにイベント通知メッセージ（イベント情報）＠デバイスＡにデバイス種ＩＤも格納されていることとする）。
また、ＭＴＣデバイス１００が複数のイベントグループ情報を保持している場合、ＭＭＥ１２０は、イベントグループ情報ラベル（複数のイベントグループ情報のうちのどのイベントグループ情報を使用するかを示すためにイベントグループ情報と関連付けられている情報）を逆イベント通知メッセージ（イベント情報）に格納して送信を行う。ＭＭＥ１２０が、どのイベントグループ情報を使用するかを判断する方法は、例えば、サブスクリプションデータに登録されている情報（例えば、イベント情報とイベントグループ情報が対になっている情報など）を用いてもよいし、ＭＴＣサーバ１５０／ＭＴＣユーザ１６０が、あらかじめ設定しているＭＴＣサービスの仕様や登録情報、また設定情報などに基づいて決定してもよい。また、ＭＭＥ１２０による上記の判断（どのイベントグループ情報を使用するか）は、ＭＴＣデバイス１００が送信するイベント通知メッセージ（イベント情報）で、複数のイベントグループ情報を保持していることを通知したうえで、実施されてもよい。
ここで、図５Ｂを参照しながら、逆イベント通知メッセージ（イベント情報）について説明する。図５Ｂは、図４のステップＳ３０４において、ＭＭＥ１２０が、ＭＴＣデバイスＡ１００Ａが属するＭＴＣグループの全てのＭＴＣデバイス１００（ＭＴＣデバイスＢ１００Ｂを含む）にブロードキャストするメッセージの一例として、逆イベント通知メッセージ（イベント情報）のフォーマット例を示す図である。
ＭＭＥ１２０は、従来のＮＡＳ返信メッセージフィールドに、イベントフラグフィールド、デバイス種ＩＤフィールド、イベントグループ情報ラベルフィールドを追加したメッセージを送信する。イベントフラグフィールドは、ＭＴＣデバイス１００がイベントを検知したことを示すためのフィールドである。なお、イベントフラグフィールドは、このメッセージが逆イベント通知メッセージであることを識別するためのフィールドとしても用いられる。また、デバイス種ＩＤフィールドは、イベントを検知したＭＴＣデバイス１００の種類の情報（例えば、煙センサ）を格納するためのフィールドである。デバイス種ＩＤフィールドには、例えば、この逆イベント通知メッセージを送信するきっかけとなったイベント通知メッセージの送信元のＭＴＣデバイス１００の種類を識別するための情報が格納される。なお、このデバイス種ＩＤフィールドに格納される情報は、後述するイベントグループ情報（図６参照）内に登録されている情報と対応付けられている必要があり、また、イベントグループ情報内に登録されている情報との対応が明確に判別できるのであれば、デバイス種ＩＤ以外の情報（例えば、イベントのＩＤなど）を用いてもよい。また、イベントグループ情報ラベルフィールドは、例えば、ＭＴＣデバイス１００が複数のイベントグループ情報を保持している際に使用されるフィールドである。このイベントグループ情報ラベルフィールドには、ＭＴＣデバイス１００がどのイベントグループ情報を使用するかを決定するために、ＭＭＥ１２０によってイベントグループ情報ラベル（例えば、火災、地震、強盗、建物崩壊、土砂崩れなど）が格納される。
なお、本実施の形態は、Ｃプレーンで逆イベント通知メッセージ（イベント情報）が送信されると仮定しているが、Ｕプレーンで送信される場合には、従来のＵプレーンで送信されるメッセージの任意のフィールドでもよい。また、ＭＴＣデバイス１００が、ＭＭＥ１２０からの逆イベント通知メッセージ（イベント情報）に格納されるイベントフラグフィールドの情報を用いなくても、同じＭＴＣグループ、若しくは、周辺のＭＴＣデバイス１００が、イベントを検知したことを確認できるのであれば（例えば、“Ｔｉｍｅ ｃｏｎｔｒｏｌｌｅｄ”で割り当てられた時間外のメッセージ受信から確認可能）、イベントフラグフィールドを省略してもよい。また、ＭＭＥ１２０が、ＭＴＣデバイス１００が１つのイベントグループ情報しか保持していないことを確認済みの場合や、イベントグループ情報を用いたモード遷移の詳細な管理を行わないような場合には、イベントグループ情報を識別する必要がないので、イベントグループ情報ラベルフィールドを省略してもよい。例えば、ネットワーク装置（例えば、ＭＭＥ１２０）から送信される逆イベント通知メッセージに、イベントグループ情報ラベルを格納せずにデバイス種ＩＤのみを格納することで、最初にイベント通知メッセージを送信したＭＴＣデバイス１００と同種のＭＴＣデバイス１００からのイベント通知メッセージのみを抑制することができる。
なお、これら従来のＮＡＳメッセージに加えたイベントフラグフィールド、デバイス種ＩＤフィールド、イベントグループ情報ラベルフィールドは、ＮＡＳ返信メッセージフィールドに埋め込まれるものであってもよい。
なお、このＭＭＥ１２０から送信される逆イベント通知メッセージ（イベント情報）は、例えば、非特許文献３や非特許文献５で記述されているＰａｇｉｎｇメッセージやBearer Modification Requestメッセージ、非特許文献１が定義するＰＡＭ、非特許文献３で記述されているＴＡＵ Ａｃｃｅｐｔメッセージ、又は、非特許文献４が定義するDS-MIPv6 bootstrapping based on IKEv2で使用されるＩＫＥ＿ＳＡ＿ＩＮＩＴメッセージやＩＫＥ＿ＡＵＴＨ Ｒｅｓｐｏｎｓｅメッセージを拡張して用いてもよい。
なお、イベント通知メッセージ（イベント情報）＠デバイスＡに格納されているイベント情報を参照し、その参照したイベント情報を逆イベント通知メッセージ（イベント情報）に格納してブロードキャストするエンティティは、ＭＭＥ１２０ではなく、ＰＧＷ１４０やＭＴＣサーバ１５０であってもよい。また、イベント通知メッセージ（イベント情報）＠デバイスＡに格納されているデバイス種ＩＤと、逆イベント通知メッセージ（イベント情報）に格納されているデバイス種ＩＤは、関連性が保証されているのであれば、必ずしも一致しなくてもよい。しかし、この場合も、逆イベント通知メッセージ（イベント情報）に格納されている情報と、イベントグループ情報に登録されている情報（例えば、デバイス種ＩＤ）とは、関連性が保証されている必要がある。なお、デバイス種ＩＤではなく、イベント情報や従来のＮＡＳメッセージに含まれているＭＴＣデバイス１００を識別する、例えば、ＩＰアドレスや、デバイスＩＤを基に、逆イベント通知メッセージ（イベント情報）に格納するデバイス種ＩＤを確認できるのであれば、イベント通知メッセージ（イベント情報）＠デバイスＡに格納されているデバイス種ＩＤを使用する必要はない。
逆イベント通知メッセージ（イベント情報）を受信したＭＴＣグループ内のＭＴＣデバイス１００（図４中のＭＴＣデバイスＢ１００Ｂに相当）は、逆イベント通知メッセージ（イベント情報）に格納されているデバイス種ＩＤを抽出し、ＭＴＣデバイスＢ１００Ｂ自身のデバイスＩＤ／デバイス種ＩＤと一致しているかどうかを確認する（図４のステップＳ３０９：自種ＩＤと一致しているかを確認）。この確認によって、逆イベント通知メッセージ（イベント情報）から抽出されたデバイス種ＩＤと、自身のデバイスＩＤ／デバイス種ＩＤとが一致している場合には、ＭＴＣデバイス１００は、ノーマルモードに遷移する（元々ノーマルモードだった場合はそのまま維持）。なお、逆イベント通知メッセージ（イベント情報）から抽出されたデバイス種ＩＤは、その逆イベント通知メッセージを送信するきっかけとなったイベント通知メッセージ（イベント）の送信元のＭＴＣデバイス１００（ここでは、ＭＴＣデバイスＡ１００Ａ）の種類を表している。すなわち、ＭＴＣデバイスＢ１００Ｂは、自デバイスと同種類のＭＴＣデバイス１００からイベント通知メッセージが送信されたかどうかを判断し、自デバイスと同種類のＭＴＣデバイス１００からイベント通知メッセージが既に送信されたことが確認できた場合には、高優先度モードによるイベント通知メッセージの送信を行わないよう、ノーマルモードで動作を行う。
また、ＭＴＣデバイスＢ１００Ｂは、受信した逆イベント通知メッセージ（イベント情報）に含まれているデバイス種ＩＤに基づいて、高優先度モードへのモード切替を行うべきかどうかを判断し、高優先度モードへのモード切替を行う必要が確認された場合には、高優先度モードへモード切替（あるいは、元々高優先度モードで動作しているのであればそのまま高優先度モードを維持）を行う（図４のステップＳ３１０:高優先度モードへの切替を行うかどうかを判断（モード切り換え））。ここで、高優先度モードへモード切替を行うべきかどうかの判断は、例えば、逆イベント通知メッセージ（イベント情報）から抽出したデバイス種ＩＤが、そのＭＴＣデバイスＢ１００Ｂが保持しているイベントグループ情報（図６）に記載されているかどうかで判断する。なお、ＭＴＣデバイスＢ１００Ｂが複数のイベントグループ情報を保持している場合は、逆イベント通知メッセージ（イベント情報）に格納されているイベントグループ情報ラベルを抽出し、抽出されたイベントグループラベル情報に対応するイベントグループ情報を使用して判断する。
図６は、ＭＴＣデバイス１００が、受信した逆イベント通知メッセージ（イベント情報）に含まれているデバイス種ＩＤ／イベントグループ情報ラベルに基づいて、モード切替を行うべきかどうかを判断するために用いられるイベントグループ情報の一例を示す図である。このイベントグループ情報には、複数のデバイス種ＩＤ（対応関係が分かるのであれば、デバイス種ＩＤと一致する必要はない）が登録されており、このデバイス種ＩＤは静的／動的に設定される。逆イベント通知メッセージ（イベント情報）を受信したＭＴＣデバイスＢ１００Ｂは、逆イベント通知メッセージ（イベント情報）から抽出されたデバイス種ＩＤが、イベントグループ情報に登録されているかどうかを確認する。
図６には、ＭＴＣデバイスＢ１００Ｂ（人感センサ）が保持しているイベントグループ情報の一例が図示されている。図６では、イベントグループ情報に煙センサＩＤと炎センサＩＤとが記載されており、このイベントグループ情報を保持しているＭＴＣデバイスＢ１００Ｂ（人感センサ）は、煙センサＩＤ又は炎センサＩＤが含まれている逆イベント通知メッセージ（イベント情報）を受信すると、高優先度モードへモード切替を行って（あるいは、そのまま高優先度モードを維持して）動作を行う。すなわち、イベントグループ情報には、特定の逆イベント通知メッセージ（イベント情報）を受信した場合、高優先度モードに遷移あるいは維持するよう規定する情報が登録されている。
イベントグループ情報にどの種類のデバイス種ＩＤを登録するかは、例えば、イベント発生時の好適な動作に基づいて考慮されることが好ましい。一例として、例えば、火災が発生したときには、煙センサからネットワーク側へ優先度の高いイベント通知メッセージ（イベント情報）が送信され、その逆イベント通知メッセージ（イベント情報）がＭＴＣグループ内にブロードキャストされた場合であっても、炎を検知するために炎センサは高優先度モードのまま動作させておき、また、人が残っていないかどうかを迅速に把握するために人感センサを高優先度モードにモード遷移させることが最適な動作であるとする。この場合には、例えば、炎センサが保持するイベントグループ情報に煙センサＩＤと人感センサＩＤ、煙センサが保持するイベントグループ情報に炎センサＩＤと人感センサＩＤ、人感センサが保持するイベントグループ情報に煙センサＩＤと炎センサＩＤをそれぞれ登録しておくことで、最適な動作を実現することが可能となる。なお、イベントグループ情報に登録するデバイス種ＩＤ及び各ＭＴＣデバイス１００の動作については、後で詳細に説明する。
なお、ステップＳ３０９及びステップＳ３１０の確認処理は、各ＭＴＣデバイス１００にイベントグループ情報をどのように持たせるか（各ＭＴＣデバイス１００個別にイベントグループ情報を持たせるのか、あるいは、複数のＭＴＣデバイス１００に同じイベントグループ情報を持たせるのか）や、イベントグループ情報内に含まれる情報をどのように構成しておくか（イベントグループ情報を持つＭＴＣデバイス１００の自種ＩＤをイベントグループ情報に含ませておくかどうか）などによって、様々な方法を採用することが可能である。しかしながら、本発明の基本的な考え方は、ステップＳ３０９及びステップＳ３１０の確認処理の方法を限定するものではない。本発明では、逆イベント通知メッセージを受信したＭＴＣデバイス１００が、自デバイスと同種類のデバイスから既にイベント通知メッセージの送信が行われたかどうかを確認でき、さらに、自デバイスと異なる種類のデバイスからイベント通知メッセージの送信が行われている場合には高優先度モードへ遷移（あるいは、現在のモードをそのまま維持）すべきかどうかを判断できるようにすることが重要である。
また、図６には、上述のように、ＭＴＣデバイスＢ１００Ｂ（人感センサ）が保持するイベントグループ情報が図示されているが、このイベントグループ情報に、人感センサ自体のＩＤ（人感センサＩＤ）が含まれていてもよい。ここで一例として挙げているステップＳ３０９及びステップＳ３１０の確認処理によれば、ＭＴＣデバイスＢ１００Ｂ（人感センサ）は、自身が保持しているイベントグループ情報に自デバイス種ＩＤ（人感センサＩＤ）が含まれているかどうかを確認することはないが、逆イベント通知メッセージ（イベント情報）を受信した場合でも例外的に高優先度モードで動作を行うＭＴＣデバイス１００のデバイス種ＩＤの一覧を、イベントグループ情報として登録することで、共通のイベントグループ情報を作成することも可能である。具体的には、火災発生時に、煙センサ、炎センサ、人感センサを高優先度モードで動作させたいと考えた場合には、イベントグループラベルの情報「火災」が付けられており、煙センサ、炎センサ、人感センサが登録されたイベントグループ情報を、煙センサ、炎センサ、人感センサに共通して持たせておくことも可能である。さらに、ステップＳ３０９及びステップＳ３１０の確認処理を上述したものとは異なる動作とすることで、すべてのＭＴＣデバイス１００が共通のイベントグループ情報を持たせた場合であっても、本発明に係る詳細なモード遷移の管理を実現できる方法も存在する。
また、ＭＴＣグループのＭＴＣデバイス１００は、逆イベント通知メッセージ（イベント情報）を受信した際、逆イベント通知メッセージ（イベント情報）に格納されているデバイス種ＩＤ（例えば、煙センサ）を記憶する（図４のステップＳ３１１：イベント情報の記憶）。この記憶したイベント情報は、ＭＴＣデバイス１００が再度ＭＭＥ１２０から別の逆イベント通知メッセージ（イベント情報（例えば、人感センサＩＤ））を受信した際に、優先度の高いイベント通知メッセージを送信しない（高優先度モードに切り替わらない）と判断するパラメータとして使用される。例えば、ＭＴＣデバイスＡ１００Ａ（煙センサ）が、イベントを検知して、優先度の高いイベント通知メッセージ（イベント情報）を送信した後、ＭＴＣデバイスＡ１００Ａと同じＭＴＣグループに属しているＭＴＣデバイス１００は、デバイス種ＩＤが“煙センサ”の逆イベント通知メッセージ（イベント情報）を受信する。このとき、ＭＴＣデバイスＡ１００Ａと同じデバイス種のＭＴＣデバイスＢ１００Ｂ（煙センサ）は、高優先度モードからノーマルモードにモード遷移するとともに、デバイス種ＩＤが“煙センサ”の逆イベント通知メッセージ（イベント情報）を受信したことを記憶する。その後、同じＭＴＣグループのＭＴＣデバイスＢ１００Ｂ（人感センサ）がイベントを検知して、優先度の高いメッセージ（イベント情報）を送信した場合には、ＭＴＣグループ内のＭＴＣデバイス１００は、デバイス種ＩＤが“人感センサ”の逆イベント通知メッセージ（イベント情報）を、デバイス種ＩＤが“煙センサ”の逆イベント通知メッセージ（イベント情報）に続いて受信する。このとき、ＭＴＣデバイスＡ１００Ａは、先に受信しているデバイス種ＩＤが“煙センサ”の逆イベント通知メッセージ（イベント情報）を記憶しており、この記憶された情報（受信履歴）をパラメータとして、ノーマルモードから高優先度モードにモード遷移せずに、再度優先度の高いイベント通知メッセージ（イベント情報）を送信しないよう動作する。これにより、同一イベント（例えば、火災発生）の際にいったん高優先度モードからノーマルモードに遷移したＭＴＣデバイス１００は、再度、高優先度モードに戻らないように制御することが可能となる。なお、このモード切替するための判断要素となるパラメータは、ＭＴＣデバイス１００の種類を示すデバイス種ＩＤ以外の情報でもよい。
なお、ステップＳ３０９の自デバイス種ＩＤの確認ステップからステップＳ３１１のイベント情報の記憶ステップは、順不同で実施してもよい。
その後、ＭＴＣデバイスＢ１００Ｂ（例えば、人感センサ）が、イベント（例えば、人の存在）を検知したとする（図４のステップＳ３１３：イベント検知）。イベント検知したＭＴＣデバイスＢ１００Ｂは、イベント検知時にデータ送信するモードを確認し、その送信モードに従って、ＭＴＣサーバ１５０に通知を行う。このとき、ＭＴＣデバイスＢ１００Ｂが高優先度モードであり、優先度の高いメッセージを通知する場合は、ＭＴＣデバイスＢ１００Ｂは、検知したイベント情報などを格納したイベント通知メッセージをＭＴＣサーバ１５０に通知する（図４のステップＳ３１４：イベント通知メッセージ（イベント情報）＠デバイスＢ）。一方、ＭＴＣデバイスＢ１００Ｂが高優先度モードではなくノーマルモードで送信する場合は、ステップＳ３１４のイベント通知メッセージ（イベント送信）（点線部分）はノーマルモードで通知するか、若しくは行わず、ＭＴＣサーバ１５０にセンシングデータを送信する（図４のステップＳ３１５：取得データ送信）。なお、ステップＳ３１４のイベント通知メッセージとステップＳ３１５の取得データ送信は、逐次的、若しくは、同時に行ってもよい。
また、最初にイベント通知メッセージ（イベント情報）を送信したＭＴＣデバイスＡ１００Ａも、逆イベント通知メッセージ（イベント情報）を受信し、逆イベント通知メッセージ（イベント情報）に従って、図７のように高優先度モードからノーマルモードにモード遷移を行い（図４のステップＳ３０６：モード切替）、逆イベント通知メッセージ（イベント情報）を受信したことを記憶する（図４のステップＳ３０７：イベント情報の記憶）。そして、その後は、ＭＴＣデバイスＡ１００Ａは、ノーマルモードでセンシングデータの送信を行う（図４のステップＳ３１６：取得データ送信）。なお、図４のステップＳ３１６の取得データ送信は、ステップＳ３０３のイベント通知メッセージ（イベント情報）＠デバイスＡ送信後の任意のタイミングに行うことが可能である。また、ここでは、最初にイベント通知メッセージ（イベント情報）を送信したＭＴＣデバイスＡ１００Ａが、逆イベント通知メッセージ（イベント情報）の受信によって、高優先度モードからノーマルモードへモード遷移を行っているが、高優先度モードによるイベント通知メッセージ（イベント情報）の送信を行った直後に自らノーマルモードへモード遷移してもよく、あるいは、イベント通知メッセージ（イベント情報）を送信したＭＴＣデバイスＡ１００Ａに関しては、そのまま高優先度モードによる通知を継続して行えるようにしてもよい。
また、通常、イベントを検知した際に高い優先度のイベント通知メッセージでＭＴＣサーバ１５０に通知していたＭＴＣデバイス１００（例えば、炎センサ）は、例えば、一定時間後（例えば、逆イベント通知メッセージでライフタイム値を通知など）、又は、ＭＭＥ１２０、ＭＴＣサーバ１５０から送信されるメッセージ（例えば、ＮＡＳメッセージなど）をＭＴＣデバイス１００が受信することで、ノーマルモードから高優先度モードに戻すことができる。また、通常、いったん高優先度モードに遷移した後にノーマルモードに戻って動作を行っているＭＴＣデバイス１００（例えば、人感センサ）に関しても、同様の方法で、元の状態（逆イベント通知メッセージを受信した場合に、ノーマルモードから高優先度モードへ遷移できる状態）に戻すことができる。これにより、１つのイベントが終了後も、通常と同様の動作に戻すことができる（図４には不図示）。
次に、図８を参照しながら、本発明の第２の実施の形態におけるＭＴＣデバイス１００の構成について説明する。図８は、本発明の第２の実施の形態におけるＭＴＣデバイス１００の構成の一例を示す図である。
図８において、ＭＴＣデバイス１００は、通信システム（例えば、Ｅ−ＵＴＲＡＮやＵＴＲＡＮ）と接続して下位レイヤにおける通信処理と上位レイヤでＩＰなどのパケット通信処理を実施する通信処理部５０１、受信したメッセージが逆イベント通知メッセージであるか判断し、受信した逆イベント通知メッセージに格納されているイベント情報を記憶し、逆イベント通知メッセージに格納されているデバイス種ＩＤが、ＭＴＣデバイス１００自身のデバイス種ＩＤと一致しているか確認し、さらに、保持しているイベントグループ情報に逆イベント通知メッセージに格納されているデバイス種ＩＤが登録されているか確認する逆イベント通知メッセージ処理部５０２、逆イベント通知メッセージを受信した際にＭＴＣデバイス１００の現在の送信モードを確認し、その送信モードを確認するために使用する情報を保持し、ＭＴＣデバイス１００の送信モードを切り替える送信モード制御部５０４、特定のイベント（そのＭＴＣデバイス１００が監視しているイベント）を検知するイベント検知部５０５、イベント検知時に高い優先度のメッセージで送るか判断するイベント通知メッセージ処理部５０３を少なくとも有する。なお、例えば、イベント通知メッセージ処理部５０３が、送信モード制御部５０４の機能を保持している場合は、送信モード制御部５０４を省略できる。他の機能部も同様に、１つの機能部で上記の機能部を含む場合は、省略してもよい。逆に、例えば、イベント通知メッセージ処理部５０３で実施している、受信した逆イベント通知メッセージに格納されているイベント情報を記憶する機能と、イベント検知時に高い優先度のメッセージで送るかどうかを判断する機能とを分けてもよい。
なお、ＭＴＣデバイス１００において上述の各構成要素が動作を行うことで、特定のイベントの発生を検知するためのセンサによって検知されたセンシングデータを通常の優先度で送信するノーマルモード、又は、センサによって特定のイベントの発生を検知したことを通知するイベント通知メッセージをノーマルモード、若しくは、ノーマルモードの優先度よりも高い優先度で送信する高優先度モードのいずれかの送信モードで動作を行うよう制御する動作モード制御部としての機能、ネットワークノードへ高優先度モードによるイベント通知メッセージの送信又はノーマルモードによるセンシングデータの送信を行う送信部としての機能、特定のイベントの発生を検知したことを通知するイベント通知メッセージを任意の通信ノードから受信したネットワークノードから、任意の通信ノードが通知するイベント通知メッセージに対する応答として送信されるメッセージであって、送信モードをノーマルモードへ遷移するか又はノーマルモードのまま維持するよう指示するメッセージを受信するメッセージ受信部としての機能、メッセージを受信した場合に、送信モードをノーマルモードへ遷移するか又はノーマルモードのまま維持するかどうかを判断するモード遷移判断部としての機能などが実現される。
次に、図８に図示されている構成を有するＭＴＣデバイス１００について、本発明における特徴的な処理を中心に、図９Ａと図９Ｂを用いて詳しく説明する。図９Ａは、本発明の第２の実施の形態において、イベント検知時に、ノーマルモード又は高優先度モードでＭＴＣサーバ１５０への送信処理を行うＭＴＣデバイス１００の処理フローの一例を示すフロー図であり、図９Ｂは、本発明の第２の実施の形態において、ネットワーク側（例えば、ＭＭＥ１２０）から逆イベント通知メッセージを受信したＭＴＣデバイス１００の処理フローの一例を示すフロー図である。
最初に、図９Ａを参照しながら、ＭＴＣデバイス１００がイベントを検知した際に、ノーマルモード又は高優先度モードでＭＴＣサーバ１５０への送信する場合の処理フローについて説明する。
ＭＴＣデバイス１００は、ＭＴＣサーバ１５０と通信を行うために、ＰＧＷ１４０との間にＰＤＮコネクション及びＥＰＳベアラを確立する（図９ＡのステップＳ６０１）。
ここで、ＭＴＣデバイス１００は、イベント検知部５０５でイベントを検知したとする（図９ＡのステップＳ６０２）。なお、イベントの検知は、例えば、煙センサであれば煙の検知、炎センサであれば炎の検知、人感センサであれば人物の検知などである。イベント検知後、ＭＴＣデバイス１００は、送信モードに関する情報を取得し（図９ＡのステップＳ６０３）、高い優先度のメッセージでＭＴＣサーバ１５０に送信するかどうかを、イベント通知メッセージ判断部５０３で判断する（図９ＡのステップＳ６０４）。
送信モードが高優先モードであり、高い優先度のイベント通知メッセージでＭＴＣサーバ１５０に通知すると判断した場合、ＭＴＣデバイス１００は通信処理部５０１で例えば、イベントフラグ（例えば、煙発生）、センシングデータ、デバイス種ＩＤを生成し（図９ＡのステップＳ６０５）、このイベント情報を格納したイベント通知メッセージ（イベント情報）＠デバイスＡを、通信システムを通じてＭＴＣサーバ１５０に送信する（図９ＡのステップＳ６０６）。
なお、上述のように、例えば、“Ｔｉｍｅ Ｃｏｎｔｒｏｌｌｅｄ” が適用されたＭＴＣデバイス１００が、割り当てられた時間外にアクセスしてきた場合に、ＭＴＣデバイス１００が高優先度モードで通知すべきイベントを検出したものとネットワーク側（例えば、ＭＭＥ１２０）が判断できる場合、ＭＴＣデバイス１００は、イベントフラグをイベント通知メッセージ（イベント情報）＠デバイスＡに格納する必要はない。また、上記以外の手段を用いて、ＭＴＣデバイス１００がイベントを検知したことをネットワーク側が確認できるのであれば、同様にイベントフラグを省略してもよい。また、デバイス種ＩＤも同様に、例えば、デバイスＩＤのうちデバイス種別を示す一部のビット列（例えば、上位あるいは下位数ビット）からＭＴＣデバイス１００の種類を導出し、ＭＴＣデバイス１００の種類をネットワーク側で識別できるのであれば、デバイス種ＩＤを格納する必要はない。
一方、送信モードがノーマルモードであり、一般的な優先度で検知したイベント（例えば、煙発生）とセンシングデータをＭＴＣサーバ１５０に送信すると判断した場合、ＭＴＣデバイス１００は、通常通り、イベント通知メッセージ（イベント情報）＠デバイスＡと取得したセンシングデータを、通信処理部５０１から送信する（図９ＡのステップＳ６０７）。
なお、上述のように、ＭＴＣデバイス１００は、一定時間後（例えば、逆イベント通知メッセージで通知されたライフタイム値など）、又は、ＭＭＥ１２０、ＭＴＣサーバ１５０から送信されるメッセージ（例えば、ＮＡＳメッセージなど）を受信したときに、高優先度モードからノーマルモード、若しくは、ノーマルモードから高優先度モードに戻す処理を行ってもよい（図９Ａには不図示）。
次に、図９Ｂを参照しながら、ＭＴＣデバイス１００がネットワーク側（例えば、ＭＭＥ１２０）から逆イベント通知メッセージを受信した場合の処理フローについて説明する。
ＭＴＣデバイス１００は、ＭＴＣサーバ１５０と通信を行うために、ＰＧＷ１４０との間にＰＤＮコネクション及びＥＰＳベアラを確立する（図９ＢのステップＳ７０１）。
ここで、ＭＴＣデバイス１００は、通信システムから何らかのメッセージを受信すると、受信したメッセージが逆イベント通知メッセージ（イベント情報）であるかどうかを逆イベント通知メッセージ処理部５０２にて判断する（図９ＢのステップＳ７０２）。逆イベント通知メッセージ（イベント情報）ではないと判断した場合には、そのメッセージに適した別の処理が行われる（図９Ｂには不図示）。
一方、逆イベント通知メッセージ（イベント情報）だと判断した場合、ＭＴＣデバイス１００は、逆イベント通知メッセージ（イベント情報）からデバイス種ＩＤを抽出し、同一のデバイス種ＩＤが格納された逆イベント通知メッセージ（イベント情報）を再度受信した場合を特定するために、抽出されたデバイス種ＩＤを逆イベント通知メッセージ処理部５０２にて記憶する（図９ＢのステップＳ７０３）。
続いて、逆イベント通知メッセージ処理部５０２において、ＭＴＣデバイス１００自身のデバイスＩＤ／デバイス種ＩＤと逆イベント通知メッセージ（イベント情報）に格納されているデバイス種ＩＤとが一致しているかどうかを確認する（図９ＢのステップＳ７０５）。ＭＴＣデバイス１００自身のデバイスＩＤ／デバイス種ＩＤと逆イベント通知メッセージ（イベント情報）に格納されているデバイス種ＩＤとが一致する場合は、自デバイスと同じ種類のＭＴＣデバイス１００からイベント通知メッセージが既に送信されていると判断でき、ＭＴＣデバイス１００は、ノーマルモードで動作を行う（図９ＢのステップＳ７０６）。なお、ステップＳ７０６では、ＭＴＣデバイスが高優先度モードだった場合は、送信モード制御部５０４においてノーマルモードに遷移し、ＭＴＣデバイスがノーマルモードだった場合は、そのままノーマルモードを維持する。
一方、ＭＴＣデバイス１００自身のデバイスＩＤ／デバイス種ＩＤと逆イベント通知メッセージ（イベント情報）に格納されているデバイス種ＩＤとが一致しない場合は、逆イベント通知メッセージ処理部５０２において、逆イベント通知メッセージ（イベント情報）に含まれるイベントグループ情報ラベルに対応するイベントグループ情報を読み出し（図９ＢのステップＳ７０７）、逆イベント通知メッセージ（イベント情報）から抽出したデバイス種ＩＤが、イベントグループ情報に登録されているかどうかを確認する（図９ＢのステップＳ７０８）。逆イベント通知メッセージ（イベント情報）から抽出したデバイス種ＩＤがイベントグループ情報に登録されていない場合は、受信した逆イベント通知メッセージはＭＴＣデバイス１００が関与していないイベントに係る逆イベント通知メッセージ（イベント情報）であると判断でき、ＭＴＣデバイス１００は、処理を終了する。なお、デバイス種ＩＤのリストが登録されたイベントグループ情報をＭＴＣデバイス１００に保持させるのではなく、自デバイス種とそのラベルとが関連付けられているかどうかを示す情報を保持させることも可能であり、この場合には、ＭＴＣデバイス１００は、ステップＳ７０８において、「自デバイス種とラベル名（例えば「火災」）とが関連付けられているかどうかを確認するだけでよい。
一方、逆イベント通知メッセージ（イベント情報）から抽出したデバイス種ＩＤが、イベントグループ情報に登録いる場合は、受信した逆イベント通知メッセージ（イベント情報）はＭＴＣデバイス１００が関与しているイベントに係る逆イベント通知メッセージ（イベント情報）であると判断できる。この場合、ＭＴＣデバイス１００は、逆イベント通知メッセージ処理部５０２に記憶されているデバイス種ＩＤを確認し、同じ種類のＭＴＣデバイス１００から送信されたイベント通知メッセージ（イベント情報）に対する逆イベント通知メッセージ（イベント情報）を既に受信しているかどうかを判断する（図９ＢのステップＳ７０９）。そして、ＭＴＣデバイス１００は、同じ種類のＭＴＣデバイス１００から送信されたイベント通知メッセージ（イベント情報）に対する逆イベント通知メッセージ（イベント情報）を既に受信している場合は処理を終了し、一方、同じ種類のＭＴＣデバイス１００から送信されたイベント通知メッセージ（イベント情報）に対する逆イベント通知メッセージ（イベント情報）を初めて受信した場合は、高優先度モードで動作を行う（図９ＢのステップＳ７１０）。なお、ステップＳ７１０では、ＭＴＣデバイス１００が高優先度モードだった場合は、送信モード制御部５０４においてそのまま高優先度モードを維持し、ＭＴＣデバイスがノーマルモードだった場合は、高優先度モードに遷移する。このようにして決定された送信モードは、図９Ａに図示されている送信モードの確認処理（図９ＡのステップＳ６０３）で参照される。
なお、ステップＳ７０５の自デバイス種ＩＤとの一致を確認するタイミング、ステップＳ７０８の逆イベント通知メッセージ（イベント情報）から抽出されたデバイス種ＩＤがイベントグループ情報に登録されているかどうかを確認するタイミング、ステップＳ７０９の逆イベント通知メッセージ（イベント情報）の受信を既に行っているデバイス種かどうかを確認するタイミングは、順序が異なっていてもよい。
次に、図１０を参照しながら、本発明の第２の実施の形態におけるＭＭＥの構成について説明する。図１０は、本発明の第２の実施の形態におけるＭＭＥ１２０の構成の一例を示す図である。
図１０において、ＭＭＥ１２０は、通信システム（例えば、Ｅ−ＵＴＲＡＮやＵＴＲＡＮ）上で通信処理を行い、ＩＰなどのパケット通信処理を実施する通信処理部８０１、受信メッセージが高い優先度で送られてきたイベント通知メッセージであるか判断した後、イベント情報を取得し、取得したイベント情報を記憶するイベント通知メッセージ処理部８０３、同一イベント、又は、そのイベントによって引き起こされたイベントによる冗長なイベント通知メッセージの受信を抑制するためにイベント通知メッセージから取得したイベント情報を格納した逆イベント通知メッセージをブロードキャスト送信するか判断する逆イベント通知メッセージ処理部８０２を少なくとも有する。なお、例えば、逆イベント通知メッセージ処理部８０２が、イベント通知メッセージ処理部８０３の機能を保持している場合、イベント通知メッセージ処理部８０３を省略できる。他の機能部も同様に、１つの機能部で上記の機能部を含む場合は、省略してもよい。
なお、ＭＭＥ１２０において上述の各構成要素が動作を行うことで、ＭＴＣデバイス１００から、特定のイベントの発生を検知したことを通知するイベント通知メッセージを受信する受信部としての機能、イベント通知メッセージに対する応答として、送信モードをノーマルモードへ遷移するか又はノーマルモードのまま維持するよう指示するメッセージを作成するメッセージ作成部としての機能、メッセージをＭＴＣデバイス１００へ送信するメッセージ送信部としての機能を有している。
次に、図１０に図示されている構成を有するＭＭＥ１２０について、本発明における特徴的な処理を中心に、図１１を用いて詳しく説明する。図１１は、本発明の第２の実施の形態におけるＭＭＥ１２０の処理フローの一例を示すフロー図である。
ＭＭＥ１２０は、ＭＴＣデバイスＡ１００Ａから送信されたメッセージを受信し、イベント通知メッセージ処理部８０３にて、このメッセージが優先度の高いイベント通知メッセージ（イベント情報）＠デバイスＡであると判断したとする（図１１のステップＳ９０１）。なお、ＭＭＥ１２０は、イベント通知メッセージ（イベント情報）＠デバイスＡだと判断する際に、イベント通知メッセージ（イベント情報）＠デバイスＡのイベントフラグフィールドを参照してもよい。
続いて、ＭＭＥ１２０は、イベント通知メッセージ処理部８０３にて、受信したイベント通知メッセージ（イベント情報）＠デバイスＡからイベント情報を取得する（図１１のステップＳ９０２）。そして、ＭＭＥ１２０は、同一イベント、又は、そのイベントを引き起こした出来事によって引き起こされたイベントによる冗長なイベント通知メッセージの送信を抑制するために逆イベント通知メッセージ（イベント情報）をＭＴＣグループのＭＴＣデバイス１００に送信するかどうかを逆イベント通知メッセージ処理部８０２にて判断する（図１１のステップＳ９０３）。なお、逆イベント通知メッセージ（イベント情報）を送信するかどうか（あるいは、高優先度モードによる動作を要求するために、どのラベルを逆イベント通知メッセージに付加するか）を判断する際、逆イベント通知メッセージ処理部８０２に保持されているイベントグループ情報を用いて判断してもよい。また、ＨＬＲ／ＨＳＳ１２５にＭＴＣデバイス１００の情報（例えば、サブスクリプションデータ）を問い合わせて判断してもよい。
逆イベント通知メッセージ（イベント情報）を送信すると判断した場合、ＭＭＥ１２０は、例えば、イベント通知メッセージ（イベント情報）＠デバイスＡから取得されたデバイス種ＩＤを格納した逆イベント通知メッセージ（イベント情報）をＭＴＣデバイスＡ１００Ａが属するＭＴＣグループの全てのＭＴＣデバイス（ＭＴＣデバイスＢ１００Ｂを含む）にブロードキャストで送信する（図１１のステップＳ９０４）。なお、ＭＭＥ１２０は、ＭＴＣデバイスＡ１００ＡがＭＴＣグループに属しているかどうかを判断する手段として、イベント通知メッセージ（イベント情報）＠デバイスＡに格納されているグループＩＤ（図５Ａには不図示）や、ＨＳＳ１２５が保持するサブスクリプションデータを用いてもよい。また、ＭＭＥ１２０が逆イベント通知メッセージ（イベント情報）を送信する際、ＭＭＥ１２０はイベント通知メッセージ（イベント情報）＠デバイスＡから抽出したデバイス種ＩＤを、再度イベント通知メッセージ（イベント情報）＠デバイスＡを受信した際に逆イベント通知メッセージ（イベント情報）を送信するかどうかを判断する際に用いるパラメータとして使用するため、例えば、逆イベント通知メッセージ処理部８０２にて記憶することが望ましい。なお、イベント通知メッセージ（イベント情報）＠デバイスＡから抽出するデバイス種ＩＤは、ＭＴＣデバイス１００の種類を識別するためのＩＤ以外を使用してもよいが、上述のように、各ＭＴＣデバイス１００が保持するイベントグループ情報に登録されている情報と関連している必要がある。
また、ＭＭＥ１２０は、逆イベント通知メッセージ（イベント情報）にイベントグループ情報ラベルを付加する場合、特定のデバイスからのイベント通知メッセージ（例えば、煙センサや炎センサ）に対して、事前に定められた特定のラベル名（例えば「火災」）を付加するように構成されていてもよく、また、イベント通知メッセージに含まれているイベント情報やセンシングデータ）、その他の情報などから、付加すべきイベントグループ情報ラベル名を決定してもよい。また、あるＭＴＣデバイス１００（例えば、煙センサ）から受信したイベント通知メッセージ（イベント情報）に応じてあるイベントグループ情報ラベル（例えば「火災」）を付加して逆イベント通知メッセージを送信した場合、イベントグループ情報などによって関連付けられている別のデバイス種のＭＴＣデバイス１００（例えば、炎センサ）からイベント通知メッセージを所定時間内に受信したときには、その逆イベント通知メッセージ（イベント情報）に同一のラベル名（例えば「火災））を付加するようにしてもよい。
また、ＭＭＥ１２０は、一定時間後、又は、ＭＴＣサーバ１５０／ＭＴＣユーザ１６０があらかじめ設定した仕様や登録情報、また設定情報などに基づいて、ＭＴＣデバイス１００又はＭＭＥ１２０が保持している情報を解放するためのメッセージ（例えば、ＮＡＳメッセージで、ＭＴＣデバイス１００が持つ送信モードの定常化（高優先度モードからノーマルモード、若しくは、ノーマルモードから高優先度モード））を送信してもよい（図１１には不図示）。
また、上述の説明では、ＭＭＥ１２０が逆イベント通知メッセージ（イベント情報）を送信しているが、ＭＴＣサーバ１５０が逆イベント通知メッセージ（イベント情報）を送信することも可能である。なお、本発明の第２の実施の形態において、ＭＴＣサーバ１５０が逆イベント通知メッセージ（イベント情報）を送信する場合のＭＴＣサーバ１５０の構成は、図１０に図示されているＭＭＥ１２０の構成と同様であり、ここでは説明を省略する。
同様に、本発明の第２の実施の形態において、ＭＴＣサーバ１５０の処理フローは、図１０に図示されているＭＭＥ１２０の処理フロー（ずなわち、図１１に図示されている処理フロー）と同様であり、ここでは説明を省略する。
次に、図１２〜図１４を参照しながら、上述した本発明の第１及び第２の実施の形態における各ＭＴＣデバイス１００の動作とイベントグループ情報について、具体的な例を挙げながら説明する。
図１２は、本発明の第１及び第２の実施の形態に係る具体的な例を説明するために、各ＭＴＣデバイス１００の配置の一例を示す図である。図１２には、ＭＴＣグループ内に様々なＭＴＣデバイス１００（煙センサ、炎センサ、人感センサ、ガスセンサ、水道センサ、水道メータセンサ、地震センサ、ドアロックセンサなど）が多数配置されている状態が模式的に図示されている。図１２に図示されているように、例えば、多数のＭＴＣデバイス１００が１つの施設内に配置されることで、例えば、施設内で発生し得るイベント（事故や災害など）を監視している。以下では、同一ＭＴＣグループ内の多数のＭＴＣデバイス１００のうち、２つの煙センサ、２つの炎センサ、２つの人感センサ、１つのドアロックセンサ、１つの水道センサに焦点を当てて、本発明に係る動作について具体的に説明する。
なお、煙センサは、通常は高優先度モードで動作し、煙の発生を検知すると高優先度のイベント通知メッセージを送信するよう構成されているとする。また、炎センサは、通常は高優先度モードで動作し、炎の発生を検知（熱の検知）すると高優先度のイベント通知メッセージを送信するよう構成されているとする。また、人感センサは、通常はノーマルモードで動作し、人の存在の有無の情報をセンシングデータとしてノーマルモードで送信するよう構成されているとする。また、ドアロックセンサは、通常は高優先度モードで動作し、施錠されたドアの開錠を検知すると高優先度のイベント通知メッセージを送信するよう構成されているとする。また、水道メータセンサは、通常はノーマルモードで動作し、水道メータの値（検針値）をセンシングデータとしてノーマルモードで送信するよう構成されているとする。
＜図１３の（１）＞
本発明の第１の実施の形態によれば、例えば、ある煙センサが煙の発生を検知し、ＭＴＣサーバ１５０へイベント通知メッセージを送信すると、ＭＭＥ１２０からＭＴＣグループ内のすべてのＭＴＣデバイス１００へ逆イベント通知メッセージが送信される。
本発明の第１の実施の形態によれば、例えば、ある煙センサが煙の発生を検知し、ＭＴＣサーバ１５０へイベント通知メッセージを送信すると、ＭＭＥ１２０からＭＴＣグループ内のすべてのＭＴＣデバイス１００へ逆イベント通知メッセージが送信される。
この場合、逆イベント通知メッセージを受信するＭＴＣデバイス１００（すなわち、ＭＴＣグループ内のすべてのＭＴＣデバイス１００）は、ノーマルモードへ遷移する（元々ノーマルモードの場合はそのまま維持）。具体的には、図１３の（１）に図示されているように、煙センサ、炎センサ、ドアロックセンサは高優先度モードからノーマルモードへ遷移し、人感センサはノーマルモードを維持し続ける。また、その他のＭＴＣデバイス１００（例えば、地震センサや水道センサなど）も、すべてノーマルモードによる動作を行うよう制御される。
＜図１３の（２）、図１４の（Ａ）、（Ｂ）＞
また、本発明の第２の実施の形態によれば、例えば、ある煙センサが煙の発生を検知し、ＭＴＣサーバ１５０へイベント通知メッセージ（イベント情報）を送信すると、ＭＭＥ１２０からＭＴＣグループ内のすべてのＭＴＣデバイス１００へ逆イベント通知メッセージ（イベント情報）が送信される。この場合、ＭＴＣグループ内のすべてのＭＴＣデバイス１００は、デバイス種ＩＤ「煙センサ」及びイベントグループ情報ラベル名「火災」を含む逆イベント通知メッセージ［煙｜火災］を受信する。
また、本発明の第２の実施の形態によれば、例えば、ある煙センサが煙の発生を検知し、ＭＴＣサーバ１５０へイベント通知メッセージ（イベント情報）を送信すると、ＭＭＥ１２０からＭＴＣグループ内のすべてのＭＴＣデバイス１００へ逆イベント通知メッセージ（イベント情報）が送信される。この場合、ＭＴＣグループ内のすべてのＭＴＣデバイス１００は、デバイス種ＩＤ「煙センサ」及びイベントグループ情報ラベル名「火災」を含む逆イベント通知メッセージ［煙｜火災］を受信する。
逆イベント通知メッセージ［煙｜火災］の受信によって、煙センサは、同じデバイス種からイベント通知メッセージ（イベント情報）が送信されたことを把握し、ノーマルモードに遷移する。一方、炎センサは、異なるデバイス種からイベント通知メッセージ（イベント情報）が送信されたことを把握し、そのまま高優先度モードを維持する。また、人感センサは、ラベル名「火災」を含む逆イベント通知メッセージ（イベント情報）を受信することで、ノーマルモードから高優先度モードへ遷移する。また、ドアロックセンサは、自デバイスとは関連性のない逆イベント通知メッセージ（イベント情報）であることを把握し、そのまま高優先度モードを維持する。
さらに、ある炎センサが炎の発生を検知し、ＭＴＣサーバ１５０へイベント通知メッセージ（イベント情報）を送信したとすると、ＭＭＥ１２０からＭＴＣグループ内のすべてのＭＴＣデバイス１００へ逆イベント通知メッセージ（イベント情報）が送信される。この場合、ＭＴＣグループ内のすべてのＭＴＣデバイス１００は、デバイス種ＩＤ「炎センサ」及びラベル名「火災」を含む逆イベント通知メッセージ［炎｜火災］を受信する。
逆イベント通知メッセージ［炎｜火災］の受信によって、炎センサは、同じデバイス種からイベント通知メッセージが送信されたことを把握し、ノーマルモードに遷移する。一方、煙センサは、同一の出来事（火災の発生）によって引き起こされたイベントの逆イベント通知メッセージ（すなわち、逆イベント通知メッセージ［煙｜火災］）の受信によってノーマルモードへの遷移を行っているので、そのままノーマルモードを維持し続ける。また、人感センサは、同一の出来事（火災の発生）によって引き起こされたイベントの逆イベント通知メッセージ（すなわち、逆イベント通知メッセージ［煙｜火災］）の受信によって高優先度モードへの遷移を既に行っているので、そのまま高優先度モードを維持し続ける。また、ドアロックセンサは、自デバイスとは関連性のない逆イベント通知メッセージであることを把握し、そのまま高優先度モードを維持する。
さらに、ある人感センサが人物の存在を検知し、ＭＴＣサーバ１５０へイベント通知メッセージを送信したとすると、ＭＭＥ１２０からＭＴＣグループ内のすべてのＭＴＣデバイス１００へ逆イベント通知メッセージ（イベント情報）が送信される。この場合、ＭＴＣグループ内のすべてのＭＴＣデバイス１００は、デバイス種ＩＤ「人感センサ」及びラベル名「火災」を含む逆イベント通知メッセージ［人感｜火災］を受信する。
逆イベント通知メッセージ［人感｜火災］の受信によって、人感センサは、同じデバイス種からイベント通知メッセージが送信されたことを把握し、ノーマルモードに遷移する。一方、煙センサ及び炎センサは、同一の出来事（火災の発生）によって引き起こされたイベントの逆イベント通知メッセージ（すなわち、逆イベント通知メッセージ［煙｜火災］及び逆イベント通知メッセージ［炎｜火災］）の受信によってノーマルモードへの遷移を行っているので、そのままノーマルモードを維持し続ける。また、ドアロックセンサは、自デバイスとは関連性のない逆イベント通知メッセージであることを把握し、そのまま高優先度モードを維持する。
図１３の（２）のような動作を実現するためには、例えば、図１４の（Ａ）に図示されているように、例えば、煙センサにラベル名「火災」のイベントグループ情報（炎センサ及び人感センサのデバイス種ＩＤが登録されている）を持たせ、炎センサにラベル名「火災」のイベントグループ情報（煙センサ及び人感センサのデバイス種ＩＤが登録されている）を持たせ、人感センサにラベル名「火災」のイベントグループ情報（炎センサ及び煙センサのデバイス種ＩＤが登録されている）を持たせればよい。なお、ドアロックセンサなどのような関連性のないＭＴＣデバイス１００においては、ラベル名「火災」のイベントグループ情報を持たせないようにしておくか、あるいは、デバイス種ＩＤが登録されていないラベル名「火災」のイベントグループ情報を持たせるようにしておく。
上述の図１４の（Ａ）のようなイベントグループ情報の持たせ方によれば、個々のデバイス種によって異なるイベントグループ情報を持たせることになるが、別の方法として、全ＭＴＣデバイス１００に共通（同一）のイベントグループ情報を持たせるようにすることも可能である。この場合、例えば図９ＢのステップＳ７０８の処理において、逆イベント通知メッセージ（イベント情報）に含まれているデバイス種ＩＤがイベントグループ情報に含まれているかどうかを確認することに加えて、さらに、自デバイス種ＩＤがイベントグループ情報に含まれているかどうかを確認することで、本発明に係る動作が実現可能となる。なお、この場合も、ドアロックセンサなどのような関連性のないＭＴＣデバイス１００においては、ラベル名「火災」のイベントグループ情報を持たせないようにしておいてもよい。
図１４の（Ａ）のように、個々のＭＴＣデバイス１００が異なるイベントグループ情報を持つようにする場合には、モード遷移に関してより詳細な管理を行うことができる。例えば、人感センサが持つラベル名「火災」のイベントグループ情報に、煙センサのみが登録された状態に変更することによって、人感センサは、煙センサのデバイス種ＩＤを含む逆イベント通知メッセージ（イベント情報）を受信した場合には高優先度モードへ遷移するが、炎センサのデバイス種ＩＤを含む逆イベント通知メッセージ（イベント情報）を受信した場合にはノーマルモードをそのまま維持するように設定することが可能となる。なお、このような状態を想定しない場合（特定のイベントに対して、どのデバイス種のＭＴＣデバイス１００からイベント通知メッセージが送信された場合であっても、関連するラベルを持っているＭＴＣデバイス１００は高優先度モードに遷移する場合）は、自デバイス種がそのラベル名に関連付けられているかどうかを確認するだけでよい。すなわち、各ＭＴＣデバイス１００のデバイス種ＩＤが登録されているイベントグループ情報を持つ必要はなく、単に、自デバイス種とラベル名（例えば「火災」）とが関連付けられているかどうかを示す情報を持っているだけでよい。一方、図１４の（Ｂ）のように、ＭＴＣデバイス１００が共通のイベントグループ情報を持つようにする場合には、どのＭＴＣデバイス１００にどのイベントグループ情報を持たせる必要があるかを考慮せずに、全ＭＴＣデバイスに対してイベントグループ情報を一括配信して保持させることが可能となる。
＜図１３の（３）、図１４の（Ｃ）、（Ｄ）＞
また、本発明の第２の実施の形態では、複数のイベントグループ情報を設定することで、イベントごと（ラベル名ごと）に、ＭＴＣデバイス１００のモード遷移を変えることが可能である。例えば、あるドアロックセンサがドアの開錠（不審者侵入の可能性）を検知し、ＭＴＣサーバ１５０へイベント通知メッセージ（イベント情報）を送信すると、ＭＭＥ１２０からＭＴＣグループ内のすべてのＭＴＣデバイス１００へ逆イベント通知メッセージ（イベント情報）が送信される。この場合、ＭＴＣグループ内のすべてのＭＴＣデバイス１００は、デバイス種ＩＤ「ドアロックセンサ」（ここでは、開錠と表記）及びラベル名「侵入」を含む逆イベント通知メッセージ［開錠｜侵入］を受信する。
また、本発明の第２の実施の形態では、複数のイベントグループ情報を設定することで、イベントごと（ラベル名ごと）に、ＭＴＣデバイス１００のモード遷移を変えることが可能である。例えば、あるドアロックセンサがドアの開錠（不審者侵入の可能性）を検知し、ＭＴＣサーバ１５０へイベント通知メッセージ（イベント情報）を送信すると、ＭＭＥ１２０からＭＴＣグループ内のすべてのＭＴＣデバイス１００へ逆イベント通知メッセージ（イベント情報）が送信される。この場合、ＭＴＣグループ内のすべてのＭＴＣデバイス１００は、デバイス種ＩＤ「ドアロックセンサ」（ここでは、開錠と表記）及びラベル名「侵入」を含む逆イベント通知メッセージ［開錠｜侵入］を受信する。
このとき、図１３の（３）のように、例えば、逆イベント通知メッセージ［開錠｜侵入］の受信によって、人感センサのみモード遷移（ノーマルモードから高優先度モード）させ、その後、人感センサが人物の存在を検知し、ＭＴＣサーバ１５０へイベント通知メッセージ（イベント情報）を送信した場合に、他の人感センサのモードを高優先度モードからノーマルモードに戻す動作を行わせるとする。
このような場合には、ＭＴＣデバイス個別にイベントグループ情報を設定する方法において、図１４の（Ｃ）のように、人感センサにラベル名「侵入」のイベントグループ情報（ドアロックセンサのデバイス種ＩＤが登録されている）を持たせるか、あるいは、ＭＴＣデバイス１００に共通のイベントグループ情報を設定する方法において、図１４の（Ｄ）のように、全ＭＴＣデバイス１００にラベル名「侵入」のイベントグループ情報（人感センサ及びドアロックセンサのデバイス種ＩＤが登録されている）を持たせればよい。この場合、少なくとも人感センサは、ラベル名の異なる複数のイベントグループ情報を保持することになる。
＜図１３の（４）＞
また、上述の本発明の第２の実施の形態では、例えば、デバイス種ＩＤ及びイベントグループ情報ラベル（ラベル名）の両方がイベント情報として含まれた逆イベント通知メッセージ（イベント情報）の送信が行われている。しかしながら、イベントグループ情報ラベル（ラベル名）を用いず、イベントグループ情報による詳細な設定が行われないような構成として、デバイス種ＩＤのみを含む逆イベント通知メッセージの送信が行われるようにしてもよい。この方法は、第１の実施の形態における逆イベント通知メッセージによって行われるノーマルモードへのモード遷移の指示を、イベント通知メッセージを送信したＭＴＣデバイス１００と同じ種類のＭＴＣデバイスに対してのみ行うものであると言える。また、図９Ｂの動作（本発明の第２の実施の形態における動作）において、ステップＳ７０７〜Ｓ７０９の処理を行わないものであるとも言える。
また、上述の本発明の第２の実施の形態では、例えば、デバイス種ＩＤ及びイベントグループ情報ラベル（ラベル名）の両方がイベント情報として含まれた逆イベント通知メッセージ（イベント情報）の送信が行われている。しかしながら、イベントグループ情報ラベル（ラベル名）を用いず、イベントグループ情報による詳細な設定が行われないような構成として、デバイス種ＩＤのみを含む逆イベント通知メッセージの送信が行われるようにしてもよい。この方法は、第１の実施の形態における逆イベント通知メッセージによって行われるノーマルモードへのモード遷移の指示を、イベント通知メッセージを送信したＭＴＣデバイス１００と同じ種類のＭＴＣデバイスに対してのみ行うものであると言える。また、図９Ｂの動作（本発明の第２の実施の形態における動作）において、ステップＳ７０７〜Ｓ７０９の処理を行わないものであるとも言える。
例えば、ある煙センサが煙の発生を検知し、ＭＴＣサーバ１５０へイベント通知メッセージを送信すると、ＭＭＥ１２０からＭＴＣグループ内のすべてのＭＴＣデバイス１００へ、デバイス種ＩＤ「煙センサ」を含む逆イベント通知メッセージ（イベント情報）が送信される。
この場合、ＭＴＣグループ内のすべてのＭＴＣデバイス１００が、デバイス種ＩＤ「煙センサ」を含む逆イベント通知メッセージを受信するが、図１３の（４）に図示されているように、この逆イベント通知メッセージに含まれているデバイス種ＩＤと同じ種類のＭＴＣデバイス（すなわち、すべての煙センサ）のみ、モード遷移（ノーマルモードへの遷移）を行う。
＜図１３の（５）、図１４の（Ｅ）＞
また、上述の本発明の第２の実施の形態では、例えば、デバイス種ＩＤ及びイベントグループ情報ラベル（ラベル名）の両方がイベント情報として含まれた逆イベント通知メッセージ（イベント情報）の送信が行われているが、逆イベント通知メッセージ（イベント情報）に、デバイス種ＩＤを挿入せず、イベントグループ情報ラベル（ラベル名）のみを付加することも可能である。この方法は、図９Ｂの動作（本発明の第２の実施の形態における動作）において、ステップＳ７０５の処理を行わないものであると言える。
また、上述の本発明の第２の実施の形態では、例えば、デバイス種ＩＤ及びイベントグループ情報ラベル（ラベル名）の両方がイベント情報として含まれた逆イベント通知メッセージ（イベント情報）の送信が行われているが、逆イベント通知メッセージ（イベント情報）に、デバイス種ＩＤを挿入せず、イベントグループ情報ラベル（ラベル名）のみを付加することも可能である。この方法は、図９Ｂの動作（本発明の第２の実施の形態における動作）において、ステップＳ７０５の処理を行わないものであると言える。
例えば、ある煙センサが煙の発生を検知し、ＭＴＣサーバ１５０へイベント通知メッセージを送信すると、ＭＭＥ１２０からＭＴＣグループ内のすべてのＭＴＣデバイス１００へ、ラベル名「火災」を含む逆イベント通知メッセージが送信される。
ここで、図１４の（Ｅ）に図示されているように、人感センサのみが、自デバイス種とラベル名「火災」とが関連付けられていることを示す情報を持っているとする。なお、図１４の（Ｅ）では、人感センサは、ラベル名「火災」のイベントグループ情報を保持しているのが図示されているように、ラベル名「火災」を含む逆イベント通知メッセージの受信時にモード遷移を行うことが特定できるような情報であれば、情報の持ち方は限定されるものではない。
ＭＴＣグループ内のすべてのＭＴＣデバイス１００が逆イベント通知メッセージ［火災］を受信するが、例えば、煙センサ、炎センサ、ドアロックセンサなどのＭＴＣデバイス１００は、ラベル名「火災」に関連付けられておらず、モード遷移を行わない。一方、人感センサは、ラベル名「火災」に関連付けられており、逆イベント通知メッセージ［火災］の受信によってモード遷移（高優先度モードへの遷移）を行う。
なお、図１３の（５）及び図１４の（Ｅ）の例によれば、人感センサ以外のＭＴＣデバイス１００のモードはそのまま維持される一方、人感センサのモードが高優先度モードへ遷移するため、ＭＴＣデバイス１００からのイベント通知メッセージの送信を抑制できているわけではない。しかしながら、あるＭＴＣデバイス１００からイベント通知メッセージが送信されたことを契機として、通常はノーマルモードで動作しているＭＴＣデバイス１００（例えば、人感センサ）の送信モードを高優先度モードに変更できるという点において有用である。すなわち、通常はノーマルモードで動作しているＭＴＣデバイス１００（人感センサ）を、必要に応じて迅速に高優先度モードに遷移させることが可能となる。
＜第３の実施の形態＞
上記の実施の形態の解決手法によれば、ＭＴＣデバイス１００が通知するイベント通知メッセージとＭＭＥ１２０が送信する逆イベント通知メッセージは、共にＣプレーン上で交換されていたが、ＭＴＣデバイス１００が通知するイベント通知メッセージはＵプレーンで、逆イベント通知メッセージはネットワーク装置（例えば、ＭＭＥ１２０、ＭＴＣサーバ１５０やＰＧＷ１４０）によってＣプレーンが用いられる場合がある。例えば、通信システムのオペレータ、ＭＴＣサーバ１５０やＭＴＣユーザ１６０によって、静的、若しくは、動的に設定されるＭＴＣサービスの仕様や登録情報、また設定情報などに基づいて、ＭＴＣサービスにおけるメッセージは基本的にＵプレーン上で交換すると設定されている場合、イベント（例えば、煙発生）を検知したＭＴＣデバイス１００は、Ｕプレーンを用いてイベント通知メッセージをＰＧＷ１４０／ＭＴＣサーバ１５０に通知する。ここで、ネットワーク装置（例えば、ＰＧＷ１４０／ＭＴＣサーバ１５０）はＭＴＣサービスの仕様や登録情報、また設定情報などに基づいて、イベント通知メッセージの応答である逆イベント通知メッセージをＵプレーンを用いて送信したいが、ＭＭＥ１２０経由で逆イベント通知メッセージを送信しなければならない場合（例えば、ＭＭＥ１２０がイベント通知メッセージに格納されているイベント情報（例えば、デバイスＩＤ／デバイス種ＩＤ）を用いて、ＭＴＣデバイス１００の管理情報を更新しなければならない場合）がある。このようなケースが、本発明の第３の実施の形態に相当する。
上記の実施の形態の解決手法によれば、ＭＴＣデバイス１００が通知するイベント通知メッセージとＭＭＥ１２０が送信する逆イベント通知メッセージは、共にＣプレーン上で交換されていたが、ＭＴＣデバイス１００が通知するイベント通知メッセージはＵプレーンで、逆イベント通知メッセージはネットワーク装置（例えば、ＭＭＥ１２０、ＭＴＣサーバ１５０やＰＧＷ１４０）によってＣプレーンが用いられる場合がある。例えば、通信システムのオペレータ、ＭＴＣサーバ１５０やＭＴＣユーザ１６０によって、静的、若しくは、動的に設定されるＭＴＣサービスの仕様や登録情報、また設定情報などに基づいて、ＭＴＣサービスにおけるメッセージは基本的にＵプレーン上で交換すると設定されている場合、イベント（例えば、煙発生）を検知したＭＴＣデバイス１００は、Ｕプレーンを用いてイベント通知メッセージをＰＧＷ１４０／ＭＴＣサーバ１５０に通知する。ここで、ネットワーク装置（例えば、ＰＧＷ１４０／ＭＴＣサーバ１５０）はＭＴＣサービスの仕様や登録情報、また設定情報などに基づいて、イベント通知メッセージの応答である逆イベント通知メッセージをＵプレーンを用いて送信したいが、ＭＭＥ１２０経由で逆イベント通知メッセージを送信しなければならない場合（例えば、ＭＭＥ１２０がイベント通知メッセージに格納されているイベント情報（例えば、デバイスＩＤ／デバイス種ＩＤ）を用いて、ＭＴＣデバイス１００の管理情報を更新しなければならない場合）がある。このようなケースが、本発明の第３の実施の形態に相当する。
以下、本発明の第３の実施の形態におけるシステム動作の一例について、図１５を用いて詳しく説明する。図１５は、本発明の第３の実施の形態におけるシステム動作の一例（複数のＭＴＣデバイス１００から送信される同一イベント、又は、そのイベントを引き起こした出来事によって引き起こされたイベントによる優先度の高いイベント通知メッセージの送信抑制方法）を説明するためのシーケンス図である。なお、図１５には、図１に図示したシステム構成における処理シーケンスの一例を図示する。ここで、ＭＴＣデバイス１００の特徴は、本発明の第２の実施の形態における特徴と同様であり、ここでは説明を省略する。
以下、図１５に図示されているシーケンスについて説明する。ステップＳ３２１〜ステップＳ３２２は、本発明の第２の実施の形態におけるステップＳ３０１〜ステップＳ３０２（図４を参照）と同様なので、ここでは説明を省略する。
続いて、ＭＴＣデバイスＡ１００Ａは、検知したイベント情報（例えば、煙センサＩＤ）を格納したイベント通知メッセージ（イベント情報）をＵプレーン上で、ＭＴＣサーバ１５０に通知する（ステップＳ３２３：イベント通知メッセージ（イベント情報）＠デバイスＡ）。すなわち、ＭＴＣデバイスＡ１００Ａから通知されるイベント通知メッセージ（イベント情報）＠デバイスＡは、ｅＮＢ１１０、ＳＧＷ１３０、ＰＧＷ１４０、ＭＴＣサーバ１５０という順に転送される。なお、ここでは、ＭＴＣサーバ１５０が、イベント通知メッセージ（イベント情報）の通知先になっているが、通信システムのオペレータ、ＭＴＣサーバ１５０やＭＴＣユーザ１６０によって設定される仕様や登録情報、また設定情報などに基づいて、イベント通知メッセージ（イベント情報）の送信先を他のネットワーク装置（例えば、ＰＧＷ１４０）にしてもよい。
続いて、ＭＴＣサーバ１５０は、受信したイベント通知メッセージ（イベント情報）からイベント情報を抽出し、逆イベント通知メッセージに格納する。そして、ＭＴＣサーバ１５０は、同一イベント（例えば、煙の発生）、若しくは、そのイベント（例えば、煙発生）を引き起こした出来事（例えば、火災発生）によって引き起こされたイベント（例えば、炎の発生）によるイベント通知メッセージの送信を抑制するために、逆イベント通知メッセージをＭＭＥ１２０に送信する。続いて、ＭＭＥ１２０がＣプレーンを用いてＭＴＣグループに属するＭＴＣデバイス１００に逆イベント通知メッセージをブロードキャスト（ステップＳ３２４：逆イベント通知メッセージ（イベント情報））。なお、ここでは、ＭＭＥ１２０が逆イベント通知メッセージを生成しているが、他のネットワーク装置（例えば、ＭＴＣサーバ１５０やＰＧＷ１４０が生成してもよい。その場合、ＭＭＥ１２０でないネットワーク装置（ＭＴＣサーバ１５０やＰＧＷ１４０）がブロードキャストしてもよい。
逆イベント通知メッセージを送信したＭＭＥ１２０は、逆イベント通知メッセージに格納されていたイベント情報（例えば、デバイスＩＤ）を抽出し、再度逆イベント通知メッセージをブロードキャストするか判断する際に使用するために記憶する（ステップＳ３２５：イベント情報の記憶）。なお、ステップＳ３２６以降は、本発明の第２の実施の形態のステップＳ３０６以降と同様なので、ここでは説明を省略する。
本発明の第３の実施の形態のように、ＭＴＣデバイス１００が通知するイベント通知メッセージはＵプレーンで、ネットワーク装置（例えば、ＭＭＥ１２０、ＭＴＣサーバ１５０やＰＧＷ１４０）から送信される逆イベント通知メッセージはＣプレーンを用いることで、ＭＴＣサービスにおけるメッセージが基本的にＵプレーンを用いて送信されると設定されている環境において、ネットワーク装置（例えば、ＰＧＷ１４０、ＭＴＣサーバ１５０）が、ＭＭＥ１２０経由（Ｃプレーン）で逆イベント通知メッセージを送信しなければいけない場合（例えば、ＭＭＥ１２０がイベント通知メッセージに格納されているイベント情報（例えば、デバイスＩＤ／デバイス種ＩＤ）を用いて、ＭＴＣデバイス１００の管理情報を更新しなければならない場合）に対応することができる。
＜第４の実施の形態＞
本発明の第４の実施の形態では、ＭＴＣデバイス１００が通知するイベント通知メッセージはＣプレーンで、ネットワーク装置（例えば、ＭＴＣサーバ１５０やＰＧＷ１４０）から送信される逆イベント通知メッセージはＵプレーンが用いられる場合について説明する。例えば、通信システムのオペレータ、ＭＴＣサーバ１５０やＭＴＣユーザ１６０によって、静的、若しくは、動的に設定されるＭＴＣサービスの仕様や登録情報、また設定情報などに基づいて、ＭＴＣサービスにおけるメッセージが基本的にＵプレーンを用いて送信されると設定されている環境において、ＭＴＣデバイス１００がイベント（例えば、煙発生）を検知したとする。本来であれば、ＭＴＣデバイス１００はＵプレーンを用いて、イベント通知メッセージをＰＧＷ１４０／ＭＴＣサーバ１５０に通知するが、ＭＭＥ１２０がＭＴＣデバイス１００の管理に必要とする情報が伴う場合（例えば、ＭＴＣデバイス１００が移動可能な煙センサ（例えば、煙発生を検知可能な移動ロボット）であり、イベント情報に加えてＭＴＣデバイス１００の位置情報を通知する場合や、ＭＴＣサービスがＭＴＣデバイス１００の位置情報も付加してイベント情報を通知するＭＴＣサービス（例えば、ＭＴＣデバイス１００が車などに搭載されていて、イベント検知時、位置情報も付加して送信するサービス）である場合）、あらかじめ通信システムのオペレータ、ＭＴＣサーバ１５０、ＭＴＣユーザ１６０によって設定されている仕様、登録情報や設定情報に基づいて、ＭＴＣデバイス１００の判断でＣプレーンを用いてイベント通知メッセージを通知する場合がある。
本発明の第４の実施の形態では、ＭＴＣデバイス１００が通知するイベント通知メッセージはＣプレーンで、ネットワーク装置（例えば、ＭＴＣサーバ１５０やＰＧＷ１４０）から送信される逆イベント通知メッセージはＵプレーンが用いられる場合について説明する。例えば、通信システムのオペレータ、ＭＴＣサーバ１５０やＭＴＣユーザ１６０によって、静的、若しくは、動的に設定されるＭＴＣサービスの仕様や登録情報、また設定情報などに基づいて、ＭＴＣサービスにおけるメッセージが基本的にＵプレーンを用いて送信されると設定されている環境において、ＭＴＣデバイス１００がイベント（例えば、煙発生）を検知したとする。本来であれば、ＭＴＣデバイス１００はＵプレーンを用いて、イベント通知メッセージをＰＧＷ１４０／ＭＴＣサーバ１５０に通知するが、ＭＭＥ１２０がＭＴＣデバイス１００の管理に必要とする情報が伴う場合（例えば、ＭＴＣデバイス１００が移動可能な煙センサ（例えば、煙発生を検知可能な移動ロボット）であり、イベント情報に加えてＭＴＣデバイス１００の位置情報を通知する場合や、ＭＴＣサービスがＭＴＣデバイス１００の位置情報も付加してイベント情報を通知するＭＴＣサービス（例えば、ＭＴＣデバイス１００が車などに搭載されていて、イベント検知時、位置情報も付加して送信するサービス）である場合）、あらかじめ通信システムのオペレータ、ＭＴＣサーバ１５０、ＭＴＣユーザ１６０によって設定されている仕様、登録情報や設定情報に基づいて、ＭＴＣデバイス１００の判断でＣプレーンを用いてイベント通知メッセージを通知する場合がある。
以下、本発明の第４の実施の形態におけるシステム動作の一例について、図１６を用いて詳しく説明する。図１６は、本発明の第４の実施の形態におけるシステム動作の一例（複数のＭＴＣデバイス１００から送信される同一イベント、又は、そのイベントを引き起こした出来事によって引き起こされたイベントによる優先度の高いイベント通知メッセージの送信抑制方法）を説明するためのシーケンス図である。なお、図１６には、図１に図示したシステム構成における処理シーケンスの一例を図示する。ここで、ＭＴＣデバイス１００の特徴は、本発明の第２の実施の形態における特徴と同様であり、ここでは説明を省略する。
以下、図１６に図示されているシーケンスについて説明する。ステップＳ３４１〜ステップＳ３４２は、本発明の第２の実施の形態におけるステップＳ３０１〜ステップＳ３０２（図４を参照）と同様なので、ここでは説明を省略する。
続いて、ＭＴＣデバイスＡ１００Ａは、検知したイベント情報（例えば、煙センサＩＤ）を格納したイベント通知メッセージ（イベント情報）をＣプレーン上で、ＭＭＥ１２０に通知する（ステップＳ３４３：イベント通知メッセージ（イベント情報）＠デバイスＡ）。
ＭＭＥ１２０は、ＭＴＣデバイスＡ１００Ａからイベント通知メッセージ（イベント情報）＠デバイスＡを受信し、必要な情報（例えば、ＭＴＣデバイスＡ１００Ａの位置情報やデバイスＩＤなど）を抽出し、例えば、ＭＴＣデバイスＡ１００Ａの管理処理（例えば、ＭＴＣデバイスＡ１００Ａのコンテキスト情報の更新や、位置情報の更新など）を行う（ステップＳ３４４：デバイスＡ管理処理）。
そして、ＭＭＥ１２０は、イベント通知メッセージ（イベント情報）＠デバイスＡに格納されていたイベント情報（例えば、デバイスＩＤやデバイス種ＩＤ）を抽出し、再度逆イベント通知メッセージをブロードキャストするか判断する際に使用するために記憶する（ステップＳ３４５：イベント情報の記憶）。
続いて、ＭＭＥ１２０は、受信したイベント通知メッセージ（イベント情報）をＭＴＣサーバ１５０に転送する（ステップＳ３４６）。このとき、ＭＭＥ１２０は、通信システムのオペレータ、ＭＴＣサーバ１５０やＭＴＣユーザ１６０によって設定された仕様、登録情報や設定情報に基づいて、受信したイベント通知メッセージ（イベント情報）＠デバイスＡをそのまま転送、若しくは、必要な情報（例えば、イベント情報）のみをＭＴＣサーバ１５０に送信する。なお、ここでは、ＭＴＣサーバ１５０が、イベント通知メッセージ（イベント情報）の通知先になっているが、通信システムのオペレータ、ＭＴＣサーバ１５０やＭＴＣユーザ１６０によって設定される仕様や登録情報、また設定情報などに基づいて、イベント通知メッセージ（イベント情報）の送信先を他のネットワーク装置（例えば、ＰＧＷ１４０）にしてもよい。なお、ステップＳ３４４のデバイスＡ管理処理からステップＳ３４６のイベント通知メッセージ（イベント情報）＠デバイスＡの転送処理は、順不同で実施してもよい。
続いて、ＭＴＣサーバ１５０は、受信したイベント通知メッセージ（イベント情報）からイベント情報を抽出し、逆イベント通知メッセージに格納する。そして、ＭＴＣサーバ１５０は、同一イベント（例えば、煙の発生）、若しくは、そのイベント（例えば、煙発生）を引き起こした出来事（例えば、火災発生）によって引き起こされたイベント（例えば、炎の発生）によるイベント通知メッセージの送信を抑制するために、逆イベント通知メッセージ（イベント情報）をＵプレーンを用いてＭＴＣグループに属するＭＴＣデバイス１００にブロードキャストする（ステップＳ３４７：逆イベント通知メッセージ（イベント情報））。ステップＳ３４８以降は、本発明の第２の実施の形態のステップＳ３０６以降と同様なので、ここでは説明を省略する。
本発明の第４の実施の形態のように、ＭＴＣデバイス１００が通知するイベント通知メッセージはＣプレーンで、ネットワーク装置（例えば、ＭＴＣサーバ１５０やＰＧＷ１４０）から送信される逆イベント通知メッセージはＵプレーンを用いることで、ＭＴＣサービスにおけるメッセージが基本的にＵプレーンを用いて送信されると設定されている環境において、ＭＴＣデバイス１００が、ＭＭＥ１２０経由（Ｃプレーン）でイベント通知メッセージを送信しなければいけない場合（例えば、ＭＭＥ１２０がイベント通知メッセージに格納されているイベント情報（例えば、デバイスＩＤ／デバイス種ＩＤ）やＭＴＣデバイス１００の位置情報を用いて、ＭＴＣデバイス１００の管理情報を更新しなければならない場合）に対応することができる。
＜第５の実施の形態＞
本発明の第５の実施の形態では、ＭＴＣデバイス１００が通知するイベント通知メッセージはＵプレーンで、ネットワーク装置（例えば、ＭＴＣサーバ１５０やＰＧＷ１４０）から送信される逆イベント通知メッセージも同様にＵプレーンが用いられる場合について説明する。すなわち、ＭＴＣデバイス１００から通知されるイベント通知メッセージ（イベント情報）とネットワーク装置（例えば、ＭＴＣサーバ１５０やＰＧＷ１４０）から送信される逆イベント通知メッセージ（イベント情報）が、共にＵプレーン上で交換される場合について説明する。例えば、通信システムのオペレータ、ＭＴＣサーバ１５０やＭＴＣユーザ１６０によって、静的、若しくは、動的に設定されるＭＴＣサービスの仕様や登録情報、また設定情報などに基づいて、ＭＴＣサービスにおける全てのメッセージがＵプレーンを用いて送信されると設定されている環境である。すなわち、ＭＴＣデバイスＡ１００Ａから通知されるイベント通知メッセージ（イベント情報）＠デバイスＡは、ｅＮＢ１１０、ＳＧＷ１３０、ＰＧＷ１４０、ＭＴＣサーバ１５０という順で転送され、ＭＴＣサーバ１５０から送信される逆イベント通知メッセージ（イベント情報）は、ＰＧＷ１４０、ＳＧＷ１３０、ｅＮＢ１１０、ＭＴＣデバイス１００という順で転送される。つまり、ＭＭＥ１２０は介さず、ＭＴＣサービスのメッセージが交換される。例えば、ＭＴＣサービスにおけるメッセージ（例えば、イベントを検知した情報や、センシングデータなど）は、ＭＴＣデバイス１００の位置情報などを更新するメッセージ（例えば、ＴＡＵ、ＲＡＵ、ページングなど）を除いて、全てアプリケーション情報と解釈し、ＭＴＣデバイス１００やＵＥ１０５のモビリティ制御やＰＤＮコネクション・ＥＰＳベアラを管理、ＱｏＳなどを管理するためのＣプレーンではなく、ユーザデータ（アプリケーション情報）を転送するＵプレーンでのみ交換しなくてはならないという環境が、本発明の第５の実施の形態に相当する。
本発明の第５の実施の形態では、ＭＴＣデバイス１００が通知するイベント通知メッセージはＵプレーンで、ネットワーク装置（例えば、ＭＴＣサーバ１５０やＰＧＷ１４０）から送信される逆イベント通知メッセージも同様にＵプレーンが用いられる場合について説明する。すなわち、ＭＴＣデバイス１００から通知されるイベント通知メッセージ（イベント情報）とネットワーク装置（例えば、ＭＴＣサーバ１５０やＰＧＷ１４０）から送信される逆イベント通知メッセージ（イベント情報）が、共にＵプレーン上で交換される場合について説明する。例えば、通信システムのオペレータ、ＭＴＣサーバ１５０やＭＴＣユーザ１６０によって、静的、若しくは、動的に設定されるＭＴＣサービスの仕様や登録情報、また設定情報などに基づいて、ＭＴＣサービスにおける全てのメッセージがＵプレーンを用いて送信されると設定されている環境である。すなわち、ＭＴＣデバイスＡ１００Ａから通知されるイベント通知メッセージ（イベント情報）＠デバイスＡは、ｅＮＢ１１０、ＳＧＷ１３０、ＰＧＷ１４０、ＭＴＣサーバ１５０という順で転送され、ＭＴＣサーバ１５０から送信される逆イベント通知メッセージ（イベント情報）は、ＰＧＷ１４０、ＳＧＷ１３０、ｅＮＢ１１０、ＭＴＣデバイス１００という順で転送される。つまり、ＭＭＥ１２０は介さず、ＭＴＣサービスのメッセージが交換される。例えば、ＭＴＣサービスにおけるメッセージ（例えば、イベントを検知した情報や、センシングデータなど）は、ＭＴＣデバイス１００の位置情報などを更新するメッセージ（例えば、ＴＡＵ、ＲＡＵ、ページングなど）を除いて、全てアプリケーション情報と解釈し、ＭＴＣデバイス１００やＵＥ１０５のモビリティ制御やＰＤＮコネクション・ＥＰＳベアラを管理、ＱｏＳなどを管理するためのＣプレーンではなく、ユーザデータ（アプリケーション情報）を転送するＵプレーンでのみ交換しなくてはならないという環境が、本発明の第５の実施の形態に相当する。
以下、本発明の第５の実施の形態におけるシステム動作の一例について、図１７を用いて詳しく説明する。図１７は、本発明の第５の実施の形態におけるシステム動作の一例（複数のＭＴＣデバイス１００から送信される同一イベント、又は、そのイベントを引き起こした出来事によって引き起こされたイベントによる優先度の高いイベント通知メッセージの送信抑制方法）を説明するためのシーケンス図である。なお、図１７には、図１に図示したシステム構成における処理シーケンスの一例を図示する。ここで、ＭＴＣデバイス１００の特徴は、本発明の第２の実施の形態における特徴と同様であり、ここでは説明を省略する。
以下、図１７に図示されているシーケンスについて説明する。ステップＳ３６１〜ステップＳ３６２は、本発明の第２の実施の形態におけるステップＳ３０１〜ステップＳ３０２と同様なので、ここでは説明を省略する。
続いて、ＭＴＣデバイスＡ１００Ａは、検知したイベント情報（例えば、煙センサＩＤ）を格納したイベント通知メッセージ（イベント情報）をＵプレーン上で、ＭＴＣサーバ１５０に通知する（ステップＳ３６３：イベント通知メッセージ（イベント情報）＠デバイスＡ）。すなわち、ＭＴＣデバイスＡ１００Ａから通知されるイベント通知メッセージ（イベント情報）＠デバイスＡは、ｅＮＢ１１０、ＳＧＷ１３０、ＰＧＷ１４０、ＭＴＣサーバ１５０という順で転送される。なお、ここでは、ＭＴＣサーバ１５０が、イベント通知メッセージ（イベント情報）の通知先になっているが、通信システムのオペレータ、ＭＴＣサーバ１５０やＭＴＣユーザ１６０によって設定される仕様や登録情報、また設定情報などに基づいて、イベント通知メッセージ（イベント情報）の送信先を他のネットワーク装置（例えば、ＰＧＷ１４０）にしてもよい。
続いて、ＭＴＣサーバ１５０は、受信したイベント通知メッセージ（イベント情報）のイベント情報（例えば、デバイスＩＤやデバイス種ＩＤ）を逆イベント通知メッセージに格納し、Ｕプレーンを用いてＭＴＣグループに属するＭＴＣデバイス１００にブロードキャストする（ステップＳ３６４：逆イベント通知メッセージ（イベント情報））。
続いて、ＭＴＣサーバ１５０は、同一イベント（例えば、煙の発生）、若しくは、そのイベント（例えば、煙発生）を引き起こした出来事（例えば、火災発生）によって引き起こされたイベント（例えば、炎の発生）によるイベント通知メッセージの送信を抑制するために、イベント通知メッセージ（イベント情報）＠デバイスＡに格納されているイベント情報（例えば、デバイスＩＤやデバイス種ＩＤ）を記憶する（ステップＳ３６５：イベント情報の記憶）。ステップＳ３６６以降は、本発明の第２の実施の形態のステップＳ３０６以降と同様なので、ここでは説明を省略する。
本発明の第５の実施の形態のように、ＭＴＣデバイス１００が通知するイベント通知メッセージとネットワーク装置（例えば、ＭＴＣサーバ１５０やＰＧＷ１４０）が送信する逆イベント通知メッセージが共にＵプレーンを用いることで、例えばＭＴＣサービスにおけるメッセージ（例えば、イベントを検知した情報や、センシングデータなど）は、ＭＴＣデバイス１００の位置情報などを更新するメッセージ（例えば、ＴＡＵ、ＲＡＵ、ページングなど）を除いて、全てアプリケーション情報と解釈し、ＭＴＣデバイス１００やＵＥ１０５のモビリティ制御やＰＤＮコネクション・ＥＰＳベアラを管理、ＱｏＳなどを管理するためのＣプレーンではなく、ユーザデータ（アプリケーション情報）を転送するＵプレーン上で交換しなくてはならないという環境に対応することができる。
＜第６の実施の形態＞
また、上記の各実施の形態では、ＰＧＷ１４０をデータゲートウェイとするＥＰＳ（Evolved Packet System）アーキテクチャを用いた例について説明したが、それ以外にも、例えばＧＰＲＳ（General Packet Radio Service）アーキテクチャや、ＵＭＴＳ（Universal Mobile Telecommunications System）アーキテクチャ、またそれらアーキテクチャが混在するような構成においても、同様に実施可能であることは当業者にとって明らかである。
また、上記の各実施の形態では、ＰＧＷ１４０をデータゲートウェイとするＥＰＳ（Evolved Packet System）アーキテクチャを用いた例について説明したが、それ以外にも、例えばＧＰＲＳ（General Packet Radio Service）アーキテクチャや、ＵＭＴＳ（Universal Mobile Telecommunications System）アーキテクチャ、またそれらアーキテクチャが混在するような構成においても、同様に実施可能であることは当業者にとって明らかである。
例えば、ＧＰＲＳアーキテクチャやＵＭＴＳアーキテクチャに基づく構成の場合、上述したようなＭＭＥ１２０とＳＧＷ１３０の役割をＳＧＳＮ（Serving GPRS Support Node）が担い、相当する処理を実施する。また、同様にＰＧＷ１４０の役割をＧＧＳＮ（Gateway GPRS Support Node）が担い、相当する処理を実施する。さらには、ＰＤＮコネクションと同等の論理通信路として、ＰＤＰコンテキストが用いられる。いくつかのメッセージについては、その表記やシグナリングの手順、またメッセージの順序などが若干異なる場合があるが、本発明による実施においては問題ではない。なお、その他の通信システム（例えば、ＷＬＡＮなどのローカル通信システムやＷｉＭＡＸなどの広域通信システム、３ＧＰＰ２などのセルラシステム、その他自営通信システムなど）においても同様に実施可能である。
＜第７の実施の形態＞
上記の実施の形態では、図１のＭＴＣ通信ネットワークの構成において、複数のＭＴＣデバイス１００が１つのＭＴＣグループとしてまとめられ、各ＭＴＣデバイスが３Ｇアクセス（例えば、Ｅ−ＵＴＲＡＮ１１５）への通信インタフェースを保持し、３Ｇアクセスを介して、ＭＴＣデバイス１００が検知したイベントや、センシングデータをＭＴＣサーバ１５０に送信するアーキテクチャを用いた例について説明した。しかし、それ以外にも、例えば、ＭＴＣデバイス１００と３Ｇアクセスとの間にＭＴＣデバイスゲートウェイを設け、ＭＴＣデバイスゲートウェイがＭＴＣデバイスから送信されたメッセージを転送するアーキテクチャにおいても実施可能であることが明らかである。本発明の第７の実施の形態におけるＭＴＣ通信ネットワークの構成の一例を図１８に示す。
上記の実施の形態では、図１のＭＴＣ通信ネットワークの構成において、複数のＭＴＣデバイス１００が１つのＭＴＣグループとしてまとめられ、各ＭＴＣデバイスが３Ｇアクセス（例えば、Ｅ−ＵＴＲＡＮ１１５）への通信インタフェースを保持し、３Ｇアクセスを介して、ＭＴＣデバイス１００が検知したイベントや、センシングデータをＭＴＣサーバ１５０に送信するアーキテクチャを用いた例について説明した。しかし、それ以外にも、例えば、ＭＴＣデバイス１００と３Ｇアクセスとの間にＭＴＣデバイスゲートウェイを設け、ＭＴＣデバイスゲートウェイがＭＴＣデバイスから送信されたメッセージを転送するアーキテクチャにおいても実施可能であることが明らかである。本発明の第７の実施の形態におけるＭＴＣ通信ネットワークの構成の一例を図１８に示す。
図１８において、図１と異なる点は、ＭＴＣデバイス１００とｅＮＢ１１０（３Ｇアクセス）との間にＭＴＣデバイスゲートウェイ１０２が存在することである。
図１８において、ＭＴＣデバイスゲートウェイ１０２は、３Ｇアクセス１１５と通信するための通信インタフェースを１つ以上持つ。さらに、ＭＴＣデバイスゲートウェイ１０２は、複数のＭＴＣデバイス１００と通信するための通信インタフェース（例えば、通信バスを設け、そのバスへの通信インタフェースや、有線ＬＡＮのような通信インタフェースや、Ｚｉｇｂｅｅ（ジグビー）（登録商標）や無線ＬＡＮなどの無線通信プロトコル）を持つ。
一方、ＭＴＣデバイス１００は、上記の各実施の形態のＭＴＣデバイス１００とは異なり、３Ｇアクセスへの通信インタフェースを持っていなくてもよい。すなわち、ＭＴＣデバイス１００は、検知したイベント情報やセンシングデータを直接３Ｇアクセス経由でＭＴＣサーバ１５０に送信することができなくてもよい。その代わり、ＭＴＣデバイス１００が検知したイベント情報やセンシングデータは、ＭＴＣデバイスゲートウェイ１０２に送信することで、ＭＴＣデバイスゲートウェイ１０２が３Ｇアクセスを経由して、ネットワーク装置（例えば、ＭＭＥ１２０、ＰＧＷ１４０やＭＴＣサーバ１５０）に転送する。このように、ＭＴＣデバイスゲートウェイ１０２が、ＭＴＣデバイス１００が取得したデータをまとめて送信することで、通信システムのオペレータ、ＭＴＣサーバ１５０やＭＴＣユーザ１６０は、個別にＭＴＣデバイス１００を管理する必要がなくなり、処理負荷とリソースが軽減される。また、３Ｇアクセスに通信する装置をＭＴＣデバイスゲートウェイ１０２にまとめることで、例えば、全ＭＴＣデバイス１００に高価な３Ｇアクセスへの通信インタフェースを搭載する必要がなくなり、コスト削減を図ることもできる。なお、本発明の第７の実施の形態は、マンションやビル、集合住宅などを監視するシステムを管理する業者において、現実的な実施の形態と言える。
また、第１の実施の形態で説明したように、少なくともＭＴＣデバイスゲートウェイ１０２が複数のＭＴＣデバイス１００から送信されたデータの優先度レベルを確認することができ、ネットワーク側で混雑状態が起こっているとき（例えば、ｅＮＢ１１０、ＭＭＥ１２０やＰＧＷ１４０がオーバーフロー）や、ＭＴＣユーザ１６０が通信システムオペレータと特別な契約（例えば、高額な利用料金の課金ルールを結ぶことで、優先的なデータ転送がされる契約）を保持するとき、又は、オペレータ方針によって一定の優先度レベルを用いたデータ転送の指示が配布されたとき（例えば、優先度レベル３以上はデータ転送可のとき）には、ＭＴＣデバイスゲートウェイ１０２が優先度レベルを確認しながら（例えば、ネットワーク側が示す許容優先度レベルとＭＴＣデバイス１００から転送されるデータに格納された優先度レベルを比較する。または、ＭＴＣデバイス１００やＭＴＣデバイスゲートウェイ１０２にあらかじめ組み込まれているコンテキスト（例えば、混雑度レベル３のときは優先度レベル３以上のメッセージのみ送信許容などのルールが登録されているコンテキスト）やアプリケーションデータに含まれている優先度レベルを確認する）、転送データの選択をすることで、優先度レベルが高いデータのみネットワーク側へ転送することができる（優先度の低いデータの転送は後回し（例えば、混雑状態の解消後）にすることができる）。これにより、ネットワーク側の混雑状態が起こっている場合でも、ＭＴＣユーザ１６０やＭＴＣサーバ１５０は、優先的に収集しているデータを受信することができる。
また、ＭＴＣデバイス１００がＭＴＣデバイスゲートウェイ１０２の役割を担うことも可能である。この場合、ＭＴＣデバイスゲートウェイ１０２となるＭＴＣデバイス１００の負荷が増えることが予想され、負荷を分散する手段が必要となり得る。例えば、ＭＴＣデバイスゲートウェイ１０２の役割を、ＭＴＣグループの各ＭＴＣデバイス１００で順番に（例えば、時間で区切って）担当していくなどして負荷分散することが可能である。
＜第８の実施の形態＞
上記の実施の形態では、ネットワーク側で混雑状態になる前にネットワーク側の装置（例えば、ｅＮＢ１１０、ＭＭＥ１２０や、ＳＧＷ１３０、ＰＧＷ１４０、ＭＴＣサーバ１５０）から逆イベント通知メッセージが通知され、ＭＴＣデバイス１００から送信される冗長なイベント通知メッセージの送信を抑制し、ネットワーク側の混雑状態を回避していた。しかし、既にネットワーク側で混雑状態が起こっているとき、若しくは、あるメッセージ（例えば、ＰＤＮコネクション確立リクエストや、転送データ）を受信した時点で混雑状態が起こり始めたときに、ＵＥ１０５などから優先度の高い緊急メッセージ（Ｅｍｅｒｇｅｎｃｙ ｒｅｑｕｅｓｔや、Ｅｍｅｒｇｅｎｃｙ ｍｅｓｓａｇｅとも呼ばれる）やデータ（アプリケーションメッセージ）、ＰＤＮコネクション確立リクエストが送られてきた場合、更なるリソース（Ｕ−ｐｌａｎｅ（Ｕプレーン）、Ｃ−ｐｌａｎｅ（Ｃプレーン）共）が必要となる。例えば、通信システムのエンティティ（例えば、ｅＮＢ１１０やＭＭＥ１２０、ＳＧＷ１３０、ＰＧＷ１４０）における処理能力のリソース（例えば、データ転送における処理）や、ＭＴＣデバイス１００やＵＥ１０５に割り当てる通信リソースや帯域リソースなどがある。このような課題も解決するために、既に確立済みであるＰＤＮコネクションをＵＥ１０５やＭＴＣデバイス１００、ネットワーク側のエンティティ（例えば、ｅＮＢ１１０やＭＭＥ１２０、ＳＧＷ１３０、ＰＧＷ１４０、ＭＴＣサーバ１５０）が保持する優先度レベル（例えば、ＵＥ１０５やＭＴＣデバイス１００に割り当てられる優先度レベルや、送信するデータの優先度レベルや、ＱＣＩやＡＲＰ）を用いて選択的に切断すること、あるいは、新規ＰＤＮコネクションの確立を制御することで優先度レベルの高いリクエストやメッセージ、アプリケーションのためのリソースを確保する。なお、この本発明の第８の実施の形態は、ＭＴＣデバイス１００やＵＥ１０５が多く存在するエリアで起こり得る現実的な実施の形態である。
上記の実施の形態では、ネットワーク側で混雑状態になる前にネットワーク側の装置（例えば、ｅＮＢ１１０、ＭＭＥ１２０や、ＳＧＷ１３０、ＰＧＷ１４０、ＭＴＣサーバ１５０）から逆イベント通知メッセージが通知され、ＭＴＣデバイス１００から送信される冗長なイベント通知メッセージの送信を抑制し、ネットワーク側の混雑状態を回避していた。しかし、既にネットワーク側で混雑状態が起こっているとき、若しくは、あるメッセージ（例えば、ＰＤＮコネクション確立リクエストや、転送データ）を受信した時点で混雑状態が起こり始めたときに、ＵＥ１０５などから優先度の高い緊急メッセージ（Ｅｍｅｒｇｅｎｃｙ ｒｅｑｕｅｓｔや、Ｅｍｅｒｇｅｎｃｙ ｍｅｓｓａｇｅとも呼ばれる）やデータ（アプリケーションメッセージ）、ＰＤＮコネクション確立リクエストが送られてきた場合、更なるリソース（Ｕ−ｐｌａｎｅ（Ｕプレーン）、Ｃ−ｐｌａｎｅ（Ｃプレーン）共）が必要となる。例えば、通信システムのエンティティ（例えば、ｅＮＢ１１０やＭＭＥ１２０、ＳＧＷ１３０、ＰＧＷ１４０）における処理能力のリソース（例えば、データ転送における処理）や、ＭＴＣデバイス１００やＵＥ１０５に割り当てる通信リソースや帯域リソースなどがある。このような課題も解決するために、既に確立済みであるＰＤＮコネクションをＵＥ１０５やＭＴＣデバイス１００、ネットワーク側のエンティティ（例えば、ｅＮＢ１１０やＭＭＥ１２０、ＳＧＷ１３０、ＰＧＷ１４０、ＭＴＣサーバ１５０）が保持する優先度レベル（例えば、ＵＥ１０５やＭＴＣデバイス１００に割り当てられる優先度レベルや、送信するデータの優先度レベルや、ＱＣＩやＡＲＰ）を用いて選択的に切断すること、あるいは、新規ＰＤＮコネクションの確立を制御することで優先度レベルの高いリクエストやメッセージ、アプリケーションのためのリソースを確保する。なお、この本発明の第８の実施の形態は、ＭＴＣデバイス１００やＵＥ１０５が多く存在するエリアで起こり得る現実的な実施の形態である。
以下、本発明の第８の実施の形態について、図１９〜２４を用いて説明する。
ここで、本発明の第８の実施の形態の説明を容易化するために、図１９と図２０におけるＭＴＣデバイスＢとＭＴＣデバイスＤとＭＴＣデバイスＥとＭＴＣデバイスＦは、非特許文献１で定義されている“Ｔｉｍｅ ｔｏｌｅｒａｎｔ（タイムトレラント）”（耐時間性）を有していることを前提とする。
この“Ｔｉｍｅ ｔｏｌｅｒａｎｔ”の機能を保持しているＭＴＣデバイス１００は、ネットワークが混雑状態の場合やオペレータ方針などによって、メッセージ（例えば、ＰＤＮコネクション確立リクエストやデータ転送）の送信タイミングを遅らせることができる。この“Ｔｉｍｅ ｔｏｌｅｒａｎｔ”の動作について、図１９を用いて説明する。図１９は、ＭＴＣデバイスＡとＭＴＣデバイスＢとＭＴＣデバイスＣが既にＰＤＮコネクションを確立済みで各ＭＴＣデバイス１００から３Ｇアクセス側にデータ転送をしており（図１９の（Ａ）データ転送）、ＭＴＣデバイスＤとＭＴＣデバイスＥとＭＴＣデバイスＦが順次的に、これからＰＤＮコネクションを確立し、３Ｇアクセス側にデータ転送を行おうとしている状態である（ＭＴＣデバイスＡ〜ＣはＣｏｎｎｅｃｔｅｄ ｍｏｄｅであり、ＭＴＣデバイスＤ〜Ｆは順次的にＩＤＬＥ ｍｏｄｅからＣｏｎｎｅｃｔｅｄ ｍｏｄｅになろうとしている状態）。このとき、ＭＴＣデバイスＤがＰＤＮコネクションを確立しようとした際に、３Ｇアクセス側で混雑状態が発生してしまうとする（例えば、３Ｇアクセス側で許容できるトラフィック量を超えてしまう）（図１９の（Ｆ）混雑発生）。この場合、３Ｇアクセス側は、ＭＴＣデバイスＤのＰＤＮコネクションの確立を拒絶することを示すＰＤＮコネクション確立拒絶メッセージをＭＴＣデバイスＤに返信した後に、３Ｇアクセス側で混雑状態になっていることを通知するメッセージ（図１９の（Ｂ）送信制御メッセージ）を対象となるＭＴＣデバイス１００（本発明の第８の実施の形態では、ＭＴＣデバイスＡ〜Ｆである。実環境では、例えば、特定のＡＰＮに接続しているＭＴＣデバイス１００、特定のＭＴＣグループに属しているＭＴＣデバイス１００、特定のオペレータに属しているＭＴＣデバイス１００、特定のエリア（例えば、特定のｅＮＢ１１０やＭＭＥ１２０に接続しているＭＴＣデバイス）など）にブロードキャスト送信する。なお、ネットワークが混雑状態を認識するタイミングは、上記のようにＭＴＣデバイスＤのＰＤＮコネクション確立要求を受けた際に限定されず、既にＰＤＮコネクションを確立しているＭＴＣデバイスによって送信されたデータによって輻輳が発生した、あるいは発生しそうである場合に、送信制御メッセージを対象となるＭＴＣデバイスが属するエリアへブロードキャスト送信する。なお、（Ｂ）送信制御メッセージには、例えば、ＭＴＣデバイス１００から送信されるメッセージ（例えば、ＰＤＮコネクション確立リクエスト）をどのくらい遅らせるかを示す値（例えば、待機時間）が格納されていることとする（図１９の（Ｃ）待機時間）。待機時間が格納された（Ｂ）送信制御メッセージを受信したＭＴＣデバイス１００は、“Ｔｉｍｅ ｔｏｌｅｒａｎｔ”の機能を保持しているか確認する。
“Ｔｉｍｅ ｔｏｌｅｒａｎｔ”の機能を保持しているＭＴＣデバイス１００は、（Ｂ）送信制御メッセージを受信した後、３Ｇアクセスから示された値（例えば、待機時間）に基づいて、送信メッセージのタイミングを遅らせることができる（例えば、図１９の（Ｄ）から（Ｅ））。なお、ここでは３Ｇアクセスから示された値（待機時間）に基づいて送信メッセージのタイミングを遅らせているが、例えばＭＴＣデバイスが値（待機時間）を計算してもよく、また、ＭＴＣサーバ１５０などの外部サーバに値（待機時間）を問い合わせてもよい。
“Ｔｉｍｅ ｔｏｌｅｒａｎｔ”の機能を保持しているＭＴＣデバイス１００は、（Ｂ）送信制御メッセージを受信した後、３Ｇアクセスから示された値（例えば、待機時間）に基づいて、送信メッセージのタイミングを遅らせることができる（例えば、図１９の（Ｄ）から（Ｅ））。なお、ここでは３Ｇアクセスから示された値（待機時間）に基づいて送信メッセージのタイミングを遅らせているが、例えばＭＴＣデバイスが値（待機時間）を計算してもよく、また、ＭＴＣサーバ１５０などの外部サーバに値（待機時間）を問い合わせてもよい。
“Ｔｉｍｅ ｔｏｌｅｒａｎｔ”の機能を保持していないＭＴＣデバイス１００やＵＥ１０５が（Ｂ）送信制御メッセージを受信した場合は、送信メッセージのタイミングを遅らせることができないため、（Ｃ）待機時間の間にメッセージ（例えば、ＰＤＮコネクション確立リクエストやアプリケーションデータ、Ｅｍｅｒｇｅｎｃｙ ｒｅｑｕｅｓｔや、Ｅｍｅｒｇｅｎｃｙ ｍｅｓｓａｇｅ）を送信する。“Ｔｉｍｅ ｔｏｌｅｒａｎｔ”を保持していないＭＴＣデバイス１００やＵＥ１０５が送信するメッセージは、（Ｃ）待機時間の後に再送信することができない（送信メッセージのタイミングを遅らせることができない）ため、優先度レベルが高いＭＴＣデバイス１００やＵＥ１０５から送信されるメッセージとして送信できるようにする。この優先度レベルが高いＭＴＣデバイス１００やＵＥ１０５から送信されるメッセージをネットワーク側が受け入れられるようにするために、送信メッセージのタイミングを遅らせることができる（優先度レベルが低い）ＭＴＣデバイス１００（“Ｔｉｍｅ ｔｏｌｅｒａｎｔ”の機能を保持するＭＴＣデバイス１００）によって確立されたＰＤＮコネクションを切断する（（Ｃ）待機時間の後にメッセージを送信させる）ことで、リソース（Ｃ−ｐｌａｎｅ、Ｕ−ｐｌａｎｅ共）を確保する。
“Ｔｉｍｅ ｔｏｌｅｒａｎｔ”の機能を保持していないＭＴＣデバイス１００とＵＥ１０５が（Ｂ）送信制御メッセージを受信した際、一定の期間（例えば、（Ｂ）送信制御メッセージに格納されている値（待機時間）ではなく、ＭＴＣデバイス１００やＵＥ１０５にあらかじめ組み込まれている待機時間（固定値））を待機することができる場合、“Ｔｉｍｅ ｔｏｌｅｒａｎｔ”の機能を保持しているＭＴＣデバイス１００は、“Ｔｉｍｅ ｔｏｌｅｒａｎｔ”の機能を保持していないＭＴＣデバイス１００より長い時間、メッセージの送信を遅らせることができるものとする。
以下、本発明の第８の実施の形態におけるシステム動作の一例について、図２０を用いて詳しく説明する。図２０は、本発明の第８の実施の形態におけるシステム動作の一例（既に確立済みであるＰＤＮコネクションをＵＥ１０５やＭＴＣデバイス１００、ネットワーク側のエンティティ（例えば、ｅＮＢ１１０やＭＭＥ１２０、ＳＧＷ１３０、ＰＧＷ１４０、ＭＴＣサーバ１５０）が保持する優先度レベル（例えば、ＵＥ１０５やＭＴＣデバイス１００に割り当てられる優先度レベルや、送信するデータの優先度レベルや、ＱＣＩやＡＲＰ）を用いて切断することで優先度レベルの高いリクエストやアプリケーションのためのリソース確保方法）を説明するためのシーケンスチャートである。なお、図２０には、図１に図示したシステム構成における処理シーケンスの一例を図示する。
ＭＴＣデバイスＡ１００ＡとＭＴＣデバイスＢ１００ＢとＭＴＣデバイスＣ１００Ｃは、既にＰＤＮコネクションを確立済みであり、データ転送を行っていることとする（図２０のステップＳ１００１Ａ、Ｓ１００１Ｂ、Ｓ１００１Ｃ：ＰＤＮコネクション確立済み）。続いて、ＭＴＣデバイスＤ１００Ｄがデータ転送をするためにＰＤＮコネクション確立リクエストをＭＭＥ１２０に送信する（図２０のステップＳ１００２：ＰＤＮコネクション確立リクエスト）。
ＰＤＮコネクション確立リクエストを受け、ネットワーク側のエンティティ（例えば、ｅＮＢ１１０やＭＭＥ１２０など）が、例えば処理能力の許容レベル（閾値）を上回ったかどうか確認することによって、混雑状態を検出する（リソースの確保が必要であることを検出する）（図２０のステップＳ１００３：混雑検出）。ここでは、ＭＴＣデバイスＤ１００Ｄから送信されたＰＤＮコネクション確立リクエストを受信することでネットワーク側のエンティティ（例えば、ｅＮＢ１１０やＭＭＥ１２０など）が混雑状態を検出しているが、データ転送をしているＭＴＣデバイス１００（本発明の第８の実施の形態では、ＭＴＣデバイスＡ〜Ｃ）によって送信されるデータサイズ（送信されているデータの総量）の増加などによって、ネットワーク側のエンティティが混雑状態を検出してもよい。
また、本実施の形態の説明を容易化するために、ＭＭＥ１２０が混雑状態を検出しているが、他のエンティティ（例えば、ｅＮＢ１１０やＳＧＷ１３０、ＰＧＷ１４０、ＭＴＣサーバ１５０）が混雑状態を検出してもよい。その場合、各エンティティがＭＴＣデバイスＤ１００Ｄに混雑状態が起こっていることを直接通知してもよいし、ＭＭＥ１２０やｅＮＢ１１０などに通知することで、間接的に通知してもよい（例えば、ＰＧＷ１４０が混雑状態を検出し次第、ＭＭＥ１２０に混雑状態を通知し、ＭＭＥ１２０はＭＴＣデバイスＤ１００ＤからＰＤＮコネクション確立リクエストが送信されてきた際に、混雑状態をＭＴＣデバイス１００に通知してもよい）。
混雑状態を検出したＭＭＥ１２０は、ＰＤＮコネクションを確立できないことを通知するためにＰＤＮコネクション確立リクエスト拒絶メッセージをＭＴＣデバイスＤ１００Ｄに送信する（図２０のステップＳ１００４：ＰＤＮコネクション確立リクエスト拒絶）。続いて、ｅＮＢ１１０は、対象となるＭＴＣデバイス１００（例えば、特定のＡＰＮに接続しているＭＴＣデバイス、特定のＭＴＣグループに属しているＭＴＣデバイス、特定のオペレータに属しているＭＴＣデバイス、特定のエリア（例えば、特定のｅＮＢ１１０やＭＭＥ１２０に接続しているＭＴＣデバイス）など）に送信制御メッセージをブロードキャストする（図２０のステップＳ１００５、Ｓ１００６：送信制御メッセージ）。対象となるＭＴＣデバイス１００の決定は、例えば、ステップＳ１００５のブロードキャストメッセージ指示でＭＭＥ１２０がｅＮＢ１１０に指示してもよい。このとき、ＭＭＥ１２０はｅＮＢ１１０やＳＧＷ１３０、ＰＧＷ１４０、ＭＴＣサーバ１５０に指示を問い合わせてもよい。
なお、ｅＮＢ１１０が対象となるＭＴＣデバイス１００にブロードキャスト送信する際、従来技術であるページングメッセージ（Ｐａｇｉｎｇ）やＭＢＭＳ（Ｍｕｌｔｉｍｅｄｉａ Ｂｒｏａｄｃａｓｔ Ａｎｄ Ｍｕｌｔｉｃａｓｔ Ｓｅｒｖｉｃｅ）を用いてよい。また、ここでは、本実施の形態の説明を容易化するために、ＭＭＥ１２０がｅＮＢ１１０にブロードキャストメッセージを指示し、ｅＮＢ１１０が対象デバイスにブロードキャストしているが、他のエンティティがブロードキャストメッセージを指示し、ブロードキャスト送信してもよい（例えば、ＰＧＷ１４０がｅＮＢ１１０にブロードキャストメッセージ指示し、ｅＮＢ１１０がブロードキャスト送信）。
また、ＭＭＥ１２０によるメッセージの送信処理（ステップＳ１００４とステップＳ１００５）の順序は、入れ替わってもよい。さらに、ステップＳ１００５において送信制御メッセージをブロードキャストすることで、ＭＴＣデバイスＤ１００ＤのＰＤＮコネクション確立リクエストの拒絶を通知することができるのであれば、ステップＳ１００４を省略してもよい。
送信制御メッセージを受信したＭＴＣデバイス１００は、“Ｔｉｍｅ ｔｏｌｅｒａｎｔ”の機能を保持しているか確認する。ＭＴＣデバイス１００が、“Ｔｉｍｅ ｔｏｌｅｒａｎｔ”の機能を保持している場合、ＰＤＮコネクション確立リクエストを送信するタイミングを送信制御メッセージに格納されている待機時間に基づいて遅らせる。“Ｔｉｍｅ ｔｏｌｅｒａｎｔ”の機能を保持していないＭＴＣデバイス１００は、送信メッセージのタイミングを遅らせることができないので、ネットワーク側で混雑状態が起こっている場合でもＰＤＮコネクション確立リクエストを送信する。
このように、ＭＴＣデバイス１００からのＰＤＮコネクション確立リクエストの送信を回避することで、通信システムの処理負荷が軽減され、Ｃ−ｐｌａｎｅのリソースは確保できる。しかしながら、既にＰＤＮコネクションを確立しているＭＴＣデバイス（ＭＴＣデバイスＡ１００Ａ〜ＭＴＣデバイスＣ１００Ｃ）のデータ転送が完了するまで、Ｕ−ｐｌａｎｅのリソースに空きは生じない。さらに、上記したようにＵＥ１０５などから優先度の高い緊急メッセージ（Ｅｍｅｒｇｅｎｃｙ ｒｅｑｕｅｓｔや、Ｅｍｅｒｇｅｎｃｙ ｍｅｓｓａｇｅとも呼ばれる）やアプリケーションメッセージが送られてくることで、優先度レベルの高いＵＥ１０５やＭＴＣデバイス１００用の更なるリソース（Ｕ−ｐｌａｎｅ、Ｃ−ｐｌａｎｅ共）が必要となることがある。
そこで、ＭＴＣデバイス１００の優先度レベルを用いて、既に確立済みであるＰＤＮコネクションを選択的に切断することで優先度レベルの高いＰＤＮコネクション確立リクエストやアプリケーションデータの転送のためのＵ−ｐｌａｎｅのリソースを確保する。この優先度レベルを判別するためにも、例えば、“Ｔｉｍｅ ｔｏｌｅｒａｎｔ”の機能を保持しているＭＴＣデバイス１００であるかどうかをＭＴＣデバイス１００に確認させる。
そこで、ｅＮＢ１１０がブロードキャスト送信する送信制御メッセージに「“Ｔｉｍｅ ｔｏｌｅｒａｎｔ”の機能を保持するＭＴＣデバイス１００は確立済みＰＤＮコネクションを切断する」よう指示するパラメータを格納する。“Ｔｉｍｅ ｔｏｌｅｒａｎｔ”の機能を保持するＭＴＣデバイス１００は、例えば、ｅＮＢ１１０からブロードキャスト送信される送信制御メッセージの受信後、確立済みのＰＤＮコネクションを切断する。また、ＭＴＣデバイス１００は、送信制御メッセージから一定時間（例えば、３Ｇアクセスから示された値（例えば、待機時間））経過後、再度ＰＤＮコネクションを確立し、データ転送を行ってもよい。
図２１は、図２０のステップＳ１００６において、ｅＮＢ１１０が対象となるＭＴＣデバイス１００にブロードキャスト送信する送信制御メッセージであり、「“Ｔｉｍｅ ｔｏｌｅｒａｎｔ”の機能を保持するＭＴＣデバイス１００は確立済みＰＤＮコネクションを切断する」よう指示するパラメータと、「更に付加される詳細な条件」を示したパラメータが格納されるメッセージ構成の一例として、送信制御メッセージのフォーマット例を示す図である。
図２１は、ブロードキャスト送信するために必要となるヘッダフィールドと「“Ｔｉｍｅ ｔｏｌｅｒａｎｔ”の機能を保持するＭＴＣデバイス１００は確立済みＰＤＮコネクションを切断する」ことを示したＴｉｍｅ ｔｏｌｅｒａｎｔフィールドとさらに詳細な情報を用いてＰＤＮコネクションの維持／切断を判断する際に用いる詳細な条件（詳細データ）が格納される詳細データフィールドで構成される。詳細データフィールドには、従来技術のＡＰＮや位置情報（例えば、ｅＮＢ ＩＤやｅＮＢアドレス）、ＭＴＣグループを識別するグループＩＤ、接続しているネットワークオペレータを識別するＰＬＭＮ ＩＤに加えて、確立済みのＰＤＮコネクションを用いて転送するデータのデータ残量（データ残量値）や予想完了時間（予想完了時刻）、残時間、ＰＤＮコネクション（ＥＰＳベアラ）のＱＣＩ（QoS Class Indicator）やＡＲＰ（Allocation and Retention Priority）、データ転送を開始した時刻（以降、“Ｂｅｆｏｒｅ ｔｉｍｅ”とも呼ぶ）、ＭＴＣ ｆｅａｔｕｒｅ（例えば、非特許文献１で定義されている着信しかできない“Ｍｏｂｉｌｅ ｏｒｉｇｉｎａｔｅｄ ｏｎｌｙ”の機能を保持しているＭＴＣデバイス１００）などを格納することができる。ＭＴＣデバイス１００は、確立済みのＰＤＮコネクションを維持／切断する判断条件として、ＭＴＣデバイス１００が“Ｔｉｍｅ ｔｏｌｅｒａｎｔ”の機能を保持しているかに加えて、詳細データフィールドに格納されている詳細な判断条件を用いることができる。つまり、この詳細データフィールドを用いることで、論理演算を用いて説明すると「“Ｔｉｍｅ ｔｏｌｅｒａｎｔ”の機能を保持しているＭＴＣデバイス１００」ＡＮＤ「詳細データ」や、「“Ｔｉｍｅ ｔｏｌｅｒａｎｔ”の機能を保持しているＭＴＣデバイス１００」ＯＲ「詳細データ」や、「“Ｔｉｍｅ ｔｏｌｅｒａｎｔ”の機能を保持しているＭＴＣデバイス１００」ＥＸＯＲ「詳細データ」の結果で、確立済みのＰＤＮコネクションの維持／切断を決定することができる。なお、ＭＴＣデバイス１００やＵＥ１０５、通信システムのエンティティが、優先度レベルの低いＭＴＣデバイス１００、又は、アプリケーションであることを示すパラメータ（例えば、“Ｌｏｗ ｐｒｉｏｒｉｔｙ ｉｎｄｉｃａｔｏｒ”）を認識できる場合は、「“Low priority”の機能を保持するＭＴＣデバイス１００は確立済みＰＤＮコネクションを切断する」ことを示したパラメータと置き換えてもよい（代わりに使用してもよい）。
例えば、「“Ｔｉｍｅ ｔｏｌｅｒａｎｔ”の機能を保持しているＭＴＣデバイス１００」であり、「“Ｍｏｂｉｌｅ ｏｒｉｇｉｎａｔｅｄ ｏｎｌｙ”の機能を保持しているＭＴＣデバイス１００」によって確立されたＰＤＮコネクションのみ切断する。または、「“Ｔｉｍｅ ｔｏｌｅｒａｎｔ”の機能を保持しているＭＴＣデバイス１００」、もしくは、「“Ｍｏｂｉｌｅ ｏｒｉｇｉｎａｔｅｄ ｏｎｌｙ”の機能を保持しているＭＴＣデバイス１００」によって確立されたＰＤＮコネクションは切断する。または、「“Ｔｉｍｅ ｔｏｌｅｒａｎｔ”の機能を保持しているＭＴＣデバイス１００」であり、「“Ｍｏｂｉｌｅ ｏｒｉｇｉｎａｔｅｄ ｏｎｌｙ”の機能を保持しているＭＴＣデバイス１００」によって確立されたＰＤＮコネクションと、「“Ｔｉｍｅ ｔｏｌｅｒａｎｔ”の機能を保持しているＭＴＣデバイス１００」と「“Ｍｏｂｉｌｅ ｏｒｉｇｉｎａｔｅｄ ｏｎｌｙ”の機能を保持しているＭＴＣデバイス１００」でもないＭＴＣデバイス１００によって確立されたＰＤＮコネクションは切断するというように定義してもよい。
また、例えば詳細データフィールドにＢｅｆｏｒｅ ｔｉｍｅを格納することで、“Ｔｉｍｅ ｔｏｌｅｒａｎｔ”の機能を保持しているＭＴＣデバイス１００であり、Ｂｅｆｏｒｅ ｔｉｍｅで示された値（時刻）以降にＰＤＮコネクションを確立、若しくは、データ送信を開始したＭＴＣデバイス１００である場合、確立済みのＰＤＮコネクションを切断すると定義してもよい。このとき、Ｂｅｆｏｒｅ ｔｉｍｅは、例えば「ＡＭ１１：００」のように値（時刻）を示してもよい。また、Ｂｅｆｏｒｅ ｔｉｍｅは、「Ｂｅｆｏｒｅ ｔｉｍｅで示された値（時刻）以内にＰＤＮコネクションを確立したＭＴＣデバイス、若しくは、データ転送を開始してから経過した時間」のように指示することもでき、その場合は、例えば「１分」のように値（時刻）を示してもよい。
また、例えば詳細データフィールドに転送するデータのデータ残量（データ残量値）を格納することで、“Ｔｉｍｅ ｔｏｌｅｒａｎｔ”の機能を保持しているＭＴＣデバイス１００であり、ＭＴＣデバイス１００によって送信されるデータの残量がネットワーク側から指示されたデータ残量値を超えてしまっている場合は、確立済みのＰＤＮコネクションを切断すると定義してもよい。このとき、データ残量値は、例えば「１Ｍ Ｂｙｔｅｓ」のように値を示してもよい。
また、例えば詳細データフィールドに予想完了時間（残時間）を格納することで、“Ｔｉｍｅ ｔｏｌｅｒａｎｔ”の機能を保持しているＭＴＣデバイス１００であり、ＭＴＣデバイス１００が予想するデータ送信の予想完了時間（残時間）がｅＮＢ１１０からブロードキャスト送信された送信制御メッセージに格納されている予想完了時間（残時間）を超えてしまっている場合は、確立済みのＰＤＮコネクションを切断すると定義してもよい。このとき、予想完了時間は、例えば「ＡＭ１１：１５」、残時間は「１分」のように値を示してもよい。また、この予想完了時間や残時間は、例えば、データダウンロード完了までの時間を表わすアプリケーションなどから取得できる情報を利用してもよい。
また、例えば詳細データフィールドにＱＣＩやＡＲＰを格納することで、“Ｔｉｍｅ ｔｏｌｅｒａｎｔ”の機能を保持しているＭＴＣデバイス１００であり、現在送信しているデータで用いているＰＤＮコネクションやＥＰＳベアラのＱＣＩやＡＲＰが、詳細データフィールドで示された値以下である場合、該当するＰＤＮコネクションを切断するというように定義してもよい。通信システムのエンティティ（例えば、ｅＮＢ１１０やＭＭＥ１２０、ＳＧＷ１３０、ＰＧＷ１４０）やＭＴＣサーバ１５０が詳細データフィールドに格納するＱＣＩやＡＲＰは、例えばＳｕｂｓｃｒｉｐｔｉｏｎ ｄａｔａやＭＴＣデバイス１００の情報が登録されているコンテキスト、課金ルールなどを管理しているＰＣＲＦ（Policy and Charging Rules Function、図１には不図示）から取得したデータなどを用いて決定してもよい。例えば、ＭＭＥ１２０がＨＳＳ１２５から送信制御メッセージの送信対象先であるＭＴＣデバイス１００のＳｕｂｓｃｒｉｐｔｉｏｎ ｄａｔａを取得し、確立されているＰＤＮコネクションの平均ＱＣＩやＡＲＰを導き出し、現在の混雑状態と照らし合わせて、詳細データフィールドに格納するＱＣＩやＡＲＰを決定してもよい。
ＭＴＣデバイス１００は、上記したような詳細データフィールドに格納されているＰＤＮコネクションを切断するための詳細な判断条件を用いるために、例えば、Ｂｅｆｏｒｅ ｔｉｍｅが格納される場合は、Ｂｅｆｏｒｅ ｔｉｍｅを用いるためにＭＴＣデバイス１００はデータ転送を開始した時刻や、ＰＤＮコネクションを確立した時刻を記憶、若しくは、その時点からタイマーを起動し、ｅＮＢ１１０からブロードキャスト送信された送信制御メッセージを受信するまでの時間を計測してもよい。
また、詳細データフィールドにデータ残量（データ残量値）が格納される場合は、ＭＴＣデバイス１００は、現在送信しているデータの残りを把握しておく必要がある。例えば、ＭＴＣデバイス１００は送信予定のデータ総量（例えば、５０Ｍ Ｂｙｔｅｓ）と送信済みデータ量を記憶しておくことで、データ残量を計算してもよい。
また、詳細データフィールドに予想完了時間（あるいは、予想完了時刻）や残時間が格納される場合は、ＭＴＣデバイス１００は、現在送信しているデータの予想完了時間や、送信完了するまでに要する時間を把握しておく必要がある。例えば、ＭＴＣデバイス１００は送信予定のデータ量（例えば、５０Ｍ Ｂｙｔｅｓ）と送信レート（例えば、１Ｍｂｐｓ）と送信済みデータ量（例えば、４０Ｍ Ｂｙｔｅｓ）を把握しておき、データ転送の予想完了時間（現時刻がＡＭ１１：００とすると、データ転送の予想完了時刻（５０Ｍ Ｂｙｔｅｓ―４０Ｍ Ｂｙｔｅｓ）×８ｂｉｔｓ÷１Ｍｂｐs＝８０秒なので、ＡＭ１１：０１ ２０秒）や残時間（８０秒）を見積もってもよい。上記式は、単純に計算した式の例であり、実環境におけるパケットロス率などを考慮した式を用いてもよい。また、このような予想完了時間や残時間は、起動しているアプリケーションから取得してもよい。
また、詳細データフィールドにＱＣＩやＡＲＰが格納される場合は、ＭＴＣデバイス１００は、現在使用しているＰＤＮコネクションのＱＣＩやＡＲＰを把握しておく必要がある。例えば、ＭＴＣデバイス１００は、ＰＤＮコネクション（ＥＰＳベアラ）を確立した際（例えば、Ａｔｔａｃｈ ｐｒｏｃｅｄｕｒｅ中や、Ｂｅａｒｅｒ ｍｏｄｉｆｉｃａｔｉｏｎ ｐｒｏｃｅｄｕｒｅ中）にネットワーク側のエンティティ（例えば、ｅＮＢ１１０、ＭＭＥ１２０、ＳＧＷ１３０、ＰＧＷ１４０、ＨＳＳ１２５）からＱＣＩやＡＲＰを取得し、ネットワーク側からブロードキャスト送信される送信制御メッセージに格納されるＱＣＩやＡＲＰと比較してもよい。
また、詳細データフィールドにＭＴＣ ｆｅａｔｕｒｅが格納される場合は、ＭＴＣデバイス１００は、搭載しているＭＴＣ ｆｅａｔｕｒｅを把握しておく必要がある。例えば、ＭＴＣデバイス１００は、ＭＴＣデバイス１００コンテキストを持ち、そのコンテキストの中に各ＭＴＣデバイス１００が搭載する全てのＭＴＣ ｆｅａｔｕｒｅを登録してもよい。または、ＭＴＣデバイス１００が３ＧアクセスとＰＤＮコネクションを確立する際（例えば、Ａｔｔａｃｈ ｐｒｏｃｅｄｕｒｅ中）、ネットワーク側からＭＴＣデバイス１００が保持できるＭＴＣ ｆｅａｔｕｒｅ、もしくは、ＭＴＣサーバ／ユーザから指示されているＭＴＣ ｆｅａｔｕｒｅをＭＴＣデバイス１００に通知することで、ＭＴＣデバイス１００が搭載しているＭＴＣ ｆｅａｔｕｒｅを把握してもよい。
なお、詳細データフィールドを用いずに、Ｔｉｍｅ ｔｏｌｅｒａｎｔフィールドのみでＰＤＮコネクションの維持／切断を判断する場合は、例えば図２１に図示されているフォーマットから詳細データフィールドを省略してもよい。
また、「“Ｔｉｍｅ ｔｏｌｅｒａｎｔ”の機能を保持するＭＴＣデバイス１００は確立済みＰＤＮコネクションを切断する」ことを通知するために、従来技術のページングとＳＩＢ（Ｓｙｓｔｅｍ Ｉｎｆｏｒｍａｔｉｏｎ Ｂｌｏｃｋ）を用いてもよい。例えば、ＭＴＣ用のＳＩＢを新たに設ける、若しくは、既存のＳＩＢを改良して、ＭＴＣデバイス１００にそのＳＩＢを読み出すように指示することで、「“Ｔｉｍｅ ｔｏｌｅｒａｎｔ”の機能を保持するＭＴＣデバイス１００は確立済みＰＤＮコネクションを切断する」ことを通知してもよい。また、従来技術のＭＢＭＳ（Ｍｕｌｔｉｍｅｄｉａ Ｂｒｏａｄｃａｓｔ Ａｎｄ Ｍｕｌｔｉｃａｓｔ Ｓｅｒｖｉｃｅ）を用いて、各ＭＴＣデバイス１００に通知してもよい。
「“Ｔｉｍｅ ｔｏｌｅｒａｎｔ”の機能を保持するＭＴＣデバイス１００は確立済みＰＤＮコネクションを切断する」ことを通知されたＭＴＣデバイス１００は、自分自身が“Ｔｉｍｅ ｔｏｌｅｒａｎｔ”の機能を保持しているかどうかを確認する。
ＭＴＣデバイス１００が、“Ｔｉｍｅ ｔｏｌｅｒａｎｔ”の機能を保持しており、かつ、既にＰＤＮコネクションを確立済みである場合には、ＰＤＮコネクションを切断する（図２０のステップＳ１００７：ＰＤＮコネクションリリース）。なお、ここではＭＴＣデバイス１００が、“Ｔｉｍｅ ｔｏｌｅｒａｎｔ”の機能を保持していて、既にＰＤＮコネクションを確立済みである場合、即座にＰＤＮコネクションを切断しているが、例えばＭＴＣデバイスと通信システムのポリシや、アプリケーションの仕様などに基づいて、切断のタイミングを見計らってもよい。また、ＭＴＣデバイス１００と通信システムのエンティティ（例えば、ｅＮＢ１１０やＭＭＥ１２０、ＳＧＷ１３０、ＰＧＷ１４０）は、ＰＤＮコネクションを切断する際、完全に切断するのではなく、再度ＰＤＮコネクションを確立する際の時間短縮や処理負荷軽減のために以前の状態（例えば、ＭＴＣデバイス１００のＩＰアドレス、ＩＭＳI、ＩＭＥＩ、鍵情報）を一定期間、各装置で保持して再利用してもよい。
また、図２０の例では、ＭＴＣデバイスＢ１００Ｂが、“Ｔｉｍｅ ｔｏｌｅｒａｎｔ”の機能を保持しており、かつ、既にＰＤＮコネクションを確立済みのＭＴＣデバイス１００に該当する。すなわち、ＭＴＣデバイスＢ１００Ｂは、ステップＳ１００６の送信制御メッセージを受信すると、確立済みのＰＤＮコネクションを切断する。なお、このとき、ＭＴＣデバイスＢ１００Ｂは、確立したＰＤＮコネクションを切断するために、非特許文献３で定義されているＵＥ−ｉｎｉｔｉａｔｅｄ Ｄｅｔａｃｈ ＰｒｏｃｅｄｕｒｅやＵＥ ｒｅｑｕｅｓｔｅｄ ｂｅａｒｅｒ ｒｅｓｏｕｒｃｅ ｍｏｄｉｆｉｃａｔｉｏｎ ｐｒｏｃｅｄｕｒｅなどの従来技術に係る処理を用いてもよい。
また、“Ｔｉｍｅ ｔｏｌｅｒａｎｔ”を保持しておらず、ＰＤＮコネクションが確立済みのＭＴＣデバイス１００（図２０の例では、ＭＴＣデバイスＡ１００ＡとＭＴＣデバイスＣ１００Ｃに相当）は、ＰＤＮコネクションをそのまま維持する。また、“Ｔｉｍｅ ｔｏｌｅｒａｎｔ”を保持していて、ＰＤＮコネクションを保持しておらず、これからメッセージ（例えば、ＰＤＮコネクション確立リクエスト）を送信しようとしていたＭＴＣデバイス１００（ＭＴＣデバイスＥ１００ＥやＭＴＣデバイスＦ１００Ｆに相当）は、上記で説明したように（例えば、図１９の（Ｄ）から（Ｅ））、メッセージの送信タイミングを遅らせる。
また、その後、ＵＥ１０５などから優先度の高い緊急メッセージ（Ｅｍｅｒｇｅｎｃｙ ｒｅｑｕｅｓｔや、Ｅｍｅｒｇｅｎｃｙ ｍｅｓｓａｇｅとも呼ばれる）やアプリケーションメッセージが送られてくる場合、若しくは、メッセージを送るためのＰＤＮコネクション確立リクエストが送られてくる場合（図２０のステップＳ１００８：データ送信／ＰＤＮコネクション確立リクエスト）がある。この場合、ＵＥ１０５は、メッセージを送信することが可能である。ステップＳ１００７で、ＭＴＣデバイスＢが確立済みのＰＤＮコネクションを切断したことによってリソース（Ｃ−ｐｌａｎｅ、Ｕ−ｐｌａｎｅ共）が確保されたため、ネットワーク側はステップＳ１００８のＵＥによるデータ送信、若しくは、ＰＤＮコネクション確立リクエストを受け入れることができる。
なお、本発明の第８の実施の形態では、“Ｔｉｍｅ ｔｏｌｅｒａｎｔ”の機能を保持するＭＴＣデバイス１００のみを対象とするのではなく、ＡＰＮやＭＴＣグループのグループＩＤ、ネットワークオペレータを識別するＰＬＭＮ ＩＤ（Public Land Mobile Network ID）、デバイス種ＩＤ、デバイスＩＤなどと組み合わせて使用してもよい。
また、本発明の第８の実施の形態は、ＭＴＣデバイス１００が送信制御メッセージ受信後に確立したＰＤＮコネクションを切断しているが、通信システムのエンティティ（例えば、ｅＮＢ１１０やＭＭＥ１２０、ＳＧＷ１３０、ＰＧＷ１４０）やＭＴＣサーバ１５０が、Ｓｕｂｓｃｒｉｐｔｉｏｎ ｄａｔａやＭＴＣデバイス１００特有のコンテキスト、メッセージ交換（例えば、Ａｔｔａｃｈ ｐｒｏｃｅｄｕｒｅ）時などの情報から、切断すべきＰＤＮコネクション（“特定のＰＤＮコネクション”）を確認することができるのであれば、通信システムのエンティティ（例えば、ｅＮＢ１１０やＭＭＥ１２０、ＳＧＷ１３０、ＰＧＷ１４０）やＭＴＣサーバ１５０主導でＰＤＮコネクションを切断してもよい。このとき、非特許文献３で定義されているＰＤＮ ＧＷ ｉｎｉｔｉａｔｅｄ ｂｅａｒｅｒ ｄｅａｃｔｉｖａｔｉｏｎやＭＭＥ−ｉｎｉｔｉａｔｅｄ Ｄｅｔａｃｈ ｐｒｏｃｅｄｕｒｅなどの従来技術に係る処理を用いてもよい。例えば、通信システムのエンティティ（例えば、ｅＮＢ１１０やＭＭＥ１２０、ＳＧＷ１３０、ＰＧＷ１４０）やＭＴＣサーバ１５０が、優先度の高いＵＥ１０５やＭＴＣデバイス１００のためのリソースを確保するために算出、若しくは、取得したＰＤＮコネクションを切断するための条件（例えば、“Ｔｉｍｅ ｔｏｌｅｒａｎｔ”の機能を保持するＭＴＣデバイス１００で、Ｂｅｆｏｒｅ ｔｉｍｅで示される値に該当するＭＴＣデバイス１００）と、記憶していたＭＴＣデバイス１００によってＰＤＮコネクションが確立された時刻を比較し、切断すべきＰＤＮコネクションを確認することができる場合がある。
次に、図２２を参照しながら、本発明の第８の実施の形態におけるＭＴＣデバイス１００の構成について説明する。図２２は、本発明の第８の実施の形態におけるＭＴＣデバイス１００の構成の一例を示す図である。
図２２において、ＭＴＣデバイス１００は、通信システム（例えば、Ｅ−ＵＴＲＡＮやＵＴＲＡＮ）と接続して下位レイヤにおける通信処理と上位レイヤでＩＰなどのパケット通信処理を実施する通信処理部１１１０、ネットワーク側からブロードキャスト送信された送信制御メッセージのＴｉｍｅ ｔｏｌｅｒａｎｔフィールドと詳細データフィールドを処理するブロードキャストメッセージ処理部１１２０、ブロードキャストメッセージ処理部１１２０の結果に基づいて、既に確立済みのＰＤＮコネクションを維持／切断するＰＤＮコネクション処理部１１３０を少なくとも有する。
また、送信制御メッセージの詳細データフィールドに情報が格納される場合は、詳細データ処理部１１４０を設けてもよい。詳細データ処理部１１４０は、例えば、Ｂｅｆｏｒｅ ｔｉｍｅを用いてデータ送信開始時間でＰＤＮコネクションの切断をする場合、ＭＴＣデバイス１００内でデータ送信を開始した時間を記憶する機能やタイマー機能を有する。詳細データ処理部１１４０は、既存の処理部（例えば、ブロードキャストメッセージ処理部１１２０）に組み込んでもよい。
次に、図２２に図示されている構成を有するＭＴＣデバイス１００について、本発明における特徴的な処理を中心に、図２３を用いて詳しく説明する。
図２３において、ＭＴＣデバイス１００は、ｅＮＢ１１０からブロードキャスト送信されたメッセージ（送信制御メッセージ）を受信する（図２３のステップＳ１２１０）。ＭＴＣデバイス１００は、ＭＴＣデバイス１００自身がＰＤＮコネクションを切断するＭＴＣデバイス１００であるかを確認するために、ブロードキャストメッセージ（送信制御メッセージ）のＴｉｍｅ ｔｏｌｅｒａｎｔフィールドと詳細データフィールドに格納されている情報をブロードキャストメッセージ処理部１１２０で取得する（図２３のステップＳ１２２０）。
ＭＴＣデバイス１００は、受信したブロードキャストメッセージの送信対象に自分が含まれていないと判断した場合には、特別な処理は行わずに終了する。
一方、ＭＴＣデバイス１００が、受信したブロードキャストメッセージの送信対象に自分が含まれていると判断した場合には、ＭＴＣデバイス１００と通信システムの間にＰＤＮコネクションを確立済みであるかどうかを更に確認する（図２３のステップＳ１２３０）。なお、ＭＴＣデバイス１００が、ブロードキャストメッセージの送信対象に自分が含まれているかどうかを判断する処理フロー（図２３のステップＳ１２２０の処理）の詳細については後述する（図２４を参照）。
ＭＴＣデバイス１００と通信システム間にＰＤＮコネクションが確立されていない場合、ＭＴＣデバイス１００はＰＤＮコネクション未確立時の動作（例えば、“Ｔｉｍｅ ｔｏｌｅｒａｎｔ”の機能を保持しているＭＴＣデバイス１００は、ＰＤＮコネクション確立リクエストの送信タイミングを遅らせる）を実施して（図２３のステップＳ１２４０）、終了する。
一方、ＭＴＣデバイス１００と通信システム間に、既にＰＤＮコネクションを確立されている場合、ＭＴＣデバイス１００は、ＰＤＮコネクション処理部１１３０で、例えば非特許文献３で定義されているＵＥ−ｉｎｉｔｉａｔｅｄ Ｄｅｔａｃｈ ＰｒｏｃｅｄｕｒｅやＵＥ ｒｅｑｕｅｓｔｅｄ ｂｅａｒｅｒ ｒｅｓｏｕｒｃｅ ｍｏｄｉｆｉｃａｔｉｏｎ ｐｒｏｃｅｄｕｒｅなどを用いて、確立済みのＰＤＮコネクションを切断する（図２３のステップＳ１２５０）。
次に、詳細データフィールドに格納された値を用いてＰＤＮコネクションを維持／切断する際の詳細な流れについて説明する。例えば、詳細データフィールドにデータ転送を開始してから経過した時間を示す“Ｂｅｆｏｒｅ ｔｉｍｅ”が格納されている場合について、図２４を用いて詳しく説明する。なお、図２４は、図２３のステップＳ１２２０の処理の詳細について説明するためのものである。
図２４において、ＭＴＣデバイス１００は、ｅＮＢ１１０からブロードキャスト送信されたメッセージ（送信制御メッセージ）を受信する（図２４のステップＳ１２１０）。続いて、ＭＴＣデバイス１００は、ＭＴＣデバイス１００自身がＰＤＮコネクションを切断するＭＴＣデバイス１００であるかを確認するために、ブロードキャストメッセージ（送信制御メッセージ）のＴｉｍｅ ｔｏｌｅｒａｎｔフィールドを確認する（図２４のステップＳ１２２１）。このとき、ＭＴＣデバイス１００は、例えば、製造時に設定された情報（例えば、ＭＴＣ ｆｅａｔｕｒｅの一覧が登録されているＭＴＣデバイス１００コンテキスト）やＡｔｔａｃｈ ｐｒｏｃｅｄｕｒｅ中にネットワーク側から通知される情報（例えば、通信システムのオペレータから設定されるＭＴＣ ｆｅａｔｕｒｅや、ＭＴＣ Ｕｓｅｒから設定されるＭＴＣ ｆｅａｔｕｒｅ）などから、自分自身が“Ｔｉｍｅ ｔｏｌｅｒａｎｔ”の機能を保持しているか確認してもよい。
ＭＴＣデバイス１００は、自分自身が“Ｔｉｍｅ ｔｏｌｅｒａｎｔ”の機能を保持していないと判断した場合には、特別な処理は行わずに終了する。
一方、ＭＴＣデバイス１００が、自分自身が“Ｔｉｍｅ ｔｏｌｅｒａｎｔ”の機能を保持していると判断した場合には、続いて、送信制御メッセージの詳細データフィールドで示されたＢｅｆｏｒｅ ｔｉｍｅの値（時刻）を取得する。ここでは、ＭＴＣデバイス１００が既にＰＤＮコネクションを確立済みであると仮定し、ＭＴＣデバイス１００はＰＤＮコネクションを確立した時刻や、確立したＰＤＮコネクションで行うデータ転送の開始時刻を記憶、若しくは、タイマーを起動し、送信制御メッセージを受信するまでの時間を計測しているとする。
ＭＴＣデバイス１００は、送信制御メッセージの詳細データフィールドで示されたＢｅｆｏｒｅ ｔｉｍｅの値（時刻）と記憶（若しくは、計測）した値（時刻）の比較を行い、ＰＤＮコネクションの切断を判断する（図２４のステップＳ１２２２）。例えば、送信制御メッセージの詳細データフィールドで示されたＢｅｆｏｒｅ ｔｉｍｅの値（時刻）が「ＡＭ１１：００」であり、ＭＴＣデバイス１００が記憶（若しくは、計測）した値（時刻）が「ＡＭ１０：５５」であった場合（送信制御メッセージで示された時刻＞ＭＴＣデバイス１００内で記憶（計測）した時刻という条件に当てはまらない場合）、ネットワーク側が判断した値（時刻）より前から通信を開始し始めていたということで、送信制御メッセージの送信対象に自分が含まれていないと判断し、その結果、特別な処理は行わずにＰＤＮコネクションを維持する。なお、この「ＡＭ１１：００」のような形式ではなく、「１分前」のような形式でもよい。
一方、送信制御メッセージで示された時刻＞ＭＴＣデバイス１００内で記憶した時刻の条件に当てはまる場合には、ネットワーク側が判断した値（時刻）より後に通信を開始し始めたということで、送信制御メッセージの送信対象に自分が含まれていると判断し、その結果、確立済みのＰＤＮコネクションを切断する（図２４のステップＳ１２３０、ステップＳ１２４０）。
また、この詳細データフィールドを用いたＰＤＮコネクションの切断について、Ｂｅｆｏｒｅ ｔｉｍｅを例に挙げて説明したが、他のデータ残量や残時間などについても同様な処理（例えば、図２４のステップＳ１２２２はＢｅｆｏｒｅ ｔｉｍｅを用いて説明しているが、送信制御メッセージで示されたデータ残量値＞ＭＴＣデバイス内で計算したデータ残量値など）が行われる。また、Ｂｅｆｏｒｅ ｔｉｍｅとデータ残量を組み合わせることによって、さらにＰＤＮコネクションの維持／切断に用いる詳細な判断条件にできる。例えば、Ｂｅｆｏｒｅ ｔｉｍｅを用いて、ＰＤＮコネクションを切断するか絞り込みをした後に、その中でデータ残量がどれくらいかによってＰＤＮコネクションを切断するかを判断してもよい。
また、本発明の第８の実施の形態を非特許文献６で定義されているＬｏｗ ｐｒｉｏｒｉｔｙ ｉｎｄｉｃａｔｏｒと組み合わせることで、ネットワーク側で混雑状態が起こっている際、最初にＬｏｗ ｐｉｒｏｒｉｔｙ ｉｎｄｉｃａｔｏｒを持つＭＴＣデバイス１００によって確立されたＰＤＮコネクションを切断し、続いて“Ｔｉｍｅ ｔｏｌｅｒａｎｔ”の機能を持つＭＴＣデバイス１００によって確立されたＰＤＮコネクションを切断するというように、段階的にＰＤＮコネクションを切断することができる。これにより、リソースを段階的に確保することができ、過剰なＰＤＮコネクションの切断を回避することができる。例えば、通信システムのエンティティ（例えば、ｅＮＢ１１０やＭＭＥ１２０、ＳＧＷ１３０、ＰＧＷ１４０、ＨＳＳ）が、Ｌｏｗ ｐｒｉｏｒｉｔｙ ｉｎｄｉｃａｔｏｒが格納されたＰＤＮコネクション確立リクエストを送信してきたＭＴＣデバイス１００を、例えば、ＭＴＣデバイスコンテキストに登録、または、Ｓｕｂｓｃｒｉｐｔｉｏｎ ｄａｔａに登録するなどによって把握しておき、上記処理を実現させてもよい。また、通信システムのエンティティが、Ｌｏｗ ｐｒｉｏｒｉｔｙ ｉｎｄｉｃａｔｏｒを持つＭＴＣデバイス１００を把握することによって、ブロードキャスト送信する送信制御メッセージの送信先をＬｏｗ ｐｒｉｏｒｉｔｙ ｉｎｄｉｃａｔｏｒを持つＭＴＣデバイス１００のみと指定してもよい。
また、Ｌｏｗ ｐｒｉｏｒｉｔｙ ｉｎｄｉｃａｔｏｒとの組み合わせではなく、Ｔｉｍｅ ｔｏｌｅｒａｎｔフィールドの代わりにＬｏｗ ｐｒｉｏｒｉｔｙ ｉｎｄｉｃａｔｏｒフィールドを用いて、切断すべきＰＤＮコネクションを決定してもよい。このとき、Ｌｏｗ ｐｒｉｏｒｉｔｙ ｉｎｄｉｃａｔｏｒフィールドは、詳細データフィールドと組み合わせて使用してもよい。
例えば、ＭＭＥ１２０が混雑状態を検知した場合、最初にＬｏｗ ｐｒｉｏｒｉｔｙ ｉｎｄｉｃａｔｏｒを持つＭＴＣデバイス１００によって確立されたＰＤＮコネクションを切断する指示をｅＮＢ１１０に送信し、ｅＮＢ１１０が対象となるＭＴＣデバイス１００に送信制御メッセージをブロードキャストする。送信制御メッセージを受信し、かつ、Ｌｏｗ ｐｒｉｏｒｉｔｙ ｉｎｄｉｃａｔｏｒを持つＭＴＣデバイス１００は、確立済みのＰＤＮコネクションを切断する。
ここで、リソースの確保が十分でないと判断された場合（例えば、混雑状態を示す閾値を超えている場合など）、ＭＭＥ１２０がＴｉｍｅ ｔｏｌｅｒａｎｔフィールド（例えば、「“Ｔｉｍｅ ｔｏｌｅｒａｎｔ”の機能を保持している」）と詳細データフィールド（例えば、「“Ｍｏｂｉｌｅ Ｏｒｉｇｉｎａｔｅｄ ｏｎｌｙ”」）を用いて、確立済みのＰＤＮコネクションを切断するとｅＮＢ１１０に通知し、ｅＮＢ１１０が対象となるＭＴＣデバイス１００にブロードキャスト送信する。送信制御メッセージを受信し、かつ、“Ｔｉｍｅ ｔｏｌｅｒａｎｔ”と“Ｍｏｂｉｌｅ Ｏｒｉｇｉｎａｔｅｄ ｏｎｌｙ”の機能を持つＭＴＣデバイス１００は、確立済みのＰＤＮコネクションを切断する。これにより、リソースを段階的に確保することができ、過剰なＰＤＮコネクションの切断を回避することができる。
本発明の第８の実施の形態では、一部のＭＴＣデバイス１００（ＭＴＣデバイスＢ１００Ｂ、ＭＴＣデバイスＤ１００Ｄ、ＭＴＣデバイスＥ１００Ｅ、ＭＴＣデバイスＦ１００Ｆ）が“Ｔｉｍｅ ｔｏｌｅｒａｎｔ”の機能を保持していることを前提としているが、全てのＭＴＣデバイス１００が“Ｔｉｍｅ ｔｏｌｅｒａｎｔ”の機能を保持している場合にも適用できる。
全てのＭＴＣデバイス１００が、“Ｔｉｍｅ ｔｏｌｅｒａｎｔ”の機能を保持している場合、“Ｔｉｍｅ ｔｏｌｅｒａｎｔ”の機能を保持しているか否かでＰＤＮコネクションの切断を判断することができなくなるので、図２１の詳細データフィールドに格納される判断条件を用いて、ＰＤＮコネクションの切断を判断する。例えば、全てのＭＴＣデバイス１００が“Ｔｉｍｅ ｔｏｌｅｒａｎｔ”の機能を保持している環境において、“Ｔｉｍｅ ｔｏｌｅｒａｎｔ”の機能を保持し、“Ｍｏｂｉｌｅ Ｏｒｉｇｉｎａｔｅｄ ｏｎｌｙ”の機能も保持しているＭＴＣデバイス１００によって確立されたＰＤＮコネクションを切断するというブロードキャストメッセージは、“Ｍｏｂｉｌｅ Ｏｒｉｇｉｎａｔｅｄ ｏｎｌｙ”の機能を保持しているＭＴＣデバイス１００によって確立されたＰＤＮコネクションは切断するという送信制御メッセージになる。同様に、全てのＭＴＣデバイス１００が、“Ｔｉｍｅ ｔｏｌｅｒａｎｔ”の機能を保持している環境において、Ｔｉｍｅ ｔｏｌｅｒａｎｔ”の機能を保持し、「送信制御メッセージで示された時刻＞ＭＴＣデバイス１００内で記憶した時刻」の条件に当てはまる場合には、確立済みのＰＤＮコネクションを切断するという送信制御メッセージは、「送信制御メッセージで示された時刻＞ＭＴＣデバイス１００内で記憶した時刻」の条件に当てはまるＭＴＣデバイス１００によって確立されたＰＤＮコネクションは切断するという送信制御メッセージになる。そのため、ｅＮＢ１１０がブロードキャスト送信する送信制御メッセージにおいて、“Ｔｉｍｅ ｔｏｌｅｒａｎｔ”の機能を保持するＭＴＣデバイス１００であるか否かを識別するための図２１のＴｉｍｅ ｔｏｌｅｒａｎｔフィールドは省略できる。
以上、本発明の第８の実施の形態によれば、既にネットワーク側で混雑状態が起こっているとき、若しくは、あるメッセージ（例えば、ＰＤＮコネクション確立リクエストや、転送データ）を受信した時点で混雑状態が起こり始めたときに、ＵＥ１０５などから優先度の高い緊急メッセージ（Ｅｍｅｒｇｅｎｃｙ ｒｅｑｕｅｓｔや、Ｅｍｅｒｇｅｎｃｙ ｍｅｓｓａｇｅとも呼ばれる）やアプリケーションメッセージが送られてくることで更なるリソース（Ｕ−ｐｌａｎｅ、Ｃ−ｐｌａｎｅ共）が必要となる課題に対して、ネットワーク側からブロードキャスト送信されるメッセージで、ＭＴＣデバイス１００が“Ｔｉｍｅ ｔｏｌｅｒａｎｔ”の機能を保持しており、そして、詳細データフィールドで示される値（例えば、“Ｂｅｆｏｒｅ ｔｉｍｅ”で示されるデータ転送を開始してから経過した時間）を用いて、既に確立済みであるＰＤＮコネクションの維持／切断をする。これにより、優先度レベルの高いリクエストやアプリケーションのためのリソースを確保することができる。
また、ネットワーク側（例えば、ｅＮＢ１１０やＭＭＥ１２０、ＳＧＷ１３０、ＰＧＷ１４０、ＭＴＣサーバ１５０）から対象となるＭＴＣデバイス１００（例えば、特定のＡＰＮに接続しているＭＴＣデバイス１００、特定のＭＴＣグループに属しているＭＴＣデバイス１００、特定のオペレータに属しているＭＴＣデバイス１００、特定のエリア（例えば、特定のｅＮＢ１１０やＭＭＥ１２０に接続しているＭＴＣデバイス１００）など）にメッセージがブロードキャストされることによって、メッセージ（例えば、ＰＤＮコネクション確立リクエスト）を送信しようとしていたＭＴＣデバイス１００からのメッセージを回避することができる。それにより、ネットワーク側のエンティティ（例えば、ｅＮＢ１１０やＭＭＥ１２０、ＳＧＷ１３０、ＰＧＷ１４０、ＭＴＣサーバ１５０）の処理負荷やトラフィックが軽減される。
また、上記の実施の形態でネットワーク側のエンティティ（例えば、ｅＮＢ１１０やＭＭＥ１２０、ＳＧＷ、ＰＧＷ、ＭＴＣサーバ１５０）からメッセージ（例えば、本発明の第１〜第７の実施の形態では逆イベント通知メッセージ、本発明の第８の実施の形態では送信制御メッセージ）がブロードキャストされる。ネットワーク側のエンティティ（例えば、ｅＮＢ１１０、ＭＭＥ１２０、ＳＧＷ１３０、ＰＧＷ１４０、ＭＴＣサーバ１５０）は、非特許文献６で定義されるように、このブロードキャストされるメッセージにＭＴＣデバイス１００が送信するメッセージを遅らすための待機時間（Ｓｔｏｐ ｔｉｍｅ、Ｂａｒｒｉｎｇ ｔｉｍｅ、Ｂａｃｋｏｆｆ ｔｉｍｅ、Ｗａｉｔ ｔｉｍｅなどとも呼ばれる）を格納する場合もある。ＭＴＣデバイス１００は、この待機時間の間はデータ送信やＰＤＮコネクション確立リクエストなどのメッセージ送信を行えないものとする（例えば、ＭＴＣデバイス１００が通常モードからデータ送信抑制モードや、規制モード、制限モードなどにモード遷移する）。しかし、優先度レベルの高いイベントを検知した場合や、緊急事態が生じた場合には、ネットワーク側からメッセージ送信の抑制をされているが、ＭＴＣデバイス１００はデータ送信やＰＤＮコネクション確立リクエストの送信が可能なモード（例えば、通常モード）にモード遷移できるものとする。また、この待機時間は、詳細データフィールドに格納されるＰＤＮコネクションを維持／切断するための条件（例えば、Ｂｅｆｏｒｅ ｔｉｍｅ）と共用してもよい。例えば、待機時間を「３分」と設定し、優先度レベルの低いＭＴＣデバイスからのメッセージ（例えば、ＰＤＮコネクション確立リクエスト）を３分間抑制すると同時に、３分以内に確立されたＰＤＮコネクションを切断するように指示してもよい。なお、このとき、詳細データフィールドは省略でき、通信システムのエンティティやＭＴＣデバイス１００の処理負荷、ネットワークのトラフィックが軽減される。
また、上記の実施の形態（特に第８の実施の形態）で、ＭＴＣデバイス１００とネットワーク側のエンティティが、異なる優先度レベルを認識できる場合（例えば、アプリケーションＡのデータは優先度レベルＡであり、ＵＥ１０５からのメッセージは優先度レベルＢなど）、ネットワーク側のエンティティ（例えば、ｅＮＢ１１０、ＭＭＥ１２０、ＳＧＷ１３０、ＰＧＷ１４０、ＭＴＣサーバ１５０）は優先度レベル毎にメッセージ送信を抑制してもよい。例えば、ｅＮＢ１１０がブロードキャスト送信する送信制御メッセージに「優先度レベルＢのみ抑制」ということを示すパラメータを格納する。この送信制御メッセージを受信したＭＴＣデバイス１００は、優先度レベルＢのメッセージのみ送信を遅らせる／停止させる、若しくは、優先度レベルを変化させてメッセージを送信する。例えば、「優先度レベルＢのみ抑制」であるが、「ＭＴＣグループＡに属しているＭＴＣデバイス１００は免除」ということを示すパラメータと組み合わせて使用してもよい。また、優先度レベルだけではなく、従来技術の、例えば、Ａｃｃｅｓｓ ｃｌａｓｓを用いてＭＴＣデバイス１００から送信されるメッセージを抑制してもよい。
また、上記の実施の形態（特に第１〜第８の実施の形態）におけるＭＴＣデバイス１００は、１つのＭＴＣグループや１つのＡＰＮ、１つのＰＬＭＮオペレータに属していたが、複数のＭＴＣグループや複数のＡＰＮ、複数のＰＬＭＮオペレータに属してもよい。例えば、ＭＴＣデバイス１００が２つのＡＰＮ（ＡＰＮ−１とＡＰＮ−２）に接続している場合、通信システムは段階的にＭＴＣデバイス１００から送信されるメッセージを抑制することができる。例えば、ネットワーク側のエンティティ（例えば、ｅＮＢ１１０、ＭＭＥ１２０、ＳＧＷ１３０、ＰＧＷ１４０、ＭＴＣサーバ１５０）がブロードキャスト送信する送信制御メッセージ、若しくは、逆イベント通知メッセージに「ＡＰＮ−１を用いた送信メッセージを抑制」ということを示すパラメータを格納する。これにより、ＭＴＣデバイス１００はＡＰＮ−１を用いたメッセージ送信は抑制されるが、ＡＰＮ−２を用いたメッセージ送信は可能となる。
また、本発明の第８の実施の形態では、説明の容易化のために、“Ｔｉｍｅ ｔｏｌｅｒａｎｔ”フィールドと詳細データフィールドを用いた結果、確立済みのＰＤＮコネクションを切断すると多く記述したが、通信システムのオペレータのポリシやＭＴＣサーバ、ＭＴＣユーザのポリシ、アプリケーションのポリシ、ＭＴＣデバイスのポリシによっては、確立済みのＰＤＮコネクションを切断ではなく、「維持」すると決定してもよい。
なお、本発明の第８の実施の形態では、“Ｔｉｍｅ ｔｏｌｅｒａｎｔ”の機能を保持し、詳細データフィールドで指定された条件に該当するＭＴＣデバイス１００が、既にＰＤＮコネクションを確立済みである場合、ＭＴＣデバイス１００はＰＤＮコネクションを切断していたが（図２４のステップＳ１２２１、Ｓ１２２２、Ｓ１２３０、Ｓ１２５０）、ＰＤＮコネクションは切断せずに（維持したまま）、データ送信のみ制御（例えば、停止、データレートの変更、データサイズの変更）を行ってもよい。これにより、Ｕ−ｐｌａｎｅのリソースを段階的に確保することができる。また、ＰＤＮコネクションを切断しないため、再度ＰＤＮコネクションを確立する必要がなくなり、通信システムのエンティティ（例えば、ｅＮＢ１１０、ＭＭＥ１２０、ＳＧＷ１３０、ＰＧＷ１４０）の処理負荷が軽減される（例えば、アドレスの割り当て、バインディングアップデート）。
なお、本発明の第８の実施の形態は、通信システムのエンティティが対象となるＭＴＣデバイス１００にブロードキャストして、優先度レベルの高いＵＥ１０５やＭＴＣデバイス１００のためのリソースを確保するためにＰＤＮコネクションを切断しているが、ブロードキャストではなく、ユニキャストやマルチキャストで送信してもよい。
なお、本発明の第８の実施の形態は、図１９、２０を用いて説明したように、ＭＴＣデバイスＤ１００ＤがＰＤＮコネクション確立リクエストをネットワーク側に送信した結果（図２０のステップＳ１００２）、ネットワーク側が混雑状態になり（図２０のステップＳ１００３）、送信制御メッセージがＭＴＣデバイスに送信されていた（図２０のステップＳ１００６）。つまり、送信制御メッセージは、ネットワーク側が混在状態にある場合に、優先度レベルが低いＭＴＣデバイス１００からのメッセージ（例えば、ＰＤＮコネクション確立リクエスト）の回避と、既に確立済みのＰＤＮコネクションを切断することを要求するために使用された。さらに、送信制御メッセージは、既にＰＤＮコネクションを確立済みであるＭＴＣデバイス１００が、新たに送信する可能性がある別のＰＤＮコネクション確立リクエストを拒絶する、あるいは遅延させるためにも用いることができる。送信制御メッセージを新たなＰＤＮコネクション確立リクエストの遅延のために用いる場合、混雑状態を検出した際に通信システムのエンティティは、待機時間を含む送信制御メッセージを対象となるＭＴＣデバイスへブロードキャストする。このとき、ネットワーク側がブロードキャスト送信する送信制御メッセージにパラメータ情報として格納される待機時間は、既にＰＤＮコネクションを確立済みであるＭＴＣデバイス１００（ＭＴＣデバイスＡ１００Ａ、ＭＴＣデバイスＢ１００Ｂ、ＭＴＣデバイスＣ１００Ｃ、ＭＴＣデバイスＤ１００Ｄ）が送信する追加のＰＤＮコネクション確立メッセージの送信タイミングを遅らせることを指示する情報として用いられる。この送信制御メッセージを受信したＭＴＣデバイス１００は、ＭＴＣデバイス１００自身が既に確立済みのＰＤＮコネクションを保持済みであり、新たに別のＰＤＮコネクションを確立したい場合は、待機時間が経過するまでそのＰＤＮコネクション確立リクエストの送信を遅らせると判断する。例えば、既に１つのＰＤＮコネクションを確立しているＭＴＣデバイス１００が、さらに１つのＰＤＮコネクションを新たに追加で確立しようとしていた場合、送信制御メッセージを受けることで、２つ目のＰＤＮコネクションの確立要求の送信を、待機時間後へと遅らせる。
また、既にＰＤＮコネクションを確立済みであるＭＴＣデバイス１００が、待機時間が格納されていない送信制御メッセージを受信した場合、追加のＰＤＮコネクション確立リクエストを送信しないようにすることもできる。例えば、送信制御メッセージに「追加確立禁止」を示すパラメータを格納することで、ＭＴＣデバイス１００による追加のＰＤＮコネクション確立リクエスト送信を回避する。
また、既にＰＤＮコネクションを確立済みであるＭＴＣデバイス１００が、待機時間が格納されていない送信制御メッセージであり、さらにＭＴＣデバイス１００による追加予定のＰＤＮコネクションに対するパラメータ（例えば、各ＭＴＣデバイス１００が確立可能なＰＤＮコネクションの最大数、又は、追加ＰＤＮコネクションに割り当て可能なＱｏＳなど）が格納された送信制御メッセージを受信した場合、追加のＰＤＮコネクションを確立する際にこの情報に従って、ＰＤＮコネクション確立リクエストを送信する。
例えば、パラメータ情報に、同時に確立可能なＰＤＮコネクションの最大数が含まれている場合、ＭＴＣデバイス１００自身が確立したいＰＤＮコネクション数と送信制御メッセージに格納されている、同時に確立可能なＰＤＮコネクションの最大数を比較し、確立したいＰＤＮコネクションの数が、同時に確立可能なＰＤＮコネクションの数を上回る場合は、確立済みのＰＤＮコネクションが終了した後に、新たなＰＤＮコネクションの確立を行う。つまり、２つ目のＰＤＮコネクションを確立したいＭＴＣデバイス１００が、同時確立可能なＰＤＮコネクションの数が１つであるパラメータ情報を受信した場合は、確立した１つ目のＰＤＮコネクションを用いた通信が終了し、そのＰＤＮコネクションを切断した後に、２つ目の新たな別のＰＤＮコネクションを確立する。さらに、３つ目のＰＤＮコネクションを確立する場合には、２つ目のＰＤＮコネクションを用いた通信が終了した後に、そのＰＤＮコネクションを切断し、３つ目の新たなＰＤＮコネクションを確立する。なお、新たなＰＤＮコネクションを確立する必要が生じた際に、既に確立されているＰＤＮコネクションを直ぐに切断すると判断してもよい。また、パラメータ情報として、同時に確立可能なＰＤＮコネクションの数を通知する代わりに、追加のＰＤＮコネクションの確立が制限されていることを示す情報を送信制御メッセージに含めてもよい。この情報を受けたＭＴＣデバイス１００は、新たなＰＤＮコネクションを確立する場合は、既に確立しているＰＤＮコネクションを切断した後に、新たなＰＤＮコネクションの確立要求を送信する。
これにより、ＭＴＣデバイス１００が複数のＰＤＮコネクションを確立しなければならない場合（例えば、ＭＴＣデバイス１００が複数のＭＴＣサーバ１５０または複数のＡＰＮ、若しくは、複数のＭＴＣユーザ１６０と接続されていて、ＭＴＣユーザの情報セキュリティや契約関係上、ＰＤＮコネクションを分けて使用しなければならない場合）に、同時に確立できるＰＤＮコネクションの数を制限することで、同時に複数のＰＤＮコネクションを確立することによって帯域が占有されてしまうことを防ぐ効果がある。
また、上記したＭＴＣデバイス１００による追加予定のＰＤＮコネクションに対するパラメータ（例えば、各ＭＴＣデバイス１００が確立可能なＰＤＮコネクションの最大数、又は、追加ＰＤＮコネクションに割り当て可能なＱｏＳなど）に加えて、待機時間が格納される場合、ＭＴＣデバイス１００による追加予定のＰＤＮコネクションに対するパラメータ（例えば、各ＭＴＣデバイス１００が確立可能なＰＤＮコネクションの最大数、又は、追加ＰＤＮコネクションに割り当て可能なＱｏＳなど）の適用時間（有効期間）として使用することで、リアルタイムに変化するネットワーク側の混雑状態に沿ったリソース管理になる。例えば、ネットワーク側からブロードキャスト送信される送信制御メッセージに、待機時間（例えば、「１分」）が格納されており、かつ、「各ＭＴＣデバイス１００が確立可能なＰＤＮコネクションは１つ」と示されている場合、送信制御メッセージを受信したＭＴＣデバイス１００は、送信制御メッセージを受信した後から１分以内に新たなＰＤＮコネクション確立リクエストを送信する場合は、既に確立済みのＰＤＮコネクションを切断した後、追加のＰＤＮコネクションを確立する。待機時間の経過後は、「各ＭＴＣデバイス１００が確立可能なＰＤＮコネクションは１つ」と示されている情報は、適用時間を過ぎているので、追加のＰＤＮコネクションを確立する際には用いなくてよい。なお、追加予定のＰＤＮコネクションに対するパラメータが格納された送信制御メッセージを受信したＭＴＣデバイス１００は、追加のＰＤＮコネクションを確立する際、追加のＰＤＮコネクションの確立を諦めて既に確立済みのＰＤＮコネクションを維持するか、若しくは、既に確立済みのＰＤＮコネクションを切断して追加のＰＤＮコネクションを確立するかを、例えば、ＭＴＣデバイス１００が保持するコンテキスト（例えば、ＭＴＣサーバ１５０やＭＴＣユーザ１６０からの要求やスタティックな情報）や、アプリケーションに仕様に基づいて判断してもよい。
この「各ＭＴＣデバイス１００が確立可能なＰＤＮコネクションは１つ」と示されている情報は、送信制御メッセージの詳細データフィールドに格納してもよい。
なお、既にＰＤＮコネクションを確立しているＭＴＣデバイス１００に対して、追加のＰＤＮコネクションに対するパラメータを通知するメッセージは、ブロードキャストではなくユニキャストで送信されてもよい。この場合、ＭＴＣデバイス１００は、最初のＰＤＮコネクションを確立する際に（例えば、Ａｔｔａｃｈ ｐｒｏｃｅｄｕｒｅ中）、通信システムのエンティティから追加のＰＤＮコネクションに対するパラメータ（例えば、各ＭＴＣデバイス１００が確立可能なＰＤＮコネクションの最大数、又は、追加ＰＤＮコネクションに割り当て可能なＱｏＳなど）を含む送信制御メッセージを受信する。パラメータ情報を取得したＭＴＣデバイス１００は、上記のように、取得したパラメータ情報に従って追加のＰＤＮコネクションを確立するためのＰＤＮコネクション確立リクエストを送信する。
なお、追加のＰＤＮコネクションに対するパラメータ情報がＭＴＣデバイス１００に通知されるタイミングは、ＭＴＣデバイス１００から最初のＰＤＮコネクション確立リクエストを受けた際に限定されず、既にＰＤＮコネクションの確立が終了した後の任意のタイミングでもよい。つまり、ネットワーク側が混雑状態を検出した際に、既にＰＤＮコネクションを確立しているＭＴＣデバイス１００に対してパラメータ情報が通知される。また、ＭＴＣデバイス１００が送信する追加のＰＤＮコネクションの確立リクエストを受信した際に、その確立リクエストが拒絶されたことを通知する送信制御メッセージ、さらには追加のＰＤＮコネクションに対するパラメータ情報を含む送信制御メッセージをＭＴＣデバイス１００に通知してもよい。
＜第９の実施の形態＞
本発明の第９の実施の形態では、既にＰＤＮコネクションを確立済みの状態で、さらに追加のＰＤＮコネクション確立を望むＭＴＣデバイス１００が、ネットワークから通知される混雑状態に関する情報に基づいて、既に確立済みのＰＤＮコネクションをリリースし、追加のＰＤＮコネクションを確立する。
本発明の第９の実施の形態では、既にＰＤＮコネクションを確立済みの状態で、さらに追加のＰＤＮコネクション確立を望むＭＴＣデバイス１００が、ネットワークから通知される混雑状態に関する情報に基づいて、既に確立済みのＰＤＮコネクションをリリースし、追加のＰＤＮコネクションを確立する。
ＭＴＣデバイス１００は、ネットワークが混雑している場合でも、新たにＰＤＮコネクションを確立し、データを送信したい場合がある。例えば、ＭＴＣデバイス１００が人感センサであり、センサが不良動作を起こしていないかなどを確認するためのメンテナンスデータと、実際にセンサが取得したセンシングデータの送信先のＭＴＣサーバ１５０が異なり、メンテナンス用のＰＤＮコネクションは確立済みで、センシングしたデータを送信するためのＰＤＮコネクションを任意の期間のみ確立するケースや、又は、ＭＴＣデバイス１００が自動販売機であり、ＭＴＣサーバ１５０に接続するためのＰＤＮコネクションと、ＩＭＳ（ＩＰ Ｍｕｌｔｉｍｅｄｉａ Ｓｕｂｓｙｓｔｅｍ）に接続するためのＰＤＮコネクションがあり、ＭＴＣサーバ１５０に接続するためのＰＤＮコネクションは確立済みで、ＩＭＳに接続するためのＰＤＮコネクションを任意のタイミングで確立するケースなどがある。しかし、最初のＰＤＮコネクションを確立してから、追加のＰＤＮコネクションを確立するまでの間に、ネットワークは混雑状態を検出する場合があり、このとき、ＭＴＣデバイス１００が送信する追加のＰＤＮコネクション確立リクエストは拒絶されてしまう。また、ＭＴＣデバイス１００において、既に確立済みのＰＤＮコネクションで送信しているデータより、追加で確立するＰＤＮコネクションで送信するデータのほうが優先度レベルの高い場合がある。このとき、ＭＴＣデバイス１００が追加のＰＤＮコネクションを確立できない場合、ＭＴＣデバイス１００やＭＴＣサーバ１５０、ＭＴＣユーザ１６０などに優先度レベルが高いデータを送受信できないなどの不利益が生じる。このような課題を解決するために、既にＰＤＮコネクションを確立済みであるＭＴＣデバイス１００は、ネットワークから通知される混雑状態に関する情報に基づいて、既に確立済みのＰＤＮコネクションをリリースし、追加のＰＤＮコネクションを確立する。
以下、本発明の第９の実施の形態について、図２５、図２６、図２７Ａ〜図２７Ｅ、図２８〜図３０、図３５、図３６を用いて説明する。
ここで、本発明の第９の実施の形態の説明を容易化するために、本発明の第９の実施の形態におけるＭＴＣデバイス１００は、ネットワークと既にＰＤＮコネクションを１つ確立済みであり、確立済みのＰＤＮコネクション内のＥＰＳベアラに対して、ネットワークが保証するビットレート（ＧＢＲ：Guaranteed Bit Rate）は５Ｍｂｐｓとする。また、ＭＴＣデバイス１００は、追加のＰＤＮコネクションを確立するために、ＰＤＮコネクション確立リクエストを送信する。
この“ＧＢＲ＝５Ｍｂｐｓ”とは、ネットワークがＭＴＣデバイス１００に対して、５Ｍｂｐｓのビットレートを保証することを示している。例えば、ＭＴＣデバイス１００に５ＭｂｐｓのＧＢＲが割り当てられている間、ネットワークは５Ｍｂｐｓを下回るビットレート（例えば、４Ｍｂｐｓ）をＭＴＣデバイス１００に提供しないことを示している。
“ＧＢＲ＝５Ｍｂｐｓ”が割り当てられたＥＰＳベアラを含むＰＤＮコネクションを確立済みであるＭＴＣデバイス１００の動作について、図２５を用いて説明する。
図２５において、“ＧＢＲ＝５Ｍｂｐｓ”が割り当てられたＥＰＳベアラを含むＰＤＮコネクションを確立済みであるＭＴＣデバイス１００が、追加のＰＤＮコネクションを確立しようとする状態を前提とする（ステップＳ２５００）。ＭＴＣデバイス１００は、追加のＰＤＮコネクションを確立するためにＰＤＮコネクション確立リクエストを送信する（ステップＳ２５０１：ＰＤＮコネクション確立リクエスト）。なお、ＭＴＣデバイス１００がＰＤＮコネクションを確立する際、非特許文献３で定義されているＰＤＮ ｃｏｎｎｅｃｔｉｖｉｔｙ ｒｅｑｕｅｓｔメッセージや、Ｓｅｒｖｉｃｅ ｒｅｑｕｅｓｔや、Ｃｒｅａｔｅ Ｂｅａｒｅｒ ｒｅｑｕｅｓｔメッセージなどを使用してもよい。
このとき、ＰＤＮコネクション確立リクエストを受信したネットワークでは、ネットワーク側で混雑状態が発生してしまうとする（図２５の（Ａ）混雑発生）。そのため、ネットワークは、ステップＳ２５０１でＭＴＣデバイス１００から送信されたＰＤＮコネクション確立リクエストを拒絶するＰＤＮコネクション確立拒絶レスポンスを送信する（ステップＳ２５０２：ＰＤＮコネクション確立拒絶レスポンス）。
追加のＰＤＮコネクション確立を拒絶されたＭＴＣデバイス１００は、追加のＰＤＮコネクションの優先度レベルと確立済みのＰＤＮコネクションの優先度レベルを比較する（ステップＳ２５０３：優先度レベルの比較）。なお、ＰＤＮコネクションの優先度レベルは、アプリケーションレイヤから取得できるアプリケーション毎に割り当てられる優先度レベルや、ＭＴＣデバイス１００が保持するポリシ、ＭＴＣデバイス１００がＭＴＣのためにスタティック（静的）に格納されている情報（例えば、最初に起動したアプリケーションを優先的に処理するなど）などを用いて取得してもよい。
追加のＰＤＮコネクションの優先度レベルのほうが高いと判断したＭＴＣデバイス１００は、確立済みのＰＤＮコネクションの代わりとして追加のＰＤＮコネクションを確立できるか確認するために、既に確立済みのＰＤＮコネクションのＥＰＳベアラに割り当てられているＱｏＳ情報（ＧＢＲ情報など）と、追加のＰＤＮコネクションのＥＰＳベアラに必要なＱｏＳ情報（ＧＢＲ情報など）を比較する（ステップＳ２５０４：ＱｏＳ比較）。
例えば、ＧＢＲで比較する場合には、図２７Ａで示すように、確立済みのＰＤＮコネクションのＥＰＳベアラに割り当てられているＧＢＲが１Ｍｂｐｓの場合、ＭＴＣデバイス１００は、追加のＰＤＮコネクションのＥＰＳベアラに必要なＧＢＲが１Ｍｂｐｓ以下であれば、確立済みのＰＤＮコネクションを切断することで、追加のＰＤＮコネクションを確立できる。なお、このとき、ＭＴＣデバイス１００は従来であれば、追加のＰＤＮコネクションを確立することができないが、確立済みのＰＤＮコネクションより追加のＰＤＮコネクションの優先度レベルのほうが高いことを知得した場合、ＭＴＣデバイス１００は確立済みのＰＤＮコネクションをリリースした後、ＭＴＣデバイス１００は追加のＰＤＮコネクションを確立する。
また、ＱＣＩで比較する場合には、図２７Ｂで示すように、ＭＴＣデバイス１００が、追加で確立するＰＤＮコネクションのＱＣＩが、既に確立済みのＰＤＮコネクションに割り当てられているＱＣＩと一致している場合、ＭＴＣデバイス１００は確立済みのＰＤＮコネクションを切断することで、追加のＰＤＮコネクションを確立できる。また、ＱＣＩが一致しており、かつ確立済みのＰＤＮコネクションのＧＢＲが、追加で確立するＰＤＮコネクションのＧＢＲよりも大きい場合に、ＭＴＣデバイス１００は確立済みのＰＤＮコネクションを切断することで、追加のＰＤＮコネクションを確立できると判断してもよい。このように、上記のＧＢＲを用いた説明と同様に、ＭＴＣデバイス１００は従来であれば、追加のＰＤＮコネクションを確立することができないが、確立済みのＰＤＮコネクションより追加のＰＤＮコネクションの優先度レベルのほうが高いため、ＭＴＣデバイス１００は確立済みのＰＤＮコネクションをリリースした後、ＭＴＣデバイス１００は追加のＰＤＮコネクションを確立する。
また、ＱｏＳ情報を複数用いて、ＭＴＣデバイス１００が確立済みのＰＤＮコネクションをリリースして、追加のＰＤＮコネクションを確立するか判断してもよい。例えば、ＭＴＣデバイス１００が、ＱｏＳ情報として、ＧＢＲとＭＢＲを用いてもよい。この場合、ＭＴＣデバイス１００は、最初のステップとして、追加で確立するＰＤＮコネクションのベアラで用いられるＧＢＲが、「既に確立済みのＰＤＮコネクションのベアラで用いられるＧＢＲ」以下であるか確認する。「既に確立済みのＰＤＮコネクションのベアラで用いられるＧＢＲ」以下の場合、ＭＴＣデバイス１００は、ＧＢＲに続いてＭＢＲも同様に確認する。ＭＢＲも同様に「既に確立済みのＰＤＮコネクションのベアラで用いられるＭＢＲ」以下の場合、ＭＴＣデバイス１００は、既に確立済みのＰＤＮコネクションをリリーすることによって確保されるリソースを用いて追加のＰＤＮコネクションを確立することができると判断し、既に確立済みのＰＤＮコネクションをリリースする。そして、ＭＴＣデバイス１００は、新しいＰＤＮコネクションを確立する。
なお、上記の説明例では、ＱｏＳ情報の比較処理を実施する際、ＧＢＲ、ＱＣＩ、ＭＢＲを挙げているが、他のＱｏＳ情報に関する例も含めて、図２６にアクション、図２７Ａ〜図２７Ｅにアクション結果が図示されている。
また、上記のＱｏＳ比較処理の説明では、ＭＴＣデバイス１００が１つのＰＤＮコネクションを確立済みの状態を前提としていたが、ＭＴＣデバイス１００が複数のＰＤＮコネクションを確立済みの状態では、各ＰＤＮコネクション、若しくは、各ＰＤＮコネクションのＥＰＳベアラに割り当てられているＱｏＳ情報の合計（ＧＢＲの合計など）や、もしくは、両方（ＱＣＩが一致するベアラケースなど）が、追加で確立するＰＤＮコネクションで必要なＱｏＳ情報を満たすことができる場合、ＭＴＣデバイス１００は追加のＰＤＮコネクションを確立することができる。このとき、ＭＴＣデバイス１００は、確立済みのＰＤＮコネクションを全てリリースしてもよいし、追加のＰＤＮコネクションに必要なＱｏＳ情報を確保するためにリリースする必要があるＰＤＮコネクションを複数選択した後、それらをリリースしてもよい。
なお、追加のＰＤＮコネクションや、ＥＰＳベアラに必要なＱｏＳ情報は、例えば、ＭＴＣサービスのアプリケーションや、ＭＴＣデバイス１００が保持するポリシ、ＭＴＣデバイス１００にＭＴＣのためにスタティックに格納されている情報、ＭＴＣサーバ１５０やＭＴＣユーザ１６０から直接通知される情報などから取得してもよい。
ステップＳ２５０４において比較した結果、追加で確立するＰＤＮコネクションのＥＰＳベアラのＱｏＳ情報（ＧＢＲ情報）が、既に確立済みのＰＤＮコネクションのＥＰＳベアラに割り当てられているＱｏＳ情報（ＧＢＲ情報）以下であれば（例えば、既に確立済みのＰＤＮコネクションのＥＰＳベアラに割り当てられているＧＢＲ情報が５Ｍｂｐｓで、追加で確立するＰＤＮコネクションのＥＰＳベアラで必要なＧＢＲ情報が４Ｍｂｐｓの場合など）、確立済みのＰＤＮコネクションをリリースする（ステップＳ２５０５：ＰＤＮコネクションＲｅｌｅａｓｅ ｐｒｏｃｅｄｕｒｅ）。なお、確立済みのＰＤＮコネクションをリリースする際に、非特許文献３で定義されるＵＥ ｒｅｑｕｅｓｔｅｄ ＰＤＮ ｄｉｓｃｏｎｎｅｃｔｉｏｎ ｐｒｏｃｅｄｕｒｅや、ＵＥ−ｉｎｉｔｉａｔｅｄ Ｄｅｔａｃｈ ｐｒｏｃｅｄｕｒｅ、ＵＥ ｒｅｑｕｅｓｔｅｄ ｂｅａｒｅｒ ｒｅｓｏｕｒｃｅ ｍｏｄｉｆｉｃａｔｉｏｎ ｐｒｏｃｅｄｕｒｅなどを使用してもよい。
また、ＭＴＣデバイス１００が、ＰＤＮコネクションをリリースすることによって確保されたリソースが、ＭＴＣデバイス１００ではなく、他のＭＴＣデバイスやＵＥに割り当てられてしまう場合が考えられる。この場合、ＭＴＣデバイス１００は、確立済みのＰＤＮコネクションをリリースする際、リリースしたＰＤＮコネクションのＥＰＳベアラに割り当てられているＱｏＳ情報（ＧＢＲ情報）を新たに確立するＰＤＮコネクションで再使用することをネットワークへ通知する。
図２８は、ＭＴＣデバイス１００がＵＥ ｒｅｑｕｅｓｔｅｄ ＰＤＮ ｄｉｓｃｏｎｎｅｃｔｉｏｎ ｐｒｏｃｅｄｕｒｅを用いて、ネットワーク側にリリースしたＰＤＮコネクションのＥＰＳベアラに割り当てられていたリソース（ＱｏＳ情報）を新たに確立するＰＤＮコネクションで再使用することをネットワークへ通知するメッセージのフォーマット例である。
図２８に図示されているメッセージは、従来のＰＤＮ Ｄｉｓｃｏｎｎｅｃｔｉｏｎ Ｒｅｑｕｅｓｔメッセージフィールドに加えて、他のＭＴＣデバイス１００やＵＥ１０５にＱｏＳ情報（ＧＢＲ情報）を割り当てないように通知するためのＱｏＳ保持フィールド、ＭＴＣデバイス１００が要求するネットワーク側でＱｏＳ情報を保持する期間を示す保持期間フィールドで構成される。
続いて、図２５において、確立済みのＰＤＮコネクションをリリース後、ＭＴＣデバイス１００は、ＰＤＮコネクション確立リクエストを送信する（ステップＳ２５０６：ＰＤＮコネクション確立リクエスト）。このとき、ネットワーク側が、ＰＤＮコネクションをリリースすることによって確保されたリソースを使用して新たにＰＤＮコネクションを確立しようとしているＭＴＣデバイス１００であることを識別できることとする。例えば、ＰＤＮコネクション確立リクエストに格納されているＭＴＣデバイス１００のＩＭＳＩやＩＭＥＩ、又は、ＰＤＮコネクションＲｅｌｅａｓｅ ｐｒｏｃｅｄｕｒｅ中に交換した新規の識別子などを用いてＭＴＣデバイス１００を識別してもよい。
ステップＳ２５０６のＰＤＮコネクション確立リクエストを受信したネットワークは、ＰＤＮコネクションをリリースすることによって確保されたリソースを使用して新たにＰＤＮコネクションを確立しようとしているＭＴＣデバイス１００であることを確認し、ＰＤＮコネクション確立許可レスポンスを送信する（ステップＳ２５０７：ＰＤＮコネクション確立許可レスポンス）。
ＰＤＮコネクション確立後、ＭＴＣデバイス１００はステップＳ２５０７で確立したＰＤＮコネクションのＥＰＳベアラで使用するＱｏＳ情報（ＧＢＲ情報）に変更するため、ＰＤＮコネクションＭｏｄｉｆｉｃａｔｉｏｎ ｐｒｏｃｅｄｕｒｅを実施する（ステップＳ２５０８）。このときも、ステップＳ２５０６のときと同様に、ネットワークは、確保しているリソースの対象ＭＴＣデバイス１００であることを識別できることとする。なお、ステップＳ２５０４のＱｏＳ情報の比較後、ＭＴＣデバイス１００が確立済みのＰＤＮコネクションをリリースし、ＰＤＮコネクションの確立処理をするのではなく、ＰＤＮコネクションＭｏｄｉｆｉｃａｔｉｏｎ ｐｒｏｃｅｄｕｒｅをするだけで、新たに確立しようとしているＰＤＮコネクションと同等のＰＤＮコネクションが確保できる場合は、ステップＳ２５０５からステップＳ２５０７を省略してもよい。
確立したＰＤＮコネクションのＱｏＳ情報を更新後、ＭＴＣデバイス１００はＰＤＮコネクションの確立を完了する（ステップＳ２５０９：ＰＤＮコネクション確立完了）。
なお、第９の実施の形態では、ＭＴＣデバイス１００が追加のＰＤＮコネクションを送信した際にネットワークが混雑状態を検出して、ＰＤＮコネクションの確立を拒絶しているが、例えば、他のＭＴＣデバイス１００やＵＥ１０５によるデータ送信などによる混雑発生を機に、例えば、同じＭＴＣグループや同じｅＮＢ１１０に接続しているＭＴＣデバイス１００など、複数のＭＴＣデバイス１００やＵＥ１０５に対して、ブロードキャストメッセージで、追加のＰＤＮコネクションの確立拒絶を通知してもよい。
次に、図２９を参照しながら、本発明の第９の実施の形態におけるＭＴＣデバイス１００の構成について説明する。図２９は、本発明の第９の実施の形態におけるＭＴＣデバイス１００の構成の一例を示す図である。
図２９において、ＭＴＣデバイス１００は、通信システム（例えば、Ｅ−ＵＴＲＡＮやＵＴＲＡＮ）と接続して下位レイヤにおける通信処理と上位レイヤでＩＰなどのパケット通信処理を実施する通信処理部２７０１、ＰＤＮコネクション確立リクエストの送信や確立したＰＤＮコネクションのＥＰＳベアラに割り当てられるＱｏＳ情報の更新、ＰＤＮコネクションのリリースなどを処理するＰＤＮコネクション処理部２７０２、確立済みＰＤＮコネクションのＱｏＳ情報と追加で確立するＰＤＮコネクションのＱｏＳ情報を比較するＱｏＳ情報比較部２７０３を少なくとも有する。なお、図２９には不図示だが、ＭＴＣデバイス１００は、追加のＰＤＮコネクションの優先度レベルと確立済みのＰＤＮコネクションの優先度レベルを比較する優先度レベル比較部を有していてもよい。
次に、図２９に図示されている構成を有するＭＴＣデバイス１００について、本発明における特徴的な処理を中心に、図３０を用いて詳しく説明する。
図３０において、ＭＴＣデバイス１００は、既にＰＤＮコネクションを１つ確立済みの状態であり、追加のＰＤＮコネクションの確立リクエストをＰＤＮコネクション処理部２７０２から通信処理部２７０１を介して、ネットワークに送信する（ステップＳ２８０１：ＰＤＮコネクション確立リクエスト送信）。
ＰＤＮコネクション確立リクエストを受信したネットワークでは、混雑状態を検出しているため、ＭＴＣデバイス１００は、３Ｇアクセスから送信されるＰＤＮコネクション確立拒絶レスポンスを受信する（ステップＳ２８０２：ＰＤＮコネクション確立拒絶レスポンス受信）。
追加ＰＤＮコネクションの確立を拒絶されたＭＴＣデバイス１００は、ＱｏＳ情報比較部２７０３にて、確立済みのＰＤＮコネクションのＥＰＳベアラに割り当てられているＱｏＳ情報と、追加で確立するＰＤＮコネクションのＥＰＳベアラに必要なＱｏＳ情報を比較する（ステップＳ２８０３：ＱｏＳ情報の比較）。なお、ＭＴＣデバイス１００は、優先度レベル比較部において、追加のＰＤＮコネクションの優先度レベルと確立済みのＰＤＮコネクションの優先度レベルを比較し、追加のＰＤＮコネクションの優先度レベルのほうが高いと判断した場合に、確立済みのＰＤＮコネクションの代わりとして追加のＰＤＮコネクションを確立できるか確認するために、ＱｏＳ情報の比較を行うようにしてもよい。
ステップＳ２８０３において比較した結果、追加で確立するＰＤＮコネクションのＱｏＳ情報が、確立済みのＰＤＮコネクションのＱｏＳ情報以下であれば（例えば、追加で確立するＰＤＮコネクションのＥＰＳベアラで必要なＧＢＲが４Ｍｂｐｓで、既に確立済みのＰＤＮコネクションのＥＰＳベアラのＧＢＲが５Ｍｂｐｓである場合など）、ＱｏＳ情報比較部２７０３からＰＤＮコネクション処理部２７０２に確立済みのＰＤＮコネクションをリリースするように指示し、通信処理部２７０１を介して、ＰＤＮコネクションをリリースするためのメッセージを送信する（ステップＳ２８０４：確立済みＰＤＮコネクションリリース）。このとき、ＭＴＣデバイス１００は、リリースするＰＤＮコネクションに割り当てられているリソース（例えば、通信リソースや帯域リソースなど）を他のＭＴＣデバイス１００やＵＥ１０５に割り当てないように指示するための識別子を送信するメッセージに格納する。
一方、ステップＳ２８０３において比較した結果、追加で確立するＰＤＮコネクションのＱｏＳ情報が、確立済みのＰＤＮコネクションのＱｏＳ情報より大きければ（例えば、追加で確立するＰＤＮコネクションのＥＰＳベアラで必要なＧＢＲが６Ｍｂｐｓで、既に確立済みのＰＤＮコネクションのＥＰＳベアラのＧＢＲが５Ｍｂｐｓである場合など）、確立済みのＰＤＮコネクションはリリースされることなく、維持される。
確立済みのＰＤＮコネクションをリリースしたＭＴＣデバイス１００は、ＰＤＮコネクション処理部２７０２から通信処理部２７０１を介して、追加のＰＤＮコネクションを確立する（ステップＳ２８０５：追加のＰＤＮコネクション確立）。この場合もステップＳ２８０４と同様に、ＭＴＣデバイス１００は、ネットワークが、ＰＤＮコネクションをリリースしたＭＴＣデバイス１００であることを識別できるような識別子を、追加のＰＤＮコネクション確立リクエストに格納する。
ＰＤＮコネクションを確立後、ＭＴＣデバイス１００は、デフォルトのＰＤＮコネクションのＱｏＳ情報から追加のＰＤＮコネクションが必要とするＱｏＳ情報に更新するため、非特許文献３で定義されるＵＥ ｒｅｑｕｅｓｔｅｄ ｂｅａｒｅｒ ｒｅｓｏｕｒｃｅ ｍｏｄｉｆｉｃａｔｉｏｎ ｐｒｏｃｅｄｕｒｅなどを用いて、更新する（ステップＳ２８０６：追加ＰＤＮコネクションのＱｏＳ情報を更新）。この場合もステップＳ２８０４と同様に、ＭＴＣデバイス１００は、ネットワークが、ＰＤＮコネクションをリリースしたＭＴＣデバイス１００であることを識別できるような識別子を、確立したＰＤＮコネクションのＱｏＳ情報の更新メッセージに格納する。
なお、ステップＳ２８０３のＱｏＳ情報の比較後、ＭＴＣデバイス１００が確立済みのＰＤＮコネクションをリリースし、ＰＤＮコネクションの確立処理をするのではなく、ＰＤＮコネクションＭｏｄｉｆｉｃａｔｉｏｎ ｐｒｏｃｅｄｕｒｅを実施し、ＭＴＣデバイス１００が要求するＰＤＮコネクションを実現できる場合は、ステップＳ２８０４及びステップＳ２８０５を省略してもよい。
なお、上記の第９の実施の形態では、ネットワークからＭＴＣデバイス１００に混雑状態に関する情報が通知され、ＭＴＣデバイス１００は確立済みのＰＤＮコネクション、若しくは、ＰＤＮコネクションのＥＰＳベアラに割り当てられているＱｏＳ情報と、追加のＰＤＮコネクションで必要なＱｏＳ情報を比較して、確立済みのＰＤＮコネクションをリリースすることで確保されるリソースを、新たなＰＤＮコネクションの確立に用いることができるか否かを判断している。このＱｏＳ情報に加えて、ＭＴＣデバイス１００は、ＭＴＣデバイス１００の確立可能なＰＤＮコネクション数を確立済みのＰＤＮコネクションをリリースする際の判断材料として用いてもよい。
この確立可能なＰＤＮコネクション数の情報を、例えば、ＭＴＣデバイス１００が、ＭＴＣのためにスタティックに格納している情報から取得してもよい、又は、ネットワークが任意のタイミング（例えば、混雑状態を検出したとき）でＭＴＣデバイス１００に確立可能なＰＤＮコネクション数をあらかじめ通知してもよい、又は、ＭＴＣデバイス１００は、確立済みのＰＤＮコネクションを確立した際にネットワークから「ＭＴＣデバイス１００が確立可能なＰＤＮコネクション数は１つ」という情報を取得してもよい、又は、ネットワークは、ＰＤＮコネクション確立拒絶レスポンスで、ＱｏＳ情報は通知することはできないが、「ＭＴＣデバイス１００が確立可能なＰＤＮコネクション数」の情報のみを通知できる場合は、ＭＴＣデバイス１００が追加のＰＤＮコネクションを確立する際に送信するＰＤＮコネクション確立リクエストの返信（ＰＤＮコネクション確立拒絶レスポンス）で、「ＭＴＣデバイス１００が確立可能なＰＤＮコネクション数は１つ」という情報を通知してもよい。
このように、ＱｏＳ情報と確立可能なＰＤＮコネクション数を組み合わせることにより、ネットワークは割り当て可能なリソースを精度高く制御することができる。例えば、ネットワークが、ＰＤＮコネクションを１つ確立済みのＭＴＣデバイス１００から、追加のＰＤＮコネクションの確立リクエストを受信した場合、ネットワークがＭＴＣデバイス１００に対して、ＰＤＮコネクション確立拒絶レスポンスを送信する。このとき、ＭＴＣデバイス１００は保持している確立可能なＰＤＮコネクション数の情報を用いて、現在確立しているＰＤＮコネクション数を確認し、さらに確立済みのＰＤＮコネクションが存在する場合、その確立済みのＰＤＮコネクション、若しくは、確立済みのＰＤＮコネクションのＥＰＳベアラに割り当てられているＱｏＳ情報（例えば、ＧＢＲ＝１Ｍｂｐｓ）と追加で確立するＰＤＮコネクションで必要なＱｏＳ情報（５００ｋｂｐｓ）を比較し、追加のＰＤＮコネクションで必要とされるＱｏＳ情報を満たすことができる場合、ＭＴＣデバイス１００は確立済みのＰＤＮコネクションをリリースし、追加のＰＤＮコネクションを確立することができる。
なお、ＭＴＣデバイス１００の保持する確立可能なＰＤＮコネクション数の情報とＰＤＮコネクション数を管理するＰＤＮコネクション処理部で情報共有（同期）がとれていない場合や、ＰＤＮコネクション確立拒絶レスポンスで取得できる情報（例えば、混雑レベルや現在の確立可能なＰＤＮコネクション数）を得る場合や、確立済みのＰＤＮコネクションより優先度レベルの高いＰＤＮコネクションの確立リクエストの場合があるため、ＭＴＣデバイス１００が保持する確立可能なＰＤＮコネクション数に既に確立済みのＰＤＮコネクションの数が達している状態にもかかわらず、ＭＴＣデバイス１００は追加のＰＤＮコネクション確立するためのＰＤＮコネクション確立リクエストを送信する可能性がある。
以上、本発明の第９の実施の形態によれば、既にＰＤＮコネクションを確立済みのＭＴＣデバイス１００が追加のＰＤＮコネクションを確立する際、ネットワークで混雑状態を検出している場合でも、確立済みのＰＤＮコネクションに割り当てられているＱｏＳ情報と追加で確立するＰＤＮコネクションに必要なＱｏＳ情報を比較し、追加で確立するＰＤＮコネクションに必要なＱｏＳ情報が、確立済みのＰＤＮコネクションに割り当てられているＱｏＳ情報を満たすことができる場合、ＭＴＣデバイス１００は確立済みＰＤＮコネクションをリリース又は変更し、追加のＰＤＮコネクションを確立することができる。これにより、ＭＴＣデバイス１００は優先度レベルが高いデータを送信することができ、ＭＴＣデバイス１００やＭＴＣサーバ１５０、ＭＴＣユーザ１６０などに優先度レベルが高いデータを送信できないなどの問題は解決される。
＜第１０の実施の形態＞
本発明の第１０の実施の形態では、既にＰＤＮコネクションを確立済みの状態で、さらに追加のＰＤＮコネクション確立を望むＭＴＣデバイス１００が、ネットワークから通知されるＭＴＣデバイス１００やＵＥ１０５に割り当て可能な通信リソースや帯域リソースの情報に基づいて、既に確立済みのＰＤＮコネクションをリリースし、追加のＰＤＮコネクションを確立する。
本発明の第１０の実施の形態では、既にＰＤＮコネクションを確立済みの状態で、さらに追加のＰＤＮコネクション確立を望むＭＴＣデバイス１００が、ネットワークから通知されるＭＴＣデバイス１００やＵＥ１０５に割り当て可能な通信リソースや帯域リソースの情報に基づいて、既に確立済みのＰＤＮコネクションをリリースし、追加のＰＤＮコネクションを確立する。
第１０の実施の形態で想定しているシナリオは、第９の実施の形態と同じである。第９の実施の形態との違いは、ＭＴＣデバイス１００が追加のＰＤＮコネクションを確立する際、確立済みのＰＤＮコネクション、又は、そのＰＤＮコネクションのＥＰＳベアラに割り当てられているＱｏＳ情報と、ネットワークから通知されるＭＴＣデバイス１００に割り当て可能なＱｏＳ情報（例えば、通信リソースや帯域リソース）を足し合わせたリソースが、新たに確立するＰＤＮコネクションに必要なリソースよりも大きい場合に、確立済みのＰＤＮコネクションをリリースすると判断する点である。以下、第９の実施の形態との違いを中心に詳しく説明する。
以下、本発明の第１０の実施の形態について、図３１、図３２、図３３Ａ〜図３３Ｅ、図３４〜図３６を用いて説明する。
ここで、本発明の第１０の実施の形態の説明を容易化するために、本発明の第１０の実施の形態におけるＭＴＣデバイス１００は、第９の実施の形態における前提と同様に、ネットワークと既にＰＤＮコネクションを１つ確立済みであり、確立済みのＰＤＮコネクション内のＥＰＳベアラに対して、ネットワークが保証するビットレート（ＧＢＲ：Guaranteed Bit Rate）は５Ｍｂｐｓとする。また、ＭＴＣデバイス１００は、追加のＰＤＮコネクションを確立するために、ＰＤＮコネクション確立リクエストを送信する。このとき、ＭＴＣデバイス１００は、既に確立済みのＰＤＮコネクションで送信されるデータの優先度より、追加で確立するＰＤＮコネクションで送信するデータの優先度レベルのほうが高いことを認識していることを前提としている。
“ＧＢＲ＝５Ｍｂｐｓ”が割り当てられたＥＰＳベアラを含むＰＤＮコネクションを確立済みであるＭＴＣデバイス１００が、追加のＰＤＮコネクションを確立する際、ネットワークから通知されるＱｏＳ情報に基づいて、確立済みのＰＤＮコネクションをリリースし、追加のＰＤＮコネクションを確立するＭＴＣデバイス１００の動作について、図３１を用いて説明する。
図３１において、“ＧＢＲ＝５Ｍｂｐｓ”が割り当てられたＥＰＳベアラを含むＰＤＮコネクションを確立済みであるＭＴＣデバイス１００が、追加のＰＤＮコネクションを確立しようとする状態を前提とする（ステップＳ２９００）。ＭＴＣデバイス１００は、追加のＰＤＮコネクションを確立するためにＰＤＮコネクション確立リクエストを送信する（ステップＳ２９０１：ＰＤＮコネクション確立リクエスト）。なお、図３１におけるステップＳ２９００及びＳ２９０１は、図２５におけるステップＳ２５００及びＳ２５０１と同じなので、ここでは詳細な説明を省略する。
続いて、混雑状態を検出したネットワークは、ＰＤＮコネクションの確立リクエストの送信元であるＭＴＣデバイス１００に割り当て可能なＱｏＳ情報（例えば、ＧＢＲ＜＝２Ｍｂｐｓなら許可など）を格納したＰＤＮコネクション確立拒絶レスポンスを送信する（ステップＳ２９０２：ＰＤＮコネクション確立拒絶レスポンス）。なお、ＧＢＲ以外のＱｏＳ情報として、図３２及び図３３Ａ〜図３３Ｅで示すように、ＱＣＩ（ＱｏＳ Ｃｌａｓｓ Ｉｎｄｉｃａｔｏｒ）、ＡＲＰ（Ａｌｌｏｃａｔｉｏｎ ａｎｄ Ｒｅｔｅｎｔｉｏｎ Ｐｒｉｏｒｉｔｙ）、ＭＢＲ（Ｍａｘｉｍｕｍ Ｂｉｔ Ｒａｔｅ）、Ｇｒｏｕｐ−ＡＭＢＲ（Ｇｒｏｕｐ−Ａｇｇｒｅｇａｔｅｄ Ｍａｘｉｍｕｍ Ｂｉｔ Ｒａｔｅ）、ＡＰＮ−ＡＭＢＲ（Ａｃｃｅｓｓ Ｐｏｉｎｔ Ｎａｍｅ−ＡＭＢＲ）、Ｔｒａｎｓｆｅｒ Ｄｅｌａｙ、Ｐａｃｋｅｔ Ｄｅｌａｙ Ｂｕｄｇｅｔ、Ｐａｃｋｅｔ Ｅｒｒｏｒ Ｌｏｓｓ Ｒａｔｅ、Ａｐｐｌｉｃａｔｉｏｎ ｐｒｉｏｒｉｔｙなどがある。
図３４は、３Ｇアクセスが、追加のＰＤＮコネクションに割り当て可能なＱｏＳ情報をＭＴＣデバイス１００に通知する際のメッセージのフォーマット例である。
図３４に図示されているメッセージは、従来のＰＤＮコネクション確立拒絶メッセージフィールドに加えて、ＭＴＣデバイス１００に割り当て可能なＱｏＳ情報を格納するＱｏＳ情報フィールド、ＱｏＳ情報フィールドに格納されている情報の有効時間（割り当て可能な時間）を示す有効期間フィールドで構成される。なお、有効期間フィールドは、本発明の第８の実施の形態で説明した待機時間と併用してもよい。
ネットワークからＭＴＣデバイス１００に割り当て可能なＱｏＳ情報を通知されたＭＴＣデバイス１００は、図３１で示すように、追加で確立するＰＤＮコネクションに必要なＱｏＳ情報が、既に確立済みのＰＤＮコネクションに割り当てられているＱｏＳ情報と、ステップＳ２９０２で通知されたＭＴＣデバイス１００に割り当て可能なＱｏＳ情報の合計以下であるか比較する（ステップＳ２９０３：ＱｏＳ比較）。
例えば、ＧＢＲで比較する場合には、図３３Ａで示すように、確立済みのＰＤＮコネクションのＥＰＳベアラに割り当てられているＧＢＲが１Ｍｂｐｓで、ネットワークからＰＤＮコネクション確立拒絶レスポンスで通知される追加ＰＤＮコネクションに割り当て可能なＧＢＲが０．５Ｍｂｐｓである場合は、ＭＴＣデバイス１００はＧＢＲが１．５Ｍｂｐｓ以下であれば、ＰＤＮコネクションを確立できる。すなわち、追加で確立するＰＤＮコネクションのＥＰＳベアラで必要とするＧＢＲが１．５Ｍｂｐｓ以下であれば、確立可能である。なお、このとき、確立済みのＰＤＮコネクションをリリースする必要があるときは、ＭＴＣデバイスが追加で確立するＰＤＮコネクションのＧＢＲが、「ネットワークから通知されるＧＢＲ＜追加で確立するＰＤＮコネクションのＧＢＲ＜ネットワークから通知されるＧＢＲと確立済みのＰＤＮコネクションのＥＰＳベアラに割り当てられているＧＢＲの合計」のときである。また、この具体例では、ネットワークからＭＴＣデバイス１００に通知される追加のＰＤＮコネクションに割り当て可能なＱｏＳ情報は、現在のＭＴＣデバイス１００に対して割り当て可能なＱｏＳ情報であるが、ＭＴＣデバイス１００が確立可能な絶対値を示すＱｏＳ情報を使用してもよい。例えば、ＧＢＲの場合、３Ｇアクセスから通知されるＭＴＣデバイス１００に割り当てられるＱｏＳ情報は、１．５Ｍｂｐｓ（確立済みＰＤＮコネクションのＥＰＳベアラに割り当てられているＧＢＲ（１Ｍｂｐｓ）＋追加のＰＤＮコネクションに割り当て可能なＧＢＲ（０．５Ｍｂｐｓ））として通知してもよい。
また、ＱＣＩで比較する場合には、図３３Ｂで示すように、ＭＴＣデバイス１００が追加で確立するＰＤＮコネクションのＱＣＩが、３Ｇアクセスから通知されるＭＴＣデバイス１００に割り当て可能なＱＣＩと一致している場合、ＭＴＣデバイス１００は追加のＰＤＮコネクションを確立できる。
また、詳しい説明は後述するが、ＱｏＳ情報に加えて、ＭＴＣデバイス１００が確立可能なＰＤＮコネクション数もＭＴＣデバイス１００に通知される場合（例えば、ＭＴＣデバイス１００は、一定時間（例えば、混雑時に通知される待機時間（Ｂａｃｋｏｆｆ ｔｉｍｅ））、合計１つのＰＤＮコネクションを確立可能）、ＭＴＣデバイス１００は確立済みのＰＤＮコネクションのＱＣＩを確認し、追加で確立するＰＤＮコネクションのＱＣＩと比較する。ＱＣＩが同じで、かつ、確立可能なＰＤＮコネクション数が１つである場合、ＭＴＣデバイス１００は、確立済みのＰＤＮコネクションをリリースすることで、追加のＰＤＮコネクションを確立できる。
なお、上記の説明例では、ＱｏＳ情報の比較処理を実施する際、ＧＢＲ、ＱＣＩを挙げているが、他のＱｏＳ情報に関する例も含めて、図３２にアクション、図３３Ａ〜図３３Ｅにアクション結果が図示されている。
また、ステップＳ２９０３のＱｏＳ比較を行う前に、本発明の第９の実施の形態で説明したように、追加のＰＤＮコネクション確立を拒絶されたＭＴＣデバイス１００は、追加のＰＤＮコネクションの優先度レベルと確立済みのＰＤＮコネクションの優先度レベルを比較した後に、ＱｏＳ比較を起こってもよい。なお、ＰＤＮコネクションの優先度レベルは、アプリケーションレイヤから取得できるアプリケーション毎に割り当てられる優先度レベルや、ＭＴＣデバイス１００が保持するポリシ、ＭＴＣデバイス１００がＭＴＣのためにスタティック（静的）に格納されている情報（例えば、最初に起動したアプリケーションを優先的に処理するなど）などを用いて取得してもよい。
続く、ステップＳ２９０３のＱｏＳ比較後、図３１のステップＳ２９０４からステップＳ２９０８は、図２５のステップＳ２５０５からステップＳ２５０９と同じなので、ここでは詳細な説明を省略する。
なお、上記の第１０の実施の形態では、ＭＴＣデバイス１００が追加のＰＤＮコネクションの確立リクエストに対するＰＤＮコネクション確立拒絶レスポンスで、ＭＴＣデバイス１００に割り当て可能なＱｏＳ情報を通知していたが、ネットワークはＭＴＣデバイス１００に割り当て可能なリソースが存在することから、ＰＤＮコネクション確立許可レスポンスで通知してもよい。その場合、ステップＳ２９０２のＰＤＮコネクション確立拒絶レスポンスは、ＰＤＮコネクション確立許可レスポンスに変わる。加えて、ステップＳ２９０３からステップＳ２９０６は省略でき、ステップＳ２９０７のＰＤＮコネクションＭｏｄｉｆｉｃａｔｉｏｎ ｐｒｏｃｅｄｕｒｅから実施可能となる。
なお、上記の第１０の実施の形態では、ネットワークからＭＴＣデバイス１００にＱｏＳ情報が通知されているが、ＱｏＳ情報に加えて、ＭＴＣデバイス１００の確立可能なＰＤＮコネクション数を通知してもよい。ＱｏＳ情報と確立可能なＰＤＮコネクション数を組み合わせることにより、ネットワークは割り当て可能なリソースを精度高く制御することができる。例えば、ネットワークが、ＰＤＮコネクションを１つ確立済みのＭＴＣデバイス１００から、追加のＰＤＮコネクションの確立リクエストを受信した場合、ネットワークがＭＴＣデバイス１００に対して、「ＭＴＣデバイス１００の確立可能なＰＤＮコネクション数は１つ」、かつ、「追加のＰＤＮコネクションに割り当て可能なＱｏＳ情報（ＧＢＲ）は、１Ｍｂｐｓ」のＱｏＳ情報をＰＤＮコネクション確立拒絶レスポンスに格納して送信する。このとき、ＭＴＣデバイス１００は「ＭＴＣデバイス１００の確立可能なＰＤＮコネクション数は１つ」という情報から、追加のＰＤＮコネクションを確立するためには、確立済みのＰＤＮコネクションをリリースする必要があることを確認できる。さらに、「追加のＰＤＮコネクションに割り当て可能なＱｏＳ情報（ＧＢＲ）は、１Ｍｂｐｓ」というＱｏＳ情報から、追加のＰＤＮコネクションで必要とされるＱｏＳ情報を満たせるか確認することができ、追加のＰＤＮコネクションで必要とされるＱｏＳ情報が、確立済みのＰＤＮコネクションに割り当てられているＱｏＳ情報以下である場合は、ＭＴＣデバイス１００は、確立済みのＰＤＮコネクションをリリースし、追加のＰＤＮコネクションを確立することができる。
以上、本発明の第１０の実施の形態によれば、既にＰＤＮコネクションを確立済みのＭＴＣデバイス１００が追加のＰＤＮコネクションを確立する際、ネットワークで混雑状態を検出している場合でも、ネットワークから通知されるＭＴＣデバイスに割り当て可能なＱｏＳ情報と、確立済みのＰＤＮコネクションに割り当てられているＱｏＳ情報と、追加で確立するＰＤＮコネクションに必要なＱｏＳ情報を比較し、追加で確立するＰＤＮコネクションに必要なＱｏＳ情報が、確立済みのＰＤＮコネクションに割り当てられているＱｏＳ情報を満たすことができる場合、ＭＴＣデバイス１００は確立済みＰＤＮコネクションをリリースし、追加のＰＤＮコネクションを確立することができる。これにより、ＭＴＣデバイスは優先度レベルが高いデータを送信することができ、ＭＴＣデバイス１００やＭＴＣサーバ１５０、ＭＴＣユーザ１６０などに優先度レベルが高いデータを送信できないなどの問題は解決される。
上記の本発明の第９の実施の形態と第１０の実施の形態では、ＭＴＣデバイス１００による確立済みのＰＤＮコネクションの接続先と、追加で確立するＰＤＮコネクションの接続先が同じであることを前提としている。
ここで、図３５ではＭＴＣデバイス１００が複数の接続先とＰＤＮコネクションを確立できる状態を示している。図３５におけるＭＴＣデバイスＡ１００Ａは、例えば、複数のＭＴＣサーバ１５０に接続することができ、１つ目のＰＤＮコネクション（確立済みのＰＤＮコネクション）の接続先はＭＴＣサーバＡ１５０Ａで、２つ目のＰＤＮコネクション（追加で確立するＰＤＮコネクション）の接続先はＭＴＣサーバＢ１５０Ｂになる場合がある。
ＭＴＣデバイスＡ１００Ａの接続先が異なる場合、本発明の第９の実施の形態と第１０の実施の形態におけるＰＤＮコネクションの確立拒絶レスポンスを受信した後の処理ステップとして、接続先を確認する処理が必要となる。
図３６は、図２５のステップＳ２５０２とステップＳ２５０３の間に接続先を確認する処理ステップを追加したものである。また、図３５におけるＭＴＣデバイスＡ１００Ａと図３６におけるＭＴＣデバイスＡ１００Ａは同一であるとする。
ＭＴＣサーバＡ１５０Ａにデータを送信するためのＰＤＮコネクションを確立済みのＭＴＣデバイスＡ１００Ａが、ＭＴＣサーバＢ１５０Ｂにデータを送信するためのＰＤＮコネクションを確立するためのＰＤＮコネクション確立リクエストをネットワーク送信する（ステップＳ２５０１）。ＭＴＣサーバＢにデータを送信するためのＰＤＮコネクション確立リクエストを受信したネットワークは、（Ａ）混雑発生によって、ＰＤＮコネクション確立拒絶レスポンスを送信する（ステップＳ２５０２）。
ここで、ＭＴＣデバイスＡ１００Ａは、確立済みのＰＤＮコネクションをリリースして、追加のＰＤＮコネクションを確立することができるかを判断するための処理として、確立済みのＰＤＮコネクションの接続先と、追加のＰＤＮコネクションの接続先が同じであるか否かを確認する（ステップＳ２５２０）。接続先を表す情報としては、ＡＰＮを用いることができる。つまり、ＡＰＮが同じであれば接続先が同じであると判断し、ＡＰＮが異なれば接続先が異なると判断する。
確立済みのＰＤＮコネクションの接続先と追加のＰＤＮコネクションの接続先が同じである場合は、引き続き、第９の実施の形態と同様の処理（図２５のステップＳ２５０３以降の処理）や第１０の実施の形態と同様の処理（図３１のステップＳ２９０３以降の処理）を行う。
しかしながら、確立済みのＰＤＮコネクションの接続先と追加のＰＤＮコネクションの接続先が異なる場合、例えば、追加のＰＤＮコネクション確立リクエストを受信したＭＴＣサーバＢ１５０Ｂでは混雑検出されているが、ＭＴＣデバイスＡ１００Ａによって既に確立済みのＰＤＮコネクションを通してデータを転送されているＭＴＣサーバＡ１５０Ａでは混雑検出されていない（混雑が起こっていない）場合には、確立済みのＰＤＮコネクションをリリースすることで確保されるリソースを、追加のＰＤＮコネクションの確立に再使用することができないと判断する。なお、追加のＰＤＮコネクション確立リクエストが拒絶されている理由は、ＭＴＣサーバＢ１５０Ｂにおける混雑検出以外に、ネットワーク（通信システム）のエンティティであるＳＧＷ−Ｂ１３０ＢやＰＧＷ−Ｂ１４０Ｂなどで起きている輻輳であってもよい。
ここで、ＭＴＣサーバＡ１５０Ａにおいて混雑状態が起きていない状態で、ＭＴＣデバイスＡ１００Ａによって送信された追加のＰＤＮコネクション確立リクエストが、ＭＴＣサーバＢ１５０Ｂの混雑状態により拒絶された場合、ＭＴＣデバイスＡ１００Ａは、ＭＴＣサーバＡ１５０Ａにデータを送信するためのＰＤＮコネクションをリリースしても、ＭＴＣサーバＢ１５０Ｂに送信するためのＰＤＮコネクションを確立できない。そのため、ＭＴＣデバイスＡ１００Ａは、確立済みのＰＤＮコネクションを維持し、追加のＰＤＮコネクションの確立をキャンセルする。
また、確立済みのＰＤＮコネクションの接続先と追加のＰＤＮコネクションの接続先が異なる状態でも、ＭＴＣデバイスＡ１００Ａが拒絶された追加のＰＤＮコネクションの接続先を変更できる場合（例えば、ＭＴＣサーバＡ１５０ＡとＭＴＣサーバ１５０Ｂが同じオペレータによる管轄、若しくは、ＭＴＣユーザ１６０に接続されている場合や、ＭＴＣサーバ１５０ＡとＭＴＣサーバＢ１５０Ｂ間でＰＤＮコネクション移行の契約が交わされており、交渉を自動的に実施するなど）、ＭＴＣデバイスＡ１００Ａは、追加で確立するＰＤＮコネクションの接続先を変更する。続いて、ＭＴＣデバイスＡ１００Ａは、確立済みのＰＤＮコネクションの接続先であるＭＴＣサーバＡ１５０ＡとのＰＤＮコネクションをリリースし、ＭＴＣサーバＡ１５０Ａにデータを転送するための追加のＰＤＮコネクションを確立する。なお、追加のＰＤＮコネクションの接続先を変更する処理と確立済みのＰＤＮコネクションの接続先であるＭＴＣサーバＡ１５０ＡとのＰＤＮコネクションをリリースする処理は順不同である。
なお、この接続先はＭＴＣサーバ１５０やＭＴＣユーザ１６０のアドレスやＩｄｅｎｔｉｔｙ（例えば、ＭＴＣサーバ ＴＥＩＤ）、ネットワーク（通信システム）の装置であるＰＧＷのアドレスやＩｄｅｎｔｉｔｙ（例えば、ＰＧＷ ＴＥＩＤ）、ＡＰＮなど接続先を識別できるものでもよい。
また、上記の実施の形態（特に第２〜第８の実施の形態）における逆イベント通知メッセージ（イベント情報）や送信制御メッセージには、イベント情報（例えば、デバイスＩＤやデバイス種ＩＤ）が格納されていたが、ｅＮＢ ＩＤやｅＮＢアドレス（並びに、ＭＴＣデバイス１００のＥＰＳベアラに対応するS1-U TEID）、イベント通知メッセージ（イベント情報）＠デバイスＡの送信元であるＭＴＣデバイスＡ１００Ａのアドレスや、ＭＴＣサービスで管理されている情報（例えば、ＭＴＣデバイスＡ１００Ａが位置する情報（例えば、３階、３０１号室、３丁目など））を追加することで、逆イベント通知メッセージ（イベント情報）を受信したＭＴＣデバイス１００がモード遷移する必要があるかどうかを判断させてもよい。
なお、本発明を説明する一例として、煙センサに通信モジュールを実装したＭＴＣデバイスＡ１００Ａが、煙を検知した後に起こりうる冗長のイベント通知メッセージに対する抑制方法について説明したが、以下のケースにも適用可能である。
例えば、ガス管の状態（例えば、破損していないか）を確認するガス管センサに通信モジュールを実装した複数のＭＴＣデバイスＡ１００Ａと主に居住スペースに配置されるガス漏れを検知するガスセンサに通信モジュールを実装した複数のＭＴＣデバイスＢ１００Ｂが、同じＭＴＣグループで構成されている環境において、ガス管が破損することにより、ＭＴＣデバイスＡ１００Ａによって通知されるイベント通知メッセージ（イベント情報）＠デバイスＡを利用して、ＭＴＣデバイスＢ１００Ｂのイベント通知メッセージを抑制してもよい。すなわち、ＭＴＣデバイスＡ１００Ａからイベント情報（例えば、ガス管センサＩＤ）が格納されたイベント通知メッセージ（イベント情報）＠デバイスＡを受け、ネットワーク装置（例えば、ＭＭＥ１２０やＭＴＣサーバ１５０）が、イベント情報（例えば、ガス管センサＩＤ）を格納した逆イベント通知メッセージをＭＴＣグループに属するＭＴＣデバイス１００に送信し、ＭＴＣデバイス１００がモード遷移する必要があるか（優先度の高いイベント通知メッセージを送信するか）判断させてもよい。このようなＭＴＣサービスに本発明を適用した場合、ガス管が破損することによって生じると予想されるガス管破損の誘発やガス漏れに対して、イベント（例えば、ガス管破損やガス漏れ）を検知した複数のＭＴＣデバイス１００による冗長な優先度の高いイベント通知メッセージを抑制することができ、ＭＴＣデバイス１００とネットワーク装置（例えば、ＭＭＥ１２０やＭＴＣサーバ１５０）の処理負荷を軽減、トラフィックを低減することができる。
また、例えば、エアバックと連動している衝撃センサを搭載済の乗用車に通信モジュールを実装したＭＴＣデバイス１００が、複数台の衝突事故（例えば、複数台による玉突き事故）を起こした場合、最初にネットワーク装置（例えば、ＭＭＥ１２０やＭＴＣサーバ１５０）に通知された優先度の高いイベント通知メッセージを利用して、後続する優先度の高いイベント通知メッセージを抑制してもよい。すなわち、ネットワーク装置（例えば、ＭＭＥ１２０やＭＴＣサーバ１５０）が、最初に受信したイベント通知メッセージのイベント情報（例えば、衝撃センサＩＤ）を格納した逆イベント通知メッセージを衝突事故が起きたエリア（例えば、イベント通知メッセージが送信されたｅＮＢ１１０配下）のＭＴＣデバイス１００にブロードキャストすることで、同一イベント、若しくは、そのイベントを引き起こした出来事によって引き起こされたイベントによる優先度の高いイベント通知メッセージを抑制することができる。このようなＭＴＣサービスに本発明を適用した場合、衝撃センサを搭載した複数台の乗用車の衝突事故が発生した際に高い確率で生じる冗長な優先度の高いイベント通知メッセージを抑制することができ、ＭＴＣデバイス１００とネットワーク装置（例えば、ＭＭＥ１２０やＭＴＣサーバ１５０）の処理負荷を軽減、トラフィックを低減することができる。
また、例えば、土砂崩れを監視する加速度センサや傾斜センサに通信モジュールを実装したＭＴＣデバイス１００が、土砂崩れが起こりそうなエリア（例えば、山や崖）に複数設置されている環境において、土砂崩れが起こることにより、ＭＴＣデバイス１００によって通知されるイベント通知メッセージを利用して、後続する優先度の高いイベント通知メッセージを抑制してもよい。すなわち、ＭＴＣデバイス１００からイベント情報（例えば、加速度センサＩＤ）が格納されたイベント通知メッセージ（イベント情報）を受け、ネットワーク装置（例えば、ＭＭＥ１２０やＭＴＣサーバ１５０）が、イベント情報（例えば、加速度センサＩＤ）を格納した逆イベント通知メッセージをＭＴＣグループに属するＭＴＣデバイス１００に送信し、ＭＴＣデバイス１００がモード遷移する必要があるか（優先度の高いイベント通知メッセージを送信するか）判断させてもよい。また、このような、あらかじめ単一の事象のみ監視するＭＴＣサービスであることが定義されている環境においては、イベント情報（例えば、加速度センサＩＤ）を含めなくても、何のイベントが発生したか明らかであるため、省略してもよい。
また、例えば、振動センサに通信モジュールを実装したＭＴＣデバイスによる陸橋の揺れ具合の監視から陸橋に異常がないか確認するＭＴＣサービスなども同様に、本発明は適用可能である。
なお、上記の本発明の各実施の形態では、ＭＴＣデバイス１００から通知されるイベント通知メッセージをトリガとして、ネットワーク装置（例えば、ＭＭＥ１２０やＳＧＷ１３０、ＰＧＷ１４０、ＭＴＣサーバ１５０）が冗長なイベント通知メッセージを抑制するための逆イベント通知メッセージをブロードキャストしていたが、イベント通知メッセージではなく、例えば、ＭＴＣデバイス１００とＭＴＣデバイス１００に組み込まれているＵＩＣＣ（Universal Integrated Circuit Card）の関連性の不一致を検知した場合や、ＭＴＣデバイス１００上で機能しているＭＴＣ ｆｅａｔｕｒｅとＨＳＳが保持するＭＴＣデバイス１００のサブスクリプションデータに登録されているＭＴＣ ｆｅａｔｕｒｅの整合が取れない場合や、設置場所が限定、若しくは、固定されているＭＴＣデバイス１００（例えば、自動販売機、煙センサ、炎センサ）、つまり、ＭＴＣデバイス１００の位置情報の変化が起こりにくい環境（通信環境の変化や、基地局の負荷バランスによってＭＴＣデバイス１００の接続する基地局切り替えは除く）で、ＭＴＣデバイス１００の位置情報の変化を検知した場合や、ＭＴＣデバイス１００とネットワークの間のＰＤＮコネクション、又は、ＥＰＳベアラが切断された場合などをトリガとして、逆イベント通知メッセージをブロードキャストしてもよい。
また、上記の本発明の各実施の形態では、ＭＴＣデバイス１００から送信されたイベント通知メッセージを受信したネットワーク装置（例えば、ＭＭＥ１２０、ＳＧＷ１３０、ＰＧＷ１４０、ＭＴＣサーバ１５０）は、イベント通知メッセージの内容を他のネットワーク装置に転送していたが（例えば、本発明の第２の実施の形態では、イベント通知メッセージを受信したＭＭＥ１２０が、ＳＧＷ１３０、ＰＧＷ１４０を経由してＭＴＣサーバ１５０にイベント通知メッセージを転送、若しくは、必要な情報のみを転送している）、オペレータの方針やＭＴＣアプリケーションの仕様などに基づいて、転送しなくてもよい。
また、上記の本発明の各実施の形態では、ＭＴＣデバイス１００がネットワークとの間にＰＤＮコネクションとＥＰＳベアラを確立した後にイベントを検知していたが、イベントを検知した後にＰＤＮコネクションとＥＰＳベアラを確立し、イベント情報やセンシング情報を送信してもよい。
また、上記の本発明の各実施の形態では、逆イベント通知メッセージを送信するネットワーク装置は、ＭＭＥ１２０やＰＧＷ１４０、ＭＴＣサーバ１５０を例として挙げて説明していたが、これらに限定されるわけではなく、ＳＧＷ１３０や外部のネットワークに位置する装置（例えば、ローミング先のネットワーク装置やＡＡＡサーバ、ＳＩＰサーバ）が送信してもよい。
また、上記の本発明の各実施の形態では、イベント通知メッセージを受信したネットワーク装置（例えば、ＭＭＥ１２０、ＳＧＷ１３０、ＰＧＷ１４０、ＭＴＣサーバ１５０）が逆イベント通知メッセージをブロードキャストしていたが、例えば、ネットワーク装置（例えば、ＭＭＥ１２０、ＳＧＷ１３０、ＰＧＷ１４０、ＭＴＣサーバ１５０）がＭＴＣデバイス１００の接続先である基地局（ｅＮＢ１１０）に逆イベント通知メッセージをブロードキャストするように指示し、ｅＮＢ１１０が逆イベント通知メッセージをブロードキャストしてもよい。例えば、現在規定されているようにｅＮＢがページングをブロードキャストし、ＵＥ１０５にＥＴＷＳの情報を取得させる手段を利用、拡張することで、既存システムに大きな影響を与えることなく、本発明を実施することができる。
また、上記の本発明の各実施の形態では、イベント通知メッセージを受信したネットワーク装置（例えば、ＭＭＥ１２０、ＳＧＷ１３０、ＰＧＷ１４０、ＭＴＣサーバ１５０）は、逆イベント通知メッセージをブロードキャストして、冗長なイベント通知メッセージを抑制していたが、他の役割を持たせたメッセージをブロードキャストしてもよい。例えば、特定のエリアに複数の自動販売機（ＭＴＣデバイス１００）が設置されている環境で、例えば、窃盗によって１つの自動販売機の位置情報が変化したことをネットワーク側が検知した場合、ネットワーク装置は自動販売機の位置情報変化をトリガとして、上記特定のエリアの複数の自動販売機に対して、各自動販売機の位置情報を送信すること（Tracking Area Update）を指示したメッセージをブロードキャストしてもよい。これにより、他の自動販売機の状況を定期的に実施される位置情報の更新時より迅速、かつ、確実に確認することができる。
また、上記の本発明の各実施の形態では、イベント通知メッセージを受信したネットワーク装置（例えば、ＭＭＥ１２０、ＳＧＷ１３０、ＰＧＷ１４０、ＭＴＣサーバ１５０）は、逆イベント通知メッセージをブロードキャストしていたが、逆イベント通知メッセージを送信するＭＴＣデバイス１００を把握している場合には、マルチキャストやユニキャストで実施してもよい。
なお、上記の本発明の各実施の形態の説明で用いた各機能ブロックは、典型的には集積回路であるＬＳＩ（Large Scale Integration）として実現される。これらは個別に１チップ化されてもよいし、一部又はすべてを含むように１チップ化されてもよい。なお、ここでは、ＬＳＩとしたが、集積度の違いにより、ＩＣ（Integrated Circuit）、システムＬＳＩ、スーパーＬＳＩ、ウルトラＬＳＩと呼称されることもある。
また、集積回路化の手法はＬＳＩに限るものではなく、専用回路又は汎用プロセッサで実現してもよい。ＬＳＩ製造後に、プログラムすることが可能なＦＰＧＡ（Field Programmable Gate Array）や、ＬＳＩ内部の回路セルの接続や設定を再構成可能なリコンフィギュラブル・プロセッサを利用してもよい。
さらには、半導体技術の進歩又は派生する別技術によりＬＳＩに置き換わる集積回路化の技術が登場すれば、当然、その技術を用いて機能ブロックの集積化を行ってもよい。例えば、バイオ技術の適応などが可能性としてあり得る。
本発明は、通信ノード（ＭＴＣデバイス１００）がイベント検知の情報を、高い優先度のメッセージを用いてネットワーク側のサーバ（ＭＴＣサーバ１５０）へ送信する環境において、周辺の他の通信ノードが同一の出来事、若しくは、その出来事によって引き起こされたイベントを検知した際に、高優先度モードでイベント通知メッセージを送信しないよう抑制し、ＭＴＣサーバ及び通信システムのエンティティ（ｅＮＢ、ＭＭＥ、ＳＧＷ、ＰＧＷなど）の処理負荷やネットワークにおけるトラフィック量を低減させるという効果を有する。また、ネットワーク側で混雑状況が検知された場合に、ＭＴＣサーバ及び通信システムのエンティティ（ｅＮＢ、ＭＭＥ、ＳＧＷ、ＰＧＷなど）の処理負荷やネットワークにおけるトラフィック量を低減させるという効果を有する。特に、複数の通信ノード（ＭＴＣデバイス１００）がグループ化（ＭＴＣグループ化）されている環境において、有効である。このように、本発明は、緊急性の高いイベント通知メッセージを高優先度モードで送信することが可能な通信技術やネットワークにおける混雑状況を緩和する通信技術に適用可能であり、特に、一機能としてＰＡＭの送信機能や時間制御機能（耐時間性機能）が定義されているＭＴＣの技術に適用可能である。
Claims (24)
- ネットワーク側のエンティティが他の通信ノードからの通知に応じて送信する制御メッセージ、又は、前記他の通信ノードとの間の通信状況に応じて送信する制御メッセージであって、特定の条件に当てはまる通信ノードの通信モードを変更するよう指示する前記制御メッセージをネットワーク側から受信し、受信した前記制御メッセージに含まれている前記特定の条件を参照して、前記特定の条件に当てはまる場合には、前記通信モードを変更するよう制御する通信制御部を有する通信ノード。
- 前記通信制御部が、
特定のイベントの発生を検知するためのセンサによって検知されたセンシングデータを通常の優先度で送信するノーマルモード、又は、前記センサによって前記特定のイベントの発生を検知したことを通知するイベント通知メッセージを前記ノーマルモードの優先度よりも高い優先度で送信する高優先度モードのいずれかの送信モードで動作を行うよう制御する動作モード制御部と、
ネットワークノードへ、前記高優先度モードによる前記イベント通知メッセージの送信又は前記ノーマルモードによる前記センシングデータの送信を行う送信部と、
特定のイベントの発生を検知したことを通知するイベント通知メッセージを任意の通信ノードから受信した前記ネットワークノードから、前記任意の通信ノードからのイベント通知メッセージに対する応答として送信されるメッセージであって、送信モードを前記ノーマルモードへ遷移するか又は前記ノーマルモードのまま維持するよう指示する前記メッセージを受信するメッセージ受信部と、
前記メッセージを受信した場合に、前記送信モードを前記ノーマルモードへ遷移するか又は前記ノーマルモードのまま維持するかどうかを判断するモード遷移判断部とを、
有し、
前記送信モードを前記ノーマルモードへ遷移するか又は前記ノーマルモードのまま維持すると前記モード遷移判断部が判断した場合には、前記動作モード制御部が、前記送信モードを前記ノーマルモードへ遷移するか又は前記ノーマルモードのまま維持するよう構成されている請求項１に記載の通信ノード。 - 前記モード遷移判断部が、自通信ノードの種類を示す種別情報が前記メッセージに含まれているかどうかを確認し、自通信ノードの種類を示す種別情報が前記メッセージに含まれている場合には、前記送信モードを前記ノーマルモードへ遷移するか又は前記ノーマルモードのまま維持すると判断するよう構成されている請求項２に記載の通信ノード。
- 前記モード遷移判断部が、自通信ノードの種類を示す種別情報が前記メッセージに含まれているかどうかを確認し、自通信ノードの種類を示す種別情報が前記メッセージに含まれていない場合は、さらに、自通信ノードの種類と関連付けられているラベル情報が前記メッセージに含まれているかどうかを確認し、自通信ノードの種類と関連付けられているラベル情報が前記メッセージに含まれている場合には、前記送信モードを前記高優先度モードへ遷移するか又は前記高優先度モードのまま維持すると判断するよう構成されている請求項３に記載の通信ノード。
- 前記通信制御部が、自通信ノードの種類と前記メッセージに含まれているラベル情報とが関連付けられているかどうかを示すイベントグループ情報を保持するイベントグループ情報保持部を有し、
前記モード遷移判断部が、前記イベントグループ情報に基づいて、自通信ノードの種類と関連付けられているラベル情報が前記メッセージに含まれているかどうかを確認するよう構成されている請求項４に記載の通信ノード。 - 前記送信モードを前記高優先度モードへ遷移するか又は前記高優先度モードのまま維持する対象の種別情報が前記イベントグループ情報に登録されており、
前記モード遷移判断部が、前記メッセージに含まれているラベル情報に対応するイベントグループ情報に、前記メッセージに含まれている種別情報が登録されているかどうかを確認することで、自通信ノードの種類と関連付けられているラベル情報が前記メッセージに含まれているかどうかを確認するよう構成されている請求項５に記載の通信ノード。 - 自通信ノードの種類を示す種別情報が前記メッセージに含まれており、前記送信モードを前記ノーマルモードへ遷移するか又は前記ノーマルモードのまま維持すると判断した後は、前記送信モードを前記高優先度モードへ遷移するよう指示する別のメッセージを受信した場合であっても、前記送信モードを前記ノーマルモードのまま維持するよう構成されている請求項２に記載の通信ノード。
- 前記通信制御部が、
ネットワークにおいて混雑状態が検知された場合にネットワークノードから送信されるメッセージであって、マシンタイプ通信において規定されている耐時間性機能を有している通信ノードは前記ネットワークへの接続を抑制するよう指示する情報を含む前記メッセージを受信するメッセージ受信部と、
前記メッセージを受信した場合、自通信ノードが前記耐時間性機能を有しているか否かを判断する機能判断部と、
前記耐時間性機能を有していると判断された場合、前記ネットワークとの間で確立されている接続を切断する、若しくは、前記ネットワークとの間で確立されている接続は維持したままデータ送信を制御するか、又は、前記ネットワークとの間で接続が確立されていない場合には前記ネットワークへの接続要求を行わないように制御する接続制御部とを、
有する請求項１に記載の通信ノード。 - 前記通信制御部が、前記メッセージに特定の付加条件が設定されており、自通信ノードが前記付加条件に当てはまるかどうかを判断する付加条件判断部を更に有し、
前記接続制御部が、前記付加条件判断部における判断結果に更に基づいて、前記ネットワークとの間で確立されている接続を切断する、若しくは、前記ネットワークとの間で確立されている接続は維持したままデータ送信を制御するか、又は、前記ネットワークとの間で接続が確立されていない場合には前記ネットワークへの接続要求を行わないように制御するよう構成されている請求項８に記載の通信ノード。 - ネットワーク側のエンティティが他の通信ノードからの通知に応じて送信する制御メッセージ、又は、前記他の通信ノードとの間の通信状況に応じて送信する制御メッセージに、特定の条件に当てはまる通信ノードの通信モードを変更するよう指示する情報を含ませ、前記特定の条件に当てはまる通信ノードの通信モードを変更させるよう制御する通信制御部を有するネットワークノード。
- 特定のイベントの発生を検知するためのセンサによって検知されたセンシングデータを通常の優先度で送信するノーマルモード、又は、前記センサによって前記特定のイベントの発生を検知したことを通知するイベント通知メッセージを前記ノーマルモードの優先度よりも高い優先度で送信する高優先度モードのいずれかの送信モードで動作を行う前記複数の通信ノードと接続されている前記ネットワークノードであって、
前記通信制御部が、
前記複数の通信ノードのいずれか１つから、特定のイベントの発生を検知したことを通知する前記イベント通知メッセージを受信する受信部と、
前記イベント通知メッセージに対する応答として、送信モードを前記ノーマルモードへ遷移するか又は前記ノーマルモードのまま維持するよう指示するメッセージを作成するメッセージ作成部と、
前記メッセージを前記複数の通信ノードへ送信するメッセージ送信部とを、
有する請求項１０に記載のネットワークノード。 - 前記イベント通知メッセージを送信した通信ノードの種類と同じ種類の通信ノードの送信モードを前記ノーマルモードへ遷移させるか又は前記ノーマルモードのまま維持させるため、前記メッセージ作成部が、前記イベント通知メッセージを送信した通信ノードの種類を示す種別情報を前記メッセージに挿入するよう構成されている請求項１１に記載のネットワークノード。
- 前記複数の通信ノードのうちの特定の種類の通信ノードの送信モードを前記高優先度モードへ遷移させるか又は前記高優先度モードのまま維持させるため、前記メッセージ作成部が、前記複数の通信ノードのうちの特定の種類の通信ノードと関連付けられているラベル情報を前記メッセージに挿入するよう構成されている請求項１２に記載のネットワークノード。
- 通信ノードの種類とラベル情報との関連付けを示すイベントグループ情報を保持するイベントグループ情報保持部を有し、
前記メッセージ作成部が、前記イベントグループ情報に基づいて、前記メッセージに挿入するラベル情報を選択するよう構成されている請求項１３に記載のネットワークノード。 - 前記通信制御部が、
混雑状態が検知された場合に、マシンタイプ通信において規定されている時間制御機能を有している通信ノードは前記ネットワークへの接続を抑制するよう指示する情報を前記メッセージに含ませるメッセージ作成部を有する請求項１０に記載のネットワークノード。 - ネットワーク内のエンティティとの間に第１の接続を確立している通信ノードが、第２の接続を確立するための接続確立方法であって、
前記第２の接続を確立するための接続確立要求メッセージが拒絶された場合に、前記第１の接続の優先度と、前記第２の接続の優先度を比較するステップと、
前記第２の接続の優先度が前記第１の接続の優先度より高い場合に、前記第１の接続に割り当てられている第１のＱｏＳ情報と、前記第２の接続に必要となる第２のＱｏＳ情報を比較し、前記第１のＱｏＳ情報を前記第２のＱｏＳ情報に再使用できるか判断するステップと、
前記第１のＱｏＳ情報を前記第２のＱｏＳ情報に再使用できると判断する場合に、前記第２の接続を確立するために前記第１の接続を修正するステップと、
を有する接続確立方法。 - 前記第１の接続の接続先と、前記第２の接続の接続先が同じであるか確認するステップを更に有する請求項１６に記載の接続確立方法。
- 前記第２の接続を確立するために前記第１の接続を修正する前記ステップは、前記第１の接続をリリースした後、前記第２の接続を確立するための前記接続確立要求メッセージを送信する請求項１６に記載の接続確立方法。
- 前記優先度は、前記通信ノードが保持する情報から取得する請求項１６に記載の接続確立方法。
- 前記優先度は、前記通信ノードが利用するアプリケーションから取得する請求項１６に記載の接続確立方法。
- 前記第２のＱｏＳ情報は、前記通信ノードが保持する情報から取得する請求項１６に記載の接続確立方法。
- 前記第２のＱｏＳ情報は、前記通信ノードが利用するアプリケーションから取得する請求項１６に記載の接続確立方法。
- 前記第２のＱｏＳ情報は、前記通信ノード以外の通信ノードから取得する請求項１６に記載の接続確立方法。
- ネットワーク内のエンティティとの間に接続を確立する通信ノードであって、
前記エンティティとの間に前記接続を確立するための接続確立要求メッセージを送信する送信部と、
前記通信ノードが、前記エンティティとの間に確立された第１の接続を保持している際、前記送信部が送信した前記第２の接続を確立するための前記接続確立要求メッセージが拒絶された場合に、前記第１の接続の優先度と、前記第２の接続の優先度を比較する比較部と、
前記第２の接続の優先度が前記第１の接続の優先度より高い場合に、前記第１の接続に割り当てられている第１のＱｏＳ情報と、前記第２の接続に必要となる第２のＱｏＳ情報を比較し、前記第１のＱｏＳ情報を前記第２のＱｏＳ情報に再使用できるか判断する判断部と、
前記第１のＱｏＳ情報を前記第２のＱｏＳ情報に再使用できると判断する場合に、前記第２の接続を確立するために前記第１の接続を修正する修正部とを、
を有する通信ノード。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2012510567A JP5755639B2 (ja) | 2010-04-14 | 2011-04-12 | 接続確立方法及び通信ノード |
Applications Claiming Priority (8)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2010093564 | 2010-04-14 | ||
| JP2010093564 | 2010-04-14 | ||
| JP2010136462 | 2010-06-15 | ||
| JP2010136462 | 2010-06-15 | ||
| JP2010178953 | 2010-08-09 | ||
| JP2010178953 | 2010-08-09 | ||
| JP2012510567A JP5755639B2 (ja) | 2010-04-14 | 2011-04-12 | 接続確立方法及び通信ノード |
| PCT/JP2011/002154 WO2011129098A1 (ja) | 2010-04-14 | 2011-04-12 | 通信ノード及びネットワークノード |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JPWO2011129098A1 true JPWO2011129098A1 (ja) | 2013-07-11 |
| JP5755639B2 JP5755639B2 (ja) | 2015-07-29 |
Family
ID=44798481
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2012510567A Expired - Fee Related JP5755639B2 (ja) | 2010-04-14 | 2011-04-12 | 接続確立方法及び通信ノード |
Country Status (3)
| Country | Link |
|---|---|
| US (1) | US20130042011A1 (ja) |
| JP (1) | JP5755639B2 (ja) |
| WO (1) | WO2011129098A1 (ja) |
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US9621470B2 (en) * | 2013-07-25 | 2017-04-11 | Convida Wireless, Llc | Service layer southbound interface and quality of service |
Families Citing this family (64)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US8949434B2 (en) * | 2007-12-17 | 2015-02-03 | Microsoft Corporation | Automatically provisioning a WWAN device |
| GB201114079D0 (en) | 2011-06-13 | 2011-09-28 | Neul Ltd | Mobile base station |
| EP3493565B1 (en) * | 2011-07-04 | 2020-11-18 | Koninklijke KPN N.V. | Triggering with time indicator |
| CN102869122B (zh) | 2011-07-05 | 2018-08-28 | 北京三星通信技术研究有限公司 | 避免切换失败的方法 |
| JP5883272B2 (ja) * | 2011-07-08 | 2016-03-09 | 株式会社Ｎｔｔドコモ | 移動通信方法、移動通信システム及び無線基地局 |
| WO2013027298A1 (ja) * | 2011-08-25 | 2013-02-28 | 富士通株式会社 | 通信確立方法、コンピュータシステム、及びコンピュータ |
| CN103024719B (zh) * | 2011-09-23 | 2018-05-11 | 中兴通讯股份有限公司 | 终端组的移动性管理实体选择方法及系统 |
| US9967362B2 (en) * | 2011-10-27 | 2018-05-08 | Telefonaktiebolaget Lm Ericsson (Publ) | Caching in wireless communication networks |
| US9497102B2 (en) | 2011-12-06 | 2016-11-15 | Qualcomm Incorporated | Systems and methods for machine to machine device control and triggering |
| US9743447B2 (en) * | 2012-01-18 | 2017-08-22 | Lg Electronics Inc. | Control method and device based on multiple priorities in wireless communication system |
| JP2013150213A (ja) * | 2012-01-20 | 2013-08-01 | Sharp Corp | 通信システム、ゲートウェイ装置及び通信方法 |
| US20130201870A1 (en) * | 2012-02-06 | 2013-08-08 | Vivek Gupta | Handling dual priority applications in a wireless communication network |
| US9912597B2 (en) * | 2012-03-08 | 2018-03-06 | Samsung Electronics Co., Ltd. | Method and apparatus for controlling traffic of radio access network in a wireless communication system |
| US9113283B2 (en) | 2012-04-03 | 2015-08-18 | Telefonaktiebolaget L M Ericsson (Publ) | Systems and methods for event notification framework in a machine-to-machine (M2M) context |
| EP2843992B1 (en) * | 2012-04-26 | 2017-11-22 | NEC Corporation | Wireless communication device, network node, user node, core network, and method mounted thereto |
| WO2013164363A1 (en) * | 2012-04-30 | 2013-11-07 | Nokia Siemens Networks Oy | Method to initiate priority alarm in a cellular network |
| US9015395B2 (en) * | 2012-05-10 | 2015-04-21 | Alcatel Lucent | Methods and apparatuses for multiple priority access in a wireless network system |
| US9749856B2 (en) * | 2012-06-20 | 2017-08-29 | Nokia Solutions And Networks Oy | Device to machine communications |
| CN103684824B (zh) * | 2012-09-13 | 2017-09-12 | 华为终端有限公司 | 一种事件上报的方法及系统 |
| US8923880B2 (en) | 2012-09-28 | 2014-12-30 | Intel Corporation | Selective joinder of user equipment with wireless cell |
| CN103312532B (zh) * | 2012-10-17 | 2016-03-02 | 中兴通讯股份有限公司 | 用于物联网网关的故障自动排除方法及系统 |
| CN104756593B (zh) * | 2012-10-29 | 2018-10-12 | Lg 电子株式会社 | 在无线通信系统中释放连接的方法和装置 |
| KR101538424B1 (ko) * | 2012-10-30 | 2015-07-22 | 주식회사 케이티 | 결제 및 원격 모니터링을 위한 사용자 단말 |
| CN104769857B (zh) * | 2012-11-01 | 2018-05-22 | Lg 电子株式会社 | 在无线通信系统中支持设备特性的调度组的方法和装置 |
| WO2014075293A1 (en) * | 2012-11-16 | 2014-05-22 | Nokia Corporation | Transmission of motion data |
| KR101710666B1 (ko) * | 2012-12-12 | 2017-02-27 | 한국전자통신연구원 | 무선 네트워크 기반 복합 사면 감시 장치 및 방법 |
| US9432797B2 (en) * | 2013-01-14 | 2016-08-30 | Qualcomm Incorporated | Broadcast and system information for machine type communication |
| GB2512879A (en) * | 2013-04-09 | 2014-10-15 | Mobbra Ltd | Improvements in or relating to communicating with electronics devices |
| EP3557894B1 (en) | 2013-05-06 | 2023-12-27 | Convida Wireless, LLC | Device triggering |
| US9325835B2 (en) * | 2013-06-03 | 2016-04-26 | Qualcomm Incorporated | Methods and apparatus for improving device functionality during long blocking UICC operations |
| US20140376426A1 (en) * | 2013-06-20 | 2014-12-25 | Gary David Boudreau | Machine type communication aggregator apparatus and method |
| US9264364B2 (en) * | 2013-07-25 | 2016-02-16 | Verizon Patent And Licensing Inc. | Transmitting data via a private sub-network of a service provider network |
| US11570161B2 (en) * | 2013-07-31 | 2023-01-31 | Nec Corporation | Devices and method for MTC group key management |
| US9853709B2 (en) * | 2013-08-18 | 2017-12-26 | Lg Electronics Inc. | Repeater operation method and apparatus in wireless communication system |
| WO2015025444A1 (ja) * | 2013-08-22 | 2015-02-26 | 日本電気株式会社 | Ｍｔｃ－ｉｗｆエンティティ、ｓｃｓエンティティ、ｐｃｒｆエンティティ、及び通信方法 |
| US9967694B2 (en) | 2013-10-25 | 2018-05-08 | At&T Intellectual Property I, L.P. | Integrated LTE radio access enode B with sensor array controller system |
| WO2015072023A1 (ja) * | 2013-11-15 | 2015-05-21 | 富士通株式会社 | システム、通信ノード、および切り替え方法 |
| US9655147B2 (en) | 2013-12-18 | 2017-05-16 | Motorola Solutions, Inc. | Method and apparatus for bearer control in a group call |
| US20150172882A1 (en) * | 2013-12-18 | 2015-06-18 | Alcatel-Lucent Usa Inc. | Method For Correlation Of Requesting Information From A Remote Device |
| WO2015100638A1 (zh) * | 2013-12-31 | 2015-07-09 | 华为技术有限公司 | 一种业务处理的方法和设备 |
| JP6476477B2 (ja) * | 2014-05-23 | 2019-03-06 | 富士通コネクテッドテクノロジーズ株式会社 | Ｍｔｃイベント検出及びシグナリング |
| US11159980B2 (en) * | 2014-07-22 | 2021-10-26 | Parallel Wireless, Inc. | Signaling storm reduction from radio networks |
| EP2981134B1 (en) * | 2014-07-30 | 2017-06-21 | Panasonic Intellectual Property Corporation of America | Cell selection and reselection in normal and enhanced coverage mode |
| US9749902B2 (en) * | 2014-08-19 | 2017-08-29 | Qualcomm Incorporated | Admission control and load balancing |
| US9928183B2 (en) * | 2014-09-26 | 2018-03-27 | Ampere Computing Llc | Priority framework for a computing device |
| WO2016070435A1 (zh) * | 2014-11-07 | 2016-05-12 | 华为技术有限公司 | 一种获取用户设备ue信息的方法和装置 |
| US9779271B2 (en) * | 2015-06-08 | 2017-10-03 | Juniper Networks, Inc. | Apparatus, system, and method for detecting theft of network devices |
| US9954778B2 (en) * | 2015-09-15 | 2018-04-24 | At&T Mobility Ii Llc | Gateways for sensor data packets in cellular networks |
| EP3351028A1 (en) * | 2015-09-18 | 2018-07-25 | Telefonaktiebolaget LM Ericsson (PUBL) | Network nodes and methods therein for enabling events triggered by a wireless device to be reported in a wireless communications network |
| US20170091889A1 (en) * | 2015-09-25 | 2017-03-30 | Detong Chen | Flexible destination setting and route indication system |
| WO2017103321A1 (en) * | 2015-12-18 | 2017-06-22 | Nokia Technologies Oy | Network management |
| US10321471B2 (en) * | 2016-01-07 | 2019-06-11 | Telefonaktiebolaget Lm Ericsson (Publ) | Conveying use of exception reporting to core network nodes |
| US10334435B2 (en) | 2016-04-27 | 2019-06-25 | Qualcomm Incorporated | Enhanced non-access stratum security |
| US9992654B2 (en) | 2016-04-29 | 2018-06-05 | At&T Intellectual Property I, L.P. | Policy driven emergency traffic handling for machine-to-machine device communication |
| US11336505B2 (en) * | 2016-06-10 | 2022-05-17 | Vmware, Inc. | Persistent alert notes |
| JP6691473B2 (ja) * | 2016-12-19 | 2020-04-28 | 株式会社日立製作所 | イベントフローシステムおよびイベントフロー制御方法 |
| US11153843B2 (en) | 2017-02-16 | 2021-10-19 | Telefonaktiebolaget Lm Ericsson (Publ) | Mechanisms for locating wireless devices |
| WO2018201451A1 (zh) * | 2017-05-05 | 2018-11-08 | 华为技术有限公司 | 一种设备接入方法、用户设备及网络设备 |
| US10764143B2 (en) * | 2018-02-26 | 2020-09-01 | Verizon Patent And Licensing Inc. | System and method for enforcing group policies for MTC devices to perform background data transfers |
| EP3782433B1 (en) * | 2018-04-16 | 2024-01-17 | Telefonaktiebolaget LM Ericsson (publ) | Methods and apparatuses for handling of reject wait time |
| US20210266765A1 (en) * | 2018-06-29 | 2021-08-26 | Lenovo (Beijing) Limited | Method and apparatus for ran event report transmission and network optimization based on analytics of ran event reports |
| EP3629618A1 (en) | 2018-09-28 | 2020-04-01 | Giesecke+Devrient Mobile Security GmbH | High-volume low-impact quality of service management for internet of things |
| SE2050148A1 (en) * | 2019-02-12 | 2020-08-13 | Reliance Jio Infocomm Ltd | Method and system for sensor data type identification NR. CENTER POINT, PANCHWATI 5 RASTA, AMBAWADI, 380006 9 |
| CN115942376B (zh) * | 2023-03-09 | 2023-06-09 | 中法渤海地质服务有限公司 | 一种井场信息远程传输方法和传输系统 |
Family Cites Families (10)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2955287B1 (ja) * | 1998-10-01 | 1999-10-04 | 株式会社エイ・ティ・アール環境適応通信研究所 | 通信サービス品質制御方法及び装置 |
| JP2003037630A (ja) * | 2001-07-23 | 2003-02-07 | Matsushita Electric Ind Co Ltd | ディジタルコンテンツの伝送におけるサービス品質を測定するための方法及び装置、並びにサービス品質を制御するための方法及び装置 |
| US7404205B2 (en) * | 2003-06-03 | 2008-07-22 | Hewlett-Packard Development Company, L.P. | System for controlling client-server connection requests |
| WO2006118398A1 (en) * | 2005-04-29 | 2006-11-09 | Lg Electronics Inc. | Method for changing service quality of a content adaptively |
| JP4507990B2 (ja) * | 2005-06-08 | 2010-07-21 | パナソニック電工株式会社 | 火災報知システム |
| JP4800162B2 (ja) * | 2006-09-28 | 2011-10-26 | 京セラ株式会社 | 無線通信装置およびその制御方法 |
| JP4577670B2 (ja) * | 2008-03-13 | 2010-11-10 | Ｎｅｃアクセステクニカ株式会社 | 通信装置およびデータ送信制御方法 |
| JP5079090B2 (ja) * | 2008-06-04 | 2012-11-21 | 三菱電機株式会社 | 車々間通信システムおよび通信端末 |
| WO2009157171A1 (ja) * | 2008-06-24 | 2009-12-30 | パナソニック株式会社 | ハンドオーバ処理方法、その方法で用いられる移動端末及び接続管理装置 |
| US8787159B2 (en) * | 2011-04-14 | 2014-07-22 | Alcatel Lucent | Mechanism for wireless access networks to throttle traffic during congestion |
-
2011
- 2011-04-12 JP JP2012510567A patent/JP5755639B2/ja not_active Expired - Fee Related
- 2011-04-12 US US13/641,072 patent/US20130042011A1/en not_active Abandoned
- 2011-04-12 WO PCT/JP2011/002154 patent/WO2011129098A1/ja active Application Filing
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US9621470B2 (en) * | 2013-07-25 | 2017-04-11 | Convida Wireless, Llc | Service layer southbound interface and quality of service |
Also Published As
| Publication number | Publication date |
|---|---|
| WO2011129098A1 (ja) | 2011-10-20 |
| US20130042011A1 (en) | 2013-02-14 |
| JP5755639B2 (ja) | 2015-07-29 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP5755639B2 (ja) | 接続確立方法及び通信ノード | |
| US9042886B2 (en) | Method of and a support node for requesting registration of stationary user equipment in a cellular telecommunication system | |
| US10687175B2 (en) | Method for transmitting and receiving V2X message in wireless communication system, and an apparatus for same | |
| CN106302622B (zh) | 车联网系统及其中的业务实现方法和装置 | |
| JP5514908B2 (ja) | ステータス依存型移動体サービス用通信システム及び装置 | |
| US20180302784A1 (en) | Machine type communication system | |
| US8811984B2 (en) | Area-based access control method for terminals which carry out M2M communications in a wireless communication system | |
| EP2571297B1 (en) | Location-based machine-to-machine communication method, system and device | |
| US9271165B2 (en) | Method for establishing connection by HNB | |
| US8787909B2 (en) | Server for control plane at mobile communication network and method for controlling local IP access service | |
| ES2954433T3 (es) | Manejo de radioseñalización de RAN | |
| WO2012051890A1 (zh) | 终端接入限制的方法及系统 | |
| JP2015510371A (ja) | 非アクセス層（ｎａｓ）信号を使用するネットワークでのマシン・タイプ通信（ｍｔｃ） | |
| JP2022511597A (ja) | ネットワークサービス制御方法及び通信機器 | |
| EP2408236A1 (en) | Wireless communication system, base station apparatus, wireless communication terminal, gateway apparatus and communication method | |
| US20210237870A1 (en) | Unmanned aerial vehicle supervision method and device | |
| US20170367031A1 (en) | Base station device, terminal device, and communication control method | |
| CN101489214A (zh) | 一种检测用户端设备的方法、装置及系统 | |
| US20150024795A1 (en) | Femtocell base station, a user terminal, a method of sending femtocell base station status information to a user terminal, and a method of receiving | |
| JP5262662B2 (ja) | コアネットワーク装置、無線ネットワーク制御装置、位置登録方法、及び無線ネットワークシステム | |
| CN102761980A (zh) | 一种实现业务处理的方法和系统 | |
| CN116097676A (zh) | 将能力信息中继到网络节点的技术 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20131125 |
|
| A711 | Notification of change in applicant |
Free format text: JAPANESE INTERMEDIATE CODE: A711 Effective date: 20140610 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20140630 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20150106 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20150406 |
|
| TRDD | Decision of grant or rejection written | ||
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20150428 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20150527 |
|
| R150 | Certificate of patent or registration of utility model |
Ref document number: 5755639 Country of ref document: JP Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| LAPS | Cancellation because of no payment of annual fees |