User Tools

Site Tools


hamnet:70cm

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revisionPrevious revision
Next revision
Previous revision
hamnet:70cm [2017/05/04 05:53] – [Idées de fonctionnalités] f4hofhamnet:70cm [2017/05/04 06:33] (current) – [Spécifiquement sur le mode Infrastructure] f4hof
Line 4: Line 4:
  
 Nous avons besoin de compléter la connectivité Hamnet sur la bande des 430MHz, à débit intermédiaire pour plusieurs raisons: Nous avons besoin de compléter la connectivité Hamnet sur la bande des 430MHz, à débit intermédiaire pour plusieurs raisons:
-  - __Réaliser des faisceaux Hertziens difficiles__: pour prolonger la connectivité là où les bandes plus hautes ne se propagent pas. +  - __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. 
-  - __Accès hamnet mobile__: assurer une connectivité cellulaire pour (enfin) permettre aux OMs de pouvoir briser la barrière des 9600bps. 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. +  - __Réaliser des faisceaux hertziens difficiles__: à utiliser en dernier recours pour prolonger la connectivité là où les bandes plus hautes ne se propagent pas. 
-  - FIXME+  - __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 ===== ===== Idées de fonctionnalités =====
-  * Débit de sig: de 250 à 500kbps en fonction de la capacité matérielle, pour permettre un débit effectif entre 128 et 430 kbps+  * Canaux radio de 300kHz à 1MHz max, pour avoir un débit confortable sans monopoliser toute la bande. 
-  * Canaux radio de 300kHz à 1MHz+  * 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: augmente significativement la fiabilité des transmissions en condition réelles. +  * 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 et les probas d'erreurs, 1526 octets peuvent être émis en moins de 200ms avec le débit utilisateur ciblé (pour la raison des 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"]]).+  * 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.   * 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:    * Deux modes: 
     * **Raw Ethernet** (trames ethernet brutes, pour prototypage, et du FH)     * **Raw Ethernet** (trames ethernet brutes, pour prototypage, et du FH)
     * **Infrastructure** (mode point d'accès).     * **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 ce point est nécessaire pour étendre l'interopérabilité sans assurer de support spécifique pour les plateformes fermées.+  * 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).   * 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).
  
Line 50: Line 50:
     * Découverte en multicast par le côté backhaul.     * 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.
hamnet/70cm.1493877232.txt.gz · Last modified: 2017/05/04 05:53 by f4hof