[e2e] I got lost in opportunistic scheduling.

[Detlef Bosau]

Khaled Elsayed wrote:
> Detlef,
>
> There are some papers that discuss the relation between OS at MAC/PHY 
> and TCP. For example check 
> http://www.isr.umd.edu/~baras/publications/reports/2002/SrinivasanB_TR_2002-48.htm 
>
> But there are also more recent stuff.

As I see, I got this paper before but did not pay enough attention to it.

Some questions.

1. As far as I see, OS/multiuser diversity is yet employed in the 
Qualcomm 1xEV-DO wireless system. (Is there a name for it, which one can 
say within a lifetime? *got scared*)

Are there other systems which employ OS?

2. Qualc..., say C3P0, it´s shorter :-), seems to have a _common_ 
downlink and _dedicated_ uplinks. Is this correct? In the paper, the 
uplinks are said to be "asynchronous circuit-switched". What does that 
mean? (I already got criticism this year because I talked about packet 
swichting in wireless networks, because packet switching were not 
restricted to wireless networks or something like that.... I didn´t 
understand it.) Does it mean, we have dedicated TDM channels with 
something like HDLC on it to enable packet transport?

3. Somwehere in the paper, a reliable link control / reliable link 
protocol is mentioned. What kind of protocol is used here? Something 
like RLPv3, which fragments L3 packets into pieces of e.g. about 20 
bytes? Or do we deal with IP packets directly? Particularly, does C3P0 
emply any ARQ? Or does it only use FEC?

4. If C3P0 emplys ARQ and some RLP, does it use sliding window? Or does 
it use stop´n wait?

5. If C3P0 only uses FEC, one could be somewhat extreme and don´t really 
use even that, at least don´t use extreme spreading but one could rely 
upon OS only. One goal of OS is to avoid errors in advance rather then 
correct them afterwards. So one could work with only little error 
correction capability intentionally. Or one could work with extensive 
adaptation of channel coding / puncturing. How is this done in C3P0?


>
> I think that implementation of pure OS without some compensation for 
> users with consistent bad channels does not make sense. I have some 
> results on that for RT services that was published in MSWIM 2004. 
> E-mail me if interested.

Of course, I´m interested!

Question, somewhat provoking: Does it make sense to combine OS and RT 
services? Somewhere on David Tse´s "talk" (he has so many slidesets of 
this one talk on his homepage that I wonder if he ever gave another one 
=8-)) we learn something about voice vs. data. (Unfortunately it´s not 
mentioned on the slides _what_ we learn =8-))

But I think it hardly makes sense to mixup voice and data, because data 
requires data integrity and voice requires time integrity _AND_ can 
tolerate errors. In data services, you either have corrupted packets or 
you have error free packets. Is there a way to allow for "half correct 
packets"?

So, at least at this moment, I think, data services and _error_  
_tolerant_ RT services should be done seperately. Or what do you think?

Detlef