stds-802-16-tg3: Re: OFDMA Ranging
Changhoi,
Thank you for your continuing work on this.
> on 02/04/22 21:06, chkoo at chkoo@metro.telecom.samsung.co.kr wrote:
>
> 1) Which message would includ this [ranging code allocation] information? (In
> my view, UL_MAP message including UIUC, but I could not really find out the
> exact information field describing which codes are allocated to which ranging
> procedures). So would you enlighte me?
>
I don't know; I trust Itzik's reply.
> 2) According to the current specification, the
> BS can dynamically allocate the Ranging codes(N for Initial, M for periodic
> and L for BW-request). I believe that the BS can distribute the ranging code
> and it strongly depends on the currecnt cell status. For, example, If the
> number of SSs in the traffic state are relatively greater than those in the
> idle state, the BS will re-allocate the Ranging code, M or L, for periodic and
> BW-request, which is greater than initial Rangng code. This means that the
> Ranging code for each group can be assigned in an imbalance status
Yes, the base station can imbalance L, M and N if it wants to.
> and it can
> issue the more colliding from the small ranging code assigned to SS. Would you
> correct what I am thinking is correct or not?
>
I don't quite understand what you mean by "issue the more colliding".
However, I would say that a good BS policy would be to allocate an "optimum"
number of codes. If too many few codes are allocated, there will be
frequent same-code collisions which may be decoded and sent a response to
which more than one SS would respond. If too many codes are allocated, the
BS will have more possible signals to search which will result in more false
alarms, or maybe the BS will not have enough processor power to search all
the possibilities.
> 3) Regarding understanding(2), from the imbalance Ranging code allocation, if
> the lack of Ranging code allocation occures due to cell status, the
> Quasi-random selection may be one of effective control scheme which selects
> Ranging code based on SS's connection ID I believe. Would you correct me?
>
The way the draft is now written, the SS selects a code "at random"; the
details of "random" are unspecified. Although a uniform distribution would
be a natural choice, the designer could choose to base it on the SS's
connection ID as you suggest. Here's what you're proposing, I believe. Say
the BS allocates N=10 codes for bandwidth requesting, and there are 1000 SS.
The quasi-random approach would be to assign SS 1-100 to use code 1, SS
101-200 to use code 2, SS 201-300 to use code 3, etc. If, say, SS 135 and
SS 235 decide to request bandwidth at the same time, quasirandom will work
good. If, however, SS 135 and 145 decide to request bandwidth at the same
time, they will collide. The probability of a subsequent collision on
retransmission will be reduced if they randomly choose their code next time.
I'd have to do a detailed study to figure out if there was some quasi-random
scheme which would work better than just simply using a uniform distribution
to pick one of the 10 codes at all times. My hunch is that a quasi-random
scheme would not work any better than the simple uniform distribution.
> 4) From point
> of implementation view, you mentioned that the Ranging code selection by the
> SS are jointed with implementation and it will be a manufacture propritery
> techniques. However, in traffic state, because the BS is recognizing the
> connection ID of the SS and it can estimate the Ranging code sequence
> corresponding to the ranging procedures, to be transmitted to the BS, the
> Quasi-random selection can give more benefit and estimated demodulation or
> something like opertion such as quick acquisition, at the BS. However, it can
> not have any benefits if that kind of selection shceme are not mentioned in
> the specification. Would you correct me also?
>
Again, since the number of SS (1000 or more) is much greater than the number
of allocated codes (less than 48), I don't see any benefit. The BS has to
search for signals using all the allocated codes.
> 5) In current specification, I think that there is only one backoff valus in
> the UCD message for the Ranging procedures. What I have question is that this
> single backoff valuse should be applied to all Ranging procedures such as
> initial, periodic and BW-request.
> This is also not unclear to me. Would you lead me from the cloud?
Itzik's answer sounds good to me.
--
Jerry Krinock <jkrinock@radiacommunications.com>
Radia Communications
1277 Borregas Ave. Suite 150
Sunnyvale, CA 94089
Phone, Voicemail: 408-541-9900 ext. 239
Fax: 408-541-9910