1、 TIA-1124 February 2011All-IP System MMD Policy Enhancements System Requirements NOTICE TIA Engineering Standards and Publications are designed to serve the public interest through eliminating misunderstandings between manufacturers and purchasers, facilitating interchangeability and improvement of
2、products, and assisting the purchaser in selecting and obtaining with minimum delay the proper product for their particular need. The existence of such Standards and Publications shall not in any respect preclude any member or non-member of TIA from manufacturing or selling products not conforming t
3、o such Standards and Publications. Neither shall the existence of such Standards and Publications preclude their voluntary use by Non-TIA members, either domestically or internationally. Standards and Publications are adopted by TIA in accordance with the American National Standards Institute (ANSI)
4、 patent policy. By such action, TIA does not assume any liability to any patent owner, nor does it assume any obligation whatever to parties adopting the Standard or Publication. This Standard does not purport to address all safety problems associated with its use or all applicable regulatory requir
5、ements. It is the responsibility of the user of this Standard to establish appropriate safety and health practices and to determine the applicability of regulatory limitations before its use. (From Project No. PN-3-0275, formulated under the cognizance of the TIA TR-45 Mobile (b) there is no assuran
6、ce that the Document will be approved by any Committee of TIA or any other body in its present or any other form; (c) the Document may be amended, modified or changed in the standards development or any editing process. The use or practice of contents of this Document may involve the use of intellec
7、tual property rights (“IPR”), including pending or issued patents, or copyrights, owned by one or more parties. TIA makes no search or investigation for IPR. When IPR consisting of patents and published pending patent applications are claimed and called to TIAs attention, a statement from the holder
8、 thereof is requested, all in accordance with the Manual. TIA takes no position with reference to, and disclaims any obligation to investigate or inquire into, the scope or validity of any claims of IPR. TIA will neither be a party to discussions of any licensing terms or conditions, which are inste
9、ad left to the parties involved, nor will TIA opine or judge whether proposed licensing terms or conditions are reasonable or non-discriminatory. TIA does not warrant or represent that procedures or practices suggested or provided in the Manual have been complied with as respects the Document or its
10、 contents. If the Document contains one or more Normative References to a document published by another organization (“other SSO”) engaged in the formulation, development or publication of standards (whether designated as a standard, specification, recommendation or otherwise), whether such referenc
11、e consists of mandatory, alternate or optional elements (as defined in the TIA Engineering Manual, 4thedition) then (i) TIA disclaims any duty or obligation to search or investigate the records of any other SSO for IPR or letters of assurance relating to any such Normative Reference; (ii) TIAs polic
12、y of encouragement of voluntary disclosure (see Engineering Manual Section 6.5.1) of Essential Patent(s) and published pending patent applications shall apply; and (iii) Information as to claims of IPR in the records or publications of the other SSO shall not constitute identification to TIA of a cl
13、aim of Essential Patent(s) or published pending patent applications. TIA does not enforce or monitor compliance with the contents of the Document. TIA does not certify, inspect, test or otherwise investigate products, designs or services or any claims of compliance with the contents of the Document.
14、 ALL WARRANTIES, EXPRESS OR IMPLIED, ARE DISCLAIMED, INCLUDING WITHOUT LIMITATION, ANY AND ALL WARRANTIES CONCERNING THE ACCURACY OF THE CONTENTS, ITS FITNESS OR APPROPRIATENESS FOR A PARTICULAR PURPOSE OR USE, ITS MERCHANTABILITY AND ITS NONINFRINGEMENT OF ANY THIRD PARTYS INTELLECTUAL PROPERTY RIG
15、HTS. TIA EXPRESSLY DISCLAIMS ANY AND ALL RESPONSIBILITIES FOR THE ACCURACY OF THE CONTENTS AND MAKES NO REPRESENTATIONS OR WARRANTIES REGARDING THE CONTENTS COMPLIANCE WITH ANY APPLICABLE STATUTE, RULE OR REGULATION, OR THE SAFETY OR HEALTH EFFECTS OF THE CONTENTS OR ANY PRODUCT OR SERVICE REFERRED
16、TO IN THE DOCUMENT OR PRODUCED OR RENDERED TO COMPLY WITH THE CONTENTS. TIA SHALL NOT BE LIABLE FOR ANY AND ALL DAMAGES, DIRECT OR INDIRECT, ARISING FROM OR RELATING TO ANY USE OF THE CONTENTS CONTAINED HEREIN, INCLUDING WITHOUT LIMITATION ANY AND ALL INDIRECT, SPECIAL, INCIDENTAL OR CONSEQUENTIAL D
17、AMAGES (INCLUDING DAMAGES FOR LOSS OF BUSINESS, LOSS OF PROFITS, LITIGATION, OR THE LIKE), WHETHER BASED UPON BREACH OF CONTRACT, BREACH OF WARRANTY, TORT (INCLUDING NEGLIGENCE), PRODUCT LIABILITY OR OTHERWISE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. THE FOREGOING NEGATION OF DAMAGES IS
18、A FUNDAMENTAL ELEMENT OF THE USE OF THE CONTENTS HEREOF, AND THESE CONTENTS WOULD NOT BE PUBLISHED BY TIA WITHOUT SUCH LIMITATIONS. TIA-1124 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56
19、57 58 59 60 i REVISION HISTORY Revision number Content changes. Date 0 Initial Release October 2007 TIA-1124 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 ii Table of Contents
20、 Table of Contentsii List of Figures.ii 1 INTRODUCTION.1 2 REFERENCES2 2.1 Informative References2 3 DEFINITIONS AND ABBREVIATIONS .3 4 GENERAL DESCRIPTION .5 4.1 Architecture Considerations9 5 REQUIREMENTS11 5.1 Policy Contexts .11 5.2 Admission Control 11 5.3 Policy Peering .13 5.4 Policy Manageme
21、nt.14 5.5 Authentication15 5.6 Privacy .15 Annex A Requirement Examples (Informative) 16 List of Figures Figure 1 A Comprehensive Services Architecture 6 TIA-1124 1 2 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50
22、51 52 53 54 55 56 57 58 59 60 1 3 4 1 INTRODUCTION Multimedia Doman (MMD) specifications 3 enable an operator to apply Quality of Service (QoS) policy controls to the Internet Protocol (IP) Connectivity Access Network on session-based applications, and to provision flow-based charging rules at the P
23、acket Data Serving Node (PDSN). These current specifications are confined to the PDSN as the sole policy enforcement point supported. The scope of MMD policy needs to be expanded to include overall coordination of network resource usage for Session Initiation Protocol (SIP) 4 and non-SIP application
24、s for all subscribers, enhancements to policy contexts, and incorporation of additional network elements in the policy architecture. This document specifies the system requirements related to these MMD Policy Enhancements, which are intended to guide the associated technical specification developmen
25、t. TIA-1124 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 2 2 REFERENCES 2.1 Informative References The references which are applicable to this specification include the follo
26、wing: 1 3GPP TS 23.228, IP Multimedia Subsystem (IMS) Stage 2. 2 3GPP2 S.R0079-A v1.0, Support for End-to-End QoS Stage 1 Requirements, July 2006. 3 3GPP2 X.S0013-A, Multimedia Domain series, November 2005. 4 IETF RFC3261, SIP: Session Initiation Protocol, June 2002. 5 IETF RFC3344, Mobility Support
27、 for IPv4, August 2002. 6 IETF RFC3775, Mobility Support for IPv6, June 2004. TIA-1124 1 2 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 3 3 4 3 DEFINITIONS AND ABBREVIATIONS The term
28、s and abbreviations which are used within this specification are defined as follows: 1xRTT 1x Radio Transmission Technology AF Application Function AGW Access Gateway AN Access Network AP Access Point AT Access Terminal BREW Binary Runtime Environment for Wireless CDMA Code Division Multiple Access
29、DSL Data Subscriber Line EVDO Evolution Data Only (a.k.a HRPD) FW Fire Wall HRPD High Rate Packet Data IMS IP Multimedia Subsytem IP Internet Protocol MMD Multi-Media Domain NAT Network Address Translation NSP Network Service Provider PCRF Policy and Charging Rules Function PDSN Packet Data Service
30、Node QoS Quality of Service SIP Session Initiation Protocol SLA Service-Level Agreement SSOO Single Sign-On/Off TCP Transmission Control Protocol TV Television VoIP Voice over IP UDP User Datagram Protocol UE User Equipment WCDMA Wide-band CDMA The following definition is used in this specification:
31、 TIA-1124 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 4 IP flow: Any identifiable (classifiable) set of IP packets from a source to one or more receivers for which a common
32、policy treatment has been requested. For example, a stream of packets having the same source address, destination address, protocol, and Transmission Control Protocol/User Datagram Protocol (TCP/UDP) ports is an IP flow. TIA-1124 1 2 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28
33、 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 5 3 4 4 GENERAL DESCRIPTION Policy requirements entail QoS requirements in reference 2, which specifies an end-to-end QoS model for cdma20001networks. While reference 2 advances a number of key QoS requi
34、rements for wireless IP networks, there are other capabilities which require policy treatment which are not discussed in that document. These additional capabilities are an integral part of evolution of MMD and are summarized in the following trends: Support for both SIP and non-SIP applications. It
35、 is anticipated that MMD networks will be deployed by operators who already have deployed non-IMS applications. It is also anticipated that these operators are not likely to replace these applications with IP Multimedia Subsystem 1 (IMS)-based versions for some time, if at all. This coexistence is e
36、xhibited in Figure 1 by showing how non-IMS-based SIP services, IMS-based SIP services, non-SIP services (e.g. Binary Runtime Environment for Wireless (BREW) and 3rdparty services are expected to be provided as part of a comprehensive services architecture. As it is likely that these services will c
37、oexist for some time, policy requirements must support the coexistence of both SIP and non-SIP applications. 1cdma2000is the trademark for the technical nomenclature for certain specifications and standards of the Organizational Partners (OPs) of 3GPP2. Geographically (and as of the date of publicat
38、ion), cdma2000is a registered trademark of the Telecommunications Industry Association (TIA-USA) in the United States. TIA-1124 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 3 4 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 6 2
39、2Non-IMSServicesHSSIMSServicesAppServersInternetOther1x RTTEVDOManaged IP NetworkBREWServices3rdParty Operator-Partnerother standards organizations have client-controlled architectures for NAT traversal. The policy requirements of this document should target an appropriate balance between these appr
40、oaches. The current MMD policy specifications primarily address policy control over IP bearer resources and per-flow accounting. Supporting the evolved MMD networks envisioned for the future necessitates enhancing the current specfications to incorporate the following items: Expansion of policy cont
41、exts. The current specifications only discuss QoS and accounting. There is a need to expand this list to include these other policy contexts: o Mobility and Roaming Policy. As part of supporting multiple access technologies, a network operator should also have the capability of controlling whether o
42、r not a roaming operation is permitted and whether or not a handoff operation is permitted. o Access. As part of providing enhanced authorization in an environment comprised of heterogeneous access technologies, a network operator should have the capability of controlling access into its network bas
43、ed on an ATs security status or account status, e.g., quarantining access to a site which allows the subscriber to download required security patches, refresh their pre-paid balance or pay a delinquent account. o Network Selection. With the availability of multiple access technologies, the network o
44、perator should have the capability of defining policies used by the AT for prioritizing network access and selecting which Access Network (AN) it uses for applications. o Packet Flow Optimization. A network should have the capability of searching IP flows, within privacy limits, in order to verify t
45、hat the application negotiated during session establishment is the application actually operating. Additionally, for selected applications incapable of requesting enhanced QoS, the network should be TIA-1124 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34
46、 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 8 able, by monitoring IP flows, to detect such applications and automatically employ network resources to provide the appropriate QoS. o Traffic Engineering. The services architecture exhibited in Figure 1 demonstrates th
47、e need to organize and allocate network resources in the most efficient manner in order to meet customer service commitments in the most cost effective manner. A network operator should have the capability of defining policies for admission control and congestion management (e.g. identifying what re
48、sources are allocated to an application, if and how these resources can be modified by an application, how the resources are modified during network congestions, etc.). o Resource Selection. When a user is in a visited network, routing traffic related to low latency applications back to the home net
49、work may result in undesireable latencies and/or network inefficiencies. A network operator should have the capability of defining policies which result in route optimization. o Authentication. After a user agent provides authentication credentials within an operator-hosted session, subsequent re-entry of the same credentials associated with subsequent session hosted by the same operator should not be required. Similarly, when a user terminates a connection to an operator hosted session manager, then all sessions which were previously authenticated under
