Difference between revisions of "Private:tethering-ideas"

From NMSL
 
(5 intermediate revisions by 2 users not shown)
Line 16: Line 16:
 
# None for now.
 
# None for now.
  
 +
== Mathieu's Notes ==
 +
According to my readings, I think we should focus on using WAN (EDGE/3G) for sharing connections, as it seems to be more energy-efficient than WiFi, especially when transfering at high bit rates.  It was proven in Sharma et al. that transfering data at a low or high bitrate doesn't cost that much more in terms of energy consumption.  However, as opposed to Sharma et al., I would say that we should use only mobile devices, and nothing else.  The idea of a proxy to gather data sounds appealing, as it allows to send data in stronger bursts in order to save energy, but this does give enough flexibility.  For example, if one is going up Burnaby Mountain, they might want to share their data plan with some of the bus passengers, and if the bus is crowded, no one will be using a laptop!
 +
 +
Can a user connect to many "providers"?  Or only one? 
 +
 +
Currently, it seems that phones give priority to sending/receiving data from WiFi and then using WAN.  It would be very important to find a way to simulate a WiFi connection for someone connecting to someone else's data plan, so they are not using theirs.
 +
 +
Security- and privacy-wise, the data provider (the person selling their data plan) should not be allowed to sniff any packets coming in and out of their phone to a customer.  From a technical point of view, this might not be possible.
 +
 +
== Cheng's Notes ==
 +
 +
===1/25/2011===
 +
 +
After briefly checking the literature, I feel while several enabling mechanisms, such as neighbor discovery and ad hoc routing, have been well studied. There exists no complete system that allows subscribers (potentially with different cellular service providers) to share their dataplan quotas. The closest work I see is the Shair paper from T-Labs published in HotMobile'09 (see below for the paper title). That paper has three weaknesses: (i) it's designed for voice calls, which are more vulnerable to device mobility compared to packet data, (ii) it uses short-range BT, which is again more vulnerable to mobility, and (iii) they did not have a real implementation. Hence, I see a room for us to make good systems contributions.
 +
 +
I propose we start from a workshop paper and a demo abstract. I suggest the following venues.
 +
* NOSSDAV or IWQoS (6-page ACM template), due in late Feb. Tentative tile: Reselling your unused cellular dataplan quotas. We might need to tweak the motivation a bit (to include some multimedia flavors), if we want to sell it to NOSSDAV community.
 +
* SIGCOOM demo session (2-page ACM template), due on May 12. Here, we present a real Android implementation.
 +
 +
I have also prepared a few more detailed todo list for Mathieu. Feel free to drop me emails anytime if you are not sure what I'm talking about. Thanks!
 +
 +
# Create a folder on svn and start putting up a technical report
 +
# (Sec. 2 Related Work) Survey existing proposals that can serve as building blocks of our systems, classifying them into a few categories, such as: device discovery, WiFi ad-hoc routing, billing mechanism, and energy saving. Finally, say, Shair (HotMobile'09) is the work that is closest to our work, but (i) it's designed for voice call, (ii) it uses short-range BT, and (iii) they don't have a complete implementation.
 +
# (Sec. 1 Introduction): Search for some numbers (remember to include citations)
 +
#* Prices of AT&T, T-Mobile, and Verizon's dataplans, including charging rates beyond the dataplans' caps.
 +
#* Youtube (and other multimedia apps) usage pattern: (i) How much data an average user consumes. This is to motivate the needs for some users to buy quotas from our system rather than the service providers. (ii) Also average bitrates of different Youtube content. This is motivate the video quality improvement users may perceived after using our system.
 +
#*Put these number into 2 paragraphs as motivation.
 +
# Setup WiFi adhoc network among Android phones using library, e.g., http://code.google.com/p/android-wifi-tether/ .
  
 
== Links and References ==
 
== Links and References ==
  
 
* A. Sharma, V. Navda, R. Ramjee, V. Padmanabhan, and E. Belding. ''Cool-Tether: energy efficient on-the-fly wifi hot-spots using mobile phones.'' In Proc. of international conference on Emerging networking experiments and technologies (CoNEXT '09).
 
* A. Sharma, V. Navda, R. Ramjee, V. Padmanabhan, and E. Belding. ''Cool-Tether: energy efficient on-the-fly wifi hot-spots using mobile phones.'' In Proc. of international conference on Emerging networking experiments and technologies (CoNEXT '09).
 +
* E. Jung, Y. Wang, I. Prilepov, F. Maker, X. Liu, and V. Akella. "User-profile-driven collaborative bandwidth sharing on mobile phones." In Proc. of ACM Workshop on Mobile Cloud Computing Services: Social Networks and Beyond (MCS '10).
 +
* P. Hui, R. Mortier, K. Xu, J. Crowcroft, and V. Li. "Sharing airtime with Shair avoids wasting time and money." In Proc. of workshop on Mobile Computing Systems and Applications (HotMobile '09).
 +
 +
==Meeting Minutes==
 +
 +
===01/26/2011===
 +
 +
* Mathieu has created a project folder in subversion server and started working on the related work and motivation.
 +
* Mathieu and Cheng discussed two main risk items. First, Android does not support WiFi ad hoc mode. Cheng is searching for the workarounds for Android Developer Phone 2 (Google Ion). Mathieu will also get familiar with the problem. Second, the decision of disabling WiFi ad hoc support is most likely a business one. So, we believe that we will need to clarify the business model that will benefit both cellular service providers and subscribers, and potentially a 3rd party company providing quota trading service.
 +
* Cheng explained the next challenging items: (i) device discovery and (ii) ad hoc routing protocol. Mathieu will survey related work in the literature.
 +
 +
====Action Items====
 +
* Cheng needs to test the WiFi ad hoc hack on Ion phone. We then need to decide whether it's worth to purchase a few Ion phones for the experiments (or we better go with more recent phones).
 +
* Cheng needs to provide Mathieu some hints on WiFi discovery and routing protocols. Mathieu needs to survey them.

Latest revision as of 18:06, 26 January 2011

Until recently, the cellular dataplans in the North America were mostly unlimited. However, since late 2010, AT&T started implementing tiered dataplans: a subscriber gets 200 MB for $15/month, 2 GB for @25/month, and so on. With the increasingly popularity of smartphones (and thus the tremendous amount of data traffic), we expect to see other cellular service providers moving away from unlimited dataplans. Under the new contracts, many subscribers can easily be charged an arm and a leg if they go above the limits. Meanwhile, some other subscribers may underutilize their quotas, which is another format of overpaying the cellular service providers.

To address this issue, we propose to capitalize the WiFI interfaces found on most modern smartphones to allow cellular subscribers reselling their un-used dataplan quotas. That is, the smartphones in proximity form an WiFi ad hoc network, which allow them to carry Internet traffic for each other. A micro billing platform is implemented to facilitate reselling un-used dataplan quotas among subscribers. The proposed platform covers several business use cases. First, subscribers who do not have enough dataplan quotas can purchase them from other subscribers at lower rate. Second, subscribers who have un-used quotas can sell them. Third, subscribers who need higher cellular bandwidth, e.g., for downloading a large file, can purchase the additional bandwidth on-demand from neighboring subscribers.

As a starting point, we are implementing an Android app to facility such collaboration using WiFi ad hoc mode. Later, we will implement servers on Linux to realize the micro-billing mechanisms.

An early todo list has been identified. Todo (updates are welcome):

  1. Survey on multi-hop tethering on smartphones
  2. Survey on micro-billing mechanisms
  3. System architecture (without considering security issues)
  4. Initial analysis on security concerns

A list of done tasks are given below. Done (updates are welcome):

  1. None for now.

Mathieu's Notes

According to my readings, I think we should focus on using WAN (EDGE/3G) for sharing connections, as it seems to be more energy-efficient than WiFi, especially when transfering at high bit rates. It was proven in Sharma et al. that transfering data at a low or high bitrate doesn't cost that much more in terms of energy consumption. However, as opposed to Sharma et al., I would say that we should use only mobile devices, and nothing else. The idea of a proxy to gather data sounds appealing, as it allows to send data in stronger bursts in order to save energy, but this does give enough flexibility. For example, if one is going up Burnaby Mountain, they might want to share their data plan with some of the bus passengers, and if the bus is crowded, no one will be using a laptop!

Can a user connect to many "providers"? Or only one?

Currently, it seems that phones give priority to sending/receiving data from WiFi and then using WAN. It would be very important to find a way to simulate a WiFi connection for someone connecting to someone else's data plan, so they are not using theirs.

Security- and privacy-wise, the data provider (the person selling their data plan) should not be allowed to sniff any packets coming in and out of their phone to a customer. From a technical point of view, this might not be possible.

Cheng's Notes

1/25/2011

After briefly checking the literature, I feel while several enabling mechanisms, such as neighbor discovery and ad hoc routing, have been well studied. There exists no complete system that allows subscribers (potentially with different cellular service providers) to share their dataplan quotas. The closest work I see is the Shair paper from T-Labs published in HotMobile'09 (see below for the paper title). That paper has three weaknesses: (i) it's designed for voice calls, which are more vulnerable to device mobility compared to packet data, (ii) it uses short-range BT, which is again more vulnerable to mobility, and (iii) they did not have a real implementation. Hence, I see a room for us to make good systems contributions.

I propose we start from a workshop paper and a demo abstract. I suggest the following venues.

  • NOSSDAV or IWQoS (6-page ACM template), due in late Feb. Tentative tile: Reselling your unused cellular dataplan quotas. We might need to tweak the motivation a bit (to include some multimedia flavors), if we want to sell it to NOSSDAV community.
  • SIGCOOM demo session (2-page ACM template), due on May 12. Here, we present a real Android implementation.

I have also prepared a few more detailed todo list for Mathieu. Feel free to drop me emails anytime if you are not sure what I'm talking about. Thanks!

  1. Create a folder on svn and start putting up a technical report
  2. (Sec. 2 Related Work) Survey existing proposals that can serve as building blocks of our systems, classifying them into a few categories, such as: device discovery, WiFi ad-hoc routing, billing mechanism, and energy saving. Finally, say, Shair (HotMobile'09) is the work that is closest to our work, but (i) it's designed for voice call, (ii) it uses short-range BT, and (iii) they don't have a complete implementation.
  3. (Sec. 1 Introduction): Search for some numbers (remember to include citations)
    • Prices of AT&T, T-Mobile, and Verizon's dataplans, including charging rates beyond the dataplans' caps.
    • Youtube (and other multimedia apps) usage pattern: (i) How much data an average user consumes. This is to motivate the needs for some users to buy quotas from our system rather than the service providers. (ii) Also average bitrates of different Youtube content. This is motivate the video quality improvement users may perceived after using our system.
    • Put these number into 2 paragraphs as motivation.
  4. Setup WiFi adhoc network among Android phones using library, e.g., http://code.google.com/p/android-wifi-tether/ .

Links and References

  • A. Sharma, V. Navda, R. Ramjee, V. Padmanabhan, and E. Belding. Cool-Tether: energy efficient on-the-fly wifi hot-spots using mobile phones. In Proc. of international conference on Emerging networking experiments and technologies (CoNEXT '09).
  • E. Jung, Y. Wang, I. Prilepov, F. Maker, X. Liu, and V. Akella. "User-profile-driven collaborative bandwidth sharing on mobile phones." In Proc. of ACM Workshop on Mobile Cloud Computing Services: Social Networks and Beyond (MCS '10).
  • P. Hui, R. Mortier, K. Xu, J. Crowcroft, and V. Li. "Sharing airtime with Shair avoids wasting time and money." In Proc. of workshop on Mobile Computing Systems and Applications (HotMobile '09).

Meeting Minutes

01/26/2011

  • Mathieu has created a project folder in subversion server and started working on the related work and motivation.
  • Mathieu and Cheng discussed two main risk items. First, Android does not support WiFi ad hoc mode. Cheng is searching for the workarounds for Android Developer Phone 2 (Google Ion). Mathieu will also get familiar with the problem. Second, the decision of disabling WiFi ad hoc support is most likely a business one. So, we believe that we will need to clarify the business model that will benefit both cellular service providers and subscribers, and potentially a 3rd party company providing quota trading service.
  • Cheng explained the next challenging items: (i) device discovery and (ii) ad hoc routing protocol. Mathieu will survey related work in the literature.

Action Items

  • Cheng needs to test the WiFi ad hoc hack on Ion phone. We then need to decide whether it's worth to purchase a few Ion phones for the experiments (or we better go with more recent phones).
  • Cheng needs to provide Mathieu some hints on WiFi discovery and routing protocols. Mathieu needs to survey them.