Open APIs

 View Only
  • 1.  Volatile Characteristics

    TM Forum Member
    Posted Aug 29, 2022 11:55
    Hello,

    While integrating an IMS platform in a TMF based solution following question popped up:
    Certain Characteristics of a Service or Resource can be changed by a customer without passing via OSS. e.g. the CallForwarding in Telephony (*21*[phone number]#).
    It should also be possible to change these Characteristics via the ServiceActivation or ResourceActivation API.

    So we do not want to store data about these kind of Characteristics in the ServiceInventory or ResourceInventory since this may be out of sync with what is present in the network.

    What is the recommended way to indicate that a Characteristic should not be persisted ?
    - keep some reference data to indicate this.
    - extend the definition of 'Characteristic'
    - something else ?


    Kind Regards
    Jan

    ------------------------------
    Jan Segers
    Proximus SA
    ------------------------------


  • 2.  RE: Volatile Characteristics

    TM Forum Member
    Posted Aug 30, 2022 08:13
    Great question Jan
    Perhaps we should consider an enhancement to the Catalog APIs (Service + Resource) to add this metadata indication on the CharacteristicSpecification.
    But in the meantime you can extend the relevant subclasses (ServiceCharacteristicSpecification and ResourceCharacteristicSpecification) to do this in your own implementation.

    Note that this works only for the dynamic (characteristic-driven) approach - if we use a strongly-typed model for services and resources there isn't an obvious way to add this meta-data information. Some talk has been had around extending JSON Schema itself, under the assumption that additional metadata that is not according to the JSON schema standard will be ignored silently by syntax checkers - not sure where this stands.

    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.
    ------------------------------



  • 3.  RE: Volatile Characteristics

    TM Forum Member
    Posted Dec 02, 2022 10:05
    Hi Jonathan,

    To support these volatile characteristics, one of our options is to go for the API extension like you proposed so I have one question:
    As we only want to know if a CharacteristicSpecification is volatile or not, could-we just use the @type and @baseType to distinguish between the 2 (VolatileCharacteristicSpecification and NormalCharacteristicSpecification for example)? Because there will be no added property, do we really have to provide an extended json schema (with allOf but nothing else) and refer it through schemaLocation?

    Best​ regards,​​

    ------------------------------
    Frederic Thise
    Proximus SA
    ------------------------------



  • 4.  RE: Volatile Characteristics

    TM Forum Member
    Posted Dec 04, 2022 08:53
    That's an interesting proposal. It should be OK, and since you are not actually extending with properties, I don't see why you need to provide a schema.
    Let's see if anyone else on the community provides feedback on this.

    ------------------------------
    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.
    ------------------------------



  • 5.  RE: Volatile Characteristics

    TM Forum Member
    Posted Aug 31, 2022 01:25
    This may be a candidate for use of Feature which is intended for intent-based configuration.  A simple implementation may be to have Features and Characteristics named the same (solely for literacy) where the Characteristic value provides explicit configuration while the Feature value provides an intent. You might implement policy which would ignore the intent if the subscriber had already explicitly set a value.  If you supply a value for the Characteristic in a request it is an explicit direction to set the value.

    ------------------------------
    Vance Shipley
    SigScale
    ------------------------------



  • 6.  RE: Volatile Characteristics

    TM Forum Member
    Posted Aug 31, 2022 01:59
    As Vance suggested, the feature is one of the best ways to capture such response-only attributes. Even if you use service characteristic, configurable property of the characteristic must be set to false.
    This will resolve the first part of your conversation.

    The second part of your query is, that you need to look into the retrieval of this information from Network in every GET operation, so NFR impact on the NE will be a big impact. So you are in a fix, 1. you cant store it in the service/resource inventory 2. you cant probe network in every query (because every query is not intended to see this information).

    ------------------------------
    Varun Nair
    Telstra Corporation
    Note: This is an opinion based on my research and not an official TMF response.
    ------------------------------



  • 7.  RE: Volatile Characteristics

    TM Forum Member
    Posted Sep 06, 2022 08:40
    Please note that it must be possible to configure this Characteristic via the API e.g via an IVR. 
    In our current legacy implementation, we don't  retrieve the info from the NE for every GET; only in case there is a complaint of a customer  (Service Assurance)
    If we use the intent-based Feature solution, we still need an indication that a certain 'category' of Characteristics should not be stored in the inventory because they can be changed via an outside source. 


    ------------------------------
    Jan Segers
    Proximus SA
    ------------------------------