IETF D. Kutscher
Internet-Draft F. Mir
Intended status: Informational R. Winter
Expires: September 8, 2011 NEC
S. Krishnan
Y. Zhang
Ericsson
March 7, 2011
Mobile Communication Congestion Exposure Scenario
draft-kutscher-conex-mobile-00
Abstract
This memo describes a mobile communications use case for congestion
exposure (CONEX) with a particular focus on mobile communication
networks such as 3GPP LTE. The draft describes the architecture of
these networks (access and core networks), current QoS mechanisms and
then discusses how congestion exposure concepts could be applied.
Based on this, this memo suggests a set of requirements for CONEX
mechanisms that particularly apply to mobile networks.
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 8, 2011.
Copyright Notice
Copyright (c) 2011 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
Kutscher, et al. Expires September 8, 2011 [Page 1]
Internet-Draft CONEX Mobile Scenario March 2011
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Overview of 3GPP's Evolved Packet System (EPS) . . . . . . . . 3
3. CONEX Use Cases in the Mobile Communication Scenario . . . . . 5
3.1. CONEX as a basis for traffic management . . . . . . . . . 6
3.2. CONEX to incentivize scavenger transports . . . . . . . . 6
3.3. Accounting for Congestion Volume . . . . . . . . . . . . . 7
3.4. CONEX as a form of differential QoS . . . . . . . . . . . 7
3.5. Partial vs. Full Deployment . . . . . . . . . . . . . . . 8
3.6. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 8
4. CONEX in the EPS . . . . . . . . . . . . . . . . . . . . . . . 9
4.1. Possible Deployment Scenarios . . . . . . . . . . . . . . 9
4.2. Implementing CONEX Functions in the EPS . . . . . . . . . 11
5. Implications for CONEX . . . . . . . . . . . . . . . . . . . . 13
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
7. Security Considerations . . . . . . . . . . . . . . . . . . . 14
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
8.1. Normative References . . . . . . . . . . . . . . . . . . . 14
8.2. Informative References . . . . . . . . . . . . . . . . . . 14
Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15
Kutscher, et al. Expires September 8, 2011 [Page 2]
Internet-Draft CONEX Mobile Scenario March 2011
1. Introduction
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
Mobile data traffic continues to grows rapidly. The challenge
wireless operators face is to support more subscribers with higher
bandwidth requirements. To meet the bandwidth demand, operators need
to seek for new technologies to efficiently utilize the available
network resources, in particular, this concerns resource allocation
and flow management. Ample statistics for network traffic from
cellular networks are available, stating that many short flows exist,
but that a few large flows constitute a large part of the overall
traffic volume. Measurement studies have shown that a small number
of users is responsible for the most part of the traffic in cellular
networks. With the highly skewed network access behavior, more
expensive resources in cellular networks as compared to other
networks and the rapidly increasing network utilization, resource
allocation and usage accountability are two important issues for
operators to solve in order to achieve a better, accountable network
resource utilization. CONEX, as described in
[I-D.ietf-conex-concepts-uses] is a technology to base this upon.
The CONEX congestion exposure mechanism is intended as a general
technology that could be applied as a key element of congestion
management solutions in a variety of use cases. The IETF CONEX WG
will however work on a specific use case, where the end hosts and the
network that contains the destination end host 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 LTE network, where the UE (User Equipment,
i.e. mobile end host), its access network and possibly an operator's
core network can be CONEX-enabled. This draft describes the
architecture of such networks (access and core networks), current QoS
mechanisms and then discusses how congestion exposure concepts could
be applied. Using this use case as a basis, a set of requirements
for CONEX mechanisms are described.
2. Overview of 3GPP's Evolved Packet System (EPS)
This section provides an overview of 3GPP's "Evolved Packet System"
(EPS [3GPP.36.300]) as a specific example of a mobile communication
architecture in order to illustrate congestion exposure applicability
in this memo. There are other mobile communication architectures.
Kutscher, et al. Expires September 8, 2011 [Page 3]
Internet-Draft CONEX Mobile Scenario March 2011
The EPS architecture and its standardized interfaces are depicted in
Figure 1. The EPS provides IP connectivity to UEs (user equipment,
i.e., mobile nodes) and access to operator services, such as global
Internet access and voice communications. The EPS comprises the
access (evolved UMTS Terrestrial Radio Access Network, E-UTRAN) and
the core network (Evolved Packet Core, EPC). QoS is supported
through an EPS bearer concept, providing hierarchical bindings within
the network.
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 LTE an 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
different interfaces.
The Home Subscriber Server, HSS, is a database that contains users
subscription and QoS profile. The Mobility Management Entity, MME,
is responsible for 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 Packet Gateway, P-GW, is responsible for IP address allocation to
the UE and is a tunnel endpoint for mobility 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 GWs. Instead, every packet is sent
in a tunneling protocol - the GPRS Tunneling Protocol (GTP
[3GPP.29.060]) over UDP/IP. A GTP path is identified in each node
with the IP address and a UDP port number on the eNB/GWs. The GTP
protocol carries both the data traffic (GTP-U tunnels) and the
control traffic (GTP-C tunnels [3GPP.29.274]).
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 protocols.
Kutscher, et al. Expires September 8, 2011 [Page 4]
Internet-Draft CONEX Mobile Scenario March 2011
+-------+
+-------+ | PCRF |
| HSS | /+-------+\
+-------+ Gx/ \Rx
| / \
| / \
| +-------+ SGi +-------+
| | PDN |=========|IP Svr |
| +-------+ +-------+
HPMN | |
------------------------------|--------------|----------------------
VPLMN | |
+-------+ |
| MME | |
/+-------+\ |S8
S1-MME / \ |
/ \S11 |
/ \ |
+-----------+ \ |
+----+ LTE-Uu | | \ |
| UE |========| | S1-U +-------+
+----+ | E-UTRAN |==============| S-GW |
| | +-------+
| |
+-----------+
Figure 1: EPS Architecture Overview
3. CONEX Use Cases in the Mobile Communication Scenario
Given the initial scope of CONEX, the problem that mobile operators
are facing and large networks that are under tight operator control,
including the mobile end devices to a certain extend, the LTE use
case appears to be an ideal first target deployment scenario. In
addition, mobile networks already have many of the principle
functions that the CONEX use cases require such as accounting.
Mobile networks however have characteristics that differ
significantly enough from fixed network architectures that these
should be taken into account.
[I-D.ietf-conex-concepts-uses] describes fundamental congestion
exposure concepts and a set of use cases for applying congestion
exposure mechanisms to achieve different functions in traffic
management, accounting etc. In this section, we relate these CONEX
use cases to the general mobile communication scenario in order to
validate the use cases for this scenario.
Kutscher, et al. Expires September 8, 2011 [Page 5]
Internet-Draft CONEX Mobile Scenario March 2011
3.1. CONEX as a basis for traffic management
Traffic management is a very important function in mobile
communication networks. Since wireless resources have been
considered scarce and since user mobility and shared bandwidth in the
wireless access create a certain dynamics with respect to available
bandwidth, these resources are traditionally managed very tightly
(admission control for bearers establishment etc.)
In LTE, the QoS requirements for different applications running on a
UE is supported by a bearer concept which is managed by the network.
Each bearer has an associated QoS Class identifier (QCI) and an
Allocation and retention policy (ARP) that has been standardized for
uniform traffic handling (across implementations). For the necessary
QoS across the mobile network, an EPS bearer is maintained that
crosses different interfaces in the network and maps to lower layer
bearers for packet forwarding. A radio bearer transports traffic
between a UE and eNB whereas S1 bearer transports traffic between the
eNB and S-GW. Primarily LTE offers two types of bearer: Guaranteed
Bit rate bearer for real time communication, e.g., Voice calls etc
and Non-Guaranteed bit rate, e.g., best effort traffic for web access
etc. Packets mapped to the same EPS bearer receive the same bearer
level packet forwarding treatment.
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 EPC -- on, for example, a PDN
gateway, and some operators do in fact deploy DPI today. 3GPP has a
current work item on "Service Awareness and Privacy Policies" that is
chartered to add DPI-related extensions to the PCC architecture
[3GPP.23.203].
In summary, it can be said that traffic management in 3GPP EPS and
other mobile communication architectures in very important.
Previously more static approach based on admission control and static
QoS have been applied, but recently, there has been a perceived need
for more dynamic mechanisms such as DPI. Adding CONEX support might
thus require revisiting the PCC architecture, depending on the scope
and impact of a CONEX-based traffic management approach.
3.2. CONEX to incentivize scavenger transports
As 3G and LTE networks are turning into universal access networks
that are shared between mobile (smart) phone users, mobile users with
laptop PC, home users with LTE access etc., the mobile communication
network will be used like any other access network, i.e., different
applications from different users compete for bandwidth.
Kutscher, et al. Expires September 8, 2011 [Page 6]
Internet-Draft CONEX Mobile Scenario March 2011
Most of this traffic is likely to be classified as best-effort
traffic, so that it will eventually be difficult to distinguish
periodic OS updates, application store downloads from web (browser)-
based communication (this is reflected by the current DPI activities
in 3GPP). Having said that, the general argument for scavenger
transports apply. Especially when wireless and backhaul resources
are scarce, incentivizing users to use less-than best effort
transport for non-interactive background communication would improve
the overall utility of the network. It can be argued that, if this
would be done with a CONEX approach, much of the envisioned DPI
mechanisms would not be needed.
This would work best, if the network did not do any traffic class
segregation below the IP layer, i.e., if all traffic would be in the
same traffic class. With current specifications, that would be
possible in principle.
3.3. Accounting for Congestion Volume
3G and LTE networks provide extensive support for accounting and
charging already, for example cf. the PCC architecture. 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 their data contractual volume budget for the charging period.
Changing this data volume-based accounting to a congestion-based
accounting would be possible in principle, especially since there
already is an elaborated per-user accounting system available. Also,
an operator-provided mobile communication network can be seen as a
network domain within such congestion volume accounting would be
possible, without requiring any support from the global Internet.
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, the user is accounted for both received and sent data,
which would facilitate congestion volume accounting as well.
3.4. CONEX as a form of differential QoS
As mentioned above, 3GPP mobile communication networks provide an
elaborate QoS architecture. In LTE, the idea is to map different
traffic classes onto different logical channels (bearers) with
individual QoS configuration.
Kutscher, et al. Expires September 8, 2011 [Page 7]
Internet-Draft CONEX Mobile Scenario March 2011
It can be argued whether this approach is sufficient in a world where
most traffic is on TCP port 80 and whether some more application
control would be useful.
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.
3.5. Partial vs. Full Deployment
A 3GPP mobile communication network can be seen as separate network
domain that would enable the introduction of CONEX through a careful
standardization of interfaces and behavior of its system elements.
While it can be possible to deploy CONEX in a single operator's
network only, it may in fact not be practical, since support on
mobile nodes (UEs) may be required to actually implement the host end
transport mechanisms.
Aspects such as roaming have to be considered, i.e., what happens if
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.
Another aspect to consider is the addition of Selected IP Traffic
Offload (SIPTO) and Local Breakout (LIPA), also see [3GPP.23.829],
i.e., the idea that some traffic (e.g., 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.
3.6. Summary
In summary, the 3GPP EPS in a system architecture that can benefit
from congestion exposure in multiple ways, as we have shown by this
brief description of CONEX use cases in this environment. Dynamic
traffic and congestion management is an acknowledged important
requirement for the EPS, also illustrated by the current DPI work for
EPS.
Moreover, we believe that networks such as an LTE mobile
communication networks 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), a single mobile network deployment is under full
control of a single operator, which can enable operator-local
enhancement without the need to change the complete architecture.
Kutscher, et al. Expires September 8, 2011 [Page 8]
Internet-Draft CONEX Mobile Scenario March 2011
In 3GPP EPS, interfaces between all elements of the architecture are
subject to standardization, including UE interfaces and eNodeB
interfaces, so that a standardized approach can be feasible as well.
4. CONEX in the EPS
The CONEX mechanism is still work in progress in the IETF working
group. Still, we would like to discuss a few options for how such a
mechanism (and possibly additional policing functions) could
eventually be deployed in 3GPP's EPS. Note that this description of
options is not intended as a complete set of possible approaches --
it is merely intended for discussing a few options. More details
will be provided in a future revision of this document.
4.1. Possible Deployment Scenarios
There are different possible ways 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.
We can differentiate two fundamental deployment scenarios for
congestion exposure as depicted in the figures below: 1) 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. For 2), 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 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.
Kutscher, et al. Expires September 8, 2011 [Page 9]
Internet-Draft CONEX Mobile Scenario March 2011
-----------------------------------------------------
| +----+ +-------+ +-------+ +-------+ |
| | UE |=====| eNB |=====| S-GW |=====| P-GW | |
| +----+ +-------+ +-------+ +-------+ |
| | |
| Operator A | |
--------------------------------------------|--------
|
-----------------------
| |
| Internet |
| |
-----------------------
|
--------------------------------------------|--------
| +----+ +-------+ +-------+ +-------+ |
| | UE |=====| eNB |=====| S-GW |=====| P-GW | |
| +----+ +-------+ +-------+ +-------+ |
| |
| Operator B |
-----------------------------------------------------
Figure 2: CONEX deployment across operator domains
Kutscher, et al. Expires September 8, 2011 [Page 10]
Internet-Draft CONEX Mobile Scenario March 2011
-----------------------------------------------------
| |--- 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
We consider both scenarios to be relevant and believe that both of
them are within the scope of the CONEX WG charter. A more detailed
description of these descriptions will be provided in a future
version of this document.
4.2. Implementing CONEX Functions in the EPS
We expect a CONEX solution to consist of different functions that
should be considered when implementing congestion exposure in 3GPP's
EPS.
o The CONEX mechanism defines how congestion is actually indicated,
how hosts can re-act to it, and how congestion contribution is
finally declared. For ECN-based mechanisms, ECN marking in
routers would be part of the mechanism.
o Policing functions are normally expected to manage the
experienced/declared congestion in the network. They are
considered important functions in an overall CONEX framework, as
they provide incentives to users/applications to actually re-act
to congestion indication. Also, it is assumed that accounting is
performed based on function related to policing. Finally,
Kutscher, et al. Expires September 8, 2011 [Page 11]
Internet-Draft CONEX Mobile Scenario March 2011
implementations of CONEX may require the network to enforce proper
congestion contribution declaration (i.e., as droppers in the Re-
ECN proposal).
In the following, we discuss some possible placement strategies for
CONEX functional entities in the EPS and for possible optimizations
for both the uplink and the downlink. In order to provide a
comprehensive CONEX-based capacity management framework for LTE, it
would be advantageous to consider user contribution to congestion for
both the radio access and the core network. Potential places for
CONEX functions are e.g. the eNBs, the S-GWs or the P-GWs. Operator
deployments may provide additional intermediary CONEX-enabled IP
network elements.
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: Proxy-Mobile-IP (PMIP,
[3GPP.23.402]) and 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 re-act to
persistent congestion contribution etc. In the EPS, per-user
information is normally part of the user profile (stored in HSS) that
would be accessed by PCC entities such as the PCRF for dynamic
updates, enforcement etc.
The Conex mechanism allows operators to either have congestion based
policing in the uplink/downlink or in both directions. With the
given flexibility, the functional entities can further be divided
into uplink and downlink directions e.g. uplink/downlink policer etc.
Policers may be placed at different network locations (also see
[nec.globecom2010]). E.g., placing an uplink Policer at the base
station can be beneficial, because if there is congestion in the
backhaul, traffic would be policed before reaching the congested
segments. On the other hand, considering user mobility, operating
uplink policers on base stations may not be the optimal approach.
Downlink Policers would also be positioned best at border gateways
where they can process ingress traffic. Depending on the specific
architecture, up- and downlink policers could also be collocated.
A more detailed description of the different approaches and their
respective advantages will be provided in a future revision of this
document.
Kutscher, et al. Expires September 8, 2011 [Page 12]
Internet-Draft CONEX Mobile Scenario March 2011
5. Implications for CONEX
Our description of possible CONEX use cases and deployment options in
the previous sections has yielded a set of implications/requirements
for the CONEX mechanism that we summarize in this section.
Performance: CONEX's capability of ensuring fairness could be used
for ensuring fairness in cellular networks. However, although the
idea looks promising, its advantages and performance have been not
yet been verified thoroughly yet. In the context of cellular
networks, which has more expensive resources and more stringent
QoS requirements, the feasibility of applying Conex to cellular
network as well as its performance and deployment scenarios need
to be examined. For instance, the mobile network may encounter
longer delay and higher loss rate but most of the flows are short-
lived. In the network with fast changing conditions, it requires
Conex to expose latest congestion information in time. In
addition, it is significant if it has the capability to indicate
out-of-date congestion information to avoid misusage of such
information.
Mobility: One of the unique characteristics in cellular network is
the presence of user mobility compared to wired networks. As the
user location changes, the same device can be connected to the
network via different base stations (eNodeBs) or even go through
switching gateways. Thus, the CONEX scheme must to be able to
carry latest congestion information per user/flow across multiple
network nodes in real time.
Multi-access: In cellular network, multiple access technologies can
co-exist. In such cases, a user can use multiple access
technologies for multiple applications or even a single
application simutaneously. 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 PMIP and
GTP.
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.
Kutscher, et al. Expires September 8, 2011 [Page 13]
Internet-Draft CONEX Mobile Scenario March 2011
6. IANA Considerations
No IANA considerations.
7. Security Considerations
Security considerations will be provided in a future version of this
document.
8. References
8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
8.2. Informative References
[3GPP.23.203]
3GPP, "Policy and charging control architecture", 3GPP
TS 23.203 10.2.1, January 2011.
[3GPP.23.402]
3GPP, "Architecture enhancements for non-3GPP accesses",
3GPP TS 23.402 10.2.1, January 2011.
[3GPP.23.829]
3GPP, "Local IP Access & Selected IP Traffic Offload
(LIPA-SIPTO)", 3GPP TR 23.829 1.3.0, September 2010.
[3GPP.29.060]
3GPP, "General Packet Radio Service (GPRS); GPRS
Tunnelling Protocol (GTP) across the Gn and Gp interface",
3GPP TS 29.060 3.19.0, March 2004.
[3GPP.29.274]
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 10.1.0,
December 2010.
[3GPP.36.300]
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
10.2.0, December 2010.
Kutscher, et al. Expires September 8, 2011 [Page 14]
Internet-Draft CONEX Mobile Scenario March 2011
[I-D.ietf-conex-concepts-uses]
Briscoe, B., Woundy, R., Moncaster, T., and J. Leslie,
"ConEx Concepts and Use Cases",
draft-ietf-conex-concepts-uses-00 (work in progress),
November 2010.
[nec.globecom2010]
Kutscher, Lundqvist, and Mir, "Congestion Exposure in
Mobile Wireless Communications", in proceedings of IEEE
GLOBECOM 2010, December 2010.
Appendix A. Acknowledgments
We would like to thank Ingemar Johansson for his support in shaping
the overall idea and in improving the draft.
Authors' Addresses
Dirk Kutscher
NEC
Kurfuersten-Anlage 36
Heidelberg,
Germany
Phone:
Email: kutscher@neclab.eu
Faisal Ghias Mir
NEC
Kurfuersten-Anlage 36
Heidelberg,
Germany
Phone:
Email: faisal.mir@neclab.eu
Kutscher, et al. Expires September 8, 2011 [Page 15]
Internet-Draft CONEX Mobile Scenario March 2011
Rolf Winter
NEC
Kurfuersten-Anlage 36
Heidelberg,
Germany
Phone:
Email: winter@neclab.eu
Suresh Krishnan
Ericsson
8400 Blvd Decarie
Town of Mount Royal, Quebec
Canada
Phone:
Email: suresh.krishnan@ericsson.com
Ying Zhang
Ericsson
200 Holger Way
San Jose, CA 95134
USA
Phone:
Email: ying.zhang@ericsson.com
Kutscher, et al. Expires September 8, 2011 [Page 16]