Re: [STDS-802-16] Is it corrigenda issuse?
Hi Yigal, all,
I think that backward compatibility is an issue if we define option (2) in
802.16e. A 802.16-2004 device, when coming across a DIUC=14 IE, would need
to skip this IE, but it does not know the length (extended IEs have variable
length) and so would not know where the next IE will appear in the map.
A 4th option can be to adopt comment #1110 from the previous round (defining
extended^2 IEs). However, my preference is to solve this more cleanly (i.e.
in corrigenda).
A 5th option can be to leave the standard broken.
Perhaps people have other ideas?
Regards,
Ran
-----Original Message-----
From: Eliaspur, Yigal [mailto:yigal.eliaspur@intel.com]
Sent: Thu 16 December 2004 20:11
To: Ran Yaniv; STDS-802-16@listserv.ieee.org
Subject: RE: [STDS-802-16] Is it corrigenda issuse?
Dear Ran, Yongseok, all,
We may use option 2 suggested by Ran to fix the problem in 802.16e.
As Ran mentioned DIUC14 and DIUC11 were already omitted from the OFDMA
Phy and are being considered reserved. Thus backward computability will
be maintained.
-Yigal
-----Original Message-----
From: owner-stds-802-16@ieee.org [mailto:owner-stds-802-16@ieee.org] On
Behalf Of Ran Yaniv
Sent: Thursday, December 16, 2004 9:32 AM
To: STDS-802-16@listserv.ieee.org
Subject: Re: [STDS-802-16] Is it corrigenda issuse?
Hi Yongseok, all,
I'd like to extend on this issue. The problem actually relates to both
the
'extended DIUC/UIUC' and the 'length' fields. 'Extended DIUC' (and UIUC)
are
4-bit fields, however in 802.16e more than 16 extended IEs are already
defined for DL. Also, the length field being only 4 bits causes some IEs
that define multiple operations (with a 'for' loop) to be useless. I
think
that there are several ways to solve this:
1) Delete extended IEs newly defined in 16e and leave only the 16 that
were
defined first.
2) Use DIUC 14 and UIUC 11 (currently not used, since 'end of map' was
deleted) for new extensions similar to DIUC/UIUC 15. This change needs
to be
done in the maintenance document due to backward compatibility.
3) Extend the 'extended UIUC/DIUC' and 'length' fields from 4 to 8 bits.
This change needs to be done in the maintenance document.
I would prefer to solve this (forward compatibility' ?) issue in
maintenance
TG using (3).
Regards,
Ran
-----Original Message-----
From: Yongseok(jay) Jin [mailto:jayjay@LGE.COM]
Sent: Thu 16 December 2004 07:06
To: STDS-802-16@listserv.ieee.org
Subject: [STDS-802-16] Is it corrigenda issuse?
Dear Jonathan,
I'd like to inquire of you about the problem that extended DIUC and UIUC
slots have the duplicated IEs.
Actually, in the 802.16-2004 standard, Extended DIUC and UIUC has 16
slots
each. And 16 slots are enough to use.
But, in the 802.16e, we add new IE for mobility to the Extended DIUC and
UIUC slots. All of 16 slots have already been full and even have
duplicated
IEs.
So, I think we need to try to extend 'length' field from 4bits to 5bits.
It
might be just one way solving the problems.
Please let me know whether it is corrigenda issues or out of scope?
Best Regards,
Yongseok Jin
-----Original Message-----
From: owner-stds-802-16@listserv.ieee.org
[mailto:owner-stds-802-16@listserv.ieee.org]
Sent: Thursday, December 16, 2004 1:19 AM
To: STDS-802-16@listserv.ieee.org
Subject: Re: [STDS-802-16] changes and updates on Maintenance Task Group
and
Corrigendum project
Dear 802.16,
I am happy to take over as Maintenance Task Group Chair from Ken and
carry
on and finish the fine work he has started, and I thank Roger for this
opportunity.
As Roger pointed out, this schedule is a challenge, and consequently I
am
going to ask for all your help to see that we meet it (and I may push on
some of you in particular for that help). It is important to keep to
this
schedule as companies are now out there designing and building equipment
based on the 802.16-2004 standard, and to ensure the success of this
standard we have make sure the errata, ambiguities and inconsisties are
cleared up soon. Also, I think it is important for 802.16e that we
complete
the technical content sooner rather than later, otherwise changes that
are
accepted in the Corrigendum project much later may have significant
repercusions to features that have been accepted in the 802.16e project.
Again, let's keep in mind that this project is not for redesigning the
standard, just cleaning up errata, ambiguities and inconsistencies.
That
point should help us meet this schedule.
Thanks,
Jon Labs, Ph.D.
Chief Scientist
Wavesat Inc.
1375 Trans-Canada Highway
Suite 300
Dorval, Quebec H9P 2W8
Canada
Ph:(514)684-0200 x325
Fax:(514)684-0211
-----Original Message-----
From: owner-stds-802-16@listserv.ieee.org
[mailto:owner-stds-802-16@listserv.ieee.org]On Behalf Of Roger B. Marks
Sent: Wednesday, December 15, 2004 2:39 AM
To: STDS-802-16@listserv.ieee.org
Subject: [STDS-802-16] changes and updates on Maintenance Task Group and
Corrigendum project
Dear 802.16,
I'm writing with an update on 802.16's Maintenance Task Group
<http://ieee802.org/16/maint> and its "P802.16-2004/Cor 1"
Corrigendum project.
Due to the pressure of business, and to his obligations as 802.16
Working Group Vice Chair, Ken Stanwood has decided to resign as Chair
of the Maintenance Task Group. I thank Ken for his service in this
position and send him our appreciation for getting the Task Group up
and running over the past few months.
Ken and I are very happy to have identified and recruited an
excellent replacement as Task Group Chair: Jonathan Labs. I welcome
Jon to this assignment and thank him for his willingness to take on
the task.
I've been working with Jon to assess where the Corrigendum project
stands and where it is going. The most obvious fact is that it is
behind schedule. The PAR says that we expected the draft to begin
Sponsor Ballot this week, but we don't yet have a first draft. It's
clear that the TG has faced a lot more work than we originally
anticipated; it's equally true that, when the WG originally drafted
the PAR, we were planning on making quick work of this project. It's
obvious to me that many WG members are anxious to get this work
completed. It's also obvious that people need to see a concrete and
realistic plan so they know when to expect the work to be finalized.
With this in mind, Jon and I have developed a schedule
<http://ieee802.org/16/maint/schedule.html>. I'd like to walk you
through it:
*We begin with the two activities agreed to by the TG at Session #34.
The first is to open an additional Call for Reply Comments on
comments that were not resolved to due to lack of time. I've compiled
those comments into a new database IEEE 802.16maint-04/09
<http://ieee802.org/16/maint/docs/80216maint-04_09.zip>. The Call for
Reply Comments will be issued later today (Wednesday). The second
activity is to issue a Working Document embodying the resolved
comments and then issue a Call for Comments on that Working Document.
Editor Itzik Kitroser expects to have the Working Document available
by the end of this week.
*Based on comment resolution at Session #35, we expect to then issue
a draft D1 and run a Working Group Letter Ballot between Sessions #35
(January) and #36 (March).
*We plan to finalize the WG Letter Ballot comment resolution at
Session #36 and move promptly to Sponsor Ballot. This will be tricky.
One challenge is that the Working Group chose to hold Session #37
unusually early in May (May 2-5). However, the schedule shows that we
hope to work around this limitation. If the plan holds true, we will
wrap up Sponsor Ballot comment resolution at the May session.
I suspect that some people will be dissatisfied with this schedule
because it is too slow, and others will be unhappy because it is too
fast. In my view, it will be challenging to meet this schedule, but I
don't think we have any choice but to set up such a challenge. The
demands to get this work concluded are, I believe, quite severe. We
are allocating three more WG sessions and six more months to complete
this work. Jon and I think that is enough.
If you do want the corrigendum to be finished by May, then I strongly
urge you to support Jon in his effort to keep the scope of the work
narrowly focused. Also, if you have any new material to introduce,
please make sure it is absolutely necessary, and introduce it early
in the process. Sponsor Ballot should be for fine tuning and
polishing any last issues, not for new material.
Regards,
Roger
This mail passed through mail.alvarion.com
************************************************************************
****
********
This footnote confirms that this email message has been scanned by
PineApp Mail-SeCure for the presence of malicious code, vandals &
computer
viruses.
************************************************************************
****
********
This mail passed through mail.alvarion.com
************************************************************************
****
********
This footnote confirms that this email message has been scanned by
PineApp Mail-SeCure for the presence of malicious code, vandals &
computer
viruses.
************************************************************************
****
********
This mail was sent via mail.alvarion.com
************************************************************************
************
This footnote confirms that this email message has been scanned by
PineApp Mail-SeCure for the presence of malicious code, vandals &
computer viruses.
************************************************************************
************
This mail passed through mail.alvarion.com
****************************************************************************
********
This footnote confirms that this email message has been scanned by
PineApp Mail-SeCure for the presence of malicious code, vandals & computer
viruses.
****************************************************************************
********
This mail passed through mail.alvarion.com
****************************************************************************
********
This footnote confirms that this email message has been scanned by
PineApp Mail-SeCure for the presence of malicious code, vandals & computer
viruses.
****************************************************************************
********
This mail was sent via mail.alvarion.com
************************************************************************************
This footnote confirms that this email message has been scanned by
PineApp Mail-SeCure for the presence of malicious code, vandals & computer viruses.
************************************************************************************