Open APIs

 View Only

  • 1.  SupportingService in TMF638

    TM Forum Member
    Posted Jan 17, 2023 12:10
    Hello,

    Service in TMF638 contains
    - supportingService
     A list of service ref or values (ServiceRefOrValue [*]). A list of supporting services
    (SupportingService [*]). A collection of services that support this service (bundling,
    link CFS to RFS).
    - serviceRelationship.
    A list of service relationships (ServiceRelationship [*]). A list of service relationships
    (ServiceRelationship [*]). Describes links with other service(s) in the inventory

    ServiceSpecification in TMF633 contains 
    - serviceSpecRelationship
    A list of service spec relationships (ServiceSpecRelationship [*]). A list of service
    specifications related to this specification, e.g. migration, substitution, dependency or
    exclusivity relationship.
         
    In catalog driven point of view, can we assuming
    every serviceRelation in service instance should have corresponding serviceSpecRelation in service specification?

    If yes, then where is supportingService rule in service specification?

    If serviceSpecRelation can be used to define rules for both serviceRelation and supportingService, 
    should we have explicit attribute in serviceSpecRelation to distinguish supporting service definition vs general relationship definition?


    Thanks for your help or comment in advance.

    David Xie




    ------------------------------
    David Xie
    Hansen Technologies
    ------------------------------


  • 2.  RE: SupportingService in TMF638

    TM Forum Member
    Posted 21 days ago

    Hello,
    this topic has not been answered yet, but I have the same question. I add my notes.

    TMF633 Service Catalog serviceSpecRelationship

    • According to the description ("migration, substitution, dependency or exclusivity relationship"), it looks like these relationships are intended for Service Specifications relations, rather than relations between service instances in the inventory. For instance, "Copper access" can be substituted by "Fiber access". Maybe "dependency" could have also a meaning for service instances(?).
    • The ServiceSpecRelationship sub-resource defines attributes – name, relationshipType, role, which in can be used to express the meaning of the relationship.
    • There is following example in the TMF633 user guide:

        "serviceSpecRelationship": [
            {
                "relationshipType": "dependency",
                "role": "dependent",
                "id": "5563",
                "href": "https://mycsp.com:8080/tmf-api/serviceCatalogManagement/v4/serviceSpecification/5563",
                "name": "Points to the Deep Packet Inspection service on which this Firewall service depends",
                "validFor": {
                    "startDateTime": "2020-08-25T00:00",
                    "endDateTime": "2021-03-25T00:00"
                },
                "@referredType": "ResourceFacingServiceSpecification",
                "@type": "ServiceSpecRelationship",
                "@baseType": "",
                "@schemaLocation": "https://mycsp.com:8080/tmf-api/schema/Service/ServiceSpecRelationship.schema.json"
            }
        ]

    • Using property name for a entire sentence seems a bit strange and not aligned with other / common using of "names".
    • In this example, I am not sure, if the relationship is only in catalog relevant, or should be also instantiated in the inventory.
    • Is there any assumption regarding the existence of the opposite relationship, when getting the serviceSpecification/5563 Deep Packet Inspection service specification? It could be in a role like "role": "needed by".

    TMF638 Service Inventory supportingService and serviceRelationship

    • supportingService – „A collection of services that support this service (bundling, link CFS to RFS)." There is no additional information about a role / meaning.
    • serviceRelationship – „A list of service relationships (ServiceRelationship [*]). Describes links with other service(s) in the inventory." It has properties relationshipType and serviceRelationshipCharacteristic [array], so it is possible to express the meaning, but not fully the same way is in catalog (type, role, id, name).

    Is there any intention for catalog serviceSpecRelationship to be instantiated in the inventory as a supportingService and/or serviceRelationship?

    Kind regards,

    ------------------------------
    Jiri Smekal
    T-Mobile Czech Republic
    ------------------------------



    ------------------------------
    Jiri Smekal
    T-Mobile Czech & Slovak Telekom, a.s.
    ------------------------------

    Original Message