Tech-invite  3GPPspace  IETFspace
21  22  23  24  25  26  27  28  29  31  32  33  34  35  36  37  38  4‑5x

Content for  TS 23.060  Word version:  18.0.0

Top   Top   Up   Prev   Next
1…   5…   5.3.8…   5.4…   5.4.2…   5.4.9…   5.6…   5.6.2   5.6.3…   5.6.3.7…   5.7…   6…   6.3…   6.5…   6.6…   6.8…   6.9…   6.9.1.3   6.9.2…   6.9.2.2…   6.9.2.2.2   6.9.2.2.3…   6.9.2.2.5…   6.9.3…   6.10…   6.12…   6.13…   6.13.1.2…   6.13.2…   6.13.2.2   6.14…   8…   8.2   9…   9.2.2…   9.2.2.2   9.2.2.3…   9.2.3…   9.2.3.2…   9.2.3.3…   9.2.4…   9.2.4.2…   9.2.5…   12…   12.5…   12.6…   12.7…   12.8…   13…   14…   15…   15.3…   16…   16.2…   A…   B… 
15 Operational Aspects  15.1 Charging  15.1.0 General  15.1.1 Charging Information  15.1.1a General impacts of applying Flow Based Charging  15.1.2 Reverse Charging  15.1.3 Location and CSG dependent charging  15.2 Quality of Service Profile  15.2.0 General  15.2.1 Radio Priority Levels (A/Gb mode)  15.2.1a APN-AMBR  15.2.2 UE-AMBR  15.2.3 Support of rate control of user data using CIoT optimisation 
...

 

15  Operational Aspects  p. 323

15.1  Charging  p. 323

15.1.0  General |R8|  p. 323

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.
The charging characteristics on the subscription and individually subscribed APNs are specified in TS 32.251.
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. 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.
Charging may be also realised by Flow Based Charging procedures at the GGSN, see referenced procedures in TS 23.203 and TS 32.251.
Up

15.1.1  Charging Information  p. 323

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.
Up

15.1.1a  General impacts of applying Flow Based Charging |R6|  p. 324

TS 23.203 and TS 32.251 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.
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:
  1. the Create PDP Context Request message,
  2. the Update PDP Context Request message sent as part of the MS-Initiated PDP Context Modification procedure
  3. the Update PDP Context Request message sent due to SGSN change.
  4. 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) and/or (if RADIUS accounting is applied in the operator's network) without modification into the RADIUS accounting messages (see TS 29.061).
Up

15.1.2  Reverse Charging  p. 325

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 |R7|  p. 325

15.1.3.1  Basic principles  p. 325

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.
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. 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.
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.
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).
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.
Up

15.1.3.2  Interaction with CGI / SAI / user CSG information reporting  p. 327

The following procedures in Figure 15.1.3-1, and Figure 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.
Reproduction of 3GPP TS 23.060, Fig. 15.1.3-1: Cell Update triggering a report of change in CGI
Figure 15.1.3-1: Cell Update triggering a report of change in CGI
Up
Reproduction of 3GPP TS 23.060, Fig. 15.1.3-2: Iu-mode Location report triggering a report of change in SAI
Figure 15.1.3-2: Iu-mode Location report triggering a report of change in SAI
Up
Reproduction of 3GPP TS 23.060, Fig. 15.1.3-3: User CSG Information Changes triggering a report of change in user CSG information
Figure 15.1.3-3: User CSG Information Changes triggering a report of change in user CSG information
Up
Step 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.
Step 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.
Up

15.1.3.2a  Interaction with CGI / SAI / user CSG information reporting using S4 |R8|  p. 328

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.
Reproduction of 3GPP TS 23.060, Fig. 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
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
Up
Step 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.
Step 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.
Up

15.1.3.3  Reporting of Presence Reporting Area entering and leaving |R12|  p. 329

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.
Reproduction of 3GPP TS 23.060, Fig. 15.1.3.3-1: Reporting of Presence Reporting Area entering and leaving
Figure 15.1.3.3-1: Reporting of Presence Reporting Area entering and leaving
Up
Step 1a.
In Gb-mode, the S4-SGSN receives a Cell Update indication via the mechanisms described in clause 6.9.1.1.
Step 1b.
In Iu-mode, the S4-SGSN receives a location report message (as per the location reporting procedures in clause 12.7.5).
Step 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).
Step 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.
Up

15.2  Quality of Service Profile  p. 329

15.2.0  General |R8|  p. 329

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, 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 and the mapping between the EPS Bearer QoS parameters and the Release 99 QoS attributes in TS 23.401.
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.
Up

15.2.1  Radio Priority Levels (A/Gb mode)  p. 330

The RLC/MAC layer supports four radio priority levels and an additional level for signalling messages as defined in TS 43.064 and TS 44.060. 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. 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.
Up

15.2.1a  APN-AMBR |R9|  p. 330

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.
Up

15.2.2  UE-AMBR |R9|  p. 330

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.
Up

15.2.3  Support of rate control of user data using CIoT optimisation |R14|  p. 331

15.2.3.1  General  p. 331

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  p. 331

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.
Up

Up   Top   ToC