Open APIs

 View Only
  • 1.  TMF 635 Usage Management vs TMF 677 Usage Consumption API

    TM Forum Member
    Posted Oct 14, 2024 13:21

    Hi All,

    I am looking for some comments/insights on the usage of TMF 677 Usage Consumption vs TMF 635 Usage Management API usage for Broadband session history details use case. We want to fetch the Broadband session history details from RADIUS server and translate to a TMF API through middleware. When looked at both the API docs, TMF 677 directs towards usage consumption from a bucket i.e. consumption of 3GB out of 5GB data and TMF 635 is more generic in terms of getting the usage details. When talk about Broadband session/connection history details, its getting info like session date/time, session length, Upstream/Downstream bytes along with static info like IP Address, Circuit ID etc . Could you please advise on the right TMF API for the use case ?

    Regards,

    Suresh 



    ------------------------------
    Suresh Barman
    Vodafone UK Ltd
    ------------------------------


  • 2.  RE: TMF 635 Usage Management vs TMF 677 Usage Consumption API

    TM Forum Member
    Posted 30 days ago

    Hi Suresh, 

    TMF635 provides the usage details and the characteristics of the usage on detail level. On the Usage resource you can specify 0 or many UsageCharacteristics in a value pair. In here you can specify the details as per what you listed above. Now to create a Usage detail, nothing says that they cannot be aggregated to a level that makes sense for the business. It is common to do so already today, where multiple event records may be aggregated into one billable event as an example (long voice call, data sessions...) So here you need to consider what your business needs are. 

    TMF677 is intended to be providing an aggregation of usage consumption for a given point. In the QueryUsageConsumption you can see that the description indicates that this is to report current counters and balances. This should indicate that this could be used for other counters than balances, but the user guide heavily uses balance (bucket) related examples.  The consumption summary is more high level and doesn't go into the characteristics to the same level as 635. It can of course be extended to allow for more details to be provided if there is a business need.

    Usage and TMF635 will evolve significantly with version 5. TMF635 will stop with version 4 and be replaced by 3 APIs that are reflecting usage on Product, Service and Resource level separately. This will have likely impact on also the evolution of TMF677. 

    Kind regards, 

    Elisabeth 



    ------------------------------
    Elisabeth Andersson
    MATRIXX Software
    ------------------------------



  • 3.  RE: TMF 635 Usage Management vs TMF 677 Usage Consumption API

    TM Forum Member
    Posted 30 days ago

    Thank you Elisabeth for the response. It helped a lot ...



    ------------------------------
    Suresh Barman
    Vodafone UK Ltd
    ------------------------------



  • 4.  RE: TMF 635 Usage Management vs TMF 677 Usage Consumption API

    Posted 29 days ago
    For your use case of fetching Broadband session history details from a RADIUS server and translating it into a TMF API, it's important to distinguish between the types of data and objectives each TMF API supports:
     

    Key Differences Between TMF 677 (Usage Consumption) and TMF 635 (Usage Management):

     
    1. TMF 677 - Usage Consumption API:
       - This API is primarily focused on usage consumption against a quota or bucket, typically used for things like data consumption limits (e.g., 3GB out of 5GB).
       - It is more aligned with quota management scenarios (such as prepaid/postpaid consumption, remaining balance) rather than detailed session-level data.
       - If the primary requirement of the use case is to track how much data a subscriber has consumed out of a given allowance, this API would fit.
     
    2. TMF 635 - Usage Management API:
       - This API is broader and more generic, focusing on retrieving detailed usage records.
       - It is suitable for pulling detailed session/connection information, such as start/end times, session duration, data volumes (upstream/downstream), IP addresses, circuit IDs, and other static data.
       - It is ideal for cases where you need a complete history of network usage sessions, such as in your scenario involving session history details from a RADIUS server.
       - TMF 635 is generally used when detailed **usage reporting** is required, without linking the data to a consumption quota or bucket.
     
    Specific to Your Broadband Session History Use Case:
    Your use case involves fetching detailed **Broadband session history details**, which includes:
    - Session date/time
    - Session length
    - Upstream/Downstream bytes
    - Static details like IP address, Circuit ID, etc.
     
    Since the goal is to get session-level details and static information that describe each individual broadband session, TMF 635 (Usage Management API) is the better fit for your scenario. It allows you to fetch detailed usage records without being constrained by consumption tracking as in TMF 677.
     

    Why TMF 635 Is the Right Fit:

    - Granular session data: TMF 635 provides more flexibility in terms of getting detailed information like session start/end times, data volumes, and other session-specific attributes.
    - Static info support: It supports the retrieval of static data like IP addresses and Circuit IDs, which are important in broadband sessions but not a part of usage consumption models (TMF 677).
    - Not linked to quotas: Since you're more focused on historical session details and not on consumption tracking against a quota, TMF 635 aligns better with your needs.
     
    ### Conclusion:
    For fetching Broadband session history details from a RADIUS server, which includes information like session times, data volumes (upstream/downstream), IP addresses, Circuit IDs, etc., TMF 635 - Usage Management API is the most appropriate choice. TMF 677 (Usage Consumption) is more relevant to tracking data consumption within predefined quotas and doesn't offer the detailed session-level granularity you're looking for.
     
    If you need to integrate this with middleware for the translation of RADIUS data into TMF API responses, TMF 635 will offer the flexibility and structure needed to represent broadband session details effectively.


    Kind regards, 

    Evgenii 



    ------------------------------
    Evgenii Kozinchenko
    TO BE VERIFIED
    ------------------------------



  • 5.  RE: TMF 635 Usage Management vs TMF 677 Usage Consumption API

    TM Forum Member
    Posted 28 days ago
    Edited by Soumit Saha 28 days ago

    Hi Evgenii Kozinchenko
    Could you please share an example of how you mapped session data, volumes as part of TMF635 model?
    Did you consider to map runtime session data (i.e bytes in, out) in `usageCharacteristics` ? My understanding of `Characteristic` is that it used for describing properties of product/service/resource. Wondering how runtime values has been captured in the Characteristic - unless you have used any extension using buckets or counters.

    Regards,
    Soumit



    ------------------------------
    Soumit Saha
    Vodafone UK Ltd
    ------------------------------