MEF 3.0 Certification Requirements for Carrier Ethernet Operators
Operators must prove sustained conformance across network boundaries, not just pass once.
MEF 3.0 certification sets out what Carrier Ethernet services must meet in their service definitions, in their performance, and across network boundaries. Its central demand is sustained operational conformance. For operators pursuing or maintaining certification, that means keeping service behavior, inter-operator configurations, and performance aligned with the standards as the network changes.
What MEF 3.0 certification is and what it actually validates
MEF, the global industry association now operating as Mplify, defines the Carrier Ethernet service specifications behind the certification program. Providers have services tested on live production networks, while vendors have products tested in labs against real-world deployment configurations. These are distinct validation settings, rather than interchangeable claims about a product and a deployed service.
Certification requires formal testing through a cloud-native platform based on virtualized network functions and cannot be self-declared. Testing must finish within six months of activation. The Mplify certification program provides three deliverables, namely a certification test record, a registry listing, and logo usage rights. The test record shows what was tested, while the listing and usage rights show which certification was earned.
The MEF 3.0 portfolio has been rebranded as Carrier Ethernet for Business, or CE for Business. Its technical requirements are identical, and existing MEF 3.0 certifications convert at no additional cost, with updated test dates and no infrastructure changes. Mplify announced a second track, CE for AI, with a targeted Q2 2026 launch. That track builds on CE for Business.
The service standards that define what operators must conform to
The standards divide into three categories, which are subscriber services, operator services enabling interconnection, and special topics. Subscriber service definitions describe the service the customer gets, while operator service definitions cover the connections that carry it across networks. A multi-operator service must meet the requirements for both the subscriber layer and the operator layer to conform.
MEF 26.2 governs the External Network-to-Network Interface, or ENNI. It specifies how Operator Virtual Connections, or OVCs, are managed across ENNIs spanning multiple operators. Its scope includes performance objectives, traffic management, service multiplexing, and OAM protocol handling at the ENNI. The Juniper MEF 3.0 validation framework documents the OVC management requirements and the O-Line, O-LAN, and O-Tree definitions and implementations under MEF 26.2.
CE for Business certification covers E-Line, E-LAN, E-Tree, Access E-Line, and Transit E-Line. CE for AI covers E-Line, Access E-Line, and Transit E-Line, with AI-specific performance objectives added to the business requirements. Certification tests the definitions and behaviors that apply to each service, so a claim that a network carries Ethernet traffic is too broad to show conformance.
Key service attributes operators must implement and prove
Within those service definitions, conformance turns on specific, testable attributes. Service multiplexing allows multiple Ethernet Virtual Connections, or EVCs, to terminate on the same User Network Interface, or UNI, while retaining traffic separation. For example, EVC1 for one customer and EVC2 for another can share the same physical interface. The requirement is not merely to support multiple connections, but to preserve the defined behavior when they share an interface.
Bandwidth profiles also set out exactly how traffic shaping and policing should behave in tests. Operators must show that both behave as MEF standards specify. Quality of Service parameters, including class of service and traffic management, must follow MEF-defined profiles even if operators have defined their own approximations. Operations, Administration, and Maintenance protocols must also function correctly at the relevant interfaces, including the ENNI for operator-layer services.
The Juniper validation framework illustrates how delivery mechanisms including EVPN-ELAN, EVPN-ETREE, and EVPN-VPWS map to MEF service types and their required behaviors. That mapping connects an implementation choice to the service definition it must satisfy. E-Access services, which provide wholesale point-to-point delivery from UNI to NNI, require implementation as Access EPL or Access EVPL. Those are distinct conformance targets, so proof for one cannot stand in for the other.
How OVC management at the ENNI works and why it is the hardest conformance layer
MEF 26.2 defines the ENNI as the interface between operators in a multi-operator Carrier Ethernet service. Both operators must independently implement its requirements for end-to-end conformance to hold. A correct internal implementation is necessary, but it is not enough to establish correct behavior across the joined networks.
OVC management requires performance objectives to hold across the ENNI span, traffic management policies to interoperate, and service multiplexing to remain correct as traffic crosses domains. OAM handling adds another shared obligation. Faults, performance measurements, and management signals must pass between the networks in ways that both sides have set up to follow the same specification. O-Line, O-LAN, and O-Tree provide the operator-layer definitions corresponding to E-Line, E-LAN, and E-Tree at the subscriber layer.
The operational difficulty follows from that shared responsibility. An operator building a multi-operator service must align its ENNI implementation with its interconnection partner’s implementation. Misaligned OVC configurations can degrade service in ways neither operator can fully diagnose alone. Interoperability testing therefore carries particular weight at this layer, validating whether a network works correctly when joined to another MEF-certified network. Deliberate implementation across the boundary is what makes the dependency manageable.
The performance objectives MEF 91 tests against, including the AI-specific tier
MEF 91 sets out how to test service performance against the objectives that apply to it. For CE for Business, the core parameters are frame delay, inter-frame delay variation, or jitter, and frame loss ratio. These apply across the business service types. Structural conformance establishes what a service must do, while performance testing establishes whether its measured behavior meets the required objectives.
The Mplify certification platform executes and logs tests through the cloud-native testing environment based on virtualized network functions. Providers set up test probes, activate the certification project, run tests through a web-based interface, and get a test record when testing is done. NFV-powered probes can also be deployed in labs for the relevant testing setting.
CE for AI uses the same MEF 91 methodology and the same three performance parameters. CE for AI uses AI-specific traffic profiles and tighter performance objectives beyond standard business service thresholds. CE for Business certification remains a prerequisite, so operators cannot bypass baseline conformance to pursue only the AI tier.
What the certification lifecycle requires operators to sustain, not just pass once
The Mplify certification lifecycle has two phases, which are initial certification and annual maintenance. Once initial testing is done, certification is valid for one year. Operators then renew each year through a maintenance process that allows renewal with or without re-testing. That distinction separates continued validity from refreshed evidence of conformance.
Paid renewal with re-testing extends validity by one year and includes up to two months of testing. Renewal without re-testing is free and also extends validity by one year, but it does not refresh test records. The lifecycle model also specifies annual maintenance fees, with a one-time initial certification cost followed by predictable annual maintenance.
Network change makes that distinction operationally important. Upgrades, configuration changes, and new service introductions must not break conformance before the next maintenance cycle. Re-testing is the mechanism for confirming that those changes have preserved the required behavior. Even when renewal needs no further test, an unchanged test record cannot show how later network changes have affected the service.
What professionals operating certified networks are expected to know
MEF-CECP is the professional certification for individuals and validates knowledge across the MEF 3.0 Carrier Ethernet domain. It complements infrastructure certification without replacing evidence that a service or product conforms. Its knowledge domains map to the operational layers under test, including service types, OAM, traffic management, and class of service. A professional holding MEF-CECP is expected to understand how those elements behave in a certified network.
That knowledge connects specifications to day-to-day implementation. Staff responsible for certified services need to recognize when a configuration or service behavior diverges from the applicable standard. Staff also need that understanding to assess changes before maintenance testing or to resolve an inter-operator mismatch.
What conformance looks like in practice across real operator deployments
IP Infusion’s OcNOS received MEF certification in October 2024 as the first open networking NOS to do so. The certification covered E-Line, including EPL and EVPL, E-LAN, including EP-LAN and EVP-LAN, and E-Tree, including EP-Tree and EVP-Tree. Testing used the UfiSpace S9510-28DC white box switch. This case demonstrates that disaggregated open networking hardware and software can meet MEF’s carrier-grade specifications. Conformance is not restricted to proprietary, integrated platforms.
Colt and AT&T jointly became the first to deploy LSO Sonata APIs in production, in partnership with each other. Integration with Colt’s On Demand service enabled straight-through provisioning within minutes. PCCW Global was also among the first with production-ready MEF 3.0 LSO Sonata APIs for serviceability, quoting, and ordering of Ethernet services. These cases illustrate the API-layer complement to service conformance, allowing carriers to participate in automated cross-carrier workflows. They show the operational payoff of standards-based interoperability rather than proving that service certification alone delivers provisioning automation.
Converge ICT Solutions achieved MEF 3.0 certification in 2026. The certification validated that its Carrier Ethernet services meet international benchmarks for performance, security, and interoperability. Taken together, these examples illustrate distinct outcomes, from conformance on an open networking stack to automated carrier workflows and validation of deployed services.
Why OSS architecture determines whether an operator can actually sustain MEF 3.0 conformance
The common requirement behind these layers is accurate, current service state. Service attributes must remain correct as networks change, OVC configurations must stay aligned across operators, and performance must be measurable on demand. To keep services in conformance, an OSS needs to track and enforce service attributes, audit changes, and manage state throughout the service lifecycle. Certification establishes the specification to meet, but keeping an implementation aligned with it requires operational architecture that supports conformance.
Fragmented tooling creates a structural obstacle to that alignment. When qualification, design, provisioning, and activation use separate tools and separate data models, service state can diverge between systems. The operator then lacks a dependable account of whether live configuration still matches the specification tested. A unified data model lets every stage of the lifecycle use the same service record, closing the reconciliation gap that can hide drift until re-testing. At the ENNI, that gap is especially consequential because configuration must also remain aligned with another operator’s network.
The AI tier extends this requirement from configuration state to performance state. To show frame delay, inter-frame delay variation, and frame loss ratio under AI traffic profiles, the OSS must hold up-to-date performance information in real time. AI agents that change certified services must also work within the same governed system as human operators. Shared APIs, audit trails, and permission structures make those actions traceable and reversible within the conformance record.
An AI-native OSS built on a unified data model is structurally better suited to this work than a fragmented stack. Its advantage rests on shared records and governed actions, with every service change logged, attributed, and testable against the applicable specification. That is the operational foundation of sustained MEF 3.0 conformance. The objective is not simply a network that passed certification, but a service lifecycle that preserves what the certification proved.
