図 1: 想定環境
近年，通信技術の発達にともない，さまざまな規格が制定されている． 例えば，802.11b，802.11a，Bluetooth，Ultra WideBand (UWB) などが挙げら れる．新たな通信規格が制定されるに従い，一つの計算機に複数のデバイスが 接続している状況が増えている．しかし，それら複数の通信デバイスを有効に 使っていないことが多い．例えば無線 LAN を利用している間は，PHS による データ通信サービスは利用しない．つまり，複数の通信デバイスを搭載してい る計算機があったとしても，片方を利用している間にもう片方のデバイスは利 用しないことが多く，資源が有効に活用されていない． 本稿では，これら計算機に接続された通信資源を有効に利用するため，それぞ れの通信デバイスを同時に利用し帯域を向上させる，ソケット層における帯域 統合機構 SBAM (Socket-level Bandwidth Aggregation Mechanism) を提案す る．
図 1 に示されるような想定環境において，帯域統合機構を実現する際に生じ る問題点について述べる．想定環境では，異なる無線ネットワークが同一地域 に存在し，そのネットワーク内をユーザは移動できる．ユーザは無線ネットワー クインタフェース (以下 N/I) が複数接続されているラップトップ PC や PDA などの計算機を利用しているとする．図 1 では Bluetooth と 802.11b が接 続されている．このような状態において，特にユーザ b のように，複数の無 線 N/I を利用できる状態を本研究では扱うこととする．
このような環境において，複数の N/I を利用して帯域統合を実現する場合， 以下に挙げる問題点が発生すると考えられる．
帯域統合機構を実現するネットワークスタックとしては，データリンク層，ネッ トワーク層，トランスポート層，アプリケーション層などが考えられるが，本 研究では OS の機能である ソケット層における実現手法を採った．以下，各 ネットワークスタックにおける利点・欠点を挙げ，ソケット層における実現手 法の優位性を示す．
帯域統合機構を実現するには，エンドノード間のネットワークの状態を把握し， その情報に応じて各 N/I からデータ送信を行なう必要がある．Hop-by-Hop で 処理されるプロトコルではエンドノード間のネットワーク状態を取得できない ので，ネットワーク層やデータリンク層における実現は現実的ではない．但し， 帯域や遅延などのリンク状態が，各 N/I において全く同一ならば，単純なラ ウンドロビンスケジューリングを用いることで帯域統合を実現でき，複雑な処 理が必要ないという利点が存在する．
新たなトランスポートプロトコルを実装した場合，3 つの欠点があげられる． 1) そのプロトコルを利用するために，既存アプリケーションを書換える必要 がある．2) 相手ホストでそのプロトコルを利用できない場合，通信は不可能 である．この場合，アプリケーションにおいて動的に利用プロトコルを切替え る必要がある．3) TCP を改良する場合，TCP の保持している帯域・遅延情報 を利用し，効率的に帯域統合機構を実現できるという利点が存在するが，TCP はインターネット上で広く利用されており，全てを新たなトランスポートプロ トコルに置き換えるのは現実的ではない．しかし置換を行なわなければ通信で きないホストが発生してしまう．
Hung-Yung Hsieh らによると，アプリケーション層において帯域 統合機構を実現した場合，N/I の数に対するスケーラビリティが低いという結 果が報告されている．また，既存のプログラムで帯域統合を実現する場合， そのプログラムに帯域統合機構を実装する必要がある．
ソケット層は OS の機能でありながら，ネットワークスタックではないので， ネットワークスタックにおける既存のプログラムの変更という欠点を回避しつ つ，アプリケーション層における欠点も回避できる．以下にソケット層におけ る利点を挙げる．
また，通信開始時に帯域統合機構は，通信先ホストにおいて同機構の有無を調 べるので，ネットワーク内に徐々に設置できる．
以上の理由により，SBAM では ソケット層における実現手法を採った．
各機能がどのように連係し動作するかについて述べる．図 2 にシステム構成 図を示す．
データ送信時にはまず，ポリシー伝達機能が MIB (Management Information Base) から情報を読みとり，その値を送信データスケジュール機能に渡す．次 に，ネットワークモニタリング機能が相手先ホストまでのネットワーク状態の 計測を開始し，その値を送信データスケジュール機能に渡す．計測は定期的に 行なわれ，値は適宜送信データスケジュール機能に渡される．送信データスケ ジュール機能では，利用可能 N/I を調査し，ポリシ伝達機能とネットワーク モニタリング機能から得た情報をもとに，各 N/I に対しどのようにデータを 配分するか決定し，その情報を送信データ分割機能に渡す．送信データ分割機 能では，渡された値をもとに送信データの配分を決定し，SBAM ヘッダを付加 した後，下位トランスポートレイヤにデータを渡し，データの送信を行なう．
受信時には，SBAM ヘッダを取り除き，パケット順の並べ替えを行なった後， データを統合しアプリケーションにデータを渡す．
本機能は，MIB を通してカーネル空間とユーザ空間の間でユーザポリシのやり とりを行う．ユーザポリシとは，ユーザの各 N/I に対する利用要求である． 2 節の 2 つ目の問題点で挙げた例のような場合に必要となる機 能である．
送信データスケジュール機能には，送信データ再スケジュール部と各 N/I の状態に応じたデータ送信部がある．本節ではそれぞれについて述べる．
何らかの理由で N/I が利用不可能になった場合，他の利用可能な N/I に送信データの再スケジュールを行う．また，利用可能な N/I の把握も行な う．例えば，ユーザが N/I をとりはずしたり，電波が届かなくなり通信を行 なえなくなった場合，送信データの再スケジュールを行なう．再スケジュール を行う際，図 2 のように，キュー内のデータを並べ替える．図 2 は N/I A と B が存在し，それぞれがキュー内にデータを保持していることを示してい る．このような状況で N/I B が利用不可能になったとする．この場合，N/I B のキュー内の送信データは図のように，N/I A のキュー内で並べ変えられ送信 される．このことにより，送信先ホストにおけるデータの並べ替え作業の軽減 を行う．
後述のネットワーク状態モニタリング機能より，各リンクの帯域・遅 延情報を受けとり，MTU (Maximum Transfer Unit) を考慮しつつデータ配分量 を決定する．まず，通信開始時には，各リンク間の帯域遅延積差をなくすため， 帯域遅延積が最小のリンク以外に対し，式 1 中の Pn で表されるパケット数 を送信する．dn は遅延，bn は帯域，mn は MTU をそれぞれ表す．また，αn は，ポリシー伝達機能によって指定された各 N/I の重みを表す．
この操作により，各リンク間の帯域遅延積の量が一定になる．次に，各リ ンクの帯域に比例したデータ量を送信する．データ量に比例したパケット数を N/I に対して割り当てるため，パケット数は式 2 中の Pn で表されるパケット数を送信する．
例えば，帯域が 2Mbps，MTU が 500 バイト，遅延が 100ms のリンク A と， 帯域が 1Mbps，MTU が 1000 バイト，遅延が 50ms のリンク B が存在したと する．この場合，通信開始時はリンク A に対して，式 1 より，2000000(bps)・ 0.1(sec) - 1000000(bps) ・ 0.05) / (500 ・ 8) = 37.5 = 38 パケット送信 する．次に，各リンクに対する送信パケット数は，式 2 より，リンク A に対 して2000000・1000) / (500・1000000) = 4 パケット，リンク B に対して同 様に，1 パケットとなる．このことにより，それぞれのリンクのパイプを埋め， 効率的に各リンクを利用できる．
本機能は前項で述べた送信データ分割機能と送信データスケジュール機能のた めに送信先ホストまでのネットワークの状態をモニターする．具体的には，通信 相手までの遅延，帯域，パケットロス率を取得する． 遅延データは，式 3 で表される TCP で利用されている遅延の平 滑化手法を利用し保持する．SRTT は平滑化された Round Trip Time (RTT) を表し，RTT は計測された RTT を表す．αは平滑化係数であり， TCP における推奨値は 0.9 となっている．
帯域情報の取得には，packet pair 方式 を利用する．この方式ではまず，2 つの同じ大きさのパケットを同時に送信先 ホストへ送信する．そしてこの 2 つのパケットの ack の到着時間の差より， 送信先ホストまでの帯域を測定する．
また，本機能は帯域統合機構が動作するホスト内において，一つだけ動作する 機能である．送信データスケジュール機能はアプリケーション毎に動作する必 要があるが，本機能はホスト内において統一的にネットワーク状態をモニター し，効率的にその情報を他の機能に渡す．
送信データを分割し，適切なポリシーに従ってトランスポート層に渡すための 機能である．適切なポリシーとは，後述のネットワーク状態モニタリング機能 から得られる遅延情報やパケットロス率や帯域情報，そして，ポリシー伝達機 能から得られるユーザポリシーなどから決定する．また，受信データ統合機能 においてデータの再構築を行なうための SBAM ヘッダの追加も行なう．
本機能は，分割されて送られてきたデータを統合する機能である．後述のSBAM ヘッダを読みとり，パケットの並べ換えを行ない，受信データをアプリケーショ ンに渡す．
パケットの再構築をどのように行なうかは，下位レイヤーで利用されている トランスポートプロトコルによって 2 つに分けられる．TCP やSTP のように 信頼性が求められるプロトコルが利用されている場合は，ヘッダ情報を利用し て正確にデータを再構築する．これに対し UDP のような信頼性は必要とされ ていないが高速なネットワーク転送と少ない遅延が求められるプロトコルが利 用されている場合は，パケットの並べ換えよりもアプリケーションに対してデー タを早く渡すことを優先する．
本節では SBAM のプロトタイプ実装について述べる．今回の実装では，送信デー タ分割機能と受信データ統合機能を実装した．また，利用するトランスポート プロトコルは UDP とした．
| マシン | ThinkPad X30,ThinkPad T30 |
| OS | FreeBSD 5.1-Release |
| NIC | BUFFALO WLI-PCM-L11, Intersil Prism2.5 |
SBAM では，図 4 のようなヘッダをパケットに付与する． シーケンス番号は，ソケット層でデータの順序を入れ換えるために存在する． データ長は，そのパケットが SBAM 対応のパケットなのかを確認するためと， その場合，ペイロード部分がどれくらいの長さなのかを把握するために存在する．
本小節では，送信と受信の時の処理の流れを示す．図 5 に，送受信時にカーネル内でどのような関数が呼び出されるかを示す．
通常のデータ送信の場合，FreeBSD の実装では，sosend 関数内で利用するト ランスポートプロトコルに応じた関数を protosw inet 構造体を利用し呼び出 す．sosend は下位トランスポートプロトコルが必要とする形に従い，send シ ステムコールや write システムコールの情報を渡す関数である．下位トラン スポートプロトコルは TCP/IP プロトコルスタックの場合，protosw inet 構 造体に関数ポインタの形で登録されている．SBAM では UDP プロトコルスタッ クを呼び出す前に，sbam_send という SBAM の処理を行なう関数を呼びだし， udp_send 関数を呼んでいる．sbam_send は 2 節で述 べた送信データ分割機能と送信データスケジュール機能にあたる．
通常，受信したデータは，ip_input，udp_input 関数で処理されソケット バッファにためられる．そして sowakeup 関数により，プロセスはそのデー タを読み出す．SBAM では，sowakeup 関数内より input 関数を呼び出し， SBAM ヘッダの処理を行なう．input 関数が 2 節で述 べた受信データ統合機能にあたる．
SBAM のプロトタイプ実装を，図 6 に示すネットワーク環境で評価した．実際 のネットワーク構成は，図 6 の Network 1 と Network 2 を ルータに接続し， そこから Network 3 へ接続している．無線デバイスは 802.11b を 2 枚利用 し，それぞれ 2チャネルと 11チャネルの帯域を利用した．また，今回はネッ トワーク状態モニタリング機能を実装していないので，コントロールパケット はネットワーク上に送信していない．トランスポートプロトコルは，UDP を利 用した．
今回は，SBAM と評価用アプリケーション実装におけるスループットと，スケ ジューリング機能の有無によるスループット，そして受信ホストにおける到着 パケットシーケンスを評価項目とした．
アプリケーション層における評価用実装 (APP1) と SBAM を用いてスループッ トの評価・比較を行なった．APP1 は1 パケット毎に Network 1 とNetwork 2 に対し交互にデータを送信した．また比較のため，UDP データを送信するだけ のアプリケーション (APP2) を用いて，N/I を 11Mbps モードで動作させた場 合と 5.5Mbps モードで動作させた場合のスループットの計測も行なった．ス ループットは 5.5MB のメディアデータを 50 回送信し，その計測結果の平均 をとった．結果を表 2 に示す．
| N/I | 実装 | スループット |
| 11Mbps + 11Mbps | SBAM | 15.0 Mbps |
| 11Mbps + 11Mbps | APP1 | 15.4 Mbps |
| 11Mbps | APP2 | 9.2 Mbps |
| 5.5Mbps | APP2 | 6.1 Mbps |
11Mbps の N/I を 1 枚利用した場合と比べ，11Mbps の N/I を 2 枚利用した APP1 も SBAM も約 1.6 倍程度スループットが向上していることが分かる． APP1 と SBAM を比較すると，SBAM のスループットは APP1 に対して$97.4\%$ となっていることが分かる．SBAM では APP1 と比べて，利用可能インタフェー スや現在のネットワークトポロジのチェック，ヘッダの付与を行なっているの で，APP1 よりも処理が多くなっている．このオーバヘッドの原因を調べるた めに，N/I を 2 枚利用した場合の sbam_send 関数と，N/I が 1 枚の場合の sbam_send 関数，そして，rtalloc 関数の実行時間を計測した．N/I が 1 枚 の場合，sbam_send 関数はリンクアップしている N/I の数を調べるために線 形探索を 1 度行ない，udp_send 関数を呼び出す．rtalloc 関数とは，ルー ティングテーブルを検索するための関数であり，sbam_send 関数の中で 2 回 呼び出されている．計測は 1400 バイトのパケットを 50 個送信し，1 パケッ ト毎に sbam_send 関数と rtalloc 関数の実行時間を計測した．その平均結 果を表 3 に示す．N/I が 2 枚の場合，sbam_send 関 数は N/I が 1 枚の場合と比べ 47.75 倍のオーバヘッドが存在することが分 かる．また，N/I が 2 枚の場合のオーバヘッドの内，30.2% が rtalloc 関数のオーバヘッドとなっている．よって，SBAM 機構に特化した rtalloc 関 数の代替を考案することで，スループット改善の余地があると考えられる．
| N/I 2 枚時の sbam_send() | 0.15 μs |
| N/I 1 枚時の sbam_send() | 1.06 μs |
| rtalloc() | 7.02 μs |
実装内容について比較すると，APP2 では raw socket の利用，指定されたデ フォルトゲートウェイへの変更，UDP データグラムの送信をアプリケーション において全て実装しなければならず，C 言語で実装したプログラムの行数は 666 行に達した．しかし SBAM では既存のソケットプログラミングによる UDP 送信手法で同等の機能を実現でき，プログラムの行数は 206 行であった．こ のことから，アプリケーション層における実装と比べて同等の機能を実現する のが容易であることが分かる．
スケジューリング機能を持たない APP1 と，式 1，2 に基づい たスケジューリング機能を実装した評価用アプリケーション (APP3) を用いて スループットの比較を行なった．APP3 に必要な帯域と遅延情報はあらかじめ 計測した値を利用し，MTU は 1500 バイトで統一した．また，N/I の重み αも 1 で統一した．結果を表 4 に示す．
| N/I | 実装 | スループット | |
| 11Mbps + 5.5Mbps | APP1 | 9.6 Mbps | |
| 11Mbps + 5.5Mbps | APP3 | 11.7 Mbps |
各リンクの帯域が異なる場合，スケジューリング機能のない APP1 は，11Mbps と 5.5Mbps の N/I のスループットの和と比べて，62.7% のスループット となっている．これに対し，帯域に比例したデータ送信を行なう APP3 では， 同様に 76.5% のスループットとなっている．このことから，リンクの帯域 に応じたデータ送信を行なうことで，各リンクの帯域を効率的に利用できるこ とが分かった．
ネットワーク環境の変化による到着パケットシーケンス番号のずれについての 実験を行なった．表 5 に今回行なった実験環境を示す．NIC1, NIC2 はそれぞ れ図 6 に対応している．
| NIC1 | & NIC2 | |
| 環境 1 | 11Mbps, 遅延 0ms． | & 11Mbps, 遅延 0ms |
| 環境 2 | 11Mbps, 遅延 50ms | & 11Mbps, 遅延 50ms |
| 環境 3 | 11Mbps, 遅延 0ms | & 5.5Mbps, 遅延 0ms |
遅延は Dummynet を Network 1 のリンク上に設置し，発生 させた．各実験とも，5.5MB のメディアデータを各 N/I に対しラウンドロビ ンで送信した．UDP パケットには，送信元ホスト上で，それぞれの NIC にお いて通し番号となるような 4 バイトのシーケンス番号を付与した．パケット 到着時間を送信先ホスト上において，Pentium Counter を利用して計測した． それぞれの環境における実験結果を図 7 〜 9 に示す．各図の縦軸は，送信元 ホストで付与されたパケットシーケンス番号を表し，横軸は送信開始からの経 過時間を示す．
図 7 より，2 枚の N/I に大きな帯域差がなく， 遅延もないネットワークにおいて，データ送信後 1 秒以降，パケットシーケ ンス番号のずれが目立ちはじめていることが分かる．データ送信開始後 1 秒 まではパケットシーケンス番号のずれはほとんど見られない．データ送信開始 後 1.7 秒の時点で，100 パケット程度のずれが見られるようになる．しかし， 遅延が 50ms ある環境では，送信当初よりパケットシーケンス番号のずれが見 られ，データ送信開始後 1.5 秒には 100 パケット程度のずれが生じているこ とが図 8 より分かる．また，NIC 1 の帯域 を 11Mbps，NIC 2 の帯域を 5.5Mbps とした実験では，データ送信開始後 0.5 秒後には，100 パケット程度のずれが生じていることが図 9 より分かる．
これらの実験より，送信元/送信先ホスト間の帯域と遅延がパケットの到着順 に影響を与えることが判明した．受信した通りのパケット順のままデータをア プリケーションに渡した場合，データを全く再構築できないという問題が発生 する．例えば映像ストリーミングを行なっている場合，パケットロスが起きた ら，そのパケットを含むフレームを破棄するだけで良いが，結果のように到着 パケットシーケンスがずれた場合，フレームを全く構成できない．本稿の結果 より，今回実装されていない送信データスケジュール機能では，送信元/送信 先ホスト間の帯域・遅延を考慮したデータ送信スケジュールを行なわなければ ならないことが分かる．ソケット層においてパケット順を入れ換える受信デー タ統合機能のみでは，TCP のような遅延の値を利用するトランスポートプロト コルの性能に悪影響を与えてしまうことが想定される．また，帯域と遅延情報 を取得するためのネットワークモニタリング機能の実装も必要であることが分 かる．
本論文では ソケット層における帯域統合機構である SBAM を提案し，プロ トタイプ実装を用いて評価を行った．SBAM は ソケット層において，送信データ スケジュール機能，ポリシー伝達機能，送信データ分割機能，ネットワーク状 態モニタリング機能，受信データ統合機能を持ち，複数 N/I の帯域を利用す ることができる．本論文では SBAM の設計・実装を述べ，実際に SBAM を用い て複数 N/I を利用しデータ送信を行なった． 評価実験では SBAM を用い，802.11b の N/I を 2 枚利用し，UDP のスルー プットをアプリケーション実装と比較した．また，送信先ホストにおける到着 パケットシーケンスについて評価を行なった． ソケット層で実装されている SBAM とアプリケーション層での実装では，約 2.6% のスループットの差があることが分かった．しかし，ソケット層で実現 しているので同等の機能を持つプログラムを容易に実装できることも分かった． 到着パケットシーケンスに関して，11Mbps と 5.5Mbps のリンクよりデータを 分割して送信した場合，送信開始後 1.5s の時点で 8% のずれが生じる ことと，相手先ホストまでの各 N/I 間の遅延の差が 50ms の場合，送信開 始後 1.5s の時点で約 8% ずれることを観測した．