I was just looking through the Configuration and Profiling section of the Information Frameworx Common Domain and noticed the following statement in section 4.17 Page 389 v22.5.
It is envisioned that SID implementers will begin to use the Service Configuration ABE as an alternative to Resource Facing Service Specification and Resource Facing Service ABEs. The reason is that the Service Configuration ABE provides a more complete model that represents how services are configured. However, the current Resource Facing Service ABEs will not be removed from the model to preserve backward compatibility and to not impact conformance to them.
My understanding is that CFS is the functional, technology-agnostic layer and RFS is the technology-specific layer. If the above were to be true, where does one envisage the technology specific configurations existing?
ResourceFunction provides an alternative to RFS which may be used to keep the technology stack specifics in the Resource Domain. ResourceFunctionSpecification/ResourceFunction is available today in Open APIs. The Configuration ABEs have yet to be realized in Open APIs.
Thanks Vance for your reply.
My understanding of resource functions are that they are used alongside Product/CFS/RFS mainly for assisting with RF activation and orchestration in the cloud, such as cloud-native deployments of 5GC and MEC Apps. The following diagrams are taken from IG1163C on CFS-RFS-RF clarification. Are there any fundamental changes since this presentation was produced?
A Resource entity (i.e. ResourceFunction) may be included directly in a Service entity (CFS).
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.
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.See Service Configuration ABE and the GSMA generic Slice template (GST) 5G examples in IG1194 Focus on Services not Slices.
"See Service Configuration ABE and the GSMA generic Slice template (GST) 5G examples in IG1194 Focus on Services not Slices."
Presumably this is suggesting that a valid implementation of S/P-NEST is using Service Configuration to handle the 3GPP ServiceProfile NRM based on GSMA NG.116 GST. I would have thought that the 3GPP ServiceProfile (NEST) are intrinsic characteristics of the slice profile CFS (i.e. the requirements of the 5G network slice) and not configuration (see the 5G slice use case from IG1228).
In GB999 ODA Production Implementation Guidelines section 4.5.1 describes 5G slice management. The 3GPP scope is entirely Resource Domain but 3GPP TS 28.530 and TR 28.805 do describe the concept of a Communications Service, and the role of a Communications Service Management Function (CSMF), which is in the Service Domain. Within the Resource Domain a network service, such as Network Slice, is represented as a compound Resource Function, as defined in TR255.
In IG1194 Focus on Services not Slices the role of GSMA NEST is described. Designing CFS is an art, as it's customer facing and going into a Product Offering, it's a creative process. Ultimately a Network Slice is orchestrated within a 5GC in a very specific, standardized, way. NEST may play a useful role in the middle.