| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
|
Phil, I appreciate you and everyone’s effort to get it
closed in time, and the editor is working very hard on it. We all want the 16e to
be as good as it can, of course in the timely manner. I agree it’s a very
late comment, however it’s an important clarification comment, I suggest
that we incorporate the change if we can. Regards, ZTE San Diego, Inc. Tel:858-554-0387 Fax:858-554-0894 -----Original Message----- Dear Mr Wang, If it is the case, hopefully, please just withdraw it. Thanks and regards Panyuh Joo -----Original Message----- From: Phillip Barber
[mailto:pbarber@BROADBANDMOBILETECH.COM] Sent: Friday, October 14, 2005 9:48 AM To: STDS-802-16@listserv.ieee.org Subject: Re: [STDS-802-16] A critical clarification is
needed in section 8.3.5.1 You have got to be kidding me. This is well beyond too
late! We are killing ourselves trying to get this out, and
you are just piling on. We cannot get the document out with this type of
exceptionally late commenting! Thanks, Phillip Barber Huawei +1 972-365-6314 direct (US) +1 925-396-0269 fax ----- Original Message ----- From: "jing wang" <jwang@ZTESANDIEGO.COM> To: <STDS-802-16@listserv.ieee.org> Sent: Thursday, October 13, 2005 7:07 PM Subject: Re: [STDS-802-16] A critical clarification is
needed in section 8.3.5.1 > Hello members; > > I have also uploaded the revised
comment > "16eD11_Jing_Wang_late_comments01.USR"
to the upload directory, >
http://dot16.org/CSUpload/CSUpload.cgi?command=viewupload&database=ballot16e > _db. > Thanks. > > Jing > > -----Original Message----- > From: jing wang [mailto:jwang@ztesandiego.com] > Sent: Thursday, October 13, 2005 4:53 PM > To: 'Roger B. Marks';
'brian.kiernan@interdigital.com' > Cc: 'STDS-802-16@LISTSERV.IEEE.ORG' > Subject: RE: [STDS-802-16] A critical
clarification is needed in section > 8.3.5.1 > > Hello Roger; > > Thank you very much for your careful
reviewing. We have fixed the > problems you identified in the revised
attachment. Please review it again > and incorporate it to the new draft. > > BR, > Jing > > > > -----Original Message----- > From: Roger B. Marks [mailto:r.b.marks@IEEE.ORG] > Sent: Thursday, October 13, 2005 2:03 PM > To: STDS-802-16@LISTSERV.IEEE.ORG > Subject: Re: [STDS-802-16] A critical
clarification is needed in section > 8.3.5.1 > > Jing, > > We are well past the time to be submitting
comments. > > In an emergency, we'll consider one, but this one
is unacceptable: > > *Your text message refers to Table 225 on page
262, but there is no > table on page 262 and not Table 225 anywhere in
the draft. > > *Your Commentary file says the change is on page
262 line 42, but in > a different table (Table 255). Again, none of
this makes a shred of > sense. > > *Your Commentary comment refers to "Table
225 starting on page 264 > lines 42". That page/line points to Table
225b, not 225. But then you > talk about the Base Station_ID, which is at Line
35, not 42. And you > talk about changing the Notes field, which does
not exist. > > I conclude that you have not constructed your
comment carefully. No > one has the time to try to decipher it or correct
it. > > Roger > > > > At 11:38 -0700 2005-10-13, jing wang wrote: >>Hello; >> >>It is necessary for the 16e standard to
clarify and indicate the >>times when the Mobile Station can get a BSID
and when it can use the >>BSID for DLFP checking. According to current
standard, this may >>prevent a MS from performing network entry.
For instance, when MS >>travel to cells covered by other BSs with
different Base_Station_IDs. >> >>Inserting the following sentence at the end of
the Notes field of >>the Base Station_ID of Table 225 on page 262
line 42 of 802.16e/D11 >>and the new text will read as the following: >> >>"4 LSBs of BS ID. Prior to completion of
network entry, the SS shall >>ignore this field and decode all bursts specified
by the DLFP. Upon >>completion of network entry, the SS shall
validate these bits with >>those of the BS on which it is registered. The
burst specified by >>the DFLP shall not be decoded if these bits do
not match those of >>the BS on which it is registered." >> >>Please review and comment on it and we hope to
this clarification be >>adapted to the 802.16e new draft. I also
attached the Commentary >>database file for easy editorial reference. >> >>BR, >>Jing > |