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



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



  • 5.  RE: Volatile Characteristics

    TM Forum Member
    Posted 26 days ago
    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
    ------------------------------