This record of the proceedings of the above event has been compiled by Mike G7RAZ, to whom corrections should be sent (either by packet to G7RAZ@GB7WIS.#22.GBR.EU or by email to MikeWager[at]aol.com).
These minutes are not intended to be an exhaustive account of the proceedings, and readers who would like more details are asked to refer to the full texts of the original presentations where available (see links in agenda and minutes below)
| 2E1GJN | Martin | |
| G0CNG | Chris | MAXPAK Chairman, Sysop GB7MAX, BLOX, WOLVES |
| G0EWH | Richard | Fourpak Treasurer |
| G0HHH | Geoff | |
| G0KFS | Albert | |
| G0LGS | Stewart | Sysop GB7LGS |
| G0SYR | Bryan | Sysop |
| G0TWN | David | Sysop |
| G0WCI | Mark | |
| G1DVA | Paul | Sysop GB7MIP |
| G1PLT | Paul | |
| G1IXV | Colin | Sysop |
| G1YGY | Chris | |
| G3ZFR | Roger | Sysop GB7COV, DCC member |
| G4APL | Paul | |
| G4DIE | Ian | |
| G4FPV | Steve | Fourpak Chairman, sysop GB7GLO, MLVN |
| G6AWT | Nick | Fourpak committee member |
| G6KUI | Peter | Sysop GB7DBY |
| G6TJZ | Peter | Sysop GB7TJZ |
| G6VEY | Ian | Sysop |
| G7BNK | David | |
| G7NZM | Geoff | |
| G7RAZ | Mike | Minutes Secretary, sysop GB7WIS |
| G7VBJ | David | |
| G8MNY | John | |
| G8PZT | Paula | Fourpak Secretary, Sysop GB7PZT, KIDDER |
| M0CYP | Andy | |
| M0DCM | David | |
| M1FDE | Anthony | Chelmsford Amateur Radio Society |
M0PZT, M1CUK, G0FTD, G1DVU, G1NNB, GM3YEW, G4JCP, G4ROA, G6HJP
The Conference began at 10.00am and Steve G4FPV (Chairman of Fourpak) welcomed the delegates and thanked Paula for organising the agenda and recruiting volunteers.
Steve was then persuaded to continue in the role of Conference Chairman, after which Mike G7RAZ was appointed Minutes Secretary.
Steve proceeded to invite the speakers and chair the debates. See Minutes Parts 2-4 for further details.
A brief update on progress since the last conference brought proceeding to an end a little after 5.00pm. Steve G4FPV thanked all who had contributed to the organisation of the conference, most notably Paula G8PZT for having cajoled contributions, coordinated the agenda and arranged the venue.
Chris gave an update of the MAXPAK network in the Wolverhampton area. He observed that the network had many radio links even in this era of Internet usage. Hard copies of his PowerPoint slides were offered and he reminded delegates that information was also available from Digicom, the MAXPAK newsletter.
The main MAXPAK node, GB7WV, is situated in the Mander Centre in the middle of Wolverhampton. It runs Xrouter and is giving good service, with thanks to various assistants (including Peter G6KUI). Some jobs remain to be done, but Chris was pleased with the current situation.
Chris outlined WV’s various links (e.g. to GB7VT in Newcastle-under-Lyme, to Worcester, to Corley, to GB7MAX/BLOX in Bloxwich), described its user ports (accessible within a 30 mile radius), and mentioned its APRS digipeater.
New links were in the pipeline. A link to a node in Telford is being developed; one port is already working, with a 4m port still to complete. Coming soon will be a 23cms link into the WV system - possibly in the summer. Links to Sedgeley, and Kings Heath (south Birmingham) are also envisaged.
Chris described the BBS provision within the network. GB7MAX in Bloxwich has both telnet and RF access (4m, 2m, 70cms). Also GB7PMB in Newport. AXUDP links from BLOX extend to a range of national and international destinations.
During the questions which followed, delegates were pleased to note the amount of RF being used for linking. Chris also invited applications from anyone interested in linking, as there was some spare capacity.
Original text of GlobalNet presentation
Paula explained that her inspiration for this idea was seeing people texting each other on their mobile phones; it was a slow but popular means of communication. Why not have a similar application with Packet Radio? We have the equipment - it only needs some software and a suitable protocol. APRS might be seen to perform this function, but it relies on a single congested frequency and is not reliable over long distances. Need to route packets from source to destination without knowledge of intervening nodes. Paula’s focus is to develop a global infrastructure software and protocols, reliant in part on the Internet but using radio where possible and most essentially at the users’ end.
The existing packet network has severe limitations. If we are on holiday in Spain, the local packet node may well be ignorant of any UK nodes, so we’d have to node-hop (which could take a longer time to get through, with RTT timing means that the link will drop out). Moreover users are not part of the network, so you can’t connect directly to them. Finally NETROM doesn't have a datagram mode, for sending a singe self-contained packet from one end user to another.
We need a global addressing and routing scheme to allow connections without knowing the routes. E.g. "CONNECT ZL2VAL" is all you want. Should support all layers, support datagrams, support control protocol, and remain compatible with existing software and protocols (as there will always be those who will not change).
Can change in an evolutionary manner. If idea good - otherwise system will remain as before.
NETROM is widely used, it works well on radio and routing is self-configuring, but has only a finite space for nodes table. It is not scaleable (e.g. can’t handle a node table of 100,000 nodes) It has no datagram mode and so can’t do user-to-user circuits.
On the other hand IP would be OK. But it needs wire links or very reliable links. Its protocol is verbose making it inefficient on radio. Despite the presence of IP in some nodes it is not realistic to get IP to every node.
Paula said she didn’t know much about ROSE or FlexNET, but in any case there was little chance of getting sysops to all change to a different system.
She suggested a possible compromise - to extend Netrom without breaking the existing network. Some of the current nodes in the Netrom list could be GlobalNet routers. These nodes would form a network of their own, exchanging GlobalNet traffic through the Netrom network. They could also tunnel GlobalNet through TCP/IP networks.
By making the protocol open and extensible we allow any software author to implement it, experiment with it and develop it further. It would be a virtual private network, free from the spamming, jamming and hacking in the Internet world.
GlobalNet would need to adapt Netrom by replacing callsigns with hierarchical information, which can then be used to route the packet to its desired destination. Compare IP where Paula’s address (44.131.91.2) tells anyone in the world where her station can be located.
A GlobalNet node would knows how to reach the major routers in each country and then they in turn know how to get to the local nodes, and so on.
These addresses should be made easy to understand, remember and administer (at a local level). They should also be as short as possible to avoid waste of space..
Paula’s preference was to use the dotted quad system (as with IP). The hierarchical system is fairly easy to understand and administer. Also a DNS service could be instated to enable looking up of calls, names, etc.
Paula outlined various routing considerations. Routes are configured manually at the moment, but eventual automatic configuration is envisaged, using a node discovery protocol (currently implemented in Xrouter, albeit temporarily disabled).
Packet format was presented in some detail. Also the range of services which could be catered for (e.g. APRS, node, PMS, name server, time server, etc).
GlobalNet would have a diagnostic side, and be able (for example) to report reasons for a packet having been dumped - Netrom just dumps any packet it cannot route.
The project is at an early stage. Basic functionality is present in Xrouter, but as yet not implemented, nor is it fully documented. Node sysops can ping GlobalNet nodes (using the GPING command) and can connect from one GlobalNet node to another using the GlobalNet address. It has been tested between UK and NZ. But it is still at an experimental stage, and may see changes yet, for example in packet format.
Future development: The self-configuring of Netrom is a plus. Paula would like the sysop to be able to enter the node’s address and leave the node to self-configure. It needs protocol numbers and client protocols. Open source client software needs to be developed. Dynamic address allocation would be desirable to enable transportability of users. Hopefully GlobalNet would make PR much more fun.
Conference delegates were interested in this new venture, although there was concern about its name which may be shared by an existing ISP. Paula had been unaware of this, and agreed to find a new name.
When asked about help, Paula said that individual users’ help was not so much sought as input from a software writer for the user interface - user to node protocol.
The problem with IP’s fixed nature was addressed. We need a dynamic DNS. Would also have DHCP - where users connect to local node and are allocated a dynamic IP-type address. Ideally amateurs should be able to "roam" (e.g. if in a car).
Paula wanted to put out some test bed software (open source) and let people play with it and develop in the light of experiences. It could work over IP and AX25 frames but there is a problem of an absence of protocol. Protocol numbers have nearly all be snapped up - no more for allocation to protocol developers - we would have to pinch one of already allocated protocols numbers.
We need to introduce the concept to the users, so that users can know it exists and play with it - using existing equipment. We should be able to connect to a local node and then connect to a GN node.
If you're not running Xrouter, Paula could supply the source code, so that it could be written into Linux, for example. Interested parties can go to web site and further cooperation and development is now possible. Once up and running, users can be invited into the experiment - publicity can be placed into magazines etc.
The time scale for delivery of messages was raised. Would it be minutes? Ideally, it would be instant. But if a message doesn't get sent, the user will be informed of non-delivery. The message would be stored on the destination system. If the sending user had roamed, the users' home node would be informed of non-delivery, then when the user logged on from another location, the message will be passed back to home node and then the user could be sent the message once logged on elsewhere.
For more information, contact Paula:
Packet: G8pzt@gb7pzt.#24.gbr.eu
Email: G8pzt[at]blueyonder.co.uk
Or visit her website: http://pzt.org.uk/gnet
Anthony introduced his talk by referring to the problems posed to network development by the current restrictions on 70cms node clearance. He quoted from the TVIPUG website, saying "our main network which we have painstakingly built operates at 9k6 full duplex on 70cms. There are to our knowledge no designs for transceivers for high speed data for higher bands which are readily reproducible."
His talk was aimed at proposing a 2.3GHz transceiver, which could enable the packet data network to be plugged where there are holes - and continue developing into higher transfer rates.
A suitable transceiver exists and is being used by the military - delegates were shown pictures of this - and it could be modified for use with KISS, particularly as this made it independent of modulation being used. It could be accessed by other devices - PCs, Palmtops, Unix devices etc. As the 2.4GHz module is widely obtainable, it can be bought at reasonable cost.
These PRRs (Personal role radios) have been used by the Army when they realised the value of these radios over shouting at each another. Every soldier can be equipped with these high volume, low cost, hands free devices.
Anthony demonstrated the module block diagram of the radio, going on to outline the specifications of the RF operation. The microcontroller was described along with the hardware adaptations required for individual amteur use.
Anthony outlined the software adaptations still required. It would have to run with KISS protocol, using control packets to set frequency and power. Test modes would be needed (a licence requirement) - for measuring frequency, power, etc.
The difficulties of the project were addressed. The unit has only small RAM and so there is a shortage of buffer space, with significant limits on MAXFRAME and MAXWIN. With additional limits on MTU, packet fragmentation is forced. Data is passed via the serial port (with maximum standard rate of 19200) but other options might be possible.
The frequency of transmission would be 2.3GHz (the unit can be re-tuned down from its usual 2.4GHz. Within the allocated amateur band, transmissions of 1Mz bandwidth were anticipated.
Anthony reported the status of the project as having 4 RF modules tested, 2 case units built and tested, and having parts for 2 more. An ISP has been built and tested (with Win9x/NT). Ongoing work included AVR KISS firmware, a demonstration network, trial links, and antenna experiments.
Anthony illustrated the properties of the 2.3GHz deployment as compared to a 2m operation. The distance covered is considerably less (obstacles such as tree leaves are significant at this frequency) and so there would be a pressing need for a "mesh" type network to be developed, in order for data to be successfully passed between distant users. Every station would need to digipeat for this to work properly.
Delegates were interested in the project and asked how soon before members of public could buy into the project? Anthony said that modules should be available soon, but as to who would build and design the boards, this was unclear.
He also discussed the possible use of higher specification chips, but concluded that it would be advisable to use what is currently in the existing hardware.
The wider viability of the project was raised. Even with units retailing possibly as low as £25, how would we get one in every street? Nonetheless experimentation with the devices was encouraged, along with experimental development of suitable dishes.
For further information on the project, consult the following websites:
http://homepage.ntlworld.com/mtn/ (but this may not last long)
http://www.m1fde.org.uk/ (under development)
http://www.g0mwt.org.uk/ Chelmsford ARC
Also Anthony may be contacted as follows:
m1fde[at]g0mwt.org.uk
Original Text of ARMAPS Presentation
Paula explained that the presentation was being given on behalf of Phil Cadman G4JCP who couldn’t attend the conference, but whose ideas on what is a new packet radio system closely resembled a project she had been working on for the last 3 years.
Amateur Radio Messaging and Paging System (ARMAPS) is a proposed protocol about how AX25-compatible data can be passed efficiently over radio links to support both new and existing packet applications. Being merely ideas at this stage, no software or hardware exists, although a development board is in preparation.
The focus of ARMAPS is on one-to-one QSOs, rather than accessing BBSs, DX Clusters, APRS, etc. The problem with packet QSOs is the need for acknowledgements. The AX25 protocol can handle unconnected message packets, but UI frames are not acknowledged, so you don't know whether they've got through or not. It doesn't matter with APRS; packets are continually transmitted at regular intervals. But a single message needs an acknowledgement.
Paula explained the thinking that packet needs not just one protocol but a whole suite of related protocols, each protocol being optimised for a specific task or radio channel. Similarly, the protocols should be made available for several micro-controller, modem and memory configurations, so the hardware too can be designed and optimised for a given application. Both hard and software should be as simple as possible, so long as the efficiency of the system is not impaired, nor its potential for expansion compromised. Moreover, unlike APRS for example, the system should not be owned or controlled by any one person or group; it should be completely open for anyone to develop.
The specific novelty of ARMAPS is the introduction of messaging and paging to amateur packet radio. In both cases, messaging and paging would use numbered but unconnected packets - messaging would employ packets which are directed to a single recipient who acknowledges each packet, and paging would use packets which are not acknowledged and so may be directed to any number of possible recipients.
The proposal also considers how to reduce considerably the problem of packet collisions during data transmission over radio links. The ARMAPS protocol would avoid collisions by two methods: Firstly by not having a "free for all", and secondly, where a free for all is unavoidable, having very low channel occupancy, say less than 10%. ARMAPS would achieve this by using a protocol whereby one station would actively control the flow of packets on a channel, in the same way as on voice nets, where the net controller decides who can speak at any one time.
To allow new stations to be able to join in, and to let stations already in the net signal their departure to the net controller, the example of emergency services could be adopted, whereby a full-duplex base station indicates to other mobiles when a mobile is transmitting (the pip-pip-pip sound).
Concentrating firstly on paging packets, Paula outlined the transmission protocol whereby these packets would be sent from one to seven times. Packets would be transmitted in the sequence they are received from the application, and each packet would only be transmitted when the previous packet has been transmitted the designated number of times. She ventured that we should look at adding FEC to paging packets to make them more resilient.
Paging packets would normally have relatively few data bytes to minimise packet loss and assist those hardware applications that might have small amounts of RAM. Moreover, as paging receivers may well have battery savers, paging transmitters should always transmit two seconds of unmodulated carrier before transmitting data.
The system software does not explicitly acknowledge paging packets, however the applications programs that use them can acknowledge them. Paging packets can be used for any purpose and they can be fast, because with no waiting for acknowledgements, they can (potentially) be sent one after another with no gaps.
Paula turned next to the basics of messaging packets. Like paging packets, messaging packets would also be sent from one to seven times. And again, there would be only one packet outstanding at any time. If an acknowledgement weren’t received within a pre-set time, the packet would be sent again. There should be no need for wasteful Receive-Ready packets as in AX25, since the loss of a packet should be very much the exception.
Full-duplex point-to-point links might have more than one packet outstanding, perhaps two or three, as one packet could be transmitted while an acknowledgement for the previous packet was being received. Not waiting for the corresponding acknowledgement would mean that there need be no gaps between transmitted packets. Transmitters on full-duplex links would not cut carrier between packets. They would only cut carrier when there had been no packet traffic for 30 seconds or more.
Paula then went on to describe the proposed packet format. Like AX25, the packets envisaged under the ARMAPS system would be delimited by the usual HDLC flags and will use bit stuffing and NRZI coding. The first byte after the opening flag would be a packet type identifier. Chips like the 85C30 can be instructed to look for a specific address or group of addresses and would only respond to packets with those addresses. The first address byte of an AX25 packet always has the LSB clear, so if we always set the LSB in the ARMAPS packet type byte, then ARMAPS TNCs can distinguish between the two protocols. Hence we can have a TNC that can handle both AX25 and ARMAPS packets.
All ARMAPS paging packets would have the top bit set. And paging packets that begin binary 1111xxxx, would be reserved for internal system use. Paging packets with a type code of 0x80 to 0xEF would be user-definable. If the top bit of the packet type byte were clear - 0x00 to 0x7F - then it would be defining a messaging packet. All codes are user definable.
To allow for very long callsigns, such as those used when you operate abroad, the source and destination address fields of ARMAPS packets would be of variable length, up to twelve characters long. Characters would be 7-bit plain ASCII, and the 8th bit would be zero. For paging use, the destination callsign could be any word, and paging receivers could be instructed to only respond to that word. This would allow paging users to share a channel.
The SSID would be a hexadecimal character 0 to 9, and A to F. The MSB would be set so as to identify the end of the callsign. The other three bits are unused at present. The network entry and exit addresses could be used for digipeating, or they could be the node callsigns of the entry and exit points to a network. If we use the Internet as a means of routing packets around the country, these fields could contain dotted quad IP addresses without the dots. The exit address could be specified by the originator for manual routing, or inserted later by the network software.
ARMAPS’ control bytes are not yet finalised. They might hold things like packet numbers, and distinguish data packets from acknowledgement packets. The data field could be zero up to 256 bytes. This will usually be 7-bit ASCII, delimited by ASCII control characters, but some packets would need to carry pure binary so the packet’s control bytes will identify binary packets and give the length of the binary payload. Finally, the frame check sequence will use the usual AX25 CRC, over all the bytes between the opening and closing flags.
Paula turned next to the hardware side of ARMAPS. On the messaging side, the hardware could be based on industry-standard 8032 micro-controller devices. An Am85C30 could handle much of the packet formatting, generation and checking. The amount and type of memory required would be flexible so as to accommodate both simple and more complex applications. On the paging side, much simpler hardware will be more appropriate (on cost, size and power requirement grounds), with the Microchip PIC family of micro-controllers, already widely used by amateur radio and electronics enthusiasts, being ideal candidates.
Concerning baud rate of transmission, the preferred option is 1200 or 2400, making it easy to interface any rig or handheld with minimal effort. For 1200 bauds, the FX614 modem chip was suggested, and for 1200/2400bd, the FX469. Samples of each were available for any interested parties.
Paula indicated that it is envisaged that the software for this project will be 'free software', licensed under the GNU General Public Licence. Once the basic protocols have been implemented in software and released under the GNU GPL, individual amateurs will be able easily to add their own specific software modules to provide whatever additional functions they require. As an aid to developing the software side of ARMAPS, Paula mentioned the Small Devices C Compiler (SDCC), which is primarily aimed at the 8032 and related processors. It's free, being released under the GNU GPL, it runs under both Win32 and Linux, and a shiny new version has just been released. It's a proper C compiler that comes with an associated assembler and linker.
Finally, Paula referred to the following, as being sources of further
information:
http://www.armaps.org
G4JCP@GB7PZT.#24.GBR.EU
The May 2004 edition of "Practical Wireless"
During the ensuing question and answer session, delegates felt that the flag bytes should be readable by AX25, to enable co-existence on joint ARMAPS/AX25 frequencies. Ideally the ARMAPS protocol would be included inside AX25. Paula was encouraged to consider having these ideas presented to the Data Conference in the USA.
Anthony’s presentation aimed to show the conference how amateur radio can create a wireless LAN (local area network) particularly on the 2.4GHz amateur frequency, mirroring the more professional applications of this phenomenon.
Illustrating his talk with many graphics, Anthony began by explaining how radio is used as an alternative to wired networks, linking computer systems. He outlined the various "architectures" or ways in which these networks are constructed.
The "peer to peer" approach simply links computers via one-to-one links, whereas access points (to which a cluster of computers are linked) are common. Radio can link computers to access points, or access points to each other, or both. Radio can be used to enable portable computer users to remain in touch with an established network. The preferred network structure is a "mesh" where multiple links are made between computers and access points.
Devices which use wireless to link to (or provide links within) a network were illustrated, including PMCIA cards, USB and PCI devices, personal mobile devices such as WLAN enabled PDAs and WLAN VOIP phones.
Anthony continued his introduction by outlining the protocols currently in use and their associated frequencies and speeds of operation. 802.11 is for 1 & 2Mbps traffic, 802.11b is for 2.4GHz 5.5 & 11Mb/s traffic, 802.11a is for 5GHz 54Mb/s traffic, and 802.11g is for 2.4GHz at 22-54Mb/s. The term Wi-Fi (Wireless Fidelity) is used to describe generically the use of radio for computer networking.
Two methods of wireless modulation were outlined. DSSS (Direct Sequence Spread Spectrum) was one method used. Based on PSK or QPSK (phase modulation), it uses a higher-rate chipping code to widen spectrum, but uses more than the necessary bandwidth. Its advantage is that it provides immunity from narrowband interferers. The second method, OFDM (Orthogonal Frequency Division Multiplex) uses multiple modulated carriers and uses all available bandwidth. The more technical aspects of 1mbps and 5.5mbps CCK modulation were illustrated, from input data to final transmission
Anthony explained that the wireless traffic in a WLAN channel needs to be arbitrated or coordinated. DCF (Distributed coordination function) operates by sensing collisions and backing off, as well as having a contention-resolution phase (as with RTS/CTS), seizing the air around both stations before sending traffic. PCF (Point coordination function) requires access points to manage timeslots. Moreover, the headers of packets are transmitted in common 1Mbps format, after which the modulation is switched for the payload. By these methods, data rates are auto-negotiated and can remain adaptive.
The range of hardware and software compliant with these standards is wide and is an invitation to amateurs to take advantage of the facility for amateur application - using distributed networks, access points connected by fixed links, with routed, bridged or "mesh" architectures.
Anthony then went on to talk about security within the WLAN. WEP ("wired equivalent privacy") is common but easily broken. It prevents accidental access but won’t stop serious attack. It requires a shared secret key, but it would be difficult to control its distribution. Also used is 802.11i WPA (AES encryption).
Because amateur radio cannot exchange coded information, the issue of security is a problem. Encryption is not permitted, although the hashing out of password is acceptable. However MAC address filtering is a useful "closed door", despite the fact that addresses can be "sniffed" and cloned.
Moving on to transmit power, Anthony provided various examples. The maximum permitted is 20dBm (100mW), with typical usage being 18dBm (60mW), but with some stations operating as low as 30mW. For receive sensitivity, about 90dBm was suggested, with 80dBm being allowed by the 802.11 specifications. 55dB between transmit and receive was required (on different channels) and a separation of dipoles in the order of 10m was recommended.
Anthony illustrated the various 802.11 Channels, of which 6 fall within the amateur bands, namely:
| Ch | Frequency |
| 1 | 2412MHz |
| 2 | 2417MHz |
| 3 | 2422MHz |
| 4 | 2427MHz |
| 5 | 2432MHz |
| 6 | 2437MHz |
The range of Wi-Fi was outlined, with the greatest distance (ca. 100m) being achievable when using 1mbps transmissions. The range decreases with the speed of transmission, dropping to around 20m at 54mbps.
The features and benefits of various antennas and boosters were presented - collinear dipoles, biquads, dishes, disk Yagis, slotted waveguides and chip antennas. The access point hardware Linksys WET-11 (802.11b - 11Mb/s, Interface: 10baseT) was recommended.
Anthony finished by pointing delegates in the direction of G8OTA, as a person with expertise in this area, along with the website www.wlan.org.uk, from where details of a mailing list can be obtained.
Further contacts and links were as follows:
Antennas
http://www.trevormarshall.com
http://www.poynting.co.za/tech_training/diskyagi.shtml
Anthony Martin M1FDE
http://homepage.ntlworld.com/mtn/
http://www.m1fde.org.uk
Email: m1fde(at)g0mwt.org.uk
Book
"802.11 Wireless Networks" - Matthew S. Gast - O’reilly
Standards
http://www.wi-fi.org
http://www.ieee802.org
http://standards.ieee.org/getieee802/
During the question and answer session, Anthony was asked about the need for CW ID (required if operating unattended) and site clearance (not required). He was less clear on the need for an NoV.
Mention was also made of G0GON in Exmouth who has an interest in this area.
The need to disassemble some WLAN cards to gain access to a hot-wiring point for an external antenna was mentioned, as not all cards have external antenna points.
XARPM is the acronym for Linux Amateur Radio Packet Mailbox, a joint project between Ian, G6VEY and Stuart, G0LGS, with Colin, G1IXV as a beta tester. The presentation was to show delegates the main features of this software, and was mainly comprised of pictures illustrating the GUI of the program, with accompanying explanations.
The program can be obtained free of charge from http://www.xarpm.org.uk and is simple to install and configure, particularly for those already familiar with such programs as WinPack and Sally, but also for those familiar with email programs such as Outlook; the interface and functionality of XARPM reflects several aspects of all these.
Beyond the standard functions, XARPM’s various servers were alluded to; the address book, the 7Plus server, the module manager, the update manager, the mail editor, etc. Its use of the "Festival" voice/sound server was a point of interest.
The versatility of the program was underlined - including its colour configurability. As well as standard telnet facilities, its monitoring capacity was a strong point, overlaying Linux’s own "Listen" facility.
XARPM has users throughout the world, who can make use of its Vconv facility - a converse client, again linked to "Festival", capable of private mode operation.
The program is still in development and the inclusion of password configuration and compressed mail forwarding is planned. However a port to Solaris/UNIX/Windows is not envisaged.
For further information, contact may be made with the author, Ian Haver
G6VEY, as follows:
G6vey@gb7yfs.ampr.org
G6VEY@GB7YFS.#26.GBR.EU
Or via the GB7YFS web site - http://www.gb7yfs.org.uk
Nick had been asked to report to conference the latest news about the restrictions in force in the 70cms band, given that for several months now no site clearances were being granted to amateur applicants.
Nick reported that the origins of this restriction apparently lay in East Anglia where a major installation was being planned by the MoD on behalf of a third party. This third party had requested there to be no further 70cms activity.
The MoD had asked the RSGB for information about amateur activity in the 70cms band, but this request had been declined on the grounds of data protection. The blanket ban by the MoD on further clearances had followed this refusal.
Geoff Hoon had been asked to justify this UK-wide ban - particularly since existing 70cms activity was being allowed to continue unrestricted - but no answer had been supplied at the time of the conference (a month or so after the question was raised). The possibility of a question in the House was mentioned.
Some PMR users had been affected by this ban - with some being taken off air - and there were some lawsuits against the MoD occurring owing to loss of business.
Nick went on to mention that the support of OfCom could not be enlisted, as the organisation has no control over that part of the spectrum. He also commented on the nature of the organisation, observing how various departments were concerned with policy alone (but were ignorant of RF matters) whereas other departments were engineering only (and found themselves sometimes constrained by the decisions made by RF-ignorant policy makers).
He also outlined the plan to liberalise the 2.0-2.4GHz band and make it a licence exempt section. Telecommunications companies would be free to use up to 40dBW (10,000W) in this band, as they develop 3rd/4th generation mobile technology. The amateur participation in the 2.3GHz area is therefore potentially under threat.
Finally Nick mentioned the plan to bring forward the shutdown of analogue TV broadcasts. Affected users would most likely be given digital-to-analogue converters. Of interest to amateurs is the freeing up of the slots in the existing TV bands, and it was hoped that the RSGB would be asking for a couple of 1MHz slots for amateur usage.
(This item was led by Paula G8PZT, who first presented the topic in depth and then went on to coordinate a discussion among delegates.)
Paula introduced her talk by pointing out that the packet network is now a hybrid, made up of both radio and Internet links. Opinions about the use of the Internet may differ, but it won't go away. Most importantly, the network works and is better than what was before. The issue before us is how best to manage and improve it.
Describing the network as it used to be, Paula observed how node tables were never full. The network topology was defined by terrain, with the consequence that some areas were badly served. Some links were slow and unreliable, meaning that real-time usage was not really feasible and leaving many users dissatisfied.
Nowadays we have huge nodes tables and much better connectivity. The network topology no longer depends on the terrain, and access to nodes worldwide is possible. As a result, real-time use is feasible in some places. Overall, users are offered a more satisfying service, although the new situation does put some strain on the network.
Paula cited firstly the huge node tables that are produced. These use lots of memory, and consume lots of bandwidth when broadcast. Some users want them because of the increased connectivity they offer; other users have no interest in them, because of the language and cultural barriers that arise.
Older software can suffer from these conditions; BPQ cannot cope with more than about 180 nodes; TheNet X1J seems to have a practical limit of just over 100. Both can become unstable or behave oddly, and BQP doesn’t easily support IP routing, making telnet over radio very difficult. Moreover BPQ’s static parameters can make it seem very slow at times on the modern fast network.
The presence of foreign software - notably Xnet - in the network brings problems of its own. Xnet puts out frequent nodes broadcasts, with rapid obsolescence. Its calculations of node qualities do not suit the UK network, and one of the main problems is that it bends routing towards its own nodes.
Paula further cited the problem of routing loops - where a packet follows a circular path through the network, never reaching its target, and resulting in level 4 connection failures. This is usually caused by delays in propagating routing changes, for example when a node dies, or goes invisible. With our network of older software, it can take several hours per hop for the node to disappear from all the tables, and if there is lots of connectivity this can end up in a loop.
Many "quality-related" problems can be resolved by using routing metrics based on round trip time rather than netrom quality. These give a true and up to date measure of the goodness of a route, and the sysops can’t mess with them. But they can’t be used everywhere, because there are some poor routes and old software in the network.
Using the newer metrics, we can restrict the number of hops accepted from each neighbour. Thus on the overseas nodes we can say we only want 1 hop, which is the neighbour itself, but none of his neighbours. We’ve tried limiting the overseas visibility by setting MINQUAL equal to the route quality, but it wasn’t so successful.
Paula observed that when foreign nodes creep in using Netrom qualities instead of time-based metrics, an effective way to restrict their numbers is to degrade the quality according to callsign. We can do this in such as way as to favour the countries according to their likelihood of anyone wanting to connect there.
In truth, the packet network probably contains too much connectivity and the disparities of software and quality setting makes it very difficult to manage. Ideally the node operators need to agree where Internet linking is necessary and agree figures concerning quality.
Discussion
The discussion that ensued re-iterated many of Paula’s concerns about the problems of legacy software, the intrusion of overseas links and of wanted/unwanted nodes, as well as the understandable but questionable desire of some operators to put on links simply out of personal interest.
It was agreed that the packet network should be coordinated, as far as was possible, without wishing to impose upon the goodwill of sysops, nor wanting to prevent experimentation. It was acknowledged that obtaining international agreements (to eliminate the disparity between the different qualities set as default by different countries, for example), was unworkable. It was hoped, however, that sysops here would talk more to each other about network issues, sharing best practice, with the aim of a more efficient network.
It was commented that it would be desirable to get some agreement at this meeting regarding a series of guidelines. The authority of the conference, however, precluded any "diktat" to sysops. Instead, conference hoped that all sysops would take note of these concerns and would work towards greater cooperation, as used to happen in the earlier days of packet.
Resolution
With this aim in view, it was agreed unanimously by delegates that a central website and a forum for discussion of issues relating to levels and links should be set up. Paula volunteered to instigate this and undertook to put out details over packet, inviting all to participate.
(As in the previous item, Paula G8PZT firstly presented the topic in depth and then went on to coordinate a discussion among delegates.)
Paula began by outlining the current demise of personal packet mail. Although bulletins reach all BBS’s (in spite of the closure of many mailboxes), private mail is unreliable, and as a consequence people are resorting to email instead.
The ways in which personal mail can get lost are various. The closure of BBS’s is a major factor, especially where neighbouring sysops have to re-arrange forwarding. The problem comes when more distant sysops are not aware of the closure; mail will then ping-pong, and the occasional ping pong message may get ignored. Also there is the regrettable problem of uninformed forwarding by lazy sysops.
UK mail forwarding operates by sending mail ever closer to its geographical destination. The UK is divided into 7 geographical regions with up to 9 sub-regions and a system of "right-to-left" hierarchical routing is used.
This system is not without its flaws. Poor cooperation between neighbouring sysops and packet groups led to non-delivery of mail. Geographical obstacles (notably the Pennines) used to mean that mail needed to be routed in a roundabout fashion - and the demise of links and intervening BBS’s means that these routes are no longer possible.
Not only national but also overseas mail delivery is compromised. The UK used to have packet SatGates in the north and the south, using HF forwarding links to carry personal mail. There is now only one SatGate (GB7LDI in East Anglia). Added to which, the former cross-channel VHF links to France are no longer operational.
Paula highlighted the main causes for this failure of the mail system. The closure of strategic BBS’s and other links is the main factor, but an absence of an overall plan as well as poor communication between sysops have contributed to the situation.
It is possible that there is insufficient interest in restoring functionality to the network. The sysop meetings that used to take place no longer occur. There is also no up-to-date information on active BBS’s (locations, frequencies, etc) despite the efforts of the DCC. In short there is a need for us not so much to tell each other what to do but instead to give information to sysops, for them to work towards restoring a more workable mail forwarding system.
A suggested way of addressing the situation is to move towards automatic mail routing, but this is not likely to meet with favour amongst all the sysops (as it involves them relinquishing control of forwarding files. Instead perhaps the best way forward is to share known information about ideal mail routes. We should have a national mail routing database, which all sysops can access via Internet or REQFIL. Armed with this information, sysops can put in place better mail routings, reducing unnecessary hops, relieving overused RF links and, most importantly, speeding up delivery.
Paula then mentioned the issue of Internet forwarding, commenting that this was a good resource but badly used. As a result again of poor coordination, there is much duplication of effort and also several areas that remain poorly served.
However, even with the increasing use of the Internet, the ideal of each BBS linking directly to each other BBS is impractical - there are about 100 BBS’s in UK, with thousands worldwide. Instead the more logical requirement for a pyramidal structure is already in place (and the software works with this, too) so the potential for successful mail delivery exists.
One way forward from the present uncoordinated situation is to have an agency system, whereby mail agents forward DIRECTLY to all BBS or agents in their area of responsibility. The agents and their areas could be published in a database. Under this scheme, areas could have more than one mail agent, and BBS’s could be agents for more than one area. Sysops would forward their mail either to an agent or to a tier above.
Paula went on to show a diagram of how this might work in the UK. At the top of the structure would be the regional agents (e.g. #1, #2, #3, etc.), capable of linking one to another. Linking to them - from below, but also possibly to each other - would be sub-regional agents (e.g. #15, #16, #25, #26, etc.). These would in turn serve the more local users of the packet network. Traffic could enter at any tier of this structure.
Conference was then shown a map of the UK with the locations of 10 Internet-linked BBS’s shown - with most English regions well served - illustrating Paula’s view that we already have the potential to put into place such an agency system, using these Internet-linked BBS’s as the top tier of the proposed structure. Admittedly not every sysop represented would necessarily wish to participate in this venture…
In conclusion, sysops were urged to exchange routing exchange information. There needed to be a well-known resource, available to all (via Internet or REQFIL) containing data that was updated directly by sysops.
Discussion
A range of responses was noted during the discussion. Some were unsure that there really was a problem with mail forwarding and advocated a test to check the goodness of the routes. One or two felt that, if the problem stemmed from the poor functioning of only a couple of BBS’s, then was it worth changing the national structure, particularly if sysops would not unanimously welcome and implement the change.
Although the value of hierarchical routing was acknowledged in theory, there was concern about its performance under failure conditions. There would need to be backup routes in place, but these would need careful planning to avoid loss of mail during sending via duplicate routes.
A query arose over the status of GB7LDI. It was believed by some that no further satellite forwarding was taking place. This view was challenged, however, by a couple of delegates, who urged sysops to maintain their routing of international mail towards Norwich. It was acknowledged that there were unreliable links into the rest of the country from GB7LDI, but conference was told that mail continues to flow and plans continue to be made to improve the link.
The value of a central information source about national routing was recognised. The concerns about it were threefold: firstly, could the cooperation of sysops be guaranteed? Secondly, who would maintain the data resource? And thirdly, how best should the data be presented?
Resolution
It was agreed that a central resource would be set up and maintained by Paula, G8PZT. This would be available on the Internet at http://pzt.org.uk/nts/ (and as a REQFIL for packet users?). This would be advertised by means of the conference minutes and by other messages put out to sysops on packet.
It was agreed that delegates would encourage their local sysops to consult the page, update their details, and update their routing/forwarding files, as necessary.
It was agreed that this issue would be considered again at next year’s packet conference, with a view to reviewing the situation.
Conference noted with satisfaction that the problem of @GBR bulletins being routed abroad (discussed at the 2003 Conference) seems to have been resolved. Thanks were expressed to sysops for their cooperation.
The Chairman announced that, FourPak having offered to cover the costs of the conference, there was no obligation for delegates to subsidise the event. Nonetheless contributions would be gladly received.
In conclusion, he thanked delegates for coming - some quite a distance - and looked forward to next year. Particular thanks were expressed to Paula for her considerable input.
Mike G7RAZ Minutes Secretary