位置依存形 P2P に基づくユーザ協調形データオフロード手法の研究
代表研究者
共同研究者

山 崎
三 好託匠

早稲田大学 基幹理工学部 助手
芝浦工業大学 システム理工学部 教授

1 まえがきLTE（Long term evolution）などの高速な移動体通信網の発達やスマートフォンなどの普及により，ユー
ザは音楽や動画などの高品質な大容量コンテンツを外出先で容易に取得することが可能となっている．
一方，モバイル端末による通信量は 2016 年から 2021 年にかけて 7 倍に増加すると予測されており，通信資源の消費による帯域圧迫が問題となっている[1]．特に，動画コンテンツが移動体通信網の通信量全体の 78%を占めると予測されており，このような大容量コンテンツが移動体通信網の通信資源に与える影響を軽減する必要があると考えられる．
このような問題を解決するため，移動体通信網の負荷の分散や軽減を行うためのデータオフロード手法が様々提案されている[2]．データオフロード手法として，無線 LAN アクセスポイント（以下，無線 AP）を用いて移動体通信網から固定回線などに負荷を分散する手法[3]-[7]，他の端末と協調してデータを取得することで通信量の削減を行う手法[8]-[10]，複数の端末が互いにデータの一部を取得し，すれ違った他の端末と直接通信することで共有する手法[11],[12]などが検討されている．
しかし，無線 AP を用いた手法では，通信負荷を異なる通信媒体に移動することは可能であるが，全体の通信量は変化せず，通信負荷を低減することはできない．近隣の端末と協調することで通信量を削減する手法
では，端末や無線 AP の機能に大きな改変が必要であることや，協調端末の発見方法については未検討であるなどの問題がある．また，すれ違った端末間でデータを共有する手法では，共有するデータの部分を移動予測に従い決定するため，実環境では適切に共有できず効率が低下する可能性がある．
本研究では，位置情報に基づいた P2P ネットワークを経由して端末間での協調を行い，各端末がダウンロードしたデータを直接通信によって共有する近距離協調データオフロードシステムを提案する．提案システ
ムでは，端末間で協調を行う際のデータ共有方式を動的に変更することが可能である．そのため，本研究では，提案システム上で動作するデータ共有方式として代表選出形データ共有方式と分割協調形データ共有方式の 2 方式を提案する．

2 関連研究2-1 アクセスポイントを用いたデータオフロード手法
現在，駅の構内や様々なイベント会場などの混雑する環境下において，無線 AP を利用することで通信負荷を分散させるデータオフロード手法が広く用いられており[3]-[5]，AP の配置に関する研究[6],[7]などが行われている．この手法では，ユーザが公衆無線 LAN などに接続し，利用する通信経路を移動体通信から無線LAN に切り替えることで，移動体通信網を通じた通信を他の通信媒体に分散することが可能である．しかし，この手法では通信負荷の移動は可能であるが，全体の通信量は変化せず削減することはできない．また，この手法では無線 AP が設置されている領域に適用領域が制限されるため，通信負荷の分散効果は無線 AP の設置状況に強く依存する．
2-2 すれ違い通信を用いた協調ダウンロード手法
文献[11],[12]では，部分的にダウンロードしたデータをすれ違った端末間で直接通信を用いて共有する協調ダウンロード手法が提案されている．まず，各端末は現在位置，目的地，出発時刻，分割されたデータの所有状況などをサーバに送信する．サーバは，これらの情報に基づき遭遇する可能性のある端末の ID，遭遇確率，遭遇時刻，所有データ情報を生成し，各端末に送信する．これらにより，各端末は協調する端末と遭遇する地点を予測し，取得が難しいと予想されるデータの部分を優先して共有を行う．しかし，実環境ではユーザの移動の予測は困難であるため，共有の効率が低下すると考えられる．

1

3 近距離協調データオフロードシステム
本研究では，近隣に存在する端末間で協調し，互いに分担してデータの取得を行う近距離協調データオフロードシステムを提案する．
3-1 提案システムの概要
提案システムの概要を図 1 に示す．まず，提案システムでは，同一データを要求する近隣の端末間で P2Pネットワークを用いたグループを構築し，協調するために必要となる制御情報をお互いに共有する．次に，協調する端末群は，P2P ネットワークを通じてそれぞれの端末がダウンロードするデータの範囲を決め，データを管理するストレージサーバに対してそれぞれデータを要求し取得する．このとき，P2P ネットワークを経由して，直接通信を行う手順などの制御情報を端末間で共有することでデータの共有方式及び共有時に用いる通信方式等の決定を行う．なお，提案システムでは 2 種類のデータ共有方式とデータ共有時に用いる3 種類の通信方式の提案する．また，ダウンロードするデータの指定は URI（Uniform resource locator）とHTTP/1.1[13][14]の Conditional Request[15]の一種である Range Request[16]を用いることで実現する．
ダウンロード後，各端末は無線 LAN や Bluetooth などによる直接通信を利用して，ダウンロードしたデータを互いに送信することで共有する．各端末がダウンロードしたデータを直接通信によりすべて共有した後，各端末はデータを復元し制御を終了する．これにより，提案手法では各端末が分割してデータを取得することで，データ量の削減を実現する．
3-2 協調グループの構成
提案システムにおいて協調制御に用いるグループは，取得するデータごとに構築され，1 台のリーダ端末と複数のフォロワ端末で構成される．また，リーダ端末の位置を中心とし，リーダ端末と直接通信を行うことができる範囲内の端末で P2P ネットワークを構築する．なお，各端末は，P2P ネットワークを通じてデータ共有以外の協調制御情報等の共有を行うものとする．
本研究では，P2P ネットワークには，端末の位置情報やアドレスなどを管理する管理サーバを用いて通信先の端末を決定する位置依存形 P2P システム[17],[18]を用いる．位置依存形 P2P システムは，上述した機能に加えて，STUN（Session traversal utilities for NAT）[19]と TURN（Traversal using relays aroundNAT）[20]を用いることでピア間の接続を補助する機能をもつ．
3-3 協調グループの構築
まず，データを要求する端末は，同一のデータを要求している近隣の端末の情報を管理サーバから検索する．このとき，同一データを要求する端末が近隣に存在しない場合，自身がリーダ端末となり，自身のピアID，位置情報，要求するデータの情報，端末 ID，募集中か否かを判定する二値を管理サーバに登録し，一定時間グループに参加する端末を募集する．なお，ピア ID は近隣端末検索時に生成し，端末間での P2P 通信に利用する．要求データ情報として，要求するデータの URI などを利用する．端末 ID は，端末間の直接通信を実行する際に生成して，利用する．なお，リーダ端末は定期的に管理サーバに登録した自身の情報を更新す

図1

提案システム2

る．同一データを要求する端末が近隣に存在する場合，管理サーバから取得した端末情報に基づき，同一データを要求する端末群の中から自身と最も近いリーダ端末に P2P 接続を行い，フォロワ端末としてグループに参加する．なお，フォロワ端末は定期的に管理サーバに登録されたリーダ端末の情報を取得する．
3-4 協調ダウンロード制御
3-3 で構築した P2P ネットワークを用いて，端末間で協調ダウンロードを行う際の制御手順（1）～（5）を以下に示す．
（1）協調端末の設定
リーダ端末は募集開始時に設定した待機時間Tadv 秒経過後，募集を停止し，構築したグループを用いて協調的にデータを取得する近隣端末を決定する．このとき，リーダ端末は，協調グループの端末数 N を取得し，各端末にはグループメンバ番号 i （0 ≤ i ≤ N）を割り当てる．なお，リーダ端末のグループメンバ番号には0 を割当て，各フォロワ端末には 1 からN - 1を割り当てる．
（2）モバイルネットワークを通じたデータの取得
メンバ番号の割り当て後，リーダ端末は，各フォロワ端末にグループの端末数Nとそれぞれの端末に割り当てられたグループメンバ番号 i を記録した制御メッセージを送信する．リーダ端末から制御メッセージを受信したフォロワ端末は，管理サーバから事前に取得したリーダ端末の情報を用いて，リーダ端末と直接通信の接続を確立し待機する．また，制御メッセージには，利用するデータ共有方式とデータ共有時の通信方式が記録されており，各端末は制御メッセージに記録された情報に従い，データ共有方式と共有の際に用いる通信方式を決定する．データのダウンロード後，各フォロワ端末は受信完了通知をリーダ端末に送信する．
（3）直接通信を用いた接続確立
全てのフォロワ端末から通知を受信した場合，リーダ端末は，全てのフォロワ端末と直接通信を行うため，全フォロワ端末に要求メッセージを送信し，直接通信を用いた接続の確立を行う．要求メッセージを受信したフォロワ端末は，管理サーバから事前に得たリーダ端末の情報を用いて直接通信の接続確立を行う．
（4）直接通信によるデータ共有
直接通信による接続確立後，各端末は，事前に決定したデータ共有方式をダウンロードしたデータの共有を開始する．なお，手順の詳細は 3-5（3）で述べる．データ共有により要求しているデータが完成した場合，フォロワはデータ共有完了通知をリーダに送信する．
（5）終了処理
リーダ端末は，全フォロワ端末から受信完了通知を受信したとき，協調制御の終了処理を行う．全フォロ
ワ端末への復元データの共有が完了した場合，リーダ端末は全フォロワ端末に全端末がダウンロードを完了したことを通知するメッセージ（共有完了通知）を送信し，P2P ネットワークと直接通信のコネクションを切断し，制御を終了する．共有完了通知を受信した各フォロワ端末も同様に，P2P ネットワークと直接通信のコネクションを切断し，制御を終了する．
3-5 提案システムにおける通信制御方式
本節では，提案オフロードシステムにおけるデータ共有方式として，代表選出形データ共有方式と分割協調形データ共有方式を提案する．また，各共有方式を実現するための制御方式を提案する．
（1）代表選出形データ共有方式
代表選出形データ共有方式は，代表として選出されたリーダ端末がデータ全体をダウンロードし，近隣の他の端末に送信する方式である．本方式の動作例を図 2 に示す．まず，近距離協調データオフロードシステ
ムに基づき同一データを要求する近隣の端末でグループを構成する．このとき，グループ内の端末群からリーダ端末を選出し，リーダ端末はストレージサーバからデータ全体をダウンロードする．ダウンロード終了
後，リーダ端末はグループ内の他の端末に対し直接通信の接続要求を行う．リーダ端末以外の端末は，リーダ端末から接続要求を受信した後，リーダ端末との接続を確立する．通信の接続を確立した後，リーダ端末はその他の端末に直接通信を用いてデータを送信することで，全ての端末とデータを共有する．

3

図 2 代表選出形データ共有方式

図3

分割協調形データ共有方式（2）分割協調形データ共有方式
分割協調形データ共有方式は，各端末が分割されたデータをダウンロードし，近隣の端末間で共有することでデータの全体を取得する方式である．本方式の動作例を図 3 に示す．
まず，代表選出形ダウンロード手法と同様に近距離協調データオフロードシステムに基づき同一データを要求する近隣端末でグループを構成する．リーダ端末は，ダウンロードするデータのデータ量とグループ内の端末数に基づいて各端末がダウンロードするデータの範囲を決定する．なお，ダウンロード範囲は，要求するデータ j のデータ量sj ，グループの端末数 N，自身のグループメンバ番号 i に基づき式(1)〜(2)より，自(head) (tail)身がダウンロードするデータ j の範囲[si, j ,si, j ]を算出する．

自身に割り当てられた範囲のデータをダウンロードした後，各フォロワ端末はダウンロード完了を示す受信完了通知をリーダ端末に送信する．
上述した分割協調形データ共有方式では，ローカルネットワーク上での接続先の切り替え回数が大きく増加する．この問題を解決するため，本研究では，分割協調形データ共有方式の拡張版を提案する．この方式
では，全ての端末が分割したデータのダウンロードを行った後，全フォロワはリーダ端末に分割データの送信を行う．全ての分割データを受信したリーダ端末は，分割データを結合することでデータの復元を行い，各フォロワに対して復元データの送信を行う．これにより，この方式では接続先の切り替えが減少すると考えられる．
（3）データ共有時の通信方式上述した 2 種類のデータ共有方式に対して，以下の 3 種類の制御方式を提案する．なお，各端末は，P2P ネットワークを用いてグループを構築済みであるとする．また，代表選出形データ共有方式では，直接通信を行うときの親となる端末（親端末）がその他の端末（子端末）に一度接続するだけで良いため，以下の処理を一度のみ行う．分割協調形データ共有方式においては，制御が終了した後に親端末を切り替え，再度制御を行う．なお，一度接続を行いデータの送受信が完了した端末との再接続は行わないものとする．
制御方式 1: 親端末は，全ての子端末と直接通信の接続を確立する．通信確立後，親端末は全ての子端末に対して同時にデータの送受信を行う．
制御方式 2: 親端末は，全ての子端末と直接通信の接続を確立する．通信確立後，親端末は全ての子端末に対して 1 台ずつ順番にデータの送受信を行う．
制御方式 3: 親端末は 1 台の子端末と直接通信の接続を確立し，データの送受信を行う．データの送受信終了後，接続を切断する．これを全ての子端末に対して繰り返す．

44 実機実装による性能評価
本性能評価実験では，提案システムの通信量を測定する実験と，各データ共有方式と各制御方式において制御が完了するまでの時間を測定する実験を行う．
4-1 通信量の測定実験
提案システムを Android アプリケーションとして実装し，性能評価実験を行う．本実験環境を表 1 に示す．
提案システムにおいて，リーダ端末が協調する端末を募集する待機時間Tabv を 60 秒とする．端末間の直接通信には Wi-Fi Direct[21]を利用し，データの共有を行う．また，データ共有方式には，分割協調データ共有方式の拡張版を用いて，通信方式には制御方式 2 を用いる．本実験では，最初に 1 端末のみアプリケーションを起動し，その後 5 秒ごとに 1 端末ずつアプリケーションの起動を行う．全端末上のアプリケーションの起動が完了した後，各端末は提案システムを用いて 10MB のデータを協調して取得する．このときのデータ取得が完了するまでに要した全端末の合計送受信量を測定する．なお，移動体通信や固定通信網への影響を評価するため，直接通信による送受信量は除外する．クライアント/サーバ方式（C/S 方式）を用いてデータを取得した場合との比較を行う．
4-2 通信量の測定実験結果
提案システムと C/S 方式をそれぞれ用いてデータを取得した際の送受信量を図 5 に示す．提案システムでは，P2P 通信を用いて協調端末に制御メッセージを送信する必要があるため，各端末が C/S 方式を用いてデータを取得したときと比較して送信量が増加している．一方，C/S 方式は端末数に比例し受信量が増加するのに対し，提案システムは端末数が増加しても，協調端末数に応じて分割したデータを取得しているため，受信量は大きく変化しないことが分かる．
次に，1 端末当たりの送信量と受信量をそれぞれ図 6 に示す．リーダ端末はフォロワ端末に情報を送信するだけでなく，管理サーバが管理している情報を 10 秒毎に更新する必要があるため，フォロワ端末より送信量が増加していることが分かる．また，リーダ端末は，フォロワ端末数に応じて交換する制御メッセージが増加するため，フォロワ端末と比較して受信量が増加しているが，ダウンロードするデータ量は分割した一部分となるため，C/S 方式より減少していることが分かる．
表1

図5

評価実験の環境

合計送受信量図65

1 端末当たりの送受信量

4-3 制御時間の測定実験
3-4 で提案した 2 種類のデータ共有方式と 3 種類の制御方式を Android アプリケーションとして実装し，性能評価実験を行う．端末間の直接通信には Nearby Connections API 2.0[22]に基づく Bluetooth による直接通信を用いる．
（1） 制御方式の比較実験
本実験では，制御方式が制御完了までの時間に与える影響について評価を行う．3～5 端末で 5MB のデータを送受信し，通信開始から全端末が受信完了となるまでの制御時間を評価する．なお，実験時に発生した通信パケットを記録し，Wireshark[23]を用いて分析する．
（2） データ共有方式の比較実験
本実験では，データ共有方式の違いが制御完了までの時間に与える影響について評価を行う．まず，混雑環境下での性能評価を想定し，移動体通信網からダウンロードする際のスループットとして，イベント会場においてドコモスピードテスト[24]より計測した値を用いる．スループット計測は，2017 年 12 月 31 日に東京国際展示場で開催された大規模イベントにおいて，午前 9 時 22 分から午前 9 時 40 分にかけて実施した．
7 回の計測から，下りのスループットは 0.8Mbps，上りのスループットは 7.48Mbps であった．計測結果より，
本実験における移動体通信網からのダウンロードする際のスループットを 0.8Mbps に設定する．また，制御方式の比較時に得られた評価結果より，制御方式には良い結果が得られた制御方式 3 を用いる．また，データの共有に用いるデータ量を 7.5MB，15MB，30MB，45MB とし，データ共有を行う端末数を変化させ，全端末のデータ受信が完了するまでの時間を計測する．
4-4 制御時間の測定実験結果（1）制御方式の比較実験
結果を図 7 に示す．結果より，端末数によらず制御方式 2 と制御方式 3 の差は小さいが，制御方式 1 では制御が完了するまでの時間が増加することが分かる．特に，端末数が 5 である場合には，制御方式 1 における制御時間が更に増加していることが分かる．また，発生した通信パケットの記録から，親端末が子端末に対し，時分割方式を用いてデータの送信を行っていることが分かった．そのため，端末数が増加すると親端末による通信相手の切り替え回数が増加し，待機による遅延が増大するため，制御方式 1 では制御時間が増加したと考えられる．また，制御方式 2 と制御方式 3 における制御時間の差は小さく，接続を複数維持した状態からデータを送信する負荷は小さいと考えられる．
（2）データ共有方式の比較実験
図 8 に評価結果を示す．2 端末でデータの共有を行う場合，共有するデータ量が増加すると代表選出形における必要時間が大きく増加していることが分かる．これは，代表選出形では，データのダウンロード時に代表端末がデータ全体をダウンロードするのに対し，分割協調形では各端末がダウンロードするデータ量が端末数に応じて減少するため，ダウンロードに必要となる時間が大きく削減されるためであると考えられる．
また，共有するデータ量が大きい場合も同様に，分割協調形では代表選出形と比較して各端末がダウンロー

図 7 各制御方式の制御時間

図 8 各データ共有方式の制御時間6ドするデータ量が減少するため，ダウンロードに必要な時間が短くなったと考えられる．
一方，端末数が増加した際に代表選出形ではどのデータ量においても制御時間の増加量（傾き）はほぼ一定であるが，分割協調形では制御時間の増加量が増加し，4 端末以上となる場合では両方式の制御時間の差が減少していることが分かる．代表選出形では，親端末がグループ内の子端末に接続しデータを送信するだけであり，グループの端末数Nに対して通信確立回数はN - 1となる．一方，分割協調形では，グループ内の全端末が互いに接続する必要があるため，通信確立回数は NC2 となる．そのため，分割協調形では𝑛&のオーダで通信確立回数が増加し，代表選出形との通信時間の差が減少したと考えられる．

5 むすび
本研究では，位置情報に基づき端末間の直接通信によるデータ共有を行う近距離協調データオフロードシステムを提案し，実装実験による評価を行った．また，端末間で直接通信を行う際のデータ共有方式として代表選出形と分割協調形の 2 種類を提案した．結果より，代表選出形では 1 端末がダウンロードを行うため必要となるダウンロード時間は増加するが，通信先の切り替えによる遅延が少ないことが分かった．一方，分割協調形では複数端末で並列にダウンロードを行うため必要となるダウンロード時間は減少するが，通信先の切り替えによる遅延が発生し，制御が完了するまでの時間が増加することが分かった．今後は，提案手法の適切なパラメータの検討やシステムの拡張を行う予定である．

【参考文献】[1] Cisco Visual Networking Index, Cisco Inc.,https://www.cisco.com/c/ja_jp/solutions/service-provider/visual-networking-index-vni/index.html[2] F. Rebecchi, M.D. Amorim, V. Conan, A. Passarella, R. Bruno, and M. Conti, “Data offloading
techniques in cellular networks: A survey,” IEEE Commun. Surveys & Tutorials., vol.17, no.2,
pp.580-603, Nov. 2014.
[3] docomo Wi-Fi, NTT DOCOMO Inc., https://www.nttdocomo.co.jp/service/wifi/docomo_wifi[4] au Wi-Fi, KDDI Corp., https://www.au.com/mobile/service/wifi/[5] ソフトバンク Wi-Fi スポット, SoftBank Corp., https://www.softbank.jp/mobile/network/wifispot/[6] X. Kang, Y.-K. Chia, and S. Sun, “Mobile data offloading through a third-party WiFi access point:
An operator's perspective,” 2013 IEEE Globecom Workshops, pp.696-701, Atlanta, USA, Dec. 2013.
[7] E. Bulut and B.K. Szymanski, “WiFi access point deployment for efficient mobile data offloading,”
1st ACM Int. Workshop on Practical Issues and Applications in Next Gen. Wireless Netw.
(PINGEN 2012), pp.45-50, Istanbul, Turkey, Aug. 2012.
[8] S.-S. Kang and M.W. Mutka, “A mobile peer-to-peer approach for multimedia content sharing
using 3G/WLAN dual mode channels,” J. Wireless Commun. & Mob. Comput., vol.5, no.6, pp.633645, Sept. 2005.
[9] S. Sharafeddine, K. Jahed, N. Abbas, E. Yaacoub, and Z. Dawy, “Exploiting multiple wirelessinterfaces in smartphones for traffic offloading,” 2013 1st Int. Black Sea Conf. Commun. and Netw.
(BlackSeaCom 2013), pp.142-146, July 2013.
[10] A. Le, L. Keller, H. Seferoglu, B. Cici, C. Fragouli, and A. Markopoulou, “MicroCast: Cooperative
video streaming using cellular and local connections,” IEEE/ACM Trans. Netw., vol.24, no.5,pp.2983-2999, Oct. 2016.
[11] 花野博司，村田佳洋，柴田直樹，安本慶一，伊藤実，“携帯電話端末への低コスト動画広告配信を目的とした WiFi 併用協調ダウンロード方式，” 情処学論，vol.51，no.2，pp.440-452，Feb. 2010．
[12] 高松悠，孫為華，安本慶一，山内由紀子，伊藤実，“すれ違い通信を活用した複数携帯電話端末による省電力協調動画ダウンロード手法，” 情処学論，vol.53，no.2，pp.783-794，Feb. 2012．
[13] R. Fielding (Ed.) and J. Reschke (Ed.), “Hypertext transfer protocol (HTTP/1.1): Message syntaxand routing,” IETF RFC7230, June 2014.

7

[14] R. Fielding (Ed.) and J. Reschke (Ed.), “Hypertext transfer protocol (HTTP/1.1): Semantics andcontent,” IETF RFC7231, June 2014.
[15] R. Fielding (Ed.), Y. Lafon (Ed.), and J. Reschke (Ed.), “Hypertext Transfer protocol (HTTP/1.1):
Range requests,” IETF RFC7233, June 2014.
[16] R. Fielding (Ed.) and J. Reschke (Ed.), “Hypertext transfer protocol (HTTP/1.1): Conditionalrequests,” IETF RFC7232, June 2014.
[17] 下村勇介，三好匠，“位置情報に基づいた P2P 形コミュニケーションシステム,” 信学技報，vol.117，no.114，
pp.77-80，ICM2017-18，July 2017．
[18] T. Miyoshi, Y. Shimomura, and O. Fourmaux, “G-LocOn: A P2P-based communication frameworkfor geo-location oriented networks,” IEICE Information and Commun. Tech. Forum (ICTF 2018),
July 2018.
[19] J. Rosenberg, R. Mahy, P Matthews, and D. Wing, “Session traversal utilities for NAT (STUN),”IETF RFC5389, Oct. 2008.
[20] R. Mahy, P. Matthews, and J. Rosenberg, “Traversal using relays around NAT (TURN): Relay
extensions to session traversal utilities for NAT (STUN),” IETF RFC5766, April 2010.
[21] Wi-Fi Direct, Wi-Fi Alliance, https://www.wi-fi.org/discover-wi-fi/wi-fi-direct[22] Nearby Connections API, Google LLC,
https://developers.google.com/nearby/connections/overview[23] Wireshark, Wireshark Foundation, https://www.wireshark.org[24] ドコモスピードテストアプリ，NTT DOCOMO Inc.，https://www.nttdocomo.co.jp/support/area/speed_test/〈発題名

複数モバイル端末による近距離協調データ
オフロードシステム
近距離協調データオフロードシステムにおける分散ダウンロード手法
位置依存形 P2P ネットワークを用いた近距
離協調データオフロード手法
Cooperative Data Offloading System withNeighbours
BasedonLocation
Information

表資料〉

掲載誌・学会名等

発表年月

電子情報通信学会総合大会

2018 年 3 月

電子情報通信学会総合大会

2018 年 3 月

電子情報通信学会技術研究報告2018 年 3 月

IEICE Information andCommunication Technology Forum2018 (ICTF 2018)2018 年 7 月

8