Lifecycle Service Orchestration, NaaS and the inter-provider seam — and how Mplify's LSO aligns with TM Forum ODA and Open APIs.
Mplify (legally the Mplify Alliance) is the name MEF took in June 2025. MEF began in 2001 as the Metro Ethernet Forum, standardising Carrier Ethernet services so that one provider's Ethernet circuit meant the same thing as another's; over two decades its scope grew to IP, SD-WAN, SASE and the automation of ordering them between providers. The rename marks that the organisation's centre is now Network-as-a-Service — standardised, certifiable connectivity services consumed on demand — together with the automation, AI and security around it, rather than one access technology.
Its lasting contribution to OSS architecture is Lifecycle Service Orchestration (LSO): a reference architecture that names the interfaces a service crosses on its way from a customer order to a working circuit, including the one that crosses between two providers. If you have seen "Sonata" or "Legato" on an integration diagram, this is where they come from. In June 2024 MEF and TM Forum agreed to align this work — moving the LSO APIs onto TM Forum's Gen5 Open API conventions release by release, with TM Forum contributing ODA, the Gen5 Domain Context Specialization APIs and the TMF909 NaaS suite as the layer that maps NaaS services onto network resources. In 2025 Mplify also joined GSMA Open Gateway, bringing LSO to wireline network APIs.
Mplify's reference architecture (MEF 55.1) for automating the lifecycle of connectivity services across a provider's own domains and between providers. It names the interface reference points — Legato between BSS and orchestration, Sonata between service providers, Interlude for inter-provider service control, Presto towards the network — and publishes APIs for them.
What problem does it solve?
Makes ordering, quoting and assuring a connectivity service between two carriers a machine-to-machine exchange instead of an email and a spreadsheet.
What does it cover?
•The LSO reference architecture and its interface reference points
•Sonata APIs for inter-provider quote, order, inventory and trouble ticketing
•Legato APIs between a provider's BSS and its service orchestration
•Alignment with TM Forum: in June 2024 MEF and TM Forum agreed to move the LSO APIs onto TM Forum's Gen5 Open API pattern (via Domain Context Specialization), release by release — treat an LSO API as Gen5-conformant only where its release notes say so
What does it NOT cover?
•Not the operator's internal product catalog or CRM model — its Product Catalog API (MEF 142) exposes offerings to buyers over Sonata and Cantata; it does not model the catalog itself.
•Does not define the internal decomposition of a service — CFS/RFS remains a TM Forum concept.
•Not a mobile standard; its heritage is carrier Ethernet and wholesale connectivity.
Where does it fit?
ApplicationServiceOSSAPIsOperations
When would an architect use this?
•Designing wholesale or partner connectivity ordering (Sonata)
•Placing a service orchestrator relative to BSS and the network (Legato / Presto)
•Multi-provider automation for SD-WAN, Ethernet and NaaS products
Mplify's programme for standardised, certifiable connectivity services consumed on demand — the reason MEF renamed itself Mplify in June 2025. It bundles service definitions (Carrier Ethernet, IP, SD-WAN, SASE), the LSO APIs to order and operate them, and certification of both providers and their implementations.
What problem does it solve?
Gives enterprises and partners a consistent way to buy connectivity across many providers, and gives providers a repeatable product they can automate end to end.
What does it cover?
•Standard service definitions with measurable attributes
•The LSO API set as the ordering and assurance interface
•Certification of services, providers and professionals
•Joint work with TM Forum on ODA / Open API alignment and with GSMA Open Gateway on wireline network APIs
What does it NOT cover?
•Not the operator's internal product catalog or a pricing framework — it standardises the product schemas exposed to buyers, not how they are modelled or priced inside.
•Does not replace the operator's own BSS; it standardises what the BSS exposes to partners.
Where does it fit?
BusinessServiceOSSAPIsNetwork
When would an architect use this?
•Defining a NaaS or wholesale connectivity product line
•Deciding which partner interfaces to standardise rather than build
•Evaluating whether a vendor's orchestration supports LSO reference points
TM Forum describes a provider's own BSS/OSS in depth and says little about the seam between providers. LSO says a great deal about that seam (Sonata) and about the BSS-to-orchestration seam (Legato), and little about what is inside either box. That is why they align rather than compete: a wholesale order arrives over Sonata, is decomposed with SID and the Open APIs inside the provider, and is pushed to the network over the orchestration-to-infrastructure interface Mplify calls Presto.