Subject: Re: [paws] Question: Encode slopes?

From: "Luzango Mfupe" <[email-masked]>
Date: Mon, 28 Oct 2013 11:34:23 +0200

Hi Andy, Ben, Rolfe and the team,

If the white space radio has been certified (i.e., obtained a type
approval certificate from the regulator) and all this information has
already been passed to the DB administrator.  What would be the point
again for the DB to pass the masks info back to the device?. I doubt if
this envelope will be feasible to radio vendors as they will be required
to to comply to many other masks requirements from different regulators
across the globe.

On a positive note however,  I think the envelope might be useful for
fishing malfunctioning radios but it should be implemented in the PAWS
as an optional functionality.

Kind Regards,
Luzango.

>>> Andy Lee <[email-masked]> 10/25/13 11:47 PM >>>
The "envelope" has not changed in this case, and we don't need to know
it to adapt to changes in what chunks of spectrum are available. 

Today, the "envelope" does change.  It's more than just a channel on/off
response.  Power limits are also part of the current response.  A
personal/portable device is normally allowed to operate at 100 mW on
open white space channels.  However, if the device is inside the
protection contour on an adjacent channel, the power limit is reduced to
40 mW (it's possible for a mix of 100 and 40 mW channels to be part of
the response).  In other words, both the frequency and power limits are
specified for each valid white space channel.

At any time (e.g., after the incentive auctions), the FCC can modify the
rules.  The calculated frequencies and power limits for white space
could change, and the new "envelope" of frequencies and power levels
would go out to all devices.  The future rules might even specify
different power levels not necessarily restricted to just 100 and 40 mW
values.

 Andy Lee | Google Inc. |  [email-masked] | 408-230-0522

On Fri, Oct 25, 2013 at 12:00 PM, Benjamin A. Rolfe <[email-masked]>
wrote:
                   
                     We             don’t have a situation where a
device has to decide between             it’s certified performance
envelope and one provided by a             database.         
         
         I'm not sure if I'm understanding this           sentence
correctly.  I think the envelope provided by the           database IS
the envelope the device is expected to conform to           (the device
doesn't have a choice in this matter).  

     Well I don't know any other way to say this - with method proposed 
   now for PAWS, the "envelope provided by the database" does not fully 
   define he envelope that the device is expected to conform to per FCC 
   regulations.  It addresses only one of many variables.
     
     The FCC expects that the device will only transmit in the TV    
channels which the database says are available. When the FCC sells    
off some of these TV channels, the database will forever after    
exclude those channels from what is available. \
     Existing devices will "adapt" because when they ask what they can  
  use, the answer will never include those it can no longer use. That   
 is simple enough.  The "envelope" has not changed in this case, and    
we don't need to know it to adapt to changes in what chunks of    
spectrum are available.  
     
     How a device transmits in those channels (i.e. the  "envelope" the 
   signal must meet) is defined by a number of variables,  of which the 
   TX power averaged over a frequency range (the TV channel) is only    
one. Notall are enumerated obviously in Subpart H of part 15 (the    
TVBD rules), as many are included by reference or implication    
(requirements inherited because it's part 15).  Right now the    
designer and the test house need work with what is hard coded  in    
the regulations.  To address dynamically adjusting to changes in the    
emissions requirements when using an available chunk of spectrum,    
we'd have to have a way to signal any and all of the parameters that    
currently are testin     There's a group in IEEE 1900 that is working on standards for    
dynamic spectrum.  I think it would be useful if PAWS and 1900.5    
collaborated.  
     
     -B

                                                                       
Andy Lee |                      Google Inc. |                     
[email-masked] |                                            
408-230-0522                                                            

           On Fri, Oct 25, 2013 at 4:33 AM,             Peter Stanforth
<[email-masked]>             wrote:
                                             Andy, First of all I didn’t
mean to sound like I                   was picking on you. I still have
a hard time speaking                   IETF, me, and not as our
organization.  I agree with                   your thought on the key
benefit of a DB. My question                   relates to how we resolve
radio certification issues                   against policy updates
implemented by the database.                    In the example you cite
about power limits we                   currently resolve that by FCCID
(as an example we                   currently support a waiver for a low
power fixed                   device (Specific FCCID) that gets treated
differently                   than a high power fixed device) but all of
this is                   taken care of inside the database.  We don’t
have a                   situation where a device has to decide between
it’s                   certified performance envelope and one provided
by a                   database. Should be an easily solvable problem,
but I                   suspect this is more of a regulatory issue than
a                   technical/PAWS issue.

                 Peter S.

                                                         From:  Andy    
                Lee <[email-masked]>
                     Date:                      Thursday, October 24,
2013 at 7:35 PM
                     To:  Peter                     Stanforth
<[email-masked]>
                     Cc:                      "Benjamin A. Rolfe"
<[email-masked]>,                     "[email-masked]"               
     <[email-masked]>                                            
                         Subject:                          Re: [paws]
Question: Encode slopes?

                                                                        
                               Hi,

                             if, in the future                          
      Andy provides different characteristics                           
     my device may no longer compliant with                             
   the rules and should not be operating.                             
                             
                             I'm not sure I understand this point or why
                            anything would become non-compliant.        
                     Whether PAWS sends the spectrum data with          
                  "flat" encoding or "sloped" encoding is               
             independent of device compliance.  Supposing               
             the FCC modifies the rules in the future and               
             allows 50 mW and 120 mW instead of 40 mW and               
             100 mW limits, then the PAWS will update                   
         accordingly (no matter which encoding is                       
     used).                             
                             
                             We've always held that one of the key      
                        benefits of database managed spectrum is                       the ability to have device automatically          
                    adapt when spectrum resources change                
              (e.g., the "incentive auction" 600 MHz                    
          NPRM) or when protection rules need to be                     
         changed (e.g., interference is being                           
   reported and the calculations need to be                             
 modified).  It gives regulators the power                              
to make tweaks to spectrum policy without                              
having to displace a large installed base                              
of devices.

                             From a "black box" perspective, the        
                      emissions limits are what define whether a        
                      WSD will cause interference or not.  In           
                   very basic terms, if the emissions are low           
                   enough, there is no way for the device to            
                  cause interference.  The database is                  
            simply providing the WSD information so                     
         that it can configure operating parameters                     
         to stay below those emissions limits.

                                                            Best
regards,

                                                           Andy Lee |   
                                                                        
            Google Inc. |                                               
                                         [email-masked] |            
                                                                        
   408-230-0522                                                         

                                 
                                 On Thu, Oct 24,                        
          2013 at 11:09 AM, Peter Stanforth                             
        <[email-masked]>                                  
wrote:
                                                                        
                                      The concept of the database       
                                 acting as a policy  manager is         
                               very appealing - but not simple.         
                               Which is why my preference is            
                            still to put this in version 2              
                          and think through all the                     
                   issues.
                                       Putting my device developer      
                                  hat on I can’t reconcile the          
                              policy manager concept under              
                          current FCC rules. It is a Catch              
                          22. Assuming I certify today it               
                         will be against a specific set                 
                       of operating characteristics. I                  
                      would expect Andy to provide                      
                  those same characteristics in                         
               his implementation. However if,                          
              in the future Andy provides                               
         different characteristics my                                   
     device may no longer compliant                                     
   with the rules and should not be                                     
   operating. However if I adjust               the operating characteristics                                        
the device is no longer in                                        
compliance with its                                        
certification, and would be                                        
operating illegally. So either                                        
the “new” rule permits                                        
grandfathered operation or my                                        
device needs to be re-certified.                                        
 It seems like we have to                                        
convince Regulators to certify                                        
databases as policy managers and                                        
simply certify radios to ensure                                        
they comply with the policy they                                        
are given for this concept to                                        
work.

                                                  From:                 
                           "Benjamin A. Rolfe"                          
                  <[email-masked]>
                                           
                                           Date:                        
                  Wednesday, October 23,                                
          2013 at 7:30 PM
                                           Cc:                          
                "[email-masked]"                                         
 <[email-masked]>                                                        
                               
                                               Subject:                 
                             Re: [paws]                                 
             Question: Encode slopes?

                                             
                                                                        
                   One                                                  
should take careful                                                  
note that the spectrum                                                  
profiles used in the                                                  
802.11 DO NOT specify                                                  
regulatory                                                  
requirements, as such                                                  
is out of scope of                                                  
802.11 as clearly                                                  
sated in the                                                  
boilerplate to the                                                  
standard:
                                                   
                                                   "Compliance with the 
                                                 provisions of any IEEE 
                                                 standards document     
                                             does not imply             
                                     compliance to any                  
                                applicable regulatory                   
                               requirements."
                                                   
                                                   The mask specified in
                                                  annex D of 802.11-2012
                                                  specifies requirements
                                                  on an 802.11 device   
                                                                             device (it should fall   
                                               within the boundaries    
                                              of the envelope given)    
                                              and as a receiving        
                                          device (it must               
                                   capture a signal that                
                                  meets these                           
                       requirements and                                 
                 tolerate emissions                                     
             within this envelope                                       
           spilling into the                                            
      channel.  This does                                               
   NOT assure regulatory                                                
  compliance anywhere on                                                
  earth (or elsewhere).
                                                   
                                                   With that out of the 
                                                 way,  Andy's           
                                       suggestion below                 
                                 ceertainly makes this                  
                                "mask" representation                   
                               more useful.  I did go                   
                               back and review the                      
                            emails on this topic                        
                          and at least once it                          
                        was stated that the                             
                     goal of this "mask" is                             
                     to capture regulatory                              
                    requirements that may                               
                   change from region to                                
                  region, or over time,                                 
                 so that an                                             
     implementation may be                                              
    adaptable instead of                                                
  having emission                                                  
requirements hard                                                  
coded. The current                                                  
representation does                                                  
not seem to meet that                                                  
goal.  The                                                  
enhancements that Andy                                                  
shows below would come                                                  
closer. 
                                                   
                                                   If the current desire
                                                  of the majority is to 
                                                 "get on with it"       
                                           addressing known             
                                     regulations now and                
                                  deal with enhancements                
                                  such as this in                       
                           version 2, then I'd                          
                        suggest removing the                            
                      "mask" representation                             
                     from the draft for                                 
                 now, and add it when                                   
               the group feels it is                                    
              appropriate to take                                       
           the time to define it                                        completly.   To meet                                         
         the current rules that                                         
         are approved for TVWS                                          
        devices (FCC) we don't                                          
        need the "mask"                                                 
 represented (as at                                                  
least one database has                                                  
been approved without                                                  
it).  It would be a                                                  
very useful                                                  
enhancement to be able                                                  
to derive the                                                  
in-channel and                                                  
near-channel emission                                                  
masks from the                                                  
database, but it is                                                  
only if it is                                                  
complete.                                                     

                                                                        
                         On 10/23/2013 12:23                            
                      PM, Andy Lee wrote:

                           Speaking                                     
               as another FCC                                           
         certified database                                             
       provider, we do                                                  
  supply a spectrum                                                    
mask, and the                                                    
response from the                                                    
database is                                                    
specified in terms                                                    
of frequencies                                                    
rather than                                                    
channels.                                                     
                                                     
                                                     As an industry     
                                                 reference, Wi-Fi       
                                               has been using           
                                           spectrum profiles            
                                          with slopes for               
                                       many years now (link             
                                           to spec).                    
                                   See section D.2.3                    
                                  Transmit Spectrum                     
                                 Mask requirements.                     
                                  The relationship                      
                                between this                            
                          transmit spectrum                             
                         mask and the TVWS                              
                        emission limit                                  
                    mask is very                                        
              relevant to                                               
       picking operating                                                
      frequencies,                                                      
especially around                                 channel 37 and the                                                      
band edges.

                                                     
                                                     Best regards,

                                                                        
                                                                        
 Andy Lee |                                                             
                                                         Google Inc. |  
                                                                        
                                           [email-masked] |          
                                                                        
                                   408-230-0522                         

                                                     On                 
                                     Wed, Oct 23, 2013                  
                                    at 8:47 AM, Peter                   
                                   Stanforth                            
                             <[email-masked]>                 
                                     wrote:

                         Speaking                                       
                   as an FCC                                            
              certified TVWS                                            
              database                                                  
        provider, we                                                    
      do not supply                                                     
     any                                                          
information to                                                          
the devices                                                          
related to                                                          
EIRP, PSD,                                                          
mask or                                                          
similar                                                          
characteristics.
                                                           The          
                                                device                  
                                        supplied FCCID                  
                                        tells us what                   
                                       the FCC                          
                                compliance is                           
                               (high power                              
                            fixed,                                      
                    personal/portable                                   
                       mode 1 or 2)                                     
                     and we                                             
             calculate                                                  
        protection,                                                     
     and respond                                                        
  with channel                                                          
lists based on                                                          
this.
                                                           All the      
                                                    device gets is      
                                                    a list of           
                                               channels that            
                                              it is legally             
                                             allowed to                 
                                         operate on,                    
                                      based on the                      
                                    device                              
                            classification                              
                            provided.

                                              From: "Benjamin A. Rolfe"
<[email-masked]>
                                                           Date:        
                                                  Wednesday,            
                                              October 23,               
                                           2013 at 11:40                
                                          AM
                                                           To:          
                                                "[email-masked]"
<[email-masked]>                                                         
 
                                                           Subject:     
                                                     Re:                
                                          [paws]                        
                                  Question:                             
                             Encode slopes?

                                                           
                                                                        
                                             It would seem from the
thread                                                           that
this                                                           method of
                                                          specifying a  
                                                        "mask"          
                                                (emission               
                                           limits) does                 
                                         not address                    
                                      the known                         
                                 regulatory                             
                             requirements                               
                           in the United                                
                          States, where                                 
                         a simple                                       
                   rectangle does                                       
                   not describe                                         
                 the emissions                                          
                profile                                                 
         limits.  
                                                           This circles 
                                                         me back to the 
                                                                                             asked quite a      
                                                    while ago,          
                                                which is how,           
                                               as a device              
                                            developer, do               
                                           I use this                   
                                       information?                     
                                      What is the                       
                                   purpose of                           
                               providing a                              
                            "mask"?                                     
                      
                                                           Related      
                                                    question: Do        
                                                  the current           
                                               FCC approved             
                                             databases                  
                                        provide this                    
                                      "mask"                            
                              information                               
                           now?                                         
                  
                                                           Thanks
                                                           Ben

                                             On                         
                                 10/23/2013                             
                             1:44 AM, Ray                               
                           Bellis wrote:

                                             On 22 Oct 2013, at 17:07,
Peter Stanforth <[email-masked]> wrote:

                                                          Took the words
right out of my mouth! My preference is to make sure we have addressed
all known regulator issues, for which I don't believe this is required,
and then do this right next time.

                                                          +lots
Ray
_______________________________________________
paws mailing list
[email-masked]://www.ietf.org/mailman/listinfo/paws                 

                                                           

 _______________________________________________
                                                         paws mailing   
                                                     list
                                                         [email-masked]
                                                        
https://www.ietf.org/mailman/listinfo/paws

                                                     

                                     
 _______________________________________________
                                     paws mailing list
                                     [email-masked]
                                    
https://www.ietf.org/mailman/listinfo/paws

                           

                        

 

-- 
This message is subject to the CSIR's copyright terms and conditions, e-mail legal notice, and implemented Open Document Format (ODF) standard. 
The full disclaimer details can be found at http://www.csir.co.za/disclaimer.html.

This message has been scanned for viruses and dangerous content by MailScanner, 
and is believed to be clean.

Please consider the environment before printing this email.

---

From: Vincent Chen <[email-masked]>
Date: Tue, 29 Oct 2013 08:52:37 -0700

Luzango,

Please see answer in-line.

On Mon, Oct 28, 2013 at 2:34 AM, Luzango Mfupe <[email-masked]> wrote:

> already been passed to the DB administrator.  What would be the point again
> for the DB to pass the masks info back to the device?. I doubt if this
> envelope will be feasible to radio vendors as they will be required to to
> comply to many other masks requirements from different regulators across
> the globe.
>

Actually, the point is that the DB can pass back the mask that is relevant
for the device's location, so that the device
can reduce regulatory-specific logic.

> fishing malfunctioning radios but it should be implemented in the PAWS as
> an optional functionality.
>
> Kind Regards,
> Luzango.
>
>
> The "envelope" has not changed in this case, and we don't need to know it
>> to adapt to changes in what chunks of spectrum are available.
>
>
> personal/portable device is normally allowed to operate at 100 mW on open
> white space channels.  However, if the device is inside the protection
> contour on an adjacent channel, the power limit is reduced to 40 mW (it's
> possible for a mix of 100 and 40 mW channels to be part of the response).
>  In other words, both the frequency and power limits are specified for each
> valid white space channel.
>
> rules.  The calculated frequencies and power limits for white space could
> change, and the new "envelope" of frequencies and power levels would go out
> to all devices.  The future rules might even specify different power levels
> not necessarily restricted to just 100 and 40 mW values.
>
>
> On Fri, Oct 25, 2013 at 12:00 PM, Benjamin A. Rolfe <[email-masked]>wrote:
>
>>
>>  We don’t have a situation where a device has to decide between it’s
>>> certified performance envelope and one provided by a database.
>>
>>
>>  I'm not sure if I'm understanding this sentence correctly.  I think the
>> envelope provided by the database IS the envelope the device is expected to
>> conform to (the device doesn't have a choice in this matter).
>>
>>
>> Well I don't know any other way to say this - with method proposed now
>> for PAWS, the "envelope provided by the database" does not fully define he
>> envelope that the device is expected to conform to per FCC regulations.  It
>> addresses only one of many variables.
>>
>> The FCC expects that the device will only transmit in the TV channels
>> which the database says are available. When the FCC sells off some of these
>> TV channels, the database will forever after exclude those channels from
>> what is available. \
>> Existing devices will "adapt" because when they ask what they can use,
>> the answer will never include those it can no longer use. That is simple
>> enough.  The "envelope" has not changed in this case, and we don't need to
>> know it to adapt to changes in what chunks of spectrum are available.
>>
>> How a device transmits in those channels (i.e. the  "envelope" the signal
>> must meet) is defined by a number of variables,  of which the TX power
>> averaged over a frequency range (the TV channel) is only one. Notall are
>> enumerated obviously in Subpart H of part 15 (the TVBD rules), as many are
>> included by reference or implication (requirements inherited because it's
>> part 15).  Right now the designer and the test house need work with what is
>> hard coded  in the regulations.  To address dynamically adjusting to
>> changes in the emissions requirements when using an available chunk of
>> spectrum, we'd have to have a way to signal any and all of the parameters
>> that currently are testing in conformance and quite possibly more.
>>
>> There's a group in IEEE 1900 that is working on standards for dynamic
>> spectrum.  I think it would be useful if PAWS and 1900.5 collaborated.
>>
>> -B
>>
>>
>>
>>
>> On Fri, Oct 25, 2013 at 4:33 AM, Peter Stanforth <
>> [email-masked]> wrote:
>>
>>>  Andy, First of all I didn’t mean to sound like I was picking on you. I
>>> still have a hard time speaking IETF, me, and not as our organization.  I
>>> agree with your thought on the key benefit of a DB. My question relates to
>>> how we resolve radio certification issues against policy updates
>>> implemented by the database.  In the example you cite about power limits we
>>> currently resolve that by FCCID (as an example we currently support a
>>> waiver for a low power fixed device (Specific FCCID) that gets treated
>>> differently than a high power fixed device) but all of this is taken care
>>> of inside the database.  We don’t have a situation where a device has to
>>> decide between it’s certified performance envelope and one provided by a
>>> database. Should be an easily solvable problem, but I suspect this is more
>>> of a regulatory issue than a technical/PAWS issue.
>>>
>>>  Peter S.
>>>
>>>   From: Andy Lee <[email-masked]>
>>> Date: Thursday, October 24, 2013 at 7:35 PM
>>> To: Peter Stanforth <[email-masked]>
>>> Cc: "Benjamin A. Rolfe" <[email-masked]>, "[email-masked]" <
>>> [email-masked]>
>>>
>>> Subject: Re: [paws] Question: Encode slopes?
>>>
>>>   Hi,
>>>
>>>  if, in the future Andy provides different characteristics my device
>>>> may no longer compliant with the rules and should not be operating.
>>>
>>>
>>>  I'm not sure I understand this point or why anything would become
>>> non-compliant.  Whether PAWS sends the spectrum data with "flat" encoding
>>> or "sloped" encoding is independent of device compliance.  Supposing the
>>> FCC modifies the rules in the future and allows 50 mW and 120 mW instead of
>>> 40 mW and 100 mW limits, then the PAWS will update accordingly (no matter
>>> which encoding is used).
>>>
>>>  We've always held that one of the key benefits of database managed
>>> spectrum is the ability to have device automatically adapt when spectrum
>>> resources change (e.g., the "incentive auction" 600 MHz NPRM) or when
>>> protection rules need to be changed (e.g., interference is being reported
>>> and the calculations need to be modified).  It gives regulators the power
>>> to make tweaks to spectrum policy without having to displace a large
>>> installed base of devices.
>>>
>>>  From a "black box" perspective, the emissions limits are what define
>>> whether a WSD will cause interference or not.  In very basic terms, if the
>>> emissions are low enough, there is no way for the device to cause
>>> interference.  The database is simply providing the WSD information so that
>>> it can configure operating parameters to stay below those emissions limits.
>>>
>>>  Best regards,
>>>
>>> On Thu, Oct 24, 2013 at 11:09 AM, Peter Stanforth <
>>> [email-masked]> wrote:
>>>
>>>>  The concept of the database acting as a policy  manager is very
>>>> appealing - but not simple. Which is why my preference is still to put this
>>>> in version 2 and think through all the issues.
>>>> Putting my device developer hat on I can’t reconcile the policy manager
>>>> concept under current FCC rules. It is a Catch 22. Assuming I certify today
>>>> it will be against a specific set of operating characteristics. I would
>>>> expect Andy to provide those same characteristics in his implementation.
>>>> However if, in the future Andy provides different characteristics my device
>>>> may no longer compliant with the rules and should not be operating. However
>>>> if I adjust the operating characteristics the device is no longer in
>>>> compliance with its certification, and would be operating illegally. So
>>>> either the “new” rule permits grandfathered operation or my device needs to
>>>> be re-certified.  It seems like we have to convince Regulators to certify
>>>> databases as policy managers and simply certify radios to ensure they
>>>> comply with the policy they are given for this concept to work.
>>>>
>>>>   From: "Benjamin A. Rolfe" <[email-masked]>
>>>>  Date: Wednesday, October 23, 2013 at 7:30 PM
>>>> Cc: "[email-masked]" <[email-masked]>
>>>>
>>>> Subject: Re: [paws] Question: Encode slopes?
>>>>
>>>>  One should take careful note that the spectrum profiles used in the
>>>> 802.11 DO NOT specify regulatory requirements, as such is out of scope of
>>>> 802.11 as clearly sated in the boilerplate to the standard:
>>>>
>>>> "Compliance with the provisions of any IEEE standards document does not
>>>> imply compliance to any applicable regulatory requirements."
>>>>
>>>> The mask specified in annex D of 802.11-2012 specifies requirements on
>>>> an 802.11 device both as a transmitting device (it should fall within the
>>>> boundaries of the envelope given) and as a receiving device (it must
>>>> capture a signal that meets these requirements and tolerate emissions
>>>> within this envelope spilling into the channel.  This does NOT assure
>>>> regulatory compliance anywhere on earth (or elsewhere).
>>>>
>>>> With that out of the way,  Andy's suggestion below ceertainly makes
>>>> this "mask" representation more useful.  I did go back and review the
>>>> emails on this topic and at least once it was stated that the goal of this
>>>> "mask" is to capture regulatory requirements that may change from region to
>>>> region, or over time, so that an implementation may be adaptable instead of
>>>> having emission requirements hard coded. The current representation does
>>>> not seem to meet that goal.  The enhancements that Andy shows below would
>>>> come closer.
>>>>
>>>> If the current desire of the majority is to "get on with it" addressing
>>>> known regulations now and deal with enhancements such as this in version 2,
>>>> then I'd suggest removing the "mask" representation from the draft for now,
>>>> and add it when the group feels it is appropriate to take the time to
>>>> define it  completly.   To meet the current rules that are approved for
>>>> TVWS devices (FCC) we don't need the "mask" represented (as at least one
>>>> database has been approved without it).  It would be a very useful
>>>> enhancement to be able to derive the in-channel and near-channel emission
>>>> masks from the database, but it is only if it is complete.
>>>>
>>>>
>>>>
>>>>  On 10/23/2013 12:23 PM, Andy Lee wrote:
>>>>
>>>> Speaking as another FCC certified database provider, we do supply a
>>>> spectrum mask, and the response from the database is specified in terms of
>>>> frequencies rather than channels.
>>>>
>>>>  As an industry reference, Wi-Fi has been using spectrum profiles with
>>>> slopes for many years now (link to spec<http://standards.ieee.org/getieee802/download/802.11-2012.pdf>).
>>>>  See section D.2.3 Transmit Spectrum Mask requirements.  The relationship
>>>> between this transmit spectrum mask and the TVWS emission limit mask is
>>>> very relevant to picking operating frequencies, especially around channel
>>>> 37 and the band edges.
>>>>
>>>>
>>>>  Best regards,
>>>>
>>>>
>>>> On Wed, Oct 23, 2013 at 8:47 AM, Peter Stanforth <
>>>> [email-masked]> wrote:
>>>>
>>>>>  Speaking as an FCC certified TVWS database provider, we do not
>>>>> supply any information to the devices related to EIRP, PSD, mask or similar
>>>>> characteristics.
>>>>> The device supplied FCCID tells us what the FCC compliance is (high
>>>>> power fixed, personal/portable mode 1 or 2) and we calculate protection,
>>>>> and respond with channel lists based on this.
>>>>> All the device gets is a list of channels that it is legally allowed
>>>>> to operate on, based on the device classification provided.
>>>>>
>>>>>   From: "Benjamin A. Rolfe" <[email-masked]>
>>>>> Date: Wednesday, October 23, 2013 at 11:40 AM
>>>>> To: "[email-masked]" <[email-masked]>
>>>>>
>>>>> Subject: Re: [paws] Question: Encode slopes?
>>>>>
>>>>>  It would seem from the thread that this method of specifying a
>>>>> "mask" (emission limits) does not address the known regulatory requirements
>>>>> in the United States, where a simple rectangle does not describe the
>>>>> emissions profile limits.
>>>>> This circles me back to the question I asked quite a while ago, which
>>>>> is how, as a device developer, do I use this information?  What is the
>>>>> purpose of providing a "mask"?
>>>>> Related question: Do the current FCC approved databases provide this
>>>>> "mask" information now?
>>>>> Thanks
>>>>> Ben
>>>>>
>>>>>
>>>>>  On 10/23/2013 1:44 AM, Ray Bellis wrote:
>>>>>
>>>>> On 22 Oct 2013, at 17:07, Peter Stanforth <[email-masked]> <[email-masked]> wrote:
>>>>>
>>>>>
>>>>>
>>>>> Took the words right out of my mouth! My preference is to make sure we have addressed all known regulator issues, for which I don't believe this is required, and then do this right next time.
>>>>>
>>>>>
>>>>>
>>>>> +lots
>>>>> Ray
> This message is subject to the CSIR's copyright terms and conditions,
> e-mail legal notice, and implemented Open Document Format (ODF) standard.
> This message has been scanned for viruses and dangerous content by *
> MailScanner* <http://www.mailscanner.info/>,

-- 
-vince