Berkeley Motes

The Berkeley motes are a family of embedded sensor nodes sharing roughly the same architecture.

Let us take the MICA mote as an example. The MICA motes have a two-CPU design. The main microcontroller (MCU), an Atmel ATmega103L, takes care of regular processing. A separate and much less capable coprocessor is only active when the MCU is being reprogrammed. The ATmega103L MCU has integrated 512 KB flash memory and 4 KB of data memory. Given these small memory sizes, writing software for motes is challenging. Ideally, programmers should be relieved from optimizing code at assembly level to keep code footprint small. However, high-level support and software services are not free. Being able to mix and match only necessary software components to support a particular application is essential to achieving a small footprint. A detailed discussion of the software architecture for motes.

In addition to the memory inside the MCU, a MICA mote also has a separate 512 KB flash memory unit that can hold data. Since the connection between the MCU and this external memory is via a low-speed serial peripheral interface (SPI) protocol, the external memory is more suited for storing data for later batch processing than for storing programs. The RF communication on MICA motes uses the TR1000 chip set (from RF Monolithics, Inc.) operating at 916 MHz band. With hardware accelerators, it can achieve a maximum of 50 kbps raw data rate. MICA motes implement a 40 kbps transmission rate. The transmission power can be digitally adjusted by software through a potentiometer (Maxim DS1804). The maximum transmission range is about 300 feet in open space.

Like other types of motes in the family, MICA motes support a 51 pin I/O extension connector. Sensors, actuators, serial I/O boards, or parallel I/O boards can be connected via the connector. A sensor/actuator board can host a temperature sensor, a light sensor, an accelerometer, a magnetometer, a microphone, and a beeper. The serial I/O (UART) connection allows the mote to communicate with a PC in real time. The parallel connection is primarily for downloading programs to the mote.

It is interesting to look at the energy consumption of various components on a MICA mote. A radio transmission bears the maximum power consumption. However, each radio packet (e.g., 30 bytes) only takes 4 ms to send, while listening to incoming packets turns the radio receiver ON all the time. The energy that can send one packet only supports the radio receiver for about 27 ms. Another observation is that there are huge differences among the power consumption levels in the active mode, the idle mode, and the suspend mode of the MCU. It is thus worthwhile from an energy-saving point of view to suspend the MCU and the RF receiver as long as possible.

Source of Information : Elsevier Wireless Networking Complete 2010

Read More

Sensor Node Hardware

Sensor node hardware can be grouped into three categories, each of which entails a different
set of trade-offs in the design choices.

● Augmented general-purpose computers: Examples include low-power PCs, embedded PCs (e.g., PC104), custom-designed PCs (e.g., Sensoria WINS NG nodes), 1 and various personal digital assistants (PDAs). These nodes typically run off-the-shelf (OTS) operating systems such as Win CE, Linux, or real-time operating systems and use standard wireless communication protocols such as Bluetooth or IEEE 802.11. Because of their relatively higher processing capability, they can accommodate a wide variety of sensors, ranging from simple microphones to more sophisticated video cameras. Compared with dedicated sensor nodes, PC-like platforms are more power hungry. However, when power is not an issue, these platforms have the advantage that they can leverage the availability of fully supported networking protocols, popular programming languages, middleware, and other OTS software.

● Dedicated embedded sensor nodes: Examples include the Berkeley mote family, the UCLA Medusa family, Ember nodes, 2 and MIT μ AMP. These platforms typically use commercial OTS (COTS) chip sets with emphasis on small form factor, low power processing and communication, and simple sensor interfaces. Because of their COTS CPU, these platforms typically support at least one programming language, such as C. However, in order to keep the program footprint small to accommodate their small memory size, programmers of these platforms are given full access to hardware but barely any operating system support. A classical example is the TinyOS platform and its companion programming language, nesC.

● System-on-chip (SoC) nodes: Examples of SoC hardware include smart dust, the BWRC picoradio node, and the PASTA node. 3 Designers of these platforms try to push the hardware limits by fundamentally rethinking the hardware architecture trade-offs for a sensor node at the chip design level. The goal is to find new ways of integrating CMOS, MEMS, and RF technologies to build extremely low power and small footprint sensor nodes that still provide certain sensing, computation, and communication capabilities. Since most of these platforms are currently in the research pipeline with no predefined instruction set, there is no software platform support available.

Source of Information : Elsevier Wireless Networking Complete 2010

Read More

Sensor Network Platforms and Tools

We discussed various aspects of sensor networks, including sensing and estimation, networking, infrastructure services, sensor tasking, and data storage and query. A real-world sensor network application most likely has to incorporate all these elements, subject to energy, bandwidth, computation, storage, and real-time constraints. This makes sensor network application development quite different from traditional distributed system development or database programming. With ad hoc deployment and frequently changing network topology, a sensor network application can hardly assume an always-on infrastructure that provides reliable services such as optimal routing, global directories, or service discovery.

There are two types of programming for sensor networks, those carried out by end users and those performed by application developers. An end user may view a sensor network as a pool of data and interact with the network via queries. Just as with query languages for database systems like SQL, a good sensor network programming language should be expressive enough to encode application logic at a high level of abstraction, and at the same time be structured enough to allow efficient execution on the distributed platform. Ideally, the end users should be shielded away from details of how sensors are organized and how nodes communicate.

On the other hand, an application developer must provide end users of a sensor network with the capabilities of data acquisition, processing, and storage. Unlike general distributed or database systems, collaborative signal and information processing (CSIP) software comprises reactive, concurrent, distributed programs running on ad hoc, resource-constrained, unreliable computation and communication platforms. Developers at this level have to deal with all kinds of uncertainty in the real world. For example, signals are noisy, events can happen at the same time, communication and computation take time, communications may be unreliable, battery life is limited, and so on. Moreover, because of the amount of domain knowledge required, application developers are typically signal and information processing specialists, rather than operating systems and networking experts. How to provide appropriate programming abstractions to these application writers is a key challenge for sensor network software development. In this chapter, we focus on software design issues to support this type of programming.

To make our discussion of these software issues concrete, we first give an overview of a few representative sensor node hardware platforms. We present the challenges of sensor network programming due to the massively concurrent interaction with the physical world. TinyOS for Berkeley motes and two types of nodecentric programming interfaces: an imperative language, nesC, and a dataflow-style language, TinyGALS. Node-centric designs are typically supported by node-level simulators such as ns-2 and TOSSIM. State-centric programming is a step toward programming beyond individual nodes. It gives programmers platform support for thinking in high-level abstractions, such as the state of the phenomena of interest over space and time.

Source of Information : Elsevier Wireless Networking Complete 2010

Read More

Ad Hoc Wireless Sensor Networks

Advances in microelectronics technology have made it possible to build inexpensive, low-power, miniature sensing devices. Equipped with a microprocessor, memory, radio, and battery, such devices can now combine the functions of sensing, computing, and wireless communication into miniature smart sensor nodes , also called motes . Since smart sensors need not be tethered to any infrastructure because of on-board radio and battery, their main utility lies in being ad hoc, in the sense that they can be rapidly deployed by randomly strewing them over a region of interest. Several applications of such wireless sensor networks have been proposed, and there have also been several experimental deployments. Example applications are:

● Ecological Monitoring: wild-life in conservation areas, remote lakes, forest fi res.

● Monitoring of Large Structures: bridges, buildings, ships, and large machinery, such as turbines.

● Industrial Measurement and Control: measurement of various environment and process parameters in very large factories, such as continuous process chemical plants.

● Navigation Assistance: guidance through the geographical area where the sensor network is deployed.

● Defense Applications: monitoring of intrusion into remote border areas; detection, identification, and tracking of intruding personnel or vehicles.

The ad hoc nature of these wireless sensor networks means that the devices and the wireless links will not be laid out to achieve a planned topology. During the operation, sensors would be difficult or even impossible to access and hence their network needs to operate autonomously. Moreover, with time it is possible that sensors fail (one reason being battery drain) and cannot be replaced. It is, therefore, essential that sensors learn about each other and organize into a network on their own. Another crucial requirement is that since sensors may often be deployed randomly (e.g., simply strewn from an aircraft), in order to be useful, the devices need to determine their locations. In the absence of a centralized control, this whole process of self-organization needs to be carried out in a distributed fashion. In a sensor network, there is usually a single, global objective to be achieved. For example, in a surveillance application, a sensor network may be deployed to detect intruders. The global objective here is intrusion detection. This can be contrasted with multihop wireless mesh networks , where we have a collection of source – destination pairs, and each pair is interested in optimizing its individual performance metric. Another characteristic feature of sensor networks appears in the packet scheduling algorithms used. Sensor nodes are battery-powered and the batteries cannot be replaced. Hence, energy-aware packet scheduling is of crucial importance.

A smart sensor may have only modest computing power, but the ability to communicate allows a group of sensors to collaborate to execute tasks more complex than just sensing and forwarding the information, as in traditional sensor arrays. Hence, they may be involved in online processing of sensed data in a distributed fashion so as to yield partial or even complete results to an observer, thereby facilitating control applications, interactive computing, and querying. A distributed computing approach will also be energy-efficient as compared to mere data dissemination since it will avoid energy consumption in long haul transport of the measurements to the observer; this is of particular importance since sensors could be used in large numbers due to their low cost, yielding very high resolutions and large volumes of sensed data. Further, by arranging computations among only the neighboring sensors the number of transmissions is reduced, thereby saving transmission energy. A simple class of distributed computing algorithms would require each sensor to periodically exchange the results of local computation with the neighboring sensors. Thus the design of distributed signal processing and computation algorithms, and the mapping of these algorithms onto a network, is an important aspect of sensor network design.

Design and analysis of sensor networks must take into account the native capabilities of the nodes, as well as architectural features of the network. We assume that the sensor nodes are not mobile . Further, nodes are not equipped with position-sensing technology , like the Global Positioning System (GPS). However, each node can set its transmit power at an appropriate level — each node can exercise power control . Further, each node has an associated sensing radius ; events occurring within a circle of this radius centered at the sensor can be detected.

In general, a sensor network can have multiple sinks, where the traffic generated by the sensor sources leaves the network. We consider networks in which only a single sink is present. Further, we will be concerned with situations in which sensors are randomly deployed . In many scenarios of practical interest, preplanned placing of sensors is infeasible, leaving random deployment as the only practical alternative; e.g., consider a large terrain that is to be populated with sensors for surveillance purposes. In addition, random deployment is a convenient assumption for analytical tractability in models. Our study will also assume a simple path loss model , with no shadowing and no fading in the environment.

Source of Information : Elsevier Wireless Networking Complete 2010

Read More

MOBILE WEB CONSIDERATIONS

What makes a good mobile website? This is an impossible question to answer, because design and taste are always highly subjective matters. But certain considerations are worth bearing in mind from the start, and these considerations will undoubtedly help you create positive user experiences for your mobile users.



Recognizing Mobile Users
It should go without saying that the most important aspect to developing a mobile website is to ensure that it is available and easy to reach! This sounds straightforward, of course, but it can
actually become relatively involved: It ’ s a fair assumption that existing site owners are very careful to promote and use their current website URL consistently. If you want to create a separate site for your mobile users, should it be a different URL? Should it appear on the same URL? If so, how does the server or CMS know whether to present one type of site or another? How can you cater to user choice and potentially let them switch back and forth between your desktop and mobile sites? How can you publicize the (attractive) fact that the mobile site exists at all? And ensure that it is correctly listed in search engines and directories?

There are glib answers to all these questions, but each has a level of subtly to it, and no matter which technique you use for hosting, selecting, and publicizing your mobile presence, it is inevitable that you will have to distinguish between mobile users and desktop users. In reality, this means detecting between mobile and desktop browsers and then providing different sites or templates accordingly. Users find content in the strangest ways, and it remains the site owner ’ s responsibility to ensure that the right type of experience is given to each type of user. You look at a number of techniques for doing this, both in the general sense, but also for specific content management systems.



Thematic Consistency
A web standards body, the W3C, uses the term thematic consistency . This is not, as you may think, related to themes or the cosmetics of a site, but to the fact that according to the body ’ s “ One Web ” philosophy, the whole Web should be accessible from any device — so given a specific URL, any browser should receive the same content.

This is not to say that the same content should look the same (because the theming of a mobile
web page can be often very different to that of its equivalent desktop page), nor even that users on different devices want to see the same content (because they are quite possibly in a different context, looking for possibly very different things).

But the One Web philosophy is valuable and important, and indeed URLs should always be used in a way that honors the Uniform adjective of the acronym. It would be counterproductive for the
whole mobile web movement if it were to become a disconnected ghetto of content targeted at one type of device alone and did not share links, resources, and content with the vast existing Web.
When you are building your mobile website, think carefully about how its information architecture is sympathetic to this: The same posts, pages, articles, products, and so forth should be easily and consistently accessible from all types of browsers, even if their appearance and surrounding user - interface may be radically different.



Brand Consistency
It is also important to ensure that your own website ’ s brand is preserved between its mobile and desktop versions. There should be consistency between the theming, color schemes, and the look and feel of different types of sites. If your desktop site is light and airy and your mobile site is dark and cluttered, you will confuse your users, many of whom may remember what your desktop site looks like and may find it hard to correlate that with the mobile site, damaging their trust in your brand or site.

The same goes for your logo, color scheme, feature images, graphical elements and so on; within reason you should endeavor to reuse as much as possible between the two sites. Users need to feel that they are interacting with the same brand while being given an entirely optimized, mobile - centric experience.

Similarly, if your desktop site is renowned for a simple, cheerful, and highly efficient user interface and experience, your mobile users will expect the same of the mobile site. Indeed, due to its constraints, a mobile website obviously needs to have even more attention paid to its usability!



A Dedication to Usability
With limited real estate (both physically and in terms of pixels) and often very different input
techniques — not to mention the fact that users may be in a more time - sensitive context, and with a slower network connection — a mobile device needs to be presented with a site interface that is as efficient to use as possible. At the very least, consider carefully any use of excessive forms, multi - paged wizards to complete common or simple tasks, or complex menus to get to critical functionality. These are not likely to be appreciated by mobile users.

Instead, think hard about what mobile users want to do, and ensure that those critical tasks are as heavily optimized as possible on the mobile version of the interface. Arguably this was one of the big successes of the “ native app ” phenomenon: Although many apps were little more than
views of a company ’ s existing web content, the app paradigm allowed interface designers to think entirely afresh about how it could be accessed. The popular pattern of a toolbar at the bottom of an app ’ s screen with four or five important tasks that can be reached with a thumb seems a long way from the lengthy and complex menu bar across the top of a website, but it shows that the same information architecture and fundamental functionality can always be accessed using different user interface techniques. Think hard about which techniques work best for the new medium and types of devices you are targeting.



Remember Mobile
Finally, remember the point about the mobile device being so much more than merely a browser on a small screen. Yes, it ’ s phone, an address book, a game console, and so on, but it ’ s also a device that is in the user ’ s hand nearly every hour of the day, a device that brings unique capabilities and possibilities for you to design to.

Never forget that your mobile is an adjective, not a noun. The important point about the mobile
web is not that the user is holding a mobile phone, but that she is mobile. Make the most of the fact that the visitors to your website don ’ t just have a small screen, rather they are out and about in the real world, living their lives, staying connected — and they want to access everything you have to offer, whenever they want it, in a wonderful mobile way.

Source of Information : Wiley - Professional Mobile Web Development with WordPress Joomla and Drupal

Read More

REVISITING ASSUMPTIONS

Before embarking upon a discussion about the practicalities of developing mobile websites, let ’s
think about some of the opportunities that a mobile web brings and how it should encourage you to revisit many of the assumptions you may have made about today ’ s desktop web.

New places: Whether it ’ s on a train, waiting in line at a bus stop or an airport, walking down a street, working in the fields, lounging on the beach, or snatching glances while driving a car, humans now have the opportunity to access websites from a whole host of new locations — places where it is impractical or impossible to use a desktop or laptop computer. The desktop web gets used from home, the office, and possibly café s and kiosks, but places and situations where users can access the mobile web are innumerable. Think how you can adapt your services and content to cater to people visiting your site from these novel contexts, and with the rise of geolocation capabilities in some modern browsers, you can even start to key your content off them.


New users: The mobile web creates the opportunity to place web content into the hands of new users altogether. It is easy to think that everyone has regular access to a computer connected the Internet, and in some developed markets and for certain demographic groups, that ’ s true. But the availability of fi xed Internet access is already dwarfed by that via mobile devices. The International Telecommunications Union (ITU) estimates that there are 13.6 mobile 3G subscriptions for every 100 people (compared to 8 fi xed broadband connections). But even that is just the start: Only 1 billion of the world ’ s 5.3 billion mobile subscribers have 3G connections. If that proportion grows rapidly over the current years, there will be literally billions of new mobile web users around the world. Suffice to say that this sheer volume can be a huge opportunity for site owners to capitalize on.


New marketing, new business models: The mobile web provides a new way to reach potential
and existing customers. If you run an online business, or an offline one that relies on online marking and promotion, this can significantly open the possibilities for you to grow and
develop your business. Through localized and targeted mobile advertising, you can reach users who are perhaps more in need of your services than ever (a web search for “ plumber ” on a mobile device might imply that the user is in more urgent need of service than from a high - and - dry desktop browser!), and location - based social networks providing check - in functionality (such as Facebook, foursquare, and the like) look set to offer exciting new ways to promote and market certain types of businesses. But the mobile medium itself provides the opportunity for new fulfillment and business models altogether. From phone - based voucher techniques, to games with in - app purchasing, to near - field communication - based commerce, the mobile device offers new ways to interact with customers and create business opportunities.


New types of relationships: Often overlooked is that fact that the mobile web is a medium viewed through the screen of what many consider to be a highly personal piece of consumer electronics. With them all the time and normally held close to their body, the mobile phone is more to many users than simply another gadget: It is their primary link with their friends, their families, and their online lives. A computer rarely engenders as much love and care as a mobile phone, and many believe that this can be an important facet to consider when developing mobile web services. Bland, impersonal web pages might jar with a user ’s perception of what his mobile device represents; he may expect the mobile web to be more immersive, more customized, more personal, and more social. As a site owner, you need to consider how your online presence can capitalize on this more emotional relationship between the user and the medium.


One final point is arguably more important than all of these, and it ’ s one that sows the seeds for
you to be able to really explore the possibility of the mobile web: The mobile phone is so much more than simply a piece of hardware upon which a lonely browser runs. Today ’ s mobile devices are truly the Swiss Army knives of modern society: a phone, an address book, a calendar, a camera, a music player, a compass, a messaging terminal, a game console, and now a web client.

Even if it simply results in ensuring that your business website has a click - to - call link with your telephone number (so the user can dial you straight from the page), keeping this fact in mind is an important step in crafting the shape of this new medium. Using geolocation; allowing social media interactions with users ’ friends and contacts; uploading photos directly from a camera; building web applications that respond to phone orientation, temperature, light levels — the list of ways in which a mobile device could be a more capable web client than a desktop one is almost endless. It ’ s true that this is still an area of much standardization work (privacy and security are important considerations, of course). But what is truly exciting about the potential of the mobile web is that you have barely glimpsed at the possibilities gained by aligning web - based services with the diverse capabilities of these amazing little devices.

Source of Information : Wiley - Professional Mobile Web Development with WordPress Joomla and Drupal

Read More

A NEW MEDIUM

So what is this mobile web, and why is it something so different that it deserves whole books dedicated to it? Well, on one hand, it is nothing dramatic at all. The fundamental idea is still that you have a browser, a server, some standardized protocols and file formats passing between them, and a user who can view and traverse through content provided by site owners.

And you ’ ve now reached a point where, more or less, those protocols and fi les are written, produced, and interpreted in the same way on a desktop or laptop computer as they are on a mobile device. For markup, most mobile devices accept and handle some sort of XHTML or HTML5; for graphics, they can display PNG, GIF, or JPEG files with high color depth; for styling, at least simple forms of CSS should be understood and interpreted in some way; and, on contemporary devices, JavaScript is feasible for adding interactivity to a mobile website.

So far, so familiar. In terms of technology, you are more or less on familiar ground. You should be careful of one or two things: Flash and Silverlight, for example, are not recommended for widespread use on mobile handsets, because there are major swathes of devices that do not support either, so they should be used selectively at most.

But despite the fact that they build on the same standards, you do need to treat mobile browsers significantly differently from desktop ones. Some of the reasons for this are still technical in nature. A mobile network is not the same as a landline Internet connection, for example. There are considerations of throughput and latency — not to mention a possible cost to the subscriber — when a mobile device is accessing a website over a cellular network. Sensibly, a mobile website should be extremely considerate toward the requirements it makes on the network; large, unwieldy pages that are slow to display and render are clearly not well suited to the challenge.

Also, despite huge advances in processor power and graphics acceleration, most mobile browsers are running on hardware that is well below the specification of an average computer. Sites that put undue load on the CPU or even GPU of a mobile device are likely to be more sluggish than the same site on a desktop device. And even if the handset can provide a decent user experience for such a page, it probably comes at the expense of temperature or battery usage, something that is still at a premium in most handheld devices.

Finally, of course, a mobile device has a different form factor and size to a desktop computer. It certainly has a smaller screen, probably with a different default orientation, and may lack a physical keyboard and almost certainly lacks a mouse. Any website that makes desktop - based assumptions about a particular type of input device or screen size undoubtedly provides a suboptimal experience on a mobile device. For these reasons alone, it is worth thinking about the mobile web as a different medium than the desktop - centric Web that we all use.

But that ’ s not the whole story. Consider cinema and television, for example. There are certainly similarities between them: Both present visual information on screens, people sit and view them,
and both can display the same material in theory. But there is still no doubt that the two are treated as distinct media — even spawning entirely separate industries. Is there more to that distinction than simply the fact that the two have different sized screens?

Yes, of course. And the differences are context and user expectation. A cinema - goer is in a distinct state of mind: possibly out for the evening with friends or family, prepared to pay money for a very particular piece of visual entertainment, and amenable to being presented with a solid period of rich, visual storytelling — the movie he ’ s selected. The television occasionally gets used in this way, of course, but also services different sorts of expectation from its users: turning it on quickly to catch the news, short episodic programming, children ’ s ad - hoc entertainment, or even just as background noise. The way humans want to interact with the technology determines how content gets created for it.

So it is with the mobile web. Yes, many mobile devices can render the same websites as those designed for a desktop screen, but apart from the technical limitations of doing so, the ways in
which the two technologies actually get used can also be very different. A desktop user is sedentary, probably relatively comfortable, and quite probably using the Web for a lengthy session, either professionally or for leisure. A mobile user, snatching time to use her handheld browser, perhaps on the move, is more likely to have a shorter browsing session, has a focused goal in mind, and is far less likely to surf aimlessly about. The mobile user can easily be in a distinctly different state of mind and bringing an entirely different set of expectations to his web browsing experience.

Of course, there will be individual websites where exactly the same content, and exactly the same design, can be presented to multiple types of devices and users in different contexts. A site that comprises merely a simple collection of plain text documents, for example, probably doesn ’ t need to change significantly between mobile and desktop consumption (assuming the layout and typography adapts to different physical constraints).

But few sites on today ’ s Web are as static and immutable as that. Through the prevalence of content management systems, even the simplest personal website is database - driven, dynamically themed, administered online, and encouraging of reader feedback. Not only is it valuable to think about how different types of readers might want to consume the information on such a site, but it ’ s extremely easy to implement solutions that take account of the types of browsers they use, reformatting the page, promoting different sections of the site, resizing graphics for different screens, and so on.

From a site owner ’ s point of view, this is exciting: The mobile web is a distinct enough new medium to consider as a priority when designing and building a site, so it ’ s arguably a revolution . But from a practical point of view on the server, its implementation is merely an evolution : You can use today ’ s tools, today ’ s plug - ins, and your existing experience, and you can make use of the current content and functionality that you provide to the homogenous desktop user base and potentially get it into the hands of billions of mobile users.

Source of Information : Wiley - Professional Mobile Web Development with WordPress Joomla and Drupal

Read More