Saturday, April 22, 2006

Data dissemination completed

It's been like the worst times, digesting them all and not finalizing them, I should make this moment, a moment to compose all in one.

There should be a ThreshValue on mobile nodes, configurable to the signal strength(interested in backchannel bandwidth), for controlling the push or pull behavior.

Push mode is bandwidth preserving in any environment, whether it's wired/wireless, I only difference is that it matters the most in wireless. But, at the end of day it depends on what's at application layer.

Let's try to classify this,
  • 1. Parameterised service mode, (prime communication mode i.e. unicast pull)

  • 2. Subscription mode, (service data broadcasts i.e. multicast push, if any by service to subscribers, broadcast items with highest count on Longest Wait First.)

  • 3. Regular housekeeping communications, (handoff communication)

  • 4. Parameterised housekeeping data transfer (code mobility, execution state transfer)

  • 5. Parameterised service mode with multicast pull (aggregation of same request over a time span, hard to realize usability in practical cases, depends on usability, it's a intermediate stage between switching from 1 to 2)



I assume above all would be the communication modes, which all are required to be supported by the framework. Push characteristics of Message brokers can be used very effectively in 2 and 3. Ofcourse, In all cases, Message brokers would be used for data stroage for data availability.

An extremly good approach I feel is to broadcase hash-index of to-be multicast push items to subscribers to defer their unicast pull.

A important point to note here is, Heat adversely effects the reliability of the digital circuits and increases costs for cooling especially in servers. In order to access the desired data, a client has to be in active mode, waiting for the data to appear on the multicast. Enabling reliable communication on the message broker could be helpful in the sense of truly providing the intermittent devices asynchronous access to data. An broadcast indexing would make things even much better. The only low point is that in MANET, we don't have any super devices, all are peers, hence to save clients heat and effectively utilize Back Chaneel bandwidth, we require memory at the serving peer (so called server in Client Server environment).

Thursday, April 20, 2006

About sensors workage

I came across a very interesting fact about working and robustness of currently deployed sensors, it is,

For a sensor network to maintain a lifetime of several years, for example, the radio’s duty cycle—the ratio of time the radio is on over time that the radio is actively sending or receiving a message—must typically be less than 1 percent.

Sunday, April 09, 2006

Providing Push or Pull in MANET

Asymmetry happens in MANET not only due to communication behavior, but also due to

  • Ratio of clients and servers

  • Difference in downlink bandwidth and uplink ones

  • Data Volume

  • Hot data items


Push has a obvious advantage in MANET, as it

  • takes same bandwidth for any subscribers

  • Conserves energy by eliminating energy consuming uplink transmission, yields only if needy items are pushed

  • Backchannel is missing or having poor bandwidth


Pull is also needed in MANET, as it

  • is required for custom query or in on-demand mode

  • much prefered mode when authorization is required.


A very interesting fact in regard to hot data items data dissemination is,
If p1,p2....,pn are the popularity ratios of data item, then their broadcast frequencies are f1,f2,...,fn, where fk = sqrt(pk)/sum of (sqrt(pks)) (By a paper of Imielinski et al)

Obviously, it is very favoring result for the push mode if we can sort hot data items at the cost of average access latencies of data items.