S.8 Charging using AAA signalling
23.2033GPPPolicy and charging control architectureRelease 17TS
The architecture shall provide charging for traffic exchanged by fixed devices and NSWO traffic to/from 3GPP UEs using AAA signalling.
In this release in case of AAA-based charging the BBF AAA server is used for performing accounting of fixed device as defined by BBF specifications TR-101 [35] and TR-146 [36].
NOTE: The AAA-based accounting for fixed device is not applicable in roaming scenario.
For the charging session over Gya and Gza, the user identifier is the same that is issued over the Gx session
S.8.1 Reference architecture – Non-Roaming
Figure S.8.1: PCC Reference architecture for Fixed Broadband Access convergence when AAA-based accounting is used
S.8.2 Reference architecture – Roaming
Figure S.8.2: PCC Reference architecture for Fixed Broadband Access convergence (roaming) when AAA-based accounting is used
S.8.3 Gza Reference Point
To transport charging information about 3GPP UE, the Gza reference point is located between Accounting Interworking function in the BBF defined network and the 3GPP offline charging system OFCS located in the VPLMN (roaming scenario) or in the HPLMN (non-roaming scenario).
To transport charging information about fixed devices, the Gza reference point is located between the Accounting Interworking function in the BBF defined network and the 3GPP offline charging system located in the HPLMN (only non-roaming scenario).
NOTE: The detailed definition of Gza reference point and diagram flows for supporting AAA-based charging is outside the scope of this specification. See SA WG5 specifications for further details.
S.8.4 Gya Reference Point
The Gya reference point is located between the Accounting Interworking function in the BBF defined Access Network and the 3GPP online charging system OCS located in the HPLMN and it transports charging information for 3GPP UE.
The Gya reference point is located between the Accounting Interworking function in the BBF defined Access Network and the 3GPP online charging system located in the HPLMN and it transports charging information for fixed device.
NOTE: The definition of Gya reference point and diagram flows for supporting AAA-based charging is outside the scope of this specification. See SA WG5 specifications for further details.
S.8.5 B Reference Point
This reference point is defined in BBF TR-300 [37].
NOTE: The definition of this reference point is out of the scope of 3GPP.
S.8.6 AAA based charging
The charging support for NSWO traffic for 3GPP UE and fixed devices can be provided when the BBF network reports per-user accounting data via B and Gya/Gza reference points.
Offline and online charging may be supported by the 3GPP and BBF domain. In this Release, in case of AAA-based charging, the Online charging is supported based on existing capability supported by B reference point and IP-Edge with limitation based on AAA RADIUS/Diameter accounting in the BBF network (e.g. BNG capability, usage of RADIUS over B reference point).
For RG in routed mode configuration with NAT, the single devices (i.e. fixed device and 3GPP UE) connected behind a RG can not be recognised, so the accounting is performed only for the RG.
In case of RG bridge mode configuration and in routed mode configuration without NAT the AAA based charging is performed per single devices having a Subscriber IP session.
In order to allow performing charging for fixed devices, the following assumptions are made about functionality in the Fixed Broadband Network:
– The BBF network is able to collect per user accounting data for fixed devices and periodically report this data via the B reference point.
S.8.7 Accounting Interworking Function
The Accounting Interworking Function that performs translation of the accounting signalling and parameters that are understood by the IP-Edge into the credit management signalling and parameters that are understood by the OCS and the OFCS is defined in BBF TR-300 [37].
S.8.8 Procedures AAA based charging using accounting signalling
S.8.8.0 General
This clause describes the AAA-based charging. The basic assumption is that B interface is not modified.
S.8.8.1 Charging Session Initiation
This procedure is performed for initiation of charging session
Figure S.8.8.1: AAA-based Charging Session Initiation
The steps included in Block A and B are mutually exclusive.
1. The 3GPP UE EAP-based authentication or BBF Fixed device authentication is performed.
NOTE 1: Authentication for fixed device is out of the scope of 3GPP specifications.
A.1 If AAA-based accounting applies, the 3GPP UE/BBF device is successfully authenticated and this triggers the interaction with the OCS system. This step is outside the 3GPP scope.
A.2. The Accounting Interworking Function that will activate the online-charging session, and provide relevant input information for the OCS decision. i.e. subscriber identifier and charging keys obtained in step A.1.
A.3. If online charging is applicable, the OCS provides the possible credit information to the Accounting Interworking Function and may provide re-authorisation triggers for each of the credits.
NOTE 2: The Only Credit Reauthorization triggers that can be reported are "Credit Reauthorization time expired".
2. If PCC is supported, the IP-CAN session establishment procedure may be established as define in clause S.7.2. The steps from 1 to 14 defined in clause 7.2 are performed with the following exception:
– Steps 9 – 10 are performed only if TDF based accounting is supported and AAA-based accounting is not supported.
– Steps 13 – 14 are performed only if PCEF accounting is supported and AAA-based accounting is not supported.
B.1. If AAA-based accounting applies, the start of accounting session is triggered in BBF AAA. This step is out of the scope of 3GPP specifications.
NOTE 3: This step may occur anytime in parallel to steps from 1 to 14 of clause 7.2
B.2. The same step as step A.1
B.3. The same step as step A.2
3 The IP-CAN session establishment as defined in clause 7.2 steps from 15 to 17 are performed.
S.8.8.2 Charging Session Modification
This procedure is performed for updating the charging information, such as the available quota.
Figure S.8.8.2: AAA-based Charging Session modification
1. The BNG can sent a RADIUS-Start accounting message or a RADIUS-Intermediate-Accounting message.
2 When the Accounting Interworking Function receives the message, it determines if it is required to update the accounting information which triggers an interaction with the OCS.
3. The Accounting Interworking Function may contact the OCS to request credit for new charging keys and/or to issue final report and return remaining credit for charging keys no longer active, i.e. when the accounting session is terminated.
4. The OCS may instruct the Accounting Interworking Function on the further handling of the session (terminate, continue, etc), provide credit information (possibly with re-authorisation trigger), and/or acknowledge the credit report.
S.8.8.3 Charging Session Termination
S.8.8.3.1 Charging Session Termination BNG-initiated
This procedure is performed when BNG send a stop accounting message to the Accounting Interworking Function, for example the IP-CAN session termination procedure is initiated by PCRF or when Subscriber IP session terminated (for example when the 3GPP UE disassociates from the fixed broadband network, the RG is switched off, etc.).
Figure S.8.8.3.1-1: AAA-based Charging Session Termination
1. The BNG determines that the Subscriber IP session is terminated (e.g. the device has left the fixed broadband network) and consequently a PCEF-Initiated IP-CAN session termination is initiated or it shall be terminated, when PCRF-Initiated IP-CAN session termination procedure is performed.
2. The BNG send a RADIUS-Stop-accounting message to the ACC_If. This step is outside the scope of 3GPP specifications.
3 The Accounting Interworking Function determines that the Accounting Session shall be terminated.
4. The Accounting Interworking Function shall issue the final reports and return the remaining credit to the OCS.
5. The OCS acknowledges the credit report and terminates the online charging session.
Annex T (informative):
How to accumulate PCC/ADC Rule usage in multiple monitoring groups
If usage for a PCC/ADC rule is accumulated in multiple Monitoring Groups, the following solution re-uses the capabilities defined in the main body of this specification, the steps are described below:
1. The PCRF retrieves the total group allowance for the Monitoring Group and the set of services belonging to the Monitoring Group from the SPR.
2. For dynamic PCC/ADC Rules, the PCRF selects a Monitoring Key for those services that belongs to more than one Monitoring Group but does not have an individual Monitoring Key assigned.
3. For pre-configured PCC/ADC Rules the PCRF selects the PCC/ADC Rules for each of the services that belong to the monitoring group. For pre-configured PCC/ADC Rules, the PCEF is configured with an individual Monitoring Key that monitors the usage.
4. The PCRF calculates a usage threshold for each of these Monitoring Keys taking into account the minimum of the individual service allowance and the monitoring group allowance(s) the service belongs to.
5. The PCRF installs or activates the PCC/ADC Rule. The PCRF provides a usage threshold for each Monitoring Key.
6. When the PCRF receives a usage report for a Monitoring Key from the requested node (PCEF or TDF), the PCRF shall deduct the value from the corresponding group allowances and from the individual allowance if needed.
7. As long as all group usage allowances are not reached, the PCRF calculates a new usage threshold for the Monitoring Key based on the corresponding group allowances the service belongs to.
Annex U (normative):
Policy and charging control in the downlink direction for traffic marked with DSCP by the TDF
In order to provide policy and charging control (e.g. QoS enforcement) in the downlink direction for applications with non-deducible service data flows detected by the TDF, in addition to the solution described in clause 4.5, the following solution is defined:
The TDF shall be able to mark detected downlink application traffic with a DSCP value received within an installed ADC Rule matching this traffic.
NOTE 1: Unless a class of applications matches the definition of a DSCP value standardised by IETF, DSCP values with no standardised meaning in IETF are used. DSCP values in ranges reserved by IANA for "experimental or Local Use" are suitable.
NOTE 2: Using DSCP values with no standardised meaning in IETF prevents any IP router between TDF and PCEF to perform differentiated service scheduling for related IP packets unless it is updated or configured to support those DSCP values. This implies that sufficient network capacity must be guaranteed along the path between the TDF and PCEF so that the disabling of DiffServ packet forwarding has no detrimental impact on the end-to-end QoS.
NOTE 3: Marking of DSCP bits for this purpose can interfere with appropriate traffic handling in some operator transport networks. The DSCP marking may also get remarked by routing entities within the operator networks.
NOTE 4: If the application sets DSCP marking that is used for policy and charging control in the PCEF, either no ADC Rule is installed in the TDF matching this application traffic or if an ADC Rule is installed, then DSCP marking is not enabled. When TDF sets DSCP to values used for policy and charging control, network configuration needs to prevent an untrusted source from getting unplanned QoS and charging and also prevent remapping of this traffic between the application and the TDF.
To ensure that the DSCP value used for service data flow detection is not visible to the operator’s transport network, based on operator configuration, a tunnelling protocol may be used between TDF and PCEF.
In case tunnelling is used then the DSCP value used for service data flow detection shall be carried in the inner IP header. The DSCP marking used in the operator’s transport network is carried in the outer IP header of the tunnel.
NOTE 5: The tunnel connections are preconfigured in the IP infrastructure connecting the TDF and the PCEF. The operator needs to ensure the same tunnel configuration is used for the TDF and for the PCEF. The tunnel protocol can be any applicable IP-based tunnel depending on operator´s choice.
In order to support policy and charging control in the downlink direction by the PCEF/BBERF for an application detected by the TDF (typically for services with non -deducible service data flows), the PCRF shall either install a dynamic PCC/QoS Rule or activate a pre-defined PCC rule, which identifies traffic based on the corresponding DSCP value (provided by the ToS/Traffic Class mask field within the service data flow filter). In case tunnelling is used, the PCEF shall use the inner header’s DSCP for the service data flow detection defined in clause 6.2.2.2.
NOTE 6: This solution is particularly useful for QoS enforcement in the downlink direction procedures performed by the PCEF/BBERF. The TDF may still perform application detection and control as per received ADC Rules, including application detection reporting to the PCRF, enforcement control, usage monitoring control and charging, while applying DSCP marking. The PCEF/BBERF may also perform then policy and charging control in the downlink direction.
Annex V (informative):
Policy Control for Remote UEs behind a ProSe UE-to-Network Relay UE
With the Proximity-based services, in accordance with TS 23.303 [44], a UE acting as a Remote UE can connect to a PDN via a ProSe UE-to-Network Relay UE, using an IP-CAN session that the Relay UE has established.
The Relay UE is assigned an IPv6 prefix that is shorter than /64.
The PCRF does not get any Remote UE identity and is not required to be aware of the Remote UE but is expected to validate Remote UE related service information from the AF and generate any necessary PCC rules according to standard procedures already defined. PCC rule authorizations may be static (e.g. predefined PCC rules) or rely on AF provided service information.
An AF serving a remote UE reaches the appropriate PCRF based on the IPv6 prefix that the UE-to-Network Relay UE has assigned to the remote UE. The AF reaches the appropriate PCRF by performing a PLMN lookup for the IPv6 prefix and using the Network Realm/Domain, as defined in TS 23.003 [16], associated with the PLMN.
In order to make a PCC rule specific for a certain Remote UE, the SDF filters used for traffic detection need to include the attribute Local Address and Mask with a value that corresponds to the Remote UE only. The value is normally an IPv6 prefix that is longer than the prefix assigned for the IP-CAN session (i.e. for the ProSe UE-to-Network Relay UE).
Annex W (informative):
Void
Annex X (informative):
Encrypted traffic detection by using domain name matching
For the cases when it is required to detect and enforce/charge sponsored services within encrypted traffic, and those sponsored services are uniquely identifiable by a list of {IP address ranges, domain name matching strings, match type (absolute/suffix)} set, while either element in the pair of {IP address ranges, domain name matching strings} can be "any", as applicable, but not both elements simultaneously, the domain name matching solution described below may be used.
NOTE 1: L3 information (IP address ranges) is visible even if traffic is encrypted.
The following assumptions apply for the solution:
– There exists an agreement between the operator and sponsored data connectivity content provider.
– Content provider uses HTTPS as a transport mechanism, using Web Public Key Infrastructure (PKI).
The set of information {IP address ranges, domain name matching strings, match type (absolute/suffix)} required to identify encrypted traffic is defined in the PCEF/TDF either by using pre-defined PCC/ADC Rules or by using dynamic PCC/ADC Rules that include Application Identifiers, as applicable. The detection logic to which Application Identifier in the PCEF/TDF refers to, is extended to cover ({IP address ranges, domain name matching strings, match type (absolute/suffix)} information. If such a pre-defined or dynamic PCC/ADC Rule is active for an IP-CAN/TDF session, the PCEF/TDF shall check IP address ranges, and, in case of compliancy with the received/preconfigured value (see note 2), match domain name strings, either absolutely or by suffix, against the following fields in the initial HTTPS handshake:
– TLS Server Name Indication (SNI) extension, when available (see [47]); or, if not available.
– Server certificate’s Subject Alternative Name x.509 extension DNS name, when available. All relevant values shall be examined for matching; or if not available or no match was found.
– Server certificate’s Subject Common Name (CN).
NOTE 2: If the IP address ranges equals "Any", then any traffic is said to be compliant.
The information required for the detection of sponsored HTTPS (i.e. defined in Annex X to be pre-configured in the PCEF/TDF and either the TLS SNI extension or the Server certificate´s Subject Alternative Name x.509 DNS name or Server certificate´s Subject CN) is verified with the corresponding server IP address/prefix of the IP packets by the PCEF/TDF. The PCEF/TDF uses implementation specific logic to perform this verification.
Annex Y (informative):
Change history
|
Change history |
|||||||
|
Date |
Meeting |
TDoc |
CR |
Rev |
Cat |
Subject/Comment |
New version |
|
2014-06 |
SP-64 |
SP-140273 |
0885 |
5 |
B |
PCC Rules sharing resources |
13.0.0 |
|
2014-06 |
SP-64 |
SP-140383 |
0885 |
6 |
B |
PCC Rules sharing resources |
13.0.1 |
|
2014-09 |
SP-65 |
SP-140428 |
0896 |
2 |
B |
Addition of RAN user plane congestion handling feature into the specification |
13.1.0 |
|
2014-09 |
SP-65 |
SP-140428 |
0897 |
2 |
B |
Np reporting restrictions |
13.1.0 |
|
2014-09 |
SP-65 |
SP-140428 |
0899 |
2 |
B |
Aggregation of Np messages |
13.1.0 |
|
2014-09 |
SP-65 |
SP-140421 |
0907 |
2 |
A |
Clarifications for PRA reporting |
13.1.0 |
|
2014-09 |
SP-65 |
SP-140431 |
0908 |
2 |
F |
Clarification of resource sharing for different Rx sessions |
13.1.0 |
|
2014-09 |
SP-65 |
SP-140441 |
0914 |
– |
A |
QCI values for Public Safety services |
13.1.0 |
|
2014-12 |
SP-66 |
SP-140674 |
0904 |
3 |
A |
Clarifications for TFT handling |
13.2.0 |
|
2014-12 |
SP-66 |
SP-140689 |
0915 |
– |
C |
Applicability of congestion information reporting for certain APNs only |
13.2.0 |
|
2014-12 |
SP-66 |
SP-140689 |
0916 |
2 |
F |
Clarifying details of deferred services |
13.2.0 |
|
2014-12 |
SP-66 |
SP-140671 |
0920 |
2 |
A |
Support for IPv6 prefix retrieve by the HSGW during the eHRPD pre-registration procedure |
13.2.0 |
|
2014-12 |
SP-66 |
SP-140694 |
0921 |
3 |
B |
Introducing the feature of excluding Usage of a Service/Application from IP-CAN session/TDF session Usage into the specification |
13.2.0 |
|
2014-12 |
SP-66 |
SP-140690 |
0922 |
2 |
B |
Indication to share resources in the UL or DL or both directions |
13.2.0 |
|
2014-12 |
SP-66 |
SP-140685 |
0924 |
4 |
A |
Charging correlation identifier for the IP-CAN session |
13.2.0 |
|
2014-12 |
SP-66 |
SP-140694 |
0925 |
1 |
D |
New Annex: Monitor service usage in multiple groups |
13.2.0 |
|
2014-12 |
SP-66 |
SP-140689 |
0926 |
3 |
C |
Np mobility handling |
13.2.0 |
|
2014-12 |
SP-66 |
SP-140689 |
0927 |
– |
C |
Resolution of Editor’s note on bandwidth limitation. |
13.2.0 |
|
2014-12 |
SP-66 |
SP-140678 |
0930 |
2 |
A |
QoS handling at inter-RAT mobility |
13.2.0 |
|
2014-12 |
SP-66 |
SP-140668 |
0939 |
1 |
A |
Correct Reference to 3GPP2 X.S0057 |
13.2.0 |
|
2014-12 |
SP-66 |
SP-140678 |
0946 |
2 |
A |
Correction to Delay Budget for first packets in a data burst |
13.2.0 |
|
2014-12 |
SP-66 |
SP-140689 |
0950 |
2 |
F |
Transfer of location information on Np |
13.2.0 |
|
2014-12 |
SP-66 |
SP-140689 |
0952 |
– |
F |
Removal of Editor Note on logical PCRF id |
13.2.0 |
|
2014-12 |
SP-66 |
SP-140693 |
0953 |
3 |
C |
TDF support for downlink’s bearer selection and bearer binding procedures |
13.2.0 |
|
2014-12 |
SP-66 |
SP-140686 |
0955 |
2 |
A |
Proposal to solve the discussion on how QoS change of default bearer affects PCC Rules bound to the default bearer |
13.2.0 |
|
2014-12 |
SP-66 |
SP-140693 |
0958 |
3 |
B |
Activate PCC function per UE based on subscription information |
13.2.0 |
|
2014-12 |
SP-66 |
SP-140689 |
0961 |
2 |
F |
Clarifying reporting of no congestion state |
13.2.0 |
|
2014-12 |
SP-66 |
SP-140693 |
0963 |
2 |
B |
TWAN release cause for Trusted WLAN |
13.2.0 |
|
2014-12 |
SP-66 |
SP-140679 |
0964 |
– |
F |
Stage 3 alignment for Fixed Broadband Access |
13.2.0 |
|
2015-03 |
SP-67 |
SP-150027 |
0966 |
3 |
B |
Removing restrictions to report RAT type to the AF |
13.3.0 |
|
2015-03 |
SP-67 |
SP-150027 |
0968 |
1 |
B |
Activate PCC function per UE based on subscription information when BBERF is deployed |
13.3.0 |
|
2015-03 |
SP-67 |
SP-150109 |
0971 |
1 |
A |
Correction to support of I-WLAN in TS 23.203 |
13.3.0 |
|
2015-06 |
SP-68 |
SP-150230 |
0905 |
6 |
A |
Priority of Default Bearer |
13.4.0 |
|
2015-06 |
SP-68 |
SP-150230 |
0941 |
5 |
A |
Clarifications for QoS change of default bearer |
13.4.0 |
|
2015-06 |
SP-68 |
SP-150235 |
0975 |
2 |
B |
Resource management for background data transfer via Rx |
13.4.0 |
|
2015-06 |
SP-68 |
SP-150232 |
0976 |
3 |
F |
Configuring AF application identifier value in PCRF to avoid SRVCC |
13.4.0 |
|
2015-06 |
SP-68 |
SP-150239 |
0977 |
1 |
F |
Session/bearer release cause over S2b |
13.4.0 |
|
2015-06 |
SP-68 |
SP-150231 |
0978 |
2 |
F |
Alignment of RUCI reporting restrictions’ basis for UPCON |
13.4.0 |
|
2015-09 |
SP-69 |
SP-150492 |
0980 |
3 |
B |
Introduction of Flexible Mobile Service Steering feature into PCC architecture |
13.5.0 |
|
2015-09 |
SP-69 |
SP-150498 |
0981 |
1 |
F |
Adding Nt reference point to architecture |
13.5.0 |
|
2015-09 |
SP-69 |
SP-150503 |
0985 |
2 |
B |
Location to Support Emergency services over WLAN access to EPC |
13.5.0 |
|
2015-09 |
SP-69 |
SP-150497 |
0986 |
3 |
B |
PCC Support of NBIFOM |
13.5.0 |
|
2015-09 |
SP-69 |
SP-150491 |
0988 |
1 |
A |
Clarifications for PCC rule actions |
13.5.0 |
|
2015-09 |
SP-69 |
SP-150492 |
0989 |
3 |
B |
Update the architecture to support the FMSS for EPC-routed scenario |
13.5.0 |
|
2015-09 |
SP-69 |
SP-150492 |
0990 |
4 |
B |
Definition of Traffic Steering Control Information |
13.5.0 |
|
2015-09 |
SP-69 |
SP-150505 |
0991 |
2 |
F |
Removal of OCS proxy in LBO roaming scenario |
13.5.0 |
|
2015-09 |
SP-69 |
SP-150492 |
0992 |
3 |
B |
High level requirement and function description of FMSS |
13.5.0 |
|
2015-09 |
SP-69 |
SP-150500 |
0994 |
1 |
F |
Addition of resource sharing indication |
13.5.0 |
|
2015-09 |
SP-69 |
SP-150492 |
0995 |
3 |
B |
PCC architecture enhancement for traffic steering using St and TSSF |
13.5.0 |
|
2015-09 |
SP-69 |
SP-150550 |
0983 |
4 |
B |
PCC Procedures and Flows including Traffic Steering |
13.5.0 |
|
2015-09 |
– |
– |
– |
– |
– |
MCC correction to implementation of CR0986R3 |
13.5.1 |
|
2015-12 |
SP-70 |
SP-150604 |
1000 |
3 |
B |
Policy Control for remote UE behind relay UE |
13.6.0 |
|
2015-12 |
SP-70 |
SP-150607 |
1002 |
3 |
F |
Bearer binding, usage monitoring and other impacts due to NBIFOM |
13.6.0 |
|
2015-12 |
SP-70 |
SP-150608 |
1004 |
1 |
F |
Clarify Nt Reference Point |
13.6.0 |
|
2015-12 |
SP-70 |
SP-150614 |
1006 |
1 |
F |
Update of the PCC rules during the addition of an access procedure |
13.6.0 |
|
2015-12 |
SP-70 |
SP-150617 |
1007 |
1 |
F |
Conveying to the EPC the IMEI of devices accessing a trusted or untrusted WLAN |
13.6.0 |
|
2015-12 |
SP-70 |
SP-150613 |
1008 |
1 |
F |
Transfer of User Location Information at Create Session Request over S2b |
13.6.0 |
|
2015-12 |
SP-70 |
SP-150600 |
1012 |
– |
A |
Correction of definition of QCI 65, 66, 69 and 70 |
13.6.0 |
|
2016-03 |
SP-71 |
SP-160162 |
1009 |
7 |
B |
APN AMBR change at a certain time on Gx |
13.7.0 |
|
2016-03 |
SP-71 |
SP-160162 |
1018 |
2 |
F |
Bitrate variations |
13.7.0 |
|
2016-06 |
SP-72 |
SP-160298 |
1013 |
7 |
C |
Priority sharing for concurrent sessions |
13.8.0 |
|
2016-06 |
SP-72 |
SP-160294 |
1021 |
1 |
F |
Clarification of the decision of NBIFOM mode |
13.8.0 |
|
2016-06 |
SP-72 |
SP-160291 |
1023 |
1 |
F |
Transfer of traffic steering policy control information for TSSF |
13.8.0 |
|
2016-06 |
SP-72 |
SP-160291 |
1026 |
– |
F |
Corrections to FMSS related descriptions |
13.8.0 |
|
2016-06 |
SP-72 |
SP-160287 |
1029 |
2 |
B |
Update of 23.203 for CIoT |
13.8.0 |
|
2016-06 |
SP-72 |
SP-160294 |
1030 |
2 |
F |
Clarifications and Corrections for NBIFOM |
13.8.0 |
|
2016-06 |
SP-72 |
SP-160304 |
1022 |
2 |
B |
Subscription to notification of PLMN id change over Rx |
14.0.0 |
|
2016-09 |
SP-73 |
SP-160653 |
1025 |
3 |
B |
Reporting entering or leaving a set of PRAs |
14.1.0 |
|
2016-09 |
SP-73 |
SP-160653 |
1031 |
9 |
B |
Support of Multiple PRAs |
14.1.0 |
|
2016-09 |
SP-73 |
SP-160655 |
1032 |
– |
C |
Support of sponsored data connectivity for TDF |
14.1.0 |
|
2016-09 |
SP-73 |
SP-160655 |
1033 |
5 |
B |
Encrypted traffic detection by using domain name matching |
14.1.0 |
|
2016-09 |
SP-73 |
SP-160645 |
1034 |
4 |
C |
Support of traffic steering control for 3rd party service function |
14.1.0 |
|
2016-09 |
SP-73 |
SP-160651 |
1035 |
3 |
B |
Provision of EPC-level identities for IMS emergency sessions over Rx |
14.1.0 |
|
2016-09 |
SP-73 |
SP-160655 |
1036 |
7 |
B |
Management of PFDs to PCEF/TDF |
14.1.0 |
|
2016-09 |
SP-73 |
SP-160644 |
1037 |
1 |
A |
Provisioning of the Source port and ePDG IP address |
14.1.0 |
|
2016-09 |
SP-73 |
SP-160641 |
1039 |
1 |
A |
Setting the RR identifier alignment with stage 3 |
14.1.0 |
|
2016-09 |
SP-73 |
SP-160655 |
1041 |
3 |
B |
Architecture enhancement to support SDCI |
14.1.0 |
|
2016-09 |
SP-73 |
SP-160655 |
1043 |
6 |
B |
PFD retrieval and the procedures for sponsored data connectivity enhancement |
14.1.0 |
|
2016-09 |
SP-73 |
SP-160641 |
1045 |
3 |
A |
Details of PCEF Routing Rule operations |
14.1.0 |
|
2016-09 |
SP-73 |
SP-160638 |
1050 |
2 |
A |
Extending the IE for application detection within the ADC Rules |
14.1.0 |
|
2016-09 |
SP-73 |
SP-160655 |
1051 |
3 |
B |
Sponsored HTTP traffic detection by using domain name matching |
14.1.0 |
|
2016-09 |
SP-73 |
SP-160658 |
1052 |
1 |
B |
Adding ENODEB_CHANGE event trigger |
14.1.0 |
|
2016-09 |
SP-73 |
SP-160655 |
1053 |
3 |
B |
Rx enhancement for SDCI |
14.1.0 |
|
2016-09 |
SP-73 |
SP-160646 |
1058 |
2 |
B |
New QCI values for V2X services |
14.1.0 |
|
2016-09 |
SP-73 |
SP-160658 |
1060 |
2 |
B |
Predictable pre-emption of media flows |
14.1.0 |
|
2016-09 |
SP-73 |
SP-160638 |
1066 |
2 |
A |
Overlapping IP Addresses with FMSS |
14.1.0 |
|
2016-12 |
SP-74 |
SP-160812 |
1070 |
1 |
A |
Remove "same media type" requirement for Priority Sharing |
14.2.0 |
|
2016-12 |
SP-74 |
SP-160818 |
1071 |
3 |
F |
Modification of PRA information over Gx reference point |
14.2.0 |
|
2016-12 |
SP-74 |
SP-160826 |
1076 |
4 |
B |
Introduction of 3GPP PS Data Off |
14.2.0 |
|
2016-12 |
SP-74 |
SP-160818 |
1077 |
3 |
F |
Corrections on the usage of set of PRA |
14.2.0 |
|
2016-12 |
SP-74 |
SP-160818 |
1079 |
1 |
F |
Configuration of multiple PRAs |
14.2.0 |
|
2016-12 |
SP-74 |
SP-160908 |
1073 |
3 |
C |
Service input for the setting of the ARP-PCI and ARP-PVI |
14.2.0 |
|
2016-12 |
SP-74 |
SP-160921 |
1068 |
5 |
C |
Deferred default EPS bearer QCI and ARP change |
14.2.0 |
|
2017-03 |
SP-75 |
SP-170052 |
1081 |
1 |
C |
TS 23.203 support for transport level packet marking |
14.3.0 |
|
2017-06 |
SP-76 |
SP-170370 |
1082 |
3 |
F |
Updating the description of 3GPP PS Data Off feature |
14.4.0 |
|
2017-06 |
SP-76 |
SP-170368 |
1086 |
7 |
F |
Clarification of caching time |
14.4.0 |
|
2017-06 |
SP-76 |
SP-170368 |
1090 |
2 |
F |
Corrections to handling of partial and full updates |
14.4.0 |
|
2017-09 |
SP-77 |
SP-170719 |
1093 |
1 |
F |
Correction to event trigger Data Off Change |
14.5.0 |
|
2017-09 |
SP-77 |
SP-170720 |
1094 |
2 |
F |
Corrections to PFD removal |
14.5.0 |
|
2017-09 |
SP-77 |
SP-170732 |
1092 |
2 |
C |
Enhancement on Sy reference point |
15.0.0 |
|
2017-09 |
SP-77 |
SP-170729 |
1099 |
2 |
C |
23.203 PCEF Support for Data Off phase 2 |
15.0.0 |
|
2017-12 |
SP-78 |
SP-170921 |
1106 |
3 |
C |
Support for Unsynchronized lists |
15.1.0 |
|
2017-12 |
SP-78 |
SP-170926 |
1107 |
5 |
B |
Enhanced VoLTE performance CR for TS 23.203 |
15.1.0 |
|
2017-12 |
SP-78 |
SP-170924 |
1110 |
3 |
C |
Use of ARP priority level in addition to QCI for packet handling |
15.1.0 |
|
2017-12 |
SP-78 |
SP-170929 |
1111 |
2 |
C |
Extension on QCI for MC Video |
15.1.0 |
|
2017-12 |
SP-78 |
SP-170920 |
1112 |
4 |
B |
Introduction of new QCIs for low latency with normal reliability requirements |
15.1.0 |
|
2017-12 |
SP-78 |
SP-170924 |
1113 |
2 |
F |
Clarify MBMS and other use of PCC/QoS specification |
15.1.0 |
|
2018-03 |
SP-79 |
SP-180110 |
1116 |
1 |
C |
QCIs for URLLC |
15.2.0 |
|
2018-06 |
SP-80 |
SP-180472 |
1119 |
4 |
A |
Application detection report when the PFDs are removed |
15.3.0 |
|
2018-06 |
SP-80 |
SP-180496 |
1120 |
5 |
F |
Policy update when UE is suspended |
15.3.0 |
|
2018-06 |
SP-80 |
SP-180494 |
1121 |
– |
F |
Updates to URLLC QCIs to align with SA1’s updated requirements |
15.3.0 |
|
2018-09 |
SP-81 |
SP-180726 |
1122 |
1 |
F |
Corrections for low latency QCIs |
15.4.0 |
|
2018-09 |
SP-81 |
SP-180729 |
1123 |
1 |
F |
Removal of incorrect definition of WB-E-UTRAN |
15.4.0 |
|
2019-03 |
SP-83 |
SP-190175 |
1124 |
3 |
C |
New QCIs for Enhanced Framework for Uplink Streaming |
16.0.0 |
|
2019-03 |
SP-83 |
SP-190163 |
1125 |
2 |
B |
Support for Restricted Local Operator Services in 23.203 |
16.0.0 |
|
2019-06 |
SP-84 |
SP-190404 |
1127 |
2 |
A |
Multiple PFD filters, alignment with stage 3 |
16.1.0 |
|
2019-12 |
SP-86 |
SP-191089 |
1130 |
1 |
F |
Aligning TS 23.203 with the CHEM feature of SA4 |
16.2.0 |
|
2021-03 |
SP-91E |
SP-210085 |
1133 |
1 |
B |
Multimedia Priority Service (MPS) Phase 2 support for Data Transport Service |
17.0.0 |
|
2021-06 |
SP-92E |
SP-210361 |
1134 |
1 |
F |
Multimedia Priority Service (MPS) Phase 2 support for Data Transport Service |
17.1.0 |
|
2021-06 |
SP-92E |
SP-210361 |
1135 |
1 |
B |
Additional authorization functionality in support of MPS for Data Transport Service |
17.1.0 |
|
2021-12 |
SP-94E |
SP-211284 |
1136 |
2 |
B |
Support policy and QoS control for satellite access |
17.2.0 |
|
2021-12 |
SP-94E |
SP-211279 |
1138 |
1 |
A |
Access network information request without PCC rules |
17.2.0 |