[要約] 要約：RFC 7778は、モバイル通信の混雑状況を示すシナリオを提供するものであり、ネットワークの負荷状態を評価するための指標を提供します。目的：このRFCの目的は、モバイル通信の混雑状況を理解し、ネットワークのパフォーマンスを向上させるためのガイドラインを提供することです。
Internet Engineering Task Force (IETF) D. Kutscher
Request for Comments: 7778 F. Mir
Category: Informational R. Winter
ISSN: 2070-1721 NEC
S. Krishnan
Ericsson
Y. Zhang
Hewlett Packard Labs
CJ. Bernardos
UC3M
March 2016
Mobile Communication Congestion Exposure Scenario
モバイル通信の輻輳暴露シナリオ
Abstract
概要
This memo describes a mobile communications use case for congestion exposure (ConEx) with a particular focus on those mobile communication networks that are architecturally similar to the 3GPP Evolved Packet System (EPS). This memo provides a brief overview of the architecture of these networks (both access and core networks) and current QoS mechanisms and then discusses how congestion exposure concepts could be applied. Based on this discussion, this memo suggests a set of requirements for ConEx mechanisms that particularly apply to these mobile networks.
このメモは、3GPP Evolved Packet System（EPS）にアーキテクチャ的に類似しているモバイル通信ネットワークに特に焦点を当てた、輻輳露出（ConEx）のモバイル通信の使用例について説明しています。このメモは、これらのネットワーク（アクセスネットワークとコアネットワークの両方）のアーキテクチャの概要と現在のQoSメカニズムを提供し、次に輻輳露出の概念をどのように適用できるかについて説明します。この議論に基づいて、このメモは、これらのモバイルネットワークに特に適用されるConExメカニズムの一連の要件を提案します。
Status of This Memo
本文書の状態
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントはInternet Standards Trackの仕様ではありません。情報提供を目的として公開されています。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。 IESGによって承認されたすべてのドキュメントが、あらゆるレベルのインターネット標準の候補になるわけではありません。 RFC 5741のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7778.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7778で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
Copyright（c）2016 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。この文書は、BCP 78およびIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . 4
2. ConEx Use Cases in Mobile Communication Networks . . . . . . 4
2.1. ConEx as a Basis for Traffic Management . . . . . . . . . 5
2.2. ConEx to Incentivize Scavenger Transports . . . . . . . . 7
2.3. Accounting for Congestion Volume . . . . . . . . . . . . 7
2.4. Partial vs. Full Deployment . . . . . . . . . . . . . . . 8
2.5. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 9
3. ConEx in the EPS . . . . . . . . . . . . . . . . . . . . . . 9
3.1. Possible Deployment Scenarios . . . . . . . . . . . . . . 9
3.2. Implementing ConEx Functions in the EPS . . . . . . . . . 14
3.2.1. ConEx Protocol Mechanisms . . . . . . . . . . . . . . 15
3.2.2. ConEx Functions in the Mobile Network . . . . . . . . 15
4. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
5. Security Considerations . . . . . . . . . . . . . . . . . . . 19
6. Informative References . . . . . . . . . . . . . . . . . . . 19
Appendix A. Overview of 3GPP's EPS . . . . . . . . . . . . . . . 22
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 24
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24
Mobile data traffic continues to grow rapidly. The challenge wireless operators face is to support more subscribers with an increasing bandwidth demand. To meet these bandwidth requirements, there is a need for new technologies that assist the operators in efficiently utilizing the available network resources. Two specific areas where such new technologies could be deemed useful are resource allocation and flow management.
モバイルデータトラフィックは急速に増加し続けています。無線事業者が直面する課題は、増加する帯域幅需要でより多くの加入者をサポートすることです。これらの帯域幅要件を満たすために、オペレーターが利用可能なネットワークリソースを効率的に利用するのを支援する新しいテクノロジーが必要です。このような新しいテクノロジーが役立つと考えられる2つの特定の領域は、リソース割り当てとフロー管理です。
Analysis of data traffic in cellular networks has shown that most flows are short lived and low volume, but a comparatively small number of high-volume flows constitute a large fraction of the overall traffic volume [lte-sigcomm2013]. That means that potentially a small fraction of users is responsible for the majority of traffic in cellular networks. In view of such highly skewed user behavior and limited and expensive resources (e.g., the wireless spectrum), resource allocation and usage accountability are two important issues for operators to solve in order to achieve both a better network resource utilization and fair resource sharing. ConEx, as described in [RFC6789], is a technology that can be used to achieve these goals.
セルラーネットワークのデータトラフィックを分析すると、ほとんどのフローは短命で少量であることが示されていますが、比較的少数の大量のフローが全体のトラフィック量の大部分を占めています[lte-sigcomm2013]。つまり、ユーザーのごく一部が、携帯電話ネットワークのトラフィックの大部分を担当している可能性があります。このような高度に歪んだユーザーの行動と限られた高価なリソース（ワイヤレススペクトラムなど）を考慮すると、リソースの割り当てと使用の説明責任は、ネットワークリソースの利用率とリソースの公平な共有の両方を実現するためにオペレーターが解決する2つの重要な問題です。 [RFC6789]で説明されているConExは、これらの目標を達成するために使用できるテクノロジーです。
The ConEx mechanism is designed to be a general technology that could be applied as a key element of congestion management solutions for a variety of use cases. In particular, use cases that are of interest for initial deployment are those in which the end hosts and the network that contains the destination end hosts are ConEx-enabled but other networks need not be.
ConExメカニズムは、さまざまなユースケースの輻輳管理ソリューションの重要な要素として適用できる一般的なテクノロジーになるように設計されています。特に、初期展開で重要なユースケースは、エンドホストと宛先エンドホストを含むネットワークがConEx対応であるが、他のネットワークがそうである必要がない場合です。
A specific example of such a use case can be a mobile communication network such as a 3GPP EPS networks where UEs (User Equipment) (i.e., mobile end hosts), servers and caches, the access network, and possibly an operator's core network can be ConEx-enabled; that is, hosts support the ConEx mechanisms, and the network provides policing/auditing functions at its edges.
このような使用例の具体例は、UE（ユーザー機器）（つまり、モバイルエンドホスト）、サーバーとキャッシュ、アクセスネットワーク、および場合によってはオペレーターのコアネットワークが可能な3GPP EPSネットワークなどのモバイル通信ネットワークです。 ConEx対応。つまり、ホストはConExメカニズムをサポートし、ネットワークはそのエッジでポリシング/監査機能を提供します。
This document provides a brief overview of the architecture of such networks (access and core networks) and current QoS mechanisms. It further discusses how such networks can benefit from congestion exposure concepts and how they should be applied. Using this use case as a basis, a set of requirements for ConEx mechanisms are described.
このドキュメントでは、そのようなネットワーク（アクセスおよびコアネットワーク）のアーキテクチャと現在のQoSメカニズムの概要を説明します。さらに、そのようなネットワークが輻輳露出の概念からどのように利益を得ることができるか、そしてそれらがどのように適用されるべきかについて議論します。この使用例を基礎として使用して、ConExメカニズムの一連の要件について説明します。
In this section, we expand some acronyms that are used throughout the text. Most are explained and put in a system context in Appendix A and the 3GPP, ECN, and ConEx specifications referenced there.
このセクションでは、本文全体で使用されているいくつかの頭字語を展開します。ほとんどは、付録Aで説明され、システムコンテキストに入れられます。また、付録Aで参照されている3GPP、ECN、およびConEx仕様も参照されます。
eNB Evolved NodeB: LTE base station
eNB Evolved NodeB：LTE基地局
HSS Home Subscriber Server
HSSホームサブスクライバーサーバー
S-GW Serving Gateway: mobility anchor and tunnel endpoint
S-GWサービスゲートウェイ：モビリティアンカーとトンネルエンドポイント
P-GW Packet Data Network (PDN) Gateway: tunnel endpoint for user-plane and control-plane protocols -- typically the GW to the Internet or an operator's service network
P-GWパケットデータネットワーク（PDN）ゲートウェイ：ユーザープレーンおよびコントロールプレーンプロトコルのトンネルエンドポイント-通常、インターネットまたはオペレーターのサービスネットワークへのGW
UE User Equipment: mobile terminals
UEユーザー機器：モバイル端末
GTP GPRS Tunneling Protocol [TS29060]
GTP GPRSトンネリングプロトコル[TS29060]
GTP-U GTP User Data Tunneling [TS29060]
GTP-U GTPユーザーデータトンネリング[TS29060]
GTP-C GTP Control [TS29060]
GTP-C GTPコントロール[TS29060]
In general, quality of service and good network resource utilization are important requirements for mobile communication network operators. Radio access and backhaul capacity are considered scarce resources, and bandwidth (and radio resource) demand is difficult to predict precisely due to user mobility, radio propagation effects, etc. Hence, today's architectures and protocols go to significant lengths in order to provide network-controlled quality of service. These efforts often lead to complexity and cost. ConEx could be a simpler and more capable approach to efficient resource sharing in these networks.
一般に、サービス品質と良好なネットワークリソース使用率は、モバイル通信ネットワークオペレーターにとって重要な要件です。無線アクセスとバックホール容量は乏しいリソースと見なされ、帯域幅（および無線リソース）の需要は、ユーザーの移動性、無線伝搬効果などのために正確に予測することは困難です。したがって、今日のアーキテクチャとプロトコルは、ネットワークを提供するためにかなりの長さになります-制御されたサービス品質。これらの努力はしばしば複雑さとコストにつながります。 ConExは、これらのネットワークでリソースを効率的に共有するための、よりシンプルでより有能なアプローチになる可能性があります。
In the following sections, we discuss ways that congestion exposure could be beneficial for supporting resource management in such mobile communication networks. [RFC6789] describes fundamental congestion exposure concepts and a set of use cases for applying congestion exposure mechanisms to realize different traffic management functions such as flow policy-based traffic management or traffic offloading. Readers that are not familiar with the 3GPP EPS should refer to Appendix A first.
次のセクションでは、そのようなモバイル通信ネットワークでのリソース管理をサポートするために、輻輳の露出が有益である方法について説明します。 [RFC6789]は、基本的な輻輳露出の概念と、輻輳露出メカニズムを適用してフローポリシーベースのトラフィック管理やトラフィックオフロードなどのさまざまなトラフィック管理機能を実現するための一連の使用例について説明しています。 3GPP EPSに慣れていない読者は、まず付録Aを参照してください。
Traffic management is a very important function in mobile communication networks. Since wireless resources are considered scarce and since user mobility and shared bandwidth in the wireless access create certain dynamics with respect to available bandwidth, commercially operated mobile networks provide mechanisms for tight resource management (admission control for bearer establishment). However, sometimes these mechanisms are not easily applicable to IP-and HTTP-dominated traffic mixes; for example, most Internet traffic in today's mobile network is transmitted over the (best-effort) default bearer.
トラフィック管理は、モバイル通信ネットワークにおいて非常に重要な機能です。ワイヤレスリソースは不足していると見なされており、ワイヤレスアクセスのユーザーモビリティと共有帯域幅は利用可能な帯域幅に関して特定のダイナミクスを生み出すため、商用で運用されているモバイルネットワークは、厳しいリソース管理（ベアラ確立のためのアドミッション制御）のメカニズムを提供します。ただし、これらのメカニズムは、IPとHTTPが優勢なトラフィックミックスに簡単に適用できない場合があります。たとえば、今日のモバイルネットワークのほとんどのインターネットトラフィックは、（ベストエフォート型の）デフォルトベアラを介して送信されます。
Given the above, and in the light of the significant increase of overall data volume in 3G networks, Deep Packet Inspection (DPI) is often considered a desirable function to have in the Evolved Packet Core (EPC) -- despite its cost and complexity. However, with the increase of encrypted data traffic, traffic management using DPI alone will become even more challenging.
上記を考慮すると、3Gネットワークでの全体的なデータ量の大幅な増加に照らして、ディープパケットインスペクション（DPI）は、そのコストと複雑さにもかかわらず、Evolved Packet Core（EPC）に備えるべき望ましい機能と見なされることがよくあります。ただし、暗号化されたデータトラフィックの増加に伴い、DPIだけを使用したトラフィック管理はさらに困難になります。
Congestion exposure can be employed to address resource management requirements in different ways:
輻輳の露出は、さまざまな方法でリソース管理要件に対処するために使用できます。
1. It can enable or enhance flow policy-based traffic management. At present, DPI-based resource management is often used to prioritize certain application classes with respect to others in overload situations, so that more users can be served effectively on the network. In overload situations, operators use DPI to identify dispensable flows and make them yield to other flows (of different application classes) through policing. Such traffic management is thus based on operator decisions, using partly static configuration and some estimation about the future per-flow bandwidth demand. With congestion exposure, it would be possible to assess the contribution to congestion of individual flows. This information can then be used as input to a policer that can optimize network utilization more accurately and dynamically. By using ConEx congestion contribution as a metric, such policers would not need to be aware of specific link loads (e.g., in wireless base stations) or flow application types.
1. フローポリシーベースのトラフィック管理を有効化または強化できます。現在、DPIベースのリソース管理は、多くのユーザーがネットワーク上で効果的にサービスを受けることができるように、過負荷状態で特定のアプリケーションクラスを他のアプリケーションクラスよりも優先するためによく使用されます。過負荷の状況では、オペレーターはDPIを使用して、不要なフローを識別し、ポリシングによって（異なるアプリケーションクラスの）他のフローに譲ることができます。したがって、このようなトラフィック管理は、部分的に静的な構成と将来のフローごとの帯域幅需要についての推定を使用して、オペレーターの決定に基づいています。輻輳にさらされると、個々のフローの輻輳への寄与を評価することが可能になります。この情報は、ネットワークの使用率をより正確かつ動的に最適化できるポリサーへの入力として使用できます。メトリックとしてConEx輻輳の寄与を使用することにより、そのようなポリサーは特定のリンク負荷（たとえば、ワイヤレス基地局）またはフローアプリケーションタイプを認識する必要がなくなります。
2. It can reduce the need for complex DPI by allowing for a bulk packet traffic management system that does not have to consider either the application classes flows belong to or the individual sessions. Instead, traffic management would be based on the current cost (contribution to congestion) incurred by different flows and enable operators to apply policing/accounting depending on their preference. Such traffic management would be simpler and more robust (no real-time flow application type identification required, no static configuration of application classes); it would also perform better as decisions can be made based on real-time actual cost contribution. With ConEx, accurate downstream path information would be visible to ingress network operators, which can respond to incipient congestion in time. This can be equivalent to offering different levels of QoS, e.g., premium service with zero congestion response. For that, ConEx could be used in two different ways:
2. アプリケーションクラスフローが属しているのか個々のセッションであるのかを考慮する必要がないバルクパケットトラフィック管理システムを可能にすることで、複雑なDPIの必要性を減らすことができます。代わりに、トラフィック管理は、さまざまなフローによって発生する現在のコスト（輻輳への寄与）に基づいて行われ、オペレーターは好みに応じてポリシング/アカウンティングを適用できます。このようなトラフィック管理は、よりシンプルで堅牢になります（リアルタイムのフローアプリケーションタイプの識別は不要で、アプリケーションクラスの静的構成は不要です）。また、リアルタイムの実際のコストへの貢献に基づいて決定できるため、パフォーマンスも向上します。 ConExを使用すると、正確なダウンストリームパス情報が入力ネットワークオペレーターに表示され、初期の輻輳に時間内に応答できます。これは、QoSのさまざまなレベルを提供することと同等です。たとえば、輻輳応答がゼロのプレミアムサービスです。そのため、ConExは2つの異なる方法で使用できます。
A. as additional information to assist network functions to impose different QoS for different application sessions; and
A.ネットワーク機能が異なるアプリケーションセッションに異なるQoSを課すのを支援する追加情報として。そして
B. as a tool to let applications decide on their response to congestion notification while incentivizing them to react (in general) appropriately, e.g., by enforcing overall limits for congestion contribution or by accounting and charging for such congestion contribution. Note that this level of responsiveness would be on a different level than, say, application-layer responsiveness in protocols such as Dynamic Adaptive Streaming over HTTP (DASH) [dash]; however, it could interwork with such protocols, for example, by triggering earlier responses.
B.アプリケーションに、（一般に）輻輳の発生に対する全体的な制限を適用するか、そのような輻輳の発生に対する課金と課金によって適切に反応するように動機付けしながら、アプリケーションに輻輳通知への応答を決定させるツールとして。このレベルの応答性は、たとえばHTTP（DASH）を介した動的適応ストリーミングなどのプロトコルのアプリケーション層の応答性とは異なるレベルになることに注意してください[ダッシュ]。ただし、たとえば、以前の応答をトリガーすることにより、このようなプロトコルと相互作用する可能性があります。
3. It can further be used to more effectively trigger the offload of selected traffic to a non-3GPP network. Nowadays, it is common that users are equipped with dual-mode mobile phones (e.g., integrating third/fourth generation cellular and Wi-Fi radio devices) capable of attaching to available networks either sequentially or simultaneously. With this scenario in mind, 3GPP is currently looking at mechanisms to seamlessly and selectively switch over a single IP flow (e.g., user application) to a different radio access while keeping all other ongoing connections untouched. The decision on when and which IP flows move is typically based on statically configured rules, whereas the use of ConEx mechanisms could also factor real-time congestion information into the decision.
3. さらに、非3GPPネットワークへの選択されたトラフィックのオフロードをより効果的にトリガーするために使用することもできます。現在、ユーザーは、利用可能なネットワークに順次または同時に接続できるデュアルモード携帯電話（たとえば、第3 /第4世代の携帯電話とWi-Fi無線デバイスを統合）を装備しているのが一般的です。このシナリオを念頭に置いて、3GPPは現在、単一のIPフロー（ユーザーアプリケーションなど）を別の無線アクセスにシームレスかつ選択的に切り替えながら、他のすべての進行中の接続に影響を与えないメカニズムを検討しています。いつどのIPフローを移動するかの決定は、通常、静的に構成されたルールに基づいていますが、ConExメカニズムの使用は、リアルタイムの輻輳情報を決定に含めることもできます。
In summary, it can be said that traffic management in the 3GPP EPS and other mobile communication architectures is very important. Currently, more static approaches based on admission control and static QoS are in use, but recently, there has been a perceived need for more dynamic mechanisms based on DPI. Introducing ConEx could make these mechanisms more efficient or even remove the need for some of the DPI functions deployed today.
要約すると、3GPP EPSおよびその他のモバイル通信アーキテクチャにおけるトラフィック管理は非常に重要であると言えます。現在、アドミッションコントロールと静的QoSに基づくより多くの静的アプローチが使用されていますが、最近、DPIに基づくより動的なメカニズムの必要性が認識されています。 ConExを導入することで、これらのメカニズムをより効率的にしたり、今日展開されているDPI機能の一部を不要にすることさえできます。
3G and LTE networks are turning into universal access networks that are shared between mobile (smart) phone users, mobile users with laptop PCs, home users with LTE access, and others. Capacity sharing among different users and application flows becomes increasingly important in these mobile communication networks.
3GおよびLTEネットワークは、モバイル（スマート）電話ユーザー、ラップトップPCを使用するモバイルユーザー、LTEアクセスを使用するホームユーザーなどの間で共有されるユニバーサルアクセスネットワークに変わりつつあります。これらのモバイル通信ネットワークでは、さまざまなユーザーとアプリケーションフロー間で容量を共有することがますます重要になります。
Most of this traffic is likely to be classified as best-effort traffic without differentiating, for example, periodic OS updates and application store downloads from web-based (i.e., browser-based) communication or other real-time communication. For many of the bulk data transfers, completion times are not important within certain bounds; therefore, if scavenger transports (or transports that are less than best effort) such as Low Extra Delay Background Transport (LEDBAT) [RFC6817] were used, it would improve the overall utility of the network. The use of these transports by the end user, however, needs to be incentivized. ConEx could be used to build an incentive scheme, e.g., by giving a larger bandwidth allowance to users that contribute less to congestion or lowering the next monthly subscription fee. In principle, this would be possible to implement with current specifications.
このトラフィックの大部分は、たとえば、OSベースの定期的な更新や、Webベースの（つまり、ブラウザベースの）通信やその他のリアルタイム通信からのアプリケーションストアのダウンロードなどを区別せずに、ベストエフォートトラフィックとして分類される可能性があります。多くのバルクデータ転送では、完了時間は特定の範囲内では重要ではありません。したがって、低エクストラ遅延バックグラウンドトランスポート（LEDBAT）[RFC6817]などのスカベンジャートランスポート（またはベストエフォート未満のトランスポート）を使用すると、ネットワークの全体的なユーティリティが向上します。ただし、エンドユーザーによるこれらのトランスポートの使用にはインセンティブが必要です。 ConExはインセンティブスキームを構築するために使用できます。たとえば、輻輳にあまり貢献しない、または次の月額サブスクリプション料金を下げるユーザーに、より大きな帯域幅の許可を与えることによって。原則として、これは現在の仕様で実装することが可能です。
3G and LTE networks provide extensive support for accounting and charging already, for example, see the Policy Charging Control (PCC) architecture [TS23203]. In fact, most operators today account transmitted data volume on a very fine granular basis and either correlate monthly charging to the exact number of packets/bytes transmitted or employ some form of flat rate (or flexible flat rate), often with a so-called fair-use policy. With such policies, users are typically limited to an administratively configured maximum bandwidth limit after they have used up their contractual data volume budget for the charging period.
3GおよびLTEネットワークは、アカウンティングと課金の広範なサポートをすでに提供しています。たとえば、ポリシー課金制御（PCC）アーキテクチャ[TS23203]を参照してください。実際、今日のほとんどの通信事業者は、送信データ量を非常に細かい単位で計算し、毎月の課金を送信パケット/バイトの正確な数に相関させるか、いわゆるいわゆる定額料金（または柔軟な定額料金）を採用しています。フェアユースポリシー。このようなポリシーを使用すると、ユーザーは通常、契約期間中の契約データ量の予算を使い切った後、管理上構成された最大帯域幅制限に制限されます。
Changing this data from volume-based accounting to congestion-based accounting would be possible in principle, especially since there already is an elaborate per-user accounting system available. Also, an operator-provided mobile communication network can be seen as a network domain that would allow for such congestion volume accounting. This would not require any support from the global Internet, especially since the typical scarce resources such as the wireless access and the mobile backhaul are all within this domain. Traffic normally leaves/enters the operator's network via well-defined egress/ingress points that would be ideal candidates for policing functions. Moreover, in most commercially operated networks, accounting is performed for both received and sent data, which would facilitate congestion volume accounting as well.
このデータをボリュームベースのアカウンティングから輻輳ベースのアカウンティングに変更することは、特に利用可能なユーザーごとの精巧なアカウンティングシステムがすでに利用可能であるため、原則的には可能です。また、事業者が提供するモバイル通信ネットワークは、そのような輻輳ボリュームのアカウンティングを可能にするネットワークドメインと見なすことができます。特に、ワイヤレスアクセスやモバイルバックホールなどの一般的な希少なリソースはすべてこのドメイン内にあるため、グローバルインターネットからのサポートは必要ありません。トラフィックは通常、ポリシング機能の理想的な候補となる明確に定義された出口/入口ポイントを介してオペレーターのネットワークを出入りします。さらに、ほとんどの商用ネットワークでは、受信データと送信データの両方に対してアカウンティングが実行されるため、輻輳ボリュームのアカウンティングも容易になります。
With respect to the current Path Computation Client (PCC) framework, accounting for congestion volume could be added as another feature to the "Usage Monitoring Control" capability that is currently based on data volume. This would not require a new interface (reference points) at all.
現在のパス計算クライアント（PCC）フレームワークに関しては、現在データボリュームに基づいている「使用状況監視制御」機能の別の機能として、輻輳ボリュームのアカウンティングを追加できます。これには、新しいインターフェイス（参照ポイント）はまったく必要ありません。
In general, ConEx lends itself to partial deployment as the mechanism does not require all routers and hosts to support congestion exposure. Moreover, assuming a policing infrastructure has been put in place, it is not required to modify all hosts. Since ConEx is about senders exposing congestion contribution to the network, senders need to be made ConEx-aware (assuming a congestion notification mechanism such as Explicit Congestion Notification (ECN) is in place).
一般に、ConExは部分的な展開に適しています。メカニズムはすべてのルーターとホストに輻輳の露出をサポートする必要がないためです。さらに、ポリシングインフラストラクチャが導入されている場合、すべてのホストを変更する必要はありません。 ConExはネットワークに輻輳の影響を公開している送信者に関するものであるため、送信者はConEx対応にする必要があります（明示的輻輳通知（ECN）などの輻輳通知メカニズムが配置されていると想定）。
When moving towards full deployment in a specific operator's network, different ways for introducing ConEx support on UEs are feasible. Since mobile communication networks are multi-vendor networks, standardizing ConEx support on UEs (e.g., in 3GPP specifications) appears useful. Still, not all UEs would have to support ConEx, and operators would be free to choose their policing approach in such deployment scenarios. Leveraging existing PCC architectures, 3GPP network operators could, for example, decide policing/accounting approaches per UE -- i.e., apply fixed volume caps for non-ConEx UEs and more flexible schemes for ConEx-enabled UEs.
特定の事業者のネットワークで完全な展開に移行する場合、UEにConExサポートを導入するさまざまな方法が可能です。モバイル通信ネットワークはマルチベンダーネットワークであるため、UEでのConExサポートの標準化（3GPP仕様など）が役立つようです。それでも、すべてのUEがConExをサポートする必要があるわけではなく、そのような展開シナリオでは、オペレーターはポリシングアプローチを自由に選択できます。既存のPCCアーキテクチャを活用して、3GPPネットワークオペレーターは、たとえば、UEごとにポリシング/アカウンティングアプローチを決定することができます。
Moreover, it should be noted that network support for ConEx is a feature that some operators may choose to deploy if they wish, but it is not required that all operators (or all other networks) do so.
さらに、ConExのネットワークサポートは一部の事業者が希望する場合に展開する機能ですが、すべての事業者（または他のすべてのネットワーク）がそうする必要はないことに注意してください。
Depending on the extent of ConEx support, specific aspects such as roaming have to be taken into account, i.e., what happens when a user is roaming in a ConEx-enabled network but their UE is not ConEx-enabled and vice versa. Although these may not be fundamental problems, they need to be considered. For supporting mobility in general, it can be required to shift users' policing state during a handover. There is existing work on distributed rate limiting (see [raghavan2007]) and on specific optimizations (see [nec.euronf-2011]) for congestion exposure and policing in mobility scenarios.
ConExサポートの範囲に応じて、ローミングなどの特定の側面を考慮する必要があります。つまり、ユーザーがConEx対応ネットワークでローミングしているが、UEがConEx対応ではない場合、またはその逆の場合はどうなりますか。これらは根本的な問題ではないかもしれませんが、考慮する必要があります。一般にモビリティをサポートするために、ハンドオーバー中にユーザーのポリシング状態をシフトする必要がある場合があります。モビリティシナリオでの輻輳の露出とポリシングのための分散レート制限（[raghavan2007]を参照）および特定の最適化（[nec.euronf-2011]を参照）に関する既存の作業があります。
Another aspect to consider is the addition of Selected IP Traffic Offload (SIPTO) and Local IP Access (LIPA) [TR23829]), i.e., the idea that some traffic such as high-volume Internet traffic is actually not passed through the EPC but is offloaded at a "break-out point" closer to (or in) the access network. On the other hand, ConEx can also enable more dynamic decisions on what traffic to actually offload by considering congestion exposure in bulk traffic aggregates, thus making traffic offload more effective.
考慮すべきもう1つの側面は、選択されたIPトラフィックオフロード（SIPTO）とローカルIPアクセス（LIPA）[TR23829]）の追加です。つまり、大量のインターネットトラフィックなどの一部のトラフィックは実際にはEPCを通過しないが、アクセスネットワークに近い（またはアクセスネットワーク内の）「ブレークアウトポイント」でオフロードされます。一方、ConExは、バルクトラフィック集約での輻輳の露出を考慮することにより、実際にオフロードするトラフィックをより動的に決定できるため、トラフィックのオフロードをより効果的にすることができます。
In summary, the 3GPP EPS is a system architecture that can benefit from congestion exposure in multiple ways. Dynamic traffic and congestion management is an acknowledged and important requirement for the EPS; this is also illustrated by the current DPI-related work for EPS.
要約すると、3GPP EPSは、複数の方法で輻輳の露出から利益を得ることができるシステムアーキテクチャです。動的なトラフィックと輻輳の管理は、EPSに認められた重要な要件です。これは、EPSの現在のDPI関連の作業でも示されています。
Moreover, networks such as an EPS mobile communication network would be quite amenable for deploying ConEx as a mechanism, since they represent clearly defined and well-separated operational domains in which local ConEx deployment would be possible. Aside from roaming (which needs to be considered for a specific solution), such a deployment is fully under the control of a single operator, which can enable operator-local enhancement without the need for major changes to the architecture.
さらに、EPSモバイル通信ネットワークなどのネットワークは、ローカルConExの展開が可能な明確に定義され、十分に分離された運用ドメインを表すため、メカニズムとしてConExを展開するのに適しています。ローミング（特定のソリューションについて検討する必要がある）を除いて、このような展開は単一のオペレーターの制御下で完全に行われるため、アーキテクチャーに大きな変更を加えることなく、オペレーターのローカル拡張を実現できます。
In 3GPP EPS, interfaces between all elements of the architecture are subject to standardization, including UE interfaces and eNB interfaces, so that a more general approach, involving more than a single operator's network, can be feasible as well.
3GPP EPSでは、UEインターフェースやeNBインターフェースなど、アーキテクチャのすべての要素間のインターフェースが標準化されているため、複数の事業者のネットワークを含むより一般的なアプローチも実現可能です。
In this section, we discuss a few options for how such a mechanism (and possibly additional policing functions) could eventually be deployed in the 3GPP EPS. Note that this description of options is not intended to be a complete set of possible approaches; it merely discusses the most promising options.
このセクションでは、このようなメカニズム（および場合によっては追加のポリシング機能）を最終的に3GPP EPSに展開する方法のいくつかのオプションについて説明します。このオプションの説明は、可能なアプローチの完全なセットを意図したものではないことに注意してください。最も有望なオプションについてのみ説明します。
There are different possible ways for how ConEx functions on hosts and network elements can be used. For example, ConEx could be used for a limited part of the network only (e.g., for the access network), congestion exposure and sender adaptation could involve the mobile nodes or not, or, finally, the ConEx feedback loop could extend beyond a single operator's domain or not.
ホストおよびネットワーク要素でのConEx機能の使用方法にはさまざまな方法があります。たとえば、ConExはネットワークの限られた部分のみ（たとえば、アクセスネットワーク）に使用でき、輻輳の露出と送信者の適応はモバイルノードを含むかどうかに関係なく、最後に、ConExフィードバックループは単一のオペレーターのドメインかどうか。
We present four different deployment scenarios for congestion exposure in the figures below:
以下の図に、輻輳の露出に関する4つの異なる展開シナリオを示します。
1. In Figure 1, ConEx is supported by servers for sending data (web servers in the Internet and caches in an operator's network) but not by UEs (neither for receiving nor sending). An operator who chooses to run a policing function on the network ingress, e.g., on the P-GW, can still benefit from congestion exposure without requiring any change on UEs.
1. 図1では、ConExはデータを送信するサーバー（インターネットのWebサーバーとオペレーターのネットワークのキャッシュ）でサポートされていますが、UE（受信でも送信でもない）ではサポートされていません。ネットワーク入口、たとえばP-GWでポリシング機能を実行することを選択したオペレーターは、UEで変更を必要とせずに、輻輳の危険から恩恵を受けることができます。
2. ConEx is universally employed between operators (as depicted in Figure 2) with an end-to-end ConEx feedback loop. Here, operators could still employ local policies, congestion accounting schemes, etc., and they could use information about congestion contribution for determining interconnection agreements. This deployment scenario would imply the willingness of operators to expose congestion to each other.
2. ConExは、エンドツーエンドのConExフィードバックループを持つオペレーター間で（図2に示すように）普遍的に採用されています。ここでは、事業者は地域の方針、混雑会計制度などを依然として採用することができ、相互接続協定を決定するために混雑の寄与に関する情報を使用することができます。この展開シナリオは、オペレーターが相互に輻輳を公開する意思があることを意味します。
3. For Isolated ConEx domains as depicted in Figure 3, ConEx is solely applied locally in the operator network, and there is no end-to-end congestion exposure. This could be the case when ConEx is only implemented in a few networks or when operators decide to not expose ECN and account for congestion for inter-domain traffic. Independent of the actual scenario, it is likely that there will be border gateways (as in today's deployments) that are associated with policing and accounting functions.
3. 図3に示すように、分離されたConExドメインの場合、ConExはオペレーターネットワークでローカルにのみ適用され、エンドツーエンドの輻輳の危険性はありません。これは、ConExが少数のネットワークにのみ実装されている場合や、事業者がECNを公開せずにドメイン間トラフィックの輻輳を考慮することにした場合に当てはまります。実際のシナリオとは関係なく、ポリシング機能とアカウンティング機能に関連付けられているボーダーゲートウェイが（今日の配置のように）存在する可能性があります。
4. [conex-lite] describes an approach called "ConEx Lite" for mobile networks that is intended for initial deployment of congestion exposure concepts in LTE, specifically in the backhaul and core network segments. As depicted in Figure 4, ConEx Lite allows a tunnel receiver to monitor the volume of bytes that has been lost, dropped, or ECN-CE (Congestion Experienced) marked between the tunnel sender and receiver. For that purpose, a new field called the Byte Sequence Marker (BSN) is introduced to the tunnel header to identify the byte in the flow of data from the tunnel sender to the tunnel receiver. A policer at the tunnel sender is expected to react according to the tunnel congestion volume (see [conex-lite] for details).
4. [conex-lite]は、モバイルネットワーク向けの「ConEx Lite」と呼ばれるアプローチを説明しています。これは、LTE、特にバックホールセグメントとコアネットワークセグメントでの輻輳露出コンセプトの初期導入を目的としています。図4に示すように、ConEx Liteを使用すると、トンネルレシーバーは、失われた、ドロップされた、またはトンネルセンダーとレシーバーの間でマークされたECN-CE（輻輳経験）のバイト数を監視できます。そのために、バイトシーケンスマーカー（BSN）と呼ばれる新しいフィールドがトンネルヘッダーに導入され、トンネルセンダーからトンネルレシーバーへのデータフロー内のバイトを識別します。トンネル送信者のポリサーは、トンネルの輻輳ボリュームに従って反応することが期待されます（詳細については、[conex-lite]を参照）。
+------------+
| Web server |
| w/ ConEx |
+------------+
|
|
|
-----------------------
| | |
| Internet | |
| | |
-----------------------
|
--------------------------------------------|--------
| | |
| +-----------+ |
| | Web cache | |
| | w/ ConEx | |
| +-----------+ |
| | |
| +----+ +-------+ +-------+ +-------+ |
| | UE |=====| eNB |=====| S-GW |=====| P-GW | |
| +----+ +-------+ +-------+ +-------+ |
| |
| Operator A |
-----------------------------------------------------
Figure 1: ConEx Support on Servers and Caches
図1：サーバーとキャッシュでのConExサポート
-----------------------------------------------------
| +----+ +-------+ +-------+ +-------+ |
| | UE |=====| eNB |=====| S-GW |=====| P-GW | |
| +----+ +-------+ +-------+ +-------+ |
| | |
| Operator A | |
--------------------------------------------|--------
|
-----------------------
| |
| Internet |
| |
-----------------------
|
--------------------------------------------|--------
| +----+ +-------+ +-------+ +-------+ |
| | UE |=====| eNB |=====| S-GW |=====| P-GW | |
| +----+ +-------+ +-------+ +-------+ |
| |
| Operator B |
-----------------------------------------------------
Figure 2: ConEx Deployment across Operator Domains
図2：オペレータードメイン間のConEx展開
-----------------------------------------------------
| |--- ConEx path ---| |
| v v |
| +----+ +-------+ +-------+ +-------+ |
| | UE |=====| eNB |=====| S-GW |=====| P-GW | |
| +----+ +-------+ +-------+ +-------+ |
| | |
| Operator A | |
--------------------------------------------|--------
|
-----------------------
| |
| Internet |
| |
-----------------------
|
--------------------------------------------|--------
| +----+ +-------+ +-------+ +-------+ |
| | UE |=====| eNB |=====| S-GW |=====| P-GW | |
| +----+ +-------+ +-------+ +-------+ |
| |
| Operator B |
-----------------------------------------------------
Figure 3: ConEx Deployment in a Single Operator Domain
図3：単一オペレータードメインでのConEx展開
Backhaul Network Core Network
+---------------+ +--------------+
| | | |
| BSN or ECN-CE | | |
| marked | | |
| packets | | |
| <--- | | |
+----+ +-------+ +----------+ +-------+ +--------+
| | | | GTP-U | | GTP-U | | | |
| UE |=====| eNB |=======| S-GW |=======| P-GW |==|Internet|
| | | | Tunnel| | Tunnel| | | |
+----+ +-------+ +----------+ +-------+ +--------+
| ---> | | |
| User/control | | User/control |
| packets with | | packet with |
| DL congestion | | DL congestion|
| vol counters | | vol counters |
| | | |
+---------------+ +--------------+
Figure 4: ConEx Lite Deployment
図4：ConEx Liteの展開
Note: DL stands for "downlink".
注：DLは「ダウンリンク」の略です。
We expect a ConEx solution to consist of different functions that should be considered when implementing congestion exposure in the 3GPP EPS. [RFC7713] describes the following congestion exposure components:
ConExソリューションは、3GPP EPSで輻輳露出を実装するときに考慮すべきさまざまな機能で構成されることが期待されます。 [RFC7713]は、次の輻輳露出コンポーネントについて説明しています。
o Modified senders that send congestion exposure information in response to congestion feedback.
o 輻輳フィードバックに応答して輻輳露出情報を送信する変更された送信者。
o Receivers that generate congestion feedback (leveraging existing behavior or requiring new functions).
o 輻輳フィードバックを生成するレシーバー（既存の動作を活用するか、新しい機能を必要とする）。
o Audit functions that audit ConEx signals against actual congestion, e.g., by monitoring flows or aggregate of flows.
o フローまたはフローの集約を監視するなどして、実際の輻輳に対してConEx信号を監査する監査機能。
o Policy devices that monitor congestion exposure information and act on the flows according to the operator's policy.
o 輻輳の露出情報を監視し、オペレーターのポリシーに従ってフローを処理するポリシーデバイス。
Two aspects are important to consider: 1) how the ConEx protocol mechanisms would be implemented and what modifications to existing networks would be required, and 2) where ConEx functional entities would be placed best (to allow for a non-invasive addition). We discuss these two aspects in the following sections.
2つの側面を検討することが重要です。1）ConExプロトコルメカニズムを実装する方法と既存のネットワークにどのような変更が必要か、および2）ConEx機能エンティティを最適に配置する場所（非侵襲的な追加を可能にするため）。次のセクションでは、これら2つの側面について説明します。
The most important step in introducing ConEx (initially) is adding the congestion exposure functionality to senders. For an initial deployment, no further modification to senders and receivers would be required. Specifically, there is no fundamental dependency on ECN, i.e., ConEx can be introduced without requiring ECN to be implemented.
（最初に）ConExを導入する上で最も重要なステップは、送信者に輻輳露出機能を追加することです。初期展開では、送信者と受信者をさらに変更する必要はありません。具体的には、ECNへの基本的な依存関係はありません。つまり、ECNを実装することなくConExを導入できます。
Congestion exposure information for IPv6 [CONEX-DESTOPT] is contained in a destination option header field, which requires minimal changes at senders and nodes that want to assess path congestion. The destination option header field does not affect non-ConEx nodes in a network.
IPv6 [CONEX-DESTOPT]の輻輳露出情報は、宛先オプションヘッダーフィールドに含まれています。これにより、パスの輻輳を評価する送信者およびノードで最小限の変更が必要になります。宛先オプションヘッダーフィールドは、ネットワーク内の非ConExノードには影響しません。
In 3GPP networks, IP tunneling is used intensively, i.e., using either IP-in-GTP-U or Proxy Mobile IPv6 (PMIPv6) (i.e., IP-in-IP) tunnels. In general, the ConEx destination option of encapsulated packets should be made available for network nodes on the tunnel path, i.e., a tunnel ingress should copy the ConEx destination option field to the outer header.
3GPPネットワークでは、IPトンネリングが集中的に使用されます。つまり、IP-in-GTP-UまたはプロキシモバイルIPv6（PMIPv6）（つまり、IP-in-IP）トンネルを使用します。一般に、カプセル化されたパケットのConEx宛先オプションは、トンネルパス上のネットワークノードで使用できるようにする必要があります。つまり、トンネルの入口は、ConEx宛先オプションフィールドを外部ヘッダーにコピーする必要があります。
For effective and efficient capacity sharing, we envisage the deployment of ECN in conjunction with ConEx so that ECN-enabled receivers and senders get more accurate and more timely information about the congestion contribution of their flows. ECN is already partially introduced into 3GPP networks: Section 11.6 in [TS36300] specifies the usage of ECN for congestion notification on the radio link (between eNB and UE), and [TS26114] specifies how this can be leveraged for voice codec adaptation. A complete, end-to-end support of ECN would require specification of tunneling behaviour, which should be based on [RFC6040] (for IP-in-IP tunnels). Specifically, a specification for tunneling ECN in GTP-U will be needed.
効果的かつ効率的な容量共有のために、ECN対応の受信者と送信者がフローの輻輳の寄与に関するより正確かつタイムリーな情報を取得できるように、ConExと組み合わせたECNの展開を想定しています。 ECNはすでに3GPPネットワークに部分的に導入されています。[TS36300]のセクション11.6は、無線リンク（eNBとUEの間）での輻輳通知のためのECNの使用法を指定し、[TS26114]はこれを音声コーデック適応に活用する方法を指定します。 ECNの完全なエンドツーエンドのサポートには、[RFC6040]（IP-in-IPトンネルの場合）に基づく必要があるトンネリング動作の仕様が必要です。具体的には、GTP-UでECNをトンネリングするための仕様が必要になります。
In this section, we discuss some possible placement strategies for ConEx functional entities (addressing both policing and auditing functions) in the EPS and for possible optimizations for both the uplink and the downlink.
このセクションでは、EPSのConEx機能エンティティ（ポリシング機能と監査機能の両方に対応）のいくつかの可能な配置戦略と、アップリンクとダウンリンクの両方の可能な最適化について説明します。
In general, ConEx information (exposed congestion) is declared by a sender and remains unchanged on the path; hence, reading ConEx information (e.g., by policing functions) is placement-agnostic. Auditing ConEx normally requires assessing declared congestion contribution and current actual congestion. If the latter is, for example, done using ECN, such a function would best be placed at the end of the path.
一般に、ConEx情報（露出した輻輳）は送信者によって宣言され、パス上で変更されないままです。したがって、（たとえば、ポリシング機能による）ConEx情報の読み取りは、配置に依存しません。 ConExを監査するには、通常、宣言された輻輳の寄与と現在の実際の輻輳を評価する必要があります。後者が、たとえばECNを使用して行われる場合、そのような関数はパスの最後に配置するのが最適です。
In order to provide a comprehensive ConEx-based capacity management framework for the EPS, it would be advantageous to consider user contribution to congestion for both the radio access and the core network. For a non-invasive introduction of ConEx, it can be beneficial to combine ConEx functions with existing logical EPS entities. For example, potential places for ConEx policing and auditing functions would then be eNBs, S-GWs, or the P-GWs. Operator deployments may, of course, still provide additional intermediary ConEx-enabled IP network elements.
EPSにConExベースの包括的な容量管理フレームワークを提供するために、無線アクセスとコアネットワークの両方の輻輳に対するユーザーの貢献を検討することは有利です。 ConExを非侵襲的に導入するには、ConEx機能を既存の論理EPSエンティティと組み合わせると効果的です。たとえば、ConExポリシングおよび監査機能の潜在的な場所は、eNB、S-GW、またはP-GWになります。もちろん、オペレーターの配置は、追加の中間的なConEx対応IPネットワーク要素を提供します。
For a more specific discussion, it will be beneficial to distinguish downlink and uplink traffic directions (also see [nec.globecom2010] for a more detailed discussion). In today's networks and usage models, downlink traffic is dominating (also reflected by the asymmetric capacity provided by the LTE radio interface). That does not, however, imply that uplink congestion is not an issue, since the asymmetric maximum bandwidth configuration can create a smaller bottleneck for uplink traffic. There are, of course, backhaul links, gateways, etc., that could be overloaded as well.
より具体的な説明については、ダウンリンクとアップリンクのトラフィックの方向を区別することが有益です（詳細については、[nec.globecom2010]も参照してください）。今日のネットワークと使用モデルでは、ダウンリンクトラフィックが支配的です（LTE無線インターフェイスによって提供される非対称容量にも反映されます）。ただし、非対称の最大帯域幅構成によりアップリンクトラフィックのボトルネックが小さくなるため、アップリンクの輻輳が問題にならないことを意味するものではありません。もちろん、過負荷になる可能性のあるバックホールリンク、ゲートウェイなどもあります。
For managing downlink traffic (e.g., in scenarios such as the one depicted in Figure 1), operators can have different requirements for policing traffic. Although policing is, in principle, location-agnostic, it is important to consider requirements related to the EPS architecture (Figure 5) such as tunneling between P-GWs and eNBs. Policing can require access to subscriber information (e.g., congestion contribution quota) or user-specific accounting, which suggests that the ConEx function could be co-located with the P-GW that already has an interface towards the Policy and Charging Rule Function (PCRF).
ダウンリンクトラフィックを管理するため（図1に示すようなシナリオなど）、オペレーターはトラフィックのポリシングに関して異なる要件を持つことができます。ポリシングは原則として場所に依存しませんが、P-GWとeNB間のトンネリングなど、EPSアーキテクチャ（図5）に関連する要件を考慮することが重要です。ポリシングは、加入者情報（たとえば、輻輳寄与クォータ）またはユーザー固有のアカウンティングへのアクセスを必要とする可能性があります。これは、ConEx機能が、ポリシーおよび課金ルール機能（PCRF）へのインターフェイスをすでに持っているP-GWと同じ場所に配置できることを示唆しています。 ）。
Still, policing can serve different purposes. For example, if the objective is to police bulk traffic induced by peer networks, additional monitoring functions can be placed directly at corresponding ingress points to monitor traffic and possibly drive out-of-band functions such as triggering border contract penalties.
それでも、ポリシングにはさまざまな目的があります。たとえば、目的がピアネットワークによって引き起こされたバルクトラフィックをポリシングすることである場合、追加のモニタリング機能を対応する入力ポイントに直接配置して、トラフィックをモニタリングし、ボーダー契約ペナルティのトリガーなどの帯域外機能を駆動することができます。
The auditing function, which should be placed at the end of the path (at least after/at the last bottleneck), would likely be placed best on the eNB (wireless base station).
パスの最後（少なくとも最後または最後のボトルネック）に配置する必要がある監査機能は、eNB（ワイヤレス基地局）に配置するのが最適です。
For the uplink direction, there are naturally different options for designing monitoring and policy enforcement functions. A likely approach can be to monitor congestion exposure on central gateway nodes (such as P-GWs) that provide the required interfaces to the PCRF but to perform policing actions in the access network (i.e., in eNBs). For example, the traffic is policed at the ingress before it reaches concentration points in the core network.
アップリンク方向については、監視およびポリシー実施機能を設計するための当然異なるオプションがあります。可能性のあるアプローチは、PCRFに必要なインターフェイスを提供する中央ゲートウェイノード（P-GWなど）での輻輳の露出を監視するが、アクセスネットワーク（つまりeNB）でポリシングアクションを実行することです。たとえば、トラフィックは、コアネットワークの集中ポイントに到達する前に、入口でポリシングされます。
Such a setup would enable all the ConEx use cases described in Section 2 without requiring significant changes to the EPS architecture. It would also enable operators to re-use existing infrastructure, specifically wireless base stations, PCRF, and Home Subscriber Server (HSS) systems.
このような設定により、EPSアーキテクチャに大きな変更を加えることなく、セクション2で説明したすべてのConExユースケースが可能になります。また、オペレータは既存のインフラストラクチャ、特に無線基地局、PCRF、およびHome Subscriber Server（HSS）システムを再利用できるようになります。
For ConEx functions on elements such as the S-GWs and P-GWs, it is important to consider mobility and tunneling protocol requirements. LTE provides two alternative approaches: PMIPv6 [TS23402] and the GPRS Tunneling Protocol (GTP). For the propagation of congestion information (responses), tunneling considerations are therefore very important.
S-GWやP-GWなどの要素のConEx機能の場合、モビリティとトンネリングプロトコルの要件を考慮することが重要です。 LTEは、PMIPv6 [TS23402]とGPRSトンネリングプロトコル（GTP）の2つの代替アプローチを提供します。したがって、輻輳情報（応答）の伝搬では、トンネリングの考慮事項が非常に重要です。
In general, policing will be done based on per-user (per-subscriber) information such as congestion quota, current quota usage, etc., and network operator policies, e.g., specifying how to react to persistent congestion contribution. In the EPS, per-user information is normally part of the user profile (stored in the HSS) that would be accessed by PCC entities such as the PCRF for dynamic updates, enforcement, etc.
一般に、ポリシングは、輻輳クォータ、現在のクォータ使用量などのユーザーごと（サブスクライバーごと）の情報、およびネットワークオペレーターのポリシーに基づいて行われます。 EPSでは、ユーザーごとの情報は通常、動的更新、施行などのPCRFなどのPCCエンティティによってアクセスされるユーザープロファイル（HSSに格納されている）の一部です。
We have shown how congestion exposure can be useful for efficient resource management in mobile communication networks. The premise for this discussion was the observation that data communication, specifically best-effort bulk data transmission, is becoming a commodity service, whereas resources are obviously still limited. This calls for efficient, scalable, and yet effective capacity sharing in such networks.
輻輳の露出がモバイル通信ネットワークの効率的なリソース管理にどのように役立つかを示しました。この議論の前提は、データ通信、具体的にはベストエフォートのバルクデータ送信が、コモディティサービスになりつつありますが、リソースは明らかに限られているという観察でした。これには、そのようなネットワークで効率的でスケーラブルでありながら効果的な容量共有が必要です。
ConEx can be a mechanism that enables such capacity sharing while allowing operators to apply these mechanisms in different ways, e.g., for implementing different use cases as described in Section 2. It is important to note that ConEx is fundamentally a mechanism that can be applied in different ways to realize the policies of different operators.
ConExは、このような容量共有を可能にするメカニズムであり、オペレーターがこれらのメカニズムをさまざまな方法で適用できるようにします。たとえば、セクション2で説明するさまざまなユースケースを実装するためです。ConExは、基本的にさまざまなオペレーターのポリシーを実現するさまざまな方法。
ConEx may also be used to complement 3GPP-based mechanisms for congestion management that are currently under development, such as in the User Plane Congestion Management (UPCON) work item described in [TR23705].
ConExは、[TR23705]で説明されているユーザープレーン輻輳管理（UPCON）ワークアイテムなど、現在開発中の輻輳管理のための3GPPベースのメカニズムを補完するためにも使用できます。
We have described a few possibilities for adding ConEx as a mechanism to 3GPP LTE-based networks and have shown how this could be done incrementally (starting with partial deployment). It is quite feasible that such partial deployments be done on a per-operator-domain basis without requiring changes to standard 3GPP interfaces.
3GPP LTEベースのネットワークへのメカニズムとしてConExを追加する可能性をいくつか説明し、これを段階的に行う方法を示しました（部分的な展開から開始）。標準の3GPPインターフェイスに変更を加えることなく、そのような部分的な展開をオペレータードメインごとに行うことは非常に現実的です。
For network-wide deployment, e.g., with congestion exposure between operators, more considerations might be needed.
事業者間の輻輳が発生するなど、ネットワーク全体に配備する場合は、さらに検討が必要になることがあります。
We have also identified a few implications/requirements that should be taken into consideration when enabling congestion exposure in such networks:
また、このようなネットワークで輻輳の影響を有効にする際に考慮すべきいくつかの影響/要件を特定しました。
Performance: In mobile communication networks with more expensive resources and more stringent QoS requirements, the feasibility of applying ConEx as well as its performance and deployment scenarios need to be examined closer. For instance, a mobile communication network may encounter longer delay and higher loss rates, which can impose specific requirements on the timeliness and accuracy of congestion exposure information.
パフォーマンス：より高価なリソースとより厳しいQoS要件を備えたモバイル通信ネットワークでは、ConExの適用の実現可能性と、そのパフォーマンスおよび展開シナリオをさらに詳しく検討する必要があります。たとえば、モバイル通信ネットワークでは、より長い遅延とより高い損失率が発生する可能性があり、輻輳の露出情報の適時性と正確性に特定の要件を課す可能性があります。
Mobility: One of the unique characteristics of cellular networks when compared to wired networks is the presence of user mobility. As the user location changes, the same device can be connected to the network via different base stations (eNBs) or even go through switching gateways. Thus, the ConEx scheme must to be able to carry the latest congestion information per user/flow across multiple network nodes in real time.
モビリティ：有線ネットワークと比較した場合のセルラーネットワークのユニークな特徴の1つは、ユーザーモビリティの存在です。ユーザーの場所が変わると、同じデバイスを異なる基地局（eNB）経由でネットワークに接続したり、スイッチングゲートウェイを経由したりすることができます。したがって、ConExスキームは、複数のネットワークノード間でユーザー/フローごとに最新の輻輳情報をリアルタイムで伝送できる必要があります。
Multi-access: In cellular networks, multiple access technologies can co-exist. In such cases, a user can use multiple access technologies for multiple applications or even a single application simultaneously. If the congestion policies are set based on each user, then ConEx should have the capability to enable information exchange across multiple access domains.
マルチアクセス：セルラーネットワークでは、複数のアクセス技術が共存できます。このような場合、ユーザーは複数のアプリケーションに複数のアクセステクノロジを使用したり、1つのアプリケーションを同時に使用したりできます。輻輳ポリシーが各ユーザーに基づいて設定されている場合、ConExには、複数のアクセスドメイン間での情報交換を可能にする機能が必要です。
Tunneling: Both 3G and LTE networks make extensive usage of tunneling. The ConEx mechanism should be designed in a way to support usage with different tunneling protocols such as PMIPv6 and GTP. For ECN-based congestion notification, [RFC6040] specifies how the ECN field of the IP header should be constructed on entry and exit from IP-in-IP tunnels.
トンネリング：3GネットワークとLTEネットワークの両方で、トンネリングが広範囲に使用されます。 ConExメカニズムは、PMIPv6やGTPなどの異なるトンネリングプロトコルでの使用をサポートする方法で設計する必要があります。 ECNベースの輻輳通知の場合、[RFC6040]は、IP-in-IPトンネルの入口と出口でIPヘッダーのECNフィールドを作成する方法を指定します。
Roaming: Independent of the specific architecture, mobile communication networks typically differentiate between non-roaming and roaming scenarios. Roaming scenarios are typically more demanding regarding implementing operator policies, charging, etc. It can be expected that this would also hold for deploying ConEx. A more detailed analysis of this problem will be provided in a future revision of this document.
ローミング：特定のアーキテクチャに関係なく、モバイル通信ネットワークは通常、非ローミングシナリオとローミングシナリオを区別します。ローミングシナリオは、通常、オペレーターポリシーの実装、課金などに関してより厳しいものです。これは、ConExの展開にも当てはまると予想できます。この問題のより詳細な分析は、このドキュメントの将来の改訂で提供されます。
It is important to note that ConEx is intended to be used as a supplement and not a replacement to the existing QoS mechanisms in mobile networks. For example, ConEx deployed in 3GPP mobile networks can provide useful input to the existing 3GPP PCC mechanisms by supplying more dynamic network information to supplement the fairly static information used by the PCC. This would enable the mobile network to make better policy control decisions than is possible with only static information.
ConExはモバイルネットワークの既存のQoSメカニズムの代わりではなく、補足として使用することを目的としていることに注意することが重要です。たとえば、3GPPモバイルネットワークに展開されたConExは、PCCが使用するかなり静的な情報を補足するために、より動的なネットワーク情報を提供することにより、既存の3GPP PCCメカニズムに有用な入力を提供できます。これにより、モバイルネットワークは、静的な情報のみで可能な場合よりも優れたポリシー制御決定を行うことができます。
For any ConEx deployment, it is important to apply appropriate mechanisms to preclude applications and senders from misstating their congestion contribution. [RFC7713] discusses this problem in detail and introduces the ConEx auditing concept. ConEx auditing can be performed in different ways -- for example, flows can be constantly audited or only audited on demand when network operators decide to do so. Also, coarse-grained auditing may operate on flow aggregates for efficiency reasons, whereas fine-grained auditing would inspect individual flows. In mobile networks, there may be deployment strategies that favor efficiency over very exact auditing. It is important to understand the trade-offs and to apply ConEx auditing appropriately.
どのConEx展開でも、適切なメカニズムを適用して、アプリケーションと送信者が輻輳の原因を誤って説明するのを防ぐことが重要です。 [RFC7713]はこの問題を詳細に説明し、ConEx監査の概念を紹介しています。 ConEx監査はさまざまな方法で実行できます。たとえば、フローは常に監査することも、ネットワークオペレーターが決定したときにオンデマンドでのみ監査することもできます。また、粗粒度の監査は効率上の理由からフロー集約で動作する可能性がありますが、細粒度監査は個々のフローを検査します。モバイルネットワークでは、非常に正確な監査よりも効率を優先する展開戦略がある場合があります。トレードオフを理解し、ConEx監査を適切に適用することが重要です。
The ConEx protocol specifications [CONEX-DESTOPT] and [TCP-MOD] discuss additional security considerations that would also apply to mobile network deployments.
ConExプロトコル仕様[CONEX-DESTOPT]および[TCP-MOD]では、モバイルネットワークの展開にも適用される追加のセキュリティの考慮事項について説明しています。
[CONEX-DESTOPT] Krishnan, S., Kuehlewind, M., Briscoe, B., and C. Ralli, "IPv6 Destination Option for Congestion Exposure (ConEx)", Work in Progress, draft-ietf-conex-destopt-12, January 2016.
[CONEX-DESTOPT]クリシュナン、S。、キューレウィンド、M。、ブリスコー、B。、およびC.ラリー、「輻輳露出のIPv6宛先オプション（ConEx）」、進行中の作業、draft-ietf-conex-destopt-12 、2016年1月。
[conex-lite] Baillargeon, S. and I. Johansson, "ConEx Lite for Mobile Networks", In Proceedings of the 2014 ACM SIGCOMM Capacity Sharing Workshop, DOI 10.1145/2630088.2630091, August 2014.
[conex-lite] Baillargeon、S。およびI. Johansson、「モバイルネットワーク用のConEx Lite」、2014 ACM SIGCOMM容量共有ワークショップの議事録、DOI 10.1145 / 2630088.2630091、2014年8月。
[dash] ISO/IEC, "Information Technology -- Dynamic Adaptive Streaming over HTTP (DASH) -- Part 1: Media presentation description and segment formats", ISO/IEC 23009-1:2014, May 2014.
[ダッシュ] ISO / IEC、「情報技術-HTTP経由の動的適応ストリーミング（DASH）-パート1：メディアプレゼンテーションの説明とセグメント形式」、ISO / IEC 23009-1：2014、2014年5月。
[lte-sigcomm2013] Huang, J., Qian, F., Guo, Y., Zhou, Y., Xu, Q., Mao, Z., Sen, S., and O. Spatscheck, "An In-depth Study of LTE: Effect of Network Protocol and Application Behavior on Performance", In Proceedings of the 2013 ACM SIGCOMM Conference, DOI 10.1145/2486001.2486006, August 2013.
[lte-sigcomm2013] Huang、J.、Qian、F.、Guo、Y.、Zhou、Y.、Xu、Q.、Mao、Z.、Sen、S.、O。Spatscheck、「An In-depth LTEの研究：ネットワークプロトコルとアプリケーションの動作がパフォーマンスに及ぼす影響」、2013 ACM SIGCOMM会議の議事録、DOI 10.1145 / 2486001.2486006、2013年8月。
[nec.euronf-2011] Mir, F., Kutscher, D., and M. Brunner, "Congestion Exposure in Mobility Scenarios", In Proceedings of the 7th Euro-NF Conference on Next Generation Internet (NGI), DOI 10.1109/NGI.2011.5985948, June 2011.
[nec.euronf-2011] Mir、F.、Kutscher、D。、およびM. Brunner、「モビリティシナリオにおける輻輳暴露」、次世代インターネット（NGI）に関する第7回Euro-NF会議の議事録、DOI 10.1109 / NGI.2011.5985948、2011年6月。
[nec.globecom2010] Kutscher, D., Lundqvist, H., and F. Mir, "Congestion Exposure in Mobile Wireless Communications", In Proceedings of 2010 IEEE Global Telecommunications Conference (GLOBECOM), DOI 10.1109/GLOCOM.2010.5684362, December 2010.
[nec.globecom2010] Kutscher、D.、Lundqvist、H。、およびF. Mir、「モバイルワイヤレス通信における輻輳の露出」、2010年IEEEグローバルテレコミュニケーション会議（GLOBECOM）の議事録、DOI 10.1109 / GLOCOM.2010.5684362、2010年12月。
[raghavan2007] Raghavan, B., Vishwanath, K., Ramabhadran, S., Yocum, K., and A. Snoeren, "Cloud Control with Distributed Rate Limiting", ACM SIGCOMM Computer Communication Review, DOI 10.1145/1282427.1282419, October 2007.
[raghavan2007] Raghavan、B.、Vishwanath、K.、Ramabhadran、S.、Yocum、K。、およびA. Snoeren、「分散レート制限によるクラウド制御」、ACM SIGCOMMコンピュータ通信レビュー、DOI 10.1145 / 1282427.1282419、2007年10月。
[RFC6040] Briscoe, B., "Tunnelling of Explicit Congestion Notification", RFC 6040, DOI 10.17487/RFC6040, November 2010, <http://www.rfc-editor.org/info/rfc6040>.
[RFC6040] Briscoe、B。、「Tunnelling of Explicit Congestion Notification」、RFC 6040、DOI 10.17487 / RFC6040、2010年11月、<http://www.rfc-editor.org/info/rfc6040>。
[RFC6789] Briscoe, B., Ed., Woundy, R., Ed., and A. Cooper, Ed., "Congestion Exposure (ConEx) Concepts and Use Cases", RFC 6789, DOI 10.17487/RFC6789, December 2012, <http://www.rfc-editor.org/info/rfc6789>.
[RFC6789] Briscoe、B。、編、Woundy、R。、編、およびA. Cooper、編、「Congestion Exposure（ConEx）Concepts and Use Cases」、RFC 6789、DOI 10.17487 / RFC6789、2012年12月、 <http://www.rfc-editor.org/info/rfc6789>。
[RFC6817] Shalunov, S., Hazel, G., Iyengar, J., and M. Kuehlewind, "Low Extra Delay Background Transport (LEDBAT)", RFC 6817, DOI 10.17487/RFC6817, December 2012, <http://www.rfc-editor.org/info/rfc6817>.
[RFC6817] Shalunov、S.、Hazel、G.、Iyengar、J。、およびM. Kuehlewind、「Low Extra Delay Background Transport（LEDBAT）」、RFC 6817、DOI 10.17487 / RFC6817、2012年12月、<http：// www.rfc-editor.org/info/rfc6817>。
[RFC7713] Mathis, M. and B. Briscoe, "Congestion Exposure (ConEx) Concepts, Abstract Mechanism, and Requirements", RFC 7713, DOI 10.17487/RFC7713, December 2015, <http://www.rfc-editor.org/info/rfc7713>.
[RFC7713] Mathis、M。、およびB. Briscoe、「Congestion Exposure（ConEx）Concepts、Abstract Mechanism、and Requirements」、RFC 7713、DOI 10.17487 / RFC7713、December 2015、<http://www.rfc-editor.org / info / rfc7713>。
[TCP-MOD] Kuehlewind, M. and R. Scheffenegger, "TCP modifications for Congestion Exposure", Work in Progress, draft-ietf-conex-tcp-modifications-10, October 2015.
[TCP-MOD] Kuehlewind、M。、およびR. Scheffenegger、「輻輳露出のためのTCP変更」、作業中、draft-ietf-conex-tcp-modifications-10、2015年10月。
[TR23705] 3GPP, "System Enhancements for User Plane Congestion Management", 3GPP TR 23.705 13.0.0, December 2015.
[TR23705] 3GPP、「ユーザープレーン輻輳管理のシステム拡張」、3GPP TR 23.705 13.0.0、2015年12月。
[TR23829] 3GPP, "Local IP Access and Selected IP Traffic Offload (LIPA-SIPTO)", 3GPP TR 23.829 10.0.1, October 2011.
[TR23829] 3GPP、「ローカルIPアクセスと選択されたIPトラフィックオフロード（LIPA-SIPTO）」、3GPP TR 23.829 10.0.1、2011年10月。
[TS23203] 3GPP, "Policy and charging control architecture", 3GPP TS 23.203 13.6.0, December 2015.
[TS23203] 3GPP、「ポリシーと課金制御アーキテクチャ」、3GPP TS 23.203 13.6.0、2015年12月。
[TS23401] 3GPP, "General Packet Radio Service (GPRS) enhancements for Evolved Universal Terrestrial Radio Access Network (E-UTRAN) access", 3GPP TS 23.401 13.5.0, December 2015.
[TS23401] 3GPP、「進化したユニバーサル地上無線アクセスネットワーク（E-UTRAN）アクセスのための一般パケット無線サービス（GPRS）の機能強化」、3GPP TS 23.401 13.5.0、2015年12月。
[TS23402] 3GPP, "Architecture enhancements for non-3GPP accesses", 3GPP TS 23.402 13.4.0, December 2015.
[TS23402] 3GPP、「非3GPPアクセスのアーキテクチャの強化」、3GPP TS 23.402 13.4.0、2015年12月。
[TS26114] 3GPP, "IP Multimedia Subsystem (IMS); Multimedia telephony; Media handling and interaction", 3GPP TS 26.114 13.2.0, December 2015.
[TS26114] 3GPP、「IPマルチメディアサブシステム（IMS）;マルチメディアテレフォニー、メディアの処理と相互作用」、3GPP TS 26.114 13.2.0、2015年12月。
[TS29060] 3GPP, "General Packet Radio Service (GPRS); GPRS Tunnelling Protocol (GTP) across the Gn and Gp interface", 3GPP TS 29.060 13.3.0, December 2015.
[TS29060] 3GPP、「General Packet Radio Service（GPRS）; GPRS Tunneling Protocol（GTP）through Gn and Gp interface」、3GPP TS 29.060 13.3.0、2015年12月。
[TS29274] 3GPP, "3GPP Evolved Packet System (EPS); Evolved General Packet Radio Service (GPRS) Tunnelling Protocol for Control plane (GTPv2-C); Stage 3", 3GPP TS 29.274 13.4.0, December 2015.
[TS29274] 3GPP、「3GPP Evolved Packet System（EPS）; Evolved General Packet Radio Service（GPRS）Tunneling Protocol for Control Plan（GTPv2-C）; Stage 3」、3GPP TS 29.274 13.4.0、December 2015。
[TS36300] 3GPP, "Evolved Universal Terrestrial Radio Access (E-UTRA) and Evolved Universal Terrestrial Radio Access Network (E-UTRAN); Overall description; Stage 2", 3GPP TS 36.300 13.2.0, January 2016.
[TS36300] 3GPP、「Evolved Universal Terrestrial Radio Access（E-UTRA）and Evolved Universal Terrestrial Radio Access Network（E-UTRAN）; General Description; Stage 2」、3GPP TS 36.300 13.2.0、2016年1月。
This section provides an overview of the 3GPP "Evolved Packet System" (EPS [TS36300] [TS23401]) as a specific example of a mobile communication architecture. Of course, other architectures exist, but the EPS is used as one example to demonstrate the applicability of congestion exposure concepts and mechanisms.
このセクションでは、モバイル通信アーキテクチャの具体例として、3GPP「Evolved Packet System」（EPS [TS36300] [TS23401]）の概要を説明します。もちろん、他のアーキテクチャも存在しますが、EPSは、輻輳露出の概念とメカニズムの適用性を示す1つの例として使用されます。
The EPS architecture and some of its standardized interfaces are depicted in Figure 5. The EPS provides IP connectivity to UE (i.e., mobile nodes) and access to operator services, such as global Internet access and voice communications. The EPS comprises the radio access network called Evolved Universal Terrestrial Radio Access Network (E-UTRAN) and the core network called the Evolved Packet Core (EPC). QoS is supported through an EPS bearer concept, providing bindings to resource reservation within the network.
EPSアーキテクチャとその標準化されたインターフェースの一部を図5に示します。EPSは、UE（つまりモバイルノード）へのIP接続と、グローバルインターネットアクセスや音声通信などのオペレーターサービスへのアクセスを提供します。 EPSは、Evolved Universal Terrestrial Radio Access Network（E-UTRAN）と呼ばれる無線アクセスネットワークと、Evolved Packet Core（EPC）と呼ばれるコアネットワークで構成されています。 QoSはEPSベアラーコンセプトを通じてサポートされ、ネットワーク内のリソース予約へのバインディングを提供します。
+-------+
+-------+ | PCRF |
| HSS | /+-------+\
+-------+ Gx/ \Rx
| / \
| / \
| +-------+ SGi +-------+
| | P-GW |=========| AF |
| +-------+ +-------+
HPLMN | |
------------------------------|--------------|----------------------
VPLMN | |
+-------+ |
| MME | |
/+-------+\ |S8
S1-MME / \ |
/ \S11 |
/ \ |
+-----------+ \ |
+----+ LTE-Uu | | \ |
| UE |========| | S1-U +-------+
+----+ | E-UTRAN |==============| S-GW |
| (eNBs) | +-------+
| |
+-----------+
Figure 5: EPS Architecture Overview (Roaming Case)
図5：EPSアーキテクチャの概要（ローミングケース）
Note: HPLMN - Home Public Land Mobile Network VPLMN - Visited Public Land Mobile Network AF - Application Function SGi - Service Gateway Interface LTE-Uu - LTE Radio Interface
注：HPLMN-ホームパブリックランドモバイルネットワークVPLMN-訪問済みパブリックランドモバイルネットワークAF-アプリケーション機能SGi-サービスゲートウェイインターフェースLTE-Uu-LTE無線インターフェース
The Evolved NodeB (eNB), the LTE base station, is part of the access network that provides radio resource management, header compression, security, and connectivity to the core network through the S1 interface. In an LTE network, the control-plane signaling traffic and the data traffic are handled separately. The eNBs transmit the control traffic and data traffic separately via two logically separate interfaces.
LTE基地局であるEvolved NodeB（eNB）は、無線リソース管理、ヘッダー圧縮、セキュリティ、およびS1インターフェイスを介したコアネットワークへの接続を提供するアクセスネットワークの一部です。 LTEネットワークでは、コントロールプレーンシグナリングトラフィックとデータトラフィックは別々に処理されます。 eNBは、論理的に分離された2つのインターフェースを介して、制御トラフィックとデータトラフィックを別々に送信します。
The Home Subscriber Server (HSS) is a database that contains user subscriptions and QoS profiles. The Mobility Management Entity (MME) is responsible for mobility management, user authentication, bearer establishment and modification, and maintenance of the UE context.
Home Subscriber Server（HSS）は、ユーザーのサブスクリプションとQoSプロファイルを含むデータベースです。モビリティ管理エンティティ（MME）は、モビリティ管理、ユーザー認証、ベアラの確立と変更、およびUEコンテキストのメンテナンスを担当します。
The Serving Gateway (S-GW) is the mobility anchor and manages the user-plane data tunnels during the inter-eNB handovers. It tunnels all user data packets and buffers downlink IP packets destined for UEs that happen to be in idle mode.
サービングゲートウェイ（S-GW）はモビリティアンカーであり、eNB間ハンドオーバー中のユーザープレーンデータトンネルを管理します。すべてのユーザーデータパケットをトンネリングし、偶発的にアイドルモードになっているUE宛てのダウンリンクIPパケットをバッファします。
The PDN Gateway (P-GW) is responsible for IP address allocation to the UE and is a tunnel endpoint for user-plane and control-plane protocols. It is also responsible for charging, packet filtering, and policy-based control of flows. It interconnects the mobile network to external IP networks, e.g., the Internet.
PDNゲートウェイ（P-GW）は、UEへのIPアドレス割り当てを担当し、ユーザープレーンおよびコントロールプレーンプロトコルのトンネルエンドポイントです。また、課金、パケットフィルタリング、ポリシーベースのフロー制御も行います。モバイルネットワークをインターネットなどの外部IPネットワークに相互接続します。
In this architecture, data packets are not sent directly on an IP network between the eNB and the gateways. Instead, every packet is tunneled over a tunneling protocol -- the GPRS Tunneling Protocol (GTP) [TS29060] over UDP/IP. A GTP path is identified in each node with the IP address and a UDP port number on the eNB/gateways. The GTP protocol carries both the data traffic (GTP-U tunnels) and the control traffic (GTP-C tunnels [TS29274]). Alternatively, PMIPv6 is used on the S5 interface between S-GW and P-GW.
このアーキテクチャでは、データパケットはeNBとゲートウェイ間のIPネットワークに直接送信されません。代わりに、すべてのパケットはトンネリングプロトコル（UDP / IPを介したGPRSトンネリングプロトコル（GTP）[TS29060]）を介してトンネリングされます。 GTPパスは、eNB /ゲートウェイのIPアドレスとUDPポート番号を使用して各ノードで識別されます。 GTPプロトコルは、データトラフィック（GTP-Uトンネル）と制御トラフィック（GTP-Cトンネル[TS29274]）の両方を伝送します。または、PMIPv6は、S-GWとP-GW間のS5インターフェイスで使用されます。
The above is very different from an end-to-end path on the Internet where the packet forwarding is performed at the IP level. Importantly, we observe that these tunneling protocols give the operator a large degree of flexibility to control the congestion mechanism incorporated with the GTP/PMIPv6 protocols.
上記は、IPレベルでパケット転送が実行されるインターネット上のエンドツーエンドパスとは大きく異なります。重要なのは、これらのトンネリングプロトコルは、GTP / PMIPv6プロトコルに組み込まれた輻輳メカニズムを制御するための高度な柔軟性をオペレーターに与えることです。
Acknowledgements
謝辞
We would like to thank Bob Briscoe and Ingemar Johansson for their support in shaping the overall idea and in improving the document by providing constructive comments. We would also like to thank Andreas Maeder and Dirk Staehle for reviewing the document and for providing helpful comments.
Bob BriscoeとIngemar Johanssonが、全体的なアイデアを形作り、建設的なコメントを提供してドキュメントを改善する上での支援に感謝します。また、このドキュメントのレビューと有益なコメントの提供について、Andreas MaederとDirk Staehleに感謝します。
Authors' Addresses
著者のアドレス
Dirk Kutscher NEC Kurfuersten-Anlage 36 Heidelberg Germany
Dirk Kutscher NEC Kurfuersten-Anlage 36ハイデルベルクドイツ
Email: kutscher@neclab.eu Faisal Ghias Mir NEC Kurfuersten-Anlage 36 Heidelberg Germany
メール：kutscher@neclab.eu Faisal Ghias Mir NEC Kurfuersten-Anlage 36ハイデルベルクドイツ
Email: faisal.mir@gmail.com
Rolf Winter NEC Kurfuersten-Anlage 36 Heidelberg Germany
Rolf Winter NEC Kurfuersten-Anlage 36ハイデルベルクドイツ
Email: rolf.winter@neclab.eu
Suresh Krishnan Ericsson 8400 Blvd Decarie Town of Mount Royal, Quebec Canada
Suresh Krishnan Ericsson 8400 Blvd Decarie Town of Mount Royal、Quebec Canada
Email: suresh.krishnan@ericsson.com
Ying Zhang Hewlett Packard Labs 3000 Hannover Street Palo Alto, CA 94304 United States
ying Zhang Hewlett Packard labs 3000 Hannover street Palo alto、CA 94304アメリカ合衆国
Email: ying.zhang13@hp.com
Carlos J. Bernardos Universidad Carlos III de Madrid Av. Universidad, 30 Leganes, Madrid 28911 Spain
カルロスJ.ベルナルドスカルロスIIIマドリッド大学Av。Universidad、30 Leganes、Madrid 28911 Spain
Phone: +34 91624 6236
Email: cjbc@it.uc3m.es
URI: http://www.it.uc3m.es/cjbc/