Project ProxMe Week4

The devil is in the details.

If we want to do auto sharing information by one-click, there're many things need to be done after that click.

It will take 12s for the BT device to scan nearby device, 4s to test the convertibility for ALL nearby devices, and 4s to pair the device for communication. This add up to 20s waiting before the data transmission start! Unfortunately, there's not much I can do at the lower layer to speed up the process. So, this needs some thought to improve user experience.

My solution is to scatter each of those steps in the entire program execution time, and utilize multi-thread. The hard part is thread synchronization, I need to carefully sharing data and device, after all, there's only one BT device on smart phone.

Status

• Refine program structure
  
  • Follow MVC, More cohesive, less coupled
    
• Implement communication services via Bluetooth
  
  • Multi-thread concurrency control on BT device
    
  • Discover -> Pair -> Connect
    
• Play with SQLite DB
  
  • Add, delete, modify, search on Contact book
    

To-do

• Create Service to search nearby devices
  
  • Periodically scan, find tradeoff between responsiveness and energy preservation
    
• Refine use-case
  
  • Save event info when saving new Contact
    
  • Simplify user operation
    
• Documentation
  
  • For stabilized version
    

Project ProxMe Week3

I added the following functions to our prototype:

1. Discover connectable devices, particularly, the cell phones that running ProxMe App.
   
2. Setup socket for one-to-one communication.
   

To do list:

1. A Service that periodically checking nearby device and send out notifications
   
2. One-to-many communication
   
3. Auto pairing
   

A new idea: when saving a contact information, we should provide/auto-filled some information about the meeting. Such as, when, where and how we meet that person.

I found several names in my address book looks fairly strange, I cannot remember who they are and how I know them.

If I'm going to contact someone, it's useful to be able to start with "hello, we met last Dec at event something in somewhere, and got talking about blahblah…" before launching into what I want, and that's polite, I guess?

Shuang's part

Shuang is working on getting the user's profile and makes it available to others. We would prefer to have the cell phone owner's info from their address book. If that is not available, we will use the Bluetooth's default device name. He's also investigating on the notification mechanism.

Project ProxMe Week2

We finished our first demo on schedule and made the presentation in class.
Next, we are going to work on exchange contact .
We did not have a nice looking class diagram for our program design, instead we have the following plan:

while(!reachDeadline){

Identify use case;

Code and test small parts;

Merge together;

Refine structure;

Documentation;

}

Project ProxME Week1

We're thinking start with prototype of small components. Iteratively increase the features, here's a tentative outline:

1. Scan nearby BT device, get MAC
   
2. Store MAC to Contact, along with a msg
   
3. Notify user when listed BT is discovered, show msg
   

• ------------ First demo on Oct 25 -------------
  

1. Exchange contact
   
2. Auto BT Scan, always discoverable on
   
3. Gesture/movement control
   

   
    

I start with step 1, Shuang is looking into 2.

Paper Review: Understanding Packet Delivery Performance In Dense Wireless Sensor Networks

J. Zhao and R. Govindan, November 2003

This paper studies the volatility and indeterminacy in packet delivery of wireless sensor network. They measured the link quality in three different environments: indoor office, habitat and open parking lot with a medium-scale development of 60 Mica motes.

Their key observation is the existence of "gray area", which "in some environments, is almost a third of the communication range". In their indoor experiment, half of the links experienced more than 10% packet loss, and a third more than 30%. To make thing more complicate, they observed that the gray area changes significantly over time.

Their second observation is that, there's no easy way to measure or estimate poor quality links. At MAC layer lever, they investigate on five factors that may affect packet transmission, they asked the following questions: 1) how distance affects packet reception, 2) whether signal strength could be used to estimate link quality, 3) whether sophisticated coding schemes will help to mask gray area 4) is there a correlation between adjacent node 5) how does packet delivery vary with time. Their answer to these questions, however, does not give optimistic result to these questions.

The last observation in their study is the asymmetric communication between nodes. At the medium access layer, they found that more than 10% of the links exhibits asymmetric packet loss in their indoor experiment. Another disappointing finding in their experiment is that, 50% to 80% of the communication energy is wasted on repairing lost transmissions.

Maybe not too bad

In my opinion, the negative impact of gray area is more depends on the application of a particular system rather than a critical problem of wireless sensor network in general. For example, gray area problem is more complicated in mobile networks than in static networks. According to different usage and implementation, we could minimize the impact of gray area by properly deploy the sensors to its suitable location or use a router algorithm that will snoop on reliable communication paths.

Snooping on surrounding traffic probably is the best solution from a protocol designer's aspect, but maybe simpler solution will also help to solve the problem. We have a similar problem when installing Wi-Fi access points inside a building. The solution for reducing interference and get best coverage is to carefully selection the installation location. I think we can use the same idea when deploying sensor nodes. Instead of placing nodes equally after a certain distance, we might want to place them inside the range where they can get a good signal.

Except for data-intensive wireless network, we can afford packet loss to some point. For many applications such as forest fire sensing and agriculture monitoring, there's not much data needs to be transmitted and doesn't need to have a persistent connection of the entire network. Particularly, given that we could nicely synchronize each node, I guess we could use some kind of smart scheduling method to reduce interference between different nodes.

What could affect the packet delivery?

This paper gives a good description about the relationship between different factors and packet delivery performance in their experiment environment. But it doesn't provide an explanation of what caused those phenomenons. The paper gives some hypothesis such as multi-path, frequency spectrum under use and difference between devices. But they did not verify them, neither provide a systematic investigate strategy.

I think we could start with investigating the following aspects:

1. What is the pattern of signal attenuation according to distance? We have learned from this paper that it is not linearly decreased, but is there other mathematic model that could simulate this decrease?
   
2. What could we do about the asymmetry links? One possible solution I read from Sigcomm poster suggests that use pairwise-reachabilities to infer the entire network graph at individual nodes. By reachability they mean the end-to-end, multipath probability of a packet to reach its destination. From my understanding, they use an intermediate way to find a link that is most probably reliable, thus achieve better availability.
   
3. What affects the radio signal strength in different directions? How does the shape and angle of antenna affect the signal strength? Maybe we could find a way to make the radio to achieve circular signal coverage, or at least less irregular.
   
4. How does multi-path and attenuation affect packet delivery, and on what extend? It seems that many people blame the multi-path effect, but we do not have a quantitative measurement of it.
   
5. How does the gray area changes over time? What is the cause of it? It seems that packet losses are highly correlated over short time periods, but are independent over longer periods.
   

Obviously many other questions can be added to this list. Wireless sensor network is greatly affected by the environment, and it is hard to evaluate all the factors, but by investigating on each of the above questions, we could get a better understanding of what problems we are facing at.

Think the opposite way

    What if high packet lost is inevitable? For example, the disposable router project for firefighters. That project is designed for harsh environment – in a fire scene, we are expecting high packet lost and possible node lost, so another research direction would be how to achieve reliable connection with all these obstacles for communication. The challenge part of such application would be how to find the tradeoff between reliability and throughput.

    To sum up, this paper provides many insights for investigating packet lose in wireless sensor network. They also left many open issues regards to a systematic technique study about packet delivery performance. The topology control mechanism mentioned in their paper is an interesting research direction. Meanwhile, design a system that could work in terrible radio environment would also be an interesting topic. A slight digression of this topic, maybe one day we could use Quantum Teleportation to solve the interference problem, and live happily ever after.

Paper Review: The Computer for the 21st Century

M. Weiser, The Computer for the 21st Century, Scientific American, Sept 1991


This article predicts a charming future for ubiquitous computing, or sometime refers to as "embodied vitality". The basic idea of ubiquitous computing is to let the computer blend in the environment. To use a computer, user will not have to learn the specialized instructions, neither go through a arduous training. User could easily get access to a computer and utilize its functions without noticing computer's existence. The author predicted the future of computer by describing a day of Sal's. For me it's like reading a Jules Veme's novel, today we are able to realize most part of the author's description, but still a few steps away.

Maybe not that right
The author presents a nice introduction to ubiquitous computing, but I think writing is a false analogy to ubiquitous computing. Compare with paper and pencil as the basic tools for writing, computing requires more complicated infrastructure and much more efforts to maintain it. The complexity of hardware and software should not be neglected, since they are essential challenges for computing.

I think electricity would be a better example. Firstly, we want using computing resource as a utility such that we can simply plug in and start using it. Secondly, we use electricity in a standard way by following specifications like voltage, currents, etc. This is the similar case in computing, we need standardizations for communication. Thirdly, I feel that electricity is a better analogy to computing, because both of them can be a ubiquitous technology. Writing, on the other hand usually is considered as a skill.

The author identified two crucial issues for ubiquitous computing: location and scale. I agree with his opinion that they are necessary for provide good services, but I think connectivity is the most important issue for ubiquitous computing. Back in 1991, the GPS system had not been established (GPS became fully operational in 1994, Wikipedia), so locate the position was a problem at that time, but not anymore. As for the scale issues, designed devices in different sizes to handle different task is a straight forward idea. And with current technology, we are no longer limited by the size of screen, computing power, storage capacity etc.

The most important issues of ubiquitous computing is how to interact with people and other computers, thus connectivity is the key. If the connection is fast and stable, as the cloud computing promises, each individual computer do not have to have a powerful CPU and large storage device, it will provide a cheap and easy-to-use computing environment.

Something is missing
It's interesting to compare what the author expected for the future with what we have accomplished in the last 20 years. Screen size and resolution is no longer a problem, we can made it light and cheap, and even with very low power consumption (electronic ink for example); the author made a very precise prediction of the increase of storage capacity. But I think he would be surprised by the development of EEPROM technology that date back to his time. Today flash memory build by EEPROM is one of the most promising storage devices; plug-and-pay/hot swapping is very common for new devices; numerous researches has been conducted on distributed systems. But, besides those hardware advancements, to make author's vision of Sal's day come true, network connectivity is the key. The author did not pay enough attention to this issue.

Future opportunity
To me, the most interesting idea of this paper is to use computer as a scrap paper. We have seen some prototype of this kind of service. For example, when I login to a computer in the library, the Window will pick up my personal configuration and data ("profile" in Microsoft's word) from the domain server and Active Directory service provide authentication and access control to all the computers in the library.

Another example would be carrying a flash drive with a bootable system or virtual machine. But they are not ubiquitous. Firstly, pause a work at one computer and resume it on another is quite time consuming in most of the current implementations. Secondly, moving work to different devices is difficult. Thirdly, collaboration hardware/software is not easy to use.

Cloud computing seems to be a good solution for the problem mentioned above, as computing and storage are handled by the cloud, user essentially login to a remote computer. This makes resume and collaboration easier to implement. Most of the cloud product use browser as its interface, potentially, all the devices that can load a browser can be used to access the cloud. This makes it very easy to access computer resources. Microsoft published their Office 365 product this July, which has many features of ubiquitous computing.

Another luminous idea I learned from the author is the design for control panel. As he mentioned in the board size computer, it's a good idea to make control panel moveable rather than fix it on the bottom. It reminded me of my previous experience. I used to work on a large touch screen all-in-one computer, it has a 25'' monitor with 1920X1080 resolution. The problem is, on that resolution the start button is quite small, and makes it hard to click. It would be nice if the control panel will come up wherever I want it on the screen, and make the buttons and icons resizable. I'm surprised that no one has made such a control panel yet!

Expectations
Cloud computing will grow, flexible control panel will come up, but I think the future of computer is also depend on the advancement of other subjects, especially physics and chemistry. In the paper author mentioned that he hopes there could be an all-in-one transmitter which can handle all the radio frequencies. As far as I know, wireless, radio and Bluetooth on Smartphone are still implemented in separate modules and do not share an antenna.

Another expectation is for battery, I read that the capacity of traditional Li-ion based battery has reached it theoretical limit, further improvement is not economically efficient. If we could find other efficient way to get energy, or reduce energy consumption, it will greatly reduce the size of current computer devices, and make gadgets last longer.

Conclusion
The author presents a charming description of ubiquitous computing. After 20 years, some of his vision still has not been realized. Based on the technology at his time, he made an impressive prediction to the further, but he overlooked the importance of network and connectivity. With the help from the development in basic science and mass production to reduce cost, we will be able to realize his prediction in the not too distance future.

Project Idea 2: Bluetooth business card and P2P file sharing

The idea

I want to provide an easy way to let people know others around them. Sharing a public profile on smart phone through Bluetooth seems to be a good way to achieve this goal.
The idea comes from the common action of exchanging business card. But this app will provide more functions that are suitable for scenarios such as class meeting, conference and blind date…. Firstly, it will provide an easy way to recognize other and save their contact information. Secondly, user can share their files. Thirdly, additional functions can also be added e.g. anonymous census.
The different between this app with existing contact sharing, friend finder, P2P file sharing and social network is that the app only care about people near the user
and it is running on smart phone.

Application design

1. Incorporate with social media to get user's profile.
2. User a web server to store user's information such as Bluetooth Mac Address along with Facebook id(not username/password). But not a must for running the application.
3. Should be recoverable from interruption such as phone calls.
4. Should be energy efficient
5. P2P file transfer
6. Extensible to more functions, such as anonymous consensus.
7. Running on android 2.2
8. Have some kind of ranking when showing the name list

Existing projects

Jung et al. proposed BlueTorrent, a cooperative content sharing protocol for Bluetooth that exploits sparsely distributed BT-APs and allows user to cooperatively download large file. For my app, however, I am more interested in how to find the catalog of shared files among nearby users, rather than speed up the download process. And there will not be any Bluetooth access point available. BitTorrent-like file swarming is not very necessary.
There are several Bluetooth chat app, such as Bluehoo, a Bluetooth friend finder app on Windows Mobile platform, I believe the project has failed on 2008 after its beta release. I want to make my app be useful in multiple scenarios, including but not only for dating… I want to think my app as a business card or name tag, and let people to know others interests by sharing their picture and music.
Bluetooth File Transfer is a nice OBEX FTP and OPP file manager. Could be a good starting point for my file sharing module.
Cardflick they got a similar idea as mine, but not quite the same in the way of sharing it. Maybe my idea is more like a name tag instead of business card. They have a beautiful design of card templates.