on Posted on Reading Time: 4 minutes
The rapid adoption of LSO APIs for business and operational automation is increasing awareness of the underlying MEF work areas of LSO Product Payloads and LSO Service Payloads. Within the context of MEF LSO APIs, what are ‘products’ and ‘services’ and how do we differentiate between them? How do we develop these LSO payloads and how does the recent formation of the MEF LSO Product Modelers group support this effort?
To answer these questions, we first turn to the MEF LSO Framework defined in MEF 55.1 Lifecycle Service Orchestration (LSO): Reference Architecture and Framework, which is represented in the figure below.
As shown at right in the figure, there are three layers in the LSO Framework: Products, Services and Resources.
Services
The services layer encompasses the OSS or Service Orchestration Functionality (SOF) of the retail service provider and wholesale operator. The LSO APIs that reside at the LSO Interface Reference Points (IRP) LSO Allegro, LSO Interlude, and LSO Legato are termed LSO Operational APIs and carry LSO Service Payloads—the latter being service data schema.
Similarly, the products layer encompasses the BSS or Business Applications (BA) of the retail service provider and wholesale operator. Again, the LSO APIs that reside at the LSO IRPs LSO Cantata and LSO Sonata APIs are termed LSO Business APIs and carry LSO Product Payloads—the latter being product data schema.
Why don’t we use the term services or products in both these layers? Why do we use the term “products” in one layer, and “services” in the other?
To answer this question, we go back to the underlying definitions of service, service instance and service specification that appear in the standards MEF 50.1 and MEF 55.1. These service-related terms are derived in large part from work in TM Forum. The simple consolidation of these definitions and the resulting work of MEF can be articulated as follows:
“A service in the MEF context is an offering to customers that is realized within the Service Provider using service attributes—which in the case of MEF-standardized services are defined in related MEF standards.”
Services have been in the MEF lexicon for almost twenty years—originally for Carrier Ethernet services and more recently for IP services, Optical Transport services, SD-WAN services, and SASE services. Service providers use the MEF service attributes and service definition standards to minimize market confusion and fragmentation and, at the same time, maximize interoperability in implementations of the services.
Using these attributes and service definitions, MEF has also standardized MEF Service Models and service data schemas for MEF services. The latter can be used as LSO Service Payloads within LSO APIs to streamline operational interactions with external partners at LSO Allegro and LSO Interlude and at LSO Legato to streamline operational interactions internally with the BSS/Business Applications of the service provider.
Products
In more recent years, the question of how to transact these services at the business layer (e.g., for quote and order management) has driven the development of the LSO Business APIs carrying LSO Product Payloads at LSO Cantata and LSO Sonata.
Again, we return to the underlying definitions of product, product instance, product offering and product specification that appear in MEF 50.1 and MEF 55.1, and these can be reduced to the following:
“A product in the MEF context is the external representation of a service to customers.”
In other words, a service is the implementation within the service provider and the product is what is bought and sold by the service provider.
What are the implications for LSO APIs and their data schema payloads?
A service provider implementing a service may need to reference a very large number of attributes, many of which are of no interest to the customer buying that offering. Conversely, a product may need attributes that are irrelevant for building a service but are essential to the customer. We can think of examples of consumer products like cars, refrigerators, lights, etc., in which the consumer is interested in a much smaller set of aspects of the product than the manufacturer is when manufacturing it.
This difference is important in the context of LSO Payloads, which are used in LSO APIs to automate interactions between different entities like service providers, partners, and customers. The LSO Product Payload needs to represent the product and its attributes while the LSO Service Payload needs to represent the service and its attributes. Building the LSO Service Payload from the very detailed and robustly developed MEF standards has been achievable by those MEF member contributors who are intimately familiar with the underlying service standards.
However, determining the product attributes around a given service for automation of business between buyers and sellers is more suited to business and product people in the telecom industry who are intimately familiar with the product requirements of their customers and how these products are transacted and perhaps less familiar with how the underlying services are built. We now refer to people with this type of expertise as ‘LSO Product Modelers’.
For this reason, the MEF’s Commercial and Business Committee is now forming an LSO Product Modelers group comprising product and business-oriented individuals from the MEF membership who are familiar with transacting products based on MEF-defined services including:
- Subscriber Carrier Ethernet
- Operator Carrier Ethernet
- Internet Access
- Optical Transport
- Network Slice
- SD-WAN
- SASE
- Edge Compute
- Power and Space
In addition, the MEF’s LSO Product Modelers group will recommend attributes for products that are out of scope for MEF standardization but are frequently found in service provider product catalogs. These attributes will be used in MEF-Endorsed LSO Product Payloads—in contrast to the MEF-Standardized LSO Product Payloads listed above.
Initial product candidates for work in this area include:
- Dark Fiber
- 5G Fixed Wireless Access (FWA)
- Trusted Location
- SIP Trunking
The benefit of reaching broad consensus on product attributes for non-MEF services is that they can be used by LSO APIs for business automation just the same as for MEF-standardized services.
Building the LSO Product Modelers group is a watershed moment in the evolution of MEF and a great opportunity for our business and product-oriented member representatives to both influence the industry and shine on the MEF stage together with our dedicated standards contributors.
Learn More
MEF members with business and product experience in transacting the following products are invited to participate in MEF workshops, which are being organized to take place in 2023; LSO Product Modelers will work to reach consensus on the contents of LSO Product Payloads and their data schema.
- Subscriber Ethernet (update of MEF 125)
- Operator Ethernet (update of MEF 106)
- Internet Access (MEF W139)
- IPVPN
- Dark Fiber
- Network Slice
- 5G FWA
Details of upcoming workshops will be announced over the coming weeks. Queries may be addressed to Daniel Bar-Lev, MEF at info@mef.net.
