5 PoC charging principles and scenarios

32.2723GPPCharging managementPush-to-talk over Cellular (PoC) chargingRelease 17Telecommunication managementTS

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

5.0 General

PoC charging architecture support service based charging. If there is a support required for traffic based charging than the FBC should be used refer TS 32.251 [11].

Editor’s note: The investigation on subscription based charging is needed.

5.1 PoC charging principles

5.1.1 PoC session related charging

PoC allows users to satisfy real time, half-duplex speech communication in a simple and easy way.
A PoC subscriber may either join an existing PoC session or may create a PoC session spontaneously.
A PoC participant, who wants to speak, typically initiates a PoC session on its terminal and starts to speak.
Other participants of the PoC group session simultaneously listen to the speaker’s voice.

The charged parties may be any of the PoC participants, depending on the role he is taking. These roles are:

– PoC session owner;

– PoC participant.

The charging of the PoC session owner is measured by the controlling PoC function. Note that PoC session owner does not have to participate in a specific PoC session (e.g. pre-arranged PoC group session). It provides centralized charging reports. In the PoC architecture the participating PoC function measures and sends charging reports to the charging system for the charging of the participant.

Charging should be done according the following types of PoC sessions according OMA-AD-POC [203]:

– 1-1 PoC session;

– PoC group session:

– ad-hoc PoC group session;

– pre-arranged PoC group session;

– chat PoC group session.

Editor’s note: The use of PoC communication methods (single participant in a 1-1 PoC session, PoC group in a 1‑many session or in a 1-many-1 session.) is FFS.

There are two mechanisms for PoC session establishment signalling supporting as described in OMA-AD-POC [203]:

– on-demand sessions,

– pre-established sessions.

An 1-1 PoC session along with PoC group session can be established on-demand or within a pre-established session. Charging should distinguish both scenarios.

PoC user can participate in PoC session in three types according to OMA-AD-POC [203]:

– Normal;

– NW PoC Box;

– UE PoC Box.

Charging should distinguish the three scenarios above for support of traffic based charging.

The charging of the PoC participant and/or PoC session owner can be done:

for the following services:

1. PoC session participation (per time period independent of usage).

2. Talk burst sending: Amount of talk bursts sent by the participant. Amount of talk bursts shall be measured as a number of talk bursts and/or as a duration and/or volume of talk bursts.

When talk burst sending is charged as a number of talk bursts, only the TBCP talk burst granted message (in response to TBCP talk burst request message) received in PoC Client should be taken into account. Note that TBCP talk burst granted message could be lost. In this case, timer T11 expires in PoC Client and it sends a TBCP talk burst request message again OMA-UP-POC: "OMA POC User Plane" [205]. Therefore, several TBCP talk burst granted message could be unsuccessfully sent and they should not be charged. To fulfil this aim, PoC Server shall meter one talk burst:

– when it receives the first RTP media packet for this talk burst, or

– when it receives the TBCP talk burst release message, independently if the PoC Client sent RTP media toward the PoC Server when PoC Client had the floor.

3. Talk burst receiving: Amount of talk bursts received by the participant. Amount of talk bursts shall be measured as a number of talk bursts and/or as a duration and/or volume of talk bursts.

Editor’s note: Sent/Received talk burst may be independent of the talk burst control protocol messages, means the successful or unsuccessful delivery.

Editor’s note: The interruption of the PoC session with "media put on hold/off hold" is FFS.

– for the following rating parameters:

1. PoC session type as defined above;

2. number, type or list(s) of participants/talk burst receivers (see clause 5.1.3);

3. identity of the serving network (e.g. SGSN PLMN identifier for the charged party);

4. date and time of PoC service usage.

Session related PoC charging is SCUR based. Hence, number of "Right-to-Speak" and talk burst exchange shall be charged by SCUR and the metering will be performed in the PoC Server. This is an important efficiency improvement since event based talk burst charging would imply the need to generate events or CDRs for each talk burst potentially for each charged party.

The PoC Server decides whether the session owner and/or the participants are to be charged for the services, e.g. session owner is charged for session participation and each participant is charged for talk burst exchange. This decision is based on configuration in the offline case and is governed by the OCS in the online case. Units for service usage are reported independently, e.g. separate minutes for session participation and number of sent and received talk bursts.

Details how this is supported are specific to online and offline charging and will be given in the subsequent clauses.

5.1.2 PoC session unrelated charging

To reflect chargeable events not directly related to a PoC session, offline and online charging procedures have to consider the occurrence of the following session unrelated SIP procedures:

– Sending/Receiving instant personal alert. Unsuccessful message shall not be charged.

– Sending/Receiving PoC group advertisement. Unsuccessful message shall not be charged.

– PoC Client subscription to the conference state (based on a PoC group identity of the PoC group or on a PoC session identity).

– PoC Client adding a user to a PoC session.

– PoC Client adding/removing media type to/from a PoC session.

– PoC Client handling for PoC session locking in a particular PoC session (simultaneous session control): the PoC Client may request to lock itself in a particular PoC session while initiating a PoC session or at any time later when a valid PoC session exists.

– Early session setting-up.

– PoC Client handling for PoC session priority in a particular PoC session (simultaneous session control): the PoC Client may set a PoC session priority in a particular PoC session while initiating a PoC session or at any time later when a valid PoC session exists.

5.1.3 Charging based on number of participants

Charging based on number of participants is possible at both the controlling and participating PoC Servers if the information is provided by the controlling PoC Server to the participating PoC Server as defined by OMA PoC User Plane [205].

5.2 PoC offline charging scenarios

5.2.0 General

Editor’s note: < If the present document does not specify offline charging for XXX, then an appropriate reference or other explanation shall be provided (cf. scope clause), and all following subclauses shall only have the text "Void. Refer to clause 5.2". >

5.2.1 Basic principles

The charging models as given in clause 5.1are supported for offline charging. CDRs are generated for the charged parties that are configured in the PoC Server.

These CDRs contain distinguished service usage data for any of the described sub-services. They may contain only usage data related to one subscriber or may aggregate service usage. The latter case occurs e.g. in the charging model where the session owner is charged for all session participants. Accumulated or detailed talk burst usage data given in the CDRs will hold duration, volume and number of talk bursts. It is up to the Billing Domain (BD) to rate them according to selected rate plans.

Event CDRs are generated for the early session establishment and instant personal alerts delivery.

Interim and final CDRs are generated for PoC session participation and talk burst usage. The generation of interim CDRs will be governed by configurable timers at the PoC Server, changes to the session, and any changes in location of the user made known to the PoC Server.

5.2.2 Message flows

The flows described in the present document specify the charging communications between PoC Server and the charging functions for different charging scenarios. The SIP messages associated with these charging scenarios are shown primarily for general information and to illustrate the charging triggers. They are not intended to be exhaustive of all the SIP message flows discussed in TS 24.228 [202].

5.2.2.1 Message flows – Successful cases and scenarios

5.2.2.1.1 Successful PoC session establishment

Figure 5.2.2.1.1 shows the Charging Data transactions that are required between PoC Server and CDF during PoC session establishment originated by a PoC Client. The Charging Data Request triggers the first CPF-CDR sequence in the controlling PoC Server and the first PPF-CDR sequence is generated for each participant in the participating PoC Server. More CPF-CDR sequences possible for additional participants.

Figure 5.2.2.1.1: Message sequence chart for offline charging PoC session establishment

5.2.2.1.2 PoC talk burst exchange

Figure 5.2.2.1.2 shows the Charging Data transactions that are required between PoC Server and CDF during talk burst exchange.

Figure 5.2.2.1.2: Message sequence chart for offline charging PoC talk burst exchange

5.2.2.1.3 Instant personal alert

Figure 5.2.2.1.3 shows the Charging Data transactions that are required between participating PoC Server and CDF for the "Instant Personal Alert" delivery.

Figure 5.2.2.1.3: Message sequence chart for offline charging Instant personal alert

5.2.2.1.4 Pre-established session set-up

Figure 5.2.2.1.4 shows the Charging Data transactions that are required between participating PoC Server and CDF for the pre-established session with the early session indication.

Figure 5.2.2.1.4: Message sequence chart for offline charging pre-established session set-up

5.2.2.1.5 Mid PoC session procedures

Figure 5.2.2.1.5 shows the Charging Data transactions that are required between PoC Server and CDF in the Mid-PoC session when SIP INVITE or SIP BYE request are received at the PoC Server. The Charging Data Request [ Start] triggers the first CPF-CDR sequence in the Controlling PoC Server and the first PPF-CDR sequence is generated for each participant in the Participating PoC Server. When SIP INVITE or SIP BYE request are sent to controlling server, Controlling PoC Server performs service control function, to recognize if the request is a chargeable event. If so, the Controlling PoC Server sends Charging Data Request[Interim].

Figure 5.2.2.1.5: Message sequence chart for offline charging in Mid PoC session

5.2.3 CDR generation

The controlling PoC function CDR (CPF-CDR) and participating PoC function CDR (PPF-CDR) are generated by the PoC Server to collect charging information that they subsequently transfer to the Charging Gateway Function (CGF).

5.2.4 GTP’ record transfer flows

The principles and protocol applications specified in TS 32.295 [54].

5.2.5 B_T CDR file transfer

The CDR file transfer for PoC charging is supported on the B_T interface, as specified in TS 32.240 [1].
For further details on the BT protocol application refer to TS 32.297 [52].

5.3 PoC online charging scenarios

5.3.1 Basic principles

PoC online charging is done according to the general principles of Debit / Reserve Units operation as specified in TS 32.299 [50]. The PoC Server generates online charging messages that contain distinguishable service usage data for any of the sub-services.

PoC online charging utilizes one time event charging for early (pre-established) sessions (session set-up is charged only) and instant personal alerts and session charging for PoC session and PoC talk burst exchange. Thus the PoC online charging interface will address both the Session Based Charging Function (SBCF) and the Event Based Charging Function (EBCF) with the OCS. There is a general PoC service with four sub-services in the interface. Each of the sub-services has specific charging information and behaviour. The DCCA concept of multiple service credit control are supported. As described by DCCA, unused reserved units for PoC session participation are released on session termination.

Talk burst exchange is a session based service with SCUR which may be metered by duration, volume or number.
The metering is done on the PoC Server and governed in a DCCA conformal way by the OCS.
Upon charging request it returns granted units of either of the three types. Unused reserved units for talk burst exchange are released at PoC session termination or based on an inactivity timer. For number of talk burst level reporting, the service specific unit shall be used to represent individual talk bursts. For talk burst duration reporting, the time based unit shall be used. For talk burst volume reporting, the volume unit shall be used.

For an "Instant Personal Alert", which is an event unrelated to a PoC session, the PoC online charging utilizes event charging for the message including a unit reservation i.e. ECUR.

5.3.2 Diameter message flows

5.3.2.1 Successful PoC session establishment

Figure 5.3.2.1 shows the Debit / Reserve Units operation that are required between PoC Server and OCS during PoC session establishment originated by a PoC Client.

Figure 5.3.2.1: Message sequence chart for online charging PoC session establishment

Editor’s Note: Detailed message description including the handling of RSU, GSU and USU should be added.

5.3.2.2 PoC talk burst exchange

Figure 5.3.2.2 shows the Debit / Reserve Units operation that are required between PoC Server and OCS during talk burst exchange.

Figure 5.3.2.2: Message sequence chart for online charging PoC talk burst exchange

5.3.2.3 Instant personal alert

Figure 5.3.2.3 shows the Debit / Reserve Units operation that are required between participating PoC Server and OCS for the (successful) "Instant Personal Alert" delivery. Each "Instant Personal Alert" shall be treated independently

Figure 5.3.2.3: Message sequence chart for online charging Instant personal alert

NOTE: The SIP 200 OK response to the PoC Client A has been omitted from figure 5.3.2.3 but can occur at any point after the SIP 200 OK is received from PoC Client B.

For successful message delivery, the Debit Units Request[ Terminate] shall report the used quota.

For unsuccessful message delivery, determined by a response timeout or a SIP error response e.g. 4xx, the PoC Server return the quota as unused within the Debit Units Request[ Terminate].

5.3.2.4 Early session set-up

Early session set-up is a preparation process for later PoC session establishment. The required negotiations, media negotiation, bearing parameters negotiation, etc, among different PoC users are also different, which occupy different resources that PoC Server can not predict before. ECUR is referred here.

Figure 5.3.2.4 shows the charging flow between PoC Server (participating) and OCS for pre-established session (early session):

Figure 5.3.2.4: Message sequence chart for Pre-established session Set-up online charging

1. PoC Client sends SIP INVITE request to PoC Server (participating) for early session setup.

2. After receiving the request PoC Server sends Reserve Units Request[Initial] to OCS for reservation by RSU(Requested-Service-Unit).

3. The OCS performs unit reservation.

4. The OCS sends back the response to PoC Server (participating) to authorize the service request with GSU(Granted-Service-Unit)

5. PoC Server (participating) starts to initiate the early session for PoC Client.

6. When finishing early session setup PoC Server responses back the result to PoC Client.

7. Also PoC Server (participating) sends Debit Units Request[Terminate] to OCS by USU(Used-Service-Unit) to indicate resource usage and result of early session setup.

8. OCS performs debit.

9. OCS sends back CCA to PoC Server (participanting) to indicate charging control result.

5.3.2.5 Participant number based charging

Figure 5.3.2.5 shows the Debit / Reserve Units operation that are required between Controlling PoC Server and OCS in participant number based charging for the session owner.

Figure 5.3.2.5: Message sequence chart for offline charging in Mid PoC session

1. PoC Client sends SIP INVITE request to controlling PoC Server to generate a multi-participants session.

2. Controlling PoC Server sends Reserve Units Request[Initial] to OCS, with the pre-defined group participant number for quota reservation. In case of the Ad-hoc session, Controlling PoC Server sends Reserve Units Request[Initial] for quota reservation, with initial invited participant number.

3. OCS performs Quota reservation.

4. OCS responses the CCA with enabling trigger condition of CHANGE_IN_PARTICIPANTS_NMB or CHANGE_IN_ THRSHLD_OF_PARTICIPANTS_NMB.

5. Controlling PoC Server forward the SIP INVITE request to participants.

6. During the session ongoing, participant can send SIP BYE or SIP 200 OK to Participating PoC Server.

7. Participating PoC Server forwards the message to Controlling PoC Server.

8. Controlling PoC Server monitors the trigger conditions, if one of the conditions occurs, it goes to next procedure.

9. Controlling PoC Server sends update request, with the changed Rating Group.

10. OCS performs re-authorization.

11. OCS sends CCA to Controlling PoC Server.

5.3.2.6 Participating type based charging

Figure 5.3.2.6 shows the Debit / Reserve Units operation that are required between Controlling PoC Server and OCS in participant type based charging for the session owner and participants.

10. CCR[Update]

12. CCA

PoC Server

8. INVITE

1. INVITE

2. CCR[Initial]

4. CCA

5. INVITE

OCS

PoC Box

6. 200 OK

11. Quota Reservation

3. Quota Reservation

9. Service Control

13. INVITE

14. 200 OK

7. PoC Session Start

15. PoC Session continue with PoC Box

Figure 5.3.2.6: Message sequence chart for online charging Participating type

1. PoC Server receives SIP INVITE.

2. PoC Server sends Reserve Units Request[Initial] to OCS.

3. OCS performs Quota reservation.

4. OCS responses the CCA with enabling trigger condition of CHANGE_IN_USER_PARTICIPATING_TYPE.

5. PoC Server forwards the SIP INVITE request to participants.

6. PoC Server receives the SIP 200 OK for SIP INVITE.

7. PoC session start.

8. During the session ongoing, participant can send SIP INVITE to PoC Server to invite PoC Box.

9. Controlling PoC Server monitors the trigger conditions, if one of the conditions occurs, it goes to next procedure.

10. PoC Server sends Reserve Units Request [Update] request, with the changed Rating Group.

11. OCS performs re-authorization.

12. OCS sends CCA to PoC Server.

13. PoC Server forwards SIP INVITE to PoC Box.

14. PoC Box response to PoC Server with SIP 200 OK.

15. PoC session continues.