Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

Re: [802.19] Avoiding continuous requests in the IEEE 802.19.1 coexistence system

Mika
 
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)
 
Just my 2 cents worth...
 
Ivan Reede
----- 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!