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 interoger 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 7159). 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 :
