The resulting complexity grows not only with the number of Smart Meter Gateways. It has to operate multiple customer tenants, SMGWs from different manufacturers and generations, and different communication profiles and configurations, while meeting service arrangements that may vary from one client to another.
This is where a Network Management System becomes a distinct operational layer. It gives the GWA team one operational view of SMGW availability, connectivity and selected device parameters across the fleets it manages. Operators can monitor where gateways are unreachable, identify devices that require attention and investigate issues without switching between separate management tools for each customer.
The NMS scope described here covers the management functions that compatible WAN communications modules expose through LwM2M, an open standard for monitoring and managing connected devices remotely. Available diagnostic data and remote actions depend on the module and its firmware.
For GWA-as-a-Service providers, a shared NMS layer can reduce duplicated operational work across client fleets. Its value depends on the diagnostic visibility and remote management capabilities it adds to the provider’s existing tools.
A single metering point operator may source SMGWs, connectivity and field services from a limited number of suppliers. An external GWA, by contrast, inherits its clients' existing environments. Those clients may not use the same manufacturers, communications providers, rollout partners or backend platforms.
SMGW and communications module manufacturers and models,
supported available management data,
communications module firmware and the management functions available in each version,
agreed service levels and escalation paths,
connected GWA, ticketing and metering systems, and
permissions for internal teams, clients and external service partners.
Separate procedures for each client and device type can increase integration and support effort. A shared NMS layer can reduce that duplication by making diagnostic routines and supported device operations reusable, while retaining client-specific permissions and monitoring rules.
A multi-tenant NMS architecture must achieve two apparently conflicting goals at the same time: technical standardisation and strict client separation.
The external GWA gains a shared platform for technical operations, while each metering point operator can access only the devices, data and processes for which it is authorised.
This separation must extend beyond the user interface. It should also apply to APIs, data exports, automation, audit logs and service access.
The scalability of a GWA-as-a-Service offering is determined as soon as a new client is onboarded.
Before the first production device is connected, identities, roles, device models, communications paths, integrations and escalation procedures need to be defined. If every tenant is implemented as a custom project, onboarding takes longer and continues to consume specialist resources after launch.Over time, these differences can also limit operational visibility. GWA teams may have different views, diagnostics or management options available for different clients, making it harder to monitor the full fleet consistently and identify issues across tenants.
A standardised onboarding model therefore may define reusable building blocks:
Users, roles, service partners and permitted actions are mapped explicitly.
The SMGW identifier, communications module, LwM2M endpoint and client-specific references are connected.
Supported resources, reporting rules and permitted remote actions are defined for the relevant manufacturer and device type.
Device events, diagnostic data and operation results are delivered through APIs and event-driven integrations to the designated GWA, metering and service management systems.
Customer-specific monitoring thresholds and event routing can be configured in the NMS. Ticket handling, escalation rules and SLA assessment are configured in the provider’s service management systems, using NMS data where relevant.
Reusing validated onboarding templates can reduce the technical effort of adding clients with compatible devices and similar integration requirements.
An external GWA generally cannot require every client to use one SMGW model indefinitely. It inherits fleets shaped by previous procurement decisions, regional requirements and different rollout stages.
The NMS needs to handle these differences without losing visibility into what each SMGW can provide. LwM2M gives the GWA a standard way to monitor SMGW status and parameters and to perform supported remote management actions through the NMS. However, supporting LwM2M does not mean that every SMGW provides the same information or supports the same actions. The NMS therefore needs to know which Objects and Resources each communications module provides through LwM2M, so operators can see and use the capabilities that are actually available.
A vendor-independent operational layer should therefore be able to:
onboard new device types through defined profiles,
show the data and functions available for each device
control access to device-specific actions
apply common workflows only to compatible devices
clearly expose device-specific differences to other systems
Interoperability then comes from managing device differences deliberately, not from assuming that every implementation is identical.
GWA-as-a-Service is typically delivered through contractually defined services. Providers must therefore be able to demonstrate operating states, response times and completed actions to their clients.
An NMS can provide technical timestamps and events showing, for example:
when the NMS last received communication from the SMGW’s module,
when a reported condition or monitoring threshold triggered an event,
when a remote operation was requested,
what status or result the device reported, where available.
These records provide technical input for service reporting. The provider’s service management systems track tickets, response times and escalations, and assess performance against contractual SLAs.
Where an SLA concerns metering data delivery or gateway administration, this assessment also requires information from the relevant metering or GWA platform.
A shared NMS layer does not take over the responsibilities of the GWA process platform. It does not manage the metering point operator's market role or replace secure, regulated gateway administration processes.
The systems perform different tasks. The GWA platform remains the system of record for its regulated and business processes. The NMS provides the technical operations and management view of supported communications modules.
An external GWA can use a shared NMS alongside its gateway administration platform and connect technical events and operation results to the relevant client systems.
Where the provider operates multiple GWA platforms, integration with each platform must be defined separately.
External GWAs should evaluate more than the number of supported devices.
true tenant separation across users, data, APIs and automation,
role-based and traceable permissions,
support for heterogeneous devices and communications paths,
standards-based management through LwM2M,
possibility of integration with the provider’s GWA platform,
possibility of integration with relevant ITSM and client systems,
auditable event and action histories,
controlled bulk operations, and
a licensing and operating model that can grow with new tenants and devices.
The NMS then becomes a shared technical platform for the GWA-as-a-Service offering rather than another isolated system for each client.
Coiote NMS is an LwM2M-based platform for device, network and lifecycle management. In the SMGW environment, it can serve as a shared network management layer while existing GWA, metering and service platforms continue to perform their respective functions.
The practical starting point is to identify what the existing environment cannot show or do. A GWA or metering platform may flag a failed gateway transaction or missing readings without showing whether the problem is related to cellular connectivity, network registration or another communication issue.
Where compatible modules expose these resources through LwM2M, Coiote can provide additional detail, such as cellular signal measurements, network registration status and diagnostic results. It can also support remote configuration changes where the module implementation and operating permissions allow them. These capabilities help operators investigate the communications layer alongside the information already available in their GWA and metering systems.
Roles, device assignments, APIs and event-driven integrations connect the technical management view to tenant-specific processes. Vendor-dependent device information can be represented in a common model without concealing differences between supported implementations.
“For an external GWA, complexity increases not only with every additional gateway, but also with every new tenant and device variant. A shared NMS layer creates a reusable operational core without mixing client responsibilities,” says Rafał Kupis, Pre-sales Engineer at AVSystem.
For GWA-as-a-Service providers, this means that adding a new client does not have to mean creating a separate way to monitor and manage its devices. The same operational layer can be extended to the new tenant while keeping its devices, users and processes separated.
Do you operate SMGW fleets for multiple metering point operators?
Discover how Coiote provides a multi-tenant, vendor-independent NMS layer for your GWA-as-a-Service offering.