A ResourceFunctionSpec specifies a function as a behavior to transform inputs of any nature into outputs of any nature, independently from the way it is provided. It is typically created by a function designer who may not have specific knowledge on realization architecture (for example using English text explanations with diagrams, like RFC standards, or preferably a machine interpretable language).<br/><br/>The realization of a ResourceFunctionSpec may be achieved by different ways; either SoftwareSpecification, PhysicalBlackBoxSpec or SoftBlackBoxSpecification.<br/><br/>Typically, when creating ProductSpec, CFSSpec and RFSSpec level definitions the choice of realization has not been made. ResourceFunctionSpecs are useful for precisely defining the required behavior before knowing the technical solution to use.<br/>Before finalising a ProductSpecification a designer – usually in a Communication Service Provider - must be sure that all the ResourceFunctionSpec required by the ProductSpecification are covered including those needed by its technical solution (CFSSpec, RFSSpec).<br/><br/><i>Note: SoftwareSpecification, PhysicalBlackBoxSpec and SoftBlackBoxSpecification are sub-classes from ResourceSpecification.</i><br/>ResourceFunctionSpecs shown below have the merit that they can be supported by any or all of Product Spec, CFSSpec and RFSSPec. They act as the bridge between service and product model specification to ResourceSpecifications. This is particularly useful when functions at Product level are augmented with more detail as they are realized as a set of services and supporting services and resource. Typically, this is achieved by using profiles or templates that add the additional Service and Resource Specification details. <br/>See Service Configuration ABE and the GSMA generic Slice template (GST) 5G examples in IG1194 Focus on Services not Slices. [4]<br/><br/><font color="#e0121d"><b>Use of ConfigurationFeature to support ResourceFunction</b></font><br/><font color="#29313b">To support a fully intent-based deployment approach, the concept of ConfigurationFeatureSpec are introduced in the model.  This is the formal representation of the concepts of a Feature and a Feature Group used in TR 255 [5] and TMF664 [6]to describe the capabilities of a function including ResourceFunctions. E.g. a router or a simple example such as a washing machine described in ‘Appendix 2: Illustrating the concepts of ConfigurationFeatures and ResourceFunctions’. It is particularly useful for intent based management as described below.</font><br/><font color="#29313b">The use of Feature and Feature Groups to support ResourceFunctions is comprehensively described for network scenarios in TR255 Resource Function – Activation and Configuration, in its ‘Section 3.2 General Concepts and TR255B Specification Requirements for Resource Functions’, and  in its ‘Section 3.4 Approaches present different instantiation approaches for Resource Functions’.</font><br/><font color="#29313b">The following paragraphs are extracted from these TR255 documents:</font><br/><font color="#29313b"><i>In particular, in the fully intent-based approach, the consumer of a given Resource Function (RF) declares what they require but not how to accomplish the task (in terms of components)</i></font><br/><font color="#29313b"><i>In this approach, the consumer for the RF selects one or more functional features or feature groups from a list of possibilities in the associated specification.</i></font><br/><font color="#29313b"><i>A </i><b><i>Feature</i></b><i> is how an RF exposes its capabilities to consumers.</i></font><br/><ul>
<li><font color="#29313b"><i>Unlike an RF, a Feature cannot be independently deployed.</i></font></li><li><font color="#29313b"><i>SomeFeatures may be mandatory while others can be selected or not by the consumer (for a given instantiation).</i></font></li><li><font color="#29313b"><i>Features may have characteristics which are settable by the consumer (at instantiation time and/or during the lifetime of the RF).</i></font></li><li><font color="#29313b"><i>Composite RFs do not necessarily (directly) expose the features of the constituent RFs. In such cases, the composite RF can abstract, rearrange, and reformulate and augment the features of the constituent RFs.</i></font></li></ul>
<font color="#29313b"><i>A </i><b><i>Feature Group</i></b><i> is an aggregation of Features.</i></font><br/><ul>
<li><font color="#29313b"><i>A feature group may have characteristics in addition to the characteristics of the constituent features.</i></font></li></ul>
<font color="#29313b">As described earlier these concepts of Functions and Function Group are supported in the Information Framework formally by use of ConfigurationFeature and ConfigurationFeatureSpec. both of which can be composed and bth are rooted on Entity. In the Open APIs ConfigurationFeatures are represented by Feature and are composed by using the ‘is bundled attribute of a Feature and can have FeatureRelationship. </font><br/>