|
Hi
Reijo,
The
thing you mentioned is important. However, probably it wouldn't be necessary
until the detail mapping and implementation of the .21 schemes to specific
technologies.
At
this stage, we are still trying to down select the proposals. For the eval
criteria document, I feel that it may not be necessary, unless the
suggestion is to ask every proposals to have detailed implementation and
performance data presented. But that would not be feasible and of much use for
.21. Because, when we talked about the measurement, it would have to be for
a certain technology, which is in the scope of individual groups, e.g. 11
or 16. Even if a proposal in .21 can claim achieved certain measurement with
some amendment to, say 11, but later on those amendments could be rejected
by 11, and those measurement would mean nothing.
As for
the interoperable issue, I think it is more of an issue of the interpretation of
the standard, which could be left for the later stage of the standard
drafting. As long as the interfaces are well defined, interoperability
should be guaranteed. Those "surprises" usually are caused by different
implementer's understanding of the standard. Therefore those testing probably
would be most helpful for improving the readability of the standards. That is
probably why we only see those "PlugFest" near the end of the standard
development instead of before the main part of standard is
fixed.
Therefore, I think at this stage for the down selection and
harmonization, we only need to concentrate on eval criteria.
cheers
Cheng
Hong
We are talking about
the same thing here – our starting point is the existing legacy and 802.21 is
developing optimizations on the existing handover mechanisms or facilitates a
handover in those cases where there is no handover mechanism available in the
legacy. These optimizations can lead to amendments that the specific groups
within IEEE will carry out further, with help of active liaisoning between
802.21 and the respective groups. 802.21 is responsible within IEEE to develop
a standard that specifies unambiguously (within the scope of 802.21 as stated
in the PAR and the requirement specification) the above mentioned handover
optimizations and ensures that the existing legacy is also supported. 802.21
is also responsible to ensure that the media specific amendments are also
interoperable within the scope of 802.21, including the performance
considerations of the standard.
This is a tough task,
and in order to reduce the lead time of the development of the 802.21
standard, it is better to start working with this activity early. It could
also lead to other synergies if planning of this activity and the development
of the standard are performed in parallel.
BR, Reijo
From: Gupta, Vivek
G [mailto:vivek.g.gupta@intel.com]
Sent: 8. joulukuuta 2004
21:36
To: Reijo
Salminen
Cc:
stds-802-21@listserv.ieee.org
Subject: RE: Ad hoc group on evaluation -
Soliciting contributions to developing Usage
Models/Scenarios
From: Reijo
Salminen [mailto:reijo.salminen@seesta.com]
Sent: Wednesday, December 08, 2004 7:59
AM
To: Gupta, Vivek G
Subject: RE: Ad hoc group on evaluation -
Soliciting contributions to developing Usage
Models/Scenarios
Hi,
Vivek
I agree that a more
formal definition of this activity is needed, and I’m working on it. I’ll find
out what has been used in other groups within IEEE, as well as in other SDO’s.
We have ‘seamless’ in
the PAR, which is a metric, and what it means in numbers depends on what is
being handed over. Stability is also a metric, even though it is not
explicitly visible in the PAR, what I mean we should have a system that does
not start to oscillate (perform cyclic handovers), behave in a consistent way
and so on.
Based on my
experience from the 5 cellular systems I’ve been involved, the handovers have
always been the last ones that have come out from testing (due to different
‘surprises’ that pop up in eg. System test phase when different system
elements are put together, and since it is the most difficult feature in a
cellular system), and I’m sure we will have the same situation also. But in
our case if such a surprise ends up into the standard before it is been caught
– then we would need to run and fast.
[Gupta, Vivek G]
There
may be a difference between what you describe above and the work in 802.21.
Seems like in this case a complete system level definition of handover
including appropriate protocols etc. was specified. That is not the case with
802.21 where we are using existing protocols and mostly optimizing the
handover process.
So
to give some perspective, once we have a formal system level definition of
test bed for our performance evaluation etc. it should be possible initially
to do handovers in some form without use of 802.21, and then we could probably
use the same system to do handovers using mechanisms specified in
802.21.
In
my view, a comparison of metrics between the two cases would likely be a fair
evaluation of mechanisms specified in 802.21.
Do you see the .21
specific media specific amendments as being initiated from the .21 proposals,
or from the specific groups? If they originate from .21 we should first check
that they will also work. Same thing with the cellular interworking
functionalities.
[Gupta, Vivek G]
I
would expect .21 folks to initiate this activity. The work would likely be
carried out in media specific groups.
We
may have more insight into this as we reach draft
text.
BR,
Reijo
From:
Gupta, Vivek G
[mailto:vivek.g.gupta@intel.com]
Sent: 8. joulukuuta 2004
15:45
To: Reijo
Salminen
Subject: RE: Ad hoc
group on evaluation - Soliciting contributions to developing Usage
Models/Scenarios
From:
owner-stds-802-21@listserv.ieee.org
[mailto:owner-stds-802-21@listserv.ieee.org] On Behalf Of Reijo Salminen
Sent: Tuesday, December 07, 2004 11:44
PM
To: Gupta, Vivek G; 'Nada Golmie';
stds-802-21@listserv.ieee.org
Subject: RE: Ad hoc group on evaluation -
Soliciting contributions to developing Usage
Models/Scenarios
The intention is to
start the development of usage models/scenarios in parallel with the
evaluation and down selection. It is going to be a tough job to fulfill, but
it is a mandatory task in the development of the 802.21 standard. As in
any complex system activity – what the development of 802.21 also is, the
planning of verification activities must started at an early stage, both to
help in understanding the complexity of the problem, to ensure good quality of
the outcome, and to reduce overall lead time.
[Gupta, Vivek G]
You
bring an interesting point about “verification of standard”.
What
does this really mean and how do other groups in IEEE typically handle
this?
So
far we have not specified any performance specific or even otherwise any
“numbers/metrics” etc. that 802.21 needs to meet, both as part of the
PAR
and
also the requirements document. So we may need a more formal definition of
this verification process to get a better understanding of
expectations.
Also
will it be feasible to do this verification before the 802.21 specific media
specific amendments have been done?
Would it help if it
was a separate document instead of a chapter in the evaluation
document?
[Gupta, Vivek G]
That’s
fine as long as this is not linked to evaluation
guidelines/criteria.
I
would just like to see the evaluation guideline document development process
close in a timely manner!
Best
Regards
-Vivek
From:
owner-stds-802-21@listserv.ieee.org
[mailto:owner-stds-802-21@listserv.ieee.org] On Behalf Of Nada Golmie
Sent: Tuesday, December 07, 2004 2:52
PM
To:
stds-802-21@listserv.ieee.org
Cc: Nada Golmie
Subject: Ad hoc group on evaluation -
Soliciting contributions to developing Usage
Models/Scenarios
Dear all,
To follow-up on our telecon
discussion this morning, the evaluation ad hoc group would like to solicit
volunteers to develop
a set of usage case models & scenarios to be
included in the evaluation guidelines document.
Although the consensus
was that no performance
analyses, modeling, and simulation results will be required for the
proposal
down-selection process, there is some value to develop template
scenarios in order to allow for simulation modeling / prototype
implementation at a later stage - after harmonization has
occurred.
[Gupta, Vivek G]
The
evaluation guidelines document should basically help with evaluations and down
selection.
If
the above information is NOT going to help with evaluation and down selection,
then it should NOT be included in evaluation guideline
document.
|