3GPP TS 29.207 V5.6.0 (2003-12)
`
`Technical Specification
`
`3rd Generation Partnership Project;
`Technical Specification Group Core Network;
`Policy control over Go interface
`(Release 5)
`
`TM
`
`T-MOBILE EXHIBIT 1005
`
`The present document has been l:]e\-'eloped within the 3'“ Generation Partnership I-‘roject (3GPP T“) and may be fiirthcr elahorated for the purposes ol"3(iI-‘P.
`
`The present document has not been subject to 1111)’ approval process by the 3GPP(}rganizalioi1a1 Partners and shall not be inipierneliled.
`This Speciliealioll is prunvided lbr future developuielll work within 3GPPoi1]_v. Tlie Organizational Partners aecepl no liability for any use oflhis Speeificalioii.
`Specifications and reports for implementation of the 3GPP N system should he obtained via the 3GPP 01'ganization:1l Partners‘ Publications ()l‘l'1ces_
`
`

`
`Release 5
`
`2
`
`3GPP TS 29.207 V5.6.0 (2003-12)
`
`Keywords
`UMTS, performance
`
`3GPP
`
`Posatal address
`
`3GPP support oflice address
`650 Route des Lucioles - Sophia Antipolis
`Valbonne - FRANCE
`Tel.: +33 4 92 94 42 00 Fax: +33 4 93 65 4716
`
`Internet
`
`http://www. 3gpp.org
`
`Copyright Notification
`
`No part may he 1'eproduced except as authorized by written permission.
`The copyright and the foregoing restriction extend to reproduction in all media.
`
`2003. 3C1l’P Organizational Pariners (ARIB. C CSA. ]:"I'Sl. 'l'l. 'l"I'A. TIC).
`All rights reserved.
`
`3GPP
`
`

`
`Release 5
`
`3
`
`3GPP TS 29.207 V5.6.0 (2003-12)
`
`Contents
`
`Definitions and
`Definitions ............................................. ..
`Abbreviations ........................................................................................................................................................ .. 8
`
`
`
`Go interface ................................... ..
`Overview ..................... ..
`
`Go reference model ............................................................................................................................................. .. 11
`
`1 2 3
`
`3.1
`3.2
`
`4
`4.1
`4.2
`
`4.3
`4.3.1
`
`11
`Functional elements and
`GGSN ............................................................................................................................................................ .. 11
`
`4.3.1 .1
`4.3.l.l.1
`4.3.1.2
`4.3.1.3
`4.3.1.4
`
`Service-based local policy enforcement point ............................................................................................... .. 11
`Q08 Information processing.........................
`.... .. 12
`
`Initialisation and maintenance ....................................................................................................................... .. 13
`Gate function ................................................................................................................................................. .. 13
`Void 13
`
`Binding nicchanisin handling ........................................................................................................................ .. 13
`PDF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
`. . . . .. 14
`
`Scrvicc—bascd local policy decision point ................................................................................................... .. 14
`Initialisation and maintenance
`........................................................................................... .. 15
`
`Binding nicchanisni handling ........................................................................................................................ .. 15
`
`
`
`. . . . .. 16
`Policy control procedures . . . . . . . . . . . . . . . . . . . . . .
`. . . . .. 16
`. .
`.
`.
`. . .
`GGSN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
`. . . . . . .
`Initial authorization at PDP context activation .............................................................................................. .. 16
`
`Modification of previously authorized PDP context ...................................................................................... .. 16
`Session rnodiiication initialed decision .......................................................................................................... .. 17
`PDP context deactivation ............................................................................................................................... .. 17
`
`. . . . .. 18
`Gate control operation . . . . . . .
`
`User plane operation ...................................................................................................................................... .. 18
`PD]-" ...................................................................................................................................................................... .. 18
`SBLP decisions .............................................................................................................................................. .. 18
`SBLP authorisation decision .......................................................................................................................... .. 18
`Session modification initiated decision . . . . . . . . . .
`.
`. . . . .. 20
`
`SBLP revoke decision .................................................................................................................................... .. 20
`
`SBLP gate decision ........................................................................................................................................ .. 21
`Support for forking ........................................................................................................................................ .. 21
`Authori7ation of 1'eso11rces for forked responses ........................................................................................... .. 21
`Updating the authorization information at the final answer........................................................................... .. 21
`
`Go protocol ........................................................................................................................................... ..22
`Protocol support .................................................................................................................................................. .. 22
`TCP connection for COPS
`.... .. 22
`COPS protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
`. . . . .. 22
`Basic COPS eventsfmessages . . . . .
`. . . . .. 23
`
`Type of messages ........................................................................................................................................... .. 23
`Go eventsfmessages ............................................................................................................................................. .. 23
`1-Event descriptions .......................................................................................................................................... .. 23
`Common Header, Client Type ....................................................................................................................... .. 23
`Context Object . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
`.
`.
`.
`. . . . . .
`.
`. . .
`.
`.
`. .
`.
`. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
`. . . . .. 23
`
`Client Specific Infonnation (Clicntsl) for outsourcing Operation ................................................................ .. 24
`Conformance Section ..................................................................................................................................... .. 24
`
`
`
`Reporting of Device Capabilities and Device Limitations............................................................................. .. 25
`1nitialGo Policy Provisioning ....................................................................................................................... .. 26
`Message description....................................................................................................................................... .. 26
`
`4.3.1.5
`4.3.2
`
`4.3.2.1
`4.3.2.2
`
`4.3.2.3
`
`5
`5.1
`5.1.1
`
`5.1.2
`5.1.3
`5.1.4
`
`5.1.5
`5.1.6
`5.2
`5.2.1
`5.2.1.1
`5.2.1.2
`5.2.1.3
`
`5.2.1.4
`5.2.2
`5.2.2.1
`5.2.2.2
`
`6
`6.1
`6.1.1
`6.1.2
`6.2
`6.2.1
`6.3
`6.3.1
`6.3.1.1
`6.3.1.2
`6.3.1.3
`6.3.1.4
`
`6.3.1.5
`6.3.1.6
`6.3.2
`
`3GPP
`
`

`
`Release 5
`
`4
`
`3GPP TS 29.207 V5.6.0 (2003-12)
`
`6.4
`
`6.5
`
`Go data ................................................................................................................................................................ .. 29
`
`Security Considerations ....................................................................................................................................... .. 29
`
`Annex A:
`
`(Void) .....................................................................................................................................30
`
`Annex B (normative):
`
`SGPP Go PIB ..................................................................................................31
`
`Annex C (normative):
`
`Flow identifiers: Format definition and examples ......................................50
`
`C .1
`
`Format of a flow identifier ................................................................................................................... ..50
`
`1.3.2
`
`Example 1 ............................................................................................................................................. ..50
`
`C.3
`
`Annex D (normative):
`
`Go interface related error code values for the PDP context handling......53
`
`Annex E (informative):
`
`Overview of the 3GPP Go PIB working mode .......................................... ..54
`
`Annex F (informative):
`
`Changehistory
`
`3GP.F'
`
`

`
`Release 5
`
`5
`
`3GPP TS 29.207 V5.6.0 (2003-12)
`
`Foreword
`
`This Technical Specification has been produced by the 3"" Generation Partnership Project (3GPP).
`
`The co11te11ts ol‘ the present document are subject to continuing work within the TSG and may change following fonnal
`TSG approval. Should the TSG modify the contents of the present document, it will be re—released by the TSG with an
`identifying change 01‘ release date and an increase in version number as follows:
`
`Version x.y.;'.
`
`where:
`
`x
`
`the first digit:
`
`1
`
`presented to TSG for information;
`
`2 presented to TSG for approval;
`
`3
`
`or greater indicates TSG approved document under change control.
`
`y
`
`the second digit is incremented for all changes of substance, i.c. technical enhancements, corrections,
`updates, etc.
`
`2
`
`the third digit is incremented when editorial only changes have been incorporated in the document.
`
`3GPP
`
`

`
`Release 5
`
`6
`
`3GPP TS 29.207 V5.6.0 (2003-12)
`
`1
`
`Scope
`
`The present document provides the stage 3 specification of the Go interface. The functional requirements and tl1e
`stage 2 specifications ofthc Go interface are contained in 3GPP TS 23.002 [2] and 3GPP TS 23.207 [3]. The Go
`interface is the interface between the GGSN and the Policy Decision Function (PDF).
`
`The present document defines:
`
`-
`
`—
`
`—
`
`the protocol to be used between PDF and GGSN over the Go interface;
`
`the signalling interactions to be performed between PDF and GGSN over the Go interface;
`
`the infonnation to be exchanged between PD]? and GG SN over the Go interface.
`
`2
`
`References
`
`The following documents contain provisions wl1icl1, through reference in this text, constitute provisions of the present
`document.
`
`0 References are either specific (identified by date of publication andfor edition number or version number) or
`non-specific.
`
`I For a specific reierence, subsequent revisions do not apply.
`
`I For a non-specific reference, the latest version applies. In the case of a reference to a 3GPP document (including
`a GSM document), a non-specific reference implicitly refers to the latest version of that document in .-‘he .S‘(m'?£’
`Referrse as the present‘ docmnent.
`
`fl]
`
`2]
`
`:3]
`
`*4]
`
`'5]
`
`_6j
`
`7|
`
`8]
`
`9|
`
`[ l0|
`
`[1 1]
`
`12]
`
`13]
`
`{ l4]
`
`'15]
`
`[16]
`
`'17]
`
`18!
`
`3GPP TR 21.905: "Vocabulary for 3GPP Specifications".
`
`3GPP TS 23.002: "Network architecture".
`
`3GPP TS 23.207: "End—to—end Quality of Service (QOS) concept and architecture".
`
`3GPP TS 23.228: "IP Multimedia Subsystem (IMS); Stage 2".
`
`Void.
`
`IETI’ RFC 2253: "A Frainework for Policy—based Admission Control".
`
`IETF RFC 2248: "The COPS (Colnrnon Open Policy Service) Protocol".
`
`IETF RFC 3084: "COPS Usage for Policy Provisioning (COPS—PR)".
`
`IIiTF RFC 3159: "Structure of Policy Provisioning Information (SPPI)".
`
`Void.
`
`IETF RFC 3520: "Session Authorization Policy F,lement".
`
`3GPP TS 24.008: "Mobile radio interface Layer 3 specification; Core network protocols; Stage 3".
`
`3GPl’ TS 27.060: "Packet domain; Mobile Station (MS) supporting Packet Switched services".
`
`3(}PP TS 24.229: "IP Multimedia Call Control Protocol based on SIP and SDP; Stage 3".
`
`IETF RFC 3318: "Framework Policy Information Base".
`
`IETI’ R1’C 3289: "Management Information Base for the Differentiated Services Architecture"
`
`IF,TF RFC 2327: "SDP: Session Description Protocol".
`
`3Gl’P TS 29.208: "lrlnd-to—end Quality of Service (Q08) signalling flows".
`
`3 GPF
`
`

`
`Release 5
`
`7
`
`3GPP TS 29.207 V5.6.0 (2003-12)
`
`[19]
`
`[20]
`
`[21]
`
`[22]
`
`IETF RFC 3291: "Textual Conventions for hiternet Network Addresses".
`
`3GPP TS 29.060: "General Packet Radio Service (GPRS): GPRS Tunnelling Protocol (GTP)
`across the Gn and Gp interface".
`
`3GPP TS 32.225: "Telecommunication 1nana gement; Charging management; Charging data
`description for the IP Multimedia Subsystem (1MS)".
`
`IETI’ R1’C 3313: "Private Session Initiatioii Protocol (SIP) Extensions for Media Authorization"
`
`3
`
`Definitions and abbreviations
`
`3.1
`
`Definitions
`
`For the purposes of the present document, the terms and definitions given in 3GPP TR 21.905 [l] and the following
`apply:
`
`Authorization Token: consists of the IMS session identifier and the PDI’ identitier in conformance with R1’C 3520
`
`[1 1]. It is used for authorizing the QoS for the IP flow (s). The UE includes an authorization token as part of the binding
`information in order to obtain QoS authorization for the IMS session. The UF. obtains this authorization token via SIP
`from the P—CSCI-‘ by means of an extension SIP header described in RFC 3313 [22]. The P—C SC I? communicates with
`the PDF in order to obtain a suitable authorization token for the UE.
`
`Binding Information: consists of an authorization token and the flow identif1er(s) of IP tlow(s) carried by a PDP
`context. When receiving an authorization token, the UE includes binding information when activating or modifying a
`PDP context. It is used for authorizing the (308 of the IP flows carried within a PDP context and to verify that the
`grouping ofthe IP flows is correct.
`
`Client Handle: an object in the COPS messages used as a unique number to correlate all the COPS messages with the
`same dialogue. Over the Go interface the Client llandlc is used to correlate COPS messages with respect to the same
`PDP Context. For the exact definition see RFC 2248 [T] and RFC 3084 [8].
`
`Common Open Policy Service (COPS) protocol: is a simple query and response protocol that can be used to
`exchange policy infonnation between a policy server (Policy Decision Point) and its clients (Policy Enforcement
`Points)
`
`Flow identifier: used for the identification of the IT’ flows, described within a media component associated with a SIP
`session. A I’low identifier consists of two parts: 1) the ordinal number of the position of the "n1=" lines in the SDP (RFC
`232? ]l? ]) session description and 2) the ordinal number of the IP flow(s) within the “rn=" line assigned in the order of
`increasing port numbers. lixamplcs are provided in Annex C.
`
`Go Interface: interface between PDF and GGSN [RGPP TS 23.002 [2])
`
`GPRS Charging ID (GCID): the Charging Id generated by the GGSN as defined in 3GPP TS 29.060 [20].
`
`IP Bearer Service Manager: uses standard IP mechanisms to manage the IP Bearer Service. It resides i11 the GGSN
`and optionally in the UE.
`
`[P flow: a unidirectional {low of IP packets with the same source IP address a11d port number and the same destination
`IP address and port number and the same transport protocol. Port numbers are only applicable if used by the transport
`protocoi.
`
`Media component: is a part of a11 SDP session description conveying information about media (eg. media type,
`format, I? address, port(:-1), transport protocol, bandwidth, direction).
`
`The media described by a media component can be either bi- or unidirectional. Media using RTP for transport may also
`have associated RTCP If so, the media component also conveys information about the associated RTCP (port and
`possibly bandwidth}. An SDP session description can consist of moi'e than one media component. A media component
`shall not be deleted nor its position changed within the SDP session description. A media component line where the port
`number has previously been set to 0 may be reused for a new media component.
`
`3 GPP
`
`

`
`Release 5
`
`8
`
`3GPP TS 29.207 V5.6.0 (2003-12)
`
`Policy Decision Function (PDF): is a logical policy decision element that uses standard IP mechanisms to implement
`policy in the II’ media layer
`The PDI’ makes decisions in regard to network based IP policy using policy rules, and communicates these decisions to
`the PEP in the GGSN.
`
`Proxy Call Session Control Function (P—CSC F): is a network element providing session nianagetnent services
`(cg. tciephony call control)
`
`Policy Enforcement Point (PEP): is a logical entity that enforces policy decisions made by the PDF. It resides in the
`H’ BS Manager of the GGSN
`
`Policy Information Base (PIB): is a set of policy data carried by COPS—PR
`The protocol assumes a named data structure, known as a Policy Information Base (PIB), to identify the type and
`purpose of solicited and unsolicited policy information that is sent from the Policy Decision Point to the Policy
`llnforcenienl Point for provisioning policy or sent from the Policy Enforcement Point to the Policy Decision Point as a
`notification.
`
`Provisioning Instance Identifier (PRID): uniquely identifies an instance of a PRC
`
`QoS class: identifies a bearer service (which is associated with a set of bearer service characteristics)
`
`Translationfmapping function: provides the intcr—working between the mechanisms and parameters used within the
`UMTS Bearer Service and those used within the H’ Bearer Service
`
`UMTS Bearer Service Manager: handles resource reservation requests from the UH. It resides in the GGSN and the
`Ulj
`
`3.2
`
`Abbreviations
`
`For the purposes ofthe present document, the abbreviations given in 3GPP TR 21.905 [I] and the following apply:
`
`COPS
`COPS—PR
`DEC
`DRQ
`GCID
`ICID
`IMS
`MIB
`P-CSCI’
`PDI’
`PEP
`PIB
`PRC
`PRI
`PRID
`Q08
`REQ
`RPT
`RTCP
`
`SBLP
`SDP
`
`Common Open Policy Service protocol
`C()PS for policy PRovisioning
`COPS DECision message
`COPS Delete ReQuest state message
`GPRS Charging IDentifier
`IM CN Subsystem Charging IDcntifier
`IP Multimedia core network Subsystem
`Management Information Base
`Proxy Call Session Contlol liunction
`Policy Decision Function
`Policy Enforcement Point
`Policy Information Base
`PRovisioning Class (21 type of policy data)
`PRovisioning Instance (an instance of a PRC)
`PRovisioning Instance iDentifier
`Quality of Service
`COPS RF.Quest message
`COPS RePorT state message
`R'l'P Control Protocol
`
`Service Based Local Policy
`Session Description Protocol
`
`3GPP
`
`

`
`Release 5
`
`9
`
`3GPP TS 29.207 V5.6.0 (2003-12)
`
`4
`
`Go interface
`
`4.1
`
`Overview
`
`The Go interface allows service—based local policy information to be "pushed" to or requested by the Policy
`Enforccinent Point (PEP) in the GGSN from a Policy Decision Function (PDP). As defined in the stage 2 specifications
`3GPP TS 23.207 [3], this information is used by the GGSN for:
`
`- GPRS bearer authorisation;
`
`— Charging correlation;
`
`—
`
`Policy based "gating" function in GGSN;
`
`The Go interface uses IP flow based policies.
`
`The Common Open Policy Service (COPS) protocol has been developed as a protocol for use between a policy server
`and a network device, as described i11 RFC 2748 [7].
`
`In addition, COPS for Provisioning extensions have been developed as described in RFC 3084 |8| with RFC 3159 [9]
`describing a structure for specifying policy information tl1at 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).
`
`The Go interface shall conform to the Ili'I‘l" COPS (RFC 2748 [7]) and the extensions of COPS-PR (RFC 3084 [8]). For
`the purpose of exchanging the required specific Go information, a 3GPP Go COPS—PR Policy Information Base (PII3) is
`defined in the present document.
`
`COPS Usage for Policy Provisioning (COPS—PR) is independent of the type ofpolicy being provisio11ed (Q08, Security,
`ctc.]. In the present document, COPS—PR is used to communicate service—bascd local policy information between PDF
`and GGSN. COPS-PR can be extended to provide per-flow policy control along with a 3GPP Go Policy Information
`Base (PIB). The 3GPP Go PIB may inherit part ofthe data object definitions from other PIBS and MIBS defined in the
`11;’r1'~‘.
`
`Signalling flows related to the Go interface are specilied in 3GPP TS 29.208 [18].
`
`The minimum functionalities that the Go interface shall cover are introduced below.
`
`1. Media Authorisation request from GGSN:
`
`'lhc GGSN receives the binding information during the activation of a (Secondary) PDP context or during the
`modification of an existing PDP context that has been previously authorized by the PDF. To authorise the
`PDP context activation, the GGSN shall send a media authorisation request to the PDF. To authorise the PDP
`context modification, the GGSN shall send a media authorisation request to the PDF when the requested QoS
`exceeds the authorised Q08 or new binding information is received.
`
`This authorisation request shall include the following information:
`
`— Binding information:
`
`The binding information is used by the GGSN to identify the correct PDI’ and subsequently request
`service—bascd local policy information from the PD1’. The GGSN may receive one or more sets ofthe
`binding information during an activation or modification of a PDP context. Each binding information
`consists of:
`
`- One Authorisation token;
`
`- One or more Flow identifiers within the session.
`
`It is assumed that only one set of binding information is carried within a PDP context i11 this Release.
`
`2. Media authorisation decision from PDF:
`
`3GPP
`
`

`
`Release 5
`
`10
`
`3GPP TS 29.207 V5.6.0 (2003-12)
`
`The media authorisation information sent by the PDF to the GGSN, contains at a minimum the following
`information:
`
`— Decision on the binding information.
`
`The PDF shall respond with an authorisation decision for the binding information. The authorisation decision
`shall identify that the binding information is validated with an ongoing SIP session. Additionally, the PDF shall
`verify if the [P flows of the multiple media components are correctly assigned to the PDP Context. If validated,
`the PD]-' shall also eonununieate the following media authorisation details to the GGSN:
`
`-
`
`"Authorised Q08".
`
`This information is used by the GGSN to authorise the media resources according to the service-based
`local policy and the requested bearer Q03.
`
`The "Authorised Q05" signalled over the Go interface is based on the SDP requirements signalled and
`agreed previously within SIT’ Si gnalling for this session.
`
`The "Authorised QoS" specifies the maximum QoS that is authorised for a PDP context for that specific
`binding information. In case of an aggregation ofmultiplc media components within one PDP context, the
`combination of the "Authorised QoS" information of the individual It’ flows of the media components is
`provided as the "Authorised Q08" for the bearer.
`
`The "Authorised QoS" contains the following information:
`
`— QoS class:
`
`The Q08 class information represents the highest class that can be used for the media component. It is
`derived from the SDP media description. The QoS class within the "Authorized Q08" information for
`the heater is determined from the QoS class values of the individual 11’ flows of these media
`conrponents identified in the binding information.
`
`- Data rate:
`
`The Data rate information is derived from the SDP bandwidth parameters. The Data rate shall include
`all the overhead coming from the IP—layer and the layers above, e. g. UDP, RTP or RTCP. If multiple
`eodees are agreed to be used in a session. the authorized data rate is set according to the codec
`requiring the highest bandwidth, meaning that terminals may under use the authorized data rate when
`choosing to use another agreed codec. The Data rate within the "Authorized Q08" information for the
`bearer is detcnnined from the data rate values of the individual IP flows identified iii the binding
`information.
`
`—
`
`Packet Classifier.
`
`The packet classifier for media components is based on the IP-address and port number information in the
`SDP and shall allow for all [P flows associated with the SDP media component description.
`
`3.
`
`Charging correlation:
`
`The PDF shall send the ICD (see SGPP TS 24.229 [l4]) provided by the P—CSCI-‘ as part of the authorisation
`decision. The GGSN shall send the GCID (sec 3GPP TS 29.060 [20]) of the PDP Context and the GGSN address
`to the PDF as part of the authorisation report.
`
`Approval ofQoS Coirunit 3' Removal of QoS Conirnit I Revokc Authorisation for GPRS and 11’ resources:
`
`The PDF controls media components and may revoke resources at any time. Approval of Q08 Commit J
`Removal of QoS Coimnit 2’ Revoke Authorisation for GPRS and IP resources is eormnunieated by the PDF to the
`GGSN.
`
`Indication of PDF Context Release I Modification toffrom 0 kbitfs:
`
`The GGSN informs the PDF of bearer changes related to the authorised resources for the IMS session in the
`following cases:
`
`— Loss of radio contact (modification toffrom 0 kbitfs for conversational and streaming class);
`
`3GPP
`
`

`
`Release 5
`
`11
`
`3GPP TS 29.207 V5.6.0 (2003-12)
`
`- Deactivation of PDP context.
`
`4.2
`
`Go reference model
`
`The Go interface is defined between the PDF and the GGSN (3(}l’l’ TS 23.002 [2]).
`
`The PDF is a logical entity of the P-CSCF (if the PDF is implemented in a separate physical node, the interface between
`the PDF and P-CSCF is not standardised}.
`
`The P—CSCF (PDF) is in the same PLMN as the GG SN.
`
`The relationships between the different functional cntitics involved are depicted in figure 4.2.
`
`
`
`NOTE:
`
`For clarity in the diagram, network elements that are not involved in service-based local policy are not
`presented here (e.g. radio network elements, SGS N, etc).
`
`Figure 4.2: Go interface architecture model
`
`4.3
`
`Functional elements and capabilities
`
`4.3.1
`
`GGSN
`
`4.3.1.1
`
`Service-based local policy enforcement point
`
`The Policy Enforcement Point (PEP) is a logical entity wl1icl1 resides in the GGSN and communicates with the PDI’
`regarding Service-based local policy (SHIP) control. Hereafter in the present document, the GGSN is assumed to
`contain the PEP implicitly unless otherwise stated. The GGSN sends requests to and receives decisions from the PDF.
`The GGSN may cache the policy decision data of the PD!’ decisions. This cached information may be used later for a
`local policy decision allowing the GGSN to make policy control decision about the QoS authorization for PDP context
`modifications without requiring additional interaction with t_he PDF in case the modification request does not exceed the
`previously authorized Q08.
`
`The following policy enforcement point fimctionalities for SBIJ’ in the GGSN are identified:
`
`-
`
`Policy based Authorisation:
`
`The GGSN requests authorisation infonnatioii tioin the PDF for the IP flows carried by a PDP context. The
`GGSN enforces the PDF decisions for this PDP context.
`
`The GGSN shall enforce unsolicited authorisation decisions which update the Q08 and packet classifiers.
`
`3GPP
`
`

`
`Release 5
`
`12
`
`3GPP TS 29.207 V5.6.0 (2003-12)
`
`Additionally, policy-based authorisation ensures that the resources, which can be used by the PDP context
`are within the "Authorised QoS" specified by the PDF. This information is mapped by the
`Translationfiiiappiiig function in tlie GGSN to give the authorised resources for GPRS bearer admission
`control.
`
`The GGSN shall also report to die PDF its success or failure in carrying out the PDF decision.
`
`-
`
`Policy based gating functionality:
`
`Policy based gating functionality represent the control of the GGSN over the Gate Function in the user plane,
`i.e. the forwarding of II’ packets associated with a media component. In the user plane, a "gate" is defined for
`each II’ flow of a media con1po11cnt. The PDF provides the gate description and the commands to open or
`close the gate. The gate description is received from the PDF in the authorisation decision. The command to
`open or close the gate shall be sent either in the authorisation decision or in subsequent decisions from the
`PDI’.
`
`-
`
`Indication of bearer releasehnodification toffrom 0 kbfs:
`
`The GGSN shall inform the PDF when the bearer changes to or from a data rate of 0 kb/s (an indication of
`bearer lossfreeovery), and at bearer release.
`
`— Charging Correlation
`
`To ensure charging correlation, the PEP shall send the GCID and the GGSN address to the PDF. The PDF
`shall also send the IMS charging identifier to the GGSN.
`
`4.3.1.1.1 Q08 information processing
`
`The GGSN is responsible for the policy based authorisation, ie. to ensure that the requested QoS is in-line with the
`"Authorized QoS".
`
`The GGSN needs the "Authorised QoS" information of tlie PDP context for the uplink as well as for the downlink
`direction. Therefore, the "Authorized QoS" information for the combination of all IP flows of each direction associated
`wit.l1 the media component as determined by the PDF is used.
`
`In case of an aggregation of multiple media components within one PDP context, the "Authorised QoS" for the bearer is
`provided by the PDF as the combination of the "Authorised QoS" information of the individual media components.
`
`The GGSN shall perform the proper mapping between the IP Q03 information and the UMTS Q08 information. This
`mapping is performed by the 'I‘ranslationl'rnapping function which maps the "Authorised QoS" information for the PDP
`context into authorised UMTS Q08 information.
`
`It is recommended that the GGSN derives the highest allowed UMTS Traffic class for the PDP context from the QoS
`class in the "Authorized QoS" according to table 4.3.1.1.}.
`
`Table 4-.3.1.1.1
`
`
`
`Q03 class reresents the hihest class that can be used for the bearer.
`
`The QoS class values given by the PDI’ are equal for both the uplink and the downlink directions.
`
`The Data rate within the "Authorized QoS" information for the bearer is the combination of the data rate values of the
`"Authorised QoS" of the individual IP flows of the media components.
`
`In the case of real-time UMTS bearers (conversational and streaming traffic classes), the GGSN shall consider, the Data
`rate value of the "Authorized Q08" information as the maximum value of the ‘Guaranteed bitrate' U MTS QoS
`parameter, whereas the ‘Maximum bitrate' UMTS QoS parameter is limited by the subscriber a11d service specific
`
`3 GPF’
`
`005 class
`UMTS Traffic Class
`Traffic Handling Priority
`
`
`A
`Conversational
`N/A
`:§:
`
`
`
`
`
`21-
`
`lnteractive
`
`
`
`
`NOTE:
`
`
`

`
`Release 5
`
`13
`
`3GPP TS 29.207 V5.6.0 (2003-12)
`
`setting in the HLRIHSS (SGSN) and by the capacityfcapabilitiesfservice configuration ofthe network (GGSN, SGSN).
`In the case of non-real-time bearers (interactive and background traffic classes) the GGSN shall consider, the Data rate
`value of the "Authorized Q08" information as the maximum value of the ‘Maximum bitrate' UMTS Q08 parameter.
`
`The UMTS BS Manager receives the authorised UMTS QoS information for the PDP context from the
`Translation!mapping function. If the requested QoS exceeds the authorised QoS, the U MTS BS Manager shall
`downgrade the requested UMTS QoS information to the authorised UMTS Q03 information.
`
`The GGSN may store the authorized QoS for the binding information of an active PDP co11text i11 order to be able to
`make local decisions, when the UE requests for a PDP context modification.
`
`4.3.1.2
`
`initialisation and maintenance
`
`The GGSN shall comply to the procedures described in RFC 2748 [7] for the i11itialisatio11 and maintenance of the
`COPS protocol over the Go interface.
`
`4.3.1.3
`
`Gate function
`
`The Gate Function represents a user plane fimction enabling or disabling the forwarding of IP packets. A gate is
`described by a set of packet classifiers that identify IP flows associated to th