JP6975065B2 - 通信システム、通信方法、及びプログラム - Google Patents

Description

本発明は、拠点におけるネットワークと、データセンタ等におけるアプリケーションとを接続する技術に関連するものである。

小規模な無線ネットワークを構成する技術として種々の技術がある。例えばＺｉｇＢｅｅ（登録商標）は数十メートルの範囲内の小規模な無線ネットワークを構成する技術であり、生成されたネットワークをＲＡＮ（Ｒａｄｉｏ Ａｒｅａ Ｎｅｔｗｏｒｋ）と呼ぶ。

図１に示すように、ＺｉｇＢｅｅでは一つのＣｏｏｒｄｉｎａｔｏｒ配下にＲＡＮ２が構成される。Ｃｏｏｒｄｉｎａｔｏｒにはシリアルインタフェースを介して、アプリケーション１が接続される。ｒｏｕｔｅｒはｅｎｄ ｄｅｖｉｃｅとｃｏｏｒｄｉｎａｔｏｒ間通信を中継する。ＲＡＮ２は、アプリケーション１からみると一つのＬ２ネットワークとしてみなせる。

なお、「アプリケーション」は、特に断らない限り、ソフトウェアをコンピュータ上で実行させることにより実現される機能を意味する。

図１のＲＡＮ２において、各端末（Ｃｏｏｒｄｉｎａｔｏｒ、ｒｏｕｔｅｒ、ｅｎｄ ｄｅｖｉｃｅ）にはＬ２アドレスが付与されており、アプリケーション１からＣｏｏｒｄｉｎａｔｏｒに対してＬ２アドレスを指定したデータフレームを渡すことで、ＺｉｇＢｅｅネットワーク内でルーティングがなされ、指定のＺｉｇＢｅｅ端末までデータが届けられる。

図２は、ＲＡＮの別の例として、Ｂｌｕｅｔｏｏｔｈ（登録商標） ＲＡＮ４を示す。図２に示すとおり、一つのＲＡＮに一つのｍａｓｔｅｒノードが存在する。ＲＡＮ内Ｐｉｃｏネット内のｓｌａｖｅノードとアプリケーション３は、シリアルインタフェースで接続されているように見える。

近年、ＩｏＴ等の普及により、ＺｉｇＢｅｅネットワーク等のＲＡＮをデータセンタを中心とした大規模ネットワークへスケールアウトする要求がある。ここでの「スケールアウト」とは、広域化により、一つのアプリケーションに複数拠点からＲＡＮが接続された場合にも、アプリケーションは個々のＲＡＮを識別することなく、一つのＲＡＮに接続されているように見せることを意味する。

しかし、ＺｉｇＢｅｅネットワークは単一の非ＩＰネットワークであるためネットワーク相互間を接続するためのネットワーク層プロトコルを持たず、データリンク層のみ規定されている。このために、アプリケーションが存在するデータセンタを中心とした大規模ネットワークへのスケールアウトには、何らかの機能追加が必要とされる。

近年ではプロトコル自体に機能を追加して、ＺｉｇＢｅｅ ＩＰ（非特許文献１）というＩＰｖ６アドレスを付与できる新たな規格も開発されている。しかし、新しいプロトコルは、既存の端末やアプリケーションを置き換えなければ使用できず、機能も高度になっている。普及の進んだ廉価な既存端末で構成されるネットワークを駆逐するまでには至っていない。

また、ＺｉｇＢｅｅではＩＰネットワークゲートウェイ（非特許文献２）製品がいくつか販売されている。図３に、ゲートウェイ（ＧＷ）７を使用した方式例を示す。その名前のとおりゲートウェイは、ＲＡＮ８からのＺｉｇＢｅｅプロトコルをゲートウェイで終端して、ＩＰベースアプリケーション５が接続されるＩＰネットワーク６へはＺｉｇＢｅｅのＬ２アドレスを隠蔽してＳＯＡＰなどのＨＴＴＰでＺｉｇＢｅｅのデータペイロード（ＡＴコマンド等）の送受信を行う。この方式では、アプリケーションをＩＰネットワーク対応に改造しなければならない。さらに単に一つのＲＡＮを遠隔から制御するだけではなく、複数のＲＡＮを一か所のデータに集約する場合には、どのノードがどのＲＡＮに接続されているのかを管理しておかなければ、ノードがＲＡＮ間を移動したときなどには、データを適切なＲＡＮに転送するネットワーク層におけるルーティング機能が必要となる。

ホームネットワークでは、ＩＰからＺｉｇＢｅｅノードを発見するために、ＩＰマルチキャスト端末からＵＰｎＰのｍ−ｓｅａｒｃｈをゲートウェイでＣｏＡＰ（非特許文献１０）にマッピングする手法が提案されている（非特許文献１１）。このような比較的狭いエリアではマルチキャストなどの手法が使えるために、ゲートウェイ方式は有効である。しかしながら、非ＩＰノードであるＲＡＮノードとアプリケーションは密に結合して動作するものであり、アプリケーションを全面作り直しとなるゲートウェイ方式では、ＲＡＮの広域化へのハードルが高い。

特開2016-218871号公報

ZigBee Alliance "The New ZigBee IP specification: IPv6 Control for Low-Power, Low-Cost Devices", April 3, 2013 ZigBee Alliance "White Paper: Understanding ZigBee Gateway", Sep.2010. 波多浩昭,"TTYインタフェースをIPでオーバレイするデバイスファイル転送方式の提案",電子情報通信学会技術研究報告IN2015-31,pp.49-53,Jul.2015 波多浩昭,上水流由香, "TTYデバイスをIPネットワークブリッジで集約するシステムの実装",電子情報通信学会技術研究報告IN2015-133,pp.147-152,Mar.2016 J.Lau, M.Townsley, I.Goyret "Layer Two Tunneling Protocol - Version 3 (L2TPv3)", IETF, RFC 3931, March 2005 Z.Zhu, R.Wakikawa, L. Zhang, "A Survey of Mobility Support in the Internet", IETF, RFC 6301, July 2011 M.ISHINO, Y.KOIZUMI, T.HASEGAWA,"A Routing-Based Mobility Management Scheme for IoT Devices in Wireless Mobile Networks", IEICE TRANSACTIONS on Communications,E98-B,No.12,pp.2376-2381,Dec.2015 C.Perkins,"IP Mobility Support for IPv4, Revised",Internet Engineering Task Force (IETF),RFC5944,Nov.2010 C.Perkins,D.Johnson,J. Arkko,"Mobility Support in IPv6",Internet Engineering Task Force (IETF),RFC6275,Jul.2011 Z.Shelby, K.Hartke, C.Bormann, "The Constrained Application Protocol (CoAP)" IETF, RFC7252, June 2014 J.MITSUGI, S.YONEMURA, T.YOKOISHI, "Reliable and Swift Device Discovery in Consolidated IP and ZigBee Home Networks", IEICE TRANSACTIONS on Communications, E96-B,No.7,pp.1837-1844,Jul.2013

ＲＡＮの広域化により複数の拠点を一箇所のデータセンタに集約できる。しかし、データセンタ側から見て単に複数の拠点への通信路が生成されただけでは、データセンタにおけるアプリケーションが、ノードと拠点への方路管理も行わなければならず、アプリケーションの大幅な改造が必要となり、コストや手間が増大する。

本発明は上記の点に鑑みてなされたものであり、既存のアプリケーションに変更を加えることなく、複数の拠点ネットワークとアプリケーションとを接続することを可能とする技術を提供することを目的とする。

開示の技術によれば、アプリケーションと拠点ネットワークとを接続する通信システムであって、
アプリケーションから送信されたデータを受信し、当該データを、当該データの宛先アドレスを持つノードが存在する拠点ネットワークに向けて送信する第１ルーティング手段と、
拠点ネットワークから送信されたデータを受信し、当該データを、当該データの送信元アドレスに対応するアプリケーションに向けて送信する第２ルーティング手段と、を備え、
前記第２ルーティング手段は、前記拠点ネットワークのノードから送信されたデータに共通ヘッダが付加された共通ヘッダ付きデータを受信し、当該共通ヘッダに含まれる送信元アドレスに対応するアプリケーションに向けて当該共通ヘッダ付きデータを送信する
ことを特徴とする通信システムが提供される。

開示の技術によれば、既存のアプリケーションに変更を加えることなく、複数の拠点ネットワークとアプリケーションとを接続することを可能とする技術が提供される。

ＲＡＮの例を示す図である。 ＲＡＮの例を示す図である。 ゲートウェイ方式を示す図である。 ブリッジ方式を示す図である。 広域化のシステム構成の例を示す図である。 広域化後の統合化前のシステム構成の例を示す図である。 本発明の実施の形態に係るシステム構成例（広域化後の統合化後のシステム構成）を示す図である。 擬似親機１００と擬似アプリケーション端末２００の機能構成を示す図である。 ルーティングテーブル生成機能を説明するための図である。 ルーティング機能を説明するための図である。 アクセス制御機能を説明するための図である。 複数データセンタへの拠点側アクセス制御を説明するための図である。 複数データセンタへの拠点側アクセスルーティングを説明するための図である。 本実施の形態におけるＷＡＮの構成例を示す図である。 本実施の形態におけるＷＡＮの構成例を示す図である。 スイッチサーバ４００を使用した場合のシステム構成図である。 スイッチサーバ４００の機能構成図である。 システムの動作を説明するためのシーケンス図である。 システムの動作を説明するためのシーケンス図である。 システムの動作を説明するためのシーケンス図である。 ホワイトリストとルーティングテーブルの生成例を説明するための図である。 生成する情報の例を示す図である。 コントローラ５００の機能構成図である。 分散スイッチ群を使用した場合のシステム構成を示す図である。 共通ヘッダの構成例を説明するための図である。 変形例におけるシステムの動作例を説明するための図である。 変形例におけるシステムの動作例を説明するための図である。 装置のハードウェア構成の例を示す図である。

以下、図面を参照して本発明の実施の形態（本実施の形態）を説明する。以下で説明する実施の形態は一例に過ぎず、本発明が適用される実施の形態は、以下の実施の形態に限られるわけではない。例えば、本実施の形態では、広域化する対象の拠点のネットワークの例としてＺｉｇＢｅｅ ＲＡＮを使用しているが、本発明を適用できるネットワークはＺｉｇＢｅｅ ＲＡＮに限られない。例えば、ＲＡＮ内に存在するＣｏｏｒｄｉｎａｔｏｒ相当のノードが宛先のＬ２アドレスを与えられた時に、適切にルーティングできる機能を持つ無線ネットワークであればどのようなネットワークでもよい。

（実施の形態の概要）
本実施の形態では、現在稼働している非ＩＰのＲＡＮを構成する要素である、ＲＡＮノードハードウェア、ファームウェア、及びアプリケーションソフトウェアに一切の改造を加えることなく、広域化、スケールアウト、及び多重化を実現する。本実施の形態は、アプリケーション及び、ＲＡＮノードをＩＰ化して実現するのではなく、ＩＰネットワークは単なる手段としてＲＡＮ及びアプリケーションからは隠蔽されている。

本実施の形態では、アプリケーションからは、複数のＲＡＮが統合された一つの大きなＲＡＮとして見えるような広域化を実現する。これを実現するために、本実施の形態に係るシステムでは、アプリケーションの発信したデータが、どのＲＡＮ、すなわちＬ２トンネルに属しているのかをＷＡＮ側で認識して振り分ける機能を持つ。Ｌ２トンネルに属するノードを管理することで、拠点側では複数のＲＡＮが存在し、複数のＬ２トンネルが開設された場合にも適切なトンネルにデータが送れるようになる。

本実施の形態では、単にＷＡＮで小規模なネットワークの広域化を実現するのみではなく、小規模な複数のネットワークを統合することで一つの大きなネットワークに見せるスケールアウト、及び多対多接続を行うことで一拠点に複数のＲＡＮが存在した場合にも適切なアプリケーションへのアクセスを許容する多重化を合わせて実現している。

（用語について）
以下、本実施の形態で使用する用語について説明しておく。なお、以下で説明する用語の意味は、必ずしも以下の説明の内容に限定されるわけではない。

ＲＡＮ：小規模な無線エリアネットワーク。本実施の形態ではＺｉｇＢｅｅを想定する。ＩＰのようなネットワークレイヤ機能を持たず、Ｌ２アドレスを指定することでＲＡＮに属するノードが指定されるデータリンクレイヤ機能のみを持つ。いわゆる非ＩＰネットワークである。

親機：アプリケーションと直接接続されるＲＡＮ内ノード。ＲＡＮに一つ存在する。多くのＲＡＮでは、親機はホストコンピュータとシリアルインタフェースで接続される。ＺｉｇＢｅｅのｃｏｏｒｄｉｎａｔｏｒは親機の例である。

アプリケーション：全てのノードが通信する対象のソフトウェア。例えば温度センサを持つノードを持つＺｉｇＢｅｅネットワークに対するアプリケーションは温度データを収集、蓄積する機能を持つ。通信相手は親機であるため、シリアルインタフェースを読み書きする。ＲＡＮはＩＰ化されていないため、アプリケーションもＩＰ対応になっていない。

前述したとおり、本実施の形態では、「アプリケーション」を、特に断らない限り、ソフトウェアをコンピュータ上で実行させることにより実現される機能として使用している。上記は、当該機能の説明である。

ＷＡＮ：ＲＡＮ（の親機）とアプリケーション間に挿入されるＩＰネットワーク上で動作するＬ２トンネルで構成されるネットワーク。

広域化：ＲＡＮ（の親機）とアプリケーションをＩＰネットワークを使い遠隔接続すること。つまり、ＲＡＮの広域化とはＲＡＮノード間の距離を拡大するのではなく、ｃｏｏｒｄｉｎａｔｏｒ等の親機とアプリケーション間の距離を拡張することで、遠隔でＲＡＮへのアクセスを可能にすることである。

スケールアウト：広域化により、一つのアプリケーションに複数拠点からＲＡＮが接続された場合にも、アプリケーションは個々のＲＡＮを識別することなく、一つのＲＡＮに接続されているように見せること。

多重化：一つの拠点に複数のＲＡＮが存在する場合にはアプリケーションも複数存在する。このようなネットワークが広域化された場合にも、ノードが適切なアプリケーションと通信できるように、ＷＡＮがアクセス制御を行うこと。ルーティングを使って一つのＲＡＮに接続されている複数のノードを論理的に分離して、あたかも複数のＲＡＮが一拠点に存在しているように見せる手法も含む。

ルーティング：アプリケーションや、ＲＡＮ内のノードから得られたデータを、どのトンネルに送出すべきかを決定する機能。トンネルから得られたデータは、アプリケーションもしくは親機に転送されるためルーティングは必要ない。親機に転送されたデータは、ＲＡＮの機能により適切なノードまで届けられるため、ＷＡＮでのルーティングは行われない。ＷＡＮでのルーティングは、データを送出すべき適切なトンネルの選択である。

（広域化のアーキテクチャについて）
本実施の形態におけるＷＡＮのベースとなっている広域化のアーキテクチャについて説明する。このアーキテクチャ自体は非特許文献３、４、特許文献１等に記載されているものであるため、以下では概要を説明している。

本実施の形態では、図３に示したＺｉｇＢｅｅ−ＩＰゲートウェイ方式とは異なり、図４に示すように、トンネルを使用したブリッジ方式を採用している。この方式では、アプリケーション３０はシリアルインタフェースへの読み書きを行う非ＩＰソフトウェアのまま、追加されたトンネル終端の機能１０、２０を使用することで、広域化を実現できる。すなわち、もともとＲＡＮの敷設されている拠点と同一拠点で動作していた非ＩＰ対応のアプリケーションに改造を加えることなく、そのままデータセンタに移動させることを可能としている。なお、特許文献１等に記載された従来技術のみではスケールアウトは実現できず、そのために後述するルーティング等の仕組みが必要である。

図５は、広域化のアーキテクチャをより詳細に示した図である。親機（ｃｏｏｒｄｉｎａｔｏｒ）とアプリケーション３０間はインターネットやＶＰＮのようなＩＰネットワーク５０で接続されている。トンネルは、アプリケーション３０と親機間のＬ２フレームを疎通させるＬ２トンネルであり、例えばＬ２ＴＰｖ３（非特許文献５）などを使用することができる。

トンネルの両端にはトンネル終端機能をもつソフトウェアがコンピュータ上に配置される。

ＲＡＮ４０側に配置されるソフトウェアは親機（ｃｏｏｒｄｉｎａｔｏｒ）にとってみれば、アプリケーションのように見えるので擬似アプリケーションと呼ぶ。なお、擬似アプリケーションは、コンピュータ（端末）で実行されることによりその機能を実現するので、その端末を擬似アプリケーション端末２０と呼び、図５にもそのように記載している。

一方アプリケーション３０側に配置されるソフトウェアがコンピュータ上で動作することにより実現される機能は、アプリケーション３０によってはＲＡＮ４０の親機として振る舞うために、擬似親機１０と呼ぶ。擬似親機１０は単独の装置であってもよいし、アプリケーション３０が動作する装置（コンピュータ）と同じ装置であってもよい。

擬似アプリケーション端末２０は、擬似親機１０との間でトンネルを生成する。ＲＡＮ４０側との接続はシリアルインタフェースを介しており、当該インタフェースから読み込んだデータをトンネルに送信する。また、トンネルから読み出したデータはシリアルインタフェースに送信する。図５に示すＬ２送受信部２２が、シリアルインタフェースとの間のデータ送受信を行い、トンネル終端部２１が、トンネルとの間のデータ送受信を行う。

トンネルプロトコルについては、データ送信と制御信号が重畳できることが望ましい。例えばＬ２ＴＰｖ３では、データ送受信とは別に制御信号の送受信ができるので、本システムに適用可能であるが、Ｌ２ＴＰｖ３に限定するものではない。

図５に示すとおり、擬似親機１０はアプリケーション３０側で動作し、擬似アプリケーション端末２０との間でトンネルを開設する。擬似アプリケーション端末２０から送られてきたデータは、ＲＡＮ４０の親機から読み取られたデータであるので、アプリケーション３０に渡される。アプリケーション３０から発信されたデータはＲＡＮ４０の親機に渡されるべきなので、トンネルに送信されＲＡＮ４０に送られる。

アプリケーション３０は非ＩＰであることが多く、ＲＡＮ４０とのデータのやりとりはシリアルインタフェースを介する。しかし、本実施の形態に係るシステムではアプリケーション３０側には実際にはＲＡＮ４０が存在しないので、シリアルインタフェースドライバ１１はハードウェアと接続されるのではなくＴＡＰとして擬似親機ソフトウェアと接続される形態をとる。図５に示すとおり、擬似親機１０は、ＴＡＰドライバ１１との接続通信を行うＬ２送受信部１２と、トンネルとの間のデータ送受信を行うトンネル終端部１３を含む。このような構成により、アプリケーション３０は、あたかも動作しているコンピュータのシリアルインタフェース経由でＲＡＮ４０に接続されているように振る舞える。このために広域化前と同じアプリケーションを広域化後にもそのまま使い続けることができる。

（スケールアウトのためのアーキテクチャについて）
上述した広域化アーキテクチャをそのまま複数のＲＡＮに適用し、トンネル毎にシリアルインタフェースを生成して一つのアプリケーション３０からアクセスさせることは可能である。この場合、図６に示すように、一台のコンピュータに複数のシリアルインタフェースが搭載され、擬似親機１０Ａ、１０Ｂ、１０Ｃを介して、その各々にＲＡＮが接続されているような構成になる。この方法では、アプリケーション３０は、個々のＲＡＮにどのノードが接続されているのかを管理する必要がある。アプリケーション３０は、あるＲＡＮノードにアクセスしようとすると、どのシリアルインタフェースに対してデータを書き込むべきかを知っていなければならない。

Ｌ２アドレスが与えられたときに、どのＲＡＮにデータを送信すべきかを決定する機能をルーティングということとする。ＲＡＮが広域化されていない場合に、数十メートルの範囲内で複数のＲＡＮが同時に存在してそれを一つのアプリケーションからアクセスするようなケースは稀であると考えられ、複数ＲＡＮが共存したとしても、それぞれに別のアプリケーションが存在して、その各々のアプリケーションは一つのＲＡＮのみアクセスすると考えられる。

すなわち既存のアプリケーションはルーティング機能を持っていないと想定される。また、運用中に、エンドノードが異なるＲＡＮに接続替えをされた場合、アプリケーションは即時にその事実を知るすべがない。このために、図６に示す方式では、広域化ができても複数のＲＡＮに同時アクセスするスケールアウトが実現できない。従って、これを実現するには、アプリケーションにルーティング機能を追加する改造を加えなければならない。これではアプリケーションをそのまま使うという目的を達成することができない。

（本実施の形態に係るシステムの基本構成）
そこで、本実施の形態では、擬似親機側にルーティング機能（詳細は後述）を備えることで、図７に示す構成を可能としている。図７に示す構成では、複数のＲＡＮが集約されていたとしても、アプリケーション３０からはそれが論理的に統合され一つの巨大なＲＡＮに見える。つまり、広域化とスケールアウトをアプリケーションの変更なく実現できる。なお、図７は概要を示しており、アプリケーション３０側の擬似親機１００とともに、ＲＡＮ側において擬似アプリケーション端末２００が存在する。擬似親機１００と擬似アプリケーション端末２００とを有するシステムは、通信システムの例である。

図８は、擬似親機１００と擬似アプリケーション端末２００の機能構成を示す図である。図８に示すように、擬似親機１００は、通信部１１０、端末管理機能部１２０、ルーティング機能部１３０、端末制御機能部１４０、記憶部１５０を含む。これらの機能部のうち、通信部１１０は、既に説明したＬ２送受信部１２やトンネル終端部１３、及び、トンネル生成機能等、データの通信に関わる機能を有する。記憶部１５０は各種のテーブルやデータを格納する。端末管理機能部１２０、ルーティング機能部１３０、端末制御機能部１４０の機能については追って詳細に説明する。

擬似アプリケーション端末２００は、通信部２１０、端末管理機能部２２０、アクセス制御部２３０、記憶部２４０を含む。これらの機能部のうち、通信部２１０は、既に説明したＬ２送受信部２２やトンネル終端部２１、及び、トンネル生成機能等、データの通信に関わる機能を担う。記憶部２４０は各種のテーブルやデータを格納する。端末管理機能部２２０、端末管理機能部２２０、アクセス制御部２３０の機能については追って詳細に説明する。

（ルーティングテーブルの生成について）
擬似親機１００は１インスタンスで複数のＬ２トンネルを収容することが可能であり、アプリケーション３０との間は一つのシリアルインタフェースドライバで接続する。アプリケーション３０の発信するデータには宛先であるＬ２アドレスが含まれるが、その宛先のノードがどのＲＡＮに所属しているのかを知っていなければ、適切なトンネルを選び出しデータを送信することができない。そこで、本実施の形態では、図９に示すようにして、ルーティングテーブルを生成することとしている。

図９に示すように、擬似アプリケーション端末２００の端末管理機能部２２０は、擬似アプリケーション端末２００に接続されているＲＡＮ上のノードのＬ２アドレスの一覧を、接続中端末管理テーブル２５０として記憶部２４０に保持し、管理している。端末管理機能部２２０は、擬似アプリケーション端末２００に接続されているＲＡＮに所属する全てのノードのＬ２アドレスをトンネルＴ１を介して擬似親機１００に通知する。

擬似親機１００の端末管理機能部１２０は、トンネル毎に受信するＲＡＮのノードのＬ２アドレス一覧表からルーティングテーブル１６０を生成し、当該ルーティングテーブル１６０を記憶部１５０に格納する。図９に示すように、ルーティングテーブル１６０は、Ｌ２アドレスとそのノードが存在するＲＡＮが接続されるトンネルのトンネルＩＤ（拠点を識別する情報でもある）とを対応付けた構造を有する。端末管理機能部１２０は、トンネルを介して受信したＬ２アドレスと、当該トンネルのトンネルＩＤとを対応付けることでルーティングテーブル１６０を生成することができる。

擬似アプリケーション端末２００の端末管理機能部２２０は、ＲＡＮに新しいノードが接続されたり、接続ノードが離脱したりすると、接続中端末管理テーブル２５０を更新する。端末管理機能部２２０は、接続中端末管理テーブル２５０に更新があると、接続中端末管理テーブル２５０に対応するトンネルの先の擬似親機１００に、更新イベント（例：Ａ４追加、Ａ３削除等）を送信する。更新イベントを受信した擬似親機１００の端末管理機能部１２０は、更新イベントの内容に応じて、ルーティングテーブル１６０へのアドレス追加や削除を行う。これにより、擬似親機１００側のルーティングテーブル１６０を最新情報に維持できる。

（ルーティング機能について）
次に、擬似親機１００のルーティング機能部１３０によるルーティングの処理動作について、図１０を参照して説明する。

アプリケーション３０は一つのシリアルインタフェースを介して、ＲＡＮに対してデータ通信を試みる（データを送信する）。擬似親機１００がアプリケーション３０からデータを受信すると、ルーティング機能部１３０は、データに含まれる宛先Ｌ２アドレスを抽出し、当該宛先Ｌ２アドレスに基づきルーティングテーブル１６０を検索することにより、当該宛先Ｌ２アドレスに対応するトンネルＩＤを抽出し、データを送信すべきトンネルを得ることができる。ルーティング機能部１３０が当該トンネルにデータを送り出すことで、データは宛先のＲＡＮに届き、ＲＡＮ内で宛先のノードまで届けられる。図１０の例では、宛先Ｌ２アドレス＝Ａ３に対し、トンネルＴ１が探し出されたことが示されている。

本実施の形態において、擬似親機１００がトンネルから受信したデータは全てアプリケーション３０に送られるだけなので、トンネルから受信するデータについてのルーティング機能は不要である。ルーティング機能が動作するのは、アプリケーション３０からトンネルへの方向のみである。

擬似親機１００にルーティング機能部１３０を実装することにより、アプリケーション３０は１つの擬似親機１００のみと接続されるので、実際には複数のＲＡＮが一箇所に集約されていても、アプリケーション３０からは論理的に一つのＲＡＮに接続されているように見える。これにより、アプリケーション３０に機能を追加することなく、複数拠点に展開される複数のＲＡＮを一つのアプリケーションインスタンスで動作させることができる。

従来より移動端末のモビリティを実現するための多数のネットワークアーキテクチャが提案されてきており、非特許文献６、７ではそれらのサーベイが報告されている。特にトンネルを使ってルーティングテーブルを生成する方式としてＭｏｂｉｌｅＩＰが知られている（非特許文献８、９）。ただしこれらの方式は、もともとネットワークアドレスの中に暗黙的に埋め込まれていたロケーションＩＤと端末識別子としてのネットワークアドレス（ＩＰではネットワークマスクとホストＩＤが相当する）を分離して、端末のモビリティを実現することを目的としている。一方、本実施の形態に係る技術ではＬ２アドレスそのものを使ってルーティングのキーとする点が異なっている。

本実施の形態に係る技術は、積極的にノードのモビリティを推奨することを目的とするものではなく、あくまで狭いエリアで使われていたＲＡＮを広域化、スケールアウトすることを目的とする。ただし、本発明はこの目的に限定されるわけではない。このＲＡＮに接続されているノードのＬ２アドレスを管理することで、副次的にノードのモビリティが実現される。

（アクセス制御機能）
次に、アクセス制御機能に関して図１１を参照して説明する。

上記のように、擬似親機１００にルーティングテーブル１６０を持たせたが、本実施の形態では、更に、擬似親機１００に、ルーティングテーブル１６０と同一構造を持つホワイトリスト１７０も持たせることでＲＡＮに接続できるノードを制御することとしている。ホワイトリスト１７０はアクセスコントロールリストの一例である。

ホワイトリスト１７０は、ＲＡＮに接続を許可するＬ２ノードリストであり、記憶部１５０に格納される。ルーティングテーブル１６０は、ＲＡＮに接続されているノード一覧の現在の状態を示すテーブルであるが、ホワイトリスト１７０は、接続許可するノードを示す設定情報であり、図１１に示すとおり、Ｌ２アドレスと、トンネルＩＤ（ＲＡＮ名と同義）とを対応付けたリストである。

ホワイトリスト１７０は、端末制御機能部１４０により使用される。端末制御機能部１４０は、Ｌ２アドレスを、当該Ｌ２アドレスに対応するトンネルを介して指定することで、当該Ｌ２アドレスのノードが、当該トンネルに対応するＲＡＮに接続可能か否かを制御する機能部である。

ホワイトリスト１７０が、例えば運用者より擬似親機１００に与えられると、擬似親機１００は、トンネルＩＤ毎に（つまり、ＲＡＮ毎に）接続を許可するノードのＬ２アドレス一覧を擬似アプリケーション端末２００側に通知する。

擬似アプリケーション端末２００におけるアクセス制御部２３０は、擬似親機１００からあるトンネル（図１１の例ではトンネルＴ１）を介して受信したＬ２アドレス一覧をホワイトリスト２６０（接続許可ノードリストと呼んでもよい）として記憶部２４０に格納する。

ＲＡＮに新たなノードが接続を試みた場合には、当該ノードのＬ２アドレスが擬似アプリケーション端末２００のアクセス制御部２３０に通知される。アクセス制御部２３０は、ホワイトリスト２６０に存在するノードのみＲＡＮへの接続を許可し、リストに存在しないノードが接続を試みても接続できない。

また、アクセス制御部２３０は、ＲＡＮへのノードの接続をホワイトリスト２６０に関わらずに許可し、ノードからトンネルを介した通信を要求され場合に、ホワイトリスト２６０によるアクセス制限を実行することとしてもよい。この場合、ノードから送信されたデータの送信元Ｌ２アドレスがホワイトリスト２６０にあれば通信は許可され、なければ通信は拒否される。

本実施の形態では、様々な拠点に存在する複数の擬似アプリケーション端末の各々にホワイトリストを投入するのではなく、アプリケーション３０の存在する擬似親機１００側で一括して複数の擬似アプリケーション端末にホワイトリストを投入できるので、制御が容易になる。

一つのノードが複数のＲＡＮで接続許可されることも可能であり、その場合にはあるＲＡＮに接続中のノードが別のＲＡＮに移動できる。その場合には、前述した端末管理機能部２２０により、移動の状況が擬似親機１００に送られるため、ルーティングテーブル１６０で当該ノードの接続中のトンネルＩＤが移動先ＲＡＮへの接続トンネルに変化する。これにより、ノードがＲＡＮを移動してもアプリケーション３０との通信が可能になる。

（複数データセンタへの拠点側アクセス制御について）
一つの拠点の一つのＲＡＮは一つのアプリケーションと通信を行うこととする場合、拠点側に複数のＲＡＮが存在する場合には、それぞれのＲＡＮは別のアプリケーションと通信するために、擬似アプリケーション端末２００は、ＲＡＮごとにトンネルを生成する。つまり、複数の擬似親機に対してトンネルを開設する。トンネルの接続先は異なる擬似親機である。なお、複数の擬似親機の設置場所は同じでもよいし異なっていてもよい。ＲＡＮごとに一つ親機が存在するので、シリアルインタフェースもＲＡＮの数だけ生成される。

図１２に示す例では、アプリケーションＡと通信するＲＡＮ−Ａに対して、擬似アプリケーション端末２００は、擬似親機１００Ａとの間にトンネルＡを生成し、アプリケーションＢと通信するＲＡＮ−Ｂに対して、擬似アプリケーション端末２００は、擬似親機１００Ｂとの間にトンネルＢを生成する。

図１２に示すように、擬似親機１００Ａはホワイトリスト２６０ＡをトンネルＡを介して擬似アプリケーション端末２００に通知する。擬似親機１００Ｂはホワイトリスト２６０ＢをトンネルＢを介して擬似アプリケーション端末２００に通知する。擬似アプリケーション端末２００は、個々のトンネルよりホワイトリスト２６０Ａ、２６０Ｂを受信し、トンネルに対応付けてホワイトリスト２６０Ａ、２６０Ｂを記憶部２４０に格納する。トンネルとＲＡＮが一対一で対応付けられるので、擬似親機側から送られてきたホワイトリスト２６０Ａ、２６０Ｂは、そのまま対応するＲＡＮのアクセス制御リストとして使用される。

対応するＲＡＮに接続しようとするノードがあれば、ホワイトリストにそのノードが載っている場合に接続を許可する。例えば、図１２に示すように、ノードＢ３（Ｌ２アドレスとしてＢ３を持つノード）は、Ｂ３を含むホワイトリスト２６０Ｂに対応するＲＡＮ−Ｂへの接続を許可されるが、Ｂ３を含まないホワイトリスト２６０Ａに対応するＲＡＮ−Ａへの接続を許可されない。従って、Ｂ３の通信先は擬似親機１００Ｂを介したアプリケーションＢとなる。なお、ホワイトリスト２６０Ａ／ホワイトリスト２６０Ｂにより、ノードから受信したデータの送出方路を決定できるので、ホワイトリスト２６０Ａ／ホワイトリスト２６０Ｂをルーティングテーブルの一種と考えてもよい。

（複数データセンタへの拠点側アクセスルーティングについて）
上記のホワイトリストの仕組みに基づいて、一つのＲＡＮを複数の論理的なネットワークに分割することも可能になる。

例えば、ホームネットワークでは、アプリケーションごとにＣｏｏｒｄｉｎａｔｏｒノード（親機）を設置して、個々のノードがどのＲＡＮに接続すべきかの設定を行うことが考えられるが、ネットワーク知識の乏しい利用者がそのような設定をするのは困難である。

そこで、ＷＡＮの運用事業者が親機（Ｃｏｏｒｄｉｎａｔｏｒ）を１台設置して、ホームネットワークのノードは全てそこに接続させることで、一つのＲＡＮとすることができ、設定運用の稼働量や難易度を低減することができる。

上記のネットワークの例を図１３に示す。上記のとおり、拠点側に複数の親機を設置するのではなく、一つのＲＡＮに複数の論理的ネットワークを混在させることで、多重化を実現する。ＲＡＮは一つであるが、図１３の例では２つの論理ネットワークが混在している。

ＲＡＮは一つであるが、擬似アプリケーション端末２００では、例えば端末管理機能部２２０に、後述するコントローラ５００等から論理ネットワークの情報を与えることで、端末管理機能部２２０の指示に基づき、論理ネットワークの数だけトンネルを生成する。図１３の例では、一つのＲＡＮにＡとＢという二つの論理ネットワークが混在している場合を示しており、親機を含むノードは、論理ネットワークのいずれかに所属する。Ａの論理ネットワークに対応するトンネルＡが、アプリケーションＡに対応する擬似親機Ａとの間に生成され、Ｂの論理ネットワークに対応するトンネルＢが、アプリケーションＢに対応する擬似親機Ｂとの間に生成される。

既に説明したように、各擬似親機は接続を許可するＬ２アドレスリスト（ホワイトリスト２６０Ａ、２６０Ｂ）をトンネルを用いて擬似アプリケーション端末２００に配信する。擬似アプリケーション端末２００において、アクセス制御部２３０が、各トンネルから受信したホワイトリスト２６０Ａ、２６０ＢをトンネルＩＤに対応付けて記憶部２４０に格納する。

得られた複数のホワイトリスト２６０Ａ、２６０Ｂのいずれかにアドレスが記載されているノードはＲＡＮへの接続を許可される。

図１３に示す二つの論理ネットワークが混在している場合において、例えばノードＢ３は異なる論理ネットワークのノードＡ２をルータとして利用してＲＡＮに接続している。ノードＢ３から発信されたデータは、異なる論理ネットワークのノードを経由して擬似アプリケーション端末２００に届く。

擬似アプリケーション端末２００では、アクセス制御部２３０が、発信元アドレスをキーとしてホワイトリスト２６０Ａ、２６０Ｂを検索する。この場合、トンネルＢに対応するホワイトリスト２６０Ｂに該当エントリがあるために、アクセス制御部２３０は、データをトンネルＢに送信し、当該データはアプリケーションＢに届けられる。一方、論理ネットワークＡに属するノードから発信されたデータはトンネルＡに送られ、アプリケーションＡに届けられる。これにより、一つのＲＡＮでありながら内部は複数のネットワークに論理的に分割することができる。

上記の仕組みは、トンネルという論理インタフェースと、実質的なルーティングテーブルであるホワイトリストを利用した、発信元アドレスをキーとするポリシールーティングによるＲＡＮ多重化機能と呼ぶことができる。

（ＷＡＮの構成例１）
図１４に、ＲＡＮの広域化、スケールアウト、アクセス制御、多重化を実現するＷＡＮの構成例を示す。図１４おいて、Ａ、Ｂ、Ｃはアプリケーションを識別する符号であり、１、２、３は拠点を識別する符号である。図１４に示すとおり、各拠点において、アプリケーションＡ、Ｂ、Ｃと通信を行うＡ、Ｂ、ＣのＲＡＮが接続されている。

例えば、拠点１には、ＲＡＮ １−Ａ、ＲＡＮ １−Ｂ、ＲＡＮ １−Ｃが接続されている。ＲＡＮ １−Ａ、ＲＡＮ １−Ｂ、ＲＡＮ １−Ｃはそれぞれ、物理的に別々のネットワークであってもよいし、図１３で説明したような論理ネットワークであってもよい。これまでに説明したとおり、擬似アプリケーション端末２００−１における発信元アドレスをキーとするルーティングにより、ＲＡＮ １−ＡからのデータはアプリケーションＡへ送信され、ＲＡＮ １−ＢからのデータはアプリケーションＢへ送信され、ＲＡＮ １−ＣからのデータはアプリケーションＣへ送信される。拠点２、３に関しても同様である。

一方、擬似親機１００側について、例えば、アプリケーションＡに対応する擬似親機１００Ａは、擬似アプリケーション端末２００−１、２００−２、２００−３のそれぞれから受信する接続中端末（アプリケーションＡに対応するノード）のＬ２アドレスに基づいて、ルーティングテーブルを生成する。また、擬似親機１００Ａは、アプリケーションＡからデータを受信すると、データの宛先Ｌ２アドレスとルーティングテーブルに基づいて、データの方路（トンネル）を決め、データを当該方路に送信する。擬似親機１００Ｂ、擬似親機１００Ｃに関しても同様である。

上記のように、Ｌ２トンネル、擬似親機側のルーティング、及び擬似アプリケーション端末におけるアクセス制御もしくはルーティングによって、ＲＡＮノード及びアプリケーションに一切の機能追加などの改造を行うことなく、広域化、スケールアウト、アクセス制御、多重化を実現することができる。

（ＷＡＮの構成例２）
図１５は、図１４に示したＷＡＮの構成をより具体的に示した例を示す。図１５の例では、アプリケーション側において、アプリケーションと擬似親機とが１つのユーザマシン（コンピュータ）に搭載される。また、各擬似アプリケーション端末では、１つの親機が例えばＵＳＢケーブルにより、擬似アプリケーション端末（コンピュータ）に接続され、各アプリケーション対応のＲＡＮは論理ネットワークとして構成されている。

例えば、拠点１の擬似アプリケーション端末２００−１は、擬似親機１００Ａ、擬似親機１００Ｂ、擬似親機１００Ｃのそれぞれとの間でＬ２トンネルを開設する。擬似アプリケーション端末２００−２、２００−３についても同様である。

Ｌ２トンネルを開設する契機の例を説明する。例えば、擬似アプリケーション端末２００−１配下のＲＡＮにおいてアプリケーションＢ対応のノードが接続されていない状態で、コントローラ５００から擬似アプリケーション端末２００−１に対して、アプリケーションＢ対応のノードが接続されることを示す情報（例えば、アプリケーションＢに対応する所有者情報）が送信されると、擬似アプリケーション端末２００−１はその情報の受信を契機に、アプリケーションＢ側の擬似親機１００ＢとのＬ２トンネルを開設する。

上記のように、Ｌ２トンネルが開設された後に、擬似アプリケーション端末側と擬似親機側において図１４を参照して説明した動作が実行される。

（ＷＡＮの構成例３）
図１５に示した構成でも、ＲＡＮノード及びアプリケーションに一切の機能追加などの改造を行うことなく、広域化、スケールアウト、アクセス制御、多重化を実現することができるが、トンネル管理の負荷や、各マシン、各端末でのルーティング負荷が増大することが考えられる。

そこで、図１６に示すように、スイッチサーバ４００を備えるＷＡＮ構成としてもよい。当該スイッチサーバ４００は通信システムの例である。図１６に示すＷＡＮ構成では、各擬似親機及び各擬似アプリケーション端末は、スイッチサーバ４００との間で１つのトンネルを張ればよい。また、図１６には、トンネルの開設方向が示されるが、トンネルの通信方向は双方向である。スイッチサーバ４００には、各擬似親機、もしくは、スイッチサーバ４００に接続されるコントローラ５００から、各アプリケーションに対応するホワイトリストが通知される。スイッチサーバ４００は、当該ホワイトリストを参照することで、図１１〜１３を参照して説明した擬似アプリケーション端末側の発信元アドレスに基づくアクセス制御及びルーティングを行うことができる。なお、図示の便宜上、図１６では、コントローラ５００と、ユーザマシンＡ（３００Ａ）、スイッチサーバ４００、擬似アプリケーション端末２００−１が接続されるように示されているが、コントローラ５００は、ユーザマシンＢ（３００Ｂ）、ユーザマシンＣ（３００Ｃ）、擬似アプリケーション端末２００−２、擬似アプリケーション端末２００−３とも接続される。

また、スイッチサーバ４００は、各アプリケーションのホワイトリストを各擬似アプリケーション端末に送信することで、アクセス制御を各擬似アプリケーション端末に行わせることとしてもよい。この場合でも、発信元アドレスに基づくルーティングについてはスイッチサーバ４００が実行する。

一例として、図１２に示したホワイトリスト２６０Ａとホワイトリスト２６０Ｂをスイッチサーバ４００が保持している場合において、スイッチサーバ４００がトンネルＴ１からポート１を介して、発信元アドレスがＢ２であるデータを受信したとすると、ホワイトリスト２６０ＢにＢ２のエントリがあるので、当該データは、ホワイトリスト２６０Ｂに対応するアプリケーションＢ向けのポートＢにスイッチサーバ４００内部で転送され（スイッチされ）、トンネルＴＢにより擬似親機１００Ｂに送られ、アプリケーションＢに届けられる。

なお、スイッチサーバ４００は、拠点別にホワイトリストを保持してもよいし、複数拠点共通のホワイトリストを保持してもよい。拠点別にホワイトリストを保持する場合、スイッチサーバ４００は、擬似アプリケーション端末側からデータを受信したトンネルに対応する拠点に対応するホワイトリストに基づいてルーティングを実施する。

また、図９を参照して説明したように、各擬似アプリケーション端末から接続中端末管理テーブルがスイッチサーバ４００に送信され、スイッチサーバ４００は接続中端末管理テーブルに基づきルーティングテーブルを生成して、当該ルーティングテーブルに基づき、アプリケーション側から送信されたデータのルーティングを実行する。

一例として、スイッチサーバ４００が、図９に示す接続中端末管理テーブルをトンネルＴ１から受信したとすると、スイッチサーバ４００は図９に示すルーティングテーブルを生成し、保持する。そして、例えば、アプリケーションＡから送信されたデータ（宛先アドレスがＡ１であるとする）を、トンネルＴＡから受信すると、当該データの宛先アドレスが上記ルーティングテーブルのエントリに合致するので、スイッチサーバ４００の内部で当該エントリのトンネルＴ１に接続されるポート１にデータが転送され、当該データは拠点１の擬似アプリケーション端末２００−１を介して、拠点１のＲＡＮ内で、ノードＡ１まで転送される。

図１７に、スイッチサーバ４００の機能構成図を示す。図１７に示すように、スイッチサーバ４００は、通信部４１０、端末管理機能部４２０、ルーティング機能部４３０、端末制御機能部４４０、記憶部４５０を含む。通信部４１０は、図１６に示した各ポートを含み、また、トンネルの生成機能、トンネルを使用したデータ送受信機能等を有する。また、通信部４１０は、後述するコントローラとの間で通信（情報の送受信）を行う機能も含む。

端末管理機能部４２０は、接続中端末管理テーブルから、ルーティングテーブル（アプリケーション側からＲＡＮ側への方向のルーティング用）を生成する機能を含む。端末制御機能部４４０は、ホワイトリストを受信し格納する機能、ホワイトリストを擬似アプリケーション端末側に送信する機能、ＲＡＮノードに対するアクセス制限機能等を含む。ルーティング機能部４３０は、ルーティングテーブルに基づくアプリケーション側からＲＡＮ側への方向のルーティングと、ホワイトリストに基づくＲＡＮ側からアプリケーション側へのルーティングを行う機能を含む。記憶部４５０は、各種のデータ、ルーティングテーブル、ホワイトリスト等を格納する。なお、ホワイトリストをルーティングテーブルと称してもよい。また、ルーティング機能部４３０は、変形例で説明する共通ヘッダからＬ２アドレス（ＭＡＣアドレス）を抽出する機能も有している。

図１８、図１９、図２０は、コントローラ５００を使用して、ＷＡＮの設定を行う場合における構成、シーケンスを示す。コントローラ５００は例えばＳＤＮコントローラであるがこれに限定されない。図１７に示したように、スイッチサーバ４００には、複数の擬似親機と複数の拠点の擬似アプリケーション端末が接続され得るが、図１８、図１９には、代表として１つの擬似親機１００と、１つの擬似アプリケーション端末２００が示されている。これらが複数であっても、同様のシーケンスが実行される。

図１８に示されるように、コントローラ５００は、擬似親機１００、擬似アプリケーション端末２００、スイッチサーバ４００のそれぞれと、例えばインターネットを介して通信可能である。図１８、図１９に示すシーケンスは同じであるので、以下、図１９を参照して説明する。

例えばユーザの端末からコントローラ５００に対し、認証要求とホワイトリストが送信され、コントローラ５００がこれらを受信する（ステップＳ１０１）。ユーザの認証ＯＫであれば、コントローラ５００はホワイトリストをスイッチサーバ４００に送信する（ステップＳ１０２）。

ある拠点のＲＡＮをＷＡＮ接続する際に、当該拠点の擬似アプリケーション端末２００は認証要求をコントローラ５００に送信し（ステップＳ１０３）、コントローラ５００による認証がＯＫであれば、コントローラ５００は、スイッチ情報（例：スイッチサーバ４００に接続するためのＩＰアドレス）と、擬似アプリケーション端末２００に対応する（つまり、その拠点に対応する）トンネルのトンネルＩＤとを擬似アプリケーション端末２００に送信する（ステップＳ１０４）。また、後述する変形例の動作を行う場合においては、ステップＳ１０４（図２０のＳ１０４でも同様）において、擬似アプリケーション端末２００に対して、共通ヘッダ生成に関わる設定情報（例：後述するオフセット、ＭＡＣアドレス長、ＭＡＣアドレスなしのＰＤＵに付加するＭＡＣアドレス等）が設定される。擬似アプリケーション端末２００は、ステップＳ１０４で受信した情報に基づき、トンネル開設要求をスイッチサーバ４００に送信することで、スイッチサーバ４００との間にトンネルを構築する（ステップＳ１０７）。ステップＳ１０８において、ホワイトリストが擬似アプリケーション端末２００に送信される。

同様にして、擬似親機１００は認証要求をコントローラ５００に送信し（ステップＳ１０５）、コントローラ５００による認証がＯＫであれば、コントローラ５００は、スイッチ情報（例：スイッチサーバ４００に接続するためのＩＰアドレス）と、擬似親機１００に対応する（つまり、そのアプリケーションに対応する）トンネルのトンネルＩＤとを擬似親機１００に送信する（ステップＳ１０６）。また、後述する変形例の動作を行う場合においては、ステップＳ１０６（図２０のＳ１０６でも同様）において、擬似親機１００に対して、共通ヘッダ生成に関わる設定情報（例：後述するオフセット、ＭＡＣアドレス長、ＭＡＣアドレスなしのＰＤＵに付加するＭＡＣアドレス等）が設定される。擬似親機１００は、ステップＳ１０６で受信した情報に基づき、トンネル開設要求をスイッチサーバ４００に送信することで、スイッチサーバ４００との間にトンネルを構築する（ステップＳ１０９）。

擬似アプリケーション端末２００からは接続中端末管理リスト（あるいは更新情報）がスイッチサーバ４００に送信される（ステップＳ１１０）。スイッチサーバ４００は、当該接続中端末管理リストに基づきルーティングテーブルを作成し、保持する。

ステップＳ１１１において、擬似親機１００から擬似アプリケーション端末２００へのトラフィックが送信される。この方向のトラフィックに対し、ルーティングテーブルにより、宛先アドレスに基づくルーティングが行われる。ステップＳ１１２において、擬似アプリケーション端末２００から擬似親機１００へのトラフィックが送信される。この方向のトラフィックに対し、ホワイトテーブルにより、発信元アドレスに基づくルーティングが行われる。

上記の例では、ホワイトリストをユーザからコントローラ５００に送信し、ルーティングテーブルを接続中端末管理リストから生成することとしたが、図２０に示すように、コントローラ５００がノード毎のＬ２アドレス、設置場所情報、所有者情報を、ユーザ端末あるいはＳＤＮ操作端末等から受信することで、これらからホワイトリストとルーティングテーブルを生成し、それらをスイッチサーバ４００に送信することととしてもよい。なお、ルーティングテーブルについては、生成、送信を行わないこととしてもよい。

また、コントローラ５００が、ノード毎のＬ２アドレス、設置場所情報、所有者情報の３つの情報全てを受信することは必須ではない。例えば、Ｌ２アドレス、設置場所情報、所有者情報の３つの情報のうち既知の情報がある場合、当該既知の情報を受信する必要はない。

ここでは、設置場所情報は拠点に対応する。所有者情報はアプリケーションに対応する。例えば、ノード１、ノード２、ノード３、ノード４の｛Ｌ２アドレス、設置場所情報、所有者情報｝として、コントローラ５００が下記の情報を受信したとする。

ノード１＝｛ＭＡＣ１、拠点１、Ａ｝
ノード２＝｛ＭＡＣ２、拠点１、Ａ｝
ノード３＝｛ＭＡＣ３、拠点１、Ｂ｝
ノード４＝｛ＭＡＣ４、拠点１、Ｂ｝
また、図２１に示すとおり、拠点１とスイッチサーバ４００間のトンネルＩＤをＴ１とし、アプリケーションＡ、Ｂ（つまり、擬似親機１００Ａ，Ｂ）とスイッチサーバ４００間のトンネルＩＤをそれぞれＴＡ、ＴＢとする。

この場合、コントローラ５００は、トンネルＴ１に対応するホワイトリスト２６０として図２２（ａ）に示すテーブルを作成する。また、トンネルＡに対応するルーティングテーブル１６０Ａとして図２２（ｂ）に示すテーブルを作成し、トンネルＢに対応するルーティングテーブル１６０Ｂとして図２２（ｃ）に示すテーブルを作成する。そして、これらをスイッチサーバ４００に送信する（図２０のステップＳ１０２）。

スイッチサーバ４００は、コントローラ５００から受信したホワイトリスト２６０とルーティングテーブル１６０Ａ、１６０Ｂを使用することにより、前述したとおりに、擬似親機１００側から擬似アプリケーション端末２００側へのルーティング（宛先アドレスに基づくルーティング）と、擬似アプリケーション端末２００側から擬似親機１００側へのルーティング（発信元アドレスに基づくルーティング）を行うことができる。

また、コントローラ５００からルーティングテーブル１６０Ａ、１６０Ｂを得るのではなく、図２０のステップＳ１１０に示すように、スイッチサーバ４００は、接続中端末管理リスト（又は、更新情報）を受信することで、ルーティングテーブルを生成、又は更新することとしてもよい。

なお、上記のようなコントローラ５００による情報配信は、図１５の構成、及び後述する図２４の構成にも適用可能である。図１５の構成では、コントローラ５００は、拠点毎にホワイトリストを作成し、設置場所情報に基づき、該当拠点の擬似アプリケーション端末に送信する。また、コントローラ５００は、アプリケーション毎にルーティングテーブルを作成し、所有者情報に基づき、該当アプリケーション側の擬似親機にルーティングテーブルを送信する。図２４の構成の場合も同様であるが、ホワイトリストの送信先が拠点側スイッチとなり、ルーティングテーブルの送信先がデータセンタ側スイッチとなる。

図２３は、コントローラ５００の機能構成図である。図２３に示すように、コントローラ５００は、情報通知部５１０、情報生成部５２０、認証部５３０、及び記憶部５４０を備える。

情報通知部５１０は、ユーザもしくは運用者の端末等から受信したホワイトリスト等の情報を受信し、スイッチサーバ４００に通知する。また、情報通知部５１０は、情報生成部５２０により生成された情報を該当の装置（スイッチサーバ４００等）に通知する機能も有する。変形例で説明する設定情報の送信動作は、この情報通知部５１０により実行される。

情報生成部５２０は、ユーザの端末等から受信したＭＡＣアドレス、設置場所情報、及び所有者情報から、ホワイトリスト及びルーティングテーブルを生成する。認証部５３０は、装置（ユーザの端末、擬似親機１００、擬似アプリケーション端末２００等）からの認証要求に基づき、当該装置の認証を行う。記憶部５４０は、他の装置から受信した情報、生成した情報、予め設定される設定情報（認証情報、拠点情報等）を格納する。

（システムの他の構成例）
図１６に示すＷＡＮの構成では、１つのスイッチ（スイッチサーバ４００）を使用しているが、ＷＡＮの規模が大きくなった場合等には、図２４に示すように、複数のスイッチである分散スイッチ群を使用してシステムを構成してもよい。

図２４に示す構成例では、アプリケーション側（データセンタ側）に、アプリケーション毎にデータセンタ収容スイッチ４００（Ａ〜Ｃ）が備えられ、拠点側に、拠点毎に拠点収容スイッチ４００（１〜３）が備えられている。データセンタ収容スイッチ４００（Ａ〜Ｃ）は、対応する擬似親機１００と１つのトンネルで接続される。また、拠点収容スイッチ４００（１〜３）は、対応する擬似アプリケーション端末と１つのトンネルで接続される。データセンタ収容スイッチ４００（Ａ〜Ｃ）と拠点収容スイッチ４００（１〜３）との間は、例えばインターネットで接続される。データセンタ収容スイッチ４００（Ａ〜Ｃ）と拠点収容スイッチ４００（１〜３）とを有するシステムは通信システムの例である。

各データセンタ収容スイッチには、ルーティングテーブルがコントローラ５００から設定される。各データセンタ収容スイッチは、アプリケーション側から受信したデータの宛先アドレスと、ルーティングテーブルとに従って、当該データを届けるべきＲＡＮが存在する拠点の拠点収容スイッチにデータを送信する。各データセンタ収容スイッチは、拠点側からデータを受信した際には、そのデータをトンネルを介して疑似親機に送信する。

各拠点収容スイッチには、ホワイトリストがコントローラ５００から設定される。各拠点収容スイッチは、ＲＡＮ側からデータを受信すると、当該データの発信元アドレスと、ホワイトリストとに従って、当該データを届けるべきアプリケーションが存在するデータセンタのデータセンタ収容スイッチにデータを送信する。また、各拠点収容スイッチは、データセンタ側からデータを受信した際には、そのデータをトンネルを介して疑似アプリケーション端末に送信する。

（変形例）
次に、変形例を説明する。変形例は、上述した図１６〜図２４で説明したスイッチサーバを用いるシステム構成に基づく例である。ただし、これに限定されるわけではなく、スイッチサーバを用いない構成において、擬似アプリケーション端末２００と擬似親機１００のそれぞれが、以下で説明する共通ヘッダの付加動作等を行うこととしてもよい。以下、端末（ノードと称してもよい）から送出されるデータフレームに共通ヘッダを付加する技術について説明する。

以下の説明において、システム構成としては、図１６に示すように、スイッチサーバ、擬似アプリケーション端末２００、擬似親機１００、及びコントローラ５００を有する構成を想定している。なお、擬似アプリケーション端末２００−１〜２００−３について、特にこれらを区別せずに動作等を説明する場合には、擬似アプリケーション端末２００と記述する。また、擬似親機１００Ａ〜１００Ｃについて、特にこれらを区別せずに動作等を説明する場合には、擬似親機１００と記述する。

これまでに説明した技術を使用することで、ＲＡＮに所属する複数の端末をそれぞれ事前に指定されたアプリケーションだけに接続することができる。上述した技術に基づき構築されたシステムに接続できるシリアルインタフェースを有する端末の条件として、送信するデータフレーム中に発信元のＬ２アドレス（ここでは例として、以下、ＭＡＣアドレスとする）が明示的に埋め込まれていることが必要である。

また、これまでに説明した通信システムにおいて、スイッチサーバ４００はデータフレームにおける発信元のＭＡＣアドレスの位置を認識しており、そのＭＡＣアドレスによってルーティングを行っている。そのため、データフレーム中にＭＡＣアドレスが存在しなければならず、更に、その位置や長さはデータフレーム毎に同じであることを前提としている。

ここで、データフレームのフォーマットは、特定省電力無線等ではＲＡＮ端末製造者により任意に決められており、埋め込まれているＭＡＣアドレスの場所や長さは様々である。

また、シリアルインタフェースを有する端末には一対一での接続を前提とするものも多く、その場合には、データフレームには発信元ＭＡＣアドレスが埋め込まれていない。例えば、ＧＮＳＳ／ＧＰＳ受信モジュールはＵＡＲＴ（Universal Asynchronous Receiver/Transmitter）インタフェースを有し、ホストコンピュータとはシリアルインタフェースで接続されるが、そのデータのフォーマットはＮＭＥＡ（National Marine Electronics Association）フォーマットと呼ばれるものであり、ＧＮＳＳ／ＧＰＳ受信モジュール自体にＭＡＣアドレスは割り当てられておらず、データフレーム中にもＧＮＳＳ／ＧＰＳ受信モジュールを特定するアドレスに相当する情報は含まれていない。このように、ＭＡＣアドレスを有しないデータに対しては、これまでに説明した技術ではスイッチサーバ４００によるルーティングを行うことができない。

そこで、変形例においては、接続するＲＡＮや端末の方式に応じて、データフレームからＭＡＣアドレスを抽出し、データフレームの固定位置に、本実施の形態に係る通信システムに共通的なフォーマットで、当該ＭＡＣアドレスのコピーを含むヘッダを付加する。ここでは、当該ヘッダを「共通ヘッダ」と呼ぶ。また、ＭＡＣアドレスを有しないデータフレームに関しては、予め割り当てたＭＡＣアドレス（これを擬似ＭＡＣアドレスと称してもよい）を有する共通ヘッダを付加する。擬似ＭＡＣアドレスは、共通ヘッダを付加する装置のＭＡＣアドレスであってもよい。

図２５を参照して、共通ヘッダの例を説明する。図２５（ａ）、（ｂ）、（ｃ）において、データフレームは、端末から送出されるものである。

図２５（ａ）の例では、共通ヘッダは、データフレームの中のＭＡＣアドレスＡ（図中の"Ａ"で記載）のコピーと、当該ＭＡＣアドレスＡの長さＬ−Ａ（ビット長）を有する。Ｌ−Ａのフィールドの長さは予め定めておく固定長である。

これにより、例えば、擬似アプリケーション端末２００から当該共通ヘッダ付きのデータフレームを受信したスイッチサーバ４００は、Ｌ−Ａにより、ＭＡＣアドレスＡの長さを知ることができるので、Ｌ−Ａフィールド（固定長）の末尾から、長さＬ−Ａの部分をＭＡＣアドレスＡとして識別し、当該ＭＡＣアドレスＡを使用して、ルーティングを実施することができる。ＭＡＣアドレスＡを認識した後の動作は既に説明した動作と同じである。

図２５（ｂ）の例は、共通ヘッダにおいて、Ｌ−Ａ、及び、ＭＡＣアドレスＡのコピーに加えて、データフレームの長さであるＬＰが追加されている点が図２５（ｂ）の例と異なる。なお、ＬＰはＰＤＵの長さであってもよい。

この場合、例えば、擬似アプリケーション端末２００から当該共通ヘッダ付きのデータフレームを受信したスイッチサーバ４００は、Ｌ−Ａにより、ＭＡＣアドレスＡの長さを知ることができるとともに、ＬＰにより、データフレームの長さを知ることができる。従って、例えば、データフレームの長さが不定であるような場合において、スイッチサーバ４００は、受信するデータ列の中からデータフレームを抽出することができる。

図２５（ｃ）の例は、データフレームがＭＡＣアドレスを含まない場合の例を示している。この場合、擬似アプリケーション端末２００は、接続されている端末から受信したＰＤＵにＭＡＣアドレスＡとＬ−Ａを含む共通ヘッダを付加する。この場合のＭＡＣアドレスＡは、例えば擬似アプリケーション端末２００のＭＡＣアドレスであってもよいし、予めコントローラ５００から擬似アプリケーション端末２００に設定しておいたＭＡＣアドレスでもよい。データフレームがＭＡＣアドレスを含まない場合においても、図２５（ｂ）のように、ＬＰを含む構成を用いてもよい。

擬似アプリケーション端末２００が、図２５（ａ）に示す共通ヘッダをデータフレームに付加するために、擬似アプリケーション端末２００には、予め図２５（ａ）に示すＯ−ＡとＬ−Ａがコントローラ５００から設定される。これらの設定情報は、擬似アプリケーション端末２００の記憶部に格納される。

図２５（ａ）に示すＯ−Ａは、例えば、ＲＡＮ−Ａにおける端末から送出されるデータフレームの先頭からＭＡＣアドレスＡの先頭までの長さ（ビット長）である。これをオフセットと称してもよい。Ｌ−ＡはＭＡＣアドレスＡの長さ（ビット長）である。

図２５（ａ）の例において、擬似アプリケーション端末２００は、ＲＡＮ−Ａの端末からデータフレームを受信すると、Ｏ−ＡとＬ−Ａにより、データフレーム中のＭＡＣアドレスＡを識別（抽出）し、Ｌ−Ａと当該ＭＡＣアドレスＡのコピーとを共通ヘッダとしてデータフレームの先頭に付加する。

図２５（ｂ）に示す例の場合、擬似アプリケーション端末２００には、予め図２５（ｂ）に示すＯ−Ａ、Ｌ−Ａ、ＯＬ−Ａ、及びＬＬ−Ａがコントローラ５００から設定される。この例では、図２５（ｂ）に示すように、ＬＰの値がデータフレーム中に格納されている。Ｏ−ＡはＭＡＣアドレスＡのデータフレーム先頭からの開始位置を示し、Ｌ−ＡはＭＡＣアドレスＡ長を示す。ＯＬ−Ａは、データフレーム長（ＬＰ）のデータフレーム先頭からの開始位置を示し、ＬＬ−Ａは、ＬＰが格納されるフィールドの長さを示す。このような構成により、擬似アプリケーション端末２００がシリアルインタフェース側からデータを読み取った時点で、ＬＰをデータフレームから読み取ることができる。なお、ＬＰの値はデータフレーム毎に異なる。

擬似アプリケーション端末２００は、ＲＡＮ−Ａの端末からデータフレームを受信すると、Ｏ−ＡとＬ−Ａにより、データフレーム中のＭＡＣアドレスＡを識別し、ＯＬ−ＡとＬＬ−Ａによりデータフレーム中のデータフレーム長（ＬＰ）を識別し、ＬＰの値のデータ量をＩＰカプセリングし、カプセリングしたデータフレームに、Ｌ−ＡとＬＰとＭＡＣアドレスＡのコピーとを共通ヘッダとしてデータフレームの先頭に付加する。ＩＰカプセリングを行うことは一例である。カプセリングを行わない形態や、ＩＰ以外のプロトコルでカプセリングを行う形態を採用してもよい。なお、図２５（ｂ）に示す例におけるＬＰで示す長さに関しては、ＩＰパケット長で推測できるが、トランスポートにＴＣＰを使用する場合には、データの先頭を見失う可能性があり、ＬＰを明示的に付加することで、受信側（例：スイッチサーバ４００）では正しく先頭を認識できる。

また、図２５（ａ）の例においても、データフレーム中にＬＰの値が含まれることとし、図２５（ｂ）の場合と同様に、Ｏ−Ａ、Ｌ−Ａ、ＯＬ−Ａ、及びＬＬ−Ａがコントローラ５００から設定され、データフレーム中から読み取ったＬＰを用いてカプセリング動作を行うこととしてもよい。ただし、ＬＰは共通ヘッダには含めない。

なお、ここでは、１種類のＲＡＮ（例：ＲＡＮ−Ａ）に接続される複数の端末間では、Ｏ−Ａ及びＬ−Ａは同一であると想定している。

擬似アプリケーション端末２００に複数種類のＲＡＮ（例：ＲＡＮ−Ａ、ＲＡＮ−Ｂ、ＲＡＮ−Ｃ）が接続される場合でも、図２５（ａ）、（ｂ）のように、各ＲＡＮに適合した共通ヘッダを付加することは可能である。以下、例として図２５（ｂ）の場合を説明する。

この場合、擬似アプリケーション端末２００には、コントローラ５００から下記の情報が予め設定される。

ＲＡＮ−Ａ用の情報＝｛Ｏ−Ａ、Ｌ−Ａ、ＯＬ−Ａ、ＬＬ−Ａ、ＲＡＮ−Ａのデータフレームの識別情報｝
ＲＡＮ−Ｂ用の情報＝｛Ｏ−Ｂ、Ｌ−Ｂ、ＯＬ−Ｂ、ＬＬ−Ｂ、ＲＡＮ−Ｂのデータフレームの識別情報｝
ＲＡＮ−Ｃ用の情報＝｛Ｏ−Ｃ、Ｌ−Ｃ、ＯＬ−Ｃ、ＬＬ−Ｃ、ＲＡＮ−Ｃのデータフレームの識別情報｝
上記において、Ｏ−Ｂ、Ｌ−Ｂ、ＯＬ−Ｂ、ＬＬ−Ｂは、それぞれＯ−Ａ、Ｌ−Ａ、ＯＬ−Ａ、ＬＬ−Ａと同様に、データフレームの先頭からＭＡＣアドレスまでのオフセット、ＭＡＣアドレスの長さ、データフレームの先頭からデータフレーム長（ＬＰ）までのオフセット、データフレーム長（ＬＰ）のフィールドの長さである。Ｏ−Ｃ、Ｌ−Ｃ、ＯＬ−Ｃ、ＬＬ−Ｃも同様である。

データフレームの識別情報は、特定の情報に限定されないが、例えば、データフレームに含まれる、該当ＲＡＮに固有の番号等の情報である。また、データフレームの長さでＲＡＮを識別できるのであれば、データフレームの長さがデータフレームの識別情報であってもよい。

例えば、擬似アプリケーション端末２００にＲＡＮ−Ａ、ＲＡＮ−Ｂ、ＲＡＮ−Ｃが接続されていて、擬似アプリケーション端末２００は、あるＲＡＮのある端末から送信されたデータフレームを受信する。

擬似アプリケーション端末２００は、例えば、データフレームの識別情報に基づき、当該データフレームがＲＡＮ−Ａに接続される端末からのデータフレームであることを把握すると、ＲＡＮ−Ａ用の情報＝｛Ｏ−Ａ、Ｌ−Ａ、ＯＬ−Ａ、ＬＬ−Ａ｝を用いて、共通ヘッダを付加する。

＜変形例の動作例＞
次に、図２６、図２７を参照して、変形例における通信システムの動作例を説明する。図２６に示すように、ここで説明する動作例においては、擬似アプリケーション端末２００−１にはＲＡＮ−Ａが接続され、ＲＡＮ−Ａにおけるある端末が、当該端末のＭＡＣアドレスとしてｍａｃ０を有するデータフレームを送信する。擬似アプリケーション端末２００−２にはＲＡＮ−Ｂが接続され、ＲＡＮ−Ｂにおけるある端末が、当該端末のＭＡＣアドレスとしてｍａｃ１を有するデータフレームを送信する。また、擬似アプリケーション端末２００−３には、ＭＡＣアドレスを有しないデータフレーム（ＰＤＵのみのデータフレーム）を送信する端末が直接に接続されている。

また、前述したように、擬似アプリケーション端末２００−１〜２００−３のそれぞれには、その配下に接続されるＲＡＮに対応した設定情報がコントローラ５００により設定され、擬似アプリケーション端末２００−１〜２００−３のそれぞれが設定情報を保持している。一例として、図２５（ａ）のケースを想定し、擬似アプリケーション端末２００−１は、Ｏ−Ａ、Ｌ−Ａを保持し、擬似アプリケーション端末２００−２は、Ｏ−Ｂ、Ｌ−Ｂを保持しているとする。また、擬似アプリケーション端末２００−３については、付加するＭＡＣアドレス（ここでは、ｍａｃ２とする）を保持している。このｍａｃ２は、コントローラ５００により設定された情報であってもよいし、擬似アプリケーション端末２００−３のＭＡＣアドレスであってもよい。

擬似アプリケーション端末２００−１は、図示するデータフレームを受信すると、Ｏ−ＡとＬ−Ａを用いてデータフレームからｍａｃ１を抽出し、当該ｍａｃ１のコピーを有する共通ヘッダをデータフレームに付加し、「共通ヘッダ＋データフレーム」をスイッチサーバ４００に送信する。スイッチサーバ４００は、受信した「共通ヘッダ＋データフレーム」における共通ヘッダの最初から、Ｌ−Ａに相当する部分を読み取り、共通ヘッダの中のｍａｃ１を抽出し、ｍａｃ１を用いたルーティングを行う。

擬似アプリケーション端末２００−２の動作は、擬似アプリケーション端末２００−１の動作と同様である。

擬似アプリケーション端末２００−３は、図示するデータフレーム（ＰＤＵのみ）を受信すると、保持しているｍａｃ２を有する共通ヘッダをデータフレームに付加し、「共通ヘッダ＋データフレーム」をスイッチサーバ４００に送信する。スイッチサーバ４００は、受信した「共通ヘッダ＋データフレーム」における共通ヘッダの最初から、ＭＡＣアドレスの長さを示す部分を読み取り、共通ヘッダの中のｍａｃ２を抽出し、ｍａｃ２を用いたルーティングを行う。

図２７に示すように、ルーティングの結果、擬似アプリケーション端末２００−１から受信した共通ヘッダ付きのデータフレームは疑似親機１００Ａに送信され、擬似アプリケーション端末２００−２から受信した共通ヘッダ付きのデータフレームは疑似親機１００Ｂに送信され、擬似アプリケーション端末２００−３から受信した共通ヘッダ付きのデータフレームは疑似親機１００Ｃに送信される。

疑似親機１００Ａ〜１００Ｃはそれぞれ、共通ヘッダ付きのデータフレームから共通ヘッダを削除し、データフレームをアプリケーションに送出する。

上記の例では、端末からアプリケーションに向けての動作を説明したが、アプリケーションから端末に向けた動作も同様に実現可能である。すなわち、例えば、擬似親機１００は、アプリケーションから、当該擬似親機１００に遠隔で接続される特定のＲＡＮ（ＲＡＮ−Ａとする）に対応したデータフレームを受信する。

擬似親機１００には、コントローラ５００からＯ−ＡとＬ−Ａが予め設定されている。擬似親機１００は、擬似アプリケーション端末２００が、ＲＡＮ−Ａからデータフレームを受信した場合と同様にして、アプリケーションから受信したデータフレームに共通ヘッダを付加し、「共通ヘッダ＋データフレーム」（例：図２５（ａ））をスイッチサーバ４００に送信する。

スイッチサーバ４００では、共通ヘッダに含まれるＭＡＣアドレスを用いてＲＡＮ側へのルーティングを実施し、「共通ヘッダ＋データフレーム」を、該当の擬似アプリケーション端末２００に送信する。擬似アプリケーション端末２００は、「共通ヘッダ＋データフレーム」から共通ヘッダを削除し、データフレームを配下のＲＡＮに送出する。

なお、アプリケーションから端末に向けた動作に関しては、アプリケーションから出力されるデータに宛先ＭＡＣアドレスが付加されることが想定されるので、擬似親機１００は、共通ヘッダ付加動作を行わないこととしてもよい。

＜変形例の効果等について＞
上述したように、変形例では、擬似アプリケーション端末２００と、擬似親機１００で、接続されているＲＡＮや端末の仕様を認識し、スイッチサーバ４００にはそれらの仕様を隠蔽する。

これにより、スイッチサーバ４００に、異なる方式のＲＡＮを混在接続することが可能となる。例えば、ＺｉｇＢｅｅとＷｉ−Ｆｉ（登録商標）等の異なる通信方式のネットワークでは、方式を超えたネットワーク間の相互通信はできないが、同じ方式内であれば一つのスイッチサーバ４００を介して、仮想的に分割したり、複数のＲＡＮを仮想的に統合できるといった、本実施の形態で説明した処理を実現できる。また、変形例では、ＭＡＣアドレスを持たないセンサ端末も、スイッチサーバ４００を介して一対一の通信が可能となる。

全ての通信がスイッチサーバ４００を介することにより、通信管理やトラフィック管理、ＳＤＮアーキテクチャによる自動コンフィギュレーションを利用できる。

特に、擬似アプリケーション端末２００、擬似親機１００には、接続されるＲＡＮや端末に応じて、ＭＡＣアドレスを抽出し、共通ヘッダを設定するための設定情報（パラメータ）の設定が必要になるが、コントローラ５００を用いたＳＤＮアーキテクチャにより、それらの設定が一元化され、擬似アプリケーション端末２００、擬似親機１００は、出荷時のコンフィグレーションが不要で、現場でネットワークに接続された時点で、接続されるＲＡＮ等に関するパラメータをコントローラ５００からダウンロードできる。

このように、変形例で説明した技術により、異なる方式のＲＡＮや、ＭＡＣアドレスを持たない端末でも本実施の形態に係る通信システムに収容でき、広域化の実現が可能となる。

（ハードウェア構成例）
これまでに説明した各装置（擬似親機、擬似アプリケーション端末、スイッチサーバ、スイッチ、コントローラ）はいずれも、例えば、コンピュータ（コンピュータの構成を備える通信装置を含む）に、本実施の形態（変形例を含む、以下同様）で説明する処理内容を記述したプログラムを実行させることにより実現可能である。すなわち、各装置が有する機能は、当該コンピュータに内蔵されるＣＰＵやメモリ、ハードディスクなどのハードウェア資源を用いて、当該装置で実施される処理に対応するプログラムを実行することによって実現することが可能である。上記プログラムは、コンピュータが読み取り可能な記録媒体（可搬メモリ等）に記録して、保存したり、配布したりすることが可能である。また、上記プログラムをインターネットや電子メールなど、ネットワークを通して提供することも可能である。

図２８は、当該装置をコンピュータで実現する場合におけるハードウェア構成例を示す図である。図２８に示す装置は、それぞれバスＢで相互に接続されているドライブ装置６００、補助記憶装置６０２、メモリ装置６０３、ＣＰＵ６０４、インタフェース装置６０５、表示装置６０６、及び入力装置６０７等を有する。

当該装置での処理を実現するプログラムは、例えば、ＣＤ−ＲＯＭ又はメモリカード等の記録媒体６０１によって提供される。プログラムを記憶した記録媒体６０１がドライブ装置６００にセットされると、プログラムが記録媒体６０１からドライブ装置６００を介して補助記憶装置６０２にインストールされる。但し、プログラムのインストールは必ずしも記録媒体６０１より行う必要はなく、ネットワークを介して他のコンピュータよりダウンロードするようにしてもよい。補助記憶装置６０２は、インストールされたプログラムを格納すると共に、必要なファイルやデータ等を格納する。

メモリ装置６０３は、プログラムの起動指示があった場合に、補助記憶装置６０２からプログラムを読み出して格納する。ＣＰＵ６０４（プロセッサ）は、メモリ装置６０３に格納されたプログラムに従って当該装置に係る機能を実現する。インタフェース装置６０５は、ネットワークに接続するためのインタフェースとして用いられる。表示装置６０６はプログラムによるＧＵＩ（Graphical User Interface）等を表示する。入力装置６０７はキーボード及びマウス、ボタン、又はタッチパネル等で構成され、様々な操作指示を入力させるために用いられる。

（実施の形態のまとめ、効果）
以上、説明したように、本実施の形態によれば、アプリケーションと拠点ネットワークとを接続する通信システムであって、アプリケーションから送信されたデータを受信し、当該データを、当該データの宛先アドレスを持つノードが存在する拠点ネットワークに向けて送信する第１ルーティング手段と、拠点ネットワークから送信されたデータを受信し、当該データを、当該データの送信元アドレスに対応するアプリケーションに向けて送信する第２ルーティング手段とを備えることを特徴とする通信システムが提供される。

前記第１ルーティング手段は、拠点ネットワークに接続されているノードのアドレスと、当該拠点ネットワークに対応する情報とを有するルーティングテーブルに基づいて、アプリケーションから送信されたデータの送信先を決定することができる。

前記第２ルーティング手段は、あるアプリケーションへの接続を許可されたアドレスを有するホワイトリストを保持し、当該ホワイトリストに基づいて、拠点ネットワークから送信されたデータを当該ホワイトリストの対象のアプリケーションに向けて送信するか否かを決定することができる。

前記第２ルーティング手段は、前記拠点ネットワークのノードから送信されたデータに共通ヘッダが付加された共通ヘッダ付きデータを受信し、当該共通ヘッダに含まれる送信元アドレスに対応するアプリケーションに向けて当該共通ヘッダ付きデータを送信することとしてもよい。

また、本実施の形態により、アプリケーションと、ノードを有する拠点ネットワークとを接続する通信システムに対する制御を行う制御装置であって、所定の端末から、ノード毎のアドレスの情報、ノード毎の設置場所情報、及びノード毎の所有者情報の３つの情報のうちの少なくとも一つの情報を受信する受信手段と、同じ所有者情報を持つノードのアドレスと設置場所情報とに基づいて、当該設置場所情報に対応する拠点から受信するデータを当該所有者情報に対応するアプリケーションに向けて送信するために前記通信システムにより使用されるホワイトリストを生成する生成手段と、前記生成手段により生成されたホワイトリストを前記通信システムに送信する送信手段とを備えることを特徴とする制御装置が提供される。

前記通信システムは、前記拠点ネットワークのノードから送信されたデータに共通ヘッダを付加する装置を含み、前記送信手段は、前記装置に対し、前記共通ヘッダの付加を実施するための設定情報を送信することとしてもよい。また、前記設定情報は、前記拠点ネットワークのノードから送信されるデータにおけるＬ２アドレスの位置を示す情報、又は、擬似的なＬ２アドレスであることとしてもよい。

本実施の形態の技術により、小規模な複数のネットワークを統合することで一つの大きなネットワークに見せるスケールアウト、及び多対多接続を行うことで一拠点に複数のＲＡＮが存在した場合にも適切なアプリケーションへのアクセスを許容する多重化が実現される。

以上、本実施の形態について説明したが、本発明はかかる特定の実施形態に限定されるものではなく、特許請求の範囲に記載された本発明の要旨の範囲内において、種々の変形・変更が可能である。

１、３、５、３０ アプリケーション
６、５０ ＩＰネットワーク
７ ＧＷ
２、４、８、４０ ＲＡＮ
１０、１００ 擬似親機
１１ ｔａｐドライバ
１２、２２ Ｌ２送受信部
１３、２１ トンネル終端部
２０、２００ 擬似アプリケーション端末
１１０ 通信部
１２０ 端末管理機能部
１３０ ルーティング機能部
１４０ 端末制御機能部
１５０ 記憶部
１６０ ルーティングテーブル
１７０ ホワイトリスト
２１０ 通信部
２２０ 端末管理機能部
２３０ アクセス制御部
２４０ 記憶部
２５０ 接続中端末管理テーブル
２６０ ホワイトリスト
４００ スイッチサーバ
４１０ 通信部
４２０ 端末管理機能部
４３０ ルーティング機能部
４４０ 端末制御機能部
４５０ 記憶部
５００ コントローラ
５１０ 情報通知部
５２０ 情報生成部
５３０ 認証部
５４０ 記憶部
６００ ドライブ装置
６０１ 記録媒体
６０２ 補助記憶装置
６０３ メモリ装置
６０４ ＣＰＵ
６０５ インタフェース装置
６０６ 表示装置
６０７ 入力装置

Claims (5)

1. アプリケーションと拠点ネットワークとを接続する通信システムであって、
   アプリケーションから送信されたデータを受信し、当該データを、当該データの宛先アドレスを持つノードが存在する拠点ネットワークに向けて送信する第１ルーティング手段と、
   拠点ネットワークから送信されたデータを受信し、当該データを、当該データの送信元アドレスに対応するアプリケーションに向けて送信する第２ルーティング手段と、を備え、
   前記第２ルーティング手段は、前記拠点ネットワークのノードから送信されたデータに共通ヘッダが付加された共通ヘッダ付きデータを受信し、当該共通ヘッダに含まれる送信元アドレスに対応するアプリケーションに向けて当該共通ヘッダ付きデータを送信する
   ことを特徴とする通信システム。
2. 前記第１ルーティング手段は、拠点ネットワークに接続されているノードのアドレスと、当該拠点ネットワークに対応する情報とを有するルーティングテーブルに基づいて、アプリケーションから送信されたデータの送信先を決定する
   ことを特徴とする請求項１に記載の通信システム。
3. 前記第２ルーティング手段は、あるアプリケーションへの接続を許可されたアドレスを有するホワイトリストを保持し、当該ホワイトリストに基づいて、拠点ネットワークから送信されたデータを当該ホワイトリストの対象のアプリケーションに向けて送信するか否かを決定する
   ことを特徴とする請求項１又は２に記載の通信システム。
4. コンピュータを、請求項１ないし３のうちいずれか１項に記載の通信システムにおける各手段として機能させるためのプログラム。
5. アプリケーションと拠点ネットワークとを接続する通信システムが実行する通信方法であって、
   アプリケーションから送信されたデータを受信し、当該データを、当該データの宛先アドレスを持つノードが存在する拠点ネットワークに向けて送信する第１ルーティングステップと、
   拠点ネットワークから送信されたデータを受信し、当該データを、当該データの送信元アドレスに対応するアプリケーションに向けて送信する第２ルーティングステップと、を備え、
   前記第２ルーティングステップにおいて、前記通信システムは、前記拠点ネットワークのノードから送信されたデータに共通ヘッダが付加された共通ヘッダ付きデータを受信し、当該共通ヘッダに含まれる送信元アドレスに対応するアプリケーションに向けて当該共通ヘッダ付きデータを送信する
   ことを特徴とする通信方法。

Images