Open APIs

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:
serviceOrderItem:
  - id: "1"
  action: add
  "@type": ServiceOrderItemAdd
  service: {}
  serviceConfiguration:
     "@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
     epTransportRef:
        - N3_Tr_Slice1
     sliceTechnicalServiceType: my_service_variant1
     sliceProfileList:
        - pLMNInfoList:
            - sNSSAI:
                  sST: 1
                  sD: A1
              pLMNId:
etc.

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!

Cheers!

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:
serviceOrderItem:
  - id: "1"
  action: add
  "@type": ServiceOrderItemAdd
  service: {}
  serviceConfiguration:
     "@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
     epTransportRef:
        - N3_Tr_Slice1
     sliceTechnicalServiceType: my_service_variant1
     sliceProfileList:
        - pLMNInfoList:
            - sNSSAI:
                  sST: 1
                  sD: A1
              pLMNId:
etc.

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!

Cheers!