<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
  <title></title>
</head>
<body bgcolor="#ffffff" text="#000099">
Detlef, <br>
<br>
I will address a subset of the questions, since I don't have answer for
all the stuff :-)<br>
<br>
Detlef Bosau wrote:
<blockquote cite="mid464ADC92.3010302@web.de" type="cite"><br>
Some questions.
  <br>
  <br>
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*)
  <br>
  <br>
Are there other systems which employ OS?
  <br>
</blockquote>
<br>
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. <br>
<blockquote cite="mid464ADC92.3010302@web.de" type="cite"><br>
2. Qualc..., say C3P0, it&acute;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&acute;t
understand it.) Does it mean, we have dedicated TDM channels with
something like HDLC on it to enable packet transport?</blockquote>
<br>
<blockquote cite="mid464ADC92.3010302@web.de" type="cite"><br>
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?
  <br>
  <br>
4. If C3P0 emplys ARQ and some RLP, does it use sliding window? Or does
it use stop&acute;n wait?
  <br>
  <br>
5. If C3P0 only uses FEC, one could be somewhat extreme and don&acute;t
really use even that, at least don&acute;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?
  <br>
  <br>
</blockquote>
<br>
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.<br>
<br>
<blockquote cite="mid464ADC92.3010302@web.de" type="cite">
  <blockquote type="cite"><br>
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.
    <br>
  </blockquote>
  <br>
Of course, I&acute;m interested!
  <br>
  <br>
Question, somewhat provoking: Does it make sense to combine OS and RT
services? Somewhere on David Tse&acute;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&acute;s not
mentioned on the slides _what_ we learn =8-))
  <br>
  <br>
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"?
  <br>
  <br>
So, at least at this moment, I think, data services and _error_&nbsp;
_tolerant_ RT services should be done seperately. Or what do you think?
  <br>
  <br>
Detlef
  <br>
</blockquote>
<br>
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.<br>
<br>
Hlaf correct bursts (not necessarily packets) can still be useful for
schemes likes HARQ :-)<br>
<br>
<br>
Regards,<br>
<br>
Khaled<br>
<br>
PS: I will send the paper in a separate mail. <br>
<br>
</body>
</html>