(57)【要約】【課題】マニフェストに従って動作をしていない端末に所定の制御をさせる。【解決手段】通信システムにおける通信管理方法であって、前記通信システムは、情報の送信元である複数の端末から通信路を介して情報を受信する集約部と、前記端末から送信されたデータを処理する処理部と、前記端末が信号を送信するタイミングをスケジューリングする予約部とを有し、前記通信管理方法は、前記処理部が、前記予約部が決定したタイミングから定められる処理時間帯において、前記端末が送信した情報を監視し、前記処理部が、前記監視された情報から、前記端末の状態を推定し、前記処理部が、前記推定された端末の状態と予め設定された状態とを比較した結果に応じて、所定の制御を実行する。【選択図】図１３
2020098952.tif 000002
【特許請求の範囲】
【請求項１】
通信システムにおける通信管理方法であって、
前記通信システムは、情報の送信元である複数の端末から通信路を介して情報を受信する集約部と、前記端末から送信されたデータを処理する処理部と、前記端末が信号を送信するタイミングをスケジューリングする予約部とを有し、
前記通信管理方法は、
前記処理部が、前記予約部が決定したタイミングから定められる処理時間帯において、前記端末が送信した情報を監視し、
前記処理部が、前記監視された情報から、前記端末の状態を推定し、
前記処理部が、前記推定された端末の状態と予め設定された状態とを比較した結果に応じて、所定の制御を実行することを特徴とする通信管理方法。
【請求項２】
請求項１に記載の通信管理方法であって、
前記予め設定された状態は、スケジューリングされた送信信号を前記処理時間帯において受信することであり、
前記処理部は、前記送信信号を前記処理時間帯において受信しない場合に、所定の制御を実行することを特徴とする通信管理方法。
【請求項３】
請求項１に記載の通信管理方法であって、
前記所定の制御は、所定の待機時間後に再送指示を前記端末に送信することであり、
前記処理部は、前記推定された端末の状態と予め設定された状態とが異なる場合に、所定の待機時間後に再送指示を前記端末に送信することを特徴とする通信管理方法。
【請求項４】
請求項３に記載の通信管理方法であって、
端末毎に前記所定の待機時間が設定可能であることを特徴とする通信管理方法。
【請求項５】
請求項４に記載の通信管理方法であって、
前記処理部は、
前記端末の種別によって予め設定された待機時間を参照して、
前記端末の種別によるグループ毎に前記所定の待機時間を設定することを特徴とする通信管理方法。
【請求項６】
複数の端末から通信路を介して情報を収集する通信システムであって、
情報の送信元である複数の端末から通信路を介して情報を受信する集約部と、
前記端末から送信されたデータを処理する処理部と、
前記端末が信号を送信するタイミングをスケジューリングする予約部とを備え、
前記処理部は、
前記予約部が決定したタイミングから定められる処理時間帯において、前記端末が送信した情報を監視し、
前記監視された情報から、前記端末の状態を推定し、
前記推定された端末の状態と予め設定された状態とを比較し、これらの状態が異なる場合に、所定の制御を実行することを特徴とする通信システム。
【請求項７】
請求項６に記載の通信システムであって、
前記予め設定された状態は、スケジューリングされた送信信号を前記処理時間帯において受信することであり、
前記処理部は、前記送信信号を前記処理時間帯において受信しない場合に、所定の制御を実行することを特徴とする通信システム。
【請求項８】
請求項６に記載の通信システムであって、
前記所定の制御は、所定の待機時間後に再送指示を前記端末に送信することであり、
前記処理部は、前記推定された端末の状態と予め設定された状態とが異なる場合に、所定の待機時間後に再送指示を前記端末に送信することを特徴とする通信システム。
【請求項９】
請求項８に記載の通信システムであって、
端末毎に前記所定の待機時間が設定可能であることを特徴とする通信システム。
【請求項１０】
請求項９に記載の通信システムであって、
前記処理部は、
前記端末の種別によって予め設定された待機時間を参照して、
前記端末の種別によるグループ毎に前記所定の待機時間を設定することを特徴とする通信システム。
【請求項１１】
通信システムにおける通信管理するためのプログラムであって、
前記通信システムは、情報の送信元である複数の端末から通信路を介して情報を受信する集約部と、前記端末から送信されたデータを処理する処理部と、前記端末が信号を送信するタイミングをスケジューリングする予約部とを有し、
前記プログラムは、
前記予約部が決定したタイミングから定められる処理時間帯において、前記端末が送信した情報を監視する第１手順と、
前記監視された情報から、前記端末の状態を推定する第２手順と、
前記推定された端末の状態と予め設定された状態とを比較し、これらの状態が異なる場合に、所定の制御を実行する第３手順とを前記処理部に実行させるためのプログラム。
【請求項１２】
請求項１１に記載のプログラムであって、
前記予め設定された状態は、スケジューリングされた送信信号を前記処理時間帯において受信することであり、
前記第３手順では、前記送信信号を前記処理時間帯において受信しない場合に、所定の制御を前記処理部に実行させるためのプログラム。
【請求項１３】
請求項１１に記載のプログラムであって、
前記所定の制御は、所定の待機時間後に再送指示を前記端末に送信することであり、
前記第３手順では、前記推定された端末の状態と予め設定された状態とが異なる場合に、所定の待機時間後に再送指示を前記端末に送信すること前記処理部に実行させるためのプログラム。
【請求項１４】
請求項１３に記載のプログラムであって、
端末毎に前記所定の待機時間が設定可能であることを特徴とするプログラム。
【請求項１５】
請求項１４に記載のプログラムであって、
前記端末の種別によって予め設定された待機時間を参照して、前記端末の種別によるグループ毎に前記所定の待機時間を設定する手順を前記処理部に実行させるためのプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、通信システムにおける通信管理方法に関する。
【背景技術】
【０００２】
通信ネットワークサービスの提供に関する契約では、サービス提供者とサービス受給者間で共有されるポリシーである回線の帯域、ＱｏＳ及び時間帯によって価格を決定し、サービス提供者は、定めれた条件に基づいて共有された回線やネットワーク機器を提供している。また、ＩｏＴシステムにおいては、センサなどのモノが情報の発信源となり、機械から機械への通信（Ｍ２Ｍ）が増加すると予測される。センサなどからの分散情報の収集において、大量のセンサが分散して配置され、これらのセンサから定期的に一次情報が報告され、別途設けられた中央処理装置に報告データが集約され、集約された情報が二次情報として利用される。情報の収集周期が十分に長いセンサデータについては、通信トラヒックの閑散時に通信を行うように時間帯を指示する技術が、特許文献１に開示されている。
【０００３】
図１７を参照し、特許文献１による従来例について簡単に説明する。図１７の下部は、汎用的な通信システムにおいて１日のトラヒックの１時間単位の変動の例を示す。横軸１０００は１日（２４時間）を示す。また、１時間単位の時間帯が帯１０２０により表され、２４本の帯によって２４時間が示され、帯の下方の黒色部によって、該当する時間帯の１時間の平均トラヒック１０１０が示されている。また、帯の上方の白色部は、ネットワークの容量であり、矢印１０３０がネットワークのマージン（すなわち、容量と利用中のトラヒックとの差）を示している。
【０００４】
図１７を参照して、特許文献１が開示する技術の要点を説明する。１日の内、通信トラヒックが低い時間帯である閑散期は、「ａ」及び「ｂ」であり、この時間帯においては追加のトラヒックを転送する余裕が十分にある。ここで、このネットワークで追加的にＩｏＴのトラヒックを転送することを考える。特許文献１には、ネットワーク上のトラヒックを分析して、閑散時間帯（図１７の「ａ」「ｂ」）を把握して、その時間帯にＩｏＴトラヒックが送信されるようにＩｏＴ機器の送信時間を設定することが開示されている。
【０００５】
この閑散時間帯に通信するということを図１７の上部を使って表す。図１７は、上部と下部の二つに分けて示されており、上部には黒色で示されたタイミング（例えば、１１００）と白塗りで示されたタイミング（例えば、１１１１）が示されている。白色のタイミング１１１１は端末Ａがデータを送信するタイミングを示し、黒色のタイミング１１０１は端末Ａによって送信された情報が中央処理部において参照されるタイミング、すなわち利用されるタイミングを示す。特許文献１に従えば、図１７に示すように、全ての白色のタイミングは、閑散期である「ａ」及び「ｂ」の時間帯に配置される。すなわち、スケジューラは、トラヒックの閑散期を調査して予め知っており、その知識に基づいて白色のデータ送信タイミングを生成する。
【０００６】
特許文献１は、ＩｏＴ向けのセンサとして、植物の成長データや、橋の亀裂等のデータなどの日、週、月単位のデータ収集などのリアルタイム性が求められないデータ収集に関して、ネットワーク機器の閑散時間帯を利用することを開示しているが、１日単位より十分に短い周期の情報収集は考慮されておらず、このような周期の通信には対応できない。この点について図１８を参照して課題を説明する。図１８では、図１７と同じく横軸１０００を１日として、データが１日４回収集されるタイミングを示す。図１７と同様に、白色のタイミング（１１１１、１１１２、１１１３、１１１４）は各端末がデータを送信するタイミングであり、黒色のタイミング（１１０１、１１０２、１１０３、１１０４）は各端末が送信したデータが集約されて処理されるタイミングを示す。図１８に示す例では、時間帯「ａ」と「ｂ」がそれぞれデータの処理タイミング（１１０１、１１０４）の直前にあるため、送信タイミング（１１１１、１１１４）は、閑散期にセンサ情報を送信しているが、データの処理タイミング（１１０２、１１０３）は直前に閑散時間帯がないため、閑散時間帯を狙って送信タイミングを決めることができない。
【０００７】
一方、従来例が問題提起するように、ユーザが自由に通信路の使い方を規定すると、ネットワークのバーストトラヒックなどの問題が発生する。例えば１時間毎の報告では、アプリケーション開発者がネットワークの状態を考慮した設計は難しく、毎時０分０秒に通信が集中すると予想される。その結果、０分０秒辺りにトラヒックが集中し、トラヒックの分散化が図れない。よって何等かのタイミング制御手段が必要である。
【０００８】
更に、無線を使った機器について詳しく見てみる。無線通信システムは、端末と複数の端末と繋がる集約手段から構成され、図１９に示すように、端末と集約手段とで信号を送受信してデータを伝送している。この際に、ＬＰＷＡなどの無線方式においては、端末は、消費電力を低下させるために、基地局からの信号を受信するタイミングを極力狭い窓とし、窓の間隔を長くして、窓の間は消費電力を抑えるためにスリープモードになるように設定している。端末がいつ送信するか分からないため、集約手段は継続的に受信を待ち受けている。
【０００９】
図１９を用いて、信号の送受信を詳しく説明する。端末の制御部がメッセージの送信を決定し、端末の無線部にメッセージの送信を指示する（２００４）。端末の無線部は、制御部からの指示を契機にスリープから復帰してアクティブになり、メッセージを送信する（２００５）。集約手段の無線部は、信号が正しく受信できればＡＣＫ信号を端末の無線部に送信する（２００６）。端末の無線部は、ＡＣＫ信号を受信するとスリープ状態に戻る。一定時間内にＡＣＫ信号を受信できない場合にはメッセージ２００５を再送する。集約部の無線部は、ＡＣＫを送信した後に、集約部の制御部に対してメッセージの受信を知らせる（２００７）。
【００１０】
一般的にＬＰＷＡでは、屋内に設置され微弱な電波しか届かない端末と通信するため、オーバーヘッドが大きい信号方式を使用し、信号を送信する。図１９では、オーバーヘッドが大きいメッセージが無線で送信される。図１９では、二つの信号２００５及び２００６がオーバーヘッドが大きい信号である。メッセージを伝えるため信号２００５はオーバーヘッドが大きくてもやむ得ないものの、ＡＣＫ信号は、受信側がデータを受け取ったことを送信側に伝えるための信号であり、１ビット程度の情報しか持たないが、その情報を伝えるためにもオーバーヘッドを含む無線リソースを大きく消費することが課題となる。
【００１１】
また、無線端末は、センサが取得した情報を上位に報告すること役割を有する。センサは移動体に付けられたり、特定の場所に固定的に設置される。無線通信においては、端末の移動や周囲環境の変化によって通信路の状態が変化し、電波の波としての性質から干渉が生じて受信信号強度が低下した時などに通信誤りが発生する。このメカニズムを考慮すると、固定的に設置された端末において通信誤りが発生する原因は、端末そのものではなく、周囲環境の変化に伴うものが多いと考えられる。周囲環境の変化による通信誤りは完全には防止できないため、周囲環境の変化に応じたデータの再送が必要である。
【先行技術文献】
【特許文献】
【００１２】
【特許文献１】特開２０１７−２１２４９４号公報
【発明の概要】
【発明が解決しようとする課題】
【００１３】
環境データなどを収集するセンサデータは、１時間や数分単位などの短い送信周期におけるデータ収集が必要である。特許文献１が開示する方法では、このような用途に対応できない。
【００１４】
また、標準化団体である３ＧＰＰで議論されているＮＢ−ＩｏＴなどの技術は、他の一般用途に利用されている帯域の一部をＩｏＴ専用に割り当てるなど、一般用途のチャネルと明確に分けてＩｏＴトラヒックを収容しようとしている。このような場合、一般用途のトラヒック分析では、ＩｏＴ専用のチャネルの利用効率を向上できず、前述した特許文献１が開示する方法では対応できない。
【００１５】
また、多様なサービスが開発されており、成功するサービスを作り上げるには、リーンスタートアップなどの運用をしながら仕様を変更していく開発手法が注目されている。リーンスタートアップは、サービスを運用しながら、その使い方や仕様を変化させていくアプリケーションソフトウェアの開発手法である。このような流れによって、アプリケーションソフトウェア開発において、ネットワークについての豊富な知識を前提とするネットワークの効率化は難しくなっており、コストを低減しながら開発速度を向上させ、ネットワークの使い方などの変更をしながら効果的なシステムを作り上げることが課題となっている。しかしながら、複雑化するネットワークの管理にもコストを掛けられない状況にあり、ネットワークの管理を簡便化するための仕組みも必要とされている。
【００１６】
また、ＡＣＫの送信は周波数リソースを消費する。無線回線の誤り率はシステムに依存するが、通常は１０％以下が適切である。ＡＣＫはメッセージが正しく届いていないことを示すために利用されるが、オーバーヘッドが大きいので、誤り率が低い環境においては周波数利用効率の点で無駄が大きい。また、通常、移動を伴なわずに固定的に設置されるセンサにおいて、多くの周囲環境の変化は外的要因（例えば、人間活動や社会活動の時間変化）によるものであると考えられる。そのため、変化が遅い環境においては、すぐにデータを再送しても、環境は悪いままであり、再び通信誤りが生じる。このように設置環境に応じた対応が必要である。
【００１７】
また、正常な動作状態を規定するマニフェストに従って端末を動作させることがあり、マニフェストに従った動作をしていない端末に、マニフェストに従った動作させるために、端末に所定の制御をさせる必要がある。
【課題を解決するための手段】
【００１８】
本願において開示される発明の代表的な一例を示せば以下の通りである。すなわち、通信システムにおける通信管理方法であって、前記通信システムは、情報の送信元である複数の端末から通信路を介して情報を受信する集約部と、前記端末から送信されたデータを処理する処理部と、前記端末が信号を送信するタイミングをスケジューリングする予約部とを有し、前記通信管理方法は、前記処理部が、前記予約部が決定したタイミングから定められる処理時間帯において、前記端末が送信した情報を監視し、前記処理部が、前記監視された情報から、前記端末の状態を推定し、前記処理部が、前記推定された端末の状態と予め設定された状態とを比較した結果に応じて、所定の制御を実行することを特徴とする。
【発明の効果】
【００１９】
本発明の一態様によれば、マニフェストに従って動作をしていない端末に所定の制御をさせることができる。前述した以外の課題、構成及び効果は、以下の実施例の説明によって明らかにされる。
【図面の簡単な説明】
【００２０】
【図１】第一の実施例のネットワークシステムの構成を示す図である。
【図２】第一の実施例の送信周期の種類を示す図である。
【図３】第一の実施例の送信周期が同じでオフセットの違いを説明する図である。
【図４】第一の実施例の予約部のインターフェースを示す図である。
【図５】第一の実施例のスケジュールが割り当てられるまでの手順を示すシーケンス図である。
【図６】第一の実施例のスロットの割り当て例を説明する図でる。
【図７】第一の実施例の割り当てが互いに衝突が発生しない周期とオフセットからなるペアを簡易に作る方法を示す図である。
【図８】第一の実施例の予約部の動作例を示す図である。
【図９】従来例において、端末手段とセンタ側システムとのメッセージの送受信を示す図である。
【図１０】第一の実施例において、端末手段とセンタ側システムとのメッセージの送受信を示す図である。
【図１１】第一の実施例において、端末手段とセンタ側システムとのメッセージの再送を示す図である。
【図１２】第一の実施例の中央処理部における再送指示に関わるシーケンスの例を示す図である。
【図１３】第一の実施例において、端末と集約部との間の伝搬環境の品質による端末と集約部との間のメッセージの送受信を示す図である。
【図１４】第二の実施例の再送要求に関する待機時間の決定方法を示すシーケンス図である。
【図１５】第二の実施例のセンサの種別毎に異なる待機時間を設定するシーケンスを示す図である。
【図１６】第二の実施例の待機時間に補正を加えるためのシーケンスを示す図である。
【図１７】従来技術における閑散時間帯のスロットの利用方法を示す図である。
【図１８】従来技術における送信頻度が上がった場合のスロットの利用方法を示す図である。
【図１９】従来技術におけるＡＣＫメッセージの送信を示す図である。
【発明を実施するための形態】
【００２１】
＜実施例１＞
本発明の第一の実施例について説明する。図１は、第一の実施例のネットワークシステムの構成を示す図である。図１において、端末１００には、センサが実装されており、通常、１日よりも短い周期において定期的に測定している。端末１００には、通信手段が実装されており、センサが測定したデータを定期的に中央処理部３００に送信する。データ収集する際の回線（図１で、端末１００と集約部２００の間の矢印）には、例えば無線が使用される。無線を使用すれば、遠距離でも有線による物理回線を敷設するための開設コストを低減できる。
【００２２】
無線回線を介した端末１００の対向には、無線回線の上り側の終端装置となる集約部２００が設けられる。集約部２００は、無線回線を終端し、電波で受信した信号をデジタルデータに変換する。集約部２００が収集したデータは、バックホール回線を通じて中央処理部３００に送られる。通常、バックホール回線は有線回線であり、例えばインターネットなどの回線や通信事業者が設けた専用線などが利用される。中央処理部３００は、収集した一次データが集計、集約、加工し、第三者が利活用可能な二次データに変換する。
【００２３】
図１においては、端末１００は一台しか記載していないが、ＩｏＴシステムにおいては、多数の端末１００が集約部２００と接続し、様々な情報を収集する。端末１００は分散した場所に設置されており、端末１００の設置範囲をサポートするため、複数の集約部２００が配置される場合もある。多数のデータが同時又は同時期に送信されると、送信された信号が重なり、干渉が発生する。このため、受信側である集約部２００においてデータの復号に失敗し、正しい情報を受信できない問題が発生する。
【００２４】
この問題を解決するために、システム全体としてデータ送信タイミングを調整し、調整されたタイミングに従って、各端末１００がデータを送信する仕組み（スケジューリング機能）が重要である。センサに様々な種類がある場合、データの種類や場所によって収集する頻度が異なる。このような多数の端末１００について、システム全体としてのデータ送信タイミングの調整を、ユーザ６００やアプリケーションの開発者が考えることは難しい。従って、本実施例では、端末１００に実装される通信手段が送信可能な絶対時間を通知し、ユーザ６００は送信周期を指定するだけで、絶対時間を決定するために必要なパラメータであるオフセットをユーザ６００が指定することなく、予約部４００がオフセットを決定する構成とした。
【００２５】
さらに、集約部２００がメッセージを受けるべきタイミング３０１を中央処理部３００が予め知っているため、集約部２００を含むセンタ側のシステムは、適切なタイミングにおいて、正しい情報が受信できないことを容易に検出できる。このことを利用して、期待するタイミングでメッセージ受信ができない場合に、メッセージの再送をセンタから要求する。この方法は、センタ側のシステムが、スケジューリング機能と連携して、端末それぞれのメッセージ送信タイミングを知っており、当該タイミングから一定時間以内に該当するメッセージを受信して、メッセージが受信できたかを判定することによって、メッセージを受信する度に端末にＡＣＫを送信しなくてもデータの完全性を高めることができる。
【００２６】
本実施例では、予約部４００がデータ送信タイミングを決定し、端末１００に指示する。無線の通信路としては、例えばＬｏＲａＷＡＮなどのＩｏＴ用途の通信方式が適する。本実施例では、「メッセージの送信タイミングをスケジューリングすること」を特徴としているが、無線システム一般において使われるスケジューリングとの違いを明らかにする必要がある。一般に、モバイル通信方式では、集約部２００がスケジューラ機能を備えており、端末１００が送信するスケジュール割り当て要求に応じて動的に回線を割り当てている。このモバイル通信のスケジューラは、端末１００からのランダムアクセスによるキューの処理を処理するものであり、予めシステムとして、メッセージの送信タイミングを調整する本実施例とはスケジューリングの考え方が異なる。このモバイル通信方式と本実施例との違いを明確にするために、モバイル通信方式の仕組みを説明する。
【００２７】
端末１００は、集約部２００が作成し指示するスケジューリング情報に従ってデータを送信する。しかし、集約部２００が作成するスケジューリング情報は、その時点で端末１００から受信したスケジューリング割り当て要求をバッファにキャッシュして、特定のアルゴリズムに従って優先順位を決めているにすぎず、高々１秒以下の範囲の短期的なスケジューリング制御しか行っていない。それゆえ、１秒以下の短期的なメッセージの衝突を緩和して回避する効果しか期待できない。大量の端末１００が同時にスケジューリングを要求する環境においては、要求そのものを分散させて回線を有効利用することは困難である。
【００２８】
モバイルのスケジューラでは、特定のトラヒックが集中する時刻には回線の利用率が限界にまで上昇し、回線がパンク状態になってしまう。例えば、０時０分などの特定時刻に多くの端末１００からのトラヒックが集中する場合、端末１００から大量のスケジュール要求がほぼ同時に送信され、割り当て可能な回線の帯域幅で回線処理が飽和し、長期に渡って通信が滞る状態が続く。このような事態を回避するため、本実施例では、ＩｏＴのトラヒックの性質を考慮し、予約部４００が特定時刻へのトラヒック集中を回避するように予め送信タイミングを分散させる。これにより特定時刻へのトラヒックの集中を回避できる。
【００２９】
次に、予約部４００の動作を説明する。予約部４００は、例えば５ミリ秒や３０ミリ秒などの固定の時間分解能で、１日を時間のスロットに分割しており、各スロットに付された識別子によって端末１００がデータを送信するタイミングを指示する。本実施例では、ポータル５００がネットワークのサービスメニューを提供する。ユーザは、提供されたメニューからＡＰＩを使って利用したいサービスを選択する仕組みを提供する。特にＩｏＴにおいて重要なのは、報告周期であることから、ポータル５００上では、複数の報告周期（例えば１分周期や１時間周期などの相対時間）が選択可能な通信サービスのメニューがユーザに提供される。
【００３０】
本実施例の中央処理部３００、予約部４００及びポータル５００は、プロセッサ（ＣＰＵ）、記憶装置及び通信インターフェースを有する計算機システムによって構成される。
【００３１】
プロセッサは、メモリに格納されたプログラムを実行する。メモリは、不揮発性の記憶素子であるＲＯＭ及び揮発性の記憶素子であるＲＡＭを含む。ＲＯＭは、不変のプログラム（例えば、ＢＩＯＳ）などを格納する。ＲＡＭは、ＤＲＡＭ（Dynamic Random Access Memory）のような高速かつ揮発性の記憶素子であり、プロセッサが実行するプログラム及びプログラムの実行時に使用されるデータを一時的に格納する。
【００３２】
記憶装置は、例えば、磁気記憶装置（ＨＤＤ）、フラッシュメモリ（ＳＳＤ）等の大容量かつ不揮発性の記憶装置である。記憶装置は、プログラムの実行時にアクセスされるデータを格納する。また、記憶装置は、プロセッサが実行するプログラムを格納してもよい。この場合、プログラムは、記憶装置から読み出されて、メモリにロードされて、プロセッサによって実行される。
【００３３】
ＣＰＵが実行するプログラムは、リムーバブルメディア（ＣＤ−ＲＯＭ、フラッシュメモリなど）又はネットワークを介して物体検出装置に提供され、非一時的記憶媒体である不揮発性の記憶装置に格納される。このため、計算機システムは、リムーバブルメディアからデータを読み込むインターフェースを有するとよい。
【００３４】
中央処理部３００、予約部４００、ポータル５００の各々は、物理的に一つの計算機上で、又は、論理的又は物理的に構成された複数の計算機上で構成される計算機システムであり、複数の物理的計算機資源上に構築された仮想計算機上で動作してもよい。
【００３５】
図２を用いて送信周期の種類を説明する。図２において、横軸１３０１は、例えば、１日（２４時間）を表している。１４０Ｘで示す縦棒は、そのタイミング（スロット）で信号を送信することを表す。１４０１は、１日に１回しか送信しないサービスを示す。１３０２は半日（１２時間）を表しており、送信タイミング（１４０２−１、１４０２−２）は１日の内、１２時間離隔した２回である。１３０３及び１３０４も同様であり、１３０４は、１／４日（６時間）を表しており、送信タイミング（１４０４−１、１４０４−２、１４０４−３、１４０４−４）は、１日の内、６時間離隔した４回である。ユーザは、このような送信周期のメニューを選択することによって、例えば１分周期で報告が上がる通信回線を契約できる。
【００３６】
ここで、ユーザがメニューから選択するのは「周期」だけで、絶対時間を確定するために必要なもう一つのパラメータである「オフセット」は選択されず、ユーザに隠ぺいされている点がポイントとなる。予約部４００は、複数の端末１００が互いに送信タイミングが重なって通信エラーが発生しないように、ユーザから指示された「周期」を維持しつつ、複数の回線のオフセットを調整して絶対時間である送信タイミングを決定する。そして、決定した絶対時間（周期とオフセット）を端末１００に伝え、干渉を回避する。本実施例によると、ユーザとの契約事項は周期のみで、オフセットは隠ぺいするので、ユーザは干渉などの問題を特に認識せずに通信回線を調達できる。また、予約部４００は、オフセットも含めて送信周期を端末１００に指示することによって、システム全体としての送信タイミングの集中を回避できる。
【００３７】
図３を用いて、オフセットの考え方を説明する。図３は、送信周期が同じでオフセットが違う送信タイミングを示し、横軸１３０１は１日（２４時間）を表している。図３に示す例では、１日を３等分した１３０３（８時間）だけ離散した３つの送信タイミング（１４０３−１、１４０３−２、１４０３−３）があり、データの送信時刻は０時０分、８時０分、１６時０分である。また、図３は、時刻を２０分オフセットした三つの送信タイミング（１４０３−４、１４０３−５、１４０３−６）も示しており、データの送信時刻は０時２０分、８時２０分、１６時２０分である。送信時刻をオフセットしていないペア（１４０３−１、１４０３−２、１４０３−３）と、送信時刻を２０分オフセットしたペア（１４０３−４、１４０３−５、１４０３−６）とでは、互いに２０分ずれて同じ「周期」でデータが送信される。「周期」は同じであるが、「オフセット」が２０分ずれている。そのため、送信タイミング（データが送信される絶対時間）は同じならない。このように、同一の送信周期であっても、オフセットの調整によってトラヒック集中を回避した割り当てが可能である。
【００３８】
予約部４００は、ユーザから要求があった周期で、過去に割り当てた送信タイミングと互いに重ならないオフセットを探して、該当する端末１００の送信タイミングの絶対時間（周期とオフセットのペアー）を決定する。
【００３９】
図４は、予約部４００のユーザ側とのインターフェースと、端末１００とのインターフェースの違いを示す。予約部４００が端末１００に対して割り当てる送信タイミングは、既に説明した通り、「周期」と「オフセット」からなる絶対時間の群を示す情報である。一方で、ユーザ６００とやり取りするスケジューリングに関わる情報は、「周期」からなる相対時間の情報だけで、オフセットに関わる情報はやり取りされない。予約部４００が端末１００に指示する周期は、ユーザが要求した周期と一致しており、ユーザが選択した相対的な送信周期は守られる。
【００４０】
端末がメッセージを送信するタイミングは、センタ側にあるスケジューラが決定しているので、スケジューリングの結果を蓄積したファイルを参照することによって、受信側であるセンタにおいて、信号が適切なタイミングで受信されたかを容易に判定できる。その判定結果に基づいて、スケジュール通りにメッセージが受信されていない場合を検知し、再送を指示するメッセージを端末に対して送る仕組みを作り、メッセージ受信の失敗によるデータの欠損を防止できる。この仕組みにより、集約部２００は、端末１００からのメッセージ受信時に、各々の受信メッセージに対するＡＣＫメッセージを送信する必要がなくなる。例えば、誤り率が１０％の無線回線の場合、全メッセージに対してＡＣＫメッセージを送付する方法と、メッセージ受信失敗時のみに再送要求を行う方法とを比べると、再送を端末に認知させるためのメッセージの送信回数は、実施例では１／１０に削減できる。ＡＣＫメッセージは、１ビットの情報であるが、ＬＰＷＡでは、大きなオーバーヘッドを付けてメッセージを送るため、ＡＣＫメッセージの送信に周波数リソースを多く消費する。例えば、ＬｏＲａＷＡＮの場合では、メッセージの物理フォーマットは、プリアンブルと呼ばれるシンボル長の長いオーバーヘッドとＭＡＣヘッダが、１ビットのＡＣＫ情報に加算されるため、プリアンブルの分の周波数リソースも消費する。従って、ＡＣＫメッセージを省略し、再送が必要な端末にのみ再送要求を送れば、周波数利用効率の改善に有効である。
【００４１】
しかし、ＬｏＲａＷＡＮのようなＬＰＷＡでは、通常、端末の送信タイミングはセンタ側では分からないため、ＡＣＫメッセージによる確認が望ましい。しかし、本実施例の場合、該当端末のメッセージ送信タイミングは、センタ側のスケジューラによって決めているため、センタ側で端末の送信タイミングを取得でき、前述した再送要求の仕組みを実施できる。
【００４２】
この再送メッセージの送信について、図９、図１０、図１１、図１３を用いて詳細に説明する。
【００４３】
図９は、従来例において、端末１００とセンタ側システム（集約部２００、中央処理部３００）とのメッセージの送受信を示す図である。図９において、中央処理部３００は、上位の予約部４００からのスケジューリング情報を含むメッセージの送信を集約部２００に指示する（２００１）。集約部２００は、中央処理部３００から指示された情報を端末１００に送信する（２００２）。
【００４４】
端末１００の無線部は、受信したメッセージを端末１００の制御部に報告する（２００３）。制御部は、指示された送信タイミングに従って、メッセージの送信タイミングを調整し、適切なタイミングにおける情報の送信を無線部に指示する（２００４）。無線部は、指示に従って該当するメッセージを無線信号として集約部２００に送信する（２００５）。
【００４５】
集約部２００は、受信したメッセージに含まれる信号の復号の成否を判定し、復号に成功した場合には中央処理部３００にメッセージを伝える（２００６）。また、集約部２００は、成否の結果をＡＣＫメッセージとして端末１００に送信する（２００７）。
【００４６】
端末１００の無線部は、制御部にＡＣＫメッセージの内容を報告する。制御部はＡＣＫメッセージに含まれる信号の復号の成否の結果によって再送するかを判定する。すなわち、ＡＣＫメッセージが受信され、且つ、復号の結果が成功（ＡＣＫ）である場合以外に、メッセージを再送する。
【００４７】
図１０及び図１１は、本発明の実施例において、端末１００とセンタ側システム（集約部２００、中央処理部３００）とのメッセージの送受信を示す図である。図１０において、中央処理部３００は、上位の予約部４００からのスケジューリング情報を含むメッセージの送信を集約部２００に指示する（２００１）、集約部２００は、中央処理部３００から指示された情報を端末１００に送信する（２００２）。
【００４８】
端末１００の無線部は、受信したメッセージを端末１００の制御部に報告する（２００３）。制御部は、指示された送信タイミングに従って、メッセージの送信タイミングを調整し、適切なタイミングにおいて情報の送信を無線部に指示する（２００４）。無線部は、指示に従って該当するメッセージを無線信号として集約部２００に送信する（２００５）。
【００４９】
集約部２００は、受信したメッセージに含まれる信号の復号の成否を判定し、復号に成功した場合には中央処理部３００にメッセージを伝える（２００６）。図９と異なり、集約部２００は、復号の成否をＡＣＫメッセージとして端末に送信しない。中央処理部３００では、スケジューラが定めた時刻を参照し、予め利用者が設定した状態と、上記の推定された端末の状態とを比較し、差分が発生した場合に、規定の制御を実施する。例えば、予め利用者が設定する状態として、「予め設定された時刻において期待されるシーケンス番号を持つデータが受信されること」を設定する。予め設定された時刻において、条件を満たさない（期待されるシーケンス番号を持つデータが受信されない）場合、予め利用者が定めたアクションを実行する。例えば、アクションは、「該当端末に対して、一定の時間が経過後に該当するデータの再送を要求すること」である。図１０では、集約部２００が中央処理部３００に伝えるメッセージ２００６の受信タイミングに設けられた窓２０２０の範囲でメッセージ２００６を受信できた場合には、ＡＣＫは送信せず、次の受信タイミングまで該当端末に対する処理はない。
【００５０】
図１１は、受信タイミングに設けられた窓２０２０において、メッセージ２００６を受信できなかった場合の処理を示す。
【００５１】
中央処理部３００は、端末の状態が期待される状態と異なる、すなわち、受信タイミングに設けられた窓２０２０において、メッセージ２００６を受信できなかったので、一定又は決められた計算によって得られた時間の待機の後、再送指示のメッセージを発行する（２００９）。集約部２００は、端末に再送指示を送信する（２０１０）。端末１００の無線部は、再送メッセージを受けると、制御部に再送メッセージを伝え（２０１１）、先のメッセージ２００５が正しく受信されていないことを知る。制御部からの指示２０１２に従って、無線部は集約部２００にメッセージを再送する（２０１３）。集約部２００は、受信した再送メッセージに含まれる信号の復号の成否を判定し、復号に成功した場合には中央処理部３００にメッセージを伝える（２０１４）。
【００５２】
再送メッセージの指示において、一定又は決められた計算によって得られた時間の待機時間を設けたが、この意味ついて、図１３を用いて説明する。図１３（Ａ）は、端末１００と集約部２００との間の伝搬環境の品質（例えば、無線信号の受信電界強度）２０３０を示している。伝搬環境の品質は、通信の誤りと密接に関係する受信信号強度等である。図１３（Ａ）において、横軸は時間を示し、品質が高いほど、通信回線は良好であることを模式的に表している。ＩｏＴのようなセンサの場合、モバイル環境ではなく、端末１００は固定位置に設置される。このような場合、無線の伝搬環境の変化は周囲の環境の変化に依存し、人や社会の活動に応じた速度で変動する。すなわち、モバイル通信のように数ミリ秒オーダの変化ではなく、数分から数時間オーダの長い時間で変動する。図１３（Ａ）に示す品質２０３０は、横軸における中央部分で低い値となっているが、そのタイミングにおいて数時間程度の品質が劣化している。このような状況において、図１３（Ｂ）に示す従来例、図１３（Ｃ）に示す本実施例における端末１００と集約部２００との間のメッセージの送受信を矢印で示している。×マークが付されている矢印はメッセージが届いていないことを示し、伝搬環境の品質が低下している期間と一致している。
【００５３】
図１３（Ｂ）に示す従来例において、端末１００はＡＣＫメッセージを受信しないため、再送を繰り返すが、すぐには伝搬環境が回復しないため、何度も再送を繰り返す。この繰り返しの周期は、無線方式に依存するため、環境やソフトの作りで制御し難く、環境に依存した設定が困難である。
【００５４】
図１３（Ｃ）に示す本実施例において、再送要求のタイミングは無線方式に依存せず、環境に応じてユーザが設定できる。これにより、周波数利用効率を低下させるＡＣＫメッセージの送信を抑止しつつ、通信の失敗を端末１００に伝え、再送を行うための仕組みを構築できる。よって課題が解決される。
【００５５】
次に、端末１００がメッセージ受信する場合について説明する。端末１００は、ある周期でスリープから復帰して一定のタイミングにおいて端末への信号が集約部２００から送られていないかをチェックしている。集約部２００は、端末１００毎に定められたスリープから復帰して、信号を受信しているタイミングに合わせて再送処理を指示するメッセージを送付する。
【００５６】
予約部４００は、中央処理部３００及び集約部２００を経由して、端末１００にスケジューリング情報を送る。端末１００は、新たな送信タイミングを含むスケジューリング情報の情報を受けると、受信した新たな送信タイミングに従って、信号を送信する。
【００５７】
本実施例のサービスでは、通信は特定の周期で実行され、干渉も回避されるように制御しやすいため、管理を自動化しやすい。例えば、ある時刻に発生した不具合に関わる通信は特定が容易である。そのため、問題発生時の関連ノードを容易に特定できる。
【００５８】
図５を用いて、スケジュールが割り当てられるまでの手順を説明する。図５の上部には端末１００、集約部２００、中央処理部３００、予約部４００、ポータル５００、ユーザ６００が記載されている。まず、ポータル５００は、ユーザに周期を選択させるために、いくつかの周期のオプションを示す（１０）。周期のオプションは、提供される通信サービスのテンプレートの形式でユーザに提示されてもよい。ユーザ６００は、ポータル５００が示したオプションから選択したものをポータル５００に伝える（２０）。ポータル５００は、選択結果を受信すると、選択された周期を予約部４００に伝える（３０）。予約部４００は、現在割り当てられているタイミングと、ポータル５００から受信した周期から、データ送信タイミングが衝突しない（すなわち、他の通信と干渉しない）オフセットを探索し、探索されたオフセット及び周期を端末１００に指示する（４０）。端末１００は、指示されたオフセット及び周期に基づいて定められるタイミングで測定結果を報告する（５０−１、５０−２、５０−３）。
【００５９】
図６を用いて、スロットの割り当てにおいて、異なる周期でオフセットがずれたスロットが互いに重ならない様に設定する例を説明する。図６の横軸１００１は、３６×１０ミリ秒の時間を示し、この時間内に３６個のスロット２０００が配置されている。また、図６は、スケジューリング結果３０００を示し、４０ミリ秒毎に割り当てられた「０／４」でマークされた送信タイミングを例示する。この「Ｘ／Ｙ」のＸはオフセットを、Ｙは周期を示す。図６で示す６種類のスケジューリング（「０／４」、「１／１６」、「２／４」、「５／１６」、「９／１６」、「１３／１６」）は、いずれも時間的に衝突しない割り当てを可能としている。ユーザからは、２種類の４０ミリ秒周期のスロットと、４種類の１６０ミリ秒周期のスロットが割り当てられているように見えるが、予約部４００がオフセットを調整することによって、これらが互いに衝突せずに同時に利用できる様にユーザに見せることができる。ユーザはオフセットを意識せずに、衝突しない割り当てを生成して、課題が解決される。
【００６０】
図６に示す例では、４分割されたスロットを更に４分割して１／１６のスロットを作り、四つの１／１６のスロットを異なるオフセットとして利用する。同様の操作を行うと、図７に示すように、１／６４のスロットも作れる。
【００６１】
図７を用いて、割り当てが互いに衝突が発生しない周期とオフセットからなるペアを簡易に作る方法を説明する。図７において、「０／１」が左端に書かれているが、この枠を分解して、４スロット周期で、オフセットがそれぞれ０、１、２、３の４つの枠を作ることができる。この４つの枠は互いに衝突しない。また、その内の「３／４」だけを分解し、更に４分割された（すなわち最初の「０／１」から１６分割された）４つの枠を作ることができる。そのオフセットを３、７、１１、１５とすることで、「０／４」、「１／４」、「２／４」、「３／１６」、「７／１６」、「１１／１６」、「１５／１６」は互いに衝突しない。このようにして、間隔があいたスロットをつくれば、無駄がないスロットを利用できる。さらに、「１５／１６」を４分割して６４スロット周期のタイミングも作成すると、「０／４」、「１／４」、「２／４」、「３／１６」、「７／１６」、「１１／１６」、「１５／６４」、「３１／６４」、「４７／６４」、「６３／６４」を作成し、これらは互いに衝突を起こさない。
【００６２】
本実施例では、図１において、端末１００はセンサを含む例で説明したが、センサ以外であっても、データを生成する装置、手段であれば、本発明の効果は変わらない。また、測定する対象も限定されるものではない。また、報告周期について、１日以下の例を挙げたが、１日よりも長い周期においても、本実施例は適用可能である。その場合、本実施例ではスロットの周期の最大値を１日として説明している部分を１週間あるいは１年と読み替えて実施方法を拡張することで本説明と同じことが容易に実施可能である。また、端末１００と集約部２００の接続について、無線通信を例に挙げて説明しているが、有線通信であっても、帯域に上限がある点は同じであり、同時に通信を行う大量の端末からのデータが集中すると、ネットワークだけでなく、データを加工する処理手段にも負荷がかかるため、時間的に分散されることが望ましい。よって、本実施例の効果は有線通信においても適用し、その効果が認められることは自明である。また、本実施例は、集約部２００と中央処理部３００が分離され、バックホール回線で接続する説明をしているが、これら（２００、３００）が物理的に１つの装置で実現される場合においても、端末１００と集約部２００間の回線における本実施例の効果は変わらないことは明らかである。更には、集約部２００（２００）が複数あり、それぞれが個別の識別子を持つなどして独立して動作する場合においても、端末１００とのメッセージの送受信において隣接する複数の集約部２００をグループとみなして、同グループ内での同時時刻の送信を回避することで、複数の集約部２００に関する問題解決に本実施例が適用できることは明らかである。十分に距離が離れ、電波が微弱にしか届かず、その影響を及ぼさない範囲については、同じ送信時間の送信時間を与えたとしても問題はない。本実施例の説明では、システム全体としてデータ送信タイミングを調整するとの記載部分を、システム全体で、互いに影響するデータ送信タイミングを調整するとの記載に読み替えることで、本実施例が適用可能である。
【００６３】
図８を用いて、予約部４００の動作例を説明する。予約部４００は、ユーザ６００からの指示である「周期」を受信すると、図８に示す処理を実行する。
【００６４】
まず、ステップ６０００において、ポータル５００から周期を取得する。また、ステップ６００１において、既に割り当てられた周期及びオフセットの情報を取得する。予約部４００は、既に割り当てられた周期及びオフセットの情報を保持しており、ステップ６００１ではこれを取得する。
【００６５】
ステップ６００２において、新たなオフセットを取得する。例えば、オフセットを０から開始すればよい。ステップ６００３において、取得した新たなオフセットを用いた仮の割り当てに従って、既に割り当てられた情報と照合し、割り当てが衝突するかを判定する。衝突が発生しなければ（ステップ６００３でＮｏ）、ステップ６００５において、端末１００に割り当てを通知して、割り当て処理を終了する。
【００６６】
一方、ステップ６００３において、衝突を検出した場合（ステップ６００３でＹｅｓ）、ステップ６００４において、全てのオフセットについて調査を終えたかを判定する。一部のオフセットの調査を残っている場合、ステップ６００２に戻り、新たなオフセットについての調査を継続する。一方、全てのオフセットの調査を終えていれば、ステップ６００６において、割り当てを行わず、割り当てが失敗したことをポータル５００に通知する。
【００６７】
図１２を用いて、中央処理部３００における再送指示メッセージに関する処理を説明する。図１２は、再送指示に関わるシーケンスの例を示す図である。
【００６８】
中央処理部３００は、メッセージの送信後、端末１００が送信するメッセージの受信を待ち受ける（６１００）。端末１００はスケジューラが定められた時刻にメッセージを送信するため、端末１００がメッセージを送信する時刻にマージン時間を含めた時刻を処理時刻（＝該当時刻＋マージン時間）とする。この処理時刻において、期待される状態と現状とを比較する（６１０３）。比較は様々な方法が考えられる。例えば、期待される状態が、処理時刻において、期待されるシーケンス番号を持つデータが受信されて、保持されること（６１１０）として説明する。この例では、端末からのメッセージに固有のシーケンス番号が付されており、そのシーケンス番号は新しいメッセージを送信する度に加算される。従って、新たに送信されるメッセージには、直近のメッセージのシーケンス番号に１を加算した番号が付される。
【００６９】
その最新の情報が期待されるタイミング、すなわち処理時刻において受信済みであることをクライテリアとする。条件を満たさない場合には、端末の状態が期待される状態と異なるため、制御アクション（６１０４）を実行する。一方、条件が満たされる場合には（すなわち、最新のシーケンス番号のメッセージを受信していれば）、端末の状態が期待される状態であるため、メッセージの受信処理（６１０１）を実行してデータを格納すると共に、タイマをリセット（６１０２）して、次のメッセージを受信するための準備を行い、待ち受け状態に戻る（６１００）。
【００７０】
条件が満たされない場合に実行される制御アクション（６１０４）には様々なものが考えられるが、本例では、所定の時間の待機の後に再送要求のメッセージを端末１００に送信し（６１１１）、その応答を待つ。応答があった場合には、受信処理を実行する（６１０１）。応答がない場合には、所定回数の再送要求を行ったかを判定し（６１１３）、所定回数未満であればさらに再送要求を行い（６１１１）、所定回数に達したならば再送要求を停止する（６１１４）という制御アクションを実行する。本実施例の動作を行うために、はじめにタイマを設定する必要があるが、そのタイマは、図８で説明した割り当ての通知（６００５）の後に設定するとよい。
【００７１】
＜実施例２＞
本発明の第二の実施例について、図１４を用いて説明する。図１４は、図１３において説明した再送要求に関する待機時間の決定方法を示すシーケンス図である。第一の実施例では、システム全体として所定の待機時間を設定しているが、既に説明している様に、端末１００の設置場所や設置方法によって電波伝搬の変動の周期が変化する。このため、システム全体で一つの待機時間ではなく、端末１００に個別の待機時間の設定が望ましい場合に、第二の実施例が好適である。端末１００に個別に待機時間を設定することによって、各端末１００が置かれた環境に対応したデータ転送方法を採用できる。例えば、工場において、端末１００の周囲で定期的な機械や機器の動作や移動があり、その周期に応じて電波環境が変化する環境であれば、その機器が移動する周期に応じた再送の周期の設定が適切である。
【００７２】
但し、個々の端末１００の特性が不明である場合、簡易な決定方法を採用しても、できるだけ時間間隔を取ることが再送を成功させる可能性が高められる。すなわち、各端末１００が設定している報告の周期に応じて時間間隔を決めることは有効である。よって、待機時間を個々の端末１００の報告周期をＮ分割し、分割された時間単位を待機時間とする方法が簡便かつ効果的である。例えば、Ｎ＝２において報告周期をＮ分割することを考える。報告周期が２時間の端末Ａと、報告周期が４時間の端末Ｂの２種類がある場合、端末Ａについては、１時の報告の次は３時の報告であるが、１時の報告が失敗した場合には、２時に再送を指する。また、同様に、端末Ｂについては、１時の報告の次は５時の報告であるが、１時の報告が失敗した場合には、３時に再送を指示する。
【００７３】
このように、個別に報告周期に応じて設定することによって、再送の頻度を減らすことができる。図１４では、これを実現するために、各端末のタイマ設定値として、端末毎の周期を取得し（７０００）、取得した周期の１／２の値を待機時間として設定する（７００１）。
【００７４】
端末１００に個別に待機時間を設定する他の例を説明する。図１５は、センサの種別毎に異なる設定が記録されたテーブルを予め持ち、センサの種別毎に異なる待機時間を設定する方法を示す。センサの種別と設置される環境に関連性がある場合には、このようなセンサの種類によるグルーピングが有効である。例えば、クレーンの近傍に設置されるセンサは、クレーンの動作の影響を受ける可能性が高く、クレーンの動きに応じた待機時間が設定されるとよい。また、運搬車の車庫の近傍に設置されるセンサは、車が収納される例えば夜間などに影響を受ける可能性が高い。このように周囲環境の変化との関係で再送の時間を決定するとよい。図１５では、センサ毎の種別（種別毎テーブルのＴＹＰＥ）を取得し、それによって、予め設定された種別毎テーブルを参照して待機時間を取得することで、センサの種別に応じた待機時間を設定できる。
【００７５】
また、同じセンサのグループでも、周囲環境が異なるために待機時間を調整する必要がある場合もある。そのため、自動的に待機時間に補正を加える方法を説明する。例えば、１時間毎に温度を測定する温度センサのグループあり、設置された場所の特殊性に影響を受ける場合、前述した種別毎テーブルの他に、個別の調整が可能な時間的な待機時間のオフセットを加えて、端末１００に個別に待機時間を設定できるようにする。
【００７６】
図１６に、待機時間に補正を加えるためのシーケンスを示す。該当する端末は、予め定められた待機時間の設定で動作している。そのため、図１２で説明した再送回数の管理（６１１３）において、期待される動作は、再送の１回目でデータ送信が成功することである。しかし、１回目の再送でデータ送信が成功せずに、再送を繰り返す場合、その環境において待機時間が足りないことを意味する。そのため、再送回数を取得し（７００４）、取得した再送回数に応じて該当する端末個別のオフセット時間αを増加させて待機時間を長くするように調整する。図１５に示すように端末の種別毎の待機時間をテーブルに定義しておく。そして、当該テーブルから得られる値に、この個別のオフセット時間αを加えた時間を待機時間に設定する。これにより、同一のグループでも、個別のオフセット時間に設定できる。
【００７７】
以上に説明したように、本発明の実施例によると、中央処理部３００が、予約部４００が決定したタイミングから定められる処理時間帯において、端末１００が送信した情報を監視し、監視された情報から端末１００の状態を推定し、推定された端末１００の状態と予め設定された状態とを比較した結果に応じて（例えば、これらの状態が異なる場合に）、所定の制御を実行するので、端末１００の正常な動作状態を規定するマニフェストに従って動作をしていない端末に所定の制御をさせることができる。また、ネットワークの効率的な運用ができる。
【００７８】
また、中央処理部３００は、送信信号を処理時間帯（窓２０２０）において受信しない場合に、所定の待機時間後に再送指示を端末に送信するので、回線利用効率を向上できる。すなわち、処理時間帯においてデータを受信できたことを示すＡＣＫメッセージの送信をなくし、データが届かなかった場合にだけ再送を要求する仕組みを設定でき、無駄な無線リソースの消費を抑制して無線回線の利用効率を向上できる。特に、ＬＰＷＡなどの無線方式に有効である。
【００７９】
また、端末１０毎に所定の待機時間が設定可能としたので、各端末に適切なタイミングで再送を要求できる。すなわち、各端末の状態を把握することによって、各端末に適切なアクションを実行させるためのトリガーを起こすことができる。
【００８０】
また、中央処理部３００は、端末の種別によって予め設定された待機時間を参照して、端末１００の種別によるグループ毎に所定の待機時間を設定するので、端末毎の再送タイミングの設定が不要であり、端末の管理が容易になる。
【００８１】
また、予約部４００が、端末１００が情報を送信する時間としてユーザが指定した相対時間を受信し、相対時間に従って端末１００が通信した場合に他の通信と干渉しないように、ＩｏＴシステム内で一意に定まる絶対時間をスケジューリング情報として定めるので、短い周期（例えば、数分程度）のデータ収集において回線利用効率を向上できる。回線としてＬＰＷＡなどのアンライセンスの無線方式に適用すると、本発明は有効である。また、３ＧＰＰなどの標準団体で議論されているＮＢ−ＩｏＴなどのＩｏＴ専用に設けられたモバイル通信においても有効である。また、サービスを提供するためのアプリケーションソフトウェアを開発する上で、ネットワークの詳細な設定を隠蔽し、上位概念である送信周期と帯域を指定するだけでネットワークが利用できるため、アプリケーションソフトウェアの開発速度を向上できる。
【００８２】
また、絶対時間は、基準時刻からのオフセット及びユーザが相対時間として指定した周期から定められるので、従来の回線提供に比べて、各ユーザによる回線の使い方を明確にできるため、ネットワークの管理が容易となり、管理のコストを低減できる。
【００８３】
なお、本発明は前述した実施例に限定されるものではなく、添付した特許請求の範囲の趣旨内における様々な変形例及び同等の構成が含まれる。例えば、前述した実施例は本発明を分かりやすく説明するために詳細に説明したものであり、必ずしも説明した全ての構成を備えるものに本発明は限定されない。また、ある実施例の構成の一部を他の実施例の構成に置き換えてもよい。また、ある実施例の構成に他の実施例の構成を加えてもよい。また、各実施例の構成の一部について、他の構成の追加・削除・置換をしてもよい。
【００８４】
また、前述した各構成、機能、処理部、処理手段等は、それらの一部又は全部を、例えば集積回路で設計する等により、ハードウェアで実現してもよく、プロセッサがそれぞれの機能を実現するプログラムを解釈し実行することにより、ソフトウェアで実現してもよい。
【００８５】
各機能を実現するプログラム、テーブル、ファイル等の情報は、メモリ、ハードディスク、ＳＳＤ（Ｓｏｌｉｄ  Ｓｔａｔｅ  Ｄｒｉｖｅ）等の記憶装置、又は、ＩＣカード、ＳＤカード、ＤＶＤ等の記録媒体に格納することができる。
【００８６】
また、制御線や情報線は説明上必要と考えられるものを示しており、実装上必要な全ての制御線や情報線を示しているとは限らない。実際には、ほとんど全ての構成が相互に接続されていると考えてよい。
【符号の説明】
【００８７】
１００・・・端末
２００・・・集約部
３００・・・中央処理部
４００・・・予約部
５００・・・ポータル
６００・・・ユーザ
７００・・・記憶部（データベース）
【図１】
2020098952.tif 000003
【図２】
2020098952.tif 000004
【図３】
2020098952.tif 000005
【図４】
2020098952.tif 000006
【図５】
2020098952.tif 000007
【図６】
2020098952.tif 000008
【図７】
2020098952.tif 000009
【図８】
2020098952.tif 000010
【図９】
2020098952.tif 000011
【図１０】
2020098952.tif 000012
【図１１】
2020098952.tif 000013
【図１２】
2020098952.tif 000014
【図１３】
2020098952.tif 000015
【図１４】
2020098952.tif 000016
【図１５】
2020098952.tif 000017
【図１６】
2020098952.tif 000018
【図１７】
2020098952.tif 000019
【図１８】
2020098952.tif 000020
【図１９】
2020098952.tif 000021