移動環境における通信予測に関する検討

全文

(1)平成 26 年度. 修士論文. 移動環境における通信予測に関する検討. 早稲田大学大学院基幹理工学研究科情報理工学専攻 5113B034-1 小西. 指導. 秀典. 甲藤二郎教授. 2015 年 2 月 6 日. 指導教授印. 受付印. 1.

(2) 目次第1章. 序論 ............................................................................................................ 5. 1.1 はじめに ......................................................................................................... 5 1.2 本論文の構成 .................................................................................................. 6 第2章. 関連技術 ..................................................................................................... 7. 2.1 無線通信技術 .................................................................................................. 7 2.1.1 LTE (Long Term Evolution)[2] ................................................................. 7 2.1.1.1 MIMO(Multi-Input Multi-Output)[3][4] ............................................. 7 2.1.1.2 OFDMA(Orthogonal Frequency Division Multiple Access)[5][6] ......... 8 2.1.1.3 SC-FDMA(Single Carrier Frequency Division Multiple Access)[7][8] . 9 2.1.1.4 64QAM[5][9] ....................................................................................... 9 2.1.1.5 次世代通信技術[10][11][12]............................................................... 10 2.1.2 Bluetooth[13][14] ................................................................................... 10 2.1.2.1 マスタとスレーブ ............................................................................. 10 2.1.2.2 ペアリング ....................................................................................... 11 2.1.3 ZigBee[14][15] ........................................................................................ 12 2.1.3.1 ネットワーク構成 ............................................................................. 13 2.1.4 高速無線 LAN[13] .................................................................................. 13 2.1.4.1 IEEE802.11n[16] .............................................................................. 14 2.1.4.2 IEEE802.11ac[17][18] ....................................................................... 14 2.2 ストリーミング技術[19] ................................................................................ 15 2.2.1 UDP[20] ................................................................................................. 15 2.2.2 RTP[21] .................................................................................................. 16 2.2.2.1 RTP ヘッダ ....................................................................................... 16 2.2.2.2 ペイロードヘッダ・データ................................................................ 18 2.2.3 RTP 制御プロトコル[21] ......................................................................... 18 2.2.3.1 RR パケット ...................................................................................... 18 2.2.3.2 SR パケット ...................................................................................... 18 2.

(3) 2.2.4 HTTP Live Streaming[22] ...................................................................... 19 2.2.5 MPEG-DASH(Dynamic Adaptive Streaming over HTTP)[23 ] ............... 20 2.2.5.1 MPEG-DASH とは ............................................................................ 20 2.2.5.2 MPD ファイル................................................................................... 22 2.3. 予測技術とバッファリング .......................................................................... 22. 2.3.1 PROTEUS[24] ........................................................................................ 23 2.3.2 無線状態を用いた手法[25] ...................................................................... 23 2.3.3 混合モデルを用いた手法 [26] ................................................................. 24 2.3.4 バッファリング戦略[27].......................................................................... 25 第3章. SVR を用いた移動環境での通信予測 ........................................................... 26. 3.1 提案システム概要 ......................................................................................... 26 3.2 事前実験 ....................................................................................................... 26 3.2.1 データの収集 .......................................................................................... 26 3.2.1.1 Android アプリ作成 .......................................................................... 26 3.2.2 データ可視化マップ................................................................................ 27 3.2.3 駅間における確率分布 ............................................................................ 28 3.2.4 基地局を利用した位置情報提供機能[29] .................................................. 31 3.2.4.1 使用例 .............................................................................................. 33 3.2.5 時間帯別スループット比較 ..................................................................... 34 3.2.6 基地局毎における比較(平日のみ) ............................................................ 35 3.2.7 平日と休日における比較 ......................................................................... 36 3.3 評価実験 ....................................................................................................... 37 3.3.1 SVR(Support Vector Regression)の利用.................................................. 37 3.3.2 パラメータ変更による比較 ..................................................................... 38 3.3.3 時間帯による比較 ................................................................................... 42 3.3.4 位置情報によるグループ分け .................................................................. 44 3.3.5 使用するデータの種類 ............................................................................ 46 3.

(4) 3.3.6 各エリアでの通信予測 ............................................................................ 48 第4章. 配信レート制御方式の検討 ........................................................................ 50. 4.1 概念.............................................................................................................. 50 4.2 閾値によるビットレート変動 ........................................................................ 51 4.3 面積によるビットレート変動 ........................................................................ 54 4.4 予測面積によるバッファリング制御 .............................................................. 58 4.4.1 idle 時間を考慮した場合 .......................................................................... 61 第5章. 総括 .......................................................................................................... 65. 5.1 まとめ .......................................................................................................... 65 5.2 今後の課題 ................................................................................................... 65 謝辞 ....................................................................................................................... 66 参考文献 ................................................................................................................. 67 発表文献リスト ...................................................................................................... 69. 4.

(5) 第1章. 序論. 1.1 はじめに近年、急激なスマートフォンの普及と共に、高性能化が進んでいる。したがって、スマートフォンを所有するユーザは、あらゆる場所からインターネットに接続し、様々なサービスを受けることができる。多くのサービスはユーザの近くにある基地局を介して行われる。しかし、例えば電車等の移動環境において同様なサービスを受ける場合、ユーザは移動しているため、接続によりサービスを受ける基地局は頻繁に変化してしまうことが考えられる。また基地局毎に利用している人数は異なり、ユーザの近くにある基地局の数やトンネル、高層ビルのような地域特有の地形はスループットに大きく影響し、基地局毎に異なる。したがって、固定網と比較した場合、移動環境ではスループットは激しく変動するため、無駄なパケットロスやネットワーク混雑が生じ、ユーザに対するサービス品質に強く影響することが考えられる。これらを改善する一つの方法として、ネットワーク自体の改善が挙げられるが、アプリケーションユーザやサービス・プロバイダーは通信事業者ではないため、ネットワークの帯域自体を増やすことはできない。. 図 1.1.1 モバイルデータ([1]より) 図 1.1.1 を見てみると、モバイルネットワークの半分以上が動画ストリーミングで利用され、2018 年には約 70%にまで到達するとされている。したがって、移動環境での動画ストリーミングの品質を維持、改善することはとても重要である。通信事業者らは LTE(Long Term Evolution)や Wi-Fi オフローディングによって、ネットワークの帯域を増やすことを試しているが、ネットワーク混雑はまだ発生しており、アプリケーションに利用される帯域幅は今後高解像度の動画等により増々増えてくると考えられる。. 5.

(6) 1.2 本論文の構成第 2 章では、関連技術について述べる。第 3 章では、SVR を用いた移動環境での通信予測について述べる。第 4 章では、配信レート制御方式の検討について述べる。第 5 章では、まとめと今後の課題について述べる。. 6.

(7) 第2章. 関連技術. 2.1 無線通信技術 2.1.1 LTE (Long Term Evolution)[2]. 図 2.1.1 通信技術のロードマップ([2]より) LTE とは、3GPP と呼ばれる標準化団体が規定した第 3.9 世代の通信規格である。LTE は、次世代通信規格である第 4 世代に効率よく移行するために、第 3 世代の技術を発展させた技術で定められている。図 2.1.1 に示すように、第 4 世代で用いられる無線技術が使用されている。 2.1.1.1 MIMO(Multi-Input Multi-Output)[3][4] MIMO は、複数のアンテナを受信側と送信側に内蔵し、複数のデータを同時に送受信させることで高速化させるワイヤレス通信技術である。図 2.1.2 は 2×2MIMO のイメージ図である。同じ周波数帯域を用いて伝送を行うため、周波数帯域を増やさずに、アンテナの本数を増やすことで通信速度を高速化することができる。MIMO は多くの無線通信に利用されており、LTE では、「2×2 MIMO」、つまり基地局と受信側であるデバイスにそれぞれアンテナを 2 つ使う技術、また「4×4 MIMO」、つまりそれぞれアンテナを 4 つ使う技術が定められている。また、利用する周波数帯域幅に比例し、通信速度が向上する。次世代の通信規格では送信側と受信側にそれぞれ 8 本のアンテナを用いる 8×8 MIMO まで規定されている。. 7.

(8) 図 2.1.2 2×2 MIMO のイメージ図([4]より) 2.1.1.2 OFDMA(Orthogonal Frequency Division Multiple Access)[5][6] OFDMA は、LTE のダウンリンクでの通信で用いられている無線アクセス方式である。この方式は OFDM を基本とされており、時間軸のチャネルと互いに干渉しない周波数軸とを分けることにより、ユーザに割り振る。図 2.1.3 に OFDM と OFDMA の比較を示す。 OFDMA では、それぞれのサブキャリアのシグナルをゼロとするように、周波数軸上で直交するサブキャリアを分けることによって、様々な周波数との干渉を回避することが可能となり、周波数を効率良く利用することができる。LTE では、一定間隔で隣り合うサブキャリアにおいてその 12 個を 1 ブロックと分割することで、これをリソースブロックと呼ぶ。サブキャリアの区切りは 1 ミリ/秒毎とし、時間軸と周波数軸を組み合わせることによって、干渉を起こす影響のないリソースブロックを利用者に提供するシステムである。. 8.

(9) 図 2.1.3 OFDM と OFDMA の違い([6]より) 2.1.1.3 SC-FDMA(Single Carrier Frequency Division Multiple Access)[7][8] SC-FDMA は、LTE のアップリンクで用いられる無線アクセス方式である。QPSK 変調で考えると、ダウンリンクで用いられる OFDMA では 4 個の QPSK データ・シンボルをサブキャリアあたり 1 個、パラレルに送信するのに対し、SC-FDMA は 4 個の QPSK データ・シンボルをシリアルにレートの 4 倍で送信する。また、SC-FDMA の特長として、信号のピーク電力対平均電力比(PAPR)を低減できることがあげられる。これにより UE の省電力化や、送信電力増幅器の低廉化を実現することが可能となる。また、周波数スケジューリングを行うことができ、さらに同一セル内のユーザ間の信号が直交化されていることにより、セル近傍とセル端で目標の受信電力を変更する送信電力制御(Fractional TPC)を行うことができる。 2.1.1.4 64QAM[5][9] 高速無線通信の要素技術にデジタルとアナログの信号を変換する変調があり、1 回の変調つまり 1 シンボルでより多くの情報量を伝送することができれば、伝送効率が上がり、通信速度も速くなる。変調方式の 1 つに QPSK がある。QPSK の場合、電波の送信タイミングを 4 パターンに変更することができる。また、QAM とは電波の位相と振幅の両方を使って信号を伝送する変調方式であり、 LTE では主に 64QAM が用いられる。 64QAM は 16QAM と比較した場合、1 シンボルあたり 4 倍の情報量を送ることができる。しかし、短所として、より細分化されていることによって、QPSK や 16QAM よりもノイズなどに弱いことが挙げられる。LTE の技術においては、変調方式を信号強度を基に変更し、通信の状態が良好 9.

(10) なときに高速に伝送を行うために、この技術を利用し、通信の状態が悪い時には QPSK 等のその他の変調方式を用いて正確に伝送を行うシステムとしている。一度の送信できるデータ量を減らしたとしても、再送を繰り返すことを考えれば、通信速度は速くなる。 2.1.1.5 次世代通信技術[10][11][12] LTE をさらに高速化する、第 4 世代に相当する携帯電話通信規格は LTE-Advanced とされている。LTE-Advanced では、周波数帯を一度に複数束ねて、それらから一斉に通信を行う「キャリアアグリゲーション」という技術が内蔵されることで、速度を上げることが可能となる。この規格で用いられる技術は、キャリアアグリゲーションだけではなく、「インテリジェントリレー」という技術もある。これは子基地局を用いることによって効率を上げる技術である。また MIMO の拡張(8×8 MIMO)、複数の基地局を連携させることでスループット改善を実現するセル間協調送受信(CoMP)、異なる種類の規格等が混ざっているネットワークで高速な通信を行うことを可能とする、ヘテロジニアスネットワーク (HetNet)という技術も導入される予定である。また、2020 年にサービス開始予定である第 5 世代の通信規格では、さらに通信速度が向上し、省電力化も図られる予定であるが、第 5 世代では、利用できる周波数帯をさらに拡大していく必要がある。. 2.1.2 Bluetooth[13][14] Bluetooth は PC のマウスやヘッドフォン等の入出力機器に多く用いられ、 IEEE802.11b/g と同じ 2.4GHz 帯で通信を行う規格である。Bluetooth では、チャネルという概念を持たずにペアリングをさせるだけで通信を行うことができる。また、通信を行う際には瞬間的にある一つの周波数を使用し、出力も制限されているため、比較的近距離の通信に向いている。Bluetooth がなぜ瞬間的にある一つの周波数を使用するのかというと、チャネルという概念を考えずに済むからである。チャネルで通信を分離しなくても、複数機器が干渉することなく、多数の共存ができるという利点があるからである。この方式は周波数ホッピング方式と呼ばれ、この方式では次から次へと周波数を移動するため、次に移動する周波数を予め知らなければ通信を行うことはできない。また、それらの周波数を乱数的に変更することで、同じ周波数が使用される確率は低くなる。Bluetooth では 1/79 の確率になる。 2.1.2.1 マスタとスレーブ Bluetooth にはマスタとスレーブの 2 種類の動作がある。一般的に PC やゲーム本体などはマスタ動作で、ヘッドフォン等がスレーブ動作となる。基本的な動作はマスタで、ペアリングにより、 1 つのマスタに対して 7 つのスレーブがぶら下がるという構造になっている。また、1 台のマスタが管理しているネットワークのことをピコネットと呼ぶ。図 2.1.4 に示すように、ピコネット内ではマスタとスレーブが交互に時間を分けあい通信を行う。 10.

(11) 図 2.1.4 ピコネット内の通信([14]より) 2.1.2.2 ペアリングペアリングは Bluetooth のセキュリティにも役立っており、同じ周波数ホッピングパターンを機器間で交換するものである。ペアリングを行う際には通常の通信とは異なる特別な動作が必要である。図 2.1.5 にペアリングから通信開始までの流れを示す。. 11.

(12) 図 2.1.5 通信開始までの流れ([14]より) ペアリング時には使用できる周波数をすべて使うのではなく、最初の 32 個のみを使用する。さらに、複数のスレーブから一斉に返事が返されると混信するため、32 個の周波数を 16 個ずつの 2 つに分けて交互に使用する。マスタは最初の 16 個の周波数を使用して、スレーブに問い合わせを行い、スレーブ側の待機中の周波数と一致すれば、受信に成功する。スレーブはマスタに対してレスポンスを送信し、存在を知らせる。もし、一致しなければ、マスタは残りの 16 個の周波数を使用して、スレーブに再度問い合わせを行う。その後、マスタは特定のスレーブに対して同期開始を送信し、スレーブは最初にピコネット内で通信が可能であるかどうかを知らせる。可能であれば、マスタは MAC アドレスと内部カウンタの値を含むパケットを送出し、スレーブはそのレスポンスを返し、高速ホッピング開始となる。. 2.1.3 ZigBee[14][15] ZigBee は、Bluetooth と同じ WPAN に属しており、少量のデータを間欠的に通信する時に向いている。Bluetooth はスリープから回復し、データが送信できる状態になるまで約数秒程度要するため、短い間隔でスリープ状態になる環境では適さない。また、ZigBee ではひとつのネットワークに、最大で 65536 台の ZigBee 端末を接続することができる。端末間距離は数十 m であるが、データの中継機能があり、通信可能な範囲を拡大することができる。また、通信のない状態から通信を開始するまでの通信プロトコルを簡素化することで、無線 LAN や Bluetooth 通信と比べて、消費電力を抑えることができる。したがって、ZigBee 12.

(13) はホーム・オートメーション等のセンサ・ネットワークで用いられる。ホーム・オートメーションとは、無線リモコンやセンサでの侵入者の検知、各部屋の空調制御等のことである。無線を使用することで、配線工事の費用等を削減できる。 2.1.3.1 ネットワーク構成. 図 2.1.6 ネットワーク構成([14]より) ZigBee のネットワーク・トポロジは 3 種類ある。スター型では 1 台のコーディネータに対して複数のエンド・デバイスが接続されるため、コーディネータが直接通信を行う必要がある。したがって、通信可能範囲は限られてくる。ツリー型では、スター型と比べて、ルータを用いるため、通信可能範囲を拡げることができる。しかし、継点となっているデバイスに障害が発生し故障してしまうと、そこから先のデバイスと通信を行えなくなってしまう。メッシュ型では、そのようなことが起きないように迂回ルートを設け、障害により強いネットワーク構成となっている。. 2.1.4 高速無線 LAN[13] 無線 LAN とは、多くの家庭や大学内、オフィス内にて、複数のデバイスとネットワーク機器を接続する時に無線を用いて構築された LAN (Local Area Network)である。表 2.1.1 に無線 LAN の分類と性質についてまとめたものを示す。最近では IEEE802.11n を用いて以前よりも高速に通信を行うデバイスが増加し、次世代高速無線 LAN 規格である IEEE802.11ac に対応したルータや PC、スマートフォン等が出始めている。表 2.1.1 無線 LAN の分類と性質([13]より) 分類. 通信距離(例). 規格化団体など. 関連団体や技術名称. 短距離無線. 数m. 個別. RF-ID. 無線 PAN. 10m 前後. IEEE802.15. Bluetooth. 13.

(14) 無線 LAN. 100m 前後. 無線 MAN. 数 km～100km. 無線 RAN. 200km～ 700km. 無線 WAN. IEEE802.11 IEEE802.16、 IEEE802.20. Wi-Fi WiMAX. IEEE802.22 GSM、CDMA、W-CDMA ３G、４G、次世代携帯. 2.1.4.1 IEEE802.11n[16] IEEE802.11n はチャネルボンディングと MIMO を用いて、理論上最大で 600Mbps を実現する無線 LAN 規格である。前者では、周波数帯において、2 つの隣接するチャネルを使用して通信を行う技術である。IEEE802.11a や g における技術では 20MHz が 1 チャネル分であったが、IEEE802.11n では 2 倍の 40MHz で、つまり 2 つのチャネルを用いて通信を行うことによって、より速い速度で通信を可能としている。また、周波数帯域は 2.4GHz と 5GHz 帯で、変調方式は OFDM、IEEE802.11b との互換性を持っている。 2.1.4.2 IEEE802.11ac[17][18] IEEE802.11ac は、従来規格 IEEE802.11n と比較した際、最大約 11.5 倍の高速化を実現する規格である。IEEE802.11ac を支える技術の一つに帯域幅拡大がある。IEEE802.11n では最大 40MHz 幅までの使用であったが、IEEE802.11ac ではさらに拡大し、最大 160MHz 幅までの情報を用いて通信を行うことができる。また、変調信号の多値化を 64QAM から 256QAM とし、シグナル 1 つに含む情報量を増やし、さらに効率を高める。また複数のクライアントが、あるアクセスポイントにぶら下がっている状況において、同時に複数のクライアントに送信することを可能にする MU-MIMO という技術も持っている。送信機：受信機=1：N となるが、ダウンリンクのみである。. 14.

(15) 2.2 ストリーミング技術[19] インターネット等で動画や音声データを再生する方法は大きく分けて 2 種類あり、プログレッシブダウンロードとストリーミングである。プログレッシブダウンロードとは、再生するデータをユーザ端末のハードディスク内に一旦ダウンロードしてから再生する方式である。したがって、ハードディスクにダウンロードされたデータが残ってしまう。ストリーミングとは、ダウンロードしながら再生を行う方式で、ハードディスクにデータは残らない。したがって、ストリーミングでは完全なダウンロードはしないので、容量の大きいデータでもよりリアルタイムに再生することができる。また、ストリーミングはさらにオンデマンド型とライブ型に分かれ、見たい時にいつでも再生を行えるものと、テレビで行われる生放送のように送信側がデータを配信するものがある。. 2.2.1 UDP[20] UDP は TCP のようなコネクション型ではなく、コネクションレス型をとる。したがって、アプリケーション間でのパケット送信以外は何もせずに、アプリケーションが上位に独自のプロトコルを築き上げさせる。UDP のセグメントは 8 バイトのヘッダーとそれに続くペイロードから構成される。図 2.2.1 にヘッダーを示す。UDP パケットが到着すると、そのペイロードは宛先ポートによって処理がされる。送信元ポートは応答を送信元に送り返す際に用いられる。応答を送信するためには、入力セグメントの送信元ポートを出力セグメントの宛先ポートにコピーすることで行われる。また、UDP 長フィールドは、8 バイトのヘッダーとデータを含むセグメント全体の長さを表す。最長の長さは 65515 バイトで、 16 ビットの最大よりも小さい。チェックサムはオプションで用いられ、アルゴリズムはすべての 16 ビットのワードの 1 の補数を合計し、その 1 の補数となっている。. 図 2.2.1 UDP ヘッダー([20]より). 15.

(16) 2.2.2 RTP[21] RTP(Real-time Transport Protocol)は音声やビデオ等のリアルタイム性を重視したものを IP ネットワークにおいて、転送を行うことに対して役立つサービスをすることを目的としている。例えば、タイミングの回復、メディア同期、受信品質のフィードバック等がある。RTP パケットの全体は下位層のペイロードの内部に入れられる。図 2.2.2 にパケットの入れ子構造を示す。. 図 2.2.2 入れ子構造([20]より) また RTP のデータ転送パケットは、RTP ヘッダ、ヘッダ拡張(オプション)、ペイロードヘッダ(オプション)、ペイロード全体の４つの部分で構成される。特にヘッダ拡張においては、試験的に用意されており、その理由としては、ヘッダにペイロードフォーマットで独自の情報を追加する必要がある場合には、新しい RTP プロファイルで定義するのが一番だからである。通常、ヘッダ拡張が使用されるケースは珍しいが、認識しにくいヘッダ拡張パケットを受信した時の対策はしておく必要がある。 2.2.2.1 RTP ヘッダ RTP ヘッダのデータ長は通常、12 オクテットであるが、4~60 オクテットが追加される場合もある。RTP ヘッダにはペイロードタイプフィールドと呼ばれるものがあるが、これは RTP パケットにより転送が行われた際のメディアを識別するために用いられる。また、アプリケーションの多くでは、ペイロードタイプ番号とその仕様を対応付ける RTP プロファイルに従う。表 2.2.1 に割り当ての例を示す。 16.

(17) 表 2.2.1 ペイロードタイプの割り当て([21]より) ペイロードタイプ番. ペイロードフォーマッ. 号. ト. 0. AUDIO/PCMU. 3. AUDIO/GSM. 8. AUDIO/PCMA. 12. AUDIO/QCELP. 14. AUDIO/MPA. 26. VIDEO/JPEG. 31. VIDEO/H261. 32. VIDEO/MPV. 仕様 RFC 1890 RFC 1890 RFC 1890 RFC 2658 RFC 2250 RFC 2435 RFC 2032 RFC 2250. 内容 ITU G.711 μ-law オーディオ GSM フルレートオーディオ ITU G.711 A-law オーディオ PureVoice QCELP オーディオ MPEG オーディオ(MP3 など) Motion JPEG ビデオ ITU H.261 ビデオ MPEG Ⅰ/Ⅱビデオ. ペイロードフォーマットの名前は MIME という、元来電子メールの添付データのコンテンツを識別するために定義された名前空間に従って付けられ、MIME タイプによって各種メディアの転送方法やエンコード方法のオプションを集中して管理する枠組みが提供できるようになった。これらは静的な割り当てであるが、シグナリングによる動的な割り当てもある。また、RTP のパケットヘッダには再生スケジュールを行うことに用いるタイムスタンプというものがある。タイムスタンプは符号なしの整数(32 ビット)で、各メディアに対しての増加する割合が異なっている。また、タイムスタンプの初期値は無作為に決められた値から始まる。理由としては、暗号化された RTP ストリーム上での攻撃を困難にするためである。タイムスタンプは RTP ペイロードに含まれるメディアクロックから取得し、メディアクロックは単調かつ線形に増加し、セッションごとに 1 つの時間軸を生成する必要がある。その他として、RTP のパケットヘッダには、マークを重要なイベントに付けることを行うマーカビットや、パディングが行われ、ペイロードが元の長さとくらべて大きくなってしまっていることを表すパディングビット、バージョンを示すフィールドが設けられている。特にパディングビットでは、追加のパディングが行われるとパディングビットのセットが行われ、最後のオクテットにパディングを行ったオクテット数がカウントされ、 17.

(18) 埋められる。 2.2.2.2 ペイロードヘッダ・データペイロードヘッダはヘッダ拡張のあとに挿入され、RTP ヘッダに入らない情報の定義を行う。また、ペイロードヘッダの直後に、ペイロードデータからなるフレームが 1 つ以上続く。フォーマットとデータのサイズはセッションを設定する時に決められるパラメータにより決定される。また、パケット 1 つに対しては通常、データフレームを複数個入れることができ、最大数は指定されない。各パケットに含めるペイロードデータ量は、データが流れるネットワークの MTU と後続データによる遅延によって選択される。MTU の問題としては、MTU を超えるパケットは分割または破棄されるため、分割された場合には、受信側で組み立てなければならない。したがって、すべての分割されたパケットを受け取る必要がある。また、遅延の問題としては、パケットすべての生成を待つため、生成が最初に完了したオクテットが最後のオクテットまで待たなければならず、全体のパケット送信遅延に繋がるということである。これらの遅延はアプリケーション機能の制限につながってしまう。. 2.2.3 RTP 制御プロトコル[21] RTP はデータ転送プロトコルと制御プロトコルで構成されており、制御プロトコルのことを RTCP(Real-time Transport Control Protocol)と呼ぶ。RTCP は受信品質、参加者の識別、ソース情報、セッション内メンバーの変更通知等を定期的にレポートする。また、ストリーム間の同期も行っている。 2.2.3.1 RR パケット RR パケットとは、RTCP 受信レポートパケットのことであり、データを受信する側はこのパケットを送信する。RR パケットを送信する目的の一つとして、受信品質のフィードバックが挙げられる。送信側では、RR パケットに従って、データ転送量を調節することができ、問題が生じた際にも対応がとりやすくなる。RR パケットを受信するまでの経過時間等から RTT を求めることもできる。また、RR パケットに含まれる情報は多くが累積値で示されるため、例えばパケットの欠落率は累積統計情報から算出することも可能となる。欠落のほとんどは輻輳に因るものなので、データのレートを下げる等の対応ができる。 2.2.3.2 SR パケット RTCP ではデータを送信した直後の参加者が送信する送信レポートパケットを運ぶ。つまり、送信者からストリームに関する情報を伝えるために用いる。SR パケットのフォーマットを図 2.2.3 に示す。. 18.

(19) 図 2.2.3 SR パケットフォーマット([21]より) NTP タイムスタンプでは、符号のない 64 ビットで表され、SR パケットが送信された時間を示し、RTP タイムスタンプでは NTP タイムスタンプと同じ瞬間を、RTP メディアクロックの単位で表現される。SR パケットを送信する目的の一つとして、リップシンクが挙げられる。リップシンクとは映像と音声の再生のタイミングをあわせることである。アプリケーションはデータ受信を行わずに、SR パケットの内容からパケットの平均レートとペイロードデータにおける平均レートを計算することができる。したがって、これらからペイロードにおける平均のサイズを得られる。そして、タイムスタンプを使用することによって、メディアクロックと外部参照との間の対応付けることが可能となる。. 2.2.4 HTTP Live Streaming[22] 従来の RTSP を用いた標準的なストリーミングでは、プロトコルや必要なポートがルータやファイアウォールの設定によってブロックされる可能性がある。一方、HTTP Live Streaming では、ウェブの標準的なプロトコルである HTTP を用いることによってブロックの問題を解消でき、特別なサーバを設置しなくてもストリーミングを行うことができる。また、PHP 等のツールからコンテンツ配信のカスタマイズを行い易いという点もメリットの一つとして挙げられる。HTTP Live Streaming では予めサーバ側で配信動画のエンコードと分割を行い、プレイリストを作成する。クライアント側は単純にダウンロードを行い、プレイリストに記された順番で再生を行う。ライブストリーミングの場合には、動的にプレイリストの更新が行われる。図 2.2.4 に HTTP Live Streaming の概要を示す。. 19.

(20) 図 2.2.4 HTTP Live Streaming([22]より). 2.2.5 MPEG-DASH(Dynamic Adaptive Streaming over HTTP)[23 ] 2.2.5.1 MPEG-DASH とは MPEG-DASH の特徴として、帯域に応じたビットレート切替えが挙げられる。様々なデバイスで動画を視聴する際に、帯域等のユーザの環境を考慮し、途切れないようにビットレートを変動させることによって、帯域に対して最適な品質で動画を視聴することができる。例えば、ネットワークが混雑して帯域が狭い場合には、高ビットレートで動画を配信してしまうと再生が途切れてしまう可能性があるため、ビットレートを最適なものに変更し、途切れないようにする。図 2.2.5 に MPEG-DASH の概要を示す。. 20.

(21) 図 2.2.5 MPEG-DASH の概要([23]より) ビットレートの切替えを行うために、予め配信サーバに複数のビットレートに対応したメディアファイルを用意しておき、これらについての情報を MPD ファイルに記載する。クライアント側(メディアプレーヤ等)は最初に MPD ファイルを取得し、解析を行う。解析によりプログラムタイミングやメディアファイルの取得先、最大最小ビットレート等のストリーミング配信に必要な情報を取得し、HTTP GET 要求を用いて、セグメントを取得しストリーミングが開始される。また、ある程度バッファリングが行われた後にネットワーク帯域の監視も行われ、この計測によってビットレートを決め、十分なバッファ量を維持・確保する。. 21.

(22) 2.2.5.2 MPD ファイル. 図 2.2.6 MPD ファイル([23]より) 図 2.2.6 に示すように、MPD ファイルは XML 形式の階層構造で書かれており、一つまたは複数の period から構成される。Period とはコンテンツなどを構成する一つの単位のことである。それぞれの period はスタート時間、符号化された情報が記載されている adaptation set を持っている。基本的に Adaptation set には異なるビットレートが含まれており、それぞれ複数の representation を持っている。Representation は一つまたは複数のセグメントから構成され、各セグメントは HTTP GET 等を用いてダウンロードを行うためのサーバの場所を示すユニークな URL を持っている。最初のセグメントは DASH クライアントのメディアデコーダの初期化を行う情報を含んでおり、そこにはメディア情報は含まれていない。また、複数の部分でセグメントをダウンロードするために、インデックスを用いてサブセグメントのシグナリング方法を定義しており、DASH クライアント側は部分的に HTTP GET を用いることによって、サブセグメントを要求するためのインデックス情報を使うことができる。ストリーミングを行うためには、DASH クライアントは最初に MPD ファイルの XML の構文解析を行い、representation を選択する。Representation にはセグメント情報が書かれているので、クライアント側では、タイムラインを決め、適切なメディアセグメントをリクエストすることによって、コンテンツをスタートし始める。. 2.3. 予測技術とバッファリング. 予測技術に関する研究は様々あるが、大きく分けて 2 種類に分けられる。一つは TCP の振る舞いを表した数式を用いた手法、もう一つはデータに基づいた手法である。ここでは、特に後者に関連する研究について述べる。また、ビデオストリーミングにおける基本的な 2 22.

(23) つのバッファリング戦略についても述べる。. 2.3.1 PROTEUS[24] PROTEUS とは、短い時間スケールでリアルタイムに詳細なネットワークパフォーマンスを予測するシステムインタフェースである。PROTEUS は、基礎となるトランスポートプロトコルと広く RTC アプリケーションによって使用されるすべてのパフォーマンスの最適化の技術（例えば、FEC、デジッタバッファ、輻輳制御）を補完するように設計されている。目的としては、アプリケーション固有の最適化を行うことができるように、遅延、損失、スループットの予測をアプリケーションに提供することである。測定時のオーバヘッドを回避するために、アプリケーショントラフィックに依存するライブラリとして設計されている。これは、発信および着信パケットのための時間とシーケンス番号を付加し記録することによって行われる。また、PROTEUS は、以下の２つの API を持っており、概要を図 2.3.1 に示す。・inform API： PROTEUS へ、そのアプリケーションの send 関数,recv 関数を wrap したり、シーケンス、タイミング情報を PROTEUS に知らせる。・inquiry API：予測したネットワークパフォーマンスを PROTEUS から取得する。. 図 2.3.1 PROTEUS 概要([24]より). 2.3.2 無線状態を用いた手法[25] [25]では、ビデオ配信制御を行うために SINR(Signal－to－Interference plus Noise power Ratio),RSRP(Reference Signal Received Power),RSRQ(Reference Signal Received Quality)等の無線状態を考えて予測を目指しており、最終的に用いるスループット TP_a を以下の式で計算される。 23.

(24) TP_a = min⁡(TP⁡_⁡r, TP⁡_⁡t). (2.3.1). TP_r : 無線状態を用いてスループットを計算された値 TP_t : 接続された基地局とアクセスするための時間に基づいて最大のスループットを計算した値 TP_t はユーザの移動に影響され、TP_r は LTE システム内の SNR に基づく CQI(Channel Quality Indicator)によって計算される。. 2.3.3 混合モデルを用いた手法 [26] [26]では、図 2.3.2 に示すようにスループットには 2 つの状態があるとしている。一つは定常状態、もう一つは非定常状態である。定常状態とは、スループットが一定値の周りを変動している状態であり、非定常状態とは、安定しないスループット変動の状態を示す。. 図 2.3.2 スループットの状態図([26]より) 予測モデルを構築する際には、先述した通り、スループットには定常状態と非定常状態が存在するため、それぞれで別々に構築し、混合比𝑟𝑡 (指数平滑)によってそれらを混合する。定常状態だと判断された場合には、モデルにおける期待値𝜇t と分散𝜎𝑡2 を以下の式で求める。. 𝜇t = 𝐸𝑠 [𝑥𝑡 ] = 𝑝𝑡 𝑥0 +. 𝜎𝑡2 = 𝑉𝑠 [𝑥𝑡 ] = 𝜎𝑠2. また非定常状態の時は以下の式で求められる。. 24. 𝑎(1 − 𝑝𝑡 ) 1−𝑝. 1 − 𝑝2𝑡 1−𝑝. (2.3.2). (2.3.3).

(25) 𝜇t = 𝐸𝑛 [𝑥𝑡 ] = 𝑥0. (2.3.4). 𝜎𝑡2 = 𝑉𝑛 [𝑥𝑡 ] = 𝜎𝑛2 t. (2.3.5). 2.3.4 バッファリング戦略[27] ビデオ配信におけるバッファリング戦略の一つに Short ON-OFF Cycles がある。Short ON-OFF Cycles は Zippy Pacing とも呼ばれ、セッション開始後に、ある短い周期でバッファリングを行い、一定のバッファ量を維持するものである。また、一度に多くのバッファ量を確保し、それらを長い周期で繰り返す Long ON-OFF Cycles という戦略もある。これは Sawtooth Pacing とも呼ばれる。以下にバッファリングの一例を示す。. 図 2.3.3 バッファリングの一例(左側:Zippy Pacing, 右側:Sawtooth Pacing)[27] ここでは、さらに効率良くバッファリングを行うために、最大バッファ量と最小バッファ量を変化させ、通信品質が良い時にはバッファ量を抑えて、また通信品質が悪い時にはバッファ量を増やすことにより、ユーザが動画再生を途中で停止した際にもパケット量がなるべく無駄にならないようにしている。. 25.

(26) 第3章. SVR を用いた移動環境での通信予測. 3.1 提案システム概要電車等の移動環境にてスループットを予測する際には、接続される基地局が頻繁に変化してしまい、スループットの変動傾向が変わる可能性がある。また、スループットは時間帯によって変動の仕方が変わるため、時間帯の考慮も行う必要がある。したがって、本研究では、スループットに位置情報を付加することにより、ユーザの移動を考慮した、異なるエリアにおけるスループットデータを用い、またスループットデータは時間帯別に収集したものを用いることにより、時間帯による変動傾向も考慮する。ユーザは様々なルートで移動するため、移動に応じて予測に利用するモデルを適応に変化させる必要性がある。今回は、電車等のユーザの移動ルートが固定化されている環境を想定している。図 3.1.1 は提案システムの概要であり、例えば、AM10:00 のスループットを予測したい場合には、予め AM10:00 の予測に使用するデータを収集しておき、エリア毎にスループットモデルの構築を行う。ここでは SVR(Support Vector Regression)を用いてモデルを構築する。したがって、事前に収集するという時間的コストはかかってしまう。事前実験として、駅間や時間帯、基地局別スループットについて調査し比較を行う。. 図 3.1.1 提案システムの概要. 3.2 事前実験 3.2.1 データの収集提案システムでは様々な場所と時間帯のデータを用いるため、事前にデータ収集を行う必要がある。今回は Android 搭載のスマートフォン(GalaxySC-03)にてアプリを作成し、実際に電車に乗り、数ヶ月の間データを収集し続けた。 3.2.1.1 Android アプリ作成データを取得する際に使用する Android アプリは、アプリマーケットにある既存のアプ 26.

(27) リを用いて収集を行ってもよいが、既存のアプリでは使用できる機能は作成者に依存しているため、研究を行う上で汎用性に欠ける。したがって、今回はアプリを自作し、データ収集を行うことにする。図 3.2.1 にアプリの主画面を示す。. 位置情報(緯度,経度) RSSI(Received Signal Strength Indication) Throughput. データ数. 図 3.2.1 アプリの主画面スループットは LTE 網で測定し、以下の式のように 1 秒間に取得できるダウンロードサイズから求めている。位置情報は GPS と NTT ドコモから提供されている基地局を利用した位置情報を用いてスループットの取得箇所としている。基地局を利用した位置情報の詳細については、後述することにする。時間や平日休日情報に関しては、図 3.2.1 のアプリ画面に直接は表示させていないが、バックグラウンドで取得している。. Throughput = ⁡. 𝑑𝑜𝑤𝑛𝑙𝑜𝑎𝑑𝑠𝑖𝑧𝑒 ∗ 8 downloadtime. (3.2.1). 取得されたデータは、逐一サーバーにアップロードし、データベースに格納することにする。データベースは様々あるが、今回はオープンソース・データベースである MySQL に PHP のスクリプトを用いてデータの追加を行った。. 3.2.2 データ可視化マップ取得されたデータを可視化するために、google maps[28]機能を用いた。具体的には、 Google maps では JavaScript 向けの API が公開されており、ここで提供されているヒートマップ描画機能を利用して視覚的にデータを見ることにする。図 3.2.2 にデータの可視化(一 27.

(28) 例)を行ったものを示す。図 3.2.2 を見てみると、通信品質はエリア毎に異なることがわかる。. 図 3.2.2 データの可視化の一例. 3.2.3 駅間における確率分布 Android 端末により、取得したスループットデータ(2013 年)を用いて、位置情報(GPS) により区別し、駅間毎の確率密度分布を作成し、比較してみる。図 3.2.3~図 3.2.9 に結果を示す。比較する時間帯は PM1:00,PM2:00,PM6:00,PM8:00,PM9:00,PM11:00 とする。. Probability density. 0.3 0.25 PM 1:00. 0.2. PM 2:00. 0.15. PM 6:00. 0.1. PM 8:00. 0.05. PM 9:00 PM 11:00. 0 0. 5. 10. Throughput [Mbps]. 図 3.2.3 市川~小岩間. 28.

(29) Probability density. 0.3 0.25. PM 1:00. 0.2. PM 2:00. 0.15. PM 6:00. 0.1. PM 8:00. 0.05. PM 9:00. 0 0. 5. 10. PM 11:00. Throughput [Mbps]. 図 3.2.4 小岩~新小岩間. Probability density. 0.3 0.25. PM 1:00. 0.2. PM 2:00. 0.15. PM 6:00. 0.1. PM 8:00 PM 9:00. 0.05. PM 11:00. 0 0. 5. 10. Throughput [Mbps]. 図 3.2.5 新小岩~平井間. Probability density. 0.6 0.5. PM 1:00. 0.4. PM 2:00. 0.3. PM 6:00. 0.2. PM 8:00. 0.1. PM 9:00. 0 0. 5. 10. Throughput [Mbps]. 図 3.2.6 平井~亀戸間 29. PM 11:00.

(30) Probability density. 0.3 0.25 PM 1:00. 0.2. PM 2:00. 0.15. PM 6:00. 0.1. PM 8:00. 0.05. PM 9:00. 0 0. 5. 10. PM 11:00. Throughput [Mbps]. Probability density. 図 3.2.7 亀戸~錦糸町間. 0.4 0.35 0.3 0.25 0.2 0.15 0.1 0.05 0. PM 1:00 PM 2:00 PM 6:00 PM 8:00 PM 9:00 0. 5. 10. PM 11:00. Throughput [Mbps]. 図 3.2.8 錦糸町~両国間. Probability density. 0.35 0.3 0.25. PM 1:00. 0.2. PM 2:00. 0.15. PM 6:00. 0.1. PM 8:00. 0.05. PM 9:00. 0. PM 11:00 0. 5. 10. Throughput [Mbps]. 図 3.2.9 両国~浅草橋間 30.

(31) 図 3.2.3 の市川~小岩間ではどの時間帯も平均スループットが約 3[Mbps]付近で、TCP スループットに関して大きな変化は見られなかった。また、図 3.2.4 では PM1:00 が最も平均スループットが高いという結果になった。時間が遅くなるにつれて、スループットは下がっていく。図 3.2.5 と図 3.2.6 については、両者とも PM2:00 台が低いスループットを示している。また、図 3.2.3 と比べてピークの位置が散らばっている。つまり、時間帯によってスループットのアップダウンが激しいことがわかる。PM1:00 と PM2:00 のスループットを比較してみると、昼間は夜に比べてスループットが高いが、区間によっては常に高いとは限らないことがわかる。これは、取得した日に依存する可能性も考えられるため、一概には言えないが、その他の理由として考えられるのは、地域の特徴で、その時間にサラリーマンのモバイル端末利用が多いことも考えられる。これはデータをより取得していくことで区間ごとの特性がわかってくると思われる。図 3.2.8 では、他の区間と比べて、スループットのピーク位置が低いところにある。. 3.2.4 基地局を利用した位置情報提供機能[29] 基地局を利用した位置情報提供機能とは、NTT ドコモが所有するサーバにアクセスすることで得られる基地局情報を利用することで、おおよその現在地を知ることができる機能である(現在は無料で利用可)。これにより、基地局ベースの位置情報を取得できる。特徴としては、位置測定が困難な屋内や地下でも短時間に位置情報を取得でき、GPS よりも消費電力が節約できることが挙げられる。また、この位置情報は同じ基地局エリアの範囲内では変化しない。図 3.2.10 に概要を示す。. 図 3.2.10 基地局を利用した位置情報提供([29]より) この機能を利用するためには、携帯キャリアはもちろん docomo のみであり、利用申請サイト[30]にて新規アカウント登録(利用するための基本情報登録等)が必要である。また、API を利用するために、サービス登録・申請が必要で、申請が許諾された後に API の利用が許可される。また利用するサービスをお客様サポートへ別途登録する必要がある。すべての登録等が完了すると利用可能となる。アプリケーションから基地局情報を取得するには図 3.2.11 の構造で HTTP リクエストを行う。また HTTP レスポンス画面を図 3.2.12 に示す。 31.

(32) 図 3.2.11 HTTP リクエスト構造([29]より). 図 3.2.12 HTTP レスポンス画面例図 3.2.12 を見てみると、HTTP レスポンスではおおまかに以下の情報を得ることができる。 ① Lat 要素 32.

(33) ② Lon 要素 ③ Time 要素：測位時刻 ④ AreaCode 要素：取得位置に対するエリアコード ⑤ AreaName 要素：取得位置に対するエリア名 ⑥ Adr 要素：取得位置に対する住所 ⑦ AdrCode 要素：取得位置に対する住所コード＝住所を一意に識別するコード ⑧ PostCode 要素：取得位置に対する郵便番号 3.2.4.1 使用例ドコモから提供される位置情報提供機能を用いて、電車に乗り位置情報を取得した。実験環境は地上と地下の２箇所で、地上は山手線、地下は丸ノ内線、副都心線で行う。図 3.2.13 と図 3.2.14 に結果を示す。. 図 3.2.13 ドコモの API 利用例(地上). 33.

(34) 図 3.2.14 ドコモの API 利用例(地下) 結果において、実際のユーザの経路を赤線で示す。図 3.2.13 は山手線における東京駅周辺を表したものである。ドコモから提供される位置情報提供機能では、同じ基地局エリアでは位置情報は変化しないため、ユーザの現在地をピンポイントで示すことは難しいが、ある程度のユーザの位置はわかり、ユーザの移動経路を追うことができるということを確認した。また、図 3.2.14 は丸ノ内線と副都心線の結果であるが、地下でも地上と同様に位置情報提供機能により、位置情報を取得することは可能である。しかし、地下では、地上ほど位置情報の更新は行われず、ピンの数が地上に比べて少ない結果となった。この位置情報提供機能は基地局情報を取得するものなので、地下から接続される基地局の数が少ないのかもしれない。また、信号強度を強くして、基地局の数自体を減らしている可能性も考えられる。今回の実験では一度の乗車で取得しているため、その時に接続されなかった基地局が隠れている可能性もあり、何度も往復して位置情報を取得すると、ピンの数も増えるかもしれない。また取得速度は、GPS よりも短時間で取得ができるため、地下での位置情報の取得や素早く位置情報が知りたい時には有効な手段の一つだと考えられる。. 3.2.5 時間帯別スループット比較時間帯によりスループットはどのように変化しているのかを調査するために、電車における異なる 3 つのルート(総武線：平井~亀戸駅、亀戸~錦糸町駅、錦糸町~両国駅)において、数か月間スループットを取得し、それらを時間帯別に分け、比較する。時間帯は朝 9 時から夜 23 時までとする。比較した結果を図 3.2.15 に示す。. 34.

(35) Average throughput [Mbps]. 5. 4. 3. 2. 1. 0 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. Time [hours] kameido～kinshichou. hirai～kameido. 19. 20. 21. 22. 23. kinshichou～ryogoku. 図 3.2.15 時間帯別スループットスループットが変化する理由の一つとして、ユーザの行動が挙げられる。ユーザの行動は時間帯によって変わる。しかし、図 3.2.15 を見てみると、まったく同じ変動をしているルートは見られないが、似たような動きをしている時間帯はある。例えば、12 時台では、近くの時間帯と比較して、スループットは減衰している。多くの人が昼休みで各々のスマートフォンからインターネット接続しているからだと考えられる。また、マクロに見た場合に、夕方 16,17 時以降はスループットが低くなる傾向もある。しかし、今回の結果では、すべての時間帯ではないが、スループットは日中よりも夜の方が平均的に低いという結果になった。場所に応じて異なる場合があるが、傾向として、昼のランチタイムに利用する人よりも帰宅ラッシュ中にモバイル網を利用する人が多いことが挙げられる。これは帰宅時と比べ、ランチタイム等の昼時は、ユーザが一つ場所に滞在する時間が長いため、店内 wifi 等を利用することによってモバイルデータ量を抑えたり、速度の速い方を選んで接続している可能性も考えられる。. 3.2.6 基地局毎における比較(平日のみ) ドコモが提供する位置情報提供機能では、同じ基地局エリアの範囲内では変化しない。したがって、ある基地局のエリア内での基地局情報、特に緯度と経度は固定の値なので、それらを基地局毎に分類し、平均スループットと RSSI の比較を行う。一定範囲のエリアにおいて、電車から接続された基地局での比較を行う。図 3.2.16 に結果を示す。. 35.

(36) 6. 0 -10 -20. 4. -30. 3. -40 -50. 2. RSSI [dBm]. Throughput [mbps]. 5. -60 1. -70. 0. -80 1. 3. 5. 7. 9 11 13 15 17 19 21 23 25 27 29 31 33 35 37 Base Stations throughput. rssi. 図 3.2.16 基地局毎のスループット図 3.2.16 を見てみると、RSSI については、基地局は高い位置に設置されていることが多く、それほど基地局毎に大きく変動はしないことがわかる。しかし、RSSI は人の動き、その時の何らかの電波干渉によって異なる可能性があるため、小さな違いは出てしまう。または取得している端末依存もあるかもしれない。ただ今回は同じ端末で取得しているので、これは考えにくい。スループットについては、基地局別に違いがあり、スループットの比較的出やすいところや出にくいところがあることがわかる。これは基地局にぶら下がっている人数が異なることを示している。また、スループットと RSSI の関係については、RSSI が変化するとスループットにも影響があり、RSSI が下がるとスループットの値が下がっている箇所もいくつか見られることがわかる。. 3.2.7 平日と休日における比較平日と休日でスループットに対する影響を調査した結果を図 3.2.17 に示す。. 36.

(37) 6. 0 -10 -20. 4. -30. 3. -40 -50. 2. RSSI [dBm]. Throughput [mbps]. 5. -60 1. -70. 0. -80 1. 3. 5. 7. 9 11 13 15 17 19 21 23 25 27 29 31 33 35 37 Base Stations. th_weekday. th_holiday. weekday. holiday. 図 3.2.17 平日と休日のスループット比較 RSSI について、平日と休日を比較してみると、ほとんど同じ範囲内で変動していることがわかる。人の動き方によって変動は変わるため、平日と休日での違いは少ないと言える。また、スループットに関しては、休日の方が平日よりも高いスループットが出ている箇所が多く、マクロに見ると、平日と似たような傾向にあることがわかる。平日、休日ともに変わらないところや、平日よりも休日の方がスループットが下がってしまう箇所も存在している。. 3.3 評価実験 3.3.1 SVR(Support Vector Regression)の利用集められたデータを用いてスループットモデルの構築は様々な方法が考えられる。しかし、今回は特に SVR で学習(R 言語)を行うことにする。R 言語のパッケージには e1071 と kernlab の 2 種類があるが、kernlab を用いることにする。データ数は少ないよりも多い方が良いと考えられるため、学習データ数を補うために、収集したデータからランダムデータを生成する。ランダムデータは、ある一つの基地局データだけで生成されないように位置情報を基に生成する。また、スループットの広がり方をモデル化するために、複数回行った後、それぞれのモデルの最大、最小、平均値(中間値も求めたが平均値とほとんど変わらなかった)を求め、スループットモデル(仮)とする。スループットモデル(仮)はランダムデータに影響されやすいため、これらを 3 回行ったものを平均することで最終的なスループットモデルとする。図 3.3.1 にランダムデータの例を、図 3.3.2 に大まかな流れを示す。 37.

(38) 図 3.3.1 ランダムデータの一例. 図 3.3.2 学習フロー. 3.3.2 パラメータ変更による比較 Kernlab ではパラメータを選択することができるため、パラメータの違いにより、モデルがどのように変化するのかについて比較を行う。最初にカーネルの違いについて比較を行う。表 3.3.1 にその他の SVR のパラメータを示す。比較を行うのは以下のカーネルであ 38.

(39) る。出力結果を図 3.3.3～図 3.3.6 に示す。 ① Polynomial (多項式カーネル) ② Gaussian (ガウシアンカーネル) ③ Linear (線形カーネル) 表 3.3.1 パラメータ Type. epsilon-svr. Cost. 0.1,1,10. Epsilon. 0.001,0.01,0.1. 図 3.3.3 多項式カーネル(左：degree=6,右：degree=9). 39.

(40) 図 3.3.4 多項式カーネル(degree=15). 図 3.3.5 ガウシアンカーネル. 40.

(41) 図 3.3.6 線形カーネル多項式カーネルに関しては、数式の指数部分にあたる degree の値を変化させることによって結果が異なってくる。ここでは、degree の値を 6,9,15 と変化させたが、このカーネルを使う場合には使用する環境に応じて、最適な degree を指定する必要がある。また、図 3.3.6 を見てみると、線形カーネルに関しては、激しく変動するスループットには適さないと考えられる。またガウシアンカーネルは、デフォルトで設定されているカーネルで、この結果から見ると多項式カーネルと似たような動きをしていることがわかる。次に type パラメータを epsilon-svr と nu-svr に変更した場合について比較を行う。カーネルはガウシアンカーネルを用いる。出力結果を図 3.3.7 に示す。図 3.3.7 を見てみると、やまなりの位置やスループットの高低において、モデルの波形が少しだけ異なっていることがわかる。. 41.

(42) 図 3.3.7 左：epsilon-svr,右：nu-svr. 3.3.3 時間帯による比較朝昼晩のデータを用いて生成されるスループットモデルにどの程度違いがあるのかを調べるために、代表として 9 時台,13 時台,21 時台の比較を行う。表 3.3.2 に SVR パラメータを示す。出力結果を図 3.3.8 に示す。表 3.3.2 パラメータ Type. epsilon-svr. kernel. Gaussian Kernel. Cost. 0.1,1,10. Epsilon. 0.001,0.01,0.1. hyperparameter. 0.5,1.0,…5.0. 42.

(43) 7. Throughput[mbps]. 6. 9h_average. 5. 9h_max. 4. 9h_min 13h_average. 3. 13h_max. 2. 13h_min 21h_average. 1. 21h_max. 0 1 -1. 11. 21. 31. 41. 51. 61. 71. 81. 91 101 111. 21h_min. Time[s]. 図 3.3.8 時間帯による比較図 3.3.8 において、9 時台は青線、13 時台は赤線、21 時台は緑線で表している。21 時台は他の時間帯よりもスループットモデルが低い結果となった。これは、スループットモデルを構築するときに使用する 21 時台のスループットデータ自体が低いので、結果的にスループットモデルは他の時間帯よりも低く構築される。また変動幅は比較的広い結果となった。 9 時台と 13 時台を比較してみると、似たような動きをしていることがわかる。しかし、詳細に見ると、例えば 60 秒後において、9 時台は少しスループットのモデルが減少しているが、13 時台は逆に増加している。増加するところと減少するところは時間帯に影響されることがわかる。このスループットモデルを用いて、評価を行う。評価方法は今回生成したスループットモデルの範囲内に実測データがどの程度おさまっているかどうかで判断を行うことにする。図 3.3.9 に評価結果を示す。. 43.

(44) 70 Accuracy[%]. 60 50 40. max. 30. min. 20. average. 10 0 9h. 13h Time[hours]. 21h. 図 3.3.9 朝昼晩の評価図 3.3.9 に複数回行ったときの最大と最小、平均値を示している。時間帯によって精度に少しばらつきがある。しかし、それほど大きなものではないと思われる。21 時台において最大最小の差が最も大きくなった。これは 21 時台が他と比較した場合に変動が大きいためだと考えられる。最大値の精度が最も低かったのは 9 時台であるが、最小値の精度が最も低かったのは 21 時台である。. 3.3.4 位置情報によるグループ分けエリアにおいてスループットモデルを生成する場合に、一つのエリアには多くの基地局が存在し、基地局毎にスループットは異なっている。したがって、位置情報として基地局情報を用いて、それらをより基地局毎の特性を考慮するために、細かいグループ分けを行う。スループットモデルの比較を図 3.3.10~図 3.3.12 に示す。. 6. Throughput[mbps]. 5 4 3. max. 2. average min. 1 0 -1. 1. 20. 39. 58. 77. 96. Time[s]. 図 3.3.10 3 グループ分け 44. 115.

(45) 6. Throughput[mbps]. 5 4 3. max. 2. average min. 1 0 -1. 1. 20. 39. 58. 77. 96. 115. Time[s]. 図 3.3.11 6 グループ分け 6. Throughput[mbps]. 5 4 3. max. 2. average min. 1 0 -1. 1. 20. 39. 58. 77. 96. 115. Time[s]. 図 3.3.12 10 グループ分け図 3.3.10 から図 3.3.12 を見てみると、スループットモデルは異なっていることがわかる。特に、60 秒付近においてモデルに違いが表れている。図 3.3.10 ではおおまかに基地局を 3 つのグループとしてモデルを生成している。したがって、複数の基地局におけるスループットデータが混在しており、基地局毎の変動特性はわかりづらいことがわかる。例えば、比較的ぶら下がっている人数が多く、高いスループットが出にくい基地局であるのに、高いスループットが出ている基地局の影響を受けてしまうといったことが考えられる。しかし、分けるグループ数を 3 から少しずつ細かくしていくと、基地局毎のより多くのデータ数を必要とするが、基地局毎の変動特性が詳細に見えるようになっていることがわかる。したがって、より基地局毎にスループットモデルを考える必要がある。評価した結果を図 45.

(46) 3.3.13 に示す。図 3.3.13 を見てみると、グループ分けを細かくすると精度に影響が出てくることがわかる。今回の結果では精度が少し良くなり、10 グループ分けでは最大約 60%となった。伸び率を比較してみると、最小値の伸び率が最も大きく、最大値と最小値の差が縮まっていることから、精度のばらつきが比較的小さくなっていることがわかる。. 70. Accuracy[%]. 60 50 40. max. 30. min. 20. average. 10 0 3group. 6group. 10group. Group number. 図 3.3.13 グループ分けの評価. 3.3.5 使用するデータの種類通信事業者は年々、基地局の増設を行っており、また通信技術の発達によりスループットはこれからも向上していくと考えられる。また、長期休暇等による人の行動パターンの変化はスループットにも影響があることが考えられる。例えば、休日等におけるデータ数が少ない状態で休日の予測を行うことは難しいのではないかと考える。また建造物やビル等における環境や地形も変化する可能性があるため、データの更新は必要であると考える。したがって、今回は土日祝日等の休日のデータをより多く収集を行い、収集する前(old)と後(old + new)での比較を行う。スループットモデルにおいて収集する前を図 3.3.14 に、後を図 3.3.15 に示す。評価結果を図 3.3.16 に示す。. 46.

(47) Throughput[Mbps]. 6 5 4 3. max. 2. average min. 1 0 1. 20. 39. 58. 77. 96. 115. Time[s]. 図 3.3.14 収集前 6. Throughput[mbps]. 5 4 3. max. 2. average min. 1 0 -1. 1. 20. 39. 58. 77. 96. Time[s]. 図 3.3.15 収集後. 47. 115.

(48) 60. Accuracy[%]. 50 40 max. 30. min. 20. average. 10 0 old. old + new Kind of data. 図 3.3.16 データの種類図 3.3.14 と図 3.3.15 を見てみると、休日の方が平日よりもスループットが平均的に高い傾向があるので、最大値、最小値が増加している箇所が見られ、またランダムデータ生成によって、休日データの選択される回数が増えたことも原因として考えられる。しかし、それほど変わっていないところもあり、これは収集前のデータにおいても休日のデータが多少含まれてしまっているからだと考えられる。図 3.3.16 を見てみると、精度は少し異なっているが、大きな変化は見られなかった。今回は収集を行う前のデータ数と比べて新たに収集されたデータ数が少ないことが原因の一つとして考えられる。また、休日データと平日データは別々に扱う必要があると思われる。したがって、平日のモデル生成には平日データで、休日のモデル生成には休日データを使うことでより変化が見られる可能性が考えられる。. 3.3.6 各エリアでの通信予測 21 時台に収集されたデータを用いて、総武線における各エリアにてスループットモデルを生成し、実データとの比較を行った。図 3.3.17 は各エリアにおいて、図 3.3.18 は長期の予測結果を示したものである。各エリアの定義を表 3.3.3 に示す。表 3.3.3 各エリアの定義 A. 平井～亀戸駅. B. 亀戸～錦糸町駅. C. 錦糸町駅～両国駅. D. 両国駅～浅草橋駅. 48.

(49) 80 70. Accuracy[%]. 60 50 max. 40 30. min. 20. average. 10 0 A. B. C. D. average. Areas. 図 3.3.17 エリア毎の予測. 70. Accuracy[%]. 60 50 40. max. 30. min average. 20 10 0 conventional. proposed. 図 3.3.18 長期の予測図 3.3.17 を見てみると、各エリアにおいて平均値を見た時には、精度に大きな違いは見られないが、最大値や最小値を見てみると、ばらつきがあることがわかる。例えば、エリア C では最大値で約 70%出ているのに対し、エリア A では最小値が最も低く 50%を下回っていることがわかる。また、エリア B では最大と最小の差が最も大きい結果となっている。したがって、すべてのエリアにおいて平均値を求めると、最大で約 60%となった。図 3.3.18 では列車において各エリアが約 2~3 分であるので、エリア A からエリア D までを 500 秒と仮定した際の結果である。比較対象はユーザが移動を始めた地点のデータを用いて予測を行ったものとする。スループットに位置情報を付加し、それぞれのエリアのデータを用いることによって精度は向上することがわかる。 49.

(50) 第4章. 配信レート制御方式の検討. ここでは、通信予測が行えると仮定した時の動画ストリーミングにおける配信レートの制御方式について考える。. 4.1 概念. 図 4.1.1 配信レート制御の概念図 t0~t1 : 見込みのデータ量を取得する時間 t0~t2 : 同じビットレートで配信する時間例えば MPEG-DASH 等の動画配信では帯域に応じたビットレート切替えが特徴として挙げられる。しかし、ビットレートの切替えが帯域の影響を受け、頻繁に起こる可能性も考えられる。これはストリーミング配信を受けているユーザにとってあまり好ましくない状態だと考える。したがって、図 4.1.1 に示すようなビットレートの決め方をここで検討する。例えばスループットが高いエリアでも DASH 内に格納している最大のビットレートを提供せずに先の通信劣化のエリアも考慮して、ビットレート下げ、通信劣化エリアでも同じビットレートで配信を行うことで、急な通信劣化に対してもビットレートの変動を抑えられ、ビットレートも高いものを保つことができるのではないかと考えている。ビットレート R は以下の式で定義する。ユーザの移動する先の通信状態を予測できるとすると、t0~t1 までに見込まれるデータ量がわかるので、そのデータ量を t2 までで割ることでビットレートが算出できると考える。 𝑡. 𝑅=. ∫𝑡 1 𝑥(𝑡)𝑑𝑡 0. (𝑡2 − 𝑡0 ) 50. (4.1.1).

(51) 4.2 閾値によるビットレート変動 t0 や t1,t2 等のビットレートを算出する際に必要な値をどのように定義するのかは重要な要素だと考えられる。ここでは t0 や t1,t2 等の値を閾値によって決めることを考える。また、スループットデータとして、図 4.1.2 のような 5 秒毎の平均をとり、正規化したデータを考える。今回は特に以下のようなスループットが予測できると仮定した場合、最大スループットの割合を閾値とし、ビットレート変動を行う。. Throughput [mbps]. 6 5 4. 3 2 1 0 1. 101. 201. 301. 401. Time [s] 図 4.1.2 正規化したスループットデータ例(閾値) 図 4.1.2 における最大スループットの 30%~90%と変化させた結果を図 4.1.3~図 4.1.9 に示す。ここでの黄色の線は閾値を示し、黄線とスループットとが交差したところを receive number と呼ぶことにする。receive number が 1 の場合を図 4.1.1 における t0~t1 の範囲に相当し、データ量を取得する時間を表す。. 51.

(52) 5. 1. 4 3 2 1. Receive number. Throughput [mbps]. 6. throughput threshold bitrate receive number. 0. 0 1. 101. 201 301 Time [s]. 401. 図 4.1.3 最大スループットの 90%. 5. 1. 4 3 2 1 0. Receive number. Throughput [mbps]. 6. 101. 201 301 Time [s]. threshold bitrate receive number. 0 1. throughput. 401. 図 4.1.4 最大スループットの 80%. 5. 1. 4 3 2 1. Receive number. Throughput [mbps]. 6. throughput threshold bitrate receive number. 0. 0 1. 101. 201 301 Time [s]. 401. 図 4.1.5 最大スループットの 70%. 52.