[e2e] I got lost in opportunistic scheduling.

[Khaled Elsayed]

Detlef,

I will address a subset of the questions, since I don't have answer for 
all the stuff :-)

Detlef Bosau wrote:

>
> 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?


I think that HSDPA also have some form of MUD/OS. Mobile Wimax/802.16e 
OFDMA mode also has the ability to implement it but it is left for 
vendor implementation.

>
> 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 am not very familiar with all HDR/EV-DO specifics. But I have seen 
some nice tutorials on the subject on IEEE Comm. magazine.

>>
>> 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


I have seen some significant work combining OS and RT services. Whether 
it makes sense or not to use OS for both RT and NRT will be left to 
field deployments to tell. Research sometimes gives the impression that 
everything is possible and makes sense but deployments tell otherwise.

Hlaf correct bursts (not necessarily packets) can still be useful for 
schemes likes HARQ :-)


Regards,

Khaled

PS: I will send the paper in a separate mail.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.postel.org/pipermail/end2end-interest/attachments/20070517/b3edbf95/attachment.html