Internet DRAFT - draft-hamer-rap-cops-umts-go

draft-hamer-rap-cops-umts-go





   Internet Draft                                   L-N. Hamer 
   Expires April 2002                               K. Chan 
   File: draft-hamer-rap-cops-umts-go-00.txt        H. Syed      
                                                    Nortel Networks 
     
                                                    H. Shieh  
                                                    AT&T Wireless 
                                                    
                                                    R. Zwart 
                                                    AT&T 
                                                    
    
                                                    November 12, 2001 
    
 
                     COPS-PR for outsourcing in UMTS: 
                                UMTS Go PIB 
    
    
 
Status of this Memo 
    
   This document is an Internet-Draft and is in full conformance with 
   all provisions of Section 10 of RFC2026.  Internet-Drafts are 
   working documents of the Internet Engineering Task Force (IETF), its 
   areas, and its working groups.  Note that other groups may also 
   distribute working documents as Internet-Drafts. 
    
   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''. 
    
   To view the current status of any Internet-Draft, please check the 
   ''1id-abstracts.txt'' listing contained in an Internet-Drafts Shadow 
   Directory, see http://www.ietf.org/shadow.html. 
    
Abstract 
    
   This document describes usage directives for supporting COPS 
   outsourcing policy services in the UMTS environment. Through the use 
   of the UMTS Go PIB, defined in this document, COPS-PR is used for 
   outsourcing over the Go interface. 
    
Disclaimer 
    
   This document is to be considered work in progress. Although, the 
   3GPP CN3 WG has ratified the use of COPS-PR over the Go interface, 
   the level of detail in this document as not been formally approved 
   yet. Its purpose is to inform the IETF of the direction 3GPP has 
   taken for the UMTS Go interface. A revised version of this document 
   will be published once it is approved by 3GPP. 
    

  
                                                              [Page 1] 

COPS-PR for outsourcing in UMTS                           November 2001 
 
 
 
1. Glossary 
    
   PRC    Provisioning Class.       A type of policy data. 
   PRI    Provisioning Instance.    An instance of a PRC. 
   PIB    Policy Information Base.  The database of policy information. 
   PDP    Policy Decision Point.    See [RAP-FRAMEWORK]. 
   PEP    Policy Enforcement Point. See [RAP-FRAMEWORK]. 
   PRID   Provisioning Instance Identifier.  Uniquely identifies an 
          instance of a PRC. 
   PCF    Policy Control Function    
   UE     User Equipment 
   GGSN   Gateway GPRS Support Node 
   SGSN   Serving GPRS Support Node 
   PDP context    Packet Data Protocol context 
 
    
2. Introduction 
    
   COPS has been developed as a protocol for use between a policy 
   server/PDP and a network device/PEP, as described in [COPS]. 
   In addition, COPS for Provisioning extensions has been developed as 
   described in [COPS-PR] with [SPPI] describing a structure for 
   specifying policy information that can then be transmitted to a 
   network device for the purpose of configuring policy at that device.  
   The model underlying this structure is one of well-defined 
   provisioning classes and instances of these classes residing in a 
   virtual information store called the Policy Information Base (PIB). 
    
   One way to provision policy is by means of the COPS protocol [COPS] 
   with the extensions for provisioning [COPS-PR].  This protocol 
   supports multiple clients, each of which may provision policy for a 
   specific policy domain such as QoS, virtual private networks, or 
   security. 
    
   The technology used in [COPS-PR], [SPPI], [FRWRK-PIB], and [DS-PIB] 
   can be applied to Policy Control of UMTS network devices.  This 
   document describes the usage of [COPS-PR] technology applied to the 
   Go interface as indicated in [UMTS-Go][UMTS-QoS]. 
    
2.1 Rationale for using COPS-PR for outsourcing in UMTS 
 
 

   Two options were studied for policy control over the Go interface: 
   1- Creating object extension for UMTS, in the same way COPS-RSVP was 
   defined. 
   2- Using COPS-PR for outsourcing with a UMTS PIB. 
    
   Option 2 was chosen for many reasons. Here are the highlights: 
    
   -Provisioning functionality has generally been thought of as static, 
   but within the context of COPS-PR, the degree of dynamic/static is 
   up to the user of the technology. The events handled by COPS-PR can 

Hamer, et al.                                                 [Page 2] 
                                                                       

COPS-PR for outsourcing in UMTS                           November 2001 
 
 
   be very dynamic to very static. The degree of dynamic-ness is in 
   itself a policy, and can be controlled with COPS-PR with flexibility 
   in both event detection/reporting frequency and granularity.  
    
   -Separation of Protocol and Policy Control Information. COPS-PR 
   takes the approach of defining a stable, reusable, more widely 
   applicable protocol. With the applicability addressed by the Policy 
   Control Information carried by the COPS-PR protocol. 
    
   -By designing a PIB (Policy Information Base) by and for 3GPP, no 
   change is needed to the COPS-PR protocol itself. This is a good way 
   of building on existing technology without having to revisit the 
   protocol every time new information needs to be carried by the 
   protocol. This also provides a faster way to deployment without 
   going through another cycle of standardization for the protocol. 
   This provides more flexibility and a standard way for the 
   implementations to add value by extending the standardized Policy 
   Control Information. 
    
   -The notion of Out-Sourcing and Provisioning really depends on the 
   Events being handled by the network device and how much of the event 
   handling is done at the network device. With COPS-PR, the definition 
   of the Events is defined by the PIB (Policy Information Base) and 
   can be changed even within the same COPS session state (the event 
   handling is itself policy controlled). This allows the handling of 
   different signaling protocols very easily. 
    
   -Capability of both the network device and policy server is 
   negotiated between the network device and policy server. This allows 
   dynamic adjustments between the network device and policy server, 
   and allows flexibility in implementation and deployment of different 
   standard features as needed. 
    
   -Levels of outsourcing details can be as coarse (aggregated) or fine 
   (per micro-flow) as necessary and can be adjusted dynamically when 
   needed. 
    
   -Re-using parts of well-defined PIBs ensures a prompt definition of 
   the Go interface and favors a more general solution that can be 
   scaled to multiple environments. 
 
 

 
 

 
 
 

 

 

 
    
    

Hamer, et al.                                                 [Page 3] 
                                                                       

COPS-PR for outsourcing in UMTS                           November 2001 
 
 
3. Definition of terms  
    
   Figure 1 introduces the policy control model for UMTS. This is only 
   an overview and does not cover all the details. For more details, 
   please consult [UMTS-QoS][UMTS-IM][UMTS-ARCH].  
    
                                                            +---+ 
                                                            |   | 
                    +-------------------+--------+          | I | 
                    | P-CSCF            | PCF    |          | n | 
                    |                   | (PDP)  |          | t | 
                    |                   |        | <------->| e | 
                    |                   |        |          | r | 
                    |                   |        |          | - | 
                    +-------------------+---|----+          | c | 
                                            |               | o | 
                                            |               | n | 
                                            |               | n | 
                                           -|- Go inter-    | e | 
                                            |     face      | c | 
                                            |               | t | 
                                            |               | i | 
                     +------------+    +----|--------+      | n |  
   +----------+      |            |    |    |        |      | g |  
   | UE       |      | SGSN       |    |GGSN|        |      |   |  
   |          |      |            |    |+---|------+ |      | N |  
   |+--------+|      |            |    ||PEP       | |      | e |  
   ||SIP User||      |+----------+|    |+----------+ |<---->| t |  
   ||Agent   ||      || UMTS BS  ||    |+----------+ |      | w |  
   |+--------+|      || Manager  ||    ||UMTS BS M | |      | o |  
   ||UMTS BS ||<---->|+----------+|<-->|+----------+ |      | r |  
   ||Manager ||      +------------+    +-------------+      | k |  
   |+--------+|                                             |   |  
   +----------+                                             +---+  
   Figure 1: Policy control model for UMTS  
    
    
   UE - User Equipment: The UE is the UMTS term for a device used by a 
   subscriber to access network services. The UE includes a client for 
   requesting network services (e.g. through SIP) and a client for 
   requesting network resources (e.g. through PDP context 
   establishment). In this document, the term 'terminal' is used to 
   mean the same as UE. 
    
   SGSN - Serving GPRS Support Node: The SGSN performs the necessary 
   functions in order to handle the packet transmission to and from the 
   UE. 
    
   PEP - Policy Enforcement Point: The PEP is a logical entity that 
   enforces policy decisions made by the PCF.  
    
   GGSN - Gateway GPRS Support Node: The GGSN is a network element 
   connecting the UE to the external network. The GGSN contains a PEP 
Hamer, et al.                                                 [Page 4] 
                                                                       

COPS-PR for outsourcing in UMTS                           November 2001 
 
 
   to enforce policies. It also contains a UMTS BS Manager for handling 
   resource reservation requests from the UE (e.g. through PDP context 
   signaling). 
    
   PCF - Policy Control Function (aka, PDP): The PCF is a logical 
   policy decision element which uses standard IP mechanisms to 
   implement policy in the IP media layer.  The PCF makes decisions in 
   regard to network based IP policy using policy rules, and 
   communicates these decisions to the PEP in the GGSN. The term PCF 
   was chosen over PDP (Policy Decision point) in this document to 
   avoid confusion with PDP context messages. 
    
   UMTS BS Manager: The UMTS Bearer Service Manager handles resource 
   reservation requests from the UE.  
    
   P-CSCF - Proxy Call Session Control Function: The P-CSCF is a 
   network element providing session management services (e.g. 
   telephony call control). 
    
   Go interface - Interface between the GGSN (PEP) and PCF (PDP). 
    
































Hamer, et al.                                                 [Page 5] 
                                                                       

COPS-PR for outsourcing in UMTS                           November 2001 
 
 
4. General UMTS and Go Interface Concepts 
    
4.1. UMTS IP Multimedia Subsystem 
    
    
   The IP Multimedia Subsystem (IMS) utilizes the UMTS Packet Switched 
   (PS) domain to transport multimedia signaling and media traffic. The 
   PS domain provides the IP network connection to the UE. The IMS 
   comprises the core network elements for provision of multimedia 
   services. This includes the collection of signaling and media 
   related network elements as defined in [UMTS-Arch]. IP multimedia 
   services are based on an IETF defined session control capability. 
   In order to achieve access independence and to maintain a smooth 
   interoperation with wireline terminals across the Internet, the IMS 
   is intended to be conformant to IETF 'Internet standards'. For IMS 
   session control, the SIP protocol [IETF-SIP] has been selected. 
    
    
4.2. Session authorization framework 
    
   The UMTS architecture has to satisfy requirements for end-to-end 
   QoS, authorization of network resource usage and accurate accounting 
   for resources used. Therefore, policies may be enforced during 
   session set up, e.g. to ensure that the media streams being 
   requested lie within the bounds of the service profile established 
   for the requesting user. Similarly, when a terminal requests 
   resources to provide a certain QoS for a packet flow, policies may 
   be enforced to ensure that the requested resources lie within the 
   bounds of the allowed resource profile established and the available 
   'budget' for the requesting terminal.  
       
   In order to prevent fraud and to ensure accurate billing, UMTS 
   defines a mechanism that allows for verification that the resources 
   being used to provide a requested QoS are in-line with the media 
   streams requested (and authorized) for the session. This linkage is 
   provided through the use of an "authorization token". We briefly 
   describe this mechanism below. The details of the procedures can be 
   found in [UMTS-IM][UMTS-QoS]. 
    
   Session authorization mechanism  
    
   1. The UE issues a session set-up request (i.e. SIP INVITE) to the 
   P-CSCF indicating, among other things, the media streams to be used 
   in the session. As part of this step, the terminal may authenticate 
   itself to the P-CSCF.  
        
   2. The P-CSCF forwards the SIP INVITE to other CSCF functions in the 
   network. These functions are not further described here. However, 
   the result of this will be that the P-CSCF receives a provisional 
   SIP response from the other endpoint of the call. This will 
   typically be a SIP 183 response message, also containing the 
   relevant media information pertaining to the other half of the media 

Hamer, et al.                                                 [Page 6] 
                                                                       

COPS-PR for outsourcing in UMTS                           November 2001 
 
 
   to be used.  Based on this information, the P-CSCF sends to the PCF 
   the necessary information to authorize the request.  
    
   3. Based on the information received, containing information 
   elements like bandwidth required, IP end points addresses and ports, 
   the PCF authorizes the session and sends a decision to the P-CSCF. 
   Included in this response is an "authorization token" that can 
   subsequently be used by the PCF to identify the session and the 
   media it has authorized.  
        
   4. The P-CSCF sends a response to the UE (e.g. by forwarding the SIP 
   183) indicating that session set-up is progressing. Included in this 
   response is a description of the negotiated media along with the 
   token from the PCF.  
        
   5. The UE issues a request (e.g. PDP context activation) to reserve 
   the resources necessary to provide the required QoS for the media 
   stream. Included in this request is the token from the PCF provided 
   via the P-CSCF and flow identifier(s) that identifies the flow(s) on 
   the PDP Context.  
        
   6. The GGSN receives the reservation request and sends a  
   policy decision request (e.g. COPS REQ) to the PCF in order to 
   determine if the resource reservation request should be allowed to 
   proceed. Included in this request is the token and the flow 
   identifier(s) provided by the UE. The PCF uses this token and flow 
   identifier(s) to correlate the request for resources with the media 
   authorization previously provided to the P-CSCF.  
        
   7. The PCF sends a decision (e.g. COPS DEC) to the GGSN. 
        
   8. The GGSN sends a response to the UE (e.g. PDP context activation 
   response) indicating that resource reservation is complete. 
    
    
4.3. Go Interface 
    
   The mechanism described in section 4.2, will allow for service based 
   policy control over the interface between the GGSN and PCF. This 
   interface is known in UMTS as the Go interface. 
    
   At initialization, the PEP will inform the PCF of its capabilities. 
   In return, the PCF will respond by provisioning the PEP what types 
   of events require the trigger of policy outsourcing.    
    
   When such an event occurs, the PEP will trigger a COPS REQ and send 
   it to the PCF. The main difference with other admission control 
   frameworks [RAP-FRAMEWORK] is that the session information is 
   already stored in the PCF prior to receiving the COPS request. 
   Therefore, the COPS REQ does not need to encapsulate all of the 
   information contained in the bearer request-signaling message. The 
   COPS REQ must contain a token and flow Ids referencing the 

Hamer, et al.                                                 [Page 7] 
                                                                       

COPS-PR for outsourcing in UMTS                           November 2001 
 
 
   previously installed session state and may also contain the 
   parameters of the QoS request. 
    
   On receipt of the COPS Request, the PCF uses the token, containing a 
   unique session identifier, to retrieve the session information and 
   take an informed decision. The PCF can then push down a decision 
   using standard COPS-PR schematics. 
    
   Over the Go interface, information can be exchanged to support the 
   following functions in the GGSN: 
    
      - Control of Diffserv inter-working, 
      - Control of 'gating' function in GGSN, 
      - UMTS media authorization, 
      - QoS charging related function. 
    
   The control of Diffserv interworking can be achieved using COPS-PR  
   and importing the necessary data structures from the diffserv PIB. 
    
   The control of gating, UMTS media authorization and QoS charging can 
   be achieved using standards COPS-PR and by importing the necessary 
   data structures from the framework PIB with minor extensions to be 
   included in the UMTS Go PIB, detailed in section 7 & 8.  
    
    
 
5. COPS-PR Usage for UMTS Go Interface 
 
5.1 General Description 
    
    
   The Go Interface uses COPS-PR [COPS-PR] schematics and the UMTS Go 
   PIB. COPS-PR was initially designed for provisioning purposes only 
   but this document proposes a usage of COPS-PR for outsourcing 
   purposes. 
    
   For COPS-PR to handle the Outsourcing Model it is required to add a 
   new UMTS Go PIB with objects to: 
    
   -Describe the Triggering Event Handling.  This needs to include 
   objects for the Functionality Capability description and 
   provisioning. 
   -Describe the Outsourcing Event. 
   -Describe the Decision for the Outsourced Event. 
   -Describe the Termination of the Outsourced Event. 
   -Describe the resource used for the Outsourced Event. 
    
    
    
    
    
    
    
Hamer, et al.                                                 [Page 8] 
                                                                       

COPS-PR for outsourcing in UMTS                           November 2001 
 
 
5.2 UMTS-specific Information in COPS-PR 
    
5.2.1 Common Header, Client Type 
    
   Client-type is UMTS Go(Client type number to be assigned through 
   IANA) 
    
5.2.2 Context Object 
    
   C-Num = 2, C-Type = 1 
    
           0             1               2               3 
          +--------------+--------------+--------------+--------------+ 
          |            R-Type           |            M-Type           | 
          +--------------+--------------+--------------+--------------+ 
    
              R-Type (Request Type Flag) 
    
                  0x02 = Resource-Allocation request 
                  0x08 = Configuration request 
    
              M-Type (Message Type) 
    
                  0x01 = Create PDP Context (with the token) 
                  0x02 = update PDP Context (with the token) 
                   
    
    
5.2.3 Client Specific Information (ClientSI) for outsourcing Operation 
     

   The Token and flow identifier(s) received in the incoming message at 
   the UMTS PEP is encapsulated inside the Client Specific Information 
   object of the COPS request message sent from the PEP to the PCF. The 
   parameters describing the requested QoS may also be contained inside 
   the Client SI object. 
  

   The following is detailed in section 8, under 'TBD'.  

    
    
5.3 General Operations 
    
5.3.1. Reporting of Device Capabilities and Device Limitations 
    
   This functionality is already supported by COPS-PR. This sectionÆs 
   purpose is to detail its usage in the UMTS environment. 
    
   The configuration request message serves as a request from the PEP 
   to the PCF for provisioning policy data that the PCF may have for 
   the PEP. The configuration request message should include 
   provisioning client information to provide the PCF with client-
   specific configuration or capability information about the PEP.   
    

Hamer, et al.                                                 [Page 9] 
                                                                       

COPS-PR for outsourcing in UMTS                           November 2001 
 
 
   In a UMTS environment, the information provided by the PEP should 
   include client capabilities and default policy configuration (e.g., 
   default role combinations) information as well as incarnation data 
   on existing policy. The client capabilities can be described by what 
   type of bearer signaling is supported (e.g. PDP context signaling). 
   This information from the client assists the server in deciding what 
   types of policy the PEP can install and enforce.   
    
    
   The PCF responds to the configuration request with an initial UMTS 
   policy Provisioning DEC message, described in 5.3.2.  
    
    
5.3.2. Initial UMTS Policy Provisioning 
    
   This functionality is already supported by COPS-PR. This section 
   purpose is to detail its usage in the UMTS environment. 
    
   The DEC message is sent from the PCF to the PEP in response to the 
   REQ message received from the PEP.  The Client Handle MUST be the 
   same Handle that was received in the corresponding REQ message. 
    
   The DEC message is sent as an immediate response to a configuration 
   request with the solicited message flag set in the COPS message 
   header. In a UMTS environment, the PCF will provision the PEPÆs 
   bearer signaling triggering capability. Basically, the PCF will 
   inform the PEP what types of events (e.g. receipt of a PDP context 
   message) require the trigger of policy outsourcing.  
    
    
5.3.3 COPS-PR Outsourcing Operation 
    
   The following sections describe all of the UMTS Policy Events. A 
   Policy event triggers the appropriate COPS messages to be sent over 
   the Go interface. 
    
5.3.3.1. UMTS Service Request 
    
   UMTS Service Requests are triggered by the PEP receiving resource 
   allocation bearer plane signaling messages. The following messages 
   trigger a UMTS Service Request: 
    
   Create PDP Context Request with a token 
   Update PDP Context Request with a token 
    
   This service request is used when the PEP is about to commit local 
   resources to a particular PDP context. The PEP includes in the UMTS 
   service Request the token and flow identifiers it received from the 
   PDP context message. The PCF can then use this token and flow 
   identifiers to correlate this media request to a previously 
   installed state in its database relating to this service request.  
    
    
Hamer, et al.                                                [Page 10] 
                                                                       

COPS-PR for outsourcing in UMTS                           November 2001 
 
 
5.3.3.2 Outsourced UMTS Decision 
 

   A Subsequent DEC message is sent from the PCF to the PEP in response 
   to the REQ message received from the PEP.  The Client Handle MUST be 
   the same Handle that was received in the corresponding REQ message. 
    
   The DEC message is sent as an immediate response to an outsourcing 
   request with the solicited message flag set in the COPS message 
   header.  Subsequent DEC messages may also be sent at any time after 
   the original DEC message to supply the PEP with additional/updated 
   policy information without the solicited message flag set in the 
   COPS message header (as they are unsolicited decisions). This can be 
   trigerred by the P-CSCF notification of a SIP event (e.g. Commit, 
   Revoke). 
    
    
    
5.3.3.3 UMTS Service Usage Reporting 
    
   The UMTS Service Usage Reporting is identical to the COPS-PR report 
   message. The RPT message is sent from the PEP to the PCF to report 
   accounting information associated with the policy control, or to 
   notify the PCF of changes in the PEP (Report-Type = 'Accounting'). 
    
   RPT is also used as a mechanism to inform the PCF about the action 
   taken at the PEP in response to a DEC message.   
    
   The RPT message may contain PEP information such as 
   accounting parameters or errors/warnings related to a decision. The 
   data format for this information is defined in the context of the 
   policy information base (see section 8).  
    
    
5.3.3.4 UMTS Service Usage Termination 
    
   UMTS Service Terminations are triggered by the PEP receiving 
   teardown bearer plane signaling messages. The following messages 
   trigger a UMTS Service Usage Termination: 
    
   Delete PDP Context Request with a token 
    
   This service usage termination is used when the PEP releases local 
   resources to a particular PDP context. This can be the result of the 
   receipt of a delete PDP context request or any other event forcing 
   the PEP to release committed resources (e.g. network failure). 
    
   If the entire resources associated with a particular installed state 
   are to be released: 
   the Termination message is the same format as a DRQ. 
   This information will then be used by the PCF to initiate the 
   appropriate housekeeping actions (e.g. the PCF terminates the entire 
   session associated with that specific client handle). 

Hamer, et al.                                                [Page 11] 
                                                                       

COPS-PR for outsourcing in UMTS                           November 2001 
 
 
    
   If only a subset of resources associated with a particular installed 
   state are to be released: 
   the Termination message is the same format as a REQ. 
   The REQ will contain the token and flow Ids to be released. The PCF 
   terminates only the specified flows and keeps alive all other flows 
   associated with that particular client handle. 
    
    
6. Relationship between UMTSÆs COPS-PR Usage and other COPS-PR Usages 
    
   COPS-PR for the UMTS Go interface is used for outsourcing policy 
   over the Go interface. This usage of COPS-PR could be coupled with 
   other COPS-PR usages. This flexibility is allowed since all COPS-PR 
   usages use the same protocol with PRCs defined in their respective 
   PIB. 
    
   For example, [FEEDBACK] defines the policy usage feedback framework 
   PIB that specifies the policy classes common for COPS feedback 
   reports. This feedback PIB could be used in conjunction with the 
   UMTS Go PIB to provide a more complete solution. 
    
   There are no restrictions on the usage of the UMTS Go PIB with other 
   defined PIBs. This decision is left to the user/operator of the 
   network. 
    
6.1 Re-use of PRCs from other PIBs 
    
   It is intended that the UMTS Go PIB will reuse as much of existing 
   standard technology as possible by importing some PRCs from existing 
   PIBS.  Following is a list of the PRCs that would be useful for the 
   Go interface: 
    
   From the Framework PIB [Frwrk-PIB]: 
    
     The Base Filter class PRC.  
     The IP Filter PRC. 
     These two PRCs will enable the PCF to push down filters to the  
     PEP. 
     A filter defines fields that a packet has to match to be  
     considered as part of a particular data flow.  Wildcards may be 
     specified for those fields that are not relevant. 
  
   From the DiffServ PIB [DS-PIB]: 
    
     Classifier Element PRCs :The classifier and classifier element  
     tables determine how traffic is sorted out. They identify  
     separable classes of traffic, by reference to appropriate filters,  
     which may select anything from an individual micro-flow to  
     aggregates identified by DSCP. 
    
     Meter PRCs : The generic meter PRC is used as a base for all more  
     specific forms of meter. This enables the use of any sort of  
Hamer, et al.                                                [Page 12] 
                                                                       

COPS-PR for outsourcing in UMTS                           November 2001 
 
 
     specific meter table that one might wish to design, standard or  
     proprietary. 
    
     Token bucket parameter PRC: A specific type of meter. This defines  
     the authorized envelope for a particular flow. 
     
     DSCP Mark Action PRC: This Action is applied to traffic in order  
     to mark it with a Diffserv Codepoint (DSCP) value. 
    
     Algorithmic Dropper PRC: Action to take on out-of-profile packets  
     from a flow not respecting the bounds of its authorized envelope. 
  
     
    
 
7. Summary of the UMTS PIB 
    
   The UMTS PIB comprises of the following groups: 
    
   1. UMTS Capability and Limitation Group 
    
      The Capability section of this PIB contains PRCs describing 
      the functionalities of the PEP. This is accomplished by 
      indicating which PRCs are used by the PEP and the limitations 
      of the attributes supported in each PRC. 
       
      The organization of the capability section follows the functional 
      sections of this PIB, it contains PRCs for: 
      - Event Handling Capability, this indicates the Events the PEP   
        can handle. 
      - Event Handler Capability, this indicates the detail capability  
        of each of the Event Handlers supported. 
      - Event PRCs supported.  This indicates the PRCs used to describe  
        the events themselves, including the decisions that the PEP  
        will accept from the PCF. 
    
      The Capability Group contains the following kinds of PRCs: 
    
      Device Capability Table 
    
        Description of Capability PRCs - Defines the capabilities of    
        the PEP in terms of PRCs. This group consists of PRCs to 
        indicate to the PDP the types of UMTS functionality supported
        on the PEP in terms of the PRCs that the PCF can install in 
        order to configure these interfaces to affect the desired 
        policy. 
 
      Device Limitations Table 
    
        Description of Limitation PRCs - Defines the limitations of the 
        PEP. For example, set the maximum number of flows that one PDP 
        context can support. 
 
Hamer, et al.                                                [Page 13] 
                                                                       

COPS-PR for outsourcing in UMTS                           November 2001 
 
 
      Device Error Handling Capability Table 
    
        Description of Error Handling PRCs - Defines the error handling 
        capabilities of the PEP to the PCF. 
    
    
   2. Event Handler Provisioning Group 
    
      This group contains the PRCs that are used for provisioning the 
      Event Handlers.  There should be a set of PRCs for each type of 
      event signaling protocol or method.  For example this document 
      contains the PRCs for provisioning the PDP Context handler.  
      Types of event may include signaling protocols, or other events 
      that will trigger an outsourcing request from the PEP to the PCF. 
    
    
   3. UMTS Event Group 
    
      This group contains the PRCs that describe the outsourcing policy 
      events.  There should be a set of PRCs for each type of event 
      being handled.  Currently this PIB contains the following PRCs 
      for describing PDP Context events: 
 
   Service request Table 
        Description of Service request PRC - Defines the service 
        request from the PEP to the PCF. 
    
   Outsourced policy Table 
        Description of Outsourced policy PRCs - Defines the policy 
        decisions supplied by the PCF to the PEP. 
    
   Service Usage Reporting Table 
        Description of the service usage reporting PRCs - Defines the   
        reports sent from the PEP to the PCF. 
    
   Service usage termination Table 
        Description of the service usage termination PRCs - Defines the 
        termination indications from the PEP to the PCF. 
 
    
    
    
8. The UMTS PIB module 
    
   Note: This section is incomplete. Currently, only a few PRCs are 
   defined for informational purposes. As the 3GPP CN3 WG defines and 
   agrees upon what new PRCs are needed, this section will be updated.  
    
   UMTS-PIB  PIB-DEFINITIONS ::= BEGIN 
    
   IMPORTS 
       Unsigned32, Integer32, MODULE-IDENTITY, 
       MODULE-COMPLIANCE, OBJECT-TYPE, OBJECT-GROUP 
Hamer, et al.                                                [Page 14] 
                                                                       

COPS-PR for outsourcing in UMTS                           November 2001 
 
 
               FROM COPS-PR-SPPI 
       InstanceId, Prid 
               FROM COPS-PR-SPPI-TC  
       RoleCombination, PrcIdentifier  
               FROM FRAMEWORK-ROLE-PIB 
       InetAddress, InetAddressType 
               FROM INET-ADDRESS-MIB 
       TruthValue, PhysAddress 
               FROM SNMPv2-TC            
       SnmpAdminString 
               FROM SNMP-FRAMEWORK-MIB; 
 
   uMTSPib  MODULE-IDENTITY 
       SUBJECT-CATEGORIES   { umts } 
       LAST-UPDATED "200111010800Z" 
       ORGANIZATION "IETF RAP WG" 
       CONTACT-INFO "Kwok Ho Chan 
                     Nortel Networks 
                     600 Technology Park Drive 
                     Billerica, MA 01821 USA 
                     Phone: +1 978 288 8175 
                     Email: khchan@nortelnetworks.com 
    
                     Louis-Nicolas Hamer 
                     Nortel Networks 
                     100 Constellation Crescent 
                     Ottawa, Ontario 
                     Canada, K2G 6J8 
                     Phone: +1 613 768 3409 
                     Email: nhamer@nortelnetworks.com" 
       DESCRIPTION 
               "A PIB module containing the set of provisioning  
               classes that are required for support of policies for  
               UMTS subject-categories." 
    
       ::= { tbd } 
    
    
   -- 
   -- The root OID for PRCs in the UMTS PIB 
   -- 
    
   uMTSCapabilityClasses   OBJECT IDENTIFIER ::= { uMTSPib 1 } 
   uMTSEventPolicyClasses  OBJECT IDENTIFIER ::= { uMTSPib 2 } 
   uMTSEventClasses        OBJECT IDENTIFIER ::= { uMTSPib 3 } 
   uMTSConformance         OBJECT IDENTIFIER ::= { uMTSPib 4 } 
 
   -- 
   -- Capability and Limitation Policy Rule Classes 
   -- 
    
   -- 
   -- UMTS Capability Base Table 
Hamer, et al.                                                [Page 15] 
                                                                       

COPS-PR for outsourcing in UMTS                           November 2001 
 
 
   -- 
    
   uMTSBaseCapsTable OBJECT-TYPE 
       SYNTAX         SEQUENCE OF UMTSBaseCapsEntry 
       PIB-ACCESS     notify  
       STATUS         current 
       DESCRIPTION 
           "" 
 
       ::= { uMTSCapabilityClasses 1 } 
    
    
    
   uMTSBaseCapsEntry OBJECT-TYPE 
       SYNTAX         UMTSBaseCapsEntry 
       STATUS         current 
       DESCRIPTION 
           "An instance of the uMTSBaseCaps class that identifies a 
           specific PRC and associated attributes as supported 
           by the device." 
    
       PIB-INDEX { uMTSBaseCapsPrid } 
       UNIQUENESS { uMTSBaseCaps }   
    
       ::= { uMTSBaseCapsTable 1 } 
 
    
   UMTSBaseCapsEntry ::= SEQUENCE { 
           uMTSBaseCapsPrid             InstanceId, 
           uMTSBaseCapsX                Unsigned32 
   } 
    
    
   uMTSBaseCapsPrid OBJECT-TYPE 
       SYNTAX         InstanceId 
       STATUS         current 
       DESCRIPTION 
           "An arbitrary integer index that uniquely identifies an 
           instance of the uMTSBaseCaps class." 
    
       ::= { uMTSBaseCapsEntry 1 } 
    
    
   uMTSBaseCapsX OBJECT-TYPE 
       SYNTAX         Unsigned32 
       STATUS         current 
       DESCRIPTION 
           "" 
    
       ::= { uMTSBaseCapsEntry 2 } 
    
    

Hamer, et al.                                                [Page 16] 
                                                                       

COPS-PR for outsourcing in UMTS                           November 2001 
 
 
   -- 
   -- Component Limitations Table 
   -- 
    
   -- This table supports the ability to export information 
   -- detailing provisioning class/attribute implementation limitations 
   -- to the policy management system. 
    
    












































Hamer, et al.                                                [Page 17] 
                                                                       

COPS-PR for outsourcing in UMTS                           November 2001 
 
 
   -- 
   -- UMTS Event Policy Classes 
   -- 
    
   -- 
   -- UMTS Event Policy Base Table 
   -- 
 
   uMTSBaseEventPolicyTable OBJECT-TYPE 
       SYNTAX         SEQUENCE OF UMTSBaseEventPolicyEntry 
       PIB-ACCESS     notify  
       STATUS         current 
       DESCRIPTION 
           "" 
 
       ::= { uMTSEventPolicyClasses 1 } 
 
 
   uMTSBaseEventPolicyEntry OBJECT-TYPE 
       SYNTAX         UMTSBaseEventPolicyEntry 
       STATUS         current 
       DESCRIPTION 
           "An instance of the uMTSBaseCaps class that identifies a 
           specific PRC and associated attributes as supported 
           by the device." 
    
       PIB-INDEX { uMTSBaseEventPolicyPrid } 
       UNIQUENESS { uMTSBaseEventPolicyPrc }   
    
       ::= { uMTSBaseEventPolicyTable 1 } 
 
    
   UMTSBaseEventPolicyEntry ::= SEQUENCE { 
           uMTSBaseEventPolicyPrid      InstanceId, 
           uMTSBaseEventPolicyIfName    SnmpAdminString, 
           uMTSBaseEventPolicyRoles     RoleCombination 
   } 
    
    
   uMTSBaseEventPolicyPrid OBJECT-TYPE 
       SYNTAX         InstanceId 
       STATUS         current 
       DESCRIPTION 
           "An arbitrary integer index that uniquely identifies an 
           instance of the uMTSBaseCaps class." 
    
       ::= { uMTSBaseEventPolicyEntry 1 } 
    
    
   uMTSBaseEventPolicyIfName OBJECT-TYPE 
       SYNTAX         SnmpAdminString 
       STATUS         current 
       DESCRIPTION 
Hamer, et al.                                                [Page 18] 
                                                                       

COPS-PR for outsourcing in UMTS                           November 2001 
 
 
           "The interface capability set to which this event handler 
           provisioning entry applies.   
           The interface capability name specified by this attribute 
           must exist in the frwkIfCapSetTable (of the Framework PIB) 
           prior to association with an instance of this class." 
       ::= { uMTSBaseEventPolicyEntry 2 } 
    
    
   uMTSBaseEventPolicyRoles OBJECT-TYPE 
       SYNTAX         RoleCombination 
       STATUS         current 
       DESCRIPTION 
           "The interfaces to which this entry applies, specified in 
           terms of roles. 
           There must exist an entry in the frwkIfCapSetRoleComboTable 
           (of the Framework PIB) specifying this role combination, 
           together with the interface capability set specified by 
           uMTSBaseEventPolicyIfName, prior to association with an 
           instance of this class." 
       ::= { uMTSBaseEventPolicyEntry 3 } 
    
    
    
   -- 
   -- UMTS PDP Context Event Handler Provisioning Table 
   --  
 
   uMTSPdpContextPolicyTable OBJECT-TYPE 
       SYNTAX         SEQUENCE OF UMTSPdpContextPolicyEntry 
       PIB-ACCESS     notify  
       STATUS         current 
       DESCRIPTION 
           "" 
 
       ::= { uMTSEventPolicyClasses 2 } 
 
 
   uMTSPdpContextPolicyEntry OBJECT-TYPE 
       SYNTAX         UMTSPdpContextPolicyEntry 
       STATUS         current 
       DESCRIPTION 
           "An instance of the uMTSBaseCaps class that identifies a 
           specific PRC and associated attributes as supported 
           by the device." 
    
       EXTENDS { uMTBaseEventPolicyEntry } 
       UNIQUENESS { uMTSPdpContextPolicyEnable, 
                    uMTSPdpContextPolicyFlowIds 
                  }   
       ::= { uMTSPdpContextPolicyTable 1 } 
 
    
   UMTSPdpContextPolicyEntry ::= SEQUENCE { 
Hamer, et al.                                                [Page 19] 
                                                                       

COPS-PR for outsourcing in UMTS                           November 2001 
 
 
           uMTSPdpContextPolicyEnable   Integer32, 
           uMTSPdpContextPolicyFlowIds  Unsigned32 
   } 
    
    
   uMTSPdpContextPolicyEnable OBJECT-TYPE 
       SYNTAX         Integer32 { 
                           disable(1), 
                           enable(2) 
                      } 
       STATUS         current 
       DESCRIPTION 
           "Controls the usage of UMTS PDP Context Events to trigger 
           requests to PCF on the go interface." 
       DEFVAL { disable } 
       ::= { uMTSPdpContextPolicyEntry 1 } 
    
    
   uMTSPdpContextPolicyFlowIds OBJECT-TYPE 
       SYNTAX         Unsigned32 
       STATUS         current 
       DESCRIPTION 
           "Indication of the maximum number of FlowIds a Token can  
           be associated with 
           The value of zero indicates policy control does not impose 
           any limit.  The limitation is based on GGSN capabilities." 
       DEFVAL  { 0 } 
       ::= { uMTSPdpContextPolicyEntry 2 } 
    
    
    
   -- 
   -- RSVP Event Handler Provisioning Table 
   -- 
    


















Hamer, et al.                                                [Page 20] 
                                                                       

COPS-PR for outsourcing in UMTS                           November 2001 
 
 
   -- 
   -- UMTS Event Classes 
   -- 
    
    
   -- 
   -- UMTS PDP Context Event Table 
   -- 
    
   uMTSPdpContextEventTable OBJECT-TYPE 
       SYNTAX         SEQUENCE OF UMTSPdpContextEventEntry 
       PIB-ACCESS     notify  
       STATUS         current 
       DESCRIPTION 
           "" 
       ::= { uMTSEventClasses 1 } 
    
    
   uMTSPdpContextEventEntry OBJECT-TYPE 
       SYNTAX         UMTSPdpContextEventEntry 
       STATUS         current 
       DESCRIPTION 
           "" 
       PIB-INDEX { uMTSPdpContextEventPrid } 
       UNIQUENESS { uMTSPdpContextEventToken }   
       ::= { uMTSPdpContextEventTable 1 } 
 
    
   UMTSPdpContextEventEntry ::= SEQUENCE { 
           uMTSPdpContextEventPrid      InstanceId, 
           uMTSPdpContextEventToken     OctetString, 
           uMTSPdpContextEventFlowIds   Prid 
   } 
    
    
   uMTSPdpContextEventPrid OBJECT-TYPE 
       SYNTAX         InstanceId 
       STATUS         current 
       DESCRIPTION 
           "An arbitrary integer index that uniquely identifies an 
           instance of the uMTSPdpContextEvent class." 
    
       ::= { uMTSPdpContextEventEntry 1 } 
    
    
   uMTSPdpContextEventToken OBJECT-TYPE 
       SYNTAX         OctetString 
       STATUS         current 
       DESCRIPTION 
           "The token associated with this PDP Context event." 
       ::= { uMTSPdpContextEventEntry 2 } 
    
    
Hamer, et al.                                                [Page 21] 
                                                                       

COPS-PR for outsourcing in UMTS                           November 2001 
 
 
   uMTSPdpContextEventFlowIds OBJECT-TYPE 
       SYNTAX         Prid 
       STATUS         current 
       DESCRIPTION 
           "References the FlowIds associated with the Token indicated 
           in this PDP Context event. 
           This is the anchor of a list of uMTSPdpContextFlowIdEntry 
           Instances. 
           A value of zeroDotZero indicates an empty list." 
       DEFVAL  { zeroDotZero } 
       ::= { uMTSPdpContextEventEntry 3 } 
    
    
    
   -- 
   -- UMTS PDP Context FlowID Table 
   -- 
    
   uMTSPdpContextFlowIdTable OBJECT-TYPE 
       SYNTAX         SEQUENCE OF UMTSPdpContextFlowIdEntry 
       PIB-ACCESS     notify  
       STATUS         current 
       DESCRIPTION 
           "" 
       ::= { uMTSEventClasses 2 } 
    
    
   uMTSPdpContextFlowIdEntry OBJECT-TYPE 
       SYNTAX         UMTSPdpContextFlowIdEntry 
       STATUS         current 
       DESCRIPTION 
           "" 
       PIB-INDEX { uMTSPdpContextFlowIdPrid } 
       UNIQUENESS { uMTPdpContextFlowIdX }   
       ::= { uMTSPdpContextFlowIdTable 1 } 
 
    
   UMTSPdpContextFlowIdEntry ::= SEQUENCE { 
           uMTSPdpContextFlowIdPrid  InstanceId, 
           uMTSPdpContextFlowIdId    OctetString, 
           uMTSPdpContextFlowIdNext  Prid 
   } 
    
    
   uMTSPdpContextFlowIdPrid OBJECT-TYPE 
       SYNTAX         InstanceId 
       STATUS         current 
       DESCRIPTION 
           "An arbitrary integer index that uniquely identifies an 
           instance of the uMTSPdpContextFlowId class." 
    
       ::= { uMTSPdpContextFlowIdEntry 1 } 
    
Hamer, et al.                                                [Page 22] 
                                                                       

COPS-PR for outsourcing in UMTS                           November 2001 
 
 
    
   uMTSPdpContextFlowIdId OBJECT-TYPE 
       SYNTAX         OctetString 
       STATUS         current 
       DESCRIPTION 
           "The FlowId itself." 
       ::= { uMTSPdpContextFlowIdEntry 2 } 
    
    
   uMTSPdpContextFlowIdsNext OBJECT-TYPE 
       SYNTAX         Prid
       STATUS         current 
       DESCRIPTION 
           "References the next FlowId in the list associated with the 
           same Token of a PDP Context event. 
           This points to a list of uMTSPdpContextFlowIdEntry 
           Instances. 
           A value of zeroDotZero indicates end of the list." 
       DEFVAL  { zeroDotZero } 
       ::= { uMTSPdpContextFlowIdEntry 3 } 
    
































Hamer, et al.                                                [Page 23] 
                                                                       

COPS-PR for outsourcing in UMTS                           November 2001 
 
 
   -- 
   -- Conformance Section 
   -- 
 
   uMTSCompliances         OBJECT IDENTIFIER ::= { uMTSConformance 1 } 
   uMTSGroups              OBJECT IDENTIFIER ::= { uMTSConformance 2 } 
    
    
    
   END 
    










































Hamer, et al.                                                [Page 24] 
                                                                       

COPS-PR for outsourcing in UMTS                           November 2001 
 
 
9. IANA considerations 
    
   This document follows the same rules as the base COPS protocol 
   [COPS].  
    
    
10. Security Considerations 
    
   It is clear that this PIB is used for configuration using [COPS-PR], 
   and anything that can be configured can be misconfigured, with 
   potentially disastrous effect. At this writing, no security holes 
   have been identified beyond those that the COPS base protocol and 
   COPS-PR protocol security have already addressed. 
    
   The security mechanisms as described in [COPS], provide the 
   necessary protection against security threats. However, even if the 
   network itself is secure, there is no control as to who on the 
   secure network is allowed to 'Install/Notify' 
   (read/change/create/delete) the PRIs in this PIB.   
        
   It is then a customer/user responsibility to ensure that the PEP/PCF  
   giving access to an instance of this PIB, is properly configured to  
   give access to the PRIs only to those principals (users) that have  
   legitimate rights to indeed 'Install' or 'Notify' (change/create/  
   delete) them.  
     
    
    
11. Author Information and Acknowledgments 
    
        Louis-Nicolas Hamer 
        Nortel Networks 
        100 Constellation Cr. 
        Ottawa, Ontario 
        CANADA K2G 6J8 
        Phone: +1 613 768 3409 
        Email: nhamer@nortelnetworks.com 
    
        Kwok Ho Chan 
        Nortel Networks 
        600 Technology Park Drive 
        Billerica, MA 01821 USA 
        Phone: +1 978 288 8175 
        Email: khchan@nortelnetworks.com 
    
        Hamid Mahmood Syed 
        Nortel Networks 
        100 Constellation Cr. 
        Ottawa, Ontario 
        CANADA K2G 6J8 
        Phone: +1 613 763 6553 
        Email: hmsyed@nortelnetworks.com 
    
Hamer, et al.                                                [Page 25] 
                                                                       

COPS-PR for outsourcing in UMTS                           November 2001 
 
 
        Hugh Shieh 
        AT&T Wireless 
        7277 164th Ave NE 
        Redmond, WA 
        Phone: +1 425 580 6898 
        Email: hugh.shieh@attws.com 
    
        Romeo Zwart 
        AT&T  
        Laarderhoogtweg 25 
        1101 EB Amsterdam, NL 
        Email: Romeo.Zwart@ICOE.ATT.COM 
    
    
   We would like to thank the following people for their very useful 
   help in the creation of this concept and document: Celine Bonnel, 
   & Bill Gage (Nortel Networks), Muhammad Jaseemuddin (Ryerson U.),
   Nigel Holland & Alexandre Harmand (BT). 
    
    
12. References 
    
   [COPS]  
        Boyle, J., Cohen, R., Durham, D., Herzog, S., Rajan, R., and 
        A. Sastry, "The COPS (Common Open Policy Service) Protocol" 
        RFC 2748, January 2000. 
    
   [COPS-PR]  
        K. Chan, D. Durham, S. Gai, S. Herzog, K. McCloghrie, 
        F. Reichmeyer, J. Seligson, A. Smith, R. Yavatkar, "COPS Usage  
        for Policy Provisioning," RFC 3084, March, 2001. 
         
   [IETF-SIP]  
        M. Handley, H. Schulzrinne, E. Schooler, and J.Rosenberg, "SIP: 
        session initiation protocol," RFC 2543, Mar. 1999. 
    
   [UMTS-QoS] 
        3GPP TS 23.207: 'End-to-End QoS Concept and Architecture', 
        Release 5,  
        ftp://ftp.3gpp.org/Specs/latest/Rel-5/23_series/23207-510.zip 
    
   [UMTS-Go] 
        3GPP TS 29.207: 'Policy control over Go interface', Release 5, 
        ftp://ftp.3gpp.org/Spec/Latest_drafts/29207-020.zip  
    
   [UMTS-IM] 
        3GPP TS 23.228: 'IP Multimedia (IM) Subsystem - Stage 2', 
        Release 5,  
        ftp://ftp.3gpp.org/Specs/latest/Rel-5/23_series/23228-520.zip 
    
   [UMTS-Arch] 
        3GPP TS 23.002: 'Network Architecture', Release 5, 
        ftp://ftp.3gpp.org/Specs/latest/Rel-5/23_series/23002-540.zip 
Hamer, et al.                                                [Page 26] 
                                                                       

COPS-PR for outsourcing in UMTS                           November 2001 
 
 
    
    
    
   [SPPI]  
        K. McCloghrie, et.al., "Structure of Policy Provisioning 
        Information," RFC 3159, August 2001. 
    
   [RAP-FRAMEWORK]  
        R. Yavatkar, D. Pendarakis, "A Framework for Policy-based  
        Admission Control", RFC 2753, January 2000. 
    
   [Frwrk-PIB] 
        M. Fine, et al., 'Framework Policy Information Base', draft-
        ietf-rap-frameworkpib-06.txt, November 2001, Work in progress. 
    
   [DS-PIB] 
        M. Fine,et al., 'Differentiated Services Quality of Service 
        Policy Information Base', draft-ietf-diffserv-pib-05.txt, 
        November 2001, Work in progress. 
    
   [FEEDBACK] 
        D. Rawlins, et al., 'Framework of COPS-PR Policy Information 
        Base for Policy Usage Feedback', draft-ietf-rap-feedback-fr-
        pib-00.txt, July 2001, Work in progress. 
         
    
    
    
    
13. Full Copyright  
    
   Copyright (C) The Internet Society (2000). All Rights Reserved. This 
   document and translations of it may be copied and furnished to 
   others, and derivative works that comment on or otherwise explain it 
   or assist in its implementation may be prepared, copied, published 
   and distributed, in whole or in part, without restriction of any 
   kind, provided that the above copyright notice and this paragraph 
   are included on all such copies and derivative works. However, this 
   document itself may not be modified in any way, such as by removing 
   the copyright notice or references to the Internet Society or other 
   Internet organizations, except as needed for the purpose of 
   developing Internet standards in which case the procedures for 
   copyrights defined in the Internet Standards process must be 
   followed, or as required to translate it into languages other than 
   English.  
    
   The limited permissions granted above are perpetual and will not be 
   revoked by the Internet Society or its successors or assigns.  
    
   This document and the information contained herein is provided on an 
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 
Hamer, et al.                                                [Page 27] 
                                                                       

COPS-PR for outsourcing in UMTS                           November 2001 
 
 
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.  
    
    
   Table of Contents 
    
   Status of this Memo...............................................1 
   Abstract..........................................................1 
   Disclaimer........................................................1 
   1. Glossary.......................................................2 
   2. Introduction...................................................2 
   2.1 Rationale for using COPS-PR for outsourcing in UMTS...........2 
   3. Definition of terms............................................4 
   4. General UMTS and Go Interface Concepts.........................6 
   4.1. UMTS IP Multimedia Subsystem.................................6 
   4.2. Session authorization framework..............................6 
   4.3. Go Interface.................................................7 
   5. COPS-PR Usage for UMTS Go Interface............................8 
   5.1 General Description...........................................8 
   5.2 UMTS-specific Information in COPS-PR..........................9 
   5.2.1 Common Header, Client Type..................................9 
   5.2.2 Context Object..............................................9 
   5.2.3 Client Specific Information (ClientSI) for outsourcing 
   Operation.........................................................9 
   5.3 General Operations............................................9 
   5.3.1. Reporting of Device Capabilities and Device Limitations....9 
   5.3.2. Initial UMTS Policy Provisioning..........................10 
   5.3.3 COPS-PR Outsourcing Operation..............................10 
   5.3.3.1. UMTS Service Request....................................10 
   5.3.3.2 Outsourced UMTS Decision.................................11 
   5.3.3.3 UMTS Service Usage Reporting.............................11 
   5.3.3.4 UMTS Service Usage Termination...........................11 
   6. Relationship between UMTSÆs COPS-PR Usage and other COPS-PR 
   Usages...........................................................12 
   6.1 Re-use of PRCs from other PIBs...............................12 
   7. Summary of the UMTS PIB.......................................13 
   8. The UMTS PIB module...........................................14 
   9. IANA considerations...........................................25 
   10. Security Considerations......................................25 
   11. Author Information and Acknowledgments.......................25 
   12. References...................................................26 
   13. Full Copyright...............................................27 
    










Hamer, et al.                                                [Page 28]