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]