Microsoft Teamsのメディア品質とネットワーク接続パフォーマンス
Important
21Vianetが中国で運営するSkype for Businessオンラインは、2023年10月1日に廃止されます。 Skype for Business Online ユーザーをまだアップグレードしていない場合は、自動的に支援されたアップグレードがスケジュールされます。 organizationを自分で Teams にアップグレードする場合は、今すぐアップグレード パスの計画を開始することを強くお勧めします。 アップグレードが成功すると技術的な準備とユーザーの準備が整っていることを忘れないでください。そのため、Teams への旅を進める際には 、アップグレード ガイダンス を活用してください。
Skype for Businessオンラインは、21Vianet が中国で運営するサービスを除き、2021 年 7 月 31 日に廃止されました。
この記事では、Microsoft Teams サービスのネットワーク パフォーマンス要件のセットと、ネットワーク間の接続にインターネットまたは ExpressRoute を使用する方法と、ネットワーク接続の評価に基づいてMicrosoft Teamsを選択する方法について説明します。 Microsoft 365 または Office 365 への専用接続用に Azure ExpressRoute をデプロイすることにした場合、このドキュメントでは、さまざまなMicrosoft Teamsデプロイ シナリオで ExpressRoute 接続を計画する方法に関するガイダンスも提供します。
IP 経由の Real-Time メディア (オーディオ、ビデオ、アプリケーション共有) の品質は、エンドツーエンドのネットワーク接続の品質によって大きく影響されます。 メディア品質Microsoft Teams最適にするには、会社のネットワークとMicrosoft Teamsの間に高品質の接続があることを確認することが重要です。 これを実現する最善の方法は、ネットワークの容量に基づいて内部ネットワークとクラウド接続を設定し、すべての接続でMicrosoft Teamsのトラフィック量のピークに対応することです。
Azure ExpressRoute は、Microsoft 365 および Office 365 サービス (Microsoft Teamsを含む) の要件ではありません。 ただし、Azure ExpressRoute は、Microsoft 365 または Office 365 への接続がMicrosoft Teamsネットワーク パフォーマンス要件を満たし、最適なMicrosoft Teamsメディア品質エクスペリエンスを確保するのに役立つデプロイ オプションの 1 つです。
先端
このトピックでは全体的なネットワーク パフォーマンス ガイダンスを提供しますが、ネットワーク評価の完全なガイダンスはこのドキュメントの範囲外です。 完全かつ完全なネットワーク評価の一環としてネットワーク パフォーマンスの測定に役立つMicrosoft Teams パートナーの一覧については、Skype for Business パートナー ソリューションに関するページを参照してください。
Microsoft Teamsするネットワーク接続の要件
メディア品質に影響Microsoft Teams要因
Microsoft Teams Real-Timeメディア (オーディオ、ビデオ、アプリケーション共有) の品質には、使用されているデバイス、環境、ネットワーク接続など、さまざまな要因があります。
デバイス
Real-Time メディア セッションでは、ヘッドセットや Web カムなどのすべての参加者が使用するメディアキャプチャおよびレンダリング デバイスは、全体的なオーディオとビデオの品質に大きな影響を与えます。 低品質のデバイスまたはデバイスドライバーが正しくないと、オーディオの全体的な音質が低下し、ビデオの画質が低くなります。 認定されたデバイスまたは良質のデバイスは、エコーキャンセレーション、ノイズフィルタリング、ビデオ解像度、待機時間の短縮に役立ちます。
認定されたオーディオおよびビデオ メディア デバイスは必要ありませんが、最適なメディア エクスペリエンスを得るには、Microsoft Teamsの認定を受けたデバイスを強くお勧めします。 すべてのMicrosoft Teams認定デバイスの一覧については、「認定された Android デバイス Microsoft Teams」を参照してください。 Skype for Business管理センターにあるMicrosoft Teams通話品質ダッシュボードを使用して、使用中のデバイスが正しく動作していることを確認し、オーディオとビデオのメディア品質を監視できます。
先端
最適なSkype for Businessメディア品質エクスペリエンスを実現するために、認定されたデバイスが必要です。
メディア フローを Real-Time するメディア デバイス、Microsoft Teams クライアント、Skype for Business サーバーでは、ある程度の待機時間が発生することを覚えておく必要があります。 デバイスとソフトウェアの処理待機時間とネットワーク待機時間は、エンド ツー エンドの全体的な待機時間とエンド ユーザーのエクスペリエンスに大きな影響を与え、貢献します。
環境
ユーザーが会議を行い、オーディオおよびビデオ デバイスを使用している環境と周辺領域は、オーディオとビデオの品質のもう 1 つの大きな要因です。 ノイズの多い環境から呼び出すユーザーは、エコー、こもった、不明瞭な音声が表示されます。 暗くて照明が不十分な環境にいるユーザーは、ビデオで明るくクリアな画質を実現することができません。 会議室の設定では、マイクとビデオ デバイスの場所が、参加者が受け取るサウンドと画質に直接影響します。
ユーザーのオーディオとビデオのエクスペリエンスをより明確に把握するには、Skype for Business アプリツール>Options>Audio Device または Video Device を使用して、使用中のデバイスを変更し、その設定をカスタマイズします。
ネットワーク
IP ネットワーク経由の Real-Time メディアの品質は、ネットワーク接続の品質、特に次の量によって大きく影響されます。
潜在 これは、ネットワーク上のポイント A からポイント B までの IP パケットを取得するのにかかる時間です。 このネットワーク伝達遅延は、2 つのポイント間の物理的な距離と光の速度に関連付けられています。これには、その間のさまざまなルーターによって余分なオーバーヘッドが発生します。 待機時間は、一方向またはラウンドトリップ時間 (RTT) として測定されます。
パケット損失 これは、多くの場合、特定の期間に失われるパケットの割合として定義されます。 パケット損失は、オーディオの品質に直接影響を与えます。ほとんど影響を及ぼすことのない小規模のパケット損失から、音声が完全に途切れる原因となる連続したバースト損失まで存在します。
パケット間到着ジッターまたは単にジッター これは、連続するパケット間の遅延の平均変化です。 Microsoft Teamsを含む最新の VoIP ソフトウェアのほとんどは、バッファリングを通じて一部のレベルのジッターに適応できます。 ジッターがバッファリングを超えた場合にのみ、参加者はジッターの影響に気付きます。
注意
ジッターのバッファリングにより、エンドツーエンドの待機時間が長くなります。
同時Microsoft Teams Real-Timeメディア セッションが多数あり、他の Microsoft 365 または Office 365 サービスやその他のビジネス アプリケーションによって生成されるその他のネットワーク トラフィックにより、ネットワークをMicrosoft Teams サービスに接続するネットワーク パス全体に十分な帯域幅があることを確認することが、ネットワークの輻輳を回避し、優れたメディア Real-Time メディア (オーディオ、 ビデオ、およびアプリケーション共有) の品質。
混雑したネットワークにサービス品質 (QoS) を実装する
さらに、ネットワーク全体のトラフィックの輻輳は、メディア品質に大きな影響を与えます。 オーディオとビデオのパケットがネットワークをより迅速に移動し、混雑したネットワーク内の他のネットワーク トラフィックよりも優先されるようにするには、Quality of Service (QoS) を使用して、オーディオおよびビデオ通信に最適なエンド ユーザー エクスペリエンスを提供できます。
QoS を使用すると、オーディオまたはビデオ データを伝送するネットワーク パケットにより高い優先順位を割り当てることができます。 これらのパケットに高い優先順位を割り当てることにより、オーディオとビデオの通信は、ファイル転送、Web 閲覧、データベース バックアップなどのネットワーク セッションよりも、ネットワーク経由の移動速度が速く、中断が少なくなります。 これは、既定でファイル転送またはデータベース バックアップに使用されるネットワーク パケットには、優先順位として "ベスト エフォート" が割り当てられ、ネットワークの輻輳に大きな影響がないためです。 メディア (オーディオ、ビデオ、アプリケーション共有) パケットに高い優先順位を割り当てず、"ベスト エフォート" としても割り当てておくと、他のすべてのネットワーク トラフィックと共に処理されます。 ネットワークの輻輳の量によっては、ユーザーの全体的なオーディオとビデオの品質エクスペリエンスが低下する可能性があります。
ネットワーク内のネットワークの輻輳が影響を受けないように、ネットワークに QoS を実装することを強くお勧めします。 ただし、これが最大の影響を与えるためには、すべてのネットワーク エンドポイントが QoS をサポートする必要があります。つまり、すべてのエンドポイントが QoS マーキングとパケットの優先順位付けを遵守する必要があります。 Microsoft Teams サービスでは、Microsoft ネットワーク内での QoS マーキングと優先順位付けが適用されます。 ただし、会社のネットワークから Microsoft ネットワークにインターネットなどのパブリック接続を経由してルーティングされるトラフィックでは、QoS マーキングとパケットの優先順位付けが保持されません。 ネットワークから Microsoft 365 または Azure ExpressRoute を使用したOffice 365へのプライベート接続は、QoS マーキングとパケットの優先順位付けを保持するデプロイ ソリューションを提供します。これにより、エンド ユーザーの全体的なオーディオとビデオの品質が向上します。
Microsoft Teamsに接続するためのネットワーク パフォーマンス要件
Skype for Business Real-Timeメディアは、さまざまなデバイス、クライアント アプリ、サーバー ソフトウェア、さまざまなネットワークを経由して移動します。 Real-Time メディアのエンドツーエンドの待機時間は、すべてのコンポーネントとネットワーク セグメントに対して導入される待機時間の合計です。 エンドツーエンドネットワーク接続の品質は、最も品質の悪いネットワーク セグメントによって決定されます。 このセグメントは、このネットワーク トラフィックのボトルネックとして機能します。
次の図は、あるMicrosoft Teams参加者から別の参加者への会議内の一方向のオーディオ フローを示しています。
この会議シナリオでは、メディア パスは次のネットワーク セグメントで構成されます。
ユーザー 1 から Microsoft ネットワークの端への接続 これには通常、WiFi やイーサネットなどのネットワーク接続、ユーザー 1 からインターネットエグレス ポイント (ネットワーク エッジ デバイス)への WAN 接続、ネットワーク エッジから Microsoft ネットワーク エッジへのインターネット接続が含まれます。
Microsoft ネットワーク内の接続 これは、A/V 会議サーバーが使用されるデータ センター Microsoft Teams Microsoft Edge 間です。
Microsoft Network 内の接続 これは、Microsoft Teams データ センターと Microsoft ネットワーク エッジの間です。
Microsoft ネットワーク エッジからユーザー 2 への接続 これには、ネットワーク エッジから Microsoft ネットワーク エッジへのインターネット接続、ユーザー 2 からインターネットエグレス ポイント (ネットワーク エッジ) への WAN 接続、WiFi やイーサネットなどのネットワーク接続が含まれます。
次の図は、Microsoft Teams PSTN 通話のコンポーネントとネットワーク セグメントの内訳を示しています。
PSTN 通話シナリオでは、メディア パスは次のネットワーク セグメントを通過します。
Skype for Business クライアントの呼び出し元から Microsoft Network のエッジへの接続 通常、WiFi やイーサネットなどのネットワーク接続、Skype for Business クライアント呼び出し元からインターネットエグレス ポイント (ネットワーク エッジ デバイス)への WAN 接続、ネットワーク Edge から Microsoft ネットワーク エッジへのインターネット接続が含まれます。
Microsoft ネットワーク内の接続 これは、仲介サーバーが使用されるデータ センター Microsoft Teams Microsoft Edge 間です。
Microsoft Network 内の接続 これは、Microsoft Teams データ センターと Microsoft ネットワーク エッジの間です。
Microsoft Network と PSTN サービス プロバイダー パートナー間の接続これは、Microsoft ネットワークの外部にあるSkype for Business クライアントから PSTN 呼び出しを行うために存在する接続です。
Skype for Business クライアントから Microsoft network Edge へのネットワーク パフォーマンス要件
メディア品質Skype for Business最適にするには、会社のネットワークから Microsoft ネットワーク Edge への接続に対して、次のネットワーク パフォーマンス メトリックのターゲットまたはしきい値が必要です。 ネットワークのこのセグメントには、内部ネットワークが含まれます。これには、すべての WiFi とイーサネット接続、WAN 接続経由の会社のサイト間トラフィック (たとえば、マルチプロトコル ラベル スイッチング (MPLS))、Microsoft ネットワーク エッジへのインターネットまたは ExpressRoute パートナー接続が含まれます。
注意
会社のネットワーク上のSkype for Business クライアントと Microsoft 365 または Office 365 サービス間の接続は、次のネットワーク パフォーマンス要件としきい値を満たす必要があります。
| 測定基準 | 最適 | Poor |
|---|---|---|
| ラウンド トリップ時間 (RFC 3550) | < 60 ミリ秒 | > 500 ミリ秒 |
| 最大パケット損失 (RFC 3550) | < 5% | > 25% |
| 平均パケット損失 (RFC 3550) | < 0.5% | > 10% |
| パケット ジッター (RFC 3550) | < 3 ミリ秒 | > 30 ミリ秒 |
その他のパフォーマンス ターゲット要件:
Microsoft ネットワークには、世界中で 160 を超える Edge の場所があります。 Microsoft は、これらの Edge サイトを通じて、世界中の主要なインターネット サービス プロバイダー (ISP) と連携しています。 待機時間メトリック ターゲットは、会社のサイトまたはサイトが同じ大陸にあり、Microsoft Edge が同じ大陸にあると想定しています。
Microsoft ネットワーク Edge 接続への会社のサイトまたはサイトには、WiFi または別のワイヤレス テクノロジを使用できる最初のホップ ネットワーク アクセスが含まれます。
ネットワーク パフォーマンス ターゲットは、適切な帯域幅やサービス品質の計画を想定しています。 つまり、これは、ネットワーク接続がピーク負荷の下にある場合Skype for Business Real-Timeメディア トラフィックに直接適用されます。
ネットワーク パフォーマンスの測定
任意の会社のネットワーク サイトからネットワーク Edge への待機時間とパケット損失に関する実際のネットワーク パフォーマンスを測定するには、ping などのツールを使用し、Microsoft Edge サイトとデータ センター サイトから実行されている一連のSkype for Business メディア リレー サービスに対してテストできます。
注意
ping (ICMP) を使用したネットワーク パフォーマンスの測定は有効ではありません。 そのため、次に示すエニーキャスト IP は、2020 年 1 月から ICMP 要求への応答を停止します。 ネットワークパフォーマンスを効果的に測定するために、Microsoft は ネットワーク Assesment ツールを推奨します。
Microsoft ネットワークへのインターネット接続をテストするには、Skype for Business メディア リレーの次の VIP に対してテストすることをお勧めします。 Anycast VIP は、テストの場所に最も近い Microsoft ネットワーク Edge サイトの Media Relay の IP アドレスに解決されます。
|
IPアドレス |
Type |
場所 |
|---|---|---|
| 13.107.8.2 |
要人 |
World Wide Anycast IP |
ネットワーク パフォーマンスを評価するために従う必要がある高レベルの推奨事項を次に示します。
内部ネットワークと、Microsoft 365 または Office 365 への接続を評価する必要があります。
長期間にわたって、すべてのネットワークのデータを評価して収集する必要があります。 すべての営業日と時間の使用パターンを確認できるように、ネットワーク パフォーマンスのテストを少なくとも 1 週間実行することをお勧めします。 これにより、ピーク時が表示されます。
ネットワーク パフォーマンス測定の複数のサンプルを取る必要があります。 データを収集する期間中は、会社のサイトから 10 分ごとに測定を行うことをお勧めします。 Microsoft Teamsネットワーク パフォーマンス要件を比較するには、このサンプル データ セットから 90 パーセンタイル測定値を取得します。
ネットワークのパフォーマンスを継続的に評価する必要があります。 ネットワーク使用率は、使用パターンの変更、大量の帯域幅を使用する新しいエンタープライズ ベースのアプリケーション、組織または物理的な会社の場所の変更により、時間の経過とともに異なります。 これらのネットワーク パフォーマンス要件とターゲット/しきい値に対してネットワーク パフォーマンスを継続的に監視し、最適な Real-Time メディア品質を確保するためにタイムリーに調整することが重要です。
Azure VM を使用したネットワーク パフォーマンスの測定
Microsoft ネットワーク エッジ サイトに対してテストする代わりに、Microsoft Azure クラウド内のサービスのテストセットアップを使用するSkype for Business顧客やパートナーからのネットワーク評価ソリューションがあります。 これらのソリューションでは、ネットワーク評価ツールは、Azure クラウドでサービスとして設定されたカスタム エンドポイントに対して待機時間、パケット損失、ジッターをテストします。 その結果、テスト ネットワーク トラフィックは他の 1 つのネットワーク セグメントを通過します。これは、ネットワーク エッジとネットワーク評価サービスをホストする Azure データ センター間の Microsoft ネットワーク内の接続です。
Azure でホストされているテスト サービスに基づくネットワーク評価ソリューションの場合。 国または地域内でネットワーク評価を実行することをお勧めします。 たとえば、米国東部の顧客サイトの場合、評価は、Azure の米国東部データ センター リージョンでホストされているテスト サービス インスタンスに対して実行する必要があります。
Azure サービス ベースのネットワーク評価セットアップの待機時間 (RTT) ターゲットを次に示します。 一方向の待機時間のターゲットは、対応する RTT ターゲットの半分になります。 パケット損失とジッターの目標は、Skype Media Relay ベースのテストで定義されているものと同じままです。
|
顧客リージョン |
Azure リージョン |
ネットワーク エッジ - Azure ラウンドトリップ時間 (RTT) |
サイト - Azure ラウンドトリップ時間 (RTT) |
|---|---|---|---|
| 米国中部 |
米国中部 |
99 |
139 |
| 米国東部 |
米国東部 |
86 |
126 |
| 米国中北部 |
米国中北部 |
97 |
137 |
| 米国中南部 |
米国中南部 |
94 |
134 |
| 米国西部 |
米国西部 |
94 |
134 |
| ハワイ米国 |
米国西部 |
116 |
156 |
| カナダ中部 |
カナダ中部 |
138 |
178 |
| カナダ東部 |
カナダ東部 |
131 |
171 |
| 北ヨーロッパ |
北ヨーロッパ |
99 |
139 |
| 西ヨーロッパ |
西ヨーロッパ |
95 |
135 |
| 東アジア |
東アジア |
118 |
158 |
| 東南アジア |
東南アジア |
97 |
137 |
| 東日本 |
東日本 |
111 |
151 |
| 西日本 |
西日本 |
118 |
158 |
| ブラジル南部 |
ブラジル南部 |
70 |
110 |
| オーストラリア東部 |
オーストラリア東部 |
124 |
164 |
| オーストラリア南東部 |
オーストラリア南東部 |
124 |
164 |
| インド中部 |
インド中部 |
103 |
143 |
| インド南部 |
インド南部 |
103 |
143 |
| インド西部 |
インド西部 |
103 |
143 |
| 中国東部 |
中国東部 |
120 |
160 |
| 中国北部 |
中国北部 |
120 |
160 |
メディア品質と ExpressRoute
Azure ExpressRoute for Microsoft 365 または Office 365 は、Microsoft 365 または Office 365に接続するための専用ネットワーク接続です。 お客様は、ネットワーク トラフィックのパスを制御できます。 データが不明な通信事業者、プロバイダー、ISP によって運ばれるインターネット上で発生する予測不可能なルーティングに関心を持つ必要はなくなりました。 ExpressRoute 経由で送信されるネットワーク トラフィックは、ExpressRoute パートナーのネットワーク経由で Microsoft のネットワークに直接送信されます。 これにより、お客様は、Microsoft 365 または Office 365を、専用接続を備えた独自のオフサイト データ センターにあるかのように扱うことができます。
Azure ExpressRoute は、すべての Microsoft 365 および Office 365 ライセンス オファリングで利用できます。 ただし、グローバル ルーティングを有効にするには、Microsoft 365 とOffice 365に Azure ExpressRoute Premium アドオンが必要です。 ExpressRoute を実装しているシートが 500 以上のお客様は、必要な ExpressRoute Premium アドオン を追加料金なしで取得できます。
適切なメディア品質を実現するために ExpressRoute は必要ですか?
Azure ExpressRoute は、メディア品質を最大限にMicrosoft Teamsするための要件ではありません。 ただし、クラウド接続がSkype for Businessネットワーク パフォーマンスのターゲットまたはしきい値を満たしていることを確認するのに役立つデプロイ オプションの 1 つです。
Microsoft 365 とOffice 365は、インターネットを使用する高パフォーマンスでセキュリティで保護されたサービスです。 Microsoft は、セキュリティとパフォーマンスを継続的に向上させるために、新しいセキュリティ機能とリージョンエッジ ノードに投資し続けます。 Azure ExpressRoute は、Microsoft 365 または Office 365 サービス (Microsoft Teamsを含む) の要件ではありません。 Azure ExpressRoute は、Microsoft 365 または Office 365 への接続がSkype for Businessネットワーク パフォーマンス要件を満たし、メディア品質の最適なMicrosoft Teamsエクスペリエンスを確保するのに役立つデプロイ オプションの 1 つです。
Microsoft Teamsメディア品質のためには、会社のサイトと Microsoft ネットワーク エッジの間の接続が、Skype for Business クライアントから Microsoft ネットワーク エッジへのネットワーク パフォーマンス要件のパフォーマンス 目標を満たし、ネットワーク エッジと Microsoft ネットワーク エッジ間の接続がパフォーマンス 目標を満たすことが重要です。
また、社内ネットワークやクラウド接続容量など、会社の物理ネットワーク接続が、メディア トラフィックのピーク量に対応することも重要です。 Azure ExpressRoute は、Microsoft Teams クラウド接続がこれらのパフォーマンス要件をすべて満たしていることを確認するのに役立つさまざまな方法の 1 つです。
音声品質 SLA には ExpressRoute が必要ですか?
いいえ。ExpressRoute は、Microsoft Teams音声品質 SLA には必要ありません。 Microsoft Teams音声品質 SLA は、適切なライセンスとサブスクリプション内の任意のMicrosoft Teams音声サービス ユーザーが行った適格な通話に適用されます。これにより、そのユーザーは任意の種類の VoIP または PSTN 通話を行うことができます。 音声品質 SLA には、次のすべての条件に対処する必要があります。
Microsoft 認定 IP 電話からの通話。
有線イーサネット接続。
Microsoft ネットワークの問題による音声品質の問題。
注意
音声品質 SLA では、ExpressRoute パートナーやその他のネットワークを含む Microsoft 以外のネットワークの問題によって低い通話品質が引き起こされる通話は除外されます。
インターネットまたは Azure ExpressRoute?
Microsoft Teamsへのネットワーク接続オプションを決定する前に、「Microsoft Teamsに接続するためのネットワーク パフォーマンス要件」で説明されているネットワーク パフォーマンス要件に基づいて、ネットワークと現在のインターネット 接続を評価する必要があります。
現在のインターネット接続に対するネットワーク パフォーマンスがピーク時に十分な容量に設定されており、サイトから Microsoft ネットワーク エッジ、ネットワーク エッジから Microsoft ネットワーク エッジまでのネットワーク パフォーマンス要件を満たしている場合は、既存のインターネット接続を引き続き使用してMicrosoft Teamsに接続できます。
ネットワーク パフォーマンス要件が満たされていない会社サイトの場合は、最初に既存のネットワーク サービス プロバイダーと連携して、全体的なネットワーク パフォーマンスを向上することを強くお勧めします。 ただし、まだ満たされていない場合は、Azure ExpressRoute を使用すると、Microsoft Teamsクラウド接続がネットワーク パフォーマンス要件を満たすのに役立ちます。
Azure ExpressRoute には、次の追加の利点があります。
ネットワークと Microsoft ネットワーク間の接続の可用性に関するサービス レベル アグリーメント (SLA)。 ExpressRoute の可用性 SLA は 99.9% です。
Microsoft 365 および Office 365 サービスに必要な計画済みおよび保証された帯域幅。 これを実現するには、ExpressRoute を使用して Microsoft 365、Office 365、またはSkype for Businessトラフィックのみを送信し、その他のすべてのインターネット トラフィックがネットワークの他のインターネット エグレス ポイントを経由します。
ExpressRoute は、ネットワークと Microsoft ネットワークの間で DSCP QoS マーキングを保持するように設計されています。
ExpressRoute QoS と容量計画の詳細については、 Microsoft Teamsの ExpressRoute と QoS に関するページを参照してください。
Microsoft Teams専用に Azure ExpressRoute を設定できますか?
はい。Azure ExpressRoute を設定して、会社のネットワークからMicrosoft Teamsのみに優れたネットワーク接続を確保できます。 これにより、ユーザーに最適な Real-Time メディア品質が提供されますが、インターネット経由で他の Microsoft 365 または Office 365 サービスに引き続き接続できます。
Border Gateway Protocol (BGP) は、インターネット経由でネットワーク トラフィックをルーティングするために使用されるインターネット上のルーティング プロトコルです。 インターネット経由で見つかった自律システム (AS) 間でルーティング情報を交換するように設計されています。 BGP コミュニティの値は、受信ルートまたは発信ルートに適用できる属性タグです。 BGP コミュニティは、多くの場合、受信 AS に信号を送信するために使用されます。この送信リンクは、地域、サービスの種類、またはその他の条件に基づいて特定の宛先に到達するために使用します。
BGP コミュニティのサポートにより、Microsoft はプレフィックスとルートに、所属するサービスに基づいて適切な BGP コミュニティ値にタグを付けます。 Microsoft は、パブリック ピアリングと Microsoft ピアリングを通じてアドバタイズされたプレフィックスに、プレフィックスがホストされているリージョンを示す適切な BGP コミュニティ値にタグを付けます。 最適なルーティングを提供するために、コミュニティの値に依存して適切なルーティングの決定を行うことができます。 Microsoft Teams BGP コミュニティ値を使用して、Microsoft Teamsに対してのみ ExpressRoute 接続を設定できます。 詳細については、 ExpressRoute ルーティング要件に関するページを参照してください。
Microsoft Teamsの ExpressRoute 接続シナリオ
上記の推奨事項に基づいて ExpressRoute が適していると判断した場合は、取得する必要がある ExpressRoute 接続の場所と数に関する推奨事項を次に示します。
オンラインのみの展開 - 単一サイト
すべてのユーザーが Microsoft Teams サービスを使用し、オフィスが 1 つの物理的な場所を中心にしていて、Azure ExpressRoute をデプロイする場合は、会社サイト間の 1 つの ExpressRoute 接続を最も近い ExpressRoute ピアリングの場所に設定する必要があります。
次の図は、この種類のデプロイの例を示しています。 この例では、Contoso はフロリダ州オーランドにある大学です。 Contoso には 10,000 人の教職員と学生がいます。 場所から Microsoft Edge サイトへのインターネット テストでは、ピーク クラスの時間中に 5% を超えるパケット損失が発生しました。 Microsoft 365 または Microsoft Teams Real-Time トラフィックの特にOffice 365のネットワーク輻輳を回避できるように、過剰にプロビジョニングされた帯域幅を持つ ExpressRoute を使用して、Microsoft 365 または Office 365 への専用接続を取得することにしました。 これらのユーザーは、アトランタの GA MeetMe サイトにある ExpressRoute を介して Microsoft クラウドに接続します。
オンラインのみの展開 - 同じ大陸の複数のサイト
会社が同じリージョンまたは大陸の複数のオフィスのMicrosoft Teams サービスを使用していて、Azure ExpressRoute の実装を選択した場合は、ExpressRoute 経由でメイン サイトを接続し、必要に応じて、推奨されるネットワーク パフォーマンス ターゲットを満たしていない他の場所に対して ExpressRoute ピアリングを追加することをお勧めします。
次の例では、Contoso はニューヨークに本社を置き、米国全体に他のオフィスを持つ米国の旅行サービス会社です。 オフィスは、MICROSOFT 365 または Office 365 への接続に MPLS を使用する WAN を介して相互に接続されています。 最初に、ニュージャージー州ホーボーケンのインターネット ルーターからニューヨーク MeetMe サイトへの ExpressRoute 接続を設定しました。
この設定により、ほとんどのサイトから Microsoft Network (New York Edge サイト) へのネットワーク トラフィックは、「Skype for Business クライアントから Microsoft ネットワーク エッジへのネットワーク パフォーマンス要件」で説明されているSkype for Businessクライアント接続ネットワーク パフォーマンス ターゲットを満たすことができます。 ただし、Contoso の西海岸オフィスからニューヨークへの待機時間は、一方向に 50 ミリ秒を超えています。 さらに、ホノルルは Contoso にとって 2 番目に大きなオフィスであり、ホノルルからニューヨークまでの待機時間は、片道 80 ミリ秒を超えています。 Contoso は、これらのオフィスのユーザーにとって優れたメディア品質を確保するために、サンノゼ サイトとシリコン バレー ExpressRoute MeetMe サイトの間に、西海岸の ExpressRoute 接続を追加することにしました。
オンラインのみの展開 - 異なる大陸の複数のサイト
すべてのユーザーがMicrosoft Teamsサービスを使用していて、オフィスが複数の大陸にまたがる複数の物理的な場所にある場合、Azure ExpressRoute をデプロイする場合は、各大陸のメイン サイト間の各大陸に対して少なくとも 1 つの ExpressRoute 接続を、最も近い ExpressRoute ピアリングの場所に設定する必要があります。 コストとメリットに応じて、ネットワーク パフォーマンスのターゲットが満たされていないサイトから追加の ExpressRoute 接続を展開することを選択できます。
次の例では、Contoso は、北米とヨーロッパの主要都市にオフィスを持つ大企業の法律事務所です。 Contoso は、インターネット接続と内部ネットワーク パフォーマンス評価に基づいて、北米に 2 つの ExpressRoute 接続を展開し、ヨーロッパのすべてのオフィスに 1 つの ExpressRoute 回線をデプロイすることにしました。
ハイブリッドデプロイ
オンプレミスの Lync またはMicrosoft Teamsデプロイがあり、ハイブリッド Microsoft Teams統合を実装する場合は、Azure ExpressRoute をデプロイする場合は、オンプレミスの Lync または Microsoft Teams Edge サイトごとに少なくとも 1 つの ExpressRoute 接続を持ち、オフィスを持つ各大陸に少なくとも 1 つの ExpressRoute 接続が必要であることをお勧めします。 コストとメリットに応じて、各大陸に対して、ネットワーク パフォーマンスターゲットが満たされていないオフィスから追加の ExpressRoute 接続をデプロイすることを選択できます。
オンプレミスのMicrosoft Teams展開がある場合は、 Edge Server の計画と展開に関するガイドに従う必要があります。 具体的には、エッジ サーバーはネットワークの外部から到達可能である必要があります。 これは通常、ルーティング可能なパブリック IP アドレスをエッジ サーバーに割り当てるか、ネットワーク アドレス変換 (NAT) を使用することによって実現されます。
次の例では、Contoso にはオンプレミスの既存の Microsoft Teams Enterprise Voice デプロイがあります。 オンプレミスのユーザーを Microsoft 365 または Office 365 オンライン サービス に移行する必要があります。 また、すべてのオンプレミスおよびオンライン ユーザーに対して既存の PSTN インフラストラクチャを引き続き使用できるように、ハイブリッド展開を使用することにしました。 Contoso のオンプレミス データ センターと Skype for Business エッジ サーバーはシカゴにあります。 デプロイのために、Contoso はシカゴ のデータ センターとシカゴ ExpressRoute の間に 1 つの ExpressRoute 接続を設定することにしました。 また、ホノルルオフィスのサービスを向上させるために、西海岸の ExpressRoute 接続を追加しました。
Cloud Connector Edition を使用したオンラインデプロイ
Skype for Business クラウド コネクタ エディションは、オンプレミスの PSTN 接続を実装するパッケージ化されたVirtual Machines (VM) のセットで構成されるハイブリッド オファリングです。 仮想化された環境に最小限のSkype for Business Server トポロジを展開することで、既存のオンプレミスの PSTN 音声インフラストラクチャを介して固定電話と携帯電話で通話を送受信できます。
Azure ExpressRoute と Cloud Connector Edition をデプロイする場合は、各大陸のメイン サイト間の各大陸に対して、最も近い ExpressRoute ピアリングの場所に少なくとも 1 つの Express Route 接続を設定することをお勧めします。 コストとメリットに応じて、各大陸で、ネットワーク パフォーマンスのターゲットが満たされていないサイトから追加の ExpressRoute 接続を展開できます。
オンプレミスのMicrosoft Teams展開がある場合は、Skype for Business クラウド コネクタ エディションの計画ガイドに従う必要があります。 具体的には、Access Edge サービスと A/V Edge サービスにパブリック IP アドレスと到達可能な Microsoft 365 または Office 365 データ センターを割り当てる必要があります。
次の例では、Contoso はヨーロッパのいくつかの主要な国/地域と都市にプレゼンスを持つヨーロッパの会計事務所です。 すべてのコラボレーション ニーズに対してMicrosoft Teamsにサインアップするときに、既に存在する PSTN インフラストラクチャと通信事業者の契約を引き続き使用するための物理的な場所を持つ国/地域ごとに Cloud Connector を配置することにしました。 すべてのサイトと Microsoft ネットワーク エッジからのテストに基づいて、ロンドンの 1 つの ExpressRoute 接続が、「Skype for Business クライアントから Microsoft ネットワーク エッジへのネットワーク パフォーマンス要件」で説明されているMicrosoft Teamsクライアント接続ネットワーク パフォーマンス ターゲットを満たすのに役立つと判断しました。
Contoso の別のデプロイ オプションを次に示します。 この場合、Cloud Connector が展開されている各サイトで ExpressRoute 接続を設定することにしました。
