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
AbstractThis 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. 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. 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.
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. 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
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. 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. 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. 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.
Appendix A and the 3GPP, ECN, and ConEx specifications referenced there. eNB Evolved NodeB: LTE base station HSS Home Subscriber Server S-GW Serving Gateway: mobility anchor and tunnel endpoint 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 UE User Equipment: mobile terminals GTP GPRS Tunneling Protocol [TS29060] GTP-U GTP User Data Tunneling [TS29060] GTP-C GTP Control [TS29060]
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.
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: A. as additional information to assist network functions to impose different QoS for different application sessions; and 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. 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. 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. 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. 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. 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. raghavan2007]) and on specific optimizations (see [nec.euronf-2011]) for congestion exposure and policing in mobility scenarios.
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.
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. 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. 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. 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).
+------------+ | 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
----------------------------------------------------- | +----+ +-------+ +-------+ +-------+ | | | UE |=====| eNB |=====| S-GW |=====| P-GW | | | +----+ +-------+ +-------+ +-------+ | | | | | Operator A | | --------------------------------------------|-------- | ----------------------- | | | Internet | | | ----------------------- | --------------------------------------------|-------- | +----+ +-------+ +-------+ +-------+ | | | UE |=====| eNB |=====| S-GW |=====| P-GW | | | +----+ +-------+ +-------+ +-------+ | | | | Operator B | ----------------------------------------------------- Figure 2: ConEx Deployment across Operator Domains
----------------------------------------------------- | |--- 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
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 Note: DL stands for "downlink". RFC7713] describes the following congestion exposure components: o Modified senders that send congestion exposure information in response to congestion feedback. o Receivers that generate congestion feedback (leveraging existing behavior or requiring new functions). o Audit functions that audit ConEx signals against actual congestion, e.g., by monitoring flows or aggregate of flows. o Policy devices that monitor congestion exposure information and act on the flows according to the operator's policy. 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.
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. 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. 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.
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. 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. 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). 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). 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.
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. 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. 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. 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 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]. 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.
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. 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. 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. 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. 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. 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. 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. The ConEx protocol specifications [CONEX-DESTOPT] and [TCP-MOD] discuss additional security considerations that would also apply to mobile network deployments. [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-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. [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.
[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. [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.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. [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. [RFC6040] Briscoe, B., "Tunnelling of Explicit Congestion Notification", RFC 6040, DOI 10.17487/RFC6040, November 2010, <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>. [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>. [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>. [TCP-MOD] Kuehlewind, M. and R. Scheffenegger, "TCP modifications for Congestion Exposure", Work in Progress, draft-ietf- conex-tcp-modifications-10, October 2015.
[TR23705] 3GPP, "System Enhancements for User Plane Congestion Management", 3GPP TR 23.705 13.0.0, December 2015. [TR23829] 3GPP, "Local IP Access and Selected IP Traffic Offload (LIPA-SIPTO)", 3GPP TR 23.829 10.0.1, October 2011. [TS23203] 3GPP, "Policy and charging control architecture", 3GPP TS 23.203 13.6.0, December 2015. [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. [TS23402] 3GPP, "Architecture enhancements for non-3GPP accesses", 3GPP TS 23.402 13.4.0, December 2015. [TS26114] 3GPP, "IP Multimedia Subsystem (IMS); Multimedia telephony; Media handling and interaction", 3GPP TS 26.114 13.2.0, December 2015. [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. [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. [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] [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. 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.
+-------+ +-------+ | 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) 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 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. 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.
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. 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. 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. 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.
Faisal Ghias Mir NEC Kurfuersten-Anlage 36 Heidelberg Germany Email: email@example.com Rolf Winter NEC Kurfuersten-Anlage 36 Heidelberg Germany Email: firstname.lastname@example.org Suresh Krishnan Ericsson 8400 Blvd Decarie Town of Mount Royal, Quebec Canada Email: email@example.com Ying Zhang Hewlett Packard Labs 3000 Hannover Street Palo Alto, CA 94304 United States Email: firstname.lastname@example.org Carlos J. Bernardos Universidad Carlos III de Madrid Av. Universidad, 30 Leganes, Madrid 28911 Spain Phone: +34 91624 6236 Email: email@example.com URI: http://www.it.uc3m.es/cjbc/