|
Public...
----- Original Message -----
Sent: Friday, July 06, 2012 12:15 PM
Subject: Re: [802.19] Avoiding continuous requests in the IEEE
802.19.1 coexistence system
Hi Ivan,
Did you mean to send this privately or share with the
reflector? I will respond privately, but feel free to share my response if
you like...or otherwise use it as you see fit :-).
Hi Benjamin,
The key words in the FCC sentence here are "is
detected". If the database suddenly tells you there's a microphone or any
other licensed device in your area, in my opinion, you just detected it. In
fact, sensing is unable to detect a "licensed" incumbent, all it senses is
signal.
So if the signal is from you neigbor's ATSC HD
camera over the air or his "game box" or from a real TV station, your sensor
can't tell the difference, he can only tell you he detects an ATSC signal.
[ If you have a circuit that can tell that the FCC granted a license, you
got better electronics than me... :-) ]. So in essence, yes, you may
elect to interpret that as being from a sensor, but in all respects, until a
judge has stipulated that, nobody knows and I rather err toward caution,
assume it's any form of detection, including database input.
Because of where the 2 second requirement is found
in the regulations, it applies to devices that depend only on sensing, and do
not have access to the database. The requirements for devices depending on the
database directly are quite different. So being informed directly or indirectly
via change in the database would not be "detected" as used in this
clause. That may not be what was intended and not what we would like.
But I think otherwise your argument is quite compelling. Having the
ability to support a timely response to changing conditions would seem very
valuable.
I also agree with you that the regulations don't define
"detected" adequately for sensing only devices. Reading it as it sits right now,
I think that the only way a device can meet the requirements for
depending on sensing only would be to understand (demodulate and decode) every
possible protected signal. IMO this part of the reg is broken, and
complying with it prohibits anything useful.
I expect FCC won't do
anything more about this until someone takes a device to them that does
something reasonable and shows that it adequately protects the privileged
users, and FCC will approve it anyway. If enough people bring such products to
FCC for approval they may eventually fix the rule. But I digress...sorry.
So in short, once you have "detected" te presence
fo the incumbent, you have 2 seconds to switch the entire network to another
operating channel or drop off the face of the earth (i.e. go off air). Now
that last alternative of going off the air is not too too good for quality of
service :-) , especially for SIP phone conversations and real-time gaimng
applications. So I would rather see our coexistence system able to provide
facilities so we can switch channel within 2 seconds ina hitless
fashion. If you're using the database, then the rules
don't constrain you so much, but I am persuaded to agree that the coexistence
system able to handle switch as this would add great value as you say. I know
from past experience doing this well is a challenge.
Like I said, 802.22 saw this, after much debate,
understood the challenge of doing this in real tmie and opted to have the
coexistence system play "simulation games" in advance and determine for all
the "what-if" scenarios, what to do when such detection occurs. In the US,
where 802.22 probably will not use sensing, they still play these what-if
secnarios and this makes that when such a situation arises, everybody knows
about the contingency plans and action can be taken qickly. Negotations were
run far in advance of the imlpementation of the scenrio which reduces the
bandwidth needs for the terrific amount of comuting and communication that may
be required in negotiating a new channel layout within a short 2 second
period. I'm not syaing this is the only or even the best solution, but it is
one that can be carried out by a service and gives added value in being
subscribed to a coexistence service... better assurance of maintaining some
quality of service while handling such rapid events. Since it's a service, it
requires very little from a station/CPE, i.e. a bit of memory with a feed
forward... AP/BS tells all its stations, switch to contingency band plan x.
And it gets this from the CM... alot of CMs may have received a single order
from thier service... he whole network topology (including mutiple networks
form multiple operators) can switch to the new channel plan in a few
milliseconds.
This can also be very uselfull for mobility, as
the station/CPE can be told to operate a switchover (frequency and AP/BS
pre-determined) when certain GPS coordiantes are reached on a road for
example.
So in summary, all I am suggesting that it
may be advisable for 802.19 to consider this need in the crafting of the
coexistence algorithms and the capabilities of the WSOs'. 802.22 found a
solution, 802.19 may find another one or mal elect to use the same
one.
Just my 2 cents worth,
Ivan Reede
===================================================================
----- Original Message -----
Sent: Thursday, July 05, 2012 8:01
PM
Subject: Re: [802.19] Avoiding
continuous requests in the IEEE 802.19.1 coexistence system
If it helps:
Here is the FCC wording:
"Channel move time.
After a TV,
wireless microphone or other low power auxiliary device signal is detected
on a TVBD operating channel, all transmissions by the TVBD must cease within
two seconds. "
This is in 15.717 titled "TVBs that rely
on spectrum sensing" [ § 15.717(c)(i)(C)(ii)(4)
].
I'd go out on a limb and say that yes, this requirement applies to
devices that rely on spectrum sensing. Usual caveats apply
;-).
I'm not sure I understand the coexistence scenario concept
enough yet to determine how this impacts the request/response. It does
seem like there is a good chance that the WM starting to transmit may
increase the packet failure probability of the TVWD, which may make reliable
request/response exchange a challenge. This is one of many challenges faced
by a device depending on sensing.
Hope that
helps.
B
Hello
Ivan,
Regarding:
?FCC regulations state that when a licensed microphone enters the
scene, license-exempt devices are to vacate the channel within 2
seconds.? Is this requirement for TVBDs that rely on spectrum sensing?
Best
Regards
Prabodh
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:4ff70f0538861721610540!
|