111 X TITLE A Proposal For QoS and Charging Policy Control SOURCE Parviz Yegani Tel: Fax: ABSTRACT This contribution proposes a Policy Control mechanism RECOMMENDATION Discussion, Feedback and Decision

222 X Cisco Systems, Inc. grants a free, irrevocable license to 3GPP2 and its Organizational Partners to incorporate text or other copyrightable material contained in the contribution and any modifications thereof in the creation of 3GPP2 publications; to copyright and sell in Organizational Partner's name any Organizational Partner's standards publication even though it may include all or portions of this contribution; and at the Organizational Partner's sole discretion to permit others to reproduce in whole or in part such contribution or the resulting Organizational Partner's standards publication. Cisco Systems, Inc. is also willing to grant licenses under such contributor copyrights to third parties on reasonable, non-discriminatory terms and conditions for purpose of practicing an Organizational Partner’s standard which incorporates this contribution. This document has been prepared by Cisco Systems, Inc. to assist the development of specifications by 3GPP2. It is proposed to the Committee as a basis for discussion and is not to be construed as a binding proposal on Cisco Systems, Inc. Cisco Systems, Inc. specifically reserves the right to amend or modify the material contained herein and to any intellectual property of Cisco Systems, Inc. other than provided in the copyright statement above.

333 X A Proposal for QoS and Charging Policy Control  QoS Policy  Charging Policy  Three Levels of Policy Control  Local Policy Control  Static Policy Control  Dynamic Policy Control  Combined Static and Dynamic Policy Control  Conclusion

444 X QoS Policy QoS Policy Definition  Identify an IP Flow or a set of IP Flows comprising a service IP flow can be identified by the five-tuple of Source IP Address, Destination IP Address, Source Port, Destination Port and the Protocol. Also, any other combinations of information in the IP Header, UDP/TCP Header and application protocol header (HTTP, SMTP, RTP) can be used to identify a flow.  Define a QoS for the flow(s) QoS consists of the following four parameters specified in various forms: Bandwidth, Reliability, Delay, Jitter

555 X QoS Policy QoS Policy Control (In Real Time)  Authorize the QoS Resources for identified flows  Unauthorize the QoS Resources, if required  Enable and Disable the flow (Gate) Based upon, for example: events in the application

666 X Charging Policy Charging Policy Definition  Identify an IP Flow or a set of IP Flows comprising a service for Charging purposes This identification is similar to the identification of flows for QoS. It need not be the same. QoS and Charging policies may be different.  Define a Set of Charging Rules For the identified flows a set of charging rules are defined. Charging Policy Control (In Real Time)  In Real Time collect and report the charging information.

777 X Three Levels of Policy Control Local Policy Local Policy is defined and administered at the entity which enforces it. For example, both QoS and Charging Local Policy may be defined at PDSN. Generally, these policies will have broad system wide applications. Static Policy Static Policy is defined on a per subscriber basis and stored on a Static Policy Server. Static Policy can be defined for both QoS as well Charging. It is downloaded into PDSN where it is enforced. Dynamic Policy Dynamic Policy is defined on a per application per session basis. It is determined by a combination of information stored at Policy Decision Function (PDF), the information provided by the subscriber during a session initiation and the application itself. It is provided by PDF to PDSN (PEF) during a session and enforced by PDSN.

888 X Application Local Policy Control PEFCPEF Local QoS Policy Local Charging Policy PDSN PEF is the standard IETF term for Policy Enforcement Function. CPEF is a new term to denote Charging Policy Enforcement Function. Both QoS and Charging Policies are locally stored at PDSN and enforced. A simple policy control like this can in fact be adequate in many instances. For example: A set of QoS parameters can be administered for each of the RTP, HTTP, SMTP and FTP flows. A set of charging rules can be administered for the same types of flows. This scheme can not be (easily) used to differentiate one subscriber from the other.

999 X Application Static Policy Control PEFCPEF Local QoS Policy Local Charging Policy PDSN Static QoS Policy Server Static Charging Policy Server Static (QoS and Charging) Policies are defined and stored on QoS and Charging Policy Servers. The policy database is on a per subscriber basis. For example: Give high priority QoS to a subscriber’s RTP traffic while best effort to the subscriber’s FTP traffic. Alternately, another subscriber may receive best effort QoS for all traffic. Please note that the terms High Priority and Best Effort are loosely used here. The policy is downloaded in the PDSN via RADIUS protocol. RADIUS is widely used and proven and it is a good starting point. Later, when the DIAMETER becomes widely available, the protocol may be changes without affecting the functionality. The Local Policies may/may not co-exist with the Static Policy. RADIUS

10 X Application Dynamic Policy Control PEFCPEF Local QoS Policy Local Charging Policy PDSN Charging Policy Decision Function Dynamic Policy is determined at the session initiation time by the application on a per subscriber per session basis. It is dynamic because it can base the QoS and Charging rules on the source IP address, destination IP address, Source Port, Destination Port, the application level protocol, media components requested by the subscriber and a host of other information. It is decided by PDF and CPDF and downloaded into the PDSN on a per session basis. It is enforced by PEF and CPEF. The Local Policies may/may not co-exist with the Dynamic Policy. RADIUS CPDFPDF QoS Policy Decision Function RADIUS

11 X Application Combined Static and Dynamic Policy Control PEFCPEF Local QoS Policy Local Charging Policy PDSN Charging Policy Decision Function CPDFPDF QoS Policy Decision Function RADIUS Static QoS Policy Server Static Charging Policy Server RADIUS

12 X Combined Static and Dynamic Policy Control (Cont…) Some applications may need only static policy. Some may need only Dynamic Policy. Some may need a combination of both. For example: suppose the Application provider is different than the Access provider. The Dynamic Policy is based upon the Application provider's rules. The Static Policy is on a subscriber basis and hence it is based upon the Access provider (the Home operator) rules. A combination of these two may take into account the rules of both.

13 X Conclusion A three level policy control approach has been proposed. The Local Policy is the default/fall back policy. The operator can start with a simple Static Policy. It uses the widely available RADIUS Servers and Protocol to define, administer and download a set of QoS and Charging Policies into the PDSN where they are enforced. As new applications evolve and new QoS and Charging Policies become necessary, then the Dynamic Policy mechanism can be introduced. The PDSN will be the final arbiter to decide whether to enforce the Static or the Dynamic or a Combined Policy.