(57)【要約】【課題】ゲートウェイとネットワークサーバとの間の通信路に流れる余計なデータトラフィックを抑制することができるようにする。【解決手段】本発明に係る通信装置は、複数の端末と、各端末を管理するサーバとの間で信号を中継する通信装置において、複数の端末のいずれかから受信した、サーバ宛の要求信号に含まれている端末識別情報を端末管理リストに登録する登録手段と、要求信号の受信後各端末の受信期間に応じた待機時間内に、要求信号に対する、サーバからの暗号化された応答信号の受信の有無を監視する監視手段と、監視手段による監視結果に応じて、各端末からサーバ宛の信号を遮断するか否かを設定する設定手段とを備えることを特徴とする。【選択図】      図１
2020028099.tif 000002
【特許請求の範囲】
【請求項１】
複数の端末と、上記各端末を管理するサーバとの間で信号を中継する通信装置において、
上記複数の端末のいずれかから受信した、上記サーバ宛の要求信号に含まれている端末識別情報を端末管理リストに登録する登録手段と、
上記要求信号の受信後上記各端末の受信期間に応じた待機時間内に、上記要求信号に対する、上記サーバからの暗号化された応答信号の受信の有無を監視する監視手段と、
上記監視手段による監視結果に応じて、上記各端末から上記サーバ宛の信号を遮断するか否かを設定する設定手段と
を備えることを特徴とする通信装置。
【請求項２】
上記監視手段が、
上記端末管理リストに登録した上記端末識別情報に、上記待機時間の待機状態であることを示す情報を対応付け、
上記待機時間内に上記応答信号の受信が無いときに、上記端末管理リストに登録した上記端末識別情報に、遮断することを示す情報を対応付け、
上記待機時間内に上記応答信号の受信が有るときに、上記端末管理リストから登録を削除する
ことを特徴とする請求項１に記載の通信装置。
【請求項３】
上記要求信号が、上記サーバによって管理される通信ネットワークへの参加要求信号であり、
上記応答信号が、上記サーバによる上記通信ネットワークへの参加許可信号である
ことを特徴とする請求項１又は２に記載の通信装置。
【請求項４】
複数の端末と、上記各端末を管理するサーバとの間で信号を中継する通信方法において、
登録手段が、上記複数の端末のいずれかから受信した、上記サーバ宛の要求信号に含まれている端末識別情報を端末管理リストに登録し、
監視手段が、上記要求信号の受信後上記各端末の受信期間に応じた待機時間内に、上記要求信号に対する、上記サーバからの暗号化された応答信号の受信の有無を監視し、
設定手段が、上記監視手段による監視結果に応じて、上記各端末から上記サーバ宛の信号を遮断するか否かを設定する
ことを特徴とする通信方法。
【請求項５】
複数の端末と、上記各端末を管理するサーバとの間で信号を中継する通信プログラムにおいて、
コンピュータを、
上記複数の端末のいずれかから受信した、上記サーバ宛の要求信号に含まれている端末識別情報を端末管理リストに登録する登録手段と、
上記要求信号の受信後上記各端末の受信期間に応じた待機時間内に、上記要求信号に対する、上記サーバからの暗号化された応答信号の受信の有無を監視する監視手段と、
上記監視手段による監視結果に応じて、上記各端末から上記サーバ宛の信号を遮断するか否かを設定する設定手段と
して機能させることを特徴とする通信プログラム
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、通信装置、通信方法及び通信プログラムに関し、例えば、情報を中継する通信装置に適用し得るものである。
【背景技術】
【０００２】
ＩｏＴ（Ｉｎｔｅｒｎｅｔ  Ｏｆ  Ｔｈｉｎｇｓ）システムを構築する無線通信技術において、低消費電力、長距離通信が可能な無線通信技術を、一般的にＬＰＷＡ（Ｌｏｗ  Ｐｏｗｅｒ  Ｗｉｄｅ  Ａｒｅａ）と総称する。このＬＰＷＡにおいて、代表的な無線通信規格として、例えばＬｏＲａＷＡＮ（登録商標）と呼ばれるものがある（特許文献１、非特許文献１参照）。一般的に、ＬｏＲａ（登録商標）はＬｏＲａ変調方式（物理層）をいい、ＬｏＲａＷＡＮは、ＬｏＲａ変調方式の無線技術を利用して、ＯＳＩ参照モデルのデータリンク層（ＭＡＣ（Ｍｅｄｉａ  Ａｃｃｅｓｓ  Ｃｏｎｔｒｏｌ）レイヤ）を含む通信規格技術をいう。
【０００３】
ＬｏＲａＷＡＮは、センサー情報等を送信する無線端末（以下、「ＬｏＲａＷＡＮ  Ｄｅｖｉｃｅ」、「エンドノード（ＥＮ）」とも呼ぶ。）、無線通信を終端してＩＰネットワークにデータ転送するゲートウェイ（以下、「無線通信ＬｏＲａＷＡＮ  Ｇａｔｅｗａｙ」、「ゲートウェイ（ＧＷ）」とも呼ぶ。）、ゲートウェイ（ＧＷ）から転送された各エンドノード（ＥＮ）からのセンサー情報を終端するサーバ（以下、「ＬｏＲａＷＡＮ  Ｎｅｔｗｏｒｋ  Ｓｅｒｖｅｒ」、「ネットワークサーバー（ＮＳ）」とも呼ぶ。）を有する。
【０００４】
ＬｏＲａＷＡＮでは、免許不要な周波数帯域が使用される。ＬｏＲａＷＡＮの使用周波数帯域は、各国で決められており、例えば、日本の場合では９２０ＭＨｚ帯の使用が考えられている。このように、ＬｏＲａＷＡＮは免許不要帯を使用するため、例えば携帯電話通信ネットワーク等とは異なり、利用したい事業者が独自にエンドノードやゲートウェイ等の無線機器を自営網に設置することができる。
【先行技術文献】
【特許文献】
【０００５】
【特許文献１】特開２０１８−４２１１０号公報
【非特許文献】
【０００６】
【非特許文献１】株式会社ソラコム，技術情報，ＳＯＲＡＣＯＭ  Ｂｌｏｇ,“ＬｏＲａＷＡＮの仕様とネットワークアーキテクチャー”，２０１７年３月１３日，２０１８年７月１２日検索，  ｈｔｔｐｓ：／／ｂｌｏｇ，ｓｏｒａｃｏｍ．ｊｐ／ｂｌｏｇ／２０１７／０３／１３／ｂｏｏｔｃａｍｐ−ｌｏｒａｗａｎ／
【発明の概要】
【発明が解決しようとする課題】
【０００７】
ところで、ゲートウェイは、エンドノードからのＬｏＲａ無線を終端して、ＩＰネットワークにデータ転送する機能のみを有する。
【０００８】
そのため、近接したエリアに異なる目的の複数の事業者のそれぞれが独自の自営網を構築した場合に、いずれかの通信網のエンドノードによって送信されたセンサー情報が両者のゲートウェイに受信され、両者のネットワークサーバに送信されてしまう。そうすると、当該エンドノードの所有者でない側のゲートウェイやネットワークに転送経路に余計なデータトラフィックが発生してしまうという課題がある。
【０００９】
例えばＬｏＲａＷＡＮの場合、各エンドノードとネットワークサーバとの間でセキュリティを確保するため、センサー情報は暗号化されている。そのため、他者の自営網にデータが転送されてもセキュリティ面では実害がない。しかし、ネットワークサーバには多数のエンドノードから多数のデータが集まることになるので、データ総量は相当なデータトラフィックとなる。
【００１０】
そのため、ゲートウェイとネットワークサーバとの間の通信路に流れる余計なデータトラフィックを抑制することができる通信装置、通信方法及び通信プログラムが求められている。
【課題を解決するための手段】
【００１１】
かかる課題を解決するために、第１の本発明に係る通信装置は、複数の端末と、各端末を管理するサーバとの間で信号を中継する通信装置において、（１）複数の端末のいずれかから受信した、サーバ宛の要求信号に含まれている端末識別情報を端末管理リストに登録する登録手段と、（２）要求信号の受信後各端末の受信期間に応じた待機時間内に、要求信号に対する、サーバからの暗号化された応答信号の受信の有無を監視する監視手段と、（３）監視手段による監視結果に応じて、各端末からサーバ宛の信号を遮断するか否かを設定する設定手段とを備えることを特徴とする。
【００１２】
第２の本発明に係る通信方法は、複数の端末と、各端末を管理するサーバとの間で信号を中継する通信方法において、（１）登録手段が、複数の端末のいずれかから受信した、サーバ宛の要求信号に含まれている端末識別情報を端末管理リストに登録し、（２）監視手段が、要求信号の受信後各端末の受信期間に応じた待機時間内に、要求信号に対する、サーバからの暗号化された応答信号の受信の有無を監視し、（３）設定手段が、監視手段による監視結果に応じて、各端末からサーバ宛の信号を遮断するか否かを設定することを特徴とする。
【００１３】
第３の本発明に係る通信プログラムは、複数の端末と、各端末を管理するサーバとの間で信号を中継する通信プログラムにおいて、コンピュータを、（１）複数の端末のいずれかから受信した、サーバ宛の要求信号に含まれている端末識別情報を端末管理リストに登録する登録手段と、（２）要求信号の受信後各端末の受信期間に応じた待機時間内に、要求信号に対する、サーバからの暗号化された応答信号の受信の有無を監視する監視手段と、（３）監視手段による監視結果に応じて、各端末からサーバ宛の信号を遮断するか否かを設定する設定手段として機能させることを特徴とする。
【発明の効果】
【００１４】
本発明によれば、ゲートウェイとネットワークサーバとの間の通信路に流れるデータトラフィックを抑制することができる。
【図面の簡単な説明】
【００１５】
【図１】実施形態に係るゲートウェイの内部構成を示す内部構成図である。
【図２】実施形態に係る通信システムの全体構成の一例を示す全体構成図である。
【図３】実施形態に係る端末管理リストの構成例を示す構成図である。
【図４】実施形態に係る無線端末のネットワーク接続処理を示すシーケンス図である。
【図５】実施形態に係るゲートウェイ１における監視処理を示すフローチャートである。
【図６】実施形態に係る無線端末の受信期間を説明する説明図である。
【図７】実施形態のゲートウェイが無線端末からの上り方向のデータを遮断するネットワーク構成の一例を示す構成図である。
【図８】実施形態のデータ監視部による端末管理リストの作成処理を説明する説明図である。
【図９】変形実施形態のゲートウェイが無線端末からの上り方向のデータを遮断するネットワーク構成の一例を示す構成図である。
【発明を実施するための形態】
【００１６】
（Ａ）主たる実施形態
以下では、本発明に係る通信装置、通信方法及び通信プログラムの実施形態を、図面を参照しながら詳細に説明する。
【００１７】
この実施形態は、ＬＰＷＡの１つの無線通信規格であるＬｏＲａＷＡＮを採用した通信システムに本発明を適用する場合を例示する。
【００１８】
（Ａ−１）実施形態の構成
［全体構成］
図２は、実施形態に係る通信システムの全体構成の一例を示す全体構成図である。
【００１９】
図２において、実施形態に係る通信システム１０は、複数の無線端末２（２−１〜２−Ｎ；Ｎは正の整数）、ゲートウェイ１、サーバ３を有する。
【００２０】
以下では、無線端末２からサーバ３に向けた方向を「上り方向」と呼び、サーバ３から無線端末２に向けた方向を「下り方向」と呼ぶ。
【００２１】
各無線端末２は、センサを搭載しており、センサによりセンシングされたセンサー情報を無線送信するものである。各無線端末２は、ＬｏＲａＷＡＮにおけるエンドノードに対応するものである。
【００２２】
ゲートウェイ１は、各無線端末との間の無線ネットワークと、有線回線ネットワークＮＴとの間でデータを中継するものである。つまり、ゲートウェイ１は、無線端末２から受信したデータを、有線回線ネットワークＮＴに転送したり、有線回線ネットワークＮＴから受信したデータを無線通信したりする。
【００２３】
サーバ３は、各無線端末２のデバイス識別子（ＤｅｖＥＵＩ：Ｄｅｖｉｃｅ  Ｅｘｔｅｎｄｅｄ  Ｕｎｉｑｕｅ  Ｉｄｅｎｔｉｆｅｒ）の管理や、データのルーティング制御や、データの暗号化等を行なうものである。サーバ３は、ＬｏＲａＷＡＮのネットワークサーバに対応するものである。なお、図示しないが、サーバ３の上位にはアプリケーション（例えばアプリケーションサーバ）が存在するようにしてもよく、サーバ３は、各無線端末２から収集したデータを上位のアプリケーションに与えるようにしてもよい。
【００２４】
［無縁通信システム］
各無線端末２とゲートウェイ１は、無線通信システム（無線ネットワーク）を構成する。無線ネットワークは、所定の無線通信方式（例えば、ＬｏＲａ方式）を採用している。例えば、日本では９２０ＭＨｚの周波数帯を使用し、変調方式としてスペクトル拡散方式を採用する場合を例示するが、使用周波数帯域はこれに限定されるものではない。
【００２５】
無線ネットワークのトポロジーは、メッシュ型ネットワーク又はスター型ネットワークを適用することができる。この実施形態では、各無線端末２に対してゲートウェイ１は親ノードとみなし、ゲートウェイ１に対して各無線端末２は子ノードとみなし、各無線端末２とゲートウェイ１とは１対１の無線通信を行なう場合を例示する。なお、無線ネットワークのトポロジーは、これに限定されるものではない。
【００２６】
各無線端末２の消費電力を抑えるため、各無線端末２は、間欠的に無線の送受信をスリープさせるスリープ機能を有している。この実施形態では、各無線端末２は、上り方向への送信期間後に、無線通信を閉鎖するスリープ期間を設定する。そして、上り方向の送信期間後の所定時間経過後に、無線通信を開放して無線受信を行なう所定の受信期間（Ｒｅｃｅｉｖｅ  Ｗｉｎｄｏｗ）が設けられているものとする。なお、ゲートウェイ１及びサーバ３は、予め無線端末２の受信期間のタイミングが設定されているものとする。
【００２７】
［無線端末２とサーバ３との間のデータ通信］
無線端末２とサーバ３との間のデータ通信は、セキュリティを確保するため、所定の暗号化方式で暗号化されたデータを授受するようにしている。暗号化方式のアルゴリズムは、特に限定されるものではないが、例えば共通鍵方式（例えばＡＥＳ（Ａｄｖａｎｃｅｄ  Ｅｎｃｒｙｐｔｉｏｎ  Ｓｔａｎｄａｒｄ）方式等）を適用することができる。
【００２８】
［ゲートウェイ１の内部構成］
図１は、実施形態に係るゲートウェイ１の内部構成を示す内部構成図である。
【００２９】
図１において、実施形態に係るゲートウェイ１は、データ監視部１１、無線送受信部１２、データ転送部１３、アンテナ部１４を有する。また、データ監視部１１は、端末管理リスト１５を有する。
【００３０】
ゲートウェイ１のハードウェア構成は、例えば、ＣＰＵ、ＲＯＭ、ＲＡＭ、ＥＥＰＲＯＭ、入出力インタフェース部、通信装置等を有する装置であり、ＣＰＵが、ＲＯＭに格納される処理プログラム（例えば、通信プログラム）を実行することにより、ゲートウェイ１の各種機能が実現される。通信プログラムがゲートウェイ１にインストールされることにより、ゲートウェイ１の各種機能が実現されるようにしてもよい。
【００３１】
アンテナ部１４は、各無線端末２が送出した電波を捕捉して電気信号に変換したり、無線送受信部１２からの信号を電波に乗せて送出したりする。
【００３２】
無線送受信部１２は、各無線端末２との間で無線通信を行なうものである。無線送受信部１２は、無線通信インタフェース等であり、アンテナ部１４を介して受信した信号をデータ転送部１３に与えたり、データ転送部１３からのデータをアンテナ部１４を介して無線送信したりする。
【００３３】
データ転送部１３は、無線送受信部１２からの信号をＩＰ（インタネットプロトコル）データに変換して有線回線ネットワークＮＴに転送したり、有線回線ネットワークＮＴからのＩＰデータを無線通信用データに変換して無線送受信部に与える。
【００３４】
データ監視部１１は、各無線端末２とサーバ３との間で授受されるデータを監視するものである。図１に示すように、データ監視部１１は、登録部５１、監視部５２、設定部５３、端末管理リスト１５を有する。
【００３５】
データ監視部１１は、無線端末２がサーバ３に対してネットワークの参加要求（接続処理）を行なう際に、端末管理リスト１５を用いて、各無線端末２からの接続リクエスト（Ｊｏｉｎ−Ｒｅｑｕｅｓｔ）と、サーバ３が参加許可をするときに無線端末２に返信する応答信号（Ｊｏｉｎ−Ａｃｃｅｐｔ）とを監視して、自営網に属する無線端末２を判断する。
【００３６】
登録部５１は、各無線端末２からサーバ３宛の接続リクエスト（Ｊｏｉｎ−Ｒｅｑｕｅｓｔ）に含まれているデバイス識別子（ＤｅｖＥＵＩ）を抽出し、そのデバイス識別子を端末管理リスト１５に登録するものである。
【００３７】
監視部５２は、各無線端末２からの接続リクエスト（Ｊｏｉｎ−Ｒｅｑｕｅｓｔ）の受信後、各無線端末２に割り当てられている受信期間（Ｒｅｃｅｉｖｅ  Ｗｉｎｄｏｗ）に対応する待機時間内に、サーバ３から参加許可を示す応答信号（Ｊｏｉｎ−Ａｃｃｅｐｔ）の受信の有無を監視するものである。監視部５２は、端末管理リスト１５に登録されたデバイス識別子に、後述するＪｏｉｎ−Ａｃｃｅｐｔ待機フラグを対応付けて付与する。
【００３８】
設定部５３は、監視部５２による監視結果に応じて、無線端末２からのデータを遮断するか否かを設定するものである。つまり、設定部５３は、監視部５２による監視結果が反映された端末管理リスト１５を参照して、端末管理リスト１５に非透過フラグが付与されていない無線端末２からのデータについては、サーバ３から参加許可された無線端末２からのデータであると判断し、当該データを透過（すなわち、有線回線ネットワークＮＴに送信）する。また、端末管理リスト１５において、非透過フラグが付与されている無線端末２からのデータについては、サーバ３から参加許可されていない無線端末２からのデータを遮断する。
【００３９】
なお、データ監視部１１の監視処理の詳細な説明は動作の項で行なう。
【００４０】
［端末管理リスト１５］
図３は、実施形態に係る端末管理リスト１５の構成例を示す構成図である。図３に示すように、端末管理リスト１５は、「ＤｅｖＥＵＩ」、「Ｊｏｉｎ−Ａｃｃｅｐｔ待機フラグ」「非透過フラグ」を項目として構成される。
【００４１】
「ＤｅｖＥＵＩ」は、ゲートウェイ１を透過した接続リクエスト（Ｊｏｉｎ−Ｒｅｑｕｅｓｔ）の要求元である無線端末２のデバイス識別子（ＤｅｖＥＵＩ）を格納する。
【００４２】
「Ｊｏｉｎ−Ａｃｃｅｐｔ待機フラグ」は、「ＤｅｖＥＵＩ」にデバイス識別子（ＤｅｖＥＵＩ）が格納された後に、応答信号（Ｊｏｉｎ−Ａｃｃｅｐｔ）がゲートウェイ１を透過するまで、ゲートウェイ１が待機していることを示すフラグを格納する。つまり、接続リクエストから抽出したデバイス識別子（ＤｅｖＥＵＩ）が「ＤｅｖＥＵＩ」に登録されると、ゲートウェイ１は当該接続リクエストに対する応答信号（Ｊｏｉｎ−Ａｃｃｅｐｔ）の受信を待機する状態となり、その待機状態を示すため「Ｊｏｉｎ−Ａｃｃｅｐｔ待機フラグ」にフラグが立つ。「Ｊｏｉｎ−Ａｃｃｅｐｔ待機フラグ」におけるフラグの立て方は、特に限定されるものではないが、この実施形態では「１」が待機状態を示し、「０」が待機状態から開放されたことを示す。
【００４３】
「非透過フラグ」は、応答信号（Ｊｏｉｎ−Ａｃｃｅｐｔ）の待機期間が経過しても、応答信号（Ｊｏｉｎ−Ａｃｃｅｐｔ）が透過しなかったことを示すフラグを格納する。「非透過フラグ」におけるフラグの立て方は、特に限定されるものではないが、この実施形態では、「１」は、応答信号（Ｊｏｉｎ−Ａｃｃｅｐｔ）が非透過であることを示す。また、「−」は、応答信号（Ｊｏｉｎ−Ａｃｃｅｐｔ）の待機期間が経過する前の段階であることを示す。
【００４４】
（Ａ−２）実施形態の動作
［無線端末の接続処理］
以下では、無線端末２がサーバ３に対してネットワーク接続要求を行ない、無線端末２及びサーバ３がネットワーク暗号鍵を生成し、無線端末２とサーバ３との間で当該ネットワーク暗号鍵を用いてデータ通信のセキュリティを確保するまでの処理を説明する。
【００４５】
図４は、実施形態に係る無線端末のネットワーク接続処理を示すシーケンス図である。
【００４６】
サーバ３との間で通信を開始しようとする無線端末２は、接続リクエスト（Ｊｏｉｎ−Ｒｅｑｕｅｓｔ）をサーバ３に向けて送信する（Ｓ１０１）。無線端末２からサーバ３宛の接続リクエストを受信したゲートウェイ１は、受信した接続リクエストをサーバ３に転送する（Ｓ１０２）。
【００４７】
ここで、接続リクエストには、自端末２のデバイス識別子（ＤｅｖＥＵＩ）、アプリケーション識別子（ＡｐｐＥＵＩ：Ａｐｐｌｉｃａｔｉｏｎ  Ｅｘｔｅｎｄｅｄ  Ｕｎｉｑｕｅ  Ｉｄｅｎｔｉｆｅｒ）及びデバイス・ナンス（ＤｅｖＮｏｎｃｅ）が含まれている。デバイス識別子（ＤｅｖＥＵＩ）は、予め設定されたＭＡＣアドレスを６４ビットに拡張したものである。アプリケーション識別子は、自端末２で実行するアプリケーション毎に固有な識別情報である。デバイス・ナンスは、自端末２側で発行されるランダムな値である。
【００４８】
ＬｏＲａＷＡＮでは、無線端末２とサーバ３との間のデータ通信についてセキュリティを確保するため、例えば共通鍵方式等により暗号化処理が行なわれる。しかし、この時点では、まだ、無線端末２及びサーバ３はネットワーク暗号鍵を生成していない。従って、無線端末２が送信した接続リクエストは暗号化されていない平文のメッセージであるので、ゲートウェイ１は、受信した接続リクエストに含まれているデバイス識別子（ＤｅｖＥＵＩ）を参照することができる。
【００４９】
このとき、無線端末２から接続リクエストを受信したゲートウェイ１は、受信した接続リクエストに含まれている無線端末２のデバイス識別子（ＤｅｖＥＵＩ）を抽出し、当該無線端末２のデバイス識別子（ＤｅｖＥＵＩ）を、端末管理リスト１５に記録する。これにより、ゲートウェイ１を透過する接続リクエスト（Ｊｏｉｎ−Ｒｅｑｕｅｓｔ）の要求元である無線端末２のデバイス識別子（ＤｅｖＥＵＩ）を保持することができる。
【００５０】
ゲートウェイ１を介して無線端末２からの接続リクエストを受信したサーバ３は、無線端末２に固有のデバイスアドレス（ＤｅｖＡｄｄｒ）と、アプリケーション・ナンス（ＡｐｐＮｏｎｃｅ）を発行する（Ｓ１０３）。そして、サーバ３は、当該デバイスアドレス（ＤｅｖＡｄｄｒ）とネットワーク識別子（ＮｅｔＩＤ）とアプリケーション・ナンス（ＡｐｐＮｏｎｃｅ）とを含む応答信号（Ｊｏｉｎ−Ａｃｃｅｐｔ）を、無線端末２に固有な暗号鍵（AppKey）で暗号化して無線端末２に送信する（Ｓ１０４）。
【００５１】
ゲートウェイ１は、サーバ３から応答信号（Ｊｏｉｎ−Ａｃｃｅｐｔ）を受信すると、当該受信した応答信号（Ｊｏｉｎ−Ａｃｃｅｐｔ）を無線端末２に転送する（Ｓ１０５）。
【００５２】
サーバ３からの応答信号（Ｊｏｉｎ−Ａｃｃｅｐｔ）は、無線端末２に固有の暗号鍵を用いて暗号化されている。従って、ゲートウェイ１は、受信した応答信号（Ｊｏｉｎ−Ａｃｃｅｐｔ）を解析することができず、応答信号（Ｊｏｉｎ−Ａｃｃｅｐｔ）の送信先（すなわち、接続リクエストの要求元）の無線端末２のデバイス識別子（ＤｅｖＥＵＩ）を参照することができない。
【００５３】
そこで、この実施形態では、無線端末２が、送信スロット後に所定時間の受信スロットで無線開放するという無線通信規格の特性を利用して、ゲートウェイ１は、自営網に属する無線端末２に対する応答信号（Ｊｏｉｎ−Ａｃｃｅｐｔ）であるか否かを判断する。なお、ゲートウェイ１による監視処理の詳細な説明は後述する。
【００５４】
暗号化された応答信号（Ｊｏｉｎ−Ａｃｃｅｐｔ）を受信した無線端末２は、当該無線端末２に固有の暗号鍵を用いて応答信号（Ｊｏｉｎ−Ａｃｃｅｐｔ）を復号し、サーバ３が発行したデバイスアドレス（ＤｅｖＡｄｄｒ）を取得する。また、無線端末２は、ネットワーク暗号鍵（ＮｗｋＳＫｅｙ）と、アプリケーション暗号鍵（ＡｐｐＳＫｅｙ）とを生成する（Ｓ１０６）。なお、サーバ３においても、無線端末２と同じ手順によりネットワーク暗号鍵（ＮｗｋＳＫｅｙ）と、アプリケーション暗号鍵（ＡｐｐＳＫｅｙ）とを生成する（Ｓ１０７）。
【００５５】
これらネットワーク暗号鍵（ＮｗｋＳＫｅｙ）とアプリケーション暗号鍵（ＡｐｐＳＫｅｙ）との生成には、端末Ｔに固有な暗号鍵（ＡｐｐＫｅｙ）と、アプリケーション・ナンスと、ネットワーク識別子と、デバイス・ナンスとがパラメータとして用いられる。また、その生成アルゴリズムは公開のものであるので、上記パラメータが知られている場合、ネットワーク暗号鍵（ＮｗｋＳＫｅｙ）及びアプリケーション暗号鍵（ＡｐｐＳＫｅｙ）も知られ得る状態となる。
【００５６】
その後、無線端末２は、送信すべきデータをネットワーク暗号鍵（ＮｗｋＳＫｅｙ）で暗号化して送出する（Ｓ１０８）。このとき、送信データには無線端末２のデバイスアドレスが含まれている。ゲートウェイ１は、無線端末２からデータを受信すると、そのデータをサーバ３に転送する（Ｓ１０９）。そして、サーバ３では、暗号化されたデータをＳ１０７で生成したネットワーク暗号鍵（ＮｗｋＳＫｅｙ）で復号し、無線端末２が送信したデータを取り出す（Ｓ１１０）。
【００５７】
［ゲートウェイ１の監視処理］
次に、上述した無線端末２のネットワーク接続処理において、ゲートウェイ１が、サーバ３により参加許可された無線端末２であるか否かを判断する処理を、図面を参照しながら詳細に説明する。
【００５８】
図５は、実施形態に係るゲートウェイ１における監視処理を示すフローチャートである。
【００５９】
ゲートウェイ１において、無線端末２からの接続リクエスト（Ｊｏｉｎ−Ｒｅｑｕｅｓｔ）を受信すると、データ監視部１１は、接続リクエスト（Ｊｏｉｎ−Ｒｅｑｕｅｓｔ）に含まれているデバイス識別子（ＤｅｖＥＵＩ）を抽出し、そのデバイス識別子（ＤｅｖＥＵＩ）を端末管理リスト１５に登録する（Ｓ１１）。
【００６０】
なお、複数の無線端末２のそれぞれから接続リクエストを受信した場合、データ監視部１１は、接続リクエストを受信した順序に従って、順番に、各無線端末２のデバイス識別子（ＤｅｖＥＵＩ）を端末管理リスト１５に登録する。
【００６１】
より具体的には、端末管理リスト１５の項目「ＤｅｖＥＵＩ」に、抽出したデバイス識別子（ＤｅｖＥＵＩ）が登録され、さらに項目「Ｊｏｉｎ−Ａｃｃｅｐｔ待機フラグ」に、応答信号（Ｊｏｉｎ−Ａｃｃｅｐｔ）の待機状態であることを示すフラグ（この例の場合「１」）が格納される。
【００６２】
データ監視部１１は、無線端末２から接続リクエストを受信すると、所定の待機時間の計時を開始する。そして、データ監視部１１は、当該待機時間内に、サーバ３から応答信号（Ｊｏｉｎ−Ａｃｃｅｐｔ）が送信されてくるか否かを監視する（Ｓ１２）。
【００６３】
なお、複数の無線端末２から接続リクエストを受信した場合、データ監視部１１は、それぞれの接続リクエストの受信時刻から待機時間の計時を開始し、接続リクエスト毎に待機時間を監視する。
【００６４】
ここで、データ監視部１１による応答信号（Ｊｏｉｎ−Ａｃｃｅｐｔ）の監視方法を説明する。
【００６５】
上述したように、接続リクエスト（Ｊｏｉｎ−Ｒｅｑｕｅｓｔ）は暗号化されていないので、データ監視部１１は接続リクエスト（Ｊｏｉｎ−Ｒｅｑｕｅｓｔ）から抽出したデバイス識別子（ＤｅｖＥＵＩ）を認識することができる。
【００６６】
一方、応答信号（Ｊｏｉｎ−Ａｃｃｅｐｔ）は、無線端末２に固有の暗号鍵で暗号されているため、データ監視部１１は、応答信号（Ｊｏｉｎ−Ａｃｃｅｐｔ）からデバイス識別子（ＤｅｖＥＵＩ）を認識することができない。つまり、ゲートウェイ１は、応答信号からデバイス識別子を抽出できないので、接続リクエストと当該接続リクエストに対する応答信号とを紐づけすることができないという問題がある。
【００６７】
そこで、この実施形態では、サーバ３が無線端末２の受信期間（Ｒｅｃｅｉｖｅ  Ｗｉｎｄｏｗ）の範囲内に応答信号（Ｊｏｉｎ−Ａｃｃｅｐｔ）を返信することを利用して、データ監視部１１が応答信号を監視する。
【００６８】
例えば、ＬｏＲａＷＡＮの仕様には、無線端末２の受信期間（Ｒｅｃｅｉｖｅ  Ｗｉｎｄｏｗ）に関して取り決めがある。図６を用いて無線端末２の受信期間（Ｒｅｃｅｉｖｅ  Ｗｉｎｄｏｗ）を説明する。
【００６９】
図６に示すように、無線端末２は、上りの送信期間後、所定時間経過後に２回の受信期間（Ｒｅｃｅｉｖｅ  Ｗｉｎｄｏｗ）が設定されており、無線端末２は２回の受信期間（Ｒｅｃｅｉｖｅ  Ｗｉｎｄｏｗ）のタイミングのみ受信可能である。
【００７０】
より具体的には、上り送信期間後、第１の所定時間経過後に、第１の受信期間（Ｒｅｃｅｉｖｅ  Ｗｉｎｄｏｗ：Ｒ１）が設定されており、上り送信時間後、第２の所定時間経過後に、第２の受信期間（Ｒｅｃｅｉｖｅ  Ｗｉｎｄｏｗ：Ｒ２）が設定されている。２回の受信期間（Ｒｅｃｅｉｖｅ  Ｗｉｎｄｏｗ）が設定されているのは、ＬｏＲａＷＡＮには、無線端末２の再送制御のためであり、第２回目の受信期間（Ｒｅｃｅｉｖｅ  Ｗｉｎｄｏｗ）は再送制御を考慮して設定されている。
【００７１】
接続リクエスト（Ｊｏｉｎ−Ｒｅｑｕｅｓｔ）を受信したサーバ３が応答信号（Ｊｏｉｎ−Ａｃｃｅｐｔ）を返信する場合、サーバ３は、当該無線端末２の受信期間（すなわち、受信期間Ｒ１又は受信期間Ｒ２）の範囲内に収まるように、応答信号（Ｊｏｉｎ−Ａｃｃｅｐｔ）を送信する必要がある。
【００７２】
そこで、この実施形態では、データ監視部１１は、接続リクエストを受信すると、無線端末２の受信期間に相当する待機時間の計時を開始し、その待機期間内に、サーバ３からの応答信号が透過するか否かを判断するようにする。
【００７３】
換言すると、データ監視部１１は、接続リクエストを受信すると、当該無線端末２について、２回の受信期間のそれぞれの時間内に応答信号が透過したか否かを判断する。
【００７４】
つまり、従来は、応答信号が暗号化されているので、ゲートウェイ１はデバイス識別子（ＤｅｖＥＵＩ）を識別できず、応答信号が透過しても、接続リクエストとそれに紐づいた応答信号であるか否かを判断することができない。しかし、この実施形態によれば、どの無線端末２の接続リクエストと紐付いた応答信号であるかを、接続リクエストがゲートウェイ１を透過した後の経過時間に基づいて判断することができる。
【００７５】
そして、２回の受信期間のいずれかの時間範囲内に応答信号が透過した場合、データ監視部１１は、端末管理リスト１５に登録されている当該デバイス識別子の無線端末２が、自営網のサーバ３から参加許可されたものと判断できる。この場合、データ監視部１１は、端末管理リスト１５の項目「ＤｅｖＥＵＩ」に登録されているデバイス識別子（ＤｅｖＥＵＩ）と、このデバイス識別子（ＤｅｖＥＵＩ）に対応するデータ（すなわち、Ｊｏｉｎ−Ａｃｃｅｐｔ待機フラグ）を削除する（Ｓ１３）。
【００７６】
一方、２回の受信期間のいずれの時間範囲内に応答信号が透過しなかった場合、データ監視部１１は、端末管理リスト１５に登録されている当該デバイス識別子の無線端末２が、自営網のサーバ３から参加許可されなかったものと判断できる。この場合、データ監視部１１は、端末管理リスト１５において、当該デバイス識別子（ＤｅｖＥＵＩ）の項目「非透過フラグ」にフラグを立てる（Ｓ１４）。
【００７７】
よって、端末管理リスト１５の「非透過フラグ」が立てられたデバイス識別子（ＤｅｖＥＵＩ）の無線端末２からの上りデータは、ゲートウェイ１が遮断することができる。その結果、ゲートウェイ１から有線回線ネットワークＮＴにかけての通信路において余分なデータトラフィックを抑制することが可能となる。
【００７８】
［データ監視部１１の動作例］
図７は、実施形態のゲートウェイ１が無線端末２からの上り方向のデータを遮断するネットワーク構成の一例を示す構成図である。
【００７９】
図８（Ａ）〜図８（Ｅ）は、実施形態のデータ監視部１１による端末管理リスト１５の作成処理を説明する説明図である。
【００８０】
図７は、自営網がサーバ３と無線端末２−２〜２−５で構築される場合に、当該自営網に属さない無線端末２−１の無線電波がゲートウェイ１に到来したときのケースである。また、図７において、例えば、無線端末２−１の「xxxxxxxxxxxxxxxA」の表記は、当該無線端末２−１のデバイス識別子（ＤｅｖＥＵＩ）を示している。
【００８１】
図７において、各無線端末２−１〜２−５がネットワークに参加していない場合、図８（Ａ）に示すように、端末管理リスト１５にはデバイス識別子が登録されていない。
【００８２】
その後、自営網でない無線端末２−１が、ネットワークに参加するため、サーバ３に対して、自端末のデバイス識別子（ＤｅｖＥＵＩ）、アプリケーション識別子（ＡｐｐＥＵＩ）及びデバイス・ナンス（ＤｅｖＮｏｎｃｅ）を含む接続リクエストを送信したとする。
【００８３】
このとき、接続リクエストを受信したゲートウェイ１では、データ監視部１１が、暗号化されていない接続リクエストからデバイス識別子（ＤｅｖＥＵＩ）を抽出して、図８（Ｂ）に示すように、端末管理リスト１５の項目「ＤｅｖＥＵＩ」にデバイス識別子「XXXXXXXXXXXXXXXA」を登録し、更にデータ監視部１１は、当該デバイス識別子に対応する「Ｊｏｉｎ−Ａｃｃｅｐｔ待機フラグ」に、待機状態であることを示す「フラグ：１」を立てる。
【００８４】
また、ゲートウェイ１は、受信した接続リクエストをサーバ３に送信する。サーバ３は、自営網の無線端末２のデバイス識別子を管理しており、無線端末２−１からの接続リクエストに基づいて、ネットワークへの参加許可するか否かを判断する。ここでは、無線端末２−１は、サーバ３の自営網のものではないので、ネットワークへの参加は許可されない。従って、サーバ３は、無線端末２−１に対して応答信号（Ｊｏｉｎ−Ａｃｃｅｐｔ）を返信しないことになる。
【００８５】
ゲートウェイ１では、データ監視部１１が、無線端末２−１からの接続リクエストが透過したときから受信期間（Ｒｅｃｅｉｖｅ  Ｗｉｎｄｏｗ）の時間内に応答信号が透過したか否かを監視している。
【００８６】
そして、サーバ３から応答信号（Ｊｏｉｎ−Ａｃｃｅｐｔ）が送信されないので、データ監視部１１は、応答信号（Ｊｏｉｎ−Ａｃｃｅｐｔ）の透過を検出できないまま、受信期間（Ｒｅｃｅｉｖｅ  Ｗｉｎｄｏｗ）の時間が経過すると、図８（Ｃ）に示すように、端末管理リスト１５に登録されているデバイス識別子「XXXXXXXXXXXXXXXA」の「Ｊｏｉｎ−Ａｃｃｅｐｔ待機フラグ」を待機状態が開放されたことを示す「フラグ（０）」にし、「非透過フラグ」を応答信号が非透過であることを示す「フラグ（１）」とする。
【００８７】
これにより、その後、無線端末２−１からの上りデータはゲートウェイ１で遮断することができる。
【００８８】
その後、自営網の無線端末２−２〜２−５が、ネットワークに参加するため、サーバ３に対して、自端末のデバイス識別子（ＤｅｖＥＵＩ）、アプリケーション識別子（ＡｐｐＥＵＩ）及びデバイス・ナンス（ＤｅｖＮｏｎｃｅ）を含む接続リクエストを送信したとする。
【００８９】
同様にして、接続リクエストを受信したゲートウェイ１では、データ監視部１１が、図８（Ｄ）に示すように、端末管理リスト１５の項目「ＤｅｖＥＵＩ」に各デバイス識別子「XXXXXXXXXXXXXXXB」〜「XXXXXXXXXXXXXXXE」と、「Ｊｏｉｎ−Ａｃｃｅｐｔ待機フラグ」に「フラグ：１」を順次登録する。
【００９０】
ここで、各接続リクエストを受信したサーバ３は、自営網の各無線端末２−２〜２−５からの接続リクエストに基づいて、ネットワークへの参加許可するため、各無線端末２−２〜２−５に対して応答信号（Ｊｏｉｎ−Ａｃｃｅｐｔ）を返信する。
【００９１】
ゲートウェイ１では、データ監視部１１が、各無線端末２−２〜２−５からの各接続リクエストが透過したときから受信期間（Ｒｅｃｅｉｖｅ  Ｗｉｎｄｏｗ）の時間内に応答信号の透過を検出することができる。
【００９２】
従って、データ監視部１１は、図８（Ｅ）に示すように、端末管理リスト１５に登録されている各デバイス識別子「XXXXXXXXXXXXXXXB」〜「XXXXXXXXXXXXXXXE」の登録データを削除する。これにより、図８（Ｅ）に示すように、接続リクエストを送信した自営網の無線端末２−２〜２−５の登録データは削除されるが、自営網でない無線端末２−１の登録データは端末管理リスト１５に保持することができる。
【００９３】
（Ａ−３）実施形態の効果
以上のように、異なる事業者が運営するそれぞれの自営網のエリアが重複した場合、無線端末はいずれかの自営網にしか参加することはなく、他方の自営網のサーバから参加許可は下りないものと考えられる。
【００９４】
従って、その状況下で、通常、無線端末は、両方の自営網に上り信号を送信し続けるが、この実施形態によれば、サーバから参加許可が降りていない自営網では、ゲートウェイで上り信号が遮断されることとなり、不要なトラフィックを抑制することが可能となる。
【００９５】
（Ｂ）他の実施形態
上述した実施形態においても種々の変形実施形態を言及したが、本発明は、以下の変形実施形態にも適用できる。
【００９６】
（Ｂ−１）上述した実施形態では、ＬｏＲａＷＡＮに適用する場合を例示して説明したが、ＬｏＲａＷＡＮに限定されるものではない。例えば、自営網が重複する可能性がある端末が参加要求を行なうネットワークであり、参加要求の上り信号と、応答の下り信号とが定義されていて、かつ、下り信号は暗号化されていても、所定期間にサーバが端末に対して応答するようなネットワークであれば、本発明を適用することができる。
【００９７】
（Ｂ−２）上述した実施形態において図７に示した構成例は、一例であり、図９に例示するようなケースにも本発明を適用することができる。図９は、サーバ３Ａと無線端末２−２〜２−５で構築される自営網に近接して、他の自営網（サーバ３Ｂ）が存在する場合に、他の自営網の無線端末２−１の無線電波がゲートウェイ１に到来したときのケースである。このようなケースでも、上述した実施形態と同様の効果を奏する。
【００９８】
（Ｂ−３）上述した実施形態では、ゲートウェイが、自営網のために設置されたものである場合を例示するが、複数の異なる自営網で共有可能なものであってもよい。
【００９９】
その場合、複数の異なる自営網の無線端末のそれぞれが送信した接続リクエストが、ゲートウェイを透過したり、異なる自営網のサーバからの応答信号がゲートウェイを透過することになる。しかし、その場合でも、ゲートウェイが、各自営網で設定した無線端末の受信期間を設定していれば、実施形態と同様の効果が得られる。
【０１００】
（Ｂ−４）上述した実施形態では、ゲートウェイが、各無線端末との間の無線ネットワークと、有線回線ネットワークＮＴとの間でデータを中継するものである場合を例示するが、次のように、有線回線ネットワークＮＴが無線回線ネットワークＮＴであってもよい。
【０１０１】
その場合、ゲートウェイは、各無線端末との間の無線ネットワークと、無線線回線ネットワークＮＴとの間でデータを中継するものである。つまり、ゲートウェイは、無線端末２から受信したデータを、無線回線ネットワークＮＴに転送したり、無線回線ネットワークＮＴから受信したデータを無線端末に対して無線通信したりする。
【符号の説明】
【０１０２】
１０…通信システム、１…ゲートウェイ、１１…データ監視部、１２…無線送受信部、１３…データ転送部、１４…アンテナ部、１５…端末管理リスト、２（２−１〜２−Ｎ）…無線端末、３…サーバ、５１…登録部、５２…監視部、５３…設定部。
【図１】
2020028099.tif 000003
【図２】
2020028099.tif 000004
【図３】
2020028099.tif 000005
【図４】
2020028099.tif 000006
【図５】
2020028099.tif 000007
【図６】
2020028099.tif 000008
【図７】
2020028099.tif 000009
【図８】
2020028099.tif 000010
【図９】
2020028099.tif 000011