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
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.
本备忘录描述了拥塞暴露（ConEx）的移动通信用例，特别关注那些在架构上类似于3GPP演进分组系统（EPS）的移动通信网络。本备忘录简要概述了这些网络（包括接入网络和核心网络）的体系结构以及当前的QoS机制，然后讨论了如何应用拥塞暴露概念。基于这一讨论，本备忘录提出了一系列适用于这些移动网络的ConEx机制要求。
Status of This Memo
关于下段备忘
This document is not an Internet Standards Track specification; it is published for informational purposes.
本文件不是互联网标准跟踪规范；它是为了提供信息而发布的。
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）的产品。它代表了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.
版权所有（c）2016 IETF信托基金和确定为文件作者的人员。版权所有。本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
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
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.
移动数据流量继续快速增长。无线运营商面临的挑战是支持带宽需求不断增长的更多用户。为了满足这些带宽要求，需要新技术来帮助运营商有效利用可用的网络资源。这类新技术可以被视为有用的两个具体领域是资源分配和流量管理。
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-SIGCOMM 2013]。这意味着可能只有一小部分用户负责蜂窝网络中的大部分流量。鉴于这种高度扭曲的用户行为和有限且昂贵的资源（如无线频谱），为了实现更好的网络资源利用和公平的资源共享，资源分配和使用责任是运营商需要解决的两个重要问题。如[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.
这种用例的具体示例可以是移动通信网络，例如3GPP EPS网络，其中ue（用户设备）（即，移动终端主机）、服务器和缓存、接入网络以及可能的运营商的核心网络可以是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和此处引用的3GPP、ECN和ConEx规范中对大部分进行了解释并将其置于系统上下文中。
eNB Evolved NodeB: LTE base station
eNB演进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）通常被认为是进化包核心（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可以两种不同的方式使用：
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）[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网络。如今，用户通常配备双模移动电话（例如，集成第三代/第四代蜂窝和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
总之，可以说3GPP EPS和其他移动通信架构中的流量管理非常重要。目前，更多的静态方法是基于准入控制和
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.
目前正在使用静态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网络正在转变为通用接入网络，在移动（智能）电话用户、使用笔记本电脑的移动用户、使用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.
大多数流量可能被归类为尽力而为流量，而不区分（例如）定期操作系统更新和应用程序商店下载与基于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的监管/计费方法——即，为非ConEx UE应用固定容量上限，为支持ConEx的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.
要考虑的另一个方面是添加选定的IP业务卸载（SIPTO）和本地IP接入（LIPA）[TR23 829 ]，即，诸如大容量因特网业务的某些业务实际上不通过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:
我们在下图中展示了四种不同的拥塞暴露部署场景：
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由发送数据的服务器（Internet中的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普遍用于操作员之间（如图2所示），具有端到端的ConEx反馈回路。在这里，运营商仍然可以采用当地政策、拥塞核算方案等，并且他们可以使用拥塞贡献信息来确定互连协议。这种部署场景意味着运营商愿意相互暴露拥塞。
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 |
-----------------------------------------------------
+------------+
| 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 |
-----------------------------------------------------
-----------------------------------------------------
| +----+ +-------+ +-------+ +-------+ |
| | 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 |
-----------------------------------------------------
-----------------------------------------------------
| |--- 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 |
| | | |
+---------------+ +--------------+
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.
需要考虑的两个方面很重要：1）如何实施ConEx协议机制，以及需要对现有网络进行哪些修改；2）ConEx功能实体的最佳位置（允许非侵入性添加）。我们将在以下部分讨论这两个方面。
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]的拥塞暴露信息包含在目的地选项标头字段中，该字段要求在想要评估路径拥塞的发送方和节点处进行最小的更改。destination option header字段不影响网络中的非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节规定了ECN在无线链路（在eNB和UE之间）上用于拥塞通知的用法，[TS26114]规定了如何将其用于语音编解码器自适应。ECN的完整端到端支持需要隧道行为规范，该规范应基于[RFC6040]（适用于IP隧道中的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监管和审计职能的潜在场所将是eNBs、S-GWs或P-GWs。当然，运营商部署仍可能提供额外的支持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所示的场景中），运营商可以有不同的流量监管要求。虽然警务原则上是位置不可知的，但重要的是考虑与EPS体系结构有关的要求（图5），例如在P GWS和ENBS之间的隧道。监管可能需要访问订户信息（例如，拥塞贡献配额）或特定于用户的计费，这表明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.
对于上行方向，设计监控和策略执行功能自然有不同的选项。一种可能的方法是监控中央网关节点（如P-GWs）上的拥塞暴露，该节点向PCRF提供所需的接口，但在接入网络（即，在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.
这样的设置将启用第2节中描述的所有ConEx用例，而无需对EPS架构进行重大更改。它还将使运营商能够重新利用现有的基础设施，特别是无线基站、PCRF和家庭用户服务器（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- GWS和P-GWS之类的元素上的CONEX函数，考虑移动性和隧道协议要求是很重要的。LTE提供了两种替代方法：PMIPv6[TS23402]和GPRS隧道协议（GTP）。因此，对于拥塞信息（响应）的传播，隧道考虑非常重要。
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中，每用户信息通常是PCC实体（如PCRF）访问的用户配置文件（存储在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还可用于补充目前正在开发的基于3GPP的拥塞管理机制，例如在[TR23705]中描述的用户平面拥塞管理（UPCON）工作项中。
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.
我们已经描述了将ConEx作为一种机制添加到基于3GPP LTE的网络中的一些可能性，并展示了如何以增量的方式实现这一点（从部分部署开始）。这样的部分部署可以在每个运营商域的基础上完成，而不需要更改标准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.
移动性：与有线网络相比，蜂窝网络的一个独特特征是存在用户移动性。随着用户位置的变化，同一设备可以通过不同的基站（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.
多址：在蜂窝网络中，多址技术可以共存。在这种情况下，用户可以同时对多个应用程序甚至单个应用程序使用多址技术。如果拥塞策略是基于每个用户设置的，那么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隧道中的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
值得注意的是，ConEx旨在作为移动网络中现有QoS机制的补充，而不是替代。例如，部署在3GPP移动网络中的ConEx
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.
通过提供更多动态网络信息来补充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-DESTOP]和[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]Krishnan，S.，Kuehlewind，M.，Briscoe，B.，和C.Ralli，“拥塞暴露的IPv6目标选项（CONEX）”，正在进行的工作，草案-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.
[dash]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-SIGCOM2013]黄，J.，钱，F.，郭，Y，周，Y，徐，Q，毛，Z，森，S和O.斯帕切克，“lte的深入研究：网络协议和应用行为对性能的影响”，2013年ACM SIGCOMM会议记录，DOI 10.1145/248601.248606，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）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.Snoren，“具有分布式速率限制的云控制”，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.，“明确拥塞通知的隧道挖掘”，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.，Ed.，Woundy，R.，Ed.，和A.Cooper，Ed.，“拥塞暴露（ConEx）概念和用例”，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，“低额外延迟背景传输（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，“拥堵暴露（ConEx）概念、抽象机制和要求”，RFC 7713，DOI 10.17487/RFC7713，2015年12月<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修改”，正在进行的工作，草案-ietf-conex-TCP-modifications-102015年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.012015年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.11911年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，“通用分组无线业务（GPRS）增强，用于演进型通用地面无线接入网（E-UTRAN）接入”，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.012015年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，“通用分组无线业务（GPRS）；通过Gn和Gp接口的GPRS隧道协议（GTP）”，3GPP TS 29.060 13.3.012015年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演进分组系统（EPS）；用于控制平面的演进通用分组无线业务（GPRS）隧道协议（GTPv2-C）；第3阶段”，3GPP TS 29.274 13.4.02015年12月。
[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，“演进通用地面无线接入（E-UTRA）和演进通用地面无线接入网络（E-UTRAN）；总体描述；第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“演进分组系统”（EPS[TS36300][TS23401]）。当然，也存在其他体系结构，但EPS被用作一个示例来演示拥塞暴露概念和机制的适用性。
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包括称为演进通用地面无线电接入网络（E-UTRAN）的无线电接入网络和称为演进分组核心（EPC）的核心网络。通过EPS承载概念支持QoS，提供网络内资源预留的绑定。
+-------+
+-------+ | 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) | +-------+
| |
+-----------+
+-------+
+-------+ | 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.
演进型NodeB（eNB），即LTE基站，是接入网络的一部分，该接入网络通过S1接口提供无线资源管理、报头压缩、安全性和到核心网络的连接。在LTE网络中，控制平面信令业务和数据业务被分开处理。enb通过两个逻辑上独立的接口分别发送控制通信量和数据通信量。
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.
家庭订户服务器（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]。在每个节点中使用eNB/网关上的IP地址和UDP端口号标识GTP路径。GTP协议承载数据通信量（GTP-U隧道）和控制通信量（GTP-C隧道[TS29274]）。或者，在S-GW和P-GW之间的S5接口上使用PMIPv6。
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
德国海德堡36号Dirk Kutscher NEC Kurfuersten Anlage
Email: kutscher@neclab.eu
Email: kutscher@neclab.eu
Faisal Ghias Mir NEC Kurfuersten-Anlage 36 Heidelberg Germany
德国海德堡36号费萨尔·吉亚斯·米尔·内克·库尔弗斯坦安拉格酒店
Email: faisal.mir@gmail.com
Email: faisal.mir@gmail.com
Rolf Winter NEC Kurfuersten-Anlage 36 Heidelberg Germany
德国海德堡36号Rolf Winter NEC Kurfuersten安乐酒店
Email: rolf.winter@neclab.eu
Email: rolf.winter@neclab.eu
Suresh Krishnan Ericsson 8400 Blvd Decarie Town of Mount Royal, Quebec Canada
Suresh Krishnan Ericsson加拿大魁北克皇家山Decarie镇8400大道
Email: suresh.krishnan@ericsson.com
Email: suresh.krishnan@ericsson.com
Ying Zhang Hewlett Packard Labs 3000 Hannover Street Palo Alto, CA 94304 United States
美国加利福尼亚州帕洛阿尔托汉诺威街3000号惠普实验室，邮编94304
Email: ying.zhang13@hp.com
Email: ying.zhang13@hp.com
Carlos J. Bernardos Universidad Carlos III de Madrid Av. Universidad, 30 Leganes, Madrid 28911 Spain
卡洛斯·J·贝尔纳多斯大学卡洛斯三世马德里大道。西班牙马德里勒冈30号大学28911
Phone: +34 91624 6236
Email: cjbc@it.uc3m.es
URI: http://www.it.uc3m.es/cjbc/
Phone: +34 91624 6236
Email: cjbc@it.uc3m.es
URI: http://www.it.uc3m.es/cjbc/