This
30 secodn limit had a serious problem. FCC regulations
state that when a licensed microphone enters the scene,
license-exemplt devices are to vacate the channel within 2
seconds. So, this means that a coexistence scenario can
and must be changeable within 2 seconds. Now, it is
unreasoable to have the coexistence scenraio revisited
that often. I am not oging to tell you what to do here,
but the solution 802.22 has taken is to pre-calculate what
needs to be done if the current operating channel for and
AP or BS becomes unserviceable. That way, if such an
"urgent" situation arises, all devices know exactly what
has to be done and can implement it. Then you can
re-calculate the next "what if" situation if a channel
again becomes unserviceable. This was deemed required so a
network (BS or AP) would not be ofrced to "go off the air"
until a new coexitence scenario is agreed upon. This was
the only acceptable way that was fouind to work so fast as
to comply to FCC this requirement without having a
continuous magamenet traffic. Ther may be others. As for
the limit above, I would also put that one should not make
requests to adjoining entities unless there is a
compelling reason to do so, like a situation change. On
the other hand, I would rather see a system where one
would only make requests upon power up and have a system
based on event and announcements rather than on "polling"
to see if there are changes. That would reduce traffic to
a bare minimum. I would then think that the "once every 30
seconds" should go away and be replaced by "upon ??? event
and no more than once every second" (yeah, we need
it to be allowed down to once every second to be able to
react to a spectrum availabiliy chage within 2 seconds)
(We also want to limit the number of requests so that if
there are 10 changes in a second, you want to limit the
number of requests n that case too)
-----
Original Message -----
Sent: Wednesday,
July 04, 2012 9:07 AM
Subject: [802.19]
Avoiding continuous requests in the IEEE 802.19.1
coexistence system
Dear all,
In reference to the TG1 call earlier
today and discussion on really frequent requests from an
entity to another (CE-to-CM, CM-to-CDIS, etc.) I would like
to propose the specification to set strict limits for
information requests and how often one can issue them. The
reason for the proposal is to avoid standard compliant
entity implementations which overload the system with really
frequent requests.
Let’s consider the procedure to obtain a
coexistence report as specified in section 5.2.4.2 of the
DF2.08. That’s the procedure with which a CE requests the
latest coexistence report from the CM to which the CE is
registered. The report is intended for WSO but from the
coexistence system perspective we should concentrate on the
interface between a CE and a CM. My proposal is to have the
specification to state that a CE may invoke the procedure to
obtain a coexistence report only once at least 30 seconds
has elapsed from the previous start of the procedure.
In practice this intends to say that a CE
may issue a CoexistenceReport_Request message only when at
least 30 seconds has elapsed from the previous
CoexistenceReport_Request message. This latter wording may
have some problems because of possible retransmissions of
the CoexistenceReport_Request message. We should at least be
very clear that retransmissions are not counted.
Further, I’m not sure whether the limit
should be 30 seconds or something else. The value should be,
however, such that one can’t overload the system by issuing
frequent requests just to check whether the coexistence
report has been changed.
What do you think on the proposal? Do you
see any challenges in it? What could be a reasonable value
to determine how often requests can be issued?
Best Regards,
Mika
!DSPAM:4ff4403338866165620315!