Content for TR 23.800 Word version: 12.0.0
5 Key Issues
6 Solutions
7 Evaluation
8 Conclusions
A Application Based Charging for the applications with deducible service data flows (as supported in Rel-11)
B Packet Marking Mechanisms
$ Change history
5 Key Issues p. 11
6 Solutions p. 13
6.1 Solutions for Scenario 1: application usage charging only per IP-CAN session p. 13
6.1.1 Alternative solution 1: sdf transfer p. 13
6.1.1.1 Solutions' assumptions p. 13
6.1.1.2 Reference architecture p. 14
6.1.1.3 Application Detection and Control Rule extension p. 14
6.1.1.4 Credit management p. 15
6.1.1.5 Termination Action p. 16
6.1.1.5a Reporting p. 16
6.1.1.6 Functional Description p. 16
6.1.1.7 Impacts on existing nodes or functionality p. 18
6.1.2 Alternative solution 2: Sy extension p. 18
6.1.2.1 Solutions' assumptions p. 18
6.1.2.2 Reference architecture p. 18
6.1.2.3 Reporting, Credit management and termination action p. 19
6.1.2.4 Functional description p. 19
6.1.2.5 Impacts on existing nodes or functionality p. 19
6.1.3 Alternative solution 3: TDF marking and PCEF based application charging p. 19
6.1.3.1 Solutions' assumptions p. 19
6.1.3.2 Reference architecture, Reporting, Credit management, Termination action p. 19
6.1.3.3 Functional description p. 19
6.1.3.3.1 General description p. 19
6.1.3.3.2 Principle message flow p. 20
6.1.3.3.3 Mechanisms for packet marking p. 21
6.1.3.3.4 Mechanisms for TDF counter transfer (variant 4c) only) p. 21
6.1.3.4 Impacts on existing nodes or functionality p. 22
6.1.4 Alternative solution 4: Bi-Directional Marking of Charged Packets p. 22
6.1.4.1 Solution assumptions p. 22
6.1.4.2 Reference architecture p. 22
6.1.4.3 Functional description p. 22
6.1.5 Alternative solution 5: TDF TFT analysis p. 23
6.1.5.1 Solutions' assumptions p. 23
6.1.5.2 Reference architecture p. 23
6.1.5.3 ADC rule extension p. 23
6.1.5.4 Termination Action p. 23
6.1.5.5 Functional description p. 23
6.1.5.6 Impacts on existing nodes or functionality p. 24
6.1.6 Alternative solution 6: Returning the dropped packet p. 24
6.1.6.1 Solutions' assumptions p. 24
6.1.6.2 Reference architecture p. 24
6.1.6.3 Functional description p. 24
6.1.6.4 Mechanisms of tunnelling p. 24
6.1.7 Alternative solution 7: Simplified solution for Application Based Charging p. 24
6.2 Solutions for Scenario 2: sdf usage charging only per IP-CAN session p. 26
6.2.1 Alternative solution 1: sdf transfer p. 26
6.2.1.1 Solutions' assumptions p. 26
6.2.1.2 Reference architecture, Reporting, Credit management, Termination action p. 26
6.2.1.3 Functional description p. 26
6.2.1.4 Impacts on existing nodes or functionality p. 27
6.2.2 Alternative solution 2: Sy extension p. 28
6.2.2.1 Solutions' assumptions p. 28
6.2.2.2 Reference architecture p. 28
6.2.2.3 Reporting, Credit management and termination action p. 28
6.2.2.4 Functional description p. 28
6.2.2.5 Impacts on existing nodes or functionality p. 28
6.2.3 Alternative solution 3: TDF marking and PCEF based application charging p. 29
6.2.3.1 Solutions' assumptions p. 29
6.2.3.2 Reference architecture, Credit management, Termination action p. 29
6.2.3.3 Functional description p. 29
6.2.3.4 Impacts on existing nodes or functionality p. 29
6.2.4 Alternative solution 4: Bi-Directional Marking of Charged Packets p. 29
6.2.4.1 Solution assumptions p. 29
6.2.4.2 Reference architecture p. 29
6.2.4.3 Functional description p. 30
6.2.5 Alternative solution 5: TDF TFT analysis p. 30
6.2.5.1 Solutions' assumptions p. 30
6.2.5.2 Reference architecture p. 30
6.2.5.3 PCC rule extension p. 30
6.2.5.4 ADC rule extension p. 30
6.2.5.5 Termination Action p. 30
6.2.5.6 Functional description p. 30
6.2.5.7 Impacts on existing nodes or functionality p. 31
6.2.6 Alternative solution 6: Returning the dropped packet p. 31
6.3 Solutions for Scenario 3: Both service data flow charging and application usage charging is required per IP-CAN session p. 32
6.3.1 Alternative solution 1: sdf transfer p. 32
6.3.1.1 Solutions' assumptions p. 32
6.3.1.2 Reference architecture p. 32
6.3.1.3 Application Detection and Control Rule extension p. 33
6.3.1.4 Credit management p. 33
6.3.1.5 Termination Action p. 33
6.3.1.5a Reporting p. 33
6.3.1.6 Functional Description p. 33
6.3.1.7 Impacts on existing nodes or functionality p. 35
6.3.2 Alternative solution 2: Sy extension p. 37
6.3.2.1 Solutions' assumptions p. 37
6.3.2.2 Reference architecture p. 37
6.3.2.3 Reporting, Credit management and termination action p. 37
6.3.2.4 Functional description p. 38
6.3.2.5 Impacts on existing nodes or functionality p. 38
6.3.3 Alternative solution 3: Correlation by OCS p. 38
6.3.3.1 Solutions' assumptions p. 38
6.3.3.2 Reference architecture, ADC Rule extension, Reporting, Credit management, Termination action p. 38
6.3.3.3 Functional description p. 38
6.3.3.4 Impacts on existing nodes or functionality p. 39
6.3.4 Alternative solution 4: TDF marking and PCEF based application charging p. 39
6.3.4.1 Solutions' assumptions p. 39
6.3.4.2 Reference architecture, Reporting, Credit management, Termination action p. 39
6.3.4.3 Functional description p. 39
6.3.4.4 Impacts on existing nodes or functionality p. 39
6.3.5 Alternative solution 5: Bi-Directional Marking of Charged Packets p. 39
6.3.5.1 Solution assumptions p. 39
6.3.5.2 Reference architecture, ADC Rule extension, Reporting, Credit management, Termination action p. 40
6.3.5.3 Functional description p. 40
6.3.5.4 Example Call Flow for Scenario 3 p. 42
6.3.5.5 Maintaining Synchronisation between Refunds p. 43
6.3.5.6 Rule Prioritization, Double Charging and Redirections p. 44
6.3.5.7 Static and Dynamic Correlation Between Charging Key and Packet Marking p. 44
6.3.5.8 Mechanisms of Packet Marking p. 45
6.3.5.9 Impacts on existing nodes or functionality p. 45
6.3.6 Alternative solution 6: TDF TFT analysis p. 45
6.3.6.1 Solutions' assumptions p. 45
6.3.6.2 Reference architecture p. 45
6.3.6.3 PCC rule extension p. 46
6.3.6.4 ADC rule extension p. 46
6.3.6.5 Termination Action p. 46
6.3.6.6 Functional description p. 47
6.3.6.6.1 Usage Report p. 47
6.3.6.7 Impacts on existing nodes or functionality p. 48
6.3.7 Alternative solution 7: Returning the dropped packet p. 48
7 Evaluation p. 51
7.1 Initial analysis of the solutions per traffic handling cases p. 51
7.2 Required modifications and major points per each one of the proposed solutions p. 51
8 Conclusions p. 52
A Application Based Charging for the applications with deducible service data flows (as supported in Rel-11) p. 54
B Packet Marking Mechanisms p. 55
B.1 DSCP p. 55
B.1.1 Description p. 55
B.1.2 Discussion p. 55
B.2 Packet Tunnelling DSCP Field p. 55
B.2.1 Description p. 55
B.2.2 Discussion p. 56
B.3 IPv6 Extension Headers p. 56
B.3.1 Description p. 56
B.3.2 Discussion p. 56
B.4 Flow Labels (IPv6) p. 56
B.4.1 Description p. 56
B.4.2 Discussion p. 56
B.5 VLAN Tagging p. 57
B.5.1 Description p. 57
B.5.2 Discussion p. 57
B.6 GRE p. 57
B.6.1 Description p. 57
B.6.2 Discussion p. 57
B.7 GTP-U p. 58
B.7.1 Description p. 58
B.7.2 Discussion p. 58
B.8 Comparison of Packet Marking Mechanisms p. 59
$ Change history p. 60
