F4HOF

This page is read only. You can view the source, but not change it. Ask your administrator if you think this is wrong.
====== Transceivers data pour 70cm ======

FIXME: page encore en cours de rédaction

Nous avons besoin de compléter la connectivité Hamnet sur la bande des 430MHz, à débit intermédiaire pour plusieurs raisons:
  - __Briser la barrière des 9600bps__: La bande des 70cms est la première à ne pas placer de restriction de largeur de bande autre que celle de nos allocations.
  - __Réaliser des faisceaux hertziens difficiles__: à utiliser en dernier recours pour prolonger la connectivité là où les bandes plus hautes ne se propagent pas.
  - __Accès hamnet mobile/portable__: assurer une connectivité cellulaire et (enfin) permettre aux OMs. Bien que la bande soit à risque sur le long terme, envisager une extensibilité sur 23cm, pour permettre une densification des cellules dans les zones où le 70cm ne peut accepter de nouvelles fréquences.

===== Idées de fonctionnalités =====
  * Canaux radio de 300kHz à 1MHz max, pour avoir un débit confortable sans monopoliser toute la bande.
  * Débit physique de 250 à 500kbps en fonction de la capacité matérielle, pour permettre un débit effectif entre 128 et 430 kbps après correction d'erreur.
  * Correction d'erreur obligatoire, si possible adaptative: nécessaire pour augmenter significativement la fiabilité des transmissions en condition réelles.
  * MTU programmable de 576 à 1526 octets (1500 octets avec un header 802.1ad). Même si on préfère des MTU courtes pour limiter le temps radio consommé et les probas d'erreurs, 1526 octets peuvent être émis en moins de 200ms avec le débit utilisateur ciblé (pour comprendre le choix de 200ms, se référer à la [[https://tools.ietf.org/html/rfc1144#section-5.2|RFC 1144, section 5.2 "Choosing a maximum transmission unit"]]).
  * Pas de fragmentation IP. Aucune exception. Ce mécanisme est connu pour être problématique [[http://www.hpl.hp.com/techreports/Compaq-DEC/WRL-87-3.pdf|depuis 1987]] (copie d'archive: {{ :hamnet:ipfrag-harm-dec-87-3.pdf |Fragmentation Considered Harmful}}), et dangereux avec les datagrammes UDP, comme l'indique cette [[https://www.ietf.org/proceedings/66/slides/tsvarea-1.pdf|présentation effectuée durant l'IETF 66]] (copie d'archive: {{ :hamnet:ipfrag-harm-ietf-2006.pdf |Fragmentation Considered Very Harmful}}). On règle des problèmes causés sur TCP avec un ajustement de la MSS, si applicable.
  * Deux modes: 
    * **Raw Ethernet** (trames ethernet brutes, pour prototypage, et du FH)
    * **Infrastructure** (mode point d'accès).
  * Au moins une version du matériel construit devra être disponible avec un port ethernet, pour permettre une interopérabilité maximum. Ça n'empêche pas de développer des modules USB/PCI plus tard, mais celà évite d'assurer de support spécifique pour les plateformes fermées.
  * Alimentation électrique: plage acceptée de 9-15V au minimum, 9-30V idéalement, pour être compatible avec les pratiques déjà en place (pas concerné pour d'autres types de transceiver).


==== Spécifiquement sur le mode Raw ethernet ====
  * Insertion d'un header radio simple inspiré de ce qui se fait en D-Star pour indiquer la station émettrice.
  * Méthode d'accès au medium: CSMA/CA simple.
  * Optimisation protocolaire optionnelle sur l'équipement:
    * Cache ARP aggressif (TTL de 10 minutes mini, ReTX de demandes freiné à 5 secondes sur l'air)
    * Blacklist de protocoles de niveau 2 "sales" (sans valeur ajoutée sur l'air, et qui gaspillent du temps radio)
    * Blacklist multicast.
    * Blacklist broadcast (sauf pour ARP).
    * Cache DNS aggressif (à envisager)


==== Spécifiquement sur le mode Infrastructure ====


FIXME: encore à développer, je dois éplucher le fonctionnement d'EUTRAN, LTE et d'EPC pour regarder ce qu'on peut en tirer de bon et ne pas simplement repartir sur du Wi-Fi.

  * Méthode d'accès au medium: CSMA/CA simple. Échange CTS/RTS a envisager, mais à activer explicitement par l'utilisateur.
  * Trames balise pour permettre la découverte et le suivi des stations de base
    * Indication d'une QRG secondaire (pour dégagement sur fréquences plus hautes, 23cm principalement, 33cm dans les pays qui l'autorisent.)
    * Indication de QRG adjacentes
    * Champs d'options
  * ESSID pour désigner l'indicatif relais, dont le format est calqué sur ce qui est fait en D-Star pour les callsign.
  * Frame bursting?
  * Duplex optionnel?
  * Groupement d'AP par "confédération"
    * Pour permettre le roaming de niveau 2 entre les membres de cette confédération. A minima entre fréquences et/ou secteurs d'un point haut, au mieux en étendant à un groupe de points hauts.
    * En mode point à point, en calquant les [[https://www.slideshare.net/schwannden/lte-x2-interface|fonctions de l'interface X2 de LTE]], mais avec un peu de dégraissage (pas question de monter réseau LTE ici).
    * Découverte en multicast par le côté backhaul.

=== Identifiant de confédération ===
| MCC (2 octets) | MZC (1 octet) | MHC (1 octet) |

Le MCC (Mobile Country Code), stocké sous forme d'entier non signé. Les octets sont stockés dans l'ordre du réseau. La valeur du MCC est celle définie dans ITU E.212.

Le MZC (Mobile Zone Code) est un identifiant de zone géographique stocké sous forme d'un entier non signé. On essayera de faire correspondre cet identifiant au découpage géographique en vigueur dans le pays (département en France, land en Allemagne, préfecture au japon, sujet en Russie, etat aux Etats-Unis...). Ce nombre est volontairement pris très élevé pour avoir des codes de réserve. En effet, on pourra ainsi affecter des codes supplémentaire dans les zones où le maillage serait plus élevé (métropoles, villes).

Le MHC (Mobile Hive Code) est un identifiant de confédération dans une zone, stocké sous forme d'un entier non signé. 

La totalité des cellules d'une confédération doivent partager une connectivité de niveau 2.