(57)【要約】  省電力広域無線通信におけるＡＣＫフレームの送信を効率的に行うサーバを提供する。サーバは、複数の端末のうち第１及び第２の端末それぞれからのデータ送信に対して確認応答を送信する。サーバは、第１及び第２の端末の受信スロットを開くタイミングが実質的に同一となるように、第１及び第２の端末を制御する。サーバは、第１及び第２の端末が共に受信スロットを開いている間に、第１及び第２の端末に共通な集約確認応答を送信する。
2019189597.tif 000002
【特許請求の範囲】
【請求項１】
複数の端末のうち第１及び第２の端末それぞれからのデータ送信に対して確認応答を送信し、  
前記第１及び第２の端末の受信スロットを開くタイミングが実質的に同一となるように、前記第１及び第２の端末を制御し、
前記第１及び第２の端末が共に受信スロットを開いている間に、前記第１及び第２の端末に共通な集約確認応答を送信する、
サーバ。
【請求項２】
前記複数の端末に無線接続を提供するゲートウェイを介して前記集約確認応答を前記第１及び第２の端末に送信すると共に、
前記ゲートウェイに対して前記集約確認応答が前記第１及び第２の端末に到達可能な送信電力にて出力するように指示する、請求項１に記載のサーバ。
【請求項３】
前記ゲートウェイに収容することが許容されている端末の数に基づき、前記集約確認応答を生成するか否かを判断する、請求項２に記載のサーバ。
【請求項４】
前記集約確認応答には、格納されたデータの宛先を特定可能とする情報が含まれる請求項１乃至３のいずれか一項に記載のサーバ。
【請求項５】
前記集約確認応答には、格納されたデータの宛先と、送信されたデータを特定するためのデータ番号と、を抽出可能な情報が含まれる、請求項１乃至４のいずれか一項に記載のサーバ。
【請求項６】
前記集約確認応答に格納されたデータを前記第１及び第２の端末が不使用とする指示を含める、請求項１乃至５のいずれか一項に記載のサーバ。
【請求項７】
前記複数の端末はグループ分けされており、
前記集約確認応答の送信先となる端末の組み合わせに応じて定まるグループを宛先とし前記集約確認応答を送信する、請求項１乃至３のいずれか一項に記載のサーバ。
【請求項８】
複数の端末と、
前記複数の端末のうち第１及び第２の端末それぞれからのデータ送信に対して確認応答を送信するサーバと、
を含み、
前記サーバは、
前記第１及び第２の端末の受信スロットを開くタイミングが実質的に同一となるように、前記第１及び第２の端末を制御し、
前記第１及び第２の端末が共に受信スロットを開いている間に、前記第１及び第２の端末に共通な集約確認応答を送信する、通信システム。
【請求項９】
複数の端末のうち第１及び第２の端末それぞれからのデータ送信に対して確認応答を送信するサーバにおいて、
前記第１及び第２の端末の受信スロットを開くタイミングが実質的に同一となるように、前記第１及び第２の端末を制御し、
前記第１及び第２の端末が共に受信スロットを開いている間に、前記第１及び第２の端末に共通な集約確認応答を送信する、通信方法。
【請求項１０】
複数の端末のうち第１及び第２の端末それぞれからのデータ送信に対して確認応答を送信するサーバに搭載されたコンピュータに、
前記第１及び第２の端末の受信スロットを開くタイミングが実質的に同一となるように、前記第１及び第２の端末を制御する処理と、
前記第１及び第２の端末が共に受信スロットを開いている間に、前記第１及び第２の端末に共通な集約確認応答を送信する処理と、
を実行させるプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
［関連出願についての記載］
本発明は、日本国特許出願：特願２０１８−０６６０２４号（２０１８年  ３月２９日出願）の優先権主張に基づくものであり、同出願の全記載内容は引用をもって本書に組み込み記載されているものとする。
本発明は、サーバ、通信システム、通信方法及びプログラムに関する。
【背景技術】
【０００２】
近年のネットワーク技術、情報処理技術の進展と共に、各種産業におけるサービス運用を効率化させるための取り組みがなされている。具体的には、電力計測計等のメータや気温等を測定するセンサに通信機能を持たせ、これらのデバイスから情報収集するシステムが増加している。とりわけ、水道メータやガスメータ等に通信機能を持たせたスマートメータの導入が進められており、検針の効率性が大幅に改善しつつある。【０００３】
このような状況の下、スマートメータ等の利用をより一層拡大させていくことが検討されている。例えば、スマートメータ等の情報収集に無線通信を利用する取り組みが進められている。【０００４】
特に、免許が不要で無線電波の到達距離が数キロメートルにも達する省電力広域無線通信（ＬＰＷＡ；Low Power Wide Area）を利用したデータ通信が進みつつある。なお、省電力広域無線通信の規格には、ＬＯＲＡ（ＬｏＲａＷＡＮ；ローラワン）、Ｗｉ−ＳＵＮ（Wireless Smart Utility Network）等が存在する。省電力広域無線通信は、主に９００ＭＨｚ帯を使用し広いエリアへの電波到達を実現しつつ、良好な通信感度を有することで送信電力を低く抑えることで低消費電力の運用も実現する。【０００５】
特許文献１には、下りのマルチキャスト、ブロードキャストに対する上りの確認応答を集約する通信システムが開示されている。また、特許文献２には、パケットを集約する無線通信システムが開示され、特許文献３には、チャネルアグリゲーションを行う無線通信システムが開示されている。特許文献４には、複数の端末に対して基地局が確認応答を返信することで複数の確認応答を１つのフレームに格納し送信する技術が開示されている。
【先行技術文献】
【特許文献】
【０００６】
【特許文献１】特許第３９６１３５１号公報
【特許文献２】特表２００７−５２５０９２号公報
【特許文献３】特許第５９８６２４４号公報
【特許文献４】特表２０１８−５０６２３１号公報
【発明の概要】
【発明が解決しようとする課題】
【０００７】
上述のように、省電力広域無線通信の利用が拡大しているが、当該無線通信では、使用する周波数帯域が厳しく制限されており、数百ｂｐｓ（ビット毎秒）から数キロｂｐｓ程度の通信速度が得られるに留まる。【０００８】
その上、省電力広域無線通信では電波の利用方法は法律により規定されている。例えば、日本国内では、キャリアセンス時間が５ｍｓ未満の場合には１時間あたりの送信時間の総和が３６０秒以下とすることが求められている。さらに、諸外国では、上記制限よりもより厳しい制限が課されている例もある。【０００９】
上記制限を遵守するため、スマートメータ等と無線接続するゲートウェイ（無線ゲートウェイ）は、種々の対応を行っている。例えば、複数のスマートメータを収容するゲートウェイは、これらのスマートメータからデータを収集し、当該スマートメータから送信されたデータに対する確認応答（ＡＣＫ；ACKnowledgement）の送信を保留するといった対応が行われる。【００１０】
しかし、このようなデータ送信制御にも限界があり、場合によっては、スマートメータ等に送信されるＡＣＫパケット（ＡＣＫフレーム）が消滅する可能性もある。詳細は後述するが、省電力広域無線通信に対応する端末（以下、単に端末と表記する）は、データフレームを送信するとアイドル状態に遷移し、電力消費を抑制する。端末は、所定期間が経過すると受信待ち状態に遷移し、ＡＣＫフレームを受信可能状態とする。当該所定期間にＡＣＫフレームが受信できなければ、端末は、再びアイドル状態に遷移する。その後、端末は、所定期間経過後に再び受信待ち状態に遷移し、ＡＣＫフレームを受信可能状態とする。【００１１】
このように、端末は、２回の受信スロットを開き、いずれかの受信スロットにてＡＣＫフレームを受信する。端末は、２つの受信スロットのいずれかにて、ＡＣＫフレームを受信できなければデータの再送処理等を行う。【００１２】
ここで、一台のゲートウェイに複数の端末が無線接続する場合がある。図２０は、２台の端末によるＬｏＲａＷＡＮ  ＣｌａｓｓＡでのデータ転送の概略を示す図である。図２０に示すように、２台の端末それぞれからのデータ送信に対し、各端末は、２回の受信スロットをそれぞれ開く。その際、２台の端末とゲートウェイのそれぞれの無線送信はキャリアセンスにより衝突回避されており、送信時刻が重ならないように制御される。【００１３】
つまり、ゲートウェイでは、各端末の受信スロットが開いている間に、他の端末向けのＡＣＫフレームが衝突しないように、ＡＣＫフレームを送信する。従って、端末の台数や通信状況によっては、ゲートウェイは各端末が開く受信スロットの間にＡＣＫフレームを送信できない可能性がある。【００１４】
即ち、一台のゲートウェイに複数の端末が接続されている場合には、ゲートウェイは、定められた期間にＡＣＫフレームを送信できないことがある。その場合、ゲートウェイは、内部のバッファに送信できなかったＡＣＫフレームを蓄積する。しかし、ゲートウェイにて記憶しきれない量のＡＣＫフレーム（送信待ちのＡＣＫフレーム）が蓄積されると、本来スマートメータに送信されるデータが消失してしまう。【００１５】
なお、当該問題は上記特許文献１を適用しても解決することはできない。例えば、特許文献１は、上りの確認応答（ＡＣＫ）を集約することを開示するが、省電力広域無線通信にて問題になるのは受信待ち受け時間が制限される下りのデータ送信（ＡＣＫ送信）の場合だからである。【００１６】
本発明は、省電力広域無線通信におけるＡＣＫフレームの送信を効率的に行うことに寄与する、サーバ、通信システム、通信方法及びプログラムを提供することを主たる目的とする。
【課題を解決するための手段】
【００１７】
本発明乃至開示の第１の視点によれば、複数の端末のうち第１及び第２の端末それぞれからのデータ送信に対して確認応答を送信し、前記第１及び第２の端末の受信スロットを開くタイミングが実質的に同一となるように、前記第１及び第２の端末を制御し、前記第１及び第２の端末が共に受信スロットを開いている間に、前記第１及び第２の端末に共通な集約確認応答を送信する、サーバが提供される。【００１８】
本発明乃至開示の第２の視点によれば、複数の端末と、前記複数の端末のうち第１及び第２の端末それぞれからのデータ送信に対して確認応答を送信するサーバと、を含み、前記サーバは、前記第１及び第２の端末の受信スロットを開くタイミングが実質的に同一となるように、前記第１及び第２の端末を制御し、前記第１及び第２の端末が共に受信スロットを開いている間に、前記第１及び第２の端末に共通な集約確認応答を送信する、通信システムが提供される。【００１９】
本発明乃至開示の第３の視点によれば、複数の端末のうち第１及び第２の端末それぞれからのデータ送信に対して確認応答を送信するサーバにおいて、前記第１及び第２の端末の受信スロットを開くタイミングが実質的に同一となるように、前記第１及び第２の端末を制御し、前記第１及び第２の端末が共に受信スロットを開いている間に、前記第１及び第２の端末に共通な集約確認応答を送信する、通信方法が提供される。【００２０】
本発明乃至開示の第４の視点によれば、複数の端末のうち第１及び第２の端末それぞれからのデータ送信に対して確認応答を送信するサーバに搭載されたコンピュータに、前記第１及び第２の端末の受信スロットを開くタイミングが実質的に同一となるように、前記第１及び第２の端末を制御する処理と、前記第１及び第２の端末が共に受信スロットを開いている間に、前記第１及び第２の端末に共通な集約確認応答を送信する処理と、を実行させるプログラムが提供される。
なお、このプログラムは、コンピュータが読み取り可能な記憶媒体に記録することができる。記憶媒体は、半導体メモリ、ハードディスク、磁気記録媒体、光記録媒体等の非トランジェント（non-transient）なものとすることができる。本発明は、コンピュータプログラム製品として具現することも可能である。
【発明の効果】
【００２１】
本発明乃至開示の各視点によれば、省電力広域無線通信におけるＡＣＫフレームの送信を効率的に行うことに寄与する、サーバ、通信システム、通信方法及びプログラムが、提供される。
【図面の簡単な説明】
【００２２】
【図１】一実施形態の概要を説明するための図である。
【図２】第１の実施形態に係る通信システムの概略構成の一例を示す図である。
【図３】第１の実施形態に係る端末が送受信するフレームの一例を示す図である。
【図４】端末のフレーム送受信動作を説明するための図である。
【図５】端末とネットワークサーバの動作を説明するための図である。
【図６】端末とネットワークサーバの動作を説明するための図である。
【図７】第１の実施形態に係る端末の処理構成の一例を示す図である。
【図８】第１の実施形態に係るゲートウェイの処理構成の一例を示す図である。
【図９】第１の実施形態に係るネットワークサーバの処理構成の一例を示す図である。
【図１０】第１の実施形態に係るネットワークサーバの動作を説明するための図である。
【図１１】端末ＩＤ、パケット番号及び集約ＩＤの関係を示す図である。
【図１２】第１の実施形態に係るアプリケーションサーバの処理構成の一例を示す図である。
【図１３】第１の実施形態に係るネットワークサーバのハードウェア構成の一例を示す図である。
【図１４】第１の実施形態に係る端末のハードウェア構成の一例を示す図である。
【図１５】第１の実施形態に係る通信システムの動作の一例を示すシーケンス図である。
【図１６】第２の実施形態に係る端末のグループ分けを説明するための図である。
【図１７】端末によるデータ送受信の一例を示す図である。
【図１８】端末によるデータ送受信の一例を示す図である。
【図１９】端末によるデータ送受信の一例を示す図である。
【図２０】２台の端末によるＬｏＲａＷＡＮ  ＣｌａｓｓＡでのデータ転送の概略を示す図である。
【発明を実施するための形態】
【００２３】
初めに、一実施形態の概要について説明する。なお、この概要に付記した図面参照符号は、理解を助けるための一例として各要素に便宜上付記したものであり、この概要の記載はなんらの限定を意図するものではない。また、各図におけるブロック間の接続線は、双方向及び単方向の双方を含む。一方向矢印については、主たる信号（データ）の流れを模式的に示すものであり、双方向性を排除するものではない。さらに、本願開示に示す回路図、ブロック図、内部構成図、接続図などにおいて、明示は省略するが、入力ポート及び出力ポートが各接続線の入力端及び出力端のそれぞれに存在する。入出力インターフェイスも同様である。
【００２４】
一実施形態に係るサーバ１００（図１参照）は、複数の端末のうち第１及び第２の端末それぞれからのデータ送信に対して確認応答を送信する。サーバ１００は、第１及び第２の端末の受信スロットを開くタイミングが実質的に同一となるように、第１及び第２の端末を制御する。サーバ１００は、第１及び第２の端末が共に受信スロットを開いている間に、第１及び第２の端末に共通な集約確認応答を送信する。
【００２５】
上記サーバ１００は、第１及び第２の端末からデータを受信したことを示す確認応答を返信する際、端末１０が受信待ち状態になるタイミングが実質的に同タイミングとなるように調整する。その上で、サーバ１００は、第１及び第２の端末向けの確認応答を集約し、当該集約した確認応答を端末に送信する。このように、サーバ１００は、複数の端末に向けて送信する確認応答を集約し、当該集約した確認応答を１回の送信で各端末に通知する。その結果、サーバ１００から端末に送信されるフレームの総量が削減され、無線通信、とりわけ、省電力広域無線通信におけるＡＣＫフレームの送信を効率的に行うことができる。
【００２６】
以下に具体的な実施の形態について、図面を参照してさらに詳しく説明する。なお、各実施形態において同一構成要素には同一の符号を付し、その説明を省略する。
【００２７】
［第１の実施形態］
第１の実施形態について、図面を用いてより詳細に説明する。
【００２８】
図２は、第１の実施形態に係る通信システムの概略構成の一例を示す図である。図２を参照すると、第１の実施形態に係る通信システムには、端末１０−１〜１０−４と、ゲートウェイ２０−１及び２０−２と、ネットワークサーバ３０と、アプリケーションサーバ４０−１及び４０−２と、が含まれる。
【００２９】
なお、以降の説明において、端末１０−１〜１０−４を区別する特段の理由がない場合には、単に「端末１０」と表記する。他の構成についても同様に、ハイフンの左側の数字にて当該構成を代表して表記する。
【００３０】
端末１０は、センサからデータを収集し、自装置を識別するための端末ＩＤ（Identifier）とセンサデータを含むデータフレームをゲートウェイ２０に向けて送信する。
【００３１】
端末１０に対して無線接続を提供するゲートウェイ２０は、端末１０が送信したデータフレームを受信し、当該データフレームを含むデータパケットをネットワークサーバ３０に向けて送信する。
【００３２】
ネットワークサーバ３０は、ゲートウェイ２０が送信するデータパケットを受信する。ネットワークサーバ３０は、データパケットに格納されたセンサデータ等を参照し、センサデータを送信した端末１０に対応するアプリケーションサーバ４０にデータパケットを転送する。
【００３３】
アプリケーションサーバ４０は、ネットワークサーバ３０から送信されるデータパケットを受信し、ＩｏＴ（Internet of Things）サービスを実現する。アプリケーションサーバ４０が収集するデータには、例えば、気象観測データ、道路混雑状況、電気／ガス／水道の使用状況等のデータが想定される。
【００３４】
アプリケーションサーバ４０は、データパケットを正常に受信できると、センサデータを送信した端末１０の端末ＩＤ及び当該端末１０用のＡＣＫデータを含むＡＣＫパケットを生成し、ネットワークサーバ３０に送信する。
【００３５】
ネットワークサーバ３０は、ＡＣＫパケットを受信し、データパケットを送信した端末１０と接続されているゲートウェイ２０に向けてＡＣＫパケットを転送する。
【００３６】
ゲートウェイ２０は、ＡＣＫパケットを受け取り、端末１０からのデータ送信に対するＡＣＫフレームを送信する。
【００３７】
なお、図２に示すシステム構成は例示であって、通信システムの構成を限定する趣旨ではない。例えば、ゲートウェイ２０やアプリケーションサーバ４０は１台であってもよいし、３台以上であってもよい。あるいは、複数のゲートウェイ２０が一台の端末１０からのデータを受信してもよい。また、ゲートウェイ２０とネットワークサーバ３０は同一のドメインに設置されていても良いし、インターネット等の広域網を介して接続されていてもよい。
【００３８】
以降の説明では、アプリケーションサーバ４０が端末１０からのデータ送信に対して確認応答（ＡＣＫ）を生成し、ネットワークサーバ３０がＡＣＫパケットをゲートウェイに転送する場合について説明する。しかし、ネットワークサーバ３０がデータパケットの内容を確認し、アプリケーションサーバ４０に対して送信するため、ネットワークサーバ３０が端末１０からのデータ送信に対する確認応答を生成してもよい。つまり、端末１０をセンサデータ等の送信端末（送信ノード）とすれば、ネットワークサーバ３０は受信端末（受信ノード、受信サーバ）となる。
【００３９】
初めに、端末１０のフレーム送受信に係る動作を図面を参照しつつ説明する。端末１０は、センサデータを収集し、当該センサデータを含むデータフレームを定期的にゲートウェイ２０に送信する。
【００４０】
例えば、端末１０は、図３（ａ）に示すような構造のデータフレームを送信する。図３（ａ）に示すように、端末１０が送信するデータフレームには、当該端末１０に割り当てられた端末ＩＤとパケット番号、センサデータを格納したペイロードが含まれる。
【００４１】
端末１０は、図３（ａ）に示すようなデータフレームを所定の間隔（例えば、１０分ごと）にゲートウェイ２０に送信する（図４（ａ）参照）。
【００４２】
端末１０は、データフレームを送信するとアイドル状態（スリープ状態）に遷移する。端末１０は、その後、所定期間が経過するとアイドル状態から復帰し、ゲートウェイ２０からのＡＣＫフレームを受信できる状態（受信待ち状態）に遷移する。具体的には、図４（ｂ）に示すように、端末１０は、データフレームの送信終了時刻Ｔ１１から所定期間（ＲＤ１；Receive Delay 1）経過するまでアイドル状態となり、時刻Ｔ１２にて受信待ち状態に遷移する。
【００４３】
端末１０は、受信待ち状態に復帰してから所定期間（ＲＷ；Receive Window）の間、ゲートウェイ２０からのＡＣＫフレームが受信可能となる。
【００４４】
端末１０は、この間にＡＣＫフレーム（アプリケーションサーバ４０からのＡＣＫデータ）を受信できれば、先に送信したデータフレームはアプリケーションサーバ４０にて正常に受信できたものとしてフレーム送信処理を完了する。
【００４５】
一方、当該期間に確認応答を受信できなければ、端末１０は再びアイドル状態に遷移する。端末１０は、先にデータフレームを送信した時刻Ｔ１１から所定期間（ＲＤ２；Receive Delay 2）経過するまでアイドル状態となり、時刻Ｔ１３にて受信待ち状態に復帰する（図４（ｂ）参照）。端末１０は、通常動作に復帰してから所定期間（ＲＷ；Receive Window）の間、ゲートウェイ２０からのＡＣＫフレームが受信可能となる。
【００４６】
なお、図４を含む図面においてゲートウェイ２０が端末１０に送信するＡＣＫフレームを「ＲＸ」と表記する。
【００４７】
端末１０は、ＡＣＫフレームを受信できれば、先に送信したフレームはアプリケーションサーバ４０にて正常に受信できたものとしてフレーム送信処理を完了する。一方、当該期間にＡＣＫフレームを受信できなければ、端末１０は、データフレームの再送処理等を行う。
【００４８】
このように、端末１０は、１回の送信スロット（１回のデータ送信）に対し、２回の受信スロットを設け、ゲートウェイ２０からのＡＣＫフレームを受信する。
【００４９】
なお、端末１０は、図３（ｂ）に示すようなＡＣＫフレームを受信する。端末１０は、ＡＣＫフレームの端末ＩＤやＡＣＫデータに基づき、自装置からのデータ送信が正常に処理されたか否かを判断する。
【００５０】
また、ネットワークサーバ３０は、アプリケーションサーバ４０から取得したＡＣＫパケットに端末１０に対する指示やデータ等を含めることも可能である。具体的には、ネットワークサーバ３０は、図３（ｂ）に示すＡＣＫデータに指示内容等を追記すればよい。
【００５１】
以降の説明において、端末１０がデータフレームを送信してから初回の受信スロットを開くまでの所定期間ＲＤ１を「第１復帰期間」又は単に「ＲＤ１」と表記する。同様に、端末１０がデータフレームを送信してから２回目の受信スロットを開くまでの所定期間ＲＤ２を「第２復帰期間」又は単に「ＲＤ２」と表記する。また、初回の受信スロット（第１受信スロット）をＲＸ１、２回目の受信スロット（第２受信スロット）をＲＸ２と表記する。
【００５２】
次に、図面を参照しつつ、第１の実施形態に係る通信システムの動作概略を説明する。
【００５３】
ネットワークサーバ３０は、データフレームを送信した端末１０に対して第１復帰期間と第２復帰期間を指定し、当該指定された期間経過後に受信スロットを開くように指示する。端末１０がゲートウェイ２０に送るデータフレームの形式や送信間隔（送信インターバル）に関しては、図３、図４を参照して説明したとおりである。
【００５４】
端末１０は、ネットワークサーバ３０から指示された２つの復帰時間（ＲＤ１、ＲＤ２）に基づき、ゲートウェイ２０からのＡＣＫフレーム送信に備える。具体的には、図５に示す第１復帰期間（ＲＤ１）と第２復帰期間（ＲＤ２）がネットワークサーバ３０から指示されるので当該指示に従いアイドル状態からの復帰とＡＣＫフレームの受信を行う。
【００５５】
ネットワークサーバ３０は、複数の端末１０それぞれが受信スロットを開くタイミングが実質的に同時刻となるように各端末１０における２つの復帰期間（ＲＤ１、ＲＤ２）を決定する。例えば、図５を参照すると、端末１０−１〜１０−３それぞれが、異なる時刻にてデータフレームを送信する。この場合、ネットワークサーバ３０から端末１０に復帰期間の指示がなければ、各端末１０は予め定めた復帰期間経過後に受信スロットを開くことになる。
【００５６】
ネットワークサーバ３０からの指示を受信した端末１０は、ネットワークサーバ３０からの指示に従い受信スロットを開く。ネットワークサーバ３０は、端末１０−１〜１０−３が同じタイミングにて受信スロットを開くように、各端末１０に２つの復帰期間（ＲＤ１、ＲＤ２）を指示する。その結果、図５に示すように、複数の端末１０が開く受信スロットが一致する。
【００５７】
ネットワークサーバ３０は、ゲートウェイ２０に接続された複数の端末１０に向けてアプリケーションサーバ４０から送信されたＡＣＫパケットを１つにまとめた集約ＡＣＫパケットを生成する。集約ＡＣＫパケットには、各端末１０向けのＡＣＫデータと「端末ＩＤ」に変わる集約ＡＣＫＩＤが含まれる。例えば、図５の例では、図６（ａ）に示すような集約ＡＣＫパケットが生成される。
【００５８】
ネットワークサーバ３０は、集約ＡＣＫパケットをゲートウェイ２０（複数の端末１０が接続されたゲートウェイ２０）に送信する。ゲートウェイ２０は、集約ＡＣＫパケットのＩＰ（Internet protocol）ヘッダを外し、集約ＡＣＫフレームを端末１０に送信する。より具体的には、ゲートウェイ２０は、同時に開かれている受信スロットにおいて、複数の端末１０からのデータ送信に対する集約ＡＣＫフレーム（図６（ｂ）参照）を端末１０に送信する。
【００５９】
各端末１０は、集約ＡＣＫフレームを受信し、当該集約ＡＣＫフレームに自装置宛ての確認応答（ＡＣＫ）か否かを判断する。各端末１０は、自装置向けの確認応答であれば、先に送信したデータフレームは正常に受信されたと判断する。各端末１０は、自装置向けの確認応答でなければ、取得した集約ＡＣＫフレームを破棄する。
【００６０】
なお、ゲートウェイ２０は、一度も復帰期間（ＲＤ１、ＲＤ２）を指示していない端末１０に対しては、集約ＡＣＫパケット（集約ＡＣＫフレーム）を送信することなく、図３（ｂ）に示す通常のＡＣＫフレームを送信する。その際に、ゲートウェイ２０は、上記復帰期間を端末１０に通知することができる。
【００６１】
上記集約ＡＣＫフレーム、集約ＡＣＫＩＤ等の詳細は後述する。
【００６２】
このように、第１の実施形態に係る通信システムでは、複数の端末１０と、ネットワークサーバ３０と、が含まれ、ネットワークサーバ３０は、当該複数の端末１０のうち第１及び第２の端末それぞれからのデータ送信に対して確認応答を送信する。その際、ネットワークサーバ３０は、第１及び第２の端末の受信スロットを開くタイミングが実質的に同一となるように、第１及び第２の端末を制御する。さらに、ネットワークサーバ３０は、第１及び第２の端末が共に受信スロットを開いている間に、第１及び第２の端末に共通な集約確認応答（集約ＡＣＫパケット）を送信する。
【００６３】
続いて、通信システムを構成する各装置の詳細を説明する。
【００６４】
図７は、端末１０の処理構成（処理モジュール）の一例を示す図である。図７を参照すると、端末１０は、アプリケーション処理部２０１と、無線通信処理部２０２と、を含んで構成される。
【００６５】
アプリケーション処理部２０１は、端末１０に内蔵された（又は、端末１０に接続された）センサ等から取得したデータを無線通信処理部２０２に引き渡す。
【００６６】
無線通信処理部２０２は、当該センサデータをデータフレームに格納し、ゲートウェイ２０に送信する。また、無線通信処理部２０２は、ゲートウェイ２０を介してネットワークサーバ３０からデータ送信に対するＡＣＫパケットを受信する。
【００６７】
無線通信処理部２０２は、送信部２１１と、受信部２１２と、フレーム処理部２１３と、を含んで構成される。
【００６８】
送信部２１１は、アプリケーション処理部２０１から取得したセンサデータからゲートウェイ２０に向けて送信するデータフレームを生成し、送信する。その際、送信部２１１は、図３（ａ）に示すような端末ＩＤ、パケット番号を含むフレームを生成する。第１の実施形態では、端末ＩＤ及びパケット番号のサイズは共に８ビットとする。
【００６９】
端末１０は、データフレームの送信から所定期間（ＲＤ１、ＲＤ２）経過するまでの間アイドル状態に遷移する。当該期間が経過すると端末１０は、ＡＣＫフレームの受信待ち状態に遷移する（受信スロットを開く）。
【００７０】
受信部２１２は、当該受信待ち状態にて、ゲートウェイ２０から送信されるＡＣＫフレームを受信する。受信部２１２は、受信したＡＣＫフレームをフレーム処理部２１３に引き渡す。
【００７１】
フレーム処理部２１３は、受信したＡＣＫフレームを確認し、当該ＡＣＫフレームが自装置向けか否かを判定する。ここで、取得したＡＣＫフレームが通常のフレーム（集約ＡＣＫＩＤを含まないフレーム）の場合、フレーム処理部２１３は、取得したＡＣＫフレームの端末ＩＤと自装置の端末ＩＤを比較し、上記判定を行う。
【００７２】
一方、取得したＡＣＫフレームが集約ＡＣＫフレームの場合、フレーム処理部２１３は、集約ＡＣＫＩＤに対して所定の論理演算を行い、上記判定を行う。なお、フレーム処理部２１３による上記所定の論理演算は、集約ＡＣＫＩＤの生成と関係するので集約ＡＣＫＩＤの生成と共に後述する。
【００７３】
フレーム処理部２１３は、取得したＡＣＫフレームが自装置向けであれば、取得したＡＣＫフレームをアプリケーション処理部２０１に引き渡す。
【００７４】
受信部２１２は、取得したＡＣＫフレームにネットワークサーバ３０からの指示（第１及び第２復帰期間に関する指示）が含まれている場合には、当該指示された復帰期間を記憶する。受信部２１２は、今後発生するデータフレームの送信に対応する受信スロットを取得した復帰期間に応じて開く。
【００７５】
図８は、ゲートウェイ２０の処理構成（処理モジュール）の一例を示す図である。図８を参照すると、ゲートウェイ２０は、無線通信処理部３０１と、通信処理部３０２と、ネットワーク処理部３０３と、を含んで構成される。
【００７６】
無線通信処理部３０１は、端末１０との間の無線通信を制御する。無線通信処理部３０１は、端末１０からのデータフレームを受信し、当該受信したデータフレームをネットワーク処理部３０３に引き渡す。無線通信処理部３０１は、ネットワーク処理部３０３から取得したＡＣＫパケットによりＡＣＫフレームを生成し、端末１０に向けて送信する。
【００７７】
通信処理部３０２は、ネットワークサーバ３０との間の通信を制御する。通信処理部３０２は、ネットワーク処理部３０３からのデータをデータパケットに格納し、ネットワークサーバ３０に向けて送信する。通信処理部３０２は、ネットワークサーバ３０からＡＣＫパケットを受信し、ネットワーク処理部３０３に引き渡す。
【００７８】
ネットワーク処理部３０３は、無線通信処理部３０１と通信処理部３０２の間のデータ転送を制御する。
【００７９】
図９は、ネットワークサーバ３０の処理構成（処理モジュール）の一例を示す図である。図９（ａ）を参照すると、ネットワークサーバ３０は、第１通信処理部４０１と、第２通信処理部４０２と、ネットワーク処理部４０３と、を含んで構成される。
【００８０】
第１通信処理部４０１は、ゲートウェイ２０との間でパケットを送受信する。
【００８１】
第２通信処理部４０２は、アプリケーションサーバ４０との間でパケットを送受信する。
【００８２】
ネットワーク処理部４０３は、第１通信処理部４０１と第２通信処理部４０２の間のデータ転送を制御する。
【００８３】
図９（ｂ）に示すように、第１通信処理部４０１は、送信部４１１と、受信部４１２と、端末管理部４１３と、集約データ処理部４１４と、記憶部４１５と、を含んで構成される。
【００８４】
記憶部４１５は、各種テーブル（テーブル情報）を保持する。記憶部４１５が保持する情報は、端末１０に関する詳細情報（端末管理テーブル）と、受信したパケットに関する情報（パケットテーブル）と、が含まれる。
【００８５】
端末管理テーブルには、各端末１０の端末ＩＤ、各端末１０のデータ送信間隔、各端末１０の復帰期間（ＲＤ１、ＲＤ２）等に関する情報が含まれる。なお、端末ＩＤや送信間隔は、システム管理者等が予めネットワークサーバ３０に入力する。また、ネットワークサーバ３０から端末１０に対して一度も復帰期間（ＲＤ１、ＲＤ２）の指示をしていない場合には、当該フィールドには初期値（デフォルト値）が設定される。
【００８６】
パケットテーブルは、ゲートウェイ２０を介して取得したデータパケットの詳細を記憶する。パケットテーブルには、データパケット（データフレーム）を送信した端末の端末ＩＤ、当該データパケットに記載されたパケット番号、当該データパケットを受信した時刻等に関する情報が含まれる。
【００８７】
送信部４１１は、データパケット、ＡＣＫパケットを送信する。
【００８８】
受信部４１２は、データパケット、ＡＣＫパケットを受信する。
【００８９】
受信部４１２は、ゲートウェイ２０からデータパケットを受信すると、取得したデータパケットの内容を確認し、記憶部４１５のパケットテーブルを更新する。
【００９０】
送信部４１１は、パケットテーブルに登録されたデータパケットに対応するＡＣＫパケット（集約ＡＣＫパケットを含む）を送信した場合には、当該データパケットのエントリをパケットテーブルから削除する。
【００９１】
なお、後述するように、パケットテーブルに記載された端末ＩＤとパケット番号を用いて集約ＡＣＫＩＤが計算される。受信部４１２は、パケットテーブルにエントリを追加する際に集約ＡＣＫＩＤを計算し、当該テーブルに格納してもよい。
【００９２】
端末管理部４１３は、複数の端末１０の受信スロットが同じタイミングにて開かれるように、各端末１０の復帰時間（ＲＤ１、ＲＤ２）を制御する。
【００９３】
ここで、送信部４１１は、ゲートウェイ２０に対して任意のタイミングにてＡＣＫパケットを送信するように設計されている。送信部４１１がＡＣＫパケットを送信するタイミングは、ネットワークサーバ３０が持つ時計により、任意の時間間隔で設定可能である。具体的には、送信部４１１は、定期的（例えば、数秒後ごと）に、ＡＣＫパケットを送信する。
【００９４】
端末管理部４１３は、各端末１０が、当該定期的に送信されるＡＣＫパケットを受信できるように、各端末１０に設定する復帰時間（ＲＤ１、ＲＤ２）を決定する。端末管理部４１３は、各端末１０のデータ送信間隔とデータパケットの受信時刻に関する情報から、当該端末１０が今後データ送信してくる時刻を予測することができる。
【００９５】
例えば、「１２：００：００」にデータパケットを受信し、送信間隔が１０分であれば、「１２：１０：００」、「１２：２０：００」といった時刻にデータパケットが送信されてくることが予測できる。端末管理部４１３は、今後送信されてくるであろうデータパケットに対する端末１０の受信スロットが開かれるタイミングと送信部４１１がＡＣＫパケットを送信するタイミングが一致するように、２つの復帰期間（ＲＤ１、ＲＤ２）を決定する。
【００９６】
具体的には、端末管理部４１３は、次に端末１０がデータ送信すると予測される送信時刻の直後に到来する送信タイミングの時刻から、上記予測したデータ送信時刻を減算し、得られる結果を第１復帰期間（ＲＤ１）とする。また、端末管理部４１３は、次に端末１０がデータ送信すると予測される送信時刻の直後の次に到来する送信タイミングの時刻から、上記予測したデータ送信時刻を減算し、得られる結果を第２復帰期間となる。
【００９７】
例えば、図１０を参照すると、端末１０が送信すると予測される時刻Ｔ３１の直後に到来する送信時刻Ｔ３２から予測される送信時刻Ｔ３１の差分（Ｔ３２−Ｔ３１）が第１復帰期間（ＲＤ１）となる。同様に、端末１０が送信すると予測される時刻Ｔ３１の直後の次に到来する送信時刻Ｔ３３から予測される送信時刻Ｔ３１の差分（Ｔ３３−Ｔ３１）が第２復帰期間となる。
【００９８】
端末管理部４１３は、このようにして算出した第１及び第２復帰期間を端末１０に通知する。なお、端末管理部４１３は、第１及び第２復帰期間をアプリケーションサーバ４０から取得したＡＣＫデータに追記し、ゲートウェイ２０経由で端末１０に通知する。
【００９９】
但し、当該通知を受信する前の端末１０は、送信部４１１が定期的に送信するタイミングにて受信スロットを開かないので、各種省電力広域無線通信の規格にて定められたタイミングで上記ＡＣＫデータを含むＡＣＫパケットを送信する。あるいは、端末管理部４１３は、端末１０との間で予め取り決めた制御パケット（オリジナルコマンド）を使って復帰期間を端末１０に通知してもよい。
【０１００】
このように、端末管理部４１３は、端末１０によるデータ送信間隔に基づき、各端末１０のそれぞれが受信スロットを開く時刻を決定する。より具体的には、端末管理部４１３は、端末１０がデータ送信した時刻と、データ送信間隔と、に基づき端末１０が次にデータ送信してくる時刻を予測する。その後、端末管理部４１３は、当該予測された送信時刻と、集約ＡＣＫパケットを送信するためにスケジュール化された送信時刻と、に基づき端末１０が受信スロットを開く時刻を決定する。
【０１０１】
集約データ処理部４１４は、ゲートウェイ２０に送信する集約ＡＣＫパケットに関する処理を行う。集約データ処理部４１４は、ネットワーク処理部４０３からの複数の端末１０宛のＡＣＫパケットを、１つのパケットに集約しゲートウェイ２０に送信する。
【０１０２】
上述のように、集約データ処理部４１４は、各端末１０向けのＡＣＫデータを連結して集約ＡＣＫパケットのデータ部分を生成する。集約データ処理部４１４は、記憶部４１５のパケットテーブルを参照し、アプリケーションサーバ４０から受信したＡＣＫパケットに対応するデータパケットを特定する。具体的には、集約データ処理部４１４は、受信したＡＣＫパケットに含まれる端末ＩＤと一致するエントリをパケットテーブルから検索し、上記データパケットを特定する。
【０１０３】
次に、集約データ処理部４１４は、端末１０の端末ＩＤと特定したデータパケットのパケット番号を利用し、集約ＡＣＫパケットに格納する集約ＡＣＫＩＤを生成する。例えば、集約データ処理部４１４は、端末ＩＤの下位３ビットとパケット番号の下位５ビットを連結し、１台の端末１０に対応する集約ＩＤを生成する。
【０１０４】
上記端末ＩＤの下位３ビットをＨｉ、パケット番号をＰｉと表記すると、集約ＩＤは、下記の式（１）のとおりとなる。
【０１０５】
［式１］
集約ＩＤ：ａｉ＝｛Ｈｉ、Ｐｉ｝
但し、ｉは正の整数であり、受信したデータパケットを特定するサフィックスである。ｎ（ｎは正の整数、以下同じ）個のデータパケットが受信された場合には、０≦ｉ≦ｎ−１となる。
【０１０６】
各端末１０から送信される端末ＩＤ、パケット番号、集約ＩＤの関係を例示すると図１１のとおりとなる。
【０１０７】
集約データ処理部４１４は、次回に到来するスケジュール化された送信時刻までに受信した全てのパケットの集約ＩＤ（ａ０、ａ１、・・・、ａｎ−１）を生成する。さらに、集約データ処理部４１４は、当該生成した集約ＩＤの総和（論理和）を計算し、得られた結果を集約ＡＣＫＩＤとする。集約ＡＣＫＩＤは下記の式（２）により得られる。
［式２］
2019189597.tif 000003
【０１０８】
集約データ処理部４１４は、図６（ａ）に示すような集約ＡＣＫパケットを生成する。なお、上記集約ＡＣＫＩＤや集約ＡＣＫパケットの生成は例示であって、種々の方法により集約ＡＣＫパケットを生成できる。例えば、データ送達確認の誤検出率を低減させるためにビット幅を拡張しても良い。あるいは、ブルームフィルタを用いた集約ＡＣＫパケットを作成しても良い。
【０１０９】
図１２は、アプリケーションサーバ４０の処理構成（処理モジュール）の一例を示す図である。図１２を参照すると、アプリケーションサーバ４０は、通信処理部５０１と、アプリケーション処理部５０２と、を含んで構成される。
【０１１０】
通信処理部５０１は、ネットワークサーバ３０との間でデータを送受信する。
【０１１１】
アプリケーション処理部５０２は、ネットワークサーバ３０とパケットを送受信する。また、アプリケーション処理部５０２は、通信処理部５０１からデータを受信し、当該データに関する集計処理等を実行する。その後、アプリケーション処理部５０２は、端末１０に対してデータの受信を確認するＡＣＫパケットを返信する。
【０１１２】
続いて、各装置のハードウェア構成について説明する。
【０１１３】
［ネットワークサーバのハードウェア構成］
図１３は、第１の実施形態に係るネットワークサーバ３０のハードウェア構成の一例を示す図である。ネットワークサーバ３０は図１３に例示する構成を備える。例えば、ネットワークサーバ３０は、内部バスにより相互に接続される、ＣＰＵ（Central Processing Unit）３１、メモリ３２、入出力インターフェイス３３及び通信インターフェイスであるＮＩＣ（Network Interface Card）３４等を備える。
【０１１４】
但し、図１３に示す構成は、ネットワークサーバ３０のハードウェア構成を限定する趣旨ではない。ネットワークサーバ３０は、図示しないハードウェアを含んでもよい。ネットワークサーバ３０に含まれるＣＰＵ等の数も図１３の例示に限定する趣旨ではなく、例えば、複数のＣＰＵ３１がネットワークサーバ３０に含まれていてもよい。
【０１１５】
メモリ３２は、ＲＡＭ（Random Access Memory）、ＲＯＭ（Read Only Memory）、補助記憶装置（ハードディスク等）等である。
【０１１６】
入出力インターフェイス３３は、図示しない入出力装置のインターフェイスである。入出力装置には、例えば、表示装置、操作デバイス等が含まれる。表示装置は、例えば、液晶ディスプレイ等である。操作デバイスは、例えば、キーボードやマウス等である。
【０１１７】
ネットワークサーバ３０の機能は、上述の処理モジュールにより実現される。当該処理モジュールは、例えば、メモリ３２に格納されたプログラムをＣＰＵ３１が実行することで実現される。また、そのプログラムは、ネットワークを介してダウンロードするか、あるいは、プログラムを記憶した記憶媒体を用いて、更新することができる。さらに、上記処理モジュールは、半導体チップにより実現されてもよい。即ち、上記処理モジュールが行う機能は、何らかのハードウェア、或いはハードウェアを利用して実行されるソフトウェアにより実現できればよい。
【０１１８】
［端末のハードウェア構成］
図１４は、第１の実施形態に係る端末１０のハードウェア構成の一例を示す図である。図１４に示すように、端末１０は、無線信号送受信回路１４を備える。無線信号送受信回路１４は、アンテナ（図示せず）に接続され、ゲートウェイ２０との間で無線通信を実現する。
【０１１９】
なお、ＣＰＵ１１、メモリ１２、入出力インターフェイス１３に関しては、図１３を参照しつつ説明した内容と同様とすることができるので説明を省略する。端末１０の機能もメモリ１２に格納されたプログラムをＣＰＵ１１が実行することで実現される。
【０１２０】
ゲートウェイ２０やアプリケーションサーバ４０のハードウェア構成は、ネットワークサーバ３０、端末１０等と同様とすることができ、当業者にとって明らかであるので説明を省略する。
【０１２１】
続いて、第１の実施形態に係る通信システムの動作について説明する。ここでは、端末１０とネットワークサーバ３０の動作を中心に説明する。
【０１２２】
図１５は、第１の実施形態に係る通信システムの動作の一例を示すシーケンス図である。なお、図１５に示す動作は、ネットワークサーバ３０に送信待ちのＡＣＫパケットは無い状態とする。また、図１５に示す動作は、各端末１０に対して復帰期間（ＲＤ１、ＲＤ２）の通知が終了しており、当該状態からパケットを受信した場合を示す。
【０１２３】
ステップＳ０１において、端末１０は、データフレームを送信する。ここでは、端末１０からｎ個のパケットが送信されたものとする。データフレームを送信した端末１０は、アイドル状態に遷移する。
【０１２４】
ネットワークサーバ３０は、データパケットを受信し、パケットテーブルを更新する（ステップＳ０２）。その際、ネットワークサーバ３０は、各パケットの集約ＩＤ（ａ０、ａ１、・・・、ａｎ−１）を計算し、記憶部４１５に格納してもよい。
【０１２５】
ステップＳ０３において、ネットワークサーバ３０は、予め定めた送信時刻（スケジュール化された送信時刻）が到来すると、各パケットの集約ＩＤから集約ＡＣＫＩＤを計算する。
【０１２６】
ステップＳ０４において、ネットワークサーバ３０は、計算した集約ＡＣＫＩＤを含む集約ＡＣＫパケットを生成し、ゲートウェイ２０を介して端末１０に送信する。
【０１２７】
当該ステップＳ０４のタイミングにおいて、各端末１０は、アイドル状態から復帰し、集約ＡＣＫフレームの到着を待つ（最初の受信スロットを開く；ステップＳ０５）。
【０１２８】
ステップＳ０６において、ネットワークサーバ３０は、次の送信タイミングにて集約ＡＣＫパケットを送信する。
【０１２９】
ステップＳ０５にてＡＣＫフレームを受信できなかった端末１０は、アイドル状態に遷移すると共に、ステップＳ０６のタイミングにてアイドル状態から復帰し、集約ＡＣＫフレームの到着を待つ（２回目の受信スロットを開く；ステップＳ０７）。
【０１３０】
ステップＳ０５又はステップＳ０７において、端末１０にて集約パケットを受信すると、端末１０は、集約ＡＣＫフレームに自装置向けのＡＣＫが含まれているか否かを判定する（集約フレームの確認；ステップＳ０８）。
【０１３１】
端末１０のフレーム処理部２１３は、集約ＡＣＫパケットに含まれる集約ＡＣＫＩＤと自身が送信したデータフレームに設定した端末ＩＤ及びパケット番号から生成した集約ＩＤの論理積Ｃを計算する（下記式（３）参照）。
［式３］
2019189597.tif 000004
式（３）において、Ａは集約ＡＣＫＩＤであり、ａｍ（ｍは正の整数、以下同じ）は端末１０が計算した集約ＩＤである。
【０１３２】
フレーム処理部２１３は、式（３）から得られる論理積Ｃと、自装置が送信したパケット番号と端末ＩＤから計算した集約ＩＤ  ａｍが一致した場合に、集約ＡＣＫＩＤを含む集約ＡＣＫフレームは自装置宛て（自装置のＡＣＫも含む）のＡＣＫであると判断する。つまり、この場合、フレーム処理部２１３は、送信したデータフレームはネットワークサーバ３０、アプリケーションサーバ４０にて正しく受信されていると判断する。
【０１３３】
一方、集約ＡＣＫＩＤと計算した集約ＩＤ  ａｍが一致しない場合には、フレーム処理部２１３は、当該ＡＣＫフレームは自装置向けではないと判断し、当該集約ＡＣＫフレームを破棄する。
【０１３４】
このように、集約ＡＣＫパケット（集約確認応答）には、格納されたデータの宛先となる端末１０を特定可能とする情報（集約ＡＣＫＩＤ）が含まれる。また、集約ＡＣＫＩＤは、端末ＩＤとパケット番号から生成され、式（３）を実行することにより、自装置の端末ＩＤとパケット番号からなる集約ＩＤを抽出することができる。即ち、集約ＡＣＫパケットには、格納されたデータの宛先（端末ＩＤ）と、送信されたデータを特定するためのデータ番号（パケット番号）と、を抽出可能な情報が含まれる。
【０１３５】
端末１０は、２回の受信スロットにて自装置向けの集約ＡＣＫフレームを受信できない場合には、先に送信したデータフレームはアプリケーションサーバ４０等にて正しく受信できていないと判断する。その場合、端末１０は、次回送信するフレームデータに欠落したデータ（センサデータ）を含める等の対応を行う。
【０１３６】
以上のように、第１の実施形態では、端末１０が送信したデータフレームに対してアプリケーションサーバ４０が当該データを受信したことを示す確認応答（ＡＣＫパケット）を返信する際、端末１０が受信待ち状態になるタイミングを調整する。より具体的には、ネットワークサーバ３０は、複数の端末１０による受信スロットを開くタイミングが揃うように各端末１０を制御する。
【０１３７】
さらに、ネットワークサーバ３０は、各端末１０向けのＡＣＫパケットを集約し、各端末１０にて同時刻に開かれた受信スロットにおいて当該集約した集約ＡＣＫパケットをゲートウェイ２０を介して端末１０に送信する。各端末１０は、ゲートウェイ２０から集約された集約ＡＣＫフレームを受信し、自装置向けのＡＣＫを抽出する。端末１０は、自装置向けのＡＣＫが抽出できれば、先に送信したデータは正しくアプリケーションサーバ４０により受理されたと判断する。
【０１３８】
このように、第１の実施形態では、ゲートウェイ２０から端末１０に向けて集約ＡＣＫフレームを送信するため、ゲートウェイ２０から端末１０に送信されるフレームの総量が削減される。また、各端末１０は、データフレームがアプリケーションサーバ４０に到着したことを判定することができるので、再送の必要性を判断でき、通信の高信頼化が実現される。
【０１３９】
上述のように、無線通信向けのフレームの集約方式が提案されており、例えば、Ｗｉ-Ｆｉ（Wireless Fidelity）のフレームアグリゲーション方式ではＷｉ-Ｆｉアクセスポイントにて複数のフレームをまとめて１つのフレームとして端末に送信する。しかし、これらの方式では、無線ゲートウェイから一台の端末に向けての送信にしか適用できない。また、マルチキャスト通信、あるいはブロードキャスト通信によって、複数の端末にデータを同時配信する通信方式がある。しかし、省電力広域無線通信では、端末はごく限られた時間にフレームの受信待ちをするため、同時配信技術を適用できない場合が多い。さらに、確認応答の返信にはそれぞれ異なる内容を返信する必要があるため、ブロードキャスト通信及びマルチキャスト通信の何れも適用できない。第１の実施形態に係る通信システムでは、複数の端末１０の受信スロットを同時に開き、且つ、各端末１０のＡＣＫを集約したフレーム（パケット）を送信するので、上記省電力広域無線通信に係る問題点を解決できる。
【０１４０】
［第２の実施形態］
続いて、第２の実施形態について図面を参照して詳細に説明する。
【０１４１】
第２の実施形態では、第１の実施形態にて説明した集約ＡＣＫＩＤに変えて、各端末１０をグループ分けして確認応答（ＡＣＫ）を集約する場合を説明する。
【０１４２】
第２の実施形態では、複数の端末１０を仮想ネットワークグループ、マルチキャストグループ等の仮想的なグループ分けを使用する。具体的には、端末１０−１〜１０−４を図１６に示すようにグループ分けする。図１６を参照すると、〇印は各グループに属することを示し、×印は各グループに属していないことを示す。
【０１４３】
集約データ処理部４１４は、集約ＡＣＫパケットの送信先となる端末１０の組み合わせに応じて定まるグループを宛先とし当該集約ＡＣＫパケットを送信する。より具体的には、集約データ処理部４１４は、ＡＣＫパケットを送信する端末１０の組み合わせによりグループを選択し、グループごとに定めたグループＩＤを含めＡＣＫパケットを送信する。例えば、図１６を参照すると、同じ送信タイミングにて、端末１０−３と端末１０−４に対するＡＣＫパケットを送信する場合には、グループ１（Ｇ１）を選択して当該グループ１のグループＩＤをＡＣＫパケットに設定する。
【０１４４】
各端末１０は、自装置が属するグループと対応するグループＩＤに関する情報を備え、ＡＣＫフレームに自装置が属するグループのグループＩＤが含まれるか否かに応じて、データフレームの受信が正常に行われたか否かを判定する。つまり、端末１０の無線通信処理部２０２は、仮想ネットワークグループやマルチキャストグループを識別する機能を有する。また、端末１０のアプリケーション処理部２０１は、受信したＡＣＫによりアプリケーションサーバ４０やネットワークサーバ３０に到達したデータを特定する機能を有する。
【０１４５】
以上のように、第２の実施形態では、ネットワークサーバ３０は、確認応答（ＡＣＫ）の送信先となる端末１０の組み合わせによってグループを選択し、決定したグループ宛にＡＣＫを送信する。その結果、端末１０による確認応答の判定処理を簡略化することができ、そのような簡易化した処理においても確認応答（ＡＣＫ）の集約を実現した通信を実施できる。
【０１４６】
［変形例］
上記実施形態にて説明した通信システムの構成、動作は例示であって、種々の変形が可能である。例えば、アプリケーションサーバ４０の機能をネットワークサーバ３０が兼ねることも可能である。
【０１４７】
また、図５では、各端末１０の初回の受信スロット（ＲＸ１）と２回目の受信スロット（ＲＸ２）が揃う場合を説明したが、各送信タイミングにて各端末１０の受信スロットは混在していてもよい（図１７参照）。つまり、受信スロット（ＲＸ１、ＲＸ２）を集約することも可能である。
【０１４８】
ネットワークサーバ３０は、複数のデータパケットに対して１つの受信スロットに関する制御をしてもよい。具体的には、ネットワークサーバ３０は、端末１０に対して、２つの復帰期間（ＲＤ１、ＲＤ２）のうちいずれか一方を指定してアイドル状態からの復帰を指示してもよい。
【０１４９】
別チャネルを使用したデータ送信に対して受信スロットを共通化してもよい（図１８参照）。なお、図１８では、データ送信（Ｔｒａｎｓｍｉｔ）や確認応答（ＲＸ）の上部にチャネル（ＣＨ）を記載している。
【０１５０】
ネットワークサーバ３０から端末１０に対する確認応答（ＡＣＫ）に格納して送信するデータがある通信の場合には、図１９に示すように、データを格納する最初の確認応答（ＡＣＫ）は集約せず、２回目の確認応答（ＡＣＫ）を集約しても良い。
【０１５１】
上記実施形態では、ネットワークサーバ３０からのゲートウェイ２０に対する制御については説明していないが、ネットワークサーバ３０は必要に応じてゲートウェイに対して制御パケットを送信し、その動作を制御してもよい。例えば、ネットワークサーバ３０は、集約ＡＣＫフレームの宛先となる全ての端末１０に到達できる送信電力を使用してフレーム送信するように、ゲートウェイ２０に指示をしてもよい。その際、ネットワークサーバ３０は、ゲートウェイ２０に対し、集約ＡＣＫフレームを送信する場合には出力が最大となるように指示してもよい。
【０１５２】
ネットワークサーバ３０は、ゲートウェイが許容できる確認応答送信数を考慮し、確認応答（ＡＣＫ）の送信数が許容数を超えると予想される場合に、集約ＡＣＫパケットを生成しても良い。例えば、一台のゲートウェイ２０に収容することが許容されている端末の数が「４」であり、当該ゲートウェイに既に３台の端末１０が接続されている場合に、ネットワークサーバ３０は集約ＡＣＫパケットを生成してもよい。このように、ネットワークサーバ３０は、ゲートウェイ２０に収容することが許容されている端末の数に基づき、集約ＡＣＫパケットを生成するか否かを判断してもよい。
【０１５３】
上記実施形態では、１つの集約ＡＣＫパケットに各端末１０向けのＡＣＫデータを含める場合を説明したが、各端末１０に送信するＡＣＫデータに相違点がない場合には、１つのＡＣＫデータを集約ＡＣＫパケットに含めても良い。
【０１５４】
ネットワークサーバ３０は、各端末１０向けの複数のＡＣＫデータを圧縮し、集約ＡＣＫフレームに格納してもよい。あるいは、ネットワークサーバ３０は、集約ＡＣＫパケットに格納されたＡＣＫデータがどの端末１０向けのデータであるかを示す情報を追加してもよいし、格納されたＡＣＫデータを無視するような指示を追加してもよい。つまり、ネットワークサーバ３０は、集約ＡＣＫパケットに格納されたデータを端末１０が不使用とする指示を、当該集約ＡＣＫパケットに含めることもできる。
【０１５５】
本願開示が対処する問題点、その解決方法及び効果をまとめると下記のとおりとなる。
【０１５６】
第１の問題は、端末１０が受信待ちをする時間が限られるため、ゲートウェイ（無線ゲートウェイ）２０から複数の端末１０に対して集約したＡＣＫの送信を端末１０が受信できないことである。当該問題を解決するため、本願開示では、端末１０がゲートウェイ２０からの確認応答を受信するために、受信待ち状態となる時刻を複数の端末１０に同期させる。その結果、端末１０が受信待ちをする時間が限られる際にも、ゲートウェイ２０から複数の端末１０に対して集約したＡＣＫの送信を端末が受信できる。
【０１５７】
第２の問題は、ゲートウェイ２０が複数の端末１０が受信待ち状態になっている時刻に集約したＡＣＫを送信できないことである。当該問題を解決するため、本願開示では、複数の端末１０宛の複数のＡＣＫ情報を集約して、端末１０が受信待ちとなっている時刻にゲートウェイ２０が端末１０に送信する。その結果、ゲートウェイ２０が複数の端末１０が受信待ち状態になっている時刻に集約したＡＣＫを送信できる。
【０１５８】
第３の問題は、端末１０が、ゲートウェイ２０が送信した複数の端末１０に対するＡＣＫの送信電力が適切でないため、送信電力が小さすぎる場合はＡＣＫを受信できないことである。当該問題を解決するため、本願開示では、ゲートウェイ２０は、集約ＡＣＫの宛先となる全ての端末１０に到達できる送信電力にて集約ＡＣＫを送信する。その結果、端末１０が、ゲートウェイ２０が送信した複数の端末１０に対するＡＣＫの送信電力が適切に設定でき、全ての端末１０がＡＣＫを受信できる。
【０１５９】
第４の問題は、ゲートウェイ２０からの送信数（端末１０の接続数）が、近い将来に許容されている送信数を超える見込みがわからないことである。当該問題を解決するため、ゲートウェイ２０が許容されている送信数が考慮され、許容数に達する見込みがある場合にＡＣＫを集約することが決定される。その結果、ゲートウェイ２０からの送信数が、近い将来に許容されている送信数を超える見込みがあるか予測できる。
【０１６０】
第５の問題は、端末１０が受信した集約ＡＣＫがどのデータに対する確認応答かわからないことである。当該問題を解決するため、本願開示では、集約されたＡＣＫに格納したデータに宛先を特定する情報を通信に含める。その結果、端末１０が受信した集約ＡＣＫがどのデータに対する確認応答なのか判定できる。
【０１６１】
第６の問題は、端末１０が集約されたＡＣＫの全てもしくは部分的に不必要な情報が含まれるのかわからないことである。当該問題を解決するため、本願開示では、集約されたＡＣＫに格納したデータを無視する指示を通信に含める。その結果、端末１０が集約されたＡＣＫの全てもしくは部分的に不必要な情報が含まれているのか判定できる。
【０１６２】
第７の問題は、実用においてＡＣＫ集約機能を全ての端末１０に実装することが難しい場合があることである。当該問題を解決するため、本願開示では、端末１０をグループ分けし、集約ＡＣＫの送信先の組み合わせに応じてグループを選択し通信する。その結果、実用において、多くの端末が有するグループ通信機能を利用して、ＡＣＫ集約機能を実現できる。
【０１６３】
上記の実施形態の一部又は全部は、以下の付記のようにも記載され得るが、以下には限られない。
［付記１］
上述の第１の視点に係るサーバのとおりである。
［付記２］
前記複数の端末に無線接続を提供するゲートウェイを介して前記集約確認応答を前記第１及び第２の端末に送信すると共に、
前記ゲートウェイに対して前記集約確認応答が前記第１及び第２の端末に到達可能な送信電力にて出力するように指示する、付記１に記載のサーバ。
［付記３］
前記ゲートウェイに収容することが許容されている端末の数に基づき、前記集約確認応答を生成するか否かを判断する、好ましくは付記２に記載のサーバ。
［付記４］
前記集約確認応答には、格納されたデータの宛先を特定可能とする情報が含まれる付記１乃至３のいずれか一に記載のサーバ。
［付記５］
前記集約確認応答には、格納されたデータの宛先と、送信されたデータを特定するためのデータ番号と、を抽出可能な情報が含まれる、付記１乃至４のいずれか一に記載のサーバ。
［付記６］
前記集約確認応答に格納されたデータを前記第１及び第２の端末が不使用とする指示を含める、付記１乃至５のいずれか一に記載のサーバ。
［付記７］
前記複数の端末はグループ分けされており、
前記集約確認応答の送信先となる端末の組み合わせに応じて定まるグループを宛先とし前記集約確認応答を送信する、付記１乃至３のいずれか一に記載のサーバ。
［付記８］
前記複数の端末それぞれは、１回のデータ送信に対して２回の受信スロットを開き、
前記２回の受信スロットそれぞれの開かれるタイミングが実質的に同一となるように前記第１及び第２の端末を制御する、付記１乃至７のいずれか一に記載のサーバ。
［付記９］
前記第１及び第２の端末によるデータ送信間隔に基づき、前記第１及び第２の端末のそれぞれが受信スロットを開く時刻を決定する、付記１乃至８のいずれか一に記載のサーバ。
［付記１０］
前記第１及び第２の端末がデータ送信した時刻と、前記データ送信間隔と、に基づき前記第１及び第２の端末が次にデータ送信してくる時刻を予測し、前記予測された送信時刻と、前記集約確認応答を送信するためにスケジュール化された送信時刻と、に基づき前記第１及び第２の端末が前記受信スロットを開く時刻を決定する、付記９に記載のサーバ。
［付記１１］
上述の第２の視点に係る通信システムのとおりである。
［付記１２］
上述の第３の視点に係る通信方法のとおりである。
［付記１３］
上述の第４の視点に係るプログラムのとおりである。
なお、付記１１〜１３の形態は、付記１の形態と同様に、付記２の形態〜付記１０の形態に展開することが可能である。
【０１６４】
なお、引用した上記の特許文献等の各開示は、本書に引用をもって繰り込むものとする。本発明の全開示（請求の範囲を含む）の枠内において、さらにその基本的技術思想に基づいて、実施形態ないし実施例の変更・調整が可能である。また、本発明の全開示の枠内において種々の開示要素（各請求項の各要素、各実施形態ないし実施例の各要素、各図面の各要素等を含む）の多様な組み合わせ、ないし、選択（非選択を含む）が可能である。すなわち、本発明は、請求の範囲を含む全開示、技術的思想にしたがって当業者であればなし得るであろう各種変形、修正を含むことは勿論である。特に、本書に記載した数値範囲については、当該範囲内に含まれる任意の数値ないし小範囲が、別段の記載のない場合でも具体的に記載されているものと解釈されるべきである。
【符号の説明】
【０１６５】
１０、１０−１〜１０−４  端末
１１、３１  ＣＰＵ（Central Processing Unit）
１２、３２  メモリ
１３、３３  入出力インターフェイス
１４  無線信号送受信回路
２０、２０−１、２０−２  ゲートウェイ
３０  ネットワークサーバ
３４  ＮＩＣ（Network Interface Card）
４０、４０−１、４０−２  アプリケーションサーバ
１００  サーバ
２０１、５０２  アプリケーション処理部
２０２、３０１  無線通信処理部
２１１、４１１  送信部
２１２、４１２  受信部
２１３  フレーム処理部
３０２、５０１  通信処理部
３０３、４０３  ネットワーク処理部
４０１  第１通信処理部
４０２  第２通信処理部
４１３  端末管理部
４１４  集約データ処理部
４１５  記憶部
【図１】
2019189597.tif 000005
【図２】
2019189597.tif 000006
【図３】
2019189597.tif 000007
【図４】
2019189597.tif 000008
【図５】
2019189597.tif 000009
【図６】
2019189597.tif 000010
【図７】
2019189597.tif 000011
【図８】
2019189597.tif 000012
【図９】
2019189597.tif 000013
【図１０】
2019189597.tif 000014
【図１１】
2019189597.tif 000015
【図１２】
2019189597.tif 000016
【図１３】
2019189597.tif 000017
【図１４】
2019189597.tif 000018
【図１５】
2019189597.tif 000019
【図１６】
2019189597.tif 000020
【図１７】
2019189597.tif 000021
【図１８】
2019189597.tif 000022
【図１９】
2019189597.tif 000023
【図２０】
2019189597.tif 000024
【国際調査報告】
2019189597.tif 000025
2019189597.tif 000026
2019189597.tif 000027
2019189597.tif 000028