[Docs] [txt|pdf|xml|html] [Tracker] [Email] [Nits]

Versions: 00

PCP                                                             R. Penno
Internet-Draft                                                  T. Reddy
Intended status: Standards Track                                 D. Wing
Expires: January 30, 2014                                    B. VerSteeg
                                                                   Cisco
                                                            M. Boucadair
                                                          France Telecom
                                                           July 29, 2013


       PCP Usage for Quality of Service (QoS) in Mobile Networks
                     draft-penno-pcp-mobile-qos-00

Abstract

   There are challenges to request quality of service for an application
   or network flow that is not part of a mobile network's Evolved Packet
   Core (EPC).  This document addresses this issue by defining a
   mechanism to signal the desired characteristics of a flow to the
   Mobile Network from a User Equipment (UE) using Port Control Protocol
   (PCP).  The signaled characteristics allow the Mobile Network to
   enforce appropriate policies such as prioritize that flow accordingly
   and trigger dedicated bearer activation or bearer modification
   procedure.

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 January 30, 2014.

Copyright Notice

   Copyright (c) 2013 IETF Trust and the persons identified as the
   document authors.  All rights reserved.





Penno, et al.           Expires January 30, 2014                [Page 1]


Internet-Draft        PCP in Mobile Network for QOS            July 2013


   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.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Notational Conventions  . . . . . . . . . . . . . . . . . . .   4
   3.  QoS in Cellular Networks  . . . . . . . . . . . . . . . . . .   4
   4.  Solution Overview . . . . . . . . . . . . . . . . . . . . . .   5
     4.1.  Network-triggered QoS . . . . . . . . . . . . . . . . . .   7
     4.2.  PCP to 3GPP . . . . . . . . . . . . . . . . . . . . . . .   8
   5.  Security Considerations . . . . . . . . . . . . . . . . . . .  10
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  10
   7.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  10
   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  10
     8.1.  Normative References  . . . . . . . . . . . . . . . . . .  10
     8.2.  Informative References  . . . . . . . . . . . . . . . . .  11
   Appendix A. . . . . . . . . . . . . . . . . . . . . . . . . . . .  12
     A.1.  Other techniques  . . . . . . . . . . . . . . . . . . . .  12
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  12

1.  Introduction

   The use of Mobile Network for accessing the Internet and other data
   services via smartphones, tablets, and notebook/netbook computers has
   increased rapidly as a result of high-speed packet data networks such
   as HSPA and HSPA+; and now Long-Term Evolution (LTE) is being
   deployed.  Mobile devices are becoming similar in capability to their
   desktop counterparts.  From that perspective, it is feasible to run
   WebRTC, HTTP Adaptive Streaming (HAS), P2P applications on mobile
   devices.  Mobile network needs to have a mechanism to prioritize such
   packet flows in both directions.

   The Web Real-Time communication (WebRTC) framework
   [I-D.ietf-rtcweb-overview] provides the protocol building blocks to
   support direct, interactive, real-time communication using audio,
   video, collaboration, games, etc., between peer web-browsers.  WebRTC
   application use Interactive Connectivity Establishment (ICE) protocol
   [RFC5245] for gathering candidates, prioritizing them, choosing
   default ones, exchanging them with the remote party, pairing them and
   ordering them into check lists.  Once all of the above steps have



Penno, et al.           Expires January 30, 2014                [Page 2]


Internet-Draft        PCP in Mobile Network for QOS            July 2013


   been completed the participating ICE agents can begin a phase of
   connectivity checks and eventually select a pair of candidates that
   will be used for real-time communication.  The P2P streams (audio,
   video, data-channel) are dynamic, time-bound, encrypted and have
   different priorities.  When WebRTC server is deployed in a 3rd party
   network trusted by the Mobile Network and the media session need to
   be prioritized, a mechanism is required to signal the flow
   characteristics (i.e., traffic performance requirements) of the media
   streams to the Mobile Network.  However, the Mobile Network may not
   trust the host (UE) to signal the correct flow characteristics
   permitted by the WebRTC server.

   PCP [RFC6887] provides a mechanism to describe a given flow to the
   network prior to actual session establishment.  The primary driver
   for PCP has been creating port mappings on NAT and firewall devices.
   When doing this, PCP pushes flow information from the host into the
   network (specifically to the network's NAT or firewall device), and
   receives information back from the network (from the NAT or firewall
   device).  This document uses PCP FLOWDATA option defined in
   [I-D.wing-pcp-flowdata] to convey the flow characteristics from the
   host to the Mobile Network, and allow the Mobile Network to
   prioritize that flow accordingly and trigger dedicated bearer
   activation or bearer modification procedure.  This document also
   explains how the PCP Server in the Evolved Packet Core (EPC) maps the
   fields in PCP FLOWDATA option to 3GPP QCI, GBR values.

   The mechanism described in this document has several useful
   properties :

   a.  Differentiated QoS services can be offered to third party
       applications.  For third party applications differentiated QoS
       services can be installed even if the UE is behind NAT provided
       by the Mobile Network.  In contrast, other mechanisms struggle to
       install differentiated QOS if the UE is behind NAT.

   b.  Mobile Network can authorize the differentiated service request
       from third party application because the proposed mechanism is
       compliant with the 3GPP's network-triggered QoS policy
       enforcement model.

   c.  This mechanism does not rely on DPI.

   d.  A UE can use single protocol no matter of the access technology;
       Abstracts layer 2 specifics, so host and applications can avoid
       layer 2-specific signaling even if their Internet connection is
       via 3G/4G or DOCSIS.





Penno, et al.           Expires January 30, 2014                [Page 3]


Internet-Draft        PCP in Mobile Network for QOS            July 2013


   e.  Usable at the application level, without needing operating system
       support

   f.  Robust metadata support, to convey sufficient information to the
       network about the flow;

   g.  Provides differentiated service for both directions of a flow,
       including flows that cross administrative boundaries (such as the
       Internet).

   h.  Both high-priority and low-priority flows can be signalled, so
       that in overload situations operators can make low-priority flows
       yield to other flows through policing.

   Note :

   1.  It is out of scope of this document to discuss the trade-offs
       between the proposed approach vs. deploying local WebRTC-IMS
       Gateways within the Mobile Network.

   2.  The mechanism described in this document provides QoS and network
       feedback for a variety of applications including interactive
       audio/video application such as WebRTC, streaming video, and
       network backup.  The value is provided for the applications that
       are orchestrated through EPC and for applications that are
       delivered over the top.

   3.  Administrative-related considerations between the administrative
       entity managing the third party application server and the Mobile
       Network are out of scope of this document.

2.  Notational Conventions

   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 [RFC2119].

   This note uses terminology defined in [RFC5245], [RFC6459].

   WebRTC Server : Web Server that supports WebRTC.

   High-Speed Packet Access : The High-Speed Packet Access (HSPA) and
   HSPA+ are enhanced versions of the Wideband Code Division Multiple
   Access (WCDMA) and UTRAN, thus providing more data throughput and
   lower latencies.

3.  QoS in Cellular Networks




Penno, et al.           Expires January 30, 2014                [Page 4]


Internet-Draft        PCP in Mobile Network for QOS            July 2013


   3GPP has standardized QoS for EPC (Enhanced Packet Core) from Release
   8 [TS23.107]. 3GPP QoS policy configuration defines access agnostic
   QoS parameters that can be used to provide service differentiation in
   multi vendor and operator deployments.  The concept of a bearer is
   used as the basic construct for which QoS treatment is applied for
   uplink and downlink packet flows between the Mobile Node (MN) and
   gateway [TS23.401].  A bearer may have more than one packet filter
   associated and this is called a Traffic Flow Template (TFT).  IP
   source address, source port, IP destination, destination port, L4
   protocol, Type of service/Traffic class type, Security parameter
   index etc identify a packet filter.  Each UE can have one or multiple
   bearers associated with its registration, each supporting different
   QoS characteristics.  An UpLink Traffic Flow Template (UL TFT) is the
   set of uplink packet filters in a TFT.  A DownLink Traffic Flow
   Template (DL TFT) is the set of downlink packet filters in a TFT.

   The access agnostic QoS parameters associated with each bearer are
   QCI (QoS Class Identifier), ARP (Allocation and Retention Priority),
   MBR (Maximum Bit Rate) and optionally GBR (Guaranteed Bit Rate)
   explained in [TS23.203].  QCI is a scalar that defines packet
   forwarding criteria in the network.  Mapping of QCI values to DSCP is
   well understood and GSMA has defined standard means of mapping
   between these scalars [GSMA-IR34].  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 bearer, e.g., best effort
   traffic for web access etc.  Packets mapped to the same EPS bearer
   receive the same bearer level packet forwarding treatment.  For
   example QCI value 1 is typically used for Conversational Voice and
   the standardized flow characteristics for QCI value 1 are Packet
   delay of 100 ms and Packet error loss Rate of 10 to the power -2.

   3G and LTE networks also provide extensive support for accounting and
   charging already, for example using the Policy Charging Control (PCC)
   architecture.  In the EPS, per-user information is normally part of
   the user profile (stored in the Home Subscriber Server) that would be
   accessed by PCC entities such as the PCRF for dynamic updates,
   enforcement etc.

4.  Solution Overview

   In the below topology, The main involved functional elements are:

   o  UE (User Equipment) is a mobile node.

   o  The evolved NodeB (eNB) is a base station entity that supports the
      Long-Term Evolution (LTE) air interface.  It is part of the access
      network that provides radio resource management, header
      compression, security and connectivity to the core network through



Penno, et al.           Expires January 30, 2014                [Page 5]


Internet-Draft        PCP in Mobile Network for QOS            July 2013


      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.

   o  The Serving gateway, SGW, 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.

   o  Policy and Charging Rule Function (PCRF) which is responsible for
      determining which policy and charging control rules are to be
      applied [TS23.203].

   o  Policy and Charging Enforcement Function (PCEF) which performs
      policy enforcement (e.g., Quality of Service (QoS)) and flow-based
      charging [TS23.203].  PCEF is co-located with PDN-GW.  PDN-GW is
      also responsible for IP address allocation to the UE, packet
      filtering, and policy-based control of flows.

   o  Application Function (AF) is an element offering applications that
      require dynamic policy and/or charging control [TS23.203].

   o  The Home Subscriber Server, HSS, is a database that contains user
      subscriptions and QoS profiles.  The Mobility Management Entity,
      MME, is responsible for user authentication, bearer establishment
      and modification and maintenance of the UE context.

                           +--------+
                           |  HSS   |
                           +--------+
                                |                      +-------+
                                |                      | PCRF  |
                                |                      +-------+
                             +-------+                     |
                           / | MME   |\                    |
                          /  +-------+ \                   |
                         /              \                  |
                        /                \                 |
       +----+        +-------+            +-------+      +-------+
       |UE  |        |  eNB  |            | SGW   |      |PDN-GW |
       |    |========|       |============|       |======|       |
       +----+        +-------+            +-------+      +-------+
        ^  .                                                  ^
        |  .                     PCP  request/response        .
        |  ....................................................
        |
        |  WebRTC Signalling



Penno, et al.           Expires January 30, 2014                [Page 6]


Internet-Draft        PCP in Mobile Network for QOS            July 2013


        +-------------------------------------------------------+
   Mobile Network                                               |
                                                                |
   ==================================================================
   3rd Party Network                                            |
                                                                |
                                                                V
                                           =========================
                                           |  WebRTC Server        |
                                           =========================


                         PCP interdomain - WebRTC

4.1.  Network-triggered QoS

   This section describes the existing steps applicable to any other
   network that requires authorization from third party application to
   permit differentiated QOS service request from UE which has been
   discussed in [I-D.wing-pcp-third-party-authz].

   1.  PCP client determines the PCP server to use by using the
       mechanisms explained in section 8.1 of [RFC6887].  In case of the
       GTP-based S5/S8 interface, the PDN-GW is the first-hop router for
       the UE, and in the case of PMIPv6-based S5/S8, the SGW is the
       first-hop router.  PCP server could be co-located with the PDN-
       GW.  For instance PCP client can also learn the PCP server
       address using DHCP [I-D.ietf-pcp-dhcp] and behavior to be
       followed by the PCP client to contact its PCP server(s) is
       explained in [I-D.ietf-pcp-server-selection].  The other benefits
       of using PCP are explained in [I-D.penno-rtcweb-pcp].

   2.  Once ICE [RFC5245] processing has completed, an updated offer/
       answer exchange takes place.  WebRTC server is aware of the
       active media path after the controlling ICE endpoint follows the
       procedures in Section 11.1 of [RFC5245], specifically to send
       updated offer if the candidates in the m and c lines for the
       media stream (called the DEFAULT CANDIDATES) do not match ICE's
       SELECTED CANDIDATES (also see Appendix B.9 of [RFC5245]).

   3.  To provide differentiated QOS, the WebRTC server generates
       cryptographic token and metadata for prioritizing the media
       streams which is passed to the WebRTC endpoint.  In this scenario
       PCP client on the UE is the third-party application obtaining
       limited access to an PCP server (resource server) on behalf of
       the WebRTC server (resource owner).  The PCP TOKEN_ACCESS option
       defined in [I-D.wing-pcp-third-party-authz] must be included in
       the PCP request sent to the PCP server.  This TOKEN_ACCESS option



Penno, et al.           Expires January 30, 2014                [Page 7]


Internet-Draft        PCP in Mobile Network for QOS            July 2013


       is created by the PCP client using the access token, key id etc
       received from the authorization server using OAuth 2.0 [RFC6749].
       The PCP client populates the fields in FLOWDATA option using the
       metadata provided by the authorization server.  The PCP client
       sends the PCP request with MAP or PEER opcodes with the above PCP
       options to the PCP server.  This mechanism is required so that
       the PCP server in the Evolved Packet (EPC) can validate that the
       PCP request for specific flow characteristics is initiated by the
       UE because of using a trusted 3rd party WebRTC Server.

   4.  The PCP server identifies the authorization server using the
       Domain Name in the PCP ACCESS_TOKEN option.  The PCP server
       validates the fields in TOKEN_ACCESS option using the mechanism
       explained in section 5.2 of [I-D.wing-pcp-third-party-authz].  If
       the token is successfully validated then the authorization server
       returns the token bound authorization data in response.  The
       token bound authorization data would be flow characteristics like
       upstream and downstream minimum bandwidth, delay, loss etc.  The
       PCP server then matches this token bound authorization data with
       what is requested in the PCP FLOWDATA option.  If the
       authorization sets match, the PCP server honors the PCP request
       made by the PCP client.

4.2.  PCP to 3GPP

   This section describes steps involved with processing PCP FLOWDATA
   option to initiate bearer activation for each media stream.

   1.  The PCP FLOWDATA option has all the required fields to trigger
       dedicated bearer activation or modification with relevant QCI,
       GBR values.  UpLink Traffic Flow Template (UL TFT) and DownLink
       Traffic Flow Template (DL TFT) would be installed in both
       directions for the media stream.  For example IP source address,
       source port, IP destination address, destination port, L4
       protocol will be used from the PCP request (PEER opcode) to
       create packet filter which is associated with UL TFT.  The
       advantage of this technique is no changes are required to TFT
       definition.  PCP success response would be sent without waiting
       for network-initiated bearer activation or modification to be
       complete: i.e., PCP success response would be sent based on the
       resource availability to setup or modify bearers.

   2.  Using the fields in PCP FLOWDATA option listed in the below
       table, relevant QCI value will be determined to initiate bearer
       activation or modification procedure.  Upstream and Downstream
       Bandwidth Minimum values will be set to zero in PCP FLOWDATA
       option to indicate QCI values in the range 5-8.  Non-zero
       Bandwidth Minimum value in FLOWDATA option will be mapped to GBR



Penno, et al.           Expires January 30, 2014                [Page 8]


Internet-Draft        PCP in Mobile Network for QOS            July 2013


       to determine if the requested bitrate can be provided or not.
       GBR is provided only for QCI values 1 to 4.

            (Fields in PCP FLOWDATA option - uDT, uLT, dDT, dLT)

   +---------------------------------------------------------------+
   | QCI  |  Delay    |  Loss    |   Example Services              |
   |---------------------------------------------------------------|
   | 1    |  Low      |  Medium  |  Conversational Voice           |
   +---------------------------------------------------------------+
   | 2    |  Medium   |  Low     |  Conversational Video           |
   +---------------------------------------------------------------+
   | 3    |  Very Low |  Low     |  Real Time Gaming               |
   +---------------------------------------------------------------+
   | 4    |  Medium   | Very Low |  Non-conversational Video,      |
   |      |           |          |  buffered streaming             |
   +---------------------------------------------------------------+
   | 5    |  Low      | Very Low |  IMS Signalling                 |
   +---------------------------------------------------------------+
   | 6    |  Medium   | Very Low |  Video (Buffered Streaming)     |
   +---------------------------------------------------------------+
   | 7    |  Low      |  Low     |  Voice, Video (Live streaming)  |
   +---------------------------------------------------------------+
   | 8    |  Medium   |  Low     |  web access                     |
   +---------------------------------------------------------------+
   | 9    |  High     |  Low     |  e-mail                         |
   +---------------------------------------------------------------+


                        PCP FLOWDATA to QCI Mapping

   3.  The PDN-GW will communicate with the PCRF to trigger the
       appropriate Policy charging and control (PCC) decision based on
       which PDN-GW will initiate bearer activation or modification
       procedure.

   4.  If PCP authentication [I-D.ietf-pcp-authentication] is used then
       the PCP server can also provide identity of the UE to PCRF.

   5.  After the call is terminated PCP client informs the PCP server to
       close the mapping.  The Authorization Server also informs the PCP
       server to revoke the access token after the call is terminated
       which is discussed in section 5.2 of
       [I-D.wing-pcp-third-party-authz].  This step triggers bearer
       deactivation procedure discussed in section 5.4.4.1 of
       [TS23.401].





Penno, et al.           Expires January 30, 2014                [Page 9]


Internet-Draft        PCP in Mobile Network for QOS            July 2013


5.  Security Considerations

   Security considerations discussed in [RFC6887] and PCP authentication
   [I-D.ietf-pcp-authentication] are to be taken into account.

6.  IANA Considerations

   None.

7.  Acknowledgements

   Authors would like to thank Harold Lassers, Basavraj Patil, Thomas
   Anderson for their comments and review.

8.  References

8.1.  Normative References

   [I-D.ietf-rtcweb-overview]
              Alvestrand, H., "Overview: Real Time Protocols for Brower-
              based Applications", draft-ietf-rtcweb-overview-06 (work
              in progress), February 2013.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC5245]  Rosenberg, J., "Interactive Connectivity Establishment
              (ICE): A Protocol for Network Address Translator (NAT)
              Traversal for Offer/Answer Protocols", RFC 5245, April
              2010.

   [RFC5389]  Rosenberg, J., Mahy, R., Matthews, P., and D. Wing,
              "Session Traversal Utilities for NAT (STUN)", RFC 5389,
              October 2008.

   [RFC6407]  Weis, B., Rowles, S., and T. Hardjono, "The Group Domain
              of Interpretation", RFC 6407, October 2011.

   [RFC6459]  Korhonen, J., Soininen, J., Patil, B., Savolainen, T.,
              Bajko, G., and K. Iisakkila, "IPv6 in 3rd Generation
              Partnership Project (3GPP) Evolved Packet System (EPS)",
              RFC 6459, January 2012.

   [RFC6749]  Hardt, D., "The OAuth 2.0 Authorization Framework", RFC
              6749, October 2012.






Penno, et al.           Expires January 30, 2014               [Page 10]


Internet-Draft        PCP in Mobile Network for QOS            July 2013


   [RFC6887]  Wing, D., Cheshire, S., Boucadair, M., Penno, R., and P.
              Selkirk, "Port Control Protocol (PCP)", RFC 6887, April
              2013.

8.2.  Informative References

   [GSMA-IR34]
              , "Inter-Service Provider Backbone Guidelines 5.0, 22
              December 2010", September 2012.

   [I-D.ietf-pcp-authentication]
              Wasserman, M., Hartman, S., and D. Zhang, "Port Control
              Protocol (PCP) Authentication Mechanism", draft-ietf-pcp-
              authentication-01 (work in progress), October 2012.

   [I-D.ietf-pcp-dhcp]
              Boucadair, M., Penno, R., and D. Wing, "DHCP Options for
              the Port Control Protocol (PCP)", draft-ietf-pcp-dhcp-07
              (work in progress), March 2013.

   [I-D.ietf-pcp-server-selection]
              Boucadair, M., Penno, R., Wing, D., Patil, P., and T.
              Reddy, "PCP Server Selection", draft-ietf-pcp-server-
              selection-01 (work in progress), May 2013.

   [I-D.ietf-rtcweb-security-arch]
              Rescorla, E., "WebRTC Security Architecture", draft-ietf-
              rtcweb-security-arch-07 (work in progress), July 2013.

   [I-D.penno-rtcweb-pcp]
              Penno, R., Reddy, T., Wing, D., and M. Boucadair, "PCP
              Considerations for WebRTC Usage", draft-penno-rtcweb-
              pcp-00 (work in progress), May 2013.

   [I-D.reddy-rtcweb-mobile]
              Reddy, T., Kaippallimalil, J., R, R., and R. Ejzak,
              "Considerations with WebRTC in Mobile Networks", draft-
              reddy-rtcweb-mobile-03 (work in progress), May 2013.

   [I-D.wing-pcp-flowdata]
              Wing, D., Penno, R., and T. Reddy, "PCP Flowdata Option",
              draft-wing-pcp-flowdata-00 (work in progress), July 2013.

   [I-D.wing-pcp-third-party-authz]
              Wing, D., Reddy, T., Patil, P., and R. Penno, "PCP
              Extension for Third Party Authorization", draft-wing-pcp-
              third-party-authz-00 (work in progress), May 2013.




Penno, et al.           Expires January 30, 2014               [Page 11]


Internet-Draft        PCP in Mobile Network for QOS            July 2013


   [RFC6342]  Koodli, R., "Mobile Networks Considerations for IPv6
              Deployment", RFC 6342, August 2011.

   [TS23.107]
              3GPP, ., "End-to-End Quality of Service (QoS) Concept and
              Architecture, Release 10, 3GPP TS 23.207, V10.0.0 (2011-
              03)", September 2012.

   [TS23.203]
              3GPP, ., "3GPP, "Policy and charging control
              architecture", 3GPP TS 23.203 10.5.0, December 2011.",
              September 2012.

   [TS23.401]
              3GPP, ., "General Packet Radio Service (GPRS) enhancements
              for Evolved Universal Terrestrial Radio Access Network (E-
              UTRAN) access (Release 11), 3GPP TS 23.401, V11.2.0 (2012-
              06).", September 2012.

Appendix A.

A.1.  Other techniques

   o  UE can also request bearer resource modification for an E-UTRAN as
      explained in Section 5.4.5 of [TS23.401].  The procedure allows
      the UE to request modification of bearer resources (e.g.,
      allocation or release of resources) for one traffic flow aggregate
      with a specific QoS demand.  Alternatively, the procedure allows
      the UE to request modification of the packet filters used for an
      active traffic flow aggregate, without changing QoS.  If accepted
      by the network, the request invokes either the Dedicated Bearer
      Activation Procedure or the Bearer Modification Procedure.
      However this technique is not widely deployed and only network-
      controlled quality of service is widely used.

   o  After certain QoS parameters are established, the UE or the
      network may want to change those QoS parameters.  This is
      supported in both 3GPP [TS23.401] and PCP FLOWDATA.

   o  Bearers modification, creation procedures when Application Server
      like WebRTC is deployed in 3GPP network is explained in section
      4.3 of [I-D.reddy-rtcweb-mobile].

   o  TODO : OneAPI.

Authors' Addresses





Penno, et al.           Expires January 30, 2014               [Page 12]


Internet-Draft        PCP in Mobile Network for QOS            July 2013


   Reinaldo Penno
   Cisco Systems, Inc.
   170 West Tasman Drive
   San Jose  95134
   USA

   Email: repenno@cisco.com


   Tirumaleswar Reddy
   Cisco Systems, Inc.
   Cessna Business Park, Varthur Hobli
   Sarjapur Marathalli Outer Ring Road
   Bangalore, Karnataka  560103
   India

   Email: tireddy@cisco.com


   Dan Wing
   Cisco Systems, Inc.
   170 West Tasman Drive
   San Jose, California  95134
   USA

   Email: dwing@cisco.com


   Bill VerSteeg
   Cisco Systems, Inc.
   5030 Sugarloaf Parkway
   Lawrenceville  30044
   USA

   Email: billvs@cisco.com


   Mohamed Boucadair
   France Telecom
   Rennes  35000
   France

   Email: mohamed.boucadair@orange.com








Penno, et al.           Expires January 30, 2014               [Page 13]


Html markup produced by rfcmarkup 1.129c, available from https://tools.ietf.org/tools/rfcmarkup/