Open APIs

 View Only
  • 1.  TMF641 - Handling Service Feature

    TM Forum Member
    Posted Jun 28, 2019 14:11
    Hi,Hi,
    We are able to map our Characteristic or group of characteristics leveraging the proposed structure using valueType of "string" or "object"

    Where we have issues are around Features. For us a feature is a "thing" that is actionable. 
    - A characteristic "describes" the service (i.e. DownloadSpeed, UploadSpeed) 
    - A feature is a capability that can be added, removed or modified (i.e. CallForward, 3WayCall). Other would see those as different CFS, but in our modelling, those are features of a Voice CFS.  We are planning to extend the characteristic object (composed of name, valueType, value...) to a new attribute (action). When "action" gets populated, it means a feature.

    We would have something like: 
    - serviceCharacteristic
    - name: 3WayCall
    - action: add

    For complex feature structure (with characteristic), we would have something like: 
    - serviceCharacteristic
    - name: CallForward
    - action: add
    - valueType: "object"
    - value: 
    - @type: CallForwardTN
    - TN: 9052224444

    Looking for some feedback if we are taking the right approach
    Regards

    ------------------------------
    Stephane AH-KO
    CGI Info Systems Management Consulting Inc.
    ------------------------------


  • 2.  RE: TMF641 - Handling Service Feature

    TM Forum Member
    Posted Jun 29, 2019 16:26
    Hi,

    as you correctly state your features is usually modeled a a seperate CFS.
    You fail to explain why this modeling doesn't suit you.

    Regards

    ------------------------------
    Koen Peeters
    Ciminko Luxembourg
    ------------------------------



  • 3.  RE: TMF641 - Handling Service Feature

    TM Forum Member
    Posted Jun 30, 2019 16:13
    Hi all

    I don't think that there is one right or wrong answer for this.

    But, to my understanding, the Product/Service/Resource entity reflects the state and not the action. For the action, we have ProductOrder/ServiceOrder/ResourceOrder - in these Orders we have the OrderItem that includes action. So to add a feature, you would model the feature as a Service in the catalog, and then issue a ServiceOrder including an OrderItem with action add for this Service. To remove the feature, use an OrderItem with action remove.

    As an alternative approach for features that don't have characteristics, you could model the feature itself as a characteristic of type Boolean; value true would cause the feature to be active and value false would cause the feature to be inactive. I don't like this approach so much, but I can understand why some people would find it attractive.

    Hope it helps.

    ------------------------------
    Jonathan Goldberg
    Amdocs Management Limited
    ------------------------------



  • 4.  RE: TMF641 - Handling Service Feature

    Posted Jul 02, 2019 02:46
    Thanks!

    ------------------------------
    CETPA Infotech
    CETPA INFOTECH
    ------------------------------



  • 5.  RE: TMF641 - Handling Service Feature

    TM Forum Member
    Posted Jul 02, 2019 08:44
    Thanks all for your answers

    @Koen Peeters, our logic to differentiate if a "thing" is a another CFS or a feature of a CFS, is to compare that "thing" to the CFS and check if it can leave without the CFS. Depending on the answer, it's a CFS or a feature.
    We looked at the option to have all our features be CFS.
    • Just for the Voice CFS, we would end up with more than 60 CFS just to represent the Voice service itself.
    • We would also require to introduce a concept of CFS hierarchy to link the (Feature) CFS to the main Voice CFS.
    • Finally, the PSR hourglass concept would not work anymore since the CFS layer would not be the thinner layer anymore​​.

    @Jonathan Goldberg. We looked at the option of using boolean characteristic as well. We abandoned for few reasons reason​s:
    • For every Voice CFS creation, there would be more than 60 characteristics defaulted to 'false'
    • The model works well for simple boolean structure, less for complex structure

    At the end, we chose a model between the 100% CFS and the 100% characteristics, with the concept of Feature. The concept of feature works well as well with our inventory system which provides the "Configuration Item" capability (Config Items are "objects" that can be assigned or unassigned under a CFS). Our gap is with the TMF Model.
    We are at the moment hesitating between 2 options:
    • Introducing a new "Feature" object child of "ServiceRestriction". "Characteristic" would be child of "ServiceRestriction" and "Feature"
    • Extending the "Characteristic" object with an attribute "action" and/or a type reflect the fact it's a Feature/capability

    Regards

    ------------------------------
    Stephane AH-KO
    CGI Info Systems Management Consulting Inc.
    ------------------------------



  • 6.  RE: TMF641 - Handling Service Feature

    TM Forum Member
    Posted Jul 03, 2019 09:59
    Hi,

    If I understand well you are calling a feature a CFS that has a dependency relationship with a 'main' CFS.
    You use it to model for example the "Call Forward Unconditional" feature of a "VOIP" service. A customer can subscribe to "Call Forward Unconditional" service only if he already subscribed to the "VOIP" service.
    The TMF638 API already supports this concept via the ServiceRelationship.
    The modelling used in TMF638 even support chaining of ServiceRelationships: "Call Forward Unconditional" depends on "VOIP" depends on "IP connectivity".

    I just lived through a transformation project where the software vendor implemented a single, hierarchical dependency model using "features".
    Particularly when you are modelling 60 CFS you will detect that some of these will be a feature of a feature or a feature depending on multiple CFS.
    A full TMF638 model would support this graciously. By implementing Feature as you call them you will severely restrict your flexibility.








  • 7.  RE: TMF641 - Handling Service Feature

    TM Forum Member
    Posted Jul 03, 2019 09:59
    Folks interesting discussion  Obaservations
    This grouping of characteristics has come up in the ODA And ZOOM work.and clearly needs formally documenting. 
    The model needs to be applicable at PSR levels in self similar way.and support atomic compositevpatterns. Catalyst Work we have on 5G GST  confirms this. 
    SID currently has concept called Resource Function but name is deceptive as only applies to PS and is not atomic composite
    SID has concept of Feature and Feature Group in Gb9222 Logical and compound Resource computing and software which is modelled formally as Configuration Feature. ODA has opened a number  SID Crs to clean up this modelling inconsistencies across PSR  Can add the CR numbers later but would be good to get wider input. Expectation is we will start on resolving these modelling matters on SID call starting Thurs 11th July




    ------------------------------
    Dave Milham
    TM Forum Chief Architect, TM Forum
    ------------------------------



  • 8.  RE: TMF641 - Handling Service Feature

    TM Forum Member
    Posted Jul 03, 2019 10:00
    Folks good discussion 
    In ODA Production ZOOM we have been looking at this general topic of grouping of characteristics. We have come to similar conclusions that we need a common model at P/S/R level and support and atomic composite pattern.
    Looking at GB922  Logical Resource Business Entity Definitions – Computing and Software The SID has a Resource Function which actually only works for P/S  and is nt supporting composite pattern.
    It also has Feature and feature group modelled as ConfigurationFeature
    The thinking is that we need a more consistent set of pattern and afew CRs have been opened with the SID to address these points ( also to support model driven automated onboarding.
    1. FP-836Create classes representing specialization of the general "Function" concept
    2. FP-835Create "Function" as a general concept
    3.  FP-832Clarify definition of "SoftwareResourceSpecifict
    4. FP-837Deprecate "Feature" and "FeatureGroup"

     


    ------------------------------
    Dave Milham
    TM Forum Chief Architect, TM Forum
    ------------------------------