Aker Design Philosophy
The existing CCSP based solution has a number of problems that created both operational issues as well as performance issues.
- On some architectures, sending messages across the CCSP bus can take upwards of 600ms.
- In the presently available CCSP implementation there is no reliable mechanism for performing bulk operations at the needed scale (100's of entries).
- The TR-181 table design limits the ability to define more complex behavior without increasing the complexity of the client (example: allowing multiple blockage windows in a 24h period without requiring periodic updates).
- Operationally, the TR-181 model combined with the CCSP implementation requires a significant number of requests to succeed in sequence, increasing the time needed and the potential for failure.
- Failure mode correction handling is significant both in terms of testing complexity and time needed.
- Idempotency
- Eliminate the need for server based scheduling engine
- Eliminate the need for altering schedules for DST transitions
- Enable arbitrarily complex schedules at no extra client complexity
- No homermobiles
One of the major operational and performance problems with the existing TR-181 design was due to the TR-181 object model itself. With each alteration to a large set of devices (think "block everyone"), the cloud needed to make an equal number of requests over the bus. There were ways around this, but they fundamentally amounted to putting all sorts of logic into a PA (Protocol Adapter) to handle the fact that this model was not efficient. At best putting logic in the PA results in a homermobile.
To resolve this issue we made the decision to simplify and move the complexity into the cloud. The cloud has two basic operations:
- Replace the document in effect.
- Retrieve the document in effect.
The document then defines all behaviors for all time for a particular local.
There are a couple of major problems with a list of MAC addresses and a start time and end time.
- It can't describe multiple blocking windows for the same device over a given amount of time.
- It takes a fair amount of processing each time the list is evaluated - which increases as the list size increases.
Both of these problems go away if the system is modeled as a time centric design. There are a fixed number of seconds in a week. The number of events during the week determines the processing time, not the number of MAC addresses. So if block groups of devices (common), the time centric approach saves you compute time and complexity. One moment in time can only have one list.
One time events can also be easily described by levering the absolute time structure. So dealing with those pesky holiday schedules or last minute changes that are to only be in effect "right now" but not "next week" expire simply because time passes. By leveraging this design pattern, no periodic cloud scheduler is needed.
Both message formats can represent the data, but MsgPack is amazingly more compact, easy to process, and with a smaller overall footprint (code and memory usage).
Parodus provides a simple way to connect to the Xmidt cloud. It has a very simple CRUD protocol built in that allows for web-like interactions on a small compute budget. By going directly to Parodus and bypassing CCSP entirely, Aker avoids the 600ms/message tax.