Pipeline Publishing, Volume 5, Issue 4

	This Month's Issue:
	Enabling Innovation

The co-Evolution of Networks and Devices: Autonomics and Device Management

article page | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 |

Devices with service capability will interact with Data. Devices like sensors will capture environmental data. Meshed smart phones might see and even capture data about other user/owners. So device management must meet the regulatory requirements of personal data management. Configuration data and dynamically collected data may affect the health and behavior of devices and also influence their relationship to other devices in local and remote cluster groupings. Little standardization exists on how to manage data, yet data management must clearly also be part of a device management framework.

So Many Twists and Turns!

Current forms of device management will not cut it. It is not just a scaling issue, nor is it just a complexity issue.

Every headache that exists in connecting computers to wide area networks also exists with smart devices. A service provider engineer using the pseudonym John G Galt, complains that downloaded javascript services currently are severely impacting both the computer/smart device and the network, which must react to the device requests. He describes "babblers," which push continual, non meaningful noise through the boxes and up to the network, and "gobbers," which pull down data and consume local and network resources. Unsuspecting users download these not knowing what impact these services will have, and then, once affected, not knowing where the impact originates. Few knew that when downloading the free Skype peer-to-peer phone service that they opened their computer to continually run data updates and routing computations for the Skype network; and that this would mean constant network usage, not just during calls. So any device management framework must include debugging tools. Debugging, either pre or post launch, is not part of the current OTT service market.

But should debugging requirements be part of the service provider market? Is this the responsibility of the service provider? When you envision the network in the middle and all devices connected slavishly to the network, device debugging requirements would clearly fall to the service provider (think big labs). We argue that certainly the effects must be monitored, but we are uncertain that the ownership of the problem lies with the network provider. One can just as easily invert the framework model and put the smart phone in the middle. Then the problem should be owned by the manufacturer of the device. Certainly Apple believes in the opportunity of the vendor to provide the configuration and service installation (and the sales of such). But there do not seem to be, for example, onboard debugging tools in the iPhone. Currently, that is the domain of the hacker identifying a problem and the blogger reporting it.

We have looked for some out-of-the-box-thinking reference models and toyed with either cars in a system of highways or schools of fish. Both involve autonomous control within the element (fish brain or car driver).

John G. Galt, "I predict gadget downloads to your desktop are going to be the next hackers heaven." Soon smart phones, like unsecured operating systems on computers, will be platforms attacked by worms becoming participants in denial of service attacks. Galt also is on the lookout for installations of billing malware. The threats from doing nothing are significant. But it is not clear who owns this problem and must react. Complications arise from ownership of the device. Once network connected devices were owned by the service provider, then they were owned by the individual or the enterprise. Once we have answered the question of ownership, we must then consider responsibility. If the user's smart phone participates in a denial of service attack, is the user legally responsible? Is the network carrying the traffic responsible? Is the web hosting center with inadequate threshold security responsible? Or is the US government who licenses the DNS system responsible? Figuring this out should be part of the determinations and suggestions of the TMForum Device Management Initiative.

Of course, these are only a few of the many ways devices need to automatically respond to stimulators and conditions. The only technical solution we see is that devices must incorporate policy enforcers that get policy from policy servers. Fortunately, we do have existing policy management standards. But to date, only network elements and some advanced CPE enact these. In the future, smart devices would enforce policy received from network or from vendor-resident policy control points with a device-resident Policy Enforcement Point (PEP). In some cases the Policy Decision Point and the PEP would both reside on a smart device such as a mobile phone.

An unavoidable implication of devices getting more powerful is an increase in the sophistication of services that run on the device and that engage resources inside networks. What is to stop these from being management services? After all, on a power limited budget, it's 1000x cheaper to process locally than communicate via radio with the network. Evolution of devices into participants in P2P autonomous networks is occurring now. What is to stop these smart devices from brokering services into that mesh network? Smart devices will also begin to control local mesh networks composed of

article page | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 |

© 2006, All information contained herein is the sole property of Pipeline Publishing, LLC. Pipeline Publishing LLC reserves all rights and privileges regarding
the use of this information. Any unauthorized use, such as copying, modifying, or reprinting, will be prosecuted under the fullest extent under the governing law.