Open APIs

 View Only
  • 1.  Service Offers in TMF633 Schema

    TM Forum Member
    Posted Nov 12, 2022 22:41
    Hi All,

    Just like we have the concept of Product Offers in the Product Catalog API, do we have anything similar to model Service Offers in TMF633 Service Catalog API? This may be needed for CSPs internal infrastructure services that are ordered by the Network Teams to build the Network Infrastructure. eg: I can have a Transport Domain Infrastructure service that is needed to be built in the network for upcoming B2B customer orders. But I offer only 2 flavours of Transport Domains, Gold Transport for mission critical services with ultra low latency and jitter and Standard Transport for standard services. So, on top of my Transport Domain service, that may have a set of characteristics to define these network properties, I would like to create 2 Service Offers where I can set the default values of specific characteristics to drive the behaviour for Standard Transport and Gold Transport. 

    One way to model this is to use full Product Catalog with Product Specs, Product Offers etc, which seems to be an overhead in this case because these services are owned by the Network Infrastructure team and never exposed to customers. Also, there is no customer billing involved here as these are internal services. Hence, I am looking for a simple construct that I can create above my Service Specifications that can specify the default value of various characteristics for each flavour. Please let me know what is the recommended way to model this requirement in TMF. I don't see anything called Service Offer in TMF633 Schema.  


    Kinshuk Kulshreshtha
    Oracle Corporation

    My views posted on this forum are personal, and do not reflect the position of my employer or TM Forum.

  • 2.  RE: Service Offers in TMF633 Schema

    TM Forum Member
    Posted Nov 13, 2022 02:12
    Hi Kinshuk
    There is a Service Candidate entity, which might go a way to meeting your requirements. You could extend it to add the CharacteristicUse functionality like we have in TMF620 for Product Offering limiting the characteristics of Product Spec.
    But I'm not sure how this would work in an end-to-end flow. It might help for you to sketch out a sequence diagram showing the flow between the various layers (network team, internal infra, etc.).
    Adding @Kamal Maghsoudlou for his thoughts 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.

  • 3.  RE: Service Offers in TMF633 Schema

    TM Forum Member
    Posted Nov 14, 2022 04:01
    Hi Kinshuk,

    Jonathan is right about the purpose of the ServiceCandidate.
    Since in your example you probably want to sell the Standard Transport at a different price then the Gold Transport, the TMF620 ProductOffering already has a ServiceCandidateRef to make this easy to accomplish. This will also make it obvious for the productOrder Orchestration which ServiceCandidate needs to be ordered in the ServiceOrder Management.

    The current TMF633 will need to be extended however, since it lacks the CharactericUse functionality.


    Koen Peeters

  • 4.  RE: Service Offers in TMF633 Schema

    Posted Nov 14, 2022 09:53
    Edited by Stephan Pelletier Nov 14, 2022 09:54

    Hi Kinshuk!

    Happy to join you in this thread! (I miss you! :-) )

    Agree with you that a catalog approach for more technical orders (such as internal service orders, but also service orders between partner companies) adds overhead in many ways.

    What I am driving, across a few partner network operators (in context of MOCN operators for 5G Network Slicing), which would apply as well to internal service orders, is the use of strongly-typed Service Order API where, for one, you can define your own JSON schema (as sophisticated as you wish - it's actually needed for Slicing Service and Slice Profiles), not being constrained with the old flat serviceCharacteristics name-value pairs approach.  This leverages a new "serviceConfiguration" section to-be-added to the TMF Service Order API (it should have been added a few years ago, as we had driven this in via the consortium of ONF, MEF, and TMF - but it is finally soon coming officially as a result of requirements of other TMF projects).

    Example here of using serviceConfiguration:
      - id: "1"
      action: add
      "@type": ServiceOrderItemAdd
      service: {}
         "@type": RanNetworkSliceSubnetAddAction
         "@schemaLocation": http://nbi/api/v4/serviceSpecification/RanNetworkSliceSubnetAddAction.json
         externald: ID
         instanceName: RanSliceSubnet-Test1
         serviceType: RanNetworkSliceSubnetAddAction
         administrativeState: UNLOCKED
         operationalState: ENABLED
         networkSliceSubnetType: RN_SLICESUBNET
         priorityLabel: 1
            - N3_Tr_Slice1
         sliceTechnicalServiceType: my_service_variant1
            - pLMNInfoList:
                - sNSSAI:
                      sST: 1
                      sD: A1

    To answer directly your question (how do you differentiate between flavors of a same service), I introduced, as part of the service schema (RAN Network Slice Subnet, in this example) an attribute that I called "sliceTechnicalServiceType" (you can call it what you want for a Transport service using the same service schema).  I basically expose ALL attributes possible for a RAN Network Slice Subnet (including RAN Slice Profile attributes) so the API supports any and every attribute possible (a generic RAN Network Slice Subnet exposure).  Then, I complement with passing a sliceTechnicalServiceType which identify a variant (or blueprint) of a RAN Network Slice Subnet service. The client is "abstract" for any default or pre-defined values or other predefined Design & Assign business logic.  This abstraction is very important. You want to hide the details from the interface. It is by using the simple sliceTechnicalServiceType attribute that the orchestration functionality executes the variant-specific Design & Assign rules (which can be static rules such as default or pre-defined values, or dynamic rules with different algorithms if needed).  The only thing the client needs to know, other than which service attributes should be used, is what variant they need to ask for (as a simple sliceTechnicalServiceType value).

    That's it!

    Hope that's interesting to you!


    Stephan Pelletier

  • 5.  RE: Service Offers in TMF633 Schema

    TM Forum Member
    Posted Nov 14, 2022 11:38
    @Jonathan Goldberg@Koen Peeters

    Thanks a lot for your inputs on this. It is very helpful. In some threads I have seen that Service Candidate does not have any semantic meaning. ​But it seems that it does have a role to play and this is exactly where it needs to be used. That is really great! 

    @Stephan Pelletier

    I am so happy that you joined this thread :-) . You have bought a very interesting point ​​about Strongly Typed Service Order API, which MEF is driving with its LSO Legato API where they (or I should say you) have added MefServiceConfiguration. I see a similar Pattern here in your payload. 

    From Catalog perspective, if I try to reconcile what you have specified with what Jonathan and Koen has mentioned above, will it be fair to say that my_service_variant1 can be modelled as a ServiceCandidate and sliceTechnicalServiceType is similar to ServiceCandidateRef that @Koen Peeters has suggested to add to Service Order API?


    Kinshuk Kulshreshtha
    Oracle Corporation

    My views posted on this forum are personal, and do not reflect the position of my employer or TM Forum.

  • 6.  RE: Service Offers in TMF633 Schema

    Posted Nov 15, 2022 07:47
    Hi Kinshuk!

    I think it's a different thing at the Product level versus Service level.  For product, yeah, you want to be able to offer multiple offerings based on the same product spec, so using this CharacteristicUse functionality for limiting the characteristics of Product Spec makes sense - that is a nice way to define new product offerings.  Note that each product offering is a different "exposure" to a client, which is perfect at this level.

    For a technical services (CFS' or RFS'), my aim is more to have a single service definition and a single exposure (the hour glass ;-) ).  I don't want to constrain characteristics (or strongly-typed attributes) for the purpose of offering multiple exposures to the client.  I just want one service API for a given service model.

    My approach is more to add a business context (intent) attribute to the service model (could be generalized in an API attribute I guess, over time) which the client can be aware of, and the client can order the service with a specific single-attribute business context (very simple), always using the same service data model interface.  It is the service orchestration functionality, under the hood, where you've onboarded the different service contexts for a same service definition, which will deal with the pre-defined/default values (both intent "and" Design&Assign values) and even context-specific algorithms, on a per context basis.

    This approach provides a more strongly abstraction-based architecture, in my view, with a single service exposure per service model, as opposed to providing some explicit "service offerings" with the use of CharacteristicUse functionality.

    My two-cents!

    Cheers! :-) 

    Stephan Pelletier