近いように見えますが、どういうわけか結果は勇気づけられません-加入者の速度は、同じ無線条件の実験室の速度よりも遅いです。 そしてすぐにネットワークの立ち上げ-あなた
どうする？ 冗談でしょ！
実際、トラブルシューティングにはそれほど時間はかからず、その理由はすぐに見つかりました-高速道路です。 2Gおよび3Gの非常に優れたバックボーンは、LTEの「まあまあ」であることが判明しました。 リザーブに転送-問題はなくなりました。
しかし、疑問が生じました-何が必要ですか？ どのチャンネル品質が必要ですか？ 113の注文も大きなマージンと内部標準で執行されますが、明らかに十分ではありません。 さて、何が必要かを理解してみましょう。 実験室をすばやく組み立てましたが、ベースステーション（BS）とトランスポートネットワーク間のS1インターフェイスに対してのみ、Debianを搭載したサーバーの形で小さなヘルパーを配置しました。 設定は驚くほど迅速に検索され、その日の終わりにはラボの準備が整います。
スキームは非常に単純です（点線はトラフィックパスを示します）。
* MBH-モバイルバックホール-トランスポートネットワーク。
* EPC-進化したパケットコア-パケットコア。
はい、なぜ逆のサーバーが必要なのですか？ 損失と遅延を作ります。 奇妙なことに、これは問題をシミュレートする最も簡単な解決策であることが判明しました。 Tcとそれ以上は必要ありません。 サーバー自体の遅延は最小限です。
加入者の速度は非常に正直に測定されました。ラップトップでは「ホイッスル」、インターネットではftpサーバーです。 私は先に走り、サンプルは多かれ少なかれ正直であったと言います-可能なオプションのそれぞれは10回測定されました。 最良と最悪は破棄され、残りは平均化されました。 ただし、加入者ユニットの不完全な監視ツールが原因でエラーが発生する可能性があります。 経験から、特殊な複合施設にも精度の問題が発生することがわかっています。
次の結果を理解しやすくするためのもう1つの改良点：1ストリーム/ 4ストリームは、ダウンロードストリームの数です。 つまり 一度に1つまたは4つのファイル。 4つのファイルの速度はもちろん合計です。 そして、はい、speedtestは少数のスレッドであるため、4スレッドオプションはより現実に近いものです。
だから、何が起こった：
1.平均速度：
2.最高速度：
遅延は確かに影響しますが、最小化することは非常に困難です。 そして、主な問題はまだドロップによるものです。 閣僚10-3は非常に悲しいようです。 私たちの目標が少なくとも1桁高いことが明らかになり、それを達成するための一連の対策が講じられました。 また、10 -5により、ほとんどすべての条件下で最大値に到達できます。 10 -5に到達するだけではうまくいかないことがありますが、それは別の話です...