Mon blog

Ah, les espaces blancs (ou fréquences blanches, ou canaux non-utilisés), un nom qui fait rêver, et penser à des mystérieuses zones inconnues sur une carte, qui attendent leurs courageux explorateurs, qui vont s'installer, virer des indigènes inutiles, et faire pousser bananes et café dans ce qui n'était qu'une jungle. Dans le monde des ondes radios, les espaces blancs sont les fréquences qui ont été réservées à un moment mais qui ne sont pas utilisées en pratique, et sont donc susceptibles d'être affectées à un autre usage. Encore faut-il savoir pour cela quelles sont les fréquences libres dans une région donnée, et c'est le rôle du protocole décrit dans ce RFC.

La traduction de « white space » par « espace blanc » figure par exemple dans ce rapport de l'ANFR. On parle aussi de « canaux non utilisés » pour les fréquences libres, et de « réutilisation du spectre » pour le concept, qui agite pas mal de régulateurs des télécommunications et d'industriels. L'idée de base du groupe de travail PAWS de l'IETF (c'est son deuxième RFC après le RFC 6953) est de concevoir un protocole qui permette à une machine en promenade de trouver facilement quelles sont les fréquences libres dans sa zone géographique. En effet, « L’une des difficultés de l’utilisation de ces fréquences blanche [sic] est qu’elles forment un véritable "gruyère" parce que ce sont des petites bandes de fréquence qui se trouvent entre des canaux de TV affectés à des endroits différents selon les régions. La technologie doit donc déterminer avec précision les canaux pré-existants et éviter les interférences locales. » La machine en promenade ne peut donc pas utiliser une bande de fréquence pré-réglée, il faut qu'elle s'adapte aux conditions locales. L'idée est que toutes les fréquences du « gruyère » soient enregistrées dans des bases publiques, et que la machine nomade puisse interroger ces bases, avec ce nouveau protocole PAWS (Protocol to Access White-Space database).

Le RFC 6953 résumait le problème des espaces blancs et les scénario d'usage de ces espaces. L'idée centrale est d'avoir une base de données des espaces blancs (donc des fréquences utilisables) et de la rendre accessible aux engins en déplacement (ordinateurs, smartphones, etc). En effet, vu la complexité de ces espaces, et leur caractère partagé, ce qui a nécessité de nombreuses règles quand à leur usage (telle que la puissance maximale d'émission), et les changements permanents dans ce domaine, essayer de mettre l'information sur chaque appareil est une tâche sans espoir. On la met donc uniquement dans un petit nombre de bases de données. Ce choix impose donc un protocole standard d'accès à ces bases et ce protocole, sans surprise, est conçu au dessus de HTTPS, avec un encodage en JSON.

Donc, PAWS est client/serveur, le client (Master Device, dans le RFC) est l'appareil en mouvement, et qui voudrait bien émettre dans les espaces blancs, et le serveur est la base de données officielle (sections 2 et 3 du RFC). Le client doit d'abord obtenir l'URI du serveur, envoyer des requêtes HTTP pour savoir ce que la base de données peut lui dire (ce qu'on nomme l'initialisation), puis demander quels sont les espaces blancs utilisables dans la région où se trouve le client, et à quelles conditions. Le serveur va alors lui envoyer l'information. (La base de données n'est pas forcément publique, elle peut imposer à ses clients d'être préalablement enregistrés.)

La section 4 du RFC détaille chacune de ces étapes. Pour découvrir le serveur, le client a une liste d'URI en dur dans sa configuration. Ces URI peuvent désigner une base de données, ou bien un service « méta » (géré, par exemple, par le régulateur des télécommunications du pays) qui indiquent plusieurs bases possibles (cf. l'annexe A du RFC). Rien de très souple ici, surtout quand on change de pays.

Certaines bases vont demander que le client s'enregistre. Par exemple, aux États-Unis, la FCC l'impose pour les clients fixes. Il existe donc des messages d'enregistrement dans PAWS. Une fois l'initialisation et l'éventuel enregistrement fait, passons à l'essentiel, la requête demandant les fréquences disponibles. Le client indique sa localisation et certaines autres caractéristiques, comme les fréquences qu'il est techniquement capable d'utiliser, le serveur lui répond avec une liste de fréquences, avec les puissances d'émission maximale dans chaque plage, et les heures où on peut émettre (au format du RFC 3339). Le client peut alors choisir une fréquence, en fonction de ses critères.

La section 5 contient quelques détails sur les requêtes et réponses. Par exemple, la position du client est indiquée par un simple point, ou sous forme d'une région, selon les règles de la section 5 du RFC 5491 (pour les amateurs de géométrie). Le client indique les caractéristiques de son antenne (car elles peuvent influer la réponse) comme sa hauteur. D'autres caractéristiques (comme la direction dans laquelle pointe l'antenne) peuvent être indiquées, et, si elles ne sont pas dans ce RFC 7545, elles seront peut-être enregistrées dans le registre des paramètres PAWS. La requête, décidément très bavarde, peut inclure des informations sur le propriétaire de la machine cliente et, dans ce cas, elles doivent être au format jCard (RFC 7095, un exemple figure dans la section 6.4 de notre RFC).

Bien sûr, la requête peut échouer et, dans ce cas, un objet Error est renvoyé, contenant un code numérique et un message texte. Les codes numériques peuvent être négatifs, comme le -104 de l'exemple ci-dessous, qui signifie que la base de données n'a pas d'information sur la région demandée. (L'ensemble des codes d'erreur est dans un registre IANA.)

Tous ces messages sont encodés en JSON-RPC, avec du contenu en JSON (RFC 8259). La requête est un objet JSON dont un des membres est method, qui indique la méthode (le type de requête). La réponse est un objet JSON dont un des membres est result (ou error), qui contient le résultat demandé. Parmi les méthodes possibles, la plus importante est certainement spectrum.paws.getSpectrum qui est la demande des plages de fréquences blanches.

Il semble qu'il existe plusieurs mises en œuvres de PAWS, en tout cas c'est ce qui s'est dit dans des réunions IETF. Mais la seule que je connais est celle de Google (il y a une bonne documentation de la base utilisée). On peut avoir un accès limité sans engagement (à part un compte Google et une clé d'API), il faut signer un contrat si on veut un accès moins limité. Cette base ne couvre que les USA. Attention, les objets JSON utilisés sont ceux d'une version antérieure de la norme, pas tout à fait les mêmes que dans le RFC. Voici un exemple de script shell pour faire une requête, via curl :

#/bin/sh

# Replace with your own key, see https://developers.google.com/spectrum/paws/gettingstarted
API_KEY=XXXXXX

if [ -z "$2" ]; then
    echo "Usage: $0 longitude latitude" 
    exit 1
fi
lon=$1
lat=$2

curl -XPOST https://www.googleapis.com/rpc -H "Content-Type: application/json" --data "{
  \"jsonrpc\": \"2.0\",
  \"method\": \"spectrum.paws.getSpectrum\",
  \"apiVersion\": \"v1explorer\",
  \"params\": {
    \"type\": \"AVAIL_SPECTRUM_REQ\",
    \"version\": \"1.0\",
    \"deviceDesc\": { \"serialNumber\": \"your_serial_number\", \"fccId\": \"TEST\", \"fccTvbdDeviceType\": \"MODE_1\" },
    \"location\": { \"point\": { \"center\": {\"latitude\": $lon, \"longitude\": $lat} } },
    \"antenna\": { \"height\": 30.0, \"heightType\": \"AGL\" },
    \"owner\": { \"owner\": { } },
    \"capabilities\": { \"frequencyRanges\": [{ \"startHz\": 100000000, \"stopHz\": 950000000 }] },
    \"key\": \"$API_KEY\"
  },
  \"id\": \"Test PAWS\"
}"

Et son résultat, pour la ville de Denver :

% sh test-paws.sh 39.739167 -104.984722 
{
 "jsonrpc": "2.0",
 "id": "Test PAWS",
 "result": {
  "kind": "spectrum#pawsGetSpectrumResponse",
  "type": "AVAIL_SPECTRUM_RESP",
  "version": "1.0",
  "timestamp": "2015-05-24T16:20:35Z",
  "deviceDesc": {
   "serialNumber": "your_serial_number",
   "fccId": "TEST",
   "fccTvbdDeviceType": "MODE_1"
  },
  "spectrumSchedules": [
   {
    "eventTime": {
     "startTime": "2015-05-24T16:20:35Z",
     "stopTime": "2015-05-26T16:20:35Z"
    },
    "spectra": [
     {
      "bandwidth": 6000000.0,
      "frequencyRanges": [
       {
        "startHz": 5.4E7,
        "stopHz": 5.12E8,
        "maxPowerDBm": -56.799999947335436
       },
       {
        "startHz": 5.12E8,
        "stopHz": 5.24E8,
        "maxPowerDBm": 15.99999928972511
       },
       {
        "startHz": 5.24E8,
        "stopHz": 5.36E8,
        "maxPowerDBm": -56.799999947335436
       },
       {
        "startHz": 5.36E8,
        "stopHz": 5.42E8,
        "maxPowerDBm": 15.99999928972511
       },
       {
        "startHz": 5.42E8,
        "stopHz": 5.48E8,
        "maxPowerDBm": -56.799999947335436
       },
       {
        "startHz": 5.48E8,
        "stopHz": 5.54E8,
        "maxPowerDBm": 15.99999928972511
       },
       {
        "startHz": 5.54E8,
        "stopHz": 6.5E8,
        "maxPowerDBm": -56.799999947335436
       },
       {
        "startHz": 6.5E8,
        "stopHz": 6.56E8,
        "maxPowerDBm": 15.99999928972511
       },
       {
        "startHz": 6.56E8,
        "stopHz": 6.68E8,
        "maxPowerDBm": -56.799999947335436
       },
       {
        "startHz": 6.68E8,
        "stopHz": 6.74E8,
        "maxPowerDBm": 15.99999928972511
       },
       {
        "startHz": 6.74E8,
        "stopHz": 6.86E8,
        "maxPowerDBm": -56.799999947335436
       },
       {
        "startHz": 6.86E8,
        "stopHz": 6.98E8,
        "maxPowerDBm": 15.99999928972511
       }
      ]
     }
    ]
   }
  ],
  "needsSpectrumReport": false,
  "rulesetInfo": {
   "authority": "US",
   "maxLocationChange": 100.0,
   "maxPollingSecs": 86400,
   "rulesetIds": [
    "FccTvBandWhiteSpace-2010"
   ]
  }
 }
}

Si on tente un lieu situé en dehors des USA :

{
 "error": {
  "code": -104,
  "message": "Requested location is outside the supported coverage zone",
  "data": [
   {
    "domain": "global",
    "reason": "invalidParameter",
    "message": "Requested location is outside the supported coverage zone"
   }
  ]
 },
 "jsonrpc": "2.0",
 "id": "Test PAWS"
}

Le monde de la gestion des fréquences radio est évidemment lourdement régulé, puisqu'il s'agit d'un espace partagé. Dans l'exemple ci-dessus, on voit la mention que les règles de la FCC s'appliquent ("rulesetIds": ["FccTvBandWhiteSpace-2010"]). D'autres organismes de régulation peuvent intervenir, par exemple l'identifiant de règles (rulesetIds) de l'ETSI serait ETSI-EN-301-598-1.1.1.

Un peu de sécurité, pour finir (section 10). D'abord, PAWS ne permet pas de vérifier que le client utilisera correctement les informations fournies. PAWS envoie des données, c'est au client de les appliquer. Si ce dernier décide d'émettre dans d'autres bandes de fréquences que celles indiquées, ou bien d'utiliser les bandes indiquées, mais avec une puissance supérieure à ce qui est autorisé, PAWS n'offre aucun mécanisme pour l'en empêcher.

On peut imaginer d'autres risques, comme un client redirigé vers un faux serveur PAWS. L'utilisation de HTTPS protège normalement contre cela, le nom du serveur de la base devant être dans le certificat. Enfin, PAWS peut poser des problèmes de vie privée : le client fournit des données de localisation, ce qui permet au serveur de suivre le client.

Quelques lectures pour finir :

• Le point de vue de la FCC,
• Celui de Google.
• La base britannique.