I have read some marerials like gb922 product, service, and ig1228 use cases. So, what I understood about CFS, it is just abstraction layer that covers multiple RFSs in order to give intangible products. So, I need to confirm my understanding about it. RFSs are real service applications, cfs is just abstract expression to be given to customer. Is it right? Or can cfs be real service?
Hi Myagaa,You are right. Basically, a CFS is an abstraction of a service that you give to your customers. It is technology-agnostic and related to products of the core commerce layer.An RFS is a technical implementation for a service. A CFS can be realized by one or more RFSs. In turn, each RFS can use several resources for its implementation.As you mentioned, IG1228 is a very good place to find many examples of catalog configurations that use this approach.Hope it helps.Best regards,
CFS are customer facing services and RFS are resource facing services, resources could be physical or non-physical in nature.
CFS could be decomposed into several RFS so that each RFS can be provisioned and activated, this decopmosition is done in catalouge, some operators have two discrete catalouges for sales and service in that case RFS are decomposed in service catalouge. and yes you are right in a way that RFS is the real service provided to customer.
Think of CFS's as 'abstractions' of network/application capabilities that you market to customers. Typically there is a 1:1 relationship between a CFS and a Product, where as CFS:RFS can be 1:1, 1:n (one CFS composed of multiple RFS) and of course the same RFS can be utilised by multiple CFSs.
Comment so far are correct.
We do have a document on this topic including examples Product & Service Modelling Best Practices – Conforming to ODA v2.0.0 (IG1233) | TM Forum.
RFS work well for physical networks and equipment.
However in virtualised network environment you may need to use Resource Functions to abstract the logical functionality of networks asn equipment.
see GB922 Resource v23.0.0 | TM Forum
The ResourceFunction concept has been used extensively for Networking and Resource Management in several ODA and Open API activities:<o:p></o:p>
· TR 255A/B/C forming part of TR255 Resource Function Activation and Configuration Suite R17.5.0 <o:p></o:p>
· TMF664 Resource Function Activation and Configuration.
Customer Facing Service(CFS) Spec describes the Service as understood by the customer.
<o:p></o:p>CFS Spec characteristics comproises of:<o:p></o:p>
· Product characteristics needed to establish what needs to be delivered/fulfilled. e.g., Bandwidth of Internet Service, number of Static IP.<o:p></o:p>
· Resources assigned to Customer. e.g., Static IPs assigned to Customer. <o:p></o:p>Configurations the customer might be able to do to use the Service per their needs. e.g., BGP
CFS is made up of one or more RFS.
Resource Facing Service(RFS) Spec describes the Service as in the network. RFS Spec abstracts/hides the technology details that are not relevant to customer. Reuse of the model and processes is also one of the consideration while modelling the RFS Spec, with-out compromising on the RFS Spec still depicting a Service.<o:p></o:p>
RFS Spec characteristics comprises:<o:p></o:p>
· CFS characteristics to be provisioned/configured in the network. e.g., Bandwidth of Internet Service, Static IPs to be provisioned in the network, and BGP configuration. Any technical attributes needed to manage the resources and services in the network. e.g., Circuit ID<o:p></o:p>