• 検索結果がありません。

IEEE802.11e 無線 LAN における 上下トラヒックの非対称性の改善

N/A
N/A
Protected

Academic year: 2022

シェア "IEEE802.11e 無線 LAN における 上下トラヒックの非対称性の改善"

Copied!
34
0
0

読み込み中.... (全文を見る)

全文

(1)

2007 年度 修士論文

IEEE802.11e 無線 LAN における 上下トラヒックの非対称性の改善

提出日: 2008 年 2 月 4 日

指導:後藤滋樹教授

早稲田大学 大学院理工学研究科 情報・ネットワーク専攻 学籍番号: 3606U014-1

閻 多一

(2)

目次

1 序論 5

1.1 研究の背景 . . . 5

1.2 研究の目的 . . . 5

1.3 本論文の構成. . . 6

2 IEEE802.11e無線LAN 7 2.1 無線LANの概要 . . . 7

2.1.1 IEEE802.11 . . . 7

2.1.2 IEEEの規格 . . . 7

2.1.3 CSMA/CA . . . 7

2.2 IEEE802.11e . . . 8

2.2.1 802.11eにおけるQoS . . . 8

2.2.2 EDCA . . . 10

3 VoIPの通信品質 12 3.1 VoIPの概要 . . . 12

3.1.1 VoIPの定義 . . . 12

3.1.2 VoIPを用いる電話システムの構成 . . . 12

3.2 VoIPの特長 . . . 13

3.2.1 通信コストの削減 . . . 13

3.2.2 データネットワークの親和性 . . . 13

3.3 VoIPの課題 . . . 14

3.3.1 通信品質の問題 . . . 14

3.3.2 SIPとは . . . 14

3.3.3 標準化 . . . 14

3.4 通信品質低下の代表的原因 . . . 14

3.4.1 ジッタ . . . 14

(3)

目次

3.4.2 パケットロス . . . 16

4 上下トラヒックの非対称性 17 4.1 問題の背景 . . . 17

4.2 非対称性の問題 . . . 17

4.2.1 リンク層におけるフロー間の非対称性 . . . 17

4.2.2 MAC層におけるフロー間の非対称性. . . 18

4.3 IEEE802.11e MACプロトコル . . . 18

4.4 CWによる改善 . . . 19

5 実証実験 21 5.1 実験の環境 . . . 21

5.1.1 使用する機材 . . . 21

5.1.2 EDCAシミュレータ . . . 21

5.1.3 EDCAシミュレータでできること . . . 22

5.2 実験 . . . 22

5.2.1 ネットワークの構成 . . . 22

5.2.2 実験の手順 . . . 22

5.2.3 実験結果および図表 . . . 23

5.2.4 考察 . . . 25

6 まとめ 26 6.1 結論 . . . 26

6.2 今後の課題 . . . 26

謝辞 27

参考文献 28

A Config program A 30

B Config program B 32

(4)

図一覧

2.1 Traffic Priority . . . 9

3.1 VoIP . . . 13

4.1 IEEE802.11 MAC frame format . . . 18

4.2 IEEE802.11e MAC frame format . . . 18

4.3 MAC Architecture . . . 19

4.4 Exponential increase of CW . . . 19

5.1 EDCA simulator model . . . 22

5.2 ネットワーク環境 . . . 23

5.3 上下トラヒックのスループット . . . 24

(5)

表一覧

2.1 IEEEによる無線LANの規格化 . . . 8

2.2 優先度の対応付け例 . . . 10

2.3 設定可能なQoSパラメータ . . . 11

3.1 ITU-T G.114の音声遅延ガイドライン . . . 15

5.1 機材一覧 . . . 21

5.2 コンピュータの仕様 . . . 21

5.3 実験データ . . . 24

5.4 提案したパラメータ . . . 24

(6)

第 1 章 序論

1.1 研究の背景

近年、IP電話やP2Pなどの双方向トラヒックが増加している。この傾向は無線LAN環境に おいても同様であり、P2PやVoIPなどの端末からアクセスポイントへの上りトラヒックが今後 増加すると予想される。その中でトラヒックの対称性は非常に重要な問題である。上下のフロー が混在すると上りフローのトラヒックに比べて下りフローのトラヒックのスループットが低下す るという非対称問題が発生する。この原因はIEEE802.11e標準MACプロトコルがフロー間で はなく、端末間で無線媒体を対称に使用するように設定されているためである。

1.2 研究の目的

無線LAN上で上下のフローが混在すると、下りフローのトラヒックが流れにくくなるという 問題が発生する。この問題を解決するために、本研究ではIEEE802.11e MACプロトコルのパ ラメータであるコンテンションウィンドを制御することによりこの問題を解決する方式を提案す る。さらに実証実験を行って、提案方式の有効性を検証する。

(7)

第 1 章 序論

1.3 本論文の構成

本論文は以下の章により構成される。

第1章 序論

本研究の背景と目的、および本論文の構成を述べる。

第2章 IEEE802.11e無線LAN

IEEE802.11e標準規格について述べる。

第3章 VoIPの通信品質

VoIPの通信品質について述べる。

第4章 上下トラヒックの非対称性

上下トラヒックの性質について述べる。

第5章 実証実験

実証実験の結果、評価について述べる。

第6章 まとめ

本研究から得られた結論、今後の課題について述べる。

(8)

第 2 章

IEEE802.11e 無線 LAN

2.1 無線 LAN の概要

2.1.1 IEEE802.11

「IEEE802.11」とは、IEEE (米国電気電子学会)でLAN技術の標準を策定している802委 員会が1998年7月に標準仕様として定めた無線LAN仕様で、2.4GHz帯域の電波を利用する方 式と赤外線を使う方式が標準化されている。伝送速度は1〜2Mbpsで、伝送距離は100m程度 となっており、基本的にはデータ伝送に用いる媒体としてケーブルの代わりに電波を用いること ができる。後に2.4GHz帯上で11Mbpsの伝送速度を実現する「IEEE802.11b」や、5.2GHz帯 を使った「IEEE802.11a」などの拡張仕様が発表された。

2.1.2 IEEEの規格

これまでに定められた規格とその概要は表2.1の通りとなっている。

2.1.3 CSMA/CA

有線リンクでは、複数のフレームが衝突するとケーブル上の直流成分が増加するので、これを 検出することで自動的な衝突検出が可能となる。これが、CSMA/CD (CSMA with Collision

Detection)方式である。しかし、無線リンクでは、受信のレベルは無線特有のフェ−ジングによ

り激しく変化するため信号の衝突を検出できない。従って、無線リンクではCSMA/CA (CSMA with Collision Avoidance)方式を用いる。CSMA/CA方式では、各クライアントは通信路が一 定時間以上継続して空いていることを確認してからデータを送信する。この待ち時間は最小限の 時間にランダムな長さの待ち時間を加えたもので、直前の通信があってから一定時間後に複数の クライアントが一斉に送信する事態を避ける。実際にデータが正しく送信されたかどうかは受 信側からのACKが到着するかどうかで判断し、ACKがなければ通信障害があったとみなして

(9)

第 2章 IEEE802.11E無線LAN

規格名 概要

IEEE802.11 最初に登場した無線LANの規格。2.4GHz帯とFHSS方式を用いて2Mbps の速度で通信を行う。

IEEE802.11a 5GHz帯を用いて54Mbpsの通信を行う。

IEEE802.11b 現在最も普及している規格。2.4GHz帯とDSSS方式を用いて11Mbpsの速 度で通信を行う。

IEEE802.11c 有線/無線のブリッジを行うための規格。

IEEE802.11d IEEE802.11で使用している2.4GHzや5GHzを利用できない国でも使用で きるようにするための追加仕様。

IEEE802.11e 無線LANにおいてQoS機能をサポートする拡張MAC規格。

IEEE802.11f 異なるベンダーのアクセスポイント間での相互接続性の保証。

IEEE802.11g IEEE802.11bを拡張し、互換性を保ちながら54Mbpsによる通信を行う。

IEEE 802.11h ヨーロッパにおいて5GHz帯による通信を行うための追加機能。

IEEE802.11i MAC層のセキュリティ機能を強化するための規格。

表 2.1: IEEEによる無線LANの規格化

データの再送信を行う。このため、CSMA/CD方式に比べると効率は落ちる。特に衝突が発生 する場合には、すべてのデータを送信してから応答を待ち、再送するという手順をとるため、通 信性能が著しく低下してしまう。

2.2 IEEE802.11e

802.11eはIEEE (米国電気電子学会)で、LAN技術の標準を策定している802委員会が開発 した無線LANの規格の一つである。IEEE802.11aやIEEE802.11bとの互換性を保ちながら、

QoS機能などの付加機能を追加したものである。

2.2.1 802.11eにおけるQoS

QoS (Quality of Service)とは、コンピュータ・ネットワークにおいて重要な通信の品質を確

保するために、ルーターに実装される技術の一つである。

近年、QoS保証を必要とするアプリケーションが増加している。即ち、1990年代に入ってか らインターネット上で音声通話や動画配信といったリアルタイム・アプリケーションが使われる ようになり、またビジネス向けの高品質なサービスも求められるようになってきた。また、デー

(10)

第 2章 IEEE802.11E無線LAN

タ通信が音声通信を量的に上回り、電話網に匹敵する品質をインターネットにおいて実現するこ とが必要となってきている。

QoSは、他者と差別化し特定のパケットを優先させることで安定したスループットや低遅延を 実現している。QoSの使い方としては、IP電話やビデオ会議、テレビ電話といったリアルタイ ム系トラヒックを最優先する。SNA (System Network Architecture)といった遅延に弱い基幹 系トラヒックや、重要度の高い業務系トラヒックを二番目に優先。電子メールやWebへのアク セス等遅延が生じても問題にならない情報系トラヒックを最も低い優先度とする。

802.11eの仕様では、4種類のトラヒック・クラスを定義することでパケットの優先順位付け

ができるようになっており、4種類のクラスはそれぞれ別の待ち行列(キュー)を持つ。基本設 定では、その4種類は、ボイス、ビデオ、ベストエフォート、バックグラウンドである。同仕様 では、各パケットのトラヒック・クラスの識別用に、有線イーサネットで使われているものに似 たマーカーを使用する。そのマーカーを確認することによって、アクセスポイントは、ボイス・

パケットの伝送を最優先し、次にビデオ・パケットを優先するという具合に対応することができ る。

図 2.1: Traffic Priority

(11)

第 2章 IEEE802.11E無線LAN

このメカニズムは、パケット間の衝突を阻止するための他の複数のメカニズムと組み合わされ る。その他に、802.11eでは、携帯機器のバッテリが長持ちするようにクライアント・デバイス の通信のタイミングを調整する方法も規定されている。

2.2.2 EDCA

EDCAは従来のDCF (Distributed Coordination Function)に相当し、データの種別ごとに チャンネルアクセス頻度に対する優先順位付けができるようになっている。サービス品質の差を つけるには、バックオフ・アルゴリズムで発生する乱数の範囲をアクセスカテゴリ (Access Cat-

egory)毎に変える。すなわち、優先度が高いカテゴリのフレームは、乱数の取る値の範囲が小さ

く、短い待機時間で送信することができる。

EDCAは優先度に基づくQoSであるため、多数の無線LAN端末が存在する環境では効果が 薄れると指摘されている。現状では、各無線機器メーカが実装しているQoSは、アクセス・ポ イントの送信キューに優先度を独自に割り当て実現しているのが殆どで、必ずしもEDCA方式 を忠実に実装しているという訳ではない。

EDCA方式では優先度は、各機器で送信キューを4つ用意し、異なるAC (Access Category) を割り当てる。各ACでは、優先度に応じて異なるキャリア・センス時間とバックオフの乱数範 囲が当てられている。つまり、待ち時間の調整をして、優先度の高いACは、優先度の低いAC と競争した場合でも先に次のデータを送信できるようにしている。また、優先度の高いACに多 量のデータが送られると、QoSを適用しない状態と変わりがなくなってしまう。

DSCP (IP) TCID (802.1p) AC (802.11e) Traffic Type

101xxx 6,7 3 Voice

100xxx 4,5 2 Video

010xxx 0,3 1 Best Effort

000000 2,1 0 Back Ground

表 2.2: 優先度の対応付け例

(12)

第 2章 IEEE802.11E無線LAN

Access Category AIFS CWmin CWmax TXOP Limit

Voice 1,2 3 7 1504

Video 1,2 7 15 3088

Best Effort 3 15 63,1023 0

Back Ground 7 15 1023 0

表 2.3: 設定可能なQoSパラメータ

(13)

第 3 章

VoIP の通信品質

3.1 VoIP の概要

3.1.1 VoIPの定義

VoIPとはVoice over IP (Internet Protocol)の略であり、IP電話やインターネット電話を実 現するための技術である。従来、公衆電話網で使われていた電話音声やFaxの信号をIPパケッ ト化し、イントラネット/インターネットなどのIPネットワーク上で音声通信等を可能にする。

電話網のインフラをデータネットワークと統合することで、回線の稼働率を上げ、通信コストを 下げるのが本来の目的である。従来の電話システムと異なり、通常のインターネットと同じくIP ネットワーク網であるため、距離非依存の固定料金制を採用することができる。これに加え、従 来の電話ではできなかったような、例えば相手が無人でも監視目的で遠方の場所の物音を聞いた り、IPパケットを受け取ることから発信元の認証が容易にできたりするといった応用技術も最 近注目されつつある。

3.1.2 VoIPを用いる電話システムの構成

VoIPを用いる電話システムの原理的な構成は、端末とネットワークから構成される。図3.1に 示す様に、電話の音声信号をゲートウェイによりIP化し、ルータを経由してInternetの網を利 用し音声通信を可能として、音声とデータを統合した情報通信システムである。VoIPを利用し たものとしてIP電話がある。従来は、内線電話のためにデータとは別の回線を用意するか、ま たは高価なTDMなどを導入する必要があったが、VoIPの技術を用いることで、データと音声 を同じ回線に通すことが可能になる。このモデルの特徴は、パケット交換ネットワークと端末と の間に、「VoIPゲートウェイ」を入れる点にある。GWは、公衆電話網とインターネットを相 互接続し、ユーザは通常の電話機を用いて、通常の電話機を持った相手と通話できる。

・ゲートウェイ

(14)

第 3章 VOIPの通信品質

図 3.1: VoIP

ゲートウェイはPBXから送られてきたダイヤル信号をInternet上のIPアドレスに変換する機 能と、音声信号を圧縮しIPパケット化して送信する機能を有している。

・スイッチングHUB

スイッチングHUBはゲートウェイから送られてくるパケットとデータ通信パケットを統合し、

ルータ経由でIP網へ送り出す機能を有する。

3.2 VoIP の特長

VoIPには既存の音声通話と比較して、以下のような特長がある。

3.2.1 通信コストの削減

音声とデータのネットワーク統合によって、電話網の回線・通信料が不要になり、通信コスト が削減できる。例えば、イントラネット/エクストラネットへ適用した場合には、既存のIP網 上で音声通話も可能になるため、複数の異なるネットワークを持つ必要がない。このため回線費 用や、ネットワークの維持・管理費用などのランニングコストを大幅に削減できる。また、一般 ユーザ向けのサービスとしても、通話料が極端に安いインターネット電話が実用されている。

3.2.2 データネットワークの親和性

VoIPは通信にIPネットワークを利用するため、音声データを他のデータ(文字、画像)など と等価に扱うことが可能である。このため、従来の音声通話とは異なる新しいサービスが期待さ

(15)

第 3章 VOIPの通信品質

れる。例えば、音声通話の内容のリアルタイムテキスト変換や、WWWと音声通話を融合させ たユーザーサポートなどである。

3.3 VoIP の課題

3.3.1 通信品質の問題

音声をIPパケット化する際や、IPネットワーク上へ送出する際の遅延やゆらぎにより品質の 劣化、また通信エラーなどによる常時安定した通信ができないという問題がある。IPネットワー ク上を文字データ、音声、静止画、動画等のデータが混在して通信されるため、その一つである 音声データについて通話が遅れることになる。これに対して、できるだけ通話が遅れたり揺らぎ がないように通話帯域を確保して品質を保証しなければならない。

3.3.2 SIPとは

VoIPを応用したインターネット電話などで用いられる、通話制御プロトコルの一つである。

1999年3月に発表された規格で、H.323など同様のプロトコルより後発のため、まだあまり普 及は進んでいない。転送機能や発信者番号通知機能など、同様のプロトコルと比べて公衆電話網 に近い機能を備え、接続にかかる時間も短くなっている。また、各端末に割り当てられるアドレ ス形式が電子メールアドレスの形式に近く、将来的には共通化も可能とされている。

3.3.3 標準化

VoIP は当初は、各社の独自規格による製品化が先行したため、相互接続性が失われていた。

それに対して1996年にITU-T(国際電気通信連合電気通信標準化部会)でH.323が承認され、

現在の標準の一つとなっている。H.323 には、ターミナル、ゲートウェイ、MCU(Multipoint

Control Unit) 、及び、それらを統括するゲートキーパと呼ばれるコンポーネントが規定されて

いる.しかしながら、現状ではH.323対応の機器同士でも完全な相互接続性が実行されていると は限らない。

3.4 通信品質低下の代表的原因

3.4.1 ジッタ

ジッタとは、パケットの到着時間のゆらぎのことである。等時性通信が前提の音声通信ではジッ タは大きな問題となる。音声を滞りなく再生するためには、受信時も送信時と全く同じタイミン

(16)

第 3章 VOIPの通信品質

グでパケットを受信側ノードに到着させるのが理想だからである。そのためVoIPシステムを構 築する際には、ジッタを極力小さくする工夫が必要である。

現在、End-to-Endの遅延は理想的には150ms以下、条件付きで400ms以下であることがITU- T (International Telecommunication Union Telecommunication sector:国際電気通信連合電気 通信標準化部門)から表3.1に示すようにG.114として勧告されている。

片道方向遅延 (ms) 説明

0〜 150 多くのアプリケーションで利用可能

送信時間がユーザーアプリケーションの送信品質に影響することを 150 〜 400 承知していれば利用可能

(ユーザーが承知している事が前提であり、推奨はできない)

400以上 一般的に利用不可能

表 3.1: ITU-T G.114の音声遅延ガイドライン ジッタの代表的な要因を次に挙げる。

音声圧縮 (CODEC) による遅延

音声圧縮 (CODEC)による起こる遅延の事で、アルゴリズム遅延と処理遅延から生じる。

アルゴリズム遅延とは、一定時間 (1フレーム)分の音声データを一括して圧縮するために 生じる遅延であり、その音声圧縮を利用する以上不可避なものである。一方、処理遅延と は、圧縮・伸張処理自体に要する時間である、具体的な実装方法次第でその時間を短くす ることが可能である。

パケット化による遅延

CODECによる圧縮された音声データは、RTP/UDP/IPヘッダを付加することでIPパケッ

ト化される。伝送レート低減の観点から、数フレーム分の音声データをまとめて一つのIP パケットとするのが通常の形式である、この際に生じる遅延がパケット化による遅延であ る。一つのパケットに組み込む音声データのフレーム数は、通話遅延の観点からは小さい ほうがよく、伝送レートの観点からは大きいほうが有利である。一概にどのサイズがよい とは言えず、ネットワークに最適化するのが好ましい。

ネットワークによる遅延

IPパケットがネットワーク上を通過する際に発生する遅延のことである。対策としてはネッ

(17)

第 3章 VOIPの通信品質

トワーク速度の他にも、一般的に通過するルータの数 (ホップ数)が少なくなるように、

ネットワークを構成することで、遅延を低減させる事ができる。

3.4.2 パケットロス

受話音声の音欠けにつながるのが、データ伝送中じ生じるパケットロスである。対策としては、

一般的に受話側で音欠けを補正する技術が使われている。音声信号は、数十ms程度の短い時間 間隔でみると定常的な信号として扱うことができる。この同じような波形が続く性質を利用し て、音欠け直前の受話音声から音欠けの部分を補完する事ができる。

(18)

第 4 章

上下トラヒックの非対称性

4.1 問題の背景

無線ネットワークの広い応用のために、QoS (Quality of Service)制御の要求が高まってい る。QoSはサービスの品質保証を意味し、対称性、安定性、通信のパフォーマンスなどの様々 な要素に着目しなければならない。

その中でも上下のフロー間の対称性は重要な要素である。今までに、対称性に関する研究は、

有線ネットワークを対象に数多く行われてきた。有線ネットワークにおいて、フロー間の対称性 が劣化する主な原因は、異なるトラヒックの混在である。例えば、ネットワーク上にUDPトラ ヒックとTCPトラヒックが混在する場合に、ボトルネットで輻輳が発生すると、TCPは輻輳 制御を行い転送レートを減少させるが、UDPは転送レートを変化させない。このような非対称 的な対応の結果、TCPトラヒックが激減することがある。有線ネットワークで生じる対称性の 問題の改善策として、バッファ・マネージメント、またはスケジューリングといったリンク層に 着目した方式が多く提案されている。

しかし、無線ネットワークにおける対称性の問題はMAC層にも大きく影響されるため、従来 の手法だけでは十分に解決することができない。

4.2 非対称性の問題

4.2.1 リンク層におけるフロー間の非対称性

無線ネットワークは、専用ルータや基地局などに依存しないネットワークである。直接通信が 行えない端末間の通信は、途中の無線端末の中継によって行われる。このように、他のフローに 中継サービスを与える無線端末のバッファは、複数のフローに共有される。したがって、中継端

(19)

第 4章 上下トラヒックの非対称性

末のバッファが各フローに非対称に割り当てられることが原因となり、フロー間の対称性が劣化 するという問題が生じる。このように発生するフロー間の非対称の問題は、従来のリンク層に着 目した方式で改善できると考えられる。

4.2.2 MAC層におけるフロー間の非対称性

無線ネットワークでは、複数の移動端末が無線チャンネルを共有するため、お互いにの通信範 囲に位置する無線端末が、同時にパケット送信を行うと衝突が起こり、通信が失敗する。そこで、

MAC層では、各端末に均等にチャネル割当を行うDCF (Distributed Coordination Function) チャネルアクセス方式が使用されている。しかし、複数のフローをもつ端末と、一本のフローし かもたない端末が、同一通信範囲に存在する場合、フロー間の対称性が劣化する。そのため、端 末に平等にチャネルを割り当てるだけでなく、フロー数に応じたチャネルアクセス方式が必要と される。

4.3 IEEE802.11e MAC プロトコル

IEEE802.11規格の無線LAN環境における上下フロー間の非対称はMACプロトコルの仕組

みに起因するものである。IEEE802.11eでは、無線媒体へのアクセスという意味では無線端末 が同等に扱われる。しかし、上下フローの種別を考えると、AP以外の送信端末は上りフロート ラヒックを送出しているのに対して、APは複数の無線端末宛の下りフローを多重化している。

従って、APに収容される下りフロー数が増加するにつれ、下りフロー1本あたりに確保できる 帯域は上りフローに比べて減少し上下フロー間で使用する帯域に非対称が生ずる。

図 4.1: IEEE802.11 MAC frame format

図 4.2: IEEE802.11e MAC frame format

(20)

第 4章 上下トラヒックの非対称性

IEEE802.11標準MACプロトコルでは、共有媒体である無線媒体へアクセスする方式として

DCF (Distributed Coordination Function)方式とPCF (Point Coordination Function)方式が 規定されている。

図 4.3: MAC Architecture

4.4 CW による改善

CWはContention Window (コンテンション・ウィンドウ)の略である。CWの値は可変で、

最小値CWminと最大値CWmaxの範囲の値をとる。CWの値は、フレームが衝突し再送を行

うたびに、2倍づつ増加していき、CWが上限値であるCWmaxに達した後は一定の値となる。

図 4.4: Exponential increase of CW

(21)

第 4章 上下トラヒックの非対称性

IEEE802.11ではCWの最小値CWminと最大値CWmaxを規定しており、初回送信における

バックオフCWminの値を用いて乱数値を算出し、再送のたびにこのCWを2倍の大きさにし てバックオフを行う。なお、CWmaxはCWの上限値である。このランダムを用いたバックオ フにより、複数の端末が同一チャンネルを共有して通信が可能となる。ただし、この方式は複数 の端末が同時にパケット送信を行う可能性があり、この場合にはパケット衝突が発生し、正しく パケットが受信されず、通信品質劣化に繋がる。

コンテンションウィンドウサイズはCWminとCWmaxの二つのパラメータで規定される。

フレームの送信が最初の場合はCWminをコンテンションウィンドウサイズとして使用する。誤 りなどで再送される場合にはこのコンテンションウィンドウサイズをCWminから増加させ、よ り広い範囲の値から待ち時間のスロット数を選択する。誤りが多いほど輻輳状態で、衝突が多い 状況である可能性が高いため、よりランダム性を増すことで衝突を回避できるようにするためで ある。何度か再送するたびにコンテンションウィンドウサイズは増加するが、その上限値を定め

るのがCWmaxになる。

EDCAではACごとの待ち時間はDIFSの代わりにAIFS (Arbitration Inter Frame Space)と 呼ばれるパラメータがセットされ、優先度が高いACほど小さく設定されている。同様にCWmin、

CWmaxも優先度が高いACほど小さく設定され、高優先度のACのパケットは優先的に送信で

きる確率が高くなっている。

(22)

第 5 章 実証実験

5.1 実験の環境

5.1.1 使用する機材

実験に使用した機材の一覧を表5.1に示す。

機種種別 ベンダー名 製品名 ノートパソコン DELL INSPIRON 300m

シミュレータ NTT ドコモ EDCAシミュレータ 表 5.1: 機材一覧

本実験で使用したコンピュータの仕様を表5.2に示す。

PC CPU メモリ

DELL Intel Pentium(R) M 1.2GHz 376MB 表 5.2: コンピュータの仕様

5.1.2 EDCAシミュレータ

EDCAシミュレータは、「IEEE802.11eのEDCAによる優先制御」が実装されたIEEE802.11b の無線LAN上でのVoIP及びTCPのシミュレーションを行うことができるツールである。

EDCAシミュレータのシミュレーションモデルは、図5.1のようになる。各端末(PC)はデー タ送信設定(シナリオ)をもとにデータを無線LANアクセスポイントまたはステーション(無線 LANカード)に送る。

(23)

第 5 章 実証実験

図 5.1: EDCA simulator model

アクセスポイント/ステーションはEDCAのアルゴリズムに基づき、無線空間が空いていた 場合に、データを無線空間に送信する。その際、同時送信等で無線空間でデータの衝突が発生し た場合は、アクセスポイント/ステーションにコリジョンが通知される。

正常にデータ送信が完了した場合に、送信先の端末(PC)までデータが届く。

5.1.3 EDCAシミュレータでできること

IEEE802.11b上でのUDPおよびTCPのデータ送受信

それぞれの無線LANアクセスポイント/ステーションでの設定

特定の時刻でのイベント発生

シミュレーション上での端末の設定

シミュレーションの出力結果の制御

5.2 実験

5.2.1 ネットワークの構成

本実験ではサーバ2台、端末2台、アクセスポイント (AP)1台によって、図5.2のように実験 ネットワーク環境を構築している。EDCAシミュレータというツールを用いて、受信した各ト ラヒックを測定する。

5.2.2 実験の手順

EDCAシミュレータを用いて双方向トラヒックを送信する。

1.下りフローの送出

TermD1からTermU1へVoIPトラヒック (Voice)を送出する。

(24)

第 5 章 実証実験

図 5.2: ネットワーク環境

TermD2からTermU2へVoIPトラヒック (Voice)を送出する。

2.上りフローの送出

TermU1からTermD1へVoIPトラヒック (Voice)を送出する。

TermU2からTermD2へVoIPトラヒック (Voice)を送出する。

3.実験パラメータ

トラヒック:上下フロー、一定値の512kbpsで送出する。10秒間隔でトラヒックを観察する。

無線アクセスポイントのデフォルト値の設定による、提案パラメータの有効性を確認する。

5.2.3 実験結果および図表

1.実験ではデフォルトパラメータと提案したパラメータを用いて双方向トラヒックを送信し た。図5.3に示すように、提案したパラメータの有効性を確認することができた。

2.提案パラメータを用いた場合と用いていない場合のスループットのデータは表5.3に示さ れている。

3.提案したEDCA設定可能なQoSパラメータは表5.4に示されている。

(25)

第 5 章 実証実験

図 5.3: 上下トラヒックのスループット

経過時間 (m) 提案値 (down)(kbps) 提案値 (up) デフォルト値 (down) デフォルト値 (up)

1 1,504.736 1,508.512 1,504.74 1,504.74

2 1,508.512 1,502.848 1,000.64 1,508.51

3 1,499.072 1,508.512 1,032.74 1,502.85

4 1,502.848 1,497.184 1,019.52 1,510.40

5 1,497.184 1,425.440 1,025.18 1,495.30

6 1,412.224 1,567.040 1,061.06 1,512.29

7 1,563.264 1,434.880 1,045.95 1,506.62

8 1,459.424 1,585.920 1,013.86 1,516.06

9 1,580.256 1,459.424 1,066.72 1,508.51

10 1,500.960 1,542.496 1,034.62 1,508.51

表 5.3: 実験データ

Access Category AIFS CWmin CWmax TXOP Limit

Voice 1 1 2 12032

表 5.4: 提案したパラメータ

(26)

第 5 章 実証実験

5.2.4 考察

デフォルトパラメータを用いた状態で、上下フロー間にスループットに関する不対称が生じる ことがわかった。それに対して、提案したパラメータを用いた状態で、下りフローのスループッ トが低下することが改善され、提案方式の有効性を確認した。

(27)

第 6 章 まとめ

6.1 結論

本研究では、IEEE802.11e無線ネットワークにおいて、双方向VoIPトラヒックを送信し、フ ロー間の対称性の改善方式を提案した。提案方式の有効性を確認するため、EDCAシミュレー タによる性能評価を行った。図表5.3と表5.4に示すように、アクセスポイントのコンテンショ ンウィンドウサイズを変化させることで802.11e無線LANの上下フロー間の対称性を改善でき ることを明らかにした。

6.2 今後の課題

本研究では、VoIPトラヒックのみの実験環境で、設定可能なQoSパラメータに対して、評価 実験を行った。

今後は、テレビ電話やTCPなどのトラヒックが混在する環境において、フロー数に応じた解 決方法を提案する予定である。

(28)

謝辞

本修士論文の作成にあたり日頃より御指導を頂いた早稲田大学理工学部の後藤滋樹教授および NTTドコモ サービス&ソリューション開発部の北原さんに深く感謝致します。最後に、多大な る御協力を頂きました後藤研究室の諸氏に感謝致します。

(29)

参考文献

[1] IEEE Standard, ”Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specification,” ANSI/IEEE Std 802.11 1999.

[2] Larry loeb: IEEE P802.11, The Working Group for Wireless LANs .

[3] Xiao Y: Enhanced DCF of IEEE 802.11e to support QoS , In Proceeding of IEEE Wireless Communications and Networking Conference, March 2003.

[4] Stefan Mangold,Sunghyun Choi,Peter May, Ole Klein,Guido Hiertz, Lothar Stibor:

IEEE 802.11e Wireless LAN for Quality of Service , ComNets RWTH Aachen Univ of Technology in Germany,Philips Research in USA, Philips Research in Germany.

[5] W.R.Stevens,井上尚司監訳『詳細TCP/IPプロトコル』ソフトバンク,1997.

[6] 夏目裕輔『IEEE802.11e 無線LANにおけるVoIPの品質評価』早稲田大学2005年度卒業 論文,2005.

[7] 佐々木洋美『DiffServeの環境におけるVoIPの品質評価』早稲田大学2002年度卒業論文,

2003.

[8] 竹下隆史, 村山公保, 荒井透, 苅田幸雄『マスタリングTCP/IP 入門編第2 版』オーム 社,1998.

[9] 松田崇弘,滝根哲哉『IEEE802.11無線LANにおける上下フロー間の公平性改善のための ウィンド制御法』大阪大学大学院工学研究科,2006.

[10] 足立桂一『無線LANにおけるストリーミングメディアの輻輳制御支援機構』早稲田大学 2004年度修士論文,2004.

[11] 山田浩之,森川博之,青山友紀『CSMA/CA型無線LANにおけるジッタ抑制手法』東京 大学大学院工学研究科.

(30)

参考文献

[12] 浜崎慎一郎『無線LANにおけるスループット低下の要因の分析』早稲田大学2003年度卒 業論文,2003.

(31)

付録 A

Config program A

本論文において使用したプログラムの設定ファイルを示す。

<?xml version=’’1.0’’ encoding=’’Windows-31J’’?>

<config>

<simulator>

<model name=’’EDCA Model’’ description=’’EDCA Simulation Model’’/>

<experiment name=’’EDCA Simulation Experiment’’ stop=’’10s’’>

<debug begin=’’0s’’ end=’’0s’’/>

</experiment>

</simulator>

<environment>

<access-point id=’’ap1’’ name=’’AP1’’ queue-capacity=’’200’’>

<category name=’’VO’’ cwmin=’’3’’ cwmax=’’7’’ aifsn=’’1’’ txop-limit=’’1504’’/>

<wireless-mode bandwidth=’’11Mbps’’ preamble=’’short’’ bit-error-rate=’’0.00 001’’/></access-point>

<udp-scenario id=’’udp1’’ category=’’VO’’ data-rate=’’512kbps’’ data-size=’’

160’’ add-rtp-header=’’true’’ distribution=’’constant’’/>

<terminal id=’’termD_1’’>

<access-point ref-id=’’ap1’’/>

<scenario ref-id=’’udp1’’ name=’’down’’ receiver=’’termU_1’’/>

</terminal>

<terminal id=’’termU_1’’>

<station id=’’st_1’’ name=’’STA_1’’ queue-capacity=’’200’’>

<category name=’’VO’’ cwmin=’’3’’ cwmax=’’7’’ aifsn=’’1’’ txop-limit=’’1504

’’/></station>

(32)

付録 A CONFIG PROGRAM A

<scenario ref-id=’’udp1’’ name=’’up’’ receiver=’’termD_1’’/>

</terminal>

<terminal id=’’termD_2’’>

<access-point ref-id=’’ap1’’/>

<scenario ref-id=’’udp1’’ name=’’down’’ receiver=’’termU_2’’/></terminal>

<terminal id=’’termU_2’’>

<station id=’’st_2’’ name=’’STA_2’’ queue-capacity=’’200’’>

<category name=’’VO’’ cwmin=’’3’’ cwmax=’’7’’ aifsn=’’1’’ txop-limit=’’1504

’’/></station>

<scenario ref-id=’’udp1’’ name=’’up’’ receiver=’’termD_2’’/>

</terminal>

<event>

<wireless-mode event-time=’’5s’’ station-ref-id=’’st_1’’ bandwidth=’’5.5 Mbps’’ preamble=’’short’’/>

<wireless-mode event-time=’’5s’’ station-ref-id=’’st_2’’ bandwidth=’’5.5 Mbps’’ preamble=’’short’’/>

<category event-time=’’5s’’ station-ref-id=’’st_1’’ name=’’VO’’ txop-limit

=’’12032’’/>

<category event-time=’’5s’’ station-ref-id=’’st_2’’ name=’’VO’’ txop-limit

=’’12032’’/>

</event>

</environment>

<output grouping-time=’’1000ms’’>

<html name=’’all’’ data-type=’’frame’’/>

<html name=’’up’’ scenario-includes=’’U.*’’ data-type=’’frame’’/>

<html name=’’down’’ scenario-includes=’’D.*’’ data-type=’’frame’’/>

<graph name=’’all’’ data-type=’’frame’’/>

<graph name=’’up’’ scenario-includes=’’U.*’’ data-type=’’frame’’/>

<graph name=’’down’’ scenario-includes=’’D.*’’ data-type=’’frame’’/>

</output>

</config>

(33)

付録 B

Config program B

本論文において使用したプログラムの設定ファイルを示す。

<?xml version=’’1.0’’ encoding=’’Windows-31J’’?>

<config>

<simulator>

<model name=’’EDCA Model’’ description=’’EDCA Simulation Model’’/>

<experiment name=’’EDCA Simulation Experiment’’ stop=’’10s’’>

<debug begin=’’0s’’ end=’’0s’’/>

</experiment>

</simulator>

<environment>

<access-point id=’’ap1’’ name=’’AP1’’ queue-capacity=’’200’’>

<category name=’’VO’’ cwmin=’’1’’ cwmax=’’2’’ aifsn=’’1’’ txop-limit=’’

12032’’/>

<wireless-mode bandwidth=’’11Mbps’’ preamble=’’short’’ bit-error-rate=’’

0.00001’’/></access-point>

<udp-scenario id=’’udp1’’ category=’’VO’’ data-rate=’’512kbps’’ data-size=’’

160’’ add-rtp-header=’’true’’ distribution=’’constant’’/>

<terminal id=’’termD_1’’>

<access-point ref-id=’’ap1’’/>

<scenario ref-id=’’udp1’’ name=’’down’’ receiver=’’termU_1’’/>

</terminal>

<terminal id=’’termU_1’’>

<station id=’’st_1’’ name=’’STA_1’’ queue-capacity=’’200’’>

<category name=’’VO’’ cwmin=’’1’’ cwmax=’’2’’ aifsn=’’1’’ txop-limit=’’

(34)

付録 B CONFIG PROGRAM B

12032’’/></station>

<scenario ref-id=’’udp1’’ name=’’up’’ receiver=’’termD_1’’/>

</terminal>

<terminal id=’’termD_2’’>

<access-point ref-id=’’ap1’’/>

<scenario ref-id=’’udp1’’ name=’’down’’ receiver=’’termU_2’’/>

</terminal>

<terminal id=’’termU_2’’>

<station id=’’st_2’’ name=’’STA_2’’ queue-capacity=’’200’’>

<category name=’’VO’’ cwmin=’’1’’ cwmax=’’2’’ aifsn=’’1’’ txop-limit=’’

12032’’/></station>

<scenario ref-id=’’udp1’’ name=’’up’’ receiver=’’termD_2’’/>

</terminal>

<event>

<wireless-mode event-time=’’5s’’ station-ref-id=’’st_1’’ bandwidth=’’

5.5Mbps’’ preamble=’’short’’/>

<wireless-mode event-time=’’5s’’ station-ref-id=’’st_2’’ bandwidth=’’

5.5Mbps’’ preamble=’’short’’/>

<category event-time=’’5s’’ station-ref-id=’’st_1’’ name=’’VO’’ txop-limit

=’’12032’’/>

<category event-time=’’5s’’ station-ref-id=’’st_2’’ name=’’VO’’ txop-limit

=’’12032’’/></event>

</environment>

<output grouping-time=’’1000ms’’>

<html name=’’all’’ data-type=’’frame’’/>

<html name=’’up’’ scenario-includes=’’U.*’’ data-type=’’frame’’/>

<html name=’’down’’ scenario-includes=’’D.*’’ data-type=’’frame’’/>

<graph name=’’all’’ data-type=’’frame’’/>

<graph name=’’up’’ scenario-includes=’’U.*’’ data-type=’’frame’’/>

<graph name=’’down’’ scenario-includes=’’D.*’’ data-type=’’frame’’/>

</output>

</config>

参照

関連したドキュメント

戦略的パートナーシップは、 Cardano のブロックチェーンテクノロジーを DISH のテレコムサービスに 導入することを目的としています。これにより、

キュリティ強化を前提に、加盟店におけるカード番号非保持化を徹底し、特

C =&gt;/ 法において式 %3;( のように閾値を設定し て原音付加を行ない,雑音抑圧音声を聞いてみたところ あまり音質の改善がなかった.図 ;

そのような発話を整合的に理解し、受け入れようとするなら、そこに何ら

 (4)以上の如き現状に鑑み,これらの関係 を明らかにする目的を以て,私は雌雄において

 TV会議やハンズフリー電話においては、音声のスピーカからマイク

テキストマイニング は,大量の構 造化されていないテキスト情報を様々な観点から

BC107 は、電源を入れて自動的に GPS 信号を受信します。GPS