RE: stds-802-16-tg3: RE: support for AAS (C802.16a-02/49)
Dear Nico, All
We have done a big step for the AAS with introducing small changes, similar
things should also be finalized for the STC.
We have to concentrate on other problems in the 256-OFDM mode, like:
1) Lack of interoperability with the optional STC solution because of the
2) The existence of two incompatible sampling rates (8/7 and 7/6)
3) Coexistence with 802.11 in the unlicensed band.
Back to AAS
At this time there are in the market solutions of Broad Band [BB] AAS
implementations that will carry the answers for the SC and OFDM and the BB
We agreed in the past to have option for Narrow Band [NB] AAS as an optional
permutation. There is no interoperability problem in the combined mode,
since we have specific burst profiles for AAS traffic and we can switch and
work with the other optional NB permutation in the AAS part of the frame. In
case of the BB AAS we will not switch permutation.
All the best,
Runcom Technologies Ltd.
[mailto:email@example.com]On Behalf Of
Sent: Monday, May 13, 2002 6:32 PM
Subject: stds-802-16-tg3: RE: support for AAS (C802.16a-02/49)
I don't believe that that analogy is quite correct.
As you correctly state, no matter the IDcell in use by the BS, the SS is
capable of complying with it by scanning the DL signal. This is not the case
with the proposed text, since if the BS is using this optional mode, the SS
isn't going to find any suitable IDcell, unless it is also capable of the
optional carrier allocation.
However, if you claim this dual implementation is simple (I didn't have that
impression, especially on the DL), then there probably won't be any
objection to making this particular permutation mandatory as well. In that
case, interoperability can be achieved by the (in your view simple)
additional complexity of the capability to detect (SS side) and select (BS
and SS side) reception and transmission of either carrier allocation.
I guess that could be a viable third alternative to creating a compromise
carrier allocation or not including one of the current ones. Any of these
three choices would then result in a single interoperable OFDMA PHY.