Thanks for the reply. I agree that we need to align all of these APIs.
I think that from the "current" TMF perspective, the meters/balances of aggregated usage (with their thresholds and events), aka. 3GPP counters, are not the same as the buckets/allowance (UsageVolumeProduct) nor the ProductUsage(s). TMF677 Usage Consumption has the concept of bucket counters (ConsumptionSummary) that could be used to support the meters/balances you mention. ConsumptionSummary contains a counterType (similar to 3GPP Counter AVP/JSON object). I imagine we would need to perhaps extend the TMF654 Bucket Management API to allow us to manage these bucket counters too somehow.
Original Message:
Sent: Jun 14, 2024 03:41
From: Elisabeth Andersson
Subject: Balance Management using TMF666 and TMF654
Hej Dan!
A very good question and one that I am pondering as well.
TMF654, TMF677 as well as the TMF635 or its replacements /resource/Service/Product) need to evolve together as I see it to solve for the individual usage, the consumption of buckets, the buckets themselves, and the application to products.
TMF654 can be queried to get the remaining balance to see what is left.
TMF677 can be queried to get the consumption and the related usage. In TMF677 it should also be possible to provide an aggregated view of consumption of buckets of the same type.
In a way it is looking at it from two perspectives - one to manage the balance and the other to be able to account for the use of a balance by accumulating what has been consuming it and relating it back to its source.
TMF677 is more created with a self-service/customer care use case in mind to display data in various levels.
One thing that I am still missing is that it is not uncommon to use balances or meters to be able to display the consumption of a balance not necessarily tied to traditional bucket. I am not clear if we mean to use the balance/buckets for all of these or is limited to traditional "prepay" buckets, if so then TMF677 will serve to be able to also show the consumption on that level. But if that is not the case, then we have a missing part. Here is the example:
- A product may be specified with tiered rating with different prices for the different tiers - say 0-100 minutes 50 cents, 101-200 40 Cents, and 201 and above 10 cents.
- From a self service perspective the expectation is to give the user transparency by providing them the information on how they are doing and what tier that is applied
- From a TMF perspective, do we see these as balances?
- If yes, then TMF654 would be able to maintain the balance and TMF677 would be able to provide the consumption details.
Any OCS and CCS does not only maintain traditional buckets to do its work, as part of product configuration, meters and balances are used to be able to fulfill the product and to be able to provide aggregated information upon request by up stream systems.
------------------------------
Elisabeth Andersson
MATRIXX Software
Original Message:
Sent: Jun 13, 2024 04:20
From: Dan d'Albuquerque
Subject: Balance Management using TMF666 and TMF654
I can see that there has been ongoing work by the ODA and API teams in relation to product/service/resource usage management components (plus Service Balance Management) and, in relation to mobile network usage, integrating this with the 4G/5G Converged Charging Systems (OCS/CCS) as described in TMFS009 Usage and Balance Managament v5.1.0.
As part of this investigation, it appears that the previous TMF654 Prepay Balance Management API has/will be renamed to TMF654 Bucket Management API in order to support both prepaid/postpaid subscription types. If my understanding is correct, it seems that this API will be used to manage the buckets/counters in the core network (OCS/CCS) based on the use cases described in TMF654 (alongside the OCS/CCS updating these buckets/counters based on real-time usages).
TMF654 also provides the ability to query the balances of these buckets/counters and provide aggregated balances too.
My question is, how does TMF677 Usage Consumption Management fit alongside this evolution of the TMF654 Bucket Management API? There now appears to be some overlap between these two APIs.
------------------------------
Dan d'Albuquerque
Individual
Original Message:
Sent: Feb 07, 2023 10:07
From: Paul Jardine
Subject: Balance Management using TMF666 and TMF654
Hi,
I agree this is an interesting thread and discusses one of several examples in the TMF standards where it appears that the correct level of abstraction has not been done. To have an API with "Prepaid" in the title is highly suspect, as it just describes a behaviour. i.e. we have an account but it is of type "Prepaid" or "Postpaid" or "Loyalty" (see the highly specific APIs for Loyalty TMF658 - which may be deprecated?). I don't agree with any of these specific APIs unless they are providing a wrapper for a general "Account Management" case, but there are still many examples of this telco-centricity in TMF. The TMF654 gives mainly useful operations on the account/balance entity, but the naming is very wrong.
------------------------------
Paul Jardine
Saudi Telecom Company
Original Message:
Sent: Jan 05, 2022 17:09
From: Eduardo Lo Presti
Subject: Balance Management using TMF666 and TMF654
Hi!
I found this interesting thread while searching for "postpaid balance", and I'd like to come back to the original question that was not answered: Is TMF654 applicable for both prepaid and postpaid balances ?
Best regards,
Eduardo
------------------------------
Eduardo Lo Presti
Telecom Argentina, S.A.
Original Message:
Sent: Jun 22, 2021 06:56
From: Shashidhar Misra
Subject: Balance Management using TMF666 and TMF654
Hi @Jonathan Goldberg
TMF666 also talks about prepaid real-time bill as well. I am assuming that there will not be any difference between a prepaid or a postpaid real-time bill. Both the bills should derive the accountBalance of that user after considering the current and active usages for that billing cycle. If that is the case then the current balance of a prepaid account should be derived after deducting the balances for the usages which the user has already done as well as the balances reserved for any ongoing session. This brings us back to the orignal question posted by @Ben Eng i.e. Is TMF654 applicable for both prepaid and postpaid balances ?
------------------------------
Shashidhar Misra
Oracle Corporation
Original Message:
Sent: May 25, 2021 08:30
From: Nitin Patil
Subject: Balance Management using TMF666 and TMF654
Hi Mukesh,
The AppliedCustomerBillingRate gets created by the billing system based on the order and pricing information. As you already stated there is only GET API for it in the TMF model, these are computed resources and are computed by the billing system based on order information and price information.
------------------------------
-----------------------------------------------------
Nitin Patil
Portfolio Architect BSS + B2B
Amdocs India Limited
Any opinions and statements made by me on this forum are purely personal, and do not necessarily reflect the position of the TM Forum or my employer
Original Message:
Sent: May 25, 2021 03:49
From: Mukesh Kumar
Subject: Balance Management using TMF666 and TMF654
Thanks for the response. In the spec, there are only GET operations support for appliedBillingRateType resource. Can you please confirm if I'm missing something?
Regards
Mukesh
------------------------------
Mukesh Kumar
Oracle Corporation
Original Message:
Sent: May 24, 2021 08:09
From: Nitin Patil
Subject: Balance Management using TMF666 and TMF654
Hi Mukesh,
In AppliedCustomerBillingRate of any appliedBillingRateType (appliedBillingCharge, appliedBillingCredit, appliedPenaltyCharge) are the capturing the Credits and Debits. They are all part of a CustomerBill which is associated with a BillingAccount.
thanks,
Nitin Patil
------------------------------
-----------------------------------------------------
Nitin Patil
Portfolio Architect BSS + B2B
Amdocs India Limited
Any opinions and statements made by me on this forum are purely personal, and do not necessarily reflect the position of the TM Forum or my employer
Original Message:
Sent: May 24, 2021 07:20
From: Mukesh Kumar
Subject: Balance Management using TMF666 and TMF654
Hi Nitin
I agree that accountBalance should be a computed/derived value and is intended to give a high level view of user's balances. While the examples provided in the spec seem to suggest that it is relevant for Postpaid, I think the same can also be used to show Prepaid balances as well. Can you please clarify the reference to TMF 678 though? Which operations in 678 enable editing credits/debits?
@Jonathan Goldberg
My observation is that though TMF 654 says 'Prepaid', the concepts seem to apply for Postpaid as well. For eg. a 5 GB prepaid data grant and a 5GB data usage quota in a Postpaid pack, they would both be handled via buckets as in both the cases, we need to continuously check if the balance/quota is depleted yet or not. The implementations could be different but the concepts would be same. If not via TMF 654, is there another API which could provide guidance on how the Postpaid services should be modeled?
Hope I'm making sense.
------------------------------
Mukesh Kumar
Oracle Corporation
Original Message:
Sent: May 24, 2021 03:58
From: Nitin Patil
Subject: Balance Management using TMF666 and TMF654
The accountBalance is a complex attribute, in my view it is a computed/deduced attribute.
Let me try to explain what I mean by that.
- Credits / Debits on an account impact the account balance.
- Debits are a result of Charge / Fees / Reversals or anything that were part of the CustomerBill.
- The Credit are a result of Payment, Manual Credits, Discounts etc. These are part of Payment subdomain.
- we should have one of the two editable (Credits & Debits) OR Balance and not BOTH
- Credits / Debits are editable under TMF 678 and 666
- balance can be deduced from that and need not be updated directly. If we edit balance directly it will not reconcile with the credits / debits associated with that billing account as they cannot be compute back in a reverse way.
Therefore, I think we should not make accountBalance editable directly from the API level.
I agree we currently do not have a financial services domain where all of these capabilities need to be enabled from, we need to work on developing such an domain in TMF. With that balance will become editable by not editing it directly but by registering/submitting a new debit or a credit towards an financial account. Thus balance will get updated but by deducing the financial impact of a debit or a credit rather than a direct edit.
------------------------------
-----------------------------------------------------
Nitin Patil
Portfolio Architect BSS + B2B
Amdocs India Limited
Any opinions and statements made by me on this forum are purely personal, and do not necessarily reflect the position of the TM Forum or my employer
Original Message:
Sent: May 22, 2021 14:41
From: Jonathan Goldberg
Subject: Balance Management using TMF666 and TMF654
Hi Ben
To the best of my knowledge, and subject to correction by other community members, the balances on account in TMF666 are post-paid, as distinct from the prepaid buckets in TMF654.
We have an open JIRA about the non-patchability of balance in TMF666, hopefully that will be corrected sometime.
Our tooling for generating API user guides (specs) includes the possibility of validating the examples against the schema. If applied properly this should ensure that the examples will be correct and that balances should include the amount and the units of measure (currency).
Hope it helps.
------------------------------
Jonathan Goldberg
Amdocs Management Limited
Any opinions and statements made by me on this forum are purely personal, and do not necessarily reflect the position of the TM Forum or my employer.
Original Message:
Sent: May 22, 2021 11:54
From: Ben Eng
Subject: Balance Management using TMF666 and TMF654
I'm trying to understand how balances are updated as charges are posted or payments are posted to an account. Looking at Account Balance in TMF666, it only defines PATCH methods for updating, but accountBalance is explicitly not patchable. There are no PUT methods, and there are no task resources to update accountBalance atomically. Meanwhile, TMF654 defines a comprehensible set of task resources for updating balances, but the API name suggests it is intended for prepay balance management to the exclusion of postpay services.
This raises two questions.
(1) Is TMF654 used for both prepay and postpay services to update balances?
(2) Is there an implicit relationship between TMF654 and the Account Balance on the accounts in TMF666, so that as the task resources on TMF654 are posted, the account balances on the accounts are updated implicitly?
Moreover, TMF666 appears to lack some precision in how Account Balance is depicted in examples. The Account Balance sub-resource is described as having an amount of type Money. However, the examples all show account as having a numeric value without a currency. I suspect the intent is for Account Balance to be a structure that handles monetary amounts similar to TMF654, but the document needs some edits to make it more consistent. Is that the right way to think of it?
------------------------------
Ben Eng
Oracle Corporation
------------------------------