JP5027886B2 - 中間のホップにおいてトラフィック形成を考慮して、マルチホップ８０２．１１ネットワークにおけるアドミッション及び経路指定を管理するための方法及び装置 - Google Patents

中間のホップにおいてトラフィック形成を考慮して、マルチホップ８０２．１１ネットワークにおけるアドミッション及び経路指定を管理するための方法及び装置 Download PDF

Info

Publication number
JP5027886B2
JP5027886B2 JP2009541626A JP2009541626A JP5027886B2 JP 5027886 B2 JP5027886 B2 JP 5027886B2 JP 2009541626 A JP2009541626 A JP 2009541626A JP 2009541626 A JP2009541626 A JP 2009541626A JP 5027886 B2 JP5027886 B2 JP 5027886B2
Authority
JP
Japan
Prior art keywords
packet
hop
channel
voice
network
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
JP2009541626A
Other languages
English (en)
Other versions
JP2010514275A (ja
JP2010514275A5 (ja
Inventor
ショーン， エー． ランプラシャッド，
ダンジュー リ，
ウラス シー． コザット，
クリスティーン ペピン，
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
NTT Docomo Inc
Original Assignee
NTT Docomo Inc
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by NTT Docomo Inc filed Critical NTT Docomo Inc
Publication of JP2010514275A publication Critical patent/JP2010514275A/ja
Publication of JP2010514275A5 publication Critical patent/JP2010514275A5/ja
Application granted granted Critical
Publication of JP5027886B2 publication Critical patent/JP5027886B2/ja
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/50—Network service management, e.g. ensuring proper service fulfilment according to agreements
    • H04L41/5003—Managing SLA; Interaction between SLA and QoS
    • H04L41/5019—Ensuring fulfilment of SLA
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/08—Configuration management of networks or network elements
    • H04L41/0893—Assignment of logical groups to network elements
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/60—Scheduling or organising the servicing of application requests, e.g. requests for application data transmissions using the analysis and optimisation of the required network resources
    • H04L67/61—Scheduling or organising the servicing of application requests, e.g. requests for application data transmissions using the analysis and optimisation of the required network resources taking into account QoS or priority requirements
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/08—Configuration management of networks or network elements
    • H04L41/0894—Policy-based network configuration management
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00—Arrangements for monitoring or testing data switching networks
    • H04L43/08—Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters
    • H04L43/0852—Delays
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W28/00—Network traffic management; Network resource management
    • H04W28/16—Central resource management; Negotiation of resources or communication parameters, e.g. negotiating bandwidth or QoS [Quality of Service]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W40/00—Communication routing or communication path finding
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W84/00—Network topologies
    • H04W84/02—Hierarchically pre-organised networks, e.g. paging networks, cellular networks, WLAN [Wireless Local Area Network] or WLL [Wireless Local Loop]
    • H04W84/10—Small scale networks; Flat hierarchical networks
    • H04W84/12—WLAN [Wireless Local Area Networks]

Description

関連出願の相互参照
本出願は、（ａ）２００６年１２月１４日に出願の米国仮特許出願第６０／８７５２６９号、及び（ｂ）２００７年１２月１３日に出願の米国特許出願第１１／９５６１４１号に関し、またその優先権を主張するものであり、それらを共に参照により本明細書に組み込む。米国指定に対しては、本出願は前述の米国特許出願第１１／９５６１４１号の継続出願である。
発明の背景
１．発明の分野
本発明は、一般に、マルチホップネットワークを介するデータトラフィックに関する。より詳細には、本発明は、各ホップでトラフィック形成サービス及びレート適応サービスを提供するマルチホップ８０２．１１ベースのネットワーク（又は同様のネットワーク）を介して送信されるデータストリームのアドミッション及び経路指定を管理することに関する。
２．関連技術の検討
アドミッションを制御し、且つ経路指定の決定を行うための機構は、効率的なネットワーク管理のために望ましいツールである。８０２．１１ネットワークでは、このような機構は、新しいユーザごとに、どのアクセスポイントに関連付けるべきか、またそのユーザと関連付けられたトラフィック及びパケットは、そのそれぞれの宛先に到達するためには、複数の可能な経路中で、どの経路をたどるべきかを決定する。このような機構は、少なくとも部分的に、資源の可用性（例えば、帯域及びアクセスポイントの数）、及びユーザのサービス品質（ＱｏＳ）要件（例えば、送信レート、スループット、遅延、及び信号対雑音比）により駆動され得る。新しいユーザは、必要な資源が利用可能ではない場合、又は新しいユーザが許可される場合であっても（新しいユーザ及び既存のユーザの両方に対する）ユーザのＱｏＳ要件が満たされることのない場合、アドミッションが拒否される可能性がある。対話的な音声通信アプリケーション（例えば、「ボイスオーバーＩＰ」すなわち「ＶｏＩＰ」）については、資源及びＱｏＳ要件は、送信スループット、遅延、及びパケット損失を含むことができる。したがって、望ましいアドミッション制御ポリシーは、ネットワークが、ＱｏＳ制約又はシステムの制限に違反することなく、所与の数のユーザをサポートできることである。マルチホップネットワークでは、アドミッション制御ポリシーはまた、障害を阻止すべきであり、したがって、サポートできるユーザ数を制限するように働く。
いくつかのアドミッション制御アルゴリズムが、シングルホップ無線ネットワークに対して提案されてきた。例えば、ＩＥＥＥ Ｇｌｏｂｅｃｏｍ ２００１の会報で公開された、Ｚ．Ｊｉａｎｇ、Ｌ．Ｃｈａｎｇ、及びＮ．Ｋ．Ｓｈａｎｋａｒａｎａｒａｙａｎａｎによる論文「Channel quality dependent scheduling for flexible wireless resourcecontrol」は、スループットだけを最適化する方法を開示する。ＡＣＭ ＭｏｂｉＣｏｍ２００１の会報で公開された、Ｖ．Ｋａｎｏｄｉａ、Ｃ．Ｌｉ、Ａ．Ｓａｂｈａｒｗａｌ、Ｂ．Ｓａｄｅｇｈｉ、及びＥ．Ｋｎｉｇｈｔｌｙによる論文「Distributed multi-hop scheduling and medium access with delay andthroughput constraints in mind」は、スループット及び遅延を共に最適化する方法を開示する。８０２．１１ベースのマルチホップネットワークに対しては、２００６年４月、米国ネバダ州ラスベガスにおけるＩＥＥＥ ＷＣＮＣ ２００６の会報で公開された、Ｓ．Ｌｅｅ、Ｇ．Ｎａｒｌｉｋａｒ、Ｍ．Ｐａｌ、Ｇ．Ｗｉｌｆｏｎｇ、及びＬ．Ｚｈａｎｇによる論文「Admission control for multihop wireless backhaul networks with QoSsupport」（「ＬＮＰＷＺ０６」）は、遅延及び接続レートにおいて、各ユーザのＱｏＳ要件を満たす方法を開示する。
他のアドミッション制御アルゴリズムは、マルチホップネットワークのシナリオにおけるアクセスポイントで、音声パケットの集約など、他の選択肢を考慮する。音声パケットの集約は、例えば、２００６年４月３〜７日のＷｉＯｐｔ ２００６の会報で公開された、Ｃ．Ｐｅｐｉｎ、Ｕ．Ｋｏｚａｔ、及びＳ．Ａ．Ｒａｍｐｒａｓｈａｄによる論文「A Joint Traffic Shaping and Routing Approach to Improve thePerformance of 802.11 Mesh Networks」（「ＷｉＯｐｔ０６」）で、またＳ．Ｒａｍｐｒａｓｈａｄ、Ｃ．Ｐｅｐｉｎ、及びＵ．Ｋｏｚａｔによる米国特許出願「Method for Improving Capacity in Multi-Hop Wireless Mesh Networks」（「ＮＰＡ０６」）、第１１／５３１３８４号で開示される。
ユーザがネットワーク中に許可された後、システムの経路指定スキームは、ユーザのデータパケットのその宛先への適正な経路指定を決定する。マルチホップ無線ネットワークにおける経路指定は、文献中で広範囲に論じられてきている。初期の無線経路指定プロトコル（例えば、ＡＯＤＶ、ＤＳＲ、ＤＳＤＰ、及びＴＯＲＡなど）では、経路指定は、低位レイヤとは独立して処理され、経路探索が、システム性能又はＱｏＳにかかわらず、ベストエフォート的に実施される。このような経路指定アルゴリズムは、主として、ＭＡＮＥＴ（モバイルアドホックネットワーク）に対して意図されており、その場合、接続経路を見出すことが優先権を有する（例えば、http://www.ietf.org/html.charters/manet-charter.htmlを参照のこと）。
このような方法は、低位レイヤにおける重要な問題を直接考慮していないことに留意することが重要である。具体的には、ネットワークが、８０２．１１ネットワークの場合がそうであるが、低位の通信レイヤで、パケットの処理及び送信において高いオーバーヘッドが存在するような場合、このようなオーバーヘッド及び低位レイヤを考慮しない経路指定プロトコルは、システム性能を悪くする可能性がある。
経路探索においてＱｏＳを考慮することは、例えば、２００３年９月、米国カリフォルニア州サンディエゴにおけるＡＣＭ Ｍｏｂｉｃｏｍ ２００３の会報、Ｄ．Ｓ．Ｊ．Ｄｅ Ｃｏｕｔｏ、Ｄ．Ａｇｕａｙｏ、Ｊ．Ｂｉｃｋｅｔ、及びＲ．Ｍｏｒｒｉｓによる論文「A high-throughput path metric for multi-hop wireless routing」で論じられている。その論文は、成功裡にパケットを送達するのに必要な送信及び再送信の予測される合計数を最小にする方法を論じている。リンク損失比の影響、各リンクの双方向の損失比における非対称性、及び経路の連続するリンク中の干渉を組み込む新しいメトリックが考案されている。そのメトリックは、ＤＳＤＶ及びＤＳＲ経路指定プロトコルで実施され、２つ以上のホップを有する経路に対して特に、最小のホップ回数メトリックよりもよい性能を提供することが示されている。
従来技術は、ユーザのＱｏＳ要件を満たすために、パケットの経路指定及びスケジューリングをジョイントさせて行う複雑な手法を含む。このような手法は、問題が複雑であるために有効ではない可能性がある。例えば、マルチホップ無線ネットワークで必要な接続レートを満たすために、ジョイントされたスケジューリング及び経路指定問題を解決することは、知られたＮＰ完全問題である。例えば、上記で論じた論文ＬＮＰＷＺ０６を参照のこと。従来技術の手法はまた、各ユーザに対して独立に、一度に１つ又は２つのパラメータ（例えば、スループット及び遅延）だけに対して焦点を当てているため有効ではない。したがって、概して、得られた結果は、ユーザ又はアクセスポイントの増加に伴って容易に拡張することができない。実際に、新しいユーザがネットワークに参加すると、このような手法では、障害を生成する可能性さえある。
このような一般的な手法を超えて、システム中に受け入れられるアプリケーションをより注意深く検討する必要があり、そのようにすることにより、性能を向上させ、最適化問題を簡単化することができる。例えば、音声アプリケーション（例えば、ＶｏＩＰアプリケーション）、又は一般に、小さなパケットサイズのデータを永続的に生成する媒体アプリケーションに対しては、「ＷｉＯｐｔ０６」及び「ＮＰＡ０６」で示されるように、中間ホップでトラフィック形成を用いて、多くの利益を達成することができる。このようなシナリオでは、ＭＡＣ（媒体アクセス制御）及びＰＨＹ（物理）レイヤなどの低位レイヤにおける重要な問題を直接考慮することができる。具体的には、各ホップで集約及びバースト送りレベルなどの低位レイヤ機構を注意深く選択することにより、音声又は同様なトラフィックに対する８０２．１１プロトコル下の固有の非効率性を低減することができる。これを用いると、このようなシステムによってサポートされ得るＶｏＩＰコールの数を実質的に増加させることができる。このようなシナリオにおけるアドミッション及び経路指定制御は、このような低位レイヤ機構を考慮に入れるべきである。
概要
本発明の一実施形態によれば、方法及び装置は、マルチホップ８０２．１１ネットワークを介するデータストリームのアドミッションを制御する。アドミッション制御方法は、特に、トラフィック形成（例えば、集約及びバースト送り）、及び複数の無線リンク若しくはホップを介してパケットを経路指定し若しくは転送することなど、複数の機構のジョイント効果を考慮する。アドミッションの決定は、システムの集約及びバースト送り機能の両方に、したがって、ＭＡＣ及びＰＨＹレイヤの挙動に影響を与えるために、これらのＭＡＣ／ＰＨＹレイヤファクタは、アドミッション制御で直接検討される。さらなる検討は、各ホップにおける物理的な送信レートをチャネル条件（例えば、信号対雑音比）に適応させることなど、システム中ですでに使用されている既存の機構に対するものも含むことができる。
本発明の一実施形態によれば、方法は、ノード（すなわち、アクセスポイント、ゲートウェイアクセスポイント、端末）及びシステムを、通信グループの集合体として見る。通信グループは、共通の無線資源を求めて競合する８０２．１１ノードから生成された１組のフローである。例えば、フロー（リンク）が、そのグループのメンバーシップを示す数「ｎ」でラベル付けされた図２及び３に示すものを参照のこと。さらに、このようなグループは、共通の無線資源を求めてそれ自体の中で競合するようなノード上で提供されるインターフェース（ＭＡＣ及び関連するＰＨＹ）であると見なすこともできる。その機構は、結果として得られたシステム中の異なる通信グループの状態の変更により、実現可能な（すなわち、安定した）システム、及び望ましい性能属性（例えば、システムによりサポートできるユーザ数を最大化する）の両方を達成するような方法で、ネットワーク中にユーザを許可する（すなわち、ユーザに対して適切なアクセスポイント（ＡＰ）を選択し、且つゲートウェイアクセスポイント（ＧＡＰ）への経路を選択する）。ここで、通信グループの「状態（state）」は、グループの各ノードがトラフィックを送信するために使用することになる集約又はバースト送りレベルなど、低位レイヤ機構の暗黙的な、又は指示された状態を含む。
本発明の一実施形態によれば、新しいユーザがシステムに入る場合、新しいユーザによりアソシエーションのためのアクセスポイントが選択される。それは、ユーザの端末がマルチホップネットワーク中に通信するためのアクセスポイントとなる。さらに、そのアクセスポイントからＧＡＰへの経路が割り当てられる。いくつかの例では、簡単なネットワークトポロジであるため、その経路はアドミッションされると暗黙的に割り当てられ得る。他の例では、システムは、アドミッション決定に基づいて、いくつかの可能な経路を検討することができる。他の状況では、それ自体がＧＡＰであるアクセスポイントにユーザ端末が接続され、したがって、経路を必要としないこともあり得る。本発明の下で正しく管理される場合、アドミッション（及び関連するパラメータ設定）は、望ましい性能レベル（例えば、最大化された効率）を達成するシステムパラメータ値へと導く。
さらに、本発明の一態様によれば、本発明の方法は、低位レイヤから独立した決定として、アドミッション及び経路を考慮するだけではなく、アクセスポイント間でパケットを転送するために使用される低位レイヤのトラフィック形成機構を直接考慮する。それは、システムの各ノードによって使用されるトラフィック形成機構で暗黙的な変化を実現することにより、又はシステムの各ノードによってトラフィック形成機構を直接変更することにより行われる。暗黙的に指示される変更は、例えば、それを介して経路指定される新しいフローに対するアクセスポイントの知られた確定的な（又は平均の）リアクションを引き出すことを含むはずである。アドミッション及び経路指定の決定は、どのアクセスポイントがさらなるトラフィックを受信するかを定義し、したがって、リアクションを予測することができる。例えば、システムは、可能な場合、各フローから到来する１つのパケットを、共通の次のホップパケットへと集約し、パケットをバースト送信で送り、或いはフローが同じ次のホップのアクセスポイント宛先を有する場合、その両方を実施するルールを行うアクセスポイントを有することができる。指示された変更は、共通の送信で集約し且つバーストするために、到来するフローを各ノードがどのように処理すべきかを指定する。
両方の場合（すなわち、暗黙的な変更及び指示された変更）では、アドミッション及び経路指定の決定は、各通信グループにおける状態変数の変更を暗に示す。通信グループと関連する状態変数は、例えば、集約レベル（例えば、より大きなパケットへと共に多重化され得るパケット数）、バースト送りレベル（すなわち、送信バーストで送信できるパケット数）、及び競合下にある共通の物理媒体にアクセスするノードによって使用される物理レイヤ（ＰＨＹ）送信レートを含むことができる。
本発明の１つの利点は、各通信グループに対する望ましいトラフィック形成パラメータは、新しい各ユーザに対して、最良のアドミッション及び経路指定戦略が決定されるのと同時に決定されることである。
本発明は、マルチホップ８０２．１１ネットワークを介して、例えば、音声送信などのトラフィックのためのアドミッション制御方法を提供するために、ジョイントさせてそのように行う。本方法は、決定を行い、且つシステムが安定した状態であることを保証するために、複数のパラメータを考慮する。そのパラメータは、選択肢（例えば、集約レベル、バースト送りレベル、及び送信レート）、及び制約（例えば、ユーザ数、アクセスポイント、又は各ユーザの感知範囲）を含むことができる。本方法は、可能性のあるアドミッション及び経路指定の決定により決定された、選択肢及び制約の各組が与えられたネットワークにおける通信グループのそれぞれの負荷を計算し、それを、各通信グループに対して利用可能な無線資源と比較する。負荷は、システムにより使用される無線資源ごとに計算されること、すなわち、通信グループごとに計算された負荷があることに留意されたい。音声の場合、音声コーデックのパケット化間隔に対するチャネル占有時間の点から、すなわち、音声コーデックのパケット化間隔ごとに、各通信グループで消費される無線資源の量（例えば、時間）の点から、負荷の測定値を検討すると便利である。音声コーダはコールの各指示でパケット化間隔ごとに１つのパケットを生成するので、これは、ＶｏＩＰにおける簡便な測定値及び時間間隔である。さらに一般的な場合では、その期間中に所与の通信グループの無線媒体がビジーである任意の間隔及び平均時間を検討することができる。さらに一般的には、通信グループの無線媒体がビジーである長期間平均時間を簡単に検討することができる。
所与の選択肢（アドミッション、経路指定、及びトラフィック形成の選択肢）に対して、次いで、利用可能な無線資源に対して、各通信グループで転送されるはずのパケットの数及びタイプ（サイズ、バースト送りなど）を処理するために必要な負荷を検査する。そのようにすることにより、所与の選択肢に対して、システムが安定に動作するかどうかを検査することができる。さらに、安定に動作することのできる選択肢中で、本方法は、各通信グループに対するシステムの負荷測定を有する。安定動作のためのこれらの選択肢の中で、次いで、他の基準、例えば、最小のホップ数、最高の送信レート、すべての通信グループに対する最低の負荷、又は最低の平均負荷などに基づいて、選択肢を選択することができる。
選択肢を調べることにおいて、さらに、パケット損失、チャネル障害、物理レイヤレート、及び適応の影響を考慮することができる。このような影響は、負荷計算中にすべて反映される。したがって、選択肢は、さらに、経路指定の他に、アドミッション、バースト送り及び集約、通信グループの各送信で使用される物理レイヤデータレートの暗黙的な若しくは直接的制御を含むことができる。
比較すると、従来技術のアドミッション制御方法は、他の検討事項及びパラメータを利用しており、しばしば、ユーザがアドミッション可能かどうかを判断するだけである。接続レート及び遅延は、最も共通する２つのパラメータである。このような技法は、トラフィック形成によりさらに最適化されるシステムを基本的に考慮しない。８０２．１１マルチホップネットワークで定義され、且つ管理されるトラフィック形成の考えは、特有のものである。安定性及び効率は、アドミッション及びトラフィック形成をジョイントさせて用いて達成することができる。
本発明は、以下の詳細な説明及び添付の図面を検討すれば、さらによく理解される。本発明は、例えば、マルチホップ８０２．１１ネットワーク上のＶｏＩＰ（ボイスオーバーＩＰ）アプリケーションに対して適用可能である。
好ましい実施形態の詳細な説明
本発明は、８０２．１１ベースの、又は同様のネットワークにおいて、ユーザを許可し、経路指定する方法を提供する。本方法は、マルチホップ無線リンクを介してユーザのトラフィックを経路指定し、ホップの１つ又は複数で（暗黙的に又は明示的に）トラフィック形成選択肢を決定し、且つ提供する。いくつかの状況では、アドミッション可能な条件はまた、各通信グループが、パラメータ又は選択肢の所与の組（例えば、集約レベル、バースト送りレベル、及び接続レート）を満たす必要のある安定条件である。解決策は、既存の且つ新しいユーザに対して課せられるサービス品質（ＱｏＳ）制約に対して過負荷となる、或いは違反することなく、各ユーザ及び通信グループに対して、パラメータの許容可能な組（複数の解決策が存在し得る）、及び経路、及びネットワークにわたるトラフィックプロファイルを決定する。
本発明の一実施形態によれば、中心の又は「制御」エンティティは、ネットワークの状態に関するデータを収集し、また異なる可能な選択肢の下で生ずるはずの各通信グループに対する負荷を計算する。この制御エンティティは、ネットワーク中の任意の場所で存在することができ、実際、それは、ＧＡＰと共に配置することができるが、ＧＡＰ中に実装することもできる。制御エンティティは、適応化（例えば、いくつかの通信グループは、それがサポートするリンクに基づいて、上記で述べたように、いくつかのパラメータを自律的に適応させることができる）のために自動化された機構を含むネットワーク内のエンティティから情報を収集し、且つそのエンティティを利用することができる。このような自動化された機構の一例は、ＲＡＰ（relay access point；リレーアクセスポイント）であり、それは、インバウンドユーザの数及びタイプ、他のＲＡＰからのインバウンドの集約された若しくはバーストフローの数及びタイプ、及び異なるリンクのＳＮＲなど、対応するインバウンドのトラフィックパラメータに基づいて、そのアウトバウンドリンクのそれぞれにおける集約及びバースト送りレベルに対して局所的な決定を行う。
従来技術とは異なり、本発明下の方法は、選択的にユーザを許可するための複数のパラメータ（例えば、集約レベル、バースト送りレベル、及び接続レート）を考慮する。以下の詳細な説明では、「システム負荷」は、各通信グループにおける相対的なチャネル占有時間を計算することから決定され得る。システム負荷は、安定性のためのメトリックとして用いることができる。安定なシステムは、通信グループがシステム負荷をサポートできるときに得られる。音声トラフィックについては、例えば、各ユーザに対する音声パケット生成間の時間間隔が、ｘミリ秒である場合、ｘミリ秒の間隔で生成されたすべてのパケットを送信するのに必要な時間は、所与の通信グループを通過するリンクを有するユーザと関連付けられたすべてのトラフィックに対してｙミリ秒であり、ｙがｘを超える場合、システムは不安定になる。安定条件は、長い待ち行列時間なしに、また大きなパケット損失レートなしに（例えば、全部で１％未満）、すべての音声コールの音声パケットがタイムリーにサービスされることを保証する。さらに、知られたギャップ、すなわち、リンクバジェット（link budget）により、ｙがｘ未満であるなど、安定のためにさらに積極的な条件を検討することもできる。
本発明の一実施形態によれば、安定条件は、制限条件だけであると見なされる。すなわち、必要なサービス品質をすべてのユーザに提供して、ユーザをサポートすることができ、且つ安定した状態でシステムを実施可能にするための多くの可能なアドミッション及び経路指定の選択肢がある。「システム負荷」ベクトルは、所与のアドミッション又は経路指定選択の下で、トラフィック形成選択肢を適応させるように提供することができる。システム負荷ベクトルはまた、不安定な通信グループを示すために使用することもできる。
複数のパラメータを考慮に入れるアドミッションに対する一手法は、２００６年１１月、非公開のＤｏＣｏＭｏ内部文書である、Ｄ．Ｌｉ、Ｕ．Ｃ．Ｋｏｚａｔ、Ｓ．Ａ．Ｒａｍｐｒａｓｈａｄ、Ｃ．Ｐｅｐｉｎによる論文「Analyzing and Managing Traffic Shaping in the Transmission of Voiceover Multi-Hop 802.11 Networks」（「ＬＫＲＰ０６」）で開示される。この論文は、効率的に使用できる負荷計算の数学的説明を提供する。
２００７年２月に提出され、２００７年１０月に改訂された、無線通信に関するＩＥＥＥ Ｔｒａｎｓａｃｔｉｎｓ（ＩＥＥＥ会報）により再検討中の、Ｓ．Ａ．Ｒａｍｐｒａｓｈａｄ、Ｄ．Ｌｉ、Ｕ．Ｃ．Ｋｏｚａｔ、及びＣ．Ｐｅｐｉｎによる再検討中の論文「An Analysis of Joint Aggregation, Bursting and Rate AdaptationMechanisms for Increasing VoIP Capacity in Multi-hop 802.11 Networks」（「ＲＬＫＰ０７」）は、さらに詳細にその概念を記述している。特に、この論文は、非常に詳しく、パケットの送信を反映する負荷計算の他の方法の詳細な数学的説明を提供する。これらの負荷計算技法に対する掘り下げた議論を提供するために、論文ＬＫＲＰ０６及びＲＬＫＰ０７を、付属物Ａ及びＢとして本明細書に添付し、且つその全体を参照により本明細書に組み込む。
図２は、本発明が適用可能なシステム２００を示す。図２で示すように、システム２００は、リレーアクセスポイント（ＲＡＰ１からＲＡＰ３）、及びゲートウェイアクセスポイント（ＧＡＰ）を含むいくつかのアクセスポイントを含み、したがって、マルチホップネットワークを作成する。（技術的には、図２のネットワークは、２ホップと３ホップを混合した木構造のネットワークである。図５は、木構造ではないが本原理がまた適用される２つのＧＡＰを有するシステムを示す。）ＧＡＰは、他のネットワーク（例えば、有線ネットワーク）への接続性を提供する。例えば、ＧＡＰは、インターネットに対する高速の有線接続とすることができる。システム２００は、移動体端末からＧＡＰへの無線のマルチホップ経路を提供する。このようなシステムは、図５で示すように複数のＧＡＰを含むことができる。図２では、マルチホップネットワークは、複数の通信グループからなり、各通信グループ及びそのリンクは、同じ参照番号でラベル付けされる（例えば、通信グループ１は、ＧＡＰと関連付けられた４つのリンクを含む）。通信グループは、無線チャネル、又はリンクにより共用される無線インターフェースにより定義することができる。無線チャネル又はインターフェースは、関連する発信元又は宛先の移動体端末若しくはアクセスポイントにより共用される共通の無線資源である。無線資源の一例は、８０２．１１チャネル、又はＨＣＣＡなどの８０２．１１ハイブリッドスキームである。無線資源はまた、異なる時間間隔から構成され得る（例えば、通信グループは、分散された競合時間間隔、又は集中化され、制御された（ポイント調整機能（Point Coordination Function）−ＰＣＦモード）間隔であるように改良され得る）。
ネットワークは、各移動体クライアントに少なくとも１つのＧＡＰへの経路（すなわち、１組の１つ又は複数の接続されたリンク）を提供して、いくつかの移動体クライアントをサポートする。クライアントは、４つのアクセスポイントＲＡＰ１〜ＲＡＰ３、又はＧＡＰのいずれか１つに接続され得る。ＧＡＰと移動体クライアントの間で交換されるパケットは、ＧＡＰに対して１つのホップだけで（例えば、図２で、「１」とラベル付けされたリンクを介してＧＡＰに直接的に接続されるクライアント）横断し、或いはＧＡＰに対して複数のホップで横断することができる。（この詳細な説明で示される基本的なネットワークトポロジは木構造であるが、本発明の方法は、さらに一般的なネットワークトポロジに適用可能である。）図２で示すように、アクセスポイントは、いくつかの通信グループに参加することができる。一実装形態は、各グループで同時に受信し、且つ送信することを可能にする異なる無線ネットワークインターフェースカードをアクセスポイントに提供する。代替的には、単一のインターフェースカードは、複数の通信グループ間でそれを使用する適切なタイムシェアリングを用いて使用される。
同じチャネルを使用する、又は互いに強く干渉するリンクへと、通信グループの概念を一般化することができる。例えば、図３は、リレーアクセスポイントＲＡＰ３がＧＡＰと同じ時間及びチャネルを使用する、通信グループの他の配置を示している。このような構成は、図２に示すものよりも劣った性能を有するシステムが得られる。しかし、システム中で、独立して利用可能な８０２．１１チャネル又はタイムスロットの数が不適切である場合、このような構成がユーザであり、又は好ましいものであり得る。
各通信グループは、以下の状態変数により特徴付けることができる、すなわち、（ａ）他の端末、ＲＡＰ、又はＧＡＰへのアウトバウンドフローのそれぞれで使用される集約レベル、（ｂ）他の端末、ＲＡＰ、又はＧＡＰへのアウトバウンドフローのそれぞれで使用されるバースト送りレベル、（ｃ）他の端末、ＲＡＰ、又はＧＡＰからのインバウンドフローのそれぞれで使用される集約レベル、ｄ）他の端末、ＲＡＰ、又はＧＡＰからのインバウンドフローのそれぞれで使用されるバースト送りレベル、（ｅ）グループ中のＡＰにより直接サポートされる移動体端末の数、（ｆ）各フロー中の、また各ユーザからのパケット生成レート（例えば、パケット／秒で）、及びデータレート（例えば、メガ若しくはキロビット／秒で）、（ｇ）各リンク又はフローの物理レイヤのデータレート、（ｈ）各フローから見たチャネル状態、（ｉ）グループ中のＭＡＣ（媒体アクセス制御）パラメータ設定又は各ＭＡＣ機構である。パラメータのこのリストは網羅的なものではないが、これらのパラメータは、以下で論ずるように、本発明の一実施形態に従って、各通信グループ上の「負荷」を推定するために使用することができる。これらのパラメータの多くは、トラフィック形成パラメータである。他の状態変数も可能であり、例えば、各送信端末若しくはＭＡＣ機構における現在のバッファレベルも含む。
通信グループは、無線媒体中で（その大部分で）、互いに干渉しないと仮定されているが、通信グループは、その各フローの性質により互いに影響を与える。例えば、図２では、１つの通信グループ「４」の状態は、通信グループ「１」の状態に影響を与える。これは、グループ４で移動体に（から）送られるパケットは、結果的にＧＡＰで終了（生成）することになり、したがって、グループ「１」のリンクＲＡＰ３←→ＧＡＰを使用するからである。さらに、１つのＲＡＰ又はＧＡＰ上の第１の通信グループのトラフィック形成選択肢は、第１の通信グループのトラフィックの転送を行う他の通信グループ又はリンクのトラフィック形成選択肢に影響を与える可能性がある。例えば、ＲＡＰ２へのそのグループ「２」リンクに適用されるＲＡＰ１のトラフィック形成設定及び状態は、通信グループ「２」のＱｏＳに影響を与える。選択されたトラフィック形成選択肢は、ＲＡＰ１→ＲＡＰ２からのフローが、グループ「１」リンクを介して、結果的にＧＡＰへと流れることになるので、グループ「１」で見られるＱｏＳに影響を与えることもあり得る。さらに、通信グループでは、トラフィック形成インバウンドトラフィック（すなわち、パケットの数及びタイプ）は、アウトバウンドパケットに対するトラフィック形成に影響を与える可能性がある。結局、インバウンドトラフィックは、アウトバウンド送信のために一緒に収集される。
この詳細な説明において、１つの中心アプリケーションは、ＶｏＩＰトラフィックである。音声コーデックのパケット化間隔に関する安定性は、ＶｏＩＰアプリケーションに対する性能パラメータとして使用することができる。簡単化のために、以下のモデルでは、ネットワークが、ＶｏＩＰアプリケーションだけをサポートし、またパケット化間隔に関する安定性を考慮するものと仮定する。すべてのユーザが同じコーダ及びパケット化間隔を使用する場合、以下で述べる本発明の方法は、このグループを使用するユーザごとに１つのパケットを、通信グループのリンク上で転送するための予測される（又は最大）時間として、各通信グループのチャネル占有時間（すなわち、「負荷」）を計算する。通常、ＧＡＰへのユーザの経路は、複数のリンクを含む可能性があり、したがって、複数の通信グループを含む。
各アクセスポイントで（すなわち、ＧＡＰで、またＲＡＰのそれぞれで）、パケットは、割り当てられた経路に沿った無線リンクを介して送信するために収集される。共通の宛先（共通のリンクを介する）への収集されたパケットは、無線資源の効率的な使用を可能にするように、様々な方法でグループとして処理され得る。具体的には、アクセスポイントは、（ｉ）複数の音声又は送信パケットをより大きい単一の送信パケットへと「集約する」いくつかの選択肢と、（ｉｉ）無線媒体を介して複数の送信パケットを「バースト送りする」ための単一のチャネル送信期間（例えば、８０２．１１のキャリア感知多重アクセス−ＣＳＭＡスキームにおいて競合後に認められる機会）を使用することの間で選択することができる。共通の送信パケットペイロードと、チャネル送信期間を共に使用することは、８０２．１１無線インターフェースを介するデータ送信と関連するオーバーヘッドを効率よく低減する。ＷｉＯＰＴ０６、ＬＫＲＰ０６、及びＲＬＫＰ０７の論文で論じられているように、オーバーヘッドは、利用可能な合計の無線資源の２／３を超えて消費する可能性があり、いくつかの場合では、実際のデータ送信のために、１／３以下の無線資源を残すことになる。各パケット中により多くのデータを配置することにより、又は各チャネル送信期間でより多くのパケットを送信することにより、８０２．１１を介して送信されるペイロード情報のビット当たりの相対的なオーバーヘッドが低減される。
通信グループによりサポートされるフローの数及びタイプが与えられると、システムパラメータの組合せ（例えば、「集約レベル」、「バースト送りレベル」。「物理レイヤレート」、及び「リンク上の信号対雑音比」）は、各通信グループが、無線媒体を介して有する無線資源の資源利用効率に影響を与える。このようなパラメータは、所与の通信グループに対して、最良の効率となる、又は望ましいレベルの効率若しくは性能（例えば、遅延）が得られる値が与えられる。図４は、効率を改善するために、チャネル送信期間において、集約とバースト送りを共に用いる例を示す。図４で示すように、チャネル送信期間において、２つの送信パケット（すなわち、パケット４０１及び４０２）と肯定応答のパケット４０３のバーストは、短フレーム間隔（ＳＩＦＳ）により互いに分離されている。送信パケット４０１及び４０２はそれぞれ、３つの音声データパケットを集約することにより形成される。ここで、フロー「ｉ」に対する集約レベルは、ＬＫＲＰ０６及びＲＬＫＰ０７で示すように、「Ａ（ｉ）」で示され、またバーストレベルは「Ｂ（ｉ）」で示される。より一般的には、バースト送信における各パケットは、異なる集約レベルを使用することができる。ここでは、以下の数学的なフレームワークにおいて、また付属物（Appendix）において、我々は、フロー「ｉ」のバーストのｊ番目のパケットの集約レベルを示すために「Ａ（ｉ、ｊ）」を使用する、ただし、「ｊ」は１からＢ（ｉ）まで進む。すべての「Ａ（ｉ、ｊ）」及び「Ｂ（ｊ）」値はまた、統計量とすることができる。
本発明の一実施形態によれば、新しいユーザがシステムに入る場合、新しいユーザに関連付けるためのアクセスポイントが選択され、またＧＡＰへの経路が割り当てられる。いくつかの場合では、その経路は、簡単なトポロジであるため、アドミッションされると経路が暗黙的に割り当てられ得る。アドミッション（及び関連するパラメータ設定）は、得られたシステムパラメータ値が、所望の性能（例えば、最大化された効率）を達成するように正しく管理される。さらに、本発明の方法は、アドミッション及び経路を考慮するだけではなく、１つのアクセスポイントで収集されたパケットを次のアクセスポイントに転送するためのトラフィック形成機構（例えば、集約及びバースト送りレベル）を（暗黙的に又は明示的に）定義する。
図１は、本発明の一実施形態に従って、新しいユーザを許可するプロセスにおいて、アドミッション、経路指定、及びトラフィック形成を考慮に入れる方法を示す。ステップ１０１で、新しいユーザ（又はユーザのグループ）がそれぞれ、ネットワークに参加すると、方法はまず、ユーザをシステム中に許可するために検討されるべき、又は検討され得る、可能なアドミッション決定及び経路に関する情報を収集する。ステップ１０２で、方法は、ネットワークの既存の状態（例えば、集約レベル、バースト送りレベル、ＳＮＲ、並びに各通信グループのユーザの数及びタイプ）を収集する。アドミッション制御アルゴリズムは、主として以下のステップを含む、すなわち、（ｉ）マルチホップネットワークのマップを、通信グループへと分解する、又は表す、（ｉｉ）異なる可能な経路及びトラフィック形成選択肢に対して、各通信グループの負荷を計算する（ステップ１０３〜１０５）、（ｉｉｉ）すべての可能なシナリオに対して通信グループごとに安定条件を検査する（ステップ１０６）、（ｉｖ）複数のシナリオに対して安定性が得られる場合、さらなる負荷属性を検討する（ステップ１０７）、（ｉｖ）最良の解決策に基づいてネットワークに対して各ユーザを許可する又は拒絶する。
図１では、安定なシナリオを求める検索は、各アドミッション及び経路指定シナリオに対して、負荷ベクトル（各通信グループに対する負荷値からなるベクトル）を理論的に計算することにより行われる。本発明の一実施形態によれば、集約レベル、バースト送りレベル、送信レート、及び通信グループ中のユーザ若しくはアクセスポイントの数のそれぞれに対して、その通信グループに対するチャネル占有時間が計算される。各シナリオは、マルチホップネットワークの制約を考慮する。その制約は、アクセスポイント、ユーザ、及び現在の接続の数、並びに各ユーザの感知範囲を含むことができる。適正な制約を設定することは、概して、検索空間を制限する。ユーザがその感知範囲中にいくつかのアクセスポイントを有することができ、且つネットワークが、（安定条件に違反することなく）ユーザの再アソシエーションが可能である一実施形態では、すでにネットワーク中に許可されているユーザを異なるアクセスポイントに再度関連付けるシナリオを調査することができる。
可能なアドミッション選択肢のそれぞれに対して、システムの状態は、新しいユーザのアドミッションの結果変化する可能性がある。実際に、複数の変化が各アドミッション選択肢から生ずる可能性があり、また複数のアドミッション選択肢が存在する。例えば、各通信グループ中のユーザの数及びユーザのタイプは変化することができ、また１つの通信グループにおける変化は、通常、他の通信グループの変化を生ずることになる。新しいユーザに対するトラフィックが、検討された又は選択されたアドミッション選択肢に基づいた可能な経路である、ＧＡＰの１つとの割り当てられた経路により運ばれることから直接的に、このような変化が起きる。
さらに、また重要なことは、本発明の方法は、通信グループの各変化が、どのようにトラフィック形成の設定（例えば、集約、バースト送りレベル、及びそのリンク上のＰＨＹレート）を変えるか（例えば、集中的に、或いは自己適応の結果として指示されたかどうか）を決定する。トラフィック形成は、システム性能に対して強い影響を有し、またアドミッション決定は、トラフィック形成に影響を与える。本方法は、アドミッション検討及びシステム状態の変化の一部として、既存のユーザを再度関連付けるための選択肢（すなわち、ユーザが関連付けられているＡＰを、またＧＡＰへのその経路を変更すること）を有することができる。
その選択肢の選択において暗黙的な、考慮される可能なアドミッション選択肢、並びに関連するジョイントされた経路及びトラフィック形成の変化のそれぞれに対して、新しい「負荷」が各通信グループに対して計算され、新しいネットワーク状態を提供することができる。これらの可能性のある「負荷」測定は、次いで、アドミッション制御決定を行うために、また経路指定選択肢とトラフィック形成選択肢の間で選択するために使用することができ、その場合、所与のアドミッション選択肢に対して多くの選択肢が存在する。計算された「負荷」は、各通信グループに対する相対的な（割合的な）又は重み付けされたチャネル占有時間を示す。ネットワーク全体に対して、所与の選択肢に対する「システム負荷」は、負荷値のベクトルとして表すことができ、そのベクトルの各値は、通信グループに対する負荷に対応する。
所与のアドミッション、経路指定、及びトラフィック形成の選択肢に対する新しい「システム負荷」は、実際には、１つ又は複数の通信グループにおいて不安定さを示す負荷値を含む可能性がある（すなわち、通信グループは、そのアドミッション選択肢をサポートできない）。例えば、１つ又は複数の通信グループ上の負荷は、許容可能な動作のための所定の限度を超える（例えば、遅延又はパケット損失における許容可能なＱｏＳを送達する無線媒体の能力を超える負荷）。代替的には、可能性のあるいくつかのアドミッション及び経路指定選択肢により、すべての通信グループは許容可能に動作することができる。その状況では、これらの可能性の中での最終的なアドミッション及び経路指定の決定は、ネットワークの現在の制約が与えられた場合、最小数のホップ、最高の信号対雑音比、すべてのグループにわたる最大負荷の最小化、及び負荷バランシングなどの他の基準に基づいて行うことができる。
上記で論じたように、負荷は、各通信グループに対して計算される。このような負荷の計算では、異なるタイプの負荷コンポーネントが存在することに留意することが有用である。いくつかのコンポーネントは、８０２．１１ＰＨＹ及びＭＡＣヘッダなど、パケット送信ごとに生ずるが、他のものは、競合オーバーヘッドなど、チャネル送信期間ごとに生ずる。さらに、他の負荷コンポーネントは、送信される実際の音声（又は媒体）データなど、パケットが何回送信されるか、又はチャネル送信期間が何回使用されるかに対して不変である。複数の音声パケットにわたり、集約及びバースト送りの技法を使用して負荷を償却する（amortized）ことができるので、前者の２つのタイプの負荷は、トラフィック形成と密接に関連する。
多くの主要なシステムの状態パラメータは、システム負荷値を計算するために使用することができ、次いで、それは、アドミッション、経路指定、及びトラフィック形成決定を行うために使用することができる。２つのこのような計算の詳細は、ＬＫＲＰ０６及びＲＬＫＰ０７（付属物として添付される）で見出すことができ、ＬＫＲＰ０６は、簡単な方法を提供し、またＲＬＫＰ０７は、さらに詳細な方法を提供する。例えば、通信グループにおける各インバウンド又はアウトバウンドフロー「ｉ」に対して、トラフィック形成変数、すなわち、（ａ）集約レベルＡ（ｉ）又はＡ（ｉ、ｊ）、（ｂ）バースト送りレベルＢ（ｉ）、及び（ｃ）物理レイヤのデータレートＰＨＹ（ｉ）を検討することができる。このようなパラメータの多くの可能な組合せを選択することができる。特定の組合せは、特定のアドミッション及び経路指定の選択肢を指すことができる。
集約レベルＡ（ｉ）は、フローｉにおける単一の８０２．１１パケットへと集約されるパケット（例えば、音声パケット）の数を示す。バースト送りレベルＢ（ｉ）は、フローｉにおけるチャネル送信期間ごとに送信される８０２．１１パケットの数を示す。あるバーストで、異なるパケットに対して、異なる集約レベルが使用される場合、バースト中の「ｊ番目」のパケットの集約レベルを示すために、上記で述べた表記Ａ（ｉ、ｊ）を使用することができる。ＰＨＹ（ｉ）は、ｉ番目のフローを送信するために使用される物理レイヤのデータレートを示す。８０２．１１規格下では、ＰＨＹ（ｉ）は、１、２、１１、・・・、５４メガビット秒（Ｍｂｓ）の値をとる。集約及びバースト送りの使用を共に示すために、図４は、Ａ（ｉ）及びＢ（ｉ）が、それぞれ３と２の値を有するフローを示している（ここで、Ａ（ｉ、１）＝Ａ（ｉ、２）＝３）。図４はまた、集約が、通信グループにおける各ユーザから正確に１つの音声パケットを含むものと仮定している。実際上、Ａ（ｉ）は、より現実的に有効な集約レベルである（すなわち、いくつかの８０２．１１パケットは、単一のユーザから、２つ以上の音声データパケットを含むことができるが、各ユーザは、８０２．１１パケットごとに、平均して１つの音声パケットを提供する）。
この詳細な議論では、集約レベルＡ（ｉ）及びバースト送りレベルＢ（ｉ）は、すべてのチャネル送信期間で同じであると仮定する。集約レベルＡ（ｉ）及びバースト送りレベルＢ（ｉ）の他の値も可能である。Ｂ（ｉ）は、すべてのチャネル送信期間で同じである必要はない。Ｂ（ｉ）は、例えば、多くのバーストにわたる平均値とすることができる。
各アドミッション及び経路指定の決定は、パケット化間隔ごとの、各通信グループ中の各リンクに対して得られるデータパケットトラフィックのレベルに関する仮定を含む。例えば、ＶｏＩＰトラフィックに対しては、双方向の一定なビットレート（又は一定なパケットレート）トラフィックを仮定することができる。各フレーム間隔（「音声パケット間隔」）内で、方向ごとにコール当たり１つの音声パケットが生成される場合、その通信グループ内で移送される音声パケットの数は、通信グループ中のリンクで使用するユーザ数×２により与えられる。それはまた、インバウンド及びアウトバウンドに同じグループを使用したい場合、すなわち、音声パケットが、同じチャネルを用いる同じ無線インターフェースで、インバウンド及びアウトバウンドリンクリンクの両方で現れる場合、ＲＡＰにおいて、通信グループ中のリンクを用いるユーザ数×４となり得る。当然であるが、方向ごとの音声パケット間隔当たり単一音声パケットという仮定は、可変のビットレートサービスに対して無効であり、或いは単一のユーザが複数の経路を使用できる場合に無効である。正しくない仮定に対する補償は、必要に応じて計算で行うことができ、ＲＬＫＰ０７で述べられている。
すべての場合で、これらのモデルは、通信グループにより担持されるべき負荷を、通信グループ中のフローによりサポートされる（パケット化間隔ごとの）パケット数に基づいて、各アドミッション及び経路指定の決定と関連付けることができることを示唆する。この数は、グループ中のフロー「ｉ」に対して検討され得る可能な集約及びバースト送りパラメータ選択肢「Ａ（ｉ）」（又は「Ａ（ｉ、ｊ）」）及び「Ｂ（ｉ）」を定義する。このようなパラメータはまた、上記で論じたように、それが受ける新しいトラフィックに応じたノードの動作に対して暗黙的であり得る。選択肢は、通信グループにおけるすべてのフローに対して、アドミッション、経路指定、及び１組のパラメータ選択肢をジョイントさせて選択することを検討することができる。そのグループに対する負荷を、次いで、計算することができる。以下では、その負荷をサポートするのに必要なチャネル占有量の計算を示すために、パラメータＡ（ｉ）、Ｂ（ｉ）、及びＰＨＹ（ｉ）が使用される。この計算は、テストされるアドミッション及び経路指定の可能性（選択肢）により影響を受けるすべてのグループに対して行われる。ＬＫＲＰ０６及びＲＬＫＰ０７は、以下で述べる計算をさらに詳細に提供する。
その計算を行うために、他のアプリケーション特有の、又はシナリオ特有のパラメータを使用することができる。これらのパラメータは、（ｉ）音声パケットごとのビット数Ｖ（ｉ）、（ｉｉ）パケットエラーレートＰ（ｉ）、及び（ｉｉｉ）成功する送信の確率の統計的記述ｐ（ｉ、ｊ、ｍ）を含むことができる。Ｖ（ｉ）は、ｉ番目のフロー内の音声パケットごとのビット数を示す。Ａ（ｉ）及びＢ（ｉ）と同様に、Ｖ（ｉ）は、負荷の計算を簡単化するために、各ユーザに対して同じ固定値を提供することができるが、この分析は、異なるユーザが、音声パケットごとに異なるビットを生成する場合へと拡張することができる。Ｖ（ｉ）は、音声又はオーディオエンコーダにより生成される音声データだけではなく、（ａ）ＩＰ（インターネットプロトコル）ヘッダのオーバーヘッド、（ｂ）ＲＴＰ（Real time Transport）オーバーヘッド、ＵＤＰ（User Datagram Protocol）ヘッダのオーバーヘッド、及び（ｄ）各８０２．１１パケットのペイロード内の任意の他のオーバーヘッド（ユーザにわたって平均された又は償却された）、などの他のオーバーヘッド量をモデル化するために使用され得る。パケットエラーレートＰ（ｉ）は、ｉ番目のフロー中でそれぞれ送信された８０２．１１パケットのパケットエラーレートを示しており、それは、Ｖ（ｉ）、ＰＨＹ（ｉ）、及びＡ（ｉ）の関数である。例えば、上記で述べた論文「ＬＫＲＰ０６」及び「ＲＬＫＰ０７」を参照のこと。パケットのバーストを送信するためには、その計算で補償され得る無線媒体上の衝突及びエラーのため、複数回の送信試行を行う可能性がある。送信確率ｐ（ｉ、ｊ、ｍ）は、フローｉに対するバーストで「ｊ」パケットを転送するために「ｍ」回のチャネル送信期間を必要とする確率を示す。
本発明の一実施形態では、各パケット化間隔に対する負荷（すなわち、「チャネル占有時間」）は、３つの付加的なパラメータからなる。すなわち、（ａ）成功した送信時間ＴＳ、（ｂ）不成功の送信時間Ｔｆ、及び（ｃ）バックオフ時間として知られる、ノードは送信されていないが、無線媒体を求めて競合状態にある時間Ｔｂである。成功した送信時間ＴＳは、パケットを成功裡に送信するのに費やされた時間を示す。不成功の送信時間Ｔｆは、送信の失敗のため浪費された時間を示す。バックオフ時間Ｔｂは、通信グループにおける各ＭＡＣによるバックオフモードにおいて費やされた時間を示す。
成功した送信時間ＴＳは３つのコンポーネントを含む。すなわち、（ａ）各リンク上で、音声（又は他のアプリケーションペイロード）ビットを送信するのに費やされた時間、（ｂ）肯定応答（ＡＣＫ）パケットを送信するのに費やされた時間、及び（ｃ）フレーム（ＩＦ）間隔などのさらなるオーバーヘッドである。アプリケーションペイロード（例えば、音声）を送信するのに費やされた時間は、データを送信するために使用された、成功した音声パケット数及び成功したチャネル送信期間の数に対して不変のパラメータである。Ｖ（ｉ）、Ａ（ｉ）、及びＢ（ｉ）が固定であり、且つリンクｉの各ユーザに対して同じであると仮定すると、リンクを介して、各パケット間隔（例えば、ユーザごとに１つの音声パケット）中に、Ｖ（ｉ）×Ａ（ｉ）×Ｂ（ｉ）ビットが送信される。これらのビットを送信するために必要な時間は、各ユーザに対して同じ物理レイヤのデータレートＰＨＹ（ｉ）であると仮定すると、ＰＨＹ（ｉ）がメガビット／秒で表される場合、単にマイクロ秒でＶ（ｉ）×Ａ（ｉ）×Ｂ（ｉ）／ＰＨＹ（ｉ）である。
ＡＣＫパケット肯定応答を送信するのに費やされる時間は、成功した送信に続いて使用される。理論的には、１つ又は複数のＡＣＫパケットが、そのチャネル送信期間中の送信されるすべてのパケットバーストをカバーするように、チャネル送信期間ごとに送ることができる。例えば、隠れ端末がない（すなわち、グループ中のすべてのノードが、すべての他のノードからの送信を感知することができる）場合、またビット又はシンボル損失となる他のチャネル障害が何もない場合、バースト送信における最初のパケットが成功すれば、バースト中のすべての他のパケットで成功するということがＬＫＲＰ０６及びＲＬＫＰ０７で示されている。したがって、１組のＢ（ｉ）バーストに対して、ＡＣＫのパケットは、そのバーストを知らせるために使用されるはずである。８０２．１１パケットのＢ（ｉ）バーストが、すべて同じチャネル送信期間の部分であると仮定すると、１つのＡＣＫパケットが、Ｖ（ｉ）×Ａ（ｉ）×Ｂ（ｉ）ビットを送信するために提供される。集約（Ａ（ｉ））及びバースト処理Ｂ（ｉ）の両方によるトラフィック形成は、複数の音声パケット上のオーバーヘッドを償却する。
代替的には、あるバーストで送信される８０２．１１パケットごとに、１つのＡＣＫパケットを送ることもできる。このことが起きる可能性のある場合は２つある。第１の場合は、システムがそのようにすることを選択する場合である（この実施は、８０２．１１規格に準拠しない可能性がある）。第２の場合は、隠れ端末、又は無線チャネル上の雑音によるビット若しくはシンボル損失など、チャネル障害がある場合である。第２の場合では、バースト中の個々のパケットが失われるおそれがあり、そのバースト送信を終了し、ＲＬＫＰ０７で述べるように、失われたパケットを再送信することになる。これが、パラメータ「ｐ（ｉ、ｊ、ｍ）」が、送信されるＡＣＫパケットの平均数を記述することを助ける場合である。さらなる詳細については、ＲＬＫＰ０７論文を参照のこと。さらに、ＡＣＫ機構に関するさらなる詳細については、８０２．１１ｅ／Ｄ１３．０規格（IEEE P802.11e/D13.0, Part II Wireless LAN Medium Access Control(MAC) and Physical Layer (PHY) specifications: Amendment Medium Access Control(MAC) Quality of service (QoS) Enhancements, IEEE, Jan 2005）及び８０２．１１ａ規格（IEEE ComputerSociety, "Part II: Wireless LAN Medium Access Control (MAC) and PhysicalLayer (PHY) specifications: Higher-speed Physical Layer (PHY) extension in the5 GHz band," IEEE Std. 802.11a-1999 R2003.）を参照のこと。すべての場合において、集約機構は、集約された送信に対して単一のＡＣＫを作成することにより、複数の音声パケットからＡＣＫオーバーヘッドを償却するのを助けることに留意されたい。バースト送りはさらに、ＡＣＫ機構及びチャネル障害に応じて、複数の集約されたパケットを介してＡＣＫを償却することができる。
フレーム間隔（ＩＦＳ）（例えば、短フレーム間隔（ＳＩＦＳ）、プリアンブル（ＰＬＣＰ）、ＰＨＹヘッダ、及びＭＡＣヘッダなどのさらなるオーバーヘッドは、８０２．１１送信パケットごとに見られるが、分散ＩＦＳ（ＤＩＦＳ））間隔のいくつかなど、他のものは、チャネル送信期間ごとに１度だけ生ずる。ＡＣＫと同様に、これらのオーバーヘッドは、集約及びバースト送りのプロセスにより、多くの音声パケットに対して償却され、これらのプロセスによって高められた効率が得られる。これらの時間の正確な値は規格で定義される。例えば、論文ＬＫＲＰ０６及びＲＬＫＰ０７、８０２．１１ｅ／Ｄ１３．０規格、及び８０２．１１ａ規格を参照のこと。
送信の失敗のため浪費された時間（すなわち、時間Ｔｆ）は、送信媒体中の衝突から、又はチャネル障害に起因する送信された情報中のエラーから生ずる可能性がある。失敗は、各チャネル送信期間において、また送信のバースト内で転送されるパケットごとに生ずる可能性がある。チャネル障害に応じて、集約レベルＡ（ｉ）は、パケット損失レートに影響を与え得る。Ｔｆは、送信されたバーストごと（すなわち、送信確率ｐ（ｉ、ｊ、ｍ））の送信失敗の数（又は予測される数）に依存する。例えば、時間Ｔｆをどのように計算するかに関する記述については、論文ＬＫＲＰ０６及びＲＬＫＰ０７を、また各失敗に関連するオーバーヘッドについては、８０２．１１ｅ／Ｄ１３．０規格及び８０２．１１ａ規格を参照のこと。
送信の試行ごとに時間Ｔｆを計算することにおいて、含まれない主な時間は、８０２．１１パケットから失われたＡＣＫパケット、又は正しく受信されないＡＣＫパケットに対する時間である。衝突又は失敗に起因して失われた送信は、統計過程であることが多いので、時間Ｔｆはしばしば、時間Ｔｓのように確定的な値ではなく、予測される値として与えられる。例えば、ＬＫＰＲ０６及びＲＬＫＰ０７論文を参照のこと。時間Ｔｆを表す値を計算するための他の方法は、Ｔｆ値の分散（distribution）、又は時間Ｔｆが所定の時間値を超える確率を含む。
通信グループ中の各ＭＡＣによるバックオフモードで費やされる時間Ｔｂは、そのチャネルがアイドルである間に、又はシステムのＭＡＣ機構が、チャネルへのアクセスを求めて競合し、ランダムなバックオフ状態にある間に浪費される時間を表す。時間Ｔｂは、キャリア感知多重アクセス（ＣＳＭＡ）スキームに基づいた、８０２．１１規格下のＤＣＦ（Distributed Coordination Function：自律分散制御）モードの中心部分である。例えば、８０２．１１ｅ／Ｄ１３．０規格及び８０２．１１ａ規格の記述を参照のこと。
合計のシステム負荷が、次いで、すべてのリンク及びユーザを考慮することにより、また値Ｔｓ、Ｔｆ、及びＴｂに対する個々の寄与量をすべて加えることにより推定される。その通信グループ内のすべてのトラフィックにわたる合計が知られると、通信グループに対する負荷が以下の総計により与えられる。
負荷＝Ｔｓ＋Ｔｆ＋Ｔｂ
この時間ベースの負荷は、相対的な値へと変換することができる。例えば、ＶｏＩＰアプリケーションでは、音声パケット間隔がＤｓであり、負荷が、ユーザにより生成されたすべての音声パケットを送信するのに費やされた時間である場合、或いはその間隔中にフローで送信された時間である場合、「相対的な負荷」を使用することができ、それは、以下により与えられる。
相対的な負荷＝（Ｔｓ＋Ｔｆ＋Ｔｂ）／Ｄｓ
安定性のために、すべての通信グループに対する相対的な負荷は、厳密に１未満とすることができるが、或いは時には、十分に１以下とすることもできる。各通信グループに対して上記で与えられた時間負荷及び相対的な負荷値は、アドミッション選択肢に対する負荷値のベクトルを形成する。複数の選択肢を用いて安定性が達成された場合、各選択肢に対する各通信グループの相対的な負荷は、選択肢を比較するために使用することができる。例えば、各選択肢に対して、通信グループにわたり推定された最大の負荷又は平均負荷は、選択肢を比較するために使用することができる。選択肢の比較は、各フローのホップ数、又は遅延などの他のメトリックを用いて改良することができる。
上記の詳細な記述は、本発明の特定の諸実施形態を示すために提供されており、限定することを意図していない。本発明の範囲に含まれる数多くの変更形態及び変形形態が可能である。本発明は、添付の特許請求の範囲に記載される。
［付属物Ａ］
マルチホップ８０２．１１ネットワークを介する音声送信におけるトラフィック形成を分析し、管理すること
Danjue Li UlasC.Kozat Sean A.Ramprashad Christine Pepin
DoCoMo USA Labs
3240 Hillview Avenue, Palo Alto, CA, 94304
dli@ucdavis.edu,{kozat,ramprashad,pepin}@docomolabs-usa.com
（DanjueLiは、カリフォルニア大学デービス校で博士号に向けて研究している、DoCoMo USA Labsのインターンである。他の著者は、DoCoMo USA Labsの従業員である。）
要約
低コスト及び展開の容易さにより、マルチホップ８０２．１１ネットワークは、都市環境におけるラストマイルのブロードバンド（無線）アクセスを提供するための魅力的な解決策となってきた。このようなネットワークを介するＶｏＩＰ（ボイスオーバーＩＰ）など、リアルタイムのストリーミングアプリケーションをサポートするために、主な課題の１つは、無線媒体にアクセスするためにＭＡＣレイヤで使用されるＤＣＦ（Distributed Coordination Function：自律分散制御）の非効率性（すなわち、オーバーヘッド）、及びそれに関連するＰＨＹのオーバーヘッドに対してどのように対処するかである。この論文では、我々は、ネットワークアウェアなジョイントされた集約及びバースト送り、並びにチャネルエラーが存在する場合のＰＨＹレート適応を実施できる、より包括的なスキームを設計するために、集約ベースのトラフィック形成に関する我々の前の研究に対して積み上げを行う。広範囲なシミュレーションを通して、我々は、従来の移送方法に対して、３倍を超えるコール容量の改善が得られたことを示す。一方で、我々はまた、我々の提案するスキームを実施するシステムの音声容量を予測するための理論的なフレームワークを開発し、様々な無線チャネル条件下で音声容量を最適化するために、トラフィック形成設定及びＰＨＹレートをどのようにして、適正に適応させるかに関するいくつかのガイドラインを提供する。最後に、このフレームワークはそれ自体、マルチホップネットワークを計画し、且つ管理するのに有用なツールであることが明らかになるが、その場合、ネットワークの負荷（すなわち、そのユーザのチャネル占有時間）が、集中化されたアドミッション制御戦略で使用されるメトリックとなる。
Ｉ．序文
我々は、マルチホップ８０２．１１ネットワークを介して音声トラフィックを効率的に送信する問題を検討する。このようなネットワークは、多くの都市環境において、ラストマイルのブロードバンド（無線）アクセスを提供するための魅力的な解決策を提示する。８０２．１１のエンドポイントが低コストであること、既存の電力源（街灯など）が利用できること、８０２．１１が、広く使用されている規格ベースの解決策であること、及びネットの外側で（有線で）接続性を提供するためにわずかなゲートウェイだけを使用する可能性を仮定すると、これは正しい。しかし、このようなネットワークは、ＤＣＦ（Distributed Coordination Function：自律分散制御）を用いる無線媒体上でアクセスし、送信することにおける固有のオーバーヘッドに起因して、シングルホップシステムと同様の非効率性問題を受けることになる［１］。マルチホップシナリオでは、このような非効率性は、ネットワークを介してフローと共に伝播する可能性があり、障害を生じ、またシングルホップシナリオに対して効率の点でさらに大きな損失になる。
特に、８０２．１１ＭＡＣ及びＰＨＹ設計の簡単さは、明らかに魅力的であり、またある範囲のトラフィックタイプ及びアプリケーションを柔軟に収容することに成功しているが、それらが有する非効率性は、ＶｏＩＰ（ボイスオーバーＩＰ）などの重要なアプリケーションにとっては厳しいものとなり得る。基本的に、わずかなペイロードサイズ、一定のビットレートトラフィック、及び厳格な遅延要件を使用することは、基本となる８０２．１１アクセス及び送信機構と十分にマッチしていない。
我々の前の論文［１］では、マルチホップ音声送信の効率を改善するために、経路指定と共に集約ベースのトラフィック形成を使用することを提案し、ｎｓ２［２］シミュレーションを介してその有効性を示した。基本的な前提は、トラフィックが（有線の）ゲートウェイの方向に移動すると、中間の（無線の）「リレー」ノードは、経路中の次のリンク（ＭＡＣ／ＰＨＹの）をより効率的にするために、タイミング、オーバーヘッドなどの点で、トラフィック特性を変更することによりインテリジェントになり得ることである。
同じ前提に基づいて、この論文では、集約及びバースト送り戦略をジョイントして検討することにより分析を拡張し、またこのようなネットワークを分析し且つ管理するために使用できる理論的なフレームワークを提案する。具体的には、我々は、［１］で定義された競合（「α」）及びヘッダ（「β」）オーバーヘッドを詳細に調べて、異なる集約、バースト送り、及び／又はＰＨＹレイヤのデータレート設定に対して音声容量を制限する。その理論はまた、より広範囲に「バランスしていない」［１］シナリオ、すなわち、異なるリレーが、異なる設定を使用し、及び／又は等しくない数のクライアントをサポートするシナリオを我々が検討することを可能にする。これは、我々がさらに多くのシナリオに対処することを助け、またｎｓ２シミュレーションを介して容易に特徴付けることのできないｎ＞２ホップのシナリオ［１］であっても対処できるようにする。
この研究で我々が行った他の貢献は、チャネル障害が存在するシステムを管理する問題に対処していることである。このような問題は、多くの小さなパケット（フロー）を共通のより大きいパケット（フロー）に集約するリレーによって生成されるものなど、大きなパケットを送信する場合に特に重要である［１］。我々が提案した理論的なフレームワークを用いて、我々は、このようなエラーの場合に、集約だけに対して、より小さな（おそらく集約された）パケットをバースト送りするなどの他の選択肢をいかに実施するかを調べる。さらに重要なことは、我々は、トラフィック形成及び経路指定とジョイントさせて、基になるＰＨＹ送信レートをどのように適応させるべきかを検討する。
論文の残りは以下のように編成される。セクションＩＩでは、我々は、現在のＤＣＦスキームの非効率性問題を論じ、また関係する研究に対する概観を行う。次いで、我々は、８０２．１１マルチホップネットワークの効率を改善するための、提案するジョイントされたトラフィック形成、レート適応、及び経路指定 (TAR；joint Traffic shaping, rate Adaptation and Routing)機構をセクションＩＩＩで提示する。セクションＩＶでは、我々は、チャネル障害のないマルチホップネットワークの音声容量を分析するための理論的なフレームワークを提供し、また次いで、セクションＶで、この理論を用いて、チャネル障害に応じた適応型ＴＡＲ構成を考察する。ここでは、集約及びバースト送りの両方の相対的な利益、すなわち、オーバーヘッド「α」及び「β」の相対的な減少を明確に見ることができる。セクションＶＩでは、我々は、その理論をｎｓシミュレーションと比較し、またそれらがどのように、またなぜ異なるのかを調べる。セクションＶ及びセクションＶＩの結果が得られると、我々は、無線チャネル品質及び音声トラフィックパターンが、絶えず変化する、又は不確定である実際の状況におけるこのようなネットワークをいかに管理すべきかをセクションＶＩＩで論ずる。ネットワーク計画及びアドミッション制御の問題は、このセクションですべて併せて論じられる。最後にセクションＶＩＩＩで、我々は研究を要約し、いくつかのオープン問題を論ずる。
ＩＩ．背景及び関係する研究
８０２．１１ベースのＶｏＩＰでは、小さなペイロードサイズを有する複数のユーザが、共用される無線媒体を求めて競争する。これは、ＤＣＦアクセススキームがＭＡＣ（媒体アクセス制御）レイヤで使用される場合、資源を非効率に使用する結果となる。このセクションでは、このような非効率の理由を調べ、またこの問題が文献でどのように対処されてきたかに関する簡単な概観を行う。
Ａ．ＤＣＦスキームの非効率性
ＤＣＦスキームの非効率性は、２つのファクタ「α」及び「β」により表すことができる。αファクタは、競合の解決、及びパケット衝突に起因する浪費されたタイムスロットに対して使用されるアイドル期間により生じたオーバーヘッドの影響を示す［１］。これらのオーバーヘッドのタイプは、ＤＣＦアクセス機構の分散された性質に固有のものである。我々は、α、０≦α≦１を、無線媒体の生の帯域幅に対するこのようなオーバーヘッドの比として示す。帯域幅がＷである場合、（１−α）Ｗは、成功した送信に対して使用することのできる有効な帯域幅である。
残りの帯域幅の中には、送信中に生成されるＰＨＹ／ＭＡＣヘッダ、フレーム分離、及び制御メッセージによるさらなるオーバーヘッドがある。β、０≦β≦１を、残りの帯域幅（１−α）Ｗに対するこれらのオーバーヘッドの比を示すものとする。その場合、（１−β）（１−α）Ｗは、図１で示すように、実際のデータ送信に対して使用される有効な帯域幅である。実験結果［３］は、ＩＴＵ−Ｔ Ｒｅｃ．Ｇ．７１１［４］により１０ｍｓｅｃの持続期間で生成されたものなど、短いパケットを用いた場合、α及びβをジョイントさせた効果は、有効な帯域幅利用率を、合計した資源の約１０％へと低下させ得ることが示されている。
βファクタは、後に考察するために重要となる１つの特有の品質を有することに留意する価値がある。多くのパラメータと共に単調に変化するαファクタとは異なり、βファクタは、ＭＡＣレイヤのＭＴＵ（maximum transfer unit）により影響を受ける。パケットがＭＴＵサイズを超える場合、そのペイロードは複数のパケットに断片化される。すべての断片は、単一のチャネル送信期間で、連続送信として送られる。したがって、各断片化された境界では、さらなるβに関係するオーバーヘッドが追加され、そのβファクタは、不連続な飛越し（jump）を有することになる。図１の例示を参照のこと［１］。

Ｂ．関連する研究
前述の帯域幅の非効率問題に対処するために、８０２．１１ｅ［５］は、元の８０２．１１規格を拡張して、αファクタを低減するために、同じチャネル送信期間に複数のパケットをバースト送りするためのさらなる機構を提供する。８０２．１１ｎ［６］［７］では、バースト送りに加えて、αとβファクタを共にさらに低減するために、ＭＡＣレイヤ並びにＰＨＹレイヤで、異なるタイプの集約が使用される。同様の趣旨で、Ｗａｎｇ他［８］は、アクセスポイント（ＡＰ）で複数のユーザからのパケットを集約し、且つダウンリンク方向に、チャネル送信期間をよりよく利用するために、マルチキャスト送信を使用することを提案した。ヘッダ圧縮及び無音抑制がまた、システム容量を改善するために、音声トラフィックに対して過去に調査されている［３］。それらはＤＣＦ機構の効率を改善する代わりに、送信すべきデータ量の低減に焦点を当てているが、特に無音抑制は、競合を減らすことにより、αオーバーヘッドに影響を与える副作用を有する。
上記の研究はすべて、基になるネットワーキング環境として、１つのホップＷＬＡＮを考えている。８０２．１１マルチホップネットワークの環境では、解決策は、負荷を異なる無線チャネル又は経路にわたり分散することに焦点を当ててきた［９］［１０］［１１］。これらの研究とは異なり、我々は、明示的に経路指定を使用して、マルチホップネットワークの後続するホップにおいて、集約及び／又はバースト送りによりトラフィック形成を可能にする。これは実際に、より少ない経路にトラフィックを集中させることと、複数の経路にわたり負荷を分散させることの利点をバランスさせる［１］。
我々は、この論文でこの概念をさらに拡張し、また異なる集約及びバースト送り設定に対する音声容量を分析的にモデル化すること、並びにＰＨＹデータレート設定の問題を検討することに焦点を当てる。この後者の問題は、（再）送信エフォートの影響を考慮すると特に重要である。ＩＥＥＥ８０２．１１ ＷＬＡＮ［１２］［１３］［１４］に対する音声容量モデルを調査するいくつかの以前の研究があるが、これらの研究の大部分は、同一のユーザデータレート及びエラーのないチャネルを仮定している。Ｍｅｄｅｐａｌｌｉ他［１５］は、チャネルエラー及び異なるユーザデータレートを考慮しており、またシングルホップのシナリオにおけるシステム容量に対するその影響を定量化しているが、マルチホップ状況におけるトラフィック形成、ＰＨＹレート適応、及び経路指定の間でジョイントさせた関係を検討していない。我々の知る限りでは、我々の研究が、音声容量に対する異なるトラフィック形成戦略及びＰＨＹレート適応をジョイントさせた影響を定量化すること、及びマルチホップ８０２．１１ネットワークの設計及び管理に、分析的な結果を用いる系統だった方法を提供することを行う最初の試みである。
ＩＩＩ．ＴＡＲ：ジョイントされたトラフィック形成、レート適応、及び経路指定（Joint Traffic Shaping, Rate Adaptation and Routing）によりマルチホップ８０２．１１ネットワークの音声容量を向上させること
Ａ．方法
ＤＣＦスキームの効率を改善するために、我々は、図２で示すネットワークにおいて、中間のＲＡＰ（リレーアクセスポイント）及びＧＡＰ（ゲートウェイアクセスポイント）で、ジョイントされたトラフィック形成、レート適応、及び経路指定(TAR：joint Traffic shaping, rate Adaptation and Routing)機構を実装することを提案する。具体的には、各アクセスポイントは、到来するフローを集約し（すなわち、多重化し）、これらの集約したパケットを、無線チャネル中の雑音に適応した送信レートで、同じチャネル送信期間内にバーストとして送信する。適切な経路指定により、このトラフィック形成を行うことができる。経路指定及びトラフィック形成の決定をジョイントさせて行うことにより、８０２．１１マルチホップネットワークの効率を改善することができる。
集約／集約解除又はバースト送りだけを実施することを利用する我々の前の研究［１］とは異なり、ここで、我々は、集約とバースト送りを併せて検討する。さらに、我々は、トラフィックパターン及び無線媒体状態に基づいて、送信（ＰＨＹ）レートと共に、集約及び／又はバースト送りのレベルを適応的に選択する。このようにジョイントさせる考察の背景にある論拠は、集約及びバースト送りは、システムに異なった方法で影響し、またそれぞれが、それ自体の利点と欠点を有することである。
集約は、競合するフローの数を低減することによって、またＭＡＣ／ＰＨＹヘッダ、フレーム分離、及び制御オーバーヘッドを共用することによって、α及びβファクタを共に効率的に抑制することができる。バースト送りは、αオーバーヘッドだけを抑制することに焦点を当てており、したがって、集約よりも有効性は劣る。前の論文［１］で示すように、より大きい集約レベルを用いると、音声容量を増加させる可能性がある。しかし、これは、ビットエラーなどのチャネル障害の影響が無視できる場合にだけ正しい。ビット／シンボル／パケットエラーによるパケット損失が無視できない場合、集約は、バースト送りに対してその利点を失うことになり得る。例えば、独立した、また同一に分散された（ｉ．ｉ．ｄ）ビット／シンボルエラー（及び所与のエラーレート）に対して、大きな集約レベルで生成されたパケットは、短いパケットよりも高いパケット損失レートを受ける。そのパケット損失レートが十分大きくなった場合、長く誤ったパケットを再送信することにより生成されるオーバーヘッドは、送信ごとにα及びβファクタを低減させることによって節約したものを超えるおそれがある。この場合、より小さい（おそらく集約された）パケットをバースト送りすることは、よりよい選択となり得る。したがって、集約とバースト送りを一緒に組み合わせることにより、２つの戦略をバランスさせるように試みることができ、よりよいシステム性能を達成することになる。さらに、ビット／シンボル／パケット損失レートなどのパラメータは、基になるＰＨＹレートに依存する。トラフィック形成が、高いパケット損失レートのためにその利点を失う場合、この損失を、８０２．１１で利用可能なＰＨＹレート適応の選択肢とバランスさせるように試みることができる。

Ｂ．システムモデル及び仮定
図３で示される木構造の２ホップ８０２．１１ネットワークモデルを検討する。そのモデルは、以下のコンポーネントを包含する。すなわち、（１）ＶｏＩＰフローのソース及びシンク（sink）の両方として働く無線ＶｏＩＰクライアント、（２）多くのＶｏＩＰフローを転送し、且つ処理できる無線ＴＡＲ−イネーブルのＲＡＰ、（３）ネットワークの外部のホストとＶｏＩＰセッションがそれを介して確立されるＴＡＲ−イネーブルのＧＡＰである。我々は、明確化のため２ホップネットワークに対して焦点を当てているが、我々の分析は、２つ以上のホップへと容易に拡張できる。我々は、すべての音声トラフィックが、ＩＴＵ−Ｔ Ｒｅｃ．Ｇ．７１１［４］に従って、６４ｋｂｐｓのデータレートで生成され、また固定された間隔で、等しいサイズのパケットへとパケット化されるものと仮定する。
図３で示すように、複数の通信グループが、ＲＡＰと関連するＶｏＩＰクライアントの間に、またＧＡＰとＲＡＰの間に存在する。各ＲＡＰ／ＧＡＰは、そのノードが参加している通信グループごとに１つ、複数の無線インターフェースカードを備えている。各ＷＮＩＣは、同時に並列に動作することができる、すなわち、一方のインターフェースで受信し、他方のインターフェースで同時に送信する。干渉を回避するために、我々は、各通信グループが互いに直交して動作するように要求する。
ＴＡＲイネーブルのＶｏＩＰシステムに対する理論的なフレームワークを開発するために、我々は、以下の仮定を行う。
・各音声コールは、１つのアップリンクフロー（すなわち、ＲＡＰからＧＡＰへと進むフロー）、及び１つのダウンリンクフロー（すなわち、ＧＡＰからＲＡＰへと進むフロー）を含み、これらの２つのフローは、時間的に近接して開始する。アップリンクフロー及びダウンリンクフローは、独立して形成される。
・同じＲＡＰに接続されるすべの局は互いにキャリアを感知する範囲内にあり、したがって、ノードが送信しているときはいつも、すべての他のノードがその送信を検出できる、すなわち、隠れ端末がない。分析においては、ＲＴＳ／ＣＴＳの支援のない基本的なアクセスが検討されるが、我々は、ＲＴＳ／ＣＴＳが音声容量に対してどのように影響を与えるかに関する議論を、後にセクションＶＩＩで提供する。
・クライアント及びアクセスポイントに関して、そのチャネルにアクセスしようとするその試みは相互に独立している。ＲＡＰは、そのすべてのバックオフ要件を満たして、システムの媒体アイドル時間を最小にするために、ＧＡＰにより要求されるアイドル時間を利用する。
ＩＶ．チャネル障害のない音声容量
このセクションでは、我々は、異なる集約及びバースト送りの選択肢により生成されたチャネル占有量を推定するための理論的なフレームワークを提示する。これは、我々が、その有効なα及びβファクタを含む、異なる選択肢の相対的なバランスを調べることを可能にする。［１］における結果を拡張すると、我々が、チャネル障害の影響が無視できる場合のＴＡＲイネーブルの無線ネットワークの音声容量を推定することを助けることになる。

Ａ．チャネル占有時間
表１は、ＩＥＥＥ８０２．１１ｂシステムに対する重要な定数を要約している。異なる８０２．１１規格は、一般性を失うことなく、送信オーバーヘッドの点で互いに異なっているが、この後、我々の分析ではＩＥＥＥ８０２．１１ｂを検討する。Ｄｓを音声コーデックのパケット化期間、すなわち、音声パケットを生成するための時間期間とする。
分析の基になる主な考えは、平均の無線資源、すなわち、ユーザごとに１つのパケット交換をサポートするのに必要なチャネル占有時間Ｔの長期間平均を計算することによって、Ｄｓ中に保持され得るパケット交換の数をカウントすることである。この手法は、元々、ＷＬＡＮの音声容量を予測するために、Ｈｏｌｅ他［１４］により提案されている。我々は、トラフィック形成戦略、チャネル障害、及び異なるＰＨＹ送信レートに対する考慮を明示的に含めることにより、このような分析を拡張する。ＴＡＲイネーブルのシステムに対しては、上記で述べた「交換」は、図４で示すように、一方のバーストはアップリンクトラフィックに、もう一方のバーストはダウンリンクトラフィックに向けた、集約された音声パケットの一対のバーストである。
チャネルエラーの影響が無視できる場合、我々は、音声容量に対するパケット衝突の影響を考えるだけである。この場合、Ｔは主として、集約されたパケットのバーストを成功裡に送信する時間Ｔｓ、衝突を生じた送信の失敗により浪費された時間Ｔｆ、及び関連するバックオフ時間Ｔｂを含む、すなわち、
Ｔ＝Ｅ（Ｔｓ＋Ｔｆ＋Ｔｂ）＝Ｅ（Ｔｓ）＋Ｅ（Ｔｆ）＋Ｅ（Ｔｂ） （１）
所与のノードｉに対して、ｉ∈｛１、・・・、ＮＲ｝、Ｔは、そのＴＡＲパラメータの関数である、すなわち、Ｔ＝Ｔ（Ｒ（ｉ）、Ａ（ｉ）、Ｂ（ｉ））、ただし、Ｒ（ｉ）、Ａ（ｉ）、及びＢ（ｉ）は、それぞれ、ＰＨＹ送信レート、集約レベル、及びバースト送りレベルを示す。ＲＡＰ及びＧＡＰは、バランスした場合では同じＴＡＲパラメータを使用し、バランスしていない場合は異なるものを使用して構成することができる。
（１）において、Ｔｓは、音声パケットの送信時間Ｔｖ、ＡＣＫメッセージの送信時間Ｔａｃｋ、及び任意の必要なフレーム間隔（ＩＦＳ）からなる。パケットは、衝突により取り消されるおそれがあるので、Ｔｓの長期間平均は、成功する送信を有する確率に依存する。ｍを、成功する前に衝突／再送信を行う必要のある数を示すものとし、またｍは、確率関数：

を有する幾何的にランダムな変数であり、式中、ＰＣは衝突確率である。チャネルエラーが無視できない場合、ｐ（ｍ）を推定するために、チャネルエラー及び衝突損失を併せて考慮する必要のあることに留意されたい。再送信の最大数をＭｍａｘと仮定することにより、Ｍｍａｘ回の再送信の試行内で、成功する送信を有する確率は、

として推定することができ、ただし、Ｍｍａｘ回のリトライ内で成功した送信が生じた場合はＩ＝０であり、その他の場合、Ｉ＝１である。図４（ｃ）に基づいて、Ｔｓは以下のようにも表すことができる。

ただし、Ｔｖ＝Ｔｈｅａｄｅｒ＋Ｔｄａｔａであり、またＴｈｅａｄｅｒ、Ｔｄａｔａ、及びＴａｃｋは以下により定義される。

（５）において、Ｒｐは、ＩＥＥＥ８０２．１１ｂの最小のデータレートである。上記の式では、集約だけのシナリオ（図４（ａ）で示すように）に対して分析を得るためにＢ（ｉ）＝１に、またバースト送りだけのシナリオ（図４（ｂ）で示すように）に対してＡ（ｉ）＝１を、それぞれ設定できることに留意されたい。
システム中には隠れ端末がないので、図５（ａ）により示されるように、衝突は、バースト中の最初の集約されたパケットに対してだけ発生し得る。最初のパケットが、成功裡に送信される前に何回衝突を受けるかに応じて、浪費されるチャネル時間Ｔｆは、以下のように推定することができる。

ただし、τｆは、１つの送信の試行が失敗したときに浪費される時間、すなわち、τｆ＝２（ＤＩＦＳ＋Ｔｖ＋ＴＡＴＯ）である。ここで、２はアップリンク及びダウンリンクトラフィックで共にカウントすることから来ていることに留意されたい。ここで、ＴＡＴＯは、ＡＣＫタイムアウトを示しており、それを、控えめな値であるＳＩＦＳプラス最小の送信レートにおけるＡＣＫ送信時間プラススロット時間δ、すなわち、ＴＡＴＯ＝Ｔａｃｋ＋ＳＩＦＳ＋δ［１６］となるように設定する。ＰＣを得るために、我々は、２次元のマルコフ連鎖モデル［１７］を使用することができるが、或いは１／（ＣＷｍｉｎ＋１）［１５］を用いてそれを近似することができる。音声コールは、通常、Ｄｓごとにだけトラフィックを生成して、時間的にランダムに開始することを考慮すると、衝突は、主として、ＧＡＰとＲＡＰの間で１／（ＣＷｍｉｎ＋１）の確率で生ずる。図６は、ＰＣの近似に対する何らかの感度検査を提供する。我々は、そこから、音声容量は、ＰＣのわずかな変化に対してほとんど影響されず、１／（ＣＷｍｉｎ＋１）の付近で全く平坦であることを見ることができる。ｎｓシミュレーションを介して測定されたそのＰＣが約１０％であり、また音声容量が図６のこれらの場合に対して、それぞれ、４０、４０、４２であることを考えると、１／（ＣＷｍｉｎ＋１）である近似を有することは、我々の分析にとって十分正確である。
Ｕｒをタイムスロットのユニット中のｒ番目のバックオフの長さであるとすると、その場合、バックオフプロセスで費やされた累積時間は、

で表すことができる。Ｅ（Ｔｂ）を推定するために、ｒ番目の送信試行における最大の衝突ウィンドウサイズをＷｒで示す。ＤＣＦの２進指数バックオフ手順に従って、Ｗｒ＝ｍｉｎ｛ＣＷｍａｘ、２ｒ（ＣＷｍｉｎ＋１）−１｝、ｒ＝０、１、・・・、Ｍｍａｘを得る。したがって、
（２）、（６）、及び（７）を用いて、（１）にＥ（Ｔｓ）、Ｅ（Ｔｆ）、及びＥ（Ｔｂ）を代入することにより、チャネル占有時間Ｔ（Ｒ（ｉ）、Ａ（ｉ）、Ｂ（ｉ））の長期間平均を得ることができる。
ＲＡＰとＧＡＰの間に少なくとも１つの双方向コールが存在するものと仮定すると、ＮＲのＲＡＰを有するネットワークでは、合計のチャネル占有時間は以下のようになる。




Ｂ．音声容量分析
安定なシステムを維持する間に与えられる負荷ＴＷＬＡＮをサポートするために、ＴＷＬＡＮは、割り当てられた無線資源ＤＳ未満である必要がある、すなわち、ＴＷＬＡＮ≦ＤＳ。このシステムの安定性基準が満たされる場合、システムがサポートする音声コールの数は、

である。数学的には、これは最適化問題として表される。すなわち、


ただし、Ｎ０は、シングルホップ８０２．１１ネットワークがサポートできるコールの最大数であり、Ａｍａｘは、断片化を生じさせない最大の集約レベルである。セクションＩＩの議論から、我々は、集約されたパケットのサイズがＭＴＵ限界に達したとき、送信の信頼性を増すために断片化が行われ、得られたすべての断片は、バースト送り機構を用いて順次送信されることを知っている。その結果、集約を実施する利益が、断片化により生ずる余分のオーバーヘッドにより損なわれる。このような状況を回避するために、我々は、最大の断片化されない集約レベルをＡｍａｘと設定する。ＭＴＵ、ＤＳ及びＲＳが与えられると、Ａｍａｘは、

を用いて計算することができる。
最適化問題を解くためには、我々は、完全解空間を検索するために貪欲計算法（greedy algorithm）を使用することができるが、或いはそれを２段階の検索に分割する、すなわち、まず、バランスした場合に対する解を取得し、次いで、取得された解の周りを検索して、一般的な場合に対する最適なＴＡＲパラメータを選択する。Ａ及びＢが、それぞれ、集約レベル及びバースト送りレベルに対する候補の組のサイズを示すものとする。完全な検索と比較して、２段階の検索は、

からＯ（ＡＢ）へと複雑さを低減することができる。
Ｃ．低減されたオーバーヘッド
上記の分析に基づいて、我々はまた、チャネルエラーが無視できる場合におけるＴＡＲイネーブルのシステムを介する音声コールをサポートするための平均のα及びβオーバーヘッドを得ることができる。すなわち、

比較として、集約及びバースト送り戦略を実施しない、同じ量の音声コールをサポートするシステムに対するα及びβオーバーヘッドもまた取得する。

ただし、Ｔ’ｆ及びＴ’ｓは、それぞれ、（２）及び（４）のＡ（ｉ）及びＢ（ｉ）を、１であるように設定することにより、ＴＡＲディセーブルのシナリオに対して更新された値である。
Ｖ．チャネル障害を有する音声容量
我々は次に、上記の分析を拡張して、ビットエラーなどのチャネル障害が無視できない場合の音声容量をモデル化する。この目的のために、まず無線チャネルのエラー性能をどのようにモデル化するかを論議し、次いで、音声容量のモデル化に関する細部を提示することに進む。
Ａ．ＩＥＥＥ８０２．１１ｂ ＰＨＹモードのエラー性能
ＩＥＥＥ８０２．１１ｂは、異なる変調スキーム（表ＩＩ）にそれぞれが対応する２．４ＧＨｚにおいて、４つの異なるＰＨＹモードを提供する。低いデータレート、すなわち、１Ｍｂｐｓ及び２Ｍｂｐｓでは、情報を変調するために、差分的に符号化されるＭ−ＰＳＫ（Ｍ＝２、４）が使用されるが、５Ｍｂｐｓ及び１１Ｍｂｐｓのデータレートを送達する高レートの物理レイヤ拡張に対する基礎として、ＣＣＫ（Complementary Code Keying；相補符号変調）が採用される。各ＰＨＹモードのエラー性能を分析するために、以下の議論ではＡＷＧＮ（additive white Gaussian noise；加算性ホワイトガウスノイズ）チャネルを仮定する。我々は、他のより実際的なチャネルモデルでも同様に、類似のエラー性能分析を確立することができるが、計算ははるかに複雑である。
差分的に符号化されたＭ−ＰＳＫ（Ｍ＝２、４）のコヒーレント検出に対するＳＥＲ（シンボルエラーレート）［１８］は、

であり、ただし、

は、受信した信号のＳＮＲ（信号対雑音比）であり、またｅｒｆｃ（ｘ）はエラー関数である、すなわち、

より高いレートに対するＳＥＲを計算するために、変調プロセスを２つの順次のプロセス、すなわち、非回転の複雑なコード選択のためのＣＣＫ変調、及びＤＱＰＳＫベースの位相回転に分割する。すなわち、

ただし、ＰＣＣＫ（Ｋ）、Ｋ＝２、６は、下記により定義される。

ただし、

Ｄｉｊは、コードワードｉとコードワードｊの間のハミング距離であり、またｒｃはコードレートであり、ＩＥＥＥ８０２．１１ｂで使用される変調スキームに対しては１である。Ｐ（Ｓｉ）は、コードワードＳｉが送信される確率であり、その長期間平均は、

により近似することができる。
上記の分析に基づいて、図７で示すように、ＩＥＥＥ８０２．１１ｂのＳＥＲ曲線を得ることができる。
Ｂ．チャネル占有時間
ビットエラーなどのチャネルエラーの影響が無視できない場合、パケットは、衝突とチャネルエラーの両方により失われるおそれがある。衝突と異なり、パケット損失を生じるチャネルエラーは、（図５で示すように）送信中いつでもデータパケット及びＡＣＫパケットに対して発生する可能性がある。ＡＣＫパケットは小さい（１４バイト）ので、ＡＣＫパケットエラーの確率は、非常に低く、無視することができる。したがって、２つのイベント、すなわち、チャネルエラー及び衝突を統合することにより、次のようにＰＬＲを得ることができる。
Ｐ＝ＰＣ＋（１−ＰＣ）ＰＥ＝ＰＣ＋（１−ＰＣ）（１−（１−ＰＳ）Ｌ） （２２）
ただし、ＰＳは、その変調スキームに応じて、（１８）又は（２０）により定義されるチャネルＳＥＲであり、ＰＣは、セクションＩＶで定義される衝突確率であり、またＬは、そのＭＡＣヘッダを含むバイトでのパケット長であり、すなわち、

である。
Ｔｅ（Ｒ（ｉ）、Ａ（ｉ）、Ｂ（ｉ））を、パケット送信が衝突及びチャネルエラーを共に受ける可能性がある場合に、ノードｉのチャネル占有時間の長期間平均時間とする。Ｒ（ｉ）、Ａ（ｉ）、及びＢ（ｉ）は、セクションＩＶで示すように同様に定義されるが、Ｒ（ｉ）が、もはや１１Ｍｂｐｓに固定されない。そうではなくて、それは、測定されたチャネル品質により決定される変数である。これらを用いると、Ｔｅは以下のように計算することができる。

ただし、

は、衝突及びチャネルエラーを共に考慮した場合に、集約されたパケットのバーストを成功裡に送信するために使用される時間である。

は、衝突及びチャネルエラーにより浪費されたタイムスロットであり、また

は、バックオフを行うことに費やされた時間である。チャネル障害が無視できる場合とは異なり、ここでは、チャネルエラーが、最初のものだけではなく、バースト中の任意のパケットに対して再送信を生ずる可能性があり、また再送信限度Ｍｍａｘがそのそれぞれに対して同様に適用される。システムが隠れ端末を有していない場合、衝突はバースト中の最初のパケットに対してだけ起こり得るので、その位置に応じて、同じバースト中のパケットは異なるＰＬＲを受け、その結果、再送信の異なる確率となる。最初のパケットに対して、ｍ回の再送信を有する確率は、ｐ’（ｍ）＝（１−Ｐ）Ｐｍ、ｍ≧０により定義され、Ｐは（２２）により定義される。残りに対しては、以下の式を用いてその再送信確率を推定することができる。

したがって、

及び

をそれぞれ、以下のように計算することができる。

ただし、τ’ｆは、バースト中のｋ番目（ｋ≧２）のパケットの最初の送信の試行が失敗した場合に浪費される時間であり、τ’ｆ＝２（ＳＩＦＳ＋Ｔｖ＋ＴＡＴＯ）である。

は、衝突及びチャネルエラーが共に存在する場合のバックオフ手順に基づいて計算することができる。図５は、バースト中の集約されたパケットｋの送信を示す。図５により示されるように、送信側ノードが損失を検出したとき、（それがすでにＣＷｍａｘに達していない限り）倍にした最大のコンテンションウィンドウから新しいバックオフ値を選択し、最後の肯定応答されていないパケットから再送信を開始する。再送信は、そのパケットが肯定応答されるまで、又はそれがＭｍａｘに達するまで継続する。次いで、システムは、その最大のコンテンションウィンドウサイズをＣＷｍｉｎとなるようにリセットし、そのバースト中の残りを送信するように進む。このようなバックオフ手順に従って、

を以下のように表すことができる。

ただし、Ｗｒは、セクションＩＶ−Ａで定義されるように、ｒ番目のバックオフに使用される最大のコンテンションウィンドウサイズであり、またＰは、（２２）で定義されるＰＬＲである。

、

及び

を（２３）に代入すると、ＲＡＰｉ及びＧＡＰの間の双方向音声コールをサポートするためのチャネル占有時間Ｔｅを得ることができる。
Ｔｅが与えられると、我々は、構成（Ｒ（ｉ）、Ａ（ｉ）、Ｂ（ｉ））、ｉ＝１、・・・ＮＲを用いて、ＮＲ個のＴＡＲイネーブルのＲＡＰをサポートするための合計のチャネル占有時間を計算することができる。すなわち、

Ｃ．音声容量分析
前のセクションの議論から、我々は、マルチホップ８０２．１１ｂネットワークの音声容量を見出す問題は、最適化問題として数学的に表され得ることを知っている。同様の趣旨に従って、チャネルエラーが無視できない場合、以下の最適化問題を解くことによって音声容量を推定することができる。


セクションＩＶ−Ａで提案されている２段階の検索手法を用いる。この最適化問題では、（３３）は、チャネルエラー及び衝突が共に、無視できないチャネル損失を生ずる場合のシステム安定性制約である。
Ｄ．α及びβオーバーヘッド
同様に、我々はまた、

、

及び

を用いて、Ｅ（Ｔｓ）、Ｅ（Ｔｆ）、及びＥ（Ｔｂ）を（１４）及び（１５）を代入することにより、この場合のα及びβオーバーヘッドを評価することができる、すなわち、

ＶＩ．理論をシミュレーションと比較する
Ａ．シミュレーションの設定
我々は、図３により示されるように、マルチホップ無線メッシュネットワークをシミュレートするが、その場合、ＮＲ個の中間のＲＡＰ及びＧＡＰが、アップリンク及びダウンリンクトラフィックの両方に対してトラフィック形成を実施する。集約されたパケットは、次のホップに転送される前に、ダウンリンク及びアップリンクトラフィックに対して、それぞれ、ＲＡＰ及びＧＡＰで集約解除されることになる。アップフロー及びダウンフローの両方に対する音声トラフィックが、ＩＴＵ−Ｔ Ｒｅｃ． Ｇ．７１１規格に従って、一定のビットレート６４ｋｂｐｓで生成され、３０ｍｓ（これは、得られたパケット化遅延と、ＣＳＭＡ及び送信アクセスオーバーヘッドによるネットワーク上の負荷との良好な妥協である。）ごとにパケットへとパックされる。これは共に、それぞれが２４０バイトの音声ペイロードからなる等しいサイズの音声パケットを我々に与える。同期化されたトラフィック生成により生ずる高い衝突を回避するために、ノードが音声トラフィックの生成を開始する時間をランダム化する。音声トラフィックは、遅延依存型トラフィックであり、またあるレベルのパケット損失に耐えることができるだけなので、満足する品質で音声コールをサポートするためには、アップリンク／ダウンリンクフローの各対に対して、そのＰＬＲは１％以下である必要があり、また往復時間のＣＤＦ（累積分布関数）の９９％百分位数が、２５０ｍｓを超えることができない。しかし、実験［１］から、我々は、システムがＰＬＲ制約を満足する場合、それはまた非常に低い送信遅延を有すること、一方で、ＰＬＲ制約が違反された場合、往復遅延は、限りなく増加を開始することを見出した。これは、ＰＬＲ制約が違反された場合、システムは過負荷になる可能性が最も高く、不安定な状態になり、待ち行列が積み重なる可能性があり遅延が限りなく生ずることに起因している。したがって、我々は、トラフィック形成設定の実現可能性を調べるために、単にＰＬＲを使用すればよい。所与のトラフィック形成設定下のすべてのフローがＰＬＲ要件を満たす場合、このような設定は実現可能であり、そうでない場合は、実現不可能である。
ジョイントされたトラフィック形成戦略を実施するために、我々は、各ノードにトラフィック形成バッファを追加することにより、８０２．１１ｅ ＥＤＣＦ［１９］の実装形態を有する現在のｎｓ−２．２６実装形態を拡張する。このバッファは、集約及び／又はバースト送りを行う前に、十分なパケットを蓄積するために使用される。我々は、バッファする最終期限を３０ｍｓに、すなわち、音声コーデックのパケット化間隔と等しくなるように選択する。それは、３０ｍｓごとに、ノードｉは、Ａ（ｉ）ユーザのそれぞれからの単一のパケットをスーパーパケット（super packet）へと集約し、次いで、チャネルを求めて競合した後、Ｂ（ｉ）個のこれらのスーパーパケットをバースト送りすることを意味する。このバッファリング遅延は、最初のホップにおける各パケットの相対的な送信／到来時間に依存する。音声トラフィックが、最初のホップを介して比較的低い遅延ジッタを有するものと仮定すると、パケット化間隔に等しいトラフィック形成のバッファリング遅延Ｔｂｕｆを用いて、Ａ（ｉ）・Ｂ（ｉ）パケットが、各トラフィック形成段階で存在することに我々は自信を持つことができる。他のパラメータは、表Ｉに従って設定されるが、我々は、最小のコンテンションウィンドウサイズＣＷｍｉｎを７タイムスロットであるように、また最大のウィンドウサイズＣＷｍａｘを１５タイムスロットであるように選択する。
ｎｓシミュレーションを介してネットワークの音声容量を決定するために、以下の基準を使用する。

ただし、ＰＬＲｉは、ｉ番目のフローのＰＬＲである。言い換えると、ｎｓシミュレーションにより音声容量を取得することは、安定なシステムの実現可能なトラフィック形成設定によりサポートされたユーザの最大数を見出すことと等価である。
Ｂ．性能評価
我々が提案するモデルを評価するために、３つの異なる側面から得られた結果を提示する。まず、トラフィック形成の実施によりどれだけ達成できるか、チャネル品質が音声容量にどのように影響を与え得るか、また異なるトラフィック形成スキームが、前述のαオーバーヘッド及びβオーバーヘッドにどのように影響を与えるかを調べるようにしたい。この結果の部分を示すとき、システムがバランスしたトラフィック形成設定を使用している、すなわち、各ＲＡＰ／ＧＡＰが、同じＡ（ｉ）及びＢ（ｉ）を使用すると仮定する。次いで、バランスしたトラフィック形成設定を用いることと、バランスしていないトラフィック形成設定を用いることの間の比較を示す。最後に、我々は、レート適応を実施することによりもたらされる音声容量の改善を調べることになる。
１）トラフィック形成の影響：表ＩＩＩ、ＩＶ、及びＶは、３つの異なるトラフィック形成スキーム、すなわち、ａ）ジョイントされた集約及びバースト送り、ｂ）集約のみ、及びｃ）バースト送りのみが実施されたとき、我々が提案するモデルにより予測される音声容量を、ｎｓシミュレーションを介して得られた音声容量と比較する。これらの３つの表では、モデルで予測された音声容量と、シミュレーションで得られた音声容量は共に、異なるＮＲ値、すなわちＮＲ∈｛１、２、・・・１５｝に対して評価され、またすべてのノードは、１１Ｍｂｐｓで動作している。表ＩＩＩ、ＩＶ、及びＶはまた、これらの音声容量を達成するために対応するＡ（ｉ）及びＢ（ｉ）設定を与える。以降では、シミュレーション結果はすべて、複数のシミュレーションの実行からの平均的な結果である。これらの結果から、我々は、提案するモデルが、ほとんどすべての場合において、音声容量を正確に予測できることが分かる。予測された音声容量が、ｎｓシミュレーションにおける達成可能な音声容量よりも高い場合がいくつかあるが、その差は小さく、またわずかに異なるＡ（ｉ）及びＢ（ｉ）値により生ずることがしばしばある。例えば、表ＩＩＩでは、ＮＲ＝３の場合、ｎｓシミュレーションにおける達成可能な音声容量は４５であり、またそれは、集約レベルＡ（ｉ）を５に、またバースト送りレベルＢ（ｉ）を３に設定することにより達成される。この構成は、同様に我々のモデルにより実現可能である。しかし、我々のモデルは、他の実現可能なトラフィック形成設定、（Ａ（ｉ）、Ｂ（ｉ））＝（８、２）又は（２、８）を提供し、それは、より高い音声容量、すなわち、４８コールを可能にする。この音声容量は、ｎｓシミュレーションでは達成することができない。ここでのミスマッチは、基本的に、我々のモデルが、音声容量に対して厳しい上限を与えていることを示しており、それは、システムが、そのモデルにより予測された容量を超える音声コールをサポートできないことを意味する。その他の場合、システムは不安定になり、高いＰＬＲ及び長い往復遅延を受けることになる。

トラフィック形成の影響をさらに詳しく説明するために、図８は、異なるトラフィック形成スキームに対する音声容量をプロットする。上記の観察に加えて、図８から、我々はまた、提案するジョイントされたトラフィック形成スキームが、集約及びバースト送りに限って考慮する２つのスキームよりも優れていることが分かる。ＮＲが十分大きい場合、ジョイントされたトラフィック形成スキームは、集約だけのスキームとなる。ＮＲが、ある点に、すなわち、ＮＲ＝１０に達した場合、３つのスキームはすべて、同じトラフィック形成設定、Ａ（ｉ）＝１、Ｂ（ｉ）＝１を使用し、同じ音声容量を生ずることになる。
チャネルビットエラーが無視できない場合、我々は、トラフィック形成の影響を再評価する。図９は、チャネルＳＥＲが５・１０−４であるときの、モデルで予測された性能対シミュレーションで得られた性能を示す。さらに、チャネルエラーを考慮に入れる場合、我々の提案するモデルがなお、システムの音声容量を予測するのに非常に正確であり得ることが分かる。無視できるチャネルビットエラーを有する場合の図８と比較して、図９は、トラフィックを形成するために集約が使用されるスキームの音声容量はさらに低くなることを示している。これは、元の音声パケットと比較して、集約されたパケットがはるかに長く、またその結果、チャネルビットエラーに対してより脆弱であるため生ずる。パケット損失によりトリガされる高い頻度の再送信は、αオーバーヘッドを増加させ、音声容量の低下を生ずることになる。しかし、このような性能の低下は、バースト送りだけのスキームに対して現れることはない。バースト送りは、元のパケットサイズを保持するので、図９で示すように、チャネル条件により影響を受けにくい。このような観察は、適正なトラフィック形成設定の選択におけるいくつかのガイドラインを我々に提供する。すなわち、チャネル品質が良好である場合、より高い集約レベルは、音声容量を改善するために使用することができるが、チャネル品質が悪化した場合、より低い集約レベルに切り換えることが、よりよい選択肢であり得る。

図１０は、ＳＮＲ（信号対雑音比）の広い範囲に対する音声容量を示しており、ＮＲが４に固定され、また異なる送信レートが考えられている。我々は、図１０で、モデルで予測された結果及びシミュレーションで得られた結果を共に提示しており、ドットは、我々が提案するモデルにより予測される音声容量を示し、一方、線はｎｓシミュレーションにより得られた音声容量を示す。図１１は、異なるＳＮＲ値に対するモデルから演繹されたトラフィック形成設定を示す。図１０から、我々は、ノードが高データレートで、すなわち、５．５Ｍｂｐｓ及び１１Ｍｂｐｓで動作しているとき、ＳＮＲ値が特定の閾値以下に下がった場合、音声容量は非常に速やかに悪化することが分かる。これは、システムが、図１１で示すように、よりよいエラー許容力を維持するために、集約レベルを低減するように試みることに起因する。所与のＰＨＹレートに対して、集約レベルは、常に単調に減少するわけではないことに留意されたい。そうではなくて、いくつかのポイントで、より高い集約レベルが、より低いＳＮＲ値に対して使用される。このような変動は、これらのポイントで、同じ音声容量を生ずることのできる複数のトラフィック形成設定が存在し、またシステムは、最も少ないチャネル時間量を消費するものを選択するために生ずる。
さらに多くのパケット中でＰＨＹ／ＭＡＣヘッダを共用することによるβオーバーヘッドの低減と、より大きなパケットをさらに高い頻度で再送信することによるαオーバーヘッドの増加との間のトレードオフに応じて、集約レベルの変動が出現する可能性がある。異なるスキームと関連付けられたα及びβオーバーヘッドは、Ｒ＝１１Ｍｂｐｓに対しては図１２で、またＲ＝５．５Ｍｂｐｓに対しては図１２で示されている。これらの２つの図から、我々は、チャネル品質が悪化すると、両方のオーバーヘッドは、この大きな傾向に現れる小さなグリッチであるにもかかわらず、増加する傾向にあることが分かる。βオーバーヘッドを低減することをさらに強調する集約ベースのスキームとは異なり、バースト送りベースのスキームは、主として、αオーバーヘッドを低減させるように働き、βオーバーヘッドと比較するとはるかに効率が劣る。集約及びバースト送りをジョイントさせて実施することにより、システムは、αオーバーヘッドの低減とβオーバーヘッドの低減の両方の中間位置に達する。これらの２つの図からの１つの興味深い所見は、バースト送りを使用することは、常に、低いα及びβオーバーヘッドになり得ることである。しかし、集約を考慮に入れると、トラフィック形成を用いることにより、βオーバーヘッドだけが常に効率的に低減される。チャネル品質及び集約レベルに応じて、トラフィック形成の場合のαオーバーヘッドは、トラフィック形成を全く考慮しない場合よりもさらに高くなる可能性もある。



２）バランスしたトラフィック形成対バランスしていないトラフィック形成：上記結果のすべてにおいて、我々は、ＲＡＰ及びＧＡＰに対して、バランスしたトラフィック形成設定を、すなわち、Ａ（ｉ）＝Ａ、Ｂ（ｉ）＝Ｂ、Ｒ（ｉ）＝Ｒを使用し、また音声容量は、このような設定下で、安定なシステムによりサポートされる音声コールの最大数である。しかし、モデルベースの分析及びｎｓシミュレーションから、それらは共に、システムが、バランスしたトラフィック形成設定下でその容量に達しているとき、システムはその無線資源のすべてまで使用しないことを我々は観察している。いくつかの場合では、無線資源の残余は、１つ又はさらに複数の音声コールをサポートするのに十分であるかもしれない。無線資源を完全に利用する１つの方法は、ＲＡＰ及びＧＡＰに対して、バランスしていないトラフィック形成設定を使用することである。言い換えると、いくつかのＲＡＰ及びＧＡＰが、異なる集約レベル及び／又はバースト送りレベルを使用する可能性もある。バランスしていないトラフィック形成を実施する利益を示すために、我々は、まず固定数のＲＡＰを有するＴＡＲイネーブルのシステムに対する音声容量を調べる。ここで、ＮＲを再度４に選択し、所与のＳＮＲ及びＲ（ｉ）に対して、最適な（Ａ（ｉ）、Ｂ（ｉ））設定を求めて網羅的に検索する。我々の前の結果が、我々のモデルは、バランスしたトラフィック形成設定を用いた場合、音声容量を非常に正確に予測できることを示しているので、これ以降、我々は、主として、提案するモデルからのバランスした場合に対する結果を提示する。図１４で示すように、バランスしていないトラフィック形成を用いることは、ＴＡＲイネーブルのシステムの音声容量をさらに改善する。ＰＨＹレイヤ送信レート及びチャネル品質に応じて、バランスしていないトラフィック形成設定によりもたらされる容量利得は変化する。ＡＰがすべて１１Ｍｂｐｓで動作し、且つ受信した信号のＳＮＲ値が高い場合、システムは、さらに５つの音声コールを通すことができる。しかし、システムが、５．５Ｍｂｐｓ以下で動作する場合、バランスしていないトラフィック形成設定を用いることによる容量利得は非常にわずかなものである。図１４は、固定された数のＲＡＰに対するものである。図１５は、システムが様々な数のＲＡＰを有する場合にバランスしていないトラフィック形成用いることの影響を示す。スペースの制限により、Ｒ＝１１Ｍｂｐｓ、ＳＥＲ＝０．０に対する結果を示すだけである。図１５から、我々は、我々が提案するモデルは、ＲＡＰ及びＧＡＰがバランスしていないトラフィック形成設定を使用しているとき、音声容量に対して、なお、良好な予測を提供できるが、バランスしたトラフィック形成設定を検討する場合ほど正確ではないことが分かる。モデルで予測した結果と比較して、シミュレーションベースの結果は、バランスしていないトラフィック形成設定を用いることにより得られた、さらにわずかな性能改善を示している。一方、セクションＩＶの前の分析から、我々は、バランスして構成されたＴＡＲイネーブルのシステムに対する音声容量を見出すことの計算上の複雑さは、アンバランスに構成されたシステムの複雑さよりもはるかに低いことを示してきた。したがって、我々は、ネットワーク管理に関する後の議論において、ＴＡＲイネーブルのシステムを構成するために、バランスしたトラフィック形成設定を選択する。

３）レート適応：ＴＡＲイネーブルのシステムに対して、無線チャネル品質が悪化した場合、システムは、よりよいエラー許容力を提供できる変調スキームへと切り換えることを選択する。８０２．１１ｂに存在する４つの変調スキームの中で、ＢＰＳＫが最も高いエラー許容力を有するが、最も低いビットレートを有しており、一方、ＣＣＫ１１は、最高のビットレートを有するが、チャネルエラーに対して許容力が最も低い。したがって、無線チャネル品質に基づいて変調スキームを切り換えることは、実際に、システム中のノードにその送信レートに適応できるように要求することである。前の文献は、無線システムのスループットを改善することに関するレート適応の有効性を示している。このセッションの残りでは、我々は、ＴＡＲイネーブルのシステムの音声容量に関するレート適応の影響、特にトラフィック形成とのそのジョイント力の影響を調べる。この研究で我々が検討している無線メッシュネットワークでは、１つのホップ範囲内のすべてのＲＡＰは、同じ無線チャネル品質を得る可能性が高いので、それらは、そのレートを同様な方法で、すなわち、レート適応の前後で同じＲ（ｉ）を用いて、適応させる傾向がある。図１６は、固定数のＲＡＰ、すなわち、ＮＲ＝４に対する提案するモデルにより評価されたレート適応の影響を示す。
図１６（ａ）（ｂ）及び（ｃ）は、それぞれ、トラフィック形成戦略を何も実施しないシステム、バランスしたトラフィック形成設定を有するＴＡＲ−イネーブルのシステム、及びバランスしていないトラフィック形成設定を有するシステムに対する結果である。この図の実線の曲線は、レート適応を行わない音声容量であり、青の点線の曲線は、ＰＨＹレートを適応させた後の容量である。図１６（ａ）では、システム容量が、９．１ｄＢ〜１１．９ｄＢのＳＮＲ範囲において１１Ｍｂｐｓで、又は６．０ｄＢ〜９．０ｄＢのＳＮＲ範囲において５．５Ｍｂｐｓで動作する場合、非常に速く減少することが分かる。我々は、同様なパターンを図１６（ｂ）（ｃ）で観察する。しかし、レート適応を実施することにより、図１６の３つのプロットのすべてにおける青の点線により示すように、システムは、チャネル品質の悪化に対してさらに許容力を有するようになる。
図１６から、我々はまた、トラフィック形成を実施することにより、音声容量が減少するこれらのポイントが、ＳＮＲ軸でさらに右にシフトされることが分かる。例えば、１１Ｍｂｐｓで動作するシステムに対して、トラフィック形成戦略を何も実施しない場合、その音声容量は、ＳＮＲ＝１１．９ｄＢから減少し始める。しかし、バランスしたトラフィック形成戦略が実施された場合、その減少はより早く、すなわち、ＳＮＲ＝１２．４ｄＢから開始する。バランスしていないトラフィック形成を考慮すると、この容量が減少するポイントは、ＳＮＲ軸でさらに右に、すなわち、ＳＮＲ＝１３．１ｄＢに現れる。このような傾向は、送信中により長いパケットを送るために集約を用いるスキームの減少したエラー許容力によって説明することができる。

ＶＩＩ．レート適応及びネットワーク管理
我々の前の分析、及び提示された結果はこれまでに、２ホップ無線メッシュネットワークの計画及び設計においていくつかの重要な観察を明らかにしている。このセクションでは、我々は、無線チャネル品質及び音声トラフィックパターンが常に変化する、又は不確定である実際の状況で、このようなネットワークを管理するために、提案するモデルをどのように使用するかを論ずる。
Ａ．ＴＡＲ−イネーブルのシステムを実施する問題
図１７は、ＴＡＲ−イネーブルのノードの包括的なアーキテクチャを示す。図１７により示されるように、受信した無線信号のＳＮＲ（信号対雑音比）を測定することにより、各ノードは、その無線チャネル品質を推定することができる。ＳＮＲ測定値は、次いで、ＴＡＲ制御ユニットにより収集されることになる。システムが、集中化された制御機構を実施するのか、それとも分散された制御機構を実施するのかに応じて、ＳＮＲ測定値は異なった形で処理される。集中化された制御スキームが実施される場合、各ＲＡＰのＴＡＲ制御ユニットは、その収集された情報をＧＡＰに転送し、ＧＡＰからＴＡＲコンフィギュレーション（すなわち、集約レベル、バースト送りレベル、ＰＨＹ送信レート、及び経路指定決定）に関する更新を取得する。分散制御スキームが実施される場合、各ＲＡＰは、ＳＮＲ情報を局所的に処理して、事前に構築された表を参照することによりＴＡＲ更新を取得し、次の送信試行のための最良のトラフィック形成設定及びＰＨＹモードを決定する。その間に、コールマネジャは、受信した経路指定に関連する情報を用いて、そのサービングリストを更新する。

Ｂ．ネットワーク計画
前の結果から引き出すことのできる重要な結論の１つは、十分な数のリレーノードが与えられる場合、そのリレー中のすべての無線ユーザを等しく共用するために、単純な（naive）負荷バランシング手法を盲目的に適用すべきではないことである。システムの音声容量曲線は、まず、リレーノードの最適な数を特定し、次いでリレーノードの特定された数の中で負荷バランシングを行うべきであることを示唆している。この点をさらに詳細に説明するために、ここで、一例を示す。１０個のリレーノードを備えるネットワークを有しており、サポートすべき４０のＶｏＩＰユーザが存在すると仮定する。ブルートフォース（brute-force）負荷バランシングは、リレー当たり４ユーザを割り当てるはずである。しかし、表ＩＩＩによれば、必要とする１０のリレーノードがすべて使用される場合、すなわち、［ＮＲ、（Ａ（ｉ）、Ｂ（ｉ））］＝［１０、（３、１）］である場合、せいぜい３０の音声コールをサポートできるだけである。明らかに、これらの１０ユーザのそれぞれに対して、４コールを与えることは、実現可能なシナリオではない。しかし、我々の結果は、４０のＶｏＩＰユーザをサポートできる他のシナリオ、すなわち、［６、（７、１）］、［７、（６、１）］、［５、（４、２）］、［４、（５、２）］、［３、（５、３）］のあることを示している。１０のノードすべてを使用する代わりに、これらの実現可能なシナリオのそれぞれは、１０のリレーノードのサブセットを選択するだけであり、またリレーの選択は、地理的な近接性、チャネル品質、及び低いバッファリングの時間待ちなどの追加の基準を当然含む。
一方、図１１で示すトラフィック形成設定曲線と共に図８で示す容量曲線は、メッシュネットワークレイアウトのための構造を明らかにする。例えば、４０ユーザの容量が望ましい場合、トラフィック形成設定（Ａ（ｉ）、Ｂ（ｉ））＝（５、２）を用いて、それぞれが１０ユーザをサービスする４個のリレーノードを有する見取り図（floor plan）、又はトラフィック形成設定（Ａ（ｉ）、Ｂ（ｉ））＝（４、２）を用いて、それぞれが８ユーザをサービスする５ノードを有する計画は共に、無線チャネル品質が良好な場合、所望のユーザ容量を達成することができる。候補レイアウトが与えられると、我々は、干渉しないチャネルの可用性など、さらなるファクタを検討することによって、最終的な決定を行うことができる。
実際的な状況では、無線チャネル品質は常に変化する。チャネル品質が非常に速く悪化した場合、エラー許容力を高める方法を見出す必要がある。図１１及び図１６から、我々は、チャネル品質の劣化を検出したとき、システムは、常に、その集約レベルをまず低下させるように試みることが分かる。チャネル品質がなお悪化する場合、システムは、そのＰＨＹレートを減少させ、且つそれに従って集約レベルを増加させることを選択する。このプロセスは、チャネル品質が減少し続けると、繰り返される。このようなネットワークアウェアなＰＨＹレート及びトラフィック形成設定の適応化プロセスでは、チャネル品質が変化する間に、異なった音声容量が得られる結果となる。前に述べたように、異なる所望の音声容量は、同様に、リレーノードの選択に影響を与える。したがって、メッシュネットワークレイアウトを計画する場合、我々はまた、無線チャネル品質を考慮し、且つシステムが迅速にネットワーク状況に適応できるようにすべきである。
Ｃ．ネットワーク管理
無線メッシュネットワークを管理することは、２つの部分を含む。すなわち、新しいユーザをシステム中にどのように許可すべきか（すなわち、新しく参加した各ユーザをどのＡＰに関連付けるか）、及びサポートするユーザが与えられた場合、各ＡＰがどのように動作するかである。
新しいユーザをシステム中にどのように許可すべきかを見出すために、我々は、新しいユーザが、参加要求を送り出したとき、まず、システム状況を判断することが必要である。システム状況は、多くの変数により判断される、すなわち、各ＲＡＰ／ＧＡＰの送信レート、システムにより使用されるトラフィック形成設定、各ＡＰ上に存在するユーザ数などである。（さらなる詳細は、仮特許出願を参照のこと。）
ＶＩＩＩ．結論
この論文では、我々は、マルチホップ８０２．１１無線ネットワークを介して音声トラフィックを送信する間における帯域幅の非効率性問題に対処する。集約及びバースト送りだけに限って使用する代わりに、我々は、それらを共に利用して、αオーバーヘッド並びにβオーバーヘッドを効率的に低減できるジョイントされたトラフィック形成スキームを設計する。適正なトラフィック形成機構とそれらが組み合わされたとき、サポートされ得るＶｏＩＰユーザの数の点で、システム容量の実質的な増加が達成され得るような方法で、リレー及び経路指定決定を使用することを我々は提案する。さらに、トラフィック形成が、高いビット／シンボル／パケット損失に起因してその利点を失う場合、我々は、容量の劣化をバランスさせるために、ＩＥＥＥ８０２．１１におけるＰＨＹレート適応選択肢を使用することを提案する。トラフィック形成設定とＰＨＹレートの選択は、ネットワーク状況に依存する。提案の戦略を用いるシステムの音声容量を分析するために、我々は、理論的なフレームワークを開発し、それはまた、所与のネットワーク見取り図の実現可能性を評価するための容易な方法を提供する。我々のシミュレーション結果は、我々のフレームワークが、所与の数のリレーノードを有するシステムの音声容量を正確に予測することができ、また従来の移送方法と比較して、提案のジョイントされたトラフィック形成は、すべての場合で、大幅にその容量を高めることができる。リレー及びトラフィック形成設定の何らかの組合せの場合では、音声容量は、さらに２倍以上になり得る。一方、我々のシミュレーション結果はまた、ＰＨＹレート及びトラフィック形成をネットワーク状況に適応させることにより、システムが、よりよいエラー許容力を提供し、さらに安定な音声容量を維持できることも示している。
我々は、２ホップの深さを有し、且つ単一のＧＡＰを有する無線ネットワークトポロジに焦点を当てているが、このネットワークトポロジを介して得られる洞察の大部分は、より一般的なネットワークに対しても行うことができる。しかし、我々が、将来の研究で取り組むことになるさらに興味深く且つ複雑なネットワーク計画及びネットワーク管理問題が存在する。この論文で検討しなかった他の問題とは、背景トラフィックの異なるタイプが共存する可能性である。ＶｏＩＰとは異なり、ビデオストリーミングなど他のサービスは、さらに変化する、またバースト的なトラフィックを生成する可能性がある。異なるタイプのサービスを収容できるトラフィック形成戦略をいかに設計するかは、同様に、我々が将来取り組みたいテーマである。
REFERENCES
[1] C. Pepin, U. C. Kozat, and S. Ramprashad, "A Joint TrafficShaping and Routing Approach to Improve the Performance of 802.11 MeshNetwork," in IEEE WIOP, April 2006.
[2] "Network simulator,"http://www.isi.edu/nsnam/ns/.
[3] Y. Gwon, James Kempf, Raghu Dendukuri,and Ravi Jain, "Experimental Results on IP-layer Enhancement to VolPv6over IEEE 802.11b Wireless LAN," in IEEE WiNMee, April 2005.
[4] ITU-T, "Pulse Code Modulation (PCM)of Voice Frequencies," ITU-T Recommendation G.711,1988 (Blue Book), 1993.
[5] IEEE Computer Society, "Part 11:Wireless Medium Access Control (MAC) and Physical Layer (PHY) specifications:Medium Access Control (MAC) Enhancements for Quality of Service (QoS),"2005, IEEE Std. 802.11eD13.0.
[6] "TGn Sync Proposal for 802.1 ln,"http://www.tgnsync.org/techdocs.
[7] "WWiSE proposal for 802.11n,"http://www.wwise.org/technicalproposal.htm.
[8] W. Wang, S. C. Liew, and V. O. K. Li,"Solutions to Performance Problems in VoIP over a 802.11 WirelessLAN," IEEE Transactions on Vehicular Technology, vol. 54, no. 1, January2005.
[9] J. Zhu and S. Roy, "A 802.11 Based Dual-Channel ReservationMAC. Protocol for In-Building Multihop Networks," Springer Mobile Networks and Applications, vol. 10,no. 5, 2005.
[10] A. Raniwala and T. Chiueh,"Architecture and Algorithms for an IEEE 802.11-Based Multi-ChannelWireless Mesh Network," in IEEE INFOCOM, Miami, FL, March 2005.
[11] R. Draves, J. Padhye, and B. Zill,"Routing in Multi-Radio, Multi-Hop Wireless Mesh Networks," in ACMMobicom, Philadelphia, PA, Sept. 26-Oct. 1 2004.
[12] S. Garg and M. Kappes, "Can I adda VoIP call?," in IEEE ICC, Anochorage, Alaska, June2003.
[13] K. Medepalli, P. Gopalakrishnan, D.Famolari, and T. Kodama, "Voice capacity of IEEE 802.11b, 802.11a and802.11g Wireless LANs," in IEEE GLOBECOM, Dallas, Texas, Nov. 2004.
[14] D. Hole and F. Tobagi, "Capacityof an IEEE802.11b WLAN Supporting VoIP; in IEEE ICC, Paris, France, June2004.
[15] K. Medepalli, P. Gopalakrishnan, D.Famolari, and T. Kodama, "Voice Capacity of IEEE802.11b and 802.11aWireless LANs in the Presence of Channel Errors and Different User DataRates;" in IEEE VTC, Los Angeles, CA, Fall 2004.
[16] IEEE Computer Society, "Part 11:Wireless LAN Medium Access Control (MAC) and Physical Layer (PRY)specifications: Higher-speed Physical Layer (PHY) extension in the 2.4 GHzband," IEEE Std. 802.11b-1999 (R2003).
[17] G. Bianchi, "Performance analysisof the ieee 802.11 distributed coordination function," IEEE JSAC, vol. 18,2000.
[18] M. K. Simon, S. M. Hinedi, and W. C.Lindsey, Digital Communication Techniques: Signal Design and Detection,Prentice-Hall, Inc., 1995.
[19] "NS2 802.11e package," http://www.tkn.tu-berlin.de/research/802.lle\_ns2.
［付属物Ｂ］
マルチホップ８０２．１１ネットワークにおけるＶｏＩＰ容量を増加するためのジョイントされた集約、バースト送り、及びレート適応機構の分析
Sean A.Ramprashad DanjueLi Ulas C.Kozat Christine Pepin
DoCoMo USALabs, Palo Alto, CA, 94304
danjli@cisco.com,{ramprashad,kozat,pepin}@docomolabs-usa.com
要約
展開が低コストであり、容易であることにより、シングルホップ及びマルチホップ８０２．１１ネットワークは、都市環境におけるラストマイルのブロードバンド（無線）アクセスを提供するための魅力的な解決策となってきた。しかし、ボイスオーバーＩＰなどのアプリケーションをサポートするためにこのようなネットワークを使用することにおける重要な問題は、各送信に対するＭＡＣ（媒体アクセス制御）レイヤ及びＰＨＹ（物理）レイヤにおける広く知られたオーバーヘッドである。これらのオーバーヘッドの影響は、マルチホップの展開においてはより厳しいものとなり、マルチホップシステム中のＧＡＰ（ゲートウェイアクセスポイント）当たりのＶｏＩＰコールの数を、シングルホップの単一のＧＡＰシステムの数以下となるように制限するおそれがある。
この論文で、我々は、単一のチャネルを用いる１つのＧＡＰを備えるマルチホップネットワークが、シングルホップネットワークよりもより多くのユーザを実際にサポートできることを示した我々の前の研究に積み上げを行っている。そのようにするために、集約などの機能は、ネットワーク中のリレーでインテリジェントに使用される必要がある。我々は、１組のアドミッション及び経路指定決定が与えられた場合、集約、バースト送り、及びＰＨＹレート適応のジョイントされたトレードオフを考慮する理論的なフレームワークを与えて、この、前の研究に積み上げを行う。我々は、理論からのコール容量推定を、シミュレーションから導かれた推定と比較し、また経路指定／アドミッション決定を、バースト送り及び集約とジョイントさせて検討する利点を諸例を通して示す。
Ｉ．序文
我々は、マルチホップ８０２．１１ネットワークを介して音声トラフィックを効率的に送信する問題を検討する。このようなネットワークは、多くの都市環境及び企業環境において、ラストマイルのブロードバンド（無線）アクセスを提供するための魅力的な解決策である。８０２．１１のエンドポイントが低コストであること、電力源（街灯など）が利用可能であること、８０２．１１が広く使用されている規格であること、及びネットの外側における有線の接続性のためにほんのわずかなゲートウェイだけを必要とする可能性を仮定すると、これは正しい。しかし、このようなネットワークは、無線媒体上でアクセスし、送信する場合、ＭＡＣ（媒体アクセス制御）及びＰＨＹ（物理）レイヤにおける固有のオーバーヘッドに起因するシングルホップシステムにおける問題と同様の効率性の問題を受けることになる［１］。マルチホップのシナリオでは、このような非効率性は、ネットワークを横断するフローに沿って伝播し、また集中するおそれがある。さらに、これらは、厳密な遅延要件を有しており、且つ小さなペイロードサイズを有する持続的な双方向トラフィックを生成するＶｏＩＰ（ボイスオーバーＩＰなどの）重要なアプリケーションに対して、厳しい可能性がある。このようなトラフィックは、それがゲートウェイの方向に集中すると、障害を生成するおそれがある。
［１］では、アドミッション／経路指定、及びトラフィック形成のジョイントされた機構が、マルチホップのＶｏＩＰ送信の効率を改善するために提案された。このような手法の利益が、ｎｓ−２シミュレーションにより示され、その場合、ジョイント機構を用いる２ホップシステムは、単にパケットを転送するだけの２ホップシステムに対して、ＶｏＩＰコール容量において３倍を超える増加が可能であることが示されている。基本的な前提は、トラフィックが（有線の）ゲートウェイに向かって移動するとき、後続するリンクをより効率的に利用するように、タイミング、オーバーヘッド、集約、バースト送りなどによってトラフィック特性を変更するために中間の（無線の）「リレー」ノードをインテリジェントに使用できることである。具体的には、その手法は、８０２．１１ｎで利用され、且つ他の研究［２］［３］［４］［５］で観察されるように、単一の（次のホップ）宛先へと予定されたペイロードを、共通の送信パケットへと集約することにより、ＭＡＣ／ＰＨＹオーバーヘッドのかなりの部分を償却できることを示している。その結果、高められた効率及びＶｏＩＰコール容量が得られた。実際に、リレー中でより大きな集約を行うことを容易するために、ＭＡＣレイヤの上位で事前対応的にパケットを遅延させることにより、複数ホップにわたるエンドツーエンドのシステム遅延を増加することなく容量を増加することができる［１、図４］。同様の観察が、異なる制約下で、集約及び他のネットワークトポロジの便宜的な使用を考慮する［６］における関連のテストベッド研究で行われている。
集約及びバースト送りを用いることによって［４］［５］、また（ダウンリンクで）マルチキャストすることによって［８］効率を高める方法が、シングルホップシナリオに対して提案されている。しかし、マルチホップシナリオに対して、［１］で行われた重要な点は、集約及びバースト送りが使用される能力及び程度は、経路指定及びアドミッションの決定にしばしば依存することである、例えば、経路指定はトラフィックをリレーへと集中させるために使用することができる。特に、［１］で示すように、ＧＡＰへのホップをさらに多く用いるようにユーザに強制すること（例えば、ＧＡＰに直接接続するよりも、リレーを介する長い経路を用いるなど）は、実際に、システム（ＧＡＰ）がサポートできるコール数を増加することができる。実際に、我々は、それだけに限らないが、音声コール容量を最大化することを含むいくつかの異なる目的を達成するために、意図的に、トラフィック形成と併せて経路指定／アドミッションを検討できることを後に（セクションＶＩＩで）示す。さらに、ＰＨＹレート適応など、［１］で検討されたものを超える選択肢が、送信エラーの存在する中で動作するシナリオにおいて対象となる。したがって、ジョイントして最適化されたマルチホップシステムなどを設計し、且つ管理することの両方において検討すべき多くの選択肢及び決定を有することになる。
しかし、所与のジョイントされたパラメータ設定及び決定がシステム性能に対して有する可能性のある影響を理解することは簡単ではない。実際に、シミュレーション／テストベッドにより、すべての可能な集約、バースト送り、ＰＨＹ設定、及びアドミッション／経路指定動作のジョイントされた影響を分析することは、検討され得る多数の可能な組合せを考えると、それが中程度のサイズのネットワークであっても実際的ではないことがしばしばある。それは、これらのシステムをどのように理解し、設計し、動作させるかに関する問題を提示する。これは、部分的には、［１］が、いくつかの「バランスした」２ホップのシナリオに調査を限定している理由である。［６］で示すように、他のシミュレーション／テストベッドベースの研究は同様に、すべてのパラメータの明示的にジョイントされた検討を行うことなく、実用的にいくつかのシナリオに（［６］では、６ノードの線形なトポロジと１５ノードの例）限定される。実際に、［１］（直接的に）及び［６］（暗黙的に）は共に、ジョイントされた最適化の利益を示しているが、これらの研究の比較は、検討されるシナリオ／ネットワークが異なるので、可能ではない。
この論文では、我々は、より一般的な状況で、さらに詳細に、これらのジョイントされた最適化の影響を検討し、且つ理解するようにしたい。そのフレームワークは、ＤＣＦ（Distributed Coordination Function：自律分散制御）の動作を考慮するなどの状況を記述する。検討されていないが、競合によるものなど、オーバーヘッドに対してさらに節約する、集中化されたＰＣＦ（centralized Point Coordination Function；ポイント調整機能）を用いるネットワークもまた、多くの固有のＭＡＣ／ＰＨＹオーバーヘッドを償却する同様のジョイント方法から利益を得るはずである。本論文の目標は、最初の段階としてＤＣＦを用いて、所与のジョイント選択のその基になる利益／効果を定量化することである。我々は、マルチホップネットワークが、隠れ端末を有しない非干渉性の通信グループへと細分化できるシナリオに限定する。そのようにすることにより、我々は、実際の展開における干渉及び／又は隠れたノードから生ずる可能性のあるさらなる劣化を簡単化のために無視して、ジョイントされたＭＡＣ／ＰＨＹパラメータ／アドミッション／経路指定の設定に関する固有の利点／欠点に、主として集中する。このような問題は、分析において、さらに損失期間を導入することにより対処することができる。いくつかのこれらの問題の影響は、［５］における分析で示すように、ＲＴＳ／ＣＴＳ（返信要求／受信準備完了）メッセージを用いることにより部分的に緩和することができるが、我々の分析では、このようなプロセス／選択肢を明示的にモデル化することはない。このようなシステムの実際的な管理において、経路の発見、チャネル／送信エラーの推定、遅延の推定などの関連する問題もまた存在する。これらのいくつかは、［６］で検討されている。しかし、このような問題は、この論文の範囲を超える。
本論文は、マルチホップネットワークにおける各リンク上で対象とする主なパラメータの多くのもの、例えば、集約、バースト送り、ＰＨＹレート、及びシンボルエラーレートを含む理論的なフレームワークを提供する。アドミッション及び経路指定選択は、どのリンクが存在し、またどんな集約及びバースト送り設定が可能かを暗黙的に定義する。我々は、主に、一般的なトレードオフに関心があり、したがって、本フレームワークは、［９］［１０］［１１］で概要が示された容量ベースの分析と、趣旨において同様である。しかし、対象とするいくつかの基本的なシナリオに対するｎｓ―２シミュレーションにより得られた結果と本理論を比較する。非干渉性のグループであるという仮定の下で、マルチホップネットワークにおける各無線資源に対する負荷が、所与の設定に対して計算される。こうすることにより、多数の可能なパラメータの組合せ及びその実現可能性を、すなわち、現在のＶｏＩＰフローをサポートするその能力を、簡便に検討することが可能になる。したがって、本フレームワークは、このようなネットワークを理解し、管理し、且つ計画することを助けるためのツールを提供し、ネットワーク中の潜在的な障害、及び負荷の重い領域を特定することを可能にする。我々はまた、［１２］［１３］［１４］で示すように、負荷を分散させるように試みる標準的な方法が、アドミッション／経路指定及びＭＡＣ／ＰＨＹパラメータをジョイントさせて選択する方法ほど多くの音声コールをサポートできないことを示す諸例を提示する。
本論文の残りは、以下のように編成される。セクションＩＩでは、我々は、簡単に、現在の８０２．１１ＤＣＦ機構の非効率性を論じて、我々の提案する、ジョイントされたトラフィック形成、アドミッション、経路指定、及びレート適応（ＪＴＡＲＲ）手法へと導く。セクションＩＩＩでは、我々は、チャネル障害のない場合に対するマルチホップネットワークの負荷を分析するための理論的なフレームワークを提供し、セクションＩＶで、ＶｏＩＰ容量に対する上限を与えるために、これらの負荷をどのように使用すべきかを述べる。セクションＶでは、我々は、チャネル障害を有する場合に対して、この理論を拡張する。セクションＶＩでは、ｎｓ−２シミュレーションと本理論を比較して、パラメータのジョイントされたトレードオフを詳細に調べる。セクションＶＩＩでは、我々は、簡単に、実際の状況において、このようなネットワークをどのように管理すべきかを論じて、ＶｏＩＰ容量を最大化することを含めて、いくつかの異なる目的に対処するために、本フレームワークをどのように使用できるかを示す。最後に、セクションＶＩＩＩで、研究を要約し、またいくつかのオープン問題を論ずる。
ＩＩ．ＪＴＡＲＲ：ジョイントされたトラフィック形成、アドミッション、経路指定、及びレート適応
最初に、１１Ｍｂ／ｓのＰＨＹレート、１Ｍｂ／ｓの基本レート、単一のチャネル、及びデフォルトでＧＡＰとして働く単一のアクセスポイント（ＡＰ）を用いるＤＣＦ管理のシングルホップシナリオを検討する。移動体ユーザは、このＡＰに接続し、またそれぞれは、ＶｏＩＰコールをサポートするために、双方向に一定のビットレートである（ＩＴＵ−Ｔ Ｒｅｃ． Ｇ．７１１［１５］と一致した）６４ｋｂ／ｓフローを用いる。各８０２．１１パケットのペイロードが、さらなる４０バイトのＩＰ／ＲＴＰ／ＵＤＰオーバーヘッドを有する３０ｍｓｅｃの音声データを表す場合、８０２．１１ｂシステムは、１５のＶｏＩＰコールをサポートできるに過ぎない可能性がある［１６、表４］。ここで、ペイロードは、無線媒体上の合計時間の約２０％を占める。パケット間隔が１０ｍｓｅｃに低減された場合、システムは、いまや媒体上の時間の約１０％だけを占めるペイロードを有する６コールをサポートできるに過ぎなくなる［１６、表４］。さらに、さらなるＡＰを同じチャネルを用いて単一のＧＡＰに接続し、単に、他のユーザ／ＡＰからのＶｏＩＰパケットを転送した場合、システム全体は、対応するシングルホップシステムよりも多くのコールをサポートできないことに留意されたい。実際に、すべてのＡＰ／ユーザがＧＡＰと同じチャネルを用いる場合、システムのスループットは、例えば、［６、図１］で示すようにホップ数が増加して、大幅に悪くなることが多い。
ＶｏＩＰユーザは小さなペイロードサイズを使用するので、その非効率性は、８０２．１１ベースのＶｏＩＰ展開で特に明らかである。送信されたパケット当たりの固有のＤＣＦ ＭＡＣ／ＰＨＹレイヤのオーバーヘッドを考えると、相対的な非効率性は、ペイロードサイズが減少すると共に増加する。ここで、シングルホップのシステムでは、遅延ペナルティを受けるので、パケットの持続期間を増加させることは、ＶｏＩＰでは実現できない可能性のあることに留意すべきである。しかし、マルチホップシステムでは、複数のパケットにわたる追加の機能を可能にする。効率を改善するために、我々は、マルチホップネットワークに対して、中間のＲＡＰ（リレーアクセスポイント）及びＧＡＰにおいて、ジョイントされたトラフィック形成、アドミッション、経路指定、及びレート適応（ＪＴＡＲＲ）機構を実施することを提案する。この論文では、我々は、図１及び２で示されるネットワークを検討するが、その場合、アクセスポイントは、パケットを集約し、及び／又はバースト送りすることが可能である。このようなネットワークでは、正しくユーザを許可し、トラフィックを経路指定することにより、またＭＡＣレイヤへのパケットのリリースを適正に遅延することにより、８０２．１１ＭＡＣ／ＰＨＹレイヤの効率を高めるような機構を、ＡＰが使用する（又はバースト送りのように、引き起こす）ことを可能にする［１］。
集約は、異なるＩＰパケットからのペイロードを１つの８０２．１１送信パケット中に含めるためのプロセスである。こうすることにより、競合する送信パケットの数を低減し、複数の音声パケットにわたるＭＡＣ／ＰＨＹヘッダ及び制御オーバーヘッドを償却することができる。バースト送りは、単一のチャネル送信期間で、複数の８０２．１１パケットが送信されるプロセスである。これは、競合／アイドルスロットのオーバーヘッドを抑制することに焦点を当てており、したがって、集約よりも有効性は低い。しかし、ビット／シンボル／パケットエラーに起因するパケット損失が無視できない場合、集約は、長いパケットの使用を利用しているので、不利になり得る。さらに、ビット／シンボル／パケット損失レートは、その基になるＰＨＹレートに依存しているので、８０２．１１ＰＨＹレート選択肢と共に、集約及びバースト送り戦略をジョイントして適応させるように試みることができる。我々の目的は、可能性のあるジョイント設定の一般的なトレードオフを定量化するフレームワークを提示することである。
Ａ．一般的なモデル、仮定、及び例
トレードオフを理解することへの第１ステップとして、我々は、可能性のあるＪＴＡＲＲイネーブルのＶｏＩＰシステムの簡略化されたモデルをこの論文で検討する。具体的には、本モデルは、分析を通信グループごとの分析へと細分化できるようにする。通信グループは、同じ無線資源を求めて互いに競合する１組のフローとして定義される。このようなグループは、所与の地理的位置における所与の無線チャネルによって定義される。単一のフローは、（所与の通信グループにおける）同じ起点及び宛先を有するいくつかのＶｏＩＰリンクを表しており、それらは、集約を介して一緒に束ねられ、及び／又は共通のチャネル送信期間を使用するようにバースト送りされる。このようなリンクは、クライアント又はアクセスポイントで生成され／終了され得る。
簡単化のために、我々は、異なる通信グループのチャネルが、互いに直交して動作すること、及びそのグループ内のフローを生成し／終了するすべてのノードが、互いに感知できる、すなわち、隠れ端末がないことを仮定する。この直交性は、異なるグループが異なるチャネルを使用する場合、及び／又は、図１及び２で示すように、異なるグループが同じチャネルを使用するが地理的に十分に分離されている場合に可能であり得る。チャネルの数又は地理的な分離が制限される可能性のある実際的な展開については、グループと隠れ端末の間の干渉などのさらなる問題が生ずる。どうしても分析を簡単に保つために、また基になるトレードオフに焦点を当てるために、我々は、これらの問題を直接検討することはない。しかし、シンボルエラーの影響が、セクションＶで検討される場合、追加のエラーベント（error-vent）を含めることによって、このような影響を部分的に補償するための可能性が存在する。
本モデルでは、アクセスポイント（ＡＰ又はＲＡＰ又はＧＡＰ）は、複数の無線インターフェースを備える。インターフェースは並列に動作する、すなわち、同時に、インターフェースで受信及び／又は送信することができる。図１（ａ）を参照する。この例では、我々は、４チャネル及び２つのゲートウェイを用いて検討するが、アクセスポイントは、最高で２つのインターフェースを有することができる。ここでは、フロー／リンクが使用するチャネルは、通信グループという用語と同義語である。ＲＡＰ１、ＲＡＰ２、及びＧＡＰ２はそれぞれ、これらのアクセスポイント間の接続に対して使用されるチャネル１に対して１つのインターフェースを有する。ＲＡＰ１は、ＧＡＰ１への接続のために、チャネル４上にさらなるインターフェースを有する。各アクセスポイントは、そのサービス領域中のユーザと通信するために、その「主チャネル」だけを使用する。４チャネルの制約を考えると、ＧＡＰ１は、この目的のためにチャネル４を使用し、またＲＡＰ１は、この目的のためにチャネル１を使用する。ＲＡＰ２及びＧＡＰ２は、ユーザに対して直接サービスするために、追加のチャネル、すなわち、チャネル２及び３をそれぞれ使用する。追加のチャネルは、より多くのインターフェース、又は異なる主チャネルを作成するために使用することもできる。代替的には、追加のチャネルは、図１（ｂ）で示すように、通達領域を拡張することができ、その場合、グループは、同じチャネルであるが、地理的に分離されているものを再使用する。
ユーザは、このようなシステムで複数の選択肢を有する。例えば、図１（ａ）では、「ユーザ１」は、ＲＡＰ１、ＧＡＰ１、又はＧＡＰ２と関連付けられ（許可され）得る可能性がある。同様に、「ユーザ２」及び「ユーザ３」はまた、複数のアドミッション可能性を有する。このようなシステムでは、他のパラメータとは独立して、アドミッション決定を（及び経路指定の決定もまた）考慮することができる。ここでは、所与のユーザを、可能な場合、まずＧＡＰ１又はＧＡＰ２に許可し、次いで、可能な場合、ＲＡＰ１又はＲＡＰ２へと許可するように試みることが理にかなっているはずである。しかし、後で示されるように、これは、実施し得る最良のジョイントを決定するものではない。
Ｂ．２ホップ木構造の例
セクションＶＩのシミュレーションでは、我々は、図２で示されるように、単一のＧＡＰを有する２ホップ木構造のネットワークに対して焦点を当てる。この例のグループ１はまた、次のセクションで説明するフレームワークに従うことを助ける。図２の２ホップネットワークは、以下のコンポーネントを有する。すなわち、（１）Ｋ個の通信グループ、それぞれが、アクセスポイントの主チャネルと関連付けられている、（２）ＶｏＩＰフローの最も遠いソース（アップリンクで）及びシンク（ダウンリンクで）の両方として働く無線ＶｏＩＰクライアント、（３）多くのＶｏＩＰフローを転送し、且つ処理できる無線ＪＴＡＲＲイネーブルのＲＡＰ、及び（４）ＶｏＩＰセッションが、ネットワークの外側のホストとそれを介して確立されるＪＴＡＲＲイネーブルのＧＡＰである。この例では、図１（ａ）で示すように、ＲＡＰは、２つのインターフェースを有し、ＧＡＰは１つのインターフェースを有する。さらなる非干渉性のチャネルが利用可能である場合、ＧＡＰは、そのクライアントに直接的にサービスするためにそれを使用し、したがって、さらなる（Ｋ＋１）番目のグループを作成することもできる。
Ｃ．リンク及びフローを定義する
我々の手法では、各通信グループの無線チャネル上に置かれた負荷を調べる。この負荷は、チャネルが「使用中」、すなわち、そのグループ中のノードにより保持される時間の割合を定義する。マルチホップシステムにおける負荷を計算するために、我々は、ＶｏＩＰパケットがどのようにしてシステムを横断するかを定義する必要がある。図２では、各音声コールは、１つのアップリンク方向、及び１つのダウンリンク方向を含み、またパケットは、１つ又は２つのホップを介して移動する。他のトポロジの場合、クライアントと、終端のＧＡＰとの間の各音声パケットの経路をより一般的に定義することができる。パケットが、ＲＡＰを介して、又はクライアント若しくはＧＡＰに送られたと仮定すると、各グループにおける各無線リンクに対して検討することのできる異なるバースト送り、集約、及びレート選択肢がある。負荷の推定を用いて、我々は、各グループに対して、実現可能な組の選択肢を決定することができる。以下では、用語「チャネル占有時間」と「負荷」は交換可能に使用する。
通信グループが、同じ無線資源を求めて競合しているいくつかのフローからなるものとする。これらのフローは、移動体クライアント、ＲＡＰ、及び／又はＧＡＰとすることのできるＮｎ個のノード、すなわち、ノード（１）、・・・、ノード（Ｎｎ）により生成される。例えば、図２のグループ１では、ノード（１）、・・・、ノード（Ｋ−１）がＲＡＰであり、ノード（Ｋ）がＧＡＰであり、ノード（Ｋ＋１）、・・・、ノード（Ｎｎ）がＧＡＰに直接接続されるクライアントである。他のグループでは、状況が異なることもあり得る。我々は、インデックスｉ＝１、・・・、ＮＦを使用して、このグループによりサポートされるＮＦ個のフローにインデックスを付ける。図２のグループ１では、各ＲＡＰにより直接サービスされるクライアントからのすべてのパケットが、１つのアップリンクフローへと組み合わされ、また所与のＲＡＰによりサービスされるクライアントに向けられたすべてのパケットが、１つのダウンリンクフローへとＧＡＰ中で組み合わされる。これを用いると、グループ１中に、合計ＮＦ＝２Ｎｎ−２個のフローがある。Ｓｋを、ノード（ｋ）で生成されたフローの１組のフローインデックスとする。
Ｓｋ＝｛ｉ：フローｉはノード（ｋ）により送信される｝ （１）
各フローがそれ自体のＪＴＡＲＲ設定を有すると仮定する。バースト送りレベルＢ（ｉ）は、フローｉに対して、何個の集約されたパケットが、単一のチャネル送信期間でバースト送りされるかを示す。１つのバースト内で、Ａ（ｉ、ｊ）、ｊ＝１、・・・、Ｂ（ｉ）は、バーストのｊ番目に送信されたパケットに含まれる音声パケットの数を示すものとする。Ａ（ｉ、ｊ）値は、任意の集約されたパケットの長さが、８０２．１１パケットのＭＴＵ（maximum transfer unit）の制限を超えないように選択される。その最大値を、Ａｍａｘとして示す。さらに、Ｒ（ｉ）及びＨ（ｉ）は、ＰＨＹレイヤのデータレート、及びフローｉに対して使用されるＰＨＹレイヤの基本レートを示すものとする。
我々は、すべての音声コールが、各方向に対して、毎秒Ｒｓビットのソースレートで一定のビットレートのトラフィックを生成すると考える。音声トラフィックは、移送するために、それぞれが音声のＤｓ秒を表すパケットへとパックされる。ＭＡＣレイヤにおけるパケットのペイロードは、４０バイトのＩＰ／ＵＤＰ／ＲＴＰヘッダを含む。すなわち、ＭＡＣレイヤにおける各音声パケットは、ペイロード中に（ＲｓＤｓ＋８・４０）ビットのデータを含む。したがって、フローは、それがサポートしている各（音声コールの）方向に対して、Ｄｓごとに少なくとも１つの音声パケットの送信を（平均して）サポートしている。表１はさらに、式及びその分析で使用する重要な定数を要約している。これらの仮定及び定義を用いると、我々は、我々のシステムにおけるトラフィックを完全に定義し、負荷分析を進めることができる。
ＩＩＩ．チャネル障害のないグループごとの負荷を分析する
このセクションでは、我々は、所与のグループに対するチャネル占有時間を推定するための理論的なフレームワークを提示する。チャネル障害が無視できる場合に関して焦点を当てることにより開始する。
Ａ．チャネル占有量の分析
グループ「ｇ」によりサポートされるトラフィックを考えると、我々は、Ｄｓの時間間隔で、グループ中のフローにより生成される予測される負荷の測定値、Ｔｇを調べる。我々は、チャネルエラーのないこと、及び送信されたパケットは、衝突によってのみ失われることを仮定することにより開始する。この場合では、負荷は、３つのコンポーネントを含む。すなわち、１）Ｔｓ、集約されたパケットのバーストを成功裡に送信した時間、２）Ｔｆ、衝突で生じた送信の失敗に起因して浪費された時間、及び３）Ｔｂ、チャネルを求めて競合している場合、ランダムなバックオフで費やされる関連の時間である。これらの時間はしばしば統計的なものである。したがって、我々は、長期間平均（予測される）値、すなわち、負荷＝Ｅ［Ｔｓ＋Ｔｆ＋Ｔｂ］＝Ｅ［Ｔｓ］＋Ｅ［Ｔｆ］＋Ｅ［Ｔｂ］を調べる。我々はこの負荷に対する下限Ｔｇを計算する。
Ｂ．成功した送信及び失敗した送信の確率
後続するセクションで使用される統計の鍵となる組は、成功した送信及び失敗した送信の確率である。量Ｅ［Ｔｓ］、Ｅ［Ｔｆ］、及びＥ［Ｔｂ］はすべて、これらの統計に依存する。我々は、いまや衝突によってのみ失われたパケットの場合を検討する。システム中には隠れ端末がないので、衝突は、２つ以上の端末が、同時に送信を開始した場合にだけ生ずる。したがって、衝突イベントでは、バースト中の最初のパケットが失われて送信バーストを終了する。我々のシステムでは、再送信の数をＭｍａｘに制限し、その場合、各パケットは、他のパケットとは独立したＭｍａｘ回のこのような試行を有する。したがって、検討する必要のあるＭｍａｘ＋２の場合、すなわち、０、・・・、Ｍｍａｘの失敗した送信とその後に続く良好な送信に対応するＭｍａｘ＋１の成功した場合と、Ｍｍａｘ＋１すべてが送信を失敗した可能性のある場合とが、各パケットに対して存在する。
フローｉにおけるｊ番目のパケットに対して、正確にｍ回失敗した送信を有する確率として、ｐ（ｍ、ｉ、ｊ）を定義する。Ｐｓｕｃｃ（ｉ、ｊ）＝１−ｐ（Ｍｍａｘ＋１、ｉ、ｊ）を定義する。これは、ｊ番目のパケットが、Ｍｍａｘ＋１回の試行で成功裡に送信された確率を定義する。明らかに、最初のパケットが成功裡に送信されると、衝突による損失のみを考えているので、ｊ＞２の他のパケットすべてが、確率１を有するバーストで成功裡に行われる。しかし、最初の（又は任意の）パケットが、Ｍｍａｘ＋１回の試行後、送信されることに失敗した場合、それは取り消される。Ｐｆａｉｌ（ｉ、ｊ）＝１−Ｐｓｕｃｃ（ｉ、ｊ）を定義する。あるパケットが取り消された場合、次のパケットは、図３で示すように競合／バースト送りプロセスを再度開始する。
ｐ（ｍ、ｉ、ｊ）値の正確な計算は、多くの仮定に基づく［９］［１１］、例えば、最初の送信試行で衝突する可能性、及びバックオフウィンドウの制限の成長に起因するさらなる影響などである。ここでは、簡単化した仮定を行う。平均の負荷及び音声容量計算のために、特に負荷の重いシナリオでは、［９］［１７］で示すように、衝突は、ほぼ定常状態の確率ＰＣで、互いに独立して生ずるものと仮定すれば十分である。このような負荷の重いシナリオは、音声容量を理解する上で、またシステムを管理するのに最も重要である。これらの仮定の下で、

により、ｐ（ｍ、ｉ、ｊ）を近似する。
Ｐｆａｉｌ（ｉ、０）＝１を用いて、ｊ＝１及びｍ＝０で開始し、再帰的に値を計算することができる。図３で示すように、
Ｐｆｉｒｓｔ（ｉ、ｊ）＝Ｐｆａｉｌ（ｉ、ｊ−１）.Ｐｂｕｒｓｔ（ｉ、ｊ）＝Ｐｓｕｃｃ（ｉ、ｊ−１） （３）
は、それぞれ、パケットｊがバースト送信中で最初である確率、及びパケットｊが、バースト送信中で、２番目である確率、また３番目である確率などである。
我々の論文では、さらに、値ＰＣを仮定する必要がある。衝突が、主としてＧＡＰとＲＡＰ若しくはクライアントとの間で（またより少ないが、ＲＡＰ間、又はクライアント間で）発生するものと仮定した場合、検討すべき１つの値は、ＰＣ＝１／（ＣＷｍｉｎ＋１）である［１１］。他のものは［５、（１）］で示唆されている。セクションＩＩＩ−ＣからＶで概略を示した式を用いると、図４は、ＰＣ値に対する容量の感度を示している。セクションＩＶで定義されるように、我々は、音声容量予測が、ＰＣの小さな変化に対してそれほど感度はなく、１／（ＣＷｍｉｎ＋１）の近くでは全く平坦であることが分かる。したがって、我々は、計算のためにＰｃ＝１／（ＣＷｍｉｎ＋１）を使用するが、概して、セクションＩＩＩ−ＣからＶにおける任意の値のＰＣ、又は任意の形式のｐ（ｍ、ｉ、ｊ）を使用することができる。最後に、Ｐｆａｉｌ（ｉ、ｊ）は、ＶｏＩＰトラフィックを分析することにおける重要性を有していることにも留意されたい。ＶｏＩＰアプリケーションは、使用される音声コーデック及びパケット損失秘匿関数（concealment functions）に応じて、値Ｐｆａｉｌ＞０を許容することができる。典型的な許容可能限界ＬＯＳＳｍａｘは、１％から５％の範囲である。
Ｃ．Ｔｓ：成功した送信の占有量
ＶｏＩＰについて、我々は、Ｄｓの時間間隔内における負荷値（チャネル占有時間）を調べる。Ｄｓ間隔中では、グループの各フローは、平均して、そのフローを用いる各クライアントから１つの音声パケットをサービスする。我々のシステムでは、フローはまた、平均して、Ｄｓ秒の時間を超えないうちに、１組のバースト／集約されたパケットとして、このようなパケットのグループを送信する必要がある。Ｔｓ（ｉ）が、フローｉからの音声パケットの成功した送信に対して費やされた時間を示すものとする。ここで、我々は、ヘッダ、ＡＣＫパケットの送信時間Ｔａｃｋ、及び任意の必要なフレーム間間隔（ＩＦＳ）を含める。バースト中のすべてのパケットが送られる場合、時間は簡単に、

であり、ただし
Ｔｖ（ｉ、ｊ）＝Ｔｈｅａｄｅｒ（ｉ）＋Ｔｄａｔａ（ｉ、ｊ）.ＴＰＨＹ（ｉ）＝ＰＨＹ／Ｈ（ｉ） （５）

８０２．１１ｂに対して、上記で使用されるパラメータ値は、表１で見出すことができる。ｊ−１番目のパケットが失敗した場合、ｊ番目のパケットが、いくつかの後続するバースト試行における最初のものとなる。ここで、次の式を定義する。

これは、ｊ番目のパケットが、バースト中の最初のものとして成功裡に送信された確率を定義する。Ｐｆｉｒｓｔ（ｉ、１）＝Ｐｆａｉｌ（ｉ、０）＝１なので、Ｐｓｕｃｃ（ｉ、１）＝Ｐｓｕｃｃ２（ｉ、１）であることに留意されたい。バースト中で最初のものとして、成功裡に送信されたパケットは、送信される前にＤＩＦＳ期間を有し、またバースト中の２番目、３番目などとして成功裡に送信されたパケットは、ＳＩＦＳ期間を有する。Ｅ［Ｔｓ（ｉ）］は以下のようになる。

最後にフロー全体で合計する。
この時点で、我々は、すべてが同じパケット間隔Ｄｓ及びソースレートＲｓを使用するＣＢＲ（一定のビットレート）ＶｏＩＰトラフィックの場合に対して焦点を合わせているが、本モデルは、他の統計を有する他のトラフィックタイプを含むことができることに留意されたい。ここでは、値Ｔｄａｔａ（ｉ、ｊ）は、所与の時間において、どのようなサイズ／タイプのパケットが、フロー中で共に集約され、且つバースト送りされたかに応じた、ある範囲の可能な値を反映させた統計量となるはずである。個々の値は、ＭＴＵサイズなどの制約に準拠する必要があり、また［１０］では、予測値Ｅ［Ｔｄａｔａ（ｉ、ｊ）］が、最終的に対象とする量である。説明の簡単化のために、我々は、一定のＤｓ及びＲｓを有するＣＢＲの場合に焦点を当てることとする。
Ｄ．Ｔｆ：不成功の送信の占有量
我々は、いまや各Ｄｓの時間間隔内における衝突により浪費された時間を調べる。衝突イベントは、バースト中の最初のパケットだけに影響を与える。フローｉのパケットｊがバースト中の最初のものであり、送信の試行が失敗した場合、このフローにより浪費された時間は、τｆ（ｉ、ｊ）により与えられる。すなわち、
τｆ（ｉ、ｊ）＝ＤＩＦＳ＋Ｔｖ（ｉ、ｊ）＋ＴＡＴＯ （１１）
ここで、ＴＡＴＯは、ＡＣＫタイムアウト、すなわち、送り側が、そのパケットが失われたことを宣言する前に、待つ必要のある時間を示す。我々は、それを、ＴＡＴＯ＝ＴＰＨＹ＋ＳＩＦＳ＋δに等しくなるように設定する［１８］。δは表Ｉで定義される。ｐ（ｍ、ｉ、ｊ）を用いると、このような失敗した最初の送信の予測される数は、

により与えられる。
衝突だけの仮定の下では、ｊ＞１のパケットは、バースト中で第２、第３などで送信される場合、決して失敗しないことに留意されたい。これは、（１２）によって、暗黙的に仮定される。（１２）を用いると、

しかし、Ｅ［Ｔｆ］の計算において、衝突は、２つ以上のフローの重なりを含むので、（１０）で示すように、すべてのｉに対して単純に合計することはできない。しかし、我々が、１つのノード、例えば、「ルート」ノードが多くのフローにサービスするネットワークを検討する場合、多くの独立したイベントを補償するＥ［Ｔｆ］に対する下限は、以下のようになる。

ここで、所与のノードから生成されるフローは、明らかに、互いに衝突することはなく、したがって、このようなフローにわたり合計することができる。我々は、（１４）における最大値は、最も重い負荷を有するノード、例えば、ルートノードにより与えられることが多いものと予測することができる。このような負荷に対するフローの数がフローの合計数の大きな割合である場合、このような限度は、実際に厳しいものとなり得る。
Ｅ．Ｔｂ：ランダムなバックオフによる時間
チャネル送信期間を得ようとする最初の試みにおいて、送信するノードは、２つの場合の一方を見ることになり得る。第１の場合では、パケットを得ると、ノードは、期間ＤＩＦＳの間、チャネルが空いていることを感知する。この場合には、バックオフは行われず、パケットが送信される。第２の場合では、ＤＩＦＳの期間の間、チャネルが空いていない。ここで、ノードは、ランダムなバックオフを用いて、チャネルを求めて競合して進む。送信ノードが、ｍ回の試行の後バースト中の最初のパケットを送信するのに失敗したと仮定し、またＵｒを、タイムスロットのユニットで使用されるｒ番目のバックオフの長さとする。ｍ回のこのような試行の後、フローｉに対するバックオフに費やされた累積時間は、以下のようになる。
ｒ番目の送信試行における最大の衝突ウィンドウサイズをＷｒで示す、すなわち、バックオフがＵｒ〜Ｕｎｉｆｏｒｍ［０、Ｗｒ］まで実施されたと仮定する。バックオフ手順に従って、我々は、Ｗｒ＝ｍｉｎ｛ＣＷｍａｘ、２（ｒ−１）（ＣＷｍｉｎ＋１）−１｝、ｒ＝１、・・・、Ｍｍａｘ＋１を得る。Ｅ［Ｕｒ］を計算するために、我々は、ノードが、最初にチャネルを感知したとき、チャネルが空いていることを知り、バックオフなしで、すなわち、Ｕ１＝０で送信できた可能性を考える必要がある。我々は、重い負荷の下では、それはわずかな確率で生ずると仮定して、この可能性を無視する。したがって、Ｅ［Ｕｒ］＝Ｗｒ／２ ∀ｒと仮定する。
Ｅ［Ｔｂ（ｉ）］を計算するために、我々は、平均して、時間間隔Ｄｓにおいて、フローｉに対して、どれだけの数のバックオフプロセスが生じたかを計算する必要がある。ここで、我々はｊ番目のパケット、ｊ＝１、・・・、Ｂ（ｉ）がバースト中で最初になるすべての可能な場合を考える必要がある。送り側ノードが、損失パケットを検出した場合、それは、新しいバックオフ値でチャネルを求めて再度競合し、且つＴＸＯＰを取得すると、最後の肯定応答されないパケットからの再送信を開始することに留意されたい。再送信は、パケットが肯定応答されるか、或いはそのパケットに対するＭｍａｘ回の再送信限度に達するまで続けられる。この限度を超えるパケットは取り消される。取り消された後、システムは、その最大のコンテンションウィンドウのサイズをＣＷｍｉｎへとリセットし、そのバースト中の残りのパケットの送信へと進む。簡単のために、ＷＭｍａｘ＋２＝０と定義し、これを用いると、Ｅ［Ｔｂ（ｉ）］は以下により与えられる。

第１項は、バックオフがパケットｊによりトリガされる確率を反映している。第２項は、任意のｒ、ｒ＞１のバックオフを反映している。（１４）のように、我々はＥ［Ｔｂ］を制限する。

その基になる仮定（１７）は、バックオフ機構が、Ｓｋ内の時間において、１つのフローにだけ適用されることである。最後に、負荷の下限を定義する。

ＩＶ．音声容量分析
Ａ．Ｈｏｌｅ−Ｔｏｂａｇｉ限界に対する関係
この時点で、（１０）及び（１７）を用いて、衝突のないシステムに対する負荷の下限を定めることを検討することができる。この下限の負荷は、次いで、音声容量の上限を定めるために使用することができる。何らかの集約及びバースト送り選択肢を有しないシングルホップのシステム、すなわち、Ｂ（ｉ）＝１＝Ａ（１、１） ∀ｉでは、式は、システム中でＱ個の音声コールをサポートするための負荷を定義することができる。ここで、我々は、Ｑクライアント及び１つのＧＡＰ、すなわち、Ｑ＋１個のノード及び２Ｑ個のフローを有する。ＧＡＰは、Ｑ個のダウンリンクフローをサポートする。したがって、Ｑコールに対する負荷の下限、ＬＱは、以下のようになる。

次いで、ＬＱ≦Ｄｓであるように、Ｑｍａｘ＝ｍａｘＱを見出すためにこれを使用することができる。衝突がないという仮定の下では、ｐ（０、ｉ、ｊ）＝Ｐｓｕｃｃ（０、ｉ、１）＝１ ∀ｊ、

及びＥ［Ｔｂ（ｉ）］＝ＣＷｍｉｎδ／２である。

を用いると、それは、Ｑｍａｘが、［１０］でＨｏｌｅ及びＴｏｂａｇｉにより導かれた上限と同じであることが得られる。その結果において、著者は、ＧＡＰだけがバックオフする、衝突のない場合を考えている。式（１９）のｍａｘｋ演算は、ＧＡＰであるノードによって達成されるため、結果は同じである、すなわち、その結果は、ＧＡＰのバックオフだけがカウントされている。
Ｂ．２ホップネットワークを有する一般的な場合を例示する
グループ的な分析は、我々に、セクションＩＶ−Ａの手法を拡張することにより多くのシステムに対して、（負荷に対する下限に基づいて）音声容量の上限を計算できるようにする。実際、システム中のコールをサポートするためには、Ｔｇは、すべてのグループｇに対して、パケット化間隔Ｄｓ未満である必要がある。例示のために、セクションＩＩ−Ｂで述べるように、異なる主チャネルをそれぞれが有するＮＲ＝Ｋ−１のＲＡＰ、及び（ＮＲ＋１）番目のチャネルを用いる単一のＧＡＰを有する２ホップシナリオを考えることとする。ＲＡＰは、この（ＮＲ＋１）番目のチャネルを用いてＧＡＰに接続される。所与のＲＡＰとそのそれぞれのクライアントとの間のフローからそれぞれが構成されるＮＲ個のＲＡＰ定義グループがある。我々は、これらのグループがバースト送り及び集約を使用せず、したがって、セクションＩＶ−Ａで述べるように、それがサポートできるクライアント数に対して、それぞれが、制限Ｎｍａｘ＝Ｑｍａｘを有するものと仮定する。
このＱｍａｘの制限が、最初のホップ（ＲＡＰ）グループに対して違反されないという制限の下で、音声容量は、第２のホップのフロー、すなわち、（ＮＲ＋１）番目のチャネル（グループ）を用いたＧＡＰ←→ＲＡＰ及びＧＡＰ←→クライアントのフローによりサポートできるコールの最大数により与えられる。各ＲＡＰが、１つのアップリンクＲＡＰ→ＧＡＰのフローをサポートしていると仮定する。これらのＮＲ個のフローは、インデックスｉ＝１、・・・、ＮＲが付される。さらに、我々は、ＧＡＰに直接接続されたＮｃのクライアントが存在すると仮定する。これは、インデックスｉ＝ＮＲ＋１、・・・、Ｎｕ、ただし、Ｎｕ＝ＮＲ＋Ｎｃを有するＮｃ個のアップリンクのクライアント→ＧＡＰフローを与える。我々は、ｉ＝ＮＲ＋１、・・・、Ｎｕに対して、Ｂ（ｉ）＝Ａ（ｉ、１）＝１と仮定する。これらのアップリンクフローによりサポートされる、Ｄｓ秒における音声パケットの数は、以下により与えられる。

コールごとに１つの音声パケットであると仮定すると、これはまた、アップリンクによりサポートされる音声コールの数である。
各アップリンクフローに対して、ＧＡＰは、１秒当たり同じパケット数を転送するダウンリンクフローをサポートすると仮定する。このようなフローをｉ＝Ｎｕ＋１、・・・、２Ｎｕにより示すと、その制約は、以下のようになる。

音声容量は、システム負荷がＤｓを超えないように、（２０）の最大値である。

（２１）が成り立つものと仮定する （２２）

である場合、
すべてのグループに対しＴｇ≦Ｄｃであり、Ｐｆａｉｌ≦ＬＯＳＳｍａｘ （２４）
Ｔｇは、ＧＡＰが（１４）及び（１７）で最大を達成したノードである形にまで低減される。
後に、我々は、簡単化のために、「バランスした」シナリオを考えるが、それは、

フローに対して、

及び

である。これらのシナリオの場合、容量は、

及び

に対する網羅的な探索により取得することができる。ＲＡＰが、異なるパラメータを使用できる、及び／又は様々な数のクライアントをサポートできる、より一般的な場合では、検索空間は大きくなる可能性があり、容量分析の意味が低くなる可能性がある。このような「バランスしていない」場合に対する限度を検討することにおいて、我々は、バランスした場合に対する最適解の周囲を局所的に探索することが多い。しかし、クライアントをサポートすることにおいて、ネットワーク動作中に、パラメータの特定の組の実現可能性をテストするために、すなわち、パラメータが、アドミッション及び／又は経路指定の決定に関しておそらく暗黙的であるＴｇ≦Ｄｓ ∀ｇをテストするために負荷を用いることは、直接的である。Ｔｇは、実際に負荷に対する下限であることに留意されたい。実際のシステムでは、セクションＶＩ−Ａ及びＶＩ−Ｂで論じたように、バジェットδ＞０、及びテストＴｇ≦Ｄｓ−δを可能にすべきである。
Ｖ．チャネル障害を有する負荷及び音声容量
我々は、いまや分析をチャネル障害が無視できない場合に対して拡張する。ここでは、パケットは、衝突及びチャネルエラーの両方に起因して失われる可能性がある。衝突による損失とは異なり、チャネルエラーによる損失は、送信中の任意の時間に、データパケット及びＡＣＫパケットで共に発生し得る。我々は、他の無線ノードからの干渉による損失は無視して、付加的な雑音によるチャネルエラーに焦点を当てる。バイトがシンボルを表すこと、及びシンボルエラーが、独立して、全く同一に分散される（ｉ、ｉ、ｄ）ように生ずると仮定する。我々はまた、我々の分析中ではＨ（ｉ）＜＜Ｒ（ｉ）であると仮定し、また基本レートＨ（ｉ）で送信されたシンボル中のエラーは無視する。ＰＳがシンボルエラーレート（ＳＥＲ）である場合、パケットエラーレートはＰＥ（ｉ、ｊ）＝１−（１−ＰＳ）Ｌ（ｉ、ｊ）である。ここで、Ｌ（ｉ、ｊ）は、集約されたパケットに対して、

のデータレートで送信されるすべてのシンボルからなる。ＡＣＫパケットは、小さい（１４バイト）ので、付加的な雑音による誤ったＡＣＫパケットの確率は、無視できるものと仮定する。
我々は、送信が、衝突及びチャネルエラーを共に受ける場合、グループｇに対するチャネル占有量の長期間平均を考える。Ｔｇにおけるように、我々は、下限

を考える。すなわち、

Ｔｇで使用された定義と並列に、

は、衝突及びチャネルエラーを共に考慮した場合、集約されたパケットを成功裡に送信するために使用される時間であり、

は、衝突及びチャネルエラーにより浪費されたタイムスロットであり、また

は、ランダムなバックオフで費やされた時間である。

及び

の値は、それぞれ、

及び

に対する下限である。
衝突は、バースト中の最初のパケットに対して発生し得るに過ぎない。シンボルエラーは、バースト中のパケットの任意のものに影響する可能性がある。したがって、バースト中で送信される最初の集約されたパケットだけが、両方の障害に会うことになる。２つのイベント（チャネルエラー及び衝突）を統合することにより、我々は、
Ｐ（ｉ、ｊ）＝ＰＣ＋（１−ＰＣ）ＰＥ（ｉ、ｊ） （２６）
により与えられるバースト送信中の最初のパケットに対して、安定状態のパケット損失レートを仮定する。他の集約されたパケットに対しては、考慮すべき２つの場合がある。前の成功した送信に続いて、このようなパケットがバースト中で送信されている場合、それは、シンボルエラーによりエラーになるだけであり得る、すなわち、損失の確率は、ＰＥ（ｉ、ｊ）により与えられる。この試行でパケットがエラーとなる場合、再送信時には、このパケットはいまや再送信における最初のパケットとなる。前のパケットが決して成功裡に送信されなかった場合、それもバースト中の最初のパケットとなる。これらの最後の２つの場合では、パケットは（２６）により与えられる損失確率となる。
衝突及びシンボルエラーの下で、Ｐ’（ｍ、ｉ、ｊ）を、フローｉのｊ番目のパケットが、ｍ回の失敗した送信を有する確率とする。我々は、セクションＩＩＩ−Ｂで示すように、Ｐ’ｆａｉｌ（ｉ、ｊ）＝ｐ’（Ｍｍａｘ＋１、ｉ、ｊ）及びＰ’ｓｕｃｃ（ｉ、ｊ）＝１−Ｐ’ｆａｉｌ（ｉ、ｊ）を定義する。我々は、バースト中の各パケットが、他のパケットから独立したＭｍａｘの再送信の機会を有するものと仮定する。それは以下のようになる。

我々は、Ｐ’ｆａｉｌ（ｉ、０）＝１を用いて、ｍ＝０及びｊ＝１で再帰的に開始して、値を計算することができる。
Ｐ’ｆｉｒｓｔ（ｉ、ｊ）＝Ｐ’ｆａｉｌ（ｉ、ｊ−１）及びＰ’ｂｕｒｓｔ（ｉ、ｊ）＝Ｐ’ｓｕｃｃ（ｉ、ｊ−１）と定義し、またセクションＩＩＩ−Ｃで示すように、

とする。

バースト中の最初のものとして、ｊ番目のパケットの失敗した送信を反映する

を定義する。その場合、

である。ここで、τ’ｆ（ｉ、ｊ）は、パケットは失敗したが、バースト中の最初のものではない場合に浪費された時間である、すなわち、τ’ｆ（ｉ、ｊ）＝（ＳＩＦＳ＋Ｔｖ（ｉ、ｊ）＋ＴＡＴＯ）であり、τｆ（ｉ、ｊ）は、（１１）で定義される。我々は、

を、

として下限を定めることができる。（１６）で示すように、Ｗｍａｘ＋２＝０と仮定する。我々は、

を

として表すことができる。（３０）で示すように、

を以下のように限度を定める。


、

及び

を（２５）中に代入すると、

が得られる。セクションＩＶは、２ホップネットワークに対する音声容量の分析を述べる。その分析において、Ｔｇの代わりに

を単に代入することにより、ＰＥ＞０について同様の分析を行うことができる。
我々の分析では検討されていないが、無線ノード間の干渉、及び隠れノードからの干渉は、さらなる損失を生成する可能性がある。いまや無視し得ない可能性のあるＡＣＫパケットの損失を含むこれらの損失のいくつかは、（２６）におけるＰＣを増加させることにより、おおよそ補償され得る。ＡＣＫパケットの損失はまた、パケットは送達されたが、ノードが再送信を続ける状況を作る可能性がある。干渉それ自体は、仮定したチャネルの信号対雑音比に、したがってＰＥに影響を与える。ＰＣ及びＰＥは共に、いまや、特定の時点における問題のグループ及び／又は個々のノードの関数である。これらの損失のいくつかは、８０２．１１のＲＴＳ／ＣＴＳ機構を用いることにより緩和される可能性があり、それは、例えば、ＰＣと、さらに各衝突で浪費された時間とを低減するはずである。この場合、分析には、さらなるシグナリングのオーバーヘッドを含める必要があるはずである。
ＶＩ．理論とシミュレーションを比較すること
理論的なフレームワークの有用性を示すために、我々は、セクションＩＶで述べられた２ホップ無線ネットワークに対する分析を提供し、且つシミュレーションに対する比較を提供する。そのシステムにおいて、トラフィック形成は、ＧＡＰとＲＡＰの間で、アップリンク及びダウンリンクのトラフィック方向に対して行われる。集約されたパケットは、クライアントに転送される前にＲＡＰで集約を解除される。ＧＡＰも同様に、８０２．１１ネットワークの外側のクライアントに転送する前に集約を解除する。
シミュレーションのために、我々は、８０２．１１ｅ ＥＤＣＦパッケージで拡張されたｎｓ−２．２６を使用する［１９］。我々は、各ＲＡＰ及びＧＡＰにトラフィック形成機能及びバッファを追加した。バッファは、集約及びバースト送り機能の前にパケットを蓄積するために使用される。理論及びシミュレーションは共に、表Ｉのパラメータ値を用いる。一般的な場合、ＲＡＰは、ノード（ｋ＊）とすると、そのＣ（ｋ＊）クライアントのそれぞれから１つのパケットを取り、遅延させ、集約し、次いで、１つ又は複数のバースト送信を用いて、これらの集約されたパケットを（平均して、Ｄｓｍｓｅｃごとに１回）転送する。１つのクライアントは、１つのフローだけのメンバーである。

をノード（ｋ＊）によりサービスされるＳｋ＊中のすべてのアップリンクＲＡＰ→ＧＡＰフローのインデックスの組とする。その場合、そのＲＡＰはＣ（ｋ＊）クライアントにサービスするので、パラメータは、

を満足する。同様に、ダウンリンク方向では、ＧＡＰは、Ｄｓｍｓｅｃごとに各クライアントから１つのパケットを受け入れ、また共通のＲＡＰに向けられたこれらのものを、１つ又は複数のフローへとグループ分けする。簡単化のために、我々は、各ダウンリンクフローに、対応するアップリンクフローで使用されるのと同じ集約／バーストパラメータを有するように強制する。その例は、Ｈ（ｉ）＝１Ｍｂ／ｓ及び制限Ａｍａｘ＝８及びＭｍａｘ＝４を用いる。レートＲ（ｉ）＝１１Ｍｂ／ｓに対して、制約

は、最初のホップの制限を表す。すべてのコール上のＶｏＩＰパケットは、ＲＳ＝６４ｋｂ／ｓ及びＤｓ＝３０ｍｓｅｃでＣＢＲコーディングを用いて生成される。
過度に同期化されたトラフィックにより生ずるシミュレーション中の衝突を回避するために、［１６］で示すように、クライアントにおけるコールの開始時間をランダム化する。シミュレートされた音声容量の検討において、我々は、低いレベルのパケット損失は許容する。［１］の前の観察から、低いパケット損失制約を満足する２ホップシステムはまた、例えば、１５０ｍｓｅｃ未満のクライアントとＧＡＰ間のパケット化遅延を含む往復など、低い送信遅延を有する。したがって、シミュレーションによる容量の決定において、我々は、すべてのフロー上のパケット損失がシミュレーションにおいて１％未満である場合に限って、そのシナリオ（ＶｏＩＰコールカウント、関連するトラフィック形成、ＲＡＰなど）がサポート可能であると考える。そのシミュレートされたＶｏＩＰ容量は、その制約下で、最大のサポート可能なコール回数である。実際に、後で与えられるシミュレートされた容量値は、平均的な値であり、テストされた各サポート可能なシナリオは、異なる（ランダムな）クライアントの開始時間を有する複数のシミュレーションの実行を表す。
Ａ．容量分析：チャネル障害がなくバランスしている
我々はまず、我々のモデルにより予測された音声容量を、シミュレーションを通して得られたものと比較して、チャネル障害のない場合を考える。表ＩＩ、ＩＩＩ及びＩＶは、それぞれ、ジョイントされた集約及びバースト送り、集約だけ（すなわち、Ｂ（ｉ）＝１ ∀ｉ）、及びバースト送りだけ（すなわち、Ａ（ｉ、ｊ）＝１ ∀ｉ、ｊ）が使用される場合を要約している。簡単化のために、「バランスした」シナリオだけを提示することに限定していることにも留意されたい。ここで、我々は、クライアントがＲＡＰにだけ接続される（Ｎｃ＝０、Ｎｕ＝ＮＲ）こと、各ＲＡＰが、同じ数のクライアントにサービスすること、すべてのフローが同じ

を使用すること、及びバーストが、すべての送信されるパケットに対して、同じ集約レベル

を使用することを考える。（２２）の理論的な予測及びシミュレーションは共に、この制約を使用する。表は、各（バランスした）シナリオの最大数を達成する

及び

を示す。異なるＲＡＰが、異なるトラフィック形成パラメータを用いて、異なる数のクライアントをサポートする場合、多数のクライアントをサポートする場合を見出すこともできる。しかし、すべての場合を考慮する検索空間は、シミュレートし、提示するには大き過ぎる。

を可能にする表ＩＩにおけるジョイント選択肢の場合、コールをサービスするために、ＲＡＰは、１つのアップリンクＲＡＰ→ＧＡＰフローだけを使用し、またＧＡＰは、ＲＡＰごとに、１つのダウンリンクＧＡＰ→ＲＡＰフローだけを使用する。表ＩＩＩ及びＩＶに対しては、アップリンク及びダウンリンクをサポートするために、複数のフローがしばしば使用される、すなわち、｜ｕｋ｜＞１である。より多くのフローを使用することは、予測される（また示される）ように効率がより悪くなる。例えば、表ＩＩＩにおけるＮＲ＝１の場合に対する

など、限定的な場合を除いて、リレーで集約及びバースト送りを用いることによって、システムは、リレーが単純にパケットを転送する場合

又はすべてのクライアントがＧＡＰに直接接続された場合よりも、多くのさらなるクライアントをサポートできることが多いことを、表は示している。後者の場合では実際に、システムは１５コールをサポートできるだけである。これらのエラーのないシナリオでは、集約が、バースト送りよりもより効率的であることを見ることができる。我々はまた、これらの表から、シミュレーション結果と理論が非常によく合っているのを見ることができる。理論により提供される上限は、シミュレーションにより得られたシナリオ無視するものではない、すなわち、理論は、シナリオの実現可能な組を過大評価していることに留意されたい。すべての場合において、過大評価は、ＲＡＰ当たり１又は２の余分なコールの程度である。このような観察は、実際のシステムで使用するために、下限の負荷（上限の容量）値を調整するのに必要な、セクションＩＶ−Ｂで述べられたヘッドルーム「δ」をガイドするために使用することができる。いくつかの差（部分的な）は、バランスした場合だけを考慮する制約に起因している。
我々は、「バランスしていない」場合を検討していない。ここで、表ＩＩＩのＮＲ＝１１の場合のように、いくつかのノードが、他のものよりもわずかに高い集約レベルを使用する場合、そのシミュレーション及び理論は共に、サポートされるより多くのコールを可能にするはずであると予測することができる。さらに、エラーのない動作の下で、且つ所与のバーストレベル

に対して、一方が、

を有し、他方が、

を有するその２つのシナリオが、

である場合に、同じ負荷を有することに留意されたい。
例えば、シミュレートされた

を有するＮＲ＝４のバランスした場合は、Ａ（ｉ、１）＝Ａｍａｘ＝８、及びＡ（ｉ、２）＝２の場合と同じ負荷を有する。両方の場合は、したがって実現可能である。
Ｂ．シンボルエラーを有する集約及びバースト送りのトレードオフ
チャネル障害を有する場合、トラフィック形成の影響を再評価する必要がある。図５は、５・１０−４のｉ．ｉ．ｄ．のＳＥＲレートを有する、モデルで予測された性能対シミュレーションで得られた性能を示す。我々は、高いレベルのチャネルエラーがある場合、我々の提案するモデルは、シミュレートされた容量に対して、よく一致した容量に対する上限を提供できることが分かる。見られる差は、前と同様に、ＲＡＰ当たり１又は２の余分のコールの程度であることが多い。表ＩＩからＩＶのエラーのない場合と比較すると、図５のＳＥＲ＝５・１０−４の場合は、特に高レベルの集約から利益が得られるエラーのないスキームに対して低い音声容量を有する。実際に、より長い集約されたパケットは、より高いパケット損失レートを有する。それとは反対に、バースト送りだけのスキームに対する性能の相対的な劣化は少ない。
Ｃ．ＰＨＹレイヤのレート適応
前のセクションにおける観察は、エラーが存在する場合、低い集約レベル及び高いバースト送りレベルを用いることが好ましい可能性のあることを示唆している。我々はいまや、さらにＰＨＹレート、Ｒ（ｉ）の適応を可能にする場合、このような適応がどのように有用であるかを調べる。図６は、Ｒ（ｉ）＝２、５．５及び１１Ｍｂ／ｓを用いるＮＲ＝４の場合、広範囲なＳＮＲ（信号対雑音比）に対する音声容量を示す。２．０及び５．５Ｍｂ／ｓの場合、その制限

は、使用されるそれぞれの最初のホップの制限を表すことに留意されたい。すべての場合では、Ｈ（ｉ）＝１Ｍｂ／ｓである。
図は、「バランスした場合」だけを示している。いくつかの点が、対応するＳＥＲ、及び音声容量を最大化する選択された「バランスした場合」のパラメータ

でラベル付けされている（低いＳＥＲでは、「バランスした場合」の値は、セクションＶＩ−Ａで述べたように、他の「バランスしていない場合」の値の実現可能性を予測する。）。図が示していることは、特定のＳＮＲ未満では、集約レベル及び音声容量が、２から３ｄＢのＳＮＲ範囲内で急激に落ちることである。この範囲を超えると、より低いＰＨＹレート

へと切り換えることが好ましい。１１Ｍｂ／ｓの場合でより高い最初のホップの制限（１５コール）が与えられた場合、６を超える集約レベルに増加させることなくＲＡＰ当たり最高で１２クライアントをＲＡＰがサービスできるようにするためには、バースト送りが有用である。実際に、高いＳＮＲでは、８を超えない集約レベルを用いて、Ｂ（ｉ）＝２で、いくつかのＲＡＰが１２を超えるユーザを許可できるようにすることが可能である。これは、「バランスした場合」だけを例示しているので示していない。２．０及び５．５Ｍｂ／ｓのバランスした場合については、最初のホップの低い制限を考えると有用性は低い。さらに、いくつかのＲＡＰが７未満のユーザにサービスできるバランスしていない場合では、５．５Ｍｂ／ｓの他のＲＡＰは、Ａ（ｉ、ｊ）＜７でＢ（ｉ）＞１を用いることから利益を得ることができ、可能な限り低いＡ（ｉ、ｊ）で、最高７ユーザをサービスする。その設定は、

リンクで体験されるＳＥＲと、他のＲＡＰにより寄与された負荷に依存する。所与の設定の実現可能性は、単に、すべての通信グループにわたる対応する負荷に対するテストである。
しかし、このような観察が実際にどのように使用されるかは、レート適応機構に依存している。多くのシステムは、既存のＰＨＹレート適応機構を有する。これらの機構は、音声容量の急激な落ち込みの前に、低いＳＥＲ、例えば、ＳＥＲ＜１０−５の切換えを維持する場合、レート適応機構は独立して動作し、またシステムは、最小のＳＥＲレートに従って、単にＢ（ｉ）及びＡ（ｉ、ｊ）を設定することもできる。例えば、チャネル強度測定などを介してＳＥＲにアクセスがある場合、また適応機構に対してアクセスがある場合、Ｂ（ｉ）、Ａ（ｉ、ｊ）、及びＲ（ｉ）のより細かな適応を用いて容量を増加できる２から３ｄＢのＳＮＲ領域が存在する。
ＶＩＩ．ネットワーク管理
我々の前の分析及び結果はいままで、２ホップ無線メッシュネットワークを計画し、且つ管理することにおけるいくつかの重要な観察を明らかにしている。その結果から我々が引き出すことのできる鍵となる結論の１つは、いくつかのリレーノードを有するシステムを考えると、リレー中のすべての無線ユーザを等しく共用するために、単純な負荷バランシング手法を盲目的に適用すべきではないことである。例えば、１０のリレーノードを有するネットワークがあり、サポートすべき４０のＶｏＩＰユーザが存在すると仮定する。ブルートフォース負荷バランシングは、リレーごとに４ユーザを割り当てようとするはずである。しかし、表ＩＩ（バランスした場合）によれば、バランスしたシステムは、１０個のリレーノードが使用される場合、３０個の音声コールだけをサポートすることができる。設定

は、すべてのリレーが同じ数のユーザを有するようにして最大容量を可能にするが、これらの１０ＲＡＰのそれぞれに対して、

のコールをつなぐことは実現可能なシナリオではない。しかし、我々の結果は、４０のＶｏＩＰユーザをサポートできる他のシナリオがあることを示している、すなわち、

である。したがって、よりよい手法は、負荷バランシングを実施する前に、ＮＲのよい選択肢を特定することにある。
上記の例に関係する留意すべき他の点は、事前対応的にＲＡＰを用いることにより、システムがサポートできるコール数を増加できることである。実際に、図２では、通信グループが、ＧＡＰと重なる地理的な領域をカバーするが異なる周波数チャネルを使用するシナリオを考えることができる。したがって、ＲＡＰは、多くの短い非効率的な送信の収集装置として働き、したがって、トラフィック形成を介してＧＡＰへの送信負荷を低減する。
システムを管理するためにシステム負荷計算を使用することは、その目的に依存する。合計のシステム負荷を最小化したい場合、すなわち、ｍｉｎΣｇＴｇ、ユーザを、可能な場合、まずＧＡＰへと許可し、次いで、最初のホップＲＡＰへと許可することによって、ホップ数を制限する戦略は理にかなっている。例えば、図１（ａ）では、ユーザ１、ユーザ２、及びユーザ３は、Ｇ１又はＧ２に許可されるはずである。ＧＡＰの最大の負荷を最小化したい場合、まずいくつかのユーザをリレーへと許可することは役に立つ。ここで、図１（ａ）で、他のユーザが存在しない場合、ユーザ２及び３に対する集約されたフローをサポートするために、

を用いて、ユーザ２及び３をＲＡＰ１に許可すること、及びユーザ１をＧ１に許可することは、よい選択肢になり得る。ｍａｘｇＴｇを最小化したい場合、ユーザ１及び２及び３を許可し、且つ経路指定することは、システム中の既存のユーザ及びフローに依存する。すべての場合において、あるユーザに対するアドミッション／経路指定の選択肢の実現可能性は、そのアドミッション／経路指定に対するすべての可能な集約及びバースト送り選択肢を検討することにより行うことができる。この後に、Ｔｇ≦（Ｄｓ−δ）∀ｇを満足し、且つ上記で述べたさらなる目的を満たすものを見出すための組合せのテストが行われるはずである。
ＶＩＩＩ．結論
この論文では、マルチホップ８０２．１１無線ネットワークを介して、ＶｏＩＰトラフィックを効率的に送信する問題を調べる。具体的には、リレーにおいて、集約及びバースト送りを使用することにより、またこのようなトラフィック形成戦略を、ＰＨＹレート適応、アドミッション、及び経路指定とジョイントさせて検討することにより得ることのできる利点を調べる。我々は、実際に、ＲＡＰにおける集約及びバースト送りが、ネットワークがサポートできるＶｏＩＰクライアントの数を実質的に増加できることを示す。さらに、ネットワークを管理する全体の目標、例えば、ネットワークによりサポート可能なクライアント数を最大化する、ＧＡＰ上の負荷を最小化する、ネットワーク全体の合計負荷を最小化するなどに依存して、トラフィック形成及びアドミッション／経路指定をジョイントさせて検討することは、利益を生む可能性がある。
しかし、このようなジョイントの最適化を行うことにおける１つの問題は、中程度のサイズのネットワークであっても、検討されるべき多数の可能性のあるパラメータ及び決定の組合せが存在することである。シミュレーションを通して、このような組合せをすべて網羅的に検討することは、実際的ではないことが多い。我々は、集約、バースト送り、及びＰＨＹレート選択に応じて、ネットワーク中の各無線資源上の負荷を分析するために使用できる理論的なフレームワークを提供する。このフレームワークにより、我々は、可能性のある利益及びＶｏＩＰ容量の制限を調べることが可能になる。それはまた、このようなネットワークの動作を計画し管理するために使用できるツールを提供する。
我々のシミュレーションは、２ホップトポロジを有するバランスしたシナリオに焦点を当てているが、得られた洞察及び使用された方法の多くは、より一般的なネットワーク、及びバランスしていない場合に対して適用することができる。直接検討していない１つの問題は、背景トラフィックの異なるタイプとＶｏＩＰとの共存であるが、このようなトラフィックの検討は、セクションＩＩＩ−Ｃで述べられたもので説明することができる。将来の研究に対する他の拡張は、衝突からの損失を低減するために使用できる、また隠れノードが存在する場合のモデル化を簡単化するために使用できるＲＴＳ／ＣＴＳ機構を直接含むことである。トラフィック形成及びＰＨＹレート適応をジョイントさせた最適化、及びアドミッション及び経路指定の影響のさらなる検討が、マルチホップ８０２．１１システムで、大幅な利益を生むことができるという基礎となる観察が、このようなすべての拡張に共通している。
REFERENCES
[1] C. Pepin, U. C. Kozat, and S. A.Ramprashad, "A Joint Traffic Shaping and Routing Approach to Improve thePerformance of 802.11 Mesh Networks," in 4th Int. Symp. on Modeling andOptimization of Mobile, Ad Hov,and Wireless Networks (WiOPT), Boston, MA, April 2006.
[2] "TGn Sync Proposal for 802.1In," http://www.tgnsync.org/techdocs.
[3] "WWiSE proposal for 802.11n,"http: //www.wwise. org/technicalproposal.htm.
[4] S. Lawrence, A. Biswas, and A. A.Sahib, "A Comparative Analysis of VoIP Support for HT TransmissionMechanisms in WLAN," in IEEE Int. Conf. on Dist. Computing SystemsWorkshops, June 2007.
[5] C. Liu and A. P. Stephens, "AnAnalytic Model for Infrastructure WLAN Capacity with Bidirectional FrameAggregation," in Wireless Comm. and Net. Conf. (WCNC), March 2005, pp.113-119.
[6] D. Niculescu, S. Ganguly, K. Kim, andR. lzmailov, "Performance of VoIP in a 802.11 wireless mesh network,"in Int. Conf. on Wireless Communications and Mobile Computing, Vancover, BC, July2006, pp. 869 - 874.
[7] IEEE Computer Society, "Part 11:Wireless Medium Access Control (MAC) and Physical Layer (PHY) Specifications:Medium Access Control (MAC) Enhancements for Quality of Service (QoS),"2005, IEEE Std. 802.11eD13.0.
[8] W. Wang, S. C. Liew, and V. O. K. Li,"Solutions to Performance Problems in VoIP over a 802.11 WirelessLAN," IEEE Transactions on Vehicular Technology, vol. 54, no. 1, January2005.
[9] K. Medepalli, P. Gopalakrishnan, D.Famolari, and T. Kodama, "Voice capacity of IEEE 802.11b, 802.11a and802.11g Wireless LANs," in IEEE GLOBECOM, Dallas, Texas, Nov. 2004.
[10] D. Hole and F. Tobagi, "Capacityof an IEEE802.11b WLAN Supporting VoIP," in IEEE ICC, Paris, France, June 2004.
[11] K. Medepalli, P. Gopalakrishnan, D.Famolari, and T. Kodama, "Voice Capacity of IEEE802.11b and 802.11aWireless LANs in the Presence of Channel Errors and Different User DataRates," in IEEE VTC, Los Angeles, CA, Fall 2004.
[12] J. Zhu and S. Roy, "A 802.11 Based Dual-Channel Reservation MACProtocol for In-Building Multihop Networks," Springer Mobile Networks and Applications, vol. 10,no. 5, 2005.
[13] A. Raniwala and T. Chiueh,"Architecture and Algorithms for an IEEE 802.11-Based Multi-ChannelWireless Mesh Network," in IEEE INFOCOM, Miami, FL, March 2005.
[14] R. Draves, J. Padhye, and B. Zill,"Routing in Multi-Radio, Multi-Hop Wireless Mesh Networks," in ACMMobicom, Philadelphia, PA, Sept. 26-Oct. 1 2004.
[15] ITU-T, "Pulse Code Modulation(PCM) of Voice Frequencies," ITU-T Recommendation G.711,1988 (Blue Book),1993.
[16] S. A. Ramprashad and C. Pepin, "Astudy of silence suppression and real speech patterns and their impact on VoIPcapacity in 802.11 networks," in IEEE Int. Conf. on Multimedia and Expo,Beijing, China, July 2007, pp. 939-942.
[17] G. Bianchi, "Performance analysisof the IEEE 802.11 distributed. coordination function," IEEE JSAC, vol.18, 2000.
[18] IEEE Computer Society, "Part 11:Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) specifications:Higher-speed Physical Layer (PHY) extension in the 2.4 GHz band," IEEEStd. 802.11b-1999 (R2003).
[19] "NS2 802.1le package,"http://www.tkn.tu-berlin.de/research/802.11e\_ns2.

本発明の一実施形態による、新しいユーザを許可するプロセスで、アドミッション、経路指定、及びトラフィック形成を考慮に入れる方法を示す図である。 本発明が適用可能なシステム２００を示す図である。 本発明が適用可能な代替のシステム３００を示す図である。 効率を改善するために、チャネル送信期間で集約及びバースト送りを共に使用する一例を示す図である。 木構造ではないが、本原理がさらに適用される２つのＧＡＰを有するシステムを示す図である。

Claims (26)

  1. ユーザをマルチホップ無線ネットワーク中に関連付ける方法であって、前記ネットワーク中の通信において、関連付けられたエンティティが１つ又は複数の数の無線資源と競合する、当該方法において、
    前記マルチホップネットワークにおける複数の通信グループを識別するステップであって、各通信グループが、無線端末、アクセスポイント、リレーアクセスポイント、及び、それらの関連付けられた無線通信の組に対応し、同じ無線資源と競合する、当該ステップと、
    各通信グループに対して、前記マルチホップネットワークで可能な経路指定及びトラフィック形成の選択肢、及び、前記通信グループのメンバーによる前記無線資源への競合ベースのアクセスのチャンネル又はタイムオーバーヘッドを考慮して、前記ユーザを前記通信グループと関連付けることの影響を評価するステップと、
    前記評価に基づいて、前記ユーザを前記通信グループの１つと関連付けるステップと
    を含む方法。
  2. 経路指定及びトラフィック形成の選択肢が、（ａ）前記マルチホップネットワークの１つ又は複数の構成、（ｂ）前記通信グループのメンバーシップ、（ｃ）前記ネットワークを通して得るルートパケット、及び、（ｄ）前記リレーアクセスポイントがそれらの個々の受信及び送信パケットを処理し、転送する方法、を変更することを含む、請求項１に記載の方法。
  3. 前記トラフィック形成選択肢が、正確な、統計的な、又はターゲット化された集約レベル及びバーストレベル、並びに物理レイヤのデータレートにより定義される集約及びバースト機構の１つ又は複数のものを含む、請求項２に記載の方法。
  4. 前記トラフィック形成選択肢が、ターゲット化されたパケット長、パケット生成のための平均時間、仮定の若しくは予測されるパケットエラーレート、及び所定数の送信機会内の送信確率のうちの１つ又は複数のものを含む、請求項３に記載の方法。
  5. 前記ユーザを許可することの前記影響を評価する前記ステップが、負荷値を計算するステップを含む、請求項２に記載の方法。
  6. 前記通信グループの前記負荷値にわたってメトリックを計算するステップをさらに含む、請求項５に記載の方法。
  7. 前記メトリックが、最大の負荷値、平均の負荷値、及びゲートウェイアクセスポイントへの経路のホップ数のうちの１つ又は複数のものを含む、請求項６に記載の方法。
  8. 負荷値を計算する前記ステップが、チャネル占有時間を計算するステップを含む、請求項５に記載の方法。
  9. 前記チャネル占有時間が、成功した送信及び不成功の送信に対して生じた前記時間の総計を含む、請求項８に記載の方法。
  10. 前記チャネル占有時間がさらに、肯定応答パケットを送るための時間を含む、請求項８に記載の方法。
  11. 前記経路指定及びトラフィック形成の選択肢が、既存のユーザを、前記マルチホップネットワークの通信グループ中に再度関連付けするステップを含む、請求項１に記載の方法。
  12. 前記ユーザを関連付けすることの前記影響を評価する前記ステップが、前記ユーザを許可する結果として、前記システムの安定性メトリックを決定するステップを含む、請求項１に記載の方法。
  13. 前記マルチホップネットワークが、１つ又は複数のリレーアクセスポイント、及び１つ又は複数のゲートウェイアクセスポイントを備える、請求項１に記載の方法。
  14. ユーザをマルチホップネットワーク中に関連付けるシステムであって、
    共用される資源にそれぞれが対応する、前記マルチホップネットワーク中の複数の通信グループと、
    （ａ）通信グループごとに、各通信グループのメンバーによって共用される資源と競合するアクセスを見積もった時間、サービスの品質、及び、前記マルチホップネットワークの構成におけるバリエーションを考慮して、前記ユーザを前記通信グループと関連付けることの影響を評価する手段、及び（ｂ）前記評価に基づいて、前記ユーザを前記通信グループの１つに関連付ける手段を有する制御エンティティと
    を備えるシステム。
  15. サービス上の考慮事項の前記品質が、経路指定及びトラフィック形成の選択肢を含む、請求項１４に記載のシステム。
  16. 前記トラフィック形成選択肢が、集約レベル、バーストレベル、及び物理レイヤのデータレートのうちの１つ又は複数のものを含む、請求項１５に記載のシステム。
  17. 前記トラフィック形成選択肢が、パケット長、パケット生成のための平均時間、パケットエラーレート、及び所定数の送信機会内の送信確率のうちの１つ又は複数のものを含む、請求項１６に記載のシステム。
  18. 前記ユーザを許可することの前記影響を評価する前記手段が、負荷値を計算する、請求項１５に記載のシステム。
  19. 前記通信グループの前記負荷値にわたってメトリックを計算することをさらに含む、請求項１８に記載のシステム。
  20. 前記メトリックが、最大の負荷値、平均の負荷値、及びゲートウェイアクセスポイントへの経路のホップ数のうちの１つ又は複数のものを含む、請求項１９に記載のシステム。
  21. 負荷値を計算することが、チャネル占有時間を計算することを含む、請求項１８に記載のシステム。
  22. 前記チャネル占有時間が、成功した送信及び不成功の送信に対して生じた前記時間の総計を含む、請求項２１に記載のシステム。
  23. 前記チャネル占有時間がさらに、肯定応答パケットを送るための時間を含む、請求項２１に記載のシステム。
  24. 前記構成におけるバリエーションが、既存のユーザを、前記マルチホップネットワークの通信グループ中に再度関連付けすることを含む、請求項１４に記載のシステム。
  25. 前記ユーザを関連付けすることの前記影響を評価する前記手段が、前記ユーザを許可する結果として、前記システムの安定性メトリックを決定する、請求項１４に記載のシステム。
  26. 前記マルチホップネットワークが、１つ又は複数のリレーアクセスポイント、及び１つ又は複数のゲートウェイアクセスポイントを備える、請求項１４に記載のシステム。
JP2009541626A 2006-12-14 2007-12-14 中間のホップにおいてトラフィック形成を考慮して、マルチホップ８０２．１１ネットワークにおけるアドミッション及び経路指定を管理するための方法及び装置 Active JP5027886B2 (ja)

Applications Claiming Priority (5)

Application Number Priority Date Filing Date Title
US87526906P 2006-12-14 2006-12-14
US60/875,269 2006-12-14
US11/956,141 US8089970B2 (en) 2006-12-14 2007-12-13 Method and apparatus for managing admission and routing in multi-hop 802.11 networks taking into consideration traffic shaping at intermediate hops
US11/956,141 2007-12-13
PCT/US2007/087677 WO2008076945A2 (en) 2006-12-14 2007-12-14 Method and apparatus for managing admission and routing in multi-hop 802 11 networks

Publications (3)

Publication Number Publication Date
JP2010514275A JP2010514275A (ja) 2010-04-30
JP2010514275A5 JP2010514275A5 (ja) 2011-01-27
JP5027886B2 true JP5027886B2 (ja) 2012-09-19

Family

ID=39527035

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2009541626A Active JP5027886B2 (ja) 2006-12-14 2007-12-14 中間のホップにおいてトラフィック形成を考慮して、マルチホップ８０２．１１ネットワークにおけるアドミッション及び経路指定を管理するための方法及び装置

Country Status (3)

Country Link
US (1) US8089970B2 (ja)
JP (1) JP5027886B2 (ja)
WO (1) WO2008076945A2 (ja)

Families Citing this family (26)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8089970B2 (en) * 2006-12-14 2012-01-03 Ntt Docomo, Inc. Method and apparatus for managing admission and routing in multi-hop 802.11 networks taking into consideration traffic shaping at intermediate hops
US20080151834A1 (en) * 2006-12-20 2008-06-26 Motorola, Inc. Method and apparatus for maintaining traffic flow in a mesh network
US8233905B2 (en) * 2007-06-15 2012-07-31 Silver Spring Networks, Inc. Load management in wireless mesh communications networks
US8559867B2 (en) * 2008-08-21 2013-10-15 Nokia Corporation Load status indicator for multihop relay system using distributed scheduling
TWI385976B (zh) * 2009-01-19 2013-02-11 Univ Nat Taiwan Science Tech 允入控制器及其方法與其多躍式無線骨幹網路系統
JP4754637B2 (ja) * 2009-03-24 2011-08-24 株式会社トヨタＩｔ開発センター 車載無線機
EP2247042A1 (en) * 2009-04-28 2010-11-03 Thomson Licensing, Inc. Device and method for computation of channel loss rate and collision loss rate of communication link(s) in a random access network
WO2010144973A1 (en) * 2009-06-19 2010-12-23 Cohda Wireless Pty Ltd Environment estimation in a wireless communication system
WO2011006661A2 (en) * 2009-07-15 2011-01-20 Nec Europe Ltd. Method for supporting admission control and/or path selection in a communication network and communication network
US8509193B2 (en) * 2009-07-21 2013-08-13 Microsoft Corporation Packet aggregation
CN102006580B (zh) * 2009-09-03 2013-11-06 中兴通讯股份有限公司 一种路由策略的获取方法及系统
US9603085B2 (en) 2010-02-16 2017-03-21 Qualcomm Incorporated Methods and apparatus providing intelligent radio selection for legacy and non-legacy applications
US9178965B2 (en) * 2011-03-18 2015-11-03 Qualcomm Incorporated Systems and methods for synchronization of application communications
KR101267467B1 (ko) 2011-12-28 2013-05-31 한국정보화진흥원 다중 무선망 환경에서 트래픽을 분산시키기 위한 단말 선택 방법
JP5695798B2 (ja) * 2012-03-28 2015-04-08 京セラ株式会社 通信装置、通信装置を有する電力管理システム、及び通信装置の制御方法
US9667536B2 (en) * 2012-10-16 2017-05-30 Cisco Technology, Inc. Network traffic shaping for Low power and Lossy Networks
JP6102461B2 (ja) * 2013-04-23 2017-03-29 富士通株式会社 通信装置、マルチホップ無線通信ネットワークシステム及び通信方法
CN104885411B (zh) 2013-09-10 2018-01-19 思飞信智能电网公司 一种减轻节点数据约束的方法及无线通信系统
US8743758B1 (en) 2013-11-27 2014-06-03 M87, Inc. Concurrent uses of non-cellular interfaces for participating in hybrid cellular and non-cellular networks
CN105981422B (zh) 2013-12-13 2020-06-30 艾姆巴奇公司 用于连结混合的蜂窝网络和非蜂窝网络的安全连接的方法和系统
US9552550B2 (en) * 2014-05-13 2017-01-24 Cisco Technology, Inc. Traffic shaping based on predicted network resources
EP3913863A1 (en) * 2015-03-20 2021-11-24 AirTies Belgium SPRL Method for evaluating a wireless link, respective device, computer program and storage medium
EP3831021A1 (en) 2018-07-27 2021-06-09 Gotenna Inc. VINEtm ZERO-CONTROL ROUTING USING DATA PACKET INSPECTION FOR WIRELESS MESH NETWORKS
CN109089334B (zh) * 2018-09-26 2021-10-22 东南（福建）汽车工业有限公司 车载网关控制器信号路由校验方法
JP6952726B2 (ja) 2019-01-07 2021-10-20 株式会社東芝 通信装置、通信方法、通信プログラム、および通信システム
CN109743213B (zh) * 2019-02-28 2021-08-13 腾讯科技（深圳）有限公司 一种网络切片处理方法和设备以及系统

Family Cites Families (26)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6389010B1 (en) 1995-10-05 2002-05-14 Intermec Ip Corp. Hierarchical data collection network supporting packetized voice communications among wireless terminals and telephones
US6442135B1 (en) * 1998-06-11 2002-08-27 Synchrodyne Networks, Inc. Monitoring, policing and billing for packet switching with a common time reference
US20050058149A1 (en) * 1998-08-19 2005-03-17 Howe Wayne Richard Time-scheduled and time-reservation packet switching
US6567378B1 (en) * 1998-12-24 2003-05-20 Genuity Inc. Cell discard scheme for IP traffic over a cell relay infrastructure
US6700869B1 (en) * 1999-10-01 2004-03-02 Lucent Technologies Inc. Method for controlling data flow associated with a communications node
US6501733B1 (en) * 1999-10-01 2002-12-31 Lucent Technologies Inc. Method for controlling data flow associated with a communications node
US6963575B1 (en) * 2000-06-07 2005-11-08 Yipes Enterprise Services, Inc. Enhanced data switching/routing for multi-regional IP over fiber network
AU2001296378A1 (en) * 2000-09-29 2002-04-08 The Regents Of The University Of California Ad hoc network accessing using distributed election of a shared transmission schedule
US7027449B2 (en) * 2000-10-10 2006-04-11 The Regents Of The University Of California Method for maintaining reservation state in a network router and resulting scalable integrated architectures for computer networks
US20040100903A1 (en) * 2002-11-25 2004-05-27 Seung-Jae Han Quality of service mechanisms for mobility access device
US7376122B2 (en) * 2004-02-23 2008-05-20 Microsoft Corporation System and method for link quality source routing
US20050246940A1 (en) * 2004-05-07 2005-11-10 Keith Jones Fishing lure for sinking presentation
US7616575B2 (en) * 2004-06-23 2009-11-10 Microsoft Corporation System and method for link quality routing using a weighted cumulative expected transmission time metric
US20080144493A1 (en) * 2004-06-30 2008-06-19 Chi-Hsiang Yeh Method of interference management for interference/collision prevention/avoidance and spatial reuse enhancement
ES2375705T3 (es) * 2004-09-06 2012-03-05 Telefonaktiebolaget L- M Ericsson (Publ) Comunicaciones de múltiples accesos sobre diversas tecnolog�?as de acceso.
US7539175B2 (en) * 2004-11-19 2009-05-26 The Trustees Of Stevens Institute Of Technology Multi-access terminal with capability for simultaneous connectivity to multiple communication channels
WO2006065896A2 (en) * 2004-12-17 2006-06-22 Meshnetworks, Inc. System and method for controlling congestion in multihopping wireless networks
JP4568598B2 (ja) * 2004-12-21 2010-10-27 株式会社エヌ・ティ・ティ・ドコモ 制御装置及び通信制御方法
KR100899751B1 (ko) * 2005-03-09 2009-05-27 삼성전자주식회사 통신 시스템에서 신호 중계 시스템 및 방법
US7626931B2 (en) * 2005-03-23 2009-12-01 Microsoft Corporation Systems and methods for coordinating wireless traffic for heterogeneous wireless devices
US20060239207A1 (en) * 2005-04-20 2006-10-26 Nokia Corporation Combined load balancing for overlay and ad hoc networks
US8339948B2 (en) * 2005-09-16 2012-12-25 Ntt Docomo, Inc. Method for improving capacity in multi-hop wireless mesh networks
CN1937615B (zh) * 2005-09-20 2012-01-25 株式会社Ntt都科摩 无线分布式网络中的媒体接入控制方法和装置
DE602006016479D1 (de) * 2005-12-15 2010-10-07 British Telecomm Anruf-zugangskontrolle in einem ad-hoc-netz
US8089970B2 (en) * 2006-12-14 2012-01-03 Ntt Docomo, Inc. Method and apparatus for managing admission and routing in multi-hop 802.11 networks taking into consideration traffic shaping at intermediate hops
KR101395562B1 (ko) * 2008-02-22 2014-05-16 삼성전자주식회사 다중 홉 중계 방식의 무선통신 시스템에서 전이중 중계 방식 사용시 기지국 및 중계기 간 간섭회피 방법 및 장치

Also Published As

Publication number Publication date
US8089970B2 (en) 2012-01-03
US20080144497A1 (en) 2008-06-19
WO2008076945A2 (en) 2008-06-26
WO2008076945A3 (en) 2008-08-14
JP2010514275A (ja) 2010-04-30

Similar Documents

Publication Publication Date Title
JP5027886B2 (ja) 中間のホップにおいてトラフィック形成を考慮して、マルチホップ８０２．１１ネットワークにおけるアドミッション及び経路指定を管理するための方法及び装置
KR100890481B1 (ko) 다중 라디오 라우팅을 위한 소프트웨어 구조 및 하드웨어추상화 계층 및 그를 제공하는 방법
KR100886060B1 (ko) 멀티호핑 통신 네트워크에서 노드간의 루트를 선택하기위해 정체-인식 라우팅 메트릭을 제공하기 위한 시스템 및방법
US7660285B2 (en) Traffic-aware routing in wireless networks
EP1911205B1 (en) Bandwidth allocation in a wireless network
Wu et al. SoftMAC: layer 2.5 collaborative MAC for multimedia support in multihop wireless networks
Azevêdo Filho et al. A packet aggregation mechanism for real time applications over wireless networks
Wu et al. SoftMAC: Layer 2.5 MAC for VoIP support in multi-hop wireless networks
Zou et al. A relay-aided media access (RAMA) protocol in multirate wireless networks
Romdhani et al. A cross-layer on-demand routing protocol for delay-sensitive applications
Charfi et al. New adaptive frame aggregation call admission control (AFA‐CAC) for high throughput WLANs
Zhang et al. An extended AODV protocol for VoIP application in mobile ad hoc network
Chowdhury et al. XCHARM: A routing protocol for multi-channel wireless mesh networks
Giacomazzi et al. Quality of service for packet telephony over mobile ad hoc networks
Zhao et al. Constructing efficient multi-hop mesh networks
Kassler et al. Voip packet aggregation based on link quality metric for multihop wireless mesh networks
Pease et al. Cross-layer signalling and middleware: A survey for inelastic soft real-time applications in MANETs
Ramprashad et al. An analysis of joint aggregation, bursting, routing, and rate adaptation for increasing VoIP capacity in multi-hop 802.11 networks
Dely Adaptive aggregation of voice over IP in wireless mesh networks
Le Back-Pressure Based Throughput Enhancement Algorithms for Cognitive Radio Networks
Tsuchiya et al. Analysis of maximum UDP throughput of short-hop string networks for VoIP applications
Zarai et al. Provision of quality of service in open wireless architectures
EP1783957A1 (en) Bandwidth allocation in a wireless network
Loyola et al. A new multi-channel mesh architecture with DCF-based inter-AP communication and radio-aware packet forwarding for IEEE 802.11-compliant WLANs
El-Azouzi et al. On extending coverage of umts networks using an ad-hoc network with weighted fair queueing

Legal Events

Date Code Title Description
A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20101203

A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20101203

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20120424

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20120531

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20120619

A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20120622

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20150629

Year of fee payment: 3

R150 Certificate of patent or registration of utility model

Ref document number: 5027886

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150

Free format text: JAPANESE INTERMEDIATE CODE: R150

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250