TR 28.826
Study on Nchf charging services Phase 2 improvements and optimizations
V18.0.0 (Wzip)
2023/12 62 p.
- Rapporteur:
- Mr. Törnkvist, Robert
Ericsson LM
full Table of Contents for TR 28.826 Word version: 18.0.0
1 Scope
2 References
3 Definitions of terms, symbols and abbreviations
4 Overview
5 Charging scenarios and key issues
6 Documentation improvements
7 Conclusions and recommendations
$ Change history
1 Scope p. 8
The present document studies the potential use cases, requirements, and solutions for the enhancements of the Nchf converge charging service.
The study will cover and identify gaps for:
- optimizations regarding amount of information in the request and number of requests;
- enhancement of input to rating;
- cancelling of chargeable events for unsuccessful scenarios;
- enhancement of non-blocking mechanism;
- enhancements of triggers having more consistent triggers and use of NF specific triggers.
2 References p. 8
The following documents contain provisions which, through reference in this text, constitute provisions of the present document.
- References are either specific (identified by date of publication, edition number, version number, etc.) or non-specific.
- For a specific reference, subsequent revisions do not apply.
- For a non-specific reference, the latest version applies. In the case of a reference to a 3GPP document (including a GSM document), a non-specific reference implicitly refers to the latest version of that document in the same Release as the present document.
[1]
TR 21.905: "Vocabulary for 3GPP Specifications".
[2]
TS 32.255: "5G data connectivity domain charging; stage 2".
[3]
TS 23.503: "Policy and charging control framework for the 5G System (5GS); Stage 2".
[4]
TS 29.500: "5G System; Technical Realization of Service Based Architecture; Stage 3".
[5]
TS 32.240: "Telecommunication management; Charging management; Charging architecture and principles".
[6]
TS 32.291: "Telecommunication management; Charging management; 5G system; Charging service, stage 3".
[7]
TS 32.298: "Telecommunication management; Charging management; Charging Data Record (CDR) parameter description".
[8]
TS 32.299: "Telecommunication management; Charging management; Diameter charging application".
[9]
TS 23.501: "3GPP TS 23.501:"System Architecture for the 5G System".
[10]
TS 23.203: "Policy and charging control architecture".
[11]
TS 29.594: "5G System; Spending Limit Control Service; Stage 3".
[12]
TS 32.290: "Telecommunication management; Charging management; 5G system; Services, operations and procedures of charging using Service Based Interface (SBI)".
[13]
RFC 4006 (2005): "Diameter Credit-Control Application".
[14]
RFC 8506 (2019): "Diameter Credit-Control Application".
[15]
TS 29.513: "5G System; Policy and Charging Control signalling flows and QoS parameter mapping; Stage 3".
[16]
TS 29.594: "5G System; Spending Limit Control Service; Stage 3".
[17]
TS 32.254: "Telecommunication management; Charging management; Exposure function Northbound Application Program Interfaces (APIs) charging".
[18]
TS 32.256: "Telecommunication management; Charging management; 5G Data connectivity domain charging; stage 2".
[19]
TS 29.244: "Technical Specification Group Core Network and Terminals; Interface between the Control Plane and the User Plane Nodes; Stage 3".
[20]
TS 29.591: "5G System; Network Exposure Function Southbound Services; Stage 3".
[21]
TS 29.541: "5G System; Network Exposure (NE) function services for Non-IP Data Delivery (NIDD) and Short Message Services (SMS); Stage 3".
[22]
TS 29.542: "5G System; Session management services for Non-IP Data Delivery (NIDD); Stage 3".
[23]
TS 38.300: "NR; NR and NG-RAN Overall description; Stage-2".
[24]
TS 32.251: "Telecommunication management; Charging management; Packet Switched (PS) domain charging".
3 Definitions of terms, symbols and abbreviations p. 9
3.1 Terms p. 9
For the purposes of the present document, the terms given in TR 21.905 and the following apply. A term defined in the present document takes precedence over the definition of the same term, if any, in TR 21.905.
3.2 Symbols p. 9
Void.
3.3 Abbreviations p. 9
4 Overview p. 9
The Nchf converged charging services was first released in Rel-15. This first iteration was to a large extent, with some minor exceptions, copying and combining its predecessors, Ro and Rf, based on Diameter to a Service Based Interface (SBI) supporting converged charging service. The depiction of the internal architecture of the Converged Charging System (CCS) was to a large extent based on the Online Charging System (OCS).
The combination of the Diameter Ro and Rf interfaces into one converged charging service together with the move of the integration point for CDRs have led to that all the information previously reported and transported over two or more interfaces now needs to be transported over a single interface. This makes it essential that the converged charging interface is optimized in regard to the amount of information and number of reports sent, or at least allows for such an optimization if needed.
The information that may be used to assist the determine of reservation in the CCS is not defined except for the rating group. This means that for an immediate event or in an initial request the information about the event or session is limited and lacks accuracy.
Low latency requirements increased by new business cases may need enhancements to the non-blocking mechanism.
Charging of new service together with converged charging have increased the need for more information in the input to rating.
The use of event-based charging has led to a need for cancelling the charging for the chargeable event, e.g. refund, for unsuccessful scenarios or cases not possible to fulfil.
The document structure of the actual service, i.e. yaml, followed the handling of Ro and Rf, based on Diameter, which may need improvements.
5 Charging scenarios and key issues p. 10
5.1 Charging information optimization p. 10
5.1.1 General p. 10
5.1.2 Use cases p. 10
5.1.2.1 Use Case #1a: Trigger without usage p. 10
5.1.2.2 Use Case #1b: Size of charging information p. 11
5.1.2.3 Use Case #1c: Charging Data Request Optimization p. 11
5.1.2.4 Use Case #1d: Undefined CDR attributes and attribute values p. 11
5.1.2.5 Use Case #1e: Charging information accuracy of location p. 12
5.1.2.6 Use Case #1f: Bitrate charging p. 12
5.1.2.7 Use Case #1g: Charging information for threshold based re-authorization triggers p. 12
5.1.3 Potential charging requirements p. 12
5.1.4 Key issues p. 12
5.1.5 Solutions p. 13
5.1.5.1 Solution #1.1: New immediate trigger variant p. 13
5.1.5.2 Solution #1.2: Keep rating group information together p. 16
5.1.5.3 Solution #1.3: NF consumer ensuring accuracy of location p. 16
5.1.5.4 Solution #1.4: Stop and discard the used units during re-authorization p. 16
5.1.5.5 Solution #1.5: Stop and report the used units during re-authorization p. 16
5.1.5.6 Solution #1.6: CHF control of granted quota during re-authorization p. 17
5.1.5.7 Solution #1.7: Continue and report the used units during re-authorization p. 17
5.1.5.8 Solution #1.8: CHF control of ChargingInformationData size p. 17
5.1.5.9 Solution #1.9: CHF control of chargingdata size p. 18
5.1.5.10 Solution #1.10: Bitrate Charging supported by SMF p. 19
5.1.5.11 Solution #1.11 New attribute on all levels of the CDR structure p. 20
5.1.5.12 Solution #1.12 New attribute in the ChargingRecord, using sequence number for multiple attributes p. 21
5.1.5.13 Solution #1.13 New attribute in the ChargingRecord, using hash value for multiple attributes p. 22
5.1.5.14 Solution #1.14: NF consumer reporting accuracy of location p. 23
5.1.5.15 Solution #1.15: IoT Charging information Optimization p. 24
5.1.5.16 Solution #1.16: Without addition of undefined CDR parameters p. 25
5.1.5.17 Solution #1.17: Vendor special for undefined CDR parameters p. 25
5.1.5.18 Solution #1.18: Introduce a container reference p. 25
5.1.5.19 Solution #1.19: IoT NEF charging information optimization p. 26
5.1.5.20 Solution #1.20: Reserve a range of special numbers for undefined values p. 28
5.1.5.21 Solution #1.21: Bitrate charging supported by CHF p. 28
5.1.5.22 Solution #1.22: Bitrate charging using volume and time measurement p. 30
5.1.6 Evaluation p. 31
5.1.7 Conclusions p. 32
5.2 Charging request optimization p. 32
5.2.1 General p. 32
5.2.2 Use cases p. 32
5.2.2.1 Use Case #2a: Operator defined trigger p. 32
5.2.2.2 Use Case #2b: Trigger handling for IEC and PEC p. 33
5.2.3 Potential charging requirements p. 33
5.2.4 Key issues p. 33
5.2.5 Solutions p. 33
5.2.5.1 Solution #2.1: Reuse of management intervention trigger p. 33
5.2.5.2 Solution #2.2: New operator defined trigger p. 33
5.2.5.3 Solution #2.3: Introduce a trigger profile p. 33
5.2.6 Evaluation p. 35
5.2.7 Conclusions p. 35
5.3 Rating input enhancement p. 36
5.3.1 General p. 36
5.3.2 Use cases p. 36
5.3.2.1 Use Case #3a: Enhancement of input to CHF rating p. 36
5.3.2.2 Use Case #3b: Service Charging Enhancement p. 36
5.3.2.3 Use Case #3c: Switching between online and offline p. 36
5.3.3 Potential charging requirements p. 38
5.3.4 Key issues p. 38
5.3.5 Solutions p. 39
5.3.5.1 Solution #3.1: Enhancement of multiple unit usage with service identifier p. 39
5.3.5.2 Solution #3.2: Enhancement of requested unit with service identifier p. 39
5.3.5.3 Solution #3.3: The QoS information in RSU as the input for CHF rating p. 40
5.3.5.4 Solution #3.4: The Additional Information in RSU as the input for CHF rating p. 41
5.3.6 Evaluation p. 41
5.3.7 Conclusions p. 42
5.4 Chargeable events and sessions cancelling p. 42
5.4.1 General p. 42
5.4.2 Use cases p. 42
5.4.3 Potential charging requirements p. 42
5.4.4 Key issues p. 42
5.4.5 Solutions p. 42
5.4.5.1 Solutions #4.1: Cancelling using cancel operation and charging session identifier p. 42
5.4.5.2 Solutions #4.2: Cancelling using a reference identifier for Charging Event p. 43
5.4.5.3 Solutions #4.3: Cancelling CREATE operation and cancal event type and charging session identifier p. 44
5.4.6 Evaluation p. 45
5.4.7 Conclusions p. 45
5.5 Non-blocking mechanism enhancement p. 45
5.5.1 General p. 45
5.5.2 Use cases p. 45
5.5.3 Potential charging requirements p. 46
5.5.4 The key issues p. 46
5.5.5 Solutions p. 46
5.5.5.1 Solution #5.1: Dedicated non-blocking indicator at service start p. 46
5.5.5.2 Solution #5.2: The non-blocking mode change from CHF to SMF p. 47
5.5.5.3 Solution #5.3: The non-blocking mode change from CHF to PCF via SMF p. 47
5.5.5.4 Solution #5.4: The non-blocking mode change per UE from CHF to PCF p. 48
5.5.5.5 Solution #5.5: Dedicated non-blocking indicator before service start p. 49
5.5.5.6 Solution #5.6: The Non-blocking mode change using policy counters from CHF to PCF p. 49
5.5.6 Evaluation p. 50
5.5.7 Conclusions p. 50
6 Documentation improvements p. 51
6.1 General p. 51
6.2 Use cases p. 52
6.2.1 Use Case # 6a: The binding description p. 52
6.2.2 Use Case # 6b: The simplification of CDR records p. 53
6.2.3 Use Case # 6c: Common IEs applied in the service charging specifications p. 53
6.3 Key issues p. 53
6.4 Solutions p. 53
6.4.1 Solution #6.1: Binding in stage2 documents p. 53
6.4.2 Solution #6.2: Binding in TS 32.298 p. 53
6.4.3 Solution #6.3: Binding in TS 32.291 and TS 32.298 p. 53
6.4.4 Solution #6.4: Separate the CHF CDR record in new TS p. 54
6.4.5 Solution #6.5: Complete the Common IE applied p. 54
6.4.6 Solution #6.6: Partial the Common IE applied p. 55
6.4.7 Solution #6.7: Binding in TS 32.291 p. 57
6.4.8 Solution #6.8: Binding in new TS p. 57
6.4.9 Solution #6.9: Separate the CHF CDR record in TS 32.298 p. 57
6.4.10 Solution #6.10: Only Applicable Common IEs p. 57
6.5 Evaluation p. 58
6.6 Conclusion p. 59
7 Conclusions and recommendations p. 59
$ Change history p. 60
