15 Operational Aspects

23.0603GPPGeneral Packet Radio Service (GPRS)Release 17Service descriptionStage 2TS

Tools: ARFCN - Frequency Conversion for 5G NR/LTE/UMTS/GSM

15.1 Charging

15.1.0 General

GPRS charging information is collected for each MS by SGSNs, S‑GWs and P‑GWs/GGSNs that are serving the MS. When based on Gn/Gp, the operator can control whether charging information shall be collected in the SGSN and the GGSN on an individual MS and/or PDP context basis by appropriately setting the Subscribed Charging Characteristics and/or PDP context Charging Characteristics in the HLR.

NOTE 1: The charging requirements for the S‑GW, including connectivity through S4, and the P‑GW are as defined in TS 23.401 [89].

The charging characteristics on the subscription and individually subscribed APNs are specified in TS 32.251 [70].

The information that the operator uses to generate a bill to a subscriber is operator-specific. Billing aspects, e.g. a regular fee for a fixed period, are outside the scope of the present document.

Every operator collects and processes his own charging information.

The SGSN, for connectivity through Gn/Gp, collects charging information for each MS related to the radio network usage while the P‑GW/GGSN collect charging information for each MS related to the packet data network usage. All core network nodes also collect charging information on usage of the network resources.

If the SGSN is connected through Gn/Gp with a GGSN/P‑GW, charging may be also realised by a CAMEL server using CAMEL interaction procedures, see referenced procedures in TS 23.078 [8b]. Prepaid charging may also be realised by a CAMEL server, which do not rely on receiving a valid Charging Id, when the SGSN is connected through S4 with a P‑GW.

NOTE 2: A network configuration may ensure that the Charging Id is valid, when the SGSN is connected with a S‑GW through S4 and GTP is in use on S5/S8.

NOTE 3: When using CAMEL for prepaid charging, the GGSN/P‑GW should not be used for the same purpose.

Charging may be also realised by Flow Based Charging procedures at the GGSN, see referenced procedures in TS 23.203 [88] and TS 32.251 [70].

15.1.1 Charging Information

Charging information is collected for the GPRS subscriber.

As a minimum, the SGSN, when connected through Gn/Gp or through S4 for non-E-UTRAN CAMEL enabled subscribers, shall collect the following charging information for MSs and/or individual PDP contexts that are subject to charging:

– usage of the radio interface: the charging information shall describe the amount of data transmitted in Mobile-originated and Mobile-terminated directions categorised with QoS and user protocols;

– usage of the general GPRS resources: the charging information shall describe the usage of other GPRS-related resources and the MS’s network activity (e.g. mobility management); and

– location of MS: HPLMN, VPLMN, plus optional higher-accuracy location information.

When connected through Gn/Gp, the SGSN shall in addition collect the following charging information for MSs and/or individual PDP contexts that are subject to charging:

– usage of the packet data protocol addresses: the charging information shall describe how long the MS has used the packet data protocol addresses.

When CSG is deployed in the network, the SGSN shall also collect the following charging information for MSs and/or individual PDP contexts that are subject to charging:

– User CSG information: CSG ID and access mode of the cell which the MS is accessing, and CSG membership indication of whether the MS is a CSG member in this cell.

The valid CSG information shall be available in the SGSN and GGSN in connected mode.

The PCRF shall, if deployed, provide User CSG Information reporting rules to the GGSN at Attach and PDP context activation procedure. The GGSN sets the CSG Information Reporting Action IE according to the User CSG Information reporting rules and sends it to SGSN.

As a minimum, the GGSN shall collect the following charging information for MSs and/or individual PDP contexts that are subject to charging:

– destination and source: the charging information shall describe the destination and source addresses with a level of accuracy as defined by the GPRS operator;

– usage of the packet data networks: the charging information shall describe the amount of data sent and received to and from the packet data network; and

– usage of the packet data protocol addresses: the charging information shall describe how long the MS has used the PDP addresses.

Additionally, the GGSN may collect the location of an MS: HPLMN, VPLMN, plus optional information i.e. RAI/CGI/SAI and/or CSG information if required for individual MSs.

For inter-operator accounting, in the case of home-routed roaming, the GGSN shall collect and report the uplink and downlink data volume (per PDP context) received from and sent to the serving node.

When the SGSN is connected through Gn/Gp or through S4 for non-E-UTRAN CAMEL enabled subscribers, the RNC and the Iu mode BSC shall collect the following charging information for an MS’s RABs when instructed by the SGSN:

– amount of not transferred downlink data, i.e. data that the RNC/BSC has either discarded or forwarded to an SGSN or to another RNC/BSC. Partially transferred packets shall be handled as not transferred. The collected charging information shall be sent by the RNC/BSC to the SGSN when a RAB is released, or when explicitly requested by the SGSN. The SGSN shall indicate at RAB setup whether data volume collection and reporting for the particular RAB is required or not.

When the SGSN is connected through S4, the S‑GW collects charging information for MSs and/or individual EPS bearers as described in TS 23.401 [89].

15.1.1a General impacts of applying Flow Based Charging

TS 23.203 [88] and TS 32.251 [70] define means for providing online and offline charging with IP flow granularity for GPRS based on functionality in the GGSN. If Flow Based Charging functionality is deployed in an operator’s GPRS network, end-user charging functionalities are provided by the GGSN.

NOTE: When Flow Based Charging is deployed, charging functions in the SGSN and S‑GW are expected to still be used for inter-operator accounting purposes for the scenario where the SGSN or S‑GW (for connectivity through S4) and the GGSN are in different networks. When the SGSN or S‑GW and the GGSN are in the same network and Flow Based Charging is deployed, then the operator may decide to disable the charging functions in the SGSN or S‑GW.

In order to allow for disabling of the charging functions in the SGSN, the SGSN shall be able to include extra information in the signalling messages sent to the GGSN/P‑GW, as follows:

a) in the Create PDP Context Request message, the IMEISV, the RAT type and the S-CDR CAMEL information shall be sent by the SGSN to the GGSN;

b) in the Update PDP Context Request messages sent due to SGSN change, the RAT type shall be sent by the SGSN to the GGSN; and

c) dependent upon the identity of the GGSN’s operator, the SGSN shall send (or omit) the CGI/SAI and User CSG Information in:

i) the Create PDP Context Request message,

ii) the Update PDP Context Request message sent as part of the MS-Initiated PDP Context Modification procedure

iii) the Update PDP Context Request message sent due to SGSN change.

iv) an Change Notification sent when requested to report changes in CGI/SAI and User CSG Information of the MS by the GGSN, see clause 15.1.3.

d) The SGSN shall send a Change Notification as part of the intra-SGSN Routeing Area Update procedures when requested to report changes in Routeing Area by the GGSN, see clause 15.1.3.

In addition:

e) the SGSN shall send an Update PDP Context Request to the GGSN when the Radio Access Technology changes during an intra SGSN routing area update, if the SGSN is not already reporting changes in RAI, SAI, CGI or User CSG Information, as defined in clause 15.1.3 to that GGSN.

The RAT type indicates whether the SGSN serves the UE by GERAN or UTRAN Radio Access Technology.

As an implementation option, the SGSN may include these parameters in other situations that cause the Update PDP Context Request message to be sent.

The above information elements shall be handled by the GGSN in a transparent manner, i.e. the GGSN copies the information elements without modification into the charging information (see TS 32.251 [70]) and/or (if RADIUS accounting is applied in the operator’s network) without modification into the RADIUS accounting messages (see TS 29.061 [27]).

15.1.2 Reverse Charging

It shall be possible to provide reverse charging as a subscription option. However, reverse charging may not be applicable to certain packet data network protocols.

15.1.3 Location and CSG dependent charging

15.1.3.1 Basic principles

The GGSN or P‑GW may request for each PDP context independently using the "MS info change report required" and/or the "CSG information change report required" parameter that the SGSN shall report changes at CGI/SAI/RAI level and/or changes of user CSG information. For GERAN, when SGSN, BSS or MS don’t support PFC procedures, the SGSN shall report a CGI/SAI/RAI change as soon as it is detected.

The P-GW may also request for each PDP context independently using the Presence Reporting Area Action parameter that the S4-SGSN shall report changes when UE enters/leaves a Presence Reporting Area. The Presence Reporting Area Action contains the PRA identifier(s) and optionally list(s) of Presence Reporting Area elements. This may be controlled through the Policy and Charging Control architecture as defined in TS 23.203 [88].

A P‑GW may (over S5) control reporting (any combination of "MS Info Change Reporting Action " and/or "Presence Reporting Area Action " and/or "CSG Information Reporting Action ") at following procedures:

– PDP Context Activation Procedure using S4,

– Routing Area Update (when inducing a Modify Bearer procedure to the PGW),

– Inter RAT Hand-Over to a S4-SGSN (when inducing a Modify Bearer procedure to the PGW),

– Secondary PDP Context Activation Procedure, PDP Creation part, using S4,

– Network Requested Secondary PDP Context Activation Procedure using S4

– Request part of SGSN-Initiated EPS Bearer Modification Procedure using S4

– PDN GW Initiated EPS Bearer Modification Procedure, using S4

– Execution part of MS-Initiated Modification Procedure using S4

The "Presence Reporting Area Action" and "Presence Reporting Area Information" parameters apply to all procedures listed above but within this specification, their usage has only been described in the message flows related with the PDP Context Activation Procedure using S4.

The reporting of entering and leaving a Presence Reporting Area (i.e. the Change of UE presence in Presence Reporting Area reporting procedure) is defined in TS 23.401 [89]. The P‑GW may request to Start/Stop reporting of changes of UE presence for one or more Presence Reporting Area(s) by using the Presence Reporting Area Action parameter. When the S4-SGSN receives the request to start reporting changes of UE presence in a Presence Reporting Area for a PDP context, the S4-SGSN shall report in the response message to the P-GW the Presence Reporting Area Information comprising the PRA identifier(s) and indication(s) on whether the UE is inside or outside the Presence Reporting Area(s). The request to Stop a reporting contains the PRA identifier(s).

The S4-SGSN may be configured with a PRA identifier which refers to a Set of Core Network predefined Presence Reporting Areas. The P-GW may request Start reporting for this Set of Presence Reporting Areas by only indicating this PRA identifier in the Presence Reporting Area Action. When the Presence Reporting Area(s) to be reported belong to a set of Core Network predefined Presence Reporting Areas in which the S4-SGSN is requested to report on change of UE presence, the S4-SGSN shall additionally add to the report the PRA identifier of the Set of Core Network predefined Presence Reporting Areas.

The Online Charging System may provide PRA identifier(s) and additionally for UE-dedicated Presence Reporting Areas the list(s) of the elements comprising each Presence Reporting Area to the P‑GW to subscribe to notifications about changes of UE presence in Presence Reporting Area as defined in TS 23.203 [88].

During both mobility management and session management procedures, the SGSN shall indicate (using the MS Info Change Reporting support indication):

– If CGI/SAI/RAI information is permitted to be sent to the GGSN/P-GW according to SGSN operator’s policy,

– If CSG information is permitted to be sent to the GGSN/P-GW according to SGSN operator’s policy.

The SGSN may be configured to report CGI/SAI/RAI changes only when there is a RAB/PFC established for the UE. Otherwise the SGSN shall report CGI/SAI/RAI changes as soon as detected.

Upon change of serving SGSN, the "MS info change report required" is transferred as part of the PDP Context information. If the level of support changes during a mobility management procedure then the target SGSN shall indicate the current level of support to the GGSN/P-GW and shall in addition provide CGI/SAI, even if the GGSN/P-GW has not requested this information and even if the RAB/PFC is not established. This could for example happen during SGSN change when the level of support indicated by the old SGSN is not the same as in the new SGSN.

NOTE 1: The inclusion of CGI/SAI will trigger a Modify Bearer Request message from S-GW to the P-GW and therefore this will make sure that the new level of support reaches the P-GW.

At change of Serving Node (MME/S4-SGSN), the old Serving Node provides the new serving node with "MS Info Change Reporting Action" as previously requested by the P-GW. The new Serving Node takes the "MS Info Change Reporting Action" immediately into account with the exception that, at mobility between a MME and a S4-SGSN, the new MME (respectively S4-SGSN) does not take into account the "MS Info Change Reporting Action" received from the S4-SGSN (respectively MME) but assumes that no ULI change reporting is requested for the target RAT. At a change of RAT type between EUTRAN and UTRAN or between EUTRAN and GERAN, if ULI change reporting is required in the target RAT, the P-GW shall request "MS Info Change Reporting Action" from the new Serving Node (MME or S4-SGSN). Upon inter-RAT mobility, if the target MME/S4-SGSN supports location information change reporting, the target MME/S4-SGSN shall include the User Location Information in the Create Session Request / Modify Bearer Request, regardless of whether User Location Information change reporting had been requested in the previous RAT by the P-GW.

Upon change of serving S4-SGSN, the PRA identifier(s) and if provided by the P-GW the list(s) of Presence Reporting Area elements are transferred for all PDN connections as part of MM Context information to the target S4-SGSN during the mobility procedure. If one or more Presence Reporting Area(s) was set to inactive, the target serving node may decide to reactivate one or more of the inactive Presence Reporting Area(s). The target S4-SGSN indicates per PDN connection to the corresponding P-GW, the PRA identifier(s) and whether the UE is inside or outside the Presence Reporting Area(s).

NOTE 2: Reporting of changes of UE presence in a Presence Reporting Area is not supported in case of roaming. For GERAN and UTRAN access, homogeneous support of reporting changes of UE presence in a Presence Reporting Area reporting in a network is assumed and there is no intent to distinguish support by S4-SGSN over GERAN versus support over UTRAN. When the PCRF configuration indicates that this reporting is supported for GERAN and UTRAN access, this means it is supported by all the PGW, all S4-SGSN and all the SGW including the S4-SGSN and SGW working in network sharing mode.

NOTE 3: The target S4-SGSN cannot set the Presence Reporting Area(s) received from the serving node to inactive.

The GGSN/P-GW shall not request the SGSN to report CGI/SAI/RAI and/or user CSG information changes if it has not received the indication for corresponding support from the SGSN. In Iu-mode, the SGSN uses the Location Reporting procedures in clause 12.7.5 to request the RNC to report changes in SAI to the SGSN.

The SGSN should report to the GGSN/P-GW per MS in the Change notification message where the report is not combined with other mobility management or session management signalling. The GGSN/P-GW may also request the SGSN to stop reporting CGI/SAI/RAI and/or user CSG information changes. The SGSN obeys the last explicit instruction from the GGSN/P‑GW.

NOTE 4: Due to the increased signalling load, it is recommended that such reporting is only applied for a limited number of subscribers or that the ULI reporting is only performed for changes of UE presence in a Presence Reporting Area.

15.1.3.2 Interaction with CGI / SAI / user CSG information reporting

The following procedures in figures 15.1.3‑1, and 15.1.3‑2 represent the notification of the CGI and SAI changes respectively to the GGSN.

The procedures only apply when the SGSN has been explicitly requested to report CGI or SAI and/or user CSG information changes.

Figure 15.1.3-1: Cell Update triggering a report of change in CGI

Figure 15.1.3-2: Iu-mode Location report triggering a report of change in SAI

Figure 15.1.3-3: User CSG Information Changes triggering a report of change in user CSG information

NOTE: Step 1 is common for architecture variants using Gn/Gp based interaction with GGSN and using S4 based interaction with S‑GW and P‑GW. For an S4 based interaction with S‑GW and P‑GW, procedure steps (A) are defined in clause 15.1.3.2B.

1. In Gb-mode, the SGSN receives a Cell Update indication via the mechanisms described in clause 6.9.1.1.

In Iu-mode, the SGSN receive a location report message (as per the location reporting procedures in clause 12.7.5)

The SGSN detects that the user CSG information has changed by comparing with the SGSN stored user CSG information.

2. If the SGSN has been requested to report the CGI or SAI and/or user CSG information changes to the GGSN for the MS (under the conditions specified in clause 15.1.3.1), the SGSN shall send the change notification to the GGSN indicating the new cell and/or new user CSG information. The SGSN stores the notified user CSG information. If dynamic PCC is deployed, and CGI or SAI changes need to be conveyed to the PCRF, then the GGSN shall send this information to the PCRF as defined in TS 23.203 [88].

15.1.3.2a Interaction with CGI / SAI / user CSG information reporting using S4

The procedures described in figure 15.1.3-4 shows only the steps, due to use of S4, which are different from the Gn/Gp variant of the procedure given by clause 15.1.3.2.

Figure 15.1.3-4: Cell Update triggering a report of change in CGI, Iu-mode Location report triggering a report of change in SAI and User CSG information change triggering a report of change in user CSG information

NOTE: Step 1 is common for architecture variants with GTP based S5/S8 and PMIP‑based S5/S8. For a PMIP‑based S5/S8, procedure step (A1) is defined in TS 23.402 [90]. Step 2 concerns GTP based S5/S8.

1. If the SGSN has been requested to report the CGI or SAI and/or user CSG information changes to the P‑GW (via the S‑GW) for the MS (under the conditions specified in clause 15.1.3.1), the SGSN shall send the change notification to the S‑GW indicating the new cell and/or new user CSG information. The SGSN stores the notified user CSG information.

2. The S‑GW forwards the change notification to the P‑GW. If dynamic PCC is deployed, and CGI or SAI changes need to be conveyed to the PCRF, then the PGW shall send this information to the PCRF as defined in TS 23.203 [88].

15.1.3.3 Reporting of Presence Reporting Area entering and leaving

The following procedure in figure 15.1.3.3-1 represents the notification of a Presence Reporting Area entering and leaving of a UE to the P-GW.

The procedures only apply when the S4-SGSN has been explicitly requested to report changes of UE presence in a Presence Reporting Area.

Figure 15.1.3.3-1: Reporting of Presence Reporting Area entering and leaving

NOTE: Steps 1 and 2 are common for architecture variants with GTP based S5/S8 and PMIP based S5/S8. For a PMIP based S5/S8, procedure step (A) is defined in TS 23.402 [90]. Step 3 concerns GTP based S5/S8.

1a. In Gb-mode, the S4-SGSN receives a Cell Update indication via the mechanisms described in clause 6.9.1.1.

1b. In Iu-mode, the S4-SGSN receives a location report message (as per the location reporting procedures in clause 12.7.5).

2. If the S4-SGSN has been requested to report changes of UE presence in a Presence Reporting Area (under the conditions specified in clause 15.1.3.1) and the S4-SGSN detects that the UE has entered or left a Presence Reporting Area, the S4-SGSN shall send the change notification to the S-GW. No notifications are sent for UE movements inside or outside the Presence Reporting Area. The Presence Reporting Area Information comprising the PRA identifier(s) and indication(s) on whether the UE is inside or outside the area(s) shall be included in this message. If the S4-SGSN decides to reactivate one or more of the inactive Presence Reporting Area(s), the Presence Reporting Area Information also comprises the reactivated PRA identifier(s), and indication(s) on whether the UE is inside or outside the reactivated area(s).

3. The S‑GW forwards the change notification to the P‑GW. If dynamic PCC is deployed, and changes of UE presence in a Presence Reporting Area need to be conveyed to the PCRF, then the P-GW shall send this information to the PCRF as defined in TS 23.203 [88].

15.2 Quality of Service Profile

15.2.0 General

A QoS profile is associated with each PDP context. The QoS profile is considered to be a single parameter with multiple data transfer attributes. The definition of the QoS attributes for Gn/Gp can be found in TS 23.107 [58], which also defines the mapping between the Release 99 QoS attributes and the QoS attributes for GPRS Releases 97 and 98. In addition the Evolved ARP is introduced over Gn/Gp from Release 9. If the network supports the Evolved ARP then this parameter shall be used instead of the Allocation/Retention Priority parameter of the QoS profile during resource allocation/modification towards the RAN. The EPS Bearer QoS parameters are defined in TS 23.203 [88] and the mapping between the EPS Bearer QoS parameters and the Release 99 QoS attributes in TS 23.401 [89].

At any given time, there should be a maximum of one PDP context, for a particular PDP address, that is not associated with a TFT.

During the QoS profile negotiation defined in clause "Activation Procedures", it shall be possible for the MS to request a value for each of the QoS attributes, including the HLR-stored subscribed default values. However if the MS requests the traffic class as ‘subscribed’, the SGSN will assume a request for Interactive class. When the MS requests a QoS, the HLR-stored subscribed default values shall be interpreted as the maximum QoS per PDP context to the associated APN. However the Evolved ARP shall be interpreted as the default value and an SGSN shall accept to receive a Negotiated Evolved ARP from the GGSN even if it is different from the subscribed Evolved ARP received from the HLR. When the application in the MS requires streaming or conversational QoS, then the MS shall at least explicitly request the traffic class and should explicitly request the guaranteed bit rate and the maximum bit rate.

For architecture variants using Gn/Gp based interaction with GGSN, the network shall negotiate each attribute to a level that is in accordance with the available GPRS resources and the known capabilities of the rest of the system. For architecture variants using S4 based interaction with SGW, the network shall not negotiate (either accept or reject) the EPS QoS attributes.

The network shall always attempt to provide adequate resources to support the negotiated QoS profiles.

15.2.1 Radio Priority Levels (A/Gb mode)

The RLC/MAC layer supports four radio priority levels and an additional level for signalling messages as defined in TS 43.064 [11] and TS 44.060 [77]. Upon uplink access the MS can indicate one of the four priority levels, and whether the cause for the uplink access is user data or signalling message transmission. This information is used by the BSS to determine the radio access precedence (i.e. access priority) and the service precedence (i.e. transfer priority under congested situation), see TS 44.060 [77]. The radio priority levels to be used for transmission of Mobile-originated SMS shall be determined by the SGSN and delivered to the MS in the Attach Accept message. The radio priority level to be used for user data transmission shall be determined by the SGSN based on the negotiated QoS profile and shall be delivered to the MS during the PDP Context Activation and PDP Context Modification procedures.

15.2.1a APN-AMBR

APN-AMBR limits the aggregate bit rate that can be expected to be provided across all non GBR PDP Contexts/bearers and across all PDN connections of the same APN (e.g. excess traffic may get discarded by a rate shaping function). GBR PDP Contexts/bearers are outside the scope of APN AMBR. It has an uplink and a downlink component. The GGSN/PDN-GW enforces the APN AMBR. Each APN configuration, stored in the HSS subscription profile may contain a subscribed APN-AMBR value. The subscribed APN-AMBR is signalled from the HSS via SGSN to the GGSN/PDN-GW. If no subscribed APN-AMBR is received from the HSS, the SGSN shall set the APN-AMBR according to implementation specific policies (e.g. a preconfigured maximum APN-AMBR). The SGSN shall set the negotiated APN-AMBR to the value of the APN-AMBR received from the GGSN/PDN-GW.

If the "Higher bitrates than 16 Mbps flag" in the MM Context of the UE is set to "not allowed", the S4-SGSN shall restrict the APN-AMBR in the EPS QoS profile to within 16 Mbps. The SGSN does not inform the PDN-GW if it applies a MBR restriction of 16 Mbps for non-GBR PDP Contexts/bearers to the UE.

The APN-AMBR is a parameter of PDP Context/PDN Connection information and is transferred over the Gn/Gp, S10 or S3 interface.

15.2.2 UE-AMBR

The UE-AMBR denote bit rates of traffic per group of bearers and as such the UE-AMBR is considered outside the scope of the Quality of Service profile. It has an uplink and a downlink component. The UE-AMBR is limited by a subscription parameter stored in the HSS. The SGSN shall set the UE-AMBR to the sum of the APN-AMBR of all active APNs, up to the value of the subscribed UE-AMBR. If no values of UE-AMBR are received from the HSS, the SGSN shall set the UE-AMBR according to implementation specific policies (e.g. a preconfigured maximum UE-AMBR). The UE-AMBR limits the aggregate bit rate that can be expected to be provided across all Non-GBR PDP contexts of a UE (e.g. excess traffic may get discarded by a rate shaping function). Each of those Non-GBR PDP contexts could potentially utilize the entire UE-AMBR, e.g. when the other Non-GBR PDP contexts do not carry any traffic. GBR (real-time) PDP contexts are outside the scope of UE-AMBR. The RAN enforces the UE-AMBR in uplink and downlink.

The operation of UE-AMBR in A/Gb mode is described in clause 12.6.3.5 and in Iu mode is described in clause 12.7.4.

The UE-AMBR is a parameter of MM Context information and is transferred over the Gn/Gp, S10 or S3 interface.

15.2.3 Support of rate control of user data using CIoT optimisation

15.2.3.1 General

The rate of user data sent to and from an MS can be controlled by:

– APN Rate Control. APN Rate Control is intended to allow HPLMN operators to offer customer services such as "maximum of Y messages per day". Existing AMBR mechanisms are not suitable for such a service since, for radio efficiency and MS battery life reasons, an AMBR of e.g. > 100kbit/s is desirable and such an AMBR translates to potentially large daily data volume.

15.2.3.2 APN Rate Control

The GGSN/PDN GW/SCEF can send an APN Uplink Rate Control command to the MS using the PCO information element. The APN Uplink Rate Control applies to data PDUs sent on that APN.

The rate control information is separate for uplink and downlink and in the form of a positive integer number of packets per time unit and an indication as to whether or not exception reports can still be sent if this rate control limit has been met.

The MS shall comply with this uplink rate control instruction. The MS shall consider this rate control instruction as valid until it receives a new one from either GGSN, PDN GW or from SCEF. The GGSN, PDN GW or SCEF may enforce the Uplink Rate Control by discarding or delaying packets that exceed the rate that is indicated to the MS. The GGSN, PDN GW or SCEF should enforce the Downlink Rate Control by discarding or delaying packets.

NOTE: If used, it is assumed that the APN Rate Control rate limit has been set taking the number of simultaneous PDN connections allowed by the subscription into account.

15.3 Traffic Flow Template

15.3.0 General

A TFT consists of one or more packet filters, each identified by a unique packet filter identifier. The maximum number of packet filters is specified in TS 24.008 [13]. A packet filter also has an evaluation precedence index that is unique among all packet filters that are associated with the PDP contexts that share the same PDP address and APN. This evaluation precedence index is in the range of 255 (lowest evaluation precedence) down to 0 (highest evaluation precedence). The MS manages packet filter identifiers and their evaluation precedence indexes, and creates the packet filter contents for those packet filters that are created by the MS. In ‘MS/NW’ mode, the GGSN/P‑GW manages packet filter identifiers and their evaluation precedence indexes for those packet filters that are created by the network. A packet filter has a direction attribute, which indicates the direction of the traffic flow(s), i.e. whether they are uplink, downlink or bi-directional. A packet filter from the MS where the direction attribute is not provided describes desired downlink traffic mapping and the network shall interpret such filter as valid for both directions. For services having no downlink IP flows, the MS shall provide packet filters for uplink IP flows to enable policy control functionality as described in TS 23.203 [88].

NOTE 1: Packet filter direction was introduced together with the support for Network Requested Secondary PDP Context Activation procedure.

The state for the TFT and packet filter settings amongst all the PDP Contexts associated with one PDP address/prefix and APN pair is valid if all of the following conditions are fulfilled:

1) there is at most one PDP Context with no associated TFT; and

2) for ‘MS/NW’ mode or when the MS uses the direction attribute in ‘MS_only’ mode, the PDP Context established with the Secondary PDP Context Activation Procedure always has an associated TFT with at least one packet filter for the uplink direction.

NOTE 2: The above conditions for the valid TFT and packet filter setting is intended for use with bearers in all types of 3GPP accesses.

NOTE 3: A TFT that does not have any packet filter for the uplink direction is not considered valid (except for the PDP context established with the PDP Context Activation Procedure). By not considering the TFT valid a non-backward compatible change is introduced, but it would otherwise introduce unnecessary complexity to the system and it would still remain ambiguous whether such a TFT would be considered as allowing or not allowing uplink flows from an MS perspective, e.g. if the MS sends uplink packets on such PDP context the network might drop such packets due to lack of of PCC rules with matching filters.

The MS shall ensure that for each TFT which includes packet filters under MS control, condition 2 is fulfilled for the packet filters under MS control.

The network shall, after conducting any action necessary to recover from a detected TFT status misalignment between the MS and the network, reject any request from the MS that would violate any of these conditions.

NOTE 4: The network action to recover from a detected TFT status misalignment sometimes include deactivating outdated bearer information remaining after MS and network getting out of synchronization.

The network shall ensure that for each TFT which includes packet filters under network control, condition 2 is fulfilled for the packet filters under network control. If the network wants to add a packet filter to the TFT of a PDP context established with the Secondary PDP Context Activation Procedure or to initiate a Network Requested Secondary PDP Context Activation Procedure, and the resulting TFT will not include any uplink packet filter among the packet filters under network control, then the GGSN/P-GW shall add a packet filter that effectively disallows any useful packet flows in uplink direction (see clause 15.3.3.4 for an example of such a packet filter).

NOTE 5: Ensuring that the own packet filters alone fulfils the conditions ensures that the TFT setting for the PDP Contexts associated with one PDP address/prefix and APN pair remains valid while allowing the MS and the network manipulating their own packet filters independently.

NOTE 6: For the PDP context established with the PDP Context Activation Procedure a packet filter for the uplink direction is not required for the TFT to maintain a valid state for the TFT settings. If a packet filter which effectively disallows any useful packet flows in uplink direction is added by the GGSN/P-GW as the only uplink packet filter, due to operator configuration, the PDP context would be usable only for the transfer of downlink traffic.

The MS may associate a TFT with a PDP context in the Secondary PDP Context Activation procedure or the MS-Initiated PDP Context Modification procedure. The network associates a TFT with a PDP context in the Network Requested Secondary PDP Context Activation Procedure or the GGSN-Initiated PDP Context Modification procedure (if in ‘MS/NW’ mode). A PDP context can never have more than one associated TFT.

In ‘MS_only’ mode the MS may modify any TFT through the MS-Initiated PDP Context Modification procedure.

In ‘MS/NW’ mode the GGSN and the MS may modify any TFT through the PDP Context Modification Procedure in accordance with the restrictions described in clause 9.2.0.

A TFT associated with a PDP context is always deleted at PDP context deactivation.

The UE may use the TFT to associate the Network Requested Secondary PDP Context Activation Procedure and the GGSN-Initiated PDP Context Modification Procedure to an application and to traffic flow aggregates of the application. Therefore the GGSN shall (in the Network Requested Secondary PDP Context Activation Procedure and the GGSN-Initiated PDP Context Modification Procedure) and the P‑GW shall (in the Create Dedicated Bearer Request and the Update Bearer Request messages) provide all available traffic flow description information applicable for the same EPS Bearer/PDP context (e.g. source and destination IP address and port numbers and the protocol information).

15.3.1 Rules for Operations on TFTs

The MS and GGSN shall use the TFT and packet filter identifiers in each operation for handling of the TFTs and packet filters in accordance with the restrictions described in clause 9.2.0.

When the MS or GGSN creates a new TFT, or modifies an existing TFT, it has to include at least one valid packet filter. If no valid packet filter is included in the newly created or modified TFT, the procedure used for the creation or modification of the TFT shall fail, and an error code shall be returned to the MS or GGSN respectively.

During the modification of a TFT, one or more existing packet filters can be modified or deleted, or a new packet filter can be created. In order to modify an existing packet filter, the new values for the packet filter attributes along with the packet filter identifier is sent from the MS to the GGSN, or from the GGSN to the MS. The MS may also modify the evaluation precedence index only of one or several packet filters by means of the MS-Initiated PDP Context Modification procedure. The GGSN may also modify the evaluation precedence index only of one or several packet filters by means of the GGSN-Initiated PDP Context Modification procedure.

A TFT is deleted when the associated PDP context is deactivated. For bearer control mode ‘MS_only’, a TFT can also be deleted by means of the MS-Initiated PDP Context Modification procedure. At any time there may exist only one PDP context with no associated TFT amongst all the PDP contexts associated with one PDP address. An attempt by the MS to delete a TFT, which would violate this rule, shall be rejected by the GGSN.

15.3.2 Packet Filter Attributes

15.3.2.0 General

Each valid downlink- and uplink-packet filter contains a unique identifier within a given TFT, an evaluation precedence index that is unique among all packet filters for one PDP address and APN pair, and at least one of the following attributes:

– Remote Address and Subnet Mask.

– Protocol Number (IPv4) / Next Header (IPv6).

– Local Address and Mask.

– Local Port Range.

– Remote Port Range.

– IPSec Security Parameter Index (SPI).

– Type of Service (TOS) (IPv4) / Traffic class (IPv6) and Mask.

– Flow Label (IPv6).

In the list of attributes above ‘Remote’ refers to the external network entity, and ‘Local’ to the MS.

Some of the above-listed attributes may coexist in a packet filter while others mutually exclude each other. In table 12 below, the possible combinations are shown. Only those attributes marked with an "X" may be specified for a single packet filter. All marked attributes may be specified, but at least one shall be specified.

If the parameters of the header of a received PDP PDU match all specified attribute values in a packet filter, then it is considered that a match is found for this packet filter. In this case, the evaluation procedure is aborted. Other packet filters in increasing order of their evaluation precedence index are evaluated until such match is found.

There may be potential conflicts if attribute values are combined in such a way that the defined filter can never achieve a match to a valid IP packet header. However, the determination of such conflicts is outside the scope of GPRS standardization.

Table 12: Valid Packet Filter Attribute Combinations

	Valid combination types
Packet filter attribute	I	II	III
Remote Address and Subnet Mask	X	X	X
Protocol Number (IPv4) / Next Header (IPv6)	X	X
Local Address and Mask	X	X	X
Local Port Range	X
Remote Port Range	X
IPSec SPI		X
TOS (IPv4) / Traffic Class (IPv6) and Mask	X	X	X
Flow Label (IPv6)			X

15.3.2.1 Remote Address and Subnet Mask

The Remote Address and Subnet Mask attribute of a valid packet filter shall contain an IPv4 or IPv6 address along with a subnet mask.

As an example, the remote address and subnet mask attribute to classify packets coming from all hosts within the IPv4 domain A.B.C.0/24 is {A.B.C.0 [255.255.255.0]}.

15.3.2.2 Protocol Number / Next Header

The Protocol Number / Next Header attribute of a valid packet filter shall contain either an IPv4 Protocol Number or an IPv6 Next Header value. The value range is from 0 to 255.

15.3.2.2A Local Address and Mask

The Local Address and Mask attribute of a valid packet filter shall contain an IP address along with a mask.

The Local Address and Mask attribute is optional for both the MS and the network and can be used in case both the MS and network has declared support for the extended TFT filter format in the Protocol Configuration Options.

NOTE: For IPv4, there is only one local address associated with the bearer. Therefore an IPv4 local address in the TFT filter would be redundant.

15.3.2.3 Port Numbers

The Local Port Range and Remote Port Range attributes of a valid packet filter shall each contain one port number, or a range of port numbers. Port numbers range between 0 and 65 535.

15.3.2.4 IPSec Security Parameter Index

The IPSec SPI attribute of a valid packet filter shall contain one SPI which is a 32‑bit field.

15.3.2.5 Type of Service / Traffic Class and Mask

The Type of Service / Traffic Class and Mask attribute of a valid packet filter shall contain either an IPv4 TOS octet or an IPv6 Traffic Class octet along with a mask defining which of the 8 bits should be used for matching.

15.3.2.6 Flow Label

The Flow Label attribute of a valid packet filter shall contain an IPv6 flow label, which is a 20‑bit field.

15.3.3 Example Usage of Packet Filters

15.3.3.0 General

Based on the type of traffic or the packet data network QoS capabilities, different types of packet filters can be used to classify a given PDP PDU in order to determine the right PDP context. Some examples are given below.

15.3.3.1 IPv4 Multi-field Classification

For multi-field classification, the packet filter consists of a number of packet header fields. For example, to classify TCP/IPv4 packets originating from 172.168.8.0/24 destined to port 5 003 at the TE, the following packet filter can be used:

– Packet Filter Identifier = 1;

– IPv4 Source Address = {172.168.8.0 [255.255.255.0]};

– Protocol Number for TCP = 6; and

– Destination Port = 5 003.

15.3.3.2 IPv4 TOS-based Classification

For TOS-based classification, the packet filter consists of only the TOS octet coding. For example to classify IPv4 packets marked with TOS coding 001010xx, the following packet filter can be used:

– Packet Filter Identifier = 3;

– Type of Service / Traffic Class = 00101000 and Mask = 11111100.

NOTE: The TOS-based classification can always be augmented with the source address attribute if it is known that different source domains use different TOS octet codings for the same traffic class.

15.3.3.3 IPv4 Multi-field Classification for IPSec Traffic

For multi-field classification of IPSec traffic, the packet filter contains the SPI instead of the port numbers that are not available due to encryption. If IPSec (ESP) was used with an SPI of 0x0F80F000, then the following packet filter can be used:

– Packet Filter Identifier = 4;

– Protocol Number for ESP = 50; and

– SPI = 0x0F80F000.

15.3.3.4 Services with IP flows in only one direction

For services with no uplink IP flows, a dummy uplink packet filter can be provided by the network to avoid that the UE uses the PDP context for uplink traffic that is expected on the PDP context without any uplink packet filter. For example that can be done by assigning the remote port "9", which is the "discard" port, i.e. the following packet filter can be used:

– Packet Filter Identifier = 5;

– Packet Filter Direction = uplink only; and

– Remote port = 9 (the discard port).

15.4 APN Restriction

The support for APN Restriction and Maximum APN Restriction at the SGSN is optional and an APN Restriction value may be configured for each APN in the GGSN or PGW. The support for reception, storage, and transfer of APN Restriction is required for an S4-SGSN. It is used to determine, on a per MS basis, whether it is allowed to establish PDP Contexts or EPS bearers to other APNs.

Table 13: Valid Combinations of APN Restriction

Maximum APN Restriction Value	Type of APN	Application Example	APN Restriction Value allowed to be established
0	No Existing Contexts or Restriction		All
1	Public-1	WAP or MMS	1, 2, 3
2	Public-2	Internet or PSPDN	1, 2
3	Private-1	Corporate (e.g. who use MMS)	1
4	Private-2	Corporate (e.g. who do not use MMS)	None

During the PDP Context Activation procedure or the default bearer activation (for connectivity through S4), the GGSN or PGW may compare the APN Restriction of the PDP Context being set up with the Maximum APN Restriction received from the SGSN to decide whether this activation is accepted. The Maximum APN Restriction is the most restrictive value of the APN Restriction (highest number) from all already active PDP Contexts. The APN Restriction is transferred at PDP Context activation to the SGSN.

The APN Restriction for each PDP context, if available, shall be transferred either from the GGSN or PGW to the new SGSN during inter-SGSN changes (e.g. SRNS Relocation and Routeing Area Update) or from the old SGSN in case both SGSNs use S16 for connectivity. The new SGSN determines the maximum APN Restriction using the APN Restriction contained in the Update PDP Context Response message(s) received from the GGSN(s) or PGW(s).

During the PDP Context Modification procedure (via the APN Restriction received from the GGSN or PGW) and inter-SGSN changes, the SGSN shall verify if there are PDP contexts to different APNs that violate valid combinations based on the APN Restriction. If a violation is detected, the SGSN shall release PDP contexts until a valid combination results and shall send appropriate error causes to the MS. Which PDP contexts are released is network operator configurable and the SGSN may perform one of the following actions, using the SGSN-Initiated PDP Context Deactivation procedures in clause 9.2.4.2, until a valid combination remains or no further actions are possible:

1. Deactivate the most restrictive, as dictated by the APN Restriction value, PDP Context sending an appropriate error cause to the MS,

2. Deactivate the least restrictive, as dictated by the APN Restriction value, PDP Context sending an appropriate error cause to the MS,

3. Deactivate PDP Contexts in no particular order sending an appropriate error cause to the MS.

During PDP Context Activation procedure or default bearer activation (for connectivity through S4) for emergency, GGSN or PGW shall ignore APN Restriction. During PDP Context Modification procedure (via the APN Restriction received from the GGSN or PGW) and inter SGSN changes, the SGSN shall not deactivate bearer(s) with emergency ARP, if any, to maintain valid APN combination. Same restriction also applies to procedures in TS 23.401 [89].

15.5 Automatic Device Detection

The Automatic Device Detection (ADD) function is an optional feature that allows the network to be updated with the current User Equipment identity (IMEISV). This, for example, enables the network to configure the subscriber’s equipment. A device management system can retrieve the IMEISV either from SGSN or from HLR, or be triggered by a changed IMEISV in either SGSN or HLR. However, the device management system and the mechanism to send the configuration to the terminal are outside the scope of 3GPP specifications.

When the ADD function is supported, the SGSN obtains and stores the IMEISV from the MS at GPRS Attach and at Inter-SGSN Routing Area Update procedures when the old SGSN does not provide the IMEISV. The SGSN uses either the GMM Identification procedure or the GMM Authentication and Ciphering procedure to obtain the IMEISV (TS 24.008 [13]). Equipment checking is independent from IMEISV retrieval for ADD. If the IMSI was not previously registered in the SGSN, the SGSN includes the IMEISV in the Update Location message to the HLR. If the IMSI was already registered, the SGSN compares the IMEISV retrieved from the UE with the one stored in SGSN MM context and sends the IMEISV in the Update Location to the HLR if these are different. The MAP parameter Skip Subscriber Data Update should be included in this case to avoid unnecessary signalling, i.e. Cancel Location and Insert Subscriber Data unnecessarily being sent to SGSN.

For the purposes of ADD the IMEISV is transferred on the Gs interface as part of the combined GPRS/IMSI attach procedure.

For further information on the Automatic Device Detection function, please refer to TS 22.101 [82] and TS 23.012 [81].

15.6 Direct Tunnel Functionality

Direct Tunnel is an optional function in Iu mode that allows the SGSN to establish a direct user plane tunnel between RAN and GGSN (for connectivity with GGSN through Gn/Gp) or S‑GW (for connectivity through S4) within the PS domain.

A Direct Tunnel capable SGSN shall have the capability to be configured on a per RNC and per GGSN or S‑GW basis whether or not it can use a direct user plane connection.

The SGSN handles the control plane signalling and makes the decision when to establish Direct Tunnel. When the RAB assigned for a PDP context is released (i.e. the PDP context is preserved) the GTP-U tunnel is established between the GGSN (for connectivity with GGSN through Gn/Gp) and SGSN in order to be able to handle the downlink packets.

Figure 15.6-1: IDLE mode handling for Gn/Gp connectivity

Figure 15.6-1: IDLE mode handling for S4 connectivity

Direct Tunnel shall not be used in following traffic cases:

1) In roaming case for connectivity with GGSN through Gn/Gp only

– The SGSN needs to know whether the GGSN is in the same or different PLMN.

2) If the SGSN is connected with a GGSN through Gn/Gp and the SGSN has received CAMEL Subscription Information in the subscriber profile from the HLR.

– If Direct Tunnel is established then volume reporting from SGSN is not possible as the SGSN no longer has visibility of the User Plane. Since a CAMEL server can invoke volume reporting at anytime during the life time of a PDP Context, the use of Direct Tunnel shall be prohibited for a subscriber whose profile contains CAMEL Subscription Information.

3) GGSN does not support GTP protocol version 1.

15.7 HPLMN Notification with specific indication due to SGSN initiated Bearer removal

When initiating a Delete PDP context procedure, the SGSN shall add an appropriate cause code facilitating the operator of the GGSN/P-GW to take appropriate action (e.g. Alarm, O&M action by operator’s management network) if needed.

NOTE: This is for the HPLMN operator to be able to differentiate Delete PDP context procedures due to a failure case (e.g. due to a QoS parameter mismatch at Initial Attach) from Delete PDP context procedures that are executed in cases not related to any failure conditions (e.g. due to a Routing Area Update). Action taken by the HPLMN operator is outside the scope of 3GPP specification.