approx-comm
Differences
This shows you the differences between two versions of the page.
| Both sides previous revision Previous revision Next revision | Previous revision | ||
|
approx-comm [2009/04/21 16:13] sdsen |
approx-comm [2009/05/02 13:31] (current) sdsen |
||
|---|---|---|---|
| Line 1: | Line 1: | ||
| **[[http://pages.cs.wisc.edu/~sdsen/wiki/doku.php?id=old_page_apex|Older updates]]**\\ | **[[http://pages.cs.wisc.edu/~sdsen/wiki/doku.php?id=old_page_apex|Older updates]]**\\ | ||
| **TODO** | **TODO** | ||
| - | - Evaluate the impact of proposed changes to the radio pipeline(via simulations), ie whether the desired behavior of scrambling(consecutive sequence of 0/1 removal), interleaving(burst error mitigation) are hampered because of our suggested pipeline modifications. | + | - **Evaluate the impact of proposed changes to the radio pipeline(via simulations), ie whether the desired behavior of scrambling(consecutive sequence of 0/1 removal), interleaving(burst error mitigation) are hampered because of our suggested pipeline modifications.** |
| - | - Bit-mapping scheme switch (ie switching from BlockII to grey etc.) -> when to switch (finding a metric). Currently we just say that the h/w should have capability to estimate error rates for all schemes (more clarifications/methodology) and some results (correlation between schemes, ie if we estimate the errors for just one scheme, can we predict the same for other schemes ?)?? | + | - **Bit-mapping scheme switch (ie switching from BlockII to grey etc.) -> when to switch (finding a metric). Currently we just say that the h/w should have capability to estimate error rates for all schemes (more clarifications/methodology) and some results (correlation between schemes, ie if we estimate the errors for just one scheme, can we predict the same for other schemes ?) + rate assignment?? ** |
| - Better bit position assignment algorithm, some joint-optimization of bit position assignment and priority of data ??, other things instead of greedy (needs more thoughts, not sure what exactly to do) | - Better bit position assignment algorithm, some joint-optimization of bit position assignment and priority of data ??, other things instead of greedy (needs more thoughts, not sure what exactly to do) | ||
| - | - Comment on delay induced by our protocol(we are buffering data), comment on the trade-off between additional delay(jitter??) and performance benefits observed. One more knob that the application can use. | + | - **Comment on delay induced by our protocol(we are buffering data), comment on the trade-off between additional delay(jitter??) and performance benefits observed. One more knob that the application can use.** Maybe point out how the protocol can be opportunistic. |
| - Comment on throughput achieved by different bit-mapping schemes(as opposed to application performance). Comment on what to choose if thrpt. is the only metric. | - Comment on throughput achieved by different bit-mapping schemes(as opposed to application performance). Comment on what to choose if thrpt. is the only metric. | ||
| - Do the multicast experiments as done by softcast, ie collect profiles from different location and show performance variation. and show that we let the users get performance commensurate with their channel conditions. | - Do the multicast experiments as done by softcast, ie collect profiles from different location and show performance variation. and show that we let the users get performance commensurate with their channel conditions. | ||
approx-comm.1240348432.txt.gz · Last modified: 2009/04/21 16:13 by sdsen
Page Tools
