Mechanism to support establishment of charging policies

Group Name: WG2-ARCSource: InterDigitalMeeting Date: TP8Agenda Item:

Charging Requirements from the Requirement TS (1/3)

CHG-001 The M2M System shall support collection of charging specific information related to the individual services facilitated by the M2M System (e.g. Data Management, Device Management and/or Connectivity Management). Collection of charging specific information shall be possible concurrent with the resource usage. The format of the recorded information shall be fully specified including mandatory and optional elements.

CHG-002 The M2M System shall support mechanisms to facilitate correlation of charging information (e.g. of a User) collected for M2M Services, M2M Application Services and services provided by underlying network operators.

Ref: oneM2M-TS-0002-V-0.6.2 oneM2M Requirements Technical Specification

CHG-003 The M2M System shall provide means to coordinate charging data records for data usages with differentiated QoS from the Underlying Network.

CHG-004 The M2M System shall be able to reuse existing charging mechanisms of Underlying Networks.

CHG-005 The M2M System shall support transfer of the charging information records to the Billing Domain of the M2M Service Provider, for the purpose of:•subscriber billing •inter-provider billing•provider-to-subscriber accounting including additional functions like statistics.

Charging Requirements from the Requirement TS (2/3)

Charging Requirements from the Requirement TS (3/3)

CHG-006 The M2M System should support generation of charging events for the purpose of requesting resource usage authorization from the real time credit control system where the subscriber account is located. The information contained in the charging events and the relevant chargeable events shall be fully specified including mandatory and optional elements.Note: A chargeable event is any activity, a provider may want to charge for that utilizes the resources and related M2M Services offered by such provider. A charging event is the set of charging information needed by the credit control system for resource authorization.

Key Aspects on Service Layer Charging • Objectives

– Support user subscription based charging– Support re-using of charging functions in underlying networks (e.g. 3GPP

charging)– Support charging of legacy applications– Support new charging scenarios based on new services– Support easy configuration of future charging scenarios

• Considerations– How can oneM2M introduce and support traditional and new charging model– Which stake-holder(s) can charge others? – Which stake-holder(s) will be charged– What scenarios will be chargeable

• Note that this slide package only addresses the mechanisms on establishing charging policies; It does not intend to cover other aspects, such as the format of charging records, coordination with underlying network charging, etc.

Some Examples of Charging Scenarios

• Service subscription based: service provider (SP) changes service subscribers, e.g. monthly fee

• Data operation based: e.g. 1) owner of the data charges the entities that use the data 2) SP charges the owner of the data for storing data on the service platform, and/or share charges to the entities that use the data

• Service session based: SP charges based on each service session• Service based: SP charges based on a service, and a service can

contain multiple operations

• There can be many more scenarios• Therefore the service layer SCA CSF needs to have the mechanism

to define charging policies and support different charging scenarios

3GPP Terms• Charging

– function within the telecommunications network and the associated OCS/BD components whereby information related to a chargeable event is collected, formatted, transferred and evaluated in order to make it possible to determine usage for which the charged party may be billed (offline charging) or the subscriber’s account balance may be debited (online charging).

• Accounting– process of apportioning charges between the Home Environment, Serving Network and

Subscriber• Billing

– function whereby CDRs generated by the charging function(s) are transformed into bills requiring payment

• Charging Data Record (CDR)– formatted collection of information about a chargeable event (e.g. time of call set-up,

duration of the call, amount of data transferred, etc) for use in billing and accounting. For each party to be charged for parts of or all charges of a chargeable event a separate CDR shall be generated, i.e. more than one CDR may be generated for a single chargeable event, e.g. because of its long duration, or because more than one charged party is to be charged

3GPP TS 32.240 Charging architecture and principles

oneM2M Terms• Re-use 3GPP concepts; Note that these terms are defined

to facilitate following discussions; • Service Charging and Accounting (SCA)

– A set of functionalities within the oneM2M service layer that enable configuration of policies, collection of Charging Records based on the policy, and correlate Charging Records to M2M users

• Service Charging Record (SCR)– formatted collection of information about a chargeable

operation for use in billing and accounting • Billing

– A set of functionalities where Service Charging Records generated by the charging function(s) are transformed into bills requiring payment

SCA in oneM2M Architecture

Charging Triggering Function: capture chargeable operations

Charging Management Function: manage charging policy

Two Resource Types Associated with SCA• <chargingPolicy>: – defines chargeable events, subscriber based

charging, etc.

• <chargingRule>: – entities take the <chargingPolicy> and define a

specific charging scenario, such as who will charge whom, based on what policy

Relationship of Charging Policy and Charging Rules

Example 1: Subscriber-Based Charging with only Infrastructure Node

Example 1: use of resources

<chargingPolicySCA1><chargingPolicySCA1>

subscriberBasedsubscriberBased E.g. subscriberBased policy is set to “ON”

E.g. SCA1AE1-rule1

E.g. ID of SCA1

E.g. ID of AE1

E.g. ACTIVE

E.g. OFFLINE

E.g. Subscriber-Based

E.g.M2M-Sub-ID for AE1

<chargingRuleAE1><chargingRuleAE1>

originatorIDoriginatorID

receiverIDreceiverID

chargingTypechargingType

chargingRuleIDchargingRuleID

ruleStatusruleStatus

chargingModelchargingModel

subscriberIDsubscriberID

collectPeriodcollectPeriod E.g.per month

Example 2: Event-Based Charging with involvement of MN

Example 2: use of resources

E.g. SCA2AE2-rule1

E.g. ID of AE2

E.g. ID of AE1

E.g. ACTIVE

E.g. OFFLINE

E.g. Event-Based

E.g.M2M-Sub-ID for AE1

<chargingRuleAE2><chargingRuleAE2>

originatorIDoriginatorID

receiverIDreceiverID

chargingTypechargingType

chargingRuleIDchargingRuleID

ruleStatusruleStatus

chargingModelchargingModel

subscriberIDsubscriberID

<chargingPolicySCA1><chargingPolicySCA1>

<chargeableEventReadData>

<chargeableEventReadData>

<chargeableEventReadData><chargeableEventReadData>

chargeableEventIDchargeableEventID

eventTypeeventType

transactionTypetransactionType

E.g. chargeableEvent1

E.g. data operation

E.g. RETRIEVE

Discussions and Conclusions

• Discuss and reach consensus on the proposed mechanisms that enable establishment of charging policy and charging rules

• Next steps: – Enhance with more policies– Specify Service Charging Record– Define relationship with underlying networks– Other enhancement to build a complete charging

and accounting service