All, The FCC publishes nothing in private, so Ivan’s response is properly in public, Regards, Mike Chair, 802.18 From: Ivan Reede [mailto:i_reede@xxxxxxxxxxxx]
Sent: Saturday, July 07, 2012 2:35 PM
To: STDS-802-19@xxxxxxxxxxxxxxxxx
Subject: [802.19] Fw: [802.19] Avoiding continuous requests in the IEEE 802.19.1 coexistence system ----- 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 :-).
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. =================================================================== ----- 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!
|