A.1 GPRS
23.2033GPPPolicy and charging control architectureRelease 17TS
A.1.0 General
The GPRS IP‑CAN employs, for an IP‑CAN session, the concept of PDP contexts in order to provide an information transmission path of defined capacity (QoS). For GPRS, the IP‑CAN bearer is the PDP context.
Figure A.1: The GPRS IP‑CAN
A.1.1 High level requirements
A.1.1.1 General
A.1.1.2 Charging related requirements
It shall be possible for the charging system to select the applicable rate based on:
– SGSN IP address that is used by the GTP control plane for the handling of control messages.
– location with the granularity as specified for the credit re-authorization trigger Location change in clause A.1.3.1.3;
– User CSG Information, including CSG ID, access mode and CSG membership indication;
– RAT type.
A.1.1.3 Policy control requirements
IP‑CAN Bearer QoS control allows the PCC architecture to control the "Authorized QoS" of a PDP context. Criteria such as the QoS subscription information may be used together with service-based, subscription-based, or a predefined PCRF internal policies to derive the "Authorized QoS" of a PDP context.
NOTE: If the PCRF provides authorized QoS for both the IP‑CAN bearer and PCC rule(s), the enforcement of authorized QoS of the individual PCC rules takes place first.
A.1.1.4 QoS control
For GPRS IP‑CANs it shall be possible to apply QoS control at APN-level.
QoS control per APN allows the PCC architecture to control the authorized APN-AMBR to be enforced for the total bandwidth usage of non-GBR QCIs at the PCEF within the same APN.
NOTE: For the enforcement of the APN-AMBR for all IP‑CAN sessions to the same APN, the IP‑CAN is required to select the same PCEF for all of them.
A.1.2 Architecture model and reference points
A.1.2.1 Reference points
A.1.2.1.1 Gx reference point
The Gx reference point enables the signalling of PCC rules, which govern the PCC behaviour, and it supports the following GPRS-specific functions:
– Indication of PDP context activation, modification and deactivation.
A.1.2.2 Reference architecture
In the GPRS IP‑CAN, the Bearer Binding and Event Reporting Function (BBERF) does not apply.
A.1.3 Functional description
A.1.3.1 Overall description
A.1.3.1.1 Binding mechanism
A.1.3.1.1.0 General
As explained in clause 6.1.1, the binding mechanism is performed in three different steps: session binding, PCC rule authorization and bearer binding. Session binding has no GPRS specifics.
For the authorization of a PCC rule with a GBR QCI the PCRF shall assign a GBR value within the limit supported by the serving network.
NOTE: For the authorization of PCC Rules with the same QCI the PCRF may also check that aggregated GBR is within the limits supported by the serving network to minimize the risk of rejection of the bearer by the serving network.
For the GPRS case bearer binding is performed by:
– PCRF, when the selected operation mode is UE-only, see TS 23.060 [12], either due to PCRF decision or network/UE capability;
– PCRF and PCEF (i.e. the PCRF performs the binding of the PCC rules for user controlled services while the PCEF performs the binding of the PCC rules for the network controlled services), when the selected operation mode is UE/NW.
The bearer binding performed by the PCRF shall bind a PCC rule that is authorized for a TFT packet filter to the PDP context the TFT packet filter has been assigned by the UE if the PCC rule can be authorized for the QCI of the PDP context. If a new PDP context is established, the PCRF can also bind PCC rule(s) to the PDP context if the QCI of the PDP context is different from the QCI, the PCC rule(s) can be authorized for since the PCRF can modify the QCI of the new PDP context. The binding mechanism shall comply with the established traffic flow template (TFT) packet filters (for the whole IP‑CAN session).
The bearer binding performed by the PCEF shall compare the PCC rule QoS parameters with the PDP context QoS parameters and bind a PCC rule:
– to a candidate PDP context with a matching QoS class and Evolved ARP (if this is supported by the SGSN);
– to a candidate PDP context with a matching QoS class and Evolved ARP (if this is supported by the SGSN) that, after modification of the bitrates, fulfils the PCC rule QoS demands;
– to a new PDP context with a matching QoS class and Evolved ARP (if this is supported by the SGSN), if there is no suitable candidate PDP context present.
The bearer binding mechanism associates the PCC rule with the PDP context to carry the service data flow. The association shall:
– cause the downlink part of the service data flow to be directed to the PDP context in the association, and
– assume that the UE directs the uplink part of the service data flow to the PDP context in the association.
Thus, the detection of the uplink part of a service data flow shall be active on the PDP context, which the downlink packets of the same service data flow is directed to. The detection of the uplink part of the service data flow may be active, in parallel, on any number of additional PDP contexts.
A.1.3.1.1.1 Bearer binding mechanism allocated to the PCEF
When the bearer binding mechanism is allocated to the PCEF, no per bearer information is required to be communicated over the Gx reference point.
Once the PCRF has provided the PCC rule decisions at the IP‑CAN session establishment procedure, the PCRF shall provide further PCC rule decisions
– using the PCRF initiated IP‑CAN Session Modification procedure; or
– in response to an event report from the PCEF (the GW (PCEF) initiated IP‑CAN Session Modification).
The bearer binding function shall not combine PCC rules with different ARP values onto the same PDP context.
NOTE: If Evolved ARP is not supported by the SGSN then this enables a modification of the PDP context ARP without impacting the bearer binding after relocation to a SGSN that supports Evolved ARP.
A.1.3.1.1.2 Bearer binding mechanism allocated to the PCRF
If a PDP context is established/modified in order to successfully perform the bearer binding the PCRF will set the PCC rule as binding-pending status until the PCEF reports the establishment or modification of a PDP context that fulfils the PCC rule demands or the PCC rule is removed.
The following particularities apply when the bearer binding mechanism is allocated to the PCRF:
– The PCEF
– shall include a bearer reference in all requests for PCC decisions;
– shall report bearer QoS class identifier and the associated bitrates for new/modified PDP contexts;
– shall report the TFT filter status for new PDP contexts and for modified TFTs;
– shall report the deactivation of a PDP context
– The PCRF
– shall provide the bearer reference for the binding result when activating a PCC rule;
– shall arm the GPRS-specific IP‑CAN event trigger "PDP context activity".
– shall arm the event trigger "traffic mapping information change".
NOTE: For the above case, the allocation of the bearer binding mechanism to the PCRF facilitates the migration from Rel-6 products to Rel-7 products. The allocation of the binding mechanism may be re-evaluated in future releases.
When the PCRF performs the bearer binding the ARP information in the PCC rule shall be ignored unless the SGSN has indicated support for Evolved ARP.
A.1.3.1.2 Reporting
A container may be closed and a new container opened by the triggering of event triggers.
A.1.3.1.3 Credit management
For GPRS the PCEF shall initiate one credit management session for each PDP context.
For GPRS the credit re-authorisation triggers in table A.1-1 shall apply in addition to the ones in table 6.1. They are applicable both in case of PCEF and in case of TDF.
Table A.1-1: GPRS specific credit re-authorization triggers
|
Credit re-authorization trigger |
Description |
|
SGSN change |
The UE has moved to a new SGSN. |
|
RAT type change. |
The characteristics of the air interface, communicated as the radio access type, have changed. |
|
Location change (routeing area) |
The routeing area of the UE has changed. |
|
Location change (CGI/SAI) |
The CGI/SAI of the UE has changed. |
|
User CSG Information change in CSG cell |
User CSG Information has changed when the UE enters/leaves/accesses via a CSG cell |
|
User CSG Information change in subscribed hybrid cell |
User CSG Information has changed when the UE enters/leaves/accesses via a hybrid cell in which the subscriber is a CSG member |
|
User CSG Information change in un-subscribed hybrid cell (see note) |
User CSG Information has changed when the UE enters/leaves/accesses via a hybrid cell in which the subscriber is not a CSG member |
|
NOTE: Due to the increased signalling load, such reporting should be applied for a limited number of subscribers only. |
|
If the Location change trigger for CGI / SAI or RAI is armed, the GGSN should request the SGSN to report any changes in location to the level indicated by the trigger according to the procedures described in TS 23.060 [12]. If credit re-authorization triggers and event triggers require different levels of reporting of location change for different PDP contexts for a single IP-CAN session, the SGSN reports location changes to the highest level of detail required. However, the GGSN should not trigger a credit re-authorization if the report received is more detailed than requested by the OCS.
If the User CSG Information change in CSG cell trigger is armed, the GGSN should request the SGSN to report any changes in user CSG information when the UE enters/leaves/accesses via a CSG cell.
If the User CSG Information change in subscribed hybrid cell trigger is armed, the GGSN should request the SGSN to report any changes in user CSG information when the UE enters/leaves/accesses via a hybrid cell in which the subscriber is a CSG member.
If the User CSG Information change in un-subscribed hybrid cell trigger is armed, the GGSN should request the SGSN to report any changes in user CSG information when the UE enters/leaves/accesses via a hybrid cell in which the subscriber is not a CSG member.
If credit re-authorization triggers, event triggers and IP-CAN session related policy information require different levels of reporting of User CSG information for a single IP-CAN session, then the User CSG information to be requested from the SGSN should be changed to the highest level of detail required.
Change of UE presence in Presence Reporting Area is not applicable for GPRS IP-CAN.
A.1.3.1.4 Event Triggers
For GPRS the event triggers in table A.2 shall apply in addition to the ones in table 6.2 at the PCEF upon the request of the PCRF.
NOTE: The request from the PCRF can be triggered by configured policy, or a request received from the TDF. In case of TDF, this may be a result of credit re-authorization trigger received by the TDF from the OCS.
Table A.2: GPRS specific event triggers
|
Event trigger |
Description |
|
SGSN change |
The UE has moved to a new SGSN. |
|
RAT type change. |
The characteristics of the air interface, communicated as the radio access type, have changed. |
|
PDP Context Activity |
The GGSN has received a request for a PDP context activation, modification or deactivation. Note 1. |
|
Location change (routeing area) |
The routeing area of the UE has changed. |
|
Location change (CGI/SAI) |
The CGI/SAI of the UE has changed. |
|
Subscribed APN-AMBR change |
The subscribed APN-AMBR has changed. |
|
User CSG Information change in CSG cell |
User CSG Information has changed when the UE enters/leaves/accesses via a CSG cell. (Note 2) |
|
User CSG Information change in subscribed hybrid cell |
User CSG Information has changed when the UE enters/leaves/accesses via a hybrid cell in which the subscriber is a CSG member. (Note 2) |
|
User CSG Information change in un-subscribed hybrid cell (see note) |
User CSG Information has changed when the UE enters/leaves/accesses via a hybrid cell in which the subscriber is not a CSG member. (Note 2) |
|
3GPP PS Data Off status change |
The PCEF reports when the 3GPP PS Data Off status changes. |
|
NOTE 1: Available only when the bearer binding mechanism is allocated to the PCRF. NOTE 2: Due to the increased signalling load, such reporting should be applied to a limited number of subscribers only. |
|
If the Location change trigger is armed, the GGSN should request the SGSN to report any changes in location to the level indicated by the trigger according to the procedures described in TS 23.060 [12]. If credit-authorization triggers and event triggers require different levels of reporting of location change for different PDP contexts for a single UE, the SGSN reports location changes to the highest level of detail required. However, the GGSN should not trigger a request for PCC rules if the report received is more detailed than requested by the PCRF.
For GPRS, the traffic mapping information is represented by the TFT information.
For GPRS, the loss/recovery of transmission resources is indicated by a PDP context modification changing the ‘Maximum bitrate’ UMTS QoS parameter to/from 0 kbit/s (as described in the PDP context preservation procedure in TS 23.060 [12]).
The User Location Report in the Access Network Information Reporting contains the CGI/SAI and when the PDP context is deactivated, information on when the UE was last known to be in that location.
If the User CSG Information change in CSG cell was provided as event trigger, the GGSN should request the SGSN to report any changes in user CSG information when the UE enters/leaves/accesses via a CSG cell.
If the User CSG Information change in subscribed hybrid cell was provided as event trigger, the GGSN should request the SGSN to report any changes in user CSG information when the UE enters/leaves/accesses via a hybrid cell in which the subscriber is a CSG member.
If the User CSG Information change in un-subscribed hybrid cell was provided as event trigger, the GGSN should request the SGSN to report any changes in user CSG information when the UE enters/leaves/accesses via a hybrid cell in which the subscriber is not a CSG member.
If credit re-authorization triggers, event triggers and IP-CAN session related policy information require different levels of reporting of User CSG information for a single IP-CAN session, then the User CSG information to be requested from the SGSN should be changed to the highest level of detail required.
Change of UE presence in Presence Reporting Area is not applicable for GPRS IP-CAN.
A.1.3.1.5 Policy Control
For GPRS the AF instruction to report changes of the IP‑CAN bearer level information Type of IP‑CAN shall also result in a reporting of RAT type changes, even if the IP‑CAN type is unchanged.
A.1.3.2 Functional entities
A.1.3.2.1 Policy Control and Charging Rules Function (PCRF)
A.1.3.2.1.0 General
The PCRF shall upon indication of PCC rule removal due to PS to CS handover notify the AF that the associated flows are no longer served by the PS-domain due to PS to CS handover.
A.1.3.2.1.1 Input for PCC decisions
The PCRF shall accept any of the following input which the PCEF may provide, specific for GPRS, as a basis for decisions on PCC rule operations.
The following information represents GPRS specific values of the ones listed in clause 6.2.1.1:
– Subscriber Identifier in the form of IMSI, MSISDN;
– A PDN identifier in the form of APN;
– A PLMN identifier in the form of SGSN Mobile Country Code and Mobile Network Code;
– Type of IP‑CAN set to GPRS;
– IP‑CAN bearer attributes in the form of:
– Requested QoS, for a PDP context;
– TFT, to enable the identification of the corresponding PDP Context;
– Location of the subscriber in the form of CGI/SAI or RAI.
The following information is in addition to the ones listed in clause 6.2.1.1:
– RAT type.
– Subscribed APN-AMBR.
The SPR may provide the following information for a subscriber (in addition to the information in clause 6.2.1.1) connecting to a specific PDN:
– Authorized APN-AMBR.
The Authorized APN-AMBR is derived by the PCRF from SPR interaction, according to operator policy.
A.1.3.2.2 Policy and Charging Enforcement Function (PCEF)
A.1.3.2.2.1 General
This functional entity is located in the GGSN. The GGSN provides the GPRS-specific bearer QoS handling.
The PCEF shall contact the PCRF based on PCRF address information that shall be configured for the access point name (APN) together with the IMSI or MSISDN (if needed).
The PCEF shall maintain a 1:1 mapping from the GPRS QoS Class Identifier to a UMTS QoS profile and vice versa. Each GPRS QoS Class Identifier (QCI) parameter value has a 1:1 mapping to a set of QoS parameters defined for GPRS, TS 23.107 [14]. A recommended mapping is listed in table A.3.
Table A.3: Recommended mapping for GPRS QoS Class Identifier to/from Release 99 UMTS QoS parameters
|
GPRS |
UMTS QoS parameters |
|||
|
QoS Class Identifier value |
Traffic Class |
THP |
Signalling Indication |
Source Statistics Descriptor |
|
1 |
Conversational |
n/a |
n/a |
speech |
|
2 |
Conversational |
n/a |
n/a |
unknown |
|
3 |
Streaming |
n/a |
n/a |
speech |
|
4 |
Streaming |
n/a |
n/a |
unknown |
|
5 |
Interactive |
1 |
Yes |
n/a |
|
6 |
Interactive |
1 |
No |
n/a |
|
7 |
Interactive |
2 |
No |
n/a |
|
8 |
Interactive |
3 |
No |
n/a |
|
9 |
Background |
n/a |
n/a |
n/a |
|
NOTE 1: The operator’s configuration should reserve QCI values that map to "speech" for service data flows consisting of speech (and the associated RTCP) only. |
||||
NOTE 2: This table defines the mapping for GPRS QCI to/from UMTS QoS parameters for pre-Release 8 GPRS. The characteristics of GPRS QCIs are independent from the standardized QCI characteristics for EPS.
The PCEF determines Release 97/Release 98 attributes from Release 99 attributes according to TS 23.107 [14].
The remaining UMTS QoS parameters are subject to operator’s policies and either provisioned in the Create PDP Context Request or locally defined in GGSN.
NOTE 3: Any change of the ARP parameter by the PCEF may get overwritten by the SGSN due to subscription enforcement unless the SGSN has indicated support for Evolved ARP.
For each PDP context, the PCEF shall accept information during bearer establishment and modification relating to:
– The user and terminal (e.g. MSISDN, IMEISV);
– Bearer characteristics (e.g. QoS negotiated, APN, IM CN Subsystem signalling flag);
– Network related information (e.g. MCC and MNC).
The PCEF shall use this information in the OCS request/reporting or request for PCC rules.
A GGSN may provide more than one APN for access to the same PDN. It should be possible to enable or disable PCC functionality for each APN, independent from the other APNs for access to the same PDN. Once the PCC functionality is disabled, regular GPRS charging and policy methods would be applied, i.e. no PCRF interaction would occur.
For each PDP context, there shall be a separate OCS request/OFCS reporting, so this allows the OCS and offline charging system to apply different rating depending on the PDP context.
The GGSN shall report the service data flow based charging data on a per PDP context basis.
The GGSN shall be able to request the SGSN to provide reports of changes in CGI/SAI/RAI of a UE as directed by the credit re-authorization triggers and/or event triggers.
The PCEF enforces QoS Policies as indicated by the PCRF in accordance to what is stated in clause 6.2.2.1 with the following additions:
– Authorized APN-AMBR enforcement. The PCEF shall enforce the authorized APN-AMBR received via the Gx interface for the total bandwidth usage of non-GBR QCI for the APN.
Only the GBR per bearer is used for resource reservation (e.g. admission control in the RAN).
The MBR (per PCC rule / per bearer) and the authorized APN-AMBR are used for rate policing.
When the GGSN is connected to a SGSN that does not support the Evolved ARP, the GGSN shall map the Evolved ARP to Rel‑99 ARP parameter value as specified in Annex E of TS 23.401 [17].
A.1.3.2.2.2 Service data flow detection
For uplink traffic, in the case of GPRS, all the uplink parts of service data flows templates, which are associated with the PDP context are candidates for matching in the detection process.
NOTE: Service data flow templates, which are not associated with the PDP context the packet was received, are not candidates for matching (dashed in the figure).
A.1.3.2.2.3 Packet Routeing and Transfer Function
The PCEF performs the packet routeing and transfer functions as specified in TS 23.060 [12], with the differences specified in this clause.
For the PDP address of an UE, the PCEF routes downlink packets to the different PDP contexts based on the downlink parts of the service data flow templates, in the active PCC rules and their routeing associations to the PDP contexts. The association between an active PCC rule and a PDP context shall correspond to the downlink TFT received from the UE. Each active PCC rule shall have a single routeing association to a PDP context. Upon reception of a packet, the PCEF evaluates the downlink part of the service data flow templates of the PCC rules activated for the PDP address in order of precedence to find a match. When the first match is found, the packet is tunnelled to the SGSN via the PDP context, for which the PCC rule has the routeing association. If no match is found, the PCEF shall silently discard the packet.
The UE shall define TFTs that enable successful binding at the PCRF for service data flows requiring a binding to occur.
For each uplink packet, the UE should choose the PDP context that is used for the downlink direction of the same service data flow, as declared in the TFT information. The PCEF shall only apply the uplink parts of the service data flow templates of the PCC rules, which are associated with the same PDP context as the uplink packet arrived on.
The packet filters, to be applied on dedicated signalling PDP contexts, shall form PCC rules, which shall be granted higher precedence than any other PCC rule and be active on the dedicated signalling context.
A.1.3.2.2.4 Measurement
The details of measurement are specified in TS 32.251 [9].
A.1.3.2.3 Application Function (AF)
For GPRS the AF instruction to report changes of the IP‑CAN bearer level information Type of IP‑CAN will also result in a reporting of RAT type changes, even if the IP‑CAN type is unchanged.
The AF instructions to report loss of transmission resources will result in a notification from the PCRF that may include an indication that the transmission resources are lost due to PS to CS handover.
NOTE: The AF action up to notification of termination of transmission resources due to PS to CS handover is application specific. IMS interprets that the PS to CS handover notification as SRVCC.
A.1.3.3 Policy and charging control rule
A.1.3.3.1 General
Void.
A.1.3.3.2 Policy and charging control rule operations
The PCRF associates, at activation, a PCC rule with a PDP context at the PCEF.
A.1.3.4 IP‑CAN bearer and IP‑CAN session related policy information
For GPRS the IP-CAN bearer and IP-CAN session related policy information in table A.4 shall apply in addition to the ones in table 6.4.
Table A.4: PCC related IP-CAN bearer and IP‑CAN session related policy information
|
Attribute |
Description |
PCRF permitted to modify the attribute |
Scope |
|---|---|---|---|
|
User CSG Information change in CSG cell |
Defines whether to report User CSG Information change when the UE enters/leaves/accesses via a CSG cell. |
Yes |
IP‑CAN session |
|
User CSG Information change in subscribed hybrid cell |
Defines whether to report User CSG Information change when the UE enters/leaves/accesses via a hybrid cell in which the subscriber is a CSG member. |
Yes |
IP‑CAN session |
|
User CSG Information change in un-subscribed hybrid cell (see note) |
Defines whether to report User CSG Information change when the UE enters/leaves/accesses via a hybrid cell in which the subscriber is not a CSG member. |
Yes |
IP‑CAN session |
|
NOTE: Due to the increased signalling load, such reporting should be applied for a limited number of subscribers only. |
|||
If the User CSG Information change in CSG cell was provided under IP-CAN session related policy information, the GGSN should request the Serving Node to report any changes in user CSG information when the UE enters/leaves/accesses via a CSG cell.
If the User CSG Information change in subscribed hybrid cell was provided under IP-CAN session related policy information, the GGSN should request the Serving Node to report any changes in user CSG information when the UE enters/leaves/accesses via a hybrid cell in which the subscriber is a CSG member.
If the User CSG Information change in un-subscribed hybrid cell was provided under IP-CAN session related policy information, the GGSN should request the Serving Node to report any changes in user CSG information when the UE enters/leaves/accesses via a hybrid cell in which the subscriber is not a CSG member.
If credit re-authorization triggers, event triggers and IP-CAN session related policy information require different levels of reporting of User CSG information for a single IP-CAN session, then the User CSG information to be requested from the Serving Node should be changed to the highest level of detail required.
The reporting of User CSG information to the OFCS shall be done on the level of detail as requested by the PCRF within IP-CAN session related policy information and the reporting of User CSG information to the OCS shall be done on the level of detail as requested by the OCS re-authorization triggers.
The authorized QoS per bearer (UE-initiated IP‑CAN bearer activation/modification) and the authorized MBR per QCI (network initiated IP‑CAN bearer activation/modification) shall be mapped by the PCEF to the GBR and MBR of the PDP context as described in clause 6.2.2.4. The mapping of the QCI to the UMTS QoS profile parameters is defined in clause A.1.3.2.2.1.
A.1.3.4a TDF session related policy information
For TDF session related policy information in table A.4a shall apply in addition to the ones in table 6.4a.
Table A.4a: TDF session related policy information
|
Attribute |
Description |
PCRF permitted to modify the attribute |
Scope |
|---|---|---|---|
|
User CSG Information change in CSG cell |
Defines whether to report User CSG Information change when the UE enters/leaves/accesses via a CSG cell. |
Yes |
TDF session |
|
User CSG Information change in subscribed hybrid cell |
Defines whether to report User CSG Information change when the UE enters/leaves/accesses via a hybrid cell in which the subscriber is a CSG member. |
Yes |
TDF session |
|
User CSG Information change in un-subscribed hybrid cell (see note) |
Defines whether to report User CSG Information change when the UE enters/leaves/accesses via a hybrid cell in which the subscriber is not a CSG member. |
Yes |
TDF session |
|
NOTE: Due to the increased signalling load, such reporting should be applied for a limited number of subscribers only. |
|||
The reporting of User CSG information to the OFCS shall be done on the level of detail as requested by the PCRF within TDF session related policy information and the reporting of User CSG information to the OCS shall be done on the level of detail as requested by the OCS re-authorization triggers.
NOTE: PCRF is responsible for setting the event triggers to the highest level of detail required in case different levels of User CSG information reporting to the charging domain are required for a single TDF session.
A.1.3.5 Void
A.1.4 PCC Procedures and flows
A.1.4.1 Introduction
For GPRS, the GW (PCEF) is the GGSN. The IP‑CAN bearer is the PDP context and the IP‑CAN Session is established by the Create PDP Context message. The IP‑CAN Session is terminated when the last PDP Context of the specific IP address is deleted and the IP Address is released.
A.1.4.2 IP‑CAN Session Establishment
The IP‑CAN session establishment procedure (described in clause 7.2) is triggered at the GGSN by receiving a Create PDP Context Request message for the first PDP Context that is created for a new IP Address. The successful procedure results in an establishment of a UE IP Address and a PDP Context for the UE. The Create PDP Context Response message, indicating that a new PDP context is created, is sent to the SGSN. The response may include any changes in QoS according to bearer binding and policy enforcement.
During the PDP context activation procedure, it shall be possible to forward the network capability of reporting of changes in CGI/SAI/RAI to the PCRF.
The PCRF also includes the Authorized APN-AMBR in the IP‑CAN Session Establishment Ack.
A.1.4.3 IP‑CAN Session Termination
A.1.4.3.1 UE initiated IP‑CAN Session termination
The UE initiated IP‑CAN Session termination procedure (described in clause 7.3.1) is triggered at the GGSN by receiving a Delete PDP Context request message if this is the deletion of the last PDP Context for the IP Address or the Teardown Indicator in the Delete PDP Context Request indicates that all PDP contexts that share the same IP address should be deactivated. All PDP Contexts in the IP‑CAN Session are deleted in the GGSN. The IP Address of the UE is released. The Delete PDP Context Response message, indicating that the PDP context(s) is deleted, is sent to the SGSN.
A.1.4.3.2 GW initiated IP‑CAN Session termination
The GW initiated IP‑CAN Session termination procedure (described in clause 7.3.2) is triggered if the GGSN detects that the IP‑CAN Session shall be terminated. The Delete PDP Context request message is sent by the GGSN to the SGSN.
This may be the deletion of the last PDP Context for the IP Address. If not, the GGSN shall set the Teardown Indicator in the Delete PDP Context Request message to indicate that all PDP contexts that share that same IP address shall also be deactivated. All PDP Contexts in the IP‑CAN Session are deleted. The IP Address of the UE is released. The Delete PDP Context Response, indicating that the PDP context(s) is deleted, is received from the SGSN.
A.1.4.4 IP‑CAN Session Modification
A.1.4.4.1 IP‑CAN Session Modification; GW (PCEF) initiated
The GW (PCEF) initiated IP‑CAN Session modification procedure (described in clause 7.4.1) is triggered at the GGSN by receiving one of the following messages:
– Create PDP Context Request message;
– Update PDP Context Request message;
– Delete PDP Context Request message;
– a Change Notification message (indicating the new CGI, SAI or RAI) – see TS 23.060 [12].
In case of a Create PDP Context Request message, the modification of the IP‑CAN Session is the addition of a new PDP Context to the IP‑CAN Session. The new PDP Context is added with specific QoS requirements and traffic mapping information (TFT). A Create PDP Context Response message, indicating that a new PDP context is created, is sent to the SGSN. The response may include any changes in QoS according to bearer binding and policy enforcement.
In case of an Update PDP Context Request, a PDP Context in the IP‑CAN Session is modified. The modification may include modifying the QoS and/or the traffic mapping information. The Update PDP Context Response message, indicating that a PDP context is modified, is sent to the SGSN. The response may include any changes in QoS according to bearer binding and policy enforcement.
In case of a Delete PDP Context Request message, a PDP Context in the IP‑CAN Session is deleted. The Delete PDP Context Response message, indicating that a PDP context is deleted, is sent to the SGSN. .If the PS to CS handover indicator is set in a Delete PDP context request message , the PCEF reports termination of transmission resources for associated PCC Rules due to PS to CS handover.
A Change Notification message indicating a change in CGI / SAI or RAI information is received when there are only changes regarding the current location of the UE. A change in CGI / SAI or RAI may also be notified within other session management messages.
The PCRF may provide the Authorized APN-AMBR in the Acknowledgement of the IP‑CAN Session Modification to the GW (in addition to the parameters in clause 7.4.1).
Based on operator policy the PCRF may re-authorize MBR/APN-AMBR.
A.1.4.4.2 IP‑CAN Session Modification; PCRF initiated
The PCRF initiated IP‑CAN Session modification procedure (described in clause 7.4.2) may result in a GGSN initiated PDP Context Modification or Deactivation or a Network Requested secondary PDP Context Activation.
If a PDP Context in the IP‑CAN Session needs to be modified, the GGSN sends an Update PDP Context Request message. The modification may include modifying the QoS negotiated, negotiated Evolved ARP or the required CGI/SAI/RAI change reporting. The Update PDP Context Response message, indicating that a PDP context is modified, will be received from the SGSN.
If a PDP Context in the IP‑CAN Session needs to be deleted, the GGSN sends a Delete PDP Context Request message. The Delete PDP Context Response message will be received from the SGSN.
If the PCEF bearer binding yields that a new PDP context is required, the PCEF shall initiate the Network Requested secondary PDP Context Activation procedure.
NOTE: If online charging is applicable, with PCEF bearer binding and a new PDP Context is required, the PCEF may not have all the information (e.g. NSAPI and negotiated QoS) associated with that PDP context for the credit authorisation until the activation procedure is complete and therefore a second credit authorisation may be necessary to provide the remaining information.
The PCRF may provide the Authorized APN-AMBR in the Policy and Charging Rule Provision to the GW (in addition to the parameters in clause 7.4.2).