Open APIs

Hi,

Most probably I might be reopening already discussed topic.

As I understand, TMF702 has been created specifically for resource configuration and activation. Previously this was part of TMF640 itself, which could have been utilized for Service as well as resource configuration and activation. Now we have a clear sepration of concerns for service and resource activation.

I was looking at IG1228 and specifically TMFS0008 use case https://projects.tmforum.org/wiki/display/PUB/TMFS008+Use+Case%3A+Service+and+Resource+Order+Management+for+Postpaid+Mobile+Subscribers+v3.2.0

Previously we had a clear defination of resource (logical or physical) like equipments (CPE etc..), or logical (IP, Port etc..), But with latest defination, as I understand all network services even has been demarcated as resources. 

So in all cases, Product spec will be backed by either CFS-RFS-Resource spec or directly by a resource spec. Which implies, all fulfillment activites are assumed to be addressed by TMF702.

If we go with this flow, what I am missing is the need of TMF640 itself. 

Is there a plan to decomission TMF640. Or am I missing something here.

Regards,

Hi

to my understanding, the fulfillment can be managed by :

• TMF622 at Product level
• TMF641 at Service level (when the ProductSpec is defined from a CFS)
• TMF652 at Resource level (when ProductSpec is defined from a Resource Spec)

Hi,

Most probably I might be reopening already discussed topic.

As I understand, TMF702 has been created specifically for resource configuration and activation. Previously this was part of TMF640 itself, which could have been utilized for Service as well as resource configuration and activation. Now we have a clear sepration of concerns for service and resource activation.

I was looking at IG1228 and specifically TMFS0008 use case https://projects.tmforum.org/wiki/display/PUB/TMFS008+Use+Case%3A+Service+and+Resource+Order+Management+for+Postpaid+Mobile+Subscribers+v3.2.0

Previously we had a clear defination of resource (logical or physical) like equipments (CPE etc..), or logical (IP, Port etc..), But with latest defination, as I understand all network services even has been demarcated as resources. 

So in all cases, Product spec will be backed by either CFS-RFS-Resource spec or directly by a resource spec. Which implies, all fulfillment activites are assumed to be addressed by TMF702.

If we go with this flow, what I am missing is the need of TMF640 itself. 

Is there a plan to decomission TMF640. Or am I missing something here.

Regards,

Thanks @olivier arnaud

This is clear for Product , Service and Resource order.

My question is mainly around activation scenarios that happens after decomposition of either service and resource order.

Hope this clarifies

Hi @Vance Shipley @Jonathan Goldberg, can you please check my query.

Regards,

Hi

to my understanding, the fulfillment can be managed by :

• TMF622 at Product level
• TMF641 at Service level (when the ProductSpec is defined from a CFS)
• TMF652 at Resource level (when ProductSpec is defined from a Resource Spec)

Hi,

Most probably I might be reopening already discussed topic.

As I understand, TMF702 has been created specifically for resource configuration and activation. Previously this was part of TMF640 itself, which could have been utilized for Service as well as resource configuration and activation. Now we have a clear sepration of concerns for service and resource activation.

I was looking at IG1228 and specifically TMFS0008 use case https://projects.tmforum.org/wiki/display/PUB/TMFS008+Use+Case%3A+Service+and+Resource+Order+Management+for+Postpaid+Mobile+Subscribers+v3.2.0

Previously we had a clear defination of resource (logical or physical) like equipments (CPE etc..), or logical (IP, Port etc..), But with latest defination, as I understand all network services even has been demarcated as resources. 

So in all cases, Product spec will be backed by either CFS-RFS-Resource spec or directly by a resource spec. Which implies, all fulfillment activites are assumed to be addressed by TMF702.

If we go with this flow, what I am missing is the need of TMF640 itself. 

Is there a plan to decomission TMF640. Or am I missing something here.

Regards,

@Alok Chhatry, there are many choices in architecture. We have Catalog, Inventory and Activation & Configuration APIs which may be used where you see fit.

TMFS0008 describes an example use case for postpaid mobile which I find quite good. The Resource entities being managed are simple Logical Resources described as "Profiles", they are pieces of information and not active processes with state, and for this TMF702 is the matching API. For the latter TMF664 would be appropriate.

Some CSPs have adopted a NaaS (Network-as-a-Service) approach where they prefer to lifecycle manage RFS in a separate system which hides the Resource domain behind it. This structural separation may mirror the organization of the CSP. With NaaS we use TMF640.

With the introduction of Resource Function (RF), almost a decade ago, we may manage Network Services as the Resource domain entities which they are, using TMF664. The relationship is then CFS -> RFS -> RF. The purpose of an RFS is to encapsulate technology domain specifics. With well defined and managed RFs there may be no need for separate RFS, for example one "5G Mobile Line" RFS may be used across multivendor 5GCs. This then becomes a redundancy which may encourage CSPs to collapse the RFS and RF into one managed Entity. Technically, the RFS can only be eliminated in the case of Physical Resources (i.e. UICC, device), current SID does not allow a Logical Resource (e.g. RF) in a CFS, so the RF gets consumed into the RFS in the collapse and we're back to using TMF640.

What is an example of a Service (Service domain) which is not a Network Service (Resource domain)? Where there is no Resource domain within scope, such as in the NaaS use case, or where the network vendors expose only a high level abstraction with a Service Intent, or something network unrelated (e.g. account related). These are examples where TMF640 would be appropriate.

Thanks @olivier arnaud

This is clear for Product , Service and Resource order.

My question is mainly around activation scenarios that happens after decomposition of either service and resource order.

Hope this clarifies

Hi @Vance Shipley @Jonathan Goldberg, can you please check my query.

Regards,

Hi

to my understanding, the fulfillment can be managed by :

• TMF622 at Product level
• TMF641 at Service level (when the ProductSpec is defined from a CFS)
• TMF652 at Resource level (when ProductSpec is defined from a Resource Spec)

Hi,

Most probably I might be reopening already discussed topic.

As I understand, TMF702 has been created specifically for resource configuration and activation. Previously this was part of TMF640 itself, which could have been utilized for Service as well as resource configuration and activation. Now we have a clear sepration of concerns for service and resource activation.

I was looking at IG1228 and specifically TMFS0008 use case https://projects.tmforum.org/wiki/display/PUB/TMFS008+Use+Case%3A+Service+and+Resource+Order+Management+for+Postpaid+Mobile+Subscribers+v3.2.0

Previously we had a clear defination of resource (logical or physical) like equipments (CPE etc..), or logical (IP, Port etc..), But with latest defination, as I understand all network services even has been demarcated as resources. 

So in all cases, Product spec will be backed by either CFS-RFS-Resource spec or directly by a resource spec. Which implies, all fulfillment activites are assumed to be addressed by TMF702.

If we go with this flow, what I am missing is the need of TMF640 itself. 

Is there a plan to decomission TMF640. Or am I missing something here.

Regards,