+
+
+
We are often asked how Xmidt+Webpa compares to some alternative. It's a great
+question. By itself Xmidt is difficult to compare directly to other systems
+primarily due to the fundamental differences in architecture & different project
+goals.
+
+
Xmidt by design is not coupled with any data models.
+This allows for inclusion of all manor of data models. TR-181, TR-104, custom
+Msgpack or JSON are all no problem. Any system tightly coupled with one of the
+TR-181 | TR-104 | TR-357 | etc, fundamentally couple the service life of
+the entire ecosystem to the use of these particular models. Xmidt's architecture
+is designed to avoid this coupling. None of the other existing services have
+this design goal as a core system value.
+
+
Xmidt, Webpa, Codex and the ecosystem are designed to be an 'à la carte'
+solution. This includes the cloud components, the client components and the
+data models available. You get the choice of which services you want to deploy.
+The service you need may be to access the existing TR-181 or TR-104 data
+model on your device (Webpa+Webpa Client). It may be an alternative cloud
+managed event scheduler (Aker Client) or something that is custom and
+proprietary to your needs.
+
+
The Xmidt community's focus is to give you the easy to use building blocks so
+you can best assemble the system that works best for your use cases.
+
+
+
+
To help provide a basic comparison between the 3 solutions we usually get
+questions about, we are limited the scope to just TR-181 or similar access.
+
+
TR-069 and USP/TR-369 appear only available as proprietary only solution end
+to end.
+
+
+
+
+| Category |
+TR-069[2]
+ |
+USP[2]
+ |
+Xmidt+Webpa |
+
+
+
+
+| End-to-End Open Source Solution |
+ |
+ |
+ |
+
+
+| All Components Available via Business Friendly Apache 2.0 License |
+ |
+ |
+ |
+
+
+| Zero Licensing Costs |
+ |
+ |
+ |
+
+
+| Inclusive and Extensible Ecosystem at Client or Server Levels |
+ |
+ |
+ |
+
+
+| Supports Multiple Management Servers |
+ |
+ |
+ |
+
+
+| Has Efficient Data Encoding |
+ |
+ |
+ |
+
+
+| Has an Always-On Communication Mechanism |
+ |
+ |
+ |
+
+
+| Utilizes a Device:2 (TR-181i2) Driven Data Model |
+ |
+ |
+ |
+
+
+| Schema Drive Protocol Definition |
+ |
+ |
+ |
+
+
+| Defines a Robust Set of Operations |
+ |
+ |
+ |
+
+
+| May Leverage a Transport Layer Security Mechanism |
+ |
+ |
+ |
+
+
+| Provides an Access Control Mechanism[1]
+ |
+1/2 |
+ |
+ |
+
+
+| Provides a Secure Clean/Screen Solution for 3rd Party Services |
+ |
+ |
+ |
+
+
+| Easy to Scale (100 - +50M CPEs)[3]
+ |
+ |
+ |
+ |
+
+
+| Easy to Scale (100 - +100K events/second)[3]
+ |
+ |
+ |
+ |
+
+
+| Upgradable Without Outages at Scale[3]
+ |
+ |
+ |
+ |
+
+
+| Functions Properly With Complete Datacenter Failure[3]
+ |
+ |
+ |
+ |
+
+
+
+
+
Notes:
+
+
+-
+
* [1] - This is an 'à la carte' Xmidt feature where one available approach is to use partner-id
+
+-
+
* [2] - Depends on your vendor
+-
+
* [3] - Confirmed by the Comcast team
+
+
+
+ This documentation is open-source. Please help improve it by filing issues or pull requests.
+
+